Skip to main content

SRv6 Path Egress Protection
draft-ietf-rtgwg-srv6-egress-protection-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Zhibo Hu, Huaimo Chen , China Telecom , Peng Wu , Mehmet Toy , Chang Cao , Tao He , Lei Liu , Xufeng Liu
Last updated 2022-09-09
Replaces draft-hu-rtgwg-srv6-egress-protection
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
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-rtgwg-srv6-egress-protection-06
Network Working Group                                              Z. Hu
Internet-Draft                                                    Huawei
Intended status: Standards Track                                 H. Chen
Expires: 13 March 2023                                         Futurewei
                                                                 H. Chen
                                                           China Telecom
                                                                   P. Wu
                                                                  Huawei
                                                                  M. Toy
                                                                 Verizon
                                                                  C. Cao
                                                                   T. He
                                                            China Unicom
                                                                  L. Liu
                                                                 Fujitsu
                                                                  X. Liu
                                                          Volta Networks
                                                        9 September 2022

                      SRv6 Path Egress Protection
               draft-ietf-rtgwg-srv6-egress-protection-06

Abstract

   This document describes protocol extensions for protecting the egress
   node of a Segment Routing for IPv6 (SRv6) path or tunnel.

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 RFC 2119 [RFC2119].

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

Hu, et al.                Expires 13 March 2023                 [Page 1]
Internet-Draft              Egress Protection             September 2022

   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 13 March 2023.

Copyright Notice

   Copyright (c) 2022 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.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SR Path Egress Protection . . . . . . . . . . . . . . . . . .   4
     3.1.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Extensions to IGP for Egress Protection . . . . . . . . . . .   9
     4.1.  Extensions to IS-IS . . . . . . . . . . . . . . . . . . .   9
     4.2.  Extensions to OSPF  . . . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . .  14
     6.2.  IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.3.  OSPFv3  . . . . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Hu, et al.                Expires 13 March 2023                 [Page 2]
Internet-Draft              Egress Protection             September 2022

1.  Introduction

   The fast protection of a transit node of a Segment Routing (SR) path
   or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and
   [I-D.hu-spring-segment-routing-proxy-forwarding].  [RFC8400]
   specifies the fast protection of egress node(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 the fast protection of the
   egress node of a Segment Routing for IPv6 (SRv6) path or tunnel.

   This document fills that void and presents protocol extensions for
   the fast protection of the egress node of an SRv6 path or tunnel.
   Egress node and egress, fast protection and protection as well as
   SRv6 path and SRv6 tunnel will be used exchangeably below.

   There are a number of topics related to the egress protection, which
   include the detection of egress node failure, the relation between
   egress protection and global repair, and so on.  These are discussed
   in details in [RFC8679].

2.  Terminologies

   The following terminologies are used in this document.

   SR:  Segment Routing

   SRv6:  SR for IPv6

   SRH:  Segment Routing Header

   SID:  Segment Identifier

   LSA:  Link State Advertisement in OSPF

   LSP:  Label Switched Path in MPLS or Link State Protocol PDU in IS-IS

   PDU:  Protocol Data Unit

   LS:  Link Sate, which is LSA in OSPF or LSP in IS-IS

   TE:  Traffic Engineering

   SA:  Source Address

   DA:  Destination Address

   P2MP:  Point-to-MultiPoint

Hu, et al.                Expires 13 March 2023                 [Page 3]
Internet-Draft              Egress Protection             September 2022

   P2P:  Point-to-Point

   CE:  Customer Edge

   PE:  Provider Edge

   LFA:  Loop-Free Alternate

   TI-LFA:  Topology Independent LFA

   BFD:  Bidirectional Forwarding Detection

   VPN:  Virtual Private Network

   L3VPN:  Layer 3 VPN

   VRF:  Virtual Routing and Forwarding

   FIB:  Forwarding Information Base

   PLR:  Point of Local Repair

   BGP:  Border Gateway Protocol

   IGP:  Interior Gateway Protocol

   OSPF:  Open Shortest Path First

   IS-IS:  Intermediate System to Intermediate System

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

Hu, et al.                Expires 13 March 2023                 [Page 4]
Internet-Draft              Egress Protection             September 2022

               *******  *******   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 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 (or say protector) to provide the
   protection for egress (or say primary egress) PEA.  Node P1 is the
   direct previous hop of egress PEA and acts as PLR to support the
   protection for PEA.

   When PEB is selected as a backup egress to protect the egress PEA, a
   Mirror SID (refer to Section 5.1 of [RFC8402]) is configured on PEB
   to protect PEA.  PEB advertises 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 if PEB wants to protect SIDa of
   PEA.  How to send the forwarding behavior of the SIDa to PEB is out
   scope of this document.

   When PEB gets the forwarding behavior of the SIDa of PEA from PEA or
   other means, it adds 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 a shortest
   path to PEB.  A Repair List RL is obtained based on the path.  It is
   one of the followings:

Hu, et al.                Expires 13 March 2023                 [Page 5]
Internet-Draft              Egress Protection             September 2022

   o  RL = <Mirror SID> if the path does not go through PEA; or

   o  RL = <S1, ..., Sn, Mirror SID> if the path goes through PEA, where
      <S1, ..., Sn> is the TI-LFA Repair List to PEB computed by P1.

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

   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 followings:

   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:

Hu, et al.                Expires 13 March 2023                 [Page 6]
Internet-Draft              Egress Protection             September 2022

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

3.2.  Example

   Figure 2 shows an example of protecting egress PE3 of a SR path,
   which is from ingress PE1 to egress 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.

   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.

Hu, et al.                Expires 13 March 2023                 [Page 7]
Internet-Draft              Egress Protection             September 2022

   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'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`s locator 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 followings:

   o  Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if backup
      path not via PE3; 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 the backup path to PE4 goes through PE3.

Hu, et al.                Expires 13 March 2023                 [Page 8]
Internet-Draft              Egress Protection             September 2022

   When PE4 receives the re-routed packet, it decapsulates the packet
   and forwards the decapsulated packet by executing End.DT6 behavior
   for an End.DT6 SID instance.  The SID instance is End.M, 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
   [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Mirror SID and
   the locators of the node 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     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     |    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.

Hu, et al.                Expires 13 March 2023                 [Page 9]
Internet-Draft              Egress Protection             September 2022

   Length:  variable.

   Flags:  1 octet.  No flags are currently defined.

   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.

   Two sub-sub-TLVs are defined.  One is the protected locators sub-sub-
   TLV, and the other is the protected SIDs sub-sub-TLV.

   A protected locators sub-sub-TLV is used to carry the Locators 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 to be
      protected by the SRv6 mirror SID.  The Locator is encoded in the
      minimal number of octets for the given number of bits.

   A protected SIDs sub-sub-TLV is used to carry the SIDs to be
   protected by the SRv6 Mirror SID.  It has the following format.

Hu, et al.                Expires 13 March 2023                [Page 10]
Internet-Draft              Egress Protection             September 2022

     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     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   SID-Size    |         SID (variable)                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   SID-Size    |         SID (variable)                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5: IS-IS Protected SIDs sub-sub-TLV

   Type:  TBD3 (suggested value 2) is to be assigned by IANA.

   Length:  variable.

   SID-Size:  1 octet.  Number of bits in the SID field.  It is from 1
      to 128.  When it is less than 128, the SID field is a locator.
      When it is 128, the SID field is an SRv6 SID.

   SID:  1-16 octets.  This field encodes an SRv6 SID to be protected.
      The SID 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.

   When node B advertises that B wants to protect node A's locators with
   a Mirror SID through an LSP, the LSP contains an IS-IS SRv6 Mirror
   SID sub-TLV, which includes the Mirror SID and the node A's locators
   in an IS-IS Protected locators sub-sub-TLV.  If B wants to protect
   just a specific set of SIDs of node A, the Mirror SID sub-TLV
   includes these SIDs in an IS-IS Protected SIDs sub-sub-TLV.

4.2.  Extensions to OSPF

   Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined.
   It is used to advertise SRv6 Mirror SID and the locators of the node
   to be protected.  Its format is illustrated below.

Hu, et al.                Expires 13 March 2023                [Page 11]
Internet-Draft              Egress Protection             September 2022

     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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     |    SRv6 Endpoint Function     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         SID (16 octets)                       |
    :                                                               :
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            sub-TLVs                           |
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6: OSPF SRv6 Mirror SID sub-TLV

   Type:  TBD4 (suggested value 8) is to be assigned by IANA.

   Length:  variable.

   Flags:  1 octet.  No flags are currently defined.

   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.

   Two sub-TLVs are defined.  One is the protected locators sub-TLV, and
   the other is the protected SIDs sub-TLV.

   A protected locators sub-TLV is used to carry the locators of the
   node 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)           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hu, et al.                Expires 13 March 2023                [Page 12]
Internet-Draft              Egress Protection             September 2022

                 Figure 7: 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 to be
      protected by the SRv6 mirror SID.  The Locator is encoded in the
      minimal number of octets for the given number of bits.

   A protected SIDs sub-TLV is used to carry the SIDs 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 (TBD6)           |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   SID-Size    |         SID (variable)                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   SID-Size    |         SID (variable)                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 8: OSPF Protected SIDs sub-TLV

   Type:  TBD6 (suggested value 2) is to be assigned by IANA.

   Length:  variable.

   SID-Size:  1 octet.  Number of bits in the SID field.  It is from 1
      to 128.  When it is less than 128, the SID field is a locator.
      When it is 128, the SID field is an SRv6 SID.

   SID:  1-16 octets.  This field encodes an SRv6 SID to be protected.
      The SID 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.

Hu, et al.                Expires 13 March 2023                [Page 13]
Internet-Draft              Egress Protection             September 2022

5.  Security Considerations

   The security about the egress protection is described in in details
   in [RFC8679].  The extensions to OSPF and IS-IS described in this
   document for SRv6 path egress protection should not cause extra
   security issues.

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       Protected SIDs Sub-Sub-TLV
     3-255   Unassigned

Hu, et al.                Expires 13 March 2023                [Page 14]
Internet-Draft              Egress Protection             September 2022

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-TLV:

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

7.  Acknowledgements

   The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang
   Li, Alexander Vainshtein, Greg Mirsky, Bruno Decraene, Jeff Tantsura,
   Chris Bowers and Ketan Talaulikar for their comments to this work.

8.  References

8.1.  Normative References

   [I-D.ietf-lsr-isis-srv6-extensions]
              Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
              Z. Hu, "IS-IS Extensions to Support Segment Routing over
              IPv6 Dataplane", Work in Progress, Internet-Draft, draft-
              ietf-lsr-isis-srv6-extensions-18, 20 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-
              extensions-18.txt>.

   [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-07, 23 August 2022,
              <https://www.ietf.org/archive/id/draft-ietf-lsr-
              ospfv3-srv6-extensions-07.txt>.

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

Hu, et al.                Expires 13 March 2023                [Page 15]
Internet-Draft              Egress Protection             September 2022

   [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
              Scope Link State PDUs (LSPs)", RFC 7356,
              DOI 10.17487/RFC7356, September 2014,
              <https://www.rfc-editor.org/info/rfc7356>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <https://www.rfc-editor.org/info/rfc7490>.

   [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, June
              2018, <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,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
              H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", RFC 8665,
              DOI 10.17487/RFC8665, December 2019,
              <https://www.rfc-editor.org/info/rfc8665>.

   [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, December 2019,
              <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, December 2019,
              <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, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

8.2.  Informative References

   [I-D.hu-spring-segment-routing-proxy-forwarding]
              Hu, Z., Chen, H., Yao, J., Bowers, C., Yongqing, and
              Yisong, "SR-TE Path Midpoint Restoration", Work in

Hu, et al.                Expires 13 March 2023                [Page 16]
Internet-Draft              Egress Protection             September 2022

              Progress, Internet-Draft, draft-hu-spring-segment-routing-
              proxy-forwarding-20, 18 August 2022,
              <https://www.ietf.org/archive/id/draft-hu-spring-segment-
              routing-proxy-forwarding-20.txt>.

   [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-
              08, 21 January 2022, <https://www.ietf.org/archive/id/
              draft-ietf-rtgwg-segment-routing-ti-lfa-08.txt>.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", Work in
              Progress, Internet-Draft, draft-ietf-spring-segment-
              routing-policy-22, 22 March 2022,
              <https://www.ietf.org/archive/id/draft-ietf-spring-
              segment-routing-policy-22.txt>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <https://www.rfc-editor.org/info/rfc5462>.

Authors' Addresses

   Zhibo Hu
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: huzhibo@huawei.com

   Huaimo Chen
   Futurewei
   Boston, MA,
   United States of America
   Email: Huaimo.chen@futurewei.com

Hu, et al.                Expires 13 March 2023                [Page 17]
Internet-Draft              Egress Protection             September 2022

   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

   Mehmet Toy
   Verizon
   United States of America
   Email: mehmet.toy@verizon.com

   Chang Cao
   China Unicom
   Email: caoc15@chinaunicom.cn

   Tao He
   China Unicom
   Email: het21@chinaunicom.cn

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

   Xufeng Liu
   Volta Networks
   McLean, VA
   United States of America
   Email: xufeng.liu.ietf@gmail.com

Hu, et al.                Expires 13 March 2023                [Page 18]