Internet Engineering Task Force (IETF) S. Litkowski, Ed.
Request for Comments: 7916 B. Decraene
Category: Standards Track Orange
ISSN: 2070-1721 C. Filsfils
K. Raza
Cisco Systems
M. Horneffer
Deutsche Telekom
P. Sarkar
Individual Contributor
July 2016
Internet Engineering Task Force (IETF) S. Litkowski, Ed.
Request for Comments: 7916 B. Decraene
Category: Standards Track Orange
ISSN: 2070-1721 C. Filsfils
K. Raza
Cisco Systems
M. Horneffer
Deutsche Telekom
P. Sarkar
Individual Contributor
July 2016
Operational Management of Loop-Free Alternates
无回路交流发电机的运行管理
Abstract
摘要
Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.
RFC 5286中定义的无环路交替（LFA）构成了一种IP快速重路由（IP FRR）机制，能够为IP流量（以及扩展为MPLS LDP流量）提供流量保护。根据早期部署经验，本文件提供了关于LFA的操作反馈，强调了一些局限性，并提出了一套改进方案以解决这些局限性。它还提出了所需的管理规范。
This proposal is also applicable to remote-LFA solutions.
本提案也适用于远程LFA解决方案。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7916.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7916.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................4
1.1. Requirements Language ......................................4
2. Definitions .....................................................4
3. Operational Issues with Default LFA Tiebreakers .................5
3.1. Case 1: PE Router Protecting against Failures
within Core Network ........................................5
3.2. Case 2: PE Router Chosen to Protect against Core
Failures while P Router LFA Exists .........................7
3.3. Case 3: Suboptimal P Router Alternate Choice ...............8
3.4. Case 4: No-Transit LFA Computing Node ......................9
4. Need for Coverage Monitoring ....................................9
5. Need for LFA Activation Granularity ............................10
6. Configuration Requirements .....................................11
6.1. LFA Enabling/Disabling Scope ..............................11
6.2. Policy-Based LFA Selection ................................12
6.2.1. Connected versus Remote Alternates .................12
6.2.2. Mandatory Criteria .................................13
6.2.3. Additional Criteria ................................14
6.2.4. Evaluation of Criteria .............................14
6.2.5. Retrieving Alternate Path Attributes ...............18
6.2.6. ECMP LFAs ..........................................23
7. Operational Aspects ............................................24
7.1. No-Transit Condition on LFA Computing Node ................24
7.2. Manual Triggering of FRR ..................................25
7.3. Required Local Information ................................26
7.4. Coverage Monitoring .......................................26
7.5. LFAs and Network Planning .................................27
8. Security Considerations ........................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................30
Contributors ......................................................31
Authors' Addresses ................................................31
1. Introduction ....................................................4
1.1. Requirements Language ......................................4
2. Definitions .....................................................4
3. Operational Issues with Default LFA Tiebreakers .................5
3.1. Case 1: PE Router Protecting against Failures
within Core Network ........................................5
3.2. Case 2: PE Router Chosen to Protect against Core
Failures while P Router LFA Exists .........................7
3.3. Case 3: Suboptimal P Router Alternate Choice ...............8
3.4. Case 4: No-Transit LFA Computing Node ......................9
4. Need for Coverage Monitoring ....................................9
5. Need for LFA Activation Granularity ............................10
6. Configuration Requirements .....................................11
6.1. LFA Enabling/Disabling Scope ..............................11
6.2. Policy-Based LFA Selection ................................12
6.2.1. Connected versus Remote Alternates .................12
6.2.2. Mandatory Criteria .................................13
6.2.3. Additional Criteria ................................14
6.2.4. Evaluation of Criteria .............................14
6.2.5. Retrieving Alternate Path Attributes ...............18
6.2.6. ECMP LFAs ..........................................23
7. Operational Aspects ............................................24
7.1. No-Transit Condition on LFA Computing Node ................24
7.2. Manual Triggering of FRR ..................................25
7.3. Required Local Information ................................26
7.4. Coverage Monitoring .......................................26
7.5. LFAs and Network Planning .................................27
8. Security Considerations ........................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................30
Contributors ......................................................31
Authors' Addresses ................................................31
Following the first deployments of Loop-Free Alternates (LFAs), this document provides feedback to the community about the management of LFAs.
在第一次部署无环替代方案（LFA）之后，本文档向社区提供了有关LFA管理的反馈。
o Section 3 provides real use cases illustrating some limitations and suboptimal behavior.
o 第3节提供了真实的用例，说明了一些限制和次优行为。
o Section 4 provides requirements for LFA simulations.
o 第4节提供了LFA模拟的要求。
o Section 5 proposes requirements for activation granularity and policy-based selection of the alternate.
o 第5节提出了对激活粒度和基于策略的备选方案选择的要求。
o Section 6 expresses requirements for the operational management of LFAs and, in particular, a policy framework to manage alternates.
o 第6节阐述了LFA运营管理的要求，特别是管理备选方案的政策框架。
o Section 7 details some operational considerations of LFAs, such as IS-IS overload bit management and troubleshooting information.
o 第7节详细介绍了LFA的一些操作注意事项，如IS-IS过载位管理和故障排除信息。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
o Per-prefix LFA computation: Evaluation for the best alternate is done for each destination prefix, as opposed to the "per-next-hop" simplification technique proposed in Section 3.8 of [RFC5286].
o 每前缀LFA计算：与[RFC5286]第3.8节中提出的“每下一跳”简化技术相反，对每个目的地前缀进行最佳备选方案的评估。
o PE router: Provider Edge router. These routers connect customers to each other.
o PE路由器：提供商边缘路由器。这些路由器将客户彼此连接起来。
o P router: Provider router. These routers are core routers without customer connections. They provide transit between PE routers, and they form the core network.
o P路由器：提供者路由器。这些路由器是没有客户连接的核心路由器。它们提供PE路由器之间的传输，并形成核心网络。
o Core network: subset of the network composed of P routers and links between them.
o 核心网络：由P个路由器和它们之间的链路组成的网络子集。
o Core link: network link part of the core network, i.e., a link between P routers.
o 核心链路：核心网络的网络链路部分，即P路由器之间的链路。
o Link-protecting LFA: alternate providing protection against link failure.
o 链路保护LFA：针对链路故障提供保护的替代方案。
o Node-protecting LFA: alternate providing protection against node failure.
o 节点保护LFA：针对节点故障提供保护的替代方案。
o Connected alternate: alternate adjacent (at the IGP level) to the Point of Local Repair (PLR) (i.e., an IGP neighbor).
o 连接备用：与本地维修点（PLR）相邻的备用（在IGP级别）（即IGP邻居）。
o Remote alternate: alternate that does not share an IGP adjacency with the PLR.
o 远程备降：与PLR不共享IGP邻接的备降。
[RFC5286] introduces the notion of tiebreakers when selecting the LFA among multiple candidate alternate next hops. When multiple LFAs exist, [RFC5286] has favored the selection of the LFA that provides the best coverage against the failure cases. While this is indeed a goal, it is one among multiple goals, and in some deployments this leads to the selection of a suboptimal LFA. The following sections detail real use cases related to such limitations.
[RFC5286]在多个候选备选下一跳中选择LFA时，引入了分段中断的概念。当存在多个LFA时，[RFC5286]倾向于选择针对故障情况提供最佳覆盖的LFA。虽然这确实是一个目标，但它是多个目标中的一个，在某些部署中，这会导致选择次优LFA。以下部分详细介绍了与这些限制相关的实际用例。
Note that the use case for LFA computation per destination (per-prefix LFA) is assumed throughout this analysis. We also assume in the network figures that all IP prefixes are advertised with zero cost.
注意，在整个分析过程中，假设每个目的地（每个前缀LFA）的LFA计算用例。我们还假设在网络图中，所有IP前缀都以零成本进行广告。
P1 --------- P2 ---------- P3 --------- P4
| 1 100 1 |
| |
| 100 | 100
| |
| 1 100 1 | 1 5k
P5 --------- P6 ---------- P7 --------- P8 --- P9 -- PE1
| | | | | |
5k| |5k 5k| |5k | 5k | 5k
| | | | | |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
P1 --------- P2 ---------- P3 --------- P4
| 1 100 1 |
| |
| 100 | 100
| |
| 1 100 1 | 1 5k
P5 --------- P6 ---------- P7 --------- P8 --- P9 -- PE1
| | | | | |
5k| |5k 5k| |5k | 5k | 5k
| | | | | |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
Px routers are P routers using n * 10 Gbps links. PEs are connected using links with lower bandwidth.
Px路由器是使用n*10 Gbps链路的P路由器。PEs使用较低带宽的链路连接。
Figure 1
图1
In Figure 1, let us consider the traffic flowing from PE1 to PE4. The nominal path is P9-P8-P7-P6-PE4. Let us now consider the failure of link P7-P8. As the P4 primary path to PE4 is P8-P7-P6-PE4, P4 is not an LFA for P8 (because P4 will loop traffic back to P8), and the only available LFA is PE2.
在图1中，让我们考虑从PE1到PE4的流量。标称路径为P9-P8-P7-P6-PE4。现在让我们考虑链接P7 P8的失败。由于到PE4的P4主路径是P8-P7-P6-PE4，因此P4不是P8的LFA（因为P4会将流量循环回P8），并且唯一可用的LFA是PE2。
When the core link P8-P7 fails, P8 switches all traffic destined to PE4/PE5 towards the node PE2. Hence, a PE node and PE links are used to protect against the failure of a core link. Typically, PE links have less capacity than core links, and congestion may occur on PE2 links. Note that although PE2 is not directly affected by the failure, its links become congested, and its traffic will suffer from the congestion.
当核心链路P8-P7发生故障时，P8将目的地为PE4/PE5的所有业务切换到节点PE2。因此，PE节点和PE链路用于防止核心链路出现故障。通常，PE链路的容量小于核心链路，并且可能会在PE2链路上发生拥塞。请注意，虽然PE2不会直接受到故障的影响，但其链路会变得拥挤，其流量也会受到拥塞的影响。
In summary, in the case of P8-P7 link failure, the impact on customer traffic is:
总之，在P8-P7链路故障的情况下，对客户流量的影响为：
o From PE2's point of view:
o 从PE2的角度来看：
* without LFA: no impact.
* 没有LFA：没有影响。
* with LFA: traffic is partially dropped (but possibly prioritized by a QoS mechanism). It must be highlighted that in such a situation, traffic not affected by the failure may be affected by the congestion.
* 使用LFA：部分丢弃通信量（但可能通过QoS机制确定优先级）。必须强调的是，在这种情况下，未受故障影响的交通可能会受到拥堵的影响。
o From P8's point of view:
o 从P8的观点来看：
* without LFA: traffic is totally dropped until convergence occurs.
* 没有LFA：流量完全下降，直到收敛发生。
* with LFA: traffic is partially dropped (but possibly prioritized by a QoS mechanism).
* 使用LFA：部分丢弃通信量（但可能通过QoS机制确定优先级）。
Besides the congestion aspects of using a PE router as an alternate to protect against a core failure, a service provider may consider this to be a bad routing design and would want to prevent it.
除了使用PE路由器作为备用以防止核心故障的拥塞方面之外，服务提供商可能认为这是一个糟糕的路由设计，并且希望阻止它。
3.2. Case 2: PE Router Chosen to Protect against Core Failures while P Router LFA Exists
3.2. 案例2：当P路由器LFA存在时，选择PE路由器来防止核心故障
P1 --------- P2 ------------ P3 ------- P4
| 1 100 | 1 |
| | |
| 100 | 30 | 30
| | |
| 1 50 50 | 10 | 1 5k
P5 --------- P6 --- P10 ---- P7 ------- P8 --- P9 -- PE1
| | | | \ |
5k| |5k 5k| |5k \ 5k | 5k
| | | | \ |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
P1 --------- P2 ------------ P3 ------- P4
| 1 100 | 1 |
| | |
| 100 | 30 | 30
| | |
| 1 50 50 | 10 | 1 5k
P5 --------- P6 --- P10 ---- P7 ------- P8 --- P9 -- PE1
| | | | \ |
5k| |5k 5k| |5k \ 5k | 5k
| | | | \ |
| +-- PE4 --+ | +---- PE2 ----+
| | |
+---- PE5 ----+ | 5k
|
PE3
Px routers are P routers meshed with n * 10 Gbps links. PEs are meshed using links with lower bandwidth.
Px路由器是与n*10 Gbps链路啮合的P路由器。PEs使用较低带宽的链路进行网格化。
Figure 2
图2
In Figure 2, let us consider the traffic coming from PE1 to PE4. The nominal path is P9-P8-P7-P10-P6-PE4. Let us now consider the failure of the link P7-P8. For P8, P4 is a link-protecting LFA and PE2 is a node-protecting LFA. PE2 is chosen as the best LFA, due to the better type of protection that it provides. Just as in case 1, this may lead to congestion on PE2 links upon LFA activation.
在图2中，让我们考虑从PE1到PE4的流量。标称路径为P9-P8-P7-P10-P6-PE4。现在让我们考虑一下P7 P8链路的故障。对于P8，P4是链路保护LFA，PE2是节点保护LFA。PE2被选为最佳LFA，因为它提供了更好的保护类型。与案例1一样，这可能会在LFA激活时导致PE2链路拥塞。
+--- PE3 ---+
/ \
1000 / \ 1000
/ \
+----- P1 ---------------- P2 ----+
| | 500 | |
| 10 | | | 10
| | | |
R5 | 10 | 10 R7
| | | |
| 10 | | | 10
| | 500 | |
+---- P3 ----------------- P4 ----+
\ /
1000 \ / 1000
\ /
+--- PE1 ---+
+--- PE3 ---+
/ \
1000 / \ 1000
/ \
+----- P1 ---------------- P2 ----+
| | 500 | |
| 10 | | | 10
| | | |
R5 | 10 | 10 R7
| | | |
| 10 | | | 10
| | 500 | |
+---- P3 ----------------- P4 ----+
\ /
1000 \ / 1000
\ /
+--- PE1 ---+
Px routers are P routers. P1-P2 and P3-P4 links are 1 Gbps links. All other inter-Px links are 10 Gbps links.
Px路由器是P路由器。P1-P2和P3-P4链路为1 Gbps链路。所有其他Px间链路均为10 Gbps链路。
Figure 3
图3
In Figure 3, let us consider the failure of link P1-P3. For destination PE3, P3 has two possible alternates:
在图3中，让我们考虑链路P1-P3的故障。对于目的地PE3，P3有两种可能的备选方案：
o P4, which is node-protecting
o P4，这是节点保护
o R5, which is link-protecting
o R5，这是链路保护
P4 is chosen as the best LFA, due to the better type of protection that it provides. However, for bandwidth capacity reasons, it may not be desirable to use P4. A service provider may prefer to use high-bandwidth links as the preferred LFA. In this example, preferring the shortest path over the type of protection may achieve the expected behavior, but in cases where metrics do not reflect the bandwidth, this technique would not work and some other criteria would need to be involved when selecting the best LFA.
P4被选为最佳LFA，因为它提供了更好的保护类型。然而，出于带宽容量的原因，可能不希望使用P4。服务提供商可能更喜欢使用高带宽链路作为首选LFA。在本例中，优先选择最短路径而不是保护类型可能会实现预期行为，但在度量不反映带宽的情况下，此技术将不起作用，并且在选择最佳LFA时需要涉及一些其他标准。
P1 P2
| \ / |
50 | 50 \/ 50 | 50
| /\ |
PE1-+ +-- PE2
\ /
45 \ / 45
-PE3-
(No-transit condition set)
P1 P2
| \ / |
50 | 50 \/ 50 | 50
| /\ |
PE1-+ +-- PE2
\ /
45 \ / 45
-PE3-
(No-transit condition set)
Figure 4
图4
The IS-IS and OSPF protocols define some way to prevent a router from being used for transit.
IS-IS和OSPF协议定义了一些防止路由器被用于传输的方法。
The IS-IS overload bit is defined in [ISO10589], and the OSPF R-bit is defined in [RFC5340]. Also, the OSPF stub router is defined in [RFC6987] as a method to prevent transit on a node by advertising MaxLinkMetric on all non-stub links.
IS-IS过载位在[ISO10589]中定义，OSPF R位在[RFC5340]中定义。此外，OSPF存根路由器在[RFC6987]中定义为一种通过在所有非存根链路上公布MaxLinkMetric来防止在节点上传输的方法。
In Figure 4, PE3 has its no-transit condition set (permanently, for design reasons) and wants to protect traffic using an LFA for destination PE2.
在图4中，PE3设置了无中转条件（出于设计原因，永久性设置），并希望使用目的地PE2的LFA来保护流量。
On PE3, the loop-free condition is not satisfied: 100 !< 45 + 45. PE1 is thus not considered as an LFA. However, thanks to the no-transit condition on PE3, we know that PE1 will not loop the traffic back to PE3. So, PE1 is an LFA to reach PE2.
在PE3上，不满足无回路条件：100！<45 + 45. 因此，PE1不被视为LFA。然而，由于PE3上没有运输条件，我们知道PE1不会将交通循环回PE3。因此，PE1是达到PE2的LFA。
In the case of a no-transit condition set on a node, LFA behavior must be clarified.
如果在节点上设置了无传输条件，则必须澄清LFA行为。
As per [RFC6571], LFA coverage depends strongly on the network topology that is in use. Even if the remote-LFA mechanism [RFC7490] significantly extends the coverage of the basic LFA specification, there are still some cases where protection would not be available. As network topologies are constantly evolving (network extension, additional capacity, latency optimization, etc.), the protection coverage may change. Fast Reroute (FRR) functionality may be critical for some services supported by the network; a service provider must always know what type of protection coverage is currently available on the network. Moreover, predicting protection coverage in the event of network topology changes is mandatory.
根据[RFC6571]，LFA覆盖范围在很大程度上取决于正在使用的网络拓扑。即使远程LFA机制[RFC7490]显著扩展了基本LFA规范的覆盖范围，仍有一些情况下无法提供保护。随着网络拓扑的不断发展（网络扩展、附加容量、延迟优化等），保护范围可能会发生变化。快速重路由（FRR）功能对于网络支持的某些服务可能至关重要；服务提供商必须始终知道网络上当前可用的保护范围类型。此外，在网络拓扑发生变化时预测保护覆盖率是强制性的。
Today, network simulation tools associated with "what if" scenarios are often used by service providers for the overall network design (capacity, path optimization, etc.). Sections 7.3, 7.4, and 7.5 of this document propose the addition of LFA information into such tools and within routers, so that a service provider may be able to:
如今，服务提供商通常使用与“假设”场景相关联的网络模拟工具进行总体网络设计（容量、路径优化等）。本文件第7.3、7.4和7.5节建议将LFA信息添加到此类工具和路由器中，以便服务提供商能够：
o evaluate protection coverage after a topology change.
o 在拓扑更改后评估保护覆盖率。
o adjust the topology change to cover the primary need (e.g., latency optimization, bandwidth increase) as well as LFA protection.
o 调整拓扑更改以满足主要需求（例如，延迟优化、带宽增加）以及LFA保护。
o constantly monitor the LFA coverage in the live network and receive alerts.
o 持续监控实时网络中的LFA覆盖率并接收警报。
Documentation of LFA selection algorithms by implementers (default and tuning options) is important in order to make it possible for third-party modules to model these policy-based LFA selection algorithms.
为了使第三方模块能够对这些基于策略的LFA选择算法进行建模，实现者对LFA选择算法的文档记录（默认和调优选项）非常重要。
As in all FRR mechanisms, an LFA installs backup paths in the Forwarding Information Base (FIB). Depending on the hardware used by a service provider, FIB resources may be critical. Activating LFAs by default on all available components (IGP topologies, interfaces, address families, etc.) may lead to a waste of FIB resources, as generally only a few destinations in a network should be protected (e.g., loopback addresses supporting MPLS services) compared to the number of destinations in the Routing Information Base (RIB).
与所有FRR机制一样，LFA在转发信息库（FIB）中安装备份路径。根据服务提供商使用的硬件，FIB资源可能至关重要。默认情况下，在所有可用组件（IGP拓扑、接口、地址族等）上激活LFA可能会导致FIB资源的浪费，因为与路由信息库（RIB）中的目的地数量相比，通常只应保护网络中的少数目的地（例如，支持MPLS服务的环回地址）。
Moreover, a service provider may implement multiple different FRR mechanisms in its networks for different applications (e.g., Maximally Redundant Trees (MRTs), TE FRR). In this scenario, an implementation MAY allow the computation of alternates for a specific destination even if the destination is already protected by another mechanism. This will provide redundancy and permit the operator to select the best option for FRR, using a policy language.
此外，服务提供商可以在其网络中为不同的应用（例如，最大冗余树（mrt）、TE-FRR）实现多个不同的FRR机制。在这种情况下，实现可能允许计算特定目的地的备选方案，即使该目的地已经受到另一种机制的保护。这将提供冗余，并允许操作员使用策略语言为FRR选择最佳选项。
Section 6 provides some implementation guidelines.
第6节提供了一些实施指南。
Controlling the selection of the best alternate and the granularity of LFA activation is a requirement for service providers. This section defines configuration requirements for LFAs.
控制最佳备选方案的选择和LFA激活的粒度是服务提供商的一项要求。本节定义了LFA的配置要求。
The granularity of LFA activation SHOULD be controlled (as alternate next hops consume memory in the forwarding plane).
应控制LFA激活的粒度（因为备用下一跳消耗转发平面中的内存）。
An implementation of an LFA SHOULD allow its activation, with the following granularities:
LFA的实现应允许其激活，具有以下粒度：
o Per routing context: Virtual Routing and Forwarding (VRF), virtual/logical router, global routing table, etc.
o 每个路由上下文：虚拟路由和转发（VRF）、虚拟/逻辑路由器、全局路由表等。
o Per interface.
o 每个接口。
o Per protocol instance, topology, area.
o 每个协议实例、拓扑、区域。
o Per prefix: Prefix protection SHOULD have a higher priority compared to interface protection. This means that if a specific prefix must be protected due to a configuration request, an LFA MUST be computed and installed for that prefix even if the primary outgoing interface is not configured for protection.
o 每个前缀：与接口保护相比，前缀保护应具有更高的优先级。这意味着，如果由于配置请求而必须保护特定前缀，则必须为该前缀计算并安装LFA，即使主传出接口未配置为保护。
An implementation of an LFA MAY allow its activation, with the following criteria:
LFA的实现可允许其激活，符合以下标准：
o Per address family: IPv4 unicast, IPv6 unicast.
o 每个地址系列：IPv4单播、IPv6单播。
o Per MPLS control plane: For MPLS control planes that inherit routing decisions from the IGP routing protocol, the MPLS data plane may be protected by an LFA. The implementation may allow an operator to control this inheritance of protection from the IP prefix to the MPLS label bound to this prefix. The inheritance of protection will concern IP-to-MPLS, MPLS-to-MPLS, and MPLS-to-IP entries. As an example, LDP and Segment Routing extensions [SEG-RTG-ARCH] for IS-IS and OSPF are control-plane eligible for this inheritance of protection.
o 每MPLS控制平面：对于从IGP路由协议继承路由决定的MPLS控制平面，MPLS数据平面可以由LFA保护。该实现可允许操作员控制从IP前缀到绑定到该前缀的MPLS标签的这种保护继承。保护的继承将涉及IP到MPLS、MPLS到MPLS以及MPLS到IP条目。例如，IS-IS和OSPF的LDP和段路由扩展[SEG-RTG-ARCH]是符合这种保护继承的控制平面。
When multiple alternates exist, the LFA selection algorithm is based on tiebreakers. Current tiebreakers do not provide sufficient control regarding how the best alternate is chosen. This document proposes an enhanced tiebreaker allowing service providers to manage all specific cases:
当存在多个备选方案时，LFA选择算法基于分段断路器。对于如何选择最佳备选方案，当前的联络线断路器无法提供足够的控制。本文件提出了一个增强的分条机制，允许服务提供商管理所有特定案例：
1. An LFA implementation SHOULD support policy-based decisions for determining the best LFA.
1. LFA实施应支持基于政策的决策，以确定最佳LFA。
2. Policy-based decisions SHOULD be based on multiple criteria, with each criterion having a level of preference.
2. 基于政策的决策应该基于多个标准，每个标准都有一个偏好水平。
3. If the defined policy does not allow the determination of a unique best LFA, an implementation SHOULD pick only one based on its own decision. For load-balancing purposes, an implementation SHOULD also support the election of multiple LFAs.
3. 如果定义的策略不允许确定唯一的最佳LFA，则实现应根据自己的决定仅选择一个LFA。出于负载平衡的目的，实现还应支持选择多个LFA。
4. The policy SHOULD be applicable to a protected interface or a specific set of destinations. In the case of applicability to the protected interface, all destinations primarily routed on that interface SHOULD use the policy for that interface.
4. 该策略应适用于受保护的接口或一组特定的目标。在适用于受保护接口的情况下，主要在该接口上路由的所有目的地都应使用该接口的策略。
5. The choice of whether or not to dynamically re-evaluate policy (in the event of a policy change) is left to the implementation. If a dynamic approach is chosen, the implementation SHOULD recompute the best LFAs and reinstall them in the FIB without service disruption. If a non-dynamic approach is chosen, the policy would be taken into account upon the next IGP event. In this case, the implementation SHOULD support a command to manually force the recomputation/reinstallation of LFAs.
5. 是否动态重新评估策略（在策略更改的情况下）的选择权留给实现。如果选择了动态方法，则实现应重新计算最佳LFA，并在FIB中重新安装它们，而不会中断服务。如果选择非动态方法，则在下一个IGP事件时将考虑该策略。在这种情况下，实现应该支持手动强制重新计算/重新安装LFA的命令。
In addition to connected LFAs, tunnels (e.g., IP, LDP, RSVP-TE, Segment Routing) to distant routers may be used to complement LFA coverage (tunnel tail used as virtual neighbor). When a router has multiple alternate candidates for a specific destination, it may have connected alternates and remote alternates (reachable via a tunnel). Connected alternates may not always provide an optimal routing path, and it may be preferable to select a remote alternate over a connected alternate. Some uses of tunnels to extend LFA [RFC5286] coverage are described in [RFC7490] and [TI-LFA]. [RFC7490] and [TI-LFA] present some use cases for LDP tunnels and Segment Routing tunnels, respectively. This document considers any type of tunneling techniques to reach remote alternates (IP, Generic Routing
除了连接的LFA之外，到远程路由器的隧道（例如，IP、LDP、RSVP-TE、段路由）可用于补充LFA覆盖（隧道尾部用作虚拟邻居）。当一个路由器对于一个特定的目的地有多个候选者时，它可能已经连接了候选者和远程候选者（可以通过隧道到达）。连接的备用可能并不总是提供最佳路由路径，最好选择远程备用而不是连接的备用。[RFC7490]和[TI-LFA]中描述了隧道扩大LFA[RFC5286]覆盖范围的一些用途。[RFC7490]和[TI-LFA]分别介绍了LDP隧道和段路由隧道的一些用例。本文件考虑任何类型的隧道技术，以达到远程替代（IP、通用路由
Encapsulation (GRE), LDP, RSVP-TE, the Layer 2 Tunneling Protocol (L2TP), Segment Routing, etc.) and does not restrict the remote alternates to the uses presented in these other documents.
封装（GRE）、LDP、RSVP-TE、第二层隧道协议（L2TP）、段路由等），并且不限制远程替代方案用于这些其他文档中介绍的用途。
In Figure 1, there is no P router alternate for P8 to reach PE4 or PE5, so P8 is using PE2 as an alternate; this may generate congestion when FRR is activated. Instead, we could have a remote alternate for P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8 to P3 (following the shortest path) can be set up, and P8 would be able to use P3 as a remote alternate to protect traffic to PE4 and PE5. In this scenario, traffic will not use a PE link during FRR activation.
在图1中，P8没有P路由器替代品到达PE4或PE5，因此P8使用PE2作为替代品；当FRR激活时，这可能会产生拥塞。取而代之的是，我们可以为P8提供一个远程替代方案，以保护到PE4和PE5的流量。例如，可以设置从P8到P3的隧道（遵循最短路径），P8可以使用P3作为远程备用，以保护到PE4和PE5的交通。在这种情况下，流量在FRR激活期间不会使用PE链路。
When selecting the best alternate, the selection algorithm MUST consider all available alternates (connected or tunnel). For example, with remote LFAs, computation of PQ sets [RFC7490] SHOULD be performed before the selection of the best alternate.
当选择最佳交替时，选择算法必须考虑所有可用的替代物（连接或隧道）。例如，对于远程LFA，应在选择最佳备选方案之前执行PQ集[RFC7490]的计算。
An LFA implementation MUST support the following criteria:
LFA实施必须支持以下标准：
o Non-candidate link: A link marked as "non-candidate" will never be used as an LFA.
o 非候选链接：标记为“非候选”的链接永远不会用作LFA。
o A primary next hop being protected by another primary next hop of the same prefix (ECMP case).
o 一个主下一个跃点受到相同前缀的另一个主下一个跃点的保护（ECMP案例）。
o Type of protection provided by the alternate: link protection or node protection. In the case of preference for node protection, an implementation SHOULD support fallback to link protection if node protection is not available.
o 备用服务器提供的保护类型：链路保护或节点保护。在首选节点保护的情况下，如果节点保护不可用，则实现应支持回退到链路保护。
o Shortest path: lowest IGP metric used to reach the destination.
o 最短路径：用于到达目的地的最低IGP指标。
o Shared Risk Link Groups (SRLGs) (as defined in Section 3 of [RFC5286]; see also Section 6.2.4.1 for more details).
o 共享风险链接组（SRLGs）（如[RFC5286]第3节所定义；有关更多详细信息，请参见第6.2.4.1节）。
An LFA implementation SHOULD support the following criteria:
LFA实施应支持以下标准：
o A downstream alternate: Preference for a downstream path over a non-downstream path SHOULD be configurable.
o 下游备选方案：相对于非下游路径，下游路径的首选方案应该是可配置的。
o Link coloring with "include", "exclude", and preference-based systems (see Section 6.2.4.2).
o 将颜色与“包括”、“排除”和基于偏好的系统联系起来（见第6.2.4.2节）。
o Link bandwidth (see Section 6.2.4.3).
o 链路带宽（见第6.2.4.3节）。
o Alternate preference / node coloring (see Section 6.2.4.4).
o 备选首选项/节点颜色（见第6.2.4.4节）。
Section 3 of [RFC5286] proposes the reuse of GMPLS IGP extensions to encode SRLGs [RFC5307] [RFC4203]. Section 3 of [RFC5286] also describes the algorithm to compute SRLG protection.
[RFC5286]第3节建议重用GMPLS IGP扩展来编码SRLGs[RFC5307][RFC4203]。[RFC5286]第3节还介绍了计算SRLG保护的算法。
When SRLG protection is computed, an implementation SHOULD allow the following:
计算SRLG保护时，实现应允许以下条件：
o Exclusion of alternates in violation of SRLGs.
o 排除违反SRLGs的候补者。
o Maintenance of a preference system between alternates based on SRLG violations. How the preference system is implemented is out of scope for this document, but here are two examples:
o 根据SRLG违规情况在候补者之间维护偏好系统。如何实施优惠制度超出了本文件的范围，但以下是两个示例：
* Preference based on the number of violations. In this case, more violations = less preferred.
* 基于违规数量的首选项。在这种情况下，违规次数越多=首选次数越少。
* Preference based on violation cost. In this case, each SRLG violation has an associated cost. The lower violation costs are preferred.
* 基于违规成本的偏好。在这种情况下，每个SRLG违规都有相关成本。较低的违规成本是首选。
When applying SRLG criteria, the SRLG violation check SHOULD be performed on sources to alternates as well as alternates to destination paths, based on the SRLG set of the primary path. In the case of remote LFAs, PQ-to-destination path attributes would be retrieved from the Shortest Path Tree (SPT) rooted at the PQ.
应用SRLG标准时，应根据主路径的SRLG集，对源到备用路径以及备用到目标路径执行SRLG冲突检查。在远程LFA的情况下，PQ到目的地的路径属性将从植根于PQ的最短路径树（SPT）中检索。
Link coloring is a powerful system to control the choice of alternates. Link colors are markers that will allow the encoding of properties of a particular link. Protecting interfaces are tagged with colors. Protected interfaces are configured to include some colors with a preference level and exclude others.
链接着色是控制备选方案选择的强大系统。链接颜色是允许对特定链接的属性进行编码的标记。保护接口用颜色标记。受保护的接口被配置为包括某些具有首选项级别的颜色，并排除其他颜色。
Link color information SHOULD be signaled in the IGP, and administrative-group IGP extensions [RFC5305] [RFC3630] that are already standardized, implemented, and widely used SHOULD be used for encoding and signaling link colors.
链路颜色信息应在IGP中发出信号，已经标准化、实现和广泛使用的管理组IGP扩展[RFC5305][RFC3630]应用于编码和发送链路颜色信号。
PE2
| +---- P4
| /
PE1 ---- P1 --------- P2
| 10 Gbps
1 Gbps |
|
P3
PE2
| +---- P4
| /
PE1 ---- P1 --------- P2
| 10 Gbps
1 Gbps |
|
P3
Figure 5
图5
In the example in Figure 5, the P1 router is connected to three P routers and two PEs. P1 is configured to protect the P1-P4 link. We assume that, given the topology, all neighbors are candidate LFAs. We would like to enforce a policy in the network where only a core router may protect against the failure of a core link and where high-capacity links are preferred.
在图5中的示例中，P1路由器连接到三个P路由器和两个PE。P1配置为保护P1-P4链路。我们假设，给定拓扑结构，所有邻居都是候选LFA。我们希望在网络中实施一项策略，在该策略中，只有核心路由器可以防止核心链路出现故障，并且首选高容量链路。
In this example, we can use the proposed link coloring by:
在本例中，我们可以通过以下方式使用建议的链接着色：
o Marking the PE links with the color RED.
o 用红色标记PE链接。
o Marking the 10 Gbps core link with the color BLUE.
o 用蓝色标记10 Gbps核心链路。
o Marking the 1 Gbps core link with the color YELLOW.
o 用黄色标记1 Gbps核心链路。
o Configuring the protected interface P1->P4 as follows:
o 按如下方式配置受保护的接口P1->P4：
* Include BLUE, preference 200.
* 包括蓝色，首选200。
* Include YELLOW, preference 100.
* 包括黄色，首选100。
* Exclude RED.
* 排除红色。
Using this, PE links will never be used to protect against P1-P4 link failure, and the 10 Gbps link will be preferred.
使用此功能，PE链路将永远不会用于防止P1-P4链路故障，而10 Gbps链路将是首选。
The main advantage of this solution is that it can easily be duplicated on other interfaces and other nodes without change. A service provider has only to define the color system (associate a color with a level of significance), as it is done already for TE affinities or BGP communities.
此解决方案的主要优点是，它可以轻松地在其他接口和其他节点上复制，而无需更改。服务提供商只需定义颜色系统（将颜色与重要性级别相关联），就像对TE亲缘关系或BGP社区所做的那样。
An implementation of link coloring:
链接着色的实现：
o SHOULD support multiple "include" and "exclude" colors on a single protected interface.
o 应在单个受保护的界面上支持多种“包括”和“排除”颜色。
o SHOULD provide a level of preference between included colors.
o 应在包含的颜色之间提供一个优先级别。
o SHOULD support the configuration of multiple colors on a single protecting interface.
o 应支持在单个保护界面上配置多种颜色。
As mentioned in previous sections, not taking into account the bandwidth of an alternate could lead to congestion during FRR activation. We propose that the bandwidth criteria be based on the link speed information, for the following reasons:
如前几节所述，在FRR激活期间，不考虑备用设备的带宽可能会导致拥塞。我们建议带宽标准基于链路速度信息，原因如下：
o If a router S has a set of X destinations primarily forwarded to N, using per-prefix LFAs may lead to having a subset of X protected by a neighbor N1, another subset by N2, another subset by Nx, etc.
o 如果路由器S具有一组主要转发到N的X目的地，则使用每前缀lfa可导致X的子集受到邻居N1的保护，另一子集受到N2的保护，另一子集受到Nx的保护，等等。
o S is not aware of traffic flows to each destination, so in the case of FRR activation, S is not able to evaluate how much traffic will be sent to N1, N2, Nx, etc.
o S不知道每个目的地的流量，因此在FRR激活的情况下，S无法评估将有多少流量发送到N1、N2、Nx等。
Based on this, it is not useful to gather available bandwidth on alternate paths, as the router does not know how much bandwidth it requires for protection. The proposed link speed approach provides a good approximation at low cost, as information is easily available.
基于此，在备用路径上收集可用带宽是没有用的，因为路由器不知道保护需要多少带宽。建议的链路速度方法以低成本提供了一个良好的近似值，因为信息很容易获得。
The bandwidth criteria of the policy framework SHOULD work in at least the following two ways:
策略框架的带宽标准应至少以以下两种方式工作：
o Prune: Exclude an LFA if the link speed to reach it is lower than the link speed of the primary next-hop interface.
o 删减：如果达到LFA的链路速度低于主下一跳接口的链路速度，则排除LFA。
o Prefer: Prefer an LFA based on its bandwidth to reach it compared to the link speed of the primary next-hop interface.
o 首选：与主下一跳接口的链路速度相比，基于到达LFA的带宽选择LFA。
Rather than tagging interfaces on each node (using link colors) to identify the types of alternate nodes (as an example), it would be helpful if routers could be identified in the IGP. This would allow grouped processing on multiple nodes. As an implementation needs to exclude some specific alternates (see Section 6.2.3), an implementation SHOULD be able to:
与其在每个节点上标记接口（使用链接颜色）来标识备用节点的类型（例如），不如在IGP中标识路由器。这将允许在多个节点上进行分组处理。由于实施需要排除某些特定备选方案（见第6.2.3节），实施应能够：
o give preference to a specific alternate.
o 优先选择特定的候补人选。
o give preference to a group of alternates.
o 优先考虑一组候补队员。
o exclude a specific alternate.
o 排除特定的替代项。
o exclude a group of alternates.
o 排除一组候补队员。
A specific alternate may be identified by its interface, IP address, or router ID, and a group of alternates may be identified by a marker (tag) advertised in IGP. The IGP encoding and signaling for marking groups of alternates SHOULD be done according to [RFC7917] and [RFC7777]. Using a tag/marker is referred to as "node coloring", as compared to the link coloring option presented in Section 6.2.4.2.
可以通过其接口、IP地址或路由器ID来识别特定的备选方案，并且可以通过IGP中公布的标记（标签）来识别一组备选方案。应根据[RFC7917]和[RFC7777]的规定，对交替组进行IGP编码和信号发送。与第6.2.4.2节中的链接着色选项相比，使用标签/标记称为“节点着色”。
Consider the following network:
考虑以下网络：
PE3
|
|
PE2
| +---- P4
| /
PE1 ---- P1 -------- P2
| 10 Gbps
1 Gbps |
|
P3
PE3
|
|
PE2
| +---- P4
| /
PE1 ---- P1 -------- P2
| 10 Gbps
1 Gbps |
|
P3
Figure 6
图6
In the example above, each node is configured with a specific tag flooded through the IGP.
在上面的示例中，每个节点都配置了一个通过IGP的特定标签。
o PE1,PE3: 200 (non-candidate).
o PE1、PE3:200（非候选人）。
o PE2: 100 (edge/core).
o PE2:100（边缘/核心）。
o P1,P2,P3: 50 (core).
o P1，P2，P3:50（核心）。
A simple policy could be configured on P1 to choose the best alternate for P1->P4 based on the function or role of the router, as follows:
可以在P1上配置一个简单的策略，以便根据路由器的功能或角色为P1->P4选择最佳备选方案，如下所示：
o criterion 1 -> alternate preference: exclude tags 100 and 200.
o 标准1->替代首选项：排除标记100和200。
o criterion 2 -> bandwidth.
o 标准2->带宽。
The alternate path is composed of two distinct parts: PLR to alternate and alternate to destination.
备用路径由两个不同的部分组成：PLR至备用路径和备用至目的地路径。
N1 -- R1 ---- R2
/50 \ \
/ R3 --- R4
/ \
S -------- E ------- D
\\ //
\\ //
N2 ---- PQ ---- R5
N1 -- R1 ---- R2
/50 \ \
/ R3 --- R4
/ \
S -------- E ------- D
\\ //
\\ //
N2 ---- PQ ---- R5
Figure 7
图7
In Figure 7, we consider a primary path from S to D, with S using E as the primary next hop. All metrics are 1, except that {S,N1} = 50. Two alternate paths are available:
在图7中，我们考虑从S到D的主路径，S使用E作为主下一跳。除了{S，N1}=50之外，所有度量都是1。有两条备用路径可用：
o {S,N1,R1,R2|R3,R4,D}, where N1 is a connected alternate. This consists of two sub-paths:
o {S，N1，R1，R2 | R3，R4，D}，其中N1是连接的候补。这包括两个子路径：
* {S,N1}: path from the PLR to the alternate.
* {S，N1}：从PLR到备用的路径。
* {N1,R1,R2|R3,R4,D}: path from the alternate to the destination.
* {N1，R1，R2 | R3，R4，D}：从备降到目的地的路径。
o {S,N2,PQ,R5,D}, where the PQ is a remote alternate. Again, the path consists of two sub-paths:
o {S，N2，PQ，R5，D}，其中PQ是远程备用。同样，路径由两个子路径组成：
* {S,N2,PQ}: path from the PLR to the alternate.
* {S，N2，PQ}：从PLR到备用的路径。
* {PQ,R5,D}: path from the alternate to the destination.
* {PQ，R5，D}：从备降到目的地的路径。
As displayed in Figure 7, some parts of the alternate path may fan out to multiple paths due to ECMP.
如图7所示，由于ECMP，备用路径的某些部分可能会扇出到多个路径。
Some criteria listed in the previous sections require the retrieval of some characteristics of the alternate path (SRLG, bandwidth, color, tag, etc.). We call these characteristics "path attributes". A path attribute can record a list of node properties (e.g., node tag) or link properties (e.g., link color).
前几节中列出的一些标准要求检索备用路径的某些特征（SRLG、带宽、颜色、标签等）。我们称这些特征为“路径属性”。路径属性可以记录节点属性（例如，节点标记）或链接属性（例如，链接颜色）的列表。
This document defines two types of path attributes:
本文档定义了两种类型的路径属性：
o Cumulative attribute: When a path attribute is cumulative, the implementation SHOULD record the value of the attribute on each element (link and node) along the alternate path. SRLG, link color, and node color are cumulative attributes.
o 累积属性：当路径属性是累积属性时，实现应该记录沿备用路径的每个元素（链接和节点）上的属性值。SRLG、链接颜色和节点颜色是累积属性。
o Unitary attribute: When a path attribute is unitary, the implementation SHOULD record the value of the attribute only on the first element along the alternate path (first node, or first link). Bandwidth is a unitary attribute.
o 酉属性：当路径属性是酉属性时，实现应该只在沿备用路径（第一个节点或第一个链接）的第一个元素上记录属性值。带宽是一个单一属性。
N1 -- R1 ---- R2
/ \
/ 50 R4
/ \
S -------- E ------- D
N1 -- R1 ---- R2
/ \
/ 50 R4
/ \
S -------- E ------- D
Figure 8
图8
In Figure 8, N1 is a connected alternate to reach D from S. We consider that all links have a RED color except {R1,R2}, which is BLUE. We consider all links to be 10 Gbps except {N1,R1}, which is 2.5 Gbps. The bandwidth attribute collected for the alternate path will be 10 Gbps. As the attribute is unitary, only the link speed of the first link {S,N1} is recorded. The link color attribute collected for the alternate path will be {RED,RED,BLUE,RED,RED}. As the attribute is cumulative, the value of the attribute on each link along the path is recorded.
在图8中，N1是从S到达D的一个连接的交替。我们认为所有的链接都有一个红色，除了{R1，R2}，它是蓝色的。我们认为所有的链接是10 Gbps，除了{N1，R1}，这是2.5 Gbps。为备用路径收集的带宽属性将为10 Gbps。由于该属性是幺正的，因此仅记录第一链路{S，N1}的链路速度。为备用路径收集的链接颜色属性将为{RED，RED，BLUE，RED，RED}。由于属性是累积的，因此会记录路径上每个链接上的属性值。
For an alternate path using a connected alternate:
对于使用连接的备用路径的备用路径：
o Attributes from the PLR to the alternate are retrieved from the interface connected to the alternate. If the alternate is connected through multiple interfaces, the evaluation of attributes SHOULD be done once per interface (each interface is considered as a separate alternate) and once per ECMP group of interfaces (Layer 3 bundle).
o 从连接到备用电源的接口检索从PLR到备用电源的属性。如果备用接口通过多个接口连接，则每个接口（每个接口被视为单独的备用接口）和每个ECMP接口组（第3层捆绑包）应进行一次属性评估。
o Path attributes from the alternate to the destination are retrieved from the SPT rooted at the alternate. As the alternate is a connected alternate, the SPT has already been computed to find the alternate, so there is no need for additional computation.
o 从备降场到目的地的路径属性从备降场根目录下的SPT检索。由于备选方案是连接的备选方案，已经计算了SPT以查找备选方案，因此无需额外计算。
N1 -- R1 ---- R2
50//50 \
// \
i1//i2 \
S -------- E -------- D
N1 -- R1 ---- R2
50//50 \
// \
i1//i2 \
S -------- E -------- D
Figure 9
图9
In Figure 9, we consider a primary path from S to D, with S using E as the primary next hop. All metrics are considered as 1 except {S,N1} links, which are using a metric of 50. We consider the following SRLGs on links:
在图9中，我们考虑从S到D的主路径，S使用E作为主下一跳。除{S，N1}链接外，所有度量都被视为1，它们使用的度量为50。我们考虑以下链接上的SRLG：
o {S,N1} using i1: SRLG1,SRLG10.
o {S，N1}使用i1:SRLG1，SRLG10。
o {S,N1} using i2: SRLG2,SRLG20.
o {S，N1}使用i2:SRLG2，SRLG20。
o {N1,R1}: SRLG3.
o {N1，R1}:SRLG3。
o {R1,R2}: SRLG4.
o {R1，R2}:SRLG4。
o {R2,D}: SRLG5.
o {R2，D}:SRLG5。
o {S,E}: SRLG10.
o {S，E}:SRLG10。
o {E,D}: SRLG6.
o {E，D}:SRLG6。
S is connected to the alternate using two interfaces: i1 and i2.
S通过两个接口连接到备用电源：i1和i2。
If i1 and i2 are not part of an ECMP group, the evaluation of attributes is done once per interface, and each interface is considered as a separate alternate path. Two alternate paths will be available with the associated SRLG attributes:
如果i1和i2不是ECMP组的一部分，则对每个接口进行一次属性评估，并且每个接口被视为单独的备用路径。两个备用路径将与相关的SRLG属性一起提供：
o Alternate path #1: {S,N1 using if1,R1,R2,D}: SRLG1,SRLG10,SRLG3,SRLG4,SRLG5.
o 备用路径#1:{S，N1使用if1，R1，R2，D}:SRLG1，SRLG10，SRLG3，SRLG4，SRLG5。
o Alternate path #2: {S,N1 using if2,R1,R2,D}: SRLG2,SRLG20,SRLG3,SRLG4,SRLG5.
o 备用路径#2:{S，N1使用if2，R1，R2，D}：SRLG2，SRLG20，SRLG3，SRLG4，SRLG5。
Alternate path #1 is sharing risks with the primary path and may be pruned, or its preference may be revoked, per user-defined policy.
备用路径#1与主路径共享风险，可能会根据用户定义的策略进行删减或撤销其首选项。
If i1 and i2 are part of an ECMP group, the evaluation of attributes is done once per ECMP group, and the implementation considers a single alternate path {S,N1 using if1|if2,R1,R2,D} with the following SRLG attributes: SRLG1,SRLG10,SRLG2,SRLG20,SRLG3,SRLG4,SRLG5. The alternate path is sharing risks with the primary path and may be pruned, or its preference may be revoked, per user-defined policy.
如果i1和i2是ECMP组的一部分，则对每个ECMP组进行一次属性评估，并且实现考虑使用具有以下SRLG属性的if1 | if2、R1、R2、D}的单个备用路径{S，N1:SRLG1、SRLG10、SRLG2、SRLG20、SRLG3、SRLG4、SRLG5。备用路径与主路径共享风险，可能会根据用户定义的策略进行删减或撤销其首选项。
For alternate path using a remote alternate (tunnel):
对于使用远程备用（隧道）的备用路径：
o Attributes on the path from the PLR to the alternate are retrieved using the PLR's primary SPT (when using a PQ node from the P-space) or the immediate neighbor's SPT (when using a PQ from the extended P-space). These are then combined with the attributes of the link(s) to reach the immediate neighbor. In both cases, no additional SPT is required.
o 使用PLR的主SPT（当从P空间使用PQ节点时）或直接邻居的SPT（当从扩展P空间使用PQ时）检索从PLR到备用路径上的属性。然后将这些属性与链路的属性组合，以到达直接邻居。在这两种情况下，不需要额外的SPT。
o Attributes from the remote alternate to the destination path may be retrieved from the SPT rooted at the remote alternate. An additional forward SPT is required for each remote alternate (PQ node), as indicated in Section 2.3.2 of [REMOTE-LFA-NODE]. In some remote-alternate scenarios, like [TI-LFA], alternate-to-destination path attributes may be obtained using a different technique.
o 从远程备用路径到目标路径的属性可以从根在远程备用路径的SPT检索。如[remote-LFA-node]第2.3.2节所示，每个远程备用（PQ节点）需要额外的正向SPT。在某些远程备用方案中，如[TI-LFA]，可使用不同的技术获得备用到目的地路径属性。
The number of remote alternates may be very high. In the case of remote LFAs, simulations of real-world network topologies have shown that as many as hundreds of PQs are possible. The computational overhead of collecting all path attributes of all such PQs to destination paths could grow beyond reasonable levels.
远程备用电源的数量可能非常高。在远程LFA的情况下，对真实网络拓扑的模拟表明，可能有多达数百个PQ。将所有此类PQ的所有路径属性收集到目标路径的计算开销可能会超过合理水平。
To handle this situation, implementations need to limit the number of remote alternates to be evaluated to a finite number before collecting alternate path attributes and running the policy evaluation. Section 2.3.3 of [REMOTE-LFA-NODE] provides a way to reduce the number of PQs to be evaluated.
为了处理这种情况，在收集备用路径属性并运行策略评估之前，实现需要将要评估的远程备用路径的数量限制为有限数量。[REMOTE-LFA-NODE]第2.3.3节提供了减少待评估PQ数量的方法。
Some other remote alternate techniques using static or dynamic tunnels may not require this pruning.
其他一些使用静态或动态隧道的远程替代技术可能不需要这种修剪。
Link Remote Remote
alternate alternate alternate
------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static/ |
| | | | | Dynamic |
sources | | | | | tunnels |
------------- ------------------ -------------
| | |
| | |
| -------------------------- |
| | Prune some alternates | |
| | (sorting strategy) | |
| -------------------------- |
| | |
| | |
------------------------------------------------
| Collect alternate attributes |
------------------------------------------------
|
|
-------------------------
| Evaluate policy |
-------------------------
|
|
Best alternates
Link Remote Remote
alternate alternate alternate
------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static/ |
| | | | | Dynamic |
sources | | | | | tunnels |
------------- ------------------ -------------
| | |
| | |
| -------------------------- |
| | Prune some alternates | |
| | (sorting strategy) | |
| -------------------------- |
| | |
| | |
------------------------------------------------
| Collect alternate attributes |
------------------------------------------------
|
|
-------------------------
| Evaluate policy |
-------------------------
|
|
Best alternates
Figure 10
图10
As described in Section 6.2.5, there may be some situations where an alternate path or part of an alternate path fans out to multiple paths (e.g., ECMP). When collecting path attributes in such a case, an implementation SHOULD consider the union of attributes of each sub-path.
如第6.2.5节所述，在某些情况下，备用路径或备用路径的一部分扇出到多个路径（例如ECMP）。在这种情况下收集路径属性时，实现应该考虑每个子路径的属性的合并。
In Figure 7 (in Section 6.2.5.1), S has two alternate paths to reach D. Each alternate path fans out to multiple paths due to ECMP. Consider the following link color attributes: all links are RED except {R1,R3}, which is BLUE. The user wants to use an alternate path with only RED links. The first alternate path {S,N1,R1,R2|R3,R4,D} does not fit the constraint, as {R1,R3} is BLUE. The second alternate path {S,N2,PQ,R5,D} fits the constraint and will be preferred, as it uses only RED links.
在图7（第6.2.5.1节）中，S有两条通向D的备用路径。由于ECMP，每条备用路径扇形成多条路径。考虑以下链接颜色属性：所有链接都是红色的，除了{R1，R3}，它是蓝色的。用户希望使用只有红色链接的备用路径。第一条备用路径{S，N1，R1，R2 | R3，R4，D}不符合约束条件，因为{R1，R3}是蓝色的。第二条备用路径{S，N2，PQ，R5，D}符合约束条件，并且将是首选路径，因为它只使用红色链接。
10
PE2 - PE3
| |
50 | 5 | 50
P1----P2
\\ //
50 \\ // 50
PE1
10
PE2 - PE3
| |
50 | 5 | 50
P1----P2
\\ //
50 \\ // 50
PE1
Links between P1 and PE1 are L1 and L2. Links between P2 and PE1 are L3 and L4.
P1和PE1之间的链路是L1和L2。P2和PE1之间的链路是L3和L4。
Figure 11
图11
In Figure 11, the primary path from PE1 to PE2 is through P1, using ECMP on two parallel links -- L1 and L2. In the case of standard ECMP behavior, if L1 is failing, the post-convergence next hop would become L2 and ECMP would no longer be in use. If an LFA is activated, as stated in Section 3.4 of [RFC5286], "alternate next-hops may themselves also be primary next-hops, but need not be" and "alternate next-hops should maximize the coverage of the failure cases." In this scenario, there is no alternate providing node protection, so PE1 will prefer L2 as the alternate to protect L1; this makes sense compared to post-convergence behavior.
在图11中，从PE1到PE2的主要路径是通过P1，在两个并行链路上使用ECMP——L1和L2。在标准ECMP行为的情况下，如果L1失败，则会聚后的下一跳将变为L2，ECMP将不再使用。如果LFA被激活，如[RFC5286]第3.4节所述，“备用下一跳本身也可以是主下一跳，但不必是”和“备用下一跳应最大限度地覆盖故障情况”。在这种情况下，没有备用节点提供保护，因此PE1将首选L2作为备用节点来保护L1；与后收敛行为相比，这是有意义的。
Consider a different scenario, again referring to Figure 11, where L1 and L2 are configured as a Layer 3 bundle using a local feature and L3/L4 comprise a second Layer 3 bundle. Layer 3 bundles are configured as if a link in the bundle is failing; the traffic must be rerouted out of the bundle. Layer 3 bundles are generally introduced to increase bandwidth between nodes. In a nominal situation, ECMP is still available from PE1 to PE2, but if L1 is failing, the post-convergence next hop would become the ECMP on L3 and L4. In this case, LFA behavior SHOULD be adapted in order to reflect the bandwidth requirement.
考虑不同的场景，再次参考图11，其中L1和L2被配置为使用局部特征的层3束，并且L3/L4包括第二层3束。第3层捆绑包被配置为捆绑包中的链路出现故障；流量必须从捆绑包中重新路由。通常引入第3层包以增加节点之间的带宽。在正常情况下，ECMP从PE1到PE2仍然可用，但如果L1失败，则会聚后的下一跳将成为L3和L4上的ECMP。在这种情况下，应调整LFA行为以反映带宽需求。
We would expect the following FIB entry on PE1:
我们预计PE1上会出现以下FIB条目：
On PE1: PE2 +--> ECMP -> L1
| |
| +----> L2
|
+--> LFA (ECMP) -> L3
|
+----------> L4
On PE1: PE2 +--> ECMP -> L1
| |
| +----> L2
|
+--> LFA (ECMP) -> L3
|
+----------> L4
Figure 12
图12
If L1 or L2 is failing, traffic must be switched on the LFA ECMP bundle rather than using the other primary next hop.
如果L1或L2出现故障，则必须在LFA ECMP包上切换流量，而不是使用另一个主下一跳。
As mentioned in Section 3.4 of [RFC5286], protecting a link within an ECMP by another primary next hop is not a MUST. Moreover, as already discussed in this document, maximizing coverage against the failure cases may not be the right approach, and a policy-based choice of an alternate may be preferred.
如[RFC5286]第3.4节所述，通过另一个主下一跳保护ECMP内的链路不是必须的。此外，正如本文件中已经讨论的那样，最大限度地覆盖故障案例可能不是正确的方法，基于策略选择备选方案可能是首选。
An implementation SHOULD allow setting a preference to protect a primary next hop with another primary next hop. An implementation SHOULD also allow setting a preference to protect a primary next hop with a NON-primary next hop. An implementation SHOULD allow the use of an ECMP bundle as an LFA.
实现应允许设置首选项，以使用另一个主下一跳保护主下一跳。实现还应允许设置首选项以保护主下一跳和非主下一跳。实现应该允许将ECMP包用作LFA。
In Section 3.5 of [RFC5286], the setting of the no-transit condition (through the IS-IS overload bit or the OSPF R-bit) in an LFA computation is only taken into account for the case where a neighbor has the no-transit condition set.
在[RFC5286]第3.5节中，LFA计算中无传输条件的设置（通过IS-IS过载位或OSPF R位）仅在邻居设置无传输条件的情况下考虑。
In addition to Inequality 1 (Loop-Free Criterion) (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)) [RFC5286], the IS-IS overload bit or the OSPF R-bit of the LFA calculating neighbor (S) SHOULD be taken into account. Indeed, if it has the IS-IS overload bit set or the OSPF R-bit clear, no neighbor will loop traffic back to itself.
除了等式1（无环路标准）（距离_opt（N，D）<距离_opt（N，S）+距离_opt（S，D））[RFC5286]，还应考虑LFA计算邻居的IS-IS过载位或OSPF R位。事实上，如果它设置了IS-IS过载位或OSPF R位清除，则没有邻居会将流量循环回自身。
An OSPF router acting as a stub router [RFC6987] SHOULD behave as if the R-bit was clear regarding the LFA computation.
充当存根路由器的OSPF路由器[RFC6987]的行为应如同R位对于LFA计算是明确的一样。
Service providers often perform manual link shutdown (using a router's command-line interface (CLI)) to perform network changes/tests. A manual link shutdown may be done at multiple levels: physical interface, logical interface, IGP interface, Bidirectional Forwarding Detection (BFD) session, etc. In particular, testing or troubleshooting FRR requires that manual shutdown be performed on the remote end of the link, as a local shutdown would not generally trigger FRR.
服务提供商通常执行手动链路关闭（使用路由器的命令行界面（CLI））以执行网络更改/测试。手动链路关闭可以在多个级别进行：物理接口、逻辑接口、IGP接口、双向转发检测（BFD）会话等。特别是，测试或故障排除FRR需要在链路的远程端执行手动关闭，因为本地关闭通常不会触发FRR。
To permit such a situation, an implementation SHOULD support triggering/activating LFA FRR for a given link when a manual shutdown is done on a component that currently supports FRR activation.
为了允许这种情况，当在当前支持FRR激活的组件上手动关闭时，实现应支持为给定链路触发/激活LFA FRR。
An implementation MAY also support FRR activation for a specific interface or a specific prefix on a primary next-hop interface and revert without any action on any running component of the node (links or protocols). In this use case, the FRR activation time needs to be controlled by a timer in case the operator forgot to revert the traffic to the primary path. When the timer expires, the traffic is automatically reverted to the primary path. This will simplify the testing of the FRR path; traffic can then be reverted back to the primary path without causing a global network convergence.
实现还可以支持针对特定接口或主下一跳接口上的特定前缀的FRR激活，并在节点的任何运行组件（链路或协议）上不进行任何操作的情况下进行恢复。在此用例中，FRR激活时间需要由计时器控制，以防操作员忘记将流量恢复到主路径。当计时器过期时，通信量将自动恢复到主路径。这将简化FRR路径的测试；然后，可以将流量恢复到主路径，而不会导致全球网络融合。
For example:
例如：
o If an implementation supports FRR activation upon a BFD session-down event, that implementation SHOULD support FRR activation when a manual shutdown is done on the BFD session. But if an implementation does not support FRR activation upon a BFD session-down event, there is no need for that implementation to support FRR activation upon manual shutdown of a BFD session.
o 如果某个实现在BFD会话关闭事件时支持FRR激活，则在BFD会话上手动关闭时，该实现应支持FRR激活。但是，如果一个实现在BFD会话关闭事件时不支持FRR激活，那么该实现就不需要在手动关闭BFD会话时支持FRR激活。
o If an implementation supports FRR activation upon a physical link-down event (e.g., Rx laser "off" detection, error threshold raised), that implementation SHOULD support FRR activation when a manual shutdown of a physical interface is done. But if an implementation does not support FRR activation upon a physical link-down event, there is no need for that implementation to support FRR activation upon manual shutdown of a physical link.
o 如果实现支持物理链路断开事件时的FRR激活（例如，Rx激光“关闭”检测，错误阈值升高），则该实现应在手动关闭物理接口时支持FRR激活。但是，如果一个实现在物理链路关闭事件时不支持FRR激活，那么该实现就不需要在手动关闭物理链路时支持FRR激活。
o A CLI command may allow switching from the primary path to the FRR path to test the FRR path for a specific interface or prefix. There is no impact on the control plane; only the data plane of the local node may be changed. A similar command may allow switching traffic back from the FRR path to the primary path.
o CLI命令可允许从主路径切换到FRR路径，以测试特定接口或前缀的FRR路径。对控制平面没有影响；只能更改本地节点的数据平面。类似的命令可允许将通信量从FRR路径切换回主路径。
The introduction of LFAs in a network requires some enhancements to standard routing information provided by implementations. Moreover, due to "non-100%" coverage, coverage information is also required.
在网络中引入LFA需要对实现提供的标准路由信息进行一些增强。此外，由于“非100%”覆盖率，还需要覆盖率信息。
Hence, an implementation:
因此，一个实现：
o MUST be able to display, for every prefix, the primary next hop as well as the alternate next-hop information.
o 必须能够为每个前缀显示主下一跳以及备用下一跳信息。
o MUST provide coverage information per LFA activation domain (area, level, topology, instance, virtual router, address family, etc.).
o 必须提供每个LFA激活域的覆盖率信息（区域、级别、拓扑、实例、虚拟路由器、地址系列等）。
o MUST provide the number of protected prefixes as well as non-protected prefixes globally.
o 必须提供全局受保护前缀和非受保护前缀的数量。
o SHOULD provide the number of protected prefixes as well as non-protected prefixes per link.
o 应提供每个链接的受保护前缀和非受保护前缀的数量。
o MAY provide the number of protected prefixes as well as non-protected prefixes per priority if the implementation supports prefix-priority insertion in the RIB/FIB.
o 如果实现支持在RIB/FIB中插入前缀优先级，则可以提供每个优先级的受保护前缀和非受保护前缀的数量。
o SHOULD provide a reason for choosing an alternate (policy and criteria) and for excluding an alternate.
o 应提供选择备选方案（政策和标准）和排除备选方案的理由。
o SHOULD provide the list of non-protected prefixes and the reason why they are not protected (e.g., no protection required, no alternate available).
o 应提供未受保护前缀的列表以及未受保护的原因（例如，无需保护，无备用前缀）。
It is pretty easy to evaluate the coverage of a network in a nominal situation, but topology changes may change the level of coverage. In some situations, the network may no longer be able to provide the required level of protection. Hence, it becomes very important for service providers to receive alerts regarding changes in coverage.
在正常情况下评估网络的覆盖范围非常容易，但拓扑更改可能会改变覆盖级别。在某些情况下，网络可能不再能够提供所需级别的保护。因此，服务提供商接收有关覆盖范围变化的警报变得非常重要。
An implementation SHOULD:
实施应：
o provide an alert system if total coverage (for a node) is below a defined threshold or when coverage returns to normal.
o 如果（节点的）总覆盖率低于定义的阈值或覆盖率恢复正常，则提供警报系统。
o provide an alert system if coverage for a specific link is below a defined threshold or when coverage returns to normal.
o 如果特定链接的覆盖率低于定义的阈值或覆盖率恢复正常，则提供警报系统。
An implementation MAY:
实施可以：
o trigger an alert if a specific destination is not protected anymore or when protection comes back up for this destination.
o 如果某个特定目的地不再受保护，或者该目的地恢复了保护，则触发警报。
Although the procedures for providing alerts are beyond the scope of this document, we recommend that implementations consider standard and well-used mechanisms like syslog or SNMP traps.
虽然提供警报的程序超出了本文档的范围，但我们建议实现考虑标准和使用良好的机制，如SysLoG或SNMP陷阱。
The operator may choose to run simulations in order to ensure a certain type of full coverage for the whole network or a given subset of the network. This is particularly likely if he operates the network in the sense of the third backbone profile described in Section 4 of [RFC6571]; that is, he seeks to design and engineer the network topology in such a way that a certain level of coverage is always achieved. Obviously, a complete and exact simulation of the IP FRR coverage can only be achieved if the behavior is deterministic and the algorithm used is available to the simulation tool. Thus, an implementation SHOULD:
运营商可以选择运行模拟，以确保整个网络或给定网络子集的某种类型的完全覆盖。如果他按照[RFC6571]第4节中所述的第三主干配置文件操作网络，则这种情况尤其可能发生；也就是说，他试图设计和设计网络拓扑，使其始终达到一定的覆盖水平。显然，只有当行为具有确定性且所使用的算法可供仿真工具使用时，才能实现对IP FRR覆盖的完整而准确的仿真。因此，实施应：
o Behave deterministically in its LFA selection process. That is, in the same topology and with the same policy configuration, the implementation MUST always choose the same alternate for a given prefix.
o 在LFA选择过程中表现出决定性。也就是说，在相同的拓扑结构和相同的策略配置中，实现必须始终为给定前缀选择相同的备选方案。
o Document its behavior. The implementation SHOULD provide enough documentation regarding its behavior to allow an implementer of a simulation tool to foresee the exact choice of the LFA implementation for every prefix in a given topology. This SHOULD take into account all possible policy configuration options. One possible way to document this behavior is to disclose the algorithm used to choose alternates.
o 记录它的行为。实现应提供足够的关于其行为的文档，以允许模拟工具的实现者预见给定拓扑中每个前缀的LFA实现的确切选择。这应该考虑所有可能的策略配置选项。记录这种行为的一种可能方法是公开用于选择替代品的算法。
The policy mechanism introduced in this document allows the tuning of the selection of the alternate. This is not seen as a security threat, because:
本文档中介绍的策略机制允许调整备选方案的选择。这不被视为安全威胁，因为：
o all candidates are already eligible as per [RFC5286] and considered usable.
o 根据[RFC5286]，所有候选人都已符合资格，并被视为可用。
o the policy is based on information from the router's own configuration and from the IGP, both of which are considered trusted.
o 该策略基于路由器自身配置和IGP的信息，两者都被认为是可信的。
Hence, this document does not introduce any new security considerations as compared to [RFC5286].
因此，与[RFC5286]相比，本文件未引入任何新的安全注意事项。
As noted above, the policy mechanism introduced in this document allows the tuning of the selection of the best alternate but does not change the list of alternates that are eligible. As described in Section 7 of [RFC5286], this best alternate "can be used anyway when a different topological change occurs, and hence this can't be viewed as a new security threat."
如上所述，本文档中引入的策略机制允许调整最佳备选方案的选择，但不会更改符合条件的备选方案列表。如[RFC5286]第7节所述，此最佳备选方案“在发生不同拓扑变化时，无论如何都可以使用，因此不能将其视为新的安全威胁。”
[ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO Standard 10589, 2002.
[ISO10589]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO标准10589，2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，DOI 10.17487/RFC4203，2005年10月<http://www.rfc-editor.org/info/rfc4203>.
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286]Atlas，A.，Ed.，和A.Zinin，Ed.，“IP快速重路由的基本规范：无环路交替”，RFC 5286，DOI 10.17487/RFC5286，2008年9月<http://www.rfc-editor.org/info/rfc5286>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>.
[RFC5307]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，DOI 10.17487/RFC5307，2008年10月<http://www.rfc-editor.org/info/rfc5307>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 5340，DOI 10.17487/RFC5340，2008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, <http://www.rfc-editor.org/info/rfc6571>.
[RFC6571]费斯菲尔斯，C.，Ed.，弗朗索瓦，P.，Ed.，尚德，M.，德雷恩，B.，乌塔罗，J.，莱曼，N.，和M.霍内弗，“服务提供商（SP）网络中的无环路备用（LFA）适用性”，RFC 6571，DOI 10.17487/RFC6571，2012年6月<http://www.rfc-editor.org/info/rfc6571>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <http://www.rfc-editor.org/info/rfc6987>.
[RFC6987]Retana，A.，Nguyen，L.，Zinin，A.，White，R.，和D.McPherson，“OSPF存根路由器广告”，RFC 6987，DOI 10.17487/RFC6987，2013年9月<http://www.rfc-editor.org/info/rfc6987>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <http://www.rfc-editor.org/info/rfc7490>.
[RFC7490]Bryant，S.，Filsfils，C.，Previdi，S.，Shand，M.，和N.So，“远程无环路备用（LFA）快速重路由（FRR）”，RFC 7490，DOI 10.17487/RFC74902015年4月<http://www.rfc-editor.org/info/rfc7490>.
[RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising Node Administrative Tags in OSPF", RFC 7777, DOI 10.17487/RFC7777, March 2016, <http://www.rfc-editor.org/info/rfc7777>.
[RFC7777]Hegde，S.，Shakir，R.，Smirnov，A.，Li，Z.，和B.Decraene，“OSPF中的广告节点管理标签”，RFC 7777，DOI 10.17487/RFC7777，2016年3月<http://www.rfc-editor.org/info/rfc7777>.
[RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S., and B. Decraene, "Advertising Node Administrative Tags in IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016, <http://www.rfc-editor.org/info/rfc7917>.
[RFC7917]Sarkar，P.，Ed.，Gredler，H.，Hegde，S.，Litkowski，S.，和B.Decraene，“IS-IS中的广告节点管理标签”，RFC 7917，DOI 10.17487/RFC79172016年7月<http://www.rfc-editor.org/info/rfc7917>.
[REMOTE-LFA-NODE] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and S. Litkowski, "Remote-LFA Node Protection and Manageability", Work in Progress, draft-ietf-rtgwg-rlfa-node-protection-05, December 2015.
[REMOTE-LFA-NODE]Sarkar，P.，Ed.，Hegde，S.，Bowers，C.，Gredler，H.，和S.Litkowski，“远程LFA节点保护和可管理性”，在建工程，草案-ietf-rtgwg-rlfa-NODE-Protection-052015年12月。
[SEG-RTG-ARCH] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-09, July 2016.
[SEG-RTG-ARCH]Filsfils，C.，Ed.，Previdi，S.，Ed.，Decaene，B.，Litkowski，S.，和R.Shakir，“分段布线架构”，正在进行的工作，草案-ietf-spring-Segment-Routing-092016年7月。
[TI-LFA] Francois, P., Filsfils, C., Bashandy, A., Decraene, B., and S. Litkowski, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, draft-francois-segment-routing-ti-lfa-00, November 2013.
[TI-LFA]Francois，P.，Filsfils，C.，Bashandy，A.，DeClaene，B.，和S.Litkowski，“使用段路由的拓扑独立快速重路由”，正在进行的工作，草稿-Francois-Segment-Routing-TI-LFA-00，2013年11月。
Contributors
贡献者
Significant contributions were made by Pierre Francois, Hannes Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri, Acee Lindem, and Mustapha Aissaoui, whom the authors would like to acknowledge.
Pierre Francois、Hannes Gredler、Chris Bowers、Jeff Tantsura、Uma Chunduri、Acee Lindem和Mustapha Aissaoui做出了重大贡献，作者希望感谢他们。
Authors' Addresses
作者地址
Stephane Litkowski (editor) Orange
斯蒂芬·利特科夫斯基（编辑）橙色
Email: stephane.litkowski@orange.com
Email: stephane.litkowski@orange.com
Bruno Decraene Orange
布鲁诺橙
Email: bruno.decraene@orange.com
Email: bruno.decraene@orange.com
Clarence Filsfils Cisco Systems
克拉伦斯菲尔斯思科系统公司
Email: cfilsfil@cisco.com
Email: cfilsfil@cisco.com
Kamran Raza Cisco Systems
卡姆兰·拉扎思科系统公司
Email: skraza@cisco.com
Email: skraza@cisco.com
Martin Horneffer Deutsche Telekom
马丁·霍内弗德国电信公司
Email: Martin.Horneffer@telekom.de
Email: Martin.Horneffer@telekom.de
Pushpasis Sarkar Individual Contributor
Pushpasis Sarkar个人贡献者
Email: pushpasis.ietf@gmail.com
Email: pushpasis.ietf@gmail.com