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