Internet Engineering Task Force (IETF) S. Hegde
Request for Comments: 9843 W. Britto
Updates: 9350 R. Shetty
Category: Standards Track Juniper Networks Inc.
ISSN: 2070-1721 B. Decraene
Orange
P. Psenak
Cisco Systems
T. Li
Juniper Networks Inc.
September 2025
Many networks configure the IGP link metric relative to the link capacity, and high bandwidth traffic gets routed per the link capacity. Flexible Algorithms provide mechanisms to create constraint-based paths in an IGP. This specification documents a generic metric-type and a set of bandwidth-related constraints to be used in Flexible Algorithms.
多くのネットワークは、リンク容量に対してIGPリンクメトリックを構成し、高帯域幅トラフィックがリンク容量ごとにルーティングされます。柔軟なアルゴリズムは、IGPに制約ベースのパスを作成するメカニズムを提供します。この仕様には、柔軟なアルゴリズムで使用される一般的なメトリックタイプと帯域幅関連の制約のセットが記録されています。
This document updates RFC 9350.
このドキュメントは、RFC 9350を更新します。
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/rfc9843.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9843で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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. Generic Metric Advertisement
2.1. IS-IS Generic Metric Sub-TLV
2.2. OSPF Generic Metric Sub-TLV
2.3. Generic Metric Applicability to Flexible Algorithm
Multi-Domain/Multi-Area Networks
3. FAD Constraint Sub-TLVs
3.1. IS-IS FAD Constraint Sub-TLVs
3.1.1. IS-IS Exclude Minimum Bandwidth Sub-TLV
3.1.2. IS-IS Exclude Maximum Delay Sub-TLV
3.2. OSPF FAD Constraint Sub-TLVs
3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV
3.2.2. OSPF Exclude Maximum Delay Sub-TLV
4. Bandwidth Metric Advertisement
4.1. Automatic Metric Calculation
4.1.1. Automatic Metric Calculation Modes
4.1.2. Automatic Metric Calculation Methods
4.1.3. IS-IS FAD Constraint Sub-TLVs for Automatic Metric
Calculation
4.1.4. OSPF FAD Constraint Sub-TLVs for Automatic Metric
Calculation
5. Bandwidth Metric Considerations
6. Calculation of Flex-Algorithm Paths
7. Backward Compatibility
8. Security Considerations
9. Operational Considerations
10. IANA Considerations
10.1. IGP Metric-Type Registry
10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition
Sub-TLV
10.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV
10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
10.5. Sub-Sub-TLV Codepoints for Application-Specific Link
Attributes
10.6. OSPFv2 Extended Link TLV Sub-TLVs
10.7. Types for Sub-TLVs of TE Link TLV (Value 2)
10.8. OSPFv3 Extended-LSA Sub-TLVs
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Updated List of Rules for Pruning Links in
Flex-Algorithm Topology
Acknowledgements
Contributors
Authors' Addresses
High bandwidth traffic such as residential Internet traffic and machine-to-machine elephant flows benefit from using high capacity links. Accordingly, many network operators define a link's metric relative to its capacity to help direct traffic to higher bandwidth links, but this is no guarantee that lower bandwidth links will be avoided, especially in failure scenarios. To ensure that elephant flows are only placed on high capacity links, it would be useful to explicitly exclude the high throughput traffic from utilizing links below a certain capacity. Flex-Algorithm [RFC9350] provides a mechanism to create constrained paths by defining a set of parameters consisting of calculation-type, metric-type, and a set of constraints. In this document, we define further extensions to the Flexible Algorithm Definition (FAD) that will allow operators additional control over their traffic flows, especially with respect to bandwidth constraints.
住宅のインターネットトラフィックやマシン間の象などの帯域幅のトラフィックは、大容量のリンクを使用することで恩恵を受けます。したがって、多くのネットワーク演算子は、より高い帯域幅リンクにトラフィックを向けるのに役立つ能力に関連するリンクのメトリックを定義しますが、これは、特に障害シナリオでは、より低い帯域幅リンクが回避されることを保証するものではありません。象の流れが大容量のリンクにのみ配置されるようにするために、特定の容量以下のリンクを利用することからの高いスループットトラフィックを明示的に除外することが役立ちます。Flex-Algorithm [RFC9350]は、計算型、メトリックタイプ、および一連の制約からなる一連のパラメーターを定義することにより、制約されたパスを作成するメカニズムを提供します。このドキュメントでは、特に帯域幅の制約に関して、オペレーターがトラフィックフローをさらに制御できるようにする柔軟なアルゴリズム定義（FAD）へのさらなる拡張を定義します。
Historically, IGPs have done path computation by minimizing the sum of the link metrics along the path from source to destination. While the metric has been administratively defined, implementations have defaulted to a metric that is inversely proportional to link bandwidth. This has driven traffic to higher bandwidth links and has required manual metric manipulation to achieve the desired loading of the network.
歴史的に、IGPSは、ソースから宛先へのパスに沿ったリンクメトリックの合計を最小化することにより、パス計算を行ってきました。メトリックは管理的に定義されていますが、実装はデフォルトで帯域幅に反比例するメトリックになりました。これにより、トラフィックがより高い帯域幅リンクに駆り立てられ、ネットワークの目的の負荷を実現するために手動メトリック操作が必要です。
Over time, with the addition of different traffic types, the need for alternate types of metrics has evolved. Flex-Algorithm already supports using the minimum link delay and the administratively assigned traffic-engineering metrics in path computation. However, it is clear that additional metrics may be of interest in different situations. A network operator may seek to minimize their operational costs and thus may want a metric that reflects the actual fiscal costs of using a link. Other traffic may require low jitter, leading to an entirely different set of metrics. With Flex-Algorithm, all of these different metrics, and more, could be used concurrently on the same network.
時間が経つにつれて、さまざまなトラフィックタイプが追加されると、代替タイプのメトリックの必要性が進化しました。Flex-Algorithmは、PATH計算で最小リンク遅延と管理上割り当てられたトラフィックエンジニアリングメトリックを使用して既にサポートしています。ただし、追加のメトリックがさまざまな状況に関心がある可能性があることは明らかです。ネットワークオペレーターは、運用コストを最小限に抑えようとする場合があるため、リンクの使用の実際の財政コストを反映するメトリックが必要になる場合があります。他のトラフィックには低いジッターが必要になる場合があり、まったく異なるメトリックセットにつながります。Flex-Algorithmを使用すると、これらの異なるメトリックなどはすべて、同じネットワークで同時に使用できます。
In some circumstances, path computation constraints, such as administrative groups, can be used to ensure that traffic avoids particular portions of the network. These strict constraints are appropriate when there is an absolute requirement to avoid parts of the topology, even in failure conditions. However, if the requirement is less strict, then using a high metric in a portion of the topology may be more appropriate.
状況によっては、管理グループなどのパス計算の制約を使用して、トラフィックがネットワークの特定の部分を回避するようにすることができます。これらの厳格な制約は、障害条件であっても、トポロジーの一部を回避するための絶対的な要件がある場合に適切です。ただし、要件が厳格でない場合は、トポロジの一部で高いメトリックを使用する方が適切かもしれません。
This document defines a family of generic metrics that can advertise various types of administratively assigned metrics. This document introduces standard metric-types that have specific semantics and require standardization. This document also specifies user-defined metric-types where specifics are not defined so that administrators are free to assign semantics as they see fit.
このドキュメントでは、さまざまな種類の管理上割り当てられたメトリックを宣伝できる一般的なメトリックのファミリーを定義します。このドキュメントでは、特定のセマンティクスを持ち、標準化が必要な標準メトリックタイプを紹介します。また、このドキュメントは、管理者が適切なセマンティクスを自由に割り当てることができるように、詳細が定義されていないユーザー定義のメトリックタイプを指定します。
Section 3 defines additional FAD [RFC9350] constraints that allow the network administrator to preclude the use of low bandwidth links or high delay links. Section 4 specifies a new bandwidth-based metric-type to be used with Flex-Algorithm and other applications.
セクション3では、ネットワーク管理者が低帯域幅リンクまたは高遅延リンクの使用を排除できる追加のFAD [RFC9350]制約を定義します。セクション4では、フレックスアルゴリズムおよびその他のアプリケーションで使用する新しい帯域幅ベースのメトリックタイプを指定します。
Section 4.1 defines mechanisms to automatically calculate link metrics based on the parameters defined in the FAD and the advertised Maximum Link Bandwidth of each link. This is advantageous because administrators can change their criteria for metric assignment centrally, without individual modification of each link metric throughout the network. The procedures described in this document are intended to assign a metric to a link based on the total link capacity, and they are not intended to update the metric based on actual traffic flow. Thus, the procedures described in this document are not a replacement to the capability of a PCE [RFC4655], which has a dynamic view of the network and provides real-time bandwidth management or a distributed bandwidth management protocol.
セクション4.1は、FADで定義されたパラメーターと各リンクの最大リンク帯域幅に基づいてリンクメトリックを自動的に計算するメカニズムを定義します。これは、管理者がネットワーク全体の各リンクメトリックを個別に変更することなく、中央にメトリック割り当ての基準を変更できるため、これは有利です。このドキュメントで説明されている手順は、総リンク容量に基づいてリンクにメトリックを割り当てることを目的としており、実際のトラフィックフローに基づいてメトリックを更新することを意図していません。したがって、このドキュメントで説明されている手順は、ネットワークの動的ビューを持ち、リアルタイム帯域幅管理または分散帯域幅管理プロトコルを提供するPCE [RFC4655]の機能に代わるものではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
IS-IS [RFC1195] and OSPF [RFC2328] advertise a metric for each link in their respective link state advertisements. Multiple metric-types are already supported. Administratively assigned metrics are described in the original OSPF and IS-IS specifications. The Traffic Engineering Default Metric is defined in [RFC5305] and [RFC3630], and the Unidirectional Link Delay is defined in [RFC8570] and [RFC7471]. Other metrics, such as jitter, reliability, and fiscal cost may be helpful, depending on the traffic class. Rather than attempt to enumerate all possible metrics of interest, this document specifies a generic mechanism for advertising metrics.
IS-IS [RFC1195]およびOSPF [RFC2328]は、それぞれのリンク状態広告の各リンクのメトリックを宣伝しています。複数のメトリックタイプがすでにサポートされています。管理上割り当てられたメトリックは、元のOSPFおよびIS-IS仕様で説明されています。トラフィックエンジニアリングのデフォルトメトリックは[RFC5305]および[RFC3630]で定義されており、単方向リンク遅延は[RFC8570]および[RFC7471]で定義されています。ジッター、信頼性、財政コストなどの他のメトリックは、トラフィッククラスに応じて役立つ場合があります。対象のすべてのメトリックを列挙しようとするのではなく、このドキュメントは、広告メトリックの一般的なメカニズムを指定します。
Each generic metric advertisement is on a per-link and per-metric-type basis. The metric advertisement consists of a metric-type field and a value for the metric. The metric-type field has been assigned in the "IGP Metric-Type" IANA registry. Metric-types 0-127 are standard metric-types as assigned by IANA. This document further specifies a user-defined metric-type space of metric-types 128-255. They can be assigned by an operator for local use.
各汎用メトリック広告は、リンクごとに、およびメトリックごとの型ベースです。メトリック広告は、メトリックタイプのフィールドとメトリックの値で構成されています。メトリックタイプのフィールドは、「IGPメトリックタイプ」IANAレジストリに割り当てられています。メトリックタイプ0-127は、IANAによって割り当てられた標準メトリックタイプです。このドキュメントは、メトリックタイプ128-255のユーザー定義のメトリックタイプ空間をさらに指定します。これらは、ローカルで使用するためにオペレーターによって割り当てることができます。
Implementations MUST support sending and receiving a Generic Metric sub-TLV in Application-Specific Link Attributes (ASLA) encodings as well as in TLV 22 and Extended Link Opaque Link State Advertisements (LSAs) [RFC7684] and TE-LSAs. The usage of a generic metric by an individual application is subject to the same rules that apply to other link attributes as defined in [RFC3630], [RFC5305], [RFC9479], [RFC9492], and [RFC9350].
実装は、アプリケーション固有のリンク属性（ASLA）エンコーディングおよびTLV 22および拡張リンク不透明なリンク状態広告（LSA）[RFC7684]およびTE-LSAでの一般的なメトリックサブTLVの送信と受信をサポートする必要があります。個々のアプリケーションによる汎用メトリックの使用は、[RFC3630]、[RFC5305]、[RFC9479]、[RFC9492]、および[RFC9350]で定義されている他のリンク属性に適用されるのと同じルールの対象となります。
The IS-IS Generic Metric sub-TLV specifies the link metric for a given metric-type. Typically, this metric is assigned by a network administrator. The Generic Metric sub-TLV is advertised in the TLVs/ sub-TLVs below:
IS-IS Generic Metric Sub-TLVは、特定のメトリックタイプのリンクメトリックを指定します。通常、このメトリックはネットワーク管理者によって割り当てられます。汎用メトリックサブTLVは、以下のTLVS/ SUB-TLVで宣伝されています。
a. TLV 22 (Extended IS reachability) [RFC5305]
a. TLV 22（拡張は到達可能性です）[RFC5305]
b. TLV 222 (MT-ISN) [RFC5120]
b. TLV 222（MT-ISN）[RFC5120]
c. TLV 23 (IS Neighbor Attribute) [RFC5311]
c. TLV 23（IS隣接属性）[RFC5311]
d. TLV 223 (MT IS Neighbor Attribute) [RFC5311]
d. TLV 223（MTは隣接属性）[RFC5311]
e. TLV 141 (Inter-AS Reachability Information) [RFC9346]
e. TLV 141（到達可能性情報間）[RFC9346]
f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLVs 22/222/23/223/141 [RFC9479]
f. TLVのSub-TLV 16（アプリケーション固有のリンク属性（ASLA））22/222/23/223/141 [RFC9479]
g. TLV 25 (L2 Bundle Member Attributes) [RFC8668]. Marked as "y(s)" (shareable among bundle members).
g. TLV 25（L2バンドルメンバー属性）[RFC8668]。「y（s）」としてマークされています（バンドルメンバー間で共有可能）。
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 | metric-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IS-IS Generic Metric Sub-TLV
図1：IS-IS Generic Metric Sub-TLV
where:
ただし：
Type (1 octet):
タイプ（1オクテット）：
An 8-bit field assigned by IANA (17). This value uniquely identifies the Generic Metric TLV.
IANA（17）によって割り当てられた8ビットフィールド。この値は、一般的なメトリックTLVを一意に識別します。
Length (1 octet):
長さ（1オクテット）：
An 8-bit field indicating the total length, in octets, of the subsequent fields. For this TLV, the Length is set to 4.
後続のフィールドのオクテットの総長さを示す8ビットフィールド。このTLVの場合、長さは4に設定されています。
Metric-Type (1 octet):
メトリックタイプ（1オクテット）：
An 8-bit field specifying the type of metric. The value is taken from the "IGP Metric-Type" registry maintained by IANA. The metric-type may be any value that is indicated as allowed in the Generic Metric sub-TLV by the "IGP Metric-Type" registry.
メトリックのタイプを指定する8ビットフィールド。値は、IANAによって維持されている「IGPメトリックタイプ」レジストリから取得されます。メトリックタイプは、「IGPメトリックタイプ」レジストリによって汎用メトリックサブTLVで許可されていると示される任意の値である場合があります。
Value (3 octets):
値（3オクテット）：
A 24-bit unsigned integer representing the metric value. The valid range is from 0 to 16,777,215 (0xFFFFFF).
メトリック値を表す24ビットの署名されていない整数。有効な範囲は0〜16,777,215（0xffffffff）です。
The Generic Metric sub-TLV MAY be advertised multiple times. For a particular metric-type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised in TLVs 22, 222, 23, 223, and 141. When the Generic Metric sub-TLV is advertised in ASLA, each metric-type MUST be advertised only once per-application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric-type (and the same application in case of ASLA) in one or more received Link State Protocol Data Units (LSPDUs), advertisement in the lowest-numbered fragment MUST be used, and the subsequent instances MUST be ignored.
汎用メトリックサブTLVは、複数回宣伝される場合があります。特定のメトリックタイプの場合、一般的なメトリックサブTLVは、TLVS 22、222、23、223、および141で宣伝された場合、リンクに対して一度だけ宣伝する必要があります。一般的なメトリックサブTLVがASLAで宣伝される場合、各メトリックタイプはリンクごとに1回だけ宣伝する必要があります。1つ以上の受信リンク状態プロトコルデータユニット（LSPDUS）に同じメトリックタイプ（およびASLAの場合と同じアプリケーション）のリンクに対して宣伝されている複数の汎用メトリックサブTLVがある場合、最低の断片の広告を使用する必要があり、その後のインスタンスは無視する必要があります。
For a link, if the metric-type corresponds to a metric-type for which legacy advertisement mechanisms exist (e.g., the IGP Metric, the Min Unidirectional Link Delay, or the Traffic Engineering Default Metric), the legacy metric-types MUST be utilized from the existing TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, it MUST be ignored.
リンクの場合、メトリックタイプがレガシー広告メカニズムが存在するメトリックタイプに対応する場合（たとえば、IGPメトリック、最小単方向リンク遅延、またはトラフィックエンジニアリングのデフォルトメトリック）、レガシーメトリック型を既存のTLVまたはサブTLVから利用する必要があります。一般的なメトリックがレガシーメトリックを宣伝する場合は、無視する必要があります。
A metric value of 0xFFFFFF is considered a maximum link metric, and a link having this metric value MUST be used during Flex-Algorithm calculations as a last resort link as described in Section 15.3 of [RFC9350]. A link can be made unusable by Flex-Algorithm by leaving out Generic Metric advertisement of the particular metric-type that the Flex-Algorithm uses, as described in [RFC9350].
0xFFFFFFのメートル値は最大リンクメトリックと見なされ、[RFC9350]のセクション15.3で説明されているように、最後のリゾートリンクとして、このメトリック値を持つリンクを使用する必要があります。[RFC9350]で説明されているように、Flex-Algorithが使用する特定のメトリックタイプの一般的なメトリック広告を除外することにより、Flex-Algorithmによってリンクを使用できません。
During the router maintenance activity, the Generic Metric for all the links on the node MAY be set to a maximum value of 16,777,215 (0xFFFFFF), as it is the maximum usable link metric for the Flex-Algorithm calculations.
ルーターメンテナンスアクティビティ中、ノード上のすべてのリンクの汎用メトリックは、フレックスアルゴリズムの計算の最大使用可能なリンクメトリックであるため、最大値16,777,215（0xffffff）に設定できます。
The OSPF Generic Metric sub-TLV specifies the link metric for a given metric-type. Typically, this metric is assigned by a network administrator. The Generic Metric sub-TLV is advertised in the TLVs below:
OSPFジェネリックメトリックサブTLVは、特定のメトリックタイプのリンクメトリックを指定します。通常、このメトリックはネットワーク管理者によって割り当てられます。汎用メトリックサブTLVは、以下のTLVで宣伝されています。
a. sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630].
a. OSPF TE LSA [RFC3630]のTEリンクTLV（タイプ2）のサブTLV。
b. sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA [RFC5392].
b. OSOSPFV2 INTER-TE-V2 LSA [RFC5392]のTEリンクTLV（タイプ2）のサブTLV。
c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA [RFC5329].
c. OSPFV3のTEリンクTLV（タイプ2）のサブTLV [RFC5329]。
d. sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA [RFC5392].
d. OSPFV3 Inter-as-V3 LSA [RFC5392]のTEリンクTLV（タイプ2）のサブTLV。
e. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV [RFC9492] of the OSPFv2 Extended Link TLV [RFC7684].
e. OSPFV2拡張リンクTLV [RFC7684]のアプリケーション固有のリンク属性（ASLA）Sub-TLV [RFC9492]のサブTLV。
f. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV [RFC9492] of the OSPFv3 Router-Link TLV [RFC8362].
f. OSPFV3ルーターリンクTLV [RFC8362]のアプリケーション固有のリンク属性（ASLA）サブTLV [RFC9492]のサブTLV。
g. sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV [RFC9356].
g. OSPFV2 L2バンドルメンバーのサブTLV属性Sub-TLV [RFC9356]。
h. sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV [RFC9356].
h. OSPFV3 L2バンドルメンバーのサブTLV属性Sub-TLV [RFC9356]。
The Generic Metric sub-TLV, types 25/36/34, is 8 octets in length.
一般的なメトリックサブTLV、タイプ25/36/34の長さは8オクテットです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-type | Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: OSPF Generic Metric Sub-TLV
図2：OSPFジェネリックメトリックサブTLV
where:
ただし：
Type (2 octets):
タイプ（2オクテット）：
A 16-bit field assigned by IANA (25/36/34). This value uniquely identifies the Generic Metric TLV.
IANA（25/36/34）によって割り当てられた16ビットフィールド。この値は、一般的なメトリックTLVを一意に識別します。
Length (2 octets):
長さ（2オクテット）：
A 16-bit field indicating the total length, in octets, of the subsequent fields. For this TLV, the Length is set to 8.
後続のフィールドのオクテットの総長さを示す16ビットフィールド。このTLVの場合、長さは8に設定されます。
Metric-Type (1 octet):
メトリックタイプ（1オクテット）：
An 8-bit field specifying the type of metric. The value is taken from the "IGP Metric-Type" registry maintained by IANA. The metric-type may be any value that is indicated as allowed in the Generic Metric sub-TLV by the "IGP Metric-Type" registry.
メトリックのタイプを指定する8ビットフィールド。値は、IANAによって維持されている「IGPメトリックタイプ」レジストリから取得されます。メトリックタイプは、「IGPメトリックタイプ」レジストリによって汎用メトリックサブTLVで許可されていると示される任意の値である場合があります。
Reserved (3 octets):
予約済み（3オクテット）：
MUST set to zero by the sender and MUST be ignored by the receiver.
送信者によってゼロに設定する必要があり、受信機は無視する必要があります。
Value (4 octets):
値（4オクテット）：
A 32-bit unsigned integer representing the metric value. The valid range is from 0 to 4,294,967,295 (0xFFFFFFFF).
メトリック値を表す32ビットの符号なし整数。有効な範囲は、0〜4,294,967,295（0xffffffff）です。
The Generic Metric sub-TLV MAY be advertised multiple times. For a particular metric-type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised as (a) through (d) above. When the Generic Metric sub-TLV is advertised as a sub-TLV of ASLA, it MUST be advertised only once per application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric-type (and the same application in case of ASLA) in one or more received LSAs, advertisement in the lowest-numbered LSA MUST be used, and the subsequent instances MUST be ignored.
汎用メトリックサブTLVは、複数回宣伝される場合があります。特定のメトリックタイプの場合、一般的なメトリックサブTLVは、上記（d）から（d）から（d）から宣伝された場合、リンクに対して一度だけ宣伝する必要があります。汎用メトリックサブTLVがASLAのサブTLVとして宣伝されている場合、リンクのアプリケーションごとに1回のみ宣伝する必要があります。同じメトリックタイプ（およびASLAの場合と同じアプリケーション）のリンクに対して宣伝されている複数の汎用メトリックサブTLVが1つまたは複数の受信LSAで、最も少ない数のLSAの広告を使用する必要があり、その後のインスタンスを無視する必要があります。
For a link, if the metric-type corresponds to a metric-type for which legacy advertisement mechanisms exist (e.g., the IGP Metric, the Min Unidirectional Link Delay, or the Traffic Engineering Default Metric), the legacy metric-types MUST be utilized from the existing TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, it MUST be ignored.
リンクの場合、メトリックタイプがレガシー広告メカニズムが存在するメトリックタイプに対応する場合（たとえば、IGPメトリック、最小単方向リンク遅延、またはトラフィックエンジニアリングのデフォルトメトリック）、レガシーメトリック型を既存のTLVまたはサブTLVから利用する必要があります。一般的なメトリックがレガシーメトリックを宣伝する場合は、無視する必要があります。
A metric value of 0xFFFFFFFF is considered a maximum link metric, and a link having this metric value MUST be used during Flex-Algorithm calculations as a last resort link, as described in Section 15.3 of [RFC9350].
0xffffffffffのメートル値は最大リンクメトリックと見なされ、[RFC9350]のセクション15.3で説明されているように、最後のリゾートリンクとしてのFlex-Algorithmの計算中に、このメトリック値を持つリンクを使用する必要があります。
A link can be made unusable by Flex-Algorithm by leaving out Generic Metric advertisement of the particular metric-type that the Flex-Algorithm uses, as described in [RFC9350].
[RFC9350]で説明されているように、Flex-Algorithが使用する特定のメトリックタイプの一般的なメトリック広告を除外することにより、Flex-Algorithmによってリンクを使用できません。
During the router maintenance activity, the Generic Metric for all the links on the node MAY be set to a maximum value of 4,294,967,295 (0xFFFFFFFF), as it is the maximum usable link metric for the Flex-Algorithm calculations.
ルーターメンテナンスアクティビティ中、ノード上のすべてのリンクの汎用メトリックは、フレックスアルゴリズムの計算の最大使用可能なリンクメトリックであるため、最大値4,294,967,295（0xffffffffff）に設定できます。
Generic Metric can be used by Flex-Algorithm by specifying the metric-type in the Flexible Algorithm Definitions. When Flex-Algorithm is used in a multi-area network, [RFC9350] defines the Flexible Algorithm Prefix Metric (FAPM) sub-TLV that carries the Flexible-Algorithm-specific metric. Metrics carried in FAPM will be equal to the metric to reach the prefix for that Flex-Algorithm in its source area or domain (source area from the Area Border Router (ABR) perspective). When Flex-Algorithm uses Generic Metric, the same procedures as described in Section 13 of [RFC9350] are used to send and process the FAPM sub-TLV.
汎用メトリックは、柔軟なアルゴリズム定義でメトリックタイプを指定することにより、フレックスアルゴリズムで使用できます。Flex-Algorithmがマルチアレアネットワークで使用される場合、[RFC9350]は、フレキシブルアルゴリズム固有のメトリックを運ぶフレキシブルアルゴリズムプレフィックスメトリック（FAPM）Sub-TLVを定義します。FAPMで運ばれるメトリックは、メトリックに等しく、ソース領域またはドメイン（エリアボーダールーター（ABR）の観点からのソースエリア）のフレックスアルゴリズムのプレフィックスに到達します。Flex-Algorithmが汎用メトリックを使用する場合、[RFC9350]のセクション13で説明されているのと同じ手順を使用して、FAPM Sub-TLVを送信および処理します。
Large high throughput flows are referred to as "elephant flows". Directing an elephant flow down a low-bandwidth link might congest the link and cause other critical application traffic flowing on the link to drop. Thus, in the context of Flex-Algorithm, it would be useful to be able to constrain the topology to only those links capable of supporting a minimum amount of bandwidth.
大きな高スループットフローは「象の流れ」と呼ばれます。象の流れを低帯域幅リンクに向けると、リンクを混雑させ、リンクに流れる他の重要なアプリケーショントラフィックがドロップされる可能性があります。したがって、Flex-Algorithmのコンテキストでは、最小量の帯域幅をサポートできるリンクのみにトポロジを制限できることが有用です。
If the capacity of a low bandwidth link is constant, constraining the topology to avoid those links can already be achieved through the use of administrative groups. However, when a Layer 3 link is actually a collection of Layer 2 links (Link Aggregation Group (LAG) / Layer 2 Bundle), the link bandwidth will vary based on the set of active constituent links. This could be automated by having an implementation vary the advertised administrative groups based on bandwidth, but this seems unnecessarily complex and expressing this requirement as a direct constraint on the topology seems simpler. This is also advantageous if the minimum required bandwidth changes, as this constraint would provide a single centralized, coordinated point of control.
低帯域幅リンクの容量が一定である場合、これらのリンクを回避するためにトポロジを制約して、管理グループを使用してすでに達成できます。ただし、レイヤー3リンクが実際にレイヤー2リンク（リンク集約グループ（LAG） /レイヤー2バンドル）のコレクションである場合、リンク帯域幅はアクティブな成分リンクのセットに基づいて異なります。これは、実装を帯域幅に基づいて広告された管理グループを変化させることで自動化できますが、これは不必要に複雑であり、トポロジの直接的な制約としてこの要件を表現するように思われます。これは、この制約が単一の集中化された調整された制御ポイントを提供するため、最小必要な帯域幅が変化する場合にも有利です。
To satisfy this requirement, this document defines an Exclude Minimum Bandwidth constraint. When this constraint is advertised in a FAD, a link will be pruned from the Flex-Algorithm topology if the link's advertised maximum link bandwidth value is below the FAD advertised minimum bandwidth value.
この要件を満たすために、このドキュメントは除外された最小帯域幅の制約を定義します。この制約がFADで宣伝される場合、リンクの宣伝された最大リンク帯域幅値がFAD広告の最小帯域幅値を下回る場合、リンクはFlex-Algorithmトポロジから剪定されます。
Similarly, this document defines an Exclude Maximum Link Delay constraint. Applications, such as High-Frequency Trading are sensitive to link delays and may perform poorly in networks prone to delay variability, such as those with transparent Layer 2 link recovery mechanisms or satellite links. Mechanisms already exist to measure the link delay dynamically and advertise it in the IGP. Networks that employ dynamic link-delay measurement, may want to exclude links that have a delay over a given threshold.
同様に、このドキュメントは、除外の最大リンク遅延制約を定義します。高周波取引などのアプリケーションは、リンクの遅延に敏感であり、透明なレイヤー2リンク回復メカニズムや衛星リンクなど、変動性を遅らせる傾向があるネットワークでパフォーマンスが低下する可能性があります。リンク遅延を動的に測定し、IGPで宣伝するメカニズムが既に存在しています。動的なリンク遅延測定を採用するネットワークは、特定のしきい値にわたって遅延があるリンクを除外することをお勧めします。
IS-IS Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
IS-IS Flex-Algorithm除外最小帯域幅（FAEMB）Sub-TLVは、IS-IS FADサブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IS-IS FAEMB Sub-TLV
図3：IS-IS FAEMB Sub-TLV
where:
ただし：
Type (1 octet):
タイプ（1オクテット）：
An 8-bit field assigned by IANA (6). This value uniquely identifies the FAEMB sub-TLV.
IANA（6）によって割り当てられた8ビットフィールド。この値は、FAEMBサブTLVを一意に識別します。
Length (1 octet):
長さ（1オクテット）：
An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to 4.
後続のフィールドのオクテットの総長さを示す8ビットフィールド。このサブTLVの場合、長さは4に設定されています。
Min Bandwidth (4 octets):
最小帯域幅（4オクテット）：
A 32-bit field specifying the link bandwidth encoded in IEEE floating point format (32 bits) [IEEE754-2019]. The units are bytes per second.
IEEEフローティングポイント形式（32ビット）でエンコードされたリンク帯域幅を指定する32ビットフィールド[IEEE754-2019]。ユニットは1秒あたりのバイトです。
The FAEMB sub-TLV MUST appear once at most in the FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver.
FAEMB Sub-TLVは、FAD Sub-TLVにせいぜい1回表示する必要があります。複数回表示される場合、IS-IS FADサブTLVはレシーバーによって無視する必要があります。
The minimum bandwidth value advertised in the FAEMB sub-TLV MUST be compared with maximum link bandwidth value advertised in sub-sub-TLV 9 of the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA sub-TLV, the minimum bandwidth value advertised in the FAEMB sub-TLV MUST be compared with the maximum link bandwidth value as advertised in the sub-TLV 9 of the TLVs 22/222/23/223/141 [RFC5305], as defined in Section 4.2 of [RFC9479].
FAEMBサブTLVで宣伝されている最小帯域幅値は、ASLAサブTLV [RFC9479]のサブサブTLV 9で宣伝されている最大リンク帯域幅値と比較する必要があります。L-FLAGがASLA Sub-TLVに設定されている場合、FAEMB Sub-TLVで宣伝されている最小帯域幅値を、[RFC9479]に定義されているように、TLVS 22/23/223/141 [RFC5305]で宣伝されている最大リンク帯域幅値と比較する必要があります。
If the maximum link bandwidth value is lower than the minimum link bandwidth value advertised in the FAEMB sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If a link does not have the Maximum Link Bandwidth advertised but the FAD contains the FAEMB sub-TLV, then that link MUST NOT be excluded from the topology based on the Minimum Bandwidth constraint.
最大リンク帯域幅値が、FAEMBサブTLVで宣伝されている最小リンク帯域幅値よりも低い場合、リンクはFlex-Algorithmトポロジから除外する必要があります。リンクに最大リンク帯域幅が宣伝されていないが、FADにFAEMBサブTLVが含まれている場合、そのリンクを最小帯域幅の制約に基づいてトポロジから除外してはなりません。
IS-IS Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
IS-IS Flex-Algorithm除外最大遅延（FAEMD）Sub-TLVは、IS-IS FAD Sub-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IS-IS FAEMD Sub-TLV
図4：IS-IS FAEMD SUB-TLV
where:
ただし：
Type (1 octet):
タイプ（1オクテット）：
An 8-bit field assigned by IANA (7). This value uniquely identifies the FAEMD sub-TLV.
IANA（7）によって割り当てられた8ビットフィールド。この値は、FAEMDサブTLVを一意に識別します。
Length (1 octet):
長さ（1オクテット）：
An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to 3.
後続のフィールドのオクテットの総長さを示す8ビットフィールド。このサブTLVの場合、長さは3に設定されます。
Max Link Delay (3 octets):
最大リンク遅延（3オクテット）：
A 24-bit field specifying the Maximum link delay in microseconds.
マイクロ秒の最大リンク遅延を指定する24ビットフィールド。
The FAEMD sub-TLV MUST appear only once in the FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver.
FAEMD Sub-TLVは、FAD Sub-TLVに1回のみ表示される必要があります。複数回表示される場合、IS-IS FADサブTLVはレシーバーによって無視する必要があります。
The maximum link delay value advertised in the FAEMD sub-TLV MUST be compared with Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA sub-TLV, the maximum link delay value advertised in the FAEMD sub-TLV MUST be compared with Min Unidirectional Link Delay as advertised by the sub-TLV 34 of the TLVs 22/222/23/223/141 [RFC8570], as defined in Section 4.2 of [RFC9479].
FAEMD Sub-TLVで宣伝されている最大リンク遅延値は、ASLAサブTLV [RFC9479]のサブサブTLV 34で宣伝されている最小単方向リンク遅延と比較する必要があります。L-FLAGがASLA Sub-TLVに設定されている場合、FAEMDサブTLVで宣伝されている最大リンク遅延値は、TLVS 22/22/223/141 [RFC8570]、[RFC9479]に定義されているように、TLVS 22/23/223/141 [RFC8570]によって宣伝されている最小単方向リンク遅延と比較する必要があります。
If the Min Unidirectional Link Delay value is higher than the Maximum Link Delay advertised in the FAEMD sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If a link does not have the Min Unidirectional Link Delay advertised but the FAD contains the FAEMD sub-TLV, then that link MUST NOT be excluded from the topology based on the Maximum Delay constraint.
最小単方向リンク遅延値がFAEMDサブTLVで宣伝されている最大リンク遅延よりも高い場合、リンクはフレックスアルゴリズムトポロジから除外する必要があります。リンクに最小単方向リンク遅延が宣伝されていないが、FADにFAEMDサブTLVが含まれている場合、そのリンクは最大遅延制約に基づいてトポロジから除外してはなりません。
OSPF Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format:
OSPF Flex-Algorithmは、最小帯域幅（FAEMB）Sub-TLVを除外して、OSPF FAD 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OSPF FAEMB Sub-TLV
図5：OSPF FAEMB SUB-TLV
where:
ただし：
Type (2 octets):
タイプ（2オクテット）：
A 16-bit field assigned by IANA (6). This value uniquely identifies the OSPF FAEMB sub-TLV.
IANA（6）によって割り当てられた16ビットフィールド。この値は、OSPF FAEMBサブTLVを一意に識別します。
Length (2 octets):
長さ（2オクテット）：
A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to 4.
後続のフィールドのオクテットの総長さを示す16ビットフィールド。このサブTLVの場合、長さは4に設定されています。
Min Bandwidth (4 octets):
最小帯域幅（4オクテット）：
A 32-bit field specifying the link bandwidth encoded in IEEE floating point format (32 bits)[IEEE754-2019]. The units are bytes per second.
IEEEフローティングポイント形式（32ビット）でエンコードされたリンク帯域幅を指定する32ビットフィールド[IEEE754-2019]。ユニットは1秒あたりのバイトです。
The FAEMB sub-TLV MUST only appear once in the FAD sub-TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver.
FAEMB Sub-TLVは、FAD Sub-TLVに1回のみ表示する必要があります。複数回見える場合は、OSPF FAD TLVを受信機によって無視する必要があります。
The Maximum Link Bandwidth as advertised in the Extended Link TLV in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub-TLV of the Router-Link TLV of the E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362] MUST be compared against the Minimum Bandwidth advertised in the FAEMB sub-TLV. If the link bandwidth value is lower than the Minimum Bandwidth advertised in the FAEMB sub-TLV, the link MUST be excluded from the Flex-Algorithm topology.
OSPFV2の拡張リンク不透明LSA [RFC7684]の拡張リンクTLVで宣伝されている最大リンク帯域幅、またはOSPFV3 [RFC8362]のE-Router-LSA Router-Link TLVのRouter-LSA Router-Link TLVのサブTLVとして、最低帯域では、最低帯域bidのサブワイズに比較してください。FAEMB Sub-TLVで宣伝されている最小帯域幅よりもリンク帯域幅の値が低い場合、リンクはFlex-Algorithmトポロジから除外する必要があります。
If a link does not have the Maximum Link Bandwidth advertised but the FAD contains the FAEMB sub-TLV, then that link MUST be included in the topology and proceed to apply further pruning rules for the link.
リンクに最大リンク帯域幅が宣伝されていないが、FADにFAEMBサブTLVが含まれている場合、そのリンクをトポロジに含め、リンクにさらに剪定ルールを適用する必要があります。
The OSPF Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format.
OSPF Flex-Algorithmは、最大遅延（FAEMD）Sub-TLVを除外し、OSPF FAD 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OSPF FAEMD Sub-TLV
図6：OSPF FAEMD sub-tlv
where:
ただし：
Type (2 octets):
タイプ（2オクテット）：
A 16-bit field assigned by IANA (7). This value uniquely identifies the OSPF FAEMD sub-TLV.
IANA（7）によって割り当てられた16ビットフィールド。この値は、OSPF FAEMDサブTLVを一意に識別します。
Length (2 octets):
長さ（2オクテット）：
A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to 4.
後続のフィールドのオクテットの総長さを示す16ビットフィールド。このサブTLVの場合、長さは4に設定されています。
Reserved (1 octet):
予約済み（1オクテット）：
MUST be set to zero by the sender and MUST be ignored by the receiver.
送信者はゼロに設定する必要があり、受信機は無視する必要があります。
Max Link Delay (3 octets):
最大リンク遅延（3オクテット）：
A 24-bit field specifying the Maximum link delay in microseconds.
マイクロ秒の最大リンク遅延を指定する24ビットフィールド。
The FAEMD sub-TLV MUST only appear once in the OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver.
FAEMD Sub-TLVは、OSPF FAD TLVに1回のみ表示される必要があります。複数回見える場合は、OSPF FAD TLVを受信機によって無視する必要があります。
The Min Delay value advertised via the Min/Max Unidirectional Link Delay of the ASLA sub-TLV [RFC9492] MUST be compared against the Maximum Delay advertised in the FAEMD sub-TLV. If the Min Unidirectional Link Delay is higher than the Maximum Delay advertised in the FAEMD sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If the Min/Max Unidirectional Link Delay is not advertised for a link but the FAD contains this sub-TLV, then that link MUST NOT be excluded from the topology based on the Maximum Delay constraint.
ASLA Sub-TLV [RFC9492]のMIN/MAX単方向リンク遅延を介して宣伝されているMIN遅延値は、FAEMD Sub-TLVで宣伝されている最大遅延と比較する必要があります。最小単方向リンク遅延がFAEMD Sub-TLVで宣伝されている最大遅延よりも高い場合、リンクはFlex-Algorithmトポロジから除外する必要があります。MIN/MAX単方向リンクの遅延がリンクに宣伝されていないが、FADにこのサブTLVが含まれている場合、そのリンクは最大遅延制約に基づいてトポロジから除外してはなりません。
Historically, IGP implementations have made default metric assignments based on link bandwidth. This has proven to be useful but has suffered from having different defaults across implementations and from the rapid growth of link bandwidths. With Flex-Algorithm, the network administrator can define a function that will produce a metric for each link and have each node automatically compute each link's metric based on its bandwidth.
歴史的に、IGPの実装は、リンク帯域幅に基づいてデフォルトのメトリック割り当てを行いました。これは有用であることが証明されていますが、実装間で異なるデフォルトを持っていることや、リンク帯域幅の急速な成長に苦しんでいます。Flex-Algorithmを使用すると、ネットワーク管理者は、各リンクのメトリックを生成する関数を定義し、各ノードが帯域幅に基づいて各リンクのメトリックを自動的に計算することができます。
This document defines a standard metric-type for this purpose called the "Bandwidth Metric". The Bandwidth Metric MAY be advertised in the Generic Metric sub-TLV with the metric-type set to "Bandwidth Metric". IS-IS and OSPF will advertise this type of metric in their link advertisements. The Bandwidth Metric is a link attribute, and it MUST follow Section 12 of [RFC9350] for its advertisement and processing during Flex-Algorithm calculation.
このドキュメントでは、「帯域幅メトリック」と呼ばれるこの目的の標準メトリックタイプを定義しています。帯域幅メトリックは、メトリックタイプが「帯域幅メトリック」に設定された一般的なメトリックサブTLVで宣伝できます。IS-ISとOSPFは、このタイプのメトリックをリンク広告に宣伝します。帯域幅メトリックはリンク属性であり、フレックスアルゴリズムの計算中の広告と処理のために[RFC9350]のセクション12に従う必要があります。
Flex-Algorithm uses this metric-type by specifying the bandwidth metric as the metric-type in a FAD TLV. A FAD TLV may also specify an automatic computation of the bandwidth metric based on a link's advertised bandwidth. An explicit advertisement of a link's bandwidth metric using the Generic Metric sub-TLV overrides this automatic computation. The automatic Bandwidth metric calculation sub-TLVs are advertised in the FAD TLV, and these parameters are applicable to applications such as Flex-Algorithm that make use of the FAD TLV.
Flex-Algorithmは、FAD TLVのメトリックタイプとして帯域幅メトリックを指定することにより、このメトリックタイプを使用します。FAD TLVは、リンクの広告帯域幅に基づいて帯域幅メトリックの自動計算を指定することもできます。汎用メトリックサブTLVを使用したリンクの帯域幅メトリックの明示的な広告は、この自動計算をオーバーライドします。自動帯域幅メトリック計算サブTLVはFAD TLVで宣伝されており、これらのパラメーターはFAD TLVを使用するFlex-Algorithmなどのアプリケーションに適用できます。
Networks that are designed to be highly regular and that follow uniform metric assignment may want to simplify their operations by automatically calculating the bandwidth metric. When a FAD advertises the metric-type as Bandwidth Metric and the link does not have the Bandwidth Metric advertised, automatic metric derivation can be used with additional FAD constraint advertisement as described in this section.
非常に規則的であり、均一なメトリック割り当てに従うように設計されたネットワークは、帯域幅メトリックを自動的に計算することにより、操作を簡素化することをお勧めします。FADがメトリックタイプを帯域幅メトリックとして宣伝し、リンクに帯域幅メトリックが宣伝されていない場合、このセクションで説明されている追加のFAD制約広告で自動メトリック導入を使用できます。
If a link's bandwidth changes, then the delay in learning about the change may create the possibility of micro-loops in the topology. This is no different from the IGP's susceptibility to micro-loops during a metric change. The micro-loop avoidance procedures described in [SR-LOOP-AVOID] or any other mechanism as described in the framework [RFC5715] can be used to avoid micro-loops when the automatic metric calculation is deployed.
リンクの帯域幅が変化した場合、変化について学習することの遅延により、トポロジにマイクロループの可能性が生じる可能性があります。これは、メトリックの変化中のマイクロループに対するIGPの感受性と違いはありません。[SR-Loop-Avoid]で説明されているマイクロループ回避手順またはフレームワーク[RFC5715]に記載されている他のメカニズムを使用して、自動メトリック計算が展開されたときにマイクロループを回避できます。
Computing the metric between adjacent systems based on bandwidth becomes more complex in the case of parallel adjacencies. If there are parallel adjacencies between systems, then the bandwidth between the systems is the sum of the bandwidth of the parallel links. This is somewhat more complex to deal with, so there is an optional mode for computing the aggregate bandwidth.
帯域幅に基づいた隣接するシステム間のメトリックを計算すると、並列隣接の場合、より複雑になります。システム間に並列隣接がある場合、システム間の帯域幅は並列リンクの帯域幅の合計です。これはやや複雑であるため、集約帯域幅を計算するためのオプションモードがあります。
In Simple Mode, the Maximum Link Bandwidth of a single Layer 3 link is used to derive the metric. This mode is suitable for deployments that do not use parallel Layer 3 links. In this case, the computation of the metric is straightforward. If a Layer 3 link is composed of a Layer 2 bundle, then the link bandwidth is the sum of the bandwidths of the working components and may vary with Layer 2 link failures.
単純なモードでは、単一層3リンクの最大リンク帯域幅を使用してメトリックを導き出します。このモードは、平行レイヤー3リンクを使用しない展開に適しています。この場合、メトリックの計算は簡単です。レイヤー3リンクがレイヤー2バンドルで構成されている場合、リンク帯域幅は作業コンポーネントの帯域幅の合計であり、レイヤー2リンク障害によって異なる場合があります。
The Simple Mode of metric calculation may not work well when there are multiple parallel Layer 3 interfaces between two nodes. Ideally, the metric between two systems should be the same given the same bandwidth, whether the bandwidth is provided by parallel Layer 2 links or parallel Layer 3 links. To address this, in Interface Group Mode, nodes MUST compute the aggregate bandwidth of all parallel adjacencies, MUST derive the metric based on the aggregate bandwidth, and MUST apply the resulting metric to each of the parallel adjacencies. Note that a single elephant flow is normally pinned to a single Layer 3 interface. If the single Layer 3 link bandwidth is not sufficient for any single elephant flow, the mechanisms to solve this issue are outside the scope of this document.
2つのノード間に複数の平行レイヤー3インターフェイスがある場合、メトリック計算の単純なモードはうまく機能しない場合があります。理想的には、帯域幅が平行レイヤー2リンクまたはパラレルレイヤー3リンクによって提供されるかどうかにかかわらず、2つのシステム間のメトリックは同じ帯域幅を考えると同じでなければなりません。これに対処するには、インターフェイスグループモードで、ノードはすべての並列隣接の集約帯域幅を計算し、集約帯域幅に基づいてメトリックを導出する必要があり、結果のメトリックを各並列隣接に適用する必要があります。単一の象の流れは通常、単一層3インターフェイスに固定されていることに注意してください。単一の象の流れに単一層3リンク帯域幅が十分でない場合、この問題を解決するメカニズムはこのドキュメントの範囲外です。
A------B====C====F====D
| |
------E-------
Figure 7: Parallel Interfaces
図7：平行インターフェイス
For example, in the above diagram, there are two parallel links between B->C, C->F, F->D. Let us assume the link bandwidth is uniform 10 Gbps on all links. When bandwidth is used to derive the metric for the links, the metric for each link will be the same. Traffic from B to D will be forwarded as B->E->D because the metric will be lower. Since the bandwidth is higher on the B->C->F->D path, the metric for that path should be lower than the B->E->D path to attract the traffic on the B->C->F->D path. Interface Group Mode should be preferred in cases where there are parallel Layer 3 links.
たとえば、上記の図には、b-> c、c-> f、f-> dの間に2つの並列リンクがあります。リンク帯域幅がすべてのリンクで均一な10 gbpsであると仮定しましょう。帯域幅を使用してリンクのメトリックを導出する場合、各リンクのメトリックは同じになります。bからdへのトラフィックは、メトリックが低くなるため、b-> e-> dとして転送されます。帯域幅はb-> c-> f-> dパスで高いため、そのパスのメトリックはb-> e-> dパスよりも低くする必要があります。インターフェイスグループモードは、並列レイヤー3リンクがある場合に推奨される必要があります。
In the Interface Group Mode, every node MUST identify the set of parallel links between a pair of nodes based on IGP link advertisements and MUST consider cumulative bandwidth of the parallel links while arriving at the metric of each link.
インターフェイスグループモードでは、すべてのノードがIGPリンク広告に基づくノードのペア間の並列リンクのセットを識別する必要があり、各リンクのメトリックに到達しながら並列リンクの累積帯域幅を考慮する必要があります。
The parallel Layer 3 links between two nodes may not have the same bandwidth. In such cases, the method described in Interface Group Mode will result in the same metric being used for all the parallel links, which may cause undesired load balancing on the links. In such cases, a device may locally apply a load-balancing factor relative to the link bandwidth on the ECMP next hops. The load-balancing mechanisms are outside the scope of this document.
2つのノード間の平行レイヤー3リンクには、同じ帯域幅がない場合があります。このような場合、インターフェイスグループモードで説明されている方法は、すべての並列リンクに同じメトリックが使用され、リンク上の望ましくない負荷バランスを引き起こす可能性があります。そのような場合、デバイスは、ECMPの次のホップのリンク帯域幅に対する負荷バランス係数を局所的に適用する場合があります。負荷分散メカニズムは、このドキュメントの範囲外です。
In automatic metric calculation for simple and Interface Group Mode, Maximum Link Bandwidth of the links is used to derive the metric. There are two types of automatic metric derivation methods.
シンプルおよびインターフェイスグループモードの自動メトリック計算では、リンクの最大リンク帯域幅を使用してメトリックを導き出します。自動メトリック導入方法には2つのタイプがあります。
1. Reference bandwidth method
1. 参照帯域幅方式
2. Bandwidth thresholds method
2. 帯域幅のしきい値法
In many networks, the metric is inversely proportional to the link bandwidth. The administrator or implementation selects a reference bandwidth and the metric is derived by dividing the reference bandwidth by the advertised Maximum Link Bandwidth. Advertising the reference bandwidth in the FAD constraints allows the metric computation to be done on every node for each link. The metric is computed using reference bandwidth and the advertised link bandwidth. Centralized control of this reference bandwidth simplifies management in the case where the reference bandwidth changes. In order to ensure that small bandwidth changes do not change the link metric, it is useful to define the granularity of the bandwidth that is of interest. The link bandwidth will be truncated to this granularity before deriving the metric.
多くのネットワークでは、メトリックはリンク帯域幅に反比例します。管理者または実装は、参照帯域幅を選択し、メトリックは、参照帯域幅を広告された最大リンク帯域幅で除算することにより導出されます。FAD制約の参照帯域幅を広告することにより、各リンクのすべてのノードでメトリック計算を実行できます。メトリックは、参照帯域幅と広告リンク帯域幅を使用して計算されます。この参照帯域幅の集中制御は、参照帯域幅が変化する場合の管理を簡素化します。小さな帯域幅の変化がリンクメトリックを変更しないようにするために、興味のある帯域幅の粒度を定義することが役立ちます。リンク帯域幅は、メトリックを導出する前にこの粒度に切り捨てられます。
For example,
例えば、
reference bandwidth = 1000G
参照帯域幅= 1000g
Granularity = 20G
粒度= 20g
The derived metric is 10 for link bandwidth in the range 100G to 119G
派生メトリックは、100g〜119gの範囲のリンク帯域幅の10です
The reference bandwidth approach described above provides a uniform metric value for a range of link bandwidths. In certain cases, there may be a need to define non-proportional metric values for the varying ranges of link bandwidth. For example, bandwidths from 10G to 30G are assigned metric value 100, bandwidth from 30G to 70G are assigned a metric value of 50, and bandwidths greater than 70G have a metric of 10. In order to support this, a staircase mapping based on bandwidth thresholds is supported in the FAD. This advertisement contains a set of threshold values and associated metrics.
上記の参照帯域幅アプローチは、さまざまなリンク帯域幅の均一なメトリック値を提供します。特定のケースでは、リンク帯域幅のさまざまな範囲の非依存性メトリック値を定義する必要がある場合があります。たとえば、10gから30gの帯域幅にはメートル値100が割り当てられ、30gから70gの帯域幅に50のメートル幅が割り当てられ、帯域幅は70gを超えるメートルートの10です。この広告には、一連のしきい値値と関連するメトリックが含まれています。
This section provides FAD constraint advertisement details for the reference bandwidth method of metric calculation, as described in Section 4.1.2.1. The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
このセクションでは、セクション4.1.2.1で説明されているように、メトリック計算の参照帯域幅法のFAD制約広告の詳細を示します。柔軟なアルゴリズム定義参照帯域幅（FADRB）Sub-TLVは、IS-IS FAD Sub-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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IS-IS FADRB Sub-TLV
図8：IS-IS FADRB Sub-TLV
where:
ただし：
Type (1 octet):
タイプ（1オクテット）：
An 8-bit field assigned by IANA (8). This value uniquely identifies the IS-IS FADRB sub-TLV.
IANA（8）によって割り当てられた8ビットフィールド。この値は、IS-IS FADRBサブTLVを一意に識別します。
Length (1 octet):
長さ（1オクテット）：
An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to 9.
後続のフィールドのオクテットの総長さを示す8ビットフィールド。このサブTLVの場合、長さは9に設定されます。
Flags (1 octet):
フラグ（1オクテット）：
An 8-bit field containing flags.
フラグを含む8ビットフィールド。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| |
+-+-+-+-+-+-+-+-+
G-flag:
g-flag：
When set, Interface Group Mode MUST be used to derive total link bandwidth. Unassigned bits MUST be set to zero and MUST be ignored by the receiver.
設定すると、インターフェイスグループモードを使用して、総リンク帯域幅を導出する必要があります。未割り当てのビットはゼロに設定する必要があり、受信機は無視する必要があります。
Reference Bandwidth (4 octets):
参照帯域幅（4オクテット）：
A 32-bit field with Bandwidth encoded in IEEE floating point format [IEEE754-2019]. The units are bytes per second.
IEEEフローティングポイント形式[IEEE754-2019]でエンコードされた帯域幅のある32ビットフィールド。ユニットは1秒あたりのバイトです。
Granularity Bandwidth (4 octets):
粒度の帯域幅（4オクテット）：
A 32-bit field with Bandwidth encoded in IEEE floating point format [IEEE754-2019]. The units are bytes per second.
IEEEフローティングポイント形式[IEEE754-2019]でエンコードされた帯域幅のある32ビットフィールド。ユニットは1秒あたりのバイトです。
When granularity_bw is less than or equal to Total_link_bandwidth, then:
Granularity_BWがtotal_link_bandwidth以下の場合、
Metric calculation:
メトリック計算：
(Reference_bandwidth) / (Total_link_bandwidth - (Modulus of(Total_link_bandwidth, granularity_bw)))
（Reference_Bandwidth） /（total_link_bandwidth-（modulus of（total_link_bandwidth、granularity_bw））））
When granularity_bw is greater than Total_link_bandwidth, then:
Granularity_BWがTotal_link_bandwidthよりも大きい場合、
Metric calculation:
メトリック計算：
Reference_bandwidth / Total_link_bandwidth
Reference_Bandwidth / total_link_bandwidth
The division used here is integer division. Modulus of operation is defined as a remainder value when two numbers are divided.
ここで使用される部門は整数部門です。動作弾性率は、2つの数値が分割されている場合、残りの値として定義されます。
The Granularity Bandwidth value ensures that the metric does not change when there is a small change in the link bandwidth. The IS-IS FADRB sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver. The value advertised in the Reference Bandwidth field MUST be non-zero. If a zero value is advertised in the Reference Bandwidth field in the IS-IS FADRB sub-TLV, the sub-TLV MUST be ignored.
粒度の帯域幅値は、リンク帯域幅に小さな変化がある場合、メトリックが変化しないことを保証します。IS-IS FADRB SUB-TLVは、IS-IS FAD SUB-TLVに1回以上表示されてはなりません。複数回表示される場合、IS-IS FADサブTLVはレシーバーによって無視する必要があります。参照帯域幅フィールドで宣伝されている値は、ゼロ以外でなければなりません。IS-IS FADRB SUB-TLVの参照帯域幅フィールドにゼロ値が宣伝されている場合、SUB-TLVは無視する必要があります。
If a Generic Metric sub-TLV with a Bandwidth metric-type is advertised for a link, the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric and MUST NOT use the automatically derived metric for that link.
帯域幅メトリックタイプを備えた汎用メトリックサブTLVがリンクに対して宣伝されている場合、フレックスアルゴリズムの計算は、広告された帯域幅メトリックを使用する必要があり、そのリンクの自動導出メトリックを使用してはなりません。
In case of Interface Group Mode, the following rules apply to parallel links:
インターフェイスグループモードの場合、次のルールが並列リンクに適用されます。
* If all the parallel links have been advertised with the Bandwidth Metric:
* すべての平行リンクが帯域幅メトリックで宣伝されている場合：
The individual link Bandwidth Metric MUST be used.
個々のリンク帯域幅メトリックを使用する必要があります。
* If only some links among the parallel links have advertised the Bandwidth Metric:
* 並列リンク間のいくつかのリンクのみが帯域幅メトリックを宣伝している場合：
- The Bandwidth Metric for such links MUST be ignored.
- このようなリンクの帯域幅メトリックは無視する必要があります。
- Automatic metric calculation MUST be used to derive the link metric.
- リンクメトリックを導出するために、自動メトリック計算を使用する必要があります。
If the calculated metric evaluates to zero, a metric of 1 MUST be used.
計算されたメトリックがゼロに評価される場合、1のメトリックを使用する必要があります。
If the calculated metric evaluates to a number greater than 0xFFFFFF, it is set to 0xFFFFFF.
計算されたメトリックが0xffffffを超える数値に評価された場合、0xffffffに設定されます。
This section provides FAD constraint advertisement details for the Bandwidth Thresholds method of metric calculation as described in Section 4.1.2.2. The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
このセクションでは、セクション4.1.2.2で説明されているように、メトリック計算の帯域幅のしきい値法のFAD制約広告の詳細を示します。柔軟なアルゴリズム定義帯域幅のしきい値（FADBT）Sub-TLVは、IS-IS FAD Sub-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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IS-IS FADBT Sub-TLV
図9：IS-IS FADBT Sub-TLV
where:
ただし：
Type (1 octet):
タイプ（1オクテット）：
An 8-bit field assigned by IANA (9). This value uniquely identifies the IS-IS FADBT sub-TLV.
IANA（9）によって割り当てられた8ビットフィールド。この値は、IS-IS FADBTサブTLVを一意に識別します。
Length (1 octet):
長さ（1オクテット）：
An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is calculated as (1+N*7). Here, N is equal to the number of Threshold Metrics specified. N MUST be greater than or equal to 1.
後続のフィールドのオクテットの総長さを示す8ビットフィールド。このサブTLVでは、長さは（1+n*7）として計算されます。ここで、nは指定されたしきい値メトリックの数に等しくなります。nは1以上でなければなりません。
Flags (1 octet):
フラグ（1オクテット）：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| | | |
+-+-+-+-+-+-+-+-+
G-flag:
g-flag：
When set, Interface Group Mode MUST be used to derive total link bandwidth. Unassigned bits MUST be set to zero and MUST be ignored by the receiver.
設定すると、インターフェイスグループモードを使用して、総リンク帯域幅を導出する必要があります。未割り当てのビットはゼロに設定する必要があり、受信機は無視する必要があります。
Following is the staircase bandwidth threshold and associated metric values.
以下は、階段帯域幅のしきい値と関連するメトリック値です。
Bandwidth Threshold 1 (4 octets):
帯域幅のしきい値1（4オクテット）：
Minimum Link Bandwidth is encoded in IEEE floating point format (32 bits)[IEEE754-2019]. The units are bytes per second.
最小リンク帯域幅は、IEEEフローティングポイント形式（32ビット）[IEEE754-2019]でエンコードされています。ユニットは1秒あたりのバイトです。
Threshold Metric 1 (3 octets):
しきい値メトリック1（3オクテット）：
Metric value range (1 - 16,777,215 (0xFFFFFF))
メトリック値範囲（1-16,777,215（0xffffff））
Bandwidth Threshold N (4 octets):
帯域幅のしきい値n（4オクテット）：
Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits)[IEEE754-2019]. The units are bytes per second.
最大リンク帯域幅は、IEEEフローティングポイント形式（32ビット）[IEEE754-2019]でエンコードされています。ユニットは1秒あたりのバイトです。
Threshold Metric N (3 octets):
しきい値メトリックN（3オクテット）：
Metric value range (1 - 16,777,215 (0xFFFFFF))
メトリック値範囲（1-16,777,215（0xffffff））
When the G-flag is set, the cumulative bandwidth of the parallel links is computed as described in Section 4.1.1.2. If the G-flag is not set, the advertised Maximum Link Bandwidth is used.
G-Flagが設定されると、並列リンクの累積帯域幅は、セクション4.1.1.2で説明されているように計算されます。G-Flagが設定されていない場合、広告された最大リンク帯域幅が使用されます。
The assignment of the Bandwidth Metric based on computed link bandwidth is described below.
計算されたリンク帯域幅に基づく帯域幅メトリックの割り当てを以下に説明します。
The Bandwidth Metric for a link during the Flex-Algorithm Shortest Path First (SPF) calculation MUST be assigned according to the following rules:
Flex-Algorithm最短パス（SPF）計算中のリンクの帯域幅メトリックは、次のルールに従って割り当てる必要があります。
1. When the computed link bandwidth is less than Bandwidth Threshold 1:
1. 計算されたリンクの帯域幅が帯域幅のしきい値より少ない場合：
The Bandwidth Metric MUST be set to the maximum metric value of 4,261,412,864.
帯域幅メトリックは、4,261,412,864の最大メトリック値に設定する必要があります。
2. When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold 2:
2. 計算されたリンク帯域幅が帯域幅のしきい値1以上で、帯域幅のしきい値2未満の場合：
The Bandwidth Metric MUST be set to Threshold Metric 1.
帯域幅メトリックは、しきい値メトリック1に設定する必要があります。
3. When the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold 3:
3. 計算されたリンク帯域幅が帯域幅のしきい値2以上で、帯域幅のしきい値3以下の場合：
The Bandwidth Metric MUST be set to Threshold Metric 2.
帯域幅メトリックは、しきい値メトリック2に設定する必要があります。
4. In general, for all integer values of X such that 1 ≤ X < N:
4. 一般に、xのすべての整数値について、1≤x<n：
When the computed link bandwidth is greater than or equal to Bandwidth Threshold X and less than Bandwidth Threshold X+1:
計算されたリンク帯域幅が帯域幅のしきい値x以上で、帯域幅のしきい値x+1未満の場合：
The Bandwidth Metric MUST be set to Threshold Metric X.
帯域幅メトリックは、しきいメトリックXに設定する必要があります。
5. When the computed link bandwidth is greater than or equal to Bandwidth Threshold N:
5. 計算されたリンク帯域幅が帯域幅のしきい値n以下の場合：
The Bandwidth Metric MUST be set to Threshold Metric N.
帯域幅メトリックは、しきいメトリックNに設定する必要があります。
Notes:
注：
* The term "Bandwidth Threshold X" refers to a predefined threshold value corresponding to the index X.
* 「帯域幅のしきい値x」という用語は、インデックスxに対応する事前定義されたしきい値を指します。
* The term "Threshold Metric X" refers to the metric value associated with Bandwidth Threshold X.
* 「しきい値X」という用語は、帯域幅のしきい値Xに関連付けられたメトリック値を指します。
* N represents the total number of bandwidth thresholds defined in the system.
* nは、システムで定義されている帯域幅のしきい値の総数を表します。
Implementations MUST ensure that these rules are consistently applied to maintain interoperability and optimal path computation within the network.
実装は、ネットワーク内の相互運用性と最適なパス計算を維持するために、これらのルールが一貫して適用されることを確認する必要があります。
The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver.
IS-IS FADBT Sub-TLVは、IS-IS FAD Sub-TLVに1回以上表示されてはなりません。複数回表示される場合、IS-IS FADサブTLVはレシーバーによって無視する必要があります。
A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If both of these sub-TLVs are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver.
FADには、FADBT SUB-TLVとFADRB SUB-TLVの両方が含まれていないはずです。これらのサブTLVの両方が柔軟なアルゴリズムのために同じFADで宣伝されている場合、FADは受信機によって無視する必要があります。
If a Generic Metric sub-TLV with Bandwidth metric-type is advertised for a link, the Flex-Algorithm calculation MUST use the Bandwidth Metric advertised on the link and MUST NOT use the automatically derived metric for that link.
帯域幅メトリックタイプを備えた汎用メトリックサブTLVがリンクに対して宣伝されている場合、フレックスアルゴリズムの計算は、リンクに宣伝されている帯域幅メトリックを使用する必要があり、そのリンクの自動導出メトリックを使用してはなりません。
In case of Interface Group Mode, the following rules apply to parallel links:
インターフェイスグループモードの場合、次のルールが並列リンクに適用されます。
* If all the parallel links have been advertised with the Bandwidth Metric:
* すべての平行リンクが帯域幅メトリックで宣伝されている場合：
The individual link Bandwidth Metric MUST be used.
個々のリンク帯域幅メトリックを使用する必要があります。
* If only some links among the parallel links have advertised the Bandwidth Metric:
* 並列リンク間のいくつかのリンクのみが帯域幅メトリックを宣伝している場合：
- The Bandwidth Metric for such links MUST be ignored.
- このようなリンクの帯域幅メトリックは無視する必要があります。
- Automatic metric calculation MUST be used to derive the link metric.
- リンクメトリックを導出するために、自動メトリック計算を使用する必要があります。
The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format:
柔軟なアルゴリズム定義参照帯域幅（FADRB）Sub-TLVは、OSPF FAD 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: OSPF FADRB Sub-TLV
図10：OSPF FADRB SUB-TLV
where:
ただし：
Type (2 octets):
タイプ（2オクテット）：
A 16-bit field assigned by IANA (8). This value uniquely identifies the OSPF FADRB sub-TLV.
IANA（8）によって割り当てられた16ビットフィールド。この値は、OSPF FADRB Sub-TLVを一意に識別します。
Length (2 octets):
長さ（2オクテット）：
A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, Length is set to 14.
後続のフィールドのオクテットの総長さを示す16ビットフィールド。このサブTLVの場合、長さは14に設定されています。
Flags (1 octet):
フラグ（1オクテット）：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| | | |
+-+-+-+-+-+-+-+-+
G-flag:
g-flag：
When set, Interface Group Mode MUST be used to derive total link bandwidth. Unassigned bits MUST be set to zero and MUST be ignored by the receiver.
設定すると、インターフェイスグループモードを使用して、総リンク帯域幅を導出する必要があります。未割り当てのビットはゼロに設定する必要があり、受信機は無視する必要があります。
Reference Bandwidth (4 octets):
参照帯域幅（4オクテット）：
Bandwidth encoded in 32 bits in IEEE floating point format [IEEE754-2019]. The units are in bytes per second.
IEEEフローティングポイント形式で32ビットでエンコードされた帯域幅[IEEE754-2019]。ユニットは毎秒バイトです。
Granularity Bandwidth (4 octets):
粒度の帯域幅（4オクテット）：
Bandwidth encoded in 32 bits in IEEE floating point format [IEEE754-2019]. The units are in bytes per second.
IEEEフローティングポイント形式で32ビットでエンコードされた帯域幅[IEEE754-2019]。ユニットは毎秒バイトです。
When granularity_bw is less than or equal to Total_link_bandwidth, then:
Granularity_BWがtotal_link_bandwidth以下の場合、
Metric calculation:
メトリック計算：
(Reference_bandwidth) / (Total_link_bandwidth - (Modulus of(Total_link_bandwidth, granularity_bw)))
（Reference_Bandwidth） /（total_link_bandwidth-（modulus of（total_link_bandwidth、granularity_bw））））
When granularity_bw is greater than Total_link_bandwidth, then:
Granularity_BWがTotal_link_bandwidthよりも大きい場合、
Metric calculation:
メトリック計算：
Reference_bandwidth/ Total_link_bandwidth
Reference_Bandwidth/ total_link_bandwidth
The division used here is integer division.
ここで使用される部門は整数部門です。
Modulus of operation is defined as a remainder value when two numbers are divided.
動作弾性率は、2つの数値が分割されている場合、残りの値として定義されます。
The Granularity Bandwidth value is used to ensure that the metric does not change when there is a small change in the link bandwidth. The OSPF FADRB sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. The value advertised in the Reference Bandwidth field MUST be non-zero. If a zero value is advertised in the Reference Bandwidth field in the OSPF FADRB sub-TLV, the sub-TLV MUST be ignored. If a Generic Metric sub-TLV with Bandwidth metric-type is advertised for a link, the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric on the link and MUST NOT use the automatically derived metric for that link. In the case of Interface Group Mode, the following procedures apply:
粒度の帯域幅値は、リンク帯域幅に小さな変化があるときにメトリックが変化しないことを確認するために使用されます。OSPF FADRB SUB-TLVは、OSPF FAD TLVに1回以上表示されてはなりません。複数回見える場合は、OSPF FAD TLVを受信機によって無視する必要があります。参照帯域幅フィールドで宣伝されている値は、ゼロ以外でなければなりません。OSPF FADRB SUB-TLVの参照帯域幅フィールドにゼロ値が宣伝されている場合、SUB-TLVは無視する必要があります。帯域幅メトリックタイプを備えた汎用メトリックサブTLVがリンクに対して宣伝されている場合、フレックスアルゴリズムの計算は、リンク上の広告帯域幅メトリックを使用する必要があり、そのリンクの自動導出メトリックを使用してはなりません。インターフェイスグループモードの場合、次の手順が適用されます。
* When all parallel links have advertised the Bandwidth Metric: The individual link Bandwidth Metric MUST be used for each link.
* すべての平行リンクが帯域幅メトリックを宣伝している場合：個々のリンク帯域幅メトリックを各リンクに使用する必要があります。
* When only a subset of the parallel links have advertised the Bandwidth Metric: The Bandwidth Metric advertisements for those links MUST be ignored. In this scenario, automatic metric calculation MUST be used to derive the link metrics for all parallel links.
* 並列リンクのサブセットのみが帯域幅メトリックを宣伝している場合：それらのリンクの帯域幅メトリック広告は無視する必要があります。このシナリオでは、自動メトリック計算を使用して、すべての並列リンクのリンクメトリックを導出する必要があります。
If the calculated metric evaluates to zero, a metric of 1 MUST be used.
計算されたメトリックがゼロに評価される場合、1のメトリックを使用する必要があります。
If the calculated metric evaluates to a number greater than 0xFFFFFFFF, it is set to 0xFFFFFFFF.
計算されたメトリックが0xffffffffffを超える数値に評価される場合、0xffffffffに設定されます。
The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format:
柔軟なアルゴリズム定義帯域幅のしきい値（FADBT）Sub-TLVは、OSPF FAD 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: OSPF FADBT Sub-TLV
図11：OSPF FADBT SUB-TLV
where:
ただし：
Type (2 octets):
タイプ（2オクテット）：
A 16-bit field assigned by IANA (9). This value uniquely identifies the OSPF FADBT sub-TLV.
IANA（9）によって割り当てられた16ビットフィールド。この値は、OSPF FADBT Sub-TLVを一意に識別します。
Length (2 octets):
長さ（2オクテット）：
A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, Length is set to 2 + N*8 octets. Here, N is equal to the number of Threshold Metrics specified. N MUST be greater than or equal to 1.
後続のフィールドのオクテットの総長さを示す16ビットフィールド。このサブTLVでは、長さは2 + n*8オクテットに設定されています。ここで、nは指定されたしきい値メトリックの数に等しくなります。nは1以上でなければなりません。
Flags (1 octet):
フラグ（1オクテット）：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| |
+-+-+-+-+-+-+-+-+
G-flag:
g-flag：
When set, Interface Group Mode MUST be used to derive total link bandwidth. Unassigned bits MUST be set to zero and MUST be ignored by the receiver.
設定すると、インターフェイスグループモードを使用して、総リンク帯域幅を導出する必要があります。未割り当てのビットはゼロに設定する必要があり、受信機は無視する必要があります。
Following is the staircase bandwidth threshold and associated metric values.
以下は、階段帯域幅のしきい値と関連するメトリック値です。
Bandwidth Threshold 1 (4 octets):
帯域幅のしきい値1（4オクテット）：
Minimum Link Bandwidth is encoded in IEEE floating point format (32 bits)[IEEE754-2019]. The units are bytes per second.
最小リンク帯域幅は、IEEEフローティングポイント形式（32ビット）[IEEE754-2019]でエンコードされています。ユニットは1秒あたりのバイトです。
Threshold Metric 1 (4 octets):
しきい値メトリック1（4オクテット）：
Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))
メートル値範囲（1-4,294,967,296（0xffffffff））
Bandwidth Threshold N (4 octets):
帯域幅のしきい値n（4オクテット）：
Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits)[IEEE754-2019]. The units are bytes per second.
最大リンク帯域幅は、IEEEフローティングポイント形式（32ビット）[IEEE754-2019]でエンコードされています。ユニットは1秒あたりのバイトです。
Threshold Metric N (4 octets):
しきい値メトリックN（4オクテット）：
Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))
メートル値範囲（1-4,294,967,296（0xffffffff））
When the G-flag is set, the cumulative bandwidth of the parallel links is computed as described in Section 4.1.1.2. If the G-flag is not set, the advertised Maximum Link Bandwidth is used.
G-Flagが設定されると、並列リンクの累積帯域幅は、セクション4.1.1.2で説明されているように計算されます。G-Flagが設定されていない場合、広告された最大リンク帯域幅が使用されます。
The assignment of the Bandwidth Metric based on computed link bandwidth is described below.
計算されたリンク帯域幅に基づく帯域幅メトリックの割り当てを以下に説明します。
During the Flex-Algorithm SPF calculation, the Bandwidth Metric for a link MUST be assigned according to the following rules:
Flex-Algorithm SPF計算中、リンクの帯域幅メトリックは、次のルールに従って割り当てる必要があります。
1. When the computed link bandwidth is less than Bandwidth Threshold 1:
1. 計算されたリンクの帯域幅が帯域幅のしきい値より少ない場合：
The Bandwidth Metric MUST be set to the maximum metric value of 4,294,967,296.
帯域幅メトリックは、4,294,967,296の最大メトリック値に設定する必要があります。
2. When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold 2:
2. 計算されたリンク帯域幅が帯域幅のしきい値1以上で、帯域幅のしきい値2未満の場合：
The Bandwidth Metric MUST be set to Threshold Metric 1.
帯域幅メトリックは、しきい値メトリック1に設定する必要があります。
3. When the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold 3:
3. 計算されたリンク帯域幅が帯域幅のしきい値2以上で、帯域幅のしきい値3以下の場合：
The Bandwidth Metric MUST be set to Threshold Metric 2.
帯域幅メトリックは、しきい値メトリック2に設定する必要があります。
4. In general, for all integer values of X where 1 ≤X < N:
4. 一般に、xのすべての整数値について1≤x<n：
When the computed link bandwidth is greater than or equal to Bandwidth Threshold X and less than Bandwidth Threshold X+1:
計算されたリンク帯域幅が帯域幅のしきい値x以上で、帯域幅のしきい値x+1未満の場合：
The Bandwidth Metric MUST be set to Threshold Metric X.
帯域幅メトリックは、しきいメトリックXに設定する必要があります。
5. When the computed link bandwidth is greater than or equal to Bandwidth Threshold N:
5. 計算されたリンク帯域幅が帯域幅のしきい値n以下の場合：
The Bandwidth Metric MUST be set to Threshold Metric N.
帯域幅メトリックは、しきいメトリックNに設定する必要があります。
Notes:
注：
* Bandwidth Threshold X refers to the predefined bandwidth threshold corresponding to index X.
* 帯域幅のしきい値Xは、インデックスXに対応する事前定義された帯域幅のしきい値を指します。
* Threshold Metric X is the metric value associated with Bandwidth Threshold X.
* しきい値メトリックXは、帯域幅のしきい値Xに関連するメトリック値です。
* N represents the total number of bandwidth thresholds defined in the system.
* nは、システムで定義されている帯域幅のしきい値の総数を表します。
Implementations MUST consistently apply these rules to ensure accurate path computations and maintain interoperability within the network.
実装は、これらのルールを一貫して適用して、正確なパス計算を確保し、ネットワーク内の相互運用性を維持する必要があります。
The OSPF FADBT sub-TLV MUST NOT appear more than once in an OSPF FAD sub-TLV. If it appears more than once, the OSPF FAD sub-TLV MUST be ignored by the receiver.
OSPF FADBT SUB-TLVは、OSPF FAD Sub-TLVに複数回表示してはなりません。複数回見える場合は、OSPF FAD Sub-TLVを受信機によって無視する必要があります。
A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If both these sub-TLVs are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver.
FADには、FADBT SUB-TLVとFADRB SUB-TLVの両方が含まれていないはずです。これらの両方のサブTLVが柔軟なアルゴリズムのために同じFADで宣伝されている場合、FADは受信機によって無視する必要があります。
If a Generic Metric sub-TLV with Bandwidth metric-type is advertised for a link, the Flex-Algorithm calculation MUST use the Bandwidth Metric advertised on the link and MUST NOT use the automatically derived metric for that link.
帯域幅メトリックタイプを備えた汎用メトリックサブTLVがリンクに対して宣伝されている場合、フレックスアルゴリズムの計算は、リンクに宣伝されている帯域幅メトリックを使用する必要があり、そのリンクの自動導出メトリックを使用してはなりません。
Metric Assignment in Interface Group Mode:
インターフェイスグループモードでのメトリック割り当て：
When a link does not have a configured Bandwidth Metric, the automatically derived metric MUST be used for that link.
リンクに構成された帯域幅メトリックがない場合、そのリンクに自動導出されたメトリックを使用する必要があります。
In case of Interface Group Mode, the following rules apply to parallel links:
インターフェイスグループモードの場合、次のルールが並列リンクに適用されます。
* If all parallel links have advertised the Bandwidth Metric:
* すべての平行リンクが帯域幅メトリックを宣伝している場合：
The individual link Bandwidth Metric MUST be used for each link during path computation.
パス計算中は、個々のリンク帯域幅メトリックを各リンクに使用する必要があります。
* If only some of the parallel links have advertised the Bandwidth Metric:
* 並列リンクの一部のみが帯域幅メトリックを宣伝している場合：
- The Bandwidth Metric advertisements for those links MUST be ignored.
- これらのリンクの帯域幅メトリック広告は無視する必要があります。
- Automatic metric calculation MUST be used to derive the link metrics for all parallel links.
- 自動メトリック計算を使用して、すべての並列リンクのリンクメトリックを導出する必要があります。
This approach ensures consistent metric calculation and avoids discrepancies caused by partial Bandwidth Metric advertisements among parallel links.
このアプローチは、一貫したメトリック計算を保証し、並列リンク間の部分帯域幅メトリック広告によって引き起こされる矛盾を回避します。
This section specifies the rules of deriving the Bandwidth Metric if and only if the winning FAD for the Flex-Algorithm specifies the metric-type as "Bandwidth Metric".
このセクションでは、フレックスアルゴリズムの勝利の流行がメトリックタイプを「帯域幅メトリック」として指定する場合にのみ、帯域幅メトリックを導出するというルールを指定します。
1. If the Generic Metric sub-TLV with Bandwidth metric-type is advertised for the link as described in Section 4, it MUST be used during the Flex-Algorithm calculation.
1. セクション4で説明されているように、帯域幅メトリックタイプを備えた一般的なメトリックサブTLVがリンクに対して宣伝されている場合、フレックスアルゴリズムの計算中に使用する必要があります。
2. If the Generic Metric sub-TLV with Bandwidth metric-type is not advertised for the link and the winning FAD for the Flex-Algorithm does not specify the automatic Bandwidth metric calculation (as defined in Section 4.1), the link is treated as if the Bandwidth Metric is not available for the link.
2. 帯域幅メトリックタイプを備えた汎用メトリックサブTLVがリンクに宣伝されておらず、フレックスアルゴリズムの勝利の流行が自動帯域幅メトリック計算（セクション4.1で定義されているように）を指定していない場合、リンクは帯域幅メトリックがリンクで使用できないかのように扱われます。
3. If the Generic Metric sub-TLV with Bandwidth metric-type is not advertised for the link and the winning FAD (Section 5.3 of [RFC9350]) for the Flex-Algorithm specifies the automatic Bandwidth metric calculation (as defined in Section 4.1), the Bandwidth Metric MUST be automatically calculated per the procedures defined in Section 4.1. If the Link Bandwidth is not advertised for a link, the link MUST be pruned for the Flex-Algorithm calculations.
3. 帯域幅メトリックタイプを備えた一般的なメトリックサブTLVがリンクに対して宣伝されておらず、Flex-Algorithmの勝者FAD（[RFC9350]のセクション5.3）が自動帯域幅メートル法の計算を指定している場合（セクション4.1で定義されているとおり）、帯域幅メトリックはセクション4.1で定義された手順で自動的に消費される必要があります。リンクの帯域幅がリンクに対して宣伝されていない場合、Flex-Algorithmの計算に対してリンクを剪定する必要があります。
4. In IS-IS, for Flex-Algorithm purposes, the Link Bandwidth is advertised as a sub-sub-TLV 9 of the Flex-Algorithm-specific ASLA sub-TLV. It is also possible to advertise the link bandwidth or Flex-Algorithm in sub-TLV 9 of TLVs 22/222/23/223/141 [RFC5305] together with the L-flag set in the Flex-Algorithm-specific ASLA advertisement. In the absence of both of these advertisements, the bandwidth of the link is not available for Flex-Algorithm purposes.
4. IS-ISでは、フレックスアルゴリズムの目的で、リンク帯域幅は、フレックスアルゴリズム固有のASLAサブTLVのサブサブTLV 9として宣伝されています。また、TLVS 22/222/23/223/223/141 [RFC5305]のサブTLV 9のリンク帯域幅またはフレックスアルゴリズムを宣伝することも可能です。これらの広告の両方がない場合、リンクの帯域幅はフレックスアルゴリズムの目的で使用できません。
The following two new additional rules are added to the existing rules in the Flex-Algorithm calculations specified in Section 13 of [RFC9350]:
次の2つの新しい追加ルールが、[RFC9350]のセクション13で指定されたFlex-Algorithm計算の既存のルールに追加されます。
6. Check if any exclude FAEMB rule is part of the Flex-Algorithm definition. If such exclude rule exists and the link has Maximum Link Bandwidth advertised, check if the link bandwidth satisfies the FAEMB rule. If the link does not satisfy the FAEMB rule, the link MUST be pruned from the Flex-Algorithm computation.
6. FAEMBルールを除外することがFlex-Algorithm定義の一部であるかどうかを確認してください。そのような除外ルールが存在し、リンクに最大リンク帯域幅が宣伝されている場合、リンク帯域幅がFAEMBルールを満たしているかどうかを確認します。リンクがFAEMBルールを満たしていない場合、リンクはFlex-Algorithmの計算から剪定する必要があります。
7. Check if any exclude FAEMD rule is part of the Flex-Algorithm definition. If such exclude rule exists and the link has Min Unidirectional link delay advertised, check if the link delay satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule, the link MUST be pruned from the Flex-Algorithm computation.
7. FAEMDルールを除外することがFlex-Algorithm定義の一部であるかどうかを確認してください。そのような除外ルールが存在し、リンクに最小単方向リンク遅延が宣伝されている場合、リンク遅延がFAEMDルールを満たしているかどうかを確認します。リンクがFAEMDルールを満たしていない場合、リンクはFlex-Algorithmの計算から剪定する必要があります。
This extension brings no new backward-compatibility issues. This document defines new FAD constraints in Sections 3, 4.1.3, and 4.1.4. As described in [RFC9350], any node that does not understand sub-TLVs in a FAD TLV stops participation in the corresponding Flex-Algorithm. The new extensions can be deployed among the nodes that are upgraded to understand the new extensions without affecting the nodes that are not upgraded. This document also defines a new metric advertisement as described in Section 2. As per Section 13 of [RFC9350], when the links do not advertise the metric-type specified by the selected FAD, the link is pruned from Flex-Algorithm calculations. The new metric-types and Flex-Algorithms using the new metric-types can be deployed in the network without affecting existing deployment.
この拡張機能は、新しい後方互換性の問題をもたらしません。このドキュメントでは、セクション3、4.1.3、および4.1.4の新しいFAD制約を定義しています。[RFC9350]で説明されているように、FAD TLVでサブTLVを理解していないノードは、対応するフレックスアルゴリズムへの参加を停止します。新しい拡張機能は、アップグレードされていないノードに影響を与えることなく、新しい拡張機能を理解するためにアップグレードされたノード間に展開できます。このドキュメントでは、セクション2で説明されている新しいメトリック広告も定義します。[RFC9350]のセクション13に従って、リンクが選択したFADで指定されたメトリックタイプを宣伝しない場合、リンクはフレックスアルゴリズムの計算から剪定されます。新しいメトリックタイプを使用した新しいメトリックタイプとフレックスアルゴリズムは、既存の展開に影響を与えることなくネットワークに展開できます。
This document inherits security considerations from [RFC9350].
このドキュメントは、[RFC9350]からのセキュリティ上の考慮事項を継承しています。
Operational considerations defined in [RFC9350] generally apply to the extensions defined in this document as well. This document defines a metric-type range for user-defined metrics. When user-defined metrics are used in an inter-area or inter-level network, all the domains should assign same meaning to the particular metric-type. The YANG data models for Flex-Algorithm extensions are defined in documents [OSPF-AUGMENTATION] and [ISIS-AUGMENTATION].
[RFC9350]で定義されている運用上の考慮事項は、一般に、このドキュメントで定義されている拡張機能にも適用されます。このドキュメントでは、ユーザー定義のメトリックのメトリックタイプの範囲を定義します。ユーザー定義のメトリックがエリア間またはレベル間ネットワークで使用される場合、すべてのドメインは特定のメトリックタイプに同じ意味を割り当てる必要があります。Flex-Algorithm拡張のYangデータモデルは、ドキュメント[OSPF-Augmentation]および[ISIS-Age-gmentation]で定義されています。
Before the router goes into maintenance activity, the traffic needs to be diverted away from the router. This is achieved by setting the overload bit or setting link metrics on the router to a high value. In case of Generic Metric, the link metrics can be set to a Maximum usable metric for OSPF and IS-IS. The traffic will be diverted away from the router to a shorter available path. If there are no alternate paths available, traffic will stay on the router as the links are not removed from the Flex-Algorithm calculation when they are set to a maximum metric per [RFC9350].
ルーターがメンテナンスアクティビティに入る前に、トラフィックをルーターから遠ざける必要があります。これは、オーバーロードビットを設定するか、ルーターのリンクメトリックを高い値に設定することで達成されます。一般的なメトリックの場合、リンクメトリックはOSPFおよびIS-ISの最大使用可能なメトリックに設定できます。トラフィックは、ルーターから利用可能な短いパスに迂回されます。使用可能な代替パスがない場合、リンクが[RFC9350]ごとに最大メトリックに設定されている場合、リンクがFlex-Algorithmの計算から削除されないため、トラフィックはルーターにとどまります。
The "IGP Metric-Type" registry has been updated to include another column specifying whether the particular metric-type is allowed in the Generic Metric sub-TLV. The range 128-255 is redefined by this document as a user-defined range, and this range does not require Standards Action [RFC8126].
「IGPメトリックタイプ」レジストリが更新され、特定のメトリックタイプが汎用メトリックサブTLVで許可されているかどうかを指定する別の列が含まれています。範囲128-255は、このドキュメントによってユーザー定義の範囲として再定義されており、この範囲には標準アクション[RFC8126]は必要ありません。
+=========+===========================+===========+================+
| Type | Description | Reference | Allowed in |
| | | | Generic-Metric |
+=========+===========================+===========+================+
| 0 | IGP Metric | Section | No |
| | | 5.1 of | |
| | | [RFC9350] | |
+---------+---------------------------+-----------+----------------+
| 1 | Min Unidirectional Link | Section | No |
| | Delay as defined in | 5.1 of | |
| | [RFC8570], Section 4.2 | [RFC9350] | |
| | and [RFC7471], | | |
| | Section 4.2 | | |
+---------+---------------------------+-----------+----------------+
| 2 | Traffic Engineering | Section | No |
| | Default Metric as defined | 5.1 of | |
| | in [RFC5305], Section 3.7 | [RFC9350] | |
| | and Traffic Engineering | | |
| | Metric as defined in | | |
| | [RFC3630], Section 2.5.5 | | |
+---------+---------------------------+-----------+----------------+
| 3 | Bandwidth Metric | RFC 9843 | Yes |
+---------+---------------------------+-----------+----------------+
| 128-255 | Reserved for User-Defined | RFC 9843 | Yes |
| | Metric | | |
+---------+---------------------------+-----------+----------------+
Table 1: IGP Metric-Type Registry
表1：IGPメトリックタイプのレジストリ
The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry is part of the "IS-IS TLV Codepoints" registry group.
「柔軟なアルゴリズム定義サブTLVのIS-ISサブサブTLV」レジストリは、「IS-IS TLV CodePoints」レジストリグループの一部です。
Type:
タイプ：
6
6
Description:
説明：
IS-IS Exclude Minimum Bandwidth
is-isは最小帯域幅を除外します
Reference:
参照：
RFC 9843, Section 3.1.1
RFC 9843、セクション3.1.1
Type:
タイプ：
7
7
Description:
説明：
IS-IS Exclude Maximum Delay
IS-ISは最大遅延を除外します
Reference:
参照：
RFC 9843, Section 3.1.2
RFC 9843、セクション3.1.2
Type:
タイプ：
8
8
Description:
説明：
IS-IS Reference Bandwidth
IS-IS参照帯域幅
Reference:
参照：
RFC 9843, Section 4.1.3.1
RFC 9843、セクション4.1.3.1
Type:
タイプ：
9
9
Description:
説明：
IS-IS Bandwidth Threshold
IS-IS帯域幅のしきい値
Reference:
参照：
RFC 9843, Section 4.1.3.2
RFC 9843、セクション4.1.3.2
The "OSPF Flexible Algorithm Definition TLV Sub-TLVs" registry is part of the "Open Shortest Path First (OSPF) Parameters" registry group.
「OSPF Flexible Algorithm Definition TLV Sub-TLVS」レジストリは、「Open Shortest Path First（OSPF）パラメーター」レジストリグループの一部です。
Type:
タイプ：
6
6
Description:
説明：
OSPF Exclude Minimum Bandwidth
OSPFは最小帯域幅を除外します
Reference:
参照：
RFC 9843, Section 3.2.1
RFC 9843、セクション3.2.1
Type:
タイプ：
7
7
Description:
説明：
OSPF Exclude Maximum Delay
OSPFは最大遅延を除外します
Reference:
参照：
RFC 9843, Section 3.2.2
RFC 9843、セクション3.2.2
Type:
タイプ：
8
8
Description:
説明：
OSPF Reference Bandwidth
OSPF参照帯域幅
Reference:
参照：
RFC 9843, Section 4.1.4.1
RFC 9843、セクション4.1.4.1
Type:
タイプ：
9
9
Description:
説明：
OSPF Bandwidth Threshold
OSPF帯域幅のしきい値
Reference:
参照：
RFC 9843, Section 4.1.4.2
RFC 9843、セクション4.1.4.2
The "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry is part of the "IS-IS TLV Codepoints" registry group.
「IS-IS Sub-TLVの近隣情報広告」レジストリは、「IS-IS TLV CodePoints」レジストリグループの一部です。
Type:
タイプ：
17
17
Description:
説明：
Generic Metric
一般的なメトリック
TLVs set to "Y":
「Y」に設定されたTLV：
22, 23, 25, 141, 222, and 223
22、23、25、141、222、および223
Reference:
参照：
RFC 9843, Section 2.1
RFC 9843、セクション2.1
The "IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes" registry is part of the "IS-IS TLV Codepoints" registry group.
「アプリケーション固有のリンク属性の「IS-IS Sub-Sub-TLV CodePoints」レジストリは、「IS-IS TLV CodePoints」レジストリグループの一部です。
Type:
タイプ：
17
17
Description:
説明：
Generic Metric
一般的なメトリック
Reference:
参照：
RFC 9843, Section 2.1
RFC 9843、セクション2.1
The "OSPFv2 Extended Link TLV Sub-TLVs" registry is part of the "Open Shortest Path First v2 (OSPFv2) Parameters" registry group.
「OSPFV2拡張リンクTLV Sub-TLVS」レジストリは、「Open Shortest Path First V2（OSPFV2）パラメーター」レジストリグループの一部です。
Value:
値：
25
25
Description:
説明：
Generic Metric
一般的なメトリック
L2BM:
L2BM：
Y
y
Reference:
参照：
RFC 9843, Section 2.2
RFC 9843、セクション2.2
The "Types for sub-TLVs of TE Link TLV (Value 2)" registry is part of the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry group.
「TE Link TLV（Value 2）のサブTLVのタイプ」レジストリは、「Open Shortest Path First（OSPF）Traffic Engineering TLVS」レジストリグループの一部です。
Value:
値：
36
36
Description:
説明：
Generic Metric
一般的なメトリック
Reference:
参照：
RFC 9843, Section 2.2
RFC 9843、セクション2.2
The "OSPFv3 Extended-LSA Sub-TLVs" registry is part of the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group.
「OSPFV3拡張LSAサブTLVS」レジストリは、「オープン最短パスファーストV3（OSPFV3）パラメーター」レジストリグループの一部です。
Value:
値：
34
34
Description:
説明：
Generic Metric
一般的なメトリック
L2BM:
L2BM：
Y
y
Reference:
参照：
RFC 9843, Section 2.2
RFC 9843、セクション2.2
[IEEE754-2019]
IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
Std 754-2019, DOI 10.1109/ieeestd.2019.8766229, 22 July
2019, <https://doi.org/10.1109/ieeestd.2019.8766229>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[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>.
[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>.
[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>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[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>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
M., and E. Aries, "Advertising Layer 2 Bundle Member Link
Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
December 2019, <https://www.rfc-editor.org/info/rfc8668>.
[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>.
[RFC9356] Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2
Bundle Member Link Attributes in OSPF", RFC 9356,
DOI 10.17487/RFC9356, January 2023,
<https://www.rfc-editor.org/info/rfc9356>.
[RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS Application-Specific Link Attributes",
RFC 9479, DOI 10.17487/RFC9479, October 2023,
<https://www.rfc-editor.org/info/rfc9479>.
[RFC9492] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
J., and J. Drake, "OSPF Application-Specific Link
Attributes", RFC 9492, DOI 10.17487/RFC9492, October 2023,
<https://www.rfc-editor.org/info/rfc9492>.
[ISIS-AUGMENTATION]
Lindem, A., Qu, Y., and S. Litkowski, "IS-IS YANG Model
Augmentations for Additional Features - Release 1", Work
in Progress, Internet-Draft, draft-ietf-lsr-isis-yang-
augmentation-v1-10, 6 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
isis-yang-augmentation-v1-10>.
[OSPF-AUGMENTATION]
Lindem, A. and Y. Qu, "OSPF YANG Model Augmentations for
Additional Features - Release 1", Work in Progress,
Internet-Draft, draft-ietf-lsr-ospf-yang-augmentation-
v1-17, 6 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
ospf-yang-augmentation-v1-17>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[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>.
[RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M.
Shand, "Simplified Extension of Link State PDU (LSP) Space
for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009,
<https://www.rfc-editor.org/info/rfc5311>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <https://www.rfc-editor.org/info/rfc5715>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS-
IS Extensions in Support of Inter-Autonomous System (AS)
MPLS and GMPLS Traffic Engineering", RFC 9346,
DOI 10.17487/RFC9346, February 2023,
<https://www.rfc-editor.org/info/rfc9346>.
[SR-LOOP-AVOID]
Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B.,
Francois, P., and P. Psenak, "Loop avoidance using Segment
Routing", Work in Progress, Internet-Draft, draft-
bashandy-rtgwg-segment-routing-uloop-17, 29 June 2024,
<https://datatracker.ietf.org/doc/html/draft-bashandy-
rtgwg-segment-routing-uloop-17>.
This section lists the entire set of rules to prune links from Flex-Algorithm topology during Flexible Algorithm calculation. It includes the original rules defined in Section 13 of [RFC9350] as well as the new additions (rules 6 and 7) described in this document.
このセクションでは、柔軟なアルゴリズムの計算中に、Flex-Algorithmトポロジからリンクを剪定するためのルールのセット全体をリストします。[RFC9350]のセクション13で定義されている元のルールと、このドキュメントで説明されている新しい追加（ルール6および7）が含まれます。
For all links in the topology:
トポロジのすべてのリンクについて：
1. Check if any exclude Administrative Group rule is part of the Flex-Algorithm Definition. If such exclude rule exists, check if any color that is part of the exclude rule is also set on the link. If such a color is set, the link MUST be pruned from the computation.
1. 除外された管理グループルールがフレックスアルゴリズムの定義の一部であるかどうかを確認してください。そのような除外ルールが存在する場合は、除外ルールの一部である色がリンクに設定されているかどうかを確認します。そのような色が設定されている場合、リンクは計算から剪定する必要があります。
2. Check if any exclude SRLG rule is part of the Flex-Algorithm Definition. If such exclude rule exists, check if the link is part of any SRLG that is also part of the SRLG exclude rule. If the link is part of such SRLG, the link MUST be pruned from the computation.
2. SRLGルールを除外することがFlex-Algorithm定義の一部であるかどうかを確認してください。そのような除外ルールが存在する場合、リンクがSRLG除外ルールの一部でもあるSRLGの一部であるかどうかを確認します。リンクがそのようなSRLGの一部である場合、リンクは計算から剪定する必要があります。
3. Check if any include-any Administrative Group rule is part of the Flex-Algorithm Definition. If such include-any rule exists, check if any color that is part of the include-any rule is also set on the link. If no such color is set, the link MUST be pruned from the computation.
3. 含まれる場合は、Any Administrative GroupルールがFlex-Algorithmの定義の一部であるかどうかを確認します。そのような内容が存在する場合は、含まれるルールの一部であるかどうかを確認します。そのような色が設定されていない場合、リンクは計算から剪定する必要があります。
4. Check if any include-all Administrative Group rule is part of the Flex-Algorithm Definition. If such include-all rule exists, check if all colors that are part of the include-all rule are also set on the link. If all such colors are not set on the link, the link MUST be pruned from the computation.
4. すべての管理グループルールがフレックスアルゴリズム定義の一部であるかどうかを確認してください。そのような内容が存在する場合は、インクルードルールの一部であるすべての色がリンクに設定されているかどうかを確認します。そのようなすべての色がリンクに設定されていない場合、リンクは計算から剪定する必要があります。
5. If the Flex-Algorithm Definition uses something other than the IGP metric (Section 5 of [RFC9350]), and such metric is not advertised for the particular link in a topology for which the computation is done, such link MUST be pruned from the computation. A metric of value 0 MUST NOT be assumed in such a case.
5. フレックスアルゴリズムの定義がIGPメトリック以外のもの（[RFC9350]のセクション5）以外のものを使用し、そのようなメトリックが計算が行われるトポロジの特定のリンクについて宣伝されていない場合、そのようなリンクは計算から剪定する必要があります。そのような場合、値0のメトリックを想定してはなりません。
6. Check if any exclude FAEMB rule is part of the Flex-Algorithm Definition. If such exclude rule exists and the link has Maximum Link Bandwidth advertised, check if the link bandwidth satisfies the FAEMB rule. If the link does not satisfy the FAEMB rule, the link MUST be pruned from the Flex-Algorithm computation.
6. FAEMBルールを除外することがFlex-Algorithm定義の一部であるかどうかを確認してください。そのような除外ルールが存在し、リンクに最大リンク帯域幅が宣伝されている場合、リンク帯域幅がFAEMBルールを満たしているかどうかを確認します。リンクがFAEMBルールを満たしていない場合、リンクはFlex-Algorithmの計算から剪定する必要があります。
7. Check if any exclude FAEMD rule is part of the Flex-Algorithm Definition. If such exclude rule exists and the link has Min Unidirectional Link Delay advertised, check if the link delay satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule, the link MUST be pruned from the Flex-Algorithm computation.
7. FAEMDルールを除外することがFlex-Algorithm定義の一部であるかどうかを確認してください。そのような除外ルールが存在し、リンクに最小単方向リンク遅延が宣伝されている場合、リンク遅延がFAEMDルールを満たしているかどうかを確認します。リンクがFAEMDルールを満たしていない場合、リンクはFlex-Algorithmの計算から剪定する必要があります。
Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, Ram Santhanakrishnan, Ketan Talaulikar, and Acee Lindem for discussions and input.
Chris Bowers、Krzysztof Szarcowitz、Julian Lucek、Ram Santhanakrishnan、Ketan Talaulikar、Acee Lindemに議論と意見をありがとう。
Salih K.A.
Juniper Networks
Email: salih@juniper.net
Shraddha Hegde
Juniper Networks Inc.
Exora Business Park
Bangalore 560103
Karnataka
India
Email: shraddha@juniper.net
William Britto
Juniper Networks Inc.
Email: bwilliam@juniper.net
Rajesh Shetty
Juniper Networks Inc.
Email: mrajesh@juniper.net
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Peter Psenak
Cisco Systems
Email: ppsenak@cisco.com
Tony Li
Juniper Networks Inc.
Email: tony.li@tony.li