< draft-ietf-isis-caps-06.txt		draft-ietf-isis-caps-07.txt >
	Network Working Group		Network Working Group Jean-Philippe Vasseur(Ed)
	Internet Draft Jean-Philippe Vasseur(Ed)		Internet Draft Naiming Shen (Ed)
	Naiming Shen (Ed)		Proposed status: Standard Cisco Systems, Inc.
	Cisco Systems, Inc.		Expires: August 2007 Rahul Aggarwal(Ed)
	Rahul Aggarwal(Ed)
	Juniper Networks		Juniper Networks
	Proposed status: Standard		February 2007
	Expires: July 2006 January 2006
	IS-IS Extensions for Advertising Router Information		IS-IS Extensions for Advertising Router Information
	draft-ietf-isis-caps-06.txt		draft-ietf-isis-caps-07.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 other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 37 ¶
	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.
			This Internet-Draft will expire on August 15, 2007.
	Abstract		Abstract
	This document defines a new optional IS-IS TLV named CAPABILITY,		This document defines a new optional IS-IS TLV named CAPABILITY,
	formed of multiple sub-TLVs, which allows a router to announce its		formed of multiple sub-TLVs, which allows a router to announce its
	capabilities within an IS-IS level or the entire routing domain.		capabilities within an IS-IS level or the entire routing domain.
	Conventions used in this document		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 this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [i].		document are to be interpreted as described in RFC-2119 [RFC-2119].
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	2. IS-IS Router CAPABILITY TLV....................................3		2. IS-IS Router CAPABILITY TLV....................................3
	3. Element of procedure...........................................3		3. Element of procedure...........................................3
	4. Interoperability with routers not supporting the capability TLV.5		4. Interoperability with routers not supporting the capability TLV.5
	5. Security considerations........................................5		5. Security considerations........................................5
	6. Acknowledgment.................................................6		6. Acknowledgment.................................................6
	7. Intellectual Property Considerations...........................6		7. Intellectual Property Considerations...........................6
	8. References.....................................................6		8. References.....................................................6
	Normative references..............................................6		Normative references..............................................6
	Informative references............................................6		Informative references............................................6
	9. Author's Addresses.............................................7		9. Author's Addresses.............................................7
	1. Introduction		1. Introduction
	There are several situations where it is useful for the IS-IS		There are several situations where it is useful for the IS-IS
	routers to learn the capabilities of the other routers of their IS-		[IS-IS, IS-IS-IP] routers to learn the capabilities of the other
	IS level, area or routing domain. For the sake of illustration, two		routers of their IS-IS level, area or routing domain. For the sake
	examples related to MPLS Traffic Engineering are described here:		of illustration, two examples related to MPLS Traffic Engineering
			are described here:
	1. Mesh-group: the setting up of a mesh of TE LSPs requires some		1. Mesh-group: the setting up of a mesh of TE LSPs [IS-IS-TE]
	significant configuration effort. [AUTOMESH] proposes an auto-		requires some significant configuration effort. [AUTOMESH]
	discovery mechanism whereby every LSR of a mesh advertises its		proposes an auto-discovery mechanism whereby every LSR of a mesh
	mesh-group membership by means of IS-IS extensions.		advertises its mesh-group membership by means of IS-IS extensions.
	2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE-		2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE-
	NODE-CAP]) allows an LSR to advertise its Point To Multipoint		NODE-CAP]) allows an LSR to advertise its Point To Multipoint
	capabilities ([P2MP] and [P2MP-REQS]).		capabilities ([P2MP] and [P2MP-REQS]).
	3. Inter-area traffic engineering: Advertisement of the IPv4		3. Inter-area traffic engineering: Advertisement of the IPv4
	and/or the IPv6 Traffic Engineering Router IDs.		and/or the IPv6 Traffic Engineering Router IDs.
	The use of IS-IS for Path Computation Element (PCE) discovery may		The use of IS-IS for Path Computation Element (PCE) discovery may
	also be considered and will be discussed in the PCE WG.		also be considered and will be discussed in the PCE WG.
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	Definition of these sub-TLVs is outside the scope of this document.		Definition of these sub-TLVs is outside the scope of this document.
	2. IS-IS Router CAPABILITY TLV		2. IS-IS Router CAPABILITY TLV
	The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,		The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,
	1 octet specifying the number of bytes in the value field, and a		1 octet specifying the number of bytes in the value field, and a
	variable length value field, starting with 4 octets of Router ID,		variable length value field, starting with 4 octets of Router ID,
	indicating the source of the TLV, and followed by 1 octet of flags.		indicating the source of the TLV, and followed by 1 octet of flags.
	A set of optional sub-TLVs may follow the flag field. Sub-TLVs are		A set of optional sub-TLVs may follow the flag field. Sub-TLVs are
	formatted as described in RFC 3784.		formatted as described in RFC 3784 [IS-IS-TE].
	TYPE: 242 (To be assigned by IANA)		TYPE: 242 (To be assigned by IANA)
	LENGTH: from 5 to 255		LENGTH: from 5 to 255
	VALUE:		VALUE:
	Router ID (4 octets)		Router ID (4 octets)
	Flags (1 octet)		Flags (1 octet)
	Set of optional sub-TLVs (0-250 octets)		Set of optional sub-TLVs (0-250 octets)
	Flags		Flags
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 41 ¶
	L1/L2 Router in every area of the domain MUST support the Router		L1/L2 Router in every area of the domain MUST support the Router
	CAPABILITY TLV.		CAPABILITY TLV.
	If leaking of the CAP TLV is required, the entire CAP TLV MUST be		If leaking of the CAP TLV is required, the entire CAP TLV MUST be
	leaked into another level even though it may contain some of the		leaked into another level even though it may contain some of the
	unsupported sub-TLVs.		unsupported sub-TLVs.
	5. Security considerations		5. Security considerations
	Any new security issues raised by the procedures in this document		Any new security issues raised by the procedures in this document
	depend upon the opportunity for LSPs to be snooped, the		depend upon the opportunity for LSPs to be snooped and modified,
	ease/difficulty of which has not been altered. As the LSPs may now		the ease/difficulty of which has not been altered. As the LSPs may
	contain additional information regarding router capabilities, this		now contain additional information regarding router capabilities,
	new information would also become available.		this new information would also become available to an attacker.
			Specifications based on this mechanism need to describe the
			security considerations around the disclosure and modification
			of their information. Note that an integrity mechanism, such as
			one defined in RFC3567 or draft-ietf-isis-hmac-sha, should be
			applied if there is high risk resulting from modification of
			capability information.
	6. IANA considerations		6. IANA considerations
	IANA will assign a new IS-IS TLV code-point for the newly defined IS-		IANA will assign a new IS-IS TLV code-point for the newly defined IS-
	IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this		IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this
	document. Suggested value is 242 (to be assigned by IANA).		document. Suggested value is 242 (to be assigned by IANA).
	7. Acknowledgment		7. Acknowledgment
	The authors would like to thank Jean-Louis Le Roux, Paul Mabey,		The authors would like to thank Jean-Louis Le Roux, Paul Mabey,
	Andrew Partan and Adrian Farrel for their useful comments.		Andrew Partan and Adrian Farrel for their useful comments.
	8. Intellectual Property Considerations		8. Intellectual Property Considerations
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 41 ¶
	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.
	9. References		9. References
	9.1 Normative references		9.1 Normative references
	[RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels," RFC 2119.		Requirement Levels," RFC 2119.
	[IS-IS] "Intermediate System to Intermediate System Intra-Domain		[IS-IS] "Intermediate System to Intermediate System Intra-Domain
	Routeing Exchange Protocol for use in Conjunction with the Protocol		Routeing 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 10589.
	[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and		[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
	dual environments", RFC 1195, December 1990.		dual environments", RFC 1195, December 1990.
	[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic		[IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
	Engineering", RFC 3784, June 2004.		Engineering", RFC 3784, June 2004.
	9.2 Informative references		9.2 Informative references
	[AUTOMESH] JP Vasseur, JL. Le Roux et al, "Routing extensions for		[AUTOMESH] JP Vasseur, JL. Le Roux et al, "Routing extensions for
	discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic		discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic
	Engineering (TE) mesh membership", draft-ietf-ccamp-automesh, work in		Engineering (TE) mesh membership", draft-ietf-ccamp-automesh, work in
	progress.		progress.
	[TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, "Routing extensions for		[TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, "Routing extensions for
	discovery of Traffic Engineering Node Capabilities", draft-ietf-		discovery of Traffic Engineering Node Capabilities", draft-ietf-
	skipping to change at page 7, line 52 ¶		skipping to change at page 8, line 4 ¶
	Berkshire,		Berkshire,
	RG2 6GB		RG2 6GB
	UK		UK
	Email: mshand@cisco.com		Email: mshand@cisco.com
	Les Ginsberg		Les Ginsberg
	Cisco Systems		Cisco Systems
	510 McCarthy Blvd.		510 McCarthy Blvd.
	Milpitas, Ca. 95035 USA		Milpitas, Ca. 95035 USA
	Email: ginsberg@cisco.com		Email: ginsberg@cisco.com
	Acee Lindem		Acee Lindem
	Cisco Systems		Redback Networks
	7025 Kit Creek Road		102 Carric Bend Court
	Research Triangle Park, NC 27709		Cary, NC 27519
	USA		USA
	e-mail: acee@cisco.com		e-mail: acee@redback.com
	Naiming Shen		Naiming Shen
	Cisco Systems		Cisco Systems
	225 West Tasman Drive		225 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	e-mail: naiming@cisco.com		e-mail: naiming@cisco.com
	Rahul Aggarwal		Rahul Aggarwal
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Avenue		1194 N. Mathilda Avenue
	San Jose, CA 94089		San Jose, CA 94089
	USA		USA
	e-mail: rahul@juniper.net		e-mail: rahul@juniper.net
	Scott Shaffer		Scott Shaffer
	e-mail: sshaffer@bridgeport-networks.com		e-mail: sshaffer@bridgeport-networks.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject		Copyright (C) The IETF Trust (2007). This document is subject to the
	to the rights, licenses and restrictions contained in BCP 78, and		rights, licenses and restrictions contained in BCP 78, and except as
	except as set forth therein, the authors retain all their rights.		set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
			FOR A PARTICULAR PURPOSE.
End of changes. 20 change blocks.
	39 lines changed or deleted		44 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/