[要約] RFC 7490は、リモートループフリーオルタネート（LFA）ファストリルート（FRR）の概要と目的を提供しています。このRFCの目的は、ネットワークの高い可用性と信頼性を確保するために、LFA FRRの実装と展開に関するガイドラインを提供することです。
Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 7490 C. Filsfils
Category: Standards Track S. Previdi
ISSN: 2070-1721 Cisco Systems
M. Shand
Independent Contributor
N. So
Vinci Systems
April 2015
Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)
リモートループフリー代替（LFA）高速リルート（FRR）
Abstract
概要
This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.
このドキュメントでは、RFC 5286で説明されている基本的な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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション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/rfc7490.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7490で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4
4. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 7
5. Construction of Repair Paths . . . . . . . . . . . . . . . . 8
5.1. Identifying Required Tunneled Repair Paths . . . . . . . 8
5.2. Determining Tunnel Endpoints . . . . . . . . . . . . . . 8
5.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 9
5.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 11
5.3. A Cost-Based RLFA Algorithm . . . . . . . . . . . . . . . 12
5.4. Interactions with IS-IS Overload, RFC 6987, and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Example Application of Remote LFAs . . . . . . . . . . . . . 17
7. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Operation in an LDP Environment . . . . . . . . . . . . . . . 19
9. Analysis of Real World Topologies . . . . . . . . . . . . . . 21
9.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21
9.2. LFA Only . . . . . . . . . . . . . . . . . . . . . . . . 22
9.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.4. Comparison of LFA and RLFA results . . . . . . . . . . . 24
10. Management and Operational Considerations . . . . . . . . . . 25
11. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
RFC 5714 [RFC5714] describes a framework for IP Fast Reroute (IPFRR) and provides a summary of various proposed IPFRR solutions. A basic mechanism using Loop-Free Alternates (LFAs) is described in [RFC5286] that provides good repair coverage in many topologies [RFC6571], especially those that are highly meshed. However, some topologies, notably ring-based topologies, are not well protected by LFAs alone. This is because there is no neighbor of the Point of Local Repair (PLR) that has a cost to the destination via a path that does not traverse the failure that is cheaper than the cost to the destination via the failure.
RFC 5714 [RFC5714]は、IP Fast Reroute（IPFRR）のフレームワークを説明し、提案されているさまざまなIPFRRソリューションの概要を提供します。ループフリー代替（LFA）を使用した基本的なメカニズムは[RFC5286]で説明されており、多くのトポロジ[RFC6571]、特に高度にメッシュ化されたトポロジで良好な修復範囲を提供します。ただし、一部のトポロジ、特にリングベースのトポロジは、LFAだけでは十分に保護されません。これは、障害を経由する宛先へのコストよりも安価な障害を通過しないパスを経由して宛先へのコストを持つローカル修復ポイント（PLR）のネイバーがないためです。
The method described in this document extends the LFA approach described in [RFC5286] to cover many of these cases by tunneling the packets that require IPFRR to a node that is both reachable from the PLR and can reach the destination.
このドキュメントで説明されている方法は、[RFC5286]で説明されているLFAアプローチを拡張して、PLRから到達可能で宛先に到達できるノードにIPFRRを必要とするパケットをトンネリングすることにより、これらのケースの多くをカバーします。
This document uses the terms defined in [RFC5714]. This section defines additional terms that are used in this document.
このドキュメントでは、[RFC5714]で定義されている用語を使用します。このセクションでは、このドキュメントで使用される追加の用語を定義します。
Repair tunnel: A tunnel established for the purpose of providing a virtual neighbor that is a Loop-Free Alternate.
修復トンネル：ループフリー代替である仮想ネイバーを提供する目的で確立されたトンネル。
P-space: The P-space of a router with respect to a protected link is the set of routers reachable from that specific router using the pre-convergence shortest paths without any of those paths (including equal-cost path splits) transiting that protected link.
Pスペース：保護されたリンクに関するルーターのPスペースは、その特定のルーターから到達可能なルーターのセットであり、保護されたものを通過するこれらのパス（等コストパススプリットを含む）のない、収束前の最短パスを使用リンク。
For example, the P-space of S with respect to link S-E is the set of routers that S can reach without using the protected link S-E.
たとえば、リンクS-Eに関するSのP空間は、保護されたリンクS-Eを使用せずにSが到達できるルーターのセットです。
Extended P-space: Consider the set of neighbors of a router protecting a link. Exclude from that set of routers the router reachable over the protected link. The extended P-space of the protecting router with respect to the protected link is the union of the P-spaces of the neighbors in that set of neighbors with respect to the protected link (see Section 5.2.1.2).
拡張Pスペース：リンクを保護しているルーターの近隣のセットを検討します。ルーターのセットから、保護されたリンクを介して到達可能なルーターを除外します。保護されたリンクに関する保護ルーターの拡張Pスペースは、保護されたリンクに関する近隣のセット内の近隣のPスペースの結合です（セクション5.2.1.2を参照）。
Q-space: The Q-space of a router with respect to a protected link is the set of routers from which that specific router can be reached without any path (including equal-cost path splits) transiting that protected link.
Qスペース：保護されたリンクに関するルーターのQスペースは、パス（等コストパススプリットを含む）が保護されたリンクを通過することなく、特定のルーターに到達できるルーターのセットです。
PQ node: A PQ node of a node S with respect to a protected link S-E is a node that is a member of both the P-space (or the extended P-space) of S with respect to that protected link S-E and the Q-space of E with respect to that protected link S-E. A repair tunnel endpoint is chosen from the set of PQ-nodes.
PQノード：保護リンクSEに関するノードSのPQノードは、その保護リンクSEおよびQに関するSのPスペース（または拡張Pスペース）の両方のメンバーであるノードです。 -保護されたリンクSEに関するEのスペース。修復トンネルエンドポイントは、PQノードのセットから選択されます。
Remote LFA (RLFA): The use of a PQ node rather than a neighbor of the repairing node as the next hop in an LFA repair [RFC5286].
リモートLFA（RLFA）：LFA修復の次のホップとして、修復ノードの隣接ノードではなくPQノードを使用する[RFC5286]。
In this document, the notation X-Y is used to mean the path from X to Y over the link directly connecting X and Y while the notation X->Y refers to the shortest path from X to Y via some set of unspecified nodes including the null set (i.e., including over a link directly connecting X and Y).
このドキュメントでは、XYという表記は、XとYを直接接続するリンク上のXからYへのパスを意味するために使用され、X-> Yという表記は、ヌルを含む未指定ノードのセットを介してXからYへの最短パスを指します。セット（つまり、XとYを直接接続するリンク上を含む）。
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]で説明されているように解釈されます。
The problem of LFA IPFRR reachability in some networks is illustrated by the network fragment shown in Figure 1 below.
一部のネットワークでのLFA IPFRR到達可能性の問題は、以下の図1に示すネットワークフラグメントによって示されます。
S---E
/ \
A D
\ /
B---C
Figure 1: A Simple Ring Topology
図1：単純なリングトポロジ
If all link costs are equal, traffic that is transiting link S-E cannot be fully protected by LFAs. The destination C is an Equal-Cost Multipath (ECMP) from S, and so traffic to C can be protected when S-E fails but traffic to D and E are not protectable using LFAs.
すべてのリンクコストが等しい場合、リンクS-Eを通過するトラフィックをLFAで完全に保護することはできません。宛先CはSからの等コストマルチパス（ECMP）であるため、S-Eに障害が発生してもCへのトラフィックは保護できますが、DおよびEへのトラフィックはLFAを使用して保護できません。
This document describes extensions to the basic repair mechanism in which tunnels are used to provide additional logical links that can then be used as loop-free alternates where none exist in the original topology. In Figure 1, S can reach A, B, and C without going via S-E; these form S's extended P-space with respect to S-E. The routers that can reach E without going through S-E will be in E's Q-space with respect to link S-E; these are D and C. B has equal-cost paths to E via B-A-S-E and B-C-D-E, and so the forwarder at S might choose to send a packet to E via link S-E. Hence, B is not in the Q-space of E with respect to link S-E. The single node in both S's extended P-space and E's Q-space is C; thus, node C is selected as the repair tunnel's endpoint. Thus, if a tunnel is provided between S and C as shown in Figure 2, then C, now being a direct neighbor of S, would become an LFA for D and E. The definition of (extended) P-space and Q-space are provided in Section 2, and details of the calculation of the tunnel end points are provided in Section 5.2.
このドキュメントでは、トンネルを使用して追加の論理リンクを提供する基本的な修復メカニズムの拡張について説明します。追加の論理リンクは、元のトポロジに存在しないループのない代替として使用できます。図1では、SはS-Eを経由せずにA、B、Cに到達できます。これらは、S-Eに関するSの拡張P空間を形成します。 S-Eを経由せずにEに到達できるルータは、リンクS-Eに関してEのQ空間にあります。これらはDとCです。BにはB-A-S-EとB-C-D-Eを介してEへの等コストパスがあるため、SのフォワーダーはリンクS-Eを介してEにパケットを送信することを選択できます。したがって、BはリンクS-Eに関してEのQ空間にありません。 Sの拡張P空間とEのQ空間の両方の単一ノードはCです。したがって、ノードCが修復トンネルのエンドポイントとして選択されます。したがって、図2に示すようにSとCの間にトンネルが提供されている場合、CはSの直接の隣接ノードになり、DとEのLFAになります。（拡張）P空間とQ空間の定義セクション2にトンネルのエンドポイントの計算の詳細が記載されています。セクション5.2に記載されています。
The non-failure traffic distribution is not disrupted by the provision of such a tunnel since it is only used for repair traffic and MUST NOT be used for normal traffic. Note that Operations, Administration, and Maintenance (OAM) traffic used specifically to verify the viability of the repair MAY traverse the tunnel prior to a failure.
障害のないトラフィック配信は、このようなトンネルの提供によって中断されることはありません。これは、トラフィックが修復トラフィックにのみ使用され、通常のトラフィックには使用してはならないためです。修理の実行可能性を検証するために特に使用される運用、管理、および保守（OAM）トラフィックは、障害が発生する前にトンネルを通過する場合があります。
S---E
/ \ \
A \ D
\ \ /
B---C
Figure 2: The Addition of a Tunnel
図2：トンネルの追加
The use of this technique is not restricted to ring-based topologies but it is a general mechanism that can be used to enhance the protection provided by LFAs. A study of the protection achieved using remote LFA in typical service provider core networks is provided in Section 9, and a side-by-side comparison between LFA and remote LFA is provided in Section 9.4.
この手法の使用は、リングベースのトポロジーに限定されませんが、LFAによって提供される保護を強化するために使用できる一般的なメカニズムです。一般的なサービスプロバイダーのコアネットワークでリモートLFAを使用して達成された保護の研究はセクション9で提供され、LFAとリモートLFAの比較はセクション9.4で提供されます。
Remote LFA is suitable for incremental deployment within a network, including a network that is already deploying LFA. Computation of the repair path requires acceptable CPU resources and takes place exclusively on the repairing node. In MPLS networks, the targeted LDP protocol needed to learn the label binding at the repair tunnel endpoint (Section 8) is a well understood and widely deployed technology.
リモートLFAは、LFAをすでに展開しているネットワークを含む、ネットワーク内の増分展開に適しています。修復パスの計算には、受け入れ可能なCPUリソースが必要であり、修復ノードでのみ実行されます。 MPLSネットワークでは、修復トンネルエンドポイント（セクション8）でのラベルバインディングを学習するために必要なターゲットLDPプロトコルは、よく理解され、広く展開されているテクノロジーです。
The technique described in this document is directed at providing repairs in the case of link failures. Considerations regarding node failures are discussed in Section 7. This memo describes a solution to the case where the failure occurs on a point-to-point link. It covers the case where the repair first hop is reached via a broadcast or non-broadcast multi-access (NBMA) link such as a LAN and the case where the P or Q node is attached via such a link. It does not, however, cover the more complicated case where the failed interface is a broadcast or NBMA link.
このドキュメントで説明する手法は、リンク障害が発生した場合に修復を提供することを目的としています。ノード障害に関する考慮事項については、セクション7で説明します。このメモは、障害がポイントツーポイントリンクで発生した場合の解決策について説明しています。これは、LANなどのブロードキャストまたは非ブロードキャストマルチアクセス（NBMA）リンクを介して修復の最初のホップに到達した場合と、そのようなリンクを介してPまたはQノードが接続されている場合を含みます。ただし、障害が発生したインターフェイスがブロードキャストまたはNBMAリンクである、より複雑なケースは対象外です。
This document considers the case when the repair path is confined to either a single area or to the level two routing domain. In all other cases, the chosen PQ node should be regarded as a tunnel adjacency of the repairing node, and the considerations described in Section 6 of [RFC5286] should be taken into account.
このドキュメントでは、修復パスが単一の領域またはレベル2のルーティングドメインに限定されている場合を考慮しています。それ以外の場合はすべて、選択したPQノードを修復ノードのトンネル隣接と見なし、[RFC5286]のセクション6で説明されている考慮事項を考慮する必要があります。
As with LFA FRR, when a router detects an adjacent link failure, it uses one or more repair paths in place of the failed link. Repair paths are precomputed in anticipation of later failures so they can be promptly activated when a failure is detected.
LFA FRRと同様に、ルーターは隣接リンクの障害を検出すると、障害のあるリンクの代わりに1つ以上の修復パスを使用します。修復パスは、後の障害を見越して事前に計算されるため、障害が検出されたときにすぐにアクティブ化できます。
A tunneled repair path tunnels traffic to some staging point in the network from which it is known that, in the absence of a worse-than-anticipated failure, the traffic will travel to its destination using normal forwarding without looping back. This is equivalent to providing a virtual loop-free alternate to supplement the physical loop-free alternates; hence the name "remote LFA FRR". In its simplest form, when a link cannot be entirely protected with local LFA neighbors, the protecting router seeks the help of a remote LFA staging point. Network manageability considerations may lead to a repair strategy that uses a remote LFA more frequently [LFA-MANAGE].
トンネル化された修復パスは、ネットワークのステージングポイントにトラフィックをトンネリングします。このステージングポイントから、予想よりも悪い障害がない場合、トラフィックはループバックせずに通常の転送を使用して宛先に送信されます。これは、物理的なループのない代替物を補足する仮想ループのない代替物を提供することと同等です。したがって、「リモートLFA FRR」という名前です。最も単純な形式では、ローカルLFAネイバーでリンクを完全に保護できない場合、保護ルーターはリモートLFAステージングポイントの支援を求めます。ネットワーク管理性の考慮事項は、リモートLFAをより頻繁に使用する修復戦略につながる可能性があります[LFA-MANAGE]。
Examples of worse failures are node failures (see Section 7), the failure of a Shared Risk Link Group (SRLG), the independent concurrent failures of multiple links, or broadcast or NBMA links (Section 3); protecting against such failures is out of scope for this specification.
より深刻な障害の例は、ノード障害（セクション7を参照）、共有リスクリンクグループ（SRLG）の障害、複数のリンクの独立した同時障害、またはブロードキャストリンクまたはNBMAリンク（セクション3）です。このような障害からの保護は、この仕様の範囲外です。
Consider an arbitrary protected link S-E. In LFA FRR, if a path to the destination from a neighbor N of S does not cause a packet to loop back over the link S-E (i.e., N is a loop-free alternate), then S can send the packet to N and the packet will be delivered to the destination using the pre-failure forwarding information. If there is no such LFA neighbor, then S may be able to create a virtual LFA by using a tunnel to carry the packet to a point in the network that is not a direct neighbor of S from which the packet will be delivered to the destination without looping back to S. In this document, such a tunnel is termed a repair tunnel. The tail end of this tunnel (the repair tunnel endpoint) is a "PQ node", and the repair mechanism is a "remote LFA". This tunnel MUST NOT traverse the link S-E.
任意の保護されたリンクS-Eを考えます。 LFA FRRでは、SのネイバーNから宛先へのパスが原因でパケットがリンクSEを介してループバックしない場合（つまり、Nはループのない代替）、SはNにパケットを送信し、パケットは、事前障害転送情報を使用して宛先に配信されます。そのようなLFAネイバーがない場合、Sは、トンネルを使用して、パケットが宛先に配信されるSの直接ネイバーではないネットワーク内のポイントにパケットを運ぶことにより、仮想LFAを作成できる可能性があります。このドキュメントでは、このようなトンネルを修復トンネルと呼びます。このトンネルの末尾（修復トンネルのエンドポイント）は「PQノード」であり、修復メカニズムは「リモートLFA」です。このトンネルはリンクS-Eを通過してはならない（MUST NOT）。
Note that the repair tunnel terminates at some intermediate router between S and E, and not E itself. This is clearly the case, since if it were possible to construct a tunnel from S to E, then a conventional LFA would have been sufficient to effect the repair.
修復トンネルは、E自体ではなく、SとEの間の中間ルーターで終了することに注意してください。これは明らかに事実です。SからEへのトンネルを構築することができれば、従来のLFAで修復を行うのに十分でした。
There are a number of IP-in-IP tunnel mechanisms that may be used to fulfill the requirements of this design, such as IP-in-IP [RFC1853] and Generic Routing Encapsulation (GRE) [RFC1701].
IP-in-IP [RFC1853]やGeneric Routing Encapsulation（GRE）[RFC1701]など、この設計の要件を満たすために使用できるIP-in-IPトンネルメカニズムがいくつかあります。
In an MPLS-enabled network using LDP [RFC5036], a simple label stack [RFC3032] may be used to provide the required repair tunnel. In this case, the outer label is S's neighbor's label for the repair tunnel endpoint, and the inner label is the repair tunnel endpoint's label for the packet destination. In order for S to obtain the correct inner label, it is necessary to establish a targeted LDP session [RFC5036] to the tunnel endpoint.
LDP [RFC5036]を使用するMPLS対応ネットワークでは、単純なラベルスタック[RFC3032]を使用して、必要な修復トンネルを提供できます。この場合、外部ラベルは修復トンネルエンドポイントのSのネイバーのラベルであり、内部ラベルはパケット宛先の修復トンネルエンドポイントのラベルです。 Sが正しい内部ラベルを取得するには、トンネルエンドポイントへのターゲットLDPセッション[RFC5036]を確立する必要があります。
The selection of the specific tunneling mechanism (and any necessary enhancements) used to provide a repair path is outside the scope of this document. The deployment in an MPLS/LDP environment is relatively simple in the data plane, as an LDP Label Switched Path (LSP) from S to the repair tunnel endpoint (the selected PQ node) is readily available and hence does not require any new protocol extension or design change. This LSP is automatically established as a basic property of LDP behavior. The performance of the encapsulation and decapsulation is efficient, as encapsulation is just a push of one label (like conventional MPLS-TE FRR) and the decapsulation is normally configured to occur at the penultimate hop before the repair tunnel endpoint. In the control plane, a Targeted LDP (TLDP) session is needed between the repairing node and the repair tunnel endpoint, which will need to be established and the labels processed before the tunnel can be used. The time to establish the TLDP session and acquire labels will limit the speed at which a new tunnel can be put into service. This is not anticipated to be a problem in normal operation since the managed introduction and removal of links is relatively rare, as is the incidence of failure in a well-managed network.
修復パスを提供するために使用される特定のトンネリングメカニズム（および必要な拡張機能）の選択は、このドキュメントの範囲外です。 Sから修復トンネルエンドポイント（選択したPQノード）へのLDPラベルスイッチドパス（LSP）がすぐに利用できるため、新しいプロトコル拡張を必要としないため、MPLS / LDP環境での展開はデータプレーンで比較的簡単です。または設計変更。このLSPは、LDP動作の基本プロパティとして自動的に確立されます。カプセル化は1つのラベルのプッシュ（従来のMPLS-TE FRRなど）であり、カプセル化解除は通常、修復トンネルエンドポイントの前から2番目のホップで発生するように構成されているため、カプセル化とカプセル化解除のパフォーマンスは効率的です。コントロールプレーンでは、修復ノードと修復トンネルエンドポイントの間にTargeted LDP（TLDP）セッションが必要です。これは、トンネルを使用する前に確立してラベルを処理する必要があります。 TLDPセッションを確立してラベルを取得する時間は、新しいトンネルを稼働させる速度を制限します。適切に管理されたネットワークでの障害の発生と同様に、リンクの管理された導入と削除は比較的まれであるため、これは通常の操作で問題になるとは予想されません。
When a failure is detected, it is necessary to immediately redirect traffic to the repair path. Consequently, the repair tunnel used MUST be provisioned beforehand in anticipation of the failure. Since the location of the repair tunnels is dynamically determined, it is necessary to automatically establish the repair tunnels. Multiple repair tunnels may share a tunnel endpoint.
障害が検出された場合、トラフィックをすぐに修復パスにリダイレクトする必要があります。したがって、使用される修復トンネルは、障害を見越して事前にプロビジョニングする必要があります。修理トンネルの場所は動的に決定されるため、修理トンネルを自動的に確立する必要があります。複数の修復トンネルがトンネルエンドポイントを共有する場合があります。
Not all links will require protection using a tunneled repair path. Referring to Figure 1, if E can already be protected via an LFA, S-E does not need to be protected using a repair tunnel since all destinations normally reachable through E must therefore also be protectable by an LFA; such an LFA is frequently termed a "link LFA". Tunneled repair paths (which may be calculated per prefix) are only required for links that do not have a link or per-prefix LFA.
すべてのリンクがトンネル修復パスを使用した保護を必要とするわけではありません。図1を参照すると、EがLFAを介してすでに保護されている場合、通常Eを介して到達可能なすべての宛先がLFAによっても保護される必要があるため、S-Eは修復トンネルを使用して保護する必要はありません。このようなLFAは、「リンクLFA」と呼ばれることがよくあります。トンネル修復パス（プレフィックスごとに計算される場合があります）は、リンクまたはプレフィックスごとのLFAがないリンクにのみ必要です。
It should be noted that using the Q-space of E as a proxy for the Q-space of each destination can result in failing to identify valid remote LFAs. The extent to which this reduces the effective protection coverage is topology dependent.
EのQスペースを各宛先のQスペースのプロキシとして使用すると、有効なリモートLFAを識別できない場合があることに注意してください。これが効果的な保護範囲を減少させる程度は、トポロジーに依存します。
The repair tunnel endpoint needs to be a node in the network reachable from S without traversing S-E. In addition, the repair tunnel endpoint needs to be a node from which packets will normally flow towards their destination without being attracted back to the failed link S-E.
修復トンネルエンドポイントは、S-Eを経由せずにSから到達可能なネットワーク内のノードである必要があります。さらに、修復トンネルのエンドポイントは、パケットが通常、障害のあるリンクS-Eに引き寄せられることなく宛先に向かって流れるノードである必要があります。
Note that once released from the tunnel, the packet will be forwarded, as normal, on the shortest path from the release point to its destination. This may result in the packet traversing the router E at the far end of the protected link S-E, but this is obviously not required.
トンネルから解放されると、パケットは通常どおり、解放ポイントから宛先への最短パスで転送されることに注意してください。これにより、パケットが保護リンクS-Eの遠端にあるルータEを通過する可能性がありますが、これは明らかに必要ありません。
The properties that are required of repair tunnel endpoints are as follows:
トンネルのエンドポイントの修復に必要なプロパティは次のとおりです。
o The repair tunneled point MUST be reachable from the tunnel source without traversing the failed link; and
o 修復トンネルポイントは、失敗したリンクを経由せずにトンネルソースから到達可能でなければなりません。そして
o when released from the tunnel, packets MUST proceed towards their destination without being attracted back over the failed link.
o トンネルから解放された場合、パケットは、失敗したリンクに引き寄せられることなく、宛先に向かって進む必要があります。
Provided both these requirements are met, packets forwarded over the repair tunnel will reach their destination and will not loop after a single link failure.
これらの両方の要件が満たされている場合、修復トンネルを介して転送されるパケットは宛先に到達し、単一のリンク障害の後にループしません。
In some topologies it will not be possible to find a repair tunnel endpoint that exhibits both the required properties. For example, if the ring topology illustrated in Figure 1 had a cost of four for the link B-C while the remaining links were the cost of one, then it would not be possible to establish a tunnel from S to C (without resorting to some form of source routing).
一部のトポロジでは、必要なプロパティの両方を示す修復トンネルエンドポイントを見つけることができません。たとえば、図1に示されているリングトポロジのリンクBCのコストが4で、残りのリンクのコストが1の場合、SからCへのトンネルを確立することはできません（何らかの形式に頼らないと）ソースルーティングの）。
To compute the repair path for link S-E, it is necessary to determine the set of routers that can be reached from S without traversing S-E and match this with the set of routers from which the node E can be reached by normal forwarding without traversing the link S-E.
リンクSEの修復パスを計算するには、SEを経由せずにSから到達できる一連のルーターを決定し、これを、リンクを経由せずに通常の転送でノードEに到達できる一連のルーターと一致させる必要があります。 SE。
The approach used in this memo is as follows:
このメモで使用されているアプローチは次のとおりです。
o The method of computing the set of routers that can be reached from S on the shortest path tree without traversing S-E is described. This is called the S's P-space with respect to the failure of link S-E.
o S-Eを経由せずにSから最短パスツリー上の到達可能なルーターのセットを計算する方法について説明します。これは、リンクS-Eの障害に関して、SのP空間と呼ばれます。
o The distance of the tunnel endpoint from the PLR is increased by noting that S is able to use the P-space of its neighbors with respect to the failure of link S-E since S can determine which neighbor it will use as the next hop for the repair. This is called the S's extended P-space with respect to the failure of link S-E. The use of extended P-space allows greater repair coverage and is the preferred approach.
o Sは修復のためのネクストホップとして使用するネイバーを決定できるため、リンクSEの障害に関してSがネイバーのPスペースを使用できることに注意することにより、PLRからのトンネルエンドポイントの距離が増加します。 。これは、リンクS-Eの障害に関して、Sの拡張Pスペースと呼ばれます。拡張Pスペースを使用すると、修理範囲が広がり、推奨されるアプローチです。
o Finally, two methods of computing the set of routers from which the node E can be reached by normal forwarding without traversing the link S-E. This is called the Q-space of E with respect to the link S-E.
o 最後に、リンクS-Eを経由せずに通常の転送でノードEに到達できるルーターのセットを計算する2つの方法。これは、リンクS-Eに関するEのQ空間と呼ばれます。
The selection of the preferred node from the set of nodes that are in both extended P-space and Q-space with respect to the S-E is described in Section 5.2.2.
S-Eに関して拡張P空間とQ空間の両方にあるノードのセットからの優先ノードの選択については、セクション5.2.2で説明します。
A suitable cost-based algorithm to compute the set of nodes common to both extended P-space and Q-space with respect to the S-E is provided in Section 5.3.
S-Eに関して拡張P空間とQ空間の両方に共通するノードのセットを計算するための適切なコストベースのアルゴリズムは、セクション5.3で提供されています。
The set of routers that can be reached from S on the shortest path tree without traversing S-E is termed the P-space of S with respect to the link S-E. This P-space can be obtained by computing a Shortest Path Tree (SPT) rooted at S and excising the subtree reached via the link S-E (including those routers that are members of an ECMP that includes link S-E). The exclusion of routers reachable via an ECMP that includes S-E prevents the forwarding subsystem from attempting to execute a repair via the failed link S-E. Thus, for example, if the Shortest Path First (SPF) computation stores at each node the next hops to be used to reach that node from S, then the node can be added to P-space if none of its next hops are link S-E. In the case of Figure 1, this P-space comprises nodes A and B only. Expressed in cost terms, the set of routers {P} are those for which the shortest path cost S->P is strictly less than the shortest path cost S->E->P.
S-Eを経由せずにSから最短パスツリー上のSに到達できるルーターのセットは、リンクS-Eに関してSのP空間と呼ばれます。このP空間は、Sをルートとする最短パスツリー（SPT）を計算し、リンクS-E（リンクS-Eを含むECMPのメンバーであるルーターを含む）を介して到達するサブツリーを削除することで取得できます。 S-Eを含むECMPを介して到達可能なルーターを除外することで、転送サブシステムが障害の発生したリンクS-Eを介して修復を実行することを防ぎます。したがって、たとえば、Shortest Path First（SPF）の計算で、Sからそのノードに到達するために使用されるネクストホップが各ノードに格納されている場合、そのネクストホップのいずれもリンクSEでない場合、ノードをPスペースに追加できます。 。図1の場合、このP空間はノードAとBのみで構成されます。コストで表すと、ルーターのセット{P}は、最短パスコストS-> Pが最短パスコストS-> E-> Pよりも厳密に小さいルーターです。
The description in Section 5.2.1.1 calculated router S's P-space rooted at S itself. However, since router S will only use a repair path when it has detected the failure of the link S-E, the initial hop of the repair path need not be subject to S's normal forwarding decision process. Thus, the concept of extended P-space is introduced. Router S's extended P-space is the union of the P-spaces of each of S's neighbors (N). This may be calculated by computing an SPT at each of S's neighbors (excluding E) and excising the subtree reached via the path N->S->E. Note this will excise those routers that are reachable through all ECMPs that include link S-E. The use of extended P-space may allow router S to reach potential repair tunnel endpoints that were otherwise unreachable. In cost terms, a router (P) is in extended P-space if the shortest path cost N->P is strictly less than the shortest path cost N->S->E->P. In other words, once the packet is forced to N by S, it is a lower cost for it to continue on to P by any path except one that takes it back to S and then across the S->E link.
セクション5.2.1.1の説明では、S自体をルートとするルーターSのP空間を計算しました。ただし、ルーターSはリンクS-Eの障害を検出したときにのみ修復パスを使用するため、修復パスの最初のホップはSの通常の転送決定プロセスの対象となる必要はありません。したがって、拡張P空間の概念が導入されます。ルーターSの拡張P空間は、Sの各近隣（N）のP空間の和集合です。これは、Sの近傍（Eを除く）のそれぞれでSPTを計算し、パスN-> S-> Eを介して到達したサブツリーを削除することで計算できます。これにより、リンクS-Eを含むすべてのECMPを介して到達可能なルーターが削除されます。拡張Pスペースを使用すると、ルーターSが、他の方法では到達できなかった潜在的な修復トンネルエンドポイントに到達できる場合があります。コスト面では、最短パスコストN-> Pが最短パスコストN-> S-> E-> Pよりも厳密に小さい場合、ルーター（P）は拡張Pスペースにあります。言い換えると、パケットがSによってNに強制されると、Sに戻されてからS-> Eリンクを経由するパス以外の任意のパスによってパケットがPに進むためのコストが低くなります。
Since in the case of Figure 1 node A is a per-prefix LFA for the destination node C, the set of extended P-space nodes with respect to link S-E comprises nodes A, B, and C. Since node C is also in E's Q-space with respect to link S-E, there is now a node common to both extended P-space and Q-space that can be used as a repair tunnel endpoint to protect the link S-E.
図1の場合、ノードAは宛先ノードCのプレフィックスごとのLFAであるため、リンクSEに関する拡張P空間ノードのセットはノードA、B、Cで構成されます。ノードCもEにあるため、リンクSEに関するQスペース。リンクSEを保護するための修復トンネルエンドポイントとして使用できる拡張PスペースとQスペースの両方に共通のノードがあります。
The set of routers from which the node E can be reached, by normal forwarding without traversing the link S-E, is termed the Q-space of E with respect to the link S-E. The Q-space can be obtained by computing a reverse Shortest Path Tree (rSPT) rooted at E, with the subtree that might traverse the protected link S-E excised (i.e., those nodes that would send the packet via S-E plus those nodes that have an ECMP set to E with one or more members of that ECMP set traversing the protected link S-E). The rSPT uses the cost towards the root rather than from it and yields the best paths towards the root from other nodes in the network. In the case of Figure 1, the Q-space of E with respect to S-E comprises nodes C and D only. Expressed in cost terms, the set of routers {Q} are those for which the shortest path cost Q<-E is strictly less than the shortest path cost Q<-S<-E. In Figure 1, the intersection of the E's Q-space with respect to S-E with S's P-space with respect to S-E defines the set of viable repair tunnel endpoints, known as "PQ nodes". As can be seen in the case of Figure 1, there is no common node and hence no viable repair tunnel endpoint. However, when the extended P-space (Section 5.2.1.2) at S with respect to S-E is considered, a suitable intersection is found at C.
リンクS-Eを経由せずに通常の転送によってノードEに到達できるルーターのセットは、リンクS-Eに関するEのQ空間と呼ばれます。 Q空間は、Eをルートとする逆の最短パスツリー（rSPT）を計算することで取得できます。保護されたリンクSEをトラバースする可能性のあるサブツリーが削除されます（つまり、SE経由でパケットを送信するノードと、 ECMPがEに設定され、そのECMPセットの1つ以上のメンバーが保護リンクSEを通過します。 rSPTは、コストをルートからではなくルートに向かって使用し、ネットワーク内の他のノードからルートへの最適なパスを生成します。図1の場合、S-Eに関するEのQ空間はノードCとDのみで構成されます。コストで表すと、ルーターのセット{Q}は、最短パスコストQ <-Eが最短パスコストQ <-S <-Eよりも厳密に小さいルーターです。図1では、S-Eに関するEのQ空間とS-Eに関するSのP空間の交点が、「PQノード」と呼ばれる実行可能な修復トンネルエンドポイントのセットを定義します。図1の場合に見られるように、共通ノードがないため、実行可能な修復トンネルエンドポイントはありません。ただし、S-Eに関するSでの拡張P空間（セクション5.2.1.2）を考慮すると、適切な交差がCで見つかります。
Note that the Q-space calculation could be conducted for each individual destination and a per-destination repair tunnel end point determined. However, this would, in the worst case, require an SPF computation per destination that is not currently considered to be scalable. Therefore, the Q-space of E with respect to link S-E is used as a proxy for the Q-space of each destination. This approximation is obviously correct since the repair is only used for the set of destinations which were, prior to the failure, routed through node E. This is analogous to the use of link LFAs rather than per-prefix LFAs.
Qスペースの計算は、個々の宛先ごとに行うことができ、宛先ごとに修復トンネルの終点が決定されることに注意してください。ただし、これには、最悪の場合、現在スケーラブルとは見なされていない宛先ごとのSPF計算が必要になります。したがって、リンクS-Eに関するEのQ空間は、各宛先のQ空間のプロキシとして使用されます。障害が発生する前にノードE経由でルーティングされた宛先のセットに対してのみ修復が使用されるため、この近似は明らかに正しいです。これは、プレフィックスごとのLFAではなく、リンクLFAの使用に類似しています。
The mechanisms described above will identify all the possible repair tunnel endpoints that can be used to protect a particular link. In a well-connected network, there are likely to be multiple possible release points for each protected link. All will deliver the packets correctly, so arguably, it does not matter which is chosen. However, one repair tunnel endpoint may be preferred over the others on the basis of path cost or some other selection criteria.
上記のメカニズムは、特定のリンクを保護するために使用できるすべての可能な修復トンネルエンドポイントを識別します。適切に接続されたネットワークでは、保護されたリンクごとに複数のリリースポイントが存在する可能性があります。すべてが正しくパケットを配信するため、どちらを選択するかは問題ではありません。ただし、1つの修復トンネルエンドポイントは、パスコストまたはその他の選択基準に基づいて、他よりも優先される場合があります。
There is no technical requirement for the selection criteria to be consistent across all routers, but such consistency may be desirable from an operational point of view. In general, there are advantages in choosing the repair tunnel endpoint closest (shortest metric) to S. Choosing the closest maximizes the opportunity for the traffic to be load balanced once it has been released from the tunnel. For consistency in behavior, it is RECOMMENDED that the member of the set of routers {PQ} with the lowest cost S->P be the default choice for P. In the event of a tie, the router with the lowest node identifier SHOULD be selected.
選択基準がすべてのルーター間で一貫している必要はありませんが、そのような一貫性は運用上の観点から望ましい場合があります。一般に、Sに最も近い（最短のメトリック）修復トンネルエンドポイントを選択することには利点があります。最も近いものを選択すると、トラフィックがトンネルから解放された後、ロードバランシングされる機会が最大化されます。動作の一貫性を保つために、最低コストS-> Pのルーターセット{PQ}のメンバーをPのデフォルトの選択にすることをお勧めします。同数の場合、最低のノード識別子を持つルーターは選択されました。
It is a local matter whether the repair path selection policy used by the router favors LFA repairs over RLFA repairs. An LFA repair has the advantage of not requiring the use of a tunnel; however, network manageability considerations may lead to a repair strategy that uses a remote LFA more frequently [LFA-MANAGE].
ルータが使用する修復パス選択ポリシーがRLFA修復よりもLFA修復を優先するかどうかは、ローカルな問題です。 LFA修復には、トンネルを使用する必要がないという利点があります。ただし、ネットワークの管理性を考慮すると、リモートLFAをより頻繁に使用する修復戦略が生じる可能性があります[LFA-MANAGE]。
As described in [RFC5286], always selecting a PQ node that is downstream to the destination with respect to the repairing node prevents the formation of loops when the failure is worse than expected. The use of downstream nodes reduces the repair coverage, and operators are advised to determine whether adequate coverage is achieved before enabling this selection feature.
[RFC5286]で説明されているように、修復ノードに対して常に宛先の下流にあるPQノードを選択すると、障害が予想よりも悪い場合にループが形成されなくなります。ダウンストリームノードを使用すると、修復範囲が減少します。オペレーターは、この選択機能を有効にする前に、適切な範囲が達成されているかどうかを判断するようにアドバイスされます。
The preceding text has described the computation of the remote LFA repair target (PQ) in terms of the intersection of two reachability graphs computed using an SPF algorithm. This section describes a method of computing the remote LFA repair target for a specific failed link using a cost-based algorithm. The pseudocode provided in this section avoids unnecessary SPF computations; for the sake of readability, it does not otherwise try to optimize the code. The algorithm covers the case where the repair first hop is reached via a broadcast or NBMA link such as a LAN. It also covers the case where the P or Q node is attached via such a link. It does not cover the case where the failed interface is a broadcast or NBMA link. To address that case it is necessary to compute the Q-space of each neighbor of the repairing router reachable through the LAN, i.e., to treat the pseudonode [RFC1195] as a node failure; this is because the Q-spaces of the neighbors of the pseudonode may be disjoint and require use of a neighbor-specific PQ node. The reader is referred to [NODE-PROTECTION] for further information on the use of RLFA for node repairs.
前のテキストでは、SPFアルゴリズムを使用して計算された2つの到達可能性グラフの共通部分の観点から、リモートLFA修復ターゲット（PQ）の計算について説明しました。このセクションでは、コストベースのアルゴリズムを使用して、特定の障害リンクのリモートLFA修復ターゲットを計算する方法について説明します。このセクションで提供される疑似コードは、不要なSPF計算を回避します。読みやすくするために、コードを最適化することはしません。このアルゴリズムは、LANなどのブロードキャストまたはNBMAリンクを介して修復の最初のホップに到達する場合をカバーします。また、そのようなリンクを介してPまたはQノードが接続されている場合についても説明します。障害が発生したインターフェイスがブロードキャストまたはNBMAリンクである場合は対象外です。その場合に対処するには、LANを介して到達可能な修復ルーターの各ネイバーのQスペースを計算する必要があります。つまり、疑似ノード[RFC1195]をノード障害として扱う必要があります。これは、疑似ノードの隣接ノードのQ空間が互いに素であり、隣接ノード固有のPQノードの使用が必要になる可能性があるためです。ノードの修復にRLFAを使用する方法の詳細については、[NODE-PROTECTION]を参照してください。
The following notation is used:
次の表記が使用されます。
o D_opt(a,b) is the shortest distance from node a to node b as computed by the SPF.
o D_opt（a、b）は、SPFによって計算されたノードaからノードbまでの最短距離です。
o dest is the packet destination.
o destはパケットの宛先です。
o fail_intf is the failed interface (S-E in the example).
o fail_intfは失敗したインターフェースです（例ではS-E）。
o fail_intf.remote_node is the node reachable over interface fail_intf (node E in the example).
o fail_intf.remote_nodeは、インターフェースfail_intfを介して到達可能なノードです（この例ではノードE）。
o intf.remote_node is the set of nodes reachable over interface intf.
o intf.remote_nodeは、インターフェースintfを介して到達可能なノードのセットです。
o root is the root of the SPF calculation.
o rootはSPF計算の根です。
o self is the node carrying out the computation.
o selfは計算を実行するノードです。
o y is the node in the network under consideration.
o yは、検討中のネットワーク内のノードです。
o y.pseudonode is true if y is a pseudonode.
o yが疑似ノードの場合、y.pseudonodeはtrueです。
//////////////////////////////////////////////////////////////////
//
// Main Function
//////////////////////////////////////////////////////////////////
//
// We have already computed the forward SPF from self to all nodes
// y in network and thus we know D_opt (self, y). This is needed
// for normal forwarding.
// However, for completeness:
Compute_and_Store_Forward_SPF(self)
Compute_and_Store_Forward_SPF（self）
// To extend P-space, we compute the SPF at each neighbor except
// the neighbor that is reached via the link being protected.
// We will also need D_opt(fail_intf.remote_node,y), so we
// compute that at the same time.
Compute_Neighbor_SPFs()
Compute_Neighbor_SPFs()
// Compute the set of nodes {P} reachable other than via the // failed link.
//失敗したリンク以外から到達可能なノードのセット{P}を計算します。
Compute_Extended_P_Space(fail_intf)
Compute_Extended_P_Space（fail_intf）
// Compute the set of nodes that can reach the node on the far // side of the failed link without traversing the failed link.
//失敗したリンクを走査せずに、失敗したリンクの//反対側のノードに到達できるノードのセットを計算します。
Compute_Q_Space(fail_intf)
Compute_Q_Space（fail_intf）
// Compute the set of candidate RLFA tunnel endpoints.
//候補RLFAトンネルエンドポイントのセットを計算します。
Intersect_Extended_P_and_Q_Space()
Intersect_Extended_P_and_Q_Space()
// Make sure that we cannot get looping repairs when the // failure is worse than expected.
//失敗が予想よりも悪化している場合は、//ループ修復を取得できないことを確認します。
if (guarantee_no_looping_on_worse_than_protected_failure) Apply_Downstream_Constraint()
if（guarantee_no_looping_on_worse_than_protected_failure）Apply_Downstream_Constraint()
//
// End of Main Function
//
//////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////
//
// Procedures
//
/////////////////////////////////////////////////////////////////
//
// This computes the SPF from root and stores the optimum
// distance from root to each node y.
Compute_and_Store_Forward_SPF(root) Compute_Forward_SPF(root) foreach node y in network store D_opt(root,y)
Compute_and_Store_Forward_SPF（root）Compute_Forward_SPF（root）foreachノードyネットワークストアD_opt（root、y）
/////////////////////////////////////////////////////////////////
//
// This computes the optimum distance from each neighbor (other
// than the neighbor reachable through the failed link) and
// every other node in the network.
//
// Note that we compute this for all neighbors, including the
// neighbor on the far side the failure. This is done on the
// expectation that more than one link will be protected and
// that the results are stored for later use.
//
Compute_Neighbor_SPFs() foreach interface intf in self Compute_and_Store_Forward_SPF(intf.remote_node)
Compute_Neighbor_SPFs()foreachインターフェースintf in self Compute_and_Store_Forward_SPF（intf.remote_node）
/////////////////////////////////////////////////////////////////
//
// The reverse SPF computes the cost from each remote node to
// root. This is achieved by running the normal SPF algorithm
// but using the link cost in the direction from the next hop
// back towards root in place of the link cost in the direction
// away from root towards the next hop.
Compute_and_Store_Reverse_SPF(root) Compute_Reverse_SPF(root) foreach node y in network store D_opt(y,root)
Compute_and_Store_Reverse_SPF（root）Compute_Reverse_SPF（root）forstore y in network store D_opt（y、root）
/////////////////////////////////////////////////////////////////
//
// Calculate Extended P-space
//
// Note that the "strictly less than" operator is needed to
// avoid ECMP issues.
Compute_Extended_P_Space(fail_intf)
foreach node y in network
y.in_extended_P_space = false
// Extend P-space to the P-spaces of all reachable
// neighbors
foreach interface intf in self
// Exclude failed interface, noting that
// the node reachable via that interface may be
// reachable via another interface (parallel path)
if (intf != fail_intf)
foreach neighbor n in intf.remote_node
// Apply RFC 5286 Inequality 1
if ( D_opt(n, y) <
D_opt(n,self) + D_opt(self, y))
y.in_extended_P_space = true
/////////////////////////////////////////////////////////////////
//
// Compute the Nodes in Q-space
//
Compute_Q_Space(fail_intf)
// Compute the cost from every node in the network to the
// node normally reachable across the failed link
Compute_and_Store_Reverse_SPF(fail_intf.remote_node)
// Compute the cost from every node in the network to self Compute_and_Store_Reverse_SPF(self)
//ネットワーク内のすべてのノードから自己までのコストを計算しますCompute_and_Store_Reverse_SPF（self）
foreach node y in network if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + D_opt(self,fail_intf.remote_node) ) y.in_Q_space = true else y.in_Q_space = false
ネットワークのforeachノードy if（D_opt（y、fail_intf.remote_node）<D_opt（y、self）+ D_opt（self、fail_intf.remote_node））y.in_Q_space = true else y.in_Q_space = false
/////////////////////////////////////////////////////////////////
//
// Compute Set of Nodes in Both Extended P-space and in Q-space
Intersect_Extended_P_and_Q_Space() foreach node y in network if ( y.in_extended_P_space && y.in_Q_space && y.pseudonode == False) y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false
Intersect_Extended_P_and_Q_Space()foreach node y in network if（y.in_extended_P_space && y.in_Q_space && y.pseudonode == False）y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false
/////////////////////////////////////////////////////////////////
//
// A downstream route is one where the next hop is strictly
// closer to the destination. By sending the packet to a
// PQ node that is downstream, we know that if the PQ node
// detects a failure it will not loop the packet back to self.
// This is useful when there are two failures or when a node has
// failed rather than a link.
Apply_Downstream_Constraint() foreach node y in network if (y.valid_tunnel_endpoint) Compute_and_Store_Forward_SPF(y) if ((D_opt(y,dest) < D_opt(self,dest)) y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false
Apply_Downstream_Constraint()foreach node y in network if（y.valid_tunnel_endpoint）Compute_and_Store_Forward_SPF（y）if（（D_opt（y、dest）<D_opt（self、dest））y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false
//
/////////////////////////////////////////////////////////////////
Since normal link state routing takes into account the IS-IS overload bit, OSPF stub router advertisement [RFC6987], and costed out links (as described in Section 3.5 of [RFC5286]), the forward SPFs performed by the PLR rooted at the neighbors of the PLR also need to take this into account. A repair tunnel path from a neighbor of the PLR to a repair tunnel endpoint will generally avoid the nodes and links excluded by the IGP overload/costing-out rules. However, there are two situations where this behavior may result in a repair path traversing a link or router that should be excluded:
通常のリンクステートルーティングでは、IS-IS過負荷ビット、OSPFスタブルーターアドバタイズメント[RFC6987]、およびコストアウトリンク（[RFC5286]のセクション3.5で説明）が考慮されるため、ネイバーをルートとするPLRによって実行される転送SPF PLRもこれを考慮する必要があります。 PLRのネイバーからリペアトンネルエンドポイントへのリペアトンネルパスは、IGP過負荷/コストアウトルールによって除外されたノードとリンクを通常回避します。ただし、この動作により、リンクまたはルーターを通過する修復パスが除外される可能性がある状況が2つあります。
1. One situation is when the first hop on the repair tunnel path (from the PLR to a direct neighbor) does not follow the IGP shortest path. In this case, the PLR MUST NOT use a repair tunnel path whose first hop is along a link that has a cost or reverse cost equal to MaxLinkMetric (for OSPF) or the maximum cost (for IS-IS) or whose first hop has the overload bit set (for IS-IS).
1. 1つの状況は、修復トンネルパスの最初のホップ（PLRから直接の隣接ノードへ）がIGP最短パスをたどらない場合です。この場合、PLRは、最初のホップがリンクに沿っており、コストまたはリバースコストがMaxLinkMetric（OSPFの場合）または最大コスト（IS-ISの場合）に等しいか、または最初のホップがオーバーロードビットセット（IS-IS用）。
2. The other situation is when the IS-IS overload bit and the mechanism of [RFC6987] only prevent transit traffic from traversing a node; they do not prevent traffic destined to a node. The per-neighbor forward SPFs using the standard IGP overload rules will not prevent a PLR from choosing a repair tunnel endpoint that is advertising a desire to not carry transit traffic. Therefore, the PLR MUST NOT use a repair tunnel endpoint with the IS-IS overload bit set or where all outgoing interfaces have the cost set to MaxLinkMetric for OSPF.
2. 他の状況は、IS-IS過負荷ビットと[RFC6987]のメカニズムがトランジットトラフィックがノードを通過するのを防ぐだけの場合です。ノード宛てのトラフィックは阻止されません。標準のIGP過負荷ルールを使用するネイバーごとの転送SPFは、トランジットトラフィックを伝送しないという要望を通知している修復トンネルエンドポイントをPLRが選択することを妨げません。したがって、PLRは、IS-IS過負荷ビットが設定されている、またはすべての発信インターフェイスのコストがOSPFのMaxLinkMetricに設定されている修復トンネルエンドポイントを使用してはなりません（MUST NOT）。
An example of a commonly deployed topology that is not fully protected by LFAs alone is shown in Figure 3. Provider Edge (PE)1 and PE2 are connected in the same site. P1 and P2 may be geographically separated (intersite). In order to guarantee the lowest latency path from/to all other remote PEs, normally the shortest path follows the geographical distance of the site locations. Therefore, to ensure this, a lower IGP metric (5) is assigned between PE1 and PE2. A high metric (1000) is set on the P-PE links to prevent the PEs being used for transit traffic. The PEs are not individually dual-homed in order to reduce costs.
LFAだけでは完全に保護されていない一般的に展開されるトポロジの例を図3に示します。プロバイダーエッジ（PE）1とPE2は同じサイトに接続されています。 P1とP2は地理的に離れている場合があります（サイト間）。他のすべてのリモートPEとの間の最小の遅延パスを保証するために、通常、最短パスはサイトロケーションの地理的距離に従います。したがって、これを確実にするために、PE1とPE2の間に低いIGPメトリック（5）が割り当てられます。通過トラフィックにPEが使用されないようにするために、P-PEリンクに高いメトリック（1000）が設定されています。コストを削減するために、PEは個別にデュアルホーム化されていません。
This is a common topology in Service Provider (SP) networks.
これは、サービスプロバイダー（SP）ネットワークの一般的なトポロジです。
When a failure occurs on the link between PE1 and P1, PE1 does not have an LFA for traffic reachable via P1. Similarly, by symmetry, if the link between PE2 and P2 fails, PE2 does not have an LFA for traffic reachable via P2.
PE1とP1の間のリンクで障害が発生すると、PE1には、P1経由で到達可能なトラフィック用のLFAがありません。同様に、対称的に、PE2とP2の間のリンクに障害が発生した場合、PE2には、P2経由で到達可能なトラフィック用のLFAがありません。
Increasing the metric between PE1 and PE2 to allow the LFA would impact the normal traffic performance by potentially increasing the latency.
PE1とPE2の間のメトリックを増やしてLFAを許可すると、待ち時間が長くなる可能性があるため、通常のトラフィックパフォーマンスに影響します。
| 100 |
-P1---------P2-
\ /
1000 \ / 1000
PE1---PE2
5
Figure 3: Example SP Topology
図3：サンプルSPトポロジ
Clearly, full protection can be provided using the techniques described in this document by PE1 choosing P2 as the remote LFA repair target node and PE2 choosing P1 as the remote LFA repair target.
PE1がリモートLFA修復ターゲットノードとしてP2を選択し、PE2がリモートLFA修復ターゲットとしてP1を選択することにより、このドキュメントで説明されている手法を使用して完全な保護を提供できることは明らかです。
When the failure is a node failure rather than a point-to-point link failure, there is a danger that the RLFA repair will loop. This is discussed in detail in [IP-FRR]. In summary, the problem is that two or more of E's neighbors, each with E as the next hop to some destination D, may attempt to repair a packet addressed to destination D via the other neighbor and then E, thus causing a loop to form. A similar problem exists in the case of a shared risk link group failure where the PLR for each failure attempts to repair via the other failure. As will be noted from [IP-FRR], this can rapidly become a complex problem to address.
障害がポイントツーポイントリンク障害ではなくノード障害である場合、RLFA修復がループする危険があります。これについては、[IP-FRR]で詳しく説明されています。要約すると、問題は、Eのいくつかの宛先DへのネクストホップとしてそれぞれがEの2つ以上のネイバーが、他のネイバー、次にEを介して宛先D宛てのパケットを修復しようとするため、ループが形成されることです。 。各障害のPLRが他の障害を介して修復しようとする共有リスクリンクグループ障害の場合にも、同様の問題が存在します。 [IP-FRR]からわかるように、これはすぐに対処する複雑な問題になる可能性があります。
There are a number of ways to minimize the probability of a loop forming when a node failure occurs, and there exists the possibility that two of E's neighbors may form a mutual repair.
ノード障害が発生したときにループが形成される可能性を最小限に抑える方法はいくつかあり、2つのEのネイバーが相互に修復を形成する可能性があります。
1. Detect when a packet has arrived on some interface I that is also the interface used to reach the first hop on the RLFA path to the remote LFA repair target, and drop the packet. This is useful in the case of a ring topology.
1. パケットが、リモートLFA修復ターゲットへのRLFAパス上の最初のホップに到達するために使用されるインターフェイスでもあるインターフェイスIに到着したことを検出し、パケットをドロップします。これは、リングトポロジの場合に役立ちます。
2. Require that the path from the remote LFA repair target to destination D never passes through E (including in the ECMP case), i.e., only use node protecting paths in which the cost from the remote LFA repair target to D is strictly less than the cost from the remote LFA repair target to E plus the cost E to D.
2. リモートLFA修復ターゲットから宛先DへのパスがE（ECMPの場合を含む）を通過しないことを要求します。つまり、リモートLFA修復ターゲットからDまでのコストが厳密にコストより低いノード保護パスのみを使用します。リモートLFA修理ターゲットからEに加えて、コストEからDまで。
3. Require that where the packet may pass through another neighbor of E, that node is down stream (i.e., strictly closer to D than the repairing node). This means that some neighbor of E (X) can repair via some other neighbor of E (Y), but Y cannot repair via X.
3. パケットがEの別のネイバーを通過する可能性がある場合は、そのノードがダウンストリームであること（つまり、修復ノードよりもDに厳密に近いこと）を要求します。これは、E（X）の一部のネイバーがE（Y）の別のネイバーを介して修復できるが、YはXを介して修復できないことを意味します。
Case 1 accepts that loops may form and suppresses them by dropping packets. Dropping packets may be considered less detrimental than looping packets. This approach may also lead to dropping some legitimate packets. Cases 2 and 3 above prevent the formation of a loop but at the expense of a reduced repair coverage and at the cost of additional complexity in the algorithm to compute the repair path. Alternatively, one might choose to assume that the probability of a node failure is sufficiently rare that the issue of looping RLFA repairs can be ignored.
ケース1は、ループが形成される可能性があることを受け入れ、パケットをドロップすることでループを抑制します。パケットをドロップすることは、ループするパケットよりも害が少ないと考えられます。このアプローチでは、一部の正当なパケットがドロップされる可能性もあります。上記のケース2と3は、ループの形成を防止しますが、修復カバレッジが減少し、修復パスを計算するアルゴリズムがさらに複雑になります。あるいは、ノード障害の可能性が非常にまれであり、RLFA修復のループの問題を無視できると想定することもできます。
The probability of a node failure and the consequences of node failure in any particular topology will depend on the node design, the particular topology in use, and the strategy adopted under node failure. It is recommended that a network operator perform an analysis of the consequences and probability of node failure in their network and determine whether the incidence and consequence of occurrence are acceptable.
特定のトポロジにおけるノード障害の可能性とノード障害の結果は、ノードの設計、使用中の特定のトポロジ、およびノード障害のもとで採用される戦略に依存します。ネットワークオペレーターは、ネットワークのノード障害の結果と確率の分析を実行し、発生の発生率と結果が許容できるかどうかを判断することをお勧めします。
This topic is further discussed in [NODE-PROTECTION].
このトピックについては、[NODE-PROTECTION]でさらに説明します。
Where this technique is used in an MPLS network using LDP [RFC5036], and S is a transit node, S will need to swap the top label in the stack for the remote LFA repair target's (PQ's) label to the destination and to then push its own label for the remote LFA repair target.
この手法がLDP [RFC5036]を使用するMPLSネットワークで使用されており、Sがトランジットノードである場合、Sはスタックの最上位ラベルをリモートLFA修復ターゲット（PQ）のラベルと宛先に交換してからプッシュする必要があります。リモートLFA修復ターゲットの独自のラベル。
In the example, S in Figure 2 already has the first hop (A) label for the remote LFA repair target (C) as a result of the ordinary operation of LDP. To get the remote LFA repair target's label (C's label) for the destination (D), S needs to establish a targeted LDP session with C. The label stack for normal operation and RLFA operation is shown below in Figure 4.
この例では、図2のSには、LDPの通常の操作の結果として、リモートLFA修復ターゲット（C）の最初のホップ（A）ラベルがすでにあります。宛先（D）のリモートLFA修復ターゲットのラベル（Cのラベル）を取得するには、SがCとのターゲットLDPセッションを確立する必要があります。通常の操作とRLFA操作のラベルスタックを図4に示します。
+-----------------+ +-----------------+ +-----------------+
| datalink | | datalink | | datalink |
+-----------------+ +-----------------+ +-----------------+
| S's label for D | | E's label for D | | A's label for C |
+-----------------+ +-----------------+ +-----------------+
| Payload | | Payload | | C's label for D |
+-----------------+ +-----------------+ +-----------------+
X Y | Payload |
+-----------------+
Z
X = Normal label stack packet arriving at S Y = Normal label stack packet leaving S Z = RLFA label stack to D via C as the remote LFA repair target
X = Sに到着する通常のラベルスタックパケットY = Sを離れる通常のラベルスタックパケットZ =リモートLFA修復ターゲットとしてCを介してDにRLFAラベルスタック
Figure 4
図4
To establish a targeted LDP session with a candidate remote LFA repair target node, the repairing node (S) needs to know what IP address the remote LFA repair target is willing to use for targeted LDP sessions. Ideally, this is provided by the remote LFA repair target advertising this address in the IGP in use. Which address is used, how this is advertised in the IGP, and whether this is a special IP address or an IP address also used for some other purpose is out of scope for this document and must be specified in an IGP-specific RFC.
候補のリモートLFA修復ターゲットノードとのターゲットLDPセッションを確立するには、修復ノード（S）は、リモートLFA修復ターゲットがターゲットLDPセッションに使用するIPアドレスを知っている必要があります。理想的には、これは、使用中のIGPでこのアドレスをアドバタイズするリモートLFA修復ターゲットによって提供されます。使用されるアドレス、IGPでのアドバタイズ方法、およびこれが特別なIPアドレスであるか、他の目的でも使用されるIPアドレスであるかは、このドキュメントの範囲外であり、IGP固有のRFCで指定する必要があります。
In the absence of a protocol to learn the preferred IP address for targeted LDP, an LSR should attempt a targeted LDP session with the Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119] [OSPF-RI] unless it is configured otherwise.
ターゲットLDPの優先IPアドレスを学習するプロトコルがない場合、LSRは、特に設定されていない限り、ルーターID [RFC2328] [RFC5305] [RFC5340] [RFC6119] [OSPF-RI]を使用してターゲットLDPセッションを試行する必要があります。
No protection is available until the TLDP session has been established and a label for the destination has been learned from the remote LFA repair target. If for any reason the TLDP session cannot be established, an implementation SHOULD advise the operator about the protection setup issue through the network management system.
TLDPセッションが確立され、宛先のラベルがリモートLFA修復ターゲットから学習されるまで、保護は利用できません。何らかの理由でTLDPセッションを確立できない場合、実装はネットワーク管理システムを通じて保護設定の問題についてオペレーターに通知する必要があります（SHOULD）。
This section gives the results of analyzing a number of real world service provider topologies collected between the end of 2012 and early 2013.
このセクションでは、2012年の終わりから2013年の初めにかけて収集された実際のサービスプロバイダートポロジの分析結果を示します。
The figure below characterizes each topology (topo) studied in terms of:
次の図は、調査された各トポロジ（トポロジ）を次のように特徴付けています。
o the number of nodes (# nodes) excluding pseudonodes;
o 疑似ノードを除くノード数（＃ノード）。
o the number of bidirectional links (# links) including parallel links and links to and from pseudonodes;
o 並列リンクと疑似ノードとの間のリンクを含む双方向リンク（＃リンク）の数。
o the number of node pairs that are connected by one or more links (# pairs);
o 1つ以上のリンク（＃ペア）によって接続されているノードペアの数。
o the number of node pairs that are connected by more than one (i.e., parallel) link (# para); and
o 複数の（つまり、並列の）リンク（＃パラ）で接続されているノードペアの数。そして
o the number of links (excluding pseudonode links, which are by definition asymmetric) that have asymmetric metrics (# asym).
o 非対称メトリック（＃asym）を持つリンク（疑似ノードリンクを除く。定義上は非対称）。
+------+---------+---------+---------+--------+--------+
| topo | # nodes | # links | # pairs | # para | # asym |
+------+---------+---------+---------+--------+--------+
| 1 | 315 | 570 | 560 | 10 | 3 |
| 2 | 158 | 373 | 312 | 33 | 0 |
| 3 | 655 | 1768 | 1314 | 275 | 1195 |
| 4 | 1281 | 2326 | 2248 | 70 | 10 |
| 5 | 364 | 811 | 659 | 80 | 86 |
| 6 | 114 | 318 | 197 | 101 | 4 |
| 7 | 55 | 237 | 159 | 67 | 2 |
| 8 | 779 | 1848 | 1441 | 199 | 437 |
| 9 | 263 | 482 | 413 | 41 | 12 |
| 10 | 86 | 375 | 145 | 64 | 22 |
| 11 | 162 | 1083 | 351 | 201 | 49 |
| 12 | 380 | 1174 | 763 | 231 | 0 |
| 13 | 1051 | 2087 | 2037 | 48 | 64 |
| 14 | 92 | 291 | 204 | 64 | 2 |
+------+---------+---------+---------+--------+--------+
The figure below shows the percentage of protected destinations (% prot) and the percentage of guaranteed node protected destinations (% gtd N) for the set of topologies characterized in Section 9.1 achieved using only LFA repairs.
以下の図は、セクション9.1で特徴付けられたトポロジーセットの保護された宛先の割合（％prot）と保証されたノード保護された宛先の割合（％gtd N）を示しています。
These statistics were generated by considering each node and then considering each link to each next hop to each destination. The percentage of such links across the entire network that are protected against link failure was determined. This is the percentage of protected destinations. If a link is protected against the failure of the next hop node, this is considered Guaranteed Node Protecting (GNP) and the percentage of guaranteed node protected destinations is calculated using the same method used for calculating the link protection coverage.
これらの統計は、各ノードを考慮し、次に各宛先への各ネクストホップへの各リンクを考慮して生成されました。リンク障害から保護されているネットワーク全体にわたるそのようなリンクの割合が決定されました。これは、保護された宛先の割合です。リンクがネクストホップノードの障害から保護されている場合、これは保証ノード保護（GNP）と見なされ、リンク保護カバレッジの計算に使用されるのと同じ方法を使用して、保証ノード保護宛先の割合が計算されます。
GNP is identical to node-protecting as defined in [RFC6571] and does not include the additional node protection coverage obtained by the de facto node-protecting condition described in [RFC6571].
GNPは、[RFC6571]で定義されているノード保護と同じであり、[RFC6571]で説明されている事実上のノード保護条件によって取得される追加のノード保護カバレッジは含まれていません。
+------+--------+---------+
| topo | % prot | % gtd N |
+------+--------+---------+
| 1 | 78.5 | 36.9 |
| 2 | 97.3 | 52.4 |
| 3 | 99.3 | 58 |
| 4 | 83.1 | 63.1 |
| 5 | 99 | 59.1 |
| 6 | 86.4 | 21.4 |
| 7 | 93.9 | 35.4 |
| 8 | 95.3 | 48.1 |
| 9 | 82.2 | 49.5 |
| 10 | 98.5 | 14.9 |
| 11 | 99.6 | 24.8 |
| 12 | 99.5 | 62.4 |
| 13 | 92.4 | 51.6 |
| 14 | 99.3 | 48.6 |
+------+--------+---------+
The figure below shows the percentage of protected destinations (% prot) and % guaranteed node protected destinations (% gtd N) for RLFA protection in the topologies studies. In addition, it shows the percentage of destinations using an RLFA repair (% PQ) together with the total number of unidirectional RLFA targeted LDP sessions established (# PQ), and the number of PQ sessions that would be required for complete protection but that could not be established because there was no PQ node, i.e., the number of cases whether neither LFA or RLFA protection was possible (no PQ). It also shows the 50 (p50), 90 (p90), and 100 (p100) percentiles for the number of individual LDP sessions terminating at an individual node (whether used for TX, RX, or both).
以下の図は、トポロジー調査におけるRLFA保護の保護された宛先の割合（％prot）および保証されたノード保護された宛先の割合（％gtd N）を示しています。さらに、RLFA修復を使用する宛先の割合（％PQ）と、確立された単方向RLFAターゲットLDPセッションの総数（＃PQ）、および完全な保護に必要であるが、それが可能なPQセッションの数を示します。 PQノードがなかったため、確立されませんでした。つまり、LFA保護もRLFA保護も可能でなかった（PQがなかった）場合の数。また、個々のノードで終了する個々のLDPセッションの数に対する50（p50）、90（p90）、および100（p100）パーセンタイル（TX、RX、またはその両方に使用されているかどうか）も表示されます。
For example, if there were LDP sessions that required A->B, A->C, C->A, and C->D, these would be counted as 2, 1, 2, and 1 at nodes A, B, C, and D respectively because:
たとえば、A-> B、A-> C、C-> A、およびC-> Dを必要とするLDPセッションがあった場合、これらはノードA、B、2、1、2、および1としてカウントされます。 CとDはそれぞれ次の理由によります。
A has two sessions (to nodes B and C);
Aには2つのセッションがあります（ノードBおよびCへ）。
B has one session (to node A);
Bには（ノードAへの）セッションが1つあります。
C has two sessions (to nodes A and D); and
Cには2つのセッションがあります（ノードAおよびDへ）。そして
D has one session (to node D).
Dには（ノードDへの）セッションが1つあります。
In this study, remote LFA is only used when necessary, i.e., when there is at least one destination that is not reparable by a per destination LFA and a single remote LFA tunnel is used (if available) to repair traffic to all such destinations. The remote LFA repair target points are computed using extended P-space and choosing the PQ node that has the lowest metric cost from the repairing node.
この調査では、リモートLFAは必要な場合にのみ使用されます。つまり、宛先LFAごとに修復できない宛先が少なくとも1つあり、そのような宛先すべてへのトラフィックを修復するために単一のリモートLFAトンネルが使用されます（可能な場合）。リモートLFA修復ターゲットポイントは、拡張Pスペースを使用して計算され、修復ノードからメトリックコストが最も低いPQノードを選択します。
+------+--------+--------+------+------+-------+-----+-----+------+
| topo | % prot |% gtd N | % PQ | # PQ | no PQ | p50 | p90 | p100 |
+------+--------+--------+------+------+-------+-----+-----+------+
| 1 | 99.7 | 53.3 | 21.2 | 295 | 3 | 1 | 5 | 14 |
| 2 | 97.5 | 52.4 | 0.2 | 7 | 40 | 0 | 0 | 2 |
| 3 | 99.999 | 58.4 | 0.7 | 63 | 5 | 0 | 1 | 5 |
| 4 | 99 | 74.8 | 16 | 1424 | 54 | 1 | 3 | 23 |
| 5 | 99.5 | 59.5 | 0.5 | 151 | 7 | 0 | 2 | 7 |
| 6 | 100 | 34.9 | 13.6 | 63 | 0 | 1 | 2 | 6 |
| 7 | 99.999 | 40.6 | 6.1 | 16 | 2 | 0 | 2 | 4 |
| 8 | 99.5 | 50.2 | 4.3 | 350 | 39 | 0 | 2 | 15 |
| 9 | 99.5 | 55 | 17.3 | 428 | 5 | 1 | 2 | 67 |
| 10 | 99.6 | 14.1 | 1 | 49 | 7 | 1 | 2 | 5 |
| 11 | 99.9 | 24.9 | 0.3 | 85 | 1 | 0 | 2 | 8 |
| 12 | 99.999 | 62.8 | 0.5 | 512 | 4 | 0 | 0 | 3 |
| 13 | 97.5 | 54.6 | 5.1 | 1188 | 95 | 0 | 2 | 27 |
| 14 | 100 | 48.6 | 0.7 | 79 | 0 | 0 | 2 | 4 |
+------+--------+--------+------+------+-------+-----+-----+------+
Another study [ISOCORE2010] confirms the significant coverage increase provided by remote LFAs.
別の調査[ISOCORE2010]では、リモートLFAによって提供されるカバレッジの大幅な増加が確認されています。
The table below provides a side-by-side comparison of the LFA and the remote LFA results. This shows a significant improvement in the percentage of protected destinations and normally a modest improvement in the percentage of guaranteed node protected destinations.
以下の表は、LFAとリモートLFAの結果を並べて比較したものです。これは、保護された宛先の割合の大幅な改善と、通常、保証されたノード保護された宛先の割合のわずかな改善を示しています。
+------+--------+--------+---------+---------+
| topo | LFA | RLFA | LFA | RLFA |
| | % prot | %prot | % gtd N | % gtd N |
+------+--------+--------+---------+---------+
| 1 | 78.5 | 99.7 | 36.9 | 53.3 |
| 2 | 97.3 | 97.5 | 52.4 | 52.4 |
| 3 | 99.3 | 99.999 | 58 | 58.4 |
| 4 | 83.1 | 99 | 63.1 | 74.8 |
| 5 | 99 | 99.5 | 59.1 | 59.5 |
| 6 | 86.4 |100 | 21.4 | 34.9 |
| 7 | 93.9 | 99.999 | 35.4 | 40.6 |
| 8 | 95.3 | 99.5 | 48.1 | 50.2 |
| 9 | 82.2 | 99.5 | 49.5 | 55 |
| 10 | 98.5 | 99.6 | 14.9 | 14.1 |
| 11 | 99.6 | 99.9 | 24.8 | 24.9 |
| 12 | 99.5 | 99.999 | 62.4 | 62.8 |
| 13 | 92.4 | 97.5 | 51.6 | 54.6 |
| 14 | 99.3 |100 | 48.6 | 48.6 |
+------+--------+--------+---------+---------+
As shown in the table, remote LFA provides close to 100% prefix protection against link failure in 11 of the 14 topologies studied and provides a significant improvement in two of the remaining three cases. Note that in an MPLS network, the tunnels to the PQ nodes are always present as a property of an LDP-based deployment.
表に示すように、リモートLFAは、調査した14のトポロジーのうち11でリンク障害に対してほぼ100％のプレフィックス保護を提供し、残りの3つのケースのうち2つで大幅な改善を提供します。 MPLSネットワークでは、PQノードへのトンネルは常にLDPベースの展開のプロパティとして存在することに注意してください。
In the small number of cases where there is no intersection between the (extended) P-space and the Q-space, a number of solutions to providing a suitable path between such disjoint regions in the network have been discussed in the working group. For example, an explicitly routed LSP between P and Q might be set up using RSVP-TE or using Segment Routing [SEGMENT-ROUTING]. Such extended repair methods are outside the scope of this document.
（拡張）P空間とQ空間の間に交差がない少数のケースでは、ネットワーク内のこのようなばらばらの領域間に適切なパスを提供するための多くの解決策がワーキンググループで議論されています。たとえば、PとQの間で明示的にルーティングされるLSPは、RSVP-TEまたはセグメントルーティング[SEGMENT-ROUTING]を使用してセットアップされる場合があります。このような拡張修復方法は、このドキュメントの範囲外です。
The management of LFA and remote LFA is the subject of ongoing work within the IETF [LFA-MANAGE], to which the reader is referred. Management considerations may lead to a preference for the use of a remote LFA over an available LFA. This preference is a matter for the network operator and not a matter of protocol correctness.
LFAおよびリモートLFAの管理は、読者が参照するIETF [LFA-MANAGE]内で進行中の作業の主題です。管理上の考慮事項により、利用可能なLFAよりもリモートLFAの使用が優先される場合があります。この設定は、ネットワークオペレーターの問題であり、プロトコルの正確さの問題ではありません。
When the network reconverges, 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, such as one of those described in [RFC5715], [RFC6976], or [ULOOP-DELAY], should be implemented.
ネットワークが再収束すると、さまざまなルーターの転送テーブルの一時的な不整合が原因でマイクロループ[RFC5715]が形成される可能性があります。展開でマイクロループが重要な問題であると判断された場合、[RFC5715]、[RFC6976]、または[ULOOP-DELAY]で説明されているような、ループのない適切な収束方法を実装する必要があります。 。
The basic concepts behind remote LFA were invented in 2002 and were later included in [IP-FRR], submitted in 2004.
リモートLFAの背後にある基本的な概念は2002年に発明され、後に2004年に提出された[IP-FRR]に含まれました。
[IP-FRR] targeted a 100% protection coverage and hence included additional mechanisms on top of the remote LFA concept. The addition of these mechanisms made the proposal very complex and computationally intensive, and it was therefore not pursued as a working group item.
[IP-FRR]は100％の保護範囲を対象としているため、リモートLFAコンセプトに加えて追加のメカニズムが含まれていました。これらのメカニズムの追加により、この提案は非常に複雑で計算集約的なものになり、したがって、ワーキンググループの項目として追求されませんでした。
As explained in [RFC6571], the purpose of the LFA FRR technology is not to provide coverage at any cost. A solution for this already exists with MPLS-TE FRR. MPLS-TE FRR is a mature technology that is able to provide protection in any topology thanks to the explicit routing capability of MPLS-TE.
[RFC6571]で説明されているように、LFA FRRテクノロジーの目的は、いかなる場合でもカバレッジを提供することではありません。これに対する解決策は、MPLS-TE FRRですでに存在しています。 MPLS-TE FRRは成熟したテクノロジーであり、MPLS-TEの明示的なルーティング機能により、あらゆるトポロジで保護を提供できます。
The purpose of LFA FRR technology is to provide for a simple FRR solution when such a solution is possible. The first step along this simplicity approach was "local" LFA [RFC5286]. This specification of "remote LFA" is a natural second step.
LFA FRRテクノロジーの目的は、そのようなソリューションが可能な場合に、単純なFRRソリューションを提供することです。このシンプルなアプローチの最初のステップは、「ローカル」LFA [RFC5286]でした。この「リモートLFA」の仕様は、当然の2番目のステップです。
The security considerations of [RFC5286] also apply.
[RFC5286]のセキュリティに関する考慮事項も適用されます。
Targeted LDP sessions and MPLS tunnels are normal features of an MPLS network, and their use in this application raises no additional security concerns.
ターゲットLDPセッションとMPLSトンネルはMPLSネットワークの通常の機能であり、このアプリケーションでのそれらの使用は、追加のセキュリティの問題を引き起こしません。
IP repair tunnel endpoints (where used) SHOULD be assigned from a set of addresses that are not reachable from outside the routing domain; this would prevent their use as an attack vector.
IP修復トンネルエンドポイント（使用する場合）は、ルーティングドメインの外部から到達できないアドレスのセットから割り当てる必要があります（SHOULD）。これにより、攻撃ベクトルとしての使用を防ぐことができます。
Other than OAM traffic used to verify the correct operation of a repair tunnel, only traffic that is being protected as a result of a link failure is placed in a repair tunnel. The repair tunnel MUST NOT be advertised by the routing protocol as a link that may be used to carry normal user traffic or routing protocol traffic.
修復トンネルの正しい動作を確認するために使用されるOAMトラフィック以外は、リンク障害の結果として保護されているトラフィックのみが修復トンネルに配置されます。修復トンネルは、通常のユーザートラフィックまたはルーティングプロトコルトラフィックの伝送に使用できるリンクとして、ルーティングプロトコルによってアドバタイズされてはなりません（MUST NOT）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、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, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286]アトラス、A。、エド。およびA. Zinin編、「IP Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、2008年9月、<http://www.rfc-editor.org/info/rfc5286>。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010, <http://www.rfc-editor.org/info/rfc5714>.
[RFC5714] Shand、M。およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、2010年1月、<http://www.rfc-editor.org/info/rfc5714>。
[IP-FRR] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", Work in Progress, draft-bryant-ipfrr-tunnels-03, November 2007.
[IP-FRR]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、およびM.シャンド、「トンネルを使用したIP高速リルート」、作業中、draft-bryant-ipfrr-tunnels-03、2007年11月。
[ISOCORE2010] So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) Case Studies in Verizon's LDP Network", 13th Annual MPLS Conference, 2010.
[ISOCORE2010]それでは、N.、Lin、T。、およびC. Chen、「LFA（Loop Free Alternates）Case Studies in Verizon's LDP Network」、第13回MPLS会議、2010年。
[LFA-MANAGE] Litkowski, S., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., and P. Sarkar, "Operational management of Loop Free Alternates", Work in Progress, draft-ietf-rtgwg-lfa-manageability-08, March 2015.
[LFA-MANAGE] Litkowski、S.、Decraene、B.、Filsfils、C.、Raza、K.、Horneffer、M。、およびP. Sarkar、「Loop Free Alternatesの運用管理」、作業中、ドラフト- ietf-rtgwg-lfa-manageability-08、2015年3月。
[NODE-PROTECTION] Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node Protection and Manageability", Work in Progress, draft-ietf-rtgwg-rlfa-node-protection-01, December 2014.
[NODE-PROTECTION] Sarkar、P.、Gredler、H.、Hegde、S.、Bowers、C.、Litkowski、S。、およびH. Raghuveer、「Remote-LFA Node Protection and Manageability」、Work in Progress、draft -ietf-rtgwg-rlfa-node-protection-01、2014年12月。
[OSPF-RI] Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP Addresses in OSPF RI LSA", Work in Progress, draft-ietf-ospf-routable-ip-address-02, April 2015.
[OSPF-RI] Xu、X.、Chunduri、U。、およびM. Bhatia、「OSPF RI LSAでのルーティング可能なIPアドレスの持ち運び」、作業中、draft-ietf-ospf-routable-ip-address-02、4月2015。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月、<http://www.rfc-editor.org/info/rfc1195>。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994, <http://www.rfc-editor.org/info/rfc1701>.
[RFC1701] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 1701、1994年10月、<http://www.rfc-editor.org / info / rfc1701>。
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995, <http://www.rfc-editor.org/info/rfc1853>.
[RFC1853] Simpson、W。、「IP in IP Tunneling」、RFC 1853、1995年10月、<http://www.rfc-editor.org/info/rfc1853>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>.
[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月、<http://www.rfc-editor.org/info/rfc3032>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007、<http://www.rfc-editor.org / info / rfc5036>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月、<http://www.rfc-editor.org/info/ rfc5340>。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010, <http://www.rfc-editor.org/info/rfc5715>.
[RFC5715] Shand、M。およびS. Bryant、「A Framework for Loop-Free Convergence」、RFC 5715、2010年1月、<http://www.rfc-editor.org/info/rfc5715>。
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6119]ハリソンJ.、バーガーJ.、およびM.バートレット、「IS-ISでのIPv6トラフィックエンジニアリング」、RFC 6119、2011年2月、<http://www.rfc-editor.org/info/rfc6119 >。
[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, June 2012, <http://www.rfc-editor.org/info/rfc6571>.
[RFC6571] Filsfils、C。、編、Francois、P。、編、Shand、M.、Decraene、B.、Uttaro、J.、Leymann、N。、およびM. Horneffer、「Loop-Free Alternate（ LFA）Applicability in Service Provider（SP）Networks」、RFC 6571、June 2012、<http://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, July 2013, <http://www.rfc-editor.org/info/rfc6976>.
[RFC6976] Shand、M.、Bryant、S.、Previdi、S.、Filsfils、C.、Francois、P。、およびO. Bonaventure、「Ordered Forwarding Information Base（oFIB）アプローチを使用したループフリーの収束のフレームワーク"、RFC 6976、2013年7月、<http://www.rfc-editor.org/info/rfc6976>。
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, September 2013, <http://www.rfc-editor.org/info/rfc6987>.
[RFC6987] Retana、A.、Nguyen、L.、Zinin、A.、White、R。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 6987、2013年9月、<http：//www.rfc- editor.org/info/rfc6987>。
[SEGMENT-ROUTING] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-01, February 2015.
[セグメントルーティング] Filsfils、C.、Previdi、S.、Bashandy、A.、Decraene、B.、Litkowski、S.、Horneffer、M.、Shakir、R.、Tantsura、J。、およびE. Crabbe、 「Segment Routing Architecture」、Work in Progress、draft-ietf-spring-segment-routing-01、2015年2月。
[ULOOP-DELAY] Litkowski, S., Decraene, B., Filsfils, C., and P. Francois, "Microloop prevention by introducing a local convergence delay", Work in Progress, draft-litkowski-rtgwg-uloop-delay-03, February 2014.
[ULOOP-DELAY] Litkowski、S.、Decraene、B.、Filsfils、C。、およびP. Francois、「ローカル収束遅延の導入によるマイクロループ防止」、Work in Progress、draft-litkowski-rtgwg-uloop-delay- 2014年2月3日。
Acknowledgements
謝辞
The authors wish to thank Levente Csikor and Chris Bowers for their contribution to the cost-based algorithm text. The authors thank Alia Atlas, Ross Callon, Stephane Litkowski, Bharath R, Pushpasis Sarkar, and Adrian Farrel for their review of this document.
著者は、コストベースのアルゴリズムテキストへの貢献に対して、Levente CsikorとChris Bowersに感謝します。この文書をレビューしてくれたAlia Atlas、Ross Callon、Stephane Litkowski、Bharath R、Pushpasis Sarkar、Adrian Farrelに感謝します。
Authors' Addresses
著者のアドレス
Stewart Bryant Cisco Systems 9-11 New Square, Bedfont Lakes, Feltham, Middlesex TW14 8HA United Kingdom
Stewart Bryant Cisco Systems 9-11 New Square、Bedfont Lakes、Feltham、Middlesex TW14 8HAイギリス
EMail: stbryant@cisco.com
Clarence Filsfils Cisco Systems De Kleetlaan 6a 1831 Diegem Belgium
Clarence Filsfils Cisco Systems De Kleetlaan 6a 1831 Diegem Belgium
EMail: cfilsfil@cisco.com
Stefano Previdi Cisco Systems
Stefano Previdi Cisco Systems
EMail: sprevidi@cisco.com
Mike Shand Independent Contributor
Mike Shandの独立した貢献者
EMail: imc.shand@gmail.com
Ning So Vinci Systems
にんｇ そ ゔぃんし Ｓｙｓてｍｓ
EMail: ningso@vinci-systems.com