--- 1/draft-ietf-opsawg-service-assurance-yang-01.txt 2022-01-04 04:13:23.736127543 -0800 +++ 2/draft-ietf-opsawg-service-assurance-yang-02.txt 2022-01-04 04:13:23.812129438 -0800 @@ -1,24 +1,24 @@ OPSAWG B. Claise Internet-Draft J. Quilbeuf Intended status: Standards Track Huawei -Expires: January 3, 2022 P. Lucente +Expires: 8 July 2022 P. Lucente NTT P. Fasano TIM S.p.A T. Arumugam Cisco Systems, Inc. - July 2, 2021 + 4 January 2022 YANG Modules for Service Assurance - draft-ietf-opsawg-service-assurance-yang-01 + draft-ietf-opsawg-service-assurance-yang-02 Abstract This document proposes YANG modules for the Service Assurance for Intent-based Networking Architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -26,76 +26,76 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 3, 2022. + This Internet-Draft will expire on 8 July 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 5. Subservice Extension: ietf-service-assurance-device YANG - module . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + module . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 14 - 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 + 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16 6. Subservice Extension: ietf-service-assurance-interface YANG - module . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + module . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20 - 7. Vendor-specific Subservice Extension: example-service- - assurance-device-acme YANG module . . . . . . . . . . . . . . 22 + 7. Vendor-specific Subservice Extension: + example-service-assurance-device-acme YANG module . . . . 22 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22 - 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 23 + 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 8. Further Extensions: IP Connectivity and IS-IS subservices . . 26 8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26 8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26 - 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 26 + 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 27 8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28 8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30 - 9. Guidelines for Specific Subservice Extension . . . . . . . . 31 + 9. Guidelines for Specific Subservice Extension . . . . . . . . 32 9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32 - 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 32 + 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 33 9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34 11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . 35 13.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Example of YANG instances . . . . . . . . . . . . . 36 Appendix B. YANG Library for Service Assurance . . . . . . . . . 40 @@ -116,46 +116,46 @@ 2. Introduction The "Service Assurance for Intent-based Networking Architecture" draft-ietf-opsawg-service-assurance-architecture, specifies the architecture and all of its components for service assurance. This document complements the architecture by providing open interfaces between components. More specifically, the goal is to provide YANG modules for the purpose of service assurance in a format that is: - o machine readable + * machine readable - o vendor independent + * vendor independent - o augmentable + * augmentable 3. YANG Models Overview The main YANG module, ietf-service-assurance, defines objects for assuring network services based on their decomposition into so-called subservices. The subservices are hierarchically organised by dependencies. The subservices, along with the dependencies, constitute an assurance graph. This module should be supported by an agent, able to interact with the devices in order to produce a health status and symptoms for each subservice in the assurance graph. This module is intended for the following use cases: - o Assurance graph configuration: + * Assurance graph configuration: - * Subservices: configure a set of subservices to assure, by + - Subservices: configure a set of subservices to assure, by specifying their types and parameters. - * Dependencies: configure the dependencies between the + - Dependencies: configure the dependencies between the subservices, along with their type. - o Assurance telemetry: export the health status of the subservices, + * Assurance telemetry: export the health status of the subservices, along with the observed symptoms. The second YANG module, ietf-service-assurance-device, extends the ietf-service-assurance module to add support for the subservice DeviceHealthy. Additional subservice types might be added the same way. The third YANG module, ietf-service-assurance-device, is another example that extends the ietf-service-assurance-device module. This extension adds support for the subservice InterfaceHealthy. @@ -187,21 +187,21 @@ +--rw id string +--ro last-change? yang:date-and-time +--ro label? string +--rw under-maintenance? boolean +--rw maintenance-contact string +--rw (parameter)? | +--:(service-instance-parameter) | +--rw service-instance-parameter | +--rw service string | +--rw instance-name string - +--ro health-score? uint8 + +--ro health-score? union +--ro symptoms-history-start? yang:date-and-time +--rw symptoms | +--ro symptom* [start-date-time id] | +--ro id string | +--ro health-score-weight? uint8 | +--ro description? string | +--ro start-date-time yang:date-and-time | +--ro stop-date-time? yang:date-and-time +--rw dependencies +--rw dependency* [type id] @@ -209,25 +209,25 @@ +--rw id -> /subservices/subservice[type=current()/../type]/id +--rw dependency-type? identityref 4.2. Concepts The ietf-service-assurance YANG model assumes an identified number of subservices, to be assured independently. A subservice is a feature or a subpart of the network system that a given service instance might depend on. Example of subservices include: - o DeviceHealthy: whether a device is healthy, and if not, what are + * DeviceHealthy: whether a device is healthy, and if not, what are the symptoms. Potential symptoms are "CPU overloaded", "Out of RAM", or "Out of TCAM". - o ConnectivityHealthy: given two IP addresses owned by two devices, + * ConnectivityHealthy: given two IP addresses owned by two devices, what is the quality of the connection between them. Potential symptoms are "No route available" or "ECMP Imbalance". The first example is a subservice representing a subpart of the network system, while the second is a subservice representing a feature of the network, In both cases, these subservices might depend on other subservices, for instance, the connectivity might depend on a subservice representing the routing mechanism and on a subservice representing ECMP. @@ -238,36 +238,36 @@ which the symptom was detected and stopped being detected. While the unique id is sufficient as an unique key list, the start-date-time second key help sorting and retrieving relevant symptoms. The assurance of a given service instance can be obtained by composing the assurance of the subservices that it depends on, via the dependency relations. A subservice declaration MUST provide: - o A type: identity inheriting of the base identity for subservice, + * A type: identity inheriting of the base identity for subservice, - o An id: string uniquely identifying the subservice among those with + * An id: string uniquely identifying the subservice among those with the same identity, - o One or more parameters, which should be specified in an augmenting + * One or more parameters, which should be specified in an augmenting model, as described in the next sections. The type and id uniquely identify a given subservice. They are used to indicate the dependencies. Dependencies have types as well. Two types are specified in the model: - o Impacting: such a dependency indicates an impact on the health of + * Impacting: such a dependency indicates an impact on the health of the dependent, - o Informational: such a dependency might explain why the dependent + * Informational: such a dependency might explain why the dependent has issues but does not impact its health. To illustrate the difference between "impacting" and "informational", consider the subservice InterfaceHealthy, representing a network interface. If the device to which the network interface belongs goes down, the network interface will transition to a down state as well. Therefore, the dependency of InterfaceHealthy towards DeviceHealthy is "impacting". On the other hand, as a the dependency towards the ECMPLoad subservice, which checks that the load between ECMP remains ce remains stable throughout time, is only "informational". Indeed, @@ -290,21 +290,21 @@ By specifying service instances and their dependencies in terms of subservices, one defines the whole assurance to apply for them. An assurance agent supporting this model should then produce telemetry in return with, for each subservice: a health-status indicating how healthy the subservice is and when the subservice is not healthy, a list of symptoms explaining why the subservice is not healthy. 4.3. YANG Module - file "ietf-service-assurance@2021-06-28.yang" + file "ietf-service-assurance@2022-01-04.yang" module ietf-service-assurance { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; prefix service-assurance; import ietf-yang-types { prefix yang; } @@ -350,20 +350,26 @@ set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. TO DO: - Better type (IETF or OC) for device-id, interface-id, etc. - Have a YANG module for IETF and one for OC?"; + revision 2022-01-04 { + description + "Explicitely model a missing value"; + reference + "RFC xxxx: Title to be completed"; + } revision 2021-06-28 { description "Made service-instance parameters mandatory."; reference "RFC xxxx: Title to be completed"; } revision 2020-01-13 { description "Added the maintenance window concept."; reference @@ -466,30 +472,30 @@ base dependency-type; } description "Represents the type of dependency (i.e. informational, impacting)."; } // augment here if more info are needed (i.e. a percentage) depending on the dependency type. } leaf assurance-graph-version { type yang:counter32; - mandatory true; config false; + mandatory true; description "The assurance graph version, which increases by 1 for each new version, after the changes (dependencies and/or maintenance windows parameters) are applied to the subservice(s)."; } leaf assurance-graph-last-change { type yang:date-and-time; - mandatory true; config false; + mandatory true; description "Date and time at which the assurance graph last changed after the changes (dependencies and/or maintenance windows parameters) are applied to the subservice(s). These date and time must be more recent or equal compared to the more recent value of any changed subservices last-change"; } container subservices { description "Root container for the subservices."; list subservice { @@ -569,23 +575,34 @@ leaf instance-name { type string; mandatory true; description "Name of the instance for that service."; } } // Other modules can augment their own cases into here } leaf health-score { + type union { type uint8 { range "0 .. 100"; } + type enumeration { + enum missing { + value -1; + description + "Explictly represent the fact that the health score is + missing. This could be used when metrics crucial to + establish the health score are not collected anymore."; + } + } + } config false; description "Score value of the subservice health. A value of 100 means that subservice is healthy. A value of 0 means that the subservice is broken. A value between 0 and 100 means that the subservice is degraded."; } leaf symptoms-history-start { type yang:date-and-time; config false; @@ -654,21 +671,21 @@ +--rw under-maintenance? boolean +--rw maintenance-contact string +--rw (parameter)? | +--:(service-instance-parameter) | | +--rw service-instance-parameter | | +--rw service string | | +--rw instance-name string | +--:(service-assurance-device:parameters) | +--rw service-assurance-device:parameters | +--rw service-assurance-device:device string - +--ro health-score? uint8 + +--ro health-score? union +--ro symptoms-history-start? yang:date-and-time +--rw symptoms | +--ro symptom* [start-date-time id] | +--ro id string | +--ro health-score-weight? uint8 | +--ro description? string | +--ro start-date-time yang:date-and-time | +--ro stop-date-time? yang:date-and-time +--rw dependencies +--rw dependency* [type id] @@ -822,21 +838,21 @@ | | +--rw service-instance-parameter | | +--rw service string | | +--rw instance-name string | +--:(service-assurance-interface:parameters) | | +--rw service-assurance-interface:parameters | | +--rw service-assurance-interface:device string | | +--rw service-assurance-interface:interface string | +--:(service-assurance-device:parameters) | +--rw service-assurance-device:parameters | +--rw service-assurance-device:device string - +--ro health-score? uint8 + +--ro health-score? union +--ro symptoms-history-start? yang:date-and-time +--rw symptoms | +--ro symptom* [start-date-time id] | +--ro id string | +--ro health-score-weight? uint8 | +--ro description? string | +--ro start-date-time yang:date-and-time | +--ro stop-date-time? yang:date-and-time +--rw dependencies +--rw dependency* [type id] @@ -987,21 +1003,21 @@ | | +--rw service-assurance-device:parameters | | +--rw service-assurance-device:device string | +--:(example-service-assurance-device-acme:parameters) | | +--rw example-service-assurance-device-acme:parameters | | +--rw example-service-assurance-device-acme:device string | | +--rw example-service-assurance-device-acme:acme-specific-parameter string | +--:(service-assurance-interface:parameters) | +--rw service-assurance-interface:parameters | +--rw service-assurance-interface:device string | +--rw service-assurance-interface:interface string - +--ro health-score? uint8 + +--ro health-score? union +--ro symptoms-history-start? yang:date-and-time +--rw symptoms | +--ro symptom* [start-date-time id] | +--ro id string | +--ro health-score-weight? uint8 | +--ro description? string | +--ro start-date-time yang:date-and-time | +--ro stop-date-time? yang:date-and-time +--rw dependencies +--rw dependency* [type id] @@ -1184,21 +1199,21 @@ | | +--rw service-assurance-device:parameters | | +--rw service-assurance-device:device string | +--:(example-service-assurance-device-acme:parameters) | | +--rw example-service-assurance-device-acme:parameters | | +--rw example-service-assurance-device-acme:device string | | +--rw example-service-assurance-device-acme:acme-specific-parameter string | +--:(service-assurance-interface:parameters) | +--rw service-assurance-interface:parameters | +--rw service-assurance-interface:device string | +--rw service-assurance-interface:interface string - +--ro health-score? uint8 + +--ro health-score? union +--ro symptoms-history-start? yang:date-and-time +--rw symptoms | +--ro symptom* [start-date-time id] | +--ro id string | +--ro health-score-weight? uint8 | +--ro description? string | +--ro start-date-time yang:date-and-time | +--ro stop-date-time? yang:date-and-time +--rw dependencies +--rw dependency* [type id] @@ -1484,27 +1498,27 @@ RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/ creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: - o /subservices/subservice/type + * /subservices/subservice/type - o /subservices/subservice/id + * /subservices/subservice/id - o /subservices/subservice/under-maintenance + * /subservices/subservice/under-maintenance - o /subservices/subservice/maintenance-contact + * /subservices/subservice/maintenance-contact 11. IANA Considerations 11.1. The IETF XML Registry This document registers two URIs in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registrations are requested: URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance @@ -1542,22 +1556,22 @@ 12. Open Issues -None 13. References 13.1. Normative References [I-D.ietf-opsawg-service-assurance-architecture] - Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. - Arumugam, "draft-claise-opsawg-service-assurance- + Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V., + and T.A. Arumugam, "draft-claise-opsawg-service-assurance- architecture", 2020. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . @@ -1595,37 +1609,33 @@ . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . -13.3. URIs - - [1] https://yangson.labs.nic.cz/ - Appendix A. Example of YANG instances This section contains examples of YANG instances that conform to the YANG modules. The validity of these data instances has been checked - using yangson [1]. Yangson requires a YANG library [RFC7895] to - define the complete model against which the data instance must be - validated. We provide in Appendix B the JSON library file, named - "ietf-service-assurance-library.json", that we used for validation. + using yangson (https://yangson.labs.nic.cz/). Yangson requires a + YANG library [RFC7895] to define the complete model against which the + data instance must be validated. We provide in Appendix B the JSON + library file, named "ietf-service-assurance-library.json", that we + used for validation. We provide below the contents of the file "example_configuration_instance.json" which contains the configuration data that models the Figure 2 of - [I-D.ietf-opsawg-service-assurance-architecture]. The instance can be validated with yangson by using the invocation "yangson -v example_configuration_instance.json ietf-service-assurance- library.json", assuming all the files (YANG and JSON) defined in this draft reside in the current folder. file "example_configuration_instance.json" { "ietf-service-assurance:subservices": { @@ -1846,26 +1855,26 @@ ] } } Appendix C. Changes between revisions v00 - v01 - o Added needed subservice to model example from architecture draft + * Added needed subservice to model example from architecture draft - o Added guideline section for naming models + * Added guideline section for naming models + * Added data instance examples and validation procedure - o Added data instance examples and validation procedure - o Added the "parameters" container in the interface YANG module to + * Added the "parameters" container in the interface YANG module to correct a bug. Acknowledgements The authors would like to thank Jan Lindblad for his help during the design of these YANG modules. The authors would like to thank Stephane Litkowski and Charles Eckel for their reviews. Authors' Addresses @@ -1875,29 +1884,28 @@ Email: benoit.claise@huawei.com Jean Quilbeuf Huawei Email: jean.quilbeuf@huawei.com Paolo Lucente NTT Siriusdreef 70-72 - Hoofddorp, WT 2132 + 2132 Hoofddorp Netherlands Email: paolo@ntt.net Paolo Fasano TIM S.p.A via G. Reiss Romoli, 274 10148 Torino Italy Email: paolo2.fasano@telecomitalia.it Thangam Arumugam Cisco Systems, Inc. - Milpitas (California) + Milpitas (California), United States - Email: tarumuga@cisco.com