idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-05.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 316 has weird spacing: '...l1vc-id str...' -- The document date (July 2, 2018) is 2124 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 263, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 275, but not defined == Missing Reference: 'UNI-ID' is mentioned on line 309, but not defined == Missing Reference: 'RFC3688' is mentioned on line 938, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-L1CS' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 6 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 3, 2019 Y. Lee (Ed.) 6 D. Dhody 7 Huawei 8 O. Gonzalez de-Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 13 July 2, 2018 15 A Yang Data Model for L1 Connectivity Service Model (L1CSM) 17 draft-ietf-ccamp-l1csm-yang-05 19 Abstract 21 This document provides a YANG data model for Layer 1 Connectivity 22 Service Model (L1CSM). 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 3, 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. Security Considerations.......................................20 72 6. IANA Considerations...........................................21 73 7. Acknowledgments...............................................22 74 8. References....................................................23 75 8.1. Normative References.....................................23 76 8.2. Informative References...................................23 77 9. Contributors..................................................24 78 Authors' Addresses...............................................24 80 1. Introduction 82 This document provides a YANG data model for L1VPN Connectivity 83 Service Model (L1CSM). 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 86 request connectivity request as well as retrieving service states 87 toward a transport network controller communicating with the client 88 controller via a NETCONF [RFC8341] 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, 102 from provider management systems. There is no control message 103 exchange 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 112 (i.e., 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 119 layer 1 connectivity between two or more customer sites where the 120 customer has some control over the establishment and type of the 121 connectivity. 123 The data model presented in Section 3 is in consistent with [MEF- 124 L1CS]. The data model includes configuration and state data 125 according to the new Network Management Datastore Architecture 126 [RFC8342]. 128 1.1. Deployment Scenarios 130 Figure 1 depicts a deployment scenario of the L1VPN SDN control- 131 based service model for an external customer instantiating L1 point- 132 to-point connectivity to the provider. 134 +------------+ 135 | Customer | 136 | Service | 137 |Orchestrator| 138 +------------+ 139 | 140 .. .. .. .. ..|.. .. .. .. .. 141 : | : 142 : +--------------------+ : 143 : | | : 144 : | +----------+ | : 145 : | | Network | | : 146 : | | SDN | | : 147 : | |Controller| | : 148 : | |/NMS/EMS | | : 149 : | +----------+ | : 150 : | | : 151 : | | : 152 +----+ : +----+ +----+ +----+ : +----+ 153 | CE |----:---| PE |----| P |----| PE |---:---| CE | 154 +----+ : +----+ +----+ +----+ : +----+ 155 : | | : 156 : | | : 157 : +--------------------+ : 158 : | | : 159 : |<-Provider network->| : 161 Customer Customer 162 Interface Interface 164 Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: External Customer 166 With this scenario, the customer service orchestrator interfaces 167 with the network SDN controller of the provider using Customer 168 Service Model as defined in [Service-Yang]. 170 Figure 2 depicts another deployment scenario for internal customer 171 (e.g., higher-layer service management department(s)) interfacing 172 the layer 1 transport network department. With this scenario, a 173 multi-service backbone is characterized such that each service 174 department of a provider (e.g., L2/3 services) that receives the 175 same provider's L1VPN service provides a different kind of higher- 176 layer service. The customer receiving the L1VPN service (i.e., each 177 service department) can offer its own services, whose payloads can 178 be any layer (e.g., ATM, IP, TDM). The layer 1 transport network and 179 each service network belong to the same organization, but may be 180 managed separately. The Service SDN Controller is the 181 control/management entity owned by higher-layer service department 182 (e.g., L2/3 VPN) whereas the Network SDN Controller is the 183 control/management entity responsible for Layer 1 connectivity 184 service. The CE's in Figure 2 are L2/3 devices that interface with 185 L1 PE devices. 187 +----------+ 188 | Service | 189 | SDN | 190 |Controller| 191 |/EMS/NMS | 192 | for L2/3 | 193 +----------+ 194 | 195 | 196 | 197 +--------------------+ 198 | | 199 | +----------+ | 200 | | Network | | 201 | | SDN | | 202 | |Controller| | 203 | |/EMS/NMS | | 204 | | for L1VPN| | 205 | +----------+ | 206 | | 207 | | 208 +----+ +----+ +----+ +----+ +----+ 209 | CE |--------| PE |----| P |----| PE |------| CE | 210 +----+ +----+ +----+ +----+ +----+ 211 | | | | 212 | | | | 213 | +--------------------+ | 214 | | | | 215 | |<------------------>| | 216 | Provider Network | 217 | For Layer 1 | 218 |<------------------------------------------>| 219 Provider Network for L2/3 221 Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: Internal Customer 223 The benefit is that the same layer 1 transport network resources are 224 shared by multiple services. A large capacity backbone network 225 (data plane) can be built economically by having the resources 226 shared by multiple services usually with flexibility to modify 227 topologies, while separating the control functions for each service 228 department. Thus, each customer can select a specific set of 229 features that are needed to provide their own service [RFC4847]. 231 1.2. Terminology 233 Refer to [RFC4847] and [RFC5253] for the key terms used in this 234 document. 236 The following terms are defined in [RFC6241] and are not redefined 237 here: 239 o client 241 o configuration data 243 o server 245 o state data 247 The following terms are defined in [RFC6020] and are not redefined 248 here: 250 o augment 252 o data model 254 o data node 256 The terminology for describing YANG data models is found in 257 [RFC6020]. 259 1.3. Tree diagram 261 A simplified graphical representation of the data model is used in 262 chapter 3 of this this document. The meaning of the symbols in 263 these diagrams is defined in [RFC8340]. 265 1.4. Prefixes in Data Node Names 267 In this document, names of data nodes and other data model objects 268 are prefixed using the standard prefix associated with the 269 corresponding YANG imported modules, as shown in Table 1. 271 +---------+------------------------------+-----------------+ 272 | Prefix | YANG module | Reference | 273 +---------+------------------------------+-----------------+ 274 | l1csm | ietf-l1cms | [RFC XXXX] | 275 | l1-st | ietf-l1-mef-service-types | [RFC XXXX] | 276 | yang | ietf-yang-types | [RFC6991] | 277 +---------+------------------------------+-----------------+ 279 Table 1: Prefixes and corresponding YANG modules 281 Note: The RFC Editor will replace XXXX with the number assigned to 282 the RFC once this draft becomes an RFC. 284 2. Definitions 286 L1VC Layer 1 Virtual Connection 288 SLS Service Level Specification 290 UNI User Network Interface 292 PE Provider Edge 294 CE Customer Edge 296 EP End Point 298 P Protocol 300 C Coding 302 O Optical Interface 304 3. L1SM YANG Model (Tree Structure) 306 module: ietf-l1csm 307 +--rw l1cs 308 +--rw access 309 | +--rw uni-list* [UNI-ID] 310 | +--rw UNI-ID string 311 | +--rw protocol? identityref 312 | +--rw coding? identityref 313 | +--rw optical_interface? identityref 314 +--rw service 315 +--rw service-list* [subscriber-l1vc-id] 316 +--rw subscriber-l1vc-id string 317 +--rw service-config 318 +--rw subscriber-l1vc-id? string 319 +--rw subscriber-l1vc-ep-id-1? string 320 +--rw subscriber-l1vc-ep-id-2? string 321 +--rw subscriber-l1vc-ep-UNI-1? -> /l1cs/access/uni-list/UNI-ID 322 +--rw subscriber-l1vc-ep-UNI-2? -> /l1cs/access/uni-list/UNI-ID 323 +--rw time-start? yang:date-and-time 324 +--rw time-interval? int16 325 +--rw performance-metric? Identityref 327 4. L1SM YANG Code 329 The YANG code is as follows: 331 file "ietf-l1csm@2018-07-02.yang" 333 module ietf-l1csm { 334 yang-version 1.1; 335 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 337 prefix "l1csm"; 338 import ietf-yang-types { 339 prefix "yang"; 340 } 342 import ietf-l1-mef-service-types { 343 prefix "l1-st"; 344 } 346 organization 347 "Internet Engineering Task Force (IETF) CCAMP WG"; 349 contact 351 "Editor: G. Fioccolla (giuseppe.fioccola@telecomitalia.it) 352 Editor: K. Lee (kwangkoog.lee@kt.com) 353 Editor: Y. Lee (leeyoung@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 Layer 1 connectivity service 360 model for subscriber Layer 1 Connectivity Services 361 and Attributes. Refer to 'MEF x.y.x Technical Specification 362 Working Draft v0.09 5, December 13, 2017' for all terms and 363 the original references used in the module. 365 Copyright (c) 2018 IETF Trust and the persons identified as 366 authors of the code. All rights reserved. 367 Redistribution and use in source and binary forms, with or 368 without modification, is permitted pursuant to, and subject 369 to the license terms contained in, the Simplified BSD 370 License set forth in Section 4.c of the IETF Trust's Legal 371 Provisions Relating to IETF Documents 372 (http://trustee.ietf.org/license-info). 374 This version of this YANG module is part of RFC XXXX; see 375 the RFC itself for full legal notices."; 377 revision 2018-07-02 { 378 description 379 "updated version to incorporate MEF comments"; 380 reference "to add the draft name"; 381 } 383 revision 2018-06-20 { 384 description 385 "updated version to incorporate MEF comments"; 386 reference "to add the draft name"; 387 } 389 revision 2018-04-11 { 390 description 391 "Initial revision."; 392 reference "to add the draft name"; 393 } 395 grouping protocol-coding-optical_interface { 396 description 397 "describes where p:protocol type; c:coding 398 function; o:optical interface function"; 399 leaf protocol { 400 type identityref { 401 base "l1-st:protocol-type"; 402 } 403 description 404 "List of physical layer L1VC clientprotocol"; 405 } 406 leaf coding { 407 type identityref { 408 base "l1-st:coding-func"; 409 } 410 description "coding function"; 411 } 412 leaf optical_interface { 413 type identityref { 414 base "l1-st:optical-interface-func"; 415 } 417 description "optical-interface-function"; 418 } 419 } 421 grouping uni-attributes { 422 description 423 "uni-service-attributes"; 425 leaf UNI-ID { 426 type string; 427 description "the UNI id of UNI Service Attributes"; 428 } 430 uses protocol-coding-optical_interface; 431 } 433 grouping subscriber-l1vc-sls-service-attribute { 434 description 435 "The value of the Subscriber L1VC SLS (Service Level 436 Specification) Service Attribute expressed in a 3-tuple 437 of the form."; 439 leaf time-start { 440 type yang:date-and-time; 441 description "a time that represent the date and time 442 for the start of the SLS"; 443 } 445 leaf time-interval { 446 type int16; 447 units seconds; 448 description "a time interval (e.g., 2,419,200 seconds 449 which is 28 days) that is used in 450 conjunction wuth time-start to specify a 451 contiguous sequence of time intervals T for 452 determining when performance objectives are 453 met."; 454 } 456 leaf performance-metric { 457 type identityref { 458 base "l1-st:performance-metriclist"; 459 } 460 description "list of performance metric"; 461 } 462 } 464 grouping subscriber-l1vc-service-attributes { 465 description 466 "subscriber layer 1 connection service service level"; 468 leaf subscriber-l1vc-id { 469 type string; 470 description "subscriber L1VC identifier"; 471 } 473 leaf subscriber-l1vc-ep-id-1 { 474 type string; 475 description "subscriber end point ID of one end"; 476 } 478 leaf subscriber-l1vc-ep-id-2 { 479 type string; 480 description "subscriber end point ID of the other end"; 481 } 483 leaf subscriber-l1vc-ep-UNI-1 { 484 type leafref { 485 path "/l1cs/access/uni-list/UNI-ID"; 486 } 487 description "this is one end of subscriber L1VC end point 488 ID value = UNI-1"; 489 } 491 leaf subscriber-l1vc-ep-UNI-2 { 492 type leafref { 493 path "/l1cs/access/uni-list/UNI-ID"; 494 } 495 description "this is the other end of subscriber L1VC end 496 point ID value = UNI-2"; 497 } 499 uses subscriber-l1vc-sls-service-attribute; 500 } 501 grouping subscriber-attributes { 502 description 503 "subscriber attributes"; 505 uses subscriber-l1vc-service-attributes; 506 } 508 container l1cs { 509 description 510 "serves as a top-level container for a list of layer 1 511 connection services (l1cs)"; 513 container access { 514 description "UNI configurations"; 516 list uni-list { 517 key "UNI-ID"; 518 description "uni identifier"; 519 uses uni-attributes { 520 description "UNI attributes information"; 521 } 522 } 523 } 525 container service { 526 description "L1VC service"; 527 list service-list { 528 key "subscriber-l1vc-id"; 529 description 530 "an unique identifier of a service"; 532 leaf subscriber-l1vc-id { 533 type string; 534 description "a unique service identifier for 535 L1VC."; 536 } 537 container service-config { 538 description "service-config container"; 539 uses subscriber-attributes; 540 }//end of service-config 541 }//end of service list 542 } //end of service container 543 }//service top container 544 } 546 548 file "ietf-l1-mef-service-types@2018-7-02.yang" 550 module ietf-l1-mef-service-types { 551 namespace "urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types"; 552 prefix "l1-st"; 554 organization 555 "IETF CCAMP Working Group"; 556 contact 557 "WG Web: 558 WG List: 560 Editor: G. Fioccolla(giuseppe.fioccola@telecomitalia.it) 561 Editor: K. Lee (kwangkoog.lee@kt.com) 562 Editor: Y. Lee (leeyoung@huawei.com) 563 Editor: D. Dhody (dhruv.ietf@gmail.com) 564 Editor: O. G. de-Dios(oscar.gonzalezdedios@telefonica.com) 565 Editor: D. Ceccarelli(daniele.ceccarelli@ericsson.com)"; 567 description 568 "This module defines L1 service types based on MEF 569 subscriber Layer 1 Connectivity Service Attribute. Refer to 570 'MEF x.y.x Technical Specification Working Draft v0.09 5, 571 December 13, 2017' for all terms and the original references 572 used in the module. 574 Copyright (c) 2018 IETF Trust and the persons identified as 575 authors of the code. All rights reserved. 576 Redistribution and use in source and binary forms, with or 577 without modification, is permitted pursuant to, and subject 578 to the license terms contained in, the Simplified BSD 579 License set forth in Section 4.c of the IETF Trust's Legal 580 Provisions Relating to IETF Documents 581 (http://trustee.ietf.org/license-info). 583 This version of this YANG module is part of RFC XXXX; see 584 the RFC itself for full legal notices."; 586 revision "2018-07-02" { 587 description 588 "Revision 0.2"; 589 reference "TBD"; 590 } 592 revision "2018-06-20" { 593 description 594 "Revision 0.2"; 595 reference "TBD"; 597 } 599 revision "2018-04-11" { 600 description 601 "Revision 0.1"; 602 reference "TBD"; 603 } 605 identity protocol-type { 606 description 607 "base identity from which client protocol type is derived."; 608 } 610 identity aGigE { 611 base "protocol-type"; 612 description 613 "GigE protocol type"; 614 } 616 identity a10GigE_WAN { 617 base "protocol-type"; 618 description 619 "10GigE-WAN protocol type"; 620 } 622 identity a10GigE_LAN { 623 base "protocol-type"; 624 description 625 "10GigE-LAN protocol type"; 626 } 628 identity a40GigE { 629 base "protocol-type"; 630 description 631 "40GigE protocol type"; 632 } 634 identity a100GigE { 635 base "protocol-type"; 636 description 637 "100GigE protocol type"; 638 } 640 identity FC-100 { 641 base "protocol-type"; 642 description 643 "Fiber Channel - 100 protocol type"; 644 } 645 identity FC-200 { 646 base "protocol-type"; 647 description 648 "Fiber Channel - 200 protocol type"; 649 } 651 identity FC-400 { 652 base "protocol-type"; 653 description 654 "Fiber Channel - 400 protocol type"; 655 } 657 identity FC-800 { 658 base "protocol-type"; 659 description 660 "Fiber Channel - 800 protocol type"; 661 } 663 identity FC-1200 { 664 base "protocol-type"; 665 description 666 "Fiber Channel - 1200 protocol type"; 667 } 669 identity FC-1600 { 670 base "protocol-type"; 671 description 672 "Fiber Channel - 1600 protocol type"; 673 } 675 identity FC-3200 { 676 base "protocol-type"; 677 description 678 "Fiber Channel - 3200 protocol type"; 679 } 681 identity STM-1 { 682 base "protocol-type"; 683 description 684 "SDH STM-1 protocol type"; 685 } 687 identity STM-4 { 688 base "protocol-type"; 689 description 690 "SDH STM-4 protocol type"; 691 } 693 identity STM-16 { 694 base "protocol-type"; 695 description 696 "SDH STM-16 protocol type"; 697 } 699 identity STM-64 { 700 base "protocol-type"; 701 description 702 "SDH STM-64 protocol type"; 703 } 705 identity STM-256 { 706 base "protocol-type"; 707 description 708 "SDH STM-256 protocol type"; 709 } 711 identity OC-3 { 712 base "protocol-type"; 713 description 714 "SONET OC-3 protocol type"; 715 } 717 identity OC-12 { 718 base "protocol-type"; 719 description 720 "SONET OC-12 protocol type"; 721 } 723 identity OC-48 { 724 base "protocol-type"; 725 description 726 "SONET OC-48 protocol type"; 727 } 729 identity OC-192 { 730 base "protocol-type"; 731 description 732 "SONET OC-192 protocol type"; 733 } 735 identity OC-768 { 736 base "protocol-type"; 737 description 738 "SONET OC-768 protocol type"; 739 } 741 identity coding-func { 742 description 743 "base identity from which coding func is derived."; 744 } 746 identity a1000X-PCS-36 { 747 base "coding-func"; 748 description 749 "PCS clause 36 coding function that corresponds to 1000BASE-X"; 750 } 752 identity a10GW-PCS-49-WIS-50 { 753 base "coding-func"; 754 description 755 "PCS clause 49 and WIS clause 50 coding func that corresponds to 756 10GBASE-W (WAN PHY)"; 757 } 759 identity a10GR-PCS-49 { 760 base "coding-func"; 761 description 762 "PCS clause 49 coding function that corresponds to 10GBASE-R (LAN 763 PHY)"; 764 } 766 identity a40GR-PCS-82 { 767 base "coding-func"; 768 description 769 "PCS clause 82 coding function that corresponds to 40GBASE-R"; 770 } 772 identity a100GR-PCS-82 { 773 base "coding-func"; 774 description 775 "PCS clause 82 coding function that corresponds to 100GBASE-R"; 776 } 778 /* coding func needs to expand for Fiber Channel, SONET, SDH */ 780 identity optical-interface-func { 781 description 782 "base identity from which optical-interface-function is derived."; 783 } 785 identity SX-PMD-clause-38 { 786 base "optical-interface-func"; 787 description 788 "SX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36"; 789 } 790 identity LX-PMD-clause-38 { 791 base "optical-interface-func"; 792 description 793 "LX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36"; 794 } 796 identity LX10-PMD-clause-59 { 797 base "optical-interface-func"; 798 description 799 "LX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS- 800 36"; 801 } 803 identity BX10-PMD-clause-59 { 804 base "optical-interface-func"; 805 description 806 "BX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS- 807 36"; 808 } 810 identity LW-PMD-clause-52 { 811 base "optical-interface-func"; 812 description 813 "LW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49- 814 WIS-50"; 815 } 817 identity EW-PMD-clause-52 { 818 base "optical-interface-func"; 819 description 820 "EW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49- 821 WIS-50"; 822 } 824 identity LR-PMD-clause-52 { 825 base "optical-interface-func"; 826 description 827 "LR-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49"; 828 } 830 identity ER-PMD-clause-52 { 831 base "optical-interface-func"; 832 description 833 "ER-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49"; 834 } 836 identity LR4-PMD-clause-87 { 837 base "optical-interface-func"; 838 description 839 "LR4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82"; 840 } 842 identity ER4-PMD-clause-87 { 843 base "optical-interface-func"; 844 description 845 "ER4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82"; 846 } 848 identity FR-PMD-clause-89 { 849 base "optical-interface-func"; 850 description 851 "FR-PMD-clause-89 Optical Interface function for 40GBASE-R PCS-82"; 852 } 854 identity LR4-PMD-clause-88 { 855 base "optical-interface-func"; 856 description 857 "LR4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS- 858 82"; 859 } 861 identity ER4-PMD-clause-88 { 862 base "optical-interface-func"; 863 description 864 "ER4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS- 865 82"; 866 } 868 /* optical interface func needs to expand for Fiber Channel, SONET and SDH */ 870 identity performance-metriclist { 871 description "list of performance metric"; 872 } 874 identity One-way-Delay { 875 base "performance-metriclist"; 876 description "one-way-delay"; 877 } 879 identity One-way-Errored-Second { 880 base "performance-metriclist"; 881 description "one-way-errored-second"; 882 } 884 identity One-way-Severely-Errored-Second { 885 base "performance-metriclist"; 886 description "one-way-severely-errored-second"; 888 } 890 identity One-way-Unavailable-Second { 891 base "performance-metriclist"; 892 description "one-way-unavailable-second"; 893 } 895 identity One-way-Availability { 896 base "performance-metriclist"; 897 description "one-way-availability"; 898 } 900 } 902 904 5. Security Considerations 906 The configuration, state, and action data defined in this document 907 are designed to be accessed via a management protocol with a secure 908 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 909 The lowest NETCONF layer is the secure transport layer, and the 910 mandatory-to-implement secure transport is Secure Shell (SSH) 911 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 912 to-implement secure transport is TLS [RFC5246]. 914 The NETCONF access control model [RFC8341] provides the means to 915 restrict access for particular NETCONF users to a preconfigured 916 subset of all available NETCONF protocol operations and content. 918 A number of configuration data nodes defined in this document are 919 writable/deletable (i.e., "config true") These data nodes may be 920 considered sensitive or vulnerable in some network environments. 922 These are the subtrees and data nodes and their 923 sensitivity/vulnerability: 925 Service-Config: 926 - subscriber-l1vc-id 927 - subscriber-l1vc-ep-id-1 928 - subscriber-l1vc-ep-id-2 929 - subscriber-l1vc-ep-UNI-1 930 - subscriber-l1vc-ep-UNI-2 931 - time-start 932 - time-interval 933 - performance-metric 935 6. IANA Considerations 937 This document registers the following namespace URIs in the IETF XML 938 registry [RFC3688]: 940 -------------------------------------------------------------------- 941 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 942 Registrant Contact: The IESG. 943 XML: N/A, the requested URI is an XML namespace. 944 -------------------------------------------------------------------- 946 -------------------------------------------------------------------- 947 URI: urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types 948 Registrant Contact: The IESG. 949 XML: N/A, the requested URI is an XML namespace. 950 -------------------------------------------------------------------- 952 This document registers the following YANG modules in the YANG 953 Module 955 Names registry [RFC7950]: 957 -------------------------------------------------------------------- 958 name: ietf-l1csm 959 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 960 reference: RFC XXXX (TDB) 961 -------------------------------------------------------------------- 963 -------------------------------------------------------------------- 964 name: ietf-l1-mef-service-types 965 namespace: urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types 966 reference: RFC XXXX (TDB) 967 -------------------------------------------------------------------- 969 7. Acknowledgments 971 The authors would like to thank Tom Petch and Italo Busi for their 972 helpful comments and valuable contributions. 974 8. References 976 8.1. Normative References 978 [MEF-L1CS] "Subscriber Layer 1 Connectivity Service Attributes", 979 Working Draft (WD) v0.09 December 13, 2017. 981 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 982 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 984 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 985 the Network Configuration Protocol (NETCONF)", RFC 6020, 986 October 2010. 988 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 989 and A. Bierman, Ed., "Network Configuration Protocol 990 (NETCONF)", RFC 6241, June 2011. 992 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 993 Shell (SSH)", RFC 6242, June 2011. 995 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 996 RFC 7950, August 2016. 998 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 999 Protocol", RFC 8040, January 2017. 1001 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1002 Access Control Model", RFC 8341, March 2018. 1004 8.2. Informative References 1006 [RFC4847] T. Takeda (Editor), "Framework and Requirements for Layer 1007 1 Virtual Private Networks", RFC 4847, April 2007. 1009 [RFC5253] T. Takeda, "Applicability Statement for Layer 1 Virtual 1010 Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. 1012 [Service-Yang] Q. Wu, et al, "Service Models Explained", draft-wu- 1013 opsawg-service-model-explained, Work in progress. 1015 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1016 and R. Wilton, "Network Management Datastore Architecture 1017 (NMDA)", RFC 8342, March 2018, 1019 [RFC6991] J. Schoenwaelder, Ed., "Common YANG Data Types", RFC 6991, 1020 July 2013. 1022 9. Contributors 1024 Contributor's Addresses 1026 I. Busi 1027 Huawei 1028 Email: Italo.Busi@huawei.com 1030 Authors' Addresses 1032 G. Fioccola (Editor) 1033 Telecom Italia 1034 Email: giuseppe.fioccola@telecomitalia.it 1036 K. Lee 1037 KT 1038 Email: kwangkoog.lee@kt.com 1040 Y. Lee (Editor) 1041 Huawei 1042 Email: leeyoung@huawei.com 1044 D. Dhody 1045 Huawei 1046 Email: dhruv.ietf@gmail.com 1048 O. Gonzalez de Dios 1049 Telefonica 1050 Email: oscar.gonzalezdedios@telefonica.com 1052 D. Ceccarelli 1053 Ericsson 1054 Email: daniele.ceccarelli@ericsson.com