SRv6 Path Egress Protection
draft-hu-rtgwg-srv6-egress-protection-07

Network Working Group                                              Z. Hu
Internet-Draft                                                    Huawei
Intended status: Standards Track                                 H. Chen
Expires: August 24, 2020                                       Futurewei
                                                                 H. Chen
                                                           China Telecom
                                                                   P. Wu
                                                                  Huawei
                                                                  M. Toy
                                                                 Verizon
                                                                  C. Cao
                                                                   T. He
                                                            China Unicom
                                                                  L. Liu
                                                                 Fujitsu
                                                                  X. Liu
                                                          Volta Networks
                                                       February 21, 2020

                      SRv6 Path Egress Protection
                draft-hu-rtgwg-srv6-egress-protection-07

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

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

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

   This Internet-Draft will expire on August 24, 2020.

Copyright Notice

   Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SR Path Egress Protection . . . . . . . . . . . . . . . . . .   4
   4.  Extensions to IGP for Egress Protection . . . . . . . . . . .   6
     4.1.  Extensions to IS-IS . . . . . . . . . . . . . . . . . . .   6
     4.2.  Extensions to OSPF  . . . . . . . . . . . . . . . . . . .   8
   5.  Behavior for SRv6 Mirror SID  . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.2.  OSPFv3  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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.

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

   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

   LSP:  Label Switched Path

   TE:  Traffic Engineering

   P2MP:  Point-to-MultiPoint

   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

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

   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

   Figure 1 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]
              / |        |&        | \            PE3 Egress
             /  |        |&        |  \           CEx Customer Edge
        [CE1]   |        |&        |   [CE2]      Px  Non-Provider Edge
             \  |        |&        |  /           *** SR Path
              \ |        |& &&&&&  | /            &&& Backup Path
              [PE2]-----[P2]-----[PE4]
                                     Locator: A4:1::/64
                                     VPN SID: A4:1::B100
                                  Mirror SID: A4:1::3, protect A3:1::/64

                  Figure 1: Protecting SR Path Egress PE3

   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 1, CE2 is 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
   a 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 mirror SID is configured on a local PE (e.g., PE4), when
   the local PE (e.g., BGP on the local PE) receives a prefix whose VPN
   SID belongs to a remote PE (e.g., PE3) with the locator that is
   protected by the local PE through mirror SID, the local PE (e.g.,
   PE4) creates a mapping from the remote PE's (e.g., PE3's) VPN SID and

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

   the mirror SID to the local PE's (e.g., PE4's) VPN SID.  The remote
   PE is protected by the local PE.

   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 creates a mapping from remote PE3's VPN SID and the
   mirror SID (i.e., "A3:1::B100, A4:1::3") to local PE4's VPN SID
   (i.e., "A4:1::B100").

   Node P1's pre-computed backup path for destination PE3 having locator
   A3:1::/64 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, node P1 protects PE3 through sending the packet to
   PE4 via the backup path pre-computed.  P1 modifies the packet before
   sending it to PE4.  The modified packet has destination PE4 with
   mirror SID A4:1::3, and SRH with PE3's VPN SID A3:1::B100 and the
   mirror SID A4:1::3 (i.e., "A3:1::B100, A4:1::3; SL=1").

   When PE4 receives the packet, it forwards the packet to CE2 through
   executing END.M instruction according to the local VPN SID (i.e.,
   A4:1::B100).

   For protecting the egress link between PE3 and CE2, when the link
   fails, PE3 acting as PLR like P1 detects the failure and forwards the
   packet to PE4 via the pre-computed backup path from PE3 to PE4.  When
   PE4 receives the packet, it sends the packet to the same CE2.

   Assume that resource X is to be protected by resource Y, where X is
   the egress node of a SR path/tunnel or the egress link between the
   egress node and a CE, Y is the backup egress node for providing
   protection against the failure of X; node Z acting as PLR is the
   direct previous hop of X.  Node Z uses the procedure below to compute
   a backup path from Z to Y without going through X.

   Step 1:  Find the P-Space P(Z, X) and the Q-Space Q(Y, X), which are
      similar to those in [RFC7490];

   Step 2:  Find a post-convergence path from Z to Y without going
      through X;

   Step 3:  Try to get a backup path by intersecting P(Z, X) and Q(Y, X)
      with the post-convergence path;

   Step 4:  If a backup path is found, then return it;

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

   Step 5:  Try to find a shortest path from Z to Y without going
      through X;

   Step 6:  If a backup path is found, then return it;

   Step 7:  Return "No backup path found".

   For a (primary) locator associated with the (primary) egress node of
   a SR path/tunnel, most often the locator is routable.  This is the
   case we assumed, in which the above procedure is used to compute a
   backup path from Z as PLR to Y as backup egress node.

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 End.M 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 Segment
   Identifiers (SIDs) with END.M function for SRv6 path egress
   protection.  The SRv6 End.M SIDs 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-TLVs                           |
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: IS-IS SRv6 End.M SID sub-TLV

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

   Length:  variable.

   Flags:  1 octet.  No flags are currently defined.

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

   SRv6 Endpoint Function:  2 octets.  Add a new endpoint function 40
      for End.M SID.

   SID:  16 octets.  This field contains the SRv6 End.M (i.e., 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 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 3: IS-IS Protected Locators 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-TLV is used to carry the SIDs to be protected by
   the SRv6 mirror SID.  It has the following format.

Hu, et al.               Expires August 24, 2020                [Page 7]
Internet-Draft              Egress Protection              February 2020

     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 (16 octets)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         SID (16 octets)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: IS-IS Protected SIDs sub-TLV

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

   Length:  variable.

   SID:  16 octets.  This field encodes an SRv6 SID to be advertised.

4.2.  Extensions to OSPF

   Similarly, a new sub-TLV, called OSPF SRv6 End.M SID sub-TLV, is
   defined.  It is used to advertise SRv6 Segment Identifiers (SIDs)
   with END.M function for SRv6 path egress protection.  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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     |    SRv6 Endpoint Function     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         SID (16 octets)                       |
    :                                                               :
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            sub-TLVs                           |
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5: OSPF SRv6 End.M SID sub-TLV

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

   Length:  variable.

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

   Flags:  1 octet.  No flags are currently defined.

   SRv6 Endpoint Function:  2 octets.  Add a new endpoint function 40
      for End.M SID.

   SID:  16 octets.  This field contains the SRv6 End.M (i.e., 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 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 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.

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

     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 (16 octets)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         SID (16 octets)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7: OSPF Protected SIDs sub-TLV

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

   Length:  variable.

   SID:  16 octets.  This field encodes an SRv6 SID to be advertised.

5.  Behavior for SRv6 Mirror SID

   The "Endpoint with mirror protection to a VPN SID" function (End.M
   for short) is a variant of the End function.  The End.M is used for
   SRv6 VPN egress protection.  It is described below.

     End.M: Mirror protection
     When N receives a packet destined to S and S is a local End.M SID,
     N does:
     IF NH=SRH and SL = 1 ;; Ref1
        SL--
        Map to a local VPN SID based on Mirror SID and SRH[SL] ;; Ref1
        forward according to the local VPN SID ;; Ref2
     ELSE
      drop the packet

                    Figure 8: SRv6 Mirror SID Procedure

   Ref1:  An End.M SID must always be the penultimate SID.

   Ref2:  The rest forwarding behavior is the same as the corresponding
      VPN sid.

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

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

   document for SRv6 path egress protection should not cause extra
   security issues.

7.  IANA Considerations

7.1.  IS-IS

   Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry"
   [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the
   following new Sub-TLV:

     +==============+========================+===============+
     | Sub-TLV Type | Sub-TLV Name           | Reference     |
     +==============+========================+===============+
     |     8        | SRv6 End.M SID Sub-TLV | This document |
     +--------------+------------------------+---------------+

   IANA is requested to create and maintain a new registry for sub-sub-
   TLVs of the SRv6 End.M SID Sub-TLV.  The suggested registry name is

    o Sub-Sub-TLVs for SRv6 End.M 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

7.2.  OSPFv3

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

     +==============+========================+===============+
     | Sub-TLV Type | Sub-TLV Name           | Reference     |
     +==============+========================+===============+
     |     8        | SRv6 End.M SID Sub-TLV | This document |
     +--------------+------------------------+---------------+

   IANA is requested to create and maintain a new registry for sub-sub-
   TLVs of the SRv6 End.M SID Sub-TLV.  The suggested registry name is

    o Sub-Sub-TLVs for SRv6 End.M SID Sub-TLV

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

   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-65535  Unassigned

8.  Acknowledgements

   The authors would like to thank Peter Psenak, Yimin Shen, Zhenqiang
   Li, Bruno Decraene and Jeff Tantsura for their comments to this work.

9.  References

9.1.  Normative References

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
              Gredler, H., and B. Decraene, "IS-IS Extensions for
              Segment Routing", draft-ietf-isis-segment-routing-
              extensions-25 (work in progress), May 2019.

   [I-D.ietf-lsr-isis-srv6-extensions]
              Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
              Z. Hu, "IS-IS Extension to Support Segment Routing over
              IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-05
              (work in progress), February 2020.

   [I-D.ietf-ospf-segment-routing-extensions]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", draft-ietf-ospf-segment-
              routing-extensions-27 (work in progress), December 2018.

   [I-D.li-ospf-ospfv3-srv6-extensions]
              Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
              "OSPFv3 Extensions for SRv6", draft-li-ospf-
              ospfv3-srv6-extensions-07 (work in progress), November
              2019.

   [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 August 24, 2020               [Page 12]
Internet-Draft              Egress Protection              February 2020

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

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

9.2.  Informative References

   [I-D.hegde-spring-node-protection-for-sr-te-paths]
              Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu,
              "Node Protection for SR-TE Paths", draft-hegde-spring-
              node-protection-for-sr-te-paths-05 (work in progress),
              July 2019.

   [I-D.hu-spring-segment-routing-proxy-forwarding]
              Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE
              Path Midpoint Protection", draft-hu-spring-segment-
              routing-proxy-forwarding-07 (work in progress), January
              2020.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
              Francois, P., Voyer, D., Clad, F., and P. Camarillo,
              "Topology Independent Fast Reroute using Segment Routing",
              draft-ietf-rtgwg-segment-routing-ti-lfa-02 (work in
              progress), January 2020.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-06 (work in progress),
              December 2019.

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

   [I-D.sivabalan-pce-binding-label-sid]
              Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J.,
              Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID
              in PCE-based Networks.", draft-sivabalan-pce-binding-
              label-sid-07 (work in progress), July 2019.

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

   Email: Huaimo.chen@futurewei.com

   Huanan Chen
   China Telecom
   109, West Zhongshan Road, Tianhe District
   Guangzhou  510000
   China

   Email: chenhuan6@chinatelecom.cn

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

   Peng Wu
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: baggio.wupeng@huawei.com

   Mehmet Toy
   Verizon
   USA

   Email: mehmet.toy@verizon.com

   Chang Cao
   China Unicom
   Beijing China

   Email: caoc15@chinaunicom.cn

   Tao He
   China Unicom
   Beijing China

   Email: het21@chinaunicom.cn

   Lei Liu
   Fujitsu
   USA

   Email: liulei.kddi@gmail.com

   Xufeng Liu
   Volta Networks
   McLean, VA
   USA

   Email: xufeng.liu.ietf@gmail.com

Hu, et al.               Expires August 24, 2020               [Page 15]