idnits 2.17.1 draft-lee-rtgwg-actn-applicability-enhanced-vpn-03.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 29 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 (July 2, 2018) is 2123 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 637, but not defined == Unused Reference: 'TE-Tunnel' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'TE-topo' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'L3SM' is defined on line 764, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 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 Expires January 3, 2019 Young Lee (Editor) 5 Huawei 7 Jeff Tansura 8 Nuage 10 Qin Wu 11 Huawei 13 Daniele Ceccarelli 14 Ericsson 16 July 2, 2018 18 Applicability of Abstraction and Control of Traffic Engineered 19 Networks (ACTN) to Enhanced VPN 21 draft-lee-rtgwg-actn-applicability-enhanced-vpn-03 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 January 2, 2019. 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...........................................16 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 or DetNet/TSN 475 tunnel to guarantee 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 ... 540 augment /vn:actn/vn:vn/vn:vn-list/vn:vn-member-list: 541 +--ro vn-member-telemetry 542 +--ro unidirectional-delay? uint32 543 +--ro unidirectional-min-delay? uint32 544 +--ro unidirectional-max-delay? uint32 545 +--ro unidirectional-delay-variation? uint32 546 +--ro unidirectional-packet-loss? decimal64 547 +--ro unidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32 548 +--ro unidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32 549 +--ro unidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32 550 +--ro bidirectional-delay? uint32 551 +--ro bidirectional-min-delay? uint32 552 +--ro bidirectional-max-delay? uint32 553 +--ro bidirectional-delay-variation? uint32 554 +--ro bidirectional-packet-loss? decimal64 555 +--ro bidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32 556 +--ro bidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32 557 +--ro bidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32 558 +--ro utilized-percentage? uint8 559 +--ro te-grouped-params* -> /te:te/tunnels/tunnel/te- 560 kpi:te-telemetry/id 561 +--ro grouping-operation? grouping-operation 563 3.3. Integration 565 ACTN provides mechanisms to correlate customer's VN and the actual 566 TE tunnels instantiated in the provider's network. Specifically, 568 o Link each VN member to actual TE tunnel 569 o Each VN can be monitored on a various level such as VN level, VN 570 member level, TE-tunnel level, and link/node level. 572 Service function integration with network topology (L3 and TE 573 topology) is in progress in [sf-topology]. Specifically, [sf- 574 topology] addresses a number of use-cases that how TE topology 575 supports various service functions. 577 3.4. Dynamic Configuration 579 ACTN provides an architecture that allows the customer network 580 controller (CNC) interacts with the MDSC which is network provider's 581 SDN controller in such a way that customer is given the control of 582 their VNs. 584 Specifically, the ACTN VN model [actn-vn] allows the following 585 capabilities: 587 o Dynamic control over VN the customer creates. 588 o Create, Modify, Delete 590 See the following tree structure from [actn-vn] as an example for 591 the dynamic configuration capability (write) VN creation, modify and 592 delete. VN can be dynamically created/modified/deleted with 593 constraints such as metric types (e.g., delay), bandwidth, 594 protection, etc. 596 +--rw vn 597 +--rw vn-list* [vn-id] 598 +--rw vn-id uint32 599 +--rw vn-name? string 600 +--rw vn-topology-id? te-types:te-topology-id 601 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 602 +--rw vn-member-list* [vn-member-id] 603 | +--rw vn-member-id uint32 604 | +--rw src 605 | | +--rw src? -> /actn/ap/access-point-list/access-point-id 606 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 607 | | +--rw multi-src? boolean {multi-src-dest}? 608 | +--rw dest 609 | | +--rw dest? -> /actn/ap/access-point-list/access-point-id 610 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 611 | | +--rw multi-dest? boolean {multi-src-dest}? 612 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- 613 node-attributes/connectivity-matrices/connectivity-matrix/id 614 | +--ro oper-status? identityref 615 +--ro if-selected? boolean {multi-src-dest}? 616 +--rw admin-status? identityref 617 +--ro oper-status? identityref 618 +--rw vn-level-diversity? vn-disjointness 620 3.5. Customized Control Plane 622 ACTN provides a YANG model that allows the customer network 623 controller (CNC) to control VN via type 2 operation. Type 2 VN 624 allows the customer to provision pertinent LSPs that connect their 625 endpoints over the customized VN topology dynamically. 627 See the following tree structure from [actn-vn] as an example for 628 the provisioning of LSPs over the VN topology via TE-topology's [TE- 629 Topo] Connectivity Matrix's construct. 631 For some VN members of a VN, the customers are allowed to configure 632 the actual path (i.e., detailed virtual nodes and virtual links) 633 over the VN/abstract topology agreed mutually between CNC and MDSC 634 prior to or a topology created by the MDSC as part of VN 635 instantiation. Type 2 VN is always built on top of a Type 1 VN. If a 636 Type 2 VN is desired for some or all of VN members of a type 1 VN 637 (see the example in Section 2.1 of [ACTN-VN]), the TE-topology model 638 can provide the following abstract topology (that consists of 639 virtual nodes and virtual links) which is built on top of the Type 1 640 VN so that customers can configure path over this topology. 642 +----------------------------------------------+ 643 | S1 S2 | 644 | O---------------O | 645 | ________/ \______ \ | 646 | / \ \ | 647 |S3 / \ S4 \ S5 | 648 L1----|-O----------------------O---------O-----------|------L4 649 | \ \ \ | 650 | \ \ \ | 651 | \ S6 \ S7 \ S8 | 652 | O ----------------O---------O-------|------L7 653 | / \ / \ ____/ | 654 |S9 / \ /S10 \ / | 655 L2-----|---O-----O---------------------O--------------|------L8 656 | / S11 | 657 L3-----|-- | 658 | | 659 +----------------------------------------------+ 661 Figure 3. Type 2 topology 663 3.6. The Gaps 665 ACTN allows the customers/users to subscribe and monitor VN/Tunnel 666 level performance data such as latency. The low level latency and 667 isolation characteristics that are sought by some VPN+ users such as 668 steering packets through specific queues resources are not in the 669 scope of ACTN. 671 This implies that the device-level performance data such as queuing 672 delay caused by various queuing mechanisms needs to be characterized 673 and monitored by a device level YANG PM model. Then the Domain SDN 674 controller (PNC) will need to estimate Domain LSP level PM data from 675 device-level PM data. Finally, the MDSC will need to derive 676 VN/Tunnel level PM data and present to the customers. 678 Another gap that needs to be filled up is how to coordinate non-TE 679 element from the routing and signaling standpoints. Currently, ACTN 680 is limited to TE elements. From an end-to-end network standpoint, 681 the scope of VPN+ may encompass non-TE elements in some 682 segments/domains as well as TE elements. How to seamlessly provide 683 end-to-end tunnel management and the operations of abstraction of 684 resources across non-TE and TE elements of the network will need to 685 be worked out further. 687 4. Security Considerations 689 Virtual network instantiation involves the control of network 690 resources in order to meet the service requirements of consumers. 691 In some deployment models, the consumer is able to directly request 692 modification in the behaviour of resources owned and operated by a 693 service provider. Such changes could significantly affect the 694 service provider's ability to provide services to other consumers. 695 Furthermore, the resources allocated for or consumed by a consumer 696 will normally be billable by the service provider. 698 Therefore, it is crucial that the mechanisms used in any virtual 699 network system allow for authentication of requests, security of 700 those requests, and tracking of resource allocations. 702 It should also be noted that while the partitioning of resources is 703 virtual, the consumers expect and require that there is no risk of 704 leakage of data from one slice to another, no transfer of knowledge 705 of the structure or even existence of other virtual networks, and 706 that changes to one virtual network (under the control of one 707 consumer) should not have detrimental effects on the operation of 708 other virtual networks (whether under control of different or the 709 same consumers) beyond the limits allowed within the SLA. Thus, 710 virtual networks are assumed to be private and to provide the 711 appearance of genuine physical connectivity. 713 ACTN operates using the [netconf] or [restconf] protocols and 714 assumes the security characteristics of those protocols. Deployment 715 models for ACTN should fully explore the authentication and other 716 security aspects before networks start to carry live traffic. 718 5. IANA Considerations 720 This document has no actions for IANA. 722 6. Acknowledgements 724 Thanks to James Guichard, Stewart Bryant, Dong Jie for their insight 725 and useful discussions about VPN+. 727 7. References 729 7.1. Informative References 731 [actn-framework] Ceccarelli, D. and Y. Lee, "Framework for 732 Abstraction and Control of Traffic Engineered Networks", 733 draft-ietf-teas-actn-framework, work in progress, February 734 2017. 736 [te-service-map] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic 737 Engineering and Service Mapping Yang Model", draft-lee- 738 teas-te-service-mapping-yang, work in progress. 740 [actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN 741 Operation", draft-lee-teas-actn-vn-yang, work in progress. 743 [actn-info] Y. Lee, S. Belotti (Editors), "Information Model for 744 Abstraction and Control of TE Networks (ACTN)", draft- 745 ietf-teas-actn-info-model, work in progress. 747 [actn-pm-elemetry] Y. Lee, et al, "YANG models for ACTN TE 748 Performance Monitoring Telemetry and Network 749 Autonomics",draft-lee-teas-actn-pm-telemetry-autonomics, 750 work in progress. 752 [vpn+] S. Bryant, and D. Jie, "Enhanced Virtual Private Networks 753 (VPN+)", draft-bryant-rtgwg-enhanced-vpn, work in 754 progress. 756 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 757 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 758 te, work in progress. 760 [TE-topo] X. Liu, et. al, "YANG Data Model for Traffic Engineering 761 (TE) Topologies", draft-ietf-teas-yang-te-topo, work in 762 progress. 764 [L3SM] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model for 765 L3VPN service delivery", draft-ietf-l3sm-l3vpn-service- 766 model, work in progress. 768 [L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service 769 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 770 progress. 772 [L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity 773 Service Model (L1CSM)", draft-fioccola-ccamp-l1csm-yang, 774 work in progress. 776 8. Contributors 778 Authors' Addresses 780 Daniel King 781 Lancaster University 782 Email: d.king@lancaster.ac.uk 784 Young Lee (Editor) 785 Huawei 786 Phone: (469)277-5838 787 Email: leeyoung@huawei.com 789 Jeff Tansura 790 Futurewei 791 Email: jefftant.ietf@gmail.com 793 Qin Wu 794 Huawei Technologies Co.,Ltd. 795 Email: bill.wu@huawei.com 797 Daniele Ceccarelli 798 Ericsson 799 Email: daniele.ceccarelli@ericsson.com