idnits 2.17.1 draft-lee-teas-te-service-mapping-yang-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2017) is 2493 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ACTN-Applicability' is mentioned on line 93, but not defined == Missing Reference: 'L3SM-Yang' is mentioned on line 150, but not defined == Missing Reference: 'RFC3688' is mentioned on line 669, but not defined == Missing Reference: 'RFC7950' is mentioned on line 679, but not defined == Unused Reference: 'Netconf' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'Restconf' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'TE-Topology' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'TE-Tunnel' is defined on line 727, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Dhruv Dhody 3 Internet Draft Huawei 4 Intended status: standard 5 Daniele Ceccarrelli 6 Expires: December 2017 Ericsson 8 - 10 June 29, 2017 12 Traffic Engineering and Service Mapping Yang Model 13 draft-lee-teas-te-service-mapping-yang-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 29, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document provides a YANG data model to map service model (e.g. 56 L3SM) and Traffic Engineering model (e.g. TE Tunnel or ACTN VN 57 model). This model is referred to as TE service Mapping Model. This 58 model is applicable to the operation's need for a seamless control 59 and management of their L3VPN with TE tunnel support. 61 Table of Contents 63 1. Introduction...................................................2 64 2. L3VPN Architecture in ACTN context.............................5 65 3. TE-Service Mapping Model.......................................7 66 4. YANG Data Tree.................................................7 67 5. Yang Data Model................................................9 68 6. Security......................................................16 69 7. Acknowledgements..............................................16 70 8. References....................................................17 71 8.1. Informative References...................................17 72 9. Contributors..................................................18 73 Authors' Addresses...............................................18 75 1. Introduction 77 Data models are a representation of objects that can be configured 78 or monitored within a system. Within the IETF, YANG [RFC6020] is the 79 language of choice for documenting data models, and YANG models have 80 been produced to allow configuration or modeling of a variety of 81 network devices, protocol instances, and network services. YANG data 82 models have been classified in [Netmod-Yang-Model-Classification] 83 and [Service-YANG]. 85 [RFC4110] provides a framework for Layer 3 Provider-Provisioned 86 Virtual Private Networks (PPVPNs). [L3SM-YANG] provides a L3VPN 87 service delivery YANG model for PE-based VPNs. The scope of this 88 draft is limited to a set of domain under the same network operators 89 to deliver services requiring TE tunnels. 91 [ACTN-VN-YANG] describes how customers or end to end orchestrators 92 can request and/or instantiate a generic virtual network service. 93 [ACTN-Applicability] describes a connection between IETF YANG model 94 classifications to ACTN interfaces. In particular, it describes the 95 customer service model can be mapped into the CMI (CNC-MDSC 96 Interface) of the ACTN architecture. 98 The YANG model on the ACTN CMI is known as customer service model in 99 [Service-YANG]. The YANG model developed in this document describes 100 how operator's end to end orchestrator interacts with the MDSC so 101 that the MDSC then can coordinate the control and management of 102 L3VPN MPLS TE tunnels that traverse both IP/MPLS and Transport 103 networks. 105 While IP/MPLS PNC is responsible for provisioning the VPN service on 106 the PE nodes, the MDSC can coordinate how to map the VPN services 107 with TE tunnels. This is consistent with the two of the core 108 functions of the MDSC specified in [ACTN-Frame]: 110 . Customer mapping/translation function: This function is to map 111 customer requests/commands into network provisioning requests 112 that can be sent to the Physical Network Controller (PNC) 113 according to business policies provisioned statically or 114 dynamically. Specifically, it provides mapping and translation 115 of a customer's service request into a set of parameters that 116 are specific to a network type and technology such that network 117 configuration process is made possible. 119 . Virtual service coordination function: This function translates 120 customer service-related information into virtual network 121 service operations in order to seamlessly operate virtual 122 networks while meeting a customer's service requirements. In 123 the context of ACTN, service/virtual service coordination 124 includes a number of service orchestration functions such as 125 multi-destination load balancing, guarantees of service 126 quality, bandwidth and throughput. It also includes 127 notifications for service fault and performance degradation and 128 so forth. 130 In some cases, under the confines of service policy, dynamic TE 131 tunnel creation may need to be supported for the VPN service. This 132 may occur when there are no suitable existing TE tunnels that can 133 support VPN service requirements. Or the operator would like to 134 dynamically create and bind tunnels to the VPN, which could not be 135 shared for network slicing. 137 To summarize there are two mode of operations - 139 . VN/Tunnel Binding - Customer could use the VPN service model 140 [L3SM-Yang] to communicate to the network operator to deliver 141 a L3VPN service. Based on the sites, QoS parameters, VPN service 142 topology, the network operator could create an ACTN VN [ACTN-VN- 143 YANG]. Further the mapping yang model described in Section 5 of 144 this document is used to set this mapping between the L3VPN 145 service and the ACTN VN. Note that this could be done dynamically. 146 The VN (and TE tunnels) could be bound to the L3VPN and not used 147 for any other VPN. 149 . VN/Tunnel Selection - Customer could request an L3VPN service 150 [L3SM-Yang], and with this model as input, the PNC configures the 151 different network elements to deliver the service. Each network 152 element would select a tunnel based on the configuration. With 153 this mode, new tunnels (or VN) are not created for each VPN. Thus, 154 the tunnels can be shared across multiple VPN. Further the mapping 155 yang model described in Section 5 of this document is used to get 156 the mapping between the L3VPN and the tunnels in use. 158 Other mode of operations could be easily added to the current model 159 in future. This could be achieved by adding more granular modes or 160 policy. Such as - 162 o No change to any tunnels is possible, need to reuse existing 163 tunnels. 164 o Change to existing tunnels are possible, but 165 - Only the bandwidth of the existing tunnels can be 166 increased. 167 - Optical Transport tunnels could not be changed, changes 168 only in the IP/MPLS layer. 169 - Optical Transport tunnels can be added on the fly. 170 o A new VN/tunels are setup and bound to the service. 171 - New tunnels in IP/MPLS, that can reuse optical transport 172 tunnels. 173 - New tunnels in both layer. 175 [Editor's note - A future version of the document can be updated to 176 add more modes or policy.] 177 The YANG model described in this document provides an ACTN TE- 178 service mapping model that enables a seamless service mapping across 179 L3VPN, ACTN VN and TE-tunnel models at the controllers. 181 2. L3VPN Architecture in ACTN context 183 Figure 1 shows the architectural context of this document. 185 | L3SM (+CMI) 186 V 187 +------+ 188 | MDSC | 189 +------+ 190 | 191 +-------------------------------+ 192 | | | 193 V V V 194 +--------+ +--------+ +--------+ 195 |IP/MPLS | | Transp.| |IP/MPLS | 196 | PNC 1 | | PNC | | PNC 2 | 197 +--------+ +--------+ +--------+ 199 CE CE 200 \ AS 100 AS 200 / 201 \ / 202 A----B----C----ASBR1------ASBR2----D----E----F 203 /: / /: /: /: /: /: /: 204 / : / / : / : / : / : / : / : 205 CE----G--:-H----I--:-ASBR3-:----ASBR4-:--J--:-K--:-L--:---CE 206 : : : : : : : : : : : : : : 207 : : : : : : : : : : : : : : 208 : : : : : : : : : : : : : : 209 : M-:----:--P---:---S------:---U-----V-:--X-:--Y 210 : / : : / : / : / : / : / 211 :/ : :/ : / : / :/ :/ 212 N----O----Q-------R----------T----------W----Z 213 Transport Network 215 Figure 1: L3VPN Architecture from the IP+Optical Network Perspective 217 There are three main entities in the architecture. 219 . MDSC: This entity is responsible for coordinating a L3VPN service 220 request (expressed in L3SM) with the IP PNC and the Transport PNC. 221 One of the key responsibilities of the MDSC for TE services is to 222 coordinate with both the IP PNC and the Transport PNC for the 223 mapping of L3VPN Service Model and ACTN VN/TE-Tunnel models. With 224 the VN/TE-tunnel binding case, the MDSC will need to coordinate 225 with the Transport PNC to dynamically create the TE-tunnel(s) in 226 the Transport network as needed. These tunnels are added as links 227 in the IP Layer topology. The MDSC coordinates with IP PNC to 228 create the TE-tunnel(s) in the IP layer, as part of the ACTN VN 229 creation. 231 . IP/MPLS PNC: This entity is responsible for device configuration 232 to create PE-PE L3VPN tunnels for the VPN customer and for the 233 configuration of the L3VPN VRF on the PE nodes. Each network 234 element would select a tunnel based on the configuration. 236 . Transport PNC: This entity is responsible for device configuration 237 for TE tunnels in the transport networks. 239 High-Level Control Flows 241 1. Customer asks for a L3VPN between CE1 and CE2 with TE 242 constraints using L3SM model. The customer can provide tunnel 243 creation policy where it allows dynamic VN/TE tunnel creation 244 or not. Under this policy, dynamic VN/TE tunnels can be created 245 when there are no proper VN/TE-tunnels that can support L3VPN 246 tunnels or when there is a strict isolation requirement for the 247 VPN service, e.g., no sharing with other tunnels is allowed. 249 2. The MDSC determines if it needs to create a new VN, and if that 250 is the case, ACTN VN YANG [ACTN-VN-YANG] is used to configure a 251 new VN based on this VPN and map the VPN service to ACTN VN. In 252 case an existing tunnel is to be used, each device will select 253 which tunnel to use and populates this mapping information. 255 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 256 PNC to create a PE-PE tunnel in the IP network mapped to a TE 257 tunnel in the transport network by providing the inter-layer 258 access points and tunnel requirements. The specific service 259 information are passed to the IP/MPLS PNC for the actual VPN 260 configuration and activation. 262 a. The Transport PNC creates the corresponding TE tunnel 263 matching with the access point and egress point. 264 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 265 tunnel ID to bind these two IDs. 267 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 268 customer. (This is not covered by the Yang Model presented in 269 this draft). 271 3. TE-Service Mapping Model 273 The role of TE-service Mapping model is to create a binding 274 relationship across L3SM and TE Tunnel model via generic ACTN VN 275 Model. The ACTN VN YANG model is a generic virtual network service 276 model that allows customers (internal or external) to create a VN 277 that meets the customer's service objective with various 278 constraints. The TE-service mapping model is needed to bind L3VPN 279 specific service model with TE-specific parameters. This binding 280 will facilitate a seamless service operation with underlay-TE 281 network visibility. The TE-service model developed in this document 282 can also be extended to support other services such as L2SM and so 283 one. 285 +---------+ +-------------+ +----------+ 286 | L3SM | <------> | | <-----> | TE-Tunnel| 287 +---------+ | | | Model | 288 | TE-Service | +-----^----+ 289 |Mapping Model| | 290 +---------+ | | +-----v----+ 291 | L2SM | <------> | | <-----> | ACTN VN | 292 +---------+ +-------------+ | Model | 293 +----------+ 295 . . . 297 4. YANG Data Tree 299 module: ietf-te-service-mapping 300 +--rw te-service-mapping 301 | +--rw service-mapping 302 | | +--rw mapping-list* [map-id] 303 | | +--rw map-id uint32 304 | | +--rw map-type? map-type 305 | | +--rw (service)? 306 | | | +--:(l3vpn) 307 | | | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn- 308 service/vpn-id 309 | | | +--:(l2vpn) 310 | | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn- 311 svc/vpn-id 312 | | +--rw (te)? 313 | | +--:(actn-vn) 314 | | | +--rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 315 | | +--:(te) 316 | | +--rw te-tunnel-list* te:tunnel-ref 317 | +--rw site-mapping 318 | +--rw mapping-list* [map-id] 319 | +--rw map-id uint32 320 | +--rw (service)? 321 | | +--:(l3vpn) 322 | | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id 323 | | +--:(l2vpn) 324 | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id 325 | +--rw (te)? 326 | +--:(actn-vn) 327 | | +--rw actn-vn-ref? -> /vn:actn/ap/access-point-list/access- 328 point-id 329 | +--:(te) 330 +--ro te-service-mapping-state 331 +--ro service-mapping 332 | +--ro mapping-list* [map-id] 333 | +--ro map-id uint32 334 | +--ro map-type? map-type 335 | +--ro (service)? 336 | | +--:(l3vpn) 337 | | | +--ro l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn- 338 service/vpn-id 339 | | +--:(l2vpn) 340 | | +--ro l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn- 341 svc/vpn-id 342 | +--ro (te)? 343 | +--:(actn-vn) 344 | | +--ro actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 345 | +--:(te) 346 | +--ro te-tunnel-list* te:tunnel-ref 347 +--ro site-mapping 348 +--ro mapping-list* [map-id] 349 +--ro map-id uint32 350 +--ro (service)? 351 | +--:(l3vpn) 352 | | +--ro l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id 353 | +--:(l2vpn) 354 | +--ro l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id 355 +--ro (te)? 356 +--:(actn-vn) 357 | +--ro actn-vn-ref? -> /vn:actn/ap/access-point-list/access- 358 point-id 359 +--:(te) 361 5. Yang Data Model 363 The YANG code is as follows: 365 file "ietf-te-service-mapping@2017-03-09.yang" 367 module ietf-te-service-mapping { 369 namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping"; 371 prefix "tm"; 373 import ietf-l3vpn-svc { 374 prefix "l3"; 375 } 377 import ietf-l2vpn-svc { 378 prefix "l2"; 379 } 381 import ietf-te { 382 prefix "te"; 383 } 385 import ietf-actn-vn { 386 prefix "vn"; 387 } 389 organization 390 "IETF Traffic Engineering Architecture and Signaling (TEAS) 391 Working Group"; 393 contact 394 "Editor: Young Lee 395 Dhruv Dhody "; 397 description 398 "This module contains a YANG module for the mapping of 399 service (e.g. L3VPN) to the TE tunnels or ACTN VN."; 401 revision 2017-03-09 { 402 description 403 "initial version."; 404 reference 405 "TBD"; 406 } 408 /* 409 * Identities 410 */ 411 identity service-type { 412 description 413 "Base identity from which specific service types are 414 derived."; 415 } 417 identity l3vpn-service { 418 base service-type; 419 description 420 "L3VPN service type."; 421 } 423 identity l2vpn-service { 424 base service-type; 425 description 426 "L2VPN service type."; 427 } 429 /* 430 * Enum 431 */ 432 typedef map-type { 433 type enumeration { 434 enum "bind" { 435 description 436 "The VN/tunnels are binded to the service"; 438 } 439 enum "select" { 440 description 441 "The VPN service select an existing tunnel"; 442 } 443 } 444 description 445 "The map-type"; 446 } 448 /* 449 * Groupings 450 */ 451 grouping service-ref{ 452 description 453 "The reference to the service."; 454 choice service { 455 description 456 "The service"; 457 case l3vpn { 458 leaf l3vpn-ref { 459 type leafref { 460 path "/l3:l3vpn-svc/l3:vpn-services/" 461 + "l3:vpn-service/l3:vpn-id"; 462 } 463 description 464 "The reference to L3VPN Service Yang Model"; 465 } 466 } 467 case l2vpn { 468 leaf l2vpn-ref { 469 type leafref { 470 path "/l2:l2vpn-svc/l2:vpn-services/" 471 + "l2:vpn-svc/l2:vpn-id"; 472 } 473 description 474 "The reference to L2VPN Service Yang Model"; 475 } 477 } 479 } 480 } 482 grouping site-ref { 483 description 484 "The reference to the site."; 485 choice service { 486 description 487 "The service choice"; 488 case l3vpn { 489 leaf l3vpn-ref{ 490 type leafref { 491 path "/l3:l3vpn-svc/l3:sites/l3:site/" 492 + "l3:site-id"; 493 } 494 description 495 "The reference to L3VPN Service Yang Model"; 496 } 497 } 498 case l2vpn { 499 leaf l2vpn-ref{ 500 type leafref { 501 path "/l2:l2vpn-svc/l2:sites/l2:site/" 502 + "l2:site-id"; 503 } 504 description 505 "The reference to L2VPN Service Yang Model"; 506 } 508 } 510 } 511 } 513 grouping te-ref { 514 description 515 "The reference to TE."; 516 choice te { 517 description 518 "The TE"; 519 case actn-vn { 520 leaf actn-vn-ref { 521 type leafref { 522 path "/vn:actn/vn:vn/vn:vn-list/vn:vn-id"; 523 } 524 description 525 "The reference to ACTN VN"; 526 } 527 } 528 case te { 529 leaf-list te-tunnel-list { 530 type te:tunnel-ref; 531 description 532 "Reference to TE Tunnels"; 533 } 534 } 536 } 538 } 540 grouping te-endpoint-ref { 541 description 542 "The reference to TE endpoints."; 543 choice te { 544 description 545 "The TE"; 546 case actn-vn { 547 leaf actn-vn-ref { 548 type leafref { 549 path "/vn:actn/vn:ap/vn:access-point-list" 550 + "/vn:access-point-id"; 551 } 552 description 553 "The reference to ACTN VN"; 554 } 555 } 556 case te { 557 /*should we refer to Te-topology or Te-tunnel's 558 endpoint(?)*/ 559 } 561 } 563 } 565 grouping service-mapping { 566 description 567 "Mapping between Services and TE"; 568 container service-mapping { 569 description 570 "Mapping between Services and TE"; 572 list mapping-list { 573 key "map-id"; 574 description 575 "Mapping identified via a map-id"; 576 leaf map-id { 577 type uint32; 578 description 579 "a unique mapping identifier"; 580 } 581 leaf map-type { 582 type map-type; 583 description 584 "Tunnel Bind or Tunnel Selection"; 585 } 586 uses service-ref; 588 uses te-ref; 589 } 590 } 591 } 592 grouping site-mapping { 593 description 594 "Mapping between VPN access site and TE 595 endpoints or AP"; 596 container site-mapping { 597 description 598 "Mapping between VPN access site and TE 599 endpoints or AP"; 600 list mapping-list { 601 key "map-id"; 602 description 603 "Mapping identified via a map-id"; 604 leaf map-id { 605 type uint32; 606 description 607 "a unique mapping identifier"; 608 } 609 uses site-ref; 611 uses te-endpoint-ref; 612 } 614 } 615 } 617 /* 618 * Configuration data nodes 619 */ 620 container te-service-mapping { 621 description 622 "Mapping between Services and TE"; 624 uses service-mapping; 626 uses site-mapping; 627 } 629 /* 630 * Operational data nodes 631 */ 633 container te-service-mapping-state{ 634 config false; 636 description 637 "Mapping between Services and TE"; 639 uses service-mapping; 641 uses site-mapping; 642 } 644 } 646 648 6. Security 650 This document is an informational draft. When the models mentioned 651 in this draft are implemented, detailed security consideration will 652 be given in such work. 654 How security fits into the whole architecture has the following 655 components: 657 - the use of Restconf security between components 659 - the use of authentication and policy to govern which services can 660 be requested by different parties. 662 - how security may be requested as an element of a service and 663 mapped down to protocol security mechanisms as well as separation 664 (slicing) of physical resources) 666 7. IANA Considerations 668 This document registers the following namespace URIs in the IETF XML 669 registry [RFC3688]: 671 -------------------------------------------------------------------- 672 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping 673 Registrant Contact: The IESG. 674 XML: N/A, the requested URI is an XML namespace. 675 -------------------------------------------------------------------- 677 This document registers the following YANG modules in the YANG 678 Module 679 Names registry [RFC7950]: 681 -------------------------------------------------------------------- 682 name: ietf-service-mapping 683 namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping 684 prefix: rip 685 reference: RFC XXXX (TDB) 686 -------------------------------------------------------------------- 688 8. Acknowledgements 690 We thank Diego Caviglia and Igor Bryskin for useful discussions and 691 motivation for this work. 693 9. References 695 9.1. Informative References 697 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 698 Provider-Provisioned Virtual Private Networks (PPVPNs)", 699 RFC 4110, July 2005. 701 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for 702 the Network Configuration Protocol (NETCONF)", RFC 6020, 703 October 2010. 705 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 706 Explained", draft-wu-opsawg-service-model-explained, work 707 in progress. 709 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. 710 Moberg, "YANG Module Classification", draft-ietf-netmod- 711 yang-model-classification, work in progress. 713 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 714 and A. Bierman, Ed., "Network Configuration Protocol 715 (NETCONF)", RFC 6241. 717 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 718 Protocol", draft-ietf-netconf-restconf, work in progress. 720 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 721 Control of Traffic Engineered Networks", draft-ietf-teas- 722 actn-framework, work in progress. 724 [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", 725 draft-ietf-teas-yang-te-topo, work in progress. 727 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 728 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 729 te, work in progress. 731 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 732 Operation", draft-lee-teas-actn-vn-yang, work in progress. 734 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model 735 for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 736 service-model, work in progress. 738 10. Contributors 740 Authors' Addresses 742 Young Lee 743 Huawei Technologies 744 5340 Legacy Drive 745 Plano, TX 75023, USA 746 Phone: (469)277-5838 748 Email: leeyoung@huawei.com 750 Dhruv Dhody 751 Huawei Technologies 753 Email: dhruv.ietf@gmail.com 754 Daniele Ceccarelli 755 Ericsson 756 Torshamnsgatan,48 757 Stockholm, Sweden 759 Email: daniele.ceccarelli@ericsson.com