idnits 2.17.1 draft-dong-teas-enhanced-vpn-vtn-scalability-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 457: '...N-specific packet forwarding, this MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2021) is 1019 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-07 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-15 == Outdated reference: A later version (-07) exists of draft-ietf-lsr-isis-sr-vtn-mt-00 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-02 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-for-enhanced-vpn-00 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-00 == Outdated reference: A later version (-07) exists of draft-zhu-lsr-isis-sr-vtn-flexalgo-02 Summary: 1 error (**), 0 flaws (~~), 8 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: January 12, 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 July 11, 2021 17 Scalability Considerations for Enhanced VPN (VPN+) 18 draft-dong-teas-enhanced-vpn-vtn-scalability-03 20 Abstract 22 Enhanced VPN (VPN+) aims to provide enhancements to existing VPN 23 services to support the needs of new applications, particularly 24 including the applications that are associated with 5G services. 25 VPN+ could be used to provide network slicing, and may also be of use 26 in more generic scenarios, such as enterprise services which have 27 demanding requirement. With the requirement for VPN+ services 28 increase, scalability would become an important factor for the 29 deployment of VPN+. This document describes the scalability 30 considerations in the control plane and data plane to enable VPN+ 31 services, some optimization mechanisms are also described. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 12, 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. VPN+ Scalability Requirements . . . . . . . . . . . . . . . . 3 69 3. VPN+ Scalability Considerations . . . . . . . . . . . . . . . 5 70 3.1. Control Plane Scalability . . . . . . . . . . . . . . . . 5 71 3.1.1. Distributed Control Plane . . . . . . . . . . . . . . 5 72 3.1.2. Centralized Control Plane . . . . . . . . . . . . . . 6 73 3.2. Data Plane Scalability . . . . . . . . . . . . . . . . . 6 74 3.3. Gap Analysis of Existing Mechanisms . . . . . . . . . . . 7 75 4. Possible Scalability Optimizations . . . . . . . . . . . . . 8 76 4.1. Control Plane Optimizations . . . . . . . . . . . . . . . 8 77 4.2. Data Plane Optimizations . . . . . . . . . . . . . . . . 10 78 5. Solution Evolution for Improved Scalability . . . . . . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 Virtual Private Networks (VPNs) have served the industry well as a 91 means of providing different customers with logically isolated 92 connectivity over a common network infrastructure. The common or 93 base network that is used to provide the VPNs is often referred to as 94 the underlay, and the VPN is often called an overlay. The underlay 95 is responsible for establishing the network connectivity and managing 96 network resources to meet the service requirement. The overlay is 97 used to distribute the membership and reachability information of the 98 customer, and provide logical separation of service delivery between 99 different customers. 101 Enhanced VPN service (VPN+) [I-D.ietf-teas-enhanced-vpn] is targeted 102 at new applications which require better isolation between customers 103 and/or services, and have more stringent performance requirements 104 than can be provided with existing VPNs. To meet the requirement of 105 VPN+ services, a number of Virtual Transport Networks (VTNs) need to 106 be created, each has a subset of the underlay network topology and a 107 set of network resources allocated from the physical network to meet 108 the requirements of one or a group of VPN+ services. The overlay 109 VPNs together with the corresponding underlay VTN provide the VPN+ 110 service. 112 Section 6 of [I-D.ietf-teas-enhanced-vpn] provides some general 113 analysis of the scalability of VPN+. This document gives detailed 114 analysis of the scalability considerations when a large number of 115 VPN+ services are provided. Since the scalability of the overlay is 116 not the major bottleneck, this document mainly focuses on the 117 scalability of the underlay VTN. 119 2. VPN+ Scalability Requirements 121 As described in [I-D.ietf-teas-enhanced-vpn], VPN+ services may 122 require additional state to be introduced into the network to take 123 advantage of the enhanced functionality. This introduces some 124 scalability considerations to the network. This section gives some 125 analysis of the number of VPN+ services that might be needed in a 126 network. 128 There are several use cases where VPN+ may be needed, and these 129 determine how many VPN+ will be required in a network. One typical 130 use case of VPN+ is to deliver IETF network slice 131 [I-D.ietf-teas-ietf-network-slices] for applications or services in 132 5G and other scenarios, thus the number of IETF network slices needed 133 could reflect the number of VPN+ services. With the development and 134 evolution of 5G, it is expected that an increasing number of network 135 slices will be deployed. The number of network slices required 136 depends on how IETF network slices will be used, and the progress of 137 5G for the vertical industrial services. The potential number of 138 network slices is analyzed by classifying the network slicing 139 deployment into three typical scenarios: 141 1. Network slices can be used by a network operator internally for 142 different types of services. For example, in a converged multi- 143 service network, different network slices can be created to carry 144 mobile transport service, fixed broadband service and enterprise 145 services respectively, each type of service could be managed by a 146 separate department or management team. Some service types, such 147 as multicast service may also be deployed in a dedicated network 148 slice. It is also possible that an infrastructure network 149 operator provides network slices to other network operators as a 150 wholesale service. In this scenario, the number of network 151 slices in a network would be relatively small, such as on the 152 order of 10 or so. This could be the typical case in the 153 beginning of the network slice deployment. 155 2. Network slices can be used to provide isolated and customized 156 virtual networks for customers in different vertical industries. 157 At the early stage of the vertical industrial service deployment, 158 a few top customers in some industries will begin to use network 159 slices to ensure the performance of their business, such as smart 160 grid, manufacturing, public safety, on-line gaming, etc. 161 Considering the number of the vertical industries, and the number 162 of top customers in each industry, the number of network slices 163 may increase to the order of 100. 165 3. With the evolution of 5G, network slices could be widely used by 166 both vertical industrial customers and enterprise customers which 167 require guaranteed or predictable service performance. The total 168 amount of network slices may increase to the order of 1000 or 169 more. However, it is expected that the number of network slices 170 would still be less than the number of traditional VPN services 171 in the network. 173 In 3GPP [TS23501], a 5G network slice is identified using Single 174 Network Slice Selection Assistance Information (S-NSSAI), which is a 175 32-bit identifier comprised of 8-bit Slice/Service Type (SST) and 176 24-bit Slice Differentiator (SD). This allows the mobile networks 177 (RAN and CN) to provide a large number of network slices. Although 178 it is possible that multiple 5G network slices in RAN and CN are 179 mapped to the same IETF network slice, the number of IETF network 180 slices may still be comparable with the number of 5G network slices. 181 Thus the scalability of IETF network slices needs to be taken into 182 consideration. 184 8-bit 24-bit 185 +------------+-------------------------+ 186 | SST | Slice Differentiator | 187 +------------+-------------------------+ 189 Figure 1. Format of S-NSSAI in 3GPP 191 VPN+ needs to meet the scalability requirement of network slicing in 192 different scenarios. The increased number of VPN+ services will 193 introduce additional complexity and overhead to both the control 194 plane and data plane, especially in the aspects related to the 195 underlying VTNs. Although multiple VPN+ services can be mapped to 196 the same VTN as the underlay, there still can be scalability 197 challenges with the increased number of VTNs. 199 3. VPN+ Scalability Considerations 201 In this section, the scalability of VTN in the control plane and data 202 plane is analyzed to understand the possible gaps in meeting the 203 scalability requirement of VPN+. 205 3.1. Control Plane Scalability 207 As described in [I-D.ietf-teas-enhanced-vpn], the control plane of 208 VPN+ could be based on the hybrid of a centralized controller and the 209 distributed control plane. 211 3.1.1. Distributed Control Plane 213 At part of the construction of VPN+ services, it is necessary to 214 create multiple VTNs which provide customized topology and resource 215 attributes. The attributes and state information of each VTN needs 216 to be exchanged in the control plane. The scalability of the 217 distributed control plane for the establishment and maintenance of 218 VTNs needs to be considered in the following aspects: 220 o The number of control protocol instances maintained on each node 222 o The number of protocol sessions maintained on each link 224 o The number of routes advertised by each node 226 o The amount of attributes associated with each route 228 o The number of route computation (i.e. SPF computation) executed 229 on each node 231 As the number of VTNs increases, it is expected that in some of the 232 above aspects, the overhead in the control plane may increase 233 dramatically. For example, the overhead of maintaining separated 234 control protocol instances (e.g. IGP instances) for different VTNs 235 is considered higher than maintaining the information of separated 236 VTNs in the same control protocol instance with appropriate 237 separation, and the overhead of maintaining separate protocol 238 sessions for different VTNs is considered higher than using a shared 239 protocol session for the information exchange of multiple VTNs. To 240 meet the requirement of the increasing number of VTNs, It is 241 suggested to choose the control plane mechanisms which could improve 242 the scalability while still provide the required functionality. 244 3.1.2. Centralized Control Plane 246 Although the SDN approach can reduce the amount of control plane 247 overhead in the distributed control plane, it may transfer some of 248 the scalability concerns from network nodes to the centralized 249 controller, thus the scalability of the controller also needs to be 250 considered. 252 To provide global optimization for the Traffic Engineered (TE) paths 253 in different VTNs, the controller needs to keep the topology and 254 resource information of all the VTNs up to date. To achieve this, 255 the controller may need to maintain a communication channel with each 256 network node in the network. When there is significant change in the 257 network, or multiple VTNs requires global optimization concurrently, 258 there may be a heavy processing burden at the controller, and a heavy 259 load in the network surrounding the controller for the distribution 260 of the updated network state and the TE paths. 262 3.2. Data Plane Scalability 264 To provide different VPN+ services with the required isolation and 265 performance characteristics, it is necessary to allocate different 266 sets of network resources to different VTNs. As the number of VPN+ 267 increases, the number of VTNs will increase accordingly. This 268 requires the underlying network to provide fine-granular network 269 resource partitioning, which means the amount of state about the 270 reserved network resources to be maintained on network nodes will 271 also increase. 273 In data plane, traffic of different VPN+ services need to be 274 processed separately according to the topology and resource 275 constraints of the associated VTN , thus the information used for VTN 276 identification needs to be carried either directly or implicitly in 277 the data packet. Different approaches of encapsulating the VTN 278 information in data packet can have different scalability 279 implications. 281 One approach is to reuse some existing fields in the data packet to 282 additionally identify the VTN the packet belongs to. This avoids the 283 cost of introducing new fields in the data packet, while since it 284 introduces additional semantics to an existing field, it requires to 285 change the processing of the existing field in packet forwarding. 286 And when the identifiers which were used to identify a node or link 287 are reused to further identify a VTN, the number of the identifiers 288 may be increased in proportion to the number of the VTNs, which may 289 cause scalability problem in some networks. 291 Another alternative approach is to introduce a dedicated field in the 292 packet for VTN identification. This could avoid the impact to the 293 existing fields in the packet. And if this new field carries a 294 global-significant VTN identifier, it could be used together with the 295 existing fields to determine the VTN-specific packet forwarding. The 296 potential issue with this approach is the difficulty in introducing a 297 new field in some types of the data plane. 299 In addition, the introduction of per VTN packet forwarding has impact 300 on the scalability of the forwarding entries on network nodes, as a 301 network node may need to maintain separate forwarding entries for 302 each VTN it participates in. 304 3.3. Gap Analysis of Existing Mechanisms 306 One candidate approach to build VTN is to use VTN specific Segment 307 Routing (either SR-MPLS or SRv6) Identifiers in the data plane 308 [I-D.ietf-spring-sr-for-enhanced-vpn], and define and distribute the 309 associated topology and resource attribute of each VTN based on 310 Multi-topology [RFC4915] [RFC5120] [I-D.ietf-lsr-isis-sr-vtn-mt], 311 Flex-Algo [I-D.ietf-lsr-flex-algo] [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 312 or the combination of these mechanisms in the control plane. This 313 mechanism is suitable for networks with a limited number of VTNs. As 314 the number of VTNs increases, there may be several scalability 315 challenges with this approach: 317 1. The number of SR SIDs needed will increase in proportion to the 318 number of VTNs in the network, which will bring challenges both 319 to the distribution of SIDs and the related information in the 320 control plane, and to the installation of forwarding entries for 321 VTN-specific SIDs in the data plane. 323 2. The number of route computation (e.g. SPF computation) will 324 increase in proportion to the number of VTNs in the network, 325 which may introduce significant overhead to the control plane of 326 network nodes. 328 3. The maximum number of logical topologies supported by OSPF is 329 128, and the maximum number of Flex-Algo is 128, which may not 330 meet the required number of VTNs in some network scenarios. 332 4. Possible Scalability Optimizations 334 4.1. Control Plane Optimizations 336 For the distributed control plane, several optimizations can be 337 considered to reduce the control plane overhead and improve the 338 scalability. 340 The first optimization mechanism is to reduce the amount of control 341 plane sessions used for the establishment and maintenance of the 342 VTNs. For multiple VTNs which have the same peering relationship 343 between two adjacent network nodes, it is proposed that one single 344 control protocol session is used for the establishment of multiple 345 VTNs. The information of different VTNs can be exchanged over the 346 same session, with necessary identification information to 347 distinguish the VTNs in the control messages. This could reduce the 348 overhead of maintaining a large number of control protocol sessions 349 for different VTNs, and could also reduce the amount of control plane 350 messages flooded in the network. 352 The second optimization mechanism is to decompose the attributes of a 353 VTN into different groups, so that different types of VTN attribute 354 can be advertised and processed separately in control plane. There 355 are two basic types of attributes associated with a VTN: the topology 356 attribute and the network resource attribute. In a network, it is 357 possible that multiple VTNs share the same topology, and multiple 358 VTNs may share the same set of network resources on particular 359 network segments. Then it is more efficient if only one copy of the 360 topology attribute is advertised, and multiple VTNs sharing the same 361 topology could refer to this topology information. More importantly, 362 with this approach the result of topology-based route computation 363 could be shared by multiple VTNs, so that the overhead of per-VTN 364 route computation could be reduced . Similarly, information of a 365 subset of network resources reserved on a particular network segment 366 could be advertised once and be referred to by multiple VTNs which 367 share the same set of resources. This methodology could also apply 368 to other attributes of VTN which may be introduced later and can be 369 processed independently. 371 O#####O#####O O*****O*****O 372 # # # * * * 373 # # # * * * 374 O#####O#####O O*****O*****O 376 VTN-1 VTN-2 378 O-----O-----O 379 | | | 380 | | | 381 O-----O-----O 383 Shared Network Topology 385 Legend 387 O Virtual node 388 ### Virtual links with a set of reserved resources 389 *** Virtual links with another set of reserved resources 391 Figure 2. Topology Sharing between VTNs 393 FIG-2 395 Figure 2 gives an example of two VTNs which share the same logical 396 topology attribute. As shown in the figure, VTN-1 and VTN-2 have the 397 same topology, while the link resource attributes of each VTN are 398 different. In this case, only one copy of the network topology 399 information needs to be advertised, and the topology-based route 400 computation result can be shared by the two VTNs to generate the 401 corresponding routing and forwarding tables. 403 O#####O#####O O----O#####O 404 # # # \/ # # 405 # # # /\ # # 406 O#####O#####O O----O#####O 408 VTN-1 VTN-2 410 Legend 412 O Virtual node 413 ### Virtual links with a set of reserved resource 414 --- Virtual links with another set of reserved resource 416 Figure 3. Resource Sharing between VTNs 418 Figure 3 gives another example of two VTNs which share the same set 419 of network resources on some links. In this case, information about 420 the reserved resource on each link only needs to be advertised once, 421 then both VTN-1 and VTN-2 could refer to the link resource for 422 constraint based path computation. 424 For the optimization of the centralized control plane, it is 425 suggested that the centralized controller is used as a complementary 426 mechanism to the distributed control plane rather than a replacement, 427 so that the VTN specific path computation burden in control plane 428 could be shared by both the centralized controller and the network 429 nodes, thus the scalability of both systems could be improved. 431 4.2. Data Plane Optimizations 433 To support more VPN+ services while keeping the amount of data plane 434 state at a reasonable scale, one possible approach is to classify a 435 set of VPN+ services which have similar service characteristics and 436 performance requirements into a group, and such group of VPN+ 437 services is mapped to one VTN, which is allocated with an aggregated 438 set of network topology and resources to meet the service requirement 439 of the whole group of VPN+. Different groups of VPN+ services need to 440 be mapped to different VTNs with different set of network resources 441 allocated. With appropriate grouping of VPN+ services, a reasonable 442 number of VTNs with network resources reservation and aggregation 443 could still meet the service requirements. 445 Another optimization in the data plane is to decouple the identifier 446 used for topology-based forwarding and the identifier used for the 447 resource-specific processing introduced by VTN. One possible 448 mechanism is to introduce a dedicated VTN-ID in the packet header to 449 uniquely identify the set of local network resources allocated to a 450 VTN on each network node for the processing and forwarding of the 451 received packet. Then the existing identifier in the packet header 452 used for topology based forwarding is kept unchanged. The benefit is 453 the amount of topology-specific identifiers is in proportion to the 454 number of topologies rather than the number of VTNs, so that its 455 scalability will not be impacted by the increased number of VTN. 456 Since this new VTN-ID field will be used together with the existing 457 fields to determine the VTN-specific packet forwarding, this MAY 458 require network nodes to support a hierarchical forwarding table in 459 the data plane. Figure 4 shows the concept of using different data 460 plane identifiers for topology-based and VTN resource-based packet 461 processing respectively. 463 +--------------------------+ 464 | Packet Header | 465 | | 466 | +----------------------+ | 467 | | Topology-specific ID | | 468 | +----------------------+ | 469 | | 470 | +----------------------+ | 471 | | VTN Resource ID | | 472 | +----------------------+ | 473 +--------------------------+ 475 Figure 4. Decoupled Data Plane Identifiers 477 In an IPv6 [RFC8200] based network, this could be achieved by 478 introducing a dedicated field in either the IPv6 fixed header or the 479 extension headers to carry the VTN identifier for the resource- 480 specific forwarding, while keeping the destination IP address field 481 used for routing towards the destination prefix in the corresponding 482 topology. Note that the VTN-ID needs to be parsed by every node 483 along the path which is capable of VTN-specific forwarding. In an 484 MPLS [RFC3032] based network, this may be achieved by introducing a 485 dedicated MPLS label to identify the VTN, while the existing MPLS 486 labels could be used for topology-based packet forwarding towards the 487 associated destination prefix. This requires that both labels be 488 parsed by each node along the forwarding path of the packet, and the 489 forwarding behavoir depends on the position of the VTN label in the 490 label stack. Another option with the MPLS data plane is to introduce 491 a new MPLS extension header which follows the MPLS label stack to 492 carry the VTN-ID and the associated information. The detailed 493 extensions in IPv6 and MPLS data plane encapsulation are out of the 494 scope of this document. 496 5. Solution Evolution for Improved Scalability 498 Based on the analysis in this document, the control plane and data 499 plane for VPN+ needs to evolve to support the increasing number of 500 VPN+ services in the network. 502 At the first step, by introducing resource-awareness to segment 503 routing SIDs [I-D.ietf-spring-resource-aware-segments], and using 504 Multi-Topology or Flex-Algo as the control plane, it could provide a 505 solution for building a limited number of VTNs in the network to meet 506 the requirement of a relatively small number of VPN+ services in the 507 network. This mechanism is considered as the basic SR VTN. 509 As the number of required VPN+ services increases, more VTNs may be 510 needed, then the control plane scalability could be improved by 511 decoupling the topology attribute from other attributes (e.g. 512 resource attribute) of VTN, so that multiple VTNs could share the 513 same topology or resource attribute. This mechanism is considered as 514 the scalable SR VTN. Both the basic and the scalable SR VTN 515 mechanisms are described in [I-D.ietf-spring-sr-for-enhanced-vpn]. 517 If the data plane scalability becomes a concern, dedicated data plane 518 VTN-ID can be introduced to decouple the topology-specific 519 identifiers from the VTN-specific resource identifiers in the data 520 plane, this could help to reduce the number of SR SIDs needed to 521 support a large number of VTNs. This mechanism is considered as the 522 Resource-Independent (RI) VTN. 524 6. Security Considerations 526 TBD 528 7. IANA Considerations 530 This document makes no request of IANA. 532 8. Contributors 534 Zhibo Hu 535 Email: huzhibo@huawei.com 537 Hongjie Yang 538 Email: hongjie.yang@huawei.com 540 9. Acknowledgments 542 The authors would like to thank Adrian Farrel for the review and 543 discussion of this document. 545 10. References 547 10.1. Normative References 549 [I-D.ietf-teas-enhanced-vpn] 550 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 551 Framework for Enhanced Virtual Private Network (VPN+) 552 Services", draft-ietf-teas-enhanced-vpn-07 (work in 553 progress), February 2021. 555 10.2. Informative References 557 [I-D.ietf-lsr-flex-algo] 558 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 559 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 560 algo-15 (work in progress), April 2021. 562 [I-D.ietf-lsr-isis-sr-vtn-mt] 563 Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi- 564 Topology (MT) for Segment Routing based Virtual Transport 565 Network", draft-ietf-lsr-isis-sr-vtn-mt-00 (work in 566 progress), March 2021. 568 [I-D.ietf-spring-resource-aware-segments] 569 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 570 Z., and F. Clad, "Introducing Resource Awareness to SR 571 Segments", draft-ietf-spring-resource-aware-segments-02 572 (work in progress), February 2021. 574 [I-D.ietf-spring-sr-for-enhanced-vpn] 575 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 576 Z., and F. Clad, "Segment Routing based Virtual Transport 577 Network (VTN) for Enhanced VPN", draft-ietf-spring-sr-for- 578 enhanced-vpn-00 (work in progress), February 2021. 580 [I-D.ietf-teas-ietf-network-slices] 581 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 582 Makhijani, K., Contreras, L. M., and J. Tantsura, 583 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 584 network-slices-00 (work in progress), April 2021. 586 [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 587 Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment 588 Routing based VTN", draft-zhu-lsr-isis-sr-vtn-flexalgo-02 589 (work in progress), February 2021. 591 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 592 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 593 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 594 . 596 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 597 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 598 RFC 4915, DOI 10.17487/RFC4915, June 2007, 599 . 601 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 602 Topology (MT) Routing in Intermediate System to 603 Intermediate Systems (IS-ISs)", RFC 5120, 604 DOI 10.17487/RFC5120, February 2008, 605 . 607 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 608 (IPv6) Specification", STD 86, RFC 8200, 609 DOI 10.17487/RFC8200, July 2017, 610 . 612 [TS23501] "3GPP TS23.501", 2016, 613 . 616 Authors' Addresses 618 Jie Dong 619 Huawei Technologies 620 Huawei Campus, No. 156 Beiqing Road 621 Beijing 100095 622 China 624 Email: jie.dong@huawei.com 626 Zhenbin Li 627 Huawei Technologies 628 Huawei Campus, No. 156 Beiqing Road 629 Beijing 100095 630 China 632 Email: lizhenbin@huawei.com 634 Liyan Gong 635 China Mobile 636 No. 32 Xuanwumenxi Ave., Xicheng District 637 Beijing 638 China 640 Email: gongliyan@chinamobile.com 641 Guangming Yang 642 China Telecom 643 No.109 West Zhongshan Ave., Tianhe District 644 Guangzhou 645 China 647 Email: yangguangm@chinatelecom.cn 649 James N Guichard 650 Futurewei Technologies 651 2330 Central Express Way 652 Santa Clara 653 USA 655 Email: james.n.guichard@futurewei.com 657 Gyan Mishra 658 Verizon Inc. 660 Email: gyan.s.mishra@verizon.com 662 Fengwei Qin 663 China Mobile 664 No. 32 Xuanwumenxi Ave., Xicheng District 665 Beijing 666 China 668 Email: qinfengwei@chinamobile.com