idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-02.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 26 instances of too long lines in the document, the longest one being 8 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 294 has weird spacing: '...l1vc-id str...' -- The document date (June 20, 2018) is 2130 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: 'RFC6241' is mentioned on line 876, but not defined == Missing Reference: 'RFC6020' is mentioned on line 252, but not defined == Missing Reference: 'UNI-ID' is mentioned on line 287, but not defined == Missing Reference: 'RFC6536' is mentioned on line 877, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 888, but not defined == Missing Reference: 'RFC7950' is mentioned on line 905, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF-L1CS' Summary: 2 errors (**), 0 flaws (~~), 8 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: December 20, 2018 Y. Lee (Ed.) 6 D. Dhody 7 Huawei 8 O. Gonzalez de-Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 13 June 20, 2018 15 A Yang Data Model for L1 Connectivity Service Model (L1CSM) 17 draft-ietf-ccamp-l1csm-yang-02 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 October 25, 2018. 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 2. Definitions....................................................7 68 3. L1SM YANG Model (Tree Structure)...............................7 69 4. L1SM YANG Code.................................................8 70 5. Security Considerations.......................................21 71 6. IANA Considerations...........................................21 72 7. Acknowledgments...............................................22 73 8. References....................................................23 74 8.1. Normative References.....................................23 75 8.2. Informative References...................................23 76 9. Contributors..................................................23 77 Authors' Addresses...............................................23 79 1. Introduction 81 This document provides a YANG data model for L1VPN Connectivity 82 Service Model (L1CSM). The intent of this document is to provide a 83 transport service model exploiting Yang data model, which can be 84 utilized by a client network controller to initiate a service 85 request connectivity request as well as retrieving service states 86 toward a transport network controller communicating with the client 87 controller via a Netconf/Restconf interface. 89 [RFC4847] provides a framework and service level requirements for 90 Layer 1 Virtual Private Networks (L1VPNs). It classifies service 91 models as management-based service model, signaling-based service 92 model (Basic Mode) and signaling and routing service model (Enhanced 93 Mode). 95 In the management-based service model, customer management systems 96 and provider management systems communicate with each other. 97 Customer management systems access provider management systems to 98 request layer 1 connection setup/deletion between a pair of CEs. 99 Customer management systems may obtain additional information, such 100 as resource availability information and monitoring information, 101 from provider management systems. There is no control message 102 exchange between a CE and PE. 104 In the signaling-based service model (Basic Model), the CE-PE 105 interface's functional repertoire is limited to path setup signaling 106 only. In the Signaling and routing service model (Enhanced Mode), 107 the CE-PE interface provides the signaling capabilities as in the 108 Basic Mode, plus permits limited exchange of information between the 109 control planes of the provider and the customer to help such 110 functions as discovery of customer network routing information 111 (i.e., reachability or TE information in remote customer sites), or 112 parameters of the part of the provider's network dedicated to the 113 customer. 115 The primary focus of this document is to describe L1CS YANG model 116 required for the instantiation of point-to-point L1VPN service. A 117 L1VPN is a service offered by a core layer 1 network to provide 118 layer 1 connectivity between two or more customer sites where the 119 customer has some control over the establishment and type of the 120 connectivity. 122 The model presented in Section 3 is in consistent with [MEF-L1CS]. 124 1.1. Deployment Scenarios 126 Figure 1 depicts a deployment scenario of the L1VPN SDN control- 127 based service model for an external customer instantiating L1 point- 128 to-point connectivity to the provider. 130 +------------+ 131 | Customer | 132 | Service | 133 |Orchestrator| 134 +------------+ 135 | 136 .. .. .. .. ..|.. .. .. .. .. 137 : | : 138 : +--------------------+ : 139 : | | : 140 : | +----------+ | : 141 : | | Network | | : 142 : | | SDN | | : 143 : | |Controller| | : 144 : | |/NMS/EMS | | : 145 : | +----------+ | : 146 : | | : 147 : | | : 148 +----+ : +----+ +----+ +----+ : +----+ 149 | CE |----:---| PE |----| P |----| PE |---:---| CE | 150 +----+ : +----+ +----+ +----+ : +----+ 151 : | | : 152 : | | : 153 : +--------------------+ : 154 : | | : 155 : |<-Provider network->| : 157 Customer Customer 158 Interface Interface 160 Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: External Customer 162 With this scenario, the customer service orchestrator interfaces 163 with the network SDN controller of the provider using Customer 164 Service Model as defined in [Service-Yang]. 166 Figure 2 depicts another deployment scenario for internal customer 167 (e.g., higher-layer service management department(s)) interfacing 168 the layer 1 transport network department. With this scenario, a 169 multi-service backbone is characterized such that each service 170 department of a provider (e.g., L2/3 services) that receives the 171 same provider's L1VPN service provides a different kind of higher- 172 layer service. The customer receiving the L1VPN service (i.e., each 173 service department) can offer its own services, whose payloads can 174 be any layer (e.g., ATM, IP, TDM). The layer 1 transport network and 175 each service network belong to the same organization, but may be 176 managed separately. The Service SDN Controller is the 177 control/management entity owned by higher-layer service department 178 (e.g., L2/3 VPN) whereas the Network SDN Controller is the 179 control/management entity responsible for Layer 1 connectivity 180 service. The CE's in Figure 2 are L2/3 devices that interface with 181 L1 PE devices. 183 +----------+ 184 | Service | 185 | SDN | 186 |Controller| 187 |/EMS/NMS | 188 | for L2/3 | 189 +----------+ 190 | 191 | 192 | 193 +--------------------+ 194 | | 195 | +----------+ | 196 | | Network | | 197 | | SDN | | 198 | |Controller| | 199 | |/EMS/NMS | | 200 | | for L1VPN| | 201 | +----------+ | 202 | | 203 | | 204 +----+ +----+ +----+ +----+ +----+ 205 | CE |--------| PE |----| P |----| PE |------| CE | 206 +----+ +----+ +----+ +----+ +----+ 207 | | | | 208 | | | | 209 | +--------------------+ | 210 | | | | 211 | |<------------------>| | 212 | Provider Network | 213 | For Layer 1 | 214 |<------------------------------------------>| 215 Provider Network for L2/3 217 Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: Internal Customer 218 The benefit is that the same layer 1 transport network resources are 219 shared by multiple services. A large capacity backbone network 220 (data plane) can be built economically by having the resources 221 shared by multiple services usually with flexibility to modify 222 topologies, while separating the control functions for each service 223 department. Thus, each customer can select a specific set of 224 features that are needed to provide their own service [RFC4847]. 226 1.2. Terminology 228 Refer to [RFC4847] and [RFC5253] for the key terms used in this 229 document. 231 The following terms are defined in [RFC6241] and are not redefined 232 here: 234 o client 236 o configuration data 238 o server 240 o state data 242 The following terms are defined in [RFC6020] and are not redefined 243 here: 245 o augment 247 o data model 249 o data node 251 The terminology for describing YANG data models is found in 252 [RFC6020]. 254 1.3. Tree diagram 256 A simplified graphical representation of the data model is presented 257 in Section x. 259 The meaning of the symbols in these diagrams is as follows: 261 o Brackets "[" and "]" enclose list keys. 263 o Curly braces "{" and "}" contain names of optional features that 264 make the corresponding node conditional. 266 o Abbreviations before data node names: "rw" means configuration 267 (read-write), and "ro" state data (read-only). 269 o Symbols after data node names: "?" means an optional node and "*" 270 denotes a "list" or "leaf-list". 272 o Parentheses enclose choice and case nodes, and case nodes are also 273 marked with a colon (":"). 275 o Ellipsis ("...") stands for contents of subtrees that are not 276 shown. 278 2. Definitions 280 TDB 282 3. L1SM YANG Model (Tree Structure) 284 module: ietf-l1csm 285 +--rw l1cs 286 +--rw access 287 | +--rw uni-list* [UNI-ID] 288 | +--rw UNI-ID string 289 | +--rw protocol? identityref 290 | +--rw coding? identityref 291 | +--rw optical_interface? identityref 292 +--rw service 293 +--rw service-list* [subscriber-l1vc-id] 294 +--rw subscriber-l1vc-id string 295 +--rw service-config 296 +--rw subscriber-l1vc-id? string 297 +--rw subscriber-l1vc-ep-id-1? string 298 +--rw subscriber-l1vc-ep-id-2? string 299 +--rw subscriber-l1vc-ep-UNI-1? -> /l1cs/access/uni- 300 list/UNI-ID 301 +--rw subscriber-l1vc-ep-UNI-2? -> /l1cs/access/uni- 302 list/UNI-ID 303 +--rw time-start? yang:date-and-time 304 +--rw time-interval? int64 305 +--rw performance-metric? identityref 307 4. L1SM YANG Code 309 The YANG code is as follows: 311 file "ietf-l1csm@2018-06-20.yang" 313 module ietf-l1csm { 314 yang-version 1.1; 315 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 317 prefix "l1csm"; 319 import ietf-yang-types { 320 prefix "yang"; 321 } 323 import ietf-l1-mef-service-types { 324 prefix "l1-st"; 325 } 327 organization 328 "Internet Engineering Task Force (IETF) CCAMP WG"; 330 contact 332 "Editor: G. Fioccolla (giuseppe.fioccola@telecomitalia.it) 333 Editor: K. Lee (kwangkoog.lee@kt.com) 334 Editor: Y. Lee (leeyoung@huawei.com) 335 Editor: D. Dhody (dhruv.ietf@gmail.com) 336 Editor: O. Gonzalez de-Dio(oscar.gonzalezdedios@telefonica.com) 337 Editor: D. Ceccarelli (daniele.ceccarelli@ericsson.com)"; 339 description 340 "this module describes Layer 1 connectivity service 341 model for subscriber Layer 1 Connectivity Services 342 and Attributes"; 344 revision 2018-06-20 { 345 description 346 "updated version to incorporate MEF 347 comments"; 348 reference "to add the draft name"; 350 } 352 revision 2018-04-11 { 353 description 354 "Initial revision."; 355 reference "to add the draft name"; 356 } 358 grouping protocol-coding-optical_interface { 359 description 360 "describes "; 361 leaf protocol { 362 type identityref { 363 base "l1-st:protocol-type"; 364 } 366 description "List of physical layer L1VC 367 client protocol"; 368 } 370 leaf coding { 371 type identityref { 372 base "l1-st:coding-func"; 373 } 375 description "coding function"; 376 } 378 leaf optical_interface { 379 type identityref { 380 base "l1-st:optical-interface-func"; 381 } 383 description "optical-interface-function"; 384 } 385 } 387 grouping uni-attributes { 388 description 389 "uni-service-attributes"; 391 leaf UNI-ID { 392 type string; 393 description "the UNI id of UNI 394 Service Attributes"; 395 } 397 uses protocol-coding-optical_interface; 399 } 401 grouping subscriber-l1vc-sls-service-attribute { 402 description 403 "The value of the Subscriber L1VC SLS 404 (Service Level Specification) Service Attribute expressed in a 3-tuple of the 405 form."; 407 leaf time-start { 408 type yang:date-and-time; 409 description "a time that represent 410 the date and time for the start of the SLS"; 411 } 413 leaf time-interval { 414 type int64; 415 units seconds; 416 description "a time interval 417 (e.g., 1 month) that is used in conjunction wuth time-start to specify a 418 contiguous sequence of time intervals T for determining when performance 419 objectives are met."; 420 } 422 leaf performance-metric { 423 type identityref { 424 base "l1-st:performance-" 425 +"metriclist"; 426 } 428 description "list of performance 429 metric"; 430 } 431 } 433 grouping subscriber-l1vc-service-attributes { 434 description 435 "subscriber layer 1 connection service 436 service level"; 437 leaf subscriber-l1vc-id { 438 type string; 439 description "subscriber L1VC identifier"; 440 } 442 leaf subscriber-l1vc-ep-id-1 { 443 type string; 444 description "subscriber end point ID"; 445 } 447 leaf subscriber-l1vc-ep-id-2 { 448 type string; 449 description "subscriber end point ID"; 450 } 452 leaf subscriber-l1vc-ep-UNI-1 { 453 type leafref { 454 path "/l1cs/access/uni-list/UNI-ID"; 455 } 456 description "this is one end of subscriber L1VC end 457 point ID value = UNI-1"; 458 } 460 leaf subscriber-l1vc-ep-UNI-2 { 461 type leafref { 462 path "/l1cs/access/uni-list/UNI-ID"; 463 } 464 description "this is the other end of subscriber 465 L1VC end point ID value = UNI-2"; 466 } 468 uses subscriber-l1vc-sls-service-attribute; 469 } 471 grouping subscriber-attributes { 472 description 473 "subscriber attributes"; 475 uses subscriber-l1vc-service-attributes; 477 } 479 container l1cs { 480 description 481 "serves as a top-level container for a list of layer 1 482 connection services (l1cs)"; 484 container access { 485 description "UNI configurations"; 487 list uni-list { 488 key "UNI-ID"; 489 description "uni identifier"; 490 uses uni-attributes { 491 description "UNI attributes 492 information"; 493 } 494 } 496 } 498 container service { 499 description "L1VC service"; 500 list service-list { 501 key "subscriber-l1vc-id"; 502 description 503 "an unique identifier of a service"; 505 leaf subscriber-l1vc-id { 506 type string; 507 description "a unique service identifier for 508 L1VC."; 509 } 510 container service-config { 511 description "service-config container"; 513 uses subscriber-attributes; 515 }//end of service-config 516 }//end of service list 517 } //end of service container 519 }//service top container 520 } 522 524 file "ietf-l1-mef-service-types@2018-06-20.yang" 526 module ietf-l1-mef-service-types { 527 namespace "urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types"; 528 prefix "l1-st"; 530 organization 531 "IETF CCAMP Working Group"; 532 contact 533 "WG Web: 534 WG List: 536 Editor: G. Fioccolla(giuseppe.fioccola@telecomitalia.it) 537 Editor: K. Lee (kwangkoog.lee@kt.com) 538 Editor: Y. Lee (leeyoung@huawei.com) 539 Editor: D. Dhody (dhruv.ietf@gmail.com) 540 Editor: O. Gonzalez de-Dios(oscar.gonzalezdedios@telefonica.com) 541 Editor: D. Ceccarelli(daniele.ceccarelli@ericsson.com)"; 543 description 544 "This module defines L1 service types based on MEF subscriber Layer 1 545 Connectivity Service Attribute."; 547 revision "2019-06-20" { 548 description 549 "Revision 0.2"; 550 reference "TBD"; 551 } 553 revision "2018-04-11" { 554 description 555 "Revision 0.1"; 556 reference "TBD"; 557 } 559 identity protocol-type { 560 description 561 "base identity from which client protocol type is derived."; 562 } 564 identity aGigE { 565 base "protocol-type"; 566 description 567 "GigE protocol type"; 568 } 570 identity a10GigE_WAN { 571 base "protocol-type"; 572 description 573 "10GigE-WAN protocol type"; 574 } 576 identity a10GigE_LAN { 577 base "protocol-type"; 578 description 579 "10GigE-LAN protocol type"; 580 } 582 identity a40GigE { 583 base "protocol-type"; 584 description 585 "40GigE protocol type"; 586 } 588 identity a100GigE { 589 base "protocol-type"; 590 description 591 "100GigE protocol type"; 592 } 594 identity FC-100 { 595 base "protocol-type"; 596 description 597 "Fiber Channel - 100 protocol type"; 598 } 600 identity FC-200 { 601 base "protocol-type"; 602 description 603 "Fiber Channel - 200 protocol type"; 604 } 606 identity FC-400 { 607 base "protocol-type"; 608 description 609 "Fiber Channel - 400 protocol type"; 610 } 612 identity FC-800 { 613 base "protocol-type"; 614 description 615 "Fiber Channel - 800 protocol type"; 616 } 618 identity FC-1200 { 619 base "protocol-type"; 620 description 621 "Fiber Channel - 1200 protocol type"; 622 } 624 identity FC-1600 { 625 base "protocol-type"; 626 description 627 "Fiber Channel - 1600 protocol type"; 628 } 630 identity FC-3200 { 631 base "protocol-type"; 632 description 633 "Fiber Channel - 3200 protocol type"; 634 } 636 identity STM-1 { 637 base "protocol-type"; 638 description 639 "SDH STM-1 protocol type"; 640 } 642 identity STM-4 { 643 base "protocol-type"; 644 description 645 "SDH STM-4 protocol type"; 646 } 648 identity STM-16 { 649 base "protocol-type"; 650 description 651 "SDH STM-16 protocol type"; 653 } 655 identity STM-64 { 656 base "protocol-type"; 657 description 658 "SDH STM-64 protocol type"; 659 } 661 identity STM-256 { 662 base "protocol-type"; 663 description 664 "SDH STM-256 protocol type"; 665 } 667 identity OC-3 { 668 base "protocol-type"; 669 description 670 "SONET OC-3 protocol type"; 671 } 673 identity OC-12 { 674 base "protocol-type"; 675 description 676 "SONET OC-12 protocol type"; 677 } 679 identity OC-48 { 680 base "protocol-type"; 681 description 682 "SONET OC-48 protocol type"; 683 } 685 identity OC-192 { 686 base "protocol-type"; 687 description 688 "SONET OC-192 protocol type"; 689 } 691 identity OC-768 { 692 base "protocol-type"; 693 description 694 "SONET OC-768 protocol type"; 695 } 697 identity coding-func { 698 description 699 "base identity from which coding func is derived."; 700 } 702 identity a1000X-PCS-36 { 703 base "coding-func"; 704 description 705 "PCS clause 36 coding function that 706 corresponds to 1000BASE-X"; 707 } 709 identity a10GW-PCS-49-WIS-50 { 710 base "coding-func"; 711 description 712 "PCS clause 49 and WIS clause 50 coding func 713 that corresponds to 10GBASE-W (WAN PHY)"; 714 } 716 identity a10GR-PCS-49 { 717 base "coding-func"; 718 description 719 "PCS clause 49 coding function that 720 corresponds to 10GBASE-R (LAN PHY)"; 721 } 723 identity a40GR-PCS-82 { 724 base "coding-func"; 725 description 726 "PCS clause 82 coding function that 727 corresponds to 40GBASE-R"; 728 } 730 identity a100GR-PCS-82 { 731 base "coding-func"; 732 description 733 "PCS clause 82 coding function that 734 corresponds to 100GBASE-R"; 735 } 737 /* coding func needs to expand for Fiber Channel, SONET, SDH */ 739 identity optical-interface-func { 740 description 741 "base identity from which optical-interface-function is derived."; 743 } 745 identity SX-PMD-clause-38 { 746 base "optical-interface-func"; 747 description 748 "SX-PMD-clause-38 Optical Interface function 749 for 1000BASE-X PCS-36"; 750 } 752 identity LX-PMD-clause-38 { 753 base "optical-interface-func"; 754 description 755 "LX-PMD-clause-38 Optical Interface function 756 for 1000BASE-X PCS-36"; 757 } 759 identity LX10-PMD-clause-59 { 760 base "optical-interface-func"; 761 description 762 "LX10-PMD-clause-59 Optical Interface 763 function for 1000BASE-X PCS-36"; 764 } 766 identity BX10-PMD-clause-59 { 767 base "optical-interface-func"; 768 description 769 "BX10-PMD-clause-59 Optical Interface 770 function for 1000BASE-X PCS-36"; 771 } 773 identity LW-PMD-clause-52 { 774 base "optical-interface-func"; 775 description 776 "LW-PMD-clause-52 Optical Interface function 777 for 10GBASE-W PCS-49-WIS-50"; 778 } 780 identity EW-PMD-clause-52 { 781 base "optical-interface-func"; 782 description 783 "EW-PMD-clause-52 Optical Interface function 784 for 10GBASE-W PCS-49-WIS-50"; 785 } 787 identity LR-PMD-clause-52 { 788 base "optical-interface-func"; 789 description 790 "LR-PMD-clause-52 Optical Interface function 791 for 10GBASE-R PCS-49"; 792 } 794 identity ER-PMD-clause-52 { 795 base "optical-interface-func"; 796 description 797 "ER-PMD-clause-52 Optical Interface function 798 for 10GBASE-R PCS-49"; 799 } 801 identity LR4-PMD-clause-87 { 802 base "optical-interface-func"; 803 description 804 "LR4-PMD-clause-87 Optical Interface function 805 for 40GBASE-R PCS-82"; 806 } 808 identity ER4-PMD-clause-87 { 809 base "optical-interface-func"; 810 description 811 "ER4-PMD-clause-87 Optical Interface function 812 for 40GBASE-R PCS-82"; 813 } 815 identity FR-PMD-clause-89 { 816 base "optical-interface-func"; 817 description 818 "FR-PMD-clause-89 Optical Interface function 819 for 40GBASE-R PCS-82"; 820 } 822 identity LR4-PMD-clause-88 { 823 base "optical-interface-func"; 824 description 825 "LR4-PMD-clause-88 Optical Interface function 826 for 100GBASE-R PCS-82"; 827 } 829 identity ER4-PMD-clause-88 { 830 base "optical-interface-func"; 831 description 832 "ER4-PMD-clause-88 Optical Interface function 833 for 100GBASE-R PCS-82"; 834 } 836 /* optical interface func needs to expand for Fiber Channel, SONET 837 and SDH */ 839 identity performance-metriclist { 840 description "list of performance metric"; 841 } 843 identity One-way-Delay { 844 base "performance-metriclist"; 845 description "one-way-delay"; 846 } 848 identity One-way-Errored-Second { 849 base "performance-metriclist"; 850 description "one-way-errored-second"; 851 } 853 identity One-way-Severely-Errored-Second { 854 base "performance-metriclist"; 855 description "one-way-severely-errored-second"; 856 } 858 identity One-way-Unavailable-Second { 859 base "performance-metriclist"; 860 description "one-way-unavailable-second"; 861 } 863 identity One-way-Availability { 864 base "performance-metriclist"; 865 description "one-way-availability"; 866 } 868 } 870 872 5. Security Considerations 874 The configuration, state, and action data defined in this document 875 are designed to be accessed via a management protocol with a secure 876 transport layer, such as NETCONF [RFC6241]. The NETCONF access 877 control model [RFC6536] provides the means to restrict access for 878 particular NETCONF users to a preconfigured subset of all available 879 NETCONF protocol operations and content. 881 A number of configuration data nodes defined in this document are 882 writable/deletable (i.e., "config true") These data nodes may be 883 considered sensitive or vulnerable in some network environments. 885 6. IANA Considerations 887 This document registers the following namespace URIs in the IETF XML 888 registry [RFC3688]: 890 -------------------------------------------------------------------- 891 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 892 Registrant Contact: The IESG. 893 XML: N/A, the requested URI is an XML namespace. 894 -------------------------------------------------------------------- 896 -------------------------------------------------------------------- 897 URI: urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types 898 Registrant Contact: The IESG. 899 XML: N/A, the requested URI is an XML namespace. 900 -------------------------------------------------------------------- 902 This document registers the following YANG modules in the YANG 903 Module 905 Names registry [RFC7950]: 907 -------------------------------------------------------------------- 908 name: ietf-l1csm 909 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 910 reference: RFC XXXX (TDB) 911 -------------------------------------------------------------------- 912 -------------------------------------------------------------------- 913 name: ietf-l1-mef-service-types 914 namespace: urn:ietf:params:xml:ns:yang:ietf-l1-mef-service-types 915 reference: RFC XXXX (TDB) 916 -------------------------------------------------------------------- 918 7. Acknowledgments 920 The authors would like to thank Italo Busi for his helpful comments 921 and valuable contributions. 923 8. References 925 8.1. Normative References 927 [MEF-L1CS] "Subscriber Layer 1 Connectivity Service Attributes", 928 Working Draft (WD) v0.09 December 13, 2017. 930 8.2. Informative References 932 [RFC4847] T. Takeda (Editor), "Framework and Requirements for Layer 933 1 Virtual Private Networks", RFC 4847, April 2007. 935 [RFC5253] T. Takeda, "Applicability Statement for Layer 1 Virtual 936 Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. 938 [Service-Yang] Q. Wu, et al, "Service Models Explained", draft-wu- 939 opsawg-service-model-explained, Work in progress. 941 9. Contributors 943 Contributor's Addresses 945 I. Busi 946 Huawei 947 Email: Italo.Busi@huawei.com 949 Authors' Addresses 951 G. Fioccola (Editor) 952 Telecom Italia 953 Email: giuseppe.fioccola@telecomitalia.it 955 K. Lee 956 KT 957 Email: kwangkoog.lee@kt.com 959 Y. Lee (Editor) 960 Huawei 961 Email: leeyoung@huawei.com 963 D. Dhody 964 Huawei 965 Email: dhruv.ietf@gmail.com 967 O. Gonzalez de Dios 968 Telefonica 969 Email: oscar.gonzalezdedios@telefonica.com 971 D. Ceccarelli 972 Ericsson 973 Email: daniele.ceccarelli@ericsson.com