Internet Engineering Task Force (IETF) P. Kaneriya
Request for Comments: 9885 T. Li
Category: Standards Track A. Przygienda
ISSN: 2070-1721 S. Hegde
Juniper Networks
L. Ginsberg
Cisco Systems
October 2025
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.
新しいテクノロジーが IS-IS に新しい情報を追加すると同時に、導入規模も拡大しています。これにより、多くの重要な TLV の内容が現在サポートされている制限である 255 オクテットを超えます。この文書は、複数の TLV を通じて TLV コンテンツ スペースを拡張する共通のメカニズムを成文化します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
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.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9885 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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
The continued growth of the Internet has resulted in a commensurate growth in the scale of service provider networks and the amount of information carried in IS-IS [ISO10589] Type-Length-Value (TLV) tuples. Simultaneously, new traffic engineering technologies are defining new attributes, further adding to the scaling pressures. The original TLV definition limits each TLV to a maximum of 255 octets of payload, which is becoming increasingly problematic.
インターネットの継続的な成長により、サービス プロバイダー ネットワークの規模と、IS-IS [ISO10589] の Type-Length-Value (TLV) タプルで伝送される情報量もそれに応じて増加しました。同時に、新しいトラフィック エンジニアリング テクノロジによって新しい属性が定義され、スケーリングのプレッシャーがさらに高まっています。元の TLV 定義では、各 TLV のペイロードが最大 255 オクテットに制限されていますが、これはますます問題になっています。
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.
一部の TLV 定義では、TLV がリンク ステート PDU (LSP) 内に複数回出現する可能性があることを明示的に示すことで、この問題に対処しています。ただし、これは現在定義されている多くの TLV に対して行われておらず、状況がやや曖昧なままになっています。
For example, [RFC5305] defines the Extended IS reachability TLV (22) and [RFC5120] defines the MT-ISN TLV (222). These documents do not specify sending multiple TLVs for the same object and no other mechanism for expanding the information carrying capacity of the TLV has been specified.
たとえば、[RFC5305] は拡張 IS 到達可能性 TLV (22) を定義し、[RFC5120] は MT-ISN TLV (222) を定義します。これらの文書では、同じオブジェクトに対して複数の TLV を送信することは指定されておらず、TLV の情報伝送容量を拡張するための他のメカニズムも指定されていません。
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.
この文書の目的は、TLV コンテンツをスケーリングするための標準メカニズムとして TLV の複数の出現を明示的に行うことで、状況を明確にし、成文化することです。特定のコードポイントの TLV コンテンツをスケーリングするための別のメカニズムを提案する将来の文書では、TLV の複数の出現が適切ではない理由を説明する必要があります。
This document does not alter the encoding of any TLV where multiple occurrences of a TLV are already defined. Some examples of this are:
この文書は、複数の TLV がすでに定義されている TLV のエンコーディングを変更するものではありません。この例としては次のようなものがあります。
* Router CAPABILITY TLV (Type 242) [RFC7981]
* ルーター機能 TLV (タイプ 242) [RFC7981]
* Application-Specific SRLG (Type 238) [RFC9479]
* アプリケーション固有の SRLG (タイプ 238) [RFC9479]
* Instance Identifier (Type 7) [RFC8202]
* インスタンス識別子 (タイプ 7) [RFC8202]
* Application-Specific Link Attributes (sub-TLV Type 16) [RFC9479]
* アプリケーション固有のリンク属性 (サブ TLV タイプ 16) [RFC9479]
[RFC7356] 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.
[RFC7356] は、フラッディングスコープのプロトコルデータユニット (PDU) の TLV に 16 ビットの長さフィールドを定義しました。この文書で取り上げられる問題は、16 ビット長の TLV が使用されている場合には発生しない可能性があります。ただし、これらの新しい PDU タイプの導入には下位互換性がありません。したがって、8 ビット長のフィールドを持つ TLV を使用する既存の PDU でアドバタイズされる情報を拡張する方法に対処する必要があります。
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.
この文書で説明されているメカニズムは、これまですべての TLV について文書化されていたわけではありません。この文書では、必要なプロトコルの定義を提供し、潜在的な相互運用性の問題と展開上の課題について説明します。
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.
この文書は、これまでに拡張メカニズムが明示的に指定されていない TLV を拡張する手段を指定します。また、このメカニズムを将来の TLV のデフォルトの拡張メカニズムとして指定します。この文書で説明されているメカニズムは、トップレベル TLV だけでなく、トップレベル TLV 内に表示されるサブ TLV のあらゆるレベルにも適用できます。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
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.
TLV は (タイプ、長さ、値) のタプルであり、IS-IS パケットでアドバタイズできます。Type フィールドと Length フィールドは両方とも 1 オクテットのサイズであるため、単一の TLV で最大 255 オクテットを送信できるという制限が生じます。特定の一般的な特性を持つ TLV には、255 オクテットを超えるアドバタイズメントが必要になる可能性があります。これらのジェネリック型については、次のサブセクションで詳しく説明します。
Some TLVs are simply 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.
一部の TLV は、単に特定のタイプのオブジェクトのリストです。たとえば、BFD-Enabled TLV (Type 148) [RFC6213] には、マルチトポロジ識別子 (MTID)/ネットワーク層プロトコル識別子 (NLPID) のペアのリストが含まれています。すべての MTID/NLPID ペアをアドバタイズするために 255 オクテットを超える必要がある場合は、複数の BFD 対応 TLV が必要になります。複数の BFD 対応 TLV 間の関係は、TLV タイプを使用して確立されます。
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.
一部の TLV は、特定のタイプのオブジェクトのアドバタイズメントをサポートしており、各オブジェクトは一意の識別子のセットによって識別されます。この場合、特定のオブジェクトを一意に識別する「キー」は一連の識別子で構成されます。
As an example, consider the Extended IS reachability TLV (Type 22) [RFC5305]. A neighbor in this TLV is specified by:
例として、拡張 IS 到達可能性 TLV (タイプ 22) [RFC5305] を考えてみましょう。この TLV のネイバーは次のように指定されます。
* 7 octets of a system ID and pseudonode number
* 7 オクテットのシステム ID と擬似ノード番号
* 3 octets of a default metric
* デフォルトのメトリックの 3 オクテット
* Optionally, one or more of the following link identifiers encoded as sub-TLVs:
* オプションで、次の 1 つ以上のリンク識別子がサブ TLV としてエンコードされます。
- an IPv4 interface address and IPv4 neighbor address as specified in [RFC5305]
- [RFC5305] で指定されている IPv4 インターフェース アドレスと IPv4 ネイバー アドレス
- an IPv6 interface address and IPv6 neighbor address as specified in [RFC6119]
- [RFC6119] で指定されている IPv6 インターフェース アドレスと IPv6 ネイバー アドレス
- Link Local/Remote Identifiers as specified in [RFC5307]
- [RFC5307] で規定されているリンクローカル/リモート識別子
The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers that are present.
キーは、7 オクテットのシステム ID と擬似ノード番号に加えて、存在するリンク識別子のセットで構成されます。
As another example, consider the Extended IP reachability TLV (Type 135) [RFC5305]. A prefix in this TLV is specified by:
別の例として、拡張 IP 到達可能性 TLV (タイプ 135) [RFC5305] を考えてみましょう。この TLV のプレフィックスは次のように指定されます。
* 4 octets of metric information
* 4 オクテットのメトリック情報
* 1 octet of control information that includes 6 bits specifying the prefix length
* プレフィックス長を指定する 6 ビットを含む 1 オクテットの制御情報
* 0-4 octets of an IPv4 prefix
* IPv4 プレフィックスの 0 ～ 4 オクテット
The above are followed by up to 250 octets of sub-TLV information.
上記の後に、最大 250 オクテットのサブ TLV 情報が続きます。
The key consists of the 6 bits of prefix length plus 0-4 octets of an IPv4 prefix.
キーは、6 ビットのプレフィックス長と IPv4 プレフィックスの 0 ～ 4 オクテットで構成されます。
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).
ルーターが、IS-IS Hello (IIH) パケットまたは特定のレベルの LSP セットで、同じ TLV タイプと同じキー (該当する場合) を持つ複数の TLV タプルをアドバタイズする場合、それらはマルチパート 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.
MP-TLV サポートがない場合、ルーターが MP-TLV を受信すると、受信側はどの TLV を処理し、どの TLV を無視するかを選択します。これは、TLV がある LSP から別の LSP に移動するときの一時的な状態として正当に発生することも、送信実装の欠陥の結果として発生することもあることに注意してください。
In the presence of MP-TLV support, when a router receives an MP-TLV, information from all the TLVs is processed.
MP-TLV サポートが存在する場合、ルーターが MP-TLV を受信すると、すべての TLV からの情報が処理されます。
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.
TLV のエンコーディングは、MP-TLV サポートの導入によって変更されません。特に、MP-TLV を形成する TLV のセットを識別するために使用される「キー」は、MP-TLV がサポートされていない場合に使用されるキーと同じです。また、「キー」の定義は TLV を定義する仕様の一部であるため、このドキュメントの範囲外であることにも注意してください。
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 [RFC8918].
MP-TLV の一部である各 TLV は、MP-TLV 内の他の TLV から独立して解析可能でなければなりません (MUST)。TLV 間で単一のサブ TLV またはその他のデータユニットを分割してはなりません (MUST NOT)。TLV 間でデータ ユニットが壊れると、無効なエンコードが発生します。このようなケースを処理するための受信機へのガイドラインは [RFC8918] で規定されています。
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.
MP-TLV を受信するルーターは、すべての部分のすべての情報を受け入れなければなりません (MUST)。LSP フラグメント内の TLV 部分の到着順序と配置順序は関係ありません。複数の TLV 部分が 1 つの LSP 内に存在してもよいし、複数の TLV 部分が異なる LSP 内に存在してもよい(MAY)。
The placement of the TLV parts in an IIH is irrelevant.
IIH 内の TLV パーツの配置は無関係です。
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 Section 8.2 for guidance on sending MP-TLVs.
MP-TLV を処理する場合、実装は最小長チェックを課してはなりません (MUST NOT)。単一の TLV の容量 (255 オクテット) を超えない限り MP-TLV を送信してはなりません (SHOULD NOT) が、送信者がこの制約を厳密に遵守しない場合、受信者は MP-TLV を拒否してはなりません (MUST NOT)。たとえば、それぞれの長さが 100 バイトである 2 つの MP-TLV を受信した場合、データの合計量が 255 バイトを超えないという事実によって TLV が拒否されてはなりません (MUST NOT)。MP-TLV の送信に関するガイダンスについては、セクション 8.2 を参照してください。
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.
MP-TLV の内容は、連結されているかのように処理しなければなりません (MUST)。TLV の内部に鍵情報が含まれている場合、鍵情報の複製は、後続のデータが鍵情報の 1 つのコピーの後に連結されたかのように処理されなければならないことを示すために取得されなければなりません (MUST)。
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.
たとえば、ルーターがマルチパート拡張 IS 到達可能性 TLV を持つ LSP を受信するとします。最初の部分には、一意のサブ TLV A、B、および C を持つ鍵情報 K が含まれます。 2 番目の部分には、一意のサブ TLV D、E、および F を持つ鍵情報 K が含まれます。受信ルーターは、これを、鍵情報 K と一意のサブ TLV A、B、C、D、E、F、または順序は無関係であるため一意のサブ TLV D、E、F、A、B、C、またはその他の順列を持つものとして処理する必要があります。
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.
TLV の固定部分には、キーの一部ではない情報が含まれる場合があります。たとえば、拡張 IS 到達可能性 TLV と拡張 IP 到達可能性 TLV の両方のメトリックは、TLV が参照するオブジェクトを指定していないため、キーの一部ではありません。MP-TLV の異なる部分に一貫性のない情報があるとエラーになります。
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.
TLV の固定部分の一部ではない情報が複製される可能性もあります。たとえば、1 回だけ表示される予定のサブ TLV が複数回表示され、値が一貫していません。これは、同じ TLV 内または MP-TLV の異なる部分で発生する可能性があります。これもエラーです。
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:
TLV を定義する文書では、そのような場合の処理方法を指定する必要があります。このような文書でそのような場合の処理方法が明示されていない場合は、次の手順が定義されています。
* The first occurrence in the lowest numbered LSP is used. Subsequent occurrences in the same LSP or higher numbered LSPs are ignored.
* 最も小さい番号の LSP で最初に出現したものが使用されます。同じ LSP またはそれより大きい番号の LSP 内でのその後の出現は無視されます。
* In the case of IIHs, the first occurrence in the IIH is used. Subsequent occurrences in the IIH are ignored.
* IIH の場合、IIH 内の最初の出現が使用されます。IIH 内のその後の出現は無視されます。
As mentioned in Section 1, existing specifications for some TLVs have explicitly stated that the use of MP-TLV procedures are applicable to that codepoint. However, MP-TLV procedures are potentially applicable to any codepoint that allows sub-TLVs to be included as part of the information advertised. MP-TLV procedures may also be applicable to codepoints that do not support sub-TLVs, but which define an unbounded number of attributes that may be advertised within a single codepoint. An example of the latter is GMPLS-SRLG as defined in [RFC5307].
セクション 1 で述べたように、一部の TLV の既存の仕様では、MP-TLV プロシージャの使用がそのコードポイントに適用できると明示的に記載されています。ただし、MP-TLV プロシージャは、アドバタイズされる情報の一部としてサブ TLV を含めることを許可するあらゆるコードポイントに潜在的に適用できます。MP-TLV プロシージャは、サブ TLV をサポートしないが、単一のコードポイント内でアドバタイズできる無制限の数の属性を定義するコードポイントにも適用できます。後者の例は、[RFC5307] で定義されている GMPLS-SRLG です。
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.
MP-TLV プロシージャが適用できるすべてのコードポイントに対する MP-TLV プロシージャの適用可能性が明示的に示されていないことは、そのようなコードポイントに対して 255 オクテットを超える情報をアドバタイズする必要がある場合に潜在的な相互運用性の問題につながります。
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 Section 9. Therefore, any new codepoints defined by future protocol extensions will explicitly indicate the applicability of MP-TLV procedures to the new codepoints.
この文書は、既存の関連する IANA プロトコル レジストリを拡張して、各コードポイントに対する MP-TLV 手順の適用性の明示的な指示を含めることにより、IS-IS プロトコル用に定義されたすべての既存のコードポイントに対する MP-TLV 手順の適用性を明示します。セクション 9 を参照してください。したがって、将来のプロトコル拡張によって定義される新しいコードポイントは、新しいコードポイントに対する MP-TLV 手順の適用可能性を明示的に示すことになります。
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.
既存の仕様で MP-TLV サポートが明示的に定義されていないコードポイントに MP-TLV の使用を導入すると、ネットワーク内のすべてのルーターがそれらのコードポイントの MP-TLV をサポートしていない場合、ネットワーク運用に大きな混乱が生じる可能性があります。部分的な展開では、トラフィック損失や診断が難しいその他の予期しない動作が発生しやすくなります。
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.
たとえば、近隣のアドバタイズメントに関連付けられた TLV が複数あり、実装がアドバタイズされたすべてのリンク属性を処理しない場合、それらの属性に基づく制約付きパス計算では、誤った結果または予期しない結果が生成される可能性があります。これにより、転送ループやトラフィックのドロップが発生する可能性があります。
As an aid to network operators when diagnosing such situations, a new sub-TLV of the IS-IS Router CAPABILITY TLV [RFC7981] is defined:
このような状況を診断する際のネットワーク オペレータの補助として、IS-IS Router CAPABILITY TLV [RFC7981] の新しいサブ TLV が定義されています。
MP-TLV Support for TLVs with Implicit Support
暗黙的なサポートによる TLV の MP-TLV サポート
Type:
タイプ：
30 (1 octet)
30（1オクテット）
Length:
長さ：
0 (1 octet)
0 (1オクテット)
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.
既存の仕様でそのようなサポートが明示的に定義されていないが、MP-TLV が適用可能なコードポイントに対して MP-TLV をサポートするルーターは、このサブ TLV を Router CAPABILITY TLV に含めるべきです (SHOULD)。
Scope of the associated Router CAPABILITY TLV is per level (S-bit clear) [RFC7981].
関連する Router CAPABILITY TLV の範囲はレベルごとです (S ビット クリア) [RFC7981]。
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.
この広告は情報提供のみを目的としています。IS-IS プロトコルの実装は、これらのアドバタイズメントに基づいて、送信される内容や受信された内容がどのように処理されるかを変更してはなりません (MUST NOT)。
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.
サブ TLV は、コードポイントごとに MP-TLV サポートを指定する構文を意図的に提供しません。このようなサポートが提供される場合、それは関連するすべてのコードポイントに適用されると想定されます。実際には、特定の実装では、それが使用される展開シナリオのニーズに基づいて、MP-TLV サポートが特定のコードポイントに制限される可能性があることが理解されています。したがって、ネットワーク内のすべてのルータが関連するコードポイントの MP-TLV をサポートするまで、特定のコードポイントの MP-TLV の送信を必要とする設定がネットワーク内のどのルータにも導入されないように、オペレータ側には依然として注意が必要です。
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.
Router CAPABILITY TLV は、IS-IS プロトコルに直接使用される機能をアドバタイズすることを目的としています。MP-TLV サポート サブ TLV は、プロトコルには直接使用されない管理情報をアドバタイズします。その目的は、ネットワーク オペレータに役立つ可能性のある情報を提供することです。Router CAPABILITY TLV の使用目的に対するこの例外は、MP-TLV サポートが明示的に定義されていない場合に、MP-TLV サポートの導入に伴う潜在的な中断を軽減するために導入されています。これは、Router CAPABILITY TLV の一般的な新しい使用例を導入することを目的としたものではありません。
NOTE: A more appropriate and robust mechanism to provide detailed information on what a given implementation supports is to utilize YANG to define Protocol Implementation Conformance Statement (PICS). An example of this can be found in [PICS-YANG].
注: 特定の実装がサポートするものに関する詳細情報を提供する、より適切で堅牢なメカニズムは、YANG を利用してプロトコル実装適合性ステートメント (PICS) を定義することです。この例は [PICS-YANG] にあります。
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.
このようなアドバタイズメントを正しく処理しないルーターが存在する中で MP-TLV を送信すると、パケットの不正な転送などの相互運用性の問題が発生する可能性があります。このセクションでは、既存の仕様で MP-TLV サポートが明示的に示されていないコードポイントに対して MP-TLV を使用する必要がある場合に使用するベスト プラクティスについて説明します。
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 Section 8.1 is important to avoid interoperability issues.
特定のコードポイントに対する MP-TLV の部分的な展開を防止する (または少なくともその可能性を低くする) 手段を実装がどのように提供するかについては、この文書の範囲には含まれていませんが、不注意で問題のある展開シナリオを回避できるようにオペレータを支援する必要性を強調することが重要です。セクション 8.1 で説明したように、MP-TLV の送信を有効または無効にするための適切な制御を提供することは、相互運用性の問題を回避するために重要です。
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.
MP-TLV の送信をサポートする実装では、MP-TLV の生成を有効/無効にする構成制御を提供することが推奨されます。特定の実装における MP-TLV サポートが TLV ごとに異なる可能性があることを考慮すると、これらのコントロールはコードポイントごとの粒度でサポートを提供する必要があります (SHOULD)。たとえば、実装では、IS 拡張到達可能性の MP-TLV はサポートされますが、IP 到達可能性についてはサポートされない場合があります。
Implementations that support disablement of MP-TLVs MUST log the following occurrences:
MP-TLV の無効化をサポートする実装では、次の発生をログに記録しなければなりません。
* An MP-TLV is received when use of MP-TLVs is disabled.
* MP-TLV の使用が無効になっている場合、MP-TLV が受信されます。
* Local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled.
* MP-TLV の生成が無効になっている場合、ローカル LSP の生成では MP-TLV を使用する必要があります。
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 Section 5.
ネットワーク事業者は、セクション 5 で説明されているように、MP-TLV を受信するすべての実装が MP-TLV を正しく解釈できることを確認するまで、MP-TLV を有効にしてはなりません (SHOULD NOT)。
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 Section 8.1.
このセクションでは、MP-TLV の送信に関する制限について説明します。これらの制限を適用する場合、8.1 節で説明した制御の設定に基づいて、MP-TLV の送信が許可されることがすでに決定されていることが前提となります。
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.
オブジェクトに関するすべての情報を含む単一の TLV を送信することは、複数の TLV を送信するよりも推奨されます。複数の TLV からの情報を結合するよりも、単一の TLV からの情報を解析する方が簡単で効率的です。MP-TLV が TLV に適用可能であり、送信する必要がある情報の量が単一の TLV の容量を超えない限り、実装は複数の TLV を送信すべきではありません (SHOULD NOT)。たとえば、既存の TLV に追加のスペースが必要な場合、TLV にスペースがある限り、情報を複数の TLV に分割すべきではありません (SHOULD NOT)。現在の LSP に、より大きくなった TLV に適合するスペースがない場合、TLV を新しい LSP に移動する必要があります (SHOULD)。
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>):
IANA は、「IS-IS Router CAPABILITY TLV の IS-IS Sub-TLV」レジストリから次のコードポイントを登録しました (<https://www.iana.org/assignments/isis-tlv-codepoints> を参照)。
Type:
タイプ：
30
30
Description:
説明：
MP-TLV Support for TLVs with Implicit Support
暗黙的サポートによる TLV の MP-TLV サポート
MP-TLV Applicability:
MP-TLV の適用性:
N
N
Reference:
参照：
Section 7 of RFC 9885
RFC 9885 のセクション 7
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.
IANA は、「IS-IS TLV コードポイント」レジストリ グループ内の多くのレジストリを拡張し、この文書で説明されている MP-TLV プロシージャがそのコードポイントに適用できるかどうかを示す列を追加しました。「Y」はMP-TLVが適用されることを示します。「N」は MP-TLV が適用されないことを示します。
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.
次のサブセクションでは、多数の既存のレジストリの新しい列の初期内容を示します。以下のサブセクションで定義される MP-TLV 適用性の初期値は、現在定義されているサブ TLV が MP-TLV の送信を要求するのに十分であるかどうかに関係なく、MP-TLV はサブ TLV をサポートするすべてのコードポイントに適用できるというルールに基づいています。
To access the relevant IANA registry, search for the registry name associated with each subsection at <https://www.iana.org/assignments/ isis-tlv-codepoints>.
関連する IANA レジストリにアクセスするには、<https://www.iana.org/assignments/isis-tlv-codepoints> で各サブセクションに関連付けられたレジストリ名を検索します。
IANA has added the MP column to the "IS-IS Top-Level TLV Codepoints" registry and populated it as shown in Table 1.
IANA は、「IS-IS トップレベル TLV コードポイント」レジストリに MP 列を追加し、表 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
表 1: IS-IS トップレベル TLV コードポイント
IANA has added the MP column to the "IS-IS Sub-TLVs for Reverse Metric TLV" registry and populated it as shown in Table 2.
IANA は、「IS-IS Sub-TLVs for Reverse Metric TLV」レジストリに MP 列を追加し、表 2 に示すように値を設定しました。
+========+============================+====+
| 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
表 2: リバース メトリック TLV の IS-IS サブ TLV
IANA has added the MP column to the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry and populated it as shown in Table 3.
IANA は、「IS-IS Sub-TLV for TLVs Advertising Neighbor Information」レジストリに MP 列を追加し、表 3 に示すように値を設定しました。
+=========+===================================================+====+
| 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
表 3: ネイバー情報をアドバタイズする TLV の IS-IS サブ TLV
IANA has added the MP column to the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry and populated it as shown in Table 4.
IANA は、「IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability」レジストリに MP 列を追加し、表 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
表 4: TLV アドバタイジング プレフィックスの到達可能性の IS-IS サブ TLV
IANA has added the MP column to the "IS-IS Sub-TLVs for MT-Capability TLV" registry and populated it as shown in Table 5.
IANA は、「IS-IS Sub-TLVs for MT-Capability TLV」レジストリに MP 列を追加し、表 5 に示すように値を設定しました。
+========+==============================+====+
| 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
表 5: MT 機能 TLV の IS-IS サブ 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 Table 6.
IANA は、「IS-IS Router CAPABILITY TLV の IS-IS Sub-TLV」レジストリに MP 列を追加し、表 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
表 6: IS-IS ルータの IS-IS サブ TLV CAPABILITY 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 Table 7.
IANA は、「IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV」レジストリに MP 列を追加し、表 7 に示すように値を入力しました。
+=======+============+====+
| Value | Name | MP |
+=======+============+====+
| 0 | Reserved | |
+-------+------------+----+
| 1-255 | Unassigned | |
+-------+------------+----+
Table 7: IS-IS Sub-Sub-TLVs for SRv6 Capabilities Sub-TLV
表 7: SRv6 機能の IS-IS サブサブ 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 Table 8.
IANA は、「IS-IS Sub-Sub-TLVs for BIER Info Sub-TLV」レジストリに MP 列を追加し、表 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
表 8: BIER 情報サブ TLV の IS-IS サブサブ TLV
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 Table 9.
IANA は、「セグメント識別子/ラベル バインディング TLV の IS-IS サブ TLV」レジストリに MP 列を追加し、表 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: セグメント識別子/ラベル バインディング TLV の IS-IS サブ TLV
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 Table 10.
IANA は、「IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes」レジストリに MP 列を追加し、表 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
表 10: アプリケーション固有のリンク属性の IS-IS サブサブ 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 Table 11.
IANA は、「IS-IS Sub-TLVs for Application-Specific SRLG TLV」レジストリに MP 列を追加し、表 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
表 11: アプリケーション固有の SRLG TLV の IS-IS サブ TLV
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 Table 12.
IANA は、「IS-IS Sub-Sub-TLV for SRv6 SID Sub-TLVs」レジストリに MP 列を追加し、表 12 に示すように値を入力しました。
+=======+====================+====+
| 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
表 12: SRv6 SID サブ TLV の IS-IS サブサブ 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 Table 13.
IANA は、「柔軟なアルゴリズム定義サブ TLV 用の IS-IS サブサブ TLV」レジストリに MP 列を追加し、表 13 に示すように値を設定しました。
+========+============================================+====+
| 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
表 13: 柔軟なアルゴリズム定義の IS-IS サブサブ 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 Table 14.
IANA は、「IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV」レジストリに MP 列を追加し、表 14 に示すように値を入力しました。
+=========+================================+====+
| 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
表 14: フラッド リフレクション ディスカバリ サブ TLV の IS-IS サブサブ TLV
This document creates no new security issues for IS-IS. Additional instances of existing TLVs expose no new information.
この文書により、IS-IS に新たなセキュリティ問題が発生することはありません。既存の TLV の追加インスタンスは新しい情報を公開しません。
Note that support for MP-TLV may result in an implementation being more robust in handling unexpected occurrences of MP-TLV.
MP-TLV のサポートにより、MP-TLV の予期しない発生を処理する実装がより堅牢になる可能性があることに注意してください。
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310].
IS-IS のセキュリティ上の懸念は、[ISO10589]、[RFC5304]、および [RFC5310] で対処されています。
[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>.
[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>.
The following individual made a substantial contribution to the content of this document and should be considered a coauthor:
次の個人は、このドキュメントの内容に多大な貢献をしており、共著者とみなされます。
Chris Bowers
Email: cbowers107@gmail.com
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