RFC 8814 - Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol

RFC 8814 - Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8814.html
タイトル : RFC 8814 - ボーダーゲートウェイプロトコルを使用した最大SID深度（MSD）のシグナリング-リンク状態
翻訳編集 : 自動生成

[要約] RFC 8814は、BGP-LSを使用して最大SID深度（MSD）をシグナリングするための標準を定義しています。このRFCの目的は、ネットワーク内のセグメント間の経路選択を改善し、ネットワークのスケーラビリティを向上させることです。

Internet Engineering Task Force (IETF)                       J. Tantsura
Request for Comments: 8814                                  Apstra, Inc.
Category: Standards Track                                    U. Chunduri
ISSN: 2070-1721                                   Futurewei Technologies
                                                           K. Talaulikar
                                                           Cisco Systems
                                                               G. Mirsky
                                                               ZTE Corp.
                                                        N. Triantafillis
                                                     Amazon Web Services
                                                             August 2020

Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State

ボーダーゲートウェイプロトコルを使用したシグナリング最大SID深度（MSD） - リンク状態

Abstract

概要

This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.

このドキュメントでは、Border Gateway Protocol - Link State (BGP-LS) スピーカが、サポートされている複数のタイプの最大SID深度(MSD)をノードおよび/またはリンクの粒度でアドバタイズする方法を定義します。

Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.

このような広告は、エンティティ（例えば、集中制御装置）が、特定のセグメント識別子（SID）スタックが所定のネットワークでサポートされているかどうかを判断することを可能にする。

Status of This Memo

本メモの状況

This is an Internet Standards Track document.

これは、インターネット標準化トラックの文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネット技術タスクフォース(IETF)の成果物である。これは 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/rfc8814.

この文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8814 で入手することができる。

著作権について

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)の対象となります。これらの文書には、本文書に関するあなたの権利と制限事項が記載されているので、注意して確認してください。この文書から抽出されたコードコンポーネントは、トラストの法的規定の第4.e項に記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供されています。

Table of Contents

   1.  Introduction
     1.1.  Conventions Used in This Document
       1.1.1.  Terminology
       1.1.2.  Requirements Language
   2.  Advertisement of MSD via BGP-LS
   3.  Node MSD TLV
   4.  Link MSD TLV
   5.  IANA Considerations
   6.  Manageability Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction

When Segment Routing (SR) [RFC8402] paths are computed by a centralized controller, it is critical that the controller learns 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）[RFC8402]パスが集中型コントローラによって計算されると、コントローラが特定のSRパス上の各ノード/リンクに課される最大SID深さ（MSD）を学習することが重要です。これにより、計算された経路のセグメント識別子（SID）スタック深さが、ノードが課すことができるSIDの数を超えないようにします。

[RFC8664] defines how to signal MSD in the Path Computation Element Protocol (PCEP). The OSPF and IS-IS extensions for the signaling of MSD are defined in [RFC8476] and [RFC8491], respectively.

[RFC8664] PATH計算要素プロトコル（PCEP）でMSDの信号を定義します。MSDのシグナリングのOSPFとIS-ISの拡張子は、それぞれ[RFC8476]と[RFC8491]で定義されています。

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 [RFC7752] defines a way to expose topology and associated attributes and capabilities of the nodes in that topology to a centralized controller.

ただし、PCEPがSRトンネルまたはBinding-SIDアンカーノードのヘッドエンドでサポート/設定されていない場合、コントローラがIGPルーティングに参加していない場合は、ノードとリンクのMSDを学習する方法はありません。BGP-LS [RFC7752]そのトポロジ内のノードのトポロジと関連する属性と機能を集中型コントローラに公開する方法を定義します。

This document defines extensions to BGP-LS to advertise one or more types of MSDs at node and/or link granularity. Other types of MSDs are known to be useful. For example, [OSPF-ELC] and [ISIS-ELC] define Entropy Readable Label Depth (ERLD), which is used by a head-end to insert an Entropy Label (EL) at a depth that can be read by transit nodes.

このドキュメントは、ノードおよび/またはリンクの粒度で1種類以上のMSDSをアドバタイズするための拡張子をBGP-LSに定義します。他の種類のMSDSは有用であることが知られている。たとえば、[OSPF-ELC]と[ISIS-ELC]はエントロピー読み取り可能なラベル深さ（ERLD）を定義します。これは、アドレスノードで読み取ることができる深さでエントロピーラベル（EL）を挿入するためにヘッドエンドによって使用されます。

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. 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 - タイプは、例えば、再循環を通して課すことができる追加の機能、またはIPv6のような別のデータプレーンに関連するSIDをシグナリングすることが期待されることが予想される。MSD広告は、SR自体が有効になっていなくても便利です。たとえば、非SR MPLSネットワークでは、MSDは最大ラベル深度を定義します。

1.1. Conventions Used in This Document

1.1. この文書で使用されている規約

1.1.1. Terminology

1.1.1. 用語

MSD: Maximum SID Depth - the number of SIDs supported by a node or a link on a node

MSD：最大SID DEPTH - ノードでサポートされているSIDの数またはノード上のリンクの数

PCE: Path Computation Element

PCE：パス計算要素

PCEP: Path Computation Element Protocol

PCEP：パス計算要素プロトコル

SID: Segment Identifier as defined in [RFC8402]

SID：[RFC8402]で定義されているセグメント識別子

SR: Segment Routing

SR：セグメントルーティング

Label Imposition: Imposition is the act of modifying and/or adding labels to the outgoing label stack associated with a packet. This includes:

ラベルImposition：Packuseに関連付けられている発信ラベルスタックにラベルを修正および/または追加する行為です。これも：

* 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]を参照してください。

1.1.2. Requirements Language

1.1.2. 要件言語

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.

「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。

2. Advertisement of MSD via BGP-LS

2. BGP-LSを介したMSDの広告

This document describes extensions that enable BGP-LS speakers to signal the MSD capabilities [RFC8491] of nodes and their links in a network to a BGP-LS consumer of network topology such as a centralized controller. The centralized controller can leverage this information in computation of SR paths based on their MSD capabilities. When a BGP-LS speaker is originating the topology learnt via link-state routing protocols such as OSPF or IS-IS, the MSD information for the nodes and their links is sourced from the underlying extensions as defined in [RFC8476] and [RFC8491], respectively.

このドキュメントでは、BGP-LSスピーカーがノードのMSD機能[RFC8491]を、ネットワーク内のMSD機能と集中型コントローラなどのネットワークトポロジのBGP-LSコンシューマにシグナリングできるようにする拡張機能について説明します。集中型コントローラは、MSD機能に基づいてSRパスの計算においてこの情報を活用することができる。BGP-LSスピーカーがOSPFまたはIS-ISなどのリンクステートルーティングプロトコルを介して学習されたトポロジーに発信されている場合、ノードのMSD情報とそのリンクは[RFC8476]と[RFC8491]で定義されている基になる拡張子から供給されます。それぞれ。

The extensions introduced in this document allow for advertisement of different MSD-Types, which are defined elsewhere and were introduced in [RFC8491]. This enables sharing of MSD-Types that may be defined in the future by the IGPs in BGP-LS.

この文書で導入された拡張機能は、他の場所で定義され、[RFC8491]で導入されたさまざまなMSD型の広告を可能にします。これにより、BGP-LSのIGPSによって将来定義され得るMSD型の共有が可能になります。

3. Node MSD TLV

3. ノードMSD TLV

The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute TLV [RFC7752] to carry the provisioned SID depth of the router identified by the corresponding Router-ID. Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use. MSD values may be learned via a hardware API or may be provisioned. The following format is used:

ノードMSD（[RFC8476] [RFC8491]）は、新しいノード属性TLV [RFC7752]に符号化され、対応するルータIDによって識別されるルータのプロビジョニングされたSID深度を搬送する。ノードMSDは、使用するように構成されたインターフェイスのセット上のノードによってサポートされている最小の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 Format

図1：ノードMSD TLVフォーマット

Where:

ただし：

Type: 266

タイプ：266

Length: variable (multiple of 2); 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型：[RFC8491]で定義されている「IGP MSD型」レジストリで定義されている値の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 protocol instance.

msd-value：0~255の範囲の数値。すべてのMSD型について、0は任意の深さのMSDスタックを課す能力の欠如を表す。他の値はノードのそれを表します。この値は、広告プロトコルインスタンスで使用するように構成されたリンクによってサポートされている最下位の値を表している必要があります。

4. Link MSD TLV

4. リンクMSD TLV

The Link MSD ([RFC8476] [RFC8491]) is defined to carry the MSD of the interface associated with the link. It is encoded in a new Link Attribute TLV [RFC7752] using the following format:

リンクMSD（[RFC8476] [RFC8491]）は、リンクに関連付けられているインターフェイスのMSDを搬送するように定義されています。次の形式を使用して、新しいリンク属性TLV [RFC7752]でエンコードされています。

      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 TLV Format

図2：リンクMSD TLVフォーマット

Where:

ただし：

Type: 267

タイプ：267

Length: variable (multiple of 2); 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型：[RFC8491]で定義されている「IGP MSD型」レジストリで定義されている値の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 link when used as an outgoing interface.

msd-value：0~255の範囲の数値。すべてのMSD型について、0は任意の深さのMSDスタックを課す能力の欠如を表す。他の値は、発信インターフェイスとして使用されるときのリンクのものを表します。

5. IANA Considerations

5. IANAの考慮事項

IANA has assigned code points from the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" based on the table below.

IANAは、レジストリ「BGP-LSノード記述子、リンク記述子、プレフィックス記述子、および属性TLV」からコードポイントを割り当てました。

    +==========+=============+===========================+===========+
    | TLV Code | Description | IS-IS TLV/Sub-TLV         | Reference |
    | Point    |             |                           |           |
    +==========+=============+===========================+===========+
    | 266      | Node MSD    | 242/23                    | This      |
    |          |             |                           | document  |
    +----------+-------------+---------------------------+-----------+
    | 267      | Link MSD    | (22,23,25,141,222,223)/15 | This      |
    |          |             |                           | document  |
    +----------+-------------+---------------------------+-----------+

Table 1: BGP-LS MSD TLV Code Points

表1：BGP-LS MSD TLVコードポイント

6. Manageability Considerations

6. 管理性の考慮事項

The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via [RFC7752]. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in Section 6 (Manageability Considerations) of [RFC7752]. Specifically, the malformed attribute tests for syntactic checks in Section 6.2.2 (Fault Management) of [RFC7752] now encompass the new BGP-LS Attribute TLVs defined in this document. The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS Network Layer Reachability Information (NLRI) types or their BGP-LS Attribute is left to the consumer of the BGP-LS information (e.g., an application or a controller) and not the BGP protocol.

この文書で導入された新しいプロトコル拡張機能は、[RFC7752]で配布されている既存のIGPトポロジ情報を拡張します。この文書で定義されている手順とプロトコル拡張機能は、[RFC7752]のセクション6（管理容易性考慮事項）で説明したように、BGPプロトコルの操作と管理には影響しません。具体的には、[RFC7752]のセクション6.2.2（障害管理）の構文チェックの不正な形式の属性テストがこのドキュメントで定義されている新しいBGP-LS属性TLVを網羅しています。この文書で指定されたTLVの意味論的またはコンテンツのチェック、およびBGP-LSネットワーク層到達可能性情報（NLRI）型またはそれらのBGP-LS属性との関連付けは、BGP-LS情報の消費者に残されています（例：アプリケーションなど）。BGPプロトコルではなくコントローラ）でもコントローラ。

A consumer of the BGP-LS information retrieves this information over a BGP-LS session (refer to Sections 1 and 2 of [RFC7752]).

BGP-LS情報の消費者は、BGP-LSセッションを介してこの情報を取得します（[RFC7752]のセクション1,2参照）。

This document only introduces new Attribute TLVs, and any syntactic error in them would result in the BGP-LS Attribute being discarded [RFC7752]. The MSD information introduced in BGP-LS by this specification, may be used by BGP-LS consumer applications like an SR PCE to learn the SR SID stack handling capabilities of the nodes in the topology. This can enable the SR PCE to perform path computations taking into consideration the size of SID stack that the specific head-end node may be able to impose. Errors in the encoding or decoding of the MSD information may result in the unavailability of such information to the SR PCE, or incorrect information being made available to it. This may result in the head-end node not being able to instantiate the desired SR path in its forwarding and provide the SR-based optimization functionality. The handling of such errors by applications like SR PCE may be implementation specific and out of scope of this document.

この文書では新しい属性TLVSのみを導入し、それらの構文エラーはBGP-LS属性が破棄されていることがあります[RFC7752]。本明細書によってBGP - LSで導入されたMSD情報は、トポロジ内のノードのSR SIDスタック処理機能を学習するためのSR PCEのようなBGP - LSコンシューマアプリケーションによって使用され得る。これにより、SR PCEは、特定のヘッドエンドノードが課すことができるSIDスタックのサイズを考慮してパス計算を実行できるようにすることができる。MSD情報の符号化または復号化におけるエラーは、SR PCEへのそのような情報の利用不可能性、またはそれに誤った情報を利用可能にすることができる。これにより、ヘッドエンドノードが転送で希望のSRパスをインスタンス化できず、SRベースの最適化機能を提供する可能性があります。SR PCEのようなアプリケーションによるそのようなエラーの処理は、この文書の実装で範囲外である可能性があります。

The extensions specified in this document do not specify any new configuration or monitoring aspects in BGP or BGP-LS. The specification of BGP models is an ongoing work based on the [BGP-MODEL].

このドキュメントで指定されている拡張機能は、BGPまたはBGP-LSの新しい構成または監視面を指定しません。BGPモデルの仕様は[BGP-MODEL]に基づく進行中の作業です。

7. Security Considerations

7. セキュリティに関する考慮事項

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. The presence of this information may also inform an attacker of how to induce any of the aforementioned conditions.

誤ったMSD値の広告は悪影響を及ぼし得る。値がサポートよりも小さい場合、パス計算は実行可能なパスを計算できない場合があります。値がサポートされているより大きい場合、ヘッドエンドでサポートできないパス（SIDの面付けを実行するノード）が発生する可能性がある場合があります。この情報の存在はまた、前述の条件のいずれかをどのように誘導するかの攻撃者に知らせることができる。

The procedures and protocol extensions defined in this document do not affect the BGP security model. See the "Security Considerations" Section of [RFC4271] for a discussion of BGP security. Also, refer to [RFC4272] and [RFC6952] for analyses of security issues for BGP. Security considerations for acquiring and distributing BGP-LS information are discussed in [RFC7752]. The TLVs introduced in this document are used to propagate the MSD IGP extensions defined in [RFC8476] and [RFC8491]. It is assumed that the IGP instances originating these TLVs will support all the required security (as described in [RFC8476] and [RFC8491]) in order to prevent any security issues when propagating the TLVs into BGP-LS. The advertisement of the node and link attribute information defined in this document presents no significant additional risk beyond that associated with the existing node and link attribute information already supported in [RFC7752].

この文書で定義されている手順とプロトコル拡張機能はBGPセキュリティモデルには影響しません。BGPセキュリティの説明については、[RFC4271]の「セキュリティ上の考慮事項」を参照してください。また、BGPのセキュリティ問題の分析については、[RFC4272]と[RFC6952]を参照してください。BGP-LS情報を取得および配布するためのセキュリティ上の考慮事項は[RFC7752]で説明されています。この文書で導入されたTLVは、[RFC8476]と[RFC8491]で定義されているMSD IGP拡張機能を伝播するために使用されます。これらのTLVを発信するIGPインスタンスは、TLVをBGP-LSに伝播するときのセキュリティの問題を防ぐために、必要なすべてのセキュリティ（[RFC8476]および[RFC8491]）をサポートすると仮定されます。この文書で定義されているノードおよびリンク属性情報の広告は、[RFC7752]で既存のノードおよびリンク属性情報に関連付けられているものを超えて重要な追加のリスクを示唆していない。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[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.、およびS. Ray、「BGPを使用したリンク状態およびトラフィックエンジニアリングの北部分布」、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https：//www.rfc-editor.org/info/rfc7752>。

[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>。

[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, <https://www.rfc-editor.org/info/rfc8476>.

[RFC8476] Tantura、J.、Chunduri、U.、Aldrin、S.、およびP. Psenak、「OSPFを使用する最大SID深度（MSD）、RFC 8476、DOI 10.17487 / RFC8476、2018年12月、<https：//www.rfc-editor.org/info/rfc8476>。

[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>。

8.2. Informative References

8.2. 参考引用

[BGP-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-09, 28 June 2020, <https://tools.ietf.org/html/draft-ietf-idr-bgp-model-09>.

[BGP-MODEL] Jethanandani、M.、Patel、K.、HAAS、S、およびJ.HAAS、「サービスプロバイダネットワークのためのBGP Yangモデル」、進行中の作業、インターネットドラフト、ドラフトIETF-IDR-BGP-model-09,2020 2020年6月28日、<https：//tools.ietf.org/html/draft-ietf-idr-bgp-model-09>。

[ISIS-ELC] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., and M. Bocci, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS", Work in Progress, Internet-Draft, draft-ietf-isis-mpls-elc-13, 28 May 2020, <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-13>.

[ISIS-ELC] XU、X.、Kini、S.、Psenak、P.、Filsfils、C.、Litkowski、S.、およびM. Bocci、「シグナリングエントロピーラベル能力とエントロピー読み取り可能なラベル深度」、進行中の作業、インターネットドラフト、ドラフトIETF-ISIS-MPLS-ELC-13,2020、<https：//tools.ietf.org/html/draft-ietf-isis-mpls-elc-13>。

[OSPF-ELC] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., and M. Bocci, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF", Work in Progress, Internet-Draft, draft-ietf-ospf-mpls-elc-15, 1 June 2020, <https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15>.

[OSPF-ELC] XU、X.、Kini、S.、Psenak、P.、Filsfils、C.、Litkowski、S.、およびM. Bocci、「Signaling Entropy Label CapabilityとEntropyの読み取り可能なラベル深さ」、仕事進行中、インターネットドラフト、ドラフト - IETF-OSPF-MPLS-ELC-15,16月1日、<https：//tools.ietf.org/html/draft-ietf-oppf-mpls-elc-15>。

[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]ローゼン、E.、Viswanathan、A.およびR.Callon、 "Multiprotocol Label Switche Architecture"、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https：//www.rfc-editor.org/info/ RFC3031>。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.

[RFC4272] Murphy、S.、「BGPセキュリティ脆弱性分析」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<https：//www.rfc-editor.org/info/rfc4272>。

[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>.

[RFC6952] Jethanandani、M.、Patel、K。、およびL.Zheng、「ルーティングプロトコル（KARP）設計ガイド」、RFC 6952、DOIのためのキーイング・認証によるBGP、LDP、PCE、およびMSDP問題の分析10.17487 / RFC6952、2013年5月、<https：//www.rfc-editor.org/info/rfc6952>。

[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、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/ RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。

[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.

[RFC8664] Sivabalan、S、Filsfils、C、Tantura、J.、HenderickX、W.、およびJ.Hormwick、セグメントルーティングのためのPATH計算要素通信プロトコル（PCE）拡張（PCE）、RFC 8664、DOI 10.17487 / RFC86642019年12月、<https：//www.rfc-editor.org/info/rfc8664>。

Acknowledgements

謝辞

We would like to thank Acee Lindem, Stephane Litkowski, Bruno Decraene, and Alvaro Retana for their reviews and valuable comments.

Adee Lindem、Stephane Litkowski、Bruno Decraene、Alvaro Retana、レビューや貴重なコメントに感謝します。

Contributors

貢献者

Siva Sivabalan Cisco Systems Inc. Canada

Siva Sivabalan Cisco Systems Inc. Canada.

   Email: msiva@cisco.com

Authors' Addresses

著者の住所

Jeff Tantsura Apstra, Inc.

Jeff Tantsura Apstra、Inc。

   Email: jefftant.ietf@gmail.com

Uma Chunduri Futurewei Technologies

Uma Chunduri FuttureWei Technologies

   Email: umac.ietf@gmail.com

Ketan Talaulikar Cisco Systems

Ketan Talaulikar Cisco Systems.

   Email: ketant@cisco.com

Greg Mirsky ZTE Corp.

Greg Mirsky Zte Corp.

   Email: gregimirsky@gmail.com

Nikos Triantafillis Amazon Web Services

Nikos Triantafillis Amazon Webサービス

   Email: nikost@amazon.com