Cisco Systems

510 McCarthy Blvd. Milpitas 95035 CA USA ginsberg@cisco.com

Cisco Systems

Via Del Serafico 200 Rome 0144 Italy sprevidi@cisco.com

Huawei Technologies Co., Ltd

KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District Beijing 100085 P.R. China mach.chen@huawei.com

Routing Area Networking Working Group Sample This document defines a new optional Intermediate 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. This document obsoletes RFC 4971. 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 [RFC2119].

There are several situations where it is useful for the IS-IS [ISO10589] [RFC1195] routers to learn the capabilities of the other routers of their IS-IS level, area, or routing domain. For the sake of illustration, three examples related to MPLS Traffic Engineering (TE) are described here: Mesh-group: the setting up of a mesh of TE Label Switched Paths (LSPs) [RFC5305] requires some significant configuration effort. [RFC4972] proposes an auto-discovery mechanism whereby every Label Switching Router (LSR) of a mesh advertises its mesh-group membership by means of IS-IS extensions. Point to Multipoint TE LSP (RFC4875). A specific sub-TLV [RFC5073] allows an LSR to advertise its Point To Multipoint capabilities ([RFC4875] and [RFC4461]). 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.

The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octet that specifies the number of bytes in the value field, and a variable length value field that starts with 4 octets of Router ID, indicating the source of the TLV, followed by 1 octet of flags. A set of optional sub-TLVs may follow the flag field. Sub-TLVs are formatted as described in [RFC5305].

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. Otherwise, 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 in Section 3, more than one Router CAPABILITY TLV 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.

The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV [RFC5305]. If no Traffic Engineering Router ID is assigned the Router ID SHOULD be identical to an IP Interface Address [RFC1195] advertised by the originating IS. If the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE Router ID sub-TLV [RFC5316] MUST be present in the TLV. Router CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the IPv6 TE Router ID sub-TLV present MUST NOT be used. 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 of capabilities, C1 and C2, 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:

In order to prevent the use of stale CAPABILITY TLVs, a system MUST NOT use a CAPABILITY TLV present in an LSP of a system that 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 whether or not the sending system is the originator of the CAPABILITY TLV. When a CAPABILITY TLV is not used, either due to lack of reachability to the originating router or due to unusable Router ID, note that leaking the CAPABILITY TLV is one of the uses that is prohibited under these conditions.

In IS-IS, the atomic unit of the update process is a TLV - or more precisely, in the case of TLVs that allow multiple entries to appear in the value field (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 fragment that had the old advertisement and the fragment that has the new advertisement arrive at other systems. Wherever possible, an implementation SHOULD advertise the update to a CAPABILITY TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action. Systems that 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 CAPABILITY TLV from the same system that have conflicting information for a given sub-TLV, the procedure used to choose which copy shall be used is undefined.

Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that 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 CAPABILITY 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 entire domain, at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV. If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level without change (except for changes to the TLV flags as noted in Section 2) even though it may contain some sub-TLVs which are unsupported by the Router doing the leaking.

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 in [RFC5304] or [RFC5310], should be applied if there is high risk resulting from modification of capability information.

IANA assigned 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. The assigned value is 242.

For the original version of this document (RFC 4971) the authors thanked Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful comments. For this new version the authors would like to thank Kris Michielsen for calling attention to the problem associated with an IPv6 only router.

International Organization for Standardization

This document makes the following changes to RFC 4971. RFC 4971 only allowed a 32 bit Router ID in the fixed header of TLV 242. This is problematic in an IPv6-only deployment where an IPv4 address may not be available. This document specifies: The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV (134) if available. If no Traffic Engineering Router ID is assigned the Router ID SHOULD be identical to an IP Interface Address [RFC1195] advertised by the originating IS. If the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE Router ID sub-TLV [RFC5316] MUST be present in the TLV. In addition, some clarifying editorial changes have been made.