Internet Engineering Task Force (IETF) A. Bashandy
Request for Comments: 9855 HPE
Category: Standards Track S. Litkowski
ISSN: 2070-1721 C. Filsfils
Cisco Systems
P. Francois
INSA Lyon
B. Decraene
Orange
D. Voyer
Bell Canada
October 2025
This document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the Point of Local Repair (PLR), reducing the operational need to control the tie-breaks among various FRR options.
このドキュメントでは、セグメント ルーティング (SR) フレームワーク内でノードおよび隣接セグメントの保護を提供することを目的とした、トポロジ独立ループフリー代替 (TI-LFA) 高速リルート (FRR) について説明します。この FRR の動作は、LFA、リモート LFA (RLFA)、および有向ループフリー代替 (DLFA) である実証済みの IP FRR の概念に基づいて構築されています。これらの概念を拡張して、リンクステート IGP を使用して 2 つの接続されたネットワークで保証されたカバレッジを提供します。TI-LFA の重要な側面は、ローカル修復ポイント (PLR) からの予想されるコンバージェンス後のパスに対する保護を確立する FRR パス選択アプローチであり、さまざまな FRR オプション間のタイブレークを制御する運用上の必要性が軽減されます。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9855.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9855 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
2.1. Abbreviations and Notations
2.2. Conventions Used in This Document
3. Base Principle
4. Intersecting P-space and Q-space with Post-Convergence Paths
4.1. Extended P-space Property Computation for a Resource X over
Post-Convergence Paths
4.2. Q-space Property Computation for a Resource X over
Post-Convergence Paths
4.3. Scaling Considerations When Computing Q-space
5. TI-LFA Repair Path
5.1. FRR Path Using a Direct Neighbor
5.2. FRR Path Using a PQ Node
5.3. FRR Path Using a P Node and Q Node That Are Adjacent
5.4. Connecting Distant P and Q Nodes Along Post-Convergence
Paths
6. Building TI-LFA Repair Lists for SR Segments
6.1. The Active Segment Is a Node Segment
6.2. The Active Segment Is an Adjacency Segment
6.2.1. Protecting [Adjacency, Adjacency] Segment Lists
6.2.2. Protecting [Adjacency, Node] Segment Lists
7. Data Plane-Specific Considerations
7.1. MPLS Data Plane Considerations
7.2. SRv6 Data Plane Considerations
8. TI-LFA and SR Algorithms
9. Usage of Adjacency Segments in the Repair List
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Advantages of Using the Expected Post-Convergence Path
During FRR
Appendix B. Analysis Based on Real Network Topologies
Acknowledgments
Contributors
Authors' Addresses
This document outlines a local repair mechanism that leverages Segment Routing (SR) to restore end-to-end connectivity in the event of a failure involving a directly connected network component. This mechanism is designed for standard link-state Interior Gateway Protocol (IGP) shortest path scenarios. Non-SR mechanisms for local repair are beyond the scope of this document. Non-local failures are addressed in a separate document [SR-LOOP].
このドキュメントでは、直接接続されたネットワーク コンポーネントに関連する障害が発生した場合に、セグメント ルーティング (SR) を活用してエンドツーエンドの接続を復元するローカル修復メカニズムの概要を説明します。このメカニズムは、標準のリンクステート内部ゲートウェイ プロトコル (IGP) の最短パス シナリオ向けに設計されています。ローカル修復のための非 SR メカニズムについては、このドキュメントの範囲外です。非ローカル障害については、別の文書 [SR-LOOP] で説明します。
The term Topology Independent (TI) describes the capability providing a loop-free backup path that is effective across all network topologies. This provides a major improvement compared to LFA [RFC5286] and RLFA [RFC7490], which cannot provide a complete protection coverage in some topologies as described in [RFC6571].
トポロジ非依存 (TI) という用語は、すべてのネットワーク トポロジにわたって効果的なループフリーのバックアップ パスを提供する機能を表します。これは、[RFC6571] で説明されているように、一部のトポロジーで完全な保護範囲を提供できない LFA [RFC5286] および RLFA [RFC7490] と比較して、大幅な改善を提供します。
When the network reconverges after failure, micro-loops [RFC5715] can form due to transient inconsistencies in the forwarding tables of different routers. If it is determined that micro-loops are a significant issue in the deployment, then a suitable loop-free convergence method should be implemented, such as one of those described in [RFC5715], [RFC6976], [RFC8333], or [SR-LOOP].
障害後にネットワークが再収束すると、さまざまなルータの転送テーブルの一時的な不一致により、マイクロ ループ [RFC5715] が形成される可能性があります。マイクロループが展開において重大な問題であると判断された場合は、[RFC5715]、[RFC6976]、[RFC8333]、または [SR-LOOP] で説明されているもののいずれかのような、適切なループフリーの収束方法を実装する必要があります。
TI-LFA operates locally at the Point of Local Repair (PLR) upon detecting a failure in one of its direct links. Consequently, this local operation does not influence:
TI-LFA は、直接リンクの 1 つで障害が検出されると、ローカル修復ポイント (PLR) でローカルに動作します。したがって、このローカル操作は以下には影響しません。
* Micro-loops that may or may not form during the distributed IGP convergence as delineated in [RFC5715]:
* [RFC5715] で説明されているように、分散 IGP コンバージェンス中に形成される場合と形成されない場合があるマイクロ ループ:
- These micro-loops occur on routes directed towards the destination that do not traverse paths configured for TI-LFA. According to [RFC5714], the formation of such micro-loops can prevent traffic from reaching the PLR, thereby bypassing the TI-LFA paths established for rerouting.
- これらのマイクロ ループは、TI-LFA 用に設定されたパスを通過しない、宛先に向かうルートで発生します。[RFC5714] によれば、このようなマイクロループの形成により、トラフィックが PLR に到達することが妨げられ、その結果、再ルーティングのために確立された TI-LFA パスがバイパスされる可能性があります。
* Micro-loops that may or may not develop when the previously failed link is restored to functionality.
* 以前に障害が発生したリンクが機能を回復したときに発生する場合と発生しない場合があるマイクロ ループ。
TI-LFA paths are activated from the instant the PLR detects a failure in a local link and remain in effect until the IGP convergence at the PLR is fully achieved. Consequently, they are not susceptible to micro-loops that may arise due to variations in the IGP convergence times across different nodes through which these paths traverse. This ensures a stable and predictable routing environment, minimizing disruptions typically associated with asynchronous network behavior. However, an early (relative to the other nodes) IGP convergence at the PLR and the consecutive "early" release of TI-LFA paths may cause micro-loops, especially if these paths have been computed using the methods described in Sections 5.2, 5.3, or 5.4 of this document. One of the possible ways to prevent such micro-loops is local convergence delay [RFC8333].
TI-LFA パスは、PLR がローカル リンクの障害を検出した瞬間からアクティブになり、PLR での IGP コンバージェンスが完全に達成されるまで有効です。したがって、これらのパスが通過するさまざまなノード間での IGP コンバージェンス時間の変動によって発生する可能性のあるマイクロ ループの影響を受けません。これにより、安定した予測可能なルーティング環境が保証され、非同期ネットワーク動作に通常伴う中断が最小限に抑えられます。ただし、特にこれらのパスがこのドキュメントのセクション 5.2、5.3、または 5.4 で説明されている方法を使用して計算されている場合、PLR での (他のノードと比較して) 早期の IGP コンバージェンスと TI-LFA パスの連続した「早期」リリースにより、マイクロ ループが発生する可能性があります。このようなマイクロループを防ぐ可能な方法の 1 つは、ローカル収束遅延 [RFC8333] です。
TI-LFA procedures are complementary to the application of any micro-loop avoidance procedures in the case of link or node failure:
TI-LFA 手順は、リンクまたはノード障害が発生した場合のマイクロループ回避手順の適用を補完します。
* Link or node failure requires some urgent action to restore the traffic that passed through the failed resource. TI-LFA paths are pre-computed and pre-installed; therefore, they are suitable for urgent recovery.
* リンクまたはノードに障害が発生した場合は、障害が発生したリソースを通過したトラフィックを復元するための緊急のアクションが必要です。TI-LFA パスは事前に計算され、事前にインストールされています。したがって、緊急の回復に適しています。
* The paths used in the micro-loop avoidance procedures typically cannot be pre-computed.
* マイクロループ回避手順で使用されるパスは通常、事前に計算できません。
For each destination (as specified by the IGP) in the network, TI-LFA pre-installs a backup forwarding entry for each protected destination ready to be activated upon detection of the failure of a link used to reach the destination. TI-LFA provides protection in the event of any one of the following: single link failure, single node failure, or single Shared Risk Link Group (SRLG) failure. In link failure mode, the destination is protected assuming the failure of the link. In node protection mode, the destination is protected assuming that the neighbor connected to the primary link (see Section 2) has failed. In SRLG protecting mode, the destination is protected assuming that a configured set of links sharing fate with the primary link has failed (e.g., a linecard or a set of links sharing a common transmission pipe).
TI-LFA は、ネットワーク内の (IGP によって指定された) 宛先ごとに、保護された宛先ごとにバックアップ転送エントリをプリインストールし、宛先に到達するために使用されるリンクの障害が検出されたときにアクティブ化できるようにします。TI-LFA は、単一リンク障害、単一ノード障害、または単一の Shared Risk Link Group (SRLG) 障害のいずれかが発生した場合に保護を提供します。リンク障害モードでは、リンクの障害を想定して宛先が保護されます。ノード保護モードでは、プライマリ リンク (セクション 2 を参照) に接続されているネイバーに障害が発生したと想定して、宛先が保護されます。SRLG 保護モードでは、プライマリ リンクと運命を共有する設定されたリンクのセット（たとえば、共通の伝送パイプを共有するラインカードまたはリンクのセット）に障害が発生したと想定して、宛先が保護されます。
Protection techniques outlined in this document are limited to protecting links, nodes, and SRLGs that are within a link-state IGP area. Protecting domain exit routers and/or links attached to another routing domain is beyond the scope of this document.
このドキュメントで概説されている保護技術は、リンクステート IGP エリア内のリンク、ノード、および SRLG の保護に限定されています。ドメイン出口ルーターや別のルーティング ドメインに接続されているリンクの保護については、このドキュメントの範囲外です。
By utilizing SR, TI-LFA eliminates the need to establish Targeted Label Distribution Protocol sessions with remote nodes for leveraging the benefits of Remote Loop-Free Alternates (RLFAs) [RFC7490] [RFC7916] or Directed Loop-Free Alternates (DLFAs) [IPFRR-TUNNELS]. All the Segment Identifiers (SIDs) required are present within the Link State Database (LSDB) of the IGP. Consequently, there is no longer a necessity to prefer LFAs over RLFAs or DLFAs, nor is there a need to minimize the number of RLFA or DLFA repair nodes.
SR を利用することにより、TI-LFA は、リモート ループフリー代替 (RLFA) [RFC7490] [RFC7916] または直接ループフリー代替 (DLFA) [IPFRR-TUNNELS] の利点を活用するために、リモート ノードとのターゲット ラベル配布プロトコル セッションを確立する必要性を排除します。必要なすべてのセグメント識別子 (SID) は、IGP のリンク状態データベース (LSDB) 内に存在します。したがって、RLFA または DLFA よりも LFA を優先する必要はなくなり、RLFA または DLFA 修復ノードの数を最小限に抑える必要もなくなりました。
Utilizing SR also eliminates the need to establish an additional state within the network for enforcing explicit Fast Reroute (FRR) paths. This spares the nodes from maintaining a supplementary state and frees the operator from the necessity to implement additional protocols or protocol sessions solely to augment protection coverage.
SR を利用すると、明示的な高速リルート (FRR) パスを強制するためにネットワーク内に追加の状態を確立する必要もなくなります。これにより、ノードが補足状態を維持する必要がなくなり、オペレータは保護範囲を拡大するためだけに追加のプロトコルやプロトコル セッションを実装する必要がなくなります。
TI-LFA also brings the benefit of the ability to provide a backup path that follows the expected post-convergence path considering a particular failure, which reduces the need of locally configured policies that influence the backup path selection [RFC7916]. The easiest way to express the expected post-convergence path in a loop-free manner is to encode it as a list of Adjacency segments. However, this may create a long segment list that some hardware may not be able to program. One of the challenges of TI-LFA is to encode the expected post-convergence path by combining Adjacency segments and node segments. Each implementation may independently develop its own algorithm for optimizing the ordered segment list. This document provides an outline of the fundamental concepts applicable to constructing the SR backup path, along with the related data plane procedures. Appendix A contains a more detailed description of some of the aspects of TI-LFA related to post-convergence path.
TI-LFA には、特定の障害を考慮して予想されるコンバージェンス後のパスに従うバックアップ パスを提供できるという利点もあります。これにより、バックアップ パスの選択に影響を与えるローカルで構成されたポリシーの必要性が軽減されます [RFC7916]。ループのない方法で予想されるコンバージェンス後のパスを表現する最も簡単な方法は、それを隣接セグメントのリストとしてエンコードすることです。ただし、これにより長いセグメント リストが作成され、一部のハードウェアではプログラムできない可能性があります。TI-LFA の課題の 1 つは、隣接セグメントとノード セグメントを組み合わせて、予想されるコンバージェンス後のパスをエンコードすることです。各実装は、順序付けされたセグメント リストを最適化するための独自のアルゴリズムを独立して開発できます。このドキュメントでは、SR バックアップ パスの構築に適用できる基本概念の概要と、関連するデータ プレーン手順を説明します。付録 A には、コンバージェンス後のパスに関連する TI-LFA のいくつかの側面のより詳細な説明が含まれています。
This document is structured as follows:
この文書は次のように構成されています。
* Section 2 defines the main notations used in the document. They are in line with [RFC5714].
* セクション 2 では、文書内で使用される主な表記法を定義します。これらは [RFC5714] に準拠しています。
* Section 3 defines the main principles of TI-LFA backup path computation.
* セクション 3 では、TI-LFA バックアップ パス計算の主な原則を定義します。
* Section 4 suggests to compute the P-space and Q-space properties defined in Section 2 for the specific case of nodes lying over the post-convergence paths towards the protected destinations.
* セクション 4 では、保護された宛先に向かう収束後のパス上にノードが存在する特定のケースに対して、セクション 2 で定義された P 空間プロパティと Q 空間プロパティを計算することを提案します。
* Section 5 describes how to compute protection lists that encode a loop-free post-convergence path towards the destination using the properties defined in Section 4.
* セクション 5 では、セクション 4 で定義されたプロパティを使用して、宛先へ向かうループのないコンバージェンス後のパスをエンコードする保護リストを計算する方法について説明します。
* Section 6 defines the segment operations to be applied by the PLR to ensure consistency with the forwarding state of the repair node.
* セクション 6 では、修復ノードの転送状態との一貫性を確保するために PLR によって適用されるセグメント操作を定義します。
* Section 7 discusses aspects that are specific to the data plane.
* セクション 7 では、データ プレーンに特有の側面について説明します。
* Section 8 discusses the relationship between TI-LFA and the SR algorithm.
* セクション 8 では、TI-LFA と SR アルゴリズムの関係について説明します。
* Section 9 provides an overview of the certain considerations that are needed when Adjacency segments are used in a Repair List (RL).
* セクション 9 では、修復リスト (RL) で隣接セグメントを使用する場合に必要となる特定の考慮事項の概要を説明します。
* Section 10 discusses security considerations.
* セクション 10 では、セキュリティに関する考慮事項について説明します。
* Appendix A highlights advantages of using the expected post-convergence path during FRR.
* 付録 A では、FRR 中に予想されるコンバージェンス後のパスを使用する利点について説明します。
* Appendix B summarizes the measurements from implementing the algorithms detailed in this document within actual service provider and large enterprise network environments. Real-life measurements are presented regarding the number of SIDs utilized by repair paths.
* 付録 B には、実際のサービス プロバイダーおよび大規模企業ネットワーク環境内でこのドキュメントで詳細に説明されているアルゴリズムを実装した測定結果がまとめられています。修復パスで使用される SID の数に関する実際の測定値が表示されます。
DLFA:
DLFA:
Directed Loop-Free Alternate
有向ループフリー代替
FRR:
FRR:
Fast Reroute
高速リルート
IGP:
IGP:
Interior Gateway Protocol
内部ゲートウェイ プロトコル
LFA:
LFA:
Loop-Free Alternate
ループフリーの代替
LSDB:
LSDB:
Link State Database
リンクステートデータベース
PLR:
PLR:
Point of Local Repair
現地修理のポイント
RL:
RL:
Repair List
修理リスト
RLFA:
RLFA:
Remote Loop-Free Alternate
リモートループフリー代替
SID:
SID:
Segment Identifier
セグメント識別子
SPF:
SPF:
Shortest Path First
最短パスを優先
SPT:
SPT:
Shortest Path Tree
最短パスツリー
SR:
SR:
Segment Routing
セグメントルーティング
SRLG:
SRLG:
Shared Risk Link Group
共有リスクリンクグループ
TI-LFA:
TI-LFA:
Topology Independent Loop-Free Alternate
トポロジーに依存しないループフリーの代替
The main notations used in this document are defined as follows:
このドキュメントで使用される主な表記は次のように定義されます。
* The terms "old" and "new" topologies refer to the LSDB state before and after the considered failure, respectively.
* 「古い」トポロジと「新しい」トポロジという用語は、それぞれ、障害が発生する前と後の LSDB の状態を指します。
* SPT_old(R) is the SPT rooted at node R in the initial state of the network.
* SPT_old(R) は、ネットワークの初期状態でノード R をルートとする SPT です。
* SPT_new(R, X) is the SPT rooted at node R in the state of the network after the resource X has failed.
* SPT_new(R, X) は、リソース X に障害が発生した後のネットワーク状態におけるノード R をルートとする SPT です。
* The PLR is the router that applies fast traffic restoration after detecting failure in a directly attached link, set of links, and/ or node.
* PLR は、直接接続されたリンク、リンクのセット、および/またはノードで障害を検出した後に、高速トラフィック復元を適用するルーターです。
* Similar to [RFC7490], the concept of P-space and Q-space is used for TI-LFA.
* [RFC7490] と同様に、P 空間と Q 空間の概念が TI-LFA に使用されます。
* The P-space P(R, X) of a router R with regard to a resource X (e.g., a link S-F, a node F, or an SRLG) is the set of routers reachable from R using the pre-convergence shortest paths without any of those paths (including equal-cost path splits) transiting through X. A P node is a node that belongs to the P-space.
* リソース X (リンク S-F、ノード F、SRLG など) に関するルータ R の P 空間 P(R, X) は、X を経由するパス (等コスト パスの分割を含む) を一切含まずに、コンバージェンス前の最短パスを使用して R から到達可能なルータのセットです。 P ノードは、P 空間に属するノードです。
* Consider the set of neighbors of a router R and a resource X. Exclude from that set the neighbors that are reachable from R using X. The extended P-space P'(R, X) of a node R with regard to a resource X is the union of the P-spaces of the neighbors in that reduced set of neighbors with regard to the resource X.
* ルーター R とリソース X の近隣ノードのセットを考えます。そのセットから、X を使用して R から到達可能な近隣ノードを除外します。リソース X に関するノード R の拡張 P 空間 P'(R, X) は、リソース X に関するその縮小された近隣ノードのセット内の近隣ノードの P 空間の和集合です。
* The Q-space Q(R, X) of a router R with regard to a resource X is the set of routers from which R can be reached without any path (including equal-cost path splits) transiting through X. A Q node is a node that belongs to the Q-space.
* リソース X に関するルータ R の Q 空間 Q(R, X) は、X を経由するパス (等コスト パスの分割を含む) なしで R に到達できるルータの集合です。Q ノードは、Q 空間に属するノードです。
* EP(P, Q) is an explicit SR path from a node P to a node Q.
* EP(P, Q) は、ノード P からノード Q への明示的な SR パスです。
* The primary interface and primary outgoing interface are one of the outgoing interfaces towards a destination according to the IGP link-state protocol.
* プライマリ インターフェイスとプライマリ発信インターフェイスは、IGP リンクステート プロトコルに従った宛先への発信インターフェイスの 1 つです。
* The primary link is a link connected to the primary interface.
* プライマリリンクは、プライマリインターフェースに接続されるリンクです。
* The Adj-SID(S-F) is the Adjacency segment from node S to node F.
* Adj-SID(S-F) は、ノード S からノード F への隣接セグメントです。
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] で説明されているように解釈されます。
The basic algorithm to compute the repair path is to pre-compute SPT_new(R, X) and, for each destination, encode the repair path as a loop-free segment list. One way to provide a loop-free segment list is to use Adjacency SIDs only. However, this approach may create very long SID lists that hardware may not be able to handle due to Maximum SID Depth (MSD) limitations.
修復パスを計算する基本的なアルゴリズムは、SPT_new(R, X) を事前に計算し、宛先ごとに修復パスをループのないセグメント リストとしてエンコードすることです。ループのないセグメント リストを提供する 1 つの方法は、隣接 SID のみを使用することです。ただし、このアプローチでは、最大 SID 深さ (MSD) の制限により、ハードウェアが処理できない非常に長い SID リストが作成される可能性があります。
An implementation is free to use any local optimization to provide smaller segment lists by combining Node-SIDs and Adjacency SIDs. In addition, the usage of Node-SIDs allow for maximizing ECMPs over the backup path. These optimizations are out of scope of this document; however, the subsequent sections provide some guidance on how to leverage P-spaces and Q-spaces to optimize the size of the segment list.
実装では、ローカル最適化を自由に使用して、ノード SID と隣接 SID を組み合わせてより小さなセグメント リストを提供できます。さらに、ノード SID を使用すると、バックアップ パス上の ECMP を最大化できます。これらの最適化は、このドキュメントの範囲外です。ただし、後続のセクションでは、P スペースと Q スペースを活用してセグメント リストのサイズを最適化する方法についていくつかのガイダンスを提供します。
One of the challenges of defining an SR path following the expected post-convergence path is to reduce the size of the segment list. In order to reduce this segment list, an implementation MAY determine the P-space / extended P-space and Q-space properties (defined in [RFC7490]) of the nodes along the expected post-convergence path from the PLR to the protected destination and compute an SR explicit path from P to Q when they are not adjacent. Such properties will be used in Section 5 to compute the TI-LFA RL.
予想されるコンバージェンス後のパスに従って SR パスを定義する際の課題の 1 つは、セグメント リストのサイズを削減することです。このセグメントリストを削減するために、実装は、PLR から保護された宛先までの予想されるコンバージェンス後のパスに沿ったノードの P 空間/拡張 P 空間および Q 空間プロパティ ([RFC7490] で定義) を決定し、それらが隣接していない場合に P から Q への SR 明示的パスを計算してもよい(MAY)。このようなプロパティは、セクション 5 で TI-LFA RL を計算するために使用されます。
The objective is to determine which nodes on the post-convergence path from the PLR R to the destination D are in the extended P-space of R with regard to resource X (where X can be a link or a set of links adjacent to the PLR or a neighbor node of the PLR).
目的は、PLR R から宛先 D までのコンバージェンス後のパス上のどのノードが、リソース X に関して R の拡張 P 空間内にあるかを判断することです (X は、PLR または PLR の隣接ノードに隣接するリンクまたはリンクのセットである可能性があります)。
This can be found by:
これは次の方法で見つけることができます。
* excluding neighbors that are not on the post-convergence path when computing P'(R, X), then
* P'(R, X) を計算するときに収束後のパス上にない近傍を除外すると、
* intersecting the set of nodes belonging to the post-convergence path from R to D, assuming the failure of X, with P'(R, X).
* X の障害を想定して、R から D への収束後のパスに属するノードのセットを P'(R, X) と交差させます。
The goal is to determine which nodes on the post-convergence path from the PLR R to the destination D are in the Q-space of destination D with regard to resource X (where X can be a link or a set of links adjacent to the PLR, or a neighbor node of the PLR).
目的は、PLR R から宛先 D へのコンバージェンス後のパス上のどのノードが、リソース X に関して宛先 D の Q 空間内にあるかを判断することです (X は、PLR に隣接するリンクまたはリンクのセット、または PLR の隣接ノードである可能性があります)。
This can be found by intersecting the set of nodes belonging to the post-convergence path from R to D, assuming the failure of X, with Q(D, X).
これは、X の障害を想定して、R から D への収束後のパスに属するノードのセットを Q(D, X) と交差させることによって見つけることができます。
[RFC7490] raises scaling concerns about computing a Q-space per destination. Similar concerns may affect TI-LFA computation if an implementation tries to compute a reverse Shortest Path Tree (SPT) [RFC7490] for every destination in the network to determine the Q-space. It will be up to each implementation to determine the good tradeoff between scaling and accuracy of the optimization.
[RFC7490] は、宛先ごとの Q スペースの計算に関するスケーリング上の懸念を引き起こします。実装が Q 空間を決定するためにネットワーク内のすべての宛先に対して逆最短パス ツリー (SPT) [RFC7490] を計算しようとする場合、同様の懸念が TI-LFA 計算に影響を与える可能性があります。スケーリングと最適化の精度の間の適切なトレードオフを決定するのは、各実装次第です。
The TI-LFA repair path consists of an outgoing interface and a list of segments (a Repair List (RL)) to insert on the SR header in accordance with the data plane used. The RL encodes the explicit (and possibly post-convergence) path to the destination, which avoids the protected resource X. At the same time, the RL is guaranteed to be loop-free, irrespective of the state of FIBs along the nodes belonging to the explicit path, as long as the states of the FIBs are programmed according to a link-state IGP. Thus, there is no need for any coordination or message exchange between the PLR and any other router in the network.
TI-LFA 修復パスは、送信インターフェイスと、使用されるデータ プレーンに従って SR ヘッダーに挿入されるセグメントのリスト (修復リスト (RL)) で構成されます。RL は、宛先への明示的 (および場合によってはコンバージェンス後の) パスをエンコードし、保護されたリソース X を回避します。同時に、FIB の状態がリンクステート IGP に従ってプログラムされている限り、明示的パスに属するノードに沿った FIB の状態に関係なく、RL はループフリーであることが保証されます。したがって、PLR とネットワーク内の他のルーターの間で調整やメッセージ交換を行う必要はありません。
The TI-LFA repair path is found by intersecting P(S, X) and Q(D, X) with the post-convergence path to D and computing the explicit SR-based path EP(P, Q) from a node P in P(S, X) to a node Q in Q(D, X) when these nodes are not adjacent along the post-convergence path. The TI-LFA RL is expressed generally as (Node-SID(P), EP(P, Q)).
TI-LFA 修復パスは、P(S, X) および Q(D, X) を D へのコンバージェンス後のパスと交差させ、これらのノードがコンバージェンス後のパスに沿って隣接していない場合に、P(S, X) のノード P から Q(D, X) のノード Q までの明示的な SR ベースのパス EP(P, Q) を計算することによって検出されます。ＴＩ−ＬＦＡ ＲＬは、一般に、（Ｎｏｄｅ−ＳＩＤ（Ｐ）、ＥＰ（Ｐ、Ｑ））として表される。
S --------- N1 --------- D
*\ | \ |
* \ | \ |
* \ | \ |
* N2----- R1***R2 *** R3
* *
N3 **********
***** : link with high metric (1k)
----- : link with metric 1
Figure 1: Sample Topology with TI-LFA
図 1: TI-LFA を使用したサンプル トポロジ
As an example, in Figure 1, the focus is on the TI-LFA backup from S to D, considering the failure of node N1.
例として、図 1 では、ノード N1 の障害を考慮して、S から D への TI-LFA バックアップに焦点を当てています。
* First, P(S, N1) is computed and results in [N3, N2, R1].
* まず、P(S, N1) が計算され、結果は [N3, N2, R1] になります。
* Then, Q(D, N1) is computed and results in [R3].
* 次に、Q(D, N1) が計算され、結果は [R3] になります。
* The expected post-convergence path from S to D considering the failure of N1 is <N2 -> R1 -> R2 -> R3 -> D> (we are naming it "PCPath" in this example).
* N1 の障害を考慮した S から D への予想されるコンバージェンス後のパスは、<N2 -> R1 -> R2 -> R3 -> D> です (この例では「PCPath」という名前を付けています)。
* P(S, N1) intersection with PCPath is [N2, R1]. With R1 being the deeper downstream node in PCPath, it can be assumed to be used as a P node (this is an example, and an implementation could use a different strategy to choose the P node).
* P(S, N1) と PCPath の交差部分は [N2, R1] です。R1 は PCPath のより深い下流ノードであるため、P ノードとして使用されると想定できます (これは一例であり、実装では P ノードを選択するために別の戦略を使用する可能性があります)。
* Q(D, N1) intersection with PCPath is [R3], so R3 is picked as a Q node. An SR-explicit path is then computed from R1 (P node) to R3 (Q node) following PCPath (R1 -> R2 -> R3): <Adj-SID(R1-R2), Adj-SID(R2-R3)>.
* Q(D, N1) と PCPath の交差は [R3] であるため、R3 が Q ノードとして選択されます。次に、SR 明示的なパスが、PCPath (R1 -> R2 -> R3) に従って R1 (P ノード) から R3 (Q ノード) まで計算されます: <Adj-SID(R1-R2), Adj-SID(R2-R3)>。
As a result, the TI-LFA RL of S for destination D considering the failure of node N1 is: <Node-SID(R1), Adj-SID(R1-R2), Adj-SID(R2-R3)>.
その結果、ノード N1 の障害を考慮した宛先 D の S の TI-LFA RL は、<Node-SID(R1), Adj-SID(R1-R2), Adj-SID(R2-R3)> となります。
Most often, the TI-LFA RL has a simpler form, as described in the following sections. Appendix B provides statistics for the number of SIDs in the explicit path to protect against various failures.
ほとんどの場合、TI-LFA RL は、次のセクションで説明するように、より単純な形式になります。付録 B では、さまざまな障害から保護するための明示的パス内の SID 数の統計を提供します。
When a direct neighbor is in P(S, X) and Q(D, x), and the link to that direct neighbor is on the post-convergence path, the outgoing interface is set to that neighbor and the repair segment list is empty.
直接ネイバーが P(S, X) および Q(D, x) にあり、その直接ネイバーへのリンクがコンバージェンス後のパス上にある場合、発信インターフェイスはそのネイバーに設定され、修復セグメント リストは空になります。
This is comparable to a post-convergence LFA FRR repair.
これは、コンバージェンス後の LFA FRR 修復に相当します。
When a remote node R is in P(S, X) and Q(D, x) and on the post-convergence path, the RL is made of a single node segment to R, and the outgoing interface is set to the outgoing interface used to reach R.
リモート ノード R が P(S, X) および Q(D, x) にあり、コンバージェンス後のパス上にある場合、RL は R への単一ノード セグメントで構成され、発信インターフェイスは R に到達するために使用される発信インターフェイスに設定されます。
This is comparable to a post-convergence RLFA repair tunnel.
これは、コンバージェンス後の RLFA 修復トンネルに相当します。
When a node P is in P(S, X) and a node Q is in Q(D, x), and both are on the post-convergence path and are adjacent to each other, the RL is made of two segments: a node segment to P (to be processed first), followed by an Adjacency segment from P to Q.
ノード P が P(S, X) にあり、ノード Q が Q(D, x) にあり、両方がコンバージェンス後のパス上にあり、互いに隣接している場合、RL は 2 つのセグメントで構成されます。つまり、P へのノード セグメント (最初に処理される) と、それに続く P から Q への隣接セグメントです。
This is comparable to a post-convergence Directed Loop-Free Alternate (DLFA) repair tunnel.
これは、コンバージェンス後の Directed Loop-Free Alternate（DLFA）修復トンネルに相当します。
In some cases, there is no adjacent P and Q node along the post-convergence path. As mentioned in Section 3, a list of Adjacency SIDs can be used to encode the path between P and Q. However, the PLR can perform additional computations to compute a shorter list of segments that represent a loop-free path from P to Q. How these computations are done is out of scope of this document and is left to implementation.
場合によっては、収束後のパスに沿って隣接する P ノードと Q ノードが存在しません。セクション 3 で述べたように、隣接 SID のリストを使用して P と Q の間のパスをエンコードできます。ただし、PLR は追加の計算を実行して、P から Q へのループのないパスを表すセグメントのより短いリストを計算できます。これらの計算がどのように行われるかは、このドキュメントの範囲外であり、実装に委ねられます。
The following sections describe how to build the RLs using the terminology defined in [RFC8402]. The procedures described in this section are equally applicable to both the Segment Routing over MPLS (SR-MPLS) and the Segment Routing over IPv6 (SRv6) data plane, while the data plane-specific considerations are described in Section 7.
以下のセクションでは、[RFC8402] で定義されている用語を使用して RL を構築する方法について説明します。このセクションで説明する手順は、セグメント ルーティング オーバー MPLS (SR-MPLS) とセグメント ルーティング オーバー IPv6 (SRv6) データ プレーンの両方に同様に適用できますが、データ プレーン固有の考慮事項についてはセクション 7 で説明します。
This section explains the process by which a protecting router S handles the active segment of a packet upon the failure of its primary outgoing interface for the packet S-F. The failure of the primary outgoing interface may occur due to various triggers, such as link failure, neighbor node failure, and others.
このセクションでは、パケット S-F のプライマリ発信インターフェイスの障害時に、保護ルータ S がパケットのアクティブ セグメントを処理するプロセスについて説明します。プライマリ発信インターフェイスの障害は、リンク障害、隣接ノード障害などのさまざまなトリガーによって発生する可能性があります。
The active segment MUST be kept on the SR header unchanged and the RL MUST be added. The active segment becomes the first segment after the RL. The way the RL is added depends on the data plane used (see Section 7).
アクティブなセグメントは SR ヘッダー上で変更されずに維持されなければならず、RL が追加されなければなりません。アクティブなセグメントは、RL の後の最初のセグメントになります。RL を追加する方法は、使用されるデータ プレーンによって異なります (セクション 7 を参照)。
This section defines the FRR behavior applied by S for any packet received with an active Adjacency segment S-F for which protection was enabled. Since protection has been enabled for the segment S-F and signaled in the IGP (for instance, using protocol extensions from [RFC8667] and [RFC8665]), a calculator of any SR policy utilizing this segment is aware that it may be transiently rerouted out of S-F in the event of an S-F failure.
このセクションでは、保護が有効になっているアクティブな隣接セグメント S-F で受信されたパケットに対して S によって適用される FRR 動作を定義します。セグメント S-F に対して保護が有効になっており、IGP でシグナリングされているため (たとえば、[RFC8667] および [RFC8665] のプロトコル拡張を使用)、このセグメントを利用する SR ポリシーの計算機は、S-F 障害が発生した場合に S-F から一時的に再ルーティングされる可能性があることを認識しています。
The simplest approach for link protection of an Adjacency segment S-F is to create an RL that will carry the traffic to F. To do so, one or more "PUSH" operations are performed. If the RL, while avoiding S-F, terminates on F, S only pushes segments of the RL. Otherwise, S pushes a node segment of F, followed by the segments of the RL. For details on the "NEXT" and "PUSH" operations, refer to [RFC8402].
隣接セグメント S-F のリンク保護の最も簡単なアプローチは、トラフィックを F に伝送する RL を作成することです。これを行うには、1 つ以上の「PUSH」操作が実行されます。RL が S-F を回避しながら F で終了する場合、S は RL のセグメントのみをプッシュします。それ以外の場合、S は F のノード セグメントをプッシュし、続いて RL のセグメントをプッシュします。"NEXT" および "PUSH" オペレーションの詳細については、[RFC8402] を参照してください。
This method, which merges back the traffic at the remote end of the Adjacency segment, has the advantage of keeping as much traffic as possible on the pre-failure path. When SR policies are involved and strict compliance with the policy is required, an end-to-end protection (beyond the scope of this document) should be preferred over the local repair mechanism described above.
隣接セグメントのリモート エンドでトラフィックをマージして戻すこの方法には、障害前のパス上にできるだけ多くのトラフィックを維持できるという利点があります。SR ポリシーが関係しており、ポリシーへの厳密な準拠が必要な場合は、上記のローカル修復メカニズムよりもエンドツーエンドの保護 (このドキュメントの範囲を超えています) を優先する必要があります。
Note, however, that when the SR source node is using Traffic Engineering (TE), it will generally not be possible for the PLR to know what post-convergence path will be selected by the source node once it detects the failure, since computation of the TE path is a local matter that depends on constraints that may not be known at the PLR. Therefore, no method applied at the PLR can guarantee protection will follow the post-convergence path.
ただし、SR ソース ノードがトラフィック エンジニアリング (TE) を使用している場合、TE パスの計算は、PLR では不明な制約に依存するローカルな問題であるため、障害を検出した後にソース ノードによってどのようなポスト コンバージェンス パスが選択されるかを PLR が知ることは一般に不可能であることに注意してください。したがって、PLR で適用される方法は、コンバージェンス後のパスに保護が従うことを保証できません。
The case where the active segment is followed by another Adjacency segment is distinguished from the case where it is followed by a node segment. Repair techniques for the respective cases are provided in the following subsections.
アクティブ セグメントの後に別の隣接セグメントが続く場合と、その後にノード セグメントが続く場合は区別されます。それぞれの場合の修復テクニックを次のサブセクションで説明します。
If the next segment in the list is an Adjacency segment, then the packet has to be conveyed to F.
リスト内の次のセグメントが隣接セグメントである場合、パケットは F に送信される必要があります。
To do so, S MUST apply a "NEXT" operation on Adj-SID(S-F) and then one or more "PUSH" operations. If the RL, while avoiding S-F, terminates on F, S only pushes the segments of the RL. Otherwise, S pushes a node segment of F, followed by the segments of the RL. For details on the "NEXT" and "PUSH" operations, refer to [RFC8402].
そうするために、S は Adj-SID(S-F) に「NEXT」操作を適用し、その後 1 つ以上の「PUSH」操作を適用しなければなりません。RL が S-F を回避しながら F で終了する場合、S は RL のセグメントのみをプッシュします。それ以外の場合、S は F のノード セグメントをプッシュし、続いて RL のセグメントをプッシュします。"NEXT" および "PUSH" オペレーションの詳細については、[RFC8402] を参照してください。
Upon failure of S-F, a packet reaching S with a segment list matching [adj-sid(S-F), adj-sid(F-M), ...] will thus leave S with a segment list matching [RL(F), node(F), adj-sid(F-M), ...], where RL(F) is the RL for destination F.
S-F が失敗すると、[adj-sid(S-F), adj-sid(F-M), ...] に一致するセグメント リストを持って S に到達したパケットは、[RL(F), node(F), adj-sid(F-M), ...] に一致するセグメント リストを持って S を離れます。ここで、RL(F) は宛先 F の RL です。
If the next segment in the stack is a node segment, say for node T, the segment list on the packet matches [adj-sid(S-F), node(T), ...].
スタック内の次のセグメントがノード セグメントである場合、たとえばノード T の場合、パケットのセグメント リストは [adj-sid(S-F), node(T), ...] と一致します。
In this case, S MUST apply a "NEXT" operation on the Adjacency segment related to S-F, followed by a "PUSH" of an RL redirecting the traffic to a node Q, whose path to node segment T is not affected by the failure.
この場合、S は、S-F に関連する隣接セグメントに「NEXT」操作を適用し、その後、ノード セグメント T へのパスが障害の影響を受けないノード Q にトラフィックをリダイレクトする RL の「PUSH」を適用しなければなりません。
Upon failure of S-F, packets reaching S with a segment list matching [adj-sid(S-F), node(T), ...] would leave S with a segment list matching [RL(Q), node(T), ...].
S-F が失敗すると、セグメント リストが [adj-sid(S-F)、node(T)、...] に一致するパケットが S に到達し、セグメント リストが [RL(Q)、node(T)、...] に一致して S から出ます。
The MPLS data plane for SR is described in [RFC8660].
SR の MPLS データ プレーンは [RFC8660] で説明されています。
The following data plane behaviors apply when creating an RL using an MPLS data plane:
MPLS データ プレーンを使用して RL を作成する場合、次のデータ プレーンの動作が適用されます。
1. If the active segment is a node segment that has been signaled with penultimate hop popping, and the RL ends with an Adjacency segment terminating on the penultimate node of the active segment, then the active segment MUST be popped before pushing the RL.
1. アクティブ セグメントが最後から 2 番目のホップ ポッピングでシグナリングされたノード セグメントであり、アクティブ セグメントの最後から 2 番目のノードで終了する隣接セグメントで RL が終了する場合、アクティブ セグメントは RL をプッシュする前にポップされなければなりません (MUST)。
2. If the active segment is a node segment, but the other conditions in 1. are not met, the active segment MUST be popped and then pushed again with a label value computed according to the Segment Routing Global Block (SRGB) of Q, where Q is the endpoint of the RL. Finally, the RL MUST be pushed.
2. アクティブ セグメントがノード セグメントであるが、1. の他の条件が満たされない場合は、アクティブ セグメントをポップし、Q のセグメント ルーティング グローバル ブロック (SRGB) に従って計算されたラベル値で再度プッシュしなければなりません (Q は RL のエンドポイントです)。最後に、RL を押す必要があります。
SRv6 data plane and programming instructions are described respectively in [RFC8754] and [RFC8986].
SRv6 データプレーンとプログラミング命令は、それぞれ [RFC8754] と [RFC8986] で説明されています。
The TI-LFA path computation algorithm is the same as in the SR-MPLS data plane. Note, however, that the Adjacency SIDs are typically globally routed. In such a case, there is no need for preceding an Adjacency SID with a Prefix-SID [RFC8402], and the resulting RL is likely shorter.
TI-LFA パス計算アルゴリズムは SR-MPLS データ プレーンと同じです。ただし、隣接 SID は通常、グローバルにルーティングされることに注意してください。このような場合、隣接関係 SID の前にプレフィックス SID [RFC8402] を付ける必要はなく、結果として得られる RL はおそらく短くなるでしょう。
If the traffic is protected at a Transit Node, then an SRv6 SID list is added on the packet to apply the RL. The addition of the RL follows the head-end behaviors as specified in Section 5 of [RFC8986].
トラフィックがトランジット ノードで保護されている場合、RL を適用するために SRv6 SID リストがパケットに追加されます。RL の追加は、[RFC8986] のセクション 5 で指定されているヘッドエンドの動作に従います。
If the traffic is protected at an SR Segment Endpoint Node, first the Segment Endpoint packet processing is executed. Then, the packet is protected as if it were a transit packet.
トラフィックが SR セグメント エンドポイント ノードで保護されている場合、最初にセグメント エンドポイント パケット処理が実行されます。その後、パケットは通過パケットであるかのように保護されます。
SR allows an operator to bind an algorithm to a Prefix-SID (as defined in [RFC8402]). The algorithm value dictates how the path to the prefix is computed. The SR default algorithm is known as the "Shortest Path" algorithm. The SR default algorithm allows an operator to override the IGP shortest path by using local policies. When TI-LFA uses Node-SIDs associated with the default algorithm, there is no guarantee that the path will be loop-free, as a local policy may have overridden the expected IGP path. As the local policies are defined by the operator, it becomes the responsibility of this operator to ensure that the deployed policies do not affect the TI-LFA deployment. It should be noted that such a situation can already happen today with existing mechanisms such as RLFA.
SR を使用すると、オペレータはアルゴリズムを Prefix-SID ([RFC8402] で定義されているように) にバインドできます。アルゴリズム値は、プレフィックスへのパスがどのように計算されるかを決定します。SR のデフォルト アルゴリズムは、「最短パス」アルゴリズムとして知られています。SR のデフォルト アルゴリズムを使用すると、オペレータはローカル ポリシーを使用して IGP 最短パスをオーバーライドできます。TI-LFA がデフォルトのアルゴリズムに関連付けられたノード SID を使用する場合、ローカル ポリシーによって予期される IGP パスがオーバーライドされる可能性があるため、パスがループフリーであるという保証はありません。ローカル ポリシーはオペレータによって定義されるため、展開されたポリシーが TI-LFA の展開に影響を与えないようにするのはこのオペレータの責任になります。このような状況は、今日、RLFA などの既存のメカニズムですでに発生する可能性があることに注意する必要があります。
[RFC9350] defines a Flexible Algorithm framework to be associated with Prefix-SIDs. A Flexible Algorithm allows a user to associate a constrained path to a Prefix-SID rather than using the regular IGP shortest path. An implementation MAY support TI-LFA to protect Node-SIDs associated with a Flexible Algorithm. In such a case, rather than computing the expected post-convergence path based on the regular SPF, an implementation SHOULD use the constrained SPF algorithm bound to the Flexible Algorithm (using the Flexible Algorithm Definition) instead of the regular Dijkstra in all the SPF/ reverse SPF computations that are occurring during the TI-LFA computation. This includes the computation of the P-space and Q-space as well as the post-convergence path. Furthermore, the implementation SHOULD only use Node-SIDs/Adj-SIDs bound to the Flexible Algorithm and/or unprotected Adj-SIDs of the regular SPF to build the RL. The use of regular Dijkstra for the TI-LFA computation or for building the repair path using SIDs other than those recommended does not ensure that the traffic going over the TI-LFA repair path during the FRR period is honoring the Flexible Algorithm constraints.
[RFC9350] は、Prefix-SID に関連付けられる柔軟なアルゴリズム フレームワークを定義しています。柔軟なアルゴリズムにより、ユーザーは通常の IGP 最短パスを使用するのではなく、制約されたパスをプレフィックス SID に関連付けることができます。実装は、柔軟なアルゴリズムに関連付けられたノード SID を保護するために TI-LFA をサポートしてもよい(MAY)。このような場合、実装では、通常の SPF に基づいて予想される収束後のパスを計算するのではなく、TI-LFA 計算中に発生するすべての SPF/逆 SPF 計算で、通常のダイクストラではなく、柔軟なアルゴリズムにバインドされた制約付き SPF アルゴリズム (柔軟なアルゴリズム定義を使用) を使用する必要があります (SHOULD)。これには、P 空間と Q 空間、および収束後のパスの計算が含まれます。さらに、実装は、RL を構築するために、柔軟なアルゴリズムにバインドされた Node-SID/Adj-SID および/または通常の SPF の保護されていない Adj-SID のみを使用する必要があります (SHOULD)。TI-LFA の計算または推奨以外の SID を使用した修復パスの構築に通常のダイクストラを使用すると、FRR 期間中に TI-LFA 修復パスを通過するトラフィックが柔軟なアルゴリズムの制約に従っていることが保証されません。
The RL of segments computed by TI-LFA may contain one or more Adjacency segments. An Adjacency segment may be protected or not protected.
TI-LFA によって計算されたセグメントの RL には、1 つ以上の隣接セグメントが含まれる場合があります。隣接セグメントは保護される場合もあれば、保護されない場合もあります。
S --- R2 --- R3 ---- R4 --- R5 --- D
* | \ *
* | \ *
R7 ** R8
* |
* |
R9 -- R10
Figure 2
In Figure 2, all the metrics are equal to 1 except R2-R7,R7-R8,R8-R4,R7-R9, which have a metric of 1000. Considering R2 as a PLR to protect against the failure of node R3 for the traffic S->D, the RL computed by R2 will be [adj-sid(R7-R8), adj-sid(R8-R4)], and the outgoing interface will be to R7. If R3 fails, R2 pushes the RL onto the incoming packet to D. During the FRR, if R7-R8 fails and if TI-LFA has picked a protected Adjacency segment for Adj-SID(R7-R8), R7 will push an additional RL onto the packet following the procedures defined in Section 6.
図 2 では、メトリックが 1000 である R2-R7、R7-R8、R8-R4、R7-R9 を除くすべてのメトリックは 1 に等しくなります。 R2 を、トラフィック S->D に対するノード R3 の障害から保護する PLR と考えると、R2 によって計算される RL は [adj-sid(R7-R8), adj-sid(R8-R4)] になります。送信インターフェイスは R7 になります。R3 が失敗した場合、R2 は D への着信パケットに RL をプッシュします。FRR 中に、R7 ～ R8 が失敗し、TI-LFA が Adj-SID(R7 ～ R8) の保護された隣接セグメントを選択した場合、R7 はセクション 6 で定義された手順に従って追加の RL をパケットにプッシュします。
To avoid the possibility of this double FRR activation, an implementation of TI-LFA MAY pick only unprotected Adjacency segments when building the RL. However, it is important to note that FRR in general is intended to protect for a single pre-planned failure. If the failure that happens is worse than expected or multiple failures happen, FRR is not guaranteed to work. In such a case, fast IGP convergence remains important to restore traffic as quickly as possible.
この二重 FRR アクティベーションの可能性を回避するために、TI-LFA の実装では、RL を構築するときに保護されていない隣接セグメントのみを選択してもよい(MAY)。ただし、FRR は一般に、事前に計画された単一の障害を保護することを目的としていることに注意することが重要です。発生した障害が予想よりも悪かった場合、または複数の障害が発生した場合、FRR の動作は保証されません。このような場合、トラフィックをできるだけ早く復元するには、高速 IGP コンバージェンスが依然として重要です。
The techniques described in this document are internal functionalities to a router that can guarantee an upper bound on the time taken to restore traffic flow upon the failure of a directly connected link or node. As these techniques steer traffic to the post-convergence path as quickly as possible, this serves to minimize the disruption associated with a local failure, which can be seen as a modest security enhancement. The protection mechanism does not protect external destinations, but rather provides quick restoration for destinations that are internal to a routing domain.
この文書で説明されている技術は、直接接続されたリンクまたはノードに障害が発生した場合にトラフィック フローを復元するのにかかる時間の上限を保証できるルーターの内部機能です。これらの技術はトラフィックをできるだけ早くコンバージェンス後のパスに誘導するため、ローカル障害に伴う中断を最小限に抑えることができ、これは控えめなセキュリティ強化であると言えます。保護メカニズムは外部の宛先を保護するのではなく、ルーティング ドメインの内部にある宛先を迅速に復元します。
The security considerations described in [RFC5286] and [RFC7490] apply to this document. Similarly, as the solution described in this document is based on SR technology, the reader should be aware of the security considerations related to this technology (see [RFC8402]) and its data plane instantiations (see [RFC8660], [RFC8754], and [RFC8986]). However, this document does not introduce additional security concerns.
[RFC5286] および [RFC7490] で説明されているセキュリティ上の考慮事項がこの文書に適用されます。同様に、この文書で説明されているソリューションは SR テクノロジーに基づいているため、読者はこのテクノロジー ([RFC8402] を参照) およびそのデータ プレーンのインスタンス化 ([RFC8660]、[RFC8754]、および [RFC8986] を参照) に関連するセキュリティ上の考慮事項に注意する必要があります。ただし、この文書では追加のセキュリティ上の懸念を紹介するものではありません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[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>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <https://www.rfc-editor.org/info/rfc7916>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[IPFRR-TUNNELS]
Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
Fast Reroute using tunnels", Work in Progress, Internet-
Draft, draft-bryant-ipfrr-tunnels-03, 16 November 2007,
<https://datatracker.ietf.org/doc/html/draft-bryant-ipfrr-
tunnels-03>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
[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>.
[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene,
B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012,
<https://www.rfc-editor.org/info/rfc6571>.
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
Francois, P., and O. Bonaventure, "Framework for Loop-Free
Convergence Using the Ordered Forwarding Information Base
(oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July
2013, <https://www.rfc-editor.org/info/rfc6976>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[RFC8333] Litkowski, S., Decraene, B., Filsfils, C., and P.
Francois, "Micro-loop Prevention by Introducing a Local
Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March
2018, <https://www.rfc-editor.org/info/rfc8333>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[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>.
[SR-LOOP] 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>.
[RFC7916] raises several operational considerations when using LFA or RLFA. Section 3 of [RFC7916] presents a case where a high bandwidth link between two core routers is protected through a Provider Edge (PE) router connected with low bandwidth links. In such a case, congestion may happen when the FRR backup path is activated. [RFC7916] introduces a local policy framework to let the operator tuning manually the best alternate election based on its own requirements.
[RFC7916] では、LFA または RLFA を使用する際の運用上の考慮事項がいくつか提起されています。[RFC7916] のセクション 3 では、2 つのコア ルーター間の高帯域幅リンクが、低帯域幅リンクに接続されたプロバイダー エッジ (PE) ルーターを通じて保護されるケースが示されています。この場合、FRR 予備パス起動時に輻輳が発生する可能性があります。[RFC7916] は、オペレータが独自の要件に基づいて最適な代替選択を手動で調整できるようにするローカル ポリシー フレームワークを導入しています。
From a network capacity planning point of view, it is often assumed for simplicity that if a link L fails on a particular node X, the bandwidth consumed on L will be spread over some of the remaining links of X. The remaining links to be used are determined by the IGP routing considering that the link L has failed (we assume that the traffic uses the post-convergence path starting from the node X). In Figure 3, we consider a network with all metrics equal to 1 except the metrics on links used by PE1, PE2, and PE3, which are 1000. An easy network capacity planning method is to consider that if the link L (X-B) fails, the traffic actually flowing through L will be spread over the remaining links of X (X-H, X-D, X-A). Considering the IGP metrics, only X-H and X-D can be used in reality to carry the traffic flowing through the link L. As a consequence, the bandwidth of links X-H and X-D is sized according to this rule. We should observe that this capacity planning policy works; however, it is not fully accurate.
ネットワーク容量計画の観点から、簡単にするために、特定のノード X でリンク L に障害が発生した場合、L で消費される帯域幅は X の残りのリンクの一部に分散されると想定されることがよくあります。使用される残りのリンクは、リンク L に障害が発生したことを考慮して IGP ルーティングによって決定されます (トラフィックはノード X から始まるコンバージェンス後のパスを使用すると仮定します)。図 3 では、PE1、PE2、および PE3 によって使用されるリンク上のメトリック (1000) を除き、すべてのメトリックが 1 に等しいネットワークを検討します。簡単なネットワーク容量計画方法は、リンク L (X-B) に障害が発生した場合に、実際に L を流れるトラフィックが X の残りのリンク (X-H、X-D、X-A) に分散されることを考慮することです。IGP メトリックを考慮すると、リンク L を流れるトラフィックを伝送するために実際に使用できるのは X-H と X-D だけです。その結果、リンク X-H と X-D の帯域幅は、この規則に従ってサイズ設定されます。このキャパシティ プランニング ポリシーが機能していることを観察する必要があります。ただし、完全に正確ではありません。
In Figure 3, considering that the source of traffic is only from PE1 and PE4, when the link L fails, depending on the convergence speed of the nodes, X may reroute its forwarding entries to the remote PEs onto X-H or X-D; however, in a similar timeframe, PE1 will also reroute a subset of its traffic (the subset destined to PE2) out of its nominal path, reducing the quantity of traffic received by X. The capacity planning rule presented previously has the drawback of oversizing the network; however, it allows for preventing any transient congestion (for example, when X reroutes traffic before PE1 does).
図 3 では、トラフィックの送信元が PE1 と PE4 からのみであることを考慮すると、リンク L に障害が発生すると、ノードのコンバージェンス速度に応じて、X はリモート PE への転送エントリを X-H または X-D に再ルーティングする可能性があります。ただし、同様の時間枠で、PE1 もそのトラフィックのサブセット (PE2 宛てのサブセット) を名目パスから再ルーティングし、X が受信するトラフィックの量を減らします。前に示したキャパシティ プランニング ルールには、ネットワークが過大になるという欠点があります。ただし、これにより、一時的な輻輳（たとえば、PE1 が行う前に X がトラフィックを再ルーティングする場合）を防ぐことができます。
H --- I --- J *
| | *
PE4 | | PE3
\ | (L) | *
* A --- X --- B --- G *
* | | *
PE1 | | PE2
* | | *
* C --- D --- E --- F *
Figure 3
Based on this assumption, in order to facilitate the operation of FRR and limit the implementation of local FRR policies, traffic can be steered by the PLR onto its expected post-convergence path during the FRR phase. In our example, when link L fails, X switches the traffic destined to PE3 and PE2 on the post-convergence paths. This is perfectly in line with the capacity planning rule that was presented before and also in line with the fact that X may converge before PE1 (or any other upstream router) and may spread the X-B traffic onto the post-convergence paths rooted at X.
この仮定に基づいて、FRR の運用を容易にし、ローカル FRR ポリシーの実装を制限するために、FRR フェーズ中にトラフィックを PLR によって予想されるコンバージェンス後のパスに誘導できます。この例では、リンク L に障害が発生すると、X はコンバージェンス後のパス上の PE3 および PE2 宛てのトラフィックを切り替えます。これは、以前に提示したキャパシティ プランニング ルールと完全に一致しており、X が PE1 (またはその他の上流ルータ) より前にコンバージし、X をルートとするコンバージェンス後のパスに X-B トラフィックを分散する可能性があるという事実とも一致しています。
It should be noted that some networks may have a different capacity planning rule, leading to an allocation of less bandwidth on X-H and X-D links. In such a case, using the post-convergence paths rooted at X during FRR may introduce some congestion on X-H and X-D links. However, it is important to note that a transient congestion may possibly happen even without FRR activated, for instance, when X converges before the upstream routers. Operators are still free to use the policy framework defined in [RFC7916] if the usage of the post-convergence paths rooted at the PLR is not suitable.
一部のネットワークには異なる容量計画ルールがあり、X-H および X-D リンク上の帯域幅の割り当てが少なくなる場合があることに注意してください。このような場合、FRR 中に X をルートとするコンバージェンス後のパスを使用すると、X-H および X-D リンクである程度の輻輳が発生する可能性があります。ただし、FRR がアクティブになっていない場合でも、たとえば X が上流ルーターの前で収束する場合など、一時的な輻輳が発生する可能性があることに注意することが重要です。PLR をルートとするコンバージェンス後のパスの使用が適切でない場合でも、オペレータは [RFC7916] で定義されているポリシー フレームワークを自由に使用できます。
Readers should be aware that FRR protection is pre-computing a backup path to protect against a particular type of failure (link, node, or SRLG). When using the post-convergence path as an FRR backup path, the computed post-convergence path is the one considering the failure we are protecting against. This means that FRR is using an expected post-convergence path, and this expected post-convergence path may be actually different from the post-convergence path used if the failure that happened is different from the failure FRR was protecting against. As an example, if the operator has implemented a protection against a node failure, the expected post-convergence path used during FRR will be the one considering that the node has failed. However, even if a single link is failing or a set of links is failing (instead of the full node), the node-protecting post-convergence path will be used. The consequence is that the path used during FRR is not optimal with respect to the failure that has actually occurred.
FRR 保護は、特定の種類の障害 (リンク、ノード、または SRLG) から保護するためにバックアップ パスを事前に計算していることに注意してください。コンバージェンス後のパスを FRR バックアップ パスとして使用する場合、計算されたコンバージェンス後のパスは、保護対象の障害を考慮したものになります。これは、FRR が予想されるコンバージェンス後のパスを使用していることを意味します。発生した障害が FRR が保護していた障害と異なる場合、この予想されるコンバージェンス後のパスは実際に使用されるコンバージェンス後のパスとは異なる可能性があります。たとえば、オペレータがノード障害に対する保護を実装している場合、FRR 中に使用される予想されるコンバージェンス後のパスは、ノードに障害が発生したことを考慮したものになります。ただし、単一のリンクに障害が発生している場合でも、（ノード全体ではなく）一連のリンクに障害が発生している場合でも、ノードを保護するコンバージェンス後のパスが使用されます。その結果、FRR 中に使用されるパスは、実際に発生した障害に関して最適ではなくなります。
Another consideration to take into account is as follows: while using the expected post-convergence path for SR traffic using node segments only (for instance, PE to PE traffic using the shortest path) has some advantages, these advantages reduce when SR policies [RFC9256] are involved. A segment list used in an SR policy is computed to obey a set of path constraints defined locally at the head-end or centrally in a controller. TI-LFA cannot be aware of such path constraints, and there is no reason to expect the TI-LFA backup path protecting one segment in that segment list to obey those constraints. When SR policies are used and the operator wants to have a backup path that still follows the policy requirements, this backup path should be computed as part of the SR policy in the ingress node (or central controller), and the SR policy should not rely on local protection. Another option could be to use a Flexible Algorithm [RFC9350] to express the set of constraints and use a single node segment associated with a Flexible Algorithm to reach the destination. When using a node segment associated with a Flexible Algorithm, TI-LFA keeps providing an optimal backup by applying the appropriate set of constraints. The relationship between TI-LFA and the SR algorithm is detailed in Section 8.
考慮すべきもう 1 つの考慮事項は次のとおりです。ノード セグメントのみを使用する SR トラフィックの予想されるコンバージェンス後のパス (たとえば、最短パスを使用する PE 間のトラフィック) を使用すると、いくつかの利点がありますが、SR ポリシー [RFC9256] が関係する場合、これらの利点は減少します。SR ポリシーで使用されるセグメント リストは、ヘッドエンドでローカルに定義されるか、コントローラーの中央で定義されたパス制約のセットに従うように計算されます。TI-LFA はそのようなパス制約を認識できず、セグメント リスト内の 1 つのセグメントを保護する TI-LFA バックアップ パスがこれらの制約に従うことを期待する理由はありません。SR ポリシーが使用されており、オペレータがポリシー要件に準拠したバックアップ パスを必要とする場合、このバックアップ パスは入口ノード (または中央コントローラ) で SR ポリシーの一部として計算される必要があり、SR ポリシーはローカル保護に依存すべきではありません。別のオプションは、柔軟なアルゴリズム [RFC9350] を使用して一連の制約を表現し、柔軟なアルゴリズムに関連付けられた単一のノード セグメントを使用して目的地に到達することです。柔軟なアルゴリズムに関連付けられたノード セグメントを使用する場合、TI-LFA は適切な制約セットを適用することで最適なバックアップを提供し続けます。TI-LFA と SR アルゴリズムの関係については、セクション 8 で詳しく説明します。
This section presents an analysis performed on real service provider and large enterprise network topologies. The objective of the analysis is to assess the number of SIDs required in an explicit path when the mechanisms described in this document are used to protect against the failure scenarios within the scope of this document. The number of segments described in this section are applicable to instantiating SR over the MPLS forwarding plane.
このセクションでは、実際のサービス プロバイダーと大規模なエンタープライズ ネットワーク トポロジに対して実行された分析を示します。分析の目的は、このドキュメントで説明されているメカニズムを使用して、このドキュメントの範囲内の障害シナリオから保護する場合に、明示的なパスで必要な SID の数を評価することです。このセクションで説明するセグメントの数は、MPLS フォワーディング プレーン上の SR のインスタンス化に適用されます。
The measurement below indicates that, for link and local SRLG protection, a repair path of 1 SID or less delivers more than 99% coverage. For node protection, a repair path of 2 SIDs or less yields 99% coverage.
以下の測定値は、リンクおよびローカル SRLG 保護の場合、1 SID 以下の修復パスが 99% 以上のカバレッジを実現することを示しています。ノード保護の場合、2 SID 以下の修復パスにより 99% のカバレッジが得られます。
Table 1 below lists the characteristics of the networks used in our measurements. The number of links refers to the number of "bidirectional" links (not directed edges of the graph). The measurements are carried out as follows:
以下の表 1 に、測定に使用したネットワークの特性を示します。リンクの数は、「双方向」リンク (グラフの有向エッジではない) の数を指します。測定は次のように実行されます。
* For each network, the algorithms described in this document are applied to protect all prefixes against link, node, and local SRLG failure.
* 各ネットワークに対して、このドキュメントで説明されているアルゴリズムが適用され、すべてのプレフィックスをリンク、ノード、およびローカル SRLG 障害から保護します。
* For each prefix, the number of SIDs used by the repair path is recorded.
* プレフィックスごとに、修復パスで使用される SID の数が記録されます。
* The percentage of number of SIDs are listed in Tables 2, 3, 4, 5, 6, and 7.
* SID 数の割合を表 2、3、4、5、6、および 7 に示します。
+=========+=======+=======+====================+============+
| Network | Nodes | Links | Node-to-Link Ratio | SRLG Info? |
+=========+=======+=======+====================+============+
| T1 | 408 | 665 | 1.63 | Yes |
+---------+-------+-------+--------------------+------------+
| T2 | 587 | 1083 | 1.84 | No |
+---------+-------+-------+--------------------+------------+
| T3 | 93 | 401 | 4.31 | Yes |
+---------+-------+-------+--------------------+------------+
| T4 | 247 | 393 | 1.59 | Yes |
+---------+-------+-------+--------------------+------------+
| T5 | 34 | 96 | 2.82 | Yes |
+---------+-------+-------+--------------------+------------+
| T6 | 50 | 78 | 1.56 | No |
+---------+-------+-------+--------------------+------------+
| T7 | 82 | 293 | 3.57 | No |
+---------+-------+-------+--------------------+------------+
| T8 | 35 | 41 | 1.17 | Yes |
+---------+-------+-------+--------------------+------------+
| T9 | 177 | 1371 | 7.74 | Yes |
+---------+-------+-------+--------------------+------------+
Table 1: Data Set Definition
表 1: データセットの定義
The rest of this section presents the measurements done on the actual topologies. The conventions that we use are as follows:
このセクションの残りの部分では、実際のトポロジで行われた測定について説明します。私たちが使用する規則は次のとおりです。
* 0 SIDs: The calculated repair path starts with a directly connected neighbor that is also a loop-free alternate; in which case, there is no need to explicitly route the traffic using additional SIDs. This scenario is described in Section 5.1.
* 0 SID: 計算された修復パスは、ループのない代替でもある直接接続されたネイバーから始まります。この場合、追加の SID を使用してトラフィックを明示的にルーティングする必要はありません。このシナリオについてはセクション 5.1 で説明します。
* 1 SID: The repair node is a PQ node; in which case, only 1 SID is needed to guarantee a loop-free path. This scenario is covered in Section 5.2.
* 1 SID: 修復ノードは PQ ノードです。この場合、ループのないパスを保証するために必要な SID は 1 つだけです。このシナリオについてはセクション 5.2 で説明します。
* 2 or more SIDs: The repair path consists of 2 or more SIDs as described in Sections 5.3 and 5.4. We do not cover the case for 2 SIDs (Section 5.3) separately because there was no granularity in the result. Also, we treat the Node-SID + Adj-SID and Node-SID + Node-SID the same because they do not differ from the data plane point of view.
* 2 つ以上の SID: 修復パスは、セクション 5.3 および 5.4 で説明されているように 2 つ以上の SID で構成されます。結果に粒度がないため、2 つの SID のケース (セクション 5.3) については個別に説明しません。また、Node-SID + Adj-SID と Node-SID + Node-SID は、データ プレーンの観点からは変わらないため、同じように扱います。
Tables 2 and 3 below summarize the measurements on the number of SIDs needed for link protection.
以下の表 2 と 3 は、リンク保護に必要な SID の数の測定結果をまとめたものです。
+=========+========+=======+========+========+
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
+=========+========+=======+========+========+
| T1 | 74.3% | 25.3% | 0.5% | 0.0% |
+---------+--------+-------+--------+--------+
| T2 | 81.1% | 18.7% | 0.2% | 0.0% |
+---------+--------+-------+--------+--------+
| T3 | 95.9% | 4.1% | 0.1% | 0.0% |
+---------+--------+-------+--------+--------+
| T4 | 62.5% | 35.7% | 1.8% | 0.0% |
+---------+--------+-------+--------+--------+
| T5 | 85.7% | 14.3% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
| T6 | 81.2% | 18.7% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
| T7 | 98.9% | 1.1% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
| T8 | 94.1% | 5.9% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
| T9 | 98.9% | 1.0% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
Table 2: Link Protection (Repair Size Distribution)
表 2: リンク保護 (修復サイズの分布)
+=========+========+=======+========+========+
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
+=========+========+=======+========+========+
| T1 | 74.2% | 99.5% | 99.9% | 100% |
+---------+--------+-------+--------+--------+
| T2 | 81.1% | 99.8% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T3 | 95.9% | 99.9% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T4 | 62.5% | 98.2% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T5 | 85.7% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T6 | 81.2% | 99.9% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T7 | 98.8% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T8 | 94.1% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T9 | 98.9% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+
Table 3: Link Protection (Repair Size Cumulative Distribution)
表 3: リンク保護 (修復サイズの累積分布)
Tables 4 and 5 summarize the measurements on the number of SIDs needed for local SRLG protection.
表 4 および 5 は、ローカル SRLG 保護に必要な SID の数の測定結果をまとめたものです。
+=========+========+=======+========+========+
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
+=========+========+=======+========+========+
| T1 | 74.2% | 25.3% | 0.5% | 0.0% |
+---------+--------+-------+--------+--------+
| T2 | No SRLG information |
+---------+--------+-------+--------+--------+
| T3 | 93.6% | 6.3% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
| T4 | 62.5% | 35.6% | 1.8% | 0.0% |
+---------+--------+-------+--------+--------+
| T5 | 83.1% | 16.8% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
| T6 | No SRLG information |
+---------+----------------------------------+
| T7 | No SRLG information |
+---------+--------+-------+--------+--------+
| T8 | 85.2% | 14.8% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
| T9 | 98.9% | 1.1% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+
Table 4: Local SRLG Protection (Repair Size Distribution)
表 4: ローカル SRLG 保護 (修復サイズの分布)
+=========+========+=======+========+========+
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
+=========+========+=======+========+========+
| T1 | 74.2% | 99.5% | 99.9% | 100% |
+---------+--------+-------+--------+--------+
| T2 | No SRLG information |
+---------+--------+-------+--------+--------+
| T3 | 93.6% | 99.9% | 100% | 0.0% |
+---------+--------+-------+--------+--------+
| T4 | 62.5% | 98.2% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T5 | 83.1% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T6 | No SRLG information |
+---------+----------------------------------+
| T7 | No SRLG information |
+---------+--------+-------+--------+--------+
| T8 | 85.2% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+
| T9 | 98.9% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+
Table 5: Local SRLG Protection (Repair Size Cumulative Distribution)
表 5: ローカル SRLG 保護 (修理サイズの累積分布)
The remaining two tables summarize the measurements on the number of SIDs needed for node protection.
残りの 2 つの表は、ノード保護に必要な SID 数の測定結果をまとめたものです。
+=========+========+=======+========+========+========+
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs |
+=========+========+=======+========+========+========+
| T1 | 49.8% | 47.9% | 2.1% | 0.1% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T2 | 36.5% | 59.6% | 3.6% | 0.2% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T3 | 73.3% | 25.6% | 1.1% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T4 | 36.1% | 57.3% | 6.3% | 0.2% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T5 | 73.2% | 26.8% | 0.0% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T6 | 78.3% | 21.3% | 0.3% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T7 | 66.1% | 32.8% | 1.1% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T8 | 59.7% | 40.2% | 0.0% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+--------+
| T9 | 98.9% | 1.0% | 0.0% | 0.0% | 0.0% |
+---------+--------+-------+--------+--------+--------+
Table 6: Node Protection (Repair Size Distribution)
表 6: ノード保護 (修復サイズの分布)
+=========+========+=======+========+========+========+
| Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs |
+=========+========+=======+========+========+========+
| T1 | 49.7% | 97.6% | 99.8% | 99.9% | 100% |
+---------+--------+-------+--------+--------+--------+
| T2 | 36.5% | 96.1% | 99.7% | 99.9% | 100% |
+---------+--------+-------+--------+--------+--------+
| T3 | 73.3% | 98.9% | 99.9% | 100% | 100% |
+---------+--------+-------+--------+--------+--------+
| T4 | 36.1% | 93.4% | 99.8% | 99.9% | 100% |
+---------+--------+-------+--------+--------+--------+
| T5 | 73.2% | 100% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+--------+
| T6 | 78.4% | 99.7% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+--------+
| T7 | 66.1% | 98.9% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+--------+
| T8 | 59.7% | 100% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+--------+
| T9 | 98.9% | 100% | 100% | 100% | 100% |
+---------+--------+-------+--------+--------+--------+
Table 7: Node Protection (Repair Size Cumulative Distribution)
表 7: ノード保護 (修復サイズの累積分布)
The authors would like to thank Les Ginsberg, Stewart Bryant, Alexander Vainsthein, Chris Bowers, Shraddha Hedge, Wes Hardaker, Gunter Van de Velde, and John Scudder for their valuable comments.
著者らは、貴重なコメントをくださった Les Pinsberg 氏、Stewart Bryant 氏、Alexander Vainsthein 氏、Chris Bowers 氏、Shraddha Hedge 氏、Wes Hardaker 氏、Gunter Van de Velde 氏、John Scudder 氏に感謝の意を表します。
In addition to the authors listed on the front page, the following co-authors have also contributed to this document:
最初のページに記載されている著者に加えて、次の共著者もこのドキュメントに貢献しています。
Francois Clad
Cisco Systems
Pablo Camarillo
Cisco Systems
Ahmed Bashandy
HPE
United States of America
Email: abashandy.ietf@gmail.com
Stephane Litkowski
Cisco Systems
France
Email: slitkows@cisco.com
Clarence Filsfils
Cisco Systems
Brussels
Belgium
Email: cfilsfil@cisco.com
Pierre Francois
INSA Lyon
Email: pierre.francois@insa-lyon.fr
Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
Daniel Voyer
Bell Canada
Canada
Email: daniel.voyer@bell.ca