]> China Unicom

No.9 South Shouti Road Beijing 100048 China het21@chinaunicom.cn

China Unicom

No.9 South Shouti Road Beijing 100048 China pangran@chinaunicom.cn

China Unicom

No.9 South Shouti Road Beijing 100048 China liuy619@chinaunicom.cn

Huawei

Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China huzhibo@huawei.com

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 (IS-IS, Section 7.2) and (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 , 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 when, and only when, they appear in all capitals, as shown here.

Introduction 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 ( Section 7.2 for IS-IS and 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 . 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 . This document focuses solely on the encoding of the IGP extensions.

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

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

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 . 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.

IS-IS Extensions for Mirror SID This section defines the IS-IS extensions for advertising the Mirror SID and associated protected locators.

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 (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.

IS-IS SRv6 End SID sub-TLV (reused for Mirror SID)

Type:

5, 1 octet, as defined in (Section 7.2). No new type is assigned.

Length:

1 octet, as defined in .

Flags:

1 octet. This field MUST be set to zero on transmit and ignored on receipt, as defined in .

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 ( 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 . 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 Section 7.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 ( 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 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.

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 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.

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 carrying an SRv6 End SID sub-TLV (Type 5) with the Endpoint Behavior field set to 74 (End.M). This sub-TLV includes the Mirror SID in the SID field and PEA's locators in the IS-IS Protected Locators sub-sub-TLV. The SRv6 End SID sub-TLV used for a Mirror SID MUST include exactly one Protected Locators sub-sub-TLV and MUST NOT carry per-service (e.g., VPN or Service-SID) enumerations. When the protected locators of a Mirror SID do not fit into one sub-sub-TLV, the protector advertises the same Mirror SID in additional SRv6 End SID sub-TLVs, as described in Section 4.2. Attempting to list individual services at large scale is not suitable due to IGP flooding and convergence considerations, as discussed in . 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 .

OSPFv3 Extensions for Mirror SID This section defines the OSPFv3 extensions for advertising the Mirror SID and associated protected locators.

OSPFv3 Advertisement of the Mirror SID in the SRv6 End SID sub-TLV This document reuses the SRv6 End SID sub-TLV defined in (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.

OSPFv3 SRv6 End SID sub-TLV (reused for Mirror SID)

Type:

1, 2 octets, as defined in (Section 8). No new type is assigned.

Length:

2 octets, as defined in .

Flags:

1 octet. This field MUST be set to zero on transmit and ignored on receipt, as defined in .

Reserved:

1 octet. This field MUST be set to zero on transmit and ignored on receipt, as defined in .

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 ( 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 . 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 Section 8.

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 ( 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.

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 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 (, 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 , 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 . 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.

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 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 . The considerations for multiple protectors described in Section 4.3 apply equally to the OSPFv3 encoding.

Comparison of IS-IS and OSPFv3 Encodings The IS-IS and OSPFv3 encodings for the Mirror SID reuse the SRv6 End SID sub-TLV ( Section 7.2 for IS-IS, Type 5; 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.

Interaction with Compressed SRv6 SRv6 segment lists can be compressed as specified in . 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 defines for End.DT6 also applies to End.M, since End.M, like End.DT6, is always the last segment of an SR path. The following clarifications apply when compression is used: - The encoding defined in this document is unaffected by compression. The protected locators are advertised in the IGP as IPv6 prefixes in their uncompressed form; SRv6 compression applies to the encoding of segment lists in the data plane, not to the IGP advertisement of locators. - A node that instantiates a Mirror SID with a compressed SID structure SHOULD also advertise the corresponding SRv6 SID Structure information (as defined in and ) 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 .

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 , 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 , 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.

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.

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 . 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 . 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.

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.

IANA Considerations This document requests IANA to make the following assignments in the specified registries.

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 (Section 7.2). Under the existing registry "IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs" ( Section 11.6), IANA is requested to assign the following new sub-sub-TLV:

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 (Section 8). Under the existing registry "OSPFv3 SRv6 Locator LSA Sub-TLVs" ( Section 13.9), IANA is requested to assign the following new sub-TLV:

BGP-LS TLV Registration Under the "BGP-LS NLRI and Attribute TLVs" registry , IANA is requested to assign the following new TLV:

YANG Module Names IANA is requested to register the following YANG module in the "YANG Module Names" registry :

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 , , and . 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 and . 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 and 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 for IS-IS and 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 to limit the scale of deployments.

o

Monitoring IGP database size and convergence times.

References Normative References International Organization for Standardization In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK] This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK] Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication. The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. China Unicom Huawei Futurewei Verizon China Unicom IETF IETF IETF IETF IETF IETF IETF IETF IETF IETF

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 () and with the IS-IS and OSPFv3 data models ( and ) as those models evolve. The module augments the SRv6 locator of the SRv6 base data model, which extends the Segment Routing data model () under the routing data model (), 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 . 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 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2026-09-15 { description "Initial revision."; reference "draft-ietf-lsr-srv6-mirror-sid-igp-encoding"; } feature mirror-sid { description "This feature indicates that the device supports the SRv6 Mirror SID (End.M) behavior and can be configured to protect a primary egress node."; } grouping mirror-sid-entry { description "Configuration and state of a single SRv6 Mirror SID protection entry."; leaf mirror-sid { type inet:ipv6-address; mandatory true; description "The SRv6 Mirror SID (End.M) instantiated on this node. The SID MUST be allocated from a locator of this node."; } leaf-list protected-locator { type inet:ipv6-prefix; description "An SRv6 locator of the primary egress node that is protected by this Mirror SID."; } leaf forwarding-context { type string; description "Name of the local forwarding context (for example, the FIB table) that is associated with this Mirror SID and that reproduces the forwarding behavior of the protected egress node."; } leaf enabled { type boolean; default "true"; description "Controls whether this Mirror SID protection entry is advertised in the IGP and used for protection."; } } augment "/rt:routing/sr:segment-routing/srv6:srv6/srv6:locators/srv6:locator" { description "Augments an SRv6 locator with the Mirror SID protection entries that are allocated from it."; list mirror-sid { if-feature "mirror-sid"; key "mirror-sid"; description "Mirror SID protection entries configured under this locator."; uses mirror-sid-entry; } } } ]]>

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 , the overall egress protection mechanism upon which this document builds.