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

Routing area                                                    S. Hegde
Internet-Draft                                                 C. Bowers
Intended status: Informational                    Juniper Networks, Inc.
Expires: January 19, 2018                                  July 18, 2017

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

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 http://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 January 19, 2018.

Hegde & Bowers          Expires January 19, 2018                [Page 1]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

Copyright Notice

   Copyright (c) 2017 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
   (http://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 adj-sid explicit paths  . . . . . . .   4
     2.3.  Node-protection of binding-sid explicit paths . . . . . .   5
   3.  Detailed Solution using Context Tables  . . . . . . . . . . .   5
     3.1.  Building Context Tables . . . . . . . . . . . . . . . . .   5
     3.2.  Building node protecting paths for node-sids  . . . . . .   5
       3.2.1.  Building node protecting paths for adjacency-sids . .   7
     3.3.  Node protection for binding sids  . . . . . . . . . . . .   8
     3.4.  Node protection for edge nodes  . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   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] and Remote
   loop free alternates [I-D.ietf-rtgwg-rlfa-node-protection] can be
   used to provide node protection to ensure minimal traffic loss after
   a node failure.  The solutions to provide node protection in this
   draft use SPF based local protection mechanisms.

Hegde & Bowers          Expires January 19, 2018                [Page 2]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

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

2.  Node Failures Along SR-TE Paths

       sid:1    sid:2     sid:3       sid:4      sid:5
    1000-2000   1000-2000 1000-2000   1000-2000  1000-2000
      +----+ 10 +----+ 10 +----+  10   +----+ 10 +----+
      | R1 |----| R2 |----| R3  |----- | R4  |-- | R5 |
      +----+    +----+    +----+       +----+    +----+
          \                  \          /
           \ 10               \ 100    / 60
            \                  \      /
             \   +----+         +----+
              +--| R7 |---------| R8 |
                 +----+    30   +----+
                  /   sid:7       sid:8        Packet Header:
                 /    1000-2000   3000-4000    +------------+
                / 10                           |   1008     |
             +----+                            +------------+
             | R6 |                            |   3005     |
             +----+                            +------------+
             sid:6
             1000-2000

                         Figure 1: Sample Network

   The topology shown in Figure 1. illustrates a sample network topology
   with SPRING enabled on each node.  The SRGB and the segment index
   corresponding to each node is described in the topology diagram.

2.1.  Node protection for node-sid explicit paths

   Consider an explicit path from R1->R5 via R1->R7->R8->R4->R5.  This
   path can be built using R1->R8 and R8->R5 shortest paths.  The label
   stack contains two node-sids 1008 and 3005.  The 1008 label would
   take the packet to R8 and get popped.  The next label in the stack
   3005 would take the packet to the destination R5.  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).  R7 does not
   need to understand the meaning of label 3005 in order to perform
   normal forwarding in the absence of a failure.  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.

Hegde & Bowers          Expires January 19, 2018                [Page 3]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

   Anycast addresses are in general advertised by more than one node and
   if per-prefix LFA calculation [RFC5286] is used node protecting paths
   can be found for the anycast sids.  If a node protecting path is
   available for the anycast sid then the context table lookup mechanism
   would not be required.  Otherwise, the anycast label has to be popped
   and next label looked up to find where the packet should be
   forwarded.

2.2.  Node-protection for adj-sid explicit paths

      R1-R2:    R2-R3:    R3-R8:       R4-R5:
      1024      1034      1044         1064
      +----+ 10 +----+ 10 +----+  10   +----+ 10    +----+
      | R1 |----| R2 |----| R3 |-------| R4 |------| R5 |
      +----+    +----+    +----+       +----+       +----+
          \                  \          /
           \ 10               \ 100    / 60
            \                  \      /
             \   +----+         +----+ R8-R5:   Label stack
              +--| R7 |---------| R8 | 1054     for explicit
                 +----+    30   +----+ R8-R7:   path from
                  /                     1074    R1->R5:
                 /                             +------------+
                / 10                           |   1034     |
             +----+                            +------------+
             | R6 |                            |   1044     |
             +----+                            +------------+
                                               |   1054     |
                                               +------------+
                                               |   1064     |
                                               +------------+

               Figure 2: Explicit path using adjacency sids

   Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5.
   This path can be built using adjacency sids, as shown in Figure 2.
   The diagram shows the adjacency sids advertised by each node required
   to realize this path, as well as the complete label stack.  When a
   packet leaving R1 with this label stack reaches R3, the top of stack
   contains the label 1044 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 R3 can learn that the packet needs
   to go to the R4 is to examine the next label in the stack, label
   1054.

Hegde & Bowers          Expires January 19, 2018                [Page 4]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

2.3.  Node-protection of binding-sid explicit paths

   Binding sids (defined in SR architecture
   [I-D.ietf-spring-segment-routing]) allow the SR-TE path to be built
   using a hierarchy of sub-paths.  The binding sid provides a single
   label to represent a set of nodes and links.  If the node advertising
   the binding sid goes down, the traffic needs to be protected.  The
   label stack involving the binding-sid contains next label in the
   stack which corresponds to the end point represented by the binding-
   sid.  The penultimate node of the binding-sid advertiser cannot know
   the meaning of the next label in the stack.

3.  Detailed Solution using Context Tables

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 Information Base (LIB)
   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 LIBs of a particular neighbor.

   When a node learns the node-sid, SRGB, and adjacency-sids or binding-
   sids from a neighbor, the label mapping is added to the context table
   corresponding to that neighbor.  The output actions for the label
   mapping are derived based on the actions that the neighbor would
   perform on receipt of the label.

   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 previous examples

3.2.  Building node protecting paths for node-sids

Hegde & Bowers          Expires January 19, 2018                [Page 5]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

      R7's Transit Routing table
      +=============+=================+
      |in-label     | Out label       |
      +===========+=================+
      | 1001        | Fwd to R1,      |
      +=============+=================+
      | 1002        | swap 1002, Fwd  |
      |             | to R1           |
      +=============+=================+
      | 1003        | swap 1003, Fwd  |
      |             | to R1           |
      +=============+=================+
      | 1004        | swap 1004,      |
      |             |  Fwd to R1      |
      +=============+=================+
      | 1005,       | swap 1005,      |
      |             |  Fwd to R1      |
      +=============+=================+
      | 1008,       | pop, fwd to r8  |
      |             | *pop,lookup     |
      |             |   context.r8    |
      +=============+=================+
       * - Indicates backup path.

      R7's Context Table for R8
      +=============+=================+
      |in-label     | Out label       |
      +=============+=================+
      | 3001        | Fwd to R1,      |
      +=============+=================+
      | 3002        | swap 1002, Fwd  |
      |             | to R1           |
      +=============+=================+
      | 3003        | swap 1003, Fwd  |
      |             | to R1           |
      +=============+=================+
      | 3004        | swap 1004,      |
      |             |  Fwd to R1      |
      +=============+=================+
      | 3005,       | swap 1005,      |
      |             |  Fwd to R1      |
      +=============+=================+

          Figure 3: Transit routing table and Context Table at R7

   The above Figure 3 shows the transit routing table and the context
   table of neighbor R8 built at R7 for the example network shown in

Hegde & Bowers          Expires January 19, 2018                [Page 6]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

   Figure 1.  When the adjacency with R8 comes up, R7 builds the context
   table for R8 and adds the label mappings to the context table by
   adding the node-sid index of all the nodes to the SRGB advertised by
   R8.  The output action is constructed by looking into the R7's SPF
   and backup SPF computations for the next-nexthop.  The backup SPF
   computations as defined in LFA [RFC5286] are applicable here.  The
   R7's SPF and backup SPF computations for the next-nexthop may provide
   multiple loop free primary or backup paths.  A loop free path that
   does not include the failure node (R8 in this example) is chosen and
   downloaded to the context table.

   R7's routing table entry for R8's sid i.e label 1008 will have a pop
   and forward action and the backup path SHOULD have action pop and
   lookup into the context table of R8.  When the node R7 detects R8
   goes down, R7's forwarding plane does a local repair and points to
   the backup path.  When a packet whose top label is 1008 arrives at
   R7, the top label is popped, and the next label is looked up in the
   context table for R8.  As shown in Figure 3, if the next label is
   3005, the packet will be directed to R5 along a path that avoids R8.

3.2.1.  Building node protecting paths for adjacency-sids

Hegde & Bowers          Expires January 19, 2018                [Page 7]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

       R3's Transit Routing table (partial)
      +=============+=================+
      |in-label     | Out label       |
      +=============+=================+
      | 1044        | pop,Fwd to R8,  |
      |             |*pop, lookup     |
      |             |context.r8       |
      +=============+=================+
      | 1004        | pop, Fwd to R4  |
      |             | *push 3004,     |
      |             |  fwd to R8      |
      +=============+=================+

       * - Indicates backup path.

      R3's Context Table for R8 (partial)
      +=============+=================+
      |in-label     | Out label       |
      +=============+=================+
      | 1054        | pop,Fwd to R4,  |
      +=============+=================+
      | 1074        | swap 1007, Fwd  |
      |             | to R2           |
      +=============+=================+

                       Figure 4: Context Table at R3

   The processing for the packet is similar to mechanism explained for
   node sids in section Section 3.2.

   Figure 4 shows the context table constructed at R3 corresponding to
   R8 for the sample network shown in Figure 2.  Adjacency sids are
   attached to the link advertisements in IGPs and the link
   advertisements contain the node information of the remote end.  When
   R3 learns adjacency sids from R8, it builds context table for R8
   which contains the adjacency labels advertised by R8 and the output
   action is built by looking at R3's own SPF and backup SPF
   computations for the remote end point of the link.  Among the
   multiple primary/backup paths to the remote end of the link, a loop
   free path that does not pass through R8 is chosen.

3.3.  Node protection for binding sids

Hegde & Bowers          Expires January 19, 2018                [Page 8]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

       sid:1    sid:2     sid:3       sid:4      sid:5
    1000-2000   1000-2000 1000-2000   1000-2000  1000-2000
      R1-R2:    R2-R3:    R3-R8:      R4-R5:
      1024      1034      1044        1064
          R4:2014 =========================
      +----+ 10 +----+ 10 +----+  10   +----+ 10 +----+
      | R1 |----| R2 |----| R3 |-------| R4  |-- | R5 |
      +----+    +----+    +----+       +----+    +----+
          \                  \          /
           \ 10               \ 100    / 60
            \                  \      /
             \   +----+         +----+
              +--| R7 |---------| R8 | R8-R4:1054
                 +----+    30   +----+ R8-R7:1074
                  /   sid:7       sid:8
                 /    1000-2000   3000-4000
                / 10
             +----+
             | R6 |                          Explicit path from R1->R5:
             +----+                            +------------+
             sid:6                             |   2014     |
             1000-2000                         +------------+
                                               |   1064     |
                                               +------------+

                 Figure 5: Node Protection for Binding SID

   Figure Section 3.3 describes a sample network where R2 advertises a
   binding sid 2014 for the path R2->R3->R4.  This mechanism is very
   useful in compressing the label stack depth as a sub-path can be
   represented using a single label.  The explicit path
   R1->R2->R3->R4->R5 can be represented by 2 label stack as shown in
   above figure.  If the node that advertises the binding-sid goes down,
   protection mechanisms are needed for the binding sid that the node
   advertised.  A receiving node that programs a forwarding path for the
   binding sid should find a node protecting path to the last node of
   the path represented by the binding sid.  In the above sample
   network, R1 programs a backup path for binding sid 2014 with the node
   protecting R-LFA path to R4 which consists of two labels [1008,
   1004].  When the packet reached R4, it has the label 1064 in the
   label stack and can recognize this label and forward to R5.  The node
   protecting path could be computed using various FRR technologies like
   LFA [RFC5286], Remote-LFA [RFC7490] , TI-LFA
   [I-D.francois-rtgwg-segment-routing-ti-lfa] etc.

Hegde & Bowers          Expires January 19, 2018                [Page 9]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

3.4.  Node protection for edge nodes

    sid:1    sid:2     sid:3       sid:4      sid:5
 1000-2000   1000-2000 1000-2000   1000-2000  1000-2000
   R2:1024    R3:1034   R8:1044     R5:1064
       R4:2014 =========================
   +----+ 10 +----+ 10 +----+  10   +----+ 10 +----+
   | PE1|----| R2 |----| R3 |-------| R4  |-- | PE2| context 1.1.1.1: sid 10
   +----+    +----+    +----+       +----+    +----+\
       \                  \          /               \+-----+
        \ 10               \ 100    / 60             /| CE1 |
         \                  \      /               /  +-----+
          \   +----+         +----+ R4:1054 +-----+
           +--| R7 |---------| R8 | --------| PE3 |context 1.1.1.1
              +----+    30   +----+         +-----+sid 10
               /   sid:7       sid:8
              /    1000-2000   3000-4000
             / 10
          +----+
          | R6 |
          +----+
          sid:6
          1000-2000

                 Figure 6: Node Protection for edge nodes

   The node protection mechanisms that are described in previous
   sections depend on the assumption that the label below the top label
   in the label stack are understood in the IGP domain.  If the edge
   node goes down, the label below the top label representing the edge
   node could be BGP service label or labels representing other
   applications.  Service mirroring use case is described in
   [I-D.filsfils-spring-segment-routing-use-cases] The Customer edges
   are multi-homed to provider edges and one of the PE's acts in 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.  The protector PE advertises a binding sid with M bit
   set which implies mirroring capability for the context.  Protector PE
   builds the context table for the BGP service labels advertised by the
   primary PE for the same context.  The BGP service is built using
   stack of labels with context-sid at the bottom of the label
   stack.when the label ranges advertised by the PE2 and the penultimate
   node, Penultimate node does not understand the bottom label which is
   advertised by the node PE2.  Any penultimate node of PE2 builds a
   context table for PE2 as explained in the section Section 3.1.  This
   context table contains the sid for the context-id and output action
   is to pop the top label and replace with the binding sid that the

Hegde & Bowers          Expires January 19, 2018               [Page 10]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

   protector PE advertised for the context 1.1.1.1.  The binding sid
   directs the protector PE to lookup the context table of Primary PE
   for the BGP service labels.  The node protection mechanisms described
   in this document also ensure the edge node protection when uniform
   label range is not assigned across the entire IGP domain.

4.  Security Considerations

   TBD

5.  IANA Considerations

6.  Acknowledgments

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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc5331>.

   [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,
              <http://www.rfc-editor.org/info/rfc7490>.

7.2.  Informative References

   [I-D.filsfils-spring-segment-routing-use-cases]
              Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
              Crabbe, "Segment Routing Use Cases", draft-filsfils-
              spring-segment-routing-use-cases-01 (work in progress),
              October 2014.

   [I-D.francois-rtgwg-segment-routing-ti-lfa]
              Francois, P., Bashandy, A., Filsfils, C., Decraene, B.,
              and S. Litkowski, "Abstract", draft-francois-rtgwg-
              segment-routing-ti-lfa-04 (work in progress), December
              2016.

Hegde & Bowers          Expires January 19, 2018               [Page 11]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

   [I-D.ietf-rtgwg-rlfa-node-protection]
              Sarkar, P., Hegde, S., Bowers, C., Gredler, H., and S.
              Litkowski, "Remote-LFA Node Protection and Manageability",
              draft-ietf-rtgwg-rlfa-node-protection-13 (work in
              progress), January 2017.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-12 (work in progress), June 2017.

   [I-D.minto-rsvp-lsp-egress-fast-protection]
              Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP
              egress fast-protection", draft-minto-rsvp-lsp-egress-fast-
              protection-03 (work in progress), November 2013.

   [ISO10589]
              "Intermediate system to Intermediate system intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service (ISO 8473), ISO/IEC
              10589:2002, Second Edition.", Nov 2002.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <http://www.rfc-editor.org/info/rfc1195>.

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

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <http://www.rfc-editor.org/info/rfc2328>.

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

Authors' Addresses

Hegde & Bowers          Expires January 19, 2018               [Page 12]
Internet-Draft       Node Protection for SR-TE Paths           July 2017

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

   Email: shraddha@juniper.net

   Chris Bowers
   Juniper Networks, Inc.

   Email: cbowers@juniper.net

Hegde & Bowers          Expires January 19, 2018               [Page 13]