idnits 2.17.1 draft-king-teas-applicability-actn-slicing-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 : ---------------------------------------------------------------------------- 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 (July 3, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group D. King (Ed.) 3 Internet-Draft Old Dog Consulting 4 Intended status: Informational Y. Lee (Ed.) 5 Expires: January 3, 2018 Huawei 6 July 3, 2017 8 Applicability of Abstraction and Control 9 of Traffic Engineered Networks (ACTN) to Network Slicing 10 draft-king-teas-applicability-actn-slicing-01 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 January 3, 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.............................................13 92 5. Security Considerations.........................................13 93 6. Acknowledgements................................................13 94 7. Contributors....................................................13 95 8. References......................................................14 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 This document highlights how the ACTN approach might be extended to 146 address these other requirements of network slicing where TE is 147 required. 149 1.1 Terminology 151 Resource: Any features that can be delivered, including connectivity, 152 compute, storage, and content delivery. 154 Service Functions (SFs): Components that provide specific function 155 within a network. SFs are often combined in a specific sequence, 156 service function chain, to deliver services. 158 Infrastructure Resources: The hardware and necessary software for 159 hosting and connecting SFs. These resources may include computing 160 hardware, storage capacity, network resources (e.g. links and 161 switching/routing devices enabling network connectivity), and 162 physical assets for radio access. 164 Service Provider: A server network or collection of server 165 networks. 167 Consumer: Any application, client network, or customer of a network 168 provider. 170 Service Level Agreement (SLA): An agreement between a consumer and 171 network provider that describes the quality with which features 172 and functions are to be delivered. It may include measures of 173 bandwidth, latency, and jitter; the types of service (such as the 174 network service functions or billing) to be executed; the location, 175 nature, and quantities of services (such as the amount and location 176 of compute resources and the accelerators require). 178 Network Slice: An agreement between a consumer and a service 179 provider to deliver network resources according to a specific service 180 level agreement. A slice could span multiple technology (e.g., radio, 181 transport and cloud) and administrative domains. 183 IETF Technology: A TE network slice or transport network slice. 185 2. Requirements for Network Slicing 187 The concept of network slicing is considered a key capability for 188 future networks and, to serve customers with a wide variety of 189 different service needs, in term of latency, reliability, capacity, 190 and service function specific capabilities. 192 This section outlines the key capabilities required, and further 193 discussed in [ngmn-network-slicing], [network-slice-5g], 194 [3gpp.28.801] and [onf-tr526], to realise network slicing in an IETF 195 technology network. 197 2.1 Resource Slicing 198 For network slicing, it is important to consider both infrastructure 199 resources and servic functions. This allows a flexible approach to 200 deliver a range of services both by partitioning (slicing) the 201 available network resources to present them for use by a consumer, 202 but also by providing instances of SFs at the right locations and in 203 the correct chaining logic, with access to the necessary hardware, 204 including specific compute and storage resources. 206 Mapping of resources to slices may 1-to-1, or resources may be shared 207 among multiple slices. 209 2.2 Network and Function Virtualization 211 Virtualization is the abstraction of resources where the abstraction 212 is made available for use by an operations entity, for example, by 213 the Network Management Station (NMS) of a consumer network. The 214 resources to be virtualized can be physical or already virtualized, 215 supporting a recursive pattern with different abstraction layers. 216 Therefore, Virtualization is critical for network slicing as it 217 enables effective resource sharing between network slices. 219 Just as server virtualization makes virtual machines (VMs) 220 independent of the underlying physical hardware, network 221 Virtualization enables the creation of multiple isolated virtual 222 networks that are completely decoupled from the underlying physical 223 network, and can safely run on top of it. 225 2.3 Resource Isolation 227 Isolation of data and traffic is a major requirement that must be 228 satisfied for certain applications to operate in concurrent network 229 slices on a common shared underlying infrastructure. Therefore, 230 isolation must be understood in terms of: 232 o Performance: Each slice is defined to meet specific service 233 requirements, usually expressed in the form of Key Performance 234 Indicators (KPIs). Performance isolation requires that service 235 delivery on one network slice is not adversely impacted by 236 congestion and performance levels of other slices; 238 o Security: Attacks or faults occurring in one slice must not have an 239 impact on other slices, or customer flows are not only isolated on 240 network edge, but multiple customer traffic is not mixed across the 241 core of the network. Moreover, each slice must have independent 242 security functions that prevent unauthorised entities to have read 243 or write access to slice-specific configuration, management, 244 accounting information, and able to record any of these attempts, 245 whether authorised or not; 247 o Management: Each slice must be independently viewed, utilised and 248 managed as a separate network. 250 2.4 Control and Orchestration 252 Orchestration is the overriding control method for network slicing. 253 We may define orchestration as combining and coordinating multiple 254 control methods to provide an operational mechanism that can deliver 255 services and control underlying resources. In a network slicing 256 environment, an orchestrator is needed to coordinate disparate 257 processes and resources for creating, managing, and deploying the 258 end-to-end service. Two scenarios are outlined below where 259 orchestration would be required: 261 1. Multi-domain Orchestration: Managing connectivity setup of the 262 transport service, across multiple administrative domains; 264 2. End-to-end Orchestration: Combining resources for an "end-to-end 265 service (e.g., transport connectivity with firewalling and 266 guaranteed bandwidth and minimum delay for premium radio users 267 (spanning multiple domains). 269 In addition, 3GPP has also developed Release 14 "Study on 270 management and orchestration of network slicing for next generation 271 network" [3gpp.28.801], which defines an information model where the 272 network slice as well as physical and virtualized network functions 273 belong to the network operator domain, while the virtualized 274 resources belong to another domain operated by a Virtualization 275 infrastructure service provider. 277 3. Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) 279 The framework for ACTN [actn-framework] includes a reference 280 architecture that has been adapted for Figure 1 in this document, it 281 describes the functional entities and methods for the coordination of 282 resources across multiple domains, to provide end-to-end services, 283 components include: 285 o Customer Network Controller (CNC); 287 o Multi-domain Service Coordinator (MDSC); 289 o Physical Network Controller (PNC). 291 --------- --------- --------- 292 | CNC-A | | CNC-B | | CNC-C | 293 --------- --------- --------- 294 \ | / 295 \__________ |-CMI I/F __________/ 296 \ | / 297 ------------------------- 298 | MDSC | 299 ------------------------- 300 / / | \ 301 / / |-MPI I/F \ 302 / / | \ 303 ------- ------- ------- ------- 304 | PNC | | PNC | | PNC | | PNC | 305 ------- ------- ------- ------- 307 CMI - (CNC-MDSC Interface ) 308 MPI - (MDSC-PNC Interface) 310 Figure 1: ACTN Hierarchy 312 ACTN facilitates end-to-end connections and provides them to the 313 user. The ACTN framework highlights how: 315 o Abstraction of the underlying network resources are provided to 316 higher-layer applications and customers; 318 o Virtualization of underlying resources, whose selection criterion 319 is the allocation of those resources for the customer, application, 320 or service; 322 o Creation of a virtualized environment allowing operators to view 323 and control multi-domain networks as a single virtualized network; 325 o The presentation to customers of networks as a virtual network via 326 open and programmable interfaces. 328 The ACTN managed infrastructure are traffic engineered network 329 resources, which may include: 331 o Statistical packet bandwidth; 333 o Physical forwarding plane sources, such as: wavelengths and 334 time slots; 336 o Forwarding and cross connect capabilities. 338 The ACTN type of network virtualization provides customers and 339 applications (tenants) to utilise and independently control 340 allocated virtual network resources as if resources as if they 341 were physically their own resource. The ACTN network is "sliced", 342 with tenants being given a different partial and abstracted 343 topology view of the physical underlying network. The capabilities 344 that ACTN provides to enable slicing are outlined in Section 2 345 (Requirements for Network Slicing). 347 3.1 ACTN Virtual Network as a "Network Slice" 349 To support multiple clients each with its own view of and control 350 of the server network, a network operator needs to partition (or 351 "slice") the network resources. The resulting slices can be 352 assigned to each client for guaranteed usage which is a step 353 further than shared use of common network resources. See 354 [actn-vn] for detailed ACTN VN and VNS. 356 An ACTN Virtual Network (VN) is a client view that may be considered 357 a "network slice" of the ACTN managed infrastructure, and is 358 presented by the ACTN provider as a set of abstracted resources. 360 Depending on the agreement between client and provider various VN 361 operations and VN views are possible. 363 o Network Slice Creation: A VN could be pre-configured and created 364 via static or dynamic request and negotiation between customer and 365 provider. It must meet the specified SLA attributes which satisfy 366 the customer's objectives. 368 o Network Slice Operations: The network slice may be further modified 369 and deleted based on customer request to request changes in the 370 network resources reserved for the customer, and used to construct 371 the network slice. The customer can further act upon the network 372 slice to manage traffic flow across the network slice. 374 o Network Slice View: The VN topology from a customer point of view. 375 These may be a variety of tunnels, or an entire VN topology. Such 376 connections may comprise of customer end points, access links, 377 intra domain paths and inter-domain links. 379 Primitives (capabilities and messages) have been provided to support 380 the different ACTN network control functions that will enable network 381 slicing. These include: topology request/query, VN service request, 382 path computation and connection control, VN service policy 383 negotiation, enforcement, routing options. [actn-info] 385 3.2 Examples of ACTN Delivering Types of Network Slices 387 In examples below the ACTN framework is used to provide 388 control, management and orchestration for the network slice 389 life-cycle, the connectivity . These dynamic and highly flexible, 390 end-to-end and dedicated network slices utilising common physical 391 infrastructure, and according to vertical-specific requirements. 393 The rest of this section provides three examples of using ACTN to 394 achieve different scenarios of ACTN for network slicing. All three 395 scenarios can be scaled up in capacity or be subject to topology 396 changes as well as changes from customer requirements perspective. 398 3.2.1 ACTN Used for Virtual Private Line Model 400 ACTN Provides virtual connections between multiple customer 401 locations, requested via Virtual Private Line (VPL) requester 402 (CNC-A). Benefits of this model include: 404 o Automated: the service set-up and operation is network provider 405 managed; 407 o Virtual: the private line is seamlessly extended from customers 408 Site A (vCE1 to vCE2) and Site B (vCE2 to vCE3) across the 409 ACTN-managed WAN to Site C; 411 o Agile: on-demand where the customer needs connectivity and 412 fully adjustable bandwidth. 414 (Customer VPL Request) 415 | 416 --------- 417 | CNC-A | 418 Boundary --------- 419 Between ====================|==================== 420 Customer & | 421 Network Provider -------- 422 | MDSC | 423 -------- 424 __|__ 425 Site A ( PNC ) Site B 426 ------ ( ) ------ 427 |vCE1|=============( Phys. )=============|vCE2| 428 ------ ( Net ) ------ 429 \ ----- / 430 \ || / 431 \ || / 432 VPL 1 \__ || __/ VPL 2 433 \ || / 434 \ || / 435 \ ------ / 436 ------|vCE3|----- 437 ------ 438 Site C 440 Figure 2: Virtual Private Line Model 442 3.2.2 ACTN Used for VPN Delivery Model 444 ACTN Provides VPN connections between multiple sites, requested via 445 a VPN requestor (CNC-A), which is managed by the customer 446 themselves. The CNC will then interact with the network providers 447 MDSC. Benefits of this model include: 449 o Provides edge-to-edge VPN multi-access connection; 450 o Mostly network provider managed, with some flexibility delegated to 451 the customer managed CNC. 453 ---------------- ---------------- 454 | Site-A Users |___________ ____________| Site-B Users | 455 ---------------- | | ---------------- 456 ------- 457 |CNC-A| 458 Boundary ------- 459 Between ==========================|========================== 460 Customer & | 461 Network Provider | 462 | 463 --------------- 464 | MDSC | 465 --------------- 466 _________/ | \__________ 467 / | \ 468 / | \ 469 --------- --------- --------- 470 | PNC | | PNC | | PNC | 471 --------- --------- --------- 472 | | / 473 | | / 474 ----- ----- ----- 475 ( ) ( ) ( ) 476 ----( Phys. )------------( Phys. )-------( Phys. )---- 477 ( Net ) ( Net ) ( Net ) 478 ----- ----- ----- 480 Figure 3: VPN Model 482 3.2.3 ACTN Used to Deliver a Virtual Customer Network 484 In this example ACTN provides a virtual network resource to the 485 customer. This resource is customer managed. Empowering the tenant 486 to control allocated slice (recursively). Benefits of this model 487 include: 489 o The MDSC provides the topology as part of the customer view so 490 that the customer can control their network slice to fit their 491 needs; 493 o Resource isolation, each customer network slice is fixed and will 494 not be affected by changes to other customer network slices; 496 o Applications can interact with their assigned network slice 497 directly, the customer may implement their own network control 498 method and traffic prioritization, manage their own addressing 499 scheme, and further slice their assigned network resource; 501 o The network slice may also include specific capability nodes, 502 delivered as Physical Network Functions (PNFs) or Virtual Network 503 Functions (VNFs). 504 ___________ 505 --------------- ( Network ) 506 | CNC |---------->( Slice 2 ) 507 --------------- _(_________ ) 508 --------------- ( Network )_) 509 | CNC |----------->( Slice 1 ) ^ 510 --------------- ( ) : 511 ^ (___________) : 512 | ^ ^ : 513 Boundary | : : : 514 Between ==========|========================:====:====:======== 515 Customer & | : : : 516 Network Provider | : : : 517 v : : : 518 --------------- : :....: 519 | MDSC | : : 520 --------------- : : 521 ^ ---^------ ... 522 | ( ) . 523 v ( Physical ) . 524 ---------------- ( Network ) . 525 | PNC |<------> ( ) ---^------ 526 ---------------- | -------- ( ) 527 | |-- ( Physical ) 528 | PNC |<------------------------->( Network ) 529 --------------- ( ) 530 -------- 531 Figure 4: Network Slicing 533 3.3 Network Slice Service Mapping from TE to ACTN VN Models 534 The role of TE-service mapping model [te-service-mapping] is to 535 create a binding relationship across a Layer-3 Service Model [l3sm], 536 Layer-2 Service Model and TE Tunnel model, via a generic ACTN Virtual 537 Network (VN) model [actn-vn]. 539 The ACTN VN YANG model is a generic virtual network service 540 model that allows customers (internal or external) to create a VN 541 that meets the customer's service objective with various 542 constraints. 544 The TE-service mapping model is needed to bind L3VPN specific 545 service model with TE-specific parameters. This binding 546 will facilitate a seamless service operation with underlay-TE 547 network visibility. The TE-service model developed in this document 548 can also be extended to support other services including L2SM, and 549 future transport network service models. 551 ----------- --------------- ------------ 552 | L3SM | <------> | | <-----> | TE-Tunnel| 553 ----------- | | | Model | 554 | TE-Service | ------^----- 555 |Mapping Model| | 556 ----------- | | ------v----- 557 | L2SM | <------> | | <-----> | ACTN VN | 558 ----------- --------------- | Model | 559 ------------ 560 Figure 5: TE-Service Mapping ([te-service-mapping]) 562 Editors note - We plan to provide a list of models available and 563 their relationships/dependencies. We will also provide a vertical 564 hierarchy of how these models may be used between functional 565 components in ACTN. 567 3.4 ACTN VN KPI telemetry Models 569 The role of ACTN VN KPI telemetry model [actn-pm-telemetry] is 570 to provide YANG models so that customer can define key 571 performance monitoring data relevant for its VN/network slicing 572 via the YANG subscription model. 574 Key characteristics of [actn-pm-telemetry] include: 576 o an ability to provide scalable VN-level telemetry aggregation 577 based on customer-subscription model for key performance 578 parameters defined by the customer; 580 o an ability to facilitate proactive re-optimization and 581 reconfiguration of VNs/Netork Slices based on network 582 autonomic traffic engineering scaling configuration 583 mechanism. 585 4. IANA Considerations 587 This document makes no requests for action by IANA. 589 5. Security Considerations 591 Network slicing involves the control of network resources in order 592 to meet the service requirements of consumers. In some deployment 593 models, the consumer is able to directly request modification in 594 the behaviour of resources owned and operated by a service provider. 595 Such changes could significantly affect the service provider's 596 ability to provide services to other consumers. Furthermore, the 597 resources allocated for or consumed by a consumer will normally be 598 billable by the service provider. 600 Therefore, it is crucial that the mechanisms used in any network 601 slicing system allow for authentication of requests, security of 602 those requests, and tracking of resource allocations. 604 It should also be noted that while the partitioning or slicing of 605 resources is virtual, the consumers expect and require that there 606 is no risk of leakage of data from one slice to another, no 607 transfer of knowledge of the structure or even existence of other 608 slices, and that changes to one slice (under the control of one 609 consumer) should not have detrimental effects on the operation of 610 other slices (whether under control of different or the same 611 consumers) beyond the limits allowed within the SLA. Thus, slices 612 are assumed to be private and to provide the appearance of genuine 613 physical connectivity. 615 ACTN operates using the [netconf] or [restconf] protocols and 616 assumes the security characteristics of those protocols. 617 Deployment models for ACTN should fully explore the authentication 618 and other security aspects before networks start to carry live 619 traffic. 621 6. Acknowledgements 623 Thanks to Qin Wu, Andy Jones, Ramon Casellas, and Gert Grammel for 624 their insight and useful discussions about network slicing. 626 7. Contributors 628 The following people contributed text to this document. 630 Adrian Farrel 631 Email: afarrel@juniper.net 632 Mohamed Boucadair 633 Email: mohamed.boucadair@orange.com 635 Sergio Belotti 636 Email: sergio.belotti@nokia.com 638 Daniele Ceccarelli 639 Email: daniele.ceccarelli@ericsson.com 641 Haomian Zheng 642 Email: zhenghaomian@huawei.com 644 8. References 646 8.1. Normative References 648 8.2. Informative References 650 [ngmn-network-slicing] 651 NGMN, "Description of Network Slicing Concept", 1 2016, 652 . 655 [3gpp.28.801] 656 3GPP, "Study on management and orchestration of network 657 slicing for next generation network", 3GPP TR 28.801 658 0.4.0, 1 2017, 659 . 661 [network-slice-5g] 662 "Network Slicing for 5G with SDN/NFV: Concepts, 663 Architectures and Challenges", Jose Ordonez-Lucena, 664 Pablo Ameigeiras, Diego Lopez, Juan J. Ramos-Munoz, 665 Javier Lorca, Jesus Folgueira, IEEE Communications 666 Magazine 55, March 2017 668 [onf-tr526] 669 ONF TR-526, "Applying SDN Architecture to 5G Slicing", 670 April 2016. 672 [actn-framework] 673 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 674 Control of Traffic Engineered Networks", draft-ietf-teas- 675 actn-framework-05 (work in progress), February 2017. 677 [te-service-mapping] 678 Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 679 and Service Mapping Yang Model", 680 draft-lee-teas-te-service-mapping-yang-00 681 (work in progress), March 2017. 683 [actn-vn] Y. Lee (Editor), "A Yang Data Model for ACTN VN 684 Operation", draft-lee-teas-actn-vn-yang, work in progress. 686 [actn-info] Y. Lee, S. Belotti (Editors), "Information Model for 687 Abstraction and Control of TE Networks (ACTN)", draft-ietf- 688 teas-actn-info-model, work in progress. 690 [actn-pm-elemetry] Y. Lee, et al, "YANG models for ACTN TE 691 Performance Monitoring Telemetry and Network Autonomics", 692 draft-lee- teas-actn-pm-telemetry-autonomics, work in 693 progress. 695 [l3sm] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 696 Model for L3VPN Service Delivery", RFC 8049, 697 DOI 10.17487/RFC8049, February 2017, 698 . 700 [netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 701 and A. Bierman, Ed., "Network Configuration Protocol 702 (NETCONF)", RFC 6241. 704 [restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 705 Protocol", draft-ietf-netconf-restconf, work in progress. 707 Authors' Addresses 709 Daniel King 710 Email: daniel@olddog.co.uk 712 Young Lee 713 Email: ylee@huawei.com