< draft-previdi-isis-mi-mt-00.txt		draft-previdi-isis-mi-mt-01.txt >
			INTERNET DRAFT IS-IS Multi-instance Multi-topology Jun 2006
	Network Working Group S. Previdi		Network Working Group S. Previdi
	Internet Draft D. Ward		Internet Draft L. Ginsberg
	L. Ginsberg		Expiration Date: Dec 2006 M. Shand
	Expires: February, 2006 A. Roy		A. Roy
	Cisco Systems, Inc		D. Ward
	August, 2005		Cisco Systems
			June 2006
	IS-IS Multi-instance Multi-topology		IS-IS Multi-instance Multi-topology
	draft-previdi-isis-mi-mt-00.txt		draft-previdi-isis-mi-mt-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other documents
	documents at any time. It is inappropriate to use Internet-Drafts		at any time. It is inappropriate to use Internet-Drafts as reference
	as reference material or to cite them other than as "work in		material or to cite them other than as "work in progress."
	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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	Abstract		Abstract
	This draft describes a mechanism that allows a single router to		This draft describes a mechanism that allows a single router to
	skipping to change at page 2, line 10 ¶		skipping to change at page 1, line 44 ¶
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	Abstract		Abstract
	This draft describes a mechanism that allows a single router to		This draft describes a mechanism that allows a single router to
	share one or more links among multiple IS-IS routing protocol		share one or more links among multiple IS-IS routing protocol
	instances.		instances.
	Multiple instances allow the deployment of multiple address-families		Multiple instances allow the deployment of multiple address-families
	as well as multiple instances of the same address-family and it is		as well as multiple instances of the same address-family and it is
	an alternative to Multi-Topology IS-IS. Routers supporting the same		an alternative to Multi-Topology IS-IS. Routers will form instance
	instance will form adjacencies, exchange routing updates and compute		specific adjacencies, exchange instance specific routing updates and
	paths. Each PDU will contain a new TLV identifying the instance to		compute paths utilizing instance specific LSDB information. Each PDU
	which the PDU belongs. This allows a network operator to deploy		will contain a new TLV identifying the instance to which the PDU
	multiple IS-IS topologies in parallel, using the same set of links		belongs. This allows a network operator to deploy multiple IS-IS
	when required and still have the capability of computing topology		topologies in parallel, using the same set of links when required
	specific paths. This draft does not address the forwarding paradigm		and still have the capability of computing topology specific paths.
	that needs to be used in order to ensure data PDUs are forwarded		This draft does not address the forwarding paradigm that needs to be
	according to the topology to which they belong.		used in order to ensure data PDUs are forwarded according to the
			topology to which they belong.
	1. Conventions used in this document		Table of Contents
			1. Conventions used in this document..............................2
			2. Introduction...................................................2
			3. Proposed Solution..............................................3
			3.1 Instance Identifier..........................................3
			3.2 Instance Membership..........................................3
			3.3 Adjacency Establishment......................................4
			3.3.1 Point-to-Point Adjacencies................................4
			3.3.2 Multi-Access Adjacencies..................................4
			3.4 Interoperability Considerations..............................4
			3.4.1 MI-ISIS Layer 2 multicast address.........................5
			3.4.2 Interoperability using p2p networks.......................5
			3.4.3 Interoperability using Broadcast networks.................5
			4. Security Considerations........................................6
			5. IANA Considerations............................................6
			6. Normative References...........................................6
			7. Acknowledgments................................................6
			8. Authors' Addresses.............................................7
			9. Full Copyright Statement.......................................7
			1. Conventions used in this document
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in RFC-2119		document are to be interpreted as described in RFC-2119 [BCP14].
	[KEYWORDS].
	2. Introduction		2. Introduction
	IS-IS has been already extended in order to support multiple		"[MT-IS-IS] defines extensions to IS-IS which support multiple
	topologies [MT-ISIS] through the use of additional TLVs in IIH/LSP		topologies through the use of additional TLVs in IIH/LSP PDUs. [MT-
	PDUs. MT-ISIS specifies that a single adjacency, single flooding		IS-IS] specifies that a single adjacency, single flooding scheme,
	scheme, and single LSDB are to be shared across all topologies to		and single LSDB are to be shared across all topologies to which a
	which a router belongs. This draft describes an alternative approach		router belongs. This draft describes an alternative approach where
	where multiple topologies are supported by the use of multiple		multiple topologies are supported by the use of multiple independent
	instances of the IS-IS protocol. Routers which support this		instances of the IS-IS protocol. Routers which support this
	extension are referred to as "multi-instance capable routers"		extension are referred to as "multi-instance capable routers" (MI-
	(MI-RTR).		RTR).
	3. Proposed Solution		3. Proposed Solution
	The solution is based on a new TLV called the Instance Identifier		The solution is based on a new TLV called the Instance Identifier
	(IID) that is used to mark each routing PDU originated by the		(IID) that is used to mark each IS-IS PDU originated by the router.
	router. Routers form adjacencies and exchange routing updates only		Routers form adjacencies and exchange routing updates only if their
	if their IIDs correspond. Each topology is therefore processed		IIDs correspond. Each topology is therefore processed within a
	within a separate instance of the IS-IS protocol.		separate instance of the IS-IS protocol.
	This also implies an instance specific flooding scheme, instance		This also implies an instance specific flooding scheme, instance
	specific LSDBs and Instance specific routing calculations. It MAY		specific LSDBs and instance specific routing calculations. It MAY
	also imply instance specific routing and forwarding tables. However,		also imply instance specific routing and forwarding tables. However,
	this aspect is outside the scope of this specification. When		this aspect is outside the scope of this specification. When
	multiple instances share the same link each instance will have a		multiple instances share the same link each instance will have a
	separate set of adjacencies. Each IS-IS PDU is associated with		separate set of adjacencies. Each IS-IS PDU is associated with only
	only one IS-IS instance.		one IS-IS instance.
	How multiple instances are implemented is outside the scope of		How multiple instances are implemented is outside the scope of this
	this specification.		specification.
	3.1. Instance Identifier (IID)		3.1 Instance Identifier
	A new TLV is defined in order to convey an instance identifier		A new TLV is defined in order to convey an instance identifier
	(IID). The scope of the IID is to mark each IS-IS instance running		(IID). The purpose of the IID is to mark each IS-IS instance running
	on a router with a unique 16-bit number. The IID TLV is carried in		on a router with a unique 16-bit number. The IID TLV is carried in
	all IS-IS PDUs (IIH, SNP, LSP) originated by the router. Routers		all IS-IS PDUs (IIH, SNP, LSP) originated by the router. Multiple
	have to exchange and agree on instance numbers so that IIDs can be		instances of IS-IS may co-exist on the same network and on the same
	understood consistently across adjacencies and flooding domain. The		physical router. IIDs MUST be unique within the same routing domain.
	following format is used for the IID:
	TLV:		Instance identifier #0 is reserved for the standard topology
	Type: TBD		supported by legacy systems.
	Length: 2
	Value: <16-bit number IID>
	3.2 Instance Membership		The following format is used for the IID:
	Each router can be configured as part of one or more instances of		Type TBA by IANA
	IS-IS. Each instance the router belongs to will correspond to the		Length 2
	value advertised in the IID TLV of IS-IS PDUs originated by that		Value <16-bit number IID>
	instance. Only one IID can be advertised in an IIH, LSP, or SNP
	PDU. PDUs with multiple IID TLVs MUST be ignored.
	3.3 Adjacency Establishment		3.2 Instance Membership
			Each router is configured to be participating in one or more
			instances of IS-IS. For each instance in which it participates, a
			router labels all IS-IS PDUs (IIH, LSP or SNP) generated pertaining
			to that instance by including the appropriate IID TLV. Note that
			this applies for the standard topology (instance identifier #0). A
			PDU can only be labeled with a single instance identifier. PDUs with
			multiple IID TLVs MUST be ignored.
			3.3 Adjacency Establishment
	In order to establish adjacencies, IS-IS routers exchange IIH PDUs.		In order to establish adjacencies, IS-IS routers exchange IIH PDUs.
	Two types of adjacencies exist in IS-IS: point-to-point and		Two types of adjacencies exist in IS-IS: point-to-point and
	broadcast. The following sub-sections describe the additional rules		broadcast. The following sub-sections describe the additional rules
	an MI-RTR MUST follow in order to establish adjacencies.		an MI-RTR MUST follow when establishing adjacencies.
	3.3.1 Point-to-Point Adjacencies		3.3.1 Point-to-Point Adjacencies
	A new IID TLV is inserted into the p2p hello PDUs originated by an		A new IID TLV is inserted into the p2p hello PDUs originated by an
	MI-RTR. Upon reception of an IIH, an MI-RTR inspects the received		MI-RTR. Upon reception of an IIH, an MI-RTR inspects the received
	IID TLV and if it matches any of the IIDs configured on that link,		IID TLV and if it matches any of the IIDs configured on that link,
	normal adjacency establishment procedures are used to establish an		normal adjacency establishment procedures are used to establish an
	instance specific adjacency.		instance specific adjacency.
	This extension allows an MI-RTR to establish multiple adjacencies to		This extension allows an MI-RTR to establish multiple adjacencies to
	the same neighbor over a p2p link. This differs from the generic		the same physical neighbor over a p2p link. This differs from the
	behavior of p2p links where only one adjacency is formed. However,		normal behavior on p2p links where only one adjacency is formed.
	in this case IS-IS instances are "ships-in-the-night" and from a		However, in this case IS-IS instances are "ships-in-the-night" and
	logical perspective only one adjacency per instance is formed on		from a logical perspective only one adjacency per instance is formed
	p2p links.		on p2p links.
	3.3.2 Multi-Access Adjacencies		3.3.2 Multi-Access Adjacencies
	Multi-Access (broadcast) networks behave differently than p2p in the		Multi-Access (broadcast) networks behave differently than p2p in
	sense that a DIS is elected. MI-RTRs will establish adjacencies and		that PDUs sent by one router are visible to all routers and all
	elect a DIS per IS-IS instance. Upon reception of an IIH each MI-RTR		routers must agree on the election of a DIS.
	will form adjacencies only with routers advertising the same IID in
	their IIH PDUs. Since an MI-RTR is not required to participate in
	all IIDs on a LAN, it's possible to elect a different DIS for
	different instances.
	3.3.3 Interoperability Considerations		MI-RTRs will establish adjacencies and elect a DIS per IS-IS
			instance. Upon reception of an IIH each MI-RTR will form adjacencies
			only with routers advertising the same IID in their IIH PDUs. Since
			an MI-RTR is not required to participate in all IIDs on a LAN, it's
			possible to elect a different DIS for different instances.
			3.4 Interoperability Considerations
	It is assumed that any TLV that is not understood is silently		It is assumed that any TLV that is not understood is silently
	ignored without compromising the processing of the whole IS-IS PDU		ignored without compromising the processing of the whole IS-IS PDU
	(IIH, LSP, SNP).		(IIH, LSP, SNP).
	To a router not implementing this extension, all IS-IS PDUs received		To a router not implementing this extension, all IS-IS PDUs received
	will appear to be associated with the standard topology regardless		will appear to be associated with the standard topology regardless
	of any IID TLVs which may be contained in those PDUs. This can cause		of any IID TLVs which may be contained in those PDUs. This can cause
	interoperability issues, not all of which can be resolved. Therefore		interoperability issues unless the mechanisms and procedures
	deployment/configuration of MI-RTRs must be done prudently. MI-RTRs		discussed below are followed.
	may be configured to accept or not to form an adjacency with a
	router not supporting this extension. In any case, only the IID zero
	instance can seamlessly interoperate with routers not supporting
	this extension.
	3.3.3.1 Interoperability using p2p networks		3.4.1 MI-ISIS Layer 2 multicast address
	MI-RTRs supporting IID #0 may interoperate over a p2p link with a		In order for routers to correctly interoperate with routers not
	router which does NOT support this extension. To do so, an MI-RTR		implementing this extension and in order not to cause disruption, a
	must refrain from sending LSPs and SNPs for instances other than		specific and dedicated MAC address is used for multicasting IS-IS
	IID #0 over the p2p link. It MUST also refrain from sending IIHs		PDUs labeled with any non-zero IID among MI-RTRs. Each level will
	for instance IDs other than zero as these IIHs may affect the state		use a specific layer 2 multicast address. Such an address allows MI-
	of the adjacency for IID #0 in the neighbor.		RTRs to exchange IS-IS PDUs with non-zero IIDs without these PDUs
			being processed by legacy routers and therefore no disruption is
			caused.
			An MI-RTR will exchange ISIS PDUs intended for IID #0 using AllL1IS
			and AllL2IS ISIS mac layer addresses (as defined in [IS-IS]) and
			will use two new (TBD) dedicated layer 2 multicast addresses (one
			for each level) when sending IS-IS PDUs for any non-zero IID.
			MI-RTRs MUST discard IS-IS PDUs received if either of the following
			is true:
			. The destination multicast address is AllL1IS or AllL2IS and the
			PDU contains an IID TLV with non-zero value.
			. The destination multicast address is one of the two new
			addresses and the PDU contains an IID TLV with a zero value or
			has no IID TLV.
			3.4.2 Interoperability using p2p networks
			In order for an instance on an MI-RTR which participates in the
			standard topology (IID #0) to interoperate over a p2p link with a
			router which does NOT support this extension, the MI-RTR MUST NOT
			send IS-IS PDUs for instances other than IID #0 over the p2p link as
			these PDUs may affect the state of IID #0 in the neighbor.
	The presence/absence of the IID TLV in an IIH indicates that the		The presence/absence of the IID TLV in an IIH indicates that the
	neighbor does/does not support this extension. Once it is determined		neighbor does/does not support this extension. Once it is determined
	that the neighbor does not support this extension, an MI-RTR MUST		that the neighbor does not support this extension, an MI-RTR MUST
	NOT send PDUs (including IIHs) for instances other than IID #0.		NOT send PDUs (including IIHs) for instances other than IID #0.
	Until such time as the capability of the neighbor are known, an		3.4.3 Interoperability using Broadcast networks
	implementation MAY send IIHs for any IID on a p2p link.
	3.3.3.2 Interoperability using Multi-Access networks
	The presence on a multi-access network of one or more MI-RTRs		If the multicast addresses AllL1IS and/or AllL2IS are improperly
	supporting one or more non-zero IIDs is incompatible with the		used to send IS-IS PDUs for non-zero IIDs, legacy systems will
	presence of any routers which do not support this extension. This is		interpret these PDUs as being associated with IID #0. This will
	because the necessary transmission of IS-IS PDUs associated with		cause inconsistencies in the LSDB in those routers, may incorrectly
	non-zero IIDs will be interpreted as being associated with IID #0 by		maintain adjacencies, and may lead to inconsistent DIS election.
	the routers not supporting this extension. Therefore, use of this
	extension on a multi-access network requires that all routers are
	upgraded to a software version supporting this extension. This
	restriction MAY be applied independently for each level of routing
	supported on the network.
	4. IANA considerations		4. Security Considerations
	IANA will assign a new codepoint for the MI-MT IID defined in this		Security concerns for IS-IS are addressed in the IS-IS specification
	document and carried within the IIH PDU. Suggest value is XX (to be		[IS-IS], and accompanying specifications on [HMAC-MD5]. No
	assigned by IANA).		additional considerations need to be made for the extension.
	5. Acknowledgments		5. IANA Considerations
	The authors would like to thank Mike Shand for his valuable input.		This document requires the definition a new ISIS TLV that needs to
			be reflected in the ISIS TLV code-point registry:
	6. Normative References		Type Description IIH LSP SNP
			---- ----------------------------------- --- --- ---
			TBA MI-MT IID y y y
	[RFC] Bradner, S., "Key words for use in RFCs to Indicate		6. Normative References
	Requirement Levels," RFC 2119.
	[IS-IS] "Intermediate System to Intermediate System Intra-Domain		[IS-IS] ISO, "Intermediate system to Intermediate system routeing
	Routeing Exchange Protocol for use in Conjunction with the Protocol		information exchange protocol for use in conjunction with the
	for Providing the Connectionless-mode Network Service (ISO 8473)",		Protocol for providing the Connectionless-mode Network Service
	ISO 10589.		(ISO 8473)," ISO/IEC 10589:2002, Second Edition.
	[IS-IS-IP] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in		[MT-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., "Multi
	TCP/IP and dual environments", RFC 1195, December 1990.		Topology (MT) Routing in IS-IS", draft-ietf-isis-wg-multi-
			topology-11.txt (work in progress), October 2005.
	[HMAC-MD5] Li, T. and R. Atkinson, "Intermediate System to		[HMAC-MD5] Li, T. and R. Atkinson, "Intermediate System to
	Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567,		Intermediate System (IS-IS) Cryptographic Authentication", RFC
	July 2003.		3567, July 2003.
	[MT-IS-IS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi		[BCP9] Bradner, S., "The Internet Standards Process -- Revision
	Topology (MT) Routing in IS-IS", draft-ietf-isis-wg-multi-topology-		3", BCP 9, RFC 2026, October 1996.
	10.txt, May 2005.
	7. Security Considerations		[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997
	Security concerns for IS-IS are addressed in the IS-IS specification		[BCP26] Narten, T. and Alvestrand, H., "Guidelines for Writing an
	[IS-IS], and accompanying specifications on [HMAC-MD5]. No		IANA Considerations Section in RFCs", BCP 26 , RFC 2434, October
	additional considerations need to be made for the extension.		1998
	8. Authors' Addresses		[BCP79] Bradner, S. Ed., "Intellectual Property Rights in IETF
			Technology ", BCP 79 , RFC 3979, March 2005
			7. Acknowledgments
			The authors would like to acknowledge contributions made by Dino
			Farinacci.
			8. Authors' Addresses
	Stefano Previdi		Stefano Previdi
			CISCO Systems, Inc.
			Via Del Serafico 200
			00142 - Roma
			ITALY
			Email: sprevidi@cisco.com
			Les Ginsberg
	Cisco Systems		Cisco Systems
	Via Del Serafico, 200		510 McCarthy Blvd.
	00142 Rome, Italy		Milpitas, Ca. 95035 USA
	sprevidi@cisco.com		Email: ginsberg@cisco.com
	Dave Ward		Abhay Roy
	Cisco Systems		Cisco Systems
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose, CA 95134 USA		San Jose, CA 95134 USA
	dward@cisco.com		akr@cisco.com
	Les Ginsberg		Mike Shand
	Cisco Systems		Cisco Systems
	170 W. Tasman Dr.		250 Longwater Avenue,
	San Jose, CA 95134 USA		Reading,
	ginsberg@cisco.com		Berkshire,
			RG2 6GB
			UK
			Email: mshand@cisco.com
	Abhay Roy		Dave Ward
	Cisco Systems		Cisco Systems
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose, CA 95134 USA		San Jose, CA 95134 USA
	akr@cisco.com		dward@cisco.com
	9. IPR Disclaimer		9. 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.
			This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph
			are included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described		to pertain to the implementation or use of the technology described
	in this document or the extent to which any license under such		in this document or the extent to which any license under such
	rights might or might not be available; nor does it represent that		rights might or might not be available; nor does it represent that
	it has made any independent effort to identify any such rights.		it has made any independent effort to identify any such rights.
	Information on the procedures with respect to rights in RFC		Information on the procedures with respect to rights in RFC
	documents can be found in BCP 78 and BCP 79.		documents can be found in BCP 78 and BCP 79.
	skipping to change at page 7, line 13 ¶		skipping to change at line 374 ¶
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	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 that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	10. Full Copyright Statement
	Copyright (C) The Internet Society (2005).
	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.
	11. Acknowledgement
	Funding for the RFC Editor function is currently provided by the
	Internet Society.
	This document expires in February, 2006.
End of changes. 57 change blocks.
	139 lines changed or deleted		236 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/