]> China Mobile

China liuyisong@chinamobile.com

China Mobile

Beijing China jiangwenying@chinamobile.com

New H3C Technologies

China linchangwang.04414@h3c.com

Huawei Technologies

China gengxuesong@huawei.com

ZTE Corp.

China liu.yao71@zte.com.cn

ops Network Working Group SRv6, Protection, Guidance This document describes the Operational Guidance for protection of Segment Routing Over IPv6 (SRv6) networks.

Introduction Segment Routing (SR) leverages the source routing paradigm. An ingress node steers a packet through an ordered list of instructions, called "segments". SR can be instantiated on the IPv6 data plane (SRv6). On the SRv6 data plane, a segment is encoded as an IPv6 address (SRv6 SID) , and an ordered list of segments is encoded as an ordered list of SRv6 SIDs in the SR Header (SRH) . This document describes operational guidance for protection mechanisms when the SR data plane is SRv6. Generic SR protection concepts are discussed only to the extent necessary to explain their SRv6 data-plane realization. SR-MPLS data-plane procedures, MPLS label-stack examples, and MPLS-specific operational guidance are outside the scope of this document.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology BE: Best Effort TE: Traffic Engineering SR-MPLS: Segment Routing over MPLS SRv6: Segment Routing over IPv6 CSID: Compressed-SID, as defined in .

Forwarding over SRv6 Network In an SRv6 network, the ingress node steers a packet through an ordered list of segments, which instructs the SRv6 network to forward the packet via a specific path to the egress node. The forwarding path is either an SRv6 BE path or an SRv6 TE path.

SRv6 BE Path An SRv6 BE path is based on shortest path forwarding. On the SRv6 data plane, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. The underlay P nodes between the PEs only need to perform plain IPv6 shortest path forwarding.

Forwarding over SRv6 BE P nodes ---> Egress PE ]]>

SRv6 TE Path In an SRv6 TE path, the ingress PE steers the traffic flow into an SRv6 Policy with an ordered list of segments associated with that SRv6 Policy. The underlay P nodes whose SIDs are part of the segment list are called endpoint nodes. They will be involved in the forwarding path and execute the function associated with the SID. On the SRv6 data plane, the ingress PE encapsulates the payload packet in an outer IPv6 header with the SRH carrying the segment list of the SRv6 policy.

Forwarding over SRv6 TE P nodes ---> Egress PE ]]>

If Compressed Segment List encoding is enabled in the SRv6 network , the segment list in the SRH will be encoded in the compressed way. The compressed SRv6 Segment-List encoding can optimize the packet header length by avoiding the repetition of the Locator-Block and trailing bits with each individual SID. The Compressed SRv6 Segment List encoding mechanism (e.g., using CSIDs) will be used as an example for the encoding of SRv6 TE path in this document. shows the encapsulation of packet using the Compressed SRv6 Segment List encoding mechanism.

Forwarding over SRv6 TE with Compressed Segment List P nodes ---> Egress PE ]]>

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.

Considerations for Path Protection

Local Protection Local protection is performed by the node adjacent to the failed component using fast-reroute techniques . The common method of local repair is to provide a repair path for the destination avoiding the failed component. 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.

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. and 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.

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.

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 . 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.

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:
• 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.

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 , 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.

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 . End.M is a new SRv6 endpoint behavior (a variant of the End.DT6 behavior of ); 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 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 ( for IS-IS, 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 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 ). 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 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 .
• 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 . 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).

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 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 . 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 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.

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.

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.

Single-homed Scenario

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.

Multi-homed Scenario

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.

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.

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.

Considerations for SRv6 Segment List Compression enables a compressed encoding of the SRv6 Segment List in the SRH, which can reduce the SRv6 encapsulation size. The SRv6 Segment-List compression may have an effect on the protection of SRv6 networks, which is discussed in this section.

TI-LFA with CSID When SRv6 Segment List compression is enabled, the repair node may check the compression capabilities of nodes along the repair path and try to use CSIDs to encode the repair path. If NEXT-CSID flavor is preferred, the TI-LFA repair list consist of the End SID with NEXT-CSID flavor of the P node and the End.X SID(s) with NEXT-CSID flavor of the path from P node to Q node, except for the last End.X SID which must not have NEXT-CSID flavor. In addition, the End SID must be a global CSID, and the End.X SID(s) can be local CSID(s). If REPLACE-CSID flavor is preferred, the TI-LFA repair list consist of the End SID with REPLACE-CSID flavor of the P node and the End.X SID(s) with REPLACE-CSID flavor of the path from P node to Q node, except for the last End.X SID which must not have REPLACE-CSID flavor.

Micro-Loop Avoidance with CSID If SRv6 Segment List compression is enabled, the converging node may check the compression capabilities of nodes along the post- convergence path and try to use CSIDs to encode the path. The TI-LFA mechanism can be used to compute the loop-free post- convergence path. If so, the building of TI-LFA repair list with C- SIDs is similar with the previous section.

Considerations for SRv6 Encapsulation Check When calculating SRv6 repair segment lists for TI-LFA and micro-loop prevention, the computing node needs to verify that the resulting SRv6 encapsulation is supported by the nodes that will impose, process, or decapsulate the repair information. This includes the number of SRv6 SIDs carried in the SRH, the use of compressed SID lists, and the endpoint behaviors or flavors required along the repair path. If the resulting SRv6 segment list exceeds the supported SRv6 SID depth or compression capability, the repair path cannot be safely installed.

Considerations for SRv6 Path MTU SRv6 uses IPv6 as the forwarding plane, it is essential to consider MTU impacts to avoid packet discards and optimize bandwidth utilization. To address this, the following guidelines should be followed when planning and configuring SRv6 Path MTU:

• Reserve Additional SRH Header Length: When configuring SRv6 Path MTU, reserve additional space for scenarios such as TI-LFA FRR, micro-loop prevention, or Egress protection, which introduce extra SRH length. This reserved length is implemented by configuring a Path MTU reserve value at the SRv6 headend node.
• Active Path MTU Calculation: The Active Path MTU can be calculated by subtracting the reserved value from the configured SRv6 Path MTU.
• Determining the Reserve Value: The required reserve value is not fixed; depends on the worst-case encapsulation overhead of the protection or repair mechanisms used. Network designs MUST calculate the appropriate reserve based on their specific repair path encapsulation.

Security Considerations This section discusses security considerations for the SRv6-based path and egress protection mechanisms described in this document. These mechanisms introduce some control-plane signalings (e.g., Mirror SID advertisements), state maintenance on protector nodes, and encapsulation changes during repair operations. They operate within the security model of SRv6 as described in Section 8.2 of and Section 7 of . The following paragraphs detail specific threats and recommended mitigations related to these protection mechanisms.

• IGP Authentication: The backup path computation relies on accurate IGP topology information. Without authentication, attackers could inject false topology or capability data, leading to incorrect backup paths. Mitigation: Implement strong IGP authentication (e.g., , ) with proper key management.
• False Protection Signaling: Unauthorized advertisement of Mirror SIDs could divert traffic to malicious nodes during failure events. Mitigation: Accept Mirror SID advertisements only from authorized nodes within the same administrative domain. Filter IGP updates at domain boundaries.
• Mirror SID Authorization: Attackers could spoof packets destined to Mirror SIDs, potentially gaining unauthorized access to service contexts. Mitigation: Perform ingress filtering on protector nodes to accept Mirror SID traffic only from authorized PLRs. Validate service contexts against local forwarding state.
• BFD/OAM Spoofing: Spoofed BFD packets could trigger false failure detection, causing unnecessary protection switching. Mitigation: Enable BFD authentication for all failure detection sessions in the SR domain.
• Tenant Isolation on Protector: During protection, traffic from multiple VPNs/tenants may converge on a single protector node. Mitigation: Ensure strict isolation between service contexts (VRFs) in the protector's forwarding plane. The Mirror SID processing must maintain the same isolation guarantees as primary forwarding.
• Backup Egress Overload: A single backup egress may receive traffic from multiple primary nodes during failure, potentially exceeding its capacity. Mitigation: (1) Provision backup egress with sufficient capacity for aggregated protected traffic; (2) Consider traffic profiles when assigning backup roles; (3) Implement QoS policies to prioritize critical traffic during congestion; (4) For critical deployments, use multiple backup egress nodes.

IANA Considerations This document has no IANA actions.

Acknowledgements The authors would like to acknowledge Daniel Voyer for their careful reviews and very helpful comments.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring. This document updates RFC 5880. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network. The document also specifies the OAM flag (O-flag) in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. This document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the Point of Local Repair (PLR), reducing the operational need to control the tie-breaks among various FRR options. Informative References This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK] This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes. Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication. The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. China Unicom Huawei Futurewei Verizon China Unicom This document describes the mechanism and operational guidelines for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. TI-LFA specifies fast protections for transit nodes and links of an SR path, but does not present protections for the egress node. The solution uses a Mirror SID (End.M) behavior to steer traffic to a protector egress upon failure of the primary egress. The IGP extensions (IS-IS/OSPFv3) can be used to advertise Mirror SID and protected locators. China Mobile China Mobile New H3C Technologies Huawei Technologies New H3C Technologies This document describes a SRv6 egress node protection mechanism in multi-homed scenarios.

Examples 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.

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.

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. For example, the SRv6 SIDs assigned for PE1 and P8 are as follows. 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: 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 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.

Contributors H3C

chen.mengxiao@h3c.com