--- 1/draft-ietf-lisp-multicast-02.txt 2010-04-17 03:11:13.000000000 +0200 +++ 2/draft-ietf-lisp-multicast-03.txt 2010-04-17 03:11:13.000000000 +0200 @@ -1,20 +1,26 @@ Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel -Expires: April 2, 2010 S. Venaas +Expires: October 18, 2010 S. Venaas cisco Systems - September 29, 2009 + April 16, 2010 LISP for Multicast Environments - draft-ietf-lisp-multicast-02.txt + draft-ietf-lisp-multicast-03 + +Abstract + + This draft describes how inter-domain multicast routing will function + in an environment where Locator/ID Separation is deployed using the + LISP architecture. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,76 +29,76 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 2, 2010. + This Internet-Draft will expire on October 18, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - This draft describes how inter-domain multicast routing will function - in an environment where Locator/ID Separation is deployed using the - LISP architecture. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 + 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 17 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 - 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 22 + 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 23 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 - 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 23 - 9.3. Making a Multicast Interworking Decision . . . . . . . . . 25 + 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 24 + 9.3. Making a Multicast Interworking Decision . . . . . . . . . 26 10. Considerations when RP Addresses are Embedded in Group - Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 - 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 28 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 - 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 - Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 33 - A.1. Changes to draft-ietf-lisp-multicsat-02.txt . . . . . . . 33 - A.2. Changes to draft-ietf-lisp-multicsat-01.txt . . . . . . . 33 - A.3. Changes to draft-ietf-lisp-multicsat-00.txt . . . . . . . 33 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 + Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28 + 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 29 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 32 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 32 + Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 34 + A.1. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 34 + A.2. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 34 + A.3. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 34 + A.4. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction The Locator/ID Separation Architecture [LISP] provides a mechanism to @@ -269,26 +275,29 @@ 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) 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 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 not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. - mPTR: this is a multicast PTR that is responsible for advertising a - very coarse EID prefix which non-LISP and uLISP sites can target - their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP - source multicast sites can send multicast packets using source - addresses from the EID namespace. mPTRs act as Proxy ETRs for - supporting multicast routing in a LISP infrastructure. + mPETR: this is a multicast proxy-ETR that is responsible for + advertising a very coarse EID prefix which non-LISP and uLISP + sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs + are used so LISP source multicast sites can send multicast packets + using source addresses from the EID namespace. mPETRs act as Proxy + ETRs for supporting multicast routing in a LISP infrastructure. + It is likely an uPITR and a mPETR will be co-loacted since the + single device advertises a coarse EID-prefix in the underlying + unicast routing system. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces @@ -318,25 +327,24 @@ header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they - join (S-EID,G). If the S-EID is a local multicast source host. - If the multicast source is external to this receiver site, the - PIM Join/Prune message flows toward the ETRs, finding the - shortest exit (that is the closest exit for the Join/Prune - message but it is the closest entrance for the multicast packet + join (S-EID,G). If the multicast source is external to this + receiver site, the PIM Join/Prune message flows toward the ETRs, + finding the shortest exit (that is the closest exit for the Join/ + Prune message and the closest entrance for the multicast packet to the receiver). 2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping. The ETR will use the same priority and weighting mechanism as for unicast. So the source site can decide which way multicast packets egress. @@ -370,39 +378,36 @@ header by copying the group address to the outer destination address field and insert its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface a (S-RLOC,G) joined was received on. The core has (S-RLOC,G) so where fanout occurs to multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group - address. It will also decapsulate packets because it has - receivers for the group. Otherwise, it would have not received - the packets because it would not have joined. The ETR - decapsulates and does a (S-EID,G) lookup in its multicast FIB to - forward packets out one or more interfaces to forward the packet - to internal receivers. + address. It will decapsulate packets because it has receivers + for the group. Otherwise, it would have not received the packets + because it would not have joined. The ETR decapsulates and does + a (S-EID,G) lookup in its multicast FIB to forward packets out + one or more interfaces to forward the packet to internal + receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. - Alternatively, [LISP] does present a mechanism where (S-EID,G) state - can reside in the core through the use of RPF-vectors [RPFV] in PIM - Join/Prune messages. However, this will require EID state in core as - well as the use of RPF-vector formatted Join/Prune messages which are - not the default implementation choice. So we choose a design that - can allow the separation of namespaces as unicast LISP provides. It - will be at the expense of creating new (S-RLOC,G) state when ITRs go - unreachable. See Section 5 for details. + Alternatively, [LISP] also has a mechanism where (S-EID,G) state can + reside in the core through the use of RPF-vectors [RPFV] in PIM Join/ + Prune messages. However, few PIM implementations support RPF vectors + and LISP should avoid S-EID state in the core. See Section 5 for + details. However, we have some observations on the algorithm above. We can scale the control plane but at the expense of sending data to sites which may have not joined the distribution tree where the 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 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 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 @@ -645,20 +650,32 @@ Prune messages are received for each RLOC, there is a oif-list merging action that must take place. Therefore, when a packet is 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 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 addition to replicating for all types of oif-lists, each oif entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined. +8.1.2. Multiple ITRs for a LISP Source Site + + Note when ETRs from different multicast receiver sites receive + (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 + 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) + 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 + the source address for encapsulated multicast traffic. The RLOC + addresses are the ones joined by remote multicast ETRs. + 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 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 state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this @@ -813,36 +830,38 @@ that its site's EIDs are not routable, it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a 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 for unicast [INTWORK] forwarding by using Proxy Tunnel Routers - (PTRs). 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 Join/Prune messages for (S-EID,G) which make their way in the core to - PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). - Since the PTRs advertise very coarse EID prefixes, they draw the PIM - Join/Prune control traffic making them the target of the distribution - tree. To get multicast packets from the LISP source multicast sites, - the tree needs to be built on the path from the mPTR to the LISP - source multicast site. To make this happen the mPTR acts as a "Proxy - ETR" (where in unicast it acts as a "Proxy ITR"). + multicast PxTRs. Let's call this use of a PxTR as a "Multicast + Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID + prefixes, they draw the PIM Join/Prune control traffic making them + the target of the distribution tree. To get multicast packets from + 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 + happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a + "Proxy ITR", or an uPITR). - The existence of mPTRs in the core allows LISP source multicast site - ITRs to encapsulate multicast packets so the state built between the - ITRs and the mPTRs is (S-RLOC,G) state. Then the mPTRs can - decapsulate packets and forward natively to the non-LISP and uLISP - receiver multicast sites. + The existence of mPETRs in the core allows source multicast site ITRs + 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 + encapsulated multicast packets are decapsulated by mPETRs and then + 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. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Clearly non-LISP multicast sites can send multicast packets to non- LISP receiver multicast sites. That is what they do today. However, discussion is required to show how non-LISP multicast sites send multicast packets to uLISP receiver multicast sites. Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non- @@ -864,20 +883,35 @@ ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source). + 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- + ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast + packets from non-LISP source multicast and uLISP sites and + encapsulate them to ETRs in receiver multicast sites or to mPETRs + that can decapsulate for non-LISP receiver multicast or uLISP sites. + The mPITRs are responsible for sending (S-EID,G) joins to the non- + LISP source multicast site. To connect the distribution trees + 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 + distribution tree to the mPITR as well as for sending unicast oins 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 + progress. + 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. @@ -904,39 +938,39 @@ forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site then it could receive packets like a non-LISP receiver multicast site making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases. - o Or alternatively, mPTR deployment would be required forcing coarse - EID prefix advertisement in the core. + o Or alternatively, mPETR deployment would be required forcing + coarse EID prefix advertisement in the core. o But what is most disturbing is that when all sites that participate are LISP-Multicast sites but then a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a viable alternative. So the solution space options are: 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to - reach LISP-Multicast sites and to reach mPTRs that can + reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites. 9.2. LISP Sites with Mixed Address Families A LISP database mapping entry that describes the locator-set, Mpriority and Mweight per locator address (RLOC), for an EID prefix associated with a site could have RLOC addresses in either IPv4 or 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 @@ -988,56 +1021,64 @@ 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 address family inside of the site and the xTRs use the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: - o Each distribution tree shared among 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 avoid head-end replication by building and sending packets on each address family based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated - urge. + urge. Multicast ITRs will only encapsulate packets where the + inner and outer headers are from the same address family. o All LISP sites on a multicast distribution tree must share a common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- - based policy modification is prohibited. + based policy modification is prohibited. When a receiver + multicast site ETR receives a (S-EID,G) join, it must select a + S-RLOC for the same address family as S-EID. + + o A mixed multicast locator-set with the best multicast priority + values MUST not be configured on multicast ITRs. A mixed locator- + set can exist (for unicast use), but the multicast priorities MUST + be the set for the same address family locators. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. 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 to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. - Therefore the design decision to go with PTRs for unicast routing and - mPTRs for multicast routing seems to be the sweet spot in the + Therefore the design decision to go with uPITRs for unicast routing + and mPETRs for multicast routing seems to be the sweet spot in the solution space so we can optimize state requirements and avoid head- end data replication at ITRs. 10. Considerations when RP Addresses are Embedded in Group Addresses 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 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the @@ -1141,30 +1182,30 @@ [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 15.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative - Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in - progress), May 2009. + Topology (LISP-ALT)", draft-ietf-lisp-alt-04.txt (work in + progress), April 2010. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP - with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt - (work in progress), May 2009. + with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt + (work in progress), March 2010. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-05.txt (work in progress), September 2009. + draft-ietf-lisp-07.txt (work in progress), April 2010. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress), November 2008. [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a Network Address (and port) Translator (NAT)", draft-ietf-behave-multicast-07.txt (work in progress), June 2007. @@ -1173,47 +1214,69 @@ Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-03.txt (work in progress), March 2009. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), February 2008. Appendix A. Document Change Log -A.1. Changes to draft-ietf-lisp-multicsat-02.txt +A.1. Changes to draft-ietf-lisp-multicast-03.txt + + o Posted April 2010. + + o Added section 8.1.2 to address Joel Halpern's comment about + receiver sites joining the same source site via 2 different RLOCs, + each being a separate ITR. + + o Change all occurences of "mPTR" to "mPETR" to become more + consistent with uPITRs and uPETRs described in [INTWORK]. That + is, an mPETR is a LISP multicast router that decapsulates + multicast packets that are encapsulated to it by ITRs in multicast + source sites. + + o Add clarifications in section 9 about how homogeneous multicast + encapsulation should occur. As well as describing in this + section, how to deal with mixed-locator sets to avoid + heterogeneous encapsulation. + + o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges + of LISP global multicast network. + +A.2. Changes to draft-ietf-lisp-multicast-02.txt o Posted September 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. -A.2. Changes to draft-ietf-lisp-multicsat-01.txt +A.3. Changes to draft-ietf-lisp-multicast-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. o Add Mttrace Considersations section. -A.3. Changes to draft-ietf-lisp-multicsat-00.txt +A.4. Changes to draft-ietf-lisp-multicast-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Authors' Addresses Dino Farinacci cisco Systems Tasman Drive