idnits 2.17.00 (12 Aug 2021) /tmp/idnits40517/draft-lee-rtgwg-actn-applicability-enhanced-vpn-01.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 27 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 == Line 634 has weird spacing: '...mber-id uin...' == Line 639 has weird spacing: '...ment-id uin...' -- The document date (May 14, 2018) is 1468 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 == Unused Reference: 'TE-Tunnel' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'L3SM' is defined on line 741, but no explicit reference was found in the text == 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 (~~), 9 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 5 Huawei 7 Expires: November 14, 2018 Jeff Tansura 8 Nuage 10 Qin Wu 11 Huawei 13 Daniele Ceccarelli 14 Ericsson 16 May 14, 2018 18 Applicability of Abstraction and Control of Traffic Engineered 19 Networks (ACTN) to Enhanced VPN 21 draft-lee-rtgwg-actn-applicability-enhanced-vpn-01 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 November 14, 2018. 59 Copyright Notice 61 Copyright (c) 2017 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...................................10 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.......................................15 93 5. IANA Considerations...........................................16 94 6. Acknowledgements..............................................16 95 7. References....................................................16 96 7.1. Informative References...................................16 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 Provisional 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 The TE-service mapping model is needed to bind L3VPN specific 389 service model with TE-specific parameters. This binding will 390 facilitate a seamless service operation with underlay-TE network 391 visibility. The TE-service model developed in this document can also 392 be extended to support other services including L2SM, and L1CSM. 394 +---------+ +-------------+ +----------+ 395 | L3SM | <------> | | <-----> | ACTN VN | 396 +---------+ | | | Model | 397 | | +----------+ 398 | | 399 +---------+ | TE-Service | +----------+ 400 | L2SM | <------> |Mapping Model| <-----> | TE-Topo | 401 +---------+ | | | Model | 402 | | +----------+ 403 | | 404 +---------+ | | +----------+ 405 | L1CSM | <------> | | <-----> | TE-Tunnel| 406 +---------+ | | | Model | 407 +-------------+ +----------+ 409 Figure 5: TE-Service Mapping ([te-service-mapping]) 411 2.4. ACTN VN KPI telemetry Models 413 The role of ACTN VN KPI telemetry model [actn-pm-telemetry] is to 414 provide YANG models so that customer can define key performance 415 monitoring data relevant for its VN via the YANG subscription model. 417 Key characteristics of [actn-pm-telemetry] include: 419 o an ability to provide scalable VN-level telemetry aggregation 420 based on customer-subscription model for key performance 421 parameters defined by the customer; 423 o an ability to facilitate proactive re-optimization and 424 reconfiguration of VNs based on network 425 autonomic traffic engineering scaling configuration 426 mechanism. 428 3. Enhanced VPN and ACTN 430 This section discusses how the advanced features of ACTN discussed 431 in Section 3 can fulfill the enhanced VPN requirements defined in 432 [vpn+]. Key requirements of the enhanced VPN include: 434 1. Isolation between VPNs 435 2. Guaranteed Performance 436 3. Integration 437 4. Dynamic Configuration 438 5. Customized Control Plane 440 Simple creation, deletion and modification of the services. 441 Control over VPN Seamless integration of both physical and virtual 442 network and service functions 444 In the subsequent sections, we discuss how each requirement can be 445 fulfilled by the ACTN features and the gaps that remain to be solved 446 if applicable. 448 3.1. Isolation between VPNs 450 The ACTN VN YANG model [actn-vn] and the TE-service mapping model 451 [te-service-mapping] fulfill the isolation requirement by providing 452 the features. 454 o Each VN is identified with a unique identifier (vn-id and vn- 455 name) and so is each VN member that belongs to the VN (vn- 456 member-id). 458 o Each instantiated VN is managed and controlled independent of 459 other VNs in the network with proper protection level 460 (protection) 462 o Each VN is instantiated with proper isolation requirement 463 mapping introduced by the TE-service mapping model [te- 464 service-mapping]. This mapping can support hard isolation 465 (i.e., dedicated TE resources in all layers (e.g., packet and 466 optical)), soft isolation (i.e., optical layer may be shared 467 while packet layer is dedicated) and no isolation (i.e., 468 sharing with other VN). 470 3.2. Guaranteed Performance 472 Performance objectives of a VN need first to be expressed in order 473 to assure the performance guarantee. [actn-vn] and [te-topo] allow 474 configuration of several parameters that may affect the VN 475 performance objectives. Among the performance-related parameters per 476 a VN level provided by [actn-vn] and [te-topo] are as follows: 478 o Bandwidth 479 o Objective function (e.g., min cost path, min load path, etc.) 480 o Metric Types and their threshold: 481 o TE cost, IGP cost, Hop count, or Unidirectional Delay (e.g., 482 can set all path delay <= threshold) 484 See the below actn-vn tree structure for the pointer for the 485 connectivity matrix identifier for each vn member in which the 486 configuration parameters listed above is provisioned using [te-topo] 487 model together with [te-tunnel] model in the network. 489 +--rw vn 490 +--rw vn-list* [vn-id] 491 +--rw vn-id uint32 492 +--rw vn-name? string 493 +--rw vn-topology-id? te-types:te-topology-id 494 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 495 +--rw vn-member-list* [vn-member-id] 496 | +--rw vn-member-id uint32 497 | +--rw src 498 | | +--rw src? -> /actn/ap/access-point-list/access-point-id 499 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 500 | | +--rw multi-src? boolean {multi-src-dest}? 501 | +--rw dest 502 | | +--rw dest? -> /actn/ap/access-point-list/access-point- 503 id 504 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 505 | | +--rw multi-dest? boolean {multi-src-dest}? 506 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- 507 node-attributes/connectivity-matrices/connectivity-matrix/id 508 | +--ro oper-status? identityref 509 +--ro if-selected? boolean {multi-src-dest}? 510 +--rw admin-status? identityref 511 +--ro oper-status? identityref 512 +--rw vn-level-diversity? vn-disjointness 514 Once these requests are instantiated, the resources are committed 515 and guaranteed through the life cycle of the VN. 517 [actn-pm-telemetry] provides models that allow for key performance 518 telemetry configuration mechanisms per VN level, VN member level as 519 well as path/link level. 521 The following tree structure from [actn-pm-telemetry] illustrates 522 how performance data (e.g., delay, delay-variation, utilization, 523 etc.) can be subscribed per VN need and monitored via YANG push 524 streaming mechanism. 526 module: ietf-actn-te-kpi-telemetry 527 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list: 528 +--ro vn-member-telemetry 529 +--ro unidirectional-delay? uint32 530 +--ro unidirectional-min-delay? uint32 531 +--ro unidirectional-max-delay? uint32 532 +--ro unidirectional-delay-variation? uint32 533 +--ro unidirectional-packet-loss? decimal64 534 +--ro unidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32 535 +--ro unidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32 536 +--ro unidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32 537 +--ro bidirectional-delay? uint32 538 +--ro bidirectional-min-delay? uint32 539 +--ro bidirectional-max-delay? uint32 540 +--ro bidirectional-delay-variation? uint32 541 +--ro bidirectional-packet-loss? decimal64 542 +--ro bidirectional-residual-bandwidth? rt-types:bandwidth-ieee-float32 543 +--ro bidirectional-available-bandwidth? rt-types:bandwidth-ieee-float32 544 +--ro bidirectional-utilized-bandwidth? rt-types:bandwidth-ieee-float32 545 +--ro utilized-percentage? uint8 546 +--ro vn-ref? -> /actn-vn:actn/vn/vn-list/vn- 547 id 548 +--ro vn-member-ref? -> /actn-vn:actn/vn/vn-list/vn- 549 member-list/vn-member-id 550 +--ro te-grouped-params* -> 551 /te:te/tunnels/tunnel/state/te-kpi:te-telemetry/id 552 ...... 554 3.3. Integration 556 ACTN provides mechanisms to correlate customer's VN and the actual 557 TE tunnels instantiated in the provider's network. Specifically, 559 o Link each VN member to actual TE tunnel 560 o Each VN can be monitored on a various level such as VN level, VN 561 member level, TE-tunnel level, and link/node level. 563 Service function integration with network topology (L3 and TE 564 topology) is in progress in [sf-topology]. Specifically, [sf- 565 topology] addresses a number of use-cases that how TE topology 566 supports various service functions. 568 3.4. Dynamic Configuration 570 ACTN provides an architecture that allows the customer network 571 controller (CNC) interacts with the MDSC which is network provider's 572 SDN controller in such a way that customer is given the control of 573 their VNs. 575 Specifically, the ACTN VN model [actn-vn] allows the following 576 capabilities: 578 o Dynamic control over VN the customer creates. 579 o Create, Modify, Delete 581 See the following tree structure from [actn-vn] as an example for 582 the dynamic configuration capability (write) VN creation, modify and 583 delete. VN can be dynamically created/modified/deleted with 584 constraints such as metric types (e.g., delay), bandwidth, 585 protection, etc. 587 +--rw vn 588 +--rw vn-list* [vn-id] 589 +--rw vn-id uint32 590 +--rw vn-name? string 591 +--rw vn-topology-id? te-types:te-topology-id 592 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node- 593 id 594 +--rw vn-member-list* [vn-member-id] 595 | +--rw vn-member-id uint32 596 | +--rw src 597 | | +--rw src? -> /actn/ap/access-point-list/access- 598 point-id 599 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn- 600 ap-id 601 | | +--rw multi-src? boolean {multi-src-dest}? 602 | +--rw dest 603 | | +--rw dest? -> /actn/ap/access-point-list/access- 604 point-id 605 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn- 606 ap-id 607 | | +--rw multi-dest? boolean {multi-src-dest}? 608 | +--rw connetivity-matrix-id? -> 609 /nw:networks/network/node/tet:te/te-node-attributes/connectivity- 610 matrices/connectivity-matrix/id 611 | +--ro oper-status? identityref 612 +--ro if-selected? boolean {multi-src-dest}? 613 +--rw admin-status? identityref 614 +--ro oper-status? identityref 615 +--rw vn-level-diversity? vn-disjointness 617 3.5. Customized Control Plane 619 ACTN provides a YANG model that allows the customer network 620 controller (CNC) to control VN via type 2 operation. Type 2 VN 621 allows the customer to provision pertinent LSPs that connect their 622 endpoints over the customized VN topology dynamically. 624 See the following tree structure from [actn-vn] as an example for 625 the provisioning of LSPs over the VN topology: 627 +--rw vn 628 +--rw vn-list* [vn-id] 629 +--rw vn-id uint32 630 +--rw vn-name? string 631 +--rw vn-topology-id? te-types:te-topology-id 632 | {type-2}? 633 +--rw vn-member-list* [vn-member-id] 634 | +--rw vn-member-id uint32 635 ......... 637 | +--rw path {type-2}? 638 | | +--rw path-element* [path-element-id] 639 | | +--rw path-element-id uint32 640 | | +--rw index? uint32 641 | | +--rw address? te-types:te-tp-id 642 | | +--rw hop-type? te-types:te-hop-type 644 3.6. The Gaps 646 ACTN allows the customers/users to subscribe and monitor VN/Tunnel 647 level performance data such as latency. The low level latency and 648 isolation characteristics that are sought by some VPN+ users such as 649 steering packets through specific queues resources are not in the 650 scope of ACTN. 652 This implies that the device-level performance data such as queuing 653 delay caused by various queuing mechanisms needs to be characterized 654 and monitored by a device level YANG PM model. Then the Domain SDN 655 controller (PNC) will need to estimate Domain LSP level PM data from 656 device-level PM data. Finally, the MDSC will need to derive 657 VN/Tunnel level PM data and present to the customers. 659 Another gap that needs to be filled up is how to coordinate non-TE 660 element from the routing and signaling standpoints. Currently, ACTN 661 is limited to TE elements. From an end-to-end network standpoint, 662 the scope of VPN+ may encompass non-TE elements in some 663 segments/domains as well as TE elements. How to seamlessly provide 664 end-to-end tunnel management and the operations of abstraction of 665 resources across non-TE and TE elements of the network will need to 666 be worked out further. 668 4. Security Considerations 670 Virtual network instantiation involves the control of network 671 resources in order to meet the service requirements of consumers. 672 In some deployment models, the consumer is able to directly request 673 modification in the behaviour of resources owned and operated by a 674 service provider. Such changes could significantly affect the 675 service provider's ability to provide services to other consumers. 676 Furthermore, the resources allocated for or consumed by a consumer 677 will normally be billable by the service provider. 679 Therefore, it is crucial that the mechanisms used in any virtual 680 network system allow for authentication of requests, security of 681 those requests, and tracking of resource allocations. 683 It should also be noted that while the partitioning of resources is 684 virtual, the consumers expect and require that there is no risk of 685 leakage of data from one slice to another, no transfer of knowledge 686 of the structure or even existence of other virtual networks, and 687 that changes to one virtual network (under the control of one 688 consumer) should not have detrimental effects on the operation of 689 other virtual networks (whether under control of different or the 690 same consumers) beyond the limits allowed within the SLA. Thus, 691 virtual networks are assumed to be private and to provide the 692 appearance of genuine physical connectivity. 694 ACTN operates using the [netconf] or [restconf] protocols and 695 assumes the security characteristics of those protocols. Deployment 696 models for ACTN should fully explore the authentication and other 697 security aspects before networks start to carry live traffic. 699 5. IANA Considerations 701 This document has no actions for IANA. 703 6. Acknowledgements 705 Thanks to James Guichard, Stewart Bryant, Dong Jie for their insight 706 and useful discussions about VPN+. 708 7. References 710 7.1. Informative References 712 [actn-framework] Ceccarelli, D. and Y. Lee, "Framework for 713 Abstraction and Control of Traffic Engineered Networks", 714 draft-ietf-teas-actn-framework, work in progress, February 715 2017. 717 [te-service-mapping] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic 718 Engineering and Service Mapping Yang Model", draft-lee- 719 teas-te-service-mapping-yang, work in progress. 721 [actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN 722 Operation", draft-lee-teas-actn-vn-yang, work in progress. 724 [actn-info] Y. Lee, S. Belotti (Editors), "Information Model for 725 Abstraction and Control of TE Networks (ACTN)", draft- 726 ietf-teas-actn-info-model, work in progress. 728 [actn-pm-elemetry] Y. Lee, et al, "YANG models for ACTN TE 729 Performance Monitoring Telemetry and Network 730 Autonomics",draft-lee-teas-actn-pm-telemetry-autonomics, 731 work in progress. 733 [vpn+] S. Bryant, and D. Jie, "Enhanced Virtual Private Networks 734 (VPN+)", draft-bryant-rtgwg-enhanced-vpn, work in 735 progress. 737 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 738 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 739 te, work in progress. 741 [L3SM] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model for 742 L3VPN service delivery", draft-ietf-l3sm-l3vpn-service- 743 model, work in progress. 745 [L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service 746 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 747 progress. 749 [L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity 750 Service Model (L1CSM)", draft-fioccola-ccamp-l1csm-yang, 751 work in progress. 753 8. Contributors 755 Authors' Addresses 757 Daniel King 758 Lancaster University 759 Email: d.king@lancaster.ac.uk 761 Young Lee 762 Huawei 763 Phone: (469)277-5838 764 Email: leeyoung@huawei.com 766 Jeff Tansura 767 Futurewei 768 Email: jefftant.ietf@gmail.com 770 Qin Wu 771 Huawei Technologies Co.,Ltd. 772 Email: bill.wu@huawei.com 774 Daniele Ceccarelli 775 Ericsson 776 Email: daniele.ceccarelli@ericsson.com