idnits 2.17.1 draft-zheng-ccamp-client-pm-yang-05.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 2 instances of too long lines in the document, the longest one being 4 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 185 has weird spacing: '...er-name ide...' == Line 189 has weird spacing: '...c-state enu...' -- The document date (6 January 2022) is 833 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-06 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-11 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-07 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-14 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-wson-tunnel-model-06 Summary: 1 error (**), 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: 10 July 2022 Y. Zheng 6 China Unicom 7 V. Lopez 8 Nokia 9 O. Gonzalez de Dios 10 Telefonica 11 6 January 2022 13 A YANG Data Model for Client Signal Performance Monitoring 14 draft-zheng-ccamp-client-pm-yang-05 16 Abstract 18 A transport network is a server-layer network to provide connectivity 19 services to its client. Given the client signal is configured, the 20 followup function for performance monitoring, such as latency and bit 21 error rate, would be needed for network operation. 23 This document describes the data model to support the performance 24 monitoring functionalities. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 10 July 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 61 3. Model Relationship . . . . . . . . . . . . . . . . . . . . . 3 62 4. Consideration on Monitoring Parameters . . . . . . . . . . . 4 63 5. OAM Configuration . . . . . . . . . . . . . . . . . . . . . . 4 64 6. YANG Model for Performance Monitoring . . . . . . . . . . . . 4 65 6.1. YANG Tree for Performance Monitoring . . . . . . . . . . 4 66 6.2. YANG Tree for OAM Configuration . . . . . . . . . . . . . 5 67 7. YANG Code for Performance Monitoring . . . . . . . . . . . . 6 68 7.1. The Performance Monitoring YANG Code . . . . . . . . . . 6 69 7.2. The OAM Configuration YANG Code . . . . . . . . . . . . . 14 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 71 9. Manageability Considerations . . . . . . . . . . . . . . . . 23 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 76 12.2. Informative References . . . . . . . . . . . . . . . . . 24 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 79 1. Introduction 81 Client-layer network and server-layer network have been respectively 82 modeled to allow the tunnels carrying the client traffic. Server- 83 layers are modeled as tunnels with various switching technologies, 84 such as OTN in [I-D.ietf-ccamp-otn-tunnel-model] and WSON in 85 [I-D.ietf-ccamp-wson-tunnel-model]. Client-layers are modeled as 86 client signals according to the client-signal identities specified in 87 [I-D.ietf-ccamp-layer1-types]. These client signals can be 88 configured to existing tunnels via the client signal configuration 89 model specified in [I-D.ietf-ccamp-client-signal-yang]. 91 In the network operation, the operator is interested in monitoring 92 their instantiated client signal over tunnels. The objective of such 93 monitoring is to complete timely adjustment once there is abnormal 94 statistic which may result in failure of the client signal. The 95 parameters specified in the performance monitoring model can be 96 collected for the operation need. The OAM mechanism, can be 97 configured together with the performance monitoring model. 99 2. Terminology and Notations 101 A simplified graphical representation of the data model is used in 102 this document. The meaning of the symbols in the YANG data tree 103 presented later in this document is defined in [RFC8340]. They are 104 provided below for reference. 106 * Brackets "[" and "]" enclose list keys. 108 * Abbreviations before data node names: "rw" means configuration 109 (read-write) and "ro" state data (read-only). 111 * Symbols after data node names: "?" means an optional node, "!" 112 means a presence container, and "*" denotes a list and leaf-list. 114 * Parentheses enclose choice and case nodes, and case nodes are also 115 marked with a colon (":"). 117 * Ellipsis ("...") stands for contents of subtrees that are not 118 shown. 120 3. Model Relationship 122 [I-D.ietf-ccamp-client-signal-yang] has specified the two models for 123 the client signal configuration, module ietf-trans-client-service for 124 transparent client service and module ietf-eth-tran-service for 125 Ethernet service. Basically the client signal types in this document 126 is consistent with ietf-eth-tran-types, and focus on different 127 functionality. On the perspective of operator, the modules in 128 [I-D.ietf-ccamp-client-signal-yang] can be used to configure the 129 service given any underlay tunnels, while the operation about 130 monitoring the performance on given service can be achieved by using 131 the model in this document. 133 Consideration on Key Performance Information (KPI) monitoring for 134 Virtual Network (VN) and tunnels has been specified in 135 [I-D.ietf-teas-actn-pm-telemetry-autonomics]. Usually the monitoring 136 on the tunnels are the VNs should be separately deployed for the 137 network operation, but it is possible to have common parameters that 138 are both needed for the VN/TE and the configured services. Common 139 types are imported in both modules. 141 VPN-level parameters and their monitoring have been defined in 142 [I-D.www-bess-yang-vpn-service-pm]. This module focus on the 143 performance on the topology at different layer or the overlay 144 topology between VPN sites. On the other hand, this document is 145 focusing on the performance of the service configured between 146 Customer Ends (CE). 148 4. Consideration on Monitoring Parameters 150 There can be multiple groups of parameters for monitoring, such as 151 latency, bit error rate (BER). Some of these parameters are layer- 152 dependent, for example, packet loss is only applicable in packet 153 networks are won't be neede for layer 1 OTN and layer 0 WSON. 155 This document starts with the specification of the latency 156 measurement for both Ethernet service and client signal service. In 157 the future version additional parameters would be added into the data 158 model in the same approach as the latency in the current version. A 159 candidate list of parameters to be monitored include: Latency, Packet 160 Loss, Bit Error Rate (BER), Jitter, Bandwidth, Byte/Packet number and 161 so on. 163 5. OAM Configuration 165 The operation, administration and maintenance protocols and data 166 models have been specified in [RFC8531] for the connection-oriented 167 network. The model is referenced in this work to develop an 168 Ethernet-specific OAM models, which is augmenting the service 169 performance monitoring data model. 171 The definitions of OAM terminologies, such as maintainence 172 Maintenance Domain (MD), Maintenance Association (MA), and 173 Maintenance End Points (MEP), can be found in [RFC8531] as well. 175 6. YANG Model for Performance Monitoring 177 6.1. YANG Tree for Performance Monitoring 178 module: ietf-service-pm 179 +--rw performance-monitoring 180 +--rw service-pm* [service-name] 181 +--rw service-name union 182 +--rw task-pm-enable? boolean 183 +--rw granularity? identityref 184 +--rw performance-data-config* [parameter-name] 185 | +--rw parameter-name identityref 186 | +--rw measure-method? identityref 187 +--ro service-pm-state 188 +--ro oam-state 189 | +--ro cc-state enumeration 190 | +--ro lm-state? enumeration 191 | +--ro dm-state? enumeration 192 +--ro performance-data* [parameter-name] 193 | +--ro parameter-name identityref 194 | +--ro parameter-value* [index] 195 | +--ro index uint64 196 | +--ro value performance-parameter-value 197 | +--ro value-unit string 198 | +--ro value-description? string 199 | +--ro start-time? yang:date-and-time 200 | +--ro end-time? yang:date-and-time 201 +--ro monitor-state identityref 202 +--ro error-info 203 | +--ro error-code? uint32 204 | +--ro error-message? string 205 +--ro alarm 206 +--ro status? identityref 208 6.2. YANG Tree for OAM Configuration 209 module: ietf-eth-service-oam 210 augment /svc-pm:performance-monitoring/svc-pm:service-pm: 211 +--rw oam-config 212 +--rw source 213 | +--rw md-name? string 214 | +--rw ma-name? string 215 | +--rw ma-level? string 216 | +--rw meg-id? string 217 | +--rw meg-level? string 218 | +--rw mep-id? uint8 219 | +--rw remote-mep-id? uint8 220 +--rw destination 221 | +--rw md-name? string 222 | +--rw ma-name? string 223 | +--rw ma-level? string 224 | +--rw meg-id? string 225 | +--rw meg-level? string 226 | +--rw mep-id? uint8 227 | +--rw remote-mep-id? uint8 228 +--rw cc-interval? identityref 229 +--rw lm-interval? identityref 230 +--rw dm-interval? identityref 232 7. YANG Code for Performance Monitoring 234 7.1. The Performance Monitoring YANG Code 236 file "ietf-service-pm@2021-07-07.yang" 237 module ietf-service-pm { 238 yang-version 1.1; 240 namespace "urn:ietf:params:xml:ns:yang:ietf-service-pm"; 241 prefix "svc-pm"; 243 import ietf-eth-tran-service { 244 prefix "ethtsvc"; 245 } 247 import ietf-yang-types { 248 prefix "yang"; 249 } 251 import ietf-trans-client-service { 252 prefix "clntsvc"; 253 } 255 organization 256 "Internet Engineering Task Force (IETF) CCAMP WG"; 257 contact 258 " 259 WG List: 260 ID-draft editor: 261 Haomian Zheng (zhenghaomian@huawei.com); 262 Italo Busi (italo.busi@huawei.com); 263 Yanlei Zheng (zhengyanlei@chinaunicom.cn); 264 Victor Lopez (victor.lopez@nokia.com); 265 Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com); 266 "; 268 description 269 "This module defines the performance monitoring for Ethernet 270 services. The model fully conforms to the Network Management 271 Datastore Architecture (NMDA). 273 Copyright (c) 2021 IETF Trust and the persons 274 identified as authors of the code. All rights reserved. 275 Redistribution and use in source and binary forms, with or 276 without modification, is permitted pursuant to, and subject 277 to the license terms contained in, the Simplified BSD License 278 set forth in Section 4.c of the IETF Trust's Legal Provisions 279 Relating to IETF Documents 280 (https://trustee.ietf.org/license-info). 281 This version of this YANG module is part of RFC XXXX; see 282 the RFC itself for full legal notices."; 284 revision 2021-07-07 { 285 description 286 "Initial version"; 287 reference 288 "ADD REFERENCE HERE"; 289 } 291 typedef performance-parameter-value { 292 type union { 293 type uint32; 294 type uint64; 295 type decimal64 { 296 fraction-digits 6; 297 } 298 type string; 299 } 300 description 301 "A performance parameter value."; 302 } 303 grouping service-performance-monitor-set{ 304 description "the set of parameter name, value and description."; 305 leaf parameter-name{ 306 type identityref { 307 base performance-parameter-type; 308 } 309 description 310 "The name of parameters to be monitored. 311 For example, latency, Bit Error Rate, Bandwidth and so on."; 312 } 313 list parameter-value { 314 key index; 315 description 316 "The table of values of the performance and 317 their descriptions."; 318 leaf index { 319 type uint64; 320 description 321 "Used for list index"; 322 } 323 leaf value { 324 type performance-parameter-value; 325 mandatory true; 326 description 327 "The value of the parameter. "; 328 } 329 leaf value-unit { 330 type string; 331 mandatory true; 332 description 333 "The value unit of the parameter. 334 For example, second, minute and so on."; 335 } 336 leaf value-description{ 337 type string; 338 description 339 "The description of previous value. "; 340 } 341 leaf start-time { 342 type yang:date-and-time; 343 description 344 "The time stamp when the parameter is started."; 345 } 346 leaf end-time { 347 type yang:date-and-time; 348 description 349 "The time stamp when the parameter is ended."; 350 } 352 } 353 } 355 identity performance-parameter-type { 356 description 357 "Base type of the performance parameter being monitored."; 358 } 360 identity near-frame-loss { 361 base performance-parameter-type; 362 description 363 "Near frame loss, using one-way eth loss measure, 364 the sampling point is the MEP."; 365 } 367 identity far-frame-loss { 368 base performance-parameter-type; 369 description 370 "Far frame loss, using one-way eth loss measure, 371 the sampling point is the MEP."; 372 } 374 identity one-way-delay { 375 base performance-parameter-type; 376 description 377 "One way delay."; 378 } 380 identity two-way-delay { 381 base performance-parameter-type; 382 description 383 "Two way delay."; 384 } 386 identity receive-packets { 387 base performance-parameter-type; 388 description 389 "Total number of received packets."; 390 } 392 identity transmit-packets { 393 base performance-parameter-type; 394 description 395 "Total number of transmitted packets."; 396 } 398 identity ingress-bandwidth { 399 base performance-parameter-type; 400 description 401 "Current bandwidth usage of the ingress traffic."; 402 } 404 identity egress-bandwidth { 405 base performance-parameter-type; 406 description 407 "Current bandwidth usage of the egress traffic."; 408 } 410 identity alarm-status { 411 description "indicates whether there is alarm or not"; 412 } 413 identity alarm { 414 base alarm-status; 415 description "There is one or multiple alarms from the monitor. "; 416 } 418 identity no-alarm { 419 base alarm-status; 420 description "There is no alarms from the monitor. "; 421 } 423 identity monitoring-state { 424 description 425 "The state of performance monitoring. "; 426 } 428 identity monitoring { 429 base monitoring-state; 430 description "The Ethernet client signal is under monitoring. "; 431 } 433 identity monitor-finished { 434 base monitoring-state; 435 description 436 "The monitoring of Ethernet client signal is finished. "; 437 } 439 identity monitor-failed { 440 base monitoring-state; 441 description 442 "The monitoring of Ethernet client signal is failed. "; 443 } 445 identity granularity-type { 446 description 447 "Monitoring granularity"; 449 } 451 identity granularity-1min { 452 base granularity-type; 453 description 454 "1 minute"; 455 } 457 identity granularity-15min { 458 base granularity-type; 459 description 460 "15 minutes"; 461 } 462 identity granularity-24h { 463 base granularity-type; 464 description 465 "24 hours"; 466 } 468 identity measure-method { 469 description "Measure method."; 470 } 472 identity measure-by-loopback { 473 base measure-method; 474 description "Loopback measure method."; 475 } 477 identity measure-at-ingress { 478 base measure-method; 479 description "Ingress measure method."; 480 } 482 container performance-monitoring { 483 description 484 "This part is for performance monitoring. "; 485 list service-pm { 486 key "service-name"; 487 description 488 "The list of service to be monitored."; 489 leaf service-name { 490 type union { 491 type leafref { 492 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 493 + "/ethtsvc:etht-svc-name"; 494 } 495 type leafref { 496 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 497 + "/clntsvc:client-svc-name"; 498 } 499 } 500 mandatory true; 501 description "The name of service."; 502 } 504 leaf task-pm-enable { 505 type boolean; 506 description 507 "Indicate whether the performance monitoring 508 is enable or not."; 509 } 511 leaf granularity { 512 type identityref { 513 base granularity-type; 514 } 515 description 516 "Monitoring granularity"; 517 } 519 list performance-data-config { 520 key parameter-name; 521 description 522 "Specify the performance parameters to be queried"; 524 leaf parameter-name { 525 type identityref { 526 base performance-parameter-type; 527 } 528 description 529 "The name of parameters to be monitored. 530 For example, latency, BER, Bandwidth and so on."; 531 } 532 leaf measure-method { 533 type identityref { 534 base measure-method; 535 } 536 description "Measure Methods."; 537 } 538 } 540 container service-pm-state { 541 config false; 542 description 543 "The state of service performance monitoring."; 545 container oam-state { 546 description "the state of OAM. "; 547 leaf cc-state { 548 type enumeration { 549 enum up { 550 description "up"; 551 } 552 enum down { 553 description "down"; 554 } 555 } 556 mandatory true; 557 description 558 "The state of continuity check."; 559 } 560 leaf lm-state { 561 type enumeration { 562 enum up { 563 description "up"; 564 } 565 enum down { 566 description "down"; 567 } 568 } 569 description 570 "The state of loss measurement."; 571 } 572 leaf dm-state { 573 type enumeration { 574 enum up { 575 description "up"; 576 } 577 enum down{ 578 description "down"; 579 } 580 } 581 description 582 "The state of delay measurement."; 583 } 584 } 586 list performance-data{ 587 key parameter-name; 588 description "The list of performance under monitor."; 589 uses service-performance-monitor-set; 590 } 592 leaf monitor-state { 593 type identityref { 594 base monitoring-state; 595 } 596 mandatory true; 597 description "The status of performance monitoring. "; 598 } 600 container error-info { 601 description 602 "Describe the error message."; 603 leaf error-code { 604 type uint32; 605 description 606 "The code of error."; 607 } 608 leaf error-message { 609 type string; 610 description 611 "The message of error."; 612 } 613 } 615 container alarm { 616 description 617 "To retrieve the Alarm during performance Monitoring."; 618 leaf status { 619 type identityref { 620 base alarm-status; 621 } 622 description "The status of the alarm. "; 623 } 624 } 625 } 626 } 627 } 629 } 630 632 7.2. The OAM Configuration YANG Code 634 file "ietf-eth-service-oam@2021-07-10.yang" 635 module ietf-eth-service-oam { 636 yang-version 1.1; 638 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-service-oam"; 639 prefix "eth-oam"; 640 import ietf-eth-tran-service { 641 prefix "ethtsvc"; 642 } 644 import ietf-service-pm { 645 prefix "svc-pm"; 646 } 648 import ietf-trans-client-service { 649 prefix "clntsvc"; 650 } 652 import ietf-network { 653 prefix nw; 654 } 656 organization 657 "Internet Engineering Task Force (IETF) CCAMP WG"; 658 contact 659 " 660 WG List: 661 ID-draft editor: 662 Haomian Zheng (zhenghaomian@huawei.com); 663 Italo Busi (italo.busi@huawei.com); 664 Yanlei Zheng (zhengyanlei@chinaunicom.cn); 665 Victor Lopez (victor.lopez@nokia.com); 666 Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com); 667 "; 669 description 670 "This module defines the performance monitoring for Ethernet 671 services OAM. The model fully conforms to the Network Management 672 Datastore Architecture (NMDA). 674 Copyright (c) 2021 IETF Trust and the persons 675 identified as authors of the code. All rights reserved. 676 Redistribution and use in source and binary forms, with or 677 without modification, is permitted pursuant to, and subject 678 to the license terms contained in, the Simplified BSD License 679 set forth in Section 4.c of the IETF Trust's Legal Provisions 680 Relating to IETF Documents 681 (https://trustee.ietf.org/license-info). 682 This version of this YANG module is part of RFC XXXX; see 683 the RFC itself for full legal notices."; 685 revision 2021-07-10 { 686 description 687 "Initial version"; 689 reference 690 "ADD REFERENCE HERE"; 691 } 693 identity interval-type { 694 description "Time interval"; 695 } 697 identity interval-3p33ms { 698 base interval-type; 699 description "3.33 milliseconds"; 700 } 702 identity interval-10ms { 703 base interval-type; 704 description "10 milliseconds"; 705 } 707 identity interval-100ms { 708 base interval-type; 709 description "100 milliseconds"; 710 } 712 identity interval-1s { 713 base interval-type; 714 description "1 second"; 715 } 717 identity interval-10s { 718 base interval-type; 719 description "10 seconds"; 720 } 722 identity interval-1m { 723 base interval-type; 724 description "1 minute"; 725 } 727 identity interval-10m { 728 base interval-type; 729 description "10 minutes"; 730 } 732 grouping eth-service-oam-config { 733 container source { 734 uses mep-config; 735 description "OAM MEP configuration on source node."; 736 } 738 container destination { 739 uses mep-config; 740 description "OAM MEP configuration on destination node."; 741 } 742 uses interval-config; 743 description "OAM configuration on Eth services."; 744 } 746 grouping interval-config { 747 description "OAM Interval Configuration."; 748 leaf cc-interval { 749 type identityref { 750 base interval-type; 751 } 752 description "Continuity check interval."; 753 } 755 leaf lm-interval { 756 type identityref { 757 base interval-type; 758 } 759 description "Loss measurement interval."; 760 } 762 leaf dm-interval { 763 type identityref { 764 base interval-type; 765 } 766 description "Delay measurement interval."; 767 } 768 } 770 grouping mep-config { 771 description "OAM MEP Configuration."; 772 leaf md-name { 773 type string; 774 description 775 "Name of Maintenance Domain."; 776 } 777 leaf ma-name { 778 type string; 779 description 780 "Name of Maintenance Domain. 781 An maintenance association(MA) is a part of an MD. 782 An MD can be divided into one or more MAs. "; 783 } 785 leaf ma-level { 786 type string; 787 description 788 "Maintenance Association Level."; 789 } 791 leaf meg-id { 792 type string; 793 description 794 "Comply with Y.1731 term, mapping with 802.lag MA name."; 795 } 796 leaf meg-level { 797 type string; 798 description "Mapping with 802.lag MA level."; 799 } 801 leaf mep-id { 802 type uint8; 803 description "0 if Abnormal"; 804 } 806 leaf remote-mep-id { 807 type uint8; 808 description "The remote MEP ID must be specified."; 809 } 810 } 812 augment "/svc-pm:performance-monitoring/svc-pm:service-pm" { 813 description 814 "Augment with additional parameters required for Ethernet OAM"; 816 container oam-config { 817 description "OAM configuration container."; 818 uses eth-service-oam-config; 819 } 820 } 822 grouping errors { 823 description "The grouping of error information."; 824 leaf error-code { 825 type uint32; 826 description "The error code."; 827 } 829 leaf error-message { 830 type string; 831 description "The error message."; 832 } 834 } 836 /* 837 * Operations 838 */ 839 rpc configure-oam { 840 description "Deliver OAM configurations. "; 842 input { 843 list oam-config-list { 844 key "service-name"; 845 description 846 "The request list of service oam to be configured."; 847 leaf service-name { 848 type union { 849 type leafref { 850 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 851 + "/ethtsvc:etht-svc-name"; 852 } 853 type leafref { 854 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 855 + "/clntsvc:client-svc-name"; 856 } 858 } 859 mandatory true; 860 description "The name of service."; 861 } 862 uses eth-service-oam-config; 863 } 864 } 866 output { 867 list oam-config-list { 868 key "service-name"; 869 description "The OAM configuration list. "; 870 leaf service-name { 871 type union { 872 type leafref { 873 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 874 + "/ethtsvc:etht-svc-name"; 875 } 876 type leafref { 877 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 878 + "/clntsvc:client-svc-name"; 879 } 880 } 881 mandatory true; 882 description "The name of service."; 883 } 884 } 885 leaf result { 886 type enumeration { 887 enum success { 888 description "success"; 889 } 890 enum failure { 891 description "failure"; 892 } 893 } 894 description "Result of OAM configuration."; 895 } 896 uses errors; 898 } 899 } 901 rpc delete-oam-configurations { 902 description "Delete OAM configurations. "; 903 input { 904 list service-list { 905 key "service-name"; 906 leaf service-name { 907 type union { 908 type leafref { 909 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 910 + "/ethtsvc:etht-svc-name"; 911 } 912 type leafref { 913 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 914 + "/clntsvc:client-svc-name"; 915 } 916 } 917 mandatory true; 918 description "The name of service."; 919 } 920 description "The list of service."; 921 } 922 } 924 output { 925 list oam-config-list { 926 key "service-name"; 927 leaf service-name { 928 type union { 929 type leafref { 930 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 931 + "/ethtsvc:etht-svc-name"; 932 } 933 type leafref { 934 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 935 + "/clntsvc:client-svc-name"; 936 } 937 } 938 mandatory true; 939 description "The name of service."; 940 } 942 leaf result { 943 type enumeration { 944 enum success { 945 description "success"; 946 } 947 enum failure { 948 description "failure"; 949 } 950 } 951 description "The result of OAM deletion."; 952 } 954 uses errors; 955 description "The list of service."; 956 } 957 } 958 } 960 rpc get-node-eth-oam-configurations { 961 description "Get the Eth node OAM configuration info."; 962 input { 963 leaf-list te-node-list { 964 type leafref { 965 path "/nw:networks/nw:network/nw:node/nw:node-id"; 966 } 967 description 968 "Node identifier. Must be same in the topology."; 969 } 970 } 972 output { 973 list oam-list { 974 leaf node-id { 975 type leafref { 976 path "/nw:networks/nw:network/nw:node/nw:node-id"; 977 } 978 description "The node identifier."; 979 } 980 list mep-config-list { 981 key "md-name ma-name meg-id mep-id"; 982 uses mep-config; 983 description "The list of MEP configuration."; 984 } 985 description "The list of OAM."; 986 } 987 } 988 } 989 } 990 992 8. IANA Considerations 994 It is proposed that IANA should assign new URIs from the "IETF XML 995 Registry" [RFC3688] as follows: 997 URI: urn:ietf:params:xml:ns:yang:ietf-service-pm 998 Registrant Contact: The IESG 999 XML: N/A; the requested URI is an XML namespace. 1001 URI: urn:ietf:params:xml:ns:yang:ietf-eth-service-oam 1002 Registrant Contact: The IESG 1003 XML: N/A; the requested URI is an XML namespace. 1005 This document registers following YANG modules in the YANG Module 1006 Names registry [RFC7950]. 1008 name: ietf-service-pm 1009 namespace: urn:ietf:params:xml:ns:yang:ietf-service-pm 1010 prefix: svc-pm 1011 reference: RFC XXXX (This document) 1013 name: ietf-eth-service-oam 1014 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-service-oam 1015 prefix: eth-oam 1016 reference: RFC XXXX (This document) 1018 9. Manageability Considerations 1020 TBD. 1022 10. Security Considerations 1024 The data following the model defined in this document is exchanged 1025 via, for example, the interface between an orchestrator and a 1026 transport network controller. The security concerns mentioned in 1027 [I-D.ietf-ccamp-client-signal-yang] also applies to this document. 1029 The YANG module defined in this document can be accessed via the 1030 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 1031 protocol [RFC6241]. 1033 11. Contributors 1035 Chaode YU Huawei Technologies, Email: yuchaode@huawei.com 1037 12. References 1039 12.1. Normative References 1041 [I-D.ietf-ccamp-client-signal-yang] 1042 Zheng, H., Guo, A., Busi, I., Snitser, A., and F. Lazzeri, 1043 "A YANG Data Model for Transport Network Client Signals", 1044 Work in Progress, Internet-Draft, draft-ietf-ccamp-client- 1045 signal-yang-06, 5 January 2022, 1046 . 1049 [I-D.ietf-ccamp-layer1-types] 1050 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 1051 Types", Work in Progress, Internet-Draft, draft-ietf- 1052 ccamp-layer1-types-11, 7 September 2021, 1053 . 1056 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1057 Lee, Y., Dhody, D., Karunanithi, S., Vilalta, R., King, 1058 D., and D. Ceccarelli, "YANG models for VN/TE Performance 1059 Monitoring Telemetry and Scaling Intent Autonomics", Work 1060 in Progress, Internet-Draft, draft-ietf-teas-actn-pm- 1061 telemetry-autonomics-07, 23 October 2021, 1062 . 1065 [I-D.www-bess-yang-vpn-service-pm] 1066 Wu, Q., Boucadair, M., Dios, O. G. D., Wen, B., Liu, C., 1067 and H. Xu, "A YANG Model for Network and VPN Service 1068 Performance Monitoring", Work in Progress, Internet-Draft, 1069 draft-www-bess-yang-vpn-service-pm-06, 22 April 2020, 1070 . 1073 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1074 DOI 10.17487/RFC3688, January 2004, 1075 . 1077 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1078 and A. Bierman, Ed., "Network Configuration Protocol 1079 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1080 . 1082 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1083 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1084 . 1086 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1087 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1088 . 1090 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1091 for Connection-Oriented Operations, Administration, and 1092 Maintenance (OAM) Protocols", RFC 8531, 1093 DOI 10.17487/RFC8531, April 2019, 1094 . 1096 12.2. Informative References 1098 [I-D.ietf-ccamp-otn-tunnel-model] 1099 Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, 1100 "OTN Tunnel YANG Model", Work in Progress, Internet-Draft, 1101 draft-ietf-ccamp-otn-tunnel-model-14, 12 July 2021, 1102 . 1105 [I-D.ietf-ccamp-wson-tunnel-model] 1106 Lee, Y., Zheng, H., Guo, A., Lopez, V., King, D., Yoon, B. 1107 Y., and R. Vilalta, "A Yang Data Model for WSON Tunnel", 1108 Work in Progress, Internet-Draft, draft-ietf-ccamp-wson- 1109 tunnel-model-06, 22 October 2021, 1110 . 1113 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1114 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1115 . 1117 Authors' Addresses 1119 Haomian Zheng 1120 Huawei Technologies 1121 H1, Xiliu Beipo Village, Songshan Lake, 1122 Dongguan 1123 Guangdong, 523808 1124 China 1126 Email: zhenghaomian@huawei.com 1128 Italo Busi 1129 Huawei Technologies 1130 Italy 1132 Email: Italo.Busi@huawei.com 1134 Yanlei Zheng 1135 China Unicom 1136 China 1138 Email: zhengyanlei@chinaunicom.cn 1140 Victor Lopez 1141 Nokia 1142 Spain 1144 Email: victor.lopez@nokia.com 1146 Oscar Gonzalez de Dios 1147 Telefonica 1148 Spain 1150 Email: oscar.gonzalezdedios@telefonica.com