idnits 2.17.1 draft-ietf-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 (October 1, 2014) is 3494 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 (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-02 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-05 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-06 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-09 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-00 == Outdated reference: A later version (-03) exists of draft-kumar-spring-sr-oam-requirement-01 Summary: 1 error (**), 0 flaws (~~), 11 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: April 4, 2015 B. Decraene 6 S. Litkowski 7 Orange 8 M. Horneffer 9 Deutsche Telekom 10 R. Shakir 11 British Telecom 12 October 1, 2014 14 SPRING Problem Statement and Requirements 15 draft-ietf-spring-problem-statement-02 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'. 26 This document outlines various use cases, with their requirements, 27 that need to be taken into account by the Source Packet Routing in 28 Networking (SPRING) architecture for unicast traffic. Multicast use- 29 cases and requirements are out of scope of this document. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 4, 2015. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . 4 74 3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 4 75 4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . 5 76 5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 5 77 5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 6 78 5.1.1. Traffic Engineering without Bandwidth Admission 79 Control . . . . . . . . . . . . . . . . . . . . . . . 6 80 5.1.2. Traffic Engineering with Bandwidth Admission Control 10 81 6. Interoperability with non-SPRING nodes . . . . . . . . . . . 14 82 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 10. Manageability Considerations . . . . . . . . . . . . . . . . 14 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 14.2. Informative References . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 The ability for a node to specify a unicast forwarding path, other 97 than the normal shortest path, that a particular packet will 98 traverse, benefits a number of network functions, for example: 100 Some types of network virtualization, including multi-topology 101 networks and the partitioning of network resources for VPNs 103 Network, link, path and node protection such as fast re-route 105 Network programmability 107 OAM techniques 109 Simplification and reduction of network signaling components 111 Load balancing and traffic engineering 113 Source-based routing mechanisms have previously been specified for 114 network protocols, but have not seen widespread adoption other than 115 in MPLS traffic engineering. 117 These network functions may require greater flexibility and per 118 packet source imposed routing than can be achieved through the use of 119 the previously defined methods. In the context of this charter, 120 'source' means 'the point at which the explicit route is imposed'. 122 In this context, Source Packet Routing in Networking (SPRING) 123 architecture is being defined in order to address the use cases and 124 requirements described in this document. 126 SPRING architecture should allow incremental and selective deployment 127 without any requirement of flag day or massive upgrade of all network 128 elements. 130 SPRING architecture should allow optimal virtualization: put policy 131 state in the packet header and not in the intermediate nodes along 132 the path. Hence, the policy is completely virtualized away from 133 midpoints and tail-ends. 135 SPRING architecture objective is not to replace existing source 136 routing and traffic engineering mechanisms but rather complement them 137 and address use cases where removal of signaling and path state in 138 the core is a requirement. 140 2. Dataplanes 142 The SPRING architecture should be general in order to ease its 143 applicability to different dataplanes. 145 MPLS dataplane doesn't require any modification in order to apply a 146 source-based routed model (e.g.: 147 [I-D.filsfils-spring-segment-routing-mpls]). 149 IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045], 150 defines the Routing Extension Header which provides IPv6 source-based 151 routing capabilities. 153 The SPRING architecture should leverage existing MPLS dataplane 154 without any modification and leverage IPv6 dataplane with a new IPv6 155 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). 157 3. IGP-based MPLS Tunneling 159 The source-based routing model, applied to the MPLS dataplane, offers 160 the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE 161 to an egress PE, with or without the expression of an explicit path 162 and without requiring forwarding plane or control plane state in 163 intermediate nodes. 165 The source-based routing model, applied to the MPLS dataplane, offers 166 the ability to tunnel unicast services (VPN, VPLS, VPWS) from an 167 ingress PE to an egress PE, with or without the expression of an 168 explicit path and without requiring forwarding plane or control plane 169 state in intermediate nodes. p2mp and mp2mp tunnels are out of the 170 scope of this document. 172 3.1. Example of IGP-based MPLS Tunnels 174 This section illustrates an example use-case taken from 175 [I-D.filsfils-spring-segment-routing-use-cases]. 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. PE1 installs the VPN prefix Z in 189 the appropriate VRF and resolves the next-hop onto the node segment 190 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 4. 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 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 5. 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 5.1. Examples of Traffic Engineering Use Cases 271 As documented in [I-D.filsfils-spring-segment-routing-use-cases] here 272 follows the description of two sets of use cases: 274 o Traffic Engineering without Admission Control 276 o Traffic Engineering with Admission Control 278 5.1.1. Traffic Engineering without Bandwidth Admission Control 280 In this section, we describe Traffic Engineering use-cases without 281 bandwidth admission control. 283 5.1.1.1. Disjointness in dual-plane networks 285 Many networks are built according to the dual-plane design, as 286 illustrated in Figure 2: 288 Each access region k is connected to the core by two C routers 289 (C(1,k) and C(2,k)). 291 C(1,k) is part of plane 1 and aggregation region K 293 C(2,k) is part of plane 2 and aggregation region K 295 C(1,k) has a link to C(2, j) iff k = j. 297 The core nodes of a given region are directly connected. 298 Inter-region links only connect core nodes of the same plane. 300 {C(1,k) has a link to C(1, j)} iff {C(2,k) has a link to C(2, j)}. 302 The distribution of these links depends on the topological 303 properties of the core of the AS. The design rule presented 304 above specifies that these links appear in both core planes. 306 We assume a common design rule found in such deployments: the inter- 307 plane link costs (Cik-Cjk where i<>j) are set such that the route to 308 an edge destination from a given plane stays within the plane unless 309 the plane is partitioned. 311 Edge Router A 312 / \ 313 / \ 314 / \ Agg Region A 315 / \ 316 / \ 317 C1A----------C2A 318 | \ | \ 319 | \ | \ 320 | C1B----------C2B 321 Plane1 | | | | Plane2 322 | | | | 323 C1C--|-----C2C | 324 \ | \ | 325 \ | \ | 326 C1Z----------C2Z 327 \ / 328 \ / Agg Region Z 329 \ / 330 \ / 331 Edge Router Z 333 Figure 2: Dual-Plane Network and Disjointness 335 In this scenario, the operator requires the ability to deploy 336 different strategies. For example, A should be able to use the three 337 following options: 339 o the traffic is load-balanced across any ECMP path through the 340 network 342 o the traffic is load-balanced across any ECMP path within the 343 Plane1 of the network 345 o the traffic is load-balanced across any ECMP path within the 346 Plane2 of the network 348 Most of the data traffic from A to Z would use the first option, such 349 as to exploit the capacity efficiently. The operator would use the 350 two other choices for specific premium traffic that has requested 351 disjoint transport. 353 The SPRING architecture should support this use case with the 354 following requirements: 356 o Zero per-service state and signaling on midpoint and tail-end 357 routers. 359 o ECMP-awareness. 361 o Node resiliency property: the traffic-engineering policy is not 362 anchored to a specific core node whose failure could impact the 363 service. 365 5.1.1.2. Egress Peering Traffic Engineering 367 +------+ 368 | | 369 +---D F 370 +---------+ / | AS 2 |\ +------+ 371 | |/ +------+ \| Z | 372 A C | | 373 | |\ +------+ /| AS 4 | 374 B AS1 | \ | |/ +------+ 375 | | +---E G 376 +---------+ | AS 3 | 377 +------+\ 379 Figure 3: Egress peering traffic engineering 381 Let us assume, in the network depicted in Figure 3, that: 383 C in AS1 learns about destination Z of AS 4 via two BGP paths 384 (AS2, AS4) and (AS3, AS4). 386 C may or may not be configured so to enforce next-hop-self 387 behavior before propagating the paths within AS1. 389 C may propagate all the paths to Z within AS1 (add-path). 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, SPRING should allow the operator of AS1 to apply the 395 following traffic-engineering policy, regardless the configured 396 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 (or a source 405 node) to select the exit point of a packet as any combination of an 406 egress node, an egress interface, a peering neighbor, and a peering 407 AS. 409 5.1.1.3. Load-balancing among non-parallel links 411 The SPRING architecture should allow a given node should be able to 412 load share traffic across multiple non parallel links even if these 413 ones lead to different neighbors. This may be useful to support 414 traffic 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 5.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 5.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 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 500 o the ability to diverge from a set of ECMP shortest paths to one or 501 more paths not in the set of shortest paths 503 5.1.2.2. SDN/SR use-case 505 The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as 506 described in [I-D.ietf-pce-stateful-pce]. 508 The SDN controller is responsible to control the evolution of the 509 traffic matrix and topology. It accepts or denies the addition of 510 new traffic into the network. It decides how to route the accepted 511 traffic. It monitors the topology and upon topological change, 512 determines the minimum traffic that should be rerouted on an 513 alternate path to alleviate a bandwidth congestion issue. 515 The algorithms supporting this behavior are a local matter of the SDN 516 controller and are outside the scope of this document. 518 The means of collecting traffic and topology information are the same 519 as what would be used with other SDN-based traffic-engineering 520 solutions (e.g. [RFC7011] and [I-D.ietf-idr-ls-distribution]. 522 The means of instantiating policy information at a traffic- 523 engineering head-end are the same as what would be used with other 524 SDN-based traffic-engineering solutions (e.g.: 525 [I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and 526 [I-D.sivabalan-pce-segment-routing]). 528 In the context of Centralized-Based Optimization and the SDN use- 529 case, here are the benefits that the SPRING architecture should 530 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 5.1.2.2.1. SDN Example 551 The data-set consists in a full-mesh of 12000 explicitly-routed 552 tunnels observed on a real network. These tunnels resulted from 553 distributed headend-based CSPF computation. 555 We measured that only 65% of the traffic is forwarded over its 556 shortest path. 558 Three well-known defects are illustrated in this data set: 560 The lack of ECMP support in explicitly routed tunnels: ATM-alike 561 traffic-steering mechanisms steer the traffic along a non-ECMP 562 path. 564 The increase of the number of explicitly-routed non-ECMP tunnels 565 to enumerate all the ECMP options. 567 The inefficiency of distributed optimization: too much traffic is 568 forwarded off its shortest path. 570 We applied the SDN use-case to this dataset implying a source route 571 model where the path of the packet is encoded within the packet 572 itself. This means that: 574 The distributed CSPF computation is replaced by centralized 575 optimization and BW admission control, supported by the SDN 576 Controller. 578 As part of the optimization, we also optimized the IGP-metrics 579 such as to get a maximum of traffic load-spread among ECMP 580 paths by default. 582 The traffic-engineering policies are supported by a source route 583 model (e.g.: [I-D.filsfils-spring-segment-routing]). 585 As a result, we measured that 98% of the traffic would be kept on its 586 normal policy (over the shortest-path) and only 2% of the traffic 587 requires a path away from the shortest-path. 589 Let us highlight a few benefits: 591 98% of the traffic-engineering head-end policies are eliminated. 593 Indeed, by default, an ingress edge node capable of injecting 594 source routed packets steers the traffic to the egress edge 595 node. No configuration or policy needs to be maintained at the 596 ingress edge node to realize this. 598 100% of the states at mid/tail nodes are eliminated. 600 6. Interoperability with non-SPRING nodes 602 SPRING must inter-operate with non-SPRING nodes. 604 An illustration of interoperability between SPRING and other MPLS 605 Signalling Protocols (LDP) is described here in 606 [I-D.filsfils-spring-segment-routing-ldp-interop]. 608 Interoperability with IPv6 non-SPRING nodes will be described in a 609 future document. 611 7. OAM 613 The SPRING WG should provide OAM and the management needed to manage 614 SPRING enabled networks. The SPRING procedures may also be used as a 615 tool for OAM in SPRING enabled networks. 617 OAM use cases and requirements are described in 618 [I-D.geib-spring-oam-usecase] and 619 [I-D.kumar-spring-sr-oam-requirement]. 621 8. Security 623 There is an assumed trust model such that any node imposing an 624 explicit route on a packet is assumed to be allowed to do so. In 625 such context trust boundaries should strip explicit routes from a 626 packet. 628 For each data plane technology that SPRING specifies, a security 629 analysis must be provided showing how protection is provided against 630 an attacker disrupting the network by for example, maliciously 631 injecting SPRING packets. 633 9. IANA Considerations 635 TBD 637 10. Manageability Considerations 639 TBD 641 11. Security Considerations 643 TBD 645 12. Contributors 647 The following individuals substantially contributed to the content of 648 this documents: 650 Ruediger Geib 651 Deutsche Telekom 652 Heinrich Hertz Str. 3-7 653 Darmstadt 64295 654 DE 655 Email: Ruediger.Geib@telekom.de 657 Robert Raszuk 658 Individual 659 Email: robert@raszuk.net 661 13. Acknowledgements 663 The authors would like to thank Yakov Rekhter for his contribution to 664 this document. 666 14. References 668 14.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 674 (IPv6) Specification", RFC 2460, December 1998. 676 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 677 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 678 RFC 6564, April 2012. 680 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 681 of IPv6 Extension Headers", RFC 7045, December 2013. 683 14.2. Informative References 685 [I-D.crabbe-pce-pce-initiated-lsp] 686 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 687 Extensions for PCE-initiated LSP Setup in a Stateful PCE 688 Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in 689 progress), October 2013. 691 [I-D.filsfils-spring-segment-routing] 692 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 693 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 694 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 695 "Segment Routing Architecture", draft-filsfils-spring- 696 segment-routing-04 (work in progress), July 2014. 698 [I-D.filsfils-spring-segment-routing-ldp-interop] 699 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 700 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 701 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 702 "Segment Routing interoperability with LDP", draft- 703 filsfils-spring-segment-routing-ldp-interop-02 (work in 704 progress), September 2014. 706 [I-D.filsfils-spring-segment-routing-mpls] 707 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 708 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 709 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 710 "Segment Routing with MPLS data plane", draft-filsfils- 711 spring-segment-routing-mpls-03 (work in progress), August 712 2014. 714 [I-D.filsfils-spring-segment-routing-use-cases] 715 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 716 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 717 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 718 Crabbe, "Segment Routing Use Cases", draft-filsfils- 719 spring-segment-routing-use-cases-00 (work in progress), 720 March 2014. 722 [I-D.geib-spring-oam-usecase] 723 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 724 case for a scalable and topology aware MPLS data plane 725 monitoring system", draft-geib-spring-oam-usecase-02 (work 726 in progress), July 2014. 728 [I-D.ietf-i2rs-architecture] 729 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 730 Nadeau, "An Architecture for the Interface to the Routing 731 System", draft-ietf-i2rs-architecture-05 (work in 732 progress), July 2014. 734 [I-D.ietf-idr-ls-distribution] 735 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 736 Ray, "North-Bound Distribution of Link-State and TE 737 Information using BGP", draft-ietf-idr-ls-distribution-06 738 (work in progress), September 2014. 740 [I-D.ietf-pce-stateful-pce] 741 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 742 Extensions for Stateful PCE", draft-ietf-pce-stateful- 743 pce-09 (work in progress), June 2014. 745 [I-D.ietf-spring-resiliency-use-cases] 746 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 747 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 748 resiliency-use-cases-00 (work in progress), May 2014. 750 [I-D.kumar-spring-sr-oam-requirement] 751 Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. 752 Mirsky, "OAM Requirements for Segment Routing Network", 753 draft-kumar-spring-sr-oam-requirement-01 (work in 754 progress), July 2014. 756 [I-D.sivabalan-pce-segment-routing] 757 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 758 Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions 759 for Segment Routing", draft-sivabalan-pce-segment- 760 routing-03 (work in progress), July 2014. 762 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 763 the IP Flow Information Export (IPFIX) Protocol for the 764 Exchange of Flow Information", STD 77, RFC 7011, September 765 2013. 767 Authors' Addresses 769 Stefano Previdi (editor) 770 Cisco Systems, Inc. 771 Via Del Serafico, 200 772 Rome 00142 773 Italy 775 Email: sprevidi@cisco.com 777 Clarence Filsfils (editor) 778 Cisco Systems, Inc. 779 Brussels 780 BE 782 Email: cfilsfil@cisco.com 783 Bruno Decraene 784 Orange 785 FR 787 Email: bruno.decraene@orange.com 789 Stephane Litkowski 790 Orange 791 FR 793 Email: stephane.litkowski@orange.com 795 Martin Horneffer 796 Deutsche Telekom 797 Hammer Str. 216-226 798 Muenster 48153 799 DE 801 Email: Martin.Horneffer@telekom.de 803 Rob Shakir 804 British Telecom 805 London 806 UK 808 Email: rob.shakir@bt.com