idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-12.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 (September 19, 2020) is 1315 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: 'RFC XXXX' is mentioned on line 275, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF63' == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Y. Lee 3 Internet-Draft Samsung 4 Intended status: Standards Track K. Lee 5 Expires: March 23, 2021 Korea Telecom 6 H. Zheng 7 Huawei Technologies 8 O. Gonzalez de Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 12 September 19, 2020 14 A YANG Data Model for L1 Connectivity Service Model (L1CSM) 15 draft-ietf-ccamp-l1csm-yang-12 17 Abstract 19 This document provides a YANG data model for Layer 1 Connectivity 20 Service Model (L1CSM). The intent of this document is to provide a 21 Layer 1 service model exploiting YANG data model, which can be 22 utilized by a customer network controller to initiate a service 23 request connectivity as well as retrieving service states toward a 24 Layer 1 network controller communicating with its customer network 25 controller. This YANG model is NMDA-compliant. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 23, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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 (https://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 respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 65 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 66 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. L1CSM YANG Model (Tree Structure) . . . . . . . . . . . . . . 7 68 4. L1CSM YANG Code . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 73 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 10.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 This document provides a YANG data model for L1VPN Connectivity 82 Service Model (L1CSM) which can be classified as Network Service YANG 83 module per [RFC8199]. The intent of this document is to provide a 84 transport service model exploiting YANG data model, which can be 85 utilized by a client network controller to initiate a service request 86 connectivity request as well as retrieving service states toward a 87 transport network controller communicating with the client controller 88 via a NETCONF [RFC8341] or a RESTCONF [RFC8040] interface. 90 [RFC4847] provides a framework and service level requirements for 91 Layer 1 Virtual Private Networks (L1VPNs). It classifies service 92 models as management-based service model, signaling-based service 93 model (Basic Mode) and signaling and routing service model (Enhanced 94 Mode). 96 In the management-based service model, customer management systems 97 and provider management systems communicate with each other. 98 Customer management systems access provider management systems to 99 request layer 1 connection setup/deletion between a pair of CEs. 100 Customer management systems may obtain additional information, such 101 as resource availability information and monitoring information, from 102 provider management systems. There is no control message exchange 103 between a CE and PE. 105 In the signaling-based service model (Basic Model), the CE-PE 106 interface's functional repertoire is limited to path setup signaling 107 only. In the Signaling and routing service model (Enhanced Mode), 108 the CE-PE interface provides the signaling capabilities as in the 109 Basic Mode, plus permits limited exchange of information between the 110 control planes of the provider and the customer to help such 111 functions as discovery of customer network routing information (i.e., 112 reachability or TE information in remote customer sites), or 113 parameters of the part of the provider's network dedicated to the 114 customer. 116 The primary focus of this document is to describe L1CS YANG model 117 required for the instantiation of point-to-point L1VPN service. A 118 L1VPN is a service offered by a core layer 1 network to provide layer 119 1 connectivity between two or more customer sites where the customer 120 has some control over the establishment and type of the connectivity. 122 The data model presented in Section 3 is in consistent with [MEF63]. 123 The data model includes configuration and state data according to the 124 new Network Management Datastore Architecture [RFC8342]. 126 1.1. Deployment Scenarios 128 Figure 1 depicts a deployment scenario of the L1VPN SDN control-based 129 service model for an external customer instantiating L1 point-to- 130 point connectivity to the provider. 132 +------------+ 133 | Customer | 134 | Service | 135 |Orchestrator| 136 +------------+ 137 | 138 .. .. .. .. ..|.. .. .. .. .. .. 139 : | : 140 : +--------------------+ : 141 : | | : 142 : | +----------+ | : 143 : | | Network | | : 144 : | | SDN | | : 145 : | |Controller| | : 146 : | |/NMS/EMS | | : 147 : | +----------+ | : 148 : | | : 149 : | | : 150 +----+ : +----+ +----+ +----+ : +----+ 151 | CE |----:---| PE |----| P |----| PE |---:---| CE | 152 +----+ : +----+ +----+ +----+ : +----+ 153 : | | : 154 : | | : 155 : +--------------------+ : 156 : | | : 157 : |<-Provider network->| : 159 Customer Customer 160 Interface Interface 162 Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: External 163 Customer 165 With this scenario, the customer service orchestrator interfaces with 166 the network SDN controller of the provider using Customer Service 167 Model as defined in [RFC8309]. 169 Figure 2 depicts another deployment scenario for internal customer 170 (e.g., higher-layer service management department(s)) interfacing the 171 layer 1 transport network department. With this scenario, a multi- 172 service backbone is characterized such that each service department 173 of a provider (e.g., L2/3 services) that receives the same provider's 174 L1VPN service provides a different kind of higher-layer service. The 175 customer receiving the L1VPN service (i.e., each service department) 176 can offer its own services, whose payloads can be any layer (e.g., 177 ATM, IP, TDM). The layer 1 transport network and each service 178 network belong to the same organization, but may be managed 179 separately. The Service SDN Controller is the control/management 180 entity owned by higher-layer service department (e.g., L2/3 VPN) 181 whereas the Network SDN Controller is the control/management entity 182 responsible for Layer 1 connectivity service. The CEs in Figure 2 183 are L2/3 devices that interface with L1 PE devices. 185 +----------+ 186 | Service | 187 | SDN | 188 |Controller| 189 |/EMS/NMS | 190 | for L2/3 | 191 +----------+ 192 | 193 | 194 | 195 +--------------------+ 196 | | 197 | +----------+ | 198 | | Network | | 199 | | SDN | | 200 | |Controller| | 201 | |/EMS/NMS | | 202 | | for L1VPN| | 203 | +----------+ | 204 | | 205 | | 206 +----+ +----+ +----+ +----+ +----+ 207 | CE |--------| PE |----| P |----| PE |------| CE | 208 +----+ +----+ +----+ +----+ +----+ 209 | | | | 210 | | | | 211 | +--------------------+ | 212 | | | | 213 | |<------------------>| | 214 | Provider Network | 215 | For Layer 1 | 216 |<------------------------------------------>| 217 Provider Network for L2/3 219 Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: Internal 220 Customer 222 The benefit is that the same layer 1 transport network resources are 223 shared by multiple services. A large capacity backbone network (data 224 plane) can be built economically by having the resources shared by 225 multiple services usually with flexibility to modify topologies, 226 while separating the control functions for each service department. 227 Thus, each customer can select a specific set of features that are 228 needed to provide their own service [RFC4847]. 230 1.2. Terminology 232 Refer to [RFC4847] and [RFC5253] for the key terms used in this 233 document. 235 The following terms are defined in [RFC7950] and are not redefined 236 here: 238 o client 240 o server 242 o augment 244 o data model 246 o data node 248 The following terms are defined in [RFC6241] and are not redefined 249 here: 251 o configuration data 253 o state data 255 The terminology for describing YANG data models is found in 256 [RFC7950]. 258 1.3. Tree Diagram 260 A simplified graphical representation of the data model is used in 261 Section 3 of this this document. The meaning of the symbols in these 262 diagrams is defined in [RFC8340]. 264 1.4. Prefixes in Data Node Names 266 In this document, names of data nodes and other data model objects 267 are prefixed using the standard prefix associated with the 268 corresponding YANG imported modules. The module ietf-layer1-types 269 specified in [I-D.ietf-ccamp-layer1-types] and ietf-yang-types 270 specified in [RFC6991] are imported in this module. 272 +-------------+-------------------+------------------------------+ 273 | Prefix | YANG module | Reference | 274 +-------------+-------------------+------------------------------+ 275 | l1csm | ietf-l1csm | [RFC XXXX] | 276 | l1-types | ietf-layer1-types |[I-D.ietf-ccamp-layer1-types] | 277 | yang | ietf-yang-types | [RFC6991] | 278 +-------------+-------------------+------------------------------+ 280 Note: The RFC Editor will replace XXXX with the number assigned to 281 the RFC once this document becomes an RFC. 283 2. Definitions 285 L1VC Layer 1 Virtual Connection 287 SLS Service Level Specification 289 UNI User Network Interface 291 PE Provider Edge 293 CE Customer Edge 295 EP End Point 297 P Protocol 299 C Coding 301 O Optical Interface 303 3. L1CSM YANG Model (Tree Structure) 304 module: ietf-l1csm 305 +--rw l1-connectivity 306 +--rw access 307 | +--rw unis 308 | +--rw uni* [id] 309 | +--rw id string 310 | +--rw protocol? identityref 311 | +--rw coding? identityref 312 | +--rw optical-interface? identityref 313 +--rw services 314 +--rw service* [service-id] 315 +--rw service-id string 316 +--rw endpoint-1 317 | +--rw id string 318 | +--rw uni 319 | -> /l1-connectivity/access/unis/uni/id 320 +--rw endpoint-2 321 | +--rw id string 322 | +--rw uni 323 | -> /l1-connectivity/access/unis/uni/id 324 +--rw start-time? yang:date-and-time 325 +--rw time-interval? int32 326 +--rw performance-metric* identityref 328 4. L1CSM YANG Code 330 file "ietf-l1csm@2020-03-09.yang" 331 module ietf-l1csm { 332 yang-version 1.1; 333 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 334 prefix "l1csm"; 336 import ietf-yang-types { 337 prefix "yang"; 338 } 340 import ietf-layer1-types { 341 prefix "l1-types"; 342 } 344 organization 345 "Internet Engineering Task Force (IETF) CCAMP WG"; 347 contact 348 "Editor: Y. Lee (younglee.tx@gmail.com) 349 Editor: K. Lee (kwangkoog.lee@kt.com) 350 Editor: H. Zheng (zhenghaomian@huawei.com) 351 Editor: D. Dhody (dhruv.ietf@gmail.com) 352 Editor: O. G. de-Dios (oscar.gonzalezdedios@telefonica.com) 353 Editor: D. Ceccarelli (daniele.ceccarelli@ericsson.com)"; 355 description 356 "This module describes L1 connectivity service based on MEF 63: 357 Subscriber Layer 1 Service Attribute Technical Specification. 358 Refer to MEF 63 for all terms and the original references 359 used in the module. 361 Copyright (c) 2020 IETF Trust and the persons identified as 362 authors of the code. All rights reserved. 363 Redistribution and use in source and binary forms, with or 364 without modification, is permitted pursuant to, and subject 365 to the license terms contained in, the Simplified BSD 366 License set forth in Section 4.c of the IETF Trust's Legal 367 Provisions Relating to IETF Documents 368 (http://trustee.ietf.org/license-info). 370 This version of this YANG module is part of RFC XXXX; see 371 the RFC itself for full legal notices."; 373 revision "2020-03-09" { 374 description "Initial revision."; 375 reference "RFC XXXX: A Yang Data Model for L1 Connectivity 376 Service Model (L1CSM)"; 377 // Note: The RFC Editor will replace XXXX with the number 378 // assigned to the RFC once this document becomes an RFC. 379 } 381 grouping protocol-coding-optical-interface { 382 description 383 "describes where p:protocol type; c:coding 384 function; o:optical interface function"; 385 reference "MEF 63"; 386 leaf protocol { 387 type identityref { 388 base "l1-types:client-signal"; 389 } 390 description 391 "List of physical layer L1VC client protocol"; 393 } 394 leaf coding { 395 type identityref { 396 base "l1-types:coding-func"; 397 } 398 description "coding function"; 399 } 401 leaf optical-interface { 402 type identityref { 403 base "l1-types:optical-interface-func"; 404 } 405 description "optical-interface-function"; 406 } 408 } 410 grouping subscriber-l1vc-sls-service-attribute { 411 description 412 "The value of the Subscriber L1VC SLS (Service Level 413 Specification) Service Attribute"; 414 reference "MEF 63"; 416 leaf start-time { 417 type yang:date-and-time; 418 description "a time that represent the date and time 419 for the start of the SLS"; 420 } 422 leaf time-interval { 423 type int32; 424 units seconds; 425 description 426 "a time interval (e.g., 2,419,200 seconds which is 28 days) 427 that is used in conjunction wuth time-start to specify a 428 contiguous sequence of time intervals T for determining 429 when performance objectives are met."; 430 } 432 leaf-list performance-metric { 433 type identityref { 434 base "l1-types:service-performance-metric"; 435 } 436 description "list of service performance metric."; 437 } 439 } 441 grouping subscriber-l1vc-endpoint-attributes { 442 description 443 "subscriber layer 1 connection endpoint attributes"; 444 reference "MEF 63"; 446 container endpoint-1 { 447 description "One end of UNI id's - string and id"; 448 leaf id { 449 type string; 450 mandatory true; 451 description "subscriber end point ID of one end"; 452 } 454 leaf uni { 455 type leafref { 456 path "/l1-connectivity/access/unis/uni/id"; 457 } 458 mandatory true; 459 description "this is one end of subscriber L1VC end point 460 ID value = UNI-1"; 461 } 462 } 463 container endpoint-2 { 464 description "One end of UNI id's - string and id"; 465 leaf id { 466 type string; 467 mandatory true; 468 description "subscriber end point ID of the other end"; 469 } 471 leaf uni { 472 type leafref { 473 path "/l1-connectivity/access/unis/uni/id"; 474 } 475 mandatory true; 476 description 477 "this is one other end of subscriber L1VC end point 478 ID value = UNI-2"; 479 } 480 } 481 } 483 container l1-connectivity { 484 description 485 "serves as a top-level container for a list of layer 1 486 connection services (l1cs)"; 488 container access { 489 description "UNI configurations for access networks"; 491 container unis { 492 description "the list of UNI's to be configured"; 494 list uni { 495 key "id"; 496 description "UNI identifier"; 497 leaf id { 498 type string; 499 description "the UNI id of UNI Service Attributes"; 500 } 502 uses protocol-coding-optical-interface; 503 } 504 } 505 } 507 container services { 508 description "L1VC services"; 509 list service { 510 key "service-id"; 511 description 512 "an unique identifier of a subscriber L1VC service"; 514 leaf service-id { 515 type string; 516 mandatory true; 517 description "a unique service identifier for 518 subscriber L1VC."; 519 } 521 uses subscriber-l1vc-endpoint-attributes; 522 uses subscriber-l1vc-sls-service-attribute; 524 }//end of service list 525 } //end of service container 526 }//service top container 527 } 529 531 5. JSON Example 533 This section provides a JSON example of the YANG module described in 534 Section 4. This example configures one L1VC service with two UNIs 535 that describe the UNI endpoints. The service is configured with the 536 starting time to be 06:06:09 on 2018-09-13 for the service life time 537 of 2419200 seconds (which is corresponds to 28 days). In addition, 538 the service is configured to collect one performance metric, One-way- 539 Delay. 541 { 542 "l1-connectivity": { 543 "access": { 544 "unis": { 545 "uni": [ 546 { 547 "id": "MTL-HQ-Node3-Slot2-Port1", 548 "protocol": "ETH-10GigE_LAN ", 549 "coding": "ETH-10GR-PCS-49 ", 550 "optical_interface": "LR-PMD-clause-52 " 551 }, 552 { 553 "id": "MTL-STL-Node5-Slot4-Port3", 554 "protocol": "ETH-10GigE_LAN ", 555 "coding": "ETH-10GR-PCS-49 ", 556 "optical_interface": "ER-PMD-clause-52 " 557 } 558 ] 559 }, 560 }, 561 "services": { 562 "service": [ 563 { 564 "service-id": "Sub-L1VC-1867-LT-MEGAMART", 565 "endpoint-1": 566 { 567 "id": "MTL-HQ_1867-MEGAMART", 568 "uni": "MTL-HQ-Node3-Slot2-Port1" 569 }, 570 "endpoint-2": 571 { 572 "id": "MTL-STL_1867-MEGAMART", 573 "uni": "MTL-STL-Node5-Slot4-Port3" 574 }, 575 "start-time": "2018-09-13T06:06:09Z", 576 "time-interval": 2419200, 577 "performance-metric": "One-way-Delay " 578 } 579 ] 580 }, 581 } 583 6. Security Considerations 585 The YANG module specified in this document defines a schema for data 586 that is designed to be accessed via network management protocols such 587 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 588 is the secure transport layer, and the mandatory-to-implement secure 589 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 590 is HTTPS, and the mandatory-to-implement secure transport is TLS 591 [RFC8446]. 593 The NETCONF access control model [RFC8341] provides the means to 594 restrict access for particular NETCONF or RESTCONF users to a 595 preconfigured subset of all available NETCONF or RESTCONF protocol 596 operations and content. 598 A number of configuration data nodes defined in this document are 599 writable/deletable (i.e., "config true") These data nodes may be 600 considered sensitive or vulnerable in some network environments. 602 These are the subtrees and data nodes and their sensitivity/ 603 vulnerability: 605 unis: 607 - id 609 Service: 611 - service-id 613 - endpoint-1 615 - endpoint-2 617 - start-time 619 - time-interval 621 - performance-metric 623 The security considerations spelled out in the YANG 1.1 specification 624 [RFC7950] apply for this document as well. 626 7. IANA Considerations 628 It is proposed that IANA should assign new URIs from the "IETF XML 629 Registry" [RFC3688] as follows: 631 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 632 Registrant Contact: The IESG 633 XML: N/A; the requested URI is an XML namespace. 635 This document registers following YANG modules in the YANG Module 636 Names registry [RFC7950]. 638 name: ietf-l1csm 639 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 640 prefix: l1csm 641 reference: RFC XXXX 643 8. Acknowledgements 645 The authors would like to thank Tom Petch for his helpful comments 646 and valuable contributions and Robert Wilton for his review that 647 improved the model significantly. 649 9. Contributors 651 Italo Busi 652 Huawei Technologies 653 Email: Italo.Busi@huawei.com 655 Giuseppe Fioccola 656 Huawei Technologies 657 Email: giuseppe.fioccola@huawei.com 659 Dhruv Dhody 660 Huawei Technologies 661 Email: dhruv.ietf@gmail.com 663 10. References 665 10.1. Normative References 667 [MEF63] Metro Ethernet Forum, "Subscriber Layer1 Service 668 Attributes Technical Specification", MEF 63, August 2018. 670 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 671 DOI 10.17487/RFC3688, January 2004, 672 . 674 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 675 and A. Bierman, Ed., "Network Configuration Protocol 676 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 677 . 679 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 680 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 681 . 683 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 684 RFC 6991, DOI 10.17487/RFC6991, July 2013, 685 . 687 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 688 RFC 7950, DOI 10.17487/RFC7950, August 2016, 689 . 691 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 692 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 693 . 695 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 696 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 697 . 699 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 700 Access Control Model", STD 91, RFC 8341, 701 DOI 10.17487/RFC8341, March 2018, 702 . 704 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 705 and R. Wilton, "Network Management Datastore Architecture 706 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 707 . 709 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 710 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 711 . 713 10.2. Informative References 715 [I-D.ietf-ccamp-layer1-types] 716 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 717 Types", draft-ietf-ccamp-layer1-types-06 (work in 718 progress), May 2020. 720 [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 721 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, 722 April 2007, . 724 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 725 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, 726 DOI 10.17487/RFC5253, July 2008, 727 . 729 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 730 Classification", RFC 8199, DOI 10.17487/RFC8199, July 731 2017, . 733 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 734 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 735 . 737 Authors' Addresses 739 Young Lee 740 Samsung 741 Samsung 742 Seoul 743 South Korea 745 Email: younglee.tx@gmail.com 747 KwangKoog Lee 748 Korea Telecom 749 South Korea 751 Email: kwangkoog.lee@kt.com 753 Haomian Zheng 754 Huawei Technologies 755 H1, Huawei Xiliu Beipo Village, Songshan Lake 756 Dongguan, Guangdong 523808 757 China 759 Email: zhenghaomian@huawei.com 761 Oscar Gonzalez de Dios 762 Telefonica 764 Email: oscar.gonzalezdedios@telefonica.com 765 Daniele Ceccarelli 766 Ericsson 768 Email: daniele.ceccarelli@ericsson.com