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.
Some recent MSDP implementations conform to the latest MSDP document,
which relaxes the requirement of peering with the Advertiser of the
next hop (the Route Reflector). This new rule allows for peering
with the next hop, in addition to the Advertiser of the next hop. In
the example above, for instance, if Ra is the next hop (perhaps due
to using BGP’s next hop self attribute), and if routers A, B, and C
are peering with Ra, the SA’s received from Ra will now succeed.
3.5. MSDP and Anycast RPs
A network with multiple RPs can achieve RP load sharing and
redundancy by using the Anycast RP mechanism in conjunction with MSDP
mesh groups [RFC3446]. This mechanism is a common deployment
technique used within a domain by service providers and enterprises
that deploy several RPs within their domains. These RPs will each
have the same IP address configured on a Loopback interface (making
this the Anycast address). These RPs will MSDP peer with each other
using a separate loopback interface and are part of the same fully
meshed MSDP mesh group. This loopback interface, used for MSDP
peering, will typically also be used for the MBGP peering. All
routers within the provider’s domain will learn of the Anycast RP
address through Auto-RP, BSR, or a static RP assignment. Each
designated router in the domain will send source registers and group
joins to the Anycast RP address. Unicast routing will direct those
registers and joins to the nearest Anycast RP. If a particular
Anycast RP router fails, unicast routing will direct subsequent
registers and joins to the nearest Anycast RP. That RP will then
forward an MSDP update to all peers within the Anycast MSDP mesh
group. Each RP will then forward (or receive) the SAs to (from)
external customers and providers.
4. Security Considerations
An MSDP service should be secured by explicitly controlling the state
that is created by, and passed within, the MSDP service. As with
unicast routing state, MSDP state should be controlled locally, at
the edge origination points. Selective filtering at the multicast
service edge helps ensure that only intended sources result in SA
message creation, and this control helps to reduce the likelihood of
state-aggregation related problems in the core. There are a variety
of points where local policy should be applied to the MSDP service.
4.1. Filtering SA Messages
The process of originating SA messages should be filtered to ensure
that only intended local sources are resulting in SA message
origination. In addition, MSDP speakers should filter which SA
messages get received and forwarded.
Typically, there is a fair amount of (S,G) state in a PIM-SM domain
that is local to the domain. However, without proper filtering, SA
messages containing these local (S,G) announcements may be advertised
to the global MSDP infrastructure. Examples of this include domain-
local applications that use global IP multicast addresses and sources
that use RFC 1918 addresses [RFC1918]. To improve on the scalability
of MSDP and to avoid global visibility of domain local (S,G)
information, an external SA filter list is recommended to help
prevent unnecessary creation, forwarding, and caching of well-known
domain local sources.
4.2. SA Message State Limits
Proper filtering on SA message origination, receipt, and forwarding
will significantly reduce the likelihood of unintended and unexpected
spikes in MSDP state. However, an SA-cache state limit SHOULD be
configured as a final safeguard to state spikes. When an MSDP
peering has reached a stable state (i.e., when the peering has been
established and the initial SA state has been transferred), it may
also be desirable to configure a rate limiter for the creation of new
SA state entries.
5. Acknowledgements
The authors would like to thank Pekka Savola, John Zwiebel, Swapna
Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier
versions of this document.
6. References
6.1. Normative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January 2003.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
6.2. Informative References
[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for
PIM Sparse Mode", Work in Progress, February 2003.
[RFCED] http://www.rfc-editor.org/policy.html
Authors’ Addresses
Mike McBride
Cisco Systems
EMail: mcbride@cisco.com
John Meylor
Cisco Systems
EMail: jmeylor@cisco.com
David Meyer
EMail: dmm@1-4-5.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).