Skip to main content

Use-cases for Resiliency in SPRING
draft-ietf-spring-resiliency-use-cases-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8355.
Authors Pierre Francois , Clarence Filsfils , Bruno Decraene , Rob Shakir
Last updated 2016-07-13 (Latest revision 2016-07-07)
Replaces draft-francois-spring-resiliency-use-case
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state In WG Last Call
Document shepherd Stephane Litkowski
IESG IESG state Became RFC 8355 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to "Stephane Litkowski" <stephane.litkowski@orange.com>
draft-ietf-spring-resiliency-use-cases-04
Internet-Draft         SPRING Resiliency use-cases             July 2016

   link metrics are equal to 1, with the exception of the links from/to
   A and Z, which are configured with a metric of 100.

2.  Path protection

   A first protection strategy consists in excluding any local repair
   but instead use end-to-end path protection.

   For example, a Pseudo Wire (PW) from A to Z can be "path protected"
   in the direction A to Z in the following manner: the operator
   configures two SPRING paths T1 and T2 from A to Z. The two paths are
   installed in the forwarding plane of A and hence are ready to forward
   packets.  The two paths are made disjoint using the SPRING
   architecture.

   T1 is established over path {AB, BC, CD, DE, EZ} and T2 over path
   {AF, FG, GH, HI, IZ}.  When T1 is up, the packets of the PW are sent
   on T1.  When T1 fails, the packets of the PW are sent on T2.  When T1
   comes back up, the operator either allows for an automated reversion
   of the traffic onto T1 or selects an operator-driven reversion.  The
   solution to detect the end-to-end liveness of the path is out of the
   scope of this document.

   From a SPRING viewpoint, we would like to highlight the following
   requirement: the two configured paths T1 and T2 MUST NOT benefit from
   local protection.

3.  Management free local protection

   This section describes two alternatives to provide local protection
   without requiring operator management, namely bypass protection and
   shortest-path based protection.

   For example, a demand from A to Z, transported over the shortest
   paths provided by the SPRING architecture, benefits from management-
   free local protection by having each node along the path
   automatically pre-compute and pre-install a backup path for the
   destination Z. Upon local detection of the failure, the traffic is
   repaired over the backup path in sub-50msec.

   The backup path computation should support the following
   requirements:

   o  100% link, node, and SRLG protection in any topology

Pierre Francois, et al.  Expires January 8, 2017                [Page 4]
Internet-Draft         SPRING Resiliency use-cases             July 2016

   o  Automated computation by the IGP
   o  Selection of the backup path such as to minimize the chance for
      transient congestion and/or delay during the protection period, as
      reflected by the IGP metric configuration in the network.

3.1.  Management free bypass protection

   One way to provide local repair is to enforce a failover along the
   shortest path around the failed component, ending at the protected
   nexthop, so as to bypass the failed component and re-join the pre-
   convergence path at the nexthop.  In the case of node protection,
   such bypass ends at the next-nexthop.

   In our example, C protects Z, that it initially reaches via CD, by
   enforcing the traffic over the bypass {CH, HD}.  The resulting end-
   to-end path between A and Z, upon recovery against the failure of
   C-D, is depicted in Figure 2.

                           B * * *C------D * * *E
                          *|      | *  / * *  / |*
                         * |      |  */  *  */  | *
                        A  |      |  /*  *  /*  |  Z
                         \ |      | /  * * /  * | *
                          \|      |/    **/    *|*
                           F------G------H------I

                Figure 2: Bypass protection around link C-D

3.2.  Management-free shortest path based protection

   An alternative protection strategy consists in management-free local
   protection, aiming at providing a repair for the destination based on
   shortest path state for that destination.

   In our example, C protects Z, that it initially reaches via CD, by
   enforcing the traffic over its shortest path to Z, considering the
   failure of the protected component.  The resulting end-to-end path
   between A and Z, upon recovery against the failure of C-D, is
   depicted in Figure 3.

                           B * * *C------D------E
                          *|      | *  / | \  * |*
                         * |      |  */  |  \*  | *
                        A  |      |  /*  |  *\  |  Z
                         \ |      | /  * | *  \ | *
                          \|      |/    *|*    \|*
                           F------G------H * * *I

Pierre Francois, et al.  Expires January 8, 2017                [Page 5]
Internet-Draft         SPRING Resiliency use-cases             July 2016

                       Figure 3: Reference topology

4.  Managed local protection

   There may be cases where a management free repair does not fit the
   policy of the operator.  For example, in our illustration, the
   operator may want to not have C-D and C-H used to protect each other,
   in fear of a shared risk among the two links.

   In this context, the protection mechanism must support the explicit
   configuration of the backup path either under the form of high-level
   constraints (end at the next-hop, end at the next-next-hop, minimize
   this metric, avoid this SRLG...) or under the form of an explicit
   path.

   We discuss such aspects for both bypass and shortest path based
   protection schemes.

4.1.  Managed bypass protection

   Let us illustrate the case using our reference example.  For the
   demand from A to Z, the operator does not want to use the shortest
   failover path to the nexthop, {CH, HD}, but rather the path
   {CG,GH,HD}, as illustrated in Figure 4.

                           B * * *C------D * * *E
                          *|      * \  / * *  / |*
                         * |      *  \/  *  */  | *
                        A  |      *  /\  *  /*  |  Z
                         \ |      * /  \ * /  * | *
                          \|      */    \*/    *|*
                           F------G * * *H------I

                    Figure 4: Managed bypass protection

4.2.  Managed shortest path protection

   In the case of shortest path protection, the case is the one of an
   operator who does not want to use the shortest failover via link C-H,
   but rather reach H via {CG, GH}.

   The resulting end-to-end path upon activation of the protection is
   illustrated in Figure 5.

Pierre Francois, et al.  Expires January 8, 2017                [Page 6]
Internet-Draft         SPRING Resiliency use-cases             July 2016

                           B * * *C------D------E
                          *|      * \  / | \  * |*
                         * |      *  \/  |  \*  | *
                        A  |      *  /\  |  *\  |  Z
                         \ |      * /  \ | *  \ | *
                          \|      */    \|*    \|*
                           F------G * * *H * * *I

                Figure 5: Managed shortest path protection

5.  Loop avoidance

   Transient inconsistencies among the Forwarding Information Bases of
   routers converging after a change in the state of links of the
   network can occur.  Such inconsistencies (some nodes forwarding
   traffic according to the past network topology while some other nodes
   are forwarding packets according to the new topology) may lead to
   forwarding loops.

   The SPRING architecture SHOULD provide solutions to prevent the
   occurrence of micro-loops during convergence following a change in
   the network state.  A SPRING enabled router could take advantage of
   the increased packet steering capabilities offered by SPRING in order
   to steer packets in a way that packets do not enter such loops.

6.  Co-existence

   The operator may want to support several very-different services on
   the same packet-switching infrastructure.  As a result, the SPRING
   architecture SHOULD allow for the co-existence of the different use
   cases listed in this document, in the same network.

   Let us illustrate this with the following example.

   o  Flow F1 is supported over path {C, C-D, E}
   o  Flow F2 is supported over path {C, C-D, I)
   o  Flow F3 is supported over path {C, C-D, Z)
   o  Flow F4 is supported over path {C, C-D, Z}

   It should be possible for the operator to configure the network to
   achieve path protection for F1, management free shortest path local
   protection for F2, managed protection over path {C-G, G-H, Z} for F3,
   and management free bypass protection for F4.

Pierre Francois, et al.  Expires January 8, 2017                [Page 7]
Internet-Draft         SPRING Resiliency use-cases             July 2016

7.  Security Considerations

   This document lists various ways to provide resiliency in networks by
   using Segment Routing Policies.  As such they do not introduce any
   new security considerations compared to the security considerations
   related to the use of segment routing itself [1].

8.  Manageability considerations

   This document provides use cases.  Solutions aimed at supporting
   these use cases should provide the necessary mechansisms to allow for
   manageability.

9.  References

   [1]  Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R.
        Shakir, "Segment Routing Architecture",
        draft-ietf-spring-segment-routing-09 (work in progress),
        July 2016.

Authors' Addresses

   Pierre Francois
   Cisco Systems, Inc.
   Vimercate
   IT

   Email: pifranco@cisco.com

   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   BE

   Email: cfilsfil@cisco.com

   Bruno Decraene
   Orange
   Issy-les-Moulineaux
   FR

   Email: bruno.decraene@orange.com

Pierre Francois, et al.  Expires January 8, 2017                [Page 8]
Internet-Draft         SPRING Resiliency use-cases             July 2016

   Rob Shakir
   Jive Communications, Inc.
   Orem
   US

   Email: rjs@rob.sh

Pierre Francois, et al.  Expires January 8, 2017                [Page 9]