idnits 2.17.1 draft-ietf-ccamp-yang-otn-slicing-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 520 has weird spacing: '...du-type ide...' == Line 757 has weird spacing: '...oint-id str...' == Line 760 has weird spacing: '...logy-id str...' == Line 782 has weird spacing: '...trix-id uin...' == Line 790 has weird spacing: '...w tp-id lea...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (5 March 2022) is 773 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) == Missing Reference: 'RFCYYYY' is mentioned on line 141, but not defined == Missing Reference: 'RFCZZZZ' is mentioned on line 143, but not defined == Unused Reference: 'GSMA-NS-Template' is defined on line 1383, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GSMA-NS-Template' == Outdated reference: A later version (-05) exists of draft-contreras-teas-slice-controller-models-01 ** Downref: Normative reference to an Informational draft: draft-contreras-teas-slice-controller-models (ref. 'I-D.draft-contreras-teas-slice-controller-models') == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-11 == Outdated reference: A later version (-17) exists of draft-ietf-ccamp-otn-topo-yang-13 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-06 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slices (ref. 'I-D.ietf-teas-ietf-network-slices') == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 ** Downref: Normative reference to an Informational RFC: RFC 4847 ** Downref: Normative reference to an Informational RFC: RFC 8453 Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group A. Guo 3 Internet-Draft Futurewei Technologies 4 Intended status: Standards Track L.M. Contreras 5 Expires: 6 September 2022 Telefonica 6 S. Belotti 7 Nokia 8 R. Rokui 9 Ciena 10 Y. Xu 11 CAICT 12 Y. Zhao 13 China Mobile 14 X. Liu 15 IBM Corporation 16 5 March 2022 18 Framework and Data Model for OTN Network Slicing 19 draft-ietf-ccamp-yang-otn-slicing-01 21 Abstract 23 The requirement of slicing network resources with desired quality of 24 service is emerging at every network technology, including the 25 Optical Transport Networks (OTN). As a part of the transport 26 network, OTN can provide hard pipes with guaranteed data isolation 27 and deterministic low latency, which are highly demanded in the 28 Service Level Agreement (SLA). 30 This document describes a framework for OTN network slicing and a 31 YANG data model augmentation of the OTN topology model. Additional 32 YANG data model augmentations will be defined in a future version of 33 this draft. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 6 September 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 70 1.3. Definition of OTN Slice . . . . . . . . . . . . . . . . . 4 71 2. Use Cases for OTN Network Slicing . . . . . . . . . . . . . . 5 72 2.1. Leased Line Services with OTN . . . . . . . . . . . . . . 6 73 2.2. Co-construction and Sharing . . . . . . . . . . . . . . . 6 74 2.3. Wholesale of optical resources . . . . . . . . . . . . . 6 75 2.4. Vertical dedicated network with OTN . . . . . . . . . . . 7 76 2.5. End-to-end network slicing . . . . . . . . . . . . . . . 7 77 3. Framework for OTN slicing . . . . . . . . . . . . . . . . . . 8 78 4. YANG Data Model for OTN Slicing Configuration . . . . . . . . 11 79 4.1. OTN Slicing YANG Model for MPI . . . . . . . . . . . . . 11 80 4.1.1. MPI YANG Model Overview . . . . . . . . . . . . . . . 12 81 4.1.2. MPI YANG Model Tree . . . . . . . . . . . . . . . . . 12 82 4.1.3. MPI YANG Code . . . . . . . . . . . . . . . . . . . . 12 83 4.2. OTN Slicing YANG Model for OTN-SC NBI . . . . . . . . . . 16 84 4.2.1. NBI YANG Model Overview . . . . . . . . . . . . . . . 16 85 4.2.2. NBI YANG Model Tree for Transport Network Slice . . . 17 86 4.2.3. NBI YANG Code for Transport Network Slice . . . . . . 18 87 4.2.4. NBI YANG Model Tree for OTN slice . . . . . . . . . . 29 88 4.2.5. NBI YANG Code for OTN Slice . . . . . . . . . . . . . 29 89 5. Manageability Considerations . . . . . . . . . . . . . . . . 29 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 92 8. Normative References . . . . . . . . . . . . . . . . . . . . 30 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 The terminology for describing YANG data models is found in 118 [RFC7950]. 120 1.2. Prefixes in Data Node Names 122 In this document, names of data nodes and other data model objects 123 are prefixed using the standard prefix associated with the 124 corresponding YANG imported modules, as shown in Table 1. 126 +==========+==============================+===========+ 127 | Prefix | YANG Module | Reference | 128 +==========+==============================+===========+ 129 | yang | ietf-yang-types | [RFC6991] | 130 +----------+------------------------------+-----------+ 131 | inet | ietf-inet-types | [RFC6991] | 132 +----------+------------------------------+-----------+ 133 | nt | ietf-network-topology | [RFC8345] | 134 +----------+------------------------------+-----------+ 135 | nw | ietf-network-topology | [RFC8345] | 136 +----------+------------------------------+-----------+ 137 | tet | ietf-te-topology | [RFC8795] | 138 +----------+------------------------------+-----------+ 139 | te-types | ietf-te-types | [RFC8776] | 140 +----------+------------------------------+-----------+ 141 | otnt | ietf-otn-topology | [RFCYYYY] | 142 +----------+------------------------------+-----------+ 143 | l1-types | ietf-layer1-types | [RFCZZZZ] | 144 +----------+------------------------------+-----------+ 145 | tns | ietf-transport-network-slice | RFCXXXX | 146 +----------+------------------------------+-----------+ 147 | otns | ietf-otn-slice | RFCXXXX | 148 +----------+------------------------------+-----------+ 150 Table 1: Prefixes and Corresponding YANG Modules 152 RFC Editor Note: Please replace XXXX with the RFC number assigned to 153 this document. Please replace YYYY with the RFC number assigned to 154 [I-D.ietf-ccamp-otn-topo-yang]. Please replace ZZZZ with the RFC 155 number assigned to [I-D.ietf-ccamp-layer1-types]. Please remove this 156 note. 158 1.3. Definition of OTN Slice 160 An OTN slice is an OTN virtual network topology connecting a number 161 of OTN endpoints using a set of shared or dedicated OTN network 162 resources to satisfy specific service level objectives (SLOs). 164 An OTN slice is a technology-specific realization of an IETF network 165 slice [I-D.ietf-teas-ietf-network-slices] in the OTN domain, with the 166 capability of configuring slice resources in the term of OTN 167 technologies. Therefore, all the terms and definitions concerning 168 network slicing as defined in [I-D.ietf-teas-ietf-network-slices] 169 apply to OTN slicing. 171 An OTN slice can span multiple OTN administrative domains, 172 encompassing access links, intra-domain paths, and inter-domain 173 links. An OTN slice may include multiple endpoints, each associated 174 with a set of physical or logical resources, e.g. optical port or 175 time slots, at the termination point (TP) of an access link or inter- 176 domain link at an OTN provider edge (PE) equipment. 178 An end-to-end OTN slice may be composed of multiple OTN segment 179 slices in a hierarchical or sequential (or stitched) combination. 181 Figure 1 illustrates the scope of OTN slices in multi-domain 182 environment. 184 <------------------End-to-end OTN Slice----------------> 186 <- OTN Segment Slice 1 ---> <-- OTN Segment Slice 2 --> 188 +-------------------------+ +-----------------------+ 189 | +-----+ +-------+ | | +-------+ +-----+| 190 +----+ | | OTN | | OTN | | | | OTN | | OTN || +----+ 191 | CE +-+-o PE +-...--+ Borde o--+--+-o Borde +-...--+ PE o+--+ CE | 192 +----+||/| | | Node |\ || | | Node | | || |+----+ 193 |||+-----+ +-------+| || | +-------+ +-----+| | 194 ||| OTN Domain 1 | || | OTN Domain 2 | | 195 |++----------------------+-+| +-----------------------+ | 196 | | | | | 197 | +-----+ +-----------+ | | 198 | | | | | 199 V V V V V 200 Access OTN Slice Inter-domain Access 201 Link Endpoint Link Link 203 Figure 1: OTN Slice 205 OTN slices may be pre-configured by the management plane and 206 presented to the customer via the northbound interface (NBI), or be 207 dynamically provisioned by a higher layer slice controller, e.g. an 208 IETF network slice controller (IETF NSC) through the NBI. The OTN 209 slice is provided by a service provider to a customer to be used as 210 though it was part of the customer's own networks. 212 2. Use Cases for OTN Network Slicing 213 2.1. Leased Line Services with OTN 215 For end business customers (like OTT or enterprises), leased lines 216 have the advantage of providing high-speed connections with low 217 costs. On the other hand, the traffic control of leased lines is 218 very challenging due to rapid changes in service demands. Carriers 219 are recommended to provide network-level slicing capabilities to meet 220 this demand. Based on such capabilities, private network users have 221 full control over the sliced resources which have been allocated to 222 them and which could be used to support their leased lines, when 223 needed. Users may formulate policies based on the demand for 224 services and time to schedule the resources from the entire network's 225 perspective flexibly. For example, the bandwidth between any two 226 points may be established or released based on the time or monitored 227 traffic characteristics. The routing and bandwidth may be adjusted 228 at a specific time interval to maximize network resource utilization 229 efficiency. 231 2.2. Co-construction and Sharing 233 Co-construction and sharing of a network are becoming a popular means 234 among service providers to reduce networking building CAPEX. For Co- 235 construction and sharing case, there are typically multiple co- 236 founders for the same network. For example, one founder may provide 237 optical fibres and another founder may provide OTN equipment, while 238 each occupies a certain percentage of the usage rights of the network 239 resources. In this scenario, the network O&M is performed by a 240 certain founder in each region, where the same founder usually 241 deploys an independent management and control system. The other 242 founders of the network use each other's management and control 243 system to provision services remotely. In this scenario, different 244 founders' network resources need to be automatically (associated) 245 divided, isolated, and visualized. All founders may share or have 246 independent O&M capabilities, and should be able to perform service- 247 level provisioning in their respective slices. 249 2.3. Wholesale of optical resources 251 In the optical resource wholesale market, smaller, local carriers and 252 wireless carriers may rent resources from larger carriers, or 253 infrastructure carriers instead of building their networks. 254 Likewise, international carriers may rent resources from respective 255 local carriers and local carriers may lease their owned networks to 256 each other to achieve better network utilization efficiency. From 257 the perspective of a resource provider, it is crucial that a network 258 slice is timely configured to meet traffic matrix requirements 259 requested by its tenants. The support for multi-tenancy within the 260 resource provider's network demands that the network slices are 261 qualitatively isolated from each other to meet the requirements for 262 transparency, non-interference, and security. Typically, a resource 263 purchaser expects to use the leased network resources flexibly, just 264 like they are self-constructed. Therefore, the purchaser is not only 265 provided with a network slice, but also the full set of 266 functionalities for operating and maintaining the network slice. The 267 purchaser also expects to, flexibly and independently, schedule and 268 maintain physical resources to support their own end-to-end 269 automation using both leased and self-constructed network resources. 271 2.4. Vertical dedicated network with OTN 273 Vertical industry slicing is an emerging category of network slicing 274 due to the high demand for private high-speed network interconnects 275 for industrial applications. In this scenario, the biggest challenge 276 is to implement differentiated optical network slices based on the 277 requirements from different industries. For example, in the 278 financial industry, to support high-frequency transactions, the slice 279 must ensure to provide the minimum latency along with the mechanism 280 for latency management. For the healthcare industry, online 281 diagnosis network and software capabilities to ensure the delivery of 282 HD video without frame loss. For bulk data migration in data 283 centers, the network needs to support on-demand, large-bandwidth 284 allocation. In each of the aforementioned vertical industry 285 scenarios, the bandwidth shall be adjusted as required to ensure 286 flexible and efficient network resource usage. 288 2.5. End-to-end network slicing 290 In an end-to-end network slicing scenario such as 5G network slicing 291 [TS.28.530-3GPP], an IETF network slice 292 [I-D.ietf-teas-ietf-network-slices] provides the required 293 connectivity between other different segments of an end-to-end 294 network slice, such as the Radio Access Network (RAN) and the Core 295 Network (CN) segments, with a specific performance commitment. An 296 IETF network slice could be composed of network slices from multiple 297 technological and administrative domains. An IETF network slice can 298 be realized by using or combining multiple underlying OTN slices with 299 OTN resources, e.g. ODU time slots or ODU containers, to achieve 300 end-to-end slicing across the transport domain. 302 3. Framework for OTN slicing 304 OTN slices may be abstracted differently depending on the requirement 305 contained in the configuration provided by the slice customer. 306 Whereas the customer requests an OTN slice to provide connectivities 307 between specified endpoints, an OTN slice can be abstracted as a set 308 of endpoint-to-endpoint links, with each link formed by an end-to-end 309 tunnel across the underlying OTN networks. The resources associated 310 with each link of the slice is reserved and commissioned in the 311 underlying physical network upon the completion of configuring the 312 OTN slice and all the links are active. 314 An OTN slice can also be abstracted as an abstract topology when the 315 customer requests the slice to share resources between multiple 316 endpoints and to use the resources on demand. The abstract topology 317 may consist of virtual nodes and virtual links, whose associated 318 resources are reserved but not commissioned across the underlying OTN 319 networks. The customer can later commission resources within the 320 slice dynamically using the NBI provided by the service provider. An 321 OTN slice could use abstract topology to connect endpoints with 322 shared resources to optimize the resource utilization, and 323 connections can be activated within the slice as needed. 325 It is worth noting that those means to abstract an OTN slice are 326 similar to the Virtual Network (VN) abstraction defined for higher- 327 level interfaces in [RFC8453], in which context a connectivity-based 328 slice corresponds to Type 1 VN and a resource-based slice corresponds 329 to Type 2 VN, respectively. 331 A particular resource in an OTN network, such as a port or link, may 332 be sliced with one of the two granularity levels: 334 * Link-based slicing, in which a link and its associated link 335 termination points (LTPs) are dedicatedly allocated to a 336 particular OTN slice. 338 * Tributary-slot based slicing, in which multiple OTN slices share 339 the same link by allocating different OTN tributary slots in 340 different granularities. 342 Furthermore, an OTN switch is typically fully non-blockable switching 343 at the lowest ODU container granularity, it is desirable to specify 344 just the total number of ODU containers in the lowest granularity 345 (e.g. ODU0), when configuring tributary-slot based slicing on links 346 and ports internal to an OTN network. In multi-domain OTN network 347 scenarios where separate OTN slices are created on each of the OTN 348 networks and are stitched at inter-domain OTN links, it is necessary 349 to specify matching tributary slots at the endpoints of the inter- 350 domain links. In some real network scenarios, OTN network resources 351 including tributary slots are managed explicitly by network operators 352 for network maintenance considerations. Therefore an OTN slice 353 controller shall support configuring an OTN slice with both options. 355 An OTN slice controller (OTN-SC) is a logical function responsible 356 for the life-cycle management of OTN slices instantiated within the 357 corresponding OTN network domains. The OTN-SC provides technology- 358 specific interfaces at its northbound (OTN-SC NBI) to allow a higher- 359 layer slice controller, such as an IETF network slice controller 360 (NSC) or an orchestrator, to request OTN slices with OTN-specific 361 requirements. The OTN-SC interfaces at the southbound using the 362 MDSC-to-PNC interface (MPI) with a Physical Network Controller (PNC) 363 or Multi-Domain Service Orchestrator (MDSC), as defined in the ACTN 364 control framework [RFC8453]. The logical function within the OTN-SC 365 is responsible for translating the OTN slice requests into concrete 366 slice realization which can be understood and provisioned at the 367 southbound by the PNC or MDSC. 369 The presence of OTN-SC provides multiple options for a high-level 370 slice controller or an orchestrator to configure and realize slicing 371 in OTN networks, depending on whether a customer's slice request is 372 technology agnostic or technology specific: 374 Option 1[opt.1]: An IETF NSC receives a technology-agnostic slice 375 request from the IETF NSC NBI and realizes full or part of the slice 376 in OTN networks directly through MPI provided by the PNC or MDSC. 377 The IETF NSC is responsible for mapping a technology-agnostic slicing 378 request into an OTN technology-specific realization. In this option, 379 the OTN-SC is not used. 381 Option 2[opt.2]: An IETF NSC receives a technology-agnostic slice 382 request from the IETF NSC NBI and delegates the request to the OTN-SC 383 through the OTN-SC NBI, which is OTN technology specific. The OTN-SC 384 in turn realizes the slice in single or multi domain OTN networks by 385 working with the underlying PNC or MDSC. In this option, the OTN-SC 386 is considered as a realization of IETF NSC, i.e., an NS realizer as 387 per [I-D.draft-contreras-teas-slice-controller-models], when the 388 underlying network is OTN. The OTN-SC is also a subordinate slice 389 controller of the IETF NSC, which is consistent with the hierarchical 390 control of slices defined by the IETF network slice framework. 392 Option 3[opt.3]: An OTN-aware orchestrator may request an OTN 393 technology-specific slice with OTN-specific SLOs through the OTN-SC 394 NBI to the OTN-SC. The OTN-SC in turn realizes the slice in single 395 or multi domain OTN networks by working with the underlying PNC or 396 MDSC 397 An OTN slice may be realized by using standard MPI interfaces, 398 control plane, network management system (NMS) or any other 399 proprietary interfaces as needed. Examples of such interfaces 400 include the abstract TE topology [RFC8795], TE tunnel 401 [I-D.ietf-teas-yang-te],L1VPN[RFC4847], or Netconf/YANG based 402 interfaces such as OpenConfig. Some of these interfaces, such as the 403 TE tunnel model, are suitable for creating connectivity-based OTN 404 slices which represent a slice as a set of TE tunnels, while other 405 interfaces such as the TE topology model are more suitable for 406 creating resource-based OTN slices which represent a slice as a 407 topology. 409 The OTN-SC NBI is a technology-specific interface that augments the 410 IETF NSC NBI, which is technology- agnostic. 412 Figure 2 illustrates the OTN slicing control hierarchy , the 413 positioning of the OTN slicing interfaces as well as the options for 414 OTN slice configuration. 416 +--------------------+ 417 | Provider's User | 418 +--------|-----------+ 419 | CMI 420 +-----------------------+----------------------------+ 421 | Orchestrator / E2E Slice Controller | 422 +------------+-----------------------------+---------+ 423 | | NSC-NBI 424 | +---------------------+---------+ 425 | | IETF Network Slice Controller | 426 | +-----+---------------+---------+ 427 | opt.3 | opt.2 | opt.1 428 | OTN-SC NBI |OTN-SC NBI | 429 +------------+-------------+--------+ | 430 | OTN-SC | | 431 +--------------------------+--------+ | 432 | MPI | MPI 433 +--------------------------+---------------+---------+ 434 | PNC | 435 +--------------------------+-------------------------+ 436 | SBI 437 +-----------+----------+ 438 |OTN Physical Network | 439 +----------------------+ 441 Figure 2: Positioning of OTN Slicing Interfaces 443 OTN-SC functionalities may be recursive such that a higher-level OTN- 444 SC may designate the creation of OTN slices to a lower-level OTN-SC 445 in a recursive manner. This scenario may apply to the creation of 446 OTN slices in multi-domain OTN networks, where multiple domain-wide 447 OTN slices provisioned by lower-layer OTN-SCs are stitched to support 448 a multi-domain OTN slice provisioned by the higher-level OTN-SC. 449 Alternatively, the OTN-SC may interface with an MDSC, which in turn 450 interfaces with multiple PNCs through the MPI to realize OTN slices 451 in multi-domain OTN networks without OTN-SC recursion. Figure 3 452 illustrates both options for OTN slicing in multi-domain. 454 +-------------------+ +-------------------+ 455 | OTN-SC | | OTN-SC | 456 +--------|----------+ +---|----------|----+ 457 |MPI |OTN-SC NBI| 458 +--------|----------+ +---|----+ +---|----+ 459 | MDSC | | OTN-SC | | OTN-SC | 460 +---|----------|----+ +---|----+ +---|----+ 461 |MPI |MPI |MPI |MPI 462 +---|----+ +---|----+ +---|----+ +---|----+ 463 | PNC | | PNC | | PNC | | PNC | 464 +--------+ +--------+ +--------+ +--------+ 465 Multi-domain Option 1 Multi-domain Option 2 467 Figure 3: OTN-SC for multi-domain 469 OTN-SC functionalities are logically independent and may be deployed 470 in different combinations to cater to the realization needs. In 471 reference with the ACTN control framework [RFC8453], an OTN-SC may be 472 deployed 474 * as an independent network function; 476 * together with a Physical Network Controller (PNC) for single- 477 domain or with a Multi-Domain Service Orchestrator (MDSC)for 478 multi-domain; 480 * together with a higher-level network slice controller to support 481 end-to-end network slicing; 483 4. YANG Data Model for OTN Slicing Configuration 485 4.1. OTN Slicing YANG Model for MPI 486 4.1.1. MPI YANG Model Overview 488 For the configuration of connectivity-based OTN slices, existing 489 models such as the TE tunnel interface [I-D.ietf-teas-yang-te] may be 490 used and no addition is needed. This model is addressing the case 491 for configuring resource-based OTN slices, where the model permits to 492 reserve resources exploiting the common knowledge of an underlying 493 virtual topology between the OTN-SC and the subtended network 494 controller (MDSC or PNC). The slice is configured by marking 495 corresponding link resources on the TE topology received from the 496 underlying MDSC or PNC with a slice identifier and OTN-specific 497 resource requirements, e.g. the number of ODU time slots or the type/ 498 number of ODU containers. The MDSC or PNC, based on the marked 499 resources by the OTN-SC, will update the underlying TE topology with 500 new TE link for each of the colored links to keep booked the reserved 501 OTN resources e.g. time slots or ODU containers. 503 4.1.2. MPI YANG Model Tree 505 module: ietf-otn-slice 507 augment /nw:networks/nw:network/nt:link/tet:te 508 /tet:te-link-attributes: 509 +--rw (otn-slice-granularity)? 510 +--:(link) 511 | +--rw slice-id? uint32 512 +--:(link-resource) 513 +--rw slices* [slice-id] 514 +--rw slice-id uint32 515 +--rw (technology)? 516 | +--:(otn) 517 | +--rw (slice-bandwidth)? 518 | +--:(containers) 519 | | +--rw odulist* [odu-type] 520 | | +--rw odu-type identityref 521 | | +--rw number? uint16 522 | +--:(time-slots) 523 | +--rw otn-ts-num? uint32 524 +--ro sliced-link-ref? 525 -> ../../../../../nt:link/link-id 527 Figure 4: OTN slicing tree diagram 529 4.1.3. MPI YANG Code 530 file "ietf-otn-slice@2022-03-04.yang" 531 module ietf-otn-slice { 532 yang-version 1.1; 533 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-slice"; 534 prefix "otns"; 536 import ietf-network { 537 prefix "nw"; 538 reference 539 "RFC 8345: A YANG Data Model for Network Topologies"; 540 } 542 import ietf-network-topology { 543 prefix "nt"; 544 reference 545 "RFC 8345: A YANG Data Model for Network Topologies"; 546 } 548 import ietf-te-topology { 549 prefix "tet"; 550 reference 551 "RFC8795: YANG Data Model for Traffic Engineering 552 (TE) Topologies"; 553 } 555 import ietf-otn-topology { 556 prefix "otnt"; 557 reference 558 "I-D.ietf-ccamp-otn-topo-yang: A YANG Data Model 559 for Optical Transport Network Topology"; 560 } 562 import ietf-layer1-types { 563 prefix "l1-types"; 564 reference 565 "I-D.ietf-ccamp-layer1-types: A YANG Data Model 566 for Layer 1 Types"; 567 } 569 organization 570 "IETF CCAMP Working Group"; 571 contact 572 "WG Web: 573 WG List: 575 Editor: Haomian Zheng 576 578 Editor: Italo Busi 579 581 Editor: Aihua Guo 582 584 Editor: Victor Lopez 585 "; 587 description 588 "This module defines a YANG data model for network slice 589 realization in Optical Transport Networks (OTN). 591 The model fully conforms to the Network Management Datastore 592 Architecture (NMDA). 594 Copyright (c) 2022 IETF Trust and the persons 595 identified as authors of the code. All rights reserved. 597 Redistribution and use in source and binary forms, with or 598 without modification, is permitted pursuant to, and subject 599 to the license terms contained in, the Simplified BSD 600 License set forth in Section 4.c of the IETF Trust's Legal 601 Provisions Relating to IETF Documents 602 (https://trustee.ietf.org/license-info). 603 This version of this YANG module is part of RFC XXXX; see 604 the RFC itself for full legal notices."; 606 revision "2022-03-04" { 607 description 608 "Latest revision of MPI YANG model for OTN slicing."; 609 reference 610 "draft-ietf-ccamp-yang-otn-slicing-01: Framework and Data 611 Model for OTN Network Slicing"; 612 } 614 /* 615 * Groupings 616 */ 618 grouping otn-link-slice-profile { 619 description 620 "Profile of an OTN link slice."; 621 choice otn-slice-granularity { 622 default "link"; 623 description 624 "Link slice granularity."; 625 case link { 626 leaf slice-id { 627 type uint32; 628 description 629 "Slice identifier"; 630 } 631 } 632 case link-resource { 633 list slices { 634 key slice-id; 635 description 636 "List of slices."; 637 leaf slice-id { 638 type uint32; 639 description 640 "Slice identifier"; 641 } 642 choice technology { 643 description 644 "Data plane technology types."; 645 case otn { 646 choice slice-bandwidth { 647 description 648 "Bandwidth specification for OTN slices."; 649 case containers { 650 uses l1-types:otn-link-bandwidth; 651 } 652 case time-slots { 653 leaf otn-ts-num { 654 type uint32; 655 description 656 "Number of OTN tributary slots allocated 657 for the slice."; 658 } 659 } 660 } 661 } 662 } 663 leaf sliced-link-ref { 664 type leafref { 665 path "../../../../../nt:link/nt:link-id"; 666 } 667 config false; 668 description 669 "Relative reference to virtual links generated from 670 this TE link."; 671 } 672 } 673 } 675 } 676 } 678 /* 679 * Augments 680 */ 681 augment "/nw:networks/nw:network/nt:link/tet:te/" 682 + "tet:te-link-attributes" { 683 when "../../../nw:network-types/tet:te-topology/" 684 + "otnt:otn-topology" { 685 description 686 "Augmentation parameters apply only for networks with 687 OTN topology type."; 688 } 689 description 690 "Augment OTN TE link attributes with slicing profile."; 691 uses otn-link-slice-profile; 692 } 693 } 694 696 Figure 5: OTN slicing YANG model 698 4.2. OTN Slicing YANG Model for OTN-SC NBI 700 4.2.1. NBI YANG Model Overview 702 The YANG model for OTN-SC NBI is OTN-technology specific, but shares 703 many common constructs and attributes with generic network slicing 704 YANG models. Furthermore, the OTN-SC NBI YANG is expected to support 705 both connectivity-based and resource-based slice configuration, which 706 is likely a common requirement for supporting slicing at other 707 transport network layers, e.g. WDM or MPLS(-TP). Therefore, the 708 OTN-SC NBI YANG model is designed into two models, a common base 709 model for transport network slicing, and an OTN slicing model which 710 augments the base model with OTN technology-specific constructs. 712 The base model defines a transport network slice (TNS) with the 713 following constructs and attributes: 715 * Common attributes, which include a set of common attributes like 716 slice identifier, name, description and names of customers who use 717 the slice. 719 * Endpoints, which represent conceptual points of connection from a 720 customer device to the TNS. An endpoint is mapped to specific 721 physical or virtual resources of the customer and provider, and 722 such mapping is pre-negotiated and known to both the customer and 723 provider prior to the slice configuration. The mechanism for 724 endpoint negotiation is outside the scope of this draft. 726 * Network topology, which represent set of shared, reserved 727 resources organized as a virtual topology between all of the 728 endpoints. A customer could use such network topology to define 729 detailed connecvitiy path traversing the topology, and allow 730 sharing of resources between its multiple endpoint pairs. 732 * Connectivity matrix, which represent the intended virtual 733 connections between the endpoints within a TNS. A connctivity 734 matrix entry could be associated with an explicit path over the 735 above network topology. 737 * Service-level objectives (SLOs) associated with different objects, 738 including the TNS, node, link, termination point, and explicit 739 path, within a TNS. 741 4.2.2. NBI YANG Model Tree for Transport Network Slice 743 module: ietf-transport-network-slice 744 +--rw network-slices 745 +--rw network-slice* [ns-id] 746 +--rw ns-id string 747 +--rw ns-name? string 748 +--rw ns-description? string 749 +--rw customer-name* string 750 +--rw slo 751 | +--rw optimization-criterion? identityref 752 | +--rw delay-tolerance? boolean 753 | +--rw periodicity* uint64 754 | +--rw isolation-level? identityref 755 +--rw endpoints 756 | +--rw endpoint* [endpoint-id] 757 | +--rw endpoint-id string 758 +--rw network-topologies 759 | +--rw network-topology* [topology-id] 760 | +--rw topology-id string 761 | +--rw node* [node-id] 762 | | +--rw node-id inet:uri 763 | | +--rw slo 764 | | | +--rw isolation-level? identityref 765 | | +--rw termination-point* [tp-id] 766 | | +--rw tp-id inet:uri 767 | | +--rw endpoint-id? leafref 768 | +--rw link* [link-id] 769 | +--rw link-id inet:uri 770 | +--rw slo 771 | | +--rw delay-tolerance? boolean 772 | | +--rw periodicity* uint64 773 | | +--rw isolation-level? identityref 774 | +--rw source 775 | | +--rw source-node? -> ../../../node/node-id 776 | | +--rw source-tp? leafref 777 | +--rw destination 778 | +--rw dest-node? -> ../../../node/node-id 779 | +--rw dest-tp? leafref 780 +--rw connectivity-matrices 781 +--rw connectivity-matrix* [connectivity-matrix-id] 782 +--rw connectivity-matrix-id uint32 783 +--rw topology-id? leafref 784 +--rw src-endpoint? 785 | -> ../../../endpoints/endpoint/endpoint-id 786 +--rw dst-endpoint? 787 | -> ../../../endpoints/endpoint/endpoint-id 788 +--rw slo 789 +--rw explicit-path* [tp-id] 790 +--rw tp-id leafref 792 Figure 6: Tree diagram for transport network slice 794 4.2.3. NBI YANG Code for Transport Network Slice 796 file "ietf-transport-network-slice@2022-03-04.yang" 797 module ietf-transport-network-slice { 798 yang-version 1.1; 799 namespace 800 "urn:ietf:params:xml:ns:yang:ietf-transport-network-slice"; 801 prefix "tns"; 803 import ietf-inet-types { 804 prefix inet; 805 reference 806 "RFC 6991: Common YANG Data Types"; 807 } 809 import ietf-te-types { 810 prefix "te-types"; 811 reference 812 "RFC 8776: Traffic Engineering Common YANG Types"; 813 } 814 organization 815 "IETF CCAMP Working Group"; 816 contact 817 "WG Web: 818 WG List: 820 Editor: Haomian Zheng 821 823 Editor: Italo Busi 824 826 Editor: Aihua Guo 827 829 Editor: Victor Lopez 830 "; 832 description 833 "This module defines a base YANG data model for configuring 834 generic network slices in optical transport networks, e.g., 835 Optical Transport Network (OTN). 837 The model fully conforms to the Network Management Datastore 838 Architecture (NMDA). 840 Copyright (c) 2022 IETF Trust and the persons 841 identified as authors of the code. All rights reserved. 843 Redistribution and use in source and binary forms, with or 844 without modification, is permitted pursuant to, and subject 845 to the license terms contained in, the Simplified BSD 846 License set forth in Section 4.c of the IETF Trust's Legal 847 Provisions Relating to IETF Documents 848 (https://trustee.ietf.org/license-info). 849 This version of this YANG module is part of RFC XXXX; see 850 the RFC itself for full legal notices."; 852 revision "2022-03-04" { 853 description 854 "Latest revision of NBI YANG model for OTN slicing."; 855 reference 856 "draft-ietf-ccamp-yang-otn-slicing-01: Framework and Data 857 Model for OTN Network Slicing"; 858 } 860 /* 861 * Identities 862 */ 863 identity isolation-level { 864 description 865 "Base identity for the isolation-level."; 866 reference 867 "GSMA-NS-Template: Generic Network Slice Template, 868 Version 3.0."; 869 } 870 identity no-isolation { 871 base isolation-level; 872 description 873 "Network slices are not separated."; 874 } 875 identity physical-isolation { 876 base isolation-level; 877 description 878 "Network slices are physically separated (e.g. different 879 rack, different hardware, different location, etc.)."; 880 } 881 identity logical-isolation { 882 base isolation-level; 883 description 884 "Network slices are logically separated."; 885 } 886 identity process-isolation { 887 base physical-isolation; 888 description 889 "Process and threads isolation."; 890 } 891 identity physical-memory-isolation { 892 base physical-isolation; 893 description 894 "Process and threads isolation."; 895 } 896 identity physical-network-isolation { 897 base physical-isolation; 898 description 899 "Process and threads isolation."; 900 } 901 identity virtual-resource-isolation { 902 base logical-isolation; 903 description 904 "A network slice has access to specific range of resources 905 that do not overlap with other network slices 906 (e.g. VM isolation)."; 907 } 908 identity network-functions-isolation { 909 base logical-isolation; 910 description 911 "NF (Network Function) is dedicated to the network slice, 912 but virtual resources are shared."; 913 } 914 identity service-isolation { 915 base logical-isolation; 916 description 917 "NSC data are isolated from other NSCs, but virtual 918 resources and NFs are shared."; 919 } 921 /* 922 * Groupings 923 */ 925 grouping ns-generic-info { 926 description 927 "Generic configuration of a network slice"; 928 leaf ns-name { 929 type string; 930 description 931 "Name of the specific network slice"; 932 } 933 leaf ns-description { 934 type string; 935 description 936 "Description regarding the specific network slice"; 937 } 938 leaf-list customer-name { 939 type string; 940 description 941 "List of customers using the slice"; 942 } 943 } 945 grouping ns-slo { 946 description 947 "SLO configuration of a network slice"; 949 container slo { 950 description 951 "SLO configuration of a network slice"; 953 leaf optimization-criterion { 954 type identityref { 955 base te-types:objective-function-type; 956 } 957 description 958 "Optimization criterion applied to this topology."; 959 } 960 leaf delay-tolerance { 961 type boolean; 962 description 963 "'true' if is not too critical how long it takes to 964 deliver the amount of data."; 965 reference 966 "GSMA-NS-Template: Generic Network Slice Template, 967 Version 3.0."; 968 } 969 leaf-list periodicity { 970 type uint64; 971 units seconds; 972 description 973 "A list of periodicities supported by the network 974 slice."; 975 reference 976 "GSMA-NS-Template: Generic Network Slice Template, 977 Version 3.0."; 978 } 979 leaf isolation-level { 980 type identityref { 981 base isolation-level; 982 } 983 description 984 "A network slice instance may be fully or partly, 985 logically and/or physically, isolated from another 986 network slice instance. This attribute describes 987 different types of isolation:"; 988 } 989 } 990 } 992 grouping node-slo { 993 description 994 "Node SLO"; 995 container slo { 996 description 997 "SLO configuration of a node"; 998 leaf isolation-level { 999 type identityref { 1000 base isolation-level; 1001 } 1002 description 1003 "A network slice instance may be fully or partly, 1004 logically and/or physically, isolated from another 1005 network slice instance. This attribute describes 1006 different types of isolation:"; 1007 } 1008 } 1009 } 1011 grouping link-slo { 1012 description 1013 "Link SLO"; 1014 container slo { 1015 description 1016 "SLO configuration of a link"; 1017 leaf delay-tolerance { 1018 type boolean; 1019 description 1020 "'true' if is not too critical how long it takes to 1021 deliver the amount of data."; 1022 reference 1023 "GSMA-NS-Template: Generic Network Slice Template, 1024 Version 3.0."; 1025 } 1026 leaf-list periodicity { 1027 type uint64; 1028 units seconds; 1029 description 1030 "A list of periodicities supported by the network 1031 slice."; 1032 reference 1033 "GSMA-NS-Template: Generic Network Slice Template, 1034 Version 3.0."; 1035 } 1036 leaf isolation-level { 1037 type identityref { 1038 base isolation-level; 1039 } 1040 description 1041 "A network slice instance may be fully or partly, 1042 logically and/or physically, isolated from another 1043 network slice instance. This attribute describes 1044 different types of isolation:"; 1045 } 1046 } 1047 } 1049 grouping connectivity-matrix-slo { 1050 description 1051 "SLO configuration of a path within a network slice"; 1053 container slo { 1054 description 1055 "Path SLO configuration"; 1056 } 1057 leaf delay-tolerance { 1058 type boolean; 1059 description 1060 "'true' if is not too critical how long it takes to 1061 deliver the amount of data."; 1062 reference 1063 "GSMA-NS-Template: Generic Network Slice Template, 1064 Version 3.0."; 1065 } 1066 leaf-list periodicity { 1067 type uint64; 1068 units seconds; 1069 description 1070 "A list of periodicities supported by the network 1071 slice."; 1072 reference 1073 "GSMA-NS-Template: Generic Network Slice Template, 1074 Version 3.0."; 1075 } 1076 leaf isolation-level { 1077 type identityref { 1078 base isolation-level; 1079 } 1080 description 1081 "A network slice instance may be fully or partly, 1082 logically and/or physically, isolated from another 1083 network slice instance. This attribute describes 1084 different types of isolation:"; 1085 } 1086 } 1088 grouping connectivity-matrix-entry-slo { 1089 description 1090 "SLO configuration of a connectivity matrix entry within a 1091 network slice"; 1093 container slo { 1094 description 1095 "SLO configuration of a connectivity matrix entry"; 1096 } 1097 } 1099 grouping explicit-path { 1100 description 1101 "Explicit path for a connectivity matrix entry"; 1103 list explicit-path { 1104 key "tp-id"; 1105 description 1106 "List of TPs within a network topology that form a 1107 path."; 1108 leaf tp-id { 1109 type leafref { 1110 path "/network-slices/network-slice[ns-id=current()"+ 1111 "/../../../../ns-id]/network-topologies"+ 1112 "/network-topology[topology-id=current()"+ 1113 "/../../topology-id]/node/termination-point"+ 1114 "/tp-id"; 1115 } 1116 description 1117 "Relative reference to TP id."; 1118 } 1119 } 1120 } 1122 grouping network-topology-def { 1123 description 1124 "Network topology definition"; 1125 list node { 1126 key "node-id"; 1127 description 1128 "The inventory of nodes of this topology."; 1129 leaf node-id { 1130 type inet:uri; 1131 description 1132 "Node identifier."; 1133 } 1134 uses node-slo; 1135 list termination-point { 1136 key "tp-id"; 1137 description 1138 "TP identifier"; 1139 leaf tp-id { 1140 type inet:uri; 1141 description 1142 "Termination point identifier."; 1143 } 1144 leaf endpoint-id { 1145 type leafref { 1146 path "/network-slices/network-slice[ns-id=current()"+ 1147 "/../../../../../ns-id]/endpoints/endpoint/"+ 1148 "endpoint-id"; 1149 } 1150 description 1151 "Relative reference to TP id."; 1152 } 1153 } 1154 } 1155 list link { 1156 key "link-id"; 1157 description 1158 "Link identifier."; 1159 leaf link-id { 1160 type inet:uri; 1161 description 1162 "Link identifier."; 1163 } 1164 uses link-slo; 1165 container source { 1166 description 1167 "Link source node"; 1168 leaf source-node { 1169 type leafref { 1170 path "../../../node/node-id"; 1171 } 1172 description 1173 "Source node identifier, must be in same topology."; 1174 } 1175 leaf source-tp { 1176 type leafref { 1177 path "../../../node[node-id=current()/../"+ 1178 "source-node]/termination-point/tp-id"; 1179 } 1180 description 1181 "Termination point within source node that terminates 1182 the link."; 1183 } 1184 } 1185 container destination { 1186 description 1187 "Link destination node"; 1188 leaf dest-node { 1189 type leafref { 1190 path "../../../node/node-id"; 1191 } 1192 description 1193 "Destination node identifier, must be in same 1194 topology."; 1195 } 1196 leaf dest-tp { 1197 type leafref { 1198 path "../../../node[node-id=current()/../"+ 1199 "dest-node]/termination-point/tp-id"; 1200 } 1201 description 1202 "Termination point within destination node that 1203 terminates the link."; 1204 } 1205 } 1206 } 1207 } 1209 /* 1210 * Configuration data nodes 1211 */ 1212 container network-slices { 1213 description 1214 "Generic network slice configurations"; 1215 list network-slice { 1216 key "ns-id"; 1217 description 1218 "Network slice identifier"; 1219 leaf ns-id { 1220 type string; 1221 description 1222 "A unique network slice identifier across a slice 1223 controller"; 1224 } 1225 uses ns-generic-info; 1226 uses ns-slo; 1228 container endpoints { 1229 description 1230 "Endpoints of a network slice"; 1232 list endpoint { 1233 key "endpoint-id"; 1234 description 1235 "List of endpoints"; 1236 leaf endpoint-id { 1237 type string; 1238 description 1239 "Endpoint identifier"; 1240 } 1241 } 1242 } 1243 container network-topologies { 1244 description 1245 "A network slice is described as a network topology"; 1247 list network-topology { 1248 key "topology-id"; 1249 description 1250 "List of network topologies"; 1251 leaf topology-id { 1252 type string; 1253 description 1254 "Topology identifier"; 1255 } 1256 uses network-topology-def; 1257 } 1258 } 1259 container connectivity-matrices { 1260 description 1261 "Connectivity matrices"; 1263 list connectivity-matrix { 1264 key "connectivity-matrix-id"; 1265 description 1266 "List of connectivity matrix entities"; 1267 leaf connectivity-matrix-id { 1268 type uint32; 1269 description 1270 "Connectivity matrix identifier"; 1271 } 1272 leaf topology-id { 1273 type leafref { 1274 path "../../../network-topologies/network-topology"+ 1275 "/topology-id"; 1276 } 1277 description 1278 "Relative reference to network topology id."; 1279 } 1280 leaf src-endpoint { 1281 type leafref { 1282 path "../../../endpoints/endpoint/endpoint-id"; 1283 } 1284 description 1285 "Relative reference to endpoint id."; 1286 } 1287 leaf dst-endpoint { 1288 type leafref { 1289 path "../../../endpoints/endpoint/endpoint-id"; 1290 } 1291 description 1292 "Relative reference to endpoint id."; 1293 } 1294 uses connectivity-matrix-entry-slo; 1295 uses explicit-path; 1296 } //connectivity-matrix 1297 } //connectivity-matrices 1298 } //network-slice 1299 } //network slices 1300 } 1301 1303 Figure 7: YANG model for transport network slice 1305 4.2.4. NBI YANG Model Tree for OTN slice 1307 TBD. 1309 4.2.5. NBI YANG Code for OTN Slice 1311 TBD. 1313 5. Manageability Considerations 1315 To ensure the security and controllability of physical resource 1316 isolation, slice-based independent operation and management are 1317 required to achieve management isolation. Each optical slice 1318 typically requires dedicated accounts, permissions, and resources for 1319 independent access and O&M. This mechanism is to guarantee the 1320 information isolation among slice tenants and to avoid resource 1321 conflicts. The access to slice management functions will only be 1322 permitted after successful security checks. 1324 6. Security Considerations 1326 The YANG module specified in this document defines a schema for data 1327 that is designed to be accessed via network management protocols such 1328 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1329 is the secure transport layer, and the mandatory-to-implement secure 1330 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1331 is HTTPS, and the mandatory-to-implement secure transport is TLS 1332 [RFC8446]. 1334 The NETCONF access control model [RFC8341] provides the means to 1335 restrict access for particular NETCONF or RESTCONF users to a 1336 preconfigured subset of all available NETCONF or RESTCONF protocol 1337 operations and content. 1339 There are a number of data nodes defined in this YANG module that are 1340 writable/creatable/deletable (i.e., config true, which is the 1341 default). These data nodes may be considered sensitive or vulnerable 1342 in some network environments. Write operations (e.g., edit-config) 1343 to these data nodes without proper protection can have a negative 1344 effect on network operations. Considerations in Section 8 of 1345 [RFC8795] are also applicable to their subtrees in the module defined 1346 in this document. 1348 Some of the readable data nodes in this YANG module may be considered 1349 sensitive or vulnerable in some network environments. It is thus 1350 important to control read access (e.g., via get, get-config, or 1351 notification) to these data nodes. Considerations in Section 8 of 1352 [RFC8795] are also applicable to their subtrees in the module defined 1353 in this document. 1355 7. IANA Considerations 1357 It is proposed to IANA to assign new URIs from the "IETF XML 1358 Registry" [RFC3688] as follows: 1360 URI: urn:ietf:params:xml:ns:yang:ietf-transport-network-slice 1361 Registrant Contact: The IESG 1362 XML: N/A; the requested URI is an XML namespace. 1364 URI: urn:ietf:params:xml:ns:yang:ietf-otn-slice 1365 Registrant Contact: The IESG 1366 XML: N/A; the requested URI is an XML namespace. 1368 This document registers a YANG module in the YANG Module Names 1369 registry [RFC6020]. 1371 name: ietf-transport-network-slice 1372 namespace: urn:ietf:params:xml:ns:yang:ietf-transport-network-slice 1373 prefix: tns 1374 reference: RFC XXXX 1376 name: ietf-otn-slice 1377 namespace: urn:ietf:params:xml:ns:yang:ietf-otn-slice 1378 prefix: otnslice 1379 reference: RFC XXXX 1381 8. Normative References 1383 [GSMA-NS-Template] 1384 GSMA Association, "Generic Network Slice Template, Version 1385 5.0", NG.116 , June 2021, . 1388 [I-D.draft-contreras-teas-slice-controller-models] 1389 Contreras, L. M., Rokui, R., Tantsura, J., Wu, B., Liu, 1390 X., Dhody, D., and S. Belloti, "IETF Network Slice 1391 Controller and its associated data models", Work in 1392 Progress, Internet-Draft, draft-contreras-teas-slice- 1393 controller-models-01, 22 February 2021, 1394 . 1397 [I-D.ietf-ccamp-layer1-types] 1398 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 1399 Types", Work in Progress, Internet-Draft, draft-ietf- 1400 ccamp-layer1-types-11, 7 September 2021, 1401 . 1404 [I-D.ietf-ccamp-otn-topo-yang] 1405 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. 1406 Dios, "A YANG Data Model for Optical Transport Network 1407 Topology", Work in Progress, Internet-Draft, draft-ietf- 1408 ccamp-otn-topo-yang-13, 12 July 2021, 1409 . 1412 [I-D.ietf-teas-ietf-network-slices] 1413 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 1414 Makhijani, K., Contreras, L. M., and J. Tantsura, 1415 "Framework for IETF Network Slices", Work in Progress, 1416 Internet-Draft, draft-ietf-teas-ietf-network-slices-06, 3 1417 March 2022, . 1420 [I-D.ietf-teas-yang-te] 1421 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 1422 and O. G. D. Dios, "A YANG Data Model for Traffic 1423 Engineering Tunnels, Label Switched Paths and Interfaces", 1424 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 1425 29, 7 February 2022, . 1428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1429 Requirement Levels", BCP 14, RFC 2119, 1430 DOI 10.17487/RFC2119, March 1997, 1431 . 1433 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1434 DOI 10.17487/RFC3688, January 2004, 1435 . 1437 [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 1438 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, 1439 April 2007, . 1441 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1442 the Network Configuration Protocol (NETCONF)", RFC 6020, 1443 DOI 10.17487/RFC6020, October 2010, 1444 . 1446 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1447 and A. Bierman, Ed., "Network Configuration Protocol 1448 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1449 . 1451 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1452 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1453 . 1455 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1456 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1457 . 1459 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1460 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1461 . 1463 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1464 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1465 . 1467 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1468 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1469 May 2017, . 1471 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1472 Access Control Model", STD 91, RFC 8341, 1473 DOI 10.17487/RFC8341, March 2018, 1474 . 1476 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1477 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1478 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1479 2018, . 1481 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1482 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1483 . 1485 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1486 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1487 DOI 10.17487/RFC8453, August 2018, 1488 . 1490 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1491 "Common YANG Data Types for Traffic Engineering", 1492 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1493 . 1495 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1496 O. Gonzalez de Dios, "YANG Data Model for Traffic 1497 Engineering (TE) Topologies", RFC 8795, 1498 DOI 10.17487/RFC8795, August 2020, 1499 . 1501 [TS.28.530-3GPP] 1502 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1503 V15.1.0 Technical Specification Group Services and System 1504 Aspects; Management and orchestration; Concepts, use cases 1505 and requirements (Release 15)", 3GPP TS 28.530 , December 1506 2018, . 1509 Acknowledgments 1511 This document was prepared using kramdown. 1513 Previous versions of this document were prepared using 2-Word- 1514 v2.0.template.dot. 1516 The authors would like to thank Adrian Farrel, Danielle Ceccarelli, 1517 Igor Bryskin, Bo Wu, Gyan Mishra, Joel M. Halpen, Dhruv Dhoddy and 1518 Loa Andersson for providing valuable insights. 1520 Contributors 1522 Haomian Zheng 1523 Huawei Technologies 1524 H1, Xiliu Beipo Village, Songshan Lake 1525 Dongguan 1526 China 1527 Email: zhenghaomian@huawei.com 1529 Italo Busi 1530 Huawei Technologies 1531 Email: italo.busi@huawei.com 1532 Oscar Gonzalez de Dios 1533 Telefonica 1534 Email: oscar.gonzalezdedios@telefonica.com 1536 Victor Lopez 1537 Nokia 1538 Email: victor.lopez@nokia.com 1540 Dieter Beller 1541 Nokia 1542 Email: Dieter.Beller@nokia.com 1544 Henry Yu 1545 Huawei Technologies Canada 1546 Email: henry.yu@huawei.com 1548 Jiang Sun 1549 China Mobile 1550 Email: sunjiang@chinamobile.com 1552 Authors' Addresses 1554 Aihua Guo 1555 Futurewei Technologies 1556 Email: aihuaguo.ietf@gmail.com 1558 Luis M. Contreras 1559 Telefonica 1560 Email: luismiguel.contrerasmurillo@telefonica.com 1562 Sergio Belotti 1563 Nokia 1564 Email: Sergio.belotti@nokia.com 1566 Reza Rokui 1567 Ciena 1568 Email: rrokui@ciena.com 1569 Yunbin Xu 1570 CAICT 1571 Email: xuyunbin@caict.ca.cn 1573 Yang Zhao 1574 China Mobile 1575 Email: zhaoyangyjy@chinamobile.com 1577 Xufeng Liu 1578 IBM Corporation 1579 Email: xufeng.liu.ietf@gmail.com