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