idnits 2.17.1 draft-ietf-mboned-msdp-deploy-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 52 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 562: '...r, a sa-cache state limit SHOULD BE be...' 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 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 (May 2003) is 7652 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) ** 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 (-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: 10 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mike McBride 2 draft-ietf-mboned-msdp-deploy-02.txt John Meylor 3 David Meyer 4 Category Best Current Practice 5 Expires: November 2003 May 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 This document is a product of an individual. Comments are solicited 32 and should be addressed to the author(s). 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document describes best current practices for intra-domain and 41 inter-domain deployment of the Multicast Source Discovery Protocol 42 (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode 43 (PIM-SM). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Inter-domain MSDP peering scenarios. . . . . . . . . . . . . . 3 49 2.1. Peering between PIM border routers. . . . . . . . . . . . . 4 50 2.2. Peering between non border routers. . . . . . . . . . . . . 5 51 2.3. MSDP peering without BGP. . . . . . . . . . . . . . . . . . 6 52 2.4. MSDP peering at a Multicast Exchange. . . . . . . . . . . . 7 53 3. Intra-domain MSDP peering scenarios. . . . . . . . . . . . . . 7 54 3.1. Peering between MSDP and MBGP configured routers. . . . . . 7 55 3.2. MSDP peer is not BGP peer (or no BGP peer). . . . . . . . . 8 56 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 9 57 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 10 58 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11 59 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 11 60 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 61 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 62 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 12 63 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 14 64 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15 67 8.2. Informative References. . . . . . . . . . . . . . . . . . . 16 68 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16 69 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 MSDP [MSDP] is used primarily in two deployment scenarios: 75 o Between PIM Domains 77 MSDP can be used between Protocol Independent Multicast Sparse 78 Mode (PIM-SM) [RFC2362] domains to convey information 79 about active sources available in other domains. MSDP peering 80 used in such cases is generally one to one peering, and 81 utilizes the deterministic peer-RPF (Reverse Path Forwarding) 82 rules described in the MSDP specification (i.e., does not use 83 mesh-groups). Peerings can be aggregated on a single MSDP 84 peer. Such a peer can typically have from one to hundreds of 85 peerings, which is similar in scale to BGP peerings. 87 o Within a PIM Domain 89 MSDP is often used between Anycast Rendezvous Points 90 (Anycast-RPs) [RFC3446] within a PIM domain to synchronize 91 information about the active sources being served by each 92 Anycast-RP peer (by virtue of IGP reachability). MSDP peering 93 used in this scenario is typically based on MSDP mesh groups, 94 where anywhere from two to tens of peers can comprise a given 95 mesh group, although more than ten is not typical. One or more 96 of these mesh-group peers may then also have additional 97 one-to-one peering with MSDP peers outside that PIM domain for 98 discovery of external sources. MSDP for anycast-RP without 99 external MSDP peering is a valid deployment option and common. 101 Current best practice for MSDP deployment utilizes PIM-SM and the 102 Border Gateway Protocol with multi-protocol extensions (MBGP) 103 [RFC1771, RFC2858]. This document outlines how these protocols work 104 together to provide an intra-domain and inter-domain Any Source 105 Multicast (ASM) service. 107 2. Inter-domain MSDP peering scenarios 109 The following sections describe the most common inter-domain MSDP 110 peering possibilities and their deployment options. 112 2.1. Peering between PIM border routers 114 In this case, the MSDP peers within the domain have their own RP 115 located within a bounded PIM domain. In addition, the domain will 116 typically have its own Autonomous System (AS) number and one or more 117 MBGP speakers. The domain may also have multiple MSDP speakers. Each 118 border router has an MSDP and MBGP peering with its peer routers. 119 These external MSDP peering deployments typically configure the MBGP 120 peering and MSDP peering using the same directly connected next hop 121 peer IP address or other IP address from the same router. Typical 122 deployments of this type are providers who have a direct peering with 123 other providers, providers peering at an exchange, or providers who 124 use their edge router to MSDP/MBGP peer with customers. 126 For a direct peering inter-domain environment to be successful, the 127 first AS in the MBGP best path to the originating RP should be the 128 same as the AS of the MSDP peer. As an example, consider the 129 following topology: 131 AS1----AS2----AS4 132 | / 133 | / 134 | / 135 AS3 137 In this case, AS4 receives a Source Active (SA) message, originated 138 by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP 139 first hop AS from AS4, in the best path to the originating RP, is 140 AS2. The origin AS of the sending MSDP peer is also AS2. In this 141 case, the peer-Reverse Path Forwarding check (peer-RPF check) passes 142 and the SA message is forwarded. 144 A peer-RPF failure would occur in this topology when the MBGP first 145 hop AS, in the best path to the originating RP, is AS2 while the 146 origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS 147 PATH information prevents endless looping of SA packets. 149 Router code, which has adopted the latest rules in the MSDP draft, 150 will relax the rules Between AS's a bit. In the following topology we 151 have an MSDP peering between AS1<->AS3 and AS3<->AS4: 153 RP 154 AS1----AS2----AS3----AS4 156 If the first AS in best path to the RP does not equal the MSDP peer, 157 MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3 since AS2 is 158 the first AS in the MBGP best path to AS4 RP. With the latest MSDP 159 draft compliant code, AS 1 will choose the peer in the closest AS 160 along best AS path to the RP. AS1 will then accept SA's coming from 161 AS3. If there are multiple MSDP peers to routers within the same AS, 162 the peer with the highest IP address is chosen as the RPF peer. 164 2.2. Peering between non border routers 166 When MSDP peering between border routers, intra-domain MSDP 167 scalability is restricted because it is necessary to also maintain 168 MBGP and MSDP peerings internally towards their border routers. 169 Within the intra-domain, the border router becomes the announcer of 170 the next hop towards the originating RP. This requires that all 171 intra-domain MSDP peerings must mirror the MBGP path back towards the 172 border router. External MSDP (eMSDP) peerings rely upon AS path for 173 peer rpf checking, while internal MSDP (iMSDP) peerings rely upon the 174 announcer of the next hop. 176 While the eMBGP peer is typically directly connected between border 177 routers, it is common for the eMSDP peer to be located deeper into 178 the transit providers AS. Providers, which desire more flexibility in 179 MSDP peering placement, commonly choose a few dedicated routers 180 within their core network for the inter-domain MSDP peerings to their 181 customers. These core MSDP routers will also typically be in the 182 providers intra-domain MSDP mesh group and configured for Anycast RP. 183 All multicast routers in the providers AS should statically point to 184 the Anycast RP address. Static RP assignment is the most commonly 185 used method for group to RP mapping due to its deterministic nature. 186 Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP 187 mapping mechanisms could be also used to disseminate RP information 188 within the provider's network 190 For an SA message to be accepted in this (multi-hop peering) 191 environment, we rely upon the next (or closest, with latest MSDP 192 spec) AS in the best path towards originating RP for the rpf check. 193 The MSDP peer address should be in the same AS as the AS of the 194 border routers MBGP peer. The MSDP peer address should be advertised 195 via MBGP. 197 For example, using the diagram below, if customer R1 router is MBGP 198 peering with R2 router and if R1 is MSDP peering with R3 router, then 199 R2 and R3 must be in the same AS. The MSDP peer with the highest IP 200 address will be chosen as the MSDP RPF peer. R1 must also have the 201 MSDP peer address of R3 in its MBGP table. 203 +--+ +--+ +--+ 204 |R1|----|R2|----|R3| 205 +--+ +--+ +--+ 206 AS1 AS2 AS2 208 From R3's perspective, AS1 (R1) is the MBGP next AS in the best path 209 towards the originating RP. As long as AS1 is the next AS (or 210 closest) in the best path towards the originating RP, RPF will 211 succeed on SAs arriving from R1. 213 In contrast, with the single hop scenario, with R2 (instead of R3) 214 border MSDP peering with R1 border, R2s MBGP address becomes the 215 announcer of the next hop for R3, towards the originating RP, and R3 216 must peer with that R2 address. And all AS2 intra-domain MSDP peers 217 need to follow iMBGP (or other IGP) peerings towards R2 since iMSDP 218 has a dependence upon peering with the address of the MBGP (or other 219 IGP) announcer of the next hop. 221 2.3. MSDP peering without BGP 223 In this case, an enterprise maintains its own RP and has an MSDP 224 peering with their service provider, but does not BGP peer with them. 225 MSDP relies upon BGP path information to learn the MSDP topology for 226 the SA peer-RPF check. MSDP can be deployed without BGP, however, and 227 as a result there are some special cases where the requirement to 228 perform an peer-RPF check on the BGP path information is suspended. 229 These cases are when there is only a single MSDP peer connection, a 230 default peer (default MSDP route) is configured, the originating RP 231 is directly connected, a mesh group is used, or an implementation is 232 used which allows for an MSDP peer-RPF check using an IGP. 234 An enterprise will typically configure a unicast default route from 235 their border router to the provider's border router and then MSDP 236 peer with the provider's MSDP router. If internal MSDP peerings are 237 also used within the enterprise, then an MSDP default peer will need 238 to be configured on the border router pointing to the provider. In 239 this way, all external multicast sources will be learned and internal 240 sources can be advertised. If only a single MSDP peering was used (no 241 internal MSDP peerings) towards the provider, then this stub site 242 will MSDP default peer towards the provider and skip the peer-RPF 243 check. 245 2.4. MSDP peering at a Multicast Exchange 247 Multicast exchanges allow multicast providers to peer at a common IP 248 subnet (or by using point to point virtual LANs) and share MSDP SA 249 updates. Each provider will MSDP and MBGP peer with each others 250 directly connected exchange IP address. Each exchange router will 251 send/receive SAs to/from their MSDP peers. They will then be able to 252 forward SAs throughout their domain to their customers and any direct 253 provider peerings. 255 3. Intra-domain MSDP peering scenarios 257 The following sections describe the different intra-domain MSDP 258 peering possibilities and their deployment options. 260 3.1. Peering between MSDP and MBGP configured routers 262 The next hop IP address of the iBGP peer is typically used for the 263 MSDP peer-RPF check (IGP can also be used). This is different from 264 the inter-domain BGP/MSDP case, where AS path information is used for 265 the peer-RPF check. For this reason, it is necessary for the IP 266 address of the MSDP peer connection be the same as the internal MBGP 267 peer connection whether or not the MSDP/MBGP peers are directly 268 connected. A successful deployment would be similar to the following: 270 +----+ 271 | Rb | 3.3.3.3 272 / +----+ 273 AS1 AS2 / | 274 +---+ +--+ / | 275 |RP1|---------|Ra| | 276 +---+ +--+ | 277 1.1.1.1 2.2.2.2 | 278 \ | 279 \ | 280 \ +-----+ 281 | RP2 | 282 +-----+ 284 Where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb 285 (using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the 286 MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update 287 from MSDP peer 2.2.2.2 which is also the correct MBGP next hop for 288 1.1.1.1. 290 When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP 291 lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly 292 fails, preventing a loop. 294 This deployment could also fail on an update from Ra to RP2 if RP2 295 was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain 296 deployments must have MSDP and MBGP (or other IGP) peering addresses 297 which match, unless a method to skip the peer-RPF check is deployed. 299 3.2. MSDP peer is not BGP peer (or no BGP peer) 301 This is a common MSDP intra-domain deployment in environments where 302 few routers are running MBGP or where the domain is not running MBGP. 303 The problem here is that the MSDP peer address needs to be the same 304 as the MBGP peer address. To get around this requirement, the intra- 305 domain MSDP RPF rules have been relaxed in the following topologies: 307 o By configuring the MSDP peer as a mesh group peer 309 o By having the MSDP peer be the only MSDP peer 311 o By configuring a default MSDP peer 313 o By peering with the originating RP. 315 o By relying upon an IGP for MSDP peer-RPF 317 The common choice around the intra-domain BGP peering requirement, 318 when more than one MSDP peer is configured, is to deploy MSDP mesh 319 groups. When a MSDP mesh group is deployed, there is no RPF check on 320 arriving SA messages when received from a mesh group peer. 321 Subsequently, SA messages are always accepted from mesh group peers. 322 MSDP mesh groups were developed to reduce the amount of SA traffic in 323 the network since SAs, which arrive from a mesh group peer, are not 324 flooded to peers within that same mesh group. Mesh groups must be 325 fully meshed. 327 If recent (but not currently widely deployed) router code is running 328 which is fully complaint with the latest MSDP draft, another option, 329 to work around not having BGP to MSDP RPF peer, is to RPF using an 330 IGP like OSPF, IS-IS, RIP, etc. This new capability will allow for 331 enterprise customers, who are not running BGP and who don't want to 332 run mesh groups, to use their existing IGP to satisfy the MSDP peer- 333 RPF rules. 335 3.3. Hierarchical Mesh Groups 337 Hierarchal Mesh Groups are occasionally deployed in intra-domain 338 environments where there are a large number of MSDP peers. Allowing 339 multiple mesh groups to forward to one another can reduce the number 340 of MSDP peerings per router (due to the full mesh requirement) and 341 hence reduce router load. A good hierarchical mesh group 342 implementation (one which prevents looping) contains a core mesh 343 group in the backbone and these core routers serve as mesh group 344 aggregation routers: 346 [R2]{A,2} 347 / \ 348 / \ 349 / \ 350 / \ 351 / \ 352 / \ 353 / \ 354 {A,1}[R1]-------------[R3]{A,3} 356 In this example, R1, R2, R3 are in MSDP mesh group A (the core mesh 357 group) and each serves as MSDP aggregation routers for their leaf (or 358 second tier) mesh groups 1, 2, and 3. Since SA messages received from 359 a mesh group peer are not forwarded to peers within that same mesh 360 group, SA messages will not loop. Do not create topologies which 361 connect mesh-groups in a loop. In the above example for instance, 362 second tier mesh-groups 1, 2, and 3 must not directly exchange SA 363 messages with each other or an endless SA loop will occur. 365 Redundancy, between mesh groups, will also cause a loop and is 366 subsequently not available with Hierarchical mesh groups. For 367 instance, assume R3 had two routers connecting its leaf mesh group 3 368 with the core mesh group A. A loop would be created between mesh 369 group 3 and mesh group A because each mesh group must be fully meshed 370 between peers. 372 3.4. MSDP and Route Reflectors 374 BGP requires all iBGP speakers, that are not route-reflector clients 375 or confederation members, be fully meshed to prevent loops. In the 376 route reflector environment, MSDP requires that the route reflector 377 clients peer with the route reflector since the router reflector (RR) 378 is the BGP announcer of the next hop towards the originating RP. The 379 RR is not the BGP next hop, but is the announcer of the BGP next hop. 380 The announcer of the next hop is the address typically used for MSDP 381 peer-RPF checks. For example, consider the following case: 383 Ra--------RR 384 /|\ 385 / | \ 386 A B C 388 Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, 389 and C also MSDP peer with RR. When RR forwards the SA to A, B, and C, 390 these RR clients will accept the SA because RR is the announcer of 391 the next hop to the originating RP address. 393 An SA will peer-RPF fail, if Ra MSDP peers directly with Routers A, 394 B, or C, because the announcer of the next hop is RR, but the SA 395 update came from Ra. Proper deployment is to have RR clients MSDP 396 peer with the RR. MSDP mesh groups may be used to work around this 397 requirement. External MSDP peerings will also prevent this 398 requirement since the next AS is compared between MBGP and MSDP 399 peerings, rather than the IP address of the announcer of the next 400 hop. 402 Some recent MSDP implementations conform to the latest MSDP draft 403 which relaxes the requirement of peering with the Advertiser of the 404 Next Hop (the Route Reflector). This new rule allows for peering with 405 the Next-Hop, in addition to the Advertiser of the next hop. In the 406 example above, for instance, if Ra is the Next-Hop (perhaps due to 407 using BGP's Next hop self attribute) and if routers A,B,C are peering 408 with Ra, the SA's received from Ra will now succeed. 410 3.5. MSDP and Anycast RPs 412 A network, with multiple RPs, can achieve RP load sharing and 413 redundancy by using the Anycast RP mechanism in conjunction with MSDP 414 mesh groups [RFC3446]. This mechanism is a common deployment 415 technique used within a domain by service providers and enterprises 416 which deploy several RPs within their domain. These RPs will each 417 have the same IP address configured on a Loopback interface (making 418 this the Anycast address). These RPs will MSDP peer with each other 419 using a separate loopback interface and are part of the same fully 420 meshed MSDP mesh group. This loopback interface, used for MSDP 421 peering, will typically also be used for the MBGP peering. All 422 routers within the provider's domain will learn of the Anycast RP 423 address either through Auto-RP, BSR, or a static RP assignment. Each 424 designated router in the domain will send source registers and group 425 joins to the Anycast RP address. Unicast routing will direct those 426 registers and joins to the nearest Anycast RP. If a particular 427 Anycast RP router fails, unicast routing will direct subsequent 428 registers and joins to the nearest Anycast RP. That RP will then 429 forward an MSDP update to all peers within the Anycast MSDP mesh 430 group. Each RP will then forward (or receive) the SAs to (from) 431 external customers and providers. 433 4. Intellectual Property 435 The IETF takes no position regarding the validity or scope of any 436 intellectual property or other rights that might be claimed to 437 pertain to the implementation or use of the technology described in 438 this document or the extent to which any license under such rights 439 might or might not be available; neither does it represent that it 440 has made any effort to identify any such rights. Information on the 441 IETF's procedures with respect to rights in standards-track and 442 standards-related documentation can be found in BCP-11. Copies of 443 claims of rights made available for publication and any assurances of 444 licenses to be made available, or the result of an attempt made to 445 obtain a general license or permission for the use of such 446 proprietary rights by implementors or users of this specification can 447 be obtained from the IETF Secretariat. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights which may cover technology that may be required to practice 452 this standard. Please address the information to the IETF Executive 453 Director. 455 5. Acknowledgments 457 The authors would like to thank John Zwiebel, Swapna Yelamanchi, Greg 458 Shepherd, and Jay Ford for their feedback on earlier versions of this 459 document. The list of group addresses listed in section 6.1 is due to 460 Bill Nickless. 462 6. Security Considerations 464 An MSDP service should be secured by explicitly controlling the state 465 which is created by, and passed within, the MSDP service. As with 466 unicast routing state, MSDP state should be controlled locally, at 467 the edge origination points. Selective filtering at the multicast 468 service edge helps ensure that only intended sources result in SA 469 message creation, and this control helps to reduce the likelihood of 470 state-aggregation related problems in the core. There are a variety 471 of points where local policy should be applied to the MSDP service. 473 6.1. Filtering SA messages 475 The process of originating SA messages should be filtered to ensure 476 only intended local sources are resulting in SA message origination. 477 In addition, MSDP speakers should filter on which SA messages get 478 received and forwarded. 480 Typically there is a fair amount of (S,G) state in a PIM-SM domain 481 that is local to the domain. However, without proper filtering, sa- 482 messages containing these local (S,G) announcements may be advertised 483 to the global MSDP infrastructure. Examples of this includes domain 484 local applications that use global IP multicast addresses and sources 485 that use RFC 1918 addresses [RFC1918]. To improve on the scalability 486 of MSDP and to avoid global visibility of domain local (S,G) 487 information, the following external SA filter list is recommended to 488 help prevent unnecessary creation, forwarding, and caching of some of 489 these well-known domain local sources. 491 Group Address Use Reference 492 ------------------------------------------------------------------- 493 224.0.0.0/24 Specific local application packets [IANA] 494 224.0.1.22/32 SVRLOC 495 224.0.1.22/32 Microsoft-DS 496 224.0.1.35/32 SVRLOC-DA 497 224.0.1.39/32 CISCO-RP-ANNOUNCE [AUTORP] 498 224.0.1.40/32 CISCO-RP-DISCOVERY [AUTORP] 499 224.0.2.2/32 SUN-RPC 500 224.77.0.0/16 Norton Ghost 501 224.128.0.0/24 Control plane of IGMP snoopers 502 225.0.0.0/24 Control plane of IGMP snoopers 503 225.1.2.3/32 Altiris 504 225.128.0.0/24 Control plane of IGMP snoopers 505 226.0.0.0/24 Control plane of IGMP snoopers 506 226.77.0.0/16 Norton Ghost 507 226.128.0.0/24 Control plane of IGMP snoopers 508 227.0.0.0/24 Control plane of IGMP snoopers 509 227.128.0.0/24 Control plane of IGMP snoopers 510 228.0.0.0/24 Control plane of IGMP snoopers 511 228.128.0.0/24 Control plane of IGMP snoopers 512 229.0.0.0/24 Control plane of IGMP snoopers 513 229.128.0.0/24 Control plane of IGMP snoopers 514 230.0.0.0/24 Control plane of IGMP snoopers 515 230.128.0.0/24 Control plane of IGMP snoopers 516 231.0.0.0/24 Control plane of IGMP snoopers 517 231.128.0.0/24 Control plane of IGMP snoopers 518 232.0.0.0/24 Control plane of IGMP snoopers 519 232.128.0.0/24 Control plane of IGMP snoopers 520 233.0.0.0/8 Source-Specific Multicast [SSM] 521 233.0.0.0/24 Control plane of IGMP snoopers 522 233.128.0.0/24 Control plane of IGMP snoopers 523 234.0.0.0/24 Control plane of IGMP snoopers 524 234.42.42.42/32 Phoenix/StorageSoft ImageCast 525 234.128.0.0/24 Control plane of IGMP snoopers 526 234.142.142.42/31 Phoenix/StorageSoft ImageCast 527 234.142.142.44/30 Phoenix/StorageSoft ImageCast 528 234.142.142.48/28 Phoenix/StorageSoft ImageCast 529 234.142.142.64/26 Phoenix/StorageSoft ImageCast 530 234.142.142.128/29 Phoenix/StorageSoft ImageCast 531 234.142.142.136/30 Phoenix/StorageSoft ImageCast 532 234.142.142.140/31 Phoenix/StorageSoft ImageCast 533 234.142.142.142/32 Phoenix/StorageSoft ImageCast 534 235.0.0.0/24 Control plane of IGMP snoopers 535 235.128.0.0/24 Control plane of IGMP snoopers 536 236.0.0.0/24 Control plane of IGMP snoopers 537 236.128.0.0/24 Control plane of IGMP snoopers 538 237.0.0.0/24 Control plane of IGMP snoopers 539 Group Address Use Reference 540 ------------------------------------------------------------------- 541 237.128.0.0/24 Control plane of IGMP snoopers 542 238.0.0.0/24 Control plane of IGMP snoopers 543 238.128.0.0/24 Control plane of IGMP snoopers 544 239.0.0.0/8 Administratively Scoped Groups [RFC2365] 545 239.0.0.0/24 Control plane of IGMP snoopers 546 239.128.0.0/24 Control plane 548 Source Address Use Reference 549 ------------------------------------------------------------------- 550 0.0.0.0/32 Any/This/Default [RFC3330] 551 10.0.0.0/8 Private addresses [RFC1918] 552 127.0.0.0/8 Loopback addresses [RFC1918] 553 169.254.0.0/16 DHCP auto-config local-use [RFC3330] 554 172.16.0.0/12 Private addresses [RFC1918] 555 192.0.2.0/24 TEST-NET [RFC3330] 556 192.168.0.0/16 Private addresses [RFC1918] 558 6.2. SA message state limits 560 Proper filtering on SA message origination, receipt, and forwarding 561 will significantly reduce the likelihood of unintended and unexpected 562 spikes in MSDP state However, a sa-cache state limit SHOULD BE be 563 configured as a final safeguard to state spikes. 565 7. IANA Considerations 567 This document creates a no new requirements on IANA namespaces 568 [RFC2434]. 570 8. References 572 8.1. Normative References 574 [MSDP] Meyer, D. and W. Fenner (Editors), "The Multicast 575 Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-20.txt, 576 May 2003. Work in Progress. 578 [SSM] Holbrook, H., and B. Cain, "Source-Specific 579 Multicast for IP", draft-ietf-ssm-arch-03.txt, 580 May, 2003. Work in Progress. 582 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway 583 Protocol 4 (BGP-4)", RFC 1771, March 1995. 585 [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de 586 Groot, E. Lear, "Address Allocation for Private 587 Internets", RFC 1918, Feburary, 1996. 589 [RFC2362] D. Estrin, et. al., "Protocol Independent 590 Multicast - Sparse Mode (PIM-SM): Protocol 591 Specification", RFC 2362, June, 1998. 593 [RFC2365] Meyer, D. "Administratively Scoped IP Multicast", 594 RFC 2365, July, 1998. 596 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 597 Writing an IANA Considerations Section in 598 RFCs", RFC 2434/BCP 0026, October, 1998. 600 [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, 601 "Multiprotocol Extensions for BGP-4", RFC 2858, 602 June 2000. 604 [RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330, 605 September 2002. 607 [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) 608 Mechanism using Protocol Independent Multicast 609 (PIM) and Multicast Source Discovery Protocol 610 (MSDP)", RFC 3446, January, 2003. 612 8.2. Informative References 614 [AUTORP] Fenner, W., et. al., " Protocol Independent 615 Multicast - Sparse Mode (PIM-SM): Protocol 616 Specification (Revised)", draft-ietf-pim-sm-v2-new-07.txt, 617 March, 2003. Work in Progress. 619 [BSR] Fenner, W., et. al., "Bootstrap Router (BSR) 620 Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, 621 February, 2003. Work in Progress. 623 [IANA] http://www.iana.org 625 9. Author's Addresses 627 Mike McBride 628 Isac Systems 629 Email: mcbride@cisco.com 631 John Meylor 632 Cisco Systems 633 Email: jmeylor@cisco.com 635 David Meyer 636 Email: dmm@maoz.com 638 10. Full Copyright Statement 640 Copyright (C) The Internet Society (2003). All Rights Reserved. 642 This document and translations of it may be copied and furnished to 643 others, and derivative works that comment on or otherwise explain it 644 or assist in its implementation may be prepared, copied, published 645 and distributed, in whole or in part, without restriction of any 646 kind, provided that the above copyright notice and this paragraph are 647 included on all such copies and derivative works. However, this 648 document itself may not be modified in any way, such as by removing 649 the copyright notice or references to the Internet Society or other 650 Internet organizations, except as needed for the purpose of 651 developing Internet standards in which case the procedures for 652 copyrights defined in the Internet Standards process must be 653 followed, or as required to translate it into languages other than 654 English. 656 The limited permissions granted above are perpetual and will not be 657 revoked by the Internet Society or its successors or assigns. 659 This document and the information contained herein is provided on an 660 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 661 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 662 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 663 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 664 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.