From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4611.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc4611.txt (limited to 'doc/rfc/rfc4611.txt') diff --git a/doc/rfc/rfc4611.txt b/doc/rfc/rfc4611.txt new file mode 100644 index 0000000..b5f1536 --- /dev/null +++ b/doc/rfc/rfc4611.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. McBride +Request for Comments: 4611 J. Meylor +BCP: 121 D. Meyer +Category: Best Current Practice August 2006 + + + Multicast Source Discovery Protocol (MSDP) Deployment Scenarios + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes best current practices for intra-domain and + inter-domain deployment of the Multicast Source Discovery Protocol + (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode + (PIM-SM). + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. BCP, Experimental Protocols, and Normative References ......3 + 2. Inter-domain MSDP Peering Scenarios .............................4 + 2.1. Peering between PIM Border Routers .........................4 + 2.2. Peering between Non-Border Routers .........................5 + 2.3. MSDP Peering without BGP ...................................7 + 2.4. MSDP Peering at a Multicast Exchange .......................7 + 3. Intra-domain MSDP Peering Scenarios .............................7 + 3.1. Peering between MSDP- and MBGP-Configured Routers ..........8 + 3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer) .................8 + 3.3. Hierarchical Mesh Groups ...................................9 + 3.4. MSDP and Route Reflectors .................................10 + 3.5. MSDP and Anycast RPs ......................................11 + 4. Security Considerations ........................................11 + 4.1. Filtering SA Messages .....................................11 + 4.2. SA Message State Limits ...................................12 + 5. Acknowledgements ...............................................12 + 6. References .....................................................12 + 6.1. Normative References ......................................12 + 6.2. Informative References ....................................13 + + + + +McBride, et al. Best Current Practice [Page 1] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + +1. Introduction + + MSDP [RFC3618] is used primarily in two deployment scenarios: + + o Between PIM Domains + + MSDP can be used between Protocol Independent Multicast Sparse + Mode (PIM-SM) [RFC4601] domains to convey information about active + sources available in other domains. MSDP peering used in such + cases is generally one-to-one peering, and utilizes the + deterministic peer-RPF (Reverse Path Forwarding) rules described + in the MSDP specification (i.e., it does not use mesh-groups). + Peerings can be aggregated on a single MSDP peer. Such a peer can + typically have from one to hundreds of peerings, which is similar + in scale to BGP peerings. + + o Within a PIM Domain + + MSDP is often used between Anycast Rendezvous Points (Anycast-RPs) + [RFC3446] within a PIM domain to synchronize information about the + active sources being served by each Anycast-RP peer (by virtue of + IGP reachability). MSDP peering used in this scenario is + typically based on MSDP mesh groups, where anywhere from two to + tens of peers can comprise a given mesh group, although more than + ten is not typical. One or more of these mesh-group peers may + also have additional one-to-one peerings with MSDP peers outside + that PIM domain for discovery of external sources. MSDP for + anycast-RP without external MSDP peering is a valid deployment + option and common. + + Current best practice for MSDP deployment utilizes PIM-SM and the + Border Gateway Protocol with multi-protocol extensions (MBGP) + [RFC4271, RFC2858]. This document outlines how these protocols work + together to provide an intra-domain and inter-domain Any Source + Multicast (ASM) service. + + The PIM-SM specification assumes that SM operates only in one PIM + domain. MSDP is used to enable the use of multiple PIM domains by + distributing the required information about active multicast sources + to other PIM domains. Due to breaking the Internet multicast + infrastructure down to multiple PIM domains, MSDP also enables the + possibility of setting policy on the visibility of the groups and + sources. + + Transit IP providers typically deploy MSDP to be part of the global + multicast infrastructure by connecting to their upstream and peer + multicast networks using MSDP. + + + + +McBride, et al. Best Current Practice [Page 2] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + Edge multicast networks typically have two choices: to use their + Internet providers' RP, or to have their own RP and connect it to + their ISP using MSDP. By deploying their own RP and MSDP, they can + use internal multicast groups that are not visible to the provider's + RP. This helps internal multicast be able to continue to work in the + event that there is a problem with connectivity to the provider or + that the provider's RP/MSDP is experiencing difficulties. In the + simplest cases, where no internal multicast groups are necessary, + there is often no need to deploy MSDP. + +1.1. BCP, Experimental Protocols, and Normative References + + This document describes the best current practice for a widely + deployed Experimental protocol, MSDP. There is no plan to advance + the MSDP's status (for example, to Proposed Standard). The reasons + for this include: + + o MSDP was originally envisioned as a temporary protocol to be + supplanted by whatever the IDMR working group produced as an + inter-domain protocol. However, the IDMR WG (or subsequently, the + BGMP WG) never produced a protocol that could be deployed to + replace MSDP. + + o One of the primary reasons given for MSDP to be classified as + Experimental was that the MSDP Working Group came up with + modifications to the protocol that the WG thought made it better + but that implementors didn't see any reasons to deploy. Without + these modifications (e.g., UDP or GRE encapsulation), MSDP can + have negative consequences to initial packets in datagram streams. + + o Scalability: Although we don't know what the hard limits might be, + readvertising everything you know every 60 seconds clearly limits + the amount of state you can advertise. + + o MSDP reached nearly ubiquitous deployment as the de facto standard + inter-domain multicast protocol in the IPv4 Internet. + + o No consensus could be reached regarding the reworking of MSDP to + address the many concerns of various constituencies within the + IETF. As a result, a decision was taken to document what is + (ubiquitously) deployed and to move that document to Experimental. + While advancement of MSDP to Proposed Standard was considered, for + the reasons mentioned above, it was immediately discarded. + + o The advent of protocols such as source-specific multicast and bi- + directional PIM, as well as embedded RP techniques for IPv6, have + further reduced consensus that a replacement protocol for MSDP for + the IPv4 Internet is required. + + + +McBride, et al. Best Current Practice [Page 3] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + The RFC Editor's policy regarding references is that they be split + into two categories known as "normative" and "informative". + Normative references specify those documents that must be read for + one to understand or implement the technology in an RFC (or whose + technology must be present for the technology in the new RFC to work) + [RFCED]. In order to understand this document, one must also + understand both the PIM and MSDP documents. As a result, references + to these documents are normative. + + The IETF has adopted the policy that BCPs must not have normative + references to Experimental protocols. However, this document is a + special case in that the underlying Experimental document (MSDP) is + not planned to be advanced to Proposed Standard. + + The MBONED Working Group has requested approval under the Variance + Procedure as documented in RFC 2026 [RFC2026]. The IESG followed the + Variance Procedure and, after an additional 4 week IETF Last Call, + evaluated the comments and status, and has approved this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Inter-domain MSDP Peering Scenarios + + The following sections describe the most common inter-domain MSDP + peering possibilities and their deployment options. + +2.1. Peering between PIM Border Routers + + In this case, the MSDP peers within the domain have their own RP + located within a bounded PIM domain. In addition, the domain will + typically have its own Autonomous System (AS) number and one or more + MBGP speakers. The domain may also have multiple MSDP speakers. + Each border router has an MSDP and MBGP peering with its peer + routers. These external MSDP peering deployments typically configure + the MBGP peering and MSDP peering using the same directly connected + next hop peer IP address or other IP address from the same router. + Typical deployments of this type are providers who have a direct + peering with other providers, providers peering at an exchange, or + providers who use their edge router to MSDP/MBGP peer with customers. + + For a direct peering inter-domain environment to be successful, the + first AS in the MBGP best path to the originating RP should be the + same as the AS of the MSDP peer. As an example, consider the + following topology: + + + + + +McBride, et al. Best Current Practice [Page 4] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + AS1----AS2----AS4 + | / + | / + | / + AS3 + + In this case, AS4 receives a Source Active (SA) message, originated + by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP + first hop AS from AS4, in the best path to the originating RP, is + AS2. The AS of the sending MSDP peer is also AS2. In this case, the + peer-Reverse Path Forwarding check (peer-RPF check) passes, and the + SA message is forwarded. + + A peer-RPF failure would occur in this topology when the MBGP first + hop AS, in the best path to the originating RP, is AS2 and the origin + AS of the sending MSDP peer is AS3. This reliance upon BGP AS PATH + information prevents endless looping of SA packets. + + Router code, which has adopted the latest rules in the MSDP document, + will relax the rules between AS's a bit. In the following topology, + we have an MSDP peering between AS1<->AS3 and AS3<->AS4: + + RP + AS1----AS2----AS3----AS4 + + If the first AS in best path to the RP does not equal the MSDP peer, + MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3, since AS2 is + the first AS in the MBGP best path to AS4 RP. With the latest MSDP + document compliant code, AS1 will choose the peer in the closest AS + along best AS path to the RP. AS1 will then accept SA's coming from + AS3. If there are multiple MSDP peers to routers within the same AS, + the peer with the highest IP address is chosen as the RPF peer. + +2.2. Peering between Non-Border Routers + + For MSDP peering between border routers, intra-domain MSDP + scalability is restricted because it is necessary to also maintain + MBGP and MSDP peerings internally towards their border routers. + Within the intra-domain, the border router becomes the announcer of + the next hop towards the originating RP. This requires that all + intra-domain MSDP peerings mirror the MBGP path back towards the + border router. External MSDP (eMSDP) peerings rely upon AS path for + peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the + announcer of the next hop. + + + + + + + +McBride, et al. Best Current Practice [Page 5] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + While the eMBGP peer is typically directly connected between border + routers, it is common for the eMSDP peer to be located deeper into + the transit provider's AS. Providers, which desire more flexibility + in MSDP peering placement, commonly choose a few dedicated routers + within their core networks for the inter-domain MSDP peerings to + their customers. These core MSDP routers will also typically be in + the provider's intra-domain MSDP mesh group and be configured for + Anycast RP. All multicast routers in the provider's AS should + statically point to the Anycast RP address. Static RP assignment is + the most commonly used method for group-to-RP mapping due to its + deterministic nature. Auto-RP [RFC4601] and/or the Bootstrap Router + (BSR) [BSR] dynamic RP mapping mechanisms could also be used to + disseminate RP information within the provider's network + + For an SA message to be accepted in this (multi-hop peering) + environment, we rely upon the next (or closest, with latest MSDP + spec) AS in the best path towards the originating RP for the RPF + check. The MSDP peer address should be in the same AS as the AS of + the border router's MBGP peer. The MSDP peer address should be + advertised via MBGP. + + For example, in the diagram below, if customer R1 router is MBGP + peering with the R2 router and if R1 is MSDP peering with the R3 + router, then R2 and R3 must be in the same AS (or must appear, to + AS1, to be from the same AS in the event that private AS numbers are + deployed). The MSDP peer with the highest IP address will be chosen + as the MSDP RPF peer. R1 must also have the MSDP peer address of R3 + in its MBGP table. + + +--+ +--+ +--+ + |R1|----|R2|----|R3| + +--+ +--+ +--+ + AS1 AS2 AS2 + + From R3's perspective, AS1 (R1) is the MBGP next AS in the best path + towards the originating RP. As long as AS1 is the next AS (or + closest) in the best path towards the originating RP, RPF will + succeed on SAs arriving from R1. + + In contrast, with the single hop scenario, with R2 (instead of R3) + border MSDP peering with R1 border, R2's MBGP address becomes the + announcer of the next hop for R3, towards the originating RP, and R3 + must peer with that R2 address. Moreover, all AS2 intra-domain MSDP + peers need to follow iMBGP (or other IGP) peerings towards R2 since + iMSDP has a dependence upon peering with the address of the MBGP (or + other IGP) announcer of the next hop. + + + + + +McBride, et al. Best Current Practice [Page 6] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + +2.3. MSDP Peering without BGP + + In this case, an enterprise maintains its own RP and has an MSDP + peering with its service provider but does not BGP peer with them. + MSDP relies upon BGP path information to learn the MSDP topology for + the SA peer-RPF check. MSDP can be deployed without BGP, however, + and as a result, there are some special cases where the requirement + to perform a peer-RPF check on the BGP path information is suspended. + These cases are: + + o There is only a single MSDP peer connection. + + o A default peer (default MSDP route) is configured. + + o The originating RP is directly connected. + + o A mesh group is used. + + o An implementation is used that allows for an MSDP peer-RPF check + using an IGP. + + An enterprise will typically configure a unicast default route from + its border router to the provider's border router and then MSDP peer + with the provider's MSDP router. If internal MSDP peerings are also + used within the enterprise, then an MSDP default peer will need to be + configured on the border router that points to the provider. In this + way, all external multicast sources will be learned, and internal + sources can be advertised. If only a single MSDP peering was used + (no internal MSDP peerings) towards the provider, then this stub site + will MSDP default peer towards the provider and skip the peer-RPF + check. + +2.4. MSDP Peering at a Multicast Exchange + + Multicast exchanges allow multicast providers to peer at a common IP + subnet (or by using point-to-point virtual LANs) and share MSDP SA + updates. Each provider will MSDP and MBGP peer with each others + directly connected exchange IP address. Each exchange router will + send/receive SAs to/from their MSDP peers. They will then be able to + forward SAs throughout their domain to their customers and any direct + provider peerings. + +3. Intra-domain MSDP Peering Scenarios + + The following sections describe the different intra-domain MSDP + peering possibilities and their deployment options. + + + + + +McBride, et al. Best Current Practice [Page 7] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + +3.1. Peering between MSDP- and MBGP-Configured Routers + + The next hop IP address of the iBGP peer is typically used for the + MSDP peer-RPF check (IGP can also be used). This is different from + the inter-domain BGP/MSDP case, where AS path information is used for + the peer-RPF check. For this reason, it is necessary for the IP + address of the MSDP peer connection to be the same as the internal + MBGP peer connection whether or not the MSDP/MBGP peers are directly + connected. A successful deployment would be similar to the + following: + + +----+ + | Rb | 3.3.3.3 + / +----+ + AS1 AS2 / | + +---+ +--+ / | + |RP1|---------|Ra| | + +---+ +--+ | + 1.1.1.1 2.2.2.2 | + \ | + \ | + \ +-----+ + | RP2 | + +-----+ + + where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb + (using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the + MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update + from MSDP peer 2.2.2.2, which is also the correct MBGP next hop for + 1.1.1.1. + + When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP + lookup for 1.1.1.1 shows a next hop of 2.2.2.2, so RPF correctly + fails, preventing a loop. + + This deployment could also fail on an update from Ra to RP2 if RP2 + was MBGP peering to an address other than 2.2.2.2 on Ra. Intra- + domain deployments must have MSDP and MBGP (or other IGP) peering + addresses that match, unless a method to skip the peer-RPF check is + deployed. + +3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer) + + This is a common MSDP intra-domain deployment in environments where + few routers are running MBGP or where the domain is not running MBGP. + The problem here is that the MSDP peer address needs to be the same + as the MBGP peer address. To get around this requirement, the intra- + domain MSDP RPF rules have been relaxed in the following topologies: + + + +McBride, et al. Best Current Practice [Page 8] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + o By configuring the MSDP peer as a mesh group peer. + + o By having the MSDP peer be the only MSDP peer. + + o By configuring a default MSDP peer. + + o By peering with the originating RP. + + o By relying upon an IGP for MSDP peer-RPF. + + The common choice around the intra-domain BGP peering requirement, + when more than one MSDP peer is configured, is to deploy MSDP mesh + groups. When an MSDP mesh group is deployed, there is no RPF check + on arriving SA messages when they are received from a mesh group + peer. Subsequently, SA messages are always accepted from mesh group + peers. MSDP mesh groups were developed to reduce the amount of SA + traffic in the network since SAs, which arrive from a mesh group + peer, are not flooded to peers within that same mesh group. Mesh + groups must be fully meshed. + + If recent (but not currently widely deployed) router code is running + that is fully compliant with the latest MSDP document, another + option, to work around not having BGP to MSDP RPF peer, is to RPF + using an IGP like OSPF, IS-IS, RIP, etc. This new capability will + allow for enterprise customers, who are not running BGP and who don't + want to run mesh groups, to use their existing IGP to satisfy the + MSDP peer-RPF rules. + +3.3. Hierarchical Mesh Groups + + Hierarchical mesh groups are occasionally deployed in intra-domain + environments where there are a large number of MSDP peers. Allowing + multiple mesh groups to forward to one another can reduce the number + of MSDP peerings per router (due to the full mesh requirement) and + hence reduce router load. A good hierarchical mesh group + implementation (one that prevents looping) contains a core mesh group + in the backbone, and these core routers serve as mesh group + aggregation routers: + + [R2]{A,2} + / \ + / \ + / \ + / \ + / \ + / \ + / \ + {A,1}[R1]-------------[R3]{A,3} + + + +McBride, et al. Best Current Practice [Page 9] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + In this example, R1, R2, and R3 are in MSDP mesh group A (the core + mesh group), and each serves as MSDP aggregation routers for their + leaf (or second tier) mesh groups 1, 2, and 3. Since SA messages + received from a mesh group peer are not forwarded to peers within + that same mesh group, SA messages will not loop. Do not create + topologies that connect mesh groups in a loop. In the above example, + for instance, second-tier mesh groups 1, 2, and 3 must not directly + exchange SA messages with each other or an endless SA loop will + occur. + + Redundancy between mesh groups will also cause a loop and is + subsequently not available with hierarchical mesh groups. For + instance, assume that R3 had two routers connecting its leaf mesh + group 3 with the core mesh group A. A loop would be created between + mesh group 3 and mesh group A because each mesh group must be fully + meshed between peers. + +3.4. MSDP and Route Reflectors + + BGP requires all iBGP speakers that are not route-reflector clients + or confederation members be fully meshed to prevent loops. In the + route reflector environment, MSDP requires that the route reflector + clients peer with the route reflector since the router reflector (RR) + is the BGP announcer of the next hop towards the originating RP. The + RR is not the BGP next hop, but is the announcer of the BGP next hop. + The announcer of the next hop is the address typically used for MSDP + peer-RPF checks. For example, consider the following case: + + Ra--------RR + /|\ + / | \ + A B C + + Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, + and C also MSDP peer with RR. When RR forwards the SA to A, B, and + C, these RR clients will accept the SA because RR is the announcer of + the next hop to the originating RP address. + + An SA will peer-RPF fail if Ra MSDP peers directly with Routers A, B, + or C because the announcer of the next hop is RR but the SA update + came from Ra. Proper deployment is to have RR clients MSDP peer with + the RR. MSDP mesh groups may be used to work around this + requirement. External MSDP peerings will also prevent this + requirement since the next AS is compared between MBGP and MSDP + peerings, rather than the IP address of the announcer of the next + hop. + + + + + +McBride, et al. Best Current Practice [Page 10] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + Some recent MSDP implementations conform to the latest MSDP document, + which relaxes the requirement of peering with the Advertiser of the + next hop (the Route Reflector). This new rule allows for peering + with the next hop, in addition to the Advertiser of the next hop. In + the example above, for instance, if Ra is the next hop (perhaps due + to using BGP's next hop self attribute), and if routers A, B, and C + are peering with Ra, the SA's received from Ra will now succeed. + +3.5. MSDP and Anycast RPs + + A network with multiple RPs can achieve RP load sharing and + redundancy by using the Anycast RP mechanism in conjunction with MSDP + mesh groups [RFC3446]. This mechanism is a common deployment + technique used within a domain by service providers and enterprises + that deploy several RPs within their domains. These RPs will each + have the same IP address configured on a Loopback interface (making + this the Anycast address). These RPs will MSDP peer with each other + using a separate loopback interface and are part of the same fully + meshed MSDP mesh group. This loopback interface, used for MSDP + peering, will typically also be used for the MBGP peering. All + routers within the provider's domain will learn of the Anycast RP + address through Auto-RP, BSR, or a static RP assignment. Each + designated router in the domain will send source registers and group + joins to the Anycast RP address. Unicast routing will direct those + registers and joins to the nearest Anycast RP. If a particular + Anycast RP router fails, unicast routing will direct subsequent + registers and joins to the nearest Anycast RP. That RP will then + forward an MSDP update to all peers within the Anycast MSDP mesh + group. Each RP will then forward (or receive) the SAs to (from) + external customers and providers. + +4. Security Considerations + + An MSDP service should be secured by explicitly controlling the state + that is created by, and passed within, the MSDP service. As with + unicast routing state, MSDP state should be controlled locally, at + the edge origination points. Selective filtering at the multicast + service edge helps ensure that only intended sources result in SA + message creation, and this control helps to reduce the likelihood of + state-aggregation related problems in the core. There are a variety + of points where local policy should be applied to the MSDP service. + +4.1. Filtering SA Messages + + The process of originating SA messages should be filtered to ensure + that only intended local sources are resulting in SA message + origination. In addition, MSDP speakers should filter which SA + messages get received and forwarded. + + + +McBride, et al. Best Current Practice [Page 11] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + Typically, there is a fair amount of (S,G) state in a PIM-SM domain + that is local to the domain. However, without proper filtering, SA + messages containing these local (S,G) announcements may be advertised + to the global MSDP infrastructure. Examples of this include domain- + local applications that use global IP multicast addresses and sources + that use RFC 1918 addresses [RFC1918]. To improve on the scalability + of MSDP and to avoid global visibility of domain local (S,G) + information, an external SA filter list is recommended to help + prevent unnecessary creation, forwarding, and caching of well-known + domain local sources. + +4.2. SA Message State Limits + + Proper filtering on SA message origination, receipt, and forwarding + will significantly reduce the likelihood of unintended and unexpected + spikes in MSDP state. However, an SA-cache state limit SHOULD be + configured as a final safeguard to state spikes. When an MSDP + peering has reached a stable state (i.e., when the peering has been + established and the initial SA state has been transferred), it may + also be desirable to configure a rate limiter for the creation of new + SA state entries. + +5. Acknowledgements + + The authors would like to thank Pekka Savola, John Zwiebel, Swapna + Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier + versions of this document. + +6. References + +6.1. Normative References + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, August 2006. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, + "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. + + + +McBride, et al. Best Current Practice [Page 12] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + + [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast + Rendevous Point (RP) mechanism using Protocol Independent + Multicast (PIM) and Multicast Source Discovery Protocol + (MSDP)", RFC 3446, January 2003. + + [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery + Protocol (MSDP)", RFC 3618, October 2003. + +6.2. Informative References + + [BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for + PIM Sparse Mode", Work in Progress, February 2003. + + [RFCED] http://www.rfc-editor.org/policy.html + +Authors' Addresses + + Mike McBride + Cisco Systems + + EMail: mcbride@cisco.com + + + John Meylor + Cisco Systems + + EMail: jmeylor@cisco.com + + + David Meyer + + EMail: dmm@1-4-5.net + + + + + + + + + + + + + + + + + + + +McBride, et al. Best Current Practice [Page 13] + +RFC 4611 MSDP Deployment Scenarios August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +McBride, et al. Best Current Practice [Page 14] + -- cgit v1.2.3