Juniper Networks

Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India pkaneria@juniper.net

Juniper Networks

1133 Innovation Way Sunnyvale California 94089 United States of America tony.li@tony.li

Juniper Networks

1133 Innovation Way Sunnyvale California 94089 United States of America prz@juniper.net

Juniper Networks

Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India shraddha@juniper.net

Cisco Systems

ginsberg@cisco.com

RTG lsr 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.

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 at .

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 () 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

• .  Introduction
• .  Requirements Language
• .  Overview of MP-TLV Applicability to TLVs
  • .  TLVs that Advertise a List of Objects
  • .  TLVs that Advertise Objects with Identifier(s)
    • .  Example: Extended IS Reachability
    • .  Example: Extended IP Reachability
• .  Multi-Part TLVs
• .  Procedure for Receiving Multi-Part TLVs
• .  Specification of Applicability of Multi-Part TLVs
• .  MP-TLV Capability Advertisement
• .  Deployment Considerations
  • .  Controls and Alarms
  • .  Restrictions on Generation of MP-TLVs
• .  IANA Considerations
  • .  MP-TLV Support Sub-TLV
  • .  Extension to IS-IS Top-Level TLV Registries
    • .  MP-TLV for IS-IS Top-Level TLV Codepoints
    • .  MP-TLV for IS-IS Sub-TLVs for Reverse Metric TLV
    • .  MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
    • .  MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability
    • .  MP-TLV for IS-IS Sub-TLVs for MT-Capability TLV
    • .  MP-TLV for IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV
    • .  IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV
    • .  MP-TLV IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV
    • .  MP-TLV for IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs
    • . MP-TLV for IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes
    • . MP-TLV for IS-IS Sub-TLVs for Application-Specific SRLG TLV
    • . MP-TLV for IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs
    • . MP-TLV for IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
    • . MP-TLV for IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV
• . Security Considerations
• . References
  • .  Normative References
  • .  Informative References
• Contributors
• Authors' Addresses

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 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, defines the Extended IS reachability TLV (22) and 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)
• Application-Specific SRLG (Type 238)
• Instance Identifier (Type 7)
• Application-Specific Link Attributes (sub-TLV Type 16)

has defined a 16-bit Length field for TLVs in flooding scoped Protocol Data Units (PDUs). The problem addressed by this document would likely not be encountered when 16-bit Length TLVs are in use. 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 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.

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 when, and only when, they appear in all capitals, as shown here.

Overview of MP-TLV Applicability to TLVs 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 following subsections.

TLVs that Advertise a List of Objects Some TLVs are simply a list of objects of a given type. For example, the BFD-Enabled TLV (Type 148) 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.

TLVs that Advertise Objects with Identifier(s) 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.

Example: Extended IS Reachability As an example, consider the Extended IS reachability TLV (Type 22) . A neighbor in this TLV is specified by:

• 7 octets of a system ID and pseudonode number
• 3 octets of a default metric
• Optionally, one or more of the following link identifiers encoded as sub-TLVs:
  • an IPv4 interface address and IPv4 neighbor address as specified in
  • an IPv6 interface address and IPv6 neighbor address as specified in
  • Link Local/Remote Identifiers as specified in

The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers that are present.

Example: Extended IP Reachability As another example, consider the Extended IP reachability TLV (Type 135) . A prefix in this TLV is specified by:

• 4 octets of metric information
• 1 octet of control information that includes 6 bits specifying the prefix length
• 0-4 octets of an IPv4 prefix

The above are followed by up to 250 octets of sub-TLV information. The key consists of the 6 bits of prefix length plus 0-4 octets of an IPv4 prefix.

Multi-Part TLVs 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). 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 condition when a TLV moves from one LSP to another or as a result of a defect in the sending implementation. In the presence of MP-TLV support, when a router receives an MP-TLV, information from all the TLVs is processed. 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. 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. 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. Breaking of a data unit across TLVs results in an invalid encoding. Guidelines to receivers for handling such a case are specified in .

Procedure for Receiving Multi-Part TLVs 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 the TLV parts in LSP fragments is irrelevant. Multiple TLV parts MAY occur in a single LSP or parts MAY occur in different LSPs. The placement of the TLV parts in an IIH is irrelevant. When processing MP-TLVs, implementations MUST NOT impose a minimum length check. Although MP-TLVs SHOULD NOT be sent unless the capacity of a single TLV (255 octets) is exceeded, receivers MUST 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 bytes MUST NOT cause the TLVs to be rejected. See for guidance on sending MP-TLVs. The contents of an MP-TLV MUST be processed as if they were concatenated. If the internals of the TLV contain key information, then replication of the key information MUST be taken to indicate that subsequent data MUST 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.

Specification of Applicability of Multi-Part TLVs As mentioned in , 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 . 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. See . Therefore, any new codepoints defined by future protocol extensions will explicitly indicate the applicability of MP-TLV procedures to the new codepoints.

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 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) . This advertisement is for informational purposes only. IS-IS protocol implementations MUST 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 .

Deployment Considerations 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. 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 is important to avoid interoperability issues.

Controls and Alarms It is RECOMMENDED that implementations that support the sending of MP-TLVs provide configuration controls that enable/disable generation of MP-TLVs. Given that MP-TLV support in a given implementation may vary on a per-TLV basis, these controls SHOULD provide support at a per-codepoint granularity. For example, an implementation might support MP-TLVs for IS Extended Reachability but not for IP Reachability. Implementations that support disablement of MP-TLVs MUST log the following occurrences:

• An MP-TLV is received when use of MP-TLVs is disabled.
• Local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled.

Network operators SHOULD NOT enable MP-TLVs until ensuring that all implementations that will receive the MP-TLVs are capable of interpreting them correctly as described in .

Restrictions on Generation of MP-TLVs 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 . 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. Implementations SHOULD NOT 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, information SHOULD NOT be split into multiple TLVs. If there is no space in the current LSP to fit the now larger TLV, the TLV SHOULD be moved to a new LSP.

IANA Considerations

MP-TLV Support Sub-TLV IANA has registered the following codepoint from the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry (see ):

Type:

30

Description:

MP-TLV Support for TLVs with Implicit Support

MP-TLV Applicability:

N

Reference:

of RFC 9885

Extension to IS-IS Top-Level TLV Registries IANA has extended a number of registries within the "IS-IS TLV Codepoints" registry group 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. The following subsections provide the initial contents of the new column for a number of existing registries. The initial values for MP-TLV applicability defined in the following subsections 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. To access the relevant IANA registry, search for the registry name associated with each subsection at .

MP-TLV for IS-IS Top-Level TLV Codepoints IANA has added the MP column to the "IS-IS Top-Level TLV Codepoints" registry and populated it as shown in . IS-IS Top-Level TLV Codepoints

Value	Name	MP
0	Reserved
1	Area Addresses	N
2	IIS Neighbors	N
3	ES Neighbors	N
4	Part. DIS	N
5	Prefix Neighbors	N
6	IIS Neighbors	N
7	Instance Identifier	Y
8	Padding	N
9	LSP Entries	N
10	Authentication	N
11	ESN TLV	N
12	Opt. Checksum	N
13	Purge Originator Identification	N
14	LSPBufferSize	N
15	Router-Fingerprint	N
16	Reverse Metric	N
17	IS-IS Area Node IDs TLV	N
18	IS-IS Flooding Path TLV	N
19	IS-IS Flooding Request TLV	N
20	Area Proxy	Y
21	Flooding Parameters TLV	Y
22	Extended IS reachability	Y
23	IS Neighbor Attribute	Y
24	IS Alias ID	N
25	L2 Bundle Member Attributes	Y
26	Unassigned
27	SRv6 Locator	Y
28-41	Unassigned
42	DECnet Phase IV	N
43-65	Unassigned
66	Lucent Proprietary	N
67-125	Unassigned
126	IPv4 Algorithm Prefix Reachability	N
127	IPv6 Algorithm Prefix Reachability	N
128	IP Int. Reach	N
129	Prot. Supported	N
130	IP Ext. Address	N
131	IDRPI	N
132	IP Intf. Address	N
133	Illegal	N
134	Traffic Engineering router ID	N
135	Extended IP reachability	Y
136	Unassigned
137	Dynamic Name	N
138	GMPLS-SRLG	Y
139	IPv6 SRLG	N
140	IPv6 TE Router ID	N
141	inter-AS reachability information	Y
142	GADDR-TLV	Y
143	MT-Port-Cap-TLV	Y
144	MT-Capability TLV	Y
145	TRILL Neighbor TLV	N
146	Unassigned
147	MAC-RI TLV	Y
148	BFD-Enabled TLV	Y
149	Segment Identifier / Label Binding	Y
150	Multi-Topology Segment Identifier / Label Binding	Y
151-160	Unassigned
161	Flood Reflection	N
162-175	Unassigned
176	Nortel Proprietary	N
177	Nortel Proprietary	N
178-210	Unassigned
211	Restart TLV	N
212-221	Unassigned
222	MT-ISN	Y
223	MT IS Neighbor Attribute	Y
224-228	Unassigned
229	M-Topologies	N
230-231	Unassigned
232	IPv6 Intf. Addr.	N
233	IPv6 Global Interface Address TLV	N
234	Unassigned
235	MT IP. Reach	Y
236	IPv6 IP. Reach	Y
237	MT IPv6 IP. Reach	Y
238	Application-Specific SRLG	Y
239	Unassigned
240	P2P 3-Way Adj. State	N
241	Unassigned
242	IS-IS Router CAPABILITY TLV	Y
243	Scope Flooding Support	N
244-250	Unassigned
251	Generic Information	Y
252-65535	Unassigned

MP-TLV for IS-IS Sub-TLVs for Reverse Metric TLV IANA has added the MP column to the "IS-IS Sub-TLVs for Reverse Metric TLV" registry and populated it as shown in . IS-IS Sub-TLVs for Reverse Metric TLV

Value	Name	MP
0	Reserved
1-17	Unassigned
18	Traffic Engineering Metric	N
19-255	Unassigned

MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Neighbor Information IANA has added the MP column to the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry and populated it as shown in . IS-IS Sub-TLVs for TLVs Advertising Neighbor Information

Value	Name	MP
0-2	Unassigned
3	Administrative group (color)	N
4	Link Local/Remote Identifiers	N
5	Unassigned
6	IPv4 interface address	N
7	Unassigned
8	IPv4 neighbor address	N
9	Maximum link bandwidth	N
10	Maximum reservable link bandwidth	N
11	Unreserved bandwidth	N
12	IPv6 Interface Address	N
13	IPv6 Neighbor Address	N
14	Extended Administrative Group	N
15	Link MSD	Y
16	Application-Specific Link Attributes	Y
17	Generic Metric	N
18	TE Default metric	N
19	Link-attributes	N
20	Link Protection Type	N
21	Interface Switching Capability Descriptor	Y
22	Bandwidth Constraints	N
23	Unconstrained TE LSP Count (sub-)TLV	N
24	Remote AS Number	N
25	IPv4 Remote ASBR Identifier	N
26	IPv6 Remote ASBR Identifier	N
27	Interface Adjustment Capability Descriptor (IACD)	Y
28	MTU	N
29	SPB-Metric	N
30	SPB-A-OALG	Y
31	Adjacency Segment Identifier	N
32	LAN Adjacency Segment Identifier	N
33	Unidirectional Link Delay	N
34	Min/Max Unidirectional Link Delay	N
35	Unidirectional Delay Variation	N
36	Unidirectional Link Loss	N
37	Unidirectional Residual Bandwidth	N
38	Unidirectional Available Bandwidth	N
39	Unidirectional Utilized Bandwidth	N
40	RTM Capability	N
41	L2 Bundle Member Adj-SID	Y
42	L2 Bundle Member LAN Adj-SID	Y
43	SRv6 End.X SID	Y
44	SRv6 LAN End.X SID	Y
45	IPv6 Local ASBR Identifier	N
46-160	Unassigned
161	Flood Reflector Adjacency	N
162-249	Unassigned
250-254	Reserved for Cisco-specific extensions
255	Reserved for future expansion

MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability IANA has added the MP column to the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry and populated it as shown in . IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability

Value	Name	MP
0	Unassigned
1	32-bit Administrative Tag Sub-TLV	Y
2	64-bit Administrative Tag Sub-TLV	Y
3	Prefix Segment Identifier	N
4	Prefix Attribute Flags	N
5	SRv6 End SID	Y
6	Flexible Algorithm Prefix Metric (FAPM)	N
7-10	Unassigned
11	IPv4 Source Router ID	N
12	IPv6 Source Router ID	N
13-31	Unassigned
32	BIER Info	Y
33-255	Unassigned

MP-TLV for IS-IS Sub-TLVs for MT-Capability TLV IANA has added the MP column to the "IS-IS Sub-TLVs for MT-Capability TLV" registry and populated it as shown in . IS-IS Sub-TLVs for MT-Capability TLV

Value	Name	MP
0	Reserved
1	SPB-Inst	N
2	SPB-I-OALG	Y
3	SPBM-SI	Y
4	SPBV-ADDR	Y
5	Unassigned
6	NICKNAME	Y
7	TREES	N
8	TREE-RT-IDs	Y
9	TREE-USE-IDs	Y
10	INT-VLAN	Y
11-12	Unassigned
13	TRILL-VER	N
14	VLAN-GROUP	Y
15	INT-LABEL	Y
16	RBCHANNELS	Y
17	AFFINITY	Y
18	LABEL-GROUP	Y
19-20	Unassigned
21	Topology sub-TLV	Y
22	Hop sub-TLV	N
23	Bandwidth Constraint sub-TLV	N
24	Bandwidth Assignment sub-TLV	N
25	Timestamp sub-TLV	N
26-254	Unassigned
255	Reserved

MP-TLV for IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV IANA has added the MP column to the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry and populated it as shown in . IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV

Value	Name	MP
0	Reserved
1	TE Node Capability Descriptor	N
2	Segment Routing Capability	N
3	TE-MESH-GROUP TLV (IPv4)	Y
4	TE-MESH-GROUP TLV (IPv6)	Y
5	PCED sub-TLV	N
6	NICKNAME	Y
7	TREES	N
8	TREE-RT-IDs	Y
9	TREE-USE-IDs	Y
10	INT-VLAN	Y
11	IPv4 TE Router ID	N
12	IPv6 TE Router ID	N
13	TRILL-VER	N
14	VLAN-GROUP	Y
15	INT-LABEL	Y
16	RBCHANNELS	Y
17	AFFINITY	Y
18	LABEL-GROUP	Y
19	Segment Routing Algorithm	N
20	S-BFD Discriminators	N
21	Node-Admin-Tag	N
22	Segment Routing Local Block (SRLB)	N
23	Node MSD	Y
24	Segment Routing Mapping Server Preference (SRMS Preference)	N
25	SRv6 Capabilities	N
26	Flexible Algorithm Definition (FAD)	N
27	IS-IS Area Leader Sub-TLV	N
28	IS-IS Dynamic Flooding Sub-TLV	N
29	IP Algorithm Sub-TLV	N
30-160	Unassigned
161	Flood Reflection Discovery	Y
162-255	Unassigned

IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV IANA has added the MP column to the "IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV" registry and populated it as shown in . IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV

Value	Name	MP
0	Reserved
1-255	Unassigned

MP-TLV IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV IANA has added the MP column to the "IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV" registry and populated it as shown in . IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV

Value	Name	MP
0	Unassigned
1	BIER MPLS Encapsulation	N
2	BIER PHP Request	N
3-255	Unassigned

MP-TLV for IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs IANA has added the MP column to the "IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs" registry and populated it as shown in . IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs

Value	Name	MP
0	Reserved
1	SID/Label	N
2	Unassigned
3	Prefix Segment Identifier	N
4-255	Unassigned

MP-TLV for IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes IANA has added the MP column to the "IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes" registry and populated it as shown in . IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes

Value	Name	MP
0-2	Unassigned
3	Administrative group (color)	N
4-8	Unassigned
9	Maximum link bandwidth	N
10	Maximum reservable link bandwidth	N
11	Unreserved bandwidth	N
12-13	Unassigned
14	Extended Administrative Group	N
15-16	Unassigned
17	Generic Metric	Y
18	TE Default metric	N
19-32	Unassigned
33	Unidirectional Link Delay	N
34	Min/Max Unidirectional Link Delay	N
35	Unidirectional Delay Variation	N
36	Unidirectional Link Loss	N
37	Unidirectional Residual Bandwidth	N
38	Unidirectional Available Bandwidth	N
39	Unidirectional Utilized Bandwidth	N
40-255	Unassigned

MP-TLV for IS-IS Sub-TLVs for Application-Specific SRLG TLV IANA has added the MP column to the "IS-IS Sub-TLVs for Application-Specific SRLG TLV" registry and populated it as shown in . IS-IS Sub-TLVs for Application-Specific SRLG TLV

Value	Name	MP
0-3	Unassigned
4	Link Local/Remote Identifiers	N
5	Unassigned
6	IPv4 interface address	N
7	Unassigned
8	IPv4 neighbor address	N
9-11	Unassigned
12	IPv6 Interface Address	N
13	IPv6 Neighbor Address	N
14-255	Unassigned

MP-TLV for IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs IANA has added the MP column to the "IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs" registry and populated it as shown in . IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs

Value	Name	MP
0	Reserved
1	SRv6 SID Structure	N
2-255	Unassigned

MP-TLV for IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV IANA has added the MP column to the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry and populated it as shown in . IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV

Value	Name	MP
0	Reserved
1	Flexible Algorithm Exclude Admin Group	N
2	Flexible Algorithm Include-Any Admin Group	N
3	Flexible Algorithm Include-All Admin Group	N
4	Flexible Algorithm Definition Flags	N
5	Flexible Algorithm Exclude SRLG	N
6	IS-IS Exclude Minimum Bandwidth	N
7	IS-IS Exclude Maximum Delay	N
8	IS-IS Reference Bandwidth	N
9	IS-IS Bandwidth Metric	N
10-255	Unassigned

MP-TLV for IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV IANA has added the MP column to the "IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV" registry and populated it as shown in . IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV

Value	Name	MP
0-160	Unassigned
161	Flood Reflection Discovery Tunnel Encapsulation Attribute	N
162-255	Unassigned

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 , , and .

References Normative References ISO/IEC In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK] This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK] This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK] This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK] Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length. The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs. This document obsoletes RFC 6822. The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit (PDU) is received. This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized. This document updates RFCs 5305 and 6232. Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support an indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. Informative References Futurewei Technologies Cisco Systems Juniper Networks Orange China Telecom The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). Work in Progress

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

cbowers107@gmail.com

Authors' Addresses Juniper Networks

Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India pkaneria@juniper.net

Juniper Networks

1133 Innovation Way Sunnyvale California 94089 United States of America tony.li@tony.li

Juniper Networks

1133 Innovation Way Sunnyvale California 94089 United States of America prz@juniper.net

Juniper Networks

Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India shraddha@juniper.net

Cisco Systems

ginsberg@cisco.com