idnits 2.17.1 draft-zheng-ccamp-client-pm-yang-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 182 has weird spacing: '...er-name ide...' == Line 186 has weird spacing: '...c-state enu...' -- The document date (January 11, 2021) is 1199 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) == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-client-signal-yang-03 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-08 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-04 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-11 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-wson-tunnel-model-05 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft I. Busi 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 15, 2021 Y. Zheng 6 China Unicom 7 January 11, 2021 9 A YANG Data Model for Client Signal Performance Monitoring 10 draft-zheng-ccamp-client-pm-yang-03 12 Abstract 14 A transport network is a server-layer network to provide connectivity 15 services to its client. Given the client signal is configured, the 16 followup function for performance monitoring, such as latency and bit 17 error rate, would be needed for network operation. 19 This document describes the data model to support the performance 20 monitoring functionalities. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 15, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 58 3. Model Relationship . . . . . . . . . . . . . . . . . . . . . 3 59 4. Consideration on Monitoring Parameters . . . . . . . . . . . 4 60 5. OAM Configuration . . . . . . . . . . . . . . . . . . . . . . 4 61 6. YANG Model for Performance Monitoring . . . . . . . . . . . . 4 62 6.1. YANG Tree for Performance Monitoring . . . . . . . . . . 4 63 6.2. YANG Tree for OAM Configuration . . . . . . . . . . . . . 5 64 7. YANG Code for Performance Monitoring . . . . . . . . . . . . 6 65 7.1. The Performance Monitoring YANG Code . . . . . . . . . . 6 66 7.2. The OAM Configuration YANG Code . . . . . . . . . . . . . 14 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 9. Manageability Considerations . . . . . . . . . . . . . . . . 19 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 70 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 73 12.2. Informative References . . . . . . . . . . . . . . . . . 20 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 Client-layer network and server-layer network have been respectively 79 modeled to allow the tunnels carrying the client traffic. Server- 80 layers are modeled as tunnels with various switching technologies, 81 such as [I-D.ietf-ccamp-otn-tunnel-model] and 82 [I-D.ietf-ccamp-wson-tunnel-model]. Client-layers are modeled as 83 client signals according to the client-signal identities specified in 84 [I-D.ietf-ccamp-layer1-types]. These client signals can be 85 configured to existing tunnels via the client signal configuration 86 model specified in [I-D.ietf-ccamp-client-signal-yang]. 88 In the network operation, the operator is interested in monitoring 89 for their instantiated client signal over tunnels. The objective for 90 such monitoring is to complete timely adjustment once there is 91 abnormal statistic which may result in failure of the client signal. 92 The parameters specified in the performance monitoring model can be 93 collected for the operation need. The OAM mechanism, can be 94 configured together with the performance monitoring model. 96 2. Terminology and Notations 98 A simplified graphical representation of the data model is used in 99 this document. The meaning of the symbols in the YANG data tree 100 presented later in this document is defined in [RFC8340]. They are 101 provided below for reference. 103 o Brackets "[" and "]" enclose list keys. 105 o Abbreviations before data node names: "rw" means configuration 106 (read-write) and "ro" state data (read-only). 108 o Symbols after data node names: "?" means an optional node, "!" 109 means a presence container, and "*" denotes a list and leaf-list. 111 o Parentheses enclose choice and case nodes, and case nodes are also 112 marked with a colon (":"). 114 o Ellipsis ("...") stands for contents of subtrees that are not 115 shown. 117 3. Model Relationship 119 [I-D.ietf-ccamp-client-signal-yang] has specified the two models for 120 the client signal configuration, module ietf-trans-client-service for 121 transparent client service and module ietf-eth-tran-service for 122 Ethernet service. Basically the client signal types in this document 123 is consistent with ietf-eth-tran-types, and focus on different 124 functionality. On the perspective of operator, the modules in 125 [I-D.ietf-ccamp-client-signal-yang] can be used to configure the 126 service given any underlay tunnels, while the operation about 127 monitoring the performance on given service can be achieved by using 128 the model in this document. 130 Consideration on Key Performance Information (KPI) monitoring for 131 Virtual Network (VN) and tunnels has been specified in 132 [I-D.ietf-teas-actn-pm-telemetry-autonomics]. Usually the monitoring 133 on the tunnels are the VNs should be separately deployed for the 134 network operation, but it is possible to have common parameters that 135 are both needed for the VN/TE and the configured services. Common 136 types are imported in both modules. 138 VPN-level parameters and their monitoring have been defined in 139 [I-D.www-bess-yang-vpn-service-pm]. This module focus on the 140 performance on the topology at different layer or the overlay 141 topology between VPN sites. On the other hand, this document is 142 focusing on the performance of the service configured between 143 Customer Ends (CE). 145 4. Consideration on Monitoring Parameters 147 There can be multiple groups of parameters for monitoring, such as 148 latency, bit error rate (BER). Some of these parameters are layer- 149 dependent, for example, packet loss is only applicable in packet 150 networks are won't be neede for layer 1 OTN and layer 0 WSON. 152 This document starts with the specification of the latency 153 measurement for both Ethernet service and client signal service. In 154 the future version additional parameters would be added into the data 155 model in the same approach as the latency in the current version. A 156 candidate list of parameters to be monitored include: Latency, Packet 157 Loss, Bit Error Rate (BER), Jitter, Bandwidth, Byte/Packet number and 158 so on. 160 5. OAM Configuration 162 The operation, administration and maintenance protocols and data 163 models have been specified in [RFC8531] for the connection-oriented 164 network. The model is referenced in this work to develop an 165 Ethernet-specific OAM models, which is augmenting the service 166 performance monitoring data model. 168 The definitions of OAM terminologies, such as maintainence 169 Maintenance Domain (MD), Maintenance Association (MA), and 170 Maintenance End Points (MEP), can be found in [RFC8531] as well. 172 6. YANG Model for Performance Monitoring 174 6.1. YANG Tree for Performance Monitoring 175 module: ietf-service-pm 176 +--rw performance-monitoring 177 +--rw service-pm* [service-name] 178 +--rw service-name union 179 +--rw task-pm-enable? boolean 180 +--rw granularity? identityref 181 +--rw performance-data-config* [parameter-name] 182 | +--rw parameter-name identityref 183 | +--rw measure-method? identityref 184 +--ro service-pm-state 185 +--ro oam-state 186 | +--ro cc-state enumeration 187 | +--ro lm-state? enumeration 188 | +--ro dm-state? enumeration 189 +--ro performance-data* [parameter-name] 190 | +--ro parameter-name identityref 191 | +--ro parameter-value* [index] 192 | +--ro index uint64 193 | +--ro value performance-parameter-value 194 | +--ro value-unit string 195 | +--ro value-description? string 196 | +--ro start-time? yang:date-and-time 197 | +--ro end-time? yang:date-and-time 198 +--ro monitor-state identityref 199 +--ro error-info 200 | +--ro error-code? uint32 201 | +--ro error-message? string 202 +--ro alarm 203 +--ro status? identityref 205 6.2. YANG Tree for OAM Configuration 206 module: ietf-eth-service-oam 207 augment /svc-pm:performance-monitoring/svc-pm:service-pm: 208 +--rw oam-config 209 +--rw source 210 | +--rw md-name? string 211 | +--rw ma-name? string 212 | +--rw ma-level? string 213 | +--rw meg-id? string 214 | +--rw meg-level? string 215 | +--rw mep-id? uint8 216 | +--rw remote-mep-id? uint8 217 +--rw destination 218 | +--rw md-name? string 219 | +--rw ma-name? string 220 | +--rw ma-level? string 221 | +--rw meg-id? string 222 | +--rw meg-level? string 223 | +--rw mep-id? uint8 224 | +--rw remote-mep-id? uint8 225 +--rw cc-interval? identityref 226 +--rw lm-interval? identityref 227 +--rw dm-interval? identityref 229 7. YANG Code for Performance Monitoring 231 7.1. The Performance Monitoring YANG Code 233 file "ietf-service-pm@2020-07-13.yang" 234 module ietf-service-pm { 235 yang-version 1.1; 237 namespace "urn:ietf:params:xml:ns:yang:ietf-service-pm"; 238 prefix "svc-pm"; 240 import ietf-eth-tran-service { 241 prefix "ethtsvc"; 242 } 244 import ietf-yang-types { 245 prefix "yang"; 246 } 248 import ietf-trans-client-service { 249 prefix "clntsvc"; 250 } 251 organization 252 "Internet Engineering Task Force (IETF) CCAMP WG"; 253 contact 254 " 255 WG List: 256 ID-draft editor: 257 Haomian Zheng (zhenghaomian@huawei.com); 258 Italo Busi (italo.busi@huawei.com); 259 Yanlei Zheng (zhengyanlei@chinaunicom.cn); 260 "; 262 description 263 "This module defines the performance monitoring for Ethernet 264 services. The model fully conforms to the Network Management 265 Datastore Architecture (NMDA). 267 Copyright (c) 2020 IETF Trust and the persons 268 identified as authors of the code. All rights reserved. 269 Redistribution and use in source and binary forms, with or 270 without modification, is permitted pursuant to, and subject 271 to the license terms contained in, the Simplified BSD License 272 set forth in Section 4.c of the IETF Trust's Legal Provisions 273 Relating to IETF Documents 274 (https://trustee.ietf.org/license-info). 275 This version of this YANG module is part of RFC XXXX; see 276 the RFC itself for full legal notices."; 278 revision 2020-07-13 { 279 description 280 "Initial version"; 281 reference 282 "ADD REFERENCE HERE"; 283 } 285 typedef performance-parameter-value { 286 type union { 287 type uint32; 288 type uint64; 289 type decimal64 { 290 fraction-digits 6; 291 } 292 type string; 293 } 294 description 295 "A performance parameter value."; 296 } 298 grouping service-performance-monitor-set{ 299 description "the set of parameter name, value and description."; 300 leaf parameter-name{ 301 type identityref { 302 base performance-parameter-type; 303 } 304 description 305 "The name of parameters to be monitored. 306 For example, latency, Bit Error Rate, Bandwidth and so on."; 307 } 308 list parameter-value { 309 key index; 310 description 311 "The table of values of the performance and 312 their descriptions."; 313 leaf index { 314 type uint64; 315 description 316 "Used for list index"; 317 } 318 leaf value { 319 type performance-parameter-value; 320 mandatory true; 321 description 322 "The value of the parameter. "; 323 } 324 leaf value-unit { 325 type string; 326 mandatory true; 327 description 328 "The value unit of the parameter. 329 For example, second, minute and so on."; 330 } 331 leaf value-description{ 332 type string; 333 description 334 "The description of previous value. "; 335 } 336 leaf start-time { 337 type yang:date-and-time; 338 description 339 "The time stamp when the parameter is started."; 340 } 341 leaf end-time { 342 type yang:date-and-time; 343 description 344 "The time stamp when the parameter is ended."; 345 } 346 } 348 } 350 identity performance-parameter-type { 351 description 352 "Base type of the performance parameter being monitored."; 353 } 355 identity near-frame-loss { 356 base performance-parameter-type; 357 description 358 "Near frame loss, using one-way eth loss measure, 359 the sampling point is the MEP."; 360 } 362 identity far-frame-loss { 363 base performance-parameter-type; 364 description 365 "Far frame loss, using one-way eth loss measure, 366 the sampling point is the MEP."; 367 } 369 identity one-way-delay { 370 base performance-parameter-type; 371 description 372 "One way delay."; 373 } 375 identity two-way-delay { 376 base performance-parameter-type; 377 description 378 "Two way delay."; 379 } 381 identity receive-packets { 382 base performance-parameter-type; 383 description 384 "Total number of received packets."; 385 } 387 identity transmit-packets { 388 base performance-parameter-type; 389 description 390 "Total number of transmitted packets."; 391 } 393 identity alarm-status { 394 description "indicates whether there is alarm or not"; 395 } 396 identity alarm { 397 base alarm-status; 398 description "There is one or multiple alarms from the monitor. "; 399 } 401 identity no-alarm { 402 base alarm-status; 403 description "There is no alarms from the monitor. "; 404 } 406 identity monitoring-state { 407 description 408 "The state of performance monitoring. "; 409 } 411 identity monitoring { 412 base monitoring-state; 413 description "The Ethernet client signal is under monitoring. "; 414 } 416 identity monitor-finished { 417 base monitoring-state; 418 description 419 "The monitoring of Ethernet client signal is finished. "; 420 } 422 identity monitor-failed { 423 base monitoring-state; 424 description 425 "The monitoring of Ethernet client signal is failed. "; 426 } 428 identity granularity-type { 429 description 430 "Monitoring granularity"; 431 } 433 identity granularity-1min { 434 base granularity-type; 435 description 436 "1 minute"; 437 } 439 identity granularity-15min { 440 base granularity-type; 441 description 442 "15 minutes"; 443 } 444 identity granularity-24h { 445 base granularity-type; 446 description 447 "24 hours"; 448 } 450 identity measure-method { 451 description "Measure method."; 452 } 454 identity measure-by-loopback { 455 base measure-method; 456 description "Loopback measure method."; 457 } 459 identity measure-at-ingress { 460 base measure-method; 461 description "Ingress measure method."; 462 } 464 container performance-monitoring { 465 description 466 "This part is for performance monitoring. "; 467 list service-pm { 468 key "service-name"; 469 description 470 "The list of service to be monitored."; 471 leaf service-name { 472 mandatory true; 473 type union { 474 type leafref { 475 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 476 + "/ethtsvc:etht-svc-name"; 477 } 478 type leafref { 479 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 480 + "/clntsvc:client-svc-name"; 481 } 482 } 484 description "The name of service."; 485 } 487 leaf task-pm-enable { 488 type boolean; 489 description 490 "Indicate whether the performance monitoring 491 is enable or not."; 493 } 495 leaf granularity { 496 type identityref { 497 base granularity-type; 498 } 499 description 500 "Monitoring granularity"; 501 } 503 list performance-data-config { 504 key parameter-name; 505 description 506 "Specify the performance parameters to be queried"; 508 leaf parameter-name { 509 type identityref { 510 base performance-parameter-type; 511 } 512 description 513 "The name of parameters to be monitored. 514 For example, latency, BER, Bandwidth and so on."; 515 } 516 leaf measure-method { 517 type identityref { 518 base measure-method; 519 } 520 } 521 } 523 container service-pm-state { 524 config false; 525 description 526 "The state of service performance monitoring."; 528 container oam-state { 529 leaf cc-state { 530 mandatory true; 531 type enumeration { 532 enum up; 533 enum down; 534 } 535 } 536 leaf lm-state { 537 type enumeration { 538 enum up; 539 enum down; 540 } 542 } 543 leaf dm-state { 544 type enumeration { 545 enum up; 546 enum down; 547 } 548 } 549 } 551 list performance-data{ 552 key parameter-name; 553 description "The list of performance under monitor."; 554 uses service-performance-monitor-set; 555 } 557 leaf monitor-state { 558 mandatory true; 559 type identityref { 560 base monitoring-state; 561 } 562 description "The status of performance monitoring. "; 563 } 565 container error-info { 566 description 567 "Describe the error message."; 568 leaf error-code { 569 type uint32; 570 description 571 "The code of error."; 572 } 573 leaf error-message { 574 type string; 575 description 576 "The message of error."; 577 } 578 } 580 container alarm { 581 description 582 "To retrieve the Alarm during performance Monitoring."; 583 leaf status { 584 type identityref { 585 base alarm-status; 586 } 587 description "The status of the alarm. "; 588 } 589 } 591 } 592 } 593 } 595 } 597 599 7.2. The OAM Configuration YANG Code 601 file "ietf-eth-service-oam@2020-07-13.yang" 602 module ietf-eth-service-oam { 603 yang-version 1.1; 605 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-service-oam"; 606 prefix "etht-oam"; 608 import ietf-eth-tran-service { 609 prefix "ethtsvc"; 610 } 612 import ietf-service-pm { 613 prefix "svc-pm"; 614 } 616 import ietf-trans-client-service { 617 prefix "clntsvc"; 618 } 620 import ietf-network { 621 prefix nw; 622 } 624 organization 625 "Internet Engineering Task Force (IETF) CCAMP WG"; 626 contact 627 " 628 WG List: 629 ID-draft editor: 630 Haomian Zheng (zhenghaomian@huawei.com); 631 Italo Busi (italo.busi@huawei.com); 632 Yanlei Zheng (zhengyanlei@chinaunicom.cn); 633 "; 635 description 636 "This module defines the performance monitoring for Ethernet 637 services OAM. The model fully conforms to the Network Management 638 Datastore Architecture (NMDA). 640 Copyright (c) 2020 IETF Trust and the persons 641 identified as authors of the code. All rights reserved. 642 Redistribution and use in source and binary forms, with or 643 without modification, is permitted pursuant to, and subject 644 to the license terms contained in, the Simplified BSD License 645 set forth in Section 4.c of the IETF Trust's Legal Provisions 646 Relating to IETF Documents 647 (https://trustee.ietf.org/license-info). 648 This version of this YANG module is part of RFC XXXX; see 649 the RFC itself for full legal notices."; 651 revision 2020-07-13 { 652 description 653 "Initial version"; 654 reference 655 "ADD REFERENCE HERE"; 656 } 658 identity interval-type { 659 description "Time interval"; 660 } 662 identity interval-3p33ms { 663 base interval-type; 664 description "3.33 milliseconds"; 665 } 667 identity interval-10ms { 668 base interval-type; 669 description "10 milliseconds"; 670 } 672 identity interval-100ms { 673 base interval-type; 674 description "100 milliseconds"; 675 } 677 identity interval-1s { 678 base interval-type; 679 description "1 second"; 680 } 682 identity interval-10s { 683 base interval-type; 684 description "10 seconds"; 686 } 688 identity interval-1m { 689 base interval-type; 690 description "1 minute"; 691 } 693 identity interval-10m { 694 base interval-type; 695 description "10 minutes"; 696 } 698 grouping eth-service-oam-config { 699 container source { 700 uses mep-config; 701 } 702 container destination { 703 uses mep-config; 704 } 706 uses interval-config; 707 } 709 grouping interval-config { 710 leaf cc-interval { 711 description "Continuity check interval"; 712 type identityref { 713 base interval-type; 714 } 715 } 717 leaf lm-interval { 718 description "Loss measurement interval"; 719 type identityref { 720 base interval-type; 721 } 722 } 724 leaf dm-interval { 725 description "Delay measurement interval"; 726 type identityref { 727 base interval-type; 728 } 729 } 730 } 732 grouping mep-config { 733 leaf md-name { 734 type string; 735 description 736 "maintenance domain"; 737 } 738 leaf ma-name { 739 type string; 740 description 741 "An maintenance association(MA) is a part of an MD. 742 An MD can be divided into one or more MAs. "; 743 } 745 leaf ma-level { 746 type string; 747 } 749 leaf meg-id { 750 type string; 751 description 752 "Comply with Y.1731 term, mapping with 802.lag MA name."; 753 } 754 leaf meg-level { 755 type string; 756 description "Mapping with 802.lag MA level."; 757 } 759 leaf mep-id { 760 type uint8; 761 description "0 if Abnormal"; 762 } 764 leaf remote-mep-id { 765 type uint8; 766 description "The remote MEP ID must be specified."; 767 } 768 } 770 augment "/svc-pm:performance-monitoring/svc-pm:service-pm" { 771 description 772 "Augment with additional parameters required for Ethernet OAM"; 774 container oam-config { 775 uses eth-service-oam-config; 776 } 777 } 779 grouping errors { 780 leaf error-code { 781 type uint32; 782 } 784 leaf error-message { 785 type string; 786 } 787 } 788 790 8. IANA Considerations 792 It is proposed that IANA should assign new URIs from the "IETF XML 793 Registry" [RFC3688] as follows: 795 URI: urn:ietf:params:xml:ns:yang:ietf-service-pm 796 Registrant Contact: The IESG 797 XML: N/A; the requested URI is an XML namespace. 799 URI: urn:ietf:params:xml:ns:yang:ietf-eth-service-oam 800 Registrant Contact: The IESG 801 XML: N/A; the requested URI is an XML namespace. 803 This document registers following YANG modules in the YANG Module 804 Names registry [RFC7950]. 806 name: ietf-service-pm 807 namespace: urn:ietf:params:xml:ns:yang:ietf-service-pm 808 prefix: svc-pm 809 reference: RFC XXXX (This document) 811 name: ietf-eth-service-oam 812 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-service-oam 813 prefix: eth-oam 814 reference: RFC XXXX (This document) 816 9. Manageability Considerations 818 TBD. 820 10. Security Considerations 822 The data following the model defined in this document is exchanged 823 via, for example, the interface between an orchestrator and a 824 transport network controller. The security concerns mentioned in 825 [I-D.ietf-ccamp-client-signal-yang] also applies to this document. 827 The YANG module defined in this document can be accessed via the 828 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 829 protocol [RFC6241]. 831 11. Contributors 833 Chaode YU 834 Huawei Technologies, 835 Email: yuchaode@huawei.com 837 12. References 839 12.1. Normative References 841 [I-D.ietf-ccamp-client-signal-yang] 842 Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F., 843 Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data 844 Model for Transport Network Client Signals", draft-ietf- 845 ccamp-client-signal-yang-03 (work in progress), July 2020. 847 [I-D.ietf-ccamp-layer1-types] 848 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 849 Types", draft-ietf-ccamp-layer1-types-08 (work in 850 progress), November 2020. 852 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 853 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 854 and D. Ceccarelli, "YANG models for VN/TE Performance 855 Monitoring Telemetry and Scaling Intent Autonomics", 856 draft-ietf-teas-actn-pm-telemetry-autonomics-04 (work in 857 progress), November 2020. 859 [I-D.www-bess-yang-vpn-service-pm] 860 WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H. 861 Xu, "A YANG Model for Network and VPN Service Performance 862 Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work 863 in progress), April 2020. 865 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 866 DOI 10.17487/RFC3688, January 2004, 867 . 869 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 870 and A. Bierman, Ed., "Network Configuration Protocol 871 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 872 . 874 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 875 RFC 7950, DOI 10.17487/RFC7950, August 2016, 876 . 878 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 879 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 880 . 882 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 883 for Connection-Oriented Operations, Administration, and 884 Maintenance (OAM) Protocols", RFC 8531, 885 DOI 10.17487/RFC8531, April 2019, 886 . 888 12.2. Informative References 890 [I-D.ietf-ccamp-otn-tunnel-model] 891 Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, 892 "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 893 model-11 (work in progress), September 2020. 895 [I-D.ietf-ccamp-wson-tunnel-model] 896 Lee, Y., Zheng, H., Guo, A., Lopez, V., King, D., Yoon, 897 B., and R. Vilata, "A Yang Data Model for WSON Tunnel", 898 draft-ietf-ccamp-wson-tunnel-model-05 (work in progress), 899 March 2020. 901 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 902 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 903 . 905 Authors' Addresses 906 Haomian Zheng 907 Huawei Technologies 908 H1, Xiliu Beipo Village, Songshan Lake, 909 Dongguan, Guangdong 523808 910 China 912 Email: zhenghaomian@huawei.com 914 Italo Busi 915 Huawei Technologies 916 Italy 918 Email: Italo.Busi@huawei.com 920 Yanlei Zheng 921 China Unicom 922 China 924 Email: zhengyanlei@chinaunicom.cn