idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-13.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 == Line 314 has weird spacing: '...terface ide...' -- The document date (November 2, 2020) is 1268 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-07 Summary: 0 errors (**), 0 flaws (~~), 4 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: May 6, 2021 Korea Telecom 6 H. Zheng 7 Huawei Technologies 8 O. Gonzalez de Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 12 November 2, 2020 14 A YANG Data Model for L1 Connectivity Service Model (L1CSM) 15 draft-ietf-ccamp-l1csm-yang-13 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 May 6, 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 73 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 76 10.2. Informative References . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 (uni-access-type)? 311 | +--:(mef) 312 | | +--rw protocol identityref 313 | | +--rw coding identityref 314 | | +--rw optical-interface identityref 315 | +--:(itu) 316 | +--rw client-signal identityref 317 +--rw services 318 +--rw service* [service-id] 319 +--rw service-id string 320 +--rw endpoint-1 321 | +--rw id string 322 | +--rw uni -> /l1-connectivity/access/unis/uni/id 323 +--rw endpoint-2 324 | +--rw id string 325 | +--rw uni -> /l1-connectivity/access/unis/uni/id 326 +--rw start-time? yang:date-and-time 327 +--rw time-interval? int32 328 +--rw performance-metric* identityref 330 4. L1CSM YANG Code 332 file "ietf-l1csm@2020-10-27.yang" 333 module ietf-l1csm { 334 yang-version 1.1; 335 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 336 prefix "l1csm"; 338 import ietf-yang-types { 339 prefix "yang"; 340 } 342 import ietf-layer1-types { 343 prefix "l1-types"; 344 } 346 organization 347 "Internet Engineering Task Force (IETF) CCAMP WG"; 349 contact 351 "Editor: Y. Lee (younglee.tx@gmail.com) 352 Editor: K. Lee (kwangkoog.lee@kt.com) 353 Editor: H. Zheng (zhenghaomian@huawei.com) 354 Editor: D. Dhody (dhruv.ietf@gmail.com) 355 Editor: O. G. de-Dios (oscar.gonzalezdedios@telefonica.com) 356 Editor: D. Ceccarelli (daniele.ceccarelli@ericsson.com)"; 358 description 359 "This module describes L1 connectivity service based on MEF 63: 360 Subscriber Layer 1 Service Attribute Technical Specification. 361 Refer to MEF 63 for all terms and the original references 362 used in the module. 364 Copyright (c) 2020 IETF Trust and the persons identified as 365 authors of the code. All rights reserved. 366 Redistribution and use in source and binary forms, with or 367 without modification, is permitted pursuant to, and subject 368 to the license terms contained in, the Simplified BSD 369 License set forth in Section 4.c of the IETF Trust's Legal 370 Provisions Relating to IETF Documents 371 (http://trustee.ietf.org/license-info). 373 This version of this YANG module is part of RFC XXXX; see 374 the RFC itself for full legal notices."; 376 revision "2020-10-27" { 377 description "Initial revision."; 378 reference "RFC XXXX: A Yang Data Model for L1 Connectivity 379 Service Model (L1CSM)"; 380 // Note: The RFC Editor will replace XXXX with the number 381 // assigned to the RFC once this draft becomes an RFC. 382 } 384 /* 385 * Identities 386 */ 388 identity service-performance-metric { 389 description 390 "Base identity of service-specific performance metric"; 391 reference "MEF63: Subscriber Layer 1 Service Attributes"; 392 } 394 identity one-way-delay { 395 base "service-performance-metric"; 396 description "one way delay."; 397 reference "MEF63: Subscriber Layer 1 Service Attributes"; 398 } 400 identity one-way-errored-second { 401 base "service-performance-metric"; 402 description "one way errored second"; 403 reference "MEF63: Subscriber Layer 1 Service Attributes"; 404 } 406 identity one-way-severely-errored-second { 407 base "service-performance-metric"; 408 description "one way severely errored second"; 409 reference "MEF63: Subscriber Layer 1 Service Attributes"; 410 } 412 identity one-way-unavailable-second { 413 base "service-performance-metric"; 414 description "one way unavailable second"; 415 reference "MEF63: Subscriber Layer 1 Service Attributes"; 416 } 418 identity one-way-availability { 419 base "service-performance-metric"; 420 description "one way availability"; 421 reference "MEF63: Subscriber Layer 1 Service Attributes"; 422 } 424 /* 425 * Groupings 426 */ 428 grouping protocol-coding-optical-interface { 429 description 430 "The 3-tuple where p:protocol type; 431 c:coding function; o:optical interface function. 433 Valid combinations are defined in Tables 4, 5, 6 and 7 434 of MEF 63."; 435 reference "MEF 63"; 437 leaf protocol { 438 type identityref { 439 base "l1-types:protocol"; 440 } 441 mandatory true; 442 description "The protocol being used at the UNI."; 443 } 444 leaf coding { 445 type identityref { 446 base "l1-types:coding-func"; 447 } 448 mandatory true; 449 description "The coding function being used at the UNI."; 450 } 451 leaf optical-interface { 452 type identityref { 453 base "l1-types:optical-interface-func"; 454 } 455 mandatory true; 456 description 457 "The optical interface function being used at the UNI."; 458 } 459 } 461 grouping subscriber-l1vc-sls-service-attribute { 462 description 463 "The value of the Subscriber L1VC SLS (Service Level 464 Specification) Service Attribute"; 465 reference "MEF 63"; 467 leaf start-time { 468 type yang:date-and-time; 469 description "a time that represent the date and time 470 for the start of the SLS"; 471 } 472 leaf time-interval { 473 type int32; 474 units seconds; 475 description 476 "a time interval (e.g., 2,419,200 seconds which is 28 days) 477 that is used in conjunction wuth time-start to specify a 478 contiguous sequence of time intervals T for determining 479 when performance objectives are met."; 480 } 481 leaf-list performance-metric { 482 type identityref { 483 base "service-performance-metric"; 484 } 485 description "list of service performance metric."; 486 } 487 } 489 grouping subscriber-l1vc-endpoint-attributes { 490 description 491 "subscriber layer 1 connection endpoint attributes"; 492 reference "MEF 63"; 493 container endpoint-1 { 494 description "One end of UNI id's - string and id"; 495 leaf id { 496 type string; 497 mandatory true; 498 description "subscriber end point ID of one end"; 499 } 500 leaf uni { 501 type leafref { 502 path "/l1-connectivity/access/unis/uni/id"; 503 } 504 mandatory true; 505 description "this is one end of subscriber L1VC end point 506 ID value = UNI-1"; 507 } 508 } 509 container endpoint-2 { 510 description "One end of UNI id's - string and id"; 511 leaf id { 512 type string; 513 mandatory true; 514 description "subscriber end point ID of the other end"; 515 } 516 leaf uni { 517 type leafref { 518 path "/l1-connectivity/access/unis/uni/id"; 519 } 520 mandatory true; 521 description 522 "this is one other end of subscriber L1VC end point 523 ID value = UNI-2"; 524 } 525 } 526 } 528 /* 529 * Data nodes 530 */ 532 container l1-connectivity { 533 description 534 "serves as a top-level container for a list of layer 1 535 connection services (l1cs)"; 537 container access { 538 description "UNI configurations for access networks"; 540 container unis { 541 description "the list of UNI's to be configured"; 543 list uni { 544 key "id"; 545 description "UNI identifier"; 546 leaf id { 547 type string; 548 description "the UNI id of UNI Service Attributes"; 549 } 550 choice uni-access-type { 551 description 552 "The UNI access type can be specified either by the 553 protocol, coding function and optical interface 554 function, defined in MEF, or by the client-signal, 555 defined in ITU-T."; 556 case mef { 557 uses protocol-coding-optical-interface; 558 } 559 case itu { 560 leaf client-signal { 561 type identityref { 562 base "l1-types:client-signal"; 563 } 564 mandatory true; 565 description 566 "The client signal being used at the UNI"; 567 } 568 } 569 } 570 } 571 } 572 } 574 container services { 575 description "L1VC services"; 576 list service { 577 key "service-id"; 578 description 579 "an unique identifier of a subscriber L1VC service"; 581 leaf service-id { 582 type string; 583 mandatory true; 584 description "a unique service identifier for 585 subscriber L1VC."; 586 } 587 uses subscriber-l1vc-endpoint-attributes; 588 uses subscriber-l1vc-sls-service-attribute; 590 } //end of service list 591 } //end of service container 592 } //service top container 593 } 594 596 5. JSON Example 598 This section provides a JSON example of the YANG module described in 599 Section 4. This example configures one L1VC service with two UNIs 600 that describe the UNI endpoints. The service is configured with the 601 starting time to be 06:06:09 on 2018-09-13 for the service life time 602 of 2419200 seconds (which is corresponds to 28 days). In addition, 603 the service is configured to collect one performance metric, One-way- 604 Delay. 606 { 607 "l1-connectivity": { 608 "access": { 609 "unis": { 610 "uni": [ 611 { 612 "id": "MTL-HQ-Node3-Slot2-Port1", 613 "protocol": "ETH-10GigE_LAN ", 614 "coding": "ETH-10GR-PCS-49 ", 615 "optical_interface": "LR-PMD-clause-52 " 616 }, 617 { 618 "id": "MTL-STL-Node5-Slot4-Port3", 619 "protocol": "ETH-10GigE_LAN ", 620 "coding": "ETH-10GR-PCS-49 ", 621 "optical_interface": "ER-PMD-clause-52 " 622 } 623 ] 624 }, 625 }, 626 "services": { 627 "service": [ 628 { 629 "service-id": "Sub-L1VC-1867-LT-MEGAMART", 630 "endpoint-1": 631 { 632 "id": "MTL-HQ_1867-MEGAMART", 633 "uni": "MTL-HQ-Node3-Slot2-Port1" 634 }, 635 "endpoint-2": 636 { 637 "id": "MTL-STL_1867-MEGAMART", 638 "uni": "MTL-STL-Node5-Slot4-Port3" 639 }, 640 "start-time": "2018-09-13T06:06:09Z", 641 "time-interval": 2419200, 642 "performance-metric": "One-way-Delay " 643 } 644 ] 645 }, 646 } 648 6. Security Considerations 650 The YANG module specified in this document defines a schema for data 651 that is designed to be accessed via network management protocols such 652 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 653 is the secure transport layer, and the mandatory-to-implement secure 654 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 655 is HTTPS, and the mandatory-to-implement secure transport is TLS 656 [RFC8446]. 658 The NETCONF access control model [RFC8341] provides the means to 659 restrict access for particular NETCONF or RESTCONF users to a 660 preconfigured subset of all available NETCONF or RESTCONF protocol 661 operations and content. 663 A number of configuration data nodes defined in this document are 664 writable/deletable (i.e., "config true") These data nodes may be 665 considered sensitive or vulnerable in some network environments. 667 These are the subtrees and data nodes and their sensitivity/ 668 vulnerability: 670 unis: 672 - id 674 Service: 676 - service-id 678 - endpoint-1 680 - endpoint-2 682 - start-time 684 - time-interval 686 - performance-metric 688 The security considerations spelled out in the YANG 1.1 specification 689 [RFC7950] apply for this document as well. 691 7. IANA Considerations 693 It is proposed that IANA should assign new URIs from the "IETF XML 694 Registry" [RFC3688] as follows: 696 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 697 Registrant Contact: The IESG 698 XML: N/A; the requested URI is an XML namespace. 700 This document registers following YANG modules in the YANG Module 701 Names registry [RFC7950]. 703 name: ietf-l1csm 704 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 705 prefix: l1csm 706 reference: RFC XXXX 708 8. Acknowledgements 710 The authors would like to thank Tom Petch for his helpful comments 711 and valuable contributions and Robert Wilton for his review that 712 improved the model significantly. 714 9. Contributors 716 Italo Busi 717 Huawei Technologies 718 Email: Italo.Busi@huawei.com 720 Giuseppe Fioccola 721 Huawei Technologies 722 Email: giuseppe.fioccola@huawei.com 724 Dhruv Dhody 725 Huawei Technologies 726 Email: dhruv.ietf@gmail.com 728 10. References 730 10.1. Normative References 732 [MEF63] Metro Ethernet Forum, "Subscriber Layer1 Service 733 Attributes Technical Specification", MEF 63, August 2018. 735 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 736 DOI 10.17487/RFC3688, January 2004, 737 . 739 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 740 and A. Bierman, Ed., "Network Configuration Protocol 741 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 742 . 744 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 745 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 746 . 748 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 749 RFC 6991, DOI 10.17487/RFC6991, July 2013, 750 . 752 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 753 RFC 7950, DOI 10.17487/RFC7950, August 2016, 754 . 756 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 757 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 758 . 760 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 761 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 762 . 764 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 765 Access Control Model", STD 91, RFC 8341, 766 DOI 10.17487/RFC8341, March 2018, 767 . 769 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 770 and R. Wilton, "Network Management Datastore Architecture 771 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 772 . 774 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 775 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 776 . 778 10.2. Informative References 780 [I-D.ietf-ccamp-layer1-types] 781 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 782 Types", draft-ietf-ccamp-layer1-types-07 (work in 783 progress), September 2020. 785 [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 786 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, 787 April 2007, . 789 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 790 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, 791 DOI 10.17487/RFC5253, July 2008, 792 . 794 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 795 Classification", RFC 8199, DOI 10.17487/RFC8199, July 796 2017, . 798 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 799 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 800 . 802 Authors' Addresses 804 Young Lee 805 Samsung 806 Samsung 807 Seoul 808 South Korea 810 Email: younglee.tx@gmail.com 812 KwangKoog Lee 813 Korea Telecom 814 South Korea 816 Email: kwangkoog.lee@kt.com 818 Haomian Zheng 819 Huawei Technologies 820 H1, Huawei Xiliu Beipo Village, Songshan Lake 821 Dongguan, Guangdong 523808 822 China 824 Email: zhenghaomian@huawei.com 826 Oscar Gonzalez de Dios 827 Telefonica 829 Email: oscar.gonzalezdedios@telefonica.com 830 Daniele Ceccarelli 831 Ericsson 833 Email: daniele.ceccarelli@ericsson.com