idnits 2.17.1 draft-tian-spring-srv6-deployment-consideration-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 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 (March 6, 2020) is 1483 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 688, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-10 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tian 3 Internet-Draft F. Zhao 4 Intended status: Informational CAICT 5 Expires: September 7, 2020 C. Xie 6 China Telecom 7 T. Li 8 J. Ma 9 China Unicom 10 S. Peng 11 Z. Li 12 Y. Xiao 13 Huawei Technologies 14 March 6, 2020 16 SRv6 Deployment Consideration 17 draft-tian-spring-srv6-deployment-consideration-01 19 Abstract 21 SRv6 has significant advantages over SR-MPLS and has attracted more 22 and more attention and interest from network operators and verticals. 23 Smooth network migration towards SRv6 is a key focal point and this 24 document provides network design and migration guidance and 25 recommendations on solutions in various scenarios. Deployment cases 26 with SRv6 are also introduced. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 7, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Advantages of SRv6 . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. IP Route Aggregation . . . . . . . . . . . . . . . . . . 3 70 2.2. End-to-end Service Auto-start . . . . . . . . . . . . . . 5 71 2.3. On-Demand Upgrade . . . . . . . . . . . . . . . . . . . . 6 72 2.4. Simplified Service Deployment . . . . . . . . . . . . . . 7 73 2.4.1. Carrier's Carrier . . . . . . . . . . . . . . . . . . 7 74 2.4.2. LDP over TE . . . . . . . . . . . . . . . . . . . . . 8 75 3. Design Guidance for SRv6 Network . . . . . . . . . . . . . . 9 76 3.1. Locator and Address Planning . . . . . . . . . . . . . . 9 77 3.2. PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4. Incremental Deployment Guidance for SRv6 Migration . . . . . 10 79 5. Migration Guidance for SRv6/SR-MPLS Co-existence Scenario . . 11 80 6. Deployment cases . . . . . . . . . . . . . . . . . . . . . . 12 81 6.1. China Telecom Si'chuan . . . . . . . . . . . . . . . . . 13 82 6.2. China Unicom . . . . . . . . . . . . . . . . . . . . . . 14 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 SRv6 is the instantiation of Segment Routing deployed on the IPv6 95 data plane [RFC8200]. Therefore, in order to support SRv6, the 96 network must first be enabled for IPv6. Over the past several years, 97 IPv6 has been actively promoted all over the world, and the 98 deployments of IPv6 have been ever-increasing which provides the 99 basis for the deployments of SRv6. 101 With IPv6 as its data plane, for network migration towards SRv6, both 102 software and hardware need to be upgraded. Compared with other new 103 protocols, only IGP and BGP need to be extended to support SRv6, 104 which significantly simplifies the software upgrade required. While 105 the hardware needs to support the new SRv6 header SRH 106 [I-D.ietf-6man-segment-routing-header], the design of SRv6 assures 107 compatibility with the existing IPv6 network as an SRv6 SID is 108 designed as a 128-bit IPv6 address and the encapsulation of an SRv6 109 packet is the same as an IPv6 packet. When only L3VPN over SRv6 BE 110 (Best-Effort) is deployed, there will be no SRH. Therefore, no 111 additional hardware capabilities are required but only software 112 upgrade for protocol extensions. 114 As the number of services supported by SRv6 increase, e.g. SFC, 115 network slicing, iOAM etc., more SIDs in the SRH may impose new 116 requirements on the hardware. Besides upgrading the hardware, 117 various solutions [I-D.peng-spring-srv6-compatibility] have already 118 been proposed to relieve the imposed pressure on the hardware, such 119 as Binding SID (BSID) etc. to guarantee the compatibility with the 120 existing network. On the other hand SRv6 has many more advantages 121 over SR-MPLS for the network migration to support new services. 123 This document summarizes the advantages of SRv6 and provides network 124 migration guidance and recommendations on solutions in various 125 scenarios. 127 2. Advantages of SRv6 129 Compared with SR-MPLS, SRv6 has significant advantages especially in 130 large scale networking scenarios. 132 2.1. IP Route Aggregation 134 The increasing complexity of service deployment is of concern for 135 network operators, especially in large-scale networking scenarios. 136 With solutions such as multi-segment PW and Option A [RFC4364], the 137 number of service-touch points has increased, and the services, with 138 associated OAM features cannot be deployed end-to-end. 140 o With Seamless MPLS or SR-MPLS, since the MPLS label itself does 141 not have reachability information, it must be attached to a 142 routable address. The 32-bit host route needs to leak across 143 domains. For an extreme case, as shown in Figure 1a, in a large 144 scale networking scenario, millions of host route LSPs might need 145 to be imported, which places big challenges on the capabilities of 146 the edge nodes. 148 o With SRv6, owing to its native IP feature of route aggregation as 149 shown in Figure 1b, the aggregated routes can be imported across 150 network domains. For large scale networking, only very few 151 aggregated routes are needed in order to start end-to-end 152 services, which also reduces the scalability requirements on the 153 edge nodes. 155 /------Metro------\ /----Core----\ /------Metro-------\ 156 LB PE1 ASBR ASBR PE2 LB 157 1.1.1.1 2.2.2.2 158 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 159 |A | |B | |ER| | | |PE| | | |PE| | | |ER| |B | |A | 160 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 161 SR-LSP SR-LSP SR-LSP SR-LSP SR-LSP 162 |<--->|<---------->| |<--------->| |<--------->|<--->| 163 BGP-LSP 164 |<---------------------------------------------------------->| 165 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 166 +IP + +IP + +IP + +IP + +IP + +IP + +IP + +IP + +IP + 167 +ETH+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +ETH+ 168 +---+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +---+ 169 +SR + +SR + +ETH+ +SR + +ETH+ +SR + +SR + 170 +ETH+ +ETH+ +---+ +ETH+ +---+ +ETH+ +ETH+ 171 +---+ +---+ +---+ +---+ +---+ 173 (a) SR-MPLS 175 /------Metro------\ /----Core----\ /------Metro-------\ 176 LOC PE1 ASBR ASBR PE2 LOC 177 A1::100:: A2::200:: 178 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 179 |A | |B | |ER| | | |PE| | | |PE| | | |ER| |B | |A | 180 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 181 \_____A1::/80____/ \__A0::/80__/ \____A2::/80____/ 182 Aggregated Route Aggregated Route Aggregated Route 183 +---+ +----------+ +----------+ +----------+ +---+ 184 +IP + + IP + + IP + + IP + +IP + 185 +ETH + +w./wo.SRH + +w./wo.SRH + +w./wo.SRH + +ETH+ 186 +---+ + ETH + + ETH + + ETH + +---+ 187 +----------+ +----------+ +----------+ 189 (b) SRv6 191 Figure 1. Large-scale Networking with (a) SR-MPLS vs. (b) SRv6 193 2.2. End-to-end Service Auto-start 195 In the SR cross-domain scenario, in order to set up end-to-end SR 196 tunnels, the SIDs in each domain need to be imported to other 197 domains. 199 o With SR-MPLS, SRGB and Node SID need overall network-wide 200 planning, and in the cross-domain scenario, it is difficult or 201 sometimes even impossible to perform as the node SIDs in different 202 domains may collide. BGP Prefix SID can be used for the cross- 203 domain SID import, but the network operator must be careful when 204 converting the SID to avoid SID collision. Moreover, the pre- 205 allocated SRGB within each domain needs to consider the total 206 number of devices in all other domains, which raises difficulties 207 for the network-wide planning. 209 o With SRv6, owing to its native IP feature of route reachability, 210 if the IPv6 address space is carefully planned, and the aggregated 211 routes are imported by using BGP4+ (BGP IPv6), the services will 212 auto-start in the cross-domain scenario. 214 2.3. On-Demand Upgrade 216 The MPLS label itself does not hold any reachability information, so 217 it must be attached to a routable address, which means that the 218 matching relationship between the label and FEC needs to be 219 maintained along the path. 221 SR-MPLS uses the MPLS data plane. When the network migrates to SR- 222 MPLS, there are two ways, as shown in Figure 2: 224 1. MPLS/SR-MPLS Dual stack: the entire network is upgraded first and 225 then deploy SR-MPLS. 227 2. MPLS and SR-MPLS interworking: mapping servers are deployed at 228 some of the intermediate nodes and then removed once the entire 229 network is upgraded 231 Regardless of which migration option is chosen, big changes in a wide 232 area is required at the initial stage therefore causing a long time- 233 to-market. 235 In contrast, the network can be migrated to SRv6 on demand. Wherever 236 the services need to be turned on, only the relevant devices need to 237 be upgraded to enable SRv6, and all other devices only need to 238 support IPv6 forwarding and need not be aware of SRv6. When Traffic 239 Engineering (TE) services are needed, only the key nodes along the 240 path need to be upgraded to support SRv6. 242 (~~~~~~MPLS/SR-MPLS~~~~~~~) 243 ( +---+ +---+ +---+ ) 244 MPLS Migration Options Option 1 ( |SM | |SM | |SM | ) 245 --->( +---+ +---+ +---+ ) 246 / ( +---+ +---+ +---+ ) 247 (~~~~~~~~~~MPLS~~~~~~~~~~~) / ( |SM | |SM | |SM | ) 248 ( +---+ +---+ +---+ ) / ( +---+ +---+ +---+ ) 249 ( | M | | M | | M | ) / ~~~~~~~~~~~~~~~~~~~~~~~~~~ 250 ( +---+ +---+ +---+ ) \ 251 ( +---+ +---+ +---+ ) \ (~~MPLS~~|~~~~~SR-MPLS~~~~~) 252 ( | M | | M | | M | ) \ ( +---+ | +---+ +---+ ) 253 ( +---+ +---+ +---+ ) \ ( | M | | |SM | |SM | ) 254 ~~~~~~~~~~~~~~~~~~~~~~~~~~ --->( +---+ | +---+ +---+ ) 255 Option 2 ( +---+ | +---+ +---+ ) 256 ( | M | | |SM | |SM | ) 257 ( +---+ | +---+ +---+ ) 258 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 259 SRv6 Migration 261 (~~~~~~~~~~MPLS~~~~~~~~~~~) (~~~~~~SRv6 on demand~~~~~) 262 ( +---+ +---+ +---+ ) ( +---+ +---+ +---+ ) 263 ( | M | | M | | M | ) ( |S6 | | M | | M | ) 264 ( +---+ +---+ +---+ ) ----------> ( +---+ +---+ +---+ ) 265 ( +---+ +---+ +---+ ) ( +---+ +---+ +---+ ) 266 ( | M | | M | | M | ) ( | M | | M | |S6 | ) 267 ( +---+ +---+ +---+ ) ( +---+ +---+ +---+ ) 268 ~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~ 270 Figure 2. MPLS Domain Migration vs. SRv6 On-Demand Upgrade 272 2.4. Simplified Service Deployment 274 With SRv6, the service deployment can be significantly simplified in 275 some scenarios. 277 2.4.1. Carrier's Carrier 279 When the customer of the VPN service carrier (Provider Carrier) is 280 itself a VPN service carrier (Customer Carrier), it becomes the 281 scenario of Carrier's Carrier. For this scenario, with SRv6, the 282 service deployment can be significantly simplified. 284 To achieve better scalability, the CEs of the Provider Carrier (i.e. 285 the PEs of the Customer Carriers) only distribute the internal 286 network routes to the PEs of the Provider Carrier. The customers' 287 routes of the Customer Carriers (i.e. from CE3 and CE4) will not be 288 distributed into the network of the Provide Carrier. Therefore, LDP 289 or Labeled BGP will be run between the CEs of the Provider Carrier 290 (i.e. CE1 and CE2 in the Figure 3) and the PEs of the Provider 291 Carrier (i.e. PE1 and PE2 in the Figure 3), and LDP will be run 292 between the CEs of the Provider Carrier (i.e. the PEs of the Customer 293 Carriers) and the PEs of the Customer Carrier (i.e. PE3 and PE4 in 294 the Figure 3). MP-BGP will be run between the PEs of the Customer 295 Carrier. The overall service deployment is very complex. 297 If SRv6 is deployed by the Customer Carrier and the Provider Carrier, 298 no LDP will be ever needed. The Locator routes and Loopback routes 299 of the Customer Carriers can be distributed into the network of the 300 Provider Carrier via BGP, and within each carrier's network only IGP 301 is needed. The end-to-end VPN services can be provided just based on 302 the IPv6 interconnections, and the customer carrier is just like a 303 normal CE to the provider carrier, which significantly simplified the 304 VPN service deployment. 306 Customer Carrier Provider Carrier Customer Carrier 307 /------------\ /-------------\ /-----------\ 308 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 309 |CE3|--|PE3| |CE1|--|PE1| |PE2|--|CE2| |PE4|--|CE4| 310 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 312 MPLS IGP/LDP IGP/LDP MP-IBGP IGP/LDP IGP/LDP 313 or Labeled BGP or Labeled BGP 315 SR-MPLS IGP Labeled BGP MP-IBGP Labeled BGP IGP 317 SRv6 IGP BGP MP-IBGP BGP IGP 318 |<--------->||<---->||<---------->||<--->||<--------->| 319 MP-IBGP 320 |<--------------------------------------------------->| 321 Figure 3. Service deployment with MPLS, SR-MPLS and SRv6 323 2.4.2. LDP over TE 325 In a MPLS network, generally RSVP-TE is deployed in the P nodes of 326 the network, and LDP is running between these P nodes and the PE 327 nodes. Customers access to VPN services via the PE nodes. This 328 scenario is called LDP over TE, which is a typical deployment for 329 carriers who want to achieve the TE capability over MPLS network 330 while keep scalability. However, such network configuration and 331 service deployment are very complex. 333 With SRv6 which can provide both TE capability and IP reachability, 334 the service deployment can be significantly simplified. Only IGP and 335 BGP are needed in the network to launch VPN services. 337 +---+ +---+ +---+ +---+ +---+ +---+ 338 |CE1|---------|PE1|------|P1 |\-------/|P2 |------|PE2|--------|CE2| 339 +---+ +---+ +---+ \ / +---+ +---+ +---+ 340 / 341 +---+ +---+ +---+ / \ +---+ +---+ +---+ 342 |CE3|---------|PE3|------|P3 |/-------\|P4 |------|PE4|--------|CE4| 343 +---+ +---+ +---+ +---+ +---+ +---+ 345 MPLS LDP RSVP-TE LDP 347 SR-MPLS IGP (SR-MPLS) 349 SRv6 IGP (SRv6) 350 |<-------->|<------------>|<------->| 351 MP-BGP 352 |<--------------------------------->| 353 Figure 4. Service deployment with (a) MPLS/SR-MPLS vs. (b) SRv6 355 3. Design Guidance for SRv6 Network 357 3.1. Locator and Address Planning 359 Address Planning is a very important factor for s successful network 360 design, especially an IPv6 network, which will directly affect the 361 design of routing, tunnel, and security. A good address plan can 362 bring big benefit for service deployment and network operation. 364 If a network has already deployed IPv6 and set up IPv6 subnets, one 365 of the subnets can be selected for the SRv6 Locator planning, and the 366 existing IPv6 address plan will not be impacted. 368 If a network has not yet deployed IPv6 and there has not been an 369 address plan, it needs to perform the IPv6 address planning first 370 taking the following steps, 372 1. to decide the IPv6 address planning principles 374 2. to choose the IPv6 address assignment methods 376 3. to assign the IPv6 address in a hierarchical manner 378 For an SRv6 network, in the first step for IPv6 address planning, the 379 following principles are suggested to follow, 381 1. Unification: all the IPv6 addresses SHOULD be planned altogether, 382 including service addresses for end users, platform addresses 383 (for IPTV, DHCP servers), and network addresses for network 384 devices interconnection. 386 2. Uniqueness: every single address SHOULD be unique. 388 3. Separation: service addresses and network addresses SHOULD be 389 planned separately; the SRv6 Locator subnet, the Loopback 390 interface addresses and the link addresses SHOULD be planned 391 separately. 393 4. Aggregatability: when being distributed across IGP/BGP domains, 394 the addresses in the preassigned subnets (e.g. SRv6 Locator 395 subnet, the Loopback interface subnet) SHOULD be aggregatable, 396 which will make the routing easier. 398 5. Security: fast tracability of the assigned addresses SHOULD be 399 facilitated, which will make the traffic filtering easier. 401 6. Evolvablity: enough address space SHOULD be reserved for each 402 subset for future service development. 404 Considering the above-mentioned IPv6 address planning principles, it 405 has been adopted in some deployment cases to set Locator length 406 96bits, function length 20bits, and args 12bits. 408 3.2. PSP 410 When Locator is imported in ISIS, the system will automatically 411 assign END SID with Flavors such as PSP (Penultimate Segment Pop) and 412 distribute the Locator subnet route through ISIS. 414 The Flavor PSP, that is, SRH is popped at penultimate segment, 415 provides the following benefits, 417 1. Reduce the load of ultimate segment endpoint. Ultimate segment 418 endpoint tends to have heavy load since it needs to handle the 419 inner IP/IPv6/Ethernet payload and demultiplex the packet to the 420 right overlay service. 422 2. Support of incremental deployment on existing network where the 423 ultimate segment endpoint is low-end device that is not fully 424 capable of handling SRH. 426 4. Incremental Deployment Guidance for SRv6 Migration 428 Incremental deployment is the key for a smooth network migration to 429 SRv6. In order to quickly launch SRv6 network services and enjoy the 430 benefits brought by SRv6, the recommended incremental SRv6 deployment 431 steps are given as follows. These are based on practical deployment 432 experience earned from the use cases described in 433 [I-D.matsushima-spring-srv6-deployment-status]. 435 The referenced network topology is shown in Figure 5. 437 /---- Path 1 ----\ 438 +------+ +----+ +---/--+ +---\--+ +----+ +------+ 439 |Site 1|----|PE 1|----|ASBR 1| IP Core |ASBR 2|----|PE 2|----|Site 2| 440 +------+ +----+ +---\--+ +---/--+ +----+ +------+ 441 \---- Path 2 ----/ 443 Figure 5. Reference Network Topology 445 Step1. All the network devices are upgraded to support IPv6. 447 Step 2. According to service demands, only a set of selected PE 448 devices are upgraded to support SRv6 in order to immediately deploy 449 SRv6 overlay VPN services. For instance, in Figure 3, PE1 and PE2 450 are SRv6-enabled. 452 Step 3. Besides the PE devices, some P devices are upgraded to 453 support SRv6 in order to deploy loose TE which enables network path 454 adjustment and optimization. SFC is also a possible service provided 455 by upgrading some of the network devices. 457 Step 4. All the network devices are upgraded to support SRv6. In 458 this case, it is now possible to deploy strict TE, which enables the 459 deterministic networking and other strict security inspection. 461 5. Migration Guidance for SRv6/SR-MPLS Co-existence Scenario 463 As the network migration to SRv6 is progressing, in most cases 464 SRv6-based services and SR-MPLS-based services will coexist. 466 As shown in Figure 6, in the Non-Standalone (NSA) case specified by 467 3GPP Release 15, 5G networks will be supported by existing 4G 468 infrastructure. 4G eNB connects to CSG 2, 5G gNB connects to CSG 1, 469 and EPC connects to RSG 1. 471 To support the 4G services, network services need to be provided 472 between CSG 2 and RSG 1 for interconnecting 4G eNB and EPC, while for 473 the 5G services, network services need to be deployed between CSG 1 474 and RSG 1 for interconnecting 5G gNB and EPC. Meanwhile, to support 475 X2 interface between the eNB and gNB, network services also need to 476 be deployed between the CSG 1 and CSG 2. 478 +-----+ 479 | eNB |------\ 480 +-----+ \ 481 +-----+ 482 |CSG 2|-------+-----+ +-----+ +-----+ 483 /+-----+ |ASG 1|-------------|RSG 1|------| EPC | 484 +-----+ +--/--+ +-----+ +-----+ +-----+ 485 | gNB |-----|CSG 1| Domain 1 | Domain 2 | 486 +-----+ +--\--+ +-----+ +-----+ 487 \+-----+ |ASG 2|-------------|RSG 2| 488 |CSG 3|-------+-----+ +-----+ 489 +-----+ 491 Figure 6. A 3GPP Non-Standalone deployment case 493 As shown in Figure 6, in most of the current network deployments, 494 MPLS-based network services may have already existed between CSG 2 495 and RSG 1 for interconnecting 4G eNB and EPC for 4G services. 497 When 5G services are to be supported, more stringent network services 498 are required, e.g. low latency and high bandwidth. SRv6-based 499 network services could be deployed between CSG 1 and RSG 1 for 500 interconnecting 5G gNB and EPC. 502 In order to perform smooth network migration, a dual-stack solution 503 can be adopted which deploys both SRv6 and MPLS stack in one node. 505 With the dual-stack solution, only CSG 1 and RSG 1 need to be 506 upgraded with SRv6/MPLS dual stack. In this case, CSG 1 can 507 immediately start SRv6-based network services to RSG 1 for support of 508 5G services, but continue to use MPLS-based services to CSG 2 for X2 509 interface communications. The upgrade at CSG 1 will not affect the 510 existing 4G services supported by the MPLS-based network services 511 between CSG 2 and RSG 1. RSG1 can provide MPLS services to CSG2 for 512 4G services as well as SRv6 services to CSG 1 for 5G services. 514 6. Deployment cases 516 With the current network, the launch of leased line service is slow, 517 the network operation and maintainence is complex, and the 518 configuration points are many. SRv6 can solve the issues above. 519 There have already been several successful SRv6 deployments following 520 the incremental deployment guidance shown in Section 3. 522 6.1. China Telecom Si'chuan 524 China Telecom Si'chuan (Si'chuan Telecom) has enabled SRv6 at the PE 525 node of the Magic-Mirror DC in Mei'shan, Cheng'du, Pan'zhihua and 526 other cities. The SRv6 BE tunnel has been deployed through the 163 527 backbone network which has the IPv6 capability. It enables the fast 528 launch of the Magic-Mirror video service, the interconnection of the 529 DCs in various cities, and the isolation of video services. The 530 deployment case is shown in Figure 7. 532 /---------163--------\ 533 +------+ / \ +-------+ 534 | Magic| +----+ +--/-+ +--\-+ +----+ | Magic | 535 |Mirror|----|PE 1|----|CR 1| IP Backbone |CR 2|----|PE 2|----|Mirror | 536 | DC 1 | +----+ +--\-+ +--/-+ +----+ | DC 2 | 537 +------+ \ / +-------+ 538 +-\---+ +---/-+ 539 |ASBR1|----CN2-----|ASBR2| 540 +-----+ +-----+ 542 IGP/IBGP EBGP IGP/IBGP 543 |<------->|<-------------------------->|<-------->| 544 EBGP VPNv4 Peer 545 |<----------------------------------------------->| 546 L3VPN over SRv6 547 |<----------------------------------------------->| 549 Figure 7. China Telecom Si'chuan deployment case 551 As shown in Figure 7, IGP (some cities such as Chengdu deploy ISIS, 552 while other cities such as Panzhihua deploy OSPF) and IBGP are 553 deployed between PE and CR, and EBGP is deployed between CRs of 554 cities in order to advertise the aggregation route. EBGP VPNv4 peers 555 are set up between PEs in different cities to deliver VPN private 556 network routes. 558 The packet enters the SRv6 BE tunnel from the egress PE of DC, and 559 the packet is forwarded according to the Native IP of the 163 560 backbone network. When the packet reaches the peer PE, the SRH is 561 decapsulated, and then the IP packet is forwarded in the VRF 562 according to the service SID (for example, End.DT4). 564 In order to further implement the path selection, ASBRs can be 565 upgraded to support SRv6. Different SRv6 policies are configured on 566 the DC egress PE so that different VPN traffic reaches the peer PE 567 through the 163 backbone network and the CN2 backbone network 568 respectively. 570 6.2. China Unicom 572 China Unicom has deployed SRv6 L3VPN over 169 IPv6 backbone network 573 from Guangzhou to Beijing to provide inter-domain Cloud VPN service. 574 The deployment case is shown in Figure 8. 576 /-------------\ /------------\ /-----------\ 577 +-/-+ Guangzhou +-\-+ +-/-+ IPv6 +-\-+ +-/-+ Beijing +-\-+ 578 |PE1| |CR1|---|CR2| Backbone |CR3|---|CR4| |PE2| 579 +-\-+ Metro +-/-+ +-\-+ 169 +-/-+ +-\-+ Metro +-/-+ 580 \-------------/ \------------/ \-----------/ 582 |<--OSPF/ISIS-->|<-EBGP->|<-Native IPv6->|<-EBGP->|<-OSPF/ISIS->| 583 |<----------------------- EBGP VPNv4 Peer --------------------->| 584 |<----------------------- L3VPN over SRv6 --------------------->| 586 Figure 8. China Unicom SRv6 L3VPN case 588 In Guangzhou and Beijing metro networks, routers exchange basic 589 routing information using IGP(OSPF/ISIS). The prefixes of IPv6 590 loopback address and SRv6 locator of routers are different, and both 591 of them need to be imported into the IGP. The 169 backbone is a 592 native IPv6 network. Between metro and backbone, the border routers 593 establish EBGP peer with each other, e.g. CR1 with CR2, CR3 with 594 CR4, to form basic connectivity. All of these constitute the 595 foundation of overlay services, and have not been changed. 597 PE1 and PE2 establish EBGP peer and advertise VPNv4 routes with each 598 other. If one site connects to two PEs, metro network will use multi 599 RD, community and local preference rules to choose one best route and 600 one backup. 602 After basic routing among networks and VPN routes between the two PEs 603 are all ready, two PEs encapsulate and forward VPN traffic within 604 SRv6 tunnel. The tunnel is SRv6 best effort (BE) tunnel. It 605 introduces only outer IPv6 header but not SRH header into traffic 606 packets. After encapsulation, the packet is treated as common IPv6 607 packet and forwarded to the egress PE, which performs decapsulation 608 and forwards the VPN traffic according to specific VRF. 610 Guangdong Unicom has also lauched the SRv6 L3VPN among Guangzhou, 611 Shenzhen, and Dongguan, which has passed the interop test between 612 different vendors. 614 With SRv6 enabled at the PE devices, the VPN service can be launched 615 very quickly without impact on the existing traffic. With SRv6 TE 616 further deployed, more benefits of using SRv6 can be exploited. 618 7. IANA Considerations 620 There are no IANA considerations in this document. 622 8. Security Considerations 624 TBD. 626 9. Acknowledgement 628 The section on the PSP use cases is inspired from the discussions 629 over the mailing list. The authors would like to acknowledge the 630 constructive discussions from Daniel Voyer, Jingrong Xie, etc.. 632 10. Contributors 634 Hailong Bai 635 China Unicom 636 China 638 Email: 640 Jichun Ma 641 China Unicom 642 China 644 Email: 646 Huizhi Wen 647 Huawei 648 China 650 Email: wenhuizhi@huawei.com 652 Ruizhao Hu 653 Huawei 654 China 656 Email: huruizhao@huawei.com 658 Jianwei Mao 659 Huawei 660 China 661 Email: maojianwei@huawei.com 663 11. References 665 11.1. Normative References 667 [I-D.ietf-6man-segment-routing-header] 668 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 669 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 670 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 671 progress), October 2019. 673 [I-D.ietf-spring-srv6-network-programming] 674 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 675 Matsushima, S., and Z. Li, "SRv6 Network Programming", 676 draft-ietf-spring-srv6-network-programming-10 (work in 677 progress), February 2020. 679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, 681 DOI 10.17487/RFC2119, March 1997, 682 . 684 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 685 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 686 2006, . 688 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 689 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 690 DOI 10.17487/RFC5659, October 2009, 691 . 693 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 694 (IPv6) Specification", STD 86, RFC 8200, 695 DOI 10.17487/RFC8200, July 2017, 696 . 698 11.2. Informative References 700 [I-D.matsushima-spring-srv6-deployment-status] 701 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 702 Implementation and Deployment Status", draft-matsushima- 703 spring-srv6-deployment-status-05 (work in progress), 704 January 2020. 706 [I-D.peng-spring-srv6-compatibility] 707 Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li, 708 Z., and J. Guichard, "SRv6 Compatibility with Legacy 709 Devices", draft-peng-spring-srv6-compatibility-02 (work in 710 progress), January 2020. 712 Authors' Addresses 714 Hui Tian 715 CAICT 716 China 718 Email: tianhui@caict.ac.cn 720 Feng Zhao 721 CAICT 722 China 724 Email: zhaofeng@caict.ac.cn 726 Chongfeng Xie 727 China Telecom 728 China 730 Email: xiechf.bri@chinatelecom.cn 732 Tong Li 733 China Unicom 734 China 736 Email: litong@chinaunicom.cn 738 Jichun Ma 739 China Unicom 740 China 742 Email: majc16@chinaunicom.cn 744 Shuping Peng 745 Huawei Technologies 746 China 748 Email: pengshuping@huawei.com 749 Zhenbin Li 750 Huawei Technologies 751 China 753 Email: lizhenbin@huawei.com 755 Yaqun Xiao 756 Huawei Technologies 757 China 759 Email: xiaoyaqun@huawei.com