Internet-Draft Egress Protection August 2023
Hu, et al. Expires 6 February 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-rtgwg-srv6-egress-protection-12
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Hu
Huawei
H. Chen
Futurewei
M. Toy
Verizon
C. Cao
China Unicom
T. He
China Unicom

SRv6 Path Egress Protection

Abstract

TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path.

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

This Internet-Draft will expire on 6 February 2024.

Table of Contents

1. Introduction

[I-D.ietf-rtgwg-segment-routing-ti-lfa] specifies fast protections for nodes and links that are within a link-state IGP area. In other words, it specifies fast protections for transit nodes and links of an SR path, but does not describe any fast protections for the egress node or link of an SR path.

[RFC8400] and [RFC8679] specify fast protections for egress node(s) and link(s) of an MPLS TE LSP tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details. However, these documents do not discuss any fast protection for the egress node and link of a Segment Routing for IPv6 (SRv6) path or tunnel.

For an SRv6 path from an ingress node to an egress node, the fast protection for the egress node and link of the path can be achieved through using 1 + 1 global protection. This solution uses more network resources and makes operation complex. A backup SRv6 path from the ingress node to a backup egress node is set up. A CE is dual homed to the egress node and the backup egress node. A SID of the egress node is used to forward the traffic to the CE. This same SID is configured on the backup egress node to forward the traffic to the same CE. Both paths transmit the traffic to the same CE, which selects one. The CE selects the traffic from the egress node if the egress node and link work well; otherwise (i.e., the egress node or link failed), the CE selects the traffic from the backup egress node.

This document presents a solution which provides fast protections for the egress node and link of an SRv6 path through extending IGP and using Mirror SID. Compared to 1 + 1 global protection, this solution is more efficient and the operation on it is simpler.

2. Terminologies

The following terminologies are used in this document.

BFD:
Bidirectional Forwarding Detection
BGP:
Border Gateway Protocol
CE:
Customer Edge
DA:
Destination Address
Egress link:
A link from an egress node to another domain [RFC8679]
Egress node:
A domain exit node on a SRv6 path
FIB:
Forwarding Information Base
IGP:
Interior Gateway Protocol
IS-IS:
Intermediate System to Intermediate System
L3VPN:
Layer 3 VPN
LFA:
Loop-Free Alternate
LS:
Link Sate, which is LSA in OSPF or LSP in IS-IS
LSA:
Link State Advertisement in OSPF
LSP:
Label Switched Path in MPLS or Link State Protocol PDU in IS-IS
OSPF:
Open Shortest Path First
P2MP:
Point-to-MultiPoint
P2P:
Point-to-Point
PDU:
Protocol Data Unit
PE:
Provider Edge
PLR:
Point of Local Repair
RL:
Repair List
SA:
Source Address
SID:
Segment Identifier
SR:
Segment Routing
SR path:
A SR path in this document is the active path of a SR Policy [RFC9256]
SRv6:
SR for IPv6
SRv6 path:
A SRv6 path in this document is the active path of a SR Policy with SRv6 SIDs [RFC9256]
TE:
Traffic Engineering
TI-LFA:
Topology Independent LFA
VPN:
Virtual Private Network

3. SR Path Egress Protection

This section describes the mechanism of SR path egress protection and illustrates it through an example.

3.1. Mechanism

Figure 1 is used to explain the mechanism of SR path egress node and link protection.

            *******  *******   SIDa
        [PE1]-----[P1]-----[PEA]---[CE2]    PEA Egress
        / |        |&        | \   /        PEB Backup Egress
       /  |        |&        |  \ /         CEx Customer Edge
  [CE1]   |        |&        |   X          Px  Non-Provider Edge
       \  |        |&        |  / \         *** SR Path
        \ |        |& &&&&&  | /   \        &&& Backup Path
        [PE2]-----[P2]-----[PEB]---[CE3]
                        Mirror SID
Figure 1: PEB Protects Egress PEA of SR Path

Where node PEA is the egress node (or egress for short) of the SR path from PE1 to PEA, and has SIDa which is the active segment in the packet from the SR path at PEA. Node PEB is the backup egress node (or say protector or backup egress for short) to provide the fast protection for the egress node (or say primary egress node) PEA. Node P1 is the direct previous/upstream hop of egress node PEA and acts as PLR (refer to [I-D.ietf-rtgwg-segment-routing-ti-lfa]) to support the fast protection for PEA.

When PEB is selected as a backup egress node to protect the egress node PEA, a Mirror SID (refer to Section 5.1 of [RFC8402]) is configured on PEB to protect PEA. PEB MUST advertise this information through IGP, which includes the Mirror SID and the egress PEA. The information is represented by <PEB, PEA, Mirror SID>, which indicates that PEB protects PEA with Mirror SID.

After PEA receives the information <PEB, PEA, Mirror SID>, it may send the forwarding behavior of the SIDa at PEA to PEB with the Mirror SID using some protocols such as BGP if PEB can not obtain this behavior from other approaches and PEB wants to protect SIDa of PEA. In some cases, PEB can figure out the behavior of the SIDa at PEA from other protocols. For example, when SIDa is a VPN SID of PEA, PEB can get the behavior of the SIDa at PEA based on the VPN SID distribution by [RFC9252] or [RFC4364]. If PEB cannot obtain the behavior of the SIDa at PEA from protocols, the behavior MUST be configured on PEB.

When PEB gets the forwarding behavior of the SIDa of PEA from PEA or other means, it MUST add a forwarding entry for the SIDa according to the behavior into the forwarding table for node PEA. This table is identified by the Mirror SID, which indicates node PEA's context. Using the forwarding entry for SIDa in this table, a packet with SIDa will be transmitted by PEB to the same destination as it is transmitted by PEA. For example, assume that the packet with SIDa is transmitted by PEA to CE2 through the forwarding behavior of the SIDa in PEA. The packet will be transmitted by PEB to the same CE2 through looking up the table identified by the Mirror SID.

After P1 as PLR receives the information <PEB, PEA, Mirror SID> and knows that PEB wants to protect SIDa of PEA, it computes an LFA for PEA assuming that PEA and PEB have a same anycast address. A Repair List RL (or say backup path) is obtained based on the LFA. It is one of the following:

o
RL = <Mirror SID> if the LFA is the next hop node to PEB along the shortest path to PEB; or
o
RL = <S1, ..., Sn, Mirror SID> if the LFA is a TI-LFA, where <S1, ..., Sn> is the TI-LFA Repair List to PEB computed by P1.

When egress node PEA fails, P1 as PLR sends the packet with SIDa carried by the SR path to backup egress node PEB, but MUST encapsulate the packet before sending it by executing H.Encaps with the Repair List RL and a Source Address T.

P1 as PLR needs to retain the route to PEA for a period of time after its IGP converges on the failure of PEA. Thus the backup path for PEA will be used when the other nodes (such as PE1) still send the packet to PEA via P1 since their IGPs do not converge on the failure.

Suppose that the packet received by P1 is represented by Pkt = (S, SIDa)Pkt0, where SA = S and DA = SIDa, and Pkt0 is the rest of the packet.

The execution of H.Encaps pushes an IPv6 header to Pkt and sets some fields in the outer and inner IPv6 header to produce an encapsulated packet Pkt'. Pkt' will be one of the following:

o
Pkt' = (T, Mirror SID) (S, SIDa)Pkt0 if RL = <Mirror SID>; or
o
Pkt' = (T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S, SIDa)Pkt0 if RL = <S1, ..., Sn, Mirror SID>.

When PEB receives the re-routed packet, which is (T, Mirror SID) (S, SIDa)Pkt0, it decapsulates the packet and forwards the decapsulated packet using the FIB table Tm identified by the Mirror SID as a variant of End.DT6 SID. The Mirror SID is called End.M.

It obtains the Mirror SID in the outer IPv6 header of the packet, removes this outer IPv6 header with all its extension headers, and then processes the inner IPv6 packet (i.e., (S, SIDa)Pkt0, the packet without the outer IPv6 header). PEB finds the FIB table Tm for node PEA using the Mirror SID as the context ID, and submits the packet to this FIB table lookup and transmission to the same destination as PEA does.

The behavior of Mirror SID (End.M for short) is a variant of the End.DT6 behavior (refer to Section 4.6 of [RFC8986]). The End.M SID MUST be the last segment in an SR path, and a SID instance is associated with an IPv6 FIB table Tm.

When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M SID, N does the following:

    S01. If (Upper-Layer header type == 41(IPv6) ) {
    S02.    Remove the outer IPv6 header with all its extension headers
    S03.    Set the packet's associated FIB table to Tm
    S04.    Submit the packet to the egress IPv6 FIB lookup for
               transmission to the new destination
    S05. } Else {
    S06.    Process as per Section 4.1.1 of RFC8986
    S07. }

Egress link protection is similar to egress node protection [RFC8679]. When the egress link from egress node PEA to CE2 fails, PEA acting as a PLR reroutes the traffic to backup egress node PEB via a backup path. Specifically, PEA as a PLR pre-computes a Repair List RL (or say backup path) toward PEB after receiving <PEB, PEA, Mirror SID> and knowing that PEB wants to protect SIDa of PEA. When the link fails, PEA as PLR sends the packet with SIDa by executing H.Encaps with the Repair List RL.

3.2. Example

Figure 2 shows an example of fast protecting egress node PE3 of an SR path, which is from ingress node PE1 to egress node PE3.

                                Locator: A3:1::/64
              *******  *******  VPN SID: A3:1::B100
          [PE1]-----[P1]-----[PE3]---[CE2]      PE3 Egress
          / |        |&        | \   /          PE4 Backup Egress
         /  |        |&        |  \ /           CEx Customer Edge
    [CE1]   |        |&        |   X            Px  Non-Provider Edge
         \  |        |&        |  / \           *** SR Path
          \ |        |& &&&&&  | /   \          &&& Backup Path
          [PE2]-----[P2]-----[PE4]---[CE3]
                                Locator: A4:1::/64
                                VPN SID: A4:1::B100
                             Mirror SID: A4:1::3, protect A3:1::/64
Figure 2: PE4 Protects Egress PE3 of SR Path

Where node P1's pre-computed backup path for PE3 is from P1 to PE4 via P2. In normal operations, after receiving a packet with destination PE3, P1 forwards the packet to PE3 according to its FIB. When PE3 receives the packet, it sends the packet to CE2.

When PE3 fails, P1 as PLR detects the failure through using a failure detection mechanism such as BFD and forwards the packet to PE4 via the backup path. When PE4 receives the packet, it sends the packet to the same CE2.

When P1's IGP converges on the failure of PE3, P1 as PLR needs to retain the route to PE3 for a period of time. Thus the backup path for PE3 will be used when the other nodes (such as PE1) still send the packet to PE3 via P1 since their IGPs do not converge on the failure.

In Figure 2, Both CE2 and CE3 are dual home to PE3 and PE4. PE3 has a locator A3:1::/64 and a VPN SID A3:1::B100. PE4 has a locator A4:1::/64 and VPN SID A4:1::B100. A Mirror SID A4:1::3 is configured on PE4 for protecting PE3 with locator A3:1::/64.

After the configuration, PE4 advertises this information through an IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's locator and Mirror SID A4:1::3. Every node in the SR domain will receive this IGP LS, which indicates that PE4 wants to protect PE3 (indicated by PE3's locator) with Mirror SID A4:1::3.

When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4 has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix 1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are for the same VPN.

The forwarding behaviors for these two VPN SIDs are the same from function's point of view. If the behavior for PE3's VPN SID in PE3 forwards the packet with it to CE2, then the behavior for PE4's VPN SID in PE4 forwards the packet to the same CE2; and vice versa. PE4 creates a forwarding entry for PE3's VPN SID A3:1::B100 in the FIB table identified by Mirror SID A4:1::3 according to the forwarding behavior for PE4's VPN SID A4:1::B100.

Node P1's pre-computed backup path for destination PE3 is from P1 to PE4 having mirror SID A4:1::3. When P1 receives a packet destined to PE3's VPN SID A3:1::B100, in normal operations, it forwards the packet with source A1:1:: and destination PE3's VPN SID A3:1::B100 according to the FIB using the destination PE3's VPN SID A3:1::B100.

When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path pre-computed. P1 encapsulates the packet using H.Encaps before sending it to PE4.

Suppose that the packet received by P1 is represented by Pkt = (SA = A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN SID, and Pkt0 is the rest of the packet. The encapsulated packet Pkt' will be one of the following:

o
Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if the LFA is the next hop node to PE4 along the shortest path to PE4; or (otherwise)
o
Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1; SL=n) (A1:1::, A3:1::B100)Pkt0.

where T is a Source Address, <S1, ..., Sn> is the TI-LFA Repair List to PE4 computed by P1.

When PE4 receives the re-routed packet, it decapsulates the packet and forwards the decapsulated packet by executing the behavior of End.M for the Mirror SID that is associated with the IPv6 FIB table for PE3. The packet received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID A3:1::B100)Pkt0.

PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the packet, removes this outer IPv6 header, and then processes the inner IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the FIB table for PE3 using Mirror SID A4:1::3 as the context ID, gets the forwarding entry for PE3's VPN SID A3:1::B100 from the table, and forwards the packet to CE2 using the entry.

4. Extensions to IGP for Egress Protection

This section describes extensions to IS-IS and OSPF for advertising the information about SRv6 path egress protection.

4.1. Extensions to IS-IS

A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It is used in the SRv6 Locator TLV defined in [RFC9352] to advertise SRv6 Mirror SID and the locators of the nodes to be protected. The SRv6 Mirror SID inherit the topology/algorithm from the parent locator. 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 3: IS-IS SRv6 Mirror SID sub-TLV
Type:
TBD1 (suggested value 8) is to be assigned by IANA.
Length:
variable.
Reserved:
1 octet. This octet MUST be set to zero on transmit, and ignored on receipt.
SRv6 Endpoint Function:
2 octets. It contains the endpoint function 74 for Mirror SID.
SID:
16 octets. This field contains the SRv6 Mirror SID to be advertised.

A protected locators sub-sub-TLV is defined and used to carry the Locators of the egress nodes to be protected by the SRv6 mirror SID. 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: IS-IS Protected Locators sub-sub-TLV
Type:
TBD2 (suggested value 1) is to be assigned by IANA.
Length:
variable.
Locator-Size:
1 octet. Number of bits (1 - 128) in the Locator field.
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.

When node B advertises that B wants to protect node A with a Mirror SID through an LSP, the LSP MUST have an SRv6 Locator TLV containing an IS-IS SRv6 Mirror SID sub-TLV, which includes the Mirror SID and node A's locator in an IS-IS Protected locators sub-sub-TLV.

4.2. Extensions to OSPF

Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined. It is used in the SRv6 Locator TLV defined in [I-D.ietf-lsr-ospfv3-srv6-extensions] to advertise SRv6 Mirror SID and the locators of the nodes to be protected. Its format 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 (TBD4)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Reserved          |    SRv6 Endpoint Function     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SID (16 octets)                       |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            sub-TLVs                           |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OSPF SRv6 Mirror SID sub-TLV
Type:
TBD4 (suggested value 8) is to be assigned by IANA.
Length:
variable.
Reserved:
2 octets. It MUST be set to zero for transmission and ignored on reception.
SRv6 Endpoint Function:
2 octets. It contains the endpoint function 74 for End.M SID.
SID:
16 octets. This field contains the SRv6 Mirror SID to be advertised.

A protected locators sub-TLV is defined and used to carry the locators of the nodes to be protected by the SRv6 Mirror SID. 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 (TBD5)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  |  Locator (variable)           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  |  Locator (variable)           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OSPF Protected Locators sub-TLV
Type:
TBD5 (suggested value 1) is to be assigned by IANA.
Length:
variable.
Locator-Size:
1 octet. Number of bits (1 - 128) in the Locator field.
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.

When node B advertises that B wants to protect node A with a Mirror SID through an LSA, the LSA MUST have an SRv6 Locator TLV containing an OSPF SRv6 Mirror SID sub-TLV, which includes the Mirror SID and node A's locator in an OSPF Protected Locators sub-TLV.

5. Security Considerations

The egress protection specified in this document involves rerouting traffic around an egress node or link failure, via a backup path from a PLR to a backup egress node. The forwarding performed by the nodes in the data plane is anticipated, as part of the planning of egress protection.

The extensions to control plane protocol OSPF or IS-IS are used to support the egress protection on the nodes in an OSPF or IS-IS area. The area is in a single administrative domain. The extensions described in this document should not cause extra security issues.

In addition, the PLR and backup egress node are located close to the egress node, which is in the same administrative domain.

Security attacks may sometimes come from a customer domain. Such attacks are not introduced by the egress protection in this document and may occur regardless of the existence of egress protection. In one possible case, the egress link between an egress node and a CE could become a point of attack. An attacker that gains control of the CE might use it to simulate link failures and trigger constant and cascading activities in the network. If egress link protection is in place, egress link protection activities may also be triggered. As a general solution to defeat the attack, a damping mechanism SHOULD be used by the egress node to promptly suppress the services associated with the link or CE. The egress node would stop delivering the services to CE, essentially detaching them from the network and eliminating the effect of the simulated link failures.

6. IANA Considerations

6.1. SRv6 Endpoint Behaviors

Under sub-registry "SRv6 Endpoint Behaviors" [RFC8986], IANA has assigned the following for End.M Endpoint Behavior:

  +==============+========+=====================+===============+
  | Value        | Hex    | Endpoint behavior   | Reference     |
  +==============+========+=====================+===============+
  |   74         | 0x004A | End.M (Mirror SID)  | This document |
  +--------------+--------+---------------------+---------------+

6.2. IS-IS

Under "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability registry", IANA is requested to add the following new Sub-TLV:

  +==============+=========================+===============+
  |     Type     | Description             | Reference     |
  +==============+=========================+===============+
  |     8        | SRv6 Mirror SID         | This document |
  +--------------+-------------------------+---------------+

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. The future assignments are to be made through IETF Review [RFC5226].

  Value    Sub-Sub-TLV Name                 Definition
  -----   -----------------------          -------------
  0       Reserved
  1       Protected Locators Sub-Sub-TLV   This Document
  2-255   Unassigned

6.3. OSPFv3

Under registry "OSPFv3 Locator LSA Sub-TLVs" [I-D.ietf-lsr-ospfv3-srv6-extensions], IANA is requested to assign the following new Sub-TLVs:

  +==============+============================+===============+
  | Sub-TLV Type | Sub-TLV Name               | Reference     |
  +==============+============================+===============+
  |     8        | SRv6 Mirror SID Sub-TLV    | This document |
  +--------------+----------------------------+---------------+
  |     11       | Protected Locators Sub-TLV | This document |
  +--------------+----------------------------+---------------+

7. References

7.1. Normative References

[I-D.ietf-lsr-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf-lsr-ospfv3-srv6-extensions-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-15>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8400]
Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, "Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection", RFC 8400, DOI 10.17487/RFC8400, , <https://www.rfc-editor.org/info/rfc8400>.
[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, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8667]
Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, , <https://www.rfc-editor.org/info/rfc8667>.
[RFC8679]
Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., Michel, C., and H. Chen, "MPLS Egress Protection Framework", RFC 8679, DOI 10.17487/RFC8679, , <https://www.rfc-editor.org/info/rfc8679>.
[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, , <https://www.rfc-editor.org/info/rfc8986>.
[RFC9256]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/info/rfc9256>.
[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, , <https://www.rfc-editor.org/info/rfc9352>.

7.2. Informative References

[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-11>.
[RFC3107]
Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, , <https://www.rfc-editor.org/info/rfc3107>.
[RFC4364]
Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, , <https://www.rfc-editor.org/info/rfc4364>.
[RFC5226]
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, , <https://www.rfc-editor.org/info/rfc5226>.
[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, , <https://www.rfc-editor.org/info/rfc9252>.

Acknowledgments

The authors would like to thank Acee Lindem, Peter Psenak, Yimin Shen, Jie Dong, Zhenqiang Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene, Jeff Tantsura, Chris Bowers, Ketan Talaulikar, Bob Halley, Tal Mizrahi and Yingzhen Qu for their comments to this work.

Contributors' Addresses

Huanan Chen
China Telecom
109, West Zhongshan Road, Tianhe District
Guangzhou
510000
China
Email: chenhn8.gd@chinatelecom.cn

Peng Wu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Email: baggio.wupeng@huawei.com

Lei Liu
Fujitsu
United States of America
Email: liulei.kddi@gmail.com

Xufeng Liu
Alef Edge
United States of America
Email: xufeng.liu.ietf@gmail.com

Authors' Addresses

Zhibo Hu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Huaimo Chen
Futurewei
Boston, MA,
United States of America
Mehmet Toy
Verizon
United States of America
Chang Cao
China Unicom
Tao He
China Unicom