Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8355 S. Previdi, Ed.
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 B. Decraene
Orange
R. Shakir
Google
March 2018
Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Request for Comments: 8355 S. Previdi, Ed.
Category: Informational Cisco Systems, Inc.
ISSN: 2070-1721 B. Decraene
Orange
R. Shakir
Google
March 2018
Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks
网络（SPRING）网络中源数据包路由的弹性用例
Abstract
摘要
This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks.
本文档确定并描述了与网络（SPRING）网络中源数据包路由的分段路由网络弹性相关的一组用例的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8355.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8355.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Path Protection . . . . . . . . . . . . . . . . . . . . . . . 4
3. Management-Free Local Protection . . . . . . . . . . . . . . 6
3.1. Management-Free Bypass Protection . . . . . . . . . . . . 7
3.2. Management-Free Shortest-Path-Based Protection . . . . . 8
4. Managed Local Protection . . . . . . . . . . . . . . . . . . 8
4.1. Managed Bypass Protection . . . . . . . . . . . . . . . . 9
4.2. Managed Shortest Path Protection . . . . . . . . . . . . 9
5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . . 10
6. Coexistence of Multiple Resilience Techniques in the Same
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Manageability Considerations . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Path Protection . . . . . . . . . . . . . . . . . . . . . . . 4
3. Management-Free Local Protection . . . . . . . . . . . . . . 6
3.1. Management-Free Bypass Protection . . . . . . . . . . . . 7
3.2. Management-Free Shortest-Path-Based Protection . . . . . 8
4. Managed Local Protection . . . . . . . . . . . . . . . . . . 8
4.1. Managed Bypass Protection . . . . . . . . . . . . . . . . 9
4.2. Managed Shortest Path Protection . . . . . . . . . . . . 9
5. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . . 10
6. Coexistence of Multiple Resilience Techniques in the Same
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Manageability Considerations . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
This document reviews various use cases for the protection of services in a SPRING network. The terminology used hereafter is in line with [RFC5286] and [RFC5714].
本文档回顾了SPRING网络中保护服务的各种用例。下文使用的术语与[RFC5286]和[RFC5714]一致。
The resiliency use cases described in this document can be applied not only to traffic that is forwarded according to the SPRING architecture, but also to traffic that originally is forwarded using other paradigms such as LDP signaling or pure IP traffic (IP-routed traffic).
本文档中描述的弹性用例不仅可以应用于根据SPRING体系结构转发的流量，还可以应用于最初使用其他范例（如LDP信令或纯IP流量（IP路由流量））转发的流量。
Three key alternatives are described: path protection, local protection without operator management, and local protection with operator management.
描述了三种关键的替代方案：路径保护、无操作员管理的本地保护和有操作员管理的本地保护。
Path protection lets the ingress node be in charge of the failure recovery, as discussed in Section 2.
路径保护允许入口节点负责故障恢复，如第2节所述。
The rest of the document focuses on approaches where protection is performed by the node adjacent to the failed component, commonly referred to as local protection techniques or fast-reroute techniques [RFC5286] [RFC5714].
本文档的其余部分重点介绍由故障组件附近的节点执行保护的方法，通常称为本地保护技术或快速重路由技术[RFC5286][RFC5714]。
In Section 3, we discuss two different approaches providing unmanaged local protection, namely link/node bypass protection and shortest-path-based protection.
在第3节中，我们将讨论提供非托管本地保护的两种不同方法，即链路/节点旁路保护和基于最短路径的保护。
Section 4 illustrates a case allowing the operator to manage the local protection behavior in order to accommodate specific policies.
第4节说明了一个允许操作员管理本地保护行为以适应特定策略的案例。
In Section 5, we discuss the opportunity for the SPRING architecture to provide loop-avoidance mechanisms such that transient forwarding state inconsistencies during routing convergence do not lead into traffic loss.
在第5节中，我们讨论了SPRING体系结构提供环路避免机制的机会，以使路由收敛期间的瞬态转发状态不一致不会导致流量丢失。
The purpose of this document is to illustrate the different use cases and explain how an operator could combine them in the same network (see Section 6). Solutions are not defined in this document.
本文档旨在说明不同的用例，并解释运营商如何将它们组合到同一网络中（参见第6节）。本文档中未定义解决方案。
B------C------D------E
/| | \ / | \ / |\
/ | | \/ | \/ | \
A | | /\ | /\ | Z
\ | | / \ | / \ | /
\| |/ \|/ \|/
F------G------H------I
B------C------D------E
/| | \ / | \ / |\
/ | | \/ | \/ | \
A | | /\ | /\ | Z
\ | | / \ | / \ | /
\| |/ \|/ \|/
F------G------H------I
Figure 1: Reference Topology
图1：参考拓扑
We use Figure 1 as a reference topology throughout the document. The following link metrics are applied:
在整个文档中，我们使用图1作为参考拓扑。将应用以下链接度量：
o Links from/to A and Z are configured with a metric of 100.
o 从/到A和Z的链路配置为100的度量。
o CH, GD, DI, and HE links are configured with a metric of 6.
o CH、GD、DI和HE链路的配置指标为6。
o All other links are configured with a metric of 5.
o 所有其他链接都配置了5的度量。
Note: Link metrics are bidirectional; in other words, the same metric value is configured at both sides of each link.
注意：链路度量是双向的；换句话说，在每个链路的两侧配置相同的度量值。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
As a reminder, one of the major network operator requirements is path disjointness capability. Network operators have deployed infrastructures with topologies that allow paths to be computed in a complete disjoint fashion where two paths wouldn't share any component (link or router), hence allowing an optimal protection strategy.
提醒一下，网络运营商的主要要求之一是路径不相交能力。网络运营商部署的基础设施的拓扑结构允许以完全不相交的方式计算路径，其中两条路径不会共享任何组件（链路或路由器），因此允许采用最佳保护策略。
A first protection strategy consists of excluding any local repair and instead uses end-to-end path protection where each SPRING path is protected by a second disjoint SPRING path. In this case, local protection is not used along the path.
第一个保护策略包括排除任何本地修复，而是使用端到端路径保护，其中每个弹簧路径由第二个不相交的弹簧路径保护。在这种情况下，不会沿路径使用本地保护。
For example, a pseudowire (PW) from A to Z can be "path protected" in the direction A to Z in the following manner: the operator configures two SPRING paths, T1 (primary) and T2 (backup), from A to Z.
例如，从a到Z的伪线（PW）可以按照以下方式在a到Z的方向上“路径保护”：操作员配置从a到Z的两条弹簧路径T1（主）和T2（备用）。
The two paths may be used:
可以使用两条路径：
o concurrently, where the ingress router sends the same traffic over the primary and secondary path (this is usually known as 1+1 protection);
o 同时，入口路由器通过主路径和辅助路径发送相同的通信量（这通常称为1+1保护）；
o concurrently, where the ingress router splits the traffic over the primary and secondary path (this is usually known as Equal-Cost Multipath (ECMP) or Unequal-Cost Multipath (UCMP)); or
o 同时，入口路由器在主路径和辅助路径上拆分流量（这通常称为等成本多路径（ECMP）或不等成本多路径（UCMP））；或
o as a primary and backup path, where the secondary path is used only when the primary failed (this is usually known as 1:1 protection).
o 作为主路径和备份路径，其中辅助路径仅在主路径出现故障时使用（这通常称为1:1保护）。
T1 is established over path {AB, BC, CD, DE, EZ} as the primary path, and T2 is established over path {AF, FG, GH, HI, IZ} as the backup path. The two paths MUST be disjoint in their links, nodes, and Shared Risk Link Groups (SRLGs) to satisfy the requirement of disjointness.
T1在路径{AB，BC，CD，DE，EZ}上建立为主路径，T2在路径{AF，FG，GH，HI，IZ}上建立备份路径。这两条路径的链接、节点和共享风险链接组（SRLGs）必须是不相交的，以满足不相交的要求。
In the case of primary/backup paths, when the primary path T1 is up, the packets of the PW are sent on T1. When T1 fails, the packets of the PW are sent on the backup path T2. When T1 comes back up, the operator either allows for an automated reversion of the traffic onto T1 or selects an operator-driven reversion. Typically, the switchover from path T1 to path T2 is done in a fast-reroute fashion (e.g., sub-50 milliseconds) but, depending on the service that needs to be delivered, other restoration times may be used.
在主/备份路径的情况下，当主路径T1向上时，PW的分组在T1上发送。当T1失败时，PW的分组在备份路径T2上发送。当T1恢复时，操作员要么允许自动将流量恢复到T1，要么选择操作员驱动的恢复。通常，从路径T1到路径T2的切换以快速重路由方式（例如，小于50毫秒）完成，但是，根据需要交付的服务，可以使用其他恢复时间。
It is essential that any path, primary or backup, benefit from an end-to-end liveness monitoring/verification. The method and mechanisms that provide such a liveness check are outside the scope of this document. An example is given by [RFC5880].
任何路径（主路径或备份路径）都必须受益于端到端的活动性监视/验证。提供此类活动性检查的方法和机制不在本文档的范围内。[RFC5880]给出了一个示例。
There are multiple options for a liveness check, e.g., path liveness, where the path is monitored at the network level (either by the head-end node or by a network controller/monitoring system). Another possible approach consists of a service-based path monitored by the service instance (verifying reachability of the endpoint). All these options are given here as examples. While this document does express the requirement for a liveness mechanism, it does not mandate, nor define, any specific one.
活跃度检查有多个选项，例如路径活跃度，其中路径在网络级别进行监控（通过前端节点或网络控制器/监控系统）。另一种可能的方法包括由服务实例监控的基于服务的路径（验证端点的可达性）。这里给出了所有这些选项作为示例。虽然本文档确实表达了对活跃性机制的需求，但它并没有规定或定义任何特定的机制。
From a SPRING viewpoint, we would like to highlight the following requirements:
从SPRING的角度来看，我们希望强调以下要求：
o SPRING architecture MUST provide a way to compute paths that are not protected by local repair techniques (as illustrated in the example of paths T1 and T2).
o SPRING体系结构必须提供一种方法来计算不受本地修复技术保护的路径（如路径T1和T2示例所示）。
o SPRING architecture MUST provide a way to instantiate pairs of disjoint paths on a topology based on a protection strategy (link, node, or SRLG protection) and allow the validation or recomputation of these paths upon network events.
o SPRING体系结构必须提供一种基于保护策略（链路、节点或SRLG保护）实例化拓扑上不相交路径对的方法，并允许在网络事件时验证或重新计算这些路径。
o The SPRING architecture MUST provide an end-to-end liveness check of SPRING-based paths.
o SPRING体系结构必须提供基于SPRING的路径的端到端活动性检查。
This section describes two alternatives that provide local protection without requiring operator management, namely bypass protection and shortest-path-based protection.
本节描述了两种提供本地保护而不需要操作员管理的替代方案，即旁路保护和基于最短路径的保护。
For example, traffic from A to Z, transported over the shortest paths provided by the SPRING architecture, benefits from management-free local protection by having each node along the path automatically precompute and preinstall a backup path for the destination Z. Upon local detection of the failure, the traffic is repaired over the backup path in sub-50 milliseconds. When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto it or selects an operator-driven reversion.
例如，通过SPRING体系结构提供的最短路径传输从A到Z的流量，通过让路径上的每个节点自动预计算并预安装目的地Z的备份路径，从无管理本地保护中获益。在本地检测到故障时，在低于50毫秒的时间内，通过备份路径修复通信量。当主路径返回时，操作员要么允许自动将流量返回到主路径，要么选择操作员驱动的返回。
The backup path computation SHOULD support the following requirements:
备份路径计算应支持以下要求：
o 100% link, node, and SRLG protection in any topology;
o 在任何拓扑中100%链路、节点和SRLG保护；
o automated computation by the IGP; and
o IGP自动计算；和
o selection of the backup path such as to minimize the chance for transient congestion and/or delay during the protection period, as reflected by the IGP metric configuration in the network.
o 备份路径的选择，如网络中IGP度量配置所反映的，以尽量减少保护期间出现瞬时拥塞和/或延迟的机会。
One way to provide local repair is to enforce a failover along the shortest path around the failed component.
提供本地修复的一种方法是沿故障组件周围的最短路径实施故障转移。
In case of link protection, the point of local repair will create a repair path avoiding the protected link and merging back to the primary path at the next hop.
在链路保护的情况下，本地修复点将创建一个修复路径，避免受保护的链路，并在下一跳时合并回主路径。
In case of node protection, the repair path will avoid the protected node and merge back to the primary path at the next-next hop.
在节点保护的情况下，修复路径将避开受保护的节点，并在下一跳时合并回主路径。
In case of SRLG protection, the repair path will avoid members of the same group and merge back to the primary path just after.
在SRLG保护的情况下，修复路径将避开同一组的成员，并在稍后合并回主路径。
In our example, C protects destination Z against a failure of the CD link by enforcing the traffic over the bypass {CH, HD}. The resulting end-to-end path between A and Z, upon recovery from the failure of CD, is depicted in Figure 2.
在我们的示例中，C通过在旁路{CH，HD}上强制传输来保护目的地Z不受CD链路故障的影响。从CD故障中恢复后，A和Z之间产生的端到端路径如图2所示。
B * * *C------D * * *E
*| | * / * \ / |*
* | | */ * \/ | *
A | | /* * /\ | Z
\ | | / * * / \ | /
\| |/ **/ \|/
F------G------H------I
B * * *C------D * * *E
*| | * / * \ / |*
* | | */ * \/ | *
A | | /* * /\ | Z
\ | | / * * / \ | /
\| |/ **/ \|/
F------G------H------I
Figure 2: Bypass Protection around Link CD
图2：链路CD周围的旁路保护
When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto the primary path or selects an operator-driven reversion.
当主路径返回时，操作员允许自动将流量恢复到主路径上，或选择操作员驱动的恢复。
An alternative protection strategy consists in management-free local protection that is aimed at providing a repair for the destination based on the shortest path to the destination.
另一种保护策略包括无管理本地保护，旨在根据到目的地的最短路径为目的地提供修复。
In our example, C protects Z (which the traffic initially reaches via CD) by enforcing the traffic over its shortest path to Z and considering the failure of the protected component. The resulting end-to-end path between A and Z, upon recovery from the failure of CD, is depicted in Figure 3.
在我们的示例中，C通过在到Z的最短路径上强制流量并考虑受保护组件的故障来保护Z（流量最初通过CD到达）。从CD故障中恢复后，A和Z之间产生的端到端路径如图3所示。
B * * *C------D------E
*| | * / | \ / |\
* | | */ | \/ | \
A | | /* | /\ | Z
\ | | / * | / \ | *
\| |/ *|/ \|*
F------G------H * * *I
B * * *C------D------E
*| | * / | \ / |\
* | | */ | \/ | \
A | | /* | /\ | Z
\ | | / * | / \ | *
\| |/ *|/ \|*
F------G------H * * *I
Figure 3: Shortest Path Protection around Link CD
图3：链路CD周围的最短路径保护
When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto the primary path or selects an operator-driven reversion.
当主路径返回时，操作员允许自动将流量恢复到主路径上，或选择操作员驱动的恢复。
There may be cases where a management-free repair does not fit the policy of the operator. For example, in our illustration, the operator may not want to have CD and CH used to protect each other due to the bandwidth (BW) availability in each link that could not suffice to absorb the other link traffic.
可能存在免管理维修不符合运营商政策的情况。例如，在我们的示例中，由于每个链路中的带宽（BW）可用性不足以吸收其他链路流量，运营商可能不希望使用CD和CH来相互保护。
In this context, the protection mechanism MUST support the explicit configuration of the backup path either under the form of high-level constraints (end at the next hop, end at the next-next hop, minimize this metric, avoid this SRLG, etc.) or under the form of an explicit path. Upon local detection of the failure, the traffic is repaired over the backup path in sub-50 milliseconds. When the primary path comes back up, the operator either allows for an automated reversion of the traffic onto it or selects an operator-driven reversion.
在这种情况下，保护机制必须以高级约束的形式（在下一跳结束、在下一跳结束、最小化此度量、避免此SRLG等）或以显式路径的形式支持备份路径的显式配置。在本地检测到故障后，将在50毫秒以下通过备份路径修复通信量。当主路径返回时，操作员要么允许自动将流量返回到主路径，要么选择操作员驱动的返回。
We discuss such aspects for both bypass and shortest-path-based protection schemes.
我们讨论了旁路和基于最短路径的保护方案的这些方面。
Let us illustrate the case using our reference example. For the demand from A to Z, the operator does not want to use the shortest failover path to the next hop, {CH, HD}, but rather the path {CG, GH, HD}, as illustrated in Figure 4.
让我们用我们的参考例子来说明这个例子。对于从A到Z的请求，操作员不希望使用到下一跳的最短故障切换路径{CH，HD}，而是使用路径{CG，GH，HD}，如图4所示。
B * * *C------D * * *E
*| * \ / * \ / |*
* | * \/ * \/ | *
A | * /\ * /\ | Z
\ | * / \ * / \ | /
\| */ \*/ \|/
F------G * * *H------I
B * * *C------D * * *E
*| * \ / * \ / |*
* | * \/ * \/ | *
A | * /\ * /\ | Z
\ | * / \ * / \ | /
\| */ \*/ \|/
F------G * * *H------I
Figure 4: Managed Bypass Protection
图4：管理旁路保护
The computation of the repair path SHOULD be possible in an automated fashion as well as statically expressed in the point of local repair.
修复路径的计算应能够以自动方式进行，并在局部修复点静态表示。
In the case of shortest path protection, the operator does not want to use the shortest failover via link CH, but rather the traffic should reach H via {CG, GH} due to constraints such as delay, BW, or SRLG.
在最短路径保护的情况下，操作员不希望通过链路CH使用最短故障切换，而是由于延迟、BW或SRLG等限制，通信量应通过{CG，GH}到达H。
The resulting end-to-end path upon activation of the protection is illustrated in Figure 5.
激活保护后产生的端到端路径如图5所示。
B * * *C------D------E
*| * \ / | \ / |\
* | * \/ | \/ | \
A | * /\ | /\ | Z
\ | * / \ | / \ | *
\| */ \|/ \|*
F------G * * *H * * *I
B * * *C------D------E
*| * \ / | \ / |\
* | * \/ | \/ | \
A | * /\ | /\ | Z
\ | * / \ | / \ | *
\| */ \|/ \|*
F------G * * *H * * *I
Figure 5: Managed Shortest Path Protection
图5：管理的最短路径保护
The computation of the repair path SHOULD be possible in an automated fashion as well as statically expressed in the point of local repair.
修复路径的计算应能够以自动方式进行，并在局部修复点静态表示。
The computation of the repair path based on a specific constraint SHOULD be possible on a per-destination prefix base.
基于特定约束的修复路径计算应该可以在每个目的地前缀基础上进行。
It is part of routing protocols' behavior to have what are called "transient routing inconsistencies". This is due to the routing convergence that happens in each node at different times and during a different lapse of time.
路由协议行为的一部分就是所谓的“暂时路由不一致”。这是由于每个节点在不同时间和不同时间段发生的路由收敛。
These inconsistencies may cause routing loops that last the time that it takes for the node impacted by a network event to converge. These loops are called "micro-loops".
这些不一致可能导致路由循环持续受网络事件影响的节点收敛所需的时间。这些回路称为“微回路”。
Usually, in normal routing protocol operations, micro-loops do not last long and are only noticed during the time it takes the network to converge. However, with the emergence of fast-convergence and fast-reroute technologies, micro-loops can be an issue in networks where sub-50 millisecond convergence/reroute is required. Therefore, the micro-loop problem needs to be addressed.
通常，在正常的路由协议操作中，微循环不会持续很长时间，只有在网络收敛时才会被注意到。然而，随着快速收敛和快速重路由技术的出现，微环路可能成为需要低于50毫秒收敛/重路由的网络中的一个问题。因此，需要解决微环问题。
Networks may be affected by micro-loops during convergence depending of their topologies. Detecting micro-loops can be done during topology computation (e.g., Shortest Path First (SPF) computation), and therefore techniques to avoid micro-loops may be applied. An example of such technique is to compute a path free of micro-loops that would be used during network convergence.
网络在收敛过程中可能会受到微环的影响，这取决于网络的拓扑结构。可以在拓扑计算期间检测微环（例如，最短路径优先（SPF）计算），因此可以应用避免微环的技术。这种技术的一个例子是计算一条没有微环的路径，该路径将在网络收敛期间使用。
The SPRING architecture SHOULD provide solutions to prevent the occurrence of micro-loops during convergence following a change in the network state. Traditionally, the lack of packet steering capability made it difficult to apply efficient solutions to micro-loops. A SPRING-enabled router could take advantage of the increased packet steering capabilities offered by SPRING in order to steer packets in a way that packets do not enter such loops.
SPRING体系结构应提供解决方案，以防止在网络状态发生变化后的聚合过程中出现微循环。传统上，由于缺乏数据包控制能力，很难将有效的解决方案应用于微环。支持SPRING的路由器可以利用SPRING提供的增加的数据包控制能力，以使数据包不进入这种循环的方式控制数据包。
6. Coexistence of Multiple Resilience Techniques in the Same Infrastructure
6. 同一基础设施中多种恢复能力技术的共存
The operator may want to support several very different services on the same packet-switching infrastructure. As a result, the SPRING architecture SHOULD allow for the coexistence of the different use cases listed in this document, in the same network.
运营商可能希望在同一分组交换基础设施上支持几个非常不同的服务。因此，SPRING体系结构应该允许本文档中列出的不同用例在同一网络中共存。
Let us illustrate this with the following example:
让我们用下面的例子来说明这一点：
o Flow F1 is supported over path {C, CD, E}
o 路径{C，CD，E}上支持流F1
o Flow F2 is supported over path {C, CD, I}
o 在路径{C，CD，I}上支持流F2
o Flow F3 is supported over path {C, CD, Z}
o 路径{C，CD，Z}上支持流F3
o Flow F4 is supported over path {C, CD, Z}
o 在路径{C，CD，Z}上支持流F4
It should be possible for the operator to configure the network to achieve path protection for F1, management-free shortest path local protection for F2, managed protection over path {CG, GH, Z} for F3, and management-free bypass protection for F4.
运营商应能够配置网络，以实现F1的路径保护、F2的无管理最短路径本地保护、F3的路径{CG、GH、Z}上的管理保护以及F4的无管理旁路保护。
This document describes requirements for the SPRING architecture to provide resiliency in SPRING networks. As such, it does not introduce any new security considerations beyond those discussed in [RFC7855].
本文档描述了SPRING体系结构在SPRING网络中提供弹性的要求。因此，除了[RFC7855]中讨论的安全注意事项外，它没有引入任何新的安全注意事项。
This document has no IANA actions.
本文档没有IANA操作。
This document provides use cases. Solutions aimed at supporting these use cases should provide the necessary mechanisms in order to allow for manageability as described in [RFC7855].
本文档提供了用例。旨在支持这些用例的解决方案应提供必要的机制，以便实现[RFC7855]中所述的可管理性。
Manageability concerns the computation, installation, and troubleshooting of the repair path. Also, necessary mechanisms SHOULD be provided in order for the operator to control when a repair path is computed, how it has been computed, and if it's installed and used.
可管理性涉及修复路径的计算、安装和故障排除。此外，还应提供必要的机制，以便操作员控制何时计算修复路径、如何计算修复路径以及是否安装和使用修复路径。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC7855]Previdi，S.，Ed.，Filsfils，C.，Ed.，DeClaene，B.，Litkowski，S.，Horneffer，M.，和R.Shakir，“网络中的源数据包路由（SPRING）问题声明和要求”，RFC 7855，DOI 10.17487/RFC7855，2016年5月<https://www.rfc-editor.org/info/rfc7855>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <https://www.rfc-editor.org/info/rfc5286>.
[RFC5286]Atlas，A.，Ed.和A.Zinin，Ed.，“IP快速重路由的基本规范：无环路交替”，RFC 5286，DOI 10.17487/RFC5286，2008年9月<https://www.rfc-editor.org/info/rfc5286>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.
[RFC5714]Shand，M.和S.Bryant，“IP快速重路由框架”，RFC 5714，DOI 10.17487/RFC5714，2010年1月<https://www.rfc-editor.org/info/rfc5714>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 5880，DOI 10.17487/RFC5880，2010年6月<https://www.rfc-editor.org/info/rfc5880>.
Acknowledgements
致谢
The authors would like to thank Stephane Litkowski and Alexander Vainshtein for the comments and review of this document.
作者感谢Stephane Litkowski和Alexander Vainstein对本文件的评论和评论。
Contributors
贡献者
Pierre Francois contributed to the writing of the first draft version of this document.
皮埃尔·弗朗索瓦对本文件初稿的编写作出了贡献。
Authors' Addresses
作者地址
Clarence Filsfils (editor) Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils（编辑）思科系统公司比利时布鲁塞尔
Email: cfilsfil@cisco.com
Email: cfilsfil@cisco.com
Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
斯蒂凡诺·普雷维迪（编辑）思科系统有限公司，意大利罗马，邮编：200，邮编：00142
Email: stefano@previdi.net
Email: stefano@previdi.net
Bruno Decraene Orange France
布鲁诺·德雷恩橙法国
Email: bruno.decraene@orange.com
Email: bruno.decraene@orange.com
Rob Shakir Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Rob Shakir Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
Email: robjs@google.com
Email: robjs@google.com