idnits 2.17.1 draft-lee-teas-te-service-mapping-yang-04.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 11 instances of too long lines in the document, the longest one being 5 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 (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Proposed 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 98, but not defined == Missing Reference: 'L3SM-Yang' is mentioned on line 156, but not defined == Missing Reference: 'RFC6241' is mentioned on line 644, but not defined == Missing Reference: 'RFC6536' is mentioned on line 645, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 656, but not defined == Missing Reference: 'RFC7950' is mentioned on line 667, but not defined == Unused Reference: 'Netconf' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'Restconf' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'TE-Topology' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'TE-Tunnel' is defined on line 714, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Internet Draft Dhruv Dhody 3 Intended status: standard track Huawei 4 Expires: April 30, 2018 5 Daniele Ceccarelli 6 Ericsson 8 Jeff Tantsura 9 Huawei 11 Giuseppe Fioccola 12 Telecom Italia 14 October 30, 2017 16 Traffic Engineering and Service Mapping Yang Model 18 draft-lee-teas-te-service-mapping-yang-04 20 Abstract 22 This document provides a YANG data model to map service model (e.g., 23 L3SM) and Traffic Engineering model (e.g., TE Tunnel or ACTN VN 24 model). This model is referred to as TE service Mapping Model. This 25 model is applicable to the operation's need for a seamless control 26 and management of their VPN services with TE tunnel support. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with 31 the provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on April 30, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction...................................................2 68 2. L3VPN Architecture in ACTN context.............................5 69 3. TE-Service Mapping Model.......................................7 70 4. YANG Data Tree.................................................7 71 5. Yang Data Model................................................8 72 6. Security......................................................15 73 7. IANA Considerations...........................................16 74 8. Acknowledgements..............................................16 75 9. References....................................................16 76 9.1. Informative References...................................16 77 10. Contributors.................................................17 78 Authors' Addresses...............................................18 80 1. Introduction 82 Data models are a representation of objects that can be configured 83 or monitored within a system. Within the IETF, YANG [RFC6020] is the 84 language of choice for documenting data models, and YANG models have 85 been produced to allow configuration or modeling of a variety of 86 network devices, protocol instances, and network services. YANG data 87 models have been classified in [Netmod-Yang-Model-Classification] 88 and [Service-YANG]. 90 [RFC4110] provides a framework for Layer 3 Provider-Provisioned 91 Virtual Private Networks (PPVPNs). [L3SM-YANG] provides a L3VPN 92 service delivery YANG model for PE-based VPNs. The scope of this 93 draft is limited to a set of domain under the same network operators 94 to deliver services requiring TE tunnels. 96 [ACTN-VN-YANG] describes how customers or end to end orchestrators 97 can request and/or instantiate a generic virtual network service. 98 [ACTN-Applicability] describes a connection between IETF YANG model 99 classifications to ACTN interfaces. In particular, it describes the 100 customer service model can be mapped into the CMI (CNC-MDSC 101 Interface) of the ACTN architecture. 103 The YANG model on the ACTN CMI is known as customer service model in 104 [Service-YANG]. The YANG model developed in this document describes 105 how operator's end to end orchestrator interacts with the MDSC so 106 that the MDSC then can coordinate the control and management of 107 L3VPN MPLS TE tunnels that traverse both IP/MPLS and Transport 108 networks. In addition, the YANG model described in this document 109 also supports the mapping with TE tunnels for other VPN models such 110 as L1VPN and L2VPN, etc. 112 While IP/MPLS PNC is responsible for provisioning the VPN service on 113 the PE nodes, the MDSC can coordinate how to map the VPN services 114 with TE tunnels. This is consistent with the two of the core 115 functions of the MDSC specified in [ACTN-Frame]: 117 . Customer mapping/translation function: This function is to map 118 customer requests/commands into network provisioning requests 119 that can be sent to the Physical Network Controller (PNC) 120 according to business policies provisioned statically or 121 dynamically. Specifically, it provides mapping and translation 122 of a customer's service request into a set of parameters that 123 are specific to a network type and technology such that network 124 configuration process is made possible. 126 . Virtual service coordination function: This function translates 127 customer service-related information into virtual network 128 service operations in order to seamlessly operate virtual 129 networks while meeting a customer's service requirements. In 130 the context of ACTN, service/virtual service coordination 131 includes a number of service orchestration functions such as 132 multi-destination load balancing, guarantees of service 133 quality, bandwidth and throughput. It also includes 134 notifications for service fault and performance degradation and 135 so forth. 137 In some cases, under the confines of service policy, dynamic TE 138 tunnel creation may need to be supported for the VPN service. This 139 may occur when there are no suitable existing TE tunnels that can 140 support VPN service requirements. Or the operator would like to 141 dynamically create and bind tunnels to the VPN, which could not be 142 shared for network slicing. 144 To summarize there are three mode of operations, but not limited to: 146 . New VN/Tunnel Binding - Customer could request an L3VPN service 147 [L3SM-YANG] with a new VN/Tunnel not shared with other existing 148 services. This is to meet VPN isolation requirement. 149 Further the mapping yang model described in Section 5 of this 150 document is used to set this mapping between the L3VPN service and 151 the ACTN VN. Note that this could be done dynamically. The VN (and 152 TE tunnels) could be bound to the L3VPN and not used for any other 153 VPN. 155 . VN/Tunnel Selection - Customer could request an L3VPN service 156 [L3SM-Yang], and with this model as input, the PNC configures the 157 different network elements to deliver the service. Each network 158 element would select a tunnel based on the configuration. With 159 this mode, new tunnels (or VN) are not created for each VPN. Thus, 160 the tunnels can be shared across multiple VPN. Further the mapping 161 yang model described in Section 5 of this document is used to get 162 the mapping between the L3VPN and the tunnels in use. No 163 modification is allowed when an existing tunnel is selected. 165 . VN/Tunnel Modify - This mode allows the modification of the 166 properties of the existing VN/tunnel (e.g., bandwidth) when 167 VN/Tunnel Selection Mode is applied. 169 Other mode of operations could be easily added to the current model 170 in the future. 172 [Editor's note - A future version of the document can be updated to 173 add more modes or policy.] 174 The YANG model described in this document provides an ACTN TE- 175 service mapping model that enables a seamless service mapping across 176 L1/2/3 VPN, ACTN VN and TE-tunnel models at the controllers. 178 2. L3VPN Architecture in ACTN context 180 Figure 1 shows the architectural context of this document. 182 | L3SM (+CMI) 183 V 184 +------+ 185 | MDSC | 186 +------+ 187 | 188 +-------------------------------+ 189 | | | 190 V V V 191 +--------+ +--------+ +--------+ 192 |IP/MPLS | | Transp.| |IP/MPLS | 193 | PNC 1 | | PNC | | PNC 2 | 194 +--------+ +--------+ +--------+ 196 CE CE 197 \ AS 100 AS 200 / 198 \ / 199 A----B----C----ASBR1------ASBR2----D----E----F 200 /: / /: /: /: /: /: /: 201 / : / / : / : / : / : / : / : 202 CE----G--:-H----I--:-ASBR3-:----ASBR4-:--J--:-K--:-L--:---CE 203 : : : : : : : : : : : : : : 204 : : : : : : : : : : : : : : 205 : : : : : : : : : : : : : : 206 : M-:----:--P---:---S------:---U-----V-:--X-:--Y 207 : / : : / : / : / : / : / 208 :/ : :/ : / : / :/ :/ 209 N----O----Q-------R----------T----------W----Z 210 Transport Network 212 Figure 1: L3VPN Architecture from the IP+Optical Network Perspective 214 There are three main entities in the architecture. 216 . MDSC: This entity is responsible for coordinating a L3VPN service 217 request (expressed in L3SM) with the IP PNC and the Transport PNC. 218 One of the key responsibilities of the MDSC for TE services is to 219 coordinate with both the IP PNC and the Transport PNC for the 220 mapping of L3VPN Service Model and ACTN VN/TE-Tunnel models. With 221 the VN/TE-tunnel binding case, the MDSC will need to coordinate 222 with the Transport PNC to dynamically create the TE-tunnel(s) in 223 the Transport network as needed. These tunnels are added as links 224 in the IP Layer topology. The MDSC coordinates with IP PNC to 225 create the TE-tunnel(s) in the IP layer, as part of the ACTN VN 226 creation. 228 . IP/MPLS PNC: This entity is responsible for device configuration 229 to create PE-PE L3VPN tunnels for the VPN customer and for the 230 configuration of the L3VPN VRF on the PE nodes. Each network 231 element would select a tunnel based on the configuration. 233 . Transport PNC: This entity is responsible for device configuration 234 for TE tunnels in the transport networks. 236 High-Level Control Flows 238 1. Customer asks for a L3VPN between CE1 and CE2 with TE 239 constraints using L3SM model. The customer can provide tunnel 240 creation policy where it allows dynamic VN/TE tunnel creation 241 or not. Under this policy, dynamic VN/TE tunnels can be created 242 when there are no proper VN/TE-tunnels that can support L3VPN 243 tunnels or when there is a strict isolation requirement for the 244 VPN service, e.g., no sharing with other tunnels is allowed. 246 2. The MDSC determines if it needs to create a new VN, and if that 247 is the case, ACTN VN YANG [ACTN-VN-YANG] is used to configure a 248 new VN based on this VPN and map the VPN service to ACTN VN. In 249 case an existing tunnel is to be used, each device will select 250 which tunnel to use and populates this mapping information. 252 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 253 PNC to create a PE-PE tunnel in the IP network mapped to a TE 254 tunnel in the transport network by providing the inter-layer 255 access points and tunnel requirements. The specific service 256 information are passed to the IP/MPLS PNC for the actual VPN 257 configuration and activation. 259 a. The Transport PNC creates the corresponding TE tunnel 260 matching with the access point and egress point. 261 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 262 tunnel ID to bind these two IDs. 264 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 265 customer. (This is not covered by the Yang Model presented in 266 this draft). 268 3. TE-Service Mapping Model 270 The role of TE-service Mapping model is to create a binding 271 relationship across L3SM, L2SM [L2SM-YANG] and L1CSM [L1CSM-YANG] 272 and TE Tunnel model via generic ACTN VN Model. The ACTN VN YANG 273 model is a generic virtual network service model that allows 274 customers (internal or external) to create a VN that meets the 275 customer's service objective with various constraints. The TE- 276 service mapping model is needed to bind LxVPN specific service model 277 with TE-specific parameters. This binding will facilitate a seamless 278 service operation with underlay-TE network visibility. The TE- 279 service model developed in this document can also be extended to 280 support other services beyond L3SM, L2SM and L1CSM. 282 +---------+ +-------------+ +----------+ 283 | L3SM | <------> | | <-----> | TE-Tunnel| 284 +---------+ | | | Model | 285 | | +-----^----+ 286 +---------+ | TE-Service | | 287 | L2SM | <------> |Mapping Model| | 288 +---------+ | | | 289 | | +-----v----+ 290 +---------+ | | | ACTN VN | 291 | L1CSM | <------> | | <-----> | Model | 292 +---------+ +-------------+ +----------+ 294 . . . 296 4. YANG Data Tree 298 module: ietf-te-service-mapping 299 +--rw te-service-mapping 300 +--rw service-mapping 301 | +--rw mapping-list* [map-id] 302 | +--rw map-id uint32 303 | +--rw map-type? map-type 304 | +--rw (service)? 305 | | +--:(l3vpn) 306 | | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn- 307 service/vpn-id 308 | | +--:(l2vpn) 309 | | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn- 310 svc/vpn-id 311 | | +--:(l1vpn) 312 | | +--rw l1vpn-ref? -> /l1:l1cs/service/service- 313 list/subscriber-l1vc-id 314 | +--rw (te)? 315 | +--:(actn-vn) 316 | | +--rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 317 | +--:(te) 318 | +--rw te-tunnel-list* te:tunnel-ref 319 +--rw site-mapping 320 +--rw mapping-list* [map-id] 321 +--rw map-id uint32 322 +--rw (service)? 323 | +--:(l3vpn) 324 | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id 325 | +--:(l2vpn) 326 | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id 327 | +--:(l1vpn) 328 | +--rw l1vpn-ref? -> /l1:l1cs/access/uni-list/UNI-ID 329 +--rw (te)? 330 +--:(actn-vn) 331 | +--rw actn-vn-ref? -> /vn:actn/ap/access-point- 332 list/access-point-id 333 +--:(te) 335 5. Yang Data Model 337 The YANG code is as follows: 339 file "ietf-te-service-mapping@2017-10-27.yang" 341 module ietf-te-service-mapping { 343 namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping"; 344 prefix "tm"; 346 import ietf-l3vpn-svc { 347 prefix "l3"; 348 } 350 import ietf-l2vpn-svc { 351 prefix "l2"; 352 } 354 import ietf-l1csm { 355 prefix "l1"; 356 } 358 import ietf-te { 359 prefix "te"; 360 } 362 import ietf-actn-vn { 363 prefix "vn"; 364 } 366 organization 367 "IETF Traffic Engineering Architecture and Signaling (TEAS) 368 Working Group"; 370 contact 371 "Editor: Young Lee 372 Dhruv Dhody "; 373 description 374 "This module contains a YANG module for the mapping of 375 service (e.g. L3VPN) to the TE tunnels or ACTN VN."; 377 revision 2017-10-27 { 378 description 379 "initial version."; 380 reference 381 "TBD"; 382 } 384 /* 385 * Identities 386 */ 387 identity service-type { 388 description 389 "Base identity from which specific service types are 390 derived."; 391 } 393 identity l3vpn-service { 394 base service-type; 395 description 396 "L3VPN service type."; 397 } 399 identity l2vpn-service { 400 base service-type; 401 description 402 "L2VPN service type."; 403 } 405 identity l1vpn-service { 406 base service-type; 407 description 408 "L1VPN connectivity service type."; 409 } 410 /* 411 * Enum 412 */ 413 typedef map-type { 414 type enumeration { 415 enum "new" { 416 description 417 "The new VN/tunnels are binded to the service"; 418 } 419 enum "select" { 420 description 421 "The VPN service selects an existing tunnel with no 422 modification"; 423 } 424 enum "modify" { 425 description 426 "The VPN service selects an existing tunnel and allows 427 to modify the properties of the tunnel (e.g., b/w) "; 428 } 429 } 430 description 431 "The map-type"; 432 } 433 /* 434 * Groupings 435 */ 436 grouping service-ref{ 437 description 438 "The reference to the service."; 439 choice service { 440 description 441 "The service"; 442 case l3vpn { 443 leaf l3vpn-ref { 444 type leafref { 445 path "/l3:l3vpn-svc/l3:vpn-services/" 446 + "l3:vpn-service/l3:vpn-id"; 447 } 448 description 449 "The reference to L3VPN Service Yang Model"; 450 } 451 } 452 case l2vpn { 453 leaf l2vpn-ref { 454 type leafref { 455 path "/l2:l2vpn-svc/l2:vpn-services/" 456 + "l2:vpn-svc/l2:vpn-id"; 457 } 458 description 459 "The reference to L2VPN Service Yang Model"; 460 } 462 } 463 case l1vpn { 464 leaf l1vpn-ref { 465 type leafref { 466 path "/l1:l1cs/l1:service/" 467 + "l1:service-list/l1:subscriber-l1vc-id"; 468 } 469 description 470 "The reference to L1VPN Service Yang Model"; 471 } 473 } 474 } 475 } 477 grouping site-ref { 478 description 479 "The reference to the site."; 480 choice service { 481 description 482 "The service choice"; 483 case l3vpn { 484 leaf l3vpn-ref{ 485 type leafref { 486 path "/l3:l3vpn-svc/l3:sites/l3:site/" 487 + "l3:site-id"; 488 } 489 description 490 "The reference to L3VPN Service Yang Model"; 491 } 492 } 493 case l2vpn { 494 leaf l2vpn-ref{ 495 type leafref { 496 path "/l2:l2vpn-svc/l2:sites/l2:site/" 497 + "l2:site-id"; 498 } 499 description 500 "The reference to L2VPN Service Yang Model"; 501 } 503 } 504 case l1vpn { 505 leaf l1vpn-ref{ 506 type leafref { 507 path "/l1:l1cs/l1:access/l1:uni-list/" 508 + "l1:UNI-ID"; 509 } 510 description 511 "The reference to L1VPN Connectivity Service Yang 512 Model"; 513 } 515 } 517 } 518 } 520 grouping te-ref { 521 description 522 "The reference to TE."; 524 choice te { 525 description 526 "The TE"; 527 case actn-vn { 528 leaf actn-vn-ref { 529 type leafref { 530 path "/vn:actn/vn:vn/vn:vn-list/vn:vn-id"; 531 } 532 description 533 "The reference to ACTN VN"; 534 } 535 } 536 case te { 537 leaf-list te-tunnel-list { 538 type te:tunnel-ref; 539 description 540 "Reference to TE Tunnels"; 541 } 542 } 544 } 546 } 548 grouping te-endpoint-ref { 549 description 550 "The reference to TE endpoints."; 551 choice te { 552 description 553 "The TE"; 554 case actn-vn { 555 leaf actn-vn-ref { 556 type leafref { 557 path "/vn:actn/vn:ap/vn:access-point-list" 558 + "/vn:access-point-id"; 559 } 560 description 561 "The reference to ACTN VN"; 562 } 563 } 564 case te { 565 /*should we refer to Te-topology or Te-tunnel's 566 endpoint(?)*/ 567 } 568 } 570 } 572 grouping service-mapping { 573 description 574 "Mapping between Services and TE"; 575 container service-mapping { 576 description 577 "Mapping between Services and TE"; 579 list mapping-list { 580 key "map-id"; 581 description 582 "Mapping identified via a map-id"; 583 leaf map-id { 584 type uint32; 585 description 586 "a unique mapping identifier"; 587 } 588 leaf map-type { 589 type map-type; 590 description 591 "Tunnel Bind or Tunnel Selection"; 592 } 593 uses service-ref; 595 uses te-ref; 596 } 597 } 598 } 599 grouping site-mapping { 600 description 601 "Mapping between VPN access site and TE 602 endpoints or AP"; 603 container site-mapping { 604 description 605 "Mapping between VPN access site and TE 606 endpoints or AP"; 607 list mapping-list { 608 key "map-id"; 609 description 610 "Mapping identified via a map-id"; 611 leaf map-id { 612 type uint32; 613 description 614 "a unique mapping identifier"; 615 } 616 uses site-ref; 618 uses te-endpoint-ref; 619 } 621 } 622 } 624 /* 625 * Configuration data nodes 626 */ 627 container te-service-mapping { 628 description 629 "Mapping between Services and TE"; 631 uses service-mapping; 633 uses site-mapping; 634 } 636 } 638 640 6. Security 642 The configuration, state, and action data defined in this document 643 are designed to be accessed via a management protocol with a secure 644 transport layer, such as NETCONF [RFC6241]. The NETCONF access 645 control model [RFC6536] provides the means to restrict access for 646 particular NETCONF users to a preconfigured subset of all available 647 NETCONF protocol operations and content. 649 A number of configuration data nodes defined in this document are 650 writable/deletable (i.e., "config true") These data nodes may be 651 considered sensitive or vulnerable in some network environments. 653 7. IANA Considerations 655 This document registers the following namespace URIs in the IETF XML 656 registry [RFC3688]: 658 -------------------------------------------------------------------- 659 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping 660 Registrant Contact: The IESG. 661 XML: N/A, the requested URI is an XML namespace. 662 -------------------------------------------------------------------- 664 This document registers the following YANG modules in the YANG 665 Module 667 Names registry [RFC7950]: 669 -------------------------------------------------------------------- 670 name: ietf-te-service-mapping 671 namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping 672 reference: RFC XXXX (TDB) 673 -------------------------------------------------------------------- 675 8. Acknowledgements 677 We thank Diego Caviglia and Igor Bryskin for useful discussions and 678 motivation for this work. 680 9. References 682 9.1. Informative References 684 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 685 Provider-Provisioned Virtual Private Networks (PPVPNs)", 686 RFC 4110, July 2005. 688 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for 689 the Network Configuration Protocol (NETCONF)", RFC 6020, 690 October 2010. 692 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 693 Explained", draft-wu-opsawg-service-model-explained, work 694 in progress. 696 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. 697 Moberg, "YANG Module Classification", draft-ietf-netmod- 698 yang-model-classification, work in progress. 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 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 708 Control of Traffic Engineered Networks", draft-ietf-teas- 709 actn-framework, work in progress. 711 [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", 712 draft-ietf-teas-yang-te-topo, work in progress. 714 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 715 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 716 te, work in progress. 718 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 719 Operation", draft-lee-teas-actn-vn-yang, work in progress. 721 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model 722 for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 723 service-model, work in progress. 725 [L2SM-YANG] B. Wen, et al, "A YANG Data Model for L2VPN Service 726 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 727 progress. 729 [L1CSM-YANG] G. Fioccola, et al, "A Yang Data Model for L1 730 Connectivity Service Model (L1CSM)", draft-fioccola-ccamp- 731 l1csm-yang, work in progress. 733 10. Contributors 734 Authors' Addresses 736 Young Lee 737 Huawei Technologies 738 5340 Legacy Drive 739 Plano, TX 75023, USA 740 Phone: (469)277-5838 742 Email: leeyoung@huawei.com 744 Dhruv Dhody 745 Huawei Technologies 747 Email: dhruv.ietf@gmail.com 749 Daniele Ceccarelli 750 Ericsson 751 Torshamnsgatan,48 752 Stockholm, Sweden 754 Email: daniele.ceccarelli@ericsson.com 756 Jeff Tantsura 757 Huawei 759 EMail: jefftant@gmail.com 761 Giuseppe Fioccola 762 Telecom Italia 764 Email: giuseppe.fioccola@telecomitalia.it