draft-ietf-lisp-multicast-08.txt   draft-ietf-lisp-multicast-09.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental J. Zwiebel Intended status: Experimental J. Zwiebel
Expires: March 12, 2012 S. Venaas Expires: April 7, 2012 S. Venaas
cisco Systems cisco Systems
September 9, 2011 October 5, 2011
LISP for Multicast Environments LISP for Multicast Environments
draft-ietf-lisp-multicast-08 draft-ietf-lisp-multicast-09
Abstract Abstract
This draft describes how inter-domain multicast routing will function This draft describes how inter-domain multicast routing will function
in an environment where Locator/ID Separation is deployed using the in an environment where Locator/ID Separation is deployed using the
LISP architecture. LISP architecture.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2012. This Internet-Draft will expire on April 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29
12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . . 35 16.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 36 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 36
A.1. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 36 A.1. Changes to draft-ietf-lisp-multicast-09.txt . . . . . . . 36
A.2. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 36 A.2. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 36
A.3. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 36 A.3. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 36
A.4. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 36 A.4. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 36
A.5. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 36 A.5. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 36
A.6. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 36 A.6. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 36
A.7. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 37 A.7. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 36
A.8. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 37 A.8. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 37
A.9. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 37 A.9. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 37
A.10. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
skipping to change at page 8, line 15 skipping to change at page 8, line 15
(S-RLOC,G) State: refers to multicast state in the core where S is (S-RLOC,G) State: refers to multicast state in the core where S is
a source locator (the IP address of a multicast ITR) of a site a source locator (the IP address of a multicast ITR) of a site
with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G)
entry by doing a mapping database lookup for the EID prefix that entry by doing a mapping database lookup for the EID prefix that
S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message
when it travels from an ETR to an ITR over the Internet core. when it travels from an ETR to an ITR over the Internet core.
uLISP Site: a unicast only LISP site according to [LISP] which has uLISP Site: a unicast only LISP site according to [LISP] which has
not deployed the procedures of this specification and therefore, not deployed the procedures of this specification and therefore,
for multicast purposes, follows the procedures from Section 9. for multicast purposes, follows the procedures from Section 9. A
uLISP site can be a traditional multicast site.
LISP Site: a unicast LISP site (uLISP Site) that is also multicast
capable according to the procedures in this specification.
mPETR: this is a multicast proxy-ETR that is responsible for mPETR: this is a multicast proxy-ETR that is responsible for
advertising a very coarse EID prefix which non-LISP and uLISP advertising a very coarse EID prefix which non-LISP and uLISP
sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs
are used so LISP source multicast sites can send multicast packets are used so LISP source multicast sites can send multicast packets
using source addresses from the EID namespace. mPETRs act as Proxy using source addresses from the EID namespace. mPETRs act as Proxy
ETRs for supporting multicast routing in a LISP infrastructure. ETRs for supporting multicast routing in a LISP infrastructure.
It is likely an uPITR [INTWORK] and a mPETR will be co-located It is likely an uPITR [INTWORK] and a mPETR will be co-located
since the single device advertises a coarse EID-prefix in the since the single device advertises a coarse EID-prefix in the
underlying unicast routing system. underlying unicast routing system.
Mixed Locator-Sets: this is a locator-set for a LISP database Mixed Locator-Sets: this is a locator-set for a LISP database
mapping entry where the RLOC addresses in the locator-set are in mapping entry where the RLOC addresses in the locator-set are in
both IPv4 and IPv6 format. both IPv4 and IPv6 format.
Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM
Join/Prune message (encapsulated in a LISP Encapsulated Control Join/Prune message (encapsulated in a LISP Encapsulated Control
Message with destination UDP port 4342) which is sent by ETRs at Message with destination UDP port 4342) which is sent by ETRs at
multicast receiver sites to an ITR at a multicast source site. multicast receiver sites to an ITR at a multicast source site.
This message is sent periodically as long as there are interfaces This message is sent periodically as long as there are interfaces
in the oif-list for the (S-EID,G) entry the ETR is joining for. in the OIF-list for the (S-EID,G) entry the ETR is joining for.
OIF-list: this is notation to describe the outgoing interface list
a multicast router stores per multicast routing table entry so it
knows what interfaces to replicate multicast packets on.
4. Basic Overview 4. Basic Overview
LISP, when used for unicast routing, increases the site's ability to LISP, when used for unicast routing, increases the site's ability to
control ingress traffic flows. Egress traffic flows are controlled control ingress traffic flows. Egress traffic flows are controlled
by the IGP in the source site. For multicast, the IGP coupled with by the IGP in the source site. For multicast, the IGP coupled with
PIM can decide which path multicast packets ingress. By using the PIM can decide which path multicast packets ingress. By using the
traffic engineering features of LISP, a multicast source site can traffic engineering features of LISP, a multicast source site can
control the egress of its multicast traffic. By controlling the control the egress of its multicast traffic. By controlling the
priorities of locators from a mapping database entry, a source priorities of locators from a mapping database entry, a source
multicast site can control which way multicast receiver sites join to multicast site can control which way multicast receiver sites join to
the source site. the source site.
At this point in time, we don't see a requirement for different At this point in time, there is no requirement for different locator-
locator-sets, priority, and weight policies for multicast than we sets, priority, and weight policies for multicast than there is for
have for unicast. However, when traffic engineering policies are unicast. However, when traffic engineering policies are different
different for unicast versus multicast flows, it will be desirable to for unicast versus multicast flows, it will be desirable to use
use multicast-based priority and weight values in Map-Reply messages. multicast-based priority and weight values in Map-Reply messages.
The fundamental multicast forwarding model is to encapsulate a The fundamental multicast forwarding model is to encapsulate a
multicast packet into another multicast packet. An ITR will multicast packet into another multicast packet. An ITR will
encapsulate multicast packets received from sources that it serves in encapsulate multicast packets received from sources that it serves in
a LISP multicast header. The destination group address from the a LISP multicast header. The destination group address from the
inner header is copied to the destination address of the outer inner header is copied to the destination address of the outer
header. The inner source address is the EID of the multicast source header. The inner source address is the EID of the multicast source
host and the outer source address is the RLOC of the encapsulating host and the outer source address is the RLOC of the encapsulating
ITR. ITR.
skipping to change at page 10, line 31 skipping to change at page 10, line 31
site. There is (S-RLOC,G) state across the core network from the site. There is (S-RLOC,G) state across the core network from the
ETR of the multicast receiver site to the ITR in the multicast ETR of the multicast receiver site to the ITR in the multicast
source site and (S-EID,G) state in the source multicast site. source site and (S-EID,G) state in the source multicast site.
Note, the (S-EID,G) state is the same S-EID in each multicast Note, the (S-EID,G) state is the same S-EID in each multicast
site. As other ETRs join the same multicast tree, they can join site. As other ETRs join the same multicast tree, they can join
through the same ITR (in which case the packet replication is through the same ITR (in which case the packet replication is
done in the core) or a different ITR (in which case the packet done in the core) or a different ITR (in which case the packet
replication is done at the source site). replication is done at the source site).
6. When a packet is originated by the multicast host in the source 6. When a packet is originated by the multicast host in the source
site, it will flow to one or more ITRs which will prepend a LISP site, the packet will flow to one or more ITRs which will prepend
header by copying the group address to the outer destination a LISP header. By copying the group address to the outer
address field and insert its own locator address in the outer destination address field, the ITR insert its own locator address
source address field. The ITR will look at its (S-RLOC,G) state, in the outer source address field. The ITR will look at its
where S-RLOC is its own locator address, and replicate the packet (S-RLOC,G) state, where S-RLOC is its own locator address, and
on each interface a (S-RLOC,G) joined was received on. The core replicate the packet on each interface a (S-RLOC,G) joined was
has (S-RLOC,G) so where fanout occurs to multiple sites, a core received on. The core has (S-RLOC,G) so where fanout occurs to
router will do packet replication. multiple sites, a core router will do packet replication.
7. When either the source site or the core replicates the packet, 7. When either the source site or the core replicates the packet,
the ETR will receive a LISP packet with a destination group the ETR will receive a LISP packet with a destination group
address. It will decapsulate packets because it has receivers address. It will decapsulate packets because it has receivers
for the group. Otherwise, it would have not received the packets for the group. Otherwise, it would have not received the packets
because it would not have joined. The ETR decapsulates and does because it would not have joined. The ETR decapsulates and does
a (S-EID,G) lookup in its multicast FIB to forward packets out a (S-EID,G) lookup in its multicast FIB to forward packets out
one or more interfaces to forward the packet to internal one or more interfaces to forward the packet to internal
receivers. receivers.
This architecture is consistent and scalable with the architecture This architecture is consistent and scalable with the architecture
presented in [LISP] where multicast state in the core operates on presented in [LISP] where multicast state in the core operates on
locators and multicast state at the sites operates on EIDs. locators and multicast state at the sites operates on EIDs.
Alternatively, [LISP] also has a mechanism where (S-EID,G) state can Alternatively, [LISP] also has a mechanism where (S-EID,G) state can
reside in the core through the use of RPF-vectors [RFC5496] in PIM reside in the core through the use of RPF-vectors [RFC5496] in PIM
Join/Prune messages. However, few PIM implementations support RPF Join/Prune messages. However, few PIM implementations support RPF
vectors and LISP should avoid S-EID state in the core. See Section 5 vectors and LISP should avoid S-EID state in the core. See Section 5
for details. for details.
However, we have some observations on the algorithm above. We can However, some observations can be made on the algorithm above. The
scale the control plane but at the expense of sending data to sites control plane can scale but at the expense of sending data to sites
which may have not joined the distribution tree where the which may have not joined the distribution tree where the
encapsulated data is being delivered. For example, one site joins encapsulated data is being delivered. For example, one site joins
(S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the
same multicast source site. Both multicast receiver sites join to same multicast source site. Both multicast receiver sites join to
the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
site. The ITR receives (S-RLOC,G) joins and populates the oif-list site. The ITR receives (S-RLOC,G) joins and populates the OIF-list
state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one
(S-RLOC,G) packets will be delivered by the core to both multicast (S-RLOC,G) packets will be delivered by the core to both multicast
receiver sites even though each have joined a single source-based receiver sites even though each have joined a single source-based
distribution tree. This behavior is a consequence of the many-to-one distribution tree. This behavior is a consequence of the many-to-one
mapping between S-EIDs and a S-RLOC. mapping between S-EIDs and a S-RLOC.
There is a possible solution to this problem which reduces the number There is a possible solution to this problem which reduces the number
of many-to-one occurrences of (S-EID,G) entries aggregating into a of many-to-one occurrences of (S-EID,G) entries aggregating into a
single (S-RLOC,G) entry. If a physical ITR can be assigned multiple single (S-RLOC,G) entry. If a physical ITR can be assigned multiple
RLOC addresses and these addresses are advertised in mapping database RLOC addresses and these addresses are advertised in mapping database
entries, then ETRs at receiver sites have more RLOC address options entries, then ETRs at receiver sites have more RLOC address options
and therefore can join different (RLOC,G) entries for each (S-EID,G) and therefore can join different (RLOC,G) entries for each (S-EID,G)
entry joined at the receiver site. It would not scale to have a one- entry joined at the receiver site. It would not scale to have a one-
to-one relationship between the number of S-EID sources at a source to-one relationship between the number of S-EID sources at a source
site and the number of RLOCs assigned to all ITRs at the site, but we site and the number of RLOCs assigned to all ITRs at the site, but
can reduce the "n" to a smaller number in the "n-to-1" relationship. "n" can reduce to a smaller number in the "n-to-1" relationship. And
And in turn, reduce the opportunity for data packets to be delivered in turn, reduce the opportunity for data packets to be delivered to
to sites for groups not joined. sites for groups not joined.
5. Source Addresses versus Group Addresses 5. Source Addresses versus Group Addresses
Multicast group addresses don't have to be associated with either the Multicast group addresses don't have to be associated with either the
EID or RLOC namespace. They actually are a namespace of their own EID or RLOC namespace. They actually are a namespace of their own
that can be treated as logical with relatively opaque allocation. that can be treated as logical with relatively opaque allocation.
So, by their nature, they don't detract from an incremental So, by their nature, they don't detract from an incremental
deployment of LISP-Multicast. deployment of LISP-Multicast.
As for source addresses, as in the unicast LISP scenario, there is a As for source addresses, as in the unicast LISP scenario, there is a
decoupling of identification from location. In a LISP site, packets decoupling of identification from location. In a LISP site, packets
are originated from hosts using their allocated EIDs, those addresses are originated from hosts using their allocated EIDs. EID addresses
are used to identify the host as well as where in the site's topology are used to identify the host as well as where in the site's topology
the host resides but not how and where it is attached to the the host resides but not how and where it is attached to the
Internet. Internet.
Therefore, when multicast distribution tree state is created anywhere Therefore, when multicast distribution tree state is created anywhere
in the network on the path from any multicast receiver to a multicast in the network on the path from any multicast receiver to a multicast
source, EID state is maintained at the source and receiver multicast source, EID state is maintained at the source and receiver multicast
sites, and RLOC state is maintained in the core. That is, a sites, and RLOC state is maintained in the core. That is, a
multicast distribution tree will be represented as a 3-tuple of multicast distribution tree will be represented as a 3-tuple of
{(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
skipping to change at page 14, line 12 skipping to change at page 14, line 12
will get the (S-EID,G) state only when the ETR sends it the next time will get the (S-EID,G) state only when the ETR sends it the next time
during its periodic sending procedures. during its periodic sending procedures.
7. Multicast Protocol Changes 7. Multicast Protocol Changes
A number of protocols are used today for inter-domain multicast A number of protocols are used today for inter-domain multicast
routing: routing:
IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for
LISP-Multicast for two reasons. One being that they are link- LISP-Multicast for two reasons. One being that they are link-
local and not used over site boundaries and second they advertise local and not used over site boundaries and second, they advertise
group addresses that don't need translation. Where source group addresses that don't need translation. Where source
addresses are supplied in IGMPv3 and MLDv2 messages, they are addresses are supplied in IGMPv3 and MLDv2 messages, they are
semantically regarded as EIDs and don't need to be converted to semantically regarded as EIDs and don't need to be converted to
RLOCs until the multicast tree-building protocol, such as PIM, is RLOCs until the multicast tree-building protocol, such as PIM, is
received by the ETR at the site boundary. Addresses used for IGMP received by the ETR at the site boundary. Addresses used for IGMP
and MLD come out of the source site's allocated addresses which and MLD come out of the source site's allocated addresses which
are therefore from the EID namespace. are therefore from the EID namespace.
MBGP: Even though MBGP is not a multicast routing protocol, it is MBGP: Even though MBGP is not a multicast routing protocol, it is
used to find multicast sources when the unicast BGP peering used to find multicast sources when the unicast BGP peering
skipping to change at page 15, line 8 skipping to change at page 15, line 8
in the BGP routing tables in the core. MSDP peering addresses can in the BGP routing tables in the core. MSDP peering addresses can
come out of either the EID or a routable address namespace. And come out of either the EID or a routable address namespace. And
the choice can be made unilaterally because the ITR at the site the choice can be made unilaterally because the ITR at the site
will determine which namespace the destination peer address is out will determine which namespace the destination peer address is out
of by looking in the mapping database service. There are no MSDP of by looking in the mapping database service. There are no MSDP
protocol changes required to support LISP-Multicast. protocol changes required to support LISP-Multicast.
PIM-SSM: In the simplest form of distribution tree building, when PIM-SSM: In the simplest form of distribution tree building, when
PIM operates in SSM mode, a source distribution tree is built and PIM operates in SSM mode, a source distribution tree is built and
maintained across site boundaries. In this case, there is a small maintained across site boundaries. In this case, there is a small
modification to the operation of the PIM protocol (but not to any modification to the operation of the PIM protocol. No
message format) to support taking a Join/Prune message originated modifications to any message format, but to support taking a Join/
inside of a LISP site with embedded addresses from the EID Prune message originated inside of a LISP site with embedded
namespace and converting them to addresses from the RLOC namespace addresses from the EID namespace and converting them to addresses
when the Join/Prune message crosses a site boundary. This is from the RLOC namespace when the Join/Prune message crosses a site
similar to the requirements documented in [RFC5135]. boundary. This is similar to the requirements documented in
[RFC5135].
PIM-Bidir: Bidirectional PIM is typically run inside of a routing PIM-Bidir: Bidirectional PIM is typically run inside of a routing
domain, but if deployed in an inter-domain environment, one would domain, but if deployed in an inter-domain environment, one would
have to decide if the RP address of the shared-tree would be from have to decide if the RP address of the shared-tree would be from
the EID namespace or the RLOC namespace. If the RP resides in a the EID namespace or the RLOC namespace. If the RP resides in a
site-based router, then the RP address is from the EID namespace. site-based router, then the RP address is from the EID namespace.
If the RP resides in the core where RLOC addresses are routed, If the RP resides in the core where RLOC addresses are routed,
then the RP address is from the RLOC namespace. This could be then the RP address is from the RLOC namespace. This could be
easily distinguishable if the EID address were well-known address easily distinguishable if the EID address were well-known address
allocation block from the RLOC namespace. Also, when using allocation block from the RLOC namespace. Also, when using
Embedded-RP for RP determination [RFC3956], the format of the Embedded-RP for RP determination [RFC3956], the format of the
group address could indicate the namespace the RP address is from. group address could indicate the namespace the RP address is from.
However, refer to Section 10 for considerations core routers need However, refer to Section 10 for considerations core routers need
to make when using Embedded-RP IPv6 group addresses. When using to make when using Embedded-RP IPv6 group addresses. When using
Bidir-PIM for inter-domain multicast routing, it is recommended to Bidir-PIM for inter-domain multicast routing, it is recommended to
use staticly configured RPs so core routers think the Bidir group use staticly configured RPs. Allowing core routers to associate a
is associated with an ITR's RLOC as the RP address and site Bidir group's RP address with an ITR's RLOC address. And site
routers think the Bidir group is associated with the site resident routers to associate the Bidir group's RP address as an EID
RP with an EID address. With respect to DF-election in Bidir PIM, address. With respect to DF-election in Bidir PIM, no changes are
no changes are required since all messaging and addressing is required since all messaging and addressing is link-local.
link-local.
PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is
deployed in the Internet today is by having shared-trees within a deployed in the Internet today is by having shared-trees within a
site and using source-trees across sites. By the use of MSDP and site and using source-trees across sites. By the use of MSDP and
PIM-SSM techniques described above, we can get multicast PIM-SSM techniques described above, multicast connectivity can
connectivity across LISP sites. Having said that, that means occur across LISP sites. Having said that, that means there are
there are no special actions required for processing (*,G) or no special actions required for processing (*,G) or (S,G,R) Join/
(S,G,R) Join/Prune messages since they all operate against the Prune messages since they all operate against the shared-tree
shared-tree which is site resident. Just like with ASM, there is which is site resident. Just like with ASM, there is no (*,G) in
no (*,G) in the core when LISP-Multicast is in use. This is also the core when LISP-Multicast is in use. This is also true for the
true for the RP-mapping mechanisms Auto-RP and BSR. RP-mapping mechanisms Auto-RP and BSR.
Based on the protocol description above, the conclusion is that there Based on the protocol description above, the conclusion is that there
are no protocol message format changes, just a translation function are no protocol message format changes, just a translation function
performed at the control-plane. This will make for an easier and performed at the control-plane. This will make for an easier and
faster transition for LISP since fewer components in the network have faster transition for LISP since fewer components in the network have
to change. to change.
It should also be stated just like it is in [LISP] that no host It should also be stated just like it is in [LISP] that no host
changes, whatsoever, are required to have a multicast source host changes, whatsoever, are required to have a multicast source host
send multicast packets and for a multicast receiver host to receive send multicast packets and for a multicast receiver host to receive
skipping to change at page 17, line 18 skipping to change at page 17, line 18
packet formats specified in [LISP]. However, encapsulating a packet formats specified in [LISP]. However, encapsulating a
multicast packet from an ITR is a much simpler process. The process multicast packet from an ITR is a much simpler process. The process
is simply to copy the inner group address to the outer destination is simply to copy the inner group address to the outer destination
address. And to have the ITR use its own IP address (its RLOC) as address. And to have the ITR use its own IP address (its RLOC) as
the source address. The process is simpler for multicast because the source address. The process is simpler for multicast because
there is no EID-to-RLOC mapping lookup performed during packet there is no EID-to-RLOC mapping lookup performed during packet
forwarding. forwarding.
In the decapsulation case, the ETR simply removes the outer header In the decapsulation case, the ETR simply removes the outer header
and performs a multicast routing table lookup on the inner header and performs a multicast routing table lookup on the inner header
(S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is (S-EID,G) addresses. Then the OIF-list for the (S-EID,G) entry is
used to replicate the packet on site-facing interfaces leading to used to replicate the packet on site-facing interfaces leading to
multicast receiver hosts. multicast receiver hosts.
There is no Data-Probe logic for ETRs as there can be in the unicast There is no Data-Probe logic for ETRs as there can be in the unicast
forwarding case. forwarding case.
8.1. ITR Forwarding Procedure 8.1. ITR Forwarding Procedure
The following procedure is used by an ITR, when it receives a The following procedure is used by an ITR, when it receives a
multicast packet from a source inside of its site: multicast packet from a source inside of its site:
skipping to change at page 17, line 40 skipping to change at page 17, line 40
1. A multicast data packet sent by a host in a LISP site will have 1. A multicast data packet sent by a host in a LISP site will have
the source address equal to the host's EID and the destination the source address equal to the host's EID and the destination
address equal to the group address of the multicast group. It is address equal to the group address of the multicast group. It is
assumed the group information is obtained by current methods. assumed the group information is obtained by current methods.
The same is true for a multicast receiver to obtain the source The same is true for a multicast receiver to obtain the source
and group address of a multicast flow. and group address of a multicast flow.
2. When the ITR receives a multicast packet, it will have both S-EID 2. When the ITR receives a multicast packet, it will have both S-EID
state and S-RLOC state stored. Since the packet was received on state and S-RLOC state stored. Since the packet was received on
a site-facing interface, the RPF lookup is based on the S-EID a site-facing interface, the RPF lookup is based on the S-EID
state. If the RPF check succeeds, then the oif-list contains state. If the RPF check succeeds, then the OIF-list contains
interfaces that are site-facing and external-facing. For the interfaces that are site-facing and external-facing. For the
site-facing interfaces, no LISP header is prepended. For the site-facing interfaces, no LISP header is prepended. For the
external-facing interfaces a LISP header is prepended. When the external-facing interfaces a LISP header is prepended. When the
ITR prepends a LISP header, it uses its own RLOC address as the ITR prepends a LISP header, it uses its own RLOC address as the
source address and copies the group address supplied by the IP source address and copies the group address supplied by the IP
header the host built as the outer destination address. header the host built as the outer destination address.
8.1.1. Multiple RLOCs for an ITR 8.1.1. Multiple RLOCs for an ITR
Typically, an ITR will have a single RLOC address but in some cases Typically, an ITR will have a single RLOC address but in some cases
there could be multiple RLOC addresses assigned from either the same there could be multiple RLOC addresses assigned from either the same
or different service providers. In this case when (S-RLOC,G) Join/ or different service providers. In this case when (S-RLOC,G) Join/
Prune messages are received for each RLOC, there is a oif-list Prune messages are received for each RLOC, there is a OIF-list
merging action that must take place. Therefore, when a packet is merging action that must take place. Therefore, when a packet is
received from a site-facing interface that matches on a (S-EID,G) received from a site-facing interface that matches on a (S-EID,G)
entry, the interfaces of the oif-list from all (RLOC,G) entries entry, the interfaces of the OIF-list from all (RLOC,G) entries
joined to the ITR as well as the site-facing oif-list joined for joined to the ITR as well as the site-facing OIF-list joined for
(S-EID,G) must be part be included in packet replication. In (S-EID,G) must be part be included in packet replication. In
addition to replicating for all types of oif-lists, each oif entry addition to replicating for all types of OIF-lists, each oif entry
must be tagged with the RLOC address, so encapsulation uses the outer must be tagged with the RLOC address, so encapsulation uses the outer
source address for the RLOC joined. source address for the RLOC joined.
8.1.2. Multiple ITRs for a LISP Source Site 8.1.2. Multiple ITRs for a LISP Source Site
Note when ETRs from different multicast receiver sites receive Note when ETRs from different multicast receiver sites receive
(S-EID,G) joins, they may select a different S-RLOC for a multicast (S-EID,G) joins, they may select a different S-RLOC for a multicast
source site due to policy (the multicast ITR can return different source site due to policy (the multicast ITR can return different
multicast priority and weight values per ETR Map-Request). In this multicast priority and weight values per ETR Map-Request). In this
case, the same (S-EID,G) is being realized by different (S-RLOC,G) case, the same (S-EID,G) is being realized by different (S-RLOC,G)
skipping to change at page 18, line 45 skipping to change at page 18, line 45
discarded. discarded.
8.2. ETR Forwarding Procedure 8.2. ETR Forwarding Procedure
The following procedure is used by an ETR, when it receives a The following procedure is used by an ETR, when it receives a
multicast packet from a source outside of its site: multicast packet from a source outside of its site:
1. When a multicast data packet is received by an ETR on an 1. When a multicast data packet is received by an ETR on an
external-facing interface, it will do an RPF lookup on the S-RLOC external-facing interface, it will do an RPF lookup on the S-RLOC
state it has stored. If the RPF check succeeds, the interfaces state it has stored. If the RPF check succeeds, the interfaces
from the oif-list are used for replication to interfaces that are from the OIF-list are used for replication to interfaces that are
site-facing as well as interfaces that are external-facing (this site-facing as well as interfaces that are external-facing (this
ETR can also be a transit multicast router for receivers outside ETR can also be a transit multicast router for receivers outside
of its site). When the packet is to be replicated for an of its site). When the packet is to be replicated for an
external-facing interface, the LISP encapsulation header are not external-facing interface, the LISP encapsulation header are not
stripped. When the packet is replicated for a site-facing stripped. When the packet is replicated for a site-facing
interface, the encapsulation header is stripped. interface, the encapsulation header is stripped.
2. The packet without a LISP header is now forwarded down the 2. The packet without a LISP header is now forwarded down the
(S-EID,G) distribution tree in the receiver multicast site. (S-EID,G) distribution tree in the receiver multicast site.
skipping to change at page 20, line 21 skipping to change at page 20, line 21
9.1. LISP and non-LISP Mixed Sites 9.1. LISP and non-LISP Mixed Sites
Since multicast communication can involve more than two entities to Since multicast communication can involve more than two entities to
communicate together, the combinations of interworking scenarios are communicate together, the combinations of interworking scenarios are
more involved. However, the state maintained for distribution trees more involved. However, the state maintained for distribution trees
at the sites is the same regardless of whether or not the site is at the sites is the same regardless of whether or not the site is
LISP enabled or not. So most of the implications are in the core LISP enabled or not. So most of the implications are in the core
with respect to storing routable EID prefixes from either PA or PI with respect to storing routable EID prefixes from either PA or PI
blocks. blocks.
Before we enumerate the multicast interworking scenarios, we must Before enumerating the multicast interworking scenarios, let's define
define 3 deployment states of a site: 3 deployment states of a site:
o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
does today. The addresses for the site are globally routable. does today. The addresses for the site are globally routable.
o A site that deploys LISP for unicast routing. The addresses for o A site that deploys LISP for unicast routing. The addresses for
the site are not globally routable. Let's define the name for the site are not globally routable. Let's define the name for
this type of site as a uLISP site. this type of site as a uLISP site.
o A site that deploys LISP for both unicast and multicast routing. o A site that deploys LISP for both unicast and multicast routing.
The addresses for the site are not globally routable. Let's The addresses for the site are not globally routable. Let's
define the name for this type of site as a LISP-Multicast site. define the name for this type of site as a LISP-Multicast site.
We will not consider a LISP site enabled for multicast purposes only What will not be considered is a LISP site enabled for multicast
but do consider a uLISP site as documented in [INTWORK]. In this purposes only but do consider a uLISP site as documented in
section we don't discuss how a LISP site sends multicast packets when [INTWORK]. In this section there is no discussion how a LISP site
all receiver sites are LISP-Multicast enabled; that has been sends multicast packets when all receiver sites are LISP-Multicast
discussed in previous sections. enabled; that has been discussed in previous sections.
The following scenarios exist to make LISP-Multicast sites interwork The following scenarios exist to make LISP-Multicast sites interwork
with non-LISP-Multicast sites: with non-LISP-Multicast sites:
1. A LISP site must be able to send multicast packets to receiver 1. A LISP site must be able to send multicast packets to receiver
sites which are a mix of non-LISP sites and uLISP sites. sites which are a mix of non-LISP sites and uLISP sites.
2. A non-LISP site must be able to send multicast packets to 2. A non-LISP site must be able to send multicast packets to
receiver sites which are a mix of non-LISP sites and uLISP sites. receiver sites which are a mix of non-LISP sites and uLISP sites.
skipping to change at page 21, line 34 skipping to change at page 21, line 34
LISP-NAT allows a unicast packet that exits a LISP site to get its LISP-NAT allows a unicast packet that exits a LISP site to get its
source address mapped to a globally routable address before the ITR source address mapped to a globally routable address before the ITR
realizes that it should not encapsulate the packet destined to a non- realizes that it should not encapsulate the packet destined to a non-
LISP site. For a multicast packet to leave a LISP site, distribution LISP site. For a multicast packet to leave a LISP site, distribution
tree state needs to be built so the ITR can know where to send the tree state needs to be built so the ITR can know where to send the
packet. So the receiver multicast sites need to know about the packet. So the receiver multicast sites need to know about the
multicast source host by its routable address and not its EID multicast source host by its routable address and not its EID
address. When this is the case, the routable address is the address. When this is the case, the routable address is the
(S-RLOC,G) state that is stored and maintained in the core routers. (S-RLOC,G) state that is stored and maintained in the core routers.
It is important to note that the routable address for the host cannot It is important to note that the routable address for the host cannot
be the same as an RLOC for the site because we want the ITRs to be the same as an RLOC for the site because it is desirable for ITRs
process a received PIM Join/Prune message from an external-facing to process a received PIM Join/Prune message from an external-facing
interface to be propagated inside of the site so the site-part of the interface to be propagated inside of the site so the site-part of the
distribution tree is built. distribution tree is built.
Using a globally routable source address allows non-LISP and uLISP Using a globally routable source address allows non-LISP and uLISP
multicast receiver to join, create, and maintain a multicast multicast receiver to join, create, and maintain a multicast
distribution tree. However, the LISP multicast receiver site will distribution tree. However, the LISP multicast receiver site will
want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
Prune message is received on a site-facing interface. It does this Prune message is received on a site-facing interface. It does this
because it wants to find a (S-RLOC,G) entry to Join in the core. So because it wants to find a (S-RLOC,G) entry to Join in the core. So
we have a conflict of behavior between the two types of sites. there is a conflict of behavior between the two types of sites.
The solution to this problem is the same as when an ITR wants to send The solution to this problem is the same as when an ITR wants to send
a unicast packet to a destination site but needs determine if the a unicast packet to a destination site but needs determine if the
site is LISP capable or not. When it is not LISP capable, the ITR site is LISP capable or not. When it is not LISP capable, the ITR
does not encapsulate the packet. So for the multicast case, when ETR does not encapsulate the packet. So for the multicast case, when ETR
receives a PIM Join/Prune message for (S-EID,G) state, it will do a receives a PIM Join/Prune message for (S-EID,G) state, it will do a
mapping table lookup on S-EID. In this case, S-EID is not in the mapping table lookup on S-EID. In this case, S-EID is not in the
mapping database because the source multicast site is using a mapping database because the source multicast site is using a
routable address and not an EID prefix address. So the ETR knows to routable address and not an EID prefix address. So the ETR knows to
simply propagate the PIM Join/Prune message to a external-facing simply propagate the PIM Join/Prune message to a external-facing
skipping to change at page 23, line 19 skipping to change at page 23, line 19
LISP source multicast site. Since the source multicast site, in this LISP source multicast site. Since the source multicast site, in this
case has not been upgraded to LISP, all multicast source host case has not been upgraded to LISP, all multicast source host
addresses are routable. So this case is simplified to where a uLISP addresses are routable. So this case is simplified to where a uLISP
receiver multicast site looks to the source multicast site as a non- receiver multicast site looks to the source multicast site as a non-
LISP receiver multicast site. LISP receiver multicast site.
9.1.3. Non-LISP Source Site to Any Receiver Site 9.1.3. Non-LISP Source Site to Any Receiver Site
When a non-LISP source multicast site has receivers in either a non- When a non-LISP source multicast site has receivers in either a non-
LISP/uLISP site or a LISP site, one needs to decide how the LISP LISP/uLISP site or a LISP site, one needs to decide how the LISP
receiver multicast site will attach to the distribution tree. We receiver multicast site will attach to the distribution tree. It is
know from Section 9.1.2 that non-LISP and uLISP receiver multicast known from Section 9.1.2 that non-LISP and uLISP receiver multicast
sites can join the distribution tree, but a LISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast
site ETR will need to know if the source address of the multicast site ETR will need to know if the source address of the multicast
source host is routable or not. We showed in Section 9.1.1 that an source host is routable or not. It has been shown in Section 9.1.1
ETR, before it sends a PIM Join/Prune message on an external-facing that an ETR, before it sends a PIM Join/Prune message on an external-
interface, does a EID-to-RLOC mapping lookup to determine if it facing interface, does a EID-to-RLOC mapping lookup to determine if
should convert the (S,G) state from a PIM Join/Prune message received it should convert the (S,G) state from a PIM Join/Prune message
on a site-facing interface to a (S-RLOC,G). If the lookup fails, the received on a site-facing interface to a (S-RLOC,G). If the lookup
ETR can conclude the source multicast site is a non-LISP site so it fails, the ETR can conclude the source multicast site is a non-LISP
simply forwards the Join/Prune message (it also doesn't need to send site so it simply forwards the Join/Prune message (it also doesn't
a unicast encapsulated Join/Prune message because there is no ITR in need to send a unicast encapsulated Join/Prune message because there
a non-LISP site and there is namespace continuity between the ETR and is no ITR in a non-LISP site and there is namespace continuity
source). between the ETR and source).
For a non-LISP source multicast site, (S-EID,G) state could be For a non-LISP source multicast site, (S-EID,G) state could be
limited to the edges of the network with the use of multicast proxy- limited to the edges of the network with the use of multicast proxy-
ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast
packets from non-LISP source multicast and uLISP sites and packets from non-LISP source multicast and uLISP sites and
encapsulate them to ETRs in receiver multicast sites or to mPETRs encapsulate them to ETRs in receiver multicast sites or to mPETRs
that can decapsulate for non-LISP receiver multicast or uLISP sites. that can decapsulate for non-LISP receiver multicast or uLISP sites.
The mPITRs are responsible for sending (S-EID,G) joins to the non- The mPITRs are responsible for sending (S-EID,G) joins to the non-
LISP source multicast site. To connect the distribution trees LISP source multicast site. To connect the distribution trees
together, multicast ETRs will need to be configured with the mPITR's together, multicast ETRs will need to be configured with the mPITR's
skipping to change at page 25, line 33 skipping to change at page 25, line 33
IPv6 format. When a mapping entry has a mix of RLOC formatted IPv6 format. When a mapping entry has a mix of RLOC formatted
addresses, it is an implicit advertisement by the site that it is a addresses, it is an implicit advertisement by the site that it is a
dual-stack site. That is, the site can receive IPv4 or IPv6 unicast dual-stack site. That is, the site can receive IPv4 or IPv6 unicast
packets. packets.
To distinguish if the site can receive dual-stack unicast packets as To distinguish if the site can receive dual-stack unicast packets as
well as dual-stack multicast packets, the Mpriority value setting well as dual-stack multicast packets, the Mpriority value setting
will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
details. details.
If you consider the combinations of LISP, non-LISP, and uLISP sites If one considers the combinations of LISP, non-LISP, and uLISP sites
sharing the same distribution tree and considering the capabilities sharing the same distribution tree and considering the capabilities
of supporting IPv4, IPv6, or dual-stack, the number of total of supporting IPv4, IPv6, or dual-stack, the number of total
combinations grows beyond comprehension. combinations grows beyond comprehension.
Using some combinatorial math, we have the following profiles of a Using some combinatorial math, the following profiles of a site and
site and the combinations that can occur: the combinations that can occur:
1. LISP-Multicast IPv4 Site 1. LISP-Multicast IPv4 Site
2. LISP-Multicast IPv6 Site 2. LISP-Multicast IPv6 Site
3. LISP-Multicast Dual-Stack Site 3. LISP-Multicast Dual-Stack Site
4. uLISP IPv4 Site 4. uLISP IPv4 Site
5. uLISP IPv6 Site 5. uLISP IPv6 Site
skipping to change at page 26, line 17 skipping to change at page 26, line 17
8. non-LISP IPv6 Site 8. non-LISP IPv6 Site
9. non-LISP Dual-Stack Site 9. non-LISP Dual-Stack Site
Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
illustrate some combinatorial math below. illustrate some combinatorial math below.
When 1 site talks to another site, the combinatorial is (9 2), when 1 When 1 site talks to another site, the combinatorial is (9 2), when 1
site talks to another 2 sites, the combinatorial is (9 3). If sum site talks to another 2 sites, the combinatorial is (9 3). If sum
this up to (9 9), we have: this up to (9 9), then:
(9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =
36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1
Which results in the total number of cases to be considered at 502. Which results in the total number of cases to be considered at 502.
This combinatorial gets even worse when you consider a site using one This combinatorial gets even worse when one considers a site using
address family inside of the site and the xTRs use the other address one address family inside of the site and the xTRs use the other
family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs
RLOCs). with IPv4 RLOCs).
To rationalize this combinatorial nightmare, there are some To rationalize this combinatorial nightmare, there are some
guidelines which need to be put in place: guidelines which need to be put in place:
o Each distribution tree shared between sites will either be an IPv4 o Each distribution tree shared between sites will either be an IPv4
distribution tree or an IPv6 distribution tree. Therefore, we can distribution tree or an IPv6 distribution tree. Therefore, head-
avoid head-end replication by building and sending packets on each end replication can be avoided by building and sending packets on
address family based distribution tree. Even though there might each address family based distribution tree. Even though there
be an urge to do multicast packet translation from one address might be an urge to do multicast packet translation from one
family format to the other, it is a non-viable over-complicated address family format to the other, it is a non-viable over-
urge. Multicast ITRs will only encapsulate packets where the complicated urge. Multicast ITRs will only encapsulate packets
inner and outer headers are from the same address family. where the inner and outer headers are from the same address
family.
o All LISP sites on a multicast distribution tree must share a o All LISP sites on a multicast distribution tree must share a
common address family which is determined by the source site's common address family which is determined by the source site's
locator-set in its LISP database mapping entry. All receiver locator-set in its LISP database mapping entry. All receiver
multicast sites will use the best RLOC priority controlled by the multicast sites will use the best RLOC priority controlled by the
source multicast site. This is true when the source site is source multicast site. This is true when the source site is
either LISP-Multicast or uLISP capable. This means that priority- either LISP-Multicast or uLISP capable. This means that priority-
based policy modification is prohibited. When a receiver based policy modification is prohibited. When a receiver
multicast site ETR receives a (S-EID,G) join, it must select a multicast site ETR receives a (S-EID,G) join, it must select a
S-RLOC for the same address family as S-EID. S-RLOC for the same address family as S-EID.
skipping to change at page 27, line 18 skipping to change at page 27, line 19
but the multicast priorities MUST be the set for the same address but the multicast priorities MUST be the set for the same address
family locators. family locators.
o When the source site is not LISP capable, it is up to how o When the source site is not LISP capable, it is up to how
receivers find the source and group information for a multicast receivers find the source and group information for a multicast
flow. That mechanism decides the address family for the flow. flow. That mechanism decides the address family for the flow.
9.3. Making a Multicast Interworking Decision 9.3. Making a Multicast Interworking Decision
This Multicast Interworking section has shown all combinations of This Multicast Interworking section has shown all combinations of
multicast connectivity that could occur. As you might have already multicast connectivity that could occur. As already concluded, this
concluded, this can be quite complicated and if the design is too can be quite complicated and if the design is too ambitious, the
ambitious, the dynamics of the protocol could cause a lot of dynamics of the protocol could cause a lot of instability.
instability.
The trade-off decisions are hard to make and we want the same single The trade-off decisions are hard to make and so the same single
solution to work for both IPv4 and IPv6 multicast. It is imperative solution is desirable to work for both IPv4 and IPv6 multicast. It
to have an incrementally deployable solution for all of IPv4 unicast is imperative to have an incrementally deployable solution for all of
and multicast and IPv6 unicast and multicast while minimizing (or IPv4 unicast and multicast and IPv6 unicast and multicast while
eliminating) both unicast and multicast EID namespace state. minimizing (or eliminating) both unicast and multicast EID namespace
state.
Therefore the design decision to go with uPITRs [INTWORK] for unicast Therefore the design decision to go with uPITRs [INTWORK] for unicast
routing and mPETRs for multicast routing seems to be the sweet spot routing and mPETRs for multicast routing seems to be the sweet spot
in the solution space so we can optimize state requirements and avoid in the solution space so state requirements can be optimized and
head-end data replication at ITRs. avoid head-end data replication at ITRs.
10. Considerations when RP Addresses are Embedded in Group Addresses 10. Considerations when RP Addresses are Embedded in Group Addresses
When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
technique exists to embed the unicast address of an RP in a IPv6 technique exists to embed the unicast address of an RP in a IPv6
group address [RFC3956]. When routers in end sites process a PIM group address [RFC3956]. When routers in end sites process a PIM
Join/Prune message which contain an embedded-RP group address, they Join/Prune message which contain an embedded-RP group address, they
extract the RP address from the group address and treat it from the extract the RP address from the group address and treat it from the
EID namespace. However, core routers do not have state for the EID EID namespace. However, core routers do not have state for the EID
namespace, need to extract an RP address from the RLOC namespace. namespace, need to extract an RP address from the RLOC namespace.
skipping to change at page 29, line 7 skipping to change at page 29, line 7
to the ITR is created. to the ITR is created.
This technique is no different than the techniques described in this This technique is no different than the techniques described in this
specification for translating (S,G) state and propagating Join/Prune specification for translating (S,G) state and propagating Join/Prune
messages into the core. The only difference is that the (*,G) state messages into the core. The only difference is that the (*,G) state
in Join/Prune messages are mapped because they contain unicast in Join/Prune messages are mapped because they contain unicast
addresses encoded in an Embedded-RP group address. addresses encoded in an Embedded-RP group address.
11. Taking Advantage of Upgrades in the Core 11. Taking Advantage of Upgrades in the Core
If the core routers are upgraded to support [RFC5496], then we can If the core routers are upgraded to support [RFC5496], then the EID
pass EID specific data through the core without, possibly, having to specific data can be passed through the core without, possibly,
store the state in the core. having to store the state in the core.
By doing this we can eliminate the ETR from unicast encapsulating PIM By doing this one can eliminate the ETR from unicast encapsulating
Join/Prune messages to the source site's ITR. PIM Join/Prune messages to the source site's ITR.
However, this solution is restricted to a small set of workable cases However, this solution is restricted to a small set of workable cases
which would not be good for general use of LISP-Multicast. In which would not be good for general use of LISP-Multicast. In
addition due to slow convergence properties, it is not being addition due to slow convergence properties, it is not being
recommended for LISP-Multicast. recommended for LISP-Multicast.
12. Mtrace Considerations 12. Mtrace Considerations
Mtrace functionality must be consistent with unicast traceroute Mtrace functionality MUST be consistent with unicast traceroute
functionality where all hops from multicast receiver to multicast functionality where all hops from multicast receiver to multicast
source are visible. source are visible.
The design for mtrace for use in LISP-Multicast environments is to be The design for mtrace for use in LISP-Multicast environments is to be
determined but should build upon the mtrace version 2 specified in determined but should build upon the mtrace version 2 specified in
[MTRACE]. [MTRACE].
13. Security Considerations 13. Security Considerations
Refer to the [LISP] specification. This document introduces no additional security concerns beyond those
specified in the base LISP specification [LISP].
14. Acknowledgments 14. Acknowledgments
The authors would like to gratefully acknowledge the people who have The authors would like to gratefully acknowledge the people who have
contributed discussion, ideas, and commentary to the making of this contributed discussion, ideas, and commentary to the making of this
proposal and specification. People who provided expert review were proposal and specification. People who provided expert review were
Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from
discussions at Summer 2008 Dublin IETF were Toerless Eckert and discussions at Summer 2008 Dublin IETF were Toerless Eckert and
Ijsbrand Wijnands. Ijsbrand Wijnands.
We would also like to thank the MBONED working group for constructive The authors would also like to thank the MBONED working group for
and civil verbal feedback when this draft was presented at the Fall constructive and civil verbal feedback when this draft was presented
2008 IETF in Minneapolis. In particular, good commentary came from at the Fall 2008 IETF in Minneapolis. In particular, good commentary
Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri
Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko. Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango,
and Jari Arkko.
An expert review of this specification was done by Yiqun Cai and An expert review of this specification was done by Yiqun Cai and
Liming Wei. We thank them for their detailed comments. Liming Wei. The authors thank them for their detailed comments.
This work originated in the Routing Research Group (RRG) of the IRTF. This work originated in the Routing Research Group (RRG) of the IRTF.
The individual submission [MLISP] was converted into this IETF LISP The individual submission [MLISP] was converted into this IETF LISP
working group draft. working group draft.
15. IANA Considerations 15. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
16. References 16. References
skipping to change at page 36, line 7 skipping to change at page 36, line 7
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-farinacci-lisp-multicast-01.txt (work in progress). draft-farinacci-lisp-multicast-01.txt (work in progress).
[MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
Version 2: Traceroute Facility for IP Multicast", Version 2: Traceroute Facility for IP Multicast",
draft-ietf-mboned-mtrace-v2-08.txt (work in progress). draft-ietf-mboned-mtrace-v2-08.txt (work in progress).
Appendix A. Document Change Log Appendix A. Document Change Log
A.1. Changes to draft-ietf-lisp-multicast-08.txt A.1. Changes to draft-ietf-lisp-multicast-09.txt
o Posted October 2011. Changes to reflect IESG review comments from
Ralph Droms and Kathleen Moriarty.
A.2. Changes to draft-ietf-lisp-multicast-08.txt
o Posted September 2011. Minor editorial changes from Jari's o Posted September 2011. Minor editorial changes from Jari's
commentary. commentary.
A.2. Changes to draft-ietf-lisp-multicast-07.txt A.3. Changes to draft-ietf-lisp-multicast-07.txt
o Posted July 2011. Fixing IDnits errors. o Posted July 2011. Fixing IDnits errors.
A.3. Changes to draft-ietf-lisp-multicast-06.txt A.4. Changes to draft-ietf-lisp-multicast-06.txt
o Posted June 2011 to complete working group last call. o Posted June 2011 to complete working group last call.
o Added paragraph to section 8.1.2 based on Jesus comment about o Added paragraph to section 8.1.2 based on Jesus comment about
making it more clear what happens when two (S-EID,G) trees use the making it more clear what happens when two (S-EID,G) trees use the
same (RLOC,G) tree. same (RLOC,G) tree.
o Make more references to [INTWORK] when mentioning uPITRs and o Make more references to [INTWORK] when mentioning uPITRs and
uPETRs. uPETRs.
o Made many changes based on editorial and wordsmithing comments o Made many changes based on editorial and wordsmithing comments
from Alia. from Alia.
A.4. Changes to draft-ietf-lisp-multicast-05.txt A.5. Changes to draft-ietf-lisp-multicast-05.txt
o Posted April 2011 to reset expiration timer. o Posted April 2011 to reset expiration timer.
o Updated references. o Updated references.
A.5. Changes to draft-ietf-lisp-multicast-04.txt A.6. Changes to draft-ietf-lisp-multicast-04.txt
o Posted October 2010 to reset expiration timer. o Posted October 2010 to reset expiration timer.
o Updated references. o Updated references.
A.6. Changes to draft-ietf-lisp-multicast-03.txt A.7. Changes to draft-ietf-lisp-multicast-03.txt
o Posted April 2010. o Posted April 2010.
o Added section 8.1.2 to address Joel Halpern's comment about o Added section 8.1.2 to address Joel Halpern's comment about
receiver sites joining the same source site via 2 different RLOCs, receiver sites joining the same source site via 2 different RLOCs,
each being a separate ITR. each being a separate ITR.
o Change all occurences of "mPTR" to "mPETR" to become more o Change all occurences of "mPTR" to "mPETR" to become more
consistent with uPITRs and uPETRs described in [INTWORK]. That consistent with uPITRs and uPETRs described in [INTWORK]. That
is, an mPETR is a LISP multicast router that decapsulates is, an mPETR is a LISP multicast router that decapsulates
skipping to change at page 37, line 15 skipping to change at page 37, line 20
source sites. source sites.
o Add clarifications in section 9 about how homogeneous multicast o Add clarifications in section 9 about how homogeneous multicast
encapsulation should occur. As well as describing in this encapsulation should occur. As well as describing in this
section, how to deal with mixed-locator sets to avoid section, how to deal with mixed-locator sets to avoid
heterogeneous encapsulation. heterogeneous encapsulation.
o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
of LISP global multicast network. of LISP global multicast network.
A.7. Changes to draft-ietf-lisp-multicast-02.txt A.8. Changes to draft-ietf-lisp-multicast-02.txt
o Posted September 2009. o Posted September 2009.
o Added Document Change Log appendix. o Added Document Change Log appendix.
o Specify that the LISP Encapsulated Control Message be used for o Specify that the LISP Encapsulated Control Message be used for
unicasting PIM Join/Prune messages from ETRs to ITRs. unicasting PIM Join/Prune messages from ETRs to ITRs.
A.8. Changes to draft-ietf-lisp-multicast-01.txt A.9. Changes to draft-ietf-lisp-multicast-01.txt
o Posted November 2008. o Posted November 2008.
o Specified that PIM Join/Prune unicast messages that get sent from o Specified that PIM Join/Prune unicast messages that get sent from
ETRs to ITRs of a source multicast site get LISP encapsulated in ETRs to ITRs of a source multicast site get LISP encapsulated in
destination UDP port 4342. destination UDP port 4342.
o Add multiple RLOCs per ITR per Yiqun's comments. o Add multiple RLOCs per ITR per Yiqun's comments.
o Indicate how static RPs can be used when LISP is run using Bidir- o Indicate how static RPs can be used when LISP is run using Bidir-
PIM in the core. PIM in the core.
o Editorial changes per Liming comments. o Editorial changes per Liming comments.
o Add Mttrace Considersations section. o Add Mttrace Considersations section.
A.9. Changes to draft-ietf-lisp-multicast-00.txt A.10. Changes to draft-ietf-lisp-multicast-00.txt
o Posted April 2008. o Posted April 2008.
o Renamed from draft-farinacci-lisp-multicast-01.txt. o Renamed from draft-farinacci-lisp-multicast-01.txt.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
cisco Systems cisco Systems
Tasman Drive Tasman Drive
 End of changes. 52 change blocks. 
133 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/