idnits 2.17.1 draft-zheng-ccamp-yang-otn-slicing-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 (July 12, 2021) is 991 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-27 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft I. Busi 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 13, 2022 A. Guo 6 Futurewei Technologies 7 L. Contreras 8 O. Dios 9 Telefonica 10 V. Lopez 11 S. Belotti 12 D. Beller 13 R. Rokui 14 Nokia 15 Y. Xu 16 CAICT 17 Y. Zhao 18 China Mobile 19 July 12, 2021 21 Framework and Data Model for OTN Network Slicing 22 draft-zheng-ccamp-yang-otn-slicing-02 24 Abstract 26 The requirement of slicing network resources with desired quality of 27 service is emerging at every network technology, including the 28 Optical Transport Networks (OTN). As a part of the transport 29 network, OTN can provide hard pipes with guaranteed data isolation 30 and deterministic low latency, which are highly demanded in the 31 Service Level Agreement (SLA). 33 This document describes a framework for OTN network slicing and a 34 YANG data model augmentation of the OTN topology model. Additional 35 YANG data model augmentations will be defined in a future version of 36 this draft. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 13, 2022. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Definition of OTN Slice . . . . . . . . . . . . . . . . . 3 74 2. Use Cases for OTN Network Slicing . . . . . . . . . . . . . . 4 75 2.1. Leased Line Services with OTN . . . . . . . . . . . . . . 4 76 2.2. Co-construction and Sharing . . . . . . . . . . . . . . . 5 77 2.3. Wholesale of optical resources . . . . . . . . . . . . . 5 78 2.4. Vertical dedicated network with OTN . . . . . . . . . . . 5 79 2.5. End-to-end network slicing . . . . . . . . . . . . . . . 6 80 3. Framework for OTN slicing . . . . . . . . . . . . . . . . . . 6 81 4. YANG Data Model for OTN Slicing Configuration . . . . . . . . 9 82 4.1. OTN Slicing YANG Model for MPI . . . . . . . . . . . . . 9 83 4.1.1. MPI YANG Model Overview . . . . . . . . . . . . . . . 9 84 4.1.2. MPI YANG Model Tree . . . . . . . . . . . . . . . . . 10 85 4.1.3. MPI YANG Code . . . . . . . . . . . . . . . . . . . . 10 86 4.2. OTN Slicing YANG Model for OTN-SC NBI . . . . . . . . . . 13 87 5. Manageability Considerations . . . . . . . . . . . . . . . . 13 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 8.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The requirement of slicing network resources with desired quality of 100 service is emerging at every network technology, including the 101 Optical Transport Networks (OTN). As a part of the transport 102 network, OTN can provide hard pipes with guaranteed data isolation 103 and deterministic low latency, which are highly demanded in the 104 Service Level Agreement (SLA). This document describes a framework 105 for OTN network slicing and a YANG data model augmentation of the OTN 106 topology model. Additional YANG data model augmentations will be 107 defined in a future version of this draft. 109 1.1. Definition of OTN Slice 111 An OTN slice is an OTN virtual network topology connecting a number 112 of OTN endpoints using a set of shared or dedicated OTN network 113 resources to satisfy specific service level objectives (SLOs). 115 An OTN slice is a technology-specific realization of an IETF network 116 slice [I-D.ietf-teas-ietf-network-slices] in the OTN domain, with the 117 capability of configuring slice resources in the term of OTN 118 technologies. Therefore, all the terms and definitions concerning 119 network slicing as defined in [I-D.ietf-teas-ietf-network-slices] 120 apply to OTN slicing. 122 An OTN slice can span multiple OTN administrative domains, 123 encompassing access links, intra-domain paths, and inter-domain 124 links. An OTN slice may include multiple endpoints, each associated 125 with a set of physical or logical resources, e.g. optical port or 126 time slots, at the termination point (TP) of an access link or inter- 127 domain link at an OTN provider edge (PE) equipment. 129 An end-to-end OTN slice may be composed of multiple OTN segment 130 slices in a hierarchical or sequential (or stitched) combination. 132 Figure 1 illustrates the scope of OTN slices in multi-domain 133 environment. 135 <------------------End-to-end OTN Slice----------------> 137 <- OTN Segment Slice 1 ---> <-- OTN Segment Slice 2 --> 139 +-------------------------+ +-----------------------+ 140 | +-----+ +-------+ | | +-------+ +-----+| 141 +----+ | | OTN | | OTN | | | | OTN | | OTN || +----+ 142 | CE +-+-o PE +-...--+ Borde o--+--+-o Borde +-...--+ PE o+--+ CE | 143 +----+ |/| | | Node |\ | | | Node | | || +----+ 144 |||+-----+ +-------+ ||| | +-------+ +-----+| | 145 ||| OTN Domain 1 ||| | OTN Domain 2 | | 146 |++-----------------------++| +-----------------------+ | 147 | | | | | 148 | +-----+ +------------+ | | 149 | | | | | 150 V V V V V 151 Access OTN Slice Inter-domain Access 152 Link Endpoint Link Link 154 Figure 1: OTN Slice 156 OTN slices may be pre-configured by the management plane and 157 presented to the customer via the northbound interface (NBI), or be 158 dynamically provisioned by a higher layer slice controller, e.g. an 159 IETF network slice controller (IETF NSC) through the NBI. The OTN 160 slice is provided by a service provider to a customer to be used as 161 though it was part of the customer's own networks. 163 2. Use Cases for OTN Network Slicing 165 2.1. Leased Line Services with OTN 167 For end business customers (like OTT or enterprises), leased lines 168 have the advantage of providing high-speed connections with low 169 costs. On the other hand, the traffic control of leased lines is 170 very challenging due to rapid changes in service demands. Carriers 171 are recommended to provide network-level slicing capabilities to meet 172 this demand. Based on such capabilities, private network users have 173 full control over the sliced resources which have been allocated to 174 them and which could be used to support their leased lines, when 175 needed. Users may formulate policies based on the demand for 176 services and time to schedule the resources from the entire network's 177 perspective flexibly. For example, the bandwidth between any two 178 points may be established or released based on the time or monitored 179 traffic characteristics. The routing and bandwidth may be adjusted 180 at a specific time interval to maximize network resource utilization 181 efficiency. 183 2.2. Co-construction and Sharing 185 Co-construction and sharing of a network are becoming a popular means 186 among service providers to reduce networking building CAPEX. For Co- 187 construction and sharing case, there are typically multiple co- 188 founders for the same network. For example, one founder may provide 189 optical fibres and another founder may provide OTN equipment, while 190 each occupies a certain percentage of the usage rights of the network 191 resources. In this scenario, the network O&M is performed by a 192 certain founder in each region, where the same founder usually 193 deploys an independent management and control system. The other 194 founders of the network use each other's management and control 195 system to provision services remotely. In this scenario, different 196 founders' network resources need to be automatically (associated) 197 divided, isolated, and visualized. All founders may share or have 198 independent O&M capabilities, and should be able to perform service- 199 level provisioning in their respective slices. 201 2.3. Wholesale of optical resources 203 In the optical resource wholesale market, smaller, local carriers and 204 wireless carriers may rent resources from larger carriers, or 205 infrastructure carriers instead of building their networks. 206 Likewise, international carriers may rent resources from respective 207 local carriers and local carriers may lease their owned networks to 208 each other to achieve better network utilization efficiency. From 209 the perspective of a resource provider, it is crucial that a network 210 slice is timely configured to meet traffic matrix requirements 211 requested by its tenants. The support for multi-tenancy within the 212 resource provider's network demands that the network slices are 213 qualitatively isolated from each other to meet the requirements for 214 transparency, non-interference, and security. Typically, a resource 215 purchaser expects to use the leased network resources flexibly, just 216 like they are self-constructed. Therefore, the purchaser is not only 217 provided with a network slice, but also the full set of 218 functionalities for operating and maintaining the network slice. The 219 purchaser also expects to, flexibly and independently, schedule and 220 maintain physical resources to support their own end-to-end 221 automation using both leased and self-constructed network resources. 223 2.4. Vertical dedicated network with OTN 225 Vertical industry slicing is an emerging category of network slicing 226 due to the high demand for private high-speed network interconnects 227 for industrial applications. In this scenario, the biggest challenge 228 is to implement differentiated optical network slices based on the 229 requirements from different industries. For example, in the 230 financial industry, to support high-frequency transactions, the slice 231 must ensure to provide the minimum latency along with the mechanism 232 for latency management. For the healthcare industry, online 233 diagnosis network and software capabilities to ensure the delivery of 234 HD video without frame loss. For bulk data migration in data 235 centers, the network needs to support on-demand, large-bandwidth 236 allocation. In each of the aforementioned vertical industry 237 scenarios, the bandwidth shall be adjusted as required to ensure 238 flexible and efficient network resource usage. 240 2.5. End-to-end network slicing 242 In an end-to-end network slicing scenario such as 5G network slicing 243 [TS.28.530-3GPP], an IETF network slice 244 [I-D.ietf-teas-ietf-network-slices] provides the required 245 connectivity between other different segments of an end-to-end 246 network slice, such as the Radio Access Network (RAN) and the Core 247 Network (CN) segments, with a specific performance commitment. An 248 IETF network slice could be composed of network slices from multiple 249 technological and administrative domains. An IETF network slice can 250 be realized by using or combining multiple underlying OTN slices with 251 OTN resources, e.g. ODU time slots or ODU containers, to achieve 252 end-to-end slicing across the transport domain. 254 3. Framework for OTN slicing 256 OTN slices may be abstracted differently depending on the requirement 257 contained in the configuration provided by the slice customer. 258 Whereas the customer requests an OTN slice to provide connectivities 259 between specified endpoints, an OTN slice can be abstracted as a set 260 of endpoint-to-endpoint links, with each link formed by an end-to-end 261 tunnel across the underlying OTN networks. The resources associated 262 with each link of the slice is reserved and commissioned in the 263 underlying physical network upon the completion of configuring the 264 OTN slice and all the links are active. 266 An OTN slice can also be abstracted as an abstract topology when the 267 customer requests the slice to share resources between multiple 268 endpoints and to use the resources on demand. The abstract topology 269 may consist of virtual nodes and virtual links, whose associated 270 resources are reserved but not commissioned across the underlying OTN 271 networks. The customer can later commission resources within the 272 slice dynamically using the NBI provided by the service provider. An 273 OTN slice could use abstract topology to connect endpoints with 274 shared resources to optimize the resource utilization, and 275 connections can be activated within the slice as needed. 277 It is worth noting that those means to abstract an OTN slice are 278 similar to the Virtual Network (VN) abstraction defined for higher- 279 level interfaces in [RFC8453], in which context a connectivity-based 280 slice corresponds to Type 1 VN and a resource-based slice corresponds 281 to Type 2 VN, respectively. 283 A particular resource in an OTN network, such as a port or link, may 284 be sliced with one of the two granularity levels: 286 o Link-based slicing, in which a link and its associated link 287 termination points (LTPs) are dedicatedly allocated to a 288 particular OTN slice. 290 o Tributary-slot based slicing, in which multiple OTN slices share 291 the same link by allocating different OTN tributary slots in 292 different granularities. 294 Furthermore, an OTN switch is typically fully non-blockable switching 295 at the lowest ODU container granularity, it is desirable to specify 296 just the total number of ODU containers in the lowest granularity 297 (e.g. ODU0), when configuring tributary-slot based slicing on links 298 and ports internal to an OTN network. In multi-domain OTN network 299 scenarios where separate OTN slices are created on each of the OTN 300 networks and are stitched at inter-domain OTN links, it is necessary 301 to specify matching tributary slots at the endpoints of the inter- 302 domain links. In some real network scenarios, OTN network resources 303 including tributary slots are managed explicitly by network operators 304 for network maintenance considerations. Therefore an OTN slice 305 controller shall support configuring an OTN slice with both options. 307 An OTN slice controller (OTN-SC) is a logical function responsible 308 for the life-cycle management of OTN slices instantiated within the 309 corresponding OTN network domains. The OTN-SC provides technology- 310 specific interfaces at its northbound (OTN-SC NBI) to allow a higher- 311 layer slice controller, such as an IETF network slice controller 312 (NSC), or an orchestrator, to request OTN slices with OTN-specific 313 requirements. The OTN-SC interfaces at the southbound using the 314 MDSC-to-PNC interface (MPI) with a Physical Network Controller (PNC) 315 or Multi-Domain Service Orchestrator (MDSC), as defined in the ACTN 316 control framework [RFC8453]. The logical function within the OTN-SC 317 is responsible for translating the OTN slice requests into concrete 318 slice realization which can be understood and provisioned at the 319 southbound by the PNC or MDSC. 321 When realizing OTN slices, the OTN-SC may translate a connectivity- 322 based OTN slice into a set of end-to-end tunnels using the Traffic- 323 engineering(TE) tunnel interface defined in [I-D.ietf-teas-yang-te]. 324 For a resource-based OTN slice, the OTN-SC may translate the abstract 325 topology representing the slice into a colored graph on an abstract 326 TE topology using the TE topology interface defined in [RFC8795]. 328 The OTN-SC NBI is technology-specific, while the IETF NSC-NBI is 329 technology- agnostic. An IETF NSC may translate its customer's 330 technology-agnostic slice request into an OTN slice request and 331 utilize the OTN-SC NBI to realize the IETF network slice. 332 Alternatively, the IETF NSC may translate the slicing request into 333 tunnel or topology configuration commands and communicate directly 334 with the underlying PNC or MDSC to provision the IETF network slice. 336 Figure 2 illustrates the OTN slicing control hierarchy and the 337 positioning of the OTN slicing interfaces. 339 +--------------------+ 340 | Provider's User | 341 +--------|-----------+ 342 | CMI 343 +-----------------------+----------------------------+ 344 | Orchestrator / E2E Slice Controller | 345 +------------+-----------------------------+---------+ 346 | | NSC-NBI 347 | +---------------------+---------+ 348 | | IETF Network Slice Controller | 349 | +-----+---------------+---------+ 350 | | | 351 | OTN-SC NBI |OTN-SC NBI | 352 +------------+-------------+--------+ | 353 | OTN-SC | | 354 +--------------------------+--------+ | 355 | MPI | MPI 356 +--------------------------+---------------+---------+ 357 | PNC | 358 +--------------------------+-------------------------+ 359 | SBI 360 +-----------+----------+ 361 |OTN Physical Network | 362 +----------------------+ 364 Figure 2: Positioning of OTN Slicing Interfaces 366 OTN-SC functionalities may be recursive such that a higher-level OTN- 367 SC may designate the creation of OTN slices to a lower-level OTN-SC 368 in a recursive manner. This scenario may apply to the creation of 369 OTN slices in multi-domain OTN networks, where multiple domain-wide 370 OTN slices provisioned by lower-layer OTN-SCs are stitched to support 371 a multi-domain OTN slice provisioned by the higher-level OTN-SC. 373 Alternatively, the OTN-SC may interface with an MDSC, which in turn 374 interfaces with multiple PNCs through the MPI to realize OTN slices 375 in multi-domain OTN networks without OTN-SC recursion. Figure 3 376 illustrates both options for OTN slicing in multi-domain. 378 +-------------------+ +-------------------+ 379 | OTN-SC | | OTN-SC | 380 +--------|----------+ +---|----------|----+ 381 |MPI |OTN-SC NBI| 382 +--------|----------+ +---|----+ +---|----+ 383 | MDSC | | OTN-SC | | OTN-SC | 384 +---|----------|----+ +---|----+ +---|----+ 385 |MPI |MPI |MPI |MPI 386 +---|----+ +---|----+ +---|----+ +---|----+ 387 | PNC | | PNC | | PNC | | PNC | 388 +--------+ +--------+ +--------+ +--------+ 389 Multi-domain Option 1 Multi-domain Option 2 391 Figure 3: OTN-SC for multi-domain 393 OTN-SC functionalities are logically independent and may be deployed 394 in different combinations to cater to the realization needs. In 395 reference with the ACTN control framework [RFC8453], an OTN-SC may be 396 deployed - as an independent network function; - together with a 397 Physical Network Controller (PNC) for single-domain or with a Multi- 398 Domain Service Orchestrator (MDSC)for multi-domain; - together with a 399 higher-level network slice controller to support end-to-end network 400 slicing; 402 4. YANG Data Model for OTN Slicing Configuration 404 4.1. OTN Slicing YANG Model for MPI 406 4.1.1. MPI YANG Model Overview 408 For the configuration of connectivity-based OTN slices, existing 409 models such as the TE tunnel interface [I-D.ietf-teas-yang-te] may be 410 used and no addition is needed. This model is addressing the case 411 for configuring resource-based OTN slices, where the model permits to 412 reserve resources exploiting the common knowledge of an underlying 413 virtual topology between the OTN-SC and the subtended network 414 controller (MDSC or PNC). The slice is configured by marking 415 corresponding link resources on the TE topology received from the 416 underlying MDSC or PNC with a slice identifier and OTN-specific 417 resource requirements, e.g. the number of ODU time slots or the type/ 418 number of ODU containers. The MDSC or PNC, based on the marked 419 resources by the OTN-SC, will update the underlying TE topology with 420 new TE link for each of the colored links to keep booked the reserved 421 OTN resources e.g. time slots or ODU containers. 423 4.1.2. MPI YANG Model Tree 425 module: ietf-otn-slice 426 augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link- 427 attributes: 428 +--rw (otn-slice-granularity)? 429 +--:(link) 430 | +--rw slice-id? uint32 431 +--:(link-resource) 432 +--rw slices* [slice-id] 433 +--rw slice-id uint32 434 +--rw (technology)? 435 | +--:(otn) 436 | +--rw otn-ts-num? uint32 437 +--ro sliced-link-ref? -> 438 ../../../../../nt:link/link-id 440 Figure 4: OTN network slicing tree diagram 442 4.1.3. MPI YANG Code 444 file "ietf-otn-slice@2021-02-22.yang" 445 module ietf-otn-slice { 446 yang-version 1.1; 447 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-slice"; 448 prefix "otnslice"; 450 import ietf-network { 451 prefix "nw"; 452 reference "RFC 8345: A YANG Data Model for Network Topologies"; 453 } 455 import ietf-network-topology { 456 prefix "nt"; 457 reference "RFC 8345: A YANG Data Model for Network Topologies"; 458 } 460 import ietf-te-topology { 461 prefix "tet"; 462 reference 463 "RFC8795: YANG Data Model for Traffic Engineering 464 (TE) Topologies"; 465 } 467 import ietf-otn-topology { 468 prefix "otntopo"; 469 reference 470 "I-D.ietf-ccamp-otn-topo-yang: A YANG Data Model 471 for Optical Transport Network Topology"; 472 } 474 organization 475 "IETF CCAMP Working Group"; 476 contact 477 "WG Web: 478 WG List: 480 Editor: Haomian Zheng 481 483 Editor: Italo Busi 484 486 Editor: Aihua Guo 487 489 Editor: Victor Lopez 490 "; 492 description 493 "This module defines a YANG data model to configure an OTN 494 network slice realization. 496 The model fully conforms to the Network Management Datastore 497 Architecture (NMDA). 499 Copyright (c) 2021 IETF Trust and the persons 500 identified as authors of the code. All rights reserved. 502 Redistribution and use in source and binary forms, with or 503 without modification, is permitted pursuant to, and subject 504 to the license terms contained in, the Simplified BSD License 505 set forth in Section 4.c of the IETF Trust's Legal Provisions 506 Relating to IETF Documents 507 (https://trustee.ietf.org/license-info). 508 This version of this YANG module is part of RFC XXXX; see 509 the RFC itself for full legal notices."; 511 revision "2021-02-22" { 512 description 513 "Initial Version"; 514 reference 515 "draft-zheng-ccamp-yang-otn-slicing-01: Framework and Data 516 Model for OTN Network Slicing"; 517 } 519 /* 520 * Groupings 521 */ 523 grouping otn-link-slice-profile { 524 description 525 "Profile of an OTN link slice."; 526 choice otn-slice-granularity { 527 default "link"; 528 description 529 "Link slice granularity."; 530 case link { 531 leaf slice-id { 532 type uint32; 533 description 534 "Slice identifier"; 535 } 536 } 537 case link-resource { 538 list slices { 539 key slice-id; 540 description 541 "List of slices."; 542 leaf slice-id { 543 type uint32; 544 description 545 "Slice identifier"; 546 } 547 choice technology { 548 description 549 "Data plane technology types."; 550 case otn { 551 leaf otn-ts-num { 552 type uint32; 553 description 554 "Number of OTN tributary slots allocated for the 555 slice."; 556 } 557 } 558 } 559 leaf sliced-link-ref { 560 type leafref { 561 path "../../../../../nt:link/nt:link-id"; 562 } 563 config false; 564 description 565 "Relative reference to virtual links generated from 566 this TE link."; 567 } 568 } 569 } 570 } 571 } 573 /* 574 * Augments 575 */ 576 augment "/nw:networks/nw:network/nt:link/tet:te/" 577 + "tet:te-link-attributes" { 578 when "../../../nw:network-types/tet:te-topology/" 579 + "otntopo:otn-topology" { 580 description 581 "Augmentation parameters apply only for networks with 582 OTN topology type."; 583 } 584 description 585 "Augment OTN TE link attributes with slicing profile."; 586 uses otn-link-slice-profile; 587 } 588 } 589 591 Figure 5: OTN network slicing YANG model 593 4.2. OTN Slicing YANG Model for OTN-SC NBI 595 TBD. 597 5. Manageability Considerations 599 To ensure the security and controllability of physical resource 600 isolation, slice-based independent operation and management are 601 required to achieve management isolation. Each optical slice 602 typically requires dedicated accounts, permissions, and resources for 603 independent access and O&M. This mechanism is to guarantee the 604 information isolation among slice tenants and to avoid resource 605 conflicts. The access to slice management functions will only be 606 permitted after successful security checks. 608 6. Security Considerations 610 612 7. IANA Considerations 614 616 8. References 618 8.1. Normative References 620 [I-D.ietf-teas-yang-te] 621 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 622 and O. G. D. Dios, "A YANG Data Model for Traffic 623 Engineering Tunnels, Label Switched Paths and Interfaces", 624 draft-ietf-teas-yang-te-27 (work in progress), July 2021. 626 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 627 O. Gonzalez de Dios, "YANG Data Model for Traffic 628 Engineering (TE) Topologies", RFC 8795, 629 DOI 10.17487/RFC8795, August 2020, 630 . 632 [TS.28.530-3GPP] 633 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 634 V15.1.0 Technical Specification Group Services and System 635 Aspects; Management and orchestration; Concepts, use cases 636 and requirements (Release 15)", 3GPP TS 28.530 , December 637 2018, . 640 8.2. Informative References 642 [I-D.ietf-teas-ietf-network-slices] 643 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 644 Makhijani, K., Contreras, L. M., and J. Tantsura, 645 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 646 network-slices-03 (work in progress), May 2021. 648 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 649 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 650 DOI 10.17487/RFC8453, August 2018, 651 . 653 Acknowledgments 655 This document was prepared using kramdown. 657 Previous versions of this document were prepared using 2-Word- 658 v2.0.template.dot. 660 Contributors' Addresses 662 Henry Yu 663 Huawei Technologies Canada 665 Email: henry.yu@huawei.com 667 Authors' Addresses 669 Haomian Zheng 670 Huawei Technologies 671 H1, Xiliu Beipo Village, Songshan Lake 672 Dongguan 673 China 675 Email: zhenghaomian@huawei.com 677 Italo Busi 678 Huawei Technologies 680 Email: italo.busi@huawei.com 682 Aihua Guo 683 Futurewei Technologies 685 Email: aihuaguo.ietf@gmail.com 687 Luis M. Contreras 688 Telefonica 690 Email: luismiguel.contrerasmurillo@telefonica.com 692 Oscar Gonzalez de Dios 693 Telefonica 695 Email: oscar.gonzalezdedios@telefonica.com 696 Victor Lopez 697 Nokia 699 Email: victor.lopez@nokia.com 701 Sergio Belotti 702 Nokia 704 Email: Sergio.belotti@nokia.com 706 Dieter Beller 707 Nokia 709 Email: Dieter.Beller@nokia.com 711 Reza Rokui 712 Nokia 714 Email: reza.rokui@nokia.com 716 Yunbin Xu 717 CAICT 719 Email: xuyunbin@caict.ca.cn 721 Yang Zhao 722 China Mobile 724 Email: zhaoyangyjy@chinamobile.com