IGP Encoding for SRv6 Mirror SID in Egress Protection
draft-ietf-lsr-srv6-mirror-sid-igp-encoding-00
| Document | Type | Active Internet-Draft (lsr WG) | |
|---|---|---|---|
| Authors | Tao He , Ran Pang , Liu Ying , Zhibo Hu | ||
| Last updated | 2026-09-15 | ||
| Replaces | draft-he-lsr-srv6-mirror-sid-igp-encoding | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lsr-srv6-mirror-sid-igp-encoding-00
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 <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.
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 <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.
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,
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-
egress-protection/>.
[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, <https://datatracker.ietf.org/doc/draft-ietf-spring-
srv6-yang-base/>.
[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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>.
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, <https://www.rfc-editor.org/info/rfc5304>.
[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, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC6991] IETF, "Common YANG Data Types", RFC 6991,
DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>.
[RFC7950] IETF, "The YANG 1.1 Data Modeling Language", RFC 7950,
DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8349] IETF, "A YANG Data Model for Routing Management (NMDA
Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[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, <https://www.rfc-editor.org/info/rfc8362>.
[RFC9020] IETF, "YANG Data Model for Segment Routing", RFC 9020,
DOI 10.17487/RFC9020, May 2021,
<https://www.rfc-editor.org/info/rfc9020>.
[RFC9129] IETF, "YANG Data Model for the OSPF Protocol", RFC 9129,
DOI 10.17487/RFC9129, October 2022,
<https://www.rfc-editor.org/info/rfc9129>.
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,
<https://www.rfc-editor.org/info/rfc9130>.
[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, <https://www.rfc-editor.org/info/rfc9352>.
[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,
<https://www.rfc-editor.org/info/rfc9513>.
[RFC9514] IETF, "Border Gateway Protocol - Link State (BGP-LS)
Extensions for Segment Routing over IPv6 (SRv6)",
RFC 9514, DOI 10.17487/RFC9514, December 2023,
<https://www.rfc-editor.org/info/rfc9514>.
[RFC9552] IETF, "Distribution of Link-State and Traffic Engineering
Information Using BGP", RFC 9552, DOI 10.17487/RFC9552,
December 2023, <https://www.rfc-editor.org/info/rfc9552>.
[RFC9800] IETF, "Compressed SRv6 Segment List Encoding", RFC 9800,
DOI 10.17487/RFC9800, 2025,
<https://www.rfc-editor.org/info/rfc9800>.
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].
<CODE BEGINS>
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: <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
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;
}
}
}
<CODE ENDS>
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]