RFC 9855

Topology Independent Fast Reroute Using Segment Routing

📅 published October 2025, from ietf

RFC 9855: Topology Independent Fast Reroute Using Segment Routing ✨

Okay bestie, so this is RFC 9855, published in October 2025 🍂. It's on the Standards Track 🎀, which means it's a real Internet standard and not just a casual idea. The ISSN is 2070-1721. The authors are A. Bashandy (HPE), S. Litkowski and C. Filsfils (Cisco Systems), P. Francois (INSA Lyon), B. Decraene (Orange), and D. Voyer (Bell Canada). Squad goals 👑. The title block doesn't list anything it obsoletes or updates, so there's nothing to mention there.

Abstract 🦋

Okay, so this doc introduces Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR) 🔥. The whole point is to protect node and Adjacency segments inside the Segment Routing (SR) framework, so when something breaks, traffic gets rerouted super fast. 💨

It's built on IP FRR ideas that already work well: LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs) 🧚. TI-LFA takes them further and gives guaranteed coverage in any two-connected network running a link-state IGP 💜.

The part I'm obsessed with is how it picks the FRR path. It sets up protection over the expected post-convergence paths from the Point of Local Repair (PLR) 🫶. Because of that, operators don't have to fiddle around as much with tie-breaks between the different FRR options 😭✨.

Status of This Memo 📜

This is an Internet Standards Track document 🎀.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🌈. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. If you want more on Internet Standards, check out Section 2 of RFC 7841 🧐.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9855 🔗.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🩷

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, bestie 🙈. They spell out your rights and restrictions for this document.

Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Revised BSD License ⚠️.

Table of Contents 🗺️

   1.  Introduction
   2.  Terminology
     2.1.  Abbreviations and Notations
     2.2.  Conventions Used in This Document
   3.  Base Principle
   4.  Intersecting P-space and Q-space with Post-Convergence Paths
     4.1.  Extended P-space Property Computation for a Resource X over
           Post-Convergence Paths
     4.2.  Q-space Property Computation for a Resource X over
           Post-Convergence Paths
     4.3.  Scaling Considerations When Computing Q-space
   5.  TI-LFA Repair Path
     5.1.  FRR Path Using a Direct Neighbor
     5.2.  FRR Path Using a PQ Node
     5.3.  FRR Path Using a P Node and Q Node That Are Adjacent
     5.4.  Connecting Distant P and Q Nodes Along Post-Convergence
           Paths
   6.  Building TI-LFA Repair Lists for SR Segments
     6.1.  The Active Segment Is a Node Segment
     6.2.  The Active Segment Is an Adjacency Segment
       6.2.1.  Protecting [Adjacency, Adjacency] Segment Lists
       6.2.2.  Protecting [Adjacency, Node] Segment Lists
   7.  Data Plane-Specific Considerations
     7.1.  MPLS Data Plane Considerations
     7.2.  SRv6 Data Plane Considerations
   8.  TI-LFA and SR Algorithms
   9.  Usage of Adjacency Segments in the Repair List
   10. Security Considerations
   11. IANA Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Appendix A.  Advantages of Using the Expected Post-Convergence Path
           During FRR
   Appendix B.  Analysis Based on Real Network Topologies
   Acknowledgments
   Contributors
   Authors' Addresses
🚨 Heads up: this paste stops at the Table of Contents. The body, starting at Section 1 (Introduction), wasn't included in what I received, so I haven't rewritten it. Paste the next part and I'll pick up right where we left off 💜.

1. Introduction ✨

okay bestie, this doc is all about a local repair mechanism that uses Segment Routing (SR) to bring back end-to-end connectivity when something breaks right next to you, like a directly connected network component 🔧. It's designed for standard link-state Interior Gateway Protocol (IGP) shortest path setups. Non-SR local repair is totally out of scope 🙅‍♀️, and non-local failures get their own doc, [SR-LOOP] 🧚.

Next up, Topology Independent (TI) means a loop-free backup path that actually works across all network topologies 🦋. That's a huge glow-up from LFA [RFC5286] and RLFA [RFC7490], which can't give complete protection coverage in some topologies, as [RFC6571] explains 💀.

When the network reconverges after a failure, micro-loops [RFC5715] can form because the forwarding tables on different routers are briefly out of sync 🙈. If micro-loops are a real problem in your deployment, then a suitable loop-free convergence method should be implemented, like one of the ones described in [RFC5715], [RFC6976], [RFC8333], or [SR-LOOP] 💖.

TI-LFA works locally at the Point of Local Repair (PLR) the moment it detects a failure on one of its direct links 🎀. So this local operation does not influence:

  • Micro-loops that may or may not form during the distributed IGP convergence described in [RFC5715]:
    • These micro-loops happen on routes heading toward the destination that don't go through TI-LFA paths. According to [RFC5714], forming these micro-loops can stop traffic from ever reaching the PLR, so it bypasses the TI-LFA paths set up for rerouting 😭.
  • Micro-loops that may or may not develop when the previously failed link comes back to life 🌈.

TI-LFA paths switch on from the instant the PLR detects a local link failure and stay active until IGP convergence at the PLR is fully done ⭐. That means they're not vulnerable to micro-loops caused by different convergence times on the nodes those paths travel through. It's giving stable and predictable routing with way less of that asynchronous chaos 👑.

Here's the tea though: if the PLR converges early (compared to the other nodes) and releases its TI-LFA paths early, micro-loops can happen anyway 😬. This is especially true if those paths were computed using the methods in Sections 5.2, 5.3, or 5.4 of this document. One possible way to prevent these micro-loops is local convergence delay [RFC8333] 🫶.

TI-LFA procedures work alongside any micro-loop avoidance procedures for link or node failure 💅:

  • Link or node failure needs some urgent action to restore the traffic that was going through the failed resource 🚨. TI-LFA paths are pre-computed and pre-installed, which makes them perfect for urgent recovery ✨.
  • The paths used in micro-loop avoidance procedures typically can't be pre-computed 🙃.

For each destination (as specified by the IGP) in the network, TI-LFA pre-installs a backup forwarding entry for each protected destination 🌸. That entry is ready to activate once the failure of a link used to reach that destination is detected. TI-LFA protects against any one of these: a single link failure, a single node failure, or a single Shared Risk Link Group (SRLG) failure 🔥.

  • In link failure mode, the destination is protected by assuming the link has failed.
  • In node protection mode, the destination is protected by assuming that the neighbor connected to the primary link (see Section 2) has failed.
  • In SRLG protecting mode, the destination is protected by assuming that a configured set of links sharing fate with the primary link has failed. Think a linecard, or a bunch of links sharing a common transmission pipe 🍓.

Protection techniques in this document are limited to protecting links, nodes, and SRLGs inside a link-state IGP area 🏡. Protecting domain exit routers and/or links attached to another routing domain is beyond the scope of this document 🙅‍♀️.

By using SR, TI-LFA doesn't need Targeted Label Distribution Protocol sessions with remote nodes to get the benefits of Remote Loop-Free Alternates (RLFAs) [RFC7490] [RFC7916] or Directed Loop-Free Alternates (DLFAs) [IPFRR-TUNNELS] 🧠. All the Segment Identifiers (SIDs) it needs are already in the Link State Database (LSDB) of the IGP 🗂️. So there's no longer a need to prefer LFAs over RLFAs or DLFAs, and no need to minimize the number of RLFA or DLFA repair nodes. Iconic, honestly 👑.

Using SR also means you don't need extra state in the network to enforce explicit Fast Reroute (FRR) paths 🦋. The nodes don't have to keep supplementary state, and the operator doesn't have to add extra protocols or protocol sessions just to boost protection coverage 💜.

TI-LFA also gives you a backup path that follows the expected post-convergence path for a particular failure 🎯. That means less need for locally configured policies that influence backup path selection [RFC7916] 🙌. The easiest way to express the expected post-convergence path in a loop-free way is to encode it as a list of Adjacency segments. BUT, that can create a long segment list that some hardware can't program 😩. So one of the challenges of TI-LFA is encoding the expected post-convergence path by combining Adjacency segments and node segments 🧩. Each implementation can independently develop its own algorithm for optimizing that ordered segment list 🛠️.

This document outlines the fundamental concepts for building the SR backup path, along with the related data plane procedures 📚. Appendix A has a more detailed look at some of the post-convergence path aspects of TI-LFA 🌟.

This document is structured as follows:

  • Section 2 defines the main notations used in the document. They are in line with [RFC5714].
  • Section 3 defines the main principles of TI-LFA backup path computation.
  • Section 4 suggests computing the P-space and Q-space properties defined in Section 2 for the specific case of nodes lying over the post-convergence paths towards the protected destinations.
  • Section 5 describes how to compute protection lists that encode a loop-free post-convergence path towards the destination, using the properties defined in Section 4.
  • Section 6 defines the segment operations the PLR applies to stay consistent with the forwarding state of the repair node.
  • Section 7 discusses aspects that are specific to the data plane.
  • Section 8 discusses the relationship between TI-LFA and the SR algorithm.
  • Section 9 gives an overview of certain considerations needed when Adjacency segments are used in a Repair List (RL).
  • Section 10 discusses security considerations 🔐.
  • Appendix A highlights the advantages of using the expected post-convergence path during FRR.
  • Appendix B summarizes measurements from implementing the algorithms in this document within actual service provider and large enterprise network environments 📊. It presents real-life measurements of the number of SIDs utilized by repair paths.

2. Terminology 📖

2.1. Abbreviations and Notations

Here's the abbreviation squad 💅:

  • 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

And now the main notations, bestie 🎀:

  • The terms "old" and "new" topologies refer to the LSDB state before and after the considered failure 🕰️.
  • SPT_old(R) is the SPT rooted at node R in the initial state of the network.
  • SPT_new(R, X) is the SPT rooted at node R in the state of the network after the resource X has failed.
  • The PLR is the router that applies fast traffic restoration after detecting a failure in a directly attached link, set of links, and/or node ⚡.
  • Similar to [RFC7490], the concept of P-space and Q-space is used for TI-LFA 🌗.
  • The P-space P(R, X) of a router R with regard to a resource X (e.g., a link S-F, a node F, or an SRLG) is the set of routers reachable from R using the pre-convergence shortest paths, without any of those paths (including equal-cost path splits) transiting through X. A P node is a node that belongs to the P-space 🧁.
  • Consider the set of neighbors of a router R and a resource X. Exclude from that set the neighbors that are reachable from R using X. The extended P-space P'(R, X) of a node R with regard to a resource X is the union of the P-spaces of the neighbors in that reduced set, with regard to the resource X 🧮.
  • The Q-space Q(R, X) of a router R with regard to a resource X is the set of routers from which R can be reached without any path (including equal-cost path splits) transiting through X. A Q node is a node that belongs to the Q-space 🫧.
  • EP(P, Q) is an explicit SR path from a node P to a node Q 🛤️.
  • The primary interface and primary outgoing interface are one of the outgoing interfaces towards a destination, according to the IGP link-state protocol 🚪.
  • The primary link is a link connected to the primary interface 🔗.
  • The Adj-SID(S-F) is the Adjacency segment from node S to node F 👯.

2.2. Conventions Used in This Document

Okay, this part is super important, so pay attention 👀🔥. 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 📜✨. Lowercase versions are just regular words, so no drama there 💖.

3. Base Principle 🧱

The basic algorithm for computing the repair path is to pre-compute SPT_new(R, X) and, for each destination, encode the repair path as a loop-free segment list 🧮. One way to get a loop-free segment list is to use Adjacency SIDs only. However, this approach may create very long SID lists that hardware may not be able to handle, because of Maximum SID Depth (MSD) limitations 😵‍💫.

An implementation is free to use any local optimization to produce smaller segment lists by combining Node-SIDs and Adjacency SIDs 🪄. Also, using Node-SIDs allows for maximizing ECMPs over the backup path 🌈. These optimizations are out of scope for this document. The subsequent sections do give some guidance on how to leverage P-spaces and Q-spaces to optimize the size of the segment list, so stay tuned 🧚‍♀️💜.

4. Intersecting P-space and Q-space with Post-Convergence Paths ✨

okay so the big challenge with defining an SR path that follows the expected post-convergence path is keeping the segment list small 📉 🫶 an implementation MAY work out the P-space / extended P-space and Q-space properties (defined in [RFC7490]) of the nodes on that path, from the PLR to the protected destination, and then compute an SR explicit path from P to Q when they aren't adjacent. Section 5 is where those properties get used to compute the TI-LFA RL 💜

4.1. Extended P-space Property Computation for a Resource X over Post-Convergence Paths 🦋

The goal here is to figure out which nodes on the post-convergence path from the PLR R to the destination D are in the extended P-space of R with regard to resource X. X can be a link or a set of links adjacent to the PLR, or a neighbor node of the PLR 🌸

This is found by:

  • excluding neighbors that are not on the post-convergence path when computing P'(R, X), then
  • intersecting the set of nodes belonging to the post-convergence path from R to D, assuming the failure of X, with P'(R, X).

4.2. Q-space Property Computation for a Resource X over Post-Convergence Paths 🎀

Same vibe, different target 🎯 This time we want the nodes on the post-convergence path from the PLR R to the destination D that are in the Q-space of destination D with regard to resource X. Again, X can be a link or a set of links adjacent to the PLR, or a neighbor node of the PLR.

This can be found by intersecting the set of nodes belonging to the post-convergence path from R to D, assuming the failure of X, with Q(D, X).

4.3. Scaling Considerations When Computing Q-space 🧚

ngl this part is a little bit of a warning 💀 [RFC7490] raises scaling concerns about computing a Q-space per destination. TI-LFA computation can run into similar concerns if an implementation tries to compute a reverse Shortest Path Tree (SPT) [RFC7490] for every destination in the network just to work out the Q-space. It's up to each implementation to find the good tradeoff between scaling and accuracy of the optimization 🙈

5. TI-LFA Repair Path 👑

The TI-LFA repair path is an outgoing interface plus a list of segments (a Repair List (RL)) that gets inserted on the SR header, depending on the data plane being used. The RL encodes the explicit (and possibly post-convergence) path to the destination, and that path avoids the protected resource X. The best part is that the RL is guaranteed to be loop-free, no matter what state the FIBs along the nodes of the explicit path are in, as long as those FIBs are programmed according to a link-state IGP 🔥 Which means there is no need for any coordination or message exchange between the PLR and any other router in the network. Iconic, honestly 💅

The TI-LFA repair path is found by intersecting P(S, X) and Q(D, X) with the post-convergence path to D, and then computing the explicit SR-based path EP(P, Q) from a node P in P(S, X) to a node Q in Q(D, X) when those nodes aren't adjacent along the post-convergence path. The TI-LFA RL is expressed generally as (Node-SID(P), EP(P, Q)).

  S --------- N1 --------- D
  *\          | \          |
  * \         |  \         |
  *  \        |   \        |
  *   N2----- R1***R2 *** R3
  *           *
  N3 **********

    ***** : link with high metric (1k)
    ----- : link with metric 1

                Figure 1: Sample Topology with TI-LFA

Okay, let's walk through Figure 1 together 🗺️✨ The focus is the TI-LFA backup from S to D, considering the failure of node N1.

  • First, P(S, N1) is computed and results in [N3, N2, R1].
  • Then, Q(D, N1) is computed and results in [R3].
  • The expected post-convergence path from S to D considering the failure of N1 is <N2 -> R1 -> R2 -> R3 -> D> (we're calling it "PCPath" in this example) 🛣️
  • P(S, N1) intersection with PCPath is [N2, R1]. With R1 being the deeper downstream node in PCPath, it can be assumed to be used as a P node. (This is just an example, and an implementation could use a different strategy to choose the P node 💖)
  • Q(D, N1) intersection with PCPath is [R3], so R3 gets picked as a Q node. An SR-explicit path is then computed from R1 (P node) to R3 (Q node) following PCPath (R1 -> R2 -> R3): <Adj-SID(R1-R2), Adj-SID(R2-R3)>.

So as a result, the TI-LFA RL of S for destination D, considering the failure of node N1, is: <Node-SID(R1), Adj-SID(R1-R2), Adj-SID(R2-R3)> 🎉

Most of the time the TI-LFA RL is simpler than that, as the following sections describe. Appendix B has statistics on the number of SIDs in the explicit path needed to protect against various failures 📊

5.1. FRR Path Using a Direct Neighbor 🌈

When a direct neighbor is in P(S, X) and Q(D, x), and the link to that direct neighbor is on the post-convergence path, the outgoing interface is set to that neighbor and the repair segment list is empty.

This is comparable to a post-convergence LFA FRR repair 🦋

5.2. FRR Path Using a PQ Node 🍓

When a remote node R is in P(S, X) and Q(D, x) and on the post-convergence path, the RL is made of a single node segment to R, and the outgoing interface is set to the outgoing interface used to reach R.

This is comparable to a post-convergence RLFA repair tunnel 🧁

5.3. FRR Path Using a P Node and Q Node That Are Adjacent 🫧

When a node P is in P(S, X) and a node Q is in Q(D, x), and both are on the post-convergence path and are adjacent to each other, the RL is made of two segments: a node segment to P (to be processed first), followed by an Adjacency segment from P to Q.

This is comparable to a post-convergence Directed Loop-Free Alternate (DLFA) repair tunnel 💜

5.4. Connecting Distant P and Q Nodes Along Post-Convergence Paths 🌙

Sometimes there's no adjacent P and Q node along the post-convergence path. As mentioned in Section 3, a list of Adjacency SIDs can be used to encode the path between P and Q. However, the PLR can do some extra computing to get a shorter list of segments that still represent a loop-free path from P to Q. How those computations get done is out of scope for this document and is left to implementation 🤷‍♀️✨

6. Building TI-LFA Repair Lists for SR Segments 🎀

This section describes how to build the RLs using the terminology defined in [RFC8402]. The procedures here apply equally to both the Segment Routing over MPLS (SR-MPLS) and the Segment Routing over IPv6 (SRv6) data planes, and the data plane-specific considerations are covered in Section 7 🦋

This section explains how a protecting router S handles the active segment of a packet when the primary outgoing interface for the packet S-F fails. The failure of the primary outgoing interface may happen for various reasons, like link failure, neighbor node failure, and others 💅

6.1. The Active Segment Is a Node Segment 🧚

The active segment MUST be kept on the SR header unchanged and the RL MUST be added. The active segment becomes the first segment after the RL. The way the RL gets added depends on the data plane used (see Section 7).

6.2. The Active Segment Is an Adjacency Segment 🌸

This section defines the FRR behavior S applies to any packet received with an active Adjacency segment S-F for which protection was enabled. Protection for the segment S-F was enabled and signaled in the IGP (for instance, using protocol extensions from [RFC8667] and [RFC8665]), so a calculator of any SR policy that uses this segment is aware that it may be transiently rerouted out of S-F if S-F fails 🫶

The simplest approach for link protection of an Adjacency segment S-F is to create an RL that carries the traffic to F. To do that, one or more "PUSH" operations are performed. If the RL, while avoiding S-F, terminates on F, S only pushes the segments of the RL. Otherwise, S pushes a node segment of F, followed by the segments of the RL. For details on the "NEXT" and "PUSH" operations, refer to [RFC8402].

This method merges the traffic back at the remote end of the Adjacency segment, which has the advantage of keeping as much traffic as possible on the pre-failure path 💜 When SR policies are involved and strict compliance with the policy is required, an end-to-end protection (beyond the scope of this document) should be preferred over the local repair mechanism described above.

Note, however: when the SR source node is using Traffic Engineering (TE), it will generally not be possible for the PLR to know what post-convergence path the source node will pick once it detects the failure 😭 Computing the TE path is a local matter that depends on constraints that may not be known at the PLR. So no method applied at the PLR can guarantee that protection will follow the post-convergence path.

The case where the active segment is followed by another Adjacency segment is different from the case where it's followed by a node segment. The repair techniques for each case are in the following subsections 🌈

6.2.1. Protecting [Adjacency, Adjacency] Segment Lists 🍓

If the next segment in the list is an Adjacency segment, then the packet has to be conveyed to F.

To do so, S MUST apply a "NEXT" operation on Adj-SID(S-F) and then one or more "PUSH" operations. If the RL, while avoiding S-F, terminates on F, S only pushes the segments of the RL. Otherwise, S pushes a node segment of F, followed by the segments of the RL. For details on the "NEXT" and "PUSH" operations, refer to [RFC8402].

Upon failure of S-F, a packet reaching S with a segment list matching [adj-sid(S-F), adj-sid(F-M), ...] will leave S with a segment list matching [RL(F), node(F), adj-sid(F-M), ...], where RL(F) is the RL for destination F. 🎀

6.2.2. Protecting [Adjacency, Node] Segment Lists 🦋

If the next segment in the stack is a node segment, say for node T, the segment list on the packet matches [adj-sid(S-F), node(T), ...].

In this case, S MUST apply a "NEXT" operation on the Adjacency segment related to S-F, followed by a "PUSH" of an RL that redirects the traffic to a node Q, whose path to node segment T is not affected by the failure 🧚

Upon failure of S-F, packets reaching S with a segment list matching [adj-sid(S-F), node(T), ...] would leave S with a segment list matching [RL(Q), node(T), ...]. 💖

7. Data Plane-Specific Considerations 💅

7.1. MPLS Data Plane Considerations 👑

The MPLS data plane for SR is described in [RFC8660].

The following data plane behaviors apply when creating an RL using an MPLS data plane:

  1. If the active segment is a node segment that has been signaled with penultimate hop popping, and the RL ends with an Adjacency segment terminating on the penultimate node of the active segment, then the active segment MUST be popped before pushing the RL. 🫧
  2. If the active segment is a node segment, but the other conditions in 1. are not met, the active segment MUST be popped and then pushed again with a label value computed according to the Segment Routing Global Block (SRGB) of Q, where Q is the endpoint of the RL. Finally, the RL MUST be pushed. 🌸

7.2. SRv6 Data Plane Considerations ✨

okay bestie, the SRv6 data plane and its programming instructions are described in [RFC8754] and [RFC8986], respectively 💅

The TI-LFA path computation algorithm is the same as in the SR-MPLS data plane. 🦋 BUT, and this is the lowkey iconic part, Adjacency SIDs are typically globally routed. So there's no need to put a Prefix-SID [RFC8402] in front of an Adjacency SID, and the resulting RL is likely shorter 🎀

If the traffic is protected at a Transit Node, an SRv6 SID list gets added to the packet to apply the RL. ✨ Adding the RL follows the head-end behaviors specified in Section 5 of [RFC8986].

If the traffic is protected at an SR Segment Endpoint Node, the Segment Endpoint packet processing runs first. Then the packet is protected as if it were a transit packet 🫶

8. TI-LFA and SR Algorithms 👑

SR lets an operator bind an algorithm to a Prefix-SID (as defined in [RFC8402]). 🌸 The algorithm value decides how the path to the prefix is computed. The SR default algorithm is called the "Shortest Path" algorithm. It lets an operator override the IGP shortest path using local policies, which is very main character energy 💅

When TI-LFA uses Node-SIDs tied to the default algorithm, there's zero guarantee the path will be loop-free, because a local policy may have overridden the expected IGP path 💀 Local policies are defined by the operator, so it's the operator's job to make sure the deployed policies don't mess with the TI-LFA deployment. It should be noted that this can already happen today with existing mechanisms, like RLFA 🙈

[RFC9350] defines a Flexible Algorithm framework to be associated with Prefix-SIDs. A Flexible Algorithm lets a user tie a constrained path to a Prefix-SID instead of the regular IGP shortest path, which is so cute 🧚

An implementation MAY support TI-LFA to protect Node-SIDs associated with a Flexible Algorithm. 💜 In that case, instead of computing the expected post-convergence path based on the regular SPF, an implementation SHOULD use the constrained SPF algorithm bound to the Flexible Algorithm (using the Flexible Algorithm Definition). This swap happens in all the SPF and reverse SPF computations that occur during the TI-LFA computation. That includes the computation of the P-space and Q-space, as well as the post-convergence path.

Furthermore, the implementation SHOULD only use Node-SIDs/Adj-SIDs bound to the Flexible Algorithm and/or unprotected Adj-SIDs of the regular SPF to build the RL. Using regular Dijkstra for the TI-LFA computation, or for building the repair path with SIDs other than those recommended, does not ensure that traffic on the TI-LFA repair path during the FRR period honors the Flexible Algorithm constraints. 😭

9. Usage of Adjacency Segments in the Repair List 🦋

The RL of segments computed by TI-LFA may contain one or more Adjacency segments. An Adjacency segment may be protected or not protected.

        S --- R2 --- R3 ---- R4 --- R5 --- D
                 *   |  \   *
                   * |   \ *
                    R7 ** R8
                     *    |
                     *    |
                    R9 -- R10

                               Figure 2

In Figure 2, all the metrics are equal to 1 except R2-R7, R7-R8, R8-R4, and R7-R9, which have a metric of 1000. 🍓 Say R2 is a PLR protecting against the failure of node R3 for the traffic S->D. Then the RL computed by R2 will be [adj-sid(R7-R8), adj-sid(R8-R4)], and the outgoing interface will be to R7. If R3 fails, R2 pushes the RL onto the incoming packet to D. During the FRR, if R7-R8 fails and TI-LFA has picked a protected Adjacency segment for Adj-SID(R7-R8), R7 pushes an additional RL onto the packet, following the procedures defined in Section 6. 🤯 That's the double FRR activation situation.

To avoid the possibility of this double FRR activation, an implementation of TI-LFA MAY pick only unprotected Adjacency segments when building the RL. ✨ But here's the important part: FRR in general is meant to protect against a single pre-planned failure. If the failure that happens is worse than expected, or multiple failures happen, FRR is not guaranteed to work. In that case, fast IGP convergence is still important to restore traffic as quickly as possible 💖

10. Security Considerations 🔥

The techniques described in this document are internal functionalities of a router that can guarantee an upper bound on the time taken to restore traffic flow after the failure of a directly connected link or node. Because these techniques steer traffic onto the post-convergence path as quickly as possible, they minimize the disruption from a local failure. That can be seen as a modest security enhancement. The protection mechanism does not protect external destinations. It only provides quick restoration for destinations that are internal to a routing domain.

The security considerations described in [RFC5286] and [RFC7490] apply to this document. Similarly, since the solution described here is based on SR technology, the reader should be aware of the security considerations related to that technology (see [RFC8402]) and its data plane instantiations (see [RFC8660], [RFC8754], and [RFC8986]). However, this document does not introduce additional security concerns. 🔐

11. IANA Considerations 🌈

This document has no IANA actions. 🫶

12. References 📚

12.1. Normative References

12.2. Informative References

Appendix A. Advantages of Using the Expected Post-Convergence Path During FRR ✨

okay bestie, so [RFC7916] raises some operational concerns when you use LFA or RLFA 😭 Section 3 of [RFC7916] has this case where a high bandwidth link between two core routers is protected through a Provider Edge (PE) router that's connected with low bandwidth links. So congestion can happen when the FRR backup path gets activated 💀 [RFC7916] brings in a local policy framework so the operator can manually tune the best alternate election based on their own needs. Very responsible of them 🫶

Now let's talk capacity planning 🎀 People often assume, just to keep things simple, that if a link L fails on a node X, the bandwidth that L was carrying gets spread over some of X's remaining links. The remaining links that get used are decided by IGP routing as if link L had already failed (we assume the traffic takes the post-convergence path starting from node X). In Figure 3, every metric is 1 except the metrics on the links used by PE1, PE2, and PE3, which are 1000. So the easy capacity planning method says: if link L (X-B) fails, the traffic that was flowing through it gets spread over X's remaining links (X-H, X-D, X-A). But once you factor in the IGP metrics, only X-H and X-D can actually carry the traffic from link L. So the bandwidth on X-H and X-D gets sized with that rule in mind. This policy works, ngl, but it isn't fully accurate 🙈

Here's the tea 🍵 Still in Figure 3, say the traffic only comes from PE1 and PE4. When link L fails, X might reroute its forwarding entries for the remote PEs onto X-H or X-D, depending on how fast the nodes converge. But around the same time, PE1 will also reroute part of its traffic (the part headed to PE2) away from its nominal path, which cuts down the amount of traffic X receives. The capacity planning rule from before has the drawback of oversizing the network, but it does prevent any transient congestion (for example, when X reroutes traffic before PE1 does). Main character energy for the planners 👑

H --- I --- J *

*

PE4 | | PE3 \ | (L) | *

  • A --- X --- B --- G *
  • | | * PE1 | | PE2
  • | | *
    • C --- D --- E --- F *

Figure 3

Okay, so based on that assumption, traffic can be steered by the PLR onto its expected post-convergence path during the FRR phase. This makes FRR easier to operate and limits how many local FRR policies you have to implement 🦋 In our example, when link L fails, X switches the traffic destined to PE3 and PE2 onto the post-convergence paths. This lines up perfectly with the capacity planning rule from before, and also with the fact that X may converge before PE1 (or any other upstream router) and may spread the X-B traffic onto the post-convergence paths rooted at X. It's giving coherence ✨

Some networks might use a different capacity planning rule, which allocates less bandwidth on the X-H and X-D links. In that case, using the post-convergence paths rooted at X during FRR may cause some congestion on the X-H and X-D links 😬 Still, transient congestion can happen even without FRR being activated, for instance when X converges before the upstream routers. And operators are still free to use the policy framework defined in [RFC7916] if using the post-convergence paths rooted at the PLR isn't suitable for them 💅

Readers should be aware that FRR pre-computes a backup path to protect against one particular type of failure (link, node, or SRLG) 🔥 When you use the post-convergence path as an FRR backup path, the computed post-convergence path is the one that considers the failure you're protecting against. So FRR is using an expected post-convergence path, and that expected path may actually be different from the post-convergence path used when the failure that really happened is a different one. For example, if the operator has implemented protection against a node failure, the expected post-convergence path used during FRR is the one that assumes the node has failed. But even if only a single link fails, or a set of links fails (instead of the full node), the node-protecting post-convergence path will still be used. The consequence is that the path used during FRR isn't optimal for the failure that actually happened 🥺

One more thing, bestie 🎀 Using the expected post-convergence path for SR traffic that only uses node segments (for instance, PE to PE traffic over the shortest path) has some advantages, but those advantages shrink when SR policies [RFC9256] are involved. A segment list used in an SR policy is computed to obey a set of path constraints, which are defined locally at the head-end or centrally in a controller. TI-LFA can't be aware of those path constraints, and there's no reason to expect the TI-LFA backup path that protects one segment in that list to obey them either. So when SR policies are in use and the operator wants a backup path that still follows the policy requirements, that backup path should be computed as part of the SR policy in the ingress node (or central controller), and the SR policy should not rely on local protection 🧚 Another option is to use a Flexible Algorithm [RFC9350] to express the set of constraints, and then use a single node segment associated with that Flexible Algorithm to reach the destination. When you use a node segment associated with a Flexible Algorithm, TI-LFA keeps providing an optimal backup by applying the right set of constraints. The relationship between TI-LFA and the SR algorithm is detailed in Section 8, so go check that out 💜

Appendix B. Analysis Based on Real Network Topologies 📊

This section shares an analysis done on real service provider and large enterprise network topologies 🌸 The goal was to figure out how many SIDs are needed in an explicit path when the mechanisms described in this document are used to protect against the failure scenarios that are in scope for this document. The number of segments described in this section apply to instantiating SR over the MPLS forwarding plane.

The measurements show that, for link and local SRLG protection, a repair path of 1 SID or less gives more than 99% coverage. For node protection, a repair path of 2 SIDs or less gives 99% coverage. Iconic numbers, honestly 🍓

Table 1 below lists the characteristics of the networks used in these measurements. The number of links counts "bidirectional" links (not directed edges of the graph). Here's how the measurements went down:

  • For each network, the algorithms described in this document are applied to protect all prefixes against link, node, and local SRLG failure.
  • For each prefix, the number of SIDs used by the repair path is recorded.
  • The percentage of SID counts is listed in Tables 2, 3, 4, 5, 6, and 7.
    +=========+=======+=======+====================+============+
    | Network | Nodes | Links | Node-to-Link Ratio | SRLG Info? |
    +=========+=======+=======+====================+============+
    | T1      | 408   | 665   | 1.63               | Yes        |
    +---------+-------+-------+--------------------+------------+
    | T2      | 587   | 1083  | 1.84               | No         |
    +---------+-------+-------+--------------------+------------+
    | T3      | 93    | 401   | 4.31               | Yes        |
    +---------+-------+-------+--------------------+------------+
    | T4      | 247   | 393   | 1.59               | Yes        |
    +---------+-------+-------+--------------------+------------+
    | T5      | 34    | 96    | 2.82               | Yes        |
    +---------+-------+-------+--------------------+------------+
    | T6      | 50    | 78    | 1.56               | No         |
    +---------+-------+-------+--------------------+------------+
    | T7      | 82    | 293   | 3.57               | No         |
    +---------+-------+-------+--------------------+------------+
    | T8      | 35    | 41    | 1.17               | Yes        |
    +---------+-------+-------+--------------------+------------+
    | T9      | 177   | 1371  | 7.74               | Yes        |
    +---------+-------+-------+--------------------+------------+

                     Table 1: Data Set Definition

The rest of this section covers the measurements done on the actual topologies. Here's how the conventions work:

  • 0 SIDs: The calculated repair path starts with a directly connected neighbor that is also a loop-free alternate, so there's no need to explicitly route the traffic using additional SIDs. This scenario is described in Section 5.1.
  • 1 SID: The repair node is a PQ node, so only 1 SID is needed to guarantee a loop-free path. This scenario is covered in Section 5.2.
  • 2 or more SIDs: The repair path consists of 2 or more SIDs, as described in Sections 5.3 and 5.4. The case for 2 SIDs (Section 5.3) isn't covered separately because there was no granularity in the result. Also, the Node-SID + Adj-SID and Node-SID + Node-SID are treated the same, because they don't differ from the data plane point of view.

Tables 2 and 3 below summarize the measurements on the number of SIDs needed for link protection 🦋

           +=========+========+=======+========+========+
           | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
           +=========+========+=======+========+========+
           | T1      | 74.3%  | 25.3% | 0.5%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T2      | 81.1%  | 18.7% | 0.2%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T3      | 95.9%  | 4.1%  | 0.1%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T4      | 62.5%  | 35.7% | 1.8%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T5      | 85.7%  | 14.3% | 0.0%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T6      | 81.2%  | 18.7% | 0.0%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T7      | 98.9%  | 1.1%  | 0.0%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T8      | 94.1%  | 5.9%  | 0.0%   | 0.0%   |
           +---------+--------+-------+--------+--------+
           | T9      | 98.9%  | 1.0%  | 0.0%   | 0.0%   |
           +---------+--------+-------+--------+--------+

               Table 2: Link Protection (Repair Size
                           Distribution)

Okay, the numbers are where the magic happens 🦋

              +=========+========+=======+========+========+
              | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
              +=========+========+=======+========+========+
              | T1      | 74.2%  | 99.5% | 99.9%  | 100%   |
              +---------+--------+-------+--------+--------+
              | T2      | 81.1%  | 99.8% | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T3      | 95.9%  | 99.9% | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T4      | 62.5%  | 98.2% | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T5      | 85.7%  | 100%  | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T6      | 81.2%  | 99.9% | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T7      | 98.8%  | 100%  | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T8      | 94.1%  | 100%  | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T9      | 98.9%  | 100%  | 100%   | 100%   |
              +---------+--------+-------+--------+--------+

                  Table 3: Link Protection (Repair Size
                         Cumulative Distribution)

Tables 4 and 5 spill the tea on how many SIDs local SRLG protection needs 💅

              +=========+========+=======+========+========+
              | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
              +=========+========+=======+========+========+
              | T1      | 74.2%  | 25.3% | 0.5%   | 0.0%   |
              +---------+--------+-------+--------+--------+
              | T2      | No SRLG information              |
              +---------+--------+-------+--------+--------+
              | T3      | 93.6%  | 6.3%  | 0.0%   | 0.0%   |
              +---------+--------+-------+--------+--------+
              | T4      | 62.5%  | 35.6% | 1.8%   | 0.0%   |
              +---------+--------+-------+--------+--------+
              | T5      | 83.1%  | 16.8% | 0.0%   | 0.0%   |
              +---------+--------+-------+--------+--------+
              | T6      | No SRLG information              |
              +---------+----------------------------------+
              | T7      | No SRLG information              |
              +---------+--------+-------+--------+--------+
              | T8      | 85.2%  | 14.8% | 0.0%   | 0.0%   |
              +---------+--------+-------+--------+--------+
              | T9      | 98.9%  | 1.1%  | 0.0%   | 0.0%   |
              +---------+--------+-------+--------+--------+

                  Table 4: Local SRLG Protection (Repair
                            Size Distribution)

              +=========+========+=======+========+========+
              | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs |
              +=========+========+=======+========+========+
              | T1      | 74.2%  | 99.5% | 99.9%  | 100%   |
              +---------+--------+-------+--------+--------+
              | T2      | No SRLG information              |
              +---------+--------+-------+--------+--------+
              | T3      | 93.6%  | 99.9% | 100%   | 0.0%   |
              +---------+--------+-------+--------+--------+
              | T4      | 62.5%  | 98.2% | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T5      | 83.1%  | 100%  | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T6      | No SRLG information              |
              +---------+----------------------------------+
              | T7      | No SRLG information              |
              +---------+--------+-------+--------+--------+
              | T8      | 85.2%  | 100%  | 100%   | 100%   |
              +---------+--------+-------+--------+--------+
              | T9      | 98.9%  | 100%  | 100%   | 100%   |
              +---------+--------+-------+--------+--------+

                  Table 5: Local SRLG Protection (Repair
                      Size Cumulative Distribution)

And the last two tables are all about node protection 🌈

          +=========+========+=======+========+========+========+
          | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs |
          +=========+========+=======+========+========+========+
          | T1      | 49.8%  | 47.9% | 2.1%   | 0.1%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T2      | 36.5%  | 59.6% | 3.6%   | 0.2%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T3      | 73.3%  | 25.6% | 1.1%   | 0.0%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T4      | 36.1%  | 57.3% | 6.3%   | 0.2%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T5      | 73.2%  | 26.8% | 0.0%   | 0.0%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T6      | 78.3%  | 21.3% | 0.3%   | 0.0%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T7      | 66.1%  | 32.8% | 1.1%   | 0.0%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T8      | 59.7%  | 40.2% | 0.0%   | 0.0%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+
          | T9      | 98.9%  | 1.0%  | 0.0%   | 0.0%   | 0.0%   |
          +---------+--------+-------+--------+--------+--------+

            Table 6: Node Protection (Repair Size Distribution)

          +=========+========+=======+========+========+========+
          | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs |
          +=========+========+=======+========+========+========+
          | T1      | 49.7%  | 97.6% | 99.8%  | 99.9%  | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T2      | 36.5%  | 96.1% | 99.7%  | 99.9%  | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T3      | 73.3%  | 98.9% | 99.9%  | 100%   | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T4      | 36.1%  | 93.4% | 99.8%  | 99.9%  | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T5      | 73.2%  | 100%  | 100%   | 100%   | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T6      | 78.4%  | 99.7% | 100%   | 100%   | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T7      | 66.1%  | 98.9% | 100%   | 100%   | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T8      | 59.7%  | 100%  | 100%   | 100%   | 100%   |
          +---------+--------+-------+--------+--------+--------+
          | T9      | 98.9%  | 100%  | 100%   | 100%   | 100%   |
          +---------+--------+-------+--------+--------+--------+

              Table 7: Node Protection (Repair Size Cumulative
                               Distribution)

Acknowledgments ✨

The authors would like to thank Les Ginsberg, Stewart Bryant, Alexander Vainsthein, Chris Bowers, Shraddha Hedge, Wes Hardaker, Gunter Van de Velde, and John Scudder for their valuable comments. Thank you all, you're literally the best 🫶

Contributors 🎀

In addition to the authors listed on the front page, these co-authors have also contributed to this document:

Francois Clad
Cisco Systems
Pablo Camarillo
Cisco Systems

Authors' Addresses 💜

Ahmed Bashandy
HPE
United States of America
Email: abashandy.ietf@gmail.com
Stephane Litkowski
Cisco Systems
France
Email: slitkows@cisco.com
Clarence Filsfils
Cisco Systems
Brussels
Belgium
Email: cfilsfil@cisco.com
Pierre Francois
INSA Lyon
Email: pierre.francois@insa-lyon.fr
Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
Daniel Voyer
Bell Canada
Canada
Email: daniel.voyer@bell.ca
📦 where this page comes from