Summary

  • RFC 9855 TI-LFA activates a preinstalled Segment Routing repair list at a Point of Local Repair after a directly attached failure.
  • That local, loop-free forwarding repair is not evidence that every router converged, a service is usable, a session survived or an intended outcome occurred.

“Traffic was repaired” is a statement with a hidden subject. It may mean that one router detected a failed neighbour or link, selected a backup forwarding entry that had been computed before the failure, and imposed a Segment Routing repair list. That is real and valuable evidence. It is evidence about the Point of Local Repair, the protected resource and a specified forwarding model. It is not yet a statement about an application, a customer path or a business process.

RFC 9855 calls the mechanism Topology Independent Loop-Free Alternate Fast Reroute, or TI-LFA. It is designed for Segment Routing with normal link-state IGP shortest-path scenarios. A PLR acts after detecting a failure in a directly connected component. Backup forwarding entries are precomputed and preinstalled, so the router does not wait for the control plane to finish reconverging before taking urgent forwarding action.

The repair list encodes an explicit path intended to avoid the failed resource and to follow the expected post-convergence path. Under the RFC’s stated FIB assumptions, that path is loop-free. This is a strong local control: it limits one familiar failure mode while the network is changing state. It also has a clear lifetime. TI-LFA repair is activated when the PLR detects the failure and remains active until IGP convergence at that PLR completes.

The specification is unusually useful because it also names what local action does not influence. TI-LFA at one PLR does not settle the order in which other routers converge. It does not eliminate micro-loops that might form elsewhere during transient inconsistency. It does not govern micro-loops that may appear when a previously failed link is restored. The word “fast” therefore belongs to a particular local response, not to every network fact that operators may care about next.

Path construction has its own boundary. TI-LFA uses P-space and Q-space properties over an expected post-convergence path; an implementation builds a repair list from node and, where needed, adjacency segments. Segment-list length and hardware programming capacity can matter. The resulting list may be correct for the specified failed link, node or SRLG model while a different fault, a remote failure, a capacity problem or an application dependency remains outside its evidence.

This distinction is operationally decisive. A forwarding counter at the PLR can show repair-list activation. A routing telemetry stream can show local convergence. Neither alone proves that a remote FIB selected the expected path, that a TLS session remained valid, that a DNS answer was current, that an application dependency responded, or that a customer transaction completed. RFC 5286, RFC 7490 and RFC 5715 provide adjacent context for loop-free alternates, remote LFAs and micro-loops; they do not erase this evidence ladder.

The useful incident record is therefore staged: failed local resource; PLR detection time; selected repair list; actual forwarding counters; IGP state at the PLR; convergence elsewhere; end-to-end synthetic measurements; application and dependency health; customer-visible result; and, separately, the decision to declare recovery. Each stage has a different owner and a different way to be wrong. Calling the first stage “service restored” makes the later stages invisible precisely when a fast repair should give them room to be checked.

Sources