Multi-Part TLVs in IS-IS
Extracted elements (24)
IS-IS TLVs are limited to 255 octets of payload because both Type and Length fields are one octet in size. Growing deployment scales and new traffic engineering technologies cause many critical TLVs to exceed this limit, motivating a standardized extension mechanism.
RFC 7356 defined 16-bit Length fields for TLVs in flooding-scoped PDUs, which would largely avoid the 255-octet problem. However, these new PDU types are not backwards compatible, so multiple TLV occurrences (MP-TLV) is used to expand information in existing 8-bit Length PDUs instead.
The MP-TLV Support sub-TLV intentionally does not provide syntax to specify MP-TLV support on a per-codepoint basis. It is presumed that support applies to all relevant codepoints; per-codepoint detail is better provided via YANG-based Protocol Implementation Conformance Statement (PICS).
For TLVs where multiple occurrences were already explicitly defined prior to this document (e.g., Router CAPABILITY TLV Type 242, Application-Specific SRLG Type 238, Instance Identifier Type 7), this document does not alter their existing encoding or procedures.
Sending MP-TLVs in the presence of routers that do not correctly process them can cause traffic loss, forwarding loops, and incorrect constrained path calculations. For example, an implementation that processes only some parts of a Multi-Part Extended IS Reachability TLV may miss link attributes needed for correct TE path computation.
A router that receives an MP-TLV MUST accept all of the information in all of the parts. The order of arrival and placement of TLV parts in LSP fragments is irrelevant; parts MAY occur in a single LSP or in different LSPs.
Any future document that proposes a different mechanism for scaling TLV contents for a given codepoint MUST explain why multiple occurrences of a TLV is not appropriate. Multiple occurrences are codified as the default and standard extension mechanism.
Each TLV that is part of an MP-TLV MUST be parsable independent of other TLVs in the MP-TLV. Breaking of a single sub-TLV or other data unit across TLVs MUST NOT be done; such breaking results in an invalid encoding handled per RFC 8918.
Implementations that support disablement of MP-TLVs MUST log two occurrences: (1) receipt of an MP-TLV when their use is disabled, and (2) when local LSP generation requires MP-TLVs but their generation is disabled.
IS-IS protocol implementations MUST NOT alter what is sent or how received information is processed based on the MP-TLV Support sub-TLV advertisement. The sub-TLV is purely informational management data, not a protocol-altering capability signal.
It is RECOMMENDED that implementations supporting the sending of MP-TLVs provide configuration controls to enable/disable their generation. These controls SHOULD provide support at a per-codepoint granularity to allow selective deployment.
Network operators SHOULD NOT enable MP-TLVs until ensuring all implementations that will receive them can interpret them correctly. Implementations SHOULD NOT send multiple TLVs unless MP-TLV is applicable and the information to be sent exceeds 255 octets.
Routers that support MP-TLV for codepoints where existing specifications do not explicitly define such support SHOULD include the MP-TLV Support sub-TLV (Type 30) in a Router CAPABILITY TLV with per-level scope (S-bit clear).
The contents of an MP-TLV MUST be processed as if they were concatenated. If the TLV internals contain key information, replication of the key MUST be taken to indicate that subsequent data MUST be processed as if concatenated after a single copy of the key information.
When additional space is required in an existing TLV, as long as there is space remaining in that TLV, information SHOULD NOT be split into multiple TLVs. If there is no space in the current LSP, the TLV SHOULD be moved to a new LSP rather than being split.
When inconsistent non-key information appears across MP-TLV parts and the defining document is silent, the first occurrence in the lowest-numbered LSP is used and subsequent occurrences are ignored. In IIHs, the first occurrence in the IIH is used and subsequent ones are ignored.
When processing MP-TLVs, implementations MUST NOT impose a minimum length check. Receivers MUST NOT reject MP-TLVs if senders do not strictly adhere to the constraint that MP-TLVs SHOULD NOT be sent unless the 255-octet capacity of a single TLV is exceeded.
A Multi-Part TLV (MP-TLV) is formed when a router advertises multiple TLV tuples with the same TLV type and the same key (when applicable) in an IS-IS IIH packet or in the set of LSPs for a given level. The encoding of TLVs is not altered by the introduction of MP-TLV support.
The MP-TLV Support for TLVs with Implicit Support sub-TLV is defined as a sub-TLV of the IS-IS Router CAPABILITY TLV (Type: 30, Length: 0). It signals that the advertising router supports MP-TLV for codepoints where existing specifications do not explicitly define such support.
IANA has extended registries for IS-IS Sub-TLVs for MT-Capability TLV, Router CAPABILITY TLV sub-TLVs, SRv6 Capabilities sub-sub-TLVs, BIER Info sub-sub-TLVs, Segment Identifier/Label Binding TLVs, Application-Specific Link Attributes sub-sub-TLVs, Application-Specific SRLG TLV sub-TLVs, SRv6 SID sub-sub-TLVs, Flexible Algorithm Definition sub-sub-TLVs, and Flood Reflection Discovery sub-sub-TLVs with MP-TLV applicability columns.
IANA has extended the 'IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability' registry with an MP column. Sub-TLVs with MP=Y include 32-bit Administrative Tag (1), 64-bit Administrative Tag (2), SRv6 End SID (5), and BIER Info (32).
IANA has extended the 'IS-IS Top-Level TLV Codepoints' registry with an MP column indicating MP-TLV applicability per codepoint. Key entries with MP=Y include Extended IS reachability (22), Extended IP reachability (135), GMPLS-SRLG (138), SRv6 Locator (27), MT-ISN (222), IS-IS Router CAPABILITY TLV (242), and Application-Specific SRLG (238).
IANA has registered Type 30 (MP-TLV Support for TLVs with Implicit Support, Length 0) in the 'IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV' registry, with MP-TLV Applicability: N, as defined in Section 7 of RFC 9885.
This document creates no new security issues for IS-IS. Additional instances of existing TLVs expose no new information. Support for MP-TLV may result in implementations being more robust in handling unexpected occurrences of MP-TLV. Existing IS-IS security is addressed in ISO 10589, RFC 5304, and RFC 5310.