Skip to main content

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

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 Clarence Filsfils , Stefano Previdi , Pierre Francois , Bruno Decraene , Rob Shakir
Last updated 2016-09-19
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-05
Network Working Group                                   C. Filsfils, Ed.
Internet-Draft                                           S. Previdi, Ed.
Intended status: Informational                               P. Francois
Expires: March 23, 2017                              Cisco Systems, Inc.
                                                             B. Decraene
                                                                  Orange
                                                               R. Shakir
                                                     Jive Communications
                                                      September 19, 2016

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

Abstract

   This document identifies and describe the requirements for a set of
   use cases related to network resiliency on Segment Routing (SPRING)
   networks.

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 March 23, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Filsfils, et al.         Expires March 23, 2017                 [Page 1]
Internet-Draft         SPRING Resiliency use-cases        September 2016

   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.  Path Protection . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Management-free Local Protection  . . . . . . . . . . . . . .   5
     3.1.  Management-free Bypass Protection . . . . . . . . . . . .   5
     3.2.  Management-free Shortest Path Based Protection  . . . . .   6
   4.  Managed Local Protection  . . . . . . . . . . . . . . . . . .   6
     4.1.  Managed Bypass Protection . . . . . . . . . . . . . . . .   7
     4.2.  Managed Shortest Path Protection  . . . . . . . . . . . .   7
   5.  Loop Avoidance  . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Co-existence of multiple resilience techniques in the same
       infrastructure  . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Manageability Considerations  . . . . . . . . . . . . . . . .   9
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     12.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   SPRING aims at providing a network architecture supporting services
   with tight SLA guarantees [I-D.ietf-spring-segment-routing].  This
   document reviews various use cases for the protection of services in
   a SPRING network.  Note that these use cases are in particular
   applicable to existing LDP based and pure IP networks.

   Three key alternatives are described: path protection, local
   protection without operator management and local protection with
   operator management.

   Path protection lets the ingress node be in charge of the failure
   recovery, as discussed in Section 2.

Filsfils, et al.         Expires March 23, 2017                 [Page 2]
Internet-Draft         SPRING Resiliency use-cases        September 2016

   The rest of the document focuses on approaches where protection is
   performed by the node adjacent to the failed component, commonly
   referred to as local protection techniques or Fast Reroute
   techniques.

   In Section 3 we discuss two different approaches providing unmanaged
   local protection, namely link/node bypass protection and shortest
   path based protection.

   Section 4 illustrates a case allowing the operator to manage the
   local protection behavior in order to accommodate specific policies.

   In Section 5 we discuss the opportunity for the SPRING architecture
   to provide loop-avoidance mechanisms, such that transient forwarding
   state inconsistencies during routing convergence do not lead into
   traffic loss.

   The purpose of this document is to illustrate the different
   approaches and explain how an operator could combine them in the same
   network (see Section 6).  Solutions are not defined in this document.

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

                       Figure 1: Reference topology

   We use Figure 1 as a reference topology throughout the document.
   Following link metrics are applied:

      Link metrics are bidirectional.  In other words, the same metric
      value is configured at both side of each link.

      Links from/to A and Z are configured with a metric of 100.

      CH, GD, DI and HE links are configured with a metric of 6.

      All other links are configured with a metric of 5.

2.  Path Protection

   A first protection strategy consists in excluding any local repair
   but instead use end-to-end path protection where each SPRING path is

Filsfils, et al.         Expires March 23, 2017                 [Page 3]
Internet-Draft         SPRING Resiliency use-cases        September 2016

   protected by a second disjoint SPRING path.  In this case local
   protection MUST NOT be used.

   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 (primary) and T2 (backup) 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} as the primary path
   and T2 is established over path {AF, FG, GH, HI, IZ} as the backup
   path.  As a requirement, the two paths MUST be disjoint in their
   links, nodes or shared risk link groups (SRLGs).

   When the primary path T1 is up, the packets of the PW are sent on T1.
   When T1 fails, the packets of the PW are sent on backup path 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.

   It is essential that the primary and backup path benefit from an end-
   to-end liveness monitoring/verification.  The method and mechanisms
   that provide such liveness check are outside the scope of this
   document.

   There are multiple options for liveness check, e.g., path liveness
   where the path is monitored at the network level (either by the head-
   end node or by a network controller/monitoring system).  Another
   possible approach consists of a service-based path monitored by the
   service instance (verifying reachability of the endpoint).  All these
   options are given here as examples.  While this document does express
   the requirement for a liveness mechanism, it does not mandate, nor
   define, any specific one.

   From a SPRING viewpoint, we would like to highlight the following
   requirements:

   o  Primary and backup paths (T1 and T2 in the example) MUST NOT
      benefit from local protection.

   o  The SPRING architecture MUST provide end-to-end liveness check of
      SPRING based paths.

   o  SPRING architecture MUST provide a way to compute paths that MUST
      NOT be protected by local repair techniques.

Filsfils, et al.         Expires March 23, 2017                 [Page 4]
Internet-Draft         SPRING Resiliency use-cases        September 2016

3.  Management-free Local Protection

   This section describes two alternatives providing 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-50 milliseconds.

   The backup path computation SHOULD support the following
   requirements:

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

   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 fail-over along the
   shortest path around the failed component.

   In case of link protection, the point of local repair will create a
   bypass avoiding the protected link and merging back to primary path
   at the nexthop.

   In case of node protection, the bypass will avoid the protected node
   and merge back to primary path at the next-nexthop.

   In our example, C protects destination Z against a failure of CD link
   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 CD,
   is depicted in Figure 2.

Filsfils, et al.         Expires March 23, 2017                 [Page 5]
Internet-Draft         SPRING Resiliency use-cases        September 2016

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

                Figure 2: Bypass protection around link CD

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
   the shortest path to the 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 CD, is depicted
   in Figure 3.

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

             Figure 3: Shortest path protection around link CD

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 not want to have CD and CH 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.

Filsfils, et al.         Expires March 23, 2017                 [Page 6]
Internet-Draft         SPRING Resiliency use-cases        September 2016

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

   The computation of the repair path SHOULD be possible in an automated
   fashion as well as statically expressed in the point of local repair.

4.2.  Managed Shortest Path Protection

   In the case of shortest path protection, the operator does not want
   to use the shortest failover via link CH, but rather reach H via {CG,
   GH}, for example, due to metric, BW, SRLG or other constraint.

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

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

                Figure 5: Managed Shortest Path Protection

   The computation of the repair path SHOULD be possible in an automated
   fashion as well as statically expressed in the point of local repair.

5.  Loop Avoidance

   It is part of routing protocols behavior to have what called
   "transient routing inconsistencies".  This is due to the routing
   convergence that happens in each node at different times and during a
   different lapse of time.

Filsfils, et al.         Expires March 23, 2017                 [Page 7]
Internet-Draft         SPRING Resiliency use-cases        September 2016

   These inconsistencies may cause routing loops that last the time that
   it takes for the node impacted by a network event to converge.  These
   loops are called "microloops".

   Usually, in a normal routing protocol operations, microloops do not
   last long enough and in general they are noticed during the time it
   takes for the network to converge.  However, with the emerging of
   fast-convergence and fast-reroute technologies, microloops may be an
   issue in networks where sub-50 millisecond convergence/reroute is
   required.  Therefore, the microloop problem needs to be addressed.

   A set of technologies preventing and addressing microloops have been
   proposed (e.g.: [I-D.ietf-rtgwg-uloop-delay]).

   Networks may be affected by microloops during convergence depending
   of their topologies.  Detecting microloops can be done during
   topology computation (e.g.: SPF computation) and therefore
   microloops-avoidance tecnhiques may be applied.  An example of such
   technique is to compute microloop-free path that would be used during
   network convergence.

   The SPRING architecture SHOULD provide solutions to prevent the
   occurrence of microloops 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 of multiple resilience techniques in the same
    infrastructure

   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, CD, E}

   o  Flow F2 is supported over path {C, CD, I}

   o  Flow F3 is supported over path {C, CD, Z}

   o  Flow F4 is supported over path {C, CD, Z}

   It should be possible for the operator to configure the network to
   achieve path protection for F1, management free shortest path local

Filsfils, et al.         Expires March 23, 2017                 [Page 8]
Internet-Draft         SPRING Resiliency use-cases        September 2016

   protection for F2, managed protection over path {CG, GH, Z} for F3,
   and management free bypass protection for F4.

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 and defined in [RFC7855]
   and [I-D.ietf-spring-segment-routing].

8.  IANA Considerations

   This document does not request any IANA allocations.

9.  Manageability Considerations

   This document provides use cases.  Solutions aimed at supporting
   these use cases should provide the necessary mechanisms in order to
   allow for manageability as described in [RFC7855] and
   [I-D.ietf-spring-segment-routing].

   Manageability concerns the computation, installation and
   troubleshooting of the repair path.  Also, necessary mechanisms
   SHOULD be provided in order for the operator to control when a repair
   path is computed, installed and used.

10.  Contributors

   TBD.

11.  Acknowledgements

   TBD.

12.  References

12.1.  Normative References

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

Filsfils, et al.         Expires March 23, 2017                 [Page 9]
Internet-Draft         SPRING Resiliency use-cases        September 2016

   [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
              Litkowski, S., Horneffer, M., and R. Shakir, "Source
              Packet Routing in Networking (SPRING) Problem Statement
              and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
              2016, <http://www.rfc-editor.org/info/rfc7855>.

12.2.  Informative References

   [I-D.ietf-rtgwg-uloop-delay]
              Litkowski, S., Decraene, B., Filsfils, C., and P.
              Francois, "Microloop prevention by introducing a local
              convergence delay", draft-ietf-rtgwg-uloop-delay-02 (work
              in progress), June 2016.

   [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-09 (work in progress), July 2016.

Authors' Addresses

   Clarence Filsfils (editor)
   Cisco Systems, Inc.
   Brussels
   BE

   Email: cfilsfil@cisco.com

   Stefano Previdi (editor)
   Cisco Systems, Inc.
   Via Del Serafico, 200
   Rome  00142
   Italy

   Email: sprevidi@cisco.com

   Pierre Francois
   Cisco Systems, Inc.
   Vimercate
   Italy

   Email: pifranco@cisco.com

Filsfils, et al.         Expires March 23, 2017                [Page 10]
Internet-Draft         SPRING Resiliency use-cases        September 2016

   Bruno Decraene
   Orange
   FR

   Email: bruno.decraene@orange.com

   Rob Shakir
   Jive Communications, Inc.
   1275 West 1600 North, Suite 100
   Orem, UT  84057

   Email: rjs@rob.sh

Filsfils, et al.         Expires March 23, 2017                [Page 11]