Network Working Group T. He Internet-Draft R. Pang Intended status: Standards Track Y. Liu Expires: 19 March 2027 China Unicom Z. Hu Huawei 15 September 2026 IGP Encoding for SRv6 Mirror SID in Egress Protection draft-ietf-lsr-srv6-mirror-sid-igp-encoding-00 Abstract 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. Requirements Language 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. Status of This Memo 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/. He, et al. Expires 19 March 2027 [Page 1] Internet-Draft Mirror SID IGP Encoding September 2026 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 Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SRv6 Mirror SID Overview . . . . . . . . . . . . . . . . . . 4 4. IS-IS Extensions for Mirror SID . . . . . . . . . . . . . . . 5 4.1. IS-IS Advertisement of the Mirror SID in the SRv6 End SID sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. IS-IS Protected Locators sub-sub-TLV . . . . . . . . . . 7 4.3. IS-IS Advertisement Procedures . . . . . . . . . . . . . 8 5. OSPFv3 Extensions for Mirror SID . . . . . . . . . . . . . . 9 5.1. OSPFv3 Advertisement of the Mirror SID in the SRv6 End SID sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. OSPFv3 Protected Locators sub-TLV . . . . . . . . . . . . 11 5.3. OSPFv3 Advertisement Procedures . . . . . . . . . . . . . 13 5.4. Comparison of IS-IS and OSPFv3 Encodings . . . . . . . . 13 6. Interaction with Compressed SRv6 . . . . . . . . . . . . . . 13 7. BGP-LS Considerations . . . . . . . . . . . . . . . . . . . . 14 8. Management and Configuration Considerations . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9.1. IS-IS Sub-Sub-TLV Registration . . . . . . . . . . . . . 17 9.2. OSPFv3 Sub-TLV Registration . . . . . . . . . . . . . . . 17 9.3. BGP-LS TLV Registration . . . . . . . . . . . . . . . . . 17 9.4. YANG Module Names . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 He, et al. Expires 19 March 2027 [Page 2] Internet-Draft Mirror SID IGP Encoding September 2026 YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction [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 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. 2. Terminology The following terminology is used in this document. End.M: Mirror SID endpoint behavior (value 74) IGP: Interior Gateway Protocol IS-IS: Intermediate System to Intermediate System LFA: Loop-Free Alternate He, et al. Expires 19 March 2027 [Page 3] Internet-Draft Mirror SID IGP Encoding September 2026 Locator: An IPv6 prefix advertised by an SRv6-capable node LS: Link State, which is LSA in OSPFv3 or LSP in IS-IS LSA: Link State Advertisement in OSPFv3 LSP: Link State Protocol Data Unit in IS-IS Mirror SID: An SRv6 SID with the End.M behavior, used to redirect traffic to a backup egress node OSPFv3: Open Shortest Path First version 3 PE: Provider Edge PEA: Primary Egress node to be protected PEB: Backup Egress node (protector) PLR: Point of Local Repair SID: Segment Identifier SR: Segment Routing SRv6: Segment Routing for IPv6 sub-TLV: A TLV nested within another TLV sub-sub-TLV: A TLV nested within a sub-TLV TI-LFA: Topology Independent LFA 3. SRv6 Mirror SID Overview 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]. He, et al. Expires 19 March 2027 [Page 4] Internet-Draft Mirror SID IGP Encoding September 2026 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 , 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. 4. IS-IS Extensions for Mirror SID This section defines the IS-IS extensions for advertising the Mirror SID and associated protected locators. 4.1. IS-IS Advertisement of the Mirror SID in the SRv6 End SID sub-TLV 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. He, et al. Expires 19 March 2027 [Page 5] Internet-Draft Mirror SID IGP Encoding September 2026 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) | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IS-IS SRv6 End SID sub-TLV (reused for Mirror SID) Type: 5, 1 octet, as defined in [RFC9352] (Section 7.2). No new type is assigned. Length: 1 octet, as defined in [RFC9352]. Flags: 1 octet. This field MUST be set to zero on transmit and ignored on receipt, as defined in [RFC9352]. Endpoint Behavior: 2 octets. When this sub-TLV is used to advertise a Mirror SID, this field MUST contain the endpoint behavior 74 (End.M). The SRv6 End SID sub-TLV is shared by all SRv6 Endpoint Behaviors ([RFC9352] Section 7.2); therefore an SRv6 End SID sub- TLV whose Endpoint Behavior field is not 74 is not a Mirror SID advertisement, and it MUST be processed as a normal SRv6 End SID advertisement as defined in [RFC9352]. In particular, the Protected Locators sub-sub-TLV defined in Section 4.2 MUST be ignored when the Endpoint Behavior field of the enclosing sub-TLV is not 74. SID: 16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The Mirror SID MUST be allocated from a locator of the advertising node, as required by [RFC9352] Section 7.2. He, et al. Expires 19 March 2027 [Page 6] Internet-Draft Mirror SID IGP Encoding September 2026 4.2. IS-IS Protected Locators sub-sub-TLV 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IS-IS Protected Locators sub-sub-TLV Type: TBD1 (suggested value 2) is to be assigned by IANA. Length: 1 octet. Its value MUST NOT be less than 2. The SRv6 End SID sub-TLV MUST be ignored if the Length is less than 2. Locator-Size: 1 octet. Number of bits in the Locator field, which He, et al. Expires 19 March 2027 [Page 7] Internet-Draft Mirror SID IGP Encoding September 2026 MUST be in the range (1-128). The SRv6 End SID sub-TLV MUST be ignored if the Locator-Size is outside this range. Locator: 1-16 octets. This field encodes an SRv6 Locator of an egress node to be protected by the SRv6 Mirror SID. The Locator is encoded in the minimal number of octets for the given number of bits. Trailing bits MUST be set to zero and ignored when received. 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. 4.3. IS-IS Advertisement Procedures 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. He, et al. Expires 19 March 2027 [Page 8] Internet-Draft Mirror SID IGP Encoding September 2026 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]. 5. OSPFv3 Extensions for Mirror SID This section defines the OSPFv3 extensions for advertising the Mirror SID and associated protected locators. 5.1. OSPFv3 Advertisement of the Mirror SID in the SRv6 End SID sub-TLV 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. He, et al. Expires 19 March 2027 [Page 9] Internet-Draft Mirror SID IGP Encoding September 2026 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) | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: OSPFv3 SRv6 End SID sub-TLV (reused for Mirror SID) Type: 1, 2 octets, as defined in [RFC9513] (Section 8). No new type is assigned. Length: 2 octets, as defined in [RFC9513]. Flags: 1 octet. This field MUST be set to zero on transmit and ignored on receipt, as defined in [RFC9513]. Reserved: 1 octet. This field MUST be set to zero on transmit and ignored on receipt, as defined in [RFC9513]. Endpoint Behavior: 2 octets. When this sub-TLV is used to advertise a Mirror SID, this field MUST contain the endpoint behavior 74 (End.M). The SRv6 End SID sub-TLV is shared by all SRv6 Endpoint Behaviors ([RFC9513] Section 8); therefore an SRv6 End SID sub-TLV whose Endpoint Behavior field is not 74 is not a Mirror SID advertisement, and it MUST be processed as a normal SRv6 End SID advertisement as defined in [RFC9513]. In particular, the Protected Locators sub-TLV defined in Section 5.2 MUST be ignored when the Endpoint Behavior field of the enclosing sub-TLV is not 74. SID: 16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The Mirror SID MUST be allocated from a locator of the advertising node, as required by [RFC9513] Section 8. He, et al. Expires 19 March 2027 [Page 10] Internet-Draft Mirror SID IGP Encoding September 2026 5.2. OSPFv3 Protected Locators sub-TLV 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) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: OSPFv3 Protected Locators sub-TLV Type: TBD2 (suggested value 6) is to be assigned by IANA. Length: 2 octets. Its value MUST NOT be less than 2. The SRv6 End SID sub-TLV MUST be ignored if the Length is less than 2. Locator-Size: 1 octet. Number of bits in the Locator field, which MUST be in the range (1-128). The SRv6 End SID sub-TLV MUST be ignored if the Locator-Size is outside this range. Locator: 1-16 octets. This field encodes an SRv6 Locator of an He, et al. Expires 19 March 2027 [Page 11] Internet-Draft Mirror SID IGP Encoding September 2026 egress node to be protected by the SRv6 Mirror SID. The Locator is encoded in the minimal number of octets for the given number of bits. Trailing bits MUST be set to zero and ignored when received. 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. He, et al. Expires 19 March 2027 [Page 12] Internet-Draft Mirror SID IGP Encoding September 2026 5.3. OSPFv3 Advertisement Procedures 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. 5.4. Comparison of IS-IS and OSPFv3 Encodings 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: o Type field: 1 octet in the IS-IS SRv6 End SID sub-TLV vs. 2 octets in the OSPFv3 SRv6 End SID sub-TLV. o Length field: 1 octet in the IS-IS SRv6 End SID sub-TLV vs. 2 octets in the OSPFv3 SRv6 End SID sub-TLV. o Flags and Reserved fields: 1 octet (Flags) in the IS-IS SRv6 End SID sub-TLV vs. 2 octets (Flags + Reserved) in the OSPFv3 SRv6 End SID sub-TLV. o Nested TLV naming: sub-sub-TLVs in IS-IS vs. sub-TLVs in OSPFv3, reflecting the terminology conventions of each protocol. 6. Interaction with Compressed SRv6 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. He, et al. Expires 19 March 2027 [Page 13] Internet-Draft Mirror SID IGP Encoding September 2026 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]. 7. BGP-LS Considerations 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. He, et al. Expires 19 March 2027 [Page 14] Internet-Draft Mirror SID IGP Encoding September 2026 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: BGP-LS SRv6 Mirror SID Protected Locators TLV Type: TBD3 (to be assigned by IANA) is the BGP-LS TLV code point for the SRv6 Mirror SID Protected Locators TLV. Length: 2 octets. Length of the value field in octets. Locator-Size: 1 octet. Number of bits in the Locator field, which MUST be in the range (1-128). Locator: 1-16 octets. An SRv6 Locator of an egress node protected by the Mirror SID, encoded in the minimal number of octets for the given number of bits. The value field of this TLV MUST contain at least one (Locator-Size, Locator) pair. 8. Management and Configuration Considerations 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): o The Mirror SID value. It MUST be allocated from a locator of the protector and MUST have the End.M (74) behavior. o The forwarding context (for example, the FIB table) that is associated with the Mirror SID and that reproduces the forwarding behavior of the protected egress node. He, et al. Expires 19 March 2027 [Page 15] Internet-Draft Mirror SID IGP Encoding September 2026 o The list of locators of the protected egress node (PEA). o Whether the Mirror SID protection entry is enabled, i.e., whether it is advertised in the IGP and used for protection. 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. 9. IANA Considerations This document requests IANA to make the following assignments in the specified registries. He, et al. Expires 19 March 2027 [Page 16] Internet-Draft Mirror SID IGP Encoding September 2026 9.1. IS-IS Sub-Sub-TLV Registration 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 | +--------------+-------------------------+---------------+ 9.2. OSPFv3 Sub-TLV Registration 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 | +--------------+----------------------------+---------------+ 9.3. BGP-LS TLV Registration 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 | +--------------+-----------------------------------------+---------------+ 9.4. YANG Module Names IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC7950]: He, et al. Expires 19 March 2027 [Page 17] Internet-Draft Mirror SID IGP Encoding September 2026 +==============+===============================+==========+==============+ | Name | Namespace | Prefix | Reference | +==============+===============================+==========+==============+ | ietf-srv6- | urn:ietf:params:xml:ns:yang: | srv6ms | This document| | mirror-sid | ietf-srv6-mirror-sid | | | +--------------+-------------------------------+----------+--------------+ 10. Security Considerations 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. He, et al. Expires 19 March 2027 [Page 18] Internet-Draft Mirror SID IGP Encoding September 2026 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: o Limiting the number of protection relationships per node. o Implementing IGP flooding rate limiting. o Following the operational guidelines in [I-D.ietf-rtgwg-srv6-egress-protection] to limit the scale of deployments. o Monitoring IGP database size and convergence times. 11. References 11.1. Normative References [I-D.ietf-rtgwg-srv6-egress-protection] He, T., Hu, Z., Chen, H., Toy, M., and C. Cao, "SRv6 Path Egress Protection", Work in Progress, Internet-Draft, draft-ietf-rtgwg-srv6-egress-protection, 2026, . [I-D.ietf-spring-srv6-yang-base] IETF, "YANG Data Model for SRv6 Base", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-yang-base, May 2026, . [ISO10589] ISO, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, November 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . He, et al. Expires 19 March 2027 [Page 19] Internet-Draft Mirror SID IGP Encoding September 2026 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC6991] IETF, "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, . [RFC7950] IETF, "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8349] IETF, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC9020] IETF, "YANG Data Model for Segment Routing", RFC 9020, DOI 10.17487/RFC9020, May 2021, . [RFC9129] IETF, "YANG Data Model for the OSPF Protocol", RFC 9129, DOI 10.17487/RFC9129, October 2022, . He, et al. Expires 19 March 2027 [Page 20] Internet-Draft Mirror SID IGP Encoding September 2026 [RFC9130] IETF, "YANG Data Model for the IS-IS Protocol", RFC 9130, DOI 10.17487/RFC9130, October 2022, . [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, February 2023, . [RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", RFC 9513, DOI 10.17487/RFC9513, December 2023, . [RFC9514] IETF, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December 2023, . [RFC9552] IETF, "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, . [RFC9800] IETF, "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, 2025, . YANG Data Model 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]. module ietf-srv6-mirror-sid { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-srv6-mirror-sid"; prefix srv6ms; He, et al. Expires 19 March 2027 [Page 21] Internet-Draft Mirror SID IGP Encoding September 2026 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: WG List: Editor: Tao He "; 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 He, et al. Expires 19 March 2027 [Page 22] Internet-Draft Mirror SID IGP Encoding September 2026 (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."; He, et al. Expires 19 March 2027 [Page 23] Internet-Draft Mirror SID IGP Encoding September 2026 } } 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; } } } Acknowledgments 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. Authors' Addresses Tao He China Unicom No.9 South Shouti Road Beijing 100048 China Email: het21@chinaunicom.cn Ran Pang China Unicom No.9 South Shouti Road Beijing 100048 China Email: pangran@chinaunicom.cn He, et al. Expires 19 March 2027 [Page 24] Internet-Draft Mirror SID IGP Encoding September 2026 Ying Liu China Unicom No.9 South Shouti Road Beijing 100048 China Email: liuy619@chinaunicom.cn Zhibo Hu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: huzhibo@huawei.com He, et al. Expires 19 March 2027 [Page 25]