--- 1/draft-ietf-opsawg-service-assurance-yang-03.txt 2022-04-25 11:13:14.925048989 -0700 +++ 2/draft-ietf-opsawg-service-assurance-yang-04.txt 2022-04-25 11:13:15.005051011 -0700 @@ -1,142 +1,149 @@ OPSAWG B. Claise Internet-Draft J. Quilbeuf Intended status: Standards Track Huawei -Expires: 26 September 2022 P. Lucente +Expires: 27 October 2022 P. Lucente NTT P. Fasano TIM S.p.A T. Arumugam Cisco Systems, Inc. - 25 March 2022 + 25 April 2022 YANG Modules for Service Assurance - draft-ietf-opsawg-service-assurance-yang-03 + draft-ietf-opsawg-service-assurance-yang-04 Abstract - This document proposes YANG modules for the Service Assurance for - Intent-based Networking Architecture. + This document specifies YANG modules representing assurance graphs. + These graphs represent the assurance of a given service by + decomposing it into atomic assurance elements called subservices. A + companion RFC, Service Assurance for Intent-based Networking + Architecture, presents an architecture for implementing the assurance + of such services. + + The YANG data models in this document conforms to the Network + Management Datastore Architecture (NMDA) defined in RFC 8342. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 26 September 2022. + This Internet-Draft will expire on 27 October 2022. Copyright Notice 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 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 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 + 3. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 + 3.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Subservice Extension: ietf-service-assurance-device YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 - 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 - 6. Subservice Extension: ietf-service-assurance-interface YANG + 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 + 4.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Subservice Extension: ietf-service-assurance-interface YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19 - 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20 - 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 - 7. Vendor-specific Subservice Extension: + 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19 + 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Vendor-specific Subservice Extension: example-service-assurance-device-acme YANG module . . . . 23 - 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 23 - 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 23 - 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 25 - 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 - 8. Further Extensions: IP Connectivity and IS-IS subservices . . 27 - 8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 27 - 8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 27 - 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 28 - 8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29 - 8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 31 - 9. Guidelines for Specific Subservice Extension . . . . . . . . 33 - 9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 33 - 9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 33 - 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 34 - 9.4. Subservice Specific Identity . . . . . . . . . . . . . . 34 - 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 34 - - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 - 11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 35 - 11.2. The YANG Module Names Registry . . . . . . . . . . . . . 35 - 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 36 - 13.2. Informative References . . . . . . . . . . . . . . . . . 37 - Appendix A. Example of YANG instances . . . . . . . . . . . . . 37 - Appendix B. YANG Library for Service Assurance . . . . . . . . . 41 - Appendix C. Changes between revisions . . . . . . . . . . . . . 42 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 - -1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in BCP - 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. + 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 23 + 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 23 + 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 25 + 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 + 7. Further Extensions: IP Connectivity and IS-IS subservices . . 27 + 7.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 27 + 7.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 28 + 7.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 28 + 7.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29 + 7.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 32 + 8. Guidelines for Specific Subservice Extension . . . . . . . . 33 + 8.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 34 + 8.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 34 + 8.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 34 + 8.4. Subservice Specific Identity . . . . . . . . . . . . . . 35 + 8.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 35 - The terms used in this document are defined in - [I-D.ietf-opsawg-service-assurance-architecture] + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 36 + 10.2. The YANG Module Names Registry . . . . . . . . . . . . . 36 + 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 12.2. Informative References . . . . . . . . . . . . . . . . . 38 + Appendix A. Example of YANG instances . . . . . . . . . . . . . 38 + Appendix B. YANG Library for Service Assurance . . . . . . . . . 42 + Appendix C. Changes between revisions . . . . . . . . . . . . . 43 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 -2. Introduction +1. Introduction The "Service Assurance for Intent-based Networking Architecture" [I-D.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: * machine readable * vendor independent * augmentable -3. YANG Models Overview +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 13 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The terms used in this document are defined in + [I-D.ietf-opsawg-service-assurance-architecture] + +2. 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: @@ -144,43 +151,49 @@ - Subservices: configure a set of subservices to assure, by specifying their types and parameters. - Dependencies: configure the dependencies between the subservices, along with their type. * Assurance telemetry: export the health status of the subservices, along with the observed symptoms. + The main module represents the configuration (subservice and + dependencies) and operational data (health status and symptoms) in a + single tree. Other modules follows the same pattern. Thus, the + modules presented in this document conform to the Network Management + Datastore Architecture defined in [RFC8342]. + 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. The fourth YANG module, example-service-assurance-device-acme, extends the ietf-service-assurance-device module as an example to add support for the subservice DeviceHealthy, with specifics for the fictional ACME Corporation. Additional vendor-specific parameters might be added the same way. - Finally, the modules ietf-service-assurance-ip-connectivity and ietf- - service-assurance-is-is are provided to completely model the example - from the SAIN architecture draft + Finally, the modules example-service-assurance-ip-connectivity and + example-service-assurance-is-is are provided to completely model the + example from the SAIN architecture draft [I-D.ietf-opsawg-service-assurance-architecture]. -4. Base ietf-service-assurance YANG module +3. Base ietf-service-assurance YANG module -4.1. Tree View +3.1. Tree View The following tree diagram [RFC8340] provides an overview of the ietf-service-assurance data model. module: ietf-service-assurance +--ro assurance-graph-version yang:counter64 +--ro assurance-graph-last-change yang:date-and-time +--rw subservices +--rw subservice* [type id] +--rw type identityref @@ -198,25 +211,26 @@ +--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] - +--rw type -> /subservices/subservice/type - +--rw id -> /subservices/subservice[type=current()/../type]/id + +--rw type + | -> /subservices/subservice/type + +--rw id leafref +--rw dependency-type? identityref -4.2. Concepts +3.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: * 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". @@ -233,29 +247,29 @@ The status of each subservice contains a list of symptoms. Each symptom is specified by a unique id and contains a health-score- weight (the impact to the health score incurred by this symptom), a label (text describing what the symptom is), and dates and times at 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 relation between the health score and the health-score-weight of - the currently active symptoms is not explictely defined in this + the currently active symptoms is not explicitly defined in this draft. The only requirement is that a non-maximal score must be explained by at least one symptom. A way to enforce that requirement is to first detect symptoms and then compute the health score based on the health-score-weight of the detected symptoms. As an example, this computation could be to sum the health-score-weight of the - active symptoms, substract that value from 100 and change the value - to 0 if negative. The relation between health-score and health- - score-weight is left to the implementor (of an agent + active symptoms, subtract that value from 100 and change the value to + 0 if negative. The relation between health-score and health-score- + weight is left to the implementor (of an agent [I-D.ietf-opsawg-service-assurance-architecture]). To consider for implementing this relation: the health-score is mostly for humans, the symptoms are what the closed loop automation can build on. 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: @@ -302,106 +316,112 @@ [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed discussion. 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 +3.3. YANG Module - file "ietf-service-assurance@2022-01-04.yang" + file "ietf-service-assurance@2022-04-07.yang" module ietf-service-assurance { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; - prefix service-assurance; + prefix sain; import ietf-yang-types { prefix yang; + reference + "RFC 6991: Common YANG Data Types"; } organization - "IETF NETCONF (Network Configuration) Working Group"; + "IETF OPSAWG Working Group"; contact - "WG Web: - WG List: + "WG Web: + WG List: Author: Benoit Claise Author: Jean Quilbeuf "; description "This module defines objects for assuring network services based on - their decomposition into so-called subservices, according to the SAIN - (Service Assurance for Intent-based Networking) architecture. + their decomposition into so-called subservices, according to the + SAIN (Service Assurance for Intent-based Networking) architecture. - The subservices hierarchically organised by dependencies constitute an - assurance graph. This module should be supported by an assurance agent, - able to interact with the devices in order to produce a health status - and symptoms for each subservice in the assurance graph. + The subservices hierarchically organised by dependencies constitute + an assurance graph. This module should be supported by an assurance + 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: * Assurance graph configuration: - * subservices: configure a set of subservices to assure, by specifying - their types and parameters. - * dependencies: configure the dependencies between the subservices, - along with their type. - * Assurance telemetry: export the health status of the subservices, along - with the observed symptoms. + - subservices: configure a set of subservices to assure, by + specifying their types and parameters. + - dependencies: configure the dependencies between the + subservices, along with their type. + * Assurance telemetry: export the health status of the subservices, + along with the observed symptoms. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c)2021 IETF Trust and the persons identified as + Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject - to the license terms contained in, the Simplified BSD License + to the license terms contained in, the Revised BSD License 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?"; + RFC itself for full legal notices. "; + revision 2022-04-07 { + description + "Shorten prefix. Fix copyright. + Fix module description"; + reference + "RFC xxxx: YANG Modules for Service Assurance"; + } revision 2022-01-04 { description "Explicitely model a missing value"; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2021-06-28 { description "Made service-instance parameters mandatory."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2020-01-13 { description "Added the maintenance window concept."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2019-11-16 { description "Initial revision."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } identity subservice-idty { description "Root identity for all subservice types."; } identity service-instance-idty { base subservice-idty; description @@ -409,55 +429,56 @@ } identity dependency-type { description "Base identity for representing dependency types."; } identity informational-dependency { base dependency-type; description - "Indicates that symptoms of the dependency might be of interest for the - dependent, but the status of the dependency should not have any - impact on the dependent."; + "Indicates that symptoms of the dependency might be of interest + for the dependent, but the status of the dependency should not + have any impact on the dependent."; } identity impacting-dependency { base dependency-type; description - "Indicates that the status of the dependency directly impacts the status - of the dependent."; + "Indicates that the status of the dependency directly impacts the + status of the dependent."; } grouping symptom { description "Contains the list of symptoms for a specific subservice."; leaf id { type string; description "A unique identifier for the symptom."; } leaf health-score-weight { type uint8 { range "0 .. 100"; } description - "The weight to the health score incurred by this symptom. The higher the - value, the more of an impact this symptom has. If a subservice health - score is not 100, there must be at least one symptom with a health - score weight larger than 0."; + "The weight to the health score incurred by this symptom. The + higher the value, the more of an impact this symptom has. If a + subservice health score is not 100, there must be at least one + symptom with a health score weight larger than 0."; } leaf description { type string; description - "Description of the symptom, i.e. text describing what the symptom is, to - be computer-consumable and be displayed on a human interface. "; + "Description of the symptom, i.e. text describing what the + symptom is, to be computer-consumable and be displayed on a + human interface. "; } leaf start-date-time { type yang:date-and-time; description "Date and time at which the symptom was detected."; } leaf stop-date-time { type yang:date-and-time; description "Date and time at which the symptom stopped being detected."; @@ -478,47 +500,51 @@ path "/subservices/subservice[type=current()/../type]/id"; } description "The identifier of the subservice to refer to."; } leaf dependency-type { type identityref { base dependency-type; } description - "Represents the type of dependency (i.e. informational, impacting)."; + "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. + // Augment here to add parameters specific to a new dependency-type. + // For instance, a specific dependency type could keep symptom + // whose health-score-weight is larger than a given value. } leaf assurance-graph-version { type yang:counter64; 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)."; + "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; 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"; + "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 { key "type id"; description "List of subservice configured."; leaf type { type identityref { base subservice-idty; } description "Name of the subservice, e.g. DeviceHealthy."; @@ -519,72 +545,78 @@ leaf type { type identityref { base subservice-idty; } description "Name of the subservice, e.g. DeviceHealthy."; } leaf id { type string; description - "Unique identifier of the subservice instance, for each type."; + "Unique identifier of the subservice instance, for each + type."; } leaf last-change { type yang:date-and-time; config false; description - "Date and time at which the assurance graph for this subservice - instance last changed, i.e. dependencies and/or maintenance windows parameters."; + "Date and time at which the assurance graph for this + subservice instance last changed, i.e. dependencies and/or + maintenance windows parameters."; } leaf label { type string; config false; description - "Label of the subservice, i.e. text describing what the subservice is to - be displayed on a human interface."; + "Label of the subservice, i.e. text describing what the + subservice is to be displayed on a human interface."; } leaf under-maintenance { type boolean; default "false"; description - "An optional flag indicating whether this particular subservice is under - maintenance. Under this circumstance, the subservice symptoms and the - symptoms of its dependencies in the assurance graph should not be taken - into account. Instead, the subservice should send a 'Under Maintenance' + "An optional flag indicating whether this particular + subservice is under maintenance. Under this circumstance, the + subservice symptoms and the symptoms of its dependencies in + the assurance graph should not be taken into account. + Instead, the subservice should send a 'Under Maintenance' single symptom. - The operator changing the under-maintenance value must set the - maintenance-contact variable. + The operator changing the under-maintenance value must set + the maintenance-contact variable. When the subservice is not under maintenance any longer, the under-maintenance flag must return to its default value and the under-maintenance-owner variable deleted."; } leaf maintenance-contact { when "../under-maintenance = 'true'"; type string; mandatory true; description - "A string used to model an administratively assigned name of the - resource that changed the under-maintenance value to 'true. + "A string used to model an administratively assigned name of + the resource that changed the under-maintenance value to + 'true'. - It is suggested that this name contain one or more of the following: - IP address, management station name, network manager's name, location, - or phone number. In some cases the agent itself will be the owner of - an entry. In these cases, this string shall be set to a string - starting with 'monitor'."; + It is suggested that this name contain one or more of the + following: IP address, management station name, + network manager's name, location, or phone number. In some + cases the agent itself will be the owner of an entry. In + these cases, this string shall be set to a string starting + with 'monitor'."; } choice parameter { description "Specify the required parameters per subservice type."; container service-instance-parameter { - when "derived-from-or-self(../type, 'service-assurance:service-instance-idty')"; + when "derived-from-or-self(../type, + 'sain:service-instance-idty')"; description "Specify the parameters of a service instance."; leaf service { type string; mandatory true; description "Name of the service."; } leaf instance-name { type string; @@ -601,245 +633,259 @@ 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."; + "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; description "Date and time at which the symptoms history starts for this subservice instance, either because the subservice instance - started at that date and time or because the symptoms before that - were removed due to a garbage collection process."; + started at that date and time or because the symptoms before + that were removed due to a garbage collection process."; } container symptoms { description "Symptoms for the subservice."; list symptom { key "start-date-time id"; config false; description - "List of symptoms the subservice. While the start-date-time key is not - necessary per se, this would get the entries sorted by start-date-time - for easy consumption."; + "List of symptoms the subservice. While the start-date-time + key is not necessary per se, this would get the entries + sorted by start-date-time for easy consumption."; uses symptom; } + } container dependencies { description - "configure the dependencies between the subservices, along with their types."; + "configure the dependencies between the subservices, along + with their types."; list dependency { key "type id"; description "List of soft dependencies of the subservice."; uses subservice-dependency; } } } } } -5. Subservice Extension: ietf-service-assurance-device YANG module +4. Subservice Extension: ietf-service-assurance-device YANG module -5.1. Tree View +4.1. Tree View The following tree diagram [RFC8340] provides an overview of the ietf-service-assurance-device data model. module: ietf-service-assurance-device - augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: + augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw device string -5.2. Complete Tree View +4.2. Complete Tree View The following tree diagram [RFC8340] provides an overview of the ietf-service-assurance and ietf-service-assurance-device data models. module: ietf-service-assurance +--ro assurance-graph-version yang:counter64 +--ro assurance-graph-last-change yang:date-and-time +--rw subservices +--rw subservice* [type id] +--rw type identityref +--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 - | +--:(service-assurance-device:parameters) - | +--rw service-assurance-device:parameters - | +--rw service-assurance-device:device string + | +--:(sain-device:parameters) + | +--rw sain-device:parameters + | +--rw sain-device:device string +--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] - +--rw type -> /subservices/subservice/type - +--rw id -> /subservices/subservice[type=current()/../type]/id + +--rw type + | -> /subservices/subservice/type + +--rw id leafref +--rw dependency-type? identityref -5.3. Concepts +4.3. Concepts As the number of subservices will grow over time, the YANG module is designed to be extensible. A new subservice type requires the precise specifications of its type and expected parameters. Let us illustrate the example of the new DeviceHealthy subservice type. As the name implies, it monitors and reports the device health, along with some symptoms in case of degradation. For our DeviceHealthy subservice definition, the new identity device- idty is specified, as an inheritance from the base identity for subservices. This indicates to the assurance agent that we are now assuring the health of a device. The typical parameter for the configuration of the DeviceHealthy subservice is the name of the device that we want to assure. By augmenting the parameter choice from ietf-service-assurance YANG module for the case of the device-idty subservice type, this new parameter is specified. -5.4. YANG Module +4.4. YANG Module - file "ietf-service-assurance-device@2021-06-28.yang" + file "ietf-service-assurance-device@2022-04-07.yang" module ietf-service-assurance-device { yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; - prefix service-assurance-device; + namespace + "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; + prefix sain-device; import ietf-service-assurance { - prefix service-assurance; + prefix sain; + reference + "RFC xxxx: YANG Modules for Service Assurance"; } organization - "IETF NETCONF (Network Configuration) Working Group"; + "IETF OPSAWG Working Group"; contact - "WG Web: - WG List: + "WG Web: + WG List: Author: Benoit Claise Author: Jean Quilbeuf "; description "This module extends the ietf-service-assurance module to add support for the subservice DeviceHealthy. Checks whether a network device is healthy. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c) 2021 IETF Trust and the persons identified as + Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject - to the license terms contained in, the Simplified BSD License + to the license terms contained in, the Revised BSD License 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. "; + revision 2022-04-07 { + description + "Fix mandatory in augment error by moving when clause. + Shorten prefix. Fix module description. + Fix module description"; + reference + "RFC xxxx: YANG Modules for Service Assurance"; + } revision 2021-06-28 { description "Renamed the container for parameters."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2020-01-13 { description "Added the maintenance window concept."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2019-11-16 { description "Initial revision."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } identity device-idty { - base service-assurance:subservice-idty; + base sain:subservice-idty; description "Network Device is healthy."; } - augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { + augment "/sain:subservices/sain:subservice/sain:parameter" { + when "derived-from-or-self(sain:type, 'device-idty')"; description "Specify the required parameters for a new subservice type"; + container parameters { - when "derived-from-or-self(../service-assurance:type, 'device-idty')"; description - "Specify the required parameters for the device-idty subservice type"; + "Specify the required parameters for the device-idty + subservice type"; leaf device { type string; mandatory true; description "The device to monitor."; } } } } -6. Subservice Extension: ietf-service-assurance-interface YANG module +5. Subservice Extension: ietf-service-assurance-interface YANG module -6.1. Tree View +5.1. Tree View The following tree diagram [RFC8340] provides an overview of the ietf-service-assurance-interface data model. module: ietf-service-assurance-interface - augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: + augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw device string +--rw interface string -6.2. Complete Tree View +5.2. Complete Tree View The following tree diagram [RFC8340] provides an overview of the ietf-service-assurance, ietf-service-assurance-device, and ietf- service-assurance-interface data models. module: ietf-service-assurance +--ro assurance-graph-version yang:counter64 +--ro assurance-graph-last-change yang:date-and-time +--rw subservices +--rw subservice* [type id] @@ -847,66 +893,70 @@ +--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 - | +--:(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 + | +--:(sain-interface:parameters) + | | +--rw sain-interface:parameters + | | +--rw sain-interface:device string + | | +--rw sain-interface:interface string + | +--:(sain-device:parameters) + | +--rw sain-device:parameters + | +--rw sain-device:device string +--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] - +--rw type -> /subservices/subservice/type - +--rw id -> /subservices/subservice[type=current()/../type]/id + +--rw type + | -> /subservices/subservice/type + +--rw id leafref +--rw dependency-type? identityref -6.3. Concepts +5.3. Concepts For our InterfaceHealthy subservice definition, the new interface- idty is specified, as an inheritance from the base identity for subservices. This indicates to the assurance agent that we are now assuring the health of an interface. The typical parameters for the configuration of the InterfaceHealthy subservice are the name of the device and, on that specific device, a specific interface. By augmenting the parameter choice from ietf- service-assurance YANG module for the case of the interface-idty - subservice type, those two new parameter are specified. + subservice type, those two new parameters are specified. -6.4. YANG Module +5.4. YANG Module - file "ietf-service-assurance-interface@2021-06-28.yang" + file "ietf-service-assurance-interface@2022-04-07.yang" module ietf-service-assurance-interface { yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; - prefix service-assurance-interface; + namespace + "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; + prefix sain-interface; import ietf-service-assurance { - prefix service-assurance; + prefix sain; + reference + "RFC xxxx: YANG Modules for Service Assurance"; } organization "IETF OPSAWG Working Group"; contact "WG Web: WG List: Author: Benoit Claise Author: Jean Quilbeuf "; description @@ -915,405 +965,461 @@ Checks whether an interface is healthy. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c) 2021 IETF Trust and the persons identified as + Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject - to the license terms contained in, the Simplified BSD License + to the license terms contained in, the Revised BSD License 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. "; + revision 2022-04-07 { + description + "Fix mandatory in augment error by moving when clause. + Shorten prefix. Fix module description. + Fix module description"; + reference + "RFC xxxx: YANG Modules for Service Assurance"; + } revision 2021-06-28 { description "Regroup parameters in a container."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2020-01-13 { description "Initial revision."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } identity interface-idty { - base service-assurance:subservice-idty; + base sain:subservice-idty; description "Checks whether an interface is healthy."; } - augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { + augment "/sain:subservices/sain:subservice/sain:parameter" { + when "derived-from-or-self(sain:type, 'interface-idty')"; description - "Specify the required parameters for the interface-idty subservice type"; + "Specify the required parameters for the interface-idty + subservice type"; container parameters { - when "derived-from-or-self(../service-assurance:type, 'interface-idty')"; description - "Required parameters for the interface-idty subservice type"; + "Required parameters for the interface-idty subservice + type"; leaf device { type string; mandatory true; description "Device supporting the interface."; } leaf interface { type string; mandatory true; description "Name of the interface."; } } } } -7. Vendor-specific Subservice Extension: example-service-assurance- +6. Vendor-specific Subservice Extension: example-service-assurance- device-acme YANG module -7.1. Tree View +6.1. Tree View The following tree diagram [RFC8340] provides an overview of the example-service-assurance-device-acme data model. module: example-service-assurance-device-acme - augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: + augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw device string +--rw acme-specific-parameter string -7.2. Complete Tree View +6.2. Complete Tree View The following tree diagram [RFC8340] provides an overview of the ietf-service-assurance, ietf-service-assurance-device, and example- service-assurance-device-acme data models. module: ietf-service-assurance +--ro assurance-graph-version yang:counter64 +--ro assurance-graph-last-change yang:date-and-time +--rw subservices +--rw subservice* [type id] +--rw type identityref +--rw id string - +--ro last-change? yang:date-and-time + +--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 - | +--:(service-assurance-device:parameters) - | | +--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 + | +--:(sain-device:parameters) + | | +--rw sain-device:parameters + | | +--rw sain-device:device string + | +--:(example-device-acme:parameters) + | | +--rw example-device-acme:parameters + | | +--rw example-device-acme:device + | | | string + | | +--rw example-device-acme:acme-specific-parameter + | | string + | +--:(sain-interface:parameters) + | +--rw sain-interface:parameters + | +--rw sain-interface:device string + | +--rw sain-interface:interface string +--ro health-score? union - +--ro symptoms-history-start? yang:date-and-time + +--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] - +--rw type -> /subservices/subservice/type - +--rw id -> /subservices/subservice[type=current()/../type]/id + +--rw type + | -> /subservices/subservice/type + +--rw id leafref +--rw dependency-type? identityref -7.3. Concepts +6.3. Concepts Under some circumstances, vendor-specific subservice types might be required. As an example of this vendor-specific implementation, this section shows how to augment the ietf-service-assurance-device module to add support for the subservice DeviceHealthy, specific to the ACME Corporation. The new parameter is acme-specific-parameter. -7.4. YANG Module +6.4. YANG Module module example-service-assurance-device-acme { yang-version 1.1; namespace "urn:example:example-service-assurance-device-acme"; - prefix example-service-assurance-device-acme; + prefix example-device-acme; import ietf-service-assurance { - prefix service-assurance; + prefix sain; + reference + "RFC xxxx: YANG Modules for Service Assurance"; } import ietf-service-assurance-device { - prefix service-assurance-device; + prefix sain-device; + reference + "RFC xxxx: YANG Modules for Service Assurance"; } organization - "IETF NETCONF (Network Configuration) Working Group"; + "IETF OPSAWG Working Group"; contact - "WG Web: - WG List: + "WG Web: + WG List: Author: Benoit Claise Author: Jean Quilbeuf "; description - "This module extends the ietf-service-assurance-device module to add - support for the subservice DeviceHealthy, specific to the ACME Corporation. + "This module extends the ietf-service-assurance-device module to + add support for the subservice DeviceHealthy, specific to the ACME + Corporation. ACME Network Device is healthy. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c) 2021 IETF Trust and the persons identified as + Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject - to the license terms contained in, the Simplified BSD License + to the license terms contained in, the Revised BSD License 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. "; + revision 2022-04-07 { + description + "Fix mandatory in augment error by moving when clause. + Shorten prefix. + Fix module description"; + reference + "RFC xxxx: YANG Modules for Service Assurance"; + } revision 2021-06-28 { description "Renamed the parameters container."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2020-01-13 { description "Added the maintenance window concept."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } revision 2019-11-16 { description "Initial revision."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } identity device-acme-idty { - base service-assurance-device:device-idty; + base sain-device:device-idty; description "Network Device is healthy."; } - augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { + augment "/sain:subservices/sain:subservice/sain:parameter" { + when "derived-from-or-self(sain:type, 'device-acme-idty')"; description "Specify the required parameters for a new subservice type"; container parameters { - when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')"; description - "Specify the required parameters for the device-acme-idty subservice type"; + "Specify the required parameters for the device-acme-idty + subservice type"; leaf device { type string; mandatory true; description "The device to monitor."; } leaf acme-specific-parameter { type string; mandatory true; description "The ACME Corporation sepcific parameter."; } } } } -8. Further Extensions: IP Connectivity and IS-IS subservices +7. Further Extensions: IP Connectivity and IS-IS subservices -8.1. IP Connectivity Tree View + In this section, we provide two additional YANG models to completely + cover the example from Figure 2 in + [I-D.ietf-opsawg-service-assurance-architecture]. The complete + normalization of these modules is to be done in future work. - The following tree diagram [RFC8340] provides an overview of the - ietf-service-assurance-ip-connectivity data model. +7.1. IP Connectivity Tree View -module: ietf-service-assurance-ip-connectivity + That subservice represents the unicast connectivity between two IP + addresses located on to different devices. Such a subservice could + report symptoms such as "No route found". The following tree diagram + [RFC8340] provides an overview of the example-service-assurance-ip- + connectivity data model. - augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: + module: example-service-assurance-ip-connectivity + + augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw device1 string +--rw address1 inet:ip-address +--rw device2 string +--rw address2 inet:ip-address To specify the connectivity that we are interested in, we specify two IP addresses and two devices. The subservice assures that the connectivity between IP address 1 on device 1 and IP address 2 on device 2 is healthy. -8.2. IS-IS Tree View +7.2. IS-IS Tree View The following tree diagram [RFC8340] provides an overview of the - ietf-service-assurance-is-is data model. + example-service-assurance-is-is data model. -module: ietf-service-assurance-is-is + module: example-service-assurance-is-is - augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: + augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw instance-name string The parameter of this subservice is the name of the IS-IS instance to assure. -8.3. Global Tree View +7.3. Global Tree View The following tree diagram [RFC8340] provides an overview of the ietf-service-assurance, ietf-service-assurance-device, example- - service-assurance-device-acme, ietf-service-assurance-ip-connectivity - and ietf-service-assurance-is-is data models. + service-assurance-device-acme, example-service-assurance-ip- + connectivity and example-service-assurance-is-is data models. module: ietf-service-assurance +--ro assurance-graph-version yang:counter64 +--ro assurance-graph-last-change yang:date-and-time +--rw subservices +--rw subservice* [type id] +--rw type identityref +--rw id string - +--ro last-change? yang:date-and-time + +--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 - | +--:(service-assurance-ip-connectivity:parameters) - | | +--rw service-assurance-ip-connectivity:parameters - | | +--rw service-assurance-ip-connectivity:device1 string - | | +--rw service-assurance-ip-connectivity:address1 inet:ip-address - | | +--rw service-assurance-ip-connectivity:device2 string - | | +--rw service-assurance-ip-connectivity:address2 inet:ip-address - | +--:(service-assurance-is-is:parameters) - | | +--rw service-assurance-is-is:parameters - | | +--rw service-assurance-is-is:instance-name string - | +--:(service-assurance-device:parameters) - | | +--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 + | +--:(example-ip-connectivity:parameters) + | | +--rw example-ip-connectivity:parameters + | | +--rw example-ip-connectivity:device1 string + | | +--rw example-ip-connectivity:address1 + | | | inet:ip-address + | | +--rw example-ip-connectivity:device2 string + | | +--rw example-ip-connectivity:address2 + | | inet:ip-address + | +--:(example-is-is:parameters) + | | +--rw example-is-is:parameters + | | +--rw example-is-is:instance-name string + | +--:(sain-device:parameters) + | | +--rw sain-device:parameters + | | +--rw sain-device:device string + | +--:(example-device-acme:parameters) + | | +--rw example-device-acme:parameters + | | +--rw example-device-acme:device + | | | string + | | +--rw example-device-acme:acme-specific-parameter + | | string + | +--:(sain-interface:parameters) + | +--rw sain-interface:parameters + | +--rw sain-interface:device string + | +--rw sain-interface:interface string +--ro health-score? union - +--ro symptoms-history-start? yang:date-and-time + +--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] - +--rw type -> /subservices/subservice/type - +--rw id -> /subservices/subservice[type=current()/../type]/id + +--rw type + | -> /subservices/subservice/type + +--rw id leafref +--rw dependency-type? identityref -8.4. IP Connectivity YANG Module - - file "ietf-service-assurance-ip- - connectivity@2021-06-28.yang" +7.4. IP Connectivity YANG Module -module ietf-service-assurance-ip-connectivity { + module example-service-assurance-ip-connectivity { yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-ip-connectivity"; - prefix service-assurance-ip-connectivity; + namespace "urn:example:example-service-assurance-ip-connectivity"; + prefix example-ip-connectivity; import ietf-inet-types { prefix inet; + reference + "RFC 6991: Common YANG Data Types"; } import ietf-service-assurance { - prefix service-assurance; + prefix sain; + reference + "RFC xxxx: YANG Modules for Service Assurance"; } organization "IETF OPSAWG Working Group"; contact "WG Web: WG List: Author: Benoit Claise Author: Jean Quilbeuf "; description - "This module extends the ietf-service-assurance module to add - support for the subservice ip-connectivity. + "This example module extends the ietf-service-assurance module to + add support for the subservice ip-connectivity. Checks whether the ip connectivity between two ip addresses belonging to two network devices is healthy. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c) 2021 IETF Trust and the persons identified as + Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject - to the license terms contained in, the Simplified BSD License + to the license terms contained in, the Revised BSD License 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. "; + revision 2022-04-07 { + description + "Fix mandatory in augment error by moving when clause. + Shorten prefix. Fix module description. + Fix module description"; + reference + "RFC xxxx: YANG Modules for Service Assurance"; + + } revision 2021-06-28 { description "Initial revision."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } identity ip-connectivity-idty { - base service-assurance:subservice-idty; + base sain:subservice-idty; description "Checks connectivity between two IP addresses."; } - augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { + augment "/sain:subservices/sain:subservice/sain:parameter" { + when "derived-from-or-self(sain:type, 'ip-connectivity-idty')"; description - "Specify the required parameters for the ip-connectivity-idty subservice type"; + "Specify the required parameters for the ip-connectivity-idty + subservice type"; container parameters { - when "derived-from-or-self(../service-assurance:type, 'ip-connectivity-idty')"; description - "Required parameters for the ip-connectivity-idty subservice type"; + "Required parameters for the ip-connectivity-idty + subservice type"; leaf device1 { type string; mandatory true; description "Device at the first end of the connection."; } leaf address1 { type inet:ip-address; mandatory true; description @@ -1325,187 +1431,194 @@ description "Device at the second end of the connection."; } leaf address2 { type inet:ip-address; mandatory true; description "Address at the second end of the connection."; } } + } } - - -8.5. IS-IS YANG Module - - file "ietf-service-assurance-is-is@2021-06-28.yang" +7.5. IS-IS YANG Module -module ietf-service-assurance-is-is { + module example-service-assurance-is-is { yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is"; - prefix service-assurance-is-is; + namespace "urn:example:example-service-assurance-is-is"; + prefix example-is-is; import ietf-service-assurance { - prefix service-assurance; + prefix sain; + reference + "RFC xxxx: YANG Modules for Service Assurance"; } organization - "IETF NETCONF (Network Configuration) Working Group"; + "IETF OPSAWG Working Group"; contact - "WG Web: - WG List: + "WG Web: + WG List: Author: Benoit Claise Author: Jean Quilbeuf "; description - "This module extends the ietf-service-assurance module to add - support for the subservice IS-ISHealthy. + "This module extends the ietf-service-assurance module to + add support for the subservice is-is. Checks whether an IS-IS instance is healthy. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c) 2021 IETF Trust and the persons identified as + Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject - to the license terms contained in, the Simplified BSD License + to the license terms contained in, the Revised BSD License 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. "; + revision 2022-04-07 { + description + "Fix mandatory in augment error by moving when clause. + Shorten prefix. Fix module description. + Fix module description"; + reference + "RFC xxxx: YANG Modules for Service Assurance"; + } revision 2021-06-28 { description "Initial revision."; reference - "RFC xxxx: Title to be completed"; + "RFC xxxx: YANG Modules for Service Assurance"; } identity is-is-idty { - base service-assurance:subservice-idty; + base sain:subservice-idty; description "Health of IS-IS routing protocol."; } - augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { + augment "/sain:subservices/sain:subservice/sain:parameter" { + when "derived-from-or-self(sain:type, 'is-is-idty')"; description - "Specify the required parameters for a new subservice type"; + "Specify the required parameters for a new subservice + type"; container parameters { - when "derived-from-or-self(../service-assurance:type, 'is-is-idty')"; description - "Specify the required parameters for the IS-IS subservice type"; + "Specify the required parameters for the IS-IS subservice + type"; leaf instance-name { type string; mandatory true; description "The instance to monitor."; } } } } - - -9. Guidelines for Specific Subservice Extension +8. Guidelines for Specific Subservice Extension - The base YANG module defined in Section 4.3 only defines a single + The base YANG module defined in Section 3.3 only defines a single type of subservices that represent service instances. As explained above, this model is meant to be augmented so that a variety of subservices can be used in the assurance graph. In this section, we propose some guidelines in order to build theses extensions. First, the specific subservice must be given an adequate unique short name that will be used to form longer names (e.g. module name, prefix ...) appearing in the YANG module. The short name identifies the type of subpart of feature that the subservice will represent, for instance if the subservice will assure the health of a network - interafce then "interface" is an adequate short name. If the + interface then "interface" is an adequate short name. If the subservice will assure the IS-IS routing protocol, then "is-is" is an adequate short name. The short name must be in kebab-case. In this section, by subservice YANG module, we mean "YANG module that - extends ieft-service-assurance in order to define a specific + extends ietf-service-assurance in order to define a specific subservice". -9.1. Module Name +8.1. Module Name For subservice YANG modules vetted by the IETF, the module name - should be "ieft-service-assurance-" followed by the short name. For + should be "ietf-service-assurance-" followed by the short name. For instance, "ietf-service-assurance-interface" or "ietf-service- assurance-is-is". For subservice YANG module that are directly provided by vendors, we propose that they use the company in the prefix. For example, the prefix for the company "acme" would be "acme-assurance-" and the YANG modules would be "acme-assurance-interface", "acme-assurance-is-is", etc. -9.2. Module Namespace +8.2. Module Namespace For subservice YANG modules vetted by the IETF, the module namespace should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-" followed by the short name. For instance, "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or - "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is". + "urn:ietf:params:xml:ns:yang:example-service-assurance-is-is". For subservice YANG module that are directly provided by vendors, a similar pattern can be used with the prefix being a namespace controlled by the vendor. -9.3. Module Prefix +8.3. Module Prefix For subservice YANG modules vetted by the IETF, the module prefix - should be "service-assurance-" followed by the short name. For - instance, "service-assurance-interface" or "service-assurance-is-is". + should be "sain-" followed by the short name. For instance, "sain- + interface" or "sain-is-is". For subservice YANG module that are directly provided by vendors, the same pattern can be used provided it does not conflict with an imported prefix. -9.4. Subservice Specific Identity +8.4. Subservice Specific Identity - Each auqment specific to a subservice must define an identity + Each augment specific to a subservice must define an identity representing the type of subpart or features of the network system that are assured by the subservice. As required in the "ietf- - service-assurance" module (see Section 4.3), that identity must be + service-assurance" module (see Section 3.3), that identity must be based on the "subservice-idty" identity. For subservice YANG modules vetted by the IETF, the subservice specific identity should be the short name of the subservice followed by "-idty". For instance, "interface-idty" or "is-is-identity". For subservice YANG module that are directly provided by vendors, the same pattern can be used. -9.5. Parameters +8.5. Parameters For subservice YANG modules vetted by the IETF, the parameters specific to the subservice should be placed in a container named "parameters". That container must be used to augment the "parameter" - choice from the module "ietf-service-assurance" (see Section 4.3 and + choice from the module "ietf-service-assurance" (see Section 3.3 and that augment must be guarded so that it is effective only for subservice instance whose type is the subservice specific identity - from Section 9.4. + from Section 8.4. For subservice YANG module that are directly provided by vendors, the same pattern can be used. -10. Security Considerations +9. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] @@ -1522,68 +1635,68 @@ and their sensitivity/vulnerability: * /subservices/subservice/type * /subservices/subservice/id * /subservices/subservice/under-maintenance * /subservices/subservice/maintenance-contact -11. IANA Considerations +10. IANA Considerations -11.1. The IETF XML Registry +10.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 Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. -11.2. The YANG Module Names Registry +10.2. The YANG Module Names Registry This document registers three YANG modules in the YANG Module Names registry [RFC7950]. Following the format in [RFC7950], the the following registrations are requested: name: ietf-service-assurance namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance prefix: inc reference: RFC XXXX name: ietf-service-assurance-device namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device prefix: inc reference: RFC XXXX name: ietf-service-assurance-interface namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface prefix: inc reference: RFC XXXX -12. Open Issues +11. Open Issues -None -13. References +12. References -13.1. Normative References +12.1. Normative References [I-D.ietf-opsawg-service-assurance-architecture] 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, . @@ -1598,25 +1711,30 @@ [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . + [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., + and R. Wilton, "Network Management Datastore Architecture + (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, + . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . -13.2. Informative References +12.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . @@ -1644,22 +1762,20 @@ 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": { "subservice": [ { "type": "service-instance-idty", "id": "simple-tunnel/example", "service-instance-parameter": { "service": "simple-tunnel", "instance-name": "example" }, @@ -1669,60 +1785,62 @@ "type": "ietf-service-assurance-interface:interface-idty", "id": "interface/peer1/tunnel0", "dependency-type": "impacting-dependency" }, { "type": "ietf-service-assurance-interface:interface-idty", "id": "interface/peer2/tunnel9", "dependency-type": "impacting-dependency" }, { - "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", + "type": + "example-service-assurance-ip-connectivity:ip-connectivity-idty", "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", "dependency-type": "impacting-dependency" } ] } }, { - "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", + "type": + "example-service-assurance-ip-connectivity:ip-connectivity-idty", "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", - "ietf-service-assurance-ip-connectivity:parameters": { + "example-service-assurance-ip-connectivity:parameters": { "device1": "Peer1", "address1": "2001:db8::1", "device2": "Peer2", "address2": "2001:db8::2" }, "dependencies": { "dependency": [ { "type": "ietf-service-assurance-interface:interface-idty", "id": "interface/peer1/physical0", "dependency-type": "impacting-dependency" }, { "type": "ietf-service-assurance-interface:interface-idty", "id": "interface/peer2/physical5", "dependency-type": "impacting-dependency" }, { - "type": "ietf-service-assurance-is-is:is-is-idty", + "type": "example-service-assurance-is-is:is-is-idty", "id": "is-is/instance1", "dependency-type": "impacting-dependency" } ] } }, { - "type": "ietf-service-assurance-is-is:is-is-idty", + "type": "example-service-assurance-is-is:is-is-idty", "id": "is-is/instance1", - "ietf-service-assurance-is-is:parameters": { + "example-service-assurance-is-is:parameters": { "instance-name": "instance1" } }, { "type": "ietf-service-assurance-interface:interface-idty", "id": "interface/peer1/tunnel0", "ietf-service-assurance-interface:parameters": { "device": "Peer1", "interface": "tunnel0" }, @@ -1798,91 +1916,99 @@ "type": "ietf-service-assurance-device:device-idty", "id": "interface/peer2", "ietf-service-assurance-device:parameters": { "device": "Peer2" } } ] } } - - Appendix B. YANG Library for Service Assurance This section provides the JSON encoding of the YANG library [RFC7895] listing all modules defined in this draft and their dependencies. This library can be used to validate data instances using yangson, as explained in the previous section. - file "ietf-service-assurance-library.json" - { "ietf-yang-library:modules-state": { - "module-set-id": "ietf-service-assurance@2020-01-13", + "module-set-id": "ietf-service-assurance@2022-04-07", "module": [ { "name": "ietf-service-assurance", - "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance", - "revision": "2021-06-28", + "namespace": + "urn:ietf:params:xml:ns:yang:ietf-service-assurance", + "revision": "2022-04-07", "conformance-type": "implement" }, { "name": "ietf-service-assurance-device", - "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", - "revision": "2021-06-28", + "namespace": + "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", + "revision": "2022-04-07", "conformance-type": "implement" }, { "name": "ietf-service-assurance-interface", - "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", - "revision": "2021-06-28", + "namespace": + "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", + "revision": "2022-04-07", "conformance-type": "implement" }, { "name": "example-service-assurance-device-acme", - "namespace": "urn:example:example-service-assurance-device-acme", - "revision": "2021-06-28", + "namespace": + "urn:example:example-service-assurance-device-acme", + "revision": "2022-04-07", "conformance-type": "implement" }, { - "name": "ietf-service-assurance-is-is", - "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-is-is", - "revision": "2021-06-28", + "name": "example-service-assurance-is-is", + "namespace": "urn:example:example-service-assurance-is-is", + "revision": "2022-04-07", "conformance-type": "implement" }, { - "name": "ietf-service-assurance-ip-connectivity", - "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-ip-connectivity", - "revision": "2021-06-28", + "name": "example-service-assurance-ip-connectivity", + "namespace": + "urn:example:example-service-assurance-ip-connectivity", + "revision": "2022-04-07", "conformance-type": "implement" }, { "name": "ietf-yang-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "revision": "2021-04-14", "conformance-type": "import" }, { "name": "ietf-inet-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", "revision": "2021-02-22", "conformance-type": "import" } ] } } - - Appendix C. Changes between revisions + v03 - v04 + + * Fix YANG errors + * Change is-is and ip-connectivity subservices from ietf to example. + + * Mention that models are NMDA compliant + + * Fix typos, reformulate for clarity + v02 - v03 * Change counter32 to counter64 to avoid resetting too frequently * Explain why relation between health-score and symptom's health- score-weight is not defined and how it could be defined v01 - v02 * Explicitly represent the fact that the health-score could not be @@ -1896,21 +2022,22 @@ * Added data instance examples and validation procedure * 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. + Stephane Litkowski, Charles Eckel, Mohamed Boucadair and Tom Petch + for their reviews. Authors' Addresses Benoit Claise Huawei Email: benoit.claise@huawei.com Jean Quilbeuf Huawei Email: jean.quilbeuf@huawei.com