idnits 2.17.1 draft-contreras-teas-slice-controller-models-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-06 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-01 == Outdated reference: A later version (-02) exists of draft-nsdt-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 == Outdated reference: A later version (-05) exists of draft-wd-teas-ietf-network-slice-nbi-yang-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational R. Rokui 5 Expires: May 6, 2021 Nokia 6 J. Tantsura 7 Apstra 8 B. Wu 9 Huawei 10 X. Liu 11 Volta 12 D. Dhody 13 Huawei 14 S. Belloti 15 Nokia 16 November 2, 2020 18 IETF Network Slice Controller and its associated data models 19 draft-contreras-teas-slice-controller-models-00 21 Abstract 23 This document describes the major functional components of an IETF 24 Network Slice Controller (NSC) as well as references the data models 25 required for supporting the requests of IETF network slices and their 26 realization. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 6, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. IETF Network Slice data models . . . . . . . . . . . . . . . 3 64 3. Structure of the IETF Network Slice Controller (NSC) . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Editor's Note: the terminology in this draft will be aligned with the 73 final terminology selected for describing the notion of IETF Network 74 Slice when applied to IETF technologies, which is currently under 75 discussion. By now same terminology as used in 76 [I-D.nsdt-teas-ietf-network-slice-definition] and 77 [I-D.nsdt-teas-ns-framework] is primarily used here. Consensus to 78 use "IETF Network Slice" term has been reached. 80 The generic idea of network slicing intends to provide tailored end- 81 to-end network capabilities to customers in the way that they could 82 be perceived as a dedicated network, despite the fact that it makes 83 use of shared physical infrastructure facilities. 85 Among the capabilities mentioned, connectivity of different parts of 86 a network slice with particular characteristics play a central role. 87 Thus, the concept of IETF Network Slice, realized by any of the IETF 88 technologies, emerges as complementary but essential part of an end- 89 to-end network slice. 91 In order to facilitate the request, realization and lifecycle control 92 and management of a transport slice, a new element named IETF Network 93 Slice Controller (NSC) is being proposed in 94 [I-D.nsdt-teas-ietf-network-slice-definition] and 95 [I-D.nsdt-teas-ns-framework]. 97 The NSC from its North Bound Interface (NBI) exposes set of APIs that 98 allow a higher level system to request an end-to-end transport slice. 99 It receives the request of enablement of an IETF Network Slice by a 100 customer (i.e. creation, modification or deletion). Upon receiving a 101 request from its NBI, NSC finds the resources needed for realization 102 of the IETF Network Slice and in turn interfaces from its South Bound 103 Interface (SBI) with one or more Network Controllers for the 104 realization of the requested IETF Network Slice request and the 105 management of its lifecycle. Figure 1 presents a high-level view of 106 the TSC. 108 +------------------------------------------+ 109 | A higher level system | 110 | (e.g E2E network slice orchestrator) | 111 +------------------------------------------+ 112 A 113 | NSC NBI 114 V 115 +------------------------------------------+ 116 | IETF Network Slice Controller (NSC) | 117 +------------------------------------------+ 118 A 119 | NSC SBI 120 V 121 +------------------------------------------+ 122 | Network Controller(s) | 123 +------------------------------------------+ 125 Figure 1: Interface of Transport Slice Controller 127 This memo describes the characteristics of the NSC as well as a 128 detailed structure of the NSC and its major components. In addition, 129 it describes the characteristics of the data models to identify the 130 IETF Network Slice and its realization. Then the data models 131 referred are mapped to the interfaces among components. 133 2. IETF Network Slice data models 135 At the time of provisioning and operating IETF Network Slices 136 different views can be identified as necessary: 138 o Customer's view, mostly focused on the individual IETF Network 139 Slice request process, reflecting the needs of each particular 140 customer, including SLOs and other characteristics of the slice 141 relevant for it. This view is technology agnostics and describes 142 the characteristics of the IETF Network Slice from a customer's 143 point of view. It can include the slice topology, performance 144 parameters, endpoints of the slice, traffic characteristics of the 145 slice, and the KPIs to monitor the slice. 147 o Provider's view, mostly focused on the provisioning and operation 148 of the IETF Network Slices in the transport network, considering 149 how a particular IETF Network Slice interplays with other IETF 150 Network Slices maintained by the provider on a shared 151 infrastructure. In other words, operator's view shows how an IETF 152 Network Slice is realized in operator's network along with all the 153 resources used during the its realization. 155 Both views are complementary, each of them specialized for a given 156 purpose. In consequence, it should be consistency between both in 157 order to ensure alignment. 159 Currently there are two different models proposed, on for each of the 160 categories above. The model in 161 [I-D.wd-teas-ietf-network-slice-nbi-yang] fits into the customer 162 view, while the model defined in 163 [I-D.liu-teas-transport-network-slice-yang] fits in to the provider 164 view. 166 It should be noted that for the realization of a transport slice, the 167 NSC interacts with one or more Network Controllers. In that case, 168 the data models to be used are particular for each Network Controller 169 (e.g., technology dependent), as well as the mapping function from 170 its NBI to SBI and the details of this mapping function are both out 171 of the scope of this document. 173 3. Structure of the IETF Network Slice Controller (NSC) 175 The NSC should work with both data models. The NSC takes first the 176 customer's view by analyzing the needs of the customer, processing 177 such requests taking into account the overall view of the network and 178 the IETF Network Slices already instantiated, normalizing its 179 instantiation across different technologies, and finally generates 180 the provider view. 182 Once the new request is processed and declared as feasible, the NSC 183 triggers its realization by interacting with the Network Controllers 184 and communicates back to the higher level controller to start the 185 billing cycle. 187 In order to accommodate these procedures, the internal structure of 188 the NSC can be divided into: 190 o IETF Network Slice Mapper: this high-level component processes the 191 customer request, putting it into the context of the overall IETF 192 Network Slices in the network. 194 o IETF Network Slice Realizer: this high-level component processes 195 the complete view of transport slices including the one requested 196 by the customer, decides the proper technologies for realizing the 197 IETF Network Slice and triggers its realization. 199 Figure 2 illustrates the components described and the associated 200 models, as follows 202 o (a) -> customer's view, e.g. 203 [I-D.wd-teas-ietf-network-slice-nbi-yang]. 205 o (b) -> provider's view, e.g. 206 [I-D.liu-teas-transport-network-slice-yang]. 208 o (c) -> models per network controller, out of scope of this 209 document 210 Higher Level System 211 | 212 | 213 --------------------------- 214 | NSC | (a) | 215 | v | 216 | ------------------- | 217 | | | | 218 | | NS Mapper | | 219 | | | | 220 | ------------------- | 221 | | (b) | 222 | v | 223 | ------------------- | 224 | | | | 225 | | NS Realizer | | 226 | | | | 227 | ------------------- | 228 | | (c) | 229 --------------------------- 230 | 231 v 232 Network Controllers 234 Figure 2: IETF Network Slice Controller structure and asspociated 235 data models 237 TODO item #1 - Breakdown "NS mapper" and "NS Realizer" to their 238 logical components. 240 TODO item #2- Add complementarity of the models for satisfying Type 1 241 and Type 2 Services as per [RFC8453]. Discussion: equivalent to the 242 Virtual Network (VN) described in [RFC8453], there are two views of 243 an IETF network slices as well: 245 o The IETF network slice can be abstracted as a set of edge-to-edge 246 links (Type 1). 248 o The IETF network slice can be abstracted as a topology of virtual 249 nodes and virtual links (Type 2) which represent the partitioning 250 of underlay network resources for use by network slice 251 connectivity. 253 The use cases of these two types of networks are further described by 254 [RFC8453]. [I-D.wd-teas-ietf-network-slice-nbi-yang] models the Type 255 1 service, while [I-D.liu-teas-transport-network-slice-yang] models 256 the Type 2 service. When a customer intends to request a Type 2 257 service, [I-D.liu-teas-transport-network-slice-yang] can also be used 258 at the point (a) in Figure 2. As an example, when ACTN is used to 259 realize an IETF network slice, model mappings are described in more 260 details in [I-D.ietf-teas-actn-yang]. 262 4. Security Considerations 264 To be done. 266 5. IANA Considerations 268 This draft does not include any IANA considerations 270 6. References 272 [I-D.ietf-teas-actn-yang] 273 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 274 Shin, J., and S. Belotti, "Applicability of YANG models 275 for Abstraction and Control of Traffic Engineered 276 Networks", draft-ietf-teas-actn-yang-06 (work in 277 progress), August 2020. 279 [I-D.liu-teas-transport-network-slice-yang] 280 Liu, X., Tantsura, J., Bryskin, I., Contreras, L., WU, Q., 281 Belotti, S., and R. Rokui, "Transport Network Slice YANG 282 Data Model", draft-liu-teas-transport-network-slice- 283 yang-01 (work in progress), July 2020. 285 [I-D.nsdt-teas-ietf-network-slice-definition] 286 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 287 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 288 teas-ietf-network-slice-definition-00 (work in progress), 289 October 2020. 291 [I-D.nsdt-teas-ns-framework] 292 Gray, E. and J. Drake, "Framework for Transport Network 293 Slices", draft-nsdt-teas-ns-framework-04 (work in 294 progress), July 2020. 296 [I-D.wd-teas-ietf-network-slice-nbi-yang] 297 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data 298 Model for IETF Network Slice NBI", draft-wd-teas-ietf- 299 network-slice-nbi-yang-00 (work in progress), October 300 2020. 302 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 303 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 304 DOI 10.17487/RFC8453, August 2018, 305 . 307 Authors' Addresses 309 Luis M. Contreras 310 Telefonica 311 Ronda de la Comunicacion, s/n 312 Sur-3 building, 3rd floor 313 Madrid 28050 314 Spain 316 Email: luismiguel.contrerasmurillo@telefonica.com 317 URI: http://lmcontreras.com/ 319 Reza Rokui 320 Nokia 321 Canada 323 Email: reza.rokui@nokia.com 325 Jeff Tantsura 326 Apstra 327 USA 329 Email: jefftant.ietf@gmail.com 331 Bo Wu 332 Huawei Technologies 333 101 Software Avenue, Yuhua District 334 Nanjing, Jiangsu 210012 335 China 337 Email: lana.wubo@huawei.com 339 Xufeng Liu 340 Volta Networks 342 Email: xufeng.liu.ietf@gmail.com 343 Dhruv Dhody 344 Huawei Technologies 345 Divyashree Techno Park 346 Bangalore, Karnataka 560066 347 India 349 Email: dhruv.ietf@gmail.com 351 Sergio Belloti 352 Nokia 354 Email: sergio.belotti@nokia.com