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-
ccamp-te-node-cap, work in progress. ccamp-te-node-cap, work in progress.
[P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions
skipping to change at page 7, line 51 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. 19 change blocks. 
36 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/