draft-ietf-mboned-msdp-deploy-02.txt   draft-ietf-mboned-msdp-deploy-03.txt 
INTERNET-DRAFT Mike McBride INTERNET-DRAFT Mike McBride
draft-ietf-mboned-msdp-deploy-02.txt John Meylor draft-ietf-msdp-deploy-03.txt John Meylor
David Meyer David Meyer
Category Best Current Practice Category Best Current Practice
Expires: November 2003 May 2003 Expires: January 2004 July 2003
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
<draft-ietf-mboned-msdp-deploy-02.txt> <draft-ietf-mboned-msdp-deploy-03.txt>
Status of this Document 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 RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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.
This document is a product of an individual. Comments are solicited The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
and should be addressed to the author(s). "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
This document is a product of the MBONED Working Group. Comments
should be addressed to the authors, or the mailing list at
mboned@ns.uoregon.edu.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes best current practices for intra-domain and This document describes best current practices for intra-domain and
inter-domain deployment of the Multicast Source Discovery Protocol inter-domain deployment of the Multicast Source Discovery Protocol
(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
(PIM-SM). (PIM-SM).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Inter-domain MSDP peering scenarios. . . . . . . . . . . . . . 3 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 4
2.1. Peering between PIM border routers. . . . . . . . . . . . . 4 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 4
2.2. Peering between non border routers. . . . . . . . . . . . . 5 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 5
2.3. MSDP peering without BGP. . . . . . . . . . . . . . . . . . 6 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 7
2.4. MSDP peering at a Multicast Exchange. . . . . . . . . . . . 7 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 7
3. Intra-domain MSDP peering scenarios. . . . . . . . . . . . . . 7 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 8
3.1. Peering between MSDP and MBGP configured routers. . . . . . 7 3.1. Peering between MSDP and MBGP Configured
3.2. MSDP peer is not BGP peer (or no BGP peer). . . . . . . . . 8 Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 9 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 9
3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 10
3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 10 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 10
3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11
4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 11 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 12 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 13
6.2. SA message state limits . . . . . . . . . . . . . . . . . . 14 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References. . . . . . . . . . . . . . . . . . . 16 8.2. Informative References. . . . . . . . . . . . . . . . . . . 16
9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
MSDP [MSDP] is used primarily in two deployment scenarios: MSDP [MSDP] is used primarily in two deployment scenarios:
skipping to change at page 3, line 41 skipping to change at page 3, line 41
one-to-one peering with MSDP peers outside that PIM domain for one-to-one peering with MSDP peers outside that PIM domain for
discovery of external sources. MSDP for anycast-RP without discovery of external sources. MSDP for anycast-RP without
external MSDP peering is a valid deployment option and common. external MSDP peering is a valid deployment option and common.
Current best practice for MSDP deployment utilizes PIM-SM and the Current best practice for MSDP deployment utilizes PIM-SM and the
Border Gateway Protocol with multi-protocol extensions (MBGP) Border Gateway Protocol with multi-protocol extensions (MBGP)
[RFC1771, RFC2858]. This document outlines how these protocols work [RFC1771, RFC2858]. This document outlines how these protocols work
together to provide an intra-domain and inter-domain Any Source together to provide an intra-domain and inter-domain Any Source
Multicast (ASM) service. Multicast (ASM) service.
2. Inter-domain MSDP peering scenarios 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 to set 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.
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, one can
use internal multicast groups which are not visible to the provider's
RP. This helps with internal multicast being able to continue to work
in the event there is a problem with connectivity to the provider or
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.
2. Inter-domain MSDP Peering Scenarios
The following sections describe the most common inter-domain MSDP The following sections describe the most common inter-domain MSDP
peering possibilities and their deployment options. peering possibilities and their deployment options.
2.1. Peering between PIM border routers 2.1. Peering between PIM Border Routers
In this case, the MSDP peers within the domain 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, the domain will located within a bounded PIM domain. In addition, the domain will
typically have its own Autonomous System (AS) number and one or more typically have its own Autonomous System (AS) number and one or more
MBGP speakers. The domain may also have multiple MSDP speakers. Each MBGP speakers. The domain may also have multiple MSDP speakers. Each
border router has an MSDP and MBGP peering with its peer routers. border router has an MSDP and MBGP peering with its peer routers.
These external MSDP peering deployments typically configure the MBGP These external MSDP peering deployments typically configure the MBGP
peering and MSDP peering using the same directly connected next hop peering and MSDP peering using the same directly connected next hop
peer IP address or other IP address from the same router. Typical peer IP address or other IP address from the same router. Typical
deployments of this type are providers who have a direct peering with deployments of this type are providers who have a direct peering with
skipping to change at page 4, line 29 skipping to change at page 5, line 4
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 MBGP best path to the originating RP should be 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 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 a Source Active (SA) message, originated 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 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 first hop AS from AS4, in the best path to the originating RP, is
AS2. The origin AS of the sending MSDP peer is also AS2. In this AS2. The AS of the sending MSDP peer is also AS2. In this case, the
case, the peer-Reverse Path Forwarding check (peer-RPF check) passes peer-Reverse Path Forwarding check (peer-RPF check) passes and the SA
and the SA message is forwarded. message is forwarded.
A peer-RPF failure would occur in this topology when the MBGP first 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 while the hop AS, in the best path to the originating RP, is AS2 while the
origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS
PATH information prevents endless looping of SA packets. PATH information prevents endless looping of SA packets.
Router code, which has adopted the latest rules in the MSDP draft, 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 will relax the rules Between AS's a bit. In the following topology we
have an MSDP peering between AS1<->AS3 and AS3<->AS4: have an MSDP peering between AS1<->AS3 and AS3<->AS4:
skipping to change at page 5, line 4 skipping to change at page 5, line 22
hop AS, in the best path to the originating RP, is AS2 while the hop AS, in the best path to the originating RP, is AS2 while the
origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS
PATH information prevents endless looping of SA packets. PATH information prevents endless looping of SA packets.
Router code, which has adopted the latest rules in the MSDP draft, 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 will relax the rules Between AS's a bit. In the following topology we
have an MSDP peering between AS1<->AS3 and AS3<->AS4: have an MSDP peering between AS1<->AS3 and AS3<->AS4:
RP RP
AS1----AS2----AS3----AS4 AS1----AS2----AS3----AS4
If the first AS in best path to the RP does not equal the MSDP peer, 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 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 the first AS in the MBGP best path to AS4 RP. With the latest MSDP
draft compliant code, AS 1 will choose the peer in the closest AS 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 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, 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. the peer with the highest IP address is chosen as the RPF peer.
2.2. Peering between non border routers 2.2. Peering between Non-Border Routers
When MSDP peering between border routers, intra-domain MSDP When MSDP peering between border routers, intra-domain MSDP
scalability is restricted because it is necessary to also maintain scalability is restricted because it is necessary to also maintain
MBGP and MSDP peerings internally towards their border routers. MBGP and MSDP peerings internally towards their border routers.
Within the intra-domain, the border router becomes the announcer of Within the intra-domain, the border router becomes the announcer of
the next hop towards the originating RP. This requires that all the next hop towards the originating RP. This requires that all
intra-domain MSDP peerings must mirror the MBGP path back towards the intra-domain MSDP peerings must mirror the MBGP path back towards the
border router. External MSDP (eMSDP) peerings rely upon AS path for border router. External MSDP (eMSDP) peerings rely upon AS path for
peer rpf checking, while internal MSDP (iMSDP) peerings rely upon the peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the
announcer of the next hop. announcer of the next hop.
While the eMBGP peer is typically directly connected between border While the eMBGP peer is typically directly connected between border
routers, it is common for the eMSDP peer to be located deeper into routers, it is common for the eMSDP peer to be located deeper into
the transit providers AS. Providers, which desire more flexibility in the transit providers AS. Providers, which desire more flexibility in
MSDP peering placement, commonly choose a few dedicated routers 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 group and configured for Anycast RP. providers intra-domain MSDP mesh group and configured for Anycast RP.
All multicast routers in the providers AS should statically point to All multicast routers in the providers AS should statically point to
the Anycast RP address. Static RP assignment is the most commonly the Anycast RP address. Static RP assignment is the most commonly
used method for group to RP mapping due to its deterministic nature. used method for group to RP mapping due to its deterministic nature.
Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP Auto-RP [AUTORP] and/or the Bootstrap Router (BSR) [BSR] dynamic RP
mapping mechanisms could be also used to disseminate RP information mapping mechanisms could be also used to disseminate RP information
within the provider's network 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, we rely upon the next (or closest, with latest MSDP environment, we rely upon the next (or closest, with latest MSDP
spec) AS in the best path towards originating RP for the rpf check. spec) AS in the best path towards originating RP for the RPF check.
The MSDP peer address should be in the same AS as the AS of the The MSDP peer address should be in the same AS as the AS of the
border routers MBGP peer. The MSDP peer address should be advertised border router's MBGP peer. The MSDP peer address should be advertised
via MBGP. via MBGP.
For example, using the diagram below, if customer R1 router is MBGP 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 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 R2 and R3 must be in the same AS (or appear, to AS1, to be from the
address will be chosen as the MSDP RPF peer. R1 must also have the same AS in the event private AS numbers are deployed). The MSDP peer
MSDP peer address of R3 in its MBGP table. 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
From R3's perspective, AS1 (R1) is the MBGP next AS in the best path 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 towards the originating RP. As long as AS1 is the next AS (or
closest) in the best path towards the originating RP, RPF will closest) in the best path towards the originating RP, RPF will
succeed on SAs arriving from R1. succeed on SAs arriving from R1.
In contrast, with the single hop scenario, with R2 (instead of R3) In contrast, with the single hop scenario, with R2 (instead of R3)
border MSDP peering with R1 border, R2s MBGP address becomes the 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 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 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 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 has a dependence upon peering with the address of the MBGP (or other
IGP) announcer of the next hop. IGP) announcer of the next hop.
2.3. MSDP peering without BGP 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.
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 which allows for an MSDP peer-RPF
check using an IGP
These cases are 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, the originating RP default peer (default MSDP route) is configured, the originating RP
is directly connected, a mesh group is used, or an implementation is is directly connected, a mesh group is used, or an implementation is
used which allows for an MSDP peer-RPF check using an IGP. used which allows for an MSDP peer-RPF check using an IGP.
An enterprise will typically configure a unicast default route from 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 MSDP 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. If only a single MSDP peering was used (no sources can be advertised. If only a single MSDP peering was used (no
internal MSDP peerings) towards the provider, then this stub site internal MSDP peerings) towards the provider, then this stub site
will MSDP default peer towards the provider and skip the peer-RPF will MSDP default peer towards the provider and skip the peer-RPF
check. check.
2.4. 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 (or by using point to point virtual LANs) and share MSDP SA subnet (or by using point to point virtual LANs) and share MSDP SA
updates. Each provider will MSDP and MBGP peer with each others updates. Each provider will MSDP and MBGP peer with each others
directly connected exchange IP address. Each exchange router will directly connected exchange IP address. Each exchange router will
send/receive SAs to/from their MSDP peers. They will then be able to 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 forward SAs throughout their domain to their customers and any direct
provider peerings. provider peerings.
3. 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.
3.1. Peering between MSDP and MBGP configured routers 3.1. Peering between MSDP and MBGP Configured Routers
The next hop IP address of the iBGP peer is typically used for the 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 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 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 the peer-RPF check. For this reason, it is necessary for the IP
address of the MSDP peer connection be the same as the internal MBGP address of the MSDP peer connection be the same as the internal MBGP
peer connection whether or not the MSDP/MBGP peers are directly peer connection whether or not the MSDP/MBGP peers are directly
connected. A successful deployment would be similar to the following: connected. A successful deployment would be similar to the following:
+----+ +----+
skipping to change at page 8, line 19 skipping to change at page 9, line 11
When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP 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 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 could also fail on an update from Ra to RP2 if RP2 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 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 deployments must have MSDP and MBGP (or other IGP) peering addresses
which match, unless a method to skip the peer-RPF check is deployed. which match, unless a method to skip the peer-RPF check is deployed.
3.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 MBGP or where the domain is not running MBGP. 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 MBGP 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 the following topologies: domain MSDP RPF rules have been relaxed in the following topologies:
o By configuring the MSDP peer as a mesh group 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 having the MSDP peer be the only MSDP peer
skipping to change at page 12, line 7 skipping to change at page 12, line 42
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
5. Acknowledgments 5. Acknowledgments
The authors would like to thank John Zwiebel, Swapna Yelamanchi, Greg The authors would like to thank Pekka Savola, John Zwiebel, Swapna
Shepherd, and Jay Ford for their feedback on earlier versions of this Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier
document. The list of group addresses listed in section 6.1 is due to versions of this document.
Bill Nickless.
6. Security Considerations 6. Security Considerations
An MSDP service should be secured by explicitly controlling the state An MSDP service should be secured by explicitly controlling the state
which is created by, and passed within, the MSDP service. As with which is created by, and passed within, the MSDP service. As with
unicast routing state, MSDP state should be controlled locally, at unicast routing state, MSDP state should be controlled locally, at
the edge origination points. Selective filtering at the multicast the edge origination points. Selective filtering at the multicast
service edge helps ensure that only intended sources result in SA service edge helps ensure that only intended sources result in SA
message creation, and this control helps to reduce the likelihood of message creation, and this control helps to reduce the likelihood of
state-aggregation related problems in the core. There are a variety state-aggregation related problems in the core. There are a variety
skipping to change at page 12, line 37 skipping to change at page 13, line 30
In addition, MSDP speakers should filter on which SA messages get In addition, MSDP speakers should filter on which SA messages get
received and forwarded. 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, an external SA filter list is recommended to help
help prevent unnecessary creation, forwarding, and caching of some of prevent unnecessary creation, forwarding, and caching of well-known
these well-known domain local sources. domain local sources [UNUSABLE].
Group Address Use Reference
-------------------------------------------------------------------
224.0.0.0/24 Specific local application packets [IANA]
224.0.1.22/32 SVRLOC
224.0.1.22/32 Microsoft-DS
224.0.1.35/32 SVRLOC-DA
224.0.1.39/32 CISCO-RP-ANNOUNCE [AUTORP]
224.0.1.40/32 CISCO-RP-DISCOVERY [AUTORP]
224.0.2.2/32 SUN-RPC
224.77.0.0/16 Norton Ghost
224.128.0.0/24 Control plane of IGMP snoopers
225.0.0.0/24 Control plane of IGMP snoopers
225.1.2.3/32 Altiris
225.128.0.0/24 Control plane of IGMP snoopers
226.0.0.0/24 Control plane of IGMP snoopers
226.77.0.0/16 Norton Ghost
226.128.0.0/24 Control plane of IGMP snoopers
227.0.0.0/24 Control plane of IGMP snoopers
227.128.0.0/24 Control plane of IGMP snoopers
228.0.0.0/24 Control plane of IGMP snoopers
228.128.0.0/24 Control plane of IGMP snoopers
229.0.0.0/24 Control plane of IGMP snoopers
229.128.0.0/24 Control plane of IGMP snoopers
230.0.0.0/24 Control plane of IGMP snoopers
230.128.0.0/24 Control plane of IGMP snoopers
231.0.0.0/24 Control plane of IGMP snoopers
231.128.0.0/24 Control plane of IGMP snoopers
232.0.0.0/24 Control plane of IGMP snoopers
232.128.0.0/24 Control plane of IGMP snoopers
233.0.0.0/8 Source-Specific Multicast [SSM]
233.0.0.0/24 Control plane of IGMP snoopers
233.128.0.0/24 Control plane of IGMP snoopers
234.0.0.0/24 Control plane of IGMP snoopers
234.42.42.42/32 Phoenix/StorageSoft ImageCast
234.128.0.0/24 Control plane of IGMP snoopers
234.142.142.42/31 Phoenix/StorageSoft ImageCast
234.142.142.44/30 Phoenix/StorageSoft ImageCast
234.142.142.48/28 Phoenix/StorageSoft ImageCast
234.142.142.64/26 Phoenix/StorageSoft ImageCast
234.142.142.128/29 Phoenix/StorageSoft ImageCast
234.142.142.136/30 Phoenix/StorageSoft ImageCast
234.142.142.140/31 Phoenix/StorageSoft ImageCast
234.142.142.142/32 Phoenix/StorageSoft ImageCast
235.0.0.0/24 Control plane of IGMP snoopers
235.128.0.0/24 Control plane of IGMP snoopers
236.0.0.0/24 Control plane of IGMP snoopers
236.128.0.0/24 Control plane of IGMP snoopers
237.0.0.0/24 Control plane of IGMP snoopers
Group Address Use Reference
-------------------------------------------------------------------
237.128.0.0/24 Control plane of IGMP snoopers
238.0.0.0/24 Control plane of IGMP snoopers
238.128.0.0/24 Control plane of IGMP snoopers
239.0.0.0/8 Administratively Scoped Groups [RFC2365]
239.0.0.0/24 Control plane of IGMP snoopers
239.128.0.0/24 Control plane
Source Address Use Reference
-------------------------------------------------------------------
0.0.0.0/32 Any/This/Default [RFC3330]
10.0.0.0/8 Private addresses [RFC1918]
127.0.0.0/8 Loopback addresses [RFC1918]
169.254.0.0/16 DHCP auto-config local-use [RFC3330]
172.16.0.0/12 Private addresses [RFC1918]
192.0.2.0/24 TEST-NET [RFC3330]
192.168.0.0/16 Private addresses [RFC1918]
6.2. SA message state limits 6.2. SA message state limits
Proper filtering on SA message origination, receipt, and forwarding Proper filtering on SA message origination, receipt, and forwarding
will significantly reduce the likelihood of unintended and unexpected will significantly reduce the likelihood of unintended and unexpected
spikes in MSDP state However, a sa-cache state limit SHOULD BE be spikes in MSDP state However, a sa-cache state limit SHOULD BE be
configured as a final safeguard to state spikes. 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.
7. IANA Considerations 7. IANA Considerations
This document creates a no new requirements on IANA namespaces This document creates a no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 15, line 24 skipping to change at page 15, line 24
Multicast for IP", draft-ietf-ssm-arch-03.txt, Multicast for IP", draft-ietf-ssm-arch-03.txt,
May, 2003. Work in Progress. May, 2003. Work in Progress.
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway
Protocol 4 (BGP-4)", RFC 1771, March 1995. Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de
Groot, E. Lear, "Address Allocation for Private Groot, E. Lear, "Address Allocation for Private
Internets", RFC 1918, Feburary, 1996. Internets", RFC 1918, Feburary, 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels" RFC 2119/BCP 14,
March 1997.
[RFC2362] D. Estrin, et. al., "Protocol Independent [RFC2362] D. Estrin, et. al., "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Multicast - Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June, 1998. Specification", RFC 2362, June, 1998.
[RFC2365] Meyer, D. "Administratively Scoped IP Multicast", [RFC2365] Meyer, D. "Administratively Scoped IP Multicast",
RFC 2365, July, 1998. RFC 2365, July, 1998.
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in Writing an IANA Considerations Section in
RFCs", RFC 2434/BCP 0026, October, 1998. RFCs", RFC 2434/BCP 0026, October, 1998.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
June 2000. June 2000.
[RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330, [RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330,
September 2002. September 2002.
[RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP)
Mechanism using Protocol Independent Multicast Mechanism using Protocol Independent Multicast
(PIM) and Multicast Source Discovery Protocol (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January, 2003. (MSDP)", RFC 3446, January, 2003.
[UNUSABLE] Nickless, B., "IPv4 Multicast Unusable Group And
Source Addresses", draft-nickless-ipv4-mcast-unusable-02.txt,
June, 2003. Work in Progress.
8.2. Informative References 8.2. Informative References
[AUTORP] Fenner, W., et. al., " Protocol Independent [AUTORP] Fenner, W., et. al., " Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", draft-ietf-pim-sm-v2-new-07.txt, Specification (Revised)", draft-ietf-pim-sm-v2-new-07.txt,
March, 2003. Work in Progress. March, 2003. Work in Progress.
[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) [BSR] Fenner, W., et. al., "Bootstrap Router (BSR)
Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,
February, 2003. Work in Progress. February, 2003. Work in Progress.
[IANA] http://www.iana.org [IANA] http://www.iana.org
9. Author's Addresses 9. Author's Addresses
Mike McBride Mike McBride
Isac Systems Cisco Systems
Email: mcbride@cisco.com Email: mcbride@cisco.com
John Meylor John Meylor
Cisco Systems Cisco Systems
Email: jmeylor@cisco.com Email: jmeylor@cisco.com
David Meyer David Meyer
Email: dmm@maoz.com Email: dmm@1-4-5.net
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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
 End of changes. 

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