Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9885.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

The continued growth of the Internet has resulted in a commensurate growth in the scale of service provider networks and the amount of information carried in IS-IS[ISO10589] Type-Length-Value (TLV) tuples. Simultaneously, new traffic engineering technologies are defining new attributes, further adding to the scaling pressures. The original TLV definition limits each TLV to a maximum of 255 octets of payload, which is becoming increasingly problematic.¶

Some TLV definitions have addressed this by explicitly stating that a TLV may appear multiple times inside of a Link State PDU (LSP). However, this has not been done for many currently defined TLVs, leaving the situation somewhat ambiguous.¶

For example,[RFC5305] defines the Extended IS reachability TLV (22) and[RFC5120] defines the MT-ISN TLV (222). These documents do not specify sending multiple TLVs for the same object and no other mechanism for expanding the information carrying capacity of the TLV has been specified.¶

The intent of this document is to clarify and codify the situation by explicitly making multiple occurrences of a TLV the standard mechanism for scaling TLV contents. 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.¶

This document does not alter the encoding of any TLV where multiple occurrences of a TLV are already defined. Some examples of this are:¶

• Router CAPABILITY TLV (Type 242)[RFC7981]¶
• Application-Specific SRLG (Type 238)[RFC9479]¶
• Instance Identifier (Type 7)[RFC8202]¶
• Application-Specific Link Attributes (sub-TLV Type 16)[RFC9479]¶

[RFC7356] has defined a 16-bit Length field for TLVs in flooding scopedProtocol Data Units (PDUs). The problem addressed by this document would likelynot be encountered when 16-bit Length TLVs are in use. However, introduction of thesenew PDU types is not backwards compatible. Therefore, there is a need to address how to expandthe information advertised in existing PDUs that use TLVs with 8-bit length fields.¶

The mechanism described in this document has not been documented for all TLVs previously. This document provides the necessary protocol definition and discusses potential interoperability issues and deployment challenges.¶

This document specifies a means for extending TLVs where no extension mechanism has been previously explicitly specified. It also specifies this mechanism as the default extension mechanism for future TLVs. The mechanism described in this document is applicable to top level TLVs as well as any level of sub-TLVs that may appear within a top level TLV.¶

2.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

5.Procedure for Receiving Multi-Part TLVs

A router that receives an MP-TLVMUST accept all of the information in all of the parts. The order of arrival and placement of the TLV parts in LSP fragments is irrelevant. Multiple TLV partsMAY occur in a single LSP or partsMAY occur in different LSPs.¶

The placement of the TLV parts in an IIH is irrelevant.¶

When processing MP-TLVs, implementationsMUST NOT impose a minimum length check. Although MP-TLVsSHOULD NOT be sent unless the capacity of a single TLV (255 octets) is exceeded, receiversMUST NOT reject MP-TLVs if senders do not strictly adhere to this constraint. For example, if two MP-TLVs are received, each of which has a length of 100 bytes, the fact that the total amount of data does not exceed 255 bytesMUST NOT cause the TLVs to be rejected. SeeSection 8.2 for guidance on sending MP-TLVs.¶

The contents of an MP-TLVMUST be processed as if they were concatenated. If the internals of the TLV contain key information, then replication of the key informationMUST be taken to indicate that subsequent dataMUST be processed as if the subsequent data were concatenated after a single copy of the key information.¶

For example, suppose that a router receives an LSP with a Multi-Part Extended IS reachability TLV. The first part contains key information K with unique sub-TLVs A, B, and C. The second part contains key information K with unique sub-TLVs D, E, and F. The receiving router must then process this as having key information K and unique sub-TLVs A, B, C, D, E, F, or, because ordering is irrelevant, unique sub-TLVs D, E, F, A, B, C, or any other permutation.¶

A TLV may contain information in its fixed part that is not part of the key. For example, the metric in both the Extended IS reachability TLV and the Extended IP Reachability TLV does not specify which object the TLV refers to, and thus is not part of the key. Having inconsistent information in different parts of an MP-TLV is an error.¶

It is also possible that information that is not part of the fixed part of a TLV can be duplicated, e.g., a sub-TLV that is intended to only appear once appears multiple times and has inconsistent values. This could occur within the same TLV or in different parts of an MP-TLV. This is also an error.¶

The document defining the TLV should specify how to handle such cases. If such a document is not explicit in how to handle such cases, the following procedure is defined:¶

• The first occurrence in the lowest numbered LSP is used. Subsequent occurrences in the same LSP or higher numbered LSPs are ignored.¶

• In the case of IIHs, the first occurrence in the IIH is used. Subsequent occurrences in the IIH are ignored.¶

6.Specification of Applicability of Multi-Part TLVs

As mentioned inSection 1, existing specifications for some TLVs have explicitly stated that the use of MP-TLV procedures are applicable to that codepoint. However, MP-TLV procedures are potentially applicable to any codepoint that allows sub-TLVs to be included as part of the information advertised. MP-TLV procedures may also be applicable to codepoints that do not support sub-TLVs, but which define an unbounded number of attributes that may be advertised within a single codepoint. An example of the latter is GMPLS-SRLG as defined in[RFC5307].¶

The lack of explicit indication of applicability of MP-TLV procedures for all codepoints to which such procedures could be applied contributes to potential interoperability problems if/when there is need to advertise more than 255 octets of information for such a codepoint.¶

This document makes explicit the applicability of MP-TLV procedures for all existing codepoints defined for the IS-IS protocol by extending existing and relevant IANA protocol registries to include an explicit indication of applicability of MP-TLV procedures for each codepoint. SeeSection 9. Therefore, any new codepoints defined by future protocol extensions will explicitly indicate the applicability of MP-TLV procedures to the new codepoints.¶

7.MP-TLV Capability Advertisement

Introduction of the use of MP-TLV for codepoints where the existing specifications have not explicitly defined MP-TLV support can be extremely disruptive to network operations in cases where not all routers in the network support MP-TLV for those codepoints. Partial deployment can easily result in traffic loss and/or other unexpected behaviors that may be hard to diagnose.¶

For example, if there are multiple TLVs associated with the advertisement of a neighbor and an implementation does not process all of the link attributes advertised, then constrained path calculations based on those attributes are likely to produce incorrect or unexpected results. This could produce forwarding loops or dropped traffic.¶

As an aid to network operators when diagnosing such situations, a new sub-TLV of the IS-IS Router CAPABILITY TLV[RFC7981] is defined:¶

MP-TLV Support for TLVs with Implicit Support¶

Type:

30 (1 octet)¶

Length:

0 (1 octet)¶

Routers that support MP-TLV for codepoints for which existing specifications do not explicitly define such support, but for which MP-TLV is applicable,SHOULD include this sub-TLV in a Router CAPABILITY TLV.¶

Scope of the associated Router CAPABILITY TLV is per level (S-bit clear)[RFC7981].¶

This advertisement is for informational purposes only. IS-IS protocol implementationsMUST NOT alter what is sent or how what is received is processed based on these advertisements.¶

The sub-TLV intentionally does not provide a syntax to specify MP-TLV support on a per-codepoint basis. It is presumed that if such support is provided that it applies to all relevant codepoints. It is understood that in reality, a given implementation might limit MP-TLV support to particular codepoints based on the needs of the deployment scenarios in which it is used. Therefore, diligence is still required on the part of the operator to ensure that configurations which require the sending of an MP-TLV for a given codepoint are not introduced on any router in the network until all routers in the network support MP-TLV for the relevant codepoints.¶

The Router CAPABILITY TLV is meant to advertise capabilities that are of direct use to the IS-IS protocol. The MP-TLV Support sub-TLV advertises management information, which is not of direct use to the protocol. The intent is to provide information that may be of use to a network operator. This exception to the intended use of the Router CAPABILITY TLV is introduced to help mitigate the potential disruptiveness associated with the introduction of MP-TLV support in cases where such support has not been explicitly defined. This is not intended to introduce a generic new use case for the Router CAPABILITY TLV.¶

NOTE: A more appropriate and robust mechanism to provide detailed information on what a given implementation supports is to utilize YANG to define Protocol Implementation Conformance Statement (PICS). An example of this can be found in[PICS-YANG].¶

9.IANA Considerations

10.Security Considerations

This document creates no new security issues for IS-IS. Additional instances of existing TLVs expose no new information.¶

Note that support for MP-TLV may result in an implementation being more robust in handling unexpected occurrences of MP-TLV.¶

Security concerns for IS-IS are addressed in[ISO10589],[RFC5304], and[RFC5310].¶

Contributors

The following individual made a substantial contribution to the content of this document and should be considered a coauthor:¶

Authors' Addresses