--- 1/draft-ietf-mboned-msdp-deploy-03.txt 2006-02-05 00:20:30.000000000 +0100 +++ 2/draft-ietf-mboned-msdp-deploy-04.txt 2006-02-05 00:20:30.000000000 +0100 @@ -1,18 +1,30 @@ -INTERNET-DRAFT Mike McBride -draft-ietf-msdp-deploy-03.txt John Meylor - David Meyer + +INTERNET-DRAFT M. McBride +draft-ietf-msdp-deploy-04.txt J. Meylor + D. Meyer Category Best Current Practice -Expires: January 2004 July 2003 +Expires: April 2004 October 2003 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios - + + +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 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -27,59 +39,47 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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 (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). + mboned@lists.uoregon.edu. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 4 - 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 4 - 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 5 - 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 7 - 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 7 - 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 8 - 3.1. Peering between MSDP and MBGP Configured - Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 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.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 11 - 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 12 - 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 - 6.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 13 - 6.2. SA message state limits . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 15 - 8.2. Informative References. . . . . . . . . . . . . . . . . . . 16 - 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 16 - 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 16 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 5 + 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 5 + 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 6 + 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 8 + 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 8 + 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 9 + 3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 9 + 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 10 + 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 11 + 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 11 + 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 12 + 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 13 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 + 5.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 14 + 5.2. SA message state limits . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 + 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 16 + 8.2. Informative References. . . . . . . . . . . . . . . . . . . 17 + 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 17 + 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 17 1. Introduction MSDP [MSDP] is used primarily in two deployment scenarios: o Between PIM Domains MSDP can be used between Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC2362] domains to convey information about active sources available in other domains. MSDP peering @@ -486,71 +486,71 @@ obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. -5. Acknowledgments - - The authors would like to thank Pekka Savola, John Zwiebel, Swapna - Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier - versions of this document. - -6. Security Considerations +5. Security Considerations An MSDP service should be secured by explicitly controlling the state which is created by, and passed within, the MSDP service. As with unicast routing state, MSDP state should be controlled locally, at the edge origination points. Selective filtering at the multicast service edge helps ensure that only intended sources result in SA message creation, and this control helps to reduce the likelihood of state-aggregation related problems in the core. There are a variety of points where local policy should be applied to the MSDP service. -6.1. Filtering SA messages +5.1. Filtering SA messages The process of originating SA messages should be filtered to ensure only intended local sources are resulting in SA message origination. In addition, MSDP speakers should filter on which SA messages get received and forwarded. Typically there is a fair amount of (S,G) state in a PIM-SM domain 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 includes 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 [UNUSABLE]. -6.2. SA message state limits +5.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, 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 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 +6. IANA Considerations This document creates a no new requirements on IANA namespaces [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.1. Normative References [MSDP] Meyer, D. and W. Fenner (Editors), "The Multicast Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-20.txt, May 2003. Work in Progress. [SSM] Holbrook, H., and B. Cain, "Source-Specific Multicast for IP", draft-ietf-ssm-arch-03.txt,