idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-14.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 (February 19, 2021) is 1162 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 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF63' 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: August 23, 2021 Korea Telecom 6 H. Zheng 7 Huawei Technologies 8 O. Gonzalez de Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 12 February 19, 2021 14 A YANG Data Model for L1 Connectivity Service Model (L1CSM) 15 draft-ietf-ccamp-l1csm-yang-14 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 August 23, 2021. 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 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. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 75 9.2. Informative References . . . . . . . . . . . . . . . . . 18 76 Appendix A. JSON Example . . . . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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@2021-02-19.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: Haomian Zheng 360 362 Editor: Dhruv Dhody 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-02-19" { 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 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 "One way delay."; 415 reference 416 "MEF63: Subscriber Layer 1 Service Attributes"; 417 } 419 identity one-way-errored-second { 420 base service-performance-metric; 421 description 422 "One way errored second"; 423 reference 424 "MEF63: Subscriber Layer 1 Service Attributes"; 425 } 427 identity one-way-severely-errored-second { 428 base service-performance-metric; 429 description 430 "One way severely errored second"; 431 reference 432 "MEF63: Subscriber Layer 1 Service Attributes"; 433 } 435 identity one-way-unavailable-second { 436 base service-performance-metric; 437 description 438 "One way unavailable second"; 439 reference 440 "MEF63: Subscriber Layer 1 Service Attributes"; 441 } 443 identity one-way-availability { 444 base service-performance-metric; 445 description 446 "One way availability"; 447 reference 448 "MEF63: Subscriber Layer 1 Service Attributes"; 449 } 451 /* 452 * Groupings 453 */ 455 grouping protocol-coding-optical-interface { 456 description 457 "The 3-tuple where p:protocol type; 458 c:coding function; o:optical interface function. 460 Valid combinations are defined in Tables 4, 5, 6 and 7 461 of MEF 63."; 462 reference 463 "MEF63: Subscriber Layer 1 Service Attributes"; 465 leaf protocol { 466 type identityref { 467 base l1-types:protocol; 468 } 469 mandatory true; 470 description 471 "The protocol being used at the UNI."; 472 } 473 leaf coding { 474 type identityref { 475 base l1-types:coding-func; 476 } 477 mandatory true; 478 description 479 "The coding function being used at the UNI."; 480 } 481 leaf optical-interface { 482 type identityref { 483 base l1-types:optical-interface-func; 484 } 485 mandatory true; 486 description 487 "The optical interface function being used at the UNI."; 488 } 489 } 491 grouping subscriber-l1vc-sls-service-attributes { 492 description 493 "The value of the Subscriber L1VC SLS (Service Level 494 Specification) Service Attribute"; 495 reference 496 "MEF63: Subscriber Layer 1 Service Attributes"; 498 leaf start-time { 499 type yang:date-and-time; 500 description 501 "A time that represent the date and time for the start of 502 the SLS"; 503 } 504 leaf time-interval { 505 type int32; 506 units seconds; 507 description 508 "A time interval (e.g., 2,419,200 seconds which is 28 days) 509 that is used in conjunction with time-start to specify a 510 contiguous sequence of time intervals T for determining 511 when performance objectives are met."; 512 } 513 leaf-list performance-metric { 514 type identityref { 515 base service-performance-metric; 516 } 517 description 518 "List of service performance metric."; 519 } 520 } 522 grouping subscriber-l1vc-endpoint-attributes { 523 description 524 "Subscriber layer 1 connection endpoint attributes"; 525 reference 526 "MEF63: Subscriber Layer 1 Service Attributes"; 528 container endpoint-1 { 529 description 530 "One end of UNI id's - string and id"; 531 leaf id { 532 type string; 533 mandatory true; 534 description 535 "Subscriber end point ID of one end"; 536 } 537 leaf uni { 538 type leafref { 539 path "/l1-connectivity/access/unis/uni/id"; 540 } 541 mandatory true; 542 description 543 "This is one end of subscriber L1VC end point ID value = 544 UNI-1"; 545 } 546 } 547 container endpoint-2 { 548 description 549 "One end of UNI id's - string and id"; 550 leaf id { 551 type string; 552 must '. != ../../endpoint-1/id' { 553 error-message 554 "The two end points must not be equal to each other. "; 555 } 556 mandatory true; 557 description 558 "Subscriber end point ID of the other end"; 559 } 560 leaf uni { 561 type leafref { 562 path "/l1-connectivity/access/unis/uni/id"; 563 } 564 mandatory true; 565 description 566 "This is one other end of subscriber L1VC end point 567 ID value = UNI-2"; 568 } 569 } 570 } 572 /* 573 * Data nodes 574 */ 576 container l1-connectivity { 577 description 578 "Serves as a top-level container for a list of layer 1 579 connection services (l1cs)"; 581 container access { 582 description 583 "UNI configurations for access networks"; 585 container unis { 586 description 587 "The list of UNI's to be configured"; 589 list uni { 590 key "id"; 591 description 592 "UNI identifier"; 593 leaf id { 594 type string; 595 description "The UNI id of UNI Service Attributes"; 596 } 597 choice uni-access-type { 598 description 599 "The UNI access type can be specified either by the 600 protocol, coding function and optical interface 601 function, defined in MEF, or by the client-signal, 602 defined in ITU-T."; 603 case mef { 604 uses protocol-coding-optical-interface; 605 } 606 case itu { 607 leaf client-signal { 608 type identityref { 609 base l1-types:client-signal; 610 } 611 mandatory true; 612 description 613 "The client signal being used at the UNI"; 614 } 615 } 616 } 617 } 618 } 619 } 621 container services { 622 description 623 "L1VC services"; 624 list service { 625 key "service-id"; 626 description 627 "A unique identifier of a subscriber L1VC service"; 629 leaf service-id { 630 type string; 631 mandatory true; 632 description 633 "A unique service identifier for subscriber L1VC."; 634 } 635 uses subscriber-l1vc-endpoint-attributes; 636 uses subscriber-l1vc-sls-service-attributes; 638 } //end of service list 639 } //end of service container 640 } //service top container 641 } 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 713 Huawei Technologies 714 Email: Italo.Busi@huawei.com 716 Giuseppe Fioccola 717 Huawei Technologies 718 Email: giuseppe.fioccola@huawei.com 720 Dhruv Dhody 721 Huawei Technologies 722 Email: dhruv.ietf@gmail.com 724 9. References 726 9.1. Normative References 728 [I-D.ietf-ccamp-layer1-types] 729 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 730 Types", draft-ietf-ccamp-layer1-types-08 (work in 731 progress), November 2020. 733 [MEF63] Metro Ethernet Forum, "Subscriber Layer1 Service 734 Attributes Technical Specification", MEF 63, August 2018. 736 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 737 DOI 10.17487/RFC3688, January 2004, 738 . 740 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 741 and A. Bierman, Ed., "Network Configuration Protocol 742 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 743 . 745 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 746 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 747 . 749 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 750 RFC 6991, DOI 10.17487/RFC6991, July 2013, 751 . 753 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 754 RFC 7950, DOI 10.17487/RFC7950, August 2016, 755 . 757 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 758 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 759 . 761 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 762 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 763 . 765 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 766 Access Control Model", STD 91, RFC 8341, 767 DOI 10.17487/RFC8341, March 2018, 768 . 770 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 771 and R. Wilton, "Network Management Datastore Architecture 772 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 773 . 775 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 776 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 777 . 779 9.2. Informative References 781 [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 782 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, 783 April 2007, . 785 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 786 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, 787 DOI 10.17487/RFC5253, July 2008, 788 . 790 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 791 Classification", RFC 8199, DOI 10.17487/RFC8199, July 792 2017, . 794 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 795 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 796 . 798 Appendix A. JSON Example 800 This section provides a JSON example of the YANG module described in 801 Section 4. This example configures one L1VC service with two UNIs 802 that describe the UNI endpoints. The service is configured with the 803 starting time to be 06:06:09 on 2018-09-13 for the service life time 804 of 2419200 seconds (which is corresponds to 28 days). In addition, 805 the service is configured to collect one performance metric, One-way- 806 Delay. 808 { 809 "l1-connectivity": { 810 "access": { 811 "unis": { 812 "uni": [ 813 { 814 "id": "MTL-HQ-Node3-Slot2-Port1", 815 "protocol": "ETH-10GigE_LAN ", 816 "coding": "ETH-10GR-PCS-49 ", 817 "optical_interface": "LR-PMD-clause-52 " 818 }, 819 { 820 "id": "MTL-STL-Node5-Slot4-Port3", 821 "protocol": "ETH-10GigE_LAN ", 822 "coding": "ETH-10GR-PCS-49 ", 823 "optical_interface": "ER-PMD-clause-52 " 824 } 825 ] 826 }, 827 }, 828 "services": { 829 "service": [ 830 { 831 "service-id": "Sub-L1VC-1867-LT-MEGAMART", 832 "endpoint-1": 833 { 834 "id": "MTL-HQ_1867-MEGAMART", 835 "uni": "MTL-HQ-Node3-Slot2-Port1" 836 }, 837 "endpoint-2": 838 { 839 "id": "MTL-STL_1867-MEGAMART", 840 "uni": "MTL-STL-Node5-Slot4-Port3" 841 }, 842 "start-time": "2018-09-13T06:06:09Z", 843 "time-interval": 2419200, 844 "performance-metric": "One-way-Delay " 845 } 846 ] 847 }, 848 } 850 Authors' Addresses 852 Young Lee 853 Samsung 854 Samsung 855 Seoul 856 South Korea 858 Email: younglee.tx@gmail.com 860 KwangKoog Lee 861 Korea Telecom 862 South Korea 864 Email: kwangkoog.lee@kt.com 866 Haomian Zheng 867 Huawei Technologies 868 H1, Huawei Xiliu Beipo Village, Songshan Lake 869 Dongguan, Guangdong 523808 870 China 872 Email: zhenghaomian@huawei.com 874 Oscar Gonzalez de Dios 875 Telefonica 877 Email: oscar.gonzalezdedios@telefonica.com 879 Daniele Ceccarelli 880 Ericsson 882 Email: daniele.ceccarelli@ericsson.com