draft-ietf-isis-caps-00.txt   draft-ietf-isis-caps-01.txt 
ISIS WG ISIS WG
Internet Draft Jean-Philippe Vasseur(Ed) Internet Draft Jean-Philippe Vasseur(Ed)
Naiming Shen (Ed)
Cisco Systems, Inc. Cisco Systems, Inc.
Rahul Aggarwal(Ed) Rahul Aggarwal(Ed)
Juniper Networks Juniper Networks
Naiming Shen(Ed)
Redback Networks
Expires: July 2005 January 2005 Proposed status: Standard
Expires: July 2005 April 2005
IS-IS extensions for advertising router information IS-IS extensions for advertising router information
draft-ietf-isis-caps-00.txt draft-ietf-isis-caps-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or IPR claims of which I am aware have been disclosed, and any patent or IPR claims of which I am aware have been disclosed, and any
of which I become aware will be disclosed, in accordance with RFC of which I become aware will be disclosed, in accordance with RFC
3668. 3668.
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 [i]. all provisions of Section 10 of RFC2026 [i].
skipping to change at page 2, line 6 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 [ii].
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....................................4 3. Element of procedure............................................3
4. Interoperability with routers not supporting the 4. Interoperability with routers not supporting the capability TLV.5
capability TLV..........................................5 5. Security considerations.........................................6
5. Security considerations.................................5 6. Acknowledgment..................................................6
6. Acknowledgment..........................................5 7. Intellectual Property Considerations............................6
7. Intellectual Property Considerations....................5 8. References......................................................6
8. References..............................................6 8.1 Normative references...........................................6
Normative references.......................................6 8.2 Informative references.........................................7
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- routers to learn the capabilities of the other routers of their IS-
IS level, area or routing domain. Some applications are described IS level, area or routing domain. For the sake of illustration, two
in [IS-IS-TE-CAP]. For the sake of illustration, two examples examples related to MPLS Traffic Engineering are described here:
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
significant configuration effort. [IS-IS-TE-CAP] proposes an auto- significant configuration effort. [AUTOMESH] proposes an auto-
discovery mechanism whereby every LSR of a mesh advertises its discovery mechanism whereby every LSR of a mesh advertises its
mesh-group membership by means of IS-IS extensions. mesh-group membership by means of IS-IS extensions.
2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([IS- 2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE-
IS-TE]) 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]).
The use of ISIS for Path Computation Element (PCE) discovery may also The use of IS-IS for Path Computation Element (PCE) discovery may
be considered and will be discussed in the PCE WG. also be considered and will be discussed in the PCE WG.
The capabilities mentioned above require the specification of new The capabilities mentioned above require the specification of new
sub-TLVs carried within the CAPABILITY TLV defined in this document. sub-TLVs carried within the CAPABILITY TLV defined in this document.
Note that the examples above are provided for the sake of Note that the examples above are provided for the sake of
illustration. This document proposes a generic capability advertising illustration. This document proposes a generic capability advertising
mechanism not limited to MPLS Traffic Engineering. mechanism not limited to MPLS Traffic Engineering.
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
skipping to change at page 4, line 6 skipping to change at page 4, line 4
The Router CAPABILITY TLV is OPTIONAL. As specified in section 3, The Router CAPABILITY TLV is OPTIONAL. As specified in section 3,
more than one Router CAPABILITY TLVs from the same source MAY be more than one Router CAPABILITY TLVs from the same source MAY be
present. present.
This document does not specify how an application may use the Router This document does not specify how an application may use the Router
Capability TLV and such specification is outside the scope of this Capability TLV and such specification is outside the scope of this
document. document.
3. Elements of procedure 3. Elements of procedure
A router which generates a capability TLV MUST also generate a
Traffic Engineering Router ID TLV (134) at each level for which it
generates a router capability TLV.
When advertising capabilities with different flooding scopes, a When advertising capabilities with different flooding scopes, a
router MUST originate a minimum of two Router CAPABILITY TLVs, each router MUST originate a minimum of two Router CAPABILITY TLVs, each
TLV carrying the set of sub-TLVs with the same flooding scope. For TLV carrying the set of sub-TLVs with the same flooding scope. For
instance, if a router advertises two sets of capabilities C1 and C2 instance, if a router advertises two sets of capabilities C1 and C2
with an area/level scope and routing domain scope respectively, C1 with an area/level scope and routing domain scope respectively, C1
and C2 being specified by their respective sub-TLV(s), the router and C2 being specified by their respective sub-TLV(s), the router
MUST originate two Router CAPABILITY TLVs: MUST originate two Router CAPABILITY TLVs:
- One Router CAPABILITY TLV with the S flag cleared, carrying the - One Router CAPABILITY TLV with the S flag cleared, carrying the
skipping to change at page 4, line 32 skipping to change at page 4, line 33
level-1, the D bit MUST be set in the level-1 LSP advertisement. level-1, the D bit MUST be set in the level-1 LSP advertisement.
When leaking Capability TLVs downward from Level-2 into Level-1, if When leaking Capability TLVs downward from Level-2 into Level-1, if
the originator of the TLV is a Level-1 router in another area, it is the originator of the TLV is a Level-1 router in another area, it is
possible that multiple copies of the same TLV may be received from possible that multiple copies of the same TLV may be received from
multiple L2 routers in the originating area. To prevent a router from multiple L2 routers in the originating area. To prevent a router from
leaking multiple copies of the same TLV, the router performing the leaking multiple copies of the same TLV, the router performing the
downward leaking MUST check for such duplication by comparing the downward leaking MUST check for such duplication by comparing the
contents of the TLVs. contents of the TLVs.
A system MUST NOT use a Capability TLV present in an LSP of a system In order to prevent the use of stale capabilities information A
system MUST NOT use a Capability TLV present in an LSP of a system
which is not currently reachable via Level-x paths, where "x" is the which is not currently reachable via Level-x paths, where "x" is the
level (1 or 2) in which the sending system advertised the TLV. This level (1 or 2) in which the sending system advertised the TLV. This
requirement applies regardless of whether the sending system is the requirement applies regardless of whether the sending system is the
originator of the Capabilities TLV or not. Note that leaking a originator of the Capabilities TLV or not. Note that leaking a
Capabilities TLV is one of the uses which is prohibited under these Capabilities TLV is one of the uses which is prohibited under these
conditions. conditions.
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
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
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
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
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
stops leaking A's information, this removes the possibility that
other routers will 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
the fragment which has the new advertisement arrive at other systems. the fragment which has the new advertisement arrive at other systems.
skipping to change at page 5, line 41 skipping to change at page 6, line 9
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. No new security issues are raised in this document.
6. Acknowledgments 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 and
Andrew Partan for their useful comments. Andrew Partan 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
skipping to change at page 6, line 23 skipping to change at page 6, line 40
http://www.ietf.org/ipr. 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.
8. References 8. References
Normative references 8.1 Normative references
[RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119. 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 Protocol
for Providing the Connectionless-mode Network Service (ISO 8473)", for Providing the Connectionless-mode Network Service (ISO 8473)",
ISO 10589. 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 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", RFC 3784, June 2004. Engineering", RFC 3784, June 2004.
Informative references 8.2 Informative references
[IS-IS-TE-CAP] JP Vasseur, S. Previdi, Paul Mabey and JL. Le Roux, [AUTOMESH] JP Vasseur, JL. Le Roux et al, ˘Routing extensions for
˘IS-IS MPLS Traffic Engineering capabilities÷, draft-vasseur-isis-te- discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic
caps-00.txt, work in progress. Engineering (TE) mesh membership÷, draft-vasseur-ccamp-automesh-
00.txt, Work in progress.
[TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, ˘Routing extensions for
discovery of Traffic Engineering Node Capabilities÷, draft-vasseur-
ccamp-te-node-cap-00.txt, Work in progress.
[P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions [P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions
to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-
p2mp-00.txt, work in progress. p2mp-01.txt, work in progress.
[P2MP-REQS] S. Yasukawa et al. Ż Requirements for point to multipoint [P2MP-REQS] S. Yasukawa et al. Ż Requirements for point to multipoint
extension to RSVP ę, draft-ietf-mpls-p2mp-sig-requirement-00.txt, extension to RSVP ę, draft-ietf-mpls-p2mp-sig-requirement-01.txt,
work in progress. work in progress.
9. Author's Addresses 9. Author's Addresses
Jean-Philippe Vasseur Jean-Philippe Vasseur
CISCO Systems, Inc. CISCO Systems, Inc.
300 Beaver Brook 300 Beaver Brook
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
 End of changes. 

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