idnits 2.17.1 draft-ietf-mboned-msdp-deploy-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 48 has weird spacing: '... depend on RP...' == Line 78 has weird spacing: '...llowing topol...' == Line 190 has weird spacing: '...cessary for t...' == Line 310 has weird spacing: '...clients will ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'MSDP' on line 370 looks like a reference -- Missing reference section? 'RFC2117' on line 380 looks like a reference -- Missing reference section? 'RFC2858' on line 388 looks like a reference -- Missing reference section? 'NICKLESS' on line 365 looks like a reference -- Missing reference section? 'ANYCAST-RP' on line 362 looks like a reference -- Missing reference section? 'RFC1918' on line 377 looks like a reference -- Missing reference section? 'IANA' on line 368 looks like a reference -- Missing reference section? 'RFC1771' on line 374 looks like a reference -- Missing reference section? 'RFC2362' on line 384 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group Mike McBride 2 Internet Draft John Meylor 3 Cisco Systems 4 David Meyer 5 Sprint 6 Category Best Current Practice 7 draft-ietf-mboned-msdp-deploy-00.txt February, 2002 9 Multicast Source Discovery Protocol Deployment Scenarios 11 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 This document describes best current practices for intra-domain and 37 inter-domain MSDP deployment. 39 3. Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 4. Introduction 45 The Multicast Source Discovery Protocol [MSDP] is a mechanism to 46 connect multiple PIM-SM [RFC2117] domains together. Each PIM-SM 47 domain uses its own independent Rendezvous Point, or RP, and does not 48 have to depend on RPs in other domains. Current best practice for 49 MSDP deployment utilizes Protocol Independent Multicast (Sparse Mode) 50 and the Border Gateway Protocol With multi-protocol extensions 51 [RFC2858,NICKLESS]. This document outlines how these protocols work 52 together to provide Intra-domain and Inter-domain Any Source 53 multicast (ASM) service. In addition, this document describes how 54 MSDP can provide a PIM-SM domain with RP redundancy and load 55 balancing using the Anycast RP mechanism [ANYCAST-RP]. 57 5. Inter-domain MSDP peering scenarios 59 The following sections describe the different inter-domain MSDP 60 peering possibilities and their deployment options. 62 5.1. Peering between PIM border routers (Single hop peering) 64 In this case, the MSDP peers within the domain each have their own RP 65 located within a bounded PIM domain. In addition, a domain has it's 66 own Autonomous Number (AS) and BGP speakers. The domain may also have 67 multiple MSDP speakers. Each router has an MSDP and BGP peering with 68 its peer routers. These deployments typically configure the BGP 69 peering and MSDP peering using the same directly connected next hop 70 peer IP address or another IP address from the same router. Typical 71 deployments of this type are providers who have a direct peering with 72 other providers or with providers who use their edge router to 73 MSDP/MBGP peer with customers. 75 For a direct peering inter-domain environment to be successful, the 76 first AS in the BGP best path to the originating RP must be the same 77 as the AS of the MSDP peer [MSDP]. As an example, consider the 78 following topology: 80 AS1----AS2----AS4 81 | / 82 | / 83 | / 84 AS3 86 In this case, AS4 receives an Source Active SA Message (SA), 87 originated by AS1 via AS2, which also has an BGP peering with AS4. 88 The BGP first hop AS from AS4, in the best path to the originating 89 RP, is AS2. The origin AS of the sending MSDP peer is also AS2. The 90 peer-RPF (Reverse Path Forwarding) check passes and the SA message is 91 forwarded. 93 A peer-RPF failure will occur in this topology when the BGP first-hop 94 AS in the best path to the originating RP is AS2 while the origin AS 95 of the sending MSDP peer is AS3. An MSDP peering between AS2 and AS4 96 would prevent this failure from occurring. 98 5.2. Peering between non border routers (Multi-hop peering) 100 While the eBGP peer is typically directly connected between border 101 routers, it is common for the MSDP peer to be located deeper into the 102 transit providers AS. However, MSDP scalability is sacrificed if a 103 provider must maintain BGP and MSDP peerings with all their edge 104 routers so that they can BGP and MSDP peer with customer routers. 105 Alternatively, providers commonly choose a few dedicated routers 106 within their core network for the inter-domain MSDP peerings to their 107 customers. These core MSDP routers will also typically be in the 108 providers intra-domain MSDP mesh [MSDP] group and configured for 109 Anycast RP. All multicast routers in the providers AS should 110 statically point to the Anycast RP address. AutoRP and BSR mechanisms 111 could be used to disseminate RP information within the provider's 112 network. 114 For an SA message to be accepted in this (multi-hop peering) 115 environment, the MSDP peer address must be in the same AS as the AS 116 of the MBGP peer and must be advertised via MBGP. For example, using 117 the diagram below, if customer R1 router is MBGP peering with AS2 118 provider's R2 router and if R1 is MSDP peering with R3 router, then 119 R2 and R3 must be in the same AS. R1 also must have the MSDP peer 120 address of R3 in its BGP table. 122 +--+ +--+ +--+ 123 |R1|----|R2|----|R3| 124 +--+ +--+ +--+ 125 AS1 AS2 AS2 127 5.3. MSDP peering without BGP 129 In this case, an enterprise maintains its own RP and has an MSDP 130 peering with their service provider, but does not BGP peer with them. 131 MSDP relies upon BGP path information to learn the MSDP topology for 132 the SA peer-RPF check. MSDP can be deployed without BGP, however, and 133 as a result there are some special cases where the requirement to 134 perform an peer-RPF check on the BGP path information is suspended. 135 In this case (when there is only a single MSDP peer connection) a 136 default peer (default MSDP route) is configured and either the 137 originating RP is directly connected or a mesh group is used. An 138 enterprise will also typically configure a unicast default route from 139 their border router to the provider's border router and then MSDP 140 peer with the provider's border router. If internal MSDP peerings are 141 also used within the enterprise, then an MSDP default peer will need 142 to be configured on the border router pointing to the provider. In 143 this way, all external multicast sources will be learned and internal 144 sources can be advertised. 146 5.4. MSDP peering between mesh groups 148 Mesh groups which are within different PIM domains can MSDP peer with 149 one another to exchange information about active sources. An RP 150 within AS1's mesh group may MSDP peer with an RP which is within 151 AS2's mesh group. However, there should be no mesh group in common 152 between PIM domains. It is important to note however, that mesh 153 groups that span PIM domains is not recommended, as SA forwarding 154 loops can develop. As an example, consider the following topology: 156 AS2 157 / \ 158 / \ 159 / \ 160 / \ 161 / \ 162 AS1 -------- AS3 164 If each AS had their own intra-domain MSDP mesh group, and if there 165 was an inter-domain MSDP mesh group between AS1-AS2, AS1-AS3, and 166 AS2-AS3 then an SA loop would be created. Since there is no RPF check 167 between mesh groups, the SAs would loop around from one PIM domain to 168 another. 170 5.5. MSDP peering at a Multicast Exchange 172 Multicast exchanges allow multicast providers to peer at a common IP 173 subnet and share MSDP SA updates. Each provider will MSDP and BGP 174 peer with each others directly connected exchange IP address. Each 175 exchange router will send/receive SAs over the exchange fabric. They 176 will then be able to forward SAs throughout their domain to their 177 customers and any direct provider peerings. 179 6. Intra-domain MSDP peering scenarios 181 The following sections describe the different intra-domain MSDP 182 peering possibilities and their deployment options. 184 6.1. Peering between routers configured for both MSDP and MBGP 186 The next hop IP address of the iBGP peer (that is MSDP is advertising 187 as the next hop toward the originating RP) is used for the peer-RPF 188 check. This is different from the inter-domain BGP/MSDP case, where 189 AS path information is used for the peer-RPF check. For this reason, 190 it is necessary for the IP address of the MSDP peer connection be 191 the same as the internal BGP peer connection whether or not the 192 MSDP/MBGP peers are directly connected. A successful deployment would 193 be similar to the following: 195 +----+ 196 | Rb | 3.3.3.3 197 / +----+ 198 AS1 AS2 / | 199 +---+ +--+ / | 200 |RP1|---------|Ra| | 201 +---+ +--+ | 202 1.1.1.1 2.2.2.2 | 203 \ | 204 \ | 205 \ +-----+ 206 | RP2 | 207 +-----+ 209 Where RP2 MSDP and MBGP peers with Ra using 2.2.2.2 and with Rb using 210 3.3.3.3. When the MSDP SA update arrives on RP2 from Ra, the MSDP RPF 211 check for 1.1.1.1 passes because RP2 receives the SA update from 212 2.2.2.2 which is the correct BGP next hop for 1.1.1.1. 214 When RP2 receives the same SA update from MSDP peer 3.3.3.3, the BGP 215 lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly 216 fails, preventing a loop. 218 This deployment would also fail on an update from Ra to RP2 if RP2 219 was BGP peering to an address other than 2.2.2.2 on Ra. Intra-domain 220 deployments should have MSDP and MBGP peering addresses which match. 222 6.2. MSDP peer is not BGP peer (or no BGP peer) 224 This is a common MSDP intra-domain deployment in environments where 225 few routers are running BGP or where the domain is not running BGP. 226 The problem here is that the MSDP peer address needs to be the same 227 as the BGP peer address. To get around this requirement, the intra- 228 domain MSDP RPF rules have been relaxed in certain as follows: 230 o By configuring the MSDP peer as a mesh group peer, 231 o By having the MSDP peer be the only MSDP peer, 232 o By configuring a default MSDP peer, or 233 o By peering with the originating RP. 235 The common choice around the intra-domain BGP peering requirement, 236 when more than one MSDP peer is configured, is to deploy MSDP mesh 237 groups. When a MSDP mesh group is deployed, there is no RPF check on 238 arriving SA messages when received from a mesh group peer. 239 Subsequently, SA messages are always accepted from mesh group peers. 241 MSDP mesh groups are helpful in reducing the amount of SA traffic in 242 the network since SAs are not flooded to other mesh group peers. 244 7. MSDP and Anycast RPs 246 A network with can achieve RP load sharing and redundancy by using 247 the Anycast RP mechanism in conjunction with MSDP mesh groups 248 [ANYCAST-RP]. This mechanism is a common deployment technique used by 249 service providers, who commonly deploy several RPs within their 250 domain. These RPs will all have the same IP address configured on a 251 Loopback interface (making this the anycast addresses). These RPs 252 will MSDP peer with each other using a separate loopback interface 253 and are part of the same MSDP mesh group. This second Loopback 254 interface will typically also be used for the MBGP peering. All 255 routers within the provider's domain will learn of the Anycast RP 256 address either through AutoRP, BSR, or a static RP assignment. Each 257 designated router in the domain will send source registers and group 258 joins to the Anycast RP address. Unicast routing will direct those 259 registers and joins to the nearest Anycast RP. If a particular 260 Anycast RP router fails, unicast routing will direct subsequent 261 registers and joins to the nearest Anycast RP. That RP will then 262 forward an MSDP update to all peers within the global MSDP mesh 263 group. Each RP will then forward (or receive) the SAs to (from) 264 external customers and providers. 266 7.1. Hierarchical Mesh Groups 268 Hierarchial Mesh Groups are typically deployed in intra-domain 269 environments where there are a large number of MSDP peers. Allowing 270 multiple mesh groups to forward to one another can reduce the number 271 of MSDP peerings per router and hence reduce router load. A good 272 hierarchical mesh group implementation (one which prevents looping) 273 contains a core mesh group in the backbone and these core routers 274 serve as mesh group aggregation routers: 276 [R2]{A,2} 277 / \ 278 / \ 279 / \ 280 / \ 281 / \ 282 / \ 283 / \ 284 {A,1}[R1]-------------[R3]{A,3} 286 In this example, R1, R2, R3 are in MSDP mesh group A (the core mesh 287 group) and each serves as MSDP aggregation routers for their mesh 288 groups 1, 2, and 3. Since SA messages received from a mesh group peer 289 are not forwarded to peers within that same mesh group, SA messages 290 will not loop. In particular, do not create topologies which connect 291 mesh-groups in a loop. In the above example for instance, "second 292 tier" mesh-groups 1, 2, and 3 must not directly exchange SA message. 294 7.2. MSDP and Route Reflectors 296 BGP requires all iBGP speakers that are not route-reflector clients 297 or confederation members be fully meshed. This requirement does not 298 scale when there are large number of iBGP speakers. In the route- 299 reflector environment, MSDP requires that the route reflector clients 300 peer with the route reflector. For example, consider the following 301 case: 303 Ra--------RR 304 /|\ 305 / | \ 306 A B C 308 Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, 309 and C also MSDP peer with RR. When RR forwards the SA to A, B, and C, 310 these RR clients will accept the SA because RR is the iBGP next hop 311 for the originating RP address. 313 An SA will peer-RPF fail if Ra MSDP peers directly with Routers A, B, 314 and C because the iBGP next hop for RR's clients is RR, but the SA 315 update came from Ra. Proper deployment is to have RR's clients MSDP 316 peer with RR. 318 7.3. MSDP Filtering 320 Typically there is a fair amount of (S,G) state in a PIM-SM domain 321 that is local to the domain. However, without proper filtering, SA- 322 messages containing these local (S,G) announcements may be advertised 323 to the global MSDP infrastructure. Examples of this includes domain 324 local applications that use global IP multicast addresses and sources 325 that use RFC 1918 addresses [RFC1918]. To improve on the scalability 326 of MSDP and to avoid global visibility of domain local (S,G) 327 information, the following external SA filter list is recommended to 328 help prevent unnecessary creation, forwarding, and caching of some of 329 these well-known �domain local� sources [IANA]. 331 224.0.0.0/4 Local application packets 332 (packets from any application which are intended to stay 333 adminstratively scoped, but use global addressing. The 334 current list of applications which could be filtered 335 is dynamic and subject to individual policy. See WG 336 mail group for latest recommendations) 337 224.0.1.39 AutoRP Announce 338 224.0.1.40 AutoRP Discovery 339 239.0.0.0/8 Admin. Scoped 340 10.0.0.0/8 private addresses [RFC1918] 341 127.0.0.0/8 private addresses [RFC1918] 342 172.16.0.0/12 private addresses [RFC1918] 343 192.168.0.0/16 private addresses [RFC1918] 344 232.0.0.0/8 Default SSM-range 346 8. Author's Addresses 348 Mike McBride 349 Cisco Systems 350 mcbride@cisco.com 352 John Meylor 353 Cisco Systems 354 jmeylor@cisco.com 356 David Meyer 357 Sprint 358 Email: dmm@sprint.net 360 9. REFERENCES 362 [ANYCAST-RP] D. Meyer et. al, "Anycast RP mechanism using PIM and 363 MSDP", draft-ietf-mboned-anycast-rp-08.txt, May, 2001. 365 [NICKLESS] Bill Nickless, "IPv4 Multicast Best Current Practice", 366 draft-nickless-ipv4-mcast-bcp-01.txt, February 2002. 368 [IANA] http://www.iana.org 370 [MSDP] D. Meyer and Bill Fenner (Editors), "The Multicast 371 Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-13.txt, 372 November 2001. 374 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 375 (BGP-4)", RFC 1771, March 1995. 377 [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, 378 "Address Allocation for Private Internets", 02/29/1996. 380 [RFC2117] D. Estrin et. al, "Protocol Independent Multicast-Sparse 381 Mode (PIM-SM): Protocol Specification", RFC 2117, 382 June, 1997. 384 [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast - 385 Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, 386 June, 1998. 388 [RFC2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, "Multiprotocol 389 Extensions for BGP-4", RFC 2858, June 2000. 391 10. Full Copyright Statement 393 Copyright (C) The Internet Society (2002). All Rights Reserved. 395 This document and translations of it may be copied and furnished to 396 others, and derivative works that comment on or otherwise explain it 397 or assist in its implementation may be prepared, copied, published 398 and distributed, in whole or in part, without restriction of any 399 kind, provided that the above copyright notice and this paragraph are 400 included on all such copies and derivative works. However, this 401 document itself may not be modified in any way, such as by removing 402 the copyright notice or references to the Internet Society or other 403 Internet organizations, except as needed for the purpose of develop- 404 ing Internet standards in which case the procedures for copyrights 405 defined in the Internet Standards process must be followed, or as 406 required to translate it into languages other than English. 408 The limited permissions granted above are perpetual and will not be 409 revoked by the Internet Society or its successors or assigns. 411 This document and the information contained herein is provided on an 412 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 413 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 414 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 415 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 416 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.