| Internet-Draft | Egress Protection | October 2026 |
| He, et al. | Expires 13 April 2027 | [Page] |
This document describes the mechanism and operational considerations for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. Topology Independent Loop-Free Alternate (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 Interior Gateway Protocol (IGP) (IS-IS/OSPFv3) extensions used to advertise the Mirror SID and protected locators are specified in [I-D.ietf-lsr-srv6-mirror-sid-igp-encoding]; they build on the IS-IS and OSPFv3 SRv6 extensions defined in [RFC9352] and [RFC9513].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC9855] and TI-LFA provide fast protection for transit nodes and links of an SR path (those within a link-state IGP area), but do not protect the egress node or its egress link. [RFC9855] Section 7.2 addresses an intermediate segment endpoint (where the packet continues as a transit packet after segment processing), and TI-LFA only pre-computes backup paths that keep the same destination. Neither addresses the final egress node of an SR path, where traffic is decapsulated and delivered outside the IGP domain. This document fills that gap for SRv6 paths by introducing a Mirror SID (End.M) mechanism that lets a backup egress node take over the forwarding behavior of the failed egress node, extending protection to the network edge.¶
[RFC8400] and [RFC8679] specify fast protection for the egress node and link of an MPLS TE LSP tunnel, but do not address SRv6 paths.¶
Full egress protection for an SRv6 path can be provided by 1+1 global protection, but that duplicates the path and complicates operation. This document instead protects the egress node and link by extending the IGP and using a Mirror SID. The solution is scoped to a single link-state IGP area/level -- a deliberate design choice so that the Point of Local Repair (PLR), the protector, and the failed egress share one flooding domain and can compute congruent LFA/TI-LFA backup paths. It relies on IGP (IS-IS/OSPFv3) extensions ([RFC9352], [RFC9513]) -- specifically the advertisement of the Mirror SID and protected locators specified in [I-D.ietf-lsr-srv6-mirror-sid-igp-encoding] -- to distribute the required state, and on BGP ([RFC9252]) or configuration to obtain the forwarding behavior of the protected service SIDs. The approach is intended for modest numbers of protected services; large-scale deployments are not recommended due to IGP scaling considerations.¶
A related mechanism, [I-D.cheng-rtgwg-srv6-multihome-egress-protection] protects the SRv6 egress using a different data-plane approach (a Penultimate Segment Decapsulation Flavor with a pre-installed backup SID) and without IGP extensions. That document protects the egress node, whereas this document protects both the egress node and its egress link. The two mechanisms are complementary and target different deployment constraints.¶
The following terminologies are used in this document.¶
This section describes the mechanism of SRv6 path egress protection and illustrates it through an example.¶
All advertisements and computations in this section are confined to a single link-state IGP area/level for SRv6.¶
The following notation is used throughout this document to represent packet formats:¶
- (SA, DA) represents an IPv6 header with Source Address SA and Destination Address DA.¶
- (SL1, SL2, ..., SLn; SL=k) represents an SRH (Segment Routing Header) with Segment List [SL1, SL2, ..., SLn] and Segments Left field set to k.¶
- Pkt0 represents the payload following the SRv6 encapsulation headers.¶
- Nested headers are represented by concatenation. For example, (T, Mirror SID)(S, SIDa) Pkt0 represents an outer IPv6 header with source T and destination Mirror SID, encapsulating an inner IPv6 header with source S and destination SIDa, followed by payload Pkt0.¶
- When an SRH is present, it is shown in parentheses following the IPv6 header. For example, (T, S1)(Mirror SID, Sn, ..., S1; SL=n)(S, SIDa) Pkt0 represents an outer IPv6 header (T, S1) with an SRH containing Segment List [Mirror SID, Sn, ..., S1] with SL=n, encapsulating an inner IPv6 header (S, SIDa) and payload Pkt0.¶
This notation is consistent with the packet format descriptions used in [RFC8754] and [RFC8986].¶
The IPv6 addresses used in the examples throughout this document are drawn from the documentation address block 3fff::/20 reserved by [RFC9637], and the IPv4 addresses are drawn from the documentation address blocks reserved by [RFC5737].¶
Figure 1 is used to explain the mechanism of SRv6 path egress node and egress link protection.¶
******* *******SIDa
[PE1]-----[P1]-----[PEA]---[CE2] PEA Egress
/ | |& | \ / PEB Backup Egress
/ | |& | \ / CEx Customer Edge
[CE1] | |& | X Px Provider Router
\ | |& | / \ *** SRv6 Path
\ | |& &&&&& | / \ &&& Backup Path
[PE2]-----[P2]-----[PEB]---[CE3]
Mirror SID
In Figure 1, P2 is a provider router that is not directly connected to the protected egress node PEA, and it is not a penultimate node of the SRv6 path toward PEA's locator and therefore does not act as a PLR. Its behavior during and after a failure of PEA is described in Section 5.5.¶
Desired Pathways in Figure 1:¶
Node PEA (Provider Edge A, i.e., the primary/protected egress node) in Figure 1 is the egress node of the SRv6 path from PE1 to PEA and has SIDa, which is the active Segment Identifier (SID) at PEA -- specifically, the SID that identifies the protected service (e.g., a VPN SID) or the protected egress link, and whose forwarding behavior the protector PEB must replicate. Node PEB (Provider Edge B, aka backup egress or protector) is the backup egress node that provides the fast protection for PEA. Node P1 is the penultimate node of the SRv6 path toward PEA's locator -- that is, the upstream node whose own shortest-path next hop toward the protected locator is PEA itself -- and it acts as the PLR (refer to [RFC9855]) that provides the fast protection for PEA.¶
In implementation, each node consults its own SPF tree and forwarding state, if its next hop toward the protected locator is PEA itself (the node that advertised the locator), it is a penultimate node for the locator, acts as a PLR, and installs a Repair List (RL) toward the protector PEB; otherwise it is not a PLR and simply forwards along the SRv6 path. Where several nodes are penultimate nodes for the same locator (e.g., over equal-cost paths), each independently acts as a PLR with its own RL. PEB does not need to know who the PLRs are, its advertisement is visible to the whole IGP area/level, and each node decides locally whether it has a role to play.¶
Mirror SID Overview: The SRv6 Mirror SID (End.M) is the core mechanism used in this document for egress protection. A Mirror SID is configured on the protector (PEB) and associated with a FIB (Forwarding Information Base) table that replicates the forwarding behavior of the protected egress node (PEA). When traffic is rerouted to PEB due to PEA failure, the Mirror SID enables PEB to decapsulate the traffic and forward it using PEA's forwarding context. The End.M behavior is a variation of the End.DT6 behavior defined in [RFC8986] Section 4.6, and its detailed processing is described in Step 3c below. The IANA assignment for End.M is described in Section 6.¶
Steps in Creating the Pathways:¶
Step 1: Normal Pathway Set-up¶
Normal path set-up establishes the SR path from ingress PE1 to egress PEA via P1. Ingress PE1 imports the traffic from CE1 into the SR path and egress PEA delivers the traffic from the SRv6 path to CE2.¶
Step 2: Backup Pathway Set-up¶
Step 2a: PEB Announces to Protect PEA¶
When PEB is selected as a backup egress node to protect the egress node PEA, a SRv6 Mirror SID (refer to Section 5.1 of [RFC8402]) is configured on PEB to protect PEA. PEB MUST advertise this information through IGP (IS-IS or OSPFv3) as specified in [I-D.ietf-lsr-srv6-mirror-sid-igp-encoding] (which extends [RFC9352] and [RFC9513]), and the advertisement includes the Mirror SID and the egress PEA. The information is represented by <PEB, PEA, Mirror SID>, together with the protected locators. This IGP signaling does not enumerate per-service entries.¶
Step 2b: PEB Learns Forwarding Behavior of PEA¶
PEB MUST learn the forwarding behavior of SIDa (the active SRv6 segment at PEA). When SIDa is a Service SID (e.g., a VPN SID) anchored on PEA, PEB learns its forwarding behavior via the BGP-based overlay as per [RFC9252] or by configuration; this document does not introduce per-service signaling in IGP. This enables PEB to reproduce the egress behavior for packets whose active segment at PEA is a Service SID, without requiring IGP to flood per-service state.¶
Step 2c: PEB Programs the Mirror SID Context for PEA¶
When PEB learns the forwarding behavior of SIDa of PEA, it MUST program the Mirror SID context (i.e., the forwarding table identified by the Mirror SID, also called the PEA context) so that packets whose active segment is SIDa are forwarded according to PEA's behavior. The exact implementation (for example, installing a forwarding entry) is a local matter; the observable requirement is that the Mirror SID context reproduces PEA's forwarding behavior for SIDa. This supports Service SID semantics at the protector. However, for large numbers of Service SIDs, operators SHOULD avoid deployments where protection requires fine-grained per-service modeling in IGP, as it may increase IGP flooding and affect convergence.¶
Step 2d: P1 as PLR Prepares to Protect PEA by PEB¶
After P1 as PLR receives the information <PEB, PEA, Mirror SID> and knows that PEB wants to protect SIDa of PEA, it computes an LFA (Loop-Free Alternate) for PEA assuming that PEA and PEB have the same anycast address. A Repair List (RL) (or say backup path) is obtained based on the LFA. It is one of the following:¶
When more than one usable <PEB, PEA, Mirror SID> association exists for the same protected locator, the PLR selects exactly one of them, as described in Section 5.2. The RL that the PLR installs may itself be a compressed segment list; see Section 3.3.¶
Step 3: Backup Path Is Engaged upon PEA Failure¶
Step 3a: P1 Detects That the Path to PEA Is No Longer Usable¶
The PLR (P1) engages the backup path when it can no longer deliver traffic to the egress node PEA. Three failure scopes are relevant to this mechanism; they are listed separately because they are detected by different means, even though the action taken by the PLR is the same for the first two of them:¶
- Case (a), failure of the link between P1 and PEA (or of P1's interface toward PEA): PEA itself may still be up and reachable from other nodes, but P1 can no longer send traffic to it directly.¶
- Case (b), failure of the PEA node: PEA is down and unreachable from the whole IGP area/level.¶
- Case (c), failure of the egress link between PEA and the CE: PEA is up and reachable, but it can no longer deliver traffic to the customer. This case is handled by PEA itself acting as a PLR, as described in Section 3.2.2.¶
From the viewpoint of P1, cases (a) and (b) are equivalent: in both cases P1 must stop sending traffic toward PEA and use its pre-computed Repair List (RL) toward the protector PEB. A failure of the P1-PEA link therefore also engages the Mirror SID protection, and the traffic is delivered to the destination through PEB. In general, a single detection mechanism cannot reliably distinguish case (a) from case (b), and this document does not require such a distinction, because the action to be taken is the same. What MUST be detected is that the path from P1 to PEA is no longer usable.¶
Detection mechanisms that can trigger the switch to the backup path include:¶
- BFD (Bidirectional Forwarding Detection) [RFC5880]: A BFD session is established between P1 (the PLR) and PEA, providing sub-second detection of a failure that affects the P1-PEA path (cases (a) and (b)). BFD authentication is RECOMMENDED (see Section 4.2).¶
- IGP Hello/adjacency detection: Loss of the IS-IS or OSPFv3 adjacency between P1 and PEA indicates that the P1-PEA link or the PEA node is no longer usable (cases (a) and (b)). IGP hello timers are typically slower than BFD and may result in longer detection times.¶
- Interface or link-level detection: Link-layer signal loss, carrier loss, or interface-down events on the P1-PEA link provide immediate detection of case (a). Such events detect a failure of the link or of the interface, not necessarily a failure of the PEA node.¶
- Node-liveness detection: mechanisms that test the liveness of the PEA node itself, such as a BFD session or an IGP adjacency with PEA, are the closest available approximation to the detection of case (b).¶
For the detection of case (c), the egress link (PEA-CE) failure, see Section 3.2.2:¶
- BFD on the PEA-CE link: When BFD is enabled on the link between PEA and CE, PEA detects the egress link failure and triggers protection by rerouting traffic to PEB.¶
- CE involvement: The CE MAY participate in failure detection. For example, if the CE detects a link failure, it can withdraw routes or signal the failure to PEA via BGP. In some deployments, BFD may be enabled between PEA and CE across the customer-operator boundary. The level of CE involvement depends on the operational agreement between the operator and the customer.¶
- Ethernet OAM [IEEE802.1ag]: Connectivity Fault Management (CFM) can detect link or node failures in Ethernet-based access networks.¶
BFD is RECOMMENDED as the primary detection mechanism due to its fast detection capability and wide deployment: between the PLR and PEA for cases (a) and (b), and on the PEA-CE link for case (c). The choice of detection mechanism depends on the deployment scenario, the required detection time, and operational constraints. Note that the mechanisms listed above are not failure-scope classifiers: an interface-down event indicates a link failure (case (a)), whereas a BFD session or an IGP adjacency toward PEA is the closest available approximation for a node failure (case (b)). As stated above, the action taken by the PLR is the same for both cases.¶
Step 3b: P1 Sends Packet with SIDa to Backup Egress PEB¶
Upon detecting egress node PEA failure, P1 as PLR sends the packet with SIDa carried by the SR path to backup egress node PEB, but MUST encapsulate the packet before sending it by executing H.Encaps with the Repair List (RL) and a Source Address T, where T is a source address of P1 (e.g., a loopback or interface address of the PLR).¶
P1 as PLR will retain the route to PEA for a period of time after its IGP converges on the failure of PEA. Thus the backup path for PEA will be used when the other nodes (such as PE1) still send the packet to PEA via P1 since their IGPs do not converge on the failure.¶
Using the notation of Section 3.1 (consistent with the packet illustrations in [RFC8754] and [RFC8986]), suppose that the packet received by P1 is represented by Pkt = (S, SID-P1)(SIDa, SID-P1; SL=1) Pkt0, where SA = S and DA = SID-P1 (i.e., SID of P1), and Pkt0 is the rest of the packet. P1 sets DA to SIDa, updates SL and executes H.Encaps.¶
The execution of H.Encaps pushes an IPv6 header to Pkt and sets some fields in the outer and inner IPv6 header to produce an encapsulated packet Pkt'. Pkt' will be one of the following:¶
Step 3c: PEB Decapsulates Packet and Forwards It¶
When PEB receives the re-routed packet -- i.e., a packet whose outer destination is the Mirror SID (the form (T, Mirror SID)(S, SIDa) Pkt0 shown in Step 3b is one instance; the same processing applies when an SRH is present in the outer header, e.g., (T, S1)(Mirror SID, Sn, ..., S1; SL=n)(S, SIDa) Pkt0) -- it decapsulates the outer IPv6 header and forwards the decapsulated packet using the FIB table Tm identified by the Mirror SID as a variant of the End.DT6 behavior. The Mirror SID is called End.M.¶
When a node processes a packet whose Destination Address is a locally instantiated End.M SID, it MUST perform the following steps in order:¶
If any of these steps fail, the packet MUST be dropped and an appropriate error counter SHOULD be incremented.¶
The processing is summarized in the following pseudocode, consistent with the numbered steps above:¶
S01. If the Destination Address of the packet is not a locally
instantiated End.M SID, then
S02. Process as specified in Section 4.1.1 of RFC 8986.
S03. Else (the Destination Address is a local End.M SID):
S04. Remove the outer IPv6 header together with all its
extension headers, including any SRH.
S05. Identify the IPv6 FIB table Tm associated with the
context of the End.M SID.
S06. If Tm cannot be determined, then
S07. Drop the packet and increment the corresponding error
counter.
S08. Else:
S09. Submit the inner packet to Tm for forwarding.
S10. End If
S11. End If
The behavior of Mirror SID (End.M for short) is a variant of the End.DT6 behavior (refer to Section 4.6 of [RFC8986]). The End.M SID MUST be the last segment in an SR path, and a SID instance is associated with an IPv6 FIB table Tm.¶
Egress link protection is similar to egress node protection for SRv6 [RFC8679]. When the egress link from egress node PEA to CE2 fails, PEA acting as a PLR reroutes the traffic to backup egress node PEB via a backup path. Specifically, PEA as a PLR pre-computes a Repair List (RL) (or say backup path) toward PEB after receiving <PEB, PEA, Mirror SID> and knowing that PEB wants to protect SIDa of PEA. When the link fails, PEA as PLR sends the packet with SIDa by executing H.Encaps with the Repair List (RL). All operations occur within the same IGP flooding scope; no per-service signaling is introduced in IGP.¶
The egress link failure is detected by PEA using one or more of the mechanisms described in Step 3a of Section 3.2.1: BFD on the PEA-CE link, CE participation (e.g., route withdrawal or BGP signaling), or Ethernet OAM [IEEE802.1ag]. BFD is RECOMMENDED as the primary detection mechanism. When the link failure is detected, PEA performs the same H.Encaps-based reroute as in egress node protection, sending the packet to PEB via the pre-computed Repair List (RL).¶
Segment lists can be compressed as specified in [RFC9800]. Because a Mirror SID (End.M) is a variant of the End.DT6 behavior, and End.DT6 is one of the behaviors for which [RFC9800] defines a REPLACE-CSID flavor, a Mirror SID can be the last segment of a compressed segment list.¶
This document defines the REPLACE-CSID flavor of End.M, referred to as "End.M with REPLACE-CSID". As specified in [RFC9800], a NEXT-CSID flavor is not defined for behaviors that are always the last segment of an SR path, because any SID can be the last element of a segment sequence that is compressed with the NEXT-CSID flavor. End.M is always the last segment of an SR path; therefore no NEXT-CSID flavor is defined for End.M either. The processing of "End.M with REPLACE-CSID" is the same as the processing of End.M described in Step 3c of Section 3.2.1, except that the Mirror SID is encoded in a CSID container as specified in [RFC9800] and the Argument, if present, is ignored -- the same treatment that [RFC9800] specifies for "End.DT6 with REPLACE-CSID".¶
Consequently, the Repair List (RL) that the PLR pushes when it redirects traffic to the protector may itself be a compressed segment list. The following considerations then apply:¶
- The Mirror SID MUST remain the last segment of the RL. When the RL is compressed, the PLR uses the compressed representation of the Mirror SID (i.e., End.M with REPLACE-CSID), and the Mirror SID is the last segment of the compressed sequence.¶
- The protector PEB MUST be able to process a packet whose outer header carries a compressed segment list and to recognize the Mirror SID that terminates that list. If a PEB does not support compressed segment lists, the operator MUST NOT use compressed segment lists on paths whose egress protection is provided by that PEB.¶
- Compression is a property of an SRv6 path and is independent of the egress protection mechanism. The primary SRv6 path (from the ingress node to PEA) and the backup path (from the PLR to PEB) may use different encodings, and the Mirror SID association advertised in the IGP is not affected by whether compression is used on either path.¶
- The protected locators carried in the IGP advertisement are IPv6 prefixes and are advertised in their uncompressed form; compression applies to the encoding of a segment list in the data plane, not to the IGP advertisement of locators. Where the locator or the Mirror SID of a node has a compressed SID structure, the node SHOULD advertise the corresponding SRv6 SID Structure information (as defined in [RFC9352] and [RFC9513]) so that other nodes can interpret the SID correctly.¶
Figure 3 shows an example of fast protecting egress node PE3 of an SRv6 path, which is from ingress node PE1 to egress node PE3.¶
SID-P1: 3fff:5::A100 Locator: 3fff:3::/64
******* ******* VPN SID: 3fff:3::B100
[PE1]-----[P1]-----[PE3]---[CE2] PE3 Egress
/ | |& | \ / PE4 Backup Egress
/ | |& | \ / CEx Customer Edge
[CE1] | |& | X Px Provider Router
\ | |& | / \ *** SR Path
\ | |& &&&&& | / \ &&& Backup Path
[PE2]-----[P2]-----[PE4]---[CE3]
Locator: 3fff:4::/64
VPN SID: 3fff:4::B100
Mirror SID: 3fff:4::3, protect 3fff:3::/64
Note: This example demonstrates egress protection at the locator level. The Mirror SID (3fff:4::3) protects PE3's entire locator (3fff:3::/64) rather than an individual Service SID. The VPN SID 3fff:3::B100 shown below is a representative Service SID under that locator, used here for illustrative purposes; its per-service forwarding behavior is learned by PE4 via BGP [RFC9252] or configuration, not through IGP signaling. The IGP only advertises the locator-level protection association <PE4, PE3, 3fff:4::3> together with the protected locator, as described in Section 3.2.1.¶
Desired Pathways in Figure 3:¶
Node P1's pre-computed backup path for PE3 is from P1 to PE4 via P2. In normal operations, after receiving a packet with SRv6 destination PE3, P1 forwards the packet to PE3 according to its FIB. When PE3 receives the packet, it sends the packet to CE2.¶
When PE3 fails, P1 as PLR detects the failure through using a failure detection mechanism such as BFD and forwards the packet to PE4 via the backup path. When PE4 receives the packet, it sends the packet to the same CE2.¶
When P1's IGP converges on the failure of PE3, P1 as PLR needs to retain the route to PE3 for a period of time. Thus the backup path for PE3 will be used when the other nodes (such as PE1) still send the packet to PE3 via P1 since their IGPs do not converge on the failure.¶
In Figure 3, Both CE2 and CE3 are dual-homed to PE3 and PE4. PE3 has a locator 3fff:3::/64 and a VPN SID 3fff:3::B100. PE4 has a locator 3fff:4::/64 and VPN SID 3fff:4::B100. A Mirror SID 3fff:4::3 is configured on PE4 for protecting PE3 with locator 3fff:3::/64. P1 has SID-P1 = 3fff:5::A100.¶
Steps in Creating the Pathways:¶
Step 1: Normal Pathway Set-up [PEB is PE4, PEA is PE3]¶
Step 2: Backup Pathway Set-up¶
Step 2a: PE4 (aka PEB) Announces to Protect PE3 (aka PEA)¶
After the configuration, PE4 advertises this information through an IGP LS (i.e., LSA in OSPFv3 or LSP in IS-IS), as specified in [I-D.ietf-lsr-srv6-mirror-sid-igp-encoding], which includes PE3's locator and Mirror SID 3fff:4::3. Every node in the SR domain will receive this IGP LS, which indicates that PE4 wants to protect PE3 (indicated by PE3's locator) with Mirror SID 3fff:4::3.¶
Step 2b: PE4 (aka PEB) Gets Forwarding Behavior of PE3 (aka PEA)¶
The IGP advertisement only associates the Mirror SID 3fff:4::3 with PE3's locator 3fff:3::/64; it does not enumerate any per-service entries. When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs to PE3 that is protected by PE4 through Mirror SID 3fff:4::3, it learns the forwarding behavior for that Service SID via BGP [RFC9252] or configuration, outside the IGP. For example, local PE4 has Prefix 203.0.113.1 with VPN SID 3fff:4::B100; when PE4 receives prefix 203.0.113.1 with remote PE3's VPN SID 3fff:3::B100, it knows that they are for the same VPN and that both SIDs are anchored on the same CE2.¶
The forwarding behaviors for these two VPN SIDs are the same from function's point of view. If the behavior for PE3's VPN SID in PE3 forwards the packet with it to CE2, then the behavior for PE4's VPN SID in PE4 forwards the packet to the same CE2; and vice versa. Because protection is at the locator level, any Service SID under 3fff:3::/64 is handled through the same Mirror SID context without requiring additional IGP state.¶
Step 2c: PE4 (aka PEB) Creates FIB for PE3 (aka PEA)¶
PE4 creates a forwarding entry for PE3's VPN SID 3fff:3::B100 in the FIB table identified by Mirror SID 3fff:4::3 according to the forwarding behavior for PE4's VPN SID 3fff:4::B100. More generally, because protection is at the locator level, PE4 creates forwarding entries for all Service SIDs under PE3's locator 3fff:3::/64 as their forwarding behaviors are learned via BGP [RFC9252] or configuration; no per-service state is introduced in IGP.¶
Step 2d: P1 Prepares to Protect PE3 (aka PEA) by PE4 (aka PEB)¶
Node P1's pre-computed backup path for destination PE3 is from P1 to PE4 having mirror SID 3fff:4::3. When P1 receives a packet destined to PE3's VPN SID 3fff:3::B100, in normal operations, it forwards the packet with source 3fff:1::1 and destination PE3's VPN SID 3fff:3::B100 according to the FIB using the destination PE3's VPN SID 3fff:3::B100.¶
Step 3: Backup Path Is Engaged upon PE3 (aka PEA) Failure¶
Step 3a: P1 Detects PE3 (aka PEA) Failure via BFD¶
Step 3b: P1 Sends Packet with SIDa to Backup Egress PE4 (aka PEB)¶
When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path pre-computed. P1 encapsulates the packet using H.Encaps before sending it to PE4.¶
Suppose that the packet received by P1 is represented by Pkt = (SA=3fff:1::1,DA=3fff:5::A100)(SIDa=3fff:3::B100,SID-P1=3fff:5::A100;SL=1) Pkt0, where DA = 3fff:5::A100 is P1's SID, 3fff:3::B100 is PE3's VPN SID, and Pkt0 is the rest of the packet. P1 sets DA to 3fff:3::B100, updates SL, and encapsulates the packet. The encapsulated packet Pkt' will be one of the following:¶
where T is a Source Address, <S1, ..., Sn> is the TI-LFA Repair List to PE4 computed by P1.¶
Step 3c: PE4 (aka PEB) Decapsulates Packet and Forwards It¶
When PE4 receives the re-routed packet, it decapsulates the packet and forwards the decapsulated packet by executing the behavior of End.M for the Mirror SID that is associated with the IPv6 FIB table for PE3. The packet received by PE4 is (T, Mirror SID 3fff:4::3) (3fff:1::1, PE3's VPN SID 3fff:3::B100)Pkt0.¶
PE4 obtains Mirror SID 3fff:4::3 in the outer IPv6 header of the packet, removes this outer IPv6 header, and then processes the inner IPv6 packet (3fff:1::1, 3fff:3::B100)Pkt0. It finds the FIB table for PE3 using Mirror SID 3fff:4::3 as the context ID, gets the forwarding entry for PE3's VPN SID 3fff:3::B100 from the table, and forwards the packet to CE2 using the entry.¶
Note:This example demonstrates that a Service SID (e.g., a VPN SID) is preserved at the protector via the Mirror-SID context, and that this is achieved through locator-level protection: the IGP advertises only the locator-level association <PE4, PE3, 3fff:4::3> with the protected locator, while per-service forwarding behaviors are learned via BGP [RFC9252] or configuration. However, at large scale (many VPN/service instances and/or random multi-homing of services across multiple protectors), the amount of egress-protection information to be flooded in IGP increases and may affect convergence; such deployments are not recommended for this IGP-based mechanism. Operators SHOULD consolidate protectors per egress and limit per-service granularity in IGP.¶
The egress protection specified in this document involves rerouting traffic around an egress node or link failure, via a backup path from a PLR to a backup egress node. The forwarding performed by the nodes in the data plane is anticipated, as part of the planning of egress protection.¶
The extensions to control plane protocol IS-IS or OSPFv3 are used to support the egress protection on the nodes in an OSPFv3 or IS-IS area. The area is in a single administrative domain.¶
In addition, the PLR and backup egress node are located close to the egress node, which is in the same administrative domain.¶
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304] and [RFC5310]. While IS-IS is deployed under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the IS-IS routing domain. In these deployments, the stronger authentication mechanisms defined in the aforementioned documents SHOULD be used.¶
Security concerns for OSPFv3 are described in [RFC5340] and [RFC8362]. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] and [RFC7166] SHOULD be used.¶
SRv6-Specific Security Considerations:The Mirror SID mechanism introduces the following SRv6-specific security considerations:¶
- Mirror SID Authentication: Since the Mirror SID is advertised through IGP, it is essential that IGP advertisements are authenticated to prevent malicious nodes from advertising counterfeit Mirror SIDs. Implementations SHOULD support the cryptographic authentication mechanisms specified in [RFC5304] for IS-IS and [RFC4552] for OSPFv3.¶
- Context Isolation: The FIB table identified by the Mirror SID MUST be properly isolated to prevent traffic from one protected egress node from being forwarded using the context of another egress node. Implementations MUST ensure that the context identified by a Mirror SID is only used for packets explicitly addressed to that Mirror SID.¶
Security attacks may sometimes come from a customer domain. Such attacks are not introduced by the egress protection in this document and may occur regardless of the existence of egress protection. In one possible case, the egress link between an egress node and a CE could become a point of attack. An attacker that gains control of the CE might use it to simulate link failures and trigger constant and cascading activities in the network. If egress link protection is in place, egress link protection activities may also be triggered. As a general solution to defeat the attack, a damping mechanism SHOULD be used by the egress node to promptly suppress the services associated with the link or CE. The egress node would stop delivering the services to CE, essentially detaching them from the network and eliminating the effect of the simulated link failures. All protocol extensions operate within a single link-state IGP area/level; no per-service signaling is introduced in IGP, and references to BGP concern only how a protector may learn forwarding behavior.When a protector learns per-service forwarding behavior via mechanisms outside the IGP (e.g., BGP as per [RFC9252] or local configuration), it SHOULD validate that the behavior is authorized and consistent with the protected egress node's capabilities advertised through those same external mechanisms. This document does not introduce per-service signaling in the IGP for this validation.¶
The following threats are addressed by corresponding mechanisms:¶
-- Unauthorized Rerouting: An attacker could attempt to trigger unnecessary rerouting by advertising false failure information. This is mitigated by:¶
* Using BFD [RFC5880] (preferably with authentication, as described in Section 4.2) or other reliable failure detection mechanisms.¶
* Authenticating IGP advertisements.¶
* Implementing damping mechanisms to prevent flapping.¶
-- Traffic Interception: An attacker could attempt to become a protector to intercept traffic. This is mitigated by:¶
* Limiting protector selection to trusted nodes within the same administrative domain.¶
* Authenticating IGP advertisements of Mirror SIDs.¶
* Monitoring for unexpected protector advertisements.¶
-- Denial of Service: An attacker could attempt to overwhelm the protector with traffic. This is mitigated by:¶
* Implementing rate limiting at the protector.¶
* Using proper FIB table isolation.¶
* Monitoring traffic patterns.¶
-- Control Plane Overload: An attacker could attempt to flood the IGP with excessive protection advertisements, causing control plane overload and convergence issues.This is mitigated by:¶
* Limit the number of protection relationships per node.¶
* Implement IGP flooding rate limiting.¶
* Use the operational considerations in Section 5 to limit the scale of deployments.¶
* Monitor IGP database size and convergence times.¶
BFD [RFC5880] is used as a primary mechanism for detecting egress node or link failures (see Step 3a of Section 3.2.1). To mitigate security threats associated with BFD misuse, the following measures are RECOMMENDED:¶
1. BFD Authentication: Implementations SHOULD support and enable BFD cryptographic authentication as defined in [RFC5880] Section 6.7. This prevents attackers from injecting forged BFD packets that could trigger false failure detection and unauthorized traffic rerouting.¶
2. BFD Deployment for Egress Node Protection: When BFD is used between the PLR and the PEA for egress node protection, the BFD session SHOULD be established over the IGP domain's authenticated infrastructure. The single-hop BFD operation between the PLR and the PEA follows [RFC5881]. When the PEA is a domain border node, BFD authentication becomes critical, as the PEA may have interfaces facing external networks.¶
3. BFD for Egress Link Protection: When BFD is used to detect egress link failures (between PEA and CE), the BFD session may span administrative boundaries. The single-hop BFD operation between the PEA and the CE follows [RFC5881]. In such cases, operators SHOULD use BFD authentication and ensure that BFD session parameters are agreed upon between the operator and the CE administrator.¶
4. Alternative Detection Mechanisms: In addition to BFD, other mechanisms such as hardware-level link detection, IGP hello timers, or Ethernet OAM [IEEE802.1ag] MAY be used either alone or in combination with BFD to provide layered failure detection.¶
An attacker may attempt to compromise the link between the protector (PEB) and the CE. In this scenario:¶
1. Traffic Interception: The attacker can intercept traffic rerouted from PEA to PEB and destined for the CE, potentially accessing sensitive data.¶
2. Traffic Injection: The attacker can inject malicious traffic toward the CE or the network through the compromised link.¶
3. Service Disruption: The attacker can disrupt connectivity between PEB and CE, causing the protection mechanism to fail when PEA fails.¶
Mitigation measures include:¶
- Physical and link-layer security (e.g., MACsec [IEEE802.1AE]) SHOULD be used to secure the PEB-CE link when feasible.¶
- When the PEB-CE link crosses administrative boundaries, operators SHOULD establish security agreements with the CE administrator.¶
- Monitoring of traffic patterns on the PEB-CE link can help detect anomalous behavior.¶
- BFD authentication on the PEB-CE link (see Section 4.2) can prevent false failure injection.¶
This section provides operational guidance for deploying the SRv6 path egress protection mechanism described in this document, in line with the IETF guidelines for operations and management considerations (see [RFC5706]).¶
Within an IGP area/level, prefer a single protector PEB per PEA to minimize the number of SRv6 <PEB, PEA, Mirror SID> advertisements. The choice of PEB SHOULD be aligned with the multi-homing topology of the destination CE:¶
- When the CE is multi-homed to both PEA and PEB, PEB is the natural choice as the protector, since it already has connectivity to the CE and can deliver traffic upon PEA failure.¶
- When the CE is multi-homed to PEA and a different PE (not PEB), the protector PEB MUST have a path to reach the CE through that other PE, or an alternative protector that has direct CE connectivity SHOULD be considered.¶
- When multiple CEs served by PEA have different multi-homing topologies, the operator SHOULD evaluate whether a single protector can adequately serve all CEs, or whether multiple protectors are needed.¶
More than one protector may advertise protection for the same locator, and a single protector may advertise several Mirror SIDs; the IGP encoding does not require the association between a protected locator and a Mirror SID to be unique. When a PLR has more than one usable <PEB, PEA, Mirror SID> association for a given protected locator, it MUST select exactly one of them when it builds the Repair List, so that all packets for that locator follow the same backup path and so that transient changes in the IGP database do not cause forwarding churn.¶
The following rules are RECOMMENDED and SHOULD be applied in order:¶
An implementation SHOULD allow the operator to designate a preferred protector for a protected locator; a configured preference takes precedence over the rules above. As with any other repair mechanism, a selected Mirror SID MUST NOT be used if doing so would create a forwarding loop or if the protector is not reachable; in that case the next Mirror SID in the order above SHOULD be used.¶
For example, let the protected locator be 3fff:3::/64, and assume that PEB1 advertises the Mirror SID 3fff:4::3 and PEB2 advertises the Mirror SID 3fff:6::3, and that the IGP cost from the PLR to PEB1 is 20 while the IGP cost from the PLR to PEB2 is 35:¶
All nodes that perform this selection use the same rules and the same inputs, so that the choice is consistent across the IGP area/level. The encoding and advertisement of the Mirror SID and of the protected locators used by these rules are specified in [I-D.ietf-lsr-srv6-mirror-sid-igp-encoding].¶
The Mirror SID mechanism complements, and partially overlaps with, IGP LFA/TI-LFA repair. The two mechanisms protect different failure scopes:¶
- LFA/TI-LFA protects transit nodes and links. It computes a repair path that keeps traffic on a path toward the original destination (PEA), and therefore it cannot restore traffic when the egress node PEA itself has failed.¶
- Mirror SID egress protection protects the egress node and, through the egress link protection procedure, the egress link. It redirects traffic to the protector PEB, whose Mirror SID context reproduces PEA's forwarding behavior.¶
The two mechanisms also share the same underlying computation: as described in Step 2d, the Repair List for the Mirror SID protection is itself an LFA/TI-LFA repair path toward PEB (RL = <S1, ..., Sn, Mirror SID>). They are therefore not mutually exclusive, and an implementation does not have to choose between "computing a TI-LFA" and "computing a Mirror SID repair".¶
What needs to be defined is which repair a node uses when both a plain LFA/TI-LFA repair toward PEA's locator and a Mirror SID repair toward PEB are available for the same destination. The following rules are RECOMMENDED:¶
- When the destination is a locator of PEA for which a usable <PEB, PEA, Mirror SID> association is known, the Mirror SID repair SHOULD take precedence over a plain LFA/TI-LFA repair toward PEA, because only the Mirror SID repair can restore traffic when PEA itself has failed.¶
- The plain LFA/TI-LFA repair toward PEA remains useful for failures that do not affect the <PEB, PEA, Mirror SID> association, in particular link failures along the primary path, and SHOULD be retained as a lower-priority repair.¶
- A repair MUST NOT be used if it would create a forwarding loop or if the associated Mirror SID is not usable (for example, if the protector is not reachable); in that case the implementation SHOULD fall back to the other repair mechanism.¶
- Implementations SHOULD allow the operator to configure the relative priority of the two mechanisms, for a given protected locator, for an IGP instance, or globally, so that deployments that rely on existing TI-LFA behavior retain control. The default behavior SHOULD be "Mirror SID repair first" when a usable Mirror SID association is available, with fallback to LFA/TI-LFA.¶
These rules apply to both failure cases described in Step 3a: the Mirror SID repair is used both when the PEA node fails (case (b)) and when the link between the PLR and PEA fails (case (a)).¶
In Step 2d of Section 3.2.1, the PLR (P1) computes an LFA for PEA "assuming that PEA and PEB have the same anycast address". This reflects an optional deployment variant rather than a strict requirement of the mechanism. In this variant, PEA and PEB are configured with a common anycast egress address (e.g., a shared service anycast SID or locator anycast) for the protected service. Because both egress nodes answer to that anycast address, P1's LFA computation toward the anycast address yields a backup path that, upon PEA failure, naturally delivers traffic to PEB.¶
The protection itself, however, is driven by the IGP-advertised Mirror SID and protected-locator association (<PEB, PEA, Mirror SID>) and the explicit Repair List (RL) toward PEB computed by P1; it therefore functions regardless of whether PEA and PEB share an anycast address.¶
Operational guidance: assigning PEA and PEB the same anycast address is NOT required for the mechanism to operate. If an operator chooses to rely on the anycast assumption to simplify LFA computation, PEA and PEB MUST be configured with the same anycast address for the protected service/locator, and the operator MUST ensure that the IGP consistently advertises that anycast address from both nodes. Where the anycast variant is not used, P1 computes the Repair List toward PEB directly from the Mirror SID association, without assuming a shared anycast address.¶
In Step 3b of Section 3.2.1, the PLR (P1) retains the route to the failed egress PEA "for a period of time" after its IGP converges on the PEA failure, so that other nodes (e.g., the ingress PE1) that have not yet converged continue to forward packets to PEA via P1 and are redirected to the backup egress PEB. The retention interval is an operator-controlled hold-down timer on the PLR.¶
It SHOULD be set long enough to cover the IGP convergence time of the slowest node in the flooding domain that may still forward traffic toward PEA, and SHOULD be bounded to avoid prolonged use of the backup path after the domain has fully converged. A typical operational value is on the order of the IGP convergence time observed in the domain (commonly tens of seconds), possibly multiplied by a small safety factor; operators SHOULD tune it to the measured convergence behavior of their network and MUST ensure it does not exceed the time after which the retained state would cause black-holing or routing loops.¶
Route retention applies to the PLR only. A node that is not a PLR for the protected locator -- for example, a provider router that is not directly connected to PEA, such as P2 in Figure 1, or an ingress node whose next hop toward PEA is another router -- MUST NOT keep forwarding traffic toward a failed PEA after it has learned about the failure through the IGP, and SHOULD NOT be configured with a retention timer for that locator. Such a node has no Mirror SID context and cannot deliver traffic addressed to a locator of PEA; retaining the route would only create a black hole. What such a node needs instead is to complete its IGP convergence as quickly as possible, so that traffic follows the post-failure topology and no packet is sent toward a locator that no longer exists.¶
Two kinds of packets need to be distinguished at a non-PLR node: packets whose Destination Address is a locator of the failed PEA, which must follow the post-convergence path toward the destination (or be dropped if no such path exists), and packets whose Destination Address is the Mirror SID of the protector PEB -- the form produced by the PLR when it redirects traffic (Step 3b). Packets of the second kind are ordinary packets addressed to a locator of PEB and are forwarded normally toward PEB by every node along the way, including nodes such as P2 that are not connected to PEA. A Mirror SID MUST NOT be treated as an address of PEA.¶
The transient behavior during convergence is therefore asymmetric: the PLR deliberately holds the stale route toward PEA for the duration of the hold-down timer, while all other nodes remove it as soon as they converge. Operators SHOULD shorten the transient period by using fast IGP convergence mechanisms (for example, fast flooding of the updated LSP/LSA and incremental SPF), so that the hold-down timer at the PLR does not need to be large.¶
The protector (PEB) must learn the per-service forwarding behavior of the protected egress (PEA) so that it can reproduce PEA's egress behavior for packets steered to the Mirror SID. This document supports two mechanisms, both operating outside the IGP (the IGP only advertises the locator-level protection association):¶
BGP-based acquisition (per [RFC9252]): The protected node PEA advertises its Service SIDs (e.g., VPN SIDs with their associated routes and next hops) via the BGP-based overlay (such as BGP VPNv4/VPNv6 or BGP SRv6 services) as it normally would for the service. The protector PEB joins the same BGP overlay (e.g., as a BGP peer or route-reflector client in the corresponding VPN/address family) and receives these BGP routes. Upon receiving a route whose Service SID belongs to a PEA that PEB protects via a Mirror SID, PEB installs the corresponding forwarding behavior into the FIB context identified by that Mirror SID. No new BGP signaling is introduced; PEB simply learns the same routes any participating PE would learn and maps them into PEA's Mirror-SID context. Configuration on PEA is its normal service/BGP configuration; configuration on PEB is to enable the same BGP address family and associate the received routes with the relevant Mirror-SID context.¶
Local configuration: The operator manually configures, on the protector PEB, the forwarding behavior for the Service SIDs under PEA's protected locator (for example, a static mapping of a VPN SID to the egress interface toward CE2) within the Mirror SID FIB context. This is suitable for small-scale or static deployments. The protected node PEA requires no special configuration for this path beyond its normal operation; the configuration is entirely on PEB.¶
In either case, when PEB learns per-service forwarding behavior via mechanisms outside the IGP (e.g., BGP per [RFC9252] or local configuration), it SHOULD validate that the behavior is authorized and consistent with the protected egress node's capabilities advertised through those same external mechanisms.¶
Limit granularity in IGP: do not attempt to enumerate per-service entries in IGP; use locator-level protection only. Service-SID behaviors are learned at the protector via BGP (per [RFC9252]) or configuration and do not alter the IGP flooding scope.¶
Applicability thresholds: When the protected service count per egress or the number of protection relationships grows large, especially with random multi-homing, the IGP control-plane load and convergence may be adversely affected; such deployments are not recommended for this IGP-based mechanism. Operators SHOULD consolidate protectors per egress and limit per-service granularity in IGP.¶
Under registry "SRv6 Endpoint Behaviors" [RFC8986], IANA has assigned the following for End.M Endpoint Behavior:¶
+==============+========+=====================+===============+ | Value | Hex | Endpoint behavior | Reference | +==============+========+=====================+===============+ | 74 | 0x004A | End.M (Mirror SID) | This document | +--------------+--------+---------------------+---------------+ | TBD | TBD | End.M with | This document | | | | REPLACE-CSID | | +--------------+--------+---------------------+---------------+¶
In addition, this document defines the "End.M with REPLACE-CSID" flavor of the End.M behavior for use with compressed segment lists (see Section 3.3). IANA is requested to assign a code point for the endpoint behavior "End.M with REPLACE-CSID" in the "SRv6 Endpoint Behaviors" registry, following the convention used in [RFC9800] for behaviors that are always the last segment of an SR path.¶
The authors would like to thank Acee Lindem, Peter Psenak, Yimin Shen, Jie Dong, Zhenqiang Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene, Jeff Tantsura, Chris Bowers, Ketan Talaulikar, Bob Halley, Tal Mizrahi, Yingzhen Qu, Susan Hares, Antoine Fressancourt, and Changwang Lin for their comments to this work.¶
Huanan Chen China Telecom 109, West Zhongshan Road, Tianhe District Guangzhou 510000 China Email: chenhn8.gd@chinatelecom.cn Peng Wu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: baggio.wupeng@huawei.com Lei Liu Fujitsu United States of America Email: liulei.kddi@gmail.com Xufeng Liu Alef Edge United States of America Email: xufeng.liu.ietf@gmail.com¶