draft-ietf-spring-problem-statement-06.txt   draft-ietf-spring-problem-statement-07.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils, Ed. Internet-Draft C. Filsfils, Ed.
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: June 16, 2016 B. Decraene Expires: September 2, 2016 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
Jive Communications Jive Communications
December 14, 2015 March 1, 2016
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-ietf-spring-problem-statement-06 draft-ietf-spring-problem-statement-07
Abstract Abstract
The ability for a node to specify a forwarding path, other than the The ability for a node to specify a forwarding path, other than the
normal shortest path, that a particular packet will traverse, normal shortest path, that a particular packet will traverse,
benefits a number of network functions. Source-based routing benefits a number of network functions. Source-based routing
mechanisms have previously been specified for network protocols, but mechanisms have previously been specified for network protocols, but
have not seen widespread adoption. In this context, the term have not seen widespread adoption. In this context, the term
'source' means 'the point at which the explicit route is imposed' and 'source' means 'the point at which the explicit route is imposed' and
therefore it is not limited to the originator of the packet (i.e.: therefore it is not limited to the originator of the packet (i.e.:
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2016. This Internet-Draft will expire on September 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 36
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . 4 3.1. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . 4
3.1.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . 4 3.1.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . 4
3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5 3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5
3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5 3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5
3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 6 3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 7
3.4. Interoperability with non-SPRING nodes . . . . . . . . . 12 3.4. Interoperability with non-SPRING nodes . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Manageability Considerations . . . . . . . . . . . . . . . . 13 6. Manageability Considerations . . . . . . . . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The ability for a node to specify a unicast forwarding path, other The ability for a node to specify a unicast forwarding path, other
than the normal shortest path, that a particular packet will than the normal shortest path, that a particular packet will
traverse, benefits a number of network functions, for example: traverse, benefits a number of network functions, for example:
Some types of network virtualization, including multi-topology Some types of network virtualization, including multi-topology
networks and the partitioning of network resources for VPNs networks and the partitioning of network resources for VPNs
skipping to change at page 3, line 35 skipping to change at page 3, line 35
term 'source' means 'the point at which the explicit route is term 'source' means 'the point at which the explicit route is
imposed' and therefore it is not limited to the originator of the imposed' and therefore it is not limited to the originator of the
packet (i.e.: the node imposing the explicit route may be the ingress packet (i.e.: the node imposing the explicit route may be the ingress
node of an operator's network). Throughout this document we refer to node of an operator's network). Throughout this document we refer to
this definition of 'source'. this definition of 'source'.
In this context, Source Packet Routing in Networking (SPRING) In this context, Source Packet Routing in Networking (SPRING)
architecture is being defined in order to address the use cases and architecture is being defined in order to address the use cases and
requirements described in this document. requirements described in this document.
The SPRING architecture SHOULD allow incremental and selective The SPRING architecture MUST allow incremental and selective
deployment without any requirement of flag day or massive upgrade of deployment without any requirement of flag day or massive upgrade of
all network elements. all network elements.
The SPRING architecture SHOULD allow optimal virtualization: put The SPRING architecture MUST allow to put policy state in the packet
policy state in the packet header and not in the intermediate nodes header and not in the intermediate nodes along the path. Hence, the
along the path. Hence, the policy is completely virtualized away policy is instantiated in the packet header and does not requires any
from midpoints and tail-ends. policy state in midpoints and tail-ends.
The SPRING architecture objective is not to replace existing source The SPRING architecture objective is not to replace existing source
routing and traffic engineering mechanisms but rather complement them routing and traffic engineering mechanisms but rather complement them
and address use cases where removal of signaling and path state in and address use cases where removal of signaling and path state in
the core is a requirement. the core is a requirement.
Multicast use-cases and requirements are out of scope of this
document.
2. Dataplanes 2. Dataplanes
The SPRING architecture SHOULD be general in order to ease its The SPRING architecture SHOULD be general in order to ease its
applicability to different dataplanes. applicability to different dataplanes.
The SPRING architecture SHOULD leverage the existing MPLS dataplane The SPRING architecture SHOULD leverage the existing MPLS dataplane
without any modification and leverage IPv6 dataplane with a new IPv6 without any modification and leverage IPv6 dataplane with a new IPv6
Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). 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].
The SPRING architecture MUST allow interoperability between SPRING
capable and non-capable nodes and this in both MPLS and IPv6
dataplanes.
3. SPRING Use Cases 3. SPRING Use Cases
3.1. IGP-based MPLS Tunneling 3.1. IGP-based MPLS Tunneling
The source-based routing model, applied to the MPLS dataplane, offers The source-based routing model, applied to the MPLS dataplane, offers
the ability to tunnel services like VPN ([RFC4364]), VPLS ([RFC4761], the ability to tunnel services like VPN ([RFC4364]), VPLS ([RFC4761],
[RFC4762]) and VPWS ([RFC6624]), from an ingress PE to an egress PE, [RFC4762]) and VPWS ([RFC6624]), from an ingress PE to an egress PE,
with or without the expression of an explicit path and without with or without the expression of an explicit path and without
requiring forwarding plane or control plane state in intermediate requiring forwarding plane or control plane state in intermediate
nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are
outside of the scope of this document. outside of the scope of this document.
3.1.1. Example of IGP-based MPLS Tunnels 3.1.1. Example of IGP-based MPLS Tunnels
This section illustrates an example use-case. This section illustrates an example use-case.
P1---P2 P1---P2
/ \ / \
A---CE1---PE1 PE2---CE2---Z A---CE1---PE1 PE2---CE2---Z
\ / \ /
P3---P4 P3---P4
Figure 1: IGP-based MPLS Tunneling Figure 1: IGP-based MPLS Tunneling
In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the
same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local 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 label LZ to that route and propagates the route and its label via
MPBGP to PE1 with nhop 192.0.2.2 (i.e.: the local address of PE2). MPBGP to PE1 with nhop 192.0.2.2 (i.e.: the local address of PE2).
PE1 installs the VPN prefix Z in the appropriate VRF and resolves the PE1 installs the VPN prefix Z in the appropriate VRF and resolves the
next-hop onto the node segment associated with PE2. next-hop onto the IGP-based MPLS tunnel to PE2.
In order to cope with the reality of current deployments, the SPRING In order to cope with the reality of current deployments, the SPRING
architecture SHOULD allow PE to PE forwarding according to the IGP architecture MUST allow PE to PE forwarding according to the IGP
shortest path without the addition of any other signaling protocol. shortest path without the addition of any other signaling protocol.
The packet each PE forwards across the network will contain (within The packet each PE forwards across the network will contain the
their label stack) the necessary information derived from the necessary information derived from the topology database in order to
topology database in order to deliver the packet to the remote PE. deliver the packet to the remote PE.
3.2. Fast Reroute (FRR) 3.2. Fast Reroute (FRR)
FRR technologies have been deployed by network operators in order to FRR technologies have been deployed by network operators in order to
cope with link or node failures through pre-computation of backup cope with link or node failures through pre-computation of backup
paths. paths.
The SPRING architecture SHOULD address the following requirements: The SPRING architecture MUST address the following requirements:
o support of Fast Reroute (FRR) on any topology o support of Fast Reroute (FRR) on any topology
o pre-computation and setup of backup path without any additional o pre-computation and setup of backup path without any additional
signaling (other than the regular IGP/BGP protocols) signaling (other than the regular IGP/BGP protocols)
o support of shared risk constraints o support of shared risk constraints
o support of node and link protection o support of node and link protection
o support of microloop avoidance o support of microloop avoidance
Further illustrations of the problem statement for FRR are to be Further illustrations of the problem statement for FRR are to be
found in [I-D.ietf-spring-resiliency-use-cases]. found in [I-D.ietf-spring-resiliency-use-cases].
3.3. Traffic Engineering 3.3. Traffic Engineering
Traffic Engineering has been addressed using IGP protocol extensions Traffic Engineering (TE) is the term used to refer to techniques that
(for resources information propagation) and RSVP-TE for signaling enable operators to control how specific traffic flows are treated
explicit paths ([RFC5305], [RFC3630], [RFC3209]. Different contexts within their networks. Different contexts and modes have been
and modes have been defined (single vs. multiple domains, with or defined (single vs. multiple domains, with or without bandwidth
without bandwidth admission control, centralized vs. distributed path admission control, centralized vs. distributed path computation,
computation, etc). etc).
In all cases, one of the major components of the TE architecture is Some deployments have a limited use of TE such as addressing specific
the soft state based signaling protocol (RSVP-TE) which is used in application or customer requirements or address specific bandwidth
order to signal and establish the explicit path. Each path, once limitation in the network (tactical TE). In this situation, there is
computed, need to be signaled and state for each path must be present need to reduce as much of possible the cost (such as the number of
in each node traversed by the path. This incurs a scalability signaling protocols and the number of nodes requiring specific
problem especially in the context of SDN where traffic configurations/features. Some other deployments have a very high
differentiation may be done at a finer granularity (e.g.: application scale use of TE, such as fine tuning flows at the application level.
specific). Also the amount of state needed to be maintained and In this situation, there is a need for a very high scalability, in
periodically refreshed in all involved nodes contributes particular on mid-points.
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 The source-based routing model allows traffic engineering to be
implemented without the need of a signaling component. implemented without the need of a signaling component.
The SPRING architecture SHOULD support traffic engineering, The SPRING architecture MUST support the following traffic
including: engineering requirements:
o loose or strict options o loose or strict options
o bandwidth admission control o bandwidth admission control
o distributed vs. centralized model (PCE o distributed vs. centralized model (PCE
[I-D.ietf-pce-stateful-pce], SDN Controller) [I-D.ietf-pce-stateful-pce], SDN Controller)
o disjointness in dual-plane networks o disjointness in dual-plane networks
skipping to change at page 6, line 31 skipping to change at page 6, line 31
o Limiting (scalable, preferably zero) per-service state and o Limiting (scalable, preferably zero) per-service state and
signaling on midpoint and tail-end routers. signaling on midpoint and tail-end routers.
o ECMP-awareness o ECMP-awareness
o node resiliency property (i.e.: the traffic-engineering policy is o node resiliency property (i.e.: the traffic-engineering policy is
not anchored to a specific core node whose failure could impact not anchored to a specific core node whose failure could impact
the service. the service.
In most cases, 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, each individual hop in
the explicit path is specified. This may incur into a long list of
hops that is instantiated into a MPLS label stack (in the MPLS
dataplane) or list of IPv6 addresses (in the IPv6 dataplane).
It is obvious that in case of long strict source routing 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 Use Cases 3.3.1. Examples of Traffic Engineering Use Cases
Here follows the description of two sets of use cases: Here follows the description of two sets of use cases:
o Traffic Engineering without Admission Control o Traffic Engineering without Admission Control
o Traffic Engineering with Admission Control o Traffic Engineering with Admission Control
3.3.1.1. Traffic Engineering without Bandwidth Admission Control 3.3.1.1. Traffic Engineering without Bandwidth Admission Control
skipping to change at page 7, line 24 skipping to change at page 7, line 42
The core nodes of a given region are directly connected. The core nodes of a given region are directly connected.
Inter-region links only connect core nodes of the same plane. Inter-region links only connect core nodes of the same plane.
{C1k has a link to C1j} iff {C2k has a link to C2j}. {C1k has a link to C1j} iff {C2k has a link to C2j}.
The distribution of these links depends on the topological The distribution of these links depends on the topological
properties of the core of the AS. The design rule presented properties of the core of the AS. The design rule presented
above specifies that these links appear in both core planes. above specifies that these links appear in both core planes.
We assume a common design rule found in such deployments: the inter- We assume a common design rule found in such deployments: the inter-
plane link costs (Cik-Cjk where i<>j) are set such that the route to plane link costs (Cik-Cjk where i != j) are set such that the route
an edge destination from a given plane stays within the plane unless to an edge destination from a given plane stays within the plane
the plane is partitioned. unless the plane is partitioned.
Edge Router A Edge Router A
/ \ / \
/ \ / \
/ \ Agg Region A / \ Agg Region A
/ \ / \
/ \ / \
C1A----------C2A C1A----------C2A
| \ | \ | \ | \
| \ | \ | \ | \
| C1B----------C2B | C1B----------C2B
Plane1 | | | | Plane2 Plane1 | | | | Plane2
| | | | | | | |
C1C--|-----C2C | C1C--|-----C2C |
\ | \ | \ | \ |
\ | \ | \ | \ |
C1Z----------C2Z C1Z----------C2Z
\ / \ /
\ / Agg Region Z \ / Agg Region Z
\ / \ /
\ / \ /
Edge Router Z Edge Router Z
Figure 2: Dual-Plane Network and Disjointness Figure 2: Dual-Plane Network and Disjointness
In this scenario, the operator requires the ability to deploy In this scenario, the operator requires the ability to deploy
different strategies. For example, Edge Router A should be able to different strategies. For example, Edge Router A should be able to
use the three following options: use the three following options:
o the traffic is load-balanced across any ECMP path through the o the traffic is load-balanced across any ECMP path through the
network network
skipping to change at page 8, line 23 skipping to change at page 8, line 47
Plane1 of the network Plane1 of the network
o the traffic is load-balanced across any ECMP path within the o the traffic is load-balanced across any ECMP path within the
Plane2 of the network Plane2 of the network
Most of the data traffic from A to Z would use the first option, such Most of the data traffic from A to Z would use the first option, such
as to exploit the capacity efficiently. The operator would use the as to exploit the capacity efficiently. The operator would use the
two other choices for specific premium traffic that has requested two other choices for specific premium traffic that has requested
disjoint transport. disjoint transport.
The SPRING architecture SHOULD support this use case with the The SPRING architecture MUST support this use case with the following
following requirements: requirements:
o Zero per-service state and signaling on midpoint and tail-end o Zero per-service state and signaling on midpoint and tail-end
routers. routers.
o ECMP-awareness. o ECMP-awareness.
o Node resiliency property: the traffic-engineering policy is not o Node resiliency property: the traffic-engineering policy is not
anchored to a specific core node whose failure could impact the anchored to a specific core node whose failure could impact the
service. service.
3.3.1.1.2. Egress Peering Traffic Engineering 3.3.1.1.2. Egress Peering Traffic Engineering
+------+ +------+
| | | |
+---D F +---D F
+---------+ / | AS 2 |\ +------+ +---------+ / | AS 2 |\ +------+
| |/ +------+ \| Z | | |/ +------+ \| Z |
A C | | A C | |
| |\ +------+ /| AS 4 | | |\ +------+ /| AS 4 |
B AS1 | \ | |/ +------+ B AS1 | \ | |/ +------+
| | +---E G | | +---E G
+---------+ | AS 3 | +---------+ | AS 3 |
+------+\ +------+\
Figure 3: Egress peering traffic engineering Figure 3: Egress peering traffic engineering
Let us assume, in the network depicted in Figure 3, that: Let us assume, in the network depicted in Figure 3, that:
C in AS1 learns about destination Z of AS 4 via two BGP paths C in AS1 learns about destination Z of AS 4 via two BGP paths
(AS2, AS4) and (AS3, AS4). (AS2, AS4) and (AS3, AS4).
C may or may not be configured so to enforce next-hop-self C may or may not be configured so to enforce next-hop-self
behavior before propagating the paths within AS1. behavior before propagating the paths within AS1.
C may propagate all the paths to Z within AS1 (BGP add-paths, C may propagate all the paths to Z within AS1 (BGP add-paths,
[I-D.ietf-idr-add-paths]). [I-D.ietf-idr-add-paths]).
C may install in its FIB only the route via AS2, or only the route C may install in its FIB only the route via AS2, or only the route
via AS3, or both. via AS3, or both.
In that context, the SPRING architecture SHOULD allow the operator of In that context, the SPRING architecture MUST allow the operator of
AS1 to apply a traffic-engineering policy such as the following one, AS1 to apply a traffic-engineering policy such as the following one,
regardless the configured behavior of next-hop-self: regardless the configured behavior of next-hop-self:
Steer 60% of the Z-destined traffic received at A via AS2 and 40% Steer 60% of the Z-destined traffic received at A via AS2 and 40%
via AS3. via AS3.
Steer 80% of the Z-destined traffic received at B via AS2 and 20% Steer 80% of the Z-destined traffic received at B via AS2 and 20%
via AS3. via AS3.
The SPRING architecture SHOULD allow an ingress node (i.e., an The SPRING architecture MUST allow an ingress node (i.e., an explicit
explicit route source node) to select the exit point of a packet as route source node) to select the exit point of a packet as any
any combination of an egress node, an egress interface, a peering combination of an egress node, an egress interface, a peering
neighbor, and a peering AS. neighbor, and a peering AS.
The use cases and requirements for Egress Peer Engineering are The use cases and requirements for Egress Peer Engineering are
described in [I-D.ietf-spring-segment-routing-central-epe]. described in [I-D.ietf-spring-segment-routing-central-epe].
3.3.1.1.3. Load-balancing among non-parallel links 3.3.1.1.3. Load-balancing among non-parallel links
The SPRING architecture SHOULD allow a given node to load share The SPRING architecture MUST allow a given node to load share traffic
traffic across multiple non parallel links (i.e.: links connected to across multiple non parallel links (i.e.: links connected to
different adjacent routers) even if these lead to different different adjacent routers) even if these lead to different
neighbors. This may be useful to support traffic engineering neighbors. This may be useful to support traffic engineering
policies. policies.
+---C---D---+ +---C---D---+
| | | |
PE1---A---B-----F-----E---PE2 PE1---A---B-----F-----E---PE2
Figure 4: Multiple (non-parallel) Adjacencies Figure 4: Multiple (non-parallel) Adjacencies
In the above example, the operator requires PE1 to load-balance its 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 PE2-destined traffic between the ABCDE and ABFE equal-cost paths in a
controlled way where the operator SHOULD be allowed to distribute controlled way where the operator MUST be allowed to distribute
traffic unevenly between paths (Weighted Equal Cost Multiplath, traffic unevenly between paths (Weighted Equal Cost Multiplath,
WECMP). WECMP).
3.3.1.2. Traffic Engineering with Bandwidth Admission Control 3.3.1.2. Traffic Engineering with Bandwidth Admission Control
The implementation of bandwidth admission control within a network The implementation of bandwidth admission control within a network
(and its possible routing consequence which consists in routing along (and its possible routing consequence which consists in routing along
explicit paths where the bandwidth is available) requires a capacity explicit paths where the bandwidth is available) requires a capacity
planning process. planning process.
skipping to change at page 10, line 34 skipping to change at page 11, line 11
The bandwidth accounting of a demand along its shortest-path is a The bandwidth accounting of a demand along its shortest-path is a
basic capability of any planning tool or PCE server. basic capability of any planning tool or PCE server.
For example, in the network topology described below, and assuming a 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 default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps
A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ,
800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and
EF. EF.
C-----D C-----D
/ \ \ / \ \
A---B +--E--F--Z A---B +--E--F--Z
\ / \ /
G------+ G------+
Figure 5: Capacity Planning an ECMP-based demand Figure 5: Capacity Planning an ECMP-based demand
ECMP is extremely frequent in SP, Enterprise and DC architectures and ECMP is extremely frequent in SP, Enterprise and DC architectures and
it is not rare to see as much as 128 different ECMP paths between a 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 source and a destination within a single network domain. It is a key
efficiency objective to spread the traffic among as many ECMP paths efficiency objective to spread the traffic among as many ECMP paths
as possible. as possible.
This is illustrated in the below network diagram which consists of a This is illustrated in the below network diagram which consists of a
subset of a network where already 5 ECMP paths are observed from A to subset of a network where already 5 ECMP paths are observed from A to
M. M.
C C
/ \ / \
B-D-L-- B-D-L--
/ \ / \ / \ / \
A E \ A E \
\ M \ M
\ G / \ G /
\ / \ / \ / \ /
F K F K
\ / \ /
I I
Figure 6: ECMP Topology Example Figure 6: ECMP Topology Example
When the capacity planning process detects that a traffic growth When the capacity planning process detects that a traffic growth
scenario and topology variation would lead to congestion, a capacity scenario and topology variation would lead to congestion, a capacity
increase is triggered and if it cannot be deployed in due time, a increase is triggered and if it cannot be deployed in due time, a
traffic engineering solution is activated within the network. traffic engineering solution is activated within the network.
A basic traffic engineering objective consists of finding the A basic traffic engineering objective consists of finding the
smallest set of demands that need to be routed off their shortest smallest set of demands that need to be routed off their shortest
path to eliminate the congestion, then to compute an explicit path path to eliminate the congestion, then to compute an explicit path
for each of them and instantiating these traffic-engineered policies for each of them and instantiating these traffic-engineered policies
in the network. in the network.
The SPRING architecture SHOULD offer a simple support for ECMP-based The SPRING architecture MUST offer a simple support for ECMP-based
shortest path placement as well as for explicit path policy without shortest path placement as well as for explicit path policy without
incurring additional signaling in the domain. This includes: 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 steer a packet across a set of ECMP paths
o the ability to diverge from a set of ECMP shortest paths to one or o the ability to diverge from a set of ECMP shortest paths to one or
more paths not in the set of shortest paths more paths not in the set of shortest paths
3.3.1.2.2. SDN/SR use-case 3.3.1.2.2. SDN Use Case
The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as
described in [I-D.ietf-pce-stateful-pce]. described in [I-D.ietf-pce-stateful-pce].
The SDN controller is responsible to control the evolution of the The SDN controller is responsible to control the evolution of the
traffic matrix and topology. It accepts or denies the addition of traffic matrix and topology. It accepts or denies the addition of
new traffic into the network. It decides how to route the accepted new traffic into the network. It decides how to route the accepted
traffic. It monitors the topology and upon topological change, traffic. It monitors the topology and upon topological change,
determines the minimum traffic that should be rerouted on an determines the minimum traffic that should be rerouted on an
alternate path to alleviate a bandwidth congestion issue. alternate path to alleviate a bandwidth congestion issue.
skipping to change at page 12, line 14 skipping to change at page 12, line 38
The means of collecting traffic and topology information are the same The means of collecting traffic and topology information are the same
as what would be used with other SDN-based traffic-engineering as what would be used with other SDN-based traffic-engineering
solutions. solutions.
The means of instantiating policy information at a traffic- The means of instantiating policy information at a traffic-
engineering head-end are the same as what would be used with other engineering head-end are the same as what would be used with other
SDN-based traffic-engineering solutions. SDN-based traffic-engineering solutions.
In the context of Centralized-Based Optimization and the SDN use- In the context of Centralized-Based Optimization and the SDN use-
case, here are the functionalities that the SPRING architecture case, here are the functionalities that the SPRING architecture MUST
SHOULD deliver: deliver:
Explicit routing capability with or without ECMP-awareness. Explicit routing capability with or without ECMP-awareness.
No signaling hop-by-hop through the network. No signaling hop-by-hop through the network.
State is only maintained at the policy head-end. No state is Policy state is only maintained at the policy head-end. No policy
maintained at mid-points and tail-ends. state is maintained at mid-points and tail-ends.
Automated guaranteed FRR for any topology. Automated guaranteed FRR for any topology.
Optimum virtualization: the policy state is in the packet header The policy state is in the packet header and not in the
and not in the intermediate nodes along the path. The policy is intermediate nodes along the path. The policy is absent from
completely virtualized away from midpoints and tail-ends. midpoints and tail-ends.
Highly responsive to change: the SDN Controller only needs to Highly responsive to change: the SDN Controller only needs to
apply a policy change at the head-end. No delay is introduced due apply a policy change at the head-end. No delay is introduced due
to programming the midpoints and tail-end along the path. to programming the midpoints and tail-end along the path.
3.4. Interoperability with non-SPRING nodes 3.4. Interoperability with non-SPRING nodes
SPRING nodes MUST inter-operate with non-SPRING nodes and in both SPRING nodes MUST inter-operate with non-SPRING nodes and in both
MPLS and IPv6 dataplanes in order to allow a gradual deployment of MPLS and IPv6 dataplanes in order to allow a gradual deployment of
SPRING on existing MPLS and IPv6 networks. SPRING on existing MPLS and IPv6 networks.
4. Security Considerations 4. Security Considerations
There is an assumed trust model such that the source imposing an SPRING reuses the concept of source routing by encoding the path in
explicit route on a packet is assumed to be allowed to do so. It is the packet. As with other similar source routing architecture, an
assumed that the default behavior is to strip any internal routing attacker may manipulate traffic path by modifying the packet header.
information from the packet before the packet is forwarded outside By manipulating traffic path, an attacker may be able to cause
the domain. In such context trust boundaries SHOULD strip explicit outages on any part of the network.
routes from a packet.
For each data plane technology that SPRING specifies, a security SPRING adds some meta-data on the packet, with the list of forwarding
analysis MUST be provided showing how protection is provided against path elements that the packet must traverse. Depending on the data
an attacker disrupting the network by for example, maliciously plane, this list may shrink as the packet traverse the network, by
injecting SPRING packets. only keeping the next elements and forgetting the past ones.
SPRING architecture MUST provide clear trust domain boundaries, so
that 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 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 MUST NOT expose any source routing
information when a packet leaves the trusted domain. Special care
will be required for the existing dataplanes 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 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 paths) between the source and the mid points, 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.
For the MPLS data plane, this not a new requirement as the existing
MPLS architecture already allow such source routing by stacking
multiple labels. And for security protection, RFC4381 section 2.4
and RFC 5920 section 8.2 already calls 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.: labels) are filtered
while the border router is not the originator of these label
advertisements.
As the SPRING architecture must be based on clear trust domain,
mechanisms allowing the authentication and validation of the source
routing information must be evaluated by the SPRING architecture in
order to prevent any form of attack or unwanted source routing
information manipulation.
Dataplane security considerations MUST be addressed in each SPRING
dataplane related document (i.e.: MPLS and IPv6).
The IPv6 data plane proposes the use of a cryptographic signature of
the source routed path which would ease this configuration. This is
indeed more needed for the IPv6 data plane which is end to end in
nature, compared to the MPLS data plane which is typically restricted
to a controlled and trusted zone.
In the forwarding plane, data plane extension documents MUST address
the security implications of the required change.
In term of privacy, SPRING does not propose change in term of
encryption. Each dataplane, may or may not provide existing or
future encryption capability.
In order to build the source routing information in the packet, a
node in 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 attacker. Control plane
security considerations MUST be addressed in each SPRING control
plane related document.
5. IANA Considerations 5. IANA Considerations
This document does not request any IANA allocations. This document does not request any IANA allocations.
6. Manageability Considerations 6. Manageability Considerations
The SPRING WG SHOULD provide OAM and the management needed to manage The SPRING WG MUST define Operations and Management (OAM) procedures
SPRING enabled networks. The SPRING procedures MAY also be used as a applicable to SPRING enabled networks.
tool for OAM in SPRING enabled networks.
OAM use cases and requirements are described in In SPRING networks, the path the packet takes is encoded in the
[I-D.geib-spring-oam-usecase] and header. SPRING architecture MUST include the necessary OAM
[I-D.kumar-spring-sr-oam-requirement]. 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) or
as a service path (formed by a set of service instances). The
network operator MUST be capable to monitor, control and manage paths
(network and service based) using OAM procedures.
OAM use cases and requirements are detailed in
[I-D.ietf-spring-oam-usecase] and
[I-D.ietf-spring-sr-oam-requirement].
7. Contributors 7. Contributors
The following individuals substantially contributed to the content of The following individuals substantially contributed to the content of
this documents: this documents:
Ruediger Geib Ruediger Geib
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt 64295 Darmstadt 64295
skipping to change at page 14, line 9 skipping to change at page 16, line 23
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>. <http://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>. <http://www.rfc-editor.org/info/rfc4762>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<http://www.rfc-editor.org/info/rfc6624>. <http://www.rfc-editor.org/info/rfc6624>.
9.2. Informative References 9.2. Informative References
[I-D.geib-spring-oam-usecase] [I-D.ietf-6man-segment-routing-header]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
case for a scalable and topology aware MPLS data plane J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
monitoring system", draft-geib-spring-oam-usecase-06 (work Routing Header (SRH)", draft-ietf-6man-segment-routing-
in progress), July 2015. header-00 (work in progress), December 2015.
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-13 (work in progress), December 2015. add-paths-13 (work in progress), December 2015.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-13 (work in progress), December 2015. pce-13 (work in progress), December 2015.
[I-D.ietf-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
Case for a Scalable and Topology-Aware Segment Routing
MPLS Data Plane Monitoring System", draft-ietf-spring-oam-
usecase-01 (work in progress), October 2015.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Francois, P., Filsfils, C., Decraene, B., and r. Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
rjs@rob.sh, "Use-cases for Resiliency in SPRING", draft- "Use-cases for Resiliency in SPRING", draft-ietf-spring-
ietf-spring-resiliency-use-cases-02 (work in progress), resiliency-use-cases-02 (work in progress), December 2015.
December 2015.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev,
"Segment Routing Centralized Egress Peer Engineering", "Segment Routing Centralized Egress Peer Engineering",
draft-ietf-spring-segment-routing-central-epe-00 (work in draft-ietf-spring-segment-routing-central-epe-00 (work in
progress), October 2015. progress), October 2015.
[I-D.kumar-spring-sr-oam-requirement] [I-D.ietf-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-kumar-spring-sr-oam-requirement-03 (work Network", draft-ietf-spring-sr-oam-requirement-01 (work in
in progress), March 2015. progress), December 2015.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200 Via Del Serafico, 200
Rome 00142 Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
 End of changes. 46 change blocks. 
167 lines changed or deleted 266 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/