idnits 2.17.1 draft-king-teas-applicability-actn-slicing-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2018) is 2130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group D. King (Ed.) 2 Internet-Draft Old Dog Consulting 3 Intended status: Informational Y. Lee (Ed.) 4 Expires: December 26, 2018 Huawei 6 June 26, 2018 8 Applicability of Abstraction and Control 9 of Traffic Engineered Networks (ACTN) to Network Slicing 10 draft-king-teas-applicability-actn-slicing-03 12 Abstract 14 Network abstraction is a technique that can be applied to a network 15 domain to select network resources by policy to obtain a view of 16 potential connectivity 18 Network slicing is an approach to network operations that builds on 19 the concept of network abstraction to provide programmability, 20 flexibility, and modularity. It may use techniques such as Software 21 Defined Networking (SDN) and Network Function Virtualization (NFV) 22 to create multiple logical (virtual) networks, each tailored for a 23 set of services that are sharing the same set of requirements, on 24 top of a common network. 26 These logical networks are referred to as transport network slices. 27 A transport network slice does not necessarily represent dedicated 28 resources in the network, but does constitute a commitment by the 29 network provider to provide a specific level of service. 31 The Abstraction and Control of Traffic Engineered Networks (ACTN) 32 defines an SDN-based architecture that relies on the concepts of 33 network and service abstraction to detach network and service 34 control from the underlying data plane. 36 This document outlines the applicability of ACTN to transport 37 network slicing in an IETF technology network. It also identifies 38 the features of network slicing not currently within the scope of 39 ACTN, and indicates where ACTN might be extended. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on December 26 2018. 58 Copyright Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction....................................................3 76 1.1. Terminology................................................4 77 2. Requirements for Network Slicing................................4 78 2.1. Resource Slicing...........................................4 79 2.2. Network and Function Virtualization........................5 80 2.3. Resource Isolation.........................................5 81 2.4. Control and Orchestration..................................6 82 3. Abstraction and Control of Traffic Engineered (TE) 83 Networks (ACTN).................................................6 84 3.1. ACTN Virtual Network as a "Network Slice"..................8 85 3.2. Examples of ACTN Delivering Types of Network Slices........8 86 3.2.1. ACTN Used for Virtual Private Line Model...............9 87 3.2.2. ACTN Used for VPN Delivery Model.......................10 88 3.2.3. ACTN Used to Deliver a Virtual Customer Network........10 89 3.3. Network Slice Service Mapping from TE to ACTN VN Models....11 90 3.4. ACTN VN KPI Telemetry Models...............................12 91 4. IANA Considerations.............................................12 92 5. Security Considerations.........................................12 93 6. Acknowledgements................................................12 94 7. References......................................................13 95 8. Contributors....................................................15 96 Authors' Addresses.................................................15 98 1. Introduction 100 The principles of network resource separation are not new. For 101 years, separated overlay and logical (virtual) networking have 102 existed, allowing multiple connectivity services to be deployed over 103 a single physical network comprised of single or multiple layers. 104 However, several key differences exist that differentiate overlay and 105 virtual networking from network slicing. 107 A transport network slice construct provides an end-to-end logical 108 network, often with compute functions and utilising shared underlying 109 (physical or virtual) network resources. This logical network is 110 separated from other, often concurrent, logical networks each with 111 independent control and management, and each of which can be created 112 or modified on demand. 114 At one end of the spectrum, a virtual private wire or a virtual 115 private network (VPN) may be used to build a network slice. In these 116 cases, the network slices do not require the service provider to 117 isolate network resources for the provision of the service - the 118 service is "virtual". 120 At the other end of the spectrum there may be a detailed description 121 of a complex service that will meet the needs of a set of 122 applications with connectivity and service function requirements that 123 may include compute resource, storage capability, and access to 124 content. Such a service may be requested dynamically (that is, 125 instantiated when an application needs it, and released when the 126 application no longer needs it), and modified as the needs of the 127 application change. 129 Each example represents a self-contained network that must be 130 flexible enough to simultaneously accommodate diverse business-driven 131 use cases from multiple players on a common network infrastructure. 133 This document outlines the application of the ACTN architecture 134 [actn-framework] and enabling technologies to provide transport 135 network slicing in an IETF technology network. It describes how the 136 ACTN functional components can be used to support model-driven 137 partitioning of variable-sized bandwidth to facilitate network 138 sharing and virtualization. Furthermore, the use of model-based 139 interfaces to dynamically request the instantiation of virtual 140 networks could be extended to encompass requesting and instantiation 141 of specific service functions (which may be both physical and/or 142 virtual), and to partition network resources such as compute 143 resource, storage capability, and access to content. 145 In an IETF context, there are works in progress that have some 146 bearing with network slicing such as Enhanced VPN (VPN+) and DetNet. 147 Both works are an independent work in their own scope while 148 This document highlights how the ACTN approach might be extended to 149 address these other requirements of network slicing where TE is 150 required. 152 1.1. Terminology 154 Resource: Any features that can be delivered, including connectivity, 155 compute, storage, and content delivery. 157 Service Functions (SFs): Components that provide specific function 158 within a network. SFs are often combined in a specific sequence, 159 service function chain, to deliver services. 161 Infrastructure Resources: The hardware and necessary software for 162 hosting and connecting SFs. These resources may include computing 163 hardware, storage capacity, network resources (e.g. links and 164 switching/routing devices enabling network connectivity), and 165 physical assets for radio access. 167 Service Provider: A server network or collection of server 168 networks. 170 Consumer: Any application, client network, or customer of a network 171 provider. 173 Service Level Agreement (SLA): An agreement between a consumer and 174 network provider that describes the quality with which features 175 and functions are to be delivered. It may include measures of 176 bandwidth, latency, and jitter; the types of service (such as the 177 network service functions or billing) to be executed; the location, 178 nature, and quantities of services (such as the amount and location 179 of compute resources and the accelerators require). 181 Network Slice: An agreement between a consumer and a service 182 provider to deliver network resources according to a specific service 183 level agreement. A slice could span multiple technology (e.g., radio, 184 transport and cloud) and administrative domains. 186 IETF Technology: A TE network slice or transport network slice. 188 2. Requirements for Network Slicing 190 The concept of network slicing is considered a key capability for 191 future networks and, to serve customers with a wide variety of 192 different service needs, in term of latency, reliability, capacity, 193 and service function specific capabilities. 195 This section outlines the key capabilities required, and further 196 discussed in [ngmn-network-slicing], [network-slice-5g], 197 [3gpp.28.801] and [onf-tr526], to realise network slicing in an IETF 198 technology network. 200 2.1. Resource Slicing 202 For network slicing, it is important to consider both infrastructure 203 resources and servic functions. This allows a flexible approach to 204 deliver a range of services both by partitioning (slicing) the 205 available network resources to present them for use by a consumer, 206 but also by providing instances of SFs at the right locations and in 207 the correct chaining logic, with access to the necessary hardware, 208 including specific compute and storage resources. 210 Mapping of resources to slices may 1-to-1, or resources may be shared 211 among multiple slices. 213 2.2. Network and Function Virtualization 215 Virtualization is the abstraction of resources where the abstraction 216 is made available for use by an operations entity, for example, by 217 the Network Management Station (NMS) of a consumer network. The 218 resources to be virtualized can be physical or already virtualized, 219 supporting a recursive pattern with different abstraction layers. 220 Therefore, Virtualization is critical for network slicing as it 221 enables effective resource sharing between network slices. 223 Just as server virtualization makes virtual machines (VMs) 224 independent of the underlying physical hardware, network 225 Virtualization enables the creation of multiple isolated virtual 226 networks that are completely decoupled from the underlying physical 227 network, and can safely run on top of it. 229 2.3. Resource Isolation 231 Isolation of data and traffic is a major requirement that must be 232 satisfied for certain applications to operate in concurrent network 233 slices on a common shared underlying infrastructure. Therefore, 234 isolation must be understood in terms of: 236 o Performance: Each slice is defined to meet specific service 237 requirements, usually expressed in the form of Key Performance 238 Indicators (KPIs). Performance isolation requires that service 239 delivery on one network slice is not adversely impacted by 240 congestion and performance levels of other slices; 242 o Security: Attacks or faults occurring in one slice must not have an 243 impact on other slices, or customer flows are not only isolated on 244 network edge, but multiple customer traffic is not mixed across the 245 core of the network. Moreover, each slice must have independent 246 security functions that prevent unauthorised entities to have read 247 or write access to slice-specific configuration, management, 248 accounting information, and able to record any of these attempts, 249 whether authorised or not; 251 o Management: Each slice must be independently viewed, utilised and 252 managed as a separate network. 254 2.4. Control and Orchestration 256 Orchestration is the overriding control method for network slicing. 257 We may define orchestration as combining and coordinating multiple 258 control methods to provide an operational mechanism that can deliver 259 services and control underlying resources. In a network slicing 260 environment, an orchestrator is needed to coordinate disparate 261 processes and resources for creating, managing, and deploying the 262 end-to-end service. Two scenarios are outlined below where 263 orchestration would be required: 265 1. Multi-domain Orchestration: Managing connectivity setup of the 266 transport service, across multiple administrative domains; 268 2. End-to-end Orchestration: Combining resources for an "end-to-end 269 service (e.g., transport connectivity with firewalling and 270 guaranteed bandwidth and minimum delay for premium radio users 271 (spanning multiple domains). 273 In addition, 3GPP has also developed Release 14 "Study on 274 management and orchestration of network slicing for next generation 275 network" [3gpp.28.801], which defines an information model where the 276 network slice as well as physical and virtualized network functions 277 belong to the network operator domain, while the virtualized 278 resources belong to another domain operated by a Virtualization 279 infrastructure service provider. 281 3. Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) 283 The framework for ACTN [actn-framework] includes a reference 284 architecture that has been adapted for Figure 1 in this document, it 285 describes the functional entities and methods for the coordination of 286 resources across multiple domains, to provide end-to-end services, 287 components include: 289 o Customer Network Controller (CNC); 291 o Multi-domain Service Coordinator (MDSC); 293 o Provisioning Network Controller (PNC). 295 --------- --------- --------- 296 | CNC-A | | CNC-B | | CNC-C | 297 --------- --------- --------- 298 \ | / 299 \__________ |-CMI I/F __________/ 300 \ | / 301 ------------------------- 302 | MDSC | 303 ------------------------- 304 / / | \ 305 / / |-MPI I/F \ 306 / / | \ 307 ------- ------- ------- ------- 308 | PNC | | PNC | | PNC | | PNC | 309 ------- ------- ------- ------- 311 CMI - (CNC-MDSC Interface ) 312 MPI - (MDSC-PNC Interface) 314 Figure 1: ACTN Hierarchy 316 ACTN facilitates end-to-end connections and provides them to the 317 user. The ACTN framework highlights how: 319 o Abstraction of the underlying network resources are provided to 320 higher-layer applications and customers; 322 o Virtualization of underlying resources, whose selection criterion 323 is the allocation of those resources for the customer, application, 324 or service; 326 o Creation of a virtualized environment allowing operators to view 327 and control multi-domain networks as a single virtualized network; 329 o The presentation to customers of networks as a virtual network via 330 open and programmable interfaces. 332 The ACTN managed infrastructure are traffic engineered network 333 resources, which may include: 335 o Statistical packet bandwidth; 337 o Physical forwarding plane sources, such as: wavelengths and 338 time slots; 340 o Forwarding and cross connect capabilities. 342 The ACTN type of network virtualization provides customers and 343 applications (tenants) to utilise and independently control 344 allocated virtual network resources as if resources as if they 345 were physically their own resource. The ACTN network is "sliced", 346 with tenants being given a different partial and abstracted 347 topology view of the physical underlying network. The capabilities 348 that ACTN provides to enable slicing are outlined in Section 2 349 (Requirements for Network Slicing). 351 3.1. ACTN Virtual Network as a "Network Slice" 353 To support multiple clients each with its own view of and control 354 of the server network, a network operator needs to partition (or 355 "slice") the network resources. The resulting slices can be 356 assigned to each client for guaranteed usage which is a step 357 further than shared use of common network resources. See 358 [actn-vn] for detailed ACTN VN and VNS. 360 An ACTN Virtual Network (VN) is a client view that may be considered 361 a "network slice" of the ACTN managed infrastructure, and is 362 presented by the ACTN provider as a set of abstracted resources. 364 Depending on the agreement between client and provider various VN 365 operations and VN views are possible. 367 o Network Slice Creation: A VN could be pre-configured and created 368 via static or dynamic request and negotiation between customer and 369 provider. It must meet the specified SLA attributes which satisfy 370 the customer's objectives. 372 o Network Slice Operations: The network slice may be further modified 373 and deleted based on customer request to request changes in the 374 network resources reserved for the customer, and used to construct 375 the network slice. The customer can further act upon the network 376 slice to manage traffic flow across the network slice. 378 o Network Slice View: The VN topology from a customer point of view. 379 These may be a variety of tunnels, or an entire VN topology. Such 380 connections may comprise of customer end points, access links, 381 intra domain paths and inter-domain links. 383 Primitives (capabilities and messages) have been provided to support 384 the different ACTN network control functions that will enable network 385 slicing. These include: topology request/query, VN service request, 386 path computation and connection control, VN service policy 387 negotiation, enforcement, routing options. [actn-info] 389 3.2. Examples of ACTN Delivering Types of Network Slices 391 In examples below the ACTN framework is used to provide 392 control, management and orchestration for the network slice 393 life-cycle, the connectivity . These dynamic and highly flexible, 394 end-to-end and dedicated network slices utilising common physical 395 infrastructure, and according to vertical-specific requirements. 397 The rest of this section provides three examples of using ACTN to 398 achieve different scenarios of ACTN for network slicing. All three 399 scenarios can be scaled up in capacity or be subject to topology 400 changes as well as changes from customer requirements perspective. 402 3.2.1. ACTN Used for Virtual Private Line Model 404 ACTN Provides virtual connections between multiple customer 405 locations, requested via Virtual Private Line (VPL) requester 406 (CNC-A). Benefits of this model include: 408 o Automated: the service set-up and operation is network provider 409 managed; 411 o Virtual: the private line is seamlessly extended from customers 412 Site A (vCE1 to vCE2) and Site B (vCE2 to vCE3) across the 413 ACTN-managed WAN to Site C; 415 o Agile: on-demand where the customer needs connectivity and 416 fully adjustable bandwidth. 418 (Customer VPL Request) 419 | 420 --------- 421 | CNC-A | 422 Boundary --------- 423 Between ====================|==================== 424 Customer & | 425 Network Provider -------- 426 | MDSC | 427 -------- 428 __|__ 429 Site A ( PNC ) Site B 430 ------ ( ) ------ 431 |vCE1|=============( Phys. )=============|vCE2| 432 ------ ( Net ) ------ 433 \ ----- / 434 \ || / 435 \ || / 436 VPL 1 \__ || __/ VPL 2 437 \ || / 438 \ || / 439 \ ------ / 440 ------|vCE3|----- 441 ------ 442 Site C 444 Figure 2: Virtual Private Line Model 446 3.2.2. ACTN Used for VPN Delivery Model 448 ACTN Provides VPN connections between multiple sites, requested via 449 a VPN requestor (CNC-A), which is managed by the customer 450 themselves. The CNC will then interact with the network providers 451 MDSC. Benefits of this model include: 453 o Provides edge-to-edge VPN multi-access connection; 454 o Mostly network provider managed, with some flexibility delegated to 455 the customer managed CNC. 457 ---------------- ---------------- 458 | Site-A Users |___________ ____________| Site-B Users | 459 ---------------- | | ---------------- 460 ------- 461 |CNC-A| 462 Boundary ------- 463 Between ==========================|========================== 464 Customer & | 465 Network Provider | 466 | 467 --------------- 468 | MDSC | 469 --------------- 470 _________/ | \__________ 471 / | \ 472 / | \ 473 --------- --------- --------- 474 | PNC | | PNC | | PNC | 475 --------- --------- --------- 476 | | / 477 | | / 478 ----- ----- ----- 479 ( ) ( ) ( ) 480 ----( Phys. )------------( Phys. )-------( Phys. )---- 481 ( Net ) ( Net ) ( Net ) 482 ----- ----- ----- 484 Figure 3: VPN Model 486 3.2.3. ACTN Used to Deliver a Virtual Customer Network 488 In this example ACTN provides a virtual network resource to the 489 customer. This resource is customer managed. Empowering the tenant 490 to control allocated slice (recursively). Benefits of this model 491 include: 493 o The MDSC provides the topology as part of the customer view so 494 that the customer can control their network slice to fit their 495 needs; 497 o Resource isolation, each customer network slice is fixed and will 498 not be affected by changes to other customer network slices; 500 o Applications can interact with their assigned network slice 501 directly, the customer may implement their own network control 502 method and traffic prioritization, manage their own addressing 503 scheme, and further slice their assigned network resource; 505 o The network slice may also include specific capability nodes, 506 delivered as Physical Network Functions (PNFs) or Virtual Network 507 Functions (VNFs). 508 ___________ 509 --------------- ( Network ) 510 | CNC |---------->( Slice 2 ) 511 --------------- _(_________ ) 512 --------------- ( Network )_) 513 | CNC |----------->( Slice 1 ) ^ 514 --------------- ( ) : 515 ^ (___________) : 516 | ^ ^ : 517 Boundary | : : : 518 Between ==========|========================:====:====:======== 519 Customer & | : : : 520 Network Provider | : : : 521 v : : : 522 --------------- : :....: 523 | MDSC | : : 524 --------------- : : 525 ^ ---^------ ... 526 | ( ) . 527 v ( Physical ) . 528 ---------------- ( Network ) . 529 | PNC |<------> ( ) ---^------ 530 ---------------- | -------- ( ) 531 | |-- ( Physical ) 532 | PNC |<------------------------->( Network ) 533 --------------- ( ) 534 -------- 535 Figure 4: Network Slicing 537 3.3. Network Slice Service Mapping from TE to ACTN VN Models 539 The role of TE-service mapping model [te-service-mapping] is to 540 create a binding relationship across a Layer-3 Service Model [l3sm], 541 Layer-2 Service Model and TE Tunnel model, via a generic ACTN Virtual 542 Network (VN) model [actn-vn]. 544 The ACTN VN YANG model is a generic virtual network service 545 model that allows customers (internal or external) to create a VN 546 that meets the customer's service objective with various 547 constraints. 549 The TE-service mapping model is needed to bind L3VPN specific 550 service model with TE-specific parameters. This binding 551 will facilitate a seamless service operation with underlay-TE 552 network visibility. The TE-service model developed in this document 553 can also be extended to support other services including L2SM, and 554 L1CSM network service models. 556 ----------- --------------- ------------ 557 | L3SM | <------> | | <-----> | ACTN VN | 558 ----------- | | ------^----- 559 ----------- | TE-Service | | 560 | L2SM | <------> |Mapping Model| <-----> ------v----- 561 ----------- | | | TE-topo | 562 ----------- | | ------------ 563 | L2CSM | <------> | | <-----> ------------ 564 ----------- --------------- | TE-tunnel| 565 ------------ 567 Figure 5: TE-Service Mapping ([te-service-mapping]) 569 Editors note - We plan to provide a list of models available and 570 their relationships/dependencies. We will also provide a vertical 571 hierarchy of how these models may be used between functional 572 components in ACTN. 574 3.4. ACTN VN KPI telemetry Models 576 The role of ACTN VN KPI telemetry model [actn-pm-telemetry] is 577 to provide YANG models so that customer can define key 578 performance monitoring data relevant for its VN/network slicing 579 via the YANG subscription model. 581 Key characteristics of [actn-pm-telemetry] include: 583 o an ability to provide scalable VN-level telemetry aggregation 584 based on customer-subscription model for key performance 585 parameters defined by the customer; 587 o an ability to facilitate proactive re-optimization and 588 reconfiguration of VNs/Netork Slices based on network 589 autonomic traffic engineering scaling configuration 590 mechanism. 592 5. IANA Considerations 594 This document makes no requests for action by IANA. 596 6. Security Considerations 598 Network slicing involves the control of network resources in order 599 to meet the service requirements of consumers. In some deployment 600 models, the consumer is able to directly request modification in 601 the behaviour of resources owned and operated by a service provider. 602 Such changes could significantly affect the service provider's 603 ability to provide services to other consumers. Furthermore, the 604 resources allocated for or consumed by a consumer will normally be 605 billable by the service provider. 607 Therefore, it is crucial that the mechanisms used in any network 608 slicing system allow for authentication of requests, security of 609 those requests, and tracking of resource allocations. 611 It should also be noted that while the partitioning or slicing of 612 resources is virtual, the consumers expect and require that there 613 is no risk of leakage of data from one slice to another, no 614 transfer of knowledge of the structure or even existence of other 615 slices, and that changes to one slice (under the control of one 616 consumer) should not have detrimental effects on the operation of 617 other slices (whether under control of different or the same 618 consumers) beyond the limits allowed within the SLA. Thus, slices 619 are assumed to be private and to provide the appearance of genuine 620 physical connectivity. 622 ACTN operates using the [netconf] or [restconf] protocols and 623 assumes the security characteristics of those protocols. 624 Deployment models for ACTN should fully explore the authentication 625 and other security aspects before networks start to carry live 626 traffic. 628 7. Acknowledgements 630 Thanks to Qin Wu, Andy Jones, Ramon Casellas, and Gert Grammel for 631 their insight and useful discussions about network slicing. 633 8. References 635 8.1. Normative References 637 8.2. Informative References 639 [ngmn-network-slicing] 640 NGMN, "Description of Network Slicing Concept", 1 2016, 641 . 644 [3gpp.28.801] 645 3GPP, "Study on management and orchestration of network 646 slicing for next generation network", 3GPP TR 28.801 647 0.4.0, 1 2017, 648 . 650 [network-slice-5g] 651 "Network Slicing for 5G with SDN/NFV: Concepts, 652 Architectures and Challenges", Jose Ordonez-Lucena, 653 Pablo Ameigeiras, Diego Lopez, Juan J. Ramos-Munoz, 654 Javier Lorca, Jesus Folgueira, IEEE Communications 655 Magazine 55, March 2017 657 [onf-tr526] 658 ONF TR-526, "Applying SDN Architecture to 5G Slicing", 659 April 2016. 661 [actn-framework] 662 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 663 Control of Traffic Engineered Networks", draft-ietf-teas- 664 actn-framework, work in progress, February 2017. 666 [te-service-mapping] 667 Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 668 and Service Mapping Yang Model", 669 draft-lee-teas-te-service-mapping-yang, work in progress. 671 [actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN 672 Operation", draft-lee-teas-actn-vn-yang, work in progress. 674 [actn-info] Y. Lee, S. Belotti (Editors), "Information Model for 675 Abstraction and Control of TE Networks (ACTN)", draft-ietf- 676 teas-actn-info-model, work in progress. 678 [actn-pm-elemetry] Y. Lee, et al, "YANG models for ACTN TE 679 Performance Monitoring Telemetry and Network Autonomics", 680 draft-lee- teas-actn-pm-telemetry-autonomics, work in 681 progress. 683 [l3sm] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 684 Model for L3VPN Service Delivery", RFC 8049, February 2017 686 [netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 687 and A. Bierman, Ed., "Network Configuration Protocol 688 (NETCONF)", RFC 6241. 690 [restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 691 Protocol", draft-ietf-netconf-restconf, work in progress. 693 [sf-topology] I. Bryskin, et al, "Use Cases for SF Aware Topology 694 Models", draft-ietf-teas-use-cases-sf-aware-topo-model, work 695 in progress. 697 [vpn+] S. Bryant and J. Dong, "Enhanced Virtual Private Networks 698 (VPN+)", draft-bryant-rtgwg-enhanced-vpn, work in progress. 700 9. Contributors 702 The following people contributed text to this document. 704 Adrian Farrel 705 Email: afarrel@juniper.net 707 Mohamed Boucadair 708 Email: mohamed.boucadair@orange.com 710 Sergio Belotti 711 Email: sergio.belotti@nokia.com 713 Daniele Ceccarelli 714 Email: daniele.ceccarelli@ericsson.com 716 Haomian Zheng 717 Email: zhenghaomian@huawei.com 719 Authors' Addresses 721 Daniel King 722 Email: daniel@olddog.co.uk 724 Young Lee 725 Email: leeyoung@huawei.com