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