[要約] この文書は、通常のIPv4およびIPv6フォワーディングと一緒にIGP Flexible Algorithmを使用できるように拡張します。
Internet Engineering Task Force (IETF) W. Britto
Request for Comments: 9502 S. Hegde
Category: Standards Track P. Kaneriya
ISSN: 2070-1721 R. Shetty
R. Bonica
Juniper Networks
P. Psenak
Cisco Systems
November 2023
This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding.
このドキュメントは、IGPフレキシブルアルゴリズムを拡張して、通常のIPv4およびIPv6転送で使用できるようにします。
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/rfc9502.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9502で取得できます。
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
2. Requirements Language
3. Use Case Example
4. Advertising Flexible Algorithm Definitions (FADs)
5. Advertising IP Flexible Algorithm Participation
5.1. The IS-IS IP Algorithm Sub-TLV
5.2. The OSPF IP Algorithm TLV
6. Advertising IP Flexible Algorithm Reachability
6.1. The IS-IS IPv4 Algorithm Prefix Reachability TLV
6.2. The IS-IS IPv6 Algorithm Prefix Reachability TLV
6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV
6.3.1. The OSPFv2 IP Forwarding Address Sub-TLV
6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV
6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV
7. Calculating of IP Flexible Algorithm Paths
8. IP Flexible Algorithm Forwarding
9. Deployment Considerations
10. Protection
11. IANA Considerations
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgements
Authors' Addresses
An IGP Flexible Algorithm allows IGPs to compute constraint-based paths. The base IGP Flexible Algorithm specification describes how it is used with Segment Routing (SR) data planes: SR MPLS and SRv6.
IGPフレキシブルアルゴリズムにより、IGPは制約ベースのパスを計算できます。ベースIGPフレキシブルアルゴリズム仕様は、セグメントルーティング（SR）データプレーンで使用する方法：SR MPLSおよびSRV6を説明します。
An IGP Flexible Algorithm as specified in [RFC9350] computes a constraint-based path to:
[RFC9350]で指定されているIGPフレキシブルアルゴリズムは、次のような制約ベースのパスを計算します。
* All Flexible-Algorithm-specific Prefix Segment Identifiers (SIDs) [RFC8402].
* すべての柔軟なアルゴリズム固有のプレフィックスセグメント識別子（SIDS）[RFC8402]。
* All Flexible-Algorithm-specific SRv6 Locators [RFC8986].
* すべての柔軟なアルゴリズム固有のSRV6ロケーター[RFC8986]。
Therefore, Flexible Algorithm cannot be deployed in the absence of SR or SRv6.
したがって、柔軟なアルゴリズムは、SRまたはSRV6の非存在下で展開することはできません。
This document extends Flexible Algorithm, allowing it to compute paths to IPv4 and IPv6 prefixes.
このドキュメントは柔軟なアルゴリズムを拡張し、IPv4およびIPv6プレフィックスへのパスを計算できるようにします。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
In this section, we illustrate one use case that motivates this specification: if a specific service can be identified by an IP address, traffic to it can use constraint-based paths computed according to this specification.
このセクションでは、この仕様を動機付ける1つのユースケースを示します。特定のサービスをIPアドレスで識別できる場合、Trafficはこの仕様に従って計算された制約ベースのパスを使用できます。
The System architecture for the 5G System [TS.23.501-3GPP] describes the N3 interface between gNodeB and UPF (User Plane Function).
5Gシステム[Ts.23.501-3GPP]のシステムアーキテクチャは、GNODEBとUPF（ユーザープレーン機能）の間のN3インターフェイスを説明しています。
Mobile networks are becoming more and more IP-centric. Each end-user session from a gNodeB can be destined to a specific UPF based on the session requirements. For example, some sessions require high bandwidth, while others need to be routed along the lowest latency path. Each UPF is assigned a unique IP address. As a result, traffic for different sessions is destined to a different destination IP address.
モバイルネットワークはますますIP中心になりつつあります。GNODEBからの各エンドユーザーセッションは、セッション要件に基づいて特定のUPFに運命づけられます。たとえば、一部のセッションには高い帯域幅が必要ですが、他のセッションは最低のレイテンシパスに沿ってルーティングする必要があります。各UPFには、一意のIPアドレスが割り当てられます。その結果、さまざまなセッションのトラフィックは、異なる宛先IPアドレスに運命づけられます。
The IP address allocated to the UPF can be associated with an algorithm. The mobile user traffic is then forwarded along the path based on the algorithm-specific metric and constraints. As a result, traffic can be sent over a path that is optimized for minimal latency or highest bandwidth. This mechanism is used to achieve Service Level Agreement (SLA) appropriate for a user session.
UPFに割り当てられたIPアドレスは、アルゴリズムに関連付けられます。モバイルユーザートラフィックは、アルゴリズム固有のメトリックと制約に基づいてパスに沿って転送されます。その結果、最小レイテンシまたは最高帯域幅のために最適化されたパスにトラフィックを送信できます。このメカニズムは、ユーザーセッションに適したサービスレベル契約（SLA）を達成するために使用されます。
To guarantee loop-free forwarding, all routers that participate in a Flex-Algorithm MUST agree on the Flexible Algorithm Definition (FAD).
ループフリーの転送を保証するには、フレックスアルゴリズムに参加するすべてのルーターが柔軟なアルゴリズム定義（FAD）に同意する必要があります。
Selected nodes within the IGP domain MUST advertise FADs as described in Sections 5, 6, and 7 of [RFC9350].
IGPドメイン内の選択されたノードは、[RFC9350]のセクション5、6、および7で説明されているようにFADを宣伝する必要があります。
A node may use various algorithms when calculating paths to nodes and prefixes. Algorithm values are defined in the "IGP Algorithm Types" registry [IANA-ALG].
ノードは、ノードとプレフィックスへのパスを計算するときに、さまざまなアルゴリズムを使用する場合があります。アルゴリズム値は、「IGPアルゴリズムタイプ」レジストリ[IANA-ALG]で定義されます。
Only a node that is participating in a Flex-Algorithm is:
Flex-Algorithmに参加しているノードのみが次のとおりです。
* Able to compute a path for such Flex-Algorithm
* このようなフレックスアルゴリズムのパスを計算できます
* Part of the topology for such Flex-Algorithm
* このようなフレックスアルゴリズムのトポロジの一部
Flexible Algorithm participation MUST be advertised for each Flexible Algorithm data plane independently, as specified in [RFC9350]. Using Flexible Algorithm for regular IPv4 and IPv6 prefixes represents an independent Flexible Algorithm data plane; as such, the Flexible Algorithm participation for the IP Flexible Algorithm data plane MUST be signaled independently of any other Flexible Algorithm data plane (e.g., SR).
[RFC9350]で指定されているように、柔軟なアルゴリズムの参加は、個別に個別に宣伝する必要があります。通常のIPv4およびIPv6プレフィックスに柔軟なアルゴリズムを使用することは、独立した柔軟なアルゴリズムデータプレーンを表します。そのため、IPフレキシブルアルゴリズムデータプレーンの柔軟なアルゴリズムの参加は、他の柔軟なアルゴリズムデータプレーン（SRなど）とは無関係にシグナルを受信する必要があります。
All routers in an IGP domain participate in default algorithm 0. Advertisement of participation in IP Flexible Algorithm does not impact the router participation in default algorithm 0.
IGPドメインのすべてのルーターは、デフォルトアルゴリズム0に関与します。IPフレキシブルアルゴリズムへの参加の広告は、デフォルトアルゴリズム0のルーター参加に影響を与えません。
Advertisement of participation in IP Flexible Algorithm does not impact the router participation signaled for other data planes. For example, it is possible that a router participates in a particular Flex-Algorithm for the IP data plane but does not participate in the same Flex-Algorithm for the SR data plane.
IP Flexibleアルゴリズムへの参加の広告は、他のデータプレーンで合図されたルーターの参加に影響を与えません。たとえば、ルーターはIPデータプレーンの特定のFlex-Algorithmに参加する可能性がありますが、SRデータプレーンの同じFlex-Algorithmに参加しない可能性があります。
The following sections describe how the IP Flexible Algorithm participation is advertised in IGP protocols.
次のセクションでは、IPフレキシブルアルゴリズムの参加がIGPプロトコルでどのように宣伝されているかについて説明します。
The IS-IS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV of the IS-IS Router Capability TLV [RFC7981] and has the following format:
IS-IS [ISO10589] IPアルゴリズムSub-TLVは、IS-ISルーター機能TLV [RFC7981]のサブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IS-IS IP Algorithm Sub-TLV
図1：IS-IS IPアルゴリズムサブTLV
Type (1 octet):
タイプ（1オクテット）：
IP Algorithm Sub-TLV (Value 29)
IPアルゴリズムSub-TLV（値29）
Length (1 octet):
長さ（1オクテット）：
Variable
変数
Algorithm (1 octet):
アルゴリズム（1オクテット）：
Value from 128 to 255
128から255までの値
The IP Algorithm Sub-TLV MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. Therefore, the S bit in the Router Capability TLV, in which the IP Algorithm Sub-TLV is advertised, MUST NOT be set.
IPアルゴリズムSub-TLVは、レベル全体で伝播する必要があり、レベルの境界を越えて宣伝してはなりません。したがって、IPアルゴリズムSub-TLVが宣伝されているルーター機能TLVのSビットを設定してはなりません。
The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised more than once at a given level. A router receiving multiple IP Algorithm sub-TLVs from the same originator MUST select the first advertisement in the lowest-numbered Link State PDU (LSP), and subsequent instances of the IP Algorithm Sub-TLV MUST be ignored.
IPアルゴリズムSub-TLVはオプションです。特定のレベルで複数回宣伝してはなりません。同じオリジネーターから複数のIPアルゴリズムサブTLVを受信するルーターは、最低数のリンク状態PDU（LSP）で最初の広告を選択する必要があり、その後のIPアルゴリズムSub-TLVのその後のインスタンスは無視する必要があります。
Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored by the receiver. This situation SHOULD be logged as an error.
フレックスアルゴリズム範囲外のアルゴリズム（128-255）は、受信機によって無視する必要があります。この状況はエラーとしてログに記録する必要があります。
The IP Flex-Algorithm participation advertised in the IS-IS IP Algorithm Sub-TLV is topology independent. When a router advertises participation in the IS-IS IP Algorithm Sub-TLV, the participation applies to all topologies in which the advertising node participates.
IS-IS IPアルゴリズムSub-TLVに宣伝されているIP Flex-Algorithmの参加は、トポロジが独立しています。ルーターがIS-IS IPアルゴリズムサブTLVへの参加を広告すると、参加は広告ノードが参加するすべてのトポロジに適用されます。
The OSPF [RFC2328] IP Algorithm TLV is a top-level TLV of the Router Information Opaque Link State Advertisement (LSA) [RFC7770] and has the following format:
OSPF [RFC2328] IPアルゴリズムTLVは、ルーター情報オパイクリンク状態広告（LSA）[RFC7770]のトップレベル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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm... | Algorithm n | |
+- -+
| |
+ +
Figure 2: OSPF IP Algorithm TLV
図2：OSPF IPアルゴリズムTLV
Type (2 octets):
タイプ（2オクテット）：
IP Algorithm TLV (21)
IPアルゴリズムTLV（21）
Length( 2 octets):
長さ（2オクテット）：
Variable
変数
Algorithm (1 octet):
アルゴリズム（1オクテット）：
Value from 128 to 255
128から255までの値
The IP Algorithm TLV is optional. It MUST only be advertised once in the Router Information LSA.
IPアルゴリズムTLVはオプションです。ルーター情報LSAで1回のみ宣伝する必要があります。
Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored by the receiver. This situation SHOULD be logged as an error.
フレックスアルゴリズム範囲外のアルゴリズム（128-255）は、受信機によって無視する必要があります。この状況はエラーとしてログに記録する必要があります。
When multiple IP Algorithm TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information LSA. If the IP Algorithm TLV appears in multiple Router Information LSAs that have different flooding scopes, the IP Algorithm TLV in the Router Information LSA with the area-scoped flooding scope MUST be used. If the IP Algorithm TLV appears in multiple Router Information LSAs that have the same flooding scope, the IP Algorithm TLV in the Router Information LSA with the numerically smallest Instance ID (Opaque ID for OSPFv2 or Link State ID for OSPFv3) MUST be used, and subsequent instances of the IP Algorithm TLV MUST be ignored.
複数のIPアルゴリズムTLVが特定のルーターから受信される場合、受信者はルーター情報LSAでTLVの最初の発生を使用する必要があります。IPアルゴリズムTLVが異なる洪水スコープを持つ複数のルーター情報LSAに表示される場合、ルーター情報LSAのIPアルゴリズムTLVを使用して、領域スコープのある洪水スコープを使用する必要があります。IPアルゴリズムTLVが同じ洪水スコープを持つ複数のルーター情報LSAに表示される場合、ルーター情報LSAのIPアルゴリズムTLVは、数値的に最小のインスタンスID（OSPFV2の不透明IDまたはOSPFV3のリンク状態ID）を使用し、使用する必要があります）を使用する必要があります。IPアルゴリズムTLVの後続インスタンスは無視する必要があります。
The Router Information LSA can be advertised at any of the defined flooding scopes (link, area, or Autonomous System (AS)). For the purpose of IP Algorithm TLV advertisement, area- or AS-scoped flooding is REQUIRED. The AS flooding scope SHOULD NOT be used unless local configuration policy on the originating router indicates domain-wide flooding.
ルーター情報LSAは、定義された洪水スコープ（リンク、面積、または自律システム（AS））のいずれかで宣伝できます。IPアルゴリズムTLV広告の目的のために、エリアまたはスコープのある洪水が必要です。起源のルーターに関するローカル構成ポリシーがドメイン全体の洪水を示していない限り、ASフラッドスコープは使用しないでください。
The IP Flexible Algorithm participation advertised in the OSPF IP Algorithm TLV is topology independent. When a router advertises participation in OSPF IP Algorithm TLV, the participation applies to all topologies in which the advertising node participates.
OSPF IPアルゴリズムTLVで宣伝されているIPフレキシブルアルゴリズムの参加は、トポロジが独立しています。ルーターがOSPF IPアルゴリズムTLVへの参加を広告すると、参加は広告ノードが参加するすべてのトポロジに適用されます。
To be able to associate the prefix with the Flex-Algorithm, the existing prefix reachability advertisements cannot be used, because they advertise the prefix reachability in default algorithm 0. Instead, new IP Flexible Algorithm reachability advertisements are defined in IS-IS and OSPF.
プレフィックスをフレックスアルゴリズムに関連付けるために、デフォルトアルゴリズム0でプレフィックスの到達可能性を宣伝するため、既存のプレフィックスリーチ可能性広告を使用することはできません。
The M-flag in the FAD is not applicable to IP Algorithm Prefixes. Any IP Algorithm Prefix advertisement includes the Algorithm and Metric fields. When an IP Algorithm Prefix is advertised between areas or domains, the metric field in the IP Algorithm Prefix advertisement MUST be used irrespective of the M-flag in the FAD advertisement.
FADのM-Flagは、IPアルゴリズムのプレフィックスには適用できません。IPアルゴリズムのプレフィックス広告には、アルゴリズムとメトリックフィールドが含まれます。IPアルゴリズムのプレフィックスが領域またはドメイン間で宣伝される場合、FAD広告のM-Flagに関係なく、IPアルゴリズムのプレフィックス広告のメトリックフィールドを使用する必要があります。
The IPv4 Algorithm Prefix Reachability top-level TLV is defined for advertising IPv4 Flexible Algorithm Prefix Reachability in IS-IS.
IPv4アルゴリズムのプレフィックスリーチビリティトップレベルTLVは、IS-ISでのIPv4フレキシブルアルゴリズムのプレフィックスリーチビリティの広告用に定義されています。
This new TLV shares the sub-TLV space defined for TLVs Advertising Prefix Reachability.
この新しいTLVは、TLVS広告のプレフィックスReghinability用に定義されているサブTLVスペースを共有します。
The IS-IS IPv4 Algorithm Prefix Reachability TLV has the following format:
IS-IS IPv4アルゴリズムのプレフィックスリーチビリティ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 | Rsvd | MTID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IS-IS IPv4 Algorithm Prefix Reachability TLV
図3：IS-IS IS IPv4アルゴリズムプレフィックスリーチビリティTLV
Type (1 octet):
タイプ（1オクテット）：
IPv4 Algorithm Prefix Reachability TLV (Value 126)
IPv4アルゴリズムプレフィックスリーチビリティTLV（値126）
Length (1 octet):
長さ（1オクテット）：
Variable based on number of prefix entries encoded
エンコードされたプレフィックスエントリの数に基づく変数
Rsvd (4 bits):
RSVD（4ビット）：
Reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt.
将来の使用のために予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
MTID (12 bits):
MTID（12ビット）：
Multitopology Identifier as defined in [RFC5120]. Note that the value 0 is legal.
[RFC5120]で定義されているマルチトポロジ識別子。値0は合法であることに注意してください。
Followed by one or more prefix entries of the form:
フォームの1つ以上のプレフィックスエントリが続きます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pfx Length | Prefix (variable)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-tlv-len | Sub-TLVs (variable) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IS-IS IPv4 Algorithm Prefix Reachability TLV
図4：IS-IS IS IPv4アルゴリズムプレフィックスリーチビリティTLV
Metric (4 octets):
メトリック（4オクテット）：
Metric information as defined in [RFC5305]
[RFC5305]で定義されているメトリック情報
Flags (1 octet):
フラグ（1オクテット）：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D| Reserved |
+-+-+-+-+-+-+-+-+
D-flag:
d-flag：
The D-flag is described as the "up/down bit" in Section 4.1 of [RFC5305]. When the Prefix is leaked from level 2 to level 1, the D bit MUST be set. Otherwise, this bit MUST be clear. Prefixes with the D bit set MUST NOT be leaked from level 1 to level 2. This is to prevent looping.
D-Flagは、[RFC5305]のセクション4.1の「アップ/ダウンビット」として説明されています。プレフィックスがレベル2からレベル1に漏れている場合、Dビットを設定する必要があります。それ以外の場合、このビットは明確でなければなりません。Dビットセットのプレフィックスは、レベル1からレベル2に漏れてはなりません。これは、ループを防ぐためです。
The remaining bits:
残りのビット：
Reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt.
将来の使用のために予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D| Reserved | +-+-+-+-+-+-+-+-+ D-flag: The D-flag is described as the "up/down bit" in Section 4.1 of [RFC5305]. When the Prefix is leaked from level 2 to level 1, the D bit MUST be set. Otherwise, this bit MUST be clear. Prefixes with the D bit set MUST NOT be leaked from level 1 to level 2. This is to prevent looping. The remaining bits: Reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt.
0 1 2 3 4 5 6 7 --------- | D |予約済み|------- D -Flag：D -Flagは[RFC5305]のセクション4.1の「アップ/ダウンビット」と呼ばれます。プレフィックスがレベル2からレベル1に漏れている場合、Dビットを設定する必要があります。それ以外の場合、このビットは明確でなければなりません。Dビットセットのプレフィックスは、レベル1からレベル2に漏れてはなりません。これは、ループを防ぐためです。残りのビット：将来の使用のために予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Algorithm (1 octet):
アルゴリズム（1オクテット）：
Associated Algorithm from 128 to 255
128から255までの関連するアルゴリズム
Prefix Len (1 octet):
プレフィックスレン（1オクテット）：
Prefix length measured in bits
ビットで測定されたプレフィックスの長さ
Prefix (variable length):
プレフィックス（変数長）：
Prefix mapped to Flex-Algorithm
Flex-Algorithmにマッピングされたプレフィックス
Optional Sub-TLV-length (1 octet):
オプションのsub-tlv-length（1オクテット）：
Number of octets used by sub-TLVs
サブTLVで使用されるオクテットの数
Optional sub-TLVs (variable length)
オプションのサブTLV（可変長）
If the Algorithms in the IS-IS IPv4 Algorithm Prefix Reachability TLV are outside the Flex-Algorithm range (128-255), the IS-IS IPv4 Algorithm Prefix Reachability TLV MUST be ignored by the receiver. This situation SHOULD be logged as an error.
IS-IS IPv4アルゴリズムのプレフィックスリーチビリティTLVのアルゴリズムがFlex-Algorithm範囲（128-255）の外側にある場合、IS-IS IPv4アルゴリズムのプレフィックスリーチビリティTLVは受信者によって無視する必要があります。この状況はエラーとしてログに記録する必要があります。
If a router receives multiple IPv4 Algorithm Prefix Reachability advertisements for the same prefix from the same originator, it MUST select the first advertisement in the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm Prefix Reachability advertisements for the same prefix.
ルーターが同じオリジネーターから同じプレフィックスの複数のIPv4アルゴリズムのプレフィックスの到達可能性広告を受信した場合、最も少ない番号LSPで最初の広告を選択し、同じプレフィックスのその後のIPv4アルゴリズムの到達可能性広告を無視する必要があります。
If a router receives multiple IPv4 Algorithm Prefix Reachability advertisements for the same prefix, from different originators, where all of them do not advertise the same algorithm, it MUST ignore all of them and MUST NOT install any forwarding entries based on these advertisements. This situation SHOULD be logged as an error.
ルーターが同じプレフィックスの複数のIPv4アルゴリズムの接頭辞のReachability Advertisementsを受信した場合、すべてのオリジネーターから同じアルゴリズムを宣伝していない異なるオリジネーターから、それらのすべてを無視する必要があり、これらの広告に基づいて転送エントリをインストールしてはなりません。この状況はエラーとしてログに記録する必要があります。
In cases where a prefix advertisement is received in both an IPv4 Prefix Reachability TLV [RFC5305] [RFC5120] and an IPv4 Algorithm Prefix Reachability TLV, the IPv4 Prefix Reachability advertisement MUST be preferred when installing entries in the forwarding plane.
IPv4プレフィックスReachability TLV [RFC5305] [RFC5120]とIPv4アルゴリズムのプレフィックスReachability TLVの両方でプレフィックス広告が受信される場合、転送面にエントリをインストールする際にIPv4プレフィックスリーチ可能性広告を優先する必要があります。
The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a distinct type. The type is 127.
IS-IS IPv6アルゴリズムのプレフィックスリーチビリティTLVは、個別のタイプを除いて、IS-IS IPv4アルゴリズムのプレフィックスリーチビリティTLVと同一です。タイプは127です。
If the Algorithms in the IS-IS IPv6 Algorithm Prefix Reachability TLV are outside the Flex-Algorithm range (128-255), the IS-IS IPv6 Algorithm Prefix Reachability TLV MUST be ignored by the receiver. This situation SHOULD be logged as an error.
IS-IS IPv6アルゴリズムプレフィックスリーチビリティTLVのアルゴリズムがFlex-Algorithm範囲（128-255）の外側にある場合、IS-IS IPv6アルゴリズムのプレフィックスリーチビリティTLVは受信者によって無視する必要があります。この状況はエラーとしてログに記録する必要があります。
If a router receives multiple IPv6 Algorithm Prefix Reachability advertisements for the same prefix from the same originator, it MUST select the first advertisement in the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm Prefix Reachability advertisements for the same prefix.
ルーターが同じオリジネーターから同じプレフィックスの複数のIPv6アルゴリズムのプレフィックスの到達可能性広告を受信した場合、最も少ない番号LSPで最初の広告を選択し、同じプレフィックスのその後のIPv6アルゴリズムの到達可能性広告を無視する必要があります。
If a router receives multiple IPv6 Algorithm Prefix Reachability advertisements for the same prefix, from different originators, where all of them do not advertise the same algorithm, it MUST ignore all of them and MUST NOT install any forwarding entries based on these advertisements. This situation SHOULD be logged as an error.
ルーターが、同じアルゴリズムをすべて宣伝しない異なるオリジネーターから、同じプレフィックスの複数のIPv6アルゴリズムのプレフィックスの到達可能性広告を受信した場合、それらのすべてを無視する必要があり、これらの広告に基づいて転送エントリをインストールしてはなりません。この状況はエラーとしてログに記録する必要があります。
In cases where a prefix advertisement is received in both an IPv6 Prefix Reachability TLV [RFC5308] [RFC5120] and an IPv6 Algorithm Prefix Reachability TLV, the IPv6 Prefix Reachability advertisement MUST be preferred when installing entries in the forwarding plane.
IPv6プレフィックスリーチビリティTLV [RFC5308] [RFC5120]とIPv6アルゴリズムのプレフィックスリーチビリティTLVの両方でプレフィックス広告が受信される場合、転送面にエントリをインストールする際にIPv6プレフィックスリーチ可能性広告を優先する必要があります。
In cases where a prefix advertisement is received in both an IS-IS SRv6 Locator TLV [RFC9352] and in IS-IS IPv6 Algorithm Prefix Reachability TLV, the receiver MUST ignore both of them and MUST NOT install any forwarding entries based on these advertisements. This situation SHOULD be logged as an error.
IS-IS SRV6ロケーターTLV [RFC9352]とIS-IS IS IPv6アルゴリズムの到達可能性TLVの両方でプレフィックス広告が受信される場合、レシーバーはそれらの両方を無視する必要があり、これらの広告に基づいて転送エントリをインストールしてはなりません。この状況はエラーとしてログに記録する必要があります。
A new sub-TLV of the OSPFv2 Extended Prefix TLV is defined for advertising IP Algorithm Prefix Reachability in OSPFv2, the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV.
OSPFV2拡張プレフィックスTLVの新しいサブTLVは、OSPFV2 IPアルゴリズムのプレフィックスリーチビリティサブTLVであるOSPFV2の広告IPアルゴリズムのプレフィックスリーチビリティに対して定義されています。
The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the following format:
OSPFV2 IPアルゴリズムのプレフィックスReghinability 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Algorithm | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OSPFv2 IP Algorithm Prefix Reachability Sub-TLV
図5：OSPFV2 IPアルゴリズムプレフィックスRECONIVALITY SUB-TLV
Type (2 octets):
タイプ（2オクテット）：
The value is 6
値は6です
Length (2 octets):
長さ（2オクテット）：
8
8
MT-ID (1 octet):
mt-id（1オクテット）：
Multi-Topology ID as defined in [RFC4915]
[rfc4915]で定義されているマルチトポロジID
Algorithm (1 octet):
アルゴリズム（1オクテット）：
Associated Algorithm from 128 to 255
128から255までの関連するアルゴリズム
Flags (1 octet):
フラグ（1オクテット）：
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+
|E| Reserved |
+-+-+-+-+-+-+-+-+-+
E bit:
eビット：
The same as the E bit defined in Appendix A.4.5 of [RFC2328].
[RFC2328]の付録A.4.5で定義されているEビットと同じ。
The remaining bits:
残りのビット：
Reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt.
将来の使用のために予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The following flags are defined: 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+ |E| Reserved | +-+-+-+-+-+-+-+-+-+ Where: E bit: The same as the E bit defined in Appendix A.4.5 of [RFC2328]. The remaining bits: Reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt.
次のフラグが定義されています：0 1 2 3 4 5 6 7 8-------- | E |予約済み|---------ここで：eビット：[RFC2328]の付録A.4.5で定義されているEビットと同じ。残りのビット：将来の使用のために予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Reserved (1 octet):
予約済み（1オクテット）：
SHOULD be set to 0 on transmission and MUST be ignored on reception.
トランスミッションで0に設定する必要があり、受信で無視する必要があります。
Metric (4 octets):
メトリック（4オクテット）：
The algorithm-specific metric value. The metric value of 0XFFFFFFFF MUST be considered unreachable.
アルゴリズム固有のメトリック値。0xffffffffのメートル値は、到達不能と見なされる必要があります。
If the Algorithms in the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV are outside the Flex-Algorithm range (128-255), the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored by the receiver. This situation SHOULD be logged as an error.
OSPFV2 IPアルゴリズムプレフィックスReghinability Sub-TLVのアルゴリズムがFlex-Algorithm範囲（128-255）の外側にある場合、OSPFV2 IPアルゴリズムのプレフィックスReghinability Sub-TLVは受信者によって無視する必要があります。この状況はエラーとしてログに記録する必要があります。
An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV MUST select the first advertisement of this sub-TLV and MUST ignore all remaining occurrences of this sub-TLV in the OSPFv2 Extended Prefix TLV.
複数のOSPFV2 IPアルゴリズムプレフィックスを受信するOSPFV2ルーターは、同じOSPFV2拡張プレフィックスTLVのReachability Sub-TLVを受信します。
An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix Reachability TLVs for the same prefix from different originators where all of them do not advertise the same algorithm MUST ignore all of them and MUST NOT install any forwarding entries based on these advertisements. This situation SHOULD be logged as an error.
複数のOSPFV2 IPアルゴリズムのプレフィックスを受信するOSPFV2ルーターは、すべてのオリジネーターから同じ接頭辞の到達可能性TLVをすべて同じアルゴリズムを宣伝しない場合、これらすべてを無視する必要があり、これらの広告に基づいて転送エントリをインストールしてはなりません。この状況はエラーとしてログに記録する必要があります。
In cases where a prefix advertisement is received in any of the LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv2 IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability advertisement for algorithm 0 MUST be used, and all occurrences of the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored.
Algorithm 0のプレフィックスリーチビリティとOSPFv2 IPアルゴリズムのReghinability Sub-TLVのプレフィックス広告のいずれかのLSAのいずれかでプレフィックス広告が受信される場合、アルゴリズムのプレフィックスリーチ性広告のみを使用する必要があり、OSOSPFV22のすべての出現のみが必要です。IPアルゴリズムのプレフィックスRechinability Sub-TLVは無視する必要があります。
When computing the IP Algorithm Prefix reachability in OSPFv2, only information present in the OSPFv2 Extended Prefix TLV MUST be used. There will not be any information advertised for the IP Algorithm Prefix in any of the OSPFv2 LSAs that advertise prefix reachability for algorithm 0. For the IP Algorithm Prefix, the OSPFv2 Extended Prefix TLV is used to advertise the prefix reachability, unlike for algorithm 0 prefixes, where the OSPFv2 Extended Prefix TLV is only used to advertise additional attributes -- but not the reachability itself.
OSPFv2でIPアルゴリズムプレフィックスの到達可能性を計算する場合、OSPFv2に存在する情報のみが拡張プレフィックスTLVを使用する必要があります。アルゴリズム0のプレフィックスリーチビリティを宣伝するOSPFV2 LSAのいずれかのIPアルゴリズムプレフィックスについて宣伝されている情報はありません。IPアルゴリズムプレフィックスの場合、AOSPFV2拡張プレフィックスTLVは、アルゴリズム0のプレフィックスの到達可能性を宣伝するために使用されます。、OSPFV2拡張プレフィックスTLVは、追加の属性を宣伝するためにのみ使用されますが、到達可能性そのものではありません。
A new sub-TLV of the OSPFv2 Extended Prefix TLV is defined for advertising IP Forwarding Address, the OSPFv2 IP Forwarding Address Sub-TLV.
OSPFV2拡張プレフィックスTLVの新しいサブTLVは、IP転送アドレス、OSPFV2 IP転送アドレスSub-TLVの広告用に定義されています。
The OSPFv2 IP Forwarding Address Sub-TLV has the following format:
OSPFV2 IP転送アドレス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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OSPFv2 IP Forwarding Address Sub-TLV
図6：OSPFV2 IP転送アドレスSub-TLV
Type (2 octets):
タイプ（2オクテット）：
The value is 7
値は7です
Length (2 octets):
長さ（2オクテット）：
4
4
Forwarding Address (4 octets):
転送アドレス（4オクテット）：
The same as defined in Appendix A.4.5 of [RFC2328]
[RFC2328]の付録A.4.5で定義されているのと同じ
The OSPFv2 IP Forwarding Address Sub-TLV MUST NOT be used for computing algorithm 0 prefix reachability and MUST be ignored for algorithm 0 prefixes.
OSPFV2 IP転送アドレスSUB-TLVは、アルゴリズム0プレフィックスの到達可能性を計算するために使用しないでください。アルゴリズム0プレフィックスでは無視する必要があります。
The OSPFv2 IP Forwarding Address Sub-TLV is optional. If it is not present, the forwarding address for computing the IP Algorithm Prefix reachability is assumed to be equal to 0.0.0.0.
OSPFV2 IP転送アドレスSUB-TLVはオプションです。存在しない場合、IPアルゴリズムプレフィックスの到達可能性を計算するための転送アドレスは0.0.0.0に等しいと想定されます。
The OSPFv2 IP Forwarding Address Sub-TLV is only applicable to AS External and Not-So-Stubby Area (NSSA) External route types. If the OSPFv2 IP Forwarding Address Sub-TLV is advertised in the OSPFv2 Extended Prefix TLV that has the Route Type field set to any other type, the OSPFv2 IP Forwarding Address Sub-TLV MUST be ignored.
OSPFV2 IPフォワーディングアドレスSub-TLVは、外部およびそれほど魅力的ではないエリア（NSSA）外部ルートタイプとしてのみ適用できます。OSPFV2 IP転送アドレスSUB-TLVが、ルートタイプフィールドが他のタイプに設定されているOSPFV2拡張プレフィックスTLVに宣伝されている場合、OSPFV2 IP転送アドレスSUB-TLVを無視する必要があります。
The OSPFv3 [RFC5340] IP Algorithm Prefix Reachability Sub-TLV is defined for advertisement of the IP Algorithm Prefix Reachability in OSPFv3.
OSPFV3 [RFC5340] IPアルゴリズムプレフィックスリーチビリティSub-TLVは、OSPFV3のIPアルゴリズムプレフィックスリーチビリティの広告のために定義されています。
The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of the following OSPFv3 TLVs defined in [RFC8362]:
OSPFV3 IPアルゴリズムのプレフィックスReghinability Sub-TLVは、[RFC8362]で定義された次のOSPFV3 TLVのサブTLVです。
* Intra-Area-Prefix TLV
* エリア内 - プレフィックスTLV
* Inter-Area-Prefix TLV
* エリア間型TLV
* External-Prefix TLV
* 外部-Prefix TLV
The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is shown below:
OSPFV3 IPアルゴリズムのプレフィックスReghinability 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: OSPFv3 IP Algorithm Prefix Reachability Sub-TLV
図7：OSPFV3 IPアルゴリズムプレフィックスRECOUNTIBALITY SUB-TLV
Where:
ただし：
Type (2 octets):
タイプ（2オクテット）：
The value is 35
値は35です
Length (2 octets):
長さ（2オクテット）：
8
8
Algorithm (1 octet):
アルゴリズム（1オクテット）：
Associated Algorithm from 128 to 255
128から255までの関連するアルゴリズム
Reserved (3 octets):
予約済み（3オクテット）：
SHOULD be set to 0 on transmission and MUST be ignored on reception.
トランスミッションで0に設定する必要があり、受信で無視する必要があります。
Metric (4 octets):
メトリック（4オクテット）：
The algorithm-specific metric value. The metric value of 0XFFFFFFFF MUST be considered unreachable.
アルゴリズム固有のメトリック値。0xffffffffのメートル値は、到達不能と見なされる必要があります。
If the Algorithms in the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV are outside the Flex-Algorithm range (128-255), the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored by the receiver. This situation SHOULD be logged as an error.
OSPFV3 IPアルゴリズムプレフィックスReghinability Sub-TLVのアルゴリズムがFlex-Algorithm範囲（128-255）の外側にある場合、OSPFV3 IPアルゴリズムのプレフィックスReghinability Sub-TLVは受信者によって無視する必要があります。この状況はエラーとしてログに記録する必要があります。
When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is present, the NU-bit in the PrefixOptions field of the parent TLV MUST be set. This is needed to prevent the OSPFv3 IP Algorithm Prefix Reachability advertisement from contributing to the base algorithm reachability. If the NU-bit in the PrefixOptions field of the parent TLV is not set, the OSPFv3 IP Algorithm Prefix Sub-TLV MUST be ignored by the receiver.
OSPFV3 IPアルゴリズムのプレフィックスReghinability Sub-TLVが存在する場合、親TLVのプレフィキソップフィールドのNUビットを設定する必要があります。これは、OSPFV3 IPアルゴリズムのプレフィックスReachability Advertisementが基本アルゴリズムの到達可能性に貢献するのを防ぐために必要です。親TLVのプレフィキソップフィールドフィールドのNU-BITが設定されていない場合、OSPFV3 IPアルゴリズムのプレフィックスSub-TLVはレシーバーによって無視する必要があります。
The metric value in the parent TLV is RECOMMENDED to be set to LSInfinity [RFC2328]. This recommendation is provided as a network troubleshooting convenience; if it is not followed, the protocol will still function correctly.
親TLVのメトリック値は、lsinfinity [rfc2328]に設定することをお勧めします。この推奨事項は、ネットワークのトラブルシューティングの利便性として提供されます。従わない場合、プロトコルは正しく機能します。
An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix Reachability Sub-TLVs in the same parent TLV MUST select the first advertisement of this sub-TLV and MUST ignore all remaining occurrences of this sub-TLV in the parent TLV.
同じ親TLVの複数のOSPFV3 IPアルゴリズムのプレフィックスReachability Sub-TLVを受信するOSPFV3ルーターは、このサブTLVの最初の広告を選択する必要があり、親TLVのこのサブTLVの残りのすべての発生を無視する必要があります。
An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix Reachability TLVs for the same prefix from different originators where all of them do not advertise the same algorithm MUST ignore all of them and MUST NOT install any forwarding entries based on these advertisements. This situation SHOULD be logged as an error.
複数のOSPFV3 IPアルゴリズムのプレフィックスを受信するOSPFV3ルーターは、同じアルゴリズムをすべて宣伝しない異なるオリジネーターから同じプレフィックスのリーチビリティTLVをすべて無視する必要があり、これらの広告に基づいて転送エントリをインストールしてはなりません。この状況はエラーとしてログに記録する必要があります。
In cases where a prefix advertisement is received in any of the LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv3 OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability advertisement for algorithm 0 MUST be used, and all occurrences of the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored.
Algorithm 0のプレフィックスリーチビリティとOSPFV3 OSOSPFV3 IPアルゴリズムのリーチビリティSub-TLVのプレフィックス広告のいずれかのLSAのいずれかでプレフィックス広告が受信される場合、Algorithm 0のプレフィックスリーチ可能性広告のみを使用する必要があり、すべての発生のすべての発生のみが必要です。OSPFV3 IPアルゴリズムのプレフィックスReghinability Sub-TLVは無視する必要があります。
In cases where a prefix advertisement is received in both an OSPFv3 SRv6 Locator TLV and in an OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, the receiver MUST ignore both of them and MUST NOT install any forwarding entries based on these advertisements. This situation SHOULD be logged as an error.
OSPFV3 SRV6ロケーターTLVの両方でプレフィックス広告が受信される場合、OSPFV3 IPアルゴリズムのプレフィックスリーチビリティSub-TLVの両方で、受信者はそれらの両方を無視する必要があり、これらの広告に基づいて転送エントリをインストールしてはなりません。この状況はエラーとしてログに記録する必要があります。
[RFC9350] defines the OSPF Flexible Algorithm ASBR Metric (FAAM) Sub-TLV that is used by an OSPFv2 or an OSPFv3 Area Border Router (ABR) to advertise a Flex-Algorithm-specific metric associated with the corresponding ASBR LSA.
[RFC9350]は、OSPFV2またはOSPFV3エリアボーダールーター（ABR）が使用するOSPFフレキシブルアルゴリズムASBRメトリック（FAAM）Sub-TLVを定義し、対応するASBR LSAに関連するFlex-AlgorithM特異的メトリックを宣伝します。
As described in [RFC9350], each data plane signals its participation independently. IP Flexible Algorithm participation is signaled independent of SR Flexible Algorithm participation. As a result, the calculated topologies for SR and IP Flexible Algorithm could be different. Such a difference prevents the usage of FAAM for the purpose of the IP Flexible Algorithm.
[rfc9350]で説明されているように、各データプレーンは独立して参加を指示します。IPフレキシブルアルゴリズムの参加は、SRの柔軟なアルゴリズムの参加とは無関係にシグナル伝えられます。その結果、SRとIPの柔軟なアルゴリズムの計算されたトポロジは異なる可能性があります。このような違いは、IPフレキシブルアルゴリズムの目的でFAAMの使用を防ぎます。
The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is defined for the advertisement of the IP Flex-Algorithm-specific metric associated with an ASBR by the ABR.
OSPF IP Flexible Algorithm ASBRメトリック（IPFAAM）Sub-TLVは、ABRによってASBRに関連付けられたIP Flex-Algorithm固有のメトリックの広告に対して定義されています。
The IPFAAM Sub-TLV is a sub-TLV of the:
IPFAAMサブTLVは、次のサブTLVです。
* OSPFv2 Extended Inter-Area ASBR TLV, as defined in [RFC9350]
* OSPFV2は[RFC9350]で定義されているように、エリア間ASBR TLVを拡張しました
* OSPFv3 Inter-Area-Router TLV, as defined in [RFC8362]
* [RFC8362]で定義されているOSPFV3インターエリアルーターTLV
The OSPF IPFAAM Sub-TLV has the following format:
OSPF IPFAAM 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: OSPF IP Flexible Algorithm ASBR Metric Sub-TLV
図8：OSPF IP Flexible Algorithm ASBR Metric Sub-TLV
Where:
ただし：
Type (2 octets):
タイプ（2オクテット）：
2 (allocated by IANA) for OSPFv2, 36 for OSPFv3
2（IANAによって割り当てられた）OSPFV2に、36 OSPFV3の場合
Length (2 octets):
長さ（2オクテット）：
8
8
Algorithm (1 octet):
アルゴリズム（1オクテット）：
Associated Algorithm from 128 to 255
128から255までの関連するアルゴリズム
Reserved (3 octets):
予約済み（3オクテット）：
SHOULD be set to 0 on transmission and MUST be ignored on reception
トランスミッションで0に設定する必要があり、受信で無視する必要があります
Metric (4 octets):
メトリック（4オクテット）：
The algorithm-specific metric value
アルゴリズム固有のメトリック値
If the Algorithms in the OSPF IP Flexible Algorithm ASBR Metric Sub-TLV are outside the Flex-Algorithm range (128-255), the OSPF IP Flexible Algorithm ASBR Metric Sub-TLV MUST be ignored by the receiver. This situation SHOULD be logged as an error.
OSPF IP Flexible Algorithm ASBRメトリックサブTLVのアルゴリズムがFlex-Algorithm範囲（128-255）の外側にある場合、OSPF IP Flexible Algorithm ASBRメトリックSub-TLVは受信者によって無視する必要があります。この状況はエラーとしてログに記録する必要があります。
The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM Sub-TLV defined in [RFC9350], but it is used to advertise IP Flexible Algorithm metric.
IPFAAM Sub-TLVの使用は、[RFC9350]で定義されているFAAM Sub-TLVの使用に似ていますが、IP Flexible Algorithmメトリックの宣伝に使用されます。
An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of any IP Flexible Algorithm ASBR reachability advertisement between areas.
OSPF ABRには、IP Flexible Algorithm ASBR Reachability Advertisementの一部として、OSPF IPFAAMサブTLVを領域間で含める必要があります。
The FAAM Sub-TLV as defined in [RFC9350] MUST NOT be used during IP Flexible Algorithm path calculation; the IPFAAM Sub-TLV MUST be used instead.
[RFC9350]で定義されているFAAM Sub-TLVは、IP柔軟なアルゴリズムパス計算中に使用してはなりません。代わりにIPFAAMサブTLVを使用する必要があります。
The IP Flexible Algorithm is considered as yet another data plane of the Flexible Algorithm as described in [RFC9350].
IPフレキシブルアルゴリズムは、[RFC9350]で説明されているように、フレキシブルアルゴリズムのさらに別のデータプレーンと見なされます。
Participation in the IP Flexible Algorithm is signaled as described in Section 5 and is specific to the IP Flexible Algorithm data plane.
IPフレキシブルアルゴリズムへの参加は、セクション5で説明されているようにシグナル伝えられ、IP柔軟なアルゴリズムデータプレーンに固有です。
Calculation of IP Flexible Algorithm paths follows what is described in [RFC9350]. This computation uses the IP Flexible Algorithm data plane participation and is independent of the Flexible Algorithm calculation done for any other Flexible Algorithm data plane (e.g., SR, SRv6).
IPフレキシブルアルゴリズムパスの計算は、[RFC9350]で説明されているものに従います。この計算は、IPフレキシブルアルゴリズムデータプレーンの参加を使用し、他の柔軟なアルゴリズムデータプレーン（SR、SRV6など）に対して行われた柔軟なアルゴリズム計算とは無関係です。
The IP Flexible Algorithm data plane only considers participating nodes during the Flexible Algorithm calculation. When computing paths for a given Flex-Algorithm, all nodes that do not advertise participation for such IP Flex-Algorithm, as described in Section 5, MUST be pruned from the topology.
IPフレキシブルアルゴリズムデータプレーンは、柔軟なアルゴリズムの計算中に参加ノードのみを考慮します。特定のフレックスアルゴリズムのパスを計算する場合、セクション5で説明されているように、そのようなIPフレックスアルゴリズムの参加を宣伝しないすべてのノードは、トポロジから剪定する必要があります。
The IP Algorithm Prefix Reachability advertisement as described in Section 5 includes the MTID value that associates the prefix with a specific topology. Algorithm Prefix Reachability advertisement also includes an Algorithm value that explicitly associates the prefix with a specific Flex-Algorithm. The paths to the prefix MUST be calculated using the specified Flex-Algorithm in the associated topology.
セクション5で説明されているIPアルゴリズムのプレフィックスReachability広告には、プレフィックスを特定のトポロジに関連付けるMTID値が含まれています。アルゴリズムプレフィックスReachability Advertisementには、プレフィックスを特定のFlex-Algorithmに明示的に関連付けるアルゴリズム値も含まれています。プレフィックスへのパスは、関連するトポロジの指定されたフレックスアルゴリズムを使用して計算する必要があります。
Forwarding entries for the IP Flex-Algorithm prefixes advertised in IGPs MUST be installed in the forwarding plane of the receiving IP Flex-Algorithm prefix capable routers when they participate in the associated topology and algorithm. Forwarding entries for IP Flex-Algorithm prefixes associated with Flex-Algorithms in which the node is not participating MUST NOT be installed in the forwarding plane.
IGPSで宣伝されているIPフレックスアルゴリズムプレフィックスの転送エントリは、関連するトポロジとアルゴリズムに参加するときに受信IPフレックスアルゴリズムプレフィックス対応ルーターの転送面にインストールする必要があります。ノードが参加していないフレックスアルゴリズムに関連付けられたIPフレックスアルゴリズムプレフィックスの転送エントリは、転送面にインストールしてはなりません。
IGP Flexible Algorithm can be used by many data planes. The original specification was done for SR and SRv6; this specification adds IP as another data plane that can use IGP Flexible Algorithm. Other data planes may be defined in the future. This section provides some details about the coexistence of the various data planes of an IGP Flexible Algorithm.
IGPフレキシブルアルゴリズムは、多くのデータプレーンで使用できます。元の仕様は、SRおよびSRV6に対して行われました。この仕様により、IPはIGP Flexible Algorithmを使用できる別のデータプレーンとして追加されます。他のデータプレーンは、将来定義される場合があります。このセクションでは、IGPフレキシブルアルゴリズムのさまざまなデータプレーンの共存に関する詳細を説明します。
Flexible Algorithm Definition (FAD), as described in [RFC9350], is data plane independent and is used by all Flexible Algorithm data planes.
[RFC9350]に記載されているように、柔軟なアルゴリズム定義（FAD）は、データプレーンが独立しており、すべての柔軟なアルゴリズムデータプレーンで使用されています。
Participation in the Flexible Algorithm, as described in [RFC9350], is data plane specific.
[RFC9350]で説明されているように、柔軟なアルゴリズムへの参加は、データプレーン固有です。
Calculation of the Flexible Algorithm paths is data plane specific and uses data-plane-specific participation advertisements.
柔軟なアルゴリズムパスの計算はデータプレーン固有であり、データプレーン固有の参加広告を使用します。
Data-plane-specific participation and calculation guarantee that the forwarding of the traffic over the Flex-Algorithm data-plane-specific paths is consistent between all nodes that apply the IGP Flex-Algorithm to the data plane.
データプレーン固有の参加と計算により、Flex-Algorithm Data-Plane固有のパス上のトラフィックの転送が、IGP Flex-Algorithmをデータプレーンに適用するすべてのノード間で一貫していることが保証されます。
Multiple data planes can use the same Flex-Algorithm value at the same time and, and as such, share the FAD for it. For example, SR-MPLS and IP can both use a common Flex-Algorithm. Traffic for SR-MPLS will be forwarded based on Flex-Algorithm-specific SR SIDs. Traffic for IP Flex-Algorithm will be forwarded based on Flex-Algorithm-specific prefix reachability advertisements. Note that for a particular Flex-Algorithm, for a particular IP prefix, there will only be path(s) calculated and installed for a single data plane.
複数のデータプレーンは、同じフレックスアルゴリズム値を同時に使用でき、そのため、FADを共有できます。たとえば、SR-MPLSとIPは両方とも共通のフレックスアルゴリズムを使用できます。SR-MPLSのトラフィックは、フレックスアルゴリズム固有のSR SIDに基づいて転送されます。IP Flex-Algorithmのトラフィックは、Flex-Algorithm固有のプレフィックスReachability Advertisementsに基づいて転送されます。特定のFlex-Algorithmの場合、特定のIPプレフィックスの場合、単一のデータプレーン用に計算およびインストールされたパスのみがあることに注意してください。
In many networks where IGP Flexible Algorithms are deployed, IGP restoration will be fast and additional protection mechanisms will not be required. IGP restoration may be enhanced by Equal Cost Multipath (ECMP).
IGPフレキシブルアルゴリズムが展開されている多くのネットワークでは、IGPの復元が高速であり、追加の保護メカニズムは必要ありません。IGPの修復は、等しいコストマルチパス（ECMP）によって強化される場合があります。
In other networks, operators can deploy additional protection mechanisms. The following are examples:
他のネットワークでは、オペレーターは追加の保護メカニズムを展開できます。以下は例です。
* Loop-Free Alternates (LFAs) [RFC5286]
* ループフリーの代替（LFAS）[RFC5286]
* Remote Loop-Free Alternates (R-LFAs) [RFC7490]
* リモートループフリーの代替（R-LFAS）[RFC7490]
LFA and R-LFA computations MUST be restricted to the Flex-Algorithm topology and the computed backup next hops should be programmed for the IP Flex-Algorithm prefixes.
LFAおよびR-LFA計算は、Flex-Algorithmトポロジに制限されている必要があり、計算されたバックアップ次のホップをIP Flex-Algorithmのプレフィックス用にプログラムする必要があります。
This specification updates the "OSPF Router Information (RI) TLVs" registry as follows:
この仕様は、「OSPFルーター情報（RI）TLVS」レジストリを次のように更新します。
+=======+==============+=======================+
| Value | TLV Name | Reference |
+=======+==============+=======================+
| 21 | IP Algorithm | RFC 9502, Section 5.2 |
+-------+--------------+-----------------------+
Table 1
This document also updates the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry as follows:
このドキュメントは、次のように「IS-ISルーター機能TLVのIS-ISサブTLV」レジストリも更新します。
+=======+==============+=======================+
| Value | TLV Name | Reference |
+=======+==============+=======================+
| 29 | IP Algorithm | RFC 9502, Section 5.1 |
+-------+--------------+-----------------------+
Table 2
This document also updates the "IS-IS Top-Level TLV Codepoints" registry as follows:
このドキュメントは、次のように「IS-ISトップレベルのTLVコードポイント」レジストリも更新します。
+=======+=====================+=====+=====+=====+=======+===========+
| Value | TLV Name | IIH | LSP | SNP | Purge | Reference |
+=======+=====================+=====+=====+=====+=======+===========+
| 126 | IPv4 Algorithm | n | y | n | n | RFC 9502, |
| | Prefix | | | | | Section |
| | Reachability | | | | | 6.1 |
+-------+---------------------+-----+-----+-----+-------+-----------+
| 127 | IPv6 Algorithm | n | y | n | n | RFC 9502, |
| | Prefix | | | | | Section |
| | Reachability | | | | | 6.2 |
+-------+---------------------+-----+-----+-----+-------+-----------+
Table 3
Since the above TLVs share the sub-TLV space managed in the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry, IANA has added "IPv4 Algorithm Prefix Reachability TLV (126)" and "IPv6 Algorithm Prefix Reachability TLV (127)" to the list of TLVs in the description of that registry.
上記のTLVは、「TLVS広告プレフィックスリーチビリティのIS-ISサブTLV」で管理されているサブTLVスペースを共有しているため、IANAは「IPv4アルゴリズムの到達可能性TLV（126）」および「IPv6アルゴリズムの接頭辞リーチビリティTLV（127」を追加しました。）」そのレジストリの説明におけるTLVのリストに。
In addition, columns headed "126" and "127" have been added to that registry, as follows:
さらに、次のように、「126」と「127」という列がそのレジストリに追加されました。
+======+=========================================+=====+=====+
| Type | Description | 126 | 127 |
+======+=========================================+=====+=====+
| 1 | 32-bit Administrative Tag Sub-TLV | y | y |
+------+-----------------------------------------+-----+-----+
| 2 | 64-bit Administrative Tag Sub-TLV | y | y |
+------+-----------------------------------------+-----+-----+
| 3 | Prefix Segment Identifier | n | n |
+------+-----------------------------------------+-----+-----+
| 4 | Prefix Attribute Flags | y | y |
+------+-----------------------------------------+-----+-----+
| 5 | SRv6 End SID | n | n |
+------+-----------------------------------------+-----+-----+
| 6 | Flexible Algorithm Prefix Metric (FAPM) | n | n |
+------+-----------------------------------------+-----+-----+
| 11 | IPv4 Source Router ID | y | y |
+------+-----------------------------------------+-----+-----+
| 12 | IPv6 Source Router ID | y | y |
+------+-----------------------------------------+-----+-----+
| 32 | BIER Info | n | n |
+------+-----------------------------------------+-----+-----+
Table 4
This document registers the following in the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry:
このドキュメントは、「OSPFV2拡張プレフィックスTLV Sub-TLVS」レジストリで以下を登録します。
+=======+=========================================+===============+
| Value | TLV Name | Reference |
+=======+=========================================+===============+
| 6 | OSPFv2 IP Algorithm Prefix Reachability | RFC 9502, |
| | | Section 6.3 |
+-------+-----------------------------------------+---------------+
| 7 | OSPFv2 IP Forwarding Address | RFC 9502, |
| | | Section 6.3.1 |
+-------+-----------------------------------------+---------------+
Table 5
IANA has created the "IP Algorithm Prefix Reachability Sub-TLV Flags" registry within the "Open Shortest Path First v2 (OSPFv2) Parameters" group of registries. The new registry defines the bits in the 8-bit Flags field in the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV (Section 6.3). New bits can be allocated via IETF Review or IESG Approval [RFC8126]
IANAは、「Open Shortest Path First V2（OSPFV2）パラメーター」レジストリの「IP Algorithm Preficability Sub-TLV Flags」レジストリを作成しました。新しいレジストリは、OSPFV2 IPアルゴリズムのプレフィックスReachability Sub-TLV（セクション6.3）の8ビットフラグフィールドのBITを定義します。IETFレビューまたはIESG承認[RFC8126]で新しいビットを割り当てることができます
+=====+============+=======================+
| Bit | Name | Reference |
+=====+============+=======================+
| 0 | E bit | RFC 9502, Section 6.3 |
+-----+------------+-----------------------+
| 1-7 | Unassigned | |
+-----+------------+-----------------------+
Table 6
This document registers the following in the "OSPFv3 Extended-LSA Sub-TLVs" registry:
このドキュメントは、「OSPFV3拡張LSAサブTLV」レジストリで以下を登録します。
+=======+=======================+======+=============+
| Value | Description | L2BM | Reference |
+=======+=======================+======+=============+
| 35 | OSPFv3 IP Algorithm | X | RFC 9502, |
| | Prefix Reachability | | Section 6.4 |
+-------+-----------------------+------+-------------+
| 36 | OSPFv3 IP Flexible | X | RFC 9502, |
| | Algorithm ASBR Metric | | Section 6.5 |
+-------+-----------------------+------+-------------+
Table 7
This document registers the following in the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs" registry:
このドキュメントは、「OSPFV2拡張エリア間ASBRサブTLV」レジストリで以下を登録します。
+=======+========================================+=============+
| Value | Description | Reference |
+=======+========================================+=============+
| 2 | OSPF IP Flexible Algorithm ASBR Metric | RFC 9502, |
| | | Section 6.5 |
+-------+----------------------------------------+-------------+
Table 8
This document inherits security considerations from [RFC9350].
このドキュメントは、[RFC9350]からのセキュリティ上の考慮事項を継承しています。
This document adds one new way to disrupt IGP networks that are using Flexible Algorithm: an attacker can suppress reachability for a given prefix whose reachability is advertised by a legitimate node for a particular IP Flex-Algorithm X by advertising the same prefix in Flex-Algorithm Y from another malicious node. (To see why this is, consider, for example, the rule given in the second-to-last paragraph of Section 6.1).
このドキュメントには、柔軟なアルゴリズムを使用しているIGPネットワークを混乱させる新しい方法が追加されます。攻撃者は、Flex-Algorithmで同じプレフィックスを宣伝することにより、特定のIP Flex-Algorithm Xの正当なノードによって到達可能性が宣伝されている特定のプレフィックスの到達可能性を抑制できます。別の悪意のあるノードからのy。（これがなぜであるかを確認するには、たとえば、セクション6.1の2番目の段落に記載されているルールを考慮してください）。
This attack can be addressed by the existing security extensions, as described in [RFC5304] and [RFC5310] for IS-IS, in [RFC2328] and [RFC7474] for OSPFv2, and in [RFC4552] and [RFC5340] for OSPFv3.
この攻撃は、IS-ISの[RFC5304]および[RFC5310]、[RFC2328]および[RFC2328]および[RFC4552]、および[RFC4552]および[RFC4552]および[RFC5340]でOSOSOSPFV3の[RFC2328]および[RFC7474]で説明されているように、既存のセキュリティ拡張機能によって対処できます。
If a node that is authenticated is taken over by an attacker, such a rogue node can perform the attack described above. Such an attack is not preventable through authentication, and it is not different from advertising any other incorrect information through IS-IS or OSPF.
認証されたノードが攻撃者によって引き継がれる場合、そのような不正なノードは上記の攻撃を実行できます。このような攻撃は認証を通じて予防できず、IS-ISまたはOSPFを通じて他の誤った情報を宣伝することと違いはありません。
[ISO10589] ISO, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", Second Edition, ISO/IEC 10589:2002, November 2002.
[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>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed.,
"OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July
2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>.
[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>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[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>.
[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>.
[IANA-ALG] IANA, "IGP Algorithm Types",
<https://www.iana.org/assignments/igp-parameters>.
[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>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[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>.
[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>.
[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>.
[TS.23.501-3GPP]
3GPP, "System architecture for 5G System (5GS)", Release
18.3.0, 3GPP TS 23.501, September 2023.
Thanks to Bruno Decraene for his contributions to this document. Special thanks to Petr Bonbon Adamec of Cesnet for supporting interoperability testing.
この文書への貢献をしてくれたブルーノ・デクレーンに感謝します。相互運用性テストをサポートしてくれたCESNETのPetr Bonbon Adamecに感謝します。
William Britto
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Email: bwilliam@juniper.net
Shraddha Hegde
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Email: shraddha@juniper.net
Parag Kaneriya
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Email: pkaneria@juniper.net
Rejesh Shetty
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Email: mrajesh@juniper.net
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20171
United States of America
Email: rbonica@juniper.net
Peter Psenak
Cisco Systems
Apollo Business Center
Mlynske nivy 43
82109 Bratislava
Slovakia
Email: ppsenak@cisco.com