draft-ietf-isis-caps-01.txt   draft-ietf-isis-caps-02.txt 
ISIS WG ISIS WG
Internet Draft Jean-Philippe Vasseur(Ed) Internet Draft Jean-Philippe Vasseur(Ed)
Naiming Shen (Ed) Naiming Shen (Ed)
Cisco Systems, Inc. Cisco Systems, Inc.
Rahul Aggarwal(Ed) Rahul Aggarwal(Ed)
Juniper Networks Juniper Networks
Proposed status: Standard Proposed status: Standard
Expires: July 2005 April 2005 Expires: November 2005 May 2005
IS-IS extensions for advertising router information IS-IS extensions for advertising router information
draft-ietf-isis-caps-01.txt draft-ietf-isis-caps-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or IPR claims of which I am aware have been disclosed, and any applicable patent or other IPR claims of which he or she is aware
of which I become aware will be disclosed, in accordance with RFC have been or will be disclosed, and any of which he or she becomes
3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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.
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
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 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 [ii]. document are to be interpreted as described in RFC-2119 [i].
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.........................................6 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
8.1 Normative references...........................................6 Normative references...............................................6
8.2 Informative references.........................................7 Informative references.............................................7
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- routers to learn the capabilities of the other routers of their IS-
IS level, area or routing domain. For the sake of illustration, two IS level, area or routing domain. For the sake of illustration, two
examples related to MPLS Traffic Engineering are described here: 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 requires some
skipping to change at page 3, line 10 skipping to change at page 3, line 8
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. The capabilities within an IS-IS level or the entire routing domain. The
applications mentioned above require the specification of new sub- applications mentioned above require the specification of new sub-
TLVs carried within the CAPABILITY TLV defined in this document. TLVs carried within the CAPABILITY TLV defined in this document.
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 TLV length, 1 octet of bit flags 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. A indicating the source of the TLV, and followed by 1 octet of flags.
set of optional sub-TLVs may follow the flag field.
A set of optional sub-TLVs may follow the flag field.
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 4, line 52 skipping to change at page 4, line 49
Example: If Level-1 router A generates a Capability TLV and floods Example: If Level-1 router A generates a Capability TLV and floods
it to two L1/L2 routers S and T, they will flood it into the Level-2 it to two L1/L2 routers S and T, they will flood it into the Level-2
domain. Now suppose the Level-1 area partitions, such that A and S domain. Now suppose the Level-1 area partitions, such that A and S
are in one partition and T is in another. IP routing will still are in one partition and T is in another. IP routing will still
continue to work, but if A now issues a revised version of the CAP continue to work, but if A now issues a revised version of the CAP
TLV, or decides to stop advertising it, S will follow suit, but T TLV, or decides to stop advertising it, S will follow suit, but T
will continue to advertise the old version until the LSP times out. will continue to advertise the old version until the LSP times out.
Routers in other areas have to choose whether to trust T's copy of Routers in other areas have to choose whether to trust T's copy of
A's capabilities or S's copy of A's information and they have no A's capabilities or S's copy of A's information and they have no
reliable way to choose (more on that below). By making sure that T reliable way to choose. By making sure that T stops leaking A's
stops leaking A's information, this removes the possibility that information, this removes the possibility that other routers will
other routers will use stale information from A. use stale information from A.
In IS-IS, the atomic unit of the update process is a TLV - or more In IS-IS, the atomic unit of the update process is a TLV - or more
precisely in the case of TLVs which allow multiple entries to appear precisely in the case of TLVs which allow multiple entries to appear
in the value field (e.g. IS-neighbors) - an entry in the value field in the value field (e.g. IS-neighbors) - an entry in the value field
of a TLV. If an update to an entry in a TLV is advertised in an LSP of a TLV. If an update to an entry in a TLV is advertised in an LSP
fragment different from the LSP fragment associated with the old fragment different from the LSP fragment associated with the old
advertisement, the possibility exists that other systems can advertisement, the possibility exists that other systems can
temporarily have either 0 copies of a particular advertisement or 2 temporarily have either 0 copies of a particular advertisement or 2
copies of a particular advertisement, depending on the order in which copies of a particular advertisement, depending on the order in which
new copies of the LSP fragment which had the old advertisement and new copies of the LSP fragment which had the old advertisement and
skipping to change at page 5, line 33 skipping to change at page 5, line 28
Systems which receive an update to an existing capability TLV can Systems which receive an update to an existing capability TLV can
minimize the potential disruption associated with the update by minimize the potential disruption associated with the update by
employing a holddown time prior to processing the update so as to employing a holddown time prior to processing the update so as to
allow for the receipt of multiple LSP fragments associated with the allow for the receipt of multiple LSP fragments associated with the
same update prior to beginning processing. same update prior to beginning processing.
Where a receiving system has two copies of a capabilities TLV from Where a receiving system has two copies of a capabilities TLV from
the same system which have different settings for a given attribute, the same system which have different settings for a given attribute,
the procedure used to choose which copy shall be used is undefined. the procedure used to choose which copy shall be used is undefined.
4. Interoperability with routers not supporting the capability TLV. 4. Interoperability with routers not supporting the capability TLV
Routers which do not support the Router CAPABILITY TLV MUST silently Routers which do not support the Router CAPABILITY TLV MUST silently
ignore the TLV(s) and continue processing other TLVs in the same LSP. ignore the TLV(s) and continue processing other TLVs in the same LSP.
Routers which do not support specific sub-TLVs carried within a Routers which do not support specific sub-TLVs carried within a
Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs
and continue processing those sub-TLVs in the Router CAPABILITY TLV and continue processing those sub-TLVs in the Router CAPABILITY TLV
which are supported. How partial support may impact the operation of which are supported. How partial support may impact the operation of
the capabilities advertised within the Router CAPABILITY TLV is the capabilities advertised within the Router CAPABILITY TLV is
outside the scope of this document. outside the scope of this document.
skipping to change at page 6, line 7 skipping to change at page 5, line 50
by L1 Routers to be flooded across the entire domain at least one by L1 Routers to be flooded across the entire domain at least one
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
No new security issues are raised in this document. Any new security issues raised by the procedures in this document
depend upon the opportunity for LSPs to be snooped, the
ease/difficulty of which has not been altered. As the LSPs may now
contain additional information regarding router capabilities, this
new information would also become available.
6. Acknowledgment 6. Acknowledgment
The authors would like to thank Jean-Louis Le Roux, Paul Mabey and The authors would like to thank Jean-Louis Le Roux, Paul Mabey,
Andrew Partan for their useful comments. Andrew Partan and Adrian Farrel for their useful comments.
7. Intellectual Property Considerations 7. Intellectual Property Considerations
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 to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/