Internet Engineering Task Force (IETF) Z. Li
Request for Comments: 9513 Z. Hu
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 K. Talaulikar, Ed.
P. Psenak
Cisco Systems
December 2023
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane.
セグメントルーティング（SR）アーキテクチャは、セグメントと呼ばれる一連のトポロジ要素としてエンコードすることにより、エンドツーエンドパスの柔軟な定義を可能にします。MPLSまたはIPv6データプレーンを介して実装できます。このドキュメントでは、IPv6データプレーンでSRをサポートするために必要なOSPFV3拡張機能について説明します。
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/rfc9513.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9513で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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ライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. SRv6 Capabilities TLV
3. Advertisement of Supported Algorithms
4. Advertisement of Maximum SRv6 SID Depths
4.1. Maximum Segments Left MSD Type
4.2. Maximum End Pop MSD Type
4.3. Maximum H.Encaps MSD Type
4.4. Maximum End D MSD Type
5. SRv6 SIDs and Reachability
5.1. SRv6 Flexible Algorithm
6. Advertisement of Anycast Property
7. SRv6 Locator LSA
7.1. SRv6 Locator TLV
7.2. SRv6 Locator Sub-TLVs
8. Advertisement of SRv6 End SIDs
9. Advertisement of SRv6 SIDs Associated with Adjacencies
9.1. SRv6 End.X SID Sub-TLV
9.2. SRv6 LAN End.X SID Sub-TLV
10. SRv6 SID Structure Sub-TLV
11. Advertising Endpoint Behaviors
12. Security Considerations
13. IANA Considerations
13.1. OSPF Router Information TLVs
13.2. OSPFv3 LSA Function Codes
13.3. OSPFv3 Prefix Options
13.4. OSPFv3 SRv6 Capabilities TLV Flags
13.5. OSPFv3 SRv6 End SID Sub-TLV Flags
13.6. OSPFv3 SRv6 Adjacency SID Sub-TLV Flags
13.7. OSPFv3 Extended-LSA Sub-TLVs
13.8. OSPFv3 SRv6 Locator LSA TLVs
13.9. OSPFv3 SRv6 Locator LSA Sub-TLVs
13.10. OSPFv3 Extended-LSA Sub-TLVs
14. References
14.1. Normative References
14.2. Informative References
Acknowledgements
Authors' Addresses
The Segment Routing (SR) architecture [RFC8402] specifies how a node can steer a packet using an ordered list of instructions called segments. These segments are identified using Segment Identifiers (SIDs).
セグメントルーティング（SR）アーキテクチャ[RFC8402]は、セグメントと呼ばれる命令のリストを使用してノードがパケットを操作する方法を指定します。これらのセグメントは、セグメント識別子（SIDS）を使用して識別されます。
SR can be instantiated on the IPv6 data plane through the use of the Segment Routing Header (SRH) defined in [RFC8754]. SR instantiation on the IPv6 data plane is referred to as SRv6.
[RFC8754]で定義されたセグメントルーティングヘッダー（SRH）を使用して、SRはIPv6データプレーンにインスタンス化できます。IPv6データプレーンのSRインスタンス化は、SRV6と呼ばれます。
The network programming paradigm for SRv6 is specified in [RFC8986]. It describes how any behavior can be bound to a SID and how any network program can be expressed as a combination of SIDs. It also describes several well-known behaviors that can be bound to SRv6 SIDs.
SRV6のネットワークプログラミングパラダイムは、[RFC8986]で指定されています。これは、動作をSIDにどのように拘束できるか、およびネットワークプログラムをSIDの組み合わせとして表現する方法を説明しています。また、SRV6 SIDSにバインドできるいくつかのよく知られている行動についても説明しています。
This document specifies OSPFv3 extensions to support SRv6 capabilities as defined in [RFC8986], [RFC8754], and [RFC9259]. The extensions include advertisement of an OSPFv3 router's SRv6 capabilities, SRv6 Locators, and required SRv6 SIDs along with their supported Endpoint behaviors. Familiarity with [RFC8986] is necessary to understand the extensions specified in this document.
このドキュメントは、[RFC8986]、[RFC8754]、および[RFC9259]で定義されているSRV6機能をサポートするOSPFV3拡張機能を指定します。拡張機能には、OSPFV3ルーターのSRV6機能、SRV6ロケーターの広告、およびサポートされているエンドポイント動作とともに必要なSRV6 SIDが含まれます。[RFC8986]に精通していることは、このドキュメントで指定されている拡張機能を理解するために必要です。
At a high level, the extensions to OSPFv3 are comprised of the following:
高レベルでは、OSPFV3の拡張は以下で構成されています。
1. An SRv6 Capabilities TLV to advertise the SRv6 features and SRH operations supported by an OSPFv3 router.
1. SRV6機能TLVは、OSPFV3ルーターによってサポートされるSRV6機能とSRH操作を宣伝します。
2. Several sub-TLVs to advertise various SRv6 Maximum SID Depths.
2. さまざまなSRV6最大SID深さを宣伝するためのいくつかのサブTLV。
3. An SRv6 Locator TLV using an SRv6 Locator Link State Advertisement (LSA) to advertise the SRv6 Locator -- a form of summary address for the IGP algorithm-specific SIDs instantiated on an OSPFv3 router.
3. SRV6ロケーターリンク状態広告（LSA）を使用してSRV6ロケーターTLVを使用してSRV6ロケーターを宣伝します。これは、OSPFV3ルーターにインスタンス化されたIGPアルゴリズム固有のSIDの要約アドレスの形式です。
4. TLVs and sub-TLVs to advertise the SRv6 SIDs instantiated on an OSPFv3 router along with their Endpoint behaviors.
4. TLVとSub-TLVは、Endpointの動作とともにOSPFV3ルーターにインスタンス化されたSRV6 SIDSを宣伝します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise its support for the SR Segment Endpoint Node [RFC8754] functionality along with its SRv6-related capabilities. This is an optional top-level TLV of the OSPFv3 Router Information LSA [RFC7770] that MUST be advertised by an SRv6-enabled router.
SRV6機能TLVは、OSPFV3ルーターによって使用され、SRセグメントエンドポイントノード[RFC8754]機能とSRV6関連機能のサポートを宣伝します。これは、SRV6対応ルーターによって宣伝する必要があるOSPFV3ルーター情報LSA [RFC7770]のオプションのトップレベルTLVです。
This TLV MUST be advertised only once in the OSPFv3 Router Information LSA. When multiple SRv6 Capabilities TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the OSPFv3 Router Information LSA. If the SRv6 Capabilities TLV appears in multiple OSPFv3 Router Information LSAs that have different flooding scopes, the TLV in the OSPFv3 Router Information LSA with the area-scoped flooding scope MUST be used. If the SRv6 Capabilities TLV appears in multiple OSPFv3 Router Information LSAs that have the same flooding scope, the TLV in the OSPFv3 Router Information LSA with the numerically smallest Link State ID MUST be used, and subsequent instances of the TLV MUST be ignored.
このTLVは、OSPFV3ルーター情報LSAで一度だけ宣伝する必要があります。複数のSRV6機能TLVが特定のルーターから受信される場合、受信者はOSPFV3ルーター情報LSAでTLVの最初の発生を使用する必要があります。SRV6機能TLVが異なる洪水スコープを持つ複数のOSPFV3ルーター情報LSAに表示される場合、エリアスコープのある洪水スコープを備えたOSPFV3ルーター情報LSAのTLVを使用する必要があります。SRV6機能TLVが同じ洪水範囲を持つ複数のOSPFV3ルーター情報LSAに表示される場合、OSPFV3ルーター情報LSAのTLVは、数値的に最小のリンク状態IDを使用する必要があり、TLVのその後のインスタンスを無視する必要があります。
The OSPFv3 Router Information LSA can be advertised at any of the defined flooding scopes (link, area, or Autonomous System (AS)). For the purpose of SRv6 Capabilities TLV advertisement, area-scoped flooding is REQUIRED. Link and AS-scoped flooding is OPTIONAL.
OSPFV3ルーター情報LSAは、定義された洪水スコープ（リンク、面積、または自律システム（AS））のいずれかで宣伝できます。SRV6機能TLV広告の目的のために、エリアスコープの洪水が必要です。リンクとスコープのある洪水はオプションです。
The format of the OSPFv3 SRv6 Capabilities TLV is shown below:
OSPFV3 SRV6機能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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6 Capabilities TLV
図1：SRV6機能TLV
where:
ただし：
Type:
タイプ：
2-octet field. The value for this type is 20.
2-OCTETフィールド。このタイプの値は20です。
Length:
長さ：
2-octet field. The total length (in octets) of the value portion of the TLV, including nested sub-TLVs.
2-OCTETフィールド。ネストされたサブTLVを含むTLVの値部分の総長さ（オクテット）。
Reserved:
予約済み：
2-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
2-OCTETフィールド。送信時に0に設定する必要があり、受領時に無視する必要があります。
Flags:
フラグ：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |O| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O-flag:
o-flag：
If set, then the router is capable of supporting the O-flag in the SRH flags, as specified in [RFC9259].
設定されている場合、[RFC9259]で指定されているように、ルーターはSRHフラグのO-Flagをサポートできます。
Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.
他のフラグは定義されておらず、将来の使用のために予約されています。それらは送信時に0に設定する必要があり、受領時に無視する必要があります。
2-octet field. The flags are defined as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |O| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: O-flag: If set, then the router is capable of supporting the O-flag in the SRH flags, as specified in [RFC9259]. Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.
2-OCTETフィールド。フラグは次のように定義されています：0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5--------------------------------------------------------------| o ||---------------ここ：O -Flag：設定されている場合、[RFC9259]で指定されているように、ルーターはSRHフラグのO -Flagをサポートできます。他のフラグは定義されておらず、将来の使用のために予約されています。それらは送信時に0に設定する必要があり、受領時に無視する必要があります。
The SRv6 Capabilities TLV may contain optional sub-TLVs. No sub-TLVs are defined in this specification.
SRV6機能TLVには、オプションのサブTLVが含まれている場合があります。この仕様では、サブTLVは定義されていません。
An SRv6-enabled OSPFv3 router advertises its algorithm support using the SR-Algorithm TLV defined in [RFC8665] and as described in [RFC8666].
SRV6対応のOSPFV3ルーターは、[RFC8665]で定義され、[RFC8666]で説明されているように、SR-AlgorithM TLVを使用してアルゴリズムサポートを宣伝します。
An SRv6-enabled router may have different capabilities and limits related to SRH processing. These need to be advertised to other OSPFv3 routers in the SRv6 domain.
SRV6対応ルーターは、SRH処理に関連する異なる機能と制限を持つ場合があります。これらは、SRV6ドメインの他のOSPFV3ルーターに宣伝する必要があります。
[RFC8476] defines the means to advertise node- and link-specific values for Maximum SID Depth (MSD) types. Node MSDs are advertised using the Node MSD TLV in the OSPFv3 Router Information LSA [RFC7770], while Link MSDs are advertised using the Link MSD sub-TLV of the Router-Link TLV [RFC8362]. The format of the MSD types for OSPFv3 is defined in [RFC8476].
[RFC8476]は、最大SID深度（MSD）タイプのノードおよびリンク固有の値を宣伝する手段を定義します。ノードMSDは、OSPFV3ルーター情報LSA [RFC7770]のノードMSD TLVを使用して宣伝され、リンクMSDはルーターリンクTLV [RFC8362]のリンクMSDサブTLVを使用して宣伝されます。OSPFV3のMSDタイプの形式は、[RFC8476]で定義されています。
The MSD types for SRv6 that are defined in Section 4 of [RFC9352] for IS-IS are also used by OSPFv3. These MSD types are allocated in the "IGP MSD-Types" registry maintained by IANA and are shared by IS-IS and OSPF. They are described in the subsections below.
IS-ISの[RFC9352]のセクション4で定義されているSRV6のMSDタイプは、OSPFV3によっても使用されます。これらのMSDタイプは、IANAによって維持されている「IGP MSDタイプ」レジストリに割り当てられ、IS-ISとOSPFによって共有されています。以下のサブセクションで説明されています。
The Maximum Segments Left MSD Type signals the maximum value of the Segments Left field of the SRH of a received packet before applying the Endpoint behavior associated with a SID. If no value is advertised, the supported value is assumed to be 0.
左の最大セグメントは、SIDに関連付けられたエンドポイント動作を適用する前に、受信パケットのSRHの左フィールドのセグメントの最大値を信号します。値が宣伝されていない場合、サポートされた値は0と想定されます。
The Maximum End Pop MSD Type signals the maximum number of SIDs in the SRH to which the router can apply "Penultimate Segment Pop (PSP) of the SRH" or "Ultimate Segment Pop (USP) of the SRH", which are flavors defined in [RFC8986]. If the advertised value is zero or no value is advertised, then the router cannot apply the PSP or USP flavors.
最大エンドポップMSDタイプは、ルーターが「SRHの最後から2番目のセグメントポップ（PSP）」または「SRHの究極のセグメントポップ（USP）」を適用できるSRHのSIDの最大数を信号します。[RFC8986]。広告された値がゼロまたは宣伝されていない場合、ルーターはPSPまたはUSPフレーバーを適用できません。
The Maximum H.Encaps MSD Type signals the maximum number of SIDs that can be added as part of the H.Encaps behavior as defined in [RFC8986]. If the advertised value is zero or no value is advertised, then the headend can apply an SR Policy that only contains one segment without inserting any SRH. A non-zero SRH Max H.Encaps MSD indicates that the headend can insert an SRH with SIDs up to the advertised value.
最大H.ENCAPS MSDタイプは、[RFC8986]で定義されているH.ENCAPSの動作の一部として追加できるSIDの最大数を信号します。広告の値がゼロまたは宣伝されている場合、ヘッドエンドは、SRHを挿入せずに1つのセグメントのみを含むSRポリシーを適用できます。ゼロ以外のSRH MAX H.ENCAPS MSDは、ヘッドエンドが広告値までSIDを添加したSRHを挿入できることを示します。
The Maximum End D MSD Type specifies the maximum number of SIDs present in an SRH when performing decapsulation. These include, but are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and End.X with USD as defined in [RFC8986]. If the advertised value is zero or no value is advertised, then the router cannot apply any behavior that results in decapsulation and forwarding of the inner packet when the outer IPv6 header contains an SRH.
最大末端D MSDタイプは、脱カプセル化を実行するときにSRHに存在するSIDの最大数を指定します。これらには、[RFC8986]で定義されているように、end.dx6、end.dt4、end.dt46、end.dt46、end.x with USDが含まれますが、これらに限定されません。広告の値がゼロまたは宣伝されている場合、ルーターは、外側のIPv6ヘッダーにSRHが含まれている場合、内側パケットの脱カプセル化と転送をもたらす動作を適用できません。
An SRv6 SID is 128 bits and consists of locator, function, and argument parts as described in [RFC8986].
SRV6 SIDは128ビットで、[RFC8986]で説明されているように、ロケーター、機能、および引数部分で構成されています。
An OSPFv3 router is provisioned with algorithm-specific locators for each algorithm supported by that router. Each locator is a covering prefix for all SIDs provisioned on that router that have the matching algorithm.
OSPFV3ルーターは、そのルーターでサポートされている各アルゴリズムのアルゴリズム固有のロケーターをプロビジョニングします。各ロケーターは、一致するアルゴリズムを持つルーターにプロビジョニングされたすべてのSIDのカバープレフィックスです。
Locators MUST be advertised within an SRv6 Locator TLV (see Section 7.1) using an SRv6 Locator LSA (see Section 7). The SRv6 Locator LSA is introduced instead of reusing the respective Extended Prefix LSAs [RFC8362] for a clear distinction between the two different types of reachability advertisements (viz., the base OSPFv3 prefix reachability advertisements and the SRv6 Locator reachability advertisements).
ロケーターは、SRV6ロケーターLSA（セクション7を参照）を使用して、SRV6ロケーターTLV（セクション7.1を参照）内で宣伝する必要があります。SRV6ロケーターLSAは、それぞれの拡張プレフィックスLSA [RFC8362]を再利用する代わりに導入され、2つの異なるタイプの到達可能性広告（すなわち、ベースOSPFV3プレフィックスリーチビリティ広告とSRV6ローケーターリーチ性広告）を明確に区別します。
Forwarding entries for the locators advertised in the SRv6 Locator TLV MUST be installed in the forwarding plane of receiving SRv6-capable routers when the associated algorithm is supported by the receiving OSPFv3 router. Locators can be of different route types that map to existing OSPFv3 LSA types: Intra-Area, Inter-Area, External, and Not-So-Stubby Area (NSSA). The advertisement and propagation of the SRv6 Locator LSAs also follow the OSPFv3 [RFC5340] specifications for the respective LSA types. The processing of the prefix advertised in the SRv6 Locator TLV, the calculation of its reachability, and the installation in the forwarding plane follows the OSPFv3 [RFC5340] specifications for the respective LSA types.
SRV6ロケーターTLVで宣伝されているロケーターの転送エントリは、関連するアルゴリズムが受信OSPFV3ルーターによってサポートされている場合、SRV6対応ルーターを受信する転送面にインストールする必要があります。ロケーターは、既存のOSPFV3 LSAタイプにマッピングされるさまざまなルートタイプを備えています。エリア内、エリア、外部、およびそれほど並んでいないエリア（NSSA）です。SRV6ロケーターLSAの広告と伝播は、それぞれのLSAタイプのOSPFV3 [RFC5340]仕様にも従います。SRV6ロケーターTLVで宣伝されているプレフィックスの処理、その到達可能性の計算、および転送面への設置は、それぞれのLSAタイプのOSPFV3 [RFC5340]仕様に従います。
Locators associated with algorithms 0 and 1 (refer to Section 3.1.1 of [RFC8402]) SHOULD also be advertised using Extended LSA types with extended TLVs [RFC8362] so that routers that do not support SRv6 will install a forwarding entry for SRv6 traffic matching those locators. When operating in Extended LSA sparse-mode [RFC8362], these locators SHOULD also be advertised using Legacy LSAs [RFC5340].
アルゴリズム0および1（[RFC8402]のセクション3.1.1を参照）に関連付けられているロケーターは、拡張TLV [RFC8362]を備えた拡張LSAタイプを使用して宣伝する必要があります。そうすることで、SRV6をサポートしないルーターがSRV6トラフィックマッチングの転送エントリをインストールします。それらのロケーター。拡張されたLSAスパースモード[RFC8362]で動作する場合、これらのロケーターは、LEGACY LSA [RFC5340]を使用して宣伝する必要があります。
When SRv6 Locators are also advertised as Intra-Area-Prefix-LSAs and/ or E-Intra-Area-Prefix-LSAs, the SRv6 Locator MUST be considered as a prefix associated with the router, and the referenced LSA type MUST point to the Router LSA of the advertising router as specified in Section 4.4.3.9 of [RFC5340].
SRV6ロケーターがエリア内 - プレーフィックスLSAおよび/またはE-Intra-Area-Prefix-LSAとして宣伝されている場合、SRV6ロケーターはルーターに関連付けられたプレフィックスと見なされ、参照されるLSAタイプは[RFC5340]のセクション4.4.3.9で指定されている広告ルーターのルーターLSA。
In cases where a locator advertisement is received both in a prefix reachability advertisement (i.e., via Legacy LSAs and/or Extended Prefix TLVs using Extended LSAs) and an SRv6 Locator TLV, the prefix reachability advertisement in the Legacy LSA or Extended LSA MUST be preferred over the advertisement in the SRv6 Locator TLV when installing entries in the forwarding plane. This prevents inconsistent forwarding entries between SRv6-capable and SRv6-incapable OSPFv3 routers. Such preference for prefix reachability advertisement does not have any impact on the rest of the data advertised in the SRv6 Locator TLV.
ロケーターの広告がプレフィックスの到達可能性広告（つまり、拡張LSAを使用したレガシーLSAおよび/または拡張プレフィックスTLVを介して）とSRV6ロケーターTLVの両方で受信される場合、レガシーLSAまたは拡張LSAのプレフィックスリーチビリティ広告は推奨されなければなりません転送面にエントリをインストールするときに、SRV6ロケーターTLVの広告を介して。これにより、SRV6対応とSRV6に入れられないOSPFV3ルーター間の一貫性のない転送エントリが防止されます。プレフィックスの到達可能性広告に対するこのような優先は、SRV6ロケーターTLVで宣伝されている他のデータに影響を与えません。
SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except for SRv6 End.X SIDs and LAN End.X SIDs, which are associated with a specific neighbor/link and are therefore advertised as sub-TLVs of the E-Router-Link TLV.
SRV6 SIDSは、SRV6 ENDS.X SIDSおよびLAN ENDS.X SIDSを除き、SRV6ロケーターTLVのサブTLVとして宣伝されています。リンクTLV。
SRv6 SIDs received from other OSFPv3 routers are not directly routable and MUST NOT be installed in the forwarding plane. Reachability to SRv6 SIDs depends upon the existence of a covering locator.
他のOSFPV3ルーターから受信したSRV6 SIDは、直接ルーティング可能ではなく、転送面に取り付けてはなりません。SRV6 SIDSの到達可能性は、カバーロケーターの存在に依存します。
Adherence to the rules defined in this section will ensure that SRv6 SIDs associated with a supported algorithm will be forwarded correctly, while SRv6 SIDs associated with an unsupported algorithm will be dropped.
このセクションで定義されているルールの順守により、サポートされているアルゴリズムに関連付けられたSRV6 SIDが正しく転送され、サポートされていないアルゴリズムに関連付けられたSRV6 SIDが削除されます。
NOTE: The drop behavior depends on the absence of a default/ summary route matching the locator prefix.
注：ドロップの動作は、ロケータープレフィックスに一致するデフォルト/サマリールートがないことに依存します。
If the locator associated with SRv6 SID advertisements is the longest prefix match installed in the forwarding plane for those SIDs, this will ensure correct forwarding. Network operators should take steps to make sure that this requirement is not compromised. For example, the following situations should be avoided:
SRV6 SID広告に関連付けられているロケーターが、これらのSIDの転送面にインストールされている最長のプレフィックスマッチである場合、これにより正しい転送が保証されます。ネットワークオペレーターは、この要件が損なわれないことを確認するための措置を講じる必要があります。たとえば、次の状況を避ける必要があります。
* Another locator associated with a different algorithm is the longest prefix match.
* 別のアルゴリズムに関連付けられた別のロケーターは、最長のプレフィックスマッチです。
* Another prefix advertised via Legacy or Extended LSA advertisement is the longest prefix match.
* Legacyまたは拡張LSA広告を介して宣伝されている別の接頭辞は、最長のプレフィックスマッチです。
[RFC9350] specifies IGP Flexible Algorithm mechanisms for OSPFv3. Section 14.2 of [RFC9350] explains SRv6 forwarding for Flexible Algorithms, and analogous procedures apply for supporting SRv6 Flexible Algorithms using OSPFv3. When the algorithm value that is advertised in the SRv6 Locator TLV (refer to Section 7.1) represents a Flexible Algorithm, the procedures described in Section 14.2 of [RFC9350] are followed for the programming of those specific SRv6 Locators.
[RFC9350]は、OSPFV3のIGP柔軟なアルゴリズムメカニズムを指定します。[RFC9350]のセクション14.2では、柔軟なアルゴリズムのSRV6転送について説明し、OSPFV3を使用したSRV6フレキシブルアルゴリズムのサポートには類似の手順が適用されます。SRV6ロケーターTLV（セクション7.1を参照）で宣伝されているアルゴリズム値が柔軟なアルゴリズムを表している場合、[RFC9350]のセクション14.2で説明されている手順が、これらの特定のSRV6ロケーターのプログラミングに従います。
Locators associated with Flexible Algorithms SHOULD NOT be advertised in the base OSPFv3 prefix reachability advertisements. Advertising the Flexible Algorithm locator in a regular prefix reachability advertisement would make it available for non-Flexible Algorithm forwarding (i.e., algorithm 0).
柔軟なアルゴリズムに関連付けられたロケーターは、ベースOSPFV3プレフィックスリーチビリティ広告に宣伝されないでください。通常のプレフィックスの到達可能性広告で柔軟なアルゴリズムロケーターを広告すると、柔軟性のないアルゴリズムの転送（つまり、アルゴリズム0）で利用可能になります。
The procedures for OSPFv3 Flexible Algorithm for SR-MPLS, as specified in [RFC9350], also apply for SRv6; these procedures include a) ASBR reachability, b) inter-area, external, and NSSA prefix advertisements, and c) the use of those prefix advertisements in Flexible Algorithm route computation.
[RFC9350]で指定されているSR-MPLSのOSPFV3フレキシブルアルゴリズムの手順もSRV6に適用されます。これらの手順には、a）ASBRリーチビリティ、b）エリア、外部、およびNSSAプレフィックス広告、c）柔軟なアルゴリズムルート計算でのプレフィックス広告の使用が含まれます。
Both prefixes and SRv6 Locators may be configured as anycast, and as such, the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier.
プレフィックスとSRV6ロケーターの両方がAnycastとして構成される場合があります。そのため、同じ値を複数のルーターで宣伝できます。他のルーターにとって、広告がAnycast Identifierのためのものであることを知ることは役立ちます。
The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340] is defined to advertise the anycast property:
OSPFV3プレフィックスオプションフィールド[RFC5340]のACビット（値0x80）は、Anycastプロパティを宣伝するために定義されています。
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|AC|EL| N|DN| P| x|LA|NU|
+--+--+--+--+--+--+--+--+
Figure 2: OSPFv3 Prefix Options Field
図2：OSPFV3プレフィックスオプションフィールド
When the prefix/SRv6 Locator is configured as anycast, the AC-bit MUST be set. Otherwise, this flag MUST be clear.
プレフィックス/srv6ロケーターがAnycastとして構成されている場合、ACビットを設定する必要があります。それ以外の場合、このフラグは明確でなければなりません。
The AC-bit MUST be preserved when re-advertising the prefix/SRv6 Locator across areas.
ACビットは、エリア全体でプレフィックス/SRV6ロケーターを再版画するときに保存する必要があります。
The AC-bit and the N-bit MUST NOT both be set. If the N-bit and AC-bit are both set in the prefix/SRv6 Locator advertisement, the receiving routers MUST ignore the N-bit.
ACビットとNビットの両方を設定してはなりません。N-BITとAC-BITがどちらもプレフィックス/SRV6ロケーター広告に設定されている場合、受信ルーターはNビットを無視する必要があります。
The same prefix/SRv6 Locator can be advertised by multiple routers. If at least one of them sets the AC-bit in its advertisement, the prefix/SRv6 Locator is considered as anycast.
同じプレフィックス/SRV6ロケーターは、複数のルーターで宣伝できます。少なくともそのうちの1つが広告にACビットを設定している場合、プレフィックス/SRV6ロケーターはAnyCastと見なされます。
A prefix/SRv6 Locator that is advertised by a single node and without an AC-bit is considered node-specific.
単一のノードによって宣伝され、ACビットなしで宣伝されているプレフィックス/SRV6ロケーターは、ノード固有と見なされます。
All the nodes advertising the same anycast SRv6 Locator MUST instantiate the exact same set of SIDs under that anycast SRv6 Locator. Failure to do so may result in traffic being dropped or misrouted.
同じAnycast SRV6ロケーターを宣伝するすべてのノードは、そのAnyCast SRV6ロケーターの下にまったく同じSIDSセットをインスタンス化する必要があります。そうしないと、トラフィックが削除または誤って削除される可能性があります。
The PrefixOptions field is common to the prefix reachability advertisements (i.e., the base OSPFv3 prefix LSA types defined in [RFC5340], the OSPFv3 Extended Prefix TLV types defined in [RFC8362]), and the SRv6 Locator TLV advertisements specified in Section 7.1 of this document. When a router originates both the prefix reachability advertisement and the SRv6 Locator advertisement for a given prefix, the router SHOULD advertise the same PrefixOptions bits in both advertisements. In the case of any inconsistency between the PrefixOptions advertised in the SRv6 Locator and in the prefix reachability advertisements, the ones advertised in the prefix reachability advertisement MUST be preferred.
プレフィキソップフィールドフィールドは、プレフィックスの到達可能性広告（つまり、[RFC5340]で定義されているベースOSPFV3プレフィックスLSAタイプ、OSPFV3が[RFC8362]で定義されたプレフィックスTLVタイプ）、およびSRV6ロケーターTLV広告に拡張されたプレフィックスTLVタイプ）に共通し、このセクション7.1のセクション7.1で指定されたSRV6ロケーターTLV広告書類。ルーターが特定のプレフィックスのプレフィックスReachability広告とSRV6ロケーター広告の両方を発信する場合、ルーターは両方の広告で同じプレフィックスオプションビットを宣伝する必要があります。SRV6ロケーターとプレフィックスReachability広告で宣伝されているプレフィキソップの矛盾の場合、プレフィックスのReachability広告に宣伝されている広告を優先する必要があります。
The SRv6 Locator LSA has a function code of 42. The S1/S2 bits are dependent on the desired flooding scope for the LSA. The flooding scope of the SRv6 Locator LSA depends on the scope of the advertised SRv6 Locator and is under the control of the advertising router. The U-bit will be set indicating that the LSA should be flooded even if it is not understood.
SRV6ロケーターLSAの関数コードは42です。S1/S2ビットは、LSAの目的の洪水範囲に依存します。SRV6ロケーターLSAの洪水範囲は、広告されたSRV6ロケーターの範囲に依存し、広告ルーターの管理下にあります。Uビットは、LSAが理解されていなくても、LSAを浸水させるべきであることを示す設定されます。
Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router, and they are distinguished by their Link State IDs (which are chosen arbitrarily by the originating router).
複数のSRV6ロケーターLSAはOSPFV3ルーターによって宣伝され、リンク状態ID（発信元のルーターによって任意に選択されます）によって区別されます。
The format of the SRv6 Locator LSA is shown below:
SRV6ロケーターLSAの形式を以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |U|S12| Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Figure 3: SRv6 Locator LSA
図3：SRV6ロケーターLSA
The format of the TLVs within the body of the SRv6 Locator LSA is the same as the format used by [RFC3630]. The variable TLV section consists of one or more nested TLV tuples. Nested TLVs are also referred to as sub-TLVs. The format of each TLV is:
SRV6ロケーターLSAの本体内のTLVの形式は、[RFC3630]で使用されている形式と同じです。変数TLVセクションは、1つ以上のネストされたTLVタプルで構成されています。ネストされたTLVは、サブTLVとも呼ばれます。各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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6 Locator LSA TLV Format
図4：SRV6ロケーターLSA TLV形式
The Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of 0). The TLV is padded to 4-octet alignment; padding is not included in the Length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For example, a 1-byte value would have the Length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. The padding is composed of zeros.
長さのフィールドは、オクテットの値部分の長さを定義します（したがって、値部分がないTLVは0の長さになります）。TLVは4-OCTETアライメントにパッドで埋められています。パディングは長さフィールドに含まれていません（したがって、3オクテットの値は3の長さですが、TLVの合計サイズは8オクテットになります）。ネストされたTLVも32ビットアライメントされています。たとえば、1バイト値の長さフィールドは1に設定され、3オクテットのパディングがTLVの値部分の最後に追加されます。パディングはゼロで構成されています。
The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA that is used to advertise an SRv6 Locator, its attributes, and SIDs associated with it. Multiple SRv6 Locator TLVs MAY be advertised in each SRv6 Locator LSA. However, since the S12 bits define the flooding scope, the LSA flooding scope has to satisfy the application-specific requirements for all the locators included in a single SRv6 Locator LSA.
SRV6ロケーターTLVは、SRV6ロケーターLSAのトップレベルTLVであり、SRV6ロケーター、その属性、およびそれに関連するSIDを宣伝するために使用されます。複数のSRV6ロケーターTLVが各SRV6ロケーターLSAに宣伝される場合があります。ただし、S12ビットは洪水範囲を定義するため、LSAフラッディングスコープは、単一のSRV6ロケーターLSAに含まれるすべてのロケーターのアプリケーション固有の要件を満たす必要があります。
When multiple SRv6 Locator TLVs are received from a given router in an SRv6 Locator LSA for the same locator, the receiver MUST use the first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for the same locator appears in multiple SRv6 Locator LSAs that have different flooding scopes, the TLV in the SRv6 Locator LSA with the area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for the same locator appears in multiple SRv6 Locator LSAs that have the same flooding scope, the TLV in the SRv6 Locator LSA with the numerically smallest Link State ID MUST be used, and subsequent instances of the TLV MUST be ignored.
同じロケーターのSRV6ロケーターLSAの特定のルーターから複数のSRV6ロケーターTLVが受信される場合、レシーバーはLSAでTLVの最初の発生を使用する必要があります。同じロケーターのSRV6ロケーターTLVが異なる洪水スコープを持つ複数のSRV6ロケーターLSAに表示される場合、エリアスコープのある洪水スコープを備えたSRV6ロケーターLSAのTLVを使用する必要があります。同じロケーターのSRV6ロケーターTLVが同じ洪水スコープを持つ複数のSRV6ロケーターLSAに表示される場合、数値的に最小のリンク状態IDを持つSRV6ロケーターLSAのTLVを使用する必要があり、TLVのその後のインスタンスを無視する必要があります。
The format of the SRv6 Locator TLV is shown below:
SRV6ロケーター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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Algorithm | Locator Length| PrefixOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator (up to 16 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
Figure 5: SRv6 Locator TLV
図5：SRV6ロケーターTLV
where:
ただし：
Type:
タイプ：
2-octet field. The value for this type is 1.
2-OCTETフィールド。このタイプの値は1です。
Length:
長さ：
2-octet field. The total length (in octets) of the value portion of the TLV, including nested sub-TLVs.
2-OCTETフィールド。ネストされたサブTLVを含むTLVの値部分の総長さ（オクテット）。
Route Type:
ルートタイプ：
1:
1：
Intra-Area
エリア内
2:
2：
Inter-Area
エリア間
3:
3：
AS External Type 1
外部タイプ1として
4:
4：
AS External Type 2
外部タイプ2として
5:
5：
NSSA External Type 1
NSSA外部タイプ1
6:
6：
NSSA External Type 2
NSSA外部タイプ2
1-octet field. The type of the locator route. The only supported types are the ones listed below, and the SRv6 Locator TLV MUST be ignored on receipt of any other type. 1: Intra-Area 2: Inter-Area 3: AS External Type 1 4: AS External Type 2 5: NSSA External Type 1 6: NSSA External Type 2
1-OCTETフィールド。ロケータールートのタイプ。サポートされている唯一のタイプは以下にリストされているタイプであり、SRV6ロケーターTLVは、他のタイプを受け取ったときに無視する必要があります。1：エリア内2：エリア間3：外部タイプ1 4：外部タイプ2として5：NSSA外部タイプ1 6：NSSA外部タイプ2
Algorithm:
アルゴリズム：
1-octet field. The algorithm associated with the SRv6 Locator. Algorithm values are defined in the "IGP Algorithm Types" registry [RFC8665].
1-OCTETフィールド。SRV6ロケーターに関連付けられたアルゴリズム。アルゴリズム値は、「IGPアルゴリズムタイプ」レジストリ[RFC8665]で定義されます。
Locator Length:
ロケーターの長さ：
1-octet field. Specifies the length of the locator prefix as the number of locator bits from the range (1-128).
1-OCTETフィールド。ロケータープレフィックスの長さを、範囲からのロケータービットの数（1-128）として指定します。
PrefixOptions:
プレフィキソプティオン：
1-octet field. Specifies the prefix options bits/ flags as specified in [RFC5340] and further extended by [RFC8362] and Section 6 of this document.
1-OCTETフィールド。[RFC5340]で指定されているように、このドキュメントの[RFC8362]とセクション6でさらに拡張されたプレフィックスオプションビット/フラグを指定します。
Metric:
メトリック：
4-octet field. The metric value associated with the SRv6 Locator. The metric value of 0xFFFFFFFF MUST be considered as unreachable.
4-OCTETフィールド。SRV6ロケーターに関連付けられたメトリック値。0xffffffffのメートル値は、到達不能と見なされる必要があります。
Locator:
ロケータ：
1-16 octets. This field encodes the advertised SRv6 Locator as an IPv6 Prefix as specified in Appendix A.4.1 of [RFC5340].
1-16オクテット。このフィールドは、[RFC5340]の付録A.4.1で指定されているように、広告されたSRV6ロケーターをIPv6プレフィックスとしてエンコードします。
Sub-TLVs:
サブTLV：
Used to advertise sub-TLVs that provide additional attributes for the given SRv6 Locator and SRv6 SIDs associated with the SRv6 Locator.
特定のSRV6ロケーターとSRV6ロケーターに関連付けられたSRV6 SIDに追加の属性を提供するサブTLVを宣伝するために使用されます。
The following OSPFv3 Extended-LSA sub-TLVs corresponding to the Extended Prefix LSAs are also applicable for use as sub-TLVs of the SRv6 Locator TLV using code points as specified in Section 13.9:
拡張プレフィックスLSAに対応する次のOSPFV3拡張LSAサブTLVは、セクション13.9で指定されているようにコードポイントを使用して、SRV6ロケーターTLVのサブTLVとして使用するために適用されます。
* IPv6-Forwarding-Address sub-TLV [RFC8362]
* IPv6-Forwarding-Address sub-tlv [rfc8362]
* Route-Tag sub-TLV [RFC8362]
* ルートタグサブTLV [RFC8362]
* Prefix Source OSPF Router-ID sub-TLV [RFC9084]
* プレフィックスソースospf router-id sub-tlv [rfc9084]
* Prefix Source Router Address sub-TLV [RFC9084]
* プレフィックスソースルーターアドレスSub-TLV [RFC9084]
The SRv6 End SID sub-TLV is a sub-TLV of the SRv6 Locator TLV in the SRv6 Locator LSA (defined in Section 7). It is used to advertise the SRv6 SIDs belonging to the router along with their associated Endpoint behaviors. SIDs associated with adjacencies are advertised as described in Section 9. Every SRv6-enabled OSPFv3 router SHOULD advertise at least one SRv6 SID associated with an End behavior for itself as specified in [RFC8986], although it MAY omit doing so if that node is not going to be used as a Segment Endpoint (e.g., for TE or Topology Independent Loop-Free Alternate (TI-LFA)) by any SR Source Node.
SRV6 END SID SUB-TLVは、SRV6ロケーターLSAのSRV6ロケーターTLVのサブTLVです（セクション7で定義）。これは、それに関連するエンドポイント動作とともに、ルーターに属するSRV6 SIDを宣伝するために使用されます。隣接に関連するSIDはセクション9で説明されているように宣伝されています。すべてのSRV6対応OSPFV3ルーターは、[RFC8986]で指定されているように、それ自体の最終挙動に関連する少なくとも1つのSRV6 SIDを宣伝する必要がありますが、ノードがそうでない場合はそうすることができます。SRソースノードによってセグメントエンドポイント（たとえば、TEまたはトポロジに依存しないループフリーの代替（TI-LFA）など）として使用されます。
SRv6 End SIDs inherit the algorithm from the parent locator. The SRv6 End SID MUST be allocated from its associated locator. SRv6 End SIDs that are NOT allocated from the associated locator MUST be ignored.
SRV6 END SIDSは、親ロケーターからアルゴリズムを継承します。SRV6 END SIDは、関連するロケーターから割り当てなければなりません。関連するロケーターから割り当てられないSRV6 END SIDは無視する必要があります。
The router MAY advertise multiple instances of the SRv6 End SID sub-TLV within the SRv6 Locator TLV -- one for each of the SRv6 SIDs to be advertised. When multiple SRv6 End SID sub-TLVs are received in the SRv6 Locator TLV from a given router for the same SRv6 SID value, the receiver MUST use the first occurrence of the sub-TLV in the SRv6 Locator TLV.
ルーターは、SRV6ロケーターTLV内のSRV6 END SID SUB-TLVの複数のインスタンスを宣伝する場合があります。複数のSRV6 END SIDサブTLVが、同じSRV6 SID値の特定のルーターからSRV6ロケーターTLVで受信される場合、受信者はSRV6ロケーターTLVでSUB-TLVの最初の発生を使用する必要があります。
The format of the SRv6 End SID sub-TLV is shown below
srv6 end sid sub-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SRv6 End SID Sub-TLV
図6：SRV6 END SID SUB-TLV
where:
ただし：
Type:
タイプ：
2-octet field. The value for this type is 1.
2-OCTETフィールド。このタイプの値は1です。
Length:
長さ：
2-octet field. The total length (in octets) of the value portion of the sub-TLV, including its nested sub-TLVs.
2-OCTETフィールド。ネストされたサブTLVを含む、サブTLVの値部分の合計長（オクテット）。
Flags:
フラグ：
1-octet field. Specifies the flags associated with the SID. No flags are currently defined, and this field MUST be set to 0 on transmission and MUST be ignored on receipt.
1-OCTETフィールド。SIDに関連付けられたフラグを指定します。現在、フラグは定義されていません。このフィールドは、送信時に0に設定する必要があり、受信時に無視する必要があります。
Reserved:
予約済み：
1-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
1-OCTETフィールド。送信時に0に設定する必要があり、受領時に無視する必要があります。
Endpoint Behavior:
エンドポイントの動作：
2-octet field. The Endpoint behavior code point for this SRv6 SID as defined in [RFC8986]. Supported behavior values for this sub-TLV are defined in Section 11 of this document. Unsupported or unrecognized behavior values are ignored by the receiver.
2-OCTETフィールド。[RFC8986]で定義されているこのSRV6 SIDのエンドポイントの動作コードポイント。このサブTLVのサポートされている動作値は、このドキュメントのセクション11で定義されています。サポートされていないまたは認識されていない動作値は、受信者によって無視されます。
SID:
シド：
16-octet field. This field encodes the advertised SRv6 SID.
16-OCTETフィールド。このフィールドは、宣伝されているSRV6 SIDをエンコードします。
Sub-TLVs:
サブTLV：
Used to advertise sub-TLVs that provide additional attributes for the given SRv6 SID.
指定されたSRV6 SIDに追加の属性を提供するサブTLVを宣伝するために使用されます。
The SRv6 Endpoint behaviors defined in [RFC8986] include certain behaviors that are specific to links or adjacencies. The most basic of these (which is critical for link-state routing protocols like OSPFv3) is the End.X behavior, which is an instruction to forward to a specific neighbor on a specific link. These SRv6 SIDs and others that are defined in [RFC8986], which are specific to links or adjacencies, need to be advertised to OSPFv3 routers within an area to steer SRv6 traffic over a specific link or adjacency.
[RFC8986]で定義されているSRV6エンドポイントの動作には、リンクまたは隣接に固有の特定の動作が含まれます。これらの中で最も基本的なもの（OSPFV3のようなリンク状態ルーティングプロトコルにとって重要です）は、特定のリンクで特定の隣人に転送するための命令であるEnd.xの動作です。リンクまたは隣接に固有の[RFC8986]で定義されているこれらのSRV6 SIDおよびその他は、特定のリンクまたは隣接するSRV6トラフィックを操縦するために、エリア内のOSPFV3ルーターに宣伝する必要があります。
Therefore, SRv6 SIDs that are specific to a particular neighbor, such as End.X, are not advertised as a sub-TLVs of the SRv6 Locator TLV. Instead, they are advertised via two different optional sub-TLVs of the E-Router-Link TLV defined in [RFC8362]:
したがって、end.xなどの特定の隣人に固有のSRV6 SIDは、SRV6ロケーターTLVのサブTLVとして宣伝されていません。代わりに、[RFC8362]で定義されているEルーターリンクTLVの2つの異なるオプションのサブTLVを介して宣伝されています。
SRv6 End.X SID sub-TLV:
srv6 end.x sid sub-tlv：
Used for OSPFv3 adjacencies over point-to-point or point-to-multipoint links and for the adjacency to the Designated Router (DR) over broadcast and Non-Broadcast-Multi-Access (NBMA) links.
ポイントツーポイントまたはポイントツーマルチポイントリンクを介したOSPFV3の隣接に、およびブロードキャストおよび非ブロードキャストマルチアクセス（NBMA）リンクを介した指定されたルーター（DR）の隣接に使用されます。
SRv6 LAN End.X SID sub-TLV:
srv6 lan end.x sid sub-tlv：
Used for OSPFv3 adjacencies on broadcast and NBMA links to the Backup DR and DR-Other neighbors. This sub-TLV includes the OSPFv3 Router-ID of the neighbor and thus allows for an instance of this sub-TLV for each neighbor to be explicitly advertised as a sub-TLV of the E-Router-Link TLV for the same link.
ブロードキャストのOSPFV3隣接に使用され、NBMAはバックアップDRおよびDR-Other Neighborsにリンクします。このサブTLVには、隣接のOSPFV3ルーターIDが含まれているため、各近隣のこのサブTLVのインスタンスを、同じリンクのeルーターリンクTLVのサブTLVとして明示的に宣伝することができます。
Every SRv6-enabled OSPFv3 router SHOULD instantiate at least one unique SRv6 End.X SID corresponding to each of its neighbors, although it MAY omit doing so if features like TE or TI-LFA that require End.X SID are not in use. A router MAY instantiate more than one SRv6 End.X SID for a single neighbor. The same SRv6 End.X SID MAY be advertised for more than one neighbor. Thus, multiple instances of the SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs MAY be advertised within the E-Router-Link TLV for a single link.
すべてのSRV6対応のOSPFV3ルーターは、それぞれに対応する少なくとも1つの一意のSRV6 END.X SIDをインスタンス化する必要がありますが、END.X SIDを必要とするTEやTI-LFAなどの機能が使用されていない場合は、そうすることができます。ルーターは、単一の隣人用に複数のsrv6 end.x sidをインスタンス化する場合があります。同じsrv6 end.x sidは、複数の隣人に対して宣伝される場合があります。したがって、SRV6 END.X SIDおよびSRV6 LAN END.X SIDサブTLVの複数のインスタンスは、単一のリンクのEルーターリンクTLV内で宣伝される場合があります。
All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a locator with the matching algorithm that is advertised by the same OSPFv3 router in an SRv6 Locator TLV. End.X SIDs that do not meet this requirement MUST be ignored. This ensures that the OSPFv3 router advertising the End.X or LAN End.X SID is also advertising its corresponding locator with the algorithm that will be used for computing paths destined to the SID.
すべてのend.xおよびlan end.x sidsは、SRV6ロケーターTLVの同じOSPFV3ルーターによって宣伝されている一致するアルゴリズムを備えたロケーターのサブネットに接続する必要があります。この要件を満たさないEnd.x SIDは無視する必要があります。これにより、end.xまたはlan end.x Sidを宣伝するOSPFV3ルーターが、SIDに向けたパスの計算に使用されるアルゴリズムで、対応するロケーターを宣伝することが保証されます。
The format of the SRv6 End.X SID sub-TLV is shown below:
srv6 end.x sid sub-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SRv6 End.X SID Sub-TLV
図7：SRV6 END.X SID SUB-TLV
where:
ただし：
Type:
タイプ：
2-octet field. The value for this type is 31.
2-OCTETフィールド。このタイプの値は31です。
Length:
長さ：
2-octet field. The total length (in octets) of the value portion of the sub-TLV, including its nested sub-TLVs.
2-OCTETフィールド。ネストされたサブTLVを含む、サブTLVの値部分の合計長（オクテット）。
Endpoint Behavior:
エンドポイントの動作：
2-octet field. The Endpoint behavior code point for this SRv6 SID as defined in [RFC8986]. Supported behavior values for this sub-TLV are defined in Section 11 of this document. Unsupported or unrecognized behavior values are ignored by the receiver.
2-OCTETフィールド。[RFC8986]で定義されているこのSRV6 SIDのエンドポイントの動作コードポイント。このサブTLVのサポートされている動作値は、このドキュメントのセクション11で定義されています。サポートされていないまたは認識されていない動作値は、受信者によって無視されます。
Flags:
フラグ：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
B-Flag:
b-flag：
Backup Flag. If set, the SID refers to a path that is eligible for protection.
バックアップフラグ。設定されている場合、SIDは保護の対象となるパスを指します。
S-Flag:
s-flag：
Set Flag. When set, the S-Flag indicates that the End.X SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well).
フラグを設定します。設定すると、s-flagはend.x sidが一連の隣接を指すことを示します（したがって、他の隣接にも割り当てられる場合があります）。
P-Flag:
P-Flag：
Persistent Flag. If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap.
永続的なフラグ。設定されている場合、SIDは永続的に割り当てられます。つまり、SID値はルーターの再起動とセッション/インターフェイスフラップ全体で一貫しています。
Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.
他のフラグは定義されておらず、将来の使用のために予約されています。それらは送信時に0に設定する必要があり、受領時に無視する必要があります。
1-octet field. The flags are defined as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P| Reserved| +-+-+-+-+-+-+-+-+ B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection. S-Flag: Set Flag. When set, the S-Flag indicates that the End.X SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well). P-Flag: Persistent Flag. If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap. Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.
1-OCTETフィールド。フラグは次のように定義されています：0 1 2 3 4 5 6 7------- | B | S | P |予約済み|-------- B -FLAG：バックアップフラグ。設定されている場合、SIDは保護の対象となるパスを指します。S-Flag：フラグを設定します。設定すると、s-flagはend.x sidが一連の隣接を指すことを示します（したがって、他の隣接にも割り当てられる場合があります）。P-Flag：永続的なフラグ。設定されている場合、SIDは永続的に割り当てられます。つまり、SID値はルーターの再起動とセッション/インターフェイスフラップ全体で一貫しています。他のフラグは定義されておらず、将来の使用のために予約されています。それらは送信時に0に設定する必要があり、受領時に無視する必要があります。
Reserved1:
予約1：
1-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
1-OCTETフィールド。送信時に0に設定する必要があり、受領時に無視する必要があります。
Algorithm:
アルゴリズム：
1-octet field. The algorithm associated with the SRv6 Locator from which the SID is allocated. Algorithm values are defined in the "IGP Algorithm Types" registry [RFC8665].
1-OCTETフィールド。SIDが割り当てられるSRV6ロケーターに関連付けられたアルゴリズム。アルゴリズム値は、「IGPアルゴリズムタイプ」レジストリ[RFC8665]で定義されます。
Weight:
重さ：
1-octet field. Its value represents the weight of the End.X SID for load-balancing. The use of the weight is defined in [RFC8402].
1-OCTETフィールド。その値は、負荷分散のためのend.x sidの重みを表します。重量の使用は[RFC8402]で定義されています。
Reserved2:
予約2：
2-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
2-OCTETフィールド。送信時に0に設定する必要があり、受領時に無視する必要があります。
SID:
シド：
16-octet field. This field encodes the advertised SRv6 SID.
16-OCTETフィールド。このフィールドは、宣伝されているSRV6 SIDをエンコードします。
Sub-TLVs:
サブTLV：
Used to advertise sub-TLVs that provide additional attributes for the given SRv6 End.X SID.
指定されたSRV6 END.X SIDに追加の属性を提供するサブTLVを宣伝するために使用されます。
The format of the SRv6 LAN End.X SID sub-TLV is as shown below:
srv6 lan end.x sid sub-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SRv6 LAN End.X SID Sub-TLV
図8：SRV6 LAN END.X SID SUB-TLV
where:
ただし：
Type:
タイプ：
2-octet field. The value for this type is 32.
2-OCTETフィールド。このタイプの値は32です。
Length:
長さ：
2-octet field. The total length (in octets) of the value portion of the sub-TLV, including its nested sub-TLVs.
2-OCTETフィールド。ネストされたサブTLVを含む、サブTLVの値部分の合計長（オクテット）。
Endpoint Behavior:
エンドポイントの動作：
2-octet field. The code point for the Endpoint behavior for this SRv6 SID as defined in Section 9.2 of [RFC8986].
2-OCTETフィールド。[RFC8986]のセクション9.2で定義されているこのSRV6 SIDのエンドポイント動作のコードポイント。
Flags:
フラグ：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
B-Flag:
b-flag：
Backup Flag. If set, the SID refers to a path that is eligible for protection.
バックアップフラグ。設定されている場合、SIDは保護の対象となるパスを指します。
S-Flag:
s-flag：
Set Flag. When set, the S-Flag indicates that the End.X SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well).
フラグを設定します。設定すると、s-flagはend.x sidが一連の隣接を指すことを示します（したがって、他の隣接にも割り当てられる場合があります）。
P-Flag:
P-Flag：
Persistent Flag. If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap.
永続的なフラグ。設定されている場合、SIDは永続的に割り当てられます。つまり、SID値はルーターの再起動とセッション/インターフェイスフラップ全体で一貫しています。
Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.
他のフラグは定義されておらず、将来の使用のために予約されています。それらは送信時に0に設定する必要があり、受領時に無視する必要があります。
1-octet field. The flags are defined as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P| Reserved| +-+-+-+-+-+-+-+-+ B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection. S-Flag: Set Flag. When set, the S-Flag indicates that the End.X SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well). P-Flag: Persistent Flag. If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap. Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt.
1-OCTETフィールド。フラグは次のように定義されています：0 1 2 3 4 5 6 7------- | B | S | P |予約済み|-------- B -FLAG：バックアップフラグ。設定されている場合、SIDは保護の対象となるパスを指します。S-Flag：フラグを設定します。設定すると、s-flagはend.x sidが一連の隣接を指すことを示します（したがって、他の隣接にも割り当てられる場合があります）。P-Flag：永続的なフラグ。設定されている場合、SIDは永続的に割り当てられます。つまり、SID値はルーターの再起動とセッション/インターフェイスフラップ全体で一貫しています。他のフラグは定義されておらず、将来の使用のために予約されています。それらは送信時に0に設定する必要があり、受領時に無視する必要があります。
Reserved1:
予約1：
1-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
1-OCTETフィールド。送信時に0に設定する必要があり、受領時に無視する必要があります。
Algorithm:
アルゴリズム：
1-octet field. The algorithm associated with the SRv6 Locator from which the SID is allocated. Algorithm values are defined in the "IGP Algorithm Types" registry [RFC8665].
1-OCTETフィールド。SIDが割り当てられるSRV6ロケーターに関連付けられたアルゴリズム。アルゴリズム値は、「IGPアルゴリズムタイプ」レジストリ[RFC8665]で定義されます。
Weight:
重さ：
1-octet field. Its value represents the weight of the End.X SID for load balancing. The use of the weight is defined in [RFC8402].
1-OCTETフィールド。その値は、負荷分散のためのend.x sidの重みを表します。重量の使用は[RFC8402]で定義されています。
Reserved2:
予約2：
2-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
2-OCTETフィールド。送信時に0に設定する必要があり、受領時に無視する必要があります。
Neighbor Router-ID:
NeighborRouter-ID：
4-octet field. It specifies the OSPFv3 Router-ID of the neighbor.
4-OCTETフィールド。隣人のOSPFV3ルーターIDを指定します。
SID:
シド：
16-octet field. This field encodes the advertised SRv6 SID.
16-OCTETフィールド。このフィールドは、宣伝されているSRV6 SIDをエンコードします。
Sub-TLVs:
サブTLV：
Used to advertise sub-TLVs that provide additional attributes for the given SRv6 SID.
指定されたSRV6 SIDに追加の属性を提供するサブTLVを宣伝するために使用されます。
The SRv6 SID Structure sub-TLV is used to advertise the structure of the SRv6 SID as defined in [RFC8986]. It is used as an optional sub-TLV of the following:
SRV6 SID構造Sub-TLVは、[RFC8986]で定義されているように、SRV6 SIDの構造を宣伝するために使用されます。以下のオプションのサブTLVとして使用されます。
* SRv6 End SID sub-TLV (refer to Section 8)
* SRV6 END SID SUB-TLV（セクション8を参照）
* SRv6 End.X SID sub-TLV (refer to Section 9.1)
* srv6 end.x sid sub-tlv（セクション9.1を参照）
* SRv6 LAN End.X SID sub-TLV (refer to Section 9.2)
* srv6 lan end.x sid sub-tlv（セクション9.2を参照）
The sub-TLV has the following format:
Sub-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SRv6 SID Structure Sub-TLV
図9：SRV6 SID構造Sub-TLV
where:
ただし：
Type:
タイプ：
2-octet field. The value for this type is 30.
2-OCTETフィールド。このタイプの値は30です。
Length:
長さ：
2-octet field. The value MUST be 4.
2-OCTETフィールド。値は4でなければなりません。
LB Length:
LBの長さ：
1-octet field. SRv6 SID Locator Block length in bits.
1-OCTETフィールド。srv6 sidロケーターブロック長さのブロック長。
LN Length:
lnの長さ：
1-octet field. SRv6 SID Locator Node length in bits.
1-OCTETフィールド。SRV6 SIDロケーターノード長さのビット。
Function Length:
関数の長さ：
1-octet field. SRv6 SID Function length in bits.
1-OCTETフィールド。SRV6 SID関数のビットの長さ。
Argument Length:
引数の長さ：
1-octet field. SRv6 SID Argument length in bits.
1-OCTETフィールド。srv6 sidビットの引数長。
The SRv6 SID Structure sub-TLV MUST NOT appear more than once in its parent sub-TLV. If it appears more than once in its parent sub-TLV, the parent sub-TLV MUST be ignored by the receiver.
SRV6 SID構造サブTLVは、親サブTLVに複数回表示してはなりません。親Sub-TLVで複数回表示される場合、親サブTLVは受信機によって無視されなければなりません。
The sum of all four sizes advertised in SRv6 SID Structure sub-TLV MUST be less than or equal to 128 bits. If the sum of all four sizes advertised in the SRv6 SID Structure sub-TLV is larger than 128 bits, the parent TLV or sub-TLV MUST be ignored by the receiver.
SRV6 SID構造サブTLVで宣伝されている4つのサイズすべての合計は、128ビット以下でなければなりません。SRV6 SID構造Sub-TLVで宣伝されている4つのサイズすべての合計が128ビットより大きい場合、親TLVまたはSub-TLVはレシーバーによって無視する必要があります。
The SRv6 SID Structure sub-TLV is intended for informational use by the control and management planes. It MUST NOT be used at a transit node (as defined in [RFC8754]) for forwarding packets. As an example, this information could be used for the following:
SRV6 SID Structure Sub-TLVは、制御および管理機による情報使用を目的としています。パケットを転送するために（[RFC8754]で定義されている）トランジットノードで使用してはなりません。例として、この情報は以下に使用できます。
* Validation of SRv6 SIDs being instantiated in the network and advertised via OSPFv3. These can be learned by controllers via BGP-LS [RFC9514] and then monitored for conformance to the SRv6 SID allocation scheme chosen by the operator as described in Section 3.2 of [RFC8986].
* ネットワークにインスタンス化され、OSPFV3を介して宣伝されているSRV6 SIDの検証。これらは、BGP-LS [RFC9514]を介してコントローラーによって学習でき、[RFC8986]のセクション3.2で説明されているように、オペレーターが選択したSRV6 SID割り当てスキームへの適合性を監視することができます。
* Verification and the automation for securing the SRv6 domain by provisioning filtering rules at SR domain boundaries as described in Section 5 of [RFC8754].
* [RFC8754]のセクション5で説明されているように、SRドメイン境界でフィルタリングルールをプロビジョニングすることにより、SRV6ドメインを保護するための検証と自動化。
The details of these potential applications are outside the scope of this document.
これらの潜在的なアプリケーションの詳細は、このドキュメントの範囲外です。
Endpoint behaviors are defined in [RFC8986]. The code points for the Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry of [RFC8986]. This section lists the Endpoint behaviors and their code points, which MAY be advertised by OSPFv3 and the sub-TLVs in which each type MAY appear.
エンドポイントの動作は[RFC8986]で定義されています。エンドポイントの動作のコードポイントは、[RFC8986]の「SRV6エンドポイント動作」レジストリで定義されます。このセクションには、エンドポイントの動作とそのコードポイントをリストします。これは、OSPFV3と各タイプが表示される可能性のあるサブTLVによって宣伝される場合があります。
+===================+===================+=====+=======+===========+
| Endpoint Behavior | Endpoint Behavior | End | End.X | LAN End.X |
| | Code Point | SID | SID | SID |
+===================+===================+=====+=======+===========+
| End (PSP, USP, | 1-4, 28-31 | Y | N | N |
| USD) | | | | |
+-------------------+-------------------+-----+-------+-----------+
| End.X (PSP, USP, | 5-8, 32-35 | N | Y | Y |
| USD) | | | | |
+-------------------+-------------------+-----+-------+-----------+
| End.DX6 | 16 | N | Y | Y |
+-------------------+-------------------+-----+-------+-----------+
| End.DX4 | 17 | N | Y | Y |
+-------------------+-------------------+-----+-------+-----------+
| End.DT6 | 18 | Y | N | N |
+-------------------+-------------------+-----+-------+-----------+
| End.DT4 | 19 | Y | N | N |
+-------------------+-------------------+-----+-------+-----------+
| End.DT64 | 20 | Y | N | N |
+-------------------+-------------------+-----+-------+-----------+
Table 1: SRv6 Endpoint Behaviors in OSPFv3
表1：OSPFV3のSRV6エンドポイントの動作
This document introduces extensions to the OSPFv3 protocol and, as such, does not affect existing security considerations for OSPFv3 as documented in [RFC5340]. [RFC7166] describes an alternative and improved authentication mechanism to IPsec for OSPFv3. The use of authentication is RECOMMENDED for OSPFv3 deployment.
このドキュメントでは、[RFC5340]で文書化されているように、OSPFV3プロトコルへの拡張機能を導入しているため、OSPFV3の既存のセキュリティ上の考慮事項には影響しません。[RFC7166]は、OSPFV3のIPSECに対する代替および改善された認証メカニズムを説明しています。OSPFV3の展開には、認証の使用が推奨されます。
Reception of a malformed TLV or sub-TLV SHOULD be counted and/or logged in a rate-limited manner for further analysis.
不正なTLVまたはSub-TLVの受信は、さらなる分析のためにレートに制限された方法でカウントおよび/またはログインする必要があります。
This document describes the OSPFv3 extensions required to support SR over an IPv6 data plane. The security considerations for SR are discussed in [RFC8402]. [RFC8986] defines the SRv6 Network Programming concept and specifies the main SR behaviors to enable the creation of interoperable overlays. The security considerations from that document apply as well.
このドキュメントでは、IPv6データプレーンでSRをサポートするために必要なOSPFV3拡張機能について説明します。SRのセキュリティ上の考慮事項については、[RFC8402]で説明します。[RFC8986]は、SRV6ネットワークプログラミングの概念を定義し、主要なSR動作を指定して、相互運用可能なオーバーレイの作成を可能にします。そのドキュメントからのセキュリティ上の考慮事項も当てはまります。
The advertisement of an incorrect MSD value may have negative consequences. See [RFC8476] for additional considerations.
誤ったMSD値の広告には負の結果が生じる可能性があります。追加の考慮事項については、[RFC8476]を参照してください。
Security concerns associated with the setting of the O-flag are described in [RFC9259].
O-Flagの設定に関連するセキュリティの懸念は、[RFC9259]で説明されています。
Security concerns associated with the usage of Flexible Algorithms are described in [RFC9350].
柔軟なアルゴリズムの使用に関連するセキュリティの懸念は、[RFC9350]で説明されています。
Per this document, IANA has made allocations in OSPF- and OSPFv3-related registries and created new registries, as detailed in the following subsections.
この文書によると、IANAはOSPFおよびOSPFV3関連のレジストリで割り当てを行い、以下のサブセクションで詳述されているように、新しいレジストリを作成しました。
IANA has allocated the following code point in the "OSPF Router Information (RI) TLVs" registry within the "Open Shortest Path First (OSPF) Parameters" registry group:
IANAは、「OSPFルーター情報（RI）TLVS」レジストリの「Oppest Shortest Path First（OSPF）パラメーター」レジストリグループ内の「OSPFルーター情報（RI）TLVS」レジストリに次のコードポイントを割り当てました。
+=======+===================+=====================+
| Value | TLV Name | Reference |
+=======+===================+=====================+
| 20 | SRv6 Capabilities | RFC 9513, Section 2 |
+-------+-------------------+---------------------+
Table 2
IANA has allocated the following code point in the "OSPFv3 LSA Function Codes" registry within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group:
IANAは、「OSPFV3 LSA関数コード」レジストリに次のコードポイントを割り当てました。
+=======+========================+=====================+
| Value | LSA Function Code Name | Reference |
+=======+========================+=====================+
| 42 | SRv6 Locator LSA | RFC 9513, Section 7 |
+-------+------------------------+---------------------+
Table 3
IANA has allocated the following code point in the "OSPFv3 Prefix Options (8 bits)" registry within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group:
IANAは、「OSPFV3プレフィックスオプション（8ビット）」レジストリの「OSPFV3プレフィックスオプション（8ビット）」に次のコードポイントを割り当てました。
+=======+=============+=====================+
| Value | Description | Reference |
+=======+=============+=====================+
| 0x80 | AC-bit | RFC 9513, Section 6 |
+-------+-------------+---------------------+
Table 4
IANA has created a new subregistry named "OSPFv3 SRv6 Capabilities TLV Flags" within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group to control the assignment of bits 0 to 15 in the Flags field of the OSPFv3 SRv6 Capabilities TLV specified in this document. The registration procedure is "Standards Action" as defined in [RFC8126].
IANAは、「Open Shortest Path First V3（OSPFV3）パラメーター」レジストリグループ内で「OSPFV3 SRV6機能TLVフラグ」という名前の新しいサブレジストリを作成し、OSPFV3 SRV6能力TLVのフラグフィールドで0〜15の割り当てを制御して、指定されています。このドキュメント。登録手順は、[RFC8126]で定義されている「標準アクション」です。
The following assignment has been made per this document:
このドキュメントに従って、次の割り当てが行われています。
+=====+=============+=====================+
| Bit | Description | Reference |
+=====+=============+=====================+
| 1 | O-flag | RFC 9513, Section 2 |
+-----+-------------+---------------------+
Table 5
IANA has created a new subregistry named "OSPFv3 SRv6 End SID Sub-TLV Flags" within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group to control the assignment of bits 0 to 7 in the Flags field of the OSPFv3 SRv6 End SID sub-TLV specified in this document. The registration procedure is "Standards Action" as defined in [RFC8126].
IANAは、「Open Shortest Path First V3（OSPFV3）パラメーター」内で「OSPFV3 SRV6 END SID SUB-TLVフラグ」という名前の新しいサブレジストリを作成しました。このドキュメントで指定されたSID Sub-TLV。登録手順は、[RFC8126]で定義されている「標準アクション」です。
No assignments are made by this document.
このドキュメントによって課題はありません。
IANA has created a new subregistry named "OSPFv3 SRv6 Adjacency SID Sub-TLV Flags" within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group to control the assignment of bits 0 to 7 in the Flags field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN End.X SID sub-TLVs specified in this document. The registration procedure is "Standards Action" as defined in [RFC8126].
IANAは、「Openest Path first V3（OSPFV3）パラメーター」内で「OSPFV3 SRV6隣接SIDサブTLVフラグ」という名前の新しいサブレジストリを作成しました。.x SIDおよびOSPFV3 SRV6 LAN END.X SIDサブTLVは、このドキュメントで指定されています。登録手順は、[RFC8126]で定義されている「標準アクション」です。
The following assignments have been made per this document:
このドキュメントに従って、次の割り当てが行われています。
+=====+=============+================================+
| Bit | Description | Reference |
+=====+=============+================================+
| 0 | B-flag | RFC 9513, Sections 9.1 and 9.2 |
+-----+-------------+--------------------------------+
| 1 | S-flag | RFC 9513, Sections 9.1 and 9.2 |
+-----+-------------+--------------------------------+
| 2 | P-flag | RFC 9513, Sections 9.1 and 9.2 |
+-----+-------------+--------------------------------+
Table 6
IANA has allocated the following code points in the "OSPFv3 Extended-LSA Sub-TLVs" registry within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group:
IANAは、「OPPFV3拡張LSAサブTLVS」レジストリに「OPPFV3拡張LSAサブTLV」に次のコードポイントを割り当てました。
+=======+====================+======+=======================+
| Value | Description | L2BM | Reference |
+=======+====================+======+=======================+
| 30 | SRv6 SID Structure | Y | RFC 9513, Section 10 |
+-------+--------------------+------+-----------------------+
| 31 | SRv6 End.X SID | Y | RFC 9513, Section 9.1 |
+-------+--------------------+------+-----------------------+
| 32 | SRv6 LAN End.X SID | Y | RFC 9513, Section 9.2 |
+-------+--------------------+------+-----------------------+
Table 7
IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA TLVs" within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group to define top-level TLVs for the OSPFv3 SRv6 Locator LSA. The initial assignments are below:
IANAは、OSPFV3 SRV6ロケーターLSAのトップレベルTLVを定義する「Openest Path First V3（OSPFV3）パラメーター」レジストリグループ内で「OSPFV3 SRV6ロケーターLSA TLV」という名前の新しいサブレジストリを作成しました。最初の割り当ては以下にあります。
+=======+==============+=======================+
| Value | Description | Reference |
+=======+==============+=======================+
| 0 | Reserved | RFC 9513 |
+-------+--------------+-----------------------+
| 1 | SRv6 Locator | RFC 9513, Section 7.1 |
+-------+--------------+-----------------------+
Table 8
Types in the range 0-32767 are allocated via IETF Review or IESG Approval [RFC8126].
範囲0-32767のタイプは、IETFレビューまたはIESG承認[RFC8126]によって割り当てられます。
Types in the range 32768-33023 are Reserved for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
範囲32768-33023のタイプは、実験用に予約されています。これらはIANAに登録されておらず、RFCSで言及してはなりません。
Types in the range 33024-45055 are to be assigned on a First Come First Served (FCFS) basis.
範囲33024-45055のタイプは、最初の提供（FCFS）ベースで割り当てられます。
Types in the range 45056-65535 are not to be assigned at this time. Before any assignments can be made in the 45056-65535 range, there MUST be an IETF specification that specifies IANA Considerations that cover the range being assigned.
範囲45056-65535のタイプは、現時点では割り当てられません。45056-65535範囲で割り当てを行う前に、割り当てられている範囲をカバーするIANAの考慮事項を指定するIETF仕様が必要です。
IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA Sub-TLVs" within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group to define sub-TLVs at any level of nesting for the SRv6 Locator LSA TLV. The initial assignment are below:
IANAは、「Openest Path first V3（OSPFV3）パラメーター」レジストリグループ内で「OSPFV3 SRV6ロケーターLSAサブTLV」という名前の新しいサブレジストリを作成し、SRV6ロケーターLSA TLVの任意のレベルでサブTLVを定義します。最初の割り当ては以下にあります。
+=======+=========================+=====================+
| Value | Description | Reference |
+=======+=========================+=====================+
| 0 | Reserved | RFC 9513 |
+-------+-------------------------+---------------------+
| 1 | SRv6 End SID | RFC 9513, Section 8 |
+-------+-------------------------+---------------------+
| 2 | IPv6-Forwarding-Address | [RFC8362]; RFC |
| | | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 3 | Route-Tag | [RFC8362]; RFC |
| | | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 4 | Prefix Source OSPF | [RFC9084]; RFC |
| | Router-ID | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 5 | Prefix Source Router | [RFC9084]; RFC |
| | Address | 9513, Section 7.2 |
+-------+-------------------------+---------------------+
| 10 | SRv6 SID Structure | RFC 9513, |
| | | Section 10 |
+-------+-------------------------+---------------------+
Table 9
Types in the range 0-32767 are allocated via IETF Review or IESG Approval [RFC8126].
範囲0-32767のタイプは、IETFレビューまたはIESG承認[RFC8126]によって割り当てられます。
Types in the range 32768-33023 are Reserved for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
範囲32768-33023のタイプは、実験用に予約されています。これらはIANAに登録されておらず、RFCSで言及してはなりません。
Types in the range 33024-45055 are to be assigned on a FCFS basis.
範囲33024-45055のタイプは、FCFSベースで割り当てられます。
Types in the range 45056-65535 are not to be assigned at this time. Before any assignments can be made in the 45056-65535 range, there MUST be an IETF specification that specifies IANA Considerations that cover the range being assigned.
範囲45056-65535のタイプは、現時点では割り当てられません。45056-65535範囲で割り当てを行う前に、割り当てられている範囲をカバーするIANAの考慮事項を指定するIETF仕様が必要です。
The following note has been added to this registry to ensure that any document requesting allocations in this registry for sub-TLVs of any of the OSPFv3 SRv6 Locator TLVs checks if allocations are also applicable for the "OSPFv3 Extended-LSA Sub-TLVs" registry.
次のメモがこのレジストリに追加され、OSPFV3 SRV6ロケーターTLVのサブTLVのこのレジストリの割り当てを要求するドキュメントが「OSPFV3拡張LSAサブTLVS」レジストリにも割り当てが適用されるかどうかを確認することを確認します。
Note: Allocations made in this registry for sub-TLVs that are associated with OSPFv3 SRv6 Locator TLVs MUST be evaluated for their applicability as OSPFv3 Extended-LSA sub-TLVs, which are required to be allocated in the "OSPFv3 Extended-LSA Sub-TLVs" registry.
注：OSPFV3 SRV6ロケーターTLVに関連するサブTLVのこのレジストリで行われた割り当ては、OSPFV3拡張LSA Sub-TLVSとして適用性を評価する必要があります。「レジストリ。
IANA has added the following note to the "OSPFv3 Extended-LSA Sub-TLVs" registry within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group. The purpose of this note is to ensure that any document requesting allocations in this registry for sub-TLVs of any of the OSPFv3 Extended Prefix TLVs checks if allocations are also applicable for the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry defined in this document.
IANAは、「Oppentest Path First V3（OSPFV3）パラメーター」レジストリグループ内の「OSPFV3拡張LSAサブTLVS」レジストリに次のメモを追加しました。このメモの目的は、このドキュメントで定義されている「OSPFV3 SRV6ロケーターLSAサブTLVS」レジストリに割り当てが適用されているかどうか、OSPFV3拡張プレフィックスTLVSチェックのいずれかのSub-TLVのこのレジストリの割り当てを要求するドキュメントを確保することです。。
Note: Allocations made in this registry for sub-TLVs that are associated with OSPFv3 Extended TLVs related to prefix advertisements MUST be evaluated for their applicability as OSPFv3 SRv6 Locator sub-TLVs, which are required to be allocated in the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry.
注：このレジストリで行われたプレフィックス広告に関連するOSPFV3拡張TLVに関連するサブTLVの割り当ては、OSPFV3 SRV6ロケーターSub-TLVとして適用されると評価する必要があります。-tlvs "レジストリ。
[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>.
[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>.
[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>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[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>.
[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>.
[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>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions
for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
December 2019, <https://www.rfc-editor.org/info/rfc8666>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9084] Wang, A., Lindem, A., Dong, J., Psenak, P., and K.
Talaulikar, Ed., "OSPF Prefix Originator Extensions",
RFC 9084, DOI 10.17487/RFC9084, August 2021,
<https://www.rfc-editor.org/info/rfc9084>.
[RFC9259] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
Chen, "Operations, Administration, and Maintenance (OAM)
in Segment Routing over IPv6 (SRv6)", RFC 9259,
DOI 10.17487/RFC9259, June 2022,
<https://www.rfc-editor.org/info/rfc9259>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M.,
Bernier, D., and B. Decraene, "Border Gateway Protocol -
Link State (BGP-LS) Extensions for Segment Routing over
IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December
2023, <https://www.rfc-editor.org/info/rfc9514>.
The authors would like to acknowledge the contributions of Dean Cheng in the early draft versions of this document. The authors would like to thank Ran Chen and Detao Zhao for their suggestions related to the extension of PrefixOptions for the signaling of the anycast property.
著者は、このドキュメントの初期ドラフトバージョンでディーンチェンの貢献を認めたいと考えています。著者は、Anycastプロパティのシグナリングのためのプレフィキソップの拡張に関する提案について、Ran ChenとDetao Zhaoに感謝したいと思います。
The authors would like to thank Chenzichao, Dirk Goethals, Baalajee S, Yingzhen Qu, Shraddha Hegde, Dhruv Dhody, Martin Vigoureux, and Reese Enghardt for their review and comments on this document. The authors would like to thank Acee Lindem for his detailed shepherd review and feedback for improvement of this document. The authors would like to thank John Scudder for his AD review and suggestions to improve this document.
著者は、この文書に関するレビューとコメントについて、チェンツィチャオ、ダークゲッタルズ、バラジーS、Yingzhen QU、Shraddha Hegde、Dhruv Dhody、Martin Vigoureux、Reese Enghardtに感謝したいと思います。著者は、この文書の改善のための詳細な羊飼いのレビューとフィードバックについて、Acee Lindemに感謝したいと思います。著者は、この文書を改善するための広告レビューと提案について、John Scudderに感謝したいと思います。
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Zhibo Hu
Huawei Technologies
Email: huzhibo@huawei.com
Ketan Talaulikar (editor)
Cisco Systems
India
Email: ketant.ietf@gmail.com
Peter Psenak
Cisco Systems
Slovakia
Email: ppsenak@cisco.com