draft-ietf-spring-problem-statement-08.txt   rfc7855.txt 
Network Working Group S. Previdi, Ed. Internet Engineering Task Force (IETF) S. Previdi, Ed.
Internet-Draft C. Filsfils, Ed. Request for Comments: 7855 C. Filsfils, Ed.
Intended status: Informational Cisco Systems, Inc. Category: Informational Cisco Systems, Inc.
Expires: October 8, 2016 B. Decraene ISSN: 2070-1721 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
Jive Communications Jive Communications, Inc.
April 6, 2016 May 2016
SPRING Problem Statement and Requirements Source Packet Routing in Networking (SPRING)
draft-ietf-spring-problem-statement-08 Problem Statement and Requirements
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";
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.,
the node imposing the explicit route may be the ingress node of an the node imposing the explicit route may be the ingress node of an
operator's network). 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 for this document.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 8, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7855.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Data Planes . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 5
3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5 3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5
3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5 3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 6
3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 7 3.3.1. Examples of Traffic-Engineering Use Cases . . . . . . 7
3.4. Interoperability with non-SPRING nodes . . . . . . . . . 13 3.4. Interoperability with Non-SPRING Nodes . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Manageability Considerations . . . . . . . . . . . . . . . . 15
6. Manageability Considerations . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 o 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
Network, link, path and node protection such as fast re-route o Network, link, path, and node protection such as fast reroute
Network programmability o Network programmability
OAM techniques o OAM techniques
Simplification and reduction of network signaling components o Simplification and reduction of network signaling components
Load balancing and traffic engineering o 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 more
packet source imposed routing than can be achieved through the use of source-imposed routing than can be achieved through the use of the
the previously defined methods. In the context of this document, the previously defined methods. In the context of this document, the
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"; 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
this definition of 'source'. 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.
The SPRING architecture MUST 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 a flag day or massive upgrade
all network elements. of all network elements.
The SPRING architecture MUST allow to put policy state in the packet The SPRING architecture MUST allow putting the policy state in the
header and not in the intermediate nodes along the path. Hence, the packet header and not in the intermediate nodes along the path.
policy is instantiated in the packet header and does not requires any Hence, the policy is instantiated in the packet header and does not
policy state in midpoints and tail-ends. requires any 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 to complement
and address use cases where removal of signaling and path state in them and address use cases where removal of signaling and path state
the core is a requirement. in the core is a requirement.
Multicast use-cases and requirements are out of scope of this Multicast use cases and requirements are out of scope for this
document. document.
2. Dataplanes 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Data Planes
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 data planes.
The SPRING architecture SHOULD leverage the existing MPLS dataplane The SPRING architecture SHOULD leverage the existing MPLS data plane
without any modification and leverage IPv6 dataplane with a new IPv6 without any modification and leverage the IPv6 data plane with a new
Routing Header Type (IPv6 Routing Header is defined in [RFC2460]) and IPv6 Routing Header Type (IPv6 Routing Header is defined in
a proposal for a new type of routing header is made by [RFC2460]) and a proposal for a new type of routing header is made by
[I-D.ietf-6man-segment-routing-header]. [SRH].
The SPRING architecture MUST allow interoperability between SPRING The SPRING architecture MUST allow interoperability between SPRING-
capable and non-capable nodes and this in both MPLS and IPv6 capable and non-SPRING-capable nodes in both the MPLS and IPv6 data
dataplanes. planes.
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 data plane,
the ability to tunnel services like VPN ([RFC4364]), VPLS ([RFC4761], offers the ability to tunnel services like VPN ([RFC4364]), Virtual
[RFC4762]) and VPWS ([RFC6624]), from an ingress PE to an egress PE, Private LAN Service (VPLS) ([RFC4761], [RFC4762]) and Virtual Private
with or without the expression of an explicit path and without Wire Service (VPWS) ([RFC6624]), from an ingress Provider Edge (PE)
requiring forwarding plane or control plane state in intermediate to an egress PE, with or without the expression of an explicit path
nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are and without requiring forwarding-plane or control-plane state in
outside of the scope of this document. intermediate nodes. Point-to-multipoint and multipoint-to-multipoint
tunnels are outside 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 the
MPBGP to PE1 with nhop 192.0.2.2 (i.e.: the local address of PE2). Multiprotocol Border Gateway Protocol (MPBGP) to PE1 with next-hop
PE1 installs the VPN prefix Z in the appropriate VRF and resolves the address 192.0.2.2 (i.e., the local address of PE2). PE1 installs the
next-hop onto the IGP-based MPLS tunnel to PE2. VPN prefix Z in the appropriate VPN Routing and Forwarding table
(VRF) and resolves the next hop onto the IGP-based MPLS tunnel to
PE2.
In order to cope with the reality of current deployments, the SPRING To cope with the reality of current deployments, the SPRING
architecture MUST 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 the The packet each PE forwards across the network will contain the
necessary information derived from the topology database in order to necessary information derived from the 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 (Fast Reroute) technologies have been deployed by network Fast Reroute (FRR) technologies have been deployed by network
operators in order to cope with link or node failures through pre- operators in order to cope with link or node failures through
computation of backup paths. precomputation of backup paths.
Illustration of the problem statement for FRR and microloop avoidance Illustration of the problem statement for FRR and micro-loop
are to be found in [I-D.ietf-spring-resiliency-use-cases]. avoidance can be found in [SPRING-RESIL].
The SPRING architecture MUST 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 precomputation 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 micro-loop avoidance
3.3. Traffic Engineering 3.3. Traffic Engineering
Traffic Engineering (TE) is the term used to refer to techniques that Traffic Engineering (TE) is the term used to refer to techniques that
enable operators to control how specific traffic flows are treated enable operators to control how specific traffic flows are treated
within their networks. Different contexts and modes have been within their networks. Different contexts and modes have been
defined (single vs. multiple domains, with or without bandwidth defined (single vs. multiple domains, with or without bandwidth
admission control, centralized vs. distributed path computation, admission control, centralized vs. distributed path computation,
etc). etc.).
Some deployments have a limited use of TE such as addressing specific Some deployments have a limited use of TE, such as addressing
application or customer requirements or address specific bandwidth specific application or customer requirements, or addressing specific
limitation in the network (tactical TE). In this situation, there is bandwidth limitations in the network (tactical TE). In these
need to reduce as much of possible the cost (such as the number of situations, there is a need to reduce, as much as possible, the cost
signaling protocols and the number of nodes requiring specific (such as the number of signaling protocols and the number of nodes
configurations/features. Some other deployments have a very high requiring specific configurations/features). Some other deployments
scale use of TE, such as fine tuning flows at the application level. have a very high-scale use of TE, such as fine tuning flows at the
In this situation, there is a need for a very high scalability, in application level. In this situation, there is a need for very high
particular on mid-points. scalability, in particular on midpoints.
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 for a signaling component.
The SPRING architecture MUST support the following traffic The SPRING architecture MUST support the following traffic-
engineering requirements: 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 (e.g., Path Computation Element
[I-D.ietf-pce-stateful-pce], SDN Controller) (PCE) [STATEFUL-PCE], Software-Defined Networking (SDN)
Controller)
o disjointness in dual-plane networks o disjointness in dual-plane networks
o egress peering traffic engineering o egress peer engineering
o load-balancing among non-parallel links (i.e.: links connected to o load balancing among non-parallel links (i.e., links connected to
different adjacent neighbors). different adjacent neighbors).
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 In most cases, traffic engineering makes use of the "loose" route
option where most of the explicit paths can be expressed through a option where most of the explicit paths can be expressed through a
small number of hops. However, there are use cases where the small number of hops. However, there are use cases where the
"strict" option may be used and, in such case, each individual hop in "strict" option may be used and, in such cases, each individual hop
the explicit path is specified. This may incur into a long list of in the explicit path is specified. This may result in a long list of
hops that is instantiated into a MPLS label stack (in the MPLS hops that is instantiated into a MPLS label stack (in the MPLS data
dataplane) or list of IPv6 addresses (in the IPv6 dataplane). plane) or list of IPv6 addresses (in the IPv6 data plane).
It is obvious that in case of long strict source routing paths, the It is obvious that, in the case of long, strict source-routed paths,
deployment is possible if the head-end of the explicit path supports the deployment is possible if the head-end of the explicit path
the instantiation of long explicit paths. supports the instantiation of long explicit paths.
Alternatively, a controller could decompose the end-to-end path into 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 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. its respective head-end and advertised with a single identifier.
Hence, the concatenation (or stitching) of the sub-paths identifiers Hence, the concatenation (or stitching) of the sub-paths identifiers
gives a compression scheme allowing an end-to-end path to be gives a compression scheme allowing an end-to-end path to be
expressed in a smaller number of hops. 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: Below are descriptions 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
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.
3.3.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 aggregation region k is connected to the core by Each aggregation region k is connected to the core by two C
two C routers C1k and C2k where k refers to the region. routers C1k and C2k, where k refers to the region.
C1k is part of plane 1 and aggregation region k C1k is part of plane 1 and aggregation region k
C2k is part of plane 2 and aggregation region k C2k is part of plane 2 and aggregation region k
C1k has a link to C2j 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.
{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 Autonomous System (AS). The
above specifies that these links appear in both core planes. design rule presented 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 plane link costs (Cik - Cjk, where i != j) are set such that the
to an edge destination from a given plane stays within the plane route to an edge destination from a given plane stays within the
unless the plane is partitioned. plane unless the plane is partitioned.
Edge Router A Edge Router A
/ \ / \
/ \ / \
/ \ Agg Region A / \ Agg Region A
/ \ / \
/ \ / \
C1A----------C2A C1A----------C2A
| \ | \ | \ | \
| \ | \ | \ | \
skipping to change at page 8, line 33 skipping to change at page 8, line 49
\ / \ /
\ / \ /
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.
o the traffic is load-balanced across any ECMP path within the o The traffic is load-balanced across any ECMP path within Plane1 of
Plane1 of the network 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 Plane2 of
Plane2 of the network 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, so
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 MUST support this use case with the following The SPRING architecture MUST support this use case with the 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 |\ +------+ +---------+ / | AS2 |\ +------+
| |/ +------+ \| Z | | |/ +------+ \| Z |
A C | | A C | |
| |\ +------+ /| AS 4 | | |\ +------+ /| AS4 |
B AS1 | \ | |/ +------+ B AS1 | \ | |/ +------+
| | +---E G | | +---E G
+---------+ | AS 3 | +---------+ | AS3 |
+------+\ +------+\
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 o C in AS1 learns about destination Z of AS4 via two BGP paths (AS2,
(AS2, AS4) and (AS3, AS4). AS4) and (AS3, AS4).
C may or may not be configured so to enforce next-hop-self o C may or may not be configured to enforce the 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, o C may propagate all the paths to Z within AS1 (using BGP ADD-PATH
[I-D.ietf-idr-add-paths]). as specified in [ADD-PATH]).
C may install in its FIB only the route via AS2, or only the route o C may install in its Forwarding Information Base (FIB) only the
via AS3, or both. route via AS2, or only the route via AS3, or both.
In that context, the SPRING architecture MUST 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 of the configured behavior of the next-hop-self:
Steer 60% of the Z-destined traffic received at A via AS2 and 40% o 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% o Steer 80% of the Z-destined traffic received at B via AS2 and 20%
via AS3. via AS3.
The SPRING architecture MUST allow an ingress node (i.e., an explicit The SPRING architecture MUST allow an ingress node (i.e., an explicit
route source node) to select the exit point of a packet as any route source node) to select the exit point of a packet as 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 [SR-BGP-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 MUST allow a given node to load share traffic The SPRING architecture MUST allow a given node to load-share 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 for supporting 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 MUST 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 Multipath
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
explicit paths where the bandwidth is available) requires a capacity along explicit paths where the bandwidth is available) requires a
planning process. capacity-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.
3.3.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.
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 1600 Mbps
A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, A-to-Z flow is accounted as consuming 1600 Mbps on links AB and FZ;
800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 800 Mbps on links BC, BG, and GF; and 400 Mbps on links CD, DF, CE,
EF. and 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 Service Provider (SP), enterprise, and
it is not rare to see as much as 128 different ECMP paths between a data-center architectures and it is not rare to see as much as 128
source and a destination within a single network domain. It is a key different ECMP paths between a source and a destination within a
efficiency objective to spread the traffic among as many ECMP paths single network domain. It is a key efficiency objective to spread
as possible. the traffic among as many ECMP paths as possible.
This is illustrated in the below network diagram which consists of a This is illustrated in the network diagram below, 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, and then to compute an explicit
for each of them and instantiating these traffic-engineered policies path for each of them and instantiate these traffic-engineered
in the network. policies in the network.
The SPRING architecture MUST 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 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 [STATEFUL-PCE]).
The SDN controller is responsible to control the evolution of the The SDN controller is responsible for controlling the evolution of
traffic matrix and topology. It accepts or denies the addition of the traffic matrix and topology. It accepts or denies the addition
new traffic into the network. It decides how to route the accepted of new traffic into the network. It decides how to route the
traffic. It monitors the topology and upon topological change, accepted traffic. It monitors the topology and, upon topological
determines the minimum traffic that should be rerouted on an change, 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.
The algorithms supporting this behavior are a local matter of the SDN The algorithms supporting this behavior are a local matter of the SDN
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. 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 optimization and the SDN use case, the
case, here are the functionalities that the SPRING architecture MUST SPRING architecture MUST have the following attributes:
deliver:
Explicit routing capability with or without ECMP-awareness. o Explicit routing capability with or without ECMP-awareness.
No signaling hop-by-hop through the network. o No signaling hop-by-hop through the network.
Policy state is only maintained at the policy head-end. No policy o The policy state is only maintained at the policy head-end. No
state is maintained at mid-points and tail-ends. policy state is maintained at midpoints and tail-ends.
Automated guaranteed FRR for any topology. o Automated guaranteed FRR for any topology.
The policy state is in the packet header and not in the o The policy state is in the packet header and not in the
intermediate nodes along the path. The policy is absent from intermediate nodes along the path. The policy is absent from
midpoints and tail-ends. midpoints and tail-ends.
Highly responsive to change: the SDN Controller only needs to o 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 interoperate with non-SPRING nodes and in both MPLS
MPLS and IPv6 dataplanes in order to allow a gradual deployment of and IPv6 data planes in order to allow a gradual deployment of SPRING
SPRING on existing MPLS and IPv6 networks. on existing MPLS and IPv6 networks.
4. Security Considerations 4. Security Considerations
SPRING reuses the concept of source routing by encoding the path in SPRING reuses the concept of source routing by encoding the path in
the packet. As with other similar source routing architecture, an the packet. As with other similar source-routing architecture, an
attacker may manipulate traffic path by modifying the packet header. attacker may manipulate the traffic path by modifying the packet
By manipulating traffic path, an attacker may be able to cause header. By manipulating the traffic path, an attacker may be able to
outages on any part of the network. cause outages on any part of the network.
SPRING adds some meta-data on the packet, with the list of forwarding SPRING adds some metadata on the packet, with the list of forwarding
path elements that the packet must traverse. Depending on the data path elements that the packet must traverse. Depending on the data
plane, this list may shrink as the packet traverse the network, by plane, this list may shrink as the packet traverses the network, by
only keeping the next elements and forgetting the past ones. keeping only the next elements and forgetting the past ones.
SPRING architecture MUST provide clear trust domain boundaries, so SPRING architecture MUST provide clear trust domain boundaries so
that source routing information is only usable within the trusted that source-routing information is only usable within the trusted
domain and never exposed to the outside world. domain and never exposed to the outside world.
From a network protection standpoint, there is an assumed trust model From a network protection standpoint, there is an assumed trust model
such that any node imposing an explicit route on a packet is assumed 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 to be allowed to do so. This is a significant change compared to
plain IP offering shortest path routing but not fundamentally plain IP offering the shortest-path routing, but not fundamentally
different compared to existing techniques providing explicit routing different compared to existing techniques providing explicit routing
capability. It is expected that, by default, the explicit routing capability. It is expected that, by default, the explicit routing
information is not leaked through the boundaries of the administered information is not leaked through the boundaries of the administered
domain. domain.
Therefore, the dataplane MUST NOT expose any source routing Therefore, the data plane MUST NOT expose any source-routing
information when a packet leaves the trusted domain. Special care information when a packet leaves the trusted domain. Special care
will be required for the existing dataplanes like MPLS, especially will be required for the existing data planes like MPLS, especially
for the inter-provider scenario where a third-party provider may push for the inter-provider scenario where a third-party provider may push
MPLS labels corresponding to a SPRING header anywhere in the stack. MPLS labels corresponding to a SPRING header anywhere in the stack.
The architecture document MUST analyze the exact security The architecture document MUST analyze the exact security
considerations of such scenario. considerations of such a scenario.
Filtering routing information is typically performed in the control Filtering routing information is typically performed in the control
plane, but an additional filtering in the forwarding plane is also plane, but an additional filtering in the forwarding plane is also
required. In SPRING, as there is no control plane (related to source required. In SPRING, as there is no control plane (related to
routed paths) between the source and the mid points, filtering in the source-routed paths) between the source and the midpoints, filtering
control plane is not possible (or not required, depending on the in the control plane is not possible (or not required, depending on
point of view). Filtering MUST be performed on the forwarding plane the point of view). Filtering MUST be performed on the forwarding
on the boundaries and MAY require looking at multiple labels/ plane on the boundaries and MAY require looking at multiple labels or
instruction. instructions.
For the MPLS data plane, this not a new requirement as the existing For the MPLS data plane, this is not a new requirement as the
MPLS architecture already allow such source routing by stacking existing MPLS architecture already allows such source routing by
multiple labels. And for security protection, RFC4381 section 2.4 stacking multiple labels. For security protection, Section 2.4 of
and RFC 5920 section 8.2 already calls for the filtering of MPLS [RFC4381] and Section 8.2 of [RFC5920] already call for the filtering
packets on trust boundaries. of MPLS packets on trust boundaries.
If all MPLS labels are filtered at domain boundaries, then SPRING If all MPLS labels are filtered at domain boundaries, then SPRING
does not introduce any change. If only a subset of labels are does not introduce any change. If only a subset of labels are
filtered, then SPRING introduces a change since the border router is filtered, then SPRING introduces a change since the border router is
expected to determine which information (e.g.: labels) are filtered expected to determine which information (e.g., labels) is filtered,
while the border router is not the originator of these label while the border router is not the originator of these label
advertisements. advertisements.
As the SPRING architecture must be based on clear trust domain, As the SPRING architecture must be based on a clear trust domain,
mechanisms allowing the authentication and validation of the source mechanisms allowing the authentication and validation of the source-
routing information must be evaluated by the SPRING architecture in routing information must be evaluated by the SPRING architecture in
order to prevent any form of attack or unwanted source routing order to prevent any form of attack or unwanted source-routing
information manipulation. information manipulation.
Dataplane security considerations MUST be addressed in each SPRING Data-plane security considerations MUST be addressed in each document
dataplane related document (i.e.: MPLS and IPv6). related to the SPRING data plane (i.e., MPLS and IPv6).
The IPv6 data plane proposes the use of a cryptographic signature of The IPv6 data plane proposes the use of a cryptographic signature of
the source routed path which would ease this configuration. This is 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 indeed needed more for the IPv6 data plane, which is end to end in
nature, compared to the MPLS data plane which is typically restricted nature, compared to the MPLS data plane, which is typically
to a controlled and trusted zone. restricted to a controlled and trusted zone.
In the forwarding plane, data plane extension documents MUST address In the forwarding plane, data-plane extension documents MUST address
the security implications of the required change. the security implications of the required change.
In term of privacy, SPRING does not propose change in term of In terms of privacy, SPRING does not propose change in terms of
encryption. Each dataplane, may or may not provide existing or encryption. Each data plane may or may not provide existing or
future encryption capability. future encryption capability.
In order to build the source routing information in the packet, a To build the source-routing information in the packet, a node in the
node in SPRING architecture will require learning information from a SPRING architecture will require learning information from a control
control layer. As this control layer will be in charge of layer. As this control layer will be in charge of programming
programming forwarding instructions, an attacker taking over this forwarding instructions, an attacker taking over this component may
component may also manipulate the traffic path. Any control protocol also manipulate the traffic path. Any control protocol used in the
used in the SPRING architecture SHOULD provide security mechanisms or SPRING architecture SHOULD provide security mechanisms or design to
design to protect against such control layer attacker. Control plane protect against such a control-layer attacker. Control-plane
security considerations MUST be addressed in each SPRING control security considerations MUST be addressed in each document related to
plane related document. the SPRING control plane.
5. IANA Considerations
This document does not request any IANA allocations.
6. Manageability Considerations 5. Manageability Considerations
The SPRING WG MUST define Operations and Management (OAM) procedures The SPRING WG MUST define Operations, Administration, and Maintenance
applicable to SPRING enabled networks. (OAM) procedures applicable to SPRING-enabled networks.
In SPRING networks, the path the packet takes is encoded in the In SPRING networks, the path the packet takes is encoded in the
header. SPRING architecture MUST include the necessary OAM header. SPRING architecture MUST include the necessary OAM
mechanisms in order for the network operator to validate the mechanisms in order for the network operator to validate the
effectiveness of a path as well as to check and monitor its liveness effectiveness of a path as well as to check and monitor its liveness
and performance. Moreover, in SPRING architecture, a path may be and performance. Moreover, in SPRING architecture, a path may be
defined in the forwarding layer (in both MPLS and IPv6 dataplanes) or defined in the forwarding layer (in both MPLS and IPv6 data planes)
as a service path (formed by a set of service instances). The 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 operator MUST be capable to monitor, control, and manage
(network and service based) using OAM procedures. paths (both 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
The following individuals substantially contributed to the content of
this documents:
Ruediger Geib
Deutsche Telekom
Heinrich Hertz Str. 3-7
Darmstadt 64295
DE
Email: Ruediger.Geib@telekom.de
Robert Raszuk
Mirantis Inc.
615 National Ave.
94043 Mt View, CA
US
Email: robert@raszuk.net
8. Acknowledgements
The authors would like to thank Yakov Rekhter for his contribution to OAM use cases and requirements are detailed in [OAM-USE] and
this document. [SR-OAM].
9. References 6. References
9.1. Normative References 6.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, 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>.
skipping to change at page 16, line 42 skipping to change at page 16, line 37
[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>.
[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 6.2. Informative References
[I-D.ietf-6man-segment-routing-header] [ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder,
Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, "Advertisement of Multiple Paths in BGP", Work in
J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment Progress, draft-ietf-idr-add-paths-14, April 2016.
Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-01 (work in progress), March 2016.
[I-D.ietf-idr-add-paths] [OAM-USE] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Walton, D., Retana, A., Chen, E., and J. Scudder, Kumar, "A Scalable and Topology-Aware MPLS Dataplane
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- Monitoring System", Work in Progress, draft-ietf-spring-
add-paths-13 (work in progress), December 2015. oam-usecase-03, April 2016.
[I-D.ietf-pce-stateful-pce] [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Virtual Private Networks (VPNs)", RFC 4381,
Extensions for Stateful PCE", draft-ietf-pce-stateful- DOI 10.17487/RFC4381, February 2006,
pce-14 (work in progress), March 2016. <http://www.rfc-editor.org/info/rfc4381>.
[I-D.ietf-spring-oam-usecase] [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
Case for a Scalable and Topology-Aware Segment Routing <http://www.rfc-editor.org/info/rfc5920>.
MPLS Data Plane Monitoring System", draft-ietf-spring-oam-
usecase-01 (work in progress), October 2015.
[I-D.ietf-spring-resiliency-use-cases] [SPRING-RESIL]
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", Work in Progress,
resiliency-use-cases-03 (work in progress), April 2016. draft-ietf-spring-resiliency-use-cases-03, April 2016.
[I-D.ietf-spring-segment-routing-central-epe] [SR-BGP-EPE]
Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, Filsfils, C., Ed., Previdi, S., Ed., Ginsburg, D., and D.
"Segment Routing Centralized BGP Peer Engineering", draft- Afanasiev, "Segment Routing Centralized BGP Peer
ietf-spring-segment-routing-central-epe-01 (work in Engineering", Work in Progress, draft-ietf-spring-segment-
progress), March 2016. routing-central-epe-01, March 2016.
[I-D.ietf-spring-sr-oam-requirement] [SR-OAM] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
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-ietf-spring-sr-oam-requirement-01 (work in Network", Work in Progress, draft-ietf-spring-sr-oam-
progress), December 2015. requirement-01, December 2015.
[SRH] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
Routing Header (SRH)", Work in Progress, draft-ietf-6man-
segment-routing-header-01, March 2016.
[STATEFUL-PCE]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", Work in Progress,
draft-ietf-pce-stateful-pce-14, March 2016.
Acknowledgements
The authors would like to thank Yakov Rekhter for his contribution to
this document.
Contributors
The following individuals substantially contributed to the content of
this document:
Ruediger Geib
Deutsche Telekom
Heinrich Hertz Str. 3-7
Darmstadt 64295
Germany
Email: Ruediger.Geib@telekom.de
Robert Raszuk
Mirantis Inc.
615 National Ave.
94043 Mountain View, CA
United States
Email: robert@raszuk.net
Authors' Addresses 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
skipping to change at page 18, line 4 skipping to change at page 18, line 40
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
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Bruno Decraene Bruno Decraene
Orange Orange
FR France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Stephane Litkowski Stephane Litkowski
Orange Orange
FR France
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226
Muenster 48153 Muenster 48153
DE Germany
Email: Martin.Horneffer@telekom.de Email: Martin.Horneffer@telekom.de
Rob Shakir Rob Shakir
Jive Communications, Inc. Jive Communications, Inc.
1275 West 1600 North, Suite 100 1275 West 1600 North, Suite 100
Orem, UT 84057 Orem, UT 84057
United States
Email: rjs@rob.sh Email: rjs@rob.sh
 End of changes. 151 change blocks. 
352 lines changed or deleted 354 lines changed or added

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