idnits 2.17.1 draft-ietf-mboned-msdp-deploy-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 714. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 666), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (March 2004) is 7337 days in the past. Is this intentional? 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: 'RFC2026' is mentioned on line 192, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 200, but not defined == Unused Reference: 'RFC2119' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC2365' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC3330' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 645, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-09 ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Downref: Normative reference to an Informational RFC: RFC 3446 ** Downref: Normative reference to an Experimental RFC: RFC 3618 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-08 -- Duplicate reference: draft-ietf-pim-sm-v2-new, mentioned in 'AUTORP', was also mentioned in 'PIM-SM'. == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-03 Summary: 15 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. McBride 3 J. Meylor 4 D. Meyer 5 Category Best Current Practice 6 Expires: September 2004 March 2004 8 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios 9 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This document is a product of the MBONED Working Group. Comments 33 should be addressed to the authors, or the mailing list at 34 mboned@lists.uoregon.edu. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes best current practices for intra-domain and 43 inter-domain deployment of the Multicast Source Discovery Protocol 44 (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode 45 (PIM-SM). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. BCP, Experimental Protocols and Normative References. . . . 5 51 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 6 52 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 7 53 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 8 54 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 9 55 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 10 56 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 10 57 3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 10 58 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 11 59 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 12 60 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 13 61 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 14 62 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 14 63 4.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 15 64 4.2. SA message state limits . . . . . . . . . . . . . . . . . . 15 65 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15 66 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 17 69 7.2. Informative References. . . . . . . . . . . . . . . . . . . 18 70 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 18 71 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 72 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 19 73 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 75 1. Introduction 77 MSDP [RFC3618] is used primarily in two deployment scenarios: 79 o Between PIM Domains 81 MSDP can be used between Protocol Independent Multicast Sparse 82 Mode (PIM-SM) [PIM-SM] domains to convey information 83 about active sources available in other domains. MSDP peering 84 used in such cases is generally one to one peering, and 85 utilizes the deterministic peer-RPF (Reverse Path Forwarding) 86 rules described in the MSDP specification (i.e., does not use 87 mesh-groups). Peerings can be aggregated on a single MSDP 88 peer. Such a peer can typically have from one to hundreds of 89 peerings, which is similar in scale to BGP peerings. 91 o Within a PIM Domain 93 MSDP is often used between Anycast Rendezvous Points 94 (Anycast-RPs) [RFC3446] within a PIM domain to synchronize 95 information about the active sources being served by each 96 Anycast-RP peer (by virtue of IGP reachability). MSDP peering 97 used in this scenario is typically based on MSDP mesh groups, 98 where anywhere from two to tens of peers can comprise a given 99 mesh group, although more than ten is not typical. One or more 100 of these mesh-group peers may then also have additional 101 one-to-one peering with MSDP peers outside that PIM domain for 102 discovery of external sources. MSDP for anycast-RP without 103 external MSDP peering is a valid deployment option and common. 105 Current best practice for MSDP deployment utilizes PIM-SM and the 106 Border Gateway Protocol with multi-protocol extensions (MBGP) 107 [RFC1771, RFC2858]. This document outlines how these protocols work 108 together to provide an intra-domain and inter-domain Any Source 109 Multicast (ASM) service. 111 The PIM-SM specification assumes that SM operates only in one PIM 112 domain. MSDP is used to enable the use of multiple PIM domains by 113 distributing the required information about active multicast sources 114 to other PIM domains. Due to breaking the Internet multicast 115 infrastructure down to multiple PIM domains, MSDP also enables the 116 possibility to set policy on the visibility of the groups and 117 sources. 119 Transit IP providers typically deploy MSDP to be part of the global 120 multicast infrastructure by connecting to their upstream and peer 121 multicast networks using MSDP. 123 Edge multicast networks typically have two choices: to use their 124 Internet providers RP, or to have their own RP and connect it to 125 their ISP using MSDP. By deploying their own RP and MSDP, one can 126 use internal multicast groups which are not visible to the provider's 127 RP. This helps with internal multicast being able to continue to work 128 in the event there is a problem with connectivity to the provider or 129 the provider's RP/MSDP is experiencing difficulties. In the simplest 130 cases where no internal multicast groups are necessary, there is 131 often no need to deploy MSDP. 133 1.1. BCP, Experimental Protocols and Normative References 135 This document describes the best current practice for a widely 136 deployed Experimental protocol, MSDP. There is no plan to advance the 137 MSDP's status (for example, to Proposed Standard). The reasons for 138 this include: 140 o MSDP was originally envisioned as a temporary protocol to be 141 supplanted by whatever the IDMR working group produced as an 142 inter-domain protocol. However, the IDMR WG (or subsequently, 143 the BGMP WG) never produced a protocol that could be deployed 144 to replace MSDP. 146 o One of the primary reasons given for MSDP to be classified as 147 Experimental was that the MSDP Working Group came up with 148 modifications to the protocol that the WG thought made it 149 better but that implementors didn't see any reasons to 150 deploy. Without these modifications (e.g., UDP or GRE 151 encapsulation), MSDP can have negative consequences to initial 152 packets in datagram streams. 154 o Scalability: Although we don't know what the hard limits might 155 be, readvertising everything you know every 60 seconds clearly 156 limits the amount of state you can advertise. 158 o MSDP reached near ubiquitous deployment as the de-facto 159 standard inter-domain multicast protocol in the IPv4 Internet. 161 o No consensus could be reached regarding the reworking of MSDP 162 to address the many concerns of various constituencies within 163 the IETF. As a result, a decision was taken to document what is 164 (ubiquitously) deployed and move that document to Experimental. 165 While advancement of MSDP to Proposed Standard was considered, 166 for the reasons mentioned above, it was immediately discarded. 168 o The advent of protocols such as source specific multicast and 169 bi-directional PIM, as well as embedded RP techniques for 170 IPv6, have further reduced consensus that a replacement 171 protocol for MSDP for the IPv4 Internet is required. 173 The RFC Editor's policy regarding references is that they be split 174 into two categories known as "normative" and "informative". Normative 175 references specify those documents which must be read to understand 176 or implement the technology in an RFC (or whose technology must be 177 present for the technology in the new RFC to work) [RFCED]. In order 178 to understand this document, one must also understand both the PIM 179 and MSDP documents. As a result, references to these documents are 180 normative. 182 The IETF has adopted the policy that BCPs must not have normative 183 references to Experimental protocols. However, this document is a 184 special case in that the underlying Experimental document (MSDP) is 185 not planned to be advanced to Proposed Standard. 187 The MBONED Working Group requests approval under the Variance 188 Procedure as documented in RFC 2026 [RFC2026]. 190 Note to RFC-Editor: If IETF/IESG approves this, please change the 191 above sentence into: The MBONED Working Group has requested approval 192 under the Variance Procedure as documented in RFC 2026 [RFC2026]. 193 The IESG followed the Variance Procedure, and after an additional 4 194 week IETF Last Call evaluated the comments and status and has 195 approved this document. 197 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in RFC 2119 [RFC 2119]. 201 2. Inter-domain MSDP Peering Scenarios 203 The following sections describe the most common inter-domain MSDP 204 peering possibilities and their deployment options. 206 2.1. Peering between PIM Border Routers 208 In this case, the MSDP peers within the domain have their own RP 209 located within a bounded PIM domain. In addition, the domain will 210 typically have its own Autonomous System (AS) number and one or more 211 MBGP speakers. The domain may also have multiple MSDP speakers. Each 212 border router has an MSDP and MBGP peering with its peer routers. 213 These external MSDP peering deployments typically configure the MBGP 214 peering and MSDP peering using the same directly connected next hop 215 peer IP address or other IP address from the same router. Typical 216 deployments of this type are providers who have a direct peering with 217 other providers, providers peering at an exchange, or providers who 218 use their edge router to MSDP/MBGP peer with customers. 220 For a direct peering inter-domain environment to be successful, the 221 first AS in the MBGP best path to the originating RP should be the 222 same as the AS of the MSDP peer. As an example, consider the 223 following topology: 225 AS1----AS2----AS4 226 | / 227 | / 228 | / 229 AS3 231 In this case, AS4 receives a Source Active (SA) message, originated 232 by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP 233 first hop AS from AS4, in the best path to the originating RP, is 234 AS2. The AS of the sending MSDP peer is also AS2. In this case, the 235 peer-Reverse Path Forwarding check (peer-RPF check) passes and the SA 236 message is forwarded. 238 A peer-RPF failure would occur in this topology when the MBGP first 239 hop AS, in the best path to the originating RP, is AS2 while the 240 origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS 241 PATH information prevents endless looping of SA packets. 243 Router code, which has adopted the latest rules in the MSDP draft, 244 will relax the rules Between AS's a bit. In the following topology we 245 have an MSDP peering between AS1<->AS3 and AS3<->AS4: 247 RP 248 AS1----AS2----AS3----AS4 250 If the first AS in best path to the RP does not equal the MSDP peer, 251 MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3 since AS2 is 252 the first AS in the MBGP best path to AS4 RP. With the latest MSDP 253 draft compliant code, AS 1 will choose the peer in the closest AS 254 along best AS path to the RP. AS1 will then accept SA's coming from 255 AS3. If there are multiple MSDP peers to routers within the same AS, 256 the peer with the highest IP address is chosen as the RPF peer. 258 2.2. Peering between Non-Border Routers 260 When MSDP peering between border routers, intra-domain MSDP 261 scalability is restricted because it is necessary to also maintain 262 MBGP and MSDP peerings internally towards their border routers. 263 Within the intra-domain, the border router becomes the announcer of 264 the next hop towards the originating RP. This requires that all 265 intra-domain MSDP peerings must mirror the MBGP path back towards the 266 border router. External MSDP (eMSDP) peerings rely upon AS path for 267 peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the 268 announcer of the next hop. 270 While the eMBGP peer is typically directly connected between border 271 routers, it is common for the eMSDP peer to be located deeper into 272 the transit providers AS. Providers, which desire more flexibility in 273 MSDP peering placement, commonly choose a few dedicated routers 274 within their core network for the inter-domain MSDP peerings to their 275 customers. These core MSDP routers will also typically be in the 276 providers intra-domain MSDP mesh group and configured for Anycast RP. 277 All multicast routers in the providers AS should statically point to 278 the Anycast RP address. Static RP assignment is the most commonly 279 used method for group to RP mapping due to its deterministic nature. 280 Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP 281 mapping mechanisms could be also used to disseminate RP information 282 within the provider's network 284 For an SA message to be accepted in this (multi-hop peering) 285 environment, we rely upon the next (or closest, with latest MSDP 286 spec) AS in the best path towards originating RP for the RPF check. 287 The MSDP peer address should be in the same AS as the AS of the 288 border router's MBGP peer. The MSDP peer address should be advertised 289 via MBGP. 291 For example, using the diagram below, if customer R1 router is MBGP 292 peering with R2 router and if R1 is MSDP peering with R3 router, then 293 R2 and R3 must be in the same AS (or appear, to AS1, to be from the 294 same AS in the event private AS numbers are deployed). The MSDP peer 295 with the highest IP address will be chosen as the MSDP RPF peer. R1 296 must also have the MSDP peer address of R3 in its MBGP table. 298 +--+ +--+ +--+ 299 |R1|----|R2|----|R3| 300 +--+ +--+ +--+ 301 AS1 AS2 AS2 303 From R3's perspective, AS1 (R1) is the MBGP next AS in the best path 304 towards the originating RP. As long as AS1 is the next AS (or 305 closest) in the best path towards the originating RP, RPF will 306 succeed on SAs arriving from R1. 308 In contrast, with the single hop scenario, with R2 (instead of R3) 309 border MSDP peering with R1 border, R2's MBGP address becomes the 310 announcer of the next hop for R3, towards the originating RP, and R3 311 must peer with that R2 address. And all AS2 intra-domain MSDP peers 312 need to follow iMBGP (or other IGP) peerings towards R2 since iMSDP 313 has a dependence upon peering with the address of the MBGP (or other 314 IGP) announcer of the next hop. 316 2.3. MSDP Peering without BGP 318 In this case, an enterprise maintains its own RP and has an MSDP 319 peering with their service provider, but does not BGP peer with them. 320 MSDP relies upon BGP path information to learn the MSDP topology for 321 the SA peer-RPF check. MSDP can be deployed without BGP, however, and 322 as a result there are some special cases where the requirement to 323 perform an peer-RPF check on the BGP path information is suspended. 324 These cases are: 326 o There is only a single MSDP peer connection 328 o A default peer (default MSDP route) is configured 330 o The originating RP is directly connected 332 o A mesh group is used 334 o An implementation is used which allows for an MSDP peer-RPF 335 check using an IGP 337 These cases are when there is only a single MSDP peer connection, a 338 default peer (default MSDP route) is configured, the originating RP 339 is directly connected, a mesh group is used, or an implementation is 340 used which allows for an MSDP peer-RPF check using an IGP. 342 An enterprise will typically configure a unicast default route from 343 their border router to the provider's border router and then MSDP 344 peer with the provider's MSDP router. If internal MSDP peerings are 345 also used within the enterprise, then an MSDP default peer will need 346 to be configured on the border router pointing to the provider. In 347 this way, all external multicast sources will be learned and internal 348 sources can be advertised. If only a single MSDP peering was used (no 349 internal MSDP peerings) towards the provider, then this stub site 350 will MSDP default peer towards the provider and skip the peer-RPF 351 check. 353 2.4. MSDP Peering at a Multicast Exchange 355 Multicast exchanges allow multicast providers to peer at a common IP 356 subnet (or by using point to point virtual LANs) and share MSDP SA 357 updates. Each provider will MSDP and MBGP peer with each others 358 directly connected exchange IP address. Each exchange router will 359 send/receive SAs to/from their MSDP peers. They will then be able to 360 forward SAs throughout their domain to their customers and any direct 361 provider peerings. 363 3. Intra-domain MSDP Peering Scenarios 365 The following sections describe the different intra-domain MSDP 366 peering possibilities and their deployment options. 368 3.1. Peering between MSDP and MBGP Configured Routers 370 The next hop IP address of the iBGP peer is typically used for the 371 MSDP peer-RPF check (IGP can also be used). This is different from 372 the inter-domain BGP/MSDP case, where AS path information is used for 373 the peer-RPF check. For this reason, it is necessary for the IP 374 address of the MSDP peer connection be the same as the internal MBGP 375 peer connection whether or not the MSDP/MBGP peers are directly 376 connected. A successful deployment would be similar to the following: 378 +----+ 379 | Rb | 3.3.3.3 380 / +----+ 381 AS1 AS2 / | 382 +---+ +--+ / | 383 |RP1|---------|Ra| | 384 +---+ +--+ | 385 1.1.1.1 2.2.2.2 | 386 \ | 387 \ | 388 \ +-----+ 389 | RP2 | 390 +-----+ 392 Where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb 393 (using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the 394 MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update 395 from MSDP peer 2.2.2.2 which is also the correct MBGP next hop for 396 1.1.1.1. 398 When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP 399 lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly 400 fails, preventing a loop. 402 This deployment could also fail on an update from Ra to RP2 if RP2 403 was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain 404 deployments must have MSDP and MBGP (or other IGP) peering addresses 405 which match, unless a method to skip the peer-RPF check is deployed. 407 3.2. MSDP Peer is not BGP Peer (or no BGP Peer) 409 This is a common MSDP intra-domain deployment in environments where 410 few routers are running MBGP or where the domain is not running MBGP. 411 The problem here is that the MSDP peer address needs to be the same 412 as the MBGP peer address. To get around this requirement, the intra- 413 domain MSDP RPF rules have been relaxed in the following topologies: 415 o By configuring the MSDP peer as a mesh group peer 417 o By having the MSDP peer be the only MSDP peer 419 o By configuring a default MSDP peer 420 o By peering with the originating RP. 422 o By relying upon an IGP for MSDP peer-RPF 424 The common choice around the intra-domain BGP peering requirement, 425 when more than one MSDP peer is configured, is to deploy MSDP mesh 426 groups. When a MSDP mesh group is deployed, there is no RPF check on 427 arriving SA messages when received from a mesh group peer. 428 Subsequently, SA messages are always accepted from mesh group peers. 429 MSDP mesh groups were developed to reduce the amount of SA traffic in 430 the network since SAs, which arrive from a mesh group peer, are not 431 flooded to peers within that same mesh group. Mesh groups must be 432 fully meshed. 434 If recent (but not currently widely deployed) router code is running 435 which is fully complaint with the latest MSDP draft, another option, 436 to work around not having BGP to MSDP RPF peer, is to RPF using an 437 IGP like OSPF, IS-IS, RIP, etc. This new capability will allow for 438 enterprise customers, who are not running BGP and who don't want to 439 run mesh groups, to use their existing IGP to satisfy the MSDP peer- 440 RPF rules. 442 3.3. Hierarchical Mesh Groups 444 Hierarchal Mesh Groups are occasionally deployed in intra-domain 445 environments where there are a large number of MSDP peers. Allowing 446 multiple mesh groups to forward to one another can reduce the number 447 of MSDP peerings per router (due to the full mesh requirement) and 448 hence reduce router load. A good hierarchical mesh group 449 implementation (one which prevents looping) contains a core mesh 450 group in the backbone and these core routers serve as mesh group 451 aggregation routers: 453 [R2]{A,2} 454 / \ 455 / \ 456 / \ 457 / \ 458 / \ 459 / \ 460 / \ 461 {A,1}[R1]-------------[R3]{A,3} 463 In this example, R1, R2, R3 are in MSDP mesh group A (the core mesh 464 group) and each serves as MSDP aggregation routers for their leaf (or 465 second tier) mesh groups 1, 2, and 3. Since SA messages received from 466 a mesh group peer are not forwarded to peers within that same mesh 467 group, SA messages will not loop. Do not create topologies which 468 connect mesh-groups in a loop. In the above example for instance, 469 second tier mesh-groups 1, 2, and 3 must not directly exchange SA 470 messages with each other or an endless SA loop will occur. 472 Redundancy, between mesh groups, will also cause a loop and is 473 subsequently not available with Hierarchical mesh groups. For 474 instance, assume R3 had two routers connecting its leaf mesh group 3 475 with the core mesh group A. A loop would be created between mesh 476 group 3 and mesh group A because each mesh group must be fully meshed 477 between peers. 479 3.4. MSDP and Route Reflectors 481 BGP requires all iBGP speakers, that are not route-reflector clients 482 or confederation members, be fully meshed to prevent loops. In the 483 route reflector environment, MSDP requires that the route reflector 484 clients peer with the route reflector since the router reflector (RR) 485 is the BGP announcer of the next hop towards the originating RP. The 486 RR is not the BGP next hop, but is the announcer of the BGP next hop. 487 The announcer of the next hop is the address typically used for MSDP 488 peer-RPF checks. For example, consider the following case: 490 Ra--------RR 491 /|\ 492 / | \ 493 A B C 495 Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, 496 and C also MSDP peer with RR. When RR forwards the SA to A, B, and C, 497 these RR clients will accept the SA because RR is the announcer of 498 the next hop to the originating RP address. 500 An SA will peer-RPF fail, if Ra MSDP peers directly with Routers A, 501 B, or C, because the announcer of the next hop is RR, but the SA 502 update came from Ra. Proper deployment is to have RR clients MSDP 503 peer with the RR. MSDP mesh groups may be used to work around this 504 requirement. External MSDP peerings will also prevent this 505 requirement since the next AS is compared between MBGP and MSDP 506 peerings, rather than the IP address of the announcer of the next 507 hop. 509 Some recent MSDP implementations conform to the latest MSDP draft 510 which relaxes the requirement of peering with the Advertiser of the 511 Next Hop (the Route Reflector). This new rule allows for peering with 512 the Next-Hop, in addition to the Advertiser of the next hop. In the 513 example above, for instance, if Ra is the Next-Hop (perhaps due to 514 using BGP's Next hop self attribute) and if routers A,B,C are peering 515 with Ra, the SA's received from Ra will now succeed. 517 3.5. MSDP and Anycast RPs 519 A network, with multiple RPs, can achieve RP load sharing and 520 redundancy by using the Anycast RP mechanism in conjunction with MSDP 521 mesh groups [RFC3446]. This mechanism is a common deployment 522 technique used within a domain by service providers and enterprises 523 which deploy several RPs within their domain. These RPs will each 524 have the same IP address configured on a Loopback interface (making 525 this the Anycast address). These RPs will MSDP peer with each other 526 using a separate loopback interface and are part of the same fully 527 meshed MSDP mesh group. This loopback interface, used for MSDP 528 peering, will typically also be used for the MBGP peering. All 529 routers within the provider's domain will learn of the Anycast RP 530 address either through Auto-RP, BSR, or a static RP assignment. Each 531 designated router in the domain will send source registers and group 532 joins to the Anycast RP address. Unicast routing will direct those 533 registers and joins to the nearest Anycast RP. If a particular 534 Anycast RP router fails, unicast routing will direct subsequent 535 registers and joins to the nearest Anycast RP. That RP will then 536 forward an MSDP update to all peers within the Anycast MSDP mesh 537 group. Each RP will then forward (or receive) the SAs to (from) 538 external customers and providers. 540 4. Security Considerations 542 An MSDP service should be secured by explicitly controlling the state 543 which is created by, and passed within, the MSDP service. As with 544 unicast routing state, MSDP state should be controlled locally, at 545 the edge origination points. Selective filtering at the multicast 546 service edge helps ensure that only intended sources result in SA 547 message creation, and this control helps to reduce the likelihood of 548 state-aggregation related problems in the core. There are a variety 549 of points where local policy should be applied to the MSDP service. 551 4.1. Filtering SA messages 553 The process of originating SA messages should be filtered to ensure 554 only intended local sources are resulting in SA message origination. 555 In addition, MSDP speakers should filter on which SA messages get 556 received and forwarded. 558 Typically there is a fair amount of (S,G) state in a PIM-SM domain 559 that is local to the domain. However, without proper filtering, sa- 560 messages containing these local (S,G) announcements may be advertised 561 to the global MSDP infrastructure. Examples of this includes domain 562 local applications that use global IP multicast addresses and sources 563 that use RFC 1918 addresses [RFC1918]. To improve on the scalability 564 of MSDP and to avoid global visibility of domain local (S,G) 565 information, an external SA filter list is recommended to help 566 prevent unnecessary creation, forwarding, and caching of well-known 567 domain local sources. 569 4.2. SA message state limits 571 Proper filtering on SA message origination, receipt, and forwarding 572 will significantly reduce the likelihood of unintended and unexpected 573 spikes in MSDP state However, a sa-cache state limit SHOULD be 574 configured as a final safeguard to state spikes. When an MSDP peering 575 has reached a stable state (i.e., when the peering has been 576 established and the initial SA state has been transferred), it may 577 also be desirable to configure a rate limiter for the creation of new 578 SA state entries. 580 5. IANA Considerations 582 This document creates no new requirements on IANA namespaces 583 [RFC2434]. 585 6. Acknowledgments 587 The authors would like to thank Pekka Savola, John Zwiebel, Swapna 588 Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier 589 versions of this document. 591 7. References 593 7.1. Normative References 595 [PIM-SM] Fenner, B., et. al, "Protocol Independent Multicast - 596 Sparse Mode (PIM-SM): Protocol Specification 597 (Revised)", draft-ietf-pim-sm-v2-new-09.txt. Work 598 in progress. 600 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway 601 Protocol 4 (BGP-4)", RFC 1771, March 1995. 603 [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de 604 Groot, E. Lear, "Address Allocation for Private 605 Internets", RFC 1918, Feburary, 1996. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to 608 Indicate Requirement Levels" RFC 2119/BCP 14, 609 March 1997. 611 [RFC2365] Meyer, D. "Administratively Scoped IP Multicast", 612 RFC 2365, July, 1998. 614 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 615 Writing an IANA Considerations Section in 616 RFCs", RFC 2434/BCP 0026, October, 1998. 618 [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, 619 "Multiprotocol Extensions for BGP-4", RFC 2858, 620 June 2000. 622 [RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330, 623 September 2002. 625 [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) 626 Mechanism using Protocol Independent Multicast 627 (PIM) and Multicast Source Discovery Protocol 628 (MSDP)", RFC 3446, January, 2003. 630 [RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast 631 Source Discovery Protocol (MSDP)", RFC 3618, 632 October, 2003. 634 7.2. Informative References 636 [AUTORP] Fenner, W., et. al., " Protocol Independent 637 Multicast - Sparse Mode (PIM-SM): Protocol 638 Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt, 639 April, 2004. Work in progress. 641 [BSR] Fenner, W., et. al., "Bootstrap Router (BSR) 642 Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, 643 February, 2003. Work in progress. 645 [IANA] http://www.iana.org 647 [RFCED] http://www.rfc-editor.org/policy.html#policy.refs 649 8. Author's Addresses 651 Mike McBride 652 Cisco Systems 653 Email: mcbride@cisco.com 655 John Meylor 656 Cisco Systems 657 Email: jmeylor@cisco.com 659 David Meyer 660 Email: dmm@1-4-5.net 662 9. Full Copyright Statement 664 Copyright (C) The Internet Society (2004). This document is subject 665 to the rights, licenses and restrictions contained in BCP 78 and 666 except as set forth therein, the authors retain all their rights. 668 This document and translations of it may be copied and furnished to 669 others, and derivative works that comment on or otherwise explain it 670 or assist in its implementation may be prepared, copied, published 671 and distributed, in whole or in part, without restriction of any 672 kind, provided that the above copyright notice and this paragraph are 673 included on all such copies and derivative works. However, this 674 document itself may not be modified in any way, such as by removing 675 the copyright notice or references to the Internet Society or other 676 Internet organizations, except as needed for the purpose of 677 developing Internet standards in which case the procedures for 678 copyrights defined in the Internet Standards process must be 679 followed, or as required to translate it into languages other than 680 English. 682 The limited permissions granted above are perpetual and will not be 683 revoked by the Internet Society or its successors or assigns. 685 This document and the information contained herein is provided on an 686 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 687 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 688 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 689 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 690 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 10. Intellectual Property 694 The IETF takes no position regarding the validity or scope of any 695 Intellectual Property Rights or other rights that might be claimed to 696 pertain to the implementation or use of the technology described in 697 this document or the extent to which any license under such rights 698 might or might not be available; nor does it represent that it has 699 made any independent effort to identify any such rights. Information 700 on the procedures with respect to rights in RFC documents can be 701 found in BCP 78 and BCP 79. 703 Copies of IPR disclosures made to the IETF Secretariat and any 704 assurances of licenses to be made available, or the result of an 705 attempt made to obtain a general license or permission for the use of 706 such proprietary rights by implementers or users of this 707 specification can be obtained from the IETF on-line IPR repository at 708 http://www.ietf.org/ipr. 710 The IETF invites any interested party to bring to its attention any 711 copyrights, patents or patent applications, or other proprietary 712 rights that may cover technology that may be required to implement 713 this standard. Please address the information to the IETF at ietf- 714 ipr@ietf.org. 716 11. Acknowledgement 718 Funding for the RFC Editor function is currently provided by the 719 Internet Society.