[要約] RFC 8476は、OSPFで最大SID深度（MSD）をシグナリングするための仕様です。その目的は、セグメントルーティング（SR）ネットワークでの経路選択と転送の最適化を可能にすることです。
Internet Engineering Task Force (IETF) J. Tantsura
Request for Comments: 8476 Apstra, Inc.
Category: Standards Track U. Chunduri
ISSN: 2070-1721 Huawei Technologies
S. Aldrin
Google, Inc.
P. Psenak
Cisco Systems
December 2018
Signaling Maximum SID Depth (MSD) Using OSPF
OSPFを使用した最大SID深度（MSD）のシグナリング
Abstract
概要
This document defines a way for an Open Shortest Path First (OSPF) 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 Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.
このドキュメントでは、Open Shortest Path First（OSPF）ルーターが、サポートされている複数のタイプの最大SID深度（MSD）をノードやリンクの粒度でアドバタイズする方法を定義しています。このようなアドバタイズメントにより、エンティティ（集中コントローラーなど）は、特定のセグメント識別子（SID）スタックを特定のネットワークでサポートできるかどうかを判断できます。このドキュメントでは、RFC 8491で定義されているシグナリングMSDのみを参照していますが、他のMSDタイプをサポートできるエンコーディングを定義しています。ここで、「OSPF」という用語は、OSPFv2とOSPFv3の両方を意味します。
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/rfc8476.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8476で入手できます。
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 ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................4
2. Node MSD Advertisement ..........................................5
3. Link MSD Sub-TLV ................................................6
4. Procedures for Defining and Using Node and Link MSD
Advertisements ..................................................7
5. IANA Considerations .............................................7
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
Acknowledgements ..................................................11
Contributors ......................................................11
Authors' Addresses ................................................11
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 on a given SR path. This ensures that the Segment Identifier (SID) stack depth of a computed path doesn't 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 BGP) [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 OSPF router in the network.
[PCEP-EXT]は、経路計算要素通信プロトコル（PCEP）でMSDに信号を送る方法を定義します。ただし、SREPトンネルまたはBinding-SIDアンカーノードのヘッドエンドでPCEPがサポート/構成されておらず、コントローラーがIGPルーティングに参加していない場合、コントローラーはノードとリンクのMSDを学習する方法がありません。 BGP-LS（BGPを使用したリンク状態とTE情報の配布）[RFC7752]は、トポロジーと、そのトポロジー内のノードの関連する属性と機能を集中型コントローラーに公開する方法を定義しています。 BGP-LSによるMSDシグナリングは、[MSD-BGP]で定義されています。通常、BGP-LSは、必ずしもヘッドエンドとして機能するとは限らない少数のノードで構成されます。 BGP-LSがMSDに関連するネットワーク内のすべてのノードとリンクにMSDを通知するために、MSD機能はネットワーク内のすべてのOSPFルーターによって通知されるべきです（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 OSPF used to advertise one or more types of MSDs at node and/or link granularity. In the future, it is expected that new MSD-Types will be defined to signal additional capabilities, e.g., ELs, SIDs that can be imposed through recirculation, or SIDs associated with another data plane such as IPv6.
このドキュメントでは、ノードやリンクの粒度で1つ以上のタイプのMSDをアドバタイズするために使用されるOSPFの拡張機能を定義しています。将来的には、追加の機能（EL、再循環によって課せられるSID、IPv6などの別のデータプレーンに関連付けられたSIDなど）を通知する新しいMSDタイプが定義される予定です。
MSD advertisements MAY be useful even if SR itself is not enabled. For example, in a non-SR MPLS network, MSD defines the maximum label depth.
MSDアドバタイズは、SR自体が有効になっていない場合でも役立つ場合があります。たとえば、非SR MPLSネットワークでは、MSDが最大ラベル深度を定義します。
This memo makes use of the terms defined in [RFC7770].
このメモは[RFC7770]で定義された用語を利用します。
BGP-LS: Distribution of Link-State and TE Information Using BGP
BGP-LS：BGPを使用したリンク状態とTE情報の配布
OSPF: Open Shortest Path First
OSPF：Open Shortest Path First
MSD: Maximum SID Depth - the number of SIDs supported by a node or a link on a node
MSD：最大SID深度-ノードまたはノード上のリンクによってサポートされるSIDの数
SID: Segment Identifier as 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]を参照してください。
PCEP: Path Computation Element Communication Protocol
PCEP：パス計算要素通信プロトコル
SR: Segment Routing
SR：セグメントルーティング
LSA: Link State Advertisement
LSA：リンクステートアドバタイズメント
RI: Router Information
RI：ルーター情報
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 TLV within the body of the OSPF RI Opaque LSA [RFC7770] is defined to carry the provisioned SID depth of the router originating the RI LSA. 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.
OSPF RI Opaque LSA [RFC7770]の本体内のノードMSD TLVは、RI LSAを発信するルーターのプロビジョニングされたSID深度を伝送するように定義されています。ノードMSDは、アドバタイジングIGPインスタンスで使用するように構成された一連のインターフェース上のノードによってサポートされる最小のMSDです。 MSD値は、ハードウェアAPIを介して学習されるか、プロビジョニングされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node MSD TLV
図1：ノードMSD TLV
Type: 12
タイプ：12
Length: variable (multiple of 2 octets); represents the total length of the value field in octets.
長さ：可変（2オクテットの倍数）;値フィールドの全長をオクテットで表します。
Value: consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value.
値：1オクテットのMSDタイプと1オクテットのMSD値の1つ以上のペアで構成されます。
MSD-Type: one of the values defined in the "IGP MSD-Types" registry defined in [RFC8491].
MSD-Type：[RFC8491]で定義されている「IGP MSD-Types」レジストリで定義されている値の1つ。
MSD-Value: a number in the range of 0-255. For all MSD-Types, 0 represents the lack of ability to impose an MSD 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 OSPF instance.
MSD値：0から255の範囲の数値。すべてのMSDタイプで、0は任意の深さのMSDスタックを強制する機能がないことを表します。その他の値はノードの値を表します。この値は、アドバタイズOSPFインスタンスで使用するように構成されたリンクでサポートされる最低値を表す必要があります。
This TLV is optional and is applicable to both OSPFv2 and OSPFv3. The scope of the advertisement is specific to the deployment.
このTLVはオプションであり、OSPFv2とOSPFv3の両方に適用できます。アドバタイズの範囲は、展開に固有です。
When multiple Node MSD TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information (RI) LSA. If the Node MSD TLV appears in multiple RI LSAs that have different flooding scopes, the Node MSD TLV in the RI LSA with the area-scoped flooding scope MUST be used. If the Node MSD TLV appears in multiple RI LSAs that have the same flooding scope, the Node MSD TLV in the RI LSA with the numerically smallest Instance ID MUST be used and other instances of the Node MSD TLV MUST be ignored. The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of Node MSD TLV advertisement, area-scoped flooding is RECOMMENDED.
特定のルーターから複数のノードMSD TLVを受信した場合、受信者はルーター情報（RI）LSAで最初に出現したTLVを使用する必要があります。ノードMSD TLVが異なるフラッディングスコープを持つ複数のRI LSAに表示される場合、エリアスコープのフラッディングスコープを持つRI LSAのノードMSD TLVを使用する必要があります。同じフラッディングスコープを持つ複数のRI LSAにノードMSD TLVが表示される場合、数値的に最小のインスタンスIDを持つRI LSAのノードMSD TLVを使用する必要があり、ノードMSD TLVの他のインスタンスは無視する必要があります。 RI LSAは、定義された不透明なフラッディングスコープ（リンク、エリア、または自律システム（AS））のいずれかでアドバタイズできます。ノードMSD TLVアドバタイズメントの目的で、エリアスコープのフラッディングをお勧めします。
The Link MSD sub-TLV is defined to carry the MSD of the interface associated with the link. MSD values may be learned via a hardware API or may be provisioned.
リンクMSDサブTLVは、リンクに関連付けられたインターフェイスのMSDを伝送するように定義されています。 MSD値は、ハードウェアAPIを介して学習されるか、プロビジョニングされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Link MSD Sub-TLV
図2：MSDサブTLVのリンク
Type: For OSPFv2, the link-level MSD-Value is advertised as an optional sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684] and has a type of 6.
タイプ：OSPFv2の場合、リンクレベルのMSD値は、[RFC7684]で定義されているように、OSPFv2拡張リンクTLVのオプションのサブTLVとしてアドバタイズされ、タイプは6です。
For OSPFv3, the link-level MSD-Value is advertised as an optional sub-TLV of the E-Router-LSA TLV as defined in [RFC8362] and has a type of 9.
OSPFv3の場合、リンクレベルのMSD値は、[RFC8362]で定義されているE-Router-LSA TLVのオプションのサブTLVとしてアドバタイズされ、タイプは9です。
Length: variable; same as defined in Section 2.
長さ：可変。セクション2の定義と同じ。
Value: consists of one or more pairs of a 1-octet MSD-Type and 1-octet MSD-Value.
値：1オクテットのMSDタイプと1オクテットのMSD値の1つ以上のペアで構成されます。
MSD-Type: one of the values defined in the "IGP MSD-Types" registry defined in [RFC8491].
MSD-Type：[RFC8491]で定義されている「IGP MSD-Types」レジストリで定義されている値の1つ。
The MSD-Value field contains the Link MSD of the router originating the corresponding LSA as specified for OSPFv2 and OSPFv3. The Link MSD is a number in the range of 0-255. For all MSD-Types, 0 represents the lack of ability to impose an MSD stack of any depth; any other value represents that of the particular link when used as an outgoing interface.
MSD-Valueフィールドには、OSPFv2およびOSPFv3で指定された、対応するLSAを発信するルーターのリンクMSDが含まれています。リンクMSDは0〜255の範囲の数値です。すべてのMSDタイプで、0は任意の深さのMSDスタックを強制する機能がないことを表します。その他の値は、発信インターフェースとして使用された場合の特定のリンクの値を表します。
If this sub-TLV is advertised multiple times for the same link in different OSPF Extended Link Opaque LSAs / E-Router-LSAs originated by the same OSPF router, the sub-TLV in the OSPFv2 Extended Link Opaque LSA with the smallest Opaque ID or in the OSPFv3 E-Router-LSA with the smallest Link State ID MUST be used by receiving OSPF routers. This situation SHOULD be logged as an error.
このサブTLVが、同じOSPFルーターによって発信された異なるOSPF拡張リンク不透明LSA / E-Router-LSAの同じリンクに対して複数回アドバタイズされる場合、最小の不透明IDを持つOSPFv2拡張リンク不透明LSAのサブTLVまたはOSPFv3 E-Router-LSAでは、リンク状態IDが最小のOSPFルーターを受信して使用する必要があります。この状況はエラーとして記録する必要があります。
When Link MSD is present for a given MSD-Type, the value of the Link MSD MUST take precedence over the Node MSD. When a Link MSD-Type is not signaled but the Node MSD-Type is, then the Node MSD-Type value MUST be considered as 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. However, in some cases the lack of advertisement might imply that the functionality associated with the MSD-Type is not supported. Per [RFC8491], the correct interpretation MUST be specified when an MSD-Type is defined.
特定のMSDタイプのノードとリンクの両方のMSDアドバタイズがないことの意味は、MSDタイプに固有です。一般に、アドバタイジングノードがそのMSDタイプのアドバタイズメントをサポートしていないことが推測されるだけです。ただし、アドバタイズの欠如は、MSDタイプに関連付けられた機能がサポートされていないことを意味する場合があります。 [RFC8491]に従い、MSD-Typeが定義されている場合、正しい解釈を指定する必要があります。
This specification updates several existing OSPF registries.
この仕様は、いくつかの既存のOSPFレジストリを更新します。
IANA has allocated TLV type 12 from the "OSPF Router Information (RI) TLVs" registry as defined by [RFC7770].
IANAは、[RFC7770]で定義されている「OSPFルーター情報（RI）TLV」レジストリからTLVタイプ12を割り当てました。
Value Description Reference
----- --------------- -------------
12 Node MSD This document
Figure 3: RI Node MSD
ふぃぐれ ３： り ので ＭＳＤ
IANA has allocated sub-TLV type 6 from the "OSPFv2 Extended Link TLV Sub-TLVs" registry.
IANAは、「OSPFv2拡張リンクTLVサブTLV」レジストリからサブTLVタイプ6を割り当てました。
Value Description Reference
----- --------------- -------------
6 OSPFv2 Link MSD This document
Figure 4: OSPFv2 Link MSD
図4：OSPFv2リンクMSD
IANA has allocated sub-TLV type 9 from the "OSPFv3 Extended-LSA Sub-TLVs" registry.
IANAは、「OSPFv3 Extended-LSA Sub-TLVs」レジストリからサブTLVタイプ9を割り当てました。
Value Description Reference
----- --------------- -------------
9 OSPFv3 Link MSD This document
Figure 5: OSPFv3 Link MSD
図5：OSPFv3リンクMSD
Security concerns for OSPF are addressed in [RFC7474], [RFC4552], and [RFC7166]. Further security analysis for the OSPF protocol is done in [RFC6863]. Security considerations as specified by [RFC7770], [RFC7684], and [RFC8362] are applicable to this document.
OSPFのセキュリティ問題は、[RFC7474]、[RFC4552]、および[RFC7166]で対処されています。 OSPFプロトコルのさらなるセキュリティ分析は[RFC6863]で行われます。 [RFC7770]、[RFC7684]、および[RFC8362]で指定されているセキュリティの考慮事項は、このドキュメントに適用されます。
Implementations MUST ensure that malformed TLVs and sub-TLVs defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPF router or routing process. Reception of malformed TLVs or sub-TLVs SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and sub-TLVs SHOULD be rate-limited to prevent a Denial-of-Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane.
実装では、このドキュメントで定義されている不正なTLVとサブTLVが検出され、攻撃者がOSPFルーターまたはルーティングプロセスをクラッシュさせる脆弱性を提供していないことを確認する必要があります。不正な形式のTLVまたはサブTLVの受信は、さらに分析するためにカウントおよび/またはログ記録する必要があります。不正なTLVとサブTLVのロギングは、サービス拒否（DoS）攻撃（分散またはその他）がOSPFコントロールプレーンに過負荷をかけないようにレート制限する必要があります（SHOULD）。
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.
この情報の存在は、前述の条件のいずれかを誘発する方法を攻撃者に通知する可能性もあります。
There's no DoS risk specific to this extension, and it is not vulnerable to replay attacks.
この拡張機能に固有のDoSリスクはなく、攻撃をリプレイすることに対して脆弱ではありません。
[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>。
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7684] Psenak、P.、Gredler、H.、Shakir、R.、Henderickx、W.、Tantsura、J。、およびA. Lindem、「OSPFv2 Prefix / Link Attribute Advertisement」、RFC 7684、DOI 10.17487 / RFC7684、 2015年11月、<https://www.rfc-editor.org/info/rfc7684>。
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7770] Lindem、A.、Ed。、Shen、N.、Vasseur、JP。、Aggarwal、R.、and S. Shaffer、 "Extensions to OSPF for Advertising Optional Router Capabilities"、RFC 7770、DOI 10.17487 / RFC7770、 2016年2月、<https://www.rfc-editor.org/info/rfc7770>。
[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>。
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8362] Lindem、A.、Roy、A.、Goethals、D.、Reddy Vallem、V。、およびF. Baker、「OSPFv3 Link State Advertisement（LSA）Extensibility」、RFC 8362、DOI 10.17487 / RFC8362、2018年4月、<https://www.rfc-editor.org/info/rfc8362>。
[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>。
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, <https://www.rfc-editor.org/info/rfc8491>.
[RFC8491] Tantsura、J.、Chunduri、U.、Aldrin、S。、およびL. Ginsberg、「IS-ISを使用したシグナリングの最大SID深度（MSD）」、RFC 8491、DOI 10.17487 / RFC8491、2018年11月、<https ：//www.rfc-editor.org/info/rfc8491>。
[ELC-ISIS] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. Litkowski, "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF", Work in Progress, draft-ietf-ospf-mpls-elc-07, September 2018.
[ELC-ISIS] Xu、X.、Kini、S.、Sivabalan、S.、Filsfils、C。、およびS. Litkowski、「OSPFを使用したシグナリングエントロピーラベル機能とエントロピー読み取り可能なラベルスタックの深さ」、進行中の作業、 draft-ietf-ospf-mpls-elc-07、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-14, 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-14、2018年10月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.
[RFC4552] Gupta、M.、N。Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、DOI 10.17487 / RFC4552、2006年6月、<https://www.rfc-editor.org/info/rfc4552>。
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, DOI 10.17487/RFC6863, March 2013, <https://www.rfc-editor.org/info/rfc6863>.
[RFC6863] Hartman、S。およびD. Zhang、「Analysis of OSPF Security Using the Keying and Authentication for Routing Protocols（KARP）Design Guide」、RFC 6863、DOI 10.17487 / RFC6863、2013年3月、<https：// www .rfc-editor.org / info / rfc6863>。
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.
[RFC7166] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 7166、DOI 10.17487 / RFC7166、2014年3月、<https://www.rfc-editor.org/ info / rfc7166>。
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.
[RFC7474] Bhatia、M.、Hartman、S.、Zhang、D。、およびA. Lindem、編、「手動キー管理を使用する場合のOSPFv2のセキュリティ拡張」、RFC 7474、DOI 10.17487 / RFC7474、2015年4月、< https://www.rfc-editor.org/info/rfc7474>。
[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, Tal Mizrahi, Stephane Litkowski, and Bruno Decraene for their reviews and valuable comments.
著者は、レビューと貴重なコメントを提供してくれたAcee Lindem、Ketan Talaulikar、Tal Mizrahi、Stephane Litkowski、およびBruno Decraeneに感謝します。
Contributors
貢献者
The following person contributed to this document:
次の人がこのドキュメントに貢献しました：
Les Ginsberg
ギンズバーグ
Email: ginsberg@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
Peter Psenak Cisco Systems
Peter Psenak Cisco Systems
Email: ppsenak@cisco.com