Operational Guidance for Protection Mechanisms in SRv6 Networks

Internet-Draft	Operational Guidance for SRv6 Protection	July 2026
Liu, et al.	Expires 19 January 2027	[Page]

3. Considerations for Protection Mechanisms

Two main categories of protection mechanism in SRv6 networks are described in this section: path protection and egress protection.¶

Path protection works when the failure occurs along the forwarding path, including SRv6 BE paths and SRv6 TE paths. Path protection is further divided into local protection, which is performed by the node adjacent to the failed component, and end-to-end protection, which is performed by the ingress PE node.¶

In multi-homed scenarios, egress protection works instead when the failure occurs on the egress PE node, and traffic will be forwarded to another backup Egress PE node. Egress protection can be performed by either local repair or ingress node switchover.¶

The corresponding liveness check mechanisms are also described along with the protection mechanisms.¶

3.1. Considerations for Path Protection

3.1.1. Local Protection

Local protection is performed by the node adjacent to the failed component using fast-reroute techniques [RFC5286] [RFC5714]. The common method of local repair is to provide a repair path for the destination avoiding the failed component.¶

[RFC9855] describes the Topology Independent Loop-free Alternate Fast Reroute technology (TI-LFA) using Segment Routing, which is able to provide a loop free backup path irrespective of the topologies used in the network. On the SRv6 data plane, the TI-LFA repair path is encoded as an SRv6 SID list, and encapsulated in the SRH along with an outer IPv6 header.¶

When local protection occurs, it changes the packet forwarding path, typically applicable in scenarios with low SLA requirements. When configuring local protection, the following factors should be considered:¶

The scope of prefixes to be protected, to avoid calculating backup paths for all IGP prefixes and to prevent excessive resource consumption.¶
According to the topology plan, configure local protection reasonably. If the network topology is loop-free, there is no need to enable the TI-LFA function.¶
Control the interfaces to be protected, enabling local protection only on specific interfaces.¶
When multiple backup paths exist, set policies to control the selection of the backup path based on network planning.¶
Set a reasonable delay time based on the network scale to avoid temporary congestion; it is usually recommended to set the time between 5 to 30 seconds.¶
In cases where multiple points of failure may exist on local links, consider configuring the FRR function with shared risk groups.¶

3.1.2. Liveness Check for Local Protection

In order to perceive the failures of links and neighbors, a node should monitor the liveness of its adjacent components.¶

[RFC5880] and [RFC7880] provide widely used mechanisms for liveness check, called Bidirectional Forwarding Detection (BFD) and Seamless Bidirectional Forwarding Detection (S-BFD).¶

Other OAM methods, such as Ping, TWAMP or STAMP, may also be used for liveness check for local protection.¶

When deploying local protection mechanisms, the following factors should be considered:¶

Detection Focus: The detection of a local egress failure should primarily rely on the state of the directly connected adjacency, the local interface, or a BFD session monitoring that specific adjacency. A routed probe (e.g., ICMP ping) toward the egress node's locator or SID may be forwarded via an alternate path in the network and therefore may not reliably detect the failure of the adjacent egress link or node.¶
Detection Requirements If the detection requirement is less than 100ms, it is recommended to configure BFD (Bidirectional Forwarding Detection).¶
Local Interface State Detection Local protection typically monitors the state of the egress interface. This can be achieved by configuring BFD or other OAM mechanisms tied to the interface state.¶
BFD Session Optimization If BFD is already configured for IGP neighbor detection, the same BFD session can be used to monitor the next-hop state. This eliminates the need for a separate BFD session for the primary path, reducing the total number of BFD sessions.¶
Alternative Detection Protocols In scenarios where TWAMP (Two-Way Active Measurement Protocol) or STAMP (Simple Two-Way Active Measurement Protocol) is already deployed, these protocols can be used not only for link quality detection but also for reachability verification. If performance requirements are not stringent, configuring BFD may not be necessary.¶

3.1.3. Micro-Loop Avoidance

On the SRv6 data plane, the loop-free post-convergence path is encoded as an SRv6 SID list, and encapsulated in the SRH along with an outer IPv6 header.¶

To effectively configure micro-loop prevention, the following guidelines should be considered:¶

Default Duration It is recommended to set the micro-loop prevention duration to 5 seconds as a default value.¶
Adjusting Duration for Larger Networks: As the network scale increases, the overall convergence time may also increase. In such cases, the duration of micro-loop prevention can be adjusted accordingly to align with the extended convergence time.¶
Local vs. Remote Micro-Loop Prevention: Micro-loops can be caused by either local link changes or remote link changes. Depending on the specific scenario, operators can choose to enable micro-loop avoidance for the appropriate scope.¶

3.1.4. End-to-End Protection

End-to-end protection lets the ingress PE node be in charge of the failure recovery. The ingress node should steer the flow from the failed path into another alive path.¶

In the case of SRv6 TE path, the SRv6 Policy itself allows for multiple candidate paths, of which at any point in time there is a single active candidate path that is provisioned in the forwarding plane and used for traffic steering [RFC9256]. The candidate path with highest preference is selected as the primary path, and the candidate path with second highest preference can be selected as the hot-standby backup. When the primary candidate path fails, switchover to the backup candidate path can be triggered by fast re- route mechanism.¶

If all the candidate paths fail, the ingress node may use SRv6 BE path for best-effort forwarding as a backup.¶

To effectively configure End-to-End protection for SRv6 Policy, the following guidelines should be considered:¶

Hot Standby for SRv6 Policy: Enable the hot standby feature for SRv6 Policy to pre-configure the suboptimal candidate paths in the forwarding plane.¶
End-to-End Detection: Ensure that End-to-End detection is enabled for both the primary path and the backup path.¶
Reversion Delay: Configure a reasonable reversion delay to avoid switching back to the primary path too quickly after fault recovery. The recommended value is 5 seconds.¶
Multiple Suboptimal Paths for Sequential Backup: In real deployments, multiple candidate paths may fail simultaneously. It is recommended to configure multiple suboptimal candidate paths to form a sequential backup, enhancing performance in scenarios with multi-point failures.¶
Escape to Best Effort (BE) Path : If all SRv6 Policy paths fail, configure whether to escape to a Best Effort (BE) path based on business requirements.¶

3.1.5. Liveness Check for End-to-End Protection

It is essential that the ingress PE node should check the end-to-end liveness of paths, including primary path and backup path. So that the ingress PE node can perceive the path failure and then trigger the switchover.¶

In the case of SRv6 TE path, BFD or S-BFD can be used to monitor the liveness of SRv6 Policy at the level of segment list. If all the BFD sessions associated with segment lists in a candidate path are down, the candidate path is deemed to be failed. If all the candidate paths are failed, the SRv6 Policy is deemed to be failed.¶

Moreover, If the SRv6 TE path is strict (every hop along the path appearing in the SID list), the reverse path of the BFD packets should be the same with the forward path. Otherwise, a failure in the reverse path may lead to misjudgment of the SRv6 Policy's liveness. To achieve the consistence of forward path and reverse path, the egress node should be instructed to use specific path to send packets back to the ingress node.¶

Other OAM methods, such as Ping, TWAMP or STAMP, may also be used for liveness check for end-to-end protection, which will not be enumerated here in detail.¶

Local protection and end-to-end protection may both be used in the same SRv6 network. Since the speed of failure detection for local protection is faster than end-to-end protection, local protection usually performs the local repair in advance, which allows the path to remain alive. In this case, the ingress node will not perceive the failure and does not need to trigger end-to-end protection.¶

To effectively configure Liveness Check for End-to-End protection in SRv6 Policy, the following guidelines should be considered:¶

Consistent Round-Trip Path for Strict Paths When the SRv6 Policy path is a strict path, it is recommended to enable the consistent round-trip path feature for detection packets. This prevents the backup path from being mistakenly marked as DOWN due to inconsistent paths.¶

Detection Time for Inconsistent Paths If the round-trip path for detection packets is inconsistent, ensure that the detection timeout for the backup path is longer than that of the primary path. For example, when using BFD, configure:¶
```
Primary path timeout: 50ms

Backup path timeout: 150ms
```
¶
No-Bypass for Detection Packets When local protection is enabled on intermediate devices, it may prevent the End-to-End detection from marking the path as DOWN. To address this, enable the no- bypass feature for detection packets, ensuring they do not take the protection path at intermediate nodes.¶
Encapsulation Mode for Detection Packets Configure the encapsulation mode for detection packets, such as Encap mode or Insert mode. For reduced payload overhead, use Insert mode. For full compatibility with detection protocols, use Encap mode.¶

3.2. Considerations for Egress Protection

Path protection mechanisms such as TI-LFA and SRv6 Policy candidate- path switchover can protect against failures of transit links and transit nodes before the egress. However, they do not by themselves protect against failure of the egress PE node that owns the service SID, nor against failure of the PE-CE attachment circuit. At the egress, the active segment is a service SID, such as an End.DT4, End.DT6, End.DT46, or End.DX behavior [RFC8986], carried in the IPv6 Destination Address. When the egress PE fails, that service SID and its associated forwarding context are no longer available at the primary egress. Protection therefore requires the traffic to be delivered to a backup egress PE that can reproduce the intended service context.¶

This is an SRv6-specific consideration. Protecting the egress does not mean swapping a transport label or merely preserving reachability to a node. It means preserving the semantics of the active SRv6 service SID, including the associated forwarding context such as the VPN table binding or attachment-circuit context.¶

Egress protection can be performed by local repair at the node upstream of the failed egress, or by ingress node switchover.¶

3.2.1. Local Repair

In local repair, the node immediately upstream of the failed egress -- typically the penultimate SRv6 endpoint, acting as the Point of Local Repair (PLR) -- redirects traffic to a backup egress (protector) that can restore the service context. In SRv6 this is realized using the Mirror SID behavior, End.M [I-D.ietf-rtgwg-srv6-egress-protection]. End.M is a new SRv6 endpoint behavior (a variant of the End.DT6 behavior of [RFC8986]); the End.M SID is the last segment of the repair encapsulation and is associated with an IPv6 forwarding table representing the context of the protected egress.¶

The essential SRv6-specific point is that egress protection is expressed as an SRv6 endpoint behavior operating on a service SID carried in the IPv6 Destination Address, rather than as a transport- label context. The MPLS egress protection framework [RFC8679] [RFC8400] addresses the analogous problem for MPLS TE LSPs using a context label; the SRv6 realization instead uses the End.M behavior, the SRv6 IGP extensions ([RFC9352] for IS-IS, [RFC9513] for OSPFv3), and H.Encaps at the PLR. None of these constructs apply to the SR- MPLS data plane.¶

The mechanism operates as follows:¶

The protector PEB is configured with a Mirror SID (End.M) that protects the primary egress PEA, and advertises the binding <PEB, PEA, Mirror SID> together with the protected locators into the link-state IGP (IS-IS/OSPFv3) within the area/level. This signaling operates at locator granularity and does not enumerate per-service entries in the IGP.¶
PEB obtains the forwarding behavior of the protected service SID of PEA -- for example via the BGP-based overlay [RFC9252] or by configuration -- and installs it into the forwarding table identified by the Mirror SID, so that it can apply the correct service action after protection.¶
Upon detecting failure of PEA, the PLR encapsulates the affected packets (H.Encaps) with a repair list whose last segment is the Mirror SID of PEB, steering them to PEB instead of PEA. PEB resolves the Mirror SID context and delivers the traffic toward the CE.¶

For a PE-CE attachment-circuit failure (as opposed to egress node failure), the primary egress PE itself acts as the repair node and forwards the affected traffic to a backup egress PE.¶

In multi-homed deployments, an alternative that avoids installing per-service mirror context relies on a penultimate-endpoint behavior (e.g., the PSD flavor of [I-D.cheng-rtgwg-srv6-multihome-egress-protection]). Upon egress failure, the penultimate endpoint decrements Segments Left and rewrites the IPv6 Destination Address to a backup SID, so that the packet is delivered to a reachable backup egress. Because the operation is bound to the penultimate position and does not act at transit nodes, it is performed only at the repair node.¶

The following operational factors should be considered:¶

Detection at the PLR. Egress liveness at the PLR is typically driven by IGP fast convergence or by BFD/S-BFD [RFC5880] [RFC7880] to the protected locator or SID (see Section 3.2.2 and Section 4.4). The repair path to the protector is computed using TI-LFA [RFC9855].¶
IGP flooding scale. Egress-protection state (mirror bindings and protected locators) is flooded in the IGP. The scale of this IGP state is governed by the number of protector nodes, protected nodes, and the configured protection relationships between them. It is independent of the number of individual service instances (e.g., VPNs). However, in deployments with extensive or unstructured multi-homing patterns, the number of these protection bindings can grow and affect control-plane load [I-D.ietf-rtgwg-srv6-egress-protection]. Separately, the protector node must maintain per-service forwarding context for the services it protects. This context scales with the number of service instances on the protected egress nodes and is learned via service signaling protocols (e.g., BGP) or configuration, not via the IGP. Mirror-SID local repair is therefore best suited to bounded, well-planned multi-homing; ingress node switchover (Section 3.2.2) may be preferable at extreme scale of service instances to avoid maintaining full per-service context on all protectors.¶
SRH/MTU impact. Redirection to a protector adds one or more SIDs to the encapsulation at the repair node; the additional header length MUST be accounted for in the SRv6 Path MTU reservation (see Section 7).¶

3.2.2. Ingress Node Switchover

If multiple egress PE nodes advertise the same service, the ingress PE node learns all of their advertisements and builds a path to each egress. The ingress node may use Fast Reroute (FRR) among these paths. When the primary egress PE fails, the ingress node steers the flow onto the path to a backup egress PE.¶

In SRv6, an egress' reachability is expressed by its locator (a routable IPv6 prefix) and its service SID (carried in the IPv6 Destination Address), so the ingress node can evaluate egress liveness in SRv6-native ways:¶

BFD or S-BFD [RFC5880] [RFC7880] to the service SID, the locator, or an interface address of the egress PE. If the session is down, the egress is deemed unreachable.¶
IGP reachability of the egress locator. SRv6 SIDs are not independently routable; reachability depends on a covering locator advertised in the IGP [RFC9352]. Withdrawal of the locator therefore signals egress loss. IGP convergence is slower than BFD but useful in some cases -- for example, in a BGP-based VPN service, ingress switchover triggered by IGP convergence of the egress locator is usually faster than BGP convergence of the VPN service routes.¶
SRv6 OAM [RFC9259] mechanisms may likewise be used to verify egress reachability.¶

In deployments requiring very fast restoration (e.g., less than 200 ms), local repair at the penultimate endpoint (Section 3.2.1) SHOULD be deployed in addition to ingress switchover, since detection plus signaling to the ingress is generally slower than local action at the PLR.¶

Egress protection and path protection may both be used in the same SRv6 network. Among the paths to the same egress PE and the paths to different egress PEs, one is selected as the primary and the others are used as backups. The priorities of multiple backup paths may be decided by the egress-node-first strategy or the TE-first strategy, as described in the following paragraphs.¶

By the Egress-node-first strategy, paths to the primary egress PE nodes are prioritized. For example, if a failure occurs on the primary path, the ingress PE node will select another path still leading to the primary egress PE nodes. Unless all the paths to the primary egress PE node are failed, the ingress PE node would use the path to the backup egress PE node.¶

By the TE-first strategy, SRv6 TE paths to any egress PE node have higher priorities than SRv6 BE paths. For example, if a failure occurs on the primary path and there is no other alive SRv6 TE path to the primary egress PE node, the ingress node will select an SRv6 TE path to the backup egress PE node, rather than an SRv6 BE path still leading to the primary egress PE node.¶

4. Operational Guidance

This section will introduce the operational guidance of protection for SRv6 networks. Section 4.1 describes the deployment options, Section 4.2 describes the single-homed scenario, and Section 4.3 describes the multi-homed scenario. In the following scenarios, we assume that both SRv6 BE paths or SRv6 TE paths are used in the same network to steer traffic with different requirements.¶

4.1. Deployment Options

When deploying SRv6 protection, the following factors SHOULD be considered:¶

Egress Protection Strategy¶

Determine whether the service operates in a single-homed or multi- homed scenario. Select between SRv6 TE or BE forwarding. When implementing SRv6 TE, incorporate multi-path protection mechanisms.¶

Protection Deployment Location¶

Protection mechanisms SHOULD be optimized according to node roles (ingress, midpoint, or egress) and SLA requirements to ensure appropriate protection strategies are deployed.¶

Multi-Level Protection Coordination¶

Protection achieves optimal effectiveness when activated at the initial failure point, though its coverage scope requires concurrent evaluation.¶

Recommended Protection Workflow:¶

Local Protection Tier: Intermediate nodes (e.g., via TI-LFA) initiate primary failure recovery.¶

Path Protection Tier: SRv6 End-to-End protection engages if local mechanisms fail.¶

BE Fallback Tier: Traffic defaults to SRv6 BE when all TE paths are unavailable.¶

Egress Redundancy Tier: Backup egress nodes assume traffic upon primary egress failure.¶

Note: Hierarchical protection intervals must be configured judiciously to ensure coordinated operation across all tiers.¶

4.2. Single-homed Scenario

                  CE1--PE1-----P1----PE3--CE2
                        |      |      |
                        |      |      |
                        |      |      |
                        |      |      |
                        |      |      |
                       PE2-----P2----PE4

Figure 4: Single-homed Scenario

In the single-homed scenario, the combination of following mechanisms can be used for the protection of SRv6 network:¶

TI-LFA¶
Multiple Candidate Paths¶
BE as Backup for TE¶

For traffic steered by SRv6 BE paths, protection is performed locally by the node adjacent to the failed component using TI-LFA mechanism. BFD for links and neighbors are used as triggers of TI- LFA.¶

For traffic steered by SRv6 TE paths, in some cases, end-to-end protection (switchover to backup candidate path) is preferred over local protection (TI-LFA) due to SLA requirements. BFD or S-BFD is enabled to monitor the liveness of candidate paths. If the main candidate path is down, the SRv6 Policy will switch to the backup candidate path. In some other cases, local protection is preferred over backup candidate path due to the requirements of traffic restoring time, like less than 200ms.¶

In the cases with high SLA requirements: For strict SRv6 TE path, TI-LFA is not used along the path; This is because TI-LFA provides local repair by detouring around a failed component (link or node); Using such a detour would cause the traffic to deviate from the explicitly specified node sequence in the strict segment list, thereby violating the traffic engineering intent and SLA guarantees of the strict path. For loose SRv6 TE path, local protection only works for the loose part on the path.¶
In the cases with fast traffic restoring requirements: TI-LFA performs local protection in advance. The ingress node will perceive the failure on the main candidate path after routing convergence, and then switch to backup candidate path.¶

In addition, SRv6 BE path can be used as a final backup for SRv6 TE path in case of multi-point faults. When all candidate paths of an SRv6 Policy are failed, the traffic will be switched to the SRv6 BE path instead of being dropped. Except for the cases where dropping is more preferred due to strong SLA requirements or where there is no requirement of fast traffic restoration for multi-point faults.¶

4.3. Multi-homed Scenario

                          PE1-----P1----PE3
                         / |      |      | \
                        /  |      |      |  \
                      CE1  |      |      |  CE2
                        \  |      |      |  /
                         \ |      |      | /
                          PE2-----P2----PE4

Figure 5: Multi-homed Scenario

In the multi-homed scenario, egress protection is also taken into consideration besides path protection. In addition to the mechanisms mentioned in the previous single-homed scenario, the following ones are also used for the protection of SRv6 network:¶

Ingress Node Switchover to Backup Egress Node¶

The ingress node monitors the liveness of egress nodes, such as enabling BFD for egress nodes, or validating IGP routes of egress nodes. When the failure occurs on the main egress node, the ingress node performs the switchover from the main egress node to the backup egress node. This mechanism works for both the traffic steered by SRv6 TE paths and SRv6 BE paths in the multi-home scenario. Note that, in the multi-homed scenario, the ingress node switchover works among the paths towards different egress nodes. Taking the SRv6 TE paths as an example, the ingress node switches among multiple SRv6 Policies with different endpoints, while in the single-homed scenario the ingress node switches among multiple candidate paths within the same SRv6 Policy.¶

In the cases with fast traffic restoring requirements, like less than 200ms, the local repair for egress node failure should be deployed.¶

The path protection is the same as the previous single-homed scenarios.¶

4.4. Liveness Check

As described in Section 4.2 and 4.3, BFD/S-BFD is used to monitor the liveness of links, neighbors, SRv6 Policies and egress nodes.¶

The BFD time interval for links and neighbors is recommended to be 10ms * 3 and thus the local protection provided by TI-LFA would restore traffic in less than 50ms.¶

The BFD time interval for main candidate paths of SRv6 Polices is recommended to be 50ms * 3, while the time interval for backup candidate paths can be relaxed to 100ms * 3. Thus, the end-to-end protection would restore traffic in less than 300ms.¶

The BFD time interval for egress nodes is recommended to be 50ms * 3.¶

4.5. Considerations for SRv6 Locator

In SRv6 deployments, operators may advertise summarized locator reachability in order to reduce routing state and improve scalability. When protection mechanisms are deployed, the interaction between locator summarization and SRv6 SID reachability needs to be considered carefully. Reachability to a summarized locator does not necessarily imply that a specific SRv6 SID, service SID, End.X SID, or egress PE remains available.¶

Protection mechanisms SHOULD ensure that the repair path preserves the intended SRv6 endpoint behavior and service reachability, not only reachability to the summarized locator prefix. In particular, egress protection, SRv6 BE fallback, and SRv6 Policy candidate-path switchover SHOULD distinguish between locator reachability, endpoint reachability, and service SID availability.¶

When locator summarization is used, operators SHOULD ensure that OAM and liveness detection mechanisms validate the SID or service being protected. Testing only the summarized locator may hide failures affecting a specific endpoint function or service SID. This is especially important for egress protection scenarios where the summarized locator remains reachable but the primary egress PE or attached service is no longer available.¶

11. References

11.1. Normative References

[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>.
[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>.
[RFC7880]: Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <https://www.rfc-editor.org/info/rfc7880>.
[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>.
[RFC8400]: Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, "Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 2018, <https://www.rfc-editor.org/info/rfc8400>.
[RFC8679]: Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., Michel, C., and H. Chen, "MPLS Egress Protection Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, <https://www.rfc-editor.org/info/rfc8679>.
[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>.
[RFC9252]: Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, <https://www.rfc-editor.org/info/rfc9252>.
[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>.
[RFC9259]: Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Chen, "Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)", RFC 9259, DOI 10.17487/RFC9259, June 2022, <https://www.rfc-editor.org/info/rfc9259>.
[RFC9352]: Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[RFC9513]: Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", RFC 9513, DOI 10.17487/RFC9513, December 2023, <https://www.rfc-editor.org/info/rfc9513>.
[RFC9800]: Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, June 2025, <https://www.rfc-editor.org/info/rfc9800>.
[RFC9855]: Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute Using Segment Routing", RFC 9855, DOI 10.17487/RFC9855, October 2025, <https://www.rfc-editor.org/info/rfc9855>.

11.2. Informative References

[I-D.cheng-rtgwg-srv6-multihome-egress-protection]: Cheng, W., Wenying, J., Lin, C., Hu, Z., and Y. Qiu, "SRv6 Egress Protection in Multi-homed scenario", Work in Progress, Internet-Draft, draft-cheng-rtgwg-srv6-multihome-egress-protection-10, 29 June 2026, <https://datatracker.ietf.org/doc/html/draft-cheng-rtgwg-srv6-multihome-egress-protection-10>.
[I-D.ietf-rtgwg-srv6-egress-protection]: He, T., Hu, Z., Chen, H., Toy, M., and C. Cao, "SRv6 Path Egress Protection", Work in Progress, Internet-Draft, draft-ietf-rtgwg-srv6-egress-protection-24, 19 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-srv6-egress-protection-24>.
[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>.
[RFC5310]: Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
[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>.
[RFC7166]: Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.
[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>.
[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>.

Appendix A. Examples

Figure 6 is used as a reference topology to illustrate the deployments of protection in SRv6 networks. PE1 and PE3 are primary PE nodes for VPN service access. PE2 and PE4 are used as backup. The prefix of CE2, along with VPN service SID, is advertised by BGP routes from PE3 and PE4 to PE1 and PE2. The VPN traffic is from CE1 to CE2.¶

                 PE1-----P1-----P3-----P5-----P7----PE3
                / | \  / | \  / | \  / | \  / | \  / | \
               /  |  \/  |  \/  |  \/  |  \/  |  \/  |  \
             CE1  |  /\  |  /\  |  /\  |  /\  |  /\  |  CE2
               \  | /  \ | /  \ | /  \ | /  \ | /  \ |  /
                \ |/    \|/    \|/    \|/    \|/    \| /
                 PE2-----P2-----P4-----P6-----P8----PE4

Figure 6: Reference Topology

The link metrics are configured as follows:¶

Metrics of PE1-P2, PE2-P1, P1-P4, P2-P3, P3-P6, P4-P5, P5-P8, P6- P7, P7-PE4, P8-PE3, PE1-PE2 and PE3-PE4 links are 11.¶
Metrics of all other links are 5.¶

8 Link metrics are bidirectional.¶

A.1. Example of SRv6 TE Scenario

TE scenario: SRv6 TE paths are used to steer the VPN service. The deployments of protection are as follows:¶

In the SRv6 Policy of SRv6 TE strict path, disjoint backup candidate path is used as hot standby for end-to-end protection.¶
Ingress PE node uses SRv6 BE paths as backup for end-to-end protection of SRv6 TE paths.¶
Ingress PE node enables BFD for SRv6 Policy. In the case of SRv6 TE strict path, the reverse path of BFD packet keeps consistent with forward path.¶
Ingress PE node enables BFD for locator of egress PE node to monitor the liveness of SRv6 BE path.¶
Ingress PE node enables FRR of paths to backup egress PE node for service protection.¶
All nodes enable TI-LFA for local protection. All nodes enable BFD for links and neighbors.¶

In this scenario, the SRv6 TE strict path is used to steer the VPN traffic flows to the primary egress node PE3, and the SRv6 TE loose path is used for the backup egress node PE4.¶

On the SRv6 data plane, the SRv6 SIDs are assigned using the following rules (just for the convenience of illustration), with Compressed SRv6 Segment List encoding enabled.¶

NodeID:                       An for PEn, Bn for Pn
Locator:                      2001:DB8:NodeID::/48
End SID:                      Locator:1::
End SID with NEXT-CSID:       Locator:2::
End DT:                       Locator:100:: (Only for PE nodes)
End.X SID:                    Locator:NeighborNodeID + F1::
End.X SID with NEXT-CSID:     Locator:NeighborNodeID + F2::

For example, the SRv6 SIDs assigned for PE1 and P8 are as follows.¶

PE1:
  Locator:                    2001:DB8:A1::/48
  End SID:                    2001:DB8:A1:1::
  End SID with NEXT-CSID:     2001:DB8:A1:2::
  End DT:                     2001:DB8:A1:100::
  For PE1->P1:
    End.X SID:                2001:DB8:A1:B1F1::
    End.X SID with NEXT-CSID: 2001:DB8:A1:B1F2::
  For PE1->P2:
    End.X SID:                2001:DB8:A1:B2F1::
    End.X SID with NEXT-CSID: 2001:DB8:A1:B2F2::

P8:
  Locator:                    2001:DB8:B8::/48
  End SID:                    2001:DB8:B8:1::
  End SID with NEXT-CSID:     2001:DB8:B8:2::
  For P8->P5:
    End.X SID:                2001:DB8:B8:B5F1::
    End.X SID with NEXT-CSID: 2001:DB8:B8:B5F2::
  For P8->P6:
    End.X SID:                2001:DB8:B8:B6F1::
    End.X SID with NEXT-CSID: 2001:DB8:B8:B6F2::
  For P8->P7:
    End.X SID:                2001:DB8:B8:B7F1::
    End.X SID with NEXT-CSID: 2001:DB8:B8:B7F2::
  For P8->PE3:
    End.X SID:                2001:DB8:B8:A3F1::
    End.X SID with NEXT-CSID: 2001:DB8:B8:A3F2::
  For P8->PE4:
    End.X SID:                2001:DB8:B8:A4F1::
    End.X SID with NEXT-CSID: 2001:DB8:B8:A4F2::

The SRv6 Policies on PE1 are configured as follows:¶

SRv6 Policy 1 (Strict Path to PE3)
  Candidate Path 1
    Preference: 20
    Segment List: 2001:DB8:A1:B1F2::, 2001:DB8:B1:B3F2::,
    2001:DB8:B3:B5F2::, 2001:DB8:B5:B7F2::, 2001:DB8:B7:A3F1::
  Candidate Path 2
    Preference: 10
    Segment List: 2001:DB8:A1:B2F2::, 2001:DB8:B2:B4F2::,
    2001:DB8:B4:B6F2::, 2001:DB8:B6:B8F2::,2001:DB8:B8:A3F1::

SRv6 Policy 2 (Loose Path to PE4)
  Candidate Path 1
    Preference: 20
    Segment List: 2001:DB8:B4:2::, 2001:DB8:B8:2::,2001:DB8:A4:1::

PE1 installs SRv6 Policy 1, which is the SRv6 TE strict path to PE3, as the primary next-hop for the VPN flow. SRv6 Policy 1 has two disjoint candidate paths. The candidate path with higher preference is selected as the primary candidate path, and the candidate path with lower preference is selected as hot standby backup.¶

Meanwhile, the SRv6 BE path to PE3, the SRv6 TE loose path to PE4 (SRv6 Policy 2), and the SRv6 BE path to PE4 are also installed as backup next-hops. The priorities of multiple backup paths may be decided by either of the egress-node-first strategy or the TE-first strategy.¶

Egress-node-first strategy:¶

primary: SRv6 TE path to primary egress node PE3 (SRv6 Policy 1)¶
backup(1st priority): SRv6 BE path to primary egress node PE3¶
backup(2nd priority): SRv6 TE path to backup egress node PE4 (SRv6 Policy 2)¶
backup(3rd priority): SRv6 BE path to backup egress node PE4¶

TE-first strategy:¶

primary: SRv6 TE path to primary egress node PE3 (SRv6 Policy 1)¶
backup(1st priority): SRv6 TE path to backup egress node PE4 (SRv6 Policy 2)¶
backup(2nd priority): SRv6 BE path to primary egress node PE3¶
backup(3rd priority): SRv6 BE path to backup egress node PE4¶

Egress-node-first strategy is used as an example below.¶

Note: When Compressed SRv6 Segment List encoding is enabled, the Segments[] array in the SRH stores compressed-encoded SIDs. This does not imply a change in the segment processing order. Forwarding nodes must still follow the rules specified in [RFC8754] when processing the SRH, meaning the Active Segment is indicated by the Segments Left pointer and corresponds to the appropriate position in the logically ordered segment list. The compressed encoding only optimizes the storage of each SID in the packet heade.¶

PE1 enables BFD for SRv6 Policy 1 and SRv6 Policy 2 to monitor the liveness of SRv6 TE paths. For SRv6 Policy 1 which is the strict path, the forward and reverse paths of BFD packet should be the same. For example, the primary path of SRv6 Policy 1 is PE1->P1->P3->P5->P7->PE3, so the reverse path should be PE3->P7->P5->P3->P1->PE1. A segment list of such reverse path is installed on PE3. PE1 may send BFD packet with the segment list of SRv6 Policy 1 along with the BSID of reverse path. When the BFD packet is forwarded along the strict path to PE3, PE3 will add an outer IPv6 header with SRH carrying the segment list of [2001:DB8:A3:B7F2::, B7:B5F2, B5:B3F2, B3:B1F2, B1:A1F1], which instructs the packet to be forwarded along the same strict path back to PE1.¶

PE1 enables BFD for locator 2001:DB8:A3::/48 and 2001:DB8:A4::/48 to monitor the liveness of SRv6 BE paths.¶

TI-LFA is enabled on all nodes. BFD are used to monitor the liveness of links and adjacent nodes.¶

Under normal circumstances, PE1 encapsulates the VPN payload in an outer IPv6 header with SRH carrying the segment list of primary candidate path of SRv6 Policy 1 along with the VPN SID advertised by PE3. Using Compressed SRv6 Segment List encoding (CSIDs), the segment list will be encoded as [2001:DB8:A1:B1F2::, B1:B3F2, B3:B5F2, B5:B7F2, B7:A3F1, 2001:DB8:A3:100::].¶

Assume that a failure occurs on P3. The packets are dropped since the failed P3 is on the path. The BFD session of the segment list in the primary candidate path of SRv6 Policy 1 is down, so PE1 triggers the switchover to the backup candidate path of SRv6 Policy 1. Then PE1 encapsulates the VPN payload in an outer IPv6 header with SRH carrying the segment list of [2001:DB8:A1:B2F2::, B2:B4F2, B4:B6F2, B6:B8F2, B8:A3F1, 2001:DB8:A3:100::].¶

Before the recovery of P3, assume that P8 also fails. The BFD session of the segment list in the backup candidate path of SRv6 Policy 1 is also down. Then PE1 triggers the switchover to the 1st priority backup next-hop which is the SRv6 BE path to PE3. PE1 encapsulates the VPN payload in an outer IPv6 header where the destination address is 2001:DB8:A3:100::.¶

Assume that a failure occurs on PE3. Both the BFD sessions of SRv6 Policy 1 and locator 2001:DB8:A3::/48 are down, which means the primary next-hop and the 1st priority backup next-hop are down. So PE1 triggers the switchover to the 2nd priority backup next-hop, which is the SRv6 TE loose path to PE4. Then PE1 encapsulates the VPN payload in an outer IPv6 header with SRH carrying the segment list of [2001:DB8:B4:2::, B8:2, A4:1, 2001:DB8:A4:100::].¶

Before the recovery of PE3, assume that a failure occurs on P6. The fail-timer of BFD from P4 to P6 expires, so P4 perceives the failure. When P4 forwards the VPN packet, the TI-LFA repair path is used. Then, P4 encapsulates the packet in an outer IPv6 Header with SRH carrying a compressed segment-list of [2001:DB8:B5:2::, B5:B7F1]. The packet is forwarded in the repair path P4->P3->P5->P7 according to the outer IPv6 Header and SRH. So the failure is repaired by local protection.¶

Before the recovery of PE3, assume that a failure occurs on P8. When P6 forwards the VPN packet to destination address 2001:DB8:B8:2:: which is one of the segments in the segment list of SRH, the TI-LFA on P6 does not work, since the failed node P8 is the destination. So the packets are dropped. The BFD session of SRv6 Policy 2 is down, and PE1 triggers the switchover to the 3rd priority backup next-hop which is the SRv6 BE path to PE4. Then PE1 encapsulates the VPN payload in an outer IPv6 header where the destination address is 2001:DB8:A4:100::. If the routing convergence is not completed at the moment, P6 will use TI-LFA repair path P6->P5->P7->PE4 to forward the packet. After the routing convergence is done, P nodes will forward the packet along new shortest path excluding P8.¶

Assume that a failure occurs on link PE3-CE2. This is similar with the same failure in section 4.3. The BFD session is still alive, PE1 continues to forward the VPN packets to PE3. PE3 will select the FRR alternate next-hop for CE2 and forward the packet to PE4 with SRv6 BE path.¶