Network Working GroupJean-Philippe Vasseur(Ed) Internet Draft Naiming Shen (Ed) Proposed status: StandardJP. Vasseur, Ed. Request for Comments: 4971 N. Shen, Ed. Category: Standards Track Cisco Systems, Inc.Expires: August 2007 Rahul Aggarwal(Ed)R. Aggarwal, Ed. Juniper NetworksFebruaryJuly 2007IS-ISIntermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Informationdraft-ietf-isis-caps-07.txtStatus ofthisThis MemoBy submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis document specifies an Internet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents validrequests discussion and suggestions fora maximumimprovements. Please refer to the current edition ofsix monthsthe "Internet Official Protocol Standards" (STD 1) for the standardization state andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The liststatus ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listthis protocol. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2007.this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a new optionalIS-ISIntermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC-2119].Table of Contents 1.Introduction...................................................2Introduction ....................................................2 1.1. Conventions Used in This Document ..........................2 2. IS-IS Router CAPABILITYTLV....................................3TLV .....................................3 3.ElementElements ofprocedure...........................................3Procedure ...........................................4 4. Interoperability withrouters not supportingRouters Not Supporting thecapability TLV.5Capability TLV ..................................................5 5. Securityconsiderations........................................5Considerations .........................................6 6.Acknowledgment.................................................6IANA Considerations .............................................6 7.Intellectual Property Considerations...........................6Acknowledgment ..................................................6 8.References.....................................................6References ......................................................6 8.1. Normativereferences..............................................6References .......................................6 8.2. Informativereferences............................................6 9. Author's Addresses.............................................7References .....................................8 1. Introduction There are several situations where it is useful for the IS-IS[IS-IS, IS-IS-IP][IS-IS] [IS-IS-IP] routers to learn the capabilities of the other routers of their IS-IS level,areaarea, or routing domain. For the sake of illustration,twothree examples related to MPLS Traffic Engineering (TE) are described here: 1. Mesh-group: the setting up of a mesh of TELSPsLabel Switched Paths (LSPs) [IS-IS-TE] requires some significant configuration effort. [AUTOMESH] proposes an auto-discovery mechanism whereby everyLSRLabel Switching Router (LSR) of a mesh advertises its mesh-group membership by means of IS-IS extensions. 2. Point toMulti-pointMultipoint TE LSP (P2MP LSP). A specific sub-TLV([TE- NODE-CAP])([TE-NODE-CAP]) allows an LSR to advertise its Point To Multipoint capabilities ([P2MP] and [P2MP-REQS]). 3. Inter-area traffic engineering: Advertisement of the IPv4 and/or the IPv6 Traffic Engineering Router IDs. The use of IS-IS for Path Computation Element (PCE) discovery may also be considered and will be discussed in the PCE WG. The capabilities mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document. Note that the examples above are provided for the sake of illustration. This document proposes a generic capability advertising mechanism that is not limited to MPLS Traffic Engineering. This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. The applications mentioned above require the specification of new sub- TLVs carried within the CAPABILITY TLV defined in this document. Definition of these sub-TLVs is outside the scope of this document. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119]. 2. IS-IS Router CAPABILITY TLV The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octetspecifyingthat specifies the number of bytes in the value field, and a variable length valuefield, startingfield that starts with 4 octets of Router ID, 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 formatted as described in RFC 3784 [IS-IS-TE]. TYPE: 242(To be assigned by IANA)LENGTH: from 5 to 255 VALUE: Router ID (4 octets) Flags (1 octet) Set of optional sub-TLVs (0-250 octets) Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |D|S| +-+-+-+-+-+-+-+-+ Currently two bit flags are defined. S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking. D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set.OtherwiseOtherwise, this bit MUST be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping. The Router CAPABILITY TLV is OPTIONAL. As specified insectionSection 3, more than one Router CAPABILITYTLVsTLV from the same source MAY be present. This document does not specify how an application may use the Router Capability TLV and such specification is outside the scope of this document. 3. Elements ofprocedureProcedure A routerwhichthat generates a CAPABILITY TLV MUST have a Router IDwhichthat is a32 bit32-bit number. The ID MUST be unique within the IS-IS area. If the router generates any capability TLVs with domain floodingscopescope, then the ID MUST also be unique within the IS-IS routing domain. When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two Router CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the same flooding scope. For instance, if a router advertises two sets ofcapabilitiescapabilities, C1 andC2C2, with an area/level scope and routing domain scope respectively, C1 and C2 being specified by their respective sub-TLV(s), the router will originate two Router CAPABILITY TLVs: - One Router CAPABILITY TLV with the S flag cleared, carrying the sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be leaked into another level. - One Router CAPABILITY TLV with the S flag set, carrying the sub- TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked into other IS-IS levels. When the TLV is leaked from level-2 to level-1, the D bit will be set in the level-1 LSP advertisement. In order to prevent the use of stalecapabilities information Acapabilities, a system MUST NOT use a Capability TLV present in an LSP of a systemwhichthat 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 requirement applies regardless of whethertheor not the sending system is the originator of the CapabilitiesTLV or not.TLV. Note that leaking a Capabilities TLV is one of the useswhichthat is prohibited under these conditions. Example: If Level-1 router A generates a Capability TLV and floods it to two L1/L2routersrouters, 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 informationandand, they have no reliable way to choose. 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 morepreciselyprecisely, in the case of TLVswhichthat allow multiple entries to appear in the value field(e.g. IS-neighbors) -(e.g., IS-neighbors), the atomic unit is an entry in the value field 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 advertisement, the possibility exists that other systems can temporarily have either 0 copies of a particular advertisement or 2 copies of a particular advertisement, depending on the order in which new copies of the LSP fragmentwhichthat had the old advertisement and the fragmentwhichthat has the new advertisement arrive at other systems. Wherever possible, an implementation SHOULD advertise the update to a capabilities TLV in the same LSP fragment as the advertisementwhichthat it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action. Systemswhichthat receive an update to an existing capability TLV can minimize the potential disruption associated with the update by employing a holddown time prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing. Where a receiving system has two copies of a capabilities TLV from the same systemwhichthat have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined. 4. Interoperability withrouters not supportingRouters Not Supporting thecapability TLV.Capability TLV Routerswhichthat do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routerswhichthat do not support specific sub-TLVs carried within a Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and continue processing those sub-TLVs that are supported in the Router CAPABILITYTLV which are supported.TLV. How partial support may impact the operation of the capabilities advertised within the Router CAPABILITY TLV is outside the scope of this document. In order for Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers to be flooded across the entiredomaindomain, at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV. If leaking of theCAPCAPABILITY TLV is required, the entireCAPCAPABILITY TLV MUST be leaked into another level even though it may contain some of the unsupported sub-TLVs. 5. SecurityconsiderationsConsiderations Any new security issues raised by the procedures in this document depend upon the opportunity for LSPs to be snooped and modified, 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 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 the one defined inRFC3567[RFC-3567] ordraft-ietf-isis-hmac-sha,[IS-IS-HMAC], should be applied if there is high risk resulting from modification of capability information. 6. IANAconsiderationsConsiderations IANAwill assignassigned a new IS-IS TLV code-point for the newly definedIS- ISIS-IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this document.SuggestedThe assigned value is242 (to be assigned by IANA).242. 7. Acknowledgment The authors would like to thank Jean-Louis Le Roux, Paul Mabey, AndrewPartanPartan, and Adrian Farrel for their useful comments. 8.Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 9.References9.18.1. NormativereferencesReferences [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate RequirementLevels,"Levels", BCP 14, RFC2119.2119, March 1997. [IS-IS] "Intermediate System to Intermediate SystemIntra-DomainIntra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589. [RFC-3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [IS-IS-TE]Li, T.,Smit,H., "IS-IS extensionsH. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for TrafficEngineering",Engineering (TE)", RFC 3784, June 2004.9.28.2. InformativereferencesReferences [AUTOMESH]JPVasseur,JL.JP., Ed., LeRoux et al,Roux, JL., Ed., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing extensions fordiscoveryDiscovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE)mesh membership", draft-ietf-ccamp-automesh, work in progress.Mesh Membership", RFC 4972, July 2007. [TE-NODE-CAP]JPVasseur,JL.JP., Ed., and J.L. LeRoux et al,Roux, "RoutingextensionsExtensions fordiscoveryDiscovery of Traffic Engineering Node Capabilities",draft-ietf- ccamp-te-node-cap, workWork inprogress.Progress, April 2007. [P2MP]R. Aggarwal,D. Papadimitriou,S.Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa,et. al.Ed., "Extensions toRSVP-TEResource Reservation Protocol - Traffic Engineering (RSVP-TE) forPoint ToPoint-to- Multipoint TELSPs", draft-ietf-mpls-rsvp-te- p2mp, work in progress.Label Switched Paths (LSPs)", RFC 4875, May 2007. [P2MP-REQS]S. Yasukawa et al. "Requirements for point to multipoint extension to RSVP", draft-ietf-mpls-p2mp-sig-requirement, workYasukawa, S., Ed., "Signaling Requirements for Point- to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006. [IS-IS-HMAC] Bhatia, M., Ed. and V. Manral, Ed., "IS-IS Generic Cryptographic Authentication", Work inprogress. 10.Progress, May 2007. Authors' Addresses Jean-Philippe Vasseur CISCO Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USAEmail:EMail: jpv@cisco.com Stefano Previdi CISCO Systems, Inc. Via Del Serafico 200 00142 - Roma ITALYEmail:EMail: sprevidi@cisco.com Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UKEmail:EMail: mshand@cisco.com Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USAEmail:EMail: ginsberg@cisco.com Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USAe-mail:EMail: acee@redback.com Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USAe-mail:EMail: naiming@cisco.com Rahul Aggarwal Juniper Networks 1194 N. Mathilda Avenue San Jose, CA 94089 USAe-mail:EMail: rahul@juniper.net Scott Shaffere-mail:EMail: sshaffer@bridgeport-networks.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.