idnits 2.17.1 draft-dong-teas-nrp-scalability-02.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 (16 May 2022) is 705 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-10 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-10 == Outdated reference: A later version (-06) exists of draft-ietf-6man-enhanced-vpn-vtn-id-00 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-19 == Outdated reference: A later version (-07) exists of draft-ietf-lsr-isis-sr-vtn-mt-02 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-04 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-for-enhanced-vpn-02 == Outdated reference: A later version (-07) exists of draft-zhu-lsr-isis-sr-vtn-flexalgo-04 Summary: 0 errors (**), 0 flaws (~~), 9 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: 17 November 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 T. Saad 16 V. Beeram 17 Juniper Networks 18 16 May 2022 20 Scalability Considerations for Network Resource Partition 21 draft-dong-teas-nrp-scalability-02 23 Abstract 25 The IETF Network Slice service aims to meet the connectivity demands 26 of a network slice customer with specific Service Level Objectives 27 (SLOs) and Service Level Expectations (SLEs) over a common underlay 28 network. A Network Resource Partition (NRP) is a set of network 29 resources that are allocated from the underlay network to carry a 30 specific set of network traffic and meet the required SLOs and SLEs. 31 One or multiple IETF Network Slice services can be mapped to one NRP. 33 As the demand for IETF Network Slice services increases, scalability 34 would become an important factor for the large scale deployment of 35 IETF Network Slices. Although the scalability of IETF Network Slices 36 can be improved by mapping a group of IETF Network Slices to one NRP, 37 there are concerns about the scalability of NRPs. This document 38 describes the scalability considerations about NRPs in the network 39 control plane and data plane, and some optimization mechanisms are 40 proposed. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 17 November 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Network Resource Partition Scalability Requirements . . . . . 3 77 3. Network Resource Partition Scalability Considerations . . . . 5 78 3.1. Control Plane Scalability . . . . . . . . . . . . . . . . 5 79 3.1.1. Distributed Control Plane . . . . . . . . . . . . . . 5 80 3.1.2. Centralized Control Plane . . . . . . . . . . . . . . 6 81 3.2. Data Plane Scalability . . . . . . . . . . . . . . . . . 7 82 3.3. Gap Analysis of the Existing Mechanism . . . . . . . . . 8 83 4. Proposed Scalability Optimizations . . . . . . . . . . . . . 8 84 4.1. Control Plane Optimizations . . . . . . . . . . . . . . . 9 85 4.1.1. Distributed Control Plane Optimizations . . . . . . . 9 86 4.1.2. Centralized Control Plane Optimization . . . . . . . 11 87 4.2. Data Plane Optimizations . . . . . . . . . . . . . . . . 12 88 5. Solution Evolution for Improved Scalability . . . . . . . . . 13 89 6. Operational Considerations . . . . . . . . . . . . . . . . . 14 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 96 11.2. Informative References . . . . . . . . . . . . . . . . . 15 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 The IETF Network Slice service aims to meet the connectivity demands 102 of a network slice customer with specific Service Level Objectives 103 (SLOs) and Service Level Expectations (SLEs) over a common underlay 104 network. [I-D.ietf-teas-ietf-network-slices] defines the 105 terminologies and the characteristics of IETF Network Slices. It 106 also discusses the general framework, the components and interfaces 107 for requesting and operating IETF Network Slices. For the 108 realization of IETF Network Slice services, a concept called Network 109 Resource Partition (NRP) is introduced, which refers to a set of 110 network resources that are available in the underlay network to 111 ensure the requested SLOs and SLEs of IETF Network Slices can be met. 113 [I-D.ietf-teas-enhanced-vpn] describes the layered framework and 114 candidate technologies for delivering enhanced VPN (VPN+) services. 115 VPN+ aims to meet the needs of customers or applications, including 116 the applications that are associated with 5G, which require 117 connectivity services with advanced characteristics, such as the 118 assurance of Service Level Objectives (SLOs) and specific Service 119 Level Expectations (SLEs). VPN+ services can be delivered by mapping 120 one or a group of overlay VPNs to a virtual underlay network built 121 with a set of network resources. The VPN+ framework and technologies 122 could be used for the realization of IETF Network Slice services. 123 NRP could be used as the underlay network construct to support the 124 VPN+ services. 126 As the demand for IETF Network Slice services increases, scalability 127 would become an important factor for the large scale deployment of 128 IETF Network Slices. Although the scalability of IETF Network Slices 129 can be improved by mapping a group of IETF Network Slices to one NRP, 130 there are concerns about the scalability of NRPs. This document 131 describes the scalability considerations about NRPs in the network 132 control plane and data plane, and some optimization mechanisms are 133 proposed. 135 2. Network Resource Partition Scalability Requirements 137 As described in [I-D.ietf-teas-ietf-network-slices], IETF Network 138 Slices may be grouped together according to their characteristics 139 (including SLOs and SLEs) and mapped the same NRP. An operator may 140 have customized policy on the grouping and mapping of IETF network 141 slices. This allows an operator to host a large number of slices on 142 a relatively small number of NRPs to reduce the amount of state 143 information needed in the network. This can help to avoid the 144 maintenance of per IETF Network Slice state in the underlay network. 146 With the development and evolution of 5G and other services, it is 147 expected that an increasing number of IETF Network Slices will be 148 deployed. The number of network slices required depends on how IETF 149 Network Slices will be used, and the progress of network slicing for 150 the vertical industrial services. The potential number of IETF 151 Network Slice services and NRPs is analyzed by classifying the 152 network slice deployment into three typical scenarios: 154 1. IETF Network Slices can be used by a network operator for 155 different types of service. For example, in a converged multi- 156 service network, different IETF Network Slices can be created to 157 carry mobile transport services, fixed broadband services and 158 enterprise services respectively: each type of service could be 159 managed by a separate department or management team. Some 160 service types, such as multicast services may also be deployed in 161 a dedicated NRP. In this case, a separate NRP may need to be 162 created for each service type. It is also possible that a 163 network infrastructure operator provides IETF Network Slices to 164 other network operators as a wholesale service, and a NRP may 165 also be needed for each wholesale service customer. In this 166 scenario, the number of NRPs in a network could be relatively 167 small, such as in the order of 10 or so. This could be one of 168 the typical cases in the beginning of IETF Network Slice 169 deployment. 171 2. IETF Network Slices can be requested by customers of industrial 172 verticals, where the assurance of SLOs and the fulfilment of SLEs 173 are quite important. At the early stage of the vertical 174 industrial services, a few top customers in some industries will 175 begin to use IETF Network Slices to provide performance assurance 176 to their business, such as smart grid, manufacturing, public 177 safety, on-line gaming, etc. The realization of such IETF 178 Network Slices typically requires the provision of different NRPs 179 for different industries, and some top customers can require 180 dedicated NRPs for strict service performance guarantees. 181 Considering the number of vertical industries, and the number of 182 top customers in each industry, the number of NRPs needed may be 183 in the order of 100. 185 3. With the evolution of 5G and cloud networks, IETF Network Slices 186 could be widely used by various vertical industrial customers and 187 enterprise customers who require guaranteed or predictable 188 service performance. The total amount of IETF Network Slices may 189 increase to thousands or more, although it is expected that the 190 number of IETF Network Slices would still be less than the number 191 of traditional VPN services in the network. Accordingly, the 192 number of NRPs needed may be in the order of 1000. 194 In [TS23501], the 3GPP defines a 32-bit identifier for a 5G network 195 slice with an 8-bit Slice/Service Type (SST) and a 24-bit Slice 196 Differentiator (SD). This allows mobile networks (the RAN and mobile 197 core networks) to potentially support a large number of 5G network 198 slices. It is likely that multiple 5G network slices are mapped to 199 the same IETF Network Slice, but in some cases (for example, for 200 specific SST or SD) the mapping may be closer to one-to-one, and the 201 required NRPs may increase as well. 203 Thus, there may be large numbers of IETF Network Slices in some 204 scenarios and the realization of IETF Network Slices needs to meet 205 the scalability requirements. Mapping multiple IETF Network Slices 206 to the same NRP presents a significant scaling benefit, but there can 207 still be a requirement for a large number of NRPs which presents its 208 own scalability challenges. 210 3. Network Resource Partition Scalability Considerations 212 This section analyses the scalability of NRPs in the control plane 213 and data plane to understand the possible gaps in meeting the 214 scalability requirements of IETF Network Slices. 216 3.1. Control Plane Scalability 218 The control plane for establishing and managing NRPs could be based 219 on the hybrid of a centralized controller and a distributed control 220 plane. The subsections that follow consider the scalability of these 221 two approaches: the resultant scalability of the control plane will 222 depend on how the hybrid is constructed. 224 3.1.1. Distributed Control Plane 226 It is necessary to create multiple NRPs for the delivery of IETF 227 network slice services. Each NRP can be associated with a customized 228 logical topology. The network resource attributes and the associated 229 logical topology information of each NRP may need to be exchanged 230 among the network nodes. The scalability of the distributed control 231 plane used for the distribution of NRP information needs to be 232 considered in the following aspects: 234 * The number of control protocol instances maintained on each node 236 * The number of protocol sessions maintained on each link 238 * The number of routes advertised by each node 240 * The amount of attributes associated with each route 242 * The number of route computations (i.e., SPF computation) executed 243 by each node 245 As the number of NRPs increases, it is expected that in some of the 246 above aspects, the overhead in the control plane may increase in 247 proportion to the number of the NRPs. For example, the overhead of 248 maintaining separated control protocol instances (e.g., IGP 249 instances) for different NRPs is considered higher than maintaining 250 the information of separate NRPs in the same control protocol 251 instance with appropriate separation, and the overhead of maintaining 252 separate protocol sessions for different NRPs is considered higher 253 than using a shared protocol session for the information exchange of 254 multiple NRPs. To meet the requirements of the increasing number of 255 NRPs, it is suggested to choose a control plane mechanism which could 256 improve the scalability while still provide the required 257 functionality, isolation and security for the NRPs. 259 3.1.2. Centralized Control Plane 261 By introducing a centralized network controller, the Software Defined 262 Network (SDN) approach may help to reduce the amount of computation 263 overhead in the distributed control plane, while it may also transfer 264 some of the scalability concerns from network nodes to the 265 centralized controller, thus the scalability of the controller also 266 needs to be considered. 268 To provide global optimization for the Traffic Engineered (TE) paths 269 in different NRPs, the controller needs to keep the topology and 270 resource information of all the NRPs up-to-date. And for some 271 network events such as network failure, the resulting updates to the 272 NRPs may need to be distributed to the controller in real time. To 273 achieve this, depend on the mechanisms used, the controller may need 274 to maintain a communication channel with each network node in the 275 network. When there is significant change in the network, or 276 multiple NRPs require global optimization concurrently, there may be 277 a heavy processing burden at the controller, and a heavy load in the 278 network surrounding the controller for the distribution of the 279 updated network state and the TE paths. 281 3.2. Data Plane Scalability 283 To provide different IETF Network Slice services with the required 284 SLOs and SLEs, it is necessary to allocate different subsets of 285 network resources as different NRPs to avoid or reduce the unexpected 286 interference from other services in the network. As the number of 287 NRPs increases, it is required that the underlying network can 288 provide fine-granular network resource partitioning, which means the 289 amount of state about the partitioned network resources to be 290 maintained on the network nodes will also increase. 292 In packet forwarding, IETF Network Slice service traffic needs to be 293 processed according to the topology and resource attributes of the 294 NRP it mapped to, this means that some fields in the data packet need 295 to be used to identify the NRP and its associated topology either 296 directly or implicitly. Different approaches of encapsulating the 297 NRP information in data packet can have different scalability 298 implications. 300 One practical approach is to reuse some of the existing fields in the 301 data packet to additionally identify the NRP the packet belongs to. 302 For example, the destination IP addresses or the MPLS forwarding 303 labels may be reused to further identify the NRP. This can avoid the 304 cost of introducing new fields in the data packet, while since it 305 introduces additional semantics to the existing fields, the 306 processing of the existing fields in packet forwarding may need to be 307 changed. Moreover, introducing resource semantics to existing 308 identifiers in the packet (e.g., IP addresses, MPLS forwarding 309 labels, etc.) may result in the increase of the amount of the 310 existing IDs in proportion to the number of the NRPs, which may cause 311 scalability problem in networks where a relatively large number of 312 NRPs is needed. 314 An alternative approach is to introduce a new dedicated field in the 315 data packet for identifying the NRP. This could avoid the impacts to 316 the existing fields in the packet. And if this new field carries a 317 globally-significant NRP identifier, it could be used together with 318 the existing fields to determine the packet forwarding behavior. The 319 potential issue with this approach is the difficulty in introducing a 320 new field in some of the data plane technologies. 322 In addition, the introduction of NRP specific packet forwarding has 323 an impact on the scalability of the forwarding entries on network 324 nodes, as a network node may need to maintain separate forwarding 325 entries for each NRP it participates in. 327 3.3. Gap Analysis of the Existing Mechanism 329 This section provides a gap analysis for an existing mechanism to 330 perform NRP identification in the data plane and the related 331 information distribution in the control plane. 333 One existing mechanism of building NRPs is to use resource-aware 334 Segment Identifiers (either SR-MPLS or SRv6) 335 [I-D.ietf-spring-resource-aware-segments] to identify the allocated 336 network resources in the data plane based on the mechanisms described 337 in [I-D.ietf-spring-sr-for-enhanced-vpn], and distribute the resource 338 attributes and the associated logical topology information in the 339 control plane using mechanisms based on Multi-topology 340 [I-D.ietf-lsr-isis-sr-vtn-mt] or Flex-Algo 341 [I-D.zhu-lsr-isis-sr-vtn-flexalgo]. This mechanism is suitable for 342 networks where a small number of NRPs are needed. As the number of 343 NRPs increases, there may be several scalability challenges with this 344 approach: 346 1. The number of SR SIDs needed will increase in proportion to the 347 number of NRPs in the network, which will bring challenges both 348 to the distribution of SR SIDs and the related information in the 349 control plane, and to the installation of forwarding entries for 350 resource-aware SIDs in the data plane. 352 2. As each NRP is associated with an independent logical topology or 353 algorithm, the number of route computations (e.g., SPF 354 computations) will increase in proportion to the number of NRPs 355 in the network, which may introduce significant overhead to the 356 control plane of network nodes. 358 3. The maximum number of logical topologies supported by OSPF 359 [RFC4915] is 128, the maximum number of logical topologies 360 supported by IS-IS [RFC5120] is 4096, and the maximum number of 361 Flexible Algorithms [I-D.ietf-lsr-flex-algo] is 128, which may 362 not meet the required number of NRPs in some network scenarios. 364 4. Proposed Scalability Optimizations 366 To support more IETF Network Slice services while keeping the amount 367 of network state at a reasonable scale, one basic approach is to 368 classify a set of IETF Network Slice services which have similar 369 service characteristics and performance requirements into a group, 370 and such group of IETF Network Slice services are mapped to one NRP, 371 which is allocated with an aggregated set of network resources and 372 the union of the required logical topologies to meet the service 373 requirement of the whole group of IETF Network Slice services. 374 Different groups of IETF Network Slice services can be mapped to 375 different NRPs, each is allocated with different set of network 376 resources from the underlay network. With appropriate grouping of 377 IETF Network Slice services, a reasonable number of NRPs with proper 378 network resource allocation could still meet the IETF Network Slice 379 service requirements. 381 4.1. Control Plane Optimizations 383 4.1.1. Distributed Control Plane Optimizations 385 Several optimizations can be considered to reduce the distributed 386 control plane overhead and improve its scalability. 388 The first optimization mechanism is to reduce the amount of control 389 plane sessions used for the establishment and maintenance of the 390 NRPs. For multiple NRPs which have the same connection relationship 391 between two adjacent network nodes, it is proposed that one single 392 control protocol session is used for each such group of NRPs. The 393 information of different NRPs can be exchanged over the same session, 394 with necessary identification information to distinguish the NRPs in 395 the control message. This could reduce the overhead of maintaining a 396 large number of separate control protocol sessions for each NRP, and 397 could also reduce the amount of control plane messages flooded in the 398 network. 400 The second optimization mechanism is to decouple the NRP information 401 from the associated logical topology information in the control 402 plane, so that the resource attributes and the topology attributes 403 can be advertised and processed separately. In a network, it is 404 possible that multiple NRPs are associated with the same logical 405 topology, or multiple NRPs may share the same set of network 406 resources on a subset of network nodes and links. For the topology 407 sharing case, it is more efficient if only one copy of the topology 408 information is advertised, and multiple NRPs sharing the same 409 topology could simply refer to this topology information. More 410 importantly, with this approach, the result of topology-based route 411 computation could be shared by multiple NRPs, so that the overhead of 412 per NRP route computation could be avoided. Similarly, for the 413 resource sharing case, information of a subset of network resources 414 reserved on a particular network node or link could be advertised 415 once and then be referred to by multiple NRPs which share the same 416 set of resources. 418 # O #### O #### O * O **** O **** O 419 # # # # * * * * 420 O # # # O * * * 421 # # # # * * * * 422 # O #### O #### O * O **** O **** O 424 NRP-1 NRP-2 425 ^^ ^^ 426 || O-----O-----O || 427 <<<< / | \ / | | >>>> 428 O | X | | 429 \ | / \ | | 430 O-----O-----O 432 Underlay Network Topology 434 Legend 436 O Virtual node 437 ### Virtual links with a set of reserved resources 438 *** Virtual links with another set of reserved resources 440 Figure 1. Topology Sharing between NRPs 442 Figure 2 gives an example of two NRPs which share the same logical 443 topology. As shown in the figure, NRP-1 and NRP-2 are associated 444 with the same topology, while the resource attributes of each NRP are 445 different. In this case, the information of the shared network 446 topology can be advertised using either MT or Flex-Algo, then the two 447 NRPs can be associated with the same MT or Flex-Algo, and the 448 topology-based route computation result can be shared by the two NRPs 449 to generate the corresponding routing and forwarding entries. 451 # O #### O #### O * O ***** O #### O 452 # # # # * * * # # 453 O # # # O * # # 454 # # # # * * * # # 455 # O #### O #### O * O ***** O #### O 457 NRP-1 NRP-2 458 ^^ ^^ 459 || O-----O-----O || 460 <<<< / | \ / | | >>>> 461 O | X | | 462 \ | / \ | | 463 O-----O-----O 465 Underlay Network Topology 467 Legend 469 O Virtual node 470 ### Virtual links with a set of reserved resource 471 *** Virtual links with another set of reserved resource 473 Figure 2. Resource Sharing between NRPs 475 Figure 3 gives another example of two NRPs which have different 476 logical topologies, while share the same set of network resources on 477 a subset of the links. In this case, the information about the 478 shared resources allocated on the links only needs to be advertised 479 once, then both NRP-1 and NRP-2 could refer to the common set of 480 reserved link resource for constraint based path computation. 482 4.1.2. Centralized Control Plane Optimization 484 For the optimization of the centralized control plane, it is 485 suggested that the centralized controller is used as a complementary 486 mechanism to the distributed control plane rather than a replacement, 487 so that the workload for NRP specific path computation in control 488 plane could be shared by both the centralized controller and the 489 network nodes, and the scalability of both systems could be improved. 490 In addition, the centralized controller may be realized with multiple 491 network entities, each is responsible for one subset or region of the 492 network. This is the typical approach for scale out of the 493 centralized control plane. 495 4.2. Data Plane Optimizations 497 One optimization in the data plane is to decouple the identifiers 498 used for topology-based forwarding and the identifier used for the 499 resource-specific processing introduced by NRP. One possible 500 mechanism is to introduce a dedicated network wide NRP Identifier 501 (NRP-ID) in the packet header to uniquely identify the set of local 502 network resources allocated to a NRP on each involved network node 503 and link for the processing and forwarding of the received packets. 504 Then the existing identifiers in the packet header used for topology 505 based forwarding (e.g., the destination IP address, MPLS forwarding 506 labels) are kept unchanged. The benefit is the amount of the 507 existing topology-specific identifiers will not be impacted by the 508 increasing number of NRPs. Since this new NRP-ID field will be used 509 together with other existing fields to determine the packet 510 forwarding behavior, this may require network nodes to support a 511 hierarchical forwarding table in data plane. Figure 4 shows the 512 concept of using different data plane identifiers for topology- 513 specific and resource-specific packet forwarding and processing 514 respectively. 516 +--------------------------+ 517 | Packet Header | 518 | | 519 | +----------------------+ | 520 | | Topology-specific IDs| | 521 | +----------------------+ | 522 | | 523 | +----------------------+ | 524 | | Global NRP-ID | | 525 | +----------------------+ | 526 +--------------------------+ 528 Figure 3. Decoupled Topology and Resource Identifiers in data packet 530 In an IPv6 [RFC8200] based network, this could be achieved by 531 introducing a dedicated field in either the IPv6 fixed header or the 532 extension headers to carry the NRP-ID for the resource-specific 533 forwarding, while keeping the destination IP address field used for 534 routing towards the destination prefix in the corresponding topology. 535 Note that the NRP-ID needs to be parsed by every node along the path 536 which is capable of NRP aware forwarding. 537 [I-D.ietf-6man-enhanced-vpn-vtn-id] introduces the mechanism of 538 carrying the VTN resource ID (which is equivalent to NRP-ID in the 539 context of network slicing) in IPv6 Hop-by-Hop extension header. 541 In an MPLS [RFC3032] based network, this may be achieved by 542 introducing a dedicated NRP-ID either in the MPLS label stack or 543 following the MPLS label stack. This way, the existing MPLS 544 forwarding labels are used for topology-specific packet forwarding 545 towards the destination node, and the NRP-ID is used to determine the 546 set of network resources for packet processing. This requires that 547 both the forwarding label and the NRP-ID be parsed by nodes along the 548 forwarding path of the packet, and the forwarding behavior may depend 549 on the position of the NRP-ID in the packet. The detailed extensions 550 to MPLS data plane are under discussion as part of the work in MPLS 551 Open Design Team and is out of the scope of this document. 553 5. Solution Evolution for Improved Scalability 555 Based on the analysis in this document, the control plane and data 556 plane for NRP need to evolve to support the increasing number of IETF 557 Network Slice services and the increasing number of NRPs in the 558 network. This section describes the possible solution evolution 559 taking the SR based NRP solutions as an example, while the analysis 560 and optimization in this document are generic and not specific to SR. 562 At the first step, by introducing resource-awareness to SR SIDs 563 [I-D.ietf-spring-resource-aware-segments], and using Multi-Topology 564 or Flex-Algo as the control plane mechanism to define the logical 565 topology of the NRP, it could provide a solution for building a 566 limited number of NRPs in the network, and can meet the requirements 567 of a relatively small number of IETF Network Slice services. This 568 mechanism is called the basic SR based NRP. 570 As the required number of IETF Network Slice services increases, more 571 NRPs may be needed, then the control plane scalability could be 572 improved by decoupling the topology attribute from the resource 573 attribute, so that multiple NRPs could share the same topology or 574 resource attribute to reduce the control plane and data plane 575 overhead. The data plane can still be based on the resource-aware 576 SIDs. This mechanism is called the scalable SR based NRP. Both the 577 basic and the scalable SR based NRP mechanisms are described in 578 [I-D.ietf-spring-sr-for-enhanced-vpn]. 580 When the data plane scalability becomes a concern, a dedicated NRP-ID 581 can be introduced in the data packet to decouple the resource- 582 specific identifiers from the topology-specific identifiers in the 583 data plane, this could help to reduce the number of IP addresses or 584 SR SIDs needed to support a large number of NRPs. This mechanism is 585 called the NRP-ID based mechanism. 587 6. Operational Considerations 589 The instantiation of NRP requires to perform NRP specific 590 configurations on the involved network nodes and links. There can 591 also be the cases in which the topology or the set of network 592 resources allocated to a existing NRP needs to be modified. With the 593 number of NRPs increases, the amount of configurations for NRP 594 instantiation and modification will increase accordingly. 596 For the management and operation of NRPs and the optimization of 597 paths within the NRPs, the status of NRPs needs to be monitored and 598 reported to the network controller. The increasing number of NRPs 599 would require additional NRP status information to be monitored and 600 reported. 602 The configuration and operation of NRP could be achieved using 603 mechanisms such as Netconf/YANG, the details are out of the scope of 604 this document. 606 7. Security Considerations 608 This document describes the scalability considerations for the 609 network control plane and data plane of NRPs in the realization of 610 IETF Network Slice services, and proposes some mechanisms for 611 scalability optimization. As the number of NRPs supported in the 612 data plane and control plane of the network can be limited, this may 613 be exploited as an attack vector by requesting a large number of 614 network slices, which then result in the creation of a large number 615 of NRPs. 617 One protection against this is to improve the scalability of the 618 system to support more NRPs. Another possible solution is to make 619 the network slice controller aware of the scaling constraints of the 620 system and dampen the arrival rate of new network slices and NRPs 621 request, and raise alarms when the thresholds are crossed. 623 The security considerations in [I-D.ietf-teas-ietf-network-slices] 624 and [I-D.ietf-teas-enhanced-vpn] also apply to this document. 626 8. IANA Considerations 628 This document makes no request of IANA. 630 9. Contributors 631 Zhibo Hu 632 Email: huzhibo@huawei.com 634 Hongjie Yang 635 Email: hongjie.yang@huawei.com 637 10. Acknowledgments 639 The authors would like to thank Adrian Farrel, Dhruv Dhody, Donald 640 Eastlake and Kenichi Ogaki for their review and valuable comments to 641 this document. 643 11. References 645 11.1. Normative References 647 [I-D.ietf-teas-enhanced-vpn] 648 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 649 Framework for Enhanced Virtual Private Network (VPN+) 650 Services", Work in Progress, Internet-Draft, draft-ietf- 651 teas-enhanced-vpn-10, 6 March 2022, 652 . 655 [I-D.ietf-teas-ietf-network-slices] 656 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 657 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 658 Network Slices", Work in Progress, Internet-Draft, draft- 659 ietf-teas-ietf-network-slices-10, 27 March 2022, 660 . 663 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 664 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 665 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 666 . 668 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 669 (IPv6) Specification", STD 86, RFC 8200, 670 DOI 10.17487/RFC8200, July 2017, 671 . 673 11.2. Informative References 675 [I-D.ietf-6man-enhanced-vpn-vtn-id] 676 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 677 "Carrying Virtual Transport Network (VTN) Identifier in 678 IPv6 Extension Header", Work in Progress, Internet-Draft, 679 draft-ietf-6man-enhanced-vpn-vtn-id-00, 5 March 2022, 680 . 683 [I-D.ietf-lsr-flex-algo] 684 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 685 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 686 Internet-Draft, draft-ietf-lsr-flex-algo-19, 7 April 2022, 687 . 690 [I-D.ietf-lsr-isis-sr-vtn-mt] 691 Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi- 692 Topology (MT) for Segment Routing based Virtual Transport 693 Network", Work in Progress, Internet-Draft, draft-ietf- 694 lsr-isis-sr-vtn-mt-02, 13 January 2022, 695 . 698 [I-D.ietf-spring-resource-aware-segments] 699 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 700 Z., and F. Clad, "Introducing Resource Awareness to SR 701 Segments", Work in Progress, Internet-Draft, draft-ietf- 702 spring-resource-aware-segments-04, 5 March 2022, 703 . 706 [I-D.ietf-spring-sr-for-enhanced-vpn] 707 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 708 Z., and F. Clad, "Segment Routing based Virtual Transport 709 Network (VTN) for Enhanced VPN", Work in Progress, 710 Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-02, 711 5 March 2022, . 714 [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 715 Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment 716 Routing based VTN", Work in Progress, Internet-Draft, 717 draft-zhu-lsr-isis-sr-vtn-flexalgo-04, 6 March 2022, 718 . 721 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 722 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 723 RFC 4915, DOI 10.17487/RFC4915, June 2007, 724 . 726 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 727 Topology (MT) Routing in Intermediate System to 728 Intermediate Systems (IS-ISs)", RFC 5120, 729 DOI 10.17487/RFC5120, February 2008, 730 . 732 [TS23501] "3GPP TS23.501", 2016, 733 . 736 Authors' Addresses 738 Jie Dong 739 Huawei Technologies 740 Huawei Campus, No. 156 Beiqing Road 741 Beijing 742 100095 743 China 744 Email: jie.dong@huawei.com 746 Zhenbin Li 747 Huawei Technologies 748 Huawei Campus, No. 156 Beiqing Road 749 Beijing 750 100095 751 China 752 Email: lizhenbin@huawei.com 754 Liyan Gong 755 China Mobile 756 No. 32 Xuanwumenxi Ave., Xicheng District 757 Beijing 758 China 759 Email: gongliyan@chinamobile.com 761 Guangming Yang 762 China Telecom 763 No.109 West Zhongshan Ave., Tianhe District 764 Guangzhou 765 China 766 Email: yangguangm@chinatelecom.cn 767 James N Guichard 768 Futurewei Technologies 769 2330 Central Express Way 770 Santa Clara, 771 United States of America 772 Email: james.n.guichard@futurewei.com 774 Gyan Mishra 775 Verizon Inc. 776 Email: gyan.s.mishra@verizon.com 778 Fengwei Qin 779 China Mobile 780 No. 32 Xuanwumenxi Ave., Xicheng District 781 Beijing 782 China 783 Email: qinfengwei@chinamobile.com 785 Tarek Saad 786 Juniper Networks 787 Email: tsaad@juniper.net 789 Vishnu Pavan Beeram 790 Juniper Networks 791 Email: vbeeram@juniper.net