<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPErfc> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-lsr-multi-tlv-19" number="9885" updates="" obsoletes="" ipr="trust200902" submissionType="IETF"consensus="true">consensus="true" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3" xml:lang="en"> <front> <title abbrev="Multi-PartTLVs"> Multi-PartTLVs">Multi-Part TLVs inIS-IS </title>IS-IS</title> <seriesInfo name="RFC" value="9885"/> <author fullname="ParagKaneriya "Kaneriya" initials="P." surname="Kaneriya"> <organization>Juniper Networks</organization> <address> <postal> <street>Elnath-Exora Business Park Survey</street> <city>Bangalore</city> <region>Karnataka</region> <code>560103</code> <country>India</country> </postal> <email>pkaneria@juniper.net</email> </address> </author> <author fullname="Tony Li" initials="T." surname="Li"> <organization>Juniper Networks</organization> <address> <postal> <street>1133 Innovation Way</street> <city>Sunnyvale</city> <region>California</region> <code>94089</code><country>USA</country><country>United States of America</country> </postal><phone></phone><email>tony.li@tony.li</email> </address> </author> <author fullname="Antoni Przygienda" initials="A." surname="Przygienda"> <organization>Juniper Networks</organization> <address> <postal> <street>1133 Innovation Way</street> <city>Sunnyvale</city> <region>California</region> <code>94089</code><country>USA</country><country>United States of America</country> </postal> <email>prz@juniper.net</email> </address> </author> <author fullname="Shraddha Hegde" initials="S." surname="Hegde"> <organization>Juniper Networks</organization> <address> <postal> <street>Elnath-Exora Business Park Survey</street> <city>Bangalore</city> <region>Karnataka</region> <code>560103</code> <country>India</country> </postal> <email>shraddha@juniper.net</email> </address> </author> <author fullname="Les Ginsberg" initials="L" surname="Ginsberg"> <organization>Cisco Systems</organization> <address> <email>ginsberg@cisco.com</email> </address> </author> <dateyear="2025"/> <area>Routing Area</area> <workgroup>LSR Working Group</workgroup> <keyword>ISIS</keyword> <keyword>Draft</keyword>year="2025" month="October"/> <area>RTG</area> <workgroup>lsr</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t> New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing. This causes the contents of many critical TLVs to exceed the currently supported limit of 255 octets. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. </t> </abstract> </front> <middle> <sectionanchor="Introduction" title="Introduction">anchor="Introduction"> <name>Introduction</name> <t> 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 <xref target="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. </t> <t> 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. </t> <t> For example, <xref target="RFC5305"/> defines the Extended IS Reachability TLV (22) and <xref target="RFC5120"/> defines the MT Intermediate Systems 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. </t> <t> 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. </t> <t> This document does not alter the encoding of any TLV where multiple occurrences of a TLV are already defined. Some examples of this are:<list> <t></t> <!-- [rfced] Capitalization for some of the TLV descriptions do not match the IANA registry. Should these match? It wasn't clear to us if you intentionally chose initial capitalization for all descriptions, regardless of what appears in the RFCs/registries. Examples: IANA vs document IS-IS Router CAPABILITY TLV vs Router Capability TLV (though "IS-IS Router CAPABILITY TLV" appears once in Section 7) Extended IS reachability vs Extended IS Reachability (outside of the IANA table) --> <ul spacing="normal"> <li> Router Capability TLV (Type 242) <xref target="RFC7981"/></t> <t></li> <li> Application-Specific SRLG (Type 238) <xref target="RFC9479"/></t> <t></li> <li> Instance Identifier (type 7) <xref target="RFC8202"/></t> <t></li> <li> Application-Specific Link Attributes (sub-TLV Type 16) <xref target="RFC9479"/></t> </list> </t></li> </ul> <t> <!-- [rfced] Presumably, the mechanism defined in this document would not be needed if the mechanims defined by RFC 7356 were backwards compatible (i.e., the existence of RFC 7356 does not resolve the problem). For clarity, we suggest the update below. Please review and clarify as needed. Original: [RFC7356] has defined a 16-bit length field for TLVs in flooding scoped Protocol Data Units (PDUs), in which case the problem addressed by this document would not exist. However, introduction of these new PDU types is not backwards compatible. Therefore, there is a need to address how to expand the information advertised in existing PDUs that use 8-bit length TLVs. Perhaps: [RFC7356] has defined a 16-bit length field for TLVs in flooding scoped Protocol Data Units (PDUs), but it is not backwards compatible. Therefore, there remains a need to address how to expand the information advertised in PDUs that use 8-bit TLVs. --> <xref target="RFC7356"/> has defined a 16-bit length field for TLVs in flooding scoped Protocol Data Units (PDUs), in which case the problem addressed by this document would not exist. However, introduction of these new PDU types is not backwards compatible. Therefore, there is a need to address how to expand the information advertised in existing PDUs that use 8-bit length TLVs. </t> <t> 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. </t> <!-- [rfced] The text indicates that this mechanism is to be used in cases where no extension was previously specified and is to be used with future TLVs. Assuming "future TLVs" refers to only the TLVs with 8-bit TLVs, we suggest the following update. Please review. Original: This document specifies a means for extending TLVs where no extension mechanism has been previously explicitly specified, and defines this mechanism as the default extension mechanism for future TLVs. Perhaps: This document specifies a means for extending TLVs where no extension mechanism has been previously explicitly specified, and defines this mechanism as the default extension mechanism for future TLVs with an 8-bit length field. --> <t> This document specifies a means for extending TLVs where no extension mechanism has been previously explicitly specified, and defines 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. </t> </section> <sectionanchor="ReqLang" title="Requirements Language">anchor="ReqLang"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119">BCP 14</xref>target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section><section title="Overview<section> <name>Overview of MP-TLV Applicability toTLVs ">TLVs</name> <t> A TLV is a tuple of (Type, Length, Value) and can be advertised in IS-IS packets. Both Type and Length fields are one octet in size, which leads to the limitation that a maximum of 255 octets can be sent in a single TLV. TLVs that have certain general characteristics have the potential to require advertisement of more than 255 octets. These generic types are described in more detail in the followingsub-sections.subsections. </t><section title="TLVs That<section> <name>TLVs that Advertise a List ofObjects">Objects</name> <t> Some TLVs are simply a list of objects of a given type. For example, the BFD-Enabled TLV(type(Type 148) <xref target="RFC6213"/> contains a list of Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier (NLPID) pairs. If more than 255 octets are required to advertise all of the MTID/NLPID pairs, multiple BFD-Enabled TLVs would be required. The relationship between multiple BFD-Enabled TLVs is established using the TLV type. </t> </section><section title="TLVs That<section> <name>TLVs that Advertise Objects withIdentifier(s)"> <t>Identifier(s)</name> <!-- [rfced] For clarity, may we update the text as follows? Original: Some TLVs support advertisement of objects of a given type, where each object is identified by a unique set of identifiers. In this case the "key" that uniquely identifies a given object consists of the set of identifiers. Perhaps: Some TLVs support advertisement of objects of a given type, where each object is identified by a unique set of identifiers, which is referred to as a "key". --> <t> Some TLVs support advertisement of objects of a given type, where each object is identified by a unique set of identifiers. In this case, the "key" that uniquely identifies a given object consists of the set of identifiers. </t><section title="Example:<section> <name>Example: Extended ISReachability">Reachability</name> <!-- [rfced] We added articles in Sections 3.2.1 and 3.2.2. Please review and let us know if any corrections are needed. --> <t> As an example, consider the Extended IS Reachability TLV(type(Type 22) <xref target="RFC5305"/>. A neighbor in this TLV is specified by:<list style="symbols"></t> <ul spacing="normal"> <li> <t> 7 octets of a system ID and pseudonode number </t> </li> <li> <t> 3 octets of a default metric </t> </li> <li> <t>OptionallyOptionally, one or more of the following link identifiers encoded as sub-TLVs:<list style="symbols"></t> <ul spacing="normal"> <li> <t> an IPv4 interface address and IPv4 neighbor address as specified in <xref target="RFC5305"/> </t> </li> <li> <t> an IPv6 interface address and IPv6 neighbor address as specified in <xref target="RFC6119"/> </t> </li> <li> <t> Link Local/Remote Identifiers as specified in <xref target="RFC5307"/> </t></list> </t> </list> </t></li> </ul> </li> </ul> <t> The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers that are present. </t> </section><section title="Example:<section> <name>Example: Extended IPReachability">Reachability</name> <t> As another example, consider the Extended IP Reachability TLV(type(Type 135) <xref target="RFC5305"/>. A prefix in this TLV is specified by:<list style="symbols"></t> <ul spacing="normal"> <li> <t> 4 octets of metric information </t> </li> <li> <t> 1 octet of control information that includes 6 bits specifying the prefix length </t> </li> <li> <t> 0-4 octets of an IPv4 prefix </t></list></li> </ul> <t> The above are followed by up to 250 octets of sub-TLV information. </t> <t> The key consists of the 6 bits of prefix length plus 0-4 octets of an IPv4 prefix. </t></t></section> </section> </section><section title="Multi-Part TLVs"><section> <name>Multi-Part TLVs</name> <t> If a router advertises multiple TLV tuples with the same TLV type and the same key (when applicable) in an IS-IS Hello (IIH) packet or in the set of LSPs for a given level, they are considered a Multi-Part TLV (MP-TLV). </t> <!-- [rfced] We are having trouble parsing "transient" as a noun. Perhaps this should read "a transient issue" or "a transient error"? Original: Note that this can occur either legitimately as a transient when a TLV moves from one LSP to another or as a result of a defect in the sending implementation. --> <t> In the absence of MP-TLV support, when a router receives an MP-TLV, the receiver chooses which TLV will be processed and which TLV will be ignored. Note that this can occur either legitimately as a transient when a TLV moves from one LSP to another or as a result of a defect in the sending implementation. </t> <t> In the presence of MP-TLV support, when a router receives an MP-TLV, information from all the TLVs is processed. </t> <t> The encoding of TLVs is not altered by the introduction of MP-TLV support. In particular, the "key" that is used to identify the set of TLVs that form an MP-TLV is the same key used in the absence of MP-TLV support. Also note the definition of the "key" is part of the specification(s) that define(s) the TLV and is therefore outside the scope of this document. </t> <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> <t> NOTE: This document intentionally does not include a definition of the key for each codepoint. To do so would be redundant and risk unintentionally deviating from the definition that already exists in the relevant specifications. Also, the term "key" is a generic term that is not used in the relevant specifications. </t> <t> Each TLV that is part of an MP-TLVMUST<bcp14>MUST</bcp14> be parsable independent of other TLVs in the MP-TLV. Breaking of a single sub-TLV or other data unit across TLVsMUST NOT<bcp14>MUST NOT</bcp14> be done. Breaking of a data unit across TLVs results in an invalid encoding. Guidelines to receivers for handling such a case are specified in <xreftarget="RFC8918"/>target="RFC8918"/>. </t> </section> <sectionanchor="RxMPTLV" title="Procedureanchor="RxMPTLV"> <name>Procedure for Receiving Multi-PartTLVs">TLVs</name> <t> A router that receivesaan MP-TLVMUST<bcp14>MUST</bcp14> 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<bcp14>MAY</bcp14> occur in a single LSP or partsMAY<bcp14>MAY</bcp14> occur in different LSPs. </t> <t> The placement of the TLV parts in an IIH is irrelevant. </t> <t> When processing MP-TLVs, implementationsMUST NOT<bcp14>MUST NOT</bcp14> impose a minimum length check. Although MP-TLVsSHOULD NOT<bcp14>SHOULD NOT</bcp14> be sent unless the capacity of a single TLV (255 octets) is exceeded, receiversMUST NOT<bcp14>MUST NOT</bcp14> 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<bcp14>MUST NOT</bcp14> cause the TLVs to be rejected. See <xref target="MPTLVRestrict"/> for guidancewhenon sending MP-TLVs. </t> <t> The contents ofaan MP-TLVMUST<bcp14>MUST</bcp14> be processed as if they were concatenated. If the internals of the TLV contain key information, then replication of the key informationMUST<bcp14>MUST</bcp14> be taken to indicate that subsequent dataMUST<bcp14>MUST</bcp14> be processed as if the subsequent data were concatenated after a single copy of the key information. </t> <!-- [rfced] We wonder if the following update would help with readability. Original: 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. Perhaps - splitting this into two sentences: The receiving router must then process this as having key information K and unique sub-TLVs A, B, C, D, E, F. Because ordering is irrelevant, the sub-TLVs may appear in any order (e.g., D, E, F, A, B, C). --> <t> 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. </t> <t> 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 ofaan MP-TLV is an error. </t> <t> It is also possible that information that is not part of the fixed part of a TLV can beduplicatedduplicated, 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. </t> <t>SpecifyingThe document defining the TLV should specify how to handle suchcases is the responsibility of the document that defines the TLV.cases. If such a document is not explicit in how to handle such cases, the following procedure is defined: </t><list style="symbols"><ul spacing="normal"> <li> <t> The first occurrence in the lowest numbered LSP is used. Subsequent occurrences in the same LSP or higher numbered LSPs are ignored. </t> </li> <li> <t> In the case of IIHs, the first occurrence in the IIH is used. Subsequent occurrences in the IIH are ignored. </t></list></li> </ul> </section> <sectionanchor="Applicability" title="Specificationanchor="Applicability"> <name>Specification of Applicability of Multi-PartTLV ">TLVs</name> <t> As mentioned in <xref target="Introduction"/>, 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 <xref target="RFC5307"/>. </t> <t> The lack of explicit indication of applicability of MP-TLV procedurestofor all codepoints to which such procedures could be applied contributes to potential interoperability problems if/whenthethere is needarisesto advertise more than 255 octets of information for such a codepoint. </t> <t> 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. See <xref target="IANA"/>.ThereforeTherefore, any new codepoints defined by future protocol extensions will explicitly indicate the applicability of MP-TLV procedures to the new codepoints. </t> </section> <sectionanchor="MPTLVCap" title="MP-TLVanchor="MPTLVCap"> <name>MP-TLV CapabilityAdvertisement">Advertisement</name> <t> 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. </t> <t> For example, if there aremutiplemultiple 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. </t> <t> As an aid to network operators when diagnosing such situations, a new sub-TLV of the IS-IS Router CAPABILITY TLV <xref target="RFC7981"/> is defined: </t><artwork><!-- [rfced] We have updated the format of artwork in Section 7. Please let us know if you have any concerns. Original: MP-TLV Support for TLVs with implicit support Type 30 (suggested - to be assigned by IANA) 1 octet Length 0 1 octet</artwork>Current: MP-TLV Support for TLVs with implicit support Type: 30 (1 octet) Length: 0 (1 octet) --> <t>MP-TLV Support for TLVs with implicit support</t> <dl spacing="compact"> <dt>Type:</dt><dd>30 (1 octet)</dd> <dt>Length:</dt><dd>0 (1 octet)</dd> </dl> <t> 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<bcp14>SHOULD</bcp14> include this sub-TLV in a Router Capability TLV. </t> <!-- [rfced] Please consider whether "per level" will be clear for the reader. Original: Scope of the associated Router Capability TLV is per level (S-bit clear). --> <t> Scope of the associated Router Capability TLV is per level (S-bit clear). </t> <t> This advertisement is for informational purposes only. IS-IS protocol implementationsMUST NOT<bcp14>MUST NOT</bcp14> alter what is sent or how what is received is processed based on these advertisements. </t> <t> 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. </t> <t> 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. </t> <t> 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 <xref target="I-D.ietf-lsr-isis-pics-yang"/>. </t> </section><section title="Deployment Considerations"><section> <name>Deployment Considerations</name> <t> Sending of MP-TLVs in the presence of routers that do not correctly process such advertisements can result in interoperability issues, including incorrect forwarding of packets. This section discusses best practices to be used when a deployment requires the use of MP-TLVs for codepoints for which existing specifications do not explicitly indicate MP-TLV support. </t> <t> While it is not in scope for this document to mandate how implementations provide the means to prevent (or at least make less likely) partial deployment of MP-TLV for a given codepoint, it is important to emphasize the need to assist operators in avoiding inadvertent problematic deployment scenarios. Providing appropriate controls to enable/disable the sending of MP-TLVs as discussed in <xref target="Controls"/> is important to avoid interoperability issues. </t> <sectionanchor="Controls" title="Controlsanchor="Controls"> <name>Controls andAlarms">Alarms</name> <t> It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that implementations that support the sending of MP-TLVstoprovide configuration controls that enable/disable generation of MP-TLVs. Given that MP-TLV support in a given implementation may vary on aper TLVper-TLV basis, these controlsSHOULD<bcp14>SHOULD</bcp14> provide supportper codepointat a per-codepoint granularity. For example, an implementation might support MP-TLVs for IS Extended Reachability but not for IP Reachability. </t> <t> Implementations that support disablement of MP-TLVsMUST<bcp14>MUST</bcp14> log the following occurrences: </t><list style="symbols"><ul spacing="normal"> <li> <t> An MP-TLV is received when use of MP-TLVs is disabled. </t> </li> <li> <t> Local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled. </t></list></li> </ul> <t> Network operatorsSHOULD NOT<bcp14>SHOULD NOT</bcp14> enable MP-TLVs until ensuring that all implementations that will receive the MP-TLVs are capable of interpreting them correctly as described in <xref target="RxMPTLV"/>. </t> </section> <sectionanchor="MPTLVRestrict" title="Restrictionsanchor="MPTLVRestrict"> <name>Restrictions on Generation ofMP-TLVs">MP-TLVs</name> <t> This section discusses restrictions on sending of MP-TLVs. When applying these restrictions, it is assumed that it has already been determined that sending of MP-TLVs is allowed based on the setting of the controls discussed in <xref target="Controls"/>. </t> <t> Sending a single TLV with all the information about an object is preferable to sending multiple TLVs. It is simpler and more efficient to parse information from a single TLV than to combine the information from multiple TLVs. ImplementationsSHOULD NOT<bcp14>SHOULD NOT</bcp14> send multiple TLVs unless MP-TLV is applicable to the TLV and the amount of information that is required to be sent exceeds the capacity of a single TLV. For example, when additional space is required in an existing TLV, as long as there is space in the TLV, informationSHOULD NOT<bcp14>SHOULD NOT</bcp14> be split into multiple TLVs. If there is no space in the current LSP to fit the now larger TLV, the TLVSHOULD<bcp14>SHOULD</bcp14> be moved to a new LSP. </t> </section> </section> <sectionanchor="IANA" title="IANA Considerations"> <section title="MP-TLVanchor="IANA"> <name>IANA Considerations</name> <section> <name>MP-TLV Supportsub-TLV">Sub-TLV</name> <t>This document requestsIANA has registered the following code point from the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry: </t><artwork> Type: 30 (suggested) Description:<!-- [rfced] Please consider whether "implicit support" should be capitalized - that is, how should it appear in other documents that refer to this TLV? Note that we will ask IANA to update their registry as needed. MP-TLV Support for TLVs with implicit supportMP-TLV Applicability: N Reference: This document Section 7.2 </artwork>--> <dl spacing="compact"> <dt>Type:</dt><dd>30</dd> <dt>Description:</dt><dd>MP-TLV Support for TLVs with implicit support</dd> <dt>MP-TLV Applicability:</dt><dd>N</dd> <dt>Reference:</dt><dd><xref target="MPTLVCap"/> of RFC 9885</dd> </dl> </section><section title="Extension<section> <name>Extension to IS-ISTop LevelTop-Level TLVRegistries">Registries</name> <!-- [rfced] Note that we have removed the URLs from each of the subsections in Section 9.2. The URLs would need to be reduced to the URL for the main registry group per IANA guidance, which is already mentioned in Section 9.2. We did not include any introductory text for the tables because the registry names are part of the section titles and table titles. Please review and let us know if you prefer that introductory text be added. --> <t>This document requestsIANAto extendhas extended a number of registries under the "IS-IS TLV Codepoints"registriesregistry group (<ereftarget="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml"/>)target="https://www.iana.org/assignments/isis-tlv-codepoints/" brackets="angle"/>) to include a column that indicates whether the MP-TLV procedures described in this document are applicable to that codepoint. "Y" indicates that MP-TLV is applicable. "N" indicates MP-TLV is not applicable. </t> <t> The followingsub-sectionssubsections provide the initial contents of the new column for a number of existing registries. The initial values for MP-TLV applicability defined in the followingsub-sectionssubsections are based on the rule that MP-TLV is applicable to any codepoint that supports sub-TLVs, without regard to whether the sub-TLVs that are currently defined are sufficient to require MP-TLVs to be sent. </t> <sectionanchor="Top-Level" title="MP-TLVanchor="Top-Level"> <name>MP-TLV for IS-IS Top-Level TLVCodepoints"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints"/>) </t>Codepoints</name> <table anchor="table_top"> <name>IS-IS Top-Level TLV Codepoints</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1</td> <td>Area Addresses</td> <td>N</td> </tr> <tr> <td>2</td> <td>IIS Neighbors</td> <td>N</td> </tr> <tr> <td>3</td> <td>ES Neighbors</td> <td>N</td> </tr> <tr> <td>4</td> <td>Part. DIS</td> <td>N</td> </tr> <tr> <td>5</td> <td>Prefix Neighbors</td> <td>N</td> </tr> <tr> <td>6</td> <td>IIS Neighbors</td> <td>N</td> </tr> <tr> <td>7</td> <td>Instance Identifier</td> <td>Y</td> </tr> <tr> <td>8</td> <td>Padding</td> <td>N</td> </tr> <tr> <td>9</td> <td>LSP Entries</td> <td>N</td> </tr> <tr> <td>10</td> <td>Authentication</td> <td>N</td> </tr> <tr> <td>11</td> <td>ESN TLV</td> <td>N</td> </tr> <tr> <td>12</td> <td>Opt. Checksum</td> <td>N</td> </tr> <tr> <td>13</td> <td>Purge Originator Identification</td> <td>N</td> </tr> <tr> <td>14</td> <td>LSPBufferSize</td> <td>N</td> </tr> <tr> <td>15</td> <td>Router-Fingerprint</td> <td>N</td> </tr> <tr> <td>16</td> <td>Reverse Metric</td> <td>N</td> </tr> <tr> <td>17</td> <td>IS-IS Area Node IDs TLV</td> <td>N</td> </tr> <tr> <td>18</td> <td>IS-IS Flooding Path TLV</td> <td>N</td> </tr> <tr> <td>19</td> <td>IS-IS Flooding Request TLV</td> <td>N</td> </tr> <tr> <td>20</td> <td>Area Proxy</td> <td>Y</td> </tr> <tr> <td>21</td> <td>Flooding Parameters TLV</td> <td>Y</td> </tr> <tr> <td>22</td> <td>Extended IS reachability</td> <td>Y</td> </tr> <tr> <td>23</td> <td>IS Neighbor Attribute</td> <td>Y</td> </tr> <tr> <td>24</td> <td>IS Alias ID</td> <td>N</td> </tr> <tr> <td>25</td> <td>L2 Bundle Member Attributes</td> <td>Y</td> </tr> <tr> <td>26</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>27</td> <td>SRv6 Locator</td> <td>Y</td> </tr> <tr> <td>28-41</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>42</td> <td>DECnet Phase IV</td> <td>N</td> </tr> <tr> <td>43-65</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>66</td> <td>Lucent Proprietary</td> <td>N</td> </tr> <tr> <td>67-125</td> <td>Unassigned</td><td></td><td/> </tr> <!-- [rfced] We removed "TLV" from these entries to match what appears in the IANA registry. 126 IPv4 Algorithm Prefix Reachability TLV N 127 IPv6 Algorithm Prefix Reachability TLV N --> <tr> <td>126</td> <td>IPv4 Algorithm PrefixReachability TLV</td>Reachability</td> <td>N</td> </tr> <tr> <td>127</td> <td>IPv6 Algorithm PrefixReachability TLV</td>Reachability</td> <td>N</td> </tr> <tr> <td>128</td> <td>IP Int. Reach</td> <td>N</td> </tr> <tr> <td>129</td> <td>Prot. Supported</td> <td>N</td> </tr> <tr> <td>130</td> <td>IP Ext. Address</td> <td>N</td> </tr> <tr> <td>131</td> <td>IDRPI</td> <td>N</td> </tr> <tr> <td>132</td> <td>IP Intf. Address</td> <td>N</td> </tr> <tr> <td>133</td> <td>Illegal</td> <td>N</td> </tr> <tr> <td>134</td> <td>Traffic Engineering router ID</td> <td>N</td> </tr> <tr> <td>135</td> <td>Extended IP reachability</td> <td>Y</td> </tr> <tr> <td>136</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>137</td> <td>Dynamic Name</td> <td>N</td> </tr> <tr> <td>138</td> <td>GMPLS-SRLG</td> <td>Y</td> </tr> <tr> <td>139</td> <td>IPv6 SRLG</td> <td>N</td> </tr> <tr> <td>140</td> <td>IPv6 TE Router ID</td> <td>N</td> </tr> <tr> <td>141</td> <td>inter-AS reachability information</td> <td>Y</td> </tr> <tr> <td>142</td> <td>GADDR-TLV</td> <td>Y</td> </tr> <tr> <td>143</td> <td>MT-Port-Cap-TLV</td> <td>Y</td> </tr> <tr> <td>144</td> <td>MT-Capability TLV</td> <td>Y</td> </tr> <tr> <td>145</td> <td>TRILL Neighbor TLV</td> <td>N</td> </tr> <tr> <td>146</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>147</td> <td>MAC-RI TLV</td> <td>Y</td> </tr> <tr> <td>148</td> <td>BFD-Enabled TLV</td> <td>Y</td> </tr> <tr> <td>149</td> <td>Segment Identifier / Label Binding</td> <td>Y</td> </tr> <tr> <td>150</td> <td>Multi-Topology Segment Identifier / Label Binding</td> <td>Y</td> </tr> <tr> <td>151-160</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>161</td> <td>Flood Reflection</td> <td>N</td> </tr> <tr> <td>162-175</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>176</td> <td>Nortel Proprietary</td> <td>N</td> </tr> <tr> <td>177</td> <td>Nortel Proprietary</td> <td>N</td> </tr> <tr> <td>178-210</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>211</td> <td>Restart TLV</td> <td>N</td> </tr> <tr> <td>212-221</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>222</td> <td>MT-ISN</td> <td>Y</td> </tr> <tr> <td>223</td> <td>MT IS Neighbor Attribute</td> <td>Y</td> </tr> <tr> <td>224-228</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>229</td> <td>M-Topologies</td> <td>N</td> </tr> <tr> <td>230-231</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>232</td> <td>IPv6 Intf. Addr.</td> <td>N</td> </tr> <tr> <td>233</td> <td>IPv6 Global Interface Address TLV</td> <td>N</td> </tr> <tr> <td>234</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>235</td> <td>MT IP. Reach</td> <td>Y</td> </tr> <tr> <td>236</td> <td>IPv6 IP. Reach</td> <td>Y</td> </tr> <tr> <td>237</td> <td>MT IPv6 IP. Reach</td> <td>Y</td> </tr> <tr> <td>238</td> <td>Application-Specific SRLG</td> <td>Y</td> </tr> <tr> <td>239</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>240</td> <td>P2P 3-Way Adj. State</td> <td>N</td> </tr> <tr> <td>241</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>242</td> <td>IS-IS Router CAPABILITY TLV</td> <td>Y</td> </tr> <tr> <td>243</td> <td>Scope Flooding Support</td> <td>N</td> </tr> <tr> <td>244-250</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>251</td> <td>Generic Information</td> <td>Y</td> </tr> <tr> <td>252-65535</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="ReverseMetric" title="MP-TLVanchor="ReverseMetric"> <name>MP-TLV for IS-IS Sub-TLVs for Reverse MetricTLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-16"/>) </t>TLV</name> <table anchor="table_rev"> <name>IS-IS Sub-TLVs for Reverse Metric TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1-17</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>18</td> <td>Traffic Engineering Metric</td> <td>N</td> </tr> <tr> <td>19-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="NeighborInfo" title="MP-TLVanchor="NeighborInfo"> <name>MP-TLV for IS-IS Sub-TLVs for TLVs Advertising NeighborInformation"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information"/>) </t>Information</name> <table anchor="table_nei"> <name>IS-IS Sub-TLVs for TLVs Advertising Neighbor Information</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0-2</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>3</td> <td>Administrative group (color)</td> <td>N</td> </tr> <tr> <td>4</td> <td>Link Local/Remote Identifiers</td> <td>N</td> </tr> <tr> <td>5</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>6</td> <td>IPv4 interface address</td> <td>N</td> </tr> <tr> <td>7</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>8</td> <td>IPv4 neighbor address</td> <td>N</td> </tr> <tr> <td>9</td> <td>Maximum link bandwidth</td> <td>N</td> </tr> <tr> <td>10</td> <td>Maximum reservable link bandwidth</td> <td>N</td> </tr> <tr> <td>11</td> <td>Unreserved bandwidth</td> <td>N</td> </tr> <tr> <td>12</td> <td>IPv6 Interface Address</td> <td>N</td> </tr> <tr> <td>13</td> <td>IPv6 Neighbor Address</td> <td>N</td> </tr> <tr> <td>14</td> <td>Extended Administrative Group</td> <td>N</td> </tr> <tr> <td>15</td> <td>Link MSD</td> <td>Y</td> </tr> <tr> <td>16</td> <td>Application-Specific Link Attributes</td> <td>Y</td> </tr> <tr> <td>17</td> <td>Generic Metric</td> <td>N</td> </tr> <tr> <td>18</td> <td>TE Default metric</td> <td>N</td> </tr> <tr> <td>19</td> <td>Link-attributes</td> <td>N</td> </tr> <tr> <td>20</td> <td>Link Protection Type</td> <td>N</td> </tr> <tr> <td>21</td> <td>Interface Switching Capability Descriptor</td> <td>Y</td> </tr> <tr> <td>22</td> <td>Bandwidth Constraints</td> <td>N</td> </tr> <tr> <td>23</td> <td>Unconstrained TE LSP Count (sub-)TLV</td> <td>N</td> </tr> <tr> <td>24</td> <td>Remote AS Number</td> <td>N</td> </tr> <tr> <td>25</td> <td>IPv4 Remote ASBR Identifier</td> <td>N</td> </tr> <tr> <td>26</td> <td>IPv6 Remote ASBR Identifier</td> <td>N</td> </tr> <tr> <td>27</td> <td>Interface Adjustment Capability Descriptor (IACD)</td> <td>Y</td> </tr> <tr> <td>28</td> <td>MTU</td> <td>N</td> </tr> <tr> <td>29</td> <td>SPB-Metric</td> <td>N</td> </tr> <tr> <td>30</td> <td>SPB-A-OALG</td> <td>Y</td> </tr> <tr> <td>31</td> <td>Adjacency Segment Identifier</td> <td>N</td> </tr> <tr> <td>32</td> <td>LAN Adjacency Segment Identifier</td> <td>N</td> </tr> <tr> <td>33</td> <td>Unidirectional Link Delay</td> <td>N</td> </tr> <tr> <td>34</td> <td>Min/Max Unidirectional Link Delay</td> <td>N</td> </tr> <tr> <td>35</td> <td>Unidirectional Delay Variation</td> <td>N</td> </tr> <tr> <td>36</td> <td>Unidirectional Link Loss</td> <td>N</td> </tr> <tr> <td>37</td> <td>Unidirectional Residual Bandwidth</td> <td>N</td> </tr> <tr> <td>38</td> <td>Unidirectional Available Bandwidth</td> <td>N</td> </tr> <tr> <td>39</td> <td>Unidirectional Utilized Bandwidth</td> <td>N</td> </tr> <tr> <td>40</td> <td>RTM Capability</td> <td>N</td> </tr> <tr> <td>41</td> <td>L2 Bundle Member Adj-SID</td> <td>Y</td> </tr> <tr> <td>42</td> <td>L2 Bundle Member LAN Adj-SID</td> <td>Y</td> </tr> <tr> <td>43</td> <td>SRv6 End.X SID</td> <td>Y</td> </tr> <tr> <td>44</td> <td>SRv6 LAN End.X SID</td> <td>Y</td> </tr> <tr> <td>45</td> <td>IPv6 Local ASBR Identifier</td> <td>N</td> </tr> <tr> <td>46-160</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>161</td> <td>Flood Reflector Adjacency</td> <td>N</td> </tr> <tr> <td>162-249</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>250-254</td> <td>Reserved for Cisco-specific extensions</td><td></td><td/> </tr> <tr> <td>255</td> <td>Reserved for future expansion</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="PrefixReach" title="MP-TLVanchor="PrefixReach"> <name>MP-TLV for IS-IS Sub-TLVs for TLVs Advertising PrefixReachability"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability"/>) </t>Reachability</name> <table anchor="table_pfx"> <name>IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>1</td> <td>32-bit Administrative Tag Sub-TLV</td> <td>Y</td> </tr> <tr> <td>2</td> <td>64-bit Administrative Tag Sub-TLV</td> <td>Y</td> </tr> <tr> <td>3</td> <td>Prefix Segment Identifier</td> <td>N</td> </tr> <tr> <td>4</td> <td>Prefix Attribute Flags</td> <td>N</td> </tr> <tr> <td>5</td> <td>SRv6 End SID</td> <td>Y</td> </tr> <tr> <td>6</td> <td>Flexible Algorithm Prefix Metric (FAPM)</td> <td>N</td> </tr> <tr> <td>7-10</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>11</td> <td>IPv4 Source Router ID</td> <td>N</td> </tr> <tr> <td>12</td> <td>IPv6 Source Router ID</td> <td>N</td> </tr> <tr> <td>13-31</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>32</td> <td>BIER Info</td> <td>Y</td> </tr> <tr><td>32-255</td><!-- [rfced] Table 4: Note that we updated the Unassigned values to be 33-255, as value 32 is assigned to "BIER Info". Original: | 32 | BIER Info | Y | | 32-255 | Unassigned | | --> <td>33-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="MT-Capability" title="MP-TLVanchor="MT-Capability"> <name>MP-TLV for IS-IS Sub-TLVs for MT-CapabilityTLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-144"/>) </t>TLV</name> <table anchor="table_mt"> <name>IS-IS Sub-TLVs for MT-Capability TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1</td> <td>SPB-Inst</td> <td>N</td> </tr> <tr> <td>2</td> <td>SPB-I-OALG</td> <td>Y</td> </tr> <tr> <td>3</td> <td>SPBM-SI</td> <td>Y</td> </tr> <tr> <td>4</td> <td>SPBV-ADDR</td> <td>Y</td> </tr> <tr> <td>5</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>6</td> <td>NICKNAME</td> <td>Y</td> </tr> <tr> <td>7</td> <td>TREES</td> <td>N</td> </tr> <tr> <td>8</td> <td>TREE-RT-IDs</td> <td>Y</td> </tr> <tr> <td>9</td> <td>TREE-USE-IDs</td> <td>Y</td> </tr> <tr> <td>10</td> <td>INT-VLAN</td> <td>Y</td> </tr> <tr> <td>11-12</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>13</td> <td>TRILL-VER</td> <td>N</td> </tr> <tr> <td>14</td> <td>VLAN-GROUP</td> <td>Y</td> </tr> <tr> <td>15</td> <td>INT-LABEL</td> <td>Y</td> </tr> <tr> <td>16</td> <td>RBCHANNELS</td> <td>Y</td> </tr> <tr> <td>17</td> <td>AFFINITY</td> <td>Y</td> </tr> <tr> <td>18</td> <td>LABEL-GROUP</td> <td>Y</td> </tr> <tr> <td>19-20</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>21</td> <td>Topology sub-TLV</td> <td>Y</td> </tr> <tr> <td>22</td> <td>Hop sub-TLV</td> <td>N</td> </tr> <tr> <td>23</td> <td>Bandwidth Constraint sub-TLV</td> <td>N</td> </tr> <tr> <td>24</td> <td>Bandwidth Assignment sub-TLV</td> <td>N</td> </tr> <tr> <td>25</td> <td>Timestamp sub-TLV</td> <td>N</td> </tr> <tr> <td>26-254</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>255</td> <td>Reserved</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="Router_cap" title="MP-TLVanchor="Router_cap"> <name>MP-TLV for IS-IS Sub-TLVs for IS-IS Router CAPABILITYTLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242"/>) </t>TLV</name> <table anchor="table_cap"> <name>IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1</td> <td>TE Node Capability Descriptor</td> <td>N</td> </tr> <tr> <td>2</td> <td>Segment Routing Capability</td> <td>N</td> </tr> <tr> <td>3</td> <td>TE-MESH-GROUP TLV (IPv4)</td> <td>Y</td> </tr> <tr> <td>4</td> <td>TE-MESH-GROUP TLV (IPv6)</td> <td>Y</td> </tr> <tr> <td>5</td> <td>PCED sub-TLV</td> <td>N</td> </tr> <tr> <td>6</td> <td>NICKNAME</td> <td>Y</td> </tr> <tr> <td>7</td> <td>TREES</td> <td>N</td> </tr> <tr> <td>8</td> <td>TREE-RT-IDs</td> <td>Y</td> </tr> <tr> <td>9</td> <td>TREE-USE-IDs</td> <td>Y</td> </tr> <tr> <td>10</td> <td>INT-VLAN</td> <td>Y</td> </tr> <tr> <td>11</td> <td>IPv4 TE Router ID</td> <td>N</td> </tr> <tr> <td>12</td> <td>IPv6 TE Router ID</td> <td>N</td> </tr> <tr> <td>13</td> <td>TRILL-VER</td> <td>N</td> </tr> <tr> <td>14</td> <td>VLAN-GROUP</td> <td>Y</td> </tr> <tr> <td>15</td> <td>INT-LABEL</td> <td>Y</td> </tr> <tr> <td>16</td> <td>RBCHANNELS</td> <td>Y</td> </tr> <tr> <td>17</td> <td>AFFINITY</td> <td>Y</td> </tr> <tr> <td>18</td> <td>LABEL-GROUP</td> <td>Y</td> </tr> <tr> <td>19</td> <td>Segment Routing Algorithm</td> <td>N</td> </tr> <tr> <td>20</td> <td>S-BFD Discriminators</td> <td>N</td> </tr> <tr> <td>21</td> <td>Node-Admin-Tag</td> <td>N</td> </tr> <tr> <td>22</td> <td>Segment Routing Local Block (SRLB)</td> <td>N</td> </tr> <tr> <td>23</td> <td>Node MSD</td> <td>Y</td> </tr> <tr> <td>24</td> <td>Segment Routing Mapping Server Preference (SRMS Preference)</td> <td>N</td> </tr> <tr> <td>25</td> <td>SRv6 Capabilities</td> <td>N</td> </tr> <tr> <td>26</td> <td>Flexible Algorithm Definition (FAD)</td> <td>N</td> </tr> <tr> <td>27</td> <td>IS-IS Area Leader Sub-TLV</td> <td>N</td> </tr> <tr> <td>28</td> <td>IS-IS Dynamic Flooding Sub-TLV</td> <td>N</td> </tr> <tr> <td>29</td> <td>IP Algorithm Sub-TLV</td> <td>N</td> </tr> <!-- [rfced] We believe it is intentional that value 30, assigned to "MP-TLV Support for TLVs with implicit support" in this document, is not listed in Table 6. Please let us know if this is incorrect. Original: | 30-160 | Unassigned | | --> <tr> <td>30-160</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>161</td> <td>Flood Reflection Discovery</td> <td>Y</td> </tr> <tr> <td>162-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="cap_sub" title="IS-ISanchor="cap_sub"> <name>IS-IS Sub-Sub-TLVs for SRv6 CapabilitiesSub-TLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-sub-sub-tlv-srv6-capability"/>) </t>Sub-TLV</name> <table anchor="table_cap_sub"> <name>IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="BIER_SUB" title="MP-TLVanchor="BIER_SUB"> <name>MP-TLV IS-IS Sub-Sub-TLVs for BIER InfoSub-TLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#bier-info-sub-tlv"/>) </t>Sub-TLV</name> <table anchor="table_bier_sub"> <name>IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>1</td> <td>BIER MPLS Encapsulation</td> <td>N</td> </tr> <tr> <td>2</td> <td>BIER PHP Request</td> <td>N</td> </tr> <tr> <td>3-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="segid_sub" title="MP-TLVanchor="segid_sub"> <name>MP-TLV for IS-IS Sub-TLVs for Segment Identifier/Label BindingTLVs"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-149-150"/>) </t>TLVs</name> <table anchor="table_segid_sub"> <name>IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1</td> <td>SID/Label</td> <td>N</td> </tr> <tr> <td>2</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>3</td> <td>Prefix Segment Identifier</td> <td>N</td> </tr> <tr> <td>4-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="sub_sub_asla" title="MP-TLVanchor="sub_sub_asla"> <name>MP-TLV for IS-IS Sub-Sub-TLV Codepoints for Application-Specific LinkAttributes"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#application-specific-link-attributes"/>) </t>Attributes</name> <table anchor="table_sub_sub_asla"> <name>IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0-2</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>3</td> <td>Administrative group (color)</td> <td>N</td> </tr> <tr> <td>4-8</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>9</td> <td>Maximum link bandwidth</td> <td>N</td> </tr> <tr> <td>10</td> <td>Maximum reservable link bandwidth</td> <td>N</td> </tr> <tr> <td>11</td> <td>Unreserved bandwidth</td> <td>N</td> </tr> <tr> <td>12-13</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>14</td> <td>Extended Administrative Group</td> <td>N</td> </tr> <tr> <td>15-16</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>17</td> <td>Generic Metric</td> <td>Y</td> </tr> <tr> <td>18</td> <td>TE DefaultMetric</td>metric</td> <td>N</td> </tr> <tr> <td>19-32</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>33</td> <td>Unidirectional Link Delay</td> <td>N</td> </tr> <tr> <td>34</td> <td>Min/Max Unidirectional Link Delay</td> <td>N</td> </tr> <tr> <td>35</td> <td>Unidirectional Delay Variation</td> <td>N</td> </tr> <tr> <td>36</td> <td>Unidirectional Link Loss</td> <td>N</td> </tr> <tr> <td>37</td> <td>Unidirectional Residual Bandwidth</td> <td>N</td> </tr> <tr> <td>38</td> <td>Unidirectional Available Bandwidth</td> <td>N</td> </tr> <tr> <td>39</td> <td>Unidirectional Utilized Bandwidth</td> <td>N</td> </tr> <tr> <td>40-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="srlg_sub" title="MP-TLVanchor="srlg_sub"> <name>MP-TLV for IS-IS Sub-TLVs for Application-Specific SRLGTLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-238"/>) </t>TLV</name> <table anchor="table_srlg_sub"> <name>IS-IS Sub-TLVs for Application-Specific SRLG TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0-3</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>4</td> <td>Link Local/Remote Identifiers</td> <td>N</td> </tr> <tr> <td>5</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>6</td> <td>IPv4 interface address</td> <td>N</td> </tr> <tr> <td>7</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>8</td> <td>IPv4 neighbor address</td> <td>N</td> </tr> <tr> <td>9-11</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>12</td> <td>IPv6 Interface Address</td> <td>N</td> </tr> <tr> <td>13</td> <td>IPv6 Neighbor Address</td> <td>N</td> </tr> <tr> <td>14-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="SRv6_sub_sub" title="MP-TLVanchor="SRv6_sub_sub"> <name>MP-TLV for IS-IS Sub-Sub-TLVs for SRv6 SIDSub-TLVs"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-sub-sub-tlvs-srv6-sid-sub-tlvs"/>) </t>Sub-TLVs</name> <table anchor="table_srv6_subsub"> <name>IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1</td> <td>SRv6 SID Structure</td> <td>N</td> </tr> <tr> <td>2-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="Flex_sub_sub" title="MP-TLVanchor="Flex_sub_sub"> <name>MP-TLV for IS-IS Sub-Sub-TLVs for Flexible Algorithm DefinitionSub-TLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-sub-sub-tlvs-flexible-algorithm-definition-sub-tlv"/>) </t>Sub-TLV</name> <table anchor="table_flex_subsub"> <name>IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td><td></td><td/> </tr> <tr> <td>1</td> <td>Flexible Algorithm Exclude Admin Group</td> <td>N</td> </tr> <tr> <td>2</td> <td>Flexible Algorithm Include-Any Admin Group</td> <td>N</td> </tr> <tr> <td>3</td> <td>Flexible Algorithm Include-All Admin Group</td> <td>N</td> </tr> <tr> <td>4</td> <td>Flexible Algorithm Definition Flags</td> <td>N</td> </tr> <tr> <td>5</td> <td>Flexible Algorithm Exclude SRLG</td> <td>N</td> </tr> <tr> <td>6</td> <td>IS-IS Exclude Minimum Bandwidth</td> <td>N</td> </tr> <tr> <td>7</td> <td>IS-IS Exclude Maximum Delay</td> <td>N</td> </tr> <tr> <td>8</td> <td>IS-IS Reference Bandwidth</td> <td>N</td> </tr> <!-- [rfced] Note that we have updated the Description for Type 9 in Table 13 to match what appears in the IANA registry. Original: | 9 | IS-IS Threshold Metric | N | Current: | 9 | IS-IS Bandwidth Metric | N | --> <tr> <td>9</td> <td>IS-ISThresholdBandwidth Metric</td> <td>N</td> </tr> <tr> <td>10-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> <sectionanchor="reflect_sub" title="MP-TLVanchor="reflect_sub"> <name>MP-TLV for IS-IS Sub-Sub-TLVs for Flood Reflection DiscoverySub-TLV"> <t> (<eref target="https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-sub-sub-tlvs-flood-reflection-discovery-sub-tlv"/>) </t>Sub-TLV</name> <table anchor="table_reflect_sub"> <name>IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV</name> <thead> <tr><th align='center'>Value</th> <th align='center'>Name</th> <th align='center'>MP</th><th>Value</th> <th>Name</th> <th>MP</th> </tr> </thead> <tbody> <tr> <td>0-160</td> <td>Unassigned</td><td></td><td/> </tr> <tr> <td>161</td> <td>Flood Reflection Discovery Tunnel Encapsulation Attribute</td> <td>N</td> </tr> <tr> <td>162-255</td> <td>Unassigned</td><td></td><td/> </tr> </tbody> </table> </section> </section> </section> <sectionanchor="Security" title="Security Considerations">anchor="Security"> <name>Security Considerations</name> <t> This document creates no new security issues for IS-IS. Additional instances of existing TLVs expose no new information. </t> <t> Note that support for MP-TLV may result in an implementation being more robust in handling unexpected occurrences of MP-TLV. </t> <t> Security concerns for IS-IS are addressed in <xref target="ISO10589"/>, <xref target="RFC5304"/>, and <xref target="RFC5310"/>. </t> </section><section anchor="Contrib" title="Contributors"> <t>The following people gave a substantial contribution to the content of this document and should be considered coauthors:</t> <contact fullname="Chris Bowers" initials="C." surname="Bowers"> <address> <email>cbowers107@gmail.com</email> </address> </contact> </section></middle> <back><references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include='reference.RFC.5120'?> <?rfc include='reference.RFC.5304'?> <?rfc include='reference.RFC.5305'?> <?rfc include='reference.RFC.5307'?> <?rfc include='reference.RFC.5310'?> <?rfc include='reference.RFC.6119'?> <?rfc include='reference.RFC.6213'?> <?rfc include='reference.RFC.7356'?> <?rfc include='reference.RFC.7981'?> <?rfc include='reference.RFC.8174'?> <?rfc include='reference.RFC.8202'?> <?rfc include='reference.RFC.8918'?> <?rfc include='reference.RFC.9479'?><displayreference target="I-D.ietf-lsr-isis-pics-yang" to="PICS-YANG"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6213.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7356.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7981.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8202.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8918.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9479.xml"/> <reference anchor="ISO10589"target="ISO/IEC 10589:2002">target="https://www.iso.org/standard/30932.html"> <front><title><title>Information technology - Telecommunications and information exchange between systems - IntermediatesystemSystem to Intermediatesystem routingSystem intra-domain routeing information exchange protocol for use in conjunction with theProtocolprotocol for providing theConnectionless-mode Network Serviceconnectionless-mode network service (ISO 8473) </title><author fullname="ISO" initials="" surname="ISO"> <organization>IANA</organization><author> <organization>ISO/IEC</organization> </author> <date month="November" year="2002"/> </front> <seriesInfo name="ISO/IEC" value="10589:2002"/> </reference> </references><references title="Informative References"> <?rfc include='reference.I-D.ietf-lsr-isis-pics-yang'?><references> <name>Informative References</name> <!-- [I-D.ietf-lsr-isis-pics-yang] draft-ietf-lsr-isis-pics-yang-01 IESG State: I-D Exists --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-isis-pics-yang.xml"/> </references> </references> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <section anchor="Contrib" numbered="false"> <name>Contributors</name> <t>The following individual made a substantial contribution to the content of this document and should be considered a coauthor:</t> <contact fullname="Chris Bowers" initials="C." surname="Bowers"> <address> <email>cbowers107@gmail.com</email> </address> </contact> </section> </back> </rfc>