draft-ietf-isis-caps-02.txt   draft-ietf-isis-caps-03.txt 
skipping to change at page 2, line ? skipping to change at page 2, line ?
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: November 2005 May 2005 Expires: November 2005 May 2005
IS-IS extensions for advertising router information IS-IS extensions for advertising router information
draft-ietf-isis-caps-02.txt draft-ietf-isis-caps-03.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 2, line ? skipping to change at page 2, line ?
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 [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.........................................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.............................................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
significant configuration effort. [AUTOMESH] proposes an auto- significant configuration effort. [AUTOMESH] proposes an auto-
skipping to change at page 5, line 28 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 6, line 7
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, the
ease/difficulty of which has not been altered. As the LSPs may now ease/difficulty of which has not been altered. As the LSPs may now
contain additional information regarding router capabilities, this contain additional information regarding router capabilities, this
new information would also become available. new information would also become available.
6. Acknowledgment 6. IANA considerations
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
document. Suggested value is 242 (to be assigned by IANA).
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.
7. Intellectual Property Considerations 8. 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 6, line 36 skipping to change at page 6, line 42
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
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 9. References
8.1 Normative references 9.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.
8.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-vasseur-ccamp-automesh- Engineering (TE) mesh membership", draft-vasseur-ccamp-automesh-
00.txt, Work in progress. 00.txt, Work in 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-vasseur- discovery of Traffic Engineering Node Capabilities", draft-vasseur-
ccamp-te-node-cap-00.txt, Work in progress. 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-01.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-01.txt, extension to RSVP", draft-ietf-mpls-p2mp-sig-requirement-01.txt, work
work in progress. in progress.
9. Author's Addresses 10. Authors' 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
Stefano Previdi Stefano Previdi
CISCO Systems, Inc. CISCO Systems, Inc.
 End of changes. 

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