LFA Support

LFA, remote LFA, and TI-LFA are supported in the following router roles:

The backup is computed and programmed for each remote SRv6 End SID, service SID (End.DT4 SID, End.DT6 SID, and End.D46), as well as for each local End.X or LAN End.X SID.

A base LFA backup path or a TI-LFA backup path that uses a direct IP next hop (not a repair tunnel), requires configuring a next hop that is different from the primary path and does not modify the SID list pushed on the primary path.

When the Remote LFA or TI-LFA backup path uses a repair tunnel (source routed or not), the additional SIDs of the repair tunnel must be inserted into the packet when the backup is activated. This requires the insertion of a LFA dedicated SRH into the packet. The SRV6 behavior is referred to as H.Insert.Red and is described in https://tools.ietf.org/html/draft-filsfils-spring-srv6-net-pgm-insertion-04. The application of this behavior to the LFA repair tunnel is described in https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-10.

Figure 1 illustrates the packet encoding for the primary and remote LFA backup path using a dedicated reduced SRH for the repair tunnel.

Figure 1. LFA Repair Tunnel Packet Encoding

The LFA backup path for the prefix of a remote End SID, End.DT4 SID, End.DT6 SID, or End.D46 SID is programmed in RTM and in the FIB with the entry of the prefix of the locator of that SID. This is because forwarding to these SIDs is based on looking up the remote locator they were derived from.

The LFA backup for a local End.X or a local LAN End.X is programmed in RTM and the FIB with the specific entry corresponding to this SID.

When the LFA backup is a direct IP link, the encapsulation of the packet is not changed. The packet is forwarded out of the backup path next hop interface.

When the LFA backup is a tunnel, the SRv6 feature on FP4 platforms can insert one additional SID for an RLFA or TI-LFA PQ node. This provides sufficient coverage in the following repair tunnel cases: