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
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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快速重路由（IPFRR）的框架，并总结了各种建议的IPFRR解决方案。[RFC5286]中描述了一种使用无环替换（LFA）的基本机制，该机制在许多拓扑[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方法，通过隧道将需要IPFRR的数据包传输到既可以从PLR到达又可以到达目的地的节点，从而覆盖了许多此类情况。
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相对于链路S-E的P空间是S在不使用受保护链路S-E的情况下可以到达的路由器集。
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节点：节点S相对于受保护链路S-E的PQ节点是S相对于该受保护链路S-E的P空间（或扩展P空间）和E相对于该受保护链路S-E的Q空间的成员。从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）：使用PQ节点而不是修复节点的邻居作为LFA修复中的下一跳[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).
在本文档中，符号X-Y用于表示直接连接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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The problem of LFA IPFRR reachability in some networks is illustrated by the network fragment shown in Figure 1 below.
图1所示的网络片段说明了某些网络中LFA IPFRR的可达性问题。
S---E
/ \
A D
\ /
B---C
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相对于S-E的扩展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不在E相对于链路S-E的Q空间中。S的扩展P空间和E的Q空间中的单个节点都是C；因此，选择节点C作为修复隧道的端点。因此，如图2所示，如果在S和C之间设置隧道，则现在是S的直接邻居的C将成为D和E的LFA。第2节提供了（扩展）P空间和Q空间的定义，第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
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提供的保护的通用机制。第9节对典型服务提供商核心网络中使用远程LFA实现的保护进行了研究，第9.4节对LFA和远程LFA进行了并列比较。
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网络中，学习修复隧道端点处的标签绑定所需的目标LDP协议（第8节）是一种被广泛理解和部署的技术。
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.
本文件考虑了维修路径局限于单个区域或二级路由域的情况。在所有其他情况下，所选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一样，当路由器检测到相邻链路故障时，它使用一个或多个修复路径来代替故障链路。修复路径是预先计算的，以预测以后的故障，因此在检测到故障时可以立即激活修复路径。
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
考虑在LFRA FRR中的任意受保护链路S E，如果从S的邻居N到目的地的路径不导致分组在链路S E上回退（即，N是无环路备用），那么S可以将分组发送到N，并且使用预故障转发信息将分组发送到目的地。如果没有这样的LFA邻居，那么S可以创建一个虚拟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的直接邻居的点，数据包将从该点传送到目的地，而不返回到S。在本文件中，此类隧道称为修复隧道。该通道的末端（修复通道端点）是一个“PQ节点”，修复机制是一个“远程LFA”。此隧道不得穿过链路S-E。
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.
请注意，修复隧道终止于S和E之间的某个中间路由器，而不是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隧道机制可用于满足本设计的要求，例如IP-in-IP[RFC1853]和通用路由封装（GRE）[RFC1701]。
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获得正确的内部标签，有必要建立到隧道端点的目标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.
用于提供修复路径的特定隧道机制（以及任何必要的增强）的选择超出了本文档的范围。MPLS/LDP环境中的部署在数据平面中相对简单，因为从MPLS到修复隧道端点（所选PQ节点）的LDP标签交换路径（LSP）随时可用，因此不需要任何新的协议扩展或设计更改。此LSP自动建立为LDP行为的基本属性。封装和去封装的性能是有效的，因为封装仅仅是一个标签的推送（类似于传统的MPLS-TE FRR），并且去封装通常被配置为在修复隧道端点之前的倒数第二跳发生。在控制平面中，需要在修复节点和修复隧道端点之间建立目标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进行保护，则S-E不需要使用修复隧道进行保护，因为通过E正常到达的所有目的地也必须可以通过LFA进行保护；这种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到达，而不经过S-E。此外，修复隧道端点需要是一个节点，数据包通常从该节点流向其目的地，而不会被吸引回故障链路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所示的环形拓扑的链路B-C的成本为四，而其余链路的成本为一，则不可能建立从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.
为了计算链路S-E的修复路径，有必要确定在不穿过链路S-E的情况下可从S到达的路由器集，并将其与在不穿过链路S-E的情况下可通过正常转发到达节点E的路由器集相匹配。
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到S的路由器集的方法，该方法不需要遍历S-E。就链路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 隧道端点到PLR的距离通过注意到S能够使用其邻居关于链路S-E的故障的P空间来增加，因为S可以确定它将使用哪个邻居作为修复的下一跳。就链路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 最后，有两种计算路由器集的方法，通过正常转发可以到达节点E，而无需穿过链路S-E。这称为E相对于链路S-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.
第5.2.2节描述了从扩展P空间和Q空间中的节点集合中选择与S-E相关的首选节点。
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.
第5.3节提供了一个合适的基于成本的算法，用于计算扩展P空间和Q空间关于S-E的公共节点集。
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-E的S的P空间。该P空间可以通过计算以S为根的最短路径树（SPT）并切除通过链路S-E到达的子树来获得（包括作为包含链路S-E的ECMP成员的路由器）。排除可通过包含S-E的ECMP访问的路由器可防止转发子系统尝试通过故障链路S-E执行修复。因此，例如，如果最短路径优先（SPF）计算将用于从S到达该节点的下一个跃点存储在每个节点上，然后如果节点的下一个跃点都不是链路S-E，则可以将该节点添加到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自身为根的路由器的P空间。然而，由于路由器S仅在检测到链路S-E的故障时使用修复路径，因此修复路径的初始跳不需要服从于路由器S的正常转发决策过程。因此，引入了扩展P-空间的概念。路由器的扩展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，则它通过任何路径继续到P的成本较低，除了将数据包带回S然后通过S->E链路的路径。
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，关于链路S-E的扩展P空间节点集包括节点A、B和C。因为节点C也在E关于链路S-E的Q空间中，现在，扩展P空间和Q空间都有一个节点，可以用作修复隧道端点来保护链路S-E。
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）获得，其中可能通过受保护链路S-E的子树被切除（即，将通过S-e发送数据包的节点加上ECMP设置为e且ECMP集的一个或多个成员穿过受保护链路S-e的节点）。rSPT使用指向根的成本而不是来自根的成本，并从网络中的其他节点生成指向根的最佳路径。在图1中，E相对于S-E的Q空间仅包括节点C和D。以成本表示，路由器集{Q}是指最短路径成本Q<-E严格小于最短路径成本Q<-S<-E的那些。在图1中，E的Q空间相对于S-E与S的P空间相对于S-E的交点定义了一组可行的修复隧道端点，称为“PQ节点”.如图1所示，没有公共节点，因此没有可行的修复隧道端点。但是，当考虑S处相对于S-E的扩展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计算，而当前认为该目的地不具有可伸缩性。因此，E相对于链路S-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.
上述机制将识别可用于保护特定链路的所有可能的修复隧道端点。在连接良好的网络中，每个受保护链路可能有多个可能的释放点。所有这些都将正确地传递数据包，因此可以说，选择哪一个并不重要。然而，基于路径成本或一些其他选择标准，一个修复隧道端点可能优于其他端点。
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.选择最近的一个最大化的机会，使流量在从隧道释放后达到负载平衡。为了行为上的一致性，建议将成本最低的路由器集{PQ}的成员S->P作为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].
路由器使用的修复路径选择策略是否支持LFA修复而不是RLFA修复，这是一个局部问题。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算法计算的两个可达图的交集计算远程LFA修复目标（PQ）。本节描述了使用基于成本的算法计算特定故障链路的远程LFA修复目标的方法。本节中提供的伪代码避免了不必要的SPF计算；为了可读性，它不会尝试优化代码。该算法涵盖通过广播或NBMA链路（如LAN）到达修复第一跳的情况。它还包括P或Q节点通过这种链路连接的情况。它不包括故障接口为广播或NBMA链路的情况。为了解决这种情况，有必要计算可通过LAN到达的修复路由器的每个邻居的Q空间，即，将伪节点[RFC1195]视为节点故障；这是因为伪节点的邻居的Q空间可能是不相交的，并且需要使用邻居特定的PQ节点。有关使用RLFA进行节点修复的更多信息，请参阅[节点保护]。
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是伪节点，则伪节点为真。
//////////////////////////////////////////////////////////////////
//
// Main Function
//////////////////////////////////////////////////////////////////
//
// 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:
//////////////////////////////////////////////////////////////////
//
// 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)
计算并存储前向SPF（自身）
// 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.
// 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()
计算\u邻居\u SPFs（）
// Compute the set of nodes {P} reachable other than via the // failed link.
//计算可通过//失败链接以外的方式访问的节点集{P}。
Compute_Extended_P_Space(fail_intf)
计算扩展空间（fail\u 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)
计算Q空间（失败intf）
// Compute the set of candidate RLFA tunnel endpoints.
//计算候选RLFA隧道端点集。
Intersect_Extended_P_and_Q_Space()
相交_扩展_P_和_Q_空间（）
// 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()
如果（保证\u无\u循环\u在\u上比\u保护\u故障更差）应用\u下游\u约束（）
//
// End of Main Function
//
//////////////////////////////////////////////////////////////////
//
// End of Main Function
//
//////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////
//
// Procedures
//
//////////////////////////////////////////////////////////////////
//
// Procedures
//
/////////////////////////////////////////////////////////////////
//
// This computes the SPF from root and stores the optimum
// distance from root to each node y.
/////////////////////////////////////////////////////////////////
//
// 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)
计算和存储转发SPF（根）计算转发SPF（根）网络存储D_opt（根，y）中每个节点y的计算转发SPF（根）
/////////////////////////////////////////////////////////////////
//
// 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.
//
/////////////////////////////////////////////////////////////////
//
// 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)
在自计算和存储转发SPF（intf.remote\u节点）中计算每个接口intf的邻居
/////////////////////////////////////////////////////////////////
//
// 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.
/////////////////////////////////////////////////////////////////
//
// 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)
计算和存储反向SPF（根）计算反向SPF（根）网络存储D_opt（y，根）中每个节点y的计算反向SPF（根）
/////////////////////////////////////////////////////////////////
//
// Calculate Extended P-space
//
// Note that the "strictly less than" operator is needed to
// avoid ECMP issues.
/////////////////////////////////////////////////////////////////
//
// 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_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 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_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)
//计算从网络中的每个节点到自计算和存储SPF（自）的成本
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
如果（D_opt（y，fail_intf.remote_node）<D_opt（y，self）+D_opt（self，fail_intf.remote_node））y.in_Q_空间=真，否则y.in_Q_空间=假
/////////////////////////////////////////////////////////////////
//
// Compute Set of Nodes in Both Extended P-space and in Q-space
/////////////////////////////////////////////////////////////////
//
// 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
如果（y.in\u Extended\u P\u Space&&y.in\u Q\u Space&&y.pseudonode==False）y.valid\u tunnel\u endpoint=true else y.valid\u tunnel\u endpoint=False，则为网络中每个节点y相交
/////////////////////////////////////////////////////////////////
//
// 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.
/////////////////////////////////////////////////////////////////
//
// 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
为网络中的每个节点y应用下游约束（）如果（y.valid\u tunnel\u endpoint）计算并存储转发SPF（y）如果（D\u opt（y，dest）<D\u opt（self，dest））y.valid\u tunnel\u endpoint=true else y.valid\u tunnel\u 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执行的以PLR邻居为根的前向SPF也需要考虑这一点。从PLR的邻居到修复隧道端点的修复隧道路径通常会避免IGP过载/成本计算规则排除的节点和链路。但是，有两种情况下，此行为可能导致修复路径穿过应排除的链路或路由器：
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. 一种情况是，修复隧道路径（从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。
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.
图3显示了一个通常部署的拓扑的示例，该拓扑不完全受LFA的保护。提供商边缘（PE）1和PE2连接在同一站点中。P1和P2可能在地理上分离（站点间）。为了保证从/到所有其他远程PE的最低延迟路径，通常最短路径遵循站点位置的地理距离。因此，为了确保这一点，在PE1和PE2之间分配较低的IGP度量（5）。在P-PE链路上设置一个高指标（1000），以防止PEs用于过境交通。为了降低成本，PEs不是单独的双宿。
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
| 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选择P2作为远程LFA修复目标节点，PE2选择P1作为远程LFA修复目标节点，可以使用本文档中描述的技术提供完全保护。
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的两个或多个邻居（每个邻居将E作为到某个目的地D的下一跳）可能试图修复经由另一个邻居然后是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.
当节点发生故障时，有许多方法可以最小化环路形成的概率，并且存在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. 检测数据包何时到达某个接口I，该接口也是用于到达远程LFA修复目标RLFA路径上的第一跳的接口，并丢弃该数据包。这在环形拓扑的情况下很有用。
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].
此主题将在[节点保护]中进一步讨论。
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.
在该示例中，由于LDP的正常操作，图2中的S已经具有远程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
+-----------------+ +-----------------+ +-----------------+
| 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=RLFA标签堆栈通过C发送到D作为远程LFA修复目标
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会话，修复节点需要知道远程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会话，实施应通过网络管理系统向操作员建议保护设置问题。
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 由一个或多个链路连接的节点对数（#对）；
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 |
+------+---------+---------+---------+--------+--------+
+------+---------+---------+---------+--------+--------+
| 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.
下图显示了仅使用LFA修复实现的第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 |
+------+--------+---------+
+------+--------+---------+
| 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
下图显示了拓扑研究中RLFA保护的受保护目标（%prot）和受保证节点保护目标（%gtd N）的百分比。此外，它还显示了使用RLFA修复（%PQ）的目的地的百分比，以及建立的单向RLFA目标LDP会话的总数（#PQ），以及需要修复的PQ会话数
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).
需要完全保护，但无法确定，因为没有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、C和D分别计为2、1、2和1，因为：
A has two sessions (to nodes B and C);
A具有两个会话（到节点B和C）；
B has one session (to node A);
B有一个会话（到节点A）；
C has two sessions (to nodes A and D); and
C有两个会话（到节点A和D）；和
D has one session (to node D).
D有一个会话（到节点D）。
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至少有一个目的地不可修复，且使用单个远程LFA隧道（如果可用）修复所有此类目的地的流量时。使用扩展P空间计算远程LFA修复目标点，并从修复节点中选择具有最低度量代价的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 |
+------+--------+--------+------+------+-------+-----+-----+------+
+------+--------+--------+------+------+-------+-----+-----+------+
| 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 |
+------+--------+--------+---------+---------+
+------+--------+--------+---------+---------+
| 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.
如表所示，在所研究的14种拓扑中的11种拓扑中，远程LFA提供了接近100%的前缀保护以防止链路故障，并在其余三种情况中的两种中提供了显著的改进。注意，在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]中正在进行的工作的主题，读者可参考该IETF。管理考虑可能导致优先使用远程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”的规范是自然的第二步。
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修复隧道端点（如果使用）应该从路由域外部无法访问的一组地址分配；这将阻止它们作为攻击向量使用。
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通信量外，只有由于链路故障而受到保护的通信量才放置在修复隧道中。路由协议不得将修复隧道作为可用于承载正常用户流量或路由协议流量的链路进行公告。
[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]Atlas，A.，Ed.和A.Zinin，Ed.，“IP快速重路由的基本规范：无环路替换”，RFC 52862008年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快速重路由框架”，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]Bryant，S.，Filsfils，C.，Previdi，S.，和M.Shand，“使用隧道的IP快速重路由”，正在进行的工作，草稿-Bryant-ipfrr-tunnels-032007年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]So，N.，Lin，T.，和C.Chen，“Verizon的LDP网络中的LFA（无环替代）案例研究”，第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.，DeClaene，B.，Filsfils，C.，Raza，K.，Horneffer，M.，和P.Sarkar，“无回路备用电源的运行管理”，在建工程，草案-ietf-rtgwg-LFA-MANAGABILITY-082015年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，“远程LFA节点保护和可管理性”，正在进行中，草案-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地址”，正在进行的工作，草稿-ietf-OSPF-Routable-IP-address-022015年4月。
[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.“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC1195，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.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年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]辛普森，W.，“IP隧道中的IP”，RFC1853，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 23281998年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]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“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.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月<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扩展”，RFC 53052008年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，“IPv6的OSPF”，RFC 53402008年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，“无环收敛框架”，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]Harrison，J.，Berger，J.，和M.Bartlett，“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]费斯菲尔斯，C.，Ed.，弗朗索瓦，P.，Ed.，尚德，M.，德雷恩，B.，乌塔罗，J.，莱曼，N.，和M.霍内弗，“服务提供商（SP）网络中的无环路备用（LFA）适用性”，RFC 65712012年6月<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，“使用有序转发信息库（oFIB）方法的无循环收敛框架”，RFC 69762013年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存根路由器广告”，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.
[SEGMENT-ROUTING]Filsfils，C.，Previdi，S.，Bashandy，A.，DeClaene，B.，Litkowski，S.，Horneffer，M.，Shakir，R.，Tantsura，J.，和E.Crabbe，“SEGMENT-ROUTING Architecture”，在建工程，草案-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.，DeClaene，B.，Filsfils，C.，和P.Francois，“通过引入局部收敛延迟防止微环”，正在进行的工作，草稿-Litkowski-rtgwg-ULOOP-DELAY-032014年2月。
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英国米德尔塞克斯郡费尔瑟姆贝德方特湖新广场TW14 8HA
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Clarence Filsfils Cisco Systems De Kleetlaan 6a 1831 Diegem Belgium
Clarence Filsfils Cisco Systems De Kleetlaan 6a 1831 Diegem比利时
EMail: cfilsfil@cisco.com
EMail: cfilsfil@cisco.com
Stefano Previdi Cisco Systems
Stefano Previdi思科系统公司
EMail: sprevidi@cisco.com
EMail: sprevidi@cisco.com
Mike Shand Independent Contributor
迈克·尚德独立撰稿人
EMail: imc.shand@gmail.com
EMail: imc.shand@gmail.com
Ning So Vinci Systems
宁苏·芬奇系统
EMail: ningso@vinci-systems.com
EMail: ningso@vinci-systems.com