[要約] RFC 8491は、IS-ISプロトコルを使用して最大SID深度（MSD）をシグナリングするための仕様です。このRFCの目的は、ネットワークデバイスがサポートする最大SID深度を他のデバイスに通知し、経路計算やトラフィックエンジニアリングにおいて最適な経路を選択するための情報を提供することです。
Internet Engineering Task Force (IETF) J. Tantsura
Request for Comments: 8491 Apstra, Inc.
Category: Standards Track U. Chunduri
ISSN: 2070-1721 Huawei Technologies
S. Aldrin
Google, Inc.
L. Ginsberg
Cisco Systems
November 2018
Signaling Maximum SID Depth (MSD) Using IS-IS
IS-ISを使用した最大SID深度（MSD）のシグナリング
Abstract
概要
This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.
このドキュメントでは、Intermediate System to Intermediate System（IS-IS）ルーターが複数のタイプのサポートされている最大SID深度（MSD）をノードやリンクの粒度でアドバタイズする方法を定義します。そのようなアドバタイズにより、エンティティ（たとえば、集中型コントローラー）は、特定のセグメントID（SID）スタックを特定のネットワークでサポートできるかどうかを判断できます。このドキュメントでは、1種類のMSD、つまり基本MPLS面付けのみを定義しています。ただし、他のMSDタイプをサポートできるエンコードを定義します。このドキュメントでは、セグメントルーティング（SR）が有効になっているネットワークでのMSDの使用に焦点を当てていますが、SRが有効でない場合にもMSDが役立つ場合があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8491.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8491で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4
3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 5
4. Procedures for Defining and Using Node and Link MSD
Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6
5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
When Segment Routing (SR) paths are computed by a centralized controller, it is critical that the controller learn the Maximum SID Depth (MSD) that can be imposed at each node/link of a given SR path. This ensures that the Segment Identifier (SID) stack depth of a computed path does not exceed the number of SIDs the node is capable of imposing.
集中ルーティングコントローラーによってセグメントルーティング（SR）パスが計算される場合、コントローラーが特定のSRパスの各ノード/リンクに課すことができる最大SID深度（MSD）をコントローラーが学習することが重要です。これにより、計算されたパスのセグメント識別子（SID）スタックの深さが、ノードが強制できるSIDの数を超えないことが保証されます。
[PCEP-EXT] defines how to signal MSD in the Path Computation Element Communication Protocol (PCEP). However, if PCEP is not supported/ configured on the head-end of an SR tunnel or a Binding-SID anchor node, and the controller does not participate in IGP routing, it has no way of learning the MSD of nodes and links. BGP-LS (Distribution of Link-State and TE Information Using Border Gateway Protocol) [RFC7752] defines a way to expose topology and associated attributes and capabilities of the nodes in that topology to a centralized controller. MSD signaling by BGP-LS has been defined in [MSD-BGP]. Typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. In order for BGP-LS to signal MSD for all the nodes and links in the network for which MSD is relevant, MSD capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router in the network.
[PCEP-EXT]は、経路計算要素通信プロトコル（PCEP）でMSDに信号を送る方法を定義します。ただし、SREPトンネルまたはBinding-SIDアンカーノードのヘッドエンドでPCEPがサポート/構成されておらず、コントローラーがIGPルーティングに参加していない場合、コントローラーはノードとリンクのMSDを学習する方法がありません。 BGP-LS（ボーダーゲートウェイプロトコルを使用したリンクステートとTE情報の配布）[RFC7752]は、トポロジーと、そのトポロジー内のノードの属性と機能を集中型コントローラーに公開する方法を定義しています。 BGP-LSによるMSDシグナリングは、[MSD-BGP]で定義されています。通常、BGP-LSは、必ずしもヘッドエンドとして機能するとは限らない少数のノードで構成されます。 BGP-LSがMSDが関連するネットワーク内のすべてのノードとリンクに対してMSDを通知するために、MSD機能はネットワーク内のすべての中間システム間（IS-IS）ルーターによって通知されるべきです（SHOULD）。
Other types of MSDs are known to be useful. For example, [ELC-ISIS] defines Entropy Readable Label Depth (ERLD), which is used by a head-end to insert an Entropy Label (EL) at a depth where it can be read by transit nodes.
他のタイプのMSDが役立つことが知られています。たとえば、[ELC-ISIS]は、エントロピーラベル（ELLD）を定義します。これは、中継ノードが読み取ることができる深度にエントロピーラベル（EL）を挿入するためにヘッドエンドで使用されます。
This document defines an extension to IS-IS used to advertise one or more types of MSDs at node and/or link granularity. It also creates an IANA registry for assigning MSD-Type identifiers and defines the Base MPLS Imposition MSD-Type. In the future, it is expected that new MSD-Types will be defined to signal additional capabilities, e.g., entropy labels, SIDs that can be imposed through recirculation, or SIDs associated with another data plane such as IPv6.
このドキュメントでは、ノードやリンクの粒度で1つ以上のタイプのMSDをアドバタイズするために使用されるIS-ISへの拡張を定義します。また、MSDタイプIDを割り当てるためのIANAレジストリを作成し、ベースMPLSインポジションMSDタイプを定義します。将来的には、エントロピーラベル、再循環によって課せられる可能性のあるSID、IPv6などの別のデータプレーンに関連付けられたSIDなどの追加機能を通知する新しいMSDタイプが定義されることが予想されます。
MSD advertisements MAY be useful even if Segment Routing itself is not enabled. For example, in a non-SR MPLS network, MSD defines the maximum label depth.
MSDアドバタイズは、セグメントルーティング自体が有効になっていない場合でも役立つ場合があります。たとえば、非SR MPLSネットワークでは、MSDが最大ラベル深度を定義します。
BMI: Base MPLS Imposition is the number of MPLS labels that can be imposed inclusive of all service/transport/special labels.
BMI：Base MPLS Impositionは、すべてのサービス/トランスポート/特殊ラベルを含めて課すことができるMPLSラベルの数です。
MSD: Maximum SID Depth is the number of SIDs supported by a node or a link on a node.
MSD：最大SID深さは、ノードまたはノード上のリンクによってサポートされるSIDの数です。
SID: Segment Identifier is defined in [RFC8402].
SID：セグメント識別子は[RFC8402]で定義されています。
Label Imposition: Imposition is the act of modifying and/or adding labels to the outgoing label stack associated with a packet. This includes:
ラベルインポジション：インポジションは、パケットに関連付けられた発信ラベルスタックにラベルを変更または追加する行為です。これも：
* replacing the label at the top of the label stack with a new label
* ラベルスタックの一番上のラベルを新しいラベルに置き換える
* pushing one or more new labels onto the label stack
* 1つ以上の新しいラベルをラベルスタックにプッシュする
The number of labels imposed is then the sum of the number of labels that are replaced and the number of labels that are pushed. See [RFC3031] for further details.
課されるラベルの数は、置き換えられるラベルの数とプッシュされるラベルの数の合計になります。詳細については、[RFC3031]を参照してください。
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]で説明されているように解釈されます。
The Node MSD sub-TLV is defined within the body of the IS-IS Router CAPABILITY TLV [RFC7981] to carry the provisioned SID depth of the router originating the IS-IS Router CAPABILITY TLV. Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use by the advertising IGP instance. MSD values may be learned via a hardware API or may be provisioned.
ノードMSDサブTLVは、IS-ISルーターCAPABILITY TLV [RFC7981]の本体内で定義され、IS-ISルーターCAPABILITY TLVを発信するルーターのプロビジョニングされたSID深度を伝達します。ノードMSDは、アドバタイジングIGPインスタンスで使用するように構成された一連のインターフェース上のノードによってサポートされる最小のMSDです。 MSD値は、ハードウェアAPIを介して学習されるか、プロビジョニングされます。
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
０ １ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ................... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node MSD Sub-TLV
図1：ノードMSDサブTLV
Type: 23
タイプ：23
Length: variable (multiple of 2 octets); represents the total length of the Value field
長さ：可変（2オクテットの倍数）;値フィールドの全長を表します
Value: field consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value
値：フィールドは、1オクテットのMSDタイプと1オクテットのMSD値の1つ以上のペアで構成されます。
MSD-Type: value defined in the "IGP MSD-Types" registry created by the IANA Considerations section of this document Section 6
MSD-Type：このドキュメントのIANAの考慮事項セクションで作成された「IGP MSD-Types」レジストリで定義された値セクション6
MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the node. This value MUST represent the lowest value supported by any link configured for use by the advertising IS-IS instance.)
MSD値：0〜255の範囲の数値（すべてのMSDタイプの場合、0は深さのSIDスタックをサポートする機能の欠如を表し、その他の値はノードの値を表します。この値は最小値を表す必要がありますアドバタイジングIS-ISインスタンスで使用するように設定されたリンクでサポートされます。
This sub-TLV is optional. The scope of the advertisement is specific to the deployment.
このサブTLVはオプションです。アドバタイズの範囲は、展開に固有です。
If there exist multiple Node MSD advertisements for the same MSD-Type originated by the same router, the procedures defined in [RFC7981] apply. These procedures may result in different MSD values being used, for example, by different controllers. This does not, however, create any interoperability issue.
同じルーターから発信された同じMSDタイプの複数のノードMSDアドバタイズが存在する場合、[RFC7981]で定義されている手順が適用されます。これらの手順により、たとえば、異なるコントローラーによって異なるMSD値が使用される可能性があります。ただし、これによって相互運用性の問題が発生することはありません。
The Link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 223 to carry the MSD of the interface associated with the link. MSD values may be signaled by the forwarding plane or may be provisioned.
リンクMSDサブTLVは、リンクに関連付けられたインターフェイスのMSDを伝送するために、TLV 22、23、25、141、222、および223に対して定義されています。 MSD値は、フォワーディングプレーンから通知されるか、プロビジョニングされます。
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
０ １ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ................... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Link MSD Sub-TLV
図2：MSDサブTLVのリンク
Type: 15
タイプ：15
Length: variable (multiple of 2 octets); represents the total length of the Value field
長さ：可変（2オクテットの倍数）;値フィールドの全長を表します
Value: field consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value
値：フィールドは、1オクテットのMSDタイプと1オクテットのMSD値の1つ以上のペアで構成されます。
MSD-Type: value defined in the "IGP MSD-Types" registry created by the IANA Considerations section of this document Section 6
MSD-Type：このドキュメントのIANAの考慮事項セクションで作成された「IGP MSD-Types」レジストリで定義された値セクション6
MSD-Value: number in the range of 0-255 (for all MSD-Types, 0 represents the lack of ability to support a SID stack of any depth; any other value represents that of the particular link when used as an outgoing interface.)
MSD値：0〜255の範囲の数値（すべてのMSDタイプの場合、0は任意の深さのSIDスタックをサポートする能力の欠如を表し、その他の値は、発信インターフェイスとして使用された場合の特定のリンクの値を表します。 ）
This sub-TLV is optional.
このサブTLVはオプションです。
If multiple Link MSD advertisements for the same MSD-Type and the same link are received, the procedure to select which copy to use is undefined.
同じMSD-Typeおよび同じリンクの複数のリンクMSDアドバタイズを受信した場合、使用するコピーを選択する手順は定義されていません。
If the advertising router performs label imposition in the context of the ingress interface, it is not possible to meaningfully advertise per-link values. In such a case, only the Node MSD SHOULD be advertised.
アドバタイジングルータが入力インターフェイスのコンテキストでラベルインポジションを実行する場合、リンクごとの値を有意義にアドバタイズすることはできません。そのような場合、ノードMSDのみがアドバタイズされるべきです（SHOULD）。
When Link MSD is present for a given MSD-Type, the value of the Link MSD MUST take precedence over the Node MSD. If a Link MSD-Type is not signaled, but the Node MSD-Type is, then the Node MSD-Type value MUST be considered to be the MSD value for that link.
リンクMSDが特定のMSDタイプに存在する場合、リンクMSDの値はノードMSDよりも優先される必要があります。リンクMSD-Typeは通知されないが、ノードMSD-Typeは通知される場合、ノードMSD-Type値はそのリンクのMSD値であると見なされなければなりません（MUST）。
In order to increase flooding efficiency, it is RECOMMENDED that routers with homogenous Link MSD values advertise just the Node MSD value.
フラッディング効率を高めるために、同種のリンクMSD値を持つルーターがノードMSD値のみをアドバタイズすることをお勧めします。
The meaning of the absence of both Node and Link MSD advertisements for a given MSD-Type is specific to the MSD-Type. Generally, it can only be inferred that the advertising node does not support advertisement of that MSD-Type. In some cases, however, the lack of advertisement might imply that the functionality associated with the MSD-Type is not supported. The correct interpretation MUST be specified when an MSD-Type is defined.
特定のMSDタイプのノードとリンクの両方のMSDアドバタイズがないことの意味は、MSDタイプに固有です。一般に、アドバタイジングノードがそのMSDタイプのアドバタイズメントをサポートしていないことが推測されるだけです。ただし、場合によっては、アドバタイズの欠如は、MSDタイプに関連付けられた機能がサポートされていないことを意味する場合があります。 MSDタイプが定義されている場合は、正しい解釈を指定する必要があります。
Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels that can be imposed, including all service/transport/special labels.
ベースMPLSインポジションMSD（BMI-MSD）は、すべてのサービス/トランスポート/特殊ラベルを含む、インポーズできるMPLSラベルの総数を通知します。
The absence of BMI-MSD advertisements indicates only that the advertising node does not support advertisement of this capability.
BMI-MSDアドバタイズがない場合は、アドバタイジングノードがこの機能のアドバタイズをサポートしていないことのみを示します。
IANA has allocated a sub-TLV type for the new sub-TLV proposed in Section 2 of this document from the "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)" registry as defined by [RFC7981].
IANAは、[RFC7981]で定義されている「TLV 242（IS-ISルーターCAPABILITY TLV）のサブTLV」レジストリから、このドキュメントのセクション2で提案された新しいサブTLVにサブTLVタイプを割り当てました。
IANA has allocated the following value:
IANAは次の値を割り当てました。
Value Description Reference
----- --------------- -------------
23 Node MSD This document
Figure 3: Node MSD
ふぃぐれ ３： ので ＭＳＤ
IANA has allocated a sub-TLV type as defined in Section 3 from the "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs)" registry.
IANAは、「TLV 22、23、25、141、222、および223のサブTLV（拡張IS到達可能性、ISネイバー属性、L2バンドルメンバー属性、インターAS）からセクション3で定義されたサブTLVタイプを割り当てました到達可能性情報、MT-ISN、およびMT ISネイバー属性TLV）」レジストリ。
IANA has allocated the following value:
IANAは次の値を割り当てました。
Value Description Reference
----- --------------- -------------
15 Link MSD This document
Figure 4: Link MSD
図4：MSDのリンク
Per-TLV information where Link MSD sub-TLV can be part of:
リンクMSDサブTLVが含まれる可能性があるTLVごとの情報：
TLV 22 23 25 141 222 223
--- --------------------
y y y y y y
Figure 5: TLVs Where LINK MSD Sub-TLV Can Be Present
図5：LINK MSDサブTLVが存在できるTLV
IANA has created an IANA-managed registry titled "IGP MSD-Types" under the "Interior Gateway Protocol (IGP) Parameters" registry to identify MSD-Types as proposed in Sections 2 and 3. The registration procedure is "Expert Review" as defined in [RFC8126]. Types are an unsigned 8-bit number. The following values are defined by this document:
IANAは、「Interior Gateway Protocol（IGP）Parameters」レジストリの下に「IGP MSD-Types」というタイトルのIANA管理レジストリを作成し、セクション2および3で提案されているMSDタイプを識別します。登録手順は、「エキスパートレビュー」です。 [RFC8126]。タイプは、符号なしの8ビット数です。このドキュメントでは、次の値が定義されています。
Value Name Reference
----- --------------------- -------------
0 Reserved This document
1 Base MPLS Imposition MSD This document
2-250 Unassigned
251-254 Experimental Use This document
255 Reserved This document
Figure 6: MSD-Types Codepoints Registry
図6：MSDタイプのコードポイントレジストリ
General guidance for the designated experts is defined in [RFC7370].
指定された専門家のための一般的なガイダンスは[RFC7370]で定義されています。
Security considerations as specified by [RFC7981] are applicable to this document.
[RFC7981]で指定されているセキュリティの考慮事項は、このドキュメントに適用されます。
The advertisement of an incorrect MSD value may have negative consequences. If the value is smaller than supported, path computation may fail to compute a viable path. If the value is larger than supported, an attempt to instantiate a path that can't be supported by the head-end (the node performing the SID imposition) may occur.
不適切なMSD値のアドバタイズは、悪影響を与える可能性があります。値がサポートされている値より小さい場合、パスの計算は実行可能なパスの計算に失敗する可能性があります。値がサポートされているよりも大きい場合、ヘッドエンド（SIDインポジションを実行するノード）でサポートできないパスをインスタンス化しようとする試みが発生する可能性があります。
The presence of this information may also inform an attacker of how to induce any of the aforementioned conditions.
この情報の存在は、前述の条件のいずれかを誘発する方法を攻撃者に通知する可能性もあります。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, <https://www.rfc-editor.org/info/rfc7370>.
[RFC7370] Ginsberg、L。、「IS-IS TLVコードポイントレジストリの更新」、RFC 7370、DOI 10.17487 / RFC7370、2014年9月、<https://www.rfc-editor.org/info/rfc7370>。
[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>.
[RFC7981] Ginsberg、L.、Previdi、S。、およびM. Chen、「IS-IS Extensions for Advertising Router Information」、RFC 7981、DOI 10.17487 / RFC7981、2016年10月、<https：//www.rfc-editor .org / info / rfc7981>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[ELC-ISIS] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. Litkowski, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS", Work in Progress, draft-ietf-isis-mpls-elc-06, September 2018.
[ELC-ISIS] Xu、X.、Kini、S.、Sivabalan、S.、Filsfils、C。、およびS. Litkowski、「IS-ISを使用したシグナリングエントロピーラベル機能とエントロピー読み取り可能なラベルの深さ」、進行中の作業、 draft-ietf-isis-mpls-elc-06、2018年9月。
[MSD-BGP] Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State", Work in Progress, draft-ietf-idr-bgp-ls-segment-routing-msd-02, August 2018.
[MSD-BGP] Tantsura、J.、Chunduri、U.、Mirsky、G。、およびS. Sivabalan、「ボーダーゲートウェイプロトコルリンクステートを使用したMSD（最大SID深度）のシグナリング」、作業中、draft-ietf- idr-bgp-ls-segment-routing-msd-02、2018年8月。
[PCEP-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-13, October 2018.
[PCEP-EXT] Sivabalan、S.、Filsfils、C.、Tantsura、J.、Henderickx、W.、J. Hardwick、 "PCEP Extensions for Segment Routing"、Work in Progress、draft-ietf-pce-segment- routing-13、2018年10月。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
Acknowledgements
謝辞
The authors would like to thank Acee Lindem, Ketan Talaulikar, Stephane Litkowski, and Bruno Decraene for their reviews and valuable comments.
著者は、レビューと貴重なコメントを提供してくれたAcee Lindem、Ketan Talaulikar、Stephane Litkowski、およびBruno Decraeneに感謝します。
Contributors
貢献者
The following people contributed to this document:
以下の人々がこの文書に貢献しました：
Peter Psenak
ピータープセナック
Email: ppsenak@cisco.com
Authors' Addresses
著者のアドレス
Jeff Tantsura Apstra, Inc.
Jeff Tantsura Apstra、Inc.
Email: jefftant.ietf@gmail.com
Uma Chunduri Huawei Technologies
u MacろくでなしURI hu Aはテクノロジー
Email: uma.chunduri@huawei.com
Sam Aldrin Google, Inc.
サムアルドリンGoogle、Inc.
Email: aldrin.ietf@gmail.com
Les Ginsberg Cisco Systems
Les Ginsberg Cisco Systems
Email: ginsberg@cisco.com