idnits 2.17.1 draft-dukes-sr-for-sdwan-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 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 26, 2017) is 2373 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) == Missing Reference: 'I-D.filsfils-spring-srv6-network-programming' is mentioned on line 618, but not defined == Missing Reference: 'SDWAN-C' is mentioned on line 128, but not defined == Missing Reference: 'SR-C' is mentioned on line 142, but not defined == Missing Reference: 'C3' is mentioned on line 153, but not defined == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-01 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-07 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-00 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 == Outdated reference: A later version (-04) exists of draft-negi-pce-segment-routing-ipv6-00 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Dukes, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track G. Dawra 5 Expires: April 29, 2018 P. Camarillo 6 F. Clad 7 Cisco Systems 8 S. Salsano 9 Univ. of Rome Tor Vergata 10 October 26, 2017 12 SR For SDWAN: VPN with Underlay SLA 13 draft-dukes-sr-for-sdwan-00.txt 15 Abstract 17 This document describes how SR enables underlay Service Level 18 Agreements (SLA) to a VPN with scale and security while ensuring 19 service opacity. This solution applies to Over-The-Top VPN (OTT VPN) 20 and Software-Defined WAN (SDWAN). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 29, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Single Provider . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Directly Connected CE to PE . . . . . . . . . . . . . . . 3 60 3.2. Best-effort Underlay Transport . . . . . . . . . . . . . 5 61 3.3. SR for Underlay SLA Differentiation . . . . . . . . . . . 6 62 3.4. Accounting . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.6. Remotely Connected (to PE) . . . . . . . . . . . . . . . 8 65 4. Multiple Providers . . . . . . . . . . . . . . . . . . . . . 8 66 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.3. Flexible Billing . . . . . . . . . . . . . . . . . . . . 12 71 6.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7.1. Single Provider Example Using End.BM With an MPLS Core . 12 74 7.2. Single Provider Example Using MPLS From CE to PE for BSID 12 75 7.3. Single Provider Example Using SRMPLS Over UDP For CE to 76 PE Not Directly Connected Over Internet . . . . . . . . . 12 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 10.1. Informative References . . . . . . . . . . . . . . . . . 13 81 10.2. Normative References' . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 This document describes how SR enables underlay SLA to a VPN with 87 scale and security while ensuring service opacity. This solution 88 applies to Over-The-Top VPN (OTT VPN) with SLA differentiation, and 89 Software-Defined WAN (SDWAN) with SLA differentiation. 91 The body of this text uses SRv6 for illustration. A similar solution 92 leveraging SR-MPLS is illustrated in an appendix. 94 This document assumes familiarity with the following IETF documents: 96 o Segment Routing Architecture [I-D.ietf-spring-segment-routing] 97 o Segment Routing with MPLS data plane 98 [I-D.ietf-spring-segment-routing-mpls] 100 o IPv6 Segment Routing Header [I-D.ietf-6man-segment-routing-header] 102 o SRv6 Network Programming 103 [I-D.filsfils-spring-srv6-network-programming] 105 o Segment Routing Policy For Traffic Engineering 106 [I-D.filsfils-spring-segment-routing-policy] 108 o IS-IS Extensions to Support Segment Routing over IPv6 Dataplane 109 [I-D.bashandy-isis-srv6-extensions] 111 For clarity, this version of the document uses the SDWAN example with 112 SRv6 to illustrate how SR can be used to provide underlay SLA to 113 overlay services. The journey of a packet from the left site to the 114 right site of the SDWAN Overlay is described. The solution applies 115 similarly for the return path. 117 2. Requirements Notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Single Provider 125 3.1. Directly Connected CE to PE 126 +------------+ /-----------/ 127 | SDWAN | / / 128 | Control | / [SDWAN-C]... 129 +------------+ / / : 130 /-----------/ : 131 : 132 /-------------------------------------------/ : 133 +---------+ / / : 134 | SDWAN | / [A]-----[E1]***********[E2]--------[Z] / : 135 | Overlay | / : : / : 136 +---------+/ :...... : / : 137 /-----------------------:--------:----------/ : 138 : : : 139 : : : 140 /----------/ : : : 141 +------------+ / / : : : 142 | SP | / [SR-C] / : : : 143 | Control | / : / : : : 144 +------------+ /------:---/ ....: .. : 145 : : : : 146 : : : : 147 +------------+ : /---:-------------:-------------/ : 148 | SP | : / : : / : 149 | Underlay | : / [C1]----------[C2] / : 150 +------------+ :/ \ / / : 151 : \ /--/ / : 152 /: \ / / : 153 / :...........[C3]..........................: 154 / / 155 /-------------------------------/ 157 **** = logical connection 158 :... = physical connection, between layers 159 /--\ = physical connection, within a layer 161 Figure 1: SDWAN Reference Diagram 163 An SDWAN overlay is composed of two sites A and Z, connected to the 164 Internet via edge nodes E1 and E2 respectively. E1 and E2 (customer 165 edge nodes) are connected via a Service Provider (SP) underlay to 166 form the VPN between the sites. 168 C1, C2 and C3 are nodes of the SP underlay, where C1 and C2 are 169 Provider Edge nodes. ISIS is deployed in the SP underlay with the 170 same cost on each link. 172 E1 and E2 connect to C1 and C2 respectively. The shortest path from 173 C1 to C2 is the best-effort path. The explicit path C1-C3-C2 is the 174 low-latency path. By default, traffic transported from C1 to C2 175 follows the best-effort path. By default, an SDWAN cannot benefit 176 from the low-latency path from C1 to C2. 178 The address of A is 10.10.0.10/32 and the address of Z is 179 10.26.0.26/32. E1 and E2 respectively advertise 10.10/16 and 180 10.26/16 to the SDWAN controller SDWAN-C via a secure channel over 181 the Internet. The solution is applicable to any traffic exchanged 182 between the sites, including IPv4, IPv6 or L2. For clarity, a single 183 example with IPv4 in the SDWAN Overlay is used. 185 The SP operates an SR controller SR-C capable of computing 186 constrained paths from C1 to C2. 188 3.2. Best-effort Underlay Transport 190 Let's consider the path taken by traffic from A to Z, across the 191 SDWAN, between nodes E1 and E2 with addresses E1:: and E2:: 192 respectively. 194 Host A sends a packet P to Z via E1. Packet P has source address 195 10.10.0.10 and destination address 10.26.0.26, illustrated as P 196 (10.10.0.10,10.26.0.26)(payload). E1, upon receipt of P, determines 197 E2 is the edge node to be used to reach Z. Edge node E1 encrypts, 198 encapsulates and forwards the packet P toward E2 and Z, and it is 199 handled as follow: 201 o Between A and E1 : P (10.10.0.10,10.26.0.26)(Payload) 203 o Between E1 and C1 : P 204 (E1::,E2::,NH=ESP)(NH=IPv4,(10.10.0.10,10.26.0.26)(Payload)) 206 * Note that ESP tunnel mode encapsulation, encryption and 207 authentication is assumed but not required. 209 o Between C1 and C2 : P 210 (E1::,E2::,NH=ESP)(NH=IPv4,(10.10.0.10,10.26.0.26)(Payload)) 212 o Between C2 and E2 : P (E1::,E2::,NH=ESP)( 213 NH=IPv4,(10.10.0.10,10.26.0.26)(Payload)) 215 o Between E2 and Z : P (10.10.0.10,10.26.0.26)(Payload) 217 This example illustrates that, classically (i.e., without the SR 218 solution described in this document), the SDWAN cannot leverage the 219 rich infrastructure of the SP to meet its needs. The SP is 220 constrained to offer best-effort transit which does not reflect the 221 capabilities of its infrastructure. 223 3.3. SR for Underlay SLA Differentiation 225 SR enables the SDWAN to steer selected flows through selected 226 transport paths of the SP, using the same example in Figure 1. 228 This small example, with only 3 SP routers, assumes all three support 229 SRv6. As explained in 230 [I-D.filsfils-spring-srv6-network-programming], a typical deployment 231 would only require SRv6 at a few strategic waypoints deployed through 232 the network. 234 It also assumes ISIS supports the lightweight SRv6 extension 235 described in [I-D.bashandy-isis-srv6-extensions]. 237 The illustration convention from 238 [I-D.filsfils-spring-srv6-network-programming] is used such that: 240 o SRv6 SID Cj:: is explicitly instantiated at node Cj and bound to 241 the END.PSP function. 243 o SRv6 SID C1::B21 is a Binding SID (BSID) explicitly instantiated 244 at headend C1 and bound to the SRTE policy towards 245 endpoint C2. 247 * Note the return direction would use a BSID C2::B11, bound at 248 headend C2, to the SRTE policy towards endpoint 249 C1. 251 The Control-Plane (CP) workflow that leads to the instantiation of 252 this Binding SID will be explained in the Control-Plane section. 254 Let's again consider the path from A to Z for a packet P, but this 255 time E1 has been configured by SDWAN-C to steer packet P into a 256 preferred low-latency path of the SP bound to the binding SID C1:B21. 258 o Between A and E1 260 * P (10.10.0.10,10.26.0.26)(payload) 262 o Between E1 and C1 264 * P (E1::,C1::B21; NH=SRH)(E2::,C1::B21; SL=1; 265 NH=ESP)(NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 267 When the Binding SID C1::B21 is processed at C1, the SR TE Policy is 268 selected and the SRH for SID list is inserted into P: 270 o Between C1 and C3 271 * P (E1::,C3::;NH=SRH)(E2::,C2::,C3::; SL=2;NH=ESP) 272 (NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 274 At C3, the SegmentsLeft is decremented as the END SID C3:: is 275 processed, and C2:: is placed in the destination address: 277 o Between C3 and C2 279 * P (E1::,C2::;NH=SRH)(E2::,C2::,C3::; SL=1;NH=ESP) 280 (NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 282 At C2, the SegmentsLeft is decremented to 0, and penultimate segment 283 pop is applied as the END SID C2:: is processed and E2:: is placed in 284 the destination address while the SRH is removed: 286 o Between C2 and E2 288 * P (E1::,E2::,NH=ESP)(NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 290 Finally, E2 decrypts the packet and strips the outer header to 291 forward the original packet to Z: 293 o Between E2 and Z 295 * P (10.10.0.10,10.26.0.26)(Payload) 297 The SDWAN edge nodes (E1,E2) maintain their existing behavior of 299 o Ingress Edge Node: classify ingress traffic, determining the 300 egress edge node, selecting a local output interface, secure the 301 traffic, and forward to the chosen egress edge node. 303 o Egress Edge Node: decapsulate, decrypt and forward on the internal 304 network. 306 The only change is that the Ingress node now monitors and selects an 307 SRv6 binding SID then pushes an SRH with two SIDs. 309 Note as well that the ingress and egress edge nodes never see the 310 actual SID list used by the SP to deliver the preferred path. A 311 variation of this design allows for the BSID to be kept in the packet 312 so that the egress node can detect which packets have been steered on 313 which preferred path (for accounting or monitoring purposes). 315 This is a fairly simple example of how SRv6 binding SIDs and SR TE 316 policies may be used to provide multiple diverse paths for SDWAN 317 traffic traversing a single provider network. 319 3.4. Accounting 321 As per SRv6 network programming 322 [I-D.filsfils-spring-srv6-network-programming], each SRTE policy and 323 its bound BSID is associated with a unique traffic counter. This 324 allows the SP to implement various forms of billing and reporting to 325 the customer of the preferred path. 327 3.5. Security 329 The domain of trust security solution documented in 330 [I-D.filsfils-spring-srv6-network-programming] is utilized. 332 Specifically SEC1, SEC2 and SEC3 guarantee that external traffic to 333 the SP cannot exercise the SID's of the SP. 335 The following behavior is added: the ACL implementing SEC1 and SEC2 336 on node C1 is updated to specifically allow traffic from E1:: to 337 C1::B21. 339 Only the SDWAN edge that has ordered the preferential service can use 340 it. 342 Any other customer of the SP is unable to use the preferential path 343 bound to BSID C1::B21. 345 The SDWAN site that has ordered the preferential service is unable to 346 directly program the network of the SP using the internal SID's of 347 the SP. The SDWAN edge node is restricted to the BSID, which 348 opacifies the SP operation. 350 3.6. Remotely Connected (to PE) 352 Well known authentication technology with details provided in 353 subsequent revisions will be added, detailing the scenario with SDWAN 354 edge nodes not directly connected to the SP node terminating the 355 binding SID. 357 4. Multiple Providers 359 Well known authentication technology with details provided in 360 subsequent revisions will be added, detailing the scenario with SDWAN 361 edge nodes connected to the SP node offering binding SID via an 362 intermediate SP. 364 5. Control Plane 366 The SDWAN overlay in Figure 1 is managed by an SDWAN controller, 367 SDWAN-C. 369 The control protocols used by the SDWAN-C to signal the site routes, 370 the BSID's and the site policies (which traffic on which BSID when) 371 securely over the SP network to E1 and E2 is outside the scope of 372 this document. 374 The SP underlay operates its internal SR deployment with an SR 375 controller (SR-C). SR-C interacts with the SP's network (Cj) through 376 standardized protocols (PCE[RFC4674] , PCEP [RFC5440]/[RFC4657], BGP 377 RR[RFC4456], BGP-TE [I-D.ietf-idr-segment-routing-te-policy], BGP-LS 378 [RFC7752]) 380 Most likely, the SP would operate its underlay SLA service with a 381 service controller (SERV-C) that is separate from SR-C. To simplify 382 the illustration, this text assumes that SERV-C and SR-C are 383 integrated. 385 This section describes the high-level interaction between these 386 controllers for the low-latency use-case described in this document, 387 where an enterprise operator installs a policy in the SDWAN-C 388 requiring a low latency service between E1 and E2. 390 +----------+ 391 |Enterprise| 392 | Operator | 393 +----------+ 394 +---+ | +----------+ +-------+ +---+ 395 |E1 | | | SDWAN-C | | SR-C | |C1 | 396 +---+ | +----------+ +-------+ +---+ 397 | | | | | 398 | |-------i----->| | | 399 | |Require low | | | 400 | |latency from | | | 401 | |E1 to E2 for | | | 402 | |some traffic | | | 403 | | +------ii----> | 404 | | request service |----+ | 405 | | from E1:: to | iii | 406 | | E2:: for low |<---+ | 407 | | latency |Compute an SR| 408 | | | |Policy for E1| 409 | | |to E2 | 410 | | | | 411 | | |-----iv----->| 412 | | | Program SR TE 413 | | | Policy | 414 | | | | 415 | | |<-----v------+ 416 | |<----vi-----| Report policy 417 | |reply with | installed | 418 | |binding SID | | 419 |<-------vii----------|C1:B21:: 420 | Notify | 421 | SID C1:B21:: | 422 | for low latency 423 | E1:: to E2:: 424 | 426 Figure 2: Controlplane Flow 428 (i) The enterprise operator requests a low-latency path from site 429 E1 to site E2. It defines which traffic needs to be steered 430 on this preferred path. 432 (ii) SDWAN-C requests a low-latency service from SR-C for the 433 public address of E1 to the public address of E2. 435 (iii) SR-C computes an SR Policy to satisfy SDWAN-C's request: 437 A. SR-C maps the E1 and E2 addresses to its managed nodes C1 438 and C2. 440 B. SR-C statefully registers the SRTE policy from C1 to C2 441 for low-latency. 443 C. SR-C computes the SID list fulfilling the SLA requirement 444 (e.g. ). The stateful nature of the SRTE 445 policy ensures that the SID list is updated whenever 446 required due to network state change. 448 D. SR-C binds a stable Binding SID C1::B21 to the SRTE 449 policy. 451 (iv) SR-C programs C1 with the computed SRTE policy and the 452 selected BSID. Standardized protocols such as 453 [I-D.ietf-idr-segment-routing-te-policy] or [RFC5440] are 454 used. 456 (v) C1 installs the policy in its dataplane and reports the 457 status of the SRTE policy to SR-C using standardized 458 protocols [RFC7752] or [RFC5440] and 459 [I-D.negi-pce-segment-routing-ipv6]. 461 (vi) SR-C replies to SDWAN-C with BSID C1::B21 463 (vii) SDWAN-C programs E1 with the flow classification and steering 464 policy to insert SRv6 SID C1::B21 on the appropriate traffic 466 6. Benefits 468 6.1. Scale 470 The SP network does not hold any per-SDWAN-flow state in the core of 471 its network. 473 The SP network does not hold any complex L3-L7 flow classification at 474 the edge of its network. 476 The SP network is unaware of any policy change of the SDWAN instance 477 either in terms of which flow to classify, when to steer it and on 478 which path. 480 The SP's role only consists in statefully maintaining SRTE policies 481 at the edge of the network and maintaining a few 100's of SID's 482 inside its core network. This is the stateless property of Segment 483 Routing. 485 6.2. Privacy 487 The SP network does not share any information of its infrastructure, 488 topology, capacity, internal SID's. 490 The SDWAN instance does not share any information on its traffic 491 classification, steering policy and business logic. 493 6.3. Flexible Billing 495 The traffic destined to a BSID is individually accounted 496 [I-D.filsfils-spring-srv6-network-programming]. 498 The SP and SDWAN instance can agree on various forms of billing for 499 the usage of the preferential path. 501 6.4. Security 503 By default, the SP's SR infrastructure is protected by the simple 504 domain of trust solution documented in 505 [I-D.filsfils-spring-srv6-network-programming]. 507 A BSID (and the related preferential path) can only be accessed by 508 the specific SDWAN instance (and site) that ordered the service. 510 The security solution supports any SDWAN site connection type: 511 directly connected to the SP edge or not. 513 7. Appendix 515 7.1. Single Provider Example Using End.BM With an MPLS Core 517 To be completed in future revisions 519 7.2. Single Provider Example Using MPLS From CE to PE for BSID 521 To be completed in future revisions 523 7.3. Single Provider Example Using SRMPLS Over UDP For CE to PE Not 524 Directly Connected Over Internet 526 To be completed in future revisions 528 8. IANA Considerations 530 No current considerations. 532 9. Security Considerations 534 A domain of trust is secured via methods documented in 535 [I-D.filsfils-spring-srv6-network-programming] 537 10. References 539 10.1. Informative References 541 [I-D.bashandy-isis-srv6-extensions] 542 Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene, 543 "IS-IS Extensions to Support Routing over IPv6 Dataplane", 544 draft-bashandy-isis-srv6-extensions-01 (work in progress), 545 September 2017. 547 [I-D.filsfils-spring-segment-routing-policy] 548 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 549 F., Lin, S., bogdanov@google.com, b., Horneffer, M., 550 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 551 Routing Policy for Traffic Engineering", draft-filsfils- 552 spring-segment-routing-policy-01 (work in progress), July 553 2017. 555 [I-D.ietf-6man-segment-routing-header] 556 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 557 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 558 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 559 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 560 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 561 segment-routing-header-07 (work in progress), July 2017. 563 [I-D.ietf-idr-segment-routing-te-policy] 564 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. 565 Lin, "Advertising Segment Routing Policies in BGP", draft- 566 ietf-idr-segment-routing-te-policy-00 (work in progress), 567 July 2017. 569 [I-D.ietf-spring-segment-routing] 570 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 571 and R. Shakir, "Segment Routing Architecture", draft-ietf- 572 spring-segment-routing-12 (work in progress), June 2017. 574 [I-D.ietf-spring-segment-routing-mpls] 575 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 576 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 577 data plane", draft-ietf-spring-segment-routing-mpls-10 578 (work in progress), June 2017. 580 [I-D.negi-pce-segment-routing-ipv6] 581 Negi, M., Kaladharan, P., Dhody, D., and S. Sivabalan, 582 "PCEP Extensions for Segment Routing leveraging the IPv6 583 data plane", draft-negi-pce-segment-routing-ipv6-00 (work 584 in progress), October 2017. 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, 588 DOI 10.17487/RFC2119, March 1997, 589 . 591 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 592 Reflection: An Alternative to Full Mesh Internal BGP 593 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 594 . 596 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 597 Element (PCE) Communication Protocol Generic 598 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 599 2006, . 601 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 602 Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674, 603 October 2006, . 605 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 606 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 607 DOI 10.17487/RFC5440, March 2009, 608 . 610 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 611 S. Ray, "North-Bound Distribution of Link-State and 612 Traffic Engineering (TE) Information Using BGP", RFC 7752, 613 DOI 10.17487/RFC7752, March 2016, 614 . 616 10.2. Normative References' 618 [I-D.filsfils-spring-srv6-network-programming] 619 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 620 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 621 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 622 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 623 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 624 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 625 Camarillo, "SRv6 Network Programming", draft-filsfils- 626 spring-srv6-network-programming-01 (work in progress), 627 June 2017. 629 Authors' Addresses 631 Darren Dukes (editor) 632 Cisco Systems 633 Canada 635 Email: ddukes@cisco.com 637 Clarence Filsfils 638 Cisco Systems 639 Belgium 641 Email: cfilsfil@cisco.com 643 Gaurav Dawra 644 Cisco Systems 645 USA 647 Email: gdawra@cisco.com 649 Pablo Camarillo Garvia 650 Cisco Systems 651 Spain 653 Email: pcamaril@cisco.com 655 Francois Clad 656 Cisco Systems 657 France 659 Stefano Salsano 660 Univ. of Rome Tor Vergata 661 Italy 663 Email: stefano.salsano@uniroma2.it