Skip to main content

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

Document Type Active Internet-Draft (rtgwg WG)
Authors Zhibo Hu, Huaimo Chen , Mehmet Toy , Chang Cao , Tao He
Last updated 2024-02-01
Replaces draft-hu-rtgwg-srv6-egress-protection
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
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-16
Network Working Group                                              Z. Hu
Internet-Draft                                                    Huawei
Intended status: Standards Track                                 H. Chen
Expires: 4 August 2024                                         Futurewei
                                                                  M. Toy
                                                                 Verizon
                                                                  C. Cao
                                                                   T. He
                                                            China Unicom
                                                         1 February 2024

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

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 4 August 2024.

Hu, et al.                Expires 4 August 2024                 [Page 1]
Internet-Draft              Egress Protection              February 2024

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SR Path Egress Protection . . . . . . . . . . . . . . . . . .   4
     3.1.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Egress Node Protection  . . . . . . . . . . . . . . .   5
       3.1.2.  Egress Link Protection  . . . . . . . . . . . . . . .   8
     3.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Extensions to IGP for Egress Protection . . . . . . . . . . .  11
     4.1.  Extensions to IS-IS . . . . . . . . . . . . . . . . . . .  11
     4.2.  Extensions to OSPF  . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . .  16
     6.2.  IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.3.  OSPFv3  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Contributors' Addresses . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

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.

Hu, et al.                Expires 4 August 2024                 [Page 2]
Internet-Draft              Egress Protection              February 2024

   [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

Hu, et al.                Expires 4 August 2024                 [Page 3]
Internet-Draft              Egress Protection              February 2024

   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.

Hu, et al.                Expires 4 August 2024                 [Page 4]
Internet-Draft              Egress Protection              February 2024

3.1.  Mechanism

   Figure 1 is used to explain the mechanism of SR path egress node and
   egress 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

3.1.1.  Egress Node Protection

   Desired Pathways in Figure 1:

   Node PEA in Figure 1 is the egress node (aka 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 node
   (aka protector or backup egress) to provide the fast protection for
   the egress node (aka primary egress node) PEA.  Node P1 is the direct
   previous/upstream endpoint 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.

   Steps in Creating the Pathways:

   Step 1: Normal Pathway Set-up

   Normal path set-up establishes the SR path from ingress PE1 to egress
   PEA via P1.  Ingress PE1 imports the traffic from CE1 into the SR
   path and egress PEA delivers the traffic from the SR path to CE2.

   Step 2: Backup Pathway Set-up

   Step 2a: PEB Announces to Protect PEA

Hu, et al.                Expires 4 August 2024                 [Page 5]
Internet-Draft              Egress Protection              February 2024

   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.

   Step 2b: PEB Gets Forwarding Behavior of PEA

   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.  This information is sent via BGP if PEB can not obtain
   this behavior from other protocols or other information.  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].  If
   PEB cannot obtain the behavior of the SIDa at PEA from protocols, the
   behavior MUST be configured on PEB.

   Step 2c: PEB Creates FIB for PEA

   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.

   Step 2d: P1 as PLR Prepares to Protect PEA by PEB

   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.

   Step 3: Backup Path Is Engaged upon PEA Failure

   Step 3a: P1 Detects PEA Failure via BFD or Other Mechanisms

Hu, et al.                Expires 4 August 2024                 [Page 6]
Internet-Draft              Egress Protection              February 2024

   Step 3b: P1 Sends Packet with SIDa to Backup Egress PEB

   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,
   SID-P1)(SIDa,SID-P1; SL=1)Pkt0, where SA = S and DA = SID-P1 (i.e.,
   SID of P1), and Pkt0 is the rest of the packet.  P1 sets DA to SIDa,
   updates SL and executes H.Encaps.

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

   Step 3c: PEB Decapsulates Packet and Forwards It

   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 4 August 2024                 [Page 7]
Internet-Draft              Egress Protection              February 2024

     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.1.2.  Egress Link Protection

   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.

               SID-P1: A5:1::A100  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

   Desired Pathways in Figure 2:

   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.

Hu, et al.                Expires 4 August 2024                 [Page 8]
Internet-Draft              Egress Protection              February 2024

   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.  P1 has SID-P1 =
   A5:1::A100.

   Steps in Creating the Pathways:

   Step 1: Normal Pathway Set-up [PEB is PE4, PEA is PE3]

   Step 2: Backup Pathway Set-up

   Step 2a: PE4 (aka PEB) Announces to Protect PE3 (aka PEA)

   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.

   Step 2b: PE4 (aka PEB) Gets Forwarding Behavior of PE3 (aka PEA)

   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.

   Step 2c: PE4 (aka PEB) Creates FIB for PE3 (aka PEA)

Hu, et al.                Expires 4 August 2024                 [Page 9]
Internet-Draft              Egress Protection              February 2024

   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.

   Step 2d: P1 Prepares to Protect PE3 (aka PEA) by PE4 (aka PEB)

   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.

   Step 3: Backup Path Is Engaged upon PE3 (aka PEA) Failure

   Step 3a: P1 Detects PE3 (aka PEA) Failure via BFD

   Step 3b: P1 Sends Packet with SIDa to Backup Egress PE4 (aka PEB)

   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=A5:1::A100)(SIDa=A3:1::B100,SID-P1=A5:1::A100;SL=1)
   Pkt0, where DA = A5:1::A100 is P1's SID, A3:1::B100 is PE3's VPN SID,
   and Pkt0 is the rest of the packet.  P1 sets DA to A3:1::B100,
   updates SL, and encapsulates 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.

   Step 3c: PE4 (aka PEB) Decapsulates Packet and Forwards It

   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.

Hu, et al.                Expires 4 August 2024                [Page 10]
Internet-Draft              Egress Protection              February 2024

   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:  1 octet.  Its value MUST NOT be less than 23. 23 is 19
      (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus
      4 (i.e., the minimum size of a IS-IS protected locators sub-sub-
      TLV).  The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if
      the length is less than 23.

   Reserved:  1 octet.  This octet MUST be set to zero on transmit, and
      ignored on receipt.

Hu, et al.                Expires 4 August 2024                [Page 11]
Internet-Draft              Egress Protection              February 2024

   SRv6 Endpoint Function:  2 octets.  It MUST contain the endpoint
      function 74 for Mirror SID.  The entire IS-IS SRv6 Mirror SID sub-
      TLV MUST be ignored if it does not contain the endpoint function
      74.

   SID:  16 octets.  This field contains the SRv6 Mirror SID to be
      advertised.  It MUST NOT be zero (0).  The entire IS-IS SRv6
      Mirror SID sub-TLV MUST be ignored if it contains zero (0).

   A protected locators sub-sub-TLV is defined and used to carry the
   Locators of the egress node to be protected by the SRv6 mirror SID.
   The IS-IS SRv6 Mirror SID sub-TLV MUST include one IS-IS protected
   locators sub-sub-TLV.  It has the following format.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type (TBD2)  |    Length     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   SID-Size    |         SID (variable)                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   SID-Size    |         SID (variable)                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: IS-IS Protected Locators sub-sub-TLV

   Type:  TBD2 (suggested value 1) is to be assigned by IANA.

   Length:  1 octet.  Its value MUST NOT be less than 2.  The entire IS-
      IS SRv6 Mirror SID sub-TLV MUST be ignored if the length is less
      than 2.

   Locator-Size:  1 octet.  Number of bits in the Locator field, which
      MUST be from the range (1-128).  The entire IS-IS SRv6 Mirror SID
      sub-TLV MUST be ignored if the Loc-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.

Hu, et al.                Expires 4 August 2024                [Page 12]
Internet-Draft              Egress Protection              February 2024

   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 locators 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:  2 octets.  Its value MUST NOT be less than 26. 26 is 20
      (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus
      6 (i.e., the minimum size of a OSPF protected locators sub-TLV).
      The entire OSPF SRv6 Mirror SID sub-TLV MUST be ignored if the
      length is less than 26.

   Reserved:  2 octets.  It MUST be set to zero for transmission and
      ignored on reception.

   SRv6 Endpoint Function:  2 octets.  It MUST contain the endpoint
      function 74 for End.M SID.  The entire OSPF SRv6 Mirror SID sub-
      TLV MUST be ignored if it does not contain the endpoint function
      74.

   SID:  16 octets.  This field contains the SRv6 Mirror SID to be

Hu, et al.                Expires 4 August 2024                [Page 13]
Internet-Draft              Egress Protection              February 2024

      advertised.  It MUST NOT be zero (0).  The entire OSPF SRv6 Mirror
      SID sub-TLV MUST be ignored if it contains zero (0).

   A protected locators sub-TLV is defined and used to carry the
   locators of the node to be protected by the SRv6 Mirror SID.  The
   OSPF SRv6 Mirror SID sub-TLV MUST include one OSPF protected locators
   sub-TLV.  It has the following format.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Type (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:  2 octets.  Its value MUST NOT be less than 2.  The entire
      OSPF SRv6 Mirror SID sub-TLV MUST be ignored if the Length is less
      than 2.

   Locator-Size:  1 octet.  Number of bits (1 - 128) in the Locator
      field.  Number of bits in the Locator field, which MUST be from
      the range (1-128).  The entire OSPF SRv6 Mirror SID sub-TLV MUST
      be ignored if the Loc-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.

   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 locators in an OSPF Protected Locators sub-TLV.

Hu, et al.                Expires 4 August 2024                [Page 14]
Internet-Draft              Egress Protection              February 2024

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 IS-IS or OSPFv3 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.

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

   Security concerns for IS-IS are addressed in [ISO10589], [RFC5304]
   and [RFC5310].  While IS-IS is deployed under a single administrative
   domain, there can be deployments where potential attackers have
   access to one or more networks in the IS-IS routing domain.  In these
   deployments, the stronger authentication mechanisms defined in the
   aforementioned documents SHOULD be used.

   Security concerns for OSPFv3 are described in [RFC5340] and
   [RFC8362].  While OSPFv3 is under a single administrative domain,
   there can be deployments where potential attackers have access to one
   or more networks in the OSPFv3 routing domain.  In these deployments,
   stronger authentication mechanisms such as those specified in
   [RFC4552] and [RFC7166] SHOULD be used.

   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

Hu, et al.                Expires 4 August 2024                [Page 15]
Internet-Draft              Egress Protection              February 2024

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:

Hu, et al.                Expires 4 August 2024                [Page 16]
Internet-Draft              Egress Protection              February 2024

     +==============+============================+===============+
     | 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, 21 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
              ospfv3-srv6-extensions-15>.

   [ISO10589] ISO, "Intermediate System to Intermediate System Intra-
              Domain Routing Exchange Protocol for use in Conjunction
              with the Protocol for Providing the Connectionless-mode
              Network Service (ISO 8473)", ISO/IEC 10589:2002, November
              2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
              <https://www.rfc-editor.org/info/rfc4552>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <https://www.rfc-editor.org/info/rfc5304>.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, DOI 10.17487/RFC5310, February
              2009, <https://www.rfc-editor.org/info/rfc5310>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.

Hu, et al.                Expires 4 August 2024                [Page 17]
Internet-Draft              Egress Protection              February 2024

   [RFC7166]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
              Authentication Trailer for OSPFv3", RFC 7166,
              DOI 10.17487/RFC7166, March 2014,
              <https://www.rfc-editor.org/info/rfc7166>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
              F. Baker, "OSPFv3 Link State Advertisement (LSA)
              Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
              2018, <https://www.rfc-editor.org/info/rfc8362>.

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

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

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

Hu, et al.                Expires 4 August 2024                [Page 18]
Internet-Draft              Egress Protection              February 2024

   [RFC9352]  Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
              and Z. Hu, "IS-IS Extensions to Support Segment Routing
              over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
              February 2023, <https://www.rfc-editor.org/info/rfc9352>.

7.2.  Informative References

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Bashandy, A., Litkowski, S., 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-
              13, 16 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
              segment-routing-ti-lfa-13>.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
              <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, February
              2006, <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, May 2008,
              <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, July 2022,
              <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, Yingzhen Qu and Susan Hares for their comments
   to this work.

Contributors' Addresses

Hu, et al.                Expires 4 August 2024                [Page 19]
Internet-Draft              Egress Protection              February 2024

   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
   Email: huzhibo@huawei.com

   Huaimo Chen
   Futurewei
   Boston, MA,
   United States of America
   Email: hchen.ietf@gmail.com

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

Hu, et al.                Expires 4 August 2024                [Page 20]
Internet-Draft              Egress Protection              February 2024

   Chang Cao
   China Unicom
   Email: caoc15@chinaunicom.cn

   Tao He
   China Unicom
   Email: het21@chinaunicom.cn

Hu, et al.                Expires 4 August 2024                [Page 21]