idnits 2.17.1 draft-ietf-spring-problem-statement-00.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 (May 13, 2014) is 3629 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-01 == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-mpls-01 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-segment-routing-00 == 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: November 14, 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 May 13, 2014 17 SPRING Problem Statement and Requirements 18 draft-ietf-spring-problem-statement-00 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 November 14, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Dataplanes . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. IGP-based MPLS Tunneling . . . . . . . . . . . . . . . . . . 4 77 3.1. Example of IGP-based MPLS Tunnels . . . . . . . . . . . . 4 78 4. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . 5 79 5. Traffic Engineering . . . . . . . . . . . . . . . . . . . . . 5 80 5.1. Examples of Traffic Engineering Use Cases . . . . . . . . 6 81 5.1.1. Traffic Engineering without Bandwidth Admission 82 Control . . . . . . . . . . . . . . . . . . . . . . . 6 83 5.1.2. Traffic Engineering with Bandwidth Admission Control 10 84 6. Interoperability with non-SPRING nodes . . . . . . . . . . . 14 85 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 10. Manageability Considerations . . . . . . . . . . . . . . . . 15 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 13.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 The ability for a node to specify a unicast forwarding path, other 99 than the normal shortest path, that a particular packet will 100 traverse, benefits a number of network functions, for example: 102 Some types of network virtualization, including multi-topology 103 networks and the partitioning of network resources for VPNs 105 Network, link, path and node protection such as fast re-route 107 Network programmability 109 OAM techniques 111 Simplification and reduction of network signaling components 113 Load balancing and traffic engineering 115 Source-based routing mechanisms have previously been specified for 116 network protocols, but have not seen widespread adoption other than 117 in MPLS traffic engineering. 119 These network functions may require greater flexibility and per 120 packet source imposed routing than can be achieved through the use of 121 the previously defined methods. In the context of this charter, 122 'source' means 'the point at which the explicit route is imposed'. 124 In this context, Source Packet Routing in Networking (SPRING) 125 architecture is being defined in order to address the use cases and 126 requirements described in this document. 128 SPRING architecture should allow incremental and selective deployment 129 without any requirement of flag day or massive upgrade of all network 130 elements. 132 SPRING architecture should allow optimal virtualization: put policy 133 state in the packet header and not in the intermediate nodes along 134 the path. Hence, the policy is completely virtualized away from 135 midpoints and tail-ends. 137 SPRING architecture objective is not to replace existing source 138 routing and traffic engineering mechanisms but rather complement them 139 and address use cases where removal of signaling and path state in 140 the core is a requirement. 142 2. Dataplanes 144 The SPRING architecture should be general in order to ease its 145 applicability to different dataplanes. 147 MPLS dataplane doesn't require any modification in order to apply a 148 source-based routed model (e.g.: 149 [I-D.filsfils-spring-segment-routing-mpls]). 151 IPv6 specification [RFC2460], amended by [RFC6564] and [RFC7045], 152 defines the Routing Extension Header which provides IPv6 source-based 153 routing capabilities. 155 The SPRING architecture should leverage existing MPLS dataplane 156 without any modification and leverage IPv6 dataplane with a new IPv6 157 Routing Header Type (IPv6 Routing Header is defined in [RFC2460]). 159 3. IGP-based MPLS Tunneling 161 The source-based routing model, applied to the MPLS dataplane, offers 162 the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE 163 to an egress PE, with or without the expression of an explicit path 164 and without requiring forwarding plane or control plane state in 165 intermediate nodes. 167 The source-based routing model, applied to the MPLS dataplane, offers 168 the ability to tunnel unicast services (VPN, VPLS, VPWS) from an 169 ingress PE to an egress PE, with or without the expression of an 170 explicit path and without requiring forwarding plane or control plane 171 state in intermediate nodes. p2mp and mp2mp tunnels are out of the 172 scope of this document. 174 3.1. Example of IGP-based MPLS Tunnels 176 This section illustrates an example use-case taken from 177 [I-D.filsfils-spring-segment-routing-use-cases]. 179 P1---P2 180 / \ 181 A---CE1---PE1 PE2---CE2---Z 182 \ / 183 P3---P4 185 Figure 1: IGP-based MPLS Tunneling 187 In Figure 1 above, the four nodes A, CE1, CE2 and Z are part of the 188 same VPN. CE2 advertises to PE2 a route to Z. PE2 binds a local 189 label LZ to that route and propagates the route and its label via 190 MPBGP to PE1 with nhop 192.168.0.2. PE1 installs the VPN prefix Z in 191 the appropriate VRF and resolves the next-hop onto the node segment 192 associated with PE2. 194 In order to cope with the reality of current deployments, the SPRING 195 architecture should allow PE to PE forwarding according to the IGP 196 shortest path without the addition of any other signaling protocol. 197 The packet each PE forwards across the network will contain (within 198 their label stack) the necessary information derived from the 199 topology database in order to deliver the packet to the remote PE. 201 4. Fast Reroute 203 FRR technologies have been deployed by network operators in order to 204 cope with link or node failures through pre-computation of backup 205 paths. 207 The SPRING architecture should address following requirements: 209 o support of FRR on any topology 211 o pre-computation and setup of backup path without any additional 212 signaling (other than the regular IGP/BGP protocols) 214 o support of shared risk constraints 216 o support of node and link protection 218 o support of microloop avoidance 220 Further illustrations of the problem statement for FRR are to be 221 found in [I-D.francois-spring-resiliency-use-case]. 223 5. Traffic Engineering 225 Traffic Engineering has been addressed using IGP protocol extensions 226 (for resources information propagation) and RSVP-TE for signaling 227 explicit paths. Different contexts and modes have been defined 228 (single vs. multiple domains, with or without bandwidth admission 229 control, centralized vs. distributed path computation, etc). 231 In all cases, one of the major components of the TE architecture is 232 the soft state based signaling protocol (RSVP-TE) which is used in 233 order to signal and establish the explicit path. Each path, once 234 computed, need to be signaled and state for each path must be present 235 in each node traversed by the path. This incurs a scalability 236 problem especially in the context of SDN where traffic 237 differentiation may be done at a finer granularity (e.g.: application 238 specific). Also the amount of state needed to be maintained and 239 periodically refreshed in all involved nodes contributes 240 significantly to complexity and the number of failures cases, and 241 thus increases operational effort while decreasing overall network 242 reliability. 244 The source-based routing model allows traffic engineering to be 245 implemented without the need of a signaling component. 247 The SPRING architecture should support traffic engineering, 248 including: 250 o loose or strict options 252 o bandwidth admission control 254 o distributed vs. centralized model (PCE, SDN Controller) 256 o disjointness in dual-plane networks 258 o egress peering traffic engineering 260 o load-balancing among non-parallel links 262 o Limiting (scalable, preferably zero) per-service state and 263 signaling on midpoint and tail-end routers. 265 o ECMP-awareness 267 o node resiliency property (i.e.: the traffic-engineering policy is 268 not anchored to a specific core node whose failure could impact 269 the service. 271 5.1. Examples of Traffic Engineering Use Cases 273 As documented in [I-D.filsfils-spring-segment-routing-use-cases] here 274 follows the description of two sets of use cases: 276 o Traffic Engineering without Admission Control 278 o Traffic Engineering with Admission Control 280 5.1.1. Traffic Engineering without Bandwidth Admission Control 282 In this section, we describe Traffic Engineering use-cases without 283 bandwidth admission control. 285 5.1.1.1. Disjointness in dual-plane networks 287 Many networks are built according to the dual-plane design, as 288 illustrated in Figure 2: 290 Each access region k is connected to the core by two C routers 291 (C(1,k) and C(2,k)). 293 C(1,k) is part of plane 1 and aggregation region K 295 C(2,k) is part of plane 2 and aggregation region K 297 C(1,k) has a link to C(2, j) iff k = j. 299 The core nodes of a given region are directly connected. 300 Inter-region links only connect core nodes of the same plane. 302 {C(1,k) has a link to C(1, j)} iff {C(2,k) has a link to C(2, j)}. 304 The distribution of these links depends on the topological 305 properties of the core of the AS. The design rule presented 306 above specifies that these links appear in both core planes. 308 We assume a common design rule found in such deployments: the inter- 309 plane link costs (Cik-Cjk where i<>j) are set such that the route to 310 an edge destination from a given plane stays within the plane unless 311 the plane is partitioned. 313 Edge Router A 314 / \ 315 / \ 316 / \ Agg Region A 317 / \ 318 / \ 319 C1A----------C2A 320 | \ | \ 321 | \ | \ 322 | C1B----------C2B 323 Plane1 | | | | Plane2 324 | | | | 325 C1C--|-----C2C | 326 \ | \ | 327 \ | \ | 328 C1Z----------C2Z 329 \ / 330 \ / Agg Region Z 331 \ / 332 \ / 333 Edge Router Z 335 Figure 2: Dual-Plane Network and Disjointness 337 In this scenario, the operator requires the ability to deploy 338 different strategies. For example, A should be able to use the three 339 following options: 341 o the traffic is load-balanced across any ECMP path through the 342 network 344 o the traffic is load-balanced across any ECMP path within the 345 Plane1 of the network 347 o the traffic is load-balanced across any ECMP path within the 348 Plane2 of the network 350 Most of the data traffic from A to Z would use the first option, such 351 as to exploit the capacity efficiently. The operator would use the 352 two other choices for specific premium traffic that has requested 353 disjoint transport. 355 The SPRING architecture should support this use case with the 356 following requirements: 358 o Zero per-service state and signaling on midpoint and tail-end 359 routers. 361 o ECMP-awareness. 363 o Node resiliency property: the traffic-engineering policy is not 364 anchored to a specific core node whose failure could impact the 365 service. 367 5.1.1.2. Egress Peering Traffic Engineering 369 +------+ 370 | | 371 +---D F 372 +---------+ / | AS 2 |\ +------+ 373 | |/ +------+ \| Z | 374 A C | | 375 | |\ +------+ /| AS 4 | 376 B AS1 | \ | |/ +------+ 377 | | +---E G 378 +---------+ | AS 3 | 379 +------+\ 381 Figure 3: Egress peering traffic engineering 383 Let us assume, in the network depicted in Figure 3, that: 385 C in AS1 learns about destination Z of AS 4 via two BGP paths 386 (AS2, AS4) and (AS3, AS4). 388 C may or may not be configured so to enforce next-hop-self 389 behavior before propagating the paths within AS1. 391 C may propagate all the paths to Z within AS1 (add-path). 393 C may install in its FIB only the route via AS2, or only the route 394 via AS3, or both. 396 In that context, SPRING should allow the operator of AS1 to apply the 397 following traffic-engineering policy, regardless the configured 398 behavior of next-hop-self: 400 Steer 60% of the Z-destined traffic received at A via AS2 and 40% 401 via AS3. 403 Steer 80% of the Z-destined traffic received at B via AS2 and 20% 404 via AS3. 406 While egress routers are known in the routing domain (generally 407 through their loopback address), the SPRING architecture should 408 enable following: 410 o identify the egress interfaces of an egress node 412 o identify the peering neighbors of an egress node 414 o identify the peering ASes of an egress node 416 With these identifiers known in the domain, the SPRING architecture 417 should allow an ingress node to select the exit point of a packet as 418 any combination of an egress node, an egress interface, a peering 419 neighbor, and a peering AS. 421 5.1.1.3. Load-balancing among non-parallel links 423 The SPRING architecture should allow a given node should be able to 424 load share traffic across multiple non parallel links even if these 425 ones lead to different neighbors. This may be useful to support 426 traffic engineering policies. 428 +---C---D---+ 429 | | 430 PE1---A---B-----F-----E---PE2 432 Figure 4: Multiple (non-parallel) Adjacencies 434 In the above example, the operator requires PE1 to load-balance its 435 PE2-destined traffic between the ABCDE and ABFE paths. 437 5.1.2. Traffic Engineering with Bandwidth Admission Control 439 The implementation of bandwidth admission control within a network 440 (and its possible routing consequence which consists in routing along 441 explicit paths where the bandwidth is available) requires a capacity 442 planning process. 444 The spreading of load among ECMP paths is a key attribute of the 445 capacity planning processes applied to packet-based networks. 447 5.1.2.1. Capacity Planning Process 449 Capacity Planning anticipates the routing of the traffic matrix onto 450 the network topology, for a set of expected traffic and topology 451 variations. The heart of the process consists in simulating the 452 placement of the traffic along ECMP-aware shortest-paths and 453 accounting for the resulting bandwidth usage. 455 The bandwidth accounting of a demand along its shortest-path is a 456 basic capability of any planning tool or PCE server. 458 For example, in the network topology described below, and assuming a 459 default IGP metric of 1 and IGP metric of 2 for link GF, a 1600Mbps 460 A-to-Z flow is accounted as consuming 1600Mbps on links AB and FZ, 461 800Mbps on links BC, BG and GF, and 400Mbps on links CD, DF, CE and 462 EF. 464 C-----D 465 / \ \ 466 A---B +--E--F--Z 467 \ / 468 G------+ 470 Figure 5: Capacity Planning an ECMP-based demand 472 ECMP is extremely frequent in SP, Enterprise and DC architectures and 473 it is not rare to see as much as 128 different ECMP paths between a 474 source and a destination within a single network domain. It is a key 475 efficiency objective to spread the traffic among as many ECMP paths 476 as possible. 478 This is illustrated in the below network diagram which consists of a 479 subset of a network where already 5 ECMP paths are observed from A to 480 M. 482 C 483 / \ 484 B-D-L-- 485 / \ / \ 486 A E \ 487 \ M 488 \ G / 489 \ / \ / 490 F K 491 \ / 492 I 494 Figure 6: ECMP Topology Example 496 When the capacity planning process detects that a traffic growth 497 scenario and topology variation would lead to congestion, a capacity 498 increase is triggered and if it cannot be deployed in due time, a 499 traffic engineering solution is activated within the network. 501 A basic traffic engineering objective consists of finding the 502 smallest set of demands that need to be routed off their shortest 503 path to eliminate the congestion, then to compute an explicit path 504 for each of them and instantiating these traffic-engineered policies 505 in the network. 507 SPRING architecture should offer a simple support for ECMP-based 508 shortest path placement as well as for explicit path policy without 509 incurring additional signaling in the domain. This includes: 511 o the ability to steer a packet across a set of ECMP paths 513 o the ability to diverge from a set of ECMP shortest paths to one or 514 more paths not in the set of shortest paths 516 5.1.2.2. SDN/SR use-case 518 The SDN use-case lies in the SDN controller, (e.g.: Stateful PCE as 519 described in [I-D.ietf-pce-stateful-pce]. 521 The SDN controller is responsible to control the evolution of the 522 traffic matrix and topology. It accepts or denies the addition of 523 new traffic into the network. It decides how to route the accepted 524 traffic. It monitors the topology and upon topological change, 525 determines the minimum traffic that should be rerouted on an 526 alternate path to alleviate a bandwidth congestion issue. 528 The algorithms supporting this behavior are a local matter of the SDN 529 controller and are outside the scope of this document. 531 The means of collecting traffic and topology information are the same 532 as what would be used with other SDN-based traffic-engineering 533 solutions (e.g. [RFC7011] and [I-D.ietf-idr-ls-distribution]. 535 The means of instantiating policy information at a traffic- 536 engineering head-end are the same as what would be used with other 537 SDN-based traffic-engineering solutions (e.g.: 538 [I-D.ietf-i2rs-architecture], [I-D.crabbe-pce-pce-initiated-lsp] and 539 [I-D.sivabalan-pce-segment-routing]). 541 In the context of Centralized-Based Optimization and the SDN use- 542 case, here are the benefits that the SPRING architecture should 543 deliver: 545 Explicit routing capability with or without ECMP-awareness. 547 No signaling hop-by-hop through the network. 549 State is only maintained at the policy head-end. No state is 550 maintained at mid-points and tail-ends. 552 Automated guaranteed FRR for any topology. 554 Optimum virtualization: the policy state is in the packet header 555 and not in the intermediate nodes along the path. The policy is 556 completely virtualized away from midpoints and tail-ends. 558 Highly responsive to change: the SDN Controller only needs to 559 apply a policy change at the head-end. No delay is introduced due 560 to programming the midpoints and tail-end along the path. 562 5.1.2.2.1. SDN Example 564 The data-set consists in a full-mesh of 12000 explicitly-routed 565 tunnels observed on a real network. These tunnels resulted from 566 distributed headend-based CSPF computation. 568 We measured that only 65% of the traffic is forwarded over its 569 shortest path. 571 Three well-known defects are illustrated in this data set: 573 The lack of ECMP support in explicitly routed tunnels: ATM-alike 574 traffic-steering mechanisms steer the traffic along a non-ECMP 575 path. 577 The increase of the number of explicitly-routed non-ECMP tunnels 578 to enumerate all the ECMP options. 580 The inefficiency of distributed optimization: too much traffic is 581 forwarded off its shortest path. 583 We applied the SDN use-case to this dataset implying a source route 584 model where the path of the packet is encoded within the packet 585 itself. This means that: 587 The distributed CSPF computation is replaced by centralized 588 optimization and BW admission control, supported by the SDN 589 Controller. 591 As part of the optimization, we also optimized the IGP-metrics 592 such as to get a maximum of traffic load-spread among ECMP 593 paths by default. 595 The traffic-engineering policies are supported by a source route 596 model (e.g.: [I-D.filsfils-spring-segment-routing]). 598 As a result, we measured that 98% of the traffic would be kept on its 599 normal policy (over the shortest-path) and only 2% of the traffic 600 requires a path away from the shortest-path. 602 Let us highlight a few benefits: 604 98% of the traffic-engineering head-end policies are eliminated. 606 Indeed, by default, an ingress edge node capable of injecting 607 source routed packets steers the traffic to the egress edge 608 node. No configuration or policy needs to be maintained at the 609 ingress edge node to realize this. 611 100% of the states at mid/tail nodes are eliminated. 613 6. Interoperability with non-SPRING nodes 615 SPRING must inter-operate with non-SPRING nodes. 617 An illustration of interoperability between SPRING and other MPLS 618 Signalling Protocols (LDP) is described here in 619 [I-D.filsfils-spring-segment-routing-ldp-interop]. 621 Interoperability with IPv6 non-SPRING nodes will be described in a 622 future document. 624 7. OAM 626 The SPRING WG should provide OAM and the management needed to manage 627 SPRING enabled networks. The SPRING procedures may also be used as a 628 tool for OAM in SPRING enabled networks. 630 OAM use cases and requirements are described in 631 [I-D.geib-spring-oam-usecase] and 632 [I-D.kumar-spring-sr-oam-requirement]. 634 8. Security 636 There is an assumed trust model such that any node imposing an 637 explicit route on a packet is assumed to be allowed to do so. In 638 such context trust boundaries should strip explicit routes from a 639 packet. 641 For each data plane technology that SPRING specifies, a security 642 analysis must be provided showing how protection is provided against 643 an attacker disrupting the network by for example, maliciously 644 injecting SPRING packets. 646 9. IANA Considerations 648 TBD 650 10. Manageability Considerations 652 TBD 654 11. Security Considerations 656 TBD 658 12. Acknowledgements 660 The authors would like to thank Yakov Rekhter for his contribution to 661 this document. 663 13. References 665 13.1. Normative References 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, March 1997. 670 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 671 (IPv6) Specification", RFC 2460, December 1998. 673 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 674 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 675 RFC 6564, April 2012. 677 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 678 of IPv6 Extension Headers", RFC 7045, December 2013. 680 13.2. Informative References 682 [I-D.crabbe-pce-pce-initiated-lsp] 683 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 684 Extensions for PCE-initiated LSP Setup in a Stateful PCE 685 Model", draft-crabbe-pce-pce-initiated-lsp-03 (work in 686 progress), October 2013. 688 [I-D.filsfils-spring-segment-routing-ldp-interop] 689 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 690 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 691 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 692 "Segment Routing interoperability with LDP", draft- 693 filsfils-spring-segment-routing-ldp-interop-01 (work in 694 progress), April 2014. 696 [I-D.filsfils-spring-segment-routing-mpls] 697 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 698 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 699 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 700 "Segment Routing with MPLS data plane", draft-filsfils- 701 spring-segment-routing-mpls-01 (work in progress), April 702 2014. 704 [I-D.filsfils-spring-segment-routing-use-cases] 705 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 706 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 707 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 708 Crabbe, "Segment Routing Use Cases", draft-filsfils- 709 spring-segment-routing-use-cases-00 (work in progress), 710 March 2014. 712 [I-D.filsfils-spring-segment-routing] 713 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 714 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 715 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 716 "Segment Routing Architecture", draft-filsfils-spring- 717 segment-routing-00 (work in progress), April 2014. 719 [I-D.francois-spring-resiliency-use-case] 720 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 721 "Use-cases for Resiliency in SPRING", draft-francois- 722 spring-resiliency-use-case-02 (work in progress), April 723 2014. 725 [I-D.geib-spring-oam-usecase] 726 Geib, R. and C. Filsfils, "Use case for a scalable and 727 topology aware MPLS data plane monitoring system", draft- 728 geib-spring-oam-usecase-01 (work in progress), February 729 2014. 731 [I-D.ietf-i2rs-architecture] 732 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 733 Nadeau, "An Architecture for the Interface to the Routing 734 System", draft-ietf-i2rs-architecture-02 (work in 735 progress), February 2014. 737 [I-D.ietf-idr-ls-distribution] 738 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 739 Ray, "North-Bound Distribution of Link-State and TE 740 Information using BGP", draft-ietf-idr-ls-distribution-04 741 (work in progress), November 2013. 743 [I-D.ietf-pce-stateful-pce] 744 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 745 Extensions for Stateful PCE", draft-ietf-pce-stateful- 746 pce-08 (work in progress), February 2014. 748 [I-D.kumar-spring-sr-oam-requirement] 749 Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. 750 Mirsky, "OAM Requirements for Segment Routing Network", 751 draft-kumar-spring-sr-oam-requirement-00 (work in 752 progress), February 2014. 754 [I-D.sivabalan-pce-segment-routing] 755 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and 756 R. Raszuk, "PCEP Extensions for Segment Routing", draft- 757 sivabalan-pce-segment-routing-02 (work in progress), 758 October 2013. 760 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 761 the IP Flow Information Export (IPFIX) Protocol for the 762 Exchange of Flow Information", STD 77, RFC 7011, September 763 2013. 765 Authors' Addresses 767 Stefano Previdi (editor) 768 Cisco Systems, Inc. 769 Via Del Serafico, 200 770 Rome 00142 771 Italy 773 Email: sprevidi@cisco.com 775 Clarence Filsfils (editor) 776 Cisco Systems, Inc. 777 Brussels 778 BE 780 Email: cfilsfil@cisco.com 781 Bruno Decraene 782 Orange 783 FR 785 Email: bruno.decraene@orange.com 787 Stephane Litkowski 788 Orange 789 FR 791 Email: stephane.litkowski@orange.com 793 Martin Horneffer 794 Deutsche Telekom 795 Hammer Str. 216-226 796 Muenster 48153 797 DE 799 Email: Martin.Horneffer@telekom.de 801 Ruediger Geib 802 Deutsche Telekom 803 Heinrich Hertz Str. 3-7 804 Darmstadt 64295 805 DE 807 Email: Ruediger.Geib@telekom.de 809 Rob Shakir 810 British Telecom 811 London 812 UK 814 Email: rob.shakir@bt.com 816 Robert Raszuk 817 Individual 819 Email: robert@raszuk.net