[要約] RFC 8102は、リモートLFAノード保護と管理に関する標準化されたプロトコルです。その目的は、ネットワークの冗長性と信頼性を向上させるために、リモートLFAノードの保護と管理を効果的に行うことです。
Internet Engineering Task Force (IETF) P. Sarkar, Ed.
Request for Comments: 8102 Arrcus, Inc.
Category: Standards Track S. Hegde
ISSN: 2070-1721 C. Bowers
Juniper Networks, Inc.
H. Gredler
RtBrick, Inc.
S. Litkowski
Orange
March 2017
Remote-LFA Node Protection and Manageability
リモートLFAノードの保護と管理性
Abstract
概要
The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.
現在のリモートLFA仕様に従って計算されたループフリー代替（LFA）は、リンク保護のみを保証します。結果のリモートLFAネクストホップ（「PQノード」とも呼ばれます）は、それによって保護されているすべての宛先のノード保護を保証しない場合があります。
This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.
このドキュメントでは、特定のPQノードが特定の宛先にノード保護を提供するかどうかを決定する手順を指定する、リモートループフリーベースのIP高速再ルーティングメカニズムの拡張について説明します。このドキュメントには、代替パスの完全な特性を収集するために同じ手順を使用する方法も示されています。すべての代替パスの特性に関する知識は、制約に適合しないパスを排除するためにオペレーターが定義したポリシーを適用する前兆です。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8102.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8102で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 5
2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Additional Definitions . . . . . . . . . . . . . . . . . 7
2.2.1. Link-Protecting Extended P-Space . . . . . . . . . . 7
2.2.2. Node-Protecting Extended P-Space . . . . . . . . . . 7
2.2.3. Q-Space . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4. Link-Protecting PQ-Space . . . . . . . . . . . . . . 8
2.2.5. Candidate Node-Protecting PQ-Space . . . . . . . . . 8
2.2.6. Cost-Based Definitions . . . . . . . . . . . . . . . 8
2.2.6.1. Link-Protecting Extended P-Space . . . . . . . . 9
2.2.6.2. Node-Protecting Extended P-Space . . . . . . . . 9
2.2.6.3. Q-Space . . . . . . . . . . . . . . . . . . . . . 10
2.3. Computing Node-Protecting R-LFA Path . . . . . . . . . . 10
2.3.1. Computing Candidate Node-Protecting PQ-Nodes for
Primary Next Hops . . . . . . . . . . . . . . . . . . 10
2.3.2. Computing Node-Protecting Paths from PQ-Nodes to
Destinations . . . . . . . . . . . . . . . . . . . . 12
2.3.3. Computing Node-Protecting R-LFA Paths for
Destinations with Multiple Primary Next-Hop Nodes . . 14
2.3.4. Limiting Extra Computational Overhead . . . . . . . . 18
3. Manageability of Remote-LFA Alternate Paths . . . . . . . . . 19
3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 19
3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The Remote-LFA specification [RFC7490] provides loop-free alternates that guarantee only link protection. The resulting remote-LFA alternate next hops (also referred to as the "PQ-nodes") may not provide node protection for all destinations covered by the same remote-LFA alternate, in case of failure of the primary next-hop node, and it does not provide a means to determine the same.
Remote-LFA仕様[RFC7490]は、リンク保護のみを保証するループのない代替を提供します。結果のリモートLFA代替ネクストホップ（「PQノード」とも呼ばれる）は、プライマリネクストホップノードに障害が発生した場合、同じリモートLFA代替でカバーされるすべての宛先に対してノード保護を提供しない場合があります。これを決定する手段は提供しません。
Also, the LFA Manageability document [RFC7916] requires a computing router to find all possible alternate next hops (including all possible remote-LFA), collect the complete set of path characteristics for each alternate path, run an alternate-selection policy (configured by the operator), and find the best alternate path. This will require that the remote-LFA implementation gathers all the required path characteristics along each link on the entire remote-LFA alternate path.
また、LFA管理ドキュメント[RFC7916]は、可能なすべての代替ネクストホップ（可能なすべてのリモートLFAを含む）を見つけ、各代替パスのパス特性の完全なセットを収集し、代替選択ポリシーを実行する（演算子）、最適な代替パスを見つけます。これには、リモートLFA実装が、リモートLFA代替パス全体の各リンクに沿って必要なすべてのパス特性を収集する必要があります。
With current LFA [RFC5286] and remote-LFA implementations, the forward SPF (and reverse SPF) is run with the computing router and its immediate one-hop routers as the roots. While that enables computation of path attributes (e.g., Shared Risk Link Group (SRLG) and Admin-groups) for the first alternate path segment from the computing router to the PQ-node, there is no means for the computing router to gather any path attributes for the path segment from the PQ-node to the destination. Consequently, any policy-based selection of alternate paths will consider only the path attributes from the computing router up until the PQ-node.
現在のLFA [RFC5286]とリモートLFAの実装では、フォワードSPF（およびリバースSPF）は、コンピューティングルーターとその直接の1ホップルーターをルートとして実行されます。これにより、コンピューティングルーターからPQノードへの最初の代替パスセグメントのパス属性（共有リスクリンクグループ（SRLG）や管理グループなど）の計算が可能になりますが、コンピューティングルーターがパスを収集する手段はありませんPQノードから宛先へのパスセグメントの属性。したがって、ポリシーベースの代替パスの選択では、コンピューティングルーターからPQノードまでのパス属性のみが考慮されます。
This document describes a procedure for determining node protection with remote-LFA. The same procedure is also extended for the collection of a complete set of path attributes, enabling more accurate policy-based selection for alternate paths obtained with remote-LFA.
このドキュメントでは、リモートLFAを使用してノード保護を決定する手順について説明します。同じ手順がパス属性の完全なセットの収集にも拡張され、リモートLFAで取得された代替パスのより正確なポリシーベースの選択が可能になります。
This document uses the following list of abbreviations:
このドキュメントでは、次の略語リストを使用しています。
LFA: Loop-Free Alternates
LFA：ループのない代替
RLFA or R-LFA: Remote Loop-Free Alternates
RLFAまたはR-LFA：リモートループフリー代替
ECMP: Equal-Cost Multiple Path
ECMP：等コストマルチパス
SPF: Shortest Path First graph computations
SPF：最短経路優先グラフの計算
NH: Next-Hop node
NH：ネクストホップノード
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Node protection is required to provide protection of traffic on a given forwarding node against the failure of the first-hop node on the primary forwarding path. Such protection becomes more critical in the absence of mechanisms like non-stop routing in the network. Certain operators refrain from deploying non-stop-routing in their network, due to the required complex state synchronization between redundant control plane hardwares it requires, and the significant additional computation and performance overheads it comes along with. In such cases, node protection is essential to guarantee uninterrupted flow of traffic, even in the case of an entire forwarding node going down.
プライマリ転送パス上の最初のホップノードの障害から特定の転送ノード上のトラフィックを保護するには、ノード保護が必要です。このような保護は、ネットワークにノンストップルーティングなどのメカニズムがない場合に、より重要になります。特定のオペレーターは、必要な冗長コントロールプレーンハードウェア間の複雑な状態の同期と、それに伴う大幅な追加の計算およびパフォーマンスオーバーヘッドのため、ノンストップルーティングをネットワークに展開しません。このような場合、転送ノード全体がダウンした場合でも、トラフィックの中断のないフローを保証するには、ノード保護が不可欠です。
The following sections discuss the node-protection problem in the context of remote-LFA and propose a solution.
次のセクションでは、リモートLFAのコンテキストでのノード保護の問題について説明し、解決策を提案します。
To better illustrate the problem and the solution proposed in this document, the following topology diagram from the remote-LFA document [RFC7490] is being re-used with slight modification.
このドキュメントで提案されている問題と解決策をわかりやすく説明するために、リモートLFAドキュメント[RFC7490]の次のトポロジー図を少し変更して再利用しています。
D1
/
S-x-E
/ \
N R3--D2
\ /
R1---R2
Figure 1: Topology 1
図1：トポロジ1
In the above topology, for all (non-ECMP) destinations reachable via the S-E link, there is no standard LFA alternate. As per the remote-LFA [RFC7490] alternate specifications, node R2 being the only PQ-node for the S-E link provides the next hop for all of the above destinations. Table 1 shows all possible primary and remote-LFA alternate paths for each destination.
上記のトポロジでは、S-Eリンクを介して到達可能なすべての（非ECMP）宛先に対して、標準のLFA代替はありません。リモートLFA [RFC7490]の代替仕様に従って、S-Eリンクの唯一のPQノードであるノードR2は、上記の宛先すべてにネクストホップを提供します。表1は、宛先ごとに考えられるすべてのプライマリおよびリモートLFA代替パスを示しています。
+-------------+--------------+---------+-------------------------+
| Destination | Primary Path | PQ-node | Remote-LFA Backup Path |
+-------------+--------------+---------+-------------------------+
| R3 | S->E->R3 | R2 | S=>N=>R1=>R2->R3 |
| E | S->E | R2 | S=>N=>R1=>R2->R3->E |
| D1 | S->E->D1 | R2 | S=>N=>R1=>R2->R3->E->D1 |
| D2 | S->E->R3->D2 | R2 | S=>N=>R1=>R2->R3->D2 |
+-------------+--------------+---------+-------------------------+
Table 1: Remote-LFA Backup Paths via PQ-Node R2
表1：PQノードR2を介したリモートLFAバックアップパス
A closer look at Table 1 shows that, while the PQ-node R2 provides link protection for all the destinations, it does not provide node protection for destinations E and D1. In the event of the node-failure on primary next hop E, the alternate path from the remote-LFA next hop R2 to E and D1 also becomes unavailable. So, for a remote-LFA next hop to provide node protection for a given destination, the shortest path from the given PQ-node to the given destination MUST NOT traverse the primary next hop.
表1をよく見ると、PQノードR2はすべての宛先にリンク保護を提供していますが、宛先EおよびD1にはノード保護を提供していません。プライマリネクストホップEでノード障害が発生した場合、リモートLFAネクストホップR2からEおよびD1への代替パスも使用できなくなります。したがって、リモートLFAネクストホップが特定の宛先にノード保護を提供するためには、特定のPQノードから特定の宛先への最短パスがプライマリネクストホップを通過してはいけません。
In another extension of the topology in Figure 1, let us consider an additional link between N and E with the same cost as the other links.
図1のトポロジーの別の拡張で、他のリンクと同じコストのNとEの間の追加リンクを考えてみましょう。
D1
/
S-x-E
/ / \
N---+ R3--D2
\ /
R1---R2
Figure 2: Topology 2
図2：トポロジ2
In the above topology, the S-E link is no longer on any of the shortest paths from N to R3, E, and D1. Hence, R3, E, and D1 are also included in both the extended P-space and the Q-space of E (with respect to the S-E link). Table 2 shows all possible primary and R-LFA alternate paths via PQ-node R3 for each destination reachable through the S-E link in the above topology. The R-LFA alternate paths via PQ-node R2 remain the same as in Table 1.
上記のトポロジでは、S-EリンクはNからR3、E、およびD1への最短パスのいずれにもありません。したがって、R3、E、およびD1も、（S-Eリンクに関して）Eの拡張P空間とQ空間の両方に含まれます。表2は、上記のトポロジのS-Eリンクを介して到達可能な各宛先のPQノードR3を介したすべての可能なプライマリおよびR-LFA代替パスを示しています。 PQノードR2を介したR-LFA代替パスは、表1と同じままです。
+-------------+--------------+---------+------------------------+
| Destination | Primary Path | PQ-node | Remote-LFA Backup Path |
+-------------+--------------+---------+------------------------+
| R3 | S->E->R3 | R3 | S=>N=>E=>R3 |
| E | S->E | R3 | S=>N=>E=>R3->E |
| D1 | S->E->D1 | R3 | S=>N=>E=>R3->E->D1 |
| D2 | S->E->R3->D2 | R3 | S=>N=>E=>R3->D2 |
+-------------+--------------+---------+------------------------+
Table 2: Remote-LFA Backup Paths via PQ-Node R3
表2：PQ-Node R3を介したリモートLFAバックアップパス
Again, a closer look at Table 2 shows that, unlike Table 1 where the single PQ-node R2 provided node protection for destinations R3 and D2, if we choose R3 as the R-LFA next hop, it no longer provides node protection for R3 and D2. If S chooses R3 as the R-LFA next hop and if there is a node-failure on primary next hop E, then one of the parallel ECMP paths between N and R3 also becomes unavailable on the alternate path from S to R-LFA next hop R3. So, for a remote-LFA next hop to provide node protection for a given destination, the shortest paths from S to the chosen PQ-node MUST NOT traverse the primary next-hop node.
ここでも、表2をよく見ると、単一のPQノードR2が宛先R3およびD2にノード保護を提供した表1とは異なり、R-LFAネクストホップとしてR3を選択すると、R3にノード保護が提供されなくなります。およびD2。 SがR3をR-LFAネクストホップとして選択し、プライマリネクストホップEにノード障害がある場合、NとR3の間の並列ECMPパスの1つも、SからR-LFAネクストへの代替パスで使用できなくなります。ホップR3。したがって、リモートLFAネクストホップが特定の宛先にノード保護を提供するためには、Sから選択したPQノードへの最短パスがプライマリネクストホップノードを通過してはなりません（MUST NOT）。
This document adds and enhances the following definitions, extending the ones mentioned in the Remote-LFA specification [RFC7490].
このドキュメントは、Remote-LFA仕様[RFC7490]で言及されている定義を拡張して、以下の定義を追加および拡張します。
The Remote-LFA specification [RFC7490] already defines this. The link-protecting extended P-space for a link S-E being protected is the set of routers that are reachable from one or more direct neighbors of S, except primary node E, without traversing the S-E link on any of the shortest paths from the direct neighbor to the router. This MUST exclude any direct neighbor for which there is at least one ECMP path from the direct neighbor traversing the link (S-E) being protected.
Remote-LFA仕様[RFC7490]はすでにこれを定義しています。保護されているリンクSEのリンク保護拡張Pスペースは、プライマリノードEを除く、Sの1つ以上の直接のネイバーから到達可能な一連のルーターであり、ダイレクトから最短パスのいずれかのSEリンクを経由することなくルーターに隣接。これは、保護されているリンク（S-E）を通過するダイレクトネイバーから、少なくとも1つのECMPパスが存在するダイレクトネイバーを除外する必要があります。
For a cost-based definition for link-protecting extended P-space, refer to Section 2.2.6.1.
拡張Pスペースをリンク保護するためのコストベースの定義については、セクション2.2.6.1を参照してください。
The node-protecting extended P-space for a primary next-hop node E being protected is the set of routers that are reachable from one or more direct neighbors of S, except primary node E, without traversing node E. This MUST exclude any direct neighbors for which there is at least one ECMP path from the direct neighbor traversing the node E being protected.
保護されているプライマリネクストホップノードEのノード保護拡張Pスペースは、プライマリノードEを除いて、ノードEを経由せずに、Sの1つ以上の直接ネイバーから到達可能なルーターのセットです。保護されているノードEを通過する直接ネイバーからのECMPパスが少なくとも1つあるネイバー。
For a cost-based definition for node-protecting extended P-space, refer to Section 2.2.6.2.
ノード保護拡張Pスペースのコストベースの定義については、セクション2.2.6.2を参照してください。
The Remote-LFA document [RFC7490] already defines this. The Q-space for a link S-E being protected is the set of nodes that can reach primary node E, without traversing the S-E link on any of the shortest paths from the node itself to primary next hop E. This MUST exclude any node for which there is at least one ECMP path from the node to the primary next hop E traversing the link (S-E) being protected.
Remote-LFAドキュメント[RFC7490]はすでにこれを定義しています。保護されているリンクSEのQスペースは、ノード自体からプライマリネクストホップEへの最短パスのいずれかでSEリンクを通過することなく、プライマリノードEに到達できるノードのセットです。これは、保護されているリンク（SE）を通過するノードからプライマリネクストホップEへの少なくとも1つのECMPパスがあります。
For a cost-based definition for Q-Space, refer to Section 2.2.6.3.
Q-Spaceのコストベースの定義については、セクション2.2.6.3を参照してください。
A node Y is in a link-protecting PQ-space with respect to the link (S-E) being protected if and only if Y is present in both link-protecting extended P-space and the Q-space for the link being protected.
ノードYは、保護されているリンク（S-E）に関してリンク保護PQスペースにあり、保護されているリンクのリンク保護拡張PスペースとQスペースの両方にYが存在する場合に限ります。
A node Y is in a candidate node-protecting PQ-space with respect to the node (E) being protected if and only if Y is present in both the node-protecting extended P-space and the Q-space for the link being protected.
ノードYは、保護されているリンクのノード保護拡張PスペースとQスペースの両方にYが存在する場合にのみ、保護されているノード（E）に関して候補ノード保護PQスペースにあります。 。
Please note that a node Y being in a candidate node-protecting PQ-space does not guarantee that the R-LFA alternate path via the same, in entirety, is unaffected in the event of a node failure of primary next-hop node E. It only guarantees that the path segment from S to PQ-node Y is unaffected by the same failure event. The PQ-nodes in the candidate node-protecting PQ-space may provide node protection for only a subset of destinations that are reachable through the corresponding primary link.
プライマリノードネクストホップノードEのノード障害が発生した場合に、ノードYが候補ノード保護PQスペースにあることは、R-LFA代替パス全体が影響を受けないことを保証しないことに注意してください。これは、SからPQノードYへのパスセグメントが同じ障害イベントの影響を受けないことを保証するだけです。候補ノード保護PQスペース内のPQノードは、対応するプライマリリンクを介して到達可能な宛先のサブセットのみにノード保護を提供できます。
This section provides cost-based definitions for some of the terms introduced in Section 2.2 of this document.
このセクションでは、このドキュメントのセクション2.2で導入されたいくつかの用語のコストベースの定義を提供します。
Please refer to Section 2.2.1 for a formal definition of link-protecting extended P-space.
リンク保護拡張Pスペースの正式な定義については、セクション2.2.1を参照してください。
A node Y is in a link-protecting extended P-space with respect to the link (S-E) being protected if and only if there exists at least one direct neighbor of S (Ni) other than primary next hop E that satisfies the following condition.
ノードYは、次の条件を満たすプライマリネクストホップE以外のS（Ni）の少なくとも1つの直接隣接ノードが存在する場合にのみ、保護されているリンク（SE）に関してリンク保護拡張Pスペースにあります。 。
D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y)
Where, D_opt(A,B) : Distance on the most optimum path from A to B. Ni : A direct neighbor of S other than primary next hop E. Y : The node being evaluated for link-protecting extended P-Space.
ここで、D_opt（A、B）：AからBへの最適パス上の距離。Ni：プライマリネクストホップE以外のSの直接隣接ノード。Y：拡張Pスペースのリンク保護について評価されているノード。
Figure 3: Link-Protecting Ext-P-Space Condition
図3：Ext-P-Space状態のリンク保護
Please refer to Section 2.2.2 for a formal definition of node-protecting extended P-space.
ノード保護拡張Pスペースの正式な定義については、セクション2.2.2を参照してください。
A node Y is in a node-protecting extended P-space with respect to the node E being protected if and only if there exists at least one direct neighbor of S (Ni) other than primary next hop E, that satisfies the following condition.
ノードYは、次の条件を満たす、プライマリネクストホップE以外のS（Ni）の直接隣接ノードが少なくとも1つ存在する場合にのみ、保護されているノードEに関してノード保護拡張Pスペースにあります。
D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y)
Where, D_opt(A,B) : Distance on the most optimum path from A to B. E : The primary next hop on the shortest path from S to destination. Ni : A direct neighbor of S other than primary next hop E. Y : The node being evaluated for node-protecting extended P-Space.
ここで、D_opt（A、B）：AからBへの最適パス上の距離。E：Sから宛先への最短パス上のプライマリネクストホップ。 Ni：プライマリネクストホップE以外のSの直接隣接ノード。Y：ノードを保護する拡張Pスペースについて評価されているノード。
Figure 4: Node-Protecting Ext-P-Space Condition
図4：ノード保護Ext-P-Space状態
Please note that a node Y satisfying the condition in Figure 4 above only guarantees that the R-LFA alternate path segment from S via direct neighbor Ni to the node Y is not affected in the event of a node failure of E. It does not yet guarantee that the path segment from node Y to the destination is also unaffected by the same failure event.
上記の図4の条件を満たすノードYは、Sから直接隣接Niを経由してノードYへのR-LFA代替パスセグメントがEのノード障害の場合に影響を受けないことのみを保証することに注意してください。ノードYから宛先へのパスセグメントも同じ障害イベントの影響を受けないことを保証します。
Please refer to Section 2.2.3 for a formal definition of Q-Space.
Q-Spaceの正式な定義については、セクション2.2.3を参照してください。
A node Y is in Q-space with respect to the link (S-E) being protected if and only if the following condition is satisfied:
ノードYは、保護されているリンク（S-E）に関してQ空間にあり、次の条件が満たされた場合に限ります。
D_opt(Y,E) < D_opt(S,E) + D_opt(Y,S)
Where, D_opt(A,B) : Distance on the most optimum path from A to B. E : The primary next hop on the shortest path from S to destination. Y : The node being evaluated for Q-Space.
ここで、D_opt（A、B）：AからBへの最適パス上の距離。E：Sから宛先への最短パス上のプライマリネクストホップ。 Y：Q-Spaceで評価されるノード。
Figure 5: Q-Space Condition
図5：Qスペース条件
The R-LFA alternate path through a given PQ-node to a given destination is comprised of two path segments as follows:
特定のPQノードから特定の宛先へのR-LFA代替パスは、次の2つのパスセグメントで構成されます。
1. Path segment from the computing router to the PQ-node (Remote-LFA alternate next hop), and
1. コンピューティングルーターからPQノード（リモートLFA代替ネクストホップ）へのパスセグメント、および
2. Path segment from the PQ-node to the destination being protected.
2. PQノードから保護されている宛先へのパスセグメント。
So, to ensure that an R-LFA alternate path for a given destination provides node protection, we need to ensure that none of the above path segments are affected in the event of failure of the primary next-hop node. Sections 2.3.1 and 2.3.2 show how this can be ensured.
したがって、特定の宛先のR-LFA代替パスがノード保護を提供するようにするには、プライマリネクストホップノードで障害が発生した場合に、上記のパスセグメントが影響を受けないようにする必要があります。セクション2.3.1と2.3.2は、これをどのように保証できるかを示しています。
2.3.1. Computing Candidate Node-Protecting PQ-Nodes for Primary Next Hops
2.3.1. プライマリネクストホップの候補ノード保護PQノードの計算
To choose a node-protecting R-LFA next hop for a destination R3, router S needs to consider a PQ-node from the candidate node-protecting PQ-space for the primary next hop E on the shortest path from S to R3. As mentioned in Section 2.2.2, to consider a PQ-node as a candidate node-protecting PQ-node, there must be at least one direct neighbor Ni of S, such that all shortest paths from Ni to the PQ-node do not traverse primary next-hop node E.
宛先R3のノード保護R-LFAネクストホップを選択するには、ルータSは、SからR3への最短パス上のプライマリネクストホップEの候補ノード保護PQスペースからのPQノードを考慮する必要があります。セクション2.2.2で述べたように、PQノードをノード保護PQノードの候補と見なすには、NiからPQノードへのすべての最短パスがプライマリネクストホップノードEをトラバースします。
Implementations SHOULD run the inequality in Section 2.2.6.2, Figure 4 for all direct neighbors, other than primary next-hop node E, to determine whether a node Y is a candidate node-protecting PQ-node. All of the metrics needed by this inequality would have been already collected from the forward SPFs rooted at each of direct neighbor S, computed as part of standard LFA [RFC5286] implementation. With reference to the topology in Figure 2, Table 3 shows how the above condition can be used to determine the candidate node-protecting PQ-space for S-E link (primary next hop E).
実装は、プライマリネクストホップノードE以外のすべての直接ネイバーに対してセクション2.2.6.2、図4の不等式を実行して、ノードYが候補ノード保護PQノードであるかどうかを判断する必要があります。この不等式に必要なすべてのメトリックは、直接隣接SのそれぞれをルートとするフォワードSPFからすでに収集されており、標準のLFA [RFC5286]実装の一部として計算されます。図2のトポロジを参照して、表3は、上記の条件を使用してS-Eリンク（プライマリネクストホップE）の候補ノード保護PQスペースを決定する方法を示しています。
+------------+----------+----------+----------+---------+-----------+
| Candidate | Direct | D_opt | D_opt | D_opt | Condition |
| PQ-node | Nbr (Ni) | (Ni,Y) | (Ni,E) | (E,Y) | Met |
| (Y) | | | | | |
+------------+----------+----------+----------+---------+-----------+
| R2 | N | 2 (N,R2) | 1 (N,E) | 2 | Yes |
| | | | | (E,R2) | |
| R3 | N | 2 (N,R3) | 1 (N,E) | 1 | No |
| | | | | (E,R3) | |
+------------+----------+----------+----------+---------+-----------+
Table 3: Node-Protection Evaluation for R-LFA Repair Tunnel to PQ-Node
表3：PQノードへのR-LFA修復トンネルのノード保護評価
As seen in the above Table 3, R3 does not meet the node-protecting extended p-space inequality; so, while R2 is in candidate node-protecting PQ-space, R3 is not.
上記の表3に示すように、R3はノードを保護する拡張p空間の不等式を満たしていません。したがって、R2はノード保護PQスペースの候補にありますが、R3はそうではありません。
Some SPF implementations may also produce a list of links and nodes traversed on the shortest path(s) from a given root to others. In such implementations, router S may have executed a forward SPF with each of its direct neighbors as the SPF root, executed as part of the standard LFA computations [RFC5286]. So, S may re-use the list of links and nodes collected from the same SPF computations to decide whether or not a node Y is a candidate node-protecting PQ-node. A node Y shall be considered as a node-protecting PQ-node if and only if there is at least one direct neighbor of S, other than the primary next hop E for which the primary next-hop node E does not exist on the list of nodes traversed on any of the shortest paths from the direct neighbor to the PQ-node. Table 4 is an illustration of the mechanism with the topology in Figure 2.
一部のSPF実装では、特定のルートから他のルートへの最短パスでトラバースされるリンクとノードのリストを生成する場合もあります。そのような実装では、ルータSは、標準のLFA計算[RFC5286]の一部として実行されるSPFルートとしてその直接のネイバーのそれぞれを使用して、フォワードSPFを実行している場合があります。そのため、Sは同じSPF計算から収集されたリンクとノードのリストを再利用して、ノードYがノード保護PQノードの候補であるかどうかを判断します。ノードYは、プライマリネクストホップEがリストに存在しないプライマリネクストホップE以外に、Sの直接隣接ノードが少なくとも1つある場合に限り、ノード保護PQノードと見なされます。直接隣接ノードからPQノードへの最短パスのいずれかを通過するノードの数。表4は、図2のトポロジーのメカニズムを示しています。
+-------------+---------------------------+------------+------------+
| Candidate | Repair Tunnel Path | Link | Node |
| PQ-node | (Repairing router to PQ- | Protection | Protection |
| | node) | | |
+-------------+---------------------------+------------+------------+
| R2 | S->N->R1->R2 | Yes | Yes |
| R2 | S->E->R3->R2 | No | No |
| R3 | S->N->E->R3 | Yes | No |
+-------------+---------------------------+------------+------------+
Table 4: Protection of Remote-LFA Tunnel to the PQ-Node
表4：PQノードへのリモートLFAトンネルの保護
As seen in the above Table 4, while R2 is a candidate node-protecting remote-LFA next hop for R3 and D2, it is not so for E and D1, since the primary next hop E is on the shortest path from R2 to E and D1.
上記の表4に示すように、R2はR3とD2の候補ノード保護リモートLFAネクストホップですが、プライマリネクストホップEはR2からEへの最短パス上にあるため、EとD1はそうではありません。およびD1。
Once a computing router finds all the candidate node-protecting PQ-nodes for a given directly attached primary link, it shall follow the procedure as proposed in this section to choose one or more node-protecting R-LFA paths for destinations reachable through the same primary link in the primary SPF graph.
コンピューティングルーターが、直接接続されたプライマリリンクのすべての候補ノード保護PQノードを見つけたら、このセクションで提案されている手順に従って、同じ経由で到達可能な宛先に対して1つ以上のノード保護R-LFAパスを選択します。プライマリSPFグラフのプライマリリンク。
To find a node-protecting R-LFA path for a given destination, the computing router needs to pick a subset of PQ-nodes from the candidate node-protecting PQ-space for the corresponding primary next hop, such that all the path(s) from the PQ-node(s) to the given destination remain unaffected in the event of a node failure of the primary next-hop node. To determine whether a given PQ-node belongs to such a subset of PQ-nodes, the computing router MUST ensure that none of the primary next-hop nodes are found on any of the shortest paths from the PQ-node to the given destination.
特定の宛先のノード保護R-LFAパスを見つけるには、コンピューティングルーターが、対応するプライマリネクストホップの候補ノード保護PQスペースからPQノードのサブセットを選択する必要があります。 ）プライマリネクストホップノードでノード障害が発生した場合でも、PQノードから特定の宛先への影響はありません。特定のPQノードがそのようなPQノードのサブセットに属しているかどうかを判断するには、コンピューティングルーターは、PQノードから特定の宛先への最短パスのいずれにもプライマリネクストホップノードが見つからないことを確認する必要があります。
This document proposes an additional forward SPF computation for each of the PQ-nodes to discover all shortest paths from the PQ-nodes to the destination. This will help determine whether or not a given primary next-hop node is on the shortest paths from the PQ-node to the given destination. To determine whether or not a given candidate node-protecting PQ-node provides node-protecting alternate for a given destination, all the shortest paths from the PQ-node to the given destination have to be inspected to check if the primary next-hop node is found on any of these shortest paths. To compute all the shortest paths from a candidate node-protecting PQ-node to one or more destinations, the computing router MUST run the forward SPF on the candidate node-protecting PQ-node. Soon after running the forward SPF, the computer router SHOULD run the inequality in Figure 6 below, once for each destination. A PQ-node that does not qualify the condition for a given destination does not guarantee node protection for the path segment from the PQ-node to the specific destination.
このドキュメントでは、PQノードから宛先へのすべての最短パスを検出するために、各PQノードの追加の前方SPF計算を提案します。これは、特定のプライマリネクストホップノードがPQノードから特定の宛先への最短パス上にあるかどうかを判断するのに役立ちます。特定の候補ノード保護PQノードが特定の宛先にノード保護代替を提供するかどうかを判断するには、PQノードから特定の宛先へのすべての最短パスを検査して、プライマリネクストホップノードを確認する必要がありますこれらの最短パスのいずれかにあります。候補ノード保護PQノードから1つ以上の宛先へのすべての最短パスを計算するには、コンピューティングルーターは候補ノード保護PQノードで転送SPFを実行する必要があります。フォワードSPFの実行後すぐに、コンピュータールーターは、宛先ごとに1回、以下の図6の不等式を実行する必要があります（SHOULD）。特定の宛先の条件を満たさないPQノードは、PQノードから特定の宛先へのパスセグメントのノード保護を保証しません。
D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D)
Where, D_opt(A,B) : Distance on the most optimum path from A to B. D : The destination node. E : The primary next hop on the shortest path from S to destination. Y : The node-protecting PQ-node being evaluated
ここで、D_opt（A、B）：AからBへの最適パス上の距離。D：宛先ノード。 E：Sから宛先への最短パス上のプライマリネクストホップ。 Y：評価中のノード保護PQノード
Figure 6: Node-Protecting Condition for PQ-Node to Destination
図6：PQノードから宛先へのノード保護条件
All of the above metric costs, except D_opt(Y, D), can be obtained with forward and reverse SPFs with E (the primary next hop) as the root, run as part of the regular LFA and remote-LFA implementation. The Distance_opt(Y, D) metric can only be determined by the additional forward SPF run with PQ-node Y as the root. With reference to the topology in Figure 2, Table 5 shows that the above condition can be used to determine node protection with a node-protecting PQ-node R2.
D_opt（Y、D）を除く上記のすべてのメトリックコストは、通常のLFAおよびリモートLFA実装の一部として実行されるE（プライマリネクストホップ）をルートとするフォワードおよびリバースSPFで取得できます。 Distance_opt（Y、D）メトリックは、ルートとしてPQノードYを使用して実行される追加のフォワードSPFによってのみ決定できます。図2のトポロジを参照すると、表5は、上記の条件を使用して、ノード保護PQノードR2でノード保護を決定できることを示しています。
+-------------+------------+---------+--------+---------+-----------+
| Destination | Primary-NH | D_opt | D_opt | D_opt | Condition |
| (D) | (E) | (Y, D) | (Y, E) | (E, D) | Met |
+-------------+------------+---------+--------+---------+-----------+
| R3 | E | 1 | 2 | 1 | Yes |
| | | (R2,R3) | (R2,E) | (E,R3) | |
| E | E | 2 | 2 | 0 (E,E) | No |
| | | (R2,E) | (R2,E) | | |
| D1 | E | 3 | 2 | 1 | No |
| | | (R2,D1) | (R2,E) | (E,D1) | |
| D2 | E | 2 | 2 | 1 | Yes |
| | | (R2,D2) | (R2,E) | (E,D2) | |
+-------------+------------+---------+--------+---------+-----------+
Table 5: Node-Protection Evaluation for R-LFA Path Segment between PQ-Node and Destination
表5：PQノードと宛先間のR-LFAパスセグメントのノード保護評価
As seen in the example above, R2 does not meet the node-protecting inequality for destination E and D1. And so, once again, while R2 is a node-protecting remote-LFA next hop for R3 and D2, it is not so for E and D1.
上記の例にあるように、R2は宛先EとD1のノード保護の不等式を満たしていません。つまり、R2はR3とD2のノード保護リモートLFAネクストホップですが、EとD1はそうではありません。
In SPF implementations that also produce a list of links and nodes traversed on the shortest path(s) from a given root to others, the inequality in Figure 6 above need not be evaluated. Instead, to determine whether or not a PQ-node provides node protection for a given destination, the list of nodes computed from forward SPF that run on the PQ-node for the given destination SHOULD be inspected. In case the list contains the primary next-hop node, the PQ-node does not provide node protection. Else, the PQ-node guarantees the node-protecting alternate for the given destination. Below is an illustration of the mechanism with candidate node-protecting PQ-node R2 in the topology in Figure 2.
特定のルートから他のルートへの最短パスでトラバースされるリンクとノードのリストも生成するSPF実装では、上記の図6の不等式を評価する必要はありません。代わりに、PQノードが特定の宛先にノード保護を提供するかどうかを判断するには、特定の宛先のPQノードで実行される前方SPFから計算されたノードのリストを検査する必要があります（SHOULD）。リストにプライマリネクストホップノードが含まれている場合、PQノードはノード保護を提供しません。それ以外の場合、PQノードは、指定された宛先のノード保護代替を保証します。以下は、図2のトポロジーで候補ノードを保護するPQノードR2を使用したメカニズムの図です。
+-------------+---------------------------+------------+------------+
| Destination | Shortest Path (Repairing | Link | Node |
| | router to PQ-node) | Protection | Protection |
+-------------+---------------------------+------------+------------+
| R3 | R2->R3 | Yes | Yes |
| E | R2->R3->E | Yes | No |
| D1 | R2->R3->E->D1 | Yes | No |
| D2 | R2->R3->D2 | Yes | Yes |
+-------------+---------------------------+------------+------------+
Table 6: Protection of Remote-LFA Path between PQ-node and Destination
表6：PQノードと宛先間のリモートLFAパスの保護
As seen in the above example, while R2 is a candidate node-protecting R-LFA next hop for R3 and D2, it is not so for E and D1, since the primary next hop E is on the shortest path from R2 to E and D1.
上記の例に見られるように、R2はR3とD2の候補ノード保護R-LFAネクストホップですが、プライマリネクストホップEはR2からEへの最短パス上にあり、 D1。
The procedure described in this document helps no more than to determine whether or not a given remote-LFA alternate provides node protection for a given destination. It does not find out any new remote-LFA alternate next hops, outside the ones already computed by the standard remote-LFA procedure. However, in the case of availability of more than one PQ-node (remote-LFA alternates) for a destination where node protection is required for the given primary next hop, this procedure will eliminate the PQ-nodes that do not provide node protection and choose only the ones that do.
このドキュメントで説明する手順は、特定のリモートLFA代替が特定の宛先にノード保護を提供するかどうかを判断するためにのみ役立ちます。標準のリモートLFA手順で既に計算されたホップ以外の新しいリモートLFA代替ネクストホップは検出されません。ただし、特定のプライマリネクストホップにノード保護が必要な宛先で複数のPQノード（リモートLFA代替）が使用可能な場合、この手順により、ノード保護を提供しないPQノードが削除され、機能するものだけを選択してください。
2.3.3. Computing Node-Protecting R-LFA Paths for Destinations with Multiple Primary Next-Hop Nodes
2.3.3. 複数のプライマリネクストホップノードを持つ宛先のノード保護R-LFAパスの計算
In certain scenarios, when one or more destinations may be reachable via multiple ECMP (equal-cost-multi-path) next-hop nodes and only link protection is required, there is no need to compute any alternate paths for such destinations. In the event of failure of one of the next-hop links, the remaining primary next hops shall always provide link protection. However, if node protection is required, the rest of the primary next hops may not guarantee node protection. Figure 7 below shows one such example topology.
特定のシナリオでは、1つ以上の宛先が複数のECMP（等コストマルチパス）ネクストホップノードを介して到達可能であり、リンク保護のみが必要な場合、そのような宛先の代替パスを計算する必要はありません。ネクストホップリンクの1つに障害が発生した場合、残りのプライマリネクストホップは常にリンク保護を提供します。ただし、ノード保護が必要な場合、残りのプライマリネクストホップはノード保護を保証しない場合があります。以下の図7は、このようなトポロジーの例を示しています。
D1
2 /
S---x---E1
/ \ / \
/ x / \
/ \ / \
N-------E2 R3--D2
\ 2 /
\ /
\ /
R1-------R2
2
Primary Next hops:
Destination D1 = [{ S-E1, E1}, {S-E2, E2}]
Destination D2 = [{ S-E1, E1}, {S-E2, E2}]
Figure 7: Topology with Multiple ECMP Primary Next Hops
図7：複数のECMPプライマリネクストホップを持つトポロジ
In the above example topology, costs of all links are 1, except the following links:
上記のトポロジ例では、次のリンクを除くすべてのリンクのコストは1です。
Link: S-E1, Cost: 2
リンク：S-E1、コスト：2
Link: N-E2: Cost: 2
Link: R1-R2: Cost: 2
In the above topology, on computing router S, destinations D1 and D2 are reachable via two ECMP next-hop nodes E1 and E2. However, the primary paths via next-hop node E2 also traverse via the next-hop node E1. So, in the event of node failure of next-hop node E1, both primary paths (via E1 and E2) become unavailable. Hence, if node protection is desired for destinations D1 and D2, alternate paths that do not traverse any of the primary next-hop nodes E1 and E2 need to be computed. In the above topology, the only alternate neighbor N does not provide such an LFA alternate path. Hence, one or more R-LFA node-protecting alternate paths for destinations D1 and D2, needs to be computed.
上記のトポロジでは、コンピューティングルータSで、宛先D1およびD2は2つのECMPネクストホップノードE1およびE2を介して到達可能です。ただし、ネクストホップノードE2を経由するプライマリパスもネクストホップノードE1を経由します。したがって、ネクストホップノードE1のノード障害が発生した場合、両方のプライマリパス（E1とE2を経由）が使用できなくなります。したがって、宛先D1およびD2にノード保護が必要な場合は、プライマリネクストホップノードE1およびE2のいずれも通過しない代替パスを計算する必要があります。上記のトポロジでは、唯一の代替ネイバーNは、そのようなLFA代替パスを提供しません。したがって、宛先D1およびD2の1つ以上のR-LFAノード保護代替パスを計算する必要があります。
In the above topology, the link-protecting PQ-nodes are as follows:
上記のトポロジでは、リンク保護PQノードは次のとおりです。
Primary Next Hop: E1, Link-Protecting PQ-Node: { R2 }
Primary Next Hop: E2, Link-Protecting PQ-Node: { R2 }
To find one (or more) node-protecting R-LFA paths for destinations D1 and D2, one (or more) node-protecting PQ-node(s) need to be determined first. Inequalities specified in Sections 2.2.6.2 and 2.2.6.3 can be evaluated to compute the node-protecting PQ-space for each of the next-hop nodes E1 and E2, as shown in Table 7 below. To select a PQ-node as a node-protecting PQ-node for a destination with multiple primary next-hop nodes, the PQ-node MUST satisfy the inequality for all primary next-hop nodes. Any PQ-node that is NOT a node-protecting PQ-node for all the primary next-hop nodes MUST NOT be chosen as the node-protecting PQ-node for the destination.
宛先D1およびD2の1つ（または複数）のノード保護R-LFAパスを見つけるには、最初に1つ（または複数）のノード保護PQノードを決定する必要があります。以下の表7に示すように、セクション2.2.6.2および2.2.6.3で指定された不等式を評価して、ネクストホップノードE1およびE2のそれぞれのノード保護PQスペースを計算できます。 PQノードを複数のプライマリネクストホップノードのある宛先のノード保護PQノードとして選択するには、PQノードがすべてのプライマリネクストホップノードの不等式を満たさなければならない（MUST）。すべてのプライマリネクストホップノードのノード保護PQノードではないPQノードは、宛先のノード保護PQノードとして選択してはなりません（MUST NOT）。
+--------+----------+-------+--------+--------+---------+-----------+
| Primary| Candidate| Direct| D_opt | D_opt | D_opt | Condition |
| Next | PQ- | Nbr | (Ni,Y) | (Ni,E) | (E,Y) | Met |
| Hop | node (Y) | (Ni) | | | | |
| (E) | | | | | | |
+--------+----------+-------+--------+--------+---------+-----------+
| E1 | R2 | N | 3 | 3 | 2 | Yes |
| | | | (N,R2) | (N,E1) | (E1,R2) | |
| E2 | R2 | N | 3 | 2 | 3 | Yes |
| | | | (N,R2) | (N,E2) | (E2,R2) | |
+--------+----------+-------+--------+--------+---------+-----------+
Table 7: Computing Node-Protected PQ-Nodes for Next Hop E1 and E2
表7：ネクストホップE1およびE2のノード保護PQノードの計算
In SPF implementations that also produce a list of links and nodes traversed on the shortest path(s) from a given root to others, the tunnel-repair paths from the computing router to candidate PQ-node can be examined to ensure that none of the primary next-hop nodes are traversed. PQ-nodes that provide one or more Tunnel-repair paths that do not traverse any of the primary next-hop nodes are to be considered as node-protecting PQ-nodes. Table 8 below shows the possible tunnel-repair paths to PQ-node R2.
特定のルートから他のルートへの最短パスで通過するリンクとノードのリストも生成するSPF実装では、コンピューティングルーターから候補PQノードへのトンネル修復パスを調べて、プライマリネクストホップノードがトラバースされます。プライマリネクストホップノードを通過しない1つ以上のトンネル修復パスを提供するPQノードは、ノード保護PQノードと見なされます。以下の表8は、PQノードR2への可能なトンネル修復パスを示しています。
+--------------+------------+-------------------+-------------------+
| Primary-NH | PQ-Node | Tunnel-Repair | Exclude All |
| (E) | (Y) | Paths | Primary-NH |
+--------------+------------+-------------------+-------------------+
| E1, E2 | R2 | S==>N==>R1==>R2 | Yes |
+--------------+------------+-------------------+-------------------+
Table 8: Tunnel-Repair Paths to PQ-Node R2
表8：PQノードR2へのトンネル修復パス
From Tables 7 and 8 in the example above, R2 is a node-protecting PQ-node for both primary next hops E1 and E2 and should be chosen as the node-protecting PQ-node for destinations D1 and D2 that are both reachable via the primary next-hop nodes E1 and E2.
上記の例の表7および8から、R2はプライマリネクストホップE1およびE2の両方のノード保護PQノードであり、両方を経由して到達可能な宛先D1およびD2のノード保護PQノードとして選択する必要があります。プライマリネクストホップノードE1およびE2。
Next, to find a node-protecting R-LFA path from a node-protecting PQ-node to destinations D1 and D2, inequalities specified in Figure 6 should be evaluated to ensure that R2 provides a node-protecting R-LFA path for each of these destinations, as shown below in Table 9. For an R-LFA path to qualify as a node-protecting R-LFA path for a destination with multiple ECMP primary next-hop nodes, the R-LFA path from the PQ-node to the destination MUST satisfy the inequality for all primary next-hop nodes.
次に、ノード保護PQノードから宛先D1およびD2へのノード保護R-LFAパスを見つけるには、図6で指定された不等式を評価して、R2がそれぞれのノード保護R-LFAパスを提供することを確認する必要があります。以下の表9に示すように、これらの宛先。R-LFAパスが複数のECMPプライマリネクストホップノードを持つ宛先のノード保護R-LFAパスとして適格である場合、PQノードから宛先は、すべてのプライマリネクストホップノードの不等式を満たす必要があります。
+----------+----------+-------+--------+--------+--------+----------+
| Destinat | Primary- | PQ- | D_opt | D_opt | D_opt | Condition|
| ion (D) | NH (E) | Node | (Y, D) | (Y, E) | (E, D) | Met |
| | | (Y) | | | | |
+----------+----------+-------+--------+--------+--------+----------+
| D1 | E1 | R2 | 3 (R2, | 2 (R2, | 1 (E1, | No |
| | | | D1) | E1) | D1) | |
| D1 | E2 | R2 | 3 (R2, | 3 (R2, | 2 (E2, | Yes |
| | | | D1) | E2) | D1) | |
| D2 | E1 | R2 | 2 (R2, | 2 (R2, | 2 (E1, | Yes |
| | | | D2) | E1) | D2) | |
| D2 | E2 | R2 | 2 (R2, | 2 (R2, | 3 (E2, | Yes |
| | | | D2) | E2) | D2) | |
+----------+----------+-------+--------+--------+--------+----------+
Table 9: Finding Node-Protecting R-LFA Path for Destinations D1 and D2
表9：宛先D1およびD2のノード保護R-LFAパスの検索
In SPF implementations that also produce a list of links and nodes traversed on the shortest path(s) from a given root to others, the R-LFA paths via a node-protecting PQ-node to the final destination can be examined to ensure that none of the primary next-hop nodes are traversed. One or more R-LFA paths that do not traverse any of the primary next-hop nodes guarantees node protection in the event of failure of any of the primary next-hop nodes. Table 10 shows the possible R-LFA-paths for destinations D1 and D2 via the node-protecting PQ-node R2.
特定のルートから他のルートへの最短パスでトラバースされるリンクとノードのリストも生成するSPF実装では、ノード保護PQノードを経由して最終的な宛先へのR-LFAパスを調べて、プライマリネクストホップノードは通過しません。プライマリネクストホップノードのいずれも通過しない1つ以上のR-LFAパスは、プライマリネクストホップノードのいずれかに障害が発生した場合のノード保護を保証します。表10は、ノード保護PQノードR2を介した宛先D1およびD2の可能なR-LFAパスを示しています。
+-------------+------------+---------+-----------------+------------+
| Destination | Primary-NH | PQ-Node | R-LFA Paths | Exclude |
| (D) | (E) | (Y) | | All |
| | | | | Primary-NH |
+-------------+------------+---------+-----------------+------------+
| D1 | E1, E2 | R2 | S==>N==>R1==>R2 | No |
| | | | -->R3-->E1-->D1 | |
| | | | | |
| D2 | E1, E2 | R2 | S==>N==>R1==>R2 | Yes |
| | | | -->R3-->D2 | |
+-------------+------------+---------+-----------------+------------+
Table 10: R-LFA Paths for Destinations D1 and D2
表10：宛先D1およびD2のR-LFAパス
From Tables 9 and 10 in the example above, the R-LFA path from R2 does not meet the node-protecting inequality for destination D1, while it does meet the same inequality for destination D2. So, while R2 provides a node-protecting R-LFA alternate for D2, it fails to provide node protection for destination D1. Finally, while it is possible to get a node-protecting R-LFA path for D2, no such node-protecting R-LFA path can be found for D1.
上記の例の表9および10から、R2からのR-LFAパスは、宛先D1のノード保護の不等式を満たしていませんが、宛先D2の同じ不等式を満たしています。したがって、R2はD2のノード保護R-LFA代替を提供しますが、宛先D1のノード保護を提供できません。最後に、D2のノード保護R-LFAパスを取得することは可能ですが、D1のそのようなノード保護R-LFAパスは見つかりません。
In addition to the extra reverse SPF computations suggested by the Remote-LFA document [RFC7490] (one reverse SPF for each of the directly connected neighbors), this document proposes a forward SPF computation for each PQ-node discovered in the network. Since the average number of PQ-nodes found in any network is considerably more than the number of direct neighbors of the computing router, the proposal of running one forward SPF per PQ-node may add considerably to the overall SPF computation time.
リモートLFAドキュメント[RFC7490]で提案されている追加の逆SPF計算（直接接続されたネイバーごとに1つの逆SPF）に加えて、このドキュメントでは、ネットワークで検出された各PQノードの順SPF計算を提案しています。任意のネットワークで見つかったPQノードの平均数は、コンピューティングルーターの直接の隣接ノードの数よりもかなり多いため、PQノードごとに1つのフォワードSPFを実行するという提案は、全体のSPF計算時間を大幅に増やす可能性があります。
To limit the computational overhead of the approach proposed, this document specifies that implementations MUST choose a subset from the entire set of PQ-nodes computed in the network, with a finite limit on the number of PQ-nodes in the subset. Implementations MUST choose a default value for this limit and may provide the user with a configuration knob to override the default limit. This document suggests 16 as a default value for this limit. Implementations MUST also evaluate some default preference criteria while considering a PQ-node in this subset. The exact default preference criteria to be used is outside the scope of this document and is a matter of implementation. Finally, implementations MAY also allow the user to override the default preference criteria, by providing a policy configuration for the same.
提案されたアプローチの計算オーバーヘッドを制限するために、このドキュメントは、実装がネットワークで計算されたPQノードのセット全体からサブセットを選択しなければならないことを指定します。サブセット内のPQノードの数には有限の制限があります。実装は、この制限のデフォルト値を選択する必要があり、デフォルトの制限をオーバーライドするための構成ノブをユーザーに提供する場合があります。このドキュメントでは、この制限のデフォルト値として16を推奨しています。実装は、このサブセットのPQノードを考慮しながら、いくつかのデフォルトの優先基準も評価する必要があります。使用される正確なデフォルトの優先基準は、このドキュメントの範囲外であり、実装の問題です。最後に、実装は、ポリシー設定を提供することにより、ユーザーがデフォルトの優先基準をオーバーライドできるようにすることもできます（MAY）。
This document proposes that implementations SHOULD use a default preference criteria for PQ-node selection that will put a score on each PQ-node, proportional to the number of primary interfaces for which it provides coverage, its distance from the computing router, and its router-id (or system-id in case of IS-IS). PQ-nodes that cover more primary interfaces SHOULD be preferred over PQ-nodes that cover fewer primary interfaces. When two or more PQ-nodes cover the same number of primary interfaces, PQ-nodes that are closer (based on metric) to the computing router SHOULD be preferred over PQ-nodes farther away from it. For PQ-nodes that cover the same number of primary interfaces and are the same distance from the computing router, the PQ-node with smaller router-id (or system-id in case of IS-IS) SHOULD be preferred.
このドキュメントは、実装がカバレッジを提供するプライマリインターフェイスの数、コンピューティングルーターからの距離、およびルーターに比例して、各PQノードにスコアを付けるPQノード選択のデフォルトの優先基準を使用する必要があることを提案します-id（IS-ISの場合はsystem-id）。より多くのプライマリインターフェイスをカバーするPQノードは、より少ないプライマリインターフェイスをカバーするPQノードよりも優先される必要があります。 2つ以上のPQノードが同じ数のプライマリインターフェイスをカバーしている場合、コンピューティングルーターに近い（メトリックに基づく）PQノードは、それより遠いPQノードよりも優先される必要があります（SHOULD）。同じ数のプライマリインターフェイスをカバーし、コンピューティングルーターから同じ距離にあるPQノードの場合、より小さいルーターID（IS-ISの場合はシステムID）のPQノードが推奨されます。
Once a subset of PQ-nodes is found, a computing router shall run a forward SPF on each of the PQ-nodes in the subset to continue with procedures proposed in Section 2.3.2.
PQノードのサブセットが見つかると、コンピューティングルータは、サブセット内の各PQノードで転送SPFを実行して、セクション2.3.2で提案された手順を続行します。
With the regular remote-LFA [RFC7490] functionality, the computing router may compute more than one PQ-node as usable remote-LFA alternate next hops. Additionally, [RFC7916] specifies an LFA (and a remote-LFA) manageability framework, in which an alternate selection policy may be configured to let the network operator choose one of them as the most appropriate remote-LFA alternates. For such a policy-based alternate selection to run, the computing router needs to collect all the relevant path characteristics (as specified in Section 6.2.4 of [RFC7916]) for each of the alternate paths (one through each of the PQ-nodes). As mentioned before in Section 2.3, the R-LFA alternate path through a given PQ-node to a given destination is comprised of two path segments. Section 6.2.4 of [RFC7916] specifies that any kind of alternate selection policy must consider path characteristics for both path segments while evaluating one or more RLFA alternate paths.
通常のリモートLFA [RFC7490]機能を使用すると、コンピューティングルーターは、複数のPQノードを使用可能なリモートLFA代替ネクストホップとして計算できます。さらに、[RFC7916]はLFA（およびリモートLFA）管理容易性フレームワークを指定します。このフレームワークでは、ネットワークオペレーターがリモートLFAの代替として最適なものを1つ選択できるように代替選択ポリシーを構成できます。このようなポリシーベースの代替選択を実行するには、コンピューティングルーターが各代替パス（各PQノードを介して1つ）の関連するすべてのパス特性（[RFC7916]のセクション6.2.4で指定）を収集する必要があります）。 2.3節で前述したように、特定のPQノードから特定の宛先へのR-LFA代替パスは、2つのパスセグメントで構成されます。 [RFC7916]のセクション6.2.4は、あらゆる種類の代替選択ポリシーが、1つ以上のRLFA代替パスを評価するときに両方のパスセグメントのパス特性を考慮する必要があることを指定しています。
The first path segment (i.e., from the computing router to the PQ-node) can be calculated from the regular forward SPF done as part of standard and remote LFA computations. However, without the mechanism proposed in Section 2.3.2 of this document, there is no way to determine the path characteristics for the second path segment (i.e., from the PQ-node to the destination). In the absence of the path characteristics for the second path segment, two remote-LFA alternate paths may be equally preferred based on the first path segment characteristics only, although the second path segment attributes may be different.
最初のパスセグメント（つまり、コンピューティングルーターからPQノードまで）は、標準およびリモートLFA計算の一部として行われる通常のフォワードSPFから計算できます。ただし、このドキュメントのセクション2.3.2で提案されたメカニズムがなければ、2番目のパスセグメント（つまり、PQノードから宛先）のパス特性を決定する方法はありません。 2番目のパスセグメントの属性が異なる場合でも、2番目のパスセグメントのパス特性がない場合、最初のパスセグメントの特性のみに基づいて、2つのリモートLFA代替パスが同等に優先されます。
The additional forward SPF computation proposed in Section 2.3.2 shall also collect links, nodes, and path characteristics along the second path segment. This shall enable the collection of complete path characteristics for a given remote-LFA alternate path to a given destination. The complete alternate path characteristics shall then facilitate more accurate alternate path selection while running the alternate selection policy.
セクション2.3.2で提案されている追加の前方SPF計算は、2番目のパスセグメントに沿ったリンク、ノード、およびパス特性も収集します。これにより、特定の宛先への特定のリモートLFA代替パスの完全なパス特性の収集が可能になります。完全な代替パスの特性は、代替選択ポリシーの実行中に、より正確な代替パスの選択を容易にします。
As already specified in Section 2.3.4, to limit the computational overhead of the proposed approach, forward SPF computations must be run on a selected subset from the entire set of PQ-nodes computed in the network, with a finite limit on the number of PQ-nodes in the subset. The detailed suggestion on how to select this subset is specified in the same section. While this limits the number of possible alternate paths provided to the alternate-selection policy, this is needed to keep the computational complexity within affordable limits. However, if the alternate-selection policy is very restrictive, this may leave few destinations in the entire topology without protection. Yet this limitation provides a necessary tradeoff between extensive coverage and immense computational overhead.
すでにセクション2.3.4で指定されているように、提案されたアプローチの計算オーバーヘッドを制限するには、ネットワークで計算されたPQノードのセット全体から選択されたサブセットでフォワードSPF計算を実行する必要があります。サブセット内のPQノード。このサブセットを選択する方法に関する詳細な提案は、同じセクションで指定されています。これにより、代替選択ポリシーに提供される可能な代替パスの数が制限されますが、これは、計算の複雑さを手頃な制限内に保つために必要です。ただし、代替選択ポリシーが非常に制限的である場合は、トポロジ全体で保護されていない宛先がほとんど残っていない可能性があります。ただし、この制限により、広範囲にわたるカバレッジと莫大な計算オーバーヘッドとの間の必要なトレードオフが提供されます。
The mechanism proposed in this section does not modify or invalidate any part of [RFC7916]. This document specifies a mechanism to meet the requirements specified in Section 6.2.5.4 of [RFC7916].
このセクションで提案されているメカニズムは、[RFC7916]のどの部分も変更または無効化しません。このドキュメントは、[RFC7916]のセクション6.2.5.4で指定された要件を満たすメカニズムを指定します。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
This document does not introduce any change in any of the protocol specifications. It simply proposes to run an extra SPF rooted on each PQ-node discovered in the whole network.
このドキュメントでは、プロトコル仕様の変更は紹介していません。ネットワーク全体で検出された各PQノードをルートとする追加のSPFを実行することを提案するだけです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[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, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286]アトラス、A。、エド。およびA. Zinin、編、「IP高速リルートの基本仕様：ループフリー代替」、RFC 5286、DOI 10.17487 / RFC5286、2008年9月、<http://www.rfc-editor.org/info/rfc5286> 。
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <http://www.rfc-editor.org/info/rfc7490>.
[RFC7490]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M。、およびN.したがって、「リモートループフリー代替（LFA）高速再ルーティング（FRR）」、RFC 7490、DOI 10.17487 / RFC7490、2015年4月、<http://www.rfc-editor.org/info/rfc7490>。
[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, <http://www.rfc-editor.org/info/rfc7916>.
[RFC7916] Litkowski、S.、Ed。、Decraene、B.、Filsfils、C.、Raza、K.、Horneffer、M。、およびP. Sarkar、「ループのない代替の運用管理」、RFC 7916、DOI 10.17487 / RFC7916、2016年7月、<http://www.rfc-editor.org/info/rfc7916>。
Acknowledgements
謝辞
Many thanks to Bruno Decraene for providing his useful comments. We would also like to thank Uma Chunduri for reviewing this document and providing valuable feedback. Also, many thanks to Harish Raghuveer for his review and comments on the initial draft versions of this document.
有用なコメントを提供してくれたBruno Decraeneに感謝します。このドキュメントをレビューし、貴重なフィードバックを提供してくれたUma Chunduriにも感謝します。また、このドキュメントの最初のドラフトバージョンに関するレビューとコメントを提供してくれたHarish Raghuveerに感謝します。
Authors' Addresses
著者のアドレス
Pushpasis Sarkar (editor) Arrcus, Inc.
Pushpasis Sarkar（編集者）Raracus、vol。
Email: pushpasis.ietf@gmail.com
Shraddha Hegde Juniper Networks, Inc. Electra, Exora Business Park Bangalore, KA 560103 India
Shraddha Hegde Juniper Networks、Inc. Electra、Exora Business Parkバンガロール、KA 560103インド
Email: shraddha@juniper.net
Chris Bowers Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
Chris Bowers Juniper Networks、Inc. 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: cbowers@juniper.net
Hannes Gredler RtBrick, Inc.
Hannes Gredler RtBrick、Inc.
Email: hannes@rtbrick.com
Stephane Litkowski Orange
ステファンリトコウスキーオレンジ
Email: stephane.litkowski@orange.com