Network Working Group
Internet Engineering Task Force (IETF)                   S. Previdi, Ed.
Internet-Draft
Request for Comments: 7855                              C. Filsfils, Ed.
Intended status:
Category: Informational                              Cisco Systems, Inc.
Expires: October 8, 2016
ISSN: 2070-1721                                              B. Decraene
                                                            S. Litkowski
                                                                  Orange
                                                            M. Horneffer
                                                        Deutsche Telekom
                                                               R. Shakir
                                               Jive Communications
                                                           April 6, Communications, Inc.
                                                                May 2016

               SPRING

              Source Packet Routing in Networking (SPRING)
                   Problem Statement and Requirements
                 draft-ietf-spring-problem-statement-08

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, protocols but
   have not seen widespread adoption.  In this context, the term
   'source'
   "source" means 'the "the point at which the explicit route is imposed' and
   therefore imposed";
   therefore, it is not limited to the originator of the packet (i.e.: (i.e.,
   the node imposing the explicit route may be the ingress node of an
   operator's network).

   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 for unicast traffic.  Multicast use- use
   cases and requirements are out of scope of for this document.

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 document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 8, 2016.
   http://www.rfc-editor.org/info/rfc7855.

Copyright Notice

   Copyright (c) 2016 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   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Dataplanes  Data Planes . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  SPRING Use Cases  . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  IGP-based  IGP-Based MPLS Tunneling  . . . . . . . . . . . . . . . .   4
       3.1.1.  Example of IGP-based IGP-Based MPLS Tunnels . . . . . . . . . .   4   5
     3.2.  Fast Reroute (FRR)  . . . . . . . . . . . . . . . . . . .   5
     3.3.  Traffic Engineering . . . . . . . . . . . . . . . . . . .   5   6
       3.3.1.  Examples of Traffic Engineering Traffic-Engineering Use Cases . . . . . .   7
     3.4.  Interoperability with non-SPRING nodes Non-SPRING Nodes  . . . . . . . . .  13
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   5.  IANA  Manageability Considerations  . . . . . . . . . . . . . . . . . . . . .  15
   6.  Manageability Considerations  . .  References  . . . . . . . . . . . . . .  15
   7.  Contributors . . . . . . . . . . .  16
     6.1.  Normative References  . . . . . . . . . . . . .  15
   8.  Acknowledgements . . . . .  16
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . .
   Acknowledgements  . . . . . . . . . . . . . . .  16
     9.1.  Normative References . . . . . . . . .  18
   Contributors  . . . . . . . . .  16
     9.2.  Informative References . . . . . . . . . . . . . . . . .  16  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17  18

1.  Introduction

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

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

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

   o  Network programmability

   o  OAM techniques

   o  Simplification and reduction of network signaling components

   o  Load balancing and traffic engineering

   Source-based routing mechanisms have previously been specified for
   network protocols, but have not seen widespread adoption other than
   in MPLS traffic engineering.

   These network functions may require greater flexibility and per
   packet source imposed more
   source-imposed routing than can be achieved through the use of the
   previously defined methods.  In the context of this document, the
   term 'source' "source" means 'the "the point at which the explicit route is
   imposed' and therefore
   imposed"; therefore, it is not limited to the originator of the
   packet (i.e.: (i.e., the node imposing the explicit route may be the ingress
   node of an operator's network).  Throughout this document document, we refer
   to this definition of 'source'. "source".

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

   The SPRING architecture MUST allow incremental and selective
   deployment without any requirement of a flag day or massive upgrade
   of all network elements.

   The SPRING architecture MUST allow to put putting the policy state in the
   packet header and not in the intermediate nodes along the path.
   Hence, the policy is instantiated in the packet header and does not
   requires any policy state in midpoints and tail-ends.

   The SPRING architecture objective is not to replace existing source source-
   routing and traffic engineering mechanisms traffic-engineering mechanisms, but rather to complement
   them and address use cases where removal of signaling and path state
   in the core is a requirement.

   Multicast use-cases and use cases and requirements are out of scope of for this
   document.

1.1.  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].

2.  Dataplanes  Data Planes

   The SPRING architecture SHOULD be general in order to ease its
   applicability to different dataplanes. data planes.

   The SPRING architecture SHOULD leverage the existing MPLS dataplane data plane
   without any modification and leverage the IPv6 dataplane data plane with a new
   IPv6 Routing Header Type (IPv6 Routing Header is defined in
   [RFC2460]) and a proposal for a new type of routing header is made by
   [I-D.ietf-6man-segment-routing-header].
   [SRH].

   The SPRING architecture MUST allow interoperability between SPRING SPRING-
   capable and non-capable non-SPRING-capable nodes and this in both the MPLS and IPv6
   dataplanes. data
   planes.

3.  SPRING Use Cases

3.1.  IGP-based  IGP-Based MPLS Tunneling

   The source-based routing model, applied to the MPLS dataplane, data plane,
   offers the ability to tunnel services like VPN ([RFC4364]), VPLS Virtual
   Private LAN Service (VPLS) ([RFC4761], [RFC4762]) and VPWS Virtual Private
   Wire Service (VPWS) ([RFC6624]), from an ingress PE Provider Edge (PE)
   to an egress PE, with or without the expression of an explicit path
   and without requiring forwarding plane forwarding-plane or control plane control-plane state in
   intermediate nodes.  Point-to-multipoint and multipoint-to-multipoint
   tunnels are outside of the scope of this document.

3.1.1.  Example of IGP-based IGP-Based MPLS Tunnels

   This section illustrates an example use-case. use case.

                                  P1---P2
                                 /       \
                    A---CE1---PE1         PE2---CE2---Z
                                 \       /
                                  P3---P4

                    Figure 1: IGP-based IGP-Based MPLS Tunneling

   In Figure 1 above, the four nodes A, CE1, CE2 CE2, and Z are part of the
   same VPN.  CE2 advertises to PE2 a route to Z.  PE2 binds a local
   label LZ to that route and propagates the route and its label via
   MPBGP the
   Multiprotocol Border Gateway Protocol (MPBGP) to PE1 with nhop next-hop
   address 192.0.2.2 (i.e.: (i.e., the local address of PE2).  PE1 installs the
   VPN prefix Z in the appropriate VRF VPN Routing and Forwarding table
   (VRF) and resolves the
   next-hop next hop onto the IGP-based MPLS tunnel to
   PE2.

   In order to

   To cope with the reality of current deployments, the SPRING
   architecture MUST allow PE to PE 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 the
   necessary information derived from the topology database in order to
   deliver the packet to the remote PE.

3.2.  Fast Reroute (FRR)

   FRR (Fast Reroute)

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

   Illustration of the problem statement for FRR and microloop micro-loop
   avoidance
   are to can be found in [I-D.ietf-spring-resiliency-use-cases]. [SPRING-RESIL].

   The SPRING architecture MUST address the following requirements:

   o  support of Fast Reroute (FRR) on any topology

   o  pre-computation  precomputation 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 micro-loop avoidance

3.3.  Traffic Engineering

   Traffic Engineering (TE) is the term used to refer to techniques that
   enable operators to control how specific traffic flows are treated
   within their networks.  Different contexts and modes have been
   defined (single vs. multiple domains, with or without bandwidth
   admission control, centralized vs. distributed path computation,
   etc).
   etc.).

   Some deployments have a limited use of TE TE, such as addressing
   specific application or customer requirements requirements, or address addressing specific
   bandwidth
   limitation limitations in the network (tactical TE).  In this situation, these
   situations, there is a need to reduce reduce, as much of possible as possible, the cost
   (such as the number of signaling protocols and the number of nodes
   requiring specific
   configurations/features. configurations/features).  Some other deployments
   have a very high
   scale high-scale use of TE, such as fine tuning flows at the
   application level.  In this situation, there is a need for a very high
   scalability, in particular on mid-points. midpoints.

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

   The SPRING architecture MUST support the following traffic traffic-
   engineering requirements:

   o  loose or strict options

   o  bandwidth admission control

   o  distributed vs. centralized model (PCE
      [I-D.ietf-pce-stateful-pce], SDN (e.g., Path Computation Element
      (PCE) [STATEFUL-PCE], Software-Defined Networking (SDN)
      Controller)

   o  disjointness in dual-plane networks

   o  egress peering traffic peer engineering

   o  load-balancing  load balancing among non-parallel links (i.e.: (i.e., links connected to
      different adjacent neighbors).

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

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

   In most cases, Traffic Engineering traffic engineering makes use of the "loose" route
   option where most of the explicit paths can be expressed through a
   small number of hops.  However, there are use cases where the
   "strict" option may be used and, in such case, cases, each individual hop
   in the explicit path is specified.  This may incur into result in a long list of
   hops that is instantiated into a MPLS label stack (in the MPLS
   dataplane) data
   plane) or list of IPv6 addresses (in the IPv6 dataplane). data plane).

   It is obvious that that, in the case of long long, strict source routing source-routed paths,
   the deployment is possible if the head-end of the explicit path
   supports the instantiation of long explicit paths.

   Alternatively, a controller could decompose the end-to-end path into
   a set of sub-paths such as each of these sub-paths is supported by
   its respective head-end and advertised with a single identifier.
   Hence, the concatenation (or stitching) of the sub-paths identifiers
   gives a compression scheme allowing an end-to-end path to be
   expressed in a smaller number of hops.

3.3.1.  Examples of Traffic Engineering Traffic-Engineering Use Cases

   Here follows the description

   Below are descriptions of two sets of use cases:

   o  Traffic Engineering without Admission Control

   o  Traffic Engineering with Admission Control

3.3.1.1.  Traffic Engineering without Bandwidth Admission Control

   In this section, we describe Traffic Engineering use-cases use cases without
   bandwidth admission control.

3.3.1.1.1.  Disjointness in dual-plane networks Dual-Plane Networks

   Many networks are built according to the dual-plane design, as
   illustrated in Figure 2:

      Each aggregation region k is connected to the core by two C
      routers C1k and C2k C2k, where k refers to the region.

      C1k is part of plane 1 and aggregation region k

      C2k is part of plane 2 and aggregation region k
      C1k has a link to C2j iff k = j.

         The core nodes of a given region are directly connected.
         Inter-region links only connect core nodes of the same plane.

      {C1k has a link to C1j} iff {C2k has a link to C2j}.

         The distribution of these links depends on the topological
         properties of the core of the AS. Autonomous System (AS).  The
         design rule presented above specifies that these links appear
         in both core planes.

   We assume a common design rule found in such deployments: the The inter-
   plane link costs (Cik-Cjk (Cik - Cjk, where i != j) are set such that the
   route to an edge destination from a given plane stays within the
   plane unless the plane is partitioned.

                             Edge Router A
                                 /  \
                                /    \
                               /      \  Agg Region A
                              /        \
                             /          \
                            C1A----------C2A
                            | \         | \
                            |  \        |  \
                            |   C1B----------C2B
                  Plane1    |    |      |    |     Plane2
                            |    |      |    |
                            C1C--|-----C2C   |
                              \  |        \  |
                               \ |         \ |
                               C1Z----------C2Z
                                  \        /
                                   \      /  Agg Region Z
                                    \    /
                                     \  /
                                 Edge Router Z

               Figure 2: Dual-Plane Network and Disjointness

   In this scenario, the operator requires the ability to deploy
   different strategies.  For example, Edge Router A should be able to
   use the three following options:

   o  the  The traffic is load-balanced across any ECMP path through the
      network
      network.

   o  the  The traffic is load-balanced across any ECMP path within the Plane1 of
      the network network.

   o  the  The traffic is load-balanced across any ECMP path within the Plane2 of
      the network network.

   Most of the data traffic from A to Z would use the first option, such so
   as to exploit the capacity efficiently.  The operator would use the
   two other choices for specific premium traffic that has requested
   disjoint transport.

   The SPRING architecture MUST support this use case with the following
   requirements:

   o  Zero per-service state and signaling on midpoint and tail-end
      routers.

   o  ECMP-awareness.

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

3.3.1.1.2.  Egress Peering Traffic Engineering

                                     +------+
                                     |      |
                                 +---D      F
                    +---------+ /    | AS 2  AS2 |\ +------+
                    |         |/     +------+ \|   Z  |
                    A         C                |      |
                    |         |\     +------+ /| AS 4  AS4 |
                    B   AS1   | \    |      |/ +------+
                    |         |  +---E      G
                    +---------+      | AS 3  AS3 |
                                     +------+\

               Figure 3: Egress peering traffic engineering Peering Traffic Engineering

   Let us assume, in the network depicted in Figure 3, that:

   o  C in AS1 learns about destination Z of AS 4 AS4 via two BGP paths (AS2,
      AS4) and (AS3, AS4).

   o  C may or may not be configured so to enforce the next-hop-self
      behavior before propagating the paths within AS1.

   o  C may propagate all the paths to Z within AS1 (BGP add-paths,
      [I-D.ietf-idr-add-paths]). (using BGP ADD-PATH
      as specified in [ADD-PATH]).

   o  C may install in its FIB Forwarding Information Base (FIB) only the
      route via AS2, or only the route via AS3, or both.

   In that context, the SPRING architecture MUST allow the operator of
   AS1 to apply a traffic-engineering policy such as the following one,
   regardless of the configured behavior of the next-hop-self:

   o  Steer 60% of the Z-destined traffic received at A via AS2 and 40%
      via AS3.

   o  Steer 80% of the Z-destined traffic received at B via AS2 and 20%
      via AS3.

   The SPRING architecture MUST allow an ingress node (i.e., an explicit
   route source node) to select the exit point of a packet as any
   combination of an egress node, an egress interface, a peering
   neighbor, and a peering AS.

   The use cases and requirements for Egress Peer Engineering egress peer engineering are
   described in [I-D.ietf-spring-segment-routing-central-epe]. [SR-BGP-EPE].

3.3.1.1.3.  Load-balancing  Load Balancing among non-parallel links Non-parallel Links

   The SPRING architecture MUST allow a given node to load share load-share traffic
   across multiple non parallel non-parallel links (i.e.: (i.e., links connected to
   different adjacent routers) routers), even if these lead to different
   neighbors.  This may be useful to support traffic engineering for supporting traffic-engineering
   policies.

                                 +---C---D---+
                                 |           |
                       PE1---A---B-----F-----E---PE2

               Figure 4: Multiple (non-parallel) (Non-parallel) Adjacencies

   In the above example, the operator requires PE1 to load-balance its
   PE2-destined traffic between the ABCDE and ABFE equal-cost paths in a
   controlled way where the operator MUST be allowed to distribute
   traffic unevenly between paths (Weighted Equal Cost Multiplath,
   WECMP). Equal-Cost Multipath
   (WECMP)).

3.3.1.2.  Traffic Engineering with Bandwidth Admission Control

   The implementation of bandwidth admission control within a network
   (and its possible routing consequence consequence, which consists in routing
   along explicit paths where the bandwidth is available) requires a capacity
   planning
   capacity-planning process.

   The spreading of load among ECMP paths is a key attribute of the
   capacity planning
   capacity-planning processes applied to packet-based networks.

3.3.1.2.1.  Capacity Planning  Capacity-Planning Process

   Capacity Planning planning anticipates the routing of the traffic matrix onto
   the network topology, topology for a set of expected traffic and topology
   variations.  The heart of the process consists in simulating the
   placement of the traffic along ECMP-aware shortest-paths shortest paths and
   accounting for the resulting bandwidth usage.

   The bandwidth accounting of a demand along its shortest-path shortest path is a
   basic capability of any planning tool or PCE server.

   For example, in the network topology described below, and assuming a
   default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps 1600 Mbps
   A-to-Z flow is accounted as consuming 1600Mbps 1600 Mbps on links AB and FZ,
   800Mbps FZ;
   800 Mbps on links BC, BG BG, and GF, GF; and 400Mbps 400 Mbps on links CD, DF, CE CE,
   and EF.

                                   C-----D
                                 /  \     \
                            A---B    +--E--F--Z
                                 \        /
                                  G------+

             Figure 5: Capacity Planning an ECMP-based demand ECMP-Based Demand

   ECMP is extremely frequent in SP, Enterprise Service Provider (SP), enterprise, and DC
   data-center architectures and it is not rare to see as much as 128
   different ECMP paths between a source and a destination within a
   single network domain.  It is a key efficiency objective to spread
   the traffic among as many ECMP paths as possible.

   This is illustrated in the below network diagram below, which consists of a
   subset of a network where already 5 ECMP paths are observed from A to
   M.

                                   C
                                  / \
                                 B-D-L--
                                / \ /   \
                               A   E     \
                                \         M
                                 \   G   /
                                  \ / \ /
                                   F   K
                                    \ /
                                     I

                      Figure 6: ECMP Topology Example

   When the capacity planning capacity-planning process detects that a traffic growth
   scenario and topology variation would lead to congestion, a capacity
   increase is triggered triggered, and if it cannot be deployed in due time, a
   traffic engineering
   traffic-engineering solution is activated within the network.

   A basic traffic engineering traffic-engineering objective consists of finding the
   smallest set of demands that need to be routed off their shortest
   path to eliminate the congestion, and then to compute an explicit
   path for each of them and instantiating instantiate these traffic-engineered
   policies in the network.

   The SPRING architecture MUST offer a simple support for ECMP-based
   shortest path
   shortest-path placement as well as for explicit path policy without
   incurring additional signaling in the domain.  This includes:

   o  the ability to steer a packet across a set of ECMP paths

   o  the ability to diverge from a set of ECMP shortest paths to one or
      more paths not in the set of shortest paths

3.3.1.2.2.  SDN Use Case

   The SDN use-case use case lies in the SDN controller, (e.g.: (e.g., Stateful PCE as
   described in [I-D.ietf-pce-stateful-pce]. [STATEFUL-PCE]).

   The SDN controller is responsible to control for controlling the evolution of
   the traffic matrix and topology.  It accepts or denies the addition
   of new traffic into the network.  It decides how to route the
   accepted traffic.  It monitors the topology and and, upon topological
   change, determines the minimum traffic that should be rerouted on an
   alternate path to alleviate a bandwidth congestion issue.

   The algorithms supporting this behavior are a local matter of the SDN
   controller and are outside the scope of this document.

   The means of collecting traffic and topology information are the same
   as what would be used with other SDN-based traffic-engineering
   solutions.

   The means of instantiating policy information at a traffic-
   engineering head-end are the same as what would be used with other
   SDN-based traffic-engineering solutions.

   In the context of Centralized-Based Optimization centralized optimization and the SDN use- use case, here are the functionalities that the
   SPRING architecture MUST
   deliver: have the following attributes:

   o  Explicit routing capability with or without ECMP-awareness.

   o  No signaling hop-by-hop through the network.

      Policy

   o  The policy state is only maintained at the policy head-end.  No
      policy state is maintained at mid-points midpoints and tail-ends.

   o  Automated guaranteed FRR for any topology.

   o  The policy state is in the packet header and not in the
      intermediate nodes along the path.  The policy is absent from
      midpoints and tail-ends.

   o  Highly responsive to change: the The SDN Controller only needs to
      apply a policy change at the head-end.  No delay is introduced due
      to programming the midpoints and tail-end along the path.

3.4.  Interoperability with non-SPRING nodes Non-SPRING Nodes

   SPRING nodes MUST inter-operate interoperate with non-SPRING nodes and in both MPLS
   and IPv6 dataplanes data planes in order to allow a gradual deployment of SPRING
   on existing MPLS and IPv6 networks.

4.  Security Considerations

   SPRING reuses the concept of source routing by encoding the path in
   the packet.  As with other similar source routing source-routing architecture, an
   attacker may manipulate the traffic path by modifying the packet
   header.  By manipulating the traffic path, an attacker may be able to
   cause outages on any part of the network.

   SPRING adds some meta-data metadata on the packet, with the list of forwarding
   path elements that the packet must traverse.  Depending on the data
   plane, this list may shrink as the packet traverse traverses the network, by
   only
   keeping only the next elements and forgetting the past ones.

   SPRING architecture MUST provide clear trust domain boundaries, boundaries so
   that source routing source-routing information is only usable within the trusted
   domain and never exposed to the outside world.

   From a network protection standpoint, 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.  This is a significant change compared to
   plain IP offering shortest path routing the shortest-path routing, but not fundamentally
   different compared to existing techniques providing explicit routing
   capability.  It is expected that, by default, the explicit routing
   information is not leaked through the boundaries of the administered
   domain.

   Therefore, the dataplane data plane MUST NOT expose any source routing source-routing
   information when a packet leaves the trusted domain.  Special care
   will be required for the existing dataplanes data planes like MPLS, especially
   for the inter-provider scenario where a third-party provider may push
   MPLS labels corresponding to a SPRING header anywhere in the stack.
   The architecture document MUST analyze the exact security
   considerations of such a scenario.

   Filtering routing information is typically performed in the control
   plane, but an additional filtering in the forwarding plane is also
   required.  In SPRING, as there is no control plane (related to source
   routed
   source-routed paths) between the source and the mid points, midpoints, filtering
   in the control plane is not possible (or not required, depending on
   the point of view).  Filtering MUST be performed on the forwarding
   plane on the boundaries and MAY require looking at multiple labels/
   instruction. labels or
   instructions.

   For the MPLS data plane, this is not a new requirement as the
   existing MPLS architecture already allow allows such source routing by
   stacking multiple labels.  And for  For security protection, RFC4381 section Section 2.4 of
   [RFC4381] and RFC 5920 section Section 8.2 of [RFC5920] already calls call for the filtering
   of MPLS packets on trust boundaries.

   If all MPLS labels are filtered at domain boundaries, then SPRING
   does not introduce any change.  If only a subset of labels are
   filtered, then SPRING introduces a change since the border router is
   expected to determine which information (e.g.: (e.g., labels) are filtered is filtered,
   while the border router is not the originator of these label
   advertisements.

   As the SPRING architecture must be based on a clear trust domain,
   mechanisms allowing the authentication and validation of the source source-
   routing information must be evaluated by the SPRING architecture in
   order to prevent any form of attack or unwanted source routing source-routing
   information manipulation.

   Dataplane

   Data-plane security considerations MUST be addressed in each SPRING
   dataplane related document (i.e.:
   related to the SPRING data plane (i.e., MPLS and IPv6).

   The IPv6 data plane proposes the use of a cryptographic signature of
   the source routed path source-routed path, which would ease this configuration.  This is
   indeed more needed more for the IPv6 data plane plane, which is end to end in
   nature, compared to the MPLS data plane plane, which is typically
   restricted to a controlled and trusted zone.

   In the forwarding plane, data plane data-plane extension documents MUST address
   the security implications of the required change.

   In term terms of privacy, SPRING does not propose change in term terms of
   encryption.  Each dataplane, data plane may or may not provide existing or
   future encryption capability.

   In order to

   To build the source routing source-routing information in the packet, a node in the
   SPRING architecture will require learning information from a control
   layer.  As this control layer will be in charge of programming
   forwarding instructions, an attacker taking over this component may
   also manipulate the traffic path.  Any control protocol used in the
   SPRING architecture SHOULD provide security mechanisms or design to
   protect against such control layer a control-layer attacker.  Control plane  Control-plane
   security considerations MUST be addressed in each document related to
   the SPRING control
   plane related document. plane.

5.  IANA Considerations

   This document does not request any IANA allocations.

6.  Manageability Considerations

   The SPRING WG MUST define Operations Operations, Administration, and Management Maintenance
   (OAM) procedures applicable to SPRING enabled SPRING-enabled networks.

   In SPRING networks, the path the packet takes is encoded in the
   header.  SPRING architecture MUST include the necessary OAM
   mechanisms in order for the network operator to validate the
   effectiveness of a path as well as to check and monitor its liveness
   and performance.  Moreover, in SPRING architecture, a path may be
   defined in the forwarding layer (in both MPLS and IPv6 dataplanes) data planes)
   or as a service path (formed by a set of service instances).  The
   network operator MUST be capable to monitor, control control, and manage
   paths
   (network (both network and service based) using OAM procedures.

   OAM use cases and requirements are detailed in
   [I-D.ietf-spring-oam-usecase] [OAM-USE] and
   [I-D.ietf-spring-sr-oam-requirement].

7.  Contributors

   The following individuals substantially contributed to the content of
   this documents:

   Ruediger Geib
   Deutsche Telekom
   Heinrich Hertz Str. 3-7
   Darmstadt  64295
   DE
   Email: Ruediger.Geib@telekom.de

   Robert Raszuk
   Mirantis Inc.
   615 National Ave.
   94043 Mt View, CA
   US
   Email: robert@raszuk.net

8.  Acknowledgements

   The authors would like to thank Yakov Rekhter for his contribution to
   this document.

9.
   [SR-OAM].

6.  References

9.1.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <http://www.rfc-editor.org/info/rfc4364>.

   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <http://www.rfc-editor.org/info/rfc4761>.

   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
              <http://www.rfc-editor.org/info/rfc4762>.

   [RFC6624]  Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
              Virtual Private Networks Using BGP for Auto-Discovery and
              Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
              <http://www.rfc-editor.org/info/rfc6624>.

9.2.

6.2.  Informative References

   [I-D.ietf-6man-segment-routing-header]
              Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
              J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-
              header-01 (work in progress), March 2016.

   [I-D.ietf-idr-add-paths]

   [ADD-PATH]
              Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
              add-paths-13 (work in progress), December 2015.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-14 (work Work in progress), March
              Progress, draft-ietf-idr-add-paths-14, April 2016.

   [I-D.ietf-spring-oam-usecase]

   [OAM-USE]  Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
              Kumar, "Use
              Case for a "A Scalable and Topology-Aware Segment Routing MPLS Data Plane Dataplane
              Monitoring System", draft-ietf-spring-oam-
              usecase-01 (work Work in progress), October 2015.

   [I-D.ietf-spring-resiliency-use-cases] Progress, draft-ietf-spring-
              oam-usecase-03, April 2016.

   [RFC4381]  Behringer, M., "Analysis of the Security of BGP/MPLS IP
              Virtual Private Networks (VPNs)", RFC 4381,
              DOI 10.17487/RFC4381, February 2006,
              <http://www.rfc-editor.org/info/rfc4381>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <http://www.rfc-editor.org/info/rfc5920>.

   [SPRING-RESIL]
              Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
              "Use-cases for Resiliency in SPRING", draft-ietf-spring-
              resiliency-use-cases-03 (work Work in progress), Progress,
              draft-ietf-spring-resiliency-use-cases-03, April 2016.

   [I-D.ietf-spring-segment-routing-central-epe]

   [SR-BGP-EPE]
              Filsfils, C., Ed., Previdi, S., Ed., Ginsburg, D., and D.
              Afanasiev, "Segment Routing Centralized BGP Peer
              Engineering", draft-
              ietf-spring-segment-routing-central-epe-01 (work Work in
              progress), Progress, draft-ietf-spring-segment-
              routing-central-epe-01, March 2016.

   [I-D.ietf-spring-sr-oam-requirement]

   [SR-OAM]   Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
              and S. Litkowski, "OAM Requirements for Segment Routing
              Network", draft-ietf-spring-sr-oam-requirement-01 (work Work in
              progress), Progress, draft-ietf-spring-sr-oam-
              requirement-01, December 2015.

   [SRH]      Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
              J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
              Routing Header (SRH)", Work in Progress, draft-ietf-6man-
              segment-routing-header-01, March 2016.

   [STATEFUL-PCE]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", Work in Progress,
              draft-ietf-pce-stateful-pce-14, March 2016.

Acknowledgements

   The authors would like to thank Yakov Rekhter for his contribution to
   this document.

Contributors

   The following individuals substantially contributed to the content of
   this document:

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

   Email: Ruediger.Geib@telekom.de

   Robert Raszuk
   Mirantis Inc.
   615 National Ave.
   94043 Mountain View, CA
   United States

   Email: robert@raszuk.net

Authors' Addresses

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

   Email: sprevidi@cisco.com

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

   Email: cfilsfil@cisco.com
   Bruno Decraene
   Orange
   FR
   France

   Email: bruno.decraene@orange.com

   Stephane Litkowski
   Orange
   FR
   France

   Email: stephane.litkowski@orange.com

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

   Email: Martin.Horneffer@telekom.de

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

   Email: rjs@rob.sh