Network Working Group T. He Internet-Draft Y. Liu Intended status: Standards Track China Unicom Expires: 21 December 2026 Z. Hu Huawei 19 June 2026 IGP Encoding for SRv6 Mirror SID in Egress Protection draft-he-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 defines new sub-TLVs within IS-IS and OSPFv3 for advertising the Mirror SID and the set of protected locators, 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/. 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." He, et al. Expires 21 December 2026 [Page 1] Internet-Draft Mirror SID IGP Encoding June 2026 This Internet-Draft will expire on 21 December 2026. 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 SRv6 Mirror SID sub-TLV . . . . . . . . . . . . . . 5 4.2. IS-IS Protected Locators sub-sub-TLV . . . . . . . . . . 6 4.3. IS-IS Advertisement Procedures . . . . . . . . . . . . . 7 5. OSPFv3 Extensions for Mirror SID . . . . . . . . . . . . . . 7 5.1. OSPFv3 SRv6 Mirror SID sub-TLV . . . . . . . . . . . . . 7 5.2. OSPFv3 Protected Locators sub-TLV . . . . . . . . . . . . 8 5.3. OSPFv3 Advertisement Procedures . . . . . . . . . . . . . 9 5.4. Comparison of IS-IS and OSPFv3 Encodings . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. IS-IS Sub-TLV Registrations . . . . . . . . . . . . . . . 10 6.2. IS-IS Sub-Sub-TLV Registry . . . . . . . . . . . . . . . 10 6.3. OSPFv3 Sub-TLV Registrations . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 He, et al. Expires 21 December 2026 [Page 2] Internet-Draft Mirror SID IGP Encoding June 2026 1. Introduction [I-D.ietf-rtgwg-srv6-egress-protection] specifies a mechanism for fast protecting 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 defines the IS-IS and OSPFv3 sub-TLVs needed to carry the Mirror SID and protected locator information within link-state advertisements. 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 terminologies are 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 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 He, et al. Expires 21 December 2026 [Page 3] Internet-Draft Mirror SID IGP Encoding June 2026 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]. 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) re-routes 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. He, et al. Expires 21 December 2026 [Page 4] Internet-Draft Mirror SID IGP Encoding June 2026 To enable this protection, PEB must advertise 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 define the IS-IS and OSPFv3 sub-TLVs for carrying this information. 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 SRv6 Mirror SID sub-TLV A new sub-TLV, called the IS-IS SRv6 Mirror SID sub-TLV, is defined. It is carried within the SRv6 Locator TLV defined in [RFC9352] to advertise the SRv6 Mirror SID and the locators of the nodes to be protected. The SRv6 Mirror SID inherits the topology and algorithm from the parent locator TLV. The format of the sub-TLV 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 (TBD1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SRv6 Endpoint Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-sub-TLVs | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IS-IS SRv6 Mirror SID sub-TLV Type: TBD1 (suggested value 8) is to be assigned by IANA. Length: 1 octet. Its value MUST NOT be less than 23. 23 is 19 (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus 4 (i.e., the minimum size of an IS-IS Protected Locators sub-sub- TLV). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 23. Reserved: 1 octet. This octet MUST be set to zero on transmit, and ignored on receipt. He, et al. Expires 21 December 2026 [Page 5] Internet-Draft Mirror SID IGP Encoding June 2026 SRv6 Endpoint Function: 2 octets. It MUST contain the endpoint function 74 for Mirror SID (End.M). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if it does not contain the endpoint function 74. SID: 16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if it contains zero (0). 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. The IS-IS SRv6 Mirror SID sub-TLV MUST include exactly one IS-IS Protected Locators sub-sub-TLV. 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 2: IS-IS Protected Locators sub-sub-TLV Type: TBD2 (suggested value 1) is to be assigned by IANA. Length: 1 octet. Its value MUST NOT be less than 2. The entire IS- IS SRv6 Mirror 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 from the range (1-128). The entire IS-IS SRv6 Mirror 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. He, et al. Expires 21 December 2026 [Page 6] Internet-Draft Mirror SID IGP Encoding June 2026 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 an SRv6 Locator TLV [RFC9352] carrying an IS-IS SRv6 Mirror SID sub-TLV. 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 IS-IS SRv6 Mirror SID sub-TLV MUST include exactly one Protected Locators sub-sub-TLV and MUST NOT carry per-service (e.g., VPN or Service-SID) enumerations. 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]. 5. OSPFv3 Extensions for Mirror SID This section defines the OSPFv3 extensions for advertising the Mirror SID and associated protected locators. 5.1. OSPFv3 SRv6 Mirror SID sub-TLV A new sub-TLV, called the OSPFv3 SRv6 Mirror SID sub-TLV, is defined. It is carried within the SRv6 Locator TLV defined in [RFC9513] to advertise the SRv6 Mirror SID and the locators of the nodes to be protected. Its format is illustrated below. Note that OSPFv3 sub- TLVs use 2-octet Type and Length fields, unlike IS-IS which uses 1-octet fields. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SRv6 Endpoint Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: OSPFv3 SRv6 Mirror SID sub-TLV Type: TBD3 (suggested value 8) is to be assigned by IANA. He, et al. Expires 21 December 2026 [Page 7] Internet-Draft Mirror SID IGP Encoding June 2026 Length: 2 octets. Its value MUST NOT be less than 26. 26 is 20 (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus 6 (i.e., the minimum size of an OSPFv3 Protected Locators sub- TLV). The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 26. Reserved: 2 octets. It MUST be set to zero for transmission and ignored on reception. SRv6 Endpoint Function: 2 octets. It MUST contain the endpoint function 74 for End.M SID. The entire OSPFv3 SRv6 Mirror SID sub- TLV MUST be ignored if it does not contain the endpoint function 74. SID: 16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if it contains zero (0). 5.2. OSPFv3 Protected Locators sub-TLV A Protected Locators sub-TLV is defined and used to carry the locators of the node to be protected by the SRv6 Mirror SID. The OSPFv3 SRv6 Mirror SID sub-TLV MUST include exactly one OSPFv3 Protected Locators sub-TLV. 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 (TBD4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: OSPFv3 Protected Locators sub-TLV Type: TBD4 (suggested value 1) is to be assigned by IANA. Length: 2 octets. Its value MUST NOT be less than 2. The entire OSPFv3 SRv6 Mirror 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 from the range (1-128). The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if the Locator-Size is outside this range. He, et al. Expires 21 December 2026 [Page 8] Internet-Draft Mirror SID IGP Encoding June 2026 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. 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 an SRv6 Locator TLV [RFC9513] carrying an OSPFv3 SRv6 Mirror SID sub-TLV. This sub-TLV includes the Mirror SID in the SID field and PEA's locators in the OSPFv3 Protected Locators sub-TLV. The OSPFv3 SRv6 Mirror SID sub-TLV MUST include exactly one Protected Locators sub-TLV and MUST NOT carry per-service (e.g., VPN or Service-SID) enumerations, for the same scaling reasons discussed in [I-D.ietf-rtgwg-srv6-egress-protection]. 5.4. Comparison of IS-IS and OSPFv3 Encodings The IS-IS and OSPFv3 encodings for the Mirror SID and Protected Locators are semantically equivalent but differ in the following structural aspects: o Type field: 1 octet in IS-IS sub-TLVs vs. 2 octets in OSPFv3 sub- TLVs. o Length field: 1 octet in IS-IS sub-TLVs vs. 2 octets in OSPFv3 sub-TLVs. o Reserved field: 1 octet in the IS-IS SRv6 Mirror SID sub-TLV vs. 2 octets in the OSPFv3 equivalent. o Minimum Length: 23 for the IS-IS SRv6 Mirror SID sub-TLV vs. 26 for the OSPFv3 equivalent. o Nested TLV naming: sub-sub-TLVs in IS-IS vs. sub-TLVs in OSPFv3, reflecting the terminology conventions of each protocol. 6. IANA Considerations This document requests IANA to make the following assignments in the specified registries. He, et al. Expires 21 December 2026 [Page 9] Internet-Draft Mirror SID IGP Encoding June 2026 6.1. IS-IS Sub-TLV Registrations Under registry "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability", IANA is requested to assign the following new sub-TLV: +==============+=========================+===============+ | Type | Description | Reference | +==============+=========================+===============+ | TBD | SRv6 Mirror SID | This document | +--------------+-------------------------+---------------+ 6.2. IS-IS Sub-Sub-TLV Registry IANA is requested to create and maintain a new registry for sub-sub- TLVs of the SRv6 Mirror SID sub-TLV. The suggested registry name is: o Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV Initial values for the registry are given below. Future assignments are to be made through IETF Review [RFC9907]. Value Sub-Sub-TLV Name Definition ----- ----------------------- ------------- 0 Reserved 1 Protected Locators Sub-Sub-TLV This Document 2-255 Unassigned 6.3. OSPFv3 Sub-TLV Registrations Under registry "OSPFv3 SRv6 Locator LSA Sub-TLVs" [RFC9513], IANA is requested to assign the following new sub-TLVs: +==============+============================+===============+ | Sub-TLV Type | Sub-TLV Name | Reference | +==============+============================+===============+ | TBD | SRv6 Mirror SID Sub-TLV | This document | +--------------+----------------------------+---------------+ | TBD | Protected Locators Sub-TLV | This document | +--------------+----------------------------+---------------+ 7. 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 introduce new sub-TLVs to IS-IS and OSPFv3 for advertising Mirror SID and protected locator information. He, et al. Expires 21 December 2026 [Page 10] Internet-Draft Mirror SID IGP Encoding June 2026 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. 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: 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. He, et al. Expires 21 December 2026 [Page 11] Internet-Draft Mirror SID IGP Encoding June 2026 8. References 8.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, . [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, . [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, . [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . He, et al. Expires 21 December 2026 [Page 12] Internet-Draft Mirror SID IGP Encoding June 2026 [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, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [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, . 8.2. Informative References [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., Michel, C., and H. Chen, "MPLS Egress Protection Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, . [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . He, et al. Expires 21 December 2026 [Page 13] Internet-Draft Mirror SID IGP Encoding June 2026 [RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", RFC 9855, DOI 10.17487/RFC9855, October 2025, . [RFC9907] Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", RFC 9907, DOI 10.17487/RFC9907, May 2026, . Acknowledgments The authors would like to thank Acee Lindem, Peter Psenak, Huaimo Chen, Mehmet Toy and all scontributors to [I-D.ietf-rtgwg-srv6-egress-protection] for their work on the overall egress protection mechanism that this document builds upon. Authors' Addresses Tao He China Unicom No.9 South Shouti Road Beijing 100048 China Email: het21@chinaunicom.cn 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 21 December 2026 [Page 14]