idnits 2.17.00 (12 Aug 2021) /tmp/idnits5704/draft-xie-spring-srv6-npi-for-overlay-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (6 March 2022) is 69 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) == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-net2cloud-problem-statement-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track 6 March 2022 5 Expires: 7 September 2022 7 Network Programming Interface for Provisioning of Underlay Services to 8 Overlay Networks Using SRv6 9 draft-xie-spring-srv6-npi-for-overlay-00 11 Abstract 13 This document describes a framework and a detailed suite of network 14 programming interface (NPI) examples for provisioning of underlay 15 services to overlay networks. It provides background by reviewing 16 the growing pains that commonly faced today by enterprise for its 17 flexiable WAN sites connection. It assumes that WAN connection 18 services are and will continue to be provided by multiple underlay 19 networks operated by different administrative entities. Based on the 20 pains and the assumptions, this document propose to use SRv6 binding 21 SIDs (BSIDs) on a transport network (TN) edge router as NPI for 22 service provisioning to be accessed remotely and securely by a 23 customer router that constitutes to a higher overlay network, 24 including the requirements of such service, the illustration of how 25 it may work, and the possible applicability of the solution. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119] [RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 7 September 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 69 3. Background and the Problem . . . . . . . . . . . . . . . . . 4 70 3.1. Internet and Transport Network for WAN Transit . . . . . 4 71 3.2. Seperation of Transport Network and Access Network . . . 5 72 3.3. The Problem . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Architecture and Design Consideration of NPI . . . . . . . . 7 74 4.1. Concept and Architecture of NPI . . . . . . . . . . . . . 7 75 4.2. Transmission Association and Transmission Policy . . . . 9 76 4.3. Data-plane Consideration . . . . . . . . . . . . . . . . 10 77 4.4. Control-plane Consideration . . . . . . . . . . . . . . . 11 78 5. Requirements of NPI . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Scalable for Multiple Tenants . . . . . . . . . . . . . . 11 80 5.2. Support for Common Service . . . . . . . . . . . . . . . 12 81 5.2.1. Slice Service . . . . . . . . . . . . . . . . . . . . 12 82 5.2.2. SR-Policy Service . . . . . . . . . . . . . . . . . . 12 83 5.2.3. Multicast Service . . . . . . . . . . . . . . . . . . 13 84 5.2.4. Other Services . . . . . . . . . . . . . . . . . . . 13 85 5.3. Cost-Effective Encapsulation . . . . . . . . . . . . . . 13 86 5.4. Secure for Remote Accessing . . . . . . . . . . . . . . . 13 87 5.5. Manageability . . . . . . . . . . . . . . . . . . . . . . 14 88 6. Examples and Illustrations of NPI . . . . . . . . . . . . . . 14 89 6.1. NPI.Slice: NPI for Slicing Service . . . . . . . . . . . 15 90 6.2. NPI.SR-Policy: NPI for SR-Policy Service . . . . . . . . 16 91 6.3. NPI.Mcast: NPI for Multicast Services . . . . . . . . . . 16 92 6.4. NPI.TI-LFA: NPI for TI-LFA Services . . . . . . . . . . . 16 93 6.5. NPI.DSCP: NPI for Diffserv Services . . . . . . . . . . . 16 94 6.6. NPI Syntax and Operation . . . . . . . . . . . . . . . . 16 95 7. Applicability of NPI . . . . . . . . . . . . . . . . . . . . 17 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 101 11.2. Informative References . . . . . . . . . . . . . . . . . 20 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 This document describes a framework and a detailed suite of network 107 programming interface (NPI) examples for provisioning of underlay 108 services to overlay networks. It provides background by reviewing 109 the growing pains that commonly faced today by enterprise for its 110 flexiable WAN sites connection. It assumes that WAN connection 111 services are and will continue to be provided by multiple underlay 112 networks operated by different administrative entities. Based on the 113 pains and the assumptions, this document propose to use SRv6 binding 114 SIDs (BSIDs) on a transport network (TN) edge router as NPI for 115 service provisioning to be accessed remotely and securely by a 116 customer router that constitutes to a higher overlay network like SD- 117 WAN or CDN, including the requirements of such service, the 118 illustration of how it may work, and the possible applicability of 119 the solution. 121 2. Terms and Abbreviations 123 The following abbreviations are used in this document. 125 * AN: Access Network 127 * TN: Transport Network 129 * VN: Virtual Network 131 * VTN: Virtuan Transport Network 133 * TSN: Time-Sensitive Networking 135 * MAN: Metro Area Network 137 * WAN: Wide Area Network 139 * SD-WAN: Software-defined Wide Area Network 141 * CDN: Content Distribution Network 143 * VPN: Virtual Private Network 144 * VRF: Virtual Routing and Forwarding 146 * PE: Provider Edge 148 * CPE: Customer Premises Equipment 150 * SR: Segment Routing 152 * MPLS: Multi-Protocol Label Switching 154 * LDP: Label Distribution Protocol 156 * BGP: Border Gateway Protocol 158 * SRv6: Segment Routing over IPv6 160 * BSID: Binding Segment Identifier 162 * NBI: NorthBound Interface 164 * NSP: Network Service Provider 166 * ISP: Internet Service Provider 168 * IXP: Internet eXchange Provider 170 * SRH: Segment Routing Header 172 * TA: Transmission Association 174 * TAB: Transmission Association Database 176 * TP: Transmission Policy 178 * TPB: Transmission Policy Database 180 * NPI: Network Programming Interface 182 3. Background and the Problem 184 3.1. Internet and Transport Network for WAN Transit 186 The following figure demonstrates an network architecture that an 187 entriprise commonly uses for its WAN sites connection. On one site, 188 a network service provider (NSP) may provide Internet access and 189 Transport Network (TN) access to the same customer. On the other 190 site, NSP2 provides the Internet access (act as Internet Service 191 Provider or ISP), and NSP1 provides the TN access (act as NSP). 193 (+--+) 194 +-----+ ( ) +-----+ 195 +----| R1 |( Internet )| R2 |----+ 196 / +-----+ ( ) +-----+ \ 197 (NSP1)/ (+--+) \(NSP2) 198 / \ 199 +----+ +----+ 200 |CPE1| |CPE2| 201 +----+ +----+ 202 \ / 203 (NSP1)\ (+--+) /(NSP1) 204 \ +-----+ ( ) +-----+ / 205 +----| PE1 |( TN )| PE2 |----+ 206 | +-----+ ( ) +-----+ | 207 | (+--+) | 208 |<--Access-->|<-----Transit----->|<--Access-->| 210 Figure 1: Multiple Transit Network 212 Inside the TN, there are many services provided, like Slice 213 [I-D.ietf-teas-ietf-network-slices], SR-Policy 214 [I-D.ietf-spring-segment-routing-policy], Multicast VPN [RFC6513], 215 TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa], or simple Diffserv 216 using DSCP. They can each be deployed with different implementations 217 but provide the same or similar functions to it user instance. 219 Take Slice as an example, the network slices can be realized in 220 different technologies, including physical connections, MPLS, time- 221 sensitive networking (TSN), Flex-E, virtual transport network (VTN), 222 or virtual network (VN) for independent transportation on the same 223 infrastructure. This document uses the VTN to represent the TN 224 (default slice) or a (non-default) Network Slice in the TN. 226 3.2. Seperation of Transport Network and Access Network 228 The following figure demonstrates an network architecture that 229 further seperate Transport network (TN) and Access Network (AN). In 230 this figure, the network operator of AN, TN and Internet can be 231 different from each other. The physical connection between AN and 232 Internet/TN is pre-built by the two operators. The connection 233 between AN and CPE is provisioned on-demand. In some scenarios, the 234 AN can be an Internet exchange provider (IXP) independent of ISP and 235 NSP. In some other scenarios, the AN can be an ISP that running 236 Internet backbone as well. 238 Once a CPE is connected to AN, a customer want to selects its WAN 239 transit service between site of CPE1 to site of CPE2 in a flexiable 240 way. For example, CPE1 may want to use the following policy for its 241 different flows: 243 * For flows to CPE2 with characteristics X, use TN (default slice) 244 to transmit. 246 * For flows to CPE2 with characteristics Y, use TN (non-default) 247 slice Y to transmit. 249 * For other flows to CPE2, use Internet to transmit. 251 In some circumstances, an enterprise may want even more flexiable way 252 as its flow policy in a timely manner: 254 * Test the quality of some type of TN service before it use this TN 255 service in a short time. 257 * Use some type of TN service for flows with characteristics Z for 258 some time (one month for example). 260 * Use another type of TN service for flows with characteristics Z 261 for some other time (another one month for example). 263 (+--+) 264 +-----+ ( ) +-----+ 265 +---| R1 |( Internet )| R2 |---+ 266 / +-----+ ( ) +-----+ \ 267 / (+--+) \ 268 / \ 269 / \ 270 +---+ +---+ 271 +----+ ( ) ( ) +----+ 272 |CPE1|---( AN ) ( AN )---|CPE2| 273 +----+ ( ) ( ) +----+ 274 +---+ +---+ 275 \ / 276 \ / 277 \ (+--+) / 278 \ +-----+ ( ) +-----+ / 279 +---| PE1 |( TN )| PE2 |---+ 280 +-----+ ( ) +-----+ 281 (+--+) 282 |<------Access------>|<-----Transit----->|<------Access------>| 283 Figure 2: Seperation of AN and TN 285 3.3. The Problem 287 In above figure, PE2 and CPE2 are connected through an AN. Assuming 288 that AN is an Layer-3 network serving in a local or metro area 289 network (MAN). This is different from the previous case. CPE and TN 290 are directly-connected in previous case and non-directly connected in 291 this case. 293 Conventional approach provided by VPN technology [RFC4364] depends 294 heavily on a physical or logical port-based "VRF attachment circuit". 296 A physical "VRF attachment circuit" means that a directly-connected 297 CPE1 (as described in previous section) is deployed, which needs 298 heavy manual work and costs a fairly long time. 300 A logical "VRF attachement circuit" means that a set of joint 301 segments, first a physical CPE-to-VRF attachement circuit from CPE1 302 to AN (west), then a pseudo-circuit like PW (Pseudo-Wire) service 303 from AN (west) to AN (east), and last a physical VRF-to-VRF 304 attachement circuit between AN (east) and PE1 (Each will treat the 305 other as if it were a CPE router). In this approach, adding or 306 removing port-based VRF attachement circuit(s) between AN and TN is 307 necessary when a customer requires to use the TN service in WAN area, 308 and this usually means collaboration and cost between AN operator and 309 TN operator. It also means that, a customer who wants to use various 310 transport services of TN has to depend additionally on AN. This 311 approach is practical when AN operator and TN operator are the same 312 NSP, but may be difficult for deployment when AN and TN are different 313 NSPs. In a cloud enviroument, the CPE may be an virtual CPE (vCPE) 314 located in Cloud DC and there is no direct connection between the 315 vCPE to the PE, and the challenge is also described in 316 [I-D.ietf-rtgwg-net2cloud-problem-statement]. 318 The general problem is that, the various services in a TN is not 319 accessiable to a CPE not having a direct connection to the PE of TN 320 flexibly. 322 4. Architecture and Design Consideration of NPI 324 4.1. Concept and Architecture of NPI 326 This section defines general concept and architecture of the 327 solution. 329 +---+ +---+ 330 +--+-+ ( ) ( ) +-+--+ 331 |CPE1|---( AN ) ( AN )---|CPE2| 332 +----+ ( ) ( ) +----+ 333 +---+ +---+ 334 \ / (overlay) 335 ------------\-----NPI NPI-----/----------- 336 \ / (underlay) 337 \ (+--+) / 338 \ +-----+ ( ) +-----+ / 339 +---| PE1 |( TN )| PE2 |---+ 340 +-----+ ( ) +-----+ 341 (+--+) 342 |-------Access------>|------Transit----->|-------Access------>| 344 Figure 3: NPI Reference Mode 346 It is helpful to think of the service architecture as consisting of 347 two layers: the "underlay" and the "overlay". 349 The underlay TN provides the WAN transmission infrastructure. It 350 provides the "Interfaces" on the edge router (PE) for overlay CPE to 351 use the WAN transmission capability with diverse services. The 352 overlay network uses the Interfaces provided by underlay network to 353 select a transport service for its specific set of flows to transmit 354 from on site to other(s). 356 It is helpful to understand the concept of "Network Programm 357 Interface" by comparing to a laryering mode that is usually used to 358 describe a network or protocol architecture. In the layering mode, a 359 "service interface" is defined as an interface between two software 360 modules (implementation of a protocol layer) vertically on the same 361 computer or network device. It defines the operations that local 362 module can perform on the protocol. A "peer-to-peer interface" is 363 defined as an interface between a software module (implementation of 364 a protocol layer) to its counterpart (peer) horizontally on another 365 computer or network device. It defines the form and meaning of 366 messages exchanged between protocol peers. The famous type of 367 Service Interface is provided by the Protocol modules TCP and UDP to 368 its high-level module (application) through "Application Programming 369 Interface (API)". API provides a syntax by which the services can be 370 invoked by upper layer modules (the applications), and the 371 implementation of the API is responsible for mapping the tangible set 372 of operations and objects defined by the API onto the abstract set of 373 services defined by the protocol. 375 +------------------+ +------------------+ 376 | Device 1 | | Device 2 | 377 | | | | 378 | +------------+ | | +------------+ | 379 | | High-level | | | | High-level | | 380 | | module | | | | module | | 381 | +---[+]------+ | | +---[+]------+ | 382 | | | | | | 383 | |Service | | |Service | 384 | |Interface | | |Interface | 385 | | | | | | 386 | +---[+]------+ | | +---[+]------+ | 387 | | | | | | | | 388 | | Protocol [+]------------------[+] Protocol | | 389 | | | | Peer-to-Peer | | | | 390 | +------------+ | Interface | +------------+ | 391 | | | | 392 +------------------+ +------------------+ 394 Figure 4: Layering Mode of Protocol 396 In the figure of NPI Reference Mode, the TN as a whole provides the 397 operations that a device in a higher layer network (the overlay 398 network) can invoke, through a message or packet between remote peers 399 (CPE1 and PE1 in the diagram). The layering and peering relation 400 between underlay network and overlay network is comparable to the 401 "Service Interface" and "Peer-to-peer Interface" respectively. The 402 "Network Programming Interface" provided to a higher overlay network 403 is comparable to the "Application Programming Interface" as well. 404 NPI provides a syntax and message specification by which the 405 transport service can be invoked by overlay network, and the 406 implementation of the NPI is responsible for mapping the tangible set 407 of operations and objects defined by the NPI onto the abstract set of 408 service defined by an underlay network. The flexiable use of the NPI 409 by overlay network is the so-called "programming" or "software- 410 define". 412 4.2. Transmission Association and Transmission Policy 414 This section defines management framework for implementations and 415 invokers of NPI between PE and CPE. The concept of a "Transmission 416 Association" (TA) and "Transmission Policy" (TP) is fundamental to 417 NPI. 419 Transmission Association (TA) is an object that defines the 420 transmission characteristics that can be offered by TN operator to a 421 customer. In the NPI architecture, VTN is used to represent an 422 example of the Transmission characteristics, and VRF is used to 423 represent a customer, and SRv6 BSID is used as the TA object. TA is 424 defined in PE of a TN, and all the TAs for all customers defined in a 425 PE constitutes the transmission association database (TAD). 427 Transmission Policy (TP) is a mapping from a set of flows of a 428 customer to a specific TA object. In the NPI architecture, TP is 429 defined in CPE and all the TPs defined in a CPE constructs the 430 Transmission policy database (TPD). 432 Implementations of NPI should include implementation on PE and 433 implementation on CPE seperately. Implementation on PE (of underlay 434 TN) should implement TA and TAD, and the TAD should support multiple 435 customers, meaning that VRF routing and forwarding should be built 436 for each customer. Implementation on CPE (of overlay) should 437 implement TP and TPD. The TPD on a CPE should be able to update 438 according to the change of TAs available on it. 440 4.3. Data-plane Consideration 442 The problem to be solved is how to access of Underlay network service 443 by a non-directly connected (or remote) CPE belonging to an overlay 444 network. There is no physical connection (and its secure mechanism) 445 between PE1 and CPE1, nor logical connection like E-Line (and its 446 secure mechanism) between PE1 and CPE1. 448 SRv6 Binding SID (BSID) provides a potential solution for this 449 problem for its "binding/mapping" and "reachability" capabilities 450 intrinsically. 452 SRv6 Binding SIDs (BSIDs) are configured on PE1, advertised to AN, 453 and accessed by CPE1 using IPv6 routing capability. When the CPE1 454 sends a packet (customer packet, c-packet) using SRv6 with the active 455 segment being the BSID, PE1 transits the packet to PE2 using the 456 transport service (e.g., network slice) that is bound to the BSID. 457 In a common case, it means a proper encapsulation of the c-packet by 458 PE1 to use the VTN bound to the BSID. 460 Multiple BSIDs can be configured on PE1 and each BSID is mapped to a 461 different services. Whenever a new VTN service is desired by the 462 customer, the network operator of TN only need to expose an 463 additional BSID to the customer. 465 As an example, the CPE encapsulates a received packet with an outer 466 IPv6 header where SRv6 BSID is in the destination address field to 467 indicate the VTN it uses, followed by an SRH to contain egress CPE's 468 SID as final destination. 470 4.4. Control-plane Consideration 472 PE needs to advertise the TA (SRv6 BSID) and its transmission 473 characteristics to CPE. Thus the CPE could know the available TAs 474 provided by a PE, and build or update its TPD. On the other hand, 475 the PE need to know the IPv6 prefixes relevant to the transmission 476 for a customer, and build or update the routing and forwarding 477 information for the VRF of the customer. For both case, the control- 478 plane Interface could use routing protocol like BGP, or some other 479 means like NorthBound Interface, and the detailed control-plane is 480 outside the scope of this document. 482 5. Requirements of NPI 484 5.1. Scalable for Multiple Tenants 486 A typical example, the transport network (TN) provides transmission 487 association (TA) as NPI for a customer to access its VTNs. Each TA 488 is mapped from an SRv6 BSID to a VRF (representing the customer) and 489 a VTN (representing the transmission characteristics). Multiple SRv6 490 BSIDs can serve different customers. For example, these SRv6 SIDs 491 can be configured under an SRv6 Locator for ease of management. The 492 SRv6 locator can be advertised to AN as an aggregrated prefix to make 493 it routable. Locally, the SRv6 locator can be bound to a VRF and 494 thus seperate it from other VRF or default-VRF (public VRF). 496 Following is an example on PE1: 498 * PE1 connect to AN using an interface that is bound to VRF-z. 500 * SRv6 BSID-11/12/13 are bound to customer-1 (VRF-x) VTN-1/2/3 501 respectively. 503 * SRv6 BSID-21/22/23 are bound to customer-2 (VRF-y) VTN-1/2/3 504 respectively. 506 In this example, BSID-11/12/13 and BSID-21/22/23 are allocated from 507 an SRv6 locator, and the SRv6 locator is advertised to AN and is 508 routable through AN. Locally the SRv6 locator and its SIDs are setup 509 in VRF-z context. When an PE1 receives an IPv6 packet from the 510 interface connected to AN, it performs longest-prefix-match lookup on 511 the packet's destination address in VRF-z table. The lookup will 512 return one of the following: 514 * A FIB entry that represents (BSID-11, VRF-x, VTN-1) 516 * A FIB entry that represents (BSID-12, VRF-x, VTN-2) 517 * A FIB entry that represents (BSID-13, VRF-x, VTN-3) 519 * A FIB entry that represents (BSID-21, VRF-y, VTN-1) 521 * A FIB entry that represents (BSID-22, VRF-y, VTN-2) 523 * A FIB entry that represents (BSID-23, VRF-y, VTN-3) 525 PE1 then performs a longest-prefix-match lookup on the next SID in 526 SRH (an SID of CPE2), in VTN-x or VTN-y table, to determine the next 527 hop (tunnel endpoint on TN). In the example, the next hop is PE2. 528 PE1 further performs the transmission of the packet from PE1 to PE2 529 over VTN-x or VTN-y, and this usually includes the necessay 530 encapsulation. 532 In this way, the NPI architecture can support multiple tenants and 533 multiple services in a scalable way. 535 5.2. Support for Common Service 537 5.2.1. Slice Service 539 Slice service is an emerging service that NSPs are deploying for the 540 5G and other wider use cases. The NPI should support Slice service 541 to be accessiable for overlay networks to invoke. 543 The SRv6 Binding SID for NPI can be independent to any VTN 544 implementation inside the TN. For example, the VTN can use MPLS 545 encapsulation, SR-MPLS or SRv6 encapsulation, or SRv6/SR-MPLS 546 encapsulation with any kind of additional info like SR/SRv6 policy, 547 SR/SRv6 slicing, Flex-E, etc. 549 5.2.2. SR-Policy Service 551 SR-Policy service is widely implemented and deployed in NSPs. The 552 NPI should support SR-Policy service to be accessiable for overlay 553 networks to invoke. 555 The SRv6 BSID for NPI can be independent to any SR-Policy 556 implementation inside the TN. For example, the SR-Policy can use 557 either SR-MPLS encapsulation SRv6 encapsulation for its SR-Policy 558 inside the TN, but the NPI for the overlay network to invoke is 559 through SRv6 BSID NPI. 561 5.2.3. Multicast Service 563 It is rare for Internet (ISP) to provide multicast service, but is 564 common for a TN to support multicast service (e.g., MVPN service). 565 The SRv6 BSID service should support, or be able to extend to support 566 multicast service provided by TN. The multicast service provided by 567 TN can use any data plane or control plane. For example, the data 568 plane can be MPLS, GRE or IP, and the control plane can be NG-MVPN 569 [RFC6513]. 571 5.2.4. Other Services 573 Some other services like TI-LFA, or simple DSCP/QoS can also be 574 considered as a service that could be provided by TN to Overlay 575 networks, determined by market and commercial design between TN 576 operators and Overlay network. In such case, the NPI should be 577 defined for Overlay network to invoke. 579 5.3. Cost-Effective Encapsulation 581 The SRv6 Binding SID for NPI is used for customer CPE to identify the 582 transport service it desired for a packet, and is in the destination 583 address of the packet as active segment. The real destination 584 address of the packet in the overlay is the last segment in the SRH. 585 When the PE1 receives a packet with the destination address being an 586 SRv6 BSID mapping to a VTN, PE1 gets the BSID semantic from the 587 packet and transit the packet through the VTN that is bound to the 588 SRv6 BSID. Since the real destination address and customer (VRF) of 589 the packet has been obtained, the SRH should be delete before it is 590 encapsulated and transmitted through the TN, in case there is no 591 additional SID(s) other than the BSID and the real destination. A 592 Delete On-demand (DoD) flavor may be used for this purpose. 594 5.4. Secure for Remote Accessing 596 Traditionally, the security of accessing an TN service is guaranteed 597 by a strictly managed (configured) object between CPE and PE named 598 "VRF attachment circuit" [RFC4364]. The concept of "VRF accachment 599 circuit" makes the accessing of Provider Edge router a "local" 600 behavior with strict and static configuration (e.g., physical wire, 601 or/and E-Line). Such kind of strict amd static configuration per- 602 site per-customer is the pain for a flexiable and instant accessing 603 of TN WAN transport service, and is the problem to be solved. 605 In the NPI concept, the "VRF attachement circuit" is replaced by the 606 SRv6 BSID which is to be accessed remotely and securely by a customer 607 router. It needs to provide the same security level as described as 608 in section 4.5 of [RFC3809]. Particularly, it needs to ensure that 609 the SRv6 SID allocated for a customer is accessed exactly by the CPE 610 belonging to the customer and no spoofed CPE could access the SRv6 611 SID. A candidate solution is to use SRH HMAC defined in [RFC8754]. 612 This solution ensures the SRv6 SID accessiable only by the serving 613 customer holding correct HMAC key(s) in a per-customer granularity. 615 5.5. Manageability 617 Use of anycast SRv6 SID in every PE of multiple TN sites can provide 618 the same access identifier for a customer. This means that, the SRv6 619 SID for NPI is allocated and managed per-customer and per-VTN. 620 Anycast SRv6 SID as a NPI can provides support when vCPE migrate from 621 one Data center to another center when vCPE uses a hard-coded "IPv6 622 address" to invoke the NPI. Alternatively, the DNS system can be 623 aided for the use of the NPI and provids the migration feature for 624 vCPE. 626 6. Examples and Illustrations of NPI 628 Following figure is a reference to illustrates the NPI examples. 630 +---+ +---+ 631 +----+ ( ) ( ) +----+ 632 |CPE1|---( AN ) ( AN )---|CPE2| 633 +----+ ( ) ( ) +----+ 634 +---+ +---+ 635 \ / (overlay) 636 ------------\----------------------------------------/------------- 637 \ / (underlay) 638 \ (+--+) / 639 \ +-----+ ( ) +-----+ / 640 +---| PE1 |( TN )| PE2 |---+ 641 +-----+ ( ) +-----+ 642 (+--+) 643 |-------Access------>|------Transit----->|-------Access------>| 644 | | | | 645 |c-pkt-invoking-NPI |c-pkt-transmitting |c-pkt | 646 | | | | 647 |(S=CPE1,D=BSID_11) |[TN encap hdr] |(S=CPE1,D=CPE2) | 648 |(SL=1,LE=0,) |(S=CPE1,D=CPE2) |(payload) | 649 |(payload) |(payload) | | 650 | | | | 652 c-pkt-invoking-NPI: Customer Packet invoking NPI (using SRv6 BSID) 653 c-pkt-transmitting: Customer Packet Transmitting through TN 654 c-pkt: Customer Packet 656 Figure 5: Reference Figure of NPI Examples 658 6.1. NPI.Slice: NPI for Slicing Service 660 PE1 receives a packet, and the destination address is an SRv6 BSID 661 bound to VTN-x, and the only left SID in SRH (with HMAC) is the final 662 destination of the overlay network - CPE2. PE1 deletes the SRH on- 663 demand, and transmits the packet using VTN-x. The "TN encap hdr" in 664 the reference mode is a kind of encapsulation that is corresponding 665 to VTN-x. 667 The TN encapsulation header corresponding to VTN-x can be based on 668 MPLS, SR-MPLS, SRv6 or any other kind of encapsulation to implement 669 the VTN-x transmitting. 671 PE1's interface connecting AN is bound to a VRF (VRF-z), and the SRv6 672 locator containing BSID_11 is also bound to the same VRF. 674 For ease of use by CPE2 of the same customer, PE2 has the same SRv6 675 BSID, we call anycast BSID, for the same purpose of using VTN-x to 676 transmit a packet from CPE2. 678 6.2. NPI.SR-Policy: NPI for SR-Policy Service 680 PE1 receives a packet, and the destination address is an SRv6 BSID 681 bound to an SR-Policy, and the only left SID in SRH (with HMAC) is 682 the final destination of the overlay network - CPE2. PE1 deletes the 683 SRH of the received packet, and re-encapsulates the packet with the 684 SR-Policy header and transmitted through the TN to PE2. The SR- 685 Policy can be SR-MPLS or SRv6 data plane. Comparing to the End.BM 686 and End.B6.Encaps/End.B6.Encaps.Red defined in [RFC8986], a delete 687 on-demand (DoD) flavor is needed to delete the SRH in the receivd 688 packet. 690 6.3. NPI.Mcast: NPI for Multicast Services 692 PE1 receives a packet, and the destination address is an SRv6 BSID 693 bound to an multicast group, and there is SRH (with HMAC) with no 694 left SID (SL=0 and LE=0). PE1 deletes the SRH of the received 695 packet, get the multicast group that is bound to the BSID, and 696 replace the destination address with the multicast group address. 697 Further, PE1 re-encapsulates the packet with proper P2MP header like 698 MPLS P2MP label-stack or mGRE header. The packet then is transmitted 699 through the TN to the PEs that receives multicast join of the 700 multicast group. 702 On the receiver site, PE2 get a multicast packet by decapsulating the 703 received packet. Further, PE2 transforms the destination address to 704 unicast address of CPE2 and send the packet to CPE2. There could be 705 some other alternatives for receiver site and the detail is outside 706 the scope of this document. 708 6.4. NPI.TI-LFA: NPI for TI-LFA Services 710 PE1 receives a packet, and the destination address is an SRv6 BSID 711 bound to null, but the TN has enabled TI-LFA as default service to 712 provide 50ms fialover guarantee. PE1 simply transfer the packet 713 through the TN to PE2 with the TI-LFA guaranteed 50ms failover. 715 6.5. NPI.DSCP: NPI for Diffserv Services 717 PE1 receives a packet, and the destination address is an SRv6 BSID 718 bound to a DSCP value representing a diffserv service in TN. PE1 719 simply transfer the packet through the TN to PE2 with the proper 720 DSCP/TOS/Traffic-Class value used for a specified queue. 722 6.6. NPI Syntax and Operation 724 The following is the NPI Syntax and Operation of the NPI examples. 726 +============+================+=======================================+ 727 | NPI Example| Message Syntax | NPI Operation | 728 +============+================+=======================================+ 729 | NPI.Slice |(DA=BSID) |Transport packet in a Slice bound to | 730 | |(SL=1,LE=0,FDA) |BSID to FDA (Final Destination Address)| 731 +------------+----------------+---------------------------------------+ 732 | NPI.SRplcy |(DA=BSID) |Transport packet in an SRpolicy bound | 733 | |(SL=1,LE=0,FDA) |to BSID to FDA | 734 +------------+----------------+---------------------------------------+ 735 | NPI.Mcast |(DA=BSID) |Transport packet to sites joined in a | 736 | |(SL=0,LE=0,HMAC)|multicast group that is bound to BSID | 737 +------------+----------------+---------------------------------------+ 738 | NPI.TILFA |(DA=BSID) |Transport packet to a site with | 739 | |(SL=1,LE=0,FDA) |50ms protection guaranteed by TI-LFA | 740 +------------+----------------+---------------------------------------+ 741 | NPI.DSCP |(DA=BSID) |Transport packet to FDA using DSCP | 742 | |(SL=1,LE=0,FDA) |bound to BSID through the TN | 743 +------------+----------------+---------------------------------------+ 745 Figure 6: NPI Syntax and Operation 747 The list is not exhaustive. In practice, any service provided by a 748 TN can have a NPI using SRv6 SID for accessing remotely and securely 749 in this framework. 751 7. Applicability of NPI 753 1. The solution provides a new approach to make various service 754 accessible to customers that need flexiable selection between 755 Internet/VTNs/Slices. 757 It provides a self-service mode for each customer to select service 758 by using the SRv6 BSID in the packet as its "transmitting request". 759 The TN edge router does not need to configure or reconfigure its 760 "steering policy" on a per-flow basis. Each customer can have very 761 flexiable policy to determine which flows to use which service in 762 which time slot. The TN is not aware of the customer's policy (TP) 763 and its timely change, but only behaves according to the active SRv6 764 BSID of a packet (TA). 766 By contrast, a northbound interface (NBI) is likely to be necessary 767 in conventional approach. A customer expresses requirements for a 768 particular service (which flows use which service) and the TN need to 769 dynamically change its configuration when the requirements changes. 771 Note that customers accessing the VTNs don't need to have a 772 "directly-connected" line to the Transport network. Any customer 773 connected to AN (usually part of Internet Service Provider, ISP) can 774 access high-quality TN transmission service in a software-define way. 776 2. This solution provides a seperation of AN and TN with very low 777 dependency of each other. 779 It encourages each operator to serve customer's requirement by using 780 its network advantage. AN operator (local operator) can uses its 781 small-area but high-bandwidth network to get more customer connected, 782 and TN operator (WAN operator) can uses its large-area network with 783 low-latency and/or ultra-reliable capabilities to get more customer 784 to use. 786 3. SRv6 BSID NPI can serve as a solution for inter-connecting 787 distributed Cloud/Edge-cloud/NFV in WAN scope as well as On-premise 788 enterprise site. 790 Using the ubiquitous AN and Internet connection, distributed Cloud/ 791 Edge-cloud/NFV in WAN scope could easily be connected for its 792 applications initially. Using the VTNs provided by TN operator, 793 advanced requirements such as ultra-reliable and/or low-latency 794 communication in WAN scope could be meet and thus enable the 795 applications to promote their performance and user experience 796 incrementally. 798 4. This solution provide an alternative evolution path for MPLS 799 network. 801 The SRv6 BSID can be deployed on edge routers of an MPLS 802 (conventional LDP/RSVP-TE MPLS or SR MPLS) network, and the MPLS data 803 plane can be used as the encapsulation for many value-added services 804 like VTN, SR-Policy, Multicast, etc. 806 Technologies including physical connections, time-sensitive 807 networking (TSN), Flex-E, etc can also be used in TN, and the 808 solution can combine with these technologies, and make these 809 technologies accessible through the SRv6 BSID Service. 811 8. Security Considerations 813 TBD. 815 9. IANA Considerations 817 Allocation is expected from IANA for implementation of the NPIs from 818 the SRv6 Endpoint Behaviors Registry. 820 +=======+============================+============+ 821 | Value | Endpoint Behavior | Reference | 822 +=======+============================+============+ 823 | TBD | NPI.Slice with DoD Flavor | This draft | 824 +-------+----------------------------+------------+ 825 | TBD | NPI.SRplcy with DoD Flavor | This draft | 826 +-------+----------------------------+------------+ 827 | TBD | NPI.Mcast with DoD Flavor | This draft | 828 +-------+----------------------------+------------+ 829 | TBD | NPI.TILFA with DoD Flavor | This draft | 830 +-------+----------------------------+------------+ 831 | TBD | NPI.DSCP with DoD Flavor | This draft | 832 +-------+----------------------------+------------+ 834 10. Acknowledgements 836 TBD. 838 11. References 840 11.1. Normative References 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, 844 DOI 10.17487/RFC2119, March 1997, 845 . 847 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 848 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 849 May 2017, . 851 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 852 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 853 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 854 . 856 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 857 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 858 (SRv6) Network Programming", RFC 8986, 859 DOI 10.17487/RFC8986, February 2021, 860 . 862 11.2. Informative References 864 [I-D.ietf-rtgwg-net2cloud-problem-statement] 865 Dunbar, L., Consulting, M., Jacquenet, C., and M. Toy, 866 "Dynamic Networks to Hybrid Cloud DCs Problem Statement", 867 Work in Progress, Internet-Draft, draft-ietf-rtgwg- 868 net2cloud-problem-statement-11, 26 July 2020, 869 . 872 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 873 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 874 Decraene, B., and D. Voyer, "Topology Independent Fast 875 Reroute using Segment Routing", Work in Progress, 876 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 877 08, 21 January 2022, . 880 [I-D.ietf-spring-segment-routing-policy] 881 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 882 P. Mattes, "Segment Routing Policy Architecture", Work in 883 Progress, Internet-Draft, draft-ietf-spring-segment- 884 routing-policy-18, 17 February 2022, 885 . 888 [I-D.ietf-teas-ietf-network-slices] 889 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 890 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 891 Network Slices", Work in Progress, Internet-Draft, draft- 892 ietf-teas-ietf-network-slices-08, 6 March 2022, 893 . 896 [RFC3809] Nagarajan, A., Ed., "Generic Requirements for Provider 897 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 898 DOI 10.17487/RFC3809, June 2004, 899 . 901 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 902 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 903 2006, . 905 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 906 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 907 2012, . 909 Author's Address 911 Jingrong Xie 912 Huawei Technologies 913 Email: xiejingrong@huawei.com