| Internet-Draft | Mirror SID IGP Encoding | September 2026 |
| He, et al. | Expires 19 March 2027 | [Page] |
This document specifies the IGP protocol extensions required to support SRv6 path egress protection using the Mirror SID (End.M) mechanism. It reuses the existing SRv6 End SID sub-TLV defined in [RFC9352] (IS-IS, Section 7.2) and [RFC9513] (OSPFv3, Section 8) with the End.M endpoint behavior (74) to advertise the Mirror SID and the set of protected locators, and defines a new Protected Locators sub-(sub-)TLV, enabling a backup egress node (protector) to signal its capability to protect a primary egress node within a single link-state IGP area.¶
This document is a companion to [I-D.ietf-rtgwg-srv6-egress-protection], which specifies the overall SRv6 path egress protection mechanism and the End.M behavior. The IGP encoding defined herein provides the signaling substrate for that mechanism.¶
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 19 March 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.¶
[I-D.ietf-rtgwg-srv6-egress-protection] specifies a mechanism for fast protection of the egress node and link of a Segment Routing for IPv6 (SRv6) path. The mechanism introduces a Mirror SID (End.M) behavior and requires the backup egress node (protector) to advertise the tuple <PEB, PEA, Mirror SID> together with the protected locators through the IGP. This enables the Point of Local Repair (PLR) to pre-compute backup paths toward the protector for use upon failure of the primary egress.¶
This document provides the IGP protocol encoding for that mechanism. It reuses the existing SRv6 End SID sub-TLV ([RFC9352] Section 7.2 for IS-IS and [RFC9513] Section 8 for OSPFv3), setting the endpoint behavior to 74 (End.M), to carry the Mirror SID and protected locator information within link-state advertisements, and defines a new Protected Locators sub-(sub-)TLV carried inside that sub-TLV. The overall egress protection mechanism, including the End.M behavior definition, protection procedures, and operational guidelines, is described in [I-D.ietf-rtgwg-srv6-egress-protection].¶
The IGP extensions defined in this document operate within a single link-state IGP area/level. They carry locator-level protection information only; no per-service (e.g., per-VPN or per-Service SID) signaling is introduced in the IGP. The encoding is designed to minimize IGP flooding overhead while enabling the PLR to compute Loop-Free Alternates (LFAs) for egress protection.¶
Note: The applicability and scaling considerations for the overall mechanism are discussed in [I-D.ietf-rtgwg-srv6-egress-protection]. This document focuses solely on the encoding of the IGP extensions.¶
The following terminology is used in this document.¶
This section provides a brief overview of the SRv6 Mirror SID (End.M) mechanism. For a complete description, including the protection procedures, packet walks, and operational guidelines, refer to [I-D.ietf-rtgwg-srv6-egress-protection].¶
In SRv6 path egress protection, a backup egress node PEB is provisioned to protect a primary egress node PEA. A Mirror SID (End.M, SRv6 Endpoint Behavior value 74) is configured on PEB. The Mirror SID is associated with an IPv6 FIB table that contains the forwarding entries for the services anchored on PEA. When PEA fails, the PLR (typically the upstream neighbor of PEA) reroutes the traffic to PEB by encapsulating the packet with the Mirror SID as the destination. PEB decapsulates the packet and forwards the inner packet using the FIB table identified by the Mirror SID, thus reproducing the egress behavior of the failed PEA.¶
To enable this protection, PEB advertises through the IGP the information <PEB, PEA, Mirror SID>, together with the locators of PEA that are protected. This advertisement allows the PLR to learn that PEB protects PEA and to compute a backup path toward PEB. The following sections specify how the existing SRv6 End SID sub-TLV (RFC 9352 Section 7.2 for IS-IS and RFC 9513 Section 8 for OSPFv3) is reused with endpoint behavior 74 to carry this information, and define the Protected Locators sub-(sub-)TLV for carrying the protected locators.¶
This section defines the IS-IS extensions for advertising the Mirror SID and associated protected locators.¶
This document reuses the SRv6 End SID sub-TLV defined in [RFC9352] (Section 7.2, Type 5) to advertise the Mirror SID; no new sub-TLV is defined. When the endpoint behavior is 74 (End.M), the sub-TLV carries the Mirror SID in the SID field and the protected locators in the Protected Locators sub-sub-TLV defined below. The SRv6 Mirror SID inherits the topology and algorithm from the parent locator TLV. The format of the SRv6 End SID sub-TLV (annotated for Mirror SID usage) is illustrated below.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (5) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-sub-TLV-len| Protected Locators Sub-sub-TLV (variable) | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Protected Locators sub-sub-TLV is defined and used to carry the locators of the egress node to be protected by the SRv6 Mirror SID. When advertising a Mirror SID, the SRv6 End SID sub-TLV ([RFC9352] Section 7.2) MUST include exactly one IS-IS Protected Locators sub-sub-TLV. Other sub-sub-TLVs defined for the SRv6 End SID sub-TLV (e.g., the SRv6 SID Structure sub-sub-TLV) MAY also be present.¶
The Protected Locators sub-sub-TLV is an attribute of the SRv6 End SID sub-TLV that carries it. The Mirror SID and the set of locators it protects are associated through the parent sub-TLV as a whole, and a single Protected Locators sub-sub-TLV can already carry many locators (see below). A second Protected Locators sub-sub-TLV in the same parent would not add any capacity, because the space available for sub-sub-TLVs is bounded by the Length of the parent sub-TLV, and would be redundant. Therefore the Protected Locators sub-sub-TLV MUST NOT appear more than once in its parent sub-TLV; if it appears more than once, the parent SRv6 End SID sub-TLV MUST be ignored, consistent with the rule that [RFC9352] Section 9 applies to the SRv6 SID Structure sub-sub-TLV.¶
The Protected Locators sub-sub-TLV is only meaningful when the Endpoint Behavior field of the enclosing SRv6 End SID sub-TLV is 74 (End.M). If the enclosing SRv6 End SID sub-TLV carries any other Endpoint Behavior, this sub-sub-TLV MUST be ignored. It has the following format.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple Locators MAY be carried in a single Protected Locators sub-sub-TLV. Each Locator is encoded with its own Locator-Size field followed by the variable-length Locator value, so a Mirror SID can protect several locators of one egress node, or the locators of several egress nodes.¶
Size limits: the Length field of an IS-IS sub-TLV and of an IS-IS sub-sub-TLV is a single octet, so a single Protected Locators sub-sub-TLV cannot exceed 255 octets. In practice, its size is instead bounded by the Length field of the enclosing SRv6 End SID sub-TLV, which counts the octets that follow it. The Flags, Endpoint Behavior, SID, and Sub-sub-TLV-length fields of the SRv6 End SID sub-TLV occupy 20 octets, and the Type and Length fields of the Protected Locators sub-sub-TLV occupy 2 more; therefore at most 233 octets remain for the locators carried in that sub-sub-TLV. An implementation MUST NOT emit a Protected Locators sub-sub-TLV that would exceed these limits.¶
When the locators of a Mirror SID do not fit into a single Protected Locators sub-sub-TLV, the protector MUST advertise the same Mirror SID in more than one SRv6 End SID sub-TLV, each carrying exactly one Protected Locators sub-sub-TLV and the same Endpoint Behavior 74, with the locators distributed across those sub-TLVs; a receiver MUST merge the locators advertised by all such SRv6 End SID sub-TLVs. Silent truncation of the protected locator list MUST NOT be performed. If an implementation cannot advertise all protected locators, it SHOULD report the condition to the management system and SHOULD NOT install protection for the locators that could not be advertised.¶
When a backup egress node PEB advertises that it protects a primary egress node PEA with a Mirror SID through an LSP, the LSP MUST contain the SRv6 Locator TLV defined in [RFC9352] carrying an SRv6 End SID sub-TLV (Type 5) with the Endpoint Behavior field set to 74 (End.M). This sub-TLV includes the Mirror SID in the SID field and PEA's locators in the IS-IS Protected Locators sub-sub-TLV.¶
The SRv6 End SID sub-TLV used for a Mirror SID MUST include exactly one Protected Locators sub-sub-TLV and MUST NOT carry per-service (e.g., VPN or Service-SID) enumerations. When the protected locators of a Mirror SID do not fit into one sub-sub-TLV, the protector advertises the same Mirror SID in additional SRv6 End SID sub-TLVs, as described in Section 4.2. Attempting to list individual services at large scale is not suitable due to IGP flooding and convergence considerations, as discussed in [I-D.ietf-rtgwg-srv6-egress-protection].¶
Multiple protectors: a protector MAY advertise more than one Mirror SID, and an egress node MAY be protected by more than one protector. In the latter case, several Mirror SIDs list the same protected locator in their Protected Locators sub-sub-TLVs. This document does not require a unique protector per protected locator, and it does not specify how the node that computes the backup path (the PLR) selects among several Mirror SIDs that protect the same locator; that selection is specified in [I-D.ietf-rtgwg-srv6-egress-protection].¶
This section defines the OSPFv3 extensions for advertising the Mirror SID and associated protected locators.¶
This document reuses the SRv6 End SID sub-TLV defined in [RFC9513] (Section 8, Type 1) to advertise the Mirror SID; no new sub-TLV is defined. When the endpoint behavior is 74 (End.M), the sub-TLV carries the Mirror SID in the SID field and the protected locators in the Protected Locators sub-TLV defined below. Note that OSPFv3 sub-TLVs use 2-octet Type and Length fields, unlike IS-IS which uses 1-octet fields. The format of the SRv6 End SID sub-TLV (annotated for Mirror SID usage) is illustrated below.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Locators sub-TLV (variable) | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Protected Locators sub-TLV is defined and used to carry the locators of the egress node to be protected by the SRv6 Mirror SID. When advertising a Mirror SID, the SRv6 End SID sub-TLV ([RFC9513] Section 8) MUST include exactly one OSPFv3 Protected Locators sub-TLV. Other sub-TLVs defined for the SRv6 End SID sub-TLV (e.g., the SRv6 SID Structure sub-TLV) MAY also be present.¶
The Protected Locators sub-TLV is an attribute of the SRv6 End SID sub-TLV that carries it. The Mirror SID and the set of locators it protects are associated through the parent sub-TLV as a whole, and a single Protected Locators sub-TLV can already carry many locators (see below). A second Protected Locators sub-TLV in the same parent would be redundant. Therefore the Protected Locators sub-TLV MUST NOT appear more than once in its parent sub-TLV; if it appears more than once, the parent SRv6 End SID sub-TLV MUST be ignored.¶
The Protected Locators sub-TLV is only meaningful when the Endpoint Behavior field of the enclosing SRv6 End SID sub-TLV is 74 (End.M). If the enclosing SRv6 End SID sub-TLV carries any other Endpoint Behavior, this sub-TLV MUST be ignored. It has the following format.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD2) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple Locators MAY be carried in a single Protected Locators sub-TLV; each Locator is encoded with its own Locator-Size field followed by the variable-length Locator value.¶
Size limits and fragmentation: OSPFv3 uses two-octet Type and Length fields for the SRv6 End SID sub-TLV and for the Protected Locators sub-TLV, so the encoding itself is not subject to the 255-octet limit that applies to the IS-IS encoding. The size that can actually be advertised is nevertheless bounded:¶
- The Length field of the OSPFv3 LSA header is also two octets ([RFC5340], Section 4.4.1), which caps a single LSA at 65535 octets.¶
- An LSA is carried in a Link State Update packet, whose length field in the OSPFv3 packet header is likewise two octets. A packet of such a size cannot be transmitted on any real link, because the size of an OSPFv3 packet is in practice bounded by the MTU of the link on which it is flooded, and OSPFv3 does not define fragmentation and reassembly of a single LSA across multiple packets. The established approach when the information does not fit into one LSA is to spread it across multiple LSAs, as OSPFv3 itself does for prefix lists (see [RFC5340], Section 4.4.3.9, where the list of prefixes may be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small).¶
- The number of protected locators that can usefully be associated with one Mirror SID is in any case limited by IGP flooding and convergence considerations, as discussed in [I-D.ietf-rtgwg-srv6-egress-protection].¶
An implementation MUST NOT generate a Protected Locators sub-TLV that would cause the containing LSA, or the Link State Update packet that carries it, to exceed the size that can be transmitted on the link. When the locators of a Mirror SID do not fit, the protector MUST advertise the same Mirror SID in additional SRv6 End SID sub-TLVs, each carrying exactly one Protected Locators sub-TLV and the same Endpoint Behavior 74, and, if necessary, in additional LSAs; a receiver MUST merge the locators advertised by all such sub-TLVs. Silent truncation of the protected locator list MUST NOT be performed: if an implementation cannot advertise all protected locators, it SHOULD report the condition to the management system and SHOULD NOT install protection for the locators that could not be advertised.¶
When a backup egress node PEB advertises that it protects a primary egress node PEA with a Mirror SID through an LSA, the LSA MUST contain the SRv6 Locator TLV defined in [RFC9513] carrying an SRv6 End SID sub-TLV (Type 1) with the Endpoint Behavior field set to 74 (End.M). This sub-TLV includes the Mirror SID in the SID field and PEA's locators in the OSPFv3 Protected Locators sub-TLV.¶
The SRv6 End SID sub-TLV used for a Mirror SID MUST include exactly one Protected Locators sub-TLV and MUST NOT carry per-service (e.g., VPN or Service-SID) enumerations. When the protected locators of a Mirror SID do not fit into one sub-TLV, the protector advertises the same Mirror SID in additional SRv6 End SID sub-TLVs, as described in Section 5.2, for the same scaling reasons discussed in [I-D.ietf-rtgwg-srv6-egress-protection]. The considerations for multiple protectors described in Section 4.3 apply equally to the OSPFv3 encoding.¶
The IS-IS and OSPFv3 encodings for the Mirror SID reuse the SRv6 End SID sub-TLV ([RFC9352] Section 7.2 for IS-IS, Type 5; [RFC9513] Section 8 for OSPFv3, Type 1). They are semantically equivalent but differ in the following structural aspects of that sub-TLV:¶
SRv6 segment lists can be compressed as specified in [RFC9800]. Because the End.M behavior is a variant of the End.DT6 behavior, a Mirror SID can be the last segment of a compressed segment list: the REPLACE-CSID flavor that [RFC9800] defines for End.DT6 also applies to End.M, since End.M, like End.DT6, is always the last segment of an SR path.¶
The following clarifications apply when compression is used:¶
- The encoding defined in this document is unaffected by compression. The protected locators are advertised in the IGP as IPv6 prefixes in their uncompressed form; SRv6 compression applies to the encoding of segment lists in the data plane, not to the IGP advertisement of locators.¶
- A node that instantiates a Mirror SID with a compressed SID structure SHOULD also advertise the corresponding SRv6 SID Structure information (as defined in [RFC9352] and [RFC9513]) so that other nodes can interpret the SID correctly.¶
- Whether the backup path computed by the PLR uses a compressed segment list is a matter for the egress protection mechanism and is discussed in [I-D.ietf-rtgwg-srv6-egress-protection].¶
When SRv6 path egress protection is deployed in a network whose IGP topology is exported to a controller or an orchestrator via BGP-LS [RFC9552], the Mirror SID and its associated protected locators need to be distributable through BGP-LS as well.¶
The Mirror SID itself requires no new BGP-LS encoding. As specified in [RFC9514], the SRv6 SID Information TLV is derived by a simple field-by-field copy from the IS-IS or OSPFv3 SRv6 End SID sub-TLV, and the SRv6 Endpoint Behavior TLV carries the Endpoint Behavior. Because this document advertises the Mirror SID by reusing the SRv6 End SID sub-TLV with the Endpoint Behavior set to 74 (End.M), the Mirror SID is carried in the existing SRv6 SID NLRI with the SRv6 SID Information TLV and the SRv6 Endpoint Behavior TLV, without any BGP-LS change.¶
The protected locator information, however, has no BGP-LS counterpart. This document therefore defines a new BGP-LS TLV, the SRv6 Mirror SID Protected Locators TLV, which carries the list of locators protected by a Mirror SID. It is carried as a sub-TLV of the SRv6 SID Information TLV in the BGP-LS Attribute associated with the SRv6 SID NLRI that carries the Mirror SID, and it carries the same information as the IGP Protected Locators sub-(sub-)TLV. Its format is shown below.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD3) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this TLV MUST contain at least one (Locator-Size, Locator) pair.¶
This section provides configuration and management guidance for the encoding defined in this document. A YANG data model is provided in Appendix "YANG Data Model". Operational guidance for the protection mechanism itself (protector selection and consolidation, acquisition of per-service forwarding behavior at the protector, retention timers at the PLR, and applicability limits) is provided in [I-D.ietf-rtgwg-srv6-egress-protection].¶
The following items MUST be configurable on a node that acts as a protector (PEB):¶
Consistency checks: the configured protected locators MUST be locators that the primary egress node actually owns and advertises. A stale or incorrect protected locator can cause traffic for destinations that the protector cannot reach to be redirected to the protector. Implementations SHOULD therefore validate the configured protected locators against the IGP database and SHOULD report inconsistencies to the management system. In addition, a given protected locator SHOULD NOT be associated with more than one Mirror SID on the same protector unless the operator intends to advertise several protection relationships for that locator.¶
Scale and flooding considerations: because the Mirror SID and its protected locators are advertised in the IGP, operators SHOULD limit the number of Mirror SIDs per node and the number of protected locators per Mirror SID. Each change to the Mirror SID or to the protected locators causes an IGP update; configuration SHOULD therefore avoid frequent changes, and the resulting IGP flooding impact SHOULD be evaluated before large-scale deployment.¶
Operational state: an implementation SHOULD expose, as operational state, the Mirror SID, its endpoint behavior, the protected locators, whether the entry is currently advertised in the IGP, and whether the protection is currently usable (for example, whether the protector can reach the protected locators and the associated forwarding context is installed).¶
Security and access control: because the Mirror SID and the protected locators are carried in the IGP and affect the forwarding of traffic, configuration of these objects SHOULD be protected by the same access-control and authentication mechanisms that protect the rest of the routing configuration; the IGP advertisements themselves SHOULD be authenticated as described in the Security Considerations section.¶
Relationship to locator configuration: the Mirror SID is advertised inside the SRv6 Locator TLV and inherits the topology and algorithm from the parent locator. Operators MUST ensure that the locator from which the Mirror SID is allocated is enabled for the topology/algorithm in which protection is required.¶
This document requests IANA to make the following assignments in the specified registries.¶
This document does not define a new IS-IS sub-TLV; it reuses the SRv6 End SID sub-TLV (Type 5) defined in [RFC9352] (Section 7.2). Under the existing registry "IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs" ([RFC9352] Section 11.6), IANA is requested to assign the following new sub-sub-TLV:¶
+==============+=========================+===============+ | Value | Sub-Sub-TLV Name | Reference | +==============+=========================+===============+ | TBD1 | Protected Locators | This document | +--------------+-------------------------+---------------+¶
This document does not define a new OSPFv3 sub-TLV; it reuses the SRv6 End SID sub-TLV (Type 1) defined in [RFC9513] (Section 8). Under the existing registry "OSPFv3 SRv6 Locator LSA Sub-TLVs" ([RFC9513] Section 13.9), IANA is requested to assign the following new sub-TLV:¶
+==============+============================+===============+ | Value | Sub-TLV Name | Reference | +==============+============================+===============+ | TBD2 | Protected Locators Sub-TLV | This document | +--------------+----------------------------+---------------+¶
Under the "BGP-LS NLRI and Attribute TLVs" registry [RFC9552], IANA is requested to assign the following new TLV:¶
+==============+=========================================+===============+ | Value | TLV Name | Reference | +==============+=========================================+===============+ | TBD3 | SRv6 Mirror SID Protected Locators TLV | This document | +--------------+-----------------------------------------+---------------+¶
IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC7950]:¶
+==============+===============================+==========+==============+ | Name | Namespace | Prefix | Reference | +==============+===============================+==========+==============+ | ietf-srv6- | urn:ietf:params:xml:ns:yang: | srv6ms | This document| | mirror-sid | ietf-srv6-mirror-sid | | | +--------------+-------------------------------+----------+--------------+¶
The IGP extensions defined in this document are used within a single link-state IGP area/level under a single administrative domain. They reuse the SRv6 End SID sub-TLV in IS-IS and OSPFv3 to advertise the Mirror SID (End.M) and define a new Protected Locators sub-(sub-)TLV for the protected locator information.¶
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 deployed 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.¶
The following additional security considerations apply specifically to the Mirror SID IGP extensions:¶
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.¶
Unauthorized Rerouting: An attacker could attempt to trigger unnecessary rerouting by advertising false protection relationships. This is mitigated by authenticating IGP advertisements and limiting protector selection to trusted nodes within the same administrative domain.¶
Traffic Interception: An attacker could attempt to become a protector to intercept traffic destined to a primary egress node. This is mitigated by authenticating IGP advertisements of Mirror SIDs and monitoring for unexpected protector advertisements.¶
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:¶
This appendix defines an initial YANG module for the configuration and operational state of the SRv6 Mirror SID protection entries described in this document. The module is provided as a starting point and is expected to be aligned with the SRv6 base data model ([I-D.ietf-spring-srv6-yang-base]) and with the IS-IS and OSPFv3 data models ([RFC9130] and [RFC9129]) as those models evolve.¶
The module augments the SRv6 locator of the SRv6 base data model, which extends the Segment Routing data model ([RFC9020]) under the routing data model ([RFC8349]), so that a Mirror SID is configured as part of the locator from which it is allocated, and it uses the common data types defined in [RFC6991].¶
<CODE BEGINS>
module ietf-srv6-mirror-sid {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-srv6-mirror-sid";
prefix srv6ms;
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-routing {
prefix rt;
reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)";
}
import ietf-segment-routing {
prefix sr;
reference "RFC 9020: YANG Data Model for Segment Routing";
}
import ietf-srv6-base {
prefix srv6;
reference "I-D.ietf-spring-srv6-yang-base: YANG Data Model for SRv6 Base";
}
organization
"IETF Link State Routing (LSR) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org>
Editor: Tao He
<mailto:het21@chinaunicom.cn>";
description
"This YANG module defines a data model for the configuration
and operational state of the SRv6 Mirror SID (End.M) protection
entries used by SRv6 path egress protection.
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 (RFC 2119)
(RFC 8174) when, and only when, they appear in all capitals,
as shown here.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.";
revision 2026-09-15 {
description
"Initial revision.";
reference
"draft-ietf-lsr-srv6-mirror-sid-igp-encoding";
}
feature mirror-sid {
description
"This feature indicates that the device supports the SRv6
Mirror SID (End.M) behavior and can be configured to protect
a primary egress node.";
}
grouping mirror-sid-entry {
description
"Configuration and state of a single SRv6 Mirror SID
protection entry.";
leaf mirror-sid {
type inet:ipv6-address;
mandatory true;
description
"The SRv6 Mirror SID (End.M) instantiated on this node.
The SID MUST be allocated from a locator of this node.";
}
leaf-list protected-locator {
type inet:ipv6-prefix;
description
"An SRv6 locator of the primary egress node that is
protected by this Mirror SID.";
}
leaf forwarding-context {
type string;
description
"Name of the local forwarding context (for example, the
FIB table) that is associated with this Mirror SID and
that reproduces the forwarding behavior of the protected
egress node.";
}
leaf enabled {
type boolean;
default "true";
description
"Controls whether this Mirror SID protection entry is
advertised in the IGP and used for protection.";
}
}
augment "/rt:routing/sr:segment-routing/srv6:srv6/srv6:locators/srv6:locator" {
description
"Augments an SRv6 locator with the Mirror SID protection entries
that are allocated from it.";
list mirror-sid {
if-feature "mirror-sid";
key "mirror-sid";
description
"Mirror SID protection entries configured under this locator.";
uses mirror-sid-entry;
}
}
}
<CODE ENDS>¶
The authors would like to thank Mach Chen, Les Ginsberg, Changwang Lin, Aijun Wang, and Li Zhang for their detailed review of this document. The authors would also like to thank Acee Lindem, Peter Psenak, Huaimo Chen, and Mehmet Toy for their work on [I-D.ietf-rtgwg-srv6-egress-protection], the overall egress protection mechanism upon which this document builds.¶