Network Working Group                                    Pierre Francois
Internet-Draft                                            IMDEA Networks
Intended status: Standards Track                       Clarence Filsfils
Expires: October 3, 2014                             Cisco Systems, Inc.
                                                          Bruno Decraene
                                                              Rob Shakir
                                                           April 1, 2014

                   Use-cases for Resiliency in SPRING


   This document describes the use cases for resiliency in SPRING

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

   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 October 3, 2014.

Copyright Notice

   Copyright (c) 2014 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
   ( 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

Pierre Francois, et al.  Expires October 3, 2014                [Page 1]

Internet-Draft         SPRING Resiliency use-cases            April 2014

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Path protection . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Management-free local protection  . . . . . . . . . . . . . . . 4
   4.  Managed local protection  . . . . . . . . . . . . . . . . . . . 4
   5.  Co-existence  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5

Pierre Francois, et al.  Expires October 3, 2014                [Page 2]

Internet-Draft         SPRING Resiliency use-cases            April 2014

1.  Introduction

   SPRING aims at providing a network architecture supporting services
   with tight SLA guarantees [1].  This document reviews various use
   cases for Fast Reroute (FRR) of services in a SPRING network.  Note
   that these use cases are in particular applicable to existing LDP
   based and pure IP networks.

   A FRR technique involves the pre-computation and dataplane pre-
   installation of backup paths so as to repair traffic in 50msec upon
   failure detection.  The term "protection" is often used as a synonym
   for FRR.  Such techniques suppose the existence of a sub-10msec
   failure detection mechanism.

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

   The purpose of this document is to illustrate the different
   techniques and explain how an operator could combine them in the same
   network.  Solutions are not defined in this document.

                             /  \
                            /    \
                          /|      | \  / | \  / |\
                         / |      |  \/  |  \/  | \
                        A  |      |  /\  |  /\  |  Z
                         \ |      | /  \ | /  \ | /
                          \|      |/    \|/    \|/

                       Figure 1: Reference topology

   We use Figure 1 as a reference topology throughout the document.  We
   describe the various use-cases in the next sections.  All link
   metrics are equal to 1, with the exception of the links of PE1 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

Pierre Francois, et al.  Expires October 3, 2014                [Page 3]

Internet-Draft         SPRING Resiliency use-cases            April 2014

   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

   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

   An alternative protection strategy consists in management-free local

   For example, a PW from C to E, transported over the shortest path to
   E provided by the SPRING architecture, benefits from management-free
   local protection by having each node along the path (e.g.  C and D)
   automatically pre-compute and pre-install a backup path for the
   destination E. 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

   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.

4.  Managed local protection

   There may be cases where a management free repair does not fit the
   policy of the operator.  For example, the operator may want the
   backup path to end at the next-hop (or next-next-hop for node
   failure) hence excluding IPFRR/LFA types of backup path.  Also, the
   operator might want to tightly control the backup path to the next-
   hop: for the destination Z upon the failure of link CD, the backup

Pierre Francois, et al.  Expires October 3, 2014                [Page 4]

Internet-Draft         SPRING Resiliency use-cases            April 2014

   path CGHD might be desired while the backup paths CGD and CHD are

   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.

5.  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  It should be possible for the operator to configure the network to
      achieve path protection for F1, management free local protection
      for F2, and managed protection over path {C-H, H-D, Z} for F3.

6.  References

   [1]  Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
        Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti,
        S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment
        Routing Architecture", draft-filsfils-rtgwg-segment-routing-01
        (work in progress), October 2013.

Authors' Addresses

   Pierre Francois
   IMDEA Networks


Pierre Francois, et al.  Expires October 3, 2014                [Page 5]

Internet-Draft         SPRING Resiliency use-cases            April 2014

   Clarence Filsfils
   Cisco Systems, Inc.


   Bruno Decraene


   Rob Shakir


Pierre Francois, et al.  Expires October 3, 2014                [Page 6]