draft-ietf-spring-problem-statement-05.txt   draft-ietf-spring-problem-statement-06.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils, Ed. Internet-Draft C. Filsfils, Ed.
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: April 21, 2016 B. Decraene Expires: June 16, 2016 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
R. Shakir R. Shakir
Jive Communications Jive Communications
October 19, 2015 December 14, 2015
SPRING Problem Statement and Requirements SPRING Problem Statement and Requirements
draft-ietf-spring-problem-statement-05 draft-ietf-spring-problem-statement-06
Abstract Abstract
The ability for a node to specify a forwarding path, other than the The ability for a node to specify a forwarding path, other than the
normal shortest path, that a particular packet will traverse, normal shortest path, that a particular packet will traverse,
benefits a number of network functions. Source-based routing benefits a number of network functions. Source-based routing
mechanisms have previously been specified for network protocols, but mechanisms have previously been specified for network protocols, but
have not seen widespread adoption. In this context, the term have not seen widespread adoption. In this context, the term
'source' means 'the point at which the explicit route is imposed' and 'source' means 'the point at which the explicit route is imposed' and
therefore it is not limited to the originator of the packet (i.e.: therefore it is not limited to the originator of the packet (i.e.:
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016. This Internet-Draft will expire on June 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . 4 3.1. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . 4
3.1.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . 4 3.1.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . 4
3.2. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 5
3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5 3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5
3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 6 3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 6
3.4. Interoperability with non-SPRING nodes . . . . . . . . . 12 3.4. Interoperability with non-SPRING nodes . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Manageability Considerations . . . . . . . . . . . . . . . . 13 6. Manageability Considerations . . . . . . . . . . . . . . . . 13
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 10 skipping to change at page 4, line 10
The SPRING architecture objective is not to replace existing source The SPRING architecture objective is not to replace existing source
routing and traffic engineering mechanisms but rather complement them routing and traffic engineering mechanisms but rather complement them
and address use cases where removal of signaling and path state in and address use cases where removal of signaling and path state in
the core is a requirement. the core is a requirement.
2. Dataplanes 2. Dataplanes
The SPRING architecture SHOULD be general in order to ease its The SPRING architecture SHOULD be general in order to ease its
applicability to different dataplanes. applicability to different dataplanes.
The IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045],
defines the Routing Extension Header which provides IPv6 source-based
routing capabilities.
The SPRING architecture SHOULD leverage the existing MPLS dataplane The SPRING architecture SHOULD leverage the existing MPLS dataplane
without any modification and leverage IPv6 dataplane with a new IPv6 without any modification and leverage IPv6 dataplane with a new IPv6
Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). Routing Header Type (IPv6 Routing Header is defined in [RFC2460]).
3. SPRING Use Cases 3. SPRING Use Cases
3.1. IGP-based MPLS Tunneling 3.1. IGP-based MPLS Tunneling
The source-based routing model, applied to the MPLS dataplane, offers The source-based routing model, applied to the MPLS dataplane, offers
the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE the ability to tunnel services like VPN ([RFC4364]), VPLS ([RFC4761],
to an egress PE, with or without the expression of an explicit path [RFC4762]) and VPWS ([RFC6624]), from an ingress PE to an egress PE,
and without requiring forwarding plane or control plane state in with or without the expression of an explicit path and without
intermediate nodes. requiring forwarding plane or control plane state in intermediate
nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are
The source-based routing model, applied to the MPLS dataplane, offers outside of the scope of this document.
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.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
skipping to change at page 5, line 12 skipping to change at page 5, line 5
PE1 installs the VPN prefix Z in the appropriate VRF and resolves the PE1 installs the VPN prefix Z in the appropriate VRF and resolves the
next-hop onto the node segment associated with PE2. next-hop onto the node segment associated with PE2.
In order to cope with the reality of current deployments, the SPRING In order to cope with the reality of current deployments, the SPRING
architecture SHOULD allow PE to PE forwarding according to the IGP architecture SHOULD allow PE to PE forwarding according to the IGP
shortest path without the addition of any other signaling protocol. shortest path without the addition of any other signaling protocol.
The packet each PE forwards across the network will contain (within The packet each PE forwards across the network will contain (within
their label stack) the necessary information derived from the their label stack) the necessary information derived from the
topology database in order to deliver the packet to the remote PE. topology database in order to deliver the packet to the remote PE.
3.2. Fast Reroute 3.2. Fast Reroute (FRR)
FRR technologies have been deployed by network operators in order to FRR technologies have been deployed by network operators in order to
cope with link or node failures through pre-computation of backup cope with link or node failures through pre-computation of backup
paths. paths.
The SPRING architecture SHOULD address the following requirements: The SPRING architecture SHOULD address the following requirements:
o support of FRR on any topology o support of Fast Reroute (FRR) on any topology
o pre-computation and setup of backup path without any additional o pre-computation and setup of backup path without any additional
signaling (other than the regular IGP/BGP protocols) signaling (other than the regular IGP/BGP protocols)
o support of shared risk constraints o support of shared risk constraints
o support of node and link protection o support of node and link protection
o support of microloop avoidance o support of microloop avoidance
Further illustrations of the problem statement for FRR are to be Further illustrations of the problem statement for FRR are to be
found in [I-D.ietf-spring-resiliency-use-cases]. found in [I-D.ietf-spring-resiliency-use-cases].
3.3. Traffic Engineering 3.3. Traffic Engineering
Traffic Engineering has been addressed using IGP protocol extensions Traffic Engineering has been addressed using IGP protocol extensions
(for resources information propagation) and RSVP-TE for signaling (for resources information propagation) and RSVP-TE for signaling
explicit paths. Different contexts and modes have been defined explicit paths ([RFC5305], [RFC3630], [RFC3209]. Different contexts
(single vs. multiple domains, with or without bandwidth admission and modes have been defined (single vs. multiple domains, with or
control, centralized vs. distributed path computation, etc). without bandwidth admission control, centralized vs. distributed path
computation, etc).
In all cases, one of the major components of the TE architecture is In all cases, one of the major components of the TE architecture is
the soft state based signaling protocol (RSVP-TE) which is used in the soft state based signaling protocol (RSVP-TE) which is used in
order to signal and establish the explicit path. Each path, once order to signal and establish the explicit path. Each path, once
computed, need to be signaled and state for each path must be present computed, need to be signaled and state for each path must be present
in each node traversed by the path. This incurs a scalability in each node traversed by the path. This incurs a scalability
problem especially in the context of SDN where traffic problem especially in the context of SDN where traffic
differentiation may be done at a finer granularity (e.g.: application differentiation may be done at a finer granularity (e.g.: application
specific). Also the amount of state needed to be maintained and specific). Also the amount of state needed to be maintained and
periodically refreshed in all involved nodes contributes periodically refreshed in all involved nodes contributes
skipping to change at page 6, line 17 skipping to change at page 6, line 12
The source-based routing model allows traffic engineering to be The source-based routing model allows traffic engineering to be
implemented without the need of a signaling component. implemented without the need of a signaling component.
The SPRING architecture SHOULD support traffic engineering, The SPRING architecture SHOULD support traffic engineering,
including: including:
o loose or strict options o loose or strict options
o bandwidth admission control o bandwidth admission control
o distributed vs. centralized model (PCE, SDN Controller) o distributed vs. centralized model (PCE
[I-D.ietf-pce-stateful-pce], SDN Controller)
o disjointness in dual-plane networks o disjointness in dual-plane networks
o egress peering traffic engineering o egress peering traffic engineering
o load-balancing among non-parallel links o load-balancing among non-parallel links (i.e.: links connected to
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.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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 access region k is connected to the core by two C routers Each aggregation region k is connected to the core by
C1k and C2k where k refers to the region. two C 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.
skipping to change at page 9, line 32 skipping to change at page 9, line 32
via AS3. via AS3.
Steer 80% of the Z-destined traffic received at B via AS2 and 20% Steer 80% of the Z-destined traffic received at B via AS2 and 20%
via AS3. via AS3.
The SPRING architecture SHOULD allow an ingress node (i.e., an The SPRING architecture SHOULD allow an ingress node (i.e., an
explicit route source node) to select the exit point of a packet as explicit route source node) to select the exit point of a packet as
any combination of an egress node, an egress interface, a peering any 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
described in [I-D.ietf-spring-segment-routing-central-epe].
3.3.1.1.3. Load-balancing among non-parallel links 3.3.1.1.3. Load-balancing among non-parallel links
The SPRING architecture SHOULD allow a given node to load share The SPRING architecture SHOULD allow a given node to load share
traffic across multiple non parallel links even if these lead to traffic across multiple non parallel links (i.e.: links connected to
different neighbors. This may be useful to support traffic different adjacent routers) even if these lead to different
engineering policies. neighbors. This may be useful to support 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 equal-cost paths in a
controlled way where the operator SHOULD be allowed to distribute
traffic unevenly between paths (Weighted Equal Cost Multiplath,
WECMP).
3.3.1.2. Traffic Engineering with Bandwidth Admission Control 3.3.1.2. Traffic Engineering with Bandwidth Admission Control
The implementation of bandwidth admission control within a network The implementation of bandwidth admission control within a network
(and its possible routing consequence which consists in routing along (and its possible routing consequence which consists in routing along
explicit paths where the bandwidth is available) requires a capacity explicit paths where the bandwidth is available) requires a capacity
planning process. planning process.
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.
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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.
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.
[I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and
[I-D.ietf-pce-segment-routing]).
In the context of Centralized-Based Optimization and the SDN use- In the context of Centralized-Based Optimization and the SDN use-
case, here are the functionalities that the SPRING architecture case, here are the functionalities that the SPRING architecture
SHOULD deliver: SHOULD deliver:
Explicit routing capability with or without ECMP-awareness. Explicit routing capability with or without ECMP-awareness.
No signaling hop-by-hop through the network. No signaling hop-by-hop through the network.
State is only maintained at the policy head-end. No state is State is only maintained at the policy head-end. No state is
skipping to change at page 12, line 39 skipping to change at page 12, line 37
and not in the intermediate nodes along the path. The policy is and not in the intermediate nodes along the path. The policy is
completely virtualized away from midpoints and tail-ends. completely virtualized away from midpoints and tail-ends.
Highly responsive to change: the SDN Controller only needs to Highly responsive to change: the SDN Controller only needs to
apply a policy change at the head-end. No delay is introduced due apply a policy change at the head-end. No delay is introduced due
to programming the midpoints and tail-end along the path. to programming the midpoints and tail-end along the path.
3.4. Interoperability with non-SPRING nodes 3.4. Interoperability with non-SPRING nodes
SPRING nodes MUST inter-operate with non-SPRING nodes and in both SPRING nodes MUST inter-operate with non-SPRING nodes and in both
MPLS and IPv6 dataplanes. MPLS and IPv6 dataplanes in order to allow a gradual deployment of
SPRING on existing MPLS and IPv6 networks.
4. Security Considerations 4. Security Considerations
There is an assumed trust model such that the source imposing an There is an assumed trust model such that the source imposing an
explicit route on a packet is assumed to be allowed to do so. In explicit route on a packet is assumed to be allowed to do so. It is
such context trust boundaries should strip explicit routes from a assumed that the default behavior is to strip any internal routing
packet. information from the packet before the packet is forwarded outside
the domain. In such context trust boundaries SHOULD strip explicit
routes from a packet.
For each data plane technology that SPRING specifies, a security For each data plane technology that SPRING specifies, a security
analysis MUST be provided showing how protection is provided against analysis MUST be provided showing how protection is provided against
an attacker disrupting the network by for example, maliciously an attacker disrupting the network by for example, maliciously
injecting SPRING packets. injecting SPRING packets.
5. IANA Considerations 5. IANA Considerations
This document does not request any IANA allocations. This document does not request any IANA allocations.
skipping to change at page 14, line 9 skipping to change at page 14, line 9
[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>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
RFC 6564, DOI 10.17487/RFC6564, April 2012, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc6564>. <http://www.rfc-editor.org/info/rfc3209>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
of IPv6 Extension Headers", RFC 7045, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC7045, December 2013, DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc7045>. <http://www.rfc-editor.org/info/rfc3630>.
9.2. Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[I-D.crabbe-pce-pce-initiated-lsp] [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP LAN Service (VPLS) Using BGP for Auto-Discovery and
Extensions for PCE-initiated LSP Setup in a Stateful PCE Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in <http://www.rfc-editor.org/info/rfc4761>.
progress), October 2013.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<http://www.rfc-editor.org/info/rfc6624>.
9.2. Informative References
[I-D.geib-spring-oam-usecase] [I-D.geib-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
case for a scalable and topology aware MPLS data plane case for a scalable and topology aware MPLS data plane
monitoring system", draft-geib-spring-oam-usecase-06 (work monitoring system", draft-geib-spring-oam-usecase-06 (work
in progress), July 2015. in progress), July 2015.
[I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-09 (work in
progress), March 2015.
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-11 (work in progress), October 2015. add-paths-13 (work in progress), December 2015.
[I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
"PCEP Extensions for Segment Routing", draft-ietf-pce-
segment-routing-06 (work in progress), August 2015.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-11 (work in progress), April 2015. pce-13 (work in progress), December 2015.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir, Francois, P., Filsfils, C., Decraene, B., and r.
"Use-cases for Resiliency in SPRING", draft-ietf-spring- rjs@rob.sh, "Use-cases for Resiliency in SPRING", draft-
resiliency-use-cases-01 (work in progress), March 2015. ietf-spring-resiliency-use-cases-02 (work in progress),
December 2015.
[I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev,
"Segment Routing Centralized Egress Peer Engineering",
draft-ietf-spring-segment-routing-central-epe-00 (work in
progress), October 2015.
[I-D.kumar-spring-sr-oam-requirement] [I-D.kumar-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-kumar-spring-sr-oam-requirement-03 (work Network", draft-kumar-spring-sr-oam-requirement-03 (work
in progress), March 2015. in progress), March 2015.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200 Via Del Serafico, 200
Rome 00142 Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
 End of changes. 29 change blocks. 
84 lines changed or deleted 86 lines changed or added

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