idnits 2.17.00 (12 Aug 2021) /tmp/idnits41145/draft-lee-rtgwg-actn-applicability-enhanced-vpn-00.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 7 instances of too long lines in the document, the longest one being 3 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 459 has weird spacing: '...mber-id uin...' == Line 490 has weird spacing: '...ic-type ide...' == Line 570 has weird spacing: '...mber-id uin...' == Line 575 has weird spacing: '...ic-type ide...' == Line 602 has weird spacing: '...mber-id uin...' == (1 more instance...) -- The document date (November 12, 2017) is 1651 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'L3sm' is mentioned on line 374, but not defined == Missing Reference: 'TE-tunnel' is mentioned on line 376, but not defined == Unused Reference: 'TE-Tunnel' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'L3SM' is defined on line 709, 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 (~~), 13 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: May 12, 2018 Jeff Tansura 8 Futurewei 10 Qin Wu 11 Huawei 13 November 12, 2017 15 Applicability of Abstraction and Control of Traffic Engineered 16 Networks (ACTN) to Enhanced VPN 18 draft-lee-rtgwg-actn-applicability-enhanced-vpn-00 20 Abstract 22 The Abstraction and Control of Traffic Engineered Networks (ACTN) 23 defines an SDN-based architecture that relies on the concepts of 24 network and service abstraction to detach network and service 25 control from the underlying data plane. 27 This document outlines the overview of ACTN capability and the 28 applicability of ACTN to Enhanced VPN. In particular, this document 29 also discusses how ACTN features can fulfill some of the 30 requirements of the enhanced VPN, which is also known as VPN+ 31 [VPN+]. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with 36 the provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other documents 45 at any time. It is inappropriate to use Internet-Drafts as 46 reference material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on May 12, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction...................................................3 73 2. ACTN Overview..................................................3 74 2.1. ACTN Virtual Network......................................4 75 2.2. Examples of ACTN Delivering Types of Virtual Networks.....5 76 2.2.1. ACTN Used for Virtual Private Line Model.............6 77 2.2.2. ACTN Used for VPN Delivery Model.....................7 78 2.2.3. ACTN Used to Deliver a Virtual Customer Network......8 79 2.3. Service Mapping from TE to ACTN VN Models.................9 80 2.4. ACTN VN KPI telemetry Models..............................9 81 3. Enhanced VPN and ACTN.........................................10 82 3.1. Isolation between VPNs...................................10 83 3.2. Guaranteed Performance...................................11 84 3.3. Integration..............................................12 85 3.4. Dynamic Configuration....................................13 86 3.5. Customized Control Plane.................................14 87 3.6. The Gaps.................................................14 88 4. Security Considerations.......................................15 89 5. IANA Considerations...........................................15 90 6. Acknowledgements..............................................16 91 7. References....................................................16 92 7.1. Informative References...................................16 93 8. Contributors..................................................17 94 Authors' Addresses...............................................17 96 1. Introduction 98 The Abstraction and Control of Traffic Engineered Networks (ACTN) 99 defines an SDN-based architecture that relies on the concepts of 100 network and service abstraction to detach network and service 101 control from the underlying data plane. 103 This document outlines the overview of ACTN capability and the 104 applicability of ACTN to Enhanced VPN. In particular, this document 105 also discusses how ACTN features can fulfill some of the key 106 requirements of the enhanced VPN, which is also known as VPN+ 107 [VPN+]. 109 2. ACTN Overview 111 The framework for ACTN [actn-framework] includes a reference 112 architecture that has been adapted for Figure 1 in this document, it 113 describes the functional entities and methods for the coordination 114 of resources across multiple domains, to provide end-to-end 115 services, components include: 117 o Customer Network Controller (CNC); 119 o Multi-domain Service Coordinator (MDSC); 121 o Provisional Network Controller (PNC). 123 --------- --------- --------- 124 | CNC-A | | CNC-B | | CNC-C | 125 --------- --------- --------- 126 \ | / 127 \__________ |-CMI I/F __________/ 128 \ | / 129 ------------------------- 130 | MDSC | 131 ------------------------- 132 / / | \ 133 / / |-MPI I/F \ 134 / / | \ 135 ------- ------- ------- ------- 136 | PNC | | PNC | | PNC | | PNC | 137 ------- ------- ------- ------- 139 CMI - (CNC-MDSC Interface) 140 MPI - (MDSC-PNC Interface) 142 Figure 1: ACTN Hierarchy 143 ACTN facilitates end-to-end connections and provides them to the 144 user. The ACTN framework highlights how: 146 o Abstraction of the underlying network resources are provided to 147 higher-layer applications and customers; 149 o Virtualization of underlying resources, whose selection 150 criterion is the allocation of those resources for the 151 customer, application, or service; 153 o Creation of a virtualized environment allowing operators to 154 view and control multi-domain networks as a single virtualized 155 network; 157 o The presentation to customers of networks as a virtual network 158 via open and programmable interfaces. 160 The ACTN managed infrastructure are traffic engineered network 161 resources, which may include: 163 o Statistical packet bandwidth; 165 o Physical forwarding plane sources, such as: wavelengths and 166 time slots; 168 o Forwarding and cross connect capabilities. 170 The ACTN type of network virtualization provides customers and 171 applications (tenants) to utilize and independently control 172 allocated virtual network resources as if resources as if they were 173 physically their own resource. 175 2.1. ACTN Virtual Network 177 To support multiple clients each with its own view of and control of 178 the server network, a network operator needs to partition the 179 network resources. The resulting partition can be assigned to each 180 client for guaranteed usage which is a step further than shared use 181 of common network resources. See [actn-vn] for detailed ACTN VN and 182 VNS. 184 An ACTN Virtual Network (VN) is a client view of the ACTN managed 185 infrastructure, and is presented by the ACTN provider as a set of 186 abstracted resources. 188 Depending on the agreement between client and provider various VN 189 operations and VN views are possible. 191 o Virtual Network Creation: A VN could be pre-configured and 192 created via static or dynamic request and negotiation between 193 customer and provider. It must meet the specified SLA 194 attributes which satisfy the customer's objectives. 196 o Virtual Network Operations: The virtual network may be further 197 modified and deleted based on customer request to request 198 changes in the network resources reserved for the customer, and 199 used to construct the network slice. The customer can further 200 act upon the virtual network to manage traffic flow across the 201 virtual network. 203 o Virtual Network View: The VN topology from a customer point of 204 view. These may be a variety of tunnels, or an entire VN 205 topology. Such connections may comprise of customer end points, 206 access links, intra domain paths and inter-domain links. 208 Dynamic VN Operations allow a customer to modify or delete the VN. 209 The customer can further act upon the virtual network to 210 create/modify/delete virtual links and nodes. These changes will 211 result in subsequent tunnel management in the operator's networks. 213 Primitives (capabilities and messages) have been provided to support 214 the different ACTN network control functions that will enable 215 virtual network. These include: topology request/query, VN service 216 request, path computation and connection control, VN service policy 217 negotiation, enforcement, routing options. [actn-info] 219 2.2. Examples of ACTN Delivering Types of Virtual Networks 221 In examples below the ACTN framework is used to provide control, 222 management and orchestration for the virtual network life-cycle, and 223 the connectivity . These dynamic and highly flexible, end-to-end and 224 dedicated virtual network utilizing common physical infrastructure, 225 and according to vertical-specific requirements. 227 The rest of this section provides three examples of using ACTN to 228 achieve different scenarios of ACTN for virtual network. All three 229 scenarios can be scaled up in capacity or be subject to topology 230 changes as well as changes from customer requirements perspective. 232 2.2.1. ACTN Used for Virtual Private Line Model 234 ACTN provides virtual connections between multiple customer 235 locations, requested via Virtual Private Line (VPL) requester (CNC- 236 A). Benefits of this model include: 238 o Automated: the service set-up and operation is network provider 239 managed; 241 o Virtual: the private line is seamlessly extended from customers 242 Site A (vCE1 to vCE3) and Site B (vCE2 to vCE3) across the 243 ACTN-managed WAN to Site C; 245 o Agile: on-demand where the customer needs connectivity and 246 fully adjustable bandwidth. 248 (Customer VPL Request) 249 | 250 --------- 251 | CNC-A | 252 Boundary --------- 253 Between ====================|==================== 254 Customer & | 255 Network Provider -------- 256 | MDSC | 257 -------- 258 __|__ 259 Site A ( PNC ) Site B 260 ------ ( ) ------ 261 |vCE1|=============( Phys. )=============|vCE2| 262 ------ ( Net ) ------ 263 \ ----- / 264 \ || / 265 \ || / 266 VPL 1 \__ || __/ VPL 2 267 \ || / 268 \ || / 269 \ ------ / 270 ------|vCE3|----- 271 ------ 272 Site C 274 Figure 2: Virtual Private Line Model 276 2.2.2. ACTN Used for VPN Delivery Model 278 ACTN provides VPN connections between multiple sites, requested Via 279 a VPN requestor (CNC-A), which is managed by the customer 280 themselves. The CNC will then interact with the network provider's 281 MDSC. Benefits of this model include: 283 o Provides edge-to-edge VPN multi-access connection; 285 o Mostly network provider managed, with some flexibility 286 delegated to the customer managed CNC. 288 ---------------- ---------------- 289 | Site-A Users |___________ ____________| Site-B Users | 290 ---------------- | | ---------------- 291 ------- 292 |CNC-A| 293 Boundary ------- 294 Between ==========================|========================== 295 Customer & | 296 Network Provider | 297 | 298 --------------- 299 | MDSC | 300 --------------- 301 _________/ | \__________ 302 / | \ 303 / | \ 304 --------- --------- --------- 305 | PNC | | PNC | | PNC | 306 --------- --------- --------- 307 | | / 308 | | / 309 ----- ----- ----- 310 ( ) ( ) ( ) 311 ----( Phys. )------------( Phys. )-------( Phys. )---- 312 ( Net ) ( Net ) ( Net ) 313 ----- ----- ----- 315 Figure 3: VPN Model 317 2.2.3. ACTN Used to Deliver a Virtual Customer Network 319 In this example ACTN provides a virtual network resource to the 320 customer. This resource is customer managed. Empowering the tenant 321 to control allocated VN (recursively). Benefits of this model 322 include: 324 o The MDSC provides the topology as part of the customer view so 325 that the customer can control their network slice to fit their 326 needs; 328 o Resource isolation, each customer network slice is fixed and 329 will not be affected by changes to other customer network 330 slices; 332 o Applications can interact with their assigned network slice 333 directly, the customer may implement their own network control 334 method and traffic prioritization, manage their own addressing 335 scheme, and further slice their assigned network resource; 337 o The network slice may also include specific capability nodes, 338 delivered as Physical Network Functions (PNFs) or Virtual 339 Network Functions (VNFs). 341 ___________ 342 --------------- ( Virtual ) 343 | CNC |---------->( Network 2 ) 344 --------------- _(_________ ) 345 --------------- ( Virtual )_) 346 | CNC |----------->( Network 2 ) ^ 347 --------------- ( ) : 348 ^ (___________) : 349 | ^ ^ : 350 Boundary | : : : 351 Between ==========|========================:====:====:======== 352 Customer & | : : : 353 Network Provider | : : : 354 v : : : 355 --------------- : :....: 356 | MDSC | : : 357 --------------- : : 358 ^ ---^------ ... 359 | ( ) . 360 v ( Physical ) . 361 ---------------- ( Network ) . 363 | PNC |<------> ( ) ---^------ 364 ---------------- | -------- ( ) 365 | |-- ( Physical ) 366 | PNC |<------------------------->( Network ) 367 --------------- ( ) 368 -------- 369 Figure 4: Virtual Customer Networks 371 2.3. Service Mapping from TE to ACTN VN Models 373 The role of TE-service mapping model [te-service-mapping] is to 374 create a binding relationship across a Layer-3 Service Model [L3sm], 375 Layer-2 Service Model [L2SM], Layer-1 Service Model [L1CSM], and TE 376 Tunnel model [TE-tunnel], via a generic ACTN Virtual Network (VN) 377 model [actn-vn]. 379 The ACTN VN YANG model [actn-vn] is a generic virtual network 380 service model that allows customers (internal or external) to create 381 a VN that meets the customer's service objective with various 382 constraints. 384 The TE-service mapping model is needed to bind L3VPN specific 385 service model with TE-specific parameters. This binding will 386 facilitate a seamless service operation with underlay-TE network 387 visibility. The TE-service model developed in this document can also 388 be extended to support other services including L2SM, and future 389 transport network service models. 391 ----------- --------------- ------------ 392 | L3SM | <------> | | <-----> | TE-Tunnel| 393 ----------- | | | Model | 394 | TE-Service | ------^----- 395 |Mapping Model| | 396 ----------- | | ------v----- 397 | L2SM | <------> | | <-----> | ACTN VN | 398 ----------- --------------- | Model | 399 ------------ 400 Figure 5: TE-Service Mapping ([te-service-mapping]) 402 2.4. ACTN VN KPI telemetry Models 404 The role of ACTN VN KPI telemetry model [actn-pm-telemetry] is to 405 provide YANG models so that customer can define key performance 406 monitoring data relevant for its VN via the YANG subscription 407 model. 409 Key characteristics of [actn-pm-telemetry] include: 411 o an ability to provide scalable VN-level telemetry aggregation 412 based on customer-subscription model for key performance 413 parameters defined by the customer; 415 o an ability to facilitate proactive re-optimization and 416 reconfiguration of VNs based on network 417 autonomic traffic engineering scaling configuration 418 mechanism. 420 3. Enhanced VPN and ACTN 422 This section discusses how the advanced features of ACTN discussed 423 in Section 2 can fulfill the enhanced VPN requirements defined in 424 [vpn+]. Key requirements of the enhanced VPN include: 426 1. Isolation between VPNs 427 2. Guaranteed Performance 428 3. Integration 429 4. Dynamic Configuration 430 5. Customized Control Plane 432 Simple creation, deletion and modification of the services. 433 Control over VPN Seamless integration of both physical and virtual 434 network and service functions 436 In the subsequent sections, we discuss how each requirement can be 437 fulfilled by the ACTN features and the gaps that remain to be solved 438 if applicable. 440 3.1. Isolation between VPNs 442 The ACTN VN YANG model [actn-vn] fulfills the isolation requirement 443 by providing the features. 445 o Each VN is identified with a unique identifier (vn-id and vn- 446 name) and so is each VN member that belongs to the VN (vn- 447 member-id). 449 o Each instantiated VN is managed and controlled independent of 450 other VNs in the network with proper protection level 451 (protection) 452 +--rw vn 453 +--rw vn-list* [vn-id] 454 +--rw vn-id uint32 455 +--rw vn-name? string 456 +--rw vn-topology-id? te-types:te-topology-id 457 | {type-2}? 458 +--rw vn-member-list* [vn-member-id] 459 | +--rw vn-member-id uint32 460 | +--rw src 461 . . . . 462 | +--rw dest 463 . . . . 464 | +--rw protection? Identityref 466 3.2. Guaranteed Performance 468 Performance objectives of a VN need first to be expressed in order 469 to assure the performance guarantee. [actn-vn] allows configuration 470 of several parameters that may affect the VN performance objectives. 471 Among the performance-related parameters per a VN level provided by 472 [actn-vn] are as follows: 474 o Bandwidth 475 o Objective function (e.g., min cost path, min load path, etc.) 476 o Metric Types and their threshold: 477 o TE cost, IGP cost, Hop count, or Unidirectional Delay (e.g., 478 can set all path delay <= threshold) 480 See the below actn-vn tree structure for configuration parameters 481 for the pertinent performance data. 483 +--rw vn 484 +--rw vn-list* [vn-id] 485 +--rw vn-id uint32 486 ............ 487 +--rw vn-name? string 488 +--rw objective-function? pcep:objective-function 489 +--rw metric* [metric-type] 490 | +--rw metric-type identityref 491 | +--rw limit 492 | | +--rw enabled? boolean 493 | | +--rw value? uint32 494 | +--rw optimize 495 | +--rw enabled? boolean 496 | +--rw value? uint32 497 +--rw bandwidth? te-types:te-bandwidth 499 Once these requests are instantiated, the resources are committed 500 and guaranteed through the life cycle of the VN. 502 [actn-pm-telemetry] provides models that allow for key performance 503 telemetry configuration mechanisms per VN level, VN member level as 504 well as path/link level. 506 The following tree structure from [actn-pm-telemetry] illustrates 507 how performance data (e.g., delay, delay-variation, utilization, 508 etc.) can be subscribed per VN need and monitored via YANG push 509 streaming mechanism. 511 module: ietf-actn-te-kpi-telemetry 512 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list: 513 +--rw vn-telemetry 514 | +--rw grouping-op 515 | | +--rw delay-op? identityref 516 | | +--rw delay-variation-op? identityref 517 | | +--rw utilized-bandwidth-op? identityref 518 | +--ro data 519 | +--ro one-way-delay? uint32 520 | +--ro two-way-delay? uint32 521 | +--ro one-way-delay-min? uint32 522 | +--ro one-way-delay-max? uint32 523 | +--ro two-way-delay-min? uint32 524 | +--ro two-way-delay-max? uint32 525 | +--ro one-way-delay-variation? uint32 526 | +--ro two-way-delay-variation? uint32 527 | +--ro utilized-bandwidth? te-types:te-bandwidth 528 ...... 530 3.3. Integration 532 ACTN provides mechanisms to correlate customer's VN and the actual 533 TE tunnels instantiated in the provider's network. Specifically, 535 o Link each VN member to actual TE tunnel 536 o Each VN can be monitored on a various level such as VN level, VN 537 member level, TE-tunnel level, and link/node level. 539 Service function integration with network topology (L3 and TE 540 topology) is in progress in [sf-topology]. Specifically, [sf- 541 topology] addresses a number of use-cases that how TE topology 542 supports various service functions. 544 3.4. Dynamic Configuration 546 ACTN provides an architecture that allows the customer network 547 controller (CNC) interacts with the MDSC which is network provider's 548 SDN controller in such a way that customer is given the control of 549 their VNs. 551 Specifically, the ACTN VN model [actn-vn] allows the following 552 capabilities: 554 o Dynamic control over VN the customer creates. 555 o Create, Modify, Delete 557 See the following tree structure from [actn-vn] as an example for 558 the dynamic configuration capability (write) VN creation, modify and 559 delete. VN can be dynamically created/modified/deleted with 560 constraints such as metric types (e.g., delay), bandwidth, 561 protection, etc. 563 +--rw vn 564 +--rw vn-list* [vn-id] 565 +--rw vn-id uint32 566 +--rw vn-name? string 567 +--rw vn-topology-id? te-types:te-topology-id 568 | {type-2}? 569 +--rw vn-member-list* [vn-member-id] 570 | +--rw vn-member-id uint32 571 ........ 573 +--rw objective-function? pcep:objective-function 574 +--rw metric* [metric-type] 575 | +--rw metric-type identityref 576 | +--rw limit 577 | | +--rw enabled? boolean 578 | | +--rw value? uint32 579 | +--rw optimize 580 | +--rw enabled? boolean 581 | +--rw value? uint32 582 +--rw bandwidth? te-types:te-bandwidth 583 +--rw protection? Identityref 585 3.5. Customized Control Plane 587 ACTN provides a YANG model that allows the customer network 588 controller (CNC) to control VN via type 2 operation. Type 2 VN 589 allows the customer to provision pertinent LSPs that connect their 590 endpoints over the customized VN topology dynamically. 592 See the following tree structure from [actn-vn] as an example for 593 the provisioning of LSPs over the VN topology: 595 +--rw vn 596 +--rw vn-list* [vn-id] 597 +--rw vn-id uint32 598 +--rw vn-name? string 599 +--rw vn-topology-id? te-types:te-topology-id 600 | {type-2}? 601 +--rw vn-member-list* [vn-member-id] 602 | +--rw vn-member-id uint32 603 ......... 605 | +--rw path {type-2}? 606 | | +--rw path-element* [path-element-id] 607 | | +--rw path-element-id uint32 608 | | +--rw index? uint32 609 | | +--rw address? te-types:te-tp-id 610 | | +--rw hop-type? te-types:te-hop-type 612 3.6. The Gaps 614 ACTN allows the customers/users to subscribe and monitor VN/Tunnel 615 level performance data such as latency. The low level latency and 616 isolation characteristics that are sought by some VPN+ users such as 617 steering packets through specific queues resources are not in the 618 scope of ACTN. 620 This implies that the device-level performance data such as queuing 621 delay caused by various queuing mechanisms needs to be characterized 622 and monitored by a device level YANG PM model. Then the Domain SDN 623 controller (PNC) will need to estimate Domain LSP level PM data from 624 device-level PM data. Finally, the MDSC will need to derive 625 VN/Tunnel level PM data and present to the customers. 627 Another gap that needs to be filled up is how to coordinate non-TE 628 element from the routing and signaling standpoints. Currently, ACTN 629 is limited to TE elements. From an end-to-end network standpoint, 630 the scope of VPN+ may encompass non-TE elements in some 631 segments/domains as well as TE elements. How to seamlessly provide 632 end-to-end tunnel management and the operations of abstraction of 633 resources across non-TE and TE elements of the network will need to 634 be worked out further. 636 4. Security Considerations 638 Virtual network instantiation involves the control of network 639 resources in order to meet the service requirements of consumers. 640 In some deployment models, the consumer is able to directly request 641 modification in the behaviour of resources owned and operated by a 642 service provider. Such changes could significantly affect the 643 service provider's ability to provide services to other consumers. 644 Furthermore, the resources allocated for or consumed by a consumer 645 will normally be billable by the service provider. 647 Therefore, it is crucial that the mechanisms used in any virtual 648 network system allow for authentication of requests, security of 649 those requests, and tracking of resource allocations. 651 It should also be noted that while the partitioning of resources is 652 virtual, the consumers expect and require that there is no risk of 653 leakage of data from one slice to another, no transfer of knowledge 654 of the structure or even existence of other virtual networks, and 655 that changes to one virtual network (under the control of one 656 consumer) should not have detrimental effects on the operation of 657 other virtual networks (whether under control of different or the 658 same consumers) beyond the limits allowed within the SLA. Thus, 659 virtual networks are assumed to be private and to provide the 660 appearance of genuine physical connectivity. 662 ACTN operates using the [netconf] or [restconf] protocols and 663 assumes the security characteristics of those protocols. Deployment 664 models for ACTN should fully explore the authentication and other 665 security aspects before networks start to carry live traffic. 667 5. IANA Considerations 669 This document has no actions for IANA. 671 6. Acknowledgements 673 Thanks to James Guichard, Stewart Bryant, Dong Jie for their insight 674 and useful discussions about VPN+. 676 7. References 678 7.1. Informative References 680 [actn-framework] Ceccarelli, D. and Y. Lee, "Framework for 681 Abstraction and Control of Traffic Engineered Networks", 682 draft-ietf-teas-actn-framework, work in progress, February 683 2017. 685 [te-service-mapping] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic 686 Engineering and Service Mapping Yang Model", draft-lee- 687 teas-te-service-mapping-yang, work in progress. 689 [actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN 690 Operation", draft-lee-teas-actn-vn-yang, work in progress. 692 [actn-info] Y. Lee, S. Belotti (Editors), "Information Model for 693 Abstraction and Control of TE Networks (ACTN)", draft- 694 ietf-teas-actn-info-model, work in progress. 696 [actn-pm-elemetry] Y. Lee, et al, "YANG models for ACTN TE 697 Performance Monitoring Telemetry and Network 698 Autonomics",draft-lee-teas-actn-pm-telemetry-autonomics, 699 work in progress. 701 [vpn+] S. Bryant, and D. Jie, "Enhanced Virtual Private Networks 702 (VPN+)", draft-bryant-rtgwg-enhanced-vpn, work in 703 progress. 705 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 706 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 707 te, work in progress. 709 [L3SM] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model for 710 L3VPN service delivery", draft-ietf-l3sm-l3vpn-service- 711 model, work in progress. 713 [L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service 714 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 715 progress. 717 [L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity 718 Service Model (L1CSM)", draft-fioccola-ccamp-l1csm-yang, 719 work in progress. 721 8. Contributors 723 Authors' Addresses 725 Daniel King 726 Lancaster University 727 Email: d.king@lancaster.ac.uk 729 Young Lee 730 Huawei 731 Phone: (469)277-5838 732 Email: leeyoung@huawei.com 734 Jeff Tansura 735 Futurewei 736 Email: jefftant.ietf@gmail.com 738 Qin Wu 739 Huawei Technologies Co.,Ltd. 740 Email: bill.wu@huawei.com