Skip to main content

Node Protection for SR-TE Paths
draft-hegde-spring-node-protection-for-sr-te-paths-03

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 "Replaced".
Authors Shraddha Hegde , Chris Bowers , Stephane Litkowski , Xiaohu Xu
Last updated 2018-07-02
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hegde-spring-node-protection-for-sr-te-paths-03
Routing area                                                    S. Hegde
Internet-Draft                                                 C. Bowers
Intended status: Informational                     Juniper Networks Inc.
Expires: January 3, 2019                                    S. Litkowski
                                                                  Orange
                                                                   X. Xu
                                                            Alibaba Inc.
                                                            July 2, 2018

                    Node Protection for SR-TE Paths
         draft-hegde-spring-node-protection-for-sr-te-paths-03

Abstract

   Segment routing supports the creation of explicit paths using
   adjacency-sids, node-sids, and binding-sids.  It is important to
   provide fast reroute (FRR) mechanisms to respond to failures of links
   and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path.  A
   point of local repair (PLR) can provide FRR protection against the
   failure of a link in an SR-TE path by examining only the first (top)
   label in the SR label stack.  In order to protect against the failure
   of a node, a PLR may need to examine the second label in the stack as
   well in order to determine SR-TE path beyond the failed node.  This
   document specifies how a PLR can use the first and second label in
   the label stack describing an SR-TE path to provide protection
   against node failures.

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

Hegde, et al.            Expires January 3, 2019                [Page 1]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   This Internet-Draft will expire on January 3, 2019.

Copyright Notice

   Copyright (c) 2018 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.  Node Failures Along SR-TE Paths . . . . . . . . . . . . . . .   3
     2.1.  Node protection for node-sid explicit paths . . . . . . .   3
     2.2.  Node-Protection for Anycast-SIDs  . . . . . . . . . . . .   4
     2.3.  Node-protection for adj-sid explicit paths  . . . . . . .   5
   3.  Detailed Solution using Context Tables  . . . . . . . . . . .   6
     3.1.  Building Context Tables . . . . . . . . . . . . . . . . .   6
     3.2.  Node protection for node SIDs . . . . . . . . . . . . . .   7
     3.3.  Node protection for ajacency SIDs . . . . . . . . . . . .   8
     3.4.  Node protection for edge nodes  . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   It is possible for a routing device to completely go out of service
   abruptly due to power failure, hardware failure or software crashes.
   Node protection is an important property of the Fast Reroute
   mechanism.  It provides protection against a node failure by
   rerouting traffic around the failed node.  For example, the
   mechanisms described in Loop Free Alternates ([RFC5286]), Remote Loop
   Free Alternates ([RFC8102]), and
   [I-D.bashandy-rtgwg-segment-routing-ti-lfa] can be used to provide
   node protection to ensure minimal traffic loss after a node failure.

Hegde, et al.            Expires January 3, 2019                [Page 2]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   Section 2 describes problems with SR-TE paths and the need for a
   specialized mechanism to provide node protection for SR-TE paths.
   Section 3 describes the solution applied to paths built using
   adjacency-sids and node-sids.  Section 3.4 describes the solution
   applied to egress node protection.

2.  Node Failures Along SR-TE Paths

   The topology shown in Figure 1. illustrates a example network
   topology with SPRING enabled on each node.

      Node          Node          Node          Node          Node
      sid:1         sid:2         sid:3         sid:4         sid:5
      +----+   10   +----+   10   +----+   10   +----+   10   +----+
      | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
      +----+        +----+        +----+        +----+        +----+
          \                           \          /
           \ 10                        \ 100    / 60
            \                           \      /
             \   +----+                  +----+
              +--| R7 |------------------| R8 |
                 +----+    30            +----+
                / Node                   Node             Label stack:
               /  sid:7                  sid:8            +------------+
         +----+                          SRGB:            |  1008 (top)|
         | R6 |                          3000-4000        +------------+
         +----+                                           |  3005      |
         Node                                             +------------+
         sid:6

   Figure 1: Example topology.  The segment index for each node is shown
     in the diagram.  All nodes have SRGB = [1000-2000], except for R8
   which has SRGB = [3000-4000].  A label stack that represents the path
                   R1->R7->R8->R4->R5 is shown as well.

2.1.  Node protection for node-sid explicit paths

   Consider an explicit path in the topology in Figure 1 from R1->R5 via
   R1->R7->R8->R4->R5.  This path can be built using the shortest paths
   from R1-to-R8 and R8-to-R5.  The label stack to instantiate this path
   contains two node-sids 1008 and 3005.  The 1008 label will take the
   packet from R1 to R8 via R7 and get popped.  The next label in the
   stack 3005 will take the packet from R8 to the destination R5 via R4.
   If the node R8 goes down, it is not possible for R7 to perform FRR
   without examining the second label in the incoming label stack
   (3005).

Hegde, et al.            Expires January 3, 2019                [Page 3]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   Note that in the absence of a failure, R7 does not need to understand
   the meaning of the second label (3005) in order to perform normal
   forwarding.  However, in order to support node protection, R7 will
   need to understand the meaning of label 3005 in order to determine
   where the packet is headed after R8.

2.2.  Node-Protection for Anycast-SIDs

   A prefix segment advertised as a node SID may only be advertised by
   one node in the network.  Instead, an anycast prefix segment may be
   advertised by more than one node.  In some situations, one can use
   anycast SIDs to construct SR-TE paths that are protected against node
   failure, without the need for the mechanism described in this
   document.

      +----+   10   +----+   10   +----+   10   +----+   10   +----+
      | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
      +----+        +----+        +----+        +----+        +----+
          \                           \          / |
           \ 10                        \100   60/  |
            \                           \      /   |
             \   +----+    30            +----+    |
              +--| R7 |------------------| R8 |    |
                 +----+                  +----+    |
                /    \                  Anycast    +
               /      \                 sid:100   /
         +----+        \                         /
         | R6 |         \    40          +----+ /60
         +----+          +---------------| R9 |+          Label stack:
                                         +----+           +------------+
                                        Anycast           |  1100 (top)|
                                        sid:100           +------------+
                                                          |  1005      |
                                                          +------------+

      Figure 2: Topology illustrating use of anycast-sids to protect
        against node failures.  All nodes have SRGB = [1000-2000].

   An example of this is shown in Figure 2.  In this example, R8 and R9
   advertise an anycast SID of 100.  The label stack in this example =
   [1100, 1005];.  The top label (1100) corresponds to the anycast SID
   advertised by both R8 and R9.  In the absence of a failure, the
   packet sent by R1 with this label stack will follow the path from
   R1->R5 along R1->R7->R8->R4->R5.

   If R7 is performing a per-prefix LFA calculation [RFC5286], then R7
   will install a backup next-hop to R9 for this anycast SID, protecting
   against the failure of the primary next-hop to R8.  This backup path

Hegde, et al.            Expires January 3, 2019                [Page 4]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   does not pass through R8, so it is would not be affected by a
   complete failure of node R8.  As illustrated by this example, for
   some topologies node-protecting SR-TE paths can constructed through
   the use of anycast SIDs, as opposed to the mechanism described in
   this document.

2.3.  Node-protection for adj-sid explicit paths

                                  Adj-sid:
                                  R3-R8:9044

      Node          Node          Node          Node          Node
      sid:1         sid:2         sid:3         sid:4         sid:5
      +----+   10   +----+   10   +----+   10   +----+   10   +----+
      | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 |
      +----+        +----+        +----+        +----+        +----+
          \                           \          /              |
           \ 10                        \ 100    / 60            | 10
            \                           \      /                |
             \   +----+                  +----+               +----+
              +--| R7 |------------------| R8 |---------------| R9 |
                 +----+    30            +----+      10       +----+
                / Node                   Node                 Node
               /  sid:7                  sid:8                sid:9
         +----+                          SRGB:
         | R6 |                          3000-4000        Label stack:
         +----+                                           +------------+
         Node                            Adj-sids:        |  1003 (top)|
         sid:6                           R8-R4:9054       +------------+
                                                          |  9044      |
                                                          +------------+
                                                          |  9054      |
                                                          +------------+
                                                          |  1005      |
                                                          +------------+

   Figure 3: Explicit path using an adjacency sid.  All nodes have SRGB
        = [1000-2000], except for R8 which has SRGB = [3000-4000].

   Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5.
   This path can be built using a combination of node sids and adjacency
   sids, as shown in Figure 3.  The diagram shows shows the label stack
   needed to instantiate this path, as well as several adjacency sids
   advertised by nodes involved in this path.  When a packet leaving R1
   with this label stack reaches R3, the top label is 9044, which will
   take the packet to R8.  The next-next-hop in the path is R4.  To
   provide protection for the failure of node R8, R3 would need to send
   the the packet to R4 without going through R8.  However, the only way

Hegde, et al.            Expires January 3, 2019                [Page 5]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   R3 can learn that the packet needs to go to the R4 is to examine the
   next label in the stack, label 9054.  Since R3 knows that R8 has
   advertised label 9054 as the adjacency segment for the link from R8
   to R4, R3 knows that a backup path can merge back into the original
   explicit path at R4.

3.  Detailed Solution using Context Tables

   This section provides a detailed description of how to construct
   node-protecting backup paths for SR-TE paths using context tables.
   The end result of this description is externally visible forwarding
   behavior that can be specified as a packet arriving at a PLR with a
   particular incoming label stack and leaving the PLR on a particular
   outgoing interface with a particular outgoing label stack.  There may
   be other methods of arriving at the same externally visible
   forwarding behavior.  It is not the intent of this document to
   exclude other methods, as long as the externally visible forwarding
   behavior is the same as produced by this method.

3.1.  Building Context Tables

   [RFC5331] introduced the concept of Context Specific Label Spaces and
   there are various applications making use of this concept.A context
   label table on a router represents the Label Forwarding Information
   Base (LFIB) from the point of view of a particular neighbor . Context
   tables are built by constructing incoming label mappings advertised
   by the neighbor and the actions corresponding to those labels.  The
   labels advertised by each node are local to the node and may not be
   unique across the segment routing domain.  The context tables are
   separate tables built on a per-neighbor basis on every node to ensure
   they represent LFIBs of a particular neighbor.

   When a PLR needs to protect an SR-TE path against the failure of a
   neighbor N, it creates a context table associated with N.  This
   context table is populated with the following segment routing
   forwarding entries:

      - All the Prefix-SIDs of the network which have N as the primary
      nexthop.  The programmed incoming label map uses the SRGB of N to
      compute the input label value.  The NHLFE (Next Hop Label
      Forwarding Entry) is then constructed by looking into all the
      nexthops for the prefix-SID and choosing a loop-free path as
      explained in Section 3.2

      - All the Adjacency SIDs advertised by N.  The NHLFE is
      constructed as explained in Section 3.3

Hegde, et al.            Expires January 3, 2019                [Page 6]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   The following section illustrates how the context table is
   constructed to allow the PLR to provide node-protecting paths for the
   next-next hops in the topology shown in Figure 1 and Figure 3.

3.2.  Node protection for node SIDs

   Figure 4 shows the routing table entries on R7 corresponding to the
   node SIDs to reach R1 and R8 for the topology in Figure 1.  In the
   absence of a failure, a packet with a label stack whose top label is
   1008 will have its top label popped by R7 (assuming PHP behavior),
   and R7 will forward the packet to R8.  When the interface to R8 is
   down, the backup next-hop entry is used.  R7 will pop the top label
   of 1008, and use the context table that R7 computed for R8 to
   evaluate the next label on the stack.

       R7's Routing Table (partial)
       Transits routes for Node SIDs for R1 and R8
      +=============+=============================================+
      | In label    | Outgoing label action                       |
      +=============+=============================================+
      | 1001        | Primary: pop, fwd to R1                     |
      |             | Backup: pop, lookup context.r1              |
      +-------------+---------------------------------------------+
      | 1008        | Primary: pop, fwd to R8                     |
      |             | Backup: pop, lookup context.r8              |
      +-------------+---------------------------------------------+

       R7's Context Table for R8 (context.r8, partial)
      +=============+=============================================+
      | In label    | Outgoing label action                       |
      +=============+=============================================+
      | 3004        | swap 1004, fwd to R1                        |
      +-------------+---------------------------------------------+
      | 3005        | swap 1005, fwd to R1                        |
      +-------------+---------------------------------------------+
      | 3008        | swap 1008, fwd to R1                        |
      +-------------+---------------------------------------------+

      Figure 4: Building node-protecting backup paths for SR-TE paths
                            involving node SIDs

   R7 builds context table for R8 using the following process.  R7
   computes the mapping of incoming label to node-sid that R8 expects to
   see based on the SRGB advertised by R8.  In the example in Figure 1,
   R7 can determine that R8 interprets in incoming label of 3005 as
   mapping to the the node SID for R5.

Hegde, et al.            Expires January 3, 2019                [Page 7]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   R7 then computes a loop-free backup path to reach R5 which is node-
   protecting with respect to the failure of R8.  In this example, the
   backup path computed by R7 to reach R5 without passing through R8 can
   be achieved forwarding the packet to R1 with a top label of 1005,
   corresponding to the node SID for R5 in the context of R1's SRGB.
   The loop-free path computation may be based on a mechanism such as
   LFA, R-LFA, TI-LFA, or constraint based SPF avoiding failure.  To
   populate the context table for R8, R7 maps the out label actions
   corresponding to the backup path to R5 to the incoming label 3005.
   This results in the entry for label 3005 showin in context.r8 in
   Figure 4.

   Therefore, when a packet arrives at R7 with label stack = [1008,
   3005], and the link from R7 to R8 has recently failed, R7 will use
   backup next-hop entry for label 1008 in its main routing table.
   Based on this entry, R7 will pop label 1008, and use context.r8 to
   lookup the new top label = 3005.  R7 will swap label 3005 for 1005
   and forward the packet to R1.  This will get the packet to R5 on a
   node protecting backup path.

   Note that R7 activates the node-protecting backup path when it
   detects that the link to R8 has failed.  R7 does not know that node
   R8 has actually failed.  However, the node-protecting backup path is
   computed assuming that the failure of the link to R8 implies that R8
   has failed.

3.3.  Node protection for ajacency SIDs

   This section gives an example of how to constuct node-protecting
   backup paths when the SR-TE path uses adjacency SIDs.  Figure 5 shows
   some of the routing table entries for R3 corresponding to the sample
   network shown in Figure 3.  When the top label of the label stack is
   an adjacency SID, the PLR needs to recognize that in order to provide
   a node-protecting backup path, it needs to pop the top label and
   examine the next label in the context of the next-hop router
   identified by the top label adjacency SID.  In this example, when R3
   is constructing its routing table, it recognizes that label 9044
   corresponds to a next-hop of R8, so it installs a backup entry,
   corresponding to the failure of the link to R8, when pops label 9044,
   and then examines the new top label in the context of R8.

Hegde, et al.            Expires January 3, 2019                [Page 8]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

       R3's Routing Table (partial)
       Transit route for Adj SID
      +=============+=============================================+
      | In label    | Outgoing label action                       |
      +=============+=============================================+
      | 9044        | Primary: pop, fwd to R8                     |
      |             | Backup: pop, lookup context.r8              |
      +-------------+---------------------------------------------+

       R3's Context Table for R8 (context.r8, partial)
      +=============+=============================================+
      | In label    | Outgoing label action                       |
      +=============+=============================================+
      | 3005        | swap 1005, fwd to R4                        |
      +-------------+---------------------------------------------+
      | 9054        | pop, fwd to R4                              |
      +-------------+---------------------------------------------+

      Figure 5: Building node-protecting backup paths for SR-TE paths
                         involving adjacency SIDs

   R3 constructs its context table for R8 by determining which labels R8
   expects to receive to accomplish different forwarding actions.  The
   entry for incoming label 3005 in context.r8 in Figure 5 corresponds
   to a node SID.  This entry is computed using the methods described in
   Section 3.2

   The entry for incoming label 9054 in context.r8 corresponds to an
   adjacency SID.  R3 recognizes that R8 has advertised this adjacency
   SID for the link from R8 to R4 in Figure 3.  So R3 determines the
   outgoing label action needed to reach R4 without passing through R8.
   This can be accomplished by popping the label 9054, and forwarding
   the packet directly on the link from R3 to R4.

3.4.  Node protection for edge nodes

   The node protection mechanism described in the previous sections
   depends on the assumption that the label immediately below the top
   label in the label stack is understood in the IGP domain.  In the
   example topology in Figure 6, CE-A and CE-B are customer edge routers
   receiving services from provider edge routers.  The provider edge
   routers are exchanging service labels via BGP or some other non-IGP
   mechanism.

Hegde, et al.            Expires January 3, 2019                [Page 9]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

                                                       Primary PE:
                                                       context 1.1.1.1
                                                       prefix sid: 201

    Node         Node          Node          Node        Node
    sid:1        sid:2         sid:3         sid:4       sid:5
    +---+   10   +----+   10   +----+   10   +----+ 10   +---+   +----+
    |PE1|--------| R2 |--------| R3 |--------| R4 |------|PE5|---|CE-A|
    +---+        +----+        +----+        +----+      +---+   +----+
       \                           \          /               \  /
        \ 10                        \ 100    / 60              \/
         \                           \      /                  /\
          \   +----+                  +----+             +---+/  +----+
           +--| R7 |------------------| R8 |-------------|PE9+---|CE-B|
              +----+    30            +----+  10         +---+   +----+
             / Node                   Node               Node
            /  sid:7                  sid:8              sid:9
      +----+
      | R6 |                                           Protector PE:
      +----+                                           context 1.1.1.1/32
      Node                                             prefix sid: 201
      sid:6                                            context label: 40001

                                 Normal                Protection
                                 label stack           label stack
                                 +------------+        +------------+
                                 |  1201 (top)|        |  1201 (top)|
                                 +------------+        +------------+
                                 |  70099     |        |  40001     |
                                 +------------+        +------------+
                                                       |  70099     |
                                                       +------------+

     Figure 6: Node Protection for edge nodes.  All nodes have SRGB =
                               [1000-2000].

   A packet with label stack = [1005,70099] sent from PE1 out the
   interface to R2 would be forwarded along the path
   PE1->R2->R3->R4->PE5.  Assuming PHP behavior, PE5 receives the packet
   with the label stack = [70099].  PE5 uses the service label 70099 to
   send the packet to CE-B with the appropriate service characteristics.

   If PE5 fails, R4 can act as a PLR, redirecting the packet to PE9.
   However, when PE9 receives the packet, it needs to be able to
   understand the meaning of the meaning of the service label 70099.
   The service mirroring use case described in
   [I-D.ietf-spring-segment-routing] addresses this issue.  The customer

Hegde, et al.            Expires January 3, 2019               [Page 10]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   edge (CE) routers are multi-homed to provider edge (PE) routers, and
   one of the PE's acts in a primary role and the other in protector
   role.  The two PEs advertise a context IP address for each customer
   site and attaches a prefix-sid to the context.  In IS-IS, the
   protector PE advertises a Label Binding TLV with the M-bit set which
   associates a context-label with the context.  The Protector PE builds
   the context table for the BGP service labels using the BGP service
   labels advertised by the primary PE for the same context.  In order
   for the Protector PE to know when to use the context table, packets
   need to arrive at the Protector PE with the context-label exposed.

   Each node acting as a PLR with respect to failure of the Primary PE
   installs a backup routing entry that accomplishes two things.  The
   route gets the packet to the Protector PE.  And it positions the
   context-label immediately above the service label in the label stack,
   so that the Protector PE is able to identify the correct context
   table to interpret the service label.

   We now continue with the example topology in Figure 6 using the
   service mirroring mechansim.  PE5 is the Primary PE, while PE9 is the
   Protector PE.  PE5 and PE9 both advertise the anycast prefix
   1.1.1.1/32 with prefix-SID=201.  In addition, PE9 advertises a
   context-label of 40001 for the context identified by 1.1.1.1.  PE9
   builds a context table for the BGP service labels advertised by PE5
   associated with 1.1.1.1.  In the event of a failure of the link from
   R4 to PE5, R4 makes sure that the packet originally destined for PE5
   is forwarded on the interface to R8 with label stack =
   [1201,40001,70099].  This gets the packet to PE9 with label stack =
   [40001,70099] (assuming PHP behavior).  PE9 then uses the context
   label of 40001 to determine the context table corresponding to
   1.1.1.1 on PE5.  After popping the context label, PE9 is able to
   process the top label [70099] using the context table where 70099 has
   the appropriate meaning.

4.  Security Considerations

   TBD

5.  IANA Considerations

6.  Acknowledgments

   The authors would like to thank Peter Psenak for his review and
   suggestions.

Hegde, et al.            Expires January 3, 2019               [Page 11]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

7.  References

7.1.  Normative References

   [RFC5286]  Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
              IP Fast Reroute: Loop-Free Alternates", RFC 5286,
              DOI 10.17487/RFC5286, September 2008,
              <https://www.rfc-editor.org/info/rfc5286>.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, DOI 10.17487/RFC5331, August 2008,
              <https://www.rfc-editor.org/info/rfc5331>.

7.2.  Informative References

   [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
              Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
              Francois, P., and d. daniel.voyer@bell.ca, "Topology
              Independent Fast Reroute using Segment Routing", draft-
              bashandy-rtgwg-segment-routing-ti-lfa-04 (work in
              progress), April 2018.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

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

   [RFC8102]  Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and
              S. Litkowski, "Remote-LFA Node Protection and
              Manageability", RFC 8102, DOI 10.17487/RFC8102, March
              2017, <https://www.rfc-editor.org/info/rfc8102>.

Authors' Addresses

   Shraddha Hegde
   Juniper Networks Inc.
   Exora Business Park
   Bangalore, KA  560103
   India

   Email: shraddha@juniper.net

Hegde, et al.            Expires January 3, 2019               [Page 12]
Internet-Draft       Node Protection for SR-TE Paths           July 2018

   Chris Bowers
   Juniper Networks Inc.

   Email: cbowers@juniper.net

   Stephane Litkowski
   Orange

   Email: stephane.litkowski@orange.com

   Xiaohu Xu
   Alibaba Inc.
   Beijing
   China

   Email: xiaohu.xxh@alibaba-inc.com

Hegde, et al.            Expires January 3, 2019               [Page 13]