idnits 2.17.1 draft-nsdt-teas-ns-framework-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 -- The document date (20 March 2020) is 1498 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-nsdt-teas-transport-slice-definition-01 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-05 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-05 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Gray, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational J. Drake, Ed. 5 Expires: 21 September 2020 Juniper Networks 6 20 March 2020 8 Framework for Transport Network Slices 9 draft-nsdt-teas-ns-framework-01 11 Abstract 13 This memo discusses setting up special-purpose transport connections 14 using existing IETF technologies. These connections are called 15 transport slices for the purposes of this memo. The memo discusses 16 the general framework for this setup, the necessary system components 17 and interfaces, and how abstract requests can be mapped to more 18 specific technologies. The memo also discusses related 19 considerations with monitoring and security. 21 This memo is intended for discussing interfaces and technologies. It 22 is not intended to be a new set of concrete interfaces or 23 technologies. Rather, it should be seen as an explanation of how 24 some existing, concrete IETF VPN and traffic-engineering technologies 25 can be used to create transport slices. Note that there are is a 26 rather large of these technologies, and new technologies or 27 capabilities keep being added. This memo is also not intended 28 presume any particular technology choice. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 21 September 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Management systems or other applications . . . . . . . . 5 67 3.2. Expressing connectivity intents . . . . . . . . . . . . . 6 68 3.3. Transport Slice Controller (TSC) . . . . . . . . . . . . 8 69 3.3.1. Northbound Inteface (NBI) . . . . . . . . . . . . . . 9 70 3.4. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.5. Underlying technology . . . . . . . . . . . . . . . . . . 9 72 4. Applicability of ACTN to Transport Slices . . . . . . . . . . 10 73 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Security Considerations . . . . . . . . . . . . . . . . . 12 76 5.3. Privacy Considerations . . . . . . . . . . . . . . . . . 12 77 5.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 7.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 This draft provides a framework for discussing transport slices, as 88 defined in [I-D.nsdt-teas-transport-slice-definition] (to be replaced 89 by draft-rokui-teas-transport-slice-definition). It is the intention 90 in this document to use terminology consistent with this and other 91 definitions provided in that draft. 93 In particular, this document uses the following terminology defined 94 in the defintions document: - Transport Slice - Transport Slice 95 Controller (TSC) - Transport Network Controller (TNC) - Nothrbound 96 Interface (NBI) - Southbound Interface (SBI) 98 This framework is intended as a structure for discussing interfaces 99 and technologies. It is not intended to be a new set of concrete 100 interfaces or technologies. Rather, the idea is that existing or 101 under-development IETF technologies (plural) can be used to realize 102 the ideas expressed here. 104 For example, virtual private networks (VPNs) have served the industry 105 well as a means of providing different groups of users with logically 106 isolated access to a common network. The common or base network that 107 is used to provide the VPNs is often referred to as an underlay 108 network, and the VPN is often called an overlay network. As an 109 example technology, a VPN may in turn serve as an underlay network 110 for transport slices. 112 Note: It is conceivable that extensions to these IETF technologies 113 are needed in order to fully support all the ideas that can be 114 implemented with slices, but at least in the beginning there is no 115 plan for the creation of new protocols or interfaces. 117 Driven largely by needs surfacing from 5G, the concept of network 118 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 119 and [BBF-SD406]). In [TS23501], Network Slice is defined as "a 120 logical network that provides specific network capabilities and 121 network characteristics", and a Network Slice Instance is defined as 122 "A set of Network Function instances and the required resources (e.g. 123 compute, storage and networking resources) which form a deployed 124 Network Slice". According to [TS28530], an end-to-end network slice 125 consists of three major types of network segments: Radio Access 126 Network (RAN), Transport Network (TN) and Core Network (CN). 127 Transport network provides the required connectivity between 128 different entities in RAN and CN segments of an end-to-end network 129 slice, with a specific performance commitment. For each end-to-end 130 network slice, the topology and performance requirement on transport 131 network can be very different, which requires the transport network 132 to have the capability of supporting multiple different transport 133 slices. 135 While network slices are commonly discussed in the context of 5G, it 136 is important to note that transport slices are a narrower concept, 137 and focus primarily on particular network connectivity aspects. 138 Other systems, including 5G deployments, may use transport slices as 139 a component to create entire systems and concatenated constructs that 140 match their needs, including end-to-end connectivity. 142 A Transport Slice could span multiple technologies and multiple 143 administrative domains. Depending on the consumer's requirements, a 144 transport slice could be isolated from other, often concurrent 145 transport slices in terms of data, control and management planes. 147 The consumer expresses requirements for a particular transport slice 148 by specifying what is required rather than how the requirement is to 149 be fulfilled. That is, the Transport Slice consumer's view of a 150 transport slice is an abstract one. 152 Thus, there is a need to create logical network structures with 153 required characteristics. The consumer of such a logical network can 154 require a degree of isolation and performance that previously might 155 not have been satisfied by traditional overlay VPNs. Additionally, 156 the transport slice consumer might ask for some level of control of 157 their virtual networks, e.g., to customize the service paths in a 158 network slice. 160 This document specifies a framework for the use of existing 161 technologies as components to provide a transport slice service, and 162 might also discuss (or reference) modified and potential new 163 technologies, as they develop (such as candidate technologies 164 described in section 5 of [I-D.ietf-teas-enhanced-vpn]). 166 2. Requirements 168 It is intended that transport slices can be created to meet specific 169 requirements, typically expressed as bandwidth, latency, latency 170 variation, and other desired or required characteristics. Creation 171 is initiated by a management system or other application used to 172 specify network-related conditions for particular traffic flows. 174 And it is intended that, once created, these slices can be monitored, 175 modified, deleted, and otherwise managed. 177 It is also intended that applications and components will be able to 178 use these transport slices to move packets between the specified end- 179 points in accordance with specified characteristics. 181 As an example of additional requirements that might apply to 182 transport slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, 183 section 3). 185 3. Framework 187 A number of transport slice services will typically be provided over 188 a shared underlying network infrastructure. Each transport slice 189 consists of both the overlay connectivity and a specific set of 190 dedicated network resources and/or functions allocated in a shared 191 underlay network to satisfy the needs of the transport slice 192 consumer. In at least some examples of underlying network 193 technologies, the integration between the overlay and various 194 underlay resources is needed to ensure the guaranteed performance 195 requested for different transport slices. 197 ** Align with definitions draft ** 199 The users of transport slices are: 201 * The management system or other application that creates and 202 manages them. 204 * The applications and components wishing to use these slices. 206 Transport users are served by the system that can build transport 207 slices, as follows: 209 * A controller takes requests from a management system or other 210 application, which are then communicated via an abstracted 211 northbound interface. This interface transmits data objects that 212 describe the needed transport slices in terms of topology and 213 service level objectives (SLO). 215 * These requests are assumed to be translated by one or more 216 underlying systems, which establish specific transport slice 217 instances, using specific implementation techniques (such as IP 218 and MPLS) implemented on top of the underlying network 219 infrastructure. 221 Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example 222 architecture that might apply in using the technology described in 223 that document. 225 3.1. Management systems or other applications 227 The transport slice system is used by a management system or other 228 application. These systems and applications may also be a part of a 229 higher level function in the system, e.g., putting together network 230 functions, access equipment, application specific components, as well 231 as the transport slices. 233 3.2. Expressing connectivity intents 235 The Transport Slice Controller (TSC) northbound interface (NBI) can 236 be used to communicate between transport slice users (or consumers) 237 and the TSC. 239 A transport slice user may be a network operator who, in turn, 240 provides the transport slice to another transport slice user or 241 consumer. 243 Using the NBI, a consumer expresses requirements for a particular 244 slice by specifying what is required rather than how that is to be 245 achieved. That is, the consumer's view of a slice is an abstract 246 one. Consumers normally have limited (or no) visibility into the 247 provider network's actual topology and resource availability 248 information. 250 This should be true even if both the consumer and provider are 251 associated with a single administrative domain, in order to reduce 252 the potential for adverse interactions between transport slice 253 consumers and other uses/users of the transport network 254 infrastructure. 256 The benefits of this model can include: 258 * Security: because the transport network (or network operator) does 259 not need to expose network details (topology, capacity, etc.) to 260 transport slice consumers the transport network components are 261 less exposed to attack; 263 * Layered Implementation: the transport network comprises network 264 elements that belong to a different layer network than consumer 265 applications, and network information (advertisements, protocols, 266 etc.) that a consumer cannot interpret or respond to (note - a 267 consumer should not use network information not exposed via the 268 TSC NBI, even if that information is available); 270 * Scalability: consumers do not need to know any information beyond 271 that which is exposed via the NBI. 273 The general issues of abstraction in a TE network is described more 274 fully in [RFC7926]. 276 This framework document does not assume any particular layer at which 277 transport slices operate as a number of layers (including virtual L2, 278 Ethernet or IP connectivity) could be employed. 280 Data models and interfaces are of course needed to set up transport 281 slices, and specific interfaces may have capabilities that allow 282 creation of specific layers. 284 Layered virtual connections are comprehensively discussed in IETF 285 documents and are widely supported. See, for instance, GMPLS-based 286 networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8353] and 287 [RFC8353]). The principles and mechanisms associated with layered 288 networking are applicable to transport slices. 290 There are several IETF-defined mechanisms for expressing the need for 291 a desired logical network. The NBI carries data either in a 292 protocol-defined format, or in a formalism associated with a modeling 293 language. 295 For instance: 297 * Path Computation Element (PCE) Communication Protocol (PCEP) 298 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 299 [RFC4208] use a TLV-based binary encoding to transmit data. 301 * Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 302 Protocol [RFC8040] use XML abnd JSON encoding. 304 * gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 305 programmable interface; 307 * SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding 308 (ASN.1). 310 * For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 311 model configuration and other data for NETCONF, RESTCONF, and GNMI 312 - among others; ProtoBufs can be used to model gRPC and GNMI data; 313 Structure of Management Information (SMI) [RFC2578] may be used to 314 define Management Information Base (MIB) modules for SNMP, using 315 an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 316 1988). 318 While several generic formats and data models for specific purposes 319 exist, it is expected that transport slice management may require 320 enhancement or augmentation of existing data models. 322 3.3. Transport Slice Controller (TSC) 324 The transport slice controller takes abstract requests for transport 325 slices and implements them using a suitable underlying technology. A 326 transport slice controller is the key building block for control and 327 management of the transport slice. It provides the 328 creation/modification/deletion, monitoring and optimization of 329 transport Slices in a multi-domain, a multi-technology and multi- 330 vendor environment. 332 A TSC northbound interface (NBI) is needed for communicating details 333 of a transport slice, as well as providing information to a slice 334 requester/consumer about transport slice status and performance. The 335 details for this NBI are not in scope for this document. 337 The controller provides the following functions: 339 * Provides a technology-agnostic NBI for creation/modification/ 340 deletion of the transport slices. The API exposed by this NBI 341 communicates the endpoints of the transport slice, transport slice 342 SLO parameters (and possibly monitoring thresholds), applicable 343 input selection (filtering) and various policies, and provides a 344 way to monitor the slice. 346 * Determines an abstract topology connecting the endpoints of the 347 transport slice that meets criteria specified via the NBI.The TSC 348 also retains information about the mapping of this abstract 349 topology to underlying components of the transport slice as 350 necessary to monitor transport slice status and performance. 352 * Provides "Mapping Functions" for the realization of transport 353 slices. In other words, it will use the mapping functions that: 355 map technology-agnostic NBI request to technology-specific SBIs. 357 map filtering/selection information as necessary to entities in 358 the underlay network. 360 * Via an SBI, the controller collects Telemetry data (e.g. OAM 361 results, Statistics, States etc.) for all elements in the abstract 362 topology used to realize the transport slice. 364 * Using the Telemetry data from the underlying realization of a 365 transport slice (i.e. services/paths/tunnels), evaluates the 366 current performance against transport slice SLO parameters and 367 exposes them to the transport slice consumer via the NBI. The TSC 368 NBI may also include a capability to provide notification in case 369 the transport slice performance reaches threshold values defined 370 by the transport slice consumer. 372 3.3.1. Northbound Inteface (NBI) 374 The Transport Slice Controller provides a Northbound Interface (NBI) 375 that allows consumers of network slices to request and monitor 376 transport slices. Consumers operate on abstract transport slices, 377 with details related to their realization hidden. 379 The NBI complements various IETF services, tunnels, path models by 380 providing an abstract layer on top of these models. 382 The NBI is independent of type of network functions or services that 383 need to be connected, i.e. it is independent of any specific storage, 384 software, protocol, or platform used to realize physical or virtual 385 network connectivity or functions in support of transport slices. 387 The NBI uses protocol mechanisms and information passed over passed 388 over those mechanisms to convey desired attributes for transport 389 slices and their status. The information is expected to be 390 represented as a well-defined data model, and should include at least 391 endpoint and connectivity information, SLO specification, and status 392 information. 394 To accomplish this, the NBI needs to convey information needed to 395 support communication across the NBI, in terms of identifying the 396 transport slices, as well providing the above model information. 398 3.4. Mapping 400 The main task of the transport slice controller is to map abstract 401 transport slice requirements to concrete technologies and establish 402 the required connectivity, and ensuring that required resources are 403 allocated to the transport slice. 405 3.5. Underlying technology 407 There are a number of different technologies that can be used, 408 including physical connections, MPLS, TSN, Flex-E, etc. 410 See [I-D.ietf-teas-enhanced-vpn] - section 5 - for instance, for 411 example underlying technologies. 413 Also, as outlined in "applicability of ACTN to Transport Slices" 414 below, ACTN ([RFC8453]) offers a framework that is used elsewhere in 415 IETF specifications to create virtual network (VN) services similar 416 to Transport Slices. 418 A transport slice can be realized in a network, using specific 419 underlying technology or technologies. The creation of a new 420 transport slice will be initiated with following three steps: 422 * Step 1: A higher level system requests connections with specific 423 characteristics via NBI. 425 * Step 2: This request will be processed by a Transport Slice 426 Controller which specifies a mapping between northbound request to 427 any IETF Services, Tunnels, and paths models. 429 * Step 3: A series of requests for creation of services, tunnels and 430 paths will be sent to the network to realize the trasport slice. 432 It is very clear that regardless of how transport slice is realized 433 in the network (i.e. using tunnels of type RSVP or SR), the 434 definition of transport slice does not change at all but rather its 435 realization. 437 4. Applicability of ACTN to Transport Slices 439 [RFC8453] defined three controllers as per the framework for 440 Abstraction and Control of TE Networks (ACTN) to support virtual 441 network (VN) services - Customer Network Controller (CNC), Multi- 442 Domain Service Coordinator (MDSC) and Provisioning Network Controller 443 (PNC). A CNC is responsible for communicating a customer's virtual 444 network requirements, a MDSC is responsible for multi-domain 445 coordination, virtualization/abstraction, customer mapping/ 446 translation and virtual service coordination to realize the virtual 447 network requirement. Its key role is to detach the network/service 448 requirements from the underlying technology. A PNC oversees the 449 configuration, monitoring and collection of the network topology. 450 The PNC is a underlay technology specific controller. 452 While the ACTN framework is a generic VN framework that is used for 453 various VN service beyond the transport slice, it is still a suitable 454 based to understand how the various controllers interact to realize 455 the Transport slice. 457 A mapping between the Transport Slice definitions and ACTN 458 definitions is as shown in Figure 1 below. 460 ------------------------------------+ 461 | Customer | | 462 +------------------------------------+ 463 A | ACTN 464 | Terminology 465 V | and Concepts 466 +------------------------------------+ 467 | A highter level system | | 468 |(e.g e2e network slice orchestrator)| 469 +------------------------------------+ | 470 A 471 | TSC NBI | 472 V 473 +------------------------------------+ | +-----+ 474 | Transport Slice Controller | ===> | CNC | 475 +------------------------------------+ | +-----+ 476 A A 477 | TSC SBI | | CMI 478 V V 479 +------------------------------------+ | +-----+ 480 | Network Controller(s) | ===> |MDSC | 481 +------------------------------------+ | +-----+ 482 A 483 Terminology/Concepts | | MPI 484 Used in this Document V 485 | +-----+ 486 | PNC | 487 | +-----+ 489 Figure 1 491 The TSC NBI conveys the generic transport slice requirements. These 492 may then be realized using an SBI. 494 As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC 495 Interface (CMI) is used to convey the virtual network service 496 requirements along with the service models and the MDSC-PNC Interface 497 (MPI) is used to realize the service along network configuration 498 models. [I-D.ietf-teas-te-service-mapping-yang] further describe how 499 the VPN services can be mapped to the underlying TE resources. 501 The Transport Network Controller is depicted as a single block, where 502 as in the ACTN framework this has been decomposed into MDSC and PNC 503 to handle multiple domains and various underlay technologies. 505 [RFC8453] also describes TE Network Slicing in the context of ACTN as 506 a collection of resources that is used to establish a logically 507 dedicated virtual network over one or more TE networks. In case of 508 TE enabled underlying network, ACTN VN can be used as a base to 509 realize the transport network slicing by coordination among multiple 510 peer domains as well as underlay technology domains. 512 5. Considerations 514 5.1. Monitoring 516 Transport slice realization needs to be instrumented in order to 517 track how it is working, and it might be necessary to modify the 518 transport slice as requirements change. Dynamic reconfiguration 519 might be needed. 521 5.2. Security Considerations 523 Transport slices might use underlying virtualized networking. All 524 types of virtual networking require special consideration to be given 525 to the separation of traffic between distinct virtual networks, as 526 well as some degree of protection from effects of traffic use of 527 underlying network (and other) resources from other virtual networks 528 sharing those resources. 530 For example, if a service requires a specific upper bound of latency, 531 then that service can be degraded by added delay in transmission of 532 service packets through the activities of another service or 533 application using the same resources. 535 Similarly, in a network with virtual functions, noticeably impeding 536 access to a function used by another transport slice (for instance, 537 compute resources) can be just as service degrading as delaying 538 physical transmission of associated packet in the network. 540 While a transport slice might include encryption and other security 541 features as part of the service, consumers might be well advised to 542 take responsibility for their own security needs, possibly by 543 encrypting traffic before hand-off to a service provider. 545 5.3. Privacy Considerations 547 Privacy of transport nework slice service consumers must be 548 preserved. It should not be possible for one transport slice 549 consumer to discover the presence of other consumers, nor should 550 sites that are members of one transport slice be visible outside the 551 context of that transport slice. 553 In this sense, it is of paramount importance that the system use the 554 privacy protection mechanism defined for the specific underlying 555 technologies used, including in particular those mechanisms designed 556 to preclude acquiring identifying information associated with any 557 transport slice consumer. 559 5.4. IANA Considerations 561 There are no requests to IANA in this framework document. 563 6. Acknowledgments 565 The entire TEAS NS design team and everyone participating in related 566 discussions has contributed to this draft. Some text fragments in 567 the draft have been copied from the [I-D.ietf-teas-enhanced-vpn], for 568 which we are grateful. 570 Significant contributions to this document were gratefully received 571 from the contributing authors listed in the "Contributors" section. 572 In addition we would like to also thank those others who have 573 attended one or more of the design team meetings, including: 575 * Aihua Guo 577 * Bo Wu 579 * Greg Mirsky 581 * Jeff Tantsura 583 * Jie Dong 585 * Kiran Makhijani 587 * Lou Berger 589 * Luis M. Contreras 591 * Rakesh Gandhi 593 * Ren Chen 595 * Sergio Belotti 597 * Shunsuke Homma 599 * Stewart Bryant 601 * Tomonobu Niwa 603 * Xuesong Geng 604 * Xufeng Liu 606 7. References 608 7.1. Normative References 610 [I-D.nsdt-teas-transport-slice-definition] 611 Rokui, R., Homma, S., Makhijani, K., and L. Contreras, 612 "IETF Definition of Transport Slice", Work in Progress, 613 Internet-Draft, draft-nsdt-teas-transport-slice- 614 definition-01, 9 March 2020, . 618 7.2. Informative References 620 [BBF-SD406] 621 Broadband Forum, ., "End-to-end network slicing", BBF 622 SD-406 , n.d.. 624 [I-D.ietf-teas-actn-yang] 625 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 626 Shin, J., and S. Belotti, "Applicability of YANG models 627 for Abstraction and Control of Traffic Engineered 628 Networks", Work in Progress, Internet-Draft, draft-ietf- 629 teas-actn-yang-05, 19 February 2020, . 632 [I-D.ietf-teas-enhanced-vpn] 633 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 634 Framework for Enhanced Virtual Private Networks (VPN+) 635 Services", Work in Progress, Internet-Draft, draft-ietf- 636 teas-enhanced-vpn-05, 18 February 2020, 637 . 640 [I-D.ietf-teas-te-service-mapping-yang] 641 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 642 and J. Tantsura, "Traffic Engineering (TE) and Service 643 Mapping Yang Model", Work in Progress, Internet-Draft, 644 draft-ietf-teas-te-service-mapping-yang-03, 8 March 2020, 645 . 648 [I-D.openconfig-rtgwg-gnmi-spec] 649 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 650 C., and C. Morrow, "gRPC Network Management Interface 651 (gNMI)", Work in Progress, Internet-Draft, draft- 652 openconfig-rtgwg-gnmi-spec-01, 5 March 2018, 653 . 656 [NGMN-NS-Concept] 657 NGMN Alliance, ., "Description of Network Slicing 658 Concept", https://www.ngmn.org/uploads/ 659 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 660 2016. 662 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 663 Schoenwaelder, Ed., "Structure of Management Information 664 Version 2 (SMIv2)", STD 58, RFC 2578, 665 DOI 10.17487/RFC2578, April 1999, 666 . 668 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 669 "Message Processing and Dispatching for the Simple Network 670 Management Protocol (SNMP)", STD 62, RFC 3412, 671 DOI 10.17487/RFC3412, December 2002, 672 . 674 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 675 (USM) for version 3 of the Simple Network Management 676 Protocol (SNMPv3)", STD 62, RFC 3414, 677 DOI 10.17487/RFC3414, December 2002, 678 . 680 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 681 Network Management Protocol (SNMP)", STD 62, RFC 3417, 682 DOI 10.17487/RFC3417, December 2002, 683 . 685 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 686 "Generalized Multiprotocol Label Switching (GMPLS) User- 687 Network Interface (UNI): Resource ReserVation Protocol- 688 Traffic Engineering (RSVP-TE) Support for the Overlay 689 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 690 . 692 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 693 Interpretation of Generalized Multiprotocol Label 694 Switching (GMPLS) Terminology within the Context of the 695 ITU-T's Automatically Switched Optical Network (ASON) 696 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 697 2006, . 699 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 700 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 701 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 702 DOI 10.17487/RFC5212, July 2008, 703 . 705 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 706 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 707 DOI 10.17487/RFC5440, March 2009, 708 . 710 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 711 the Network Configuration Protocol (NETCONF)", RFC 6020, 712 DOI 10.17487/RFC6020, October 2010, 713 . 715 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 716 and A. Bierman, Ed., "Network Configuration Protocol 717 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 718 . 720 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 721 Ceccarelli, D., and X. Zhang, "Problem Statement and 722 Architecture for Information Exchange between 723 Interconnected Traffic-Engineered Networks", BCP 206, 724 RFC 7926, DOI 10.17487/RFC7926, July 2016, 725 . 727 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 728 RFC 7950, DOI 10.17487/RFC7950, August 2016, 729 . 731 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 732 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 733 . 735 [RFC8353] Upadhyay, M., Malkani, S., and W. Wang, "Generic Security 736 Service API Version 2: Java Bindings Update", RFC 8353, 737 DOI 10.17487/RFC8353, May 2018, 738 . 740 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 741 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 742 DOI 10.17487/RFC8453, August 2018, 743 . 745 [TS23501] 3GPP, ., "System architecture for the 5G System (5GS)", 746 3GPP TS 23.501 , 2019. 748 [TS28530] 3GPP, ., "Management and orchestration; Concepts, use 749 cases and requirements", 3GPP TS 28.530 , 2019. 751 Contributors 753 The following authors contributed significantly to this document: 755 Jari Arkko 756 Ericsson 758 Email: jari.arkko@piuha.net 760 Dhruv Dhody 761 Huawei, India 763 Email: dhruv.ietf@gmail.com 765 Reza Rokui 766 Nokia 768 Email: reza.rokui@nokia.com 770 Xufeng Liu 772 Email: xufeng.liu.ietf@gmail.com 774 Jie Dong 775 Huawei 777 Email: jie.dong@huawei.com 779 Authors' Addresses 781 Eric Gray (editor) 782 Ericsson 784 Email: eric.gray@ericsson.com 786 John Drake (editor) 787 Juniper Networks 789 Email: jdrake@juniper.net