draft-ietf-mboned-msdp-deploy-05.txt		draft-ietf-mboned-msdp-deploy-06.txt
	INTERNET-DRAFT M. McBride		INTERNET-DRAFT M. McBride
	draft-ietf-msdp-deploy-05.txt J. Meylor		J. Meylor
	D. Meyer		D. Meyer
	Category Best Current Practice		Category Best Current Practice
	Expires: July 2004 January 2004		Expires: September 2004 March 2004
	Multicast Source Discovery Protocol (MSDP) Deployment Scenarios		Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
	<draft-ietf-mboned-msdp-deploy-05.txt>		<draft-ietf-mboned-msdp-deploy-06.txt>
	Copyright Notice
	Copyright (C) The Internet Society (2004). 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 2, line 33		skipping to change at page 1, line 33
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	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",
	"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		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@lists.uoregon.edu.		mboned@lists.uoregon.edu.
			Copyright Notice
			Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 5		1.1. BCP, Experimental Protocols and Normative References. . . . 5
	2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 5		2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 6
	2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 6		2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 7
	2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 8		2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 8
	2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 8		2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 9
	3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 9		2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 10
	3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 9		3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 10
	3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 10		3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 10
	3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 11		3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 11
	3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 11		3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 12
	3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 12		3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 13
	4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 13		3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 14
	5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13		4. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
	5.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 14		4.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 15
	5.2. SA message state limits . . . . . . . . . . . . . . . . . . 14		4.2. SA message state limits . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
	7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15		6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References. . . . . . . . . . . . . . . . . . . . 16		7.1. Normative References. . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References. . . . . . . . . . . . . . . . . . . 17		7.2. Informative References. . . . . . . . . . . . . . . . . . . 18
	9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 17		8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 18
	10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 17		9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
			10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 19
			11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	MSDP [RFC3618] is used primarily in two deployment scenarios:		MSDP [RFC3618] 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) [PIM-SM] domains to convey information
	about active sources available in other domains. MSDP peering		about active sources available in other domains. MSDP peering
	used in such cases is generally one to one peering, and		used in such cases is generally one to one peering, and
	utilizes the deterministic peer-RPF (Reverse Path Forwarding)		utilizes the deterministic peer-RPF (Reverse Path Forwarding)
	rules described in the MSDP specification (i.e., does not use		rules described in the MSDP specification (i.e., does not use
	mesh-groups). Peerings can be aggregated on a single MSDP		mesh-groups). Peerings can be aggregated on a single MSDP
	peer. Such a peer can typically have from one to hundreds of		peer. Such a peer can typically have from one to hundreds of
	peerings, which is similar in scale to BGP peerings.		peerings, which is similar in scale to BGP peerings.
	o Within a PIM Domain		o Within a PIM Domain
	skipping to change at page 4, line 41		skipping to change at page 4, line 41
	one-to-one peering with MSDP peers outside that PIM domain for		one-to-one peering with MSDP peers outside that PIM domain for
	discovery of external sources. MSDP for anycast-RP without		discovery of external sources. MSDP for anycast-RP without
	external MSDP peering is a valid deployment option and common.		external MSDP peering is a valid deployment option and common.
	Current best practice for MSDP deployment utilizes PIM-SM and the		Current best practice for MSDP deployment utilizes PIM-SM and the
	Border Gateway Protocol with multi-protocol extensions (MBGP)		Border Gateway Protocol with multi-protocol extensions (MBGP)
	[RFC1771, RFC2858]. This document outlines how these protocols work		[RFC1771, RFC2858]. This document outlines how these protocols work
	together to provide an intra-domain and inter-domain Any Source		together to provide an intra-domain and inter-domain Any Source
	Multicast (ASM) service.		Multicast (ASM) service.
	Multicast (ASM) service. The PIM-SM specification assumes that SM		The PIM-SM specification assumes that SM operates only in one PIM
	operates only in one PIM domain. MSDP is used to enable the use of		domain. MSDP is used to enable the use of multiple PIM domains by
	multiple PIM domains by distributing the required information about		distributing the required information about active multicast sources
	active multicast sources to other PIM domains. Due to breaking the		to other PIM domains. Due to breaking the Internet multicast
	Internet multicast infrastructure down to multiple PIM domains, MSDP		infrastructure down to multiple PIM domains, MSDP also enables the
	also enables the possibility to set policy on the visibility of the		possibility to set policy on the visibility of the groups and
	groups and sources.		sources.
	Transit IP providers typically deploy MSDP to be part of the global		Transit IP providers typically deploy MSDP to be part of the global
	multicast infrastructure by connecting to their upstream and peer		multicast infrastructure by connecting to their upstream and peer
	multicast networks using MSDP.		multicast networks using MSDP.
	Edge multicast networks typically have two choices: to use their		Edge multicast networks typically have two choices: to use their
	Internet providers RP, or to have their own RP and connect it to		Internet providers RP, or to have their own RP and connect it to
	their ISP using MSDP. By deploying their own RP and MSDP, one can		their ISP using MSDP. By deploying their own RP and MSDP, one can
	use internal multicast groups which are not visible to the provider's		use internal multicast groups which are not visible to the provider's
	RP. This helps with internal multicast being able to continue to work		RP. This helps with internal multicast being able to continue to work
	in the event there is a problem with connectivity to the provider or		in the event there is a problem with connectivity to the provider or
	the provider's RP/MSDP is experiencing difficulties. In the simplest		the provider's RP/MSDP is experiencing difficulties. In the simplest
	cases where no internal multicast groups are necessary, there is		cases where no internal multicast groups are necessary, there is
	often no need to deploy MSDP.		often no need to deploy MSDP.
			1.1. BCP, Experimental Protocols and Normative References
			This document describes the best current practice for a widely
			deployed Experimental protocol, MSDP. There is no plan to advance the
			MSDP's status (for example, to Proposed Standard). The reasons for
			this include:
			o MSDP was originally envisioned as a temporary protocol to be
			supplanted by whatever the IDMR working group produced as an
			inter-domain protocol. However, the IDMR WG (or subsequently,
			the BGMP WG) never produced a protocol that could be deployed
			to replace MSDP.
			o One of the primary reasons given for MSDP to be classified as
			Experimental was that the MSDP Working Group came up with
			modifications to the protocol that the WG thought made it
			better but that implementors didn't see any reasons to
			deploy. Without these modifications (e.g., UDP or GRE
			encapsulation), MSDP can have negative consequences to initial
			packets in datagram streams.
			o Scalability: Although we don't know what the hard limits might
			be, readvertising everything you know every 60 seconds clearly
			limits the amount of state you can advertise.
			o MSDP reached near ubiquitous deployment as the de-facto
			standard inter-domain multicast protocol in the IPv4 Internet.
			o No consensus could be reached regarding the reworking of MSDP
			to address the many concerns of various constituencies within
			the IETF. As a result, a decision was taken to document what is
			(ubiquitously) deployed and move that document to Experimental.
			While advancement of MSDP to Proposed Standard was considered,
			for the reasons mentioned above, it was immediately discarded.
			o The advent of protocols such as source specific multicast and
			bi-directional PIM, as well as embedded RP techniques for
			IPv6, have further reduced consensus that a replacement
			protocol for MSDP for the IPv4 Internet is required.
			The RFC Editor's policy regarding references is that they be split
			into two categories known as "normative" and "informative". Normative
			references specify those documents which must be read to understand
			or implement the technology in an RFC (or whose technology must be
			present for the technology in the new RFC to work) [RFCED]. In order
			to understand this document, one must also understand both the PIM
			and MSDP documents. As a result, references to these documents are
			normative.
			The IETF has adopted the policy that BCPs must not have normative
			references to Experimental protocols. However, this document is a
			special case in that the underlying Experimental document (MSDP) is
			not planned to be advanced to Proposed Standard.
			The MBONED Working Group requests approval under the Variance
			Procedure as documented in RFC 2026 [RFC2026].
			Note to RFC-Editor: If IETF/IESG approves this, please change the
			above sentence into: The MBONED Working Group has requested approval
			under the Variance Procedure as documented in RFC 2026 [RFC2026].
			The IESG followed the Variance Procedure, and after an additional 4
			week IETF Last Call evaluated the comments and status and has
			approved this document.
			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].
	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, the domain will		located within a bounded PIM domain. In addition, the domain will
	typically have its own Autonomous System (AS) number and one or more		typically have its own Autonomous System (AS) number and one or more
	skipping to change at page 13, line 18		skipping to change at page 14, line 38
	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
	registers and joins to the nearest Anycast RP. If a particular		registers and joins to the nearest Anycast RP. If a particular
	Anycast RP router fails, unicast routing will direct subsequent		Anycast RP router fails, unicast routing will direct subsequent
	registers and joins to the nearest Anycast RP. That RP will then		registers and joins to the nearest Anycast RP. That RP will then
	forward an MSDP update to all peers within the Anycast MSDP mesh		forward an MSDP update to all peers within the Anycast MSDP mesh
	group. Each RP will then forward (or receive) the SAs to (from)		group. Each RP will then forward (or receive) the SAs to (from)
	external customers and providers.		external customers and providers.
	4. Intellectual Property		4. Security Considerations
	The IETF takes no position regarding the validity or scope of any
	intellectual property 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; neither does it represent that it
	has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication 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 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. 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.
	5.1. Filtering SA messages		4.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.		domain local sources.
	5.2. SA message state limits		4.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		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.
	6. IANA Considerations		5. IANA Considerations
	This document creates a no new requirements on IANA namespaces		This document creates no new requirements on IANA namespaces
	[RFC2434].		[RFC2434].
	7. Acknowledgments		6. Acknowledgments
	The authors would like to thank Pekka Savola, John Zwiebel, Swapna		The authors would like to thank Pekka Savola, John Zwiebel, Swapna
	Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier		Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier
	versions of this document.		versions of this document.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
			[PIM-SM] Fenner, B., et. al, "Protocol Independent Multicast -
			Sparse Mode (PIM-SM): Protocol Specification
			(Revised)", draft-ietf-pim-sm-v2-new-09.txt. 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
	Groot, E. Lear, "Address Allocation for Private		Groot, E. Lear, "Address Allocation for Private
	Internets", RFC 1918, Feburary, 1996.		Internets", RFC 1918, Feburary, 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to		[RFC2119] Bradner, S., "Key words for use in RFCs to
	Indicate Requirement Levels" RFC 2119/BCP 14,		Indicate Requirement Levels" RFC 2119/BCP 14,
	March 1997.		March 1997.
	[RFC2362] D. Estrin, et. al., "Protocol Independent
	Multicast - Sparse Mode (PIM-SM): Protocol
	Specification", RFC 2362, June, 1998.
	[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.
	skipping to change at page 17, line 5		skipping to change at page 18, line 5
	[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.
	[RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast		[RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast
	Source Discovery Protocol (MSDP)", RFC 3618,		Source Discovery Protocol (MSDP)", RFC 3618,
	October, 2003.		October, 2003.
	8.2. Informative References		7.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
	Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt,		Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt,
	April, 2004. Work in progress.		April, 2004. Work in progress.
	[BSR] Fenner, W., et. al., "Bootstrap Router (BSR)		[BSR] Fenner, W., et. al., "Bootstrap Router (BSR)
	Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,		Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,
	February, 2003. Work in progress.		February, 2003. Work in progress.
	[IANA] http://www.iana.org		[IANA] http://www.iana.org
	9. Author's Addresses		[RFCED] http://www.rfc-editor.org/policy.html#policy.refs
			8. Author's Addresses
	Mike McBride		Mike McBride
	Cisco Systems		Cisco Systems
	Email: mcbride@cisco.com		Email: mcbride@cisco.com
	John Meylor		John Meylor
	Cisco Systems		Cisco Systems
	Email: jmeylor@cisco.com		Email: jmeylor@cisco.com
	David Meyer		David Meyer
	Email: dmm@1-4-5.net		Email: dmm@1-4-5.net
	10. Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	skipping to change at line 642		skipping to change at page 19, line 20
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			10. 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.
			11. Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/