idnits 2.17.00 (12 Aug 2021) /tmp/idnits14810/draft-dong-teas-nrp-scalability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 February 2022) is 96 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: 'RFC5120' is defined on line 684, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-teas-enhanced-vpn-09 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-05 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-04) exists of draft-ietf-spring-resource-aware-segments-03 == Outdated reference: A later version (-02) exists of draft-ietf-spring-sr-for-enhanced-vpn-01 == Outdated reference: A later version (-04) exists of draft-zhu-lsr-isis-sr-vtn-flexalgo-03 Summary: 0 errors (**), 0 flaws (~~), 7 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: 11 August 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 7 February 2022 20 Scalability Considerations for Network Resource Partition 21 draft-dong-teas-nrp-scalability-01 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 11 August 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 . . . . . . . . . . . . . . . . . 6 82 3.3. Gap Analysis of the Existing Mechanism . . . . . . . . . 7 83 4. Proposed Scalability Optimizations . . . . . . . . . . . . . 8 84 4.1. Control Plane Optimizations . . . . . . . . . . . . . . . 8 85 4.1.1. Distributed Control Plane Optimizations . . . . . . . 8 86 4.1.2. Centralized Control Plane Optimization . . . . . . . 10 87 4.2. Data Plane Optimizations . . . . . . . . . . . . . . . . 10 88 5. Solution Evolution for Improved Scalability . . . . . . . . . 12 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 95 10.2. Informative References . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 98 1. Introduction 100 The IETF Network Slice service aims to meet the connectivity demands 101 of a network slice customer with specific Service Level Objectives 102 (SLOs) and Service Level Expectations (SLEs) over a common underlay 103 network. [I-D.ietf-teas-ietf-network-slices] defines the 104 terminologies and the characteristics of IETF Network Slices. It 105 also discusses the general framework, the components and interfaces 106 for requesting and operating IETF Network Slices. For the 107 realization of IETF Network Slice services, a concept called Network 108 Resource Partition (NRP) is introduced, which refers to a set of 109 network resources that are available in the underlay network to 110 ensure the requested SLOs and SLEs of IETF Network Slices can be met. 112 [I-D.ietf-teas-enhanced-vpn] describes the layered framework and 113 candidate technologies for delivering enhanced VPN (VPN+) services. 114 VPN+ aims to meet the needs of customers or applications, including 115 the applications that are associated with 5G, which require 116 connectivity services with advanced characteristics, such as the 117 assurance of Service Level Objectives (SLOs) and specific Service 118 Level Expectations (SLEs). VPN+ services can be delivered by mapping 119 one or a group of overlay VPNs to a virtual underlay network built 120 with a set of network resources. The VPN+ framework and technologies 121 could be used for the realization of IETF Network Slice services. 122 NRP could be used as the underlay network construct to support the 123 VPN+ services. 125 As the demand for IETF Network Slice services increases, scalability 126 would become an important factor for the large scale deployment of 127 IETF Network Slices. Although the scalability of IETF Network Slices 128 can be improved by mapping a group of IETF Network Slices to one NRP, 129 there are concerns about the scalability of NRPs. This document 130 describes the scalability considerations about NRPs in the network 131 control plane and data plane, and some optimization mechanisms are 132 proposed. 134 2. Network Resource Partition Scalability Requirements 136 As described in [I-D.ietf-teas-ietf-network-slices], IETF Network 137 Slices may be grouped together according to characteristics 138 (including SLOs and SLEs). This grouping allows an operator to host 139 a number of slices on a particular set of resources to reduce the 140 amount of state information needed in the network. This can help to 141 avoid the maintenance of per IETF Network Slice state in the underlay 142 network. 144 With the development and evolution of 5G and other services, it is 145 expected that an increasing number of IETF Network Slices will be 146 deployed. The number of network slices required depends on how IETF 147 Network Slices will be used, and the progress of network slicing for 148 the vertical industrial services. The potential number of IETF 149 Network Slice services and NRPs is analyzed by classifying the 150 network slice deployment into three typical scenarios: 152 1. IETF Network Slices can be used by a network operator for 153 different types of service. For example, in a converged multi- 154 service network, different IETF Network Slices can be created to 155 carry mobile transport services, fixed broadband services 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 services may also be deployed in 159 a dedicated NRP. In this case, a separate NRP may need to be 160 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 NRP may 163 also be needed for each wholesale service customer. In this 164 scenario, the number of NRPs 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 of industrial 170 verticals, where the assurance of SLOs and the fulfilment of SLEs 171 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 the provision of different NRPs 177 for different industries, and some top customers can require 178 dedicated NRPs for strict service performance guarantees. 179 Considering the number of vertical industries, and the number of 180 top customers in each industry, the number of NRPs needed may be 181 in the order of 100. 183 3. With the evolution of 5G and cloud networks, IETF Network Slices 184 could be widely used by various vertical industrial customers and 185 enterprise customers who require guaranteed or predictable 186 service performance. The total amount of IETF Network Slices may 187 increase to thousands or more, although it is expected that the 188 number of IETF Network Slices would still be less than the number 189 of traditional VPN services in the network. Accordingly, the 190 number of NRPs needed may be in the order of 1000. 192 In [TS23501], the 3GPP defines a 32-bit identifier for a 5G network 193 slice with an 8-bit Slice/Service Type (SST) and a 24-bit Slice 194 Differentiator (SD). This allows mobile networks (the RAN and mobile 195 core networks) to potentially support a large number of 5G network 196 slices. It is likely that multiple 5G network slices are mapped to 197 the same IETF Network Slice, but in some cases (for example, for 198 specific SST or SD) the mapping may be closer to one-to-one, and the 199 required NRPs may increase as well. 201 Thus, there may be large numbers of IETF Network Slices in some 202 scenarios and the realization of IETF Network Slices needs to meet 203 the scalability requirements. Mapping multiple IETF Network Slices 204 to the same NRP presents a significant scaling benefit, but there can 205 still be a requirement for a large number of NRPs which presents its 206 own scalability challenges. 208 3. Network Resource Partition Scalability Considerations 210 This section analyses the scalability of NRPs in the control plane 211 and data plane to understand the possible gaps in meeting the 212 scalability requirements of IETF Network Slices. 214 3.1. Control Plane Scalability 216 The control plane for establishing and managing NRPs could be based 217 on the hybrid of a centralized controller and a distributed control 218 plane. The subsections that follow consider the scalability of these 219 two approaches: the resultant scalability of the control plane will 220 depend on how the hybrid is constructed. 222 3.1.1. Distributed Control Plane 224 It is necessary to create multiple NRPs for the delivery of IETF 225 network slice services. Each NRP can be associated with a customized 226 logical topology. The network resource attributes and the associated 227 logical topology information of each NRP may need to be exchanged 228 among the network nodes. The scalability of the distributed control 229 plane used for the distribution of NRP information needs to be 230 considered in the following aspects: 232 * The number of control protocol instances maintained on each node 234 * The number of protocol sessions maintained on each link 236 * The number of routes advertised by each node 238 * The amount of attributes associated with each route 239 * The number of route computations (i.e., SPF computation) executed 240 by each node 242 As the number of NRPs increases, it is expected that in some of the 243 above aspects, the overhead in the control plane may increase in 244 proportion to the number of the NRPs. For example, the overhead of 245 maintaining separated control protocol instances (e.g., IGP 246 instances) for different NRPs is considered higher than maintaining 247 the information of separate NRPs in the same control protocol 248 instance with appropriate separation, and the overhead of maintaining 249 separate protocol sessions for different NRPs is considered higher 250 than using a shared protocol session for the information exchange of 251 multiple NRPs. To meet the requirements of the increasing number of 252 NRPs, it is suggested to choose a control plane mechanism which could 253 improve the scalability while still provide the required 254 functionality. 256 3.1.2. Centralized Control Plane 258 By introducing a centralized network controller, the Software Defined 259 Network (SDN) approach may help to reduce the amount of computation 260 overhead in the distributed control plane, while it may also transfer 261 some of the scalability concerns from network nodes to the 262 centralized controller, thus the scalability of the controller also 263 needs to be considered. 265 To provide global optimization for the Traffic Engineered (TE) paths 266 in different NRPs, the controller needs to keep the topology and 267 resource information of all the NRPs up-to-date. To achieve this, 268 the controller may need to maintain a communication channel with each 269 network node in the network. When there is significant change in the 270 network, or multiple NRPs require global optimization concurrently, 271 there may be a heavy processing burden at the controller, and a heavy 272 load in the network surrounding the controller for the distribution 273 of the updated network state and the TE paths. 275 3.2. Data Plane Scalability 277 To provide different IETF Network Slice services with the required 278 SLOs and SLEs, it is necessary to allocate different subsets of 279 network resources as different NRPs to avoid or reduce the unexpected 280 interference from other services in the network. As the number of 281 NRPs increases, it is required that the underlying network can 282 provide fine-granular network resource partitioning, which means the 283 amount of state about the partitioned network resources to be 284 maintained on the network nodes will also increase. 286 In packet forwarding, IETF Network Slice service traffic needs to be 287 processed according to the topology and resource attributes of the 288 NRP it is mapped to, this means that some fields in the data packet 289 need to be used to identify the NRP and its associated topology 290 either directly or implicitly. Different approaches of encapsulating 291 the NRP information in data packet can have different scalability 292 implications. 294 One practical approach is to reuse some of the existing fields in the 295 data packet to additionally identify the NRP the packet belongs to. 296 For example, the destination IP addresses or the MPLS forwarding 297 labels may be reused to further identify the NRP. This can avoid the 298 cost of introducing new fields in the data packet, while since it 299 introduces additional semantics to the existing fields, the 300 processing of the existing fields in packet forwarding may need to be 301 changed. Moreover, introducing resource semantics to existing 302 identifiers in the packet (e.g., IP addresses, MPLS forwarding 303 labels, etc.) may result in the increase of the amount of the 304 existing IDs in proportion to the number of the NRPs, which may cause 305 scalability problem in networks where a relatively large number of 306 NRPs is needed. 308 An alternative approach is to introduce a new dedicated field in the 309 data packet for identifying the NRP. This could avoid the impacts to 310 the existing fields in the packet. And if this new field carries a 311 globally-significant identifier of the NRP, it could be used together 312 with the existing fields to determine the packet forwarding behavior. 313 The potential issue with this approach is the difficulty in 314 introducing a new field in some of the data plane technologies. 316 In addition, the introduction of NRP specific packet forwarding has 317 an impact on the scalability of the forwarding entries on network 318 nodes, as a network node may need to maintain separate forwarding 319 entries for each NRP it participates in. 321 3.3. Gap Analysis of the Existing Mechanism 323 This section provides a gap analysis for an existing mechanism to 324 perform NRP identification in the data plane and the related 325 information distribution in the control plane. 327 One existing mechanism of building NRPs is to use resource-aware 328 Segment Identifiers (either SR-MPLS or SRv6) 329 [I-D.ietf-spring-resource-aware-segments] to identify the allocated 330 network resources in the data plane based on the mechanisms described 331 in [I-D.ietf-spring-sr-for-enhanced-vpn], and distribute the resource 332 attributes and the associated logical topology information in the 333 control plane using mechanisms based on Multi-topology 335 [I-D.ietf-lsr-isis-sr-vtn-mt] or Flex-Algo 336 [I-D.zhu-lsr-isis-sr-vtn-flexalgo]. This mechanism is suitable for 337 networks where a small number of NRPs are needed. As the number of 338 NRPs increases, there may be several scalability challenges with this 339 approach: 341 1. The number of SR SIDs needed will increase in proportion to the 342 number of NRPs in the network, which will bring challenges both 343 to the distribution of SR SIDs and the related information in the 344 control plane, and to the installation of forwarding entries for 345 resource-aware SIDs in the data plane. 347 2. As each NRP is associated with an independent logical topology or 348 algorithm, the number of route computations (e.g., SPF 349 computations) will increase in proportion to the number of NRPs 350 in the network, which may introduce significant overhead to the 351 control plane of network nodes. 353 3. The maximum number of logical topologies supported by OSPF 354 [RFC4915] is 128, and the maximum number of Flexible Algorithms 355 [I-D.ietf-lsr-flex-algo] is 128, which may not meet the required 356 number of NRPs in some network scenarios. 358 4. Proposed Scalability Optimizations 360 4.1. Control Plane Optimizations 362 4.1.1. Distributed Control Plane Optimizations 364 Several optimizations can be considered to reduce the distributed 365 control plane overhead and improve its scalability. 367 The first optimization mechanism is to reduce the amount of control 368 plane sessions used for the establishment and maintenance of the 369 NRPs. For multiple NRPs which have the same connection relationship 370 between two adjacent network nodes, it is proposed that one single 371 control protocol session is used for each such group of NRPs. The 372 information of different NRPs can be exchanged over the same session, 373 with necessary identification information to distinguish the NRPs in 374 the control message. This could reduce the overhead of maintaining a 375 large number of separate control protocol sessions for each NRP, and 376 could also reduce the amount of control plane messages flooded in the 377 network. 379 The second optimization mechanism is to decouple the NRP information 380 from the associated logical topology information in the control 381 plane, so that the resource attributes and the topology attributes 382 can be advertised and processed separately. In a network, it is 383 possible that multiple NRPs associate with the same logical topology, 384 and multiple NRPs may share the same set of network resources on a 385 subset of network nodes and links. Then it is more efficient if only 386 one copy of the topology information is advertised, and multiple NRPs 387 sharing the same topology could refer to this topology information. 388 More importantly, with this approach, the result of topology-based 389 route computation could be shared by multiple NRPs, so that the 390 overhead of per NRP route computation could be avoided. Similarly, 391 information of a subset of network resources reserved on a particular 392 network node or link could be advertised once and may be referred to 393 by multiple NRPs which share the same set of resources. 395 O#####O#####O O*****O*****O 396 # # # * * * 397 # # # * * * 398 O#####O#####O O*****O*****O 400 NRP-1 NRP-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 1. Topology Sharing between NRPs 417 Figure 1 gives an example of two NRPs which share the same logical 418 topology. As shown in the figure, NRP-1 and NRP-2 are associated 419 with the same topology, while the resource attributes of each NRP are 420 different. In this case, only one copy of the network topology 421 information needs to be advertised, and the topology-based route 422 computation result can be shared by the two NRPs to generate the 423 corresponding routing and forwarding tables. 425 O#####O#####O O----O#####O 426 # # # \/ # # 427 # # # /\ # # 428 O#####O#####O O----O#####O 430 NRP-1 NRP-2 432 Legend 434 O Virtual node 435 ### Virtual links with a set of reserved resource 436 --- Virtual links with another set of reserved resource 438 Figure 2. Resource Sharing between NRPs 440 Figure 2 gives another example of two NRPs which share the same set 441 of network resources on some of the links. In this case, information 442 about the resources allocated on each link only needs to be 443 advertised once, then both NRP-1 and NRP-2 could refer to the 444 reserved link resource for constraint based path computation. 446 4.1.2. Centralized Control Plane Optimization 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 NRP 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. 454 In addition, the centralized controller may be realized with multiple 455 network entities, each is responsible for one subset or region of the 456 network. This is the typical approach for scale out of the 457 centralized control plane. 459 4.2. Data Plane Optimizations 461 To support more IETF Network Slice services while keeping the amount 462 of data plane state at a reasonable scale, one typical approach is to 463 classify a set of IETF Network Slice services which have similar 464 service characteristics and performance requirements into a group, 465 and such groups of IETF Network Slice services are mapped to one NRP, 466 which is allocated with an aggregated set of network resources and 467 the union of the required logical topologies to meet the service 468 requirement of the whole group of IETF Network Slice services. 469 Different groups of IETF Network Slice services can be mapped to 470 different NRPs with different set of network resources allocated from 471 the underlay network. With appropriate grouping of IETF Network 472 Slice services, a reasonable number of NRPs with network resources 473 reservation and aggregation could still meet the IETF Network Slice 474 service requirements. 476 Another optimization in the data plane is to decouple the identifiers 477 used for topology-based forwarding and the identifier used for the 478 resource-specific processing introduced by NRP. One possible 479 mechanism is to introduce a dedicated network-wide NRP Identifier 480 (NRP-ID) in the packet header to uniquely identify the set of network 481 resources allocated to a NRP on each involved network node and link 482 for the processing and forwarding of the data packets mapped to the 483 NRP. Then the existing identifiers in the packet header used for 484 topology based forwarding (e.g., the destination IP address, MPLS 485 forwarding labels) are kept unchanged. The benefit is the amount of 486 the existing topology-specific identifiers will not be impacted by 487 the increasing number of NRPs. Since this new global NRP-ID field 488 will be used together with other existing fields to determine the 489 packet forwarding behavior, this may require network nodes to support 490 a hierarchical forwarding table in data plane. Figure 3 shows the 491 concept of using different data plane identifiers for topology- 492 specific and resource-specific packet forwarding and processing 493 respectively. 495 +--------------------------+ 496 | Packet Header | 497 | | 498 | +----------------------+ | 499 | | Topology-specific IDs| | 500 | +----------------------+ | 501 | | 502 | +----------------------+ | 503 | | Global NRP-ID | | 504 | +----------------------+ | 505 +--------------------------+ 507 Figure 3. Decoupled Topology and Resource Identifiers in data packet 509 In an IPv6 [RFC8200] based network, this could be achieved by 510 introducing a dedicated field in either the IPv6 fixed header or the 511 extension headers to carry the NRP-ID for the resource-specific 512 forwarding, while keeping the destination IP address field used for 513 routing towards the destination prefix in the corresponding topology. 514 Note that the NRP-ID needs to be parsed by every node along the path 515 which is capable of NRP aware forwarding. 516 [I-D.dong-6man-enhanced-vpn-vtn-id] introduces the mechanism of 517 carrying the VTN resource ID (which is equivalent to NRP-ID in the 518 context of network slicing) in IPv6 Hop-by-Hop extension header. 520 In an MPLS [RFC3032] based network, this may be achieved by 521 introducing a dedicated NRP-ID either in the MPLS label stack or 522 following the MPLS label stack. This way, the existing MPLS 523 forwarding labels are used for topology-specific packet forwarding 524 towards the destination node, and the NRP-ID is used to determine the 525 set of network resources for packet processing. This requires that 526 both the forwarding label and the NRP-ID be parsed by nodes along the 527 forwarding path of the packet, and the forwarding behavior may depend 528 on the position of the NRP-ID in the packet. The detailed extensions 529 to MPLS data plane are under discussion as part of the work in MPLS 530 Open Design Team and is out of the scope of this document. 532 5. Solution Evolution for Improved Scalability 534 Based on the analysis in this document, the control plane and data 535 plane for NRP need to evolve to support the increasing number of IETF 536 Network Slice services and the increasing number of NRPs in the 537 network. 539 At the first step, by introducing resource-awareness to segment 540 routing SIDs [I-D.ietf-spring-resource-aware-segments], and using 541 Multi-Topology or Flex-Algo as the control plane mechanism to define 542 the logical topology, it could provide a solution for building a 543 limited number of NRPs in the network, and can meet the requirements 544 of a relatively small number of IETF Network Slice services. This 545 mechanism is called the basic SR based NRP. 547 As the required number of IETF Network Slice services increases, more 548 NRPs may be needed, then the control plane scalability could be 549 improved by decoupling the topology attribute from the resource 550 attribute, so that multiple NRPs could share the same topology or 551 resource attribute to reduce the control plane and data plane 552 overhead. The data plane can still be based on the resource-aware 553 SIDs. This mechanism is called the scalable SR based NRP. Both the 554 basic and the scalable SR based NRP mechanisms are described in 555 [I-D.ietf-spring-sr-for-enhanced-vpn]. 557 When the data plane scalability becomes a concern, a dedicated NRP-ID 558 can be introduced in the data packet to decouple the resource- 559 specific identifiers from the topology-specific identifiers in the 560 data plane, this could help to reduce the number of IP addresses or 561 SR SIDs needed to support a large number of NRPs. This mechanism is 562 called the NRP-ID based mechanism. 564 6. Security Considerations 566 This document describes the scalability considerations about the 567 network control plane and data plane of NRPs in the realization of 568 IETF Network Slice services, and proposes the mechanisms for 569 scalability optimization. As the number of NRPs supported in the 570 data plane and control plane of the network can be limited, this may 571 be exploited as an attack vector by requesting a large number of 572 network slices, which then result in the creation of a large number 573 of NRPs. 575 One protection against this is to improve the scalability of the 576 system to support more NRPs. Another possible solution is to make 577 the network slice controller aware of the scaling constraints of the 578 system and dampen the arrival rate of new network slices and NRPs 579 request, and raise alarms when the thresholds are crossed. 581 The security considerations in [I-D.ietf-teas-ietf-network-slices] 582 and [I-D.ietf-teas-enhanced-vpn] also apply to this document. 584 7. IANA Considerations 586 This document makes no request of IANA. 588 8. Contributors 590 Zhibo Hu 591 Email: huzhibo@huawei.com 593 Hongjie Yang 594 Email: hongjie.yang@huawei.com 596 9. Acknowledgments 598 The authors would like to thank Adrian Farrel for the review and 599 discussion of this document. 601 10. References 603 10.1. Normative References 605 [I-D.ietf-teas-enhanced-vpn] 606 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 607 Framework for Enhanced Virtual Private Network (VPN+) 608 Services", Work in Progress, Internet-Draft, draft-ietf- 609 teas-enhanced-vpn-09, 25 October 2021, 610 . 613 [I-D.ietf-teas-ietf-network-slices] 614 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 615 Makhijani, K., Contreras, L. M., and J. Tantsura, 616 "Framework for IETF Network Slices", Work in Progress, 617 Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 618 October 2021, . 621 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 622 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 623 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 624 . 626 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 627 (IPv6) Specification", STD 86, RFC 8200, 628 DOI 10.17487/RFC8200, July 2017, 629 . 631 10.2. Informative References 633 [I-D.dong-6man-enhanced-vpn-vtn-id] 634 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 635 "Carrying Virtual Transport Network (VTN) Identifier in 636 IPv6 Extension Header", Work in Progress, Internet-Draft, 637 draft-dong-6man-enhanced-vpn-vtn-id-06, 24 October 2021, 638 . 641 [I-D.ietf-lsr-flex-algo] 642 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 643 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 644 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 645 2021, . 648 [I-D.ietf-lsr-isis-sr-vtn-mt] 649 Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi- 650 Topology (MT) for Segment Routing based Virtual Transport 651 Network", Work in Progress, Internet-Draft, draft-ietf- 652 lsr-isis-sr-vtn-mt-02, 13 January 2022, 653 . 656 [I-D.ietf-spring-resource-aware-segments] 657 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 658 Z., and F. Clad, "Introducing Resource Awareness to SR 659 Segments", Work in Progress, Internet-Draft, draft-ietf- 660 spring-resource-aware-segments-03, 12 July 2021, 661 . 664 [I-D.ietf-spring-sr-for-enhanced-vpn] 665 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 666 Z., and F. Clad, "Segment Routing based Virtual Transport 667 Network (VTN) for Enhanced VPN", Work in Progress, 668 Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01, 669 12 July 2021, . 672 [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 673 Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment 674 Routing based VTN", Work in Progress, Internet-Draft, 675 draft-zhu-lsr-isis-sr-vtn-flexalgo-03, 11 July 2021, 676 . 679 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 680 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 681 RFC 4915, DOI 10.17487/RFC4915, June 2007, 682 . 684 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 685 Topology (MT) Routing in Intermediate System to 686 Intermediate Systems (IS-ISs)", RFC 5120, 687 DOI 10.17487/RFC5120, February 2008, 688 . 690 [TS23501] "3GPP TS23.501", 2016, 691 . 694 Authors' Addresses 696 Jie Dong 697 Huawei Technologies 698 Huawei Campus, No. 156 Beiqing Road 699 Beijing 700 100095 701 China 703 Email: jie.dong@huawei.com 704 Zhenbin Li 705 Huawei Technologies 706 Huawei Campus, No. 156 Beiqing Road 707 Beijing 708 100095 709 China 711 Email: lizhenbin@huawei.com 713 Liyan Gong 714 China Mobile 715 No. 32 Xuanwumenxi Ave., Xicheng District 716 Beijing 717 China 719 Email: gongliyan@chinamobile.com 721 Guangming Yang 722 China Telecom 723 No.109 West Zhongshan Ave., Tianhe District 724 Guangzhou 725 China 727 Email: yangguangm@chinatelecom.cn 729 James N Guichard 730 Futurewei Technologies 731 2330 Central Express Way 732 Santa Clara, 733 United States of America 735 Email: james.n.guichard@futurewei.com 737 Gyan Mishra 738 Verizon Inc. 740 Email: gyan.s.mishra@verizon.com 741 Fengwei Qin 742 China Mobile 743 No. 32 Xuanwumenxi Ave., Xicheng District 744 Beijing 745 China 747 Email: qinfengwei@chinamobile.com 749 Tarek Saad 750 Juniper Networks 752 Email: tsaad@juniper.net 754 Vishnu Pavan Beeram 755 Juniper Networks 757 Email: vbeeram@juniper.net