idnits 2.17.1 draft-previdi-spring-problem-statement-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 4, 2014) is 3674 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-00 == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-mpls-00 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 == Outdated reference: A later version (-02) exists of draft-francois-spring-resiliency-use-case-01 == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-01 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-02 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-04 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-08 == Outdated reference: A later version (-03) exists of draft-kumar-spring-sr-oam-requirement-00 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-segment-routing-02 Summary: 1 error (**), 0 flaws (~~), 13 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: Standards Track Cisco Systems, Inc. 5 Expires: October 6, 2014 B. Decraene 6 S. Litkowski 7 Orange 8 M. Horneffer 9 R. Geib 10 Deutsche Telekom 11 R. Shakir 12 British Telecom 13 R. Raszuk 14 Individual 15 April 4, 2014 17 SPRING Problem Statement and Requirements 18 draft-previdi-spring-problem-statement-02 20 Abstract 22 The ability for a node to specify a forwarding path, other than the 23 normal shortest path, that a particular packet will traverse, 24 benefits a number of network functions. Source-based routing 25 mechanisms have previously been specified for network protocols, but 26 have not seen widespread adoption. In this context, the term 27 'source' means 'the point at which the explicit route is imposed'. 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 6, 2014. 57 Copyright Notice 59 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . . 5 77 3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 5 78 4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 6 80 5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 7 81 5.1.1. Traffic Engineering without Bandwidth Admission 82 Control . . . . . . . . . . . . . . . . . . . . . . . 7 83 5.1.2. Traffic Engineering with Bandwidth Admission 84 Control . . . . . . . . . . . . . . . . . . . . . . . 11 85 6. Interoperability with non-SPRING nodes . . . . . . . . . . . . 14 86 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 10. Manageability Considerations . . . . . . . . . . . . . . . . . 15 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 94 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 The ability for a node to specify a unicast forwarding path, other 100 than the normal shortest path, that a particular packet will 101 traverse, benefits a number of network functions, for example: 103 Some types of network virtualization, including multi-topology 104 networks and the partitioning of network resources for VPNs 106 Network, link, path and node protection such as fast re-route 108 Network programmability 110 OAM techniques 112 Simplification and reduction of network signaling components 114 Load balancing and traffic engineering 116 The term 'source' means 'the point at which the explicit route is 117 imposed'. 119 In this context, Source Packet Routing in Networking (SPRING) 120 architecture is being defined so as to address the use cases and 121 requirements described in this document. 123 SPRING architecture should allow incremental and selective deployment 124 without any requirement of flag day or massive upgrade of all network 125 elements. 127 SPRING architecture should allow optimal virtualization: put policy 128 state in the packet header and not in the intermediate nodes along 129 the path. Hence, the policy is completely virtualized away from 130 midpoints and tail-ends. 132 2. Dataplanes 134 The SPRING architecture should be general in order to ease its 135 applicability to different dataplanes. 137 MPLS dataplane doesn't require any modification in order to apply a 138 source-based routed model (e.g.: 139 [I-D.filsfils-spring-segment-routing-mpls]). 141 IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045], 142 defines the Routing Extension Header which provides IPv6 source-based 143 routing capabilities. 145 The SPRING architecture should leverage existing MPLS dataplane 146 without any modification and leverage IPv6 dataplane with minor 147 modifications. 149 3. IGP-based MPLS Tunneling 151 The source-based routing model, applied to the MPLS dataplane, offers 152 the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE 153 to an egress PE, with or without the expression of an explicit path 154 and without requiring forwarding plane or control plane state in 155 intermediate nodes. 157 3.1. Example of IGP-based MPLS Tunnels 159 This section illustrates an example use-case taken from 160 [I-D.filsfils-spring-segment-routing-use-cases]. 162 P1---P2 163 / \ 164 A---CE1---PE1 PE2---CE2---Z 165 \ / 166 P3---P4 168 Figure 1: IGP-based MPLS Tunneling 170 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 171 same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local 172 label LZ to that route and propagates the route and its label via 173 MPBGP to PE1 with nhop 192.168.0.2. PE1 installs the VPN prefix Z in 174 the appropriate VRF and resolves the next-hop onto the node segment 175 associated with PE2. 177 In order to cope with the reality of current deployments, the SPRING 178 architecture should allow PE to PE forwarding according to the IGP 179 shortest path without the addition of any other signaling protocol. 180 The packet each PE forwards across the network will contain (within 181 their label stack) the necessary information derived from the 182 topology database in order to deliver the packet to the remote PE. 184 4. Fast Reroute 186 FRR technologies have been deployed by network operators in order to 187 cope with link or node failures through pre-computation of backup 188 paths. 190 The SPRING architecture should address following requirements: 192 o support of FRR on any topology 194 o pre-computation and setup of backup path without any additional 195 signaling (other than the regular IGP/BGP protocols) 197 o support of shared risk constraints 199 o support of node and link protection 201 o support of microloop avoidance 203 Further illustrations of the problem statement for FRR are to be 204 found in [I-D.francois-spring-resiliency-use-case]. 206 5. Traffic Engineering 208 Traffic Engineering has been addressed using IGP protocol extensions 209 (for resources information propagation) and RSVP-TE for signaling 210 explicit paths. Different contexts and modes have been defined 211 (single vs. multiple domains, with or without bandwidth admission 212 control, centralized vs. distributed path computation, etc). 214 In all cases, one of the major components of the TE architecture is 215 the soft state based signaling protocol (RSVP-TE) which is used in 216 order to signal and establish the explicit path. Each path, once 217 computed, need to be signaled and state for each path must be present 218 in each node traversed by the path. This incurs a scalability 219 problem especially in the context of SDN where traffic 220 differentiation may be done at a finer granularity (e.g.: application 221 specific). Also the amount of state needed to be maintained and 222 periodically refreshed in all involved nodes contributes 223 significantly to complexity and the number of failures cases, and 224 thus increases operational effort while decreasing overall network 225 reliability. 227 The source-based routing model allows traffic engineering to be 228 implemented without the need of a signaling component. 230 The SPRING architecture should support traffic engineering, 231 including: 233 o loose or strict options 235 o bandwidth admission control 237 o distributed vs. centralized model (PCE, SDN Controller) 238 o disjointness in dual-plane networks 240 o egress peering traffic engineering 242 o load-balancing among non-parallel links 244 o Limiting (scalable, preferably zero) per-service state and 245 signaling on midpoint and tail-end routers. 247 o ECMP-awareness 249 o node resiliency property (i.e.: the traffic-engineering policy is 250 not anchored to a specific core node whose failure could impact 251 the service. 253 5.1. Examples of Traffic Engineering Use Cases 255 As documented in [I-D.filsfils-spring-segment-routing-use-cases] here 256 follows the description of two sets of use cases: 258 o Traffic Engineering without Admission Control 260 o Traffic Engineering with Admission Control 262 5.1.1. Traffic Engineering without Bandwidth Admission Control 264 In this section, we describe Traffic Engineering use-cases without 265 bandwidth admission control. 267 5.1.1.1. Disjointness in dual-plane networks 269 Many networks are built according to the dual-plane design, as 270 illustrated in Figure 2: 272 Each access region k is connected to the core by two C routers 273 (C(1,k) and C(2,k)). 275 C(1,k) is part of plane 1 and aggregation region K 277 C(2,k) is part of plane 2 and aggregation region K 279 C(1,k) has a link to C(2, j) iff k = j. 281 The core nodes of a given region are directly connected. 282 Inter-region links only connect core nodes of the same plane. 284 {C(1,k) has a link to C(1, j)} iff {C(2,k) has a link to C(2, j)}. 286 The distribution of these links depends on the topological 287 properties of the core of the AS. The design rule presented 288 above specifies that these links appear in both core planes. 290 We assume a common design rule found in such deployments: the inter- 291 plane link costs (Cik-Cjk where i<>j) are set such that the route to 292 an edge destination from a given plane stays within the plane unless 293 the plane is partitioned. 294 Edge Router A 295 / \ 296 / \ 297 / \ Agg Region A 298 / \ 299 / \ 300 C1A----------C2A 301 | \ | \ 302 | \ | \ 303 | C1B----------C2B 304 Plane1 | | | | Plane2 305 | | | | 306 C1C--|-----C2C | 307 \ | \ | 308 \ | \ | 309 C1Z----------C2Z 310 \ / 311 \ / Agg Region Z 312 \ / 313 \ / 314 Edge Router Z 316 Figure 2: Dual-Plane Network and Disjointness 318 In this scenario, the operator requires the ability to deploy 319 different strategies. For example, A should be able to use the three 320 following options: 322 o the traffic is load-balanced across any ECMP path through the 323 network 325 o the traffic is load-balanced across any ECMP path within the 326 Plane1 of the network 328 o the traffic is load-balanced across any ECMP path within the 329 Plane2 of the network 331 Most of the data traffic from A to Z would use the first option, such 332 as to exploit the capacity efficiently. The operator would use the 333 two other choices for specific premium traffic that has requested 334 disjoint transport. 336 The SPRING architecture should support this use case with the 337 following requirements: 339 o Zero per-service state and signaling on midpoint and tail-end 340 routers. 342 o ECMP-awareness. 344 o Node resiliency property: the traffic-engineering policy is not 345 anchored to a specific core node whose failure could impact the 346 service. 348 5.1.1.2. Egress Peering Traffic Engineering 349 +------+ 350 | | 351 +---D F 352 +---------+ / | AS 2 |\ +------+ 353 | |/ +------+ \| Z | 354 A C | | 355 | |\ +------+ /| AS 4 | 356 B AS1 | \ | |/ +------+ 357 | | +---E G 358 +---------+ | AS 3 | 359 +------+\ 361 Figure 3: Egress peering traffic engineering 363 Let us assume, in the network depicted in Figure 3, that: 365 C in AS1 learns about destination Z of AS 4 via two BGP paths 366 (AS2, AS4) and (AS3, AS4). 368 C may or may not be configured so to enforce next-hop-self 369 behavior before propagating the paths within AS1. 371 C propagates all the paths to Z within AS1 (add-path). 373 C only installs the path via AS2 in its RIB. 375 In that context, SPRING should allow the operator of AS1 to apply the 376 following traffic-engineering policy, regardless the configured 377 behavior of next-hop-self: 379 Steer 60% of the Z-destined traffic received at A via AS2 and 40% 380 via AS3. 382 Steer 80% of the Z-destined traffic received at B via AS2 and 20% 383 via AS3. 385 While egress routers are known in the routing domain (generally 386 through their loopback address), the SPRING architecture should 387 enable following: 389 o identify the egress interfaces of an egress node 391 o identify the peering neighbors of an egress node 393 o identify the peering ASes of an egress node 395 With these identifiers known in the domain, the SPRING architecture 396 should allow an ingress node to select the exit point of a packet as 397 any combination of an egress node, an egress interface, a peering 398 neighbor, and a peering AS. 400 5.1.1.3. Load-balancing among non-parallel links 402 The SPRING architecture should allow a given node should be able to 403 load share traffic across multiple non parallel links even if these 404 ones lead to different neighbors. This may be useful to support 405 traffic engineering policies. 407 +---C---D---+ 408 | | 409 PE1---A---B-----F-----E---PE2 411 Figure 4: Multiple (non-parallel) Adjacencies 413 In the above example, the operator requires PE1 to load-balance its 414 PE2-destined traffic between the ABCDE and ABFE paths. 416 5.1.2. Traffic Engineering with Bandwidth Admission Control 418 The implementation of bandwidth admission control within a network 419 (and its possible routing consequence which consists in routing along 420 explicit paths where the bandwidth is available) requires a capacity 421 planning process. 423 The spreading of load among ECMP paths is a key attribute of the 424 capacity planning processes applied to packet-based networks. 426 5.1.2.1. Capacity Planning Process 428 Capacity Planning anticipates the routing of the traffic matrix onto 429 the network topology, for a set of expected traffic and topology 430 variations. The heart of the process consists in simulating the 431 placement of the traffic along ECMP-aware shortest-paths and 432 accounting for the resulting bandwidth usage. 434 The bandwidth accounting of a demand along its shortest-path is a 435 basic capability of any planning tool or PCE server. 437 For example, in the network topology described below, and assuming a 438 default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps 439 A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, 440 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 441 EF. 442 C-----D 443 / \ \ 444 A---B +--E--F--Z 445 \ / 446 G------+ 448 Figure 5: Capacity Planning an ECMP-based demand 450 ECMP is extremely frequent in SP, Enterprise and DC architectures and 451 it is not rare to see as much as 128 different ECMP paths between a 452 source and a destination within a single network domain. It is a key 453 efficiency objective to spread the traffic among as many ECMP paths 454 as possible. 456 This is illustrated in the below network diagram which consists of a 457 subset of a network where already 5 ECMP paths are observed from A to 458 M. 460 C 461 / \ 462 B-D-L-- 463 / \ / \ 464 A E \ 465 \ M 466 \ G / 467 \ / \ / 468 F K 469 \ / 470 I 472 Figure 6: ECMP Topology Example 474 When the capacity planning process detects that a traffic growth 475 scenario and topology variation would lead to congestion, a capacity 476 increase is triggered and if it cannot be deployed in due time, a 477 traffic engineering solution is activated within the network. 479 A basic traffic engineering objective consists of finding the 480 smallest set of demands that need to be routed off their shortest 481 path to eliminate the congestion, then to compute an explicit path 482 for each of them and instantiating these traffic-engineered policies 483 in the network. 485 SPRING architecture should offer a simple support for ECMP-based 486 shortest path placement as well as for explicit path policy without 487 incurring additional signaling in the domain. This includes: 489 o the ability to steer a packet across a set of ECMP paths 491 o the ability to diverge from a set of ECMP shortest paths to one or 492 more paths not in the set of shortest paths 494 5.1.2.2. SDN/SR use-case 496 The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as 497 described in [I-D.ietf-pce-stateful-pce]. 499 The SDN controller is responsible to control the evolution of the 500 traffic matrix and topology. It accepts or denies the addition of 501 new traffic into the network. It decides how to route the accepted 502 traffic. It monitors the topology and upon topological change, 503 determines the minimum traffic that should be rerouted on an 504 alternate path to alleviate a bandwidth congestion issue. 506 The algorithms supporting this behavior are a local matter of the SDN 507 controller and are outside the scope of this document. 509 The means of collecting traffic and topology information are the same 510 as what would be used with other SDN-based traffic-engineering 511 solutions (e.g. [RFC7011] and [I-D.ietf-idr-ls-distribution]. 513 The means of instantiating policy information at a traffic- 514 engineering head-end are the same as what would be used with other 515 SDN-based traffic-engineering solutions (e.g.: 516 [I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and 517 [I-D.sivabalan-pce-segment-routing]). 519 In the context of Centralized-Based Optimization and the SDN use- 520 case, here are the benefits that the SPRING architecture should 521 deliver: 523 Explicit routing capability with or without ECMP-awareness. 525 No signaling hop-by-hop through the network. 527 State is only maintained at the policy head-end. No state is 528 maintained at mid-points and tail-ends. 530 Automated guaranteed FRR for any topology. 532 Optimum virtualization: the policy state is in the packet header 533 and not in the intermediate nodes along the path. The policy is 534 completely virtualized away from midpoints and tail-ends. 536 Highly responsive to change: the SDN Controller only needs to 537 apply a policy change at the head-end. No delay is introduced due 538 to programming the midpoints and tail-end along the path. 540 5.1.2.2.1. SDN Example 542 The data-set consists in a full-mesh of 12000 explicitly-routed 543 tunnels observed on a real network. These tunnels resulted from 544 distributed headend-based CSPF computation. 546 We measured that only 65% of the traffic is forwarded over its 547 shortest path. 549 Three well-known defects are illustrated in this data set: 551 The lack of ECMP support in explicitly routed tunnels: ATM-alike 552 traffic-steering mechanisms steer the traffic along a non-ECMP 553 path. 555 The increase of the number of explicitly-routed non-ECMP tunnels 556 to enumerate all the ECMP options. 558 The inefficiency of distributed optimization: too much traffic is 559 forwarded off its shortest path. 561 We applied the SDN use-case to this dataset implying a source route 562 model where the path of the packet is encoded within the packet 563 itself. This means that: 565 The distributed CSPF computation is replaced by centralized 566 optimization and BW admission control, supported by the SDN 567 Controller. 569 As part of the optimization, we also optimized the IGP-metrics 570 such as to get a maximum of traffic load-spread among ECMP 571 paths by default. 573 The traffic-engineering policies are supported by a source route 574 model (e.g.: [I-D.filsfils-rtgwg-segment-routing]). 576 As a result, we measured that 98% of the traffic would be kept on its 577 normal policy (over the shortest-path) and only 2% of the traffic 578 requires a path away from the shortest-path. 580 Let us highlight a few benefits: 582 98% of the traffic-engineering head-end policies are eliminated. 584 Indeed, by default, an ingress edge node capable of injecting 585 source routed packets steers the traffic to the egress edge 586 node. No configuration or policy needs to be maintained at the 587 ingress edge node to realize this. 589 100% of the states at mid/tail nodes are eliminated. 591 6. Interoperability with non-SPRING nodes 593 SPRING must inter-operate with non-SPRING nodes. 595 An illustration of interoperability between SPRING and other MPLS 596 Signalling Protocols (LDP) is described here in 597 [I-D.filsfils-spring-segment-routing-ldp-interop]. 599 Interoperability with IPv6 non-SPRING nodes will be described in a 600 future document. 602 7. OAM 604 The SPRING WG should provide OAM and the management needed to manage 605 SPRING enabled networks. The SPRING procedures may also be used as a 606 tool for OAM in SPRING enabled networks. 608 OAM use cases and requirements are described in 609 [I-D.geib-spring-oam-usecase] and 610 [I-D.kumar-spring-sr-oam-requirement]. 612 8. Security 614 There is an assumed trust model such that any node imposing an 615 explicit route on a packet is assumed to be allowed to do so. In 616 such context trust boundaries should strip explicit routes from a 617 packet. 619 For each data plane technology that SPRING specifies, a security 620 analysis must be provided showing how protection is provided against 621 an attacker disrupting the network by for example, maliciously 622 injecting SPRING packets. 624 9. IANA Considerations 626 TBD 628 10. Manageability Considerations 630 TBD 632 11. Security Considerations 634 TBD 636 12. Acknowledgements 638 The authors would like to thank Yakov Rekhter for his contribution to 639 this document. 641 13. References 642 13.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, March 1997. 647 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 648 (IPv6) Specification", RFC 2460, December 1998. 650 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 651 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 652 RFC 6564, April 2012. 654 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 655 the IP Flow Information Export (IPFIX) Protocol for the 656 Exchange of Flow Information", STD 77, RFC 7011, 657 September 2013. 659 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 660 of IPv6 Extension Headers", RFC 7045, December 2013. 662 13.2. Informative References 664 [I-D.crabbe-pce-pce-initiated-lsp] 665 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 666 Extensions for PCE-initiated LSP Setup in a Stateful PCE 667 Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in 668 progress), October 2013. 670 [I-D.filsfils-rtgwg-segment-routing] 671 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 672 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 673 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 674 "Segment Routing Architecture", 675 draft-filsfils-rtgwg-segment-routing-01 (work in 676 progress), October 2013. 678 [I-D.filsfils-spring-segment-routing-ldp-interop] 679 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 680 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 681 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 682 "Segment Routing interoperability with LDP", 683 draft-filsfils-spring-segment-routing-ldp-interop-00 (work 684 in progress), October 2013. 686 [I-D.filsfils-spring-segment-routing-mpls] 687 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 688 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 689 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 690 "Segment Routing with MPLS data plane", 691 draft-filsfils-spring-segment-routing-mpls-00 (work in 692 progress), October 2013. 694 [I-D.filsfils-spring-segment-routing-use-cases] 695 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 696 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 697 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 698 Crabbe, "Segment Routing Use Cases", 699 draft-filsfils-spring-segment-routing-use-cases-00 (work 700 in progress), March 2014. 702 [I-D.francois-spring-resiliency-use-case] 703 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 704 "Use-cases for Resiliency in SPRING", 705 draft-francois-spring-resiliency-use-case-01 (work in 706 progress), April 2014. 708 [I-D.geib-spring-oam-usecase] 709 Geib, R. and C. Filsfils, "Use case for a scalable and 710 topology aware MPLS data plane monitoring system", 711 draft-geib-spring-oam-usecase-01 (work in progress), 712 February 2014. 714 [I-D.ietf-i2rs-architecture] 715 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 716 Nadeau, "An Architecture for the Interface to the Routing 717 System", draft-ietf-i2rs-architecture-02 (work in 718 progress), February 2014. 720 [I-D.ietf-idr-ls-distribution] 721 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 722 Ray, "North-Bound Distribution of Link-State and TE 723 Information using BGP", draft-ietf-idr-ls-distribution-04 724 (work in progress), November 2013. 726 [I-D.ietf-pce-stateful-pce] 727 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 728 Extensions for Stateful PCE", 729 draft-ietf-pce-stateful-pce-08 (work in progress), 730 February 2014. 732 [I-D.kumar-spring-sr-oam-requirement] 733 Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. 734 Mirsky, "OAM Requirements for Segment Routing Network", 735 draft-kumar-spring-sr-oam-requirement-00 (work in 736 progress), February 2014. 738 [I-D.sivabalan-pce-segment-routing] 739 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and 740 R. Raszuk, "PCEP Extensions for Segment Routing", 741 draft-sivabalan-pce-segment-routing-02 (work in progress), 742 October 2013. 744 Authors' Addresses 746 Stefano Previdi (editor) 747 Cisco Systems, Inc. 748 Via Del Serafico, 200 749 Rome 00142 750 Italy 752 Email: sprevidi@cisco.com 754 Clarence Filsfils (editor) 755 Cisco Systems, Inc. 756 Brussels, 757 BE 759 Email: cfilsfil@cisco.com 761 Bruno Decraene 762 Orange 763 FR 765 Email: bruno.decraene@orange.com 767 Stephane Litkowski 768 Orange 769 FR 771 Email: stephane.litkowski@orange.com 773 Martin Horneffer 774 Deutsche Telekom 775 Hammer Str. 216-226 776 Muenster 48153 777 DE 779 Email: Martin.Horneffer@telekom.de 780 Ruediger Geib 781 Deutsche Telekom 782 Heinrich Hertz Str. 3-7 783 Darmstadt 64295 784 DE 786 Email: Ruediger.Geib@telekom.de 788 Rob Shakir 789 British Telecom 790 London 791 UK 793 Email: rob.shakir@bt.com 795 Robert Raszuk 796 Individual 798 Email: robert@raszuk.net