draft-previdi-spring-problem-statement-02.txt   draft-previdi-spring-problem-statement-03.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: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: October 6, 2014 B. Decraene Expires: October 20, 2014 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
R. Geib R. Geib
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
British Telecom British Telecom
R. Raszuk R. Raszuk
Individual Individual
April 4, 2014 April 18, 2014
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-previdi-spring-problem-statement-02 draft-previdi-spring-problem-statement-03
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'.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 6, 2014. This Internet-Draft will expire on October 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . . 5 3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . 4
3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 5 3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 4
4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 6 5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 5
5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 7 5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 6
5.1.1. Traffic Engineering without Bandwidth Admission 5.1.1. Traffic Engineering without Bandwidth Admission
Control . . . . . . . . . . . . . . . . . . . . . . . 7 Control . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Traffic Engineering with Bandwidth Admission 5.1.2. Traffic Engineering with Bandwidth Admission Control 10
Control . . . . . . . . . . . . . . . . . . . . . . . 11 6. Interoperability with non-SPRING nodes . . . . . . . . . . . 13
6. Interoperability with non-SPRING nodes . . . . . . . . . . . . 14 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Manageability Considerations . . . . . . . . . . . . . . . . 14
10. Manageability Considerations . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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
Network, link, path and node protection such as fast re-route Network, link, path and node protection such as fast re-route
Network programmability Network programmability
OAM techniques OAM techniques
Simplification and reduction of network signaling components Simplification and reduction of network signaling components
Load balancing and traffic engineering Load balancing and traffic engineering
The term 'source' means 'the point at which the explicit route is Source-based routing mechanisms have previously been specified for
imposed'. network protocols, but have not seen widespread adoption other than
in MPLS traffic engineering.
These network functions may require greater flexibility and per
packet source imposed routing than can be achieved through the use of
the previously defined methods. In the context of this charter,
'source' means 'the point at which the explicit route is imposed'.
In this context, Source Packet Routing in Networking (SPRING) In this context, Source Packet Routing in Networking (SPRING)
architecture is being defined so as 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 SPRING architecture should allow incremental and selective deployment
without any requirement of flag day or massive upgrade of all network without any requirement of flag day or massive upgrade of all network
elements. elements.
SPRING architecture should allow optimal virtualization: put policy SPRING architecture should allow optimal virtualization: put policy
state in the packet header and not in the intermediate nodes along state in the packet header and not in the intermediate nodes along
the path. Hence, the policy is completely virtualized away from the path. Hence, the policy is completely virtualized away from
midpoints and tail-ends. midpoints and tail-ends.
SPRING architecture objective is not to replace existing source
routing and traffic engineering mechanisms but rather complement them
and address use cases where removal of signaling and path state in
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 MPLS dataplane doesn't require any modification in order to apply a
source-based routed model (e.g.: source-based routed model (e.g.:
[I-D.filsfils-spring-segment-routing-mpls]). [I-D.filsfils-spring-segment-routing-mpls]).
IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045], 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 existing MPLS dataplane
without any modification and leverage IPv6 dataplane with minor without any modification and leverage IPv6 dataplane with a new IPv6
modifications. Routing Header Type (IPv6 Routing Header is defined in [RFC2460]).
3. IGP-based MPLS Tunneling 3. 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 ability to tunnel unicast services (VPN, VPLS, VPWS) from an
ingress PE to an egress PE, with or without the expression of an
explicit path and without requiring forwarding plane or control plane
state in intermediate nodes. p2mp and mp2mp tunnels are out of the
scope of this document.
3.1. Example of IGP-based MPLS Tunnels 3.1. Example of IGP-based MPLS Tunnels
This section illustrates an example use-case taken from This section illustrates an example use-case taken from
[I-D.filsfils-spring-segment-routing-use-cases]. [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. PE1 installs the VPN prefix Z in
the appropriate VRF and resolves the next-hop onto the node segment the appropriate VRF and resolves the next-hop onto the node segment
associated with PE2. 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
skipping to change at page 8, line 27 skipping to change at page 8, line 4
{C(1,k) has a link to C(1, j)} iff {C(2,k) has a link to C(2, j)}. {C(1,k) has a link to C(1, j)} iff {C(2,k) has a link to C(2, j)}.
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.
Edge Router A
/ \ Edge Router A
/ \ / \
/ \ Agg Region A / \
/ \ / \ Agg Region A
/ \ / \
C1A----------C2A / \
| \ | \ C1A----------C2A
| \ | \ | \ | \
| C1B----------C2B | \ | \
Plane1 | | | | Plane2 | C1B----------C2B
| | | | Plane1 | | | | Plane2
C1C--|-----C2C | | | | |
\ | \ | C1C--|-----C2C |
\ | \ | \ | \ |
C1Z----------C2Z \ | \ |
\ / C1Z----------C2Z
\ / Agg Region Z \ /
\ / \ / Agg Region Z
\ / \ /
Edge Router Z \ /
Edge Router Z
Figure 2: Dual-Plane Network and Disjointness Figure 2: Dual-Plane Network and Disjointness
In this scenario, the operator requires the ability to deploy In this scenario, the operator requires the ability to deploy
different strategies. For example, A should be able to use the three different strategies. For example, A should be able to use the three
following options: following options:
o the traffic is load-balanced across any ECMP path through the o the traffic is load-balanced across any ECMP path through the
network network
skipping to change at page 9, line 33 skipping to change at page 9, line 12
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 5.1.1.2. Egress Peering Traffic Engineering
+------+
| |
+---D F
+---------+ / | AS 2 |\ +------+
| |/ +------+ \| Z |
A C | |
| |\ +------+ /| AS 4 |
B AS1 | \ | |/ +------+
| | +---E G
+---------+ | AS 3 |
+------+\
Figure 3: Egress peering traffic engineering +------+
| |
Let us assume, in the network depicted in Figure 3, that: +---D F
+---------+ / | AS 2 |\ +------+
C in AS1 learns about destination Z of AS 4 via two BGP paths | X |/ +------+ \ | Z |---L/8
(AS2, AS4) and (AS3, AS4). A C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8
C may or may not be configured so to enforce next-hop-self | AS1 | \\ +-H |/ +------+
behavior before propagating the paths within AS1. | | \\ | G
+----P----+ +===E AS 3 |
C propagates all the paths to Z within AS1 (add-path). | +--Q---+
| |
C only installs the path via AS2 in its RIB. +----------------+
In that context, SPRING should allow the operator of AS1 to apply the
following traffic-engineering policy, regardless the configured
behavior of next-hop-self:
Steer 60% of the Z-destined traffic received at A via AS2 and 40%
via AS3.
Steer 80% of the Z-destined traffic received at B via AS2 and 20%
via AS3.
While egress routers are known in the routing domain (generally Figure 3: Reference Diagram
through their loopback address), the SPRING architecture should
enable following:
o identify the egress interfaces of an egress node Assuming the topology illustrated in the diagram above, a solution is
required to allow a centralized controller to force an ingress PE or
a content source to use a specific egress PE and a specific egress
interface of that egress PE to reach some destination. We call this
solution "EPE" for "Egress Peer Engineering".
o identify the peering neighbors of an egress node For example, the solution MUST provide a mechanism in order to
instruct node A to prefer C-H link for destination L/8 and prefer the
parallel links between C and E for destination M/8.
o identify the peering ASes of an egress node The solution MUST apply to the Internet use-case where the Internet
routes are assumed to use IPv4 unlabeled. The solution MUST NOT
require to place the internet routes in a VRF and allocate labels on
a per route, per-path basis.
With these identifiers known in the domain, the SPRING architecture The solution MUST NOT make assumption in the way iBGP scheme is
should allow an ingress node to select the exit point of a packet as deployed (RRs, Confederations or iBGP full mesh).
any combination of an egress node, an egress interface, a peering
neighbor, and a peering AS.
5.1.1.3. Load-balancing among non-parallel links 5.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 should be able to
load share traffic across multiple non parallel links even if these load share traffic across multiple non parallel links even if these
ones lead to different neighbors. This may be useful to support ones lead to different neighbors. This may be useful to support
traffic engineering policies. traffic 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 5.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
skipping to change at page 11, line 34 skipping to change at page 10, line 40
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 1600Mbps
A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ,
800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and
EF. EF.
C-----D
/ \ \ C-----D
A---B +--E--F--Z / \ \
\ / A---B +--E--F--Z
G------+ \ /
G------+
Figure 5: Capacity Planning an ECMP-based demand Figure 5: Capacity Planning an ECMP-based demand
ECMP is extremely frequent in SP, Enterprise and DC architectures and ECMP is extremely frequent in SP, Enterprise and DC architectures and
it is not rare to see as much as 128 different ECMP paths between a it is not rare to see as much as 128 different ECMP paths between a
source and a destination within a single network domain. It is a key source and a destination within a single network domain. It is a key
efficiency objective to spread the traffic among as many ECMP paths efficiency objective to spread the traffic among as many ECMP paths
as possible. as possible.
This is illustrated in the below network diagram which consists of a This is illustrated in the below network diagram which consists of a
subset of a network where already 5 ECMP paths are observed from A to subset of a network where already 5 ECMP paths are observed from A to
M. M.
C C
/ \ / \
B-D-L-- B-D-L--
/ \ / \ / \ / \
A E \ A E \
\ M \ M
\ G / \ G /
\ / \ / \ / \ /
F K F K
\ / \ /
I I
Figure 6: ECMP Topology Example Figure 6: ECMP Topology Example
When the capacity planning process detects that a traffic growth When the capacity planning process detects that a traffic growth
scenario and topology variation would lead to congestion, a capacity scenario and topology variation would lead to congestion, a capacity
increase is triggered and if it cannot be deployed in due time, a increase is triggered and if it cannot be deployed in due time, a
traffic engineering solution is activated within the network. traffic engineering solution is activated within the network.
A basic traffic engineering objective consists of finding the A basic traffic engineering objective consists of finding the
smallest set of demands that need to be routed off their shortest smallest set of demands that need to be routed off their shortest
skipping to change at page 13, line 7 skipping to change at page 12, line 14
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.
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 (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.sivabalan-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 benefits that the SPRING architecture should
deliver: deliver:
skipping to change at page 16, line 18 skipping to change at page 15, line 21
[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.
[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, Exchange of Flow Information", STD 77, RFC 7011, September
September 2013. 2013.
[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.
13.2. Informative References 13.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-rtgwg-segment-routing] [I-D.filsfils-rtgwg-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", "Segment Routing Architecture", draft-filsfils-rtgwg-
draft-filsfils-rtgwg-segment-routing-01 (work in segment-routing-01 (work in progress), October 2013.
progress), October 2013.
[I-D.filsfils-spring-segment-routing-ldp-interop] [I-D.filsfils-spring-segment-routing-ldp-interop]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing interoperability with LDP", "Segment Routing interoperability with LDP", draft-
draft-filsfils-spring-segment-routing-ldp-interop-00 (work filsfils-spring-segment-routing-ldp-interop-00 (work in
in progress), October 2013. progress), October 2013.
[I-D.filsfils-spring-segment-routing-mpls] [I-D.filsfils-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing with MPLS data plane", "Segment Routing with MPLS data plane", draft-filsfils-
draft-filsfils-spring-segment-routing-mpls-00 (work in spring-segment-routing-mpls-00 (work in progress), October
progress), October 2013. 2013.
[I-D.filsfils-spring-segment-routing-use-cases] [I-D.filsfils-spring-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B., Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", Crabbe, "Segment Routing Use Cases", draft-filsfils-
draft-filsfils-spring-segment-routing-use-cases-00 (work spring-segment-routing-use-cases-00 (work in progress),
in progress), March 2014. March 2014.
[I-D.francois-spring-resiliency-use-case] [I-D.francois-spring-resiliency-use-case]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir, Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
"Use-cases for Resiliency in SPRING", "Use-cases for Resiliency in SPRING", draft-francois-
draft-francois-spring-resiliency-use-case-01 (work in spring-resiliency-use-case-02 (work in progress), April
progress), April 2014. 2014.
[I-D.geib-spring-oam-usecase] [I-D.geib-spring-oam-usecase]
Geib, R. and C. Filsfils, "Use case for a scalable and Geib, R. and C. Filsfils, "Use case for a scalable and
topology aware MPLS data plane monitoring system", topology aware MPLS data plane monitoring system", draft-
draft-geib-spring-oam-usecase-01 (work in progress), geib-spring-oam-usecase-01 (work in progress), February
February 2014. 2014.
[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-02 (work in System", draft-ietf-i2rs-architecture-02 (work in
progress), February 2014. progress), February 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-04 Information using BGP", draft-ietf-idr-ls-distribution-04
(work in progress), November 2013. (work in progress), November 2013.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
Extensions for Stateful PCE", Extensions for Stateful PCE", draft-ietf-pce-stateful-
draft-ietf-pce-stateful-pce-08 (work in progress), pce-08 (work in progress), February 2014.
February 2014.
[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., and G.
Mirsky, "OAM Requirements for Segment Routing Network", Mirsky, "OAM Requirements for Segment Routing Network",
draft-kumar-spring-sr-oam-requirement-00 (work in draft-kumar-spring-sr-oam-requirement-00 (work in
progress), February 2014. progress), February 2014.
[I-D.sivabalan-pce-segment-routing] [I-D.sivabalan-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and
R. Raszuk, "PCEP Extensions for Segment Routing", R. Raszuk, "PCEP Extensions for Segment Routing", draft-
draft-sivabalan-pce-segment-routing-02 (work in progress), sivabalan-pce-segment-routing-02 (work in progress),
October 2013. October 2013.
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 BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Bruno Decraene Bruno Decraene
Orange Orange
FR FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
 End of changes. 36 change blocks. 
148 lines changed or deleted 149 lines changed or added

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