idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-16.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 313 has weird spacing: '...terface ide...' == Line 321 has weird spacing: '...-rw uni lea...' == Line 324 has weird spacing: '...-rw uni lea...' -- The document date (13 December 2021) is 862 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 274, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF63' Summary: 0 errors (**), 0 flaws (~~), 6 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: 16 June 2022 Korea Telecom 6 H. Zheng 7 Huawei Technologies 8 O. Gonzalez de Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 12 13 December 2021 14 A YANG Data Model for L1 Connectivity Service Model (L1CSM) 15 draft-ietf-ccamp-l1csm-yang-16 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 16 June 2022. 44 Copyright Notice 46 Copyright (c) 2021 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 63 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 64 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 7 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. L1CSM YANG Model (Tree Structure) . . . . . . . . . . . . . . 7 67 4. L1CSM YANG Code . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 71 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 9.2. Informative References . . . . . . . . . . . . . . . . . 18 75 Appendix A. JSON Example . . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 This document provides a YANG data model for L1VPN Connectivity 81 Service Model (L1CSM) which can be classified as Network Service YANG 82 module per [RFC8199]. The intent of this document is to provide a 83 transport service model exploiting YANG data model, which can be 84 utilized by a client network controller to initiate a service request 85 connectivity request as well as retrieving service states toward a 86 transport network controller communicating with the client controller 87 via a NETCONF [RFC8341] or a RESTCONF [RFC8040] interface. 89 [RFC4847] provides a framework and service level requirements for 90 Layer 1 Virtual Private Networks (L1VPNs). It classifies service 91 models as management-based service model, signaling-based service 92 model (Basic Mode) and signaling and routing service model (Enhanced 93 Mode). 95 In the management-based service model, customer management systems 96 and provider management systems communicate with each other. 97 Customer management systems access provider management systems to 98 request layer 1 connection setup/deletion between a pair of CEs. 99 Customer management systems may obtain additional information, such 100 as resource availability information and monitoring information, from 101 provider management systems. There is no control message exchange 102 between a CE and PE. 104 In the signaling-based service model (Basic Model), the CE-PE 105 interface's functional repertoire is limited to path setup signaling 106 only. In the Signaling and routing service model (Enhanced Mode), 107 the CE-PE interface provides the signaling capabilities as in the 108 Basic Mode, plus permits limited exchange of information between the 109 control planes of the provider and the customer to help such 110 functions as discovery of customer network routing information (i.e., 111 reachability or TE information in remote customer sites), or 112 parameters of the part of the provider's network dedicated to the 113 customer. 115 The primary focus of this document is to describe L1CS YANG model 116 required for the instantiation of point-to-point L1VPN service. A 117 L1VPN is a service offered by a core layer 1 network to provide layer 118 1 connectivity between two or more customer sites where the customer 119 has some control over the establishment and type of the connectivity. 121 The data model presented in Section 3 is in consistent with [MEF63]. 122 The data model includes configuration and state data according to the 123 new Network Management Datastore Architecture [RFC8342]. 125 1.1. Deployment Scenarios 127 Figure 1 depicts a deployment scenario of the L1VPN SDN control-based 128 service model for an external customer instantiating L1 point-to- 129 point connectivity to the provider. 131 +------------+ 132 | Customer | 133 | Service | 134 |Orchestrator| 135 +------------+ 136 | 137 .. .. .. .. ..|.. .. .. .. .. .. 138 : | : 139 : +--------------------+ : 140 : | | : 141 : | +----------+ | : 142 : | | Network | | : 143 : | | SDN | | : 144 : | |Controller| | : 145 : | |/NMS/EMS | | : 146 : | +----------+ | : 147 : | | : 148 : | | : 149 +----+ : +----+ +----+ +----+ : +----+ 150 | CE |----:---| PE |----| P |----| PE |---:---| CE | 151 +----+ : +----+ +----+ +----+ : +----+ 152 : | | : 153 : | | : 154 : +--------------------+ : 155 : | | : 156 : |<-Provider network->| : 158 Customer Customer 159 Interface Interface 161 Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: 162 External Customer 164 With this scenario, the customer service orchestrator interfaces with 165 the network SDN controller of the provider using Customer Service 166 Model as defined in [RFC8309]. 168 Figure 2 depicts another deployment scenario for internal customer 169 (e.g., higher-layer service management department(s)) interfacing the 170 layer 1 transport network department. With this scenario, a multi- 171 service backbone is characterized such that each service department 172 of a provider (e.g., L2/3 services) that receives the same provider's 173 L1VPN service provides a different kind of higher-layer service. The 174 customer receiving the L1VPN service (i.e., each service department) 175 can offer its own services, whose payloads can be any layer (e.g., 176 ATM, IP, TDM). The layer 1 transport network and each service 177 network belong to the same organization, but may be managed 178 separately. The Service SDN Controller is the control/management 179 entity owned by higher-layer service department (e.g., L2/3 VPN) 180 whereas the Network SDN Controller is the control/management entity 181 responsible for Layer 1 connectivity service. The CEs in Figure 2 182 are L2/3 devices that interface with L1 PE devices. 184 +----------+ 185 | Service | 186 | SDN | 187 |Controller| 188 |/EMS/NMS | 189 | for L2/3 | 190 +----------+ 191 | 192 | 193 | 194 +--------------------+ 195 | | 196 | +----------+ | 197 | | Network | | 198 | | SDN | | 199 | |Controller| | 200 | |/EMS/NMS | | 201 | | for L1VPN| | 202 | +----------+ | 203 | | 204 | | 205 +----+ +----+ +----+ +----+ +----+ 206 | CE |--------| PE |----| P |----| PE |------| CE | 207 +----+ +----+ +----+ +----+ +----+ 208 | | | | 209 | | | | 210 | +--------------------+ | 211 | | | | 212 | |<------------------>| | 213 | Provider Network | 214 | For Layer 1 | 215 |<------------------------------------------>| 216 Provider Network for L2/3 218 Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: 219 Internal Customer 221 The benefit is that the same layer 1 transport network resources are 222 shared by multiple services. A large capacity backbone network (data 223 plane) can be built economically by having the resources shared by 224 multiple services usually with flexibility to modify topologies, 225 while separating the control functions for each service department. 226 Thus, each customer can select a specific set of features that are 227 needed to provide their own service [RFC4847]. 229 1.2. Terminology 231 Refer to [RFC4847] and [RFC5253] for the key terms used in this 232 document. 234 The following terms are defined in [RFC7950] and are not redefined 235 here: 237 * client 239 * server 241 * augment 243 * data model 245 * data node 247 The following terms are defined in [RFC6241] and are not redefined 248 here: 250 * configuration data 252 * state data 254 The terminology for describing YANG data models is found in 255 [RFC7950]. 257 1.3. Tree Diagram 259 A simplified graphical representation of the data model is used in 260 Section 3 of this this document. The meaning of the symbols in these 261 diagrams is defined in [RFC8340]. 263 1.4. Prefixes in Data Node Names 265 In this document, names of data nodes and other data model objects 266 are prefixed using the standard prefix associated with the 267 corresponding YANG imported modules. The module ietf-layer1-types 268 specified in [I-D.ietf-ccamp-layer1-types] and ietf-yang-types 269 specified in [RFC6991] are imported in this module. 271 +-------------+-------------------+------------------------------+ 272 | Prefix | YANG module | Reference | 273 +-------------+-------------------+------------------------------+ 274 | l1csm | ietf-l1csm | [RFC XXXX] | 275 | l1-types | ietf-layer1-types |[I-D.ietf-ccamp-layer1-types] | 276 | yang | ietf-yang-types | [RFC6991] | 277 +-------------+-------------------+------------------------------+ 279 Note: The RFC Editor will replace XXXX with the number assigned to 280 the RFC once this document becomes an RFC. 282 2. Definitions 284 L1VC Layer 1 Virtual Connection 286 SLS Service Level Specification 288 UNI User Network Interface 290 PE Provider Edge 292 CE Customer Edge 294 EP End Point 296 P Protocol 298 C Coding 300 O Optical Interface 302 3. L1CSM YANG Model (Tree Structure) 303 module: ietf-l1csm 304 +--rw l1-connectivity 305 +--rw access 306 | +--rw unis 307 | +--rw uni* [id] 308 | +--rw id string 309 | +--rw (uni-access-type)? 310 | +--:(mef) 311 | | +--rw protocol identityref 312 | | +--rw coding identityref 313 | | +--rw optical-interface identityref 314 | +--:(itu) 315 | +--rw client-signal identityref 316 +--rw services 317 +--rw service* [service-id] 318 +--rw service-id string 319 +--rw endpoint-1 320 | +--rw id string 321 | +--rw uni leafref 322 +--rw endpoint-2 323 | +--rw id string 324 | +--rw uni leafref 325 +--rw start-time? yang:date-and-time 326 +--rw time-interval? uint32 327 +--rw performance-metric* identityref 329 4. L1CSM YANG Code 331 332 file "ietf-l1csm@2021-12-13.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 reference 341 "RFC6991: Common YANG Data Types"; 342 } 344 import ietf-layer1-types { 345 prefix "l1-types"; 346 reference 347 "RFCYYYY: A YANG Data Model for Layer 1 Types"; 348 } 349 organization 350 "Internet Engineering Task Force (IETF) CCAMP WG"; 352 contact 353 "WG Web: 354 WG List: 356 Editor: Young Lee 357 359 Editor: KwangKoog Lee 360 362 Editor: Haomian Zheng 363 365 Editor: Oscar Gonzalez de Dios 366 368 Editor: Daniele Ceccarelli 369 "; 371 description 372 "This module describes L1 connectivity service based on MEF 63: 373 Subscriber Layer 1 Service Attribute Technical Specification. 374 Refer to MEF 63 for all terms and the original references 375 used in the module. 377 Copyright (c) 2021 IETF Trust and the persons identified as 378 authors of the code. All rights reserved. 379 Redistribution and use in source and binary forms, with or 380 without modification, is permitted pursuant to, and subject 381 to the license terms contained in, the Simplified BSD 382 License set forth in Section 4.c of the IETF Trust's Legal 383 Provisions Relating to IETF Documents 384 (http://trustee.ietf.org/license-info). 386 This version of this YANG module is part of RFC XXXX; see 387 the RFC itself for full legal notices."; 389 revision "2021-12-13" { 390 description 391 "Initial revision."; 392 reference 393 "RFC XXXX: A Yang Data Model for L1 Connectivity Service Model 394 (L1CSM)"; 395 // Note: The RFC Editor will replace XXXX/YYYY with the number 396 // assigned to the RFC once this draft becomes an RFC. 398 } 400 /* 401 * Identities 402 */ 404 identity service-performance-metric { 405 description 406 "Base identity of service-specific performance metric"; 407 reference 408 "MEF63: Subscriber Layer 1 Service Attributes"; 409 } 411 identity one-way-delay { 412 base service-performance-metric; 413 description 414 "The time elapsed from the reception of the first bit of the 415 ingress until the reception of the first bit of the egress."; 416 reference 417 "MEF63: Subscriber Layer 1 Service Attributes"; 418 } 420 identity one-way-errored-second { 421 base service-performance-metric; 422 description 423 "One second in the available time with at least one errored 424 block, but not a severely errored second."; 425 reference 426 "MEF63: Subscriber Layer 1 Service Attributes"; 427 } 429 identity one-way-severely-errored-second { 430 base service-performance-metric; 431 description 432 "One second which contains more than 15 percent errored info, 433 or contains a defect (e.g., loss of signal)."; 434 reference 435 "MEF63: Subscriber Layer 1 Service Attributes"; 436 } 438 identity one-way-unavailable-second { 439 base service-performance-metric; 440 description 441 "One second during unavailable time."; 442 reference 443 "MEF63: Subscriber Layer 1 Service Attributes"; 444 } 445 identity one-way-availability { 446 base service-performance-metric; 447 description 448 "The percentage of available time over a given interval."; 449 reference 450 "MEF63: Subscriber Layer 1 Service Attributes"; 451 } 453 /* 454 * Groupings 455 */ 457 grouping protocol-coding-optical-interface { 458 description 459 "The 3-tuple where p:protocol type; 460 c:coding function; o:optical interface function. 462 Valid combinations are defined in Tables 4, 5, 6 and 7 463 of MEF 63."; 464 reference 465 "MEF63: Subscriber Layer 1 Service Attributes"; 467 leaf protocol { 468 type identityref { 469 base l1-types:protocol; 470 } 471 mandatory true; 472 description 473 "The protocol being used at the UNI."; 474 } 475 leaf coding { 476 type identityref { 477 base l1-types:coding-func; 478 } 479 mandatory true; 480 description 481 "The coding function being used at the UNI."; 482 } 483 leaf optical-interface { 484 type identityref { 485 base l1-types:optical-interface-func; 486 } 487 mandatory true; 488 description 489 "The optical interface function being used at the UNI."; 490 } 491 } 492 grouping subscriber-l1vc-sls-service-attributes { 493 description 494 "A set of service attributes on L1VC Service Level 495 Specification (SLS) that are agreed between the service 496 provider and the subscriber. "; 497 reference 498 "MEF63: Subscriber Layer 1 Service Attributes"; 500 leaf start-time { 501 type yang:date-and-time; 502 description 503 "A time that represent the date and time for the start of 504 the SLS"; 505 } 506 leaf time-interval { 507 type uint32; 508 units seconds; 509 description 510 "A time interval (e.g., 2,419,200 seconds which is 28 days) 511 that is used in conjunction with time-start to specify a 512 contiguous sequence of time intervals T for determining 513 when performance objectives are met."; 514 } 515 leaf-list performance-metric { 516 type identityref { 517 base service-performance-metric; 518 } 519 description 520 "List of service performance metric."; 521 } 522 } 524 grouping subscriber-l1vc-endpoint-attributes { 525 description 526 "Subscriber layer 1 connection endpoint attributes"; 527 reference 528 "MEF63: Subscriber Layer 1 Service Attributes"; 530 container endpoint-1 { 531 description 532 "One end of UNI id's - string and id"; 533 leaf id { 534 type string; 535 mandatory true; 536 description 537 "Subscriber end point ID of one end"; 538 } 539 leaf uni { 540 type leafref { 541 path "/l1-connectivity/access/unis/uni/id"; 542 } 543 mandatory true; 544 description 545 "This is one end of subscriber L1VC end point ID value = 546 UNI-1"; 547 } 548 } 549 container endpoint-2 { 550 description 551 "One end of UNI id's - string and id"; 552 leaf id { 553 type string; 554 must '. != ../../endpoint-1/id' { 555 error-message 556 "The two end points must not be equal to each other. "; 557 } 558 mandatory true; 559 description 560 "Subscriber end point ID of the other end"; 561 } 562 leaf uni { 563 type leafref { 564 path "/l1-connectivity/access/unis/uni/id"; 565 } 566 mandatory true; 567 description 568 "This is one other end of subscriber L1VC end point 569 ID value = UNI-2"; 570 } 571 } 572 } 574 /* 575 * Data nodes 576 */ 578 container l1-connectivity { 579 description 580 "Serves as a top-level container for a list of layer 1 581 connection services (l1cs)"; 583 container access { 584 description 585 "UNI configurations for access networks"; 587 container unis { 588 description 589 "The list of UNI's to be configured"; 591 list uni { 592 key "id"; 593 description 594 "UNI identifier"; 595 leaf id { 596 type string; 597 description "The UNI id of UNI Service Attributes"; 598 } 599 choice uni-access-type { 600 description 601 "The UNI access type can be specified either by the 602 protocol, coding function and optical interface 603 function, defined in MEF, or by the client-signal, 604 defined in ITU-T."; 605 case mef { 606 uses protocol-coding-optical-interface; 607 } 608 case itu { 609 leaf client-signal { 610 type identityref { 611 base l1-types:client-signal; 612 } 613 mandatory true; 614 description 615 "The client signal being used at the UNI"; 616 } 617 } 618 } 619 } 620 } 621 } 623 container services { 624 description 625 "L1VC services"; 626 list service { 627 key "service-id"; 628 description 629 "A unique identifier of a subscriber L1VC service"; 631 leaf service-id { 632 type string; 633 description 634 "A unique service identifier for subscriber L1VC."; 635 } 636 uses subscriber-l1vc-endpoint-attributes; 637 uses subscriber-l1vc-sls-service-attributes; 639 } //end of service list 640 } //end of service container 641 } //service top container 642 } 643 645 5. Security Considerations 647 The YANG module specified in this document defines a schema for data 648 that is designed to be accessed via network management protocols such 649 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 650 is the secure transport layer, and the mandatory-to-implement secure 651 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 652 is HTTPS, and the mandatory-to-implement secure transport is TLS 653 [RFC8446]. 655 The NETCONF access control model [RFC8341] provides the means to 656 restrict access for particular NETCONF or RESTCONF users to a 657 preconfigured subset of all available NETCONF or RESTCONF protocol 658 operations and content. 660 A number of configuration data nodes defined in this document are 661 writable/deletable (i.e., "config true") These data nodes may be 662 considered sensitive or vulnerable in some network environments. 664 These are the subtrees and data nodes and their sensitivity/ 665 vulnerability: 667 unis: 669 - id 671 Service: 673 - service-id 675 - endpoint-1 677 - endpoint-2 679 - start-time 681 - time-interval 683 - performance-metric 684 The security considerations spelled out in the YANG 1.1 specification 685 [RFC7950] apply for this document as well. 687 6. IANA Considerations 689 It is proposed that IANA should assign new URIs from the "IETF XML 690 Registry" [RFC3688] as follows: 692 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 693 Registrant Contact: The IESG 694 XML: N/A; the requested URI is an XML namespace. 696 This document registers following YANG modules in the YANG Module 697 Names registry [RFC7950]. 699 name: ietf-l1csm 700 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 701 prefix: l1csm 702 reference: RFC XXXX 704 7. Acknowledgements 706 The authors would like to thank Tom Petch for his helpful comments 707 and valuable contributions and Robert Wilton for his review that 708 improved the model significantly. 710 8. Contributors 712 Italo Busi Huawei Technologies Email: Italo.Busi@huawei.com 714 Giuseppe Fioccola Huawei Technologies Email: 715 giuseppe.fioccola@huawei.com 717 Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com 719 9. References 721 9.1. Normative References 723 [I-D.ietf-ccamp-layer1-types] 724 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 725 Types", Work in Progress, Internet-Draft, draft-ietf- 726 ccamp-layer1-types-11, 7 September 2021, 727 . 730 [MEF63] Metro Ethernet Forum, "Subscriber Layer1 Service 731 Attributes Technical Specification", MEF 63, August 2018. 733 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 734 DOI 10.17487/RFC3688, January 2004, 735 . 737 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 738 and A. Bierman, Ed., "Network Configuration Protocol 739 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 740 . 742 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 743 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 744 . 746 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 747 RFC 6991, DOI 10.17487/RFC6991, July 2013, 748 . 750 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 751 RFC 7950, DOI 10.17487/RFC7950, August 2016, 752 . 754 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 755 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 756 . 758 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 759 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 760 . 762 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 763 Access Control Model", STD 91, RFC 8341, 764 DOI 10.17487/RFC8341, March 2018, 765 . 767 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 768 and R. Wilton, "Network Management Datastore Architecture 769 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 770 . 772 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 773 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 774 . 776 9.2. Informative References 778 [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 779 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, 780 April 2007, . 782 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 783 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, 784 DOI 10.17487/RFC5253, July 2008, 785 . 787 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 788 Classification", RFC 8199, DOI 10.17487/RFC8199, July 789 2017, . 791 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 792 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 793 . 795 Appendix A. JSON Example 797 This section provides a JSON example of the YANG module described in 798 Section 4. This example configures one L1VC service with two UNIs 799 that describe the UNI endpoints. The service is configured with the 800 starting time to be 06:06:09 on 2018-09-13 for the service life time 801 of 2419200 seconds (which is corresponds to 28 days). In addition, 802 the service is configured to collect one performance metric, One-way- 803 Delay. 805 { 806 "l1-connectivity": { 807 "access": { 808 "unis": { 809 "uni": [ 810 { 811 "id": "MTL-HQ-Node3-Slot2-Port1", 812 "protocol": "ETH-10GigE_LAN ", 813 "coding": "ETH-10GR-PCS-49 ", 814 "optical_interface": "LR-PMD-clause-52 " 815 }, 816 { 817 "id": "MTL-STL-Node5-Slot4-Port3", 818 "protocol": "ETH-10GigE_LAN ", 819 "coding": "ETH-10GR-PCS-49 ", 820 "optical_interface": "ER-PMD-clause-52 " 821 } 822 ] 823 }, 824 }, 825 "services": { 826 "service": [ 827 { 828 "service-id": "Sub-L1VC-1867-LT-MEGAMART", 829 "endpoint-1": 830 { 831 "id": "MTL-HQ_1867-MEGAMART", 832 "uni": "MTL-HQ-Node3-Slot2-Port1" 833 }, 834 "endpoint-2": 835 { 836 "id": "MTL-STL_1867-MEGAMART", 837 "uni": "MTL-STL-Node5-Slot4-Port3" 838 }, 839 "start-time": "2018-09-13T06:06:09Z", 840 "time-interval": 2419200, 841 "performance-metric": "One-way-Delay " 842 } 843 ] 844 }, 845 } 847 Authors' Addresses 848 Young Lee 849 Samsung 850 Samsung 851 Seoul 852 South Korea 854 Email: younglee.tx@gmail.com 856 KwangKoog Lee 857 Korea Telecom 858 South Korea 860 Email: kwangkoog.lee@kt.com 862 Haomian Zheng 863 Huawei Technologies 864 H1, Huawei Xiliu Beipo Village, Songshan Lake 865 Dongguan 866 Guangdong, 523808 867 China 869 Email: zhenghaomian@huawei.com 871 Oscar Gonzalez de Dios 872 Telefonica 874 Email: oscar.gonzalezdedios@telefonica.com 876 Daniele Ceccarelli 877 Ericsson 879 Email: daniele.ceccarelli@ericsson.com