idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-08.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 9 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 -- The document date (September 12, 2018) is 2053 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: 'MEF-L1CS' is mentioned on line 131, but not defined == Missing Reference: 'RFC8340' is mentioned on line 270, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 282, but not defined == Missing Reference: 'RFC3688' is mentioned on line 1017, but not defined == Unused Reference: 'MEF63' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'G.709' is defined on line 1105, but no explicit reference was found in the text == Unused Reference: 'IEEE802.3' is defined on line 1108, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF63' Summary: 1 error (**), 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: March 12, 2019 Y. Lee (Ed.) 6 D. Dhody 7 Huawei 8 O. Gonzalez de-Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 13 September 12, 2018 15 A YANG Data Model for L1 Connectivity Service Model (L1CSM) 17 draft-ietf-ccamp-l1csm-yang-08 19 Abstract 21 This document provides a YANG data model for Layer 1 Connectivity 22 Service Model (L1CSM). The intent of this document is to provide a 23 transport service model exploiting YANG data model, which can be 24 utilized by a client network controller to initiate a service 25 request connectivity request as well as retrieving service states 26 toward a transport network controller communicating with the client 27 controller. This YANG model is NMDA-compliant. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with 32 the provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on March 12 2019. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction...................................................2 69 1.1. Deployment Scenarios......................................4 70 1.2. Terminology...............................................6 71 1.3. Tree diagram..............................................7 72 1.4. Prefixes in Data Node Names...............................7 73 2. Definitions....................................................7 74 3. L1SM YANG Model (Tree Structure)...............................8 75 4. L1SM YANG Code.................................................8 76 5. JSON Example..................................................21 77 6. Security Considerations.......................................22 78 7. IANA Considerations...........................................23 79 8. Acknowledgments...............................................24 80 9. References....................................................25 81 9.1. Normative References.....................................25 82 9.2. Informative References...................................25 83 10. Contributors.................................................26 84 Authors' Addresses...............................................26 86 1. Introduction 88 This document provides a YANG data model for L1VPN Connectivity 89 Service Model (L1CSM) which can be classified as Network Service 90 YANG module per [RFC8199]. The intent of this document is to provide 91 a transport service model exploiting YANG data model, which can be 92 utilized by a client network controller to initiate a service 93 request connectivity request as well as retrieving service states 94 toward a transport network controller communicating with the client 95 controller via a NETCONF [RFC8341] or a RESTCONF [RFC8040] 96 interface. 98 [RFC4847] provides a framework and service level requirements for 99 Layer 1 Virtual Private Networks (L1VPNs). It classifies service 100 models as management-based service model, signaling-based service 101 model (Basic Mode) and signaling and routing service model (Enhanced 102 Mode). 104 In the management-based service model, customer management systems 105 and provider management systems communicate with each other. 106 Customer management systems access provider management systems to 107 request layer 1 connection setup/deletion between a pair of CEs. 108 Customer management systems may obtain additional information, such 109 as resource availability information and monitoring information, 110 from provider management systems. There is no control message 111 exchange between a CE and PE. 113 In the signaling-based service model (Basic Model), the CE-PE 114 interface's functional repertoire is limited to path setup signaling 115 only. In the Signaling and routing service model (Enhanced Mode), 116 the CE-PE interface provides the signaling capabilities as in the 117 Basic Mode, plus permits limited exchange of information between the 118 control planes of the provider and the customer to help such 119 functions as discovery of customer network routing information 120 (i.e., reachability or TE information in remote customer sites), or 121 parameters of the part of the provider's network dedicated to the 122 customer. 124 The primary focus of this document is to describe L1CS YANG model 125 required for the instantiation of point-to-point L1VPN service. A 126 L1VPN is a service offered by a core layer 1 network to provide 127 layer 1 connectivity between two or more customer sites where the 128 customer has some control over the establishment and type of the 129 connectivity. 131 The data model presented in Section 3 is in consistent with [MEF- 132 L1CS]. The data model includes configuration and state data 133 according to the new Network Management Datastore Architecture 134 [RFC8342]. 136 1.1. Deployment Scenarios 138 Figure 1 depicts a deployment scenario of the L1VPN SDN control- 139 based service model for an external customer instantiating L1 point- 140 to-point connectivity to the provider. 142 +------------+ 143 | Customer | 144 | Service | 145 |Orchestrator| 146 +------------+ 147 | 148 .. .. .. .. .. .|.. .. .. .. .. .. 149 : | : 150 : +--------------------+ : 151 : | | : 152 : | +----------+ | : 153 : | | Network | | : 154 : | | SDN | | : 155 : | |Controller| | : 156 : | |/NMS/EMS | | : 157 : | +----------+ | : 158 : | | : 159 : | | : 160 +----+ : +----+ +----+ +----+ : +----+ 161 | CE |----:---| PE |----| P |----| PE |---:---| CE | 162 +----+ : +----+ +----+ +----+ : +----+ 163 : | | : 164 : | | : 165 : +--------------------+ : 166 : | | : 167 : |<-Provider network->| : 169 Customer Customer 170 Interface Interface 172 Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: External Customer 173 With this scenario, the customer service orchestrator interfaces 174 with the network SDN controller of the provider using Customer 175 Service Model as defined in [RFC8309]. 177 Figure 2 depicts another deployment scenario for internal customer 178 (e.g., higher-layer service management department(s)) interfacing 179 the layer 1 transport network department. With this scenario, a 180 multi-service backbone is characterized such that each service 181 department of a provider (e.g., L2/3 services) that receives the 182 same provider's L1VPN service provides a different kind of higher- 183 layer service. The customer receiving the L1VPN service (i.e., each 184 service department) can offer its own services, whose payloads can 185 be any layer (e.g., ATM, IP, TDM). The layer 1 transport network and 186 each service network belong to the same organization, but may be 187 managed separately. The Service SDN Controller is the 188 control/management entity owned by higher-layer service department 189 (e.g., L2/3 VPN) whereas the Network SDN Controller is the 190 control/management entity responsible for Layer 1 connectivity 191 service. The CE's in Figure 2 are L2/3 devices that interface with 192 L1 PE devices. 194 +----------+ 195 | Service | 196 | SDN | 197 |Controller| 198 |/EMS/NMS | 199 | for L2/3 | 200 +----------+ 201 | 202 | 203 | 205 +--------------------+ 206 | | 207 | +----------+ | 208 | | Network | | 209 | | SDN | | 210 | |Controller| | 211 | |/EMS/NMS | | 212 | | for L1VPN| | 213 | +----------+ | 214 | | 215 | | 216 +----+ +----+ +----+ +----+ +----+ 217 | CE |--------| PE |----| P |----| PE |------| CE | 218 +----+ +----+ +----+ +----+ +----+ 219 | | | | 220 | | | | 221 | +--------------------+ | 222 | | | | 223 | |<------------------>| | 224 | Provider Network | 225 | For Layer 1 | 226 |<------------------------------------------>| 227 Provider Network for L2/3 229 Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: Internal Customer 231 The benefit is that the same layer 1 transport network resources are 232 shared by multiple services. A large capacity backbone network 233 (data plane) can be built economically by having the resources 234 shared by multiple services usually with flexibility to modify 235 topologies, while separating the control functions for each service 236 department. Thus, each customer can select a specific set of 237 features that are needed to provide their own service [RFC4847]. 239 1.2. Terminology 241 Refer to [RFC4847] and [RFC5253] for the key terms used in this 242 document. 244 The following terms are defined in [RFC7950] and are not redefined 245 here: 247 o client 249 o server 250 o augment 252 o data model 254 o data node 256 The following terms are defined in [RFC6241] and are not redefined 257 here: 259 o configuration data 261 o state data 263 The terminology for describing YANG data models is found in 264 [RFC7950]. 266 1.3. Tree diagram 268 A simplified graphical representation of the data model is used in 269 chapter 3 of this this document. The meaning of the symbols in 270 these diagrams is defined in [RFC8340]. 272 1.4. Prefixes in Data Node Names 274 In this document, names of data nodes and other data model objects 275 are prefixed using the standard prefix associated with the 276 corresponding YANG imported modules, as shown in Table 1. 278 +---------+------------------------------+-----------------+ 279 | Prefix | YANG module | Reference | 280 +---------+------------------------------+-----------------+ 281 | l1csm | ietf-l1cms | [RFC XXXX] | 282 | l1-st | ietf-l1-service-types | [RFC XXXX] | 283 | yang | ietf-yang-types | [RFC6991] | 284 +---------+------------------------------+-----------------+ 286 Table 1: Prefixes and corresponding YANG modules 288 Note: The RFC Editor will replace XXXX with the number assigned to 289 the RFC once this draft becomes an RFC. 291 2. Definitions 293 L1VC Layer 1 Virtual Connection 295 SLS Service Level Specification 296 UNI User Network Interface 298 PE Provider Edge 300 CE Customer Edge 302 EP End Point 304 P Protocol 306 C Coding 308 O Optical Interface 310 3. L1SM YANG Model (Tree Structure) 312 module: ietf-l1csm 313 +--rw l1-connectivity 314 +--rw access 315 | +--rw unis 316 | +--rw uni* [id] 317 | +--rw id string 318 | +--rw protocol? identityref 319 | +--rw coding? identityref 320 | +--rw optical-interface? identityref 321 +--rw services 322 +--rw service* [service-id] 323 +--rw service-id string 324 +--rw endpoint-1 325 | +--rw id string 326 | +--rw uni -> /l1-connectivity/access/unis/uni/id 327 +--rw endpoint-2 328 | +--rw id string 329 | +--rw uni -> /l1-connectivity/access/unis/uni/id 330 +--rw start-time? yang:date-and-time 331 +--rw time-interval? int32 332 +--rw performance-metric* identityref 334 4. L1SM YANG Code 336 The YANG code is as follows: 338 file "ietf-l1csm@2018-09-12.yang" 340 module ietf-l1csm { 341 yang-version 1.1; 342 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 344 prefix "l1csm"; 345 import ietf-yang-types { 346 prefix "yang"; 347 reference "RFC 6991 - Common YANG Data Types"; 348 } 350 import ietf-l1-service-types { 351 prefix "l1-st"; 352 reference "RFC XXXX - A YANG Data Model for L1 Connectivity 353 Service Model (L1CSM)"; 354 } 356 organization 357 "Internet Engineering Task Force (IETF) CCAMP WG"; 359 contact 361 "Editor: G. Fioccolla (giuseppe.fioccola@telecomitalia.it) 362 Editor: K. Lee (kwangkoog.lee@kt.com) 363 Editor: Y. Lee (leeyoung@huawei.com) 364 Editor: D. Dhody (dhruv.ietf@gmail.com) 365 Editor: O. G. de-Dios (oscar.gonzalezdedios@telefonica.com) 366 Editor: D. Ceccarelli (daniele.ceccarelli@ericsson.com)"; 368 description 369 "This module describes L1 connectivity service based on MEF 63: 370 Subscriber Layer 1 Service Attribute Technical Specification. 371 Refer to MEF 63 for all terms and the original references 372 used in the module. 374 Copyright (c) 2018 IETF Trust and the persons identified as 375 authors of the code. All rights reserved. 376 Redistribution and use in source and binary forms, with or 377 without modification, is permitted pursuant to, and subject 378 to the license terms contained in, the Simplified BSD 379 License set forth in Section 4.c of the IETF Trust's Legal 380 Provisions Relating to IETF Documents 381 (http://trustee.ietf.org/license-info). 383 This version of this YANG module is part of RFC XXXX; see 384 the RFC itself for full legal notices."; 386 revision "2018-09-12" { 387 description "Initial revision."; 388 reference "RFC XXXX: A YANG Data Model for L1 Connectivity 389 Service Model (L1CSM)"; 390 // Note: The RFC Editor will replace XXXX with the number 391 // assigned to the RFC once this draft becomes an RFC. 392 } 394 grouping protocol-coding-optical-interface { 395 description 396 "describes where p:protocol type; c:coding 397 function; o:optical interface function"; 398 reference "MEF 63"; 399 leaf protocol { 400 type identityref { 401 base "l1-st:protocol-type"; 402 } 403 description 404 "List of physical layer L1VC clientprotocol"; 406 } 407 leaf coding { 408 type identityref { 409 base "l1-st:coding-func"; 410 } 411 description "coding function"; 412 } 414 leaf optical-interface { 415 type identityref { 416 base "l1-st:optical-interface-func"; 417 } 418 description "optical-interface-function"; 419 } 421 } 423 grouping subscriber-l1vc-sls-service-attribute { 424 description 425 "The value of the Subscriber L1VC SLS (Service Level 426 Specification) Service Attribute"; 427 reference "MEF 63"; 429 leaf start-time { 430 type yang:date-and-time; 431 description "a time that represent the date and time 432 for the start of the SLS"; 433 } 435 leaf time-interval { 436 type int32; 437 units seconds; 438 description "a time interval (e.g., 2,419,200 seconds 439 which is 28 days) that is used in 440 conjunction wuth time-start to specify a 441 contiguous sequence of time intervals T for 442 determining when performance objectives are 443 met."; 444 } 446 leaf-list performance-metric { 447 type identityref { 448 base "l1-st:performance-metric"; 449 } 450 description "list of performance metric"; 451 } 453 } 455 grouping subscriber-l1vc-endpoint-attributes { 456 description 457 "subscriber layer 1 connection endpoint attributes"; 458 reference "MEF 63"; 460 container endpoint-1 { 461 description "One end of UNI id's - string and id"; 462 leaf id { 463 type string; 464 mandatory true; 465 description "subscriber end point ID of one end"; 466 } 468 leaf uni { 469 type leafref { 470 path "/l1-connectivity/access/unis/uni/id"; 471 } 472 mandatory true; 473 description "this is one end of subscriber L1VC end point 474 ID value = UNI-1"; 475 } 476 } 477 container endpoint-2 { 478 description "One end of UNI id's - string and id"; 479 leaf id { 480 type string; 481 mandatory true; 482 description "subscriber end point ID of the other end"; 483 } 484 leaf uni { 485 type leafref { 486 path "/l1-connectivity/access/unis/uni/id"; 487 } 488 mandatory true; 489 description "this is one other end of subscriber L1VC end point 490 ID value = UNI-2"; 491 } 492 } 493 } 495 container l1-connectivity { 496 description 497 "serves as a top-level container for a list of layer 1 498 connection services (l1cs)"; 500 container access { 501 description "UNI configurations for access networks"; 503 container unis { 504 description "the list of UNI's to be configured"; 506 list uni { 507 key "id"; 508 description "UNI identifier"; 509 leaf id { 510 type string; 511 description "the UNI id of UNI Service Attributes"; 512 } 514 uses protocol-coding-optical-interface; 515 } 516 } 517 } 519 container services { 520 description "L1VC services"; 521 list service { 522 key "service-id"; 523 description 524 "an unique identifier of a subscriber L1VC service"; 526 leaf service-id { 527 type string; 528 mandatory true; 529 description "a unique service identifier for 530 subscriber L1VC."; 531 } 532 uses subscriber-l1vc-endpoint-attributes; 533 uses subscriber-l1vc-sls-service-attribute; 535 }//end of service list 536 } //end of services container 537 }//end of l1 connectivity top container 538 } 540 542 file "ietf-l1-service-types@2018-09-12.yang" 544 module ietf-l1-service-types { 545 namespace "urn:ietf:params:xml:ns:yang:ietf-l1-service-types"; 546 prefix "l1-st"; 548 organization 549 "IETF CCAMP Working Group"; 550 contact 551 "WG Web: 552 WG List: 554 Editor: G. Fioccolla(giuseppe.fioccola@telecomitalia.it) 555 Editor: K. Lee (kwangkoog.lee@kt.com) 556 Editor: Y. Lee (leeyoung@huawei.com) 557 Editor: D. Dhody (dhruv.ietf@gmail.com) 558 Editor: O. G. de-Dios(oscar.gonzalezdedios@telefonica.com) 559 Editor: D. Ceccarelli(daniele.ceccarelli@ericsson.com)"; 561 description 562 "This module defines L1 service types based on MEF 63: 563 Subscriber Layer 1 Service Attribute Technical Specification. 564 Refer to MEF 63 for all terms and the original references 565 used in the module. As for the protocol-type, refer also to 566 the client-type in G.709. 568 Copyright (c) 2018 IETF Trust and the persons identified as 569 authors of the code. All rights reserved. 570 Redistribution and use in source and binary forms, with or 571 without modification, is permitted pursuant to, and subject 572 to the license terms contained in, the Simplified BSD 573 License set forth in Section 4.c of the IETF Trust's Legal 574 Provisions Relating to IETF Documents 575 (http://trustee.ietf.org/license-info). 577 This version of this YANG module is part of RFC XXXX; see 578 the RFC itself for full legal notices."; 579 revision "2018-09-12" { 580 description "Initial revision."; 581 reference "RFC XXXX: A Yang Data Model for L1 Connectivity 582 Service Model (L1CSM)"; 583 // Note: The RFC Editor will replace XXXX with the number 584 // assigned to the RFC once this draft becomes an RFC. 585 } 587 identity protocol-type { 588 description 589 "base identity from which client protocol type is derived."; 590 } 592 identity ETH-1GbE { 593 base "protocol-type"; 594 description 595 "Gigabit Ethernet protocol type"; 596 reference "MEF63 & G.709"; 597 } 599 identity ETH-10GbE-WAN { 600 base "protocol-type"; 601 description 602 "10 Gigabit Ethernet-WAN protocol type"; 603 reference "MEF63 & G.709"; 604 } 606 identity ETH-10GbE-LAN { 607 base "protocol-type"; 608 description 609 "10 Gigabit Ethernet-LAN protocol type"; 610 reference "MEF63 & G.709"; 611 } 613 identity ETH-40GbE { 614 base "protocol-type"; 615 description 616 "40 Gigabit Ethernet protocol type"; 617 reference "MEF63 & G.709"; 618 } 620 identity ETH-100GbE { 621 base "protocol-type"; 622 description 623 "100 Gigabit Ethernet protocol type"; 625 reference "MEF63 & G.709"; 626 } 628 identity FC-100 { 629 base "protocol-type"; 630 description 631 "Fiber Channel - 100 protocol type"; 632 reference "MEF63 & G.709"; 633 } 635 identity FC-200 { 636 base "protocol-type"; 637 description 638 "Fiber Channel - 200 protocol type"; 639 reference "MEF63 & G.709"; 640 } 642 identity FC-400 { 643 base "protocol-type"; 644 description 645 "Fiber Channel - 400 protocol type"; 646 reference "MEF63 & G.709"; 647 } 649 identity FC-800 { 650 base "protocol-type"; 651 description 652 "Fiber Channel - 800 protocol type"; 653 reference "MEF63 & G.709"; 654 } 656 identity FC-1200 { 657 base "protocol-type"; 658 description 659 "Fiber Channel - 1200 protocol type"; 660 reference "MEF63 & G.709"; 661 } 663 identity FC-1600 { 664 base "protocol-type"; 665 description 666 "Fiber Channel - 1600 protocol type"; 667 reference "MEF63 & G.709"; 668 } 670 identity FC-3200 { 671 base "protocol-type"; 672 description 673 "Fiber Channel - 3200 protocol type"; 674 reference "MEF63 & G.709"; 675 } 677 identity STM-1 { 678 base "protocol-type"; 679 description 680 "SDH STM-1 protocol type"; 681 reference "MEF63 & G.709"; 682 } 684 identity STM-4 { 685 base "protocol-type"; 686 description 687 "SDH STM-4 protocol type"; 688 reference "MEF63 & G.709"; 689 } 691 identity STM-16 { 692 base "protocol-type"; 693 description 694 "SDH STM-16 protocol type"; 695 reference "MEF63 & G.709"; 696 } 698 identity STM-64 { 699 base "protocol-type"; 700 description 701 "SDH STM-64 protocol type"; 702 reference "MEF63 & G.709"; 703 } 705 identity STM-256 { 706 base "protocol-type"; 707 description 708 "SDH STM-256 protocol type"; 709 reference "MEF63 & G.709"; 710 } 712 identity OC-3 { 713 base "protocol-type"; 714 description 715 "SONET OC-3 protocol type"; 716 reference "MEF63 & G.709"; 717 } 718 identity OC-12 { 719 base "protocol-type"; 720 description 721 "SONET OC-12 protocol type"; 722 reference "MEF63 & G.709"; 723 } 725 identity OC-48 { 726 base "protocol-type"; 727 description 728 "SONET OC-48 protocol type"; 729 reference "MEF63 & G.709"; 730 } 732 identity OC-192 { 733 base "protocol-type"; 734 description 735 "SONET OC-192 protocol type"; 736 reference "MEF63 & G.709"; 737 } 739 identity OC-768 { 740 base "protocol-type"; 741 description 742 "SONET OC-768 protocol type"; 743 reference "MEF63 & G.709"; 744 } 746 identity coding-func { 747 description 748 "base identity from which coding func is derived."; 749 } 751 identity ETH-1000X-PCS-36 { 752 base "coding-func"; 753 description 754 "PCS clause 36 coding function that corresponds to 1000BASE-X"; 755 reference "MEF63 & IEEE802.3"; 756 } 758 identity ETH-10GW-PCS-49-WIS-50 { 759 base "coding-func"; 760 description 761 "PCS clause 49 and WIS clause 50 coding func that corresponds 762 to 10GBASE-W (WAN PHY)"; 763 reference "MEF63 & IEEE802.3"; 764 } 765 identity ETH-10GR-PCS-49 { 766 base "coding-func"; 767 description 768 "PCS clause 49 coding function that corresponds to 10GBASE-R 769 (LAN PHY)"; 770 reference "MEF63 & IEEE802.3"; 771 } 773 identity ETH-40GR-PCS-82 { 774 base "coding-func"; 775 description 776 "PCS clause 82 coding function that corresponds to 40GBASE-R"; 777 reference "MEF63 & IEEE802.3"; 778 } 780 identity ETH-100GR-PCS-82 { 781 base "coding-func"; 782 description 783 "PCS clause 82 coding function that corresponds to 100GBASE-R"; 784 reference "MEF63 & IEEE802.3"; 785 } 787 /* coding func needs to expand for Fiber Channel, SONET, SDH */ 789 identity optical-interface-func { 790 description 791 "base identity from which optical-interface-function is derived."; 792 } 794 identity SX-PMD-clause-38 { 795 base "optical-interface-func"; 796 description 797 "SX-PMD-clause-38 Optical Interface function for 798 1000BASE-X PCS-36"; 799 reference "MEF63 & IEEE802.3"; 800 } 802 identity LX-PMD-clause-38 { 803 base "optical-interface-func"; 804 description 805 "LX-PMD-clause-38 Optical Interface function for 806 1000BASE-X PCS-36"; 807 reference "MEF63 & IEEE802.3"; 808 } 809 identity LX10-PMD-clause-59 { 810 base "optical-interface-func"; 811 description 812 "LX10-PMD-clause-59 Optical Interface function for 813 1000BASE-X PCS-36"; 814 reference "MEF63 & IEEE802.3"; 815 } 817 identity BX10-PMD-clause-59 { 818 base "optical-interface-func"; 819 description 820 "BX10-PMD-clause-59 Optical Interface function for 821 1000BASE-X PCS-36"; 822 reference "MEF63 & IEEE802.3"; 823 } 825 identity LW-PMD-clause-52 { 826 base "optical-interface-func"; 827 description 828 "LW-PMD-clause-52 Optical Interface function for 829 10GBASE-W PCS-49-WIS-50"; 830 reference "MEF63 & IEEE802.3"; 831 } 833 identity EW-PMD-clause-52 { 834 base "optical-interface-func"; 835 description 836 "EW-PMD-clause-52 Optical Interface function for 837 10GBASE-W PCS-49-WIS-50"; 838 reference "MEF63 & IEEE802.3"; 839 } 841 identity LR-PMD-clause-52 { 842 base "optical-interface-func"; 843 description 844 "LR-PMD-clause-52 Optical Interface function for 845 10GBASE-R PCS-49"; 846 reference "MEF63 & IEEE802.3"; 847 } 849 identity ER-PMD-clause-52 { 850 base "optical-interface-func"; 851 description 852 "ER-PMD-clause-52 Optical Interface function for 853 10GBASE-R PCS-49"; 854 reference "MEF63 & IEEE802.3"; 855 } 856 identity LR4-PMD-clause-87 { 857 base "optical-interface-func"; 858 description 859 "LR4-PMD-clause-87 Optical Interface function for 860 40GBASE-R PCS-82"; 861 reference "MEF63 & IEEE802.3"; 862 } 864 identity ER4-PMD-clause-87 { 865 base "optical-interface-func"; 866 description 867 "ER4-PMD-clause-87 Optical Interface function for 868 40GBASE-R PCS-82"; 869 reference "MEF63 & IEEE802.3"; 870 } 872 identity FR-PMD-clause-89 { 873 base "optical-interface-func"; 874 description 875 "FR-PMD-clause-89 Optical Interface function for 876 40GBASE-R PCS-82"; 877 reference "MEF63 & IEEE802.3"; 878 } 880 identity LR4-PMD-clause-88 { 881 base "optical-interface-func"; 882 description 883 "LR4-PMD-clause-88 Optical Interface function for 884 100GBASE-R PCS-82"; 885 reference "MEF63 & IEEE802.3"; 886 } 888 identity ER4-PMD-clause-88 { 889 base "optical-interface-func"; 890 description 891 "ER4-PMD-clause-88 Optical Interface function for 892 100GBASE-R PCS-82"; 893 reference "MEF63 & IEEE802.3"; 894 } 896 /* optical interface func needs to expand for Fiber Channel, SONET and SDH */ 898 identity performance-metric { 899 description "list of performance metric"; 900 } 901 identity One-way-Delay { 902 base "performance-metric"; 903 description "one-way-delay"; 904 } 906 identity One-way-Errored-Second { 907 base "performance-metric"; 908 description "one-way-errored-second"; 909 } 911 identity One-way-Severely-Errored-Second { 912 base "performance-metric"; 913 description "one-way-severely-errored-second"; 914 } 916 identity One-way-Unavailable-Second { 917 base "performance-metric"; 918 description "one-way-unavailable-second"; 919 } 921 identity One-way-Availability { 922 base "performance-metric"; 923 description "one-way-availability"; 924 } 926 } 928 930 5. JSON Example 932 This section provides a JSON example of the YANG module described in 933 Section 4. This example configures one L1VC service with two UNIs 934 that describe the UNI endpoints. The service is configured with the 935 starting time to be 06:06:09 on 2018-09-13 for the service life time 936 of 2419200 seconds (which is corresponds to 28 days). In addition, 937 the service is configured to collect one performance metric, One- 938 way-Delay. 940 { 941 "l1-connectivity": { 942 "access": { 943 "unis": { 944 "uni": [ 945 { 946 "id": "MTL-HQ-Node3-Slot2-Port1", 947 "protocol": "ETH-10GigE_LAN ", 948 "coding": "ETH-10GR-PCS-49 ", 949 "optical_interface": "LR-PMD-clause-52 " 950 }, 951 { 952 "id": "MTL-STL-Node5-Slot4-Port3", 953 "protocol": "ETH-10GigE_LAN ", 954 "coding": "ETH-10GR-PCS-49 ", 955 "optical_interface": "ER-PMD-clause-52 " 956 } 957 ] 958 }, 959 }, 960 "services": { 961 "service": [ 962 { 963 "service-id": "Sub-L1VC-1867-LT-MEGAMART", 964 "endpoint-1": 965 { 966 "id": "MTL-HQ_1867-MEGAMART", 967 "uni": "MTL-HQ-Node3-Slot2-Port1" 968 }, 969 "endpoint-2": 970 { 971 "id": "MTL-STL_1867-MEGAMART", 972 "uni": "MTL-STL-Node5-Slot4-Port3" 973 }, 974 "start-time": "2018-09-13T06:06:09Z", 975 "time-interval": 2419200, 976 "performance-metric": "One-way-Delay " 977 } 978 ] 979 }, 980 } 982 6. Security Considerations 984 The configuration, state, and action data defined in this document 985 are designed to be accessed via a management protocol with a secure 986 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 987 The lowest NETCONF layer is the secure transport layer, and the 988 mandatory-to-implement secure transport is Secure Shell (SSH) 989 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 990 to-implement secure transport is TLS [RFC8446]. 992 The NETCONF access control model [RFC8341] provides the means to 993 restrict access for particular NETCONF users to a preconfigured 994 subset of all available NETCONF protocol operations and content. 996 A number of configuration data nodes defined in this document are 997 writable/deletable (i.e., "config true") These data nodes may be 998 considered sensitive or vulnerable in some network environments. 1000 These are the subtrees and data nodes and their 1001 sensitivity/vulnerability: 1003 unis: 1004 - id 1006 Service: 1007 - service-id 1008 - endpoint-1 1009 - endpoint-2 1010 - start-time 1011 - time-interval 1012 - performance-metric 1014 7. IANA Considerations 1016 This document registers the following namespace URIs in the IETF XML 1017 registry [RFC3688]: 1019 -------------------------------------------------------------------- 1020 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 1021 Registrant Contact: The IESG. 1022 XML: N/A, the requested URI is an XML namespace. 1023 -------------------------------------------------------------------- 1025 -------------------------------------------------------------------- 1026 URI: urn:ietf:params:xml:ns:yang:ietf-l1-service-types 1027 Registrant Contact: The IESG. 1028 XML: N/A, the requested URI is an XML namespace. 1029 -------------------------------------------------------------------- 1031 This document registers the following YANG modules in the YANG 1032 Module 1034 Names registry [RFC6020]: 1036 -------------------------------------------------------------------- 1037 name: ietf-l1csm 1038 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 1039 reference: RFC XXXX (TDB) 1040 -------------------------------------------------------------------- 1042 -------------------------------------------------------------------- 1043 name: ietf-l1-service-types 1044 namespace: urn:ietf:params:xml:ns:yang:ietf-l1-service-types 1045 reference: RFC XXXX (TDB) 1046 -------------------------------------------------------------------- 1048 8. Acknowledgments 1050 The authors would like to thank Tom Petch and Italo Busi for their 1051 helpful comments and valuable contributions and Robert Wilton for 1052 his YANG doctor's review that improved the model significantly. 1054 9. References 1056 9.1. Normative References 1058 [MEF63] "Subscriber Layer 1 Service Attributes", Technical 1059 Specification, MEF 63, August 2018. 1061 [RFC8446] Dierks, T. and E. Rescorla, "The Transport Layer Security 1062 (TLS) Protocol Version 1.3", RFC 8446, August 2018. 1064 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1065 the Network Configuration Protocol (NETCONF)", RFC 6020, 1066 October 2010. 1068 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1069 and A. Bierman, Ed., "Network Configuration Protocol 1070 (NETCONF)", RFC 6241, June 2011. 1072 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1073 Shell (SSH)", RFC 6242, June 2011. 1075 [RFC6991] J. Schoenwaelder, Ed., "Common YANG Data Types", RFC 6991, 1076 July 2013. 1078 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1079 RFC 7950, August 2016. 1081 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1082 Protocol", RFC 8040, January 2017. 1084 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1085 Access Control Model", RFC 8341, March 2018. 1087 9.2. Informative References 1089 [RFC4847] T. Takeda (Editor), "Framework and Requirements for Layer 1090 1 Virtual Private Networks", RFC 4847, April 2007. 1092 [RFC5253] T. Takeda, "Applicability Statement for Layer 1 Virtual 1093 Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. 1095 [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module 1096 Classification", RFC 8199, July 2017. 1098 [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", 1099 RFC 8309, January 2018. 1101 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1102 and R. Wilton, "Network Management Datastore Architecture 1103 (NMDA)", RFC 8342, March 2018, 1105 [G.709] ITU-T Recommendation G.709/Y.1331, Interfaces for the 1106 optical transport network, Corrigendum 1, August 2017. 1108 [IEEE802.3] IEEE Std 802.3, IEEE Standard for Ethernet, 2015. 1110 10. Contributors 1112 Contributor's Addresses 1114 I. Busi 1115 Huawei 1116 Email: Italo.Busi@huawei.com 1118 Authors' Addresses 1120 G. Fioccola (Editor) 1121 Telecom Italia 1122 Email: giuseppe.fioccola@telecomitalia.it 1124 K. Lee 1125 KT 1126 Email: kwangkoog.lee@kt.com 1128 Y. Lee (Editor) 1129 Huawei 1130 Email: leeyoung@huawei.com 1132 D. Dhody 1133 Huawei 1134 Email: dhruv.ietf@gmail.com 1136 O. Gonzalez de Dios 1137 Telefonica 1138 Email: oscar.gonzalezdedios@telefonica.com 1140 D. Ceccarelli 1141 Ericsson 1142 Email: daniele.ceccarelli@ericsson.com