idnits 2.17.1 draft-dukes-spring-sr-for-sdwan-03.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 date (February 22, 2021) is 1130 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: 'SDWAN-C' is mentioned on line 139, but not defined == Missing Reference: 'SR-C' is mentioned on line 153, but not defined == Missing Reference: 'C3' is mentioned on line 164, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 7 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: August 26, 2021 G. Dawra 6 LinkedIn 7 X. Xu 8 Alibaba 9 D. Voyer 10 Bell Canada 11 P. Camarillo 12 F. Clad 13 Cisco Systems 14 S. Salsano 15 Univ. of Rome Tor Vergata 16 February 22, 2021 18 SR For SDWAN: VPN with Underlay SLA 19 draft-dukes-spring-sr-for-sdwan-03 21 Abstract 23 This document describes how SR enables underlay Service Level 24 Agreements (SLA) to a VPN with scale and security while ensuring 25 service opacity. This solution applies to Over-The-Top VPN (OTT VPN) 26 and Software-Defined WAN (SDWAN). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 64 3. Single Provider . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Directly Connected CE to PE . . . . . . . . . . . . . . . 3 66 3.2. Best-effort Underlay Transport . . . . . . . . . . . . . 5 67 3.3. SR for Underlay SLA Differentiation . . . . . . . . . . . 6 68 3.4. Accounting . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.6. Remotely Connected (to PE) . . . . . . . . . . . . . . . 8 71 4. Multiple Providers . . . . . . . . . . . . . . . . . . . . . 8 72 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 6.1. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.3. Flexible Billing . . . . . . . . . . . . . . . . . . . . 12 77 6.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.1. Single Provider Example Using End.BM With an MPLS Core . 12 80 7.1.1. Accounting . . . . . . . . . . . . . . . . . . . . . 14 81 7.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 14 82 7.2. Single Provider Example Using MPLS From CE to PE for BSID 14 83 7.3. Single Provider Example Using SRMPLS Over UDP For CE to 84 PE Not Directly Connected Over Internet . . . . . . . . . 14 85 7.3.1. Accounting . . . . . . . . . . . . . . . . . . . . . 15 86 7.3.2. Security . . . . . . . . . . . . . . . . . . . . . . 15 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 10.1. Informative References . . . . . . . . . . . . . . . . . 15 91 10.2. Normative References . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 This document describes how SR enables underlay SLA to a VPN with 97 scale and security while ensuring service opacity. This solution 98 applies to Over-The-Top VPN (OTT VPN) with SLA differentiation, and 99 Software-Defined WAN (SDWAN) with SLA differentiation. 101 The body of this text uses SRv6 for illustration. A similar solution 102 leveraging SR-MPLS is illustrated in an appendix. 104 This document assumes familiarity with the following IETF documents: 106 o Segment Routing Architecture [I-D.ietf-spring-segment-routing] 108 o Segment Routing with MPLS data plane 109 [I-D.ietf-spring-segment-routing-mpls] 111 o IPv6 Segment Routing Header [RFC8754] 113 o SRv6 Network Programming 114 [I-D.filsfils-spring-srv6-network-programming] 116 o Segment Routing Policy For Traffic Engineering 117 [I-D.filsfils-spring-segment-routing-policy] 119 o IS-IS Extensions to Support Segment Routing over IPv6 Dataplane 120 [I-D.bashandy-isis-srv6-extensions] 122 For clarity, this version of the document uses the SDWAN example with 123 SRv6 to illustrate how SR can be used to provide underlay SLA to 124 overlay services. The journey of a packet from the left site to the 125 right site of the SDWAN Overlay is described. The solution applies 126 similarly for the return path. 128 2. Requirements Notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Single Provider 136 3.1. Directly Connected CE to PE 137 +------------+ /-----------/ 138 | SDWAN | / / 139 | Control | / [SDWAN-C]... 140 +------------+ / / : 141 /-----------/ : 142 : 143 /-------------------------------------------/ : 144 +---------+ / / : 145 | SDWAN | / [A]-----[E1]***********[E2]--------[Z] / : 146 | Overlay | / : : / : 147 +---------+/ :...... : / : 148 /-----------------------:--------:----------/ : 149 : : : 150 : : : 151 /----------/ : : : 152 +------------+ / / : : : 153 | SP | / [SR-C] / : : : 154 | Control | / : / : : : 155 +------------+ /------:---/ ....: .. : 156 : : : : 157 : : : : 158 +------------+ : /---:-------------:-------------/ : 159 | SP | : / : : / : 160 | Underlay | : / [C1]----------[C2] / : 161 +------------+ :/ \ / / : 162 : \ /--/ / : 163 /: \ / / : 164 / :...........[C3]..........................: 165 / / 166 /-------------------------------/ 168 **** = logical connection 169 :... = physical connection, between layers 170 /--\ = physical connection, within a layer 172 Figure 1: SDWAN Reference Diagram 174 An SDWAN overlay is composed of two sites A and Z, connected to the 175 Internet via edge nodes E1 and E2 respectively. E1 and E2 (customer 176 edge nodes) are connected via a Service Provider (SP) underlay to 177 form the VPN between the sites. 179 C1, C2 and C3 are nodes of the SP underlay, where C1 and C2 are 180 Provider Edge nodes. ISIS is deployed in the SP underlay with the 181 same cost on each link. 183 E1 and E2 connect to C1 and C2 respectively. The shortest path from 184 C1 to C2 is the best-effort path. The explicit path C1-C3-C2 is the 185 low-latency path. By default, traffic transported from C1 to C2 186 follows the best-effort path. By default, an SDWAN cannot benefit 187 from the low-latency path from C1 to C2. 189 The address of A is 10.10.0.10/32 and the address of Z is 190 10.26.0.26/32. E1 and E2 respectively advertise 10.10/16 and 191 10.26/16 to the SDWAN controller SDWAN-C via a secure channel over 192 the Internet. The solution is applicable to any traffic exchanged 193 between the sites, including IPv4, IPv6 or L2. For clarity, a single 194 example with IPv4 in the SDWAN Overlay is used. 196 The SP operates an SR controller SR-C capable of computing 197 constrained paths from C1 to C2. 199 3.2. Best-effort Underlay Transport 201 Let's consider the path taken by traffic from A to Z, across the 202 SDWAN, between nodes E1 and E2 with addresses E1:: and E2:: 203 respectively. 205 Host A sends a packet P to Z via E1. Packet P has source address 206 10.10.0.10 and destination address 10.26.0.26, illustrated as P 207 (10.10.0.10,10.26.0.26)(payload). E1, upon receipt of P, determines 208 E2 is the edge node to be used to reach Z. Edge node E1 encrypts, 209 encapsulates and forwards the packet P toward E2 and Z, and it is 210 handled as follow: 212 o Between A and E1 : P (10.10.0.10,10.26.0.26)(Payload) 214 o Between E1 and C1 : P 215 (E1::,E2::,NH=ESP)(NH=IPv4,(10.10.0.10,10.26.0.26)(Payload)) 217 * Note that ESP tunnel mode encapsulation, encryption and 218 authentication is assumed but not required. 220 o Between C1 and C2 : P 221 (E1::,E2::,NH=ESP)(NH=IPv4,(10.10.0.10,10.26.0.26)(Payload)) 223 o Between C2 and E2 : P (E1::,E2::,NH=ESP)( 224 NH=IPv4,(10.10.0.10,10.26.0.26)(Payload)) 226 o Between E2 and Z : P (10.10.0.10,10.26.0.26)(Payload) 228 This example illustrates that, classically (i.e., without the SR 229 solution described in this document), the SDWAN cannot leverage the 230 rich infrastructure of the SP to meet its needs. The SP is 231 constrained to offer best-effort transit which does not reflect the 232 capabilities of its infrastructure. 234 3.3. SR for Underlay SLA Differentiation 236 SR enables the SDWAN to steer selected flows through selected 237 transport paths of the SP, using the same example in Figure 1. 239 This small example, with only 3 SP routers, assumes all three support 240 SRv6. As explained in 241 [I-D.filsfils-spring-srv6-network-programming], a typical deployment 242 would only require SRv6 at a few strategic waypoints deployed through 243 the network. 245 It also assumes ISIS supports the lightweight SRv6 extension 246 described in [I-D.bashandy-isis-srv6-extensions]. 248 The illustration convention from 249 [I-D.filsfils-spring-srv6-network-programming] is used such that: 251 o SRv6 SID Cj:: is explicitly instantiated at node Cj and bound to 252 the END.PSP function. 254 o SRv6 SID C1::B21 is a Binding SID (BSID) explicitly instantiated 255 at headend C1 and bound to the SRTE policy toward 256 endpoint C2. 258 * Note the return direction would use a BSID C2::B11, bound at 259 headend C2, to the SRTE policy toward endpoint C1. 261 The Control-Plane (CP) workflow that leads to the instantiation of 262 this Binding SID will be explained in the Control-Plane section. 264 Let's again consider the path from A to Z for a packet P, but this 265 time E1 has been configured by SDWAN-C to steer packet P into a 266 preferred low-latency path of the SP bound to the binding SID C1:B21. 268 o Between A and E1 270 * P (10.10.0.10,10.26.0.26)(payload) 272 o Between E1 and C1 274 * P (E1::,C1::B21; NH=SRH)(E2::,C1::B21; SL=1; 275 NH=ESP)(NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 277 When the Binding SID C1::B21 is processed at C1, the SR TE Policy is 278 selected and the SRH for SID list is inserted into P: 280 o Between C1 and C3 281 * P (E1::,C3::;NH=SRH)(E2::,C2::,C3::; SL=2;NH=ESP) 282 (NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 284 At C3, the SegmentsLeft is decremented as the END SID C3:: is 285 processed, and C2:: is placed in the destination address: 287 o Between C3 and C2 289 * P (E1::,C2::;NH=SRH)(E2::,C2::,C3::; SL=1;NH=ESP) 290 (NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 292 At C2, the SegmentsLeft is decremented to 0, and penultimate segment 293 pop is applied as the END SID C2:: is processed and E2:: is placed in 294 the destination address while the SRH is removed: 296 o Between C2 and E2 298 * P (E1::,E2::,NH=ESP)(NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 300 Finally, E2 decrypts the packet and strips the outer header to 301 forward the original packet to Z: 303 o Between E2 and Z 305 * P (10.10.0.10,10.26.0.26)(Payload) 307 The SDWAN edge nodes (E1,E2) maintain their existing behavior of 309 o Ingress Edge Node: classify ingress traffic, determining the 310 egress edge node, selecting a local output interface, secure the 311 traffic, and forward to the chosen egress edge node. 313 o Egress Edge Node: decapsulate, decrypt and forward on the internal 314 network. 316 The only change is that the Ingress node now monitors and selects an 317 SRv6 binding SID then pushes an SRH with two SIDs. 319 Note as well that the ingress and egress edge nodes never see the 320 actual SID list used by the SP to deliver the preferred path. A 321 variation of this design allows for the BSID to be kept in the packet 322 so that the egress node can detect which packets have been steered on 323 which preferred path (for accounting or monitoring purposes). 325 This is a fairly simple example of how SRv6 binding SIDs and SR TE 326 policies may be used to provide multiple diverse paths for SDWAN 327 traffic traversing a single provider network. 329 3.4. Accounting 331 As per SRv6 network programming 332 [I-D.filsfils-spring-srv6-network-programming], each SRTE policy and 333 its bound BSID is associated with a unique traffic counter. This 334 allows the SP to implement various forms of billing and reporting to 335 the customer of the preferred path. 337 3.5. Security 339 The domain of trust security solution documented in 340 [I-D.filsfils-spring-srv6-network-programming] is utilized. 342 Specifically SEC1, SEC2 and SEC3 guarantee that external traffic to 343 the SP cannot exercise the SID's of the SP. 345 The following behavior is added: the ACL implementing SEC1 and SEC2 346 on node C1 is updated to specifically allow traffic from E1:: to 347 C1::B21. 349 Only the SDWAN edge that has ordered the preferential service can use 350 it. 352 Any other customer of the SP is unable to use the preferential path 353 bound to BSID C1::B21. 355 The SDWAN site that has ordered the preferential service is unable to 356 directly program the network of the SP using the internal SID's of 357 the SP. The SDWAN edge node is restricted to the BSID, which 358 opacifies the SP operation. 360 3.6. Remotely Connected (to PE) 362 Well known authentication technology with details provided in 363 subsequent revisions will be added, detailing the scenario with SDWAN 364 edge nodes not directly connected to the SP node terminating the 365 binding SID. 367 4. Multiple Providers 369 Well known authentication technology with details provided in 370 subsequent revisions will be added, detailing the scenario with SDWAN 371 edge nodes connected to the SP node offering binding SID via an 372 intermediate SP. 374 5. Control Plane 376 The SDWAN overlay in Figure 1 is managed by an SDWAN controller, 377 SDWAN-C. 379 The control protocols used by the SDWAN-C to signal the site routes, 380 the BSID's and the site policies (which traffic on which BSID when) 381 securely over the SP network to E1 and E2 is outside the scope of 382 this document. 384 The SP underlay operates its internal SR deployment with an SR 385 controller (SR-C). SR-C interacts with the SP's network (Cj) through 386 standardized protocols (PCE[RFC4674] , PCEP [RFC5440]/[RFC4657], BGP 387 RR[RFC4456], BGP-TE [I-D.ietf-idr-segment-routing-te-policy], BGP-LS 388 [RFC7752]) 390 Most likely, the SP would operate its underlay SLA service with a 391 service controller (SERV-C) that is separate from SR-C. To simplify 392 the illustration, this text assumes that SERV-C and SR-C are 393 integrated. 395 This section describes the high-level interaction between these 396 controllers for the low-latency use-case described in this document, 397 where an enterprise operator installs a policy in the SDWAN-C 398 requiring a low latency service between E1 and E2. 400 +----------+ 401 |Enterprise| 402 | Operator | 403 +----------+ 404 +---+ | +----------+ +-------+ +---+ 405 |E1 | | | SDWAN-C | | SR-C | |C1 | 406 +---+ | +----------+ +-------+ +---+ 407 | | | | | 408 | |-------i----->| | | 409 | |Require low | | | 410 | |latency from | | | 411 | |E1 to E2 for | | | 412 | |some traffic | | | 413 | | +------ii----> | 414 | | request service |----+ | 415 | | from E1:: to | iii | 416 | | E2:: for low |<---+ | 417 | | latency |Compute an SR| 418 | | | |Policy for E1| 419 | | |to E2 | 420 | | | | 421 | | |-----iv----->| 422 | | | Program SR TE 423 | | | Policy | 424 | | | | 425 | | |<-----v------+ 426 | |<----vi-----| Report policy 427 | |reply with | installed | 428 | |binding SID | | 429 |<-------vii----------|C1:B21:: 430 | Notify | 431 | SID C1:B21:: | 432 | for low latency 433 | E1:: to E2:: 434 | 436 Figure 2: Controlplane Flow 438 (i) The enterprise operator requests a low-latency path from site 439 E1 to site E2. It defines which traffic needs to be steered 440 on this preferred path. 442 (ii) SDWAN-C requests a low-latency service from SR-C for the 443 public address of E1 to the public address of E2. 445 (iii) SR-C computes an SR Policy to satisfy SDWAN-C's request: 447 A. SR-C maps the E1 and E2 addresses to its managed nodes C1 448 and C2. 450 B. SR-C statefully registers the SRTE policy from C1 to C2 451 for low-latency. 453 C. SR-C computes the SID list fulfilling the SLA requirement 454 (e.g. ). The stateful nature of the SRTE 455 policy ensures that the SID list is updated whenever 456 required due to network state change. 458 D. SR-C binds a stable Binding SID C1::B21 to the SRTE 459 policy. 461 (iv) SR-C programs C1 with the computed SRTE policy and the 462 selected BSID. Standardized protocols such as 463 [I-D.ietf-idr-segment-routing-te-policy] or [RFC5440] are 464 used. 466 (v) C1 installs the policy in its dataplane and reports the 467 status of the SRTE policy to SR-C using standardized 468 protocols [RFC7752] or [RFC5440] and 469 [I-D.negi-pce-segment-routing-ipv6]. 471 (vi) SR-C replies to SDWAN-C with BSID C1::B21 473 (vii) SDWAN-C programs E1 with the flow classification and steering 474 policy to insert SRv6 SID C1::B21 on the appropriate traffic 476 6. Benefits 478 6.1. Scale 480 The SP network does not hold any per-SDWAN-flow state in the core of 481 its network. 483 The SP network does not hold any complex L3-L7 flow classification at 484 the edge of its network. 486 The SP network is unaware of any policy change of the SDWAN instance 487 either in terms of which flow to classify, when to steer it and on 488 which path. 490 The SP's role only consists in statefully maintaining SRTE policies 491 at the edge of the network and maintaining a few 100's of SID's 492 inside its core network. This is the stateless property of Segment 493 Routing. 495 6.2. Privacy 497 The SP network does not share any information of its infrastructure, 498 topology, capacity, internal SID's. 500 The SDWAN instance does not share any information on its traffic 501 classification, steering policy and business logic. 503 6.3. Flexible Billing 505 The traffic destined to a BSID is individually accounted 506 [I-D.filsfils-spring-srv6-network-programming]. 508 The SP and SDWAN instance can agree on various forms of billing for 509 the usage of the preferential path. 511 6.4. Security 513 By default, the SP's SR infrastructure is protected by the simple 514 domain of trust solution documented in 515 [I-D.filsfils-spring-srv6-network-programming]. 517 A BSID (and the related preferential path) can only be accessed by 518 the specific SDWAN instance (and site) that ordered the service. 520 The security solution supports any SDWAN site connection type: 521 directly connected to the SP edge or not. 523 7. Appendix 525 7.1. Single Provider Example Using End.BM With an MPLS Core 527 Reusing the example from Section 3.3, with an SP core that supports 528 SR MPLS as defined in [I-D.ietf-spring-segment-routing-mpls]. Each 529 node C1, C2 and C3 have node-SIDs defined, resulting in labels 16001, 530 16002, and 16003 respectively. In such a case a packet from A to Z 531 has an SRv6 binding SID applied, associated with an SR policy at node 532 C1. Node C1 translates the binding SID to an MPLS label stack which 533 is pushed on the packet. 535 For example: 537 o SRv6 SID C1::B22 is a Binding SID (BSID) explicitly instantiated 538 at headend C1 and bound to the SRTE policy <16003,16002> toward 539 endpoint C2. 541 * Note the return direction would use a BSID C2::B12, bound at 542 headend C2, to the SRTE policy <16003, 16001> toward endpoint 543 C1. 545 Let's again consider the path from A to Z for a packet P where E1 has 546 been configured by SDWAN-C to steer packet P into a preferred low- 547 latency path of the SP bound to the binding SID C1::B22. 549 o Between A and E1 551 * P (10.10.0.10,10.26.0.26)(payload) 553 o Between E1 and C1 555 * P (E1::,C1::B22; NH=SRH)(E2::,C1::B22; SL=1; 556 NH=ESP)(NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 558 When the Binding SID C1::B22 is processed at C1, the SR TE Policy is 559 selected and the label stack for SID list <16003,16002> is pushed on 560 P. In practice 16003 is not pushed on the wire since it has been 561 distributed with PHP: 563 o Between C1 and C3 565 * P (16002)(E1::,E2::;NH=ESP) 566 (NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 568 At C3, 16002 is popped and PHP requires no new label be pushed as P 569 is forwarded via the link to C2: 571 o Between C3 and C2 573 * P (E1::,E2::;NH=ESP)(NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 575 At C2, there is no more label stack so it forwards E2:: using the 576 global IPv6 table toward E2: 578 o Between C2 and E2 580 * P (E1::,E2::,NH=ESP)(NH=IPv4(10.10.0.10,10.26.0.26)(Payload)) 582 Finally, E2 decrypts the packet and strips the outer header to 583 forward the original packet to Z: 585 o Between E2 and Z 587 * P (10.10.0.10,10.26.0.26)(Payload) 589 Again the only change is that the Ingress node now selects an MPLS 590 binding SID for traffic taking the lowest latency path. The Ingress 591 node has no knowledge of the SP underlay. 593 7.1.1. Accounting 595 As defined in Section 3.4 597 7.1.2. Security 599 The SRv6 SID is secured as defined in Section 3.5 601 MPLS is not enabled on the CE-to-PE link. 603 7.2. Single Provider Example Using MPLS From CE to PE for BSID 605 To be completed in future revisions 607 7.3. Single Provider Example Using SRMPLS Over UDP For CE to PE Not 608 Directly Connected Over Internet 610 Reusing the example from Section 3.3, with an SP core that supports 611 the SR MPLS extensions defined in 612 [I-D.ietf-isis-segment-routing-extensions]. Each node C1, C2 and C3 613 have node-SIDs defined, resulting in labels 16001, 16002, and 16003 614 respectively. 616 Let's again consider the path from A to Z for a packet P, but this 617 time E1 has been configured by SDWAN-C to steer packet P into a 618 preferred low-latency path of the SP bound to an MPLS binding SID. 620 For example: 622 o MPLS label 24102 is a Binding SID (BSID) explicitly instantiated 623 at headend C1 and bound to the SRTE policy <16003,16002> toward 624 endpoint C2. 626 * Note the return direction would use a BSID 24201, bound at 627 headend C2, to the SRTE policy <16003, 16001> toward endpoint 628 C1. 630 Let's again consider the path from A to Z for a packet P where E1 has 631 been configured by SDWAN-C to steer packet P into a preferred low- 632 latency path of the SP bound to the binding SID 24102. 634 o Between A and E1 636 * P (10.10.0.10,10.26.0.26)(payload) 638 o Between E1 and C1, RFC7510 UDP encapsulation of MPLS is used to 639 transport the MPLS labeled traffic. 641 * P (E1::,C1::; NH=UDP)(24102,(10.10.0.10,10.26.0.26)(Payload)) 643 When C1 receives P, it decapsulates the UDP header and pops the 644 Binding SID 24102, the SR TE Policy is selected and the label stack 645 for SID list <16003,16002> is pushed on P. In practice, 16003 is not 646 pushed on the wire since it has been distributed with PHP. 648 The remainder of this use case is identical to Section 7.1. The only 649 change is that the Ingress node now uses an MPLS binding SID 650 transported over UDP instead of an SRv6 binding SID, allowing the use 651 of an IPv6 or IPv4 transport from CE to PE. 653 7.3.1. Accounting 655 As defined in Section 3.4 657 7.3.2. Security 659 [RFC7510] defines the use of DTLS to authenticate and encrypt the 660 MPLS in UDP encapsulation between CE and PE. The authentication 661 ensures the source is authorized to send traffic to a binding SID. 663 After the source is verified as authorized, the source address and 664 Binding SID SHOULD be checked to determine if the source is permitted 665 to use the specific Binding SID in the MPLS label. 667 MPLS is not enabled on the CE-to-PE link. 669 8. IANA Considerations 671 No current considerations. 673 9. Security Considerations 675 A domain of trust is secured via methods documented in 676 [I-D.filsfils-spring-srv6-network-programming] 678 10. References 680 10.1. Informative References 682 [I-D.bashandy-isis-srv6-extensions] 683 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 684 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 685 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 686 in progress), March 2019. 688 [I-D.filsfils-spring-segment-routing-policy] 689 Filsfils, C., Sivabalan, S., Hegde, S., 690 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 691 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 692 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 693 J., Clad, F., and K. Raza, "Segment Routing Policy 694 Architecture", draft-filsfils-spring-segment-routing- 695 policy-06 (work in progress), May 2018. 697 [I-D.ietf-idr-segment-routing-te-policy] 698 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 699 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 700 Routing Policies in BGP", draft-ietf-idr-segment-routing- 701 te-policy-11 (work in progress), November 2020. 703 [I-D.ietf-isis-segment-routing-extensions] 704 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 705 Gredler, H., and B. Decraene, "IS-IS Extensions for 706 Segment Routing", draft-ietf-isis-segment-routing- 707 extensions-25 (work in progress), May 2019. 709 [I-D.ietf-spring-segment-routing] 710 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 711 Litkowski, S., and R. Shakir, "Segment Routing 712 Architecture", draft-ietf-spring-segment-routing-15 (work 713 in progress), January 2018. 715 [I-D.ietf-spring-segment-routing-mpls] 716 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 717 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 718 data plane", draft-ietf-spring-segment-routing-mpls-22 719 (work in progress), May 2019. 721 [I-D.negi-pce-segment-routing-ipv6] 722 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 723 Extensions for Segment Routing leveraging the IPv6 data 724 plane", draft-negi-pce-segment-routing-ipv6-04 (work in 725 progress), February 2019. 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 729 DOI 10.17487/RFC2119, March 1997, 730 . 732 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 733 Reflection: An Alternative to Full Mesh Internal BGP 734 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 735 . 737 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 738 Element (PCE) Communication Protocol Generic 739 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 740 2006, . 742 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 743 Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674, 744 October 2006, . 746 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 747 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 748 DOI 10.17487/RFC5440, March 2009, 749 . 751 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 752 "Encapsulating MPLS in UDP", RFC 7510, 753 DOI 10.17487/RFC7510, April 2015, 754 . 756 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 757 S. Ray, "North-Bound Distribution of Link-State and 758 Traffic Engineering (TE) Information Using BGP", RFC 7752, 759 DOI 10.17487/RFC7752, March 2016, 760 . 762 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 763 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 764 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 765 . 767 10.2. Normative References 769 [I-D.filsfils-spring-srv6-network-programming] 770 Filsfils, C., Camarillo, P., Leddy, J., 771 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 772 Network Programming", draft-filsfils-spring-srv6-network- 773 programming-07 (work in progress), February 2019. 775 Authors' Addresses 777 Darren Dukes (editor) 778 Cisco Systems 779 Canada 781 Email: ddukes@cisco.com 783 Clarence Filsfils 784 Cisco Systems 785 Belgium 787 Email: cfilsfil@cisco.com 789 Gaurav Dawra 790 LinkedIn 791 USA 793 Email: gdawra@linkedin.com 795 Xiaohu Xu 796 Alibaba 797 China 799 Email: xiaohu.xxh@alibaba-inc.com 801 Daniel Voyer 802 Bell Canada 803 Canada 805 Email: daniel.voyer@bell.ca 807 Pablo Camarillo Garvia 808 Cisco Systems 809 Spain 811 Email: pcamaril@cisco.com 812 Francois Clad 813 Cisco Systems 814 France 816 Email: fclad@cisco.com 818 Stefano Salsano 819 Univ. of Rome Tor Vergata 820 Italy 822 Email: stefano.salsano@uniroma2.it