idnits 2.17.1 draft-dong-teas-enhanced-vpn-vtn-scalability-04.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 (25 October 2021) is 912 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.dong-lsr-sr-enhanced-vpn' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lsr-flex-algo' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 666, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-08 == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-05 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-06 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 == Outdated reference: A later version (-07) exists of draft-ietf-lsr-isis-sr-vtn-mt-01 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-03 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-for-enhanced-vpn-01 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-04 == Outdated reference: A later version (-07) exists of draft-zhu-lsr-isis-sr-vtn-flexalgo-03 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: 28 April 2022 L. Gong 6 China Mobile 7 G. Yang 8 China Telecom 9 J. Guichard 10 Futurewei Technologies 11 G. Mishra 12 Verizon Inc. 13 F. Qin 14 China Mobile 15 25 October 2021 17 Scalability Considerations for Enhanced VPN (VPN+) 18 draft-dong-teas-enhanced-vpn-vtn-scalability-04 20 Abstract 22 Enhanced VPN (VPN+) aims to meet the needs of some customers or 23 applications, including the customers and applications that are 24 associated with 5G, which requires connectivity services with 25 advanced characteristics, such as the assurance of some Service Level 26 Objectives (SLOs) and specific Service Level Expectations (SLEs). 27 VPN+ could be used for network slice realization both in the context 28 of 5G and in more generic scenarios, such as enterprise services 29 which have requirement on the performance assurance. With the demand 30 for VPN+ services increases, scalability would become an important 31 factor for the large scale deployment of VPN+. This document 32 describes the scalability considerations about the network control 33 plane and data plane in enabling VPN+ services, some optimization 34 mechanisms are also proposed. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 28 April 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. VPN+ Scalability Requirements . . . . . . . . . . . . . . . . 4 71 3. VTN Scalability Considerations . . . . . . . . . . . . . . . 5 72 3.1. Control Plane Scalability . . . . . . . . . . . . . . . . 6 73 3.1.1. Distributed Control Plane . . . . . . . . . . . . . . 6 74 3.1.2. Centralized Control Plane . . . . . . . . . . . . . . 6 75 3.2. Data Plane Scalability . . . . . . . . . . . . . . . . . 7 76 3.3. Gap Analysis of Existing Mechanisms . . . . . . . . . . . 8 77 4. Proposed Scalability Optimizations . . . . . . . . . . . . . 8 78 4.1. Control Plane Optimizations . . . . . . . . . . . . . . . 9 79 4.2. Data Plane Optimizations . . . . . . . . . . . . . . . . 11 80 5. Solution Evolution for Improved Scalability . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 10.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 Virtual Private Networks (VPNs) have served the industry well as a 93 means of providing different customers with logically separated 94 connectivity services over a common network infrastructure. The 95 common or base network that is used to provide the VPNs is often 96 referred to as the underlay, and the VPNs are often called the 97 overlay. The underlay network is responsible for establishing the 98 network connectivity and managing the network resources to meet 99 specific service requirement. The overlay network is used to 100 distribute the membership and reachability information of the 101 customers, and provide logical separation in terms of service 102 delivery between different customers in the shared network. 104 Enhanced VPN (VPN+) aims to meet the needs of some customers or 105 applications, including the applications that are associated with 5G, 106 which requires connectivity services with advanced characteristics, 107 such as the assurance of Service Level Objectives (SLOs) and specific 108 Service Level Expectations (SLEs). 109 [I-D.ietf-teas-ietf-network-slices] defines the terminologies and the 110 general framework of IETF network slices. VPN+ could be used for 111 IETF network slice realization both in the context of 5G and in more 112 generic scenarios, such as enterprise services which have requirement 113 on the performance assurance. 115 [I-D.ietf-teas-enhanced-vpn] describes the framework for delivering 116 VPN+ services. To meet the requirement of some VPN+ services, a 117 Virtual Transport Networks (VTNs) need to be created, which has a 118 subset of network resources allocated from the physical network and 119 is associated with a logical network topology to meet the 120 requirements of one or a group of VPN+ services. VPN+ services can 121 be delivered by mapping one or a group of overlay VPNs to the 122 appropriate VTNs as the virtual underlay. 124 Section 6 of [I-D.ietf-teas-enhanced-vpn] provides some general 125 analysis of the scalability of VPN+. This document gives further 126 analysis of the scalability considerations when a large number of 127 VPN+ services needs to be provided. Since the scalability of the 128 overlay is usually not the major bottleneck, this document mainly 129 focuses on the scalability of the VTNs in the underlay . 131 2. VPN+ Scalability Requirements 133 As described in [I-D.ietf-teas-enhanced-vpn], VPN+ services may 134 require additional state to be introduced into the network to take 135 advantage of the enhanced functionality. This may introduces some 136 concerns about the network scalability. This section gives some 137 analysis of the number of VPN+ services and the VTNs that might be 138 needed in different network scenarios. 140 Since the typical use case of VPN+ is to deliver IETF network slice 141 [I-D.ietf-teas-ietf-network-slices] for customers and services in 5G 142 and other scenarios, the number of IETF network slices required could 143 reflect the number of VPN+ needed in the network. With the 144 development and evolution of 5G and other services, it is expected 145 that an increasing number of IETF network slices will be deployed. 146 The number of network slices required depends on how IETF network 147 slices will be used, and the progress of network slicing for the 148 vertical industrial services. The potential number of VPN+ services 149 and VTNs is analyzed by classifying the network slice deployment into 150 three typical scenarios: 152 1. IETF network slices can be used by a network operator for 153 different types of services. For example, in a converged multi- 154 service network, different IETF network slices can be created to 155 carry mobile transport service, fixed broadband service and 156 enterprise services respectively, each type of service could be 157 managed by a separate department or management team. Some 158 service types, such as multicast service may also be deployed in 159 a dedicated network slice. In this case, a separate VTN may need 160 to be created for each service type. It is also possible that a 161 network infrastructure operator provides IETF network slices to 162 other network operators as a wholesale service, and a VTN may 163 also be needed for each wholesale service customer. In this 164 scenario, the number of VTNs in a network could be relatively 165 small, such as in the order of 10 or so. This could be one of 166 the typical cases in the beginning of IETF network slice 167 deployment. 169 2. IETF network slices can be requested by customers in vertical 170 industries, where the assurance of SLOs and the fulfilment of 171 SLEs are quite important. At the early stage of the vertical 172 industrial services, a few top customers in some industries will 173 begin to use IETF network slices to provide performance assurance 174 to their business, such as smart grid, manufacturing, public 175 safety, on-line gaming, etc. The realization of such IETF 176 network slices typically requires to provide different VTNs for 177 different industries, and some top customers can require 178 dedicated VTNs for strict service performance guarantee. 180 Considering the number of vertical industries, and the number of 181 top customers in each industry, the number of VTNs needed may be 182 in the order of 100. 184 3. With the evolution of 5G and cloud networks, IETF network slices 185 could be widely used by various vertical industrial customers and 186 enterprise customers who require guaranteed or predictable 187 service performance. The total amount of IETF network slices may 188 increase to thousands or more, although it is expected that the 189 number of IETF network slices would still be less than the number 190 of traditional VPN services in the network. Accordingly, the 191 number of VTNs needed may be in the order of 1000. 193 As defined by 3GPP [TS23501], a 5G network slice is identified using 194 the Single Network Slice Selection Assistance Information (S-NSSAI), 195 which is a 32-bit identifier comprised of 8-bit Slice/Service Type 196 (SST) and 24-bit Slice Differentiator (SD). This allows the mobile 197 networks (the RAN and mobile core networks) to support a large number 198 of 5G network slices. Although it is likely that multiple 5G network 199 slices are mapped to the same IETF network slice, in some cases the 200 number of IETF network slices may still be comparable to the number 201 of 5G network slices. 203 8-bit 24-bit 204 +------------+-------------------------+ 205 | SST | Slice Differentiator | 206 +------------+-------------------------+ 208 Figure 1. Format of S-NSSAI in 3GPP 210 Thus solution of VPN+ and VTN needs to meet the scalability 211 requirement of IETF network slices in different scenarios. The 212 increased number of VPN+ services will introduce additional 213 complexity and overhead both to the control plane and the data plane, 214 especially in the aspects related to the underlay VTNs. Although in 215 many cases multiple VPN+ services can be mapped to the same VTN as 216 the underlay, there still can be scalability challenges with the 217 increased number of VTNs. 219 3. VTN Scalability Considerations 221 In this section, the scalability of VTN in the control plane and data 222 plane is analyzed to understand the possible gaps in meeting the 223 scalability requirement of VPN+ and VTN. 225 3.1. Control Plane Scalability 227 As described in [I-D.ietf-teas-enhanced-vpn], the control plane of 228 VPN+ could be based on the hybrid of a centralized controller and the 229 distributed control plane. 231 3.1.1. Distributed Control Plane 233 At part of the delivery of VPN+ services, it is necessary to create 234 multiple VTNs, each of which is allocated with a set of dedicated or 235 shared network resources, and is associated with a customized logical 236 topology. The topological and resource attributes and the state 237 information of each VTN may need to be exchanged among the network 238 nodes. The scalability of the distributed control plane used for the 239 distribution of VTN information needs to be considered in the 240 following aspects: 242 * The number of control protocol instances maintained on each node 244 * The number of protocol sessions maintained on each link 246 * The number of routes advertised by each node 248 * The amount of attributes associated with each route 250 * The number of route computation (i.e. SPF computation) executed 251 by each node 253 As the number of VTNs increases, it is expected that in some of the 254 above aspects, the overhead in the control plane may increase 255 dramatically. For example, the overhead of maintaining separated 256 control protocol instances (e.g. IGP instances) for different VTNs 257 is considered higher than maintaining the information of separated 258 VTNs in the same control protocol instance with appropriate 259 separation, and the overhead of maintaining separate protocol 260 sessions for different VTNs is considered higher than using a shared 261 protocol session for the information exchange of multiple VTNs. To 262 meet the requirement of the increasing number of VTNs, It is 263 suggested to choose the control plane mechanisms which could improve 264 the scalability while still provide the required functionality. 266 3.1.2. Centralized Control Plane 268 By introducing the centralized network controller, the SDN approach 269 can reduce the amount of control plane overhead in the distributed 270 control plane, while it may also transfer some of the scalability 271 concerns from network nodes to the centralized controller, thus the 272 scalability of the controller also needs to be considered. 274 To provide global optimization for the Traffic Engineered (TE) paths 275 in different VTNs, the controller needs to keep the topology and 276 resource information of all the VTNs up-to-date. To achieve this, 277 the controller may need to maintain a communication channel with each 278 network node in the network. When there is significant change in the 279 network, or multiple VTNs requires global optimization concurrently, 280 there may be a heavy processing burden at the controller, and a heavy 281 load in the network surrounding the controller for the distribution 282 of the updated network state and the TE paths. 284 3.2. Data Plane Scalability 286 To provide different VPN+ services with the required SLOs and SLEs, 287 it is necessary to allocate different subsets of network resources to 288 different VTNs to avoid or reduce unexpected interruption. As the 289 number of VTNs increases, it is required that the underlying network 290 can provide fine-granular network resource partitioning, which means 291 the amount of state about the partitioned network resources to be 292 maintained on the network nodes will also increase. 294 In packet forwarding, VPN+ service traffic needs to be processed 295 separately according to the topology and resource attributes of the 296 VTN it mapped to, this means that some fields in the data packet 297 needs to be used to identify the VTN topology and resources either 298 directly or implicitly. Different approaches of encapsulating the 299 VTN information in data packet can have different scalability 300 implications. 302 One practical approach is to reuse some of the existing fields in the 303 data packet to additionally identify the VTN the packet belongs to. 304 For example, the destination IP addresses or the MPLS forwarding 305 labels may be reused to further identify a VTN. This can avoid the 306 cost of introducing new fields in the data packet, while since it 307 introduces additional semantics to the existing fields, the 308 processing of the existing fields in packet forwarding may need to be 309 changed. Moreover, introducing VTN semantics to existing identifiers 310 in the packet (e.g. IP addresses, MPLS forwarding labels, etc.) may 311 result in the increase of the amount of the existing IDs in 312 proportion to the number of the VTNs, which may cause scalability 313 problem in networks where a relatively large number of VTNs is 314 needed. 316 An alternative approach is to introduce a new dedicated field in the 317 data packet for VTN identification. This could avoid the impacts to 318 the existing fields in the packet. And if this new field carries a 319 global-significant VTN identifier, it could be used together with the 320 existing fields to determine the VTN-specific packet forwarding. The 321 potential issue with this approach is the difficulty in introducing a 322 new field in some of the data plane technologies. 324 In addition, the introduction of per VTN packet forwarding has impact 325 on the scalability of the forwarding entries on network nodes, as a 326 network node may need to maintain separate forwarding entries for 327 each VTN it participates in. 329 3.3. Gap Analysis of Existing Mechanisms 331 One candidate mechanism to build VTN is to use VTN-specific Segment 332 Routing (either SR-MPLS or SRv6) Identifiers in the data plane as 333 described in [I-D.ietf-spring-sr-for-enhanced-vpn], and define and 334 distribute the associated topology and resource attribute of each VTN 335 based on either Multi-topology [I-D.ietf-lsr-isis-sr-vtn-mt], Flex- 336 Algo [I-D.zhu-lsr-isis-sr-vtn-flexalgo] or the combination of these 337 mechanisms in the control plane. This mechanism is suitable for 338 networks where a small number of VTNs is needed. As the number of 339 VTNs increases, there may be several scalability challenges with this 340 approach: 342 1. The number of SR SIDs needed will increase in proportion to the 343 number of VTNs in the network, which will bring challenges both 344 to the distribution of SIDs and the related information in the 345 control plane, and to the installation of forwarding entries for 346 VTN-specific SIDs in the data plane. 348 2. The number of route computation (e.g. SPF computation) will 349 increase in proportion to the number of VTNs in the network, 350 which may introduce significant overhead to the control plane of 351 network nodes. 353 3. The maximum number of logical topologies supported by OSPF is 354 128, and the maximum number of Flex-Algo is 128, which may not 355 meet the required number of VTNs in some network scenarios. 357 4. Proposed Scalability Optimizations 358 4.1. Control Plane Optimizations 360 For the distributed control plane, several optimizations can be 361 considered to reduce the control plane overhead and improve the 362 control plane scalability. 364 The first optimization mechanism is to reduce the amount of control 365 plane sessions used for the establishment and maintenance of the 366 VTNs. For multiple VTNs which have the same peering relationship 367 between two adjacent network nodes, it is proposed that one single 368 control protocol session is used for the establishment of multiple 369 VTNs. The information of different VTNs can be exchanged over the 370 same session, with necessary identification information to 371 distinguish the VTNs in the control messages. This could reduce the 372 overhead of maintaining a large number of control protocol sessions 373 for different VTNs, and could also reduce the amount of control plane 374 messages flooded in the network. 376 The second optimization mechanism is to decompose the attributes of a 377 VTN into different groups, so that different types of VTN attribute 378 can be advertised and processed separately in control plane. There 379 are two basic types of attributes associated with a VTN: the topology 380 attribute and the network resource attribute. In a network, it is 381 possible that multiple VTNs share the same topology, and multiple 382 VTNs may share the same set of network resources on particular 383 network nodes and links. Then it is more efficient if only one copy 384 of the topology information is advertised, and multiple VTNs sharing 385 the same topology could refer to this topology information. More 386 importantly, with this approach, the result of topology-based route 387 computation could be shared by multiple VTNs, so that the overhead of 388 per-VTN route computation could also be reduced . Similarly, 389 information of a subset of network resources reserved on a particular 390 network node or link could be advertised once and be referred to by 391 multiple VTNs which share the same set of resources. This 392 methodology could also apply to other attributes of VTN which may be 393 introduced later and can be processed independently. 395 O#####O#####O O*****O*****O 396 # # # * * * 397 # # # * * * 398 O#####O#####O O*****O*****O 400 VTN-1 VTN-2 402 O-----O-----O 403 | | | 404 | | | 405 O-----O-----O 407 Shared Network Topology 409 Legend 411 O Virtual node 412 ### Virtual links with a set of reserved resources 413 *** Virtual links with another set of reserved resources 415 Figure 2. Topology Sharing between VTNs 417 Figure 1: FIG-2 419 Figure 2 gives an example of two VTNs which share the same logical 420 topology. As shown in the figure, VTN-1 and VTN-2 are associated 421 with the same topology, while the resource attributes of each VTN are 422 different. In this case, only one copy of the network topology 423 information needs to be advertised, and the topology-based route 424 computation result can be shared by the two VTNs to generate the 425 corresponding routing and forwarding tables. 427 O#####O#####O O----O#####O 428 # # # \/ # # 429 # # # /\ # # 430 O#####O#####O O----O#####O 432 VTN-1 VTN-2 434 Legend 436 O Virtual node 437 ### Virtual links with a set of reserved resource 438 --- Virtual links with another set of reserved resource 440 Figure 3. Resource Sharing between VTNs 442 Figure 3 gives another example of two VTNs which share the same set 443 of network resources on some of the links. In this case, information 444 about the resources allocated on each link only needs to be 445 advertised once, then both VTN-1 and VTN-2 could refer to the 446 reserved link resource for constraint based path computation. 448 For the optimization of the centralized control plane, it is 449 suggested that the centralized controller is used as a complementary 450 mechanism to the distributed control plane rather than a replacement, 451 so that the workload for VTN specific path computation in control 452 plane could be shared by both the centralized controller and the 453 network nodes, and the scalability of both systems could be improved. 455 4.2. Data Plane Optimizations 457 To support more VPN+ services while keeping the amount of data plane 458 state at a reasonable scale, one typical approach is to classify a 459 set of VPN+ services which have similar service characteristics and 460 performance requirements into a group, and such group of VPN+ 461 services are mapped to one VTN, which is allocated with an aggregated 462 set of network resources and the union of the required logical 463 topologies to meet the service requirement of the whole group of VPN+ 464 services. Different groups of VPN+ services can be mapped to 465 different VTNs with different set of network resources allocated. 466 With appropriate grouping of VPN+ services, a reasonable number of 467 VTNs with network resources reservation and aggregation could still 468 meet the service requirements. 470 Another optimization in the data plane is to decouple the identifiers 471 used for topology-based forwarding and the identifier used for the 472 resource-specific processing introduced by VTN. One possible 473 mechanism is to introduce a dedicated VTN Resource identifier in the 474 packet header to uniquely identify the set of local network resources 475 allocated to a VTN on each network node for the processing and 476 forwarding of the received packets. Then the existing identifiers in 477 the packet header used for topology based forwarding (e.g. the 478 destination IP address, MPLS forwarding labels) are kept unchanged. 479 The benefit is the amount of the existing topology-specific 480 identifiers will not be impacted by the increasing number of VTNs. 481 Since this new VTN Resource ID field will be used together with other 482 existing fields to determine the VTN-specific packet forwarding, this 483 may require network nodes to support a hierarchical forwarding table 484 in data plane. Figure 4 shows the concept of using different data 485 plane identifiers for topology-specific and resource-specific packet 486 forwarding and processing in a VTN respectively. 488 +--------------------------+ 489 | Packet Header | 490 | | 491 | +----------------------+ | 492 | | Topology-specific IDs| | 493 | +----------------------+ | 494 | | 495 | +----------------------+ | 496 | | VTN Resource ID | | 497 | +----------------------+ | 498 +--------------------------+ 500 Figure 4. Decoupled Data Plane Topology and Resource Identifiers 502 In an IPv6 [RFC8200] based network, this could be achieved by 503 introducing a dedicated field in either the IPv6 fixed header or the 504 extension headers to carry the VTN resource identifier for the 505 resource-specific forwarding, while keeping the destination IP 506 address field used for routing towards the destination prefix in the 507 corresponding topology. Note that the VTN resource ID needs to be 508 parsed by every node along the path which is capable of VTN-specific 509 forwarding. [I-D.dong-6man-enhanced-vpn-vtn-id] introduces the 510 mechanism of carrying the VTN resource ID in IPv6 Hop-by-Hop 511 extension header. 513 In an MPLS [RFC3032] based network, this may be achieved by 514 introducing a dedicated VTN resource ID either in the MPLS label 515 stack or following the MPLS label stack. This way, the existing MPLS 516 forwarding labels could be used for topology-specific packet 517 forwarding towards the destination node, and the VTN resource ID is 518 used to determine the set of network resources for packet processing. 519 This requires that both the forwarding label and the VTN Resource ID 520 be parsed by nodes along the forwarding path of the packet, and the 521 forwarding behavior may depend on the position of the VTN resource ID 522 in the packet. The detailed extensions in MPLS data plane are out of 523 the scope of this document. 525 5. Solution Evolution for Improved Scalability 527 Based on the analysis in this document, the control plane and data 528 plane for VPN+ and VTN needs to evolve to support the increasing 529 number of VPN+ services and the increasing number of VTNs in the 530 network. 532 At the first step, by introducing resource-awareness to segment 533 routing SIDs [I-D.ietf-spring-resource-aware-segments], and using 534 Multi-Topology or Flex-Algo as the control plane, it could provide a 535 solution for building a limited number of VTNs in the network to meet 536 the requirement of a relatively small number of VPN+ services in the 537 network. This mechanism is considered as the basic SR VTN. 539 As the required number of VPN+ services increases, more VTNs may be 540 needed, then the control plane scalability could be improved by 541 decoupling the topology attribute from the resource attribute and 542 other attributes of VTN, so that multiple VTNs could share the same 543 topology or resource attribute to reduce the control plane and data 544 plane overhead. This mechanism is considered as the scalable SR VTN. 545 Both the basic and the scalable SR VTN mechanisms are described in 546 [I-D.ietf-spring-sr-for-enhanced-vpn]. 548 If the data plane scalability becomes a concern, a dedicated VTN 549 resource ID can be introduced in the data packet to decouple the 550 topology-specific identifiers from the VTN resource identifiers in 551 the data plane, this could help to reduce the number of SR SIDs 552 needed to support a large number of VTNs. This mechanism is 553 considered as the Resource-Independent (RI) VTN. 555 6. Security Considerations 557 This document describes the scalability considerations about the 558 network control plane and data plane in enabling VPN+ services and 559 the VTNs, and proposes several scalability optimization mechanisms. 560 The security considerations in [I-D.ietf-teas-enhanced-vpn] applies 561 to this document. 563 7. IANA Considerations 565 This document makes no request of IANA. 567 8. Contributors 569 Zhibo Hu 570 Email: huzhibo@huawei.com 572 Hongjie Yang 573 Email: hongjie.yang@huawei.com 575 9. Acknowledgments 577 The authors would like to thank Adrian Farrel for the review and 578 discussion of this document. 580 10. References 582 10.1. Normative References 584 [I-D.ietf-teas-enhanced-vpn] 585 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 586 Framework for Enhanced Virtual Private Network (VPN+) 587 Services", Work in Progress, Internet-Draft, draft-ietf- 588 teas-enhanced-vpn-08, 12 July 2021, 589 . 592 10.2. Informative References 594 [I-D.dong-6man-enhanced-vpn-vtn-id] 595 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 596 "Carrying Virtual Transport Network Identifier in IPv6 597 Extension Header", Work in Progress, Internet-Draft, 598 draft-dong-6man-enhanced-vpn-vtn-id-05, 8 September 2021, 599 . 602 [I-D.dong-lsr-sr-enhanced-vpn] 603 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 604 and S. Bryant, "IGP Extensions for Scalable Segment 605 Routing based Enhanced VPN", Work in Progress, Internet- 606 Draft, draft-dong-lsr-sr-enhanced-vpn-06, 11 July 2021, 607 . 610 [I-D.ietf-lsr-flex-algo] 611 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 612 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 613 Internet-Draft, draft-ietf-lsr-flex-algo-17, 6 July 2021, 614 . 617 [I-D.ietf-lsr-isis-sr-vtn-mt] 618 Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi- 619 Topology (MT) for Segment Routing based Virtual Transport 620 Network", Work in Progress, Internet-Draft, draft-ietf- 621 lsr-isis-sr-vtn-mt-01, 12 July 2021, 622 . 625 [I-D.ietf-spring-resource-aware-segments] 626 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 627 Z., and F. Clad, "Introducing Resource Awareness to SR 628 Segments", Work in Progress, Internet-Draft, draft-ietf- 629 spring-resource-aware-segments-03, 12 July 2021, 630 . 633 [I-D.ietf-spring-sr-for-enhanced-vpn] 634 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 635 Z., and F. Clad, "Segment Routing based Virtual Transport 636 Network (VTN) for Enhanced VPN", Work in Progress, 637 Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01, 638 12 July 2021, . 641 [I-D.ietf-teas-ietf-network-slices] 642 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 643 Makhijani, K., Contreras, L. M., and J. Tantsura, 644 "Framework for IETF Network Slices", Work in Progress, 645 Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 646 August 2021, . 649 [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 650 Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment 651 Routing based VTN", Work in Progress, Internet-Draft, 652 draft-zhu-lsr-isis-sr-vtn-flexalgo-03, 11 July 2021, 653 . 656 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 657 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 658 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 659 . 661 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 662 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 663 RFC 4915, DOI 10.17487/RFC4915, June 2007, 664 . 666 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 667 Topology (MT) Routing in Intermediate System to 668 Intermediate Systems (IS-ISs)", RFC 5120, 669 DOI 10.17487/RFC5120, February 2008, 670 . 672 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 673 (IPv6) Specification", STD 86, RFC 8200, 674 DOI 10.17487/RFC8200, July 2017, 675 . 677 [TS23501] "3GPP TS23.501", 2016, 678 . 681 Authors' Addresses 683 Jie Dong 684 Huawei Technologies 685 Huawei Campus, No. 156 Beiqing Road 686 Beijing 687 100095 688 China 690 Email: jie.dong@huawei.com 692 Zhenbin Li 693 Huawei Technologies 694 Huawei Campus, No. 156 Beiqing Road 695 Beijing 696 100095 697 China 699 Email: lizhenbin@huawei.com 701 Liyan Gong 702 China Mobile 703 No. 32 Xuanwumenxi Ave., Xicheng District 704 Beijing 705 China 707 Email: gongliyan@chinamobile.com 709 Guangming Yang 710 China Telecom 711 No.109 West Zhongshan Ave., Tianhe District 712 Guangzhou 713 China 715 Email: yangguangm@chinatelecom.cn 716 James N Guichard 717 Futurewei Technologies 718 2330 Central Express Way 719 Santa Clara, 720 United States of America 722 Email: james.n.guichard@futurewei.com 724 Gyan Mishra 725 Verizon Inc. 727 Email: gyan.s.mishra@verizon.com 729 Fengwei Qin 730 China Mobile 731 No. 32 Xuanwumenxi Ave., Xicheng District 732 Beijing 733 China 735 Email: qinfengwei@chinamobile.com