RFC 9294 - Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol

RFC 9294 - Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9294.html
タイトル : RFC 9294 - 境界ゲートウェイプロトコルを使用したアプリケーション固有のリンク属性広告 - リンク状態（BGP-LS）
翻訳編集 : 自動生成

[要約] RFC 9294 は、既存および新しいアプリケーション（例：Segment Routing）向けのアプリケーション固有のリンク属性を配布するためのリンク状態ルーティングプロトコルの拡張を定義しています。BGP-LSの拡張を定義し、ネットワークからのトポロジ情報の一部としてこれらのアプリケーション固有の属性を広告することを可能にします。

Internet Engineering Task Force (IETF)                K. Talaulikar, Ed.
Request for Comments: 9294                                   Arrcus Inc.
Category: Standards Track                                      P. Psenak
ISSN: 2070-1721                                            Cisco Systems
                                                             J. Tantsura
                                                               Microsoft
                                                             August 2022

Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)

境界ゲートウェイプロトコルを使用したアプリケーション固有のリンク属性広告 - リンク状態（BGP-LS）

Abstract

概要

Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR). This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) to enable the advertisement of these application-specific attributes as a part of the topology information from the network.

拡張機能は、セグメントルーティング（SR）などの既存および新しいアプリケーションのアプリケーション固有のリンク属性の分布を可能にするリンク状態ルーティングプロトコルに対して定義されています。このドキュメントでは、ネットワークからのトポロジ情報の一部としてこれらのアプリケーション固有の属性の広告を有効にするために、境界ゲートウェイプロトコル - リンク状態（BGP-LS）への拡張機能を定義します。

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/rfc9294.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9294で取得できます。

著作権表示

著作権（c）2022 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Application-Specific Link Attributes TLV
   3.  Application-Specific Link Attributes
   4.  Procedures
     4.1.  Illustration for IS-IS
   5.  Deployment Considerations
   6.  IANA Considerations
   7.  Manageability Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

The Border Gateway Protocol - Link State (BGP-LS) [RFC7752] enables the distribution of the link-state topology information from link-state routing protocols (viz., IS-IS [RFC1195], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) to an application like a controller or Path Computation Engine (PCE) via BGP. The controller or PCE gets the end-to-end topology information across IGP domains so it can perform path computations for use cases like end-to-end traffic engineering (TE).

境界ゲートウェイプロトコル - リンク状態（BGP-LS）[RFC7752]は、リンク状態のルーティングプロトコルからのリンク状態トポロジー情報の分布を可能にします（Viz。、IS-IS [RFC1195]、OSPFV2 [RFC2328]、およびOSOSPFV3 [OSPFV3 [RFC5340]）BGP経由のコントローラーまたはパス計算エンジン（PCE）などのアプリケーションへ。コントローラーまたはPCEは、IGPドメイン全体でエンドツーエンドトポロジー情報を取得して、エンドツーエンドトラフィックエンジニアリング（TE）などのユースケースのパス計算を実行できます。

The link-state topology information distributed via BGP-LS includes link attributes that were originally defined for MPLS TE (i.e., using RSVP-TE [RFC3209] or GMPLS [RFC4202] applications). In recent years, applications, such as Segment Routing (SR) Policy [RFC8402] and Loop-Free Alternates (LFA) [RFC5286], which also make use of link attributes, have been introduced. [RFC8919] and [RFC8920] define extensions for IS-IS and OSPF, respectively, that enable advertising application-specific link attributes for these and other future applications. This has resulted in the need for a similar BGP-LS extension to include this additional link-state topology information from the link-state routing protocols.

BGP-LSを介して配布されるリンク状態トポロジ情報には、元々MPLS TEに対して定義されていたリンク属性（つまり、RSVP-TE [RFC3209]またはGMPLS [RFC4202]アプリケーションを使用しています）が含まれています。近年、セグメントルーティング（SR）ポリシー[RFC8402]やループフリーの代替（LFA）[RFC5286]などのアプリケーションは、リンク属性を使用して導入されています。[RFC8919]および[RFC8920]は、IS-ISとOSPFの拡張機能をそれぞれ定義し、これらおよびその他の将来のアプリケーションの広告アプリケーション固有のリンク属性を可能にします。これにより、同様のBGP-LS拡張が、リンク状態のルーティングプロトコルからのこの追加のリンク状態トポロジ情報を含める必要がありました。

This document defines the BGP-LS extensions for the advertisement of application-specific link attributes. It describes the advertisement of these link attributes as top-level TLVs (i.e., as TLVs of the BGP-LS Attribute) and as sub-TLVs of the (top-level) Application-Specific Link Attributes (ASLA) TLV. The document also describes the procedures for the advertisement of these attributes from the underlying IGPs and discusses their deployment aspects.

このドキュメントでは、アプリケーション固有のリンク属性の広告のBGP-LS拡張機能を定義します。これらのリンク属性の広告は、トップレベルのTLV（つまり、BGP-LS属性のTLV）および（トップレベル）アプリケーション固有のリンク属性（ASLA）TLVのサブTLVとして説明します。ドキュメントでは、基礎となるIGPSからのこれらの属性の広告の手順についても説明し、展開の側面について説明します。

1.1. Requirements Language

1.1. 要件言語

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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

2. Application-Specific Link Attributes TLV

2. アプリケーション固有のリンク属性TLV

BGP-LS [RFC7752] specifies the Link Network Layer Reachability Information (NLRI) for the advertisement of links and their attributes using the BGP-LS Attribute. The ASLA TLV is an optional top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It is defined such that it may act as a container for certain existing and future link attributes that require application-specific definition.

BGP-LS [RFC7752]は、BGP-LS属性を使用して、リンクの広告とその属性のリンクネットワークレイヤーリーチビリティ情報（NLRI）を指定します。ASLA TLVは、Link NLRIS用に導入されるオプションのトップレベルBGP-LS属性TLVです。アプリケーション固有の定義を必要とする特定の既存および将来のリンク属性のコンテナとして機能するように定義されています。

The format of this TLV is as follows and is similar to the corresponding ASLA sub-TLVs defined for OSPF and IS-IS in [RFC8920] and [RFC8919], respectively.

このTLVの形式は次のとおりであり、[RFC8920]および[RFC8919]でそれぞれOSPFおよびIS-ISで定義された対応するASLAサブTLVに類似しています。

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | SABM Length   | UDABM Length  |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Standard Application Identifier Bit Mask (variable)      //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    User-Defined Application Identifier Bit Mask (variable)   //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Link Attribute sub-TLVs                 //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Application-Specific Link Attributes TLV

図1：アプリケーション固有のリンク属性TLV

where:

ただし：

Type: 1122

タイプ：1122

Length: variable

長さ：変数

SABM Length: 1-octet field that carries the Standard Application Identifier Bit Mask Length in octets as defined in [RFC8920].

SABMの長さ：[RFC8920]で定義されているように、オクテットの標準アプリケーション識別子ビットマスク長を搭載する1-OCTETフィールド。

UDABM Length: 1-octet field that carries the User-Defined Application Identifier Bit Mask Length in octets as defined in [RFC8920].

UDABMの長さ：[RFC8920]で定義されているように、ユーザー定義のアプリケーション識別子識別子ビットマスク長さをオクテットに搭載する1-OCTETフィールド。

Reserved: 2-octet field that MUST be set to zero on transmission and MUST be ignored on reception.

予約済み：トランスミッションでゼロに設定する必要があり、レセプションでは無視する必要があります。

Standard Application Identifier Bit Mask: An optional set of bits (of size 0, 4, or 8 octets as indicated by the SABM Length), where each bit represents a single standard application as defined in [RFC8919].

標準アプリケーション識別子ビットマスク：各ビットは[RFC8919]で定義されている単一の標準アプリケーションを表します。

User-Defined Application Identifier Bit Mask: An optional set of bits (of size 0, 4, or 8 octets as indicated by the UDABM Length), where each bit represents a single user-defined application as defined in [RFC8919] and [RFC8920].

ユーザー定義アプリケーション識別子ビットマスク：オプションのビットセット（サイズ0、4、または8オクテットのUDABM長で示されている）。各ビットは[RFC8919]および[RFC8920で定義されている単一のユーザー定義アプリケーションを表します。]。

Link Attribute sub-TLVs: BGP-LS Attribute TLVs corresponding to the Link NLRI that are application-specific (including existing ones as specified in Section 3) are included as sub-TLVs of the ASLA TLV.

リンク属性サブTLV：アプリケーション固有のリンクNLRI（セクション3で指定された既存のものを含む）に対応するBGP-LS属性TLVは、ASLA TLVのサブTLVとして含まれています。

The semantics associated with the standard and user-defined bit masks as well as the encoding scheme for application-specific attributes are as specified in [RFC8920].

標準およびユーザー定義のビットマスクに関連するセマンティクスと、アプリケーション固有の属性のエンコードスキームは、[RFC8920]で指定されているとおりです。

The ASLA TLV and its sub-TLVs can only be added to the BGP-LS Attribute associated with the Link NLRI of the node that originates the underlying IGP link attribute TLVs and sub-TLVs. The procedures for originating link attributes in the ASLA TLV from underlying IGPs are specified in Section 4.

ASLA TLVとそのサブTLVは、基礎となるIGPリンク属性TLVおよびSub-TLVを発信するノードのリンクNLRIに関連付けられたBGP-LS属性にのみ追加できます。基礎となるIGPのASLA TLVのリンク属性を発信する手順は、セクション4で指定されています。

3. Application-Specific Link Attributes

3. アプリケーション固有のリンク属性

Several BGP-LS Attribute TLVs corresponding to the Link NLRI are defined in BGP-LS [RFC7752], and more may be added in the future. Those attributes that have been determined to be, and advertised as, application-specific in the underlying IGPs are also encoded similarly in BGP-LS.

NLRIに対応するいくつかのBGP-LS属性TLVは、BGP-LS [RFC7752]で定義されており、将来さらに追加される可能性があります。基礎となるIGPのアプリケーション固有であると判断され、宣伝されているこれらの属性も、BGP-LSで同様にエンコードされます。

The following table lists the currently defined BGP-LS Attribute TLVs corresponding to Link NLRI that can have application-specific semantics based on the underlying IGP specifications [RFC8919] [RFC8920]. These were originally defined with semantics for RSVP-TE and GMPLS applications in BGP-LS by the respective reference documents.

次の表には、基礎となるIGP仕様[RFC8919] [RFC8920]に基づいてアプリケーション固有のセマンティクスを持つことができるリンクNLRIに対応する現在定義されているBGP-LS属性TLVを示します。これらはもともと、それぞれの参照文書によってBGP-LSのRSVP-TEおよびGMPLSアプリケーションのセマンティクスで定義されていました。

     +================+========================+====================+
     | TLV Code Point | Description            | Reference Document |
     +================+========================+====================+
     |      1088      | Administrative group   | [RFC7752]          |
     |                | (color)                |                    |
     +----------------+------------------------+--------------------+
     |      1092      | TE Default Metric      | [RFC7752]          |
     +----------------+------------------------+--------------------+
     |      1096      | Shared Risk Link Group | [RFC7752]          |
     +----------------+------------------------+--------------------+
     |      1114      | Unidirectional Link    | [RFC8571]          |
     |                | Delay                  |                    |
     +----------------+------------------------+--------------------+
     |      1115      | Min/Max Unidirectional | [RFC8571]          |
     |                | Link Delay             |                    |
     +----------------+------------------------+--------------------+
     |      1116      | Unidirectional Delay   | [RFC8571]          |
     |                | Variation              |                    |
     +----------------+------------------------+--------------------+
     |      1117      | Unidirectional Link    | [RFC8571]          |
     |                | Loss                   |                    |
     +----------------+------------------------+--------------------+
     |      1118      | Unidirectional         | [RFC8571]          |
     |                | Residual Bandwidth     |                    |
     +----------------+------------------------+--------------------+
     |      1119      | Unidirectional         | [RFC8571]          |
     |                | Available Bandwidth    |                    |
     +----------------+------------------------+--------------------+
     |      1120      | Unidirectional         | [RFC8571]          |
     |                | Utilized Bandwidth     |                    |
     +----------------+------------------------+--------------------+
     |      1173      | Extended               | [RFC9104]          |
     |                | Administrative Group   |                    |
     +----------------+------------------------+--------------------+

Table 1: Existing BGP-LS TLVs Identified as Application-Specific

表1：アプリケーション固有として識別される既存のBGP-LS TLV

All the BGP-LS Attribute TLVs listed in the table above are REQUIRED to be advertised as a top-level TLV in the BGP-LS Attribute when used to carry link attributes specific to RSVP-TE.

上記の表にリストされているすべてのBGP-LS属性TLVは、RSVP-TEに固有のリンク属性を運ぶために使用する場合、BGP-LS属性のトップレベルTLVとして宣伝する必要があります。

BGP-LS Attribute TLVs corresponding to Link NLRI that are advertised in the underlying IGP as application-specific are REQUIRED to be encoded within an ASLA TLV.

基礎となるIGPで宣伝されているリンクNLRIに対応するBGP-LS属性TLVSは、ASLA TLV内でエンコードする必要があります。

Link attributes that do not have application-specific semantics MUST NOT be advertised within the ASLA TLV.

アプリケーション固有のセマンティクスを持たないリンク属性は、ASLA TLV内で宣伝してはなりません。

When the same application-specific link attributes are advertised both within the ASLA TLV and as top-level TLVs in the BGP-LS Attribute, the attributes advertised within the ASLA TLV take precedence for the applications indicated in the ASLA TLV encoding.

ASLA TLV内およびBGP-LS属性のトップレベルTLVとして同じアプリケーション固有のリンク属性が宣伝されている場合、ASLA TLV内で宣伝されている属性がASLA TLVエンコーディングで示されるアプリケーションで優先されます。

4. Procedures

4. 手順

The BGP-LS originator learns of the association of an application-specific attribute to one or more applications from the underlying IGP protocol Link State Advertisements (LSAs) or Link State Packets (LSPs) from which it is advertising the topology information. [RFC8920] and [RFC8919] specify the mechanisms for advertising application-specific link attributes in OSPF and IS-IS, respectively.

BGP-LSオリジネーターは、トポロジ情報を宣伝している基礎となるIGPプロトコルリンク状態広告（LSA）またはリンク状態パケット（LSP）からの1つ以上のアプリケーションとのアプリケーション固有の属性との関連性を学びます。[RFC8920]および[RFC8919]は、それぞれOSPFおよびIS-ISでアプリケーション固有のリンク属性を広告するメカニズムを指定します。

Application-specific link attributes received from an IGP node without the use of ASLA encodings continue to be encoded using the respective BGP-LS top-level TLVs listed in Table 1 as specified in their respective reference documents.

ASLAエンコーディングを使用せずにIGPノードから受信したアプリケーション固有のリンク属性は、それぞれの参照ドキュメントで指定されているように、表1にリストされているそれぞれのBGP-LSトップレベルTLVを使用して引き続きエンコードされています。

While the ASLA encoding in OSPF is similar to that of BGP-LS, the encoding in IS-IS differs and requires additional procedures when conveying information into BGP-LS. One of these differences arises from the presence of the L-flag in the IS-IS encoding. Another difference arises due to the requirement to collate information from two types of IS-IS encodings for application-specific link information (i.e., the IS-IS ASLA sub-TLV and the IS-IS Application-Specific Shared Risk Link Group (SRLG) TLV) [RFC8919] and to carry them together in the BGP-LS ASLA TLV.

OSPFでのASLAエンコードはBGP-LSのASLAエンコードと類似していますが、IS-ISでのエンコードは異なり、BGP-LSに情報を伝える際に追加の手順が必要です。これらの違いの1つは、ISエンコードにL-Flagが存在することから生じます。アプリケーション固有のリンク情報（つまり、IS-IS ASLA SUB-TLVおよびIS-ISアプリケーション固有の共有リスクリンクグループ（SRLG）の2種類のISエンコーディングから情報を照合するための要件があるため、別の違いが生じます。TLV）[RFC8919]およびBGP-LS ASLA TLVでそれらを一緒に運ぶ。

A BGP-LS originator node that is advertising link-state information from the underlying IGP using ASLA encodings determines their BGP-LS encoding based on the following rules:

ASLAエンコーディングを使用して基礎となるIGPからの広告リンク状態情報であるBGP-LSオリジネーターノードは、次のルールに基づいてBGP-LSエンコードを決定します。

1. Application-specific link attributes received from an OSPF node using an ASLA sub-TLV or from an IS-IS node using either an ASLA sub-TLV or an Application-Specific SRLG TLV MUST be encoded in the BGP-LS ASLA TLV as sub-TLVs. Exceptions to this rule are specified in (2)(F) and (2)(G) below.

1. ASLA Sub-TLVを使用してOSPFノードから受信したアプリケーション固有のリンク属性またはASLA Sub-TLVまたはアプリケーション固有のSRLG TLVを使用したIS-ISノードから、BGP-LS ASLA TLVでサブサブとしてエンコードする必要があります。TLVS。この規則の例外は、以下の（2）（f）および（2）（g）で指定されています。

2. In the case of IS-IS, the specific procedures below are to be followed:

2. IS-ISの場合、以下の特定の手順に従う必要があります。

A. When application-specific link attributes are received from a node with the L-flag set in the IS-IS ASLA sub-TLV and when application bits (other than RSVP-TE) are set in the application bit masks, then the application-specific link attributes advertised in the corresponding legacy IS-IS TLVs and sub-TLVs MUST be encoded within the BGP-LS ASLA TLV as sub-TLVs with the application bits (other than the RSVP-TE bit) copied from the IS-IS ASLA sub-TLV. The link attributes advertised in the legacy IS-IS TLVs and sub-TLVs are also advertised in BGP-LS top-level TLVs as per [RFC7752], [RFC8571], and [RFC9104]. The same procedure also applies for the advertisement of the SRLG values from the IS-IS Application-Specific SRLG TLV.

A. IS-IS ASLA Sub-TLVに設定されたL-FLAGセットを備えたアプリケーション固有のリンク属性がノードから受信され、アプリケーションビット（RSVP-TEを除く）がアプリケーションビットマスクに設定されている場合、アプリケーションはアプリケーションに設定されている場合対応するレガシーIS-IS TLVおよびSUB-TLVで宣伝されている - 固有のリンク属性は、IS-ISからコピーされたアプリケーションビット（RSVP-TEビット以外）を使用して、SUB-TLVとしてBGP-LS ASLA TLV内でエンコードする必要があります。ASLAサブTLV。レガシーIS-IS TLVとサブTLVで宣伝されているリンク属性は、[RFC7752]、[RFC8571]、および[RFC9104]に従って、BGP-LSトップレベルTLVで宣伝されています。同じ手順は、IS-ISアプリケーション固有のSRLG TLVからのSRLG値の広告にも適用されます。

B. When the IS-IS ASLA sub-TLV has the RSVP-TE application bit set, then the link attributes for the corresponding IS-IS ASLA sub-TLVs MUST be encoded using the respective BGP-LS top-level TLVs as per [RFC7752], [RFC8571], and [RFC9104]. Similarly, when the IS-IS Application-Specific SRLG TLV has the RSVP-TE application bit set, then the SRLG values within it MUST be encoded using the top-level BGP-LS SRLG TLV (1096) as per [RFC7752].

B. IS-IS ASLA Sub-TLVにRSVP-TEアプリケーションビットが設定されている場合、対応するIS-IS ASLAサブTLVのリンク属性は、それぞれのBGP-LSトップレベルTLVを使用してエンコードする必要があります[RFC7752]、[RFC8571]、および[RFC9104]。同様に、IS-ISアプリケーション固有のSRLG TLVにRSVP-TEアプリケーションビットが設定されている場合、[RFC7752]に従って、トップレベルBGP-LS SRLG TLV（1096）を使用してSRLG値をエンコードする必要があります。

C. The SRLGs advertised in one or more IS-IS Application-Specific SRLG TLVs and the other link attributes advertised in one or more IS-IS ASLA sub-TLVs are REQUIRED to be collated, on a per-application basis, only for those applications that meet all the following criteria:

C. 1つ以上のIS-ISアプリケーション固有のSRLG TLVで宣伝されているSRLGSおよび1つまたは複数のIS-IS ASLAサブTLVで宣伝されている他のリンク属性は、適用ごとに照合する必要があります。次のすべての基準を満たすアプリケーション：

* their bit is set in the SABM or UDABM in one of the two types of IS-IS encodings (e.g., IS-IS ASLA sub-TLV)

* 彼らのビットは、2種類のISエンコーディングのいずれかでSABMまたはUDABMに設定されています（例：IS ASLA Sub-TLV）

* the other encoding type (e.g., IS-IS Application Specific SRLG TLV) has an advertisement with zero-length application bit masks

* もう1つのエンコードタイプ（例：IS-ISアプリケーション固有のSRLG TLV）には、ゼロレングスのアプリケーションビットマスクを備えた広告があります

* there is no corresponding advertisement of that other encoding type (following the example, IS-IS Application Specific SRLG TLV) with that specific application bit set

* その特定のアプリケーションビットセットを使用して、その他のエンコードタイプ（例に従って、IS-ISアプリケーション固有のSRLG TLV）の対応する広告はありません

For each such application, its collated information MUST be carried in a BGP-LS ASLA TLV with that application's bit set in the SABM or UDABM. See the illustration in Section 4.1.

このようなアプリケーションごとに、照合された情報は、SABMまたはUDABMに設定されたそのアプリケーションのビットを使用して、BGP-LS ASLA TLVで運ばなければなりません。セクション4.1の図を参照してください。

D. If the resulting set of collated link attributes and SRLG values is common across multiple applications, they MAY be advertised in a common BGP-LS ASLA TLV instance where the bits for all such applications would be set in the application bit mask.

D.結果の照合リンク属性とSRLG値のセットが複数のアプリケーションで一般的である場合、そのようなすべてのアプリケーションのビットがアプリケーションビットマスクに設定される一般的なBGP-LS ASLA TLVインスタンスで宣伝される場合があります。

E. Both the SRLG values from IS-IS Application-Specific SRLG TLVs and the link attributes from IS-IS ASLA sub-TLVs, with the zero-length application bit mask, MUST be advertised into a BGP-LS ASLA TLV with a zero-length application bit mask, independent of the collation described above.

E. IS-ISアプリケーション固有のSRLG TLVからのSRLG値とIS-IS ASLAサブTLVからのリンク属性の両方が、ゼロレングスアプリケーションビットマスクを使用して、ゼロを備えたBGP-LS ASLA TLVに宣伝する必要があります。 - 上記の照合とは無関係に、長さのアプリケーションビットマスク。

F. [RFC8919] allows the advertisement of the Maximum Link Bandwidth within an IS-IS ASLA sub-TLV even though it is not an application-specific attribute. However, when originating the Maximum Link Bandwidth into BGP-LS, the attribute MUST be encoded only in the top-level BGP-LS Maximum Link Bandwidth TLV (1089) and MUST NOT be advertised within the BGP-LS ASLA TLV.

F. [RFC8919]は、アプリケーション固有の属性ではない場合でも、IS-IS ASLAサブTLV内の最大リンク帯域幅の広告を許可します。ただし、最大リンク帯域幅をBGP-LSに発信する場合、属性はトップレベルのBGP-LS最大リンク帯域幅TLV（1089）でのみエンコードする必要があり、BGP-LS ASLA TLV内で宣伝してはなりません。

G. [RFC8919] also allows the advertisement of the Maximum Reservable Link Bandwidth and the Unreserved Bandwidth within an IS-IS ASLA sub-TLV even though these attributes are specific to RSVP-TE application. However, when originating the Maximum Reservable Link Bandwidth and Unreserved Bandwidth into BGP-LS, these attributes MUST be encoded only in the BGP-LS top-level Maximum Reservable Link Bandwidth TLV (1090) and Unreserved Bandwidth TLV (1091), respectively, and not within the BGP-LS ASLA TLV.

G. [RFC8919]は、これらの属性がRSVP-TEアプリケーションに固有のものであるにもかかわらず、IS-IS ASLAサブTLV内の最大予約可能リンク帯域幅と予約されていない帯域幅の広告も許可します。ただし、最大予約可能なリンク帯域幅と予約されていない帯域幅をBGP-LSに発信する場合、これらの属性は、BGP-LSのトップレベルの最大リンク帯域幅TLV（1090）およびそれぞれ予約されていない帯域幅TLV（1091）でのみエンコードする必要があります。BGP-LS ASLA TLV内ではありません。

These rules ensure that a BGP-LS originator performs the advertisement for all application-specific link attributes from the IGP nodes that support the ASLA extension. Furthermore, it also ensures that the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS applications continue to be used for advertisement of their application-specific attributes.

これらのルールにより、BGP-LSオリジネーターがASLA拡張機能をサポートするIGPノードからのすべてのアプリケーション固有のリンク属性の広告を実行することが保証されます。さらに、RSVP-TEおよびGMPLSアプリケーションで定義されたトップレベルのBGP-LS TLVが、アプリケーション固有の属性の広告に引き続き使用されることを保証します。

A BGP-LS speaker would normally advertise all the application-specific link attributes corresponding to RSVP-TE and GMPLS applications as existing top-level BGP-LS TLVs while for other applications they are encoded in the ASLA TLV(s) with appropriate applicable bit mask setting. An application-specific attribute value received via a sub-TLV within the ASLA TLV has precedence over the value received via a top-level TLV.

BGP-LSスピーカーは通常、RSVP-TEおよびGMPLSアプリケーションに対応するすべてのアプリケーション固有のリンク属性を既存のトップレベルBGP-LS TLVとして宣伝し、適切なビットを備えたASLA TLVでエンコードされている他のアプリケーションではマスク設定。ASLA TLV内のSub-TLVを介して受信したアプリケーション固有の属性値は、トップレベルのTLVを介して受信した値よりも優先されます。

4.1. Illustration for IS-IS

4.1. IS-ISのイラスト

This section illustrates the procedure for the advertisement of application-specific link attributes from IS-IS into BGP-LS.

このセクションでは、IS-ISからBGP-LSへのアプリケーション固有のリンク属性の広告の手順を示します。

Consider the following advertisements for a link in IS-IS. We start with this set:

IS-ISのリンクの次の広告を検討してください。このセットから始めます：

a. IS-IS ASLA sub-TLV with the S, F, and X bits set on it that carries certain application-specific link attributes

a. S、F、およびXビットが設定されたIS-IS ASLA SUB-TLVは、特定のアプリケーション固有のリンク属性を搭載しています

b. IS-IS Application-Specific SRLG TLV with zero-length bit masks with a set of application-specific SRLGs

b. IS-ISアプリケーション固有のSRLG TLVは、アプリケーション固有のSRLGSのセットを備えたゼロレングスビットマスクを備えています

c. IS-IS Application-Specific SRLG TLV with the X bit set on it with a set of application-specific SRLGs

c. IS-ISアプリケーション固有のSRLG TLVを使用して、アプリケーション固有のSRLGSのセットでXビットを設定します

The corresponding BGP-LS advertisements for that link are determined as follows:

そのリンクの対応するBGP-LS広告は、次のように決定されます。

First, based on rule (1), the advertisements are conveyed to BGP-LS to get the following "updated set":

まず、ルール（1）に基づいて、広告はBGP-LSに伝えられ、次の「更新セット」を取得します。

1. ASLA with the S, F, and X bits set on it that carries link attributes from IS-IS advertisement (a)

1. S、F、およびXビットが設定されたASLAは、IS-IS広告（a）からのリンク属性を搭載しています。

2. ASLA SRLG with zero-length bit masks with a set of SRLGs from IS-IS advertisement (b)

2. ゼロ長さのビットマスクを備えたASLA SRLG IS ADVERTISEMENT（b）のSRLGSのセット

3. ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS advertisement (c)

3. xビットを備えたasla srlgは、is-is広告（c）のsrlgsのセットで設定されています

Next, we apply the rules from (2) to this "updated set", because all of them were sourced from IS-IS, to derive a new set.

次に、（2）からこの「更新されたセット」にルールを適用します。なぜなら、それらはすべてIS-ISから供給され、新しいセットを導き出すためです。

The next rule that applies is (2)(c), and it is determined that collation is required for applications S and F; therefore, we get the following "final set":

適用される次のルールは（2）（c）であり、アプリケーションsおよびfに照合が必要であると判断されます。したがって、次の「最終セット」を取得します。

1. ASLA with the S bit set on it that carries link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is collation for application S based on (2)(c))

1. ASLAは、IS-IS Advertisement（a）からのリンク属性とIS-IS広告（b）からのsrlgsを運ぶsビットを備えたASLA（これは（2）（c）に基づくアプリケーションSの照合です）

2. ASLA with the F bit set on it that carries link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is collation for application F based on (2)(c))

2. ASLAは、IS-IS広告（a）からのリンク属性とIS-IS広告（b）からのsrlgsを搭載したasla（これは（2）（c）に基づくアプリケーションFの照合です）

3. ASLA with the X bit set on it that carries link attributes from IS-IS advertisement (a) (remaining application not affected by collation based on (2)(c))

3. ASLAは、IS-IS Advertisement（a）からのリンク属性を運ぶxビットを設定しています（（2）（c）に基づいて照合によって影響を受けない残りのアプリケーション）

4. ASLA with zero-length bit masks with SRLGs from IS-IS advertisement (b) (not affected by (2)(c) and therefore carried forward unchanged from the "updated set")

4. IS-IS広告（b）からのsrlgsを使用したゼロ長ビットマスクを備えたASLA（（2）（c）の影響を受けないため、「更新されたセット」から変わらずに繰り越されます）

5. ASLA with the X bit set on it with SRLGs from IS-IS advertisement (c) (not affected by (2)(c) and therefore carried forward unchanged from the "updated set")

5. Xビットを備えたASLAは、IS-IS広告（c）のsrlgsで設定されています（（2）（c）の影響を受けないため、「更新されたセット」から変更されずに繰り越されます）

Implementations may optionally perform further consolidation by processing the "final set" above based on (2)(d) to determine the following "consolidated final set":

実装は、（2）（d）に基づいて上記の「最終セット」を処理して、次の「統合最終セット」を決定することにより、オプションでさらに統合を実行する場合があります。

1. ASLA with the S and F bits set on it that carries application-specific link attributes from IS-IS advertisement (a) and SRLGs from IS-IS advertisement (b) (this is the consolidation of items 1 and 2 of the "final set" based on (2)(d))

1. IS-IS広告（a）からのアプリケーション固有のリンク属性とIS-IS広告（b）からのSRLG（これは、「最終セットの項目1と2の統合）を搭載したSおよびFビットを備えたASLAが設定されています。"（2）（d）に基づいて

2. ASLA with the X bit set on it that carries certain application-specific link attributes from IS-IS advertisement (a) (it is unaffected by this consolidation)

2. xビットが設定されたASLAは、IS-IS Advertisement（a）から特定のアプリケーション固有のリンク属性を搭載しています（この統合の影響を受けません）

3. ASLA with zero-length bit masks with a set of application-specific SRLGs from IS-IS advertisement (b) (this is retained based on (2)(e) and is unaffected by any further consolidation)

3. IS-IS広告（b）からのアプリケーション固有のSRLGSのセットを備えたゼロレングスビットマスクを備えたASLA（これは（2）（e）に基づいて保持され、さらなる統合の影響を受けません）

4. ASLA with the X bit set on it with a set of application-specific SRLGs from IS-IS advertisement (c) (it is unaffected by this consolidation)

4. xビットを備えたASLAは、IS-IS広告（c）からのアプリケーション固有のSRLGSのセットで設定されています（この統合の影響を受けません）

Further optimization (e.g., combining (2) and (4) from the "consolidated final set" above into a single BGP-LS ASLA TLV) may be possible while ensuring that the semantics are preserved between the IS-IS and BGP-LS advertisements. Such optimizations are outside the scope of this document.

IS-ISとBGP-LS広告の間にセマンティクスが保存されていることを保証しながら、さらに最適化（例：上記の「統合最終セット」からの（統合最終セット」からの組み合わせ）が可能になる場合があります。このような最適化は、このドキュメントの範囲外です。

5. Deployment Considerations

5. 展開の考慮事項

BGP-LS sources the link-state topology information (including the extensions introduced by this document) from the underlying link-state IGP protocols. The various deployment aspects related to the advertisement and use of application-specific link attributes are discussed in the Deployment Considerations sections of [RFC8920] and [RFC8919]. The IGP backward-compatibility aspects described in those documents associated with application-specific link attributes along with the BGP-LS procedures specified in this document enable backward compatibility in deployments of existing implementations of [RFC7752], [RFC8571], and [RFC9104] for applications such as RSVP-TE, SR Policy, and LFA.

BGP-LSは、基礎となるリンク状態のIGPプロトコルから、リンク状態トポロジ情報（このドキュメントで導入された拡張機能を含む）を調達します。アプリケーション固有のリンク属性の広告と使用に関連するさまざまな展開の側面については、[RFC8920]および[RFC8919]の展開考慮事項セクションで説明します。このドキュメントで指定されたBGP-LS手順とともに、アプリケーション固有のリンク属性に関連するドキュメントで説明されているIGP後方互換性の側面は、[RFC7752]、[RFC8571]、および[RFC9104]の既存の実装の展開において後方互換性を可能にします。RSVP-TE、SRポリシー、LFAなどのアプリケーション。

It is recommended that only nodes supporting this specification are selected as originators of BGP-LS information when advertising the link-state information from the IGPs in deployments supporting application-specific link attributes.

この仕様をサポートするノードのみが、アプリケーション固有のリンク属性をサポートする展開のIGPSからリンク状態情報を宣伝する際に、BGP-LS情報の発信者として選択されることをお勧めします。

BGP-LS consumers that do not support this specification can continue to use the existing top-level TLVs for link attributes for existing applications as discussed above. However, they would be able to support neither the application-specific link attributes nor newer applications that may be encoded only using the ASLA TLV.

この仕様をサポートしていないBGP-LS消費者は、上記のように既存のアプリケーションのリンク属性に既存のトップレベルTLVを引き続き使用できます。ただし、アプリケーション固有のリンク属性も、ASLA TLVを使用してエンコードできる新しいアプリケーションもサポートできません。

6. IANA Considerations

6. IANAの考慮事項

IANA has assigned a code point from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry as described in the following table. There is no "IS-IS TLV/Sub-TLV" value for this entry.

IANAは、次の表で説明されているように、「BGP-LSノード記述子、リンク記述子、プレフィックス記述子、および属性TLVS」レジストリからコードポイントを割り当てました。このエントリには、「is-is tlv/sub-tlv」値はありません。

   +================+======================================+===========+
   | TLV Code Point | Description                          | Reference |
   +================+======================================+===========+
   | 1122           | Application-Specific                 | RFC 9294  |
   |                | Link Attributes                      |           |
   +----------------+--------------------------------------+-----------+

Table 2: ASLA TLV Code Point Allocation

表2：ASLA TLVコードポイント割り当て

7. Manageability Considerations

7. 管理可能性の考慮事項

The protocol extensions introduced in this document augment the existing IGP topology information defined in [RFC7752]. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in the Manageability Considerations section of [RFC7752]. Specifically, the malformed NLRI attribute tests in the Fault Management section of [RFC7752] now encompass the BGP-LS TLVs defined in this document.

このドキュメントで導入されたプロトコル拡張は、[RFC7752]で定義された既存のIGPトポロジ情報を強化します。このドキュメントで定義されている手順とプロトコル拡張は、[RFC7752]の管理セクションで説明されている場合を除き、BGPプロトコル操作と管理に影響しません。具体的には、[RFC7752]の障害管理セクションの奇形のNLRI属性テストは、このドキュメントで定義されているBGP-LS TLVを包含するようになりました。

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 [IDR-BGP-MODEL].

このドキュメントで指定された拡張機能は、BGPまたはBGP-LSの新しい構成または監視の側面を指定しません。BGPモデルの仕様は、[IDR-BGP-Model]に基づいた継続的な作業です。

8. Security Considerations

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

Security considerations for acquiring and distributing BGP-LS information are discussed in [RFC7752]. Specifically, the considerations related to topology information, which are related to traffic engineering, apply.

BGP-LS情報を取得および配布するためのセキュリティ上の考慮事項については、[RFC7752]で説明されています。具体的には、トラフィックエンジニアリングに関連するトポロジ情報に関連する考慮事項が適用されます。

The TLVs introduced in this document are used to propagate the application-specific link attributes IGP extensions defined in [RFC8919] and [RFC8920]. It is assumed that the IGP instances originating these TLVs will support all the required security (as described in [RFC8919] and [RFC8920]).

このドキュメントで導入されたTLVは、[RFC8919]および[RFC8920]で定義されているアプリケーション固有のリンク属性IGP拡張属性を伝播するために使用されます。これらのTLVを発信するIGPインスタンスは、必要なすべてのセキュリティをサポートすると想定されています（[RFC8919]および[RFC8920]で説明されています）。

This document defines a new way to advertise link attributes. Tampering with the information defined in this document may affect applications using it, including impacting traffic engineering, which uses various link attributes for its path computation. As the advertisements defined in this document limit the scope to specific applications, the impact of tampering is similarly limited in scope. The advertisement of the link attribute information defined in this document presents no significant additional risk beyond that associated with the existing link attribute information already supported in [RFC7752].

このドキュメントは、リンク属性を宣伝する新しい方法を定義します。このドキュメントで定義されている情報を改ざんすると、パス計算にさまざまなリンク属性を使用するトラフィックエンジニアリングに影響を与えるなど、アプリケーションを使用するアプリケーションに影響を与える可能性があります。このドキュメントで定義されている広告が特定のアプリケーションに範囲を制限するため、改ざんの影響は同様に範囲が制限されています。このドキュメントで定義されているリンク属性情報の広告は、[RFC7752]で既にサポートされている既存のリンク属性情報に関連するものを超えた重大な追加リスクを提示しません。

9. References

9. 参考文献

9.1. Normative References

9.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。、「要件レベルを示すためにRFCで使用するためのキーワード」、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を使用したリンク状態および交通工学の北行き分布（TE）情報」、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>。

[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.

[RFC8571] Ginsberg、L.、Ed。、Previdi、S.、Wu、Q.、Tantsura、J.、およびC. Filsfils、「BGP -Link State（BGP -LS）IGPトラフィックエンジニアリングパフォーマンスメトリック拡張の広告」、RFC 8571、DOI 10.17487/RFC8571、2019年3月、<https://www.rfc-editor.org/info/rfc8571>。

[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.

[RFC8919] Ginsberg、L.、Psenak、P.、Previdi、S.、Henderickx、W。、およびJ. Drake、「IS-ISアプリケーション固有のリンク属性」、RFC 8919、DOI 10.17487/RFC8919、2020年10月、<https://www.rfc-editor.org/info/rfc8919>。

[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, "OSPF Application-Specific Link Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, <https://www.rfc-editor.org/info/rfc8920>.

[RFC8920] Psenak、P.、Ed。、Ginsberg、L.、Henderickx、W.、Tantsura、J.、およびJ. Drake、「OSPFアプリケーション固有のリンク属性」、RFC 8920、DOI 10.17487/RFC8920、2020202020202020202020、<https://www.rfc-editor.org/info/rfc8920>。

[RFC9104] Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar, "Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104, August 2021, <https://www.rfc-editor.org/info/rfc9104>.

[RFC9104] Tantsura、J.、Wang、Z.、Wu、Q.、およびK. Talaulikar、「Border Gateway Protocol -link State（BGP -LS）を使用して、トラフィックエンジニアリングの分布拡張管理グループ」、RFC 9104、doi10.17487/rfc9104、2021年8月、<https://www.rfc-editor.org/info/rfc9104>。

9.2. Informative References

9.2. 参考引用

[IDR-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-14, 3 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-14>.

[IDR-BGP-Model] Jethanandani、M.、Patel、K.、Hares、S。、およびJ. Haas、「サービスプロバイダーネットワーク用のBGP Yangモデル」、作業中、インターネットドラフト、Draft-Itf-Idr-bgp-model-14、2022年7月3日、<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-14>。

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.

[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS ISの使用」、RFC 1195、DOI 10.17487/RFC1195、1990年12月、<https://www.rfc-editor.org/情報/rfc1195>。

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487/RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSPトンネルのRSVPへの拡張"、RFC 3209、doi10.17487/rfc3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。

[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <https://www.rfc-editor.org/info/rfc4202>.

[RFC4202] Kompella、K.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、DOI 10.17487/RFC4202、2005年10月、<https://www.rfc-editor.org/info/rfc4202>。

[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <https://www.rfc-editor.org/info/rfc5286>.

[RFC5286] Atlas、A.、ed。and A. Zinin、ed。、「IP Fast Reroute：Loop-Free Alternatesの基本仕様」、RFC 5286、DOI 10.17487/RFC5286、2008年9月、<https://www.rfc-editor.org/info/rfc5286>。

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487/RFC5340、2008年7月、<https：//www.rfc-editor.org/info/rfc5340>。

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

Acknowledgements

謝辞

The authors would like to thank Les Ginsberg, Baalajee S., Amalesh Maity, Acee Lindem, Keyur Patel, Paul Wouters, Rudy Selderslaghs, Kristy Paine, and Shraddha Hegde for their review and feedback on this document. The authors would like to thank Alvaro Retana for his very detailed AD review and comments that improved this document. The authors would also like to thank John Scudder for his detailed review and feedback on clarifying the procedures along with the example in Section 4.

著者は、レス・ギンズバーグ、バラジー・S、アマレシュ・メイティ、エーシー・リンデム、キール・パテル、ポール・ウーターズ、ルディ・セルダースラグス、クリスティ・ペイン、シュラダ・ヘグデにこの文書に関するレビューとフィードバックに感謝します。著者は、この文書を改善した非常に詳細な広告レビューとコメントについて、Alvaro Retanaに感謝したいと思います。著者はまた、セクション4の例とともに手順を明確にすることに関する詳細なレビューとフィードバックについて、John Scudderに感謝したいと思います。

Authors' Addresses

著者のアドレス

Ketan Talaulikar (editor) Arrcus Inc. India Email: ketant.ietf@gmail.com

Ketan Talaulikar（編集者）Arrcus Inc.インドメール：ketant.ietf@gmail.com

Peter Psenak Cisco Systems Slovakia Email: ppsenak@cisco.com

Peter Psenak Cisco Systems Slovakiaメール：ppsenak@cisco.com

Jeff Tantsura Microsoft Email: jefftant.ietf@gmail.com

Jeff Tantsura Microsoftメール：jefftant.ietf@gmail.com