--- 1/draft-ietf-lisp-multicast-12.txt 2012-02-07 11:13:58.206670975 +0100 +++ 2/draft-ietf-lisp-multicast-13.txt 2012-02-07 11:13:58.262670753 +0100 @@ -1,20 +1,20 @@ Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel -Expires: July 5, 2012 S. Venaas +Expires: August 10, 2012 S. Venaas cisco Systems - January 2, 2012 + February 7, 2012 LISP for Multicast Environments - draft-ietf-lisp-multicast-12 + draft-ietf-lisp-multicast-13 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 in full conformance with the @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." - This Internet-Draft will expire on July 5, 2012. + This Internet-Draft will expire on August 10, 2012. Copyright Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -75,34 +75,34 @@ Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 30 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1. Normative References . . . . . . . . . . . . . . . . . . . 35 16.2. Informative References . . . . . . . . . . . . . . . . . . 36 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 37 - A.1. Changes to draft-ietf-lisp-multicast-12.txt . . . . . . . 37 - A.2. Changes to draft-ietf-lisp-multicast-11.txt . . . . . . . 37 - A.3. Changes to draft-ietf-lisp-multicast-10.txt . . . . . . . 37 - A.4. Changes to draft-ietf-lisp-multicast-09.txt . . . . . . . 37 - A.5. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 37 - A.6. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 37 - A.7. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 37 - A.8. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 38 - A.9. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 38 - A.10. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 38 - A.11. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 38 - A.12. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 39 - A.13. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 39 - + A.1. Changes to draft-ietf-lisp-multicast-13.txt . . . . . . . 37 + A.2. Changes to draft-ietf-lisp-multicast-12.txt . . . . . . . 37 + A.3. Changes to draft-ietf-lisp-multicast-11.txt . . . . . . . 37 + A.4. Changes to draft-ietf-lisp-multicast-10.txt . . . . . . . 37 + A.5. Changes to draft-ietf-lisp-multicast-09.txt . . . . . . . 37 + A.6. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 37 + A.7. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 37 + A.8. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 38 + A.9. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 38 + A.10. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 38 + A.11. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 38 + A.12. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 39 + A.13. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 39 + A.14. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 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 @@ -164,24 +164,25 @@ other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no packet format changes to the protocols and no operational procedural changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. - Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], - and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not - run in an inter-domain environment is not addressed in depth in this - version of the specification. + Therefore, we see only operational (and not protocol) changes for + PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM + [RFC5015], which typically does not run in an inter-domain + environment is not addressed in depth in this version of the + specification. Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR (Traffic Engineering based Ingress Tunnel Router) and TE-ETR (Traffic Engineering based Egress Tunnel Router) descriptions in [LISP]. Futher work is also needed to determine the detailed behavior for multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator reachability (Section 6). Finally, further deployment and experimentation would be useful to understand the real-life performance of the LISP-Multicast solution. For instance, the design @@ -330,22 +331,22 @@ routers. A router will accept a multicast packet for forwarding if the packet was received on the path that the router would use to forward unicast packets to the multicast packet's source. 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the - traffic engineering features of LISP, a multicast source site can - control the egress of its multicast traffic. By controlling the + traffic engineering features of LISP [LISP], a multicast source site + can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, there is no requirement for different locator- sets, priority, and weight policies for multicast than there is 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. @@ -530,102 +531,103 @@ ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures. 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: - IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for - LISP-Multicast for two reasons. One being that they are link- - local and not used over site boundaries and second, they advertise - group addresses that don't need translation. Where source - addresses are supplied in IGMPv3 and MLDv2 messages, they are - semantically regarded as EIDs and don't need to be converted to - RLOCs until the multicast tree-building protocol, such as PIM, is - received by the ETR at the site boundary. Addresses used for IGMP - and MLD come out of the source site's allocated addresses which - are therefore from the EID namespace. + IGMPv1-v3, MLDv1-v2: These protocols [RFC4604] do not require any + changes for LISP-Multicast for two reasons. One being that they + are link-local and not used over site boundaries and second, they + advertise group addresses that don't need translation. Where + source addresses are supplied in IGMPv3 and MLDv2 messages, they + are semantically regarded as EIDs and don't need to be converted + to RLOCs until the multicast tree-building protocol, such as PIM, + is received by the ETR at the site boundary. Addresses used for + IGMP and MLD come out of the source site's allocated addresses + which are therefore from the EID namespace. - MBGP: Even though MBGP is not a multicast routing protocol, it is - used to find multicast sources when the unicast BGP peering - topology and the multicast MBGP peering topology are not - congruent. When MBGP is used in a LISP-Multicast environment, the - prefixes which are advertised are from the RLOC namespace. This - allows receiver multicast sites to find a path to the source + MBGP: Even though MBGP [RFC4760] is not a multicast routing + protocol, it is used to find multicast sources when the unicast + BGP peering topology and the multicast MBGP peering topology are + not congruent. When MBGP is used in a LISP-Multicast environment, + the prefixes which are advertised are from the RLOC namespace. + This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. There are no MBGP protocol changes required to support LISP-Multicast. - MSDP: MSDP is used to announce active multicast sources to other - routing domains (or LISP sites). The announcements come from the - PIM Rendezvous Points (RPs) from sites where there are active - multicast sources sending to various groups. In the context of - LISP-Multicast, the source addresses advertised in MSDP will - semantically be from the EID namespace since they describe the - identity of a source multicast host. It will be true that the + MSDP: MSDP [RFC3618] is used to announce active multicast sources + to other routing domains (or LISP sites). The announcements come + from the PIM Rendezvous Points (RPs) from sites where there are + active multicast sources sending to various groups. In the + context of LISP-Multicast, the source addresses advertised in MSDP + will semantically be from the EID namespace since they describe + the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. There are no MSDP protocol changes required to support LISP-Multicast. PIM-SSM: In the simplest form of distribution tree building, when - PIM operates in SSM mode, a source distribution tree is built and - maintained across site boundaries. In this case, there is a small - modification to the operation of the PIM protocol. No - modifications to any message format, but to support taking a Join/ - Prune message originated inside of a LISP site with embedded - addresses from the EID namespace and converting them to addresses - from the RLOC namespace when the Join/Prune message crosses a site - boundary. This is similar to the requirements documented in - [RFC5135]. + PIM operates in SSM mode [RFC4607], a source distribution tree is + built and maintained across site boundaries. In this case, there + is a small modification to how PIM Join/Prune messages are sent by + the LISP-Multicast component. No modifications to any message + format, but to support taking a Join/Prune message originated + inside of a LISP site with embedded addresses from the EID + namespace and converting them to addresses from the RLOC namespace + when the Join/Prune message crosses a site boundary. This is + similar to the requirements documented in [RFC5135]. - PIM-Bidir: Bidirectional PIM is typically run inside of a routing - 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 - 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. - If the RP resides in the core where RLOC addresses are routed, - then the RP address is from the RLOC namespace. This could be - easily distinguishable if the EID address were well-known address - allocation block from the RLOC namespace. Also, when using - Embedded-RP for RP determination [RFC3956], the format of the - group address could indicate the namespace the RP address is from. - However, refer to Section 10 for considerations core routers need - to make when using Embedded-RP IPv6 group addresses. When using - Bidir-PIM for inter-domain multicast routing, it is recommended to - use staticly configured RPs. Allowing core routers to associate a - Bidir group's RP address with an ITR's RLOC address. And site - routers to associate the Bidir group's RP address as an EID - address. With respect to DF-election in Bidir PIM, no changes are - required since all messaging and addressing is link-local. + PIM-Bidir: Bidirectional PIM [RFC5015] is typically run inside of a + routing 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 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. If the RP resides in the core where RLOC addresses + are routed, then the RP address is from the RLOC namespace. This + could be easily distinguishable if the EID address were well-known + address allocation block from the RLOC namespace. Also, when + using Embedded-RP for RP determination [RFC3956], the format of + the group address could indicate the namespace the RP address is + from. However, refer to Section 10 for considerations core + routers need to make when using Embedded-RP IPv6 group addresses. + When using Bidir-PIM for inter-domain multicast routing, it is + recommended to use staticly configured RPs. Allowing core routers + to associate a Bidir group's RP address with an ITR's RLOC + address. And site routers to associate the Bidir group's RP + address as an EID address. With respect to DF-election in Bidir + PIM, no changes are required since all messaging and addressing is + link-local. - 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 - site and using source-trees across sites. By the use of MSDP and - PIM-SSM techniques described above, multicast connectivity can - occur across LISP sites. Having said that, that means there are - no special actions required for processing (*,G) or (S,G,R) Join/ - Prune messages since they all operate against the shared-tree - which is site resident. Just like with ASM, there is no (*,G) in - the core when LISP-Multicast is in use. This is also true for the - RP-mapping mechanisms Auto-RP and BSR. + PIM-ASM: The ASM mode of PIM [RFC4601], the most popular form of + PIM, is 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 PIM-SSM techniques described above, multicast + connectivity can occur across LISP sites. Having said that, that + means there are no special actions required for processing (*,G) + or (S,G,R) Join/Prune messages since they all operate against the + shared-tree which is site resident. Just like with ASM, there is + no (*,G) in the core when LISP-Multicast is in use. This is also + true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive @@ -961,22 +963,22 @@ Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled. Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, - Mweight) per RLOC. When the Mpriority is set to 255, the site is - considered not multicast capable. So an ETR in a LISP receiver + Mweight) per RLOC [LISP]. When the Mpriority is set to 255, the site + is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. 9.1.5. LISP Source Site to Any Receiver Sites When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism @@ -1271,85 +1273,91 @@ [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress). [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-08.txt (work in progress). Appendix A. Document Change Log -A.1. Changes to draft-ietf-lisp-multicast-12.txt +A.1. Changes to draft-ietf-lisp-multicast-13.txt + + o Posted February 2012. + + o Resolution to Stewart Bryant's and Adrian Farrel's comments. + +A.2. Changes to draft-ietf-lisp-multicast-12.txt o Posted January 2012. o Added more security disclaimers to the Security Considerations section. -A.2. Changes to draft-ietf-lisp-multicast-11.txt +A.3. Changes to draft-ietf-lisp-multicast-11.txt o Posted November 2011. o Added Stig text to Security Considerations section to reflect comments from IESG review comment from Stephen Farrell. o Changed how an unicast PIM join gets sent. Do not use an ECM or else an instance-ID cannot be included in the join. So go back to what we had where the unicast PIM join is encapsulated in a 4341 UDP packet. -A.3. Changes to draft-ietf-lisp-multicast-10.txt +A.4. Changes to draft-ietf-lisp-multicast-10.txt o Posted second half of October 2011. Changes to reflect IESG review comments from Stephen Farrell. -A.4. Changes to draft-ietf-lisp-multicast-09.txt +A.5. 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.5. Changes to draft-ietf-lisp-multicast-08.txt +A.6. Changes to draft-ietf-lisp-multicast-08.txt o Posted September 2011. Minor editorial changes from Jari's commentary. -A.6. Changes to draft-ietf-lisp-multicast-07.txt +A.7. Changes to draft-ietf-lisp-multicast-07.txt o Posted July 2011. Fixing IDnits errors. -A.7. Changes to draft-ietf-lisp-multicast-06.txt +A.8. 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.8. Changes to draft-ietf-lisp-multicast-05.txt +A.9. Changes to draft-ietf-lisp-multicast-05.txt o Posted April 2011 to reset expiration timer. o Updated references. -A.9. Changes to draft-ietf-lisp-multicast-04.txt +A.10. Changes to draft-ietf-lisp-multicast-04.txt o Posted October 2010 to reset expiration timer. o Updated references. -A.10. Changes to draft-ietf-lisp-multicast-03.txt +A.11. 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 @@ -1357,47 +1365,47 @@ 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.11. Changes to draft-ietf-lisp-multicast-02.txt +A.12. 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.12. Changes to draft-ietf-lisp-multicast-01.txt +A.13. 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.13. Changes to draft-ietf-lisp-multicast-00.txt +A.14. 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