idnits 2.17.1 draft-ietf-teas-ietf-network-slice-framework-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 : ---------------------------------------------------------------------------- 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 (8 March 2021) is 1135 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-06 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-05 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: 9 September 2021 Juniper Networks 6 8 March 2021 8 Framework for IETF Network Slices 9 draft-ietf-teas-ietf-network-slice-framework-00 11 Abstract 13 This memo discusses setting up special-purpose network connections 14 using existing IETF technologies. These connections are called IETF 15 network slices for the purposes of this memo. The memo discusses the 16 general framework for this setup, the necessary system components and 17 interfaces, and how abstract requests can be mapped to more specific 18 technologies. The memo also discusses related considerations with 19 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 IETF network slices. Note that there are a 26 number of these technologies, and new technologies or capabilities 27 keep being added. This memo is also not intended presume any 28 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 9 September 2021. 47 Copyright Notice 49 Copyright (c) 2021 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. IETF Network Slice Objectives . . . . . . . . . . . . . . . . 4 65 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Management systems or other applications . . . . . . . . 6 67 3.2. Expressing connectivity intents . . . . . . . . . . . . . 6 68 3.3. IETF Network Slice Controller (NSC) . . . . . . . . . . . 8 69 3.3.1. Northbound Interface (NBI) . . . . . . . . . . . . . 9 70 3.4. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.5. Underlying technology . . . . . . . . . . . . . . . . . . 9 72 4. Applicability of ACTN to IETF Network Slices . . . . . . . . 10 73 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Security Considerations . . . . . . . . . . . . . . . . . 13 76 5.3. Privacy Considerations . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 This draft provides a framework for discussing IETF network slices, 88 as defined in [I-D.ietf-teas-ietf-network-slice-definition] It is the 89 intention in this document to use terminology consistent with this 90 and other definitions provided in that draft. 92 In particular, this document uses the following terminology defined 93 in the definitions document: 95 * IETF Network Slice 97 * IETF Network Slice Controller (NSC) 99 * Network Controller (NC) 101 * Northbound Interface (NBI) 103 * Southbound Interface (SBI) 105 This framework is intended as a structure for discussing interfaces 106 and technologies. It is not intended to specify a new set of 107 concrete interfaces or technologies. Rather, the idea is that 108 existing or under-development IETF technologies (plural) can be used 109 to realize the concepts expressed herein. 111 For example, virtual private networks (VPNs) have served the industry 112 well as a means of providing different groups of users with logically 113 isolated access to a common network. The common or base network that 114 is used to provide the VPNs is often referred to as an underlay 115 network, and the VPN is often called an overlay network. As an 116 example technology, a VPN may in turn serve as an underlay network 117 for IETF network slices. 119 Note: It is conceivable that extensions to these IETF technologies 120 are needed in order to fully support all the ideas that can be 121 implemented with slices, but at least in the beginning there is no 122 plan for the creation of new protocols or interfaces. 124 Driven largely by needs surfacing from 5G, the concept of network 125 slicing has gained traction ([NGMN-NS-Concept], [TS23501], [TS28530], 126 and [BBF-SD406]). In [TS23501], Network Slice is defined as "a 127 logical network that provides specific network capabilities and 128 network characteristics", and a Network Slice Instance is defined as 129 "A set of Network Function instances and the required resources (e.g. 130 compute, storage and networking resources) which form a deployed 131 Network Slice". According to [TS28530], an end-to-end network slice 132 consists of three major types of network segments: Radio Access 133 Network (RAN), Transport Network (TN) and Core Network (CN). IETF 134 network slice provides the required connectivity between different 135 entities in RAN and CN segments of an end-to-end network slice, with 136 a specific performance commitment. For each end-to-end network 137 slice, the topology and performance requirement on a consumer's use 138 of IETF network slice can be very different, which requires the 139 underlay network to have the capability of supporting multiple 140 different IETF network slices. 142 While network slices are commonly discussed in the context of 5G, it 143 is important to note that IETF network slices are a narrower concept, 144 and focus primarily on particular network connectivity aspects. 145 Other systems, including 5G deployments, may use IETF network slices 146 as a component to create entire systems and concatenated constructs 147 that match their needs, including end-to-end connectivity. 149 A IETF network slice could span multiple technologies and multiple 150 administrative domains. Depending on the IETF network slice 151 consumer's requirements, an IETF network slice could be isolated from 152 other, often concurrent IETF network slices in terms of data, control 153 and management planes. 155 The consumer expresses requirements for a particular IETF network 156 slice by specifying what is required rather than how the requirement 157 is to be fulfilled. That is, the IETF network slice consumer's view 158 of a IETF network slice is an abstract one. 160 Thus, there is a need to create logical network structures with 161 required characteristics. The consumer of such a logical network can 162 require a degree of isolation and performance that previously might 163 not have been satisfied by traditional overlay VPNs. Additionally, 164 the IETF network slice consumer might ask for some level of control 165 of their virtual networks, e.g., to customize the service paths in a 166 network slice. 168 This document specifies a framework for the use of existing 169 technologies as components to provide a IETF network slice service, 170 and might also discuss (or reference) modified and potential new 171 technologies, as they develop (such as candidate technologies 172 described in section 5 of [I-D.ietf-teas-enhanced-vpn]). 174 2. IETF Network Slice Objectives 176 It is intended that IETF network slices can be created to meet 177 specific requirements, typically expressed as bandwidth, latency, 178 latency variation, and other desired or required characteristics. 179 Creation is initiated by a management system or other application 180 used to specify network-related conditions for particular traffic 181 flows. 183 And it is intended that, once created, these slices can be monitored, 184 modified, deleted, and otherwise managed. 186 It is also intended that applications and components will be able to 187 use these IETF network slices to move packets between the specified 188 end-points in accordance with specified characteristics. 190 As an example of requirements that might apply to IETF network 191 slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3). 193 3. Framework 195 A number of IETF network slice services will typically be provided 196 over a shared underlying network infrastructure. Each IETF network 197 slice consists of both the overlay connectivity and a specific set of 198 dedicated network resources and/or functions allocated in a shared 199 underlay network to satisfy the needs of the IETF network slice 200 consumer. In at least some examples of underlying network 201 technologies, the integration between the overlay and various 202 underlay resources is needed to ensure the guaranteed performance 203 requested for different IETF network slices. 205 IETF Network Slice Definition 206 ([I-D.ietf-teas-ietf-network-slice-definition]) defines the role of a 207 Customer (or User) and a IETF Network Slice Controller. That draft 208 also defines a NSC Northbound Interface (NBI). 210 A IETF network slice user is served by the IETF Network Slice 211 Controller (NSC), as follows: 213 * The NSC takes requests from a management system or other 214 application, which are then communicated via an NBI. This 215 interface carries data objects the IETF network slice user 216 provides, describing the needed IETF network slices in terms of 217 topology, applicable service level objectives (SLO), and any 218 monitoring and reporting requirements that may apply. Note that - 219 in this context - "topology" means what the IETF network slice 220 connectivity is meant to look like from the user's perspective; it 221 may be as simple as a list of mutually (and symmetrically) 222 connected end points, or it may be complicated by details of 223 connection asymmetry, per-connection SLO requirements, etc. 225 * These requests are assumed to be translated by one or more 226 underlying systems, which are used to establish specific IETF 227 network slice instances on top of an underlying network 228 infrastructure. 230 * The NSC maintains a record of the mapping from user requests to 231 slice instantiations, as needed to allow for subsequent control 232 functions (such as modification or deletion of the requested 233 slices), and as needed for any requested monitoring and reporting 234 functions. 236 Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example 237 architecture that might apply in using the technology described in 238 that document. 240 3.1. Management systems or other applications 242 The IETF network slice system is used by a management system or other 243 application. These systems and applications may also be a part of a 244 higher level function in the system, e.g., putting together network 245 functions, access equipment, application specific components, as well 246 as the IETF network slices. 248 3.2. Expressing connectivity intents 250 The IETF Network Slice Controller (NSC) northbound interface (NBI) 251 can be used to communicate between IETF network slice users (or 252 consumers) and the NSC. 254 A IETF network slice user may be a network operator who, in turn, 255 provides the IETF network slice to another IETF network slice user or 256 consumer. 258 Using the NBI, a consumer expresses requirements for a particular 259 slice by specifying what is required rather than how that is to be 260 achieved. That is, the consumer's view of a slice is an abstract 261 one. Consumers normally have limited (or no) visibility into the 262 provider network's actual topology and resource availability 263 information. 265 This should be true even if both the consumer and provider are 266 associated with a single administrative domain, in order to reduce 267 the potential for adverse interactions between IETF network slice 268 consumers and other users of the underlay network infrastructure. 270 The benefits of this model can include: 272 * Security: because the underlay network (or network operator) does 273 not need to expose network details (topology, capacity, etc.) to 274 IETF network slice consumers the underlay network components are 275 less exposed to attack; 277 * Layered Implementation: the underlay network comprises network 278 elements that belong to a different layer network than consumer 279 applications, and network information (advertisements, protocols, 280 etc.) that a consumer cannot interpret or respond to (note - a 281 consumer should not use network information not exposed via the 282 NSC NBI, even if that information is available); 284 * Scalability: consumers do not need to know any information beyond 285 that which is exposed via the NBI. 287 The general issues of abstraction in a TE network is described more 288 fully in [RFC7926]. 290 This framework document does not assume any particular layer at which 291 IETF network slices operate as a number of layers (including virtual 292 L2, Ethernet or IP connectivity) could be employed. 294 Data models and interfaces are of course needed to set up IETF 295 network slices, and specific interfaces may have capabilities that 296 allow creation of specific layers. 298 Layered virtual connections are comprehensively discussed in IETF 299 documents and are widely supported. See, for instance, GMPLS-based 300 networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and 301 [RFC8454]). The principles and mechanisms associated with layered 302 networking are applicable to IETF network slices. 304 There are several IETF-defined mechanisms for expressing the need for 305 a desired logical network. The NBI carries data either in a 306 protocol-defined format, or in a formalism associated with a modeling 307 language. 309 For instance: 311 * Path Computation Element (PCE) Communication Protocol (PCEP) 312 [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE 313 [RFC4208] use a TLV-based binary encoding to transmit data. 315 * Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF 316 Protocol [RFC8040] use XML abnd JSON encoding. 318 * gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded 319 programmable interface; 321 * SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding 322 (ASN.1). 324 * For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to 325 model configuration and other data for NETCONF, RESTCONF, and GNMI 326 - among others; ProtoBufs can be used to model gRPC and GNMI data; 327 Structure of Management Information (SMI) [RFC2578] may be used to 328 define Management Information Base (MIB) modules for SNMP, using 329 an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 330 1988). 332 While several generic formats and data models for specific purposes 333 exist, it is expected that IETF network slice management may require 334 enhancement or augmentation of existing data models. 336 3.3. IETF Network Slice Controller (NSC) 338 The IETF Network Slice Controller takes abstract requests for IETF 339 network slices and implements them using a suitable underlying 340 technology. A IETF Network Slice Controller is the key building 341 block for control and management of the IETF network slice. It 342 provides the creation/modification/deletion, monitoring and 343 optimization of IETF network slices in a multi-domain, a multi- 344 technology and multi-vendor environment. 346 A NSC northbound interface (NBI) is needed for communicating details 347 of a IETF network slice (configuration, selected policies, 348 operational state, etc.), as well as providing information to a slice 349 requester/consumer about IETF network slice status and performance. 350 The details for this NBI are not in scope for this document. 352 The controller provides the following functions: 354 * Provides a technology-agnostic NBI for creation/modification/ 355 deletion of the IETF network slices. The API exposed by this NBI 356 communicates the endpoints of the IETF network slice, IETF network 357 slice SLO parameters (and possibly monitoring thresholds), 358 applicable input selection (filtering) and various policies, and 359 provides a way to monitor the slice. 361 * Determines an abstract topology connecting the endpoints of the 362 IETF network slice that meets criteria specified via the NBI.The 363 NSC also retains information about the mapping of this abstract 364 topology to underlying components of the IETF network slice as 365 necessary to monitor IETF network slice status and performance. 367 * Provides "Mapping Functions" for the realization of IETF network 368 slices. In other words, it will use the mapping functions that: 370 map technology-agnostic NBI request to technology-specific SBIs. 372 map filtering/selection information as necessary to entities in 373 the underlay network. 375 * Via an SBI, the controller collects telemetry data (e.g. OAM 376 results, statistics, states etc.) for all elements in the abstract 377 topology used to realize the IETF network slice. 379 * Using the telemetry data from the underlying realization of a IETF 380 network slice (i.e. services/paths/tunnels), evaluates the current 381 performance against IETF network slice SLO parameters and exposes 382 them to the IETF network slice consumer via the NBI. The NSC NBI 383 may also include a capability to provide notification in case the 384 IETF network slice performance reaches threshold values defined by 385 the IETF network slice consumer. 387 3.3.1. Northbound Interface (NBI) 389 The IETF Network Slice Controller provides a Northbound Interface 390 (NBI) that allows consumers of network slices to request and monitor 391 IETF network slices. Consumers operate on abstract IETF network 392 slices, with details related to their realization hidden. 394 The NBI complements various IETF services, tunnels, path models by 395 providing an abstract layer on top of these models. 397 The NBI is independent of type of network functions or services that 398 need to be connected, i.e. it is independent of any specific storage, 399 software, protocol, or platform used to realize physical or virtual 400 network connectivity or functions in support of IETF network slices. 402 The NBI uses protocol mechanisms and information passed over those 403 mechanisms to convey desired attributes for IETF network slices and 404 their status. The information is expected to be represented as a 405 well-defined data model, and should include at least endpoint and 406 connectivity information, SLO specification, and status information. 408 To accomplish this, the NBI needs to convey information needed to 409 support communication across the NBI, in terms of identifying the 410 IETF network slices, as well providing the above model information. 412 3.4. Mapping 414 The main task of the IETF network slice controller is to map abstract 415 IETF network slice requirements to concrete technologies and 416 establish required connectivity, and ensuring that required resources 417 are allocated to the IETF network slice. 419 3.5. Underlying technology 421 There are a number of different technologies that can be used, 422 including physical connections, MPLS, TSN, Flex-E, etc. 424 See [I-D.ietf-teas-enhanced-vpn] - section 5 - for instance, for 425 example underlying technologies. 427 Also, as outlined in "applicability of ACTN to IETF Network Slices" 428 below, ACTN ([RFC8453]) offers a framework that is used elsewhere in 429 IETF specifications to create virtual network (VN) services similar 430 to IETF netrwork slices. 432 A IETF network slice can be realized in a network, using specific 433 underlying technology or technologies. The creation of a new IETF 434 network slice will be initiated with following three steps: 436 * Step 1: A higher level system requests connections with specific 437 characteristics via NBI. 439 * Step 2: This request will be processed by a IETF Network Slice 440 Controller which specifies a mapping between northbound request to 441 any IETF Services, Tunnels, and paths models. 443 * Step 3: A series of requests for creation of services, tunnels and 444 paths will be sent to the network to realize the trasport slice. 446 It is very clear that regardless of how IETF network slice is 447 realized in the network (i.e. using tunnels of type RSVP or SR), the 448 definition of IETF network slice does not change at all but rather 449 its realization. 451 4. Applicability of ACTN to IETF Network Slices 453 Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an 454 example of similar IETF work. ACTN defines three controllers to 455 support virtual network (VN) services - 457 * Customer Network Controller (CNC), 459 * Multi-Domain Service Coordinator (MDSC) and 461 * Provisioning Network Controller (PNC). 463 A CNC is responsible for communicating a customer's VN requirements. 465 A MDSC is responsible for multi-domain coordination, virtualization 466 (or abstraction), customer mapping/translation and virtual service 467 coordination to realize the VN requirement. Its key role is to 468 detach the network/service requirements from the underlying 469 technology. 471 A PNC oversees the configuration, monitoring and collection of the 472 network topology. The PNC is a underlay technology specific 473 controller. 475 While the ACTN framework is a generic VN framework that is used for 476 various VN service beyond the IETF network slice, it is still a 477 suitable basis to understand how the various controllers interact to 478 realize a IETF network slice. 480 One possible mapping between the IETF network slice, and ACTN, 481 definitions is as shown in Figure 1 below. 483 IETF Network Slice | ACTN analogous 484 Terminology / Concepts Terminology 485 | and Concepts 486 +--------------------------------------+ 487 |Consumer higher level operation system| | +-----+ 488 | (e.g E2E network slice orchestrator) | =====> | CNC | 489 +--------------------------------------+ | +-----+ 490 ^ ^ 491 | NSC NBI | | CMI 492 v v 493 +-------------------------------------+ | +------+ 494 | IETF Network Slice Controller (NSC) | =====> | MDSC | 495 +-------------------------------------+ | +------+ 496 ^ ^ 497 | NSC SBI | | MPI 498 v v 499 +-------------------------------------+ | +-----+ 500 | Network Controller(s) | =====> | PNC | 501 +-------------------------------------+ | +-----+ 503 Figure 1 505 Note that the left-hand side of this figure comes from IETF Network 506 Slice Definition ([I-D.ietf-teas-ietf-network-slice-definition]). 508 The NSC NBI conveys the generic IETF network slice requirements. 509 These may then be realized using an SBI within the NSC. 511 As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC 512 Interface (CMI) is used to convey the virtual network service 513 requirements along with the service models and the MDSC-PNC Interface 514 (MPI) is used to realize the service along network configuration 515 models. [I-D.ietf-teas-te-service-mapping-yang] further describe how 516 the VPN services can be mapped to the underlying TE resources. 518 The Network Controller is depicted as a single block, analogous to a 519 Provisioning Network Controller (PNC - in this example). In the ACTN 520 framework, however, it is also possible that the NC function is 521 decomposed into MDSC and PNC - that is, the NC may comprise hierarchy 522 as needed to handle the multiple domains and various underlay 523 technologies, whereas a PNC in ACTN is intended to be specific to at 524 most a single underlay technology and (likely) to individual devices 525 (or functional components). 527 Note that the details of potential implementations of everything that 528 is below the NSC in Figure 1 are out of scope in this document - 529 hence the specifics of the relationship between NC and PNC, and the 530 possibility that the MDSC and PNC may be combined are at most 531 academically interesting in this context. Another way to view this 532 is that, in the same way that ACTN might combine MDSC and PNC, the 533 NSC might also directly include NC functionality. 535 [RFC8453] also describes TE Network Slicing in the context of ACTN as 536 a collection of resources that is used to establish a logically 537 dedicated virtual network over one or more TE networks. In case of 538 TE enabled underlying network, ACTN VN can be used as a base to 539 realize the IETF network slicing by coordination among multiple peer 540 domains as well as underlay technology domains. 542 Figure 1 shows only one possible mapping as each ACTN component (or 543 interface) in the figure may be a composed differently in other 544 mappings, and the exact role of both components and subcomponents 545 will not be always an exact analogy between the concepts used in this 546 document and those defined in ACTN. 548 This is - in part - shown in a previous paragraph in this section 549 where it is pointed out that the NC may actually subsume some aspects 550 of both the MDSC and PNC. 552 Similarly, in part depending on how "customer" is interpreted, CNC 553 might merge some aspects of the higher level system and the NSC. As 554 in the NC/PNC case, this way of comparing ACTN to this work is not 555 useful as the NSC and NSC NBI are the focus on this document. 557 5. Considerations 559 5.1. Monitoring 561 IETF network slice realization needs to be instrumented in order to 562 track how it is working, and it might be necessary to modify the IETF 563 network slice as requirements change. Dynamic reconfiguration might 564 be needed. 566 5.2. Security Considerations 568 IETF network slices might use underlying virtualized networking. All 569 types of virtual networking require special consideration to be given 570 to the separation of traffic between distinct virtual networks, as 571 well as some degree of protection from effects of traffic use of 572 underlying network (and other) resources from other virtual networks 573 sharing those resources. 575 For example, if a service requires a specific upper bound of latency, 576 then that service can be degraded by added delay in transmission of 577 service packets through the activities of another service or 578 application using the same resources. 580 Similarly, in a network with virtual functions, noticeably impeding 581 access to a function used by another IETF network slice (for 582 instance, compute resources) can be just as service degrading as 583 delaying physical transmission of associated packet in the network. 585 While a IETF network slice might include encryption and other 586 security features as part of the service, consumers might be well 587 advised to take responsibility for their own security needs, possibly 588 by encrypting traffic before hand-off to a service provider. 590 5.3. Privacy Considerations 592 Privacy of IETF network slice service consumers must be preserved. 593 It should not be possible for one IETF network slice consumer to 594 discover the presence of other consumers, nor should sites that are 595 members of one IETF network slice be visible outside the context of 596 that IETF network slice. 598 In this sense, it is of paramount importance that the system use the 599 privacy protection mechanism defined for the specific underlying 600 technologies used, including in particular those mechanisms designed 601 to preclude acquiring identifying information associated with any 602 IETF network slice consumer. 604 5.4. IANA Considerations 606 There are no requests to IANA in this framework document. 608 6. Acknowledgments 610 The entire TEAS NS design team and everyone participating in related 611 discussions has contributed to this draft. Some text fragments in 612 the draft have been copied from the [I-D.ietf-teas-enhanced-vpn], for 613 which we are grateful. 615 Significant contributions to this document were gratefully received 616 from the contributing authors listed in the "Contributors" section. 617 In addition we would like to also thank those others who have 618 attended one or more of the design team meetings, including: 620 * Aihua Guo 622 * Bo Wu 624 * Greg Mirsky 626 * Jeff Tantsura 628 * Kiran Makhijani 630 * Lou Berger 632 * Luis M. Contreras 634 * Rakesh Gandhi 636 * Ran Chen 638 * Sergio Belotti 640 * Shunsuke Homma 642 * Stewart Bryant 644 * Tomonobu Niwa 646 * Xuesong Geng 648 7. References 650 7.1. Normative References 652 [I-D.ietf-teas-ietf-network-slice-definition] 653 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 654 Tantsura, "Definition of IETF Network Slices", Work in 655 Progress, Internet-Draft, draft-ietf-teas-ietf-network- 656 slice-definition-00, 25 January 2021, 657 . 660 7.2. Informative References 662 [BBF-SD406] 663 Broadband Forum, ., "End-to-end network slicing", BBF 664 SD-406 , n.d.. 666 [I-D.ietf-teas-actn-yang] 667 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 668 Shin, J., and S. Belotti, "Applicability of YANG models 669 for Abstraction and Control of Traffic Engineered 670 Networks", Work in Progress, Internet-Draft, draft-ietf- 671 teas-actn-yang-06, 22 August 2020, . 674 [I-D.ietf-teas-enhanced-vpn] 675 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 676 Framework for Enhanced Virtual Private Networks (VPN+) 677 Service", Work in Progress, Internet-Draft, draft-ietf- 678 teas-enhanced-vpn-06, 13 July 2020, . 681 [I-D.ietf-teas-te-service-mapping-yang] 682 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 683 and J. Tantsura, "Traffic Engineering (TE) and Service 684 Mapping Yang Model", Work in Progress, Internet-Draft, 685 draft-ietf-teas-te-service-mapping-yang-05, 2 November 686 2020, . 689 [I-D.openconfig-rtgwg-gnmi-spec] 690 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 691 C., and C. Morrow, "gRPC Network Management Interface 692 (gNMI)", Work in Progress, Internet-Draft, draft- 693 openconfig-rtgwg-gnmi-spec-01, 5 March 2018, 694 . 697 [NGMN-NS-Concept] 698 NGMN Alliance, ., "Description of Network Slicing 699 Concept", https://www.ngmn.org/uploads/ 700 media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf , 701 2016. 703 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 704 Schoenwaelder, Ed., "Structure of Management Information 705 Version 2 (SMIv2)", STD 58, RFC 2578, 706 DOI 10.17487/RFC2578, April 1999, 707 . 709 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 710 "Message Processing and Dispatching for the Simple Network 711 Management Protocol (SNMP)", STD 62, RFC 3412, 712 DOI 10.17487/RFC3412, December 2002, 713 . 715 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 716 (USM) for version 3 of the Simple Network Management 717 Protocol (SNMPv3)", STD 62, RFC 3414, 718 DOI 10.17487/RFC3414, December 2002, 719 . 721 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 722 Network Management Protocol (SNMP)", STD 62, RFC 3417, 723 DOI 10.17487/RFC3417, December 2002, 724 . 726 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 727 "Generalized Multiprotocol Label Switching (GMPLS) User- 728 Network Interface (UNI): Resource ReserVation Protocol- 729 Traffic Engineering (RSVP-TE) Support for the Overlay 730 Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, 731 . 733 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 734 Interpretation of Generalized Multiprotocol Label 735 Switching (GMPLS) Terminology within the Context of the 736 ITU-T's Automatically Switched Optical Network (ASON) 737 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 738 2006, . 740 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 741 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 742 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 743 DOI 10.17487/RFC5212, July 2008, 744 . 746 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 747 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 748 DOI 10.17487/RFC5440, March 2009, 749 . 751 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 752 the Network Configuration Protocol (NETCONF)", RFC 6020, 753 DOI 10.17487/RFC6020, October 2010, 754 . 756 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 757 and A. Bierman, Ed., "Network Configuration Protocol 758 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 759 . 761 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 762 Ceccarelli, D., and X. Zhang, "Problem Statement and 763 Architecture for Information Exchange between 764 Interconnected Traffic-Engineered Networks", BCP 206, 765 RFC 7926, DOI 10.17487/RFC7926, July 2016, 766 . 768 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 769 RFC 7950, DOI 10.17487/RFC7950, August 2016, 770 . 772 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 773 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 774 . 776 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 777 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 778 DOI 10.17487/RFC8453, August 2018, 779 . 781 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 782 Yoon, "Information Model for Abstraction and Control of TE 783 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 784 September 2018, . 786 [TS23501] 3GPP, ., "System architecture for the 5G System (5GS)", 787 3GPP TS 23.501 , 2019. 789 [TS28530] 3GPP, ., "Management and orchestration; Concepts, use 790 cases and requirements", 3GPP TS 28.530 , 2019. 792 Contributors 794 The following authors contributed significantly to this document: 796 Jari Arkko 797 Ericsson 799 Email: jari.arkko@piuha.net 801 Dhruv Dhody 802 Huawei, India 804 Email: dhruv.ietf@gmail.com 806 Jie Dong 807 Huawei 809 Email: jie.dong@huawei.com 811 Xufeng Liu 813 Email: xufeng.liu.ietf@gmail.com 815 Reza Rokui 816 Nokia 818 Email: reza.rokui@nokia.com 820 Authors' Addresses 822 Eric Gray (editor) 823 Ericsson 825 Email: eric.gray@ericsson.com 827 John Drake (editor) 828 Juniper Networks 830 Email: jdrake@juniper.net