draft-ietf-mboned-msdp-deploy-03.txt   draft-ietf-mboned-msdp-deploy-04.txt 
INTERNET-DRAFT Mike McBride
draft-ietf-msdp-deploy-03.txt John Meylor INTERNET-DRAFT M. McBride
David Meyer draft-ietf-msdp-deploy-04.txt J. Meylor
D. Meyer
Category Best Current Practice Category Best Current Practice
Expires: January 2004 July 2003 Expires: April 2004 October 2003
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
<draft-ietf-mboned-msdp-deploy-03.txt> <draft-ietf-mboned-msdp-deploy-04.txt>
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes best current practices for intra-domain and
inter-domain deployment of the Multicast Source Discovery Protocol
(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
(PIM-SM).
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 38 skipping to change at page 2, line 39
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.
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
This document is a product of the MBONED Working Group. Comments This document is a product of the MBONED Working Group. Comments
should be addressed to the authors, or the mailing list at should be addressed to the authors, or the mailing list at
mboned@ns.uoregon.edu. mboned@lists.uoregon.edu.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes best current practices for intra-domain and
inter-domain deployment of the Multicast Source Discovery Protocol
(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
(PIM-SM).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 4 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 5
2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 4 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 5
2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 5 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 6
2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 7 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 8
2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 7 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 8
3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 8 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 9
3.1. Peering between MSDP and MBGP Configured 3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 9
Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 10
3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 9 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 11
3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 10 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 11
3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 10 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 12
3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 13
4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 5.2. SA message state limits . . . . . . . . . . . . . . . . . . 14
6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14
6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References. . . . . . . . . . . . . . . . . . . 17
8.2. Informative References. . . . . . . . . . . . . . . . . . . 16 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 17
9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 17
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 12, line 40 skipping to change at page 13, line 40
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
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. Security Considerations
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. 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 5.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, an external SA filter list is recommended to help information, an external SA filter list is recommended to help
prevent unnecessary creation, forwarding, and caching of well-known prevent unnecessary creation, forwarding, and caching of well-known
domain local sources [UNUSABLE]. domain local sources [UNUSABLE].
6.2. SA message state limits 5.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
configured as a final safeguard to state spikes. When an MSDP peering configured as a final safeguard to state spikes. When an MSDP peering
has reached a stable state (i.e., when the peering has been has reached a stable state (i.e., when the peering has been
established and the initial SA state has been transferred), it may established and the initial SA state has been transferred), it may
also be desirable to configure a rate limiter for the creation of new also be desirable to configure a rate limiter for the creation of new
SA state entries. SA state entries.
7. IANA Considerations 6. IANA Considerations
This document creates a no new requirements on IANA namespaces This document creates a no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
7. Acknowledgments
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.
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-20.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
 End of changes. 

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