idnits 2.17.1 draft-ietf-spring-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 27, 2015) is 3281 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-04 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-10 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-10 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-03 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-11 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-01 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi, Ed. 3 Internet-Draft C. Filsfils, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: October 29, 2015 B. Decraene 6 S. Litkowski 7 Orange 8 M. Horneffer 9 Deutsche Telekom 10 R. Shakir 11 British Telecom 12 April 27, 2015 14 SPRING Problem Statement and Requirements 15 draft-ietf-spring-problem-statement-04 17 Abstract 19 The ability for a node to specify a forwarding path, other than the 20 normal shortest path, that a particular packet will traverse, 21 benefits a number of network functions. Source-based routing 22 mechanisms have previously been specified for network protocols, but 23 have not seen widespread adoption. In this context, the term 24 'source' means 'the point at which the explicit route is imposed' and 25 therefore it is not limited to the originator of the packet (i.e.: 26 the node imposing the explicit route may be the ingress node of an 27 operator's network). 29 This document outlines various use cases, with their requirements, 30 that need to be taken into account by the Source Packet Routing in 31 Networking (SPRING) architecture for unicast traffic. Multicast use- 32 cases and requirements are out of scope of this document. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on October 29, 2015. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. SPRING Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . 4 78 3.1.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . 4 79 3.2. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . 5 80 3.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 5 81 3.3.1. Examples of Traffic Engineering Use Cases . . . . . . 6 82 3.4. Interoperability with non-SPRING nodes . . . . . . . . . 12 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 6. Manageability Considerations . . . . . . . . . . . . . . . . 13 86 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 9.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 The ability for a node to specify a unicast forwarding path, other 96 than the normal shortest path, that a particular packet will 97 traverse, benefits a number of network functions, for example: 99 Some types of network virtualization, including multi-topology 100 networks and the partitioning of network resources for VPNs 102 Network, link, path and node protection such as fast re-route 104 Network programmability 106 OAM techniques 108 Simplification and reduction of network signaling components 110 Load balancing and traffic engineering 112 Source-based routing mechanisms have previously been specified for 113 network protocols, but have not seen widespread adoption other than 114 in MPLS traffic engineering. 116 These network functions may require greater flexibility and per 117 packet source imposed routing than can be achieved through the use of 118 the previously defined methods. In the context of this document, the 119 term 'source' means 'the point at which the explicit route is 120 imposed' and therefore it is not limited to the originator of the 121 packet (i.e.: the node imposing the explicit route may be the ingress 122 node of an operator's network). Throughout this document we refer to 123 this definition of 'source'. 125 In this context, Source Packet Routing in Networking (SPRING) 126 architecture is being defined in order to address the use cases and 127 requirements described in this document. 129 The SPRING architecture SHOULD allow incremental and selective 130 deployment without any requirement of flag day or massive upgrade of 131 all network elements. 133 The SPRING architecture SHOULD allow optimal virtualization: put 134 policy state in the packet header and not in the intermediate nodes 135 along the path. Hence, the policy is completely virtualized away 136 from midpoints and tail-ends. 138 The SPRING architecture objective is not to replace existing source 139 routing and traffic engineering mechanisms but rather complement them 140 and address use cases where removal of signaling and path state in 141 the core is a requirement. 143 2. Dataplanes 145 The SPRING architecture SHOULD be general in order to ease its 146 applicability to different dataplanes. 148 The IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045], 149 defines the Routing Extension Header which provides IPv6 source-based 150 routing capabilities. 152 The SPRING architecture SHOULD leverage the existing MPLS dataplane 153 without any modification and leverage IPv6 dataplane with a new IPv6 154 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). 156 3. SPRING Use Cases 158 3.1. IGP-based MPLS Tunneling 160 The source-based routing model, applied to the MPLS dataplane, offers 161 the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE 162 to an egress PE, with or without the expression of an explicit path 163 and without requiring forwarding plane or control plane state in 164 intermediate nodes. 166 The source-based routing model, applied to the MPLS dataplane, offers 167 the ability to tunnel unicast services (VPN, VPLS, VPWS) from an 168 ingress PE to an egress PE, with or without the expression of an 169 explicit path and without requiring forwarding plane or control plane 170 state in intermediate nodes. p2mp and mp2mp tunnels are out of the 171 scope of this document. 173 3.1.1. Example of IGP-based MPLS Tunnels 175 This section illustrates an example use-case. 177 P1---P2 178 / \ 179 A---CE1---PE1 PE2---CE2---Z 180 \ / 181 P3---P4 183 Figure 1: IGP-based MPLS Tunneling 185 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 186 same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local 187 label LZ to that route and propagates the route and its label via 188 MPBGP to PE1 with nhop 192.168.0.2 (i.e.: the local address of PE2). 189 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 190 next-hop onto the node segment associated with PE2. 192 In order to cope with the reality of current deployments, the SPRING 193 architecture SHOULD allow PE to PE forwarding according to the IGP 194 shortest path without the addition of any other signaling protocol. 195 The packet each PE forwards across the network will contain (within 196 their label stack) the necessary information derived from the 197 topology database in order to deliver the packet to the remote PE. 199 3.2. Fast Reroute 201 FRR technologies have been deployed by network operators in order to 202 cope with link or node failures through pre-computation of backup 203 paths. 205 The SPRING architecture SHOULD address the following requirements: 207 o support of FRR on any topology 209 o pre-computation and setup of backup path without any additional 210 signaling (other than the regular IGP/BGP protocols) 212 o support of shared risk constraints 214 o support of node and link protection 216 o support of microloop avoidance 218 Further illustrations of the problem statement for FRR are to be 219 found in [I-D.ietf-spring-resiliency-use-cases]. 221 3.3. Traffic Engineering 223 Traffic Engineering has been addressed using IGP protocol extensions 224 (for resources information propagation) and RSVP-TE for signaling 225 explicit paths. Different contexts and modes have been defined 226 (single vs. multiple domains, with or without bandwidth admission 227 control, centralized vs. distributed path computation, etc). 229 In all cases, one of the major components of the TE architecture is 230 the soft state based signaling protocol (RSVP-TE) which is used in 231 order to signal and establish the explicit path. Each path, once 232 computed, need to be signaled and state for each path must be present 233 in each node traversed by the path. This incurs a scalability 234 problem especially in the context of SDN where traffic 235 differentiation may be done at a finer granularity (e.g.: application 236 specific). Also the amount of state needed to be maintained and 237 periodically refreshed in all involved nodes contributes 238 significantly to complexity and the number of failures cases, and 239 thus increases operational effort while decreasing overall network 240 reliability. 242 The source-based routing model allows traffic engineering to be 243 implemented without the need of a signaling component. 245 The SPRING architecture SHOULD support traffic engineering, 246 including: 248 o loose or strict options 250 o bandwidth admission control 252 o distributed vs. centralized model (PCE, SDN Controller) 254 o disjointness in dual-plane networks 256 o egress peering traffic engineering 258 o load-balancing among non-parallel links 260 o Limiting (scalable, preferably zero) per-service state and 261 signaling on midpoint and tail-end routers. 263 o ECMP-awareness 265 o node resiliency property (i.e.: the traffic-engineering policy is 266 not anchored to a specific core node whose failure could impact 267 the service. 269 3.3.1. Examples of Traffic Engineering Use Cases 271 Here follows the description of two sets of use cases: 273 o Traffic Engineering without Admission Control 275 o Traffic Engineering with Admission Control 277 3.3.1.1. Traffic Engineering without Bandwidth Admission Control 279 In this section, we describe Traffic Engineering use-cases without 280 bandwidth admission control. 282 3.3.1.1.1. Disjointness in dual-plane networks 284 Many networks are built according to the dual-plane design, as 285 illustrated in Figure 2: 287 Each access region k is connected to the core by two C routers 288 C1k and C2k where k refers to the region. 290 C1k is part of plane 1 and aggregation region k 292 C2k is part of plane 2 and aggregation region k 294 C1k has a link to C2j iff k = j. 296 The core nodes of a given region are directly connected. 297 Inter-region links only connect core nodes of the same plane. 299 {C1k has a link to C1j} iff {C2k has a link to C2j}. 301 The distribution of these links depends on the topological 302 properties of the core of the AS. The design rule presented 303 above specifies that these links appear in both core planes. 305 We assume a common design rule found in such deployments: the inter- 306 plane link costs (Cik-Cjk where i<>j) are set such that the route to 307 an edge destination from a given plane stays within the plane unless 308 the plane is partitioned. 310 Edge Router A 311 / \ 312 / \ 313 / \ Agg Region A 314 / \ 315 / \ 316 C1A----------C2A 317 | \ | \ 318 | \ | \ 319 | C1B----------C2B 320 Plane1 | | | | Plane2 321 | | | | 322 C1C--|-----C2C | 323 \ | \ | 324 \ | \ | 325 C1Z----------C2Z 326 \ / 327 \ / Agg Region Z 328 \ / 329 \ / 330 Edge Router Z 332 Figure 2: Dual-Plane Network and Disjointness 334 In this scenario, the operator requires the ability to deploy 335 different strategies. For example, Edge Router A should be able to 336 use the three following options: 338 o the traffic is load-balanced across any ECMP path through the 339 network 341 o the traffic is load-balanced across any ECMP path within the 342 Plane1 of the network 344 o the traffic is load-balanced across any ECMP path within the 345 Plane2 of the network 347 Most of the data traffic from A to Z would use the first option, such 348 as to exploit the capacity efficiently. The operator would use the 349 two other choices for specific premium traffic that has requested 350 disjoint transport. 352 The SPRING architecture SHOULD support this use case with the 353 following requirements: 355 o Zero per-service state and signaling on midpoint and tail-end 356 routers. 358 o ECMP-awareness. 360 o Node resiliency property: the traffic-engineering policy is not 361 anchored to a specific core node whose failure could impact the 362 service. 364 3.3.1.1.2. Egress Peering Traffic Engineering 366 +------+ 367 | | 368 +---D F 369 +---------+ / | AS 2 |\ +------+ 370 | |/ +------+ \| Z | 371 A C | | 372 | |\ +------+ /| AS 4 | 373 B AS1 | \ | |/ +------+ 374 | | +---E G 375 +---------+ | AS 3 | 376 +------+\ 378 Figure 3: Egress peering traffic engineering 380 Let us assume, in the network depicted in Figure 3, that: 382 C in AS1 learns about destination Z of AS 4 via two BGP paths 383 (AS2, AS4) and (AS3, AS4). 385 C may or may not be configured so to enforce next-hop-self 386 behavior before propagating the paths within AS1. 388 C may propagate all the paths to Z within AS1 (BGP add-paths, 389 [I-D.ietf-idr-add-paths]). 391 C may install in its FIB only the route via AS2, or only the route 392 via AS3, or both. 394 In that context, the SPRING architecture SHOULD allow the operator of 395 AS1 to apply a traffic-engineering policy such as the following one, 396 regardless the configured behavior of next-hop-self: 398 Steer 60% of the Z-destined traffic received at A via AS2 and 40% 399 via AS3. 401 Steer 80% of the Z-destined traffic received at B via AS2 and 20% 402 via AS3. 404 The SPRING architecture SHOULD allow an ingress node (i.e., an 405 explicit route source node) to select the exit point of a packet as 406 any combination of an egress node, an egress interface, a peering 407 neighbor, and a peering AS. 409 3.3.1.1.3. Load-balancing among non-parallel links 411 The SPRING architecture SHOULD allow a given node to load share 412 traffic across multiple non parallel links even if these lead to 413 different neighbors. This may be useful to support traffic 414 engineering policies. 416 +---C---D---+ 417 | | 418 PE1---A---B-----F-----E---PE2 420 Figure 4: Multiple (non-parallel) Adjacencies 422 In the above example, the operator requires PE1 to load-balance its 423 PE2-destined traffic between the ABCDE and ABFE paths. 425 3.3.1.2. Traffic Engineering with Bandwidth Admission Control 427 The implementation of bandwidth admission control within a network 428 (and its possible routing consequence which consists in routing along 429 explicit paths where the bandwidth is available) requires a capacity 430 planning process. 432 The spreading of load among ECMP paths is a key attribute of the 433 capacity planning processes applied to packet-based networks. 435 3.3.1.2.1. Capacity Planning Process 437 Capacity Planning anticipates the routing of the traffic matrix onto 438 the network topology, for a set of expected traffic and topology 439 variations. The heart of the process consists in simulating the 440 placement of the traffic along ECMP-aware shortest-paths and 441 accounting for the resulting bandwidth usage. 443 The bandwidth accounting of a demand along its shortest-path is a 444 basic capability of any planning tool or PCE server. 446 For example, in the network topology described below, and assuming a 447 default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps 448 A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, 449 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 450 EF. 452 C-----D 453 / \ \ 454 A---B +--E--F--Z 455 \ / 456 G------+ 458 Figure 5: Capacity Planning an ECMP-based demand 460 ECMP is extremely frequent in SP, Enterprise and DC architectures and 461 it is not rare to see as much as 128 different ECMP paths between a 462 source and a destination within a single network domain. It is a key 463 efficiency objective to spread the traffic among as many ECMP paths 464 as possible. 466 This is illustrated in the below network diagram which consists of a 467 subset of a network where already 5 ECMP paths are observed from A to 468 M. 470 C 471 / \ 472 B-D-L-- 473 / \ / \ 474 A E \ 475 \ M 476 \ G / 477 \ / \ / 478 F K 479 \ / 480 I 482 Figure 6: ECMP Topology Example 484 When the capacity planning process detects that a traffic growth 485 scenario and topology variation would lead to congestion, a capacity 486 increase is triggered and if it cannot be deployed in due time, a 487 traffic engineering solution is activated within the network. 489 A basic traffic engineering objective consists of finding the 490 smallest set of demands that need to be routed off their shortest 491 path to eliminate the congestion, then to compute an explicit path 492 for each of them and instantiating these traffic-engineered policies 493 in the network. 495 The SPRING architecture SHOULD offer a simple support for ECMP-based 496 shortest path placement as well as for explicit path policy without 497 incurring additional signaling in the domain. This includes: 499 o the ability to steer a packet across a set of ECMP paths 501 o the ability to diverge from a set of ECMP shortest paths to one or 502 more paths not in the set of shortest paths 504 3.3.1.2.2. SDN/SR use-case 506 The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as 507 described in [I-D.ietf-pce-stateful-pce]. 509 The SDN controller is responsible to control the evolution of the 510 traffic matrix and topology. It accepts or denies the addition of 511 new traffic into the network. It decides how to route the accepted 512 traffic. It monitors the topology and upon topological change, 513 determines the minimum traffic that should be rerouted on an 514 alternate path to alleviate a bandwidth congestion issue. 516 The algorithms supporting this behavior are a local matter of the SDN 517 controller and are outside the scope of this document. 519 The means of collecting traffic and topology information are the same 520 as what would be used with other SDN-based traffic-engineering 521 solutions (e.g. [RFC7011] and [I-D.ietf-idr-ls-distribution]. 523 The means of instantiating policy information at a traffic- 524 engineering head-end are the same as what would be used with other 525 SDN-based traffic-engineering solutions (e.g.: 526 [I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and 527 [I-D.ietf-pce-segment-routing]). 529 In the context of Centralized-Based Optimization and the SDN use- 530 case, here are the functionalities that the SPRING architecture 531 SHOULD deliver: 533 Explicit routing capability with or without ECMP-awareness. 535 No signaling hop-by-hop through the network. 537 State is only maintained at the policy head-end. No state is 538 maintained at mid-points and tail-ends. 540 Automated guaranteed FRR for any topology. 542 Optimum virtualization: the policy state is in the packet header 543 and not in the intermediate nodes along the path. The policy is 544 completely virtualized away from midpoints and tail-ends. 546 Highly responsive to change: the SDN Controller only needs to 547 apply a policy change at the head-end. No delay is introduced due 548 to programming the midpoints and tail-end along the path. 550 3.4. Interoperability with non-SPRING nodes 552 SPRING nodes MUST inter-operate with non-SPRING nodes and in both 553 MPLS and IPv6 dataplanes. 555 4. Security Considerations 557 There is an assumed trust model such that the source imposing an 558 explicit route on a packet is assumed to be allowed to do so. In 559 such context trust boundaries should strip explicit routes from a 560 packet. 562 For each data plane technology that SPRING specifies, a security 563 analysis MUST be provided showing how protection is provided against 564 an attacker disrupting the network by for example, maliciously 565 injecting SPRING packets. 567 5. IANA Considerations 569 This document does not request any IANA allocations. 571 6. Manageability Considerations 573 The SPRING WG SHOULD provide OAM and the management needed to manage 574 SPRING enabled networks. The SPRING procedures MAY also be used as a 575 tool for OAM in SPRING enabled networks. 577 OAM use cases and requirements are described in 578 [I-D.geib-spring-oam-usecase] and 579 [I-D.kumar-spring-sr-oam-requirement]. 581 7. Contributors 583 The following individuals substantially contributed to the content of 584 this documents: 586 Ruediger Geib 587 Deutsche Telekom 588 Heinrich Hertz Str. 3-7 589 Darmstadt 64295 590 DE 591 Email: Ruediger.Geib@telekom.de 593 Robert Raszuk 594 Mirantis Inc. 595 615 National Ave. 596 94043 Mt View, CA 597 US 598 Email: robert@raszuk.net 600 8. Acknowledgements 602 The authors would like to thank Yakov Rekhter for his contribution to 603 this document. 605 9. References 607 9.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 613 (IPv6) Specification", RFC 2460, December 1998. 615 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 616 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 617 RFC 6564, April 2012. 619 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 620 of IPv6 Extension Headers", RFC 7045, December 2013. 622 9.2. Informative References 624 [I-D.crabbe-pce-pce-initiated-lsp] 625 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 626 Extensions for PCE-initiated LSP Setup in a Stateful PCE 627 Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in 628 progress), October 2013. 630 [I-D.geib-spring-oam-usecase] 631 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 632 case for a scalable and topology aware MPLS data plane 633 monitoring system", draft-geib-spring-oam-usecase-04 (work 634 in progress), March 2015. 636 [I-D.ietf-i2rs-architecture] 637 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 638 Nadeau, "An Architecture for the Interface to the Routing 639 System", draft-ietf-i2rs-architecture-09 (work in 640 progress), March 2015. 642 [I-D.ietf-idr-add-paths] 643 Walton, D., Retana, A., Chen, E., and J. Scudder, 644 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 645 add-paths-10 (work in progress), October 2014. 647 [I-D.ietf-idr-ls-distribution] 648 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 649 Ray, "North-Bound Distribution of Link-State and TE 650 Information using BGP", draft-ietf-idr-ls-distribution-10 651 (work in progress), January 2015. 653 [I-D.ietf-pce-segment-routing] 654 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 655 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 656 "PCEP Extensions for Segment Routing", draft-ietf-pce- 657 segment-routing-03 (work in progress), April 2015. 659 [I-D.ietf-pce-stateful-pce] 660 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 661 Extensions for Stateful PCE", draft-ietf-pce-stateful- 662 pce-11 (work in progress), April 2015. 664 [I-D.ietf-spring-resiliency-use-cases] 665 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 666 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 667 resiliency-use-cases-01 (work in progress), March 2015. 669 [I-D.kumar-spring-sr-oam-requirement] 670 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 671 and S. Litkowski, "OAM Requirements for Segment Routing 672 Network", draft-kumar-spring-sr-oam-requirement-03 (work 673 in progress), March 2015. 675 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 676 the IP Flow Information Export (IPFIX) Protocol for the 677 Exchange of Flow Information", STD 77, RFC 7011, September 678 2013. 680 Authors' Addresses 682 Stefano Previdi (editor) 683 Cisco Systems, Inc. 684 Via Del Serafico, 200 685 Rome 00142 686 Italy 688 Email: sprevidi@cisco.com 690 Clarence Filsfils (editor) 691 Cisco Systems, Inc. 692 Brussels 693 BE 695 Email: cfilsfil@cisco.com 697 Bruno Decraene 698 Orange 699 FR 701 Email: bruno.decraene@orange.com 703 Stephane Litkowski 704 Orange 705 FR 707 Email: stephane.litkowski@orange.com 708 Martin Horneffer 709 Deutsche Telekom 710 Hammer Str. 216-226 711 Muenster 48153 712 DE 714 Email: Martin.Horneffer@telekom.de 716 Rob Shakir 717 British Telecom 718 London 719 UK 721 Email: rob.shakir@bt.com