idnits 2.17.1 draft-li-rtgwg-ipv6-based-con-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2021) is 1115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-39) exists of draft-ietf-rtgwg-net2cloud-problem-statement-11 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-05 == Outdated reference: A later version (-03) exists of draft-dukes-spring-sr-for-sdwan-02 == Outdated reference: A later version (-07) exists of draft-dunbar-sr-sdwan-over-hybrid-networks-06 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-02 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 == Outdated reference: A later version (-15) exists of draft-ietf-spring-nsh-sr-04 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-02 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-02 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-13 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-05 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-12 == Outdated reference: A later version (-14) exists of draft-chen-rtgwg-srv6-midpoint-protection-03 == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-srv6-egress-protection-02 == Outdated reference: A later version (-05) exists of draft-geng-spring-sr-redundancy-protection-00 == Outdated reference: A later version (-11) exists of draft-li-spring-srv6-security-consideration-05 == Outdated reference: A later version (-06) exists of draft-ietf-idr-bgp-ls-link-mtu-00 == Outdated reference: A later version (-08) exists of draft-ietf-idr-sr-policy-path-mtu-02 == Outdated reference: A later version (-05) exists of draft-li-pce-pcep-pmtu-03 == Outdated reference: A later version (-07) exists of draft-srcompdt-spring-compression-requirement-03 == Outdated reference: A later version (-03) exists of draft-cl-spring-generalized-srv6-np-02 == Outdated reference: A later version (-03) exists of draft-lc-6man-generalized-srh-01 == Outdated reference: A later version (-07) exists of draft-cl-spring-generalized-srv6-for-cmpr-02 == Outdated reference: A later version (-07) exists of draft-li-apn-framework-01 == Outdated reference: A later version (-03) exists of draft-li-6man-app-aware-ipv6-network-02 Summary: 0 errors (**), 0 flaws (~~), 30 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Li 3 Internet-Draft Z. Li 4 Intended status: Informational H. Yang 5 Expires: October 2, 2021 Huawei Technologies 6 March 31, 2021 8 IPv6-based Cloud-Oriented Networking (CON) 9 draft-li-rtgwg-ipv6-based-con-01 11 Abstract 13 This document describes the scenarios, requirements and technologies 14 for IPv6-based Cloud-oriented Networking. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 2, 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Underlay . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Overlay . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. IPv6-based Cloud-Oriented Networking . . . . . . . . . . . . 6 57 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1.1. Quick Connection . . . . . . . . . . . . . . . . . . 7 59 4.1.2. Hybrid Network Connection . . . . . . . . . . . . . . 7 60 4.1.3. Path Programming . . . . . . . . . . . . . . . . . . 7 61 4.1.4. Resource Assurance . . . . . . . . . . . . . . . . . 8 62 4.1.5. Deterministic Delay . . . . . . . . . . . . . . . . . 8 63 4.1.6. Service Function Chaining . . . . . . . . . . . . . . 8 64 4.1.7. Performance Measurement . . . . . . . . . . . . . . . 9 65 4.1.8. Reliability . . . . . . . . . . . . . . . . . . . . . 9 66 4.1.9. Security . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1.10. Forwarding Efficiency . . . . . . . . . . . . . . . . 9 68 4.1.11. Application-Aware Networking . . . . . . . . . . . . 10 69 4.2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.2.1. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2.2. Path Programming . . . . . . . . . . . . . . . . . . 11 72 4.2.3. Service Function Chaining . . . . . . . . . . . . . . 11 73 4.2.4. IPv6 based Network Slicing . . . . . . . . . . . . . 11 74 4.2.5. IPv6-based On-path Measurement . . . . . . . . . . . 12 75 4.2.6. Reliability . . . . . . . . . . . . . . . . . . . . . 13 76 4.2.7. Security . . . . . . . . . . . . . . . . . . . . . . 14 77 4.2.8. IPv6 Forwarding Efficiency . . . . . . . . . . . . . 14 78 4.2.9. Application-aware IPv6 Networking . . . . . . . . . . 15 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 With the development of cloud computing, increasing services have 91 been migrated from enterprises to cloud data centers. Compared with 92 interconnections between branches and headquarters, new connections 93 between enterprise sites to cloud data centers and inter-cloud are 94 added, which bring new requirements and challenges for existing 95 networks. 97 When enterprises have workloads & applications & data split among 98 different data centers, especially for those enterprises with 99 multiple sites that are already interconnected by VPNs (e.g., MPLS 100 L2VPN/L3VPN), challenges are introduced. 101 [I-D.ietf-rtgwg-net2cloud-problem-statement] describes the problems 102 that enterprises face today when interconnecting their branch offices 103 with dynamic workloads in third party data centers (a.k.a. Cloud 104 DCs). 106 SD-WAN is a flexible WAN architecture that enables flexible network- 107 to-cloud and inter-clouds connections. It supports to use 108 alternative paths like internet or 4G / 5G connection instead of 109 expensive MPLS leased lines to exchange data between sites and 110 clouds. However, when a WAN path travels multiple MPLS domains, the 111 configurations are complicated due to multiple services touch points 112 need to be configured. Therefore, it is hard to support end-to-end 113 path programming in IPv4/MPLS based SD-WAN. 115 When using VXLAN in SD-WAN, only the overlay path or anchor points 116 can be specified while the underlay forwarding path can not be 117 specified. Therefore, strict TE requirements like deterministic 118 delay, specified path forwarding can not be satisfied. 120 In order to resolve these challenges, this document propose 121 IPv6-based Cloud-Oriented Networking (CON). In addition, it 122 describes the challenges for existing networks when clouds and 123 networks are converged, requirements that IPv6-based CON should 124 satisfy, and the solutions in IPv6-based CON that satisfy the 125 requirements. 127 IPv6-based CON supports quick and flexible connections between sites 128 and clouds and inter-clouds, it also supports end-to-end path 129 programming, which can be used for many use cases, such as strict 130 path traffic engineering, deterministic delay forwarding, and service 131 function chaining, to provide better network services for cloud- 132 network and inter-cloud interconnections. 134 2. Terminology 136 This document makes use of the terms defined in [RFC8754] and 137 [RFC8200], and the reader is assumed to be familiar with that 138 terminology. This document introduces the following terms: 140 POP: Point of Presence 142 CON: Cloud-Oriented Networking. 144 EC: Edge Computing. 146 EDC: Edge Data center 148 RDC: Regional Data Center 150 CDC: Core Data Center 152 2.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. Problem Statement 162 As development of cloud, many clouds have been deployed, such as 163 Private cloud, Public Cloud, and Hybrid Cloud. The cloud services 164 can be provided by a third party, such as an OTT (Over-The-Top) 165 content provider, and it can be provided by a network operator as 166 well. Furthermore, cloud can be deployed not only in IT data centers 167 but also CT data centers. 169 With the development and successful application of cloud native 170 design in the IT field and Network Functions Virtualization (NFV) 171 technologies, virtualization and cloudification have gradually 172 matured and evolved to provide a new level of productivity, offering 173 a new approach to telecom network construction. Building cloud-based 174 telecom networks (also known as telco clouds) becomes a new way of 175 telecom network construction. 177 In order to support low latency communication, the request should be 178 responded at the near cloud data center, therefore edge computing 179 data center (a.k.a Edge Cloud) is introduced. Telecommunication 180 services and third-party OTT services can be deployed in the edge 181 cloud. 183 As the deployment of clouds, the traffic pattern in the network has 184 changed significantly, which results in new challenges for existing 185 networks. 187 3.1. Underlay 189 From the aspect of underlay, cloud services requires the network to 190 provide quick and flexible connection. 192 The typical topology of telco cloud is shown in figure 1. 194 +++++++ +++++++ ++++++ 195 | EDC | | RDC | | CDC| 196 +++++++ +++++++ ++++++ 197 | ********* | ************ | 198 | * * | * * | 199 OLT/CSG/CPE---PE--* Metro *--PE--* Backbone *--PE--IGW---Internet 200 * * * * 201 ********* ************ 203 Figure 1.Typical topology of telco cloud 205 The edge cloud is deployed in edge data center (EDC) in the access 206 network usually, so that the servers in the edge cloud can respond to 207 the delay-sensitive requests rapidly, like 5G URLLC traffic. The 208 traffic is not delay-sensitive can be responded in regional cloud DC, 209 which is located in the metro or core network. Most cloud services 210 may be deployed in the core cloud DC considering reducing the cost, 211 which is far from the end user. Like, the UPF may locate in the 212 regional cloud DC or Core cloud DC, so that it can support more 213 users. 215 The traffic from end users to cloud servers are forwarded along with 216 different paths due to the different locations of the end users and 217 the cloud servers. 219 In addition, when deploying new services, for instance, deploying a 220 leased line from an enterprise site to a cloud data center, it will 221 take probably weeks in the current IPv4/MPLS carrier network. 222 Because the VPN configuration is needed to be done at multiple PE 223 nodes if the leased line travels multiple domains (when using Option 224 A between domains). Also, the cloud operator needs to negotiate with 225 network operators if the cloud services and the network services are 226 provided by different operators. For example, thousands of chain 227 stores such as grocery stores or super markets are needed to connect 228 to their enterprise VPNs, and they may use the cloud services. 229 However, in IPv4/MPLS network, it may take weeks to establish a new 230 VPN connection from a site to headquarter or cloud tenant networks. 232 Furthermore, different traffic of different enterprise/tenant/users 233 are treated differently in clouds, and they MAY be forwarded along 234 with different service function chains (SFC). However, it is hard to 235 support SFC in IPv4 or MPLS based network in carrier's networks or 236 data center networks. Normally, to support SFC, the traffic steering 237 policies are configured at multiple nodes along the SFC path, which 238 is complicated. 240 3.2. Overlay 242 In order to provide quick and flexible cloud connection, overlay 243 connection is provided by cloud providers, especially the OTT cloud 244 providers. 246 SD-WAN is a typical fabric for DCI connection between clouds and 247 sites, which provides a cheaper and smarter WAN connection. Many SD- 248 WAN providers builds their own WAN backbone network by connecting 249 their POP GWs to provide better SLA assurance for tenants. The 250 typical topology of SD-WAN with POP GWs is shown in figure 2. 252 Site CPE1--POP GW1 --------------------------POP GW2---Site CPE2 253 | | 254 | SD-WAN Backbone | 255 | | 256 Cloud1---POP GW3---------------------------POP GW4--Cloud2 258 Figure 2. Typical topology of SD-WAN 260 Currently, the traffic from the CPE to POP GW is forwarded through 261 the shortest forwarding path over the Internet, or an MPLS tunnel. 263 In addition, traffic from POP GW to another POP GW can be forwarded 264 along with the MPLS tunnel that is a leased line, or over the 265 internet, depending on the forwarding policies. 267 When the traffic is forwarded over the internet, it can be forwarded 268 over a VXLAN tunnel. However, when using VXLAN, only the overlay 269 connection is provided to enterprises/tenants, while the underlay 270 forwarding path can not be specified and programmed. Therefore the 271 SLA requirements can not be guaranteed when the traffic is forwarded 272 overlay. 274 4. IPv6-based Cloud-Oriented Networking 276 This document describes a networking architecture called IPv6-based 277 Cloud-Oriented Networking (CON). IPv6-based CON is an IPv6-based 278 networking which provide quick, flexible connection to support 279 dynamic site to cloud, and inter-cloud connections. Also, it 280 supports end-to-end underlay forwarding path programming, so that 281 services like strict path TE and SFC can be supported better. 283 The following section describes the requirements in IPv6-based CON, 284 and the related solutions that meet the requirements. 286 4.1. Requirements 288 This section describes the overall requirements which need to be 289 fulfilled by IPv6-based Cloud-Oriented Networking. 291 4.1.1. Quick Connection 293 Enterprise sites can locate at any location around the world, they 294 need to connect to the clouds or other sites in any time, from any 295 where. Also, enterprises may have some Virtual Private Clouds (VPC) 296 in different clouds, they need to connect to each other in real time 297 as well. The servers may locate in different cloud data centers or 298 enterprise sites, which provide services for employees or other 299 users. Therefore quick connection is required in IPv6-based CON. 301 4.1.2. Hybrid Network Connection 303 The enterprise VPN traffic can be forwarded around the world, which 304 may travel heterogeneous networks, such as IPv4, MPLS and IPv6. 306 Typically, when a SD-WAN network connects multiple sites and clouds, 307 it may cover hybrid networks. For example, the sub-path from the CPE 308 to POP WG could be an IPv4 sub-path without any resource guarantee. 309 The sub-path between POP GWs could be an MPLS LSP with resource 310 reservation. 312 Therefore, connection over hybrid networks MUST be supported in 313 IPv6-based CON. 315 4.1.3. Path Programming 317 When the enterprise VPN traffic is forwarded among sites or clouds, 318 it may be forwarded along different paths. Each path has different 319 performance such as different bandwidth, delay, etc. For instance, 320 path A is the shortest path from site 1 to cloud 1, which has the 321 lowest delay, while the path B can provide more bandwidth than path 322 A. Therefore, the delay-sensitive traffic like PC gaming traffic 323 SHOULD be forwarded along with path A, and the traffic that is delay- 324 insensitive but requiring large bandwidth SHOULD be forwarded along 325 with path B. 327 In order to meet the different SLA requirements, IPv6-based CON MUST 328 support path programming. 330 4.1.4. Resource Assurance 332 In RSVP-TE MPLS, resources like bandwidth can be reserved for an LSP. 333 When the traffic is forwarded along the LSP, the bandwidth can be 334 guaranteed, which makes sure that the traffic will not be affected by 335 other traffic. In order to provide SLA guaranteed services, 336 IPv6-based CON MUST support Resource Assurance. 338 Network slicing is an approach to provide separate and independent 339 end-to-end logical network over the physical network infrastructure. 340 Each Network Slicing has its own resources, which can meet the 341 specific SLA requirements. In order to provide SLA guaranteed 342 services, IPv6-based CON MUST support network slicing. 344 4.1.5. Deterministic Delay 346 Delay-sensitive traffic has the strict requirements of network delay. 347 Especially, when the servers moved to clouds instead of locating 348 locally within the enterprise site, the long physical distance of 349 packet forwarding path will introduce larger delay. In the 350 traditional network, the shortest forwarding path is calculated based 351 on the metric, and the metric is usually associated to the physical 352 hops instead of latency. However, minimum delay forwarding is 353 required for delay-sensitive traffic, like real-time video broadcast 354 and video meeting. 356 Therefore, IPv6-based CON MUST have the capability to support path 357 computing based on delay. Also, it MUST be able to provide 358 deterministic delay forwarding. 360 4.1.6. Service Function Chaining 362 Service Function Chaining [RFC7665] is a mechanism to provide 363 different value-added services (VAS) for packets. 365 A service function chain defines an ordered set of abstract service 366 functions and ordering constraints that must be applied to packets 367 and/or frames and/or flows selected as a result of classification 368 [RFC7665]. 370 An example of an abstract service function is "a firewall". 371 Typically, different tenant's traffic in cloud data center will 372 traverse different services function chain containing Firewall, DPI 373 or other VAS. 375 Therefore, IPv6-based CON MUST have the capability to support SFC. 377 4.1.7. Performance Measurement 379 Many OAM mechanisms are used to support network operation. 380 Performance Measurement (PM) is one of the most important part of 381 OAM. With PM, the real-time QoS of the forwarding path, like delay, 382 packet loss ratio and throughput, can be measured. 384 PM can be implemented in one of three ways: active, passive, or 385 hybrid [RFC7799], differing in whether OAM packets need to be 386 proactively sent. 388 On-path telemetry [I-D.song-opsawg-ifit-framework] is an hybrid mode 389 OAM/PM mechanism, which provides better accuracy than active PM. 390 Therefore, on-path Performance Measurement MUST be supported in 391 IPv6-based CON. 393 4.1.8. Reliability 395 In Cloud-Network Interconnection scenarios, the enterprise traffic is 396 forwarded over the WAN paths. The traffic can be sensitive to delay 397 or packet losing, so high reliability is required in these scenarios. 398 Therefore, protection of node and links MUST be supported in 399 IPv6-based CON. Furthermore, redundancy transmission SHOULD be 400 supported. 402 4.1.9. Security 404 As mentioned above, the enterprise traffic is forwarded over the WAN 405 paths in IPv6-based CON. The security of the traffic MUST be 406 ensured. 408 Also, in SD-WAN scenarios, customers are most concerned about 409 security. 411 Therefore, IPv6-based CON MUST support secure connection, and MUST 412 provide security assurance for the traffic in transmission. 414 4.1.10. Forwarding Efficiency 416 Tenants/Customers rent the physical or logical WAN links/paths from 417 network operators for building they cloud-network interconnection 418 enterprise network, so the forwarding efficiency is important for the 419 WAN path tenant. 421 Path Maximum Transmission Unit indicates the maximum size of a packet 422 that it can be forwarded along a path. Setting an appropriate PMTU 423 for packets can avoid fragmentation or dropping, so that the 424 forwarding efficiency can be raised. 426 Also, the overhead of packets MUST be added very carefully since it 427 affects the forwarding efficiency directly. Especially, when many 428 SIDs are inserted in an SRv6 packet, the overhead of the SID list is 429 too large. [I-D.srcompdt-spring-compression-requirement] describes 430 the requirements of SRv6 compression. 432 Therefore, the IPv6-based CON MUST support PMTU probing and 433 configuration. In addition, it MUST support SRv6 compression. 435 4.1.11. Application-Aware Networking 437 Network operators are typically unaware of which applications are 438 traversing their networks, which is because the network layer is 439 decoupled from application layer. Adding application knowledge to 440 the network layer enables finer granularity requirements of 441 applications to be specified to the network operator. As IPv6 is 442 being widely deployed, the programmability provided by IPv6 443 encapsulations can be augmented by conveying application information. 445 In IPv6-based CON, many types of applications' traffic is exchanged 446 between sites and clouds. They have various requirements of QoS, and 447 should be treated differently. In order to provide finer granularity 448 traffic engineering to reduce the cost of WAN services, application- 449 aware networking SHOULD be supported in IPv6-based CON. 451 4.2. Solutions 453 This section describes the candidate solutions that meet the 454 requirements in IPv6-based CON. 456 4.2.1. VPN 458 VPN is a basic and essential services for cloud-networks 459 interconnections. 461 SRv6 supports VPN by encoding the VPN information into the VPN SID 462 [I-D.ietf-spring-srv6-network-programming]. 464 Based on IPv6, SRv6 VPN can be established across multiple domains. 465 It avoids configuring VPN services at each boundary nodes at each 466 domain like the way in IPv4/MPLS networks (Option A). Deploying VPN 467 based on SRv6 can shorten the duration significantly. 469 Also, L2VPN and L3VPN can be supported uniformly based on EVPN 470 control plane [I-D.ietf-bess-srv6-services]. Therefore, combining 471 the SRv6 data plane and EVPN control plane, the VPN can be deployed 472 in an easy and flexible way in IPv6-based CON. 474 4.2.2. Path Programming 476 Based on SRv6, the traffic forwarding path can be programmed at the 477 ingress of the SRv6 domain, so that the traffic from sites to clouds 478 or inter-cloud can be forwarded through the specific underlay path. 480 For instance, in SD-WAN scenarios, the POP GW can choose a specific 481 underlay forwarding path in WAN by choosing a binding SID 482 [I-D.dukes-spring-sr-for-sdwan]. If the CPE supports SRv6, a 483 controller can convey the programmed path information to the CPE via 484 BGP SRv6 policy [I-D.ietf-idr-segment-routing-te-policy] or PCEP SRv6 485 policy [I-D.ietf-pce-segment-routing-policy-cp]. 487 If the WAN connection travels multiple domains, the WAN path can be 488 connected by multiple tunnels, such as VXLAN, GRE tunnel. 489 [I-D.dunbar-sr-sdwan-over-hybrid-networks] describes how to 490 associated the tunnels. 492 In order to shorten the delay, a CPE or PE can choose the nearest 493 server in a specific cloud, and forward the packets through 494 programmed paths. 496 4.2.3. Service Function Chaining 498 SFC is required in IPv6-based CON since different tenants subscribe 499 different value-added services. 501 [I-D.ietf-spring-sr-service-programming] defines the mechanism to 502 support SFC in SRv6. Each service function (SF) can be represented 503 as an SRv6 SID if it supports SRv6. If the SF is SRv6-unaware 504 device, then proxy SID is used. By programming service SIDs into the 505 SRH, the SFC can be supported in SRv6. 507 Thanks to IPv6 reachability, SRv6 supports to program the end-to-end 508 forwarding path from the carrier network to the inside the cloud data 509 center, even to multiple clouds. 511 If NSH-based SFC has been deployed, a transition solution should be 512 considered, and [I-D.ietf-spring-nsh-sr] describes a NSH and SR 513 integration SFC solution. 515 4.2.4. IPv6 based Network Slicing 517 The tenant traffic MUST be isolated in WAN to avoid affecting by 518 other internet traffic. 520 A framework, Enhanced VPN (VPN+), to form an enhanced connectivity 521 services between customer sites is defined as per 523 [I-D.ietf-teas-enhanced-vpn]. Typically, VPN+ will be used to form 524 the underpinning of network slicing. It also defines Virtual 525 Transport Network (VTN). A VTN is a virtual underlay network that 526 connects customer edge points with the capability of providing the 527 isolation and performance characteristics required by an enhanced VPN 528 customer. A VTN usually has a customized topology and a set of 529 dedicated or shared network resources [I-D.ietf-teas-enhanced-vpn]. 531 A VTN-ID option in IPv6 HBH header is defined in 532 [I-D.dong-6man-enhanced-vpn-vtn-id] to identify the Virtual Transport 533 Network (VTN) the packet belongs to. A VTN can be used as the 534 underlay for one or a group of VPNs to provide enhanced VPN (VPN+) 535 services. 537 By using VTN-ID, an end-to-end IPv6 network slicing is identified in 538 transport network. Tenant traffic in WAN can be forwarded in the VTN 539 with guaranteed resource. 541 4.2.5. IPv6-based On-path Measurement 543 The extension of supporting Alternate Marking Method [RFC8321] in 544 IPv6 is defined in [I-D.ietf-6man-ipv6-alt-mark]. It describes how 545 the Alternate Marking Method to be used as the hybrid performance 546 measurement tool in an IPv6 domain by defining a new Extension Header 547 Option. 549 Alternate Marking Method is a hybrid on-path performance measurement 550 method, and the metadata of each node can be collected by the 551 collector to compute the performance of the path. 553 IOAM is another on-path measurement method. 554 [I-D.ietf-ippm-ioam-ipv6-options] defines a new IPv6 option, called 555 IOAM option to support carrying IOAM metadata in the IPv6 data 556 packet. However, carrying all the metadata in the data packet will 557 bring challenges for hardware processing. For instance, long-length 558 metadata may cause recircle in processing. Therefore, 559 [I-D.ietf-ippm-ioam-direct-export] defines a direct export option in 560 IOAM, which enables the nodes to export the metadata to collector 561 directly. Furthermore,[I-D.song-opsawg-ifit-framework] outlines a 562 high-level framework to provide an operational environment that 563 utilizes existing and emerging on-path telemetry techniques to enable 564 the collection and correlation of performance information from the 565 network. 567 4.2.6. Reliability 569 4.2.6.1. Local Protection 571 Local protection mechanisms like Fast Reroute (FRR) provide 50 ms 572 protection on nodes for traffic. 574 Regarding link failures, TI-LFA 575 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a fast reroute 576 mechanism by sending the traffic to an expected post-convergence 577 paths from the point of local repair. 579 Regarding the middle endpoint node failures, 580 [I-D.hu-spring-segment-routing-proxy-forwarding] defines a mechanism 581 for fast reroute protection against the failure of a SR-TE path. It 582 can provide fast reroute protection for an adjacency segment, a node 583 segment and a binding segment of the path. Also, 584 [I-D.chen-rtgwg-srv6-midpoint-protection] defines midpoint 585 protection, which enables the direct neighbor of the failed endpoint 586 to perform the function of the endpoint, replace the IPv6 destination 587 address to the next endpoint, and choose the next hop based on the 588 new destination address. 590 Regarding the egress node failures, 591 [I-D.ietf-rtgwg-srv6-egress-protection] defines a local protection 592 solution using the mirror SID. 594 4.2.6.2. End-to-End Protection 596 End-to-End Protection is also required in IPv6-based CON. Normally, 597 host-standby nodes are deployed for supporting traffic switching from 598 the failed node to the alternative node. In order to detect the 599 failure, End-to-end BFD is required. Once the BFD session is failed, 600 the traffic can be steered into a disjoint forwarding path, and the 601 traffic will be forwarded to the host-standby node. 603 4.2.6.3. Redundancy Protection 605 In order to avoid losing packets, 606 [I-D.geng-spring-sr-redundancy-protection] defines a redundancy 607 transmission solution. 609 The document defines two types of segment including Redundancy 610 Segment and Merging Segment to empower the Segment Routing with the 611 capability of redundancy protection. 613 4.2.7. Security 615 As per [I-D.li-spring-srv6-security-consideration], SRv6 inherits 616 potential security vulnerabilities from Source Routing and IPv6, but 617 it does not introduce new critical security threats. 619 Regarding a limited domain, SPRING architecture [RFC8402] defines 620 clear trusted domain boundaries so that source-routing information is 621 only available within the trusted domain and never exposed to the 622 outside of the domain. It is expected that, by default, explicit 623 routing is only used within the boundaries of the administered 624 domain. Therefore, the data plane does not expose any source-routing 625 information when a packet leaves the trusted domain. The traffic is 626 filtered at the domain boundaries [RFC8402]. 628 However, it has been noted that the AH and ESP are not directly 629 applicable in order to reduce the vulnerabilities of SRv6 due to the 630 presence of mutable fields in the SRH 631 [I-D.li-spring-srv6-security-consideration]. In order to resolve 632 this problem, [RFC8754] defines a mechanism to carry HMAC TLV in the 633 SRH to verify the integrity of packets including the SRH fields. 635 Regarding end-to-end security protection across multiple domains, an 636 end-to-end IPSec tunnel is suggested to be deployed. 638 In typical SD-WAN scenarios, the IPSec tunnel should be used between 639 the CPE and POP GW. 641 4.2.8. IPv6 Forwarding Efficiency 643 4.2.8.1. PMTU 645 The host may discover the PMTU by Path MTU Discovery (PMTUD) 646 [RFC8201] or other means. But the ingress node still needs to 647 examine the packet size to drop too large packets to avoid malicious 648 packets or error packets attack. Also, the packet size may exceed 649 the PMTU because of the new encapsulation of SR-MPLS or SRv6 at the 650 ingress. In order to check whether the packet size exceeds the PMTU 651 or not, the ingress node need to know the Path MTU associated to the 652 forwarding path. 654 However, the path maximum transmission unit (MTU) information for SR 655 path is not available since the SR does not require signaling. 656 [I-D.ietf-idr-bgp-ls-link-mtu] proposes a BGP-LS extensions to 657 collect the link MTU of the links in the networks. 658 [I-D.ietf-idr-sr-policy-path-mtu] and [I-D.li-pce-pcep-pmtu] defines 659 extensions to distribute path MTU information within BGP and PCEP SR 660 policies, respectively. In this way, the controller can compute the 661 appropriate PMTU for an SR path. 663 4.2.8.2. SRv6 Compression 665 The overhead of SRv6 encapsulation brings challenges for hardware 666 processing and transmission. 667 [I-D.srcompdt-spring-compression-requirement] describes the 668 requirements of SRv6 compression. 670 G-SRv6 is proposed in [I-D.cl-spring-generalized-srv6-np], which 671 supports to encode multiple types of SIDs in SRH. This SRH is called 672 Generalized SRH [I-D.lc-6man-generalized-srh] while the SID is called 673 Generalized SID. 675 G-SRv6 supports to encode the compressed SIDs in the SRH to reduce 676 the size of SRv6 SID list in SRH 677 [I-D.cl-spring-generalized-srv6-for-cmpr]. A COC (Continuation of 678 Compression) flavor is defined to indicate the continuation of SRv6 679 compressed SIDs in the SID list. 681 4.2.9. Application-aware IPv6 Networking 683 Application-aware Networking (APN) is proposed by 684 [I-D.li-apn-framework], where application characteristic information 685 such as application identification and its network performance 686 requirements is carried in the packet encapsulation in order to 687 facilitate service provisioning, perform application-level traffic 688 steering and network resource adjustment. 690 Application-aware IPv6 Networking (APN6) framework makes use of IPv6 691 encapsulation in order to convey the application-aware information 692 along with the data packet to the network so to facilitate the 693 service deployment and SLA guarantee. 694 [I-D.li-6man-app-aware-ipv6-network] defines the encodings of the 695 application characteristic information, for the APN6 framework, that 696 can be exchanged between an application and the network 697 infrastructure through IPv6 extension headers. 699 5. IANA Considerations 701 TBD 703 6. Security Considerations 705 TBD 707 7. Contributors 709 TBD 711 8. Acknowledgements 713 9. References 715 9.1. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, 719 DOI 10.17487/RFC2119, March 1997, 720 . 722 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 723 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 724 May 2017, . 726 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 727 (IPv6) Specification", STD 86, RFC 8200, 728 DOI 10.17487/RFC8200, July 2017, 729 . 731 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 732 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 733 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 734 . 736 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 737 Decraene, B., Litkowski, S., and R. Shakir, "Segment 738 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 739 July 2018, . 741 9.2. Informative References 743 [I-D.ietf-rtgwg-net2cloud-problem-statement] 744 Dunbar, L., Malis, A., Jacquenet, C., and M. Toy, "Dynamic 745 Networks to Hybrid Cloud DCs Problem Statement", draft- 746 ietf-rtgwg-net2cloud-problem-statement-11 (work in 747 progress), July 2020. 749 [I-D.ietf-spring-srv6-network-programming] 750 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 751 Matsushima, S., and Z. Li, "SRv6 Network Programming", 752 draft-ietf-spring-srv6-network-programming-28 (work in 753 progress), December 2020. 755 [I-D.ietf-bess-srv6-services] 756 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 757 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 758 Overlay services", draft-ietf-bess-srv6-services-05 (work 759 in progress), November 2020. 761 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 762 Chaining (SFC) Architecture", RFC 7665, 763 DOI 10.17487/RFC7665, October 2015, 764 . 766 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 767 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 768 May 2016, . 770 [I-D.dukes-spring-sr-for-sdwan] 771 Dukes, D., Filsfils, C., Dawra, G., Xu, X., Voyer, D., 772 Camarillo, P., Clad, F., and S. Salsano, "SR For SDWAN: 773 VPN with Underlay SLA", draft-dukes-spring-sr-for-sdwan-02 774 (work in progress), June 2019. 776 [I-D.dunbar-sr-sdwan-over-hybrid-networks] 777 Dunbar, L. and M. Toy, "Segment routing for SDWAN paths 778 over hybrid networks", draft-dunbar-sr-sdwan-over-hybrid- 779 networks-06 (work in progress), November 2019. 781 [I-D.ietf-idr-segment-routing-te-policy] 782 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 783 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 784 Routing Policies in BGP", draft-ietf-idr-segment-routing- 785 te-policy-11 (work in progress), November 2020. 787 [I-D.ietf-pce-segment-routing-policy-cp] 788 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 789 Bidgoli, "PCEP extension to support Segment Routing Policy 790 Candidate Paths", draft-ietf-pce-segment-routing-policy- 791 cp-02 (work in progress), January 2021. 793 [I-D.ietf-spring-sr-service-programming] 794 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 795 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 796 Henderickx, W., and S. Salsano, "Service Programming with 797 Segment Routing", draft-ietf-spring-sr-service- 798 programming-03 (work in progress), September 2020. 800 [I-D.ietf-spring-nsh-sr] 801 Guichard, J. and J. Tantsura, "Integration of Network 802 Service Header (NSH) and Segment Routing for Service 803 Function Chaining (SFC)", draft-ietf-spring-nsh-sr-04 804 (work in progress), December 2020. 806 [I-D.ietf-teas-enhanced-vpn] 807 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 808 Framework for Enhanced Virtual Private Networks (VPN+) 809 Service", draft-ietf-teas-enhanced-vpn-06 (work in 810 progress), July 2020. 812 [I-D.dong-6man-enhanced-vpn-vtn-id] 813 Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual 814 Transport Network Identifier in IPv6 Extension Header", 815 draft-dong-6man-enhanced-vpn-vtn-id-02 (work in progress), 816 November 2020. 818 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 819 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 820 "Alternate-Marking Method for Passive and Hybrid 821 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 822 January 2018, . 824 [I-D.ietf-6man-ipv6-alt-mark] 825 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 826 Pang, "IPv6 Application of the Alternate Marking Method", 827 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 828 October 2020. 830 [I-D.ietf-ippm-ioam-ipv6-options] 831 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 832 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 833 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 834 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 835 ipv6-options-04 (work in progress), November 2020. 837 [I-D.ietf-ippm-ioam-direct-export] 838 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 839 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 840 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 841 export-02 (work in progress), November 2020. 843 [I-D.song-opsawg-ifit-framework] 844 Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In- 845 situ Flow Information Telemetry", draft-song-opsawg-ifit- 846 framework-13 (work in progress), October 2020. 848 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 849 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 850 and D. Voyer, "Topology Independent Fast Reroute using 851 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 852 lfa-05 (work in progress), November 2020. 854 [I-D.hu-spring-segment-routing-proxy-forwarding] 855 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 856 Path Midpoint Protection", draft-hu-spring-segment- 857 routing-proxy-forwarding-12 (work in progress), October 858 2020. 860 [I-D.chen-rtgwg-srv6-midpoint-protection] 861 Chen, H., Hu, Z., Chen, H., and X. Geng, "SRv6 Midpoint 862 Protection", draft-chen-rtgwg-srv6-midpoint-protection-03 863 (work in progress), October 2020. 865 [I-D.ietf-rtgwg-srv6-egress-protection] 866 Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., He, 867 T., Liu, L., and X. Liu, "SRv6 Path Egress Protection", 868 draft-ietf-rtgwg-srv6-egress-protection-02 (work in 869 progress), November 2020. 871 [I-D.geng-spring-sr-redundancy-protection] 872 Geng, X., Chen, M., and F. Yang, "Segment Routing for 873 Redundancy Protection", draft-geng-spring-sr-redundancy- 874 protection-00 (work in progress), November 2020. 876 [I-D.li-spring-srv6-security-consideration] 877 Li, C., Li, Z., Xie, C., Tian, H., and J. Mao, "Security 878 Considerations for SRv6 Networks", draft-li-spring-srv6- 879 security-consideration-05 (work in progress), October 880 2020. 882 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 883 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 884 DOI 10.17487/RFC8201, July 2017, 885 . 887 [I-D.ietf-idr-bgp-ls-link-mtu] 888 Zhu, Y., Hu, Z., Peng, S., and R. Mwehair, "Signaling 889 Maximum Transmission Unit (MTU) using BGP-LS", draft-ietf- 890 idr-bgp-ls-link-mtu-00 (work in progress), November 2020. 892 [I-D.ietf-idr-sr-policy-path-mtu] 893 Li, C., Zhu, Y., Sawaf, A., and Z. Li, "Segment Routing 894 Path MTU in BGP", draft-ietf-idr-sr-policy-path-mtu-02 895 (work in progress), November 2020. 897 [I-D.li-pce-pcep-pmtu] 898 Peng, S., Li, C., Han, L., and L. Ndifor, "Support for 899 Path MTU (PMTU) in the Path Computation Element (PCE) 900 communication Protocol (PCEP).", draft-li-pce-pcep-pmtu-03 901 (work in progress), October 2020. 903 [I-D.srcompdt-spring-compression-requirement] 904 Cheng, W., "Compressed SRv6 SID List Requirements", draft- 905 srcompdt-spring-compression-requirement-03 (work in 906 progress), January 2021. 908 [I-D.cl-spring-generalized-srv6-np] 909 Cheng, W., Li, Z., Li, C., Xie, C., Li, C., Tian, H., and 910 F. Zhao, "Generalized SRv6 Network Programming", draft-cl- 911 spring-generalized-srv6-np-02 (work in progress), 912 September 2020. 914 [I-D.lc-6man-generalized-srh] 915 Li, Z., Li, C., Cheng, W., Xie, C., Cong, L., Tian, H., 916 and F. Zhao, "Generalized Segment Routing Header", draft- 917 lc-6man-generalized-srh-01 (work in progress), August 918 2020. 920 [I-D.cl-spring-generalized-srv6-for-cmpr] 921 Cheng, W., Li, Z., Li, C., Clad, F., Aihua, L., Xie, C., 922 Liu, Y., and S. Zadok, "Generalized SRv6 Network 923 Programming for SRv6 Compression", draft-cl-spring- 924 generalized-srv6-for-cmpr-02 (work in progress), November 925 2020. 927 [I-D.li-apn-framework] 928 Li, Z., Peng, S., Voyer, D., Li, C., Geng, L., Cao, C., 929 Ebisawa, K., Previdi, S., and J. Guichard, "Application- 930 aware Networking (APN) Framework", draft-li-apn- 931 framework-01 (work in progress), September 2020. 933 [I-D.li-6man-app-aware-ipv6-network] 934 Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, 935 P., Liu, C., and K. Ebisawa, "Application-aware IPv6 936 Networking (APN6) Encapsulation", draft-li-6man-app-aware- 937 ipv6-network-02 (work in progress), July 2020. 939 Authors' Addresses 941 Cheng Li (editor) 942 Huawei Technologies 943 Huawei Campus, No. 156 Beiqing Rd. 944 Beijing 100095 945 China 947 Email: c.l@huawei.com 949 Zhenbin Li 950 Huawei Technologies 951 Huawei Campus, No. 156 Beiqing Rd. 952 Beijing 100095 953 China 955 Email: lizhenbin@huawei.com 957 Hongjie Yang 958 Huawei Technologies 959 Huawei Campus, No. 156 Beiqing Rd. 960 Beijing 100095 961 China 963 Email: hongjie.yang@huawei.com