idnits 2.17.1 draft-ietf-spring-problem-statement-06.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2015) is 3055 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 (-15) exists of draft-ietf-idr-add-paths-13 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-13 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-02 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: June 16, 2016 B. Decraene 6 S. Litkowski 7 Orange 8 M. Horneffer 9 Deutsche Telekom 10 R. Shakir 11 Jive Communications 12 December 14, 2015 14 SPRING Problem Statement and Requirements 15 draft-ietf-spring-problem-statement-06 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 June 16, 2016. 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 (FRR) . . . . . . . . . . . . . . . . . . . 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 SPRING architecture SHOULD leverage the existing MPLS dataplane 149 without any modification and leverage IPv6 dataplane with a new IPv6 150 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). 152 3. SPRING Use Cases 154 3.1. IGP-based MPLS Tunneling 156 The source-based routing model, applied to the MPLS dataplane, offers 157 the ability to tunnel services like VPN ([RFC4364]), VPLS ([RFC4761], 158 [RFC4762]) and VPWS ([RFC6624]), from an ingress PE to an egress PE, 159 with or without the expression of an explicit path and without 160 requiring forwarding plane or control plane state in intermediate 161 nodes. Point-to-multipoint and multipoint-to-multipoint tunnels are 162 outside of the scope of this document. 164 3.1.1. Example of IGP-based MPLS Tunnels 166 This section illustrates an example use-case. 168 P1---P2 169 / \ 170 A---CE1---PE1 PE2---CE2---Z 171 \ / 172 P3---P4 174 Figure 1: IGP-based MPLS Tunneling 176 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 177 same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local 178 label LZ to that route and propagates the route and its label via 179 MPBGP to PE1 with nhop 192.0.2.2 (i.e.: the local address of PE2). 180 PE1 installs the VPN prefix Z in the appropriate VRF and resolves the 181 next-hop onto the node segment associated with PE2. 183 In order to cope with the reality of current deployments, the SPRING 184 architecture SHOULD allow PE to PE forwarding according to the IGP 185 shortest path without the addition of any other signaling protocol. 186 The packet each PE forwards across the network will contain (within 187 their label stack) the necessary information derived from the 188 topology database in order to deliver the packet to the remote PE. 190 3.2. Fast Reroute (FRR) 192 FRR technologies have been deployed by network operators in order to 193 cope with link or node failures through pre-computation of backup 194 paths. 196 The SPRING architecture SHOULD address the following requirements: 198 o support of Fast Reroute (FRR) on any topology 200 o pre-computation and setup of backup path without any additional 201 signaling (other than the regular IGP/BGP protocols) 203 o support of shared risk constraints 205 o support of node and link protection 207 o support of microloop avoidance 209 Further illustrations of the problem statement for FRR are to be 210 found in [I-D.ietf-spring-resiliency-use-cases]. 212 3.3. Traffic Engineering 214 Traffic Engineering has been addressed using IGP protocol extensions 215 (for resources information propagation) and RSVP-TE for signaling 216 explicit paths ([RFC5305], [RFC3630], [RFC3209]. Different contexts 217 and modes have been defined (single vs. multiple domains, with or 218 without bandwidth admission control, centralized vs. distributed path 219 computation, etc). 221 In all cases, one of the major components of the TE architecture is 222 the soft state based signaling protocol (RSVP-TE) which is used in 223 order to signal and establish the explicit path. Each path, once 224 computed, need to be signaled and state for each path must be present 225 in each node traversed by the path. This incurs a scalability 226 problem especially in the context of SDN where traffic 227 differentiation may be done at a finer granularity (e.g.: application 228 specific). Also the amount of state needed to be maintained and 229 periodically refreshed in all involved nodes contributes 230 significantly to complexity and the number of failures cases, and 231 thus increases operational effort while decreasing overall network 232 reliability. 234 The source-based routing model allows traffic engineering to be 235 implemented without the need of a signaling component. 237 The SPRING architecture SHOULD support traffic engineering, 238 including: 240 o loose or strict options 242 o bandwidth admission control 244 o distributed vs. centralized model (PCE 245 [I-D.ietf-pce-stateful-pce], SDN Controller) 247 o disjointness in dual-plane networks 249 o egress peering traffic engineering 251 o load-balancing among non-parallel links (i.e.: links connected to 252 different adjacent neighbors). 254 o Limiting (scalable, preferably zero) per-service state and 255 signaling on midpoint and tail-end routers. 257 o ECMP-awareness 259 o node resiliency property (i.e.: the traffic-engineering policy is 260 not anchored to a specific core node whose failure could impact 261 the service. 263 3.3.1. Examples of Traffic Engineering Use Cases 265 Here follows the description of two sets of use cases: 267 o Traffic Engineering without Admission Control 269 o Traffic Engineering with Admission Control 271 3.3.1.1. Traffic Engineering without Bandwidth Admission Control 273 In this section, we describe Traffic Engineering use-cases without 274 bandwidth admission control. 276 3.3.1.1.1. Disjointness in dual-plane networks 278 Many networks are built according to the dual-plane design, as 279 illustrated in Figure 2: 281 Each aggregation region k is connected to the core by 282 two C routers C1k and C2k where k refers to the region. 284 C1k is part of plane 1 and aggregation region k 286 C2k is part of plane 2 and aggregation region k 288 C1k has a link to C2j iff k = j. 290 The core nodes of a given region are directly connected. 291 Inter-region links only connect core nodes of the same plane. 293 {C1k has a link to C1j} iff {C2k has a link to C2j}. 295 The distribution of these links depends on the topological 296 properties of the core of the AS. The design rule presented 297 above specifies that these links appear in both core planes. 299 We assume a common design rule found in such deployments: the inter- 300 plane link costs (Cik-Cjk where i<>j) are set such that the route to 301 an edge destination from a given plane stays within the plane unless 302 the plane is partitioned. 304 Edge Router A 305 / \ 306 / \ 307 / \ Agg Region A 308 / \ 309 / \ 310 C1A----------C2A 311 | \ | \ 312 | \ | \ 313 | C1B----------C2B 314 Plane1 | | | | Plane2 315 | | | | 316 C1C--|-----C2C | 317 \ | \ | 318 \ | \ | 319 C1Z----------C2Z 320 \ / 321 \ / Agg Region Z 322 \ / 323 \ / 324 Edge Router Z 326 Figure 2: Dual-Plane Network and Disjointness 328 In this scenario, the operator requires the ability to deploy 329 different strategies. For example, Edge Router A should be able to 330 use the three following options: 332 o the traffic is load-balanced across any ECMP path through the 333 network 335 o the traffic is load-balanced across any ECMP path within the 336 Plane1 of the network 338 o the traffic is load-balanced across any ECMP path within the 339 Plane2 of the network 341 Most of the data traffic from A to Z would use the first option, such 342 as to exploit the capacity efficiently. The operator would use the 343 two other choices for specific premium traffic that has requested 344 disjoint transport. 346 The SPRING architecture SHOULD support this use case with the 347 following requirements: 349 o Zero per-service state and signaling on midpoint and tail-end 350 routers. 352 o ECMP-awareness. 354 o Node resiliency property: the traffic-engineering policy is not 355 anchored to a specific core node whose failure could impact the 356 service. 358 3.3.1.1.2. Egress Peering Traffic Engineering 360 +------+ 361 | | 362 +---D F 363 +---------+ / | AS 2 |\ +------+ 364 | |/ +------+ \| Z | 365 A C | | 366 | |\ +------+ /| AS 4 | 367 B AS1 | \ | |/ +------+ 368 | | +---E G 369 +---------+ | AS 3 | 370 +------+\ 372 Figure 3: Egress peering traffic engineering 374 Let us assume, in the network depicted in Figure 3, that: 376 C in AS1 learns about destination Z of AS 4 via two BGP paths 377 (AS2, AS4) and (AS3, AS4). 379 C may or may not be configured so to enforce next-hop-self 380 behavior before propagating the paths within AS1. 382 C may propagate all the paths to Z within AS1 (BGP add-paths, 383 [I-D.ietf-idr-add-paths]). 385 C may install in its FIB only the route via AS2, or only the route 386 via AS3, or both. 388 In that context, the SPRING architecture SHOULD allow the operator of 389 AS1 to apply a traffic-engineering policy such as the following one, 390 regardless the configured behavior of next-hop-self: 392 Steer 60% of the Z-destined traffic received at A via AS2 and 40% 393 via AS3. 395 Steer 80% of the Z-destined traffic received at B via AS2 and 20% 396 via AS3. 398 The SPRING architecture SHOULD allow an ingress node (i.e., an 399 explicit route source node) to select the exit point of a packet as 400 any combination of an egress node, an egress interface, a peering 401 neighbor, and a peering AS. 403 The use cases and requirements for Egress Peer Engineering are 404 described in [I-D.ietf-spring-segment-routing-central-epe]. 406 3.3.1.1.3. Load-balancing among non-parallel links 408 The SPRING architecture SHOULD allow a given node to load share 409 traffic across multiple non parallel links (i.e.: links connected to 410 different adjacent routers) even if these lead to different 411 neighbors. This may be useful to support traffic engineering 412 policies. 414 +---C---D---+ 415 | | 416 PE1---A---B-----F-----E---PE2 418 Figure 4: Multiple (non-parallel) Adjacencies 420 In the above example, the operator requires PE1 to load-balance its 421 PE2-destined traffic between the ABCDE and ABFE equal-cost paths in a 422 controlled way where the operator SHOULD be allowed to distribute 423 traffic unevenly between paths (Weighted Equal Cost Multiplath, 424 WECMP). 426 3.3.1.2. Traffic Engineering with Bandwidth Admission Control 428 The implementation of bandwidth admission control within a network 429 (and its possible routing consequence which consists in routing along 430 explicit paths where the bandwidth is available) requires a capacity 431 planning process. 433 The spreading of load among ECMP paths is a key attribute of the 434 capacity planning processes applied to packet-based networks. 436 3.3.1.2.1. Capacity Planning Process 438 Capacity Planning anticipates the routing of the traffic matrix onto 439 the network topology, for a set of expected traffic and topology 440 variations. The heart of the process consists in simulating the 441 placement of the traffic along ECMP-aware shortest-paths and 442 accounting for the resulting bandwidth usage. 444 The bandwidth accounting of a demand along its shortest-path is a 445 basic capability of any planning tool or PCE server. 447 For example, in the network topology described below, and assuming a 448 default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps 449 A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, 450 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 451 EF. 453 C-----D 454 / \ \ 455 A---B +--E--F--Z 456 \ / 457 G------+ 459 Figure 5: Capacity Planning an ECMP-based demand 461 ECMP is extremely frequent in SP, Enterprise and DC architectures and 462 it is not rare to see as much as 128 different ECMP paths between a 463 source and a destination within a single network domain. It is a key 464 efficiency objective to spread the traffic among as many ECMP paths 465 as possible. 467 This is illustrated in the below network diagram which consists of a 468 subset of a network where already 5 ECMP paths are observed from A to 469 M. 471 C 472 / \ 473 B-D-L-- 474 / \ / \ 475 A E \ 476 \ M 477 \ G / 478 \ / \ / 479 F K 480 \ / 481 I 483 Figure 6: ECMP Topology Example 485 When the capacity planning process detects that a traffic growth 486 scenario and topology variation would lead to congestion, a capacity 487 increase is triggered and if it cannot be deployed in due time, a 488 traffic engineering solution is activated within the network. 490 A basic traffic engineering objective consists of finding the 491 smallest set of demands that need to be routed off their shortest 492 path to eliminate the congestion, then to compute an explicit path 493 for each of them and instantiating these traffic-engineered policies 494 in the network. 496 The SPRING architecture SHOULD offer a simple support for ECMP-based 497 shortest path placement as well as for explicit path policy without 498 incurring additional signaling in the domain. This includes: 500 o the ability to steer a packet across a set of ECMP paths 502 o the ability to diverge from a set of ECMP shortest paths to one or 503 more paths not in the set of shortest paths 505 3.3.1.2.2. SDN/SR use-case 507 The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as 508 described in [I-D.ietf-pce-stateful-pce]. 510 The SDN controller is responsible to control the evolution of the 511 traffic matrix and topology. It accepts or denies the addition of 512 new traffic into the network. It decides how to route the accepted 513 traffic. It monitors the topology and upon topological change, 514 determines the minimum traffic that should be rerouted on an 515 alternate path to alleviate a bandwidth congestion issue. 517 The algorithms supporting this behavior are a local matter of the SDN 518 controller and are outside the scope of this document. 520 The means of collecting traffic and topology information are the same 521 as what would be used with other SDN-based traffic-engineering 522 solutions. 524 The means of instantiating policy information at a traffic- 525 engineering head-end are the same as what would be used with other 526 SDN-based traffic-engineering solutions. 528 In the context of Centralized-Based Optimization and the SDN use- 529 case, here are the functionalities that the SPRING architecture 530 SHOULD deliver: 532 Explicit routing capability with or without ECMP-awareness. 534 No signaling hop-by-hop through the network. 536 State is only maintained at the policy head-end. No state is 537 maintained at mid-points and tail-ends. 539 Automated guaranteed FRR for any topology. 541 Optimum virtualization: the policy state is in the packet header 542 and not in the intermediate nodes along the path. The policy is 543 completely virtualized away from midpoints and tail-ends. 545 Highly responsive to change: the SDN Controller only needs to 546 apply a policy change at the head-end. No delay is introduced due 547 to programming the midpoints and tail-end along the path. 549 3.4. Interoperability with non-SPRING nodes 551 SPRING nodes MUST inter-operate with non-SPRING nodes and in both 552 MPLS and IPv6 dataplanes in order to allow a gradual deployment of 553 SPRING on existing MPLS and IPv6 networks. 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. It is 559 assumed that the default behavior is to strip any internal routing 560 information from the packet before the packet is forwarded outside 561 the domain. In such context trust boundaries SHOULD strip explicit 562 routes from a packet. 564 For each data plane technology that SPRING specifies, a security 565 analysis MUST be provided showing how protection is provided against 566 an attacker disrupting the network by for example, maliciously 567 injecting SPRING packets. 569 5. IANA Considerations 571 This document does not request any IANA allocations. 573 6. Manageability Considerations 575 The SPRING WG SHOULD provide OAM and the management needed to manage 576 SPRING enabled networks. The SPRING procedures MAY also be used as a 577 tool for OAM in SPRING enabled networks. 579 OAM use cases and requirements are described in 580 [I-D.geib-spring-oam-usecase] and 581 [I-D.kumar-spring-sr-oam-requirement]. 583 7. Contributors 585 The following individuals substantially contributed to the content of 586 this documents: 588 Ruediger Geib 589 Deutsche Telekom 590 Heinrich Hertz Str. 3-7 591 Darmstadt 64295 592 DE 593 Email: Ruediger.Geib@telekom.de 595 Robert Raszuk 596 Mirantis Inc. 597 615 National Ave. 598 94043 Mt View, CA 599 US 600 Email: robert@raszuk.net 602 8. Acknowledgements 604 The authors would like to thank Yakov Rekhter for his contribution to 605 this document. 607 9. References 609 9.1. Normative References 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, 613 DOI 10.17487/RFC2119, March 1997, 614 . 616 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 617 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 618 December 1998, . 620 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 621 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 622 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 623 . 625 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 626 (TE) Extensions to OSPF Version 2", RFC 3630, 627 DOI 10.17487/RFC3630, September 2003, 628 . 630 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 631 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 632 2006, . 634 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 635 LAN Service (VPLS) Using BGP for Auto-Discovery and 636 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 637 . 639 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 640 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 641 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 642 . 644 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 645 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 646 2008, . 648 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 649 Virtual Private Networks Using BGP for Auto-Discovery and 650 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 651 . 653 9.2. Informative References 655 [I-D.geib-spring-oam-usecase] 656 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 657 case for a scalable and topology aware MPLS data plane 658 monitoring system", draft-geib-spring-oam-usecase-06 (work 659 in progress), July 2015. 661 [I-D.ietf-idr-add-paths] 662 Walton, D., Retana, A., Chen, E., and J. Scudder, 663 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 664 add-paths-13 (work in progress), December 2015. 666 [I-D.ietf-pce-stateful-pce] 667 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 668 Extensions for Stateful PCE", draft-ietf-pce-stateful- 669 pce-13 (work in progress), December 2015. 671 [I-D.ietf-spring-resiliency-use-cases] 672 Francois, P., Filsfils, C., Decraene, B., and r. 673 rjs@rob.sh, "Use-cases for Resiliency in SPRING", draft- 674 ietf-spring-resiliency-use-cases-02 (work in progress), 675 December 2015. 677 [I-D.ietf-spring-segment-routing-central-epe] 678 Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, 679 "Segment Routing Centralized Egress Peer Engineering", 680 draft-ietf-spring-segment-routing-central-epe-00 (work in 681 progress), October 2015. 683 [I-D.kumar-spring-sr-oam-requirement] 684 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 685 and S. Litkowski, "OAM Requirements for Segment Routing 686 Network", draft-kumar-spring-sr-oam-requirement-03 (work 687 in progress), March 2015. 689 Authors' Addresses 691 Stefano Previdi (editor) 692 Cisco Systems, Inc. 693 Via Del Serafico, 200 694 Rome 00142 695 Italy 697 Email: sprevidi@cisco.com 699 Clarence Filsfils (editor) 700 Cisco Systems, Inc. 701 Brussels 702 BE 704 Email: cfilsfil@cisco.com 705 Bruno Decraene 706 Orange 707 FR 709 Email: bruno.decraene@orange.com 711 Stephane Litkowski 712 Orange 713 FR 715 Email: stephane.litkowski@orange.com 717 Martin Horneffer 718 Deutsche Telekom 719 Hammer Str. 216-226 720 Muenster 48153 721 DE 723 Email: Martin.Horneffer@telekom.de 725 Rob Shakir 726 Jive Communications, Inc. 727 1275 West 1600 North, Suite 100 728 Orem, UT 84057 730 Email: rjs@rob.sh