draft-ietf-spring-problem-statement-03.txt   draft-ietf-spring-problem-statement-04.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: April 26, 2015 B. Decraene Expires: October 29, 2015 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
British Telecom British Telecom
October 23, 2014 April 27, 2015
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-ietf-spring-problem-statement-03 draft-ietf-spring-problem-statement-04
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'. '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.:
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, This document outlines various use cases, with their requirements,
that need to be taken into account by the Source Packet Routing in that need to be taken into account by the Source Packet Routing in
Networking (SPRING) architecture for unicast traffic. Multicast use- Networking (SPRING) architecture for unicast traffic. Multicast use-
cases and requirements are out of scope of this document. cases and requirements are out of scope of this document.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 2, line 7 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 April 26, 2015. This Internet-Draft will expire on October 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . 4 3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 4 3.1. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . 4
4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . 4
5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 5 3.2. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 6 3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5
5.1.1. Traffic Engineering without Bandwidth Admission 3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 6
Control . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Interoperability with non-SPRING nodes . . . . . . . . . 12
5.1.2. Traffic Engineering with Bandwidth Admission Control 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Interoperability with non-SPRING nodes . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Manageability Considerations . . . . . . . . . . . . . . . . 13
8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Manageability Considerations . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 14
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 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 30 skipping to change at page 3, line 24
Simplification and reduction of network signaling components Simplification and reduction of network signaling components
Load balancing and traffic engineering Load balancing and traffic engineering
Source-based routing mechanisms have previously been specified for Source-based routing mechanisms have previously been specified for
network protocols, but have not seen widespread adoption other than network protocols, but have not seen widespread adoption other than
in MPLS traffic engineering. in MPLS traffic engineering.
These network functions may require greater flexibility and per These network functions may require greater flexibility and per
packet source imposed routing than can be achieved through the use of packet source imposed routing than can be achieved through the use of
the previously defined methods. In the context of this charter, the previously defined methods. In the context of this document, the
'source' means 'the point at which the explicit route is imposed'. term '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.: the node imposing the explicit route may be the ingress
node of an operator's network). Throughout this document we refer to
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.
SPRING architecture should allow incremental and selective deployment The SPRING architecture SHOULD allow incremental and selective
without any requirement of flag day or massive upgrade of all network deployment without any requirement of flag day or massive upgrade of
elements. all network elements.
SPRING architecture should allow optimal virtualization: put policy The SPRING architecture SHOULD allow optimal virtualization: put
state in the packet header and not in the intermediate nodes along policy state in the packet header and not in the intermediate nodes
the path. Hence, the policy is completely virtualized away from along the path. Hence, the policy is completely virtualized away
midpoints and tail-ends. from midpoints and tail-ends.
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.
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.
MPLS dataplane doesn't require any modification in order to apply a The IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045],
source-based routed model (e.g.:
[I-D.filsfils-spring-segment-routing-mpls]).
IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045],
defines the Routing Extension Header which provides IPv6 source-based defines the Routing Extension Header which provides IPv6 source-based
routing capabilities. routing capabilities.
The SPRING architecture should leverage 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]).
3. IGP-based MPLS Tunneling 3. SPRING Use Cases
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 (VPN, VPLS, VPWS) from an ingress PE the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE
to an egress PE, with or without the expression of an explicit path to an egress PE, with or without the expression of an explicit path
and without requiring forwarding plane or control plane state in and without requiring forwarding plane or control plane state in
intermediate nodes. intermediate nodes.
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 unicast services (VPN, VPLS, VPWS) from an the ability to tunnel unicast services (VPN, VPLS, VPWS) from an
ingress PE to an egress PE, with or without the expression of an ingress PE to an egress PE, with or without the expression of an
explicit path and without requiring forwarding plane or control plane explicit path and without requiring forwarding plane or control plane
state in intermediate nodes. p2mp and mp2mp tunnels are out of the state in intermediate nodes. p2mp and mp2mp tunnels are out of the
scope of this document. scope of this document.
3.1. Example of IGP-based MPLS Tunnels 3.1.1. Example of IGP-based MPLS Tunnels
This section illustrates an example use-case taken from This section illustrates an example use-case.
[I-D.filsfils-spring-segment-routing-use-cases].
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.168.0.2. PE1 installs the VPN prefix Z in MPBGP to PE1 with nhop 192.168.0.2 (i.e.: the local address of PE2).
the appropriate VRF and resolves the next-hop onto the node segment PE1 installs the VPN prefix Z in the appropriate VRF and resolves the
associated with PE2. next-hop onto the node segment associated with 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 SHOULD 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 (within
their label stack) the necessary information derived from the their label stack) the necessary information derived from the
topology database in order to deliver the packet to the remote PE. topology database in order to deliver the packet to the remote PE.
4. Fast Reroute 3.2. Fast Reroute
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 following requirements: The SPRING architecture SHOULD address the following requirements:
o support of FRR on any topology o support of 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].
5. Traffic Engineering 3.3. Traffic Engineering
Traffic Engineering has been addressed using IGP protocol extensions Traffic Engineering has been addressed using IGP protocol extensions
(for resources information propagation) and RSVP-TE for signaling (for resources information propagation) and RSVP-TE for signaling
explicit paths. Different contexts and modes have been defined explicit paths. Different contexts and modes have been defined
(single vs. multiple domains, with or without bandwidth admission (single vs. multiple domains, with or without bandwidth admission
control, centralized vs. distributed path computation, etc). control, centralized vs. distributed path computation, etc).
In all cases, one of the major components of the TE architecture is In all cases, one of the major components of the TE architecture is
the soft state based signaling protocol (RSVP-TE) which is used in the soft state based signaling protocol (RSVP-TE) which is used in
order to signal and establish the explicit path. Each path, once order to signal and establish the explicit path. Each path, once
skipping to change at page 6, line 13 skipping to change at page 6, line 10
differentiation may be done at a finer granularity (e.g.: application differentiation may be done at a finer granularity (e.g.: application
specific). Also the amount of state needed to be maintained and specific). Also the amount of state needed to be maintained and
periodically refreshed in all involved nodes contributes periodically refreshed in all involved nodes contributes
significantly to complexity and the number of failures cases, and significantly to complexity and the number of failures cases, and
thus increases operational effort while decreasing overall network thus increases operational effort while decreasing overall network
reliability. 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 SHOULD support traffic engineering,
including: including:
o loose or strict options o loose or strict options
o bandwidth admission control o bandwidth admission control
o distributed vs. centralized model (PCE, SDN Controller) o distributed vs. centralized model (PCE, SDN Controller)
o disjointness in dual-plane networks o disjointness in dual-plane networks
skipping to change at page 6, line 37 skipping to change at page 6, line 34
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.
5.1. Examples of Traffic Engineering Use Cases 3.3.1. Examples of Traffic Engineering Use Cases
As documented in [I-D.filsfils-spring-segment-routing-use-cases] here Here follows the description of two sets of use cases:
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
5.1.1. Traffic Engineering without Bandwidth Admission Control 3.3.1.1. Traffic Engineering without Bandwidth Admission Control
In this section, we describe Traffic Engineering use-cases without In this section, we describe Traffic Engineering use-cases without
bandwidth admission control. bandwidth admission control.
5.1.1.1. Disjointness in dual-plane networks 3.3.1.1.1. Disjointness in dual-plane networks
Many networks are built according to the dual-plane design, as Many networks are built according to the dual-plane design, as
illustrated in Figure 2: illustrated in Figure 2:
Each access region k is connected to the core by two C routers Each access region k is connected to the core by two C routers
(C(1,k) and C(2,k)). C1k and C2k where k refers to the region.
C(1,k) is part of plane 1 and aggregation region K C1k is part of plane 1 and aggregation region k
C(2,k) is part of plane 2 and aggregation region K C2k is part of plane 2 and aggregation region k
C(1,k) has a link to C(2, j) iff k = j. C1k has a link to C2j iff k = j.
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.
{C(1,k) has a link to C(1, j)} iff {C(2,k) has a link to C(2, j)}. {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 to
an edge destination from a given plane stays within the plane unless an edge destination from a given plane stays within the plane unless
the plane is partitioned. the plane is partitioned.
skipping to change at page 8, line 30 skipping to change at page 8, line 6
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, A should be able to use the three different strategies. For example, Edge Router A should be able to
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
o the traffic is load-balanced across any ECMP path within the o the traffic is load-balanced across any ECMP path within the
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 SHOULD support this use case with the
following requirements: following 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.
5.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
skipping to change at page 9, line 35 skipping to change at page 9, line 11
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 (add-path). C may propagate all the paths to Z within AS1 (BGP 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, SPRING should allow the operator of AS1 to apply the In that context, the SPRING architecture SHOULD allow the operator of
following traffic-engineering policy, regardless the configured AS1 to apply a traffic-engineering policy such as the following one,
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 (or a source The SPRING architecture SHOULD allow an ingress node (i.e., an
node) to select the exit point of a packet as any combination of an explicit route source node) to select the exit point of a packet as
egress node, an egress interface, a peering neighbor, and a peering any combination of an egress node, an egress interface, a peering
AS. neighbor, and a peering AS.
5.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 should be able to The SPRING architecture SHOULD allow a given node to load share
load share traffic across multiple non parallel links even if these traffic across multiple non parallel links even if these lead to
ones lead to different neighbors. This may be useful to support different neighbors. This may be useful to support traffic
traffic engineering policies. engineering 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 paths. PE2-destined traffic between the ABCDE and ABFE paths.
5.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.
The spreading of load among ECMP paths is a key attribute of the The spreading of load among ECMP paths is a key attribute of the
capacity planning processes applied to packet-based networks. capacity planning processes applied to packet-based networks.
5.1.2.1. Capacity Planning Process 3.3.1.2.1. Capacity Planning Process
Capacity Planning anticipates the routing of the traffic matrix onto Capacity Planning anticipates the routing of the traffic matrix onto
the network topology, for a set of expected traffic and topology the network topology, for a set of expected traffic and topology
variations. The heart of the process consists in simulating the variations. The heart of the process consists in simulating the
placement of the traffic along ECMP-aware shortest-paths and placement of the traffic along ECMP-aware shortest-paths and
accounting for the resulting bandwidth usage. accounting for the resulting bandwidth usage.
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.
skipping to change at page 11, line 48 skipping to change at page 11, line 30
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.
SPRING architecture should offer a simple support for ECMP-based The SPRING architecture SHOULD 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
5.1.2.2. SDN/SR use-case 3.3.1.2.2. SDN/SR 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 30 skipping to change at page 12, line 13
controller and are outside the scope of this document. controller and are outside the scope of this document.
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 (e.g. [RFC7011] and [I-D.ietf-idr-ls-distribution]. solutions (e.g. [RFC7011] and [I-D.ietf-idr-ls-distribution].
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 (e.g.: SDN-based traffic-engineering solutions (e.g.:
[I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and [I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and
[I-D.sivabalan-pce-segment-routing]). [I-D.ietf-pce-segment-routing]).
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 benefits that the SPRING architecture should case, here are the functionalities that the SPRING architecture
deliver: SHOULD 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 State is only maintained at the policy head-end. No state is
maintained at mid-points and tail-ends. 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 Optimum virtualization: the policy state is in the packet header
and not in the intermediate nodes along the path. The policy is and not in the intermediate nodes along the path. The policy is
completely virtualized away from midpoints and tail-ends. completely virtualized away from 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.
5.1.2.2.1. SDN Example 3.4. Interoperability with non-SPRING nodes
The data-set consists in a full-mesh of 12000 explicitly-routed
tunnels observed on a real network. These tunnels resulted from
distributed headend-based CSPF computation.
We measured that only 65% of the traffic is forwarded over its
shortest path.
Three well-known defects are illustrated in this data set:
The lack of ECMP support in explicitly routed tunnels: ATM-alike
traffic-steering mechanisms steer the traffic along a non-ECMP
path.
The increase of the number of explicitly-routed non-ECMP tunnels
to enumerate all the ECMP options.
The inefficiency of distributed optimization: too much traffic is
forwarded off its shortest path.
We applied the SDN use-case to this dataset implying a source route
model where the path of the packet is encoded within the packet
itself. This means that:
The distributed CSPF computation is replaced by centralized
optimization and BW admission control, supported by the SDN
Controller.
As part of the optimization, we also optimized the IGP-metrics
such as to get a maximum of traffic load-spread among ECMP
paths by default.
The traffic-engineering policies are supported by a source route
model (e.g.: [I-D.filsfils-spring-segment-routing]).
As a result, we measured that 98% of the traffic would be kept on its
normal policy (over the shortest-path) and only 2% of the traffic
requires a path away from the shortest-path.
Let us highlight a few benefits:
98% of the traffic-engineering head-end policies are eliminated.
Indeed, by default, an ingress edge node capable of injecting
source routed packets steers the traffic to the egress edge
node. No configuration or policy needs to be maintained at the
ingress edge node to realize this.
100% of the states at mid/tail nodes are eliminated.
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.
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 use cases and requirements are described in SPRING nodes MUST inter-operate with non-SPRING nodes and in both
[I-D.geib-spring-oam-usecase] and MPLS and IPv6 dataplanes.
[I-D.kumar-spring-sr-oam-requirement].
8. Security 4. Security Considerations
There is an assumed trust model such that any node imposing an There is an assumed trust model such that the source imposing an
explicit route on a packet is assumed to be allowed to do so. In explicit route on a packet is assumed to be allowed to do so. In
such context trust boundaries should strip explicit routes from a such context trust boundaries should strip explicit routes from a
packet. packet.
For each data plane technology that SPRING specifies, a security For each data plane technology that SPRING specifies, a security
analysis must be provided showing how protection is provided against analysis MUST be provided showing how protection is provided against
an attacker disrupting the network by for example, maliciously an attacker disrupting the network by for example, maliciously
injecting SPRING packets. injecting SPRING packets.
9. IANA Considerations 5. IANA Considerations
TBD
10. Manageability Considerations This document does not request any IANA allocations.
TBD 6. Manageability Considerations
11. Security Considerations 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.
TBD OAM use cases and requirements are described in
[I-D.geib-spring-oam-usecase] and
[I-D.kumar-spring-sr-oam-requirement].
12. 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
DE DE
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
Robert Raszuk Robert Raszuk
Mirantis Inc. Mirantis Inc.
615 National Ave. 615 National Ave.
94043 Mt View, CA 94043 Mt View, CA
US US
Email: robert@raszuk.net Email: robert@raszuk.net
13. Acknowledgements 8. Acknowledgements
The authors would like to thank Yakov Rekhter for his contribution to The authors would like to thank Yakov Rekhter for his contribution to
this document. this document.
14. References 9. References
14.1. Normative References 9.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012. RFC 6564, April 2012.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013. of IPv6 Extension Headers", RFC 7045, December 2013.
14.2. Informative References 9.2. Informative References
[I-D.crabbe-pce-pce-initiated-lsp] [I-D.crabbe-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in
progress), October 2013. progress), October 2013.
[I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring-
segment-routing-04 (work in progress), July 2014.
[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-02 (work in
progress), September 2014.
[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-03 (work in progress), August
2014.
[I-D.filsfils-spring-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils-
spring-segment-routing-use-cases-01 (work in progress),
October 2014.
[I-D.geib-spring-oam-usecase] [I-D.geib-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
case for a scalable and topology aware MPLS data plane case for a scalable and topology aware MPLS data plane
monitoring system", draft-geib-spring-oam-usecase-03 (work monitoring system", draft-geib-spring-oam-usecase-04 (work
in progress), October 2014. in progress), March 2015.
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-05 (work in System", draft-ietf-i2rs-architecture-09 (work in
progress), July 2014. progress), March 2015.
[I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-10 (work in progress), October 2014.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-06 Information using BGP", draft-ietf-idr-ls-distribution-10
(work in progress), September 2014. (work in progress), January 2015.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
"PCEP Extensions for Segment Routing", draft-ietf-pce-
segment-routing-03 (work in progress), April 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-09 (work in progress), June 2014. pce-11 (work in progress), April 2015.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir, Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
"Use-cases for Resiliency in SPRING", draft-ietf-spring- "Use-cases for Resiliency in SPRING", draft-ietf-spring-
resiliency-use-cases-00 (work in progress), May 2014. resiliency-use-cases-01 (work in progress), March 2015.
[I-D.kumar-spring-sr-oam-requirement] [I-D.kumar-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
Mirsky, "OAM Requirements for Segment Routing Network", and S. Litkowski, "OAM Requirements for Segment Routing
draft-kumar-spring-sr-oam-requirement-01 (work in Network", draft-kumar-spring-sr-oam-requirement-03 (work
progress), July 2014. in progress), March 2015.
[I-D.sivabalan-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions
for Segment Routing", draft-sivabalan-pce-segment-
routing-03 (work in progress), July 2014.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September Exchange of Flow Information", STD 77, RFC 7011, September
2013. 2013.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 70 change blocks. 
224 lines changed or deleted 134 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/