RFC 9885
Multi-Part TLVs in IS-IS
Part 1 of 7 π
Okay bestie, let's get into RFC 9885 π¦ It's called Multi-Part TLVs in IS-IS, and it's a Standards Track doc from the IETF (Internet Engineering Task Force), so this is the real deal π The authors are P. Kaneriya, T. Li, A. Przygienda, and S. Hegde from Juniper Networks, plus L. Ginsberg from Cisco Systems. It was published in October 2025 with ISSN 2070-1721. The header has no Obsoletes or Updates line, so nothing gets replaced or changed here π«Ά
Abstract β¨
New technologies keep stuffing new info into IS-IS while networks keep getting bigger, so a bunch of critical TLVs are going past the current 255-octet limit π This doc officially writes down the trick people already use: stretch the TLV's space by sending 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 https://www.rfc-editor.org/info/rfc9885.
Copyright Notice β
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents ποΈ
1. Introduction
2. Requirements Language
3. Overview of MP-TLV Applicability to TLVs
3.1. TLVs that Advertise a List of Objects
3.2. TLVs that Advertise Objects with Identifier(s)
3.2.1. Example: Extended IS Reachability
3.2.2. Example: Extended IP Reachability
4. Multi-Part TLVs
5. Procedure for Receiving Multi-Part TLVs
6. Specification of Applicability of Multi-Part TLVs
7. MP-TLV Capability Advertisement
8. Deployment Considerations
8.1. Controls and Alarms
8.2. Restrictions on Generation of MP-TLVs
9. IANA Considerations
9.1. MP-TLV Support Sub-TLV
9.2. Extension to IS-IS Top-Level TLV Registries
9.2.1. MP-TLV for IS-IS Top-Level TLV Codepoints
9.2.2. MP-TLV for IS-IS Sub-TLVs for Reverse Metric TLV
9.2.3. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Neighbor
Information
9.2.4. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Prefix
Reachability
9.2.5. MP-TLV for IS-IS Sub-TLVs for MT-Capability TLV
9.2.6. MP-TLV for IS-IS Sub-TLVs for IS-IS Router CAPABILITY
TLV
9.2.7. IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV
9.2.8. MP-TLV IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV
9.2.9. MP-TLV for IS-IS Sub-TLVs for Segment Identifier/Label
Binding TLVs
9.2.10. MP-TLV for IS-IS Sub-Sub-TLV Codepoints for
Application-Specific Link Attributes
9.2.11. MP-TLV for IS-IS Sub-TLVs for Application-Specific SRLG
TLV
9.2.12. MP-TLV for IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs
9.2.13. MP-TLV for IS-IS Sub-Sub-TLVs for Flexible Algorithm
Definition Sub-TLV
9.2.14. MP-TLV for IS-IS Sub-Sub-TLVs for Flood Reflection
Discovery Sub-TLV
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Contributors
Authors' Addresses
1. Introduction πΈ
The internet keeps growing, and so do service provider networks and the amount of info carried in IS-IS [ISO10589] Type-Length-Value (TLV) tuples. On top of that, new traffic engineering technologies keep defining new attributes, which adds even more scaling pressure π The original TLV definition caps each TLV at a maximum of 255 octets of payload, and honestly that's becoming a real problem π©
Some TLV definitions already handle this by explicitly saying a TLV may appear multiple times inside of a Link State PDU (LSP). But lots of currently defined TLVs never did that, so the situation is kinda ambiguous π
For example, [RFC5305] defines the Extended IS reachability TLV (22), and [RFC5120] defines the MT-ISN TLV (222). Neither document says to send multiple TLVs for the same object, and no other mechanism for expanding the info carrying capacity of the TLV has been specified either π
This document is here to clarify and codify all of that. It explicitly makes multiple occurrences of a TLV the standard mechanism for scaling TLV contents. Any future document that proposes a different mechanism for scaling TLV contents for a given codepoint must explain why multiple occurrences of a TLV is not appropriate π
This document does not alter the encoding of any TLV where multiple occurrences of a TLV are already defined. Some examples of this are:
- Router CAPABILITY TLV (Type 242) [RFC7981]
- Application-Specific SRLG (Type 238) [RFC9479]
- Instance Identifier (Type 7) [RFC8202]
- Application-Specific Link Attributes (sub-TLV Type 16) [RFC9479]
[RFC7356] defined a 16-bit Length field for TLVs in flooding scoped Protocol Data Units (PDUs). The problem this document addresses would likely not show up when 16-bit Length TLVs are in use. However, introducing these new PDU types is not backwards compatible π₯² So there's still a need to figure out how to expand the info advertised in existing PDUs that use TLVs with 8-bit length fields.
The mechanism described here hasn't been documented for all TLVs before. This document provides the necessary protocol definition and discusses potential interoperability issues and deployment challenges π§
This document specifies a way to extend TLVs where no extension mechanism was explicitly specified before. It also makes this mechanism the default extension mechanism for future TLVs β¨ The mechanism applies to top level TLVs as well as any level of sub-TLVs that may appear within a top level TLV.
2. Requirements Language π₯
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
3. 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 the Type and Length fields are one octet in size, which means a maximum of 255 octets can be sent in a single TLV. TLVs with certain general characteristics could need to advertise more than 255 octets. These generic types are described in more detail in the following subsections.
3.1. TLVs that Advertise a List of Objects π
Some TLVs are just a list of objects of a given type. For example, the BFD-Enabled TLV (Type 148) [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 π€
3.2. TLVs that Advertise Objects with Identifier(s) π§
Some TLVs support advertising 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 is the set of identifiers π
3.2.1. Example: Extended IS Reachability π
Let's look at the Extended IS reachability TLV (Type 22) [RFC5305] as an example. 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:
The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers that are present π
3.2.2. Example: Extended IP Reachability π
Another example is the Extended IP reachability TLV (Type 135) [RFC5305]. 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 π«Ά
4. 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) π
Without MP-TLV support, when a router receives an MP-TLV, the receiver chooses which TLV gets processed and which gets ignored π¬ This can happen legitimately as a transient condition when a TLV moves from one LSP to another, or because of a defect in the sending implementation.
With MP-TLV support, when a router receives an MP-TLV, info from all the TLVs gets processed β¨
The encoding of TLVs is not altered by introducing MP-TLV support. In particular, the "key" used to identify the set of TLVs that form an MP-TLV is the same key used without MP-TLV support. Also, the definition of the "key" is part of the specification(s) that define(s) the TLV, so it's outside the scope of this document π
NOTE: This document intentionally does not include a definition of the key for each codepoint. Doing so would be redundant and would 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 a single sub-TLV or other data unit across TLVs MUST NOT be done. Breaking a data unit across TLVs results in an invalid encoding π« Guidelines to receivers for handling such a case are specified in [RFC8918].
5. Procedure for Receiving Multi-Part TLVs β¨
okay so bestie, here's how a router handles MP-TLVs when they come in π«Ά. A router that receives an MP-TLV MUST accept all of the information in all of the parts π. It does not matter what order the parts show up in, or where they sit inside the LSP fragments π¦. Multiple TLV parts MAY be in a single LSP, or the parts MAY be spread across different LSPs πΈ.
Placement of the TLV parts in an IIH is irrelevant too π§.
When processing MP-TLVs, implementations MUST NOT impose a minimum length check π. Now, MP-TLVs SHOULD NOT be sent unless a single TLV (255 octets) is actually full π . But receivers MUST NOT reject MP-TLVs just because senders don't stick to that rule perfectly π. For example, say two MP-TLVs each show up at 100 bytes. The total is more than 255 bytes, and that MUST NOT get the TLVs rejected π. See Section 8.2 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 replicated key information MUST be taken to mean that the data after it MUST be processed as if it were concatenated after one single copy of that key information π.
Here's an example. A router gets an LSP with a Multi-Part Extended IS reachability TLV π. The first part has key information K with unique sub-TLVs A, B, and C. The second part also has key information K, plus unique sub-TLVs D, E, and F π. The receiving router must then treat it as having key information K and unique sub-TLVs A, B, C, D, E, F. Or, since ordering doesn't matter, it could be D, E, F, A, B, C, or any other permutation β¨.
A TLV can also carry information in its fixed part that is NOT part of the key π. The metric in both the Extended IS reachability TLV and the Extended IP Reachability TLV doesn't say which object the TLV is about, so it isn't part of the key π¦. Having inconsistent information in different parts of an MP-TLV is an error π.
Info that isn't in the fixed part can get duplicated too π¬. For example, a sub-TLV that's only supposed to show up once shows up multiple times with different values. That can happen inside the same TLV or across different parts of an MP-TLV. This is also an error π ββοΈ.
The document that defines the TLV should say how to handle these cases π. If that document isn't clear about it, then this procedure applies π :
- The first occurrence in the lowest numbered LSP is used. Later occurrences in the same LSP, or in higher numbered LSPs, are ignored πΈ.
- For IIHs, the first occurrence in the IIH is used. Later occurrences in the IIH are ignored π§.
6. Specification of Applicability of Multi-Part TLVs π
As mentioned in Section 1, some existing specs have explicitly said that MP-TLV procedures apply to a given codepoint π. But MP-TLV procedures could potentially apply to ANY codepoint that lets sub-TLVs be included in the advertised info π¦. They may also apply to codepoints that don't support sub-TLVs but do define an unbounded number of attributes that can be advertised in a single codepoint π§. GMPLS-SRLG, defined in [RFC5307], is an example of that second kind π.
Here's the tea β: when a codepoint doesn't explicitly say whether MP-TLV procedures apply, that's a recipe for interoperability problems π. That gets real if someone needs to advertise more than 255 octets of info for that codepoint π.
This document fixes that by making MP-TLV applicability explicit for all existing IS-IS codepoints π. It does this by extending the existing, relevant IANA protocol registries with an explicit indication of MP-TLV applicability for each codepoint. See Section 9 π. So any new codepoints defined by future protocol extensions will explicitly indicate MP-TLV applicability too π«Ά.
7. MP-TLV Capability Advertisement π₯
Introducing MP-TLV for codepoints where the existing specs haven't explicitly defined MP-TLV support can be extremely disruptive to network operations π±. This is especially true when not all routers in the network support MP-TLV for those codepoints. Partial deployment can easily lead to traffic loss and/or other unexpected behaviors that are hard to diagnose π.
For example, if there are multiple TLVs associated with advertising a neighbor, and an implementation doesn't process all of the advertised link attributes, then constrained path calculations based on those attributes are likely to give wrong or unexpected results π. That could create forwarding loops or dropped traffic π.
To help network operators diagnose these situations, a new sub-TLV of the IS-IS Router CAPABILITY TLV [RFC7981] is defined π§. Here it is π:
MP-TLV Support for TLVs with Implicit Support
Type: 30 (1 octet)
Length: 0 (1 octet)
Routers that support MP-TLV for codepoints where existing specs don't explicitly define such support, but where MP-TLV is applicable, SHOULD include this sub-TLV in a Router CAPABILITY TLV π.
The scope of the associated Router CAPABILITY TLV is per level (S-bit clear) [RFC7981] πΈ.
This advertisement is for informational purposes only π. IS-IS protocol implementations MUST NOT change what they send, or how they process what they receive, based on these advertisements π ββοΈ.
The sub-TLV intentionally does NOT provide a syntax to specify MP-TLV support on a per-codepoint basis π¦. It's presumed that if such support is provided, it applies to all relevant codepoints π. In reality though, a given implementation might limit MP-TLV support to particular codepoints based on the needs of its deployment scenarios π . So operators still have to be diligent: configurations that require sending an MP-TLV for a given codepoint must not be 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 point is to give info that might be useful to a network operator β¨. This exception to the intended use of the Router CAPABILITY TLV is there to help reduce the disruption that comes with introducing MP-TLV support where that support hasn't been explicitly defined π₯. It is NOT meant to introduce a generic new use case for the Router CAPABILITY TLV π .
NOTE: A more appropriate and robust way to provide detailed info on what an implementation supports is to use YANG to define a Protocol Implementation Conformance Statement (PICS) π§ . An example of this can be found in [PICS-YANG] π.
8. Deployment Considerations πΈ
Sending MP-TLVs when some routers don't correctly process such advertisements can cause interoperability issues, including incorrect packet forwarding π±. This section covers best practices for when a deployment needs MP-TLVs for codepoints where the existing specs don't explicitly indicate MP-TLV support π.
It's not in scope for this document to mandate how implementations prevent (or at least make less likely) partial deployment of MP-TLV for a given codepoint π. But it's really important to help operators avoid accidental problematic deployments π. Providing proper controls to enable/disable sending MP-TLVs, as discussed in Section 8.1, is key to avoiding interoperability issues π.
8.1. Controls and Alarms π¨
It is RECOMMENDED that implementations that support sending MP-TLVs provide configuration controls that enable/disable generation of MP-TLVs π . Since 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 disabling 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 they've made sure that all implementations that will receive the MP-TLVs can interpret them correctly, as described in Section 5 π§.
8.2. Restrictions on Generation of MP-TLVs π
This section talks about restrictions on sending MP-TLVs π«. When applying these restrictions, it's assumed that it has already been decided that sending MP-TLVs is allowed, based on the settings of the controls discussed in Section 8.1 β .
Sending a single TLV with all the info about an object is better than sending multiple TLVs π. It's simpler and more efficient to parse info from one TLV than to combine info from several π§ . Implementations SHOULD NOT send multiple TLVs unless MP-TLV applies to the TLV AND the amount of info that needs to be sent exceeds the capacity of a single TLV π. For example, when extra space is needed in an existing TLV, then as long as there's room in the TLV, info SHOULD NOT be split into multiple TLVs π«Ά. If there's no room left in the current LSP to fit the now-larger TLV, the TLV SHOULD be moved to a new LSP π§.
9. IANA Considerations π
9.1. 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 <https://www.iana.org/assignments/isis-tlv-codepoints>) πΈ:
Type: 30
Description: MP-TLV Support for TLVs with Implicit Support
MP-TLV Applicability: N
Reference: Section 7 of RFC 9885
9.2. 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 shows whether the MP-TLV procedures described in this document apply to that codepoint π¦. "Y" means MP-TLV is applicable. "N" means MP-TLV is not applicable π .
The following subsections give the initial contents of the new column for a number of existing registries π. The initial MP-TLV applicability values in those subsections are based on the rule that MP-TLV applies to any codepoint that supports sub-TLVs, regardless of whether the sub-TLVs currently defined are enough to actually require MP-TLVs to be sent π₯.
To find the relevant IANA registry, search for the registry name associated with each subsection at <https://www.iana.org/assignments/isis-tlv-codepoints> π.
9.2.1. MP-TLV for IS-IS Top-Level TLV Codepoints
okay so IANA went and added a brand new MP column to the "IS-IS Top-Level TLV Codepoints" registry π and filled it in for every codepoint, which you can see right here in Table 1 π
+===========+====================================+====+
| 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 | Y |
| | / Label Binding | |
+-----------+------------------------------------+----+
| 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 | |
+-----------+------------------------------------+----+
Table 1: IS-IS Top-Level TLV Codepoints
9.2.2. MP-TLV for IS-IS Sub-TLVs for Reverse Metric TLV β¨
okay so IANA slid a brand new MP column into the "IS-IS Sub-TLVs for Reverse Metric TLV" registry π and filled it in like this π
+========+============================+====+
| Value | Name | MP |
+========+============================+====+
| 0 | Reserved | |
+--------+----------------------------+----+
| 1-17 | Unassigned | |
+--------+----------------------------+----+
| 18 | Traffic Engineering Metric | N |
+--------+----------------------------+----+
| 19-255 | Unassigned | |
+--------+----------------------------+----+
Table 2: IS-IS Sub-TLVs for Reverse
Metric TLV
9.2.3. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Neighbor Information π¦
same energy here π«Ά IANA added the MP column to the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry and populated it as shown in Table 3. this one is literally the longest list, so get a snack first π
+=========+===================================================+====+
| 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 | |
+---------+---------------------------------------------------+----+
Table 3: IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
9.2.4. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability π
last one in this batch, bestie π§ IANA added the MP column to the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry and populated it as shown in Table 4 β¨
+========+=========================================+====+
| 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 | |
+--------+-----------------------------------------+----+
Table 4: IS-IS Sub-TLVs for TLVs Advertising Prefix
Reachability
9.2.5. MP-TLV for IS-IS Sub-TLVs for MT-Capability TLV
okay so IANA slid an MP column into the "IS-IS Sub-TLVs for MT-Capability TLV" registry and filled it in like this π β¨
+========+==============================+====+
| 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 | |
+--------+------------------------------+----+
Table 5: IS-IS Sub-TLVs for MT-Capability TLV
9.2.6. MP-TLV for IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV
same energy here πΈ IANA added the MP column to the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry, and the result is in Table 6 π
+=========+====================================+====+
| 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 | N |
| | Preference (SRMS Preference) | |
+---------+------------------------------------+----+
| 25 | SRv6 Capabilities | N |
+---------+------------------------------------+----+
| 26 | Flexible Algorithm Definition | N |
| | (FAD) | |
+---------+------------------------------------+----+
| 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 | |
+---------+------------------------------------+----+
Table 6: IS-IS Sub-TLVs for IS-IS Router
CAPABILITY TLV
9.2.7. IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV
this one's a short and sweet moment π¦ IANA added the MP column to the "IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV" registry, and it looks like this:
+=======+============+====+
| Value | Name | MP |
+=======+============+====+
| 0 | Reserved | |
+-------+------------+----+
| 1-255 | Unassigned | |
+-------+------------+----+
Table 7: IS-IS Sub-Sub-
TLVs for SRv6
Capabilities Sub-TLV
9.2.8. MP-TLV IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV
ngl the BIER one is giving tidy π IANA added the MP column to the "IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV" registry and filled it in as Table 8:
+=======+=========================+====+
| Value | Name | MP |
+=======+=========================+====+
| 0 | Unassigned | |
+-------+-------------------------+----+
| 1 | BIER MPLS Encapsulation | N |
+-------+-------------------------+----+
| 2 | BIER PHP Request | N |
+-------+-------------------------+----+
| 3-255 | Unassigned | |
+-------+-------------------------+----+
Table 8: IS-IS Sub-Sub-TLVs for BIER
Info Sub-TLV
9.2.9. MP-TLV for IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs
last one in this batch and it's a bop π§ IANA added the MP column to the "IS-IS Sub-TLVs for Segment Identifier/Label Binding TLVs" registry, populated as shown in Table 9:
+=======+===========================+====+
| Value | Name | MP |
+=======+===========================+====+
| 0 | Reserved | |
+-------+---------------------------+----+
| 1 | SID/Label | N |
+-------+---------------------------+----+
| 2 | Unassigned | |
+-------+---------------------------+----+
| 3 | Prefix Segment Identifier | N |
+-------+---------------------------+----+
| 4-255 | Unassigned | |
+-------+---------------------------+----+
Table 9: IS-IS Sub-TLVs for Segment
Identifier/Label Binding TLVs
9.2.10. MP-TLV for IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes β¨
okay so IANA slid an MP column into the "IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes" registry π and filled it in like this (see Table 10) π:
+========+====================================+====+
| 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 | |
+--------+------------------------------------+----+
Table 10: IS-IS Sub-Sub-TLV Codepoints for
Application-Specific Link Attributes
9.2.11. MP-TLV for IS-IS Sub-TLVs for Application-Specific SRLG TLV πΈ
IANA also added the MP column to the "IS-IS Sub-TLVs for Application-Specific SRLG TLV" registry, and it looks like this (Table 11) π¦:
+========+===============================+====+
| 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 | |
+--------+-------------------------------+----+
Table 11: IS-IS Sub-TLVs for Application-
Specific SRLG TLV
9.2.12. MP-TLV for IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs π
same energy here: the "IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs" registry got its MP column too, and Table 12 shows the full lineup π§
+=======+====================+====+
| Value | Name | MP |
+=======+====================+====+
| 0 | Reserved | |
+-------+--------------------+----+
| 1 | SRv6 SID Structure | N |
+-------+--------------------+----+
| 2-255 | Unassigned | |
+-------+--------------------+----+
Table 12: IS-IS Sub-Sub-TLVs
for SRv6 SID Sub-TLVs
9.2.13. MP-TLV for IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV π
IANA added the MP column to the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry as well, and Table 13 has all the details π:
+========+============================================+====+
| 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 | |
+--------+--------------------------------------------+----+
Table 13: IS-IS Sub-Sub-TLVs for Flexible Algorithm
Definition Sub-TLV
9.2.14. MP-TLV for IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV π
last one in this batch: the "IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV" registry gets an MP column too, and Table 14 is the lookup β:
+=========+================================+====+
| Value | Name | MP |
+=========+================================+====+
| 0-160 | Unassigned | |
+---------+--------------------------------+----+
| 161 | Flood Reflection Discovery | N |
| | Tunnel Encapsulation Attribute | |
+---------+--------------------------------+----+
| 162-255 | Unassigned | |
+---------+--------------------------------+----+
Table 14: IS-IS Sub-Sub-TLVs for Flood
Reflection Discovery Sub-TLV
10. Security Considerations π
bestie, this one's a chill read π«Ά. 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. That's a nice little bonus for your code π
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310]. Go read those if you want the full picture π
11. References π
11.1. Normative References π
okay bestie, these are the docs this RFC leans on SO hard that you literally can't skip them π every one of these shows up as a must-read, so here they are in full:
- [ISO10589] ISO/IEC, "Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, November 2002,
https://www.iso.org/standard/30932.html. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008,
https://www.rfc-editor.org/info/rfc5120. - [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008,
https://www.rfc-editor.org/info/rfc5304. - [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008,
https://www.rfc-editor.org/info/rfc5305. - [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
https://www.rfc-editor.org/info/rfc5307. - [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009,
https://www.rfc-editor.org/info/rfc5310. - [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011,
https://www.rfc-editor.org/info/rfc6119. - [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, DOI 10.17487/RFC6213, April 2011,
https://www.rfc-editor.org/info/rfc6213. - [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014,
https://www.rfc-editor.org/info/rfc7356. - [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016,
https://www.rfc-editor.org/info/rfc7981. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. - [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017,
https://www.rfc-editor.org/info/rfc8202. - [RFC8918] Ginsberg, L., Wells, P., Li, T., Przygienda, T., and S. Hegde, "Invalid TLV Handling in IS-IS", RFC 8918, DOI 10.17487/RFC8918, September 2020,
https://www.rfc-editor.org/info/rfc8918. - [RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 9479, DOI 10.17487/RFC9479, October 2023,
https://www.rfc-editor.org/info/rfc9479.
11.2. Informative References πΈ
these ones are more like the "bonus reading" shelf π§ handy for background, but the spec itself doesn't lean on them the same way:
- [PICS-YANG] Qu, Y., Ginsberg, L., Przygienda, A., Decraene, B., and Y. Zhu, "YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS)", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-pics-yang-02, 20 October 2025,
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-pics-yang-02.
Contributors π«Ά
the following individual made a substantial contribution to the content of this document and should be considered a coauthor, so a huge shoutout to them π
Chris Bowers
Email: cbowers107@gmail.com
Authors' Addresses π
and here are the brilliant humans who wrote this thing, with their contact details exactly as listed π¦
Parag Kaneriya
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Email: pkaneria@juniper.net
Tony Li
Juniper Networks
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Email: tony.li@tony.li
Antoni Przygienda
Juniper Networks
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Email: prz@juniper.net
Shraddha Hegde
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Email: shraddha@juniper.net
Les Ginsberg
Cisco Systems
Email: ginsberg@cisco.com
π¦ where this page comes from
- ietf: rfc9885 2025-10
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms