idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 318 has weird spacing: '...l1vc-id str...' -- The document date (July 17, 2018) is 2110 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: 'RFC8340' is mentioned on line 265, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 277, but not defined == Missing Reference: 'UNI-ID' is mentioned on line 311, but not defined == Missing Reference: 'RFC3688' is mentioned on line 960, but not defined == Unused Reference: 'RFC6020' is defined on line 1006, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-L1CS' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group G. Fioccola (Ed.) 2 Telecom Italia 3 Internet Draft K. Lee 4 Intended Status: Standard Track Korea Telecom 5 Expires: January 17, 2019 Y. Lee (Ed.) 6 D. Dhody 7 Huawei 8 O. Gonzalez de-Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 13 July 17, 2018 15 A Yang Data Model for L1 Connectivity Service Model (L1CSM) 17 draft-ietf-ccamp-l1csm-yang-06 19 Abstract 21 This document provides a YANG data model for Layer 1 Connectivity 22 Service Model (L1CSM). This YANG model is NMDA-compliant. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with 27 the provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on January 17, 2019. 47 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................2 64 1.1. Deployment Scenarios......................................3 65 1.2. Terminology...............................................6 66 1.3. Tree diagram..............................................6 67 1.4. Prefixes in Data Node Names...............................7 68 2. Definitions....................................................7 69 3. L1SM YANG Model (Tree Structure)...............................7 70 4. L1SM YANG Code.................................................8 71 5. JSON Example..................................................19 72 6. Security Considerations.......................................20 73 7. IANA Considerations...........................................21 74 8. Acknowledgments...............................................22 75 9. References....................................................23 76 9.1. Normative References.....................................23 77 9.2. Informative References...................................23 78 10. Contributors.................................................24 79 Authors' Addresses...............................................24 81 1. Introduction 83 This document provides a YANG data model for L1VPN Connectivity 84 Service Model (L1CSM). The intent of this document is to provide a 85 transport service model exploiting Yang data model, which can be 86 utilized by a client network controller to initiate a service 87 request connectivity request as well as retrieving service states 88 toward a transport network controller communicating with the client 89 controller via a NETCONF [RFC8341] or a RESTCONF [RFC8040] 90 interface. 92 [RFC4847] provides a framework and service level requirements for 93 Layer 1 Virtual Private Networks (L1VPNs). It classifies service 94 models as management-based service model, signaling-based service 95 model (Basic Mode) and signaling and routing service model (Enhanced 96 Mode). 98 In the management-based service model, customer management systems 99 and provider management systems communicate with each other. 100 Customer management systems access provider management systems to 101 request layer 1 connection setup/deletion between a pair of CEs. 102 Customer management systems may obtain additional information, such 103 as resource availability information and monitoring information, 104 from provider management systems. There is no control message 105 exchange between a CE and PE. 107 In the signaling-based service model (Basic Model), the CE-PE 108 interface's functional repertoire is limited to path setup signaling 109 only. In the Signaling and routing service model (Enhanced Mode), 110 the CE-PE interface provides the signaling capabilities as in the 111 Basic Mode, plus permits limited exchange of information between the 112 control planes of the provider and the customer to help such 113 functions as discovery of customer network routing information 114 (i.e., reachability or TE information in remote customer sites), or 115 parameters of the part of the provider's network dedicated to the 116 customer. 118 The primary focus of this document is to describe L1CS YANG model 119 required for the instantiation of point-to-point L1VPN service. A 120 L1VPN is a service offered by a core layer 1 network to provide 121 layer 1 connectivity between two or more customer sites where the 122 customer has some control over the establishment and type of the 123 connectivity. 125 The data model presented in Section 3 is in consistent with [MEF- 126 L1CS]. The data model includes configuration and state data 127 according to the new Network Management Datastore Architecture 128 [RFC8342]. 130 1.1. Deployment Scenarios 132 Figure 1 depicts a deployment scenario of the L1VPN SDN control- 133 based service model for an external customer instantiating L1 point- 134 to-point connectivity to the provider. 136 +------------+ 137 | Customer | 138 | Service | 139 |Orchestrator| 140 +------------+ 141 | 142 .. .. .. .. ..|.. .. .. .. .. .. . 143 : | : 144 : +--------------------+ : 145 : | | : 146 : | +----------+ | : 147 : | | Network | | : 148 : | | SDN | | : 149 : | |Controller| | : 150 : | |/NMS/EMS | | : 151 : | +----------+ | : 152 : | | : 153 : | | : 154 +----+ : +----+ +----+ +----+ : +----+ 155 | CE |----:---| PE |----| P |----| PE |---:---| CE | 156 +----+ : +----+ +----+ +----+ : +----+ 157 : | | : 158 : | | : 159 : +--------------------+ : 160 : | | : 161 : |<-Provider network->| : 163 Customer Customer 164 Interface Interface 166 Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: External Customer 168 With this scenario, the customer service orchestrator interfaces 169 with the network SDN controller of the provider using Customer 170 Service Model as defined in [Service-Yang]. 172 Figure 2 depicts another deployment scenario for internal customer 173 (e.g., higher-layer service management department(s)) interfacing 174 the layer 1 transport network department. With this scenario, a 175 multi-service backbone is characterized such that each service 176 department of a provider (e.g., L2/3 services) that receives the 177 same provider's L1VPN service provides a different kind of higher- 178 layer service. The customer receiving the L1VPN service (i.e., each 179 service department) can offer its own services, whose payloads can 180 be any layer (e.g., ATM, IP, TDM). The layer 1 transport network and 181 each service network belong to the same organization, but may be 182 managed separately. The Service SDN Controller is the 183 control/management entity owned by higher-layer service department 184 (e.g., L2/3 VPN) whereas the Network SDN Controller is the 185 control/management entity responsible for Layer 1 connectivity 186 service. The CE's in Figure 2 are L2/3 devices that interface with 187 L1 PE devices. 189 +----------+ 190 | Service | 191 | SDN | 192 |Controller| 193 |/EMS/NMS | 194 | for L2/3 | 195 +----------+ 196 | 197 | 198 | 199 +--------------------+ 200 | | 201 | +----------+ | 202 | | Network | | 203 | | SDN | | 204 | |Controller| | 205 | |/EMS/NMS | | 206 | | for L1VPN| | 207 | +----------+ | 208 | | 209 | | 210 +----+ +----+ +----+ +----+ +----+ 211 | CE |--------| PE |----| P |----| PE |------| CE | 212 +----+ +----+ +----+ +----+ +----+ 213 | | | | 214 | | | | 215 | +--------------------+ | 216 | | | | 217 | |<------------------>| | 218 | Provider Network | 219 | For Layer 1 | 220 |<------------------------------------------>| 221 Provider Network for L2/3 223 Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: Internal Customer 225 The benefit is that the same layer 1 transport network resources are 226 shared by multiple services. A large capacity backbone network 227 (data plane) can be built economically by having the resources 228 shared by multiple services usually with flexibility to modify 229 topologies, while separating the control functions for each service 230 department. Thus, each customer can select a specific set of 231 features that are needed to provide their own service [RFC4847]. 233 1.2. Terminology 235 Refer to [RFC4847] and [RFC5253] for the key terms used in this 236 document. 238 The following terms are defined in [RFC7950] and are not redefined 239 here: 241 o client 243 o server 245 o augment 247 o data model 249 o data node 251 The following terms are defined in [RFC6241] and are not redefined 252 here: 254 o configuration data 256 o state data 258 The terminology for describing YANG data models is found in 259 [RFC7950]. 261 1.3. Tree diagram 263 A simplified graphical representation of the data model is used in 264 chapter 3 of this this document. The meaning of the symbols in 265 these diagrams is defined in [RFC8340]. 267 1.4. Prefixes in Data Node Names 269 In this document, names of data nodes and other data model objects 270 are prefixed using the standard prefix associated with the 271 corresponding YANG imported modules, as shown in Table 1. 273 +---------+------------------------------+-----------------+ 274 | Prefix | YANG module | Reference | 275 +---------+------------------------------+-----------------+ 276 | l1csm | ietf-l1cms | [RFC XXXX] | 277 | l1-st | ietf-l1-mef-service-types | [RFC XXXX] | 278 | yang | ietf-yang-types | [RFC6991] | 279 +---------+------------------------------+-----------------+ 281 Table 1: Prefixes and corresponding YANG modules 283 Note: The RFC Editor will replace XXXX with the number assigned to 284 the RFC once this draft becomes an RFC. 286 2. Definitions 288 L1VC Layer 1 Virtual Connection 290 SLS Service Level Specification 292 UNI User Network Interface 294 PE Provider Edge 296 CE Customer Edge 298 EP End Point 300 P Protocol 302 C Coding 304 O Optical Interface 306 3. L1SM YANG Model (Tree Structure) 308 module: ietf-l1csm 309 +--rw l1cs 310 +--rw access 311 | +--rw uni-list* [UNI-ID] 312 | +--rw UNI-ID string 313 | +--rw protocol? identityref 314 | +--rw coding? identityref 315 | +--rw optical_interface? identityref 316 +--rw service 317 +--rw service-list* [subscriber-l1vc-id] 318 +--rw subscriber-l1vc-id string 319 +--rw service-config 320 +--rw subscriber-l1vc-id? string 321 +--rw subscriber-l1vc-ep-id-1? string 322 +--rw subscriber-l1vc-ep-id-2? string 323 +--rw subscriber-l1vc-ep-UNI-1? -> /l1cs/access/uni-list/UNI-ID 324 +--rw subscriber-l1vc-ep-UNI-2? -> /l1cs/access/uni-list/UNI-ID 325 +--rw time-start? yang:date-and-time 326 +--rw time-interval? Int32 327 +--rw performance-metric? Identityref 329 4. L1SM YANG Code 331 The YANG code is as follows: 333 file "ietf-l1csm@2018-07-05" 335 module ietf-l1csm { 336 yang-version 1.1; 337 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 339 prefix "l1csm"; 340 import ietf-yang-types { 341 prefix "yang"; 342 } 344 import ietf-l1-mef-service-types { 345 prefix "l1-st"; 346 } 348 organization 349 "Internet Engineering Task Force (IETF) CCAMP WG"; 351 contact 353 "Editor: G. Fioccolla (giuseppe.fioccola@telecomitalia.it) 354 Editor: K. Lee (kwangkoog.lee@kt.com) 355 Editor: Y. Lee (leeyoung@huawei.com) 356 Editor: D. Dhody (dhruv.ietf@gmail.com) 357 Editor: O. G. de-Dios (oscar.gonzalezdedios@telefonica.com) 358 Editor: D. Ceccarelli (daniele.ceccarelli@ericsson.com)"; 360 description 361 "this module describes Layer 1 connectivity service 362 model for subscriber Layer 1 Connectivity Services 363 and Attributes. Refer to 'MEF x.y.x Technical Specification 364 Working Draft v0.09 5, December 13, 2017' for all terms and 365 the original references used in the module. 367 Copyright (c) 2018 IETF Trust and the persons identified as 368 authors of the code. All rights reserved. 369 Redistribution and use in source and binary forms, with or 370 without modification, is permitted pursuant to, and subject 371 to the license terms contained in, the Simplified BSD 372 License set forth in Section 4.c of the IETF Trust's Legal 373 Provisions Relating to IETF Documents 374 (http://trustee.ietf.org/license-info). 376 This version of this YANG module is part of RFC XXXX; see 377 the RFC itself for full legal notices."; 379 revision "2018-07-05" { 380 description "Initial revision."; 381 reference "RFC XXXX: A Yang Data Model for L1 Connectivity 382 Service Model (L1CSM)"; 383 // Note: The RFC Editor will replace XXXX with the number 384 // assigned to the RFC once this draft becomes an RFC. 385 } 387 grouping protocol-coding-optical_interface { 388 description 389 "describes where p:protocol type; c:coding 390 function; o:optical interface function"; 391 leaf protocol { 392 type identityref { 393 base "l1-st:protocol-type"; 394 } 395 description 396 "List of physical layer L1VC clientprotocol"; 397 } 398 leaf coding { 399 type identityref { 400 base "l1-st:coding-func"; 401 } 402 description "coding function"; 403 } 404 leaf optical_interface { 405 type identityref { 406 base "l1-st:optical-interface-func"; 407 } 409 description "optical-interface-function"; 410 } 411 } 413 grouping uni-attributes { 414 description 415 "uni-service-attributes"; 417 leaf UNI-ID { 418 type string; 419 description "the UNI id of UNI Service Attributes"; 420 } 422 uses protocol-coding-optical_interface; 423 } 425 grouping subscriber-l1vc-sls-service-attribute { 426 description 427 "The value of the Subscriber L1VC SLS (Service Level 428 Specification) Service Attribute expressed in a 3-tuple 429 of the form."; 431 leaf time-start { 432 type yang:date-and-time; 433 description "a time that represent the date and time 434 for the start of the SLS"; 435 } 437 leaf time-interval { 438 type int32; 439 units seconds; 440 description "a time interval (e.g., 2,419,200 seconds 441 which is 28 days) that is used in 442 conjunction wuth time-start to specify a 443 contiguous sequence of time intervals T for 444 determining when performance objectives are 445 met."; 446 } 448 leaf performance-metric { 449 type identityref { 450 base "l1-st:performance-metriclist"; 451 } 452 description "list of performance metric"; 453 } 454 } 455 grouping subscriber-l1vc-service-attributes { 456 description 457 "subscriber layer 1 connection service service level"; 459 leaf subscriber-l1vc-id { 460 type string; 461 description "subscriber L1VC identifier"; 462 } 464 leaf subscriber-l1vc-ep-id-1 { 465 type string; 466 description "subscriber end point ID of one end"; 467 } 469 leaf subscriber-l1vc-ep-id-2 { 470 type string; 471 description "subscriber end point ID of the other end"; 472 } 474 leaf subscriber-l1vc-ep-UNI-1 { 475 type leafref { 476 path "/l1cs/access/uni-list/UNI-ID"; 477 } 478 description "this is one end of subscriber L1VC end point 479 ID value = UNI-1"; 480 } 482 leaf subscriber-l1vc-ep-UNI-2 { 483 type leafref { 484 path "/l1cs/access/uni-list/UNI-ID"; 485 } 486 description "this is the other end of subscriber L1VC end 487 point ID value = UNI-2"; 488 } 490 uses subscriber-l1vc-sls-service-attribute; 491 } 493 grouping subscriber-attributes { 494 description 495 "subscriber attributes"; 497 uses subscriber-l1vc-service-attributes; 498 } 500 container l1cs { 501 description 502 "serves as a top-level container for a list of layer 1 503 connection services (l1cs)"; 505 container access { 506 description "UNI configurations"; 508 list uni-list { 509 key "UNI-ID"; 510 description "uni identifier"; 511 uses uni-attributes { 512 description "UNI attributes information"; 513 } 514 } 515 } 517 container service { 518 description "L1VC service"; 519 list service-list { 520 key "subscriber-l1vc-id"; 521 description 522 "an unique identifier of a service"; 524 leaf subscriber-l1vc-id { 525 type string; 526 description "a unique service identifier for 527 L1VC."; 528 } 529 container service-config { 530 description "service-config container"; 531 uses subscriber-attributes; 532 }//end of service-config 533 }//end of service list 534 } //end of service container 535 }//service top container 536 } 538 540 file "ietf-l1-mef-service-types@2018-07-05" 542 module ietf-l1-mef-service-types { 543 namespace "urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types"; 544 prefix "l1-st"; 546 organization 547 "IETF CCAMP Working Group"; 548 contact 549 "WG Web: 550 WG List: 551 Editor: G. Fioccolla(giuseppe.fioccola@telecomitalia.it) 552 Editor: K. Lee (kwangkoog.lee@kt.com) 553 Editor: Y. Lee (leeyoung@huawei.com) 554 Editor: D. Dhody (dhruv.ietf@gmail.com) 555 Editor: O. G. de-Dios(oscar.gonzalezdedios@telefonica.com) 556 Editor: D. Ceccarelli(daniele.ceccarelli@ericsson.com)"; 558 description 559 "This module defines L1 service types based on MEF 560 subscriber Layer 1 Connectivity Service Attribute. Refer to 561 'MEF x.y.x Technical Specification Working Draft v0.09 5, 562 December 13, 2017' for all terms and the original references 563 used in the module. 565 Copyright (c) 2018 IETF Trust and the persons identified as 566 authors of the code. All rights reserved. 567 Redistribution and use in source and binary forms, with or 568 without modification, is permitted pursuant to, and subject 569 to the license terms contained in, the Simplified BSD 570 License set forth in Section 4.c of the IETF Trust's Legal 571 Provisions Relating to IETF Documents 572 (http://trustee.ietf.org/license-info). 574 This version of this YANG module is part of RFC XXXX; see 575 the RFC itself for full legal notices."; 577 revision "2018-07-05" { 578 description "Initial revision."; 579 reference "RFC XXXX: A Yang Data Model for L1 Connectivity 580 Service Model (L1CSM)"; 581 // Note: The RFC Editor will replace XXXX with the number 582 // assigned to the RFC once this draft becomes an RFC. 583 } 585 identity protocol-type { 586 description 587 "base identity from which client protocol type is derived."; 588 } 590 identity aGigE { 591 base "protocol-type"; 592 description 593 "GigE protocol type"; 594 } 596 identity a10GigE_WAN { 597 base "protocol-type"; 598 description 599 "10GigE-WAN protocol type"; 600 } 602 identity a10GigE_LAN { 603 base "protocol-type"; 604 description 605 "10GigE-LAN protocol type"; 606 } 608 identity a40GigE { 609 base "protocol-type"; 610 description 611 "40GigE protocol type"; 612 } 614 identity a100GigE { 615 base "protocol-type"; 616 description 617 "100GigE protocol type"; 618 } 620 identity FC-100 { 621 base "protocol-type"; 622 description 623 "Fiber Channel - 100 protocol type"; 624 } 626 identity FC-200 { 627 base "protocol-type"; 628 description 629 "Fiber Channel - 200 protocol type"; 630 } 632 identity FC-400 { 633 base "protocol-type"; 634 description 635 "Fiber Channel - 400 protocol type"; 636 } 638 identity FC-800 { 639 base "protocol-type"; 640 description 641 "Fiber Channel - 800 protocol type"; 642 } 644 identity FC-1200 { 645 base "protocol-type"; 646 description 647 "Fiber Channel - 1200 protocol type"; 649 } 651 identity FC-1600 { 652 base "protocol-type"; 653 description 654 "Fiber Channel - 1600 protocol type"; 655 } 657 identity FC-3200 { 658 base "protocol-type"; 659 description 660 "Fiber Channel - 3200 protocol type"; 661 } 663 identity STM-1 { 664 base "protocol-type"; 665 description 666 "SDH STM-1 protocol type"; 667 } 669 identity STM-4 { 670 base "protocol-type"; 671 description 672 "SDH STM-4 protocol type"; 673 } 675 identity STM-16 { 676 base "protocol-type"; 677 description 678 "SDH STM-16 protocol type"; 679 } 681 identity STM-64 { 682 base "protocol-type"; 683 description 684 "SDH STM-64 protocol type"; 685 } 687 identity STM-256 { 688 base "protocol-type"; 689 description 690 "SDH STM-256 protocol type"; 691 } 693 identity OC-3 { 694 base "protocol-type"; 695 description 696 "SONET OC-3 protocol type"; 697 } 698 identity OC-12 { 699 base "protocol-type"; 700 description 701 "SONET OC-12 protocol type"; 702 } 704 identity OC-48 { 705 base "protocol-type"; 706 description 707 "SONET OC-48 protocol type"; 708 } 710 identity OC-192 { 711 base "protocol-type"; 712 description 713 "SONET OC-192 protocol type"; 714 } 716 identity OC-768 { 717 base "protocol-type"; 718 description 719 "SONET OC-768 protocol type"; 720 } 722 identity coding-func { 723 description 724 "base identity from which coding func is derived."; 725 } 727 identity a1000X-PCS-36 { 728 base "coding-func"; 729 description 730 "PCS clause 36 coding function that corresponds to 1000BASE-X"; 731 } 733 identity a10GW-PCS-49-WIS-50 { 734 base "coding-func"; 735 description 736 "PCS clause 49 and WIS clause 50 coding func that corresponds to 737 10GBASE-W (WAN PHY)"; 738 } 740 identity a10GR-PCS-49 { 741 base "coding-func"; 742 description 743 "PCS clause 49 coding function that corresponds to 10GBASE-R (LAN 744 PHY)"; 745 } 746 identity a40GR-PCS-82 { 747 base "coding-func"; 748 description 749 "PCS clause 82 coding function that corresponds to 40GBASE-R"; 750 } 752 identity a100GR-PCS-82 { 753 base "coding-func"; 754 description 755 "PCS clause 82 coding function that corresponds to 100GBASE-R"; 756 } 758 /* coding func needs to expand for Fiber Channel, SONET, SDH */ 760 identity optical-interface-func { 761 description 762 "base identity from which optical-interface-function is derived."; 763 } 765 identity SX-PMD-clause-38 { 766 base "optical-interface-func"; 767 description 768 "SX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36"; 769 } 771 identity LX-PMD-clause-38 { 772 base "optical-interface-func"; 773 description 774 "LX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36"; 775 } 777 identity LX10-PMD-clause-59 { 778 base "optical-interface-func"; 779 description 780 "LX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS- 781 36"; 782 } 784 identity BX10-PMD-clause-59 { 785 base "optical-interface-func"; 786 description 787 "BX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS- 788 36"; 789 } 791 identity LW-PMD-clause-52 { 792 base "optical-interface-func"; 793 description 794 "LW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49- 795 WIS-50"; 796 } 798 identity EW-PMD-clause-52 { 799 base "optical-interface-func"; 800 description 801 "EW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49- 802 WIS-50"; 803 } 805 identity LR-PMD-clause-52 { 806 base "optical-interface-func"; 807 description 808 "LR-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49"; 809 } 811 identity ER-PMD-clause-52 { 812 base "optical-interface-func"; 813 description 814 "ER-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49"; 815 } 817 identity LR4-PMD-clause-87 { 818 base "optical-interface-func"; 819 description 820 "LR4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82"; 821 } 823 identity ER4-PMD-clause-87 { 824 base "optical-interface-func"; 825 description 826 "ER4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82"; 827 } 829 identity FR-PMD-clause-89 { 830 base "optical-interface-func"; 831 description 832 "FR-PMD-clause-89 Optical Interface function for 40GBASE-R PCS-82"; 833 } 835 identity LR4-PMD-clause-88 { 836 base "optical-interface-func"; 837 description 838 "LR4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS- 839 82"; 840 } 841 identity ER4-PMD-clause-88 { 842 base "optical-interface-func"; 843 description 844 "ER4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS- 845 82"; 846 } 848 /* optical interface func needs to expand for Fiber Channel, SONET and SDH */ 850 identity performance-metriclist { 851 description "list of performance metric"; 852 } 854 identity One-way-Delay { 855 base "performance-metriclist"; 856 description "one-way-delay"; 857 } 859 identity One-way-Errored-Second { 860 base "performance-metriclist"; 861 description "one-way-errored-second"; 862 } 864 identity One-way-Severely-Errored-Second { 865 base "performance-metriclist"; 866 description "one-way-severely-errored-second"; 867 } 869 identity One-way-Unavailable-Second { 870 base "performance-metriclist"; 871 description "one-way-unavailable-second"; 872 } 874 identity One-way-Availability { 875 base "performance-metriclist"; 876 description "one-way-availability"; 877 } 879 } 881 883 5. JSON Example 885 This section provides a JSON example of the YANG module described in 886 Section 4. 888 { 889 "l1cs": { 890 "access": { 891 "uni-list": [ 892 { 893 "UNI-ID": "MTL-HQ-Node3-Slot2-Port1", 894 "protocol": "a10GigE_LAN ", 895 "coding": "a10GR-PCS-49 ", 896 "optical_interface": "LR-PMD-clause-52 " 897 }, 898 { 899 "UNI-ID": "MTL-STL-Node5-Slot4-Port3", 900 "protocol": "a10GigE_LAN ", 901 "coding": "a10GR-PCS-49 ", 902 "optical_interface": "ER-PMD-clause-52 " 903 } 904 ] 905 }, 906 "service": { 907 "service-list": [ 908 { 909 "subscriber-l1vc-id": "Sub-L1VC-1867-LT-MEGAMART", 910 "service-config": { 911 "subscriber-l1vc-id": "Sub-L1VC-1867-LT-MEGAMART", 912 "subscriber-l1vc-ep-id-1": "MTL-HQ_1867-MEGAMART", 913 "subscriber-l1vc-ep-id-2": "MTL-STL_1867-MEGAMART", 914 "subscriber-l1vc-ep-UNI-1": "MTL-HQ-Node3-Slot2-Port1", 915 "subscriber-l1vc-ep-UNI-2": "MTL-STL-Node5-Slot4-Port3", 916 "time-start": "2018-07-13T06:06:09Z", 917 "time-interval": 2419200, 918 "performance-metric": "One-way-Delay " 919 } 920 } 921 ] 922 } 923 } 924 } 926 6. Security Considerations 928 The configuration, state, and action data defined in this document 929 are designed to be accessed via a management protocol with a secure 930 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 931 The lowest NETCONF layer is the secure transport layer, and the 932 mandatory-to-implement secure transport is Secure Shell (SSH) 933 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 934 to-implement secure transport is TLS [RFC5246]. 936 The NETCONF access control model [RFC8341] provides the means to 937 restrict access for particular NETCONF users to a preconfigured 938 subset of all available NETCONF protocol operations and content. 940 A number of configuration data nodes defined in this document are 941 writable/deletable (i.e., "config true") These data nodes may be 942 considered sensitive or vulnerable in some network environments. 944 These are the subtrees and data nodes and their 945 sensitivity/vulnerability: 947 Service-Config: 948 - subscriber-l1vc-id 949 - subscriber-l1vc-ep-id-1 950 - subscriber-l1vc-ep-id-2 951 - subscriber-l1vc-ep-UNI-1 952 - subscriber-l1vc-ep-UNI-2 953 - time-start 954 - time-interval 955 - performance-metric 957 7. IANA Considerations 959 This document registers the following namespace URIs in the IETF XML 960 registry [RFC3688]: 962 -------------------------------------------------------------------- 963 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 964 Registrant Contact: The IESG. 965 XML: N/A, the requested URI is an XML namespace. 966 -------------------------------------------------------------------- 968 -------------------------------------------------------------------- 969 URI: urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types 970 Registrant Contact: The IESG. 971 XML: N/A, the requested URI is an XML namespace. 972 -------------------------------------------------------------------- 974 This document registers the following YANG modules in the YANG 975 Module 977 Names registry [RFC7950]: 979 -------------------------------------------------------------------- 980 name: ietf-l1csm 981 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 982 reference: RFC XXXX (TDB) 983 -------------------------------------------------------------------- 985 -------------------------------------------------------------------- 986 name: ietf-l1-mef-service-types 987 namespace: urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types 988 reference: RFC XXXX (TDB) 989 -------------------------------------------------------------------- 991 8. Acknowledgments 993 The authors would like to thank Tom Petch and Italo Busi for their 994 helpful comments and valuable contributions. 996 9. References 998 9.1. Normative References 1000 [MEF-L1CS] "Subscriber Layer 1 Connectivity Service Attributes", 1001 Working Draft (WD) v0.09 December 13, 2017. 1003 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1004 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1006 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1007 the Network Configuration Protocol (NETCONF)", RFC 6020, 1008 October 2010. 1010 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1011 and A. Bierman, Ed., "Network Configuration Protocol 1012 (NETCONF)", RFC 6241, June 2011. 1014 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1015 Shell (SSH)", RFC 6242, June 2011. 1017 [RFC6991] J. Schoenwaelder, Ed., "Common YANG Data Types", RFC 6991, 1018 July 2013. 1020 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1021 RFC 7950, August 2016. 1023 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1024 Protocol", RFC 8040, January 2017. 1026 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1027 Access Control Model", RFC 8341, March 2018. 1029 9.2. Informative References 1031 [RFC4847] T. Takeda (Editor), "Framework and Requirements for Layer 1032 1 Virtual Private Networks", RFC 4847, April 2007. 1034 [RFC5253] T. Takeda, "Applicability Statement for Layer 1 Virtual 1035 Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. 1037 [Service-Yang] Q. Wu, et al, "Service Models Explained", draft-wu- 1038 opsawg-service-model-explained, Work in progress. 1040 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1041 and R. Wilton, "Network Management Datastore Architecture 1042 (NMDA)", RFC 8342, March 2018, 1044 10. Contributors 1046 Contributor's Addresses 1048 I. Busi 1049 Huawei 1050 Email: Italo.Busi@huawei.com 1052 Authors' Addresses 1054 G. Fioccola (Editor) 1055 Telecom Italia 1056 Email: giuseppe.fioccola@telecomitalia.it 1058 K. Lee 1059 KT 1060 Email: kwangkoog.lee@kt.com 1062 Y. Lee (Editor) 1063 Huawei 1064 Email: leeyoung@huawei.com 1066 D. Dhody 1067 Huawei 1068 Email: dhruv.ietf@gmail.com 1070 O. Gonzalez de Dios 1071 Telefonica 1072 Email: oscar.gonzalezdedios@telefonica.com 1074 D. Ceccarelli 1075 Ericsson 1076 Email: daniele.ceccarelli@ericsson.com