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/