idnits 2.17.1 draft-fioccola-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 29 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 (March 5, 2018) is 2242 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 822, 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 823, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 834, but not defined == Missing Reference: 'RFC7950' is mentioned on line 845, 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: September 5, 2018 Y. Lee (Ed.) 6 D. Dhody 7 Huawei 8 O. Gonzalez de-Dios 9 Telefonica 10 D. Ceccarelli 11 Ericsson 13 March 5, 2018 15 A Yang Data Model for L1 Connectivity Service Model (L1CSM) 17 draft-fioccola-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 September 5, 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.......................................19 71 6. IANA Considerations...........................................20 72 7. Acknowledgments...............................................20 73 8. References....................................................21 74 8.1. Normative References.....................................21 75 8.2. Informative References...................................21 76 9. Contributors..................................................21 77 Authors' Addresses...............................................21 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-ingress? -> 298 /l1cs/access/uni-list/UNI-ID 299 +--rw subscriber-l1vc-ep-egress? -> 300 /l1cs/access/uni-list/UNI-ID 301 +--rw client-protocol? identityref 302 +--rw time-start? yang:date-and-time 303 +--rw time-interval? int64 304 +--rw CoS_Name? string 305 +--rw performance-metric? identityref 306 4. L1SM YANG Code 308 The YANG code is as follows: 310 file "ietf-l1csm@2018-03-05.yang" 312 module ietf-l1csm { 313 yang-version 1.1; 314 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 315 prefix "l1csm"; 317 import ietf-yang-types { 318 prefix "yang"; 319 } 321 organization 322 "Internet Engineering Task Force (IETF) CCAMP WG"; 324 contact 326 "Editor: G. Fioccolla (giuseppe.fioccola@telecomitalia.it) 327 Editor: K. Lee (kwangkoog.lee@kt.com) 328 Editor: Y. Lee (leeyoung@huawei.com) 329 Editor: D. Dhody (dhruv.ietf@gmail.com) 330 Editor: O. Gonzalez de-Dios (oscar.gonzalezdedios@telefonica.com) 331 Editor: D. Ceccarelli (daniele.ceccarelli@ericsson.com)"; 333 description 334 "this module describes Layer 1 connectivity service model for 335 subscriber Layer 1 Connectivity Services and Attributes"; 337 revision 2018-03-05 { 338 description 339 "Initial revision."; 340 reference "to add the draft name"; 342 } 344 identity protocol-type { 345 description 346 "base identity from which client protocol 347 type is derived."; 348 } 350 identity aGigE { 351 base protocol-type; 352 description 353 "GigE protocol type"; 354 } 356 identity a10GigE_WAN { 357 base protocol-type; 358 description 359 "10GigE-WAN protocol type"; 360 } 362 identity a10GigE_LAN { 363 base protocol-type; 364 description 365 "10GigE-LAN protocol type"; 366 } 368 identity a40GigE { 369 base protocol-type; 370 description 371 "40GigE protocol type"; 372 } 374 identity a100GigE { 375 base protocol-type; 376 description 377 "100GigE protocol type"; 378 } 380 identity FC-100 { 381 base protocol-type; 382 description 383 "Fiber Channel - 100 protocol type"; 384 } 386 identity FC-200 { 387 base protocol-type; 388 description 389 "Fiber Channel - 200 protocol type"; 390 } 391 identity FC-400 { 392 base protocol-type; 393 description 394 "Fiber Channel - 400 protocol type"; 395 } 397 identity FC-800 { 398 base protocol-type; 399 description 400 "Fiber Channel - 800 protocol type"; 401 } 403 identity FC-1200 { 404 base protocol-type; 405 description 406 "Fiber Channel - 1200 protocol type"; 407 } 409 identity FC-1600 { 410 base protocol-type; 411 description 412 "Fiber Channel - 1600 protocol type"; 413 } 415 identity FC-3200 { 416 base protocol-type; 417 description 418 "Fiber Channel - 3200 protocol type"; 419 } 421 identity STM-1 { 422 base protocol-type; 423 description 424 "SDH STM-1 protocol type"; 425 } 427 identity STM-4 { 428 base protocol-type; 429 description 430 "SDH STM-4 protocol type"; 431 } 433 identity STM-16 { 434 base protocol-type; 435 description 436 "SDH STM-16 protocol type"; 437 } 439 identity STM-64 { 440 base protocol-type; 441 description 442 "SDH STM-64 protocol type"; 443 } 445 identity STM-256 { 446 base protocol-type; 447 description 448 "SDH STM-256 protocol type"; 449 } 451 identity OC-3 { 452 base protocol-type; 453 description 454 "SONET OC-3 protocol type"; 455 } 457 identity OC-12 { 458 base protocol-type; 459 description 460 "SONET OC-12 protocol type"; 461 } 463 identity OC-48 { 464 base protocol-type; 465 description 466 "SONET OC-48 protocol type"; 467 } 469 identity OC-192 { 470 base protocol-type; 471 description 472 "SONET OC-192 protocol type"; 473 } 475 identity OC-768 { 476 base protocol-type; 477 description 478 "SONET OC-768 protocol type"; 479 } 480 identity coding-func { 481 description 482 "base identity from which coding func is 483 derived."; 484 } 486 identity a1000X-PCS-36 { 487 base coding-func; 488 description 489 "PCS clause 36 coding function that 490 corresponds to 1000BASE-X"; 491 } 493 identity a10GW-PCS-49-WIS-50 { 494 base coding-func; 495 description 496 "PCS clause 49 and WIS clause 50 coding func 497 that corresponds to 10GBASE-W (WAN PHY)"; 498 } 500 identity a10GR-PCS-49 { 501 base coding-func; 502 description 503 "PCS clause 49 coding function that 504 corresponds to 10GBASE-R (LAN PHY)"; 505 } 507 identity a40GR-PCS-82 { 508 base coding-func; 509 description 510 "PCS clause 82 coding function that 511 corresponds to 40GBASE-R"; 512 } 514 identity a100GR-PCS-82 { 515 base coding-func; 516 description 517 "PCS clause 82 coding function that 518 corresponds to 100GBASE-R"; 519 } 521 /* coding func needs to expand for Fiber Channel, SONET, SDH */ 523 identity optical-interface-func { 524 description 525 "base identity from which optical-interface- 526 function is derived."; 527 } 529 identity SX-PMD-clause-38 { 530 base optical-interface-func; 531 description 532 "SX-PMD-clause-38 Optical Interface function 533 for 1000BASE-X PCS-36"; 534 } 536 identity LX-PMD-clause-38 { 537 base optical-interface-func; 538 description 539 "LX-PMD-clause-38 Optical Interface function 540 for 1000BASE-X PCS-36"; 541 } 543 identity LX10-PMD-clause-59 { 544 base optical-interface-func; 545 description 546 "LX10-PMD-clause-59 Optical Interface 547 function for 1000BASE-X PCS-36"; 548 } 550 identity BX10-PMD-clause-59 { 551 base optical-interface-func; 552 description 553 "BX10-PMD-clause-59 Optical Interface 554 function for 1000BASE-X PCS-36"; 555 } 557 identity LW-PMD-clause-52 { 558 base optical-interface-func; 559 description 560 "LW-PMD-clause-52 Optical Interface function 561 for 10GBASE-W PCS-49-WIS-50"; 562 } 564 identity EW-PMD-clause-52 { 565 base optical-interface-func; 566 description 567 "EW-PMD-clause-52 Optical Interface function 568 for 10GBASE-W PCS-49-WIS-50"; 569 } 571 identity LR-PMD-clause-52 { 572 base optical-interface-func; 573 description 574 "LR-PMD-clause-52 Optical Interface function 575 for 10GBASE-R PCS-49"; 576 } 578 identity ER-PMD-clause-52 { 579 base optical-interface-func; 580 description 581 "ER-PMD-clause-52 Optical Interface function 582 for 10GBASE-R PCS-49"; 583 } 585 identity LR4-PMD-clause-87 { 586 base optical-interface-func; 587 description 588 "LR4-PMD-clause-87 Optical Interface function 589 for 40GBASE-R PCS-82"; 590 } 592 identity ER4-PMD-clause-87 { 593 base optical-interface-func; 594 description 595 "ER4-PMD-clause-87 Optical Interface function 596 for 40GBASE-R PCS-82"; 597 } 599 identity FR-PMD-clause-89 { 600 base optical-interface-func; 601 description 602 "FR-PMD-clause-89 Optical Interface function 603 for 40GBASE-R PCS-82"; 604 } 606 identity LR4-PMD-clause-88 { 607 base optical-interface-func; 608 description 609 "LR4-PMD-clause-88 Optical Interface function 610 for 100GBASE-R PCS-82"; 611 } 613 identity ER4-PMD-clause-88 { 614 base optical-interface-func; 615 description 616 "ER4-PMD-clause-88 Optical Interface function 617 for 100GBASE-R PCS-82"; 618 } 620 /* optical interface func needs to expand for Fiber Channel, SONET 621 and SDH */ 623 identity performance-metriclist { 624 description "list of performance metric"; 625 } 627 identity One-way-Delay { 628 base performance-metriclist; 629 description "one-way-delay"; 630 } 632 identity One-way-Errored-Second { 633 base performance-metriclist; 634 description "one-way-errored-second"; 635 } 637 identity One-way-Severely-Errored-Second { 638 base performance-metriclist; 639 description "one-way-severely-errored-second"; 640 } 642 identity One-way-Unavailable-Second { 643 base performance-metriclist; 644 description "one-way-unavailable-second"; 645 } 647 identity One-way-Availability { 648 base performance-metriclist; 649 description "one-way-availability"; 650 } 652 grouping protocol-coding-optical_interface { 653 description 654 "describes "; 655 leaf protocol { 656 type identityref { 657 base protocol-type; 658 } 659 description "Physical layer L1VC client 660 protocol service attribute"; 661 } 663 leaf coding { 664 type identityref { 665 base coding-func; 666 } 667 description "coding function"; 668 } 670 leaf optical_interface { 671 type identityref { 672 base optical-interface-func; 673 } 674 description "optical-interface-function"; 675 } 676 } 678 grouping uni-attributes { 679 description 680 "uni-service-attributes"; 682 leaf UNI-ID { 683 type string; 684 description "the UNI id of UNI 685 Service Attributes"; 686 } 688 uses protocol-coding-optical_interface; 690 } 692 grouping subscriber-l1vc-sls-service-attribute { 693 description 694 "The value of the Subscriber L1VC SLS 695 (Service Level Specification) Service Attribute expressed in a 4-tuple of the 696 form."; 698 leaf time-start { 699 type yang:date-and-time; 700 description "a time that represent 701 the date and time for the start of the SLS"; 702 } 704 leaf time-interval { 705 type int64; 706 units seconds; 707 description "a time interval 708 (e.g., 1 month) that is used in conjunction wuth time-start to specify a 709 contiguous sequence of time intervals T for determining when performance 710 objectives are met."; 711 } 713 leaf CoS_Name { 714 type string; 715 description "a Class of Service 716 Name used by the Subscriber L1VC End Point Class of Service Identifier Service 717 Attribute."; 718 } 720 leaf performance-metric { 721 type identityref { 722 base performance-metriclist; 723 } 724 description "list of performance 725 metric"; 726 } 727 } 729 grouping subscriber-l1vc-service-attributes { 730 description 731 "subscriber layer 1 connection service 732 service level"; 734 leaf subscriber-l1vc-id { 735 type string; 736 description "subscriber L1VC identifier"; 737 } 739 leaf subscriber-l1vc-ep-ingress { 740 type leafref { 741 path "/l1cs/access/uni-list/UNI-ID"; 742 } 743 description "this is one end of subscriber L1VC end 744 point ID value = UNI-1"; 745 } 746 leaf subscriber-l1vc-ep-egress { 747 type leafref { 748 path "/l1cs/access/uni-list/UNI-ID"; 749 } 750 description "this is the other end of subscriber 751 L1VC end point ID value = UNI-2"; 752 } 754 leaf client-protocol { 755 type identityref { 756 base protocol-type; 757 } 758 description "One of Ethernet, Fiber Channel, SONET, 759 SDH"; 760 } 762 uses subscriber-l1vc-sls-service-attribute; 763 } 765 grouping subscriber-attributes { 766 description 767 "subscriber attributes"; 769 uses subscriber-l1vc-service-attributes; 771 } 773 container l1cs { 774 description 775 "serves as a top-level container for a list of layer 1 776 connection services (l1cs)"; 778 container access { 779 description "UNI configurations"; 781 list uni-list { 782 key "UNI-ID"; 783 description "uni identifier"; 784 uses uni-attributes { 785 description "UNI attributes 786 information"; 787 } 788 } 790 } 792 container service { 793 description "L1VC service"; 794 list service-list { 795 key "subscriber-l1vc-id"; 796 description 797 "an unique identifier of a service"; 799 leaf subscriber-l1vc-id { 800 type string; 801 description "a unique service identifier for 802 L1VC."; 803 } 804 container service-config { 805 description "service-config container"; 807 uses subscriber-attributes; 809 }//end of service-config 810 }//end of service list 811 } //end of service container 813 }//service top container 814 } 816 818 5. Security Considerations 820 The configuration, state, and action data defined in this document 821 are designed to be accessed via a management protocol with a secure 822 transport layer, such as NETCONF [RFC6241]. The NETCONF access 823 control model [RFC6536] provides the means to restrict access for 824 particular NETCONF users to a preconfigured subset of all available 825 NETCONF protocol operations and content. 827 A number of configuration data nodes defined in this document are 828 writable/deletable (i.e., "config true") These data nodes may be 829 considered sensitive or vulnerable in some network environments. 831 6. IANA Considerations 833 This document registers the following namespace URIs in the IETF XML 834 registry [RFC3688]: 836 -------------------------------------------------------------------- 837 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 838 Registrant Contact: The IESG. 839 XML: N/A, the requested URI is an XML namespace. 840 -------------------------------------------------------------------- 842 This document registers the following YANG modules in the YANG 843 Module 845 Names registry [RFC7950]: 847 -------------------------------------------------------------------- 848 name: ietf-l1csm 849 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 850 reference: RFC XXXX (TDB) 851 -------------------------------------------------------------------- 853 7. Acknowledgments 855 The authors would like to thank Italo Busi for his helpful comments 856 and valuable contributions. 858 8. References 860 8.1. Normative References 862 [MEF-L1CS] "Subscriber Layer 1 Connectivity Service Attributes", 863 Working Draft (WD) v0.09 December 13, 2017. 865 8.2. Informative References 867 [RFC4847] T. Takeda (Editor), "Framework and Requirements for Layer 868 1 Virtual Private Networks", RFC 4847, April 2007. 870 [RFC5253] T. Takeda, "Applicability Statement for Layer 1 Virtual 871 Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. 873 [Service-Yang] Q. Wu, et al, "Service Models Explained", draft-wu- 874 opsawg-service-model-explained, Work in progress. 876 9. Contributors 878 Contributor's Addresses 880 I. Busi 881 Huawei 882 Email: Italo.Busi@huawei.com 884 Authors' Addresses 886 G. Fioccola (Editor) 887 Telecom Italia 888 Email: giuseppe.fioccola@telecomitalia.it 890 K. Lee 891 KT 892 Email: kwangkoog.lee@kt.com 894 Y. Lee (Editor) 895 Huawei 896 Email: leeyoung@huawei.com 898 D. Dhody 899 Huawei 900 Email: dhruv.ietf@gmail.com 902 O. Gonzalez de Dios 903 Telefonica 904 Email: oscar.gonzalezdedios@telefonica.com 906 D. Ceccarelli 907 Ericsson 908 Email: daniele.ceccarelli@ericsson.com