idnits 2.17.1 draft-ietf-mboned-msdp-deploy-03.txt: 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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-msdp-deploy-03', but the file name used is 'draft-ietf-mboned-msdp-deploy-03' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 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). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 2003) is 7591 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: 'RFC 2119' is mentioned on line 34, but not defined == Unused Reference: 'SSM' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC2365' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC3330' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 609, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (ref. 'MSDP') == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-03 ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) ** 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 == Outdated reference: A later version (-03) exists of draft-nickless-ipv4-mcast-unusable-02 -- Possible downref: Normative reference to a draft: ref. 'UNUSABLE' == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-07 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-03 Summary: 9 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mike McBride 2 draft-ietf-msdp-deploy-03.txt John Meylor 3 David Meyer 4 Category Best Current Practice 5 Expires: January 2004 July 2003 7 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios 8 10 Status of this Document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC 2119]. 35 This document is a product of the MBONED Working Group. Comments 36 should be addressed to the authors, or the mailing list at 37 mboned@ns.uoregon.edu. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document describes best current practices for intra-domain and 46 inter-domain deployment of the Multicast Source Discovery Protocol 47 (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode 48 (PIM-SM). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 4 54 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 4 55 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 5 56 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 7 57 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 7 58 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 8 59 3.1. Peering between MSDP and MBGP Configured 60 Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 9 62 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 10 63 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 10 64 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11 65 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 12 66 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 67 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 68 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 13 69 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15 73 8.2. Informative References. . . . . . . . . . . . . . . . . . . 16 74 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16 75 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 MSDP [MSDP] is used primarily in two deployment scenarios: 81 o Between PIM Domains 83 MSDP can be used between Protocol Independent Multicast Sparse 84 Mode (PIM-SM) [RFC2362] domains to convey information 85 about active sources available in other domains. MSDP peering 86 used in such cases is generally one to one peering, and 87 utilizes the deterministic peer-RPF (Reverse Path Forwarding) 88 rules described in the MSDP specification (i.e., does not use 89 mesh-groups). Peerings can be aggregated on a single MSDP 90 peer. Such a peer can typically have from one to hundreds of 91 peerings, which is similar in scale to BGP peerings. 93 o Within a PIM Domain 95 MSDP is often used between Anycast Rendezvous Points 96 (Anycast-RPs) [RFC3446] within a PIM domain to synchronize 97 information about the active sources being served by each 98 Anycast-RP peer (by virtue of IGP reachability). MSDP peering 99 used in this scenario is typically based on MSDP mesh groups, 100 where anywhere from two to tens of peers can comprise a given 101 mesh group, although more than ten is not typical. One or more 102 of these mesh-group peers may then also have additional 103 one-to-one peering with MSDP peers outside that PIM domain for 104 discovery of external sources. MSDP for anycast-RP without 105 external MSDP peering is a valid deployment option and common. 107 Current best practice for MSDP deployment utilizes PIM-SM and the 108 Border Gateway Protocol with multi-protocol extensions (MBGP) 109 [RFC1771, RFC2858]. This document outlines how these protocols work 110 together to provide an intra-domain and inter-domain Any Source 111 Multicast (ASM) service. 113 Multicast (ASM) service. The PIM-SM specification assumes that SM 114 operates only in one PIM domain. MSDP is used to enable the use of 115 multiple PIM domains by distributing the required information about 116 active multicast sources to other PIM domains. Due to breaking the 117 Internet multicast infrastructure down to multiple PIM domains, MSDP 118 also enables the possibility to set policy on the visibility of the 119 groups and sources. 121 Transit IP providers typically deploy MSDP to be part of the global 122 multicast infrastructure by connecting to their upstream and peer 123 multicast networks using MSDP. 125 Edge multicast networks typically have two choices: to use their 126 Internet providers RP, or to have their own RP and connect it to 127 their ISP using MSDP. By deploying their own RP and MSDP, one can 128 use internal multicast groups which are not visible to the provider's 129 RP. This helps with internal multicast being able to continue to work 130 in the event there is a problem with connectivity to the provider or 131 the provider's RP/MSDP is experiencing difficulties. In the simplest 132 cases where no internal multicast groups are necessary, there is 133 often no need to deploy MSDP. 135 2. Inter-domain MSDP Peering Scenarios 137 The following sections describe the most common inter-domain MSDP 138 peering possibilities and their deployment options. 140 2.1. Peering between PIM Border Routers 142 In this case, the MSDP peers within the domain have their own RP 143 located within a bounded PIM domain. In addition, the domain will 144 typically have its own Autonomous System (AS) number and one or more 145 MBGP speakers. The domain may also have multiple MSDP speakers. Each 146 border router has an MSDP and MBGP peering with its peer routers. 147 These external MSDP peering deployments typically configure the MBGP 148 peering and MSDP peering using the same directly connected next hop 149 peer IP address or other IP address from the same router. Typical 150 deployments of this type are providers who have a direct peering with 151 other providers, providers peering at an exchange, or providers who 152 use their edge router to MSDP/MBGP peer with customers. 154 For a direct peering inter-domain environment to be successful, the 155 first AS in the MBGP best path to the originating RP should be the 156 same as the AS of the MSDP peer. As an example, consider the 157 following topology: 159 AS1----AS2----AS4 160 | / 161 | / 162 | / 163 AS3 165 In this case, AS4 receives a Source Active (SA) message, originated 166 by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP 167 first hop AS from AS4, in the best path to the originating RP, is 168 AS2. The AS of the sending MSDP peer is also AS2. In this case, the 169 peer-Reverse Path Forwarding check (peer-RPF check) passes and the SA 170 message is forwarded. 172 A peer-RPF failure would occur in this topology when the MBGP first 173 hop AS, in the best path to the originating RP, is AS2 while the 174 origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS 175 PATH information prevents endless looping of SA packets. 177 Router code, which has adopted the latest rules in the MSDP draft, 178 will relax the rules Between AS's a bit. In the following topology we 179 have an MSDP peering between AS1<->AS3 and AS3<->AS4: 181 RP 182 AS1----AS2----AS3----AS4 184 If the first AS in best path to the RP does not equal the MSDP peer, 185 MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3 since AS2 is 186 the first AS in the MBGP best path to AS4 RP. With the latest MSDP 187 draft compliant code, AS 1 will choose the peer in the closest AS 188 along best AS path to the RP. AS1 will then accept SA's coming from 189 AS3. If there are multiple MSDP peers to routers within the same AS, 190 the peer with the highest IP address is chosen as the RPF peer. 192 2.2. Peering between Non-Border Routers 194 When MSDP peering between border routers, intra-domain MSDP 195 scalability is restricted because it is necessary to also maintain 196 MBGP and MSDP peerings internally towards their border routers. 197 Within the intra-domain, the border router becomes the announcer of 198 the next hop towards the originating RP. This requires that all 199 intra-domain MSDP peerings must mirror the MBGP path back towards the 200 border router. External MSDP (eMSDP) peerings rely upon AS path for 201 peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the 202 announcer of the next hop. 204 While the eMBGP peer is typically directly connected between border 205 routers, it is common for the eMSDP peer to be located deeper into 206 the transit providers AS. Providers, which desire more flexibility in 207 MSDP peering placement, commonly choose a few dedicated routers 208 within their core network for the inter-domain MSDP peerings to their 209 customers. These core MSDP routers will also typically be in the 210 providers intra-domain MSDP mesh group and configured for Anycast RP. 211 All multicast routers in the providers AS should statically point to 212 the Anycast RP address. Static RP assignment is the most commonly 213 used method for group to RP mapping due to its deterministic nature. 214 Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP 215 mapping mechanisms could be also used to disseminate RP information 216 within the provider's network 218 For an SA message to be accepted in this (multi-hop peering) 219 environment, we rely upon the next (or closest, with latest MSDP 220 spec) AS in the best path towards originating RP for the RPF check. 221 The MSDP peer address should be in the same AS as the AS of the 222 border router's MBGP peer. The MSDP peer address should be advertised 223 via MBGP. 225 For example, using the diagram below, if customer R1 router is MBGP 226 peering with R2 router and if R1 is MSDP peering with R3 router, then 227 R2 and R3 must be in the same AS (or appear, to AS1, to be from the 228 same AS in the event private AS numbers are deployed). The MSDP peer 229 with the highest IP address will be chosen as the MSDP RPF peer. R1 230 must also have the MSDP peer address of R3 in its MBGP table. 232 +--+ +--+ +--+ 233 |R1|----|R2|----|R3| 234 +--+ +--+ +--+ 235 AS1 AS2 AS2 237 From R3's perspective, AS1 (R1) is the MBGP next AS in the best path 238 towards the originating RP. As long as AS1 is the next AS (or 239 closest) in the best path towards the originating RP, RPF will 240 succeed on SAs arriving from R1. 242 In contrast, with the single hop scenario, with R2 (instead of R3) 243 border MSDP peering with R1 border, R2's MBGP address becomes the 244 announcer of the next hop for R3, towards the originating RP, and R3 245 must peer with that R2 address. And all AS2 intra-domain MSDP peers 246 need to follow iMBGP (or other IGP) peerings towards R2 since iMSDP 247 has a dependence upon peering with the address of the MBGP (or other 248 IGP) announcer of the next hop. 250 2.3. MSDP Peering without BGP 252 In this case, an enterprise maintains its own RP and has an MSDP 253 peering with their service provider, but does not BGP peer with them. 254 MSDP relies upon BGP path information to learn the MSDP topology for 255 the SA peer-RPF check. MSDP can be deployed without BGP, however, and 256 as a result there are some special cases where the requirement to 257 perform an peer-RPF check on the BGP path information is suspended. 258 These cases are: 260 o There is only a single MSDP peer connection 262 o A default peer (default MSDP route) is configured 264 o The originating RP is directly connected 266 o A mesh group is used 268 o An implementation is used which allows for an MSDP peer-RPF 269 check using an IGP 271 These cases are when there is only a single MSDP peer connection, a 272 default peer (default MSDP route) is configured, the originating RP 273 is directly connected, a mesh group is used, or an implementation is 274 used which allows for an MSDP peer-RPF check using an IGP. 276 An enterprise will typically configure a unicast default route from 277 their border router to the provider's border router and then MSDP 278 peer with the provider's MSDP router. If internal MSDP peerings are 279 also used within the enterprise, then an MSDP default peer will need 280 to be configured on the border router pointing to the provider. In 281 this way, all external multicast sources will be learned and internal 282 sources can be advertised. If only a single MSDP peering was used (no 283 internal MSDP peerings) towards the provider, then this stub site 284 will MSDP default peer towards the provider and skip the peer-RPF 285 check. 287 2.4. MSDP Peering at a Multicast Exchange 289 Multicast exchanges allow multicast providers to peer at a common IP 290 subnet (or by using point to point virtual LANs) and share MSDP SA 291 updates. Each provider will MSDP and MBGP peer with each others 292 directly connected exchange IP address. Each exchange router will 293 send/receive SAs to/from their MSDP peers. They will then be able to 294 forward SAs throughout their domain to their customers and any direct 295 provider peerings. 297 3. Intra-domain MSDP Peering Scenarios 299 The following sections describe the different intra-domain MSDP 300 peering possibilities and their deployment options. 302 3.1. Peering between MSDP and MBGP Configured Routers 304 The next hop IP address of the iBGP peer is typically used for the 305 MSDP peer-RPF check (IGP can also be used). This is different from 306 the inter-domain BGP/MSDP case, where AS path information is used for 307 the peer-RPF check. For this reason, it is necessary for the IP 308 address of the MSDP peer connection be the same as the internal MBGP 309 peer connection whether or not the MSDP/MBGP peers are directly 310 connected. A successful deployment would be similar to the following: 312 +----+ 313 | Rb | 3.3.3.3 314 / +----+ 315 AS1 AS2 / | 316 +---+ +--+ / | 317 |RP1|---------|Ra| | 318 +---+ +--+ | 319 1.1.1.1 2.2.2.2 | 320 \ | 321 \ | 322 \ +-----+ 323 | RP2 | 324 +-----+ 326 Where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb 327 (using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the 328 MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update 329 from MSDP peer 2.2.2.2 which is also the correct MBGP next hop for 330 1.1.1.1. 332 When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP 333 lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly 334 fails, preventing a loop. 336 This deployment could also fail on an update from Ra to RP2 if RP2 337 was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain 338 deployments must have MSDP and MBGP (or other IGP) peering addresses 339 which match, unless a method to skip the peer-RPF check is deployed. 341 3.2. MSDP Peer is not BGP Peer (or no BGP Peer) 343 This is a common MSDP intra-domain deployment in environments where 344 few routers are running MBGP or where the domain is not running MBGP. 345 The problem here is that the MSDP peer address needs to be the same 346 as the MBGP peer address. To get around this requirement, the intra- 347 domain MSDP RPF rules have been relaxed in the following topologies: 349 o By configuring the MSDP peer as a mesh group peer 351 o By having the MSDP peer be the only MSDP peer 353 o By configuring a default MSDP peer 355 o By peering with the originating RP. 357 o By relying upon an IGP for MSDP peer-RPF 359 The common choice around the intra-domain BGP peering requirement, 360 when more than one MSDP peer is configured, is to deploy MSDP mesh 361 groups. When a MSDP mesh group is deployed, there is no RPF check on 362 arriving SA messages when received from a mesh group peer. 363 Subsequently, SA messages are always accepted from mesh group peers. 364 MSDP mesh groups were developed to reduce the amount of SA traffic in 365 the network since SAs, which arrive from a mesh group peer, are not 366 flooded to peers within that same mesh group. Mesh groups must be 367 fully meshed. 369 If recent (but not currently widely deployed) router code is running 370 which is fully complaint with the latest MSDP draft, another option, 371 to work around not having BGP to MSDP RPF peer, is to RPF using an 372 IGP like OSPF, IS-IS, RIP, etc. This new capability will allow for 373 enterprise customers, who are not running BGP and who don't want to 374 run mesh groups, to use their existing IGP to satisfy the MSDP peer- 375 RPF rules. 377 3.3. Hierarchical Mesh Groups 379 Hierarchal Mesh Groups are occasionally deployed in intra-domain 380 environments where there are a large number of MSDP peers. Allowing 381 multiple mesh groups to forward to one another can reduce the number 382 of MSDP peerings per router (due to the full mesh requirement) and 383 hence reduce router load. A good hierarchical mesh group 384 implementation (one which prevents looping) contains a core mesh 385 group in the backbone and these core routers serve as mesh group 386 aggregation routers: 388 [R2]{A,2} 389 / \ 390 / \ 391 / \ 392 / \ 393 / \ 394 / \ 395 / \ 396 {A,1}[R1]-------------[R3]{A,3} 398 In this example, R1, R2, R3 are in MSDP mesh group A (the core mesh 399 group) and each serves as MSDP aggregation routers for their leaf (or 400 second tier) mesh groups 1, 2, and 3. Since SA messages received from 401 a mesh group peer are not forwarded to peers within that same mesh 402 group, SA messages will not loop. Do not create topologies which 403 connect mesh-groups in a loop. In the above example for instance, 404 second tier mesh-groups 1, 2, and 3 must not directly exchange SA 405 messages with each other or an endless SA loop will occur. 407 Redundancy, between mesh groups, will also cause a loop and is 408 subsequently not available with Hierarchical mesh groups. For 409 instance, assume R3 had two routers connecting its leaf mesh group 3 410 with the core mesh group A. A loop would be created between mesh 411 group 3 and mesh group A because each mesh group must be fully meshed 412 between peers. 414 3.4. MSDP and Route Reflectors 416 BGP requires all iBGP speakers, that are not route-reflector clients 417 or confederation members, be fully meshed to prevent loops. In the 418 route reflector environment, MSDP requires that the route reflector 419 clients peer with the route reflector since the router reflector (RR) 420 is the BGP announcer of the next hop towards the originating RP. The 421 RR is not the BGP next hop, but is the announcer of the BGP next hop. 422 The announcer of the next hop is the address typically used for MSDP 423 peer-RPF checks. For example, consider the following case: 425 Ra--------RR 426 /|\ 427 / | \ 428 A B C 430 Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, 431 and C also MSDP peer with RR. When RR forwards the SA to A, B, and C, 432 these RR clients will accept the SA because RR is the announcer of 433 the next hop to the originating RP address. 435 An SA will peer-RPF fail, if Ra MSDP peers directly with Routers A, 436 B, or C, because the announcer of the next hop is RR, but the SA 437 update came from Ra. Proper deployment is to have RR clients MSDP 438 peer with the RR. MSDP mesh groups may be used to work around this 439 requirement. External MSDP peerings will also prevent this 440 requirement since the next AS is compared between MBGP and MSDP 441 peerings, rather than the IP address of the announcer of the next 442 hop. 444 Some recent MSDP implementations conform to the latest MSDP draft 445 which relaxes the requirement of peering with the Advertiser of the 446 Next Hop (the Route Reflector). This new rule allows for peering with 447 the Next-Hop, in addition to the Advertiser of the next hop. In the 448 example above, for instance, if Ra is the Next-Hop (perhaps due to 449 using BGP's Next hop self attribute) and if routers A,B,C are peering 450 with Ra, the SA's received from Ra will now succeed. 452 3.5. MSDP and Anycast RPs 454 A network, with multiple RPs, can achieve RP load sharing and 455 redundancy by using the Anycast RP mechanism in conjunction with MSDP 456 mesh groups [RFC3446]. This mechanism is a common deployment 457 technique used within a domain by service providers and enterprises 458 which deploy several RPs within their domain. These RPs will each 459 have the same IP address configured on a Loopback interface (making 460 this the Anycast address). These RPs will MSDP peer with each other 461 using a separate loopback interface and are part of the same fully 462 meshed MSDP mesh group. This loopback interface, used for MSDP 463 peering, will typically also be used for the MBGP peering. All 464 routers within the provider's domain will learn of the Anycast RP 465 address either through Auto-RP, BSR, or a static RP assignment. Each 466 designated router in the domain will send source registers and group 467 joins to the Anycast RP address. Unicast routing will direct those 468 registers and joins to the nearest Anycast RP. If a particular 469 Anycast RP router fails, unicast routing will direct subsequent 470 registers and joins to the nearest Anycast RP. That RP will then 471 forward an MSDP update to all peers within the Anycast MSDP mesh 472 group. Each RP will then forward (or receive) the SAs to (from) 473 external customers and providers. 475 4. Intellectual Property 477 The IETF takes no position regarding the validity or scope of any 478 intellectual property or other rights that might be claimed to 479 pertain to the implementation or use of the technology described in 480 this document or the extent to which any license under such rights 481 might or might not be available; neither does it represent that it 482 has made any effort to identify any such rights. Information on the 483 IETF's procedures with respect to rights in standards-track and 484 standards-related documentation can be found in BCP-11. Copies of 485 claims of rights made available for publication and any assurances of 486 licenses to be made available, or the result of an attempt made to 487 obtain a general license or permission for the use of such 488 proprietary rights by implementors or users of this specification can 489 be obtained from the IETF Secretariat. 491 The IETF invites any interested party to bring to its attention any 492 copyrights, patents or patent applications, or other proprietary 493 rights which may cover technology that may be required to practice 494 this standard. Please address the information to the IETF Executive 495 Director. 497 5. Acknowledgments 499 The authors would like to thank Pekka Savola, John Zwiebel, Swapna 500 Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier 501 versions of this document. 503 6. Security Considerations 505 An MSDP service should be secured by explicitly controlling the state 506 which is created by, and passed within, the MSDP service. As with 507 unicast routing state, MSDP state should be controlled locally, at 508 the edge origination points. Selective filtering at the multicast 509 service edge helps ensure that only intended sources result in SA 510 message creation, and this control helps to reduce the likelihood of 511 state-aggregation related problems in the core. There are a variety 512 of points where local policy should be applied to the MSDP service. 514 6.1. Filtering SA messages 516 The process of originating SA messages should be filtered to ensure 517 only intended local sources are resulting in SA message origination. 518 In addition, MSDP speakers should filter on which SA messages get 519 received and forwarded. 521 Typically there is a fair amount of (S,G) state in a PIM-SM domain 522 that is local to the domain. However, without proper filtering, sa- 523 messages containing these local (S,G) announcements may be advertised 524 to the global MSDP infrastructure. Examples of this includes domain 525 local applications that use global IP multicast addresses and sources 526 that use RFC 1918 addresses [RFC1918]. To improve on the scalability 527 of MSDP and to avoid global visibility of domain local (S,G) 528 information, an external SA filter list is recommended to help 529 prevent unnecessary creation, forwarding, and caching of well-known 530 domain local sources [UNUSABLE]. 532 6.2. SA message state limits 534 Proper filtering on SA message origination, receipt, and forwarding 535 will significantly reduce the likelihood of unintended and unexpected 536 spikes in MSDP state However, a sa-cache state limit SHOULD BE be 537 configured as a final safeguard to state spikes. When an MSDP peering 538 has reached a stable state (i.e., when the peering has been 539 established and the initial SA state has been transferred), it may 540 also be desirable to configure a rate limiter for the creation of new 541 SA state entries. 543 7. IANA Considerations 545 This document creates a no new requirements on IANA namespaces 546 [RFC2434]. 548 8. References 550 8.1. Normative References 552 [MSDP] Meyer, D. and W. Fenner (Editors), "The Multicast 553 Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-20.txt, 554 May 2003. Work in Progress. 556 [SSM] Holbrook, H., and B. Cain, "Source-Specific 557 Multicast for IP", draft-ietf-ssm-arch-03.txt, 558 May, 2003. Work in Progress. 560 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway 561 Protocol 4 (BGP-4)", RFC 1771, March 1995. 563 [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de 564 Groot, E. Lear, "Address Allocation for Private 565 Internets", RFC 1918, Feburary, 1996. 567 [RFC2119] Bradner, S., "Key words for use in RFCs to 568 Indicate Requirement Levels" RFC 2119/BCP 14, 569 March 1997. 571 [RFC2362] D. Estrin, et. al., "Protocol Independent 572 Multicast - Sparse Mode (PIM-SM): Protocol 573 Specification", RFC 2362, June, 1998. 575 [RFC2365] Meyer, D. "Administratively Scoped IP Multicast", 576 RFC 2365, July, 1998. 578 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 579 Writing an IANA Considerations Section in 580 RFCs", RFC 2434/BCP 0026, October, 1998. 582 [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, 583 "Multiprotocol Extensions for BGP-4", RFC 2858, 584 June 2000. 586 [RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330, 587 September 2002. 589 [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) 590 Mechanism using Protocol Independent Multicast 591 (PIM) and Multicast Source Discovery Protocol 592 (MSDP)", RFC 3446, January, 2003. 594 [UNUSABLE] Nickless, B., "IPv4 Multicast Unusable Group And 595 Source Addresses", draft-nickless-ipv4-mcast-unusable-02.txt, 596 June, 2003. Work in Progress. 598 8.2. Informative References 600 [AUTORP] Fenner, W., et. al., " Protocol Independent 601 Multicast - Sparse Mode (PIM-SM): Protocol 602 Specification (Revised)", draft-ietf-pim-sm-v2-new-07.txt, 603 March, 2003. Work in Progress. 605 [BSR] Fenner, W., et. al., "Bootstrap Router (BSR) 606 Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, 607 February, 2003. Work in Progress. 609 [IANA] http://www.iana.org 611 9. Author's Addresses 613 Mike McBride 614 Cisco Systems 615 Email: mcbride@cisco.com 617 John Meylor 618 Cisco Systems 619 Email: jmeylor@cisco.com 621 David Meyer 622 Email: dmm@1-4-5.net 624 10. Full Copyright Statement 626 Copyright (C) The Internet Society (2003). All Rights Reserved. 628 This document and translations of it may be copied and furnished to 629 others, and derivative works that comment on or otherwise explain it 630 or assist in its implementation may be prepared, copied, published 631 and distributed, in whole or in part, without restriction of any 632 kind, provided that the above copyright notice and this paragraph are 633 included on all such copies and derivative works. However, this 634 document itself may not be modified in any way, such as by removing 635 the copyright notice or references to the Internet Society or other 636 Internet organizations, except as needed for the purpose of 637 developing Internet standards in which case the procedures for 638 copyrights defined in the Internet Standards process must be 639 followed, or as required to translate it into languages other than 640 English. 642 The limited permissions granted above are perpetual and will not be 643 revoked by the Internet Society or its successors or assigns. 645 This document and the information contained herein is provided on an 646 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 647 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 648 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 649 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 650 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.