| Internet-Draft | Multi-part TLVs | October 2023 |
| Kaneriya, et al. | Expires 8 April 2024 | [Page] |
- Workgroup:
- LSR Working Group
- Internet-Draft:
- draft-pkaneria-lsr-multi-tlv-04
- Published:
- Intended Status:
- Standards Track
- Expires:
Multi-part TLVs in IS-IS
Abstract
New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial. This document codifies the common mechanism of extending the TLV content space through multiple TLVs.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 April 2024.¶
Copyright Notice
Copyright (c) 2023 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.¶
1. Introduction
The continued growth of the Internet has resulted in a commensurate growth in the scale of service provider networks and the amount of information carried in IS-IS [ISO10589] Type-Length-Value (TLV) tuples. Simultaneously, new traffic engineering technologies are defining new attributes, further adding to the scaling pressures. The original TLV definition allows for 255 octets of payload, which is becoming increasingly stressful.¶
Some TLV definitions have addressed this by explicitly stating that a TLV may appear multiple times inside of an LSP. However, this has not been done for many legacy TLVs, leaving the situation somewhat ambiguous. The intent of this document is to clarify and codify the situation by explicitly making multiple occurences of a TLV the mechanism for scaling TLV contents, except where otherwise explicitly stated.¶
This document does not pertain to any TLV where multiple occurrences of a TLV are already defined. As of this writing, the authors are aware of the following TLVs that fall into this category:¶
- Router Capability TLV (Type 242) [RFC7981]¶
- GMPLS-SRLG (Type 138) [RFC5307]¶
- IPv6 SRLG (Type 139) [RFC6119]¶
- Application-Specific SRLG (Type 238) [RFC8919]¶
- Application-Specific Link Attributes (sub-TLV Type 16) [RFC8919]¶
Today, for example, the Extended IS Reachability TLV (22) [RFC5305] and MT Intermediate Systems TLV (222) [RFC5120] are TLVs where existing standards 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.¶
[RFC7356] has proposed a 16 bit length field for TLVs in flooding scoped Protocol Data Units (PDUs), but this does not address how to expand the information advertised when using the existing 8-bit length TLVs.¶
The mechanism described in this document has not been documented for all TLVs previously, so it is likely that some implementations would not interoperate correctly if these mechanisms were used without caution.¶
The mechanism described in this document has been used explicitly by some implementations, so this document is not creating an unprecedented mechanism. It is specifying a means for extending TLVs where no extension mechanism has been previously specified, and defining a default extension mechanism for future TLVs, if they choose not to specify another extension mechanism. The mechanism described in this document is applicable to top level TLVs as well as any level of sub-TLVs which 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. Multi-part TLVs
A TLV is a tuple of (Type, Length, Value) and can be advertised in IS-IS packets. TLVs sometimes contain information, called a key, that indicates the applicability of the remaining contents of the TLV. If a router advertises multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the set of LSPs for a level with the same key value, they are considered a multi-part TLV (MP-TLV).¶
4. Procedure for Advertising Multi-part TLVs
Network operators should not enable Multi-part TLVs until ensuring that all implementations that will receive the Multi-part TLVs are capable of interpreting them correctly.¶
If a Multi-part TLV contains information that specifies the applicability of its contents (i.e., a key), the key information MUST be replicated in additional TLV instances so that all contents specific to that key can be identified.¶
4.1. 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 system ID and pseudonode number¶
- 3 octets of default metric¶
-
Optionally one or more of the following identifiers:¶
This acts as the key for this entry. Note that the link identifiers are encoded as sub-TLVs and MAY appear in any order. It is RECOMMENDED that the link identifiers be the first sub-TLVs. Note that it is valid to advertise no link identifiers, but in the presence of parallel adjacencies to the same neighbor it will not be possible to associate the advertisement with a specific link.¶
If the remaining space in the TLV is insufficient to advertise all other sub-TLVs, then the node MAY advertise additional Extended IS Reachability TLVs. The key information MUST be replicated identically.¶
4.2. Example: Extended IP Reachability
As another example, consider 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 which includes 6 bits specifying the prefix length¶
- 0-4 octets of IPv4 prefix¶
followed by up to 250 octets of sub-TLV information.¶
The key consists of the 6 bits of prefix length and the 0-4 octets of IPv4 prefix.¶
If this is insufficient sub-TLV space, then the node MAY advertise additional instances of the Extended IP Reachability TLV. The key information MUST be replicated identically. The complete information for a given key in such cases is the joined set of all the carried information under the key in all the TLV instances.¶
5. Procedure for Receiving Multi-part TLVs
A node that receives a multi-part 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. The placement of the TLV parts in an IIH is irrelevant.¶
The contents of a multi-part TLV MUST be processed as if they were concatenated. If the internals of the TLV contain key information, then replication of the key information should 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 node receives an LSP with a multi-part Extended IS Reachability TLV. The first part contains key information K with sub-TLVs A, B, and C. The second part contains key information K with sub-TLVs D, E, and F. The receiving node must then process this as having key information K and sub-TLVs A, B, C, D, E, F, or, because ordering is irrelevant, 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 a MP-TLV is an error and is out of scope for this document.¶
6. Specification of Applicability of Multi-part TLV
As mentioned in Section 1, existing specifications for some TLVs have explicitly stated that the use of Multi-Part TLV procedures are applicable to that codepoint. However, Multi-Part TLV procedures are potentially applicable to any codepoint that allows sub-TLVs to be included as part of the information advertised. The lack of explicit indication of applicability of Multi-Part TLV procedures to all codepoints to which such procedures could be applied contributes to potential interoperability problems if/when the need arises to advertise more than 255 bytes of information for such a codepoint.¶
This document makes explicit the applicability of Multi-Part 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 Multi-Part TLV procedures for each codepoint. See Section 8. This guarantees that any new codepoints defined by future protocol extensions will explicitly indicate the applicability of Multi-Part TLV procedures to the new codepoints.¶
7. Deployment Considerations
Sending of MP-TLVs in the presence of nodes which do not correctly process such advertisements can result in interoperablity issues, including incorrect forwarding of packets. This section discusses best practices which SHOULD be used when a deployment requires the use of MP-TLVs for codepoints for which existing specifications do not explicitly indicate MP-TLV support.¶
7.1. Recommended Controls and Alarms
It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to 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 support per codepoint granularity. For example, an implementation might support MP-TLVs for IS Extended Reachability but not for IP Reachability.¶
Implementations SHOULD report alarms under the following conditions:¶
7.2. 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 nodes in the network support MP-TLV for those codepoints. Partial deployment can easily result in traffic loss and/or other unexpected behaviors which may be hard to diagnose.¶
As an aid to network operators, a new sub-TLV of the IS-IS Router CAPABILITY TLV [RFC7981] is defined:¶
MP-TLV Support for TLVs with implicit support Type 30 (suggested - to be assigned by IANA) 1 octet Length 0 1 octet¶
Nodes which 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. 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-TLV basis. It is presumed that if such support is provided that it applies to all relevant TLVs. It is understood that in reality, a given implementation might limit MP-TLV support to particular TLVs based on the needs of the deployment scenarios in which it is used.¶
The Router Capability TLV is meant to advertise capabilities which are of direct use to the IS-IS protocol. The MP-TLV Support sub-TLV advertises management information, not of direct use to the protocol. The intent is to provide information which 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 that with the introduction of explicit specification of MP-TLV applicability for codepoints (see Section 8), implicit MP-TLV support will never occur in the future. Where MP-TLV support is explicitly defined, conformant implementations MUST support MP-TLV.¶
8. IANA Considerations
8.1. MP-TLV Support sub-TLV
This document requests the following code point from the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry:¶
Type: 30 (suggested) Description: MP-TLV Support for TLVs with implicit support MP-TLV Applicability: N Reference: This document Section 7.2¶
8.2. Extension to IS-IS Top Level TLV Registries
This document requests that IANA extend a number of registries under the "IS-IS TLV Codepoints" registries 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 sub-sections provide the initial contents of the new column for a number of existing registries.¶
8.2.1. MP-TLV for 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 | N |
| 21 | Flooding Parameters TLV | N |
| 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 | Zone ID | N |
| 29-41 | Unassigned | |
| 42 | DECnet Phase IV | N |
| 43-65 | Unassigned | |
| 66 | Lucent Proprietary | N |
| 67-125 | Unassigned | |
| 126 | IPv4 Algorithm Prefix Reachability TLV | N |
| 127 | IPv6 Algorithm Prefix Reachability TLV | 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 |
8.2.2. MP-TLV for IS-IS Sub-TLVs for Reverse Metric TLV
| Value | Name | MP |
|---|---|---|
| 0 | Reserved | |
| 1-17 | Unassigned | |
| 18 | Traffic Engineering Metric | N |
| 19-255 | Unassigned |
8.2.3. MP-TLV for 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 | Y |
| 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 |
8.2.4. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability
| Value | Name | MP |
|---|---|---|
| 0 | Unassigned | |
| 1 | 32-bit Administrative Tag Sub-TLV | N |
| 2 | 64-bit Administrative Tag Sub-TLV | N |
| 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 |
| 32-255 | Unassigned |
8.2.5. MP-TLV for 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 |
8.2.6. MP-TLV for 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 |
8.2.7. IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV
| Value | Name | MP |
|---|---|---|
| 0 | Reserved | |
| 1-255 | Unassigned |
8.2.8. MP-TLV IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV
| Value | Name | MP |
|---|---|---|
| 0 | Unassigned | |
| 1 | BIER MPLS Encapsulation | N |
| 2-255 | Unassigned |
8.2.9. MP-TLV for 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 |
8.2.10. MP-TLV for 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 |
8.2.11. MP-TLV for 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 |
8.2.12. MP-TLV for IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs
| Value | Name | MP |
|---|---|---|
| 0 | Reserved | |
| 1 | SRv6 SID Structure | N |
| 2-255 | Unassigned |
8.2.13. MP-TLV for 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 Threshold Metric | N |
| 10-255 | Unassigned |
8.2.14. MP-TLV for 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 |
9. Security Considerations
This document creates no new security issues for IS-IS. Additional instances of existing TLVs expose no new information.¶
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310].¶
10. Normative References
- [ISO10589]
- ISO, "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", , <ISO/IEC 10589:2002>.
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc5120>.
- [RFC5304]
- Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc6119>.
- [RFC7356]
- Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8919]
- Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 8919, DOI 10.17487/RFC8919, , <https://www.rfc-editor.org/info/rfc8919>.
