idnits 2.17.1 draft-zhang-teas-actn-yang-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 27, 2016) is 2766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6020' is mentioned on line 109, but not defined == Missing Reference: 'TE-topology' is mentioned on line 399, but not defined == Missing Reference: 'TE-tunnel' is mentioned on line 410, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Xian Zhang 3 Internet Draft Huawei 4 Intended status: Informational 5 Daniele Ceccarrelli 6 Expires: February 2017 Ericsson 8 Bin Yeong Yoon 9 ETRI 11 Oscar Gonzalez de Dios 12 Telefonica 14 September 27, 2016 16 Applicability of YANG models for Abstraction and Control of Traffic 17 Engineered Networks 19 draft-zhang-teas-actn-yang-00 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 27, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 Abstraction and Control of TE Networks (ACTN) refers to the set of 62 virtual network operations needed to orchestrate, control and manage 63 large-scale multi-domain TE networks, so as to facilitate network 64 programmability, automation, efficient resource sharing, and end-to- 65 end virtual service aware connectivity and network function 66 virtualization services. 68 This document explains how the different types of YANG models 69 defined in the Operations and Management Area and in the Routing 70 Area are applicable to the ACTN framework. 72 Table of Contents 74 1. Introduction...................................................3 75 2. Abstraction and Control of TE Networks (ACTN) Architecture.....3 76 3. Service Models.................................................5 77 4. Service Model Mapping to ACTN..................................6 78 4.1. Customer Service Models in the ACTN Architecture (CMI)....8 79 4.2. Service Delivery Model in ACTN Architecture...............9 80 4.3. Network Configuration Model in ACTN Architecture (MPI)....9 81 4.4. Device Model in ACTN Architecture (SBI)..................10 82 4.5. Advanced Models..........................................10 83 5. Examples of Using Different Types of YANG Models..............11 84 5.1. Simple Connectivity Examples.............................11 85 5.2. VN service example.......................................11 86 5.3. Data Center-Interconnection Example......................12 87 5.3.1. CMI (CNC-MDSC Interface)............................14 88 5.3.2. MPI (MDSC-PNC Interface)............................14 89 5.3.3. PDI (PNC-Device interface)..........................14 90 6. Security......................................................15 91 7. Acknowledgements..............................................15 92 8. References....................................................15 93 8.1. Informative References...................................15 94 9. Contributors..................................................16 95 Authors' Addresses...............................................17 97 1. Introduction 99 Abstraction and Control of TE Networks (ACTN) describes a method for 100 operating a Traffic Engineered (TE) network (such as an MPLS-TE 101 network or a layer 1 transport network) to provide connectivity and 102 virtual network services for customers of the TE network. The 103 services provided can be tuned to meet the requirements (such as 104 traffic patterns, quality, and reliability) of the applications 105 hosted by the customers. More details about ACTN can be found in 106 Section 2. 108 Data models are a representation of objects that can be configured 109 or monitored within a system. Within the IETF, YANG [RFC6020] is the 110 language of choice for documenting data models, and YANG models have 111 been produced to allow configuration or modelling of a variety of 112 network devices, protocol instances, and network services. YANG data 113 models have been classified in [Netmod-Yang-Model-Classification] 114 and [Service-YANG]. 116 This document shows how the ACTN architecture can be satisfied using 117 classes of data model that have already been defined, and discusses 118 the applicability of specific data models that are under 119 development. It also highlights where new data models may need to be 120 developed. 122 2. Abstraction and Control of TE Networks (ACTN) Architecture 124 [ACTN-Requirements] describes the high-level ACTN requirements. 125 [ACTN-Frame] describes the architecture model for ACTN including the 126 entities (Customer Network Controller (CNC), Multi-domain Service 127 Coordinator (MDSC), and Physical Network Controller (PNC)) and their 128 interfaces. 130 Figure 1 depicts a high-level control and interface architecture for 131 ACTN and is a reproduction of Figure 7 from [ACTN-Frame]. A number 132 of key ACTN interfaces exist for deployment and operation of ACTN- 133 based networks. These are highlighted in Figure 1 (ACTN Interfaces) 134 below: 136 .-------------- 137 ------------- | 138 | Application |-- 139 ------------- 140 ^ 141 | I/F A -------- 142 v ( ) 143 -------------- - - 144 | Customer | ( Customer ) 145 | Network |--------->( Network ) 146 | Controller | ( ) 147 -------------- - - 148 ^ ( ) 149 | I/F B -------- 150 v 151 -------------- 152 | MultiDomain | 153 | Service | 154 | Coordinator| -------- 155 -------------- ( ) 156 ^ - - 157 | I/F C ( Physical ) 158 v ( Network ) 159 --------------- ( ) -------- 160 | |<----> - - ( ) 161 -------------- | ( ) - - 162 | Physical |-- -------- ( Physical ) 163 | Network |<---------------------->( Network ) 164 | Controller | I/F D ( ) 165 -------------- - - 166 ( ) 167 -------- 169 Figure 1 : ACTN Interfaces 171 The interfaces and functions are described below (without modifying 172 the definitions) in [ACTN-Frame]: 174 . Interface A: This is out of scope of this draft. 176 . Interface B: The CNC-MDSC Interface (CMI) is an interface 177 between a Customer Network Controller and a Multi Domain 178 Service Controller. The interface will communicate the service 179 request or application demand. A request will include specific 180 service properties, including: services, bandwidth and 181 constraint information. The CNC can also request the creation 182 of the virtual network resources and virtual topology based on 183 underlying physical resources to provide network services for 184 the applications. The CNC can provide the end-point 185 information/characteristics, traffic demand, a connectivity 186 matrix, and a virtual network. The MDSC may also report 187 potential network topology availability if queried for current 188 capability from the Customer Network Controller. 190 . Interface C: The MDSC-PNC Interface (MPI) is an interface 191 between a Multi Domain Service Coordinator and a Physical 192 Network Controller. It allows the MDSC to communicate requests 193 to create connectivity or to modify bandwidth reservations in 194 the physical network. In multi-domain environments, each PNC is 195 responsible for a separate domain and so the MDSC needs to 196 establish multiple MPIs, one for each PNC and perform 197 coordination between them. 199 . Interface D: The provisioning interface for creating forwarding 200 state in the physical network, requested via the Physical 201 Network Controller. 203 3. Service Models 205 [Service-YANG] introduces a reference architecture to explain the 206 nature and usage of service YANG models in the context of service 207 orchestration. Figure 2 below depicts this relationship and is a 208 reproduction of Figure 2 from [Service-YANG]. Four models depicted 209 in Figure 2 are defined as follows: 211 . Customer Service Model: A customer service model is used to 212 describe a service as offer or delivered to a customer by a 213 network operator. 214 . Service Delivery Model: A service delivery model is used by a 215 network operator to define and configure how a service is 216 provided by the network. 217 . Network Configuration Model: A network configuration model is 218 used by a network orchestrator to provide network-level 219 configuration model to a controller. 220 . Device Configuration Model: A device configuration model is 221 used by a controller to configure physical network elements. 223 Customer 224 ------------------ Service ---------- 225 | | Model | | 226 | Service |<-------->| Customer | 227 | Orchestrator | | | 228 | | ---------- 229 ------------------ 230 . . 231 . . ----------- 232 . . ......|Application| 233 . . : | BSS/OSS | 234 . . : ----------- 235 . Service Delivery . : 236 . Model . : 237 ------------------ ------------------ 238 | | | | 239 | Network | | Network | 240 | Orchestrator | | Orchestrator | 241 | | | | 242 .------------------ ------------------. 243 . : : . 244 . : Network Configuration : . 245 . : Model : . 246 ------------ ------------ ------------ ------------ 247 | | | | | | | | 248 | Controller | | Controller | | Controller | | Controller | 249 | | | | | | | | 250 ------------ ------------ ------------ ------------ 251 : . . : : 252 : . . Device : : 253 : . . Configuration : : 254 : . . Model : : 255 --------- --------- --------- --------- --------- 256 | Network | | Network | | Network | | Network | | Network | 257 | Element | | Element | | Element | | Element | | Element | 258 --------- --------- --------- --------- --------- 260 Figure 2: An SDN Architecture with a Service Orchestrator 261 4. Service Model Mapping to ACTN 263 YANG models coupled with the RESTCONF/NETCONF protocol 264 [Netconf][Restconf] is a solution for the ACTN framework. This 265 section explains which types of YANG models apply to each of the 266 ACTN interfaces. 268 +-------------------------------------------------------------+ 269 | | 270 | +-----------+ +-------+ | 271 | | Customer | | CNC | | 272 | +-----------+ +-------+ | 273 | /|\ /|\ | 274 +---------|-------------------------------------------|-------+ 275 | Customer Service Model | CMI 276 | | 277 +------ --|-------------------------------------------|--------+ 278 | \|/ | | 279 | +------------+ | | 280 | | Service | \|/ | 281 | |Orchestrator| +----------+ | 282 | +------------+ | | | 283 | /|\ | MDSC | | 284 | | Service Delivery Model | | | 285 | \|/ | | | 286 | +------------+ +----------+ | 287 | | Network | /|\ | 288 | |Orchestrator| | | 289 | +------------+ | | 290 | /|\ | | 291 | | | | 292 +---------|-------------------------------------------|--------+ 293 | | MPI 294 | Network Configuration Model | 295 +---------|-------------------------------------------|--------+ 296 | \|/ \|/ | 297 | +----------+ +-----------+ | 298 | | Domain | | PNC | | 299 | |Controller| +-----------+ | 300 | +----------+ /|\ /|\ | 301 | /|\ /|\ | | | 302 | | | | | | 303 +------|-----|-------------------------------------|-----|-----+ 304 | | Device Configuration Model | | SBI 305 \|/ \|/ \|/ \|/ 306 --- --- --- --- 307 / \ / \ / \ / \ 308 \ / \ / \ / \ / 309 --- --- --- --- 311 Figure 3 : Mapping between Service Model and ACTN Architecture 313 As shown in Figure 3, the architecture described in [Service-YANG] 314 can be mapped to the ACTN architecture well. A point worth noting is 315 that here the functions of the MDSC can include: 317 1. Customer mapping/translation 319 This function is to map customer intent-like commands into network 320 provisioning requests to the Physical Network Controller (PNC) 321 according to business OSS/NMS provisioned static or dynamic policy. 322 . Moreover, it provides mapping and translation of customer network 323 slices into physical network resources. 325 2. Service/Virtual service coordination 327 This function translates customer service-related information into 328 the virtual network operations in order to seamlessly operate 329 virtual networks while meeting customer's service requirements. 331 3. Multi domain coordination 333 This function oversees the specific aspects of the different domains 334 and to build a single abstracted end-to-end network topology in 335 order to coordinate end-to-end path computation and path/service 336 provisioning. Domain sequence path calculation/determination is also 337 a part of this function. 339 4. Virtualization/Abstraction 341 This function provides an abstracted view of the underlying network 342 resources towards customer, being it the client or a higher level 343 controller entity. It includes computation of customer resource 344 requests into network paths based on the global network-wide 345 abstracted topology and the creation of an abstracted view of 346 network slices allocated to each customer, according to customer- 347 specific network objective functions, and to the customer traffic 348 profile. 350 The first two of these functions (1 and 2) are related to service 351 orchestration while function 3 is related to network orchestration 352 and function 4 is related to both service and network orchestration. 354 4.1. Customer Service Models in the ACTN Architecture (CMI) 356 Customer Service Models, which are used between a customer and a 357 service orchestrator as in [Service-YANG], should be used between 358 the CNC and MDSC (e.g., CMI) serving as providing a simple intent- 359 like model/interface. 361 Among the key functions of Customer Service Models on the CMI is the 362 service request. A request will include specific service properties, 363 including: service type and its characteristics, bandwidth, 364 constraint information, and end-point characteristics. 366 Examples of service models applicable to ACTN are [Transport- 367 Service-Model] and [ACTN-VN-YANG]. 369 4.2. Service Delivery Model in ACTN Architecture 371 The Service Delivery Models (as shown in Figure 3) where the service 372 orchestration and the network orchestration could be implemented as 373 separate components as seen in [Service-YANG]. This is also known as 374 Network Service Models. On the other hand, from an ACTN architecture 375 point of view, the service delivery model between the service 376 orchestrator and the network orchestrator is an internal interface 377 between sub-components of the MDSC. 379 4.3. Network Configuration Model in ACTN Architecture (MPI) 381 The Network Configuration Models is used between the network 382 orchestrator (MSDC) and the controller (PNC) in [Service-YANG]. In 383 ACTN, this model is used either between hierarchical MDSCs (see 384 Section 4.5) or between a MDSC and a PNC. 386 The Network Configuration Model captures the parameters which are 387 network wide information. Examples of Network configuration models 388 are [TE-Tunnel] and [TE-Topology]. 390 The following table provides key functions of the MPI mapped with 391 Network Configuration Yang Models. Note that there are various Yang 392 models are work in progress. 394 Function Yang Models 395 ------------------------------------------ 396 Configuration Scheduling [Schedule] 397 Path computation TDB 398 Path Provisioning [TE-Tunnel]* 399 Topology Abstraction [TE-topology] 400 Telemetry TDB 402 *Note that path provisioning function is provided by ietf-te module 403 in [TE-Tunnel]. 405 4.4. Device Models in ACTN Architecture (SBI) 407 For the device YANG models are used for per-device configuration 408 purpose, they can be used between the PNC and the physical 409 network/devices. An example of Device Models is ietf-te-device yang 410 module defined in [TE-tunnel]. Note that SBI is not in the scope of 411 ACTN. This section is provided to give some examples of YANG-based 412 Device Models. 414 4.5. Advanced Models 416 There may be some variation of interface C whereby there may be 417 MDSC-MDSC interface (MMI) in case where there may be a recursive 418 hierarchy among the MDSCs. This is a variation of ACTN architecture. 419 See Figure 4 for this. 421 +-------+ +-------+ +-------+ 422 | CNC-A | | CNC-B | | CNC-C | 423 +-------+ +-------+ +-------+ 424 \ | / 425 ---------- | ---------- 426 \ | / 427 +-----------------------+ 428 | MDSC | 429 +-----------------------+ 430 / | \ 431 ---------- | ----------- 432 / | \ 433 +----------+ +----------+ +--------+ 434 | MDSC | | MDSC | | MDSC | 435 +----------+ +----------+ +--------+ 436 | / | / \ 437 | / | / \ 438 +-----+ +-----+ +-----+ +-----+ +-----+ 439 | PNC | | PNC | | PNC | | PNC | | PNC | 440 +-----+ +-----+ +-----+ +-----+ +-----+ 442 Figure 4: MDSC Controller Hierarchy 444 The MDSC-MDSC interface can be viewed as a recursive network 445 configuration model which is similar to the MDSC-PNC interface. 447 5. Examples of Using Different Types of YANG Models 449 5.1. Simple Connectivity Examples 451 The data model in [Transport-Service-Model] provides an intent-like 452 connectivity service model which can be used in connection-oriented 453 transport networks. 455 It would be used as follows in the ACTN architecture: 457 . A CNC uses this service model to specify the two client nodes 458 that are to be connected, and also indicates the amount of 459 traffic (i.e., the bandwidth required) and payload type. What 460 may additionally is the SLA that describes the required quality 461 and resilience of the service. 463 . The MDSC uses the information in the request to pick the right 464 network (domain) and also to select the provider edge nodes 465 corresponding to the customer edge nodes. 467 If there are multiple domains, then the MDSC needs to 468 coordinate across domains to set up network tunnels to deliver 469 a service. Thus coordination includes, but is not limited to, 470 picking the right domain sequence to deliver a service. Before 471 it can perform such functions, it needs to get the topology 472 information from each PNC, be it abstract or not, using 473 topology YANG models such as [te-topology]. 475 Additionally, a MDSC can initiate the creation of a tunnel (or 476 tunnel segment) in order to fulfill the service request from 477 CNC based on path computation upon the overall topology 478 information it synthesized from different PNCs. The based model 479 that can cater this purpose is the te-tunnel model specified in 480 [te-tunnel]. 482 . Then, the PNC needs to decide the explicit route of such a 483 tunnel or tunnel segment (in case of multiple domains), and 484 create such a tunnel using protocols such as PCEP and RSVP-TE 485 or using per-hop configuration. 487 5.2. VN service example 489 The service model defined in [ACTN-VN-YANG] describes a virtual 490 network (VN) as a service which is a set of multiple connectivity 491 services: 493 . A CNC will specify to the MDSC a list of VN members. Each VN 494 member specifies either a single connectivity service, or a 495 source with multiple potential destination points in the case 496 that the precise destination sites are to be determined by 497 MDSC. 499 o In the first case, the procedure is the same as the 500 connectivity service, except that in this case, there is a 501 list of connections requested. 503 o In the second case, where the CNC requests the MDSC to 504 select the right destination out of a list of candidates, 505 the MDSC needs to choose the best candidate and reply with 506 the chosen destination for a given VN member. After this 507 is selected, the connectivity request setup procedure is 508 the same as in the connectivity-as-a-service example. 510 5.3. Data Center-Interconnection Example 512 This section describes more concretely how existing YANG models 513 described in Section 4 map to an ACTN data center interconnection 514 use case. Figure 5 shows a use-case which shows service policy- 515 driven Data Center selection and is a reproduction of Figure A.1 516 from [ACTN-Info]. 518 +----------------+ 519 | CNC | 520 | (Global DC | 521 | Operation | 522 | Control) | 523 +--------+-------+ 524 | | VN Requirement/Policy: 525 CMI: | | - Endpoint/DC location info 526 Service model | | - Endpoint/DC dynamic 527 | | selection policy 528 | | (for VM migration, DR, LB) 529 | v 530 +---------+---------+ 531 | Multi-domain | Service policy-driven 532 |Service Coordinator| dynamic DC selection 533 MPI: +-----+---+---+-----+ 534 Network Configuration | | | 535 Model | | | 536 +----------------+ | +---------------+ 537 | | | 538 +-----+-----+ +------+-----+ +------+-----+ 539 | PNC for | | PNC for | | PNC for | 540 | Transport | | Transport | | Transport | 541 | Network A | | Network B | | network C | 542 +-----------+ +------------+ +------------+ 543 Device | | | 544 Model | | | 545 | | | 546 +---+ ------ ------ ------ +---+ 547 |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5| 548 +---+ | | | | | | +---+ 549 | TN A +-----+ TN B +----+ TN C | 550 / | | | | | 551 / \\\\ //// / \\\\ //// \\\\ //// 552 +---+ ------ / ------ \ ------ \ 553 |DC2| / \ \+---+ 554 +---+ / \ |DC6| 555 +---+ \ +---+ +---+ 556 |DC3| \|DC4| 557 +---+ +---+ 559 DR: Disaster Recovery 560 LB: Load Balancing 562 Figure 5: Service Policy-driven Data Center Selection 564 Figure 5 shows how VN policies from the CNC (Global Data Center 565 Operation) are incorporated by the MDSC to support multi-destination 566 applications. Multi-destination applications refer to applications 567 in which the selection of the destination of a network path for a 568 given source needs to be decided dynamically to support such 569 applications. 571 Data Center selection problems arise for VM mobility, disaster 572 recovery and load balancing cases. VN's policy plays an important 573 role for virtual network operation. Policy can be static or dynamic. 574 Dynamic policy for data center selection may be placed as a result 575 of utilization of data center resources supporting VMs. The MDSC 576 would then incorporate this information to meet the objective of 577 this application. 579 5.3.1. CMI (CNC-MDSC Interface) 581 The VN Service Model [ACTN-VN-YANG] is used to express the 582 definition of a VN, its VN creation request, the service objectives 583 (metrics, QoS parameters, etc.), dynamic service policy when VM 584 needs to be moved from one Data Center to another Data Center, etc. 585 This service model is used between the CNC and the MDSC (CMI). The 586 CNC in this use-case is an external entity that wants to create a VN 587 and operates on the VN. 589 5.3.2. MPI (MDSC-PNC Interface) 591 The Network Configuration Model is used between the MDSC and the 592 PNCs. Based on the Customer Service Model's request, the MDSC will 593 need to translate the service model into the network configuration 594 model to instantiate a set of multi-domain connections between the 595 prescribed sources and the destinations. The MDSC will also need to 596 dynamically interact with the CNC for dynamic policy changes 597 initiated by the CNC. Upon the determination of the multi-domain 598 connections, the MDSC will need to use the network configuration 599 model such as [TE-Tunnel] to interact with each PNC involved on the 600 path. [TE-Topology] is used to for the purpose of underlying domain 601 network abstraction from the PNC to the MDSC. 603 5.3.3. PDI (PNC-Device interface) 605 The Device Model can be used between the PNC and its underlying 606 devices that are controlled by the PNC. The PNC will need to trigger 607 signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to 608 provision its domain path segment. There can be a plethora of 609 choices how to control/manage its domain network. The PNC is 610 responsible to abstract its domain network resources and update it 611 to the MDSC. Note that this interface is not in the scope of ACTN. 612 This section is provided just for an illustration purpose. 614 6. Security 616 This document is an informational draft. When the models mentioned 617 in this draft are implemented, detailed security consideration will 618 be given in such work. 620 How security fits into the whole architecture has the following 621 components: 623 - the use of Restconf security between components 625 - the use of authentication and policy to govern which services can 626 be requested by different parties. 628 - how security may be requested as an element of a service and 629 mapped down to protocol security mechanisms as well as separation 630 (slicing) of physical resources) 632 7. Acknowledgements 634 We thank Adrian Farrel for providing useful comments and suggestions 635 for this draft. 637 8. References 639 8.1. Informative References 641 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 642 Explained", draft-wu-opsawg-service-model-explained, work 643 in progress. 645 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. 646 Moberg, "YANG Module Classification", draft-ietf-netmod- 647 yang-model-classification, work in progress. 649 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 651 and A. Bierman, Ed., "Network Configuration Protocol 653 (NETCONF)", RFC 6241. 655 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 656 Protocol", draft-ietf-netconf-restconf, work in progress. 658 [ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for 659 Abstraction and Control of TE Networks", draft-ietf-teas- 660 actn-requirements, work in progress. 662 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 663 Control of Traffic Engineered Networks", draft-ietf-teas- 664 actn-framework, work in progress. 666 [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", 667 draft-ietf-teas-yang-te-topo, work in progress. 669 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 670 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 671 te, work in progress. 673 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 674 Operation", draft-lee-teas-actn-vn-yang, work in progress. 676 [ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction 677 and Control of TE Networks (ACTN)", draft-leebelotti-teas- 678 actn-info, work in progress. 680 [Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model 681 for Connection-oriented Transport Networks", draft-zhang- 682 teas-transport-service-model, work in progress. 684 [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource 685 Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, 686 work in progress. 688 [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration 689 Scheduling", draft-liu-netmod-yang-schedule, work in 690 progress. 692 9. Contributors 694 Contributor's Addresses 696 Dhruv Dhoddy 697 Huawei Technologies 699 Email: dhruv.ietf@gmail.com 700 Haomian Zheng 701 Huawei Technologies 703 Email: zhenghaomian@huawei.com 705 Sergio Belotti 706 Nokia 708 Email: sergio.belotti@nokia.com 710 Authors' Addresses 712 Young Lee 713 Huawei Technologies 714 5340 Legacy Drive 715 Plano, TX 75023, USA 716 Phone: (469)277-5838 718 Email: leeyoung@huawei.com 720 Xian Zhang 721 Huawei Technologies 723 Email: zhang.xian@huawei.com 725 Daniele Ceccarelli 726 Ericsson 727 Torshamnsgatan,48 728 Stockholm, Sweden 730 Email: daniele.ceccarelli@ericsson.com 732 Bin Yeong Yoon 733 ETRI 735 Email: byyun@etri.re.kr 737 Oscar Gonzalez de Dios 738 Telefonica 740 Email: oscar.gonzalezdedios@telefonica.com