summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4611.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4611.txt')
-rw-r--r--doc/rfc/rfc4611.txt787
1 files changed, 787 insertions, 0 deletions
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]
+