idnits 2.17.1 draft-king-teas-applicability-actn-slicing-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-11 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-02 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-08 == 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 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-23 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group D. King 3 Internet-Draft Old Dog Consulting 4 Intended status: Informational J. Drake 5 Expires: January 14, 2021 Juniper Networks 6 H. Zheng 7 Huawei Technologies 8 July 13, 2020 10 Applicability of Abstraction and Control of Traffic Engineered Networks 11 (ACTN) to TE Network Slicing 12 draft-king-teas-applicability-actn-slicing-06 14 Abstract 16 Network abstraction is a technique that can be applied to a network 17 domain that utilizes a set of policies to select network resources 18 and obtain a view of potential connectivity across the network. 20 Network slicing is an approach to network operations that builds on 21 the concept of network abstraction to provide programmability, 22 flexibility, and modularity. It may use techniques such as Software 23 Defined Networking (SDN) and Network Function Virtualization (NFV) to 24 create multiple logical or virtual networks, each tailored for a set 25 of services share the same set of requirements. 27 Abstraction and Control of Traffic Engineered Networks (ACTN) is 28 described in RFC 8453. It defines an SDN-based architecture that 29 relies on the concept of network and service abstraction to detach 30 network and service control from the underlying data plane. 32 This document outlines the applicability of ACTN to transport network 33 slicing in a Traffic Engineering (TE) network that utilizes IETF 34 technology. It also identifies the features of network slicing not 35 currently within the scope of ACTN, and indicates where ACTN might be 36 extended. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 14, 2021. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Requirements for Network Slicing . . . . . . . . . . . . . . 5 75 2.1. Resource Slicing . . . . . . . . . . . . . . . . . . . . 5 76 2.2. Service Isolation . . . . . . . . . . . . . . . . . . . . 5 77 2.3. Network Virtualization . . . . . . . . . . . . . . . . . 6 78 2.4. Control and Orchestration . . . . . . . . . . . . . . . . 6 79 3. Abstraction and Control of Traffic Engineered (TE) Networks 80 (ACTN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.1. ACTN Virtual Network as a Network Slice . . . . . . . . . 8 82 3.2. Examples of ACTN Delivering Types of Network Slices . . . 8 83 3.2.1. ACTN Used for Virtual Private Line Model . . . . . . 8 84 3.2.2. ACTN Used for VPN Delivery Model . . . . . . . . . . 10 85 3.2.3. ACTN Used to Deliver a Virtual Consumer Network . . . 11 86 3.2.4. Network Slice Service Mapping from TE to ACTN VN 87 Models . . . . . . . . . . . . . . . . . . . . . . . 12 88 3.3. ACTN VN Telemetry . . . . . . . . . . . . . . . . . . . . 12 89 4 Transport Slice NBI Model . . . . . . . . . . . . . . . . . . 13 90 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 93 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 94 9. Informative References . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 The principles of network resource separation are not new. For 100 years, separated overlay and logical (virtual) networking have 101 existed, allowing multiple services to be deployed over a single 102 physical network comprised of single or multiple layers. However, 103 several key differences exist that differentiate overlay and virtual 104 networking from network slicing. 106 A network slice is a virtual (that is, logical) network with its own 107 network topology and a set of network resources that are used to 108 provide connectivity that conforms to a specific Service Level 109 Agreement (SLA) or Service Level Objective (SLO). The network 110 resources used to realize a network slice belong to the network that 111 is sliced. The resources may be assigned and dedicated to an 112 individual slice, or they may be shared with other slices enabling 113 different degrees of service guarantee and providing different levels 114 of isolation between the traffic in each slice. 116 The term "Transport Network Slice" is used to describe a network 117 slice that is used to support another network service by carrying 118 traffic across one or more networks. A transport network slice could 119 span multiple technologies (such as IP, MPLS, or optical) and 120 multiple administrative domains. 122 The logical network that is a transport network slice may be kept 123 separate from other concurrent logical networks each with independent 124 control and management. Each can be created or modified on demand. 126 At one end of the spectrum, a virtual private wire or a virtual 127 private network (VPN) may be used to build a network slice. In these 128 cases, the network slices do not require the service provider to 129 isolate network resources for the provision of the service - the 130 service is "virtual". 132 At the other end of the spectrum there may be a detailed description 133 of a complex service that will meet the needs of a set of 134 applications with connectivity and service function requirements that 135 may include compute resource, storage capability, and access to 136 content. Such a service may be requested dynamically (that is, 137 instantiated when an application needs it, and released when the 138 application no longer needs it), and modified as the needs of the 139 application change. This type of enhanced VPN is described in more 140 detail in [I-D.ietf-teas-enhanced-vpn]. 142 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 143 framework that facilitates the abstraction of underlying network 144 resources to higher-layer applications and that allows network 145 operators to create virtual networks for their customers through the 146 abstraction of the operators' network resources. ACTN is described 147 further in Section 3. 149 This document outlines the application of ACTN and associated 150 enabling technologies to provide transport network slicing in a 151 network that utilizes IETF technologies such as IP, MPLS, or GMPLS. 152 It describes how the ACTN functional components can be used to 153 support model-driven partitioning of variable-sized bandwidth to 154 facilitate network sharing and virtualization. Furthermore, the use 155 of model-based interfaces to dynamically request the instantiation of 156 virtual networks can be extended to encompass requesting and 157 instantiation of specific service functions (which may be both 158 physical or virtual), and to partition network resources such as 159 compute resource, storage capability, and access to content. 161 Various efforts within the IETF are investigating the concept of 162 network slicing (for example, [I-D.nsdt-teas-ns-framework]) and 163 investigate the applicability of IETF protocols to the delivery of 164 network slicing (for example, [I-D.ietf-teas-enhanced-vpn]). This 165 document highlights how the ACTN approach might be extended to 166 address the requirements of network slicing where the underlying 167 network is TE-capable. It is not the intention that this work 168 contradicts or competes with other IETF work. 170 1.1. Terminology 172 This document uses the following terminology. Many of these terms 173 are in common usage in other work in the IETF and do not always have 174 consistent meanings (see for example, [I-D.ietf-teas-enhanced-vpn] 175 and [I-D.nsdt-teas-ns-framework]). The terms defined below are 176 intended to give context and meaning for use in this document only 177 and do not force wider applicability. 179 Service Provider: A server network or collection of server networks. 180 The persons or organization responsible for operating such 181 networks. 183 Consumer: Any application, client network, or customer of a service 184 provider. 186 Service Functions (SFs): Components that provide specific functions 187 within a network. SFs are often combined in a specific sequence 188 called a service function chain to deliver services [RFC7665]. 190 Resource: Any feature including connectivity, compute, storage, and 191 content delivery that forms part of or can be accessed through a 192 network. Resources may be shared between users, applications, and 193 clients, or they may be dedicated for use by a unique consumer. 195 Infrastructure Resources: The hardware and software for hosting and 196 connecting SFs. These resources may include computing hardware, 197 storage capacity, network resources (e.g., links and switching/ 198 routing devices enabling network connectivity), and physical 199 assets for radio access. 201 Service Level Agreement (SLA): An agreement between a consumer and 202 network provider that describes the quality with which features 203 and functions are to be delivered. It may include measures of 204 bandwidth, latency, and jitter; the types of service (such as 205 firewalls or billing) to be provided; the location, nature, and 206 quantities of services (such as the amount and location of compute 207 resources and the accelerators required). 209 Network Slice: An agreement between a consumer and a service 210 provider to deliver network resources according to a specific 211 service level agreement. A slice could span multiple technologies 212 (e.g., radio, transport and cloud) and administrative domains. 214 Transport Network Slice: A network slice that is used to support 215 another network service by carrying traffic across one or more 216 networks. A transport network slice could span multiple transport 217 technologies (such as IP, MPLS, or optical) and multiple 218 administrative domains. 220 2. Requirements for Network Slicing 222 The concept of network slicing is a key capability to serve consumers 223 with a wide variety of different service needs express in term of 224 latency, reliability, capacity, and service function specific 225 capabilities. 227 This section outlines the key capabilities required to realize 228 network slicing in an IETF technology network. Consideration of 229 slicing in other technology networks (such as radio access networks) 230 is out of scope. 232 2.1. Resource Slicing 234 Network resources need to be allocated and dedicated for use by a 235 specific network slice, or they may be shared among multiple slices. 236 This allows a flexible approach that can deliver a range of services 237 by partitioning (that is, slicing) the available network resources to 238 present make them available to meet the consumer's SLA. 240 2.2. Service Isolation 242 A consumer may request, through their SLA, that the service deliver 243 to them is isolated from any other services delivered to any other 244 consumers. That is, the SLA may request that changes to the other 245 services do not have any negative impact on the delivery of the 246 service. 248 Delivery of such service isolation may be achieved in the underlying 249 network by various forms of resource partitioning ranging from 250 dedicated allocation of resources for a specific slice, to sharing or 251 resources with safeguards. 253 Although multiple network slices may utilize resources from a single 254 underlying network, isolation should be understood in terms of: 256 o Performance isolation requires that service delivery on one 257 network slice does not adversely impact congestion or performance 258 levels of other slices. 260 o Security isolation means that attacks or faults occurring in one 261 slice do not impact on other slices. Moreover, the security 262 functions supporting each slice must operate independently so that 263 an attack or misconfiguration of security in one slice will not 264 prevent proper security function in the other slices. 266 o Management isolation means that each slice must be independently 267 viewed, utilized and managed as a separate network. Furthermore, 268 it should be possible to prevent the operator of one slice from 269 being able to control, view, or detect any aspect of any other 270 network slice. 272 2.3. Network Virtualization 274 Network virtualization enables the creation of multiple isolated 275 virtual networks that are operationally decoupled from the underlying 276 physical network, and are run on top of it. Slicing should enable 277 the creation of virtual networks as consumer services. 279 2.4. Control and Orchestration 281 Orchestration combines and coordinates multiple control methods to 282 provide a mechanism to operate one or more networks to deliver 283 services. In a network slicing environment, an orchestrator is 284 needed to coordinate disparate processes and resources for creating, 285 managing, and deploying the end-to-end service. Two aspects of 286 orchestration are required: 288 o Multi-domain Orchestration: Managing connectivity setup of the 289 transport network slice across multiple administrative domains. 291 o End-to-end Orchestration: Combining resources for an end-to-end 292 service (e.g., transport connectivity with firewalling and 293 guaranteed bandwidth with minimum delay). 295 3. Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) 297 ACTN facilitates end-to-end connections and provides them to the 298 user. The ACTN framework [RFC8453] introduces three functional 299 components and two interfaces: 301 o Customer Network Controller (CNC) 303 o Multi-domain Service Coordinator (MDSC) 305 o Provisioning Network Controller (PNC) 307 o CNC-MDSC Interface (CMI) 309 o MDSC-PNC Interface (MPI) 311 RFC 8453 also highlights how: 313 o Abstraction of the underlying network resources is provided to 314 higher-layer applications and consumers. 316 o Virtualization is achieved by selecting resources according to 317 criteria derived from the details and requirements of the 318 consumer, application, or service. 320 o Creation of a virtualized environment is performed to allow 321 operators to view and control multi-domain networks as a single 322 virtualized network. 324 o The presentation of networks to a consumer as a single virtual 325 network via open and programmable interfaces. 327 The ACTN managed infrastructure consists of traffic engineered 328 network resources, which may include: 330 o Statistical packet bandwidth. 332 o Physical forwarding plane sources, such as: wavelengths and time 333 slots. 335 o Forwarding and cross-connect capabilities. 337 The ACTN network is "sliced" with consumers being given a different 338 partial and abstracted topology view of the physical underlying 339 network. 341 3.1. ACTN Virtual Network as a Network Slice 343 To support multiple consumers, each with its own view of and control 344 of the server network, a service provider needs to partition the 345 server network resources to create slices assigned to each consumer. 347 An ACTN Virtual Network (VN) is a consumer view that is a slice of 348 the ACTN-managed infrastructure. It is a network slice that is 349 presented to the consumer by the ACTN provider as a set of abstracted 350 resources. See [I-D.ietf-teas-actn-vn-yang] for detailed ACTN VN. 352 Depending on the agreement between consumer and provider various VN 353 operations possible: 355 o Network Slice Creation: A VN could be pre-configured and created 356 through static configuration or through dynamic request and 357 negotiation between consumer and service provider. The VN must 358 meet the network slice requirements specified in the SLA to 359 satisfy the consumer's objectives. 361 o Network Slice Operations: The VN may be modified and deleted based 362 on consumer requests. The consumer can further act upon the VN to 363 manage traffic flows across the network slice. 365 o Network Slice View: The VN topology may be viewed from the 366 consumer's perspective. This may be the entire VN topology or a 367 collection of tunnels that are expressed as consumer end points, 368 access links, intra domain paths and inter-domain links. 370 [RFC8454] describes a set of functional primitives that support these 371 different ACTN VN operations. 373 3.2. Examples of ACTN Delivering Types of Network Slices 375 The examples that follow build on the ACTN framework to provide 376 control, management, and orchestration for the network slice life- 377 cycle. These network slices utilize common physical infrastructure, 378 and meet specific requirements. 380 Three examples are shown. Each uses ACTN to achieve a different 381 network slicing scenario. All three scenarios can be scaled up in 382 capacity or be subject to topology changes as well as changes of 383 consumer requirements. 385 3.2.1. ACTN Used for Virtual Private Line Model 387 In the example shown in Figure 1, ACTN provides virtual connections 388 between multiple consumer locations, requested by the requester of a 389 Virtual Private Line (VPL) service (CNC-A). Benefits of this model 390 include: 392 o Automated: the service set-up and operation is network provider 393 managed. 395 o Virtual: the private line connectivity is provided from Site A to 396 Site C (VPL1) and from Site B to Site C (VPL2) across the ACTN- 397 managed physical network. 399 o Agile: on-demand when the consumer needs connectivity and fully 400 adjustable bandwidth. 402 (Consumer VPL Request) 403 : 404 ------- 405 | CNC-A | 406 Boundary ------- 407 Between . . . . . . . . .:. . . . . . . . . . . 408 Consumer & : 409 Network Provider ------ 410 | MDSC | 411 ------ 412 : 413 ----- 414 | PNC | 415 Site A ( ----- ) Site B 416 ------ ( ) ------ 417 | vCE1 |========( Physical )========| vCE2 | 418 ------ ( Network ) ------ 419 \ (_______) / 420 \ || / 421 \ || / 422 VPL 1 \ || / VPL 2 423 \ || / 424 \ || / 425 \ ------ / 426 -----| vCE3 |---- 427 ------ 428 Site C 430 Key: ... ACTN control connectivity 431 === Physical connectivity 432 --- Logical connectivity 434 Figure 1: Virtual Private Line Model 436 3.2.2. ACTN Used for VPN Delivery Model 438 In the example shown in Figure 2, ACTN provides VPN connectivity 439 between two sites across three physical networks. The VPN requestor 440 (CNC) is managed by the consumer expressed as users of the two VPN 441 sites. The CNC interacts with the network provider's MDSC. Benefits 442 of this model include: 444 o Provides edge-to-edge VPN multi-access connectivity. 446 o Most of the function is managed by the network provider, with some 447 flexibility delegated to the consumer managed CNC. 449 -------------- -------------- 450 | Site-A Users | | Site-B Users | 451 -------------- -------------- 452 : : 453 ------------- 454 | CNC | 455 Boundary ------------- 456 Between . . . . . . . . . . . : . . . . . . . . . . . 457 Consumer & : 458 Network Provider : 459 --------------------------------- 460 | MDSC | 461 --------------------------------- 462 : : : 463 : : : 464 ------- ------- ------- 465 | PNC | | PNC | | PNC | 466 ------- ------- ------- 467 : : : 468 : : : 469 ______ ----- ----- ----- ______ 470 < > ( ) ( ) ( ) < > 471 ====( Phys. )======( Phys. )======( Phys. )==== 472 < > ( Net ) ( Net ) ( Net ) < > 473 < > ----- ----- ----- < > 474 < >-----------------------------------------------< > 475 <______> <______> 477 Key: ... ACTN control connectivity 478 === Physical connectivity 479 --- Logical connectivity 481 Figure 2: VPN Model 483 3.2.3. ACTN Used to Deliver a Virtual Consumer Network 485 In this example (shown in Figure 3), ACTN provides a virtual network 486 to the consumer. This virtual network is managed by the consumer. 487 Benefits of this model include: 489 o The MDSC provides the topology as part of the consumer view so 490 that the consumer can control their network slice to fit their 491 needs. 493 o Service isolation can be provided through selection of physical 494 networking resources. 496 o Applications can interact with their assigned network slices 497 directly. The consumer may implement their own network control 498 methods and traffic prioritization, manage their own addressing 499 schemes, and further slice their virtual networks. 501 o The network slice may include nodes with specific capabilities. 502 These are delivered as Physical Network Functions (PNFs) or 503 Virtual Network Functions (VNFs). 505 ------------- ( Network ) 506 | CNC |----------->( Slice 2 ) 507 ------------- __(________ ) 508 ------------- ( )__) 509 | CNC |----------->( Network ) ^ 510 ------------- ( Slice 1 ) : 511 ^ (___________) : 512 | ^ ^ : 513 Boundary | : : : 514 Between . . . .|. . . . . . . . . . . . : . .:. . : . . . 515 Consumer & | : : : 516 Network Provider | : : : 517 v : : : 518 ------------- : :....: 519 | MDSC | : : 520 ------------- : : 521 ^ ------^-- : 522 | ( ) : 523 v ( Physical ) : 524 ------- ( Network ) : 525 | PNC |<------------>( ) ---^----- 526 ------- | ------- ( ) 527 | PNC |- ( Physical ) 528 | |<-------------------------->( Network ) 529 ------- ( ) 530 ------- 532 Key: --- ACTN control connection 533 ... Virtualization/abstraction through slicing 535 Figure 3: Network Slicing 537 3.2.4. Network Slice Service Mapping from TE to ACTN VN Models 539 The role of the TE-service mapping model 540 [I-D.ietf-teas-te-service-mapping-yang] is to create a binding 541 relationship across a Layer 3 Service Model (L3SM) [RFC8299], Layer 2 542 Service Model (L2SM) [RFC8466], and TE Tunnel model 543 [I-D.ietf-teas-yang-te], via the generic ACTN Virtual Network (VN) 544 model [I-D.ietf-teas-actn-vn-yang]. 546 The ACTN VN model is a generic virtual network service model that 547 allows consumers to specify a VN that meets the consumer's service 548 objectives with various constraints on how the service is delivered. 550 The TE-service mapping model [I-D.ietf-teas-te-service-mapping-yang] 551 is used to bind the L3SM with TE-specific parameters. This binding 552 facilitates seamless service operation and enables visibility of the 553 underlay TE network. The TE-service model developed in that document 554 can also be extended to support other services including L2SM, and 555 the Layer 1 Connectivity Service Model (L1CSM) 556 [I-D.ietf-ccamp-l1csm-yang] L1CSM network service models. 558 Figure 4 shows the relationship between the models discussed above. 560 -------------- -------------- 561 | L3SM |<=======| | ---------- 562 -------------- augment| |..........>| ACTN VN | 563 -------------- | Augmented | reference ---------- 564 | L2SM |<=======| Service | 565 -------------- augment| Model | ---------- 566 -------------- | |..........>| TE-topo | 567 | L1CSM |<=======| | reference ---------- 568 -------------- augment| | 569 -------------- | | ---------- 570 | TE & Service |------->| |..........>| TE-tunnel| 571 | Mapping Types| import -------------- reference ---------- 572 -------------- 574 Figure 4: TE-Service Mapping 576 3.3. ACTN VN Telemetry 577 The ACTN VN KPI telemetry model 578 [I-D.ietf-teas-actn-pm-telemetry-autonomics] provides a way for a 579 consumer to define performance monitoring relevant for its VN/network 580 slice via the NETCONF subscription mechanisms [RFC8639], [RFC8640] or 581 the equivalent mechanisms in RESTCONF [RFC8641], [RFC8650]. 583 Key characteristics of [I-D.ietf-teas-actn-pm-telemetry-autonomics] 584 include: 586 o An ability to provide scalable VN-level telemetry aggregation 587 based on consumer subscription model for key performance 588 parameters defined by the consumer. 590 o An ability to facilitate proactive re-optimization and 591 reconfiguration of VNs/network slices based on network autonomic 592 traffic engineering scaling configuration mechanism. 594 4 Transport Slice NBI Model 596 A network slice, or "transport network slice", resource model will 597 be required or operation of ACTN-based network slicing. This model 598 will be generated for instantiation, operation and monitoring, of 599 network and function resource slices. The YANG model defined in 600 [I-D.wd-teas-transport-slice-yang] provides a suitable basis for 601 requesting, controlling and deleting, network slices. 603 5. IANA Considerations 605 This document makes no requests for action by IANA. 607 6. Security Considerations 609 Network slicing involves the control of network resources in order to 610 meet the service requirements of consumers. In some deployment 611 models, the consumer is able to directly request modification in the 612 behaviour of resources owned and operated by a service provider. 613 Such changes could significantly affect the service provider's 614 ability to provide services to other consumers. Furthermore, the 615 resources allocated for or consumed by a consumer will normally be 616 billable by the service provider. 618 Therefore, it is crucial that the mechanisms used in any network 619 slicing system allow for authentication of requests, security of 620 those requests, and tracking of resource allocations. 622 It should also be noted that while the partitioning or slicing of 623 resources is virtual, the consumers expect and require that there is 624 no risk of leakage of data from one slice to another, no transfer of 625 knowledge of the structure or even existence of other slices, and 626 that changes to one slice (under the control of one consumer) should 627 not have detrimental effects on the operation of other slices 628 (whether under control of different or the same consumers) beyond the 629 limits allowed within the SLA. Thus, slices are assumed to be 630 private and to provide the appearance of genuine physical 631 connectivity. 633 ACTN operates using the NETCONF [RFC6241] or RESTCONF [RFC8040] 634 protocols and assumes the security characteristics of those 635 protocols. Deployment models for ACTN should fully explore the 636 authentication and other security aspects before networks start to 637 carry live traffic. 639 7. Acknowledgements 641 Thanks to Qin Wu, Andy Jones, Ramon Casellas, and Gert Grammel for 642 their insight and useful discussions about network slicing. 644 8. Contributors 646 The following people contributed text to this document. 648 Young Lee 649 Email: younglee.tx@gmail.com 651 Mohamed Boucadair 652 Email: mohamed.boucadair@orange.com 654 Sergio Belotti 655 Email: sergio.belotti@nokia.com 657 Daniele Ceccarelli 658 Email: daniele.ceccarelli@ericsson.com 660 Adrian Farrel 661 adrian@olddog.co.uk 663 9. Informative References 665 [I-D.ietf-ccamp-l1csm-yang] 666 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 667 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 668 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in 669 progress), March 2020. 671 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 672 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 673 and D. Ceccarelli, "YANG models for VN/TE Performance 674 Monitoring Telemetry and Scaling Intent Autonomics", 675 draft-ietf-teas-actn-pm-telemetry-autonomics-02 (work in 676 progress), March 2020. 678 [I-D.ietf-teas-actn-vn-yang] 679 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 680 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 681 teas-actn-vn-yang-08 (work in progress), March 2020. 683 [I-D.ietf-teas-enhanced-vpn] 684 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 685 Framework for Enhanced Virtual Private Networks (VPN+) 686 Services", draft-ietf-teas-enhanced-vpn-05 (work in 687 progress), February 2020. 689 [I-D.ietf-teas-te-service-mapping-yang] 690 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 691 and J. Tantsura, "Traffic Engineering (TE) and Service 692 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 693 yang-03 (work in progress), March 2020. 695 [I-D.ietf-teas-yang-te] 696 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 697 "A YANG Data Model for Traffic Engineering Tunnels and 698 Interfaces", draft-ietf-teas-yang-te-23 (work in 699 progress), March 2020. 701 [I-D.nsdt-teas-ns-framework] 702 Gray, E. and J. Drake, "Framework for Transport Network 703 Slices", draft-nsdt-teas-ns-framework-02 (work in 704 progress), April 2020. 706 [I-D.wd-teas-transport-slice-yang] 707 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data 708 Model for Transport Slice NBI", draft-wd-teas-transport- 709 slice-yang-02 (work in progress), July 2020. 711 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 712 and A. Bierman, Ed., "Network Configuration Protocol 713 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 714 . 716 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 717 Chaining (SFC) Architecture", RFC 7665, 718 DOI 10.17487/RFC7665, October 2015, 719 . 721 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 722 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 723 . 725 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 726 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 727 DOI 10.17487/RFC8299, January 2018, 728 . 730 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 731 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 732 DOI 10.17487/RFC8453, August 2018, 733 . 735 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 736 Yoon, "Information Model for Abstraction and Control of TE 737 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 738 September 2018, . 740 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 741 Data Model for Layer 2 Virtual Private Network (L2VPN) 742 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 743 2018, . 745 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 746 E., and A. Tripathy, "Subscription to YANG Notifications", 747 RFC 8639, DOI 10.17487/RFC8639, September 2019, 748 . 750 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 751 E., and A. Tripathy, "Dynamic Subscription to YANG Events 752 and Datastores over NETCONF", RFC 8640, 753 DOI 10.17487/RFC8640, September 2019, 754 . 756 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 757 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 758 September 2019, . 760 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 761 A. Bierman, "Dynamic Subscription to YANG Events and 762 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 763 November 2019, . 765 Authors' Addresses 767 Daniel King 768 Old Dog Consulting 770 Email: daniel@olddog.co.uk 772 John Drake 773 Juniper Networks 775 Email: jdrake@juniper.net 777 Haomian Zheng 778 Huawei Technologies 780 Email: zhenghaomian@huawei.com