doc: Add RFC documents

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]
+