SPRING Problem Statement and Requirements
draft-previdi-spring-problem-statement-00

Network Working Group                                    S. Previdi, Ed.
Internet-Draft                                          C. Filsfils, Ed.
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: August 17, 2014                                     B. Decraene
                                                            S. Litkowski
                                                                  Orange
                                                            M. Horneffer
                                                                 R. Geib
                                                        Deutsche Telekom
                                                       February 13, 2014

               SPRING Problem Statement and Requirements
               draft-previdi-spring-problem-statement-00

Abstract

   The ability for a node to specify a forwarding path, other than the
   normal shortest path, that a particular packet will traverse,
   benefits a number of network functions.  Source-based routing
   mechanisms have previously been specified for network protocols, but
   have not seen widespread adoption.  In this context, the term
   'source' means 'the point at which the explicit route is imposed'.

   This document outlines various use cases, with their requirements,
   that need to be taken into account by the Source Packet Routing in
   Networking (SPRING) architecture.

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

Previdi, et al.          Expires August 17, 2014                [Page 1]
Internet-Draft          SPRING Problem Statement           February 2014

   This Internet-Draft will expire on August 17, 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
   (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.

Previdi, et al.          Expires August 17, 2014                [Page 2]
Internet-Draft          SPRING Problem Statement           February 2014

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Dataplanes  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  IGP-based MPLS Tunneling  . . . . . . . . . . . . . . . . . . . 4
   4.  Fast Reroute  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Interoperability with non-SPRING nodes  . . . . . . . . . . . . 6
   7.  OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   10. Manageability Considerations  . . . . . . . . . . . . . . . . . 7
   11. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     13.1.  Normative References . . . . . . . . . . . . . . . . . . . 8
     13.2.  Informative References . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Previdi, et al.          Expires August 17, 2014                [Page 3]
Internet-Draft          SPRING Problem Statement           February 2014

1.  Introduction

   The ability for a node to specify a forwarding path, other than the
   normal shortest path, that a particular packet will traverse,
   benefits a number of network functions, for example:

      Some types of network virtualization, including multi-topology
      networks and the partitioning of network resources for VPNs

      Network, link, path and node protection such as fast re-route

      Network programmability

      OAM techniques

      Simplification and reduction of network signaling components

      Load balancing and traffic engineering

   The term 'source' means 'the point at which the explicit route is
   imposed'.

   In this context, Source Packet Routing in Networking (SPRING)
   architecture is being defined so as to address the use cases and
   requirements described in this document.

2.  Dataplanes

   The SPRING architecture should be general in order to ease its
   applicability to different dataplanes.

   MPLS dataplane doesn't require any modification in order to apply a
   source-based routed model (e.g.:
   [I-D.filsfils-spring-segment-routing-mpls]).

   IPv6 specification [RFC2460] defines the Routing Extension Header
   which provides IPv6 source-based routing capabilities.

   The SPRING architecture should leverage existing MPLS dataplane
   without any modification and leverage IPv6 dataplane with minor
   modifications.

3.  IGP-based MPLS Tunneling

   The source-based routing model, applied to the MPLS dataplane, offers
   the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE

Previdi, et al.          Expires August 17, 2014                [Page 4]
Internet-Draft          SPRING Problem Statement           February 2014

   to an egress PE, without any other protocol than IGPs (ISIS or OSPF).
   LDP and RSVP-TE signaling protocols are not required.

   The SPRING architecture should allow PE to PE forwarding according to
   the IGP shortest path without the addition of any other signaling
   protocol.  The packet each PE forwards across the network will
   contain (within their label stack) the necessary information derived
   from the topology database in order to deliver the packet to the
   remote PE.

4.  Fast Reroute

   FRR technologies have been deployed by network operators in order to
   cope with link or node failures through pre-computation of backup
   paths.

   The SPRING architecture should address following requirements:

   o  support of FRR on any topology

   o  pre-computation and setup of backup path without any additional
      signaling (other than the regular IGP/BGP protocols)

   o  support of shared risk constraints

   o  support of node and link protection

   o  support of microloop avoidance

   Further illustrations of the problem statement for FRR are to be
   found in [I-D.francois-sr-resiliency-use-case].

5.  Traffic Engineering

   Traffic Engineering has been widely addressed using IGP protocol
   extensions (for resources information propagation) and RSVP-TE for
   signaling explicit paths.  Different contexts and modes have been
   defined (single vs. multiple domains, with or without bandwidth
   admission control, centralized vs. distributed path computation,
   etc).

   In all cases, one of the major components of the TE architecture is
   the signaling protocol (RSVP-TE) which is used in order to signal and
   establish the explicit path.  Each path, once computed, need to be
   signaled and state for each path must be present in each node
   traversed by the path.  This incurs a scalability problem especially

Previdi, et al.          Expires August 17, 2014                [Page 5]
Internet-Draft          SPRING Problem Statement           February 2014

   in the context of SDN where traffic differentiation may be done at a
   finer granularity (e.g.: application specific).  Also the amount of
   state needed to be carried in all involved nodes contributes
   significantly to complexity and the number of failures cases, and
   thus increases operational effort while decreasing overall network
   reliability.

   The source-based routing model allows traffic engineering to be
   implemented without the need of a signaling component.

   The SPRING architecture should support traffic engineering,
   including:

   o  loose or strict options

   o  bandwidth admission control

   o  distributed vs. centralized model (PCE, SDN Controller)

   o  disjointness in dual-plane networks

   o  egress peering traffic engineering

   o  load-balancing among non-parallel links

   o  Limiting (scalable, preferably zero) per-service state and
      signaling on midpoint and tail-end routers.

   o  ECMP-awareness

   o  node resiliency property (i.e.: the traffic-engineering policy is
      not anchored to a specific core node whose failure could impact
      the service.

6.  Interoperability with non-SPRING nodes

   SPRING must inter-operate with non-SPRING nodes.

   An illustration of interoperability between SPRING and other MPLS
   Signalling Protocols (LDP) is described here in
   [I-D.filsfils-spring-segment-routing-ldp-interop].

   Interoperability with IPv6 non-SPRING nodes will be described in a
   future document.

Previdi, et al.          Expires August 17, 2014                [Page 6]
Internet-Draft          SPRING Problem Statement           February 2014

7.  OAM

   The SPRING WG should provide OAM and the management needed to manage
   SPRING enabled networks.  The SPRING procedures may also be used as a
   tool for OAM in SPRING enabled networks.

   OAM problem statement and requirements will be described in a
   separate document..

   Interoperability with IPv6 non-SPRING nodes will be described in a
   future document.

8.  Security

   There is an assumed trust model such that any node imposing an
   explicit route on a packet is assumed to be allowed to do so.  In
   such context trust boundaries should strip explicit routes from a
   packet.

   For each data plane technology that SPRING specifies, a security
   analysis must be provided showing how protection is provided against
   an attacker disrupting the network by for example, maliciously
   injecting SPRING packets.

9.  IANA Considerations

   TBD

10.  Manageability Considerations

   TBD

11.  Security Considerations

   TBD

12.  Acknowledgements

   TBD

13.  References

Previdi, et al.          Expires August 17, 2014                [Page 7]
Internet-Draft          SPRING Problem Statement           February 2014

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

13.2.  Informative References

   [I-D.filsfils-spring-segment-routing-ldp-interop]
              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 interoperability with LDP",
              draft-filsfils-spring-segment-routing-ldp-interop-00 (work
              in progress), October 2013.

   [I-D.filsfils-spring-segment-routing-mpls]
              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 with MPLS data plane",
              draft-filsfils-spring-segment-routing-mpls-00 (work in
              progress), October 2013.

   [I-D.francois-sr-resiliency-use-case]
              Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
              "Use-cases for Resiliency in Segment Routing",
              draft-francois-sr-resiliency-use-case-00 (work in
              progress), January 2014.

Authors' Addresses

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

   Email: sprevidi@cisco.com

Previdi, et al.          Expires August 17, 2014                [Page 8]
Internet-Draft          SPRING Problem Statement           February 2014

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

   Email: cfilsfil@cisco.com

   Bruno Decraene
   Orange
   FR

   Email: bruno.decraene@orange.com

   Stephane Litkowski
   Orange
   FR

   Email: stephane.litkowski@orange.com

   Martin Horneffer
   Deutsche Telekom
   Hammer Str. 216-226
   Muenster  48153
   DE

   Email: Martin.Horneffer@telekom.de

   Ruediger Geib
   Deutsche Telekom
   Heinrich Hertz Str. 3-7
   Darmstadt  64295
   DE

   Email: Ruediger.Geib@telekom.de

Previdi, et al.          Expires August 17, 2014                [Page 9]