idnits 2.17.00 (12 Aug 2021) /tmp/idnits40811/draft-lee-rtgwg-actn-applicability-enhanced-vpn-02.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 : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2018) is 1422 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'L3sm' is mentioned on line 378, but not defined == Missing Reference: 'TE-tunnel' is mentioned on line 380, but not defined == Missing Reference: 'ACTN-VN' is mentioned on line 640, but not defined == Unused Reference: 'TE-Tunnel' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'TE-topo' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'L3SM' is defined on line 767, but no explicit reference was found in the text == Outdated reference: draft-ietf-teas-yang-te-topo has been published as RFC 8795 == Outdated reference: draft-ietf-l3sm-l3vpn-service-model has been published as RFC 8049 == Outdated reference: draft-ietf-l2sm-l2vpn-service-model has been published as RFC 8466 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTGWG Working Group Daniel King 2 Internet Draft Lancaster University 3 Intended status: Informational 4 Young Lee (Editor) 5 Huawei 7 Expires: December 29, 2018 Jeff Tansura 8 Nuage 10 Qin Wu 11 Huawei 13 Daniele Ceccarelli 14 Ericsson 16 June 29, 2018 18 Applicability of Abstraction and Control of Traffic Engineered 19 Networks (ACTN) to Enhanced VPN 21 draft-lee-rtgwg-actn-applicability-enhanced-vpn-02 23 Abstract 25 The Abstraction and Control of Traffic Engineered Networks (ACTN) 26 defines an SDN-based architecture that relies on the concepts of 27 network and service abstraction to detach network and service 28 control from the underlying data plane. 30 This document outlines the overview of ACTN capability and the 31 applicability of ACTN to Enhanced VPN. In particular, this document 32 also discusses how ACTN features can fulfill some of the 33 requirements of the enhanced VPN, which is also known as VPN+ 34 [VPN+]. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on December 29, 2018. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with 69 respect to this document. Code Components extracted from this 70 document must include Simplified BSD License text as described in 71 Section 4.e of the Trust Legal Provisions and are provided without 72 warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction...................................................3 77 2. ACTN Overview..................................................3 78 2.1. ACTN Virtual Network......................................4 79 2.2. Examples of ACTN Delivering Types of Virtual Networks.....5 80 2.2.1. ACTN Used for Virtual Private Line Model.............6 81 2.2.2. ACTN Used for VPN Delivery Model.....................7 82 2.2.3. ACTN Used to Deliver a Virtual Customer Network......8 83 2.3. Service Mapping from TE to ACTN VN Models.................9 84 2.4. ACTN VN KPI telemetry Models.............................10 85 3. Enhanced VPN and ACTN.........................................10 86 3.1. Isolation between VPNs...................................11 87 3.2. Guaranteed Performance...................................11 88 3.3. Integration..............................................13 89 3.4. Dynamic Configuration....................................13 90 3.5. Customized Control Plane.................................14 91 3.6. The Gaps.................................................15 92 4. Security Considerations.......................................16 93 5. IANA Considerations...........................................17 94 6. Acknowledgements..............................................17 95 7. References....................................................17 96 7.1. Informative References...................................17 97 8. Contributors..................................................18 98 Authors' Addresses...............................................18 100 1. Introduction 102 The Abstraction and Control of Traffic Engineered Networks (ACTN) 103 defines an SDN-based architecture that relies on the concepts of 104 network and service abstraction to detach network and service 105 control from the underlying data plane. 107 This document outlines the overview of ACTN capability and the 108 applicability of ACTN to Enhanced VPN. In particular, this document 109 also discusses how ACTN features can fulfill some of the key 110 requirements of the enhanced VPN, which is also known as VPN+ 111 [VPN+]. 113 2. ACTN Overview 115 The framework for ACTN [actn-framework] includes a reference 116 architecture that has been adapted for Figure 1 in this document, it 117 describes the functional entities and methods for the coordination 118 of resources across multiple domains, to provide end-to-end 119 services, components include: 121 o Customer Network Controller (CNC); 123 o Multi-domain Service Coordinator (MDSC); 125 o Provisioning Network Controller (PNC). 127 --------- --------- --------- 128 | CNC-A | | CNC-B | | CNC-C | 129 --------- --------- --------- 130 \ | / 131 \__________ |-CMI I/F __________/ 132 \ | / 133 ------------------------- 134 | MDSC | 135 ------------------------- 136 / / | \ 137 / / |-MPI I/F \ 138 / / | \ 139 ------- ------- ------- ------- 140 | PNC | | PNC | | PNC | | PNC | 141 ------- ------- ------- ------- 143 CMI - (CNC-MDSC Interface) 144 MPI - (MDSC-PNC Interface) 146 Figure 1: ACTN Hierarchy 147 ACTN facilitates end-to-end connections and provides them to the 148 user. The ACTN framework highlights how: 150 o Abstraction of the underlying network resources are provided to 151 higher-layer applications and customers; 153 o Virtualization of underlying resources, whose selection 154 criterion is the allocation of those resources for the 155 customer, application, or service; 157 o Creation of a virtualized environment allowing operators to 158 view and control multi-domain networks as a single virtualized 159 network; 161 o The presentation to customers of networks as a virtual network 162 via open and programmable interfaces. 164 The ACTN managed infrastructure are traffic engineered network 165 resources, which may include: 167 o Statistical packet bandwidth; 169 o Physical forwarding plane sources, such as: wavelengths and 170 time slots; 172 o Forwarding and cross connect capabilities. 174 The ACTN type of network virtualization provides customers and 175 applications (tenants) to utilize and independently control 176 allocated virtual network resources as if resources as if they were 177 physically their own resource. 179 2.1. ACTN Virtual Network 181 To support multiple clients each with its own view of and control of 182 the server network, a network operator needs to partition the 183 network resources. The resulting partition can be assigned to each 184 client for guaranteed usage which is a step further than shared use 185 of common network resources. See [actn-vn] for detailed ACTN VN and 186 VNS. 188 An ACTN Virtual Network (VN) is a client view of the ACTN managed 189 infrastructure, and is presented by the ACTN provider as a set of 190 abstracted resources. 192 Depending on the agreement between client and provider various VN 193 operations and VN views are possible. 195 o Virtual Network Creation: A VN could be pre-configured and 196 created via static or dynamic request and negotiation between 197 customer and provider. It must meet the specified SLA 198 attributes which satisfy the customer's objectives. 200 o Virtual Network Operations: The virtual network may be further 201 modified and deleted based on customer request to request 202 changes in the network resources reserved for the customer, and 203 used to construct the network slice. The customer can further 204 act upon the virtual network to manage traffic flow across the 205 virtual network. 207 o Virtual Network View: The VN topology from a customer point of 208 view. These may be a variety of tunnels, or an entire VN 209 topology. Such connections may comprise of customer end points, 210 access links, intra domain paths and inter-domain links. 212 Dynamic VN Operations allow a customer to modify or delete the VN. 213 The customer can further act upon the virtual network to 214 create/modify/delete virtual links and nodes. These changes will 215 result in subsequent tunnel management in the operator's networks. 217 Primitives (capabilities and messages) have been provided to support 218 the different ACTN network control functions that will enable 219 virtual network. These include: topology request/query, VN service 220 request, path computation and connection control, VN service policy 221 negotiation, enforcement, routing options. [actn-info] 223 2.2. Examples of ACTN Delivering Types of Virtual Networks 225 In examples below the ACTN framework is used to provide control, 226 management and orchestration for the virtual network life-cycle, and 227 the connectivity. These dynamic and highly flexible, end-to-end and 228 dedicated virtual network utilizing common physical infrastructure, 229 and according to vertical-specific requirements. 231 The rest of this section provides three examples of using ACTN to 232 achieve different scenarios of ACTN for virtual network. All three 233 scenarios can be scaled up in capacity or be subject to topology 234 changes as well as changes from customer requirements perspective. 236 2.2.1. ACTN Used for Virtual Private Line Model 238 ACTN provides virtual connections between multiple customer 239 locations, requested via Virtual Private Line (VPL) requester (CNC- 240 A). Benefits of this model include: 242 o Automated: the service set-up and operation is network provider 243 managed; 245 o Virtual: the private line is seamlessly extended from customers 246 Site A (vCE1 to vCE3) and Site B (vCE2 to vCE3) across the 247 ACTN-managed WAN to Site C; 249 o Agile: on-demand where the customer needs connectivity and 250 fully adjustable bandwidth. 252 (Customer VPL Request) 253 | 254 --------- 255 | CNC-A | 256 Boundary --------- 257 Between ====================|==================== 258 Customer & | 259 Network Operator -------- 260 | MDSC | 261 -------- 262 __|__ 263 Site A ( PNC ) Site B 264 ------ ( ) ------ 265 |vCE1|=============( Phys. )=============|vCE2| 266 ------ ( Net ) ------ 267 \ ----- / 268 \ || / 269 \ || / 270 VPL 1 \__ || __/ VPL 2 271 \ || / 272 \ || / 273 \ ------ / 274 ------|vCE3|----- 275 ------ 276 Site C 278 Figure 2: Virtual Private Line Model 280 2.2.2. ACTN Used for VPN Delivery Model 282 ACTN provides VPN connections between multiple sites, requested Via 283 a VPN requestor (CNC-A), which is managed by the customer 284 themselves. The CNC will then interact with the network provider's 285 MDSC. Benefits of this model include: 287 o Provides edge-to-edge VPN multi-access connection; 289 o Mostly network provider managed, with some flexibility 290 delegated to the customer managed CNC. 292 ---------------- ---------------- 293 | Site-A Users |___________ ____________| Site-B Users | 294 ---------------- | | ---------------- 295 ------- 296 |CNC-A| 297 Boundary ------- 298 Between ==========================|========================== 299 Customer & | 300 Network Operator | 301 | 302 --------------- 303 | MDSC | 304 --------------- 305 _________/ | \__________ 306 / | \ 307 / | \ 308 --------- --------- --------- 309 | PNC | | PNC | | PNC | 310 --------- --------- --------- 311 | | / 312 | | / 313 ----- ----- ----- 314 ( ) ( ) ( ) 315 ----( Phys. )------------( Phys. )-------( Phys. )---- 316 ( Net ) ( Net ) ( Net ) 317 ----- ----- ----- 319 Figure 3: VPN Model 321 2.2.3. ACTN Used to Deliver a Virtual Customer Network 323 In this example ACTN provides a virtual network resource to the 324 customer. This resource is customer managed. Empowering the tenant 325 to control allocated VN (recursively). Benefits of this model 326 include: 328 o The MDSC provides the topology as part of the customer view so 329 that the customer can control their network slice to fit their 330 needs; 332 o Resource isolation, each customer network slice is fixed and 333 will not be affected by changes to other customer network 334 slices; 336 o Applications can interact with their assigned network slice 337 directly, the customer may implement their own network control 338 method and traffic prioritization, manage their own addressing 339 scheme, and further slice their assigned network resource; 341 o The network slice may also include specific capability nodes, 342 delivered as Physical Network Functions (PNFs) or Virtual 343 Network Functions (VNFs). 345 ___________ 346 --------------- ( Virtual ) 347 | CNC |---------->( Network 2 ) 348 --------------- _(_________ ) 349 --------------- ( Virtual )_) 350 | CNC |----------->( Network 2 ) ^ 351 --------------- ( ) : 352 ^ (___________) : 353 | ^ ^ : 354 Boundary | : : : 355 Between ==========|========================:====:====:======== 356 Customer & | : : : 357 Network Operator | : : : 358 v : : : 359 --------------- : :....: 360 | MDSC | : : 361 --------------- : : 362 ^ ---^------ ... 364 | ( ) . 365 v ( Physical ) . 366 ---------------- ( Network ) . 367 | PNC |<------> ( ) ---^------ 368 ---------------- | -------- ( ) 369 | |-- ( Physical ) 370 | PNC |<------------------------->( Network ) 371 --------------- ( ) 372 -------- 373 Figure 4: Virtual Customer Networks 375 2.3. Service Mapping from TE to ACTN VN Models 377 The role of TE-service mapping model [te-service-mapping] is to 378 create a binding relationship across a Layer-3 Service Model [L3sm], 379 Layer-2 Service Model [L2SM], Layer-1 Service Model [L1CSM], and TE 380 Tunnel model [TE-tunnel], via a generic ACTN Virtual Network (VN) 381 model [actn-vn]. 383 The ACTN VN YANG model [actn-vn] is a generic virtual network 384 service model that allows customers (internal or external) to create 385 a VN that meets the customer's service objective with various 386 constraints. 388 +---------+ +-------------+ +----------+ 389 | L3SM | <------> | | <-----> | ACTN VN | 390 +---------+ | | | Model | 391 | | +-----^----+ 392 | | | 393 +---------+ | TE-Service | +-----v----+ 394 | L2SM | <------> |Mapping Model| <-----> | TE-Topo | 395 +---------+ | | | Model | 396 | | +----------+ 397 | | 398 +---------+ | | +----------+ 399 | L1CSM | <------> | | <-----> | TE-Tunnel| 400 +---------+ | | | Model | 401 +-------------+ +----------+ 403 Figure 5: TE-Service Mapping ([te-service-mapping]) 405 The TE-service mapping model [te-service-map] is needed to bind 406 L1/2/3 VPN specific service requirements and policies pertaining to 407 TE-specific parameters. For example, the model can express the 408 isolation requirement for each VPN service instance. Some VPN 409 service would require a strict hard isolation with deterministic 410 characteristic. In such case the underlay TE networks has to find 411 end-to-end tunnels/LSPs that satisfy this particular isolation 412 requirement. 414 This binding will facilitate a seamless service operation with 415 underlay-TE network visibility. The TE-service model developed in 416 this document can also be extended to support other services 417 including L2SM, and L1CSM. 419 2.4. ACTN VN KPI telemetry Models 421 The role of ACTN VN KPI telemetry model [actn-pm-telemetry] is to 422 provide YANG models so that customer can define key performance 423 monitoring data relevant for its VN via the YANG subscription model. 425 Key characteristics of [actn-pm-telemetry] include: 427 o an ability to provide scalable VN-level telemetry aggregation 428 based on customer-subscription model for key performance 429 parameters defined by the customer; 431 o an ability to facilitate proactive re-optimization and 432 reconfiguration of VNs based on network 433 autonomic traffic engineering scaling configuration 434 mechanism. 436 3. Enhanced VPN and ACTN 438 This section discusses how the advanced features of ACTN discussed 439 in Section 3 can fulfill the enhanced VPN requirements defined in 440 [vpn+]. Key requirements of the enhanced VPN include: 442 1. Isolation between VPNs 443 2. Guaranteed Performance 444 3. Integration 445 4. Dynamic Configuration 446 5. Customized Control Plane 448 Simple creation, deletion and modification of the services. 449 Control over VPN Seamless integration of both physical and virtual 450 network and service functions 451 In the subsequent sections, we discuss how each requirement can be 452 fulfilled by the ACTN features and the gaps that remain to be solved 453 if applicable. 455 3.1. Isolation between VPNs 457 The ACTN VN YANG model [actn-vn] and the TE-service mapping model 458 [te-service-mapping] fulfill the isolation requirement by providing 459 the features. 461 o Each VN is identified with a unique identifier (vn-id and vn- 462 name) and so is each VN member that belongs to the VN (vn- 463 member-id). 465 o Each instantiated VN is managed and controlled independent of 466 other VNs in the network with proper protection level 467 (protection) 469 o Each VN is instantiated with proper isolation requirement 470 mapping introduced by the TE-service mapping model [te- 471 service-mapping]. This mapping can support: 473 o hard isolation with deterministic characteristics (e.g., 474 this case may need optical bypass tunnel to guarantee 475 latency with no jitter); 476 o hard isolation (i.e., dedicated TE resources in all 477 layers (e.g., packet and optical)); 478 o soft isolation (i.e., optical layer may be shared while 479 packet layer is dedicated); 480 o no isolation (i.e., sharing with other VN). 482 3.2. Guaranteed Performance 484 Performance objectives of a VN need first to be expressed in order 485 to assure the performance guarantee. [actn-vn] and [te-topo] allow 486 configuration of several parameters that may affect the VN 487 performance objectives. Among the performance-related parameters per 488 a VN level provided by [actn-vn] and [te-topo] are as follows: 490 o Bandwidth 491 o Objective function (e.g., min cost path, min load path, etc.) 492 o Metric Types and their threshold: 493 o TE cost, IGP cost, Hop count, or Unidirectional Delay (e.g., 494 can set all path delay <= threshold) 496 See the below actn-vn tree structure for the pointer for the 497 connectivity matrix identifier for each vn member in which the 498 configuration parameters listed above is provisioned using [te-topo] 499 model together with [te-tunnel] model in the network. 501 +--rw vn 502 +--rw vn-list* [vn-id] 503 +--rw vn-id uint32 504 +--rw vn-name? string 505 +--rw vn-topology-id? te-types:te-topology-id 506 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 507 +--rw vn-member-list* [vn-member-id] 508 | +--rw vn-member-id uint32 509 | +--rw src 510 | | +--rw src? -> /actn/ap/access-point-list/access-point-id 511 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 512 | | +--rw multi-src? boolean {multi-src-dest}? 513 | +--rw dest 514 | | +--rw dest? -> /actn/ap/access-point-list/access-point- 515 id 516 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 517 | | +--rw multi-dest? boolean {multi-src-dest}? 518 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- 519 node-attributes/connectivity-matrices/connectivity-matrix/id 520 | +--ro oper-status? identityref 521 +--ro if-selected? boolean {multi-src-dest}? 522 +--rw admin-status? identityref 523 +--ro oper-status? identityref 524 +--rw vn-level-diversity? vn-disjointness 526 Once these requests are instantiated, the resources are committed 527 and guaranteed through the life cycle of the VN. 529 [actn-pm-telemetry] provides models that allow for key performance 530 telemetry configuration mechanisms per VN level, VN member level as 531 well as path/link level. 533 The following tree structure from [actn-pm-telemetry] illustrates 534 how performance data (e.g., delay, delay-variation, utilization, 535 etc.) can be subscribed per VN need and monitored via YANG push 536 streaming mechanism. 538 module: ietf-actn-te-kpi-telemetry 539 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list: 540 +--ro vn-member-telemetry 541 +--ro unidirectional-delay? uint32 542 +--ro unidirectional-min-delay? uint32 543 +--ro unidirectional-max-delay? uint32 544 +--ro unidirectional-delay-variation? uint32 545 +--ro unidirectional-packet-loss? decimal64 546 +--ro unidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32 547 +--ro unidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32 548 +--ro unidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32 549 +--ro bidirectional-delay? uint32 550 +--ro bidirectional-min-delay? uint32 551 +--ro bidirectional-max-delay? uint32 552 +--ro bidirectional-delay-variation? uint32 553 +--ro bidirectional-packet-loss? decimal64 554 +--ro bidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32 555 +--ro bidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32 556 +--ro bidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32 557 +--ro utilized-percentage? uint8 558 +--ro vn-ref? -> /actn-vn:actn/vn/vn-list/vn- 559 id 560 +--ro vn-member-ref? -> /actn-vn:actn/vn/vn-list/vn- 561 member-list/vn-member-id 562 +--ro te-grouped-params* -> 563 /te:te/tunnels/tunnel/state/te-kpi:te-telemetry/id 564 ...... 566 3.3. Integration 568 ACTN provides mechanisms to correlate customer's VN and the actual 569 TE tunnels instantiated in the provider's network. Specifically, 571 o Link each VN member to actual TE tunnel 572 o Each VN can be monitored on a various level such as VN level, VN 573 member level, TE-tunnel level, and link/node level. 575 Service function integration with network topology (L3 and TE 576 topology) is in progress in [sf-topology]. Specifically, [sf- 577 topology] addresses a number of use-cases that how TE topology 578 supports various service functions. 580 3.4. Dynamic Configuration 582 ACTN provides an architecture that allows the customer network 583 controller (CNC) interacts with the MDSC which is network provider's 584 SDN controller in such a way that customer is given the control of 585 their VNs. 587 Specifically, the ACTN VN model [actn-vn] allows the following 588 capabilities: 590 o Dynamic control over VN the customer creates. 591 o Create, Modify, Delete 593 See the following tree structure from [actn-vn] as an example for 594 the dynamic configuration capability (write) VN creation, modify and 595 delete. VN can be dynamically created/modified/deleted with 596 constraints such as metric types (e.g., delay), bandwidth, 597 protection, etc. 599 +--rw vn 600 +--rw vn-list* [vn-id] 601 +--rw vn-id uint32 602 +--rw vn-name? string 603 +--rw vn-topology-id? te-types:te-topology-id 604 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 605 +--rw vn-member-list* [vn-member-id] 606 | +--rw vn-member-id uint32 607 | +--rw src 608 | | +--rw src? -> /actn/ap/access-point-list/access-point-id 609 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 610 | | +--rw multi-src? boolean {multi-src-dest}? 611 | +--rw dest 612 | | +--rw dest? -> /actn/ap/access-point-list/access-point-id 613 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 614 | | +--rw multi-dest? boolean {multi-src-dest}? 615 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- 616 node-attributes/connectivity-matrices/connectivity-matrix/id 617 | +--ro oper-status? identityref 618 +--ro if-selected? boolean {multi-src-dest}? 619 +--rw admin-status? identityref 620 +--ro oper-status? identityref 621 +--rw vn-level-diversity? vn-disjointness 623 3.5. Customized Control Plane 625 ACTN provides a YANG model that allows the customer network 626 controller (CNC) to control VN via type 2 operation. Type 2 VN 627 allows the customer to provision pertinent LSPs that connect their 628 endpoints over the customized VN topology dynamically. 630 See the following tree structure from [actn-vn] as an example for 631 the provisioning of LSPs over the VN topology via TE-topology's [TE- 632 Topo] Connectivity Matrix's construct. 634 For some VN members of a VN, the customers are allowed to configure 635 the actual path (i.e., detailed virtual nodes and virtual links) 636 over the VN/abstract topology agreed mutually between CNC and MDSC 637 prior to or a topology created by the MDSC as part of VN 638 instantiation. Type 2 VN is always built on top of a Type 1 VN. If a 639 Type 2 VN is desired for some or all of VN members of a type 1 VN 640 (see the example in Section 2.1 of [ACTN-VN]), the TE-topology model 641 can provide the following abstract topology (that consists of 642 virtual nodes and virtual links) which is built on top of the Type 1 643 VN so that customers can configure path over this topology. 645 +----------------------------------------------+ 646 | S1 S2 | 647 | O---------------O | 648 | ________/ \______ \ | 649 | / \ \ | 650 |S3 / \ S4 \ S5 | 651 L1----|-O----------------------O---------O-----------|------L4 652 | \ \ \ | 653 | \ \ \ | 654 | \ S6 \ S7 \ S8 | 655 | O ----------------O---------O-------|------L7 656 | / \ / \ ____/ | 657 |S9 / \ /S10 \ / | 658 L2-----|---O-----O---------------------O--------------|------L8 659 | / S11 | 660 L3-----|-- | 661 | | 662 +----------------------------------------------+ 664 Figure 3. Type 2 topology 666 3.6. The Gaps 668 ACTN allows the customers/users to subscribe and monitor VN/Tunnel 669 level performance data such as latency. The low level latency and 670 isolation characteristics that are sought by some VPN+ users such as 671 steering packets through specific queues resources are not in the 672 scope of ACTN. 674 This implies that the device-level performance data such as queuing 675 delay caused by various queuing mechanisms needs to be characterized 676 and monitored by a device level YANG PM model. Then the Domain SDN 677 controller (PNC) will need to estimate Domain LSP level PM data from 678 device-level PM data. Finally, the MDSC will need to derive 679 VN/Tunnel level PM data and present to the customers. 681 Another gap that needs to be filled up is how to coordinate non-TE 682 element from the routing and signaling standpoints. Currently, ACTN 683 is limited to TE elements. From an end-to-end network standpoint, 684 the scope of VPN+ may encompass non-TE elements in some 685 segments/domains as well as TE elements. How to seamlessly provide 686 end-to-end tunnel management and the operations of abstraction of 687 resources across non-TE and TE elements of the network will need to 688 be worked out further. 690 4. Security Considerations 692 Virtual network instantiation involves the control of network 693 resources in order to meet the service requirements of consumers. 694 In some deployment models, the consumer is able to directly request 695 modification in the behaviour of resources owned and operated by a 696 service provider. Such changes could significantly affect the 697 service provider's ability to provide services to other consumers. 698 Furthermore, the resources allocated for or consumed by a consumer 699 will normally be billable by the service provider. 701 Therefore, it is crucial that the mechanisms used in any virtual 702 network system allow for authentication of requests, security of 703 those requests, and tracking of resource allocations. 705 It should also be noted that while the partitioning of resources is 706 virtual, the consumers expect and require that there is no risk of 707 leakage of data from one slice to another, no transfer of knowledge 708 of the structure or even existence of other virtual networks, and 709 that changes to one virtual network (under the control of one 710 consumer) should not have detrimental effects on the operation of 711 other virtual networks (whether under control of different or the 712 same consumers) beyond the limits allowed within the SLA. Thus, 713 virtual networks are assumed to be private and to provide the 714 appearance of genuine physical connectivity. 716 ACTN operates using the [netconf] or [restconf] protocols and 717 assumes the security characteristics of those protocols. Deployment 718 models for ACTN should fully explore the authentication and other 719 security aspects before networks start to carry live traffic. 721 5. IANA Considerations 723 This document has no actions for IANA. 725 6. Acknowledgements 727 Thanks to James Guichard, Stewart Bryant, Dong Jie for their insight 728 and useful discussions about VPN+. 730 7. References 732 7.1. Informative References 734 [actn-framework] Ceccarelli, D. and Y. Lee, "Framework for 735 Abstraction and Control of Traffic Engineered Networks", 736 draft-ietf-teas-actn-framework, work in progress, February 737 2017. 739 [te-service-map] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic 740 Engineering and Service Mapping Yang Model", draft-lee- 741 teas-te-service-mapping-yang, work in progress. 743 [actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN 744 Operation", draft-lee-teas-actn-vn-yang, work in progress. 746 [actn-info] Y. Lee, S. Belotti (Editors), "Information Model for 747 Abstraction and Control of TE Networks (ACTN)", draft- 748 ietf-teas-actn-info-model, work in progress. 750 [actn-pm-elemetry] Y. Lee, et al, "YANG models for ACTN TE 751 Performance Monitoring Telemetry and Network 752 Autonomics",draft-lee-teas-actn-pm-telemetry-autonomics, 753 work in progress. 755 [vpn+] S. Bryant, and D. Jie, "Enhanced Virtual Private Networks 756 (VPN+)", draft-bryant-rtgwg-enhanced-vpn, work in 757 progress. 759 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 760 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 761 te, work in progress. 763 [TE-topo] X. Liu, et. al, "YANG Data Model for Traffic Engineering 764 (TE) Topologies", draft-ietf-teas-yang-te-topo, work in 765 progress. 767 [L3SM] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model for 768 L3VPN service delivery", draft-ietf-l3sm-l3vpn-service- 769 model, work in progress. 771 [L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service 772 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 773 progress. 775 [L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity 776 Service Model (L1CSM)", draft-fioccola-ccamp-l1csm-yang, 777 work in progress. 779 8. Contributors 781 Authors' Addresses 783 Daniel King 784 Lancaster University 785 Email: d.king@lancaster.ac.uk 787 Young Lee (Editor) 788 Huawei 789 Phone: (469)277-5838 790 Email: leeyoung@huawei.com 792 Jeff Tansura 793 Futurewei 794 Email: jefftant.ietf@gmail.com 796 Qin Wu 797 Huawei Technologies Co.,Ltd. 798 Email: bill.wu@huawei.com 800 Daniele Ceccarelli 801 Ericsson 802 Email: daniele.ceccarelli@ericsson.com