idnits 2.17.1 draft-king-teas-applicability-actn-slicing-09.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 (February 4, 2021) is 1176 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-13 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-04 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-10 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-27) exists of draft-ietf-teas-rfc3272bis-10 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-05 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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: August 8, 2021 Juniper Networks 6 H. Zheng 7 Huawei Technologies 8 A. Farrel 9 Old Dog Consulting 10 February 4, 2021 12 Applicability of Abstraction and Control of Traffic Engineered Networks 13 (ACTN) to Network Slicing 14 draft-king-teas-applicability-actn-slicing-09 16 Abstract 18 Network abstraction is a technique that can be applied to a network 19 domain. It utilizes a set of policies to select network resources 20 and obtain a view of potential connectivity across the network. 22 Network slicing is an approach to network operations that builds on 23 the concept of network abstraction to provide programmability, 24 flexibility, and modularity. It may use techniques such as Software 25 Defined Networking (SDN) and Network Function Virtualization (NFV) to 26 create multiple logical or virtual networks, each tailored for a set 27 of services that share the same set of requirements. 29 Abstraction and Control of Traffic Engineered Networks (ACTN) is 30 described in RFC 8453. It defines an SDN-based architecture that 31 relies on the concept of network and service abstraction to detach 32 network and service control from the underlying data plane. 34 This document outlines the applicability of ACTN to network slicing 35 in a Traffic Engineering (TE) network that utilizes IETF technology. 36 It also identifies the features of network slicing not currently 37 within the scope of ACTN, and indicates where ACTN might be extended. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on August 8, 2021. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Requirements for Network Slicing . . . . . . . . . . . . . . 5 76 2.1. Resource Slicing . . . . . . . . . . . . . . . . . . . . 6 77 2.2. Service Isolation . . . . . . . . . . . . . . . . . . . . 6 78 2.3. Network Virtualization . . . . . . . . . . . . . . . . . 7 79 2.4. Control and Orchestration . . . . . . . . . . . . . . . . 7 80 3. Abstraction and Control of Traffic Engineered (TE) Networks 81 (ACTN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3.1. ACTN Virtual Network as a Network Slice . . . . . . . . . 8 83 3.2. Examples of ACTN Delivering Types of Network Slices . . . 9 84 3.2.1. ACTN Used for Virtual Private Line . . . . . . . . . 9 85 3.2.2. ACTN Used for VPN Delivery Model . . . . . . . . . . 10 86 3.2.3. ACTN Used to Deliver a Virtual Consumer Network . . . 11 87 4. YANG Models . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 4.1. Network Slice Service Mapping from TE to ACTN VN Models . 13 89 4.2. Interfaces and Yang Models . . . . . . . . . . . . . . . 14 90 4.3. ACTN VN Telemetry . . . . . . . . . . . . . . . . . . . . 15 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 94 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 95 9. Informative References . . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 The principles of network resource separation are not new. For 101 years, concept of separated overlay and logical (virtual) networking 102 has existed, allowing multiple services to be deployed over a single 103 physical network comprised of single or multiple layers. However, 104 several key differences exist that differentiate overlay and virtual 105 networking from network slicing. 107 A network slice is a virtual (that is, logical) network with its own 108 network topology and a set of network resources that are used to 109 provide connectivity that conforms to a specific Service Level 110 Agreement (SLA) or set of Service Level Objectives (SLOs). The 111 network resources used to realize a network slice belong to the 112 network that is sliced. The resources may be assigned and dedicated 113 to an individual slice, or they may be shared with other slices 114 enabling different degrees of service guarantee and providing 115 different levels of isolaiton between the traffic in each slice. 117 [I-D.ietf-teas-ietf-network-slice-definition] provides a number of 118 useful definitions for network slicing in the context of IETF network 119 technologies. In particular, that document defines the term "IETF 120 network slice" to be the generic network slice concept applied to a 121 network that uses IETF technologies. An IETF network slice could 122 span multiple technologies (such as IP, MPLS, or optical) and 123 multiple administrative domains. The logical network that is an IETF 124 network slice may be kept separate from other concurrent logical 125 networks each with independent control and management: each can be 126 created or modified on demand. Since this document is focused 127 entirely on IETF technologies, it uses the term "network slice" as a 128 more concise expression. Further dicussion on the topic of network 129 slicing can be found in [I-D.nsdt-teas-ns-framework]. 131 At one end of the spectrum, a virtual private wire or a virtual 132 private network (VPN) may be used to build a network slice. In these 133 cases, the network slices do not require the service provider to 134 isolate network resources for the provision of the service - the 135 service is "virtual". 137 At the other end of the spectrum there may be a detailed description 138 of a complex service that will meet the needs of a set of 139 applications with connectivity and service function requirements that 140 may include compute resource, storage capability, and access to 141 content. Such a service may be requested dynamically (that is, 142 instantiated when an application needs it, and released when the 143 application no longer needs it), and modified as the needs of the 144 application change. This type of service is called an enhanced VPN 145 and is described in more detail in [I-D.ietf-teas-enhanced-vpn] and 146 is often based on Traffic Engineering (TE) constructs in the underlay 147 network. 149 Abstraction and Control of TE Networks (ACTN) [RFC8453] is a 150 framework that facilitates the abstraction of underlying network 151 resources to higher-layer applications and that allows nework 152 operators to create virtual networks for their customers through the 153 abstraction of the operators' network resources. 155 This document outlines the application of ACTN and associated 156 enabling technologies to provide network slicing in a network that 157 utilizes IETF technologies such as IP, MPLS, or GMPLS. It describes 158 how the ACTN functional components can be used to support model- 159 driven partitioning of resources into variable-sized bandwidth units 160 to facilitate network sharing and virtualization. Furthermore, the 161 use of model-based interfaces to dynamically request the 162 instantiation of virtual networks can be extended to encompass 163 requesting and instantiation of specific service functions (which may 164 be both physical or virtual), and to partition network resources such 165 as compute resource, storage capability, and access to content. 167 Various efforts within the IETF are investigating the concept of 168 network slicing (for example, [I-D.nsdt-teas-ns-framework]) and 169 consider the applicability of IETF protocols to the delivery of 170 network slicing (for example, [I-D.ietf-teas-enhanced-vpn]). This 171 document highlights how the ACTN approach might be extended to 172 address the requirements of network slicing where the underlying 173 network is TE-capable. It is not the intention that this work 174 contradicts or competes with other IETF work. 176 1.1. Terminology 178 This document uses the following terminology. Many of these terms 179 are in common usage in other work in the IETF (see for example, 180 [I-D.ietf-teas-ietf-network-slice-definition], 181 [I-D.ietf-teas-enhanced-vpn] and [I-D.nsdt-teas-ns-framework]). The 182 terms defined below are intended to give context and meaning for use 183 in this document only and do not force wider applicability. As other 184 work matures, it is hoped that the terminology will converge. 186 Service Provider: A server network or collection of server networks. 187 The persons or organization responsible for operating such 188 networks. 190 Consumer: As defined in 191 [I-D.ietf-teas-ietf-network-slice-definition], a consumer is the 192 component that requests and uses a network slice. This may be any 193 application, client network, or customer of a service provider. 195 In the ACTN framework [RFC8453] the consumer of a network service 196 is termed a 'customer' because it will often be the case that a 197 VPN consumer is a customer of the operator of the core network 198 that delivers the service. In the context of a network slice, the 199 consumer may well be a customer, but might also be a client 200 network of the service provider (which could also be an internal 201 organization of the service provider), or an application that 202 engineers traffic in the network. 204 Service Functions (SFs): Components that provide specific functions 205 within a network. SFs are often combined in a specific sequence 206 called a service function chain to deliver services [RFC7665]. 208 Resource: Any feature including connectivity, compute, storage, and 209 content delivery that forms part of or can be accessed through a 210 network. Resources may be shared between users, applications, and 211 clients, or they may be dedicated for use by a unique consumer. 213 Infrastructure Resources: The hardware and software for hosting and 214 connecting SFs. These resources may include computing hardware, 215 storage capacity, network resources (e.g., links and switching/ 216 routing devices enabling network connectivity), and physical 217 assets for radio access. 219 Service Level Agreement (SLA): Per [I-D.ietf-teas-ietf-network-slice 220 -definition], an SLA is an explicit or implicit contract between 221 the consumer of a network slice and the provider of the slice. 222 The SLA is expressed in terms of a set of Service Level Objectives 223 (SLOs) and may include commercial terms as well as the 224 consequences of violating the SLOs. The SLA describes the quality 225 with which features and functions are to be delivered. It may 226 include measures of bandwidth, latency, and jitter; the types of 227 service (such as firewalls or billing) to be provided; the 228 location, nature, and quantities of services (such as the amount 229 and location of compute resources and the accelerators required). 231 Network Slice Service: An agreement between a consumer and a service 232 provider to deliver network resources according to a specific 233 service level agreement. 235 2. Requirements for Network Slicing 237 The concept of network slicing is a key capability to serve consumers 238 with a wide variety of different service needs expressed as SLOs in 239 term of latency, reliability, capacity, and service function specific 240 capabilities. 242 This section outlines the key capabilities required to realize 243 network slicing in a TE-enabled IETF technology network. 245 2.1. Resource Slicing 247 Network resources need to be allocated and dedicated for use by a 248 specific network slice, or they may be shared among multiple slices. 249 This allows a flexible approach that can deliver a range of services 250 by partitioning (that is, slicing) the available network resources to 251 make them available to meet the consumer's SLA. 253 2.2. Service Isolation 255 A consumer may request, through their SLA, that changes to the other 256 services delivered by the service provider do not have any negative 257 impact on the delivery of the service. This quality is refered to as 258 "isolation" [I-D.ietf-teas-ietf-network-slice-definition] 259 [I-D.ietf-teas-enhanced-vpn]. 261 Delivery of such service isolation may be achieved in the underlying 262 network by various forms of resource partitioning ranging from 263 dedicated allocation of resources for a specific slice, to sharing or 264 resources with safeguards. 266 Although multiple network slices may utilize resources from a single 267 underlying network, isolation should be understood in terms of the 268 following three categorisations. 270 o Performance isolation requires that service delivery for one 271 network slice does not adversely impact congestion or performance 272 levels of other slices. 274 o Security isolation means that attacks or faults occurring in one 275 slice do not impact on other slices. Moreover, the security 276 functions supporting each slice must operate independently so that 277 an attack or misconfiguration of security in one slice will not 278 prevent proper security function in the other slices. Further, 279 privacy concerns require that traffic from one slice is not 280 delivered to an end point in another slice, and that it should not 281 be possible to determine the nature or characteristics of a slice 282 from any external point. 284 o Management isolation means that each slice must be independently 285 viewed, utilized, and managed as a separate network. Furthermore, 286 it should be possible to prevent the operator of one slice from 287 being able to control, view, or detect any aspect of any other 288 network slice. 290 2.3. Network Virtualization 292 Network virtualization enables the creation of multiple virtual 293 networks that are operationally decoupled from the underlying 294 physical network, and are run on top of it. Slicing enables the 295 creation of virtual networks as consumer services. 297 2.4. Control and Orchestration 299 Orchestration combines and coordinates multiple control methods to 300 provide a single mechanism to operate one or more networks to deliver 301 services. In a network slicing environment, an orchestrator is 302 needed to coordinate disparate processes and resources for creating, 303 managing, and deploying the network slicing service. Two aspects of 304 orchestration are required: 306 o Multi-domain Orchestration: Managing connectivity to set up a 307 network slice across multiple administrative domains. 309 o End-to-end Orchestration: Combining resources for an end-to-end 310 service (e.g., underlay connectivity with firewalling, and 311 guaranteed bandwidth with minimum delay). 313 3. Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) 315 ACTN facilitates end-to-end connectivity and provide virtual 316 connectivity services (such as virtual links and virtual networks) to 317 the user. The ACTN framework [RFC8453] introduces three functional 318 components and two interfaces: 320 o Customer Network Controller (CNC) 322 o Multi-domain Service Coordinator (MDSC) 324 o Provisioning Network Controller (PNC) 326 o CNC-MDSC Interface (CMI) 328 o MDSC-PNC Interface (MPI) 330 RFC 8453 also highlights how: 332 o Abstraction of the underlying network resources is provided to 333 higher-layer applications and consumers. 335 o Virtualization is achieved by selecting resources according to 336 criteria derived from the details and requirements of the 337 consumer, application, or service. 339 o Creation of a virtualized environment is performed to allow 340 operators to view and control multi-domain networks as a single 341 virtualized network. 343 o A network is presented to a consumer as a single virtual network 344 via open and programmable interfaces. 346 The ACTN managed infrastructure consists of traffic engineered 347 network resources. The concept of traffic engineering is broad: it 348 describes the planning and operation of networks using a method of 349 reserving and partitioning of network resources in order to 350 facilitate traffic delivery across a network (see 351 [I-D.ietf-teas-rfc3272bis] for more details). In the context of 352 ACTN, traffic engineering network resources may include: 354 o Statistical packet bandwidth. 356 o Physical forwarding plane sources, such as wavelengths and time 357 slots. 359 o Forwarding and cross-connect capabilities. 361 The ACTN network is "sliced" with consumers being given a different 362 partial and abstracted topology view of the physical underlay 363 network. 365 3.1. ACTN Virtual Network as a Network Slice 367 To support multiple consumers, each with its own view of and control 368 of a vrtual network constructed using a server network, a service 369 provider needs to partition the server network resources to create 370 network slices assigned to each consumer. 372 An ACTN Virtual Network (VN) is a consumer view of a slice of the 373 ACTN-managed infrastructure. It is a network slice that is presented 374 to the consumer by the ACTN provider as a set of abstracted 375 resources. See [I-D.ietf-teas-actn-vn-yang] for a detailed 376 description of ACTN VNs and an overview of how various different 377 types of YANG model are applicable to the ACTN framework. 379 Depending on the agreement between consumer and provider, various VN 380 operations are possible: 382 o Network Slice Creation: A VN could be pre-configured and created 383 through static configuration or through dynamic request and 384 negotiation between consumer and service provider. The VN must 385 meet the network slice requirements specified in the SLA to 386 satisfy the consumer's objectives. 388 o Network Slice Operations: The VN may be modified and deleted based 389 on consumer requests. The consumer can further act upon the VN to 390 manage the consumer's traffic flows across the network slice. 392 o Network Slice View: The VN topology is viewed from the consumer's 393 perspective. This may be the entire VN topology or a collection 394 of tunnels that are expressed as consumer end points, access 395 links, intra domain paths and inter-domain links. 397 [RFC8454] describes a set of functional primitives that support these 398 different ACTN VN operations. 400 3.2. Examples of ACTN Delivering Types of Network Slices 402 The examples that follow build on the ACTN framework to provide 403 control, management, and orchestration for the network slice life- 404 cycle. These network slices utilize common physical infrastructure, 405 and meet specific service-level requirements. 407 Three examples are shown. Each uses ACTN to achieve a different 408 network slicing scenario. All three scenarios can be scaled up in 409 capacity or be subject to topology changes as well as changes of 410 consumer requirements. 412 3.2.1. ACTN Used for Virtual Private Line 414 In the example shown in Figure 1, ACTN provides virtual connections 415 between multiple consumer locations (sites accessed through Customer 416 Edge nodes - CEs). The service is requested by the consumer (via 417 CNC-A) and delivered as a Virtual Private Line (VPL) service. The 418 benefits of this model include: 420 o Automated: the service set-up and operation is managed by the 421 network provider. 423 o Virtual: the private line connectivity is provided from Site A to 424 Site C (VPL1) and from Site B to Site C (VPL2) across the ACTN- 425 managed physical network. 427 o Agile: on-demand adjustments to the connectivity and bandwidth are 428 available according to the consumer's requests. 430 (Consumer VPL Request) 431 : 432 ------- 433 | CNC-A | 434 Boundary ------- 435 Between . . . . . . . . .:. . . . . . . . . . . 436 Consumer & : 437 Network Provider ------ 438 | MDSC | 439 ------ 440 : 441 ----- 442 | PNC | 443 Site A ( ----- ) Site B 444 ----- ( ) ----- 445 | CE1 |========( Physical )========| CE2 | 446 -----\ ( Network ) /----- 447 \ (_______) / 448 \ || / 449 \ || / 450 VPL1 \ || / VPL2 451 \ || / 452 \ || / 453 \ || / 454 \-------------/ 455 | CE3 | 456 ------------- 457 Site C 459 Key: ... ACTN control connectivity 460 === Physical connectivity 461 --- Logical connectivity 463 Figure 1: Virtual Private Line Model 465 3.2.2. ACTN Used for VPN Delivery Model 467 In the example shown in Figure 2, ACTN provides VPN connectivity 468 between two sites across three physical networks. The requirements 469 for the VPN are expressed by the users of the two sites who are the 470 consumers. Their requests are directed to the CNC, and the CNC 471 interacts with the network provider's MDSC. The benefits of this 472 model include: 474 o Provides edge-to-edge VPN multi-access connectivity. 476 o Most of the function is managed by the network provider, with some 477 flexibility delegated to the consumer-managed CNC. 479 -------------- -------------- 480 | Site-A Users | | Site-B Users | 481 -------------- -------------- 482 : : 483 ------------- 484 | CNC | 485 Boundary ------------- 486 Between . . . . . . . . . . . : . . . . . . . . . . . 487 Consumer & : 488 Network Provider : 489 --------------------------------- 490 | MDSC | 491 --------------------------------- 492 : : : 493 : : : 494 ------- ------- ------- 495 | PNC | | PNC | | PNC | 496 ------- ------- ------- 497 : : : 498 : : : 499 ______ --------- --------- --------- ______ 500 < > ( ) ( ) ( ) < > 501 ==( Physical )==( Physical )==( Physical )== 502 < > ( Network ) ( Network ) ( Network ) < > 503 < > ( ) ( ) ( ) < > 504 < > ------- ------- ------- < > 505 < >-----------------------------------------------< > 506 <______> <______> 508 Key: ... ACTN control connectivity 509 === Physical connectivity 510 --- Logical connectivity 512 Figure 2: VPN Model 514 3.2.3. ACTN Used to Deliver a Virtual Consumer Network 516 In the example shown in Figure 3, ACTN provides a virtual network to 517 the consumer. This virtual network is managed by the consumer. The 518 figure shows two virtual networks (Network Slice 1 and Network Slice 519 2) each created for a different consumer under the care of a 520 different CNC. There are two physical networks controlled by 521 separate PNCs. Network Slice 2 is built using resources from just 522 one physical network, while Network Slice 1 is constructed from 523 resources from both physical networks. 525 The benefits of this model include: 527 o The MDSC provides the topology to the consumer so that the 528 consumer can control their network slice to fit their needs. 530 o Applications can interact with their assigned network slices 531 directly. The consumer may implement their own network control 532 methods and traffic prioritization, and manage their own 533 addressing schemes. 535 o Consumers may further slice their vitrual networks so that this 536 becomes a recursive model. 538 o Service isolation can be provided through selection of physical 539 networking resources through a combination of efforts of the MSDC 540 and PNC. 542 o The network slice may include nodes with specific capabilities. 543 These can be delivered as Physical Network Functions (PNFs) or 544 Virtual Network Functions (VNFs). 546 ___________ 547 ------------- ( ) 548 | CNC |----------->( Network ) 549 ------------- ( Slice 2 ) 550 ^ (___________) 551 | ___________ ^ 552 ------------- ( ) : 553 | CNC |----------->( Network ) : 554 ------------- ( Slice 1 ) : 555 ^ | (___________) : 556 | | ^ ^ : 557 Boundary | | : : : 558 Between . . . .|. .|. . . . . . . . . . : . .:. . : . . . 559 Consumer & | | : : : 560 Network Provider | | : : : 561 v v : : : 562 ------------- : :....: 563 | MDSC | : : 564 ------------- : : 565 ^ ------^-- : 566 | ( ) : 567 v ( Physical ) : 568 ------- ( Network ) : 569 | PNC |<------------>( ) ---^----- 570 ------- | ------- ( ) 571 | PNC |- ( Physical ) 572 | |<-------------------------->( Network ) 573 ------- ( ) 574 ------- 576 Key: --- ACTN control connection 577 ... Virtualization/abstraction through slicing 579 Figure 3: Network Slicing 581 4. YANG Models 583 4.1. Network Slice Service Mapping from TE to ACTN VN Models 585 The role of the TE-service mapping model 586 [I-D.ietf-teas-te-service-mapping-yang] is to create a binding 587 relationship across a Layer 3 Service Model (L3SM) [RFC8049], Layer 2 588 Service Model (L2SM) [RFC8466], and TE Tunnel model 589 [I-D.ietf-teas-yang-te], via the generic ACTN Virtual Network (VN) 590 model [I-D.ietf-teas-actn-vn-yang]. 592 The ACTN VN model is a generic virtual network service model that 593 allows consumers to specify a VN (i.e., network slice) that meets the 594 consumer's service objectives with various constraints on how the 595 service is delivered. 597 The TE-service mapping model [I-D.ietf-teas-te-service-mapping-yang] 598 is used to bind the L3SM with TE-specific parameters. This binding 599 facilitates seamless service operation and enables visibility of the 600 underlay TE network. The TE-service model developed in that document 601 can also be extended to support other services including L2SM, and 602 the Layer 1 Connectivity Service Model (L1CSM) 603 [I-D.ietf-ccamp-l1csm-yang] L1CSM network service models. 605 Figure 4 shows the relationship between the models discussed above. 607 -------------- -------------- 608 | L3SM |<=======| | ---------- 609 -------------- augment| |..........>| ACTN VN | 610 -------------- | Augmented | reference ---------- 611 | L2SM |<=======| Service | 612 -------------- augment| Model | ---------- 613 -------------- | |..........>| TE-topo | 614 | L1CSM |<=======| | reference ---------- 615 -------------- augment| | 616 -------------- | | ---------- 617 | TE & Service |------->| |..........>| TE-tunnel| 618 | Mapping Types| import -------------- reference ---------- 619 -------------- 621 Figure 4: TE-Service Mapping 623 4.2. Interfaces and Yang Models 625 Figure 5 shows the three ACTN components and two ACTN interfaces as 626 listed in Section 3. The figure also shows the Southbound Interface 627 (SBI) between the PNC and the devices in the physical network. That 628 interface might be used to install state on every device in the 629 network, or might instruct a "head-end" node if a control plane is 630 used within the physical network. In the context of [RFC8309], the 631 SBI uses one or more device configuration models. 633 The figure also shows the Network Slice Service Interface. This 634 interface allows a consumer of a service to make requests for 635 delivery of the service, and it facilitates the consumer modifying 636 and monitoring the service. In the context of [RFC8309], this 637 "northbound interface (NBI)" is a customer service interface and uses 638 a service model. 640 When an ACTN system is used to manage the delivery of network slices, 641 a network slice resource model is needed. This model will be used 642 for instantiation, operation, and monitoring of network and function 643 resource slices. The YANG model defined in 644 [I-D.wd-teas-transport-slice-yang] provides a suitable basis for 645 requesting, controlling, and deleting, network slices. 647 ---------- 648 | Consumer | 649 ---------- 650 .......:....... Network Slice Service Interface 651 : 652 ------------- 653 | CNC | 654 ------------- 655 .......:....... CMI 656 : 657 --------------- 658 | MDSC | 659 --------------- 660 .......:....... MPI 661 : 662 ------- 663 | PNC | 664 ------- 665 .......:....... SBI 666 : 667 ---------- 668 ( ) 669 ( Physical ) 670 ( Network ) 671 (________) 673 Figure 5: The Yang Interfaces in Context 675 4.3. ACTN VN Telemetry 677 The ACTN VN KPI telemetry model 678 [I-D.ietf-teas-actn-pm-telemetry-autonomics] provides a way for a 679 consumer to define performance monitoring relevant for its VN/network 680 slice via the NETCONF subscription mechanisms [RFC8639], [RFC8640], 681 or using the equivalent mechanisms in RESTCONF [RFC8641], [RFC8650]. 683 Key characteristics of [I-D.ietf-teas-actn-pm-telemetry-autonomics] 684 include: 686 o An ability to provide scalable VN-level telemetry aggregation 687 based on consumer subscription model for key performance 688 parameters defined by the consumer. 690 o An ability to facilitate proactive re-optimization and 691 reconfiguration of VNs/network slices based on network autonomic 692 traffic engineering scaling configuration mechanism. 694 5. IANA Considerations 696 This document makes no requests for action by IANA. 698 6. Security Considerations 700 Network slicing involves the control of network resources in order to 701 meet the service requirements of consumers. In some deployment 702 models, the consumer is able to directly request modification in the 703 behaviour of resources owned and operated by a service provider. 704 Such changes could significantly affect the service provider's 705 ability to provide services to other consumers. Furthermore, the 706 resources allocated for or consumed by a consumer will normally be 707 billable by the service provider. 709 Therefore, it is crucial that the mechanisms used in any network 710 slicing system allow for authentication of requests, security of 711 those requests, and tracking of resource allocations. 713 It should also be noted that while the partitioning or slicing of 714 resources is virtual, as mentioned in Section 2.2 the consumers 715 expect and require that there is no risk of leakage of data from one 716 slice to another, no transfer of knowledge of the structure or even 717 existence of other slices, and that changes to one slice (under the 718 control of one consumer) should not have detrimental effects on the 719 operation of other slices (whether under control of different or the 720 same consumers) beyond the limits allowed within the SLA. Thus, 721 slices are assumed to be private and to provide the appearance of 722 genuine physical connectivity. 724 Some service providers may offer secure network slices as a service. 725 Such services may claim to include edge-to-edge encryption for the 726 consumer's traffic. However, a consumer should take full 727 responsibility for the privacy and integrity of their traffic and 728 should carefully consider using their own edge-to-edge engryption. 730 ACTN operates using the NETCONF [RFC6241] or RESTCONF [RFC8040] 731 protocols and assumes the security characteristics of those 732 protocols. Deployment models for ACTN should fully explore the 733 authentication and other security aspects before networks start to 734 carry live traffic. 736 7. Acknowledgements 738 Thanks to Qin Wu, Andy Jones, Ramon Casellas, Gert Grammel, and Kiran 739 Makhijani for their insight and useful discussions about network 740 slicing. 742 8. Contributors 744 The following people contributed text to this document. 746 Young Lee 747 Email: younglee.tx@gmail.com 749 Mohamed Boucadair 750 Email: mohamed.boucadair@orange.com 752 Sergio Belotti 753 Email: sergio.belotti@nokia.com 755 Daniele Ceccarelli 756 Email: daniele.ceccarelli@ericsson.com 758 9. Informative References 760 [I-D.ietf-ccamp-l1csm-yang] 761 Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, 762 "A YANG Data Model for L1 Connectivity Service Model 763 (L1CSM)", draft-ietf-ccamp-l1csm-yang-13 (work in 764 progress), November 2020. 766 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 767 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 768 and D. Ceccarelli, "YANG models for VN/TE Performance 769 Monitoring Telemetry and Scaling Intent Autonomics", 770 draft-ietf-teas-actn-pm-telemetry-autonomics-04 (work in 771 progress), November 2020. 773 [I-D.ietf-teas-actn-vn-yang] 774 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 775 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 776 teas-actn-vn-yang-10 (work in progress), November 2020. 778 [I-D.ietf-teas-enhanced-vpn] 779 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 780 Framework for Enhanced Virtual Private Networks (VPN+) 781 Service", draft-ietf-teas-enhanced-vpn-06 (work in 782 progress), July 2020. 784 [I-D.ietf-teas-ietf-network-slice-definition] 785 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 786 Tantsura, "Definition of IETF Network Slices", draft-ietf- 787 teas-ietf-network-slice-definition-00 (work in progress), 788 January 2021. 790 [I-D.ietf-teas-rfc3272bis] 791 Farrel, A., "Overview and Principles of Internet Traffic 792 Engineering", draft-ietf-teas-rfc3272bis-10 (work in 793 progress), December 2020. 795 [I-D.ietf-teas-te-service-mapping-yang] 796 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 797 and J. Tantsura, "Traffic Engineering (TE) and Service 798 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 799 yang-05 (work in progress), November 2020. 801 [I-D.ietf-teas-yang-te] 802 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 803 "A YANG Data Model for Traffic Engineering Tunnels, Label 804 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 805 (work in progress), July 2020. 807 [I-D.nsdt-teas-ns-framework] 808 Gray, E. and J. Drake, "Framework for Transport Network 809 Slices", draft-nsdt-teas-ns-framework-04 (work in 810 progress), July 2020. 812 [I-D.wd-teas-transport-slice-yang] 813 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data 814 Model for Transport Slice NBI", draft-wd-teas-transport- 815 slice-yang-02 (work in progress), July 2020. 817 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 818 and A. Bierman, Ed., "Network Configuration Protocol 819 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 820 . 822 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 823 Chaining (SFC) Architecture", RFC 7665, 824 DOI 10.17487/RFC7665, October 2015, 825 . 827 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 828 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 829 . 831 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 832 Model for L3VPN Service Delivery", RFC 8049, 833 DOI 10.17487/RFC8049, February 2017, 834 . 836 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 837 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 838 . 840 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 841 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 842 DOI 10.17487/RFC8453, August 2018, 843 . 845 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 846 Yoon, "Information Model for Abstraction and Control of TE 847 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 848 September 2018, . 850 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 851 Data Model for Layer 2 Virtual Private Network (L2VPN) 852 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 853 2018, . 855 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 856 E., and A. Tripathy, "Subscription to YANG Notifications", 857 RFC 8639, DOI 10.17487/RFC8639, September 2019, 858 . 860 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 861 E., and A. Tripathy, "Dynamic Subscription to YANG Events 862 and Datastores over NETCONF", RFC 8640, 863 DOI 10.17487/RFC8640, September 2019, 864 . 866 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 867 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 868 September 2019, . 870 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 871 A. Bierman, "Dynamic Subscription to YANG Events and 872 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 873 November 2019, . 875 Authors' Addresses 877 Daniel King 878 Old Dog Consulting 880 Email: daniel@olddog.co.uk 882 John Drake 883 Juniper Networks 885 Email: jdrake@juniper.net 887 Haomian Zheng 888 Huawei Technologies 890 Email: zhenghaomian@huawei.com 892 Adrian Farrel 893 Old Dog Consulting 895 Email: adrian@olddog.co.uk