idnits 2.17.1 draft-zheng-ccamp-client-pm-yang-04.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 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 186 has weird spacing: '...er-name ide...' == Line 190 has weird spacing: '...c-state enu...' -- The document date (July 10, 2021) is 1019 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-04 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-10 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-05 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-13 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-wson-tunnel-model-05 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: January 11, 2022 Y. Zheng 6 China Unicom 7 V. Lopez 8 Nokia 9 O. Gonzalez de Dios 10 Telefonica 11 July 10, 2021 13 A YANG Data Model for Client Signal Performance Monitoring 14 draft-zheng-ccamp-client-pm-yang-04 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 January 11, 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 62 3. Model Relationship . . . . . . . . . . . . . . . . . . . . . 3 63 4. Consideration on Monitoring Parameters . . . . . . . . . . . 4 64 5. OAM Configuration . . . . . . . . . . . . . . . . . . . . . . 4 65 6. YANG Model for Performance Monitoring . . . . . . . . . . . . 4 66 6.1. YANG Tree for Performance Monitoring . . . . . . . . . . 4 67 6.2. YANG Tree for OAM Configuration . . . . . . . . . . . . . 5 68 7. YANG Code for Performance Monitoring . . . . . . . . . . . . 6 69 7.1. The Performance Monitoring YANG Code . . . . . . . . . . 6 70 7.2. The OAM Configuration YANG Code . . . . . . . . . . . . . 14 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 72 9. Manageability Considerations . . . . . . . . . . . . . . . . 23 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 74 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 77 12.2. Informative References . . . . . . . . . . . . . . . . . 24 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 80 1. Introduction 82 Client-layer network and server-layer network have been respectively 83 modeled to allow the tunnels carrying the client traffic. Server- 84 layers are modeled as tunnels with various switching technologies, 85 such as OTN in [I-D.ietf-ccamp-otn-tunnel-model] and WSON in 86 [I-D.ietf-ccamp-wson-tunnel-model]. Client-layers are modeled as 87 client signals according to the client-signal identities specified in 88 [I-D.ietf-ccamp-layer1-types]. These client signals can be 89 configured to existing tunnels via the client signal configuration 90 model specified in [I-D.ietf-ccamp-client-signal-yang]. 92 In the network operation, the operator is interested in monitoring 93 their instantiated client signal over tunnels. The objective of such 94 monitoring is to complete timely adjustment once there is abnormal 95 statistic which may result in failure of the client signal. The 96 parameters specified in the performance monitoring model can be 97 collected for the operation need. The OAM mechanism, can be 98 configured together with the performance monitoring model. 100 2. Terminology and Notations 102 A simplified graphical representation of the data model is used in 103 this document. The meaning of the symbols in the YANG data tree 104 presented later in this document is defined in [RFC8340]. They are 105 provided below for reference. 107 o Brackets "[" and "]" enclose list keys. 109 o Abbreviations before data node names: "rw" means configuration 110 (read-write) and "ro" state data (read-only). 112 o Symbols after data node names: "?" means an optional node, "!" 113 means a presence container, and "*" denotes a list and leaf-list. 115 o Parentheses enclose choice and case nodes, and case nodes are also 116 marked with a colon (":"). 118 o Ellipsis ("...") stands for contents of subtrees that are not 119 shown. 121 3. Model Relationship 123 [I-D.ietf-ccamp-client-signal-yang] has specified the two models for 124 the client signal configuration, module ietf-trans-client-service for 125 transparent client service and module ietf-eth-tran-service for 126 Ethernet service. Basically the client signal types in this document 127 is consistent with ietf-eth-tran-types, and focus on different 128 functionality. On the perspective of operator, the modules in 129 [I-D.ietf-ccamp-client-signal-yang] can be used to configure the 130 service given any underlay tunnels, while the operation about 131 monitoring the performance on given service can be achieved by using 132 the model in this document. 134 Consideration on Key Performance Information (KPI) monitoring for 135 Virtual Network (VN) and tunnels has been specified in 136 [I-D.ietf-teas-actn-pm-telemetry-autonomics]. Usually the monitoring 137 on the tunnels are the VNs should be separately deployed for the 138 network operation, but it is possible to have common parameters that 139 are both needed for the VN/TE and the configured services. Common 140 types are imported in both modules. 142 VPN-level parameters and their monitoring have been defined in 143 [I-D.www-bess-yang-vpn-service-pm]. This module focus on the 144 performance on the topology at different layer or the overlay 145 topology between VPN sites. On the other hand, this document is 146 focusing on the performance of the service configured between 147 Customer Ends (CE). 149 4. Consideration on Monitoring Parameters 151 There can be multiple groups of parameters for monitoring, such as 152 latency, bit error rate (BER). Some of these parameters are layer- 153 dependent, for example, packet loss is only applicable in packet 154 networks are won't be neede for layer 1 OTN and layer 0 WSON. 156 This document starts with the specification of the latency 157 measurement for both Ethernet service and client signal service. In 158 the future version additional parameters would be added into the data 159 model in the same approach as the latency in the current version. A 160 candidate list of parameters to be monitored include: Latency, Packet 161 Loss, Bit Error Rate (BER), Jitter, Bandwidth, Byte/Packet number and 162 so on. 164 5. OAM Configuration 166 The operation, administration and maintenance protocols and data 167 models have been specified in [RFC8531] for the connection-oriented 168 network. The model is referenced in this work to develop an 169 Ethernet-specific OAM models, which is augmenting the service 170 performance monitoring data model. 172 The definitions of OAM terminologies, such as maintainence 173 Maintenance Domain (MD), Maintenance Association (MA), and 174 Maintenance End Points (MEP), can be found in [RFC8531] as well. 176 6. YANG Model for Performance Monitoring 178 6.1. YANG Tree for Performance Monitoring 179 module: ietf-service-pm 180 +--rw performance-monitoring 181 +--rw service-pm* [service-name] 182 +--rw service-name union 183 +--rw task-pm-enable? boolean 184 +--rw granularity? identityref 185 +--rw performance-data-config* [parameter-name] 186 | +--rw parameter-name identityref 187 | +--rw measure-method? identityref 188 +--ro service-pm-state 189 +--ro oam-state 190 | +--ro cc-state enumeration 191 | +--ro lm-state? enumeration 192 | +--ro dm-state? enumeration 193 +--ro performance-data* [parameter-name] 194 | +--ro parameter-name identityref 195 | +--ro parameter-value* [index] 196 | +--ro index uint64 197 | +--ro value performance-parameter-value 198 | +--ro value-unit string 199 | +--ro value-description? string 200 | +--ro start-time? yang:date-and-time 201 | +--ro end-time? yang:date-and-time 202 +--ro monitor-state identityref 203 +--ro error-info 204 | +--ro error-code? uint32 205 | +--ro error-message? string 206 +--ro alarm 207 +--ro status? identityref 209 6.2. YANG Tree for OAM Configuration 210 module: ietf-eth-service-oam 211 augment /svc-pm:performance-monitoring/svc-pm:service-pm: 212 +--rw oam-config 213 +--rw source 214 | +--rw md-name? string 215 | +--rw ma-name? string 216 | +--rw ma-level? string 217 | +--rw meg-id? string 218 | +--rw meg-level? string 219 | +--rw mep-id? uint8 220 | +--rw remote-mep-id? uint8 221 +--rw destination 222 | +--rw md-name? string 223 | +--rw ma-name? string 224 | +--rw ma-level? string 225 | +--rw meg-id? string 226 | +--rw meg-level? string 227 | +--rw mep-id? uint8 228 | +--rw remote-mep-id? uint8 229 +--rw cc-interval? identityref 230 +--rw lm-interval? identityref 231 +--rw dm-interval? identityref 233 7. YANG Code for Performance Monitoring 235 7.1. The Performance Monitoring YANG Code 237 file "ietf-service-pm@2021-07-07.yang" 238 module ietf-service-pm { 239 yang-version 1.1; 241 namespace "urn:ietf:params:xml:ns:yang:ietf-service-pm"; 242 prefix "svc-pm"; 244 import ietf-eth-tran-service { 245 prefix "ethtsvc"; 246 } 248 import ietf-yang-types { 249 prefix "yang"; 250 } 252 import ietf-trans-client-service { 253 prefix "clntsvc"; 254 } 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 } 631 633 7.2. The OAM Configuration YANG Code 635 file "ietf-eth-service-oam@2021-07-10.yang" 636 module ietf-eth-service-oam { 637 yang-version 1.1; 638 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-service-oam"; 639 prefix "eth-oam"; 641 import ietf-eth-tran-service { 642 prefix "ethtsvc"; 643 } 645 import ietf-service-pm { 646 prefix "svc-pm"; 647 } 649 import ietf-trans-client-service { 650 prefix "clntsvc"; 651 } 653 import ietf-network { 654 prefix nw; 655 } 657 organization 658 "Internet Engineering Task Force (IETF) CCAMP WG"; 659 contact 660 " 661 WG List: 662 ID-draft editor: 663 Haomian Zheng (zhenghaomian@huawei.com); 664 Italo Busi (italo.busi@huawei.com); 665 Yanlei Zheng (zhengyanlei@chinaunicom.cn); 666 Victor Lopez (victor.lopez@nokia.com); 667 Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com); 668 "; 670 description 671 "This module defines the performance monitoring for Ethernet 672 services OAM. The model fully conforms to the Network Management 673 Datastore Architecture (NMDA). 675 Copyright (c) 2021 IETF Trust and the persons 676 identified as authors of the code. All rights reserved. 677 Redistribution and use in source and binary forms, with or 678 without modification, is permitted pursuant to, and subject 679 to the license terms contained in, the Simplified BSD License 680 set forth in Section 4.c of the IETF Trust's Legal Provisions 681 Relating to IETF Documents 682 (https://trustee.ietf.org/license-info). 683 This version of this YANG module is part of RFC XXXX; see 684 the RFC itself for full legal notices."; 686 revision 2021-07-10 { 687 description 688 "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 } 737 container destination { 738 uses mep-config; 739 description "OAM MEP configuration on destination node."; 740 } 741 uses interval-config; 742 description "OAM configuration on Eth services."; 743 } 745 grouping interval-config { 746 description "OAM Interval Configuration."; 747 leaf cc-interval { 748 type identityref { 749 base interval-type; 750 } 751 description "Continuity check interval."; 752 } 754 leaf lm-interval { 755 type identityref { 756 base interval-type; 757 } 758 description "Loss measurement interval."; 759 } 761 leaf dm-interval { 762 type identityref { 763 base interval-type; 764 } 765 description "Delay measurement interval."; 766 } 767 } 769 grouping mep-config { 770 description "OAM MEP Configuration."; 771 leaf md-name { 772 type string; 773 description 774 "Name of Maintenance Domain."; 775 } 776 leaf ma-name { 777 type string; 778 description 779 "Name of Maintenance Domain. 780 An maintenance association(MA) is a part of an MD. 781 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 } 833 } 835 /* 836 * Operations 837 */ 838 rpc configure-oam { 839 description "Deliver OAM configurations. "; 841 input { 842 list oam-config-list { 843 key "service-name"; 844 description 845 "The request list of service oam to be configured."; 846 leaf service-name { 847 type union { 848 type leafref { 849 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 850 + "/ethtsvc:etht-svc-name"; 851 } 852 type leafref { 853 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 854 + "/clntsvc:client-svc-name"; 855 } 857 } 858 mandatory true; 859 description "The name of service."; 860 } 861 uses eth-service-oam-config; 862 } 863 } 865 output { 866 list oam-config-list { 867 key "service-name"; 868 description "The OAM configuration list. "; 869 leaf service-name { 870 type union { 871 type leafref { 872 path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" 873 + "/ethtsvc:etht-svc-name"; 874 } 875 type leafref { 876 path "/clntsvc:client-svc/clntsvc:client-svc-instances" 877 + "/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 } 991 993 8. IANA Considerations 995 It is proposed that IANA should assign new URIs from the "IETF XML 996 Registry" [RFC3688] as follows: 998 URI: urn:ietf:params:xml:ns:yang:ietf-service-pm 999 Registrant Contact: The IESG 1000 XML: N/A; the requested URI is an XML namespace. 1002 URI: urn:ietf:params:xml:ns:yang:ietf-eth-service-oam 1003 Registrant Contact: The IESG 1004 XML: N/A; the requested URI is an XML namespace. 1006 This document registers following YANG modules in the YANG Module 1007 Names registry [RFC7950]. 1009 name: ietf-service-pm 1010 namespace: urn:ietf:params:xml:ns:yang:ietf-service-pm 1011 prefix: svc-pm 1012 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 1036 Huawei Technologies, 1037 Email: yuchaode@huawei.com 1039 12. References 1041 12.1. Normative References 1043 [I-D.ietf-ccamp-client-signal-yang] 1044 Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F., 1045 Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data 1046 Model for Transport Network Client Signals", draft-ietf- 1047 ccamp-client-signal-yang-04 (work in progress), January 1048 2021. 1050 [I-D.ietf-ccamp-layer1-types] 1051 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 1052 Types", draft-ietf-ccamp-layer1-types-10 (work in 1053 progress), February 2021. 1055 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1056 Lee, Y., Dhody, D., Karunanithi, S., Vilalta, R., King, 1057 D., and D. Ceccarelli, "YANG models for VN/TE Performance 1058 Monitoring Telemetry and Scaling Intent Autonomics", 1059 draft-ietf-teas-actn-pm-telemetry-autonomics-05 (work in 1060 progress), February 2021. 1062 [I-D.www-bess-yang-vpn-service-pm] 1063 Wu, Q., Boucadair, M., Dios, O. G. D., Wen, B., Liu, C., 1064 and H. Xu, "A YANG Model for Network and VPN Service 1065 Performance Monitoring", draft-www-bess-yang-vpn-service- 1066 pm-06 (work in progress), April 2020. 1068 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1069 DOI 10.17487/RFC3688, January 2004, 1070 . 1072 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1073 and A. Bierman, Ed., "Network Configuration Protocol 1074 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1075 . 1077 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1078 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1079 . 1081 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1082 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1083 . 1085 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1086 for Connection-Oriented Operations, Administration, and 1087 Maintenance (OAM) Protocols", RFC 8531, 1088 DOI 10.17487/RFC8531, April 2019, 1089 . 1091 12.2. Informative References 1093 [I-D.ietf-ccamp-otn-tunnel-model] 1094 Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, 1095 "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 1096 model-13 (work in progress), April 2021. 1098 [I-D.ietf-ccamp-wson-tunnel-model] 1099 Lee, Y., Zheng, H., Guo, A., Lopez, V., King, D., Yoon, B. 1100 Y., and R. Vilalta, "A Yang Data Model for WSON Tunnel", 1101 draft-ietf-ccamp-wson-tunnel-model-05 (work in progress), 1102 March 2020. 1104 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1105 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1106 . 1108 Authors' Addresses 1110 Haomian Zheng 1111 Huawei Technologies 1112 H1, Xiliu Beipo Village, Songshan Lake, 1113 Dongguan, Guangdong 523808 1114 China 1116 Email: zhenghaomian@huawei.com 1118 Italo Busi 1119 Huawei Technologies 1120 Italy 1122 Email: Italo.Busi@huawei.com 1124 Yanlei Zheng 1125 China Unicom 1126 China 1128 Email: zhengyanlei@chinaunicom.cn 1130 Victor Lopez 1131 Nokia 1132 Spain 1134 Email: victor.lopez@nokia.com 1136 Oscar Gonzalez de Dios 1137 Telefonica 1138 Spain 1140 Email: oscar.gonzalezdedios@telefonica.com