draft-ietf-lisp-multicast-05.txt   draft-ietf-lisp-multicast-06.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: October 7, 2011 S. Venaas Expires: December 22, 2011 S. Venaas
cisco Systems cisco Systems
April 5, 2011 June 20, 2011
LISP for Multicast Environments LISP for Multicast Environments
draft-ietf-lisp-multicast-05 draft-ietf-lisp-multicast-06
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 to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 7, 2011. This Internet-Draft will expire on December 22, 2011.
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 25 skipping to change at page 2, line 25
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Source Addresses versus Group Addresses . . . . . . . . . . . 13 5. Source Addresses versus Group Addresses . . . . . . . . . . . 13
6. Locator Reachability Implications on LISP-Multicast . . . . . 14 6. Locator Reachability Implications on LISP-Multicast . . . . . 14
7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15
8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17
8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17
8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 18 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20
9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20
9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21
9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22
9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25
9.3. Making a Multicast Interworking Decision . . . . . . . . . 27 9.3. Making a Multicast Interworking Decision . . . . . . . . . 27
10. Considerations when RP Addresses are Embedded in Group 10. Considerations when RP Addresses are Embedded in Group
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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35
A.1. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 A.1. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35
A.2. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 A.2. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35
A.3. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 A.3. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35
A.4. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 35 A.4. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35
A.5. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 A.5. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36
A.6. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 A.6. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36
A.7. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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 9, line 23 skipping to change at page 9, line 23
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.
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 and a mPETR will be co-loacted since the It is likely an uPITR [INTWORK] and a mPETR will be co-located
single device advertises a coarse EID-prefix in the underlying since the single device advertises a coarse EID-prefix in the
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
skipping to change at page 10, line 19 skipping to change at page 10, line 19
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, we don't see a requirement for different
locator-sets, priority, and weight policies for multicast than we locator-sets, priority, and weight policies for multicast than we
have for unicast. have for unicast. However, when traffic engineering policies are
different for unicast versus multicast flows, it will be desirable to
use 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
another LISP multicast header. The destination group address from another LISP multicast header. The destination group address from
the inner header is copied to the destination address of the outer the 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 18, line 26 skipping to change at page 18, line 26
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)
state in the core. This will not result in duplicate packets because state in the core. This will not result in duplicate packets because
each ITR in the multicast source site will choose their own RLOC for each ITR in the multicast source site will choose their own RLOC for
the source address for encapsulated multicast traffic. The RLOC the source address for encapsulated multicast traffic. The RLOC
addresses are the ones joined by remote multicast ETRs. addresses are the ones joined by remote multicast ETRs.
When different (S-EID,G) traffic is combined into a single (RLOC,G)
core distribution tree, this may cause traffic to go to a receiver
multicast site when it does not need to. This happens when one
receiver multicast site joins (S1-EID,Gi) through a core distribution
tree of (RLOC1,Gi) and another multicast receiver site joins (S2-
EID,Gi) through the same core distribution tree of (RLOC1,Gi). When
ETRs decapsulate such traffic, they should know from their local
(S-EID,G) state if the packet should be forwarded. If there is no
(S-EID,G) state that matches the inner packet header, the packet is
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
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 we want the ITRs to
process a received PIM Join/Prune message from an external-facing 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
skipping to change at page 22, line 19 skipping to change at page 22, line 19
Now that the multicast distribution tree is built and maintained from Now that the multicast distribution tree is built and maintained from
any non-LISP or uLISP receiver multicast site, the way packet any non-LISP or uLISP receiver multicast site, the way packet
forwarding model is performed can be explained. forwarding model is performed can be explained.
Since the ITR in the source multicast site has never received a Since the ITR in the source multicast site has never received a
unicast encapsulated PIM Join/Prune message from any ETR in a unicast encapsulated PIM Join/Prune message from any ETR in a
receiver multicast site, it knows there are no LISP-Multicast receiver multicast site, it knows there are no LISP-Multicast
receiver sites. Therefore, there is no need for the ITR to receiver sites. Therefore, there is no need for the ITR to
encapsulate data. Since it will know a priori (via configuration) encapsulate data. Since it will know a priori (via configuration)
that its site's EIDs are not routable, it assumes that the multicast that its site's EIDs are not routable (and not registered to the
packets from the source host are sent by a routable address. That mapping database system), it assumes that the multicast packets from
is, it is the responsibility of the multicast source host's system the source host are sent by a routable address. That is, it is the
administrator to ensure that the source host sends multicast traffic responsibility of the multicast source host's system administrator to
using a routable source address. When this happens, the ITR acts ensure that the source host sends multicast traffic using a routable
simply as a router and forwards the multicast packet like an ordinary source address. When this happens, the ITR acts simply as a router
multicast router. and forwards the multicast packet like an ordinary multicast router.
There is an alternative to using a LISP-NAT scheme just like there is There is an alternative to using a LISP-NAT scheme just like there is
for unicast [INTWORK] forwarding by using Proxy Tunnel Routers for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
(PxTRs). This can work the same way for multicast routing as well, (PxTRs). This can work the same way for multicast routing as well,
but the difference is that non-LISP and uLISP sites will send PIM but the difference is that non-LISP and uLISP sites will send PIM
Join/Prune messages for (S-EID,G) which make their way in the core to Join/Prune messages for (S-EID,G) which make their way in the core to
multicast PxTRs. Let's call this use of a PxTR as a "Multicast multicast PxTRs. Let's call this use of a PxTR as a "Multicast
Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID
prefixes, they draw the PIM Join/Prune control traffic making them prefixes, they draw the PIM Join/Prune control traffic making them
the target of the distribution tree. To get multicast packets from the target of the distribution tree. To get multicast packets from
the LISP source multicast sites, the tree needs to be built on the the LISP source multicast sites, the tree needs to be built on the
path from the mPETR to the LISP source multicast site. To make this path from the mPETR to the LISP source multicast site. To make this
happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a
"Proxy ITR", or an uPITR). "Proxy ITR", or an uPITR [INTWORK]).
The existence of mPETRs in the core allows source multicast site ITRs The existence of mPETRs in the core allows source multicast site ITRs
to encapsulate multicast packets according to (S-RLOC,G) state. The to encapsulate multicast packets according to (S-RLOC,G) state. The
(S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The
encapsulated multicast packets are decapsulated by mPETRs and then encapsulated multicast packets are decapsulated by mPETRs and then
forwarded according to (S-EID,G) state. The (S-EID,G) state is built forwarded according to (S-EID,G) state. The (S-EID,G) state is built
from the non-LISP and uLISP receiver multicast sites to the mPETRs. from the non-LISP and uLISP receiver multicast sites to the mPETRs.
9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites
skipping to change at page 23, line 44 skipping to change at page 23, line 44
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
RLOC addresses so they can send both (S-RLOC,G) joins to build a RLOC addresses so they can send both (S-RLOC,G) joins to build a
distribution tree to the mPITR as well as for sending unicast oins to distribution tree to the mPITR as well as for sending unicast joins
mPITRs so they can propogate (S-EID,G) joins into source multicast to mPITRs so they can propogate (S-EID,G) joins into source multicast
sites. The use of mPITRs is undergoing more study and is work in sites. The use of mPITRs is undergoing more study and is work in
progress. progress.
9.1.4. Unicast LISP Source Site to Any Receiver Sites 9.1.4. Unicast LISP Source Site to Any Receiver Sites
In the last section, it was explained how an ETR in a multicast In the last section, it was explained how an ETR in a multicast
receiver site can determine if a source multicast site is LISP- receiver site can determine if a source multicast site is LISP-
enabled by looking into the mapping database. When the source enabled by looking into the mapping database. When the source
multicast site is a uLISP site, it is LISP enabled but the ITR, by multicast site is a uLISP site, it is LISP enabled but the ITR, by
definition is not capable of doing multicast encapsulation. So for definition is not capable of doing multicast encapsulation. So for
skipping to change at page 27, line 6 skipping to change at page 27, line 6
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.
o A mixed multicast locator-set with the best multicast priority o A mixed multicast locator-set with the best multicast priority
values MUST not be configured on multicast ITRs. A mixed locator- values MUST NOT be configured on multicast ITRs. A mixed locator-
set can exist (for unicast use), but the multicast priorities MUST set can exist (for unicast use), but the multicast priorities MUST
be the set for the same address family locators. be the set for the same address 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
skipping to change at page 27, line 28 skipping to change at page 27, line 28
concluded, this can be quite complicated and if the design is too concluded, this can be quite complicated and if the design is too
ambitious, the dynamics of the protocol could cause a lot of ambitious, the 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 we want the same single
solution to work for both IPv4 and IPv6 multicast. It is imperative solution to work for both IPv4 and IPv6 multicast. It is imperative
to have an incrementally deployable solution for all of IPv4 unicast to have an incrementally deployable solution for all of IPv4 unicast
and multicast and IPv6 unicast and multicast while minimizing (or and multicast and IPv6 unicast and multicast while minimizing (or
eliminating) both unicast and multicast EID namespace state. eliminating) both unicast and multicast EID namespace state.
Therefore the design decision to go with uPITRs for unicast routing Therefore the design decision to go with uPITRs [INTWORK] for unicast
and mPETRs for multicast routing seems to be the sweet spot in the routing and mPETRs for multicast routing seems to be the sweet spot
solution space so we can optimize state requirements and avoid head- in the solution space so we can optimize state requirements and avoid
end data replication at ITRs. 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 16 skipping to change at page 29, line 16
If the core routers are upgraded to support [RPFV] and [RFC5496], If the core routers are upgraded to support [RPFV] and [RFC5496],
then we can pass EID specific data through the core without, then we can pass EID specific data through the core without,
possibly, having to store the state in the core. possibly, having to store the state in the core.
By doing this we can eliminate the ETR from unicast encapsulating PIM By doing this we can eliminate the ETR from unicast encapsulating PIM
Join/Prune messages to the source site's ITR. 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 to slow convergence properties, it is not being recommended addition due to slow convergence properties, it is not being
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].
skipping to change at page 32, line 18 skipping to change at page 32, line 18
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 We would also like to thank the MBONED working group for constructive
and civil verbal feedback when this draft was presented at the Fall and civil verbal feedback when this draft was presented at the Fall
2008 IETF in Minneapolis. In particular, good commentary came from 2008 IETF in Minneapolis. In particular, good commentary came from
Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
Ron Bonica, and Lenny Guardino. Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango.
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. We 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. References 15. References
15.1. Normative References 15.1. Normative References
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-13.txt (work in progress), June 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
skipping to change at page 33, line 49 skipping to change at page 34, line 4
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
15.2. Informative References 15.2. Informative References
[ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in
progress), March 2011. progress), March 2011.
[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt
(work in progress), March 2010. (work in progress), March 2011.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-12.txt (work in progress), April 2011.
[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),
November 2008. November 2008.
[MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a
Network Address (and port) Translator (NAT)", Network Address (and port) Translator (NAT)",
draft-ietf-behave-multicast-07.txt (work in progress), draft-ietf-behave-multicast-07.txt (work in progress),
June 2007. June 2007.
skipping to change at page 35, line 7 skipping to change at page 35, line 7
Version 2: Traceroute Facility for IP Multicast", Version 2: Traceroute Facility for IP Multicast",
draft-ietf-mboned-mtrace-v2-03.txt (work in progress), draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
March 2009. March 2009.
[RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
February 2008. February 2008.
Appendix A. Document Change Log Appendix A. Document Change Log
A.1. Changes to draft-ietf-lisp-multicast-05.txt A.1. Changes to draft-ietf-lisp-multicast-06.txt
o Posted June 2011 to complete working group last call.
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
same (RLOC,G) tree.
o Make more references to [INTWORK] when mentioning uPITRs and
uPETRs.
o Made many changes based on editorial and wordsmithing comments
from Alia.
A.2. 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.2. Changes to draft-ietf-lisp-multicast-04.txt A.3. 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.3. Changes to draft-ietf-lisp-multicast-03.txt A.4. 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 35, line 41 skipping to change at page 36, line 8
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.4. Changes to draft-ietf-lisp-multicast-02.txt A.5. 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.5. Changes to draft-ietf-lisp-multicast-01.txt A.6. 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.6. Changes to draft-ietf-lisp-multicast-00.txt A.7. 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. 25 change blocks. 
47 lines changed or deleted 74 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/