draft-ietf-mboned-msdp-deploy-00.txt   draft-ietf-mboned-msdp-deploy-01.txt 
INTERNET-DRAFT Mike McBride
MBONED Working Group Mike McBride draft-ietf-mboned-msdp-deploy-01.txt John Meylor
Internet Draft John Meylor
Cisco Systems
David Meyer David Meyer
Sprint
Category Best Current Practice Category Best Current Practice
Multicast Source Discovery Protocol Deployment Scenarios Expires: November 2003 May 2003
<draft-ietf-mboned-msdp-deploy-00.txt> Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
<draft-ietf-mboned-msdp-deploy-01.txt>
1. Status of this Memo Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract This document is a product of an individual. Comments are solicited
and should be addressed to the author(s).
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes best current practices for intra-domain and This document describes best current practices for intra-domain and
inter-domain MSDP deployment. inter-domain deployment of the Multicast Source Discovery Protocol
(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
(PIM-SM).
3. Copyright Notice Table of Contents
Copyright (C) The Internet Society (2002). All Rights Reserved. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Inter-domain MSDP peering scenarios. . . . . . . . . . . . . . 3
2.1. Peering between PIM border routers. . . . . . . . . . . . . 4
2.2. Peering between non border routers. . . . . . . . . . . . . 5
2.3. MSDP peering without BGP. . . . . . . . . . . . . . . . . . 6
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. . . . . . 7
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. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 12
6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References. . . . . . . . . . . . . . . . . . . 14
9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 15
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
4. Introduction 1. Introduction
The Multicast Source Discovery Protocol [MSDP] is a mechanism to MSDP [MSDP] is used primarily in two deployment scenarios:
connect multiple PIM-SM [RFC2117] domains together. Each PIM-SM
domain uses its own independent Rendezvous Point, or RP, and does not
have to depend on RPs in other domains. Current best practice for
MSDP deployment utilizes Protocol Independent Multicast (Sparse Mode)
and the Border Gateway Protocol With multi-protocol extensions
[RFC2858,NICKLESS]. This document outlines how these protocols work
together to provide Intra-domain and Inter-domain Any Source
multicast (ASM) service. In addition, this document describes how
MSDP can provide a PIM-SM domain with RP redundancy and load
balancing using the Anycast RP mechanism [ANYCAST-RP].
5. Inter-domain MSDP peering scenarios o Between PIM Domains
The following sections describe the different inter-domain MSDP MSDP can be used between Protocol Independent Multicast Sparse
Mode (PIM-SM) [RFC2362] 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., 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 then also have additional
one-to-one peering 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)
[RFC1771, RFC2858]. This document outlines how these protocols work
together to provide an intra-domain and inter-domain Any Source
Multicast (ASM) service.
2. Inter-domain MSDP peering scenarios
The following sections describe the most common inter-domain MSDP
peering possibilities and their deployment options. peering possibilities and their deployment options.
5.1. Peering between PIM border routers (Single hop peering) 2.1. Peering between PIM border routers
In this case, the MSDP peers within the domain each have their own RP In this case, the MSDP peers within the domain have their own RP
located within a bounded PIM domain. In addition, a domain has it's located within a bounded PIM domain. In addition, a domain has it's
own Autonomous Number (AS) and BGP speakers. The domain may also have own Autonomous System (AS) number MBGP speakers. The domain may also
multiple MSDP speakers. Each router has an MSDP and BGP peering with have multiple MSDP speakers. Each border router has an MSDP and MBGP
its peer routers. These deployments typically configure the BGP peering with its peer routers. These external MSDP peering
peering and MSDP peering using the same directly connected next hop deployments typically configure the MBGP peering and MSDP peering
peer IP address or another IP address from the same router. Typical using the same directly connected next hop peer IP address or other
deployments of this type are providers who have a direct peering with IP address from the same router. Typical deployments of this type are
other providers or with providers who use their edge router to 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. MSDP/MBGP peer with customers.
For a direct peering inter-domain environment to be successful, the For a direct peering inter-domain environment to be successful, the
first AS in the BGP best path to the originating RP must be the same first AS in the MBGP best path to the originating RP should be the
as the AS of the MSDP peer [MSDP]. As an example, consider the same as the AS of the MSDP peer. As an example, consider the
following topology: following topology:
AS1----AS2----AS4 AS1----AS2----AS4
| / | /
| / | /
| / | /
AS3 AS3
In this case, AS4 receives an Source Active SA Message (SA), In this case, AS4 receives a Source Active (SA) message, originated
originated by AS1 via AS2, which also has an BGP peering with AS4. by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP
The BGP first hop AS from AS4, in the best path to the originating first hop AS from AS4, in the best path to the originating RP, is
RP, is AS2. The origin AS of the sending MSDP peer is also AS2. The AS2. The origin AS of the sending MSDP peer is also AS2. In this
peer-RPF (Reverse Path Forwarding) check passes and the SA message is case, the peer-Reverse Path Forwarding check (peer-RPF check) passes
forwarded. and the SA message is forwarded.
A peer-RPF failure will occur in this topology when the BGP first-hop A peer-RPF failure would occur in this topology when the MBGP first
AS in the best path to the originating RP is AS2 while the origin AS hop AS, in the best path to the originating RP, is AS2 while the
of the sending MSDP peer is AS3. An MSDP peering between AS2 and AS4 origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS
would prevent this failure from occurring. PATH information prevents endless looping of SA packets.
5.2. Peering between non border routers (Multi-hop peering) Router code, which has adopted the latest rules in the MSDP draft,
will relax the rules Between AS's a bit. In the following topology we
have an MSDP peering between AS1<->AS3 and AS3<->AS4:
While the eBGP peer is typically directly connected between border RP
routers, it is common for the MSDP peer to be located deeper into the AS1----AS2----AS3----AS4
transit providers AS. However, MSDP scalability is sacrificed if a If the first AS in best path to the RP does not equal the MSDP peer,
provider must maintain BGP and MSDP peerings with all their edge MSDP peer RPF fails. So AS1 cannot MSDP peer with AS3 since AS2 is
routers so that they can BGP and MSDP peer with customer routers. the first AS in the MBGP best path to AS4 RP. With the latest MSDP
Alternatively, providers commonly choose a few dedicated routers draft compliant code, AS 1 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
When 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 must 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.
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 providers AS. Providers, which desire more flexibility in
MSDP peering placement, commonly choose a few dedicated routers
within their core network for the inter-domain MSDP peerings to their within their core network for the inter-domain MSDP peerings to their
customers. These core MSDP routers will also typically be in the customers. These core MSDP routers will also typically be in the
providers intra-domain MSDP mesh [MSDP] group and configured for providers intra-domain MSDP mesh group and configured for Anycast RP.
Anycast RP. All multicast routers in the providers AS should All multicast routers in the providers AS should statically point to
statically point to the Anycast RP address. AutoRP and BSR mechanisms the Anycast RP address. Static RP assignment is the most commonly
could be used to disseminate RP information within the provider's used method for group to RP mapping due to its deterministic nature.
network. Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP
mapping mechanisms could be also used to disseminate RP information
within the provider's network
For an SA message to be accepted in this (multi-hop peering) For an SA message to be accepted in this (multi-hop peering)
environment, the MSDP peer address must be in the same AS as the AS environment, we rely upon the next (or closest, with latest MSDP
of the MBGP peer and must be advertised via MBGP. For example, using spec) AS in the best path towards originating RP for the rpf check.
the diagram below, if customer R1 router is MBGP peering with AS2 The MSDP peer address should be in the same AS as the AS of the
provider's R2 router and if R1 is MSDP peering with R3 router, then border routers MBGP peer. The MSDP peer address should be advertised
R2 and R3 must be in the same AS. R1 also must have the MSDP peer via MBGP.
address of R3 in its BGP table.
For example, using the diagram below, if customer R1 router is MBGP
peering with R2 router and if R1 is MSDP peering with R3 router, then
R2 and R3 must be in the same AS. 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| |R1|----|R2|----|R3|
+--+ +--+ +--+ +--+ +--+ +--+
AS1 AS2 AS2 AS1 AS2 AS2
5.3. MSDP peering without BGP 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, R2s MBGP address becomes the
announcer of the next hop for R3, towards the originating RP, and R3
must peer with that R2 address. And 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.
2.3. MSDP peering without BGP
In this case, an enterprise maintains its own RP and has an MSDP In this case, an enterprise maintains its own RP and has an MSDP
peering with their service provider, but does not BGP peer with them. peering with their service provider, but does not BGP peer with them.
MSDP relies upon BGP path information to learn the MSDP topology for 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 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 as a result there are some special cases where the requirement to
perform an peer-RPF check on the BGP path information is suspended. perform an peer-RPF check on the BGP path information is suspended.
In this case (when there is only a single MSDP peer connection) a These cases are when there is only a single MSDP peer connection, a
default peer (default MSDP route) is configured and either the default peer (default MSDP route) is configured, the originating RP
originating RP is directly connected or a mesh group is used. An is directly connected, a mesh group is used, or an implementation is
enterprise will also typically configure a unicast default route from is used which allows for an MSDP peer RPF check using an IGP.
An enterprise will typically configure a unicast default route from
their border router to the provider's border router and then MSDP their border router to the provider's border router and then MSDP
peer with the provider's border router. If internal MSDP peerings are peer with the provider's MSDP router. If internal MSDP peerings are
also used within the enterprise, then an MSDP default peer will need also used within the enterprise, then an MSDP default peer will need
to be configured on the border router pointing to the provider. In to be configured on the border router pointing to the provider. In
this way, all external multicast sources will be learned and internal this way, all external multicast sources will be learned and internal
sources can be advertised. sources can be advertised. If only a single MSDP peering was used (no
internal MSDP peerings) towards the provider, then this stub site
5.4. MSDP peering between mesh groups will MSDP default peer towards the provider and skip the BGP RPF
check.
Mesh groups which are within different PIM domains can MSDP peer with
one another to exchange information about active sources. An RP
within AS1's mesh group may MSDP peer with an RP which is within
AS2's mesh group. However, there should be no mesh group in common
between PIM domains. It is important to note however, that mesh
groups that span PIM domains is not recommended, as SA forwarding
loops can develop. As an example, consider the following topology:
AS2
/ \
/ \
/ \
/ \
/ \
AS1 -------- AS3
If each AS had their own intra-domain MSDP mesh group, and if there
was an inter-domain MSDP mesh group between AS1-AS2, AS1-AS3, and
AS2-AS3 then an SA loop would be created. Since there is no RPF check
between mesh groups, the SAs would loop around from one PIM domain to
another.
5.5. MSDP peering at a Multicast Exchange 2.4. MSDP peering at a Multicast Exchange
Multicast exchanges allow multicast providers to peer at a common IP Multicast exchanges allow multicast providers to peer at a common IP
subnet and share MSDP SA updates. Each provider will MSDP and BGP subnet (or by using point to point virtual LANs) and share MSDP SA
peer with each others directly connected exchange IP address. Each updates. Each provider will MSDP and MBGP peer with each others
exchange router will send/receive SAs over the exchange fabric. They directly connected exchange IP address. Each exchange router will
will then be able to forward SAs throughout their domain to their send/receive SAs to/from their MSDP peers. They will then be able to
customers and any direct provider peerings. forward SAs throughout their domain to their customers and any direct
provider peerings.
6. Intra-domain MSDP peering scenarios 3. Intra-domain MSDP peering scenarios
The following sections describe the different intra-domain MSDP The following sections describe the different intra-domain MSDP
peering possibilities and their deployment options. peering possibilities and their deployment options.
6.1. Peering between routers configured for both MSDP and MBGP 3.1. Peering between MSDP and MBGP configured routers
The next hop IP address of the iBGP peer (that is MSDP is advertising The next hop IP address of the iBGP peer is typically used for the
as the next hop toward the originating RP) is used for the peer-RPF MSDP peer-RPF check (IGP can also be used). This is different from
check. This is different from the inter-domain BGP/MSDP case, where the inter-domain BGP/MSDP case, where AS path information is used for
AS path information is used for the peer-RPF check. For this reason, the peer-RPF check. For this reason, it is necessary for the IP
it is necessary for the IP address of the MSDP peer connection be address of the MSDP peer connection be the same as the internal MBGP
the same as the internal BGP peer connection whether or not the peer connection whether or not the MSDP/MBGP peers are directly
MSDP/MBGP peers are directly connected. A successful deployment would connected. A successful deployment would be similar to the following:
be similar to the following:
+----+ +----+
| Rb | 3.3.3.3 | Rb | 3.3.3.3
/ +----+ / +----+
AS1 AS2 / | AS1 AS2 / |
+---+ +--+ / | +---+ +--+ / |
|RP1|---------|Ra| | |RP1|---------|Ra| |
+---+ +--+ | +---+ +--+ |
1.1.1.1 2.2.2.2 | 1.1.1.1 2.2.2.2 |
\ | \ |
\ | \ |
\ +-----+ \ +-----+
| RP2 | | 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.
Where RP2 MSDP and MBGP peers with Ra using 2.2.2.2 and with Rb using When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP
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
2.2.2.2 which is the correct BGP next hop for 1.1.1.1.
When RP2 receives the same SA update from MSDP peer 3.3.3.3, the BGP
lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly lookup for 1.1.1.1 shows a next hop of 2.2.2.2 so RPF correctly
fails, preventing a loop. fails, preventing a loop.
This deployment would also fail on an update from Ra to RP2 if RP2 was MBGP peering to an address other than 2.2.2.2 on
was BGP peering to an address other than 2.2.2.2 on Ra. Intra-domain Ra. Intra-domain deployments must have MSDP and MBGP (or other
deployments should have MSDP and MBGP peering addresses which match. IGP) peering addresses which match, unless a method to skip the
peer rpf check is deployed.
6.2. MSDP peer is not BGP peer (or no BGP peer) 3.2. MSDP peer is not BGP peer (or no BGP peer)
This is a common MSDP intra-domain deployment in environments where This is a common MSDP intra-domain deployment in environments where
few routers are running BGP or where the domain is not running BGP. 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 The problem here is that the MSDP peer address needs to be the same
as the BGP peer address. To get around this requirement, the intra- as the MBGP peer address. To get around this requirement, the intra-
domain MSDP RPF rules have been relaxed in certain as follows: domain MSDP RPF rules have been relaxed in the following topologies:
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 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, or
o By peering with the originating RP. 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, The common choice around the intra-domain BGP peering requirement,
when more than one MSDP peer is configured, is to deploy MSDP mesh when more than one MSDP peer is configured, is to deploy MSDP mesh
groups. When a MSDP mesh group is deployed, there is no RPF check on groups. When a MSDP mesh group is deployed, there is no RPF check on
arriving SA messages when received from a mesh group peer. arriving SA messages when received from a mesh group peer.
Subsequently, SA messages are always accepted from mesh group peers. 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.
MSDP mesh groups are helpful in reducing the amount of SA traffic in If recent (but not currently widely deployed) router code is running
the network since SAs are not flooded to other mesh group peers. which is fully complaint with the latest MSDP draft, another option,
to work around not having BGP to MSDP RPF peer, is to RPF using an
7. MSDP and Anycast RPs 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
A network with can achieve RP load sharing and redundancy by using run mesh groups, to use their existing IGP to satisfy the MSDP peer
the Anycast RP mechanism in conjunction with MSDP mesh groups RPF rules.
[ANYCAST-RP]. This mechanism is a common deployment technique used by
service providers, who commonly deploy several RPs within their
domain. These RPs will all have the same IP address configured on a
Loopback interface (making this the anycast addresses). These RPs
will MSDP peer with each other using a separate loopback interface
and are part of the same MSDP mesh group. This second Loopback
interface will typically also be used for the MBGP peering. All
routers within the provider's domain will learn of the Anycast RP
address either through AutoRP, 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 global MSDP mesh
group. Each RP will then forward (or receive) the SAs to (from)
external customers and providers.
7.1. Hierarchical Mesh Groups 3.3. Hierarchical Mesh Groups
Hierarchial Mesh Groups are typically deployed in intra-domain Hierarchal Mesh Groups are occasionally deployed in intra-domain
environments where there are a large number of MSDP peers. Allowing environments where there are a large number of MSDP peers. Allowing
multiple mesh groups to forward to one another can reduce the number multiple mesh groups to forward to one another can reduce the number
of MSDP peerings per router and hence reduce router load. A good of MSDP peerings per router (due to the full mesh requirement) and
hierarchical mesh group implementation (one which prevents looping) hence reduce router load. A good hierarchical mesh group
contains a core mesh group in the backbone and these core routers implementation (one which prevents looping) contains a core mesh
serve as mesh group aggregation routers: group in the backbone and these core routers serve as mesh group
aggregation routers:
[R2]{A,2} [R2]{A,2}
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
{A,1}[R1]-------------[R3]{A,3} {A,1}[R1]-------------[R3]{A,3}
skipping to change at page 8, line 4 skipping to change at page 9, line 33
[R2]{A,2} [R2]{A,2}
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
{A,1}[R1]-------------[R3]{A,3} {A,1}[R1]-------------[R3]{A,3}
In this example, R1, R2, R3 are in MSDP mesh group A (the core mesh In this example, R1, R2, R3 are in MSDP mesh group A (the core mesh
group) and each serves as MSDP aggregation routers for their mesh group) and each serves as MSDP aggregation routers for their leaf (or
groups 1, 2, and 3. Since SA messages received from a mesh group peer second tier) mesh groups 1, 2, and 3. Since SA messages received from
are not forwarded to peers within that same mesh group, SA messages a mesh group peer are not forwarded to peers within that same mesh
will not loop. In particular, do not create topologies which connect group, SA messages will not loop. Do not create topologies which
mesh-groups in a loop. In the above example for instance, "second connect mesh-groups in a loop. In the above example for instance,
tier" mesh-groups 1, 2, and 3 must not directly exchange SA message. second tier mesh-groups 1, 2, and 3 must not directly exchange SA
messages with each other or an endless SA loop will occur.
7.2. MSDP and Route Reflectors Redundancy, between mesh groups, will also cause a loop and is
subsequently not available with Hierarchical mesh groups. For
instance, assume R3 had two routers connecting it's 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.
BGP requires all iBGP speakers that are not route-reflector clients 3.4. MSDP and Route Reflectors
or confederation members be fully meshed. This requirement does not
scale when there are large number of iBGP speakers. In the route- or confederation members, be fully meshed to prevent loops. In
reflector environment, MSDP requires that the route reflector clients the route reflector environment, MSDP requires that the route
peer with the route reflector. For example, consider the following reflector clients peer with the route reflector since the RR is
case: 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 Ra--------RR
/|\ /|\
/ | \ / | \
A B C A B C
Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, 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, 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 iBGP next hop these RR clients will accept the SA because RR is the announcer of
for the originating RP address. the next hop to the originating RP address.
An SA will peer-RPF fail if Ra MSDP peers directly with Routers A, B, An SA will peer-RPF fail, if Ra MSDP peers directly with Routers A,
and C because the iBGP next hop for RR's clients is RR, but the SA 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's clients MSDP update came from Ra. Proper deployment is to have RR clients MSDP
peer with RR. 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.
7.3. MSDP Filtering Some recent MSDP implementations conform to the latest MSDP draft
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,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
which deploy several RPs within their domain. 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 either 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. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
5. Acknowledgments
The authors would like to thank John Zwiebel and Swapna Yelamanchi
for their feedback on earlier versions of this document.
6. Security Considerations
An MSDP service should be secured by explicitly controlling the state
which 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.
6.1. Filtering SA messages
The process of originating sa-messages should be filtered to ensure
only intended local sources are resulting in sa-message origination.
In addition, MSDP speakers should filter on which sa-messages get
received and forwarded.
Typically there is a fair amount of (S,G) state in a PIM-SM domain 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- that is local to the domain. However, without proper filtering, sa-
messages containing these local (S,G) announcements may be advertised messages containing these local (S,G) announcements may be advertised
to the global MSDP infrastructure. Examples of this includes domain to the global MSDP infrastructure. Examples of this includes domain
local applications that use global IP multicast addresses and sources local applications that use global IP multicast addresses and sources
that use RFC 1918 addresses [RFC1918]. To improve on the scalability that use RFC 1918 addresses [RFC1918]. To improve on the scalability
of MSDP and to avoid global visibility of domain local (S,G) of MSDP and to avoid global visibility of domain local (S,G)
information, the following external SA filter list is recommended to information, the following external SA filter list is recommended to
help prevent unnecessary creation, forwarding, and caching of some of help prevent unnecessary creation, forwarding, and caching of some of
these well-known ≥domain local≥ sources [IANA]. these well-known domain local sources.
224.0.0.0/4 Local application packets 224.0.0.0/4 Specific local application packets [IANA]
(packets from any application which are intended to stay 224.0.1.39 Auto-RP Announce [AUTORP]
adminstratively scoped, but use global addressing. The 224.0.1.40 Auto-RP Discovery [AUTORP]
current list of applications which could be filtered 239.0.0.0/8 Administratively Scoped IP Multicast [RFC2365]
is dynamic and subject to individual policy. See WG 10.0.0.0/8 Private addresses [RFC1918]
mail group for latest recommendations) 127.0.0.0/8 Private addresses [RFC1918]
224.0.1.39 AutoRP Announce 172.16.0.0/12 Private addresses [RFC1918]
224.0.1.40 AutoRP Discovery 192.168.0.0/16 Private addresses [RFC1918]
239.0.0.0/8 Admin. Scoped 232.0.0.0/8 Default SSM-range [SSM]
10.0.0.0/8 private addresses [RFC1918]
127.0.0.0/8 private addresses [RFC1918]
172.16.0.0/12 private addresses [RFC1918]
192.168.0.0/16 private addresses [RFC1918]
232.0.0.0/8 Default SSM-range
8. Author's Addresses 6.2. SA message state limits
Mike McBride Proper filtering on sa-message origination, receipt, and forwarding
Cisco Systems will significantly reduce the likelihood of unintended and unexpected
mcbride@cisco.com spikes in MSDP state However, a sa-cache state limit SHOULD BE be
configured as a final safeguard to state spikes.
John Meylor 7. IANA Considerations
Cisco Systems
jmeylor@cisco.com
David Meyer This document creates a no new requirements on IANA namespaces
Sprint [RFC2434].
Email: dmm@sprint.net
9. REFERENCES 8. References
[ANYCAST-RP] D. Meyer et. al, "Anycast RP mechanism using PIM and 8.1. Normative References
MSDP", draft-ietf-mboned-anycast-rp-08.txt, May, 2001.
[NICKLESS] Bill Nickless, "IPv4 Multicast Best Current Practice", [MSDP] Meyer, D. and W. Fenner (Editors), "The Multicast
draft-nickless-ipv4-mcast-bcp-01.txt, February 2002. Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-19.txt,
May 2003. Work in Progress.
[IANA] http://www.iana.org [SSM] Holbrook, H., and B. Cain, "Source-Specific
Multicast for IP", draft-ietf-ssm-arch-03.txt,
May, 2003. Work in Progress.
[MSDP] D. Meyer and Bill Fenner (Editors), "The Multicast [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway
Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-13.txt, Protocol 4 (BGP-4)", RFC 1771, March 1995.
November 2001.
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de
(BGP-4)", RFC 1771, March 1995. Groot, E. Lear, "Address Allocation for Private
Internets", RFC 1918, Feburary, 1996.
[RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, [RFC2362] D. Estrin, et. al., "Protocol Independent
"Address Allocation for Private Internets", 02/29/1996. Multicast - Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June, 1998.
[RFC2117] D. Estrin et. al, "Protocol Independent Multicast-Sparse [RFC2365] Meyer, D. "Administratively Scoped IP Multicast",
Mode (PIM-SM): Protocol Specification", RFC 2117, RFC 2365, July, 1998.
June, 1997.
[RFC2362] D. Estrin, et. al., "Protocol Independent Multicast - [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for
Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, Writing an IANA Considerations Section in
June, 1998. RFCs", RFC 2434/BCP 0026, October, 1998.
[RFC2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, "Multiprotocol [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz,
Extensions for BGP-4", RFC 2858, June 2000. "Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000.
[RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP)
Mechanism using Protocol Independent Multicast
(PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January, 2003.
8.2. Informative References
[AUTORP] Fenner, W., et. al., " Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", draft-ietf-pim-sm-v2-new-07.txt,
March, 2003. Work in Progress.
[BSR] Fenner, W., et. al., "Bootstrap Router (BSR)
Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,
February, 2003. Work in Progress.
[IANA] http://www.iana.org
9. Author's Addresses
Mike McBride
Isac Systems
Email: mcbride@cisco.com
John Meylor
Cisco Systems
Email: jmeylor@cisco.com
David Meyer
Email: dmm@maoz.com
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop- Internet organizations, except as needed for the purpose of
ing Internet standards in which case the procedures for copyrights developing Internet standards in which case the procedures for
defined in the Internet Standards process must be followed, or as copyrights defined in the Internet Standards process must be
required to translate it into languages other than English. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/