draft-ietf-mboned-msdp-deploy-01.txt   draft-ietf-mboned-msdp-deploy-02.txt 
INTERNET-DRAFT Mike McBride INTERNET-DRAFT Mike McBride
draft-ietf-mboned-msdp-deploy-01.txt John Meylor draft-ietf-mboned-msdp-deploy-02.txt John Meylor
David Meyer David Meyer
Category Best Current Practice Category Best Current Practice
Expires: November 2003 May 2003 Expires: November 2003 May 2003
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
<draft-ietf-mboned-msdp-deploy-01.txt> <draft-ietf-mboned-msdp-deploy-02.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 2, line 30 skipping to change at page 2, line 30
3. Intra-domain MSDP peering scenarios. . . . . . . . . . . . . . 7 3. Intra-domain MSDP peering scenarios. . . . . . . . . . . . . . 7
3.1. Peering between MSDP and MBGP configured routers. . . . . . 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.2. MSDP peer is not BGP peer (or no BGP peer). . . . . . . . . 8
3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 9 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 9
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. . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 12 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 12
6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References. . . . . . . . . . . . . . . . . . . 14 8.2. Informative References. . . . . . . . . . . . . . . . . . . 16
9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 15 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15 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:
o Between PIM Domains o Between PIM Domains
MSDP can be used between Protocol Independent Multicast Sparse MSDP can be used between Protocol Independent Multicast Sparse
Mode (PIM-SM) [RFC2362] domains to convey information Mode (PIM-SM) [RFC2362] domains to convey information
about active sources available in other domains. MSDP peering about active sources available in other domains. MSDP peering
skipping to change at page 4, line 8 skipping to change at page 4, line 8
Multicast (ASM) service. Multicast (ASM) service.
2. Inter-domain MSDP peering scenarios 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, a domain has it's located within a bounded PIM domain. In addition, the domain will
own Autonomous System (AS) number MBGP speakers. The domain may also typically have its own Autonomous System (AS) number and one or more
have multiple MSDP speakers. Each border router has an MSDP and MBGP MBGP speakers. The domain may also have multiple MSDP speakers. Each
peering with its peer routers. These external MSDP peering border router has an MSDP and MBGP peering with its peer routers.
deployments typically configure the MBGP peering and MSDP peering These external MSDP peering deployments typically configure the MBGP
using the same directly connected next hop peer IP address or other peering and MSDP peering using the same directly connected next hop
IP address from the same router. Typical deployments of this type are peer IP address or other IP address from the same router. Typical
providers who have a direct peering with other providers, providers deployments of this type are providers who have a direct peering with
peering at an exchange, or providers who use their edge router to other providers, providers peering at an exchange, or providers who
MSDP/MBGP peer with customers. use their edge router to 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 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
| / | /
| / | /
| / | /
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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
skipping to change at page 6, line 35 skipping to change at page 6, line 35
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 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
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 BGP 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
skipping to change at page 8, line 14 skipping to change at page 8, line 14
Where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb 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 (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 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 from MSDP peer 2.2.2.2 which is also the correct MBGP next hop for
1.1.1.1. 1.1.1.1.
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.
was MBGP peering to an address other than 2.2.2.2 on This deployment could also fail on an update from Ra to RP2 if RP2
Ra. Intra-domain deployments must have MSDP and MBGP (or other was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain
IGP) peering addresses which match, unless a method to skip the deployments must have MSDP and MBGP (or other IGP) peering addresses
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
o By configuring a default MSDP peer o By configuring a default MSDP peer
o By peering with the originating RP. o By peering with the originating RP.
o By relying upon an IGP for MSDP peer RPF 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 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 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 flooded to peers within that same mesh group. Mesh groups must be
fully meshed. fully meshed.
If recent (but not currently widely deployed) router code is running If recent (but not currently widely deployed) router code is running
which is fully complaint with the latest MSDP draft, another option, 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 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 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 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 run mesh groups, to use their existing IGP to satisfy the MSDP peer-
RPF rules. RPF rules.
3.3. Hierarchical Mesh Groups 3.3. Hierarchical Mesh Groups
Hierarchal Mesh Groups are occasionally 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 (due to the full mesh requirement) and of MSDP peerings per router (due to the full mesh requirement) and
hence reduce router load. A good hierarchical mesh group hence reduce router load. A good hierarchical mesh group
implementation (one which prevents looping) contains a core mesh implementation (one which prevents looping) contains a core mesh
skipping to change at page 9, line 45 skipping to change at page 9, line 45
group) and each serves as MSDP aggregation routers for their leaf (or 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 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 a mesh group peer are not forwarded to peers within that same mesh
group, SA messages will not loop. Do not create topologies which group, SA messages will not loop. Do not create topologies which
connect mesh-groups in a loop. In the above example for instance, 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 second tier mesh-groups 1, 2, and 3 must not directly exchange SA
messages with each other or an endless SA loop will occur. messages with each other or an endless SA loop will occur.
Redundancy, between mesh groups, will also cause a loop and is Redundancy, between mesh groups, will also cause a loop and is
subsequently not available with Hierarchical mesh groups. For subsequently not available with Hierarchical mesh groups. For
instance, assume R3 had two routers connecting it's leaf mesh group 3 instance, assume R3 had two routers connecting its leaf mesh group 3
with the core mesh group A. A loop would be created between mesh 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 group 3 and mesh group A because each mesh group must be fully meshed
between peers. between peers.
3.4. MSDP and Route Reflectors 3.4. MSDP and Route Reflectors
or confederation members, be fully meshed to prevent loops. In BGP requires all iBGP speakers, that are not route-reflector clients
the route reflector environment, MSDP requires that the route or confederation members, be fully meshed to prevent loops. In the
reflector clients peer with the route reflector since the RR is route reflector environment, MSDP requires that the route reflector
the BGP announcer of the next hop towards the originating clients peer with the route reflector since the router reflector (RR)
RP. The RR is not the BGP next hop, but is the announcer of the is the BGP announcer of the next hop towards the originating RP. The
BGP next hop. The announcer of the next hop is the address RR is not the BGP next hop, but is the announcer of the BGP next hop.
typically used for MSDP peer RPF checks. For example, consider The announcer of the next hop is the address typically used for MSDP
the following case: 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 announcer of these RR clients will accept the SA because RR is the announcer of
the next hop to the originating RP address. the next hop to the originating RP address.
skipping to change at page 11, line 10 skipping to change at page 11, line 10
the Next-Hop, in addition to the Advertiser of the next hop. In the 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 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 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. with Ra, the SA's received from Ra will now succeed.
3.5. MSDP and Anycast RPs 3.5. MSDP and Anycast RPs
A network, with multiple RPs, can achieve RP load sharing and A network, with multiple RPs, can achieve RP load sharing and
redundancy by using the Anycast RP mechanism in conjunction with MSDP redundancy by using the Anycast RP mechanism in conjunction with MSDP
mesh groups [RFC3446]. This mechanism is a common deployment mesh groups [RFC3446]. This mechanism is a common deployment
technique used within a domain by service providers and Enterprises technique used within a domain by service providers and enterprises
which deploy several RPs within their domain. These RPs will each which deploy several RPs within their domain. These RPs will each
have the same IP address configured on a Loopback interface (making have the same IP address configured on a Loopback interface (making
this the Anycast address). These RPs will MSDP peer with each other this the Anycast address). These RPs will MSDP peer with each other
using a separate loopback interface and are part of the same fully using a separate loopback interface and are part of the same fully
meshed MSDP mesh group. This loopback interface, used for MSDP meshed MSDP mesh group. This loopback interface, used for MSDP
peering, will typically also be used for the MBGP peering. All peering, will typically also be used for the MBGP peering. All
routers within the provider's domain will learn of the Anycast RP routers within the provider's domain will learn of the Anycast RP
address either through Auto-RP, BSR, or a static RP assignment. Each address either through Auto-RP, BSR, or a static RP assignment. Each
designated router in the domain will send source registers and group designated router in the domain will send source registers and group
joins to the Anycast RP address. Unicast routing will direct those joins to the Anycast RP address. Unicast routing will direct those
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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 and Swapna Yelamanchi The authors would like to thank John Zwiebel, Swapna Yelamanchi, Greg
for their feedback on earlier versions of this document. Shepherd, and Jay Ford for their feedback on earlier versions of this
document. The list of group addresses listed in section 6.1 is due to
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
of points where local policy should be applied to the MSDP service. of points where local policy should be applied to the MSDP service.
6.1. Filtering SA messages 6.1. Filtering SA messages
The process of originating sa-messages should be filtered to ensure The process of originating SA messages should be filtered to ensure
only intended local sources are resulting in sa-message origination. only intended local sources are resulting in SA message origination.
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, 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. these well-known domain local sources.
224.0.0.0/4 Specific local application packets [IANA] Group Address Use Reference
224.0.1.39 Auto-RP Announce [AUTORP] -------------------------------------------------------------------
224.0.1.40 Auto-RP Discovery [AUTORP] 224.0.0.0/24 Specific local application packets [IANA]
239.0.0.0/8 Administratively Scoped IP Multicast [RFC2365] 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] 10.0.0.0/8 Private addresses [RFC1918]
127.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] 172.16.0.0/12 Private addresses [RFC1918]
192.0.2.0/24 TEST-NET [RFC3330]
192.168.0.0/16 Private addresses [RFC1918] 192.168.0.0/16 Private addresses [RFC1918]
232.0.0.0/8 Default SSM-range [SSM]
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.
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
[MSDP] Meyer, D. and W. Fenner (Editors), "The Multicast [MSDP] Meyer, D. and W. Fenner (Editors), "The Multicast
Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-19.txt, Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-20.txt,
May 2003. Work in Progress. May 2003. Work in Progress.
[SSM] Holbrook, H., and B. Cain, "Source-Specific [SSM] Holbrook, H., and B. Cain, "Source-Specific
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
skipping to change at page 14, line 38 skipping to change at page 15, line 38
[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.
[RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, "Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000. June 2000.
[RFC3330] IANA, "Special-User IPv4 Addresses", RFC 3330,
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.
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
 End of changes. 

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