--- 1/draft-ietf-mboned-msdp-deploy-02.txt 2006-02-05 00:20:28.000000000 +0100 +++ 2/draft-ietf-mboned-msdp-deploy-03.txt 2006-02-05 00:20:28.000000000 +0100 @@ -1,18 +1,18 @@ INTERNET-DRAFT Mike McBride -draft-ietf-mboned-msdp-deploy-02.txt John Meylor +draft-ietf-msdp-deploy-03.txt John Meylor David Meyer Category Best Current Practice -Expires: November 2003 May 2003 +Expires: January 2004 July 2003 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios - + Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. @@ -21,53 +21,59 @@ 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 document is a product of an individual. Comments are solicited - and should be addressed to the author(s). + 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 RFC 2119 [RFC 2119]. + + This document is a product of the MBONED Working Group. Comments + should be addressed to the authors, or the mailing list at + mboned@ns.uoregon.edu. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Inter-domain MSDP peering scenarios. . . . . . . . . . . . . . 3 - 2.1. Peering between PIM border routers. . . . . . . . . . . . . 4 - 2.2. Peering between non border routers. . . . . . . . . . . . . 5 - 2.3. MSDP peering without BGP. . . . . . . . . . . . . . . . . . 6 - 2.4. MSDP peering at a Multicast Exchange. . . . . . . . . . . . 7 - 3. Intra-domain MSDP peering scenarios. . . . . . . . . . . . . . 7 - 3.1. Peering between MSDP and MBGP configured routers. . . . . . 7 - 3.2. MSDP peer is not BGP peer (or no BGP peer). . . . . . . . . 8 - 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 9 + 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 4 + 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 4 + 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 5 + 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 7 + 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 7 + 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 8 + 3.1. Peering between MSDP and MBGP Configured + Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 9 + 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 10 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 10 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11 - 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 11 + 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 - 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 12 - 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 14 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 + 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 13 + 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References. . . . . . . . . . . . . . . . . . . 16 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 1. Introduction MSDP [MSDP] is used primarily in two deployment scenarios: @@ -97,26 +103,48 @@ one-to-one peering with MSDP peers outside that PIM domain for discovery of external sources. MSDP for anycast-RP without external MSDP peering is a valid deployment option and common. Current best practice for MSDP deployment utilizes PIM-SM and the Border Gateway Protocol with multi-protocol extensions (MBGP) [RFC1771, RFC2858]. This document outlines how these protocols work together to provide an intra-domain and inter-domain Any Source Multicast (ASM) service. -2. Inter-domain MSDP peering scenarios + Multicast (ASM) service. The PIM-SM specification assumes that SM + operates only in one PIM domain. MSDP is used to enable the use of + multiple PIM domains by distributing the required information about + active multicast sources to other PIM domains. Due to breaking the + Internet multicast infrastructure down to multiple PIM domains, MSDP + also enables the possibility to set policy on the visibility of the + groups and sources. + + Transit IP providers typically deploy MSDP to be part of the global + multicast infrastructure by connecting to their upstream and peer + multicast networks using MSDP. + + Edge multicast networks typically have two choices: to use their + Internet providers RP, or to have their own RP and connect it to + their ISP using MSDP. By deploying their own RP and MSDP, one can + use internal multicast groups which are not visible to the provider's + RP. This helps with internal multicast being able to continue to work + in the event there is a problem with connectivity to the provider or + the provider's RP/MSDP is experiencing difficulties. In the simplest + cases where no internal multicast groups are necessary, there is + often no need to deploy MSDP. + +2. Inter-domain MSDP Peering Scenarios The following sections describe the most common inter-domain MSDP peering possibilities and their deployment options. -2.1. Peering between PIM border routers +2.1. Peering between PIM Border Routers In this case, the MSDP peers within the domain have their own RP located within a bounded PIM domain. In addition, the domain will typically have its own Autonomous System (AS) number and one or more MBGP speakers. The domain may also have multiple MSDP speakers. Each border router has an MSDP and MBGP peering with its peer routers. These external MSDP peering deployments typically configure the MBGP peering and MSDP peering using the same directly connected next hop peer IP address or other IP address from the same router. Typical deployments of this type are providers who have a direct peering with @@ -126,27 +154,26 @@ For a direct peering inter-domain environment to be successful, the first AS in the MBGP best path to the originating RP should be the same as the AS of the MSDP peer. As an example, consider the following topology: AS1----AS2----AS4 | / | / | / AS3 - In this case, AS4 receives a Source Active (SA) message, originated by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP first hop AS from AS4, in the best path to the originating RP, is - AS2. The origin AS of the sending MSDP peer is also AS2. In this - case, the peer-Reverse Path Forwarding check (peer-RPF check) passes - and the SA message is forwarded. + AS2. The AS of the sending MSDP peer is also AS2. In this case, the + peer-Reverse Path Forwarding check (peer-RPF check) passes and the SA + message is forwarded. A peer-RPF failure would occur in this topology when the MBGP first hop AS, in the best path to the originating RP, is AS2 while the origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS PATH information prevents endless looping of SA packets. Router code, which has adopted the latest rules in the MSDP draft, will relax the rules Between AS's a bit. In the following topology we have an MSDP peering between AS1<->AS3 and AS3<->AS4: @@ -145,125 +172,140 @@ hop AS, in the best path to the originating RP, is AS2 while the origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS PATH information prevents endless looping of SA packets. Router code, which has adopted the latest rules in the MSDP draft, will relax the rules Between AS's a bit. In the following topology we have an MSDP peering between AS1<->AS3 and AS3<->AS4: RP AS1----AS2----AS3----AS4 + If the first AS in best path to the RP does not equal the MSDP peer, MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3 since AS2 is the first AS in the MBGP best path to AS4 RP. With the latest MSDP draft compliant code, AS 1 will choose the peer in the closest AS along best AS path to the RP. AS1 will then accept SA's coming from AS3. If there are multiple MSDP peers to routers within the same AS, the peer with the highest IP address is chosen as the RPF peer. -2.2. Peering between non border routers +2.2. Peering between Non-Border Routers When MSDP peering between border routers, intra-domain MSDP scalability is restricted because it is necessary to also maintain MBGP and MSDP peerings internally towards their border routers. Within the intra-domain, the border router becomes the announcer of the next hop towards the originating RP. This requires that all intra-domain MSDP peerings must mirror the MBGP path back towards the border router. External MSDP (eMSDP) peerings rely upon AS path for - peer rpf checking, while internal MSDP (iMSDP) peerings rely upon the + peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the announcer of the next hop. While the eMBGP peer is typically directly connected between border routers, it is common for the eMSDP peer to be located deeper into the transit providers AS. Providers, which desire more flexibility in MSDP peering placement, commonly choose a few dedicated routers within their core network for the inter-domain MSDP peerings to their customers. These core MSDP routers will also typically be in the providers intra-domain MSDP mesh group and configured for Anycast RP. All multicast routers in the providers AS should statically point to the Anycast RP address. Static RP assignment is the most commonly used method for group to RP mapping due to its deterministic nature. Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP mapping mechanisms could be also used to disseminate RP information within the provider's network For an SA message to be accepted in this (multi-hop peering) environment, we rely upon the next (or closest, with latest MSDP - spec) AS in the best path towards originating RP for the rpf check. + spec) AS in the best path towards originating RP for the RPF check. The MSDP peer address should be in the same AS as the AS of the - border routers MBGP peer. The MSDP peer address should be advertised + border router's MBGP peer. The MSDP peer address should be advertised via MBGP. For example, using the diagram below, if customer R1 router is MBGP peering with R2 router and if R1 is MSDP peering with R3 router, then - R2 and R3 must be in the same AS. The MSDP peer with the highest IP - address will be chosen as the MSDP RPF peer. R1 must also have the - MSDP peer address of R3 in its MBGP table. + R2 and R3 must be in the same AS (or appear, to AS1, to be from the + same AS in the event private AS numbers are deployed). The MSDP peer + with the highest IP address will be chosen as the MSDP RPF peer. R1 + must also have the MSDP peer address of R3 in its MBGP table. +--+ +--+ +--+ |R1|----|R2|----|R3| +--+ +--+ +--+ AS1 AS2 AS2 From R3's perspective, AS1 (R1) is the MBGP next AS in the best path towards the originating RP. As long as AS1 is the next AS (or closest) in the best path towards the originating RP, RPF will succeed on SAs arriving from R1. In contrast, with the single hop scenario, with R2 (instead of R3) - border MSDP peering with R1 border, R2s MBGP address becomes the + border MSDP peering with R1 border, R2's MBGP address becomes the announcer of the next hop for R3, towards the originating RP, and R3 must peer with that R2 address. And all AS2 intra-domain MSDP peers need to follow iMBGP (or other IGP) peerings towards R2 since iMSDP has a dependence upon peering with the address of the MBGP (or other IGP) announcer of the next hop. -2.3. MSDP peering without BGP +2.3. MSDP Peering without BGP In this case, an enterprise maintains its own RP and has an MSDP peering with their service provider, but does not BGP peer with them. MSDP relies upon BGP path information to learn the MSDP topology for the SA peer-RPF check. MSDP can be deployed without BGP, however, and as a result there are some special cases where the requirement to perform an peer-RPF check on the BGP path information is suspended. + These cases are: + + o There is only a single MSDP peer connection + + o A default peer (default MSDP route) is configured + + o The originating RP is directly connected + + o A mesh group is used + + o An implementation is used which allows for an MSDP peer-RPF + check using an IGP + These cases are when there is only a single MSDP peer connection, a default peer (default MSDP route) is configured, the originating RP is directly connected, a mesh group is used, or an implementation is used which allows for an MSDP peer-RPF check using an IGP. An enterprise will typically configure a unicast default route from their border router to the provider's border router and then MSDP peer with the provider's MSDP router. If internal MSDP peerings are also used within the enterprise, then an MSDP default peer will need to be configured on the border router pointing to the provider. In this way, all external multicast sources will be learned and internal sources can be advertised. If only a single MSDP peering was used (no internal MSDP peerings) towards the provider, then this stub site will MSDP default peer towards the provider and skip the peer-RPF check. -2.4. MSDP peering at a Multicast Exchange +2.4. MSDP Peering at a Multicast Exchange Multicast exchanges allow multicast providers to peer at a common IP subnet (or by using point to point virtual LANs) and share MSDP SA updates. Each provider will MSDP and MBGP peer with each others directly connected exchange IP address. Each exchange router will send/receive SAs to/from their MSDP peers. They will then be able to forward SAs throughout their domain to their customers and any direct provider peerings. -3. Intra-domain MSDP peering scenarios +3. Intra-domain MSDP Peering Scenarios The following sections describe the different intra-domain MSDP peering possibilities and their deployment options. -3.1. Peering between MSDP and MBGP configured routers +3.1. Peering between MSDP and MBGP Configured Routers The next hop IP address of the iBGP peer is typically used for the MSDP peer-RPF check (IGP can also be used). This is different from the inter-domain BGP/MSDP case, where AS path information is used for the peer-RPF check. For this reason, it is necessary for the IP address of the MSDP peer connection be the same as the internal MBGP peer connection whether or not the MSDP/MBGP peers are directly connected. A successful deployment would be similar to the following: +----+ @@ -287,21 +330,21 @@ When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly fails, preventing a loop. This deployment could also fail on an update from Ra to RP2 if RP2 was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain deployments must have MSDP and MBGP (or other IGP) peering addresses which match, unless a method to skip the peer-RPF check is deployed. -3.2. MSDP peer is not BGP peer (or no BGP peer) +3.2. MSDP Peer is not BGP Peer (or no BGP Peer) This is a common MSDP intra-domain deployment in environments where few routers are running MBGP or where the domain is not running MBGP. The problem here is that the MSDP peer address needs to be the same as the MBGP peer address. To get around this requirement, the intra- domain MSDP RPF rules have been relaxed in the following topologies: o By configuring the MSDP peer as a mesh group peer o By having the MSDP peer be the only MSDP peer @@ -445,24 +488,23 @@ be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 5. Acknowledgments - The authors would like to thank John Zwiebel, Swapna Yelamanchi, Greg - Shepherd, and Jay Ford for their feedback on earlier versions of this - document. The list of group addresses listed in section 6.1 is due to - Bill Nickless. + The authors would like to thank Pekka Savola, John Zwiebel, Swapna + Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier + versions of this document. 6. Security Considerations An MSDP service should be secured by explicitly controlling the state which is created by, and passed within, the MSDP service. As with unicast routing state, MSDP state should be controlled locally, at the edge origination points. Selective filtering at the multicast service edge helps ensure that only intended sources result in SA message creation, and this control helps to reduce the likelihood of state-aggregation related problems in the core. There are a variety @@ -475,97 +517,34 @@ In addition, MSDP speakers should filter on which SA messages get received and forwarded. Typically there is a fair amount of (S,G) state in a PIM-SM domain that is local to the domain. However, without proper filtering, sa- messages containing these local (S,G) announcements may be advertised to the global MSDP infrastructure. Examples of this includes domain local applications that use global IP multicast addresses and sources that use RFC 1918 addresses [RFC1918]. To improve on the scalability of MSDP and to avoid global visibility of domain local (S,G) - information, the following external SA filter list is recommended to - help prevent unnecessary creation, forwarding, and caching of some of - these well-known domain local sources. - - Group Address Use Reference - ------------------------------------------------------------------- - 224.0.0.0/24 Specific local application packets [IANA] - 224.0.1.22/32 SVRLOC - 224.0.1.22/32 Microsoft-DS - 224.0.1.35/32 SVRLOC-DA - 224.0.1.39/32 CISCO-RP-ANNOUNCE [AUTORP] - 224.0.1.40/32 CISCO-RP-DISCOVERY [AUTORP] - 224.0.2.2/32 SUN-RPC - 224.77.0.0/16 Norton Ghost - 224.128.0.0/24 Control plane of IGMP snoopers - 225.0.0.0/24 Control plane of IGMP snoopers - 225.1.2.3/32 Altiris - 225.128.0.0/24 Control plane of IGMP snoopers - 226.0.0.0/24 Control plane of IGMP snoopers - 226.77.0.0/16 Norton Ghost - 226.128.0.0/24 Control plane of IGMP snoopers - 227.0.0.0/24 Control plane of IGMP snoopers - 227.128.0.0/24 Control plane of IGMP snoopers - 228.0.0.0/24 Control plane of IGMP snoopers - 228.128.0.0/24 Control plane of IGMP snoopers - 229.0.0.0/24 Control plane of IGMP snoopers - 229.128.0.0/24 Control plane of IGMP snoopers - 230.0.0.0/24 Control plane of IGMP snoopers - 230.128.0.0/24 Control plane of IGMP snoopers - 231.0.0.0/24 Control plane of IGMP snoopers - 231.128.0.0/24 Control plane of IGMP snoopers - 232.0.0.0/24 Control plane of IGMP snoopers - 232.128.0.0/24 Control plane of IGMP snoopers - 233.0.0.0/8 Source-Specific Multicast [SSM] - 233.0.0.0/24 Control plane of IGMP snoopers - 233.128.0.0/24 Control plane of IGMP snoopers - 234.0.0.0/24 Control plane of IGMP snoopers - 234.42.42.42/32 Phoenix/StorageSoft ImageCast - 234.128.0.0/24 Control plane of IGMP snoopers - 234.142.142.42/31 Phoenix/StorageSoft ImageCast - 234.142.142.44/30 Phoenix/StorageSoft ImageCast - 234.142.142.48/28 Phoenix/StorageSoft ImageCast - 234.142.142.64/26 Phoenix/StorageSoft ImageCast - 234.142.142.128/29 Phoenix/StorageSoft ImageCast - 234.142.142.136/30 Phoenix/StorageSoft ImageCast - 234.142.142.140/31 Phoenix/StorageSoft ImageCast - 234.142.142.142/32 Phoenix/StorageSoft ImageCast - 235.0.0.0/24 Control plane of IGMP snoopers - 235.128.0.0/24 Control plane of IGMP snoopers - 236.0.0.0/24 Control plane of IGMP snoopers - 236.128.0.0/24 Control plane of IGMP snoopers - 237.0.0.0/24 Control plane of IGMP snoopers - Group Address Use Reference - ------------------------------------------------------------------- - 237.128.0.0/24 Control plane of IGMP snoopers - 238.0.0.0/24 Control plane of IGMP snoopers - 238.128.0.0/24 Control plane of IGMP snoopers - 239.0.0.0/8 Administratively Scoped Groups [RFC2365] - 239.0.0.0/24 Control plane of IGMP snoopers - 239.128.0.0/24 Control plane - - Source Address Use Reference - ------------------------------------------------------------------- - 0.0.0.0/32 Any/This/Default [RFC3330] - 10.0.0.0/8 Private addresses [RFC1918] - 127.0.0.0/8 Loopback addresses [RFC1918] - 169.254.0.0/16 DHCP auto-config local-use [RFC3330] - 172.16.0.0/12 Private addresses [RFC1918] - 192.0.2.0/24 TEST-NET [RFC3330] - 192.168.0.0/16 Private addresses [RFC1918] + information, an external SA filter list is recommended to help + prevent unnecessary creation, forwarding, and caching of well-known + domain local sources [UNUSABLE]. 6.2. SA message state limits Proper filtering on SA message origination, receipt, and forwarding will significantly reduce the likelihood of unintended and unexpected spikes in MSDP state However, a sa-cache state limit SHOULD BE be - configured as a final safeguard to state spikes. + configured as a final safeguard to state spikes. When an MSDP peering + has reached a stable state (i.e., when the peering has been + established and the initial SA state has been transferred), it may + also be desirable to configure a rate limiter for the creation of new + SA state entries. 7. IANA Considerations This document creates a no new requirements on IANA namespaces [RFC2434]. 8. References 8.1. Normative References @@ -577,20 +556,24 @@ Multicast for IP", draft-ietf-ssm-arch-03.txt, May, 2003. Work in Progress. [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, "Address Allocation for Private Internets", RFC 1918, Feburary, 1996. + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels" RFC 2119/BCP 14, + March 1997. + [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June, 1998. [RFC2365] Meyer, D. "Administratively Scoped IP Multicast", RFC 2365, July, 1998. [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434/BCP 0026, October, 1998. @@ -600,45 +583,49 @@ June 2000. [RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330, September 2002. [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) Mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January, 2003. + [UNUSABLE] Nickless, B., "IPv4 Multicast Unusable Group And + Source Addresses", draft-nickless-ipv4-mcast-unusable-02.txt, + June, 2003. Work in Progress. + 8.2. Informative References [AUTORP] Fenner, W., et. al., " Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-07.txt, March, 2003. Work in Progress. [BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, February, 2003. Work in Progress. [IANA] http://www.iana.org 9. Author's Addresses Mike McBride - Isac Systems + Cisco Systems Email: mcbride@cisco.com John Meylor Cisco Systems Email: jmeylor@cisco.com David Meyer - Email: dmm@maoz.com + Email: dmm@1-4-5.net 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are