--- 1/draft-ietf-mboned-msdp-deploy-01.txt 2006-02-05 00:20:27.000000000 +0100 +++ 2/draft-ietf-mboned-msdp-deploy-02.txt 2006-02-05 00:20:27.000000000 +0100 @@ -1,18 +1,18 @@ INTERNET-DRAFT Mike McBride -draft-ietf-mboned-msdp-deploy-01.txt John Meylor +draft-ietf-mboned-msdp-deploy-02.txt John Meylor David Meyer Category Best Current Practice Expires: November 2003 May 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. @@ -53,27 +53,27 @@ 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 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 10 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 12 - 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 14 - 8.2. Informative References. . . . . . . . . . . . . . . . . . . 14 - 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 15 - 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15 + 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 14 + 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: o Between PIM Domains MSDP can be used between Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC2362] domains to convey information about active sources available in other domains. MSDP peering @@ -105,30 +105,30 @@ Multicast (ASM) service. 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 In this case, the MSDP peers within the domain have their own RP - located within a bounded PIM domain. In addition, a domain has it's - own Autonomous System (AS) number 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 other providers, providers - peering at an exchange, or providers who use their edge router to - MSDP/MBGP peer with customers. + 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 + other providers, providers peering at an exchange, or providers who + use their edge router to MSDP/MBGP peer with customers. 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 | / | / | / @@ -146,21 +146,21 @@ 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 + 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 When MSDP peering between border routers, intra-domain MSDP scalability is restricted because it is necessary to also maintain @@ -221,31 +221,31 @@ 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 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 - is used which allows for an MSDP peer RPF check using an IGP. + 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 BGP RPF + will MSDP default peer towards the provider and skip the peer-RPF check. 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 @@ -282,59 +282,59 @@ Where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb (using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update from MSDP peer 2.2.2.2 which is also the correct MBGP next hop for 1.1.1.1. 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. - 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. + 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) 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 o By configuring a default MSDP peer o By peering with the originating RP. - o By relying upon an IGP for MSDP peer RPF + o By relying upon an IGP for MSDP peer-RPF The common choice around the intra-domain BGP peering requirement, when more than one MSDP peer is configured, is to deploy MSDP mesh groups. When a MSDP mesh group is deployed, there is no RPF check on arriving SA messages when received from a mesh group peer. Subsequently, SA messages are always accepted from mesh group peers. MSDP mesh groups were developed to reduce the amount of SA traffic in the network since SAs, which arrive from a mesh group peer, are not flooded to peers within that same mesh group. Mesh groups must be fully meshed. If recent (but not currently widely deployed) router code is running which is fully complaint with the latest MSDP draft, another option, to work around not having BGP to MSDP RPF peer, is to RPF using an IGP like OSPF, IS-IS, RIP, etc. This new capability will allow for - Enterprise customers, who are not running BGP and who don't want to - run mesh groups, to use their existing IGP to satisfy the MSDP peer + enterprise customers, who are not running BGP and who don't want to + run mesh groups, to use their existing IGP to satisfy the MSDP peer- RPF rules. 3.3. Hierarchical Mesh Groups Hierarchal Mesh Groups are occasionally deployed in intra-domain environments where there are a large number of MSDP peers. Allowing multiple mesh groups to forward to one another can reduce the number of MSDP peerings per router (due to the full mesh requirement) and hence reduce router load. A good hierarchical mesh group implementation (one which prevents looping) contains a core mesh @@ -355,35 +355,35 @@ group) and each serves as MSDP aggregation routers for their leaf (or second tier) mesh groups 1, 2, and 3. Since SA messages received from a mesh group peer are not forwarded to peers within that same mesh group, SA messages will not loop. Do not create topologies which connect mesh-groups in a loop. In the above example for instance, second tier mesh-groups 1, 2, and 3 must not directly exchange SA messages with each other or an endless SA loop will occur. Redundancy, between mesh groups, will also cause a loop and is subsequently not available with Hierarchical mesh groups. For - instance, assume R3 had two routers connecting it's leaf mesh group 3 + instance, assume R3 had two routers connecting its leaf mesh group 3 with the core mesh group A. A loop would be created between mesh group 3 and mesh group A because each mesh group must be fully meshed between peers. 3.4. MSDP and Route Reflectors - or confederation members, be fully meshed to prevent loops. In - the route reflector environment, MSDP requires that the route - reflector clients peer with the route reflector since the RR is - the BGP announcer of the next hop towards the originating - RP. The RR is not the BGP next hop, but is the announcer of the - BGP next hop. The announcer of the next hop is the address - typically used for MSDP peer RPF checks. For example, consider - the following case: + BGP requires all iBGP speakers, that are not route-reflector clients + or confederation members, be fully meshed to prevent loops. In the + route reflector environment, MSDP requires that the route reflector + clients peer with the route reflector since the router reflector (RR) + is the BGP announcer of the next hop towards the originating RP. The + RR is not the BGP next hop, but is the announcer of the BGP next hop. + The announcer of the next hop is the address typically used for MSDP + peer-RPF checks. For example, consider the following case: Ra--------RR /|\ / | \ A B C Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, and C also MSDP peer with RR. When RR forwards the SA to A, B, and C, these RR clients will accept the SA because RR is the announcer of the next hop to the originating RP address. @@ -403,21 +403,21 @@ the Next-Hop, in addition to the Advertiser of the next hop. In the example above, for instance, if Ra is the Next-Hop (perhaps due to using BGP's Next hop self attribute) and if routers A,B,C are peering with Ra, the SA's received from Ra will now succeed. 3.5. MSDP and Anycast RPs A network, with multiple RPs, can achieve RP load sharing and redundancy by using the Anycast RP mechanism in conjunction with MSDP mesh groups [RFC3446]. This mechanism is a common deployment - technique used within a domain by service providers and Enterprises + technique used within a domain by service providers and enterprises which deploy several RPs within their domain. These RPs will each have the same IP address configured on a Loopback interface (making this the Anycast address). These RPs will MSDP peer with each other using a separate loopback interface and are part of the same fully meshed MSDP mesh group. This loopback interface, used for MSDP peering, will typically also be used for the MBGP peering. All routers within the provider's domain will learn of the Anycast RP address either through Auto-RP, BSR, or a static RP assignment. Each designated router in the domain will send source registers and group joins to the Anycast RP address. Unicast routing will direct those @@ -445,80 +445,139 @@ 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 and Swapna Yelamanchi - for their feedback on earlier versions of this document. + 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. 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- + 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 of points where local policy should be applied to the MSDP service. 6.1. Filtering SA messages - The process of originating sa-messages should be filtered to ensure - only intended local sources are resulting in sa-message origination. - In addition, MSDP speakers should filter on which sa-messages get + The process of originating SA messages should be filtered to ensure + only intended local sources are resulting in SA message origination. + 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. - 224.0.0.0/4 Specific local application packets [IANA] - 224.0.1.39 Auto-RP Announce [AUTORP] - 224.0.1.40 Auto-RP Discovery [AUTORP] - 239.0.0.0/8 Administratively Scoped IP Multicast [RFC2365] + 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 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] - 232.0.0.0/8 Default SSM-range [SSM] 6.2. SA message state limits - Proper filtering on sa-message origination, receipt, and forwarding + 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. 7. IANA Considerations This document creates a no new requirements on IANA namespaces [RFC2434]. 8. References 8.1. Normative References [MSDP] Meyer, D. and W. Fenner (Editors), "The Multicast - Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-19.txt, + Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-20.txt, May 2003. Work in Progress. [SSM] Holbrook, H., and B. Cain, "Source-Specific 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 @@ -533,20 +592,23 @@ 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. [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, 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. 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,