文章总结： 本文档RFC9855定义了拓扑独立无环替代(TI-LFA)快速重路由机制，利用分段路由(SR)在链路或节点故障时提供有保证的保护覆盖。它通过预计算备份路径并编码为段列表，避免了传统LFA的拓扑限制和微环路问题。关键优势包括无需额外协议、减少配置需求，并支持链路、节点及SRLG故障保护。建议网络运营商在部署SR时采用TI-LFA以提升网络弹性。 综合评分： 85 文章分类： 技术标准,网络安全,解决方案
使用分段路由实现独立于拓扑的快速重新路由
衡水石头哥 衡水石头哥
铁军哥
2026年7月18日 07:36 北京
在小说阅读器读本章
去阅读
RFC 9855：Topology Independent Fast Reroute Using Segment Routing，October 2025
梗概
本文档介绍了拓扑独立无环替代（Topology Independent Loop-Free Alternate，TILFA）快速重路由（Fast Reroute，FRR），旨在为分段路由（Segment Routing，SR）框架内的节点和邻接分段提供保护。此FRR行为建立在经过验证的IP FRR概念之上，即LFA、远程LFA（Remote LFAs，RLFA）和定向无环替代（Directed Loop-Free Alternates，DLFA）。它扩展了这些概念，以使用链路状态IGP在任何两个连接的网络中提供有保证的覆盖范围。TI-LFA的一个重要方面是FRR路径选择方法，从本地修复点（Point of Local Repair，PLR）建立对预期收敛后路径的保护，从而减少控制各种FRR选项之间的决胜局的操作需求。
本备忘录的状态
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc9855。
版权声明
版权所有（c）2025 IETF Trust和文档作者。版权所有。
本文件受本文件发布之日生效的BCP 78和IETF信托与IETF文件相关的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括《信托法律条款》第4.e节中所述的修订版BSD许可证文本，并且不提供修订版BSD许可证中所述的保证。
1、简介
本文档概述了一种本地修复机制，该机制利用分段路由（SR）在涉及直接连接的网络组件发生故障时恢复端到端连接。该机制专为标准链路状态内部网关协议（Interior Gateway Protocol，IGP）最短路径场景而设计。用于局部修复的非SR机制超出了本文档的范围。非本地故障在单独的文档[SR-LOOP]中得到解决。
术语“拓扑独立”（Topology Independent，TI）描述了提供在所有网络拓扑中均有效的无环备份路径的功能。与LFA[RFC5286]和RLFA[RFC7490]相比，这提供了重大改进，LFA[RFC5286]和RLFA[RFC7490]无法在[RFC6571]中描述的某些拓扑中提供完整的保护覆盖。
当网络在故障后重新收敛时，由于不同路由器的转发表暂时不一致，可能会形成微环路[RFC5715]。如果确定微环是部署中的一个重要问题，则应实施合适的无环收敛方法，例如[RFC5715]、[RFC6976]、[RFC8333]或[SR-LOOP]中描述的方法之一。
TI-LFA在检测到其直接链路之一出现故障后，在本地修复点（PLR）进行本地操作。因此，此本地操作不会影响：
* 在分布式IGP收敛期间可能形成也可能不形成的微环路，如[RFC5715]中所述：
- 这些微环路发生在指向目的地的路由上，且不经过为TI-LFA配置的路径。根据[RFC5714]，这种微环路的形成可以阻止流量到达PLR，从而绕过为重新路由而建立的TI-LFA路径。
* 当先前失效的链接恢复功能时，可能会或可能不会形成微循环。
TI-LFA路径从PLR检测到本地链路故障的那一刻起就被激活，并保持有效，直到PLR处完全实现IGP收敛。因此，它们不易受到因这些路径所经过的不同节点之间的IGP收敛时间变化而可能出现的微环路的影响。这可确保稳定且可预测的路由环境，最大限度地减少通常与异步网络行为相关的中断。然而，PLR处的早期（相对于其他节点）IGP收敛以及TI-LFA路径的连续“早期”释放可能会导致微循环，特别是如果这些路径是使用本文档第5.2、5.3或5.4节中描述的方法计算的。防止此类微环路的可能方法之一是局部收敛延迟[RFC8333]。
TI-LFA程序是链路或节点故障时任何微环路避免程序应用的补充：
* 链路或节点故障需要采取一些紧急措施来恢复通过故障资源的流量。TI-LFA路径是预先计算和预先安装的；因此，它们适合紧急恢复。
* 微环路避免程序中使用的路径通常无法预先计算。
对于网络中的每个目的地（由IGP指定），TI-LFA为每个受保护的目的地预安装一个备份转发条目，准备在检测到用于到达目的地的链路故障时激活。TI-LFA在发生以下任一情况时提供保护：单链路故障、单节点故障或单共享风险链路组（Shared Risk Link Group，SRLG）故障。在链路故障模式下，假设链路发生故障，目的地将受到保护。在节点保护模式下，假设连接到主链路（参见第2节）的邻居发生故障，则目标受到保护。在SRLG保护模式中，假设与主链路共享命运的一组已配置链路发生故障（例如，共享公共传输管道的线卡或一组链路），则目标受到保护。
本文档中概述的保护技术仅限于保护链路状态IGP区域内的链路、节点和SRLG。保护域出口路由器和/或连接到另一个路由域的链路超出了本文档的范围。
通过利用SR，TI-LFA无需与远程节点建立目标标签分发协议会话，即可利用远程无环替代（Remote Loop-Free Alternates，RLFA）[RFC7490][RFC7916]或定向无环替代（Directed Loop-Free Alternates，DLFA）[IPFRR-TUNNELS]的优势。所有所需的段标识符（Segment Identifiers，SID）都存在于IGP的链路状态数据库（Link State Database，LSDB）中。因此，不再需要优先选择LFA而不是RLFA或DLFA，也不需要最小化RLFA或DLFA修复节点的数量。
利用SR还无需在网络内建立额外的状态来强制实施显式快速重新路由（FRR）路径。这使得节点无需维护补充状态，并使运营商无需仅仅为了扩大保护范围而实施附加协议或协议会话。
TI-LFA还具有以下优势：能够提供一条备份路径，该路径遵循考虑到特定故障的预期收敛后路径，从而减少了影响备份路径选择的本地配置策略的需要[RFC7916]。以无环方式表达预期收敛后路径的最简单方法是将其编码为邻接段列表。然而，这可能会创建一个长段列表，某些硬件可能无法对其进行编程。TI-LFA的挑战之一是通过组合邻接段和节点段来编码预期的收敛后路径。每个实现可以独立开发自己的算法来优化有序段列表。本文档概述了适用于构建SR备份路径的基本概念以及相关的数据平面过程。附录A包含与收敛后路径相关的TI-LFA一些方面的更详细描述。
本文档的结构如下：
* 第2节定义了文档中使用的主要符号。它们符合[RFC5714]。
* 第3节定义了TI-LFA备份路径计算的主要原理。
* 第4节建议计算第2节中定义的P空间和Q空间属性，以针对位于通往受保护目的地的收敛后路径上的节点的特定情况。
* 第5节描述了如何使用第4节中定义的属性计算保护列表，该保护列表对通往目的地的无环收敛后路径进行编码。
* 第6节定义了PLR要应用的段操作，以确保与修复节点的转发状态一致。
* 第7节讨论特定于数据平面的方面。
* 第8节讨论TI-LFA和SR算法之间的关系。
* 第9节概述了在修复列表（Repair List，RL）中使用邻接段时需要考虑的某些事项。
* 第10节讨论安全考虑因素。
* 附录A强调了在FRR期间使用预期收敛后路径的优点。
* 附录B总结了在实际服务提供商和大型企业网络环境中实施本文档中详细介绍的算法的测量结果。提供了有关修复路径所使用的SID数量的实际测量结果。
2、术语
2.1、缩写和符号
DLFA: Directed Loop-Free Alternate，定向无环替代
FRR: Fast Reroute，快速重新路由
IGP: Interior Gateway Protocol，内部网关协议
LFA: Loop-Free Alternate，无环替代
LSDB: Link State Database，链路状态数据库
PLR: Point of Local Repair，本地修复点
RL: Repair List，修复清单
RLFA: Remote Loop-Free Alternate，远程无环替代
SID: Segment Identifier，段标识符
SPF: Shortest Path First，最短路径优先
SPT: Shortest Path Tree，最短路径树
SR: Segment Routing，分段路由
SRLG: Shared Risk Link Group，共享风险链接组
TI-LFA: Topology Independent Loop-Free Alternate，拓扑独立的无环替代
本文档中使用的主要符号定义如下：
* 术语“旧”和“新”拓扑分别指所考虑的故障之前和之后的LSDB状态。
* SPT_old(R)是网络初始状态下以节点R为根的SPT。
* SPT_new(R, X)是资源X失效后网络状态下以节点R为根的SPT。
* PLR是在检测到直连链路、链路集和/或节点中的故障后应用快速流量恢复的路由器。
* 与[RFC7490]类似，TI-LFA使用P空间和Q空间的概念。
* 路由器R相对于资源X（例如，链路S-F、节点F或SRLG）的P空间P(R, X)是使用收敛前最短路径从R可达的路由器集合，而没有任何这些路径（包括等成本路径分割）经过X。P节点是属于P空间的节点。
* 考虑路由器R和资源X的邻居集合。从该集合中排除使用X可从R到达的邻居。节点R关于资源X的扩展P空间P'(R, X)是该简化邻居集合中关于资源X的邻居P空间的并集。
* 路由器R相对于资源X的Q空间Q(R, X)是在没有任何路径（包括等价路径分叉）经过X的情况下可以到达R的路由器的集合。Q节点是属于Q空间的节点。
* EP(P, Q)是从节点P到节点Q的显式SR路径。
* 主接口和主出接口是根据IGP链路状态协议到目的地的出接口之一。
* 主链路是连接到主接口的链路。
* Adj-SID(S-F)是从节点S到节点F的邻接段。
2.2、本文档中使用的约定
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14[RFC2119][RFC8174]中的描述进行解释。首都，如此处所示。
3、基本原理
计算修复路径的基本算法是预先计算SPT_new(R, X)，并且对于每个目的地，将修复路径编码为无环段列表。提供无环段列表的一种方法是仅使用邻接SID。但是，此方法可能会创建非常长的SID列表，由于最大SID深度（Maximum SID Depth，MSD）限制，硬件可能无法处理该列表。
实现可以自由地使用任何本地优化，通过组合Node-SID和邻接SID来提供更小的段列表。此外，Node-SID的使用允许在备份路径上最大化ECMP。这些优化超出了本文档的范围；但是，后续部分提供了有关如何利用P空间和Q空间来优化段列表大小的一些指导。
4、P空间和Q空间与收敛后路径相交
定义遵循预期收敛后路径的SR路径的挑战之一是减小段列表的大小。为了减少此段列表，实现可以确定沿从PLR到受保护目的地的预期收敛后路径的节点的P空间/扩展P空间和Q空间属性（在[RFC7490]中定义），并在它们不相邻时计算从P到Q的SR显式路径。这些属性将在第5节中用于计算TI-LFA RL。
4.1、资源X在收敛后路径上的扩展P空间属性计算
目标是确定从PLR R到目的地D的收敛后路径上的哪些节点位于R的关于资源X的扩展P空间中（其中X可以是与PLR或PLR的邻居节点相邻的一条链路或一组链路）。
这可以通过以下方式找到：
* 计算P'(R, X)时排除不在收敛后路径上的邻居，则
* 假设X发生故障，将属于从 R到D的收敛后路径的节点集与P'(R, X)相交。
4.2、资源X在收敛后路径上的Q空间属性计算
目标是确定从PLR R到目的地D的收敛后路径上的哪些节点位于关于资源X的目的地D的Q空间中（其中X可以是与PLR相邻的一条链路或一组链路，或者是PLR的邻居节点）。
这可以通过将属于从 R到D的收敛后路径的节点集与Q(D, X)相交来找到，假设X发生故障。
4.3、计算Q空间时的缩放注意事项
[RFC7490]提出了关于计算每个目的地的Q空间的扩展问题。如果实现尝试为网络中的每个目的地计算反向最短路径树（SPT）[RFC7490]以确定Q空间，类似的问题可能会影响TI-LFA计算。将由每个实现来确定优化的扩展性和准确性之间的良好权衡。
5、TI-LFA修复路径
TI-LFA修复路径由传出接口和根据所使用的数据平面插入到SR标头的段列表（修复列表（RL））组成。RL对到达目的地的显式（并且可能是收敛后）路径进行编码，这避免了受保护的资源X。同时，只要FIB的状态根据链路状态IGP进行编程，无论属于显式路径的节点上的FIB的状态如何，都保证RL是无环的。因此，PLR和网络中任何其他路由器之间不需要任何协调或消息交换。
通过将P(S, X)和Q(D, X)与到D的收敛后路径相交，并计算从P(S, X)中的节点P到Q(D, X)中的节点Q的显式基于SR的路径EP(P, Q)（当这些节点沿收敛后路径不相邻时）来找到TI-LFA修复路径。TI-LFA RL一般表示为（Node-SID(P)，EP(P, Q)）。
***** : 具有高度量（1k）的链接 —– : 具有度量1的链接
图1：采用TI-LFA的拓扑示例
例如，在图1中，考虑到节点N1发生故障，重点是从S到D的TI-LFA备份。
* 首先，计算P(S, N1)并得出[N3, N2, R1]。
* 然后，计算Q(D, N1)并得出[R3]。
* 考虑到N1的失效，从S到D的预期收敛后路径为
* P(S, N1)与PCPath的交集为[N2, R1]。由于R1是PCPath中更深层的下游节点，因此可以假设将其用作P节点（这是一个示例，并且实现可以使用不同的策略来选择P节点）。
* Q(D, N1)与PCPath的交集为[R3]，因此选取R3作为Q节点。然后按照PCPath（R1 -> R2 -> R3）： 计算从R1（P节点）到R3（Q节点）的SR显式路径。
结果，考虑到节点N1的故障，目的地D的S的TI-LFA RL为：
大多数情况下，TI-LFA RL具有更简单的形式，如以下部分所述。附录B提供了显式路径中SID数量的统计信息，以防止出现各种故障。
5.1、使用直接邻居的FRR路径
当P(S, X)和Q(D, x)中存在直接邻居，并且到该直接邻居的链路位于收敛后路径上时，出接口设置为该邻居，并且修复段列表为空。
这与收敛后LFA FRR修复相当。
5.2、使用PQ节点的FRR路径
当远程节点R位于P(S, X)和Q(D, X)中并且位于收敛后路径上时，RL由到R的单个节点段组成，并且出接口设置为用于到达R的出接口。
这与收敛后RLFA修复隧道相当。
5.3、使用相邻P节点和Q节点的FRR路径
当P(S, X)中的节点P和Q(D, x)中的节点Q，并且两者都在收敛后路径上并且彼此相邻时，RL由两段组成：到P的节点段（首先要处理），然后是从P到Q的Adjacency段。
这与收敛后定向无环替代（DLFA）修复隧道相当。
5.4、沿收敛后路径连接远程P和Q节点
在某些情况下，收敛后路径上不存在相邻的P和Q节点。如第3节中所述，邻接SID列表可用于对P和Q之间的路径进行编码。但是，PLR可以执行额外的计算来计算表示从P到Q的无环径的更短的段列表。如何完成这些计算超出了本文档的范围，并留待实现。
6、为SR段构建TI-LFA修复列表
以下部分描述如何使用[RFC8402]中定义的术语构建RL。本节中描述的过程同样适用于MPLS分段路由（Segment Routing over MPLS，SR-MPLS）和IPv6分段路由（Segment Routing over IPv6，SRv6）数据平面，而数据平面特定的注意事项在第7节中描述。
本节说明保护路由器S在数据包S-F的主要传出接口发生故障时处理数据包的活动段的过程。主出接口发生故障的原因可能有多种，例如链路故障、邻居节点故障等。
6.1、活动段是节点段
SR标头上的活动段必须保持不变，并且必须添加RL。活动段成为RL之后的第一个段。添加RL的方式取决于所使用的数据平面（参见第7节）。
6.2、活动段是邻接段
本节定义S对通过已启用保护的活动邻接段S-F接收到的任何数据包应用的FRR行为。由于已为分段S-F启用保护并在IGP中发出信号（例如，使用[RFC8667]和[RFC8665]的协议扩展），因此使用此分段的任何SR策略的计算器都知道，如果发生S-F故障，它可能会暂时重新路由出S-F。
邻接段S-F链路保护的最简单方法是创建将流量传送到F的RL。为此，需要执行一个或多个“PUSH”操作。如果RL在避开S-F的同时终止于F，则S仅推送RL的段。否则，S推送F的节点段，然后推送RL的节点段。有关“NEXT”和“PUSH”操作的详细信息，请参阅[RFC8402]。
这种方法将流量合并回邻接段远端，其优点是可以将尽可能多的流量保留在故障前的路径上。当涉及SR策略并且需要严格遵守策略时，应优先考虑端到端的保护（超出本文档的范围）而不是上述的本地修复机制。
但请注意，当SR源节点使用流量工程（Traffic Engineering，TE）时，PLR通常不可能知道一旦检测到故障，源节点将选择什么收敛后路径，因为TE路径的计算是本地事务，取决于PLR可能不知道的约束。因此，在PLR上应用的任何方法都不能保证保护遵循收敛后路径。
活动段后面跟随另一个邻接段的情况与它后面跟随节点段的情况不同。以下小节提供了针对各种情况的修复技术。
6.2.1、保护[邻接、邻接]段列表
如果列表中的下一个段是邻接段，则数据包必须传送到F。
为此，S必须对Adj-SID(S-F)应用“NEXT”操作，然后应用一个或多个“PUSH”操作。如果RL在避开S-F的同时终止于F，则S仅推送RL的段。否则，S推送F的节点段，然后推送RL的节点段。有关“NEXT”和“PUSH”操作的详细信息，请参阅[RFC8402]。
当S-F失效时，到达S且其段列表匹配[adj-sid(S-F)、adj-sid(F-M)、…]的数据包将因此在S中留下匹配[RL(F)、node(F)、adj-sid(F-M)、…]的段列表，其中RL(F)是目的地F的RL。
6.2.2、保护[邻接、节点]段列表
如果堆栈中的下一个段是节点段（例如节点T），则数据包上的段列表匹配[adj-sid(S-F), node(T), …]。
在这种情况下，S必须对与S-F相关的邻接段应用“NEXT”操作，然后是RL的“PUSH”，将流量重定向到节点Q，该节点到节点段T的路径不受故障影响。
当S-F发生故障时，到达S且段列表匹配[adj-sid(S-F)，node(T)，…]的数据包将离开S，且段列表匹配[RL(Q)，node(T)，…]。
7、数据平面特定的注意事项
7.1、MPLS数据平面注意事项
[RFC8660]中描述了SR的MPLS数据平面。
使用MPLS数据平面创建RL时，适用以下数据平面行为：
-
如果活动段是已通过倒数第二跳弹出发出信号的节点段，并且RL以终止于活动段的倒数第二个节点的邻接段结束，则必须在推送RL之前弹出活动段。
-
如果活动段是节点段，但不满足1. 中的其他条件，则必须弹出活动段，然后使用根据Q的段路由全局块（Segment Routing Global Block，SRGB）计算的标签值再次压入活动段，其中Q是RL的端点。最后，必须压入RL。
7.2、SRv6数据平面注意事项
SRv6数据平面和编程指令分别在[RFC8754]和[RFC8986]中描述。
TI-LFA路径计算算法与SR-MPLS数据平面中的相同。但请注意，邻接SID通常是全局路由的。在这种情况下，不需要在邻接SID之前添加前缀SID[RFC8402]，并且生成的RL可能更短。
如果流量在传输节点受到保护，则会在数据包上添加SRv6 SID列表以应用RL。RL的添加遵循[RFC8986]第5节中指定的头端行为。
如果流量在SR分段端点节点受到保护，则首先执行分段端点数据包处理。然后，该数据包将像传输数据包一样受到保护。
8、TI-LFA和SR算法
SR允许操作员将算法绑定到Prefix-SID（如[RFC8402]中定义）。算法值指示如何计算到前缀的路径。SR默认算法称为“最短路径”算法。SR默认算法允许运营商使用本地策略覆盖IGP最短路径。当TI-LFA使用与默认算法关联的Node-SID时，无法保证路径不会出现环路，因为本地策略可能会覆盖预期的IGP路径。由于本地策略是由运营商定义的，因此该运营商有责任确保部署的策略不会影响TI-LFA部署。应该指出的是，这种情况在今天的RLFA等现有机制中已经可能发生。
[RFC9350]定义了与Prefix-SID关联的灵活算法框架。灵活的算法允许用户将约束路径关联到Prefix-SID，而不是使用常规IGP最短路径。实现可以支持TI-LFA来保护与灵活算法关联的NodeSID。在这种情况下，实现应该使用绑定到灵活算法（使用灵活算法定义）的约束SPF算法，而不是在TI-LFA计算期间发生的所有SPF/反向SPF计算中使用常规Dijkstra，而不是基于常规SPF计算预期的收敛后路径。这包括P空间和Q空间以及收敛后路径的计算。此外，实现应该仅使用绑定到灵活算法的Node-SID/Adj-SID和/或常规SPF的未受保护的Adj-SID来构建RL。使用常规Dijkstra进行TI-LFA计算或使用建议以外的SID构建修复路径并不能确保FRR期间经过TI-LFA修复路径的流量遵守灵活算法约束。
9、修复列表中邻接段的使用
TI-LFA计算的段的RL可能包含一个或多个邻接段。邻接段可以是受保护的，也可以是不受保护的。
图2
在图2中，除了R2-R7、R7-R8、R8-R4、R7-R9的度量为1000之外，所有度量都等于1。将R2视为PLR，以防止节点R3因流量S->D发生故障，由R2计算的RL将是[adj-sid(R7-R8), adj-sid(R8-R4)]，出接口将到R7。如果R3发生故障，R2将RL推送到传入数据包上至D。在FRR期间，如果R7-R8发生故障并且TI-LFA为AdjSID(R7-R8)选择了受保护的邻接段，则R7将按照第6节中定义的过程将附加RL推送到数据包上。
为了避免这种双重FRR激活的可能性，TI-LFA的实现可以在构建RL时仅选择未受保护的邻接段。然而，值得注意的是，FRR通常旨在针对单个预先计划的故障提供保护。如果发生的故障比预期更严重或发生多次故障，则不保证FRR能够正常工作。在这种情况下，快速IGP收敛对于尽快恢复流量仍然很重要。
10、安全考虑
本文档中描述的技术是路由器的内部功能，可以保证在直接连接的链路或节点发生故障时恢复流量所需的时间上限。由于这些技术尽快将流量引导至收敛后路径，因此可以最大限度地减少与本地故障相关的中断，这可以被视为适度的安全增强。该保护机制不保护外部目的地，而是为路由域内部的目的地提供快速恢复。
[RFC5286]和[RFC7490]中描述的安全注意事项适用于本文档。同样，由于本文档中描述的解决方案基于SR技术，因此读者应该了解与该技术（参见[RFC8402]）及其数据平面实例（参见[RFC8660]、[RFC8754]和[RFC8986]）相关的安全注意事项。然而，本文档并没有引入额外的安全问题。
11、IANA考虑因素
本文档没有IANA行动。
12、参考文献
12.1、规范性参考文献
[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>.[RFC7916]Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., and P. Sarkar, "Operational Management of Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, July 2016, <https://www.rfc-editor.org/info/rfc7916>.[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>.[RFC8402]Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.[RFC8660]Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.[RFC8754]Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.[RFC8986]Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.
12.2、参考资料
[IPFRR-TUNNELS]Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", Work in Progress, InternetDraft, draft-bryant-ipfrr-tunnels-03, 16 November 2007, <https://datatracker.ietf.org/doc/html/draft-bryant-ipfrrtunnels-03>.[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>.[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>.[RFC5715]Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2010, <https://www.rfc-editor.org/info/rfc5715>.[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, <https://www.rfc-editor.org/info/rfc6571>.[RFC6976]Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P., and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 2013, <https://www.rfc-editor.org/info/rfc6976>.[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, <https://www.rfc-editor.org/info/rfc7490>.[RFC8333]Litkowski, S., Decraene, B., Filsfils, C., and P. Francois, "Micro-loop Prevention by Introducing a Local Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March 2018, <https://www.rfc-editor.org/info/rfc8333>.[RFC8665]Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.[RFC8667]Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.[RFC9256]Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.[RFC9350]Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.[SR-LOOP]Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., Francois, P., and P. Psenak, "Loop avoidance using Segment Routing", Work in Progress, Internet-Draft, draftbashandy-rtgwg-segment-routing-uloop-17, 29 June 2024, <https://datatracker.ietf.org/doc/html/draft-bashandyrtgwg-segment-routing-uloop-17>.
附录A、FRR期间使用预期收敛后路径的优点
[RFC7916]提出了使用LFA或RLFA时的几个操作注意事项。[RFC7916]的第3节介绍了通过与低带宽链路连接的提供商边缘（PE）路由器来保护两个核心路由器之间的高带宽链路的情况。这种情况下，当FRR备份路径激活时，可能会出现拥塞。[RFC7916]引入了一个本地策略框架，让运营商根据自己的要求手动调整最佳替代选择。
从网络容量规划的角度来看，为了简单起见，通常假设如果链路L在特定节点X上发生故障，则L上消耗的带宽将分布在X的剩余一些链路上。剩余的使用链路由考虑到链路L发生故障的IGP路由确定（我们假设流量使用从节点X开始的收敛后路径）。在图3中，我们考虑一个网络，除了PE1、PE2和PE3使用的链路上的度量为1000之外，所有度量都等于1。一种简单的网络容量规划方法是考虑如果链路L(X-B)发生故障，实际流经L的流量将分布在X（X-H，X-D，X-A）的剩余链路上。考虑到IGP度量，实际上只能使用X-H和X-D来承载流经链路L的流量。因此，链路X-H和X-D的带宽根据该规则来调整。我们应该观察到这种容量规划政策是有效的；然而，它并不完全准确。
图3中，考虑到流量来源仅来自PE1和PE4，当链路L发生故障时，根据节点的收敛速度，X可能会将其到远端PE的转发表项重新路由到X-H或X-D上；然而，在类似的时间范围内，PE1也会将其流量的子集（目的地为PE2的子集）重新路由到其标称路径之外，从而减少X接收的流量数量。前面提出的容量规划规则存在网络规模过大的缺点；然而，它可以防止任何瞬时拥塞（例如，当X在PE1之前重新路由流量时）。
图3
基于这个假设，为了便于FRR的运行并限制本地FRR策略的实施，在FRR阶段，PLR可以将流量引导到其期望的收敛后路径上。在我们的例子中，当链路L出现故障时，X将去往PE3和PE2的流量切换到收敛后路径上。这完全符合之前提出的容量规划规则，也符合X可能在PE1（或任何其他上游路由器）之前收敛并可能将X-B流量传播到以X为根的收敛后路径上的事实。
需要注意的是，某些网络可能具有不同的容量规划规则，导致在X-H和X-D链路上分配较少的带宽。在这种情况下，在FRR期间使用以X为根的收敛后路径可能会在X-H和X-D链路上引入一些拥塞。然而，需要注意的是，即使没有激活FRR，也可能会发生暂时性拥塞，例如，当X在上游路由器之前收敛时。如果不适合使用基于PLR的聚合后路径，运营商仍然可以自由使用[RFC7916]中定义的策略框架。
读者应该知道，FRR保护是预先计算备份路径，以防止特定类型的故障（链路、节点或SRLG）。当使用收敛后路径作为FRR备份路径时，计算出的收敛后路径是考虑我们要防止的故障的路径。这意味着FRR正在使用预期的收敛后路径，并且如果发生的故障与FRR所防止的故障不同，则该预期的收敛后路径实际上可能与所使用的收敛后路径不同。例如，如果运营商实施了针对节点故障的保护，则FRR期间使用的预期收敛后路径将是考虑到节点已故障的路径。然而，即使单个链路发生故障或一组链路发生故障（而不是整个节点），也会使用节点保护后收敛路径。结果是FRR期间使用的路径相对于实际发生的故障而言并不是最佳的。
另一个需要考虑的因素如下：虽然仅使用节点段（例如，使用最短路径的PE到PE流量）对SR流量使用预期的收敛后路径具有一些优势，但当涉及SR策略[RFC9256]时，这些优势会减弱。SR策略中使用的段列表被计算为遵守在头端本地定义或在控制器集中定义的一组路径约束。TI-LFA无法意识到此类路径约束，并且没有理由期望保护该段列表中的一个段的TI-LFA备份路径遵守这些约束。当使用SR策略并且运营商希望有一条仍遵循策略要求的备份路径时，该备份路径应作为入口节点（或中央控制器）中SR策略的一部分进行计算，并且SR策略不应依赖于本地保护。另一种选择可能是使用灵活算法[RFC9350]来表达约束集，并使用与灵活算法关联的单个节点段来到达目的地。当使用与灵活算法关联的节点段时，TI-LFA通过应用适当的约束集不断提供最佳备份。TI-LFA和SR算法之间的关系详见第8节。
附录B、基于真实网络拓扑的分析
本节介绍对真实服务提供商和大型企业网络拓扑进行的分析。分析的目的是评估当使用本文档中描述的机制来防止本文档范围内的故障场景时，显式路径中所需的SID数量。本节中描述的段数适用于在MPLS转发平面上实例化SR。
下面的测量结果表明，对于链路和本地SRLG保护，1个SID或更少的修复路径可提供超过99% 的覆盖范围。对于节点保护，2个SID或更少的修复路径可产生99% 的覆盖率。
下面的表1列出了我们测量中使用的网络的特性。链接的数量是指“双向”链接（不是图中的有向边）的数量。测量进行如下：
* 对于每个网络，应用本文档中描述的算法来保护所有前缀免受链路、节点和本地SRLG故障的影响。
* 对于每个前缀，记录修复路径使用的SID数量。
* SID数量百分比列于表2、3、4、5、6和7中。
表1：数据集定义
本节的其余部分介绍了对实际拓扑进行的测量。我们使用的约定如下：
* 0 SID：计算的修复路径从直接连接的邻居开始，该邻居也是无环替代；在这种情况下，无需使用额外的SID显式路由流量。第5.1节描述了这种情况。
* 1 SID：修复节点为PQ节点；在这种情况下，只需要1个SID就可以保证无环径。第5.2节介绍了这种情况。
* 2个或更多SID：修复路径由2个或更多SID组成，如第5.3和5.4节中所述。我们不单独讨论2个SID的情况（第5.3节），因为结果没有粒度。此外，我们将Node-SID + Adj-SID和Node-SID + Node-SID视为相同，因为它们从数据平面的角度来看没有区别。
下面的表2和表3总结了链路保护所需的SID数量的测量结果。
表2：链路保护（修复规模分布）
表3：链路保护（修复规模累积分布）
表4和表5总结了本地SRLG保护所需的SID数量的测量结果。
表4：本地SRLG保护（修复规模分布）
表5：本地SRLG保护（修复规模累积分布）
其余两个表总结了节点保护所需的SID数量的测量结果。
表6：节点保护（修复规模分布）
表7：节点保护（修复规模累积分布）
致谢
作者要感谢Les Ginsberg、Stewart Bryant、Alexander Vainsthein、Chris Bowers、Shraddha Hedge、Wes Hardaker、Gunter Van de Velde和John Scudder提出的宝贵意见。
***推荐阅读***
无需公网IPv4！手把手教你配置基于IPv6的WireGuard安全隧道
基于IPv6配置openVPN实战：告别双栈难题，一步打通IPv6隧道！
openVPN进阶技巧：如何实现从服务端反向访问客户端内网？
OpenVPN管理竟能如此简单？实时监控、固定IP、强制下线，运维效率翻倍
OpenVPN管理迎来终极形态：支持6种多因子认证，安全等级拉满，运维效率飙升！
服务器端口不对外开放怎么办？用SSH“秒建”加密隧道，安全访问内部服务
OSPF路由引入的陷阱：为何Ubuntu上静态路由神秘消失？深挖FRR路由分类机制
H3C这个冷门功能Guard路由有什么用？我搭了一套实验环境，发现了它的秘密
为SRv6实验铺路：手把手教你将Ubuntu中的FRR升级至最新v10.5稳定版
真白嫖攻略：如何将免费的运营商云电脑，变成高性能远程开发/测试服务器？
Windows系统VPN老掉线？我教你轻松实现VPN开机自启、断线重连，7×24小时稳定守护
256台H100服务器的RoCEv2无损与全互联算力网络建设方案
2048卡H100算力中心HPE Alletra 4140存储集群部署手册
2048卡H100算力中心H3C R5500 G6服务器集群部署手册
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：铁军哥 衡水石头哥 衡水石头哥《使用分段路由实现独立于拓扑的快速重新路由》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论