<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="4"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" ipr="trust200902"docName="draft-ietf-opsawg-service-assurance-yang-11">docName="draft-ietf-opsawg-service-assurance-yang-11" number="9418" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.16.0 --> <front> <titleabbrev="YANG Modulesabbrev="A YANG Data Model for ServiceAssurance">YANG ModulesAssurance">A YANG Data Model for Service Assurance</title> <seriesInfo name="RFC" value="9418"/> <author fullname="Benoit Claise" initials="B" surname="Claise"> <organization>Huawei</organization> <address> <postal><street></street> <city></city> <country></country><street/> <city/> <country/> </postal> <email>benoit.claise@huawei.com</email> </address> </author> <author fullname="Jean Quilbeuf" initials="J" surname="Quilbeuf "> <organization>Huawei</organization> <address> <email>jean.quilbeuf@huawei.com</email> </address> </author> <author fullname="Paolo Lucente" initials="P." surname="Lucente"> <organization>NTT</organization> <address> <postal> <street>Siriusdreef 70-72</street> <city>Hoofddorp</city><region>WT</region><code>2132</code> <country>Netherlands</country> </postal> <email>paolo@ntt.net</email> </address> </author> <author fullname="Paolo Fasano" initials="P" surname="Fasano"> <organization>TIM S.p.A</organization> <address> <postal> <street>via G. Reiss Romoli, 274</street><city>10148 Torino</city><city>Torino</city> <code>10148</code> <country>Italy</country> </postal> <email>paolo2.fasano@telecomitalia.it</email> </address> </author> <author fullname="Thangam Arumugam" initials="T" surname="Arumugam"><organization>Cisco Systems, Inc.</organization><organization>Consultant</organization> <address> <postal><street></street> <city>Milpitas (California)</city><street/> <city>Milpitas</city> <region>California</region> <country>UnitedStates</country>States of America</country> </postal><email>tarumuga@cisco.com</email><email>thangavelu@yahoo.com</email> </address> </author><date/> <area>OPS</area> <workgroup>OPSAWG</workgroup><date year="2023" month="June" /> <area>ops</area> <workgroup>opsawg</workgroup> <keyword>health</keyword> <keyword>SAIN</keyword> <keyword>subservice</keyword> <keyword>symptom</keyword> <keyword>telemetry</keyword> <abstract> <t> This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices.AThe companion document,Service"Service Assurance forIntent-basedIntent-Based NetworkingArchitecture,Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services. </t> <t> The YANG data models in this documentconformsconform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. </t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> <xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>target="RFC9417" format="default"/> describes an architecture and a set of involved components for service assurance, called Service Assurance forIntent-BasedIntent-based Networking (SAIN). This document complements the architecture by specifying a data model for the interfaces between components. More specifically, the document provides YANG modules for the purpose of service assurance in a format that is:<list style="symbols"> <t>machine-readable</t> <t>vendor independent</t> <t>augmentable</t> <ul spacing="normal"> <li>machine readable,</li> <li>vendor independent, and</li> <li>augmentable such that SAIN agents from Figure 1 of <xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>target="RFC9417" format="default"/> can support and expose new subservices to SAIN orchestrators andcollectors.</t> </list> </t>collectors.</li> </ul> <sectiontitle="Terminology" anchor="terminology">anchor="terminology" numbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <t> The terms used in this document are defined in <xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>.target="RFC9417" format="default"/>. </t> <t> The meanings of the symbols in the tree diagrams are defined in <xreftarget="RFC8340"/>.target="RFC8340" format="default"/>. </t> </section> </section> <section anchor="capability_model"title="YANGnumbered="true" toc="default"> <name>YANG ModulesOverview">Overview</name> <t> The main YANG module, "ietf-service-assurance" (<xreftarget="main-module"/>),target="main-module" format="default"/>), defines objects for assuring network services based on their decomposition into so-called subservices. The subservices are hierarchically organized by dependencies. The subservices, along with the dependencies, constitute an assurance graph. This module should be supported by anagent,agent that is able to interact with the devices in order to produceathe healthstatusstatuses and symptoms for each subservice in an assurance graph. This module is intended for the following use cases:<list style="symbols"></t> <ul spacing="normal"> <li> <t> Assurance graph configuration:<list style="symbols"> <t></t> <ul spacing="normal"> <li> Subservices:configureConfigure a set of subservices toassure,assure by specifying their types and parameters.</t> <t></li> <li> Dependencies:configureConfigure the dependencies between the subservices, along with theirtype. </t> </list> </t> <t>types. </li> </ul> </li> <li> Assurance telemetry:exportExport the assurance graph with healthstatusstatuses and symptoms for each node.</t> </list></li> </ul> <t> The module is also intended to be exported by the SAIN collectorwhichthat aggregates the output of several SAIN agents to provide the global assurance graph. In that case, only the telemetry export use case is considered. </t> <t> The modules presented in this document conform to the Network Management Datastore Architecture (NMDA) defined in <xreftarget="RFC8342"/>.target="RFC8342" format="default"/>. </t> <t> The second YANG module, "ietf-service-assurance-device" (<xreftarget="device-module"/>),target="device-module" format="default"/>), augments the "ietf-service-assurance" module by adding support for the device subservice. Additional subservice types might be added following a similar approach. </t> <t> The third YANG module, "ietf-service-assurance-interface" (<xreftarget="interface-module"/>),target="interface-module" format="default"/>), augments the "ietf-service-assurance" module aswell,well by adding support for the interface subservice. </t> <t> We provide additional examples in the appendix. The module "example-service-assurance-device-acme" (<xreftarget="acme-device-module"/>)target="acme-device-module" format="default"/>) augments the "ietf-service-assurance-device" module to customize it for devices of the fictionalACMEAcme Corporation. Additional vendor-specific parameters might be added following a similar approach. We also provide the modules "example-service-assurance-ip-connectivity" and "example-service-assurance-is-is" (<xreftarget="ip-connectivity-is-is"/>)target="ip-connectivity-is-is" format="default"/>) to model the example in Figure 2 fromSection 3.1 of<xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>.target="RFC9417" section="3.1" sectionFormat="of" format="default"/>. </t> </section> <sectiontitle="Baseanchor="main-module" numbered="true" toc="default"> <name>Base IETF Service Assurance YANGModule" anchor="main-module">Module</name> <sectiontitle="Concepts" anchor="ietf-service-assurance-concepts">anchor="ietf-service-assurance-concepts" numbered="true" toc="default"> <name>Concepts</name> <t> The "ietf-service-assurance" YANG module assumes a set ofsubservices,subservices to be assured independently. A subservice is a feature or a subpart of the network system that a given service instance depends on. Examples of subservice typesinclude: <list style="symbols"> <t>include the following: </t> <ul spacing="normal"> <li> device:whetherWhether a device is healthy, and if not, what are thesymptoms.symptoms? Such a subservice might monitor the deviceresourcesresources, such as CPU,RAMRAM, or Ternary Content-Addressable Memory (TCAM). Potential symptoms are "CPU overloaded", "Out of RAM", or "Out of TCAM".</t> <t></li> <li> ip-connectivity:givenGiven two IP addresses bound to two devices, what is the quality of the IP connectivity betweenthem.them? Potential symptoms are "No route available" or"Equal Cost Multiple Paths (ECMP) Imbalance". </t> </list>"Equal-Cost Multipaths (ECMPs) imbalance". </li> </ul> <t> An instance of the device subservice is representing a subpart of the network system, namely a specific device. An instance of the ip-connectivity subservice is representing a feature of the network, namely the connectivity between two specific IP addresses on two devices. In both cases, these subservices might depend on other subservices, for instance, the connectivity might depend on a subservice representing the routing system and on a subservice representingECMP.ECMPs. </t> <t> The two example subservices presented above need different sets of parameters to fully characterize one of theirinstance.instances. An instance of the device subservice is fully characterized by a single parameter allowing to identify the device to monitor. For the ip-connectivity subservice, at least the device and IP address for both ends of the link are needed to fully characterize an instance. </t> <t> The base model presented in this section specifies a single type of subservice, which represents service instances. Such nodes play a particular role in the assurance graph because they represent the starting point, or root, for the assurance graph of the corresponding service instance. The parameters required to fully identify a service instance are the name of the service and the name of the service instance. To support other types ofsubservicesubservices, such as'device'device or'ip-connectivity',ip-connectivity, the "ietf-service-assurance" module is intended to be augmented. </t> <t> The dependencies aremodelledmodeled as alist:list, i.e., each subservice contains a list of references to its dependencies. That list can be empty if the subservice instance does not have any dependencies. </t> <t> By specifying service instances and their dependencies in terms of subservices, one defines a global assurance graph. That assurance graph is the result of merging all the individual assurance graphs for the assured service instances. Each subservice instance is expected to appear onlyoneonce in the global assurance graph even if several service instances depend on it. For example, an instance of the device subservice is a dependency of every service instance thatrelyrelies on the corresponding device. The assurance graph of a specific service instance is the subgraph obtained by traversing the global assurance graph through thedependenciesdependencies, starting from the specific service instance. </t> <t> An assurance agent configured with such a graph is expected to produce, for each configuredsubservice:subservice, ahealth-status indicatinghealth status that indicates how healthy the subserviceis and whenis. If the the subservice is not healthy, the agent is expected to produce a list of symptoms explaining why the subservice is not healthy. </t><!-- <t> A symptom raised by an agent will need to be interpreted outside of the scope of the agent, as the result of several agents needs to be collected in order to have a complete graph. We use a pair of identifiers to fully identify a symptom: the agent identifier and the symptom identifier. Each agent MUST have a unique id within the system. Each symptom MUST have a unique id within the agent. A list mapping agent-id and symptom-id to their description is included in the model and must provide the description for every symptom raised in the assurance graph. </t> --></section> <sectiontitle="Tree View" anchor="ietf-service-assurance-tree-view">anchor="ietf-service-assurance-tree-view" numbered="true" toc="default"> <name>Tree View</name> <t> The following tree diagram <xreftarget="RFC8340"/>target="RFC8340" format="default"/> provides an overview of the "ietf-service-assurance" module. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-service-assurance +--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! | | +--rw contact string | +--rw (parameter) | | +--:(service-instance-parameter) | | +--rw service-instance-parameter | | +--rw service string | | +--rw instance-name string | +--ro health-score int8 | +--ro symptoms-history-start? yang:date-and-time | +--ro symptoms | | +--ro symptom* [start-date-time agent-id symptom-id] | | +--ro symptom-id leafref | | +--ro agent-id -> /agents/agent/id | | +--ro health-score-weight? uint8 | | +--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 leafref | +--rw dependency-type? identityref +--ro agents | +--ro agent* [id] | +--ro id string | +--ro symptoms* [id] | +--ro id string | +--ro description string +--ro assured-services +--ro assured-service* [service] +--ro service leafref +--ro instances* [name] +--ro name leafref +--ro subservices* [type id] +--ro type -> /subservices/subservice/type +--ro id leafref]]></artwork> </figure> </t>]]></sourcecode> <t> The date of the last change in "assurance-graph-last-change" is read only. It must be updated each time the graph structure is changed by addition or deletion ofsubservices,subservices and dependencies ormodificationmodifications of their configurable attributes, including their maintenancestatus.statuses. Such modifications correspond to a structural change in the graph. The date of the last change is useful for a client to quickly check if there is a need to update the graph structure. A change in thehealth-scorehealth score or symptoms associated to a service or subservice does not change the structure of thegraphgraph, and thus has no effect on the date of the last change. </t> <t> The"subservice""subservices" list contains all the subservice instances currently known by the server(i.e.(i.e., SAIN agent or SAIN collector). A subservice declarationMUST provide: <list style="symbols"> <t> A<bcp14>MUST</bcp14> provide the following: </t> <ul spacing="normal"> <li> a subservice type ("type"): a reference to an identity that inherits from "subservice-base", which is the base identity for any subservicetype. </t> <t> Antype </li> <li> an id ("id"): a string uniquely identifying the subservice among those with the sametype, </t> </list>type </li> </ul> <t> The type and id uniquely identify a given subservice. </t> <t> The "last-change" indicates when the dependencies or maintenance status of this particular subservice were last modified. </t> <t> The "label" is a human-readable description of the subservice. </t> <t> The presence of the "under-maintenance" container inhibits the emission of symptoms forthatthe subservice and subservices that depend on them. In that case, a "contact"MUST<bcp14>MUST</bcp14> be provided to indicate who or which software is responsible for the maintenance. SeeSection 3.6 of<xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>target="RFC9417" section="3.6" sectionFormat="of" format="default"/> for a more detailed discussion. </t> <t> The "parameter" choice is intended to be augmented in order to describe parameters that are specific to the current subservice type. This base module defines only the subservice type representing service instances. Service instancesMUST<bcp14>MUST</bcp14> be modeled as a particular type of subservice with twoparameters,parameters: "service" and "instance-name". The "service" parameter is the name of the service defined in the network orchestrator, forinstanceinstance, "point-to-point-l2vpn". The "instance-name" parameter is the name assigned to the particular instance to be assured, forinstanceinstance, the name of the customer using that instance. </t> <t> The "health-score" contains a value normally between 0 and100100, indicating how healthy the subservice is. As mentioned in thehealth-scorehealth score definition, the special value -1 can be used to specify that no value could be computed for thathealth-score,health score, forinstanceinstance, if some metric needed for that computation could not be collected. </t> <t> The "symptoms-history-start" is the cutoff date for reporting symptoms. Symptoms that were terminated before that date are not reported anymore in the model. </t> <t> The status of each subservice contains a list of symptoms. Each symptom is specifiedby <list style="symbols"> <t>by: </t> <ul spacing="normal"> <li> an identifier"symptom-id""symptom-id", which identifies the symptom locally to an agent,</t> <t></li> <li> an agent identifier"agent-id""agent-id", which identifies the agent raising thesymptom,</t> <t>symptom,</li> <li> a "health-score-weight" specifying the impact to the health score incurred by thissymptom,</t> <t>symptom,</li> <li> a "start-date-time" indicating when the symptom becameactive and </t> <t>active, and</li> <li> a "stop-date-time" indicating when the symptom stopped beingactive, thatactive (this field is not present if the symptom is stillactive.</t> </list>active).</li> </ul> <t> In order for the pair "agent-id" and "symptom-id" to uniquely identify a symptom, the following is necessary:<list style="symbols"> <t> The</t> <ul spacing="normal"> <li> "agent-id"MUST<bcp14>MUST</bcp14> be unique among all agents of thesystem </t> <t> Thesystem. </li> <li> "symptom-id"MUST<bcp14>MUST</bcp14> be unique among all symptoms raised by theagent </t> </list>agent. </li> </ul> <t> Note that "agent-id" and "symptom-id" are leafrefs pointing to the objects defined later in the document. While the combination of "symptom-id" and "agent-id" is sufficient as a unique key list, the "start-date-time" second key helps to sort and retrieve relevant symptoms. </t> <t> The "dependency" list contains the dependencies for the current subservice. Each of them is specified by a leafref to both "type" and "id" of the target dependencies. A dependency has a type indicated in the "dependency-type" field. Two types are specified in the model:<list style="symbols"> <t>Impacting: such</t> <ul spacing="normal"> <li>Impacting: Such a dependency indicates an impact on the health of thedependent,</t> <t>Informational: suchdependent.</li> <li>Informational: Such a dependency might explain why the dependent has issues but does not impact itshealth.</t> </list>health.</li> </ul> <t> To illustrate the difference between "impacting" and "informational", consider the interfacesubservice,subservice 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 the interface subservice towards the device subservice is "impacting". On the other hand, a dependency towards the ecmp-load subservice, which checks that the load betweenECMPECMPs remains stable throughout time, is only "informational". Indeed, services might be perfectly healthy even if the load distribution betweenECMPECMPs changed. However, such an instability might be a relevant symptom for diagnosing the root cause of a problem. </t> <t> Within the container "agents", the list "agent" contains the list of symptoms per agent. The key of the list is the "id", whichMUST<bcp14>MUST</bcp14> be unique among agents of a given assurance system. For each agent, the list "symptoms-description" maps an "id" to its "description". The "id"MUST<bcp14>MUST</bcp14> be unique among the symptoms raised by the agent. </t> <t> Within the container "assured-services", the list "assured-service" contains the subservices indexed by assured service instances. For each servicetype,type identified by the "service" leaf, all instances of that service are listed in the "instances" list. For eachinstance,instance identified by the "name" leaf, the "subservices" list contains all descendant subservices that are part of the assurance graph for that specific instance. These imbricated lists provide a query optimization to get the list of subservices in that assurance graph in a singlequery,query instead of recursively querying the dependencies of each subservice, starting from the node representing the service instance. </t> <t> The relation between the health score ("health-score") and thehealth-score-weight"health-score-weight" of the currently active symptoms is not explicitly defined in this document. The only requirement is that a health score that is strictly smaller than 100 (the maximal value) 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 thehealth-score-weight"health-score-weight" of the detected symptoms. As an example, such a computation could be to sum thehealth-score-weight"health-score-weight" of the active symptoms, subtract that value from100100, and change the value to 0 if the result is negative. The relation betweenhealth-scorehealth score andhealth-score-weight"health-score-weight" is left to the implementor (of an agent <xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>).target="RFC9417" format="default"/>). </t> <t> Keeping the history of the graph structure is out of scope for this YANG module. Only the current version of the assurance graph can be fetched. In order to keep the history of the graph structure, some time-series database (TSDB) or similar storage must be used. </t> </section> <sectiontitle="YANG Module" anchor="ietf-service-assurance-yang-model"> <t><CODE BEGINS> file "ietf-service-assurance@2022-08-10.yang"</t> <figure> <artwork><![CDATA[anchor="ietf-service-assurance-yang-model" numbered="true" toc="default"> <name>YANG Module</name> <t> This model contains references to <xref target="RFC6991"/>. </t> <sourcecode name="ietf-service-assurance@2023-06-02.yang" type="yang" markers="true"><![CDATA[ module ietf-service-assurance { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; prefix sain; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } organization "IETF OPSAWG Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Jean Quilbeuf <mailto:jean.quilbeu@huawei.com>"; description "This module defines objects for assuring services based on their decomposition into so-called subservices, according to theSAIN (ServiceService Assurance for Intent-basedNetworking)Networking (SAIN) architecture. The subservices hierarchicallyorganisedorganized by dependencies constitute an assurance graph. This module should be supported by an assuranceagent,agent that is able to interact with the devices in order to produceathe health status and symptoms for each subservice in the assurance graph. This module is intended for the following use cases: * Assurance graph configuration: -subservices: configureSubservices: Configure a set of subservices toassure,assure by specifying their types and parameters. -dependencies: configureDependencies: Configure the dependencies between the subservices, along with their type. * Assurance telemetry:exportExport the healthstatusstatuses of the subservices, along with the observed symptoms. Copyright (c)20222023 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 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 RFCXXXX;9418; see the RFC itself for full legal notices. "; revision2022-08-102023-06-02 { description "Initial version."; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } identity subservice-base { description "Base identity for subservice types."; } identity service-instance-type { base subservice-base; description "Specific type of subservice that represents a service instance. Instance of this type will depend on other subservices to build the top of the assurance graph."; } identity dependency-type { description "Base identity for representing dependency types."; } identity informational { 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."; } identity impacting { base dependency-type; description "Indicates that the status of the dependency directly impacts the status of the dependent."; } grouping subservice-reference { description "Reference to a specificsubservice,subservice identified by its type and identifier. This grouping is only for internal use in this module."; leaf type { type leafref { path "/subservices/subservice/type"; } description "The type of the subservice to refer to (e.g., device)."; } leaf id { type leafref { path "/subservices/subservice[type=current()/../type]/id"; } description "The identifier of the subservice to refer to."; } } grouping subservice-dependency { description "Represents a dependency to another subservice. This grouping is only for internal use in this module"; uses subservice-reference; leaf dependency-type { type identityref { base dependency-type; } description "Represents the type of dependency (e.g.,informational,informational or impacting)."; } } leaf assurance-graph-last-change { type yang:date-and-time; config false; mandatory true; description "Time and date at which the assurance graph last changed after any structural changes (dependencies and/or maintenance windows parameters) are applied to the subservice(s). The time and date must be the same or more recent than the most recent value of any changed subservices last-change time and date."; } container subservices { description "Root container for the subservices."; list subservice { key "type id"; description "List of configured subservices."; leaf type { type identityref { base subservice-base; } description "Type of thesubservice,subservice identifying the type of the part or functionality that is being assured by this listentry. For instance 'interface', 'device', 'ip-connectivity'.";entry, for instance, interface, device, or ip-connectivity."; } leaf id { type string; description "Identifier of the subservice instance. Must be unique among subservices of the same type."; } leaf last-change { type yang:date-and-time; config false; description "Date and time at which the structure 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. It is not intended for random end users but for network/system/software engineers that are able to interpret it. Therefore, no mechanism for language tagging is needed."; } container under-maintenance { presence "true"; description "The presence of this container indicates that the current subservice is undermaintenance";maintenance."; leaf contact { type string; mandatory true; description "A string used to model an administratively assigned name of the resource that is performing maintenance. It is suggested that this freeform field, which could be a URI, contains one or more of the following: IP address, management station name, network manager's name, location,orand/or phone number. It might even contain the expected maintenance time. In somecasescases, 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 { mandatory true; description "Specify the required parameters per subservice type. Each module augmenting this module with a new subservicetype,type that is a new identity based on subservice-base should augment this choice aswell,well by adding a container available only if the current subservice type is the newly added identity."; container service-instance-parameter { when "derived-from-or-self(../type, 'sain:service-instance-type')"; description "Specify the parameters of a service instance."; leaf service { type string; mandatory true; description "Name of the service."; } leaf instance-name { type string; mandatory true; description "Name of the instance for that service."; } } // Other modules can augment their own cases intoherehere. } leaf health-score { type int8 { range "-1 .. 100"; } config false; mandatory true; description "Score value of the subservice health. A value of 100 means that the 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. The special value -1 means that thehealth-scorehealth score could not be computed."; } leaf symptoms-history-start { type yang:date-and-time; config false; description "Date and time at which thesymptom’ssymptom's 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."; } container symptoms { config false; description "Symptoms for the subservice."; list symptom { key "start-date-time agent-id symptom-id"; unique "agent-id symptom-id"; description "List of symptoms of 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."; leaf symptom-id { type leafref { path "/agents/agent[id=current()/../agent-id]" + "/symptoms/id"; } description "Identifier of thesymptom,symptom to be interpreted according to the agent identified by the agent-id."; } leaf agent-id { type leafref { path "/agents/agent/id"; } description "Identifier of the agent raising the current 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 ahealth score weighthealth-score-weight larger than 0."; } 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.mustMust be after the start-date-time. If the symptom is ongoing, this field should not be populated."; } } } container dependencies { description "Indicates the set of dependencies of the current subservice, along with their types."; list dependency { key "type id"; description "List of dependencies of the subservice."; uses subservice-dependency; } } } } container agents { config false; description "Container for the list ofagents’s symptoms";agents's symptoms."; list agent { key "id"; description "Contains symptoms of each agent involved in computing the health status of the current graph. This list acts as a glossary for understanding the symptom ids returned by each agent."; leaf id { type string; description "Id of the agent for which we are defining the symptoms. This identifier must be unique among all agents."; } list symptoms { key "id"; description "List of symptoms raised by the currentagent,agent that is identified bytheirthe symptom-id."; leaf id { type string; description "Id of the symptom for the current agent. The agent must guarantee the unicity of this identifier."; } leaf description { type string; mandatory true; description "Description of the symptom, i.e., text describing what the symptom is, is to becomputer-consumablecomputer consumable andbedisplayed on a human interface. It is not intended for random end users but for network/system/software engineers that are able to interpret it. Therefore, no mechanism for language tagging is needed."; } } } } container assured-services { config false; description "Container for the index of assuredservices";services."; list assured-service { key "service"; description "Service instances that are currently part of the assurance graph. The list must contain an entry for every service that is currently present in the assurance graph. This list presents an alternate access to the graph stored in/subservicessubservices that optimizes querying the assurance graph of a specific service instance."; leaf service { type leafref { path "/subservices/subservice/service-instance-parameter/" + "service"; } description "Name of the service."; } list instances { key "name"; description "Instances of the service. The list must contain an entry for every instance of the parent service."; leaf name { type leafref { path"/subservices/subservice/service-instance-parameter/""/subservices/subservice/service-instance-parameter" +"instance-name";"/instance-name"; } description "Name of the service instance. The leafref must point to a service-instance-parameter whose service leaf matches the parent service."; } list subservices { key "type id"; description "Subservices that appear in the assurance graph of the current service instance. The list must contain the subservice corresponding to the service instance,that isi.e., the subservice that matches the service and instance-name keys. For every subservice in the list, all subservices listed as dependencies must also appear in the list."; uses subservice-reference; } } } } }]]></artwork> </figure> <t><CODE ENDS></t>]]></sourcecode> </section><!--<sectiontitle="Getting the Assurance Graph" anchor="getting-graph"> <t> In practice, getting the assurance graph of a service requires applying a graph traversal algorithm such as depth-first search (DFS) starting from the node representing the service. Such an algorithm can be applied on the global graph fetched at once. Otherwise, the algorithm can query nodes and their dependencies as needed. The second version might be more interesting if only one service is of interest among several other services in the global graph. </t> <t> A more frequent use case might be to maintain a local version of the assurance graph. Model driven telemetry (MDT) enables subscribing to a path of interest such as '/subservices/subservice/dependencies' and thus getting regular updates about the graph structure. If event driven telemetry (EDT) is supported, updates would be sent only when the structure of the graph changes. Again, one can subscribe to changes in the whole graph (e.g. to save it in a time series database (TSDB)), or only on the dependencies of selected node (e.g. to monitor evolution of the graph of a single service). In the latter case, the subscription must be updated dynamically as nodes are added and removed from the service assurance graph. </t> <t> Finally, some use cases do not require to get the whole assurance graph. For instance, the health status of a given service instance is obtained by monitoring the '/subservices/subservice/health-score' and '/subservices/subservice/symptoms' paths for that service instance. In this use case, the assurance graph might be optionally obtained by using one of the previous methods only if the health score of the service is below a given threshold. </t> </section> --> <section title="Rejectinganchor="circular-dependencies" numbered="true" toc="default"> <name>Rejecting CircularDependencies" anchor="circular-dependencies">Dependencies</name> <t><!-- Circular dependencies check is needed at the server side -->The statuses of services and subservices depend on the statuses of their dependencies, and thus circular dependencies between thempreventsprevent the computation of statuses.TheSection <xref target="RFC9417" sectionFormat="bare" section="3.1.1"/> of the SAIN architecture document <xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>target="RFC9417" format="default"/> discussesin Section 3.1.1how such dependencies appear and how they could be removed. The responsibility of avoiding such dependencies falls to the SAIN orchestrator. However, we specify in this section the expected behavior when a server supporting theietf-service-assurance"ietf-service-assurance" module receives a data instance containing circular dependencies. </t> <t><!--We cannot rely on YANG to validate -->Enforcing the absence of circular dependencies as a YANG constraint falls back to implementing a graph traversal algorithm with XPath and checking that the current node is not reachable from its dependencies. Even with such a constraint, there is no guarantee that merging two graphs without dependency loops will result in a graph without dependency loops. Indeed,the Section 3.1.1 of<xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>target="RFC9417" section="3.1.1" sectionFormat="of" format="default"/> presents an example where merging two graphs without dependency loops results in a graph with a dependency loop. </t> <t><!-- The server must reject circular dependencies -->Therefore, a server implementing theietf-service-assurance"ietf-service-assurance" moduleMUST<bcp14>MUST</bcp14> check that there is no dependency loop whenever the graph is modified. A modification creating a dependency loopMUST<bcp14>MUST</bcp14> be rejected. </t> </section> </section> <sectiontitle="Guidelinesanchor="augment-guide" numbered="true" toc="default"> <name>Guidelines for Defining New SubserviceTypes" anchor="augment-guide">Types</name> <t> The base YANG module defined in <xref target="ietf-service-assurance-yang-model"/>format="default"/> only defines a single type ofsubservicessubservice 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 for specifying such extensions at IETF. </t> <t> The mechanism to add a new subservice type is to define a new module for that subservice. The module name should start with "ietf-service-assurance-". The namespace of the module should start with "urn:ietf:params:xml:ns:yang:ietf-service-assurance-". The prefix of the module should start with "sain-". For instance, the subservice type representing the assurance of a device should have:<list style="symbols"> <t>the</t> <ul spacing="normal"> <li>the name"ietf-service-assurance-device",</t> <t>the"ietf-service-assurance-device",</li> <li>the namespace"urn:ietf:params:xml:ns:yang:ietf-service-assurance-device",</t> <t>and the"urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", and</li> <li>the prefix"sain-device".</t> </list> </t>"sain-device".</li> </ul> <t> The new module should define:<list style="symbols"> <t> A</t> <ul spacing="normal"> <li> a new identity to represent the newtype. </t> <t> Thetype and </li> <li> the parameters fully specifying an instance of the new subservice type.</t> </list> </t></li> </ul> <t> The new identity should be based on the "subservice-base" identity. The name of the identity should end with "-type", forinstanceinstance, "device-type". </t> <t> The parameters should be defined in a container named "parameters"augmenting ofthat augments the choice "/subservices/subservice/parameter" from the main module. The augmentation should be restricted to cases where the type of the subservice matches the identity representing the new service type. </t> <t> We define two subservice types in the next sections: the "device" subservice type is defined in <xreftarget="device-module"/>target="device-module" format="default"/> and the "interface" subservice type is defined is <xreftarget="interface-module"/>.target="interface-module" format="default"/>. These subservices can be taken as examples of the rules defined in this section. </t> <t> Vendors can specify their own subservices types by defining the corresponding modules in their own namespace. An example of such a vendor-specific module is specified inAppendix<xreftarget="acme-device-module"/>.target="acme-device-module" format="default"/>. Vendors can also augment existing IETF-specified subservices to add their own vendor-specific information. </t> </section> <sectiontitle="Subserviceanchor="device-module" numbered="true" toc="default"> <name>Subservice Augmentation:ietf-service-assurance-device"ietf-service-assurance-device" YANGmodule" anchor="device-module">Module</name> <sectiontitle="Tree View" anchor="ietf-service-assurance-device-tree-view">anchor="ietf-service-assurance-device-tree-view" numbered="true" toc="default"> <name>Tree View</name> <t> The following tree diagram <xreftarget="RFC8340"/>target="RFC8340" format="default"/> provides an overview of the "ietf-service-assurance-device" module. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-service-assurance-device augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw device string]]></artwork> </figure> </t>]]></sourcecode> <t>A complete tree view of the base module with all augmenting modules presented in thisdraftdocument is available in <xreftarget="global_tree_view"/>.target="global_tree_view" format="default"/>. </t> </section> <sectiontitle="Concepts" anchor="ietf-service-assurance-device-concepts">anchor="ietf-service-assurance-device-concepts" numbered="true" toc="default"> <name>Concepts</name> <t> 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 device subservice type. As the name implies, it monitors and reports the device health, along with some symptoms in case of degradation. </t> <t> For our device subservice definition, the new identity "device-type" isspecified,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. </t> <t> The typical parameter for the configuration of the device subservice is the name of the device that we want to assure. By augmenting the parameter choice fromietf-service-assurancethe "ietf-service-assurance" YANG module for the case of the "device-type" subservice type, this new parameter is specified. </t> </section> <sectiontitle="YANG Module" anchor="ietf-service-assurance-device-yang-model"> <t><CODE BEGINS> file "ietf-service-assurance-device@2022-08-10.yang"</t> <figure> <artwork><![CDATA[anchor="ietf-service-assurance-device-yang-model" numbered="true" toc="default"> <name>YANG Module</name> <sourcecode name="ietf-service-assurance-device@2023-06-02.yang" type="yang" markers="true"><![CDATA[ module ietf-service-assurance-device { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; prefix sain-device; import ietf-service-assurance { prefix sain; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } organization "IETF OPSAWG Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; description "This module augments the ietf-service-assurance module with support of the device subservice. Copyright (c)20222023 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 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 RFCXXXX;9418; see the RFC itself for full legal notices. "; revision2022-08-102023-06-02 { description "Initial revision."; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } identity device-type { base sain:subservice-base; description "Identity of device subservice."; } augment "/sain:subservices/sain:subservice/sain:parameter" { when "derived-from-or-self(sain:type, 'device-type')"; description "Augments the parameter choice from the ietf-service-assurance module with a case specific to the device subservice."; container parameters { description "Parameters for the device subservicetype";type."; leaf device { type string; mandatory true; description "Identifier of the device to monitor. The identifier(e.g.(e.g., device id, hostname, or management IP) depends on the context."; } } } }]]></artwork> </figure> <t><CODE ENDS></t>]]></sourcecode> </section> </section> <sectiontitle="Subserviceanchor="interface-module" numbered="true" toc="default"> <name>Subservice Augmentation:ietf-service-assurance-interface"ietf-service-assurance-interface" YANGmodule" anchor="interface-module">Module</name> <sectiontitle="Tree View" anchor="ietf-service-assurance-interface-tree-view">anchor="ietf-service-assurance-interface-tree-view" numbered="true" toc="default"> <name>Tree View</name> <t> The following tree diagram <xreftarget="RFC8340"/>target="RFC8340" format="default"/> provides an overview of theietf-service-assurance-interface"ietf-service-assurance-interface" data model. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-service-assurance-interface augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw device string +--rw interface string]]></artwork> </figure> </t>]]></sourcecode> <t>A complete tree view of the base module with all augmenting modules presented in thisdraftdocument is available in <xreftarget="global_tree_view"/>.target="global_tree_view" format="default"/>. </t> </section> <sectiontitle="Concepts" anchor="ietf-service-assurance-interface-concepts">anchor="ietf-service-assurance-interface-concepts" numbered="true" toc="default"> <name>Concepts</name> <t> For the interface subservice definition, the new interface-type isspecified,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. </t> <t> The parameters for the configuration of the interface subservice are the name of the device and, on that specific device, a specific interface. These parameters are aligned with theietf-interfaces"ietf-interfaces" model described in <xreftarget="RFC8343"/>target="RFC8343" format="default"/>, where the name of the interface is the only key needed to identify an interface on a given device. By augmenting the parameter choice fromietf-service-assurancethe "ietf-service-assurance" YANG module for the case of the interface-type subservice type, those two new parameters are specified. </t> </section> <sectiontitle="YANG Module" anchor="ietf-service-assurance-interface-yang-model"> <t><CODE BEGINS> file "ietf-service-assurance-interface@2022-08-10.yang"</t> <figure> <artwork><![CDATA[anchor="ietf-service-assurance-interface-yang-model" numbered="true" toc="default"> <name>YANG Module</name> <sourcecode name="ietf-service-assurance-interface@2023-06-02.yang" type="yang" markers="true"><![CDATA[ module ietf-service-assurance-interface { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; prefix sain-interface; import ietf-service-assurance { prefix sain; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } organization "IETF OPSAWG Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; description "This module extends the ietf-service-assurance module to add support for the interface subservice.ChecksIt checks whether an interface is healthy. Copyright (c)20222023 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 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 RFCXXXX;9418; see the RFC itself for full legal notices. "; revision2022-08-102023-06-02 { description "Initial revision."; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } identity interface-type { base sain:subservice-base; description "Checks whether an interface is healthy."; } augment "/sain:subservices/sain:subservice/sain:parameter" { when "derived-from-or-self(sain:type, 'interface-type')"; description "Augments the parameter choice from ietf-service-assurance module with a case specific to the interface subservice."; container parameters { description "Parameters for the interface subservice type."; leaf device { type string; mandatory true; description "Device supporting the interface."; } leaf interface { type string; mandatory true; description "Name of the interface."; } } } }]]></artwork> </figure> <t><CODE ENDS></t>]]></sourcecode> </section> </section><!-- <section title="Guidelines for Specific Subservice Extension" anchor="guidelines-specific-subservice"> <t> The base YANG module defined in <xref target="ietf-service-assurance-yang-model" /> 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. </t> <t> 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 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. </t> <t> In this section, by subservice YANG module, we mean "YANG module that extends ietf-service-assurance in order to define a specific subservice". </t> <section title="Module Name"> <t> For subservice YANG modules vetted by the IETF, the module name should be "ietf-service-assurance-" followed by the short name. For instance, "ietf-service-assurance-interface" or "ietf-service-assurance-is-is". </t> <t> 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. </t> </section> <section title="Module Namespace"> <t> 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:example-service-assurance-is-is". </t> <t> 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. </t> </section> <section title="Module Prefix"> <t> For subservice YANG modules vetted by the IETF, the module prefix should be "sain-" followed by the short name. For instance, "sain-interface" or "sain-is-is". </t> <t> 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. </t> </section> <section title="Subservice Specific Identity" anchor="guidelines_subservice_identity"> <t> 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 <xref target="ietf-service-assurance-yang-model"/>), that identity must be based on the "subservice-base" identity. </t> <t> For subservice YANG modules vetted by the IETF, the subservice specific identity should be the short name of the subservice followed by "-type". For instance, "interface-type" or "is-is-type". </t> <t> For subservice YANG module that are directly provided by vendors, the same pattern can be used. </t> </section> <section title="Parameters"> <t> 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 <xref target="ietf-service-assurance-yang-model"/> and that augment must be guarded so that it is effective only for subservice instance whose type is the subservice specific identity from <xref target="guidelines_subservice_identity" />. </t> <t> For subservice YANG module that are directly provided by vendors, the same pattern can be used. </t> </section> </section> --><section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> The YANGmodulemodules specified in this documentdefines adefine schema for data that is designed to be accessed via network management protocols such as NETCONF <xreftarget="RFC6241"/>target="RFC6241" format="default"/> or RESTCONF <xreftarget="RFC8040"/>.target="RFC8040" format="default"/>. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) <xreftarget="RFC6242"/>.target="RFC6242" format="default"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xreftarget="RFC8446"/>.target="RFC8446" format="default"/>. </t> <t> The Network Configuration Access Control Model (NACM) <xreftarget="RFC8341"/>target="RFC8341" format="default"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. </t> <t>There are a number of data nodes defined inthisthese YANGmodulemodules that arewritable/ creatable/deletablewritable/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:<list style="symbols"> <t></t> <ul spacing="normal"> <li> /subservices/subservice : By modifying this subtree, one can modify the structure of the assurancegraphgraph, which could alter the status of the services reported by the assurance framework. On one hand, modifications can cause the assurance system to report a service as broken when it is actually healthy (false positive), resulting in engineers or automation software losingtime,time and potentiallycausecausing real issues by doing unnecessary modifications on the network. On the other hand, modifications could prevent the assurance systemto reportfrom reporting actual issues (false negative), resulting in failures that could have been avoided. Depending on the service, the impact of these avoidable failures could beSLAService-Level Agreement (SLA) violations fees or disruption of emergency calls.</t> </list> </t></li> </ul> <t> Some readable data nodes inthisthese YANGmodulemodules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:<list style="symbols"> <t>/subservices/subservice</t> <t>/agents/agent</t> <t>/assured-services/assured-service</t> </list></t> <ul spacing="normal"> <li>/subservices/subservice</li> <li>/agents/agent</li> <li>/assured-services/assured-service</li> </ul> <t> Each of these subtrees contains information about services,subservicessubservices, or possible symptoms raised by the agents. The information contained in this subtree might give information about the underlying network as well as services deployed for the customers. For instance, a customer might be given access to monitor their services status(e.g.(e.g., via model-driven telemetry). In that example, the customer access should be restricted to nodes representing theirservices,services so as not to divulge information about the underlying network structure or others customers services. </t> </section> <section anchor="iana"title="IANA Considerations"> <section title="Thenumbered="true" toc="default"> <name>IANA Considerations</name> <section numbered="true" toc="default"> <name>The IETF XMLRegistry"><t>This document registers 3Registry</name> <t>IANA has registered the following three URIs in theIETF"IETF XMLregistry <xref target="RFC3688"/>. Following the format inRegistry" <xreftarget="RFC3688"/>, the following registrations are requested:</t><t><figure><artwork> URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance Registrant Contact: Thetarget="RFC3688" format="default"/>:</t> <dl newline="false" spacing="compact"> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-service-assurance</dd> <dt>Registrant Contact:</dt> <dd>The OPSAWG WG of theIETF. XML: N/A,IETF.</dd> <dt>XML:</dt> <dd>N/A; the requested URI is an XMLnamespace. URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device Registrant Contact: Thenamespace.</dd> </dl> <dl newline="false" spacing="compact"> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-service-assurance-device</dd> <dt>Registrant Contact:</dt> <dd>The OPSAWG WG of theIETF. XML: N/A,IETF.</dd> <dt>XML:</dt> <dd>N/A; the requested URI is an XMLnamespace. URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface Registrant Contact: Thenamespace.</dd> </dl> <dl newline="false" spacing="compact"> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface</dd> <dt>Registrant Contact:</dt> <dd>The OPSAWG WG of theIETF. XML: N/A,IETF.</dd> <dt>XML:</dt> <dd>N/A; the requested URI is an XMLnamespace. </artwork></figure></t></section>namespace.</dd> </dl> </section> <sectiontitle="Thenumbered="true" toc="default"> <name>The YANG Module NamesRegistry"> <t>This document registersRegistry</name> <t>IANA has registered the following three YANG modules in theYANG"YANG ModuleNamesNames" registry <xreftarget="RFC7950"/>. Following the format in <xref target="RFC7950"/>, the following registrations are requested:</t> <t><figure><artwork> name: ietf-service-assurance namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance prefix: sain reference: RFC XXXX name: ietf-service-assurance-device namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device prefix: sain-device reference: RFC XXXX name: ietf-service-assurance-interface namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface prefix: sain-interface reference: RFC XXXX </artwork></figure></t>target="RFC7950" format="default"/>: </t> <dl newline="false" spacing="compact"> <dt>name:</dt> <dd>ietf-service-assurance</dd> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-service-assurance</dd> <dt>prefix:</dt> <dd>sain</dd> <dt>reference:</dt> <dd>RFC 9418</dd> </dl> <dl newline="false" spacing="compact"> <dt>name:</dt> <dd>ietf-service-assurance-device</dd> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-service-assurance-device</dd> <dt>prefix:</dt> <dd>sain-device</dd> <dt>reference:</dt> <dd>RFC 9418</dd> </dl> <dl newline="false" spacing="compact"> <dt>name:</dt> <dd>ietf-service-assurance-interface</dd> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface</dd> <dt>prefix:</dt> <dd>sain-interface</dd> <dt>reference:</dt> <dd>RFC 9418</dd> </dl> <t>All theseThese modules are not maintained by IANA. </t> </section> </section> </middle> <back><references title="Normative References"> <?rfc include='reference.I-D.ietf-opsawg-service-assurance-architecture'?> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.3688'?> <?rfc include='reference.RFC.6241'?> <?rfc include='reference.RFC.6242'?> <?rfc include='reference.RFC.6991'?> <?rfc include='reference.RFC.7950'?> <?rfc include="reference.RFC.8040"?> <?rfc include='reference.RFC.8174'?> <?rfc include="reference.RFC.8446"?> <?rfc include="reference.RFC.8341"?> <?rfc include="reference.RFC.8342"?><references> <name>References</name> <references> <name>Normative References</name> <reference anchor='RFC9417' target='https://www.rfc-editor.org/info/rfc9417'> <front> <title> Service Assurance for Intent-Based Networking Architecture </title> <author initials="B." surname="Claise" fullname="Benoit Claise"> </author> <author initials="J." surname="Quilbeuf" fullname="Jean Quilbeuf"> </author> <author initials="D." surname="Lopez" fullname="Diego R. Lopez"> </author> <author initials="D." surname="Voyer" fullname="Dan Voyer"> </author> <author initials="T." surname="Arumugam" fullname="Thangam Arumugam"> </author> <date month="June" year="2023"/> </front> <seriesInfo name="RFC" value="9417"/> <seriesInfo name="DOI" value="10.17487/RFC9417"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8525.xml"/> </references><references title="Informative References"> <?rfc include="reference.RFC.8340"?> <?rfc include="reference.RFC.8343"?> <?rfc include="reference.RFC.8525"?></references><?rfc needLines="100"?><sectiontitle="Vendor-specificanchor="acme-device-module" numbered="true" toc="default"> <name>Vendor-Specific Subservice Augmentation:example-service-assurance-device-acme"example-service-assurance-device-acme" YANGmodule" anchor="acme-device-module">Module</name> <sectiontitle="Tree View" anchor="example-service-assurance-device-acme-tree-view">anchor="example-service-assurance-device-acme-tree-view" numbered="true" toc="default"> <name>Tree View</name> <t> The following tree diagram <xreftarget="RFC8340"/>target="RFC8340" format="default"/> provides an overview of the "example-service-assurance-device-acme" module. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: example-service-assurance-device-acme augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw device string +--rw acme-specific-parameter string]]></artwork> </figure> </t>]]></sourcecode> <t>A complete tree view of the base module with all augmenting modules presented in thisdraftdocument is available in <xreftarget="global_tree_view"/>.target="global_tree_view" format="default"/>. </t> </section> <sectiontitle="Concepts" anchor="example-service-assurance-device-acme-concepts">anchor="example-service-assurance-device-acme-concepts" numbered="true" toc="default"> <name>Concepts</name> <t> 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 custom support for the devicesubservice,subservice specific to theACMEAcme Corporation. The specific version adds a newparameter,parameter named "acme-specific-parameter". It's an implementation choice to either derive a new specific identity from the "subservice-base" identity defined inietf-service-assurancethe "ietf-service-assurance" module or to augment the parameters fromietf-service-assurance-device, herethe "ietf-service-assurance-device" module; here, we choose to create a new identity. </t> </section> <sectiontitle="YANG Module" anchor="example-service-assurance-device-acme-yang-model"> <figure> <artwork><![CDATA[anchor="example-service-assurance-device-acme-yang-model" numbered="true" toc="default"> <name>YANG Module</name> <sourcecode type="yang"><![CDATA[ module example-service-assurance-device-acme { yang-version 1.1; namespace "urn:example:example-service-assurance-device-acme"; prefix example-device-acme; import ietf-service-assurance { prefix sain; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } import ietf-service-assurance-device { prefix sain-device; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } organization "IETF OPSAWG Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; description "This example module extends the ietf-service-assurance-device module to add specific support for devices ofACMEthe Acme Corporation. "; revision2022-08-102023-06-02 { description "Initialrevision";revision."; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } identity device-acme-type { base sain-device:device-type; description "NetworkDevicedevice is healthy."; } augment "/sain:subservices/sain:subservice/sain:parameter" { when "derived-from-or-self(sain:type, 'device-acme-type')"; description "Augments the parameter choice from the ietf-service-assurance module with a case specific to the device-acme subservice."; container parameters { description "Parameters for the device-acme subservicetype";type."; leaf device { type string; mandatory true; description "The device to monitor."; } leaf acme-specific-parameter { type string; mandatory true; description "TheACME Corporation specificAcme-Corporation-specific parameter."; } } } }]]></artwork> </figure>]]></sourcecode> </section> </section> <sectiontitle="Furtheranchor="ip-connectivity-is-is" numbered="true" toc="default"> <name>Further Augmentations: IP Connectivity and IS-ISsubservices" anchor="ip-connectivity-is-is">Subservices</name> <t> In this section, we provide two additional YANG modules to completely cover the example in Figure 2 fromSection 3.1 of<xreftarget="I-D.ietf-opsawg-service-assurance-architecture"/>.target="RFC9417" section="3.1" sectionFormat="of" format="default"/>. The two missing subservice types are IPConnectivityconnectivity and the Intermediate System to Intermediate System (IS-IS) routing protocol. These modules are presented asexamples,examples; some future work is needed to propose a more complete version. </t> <sectiontitle="IPnumbered="true" toc="default"> <name>IP Connectivity Module TreeView">View</name> <t> That subservice represents the unicast connectivity between two IP addresses located on two different devices. Such a subservice could report symptoms such as "No route found". The following tree diagram <xreftarget="RFC8340"/>target="RFC8340" format="default"/> provides an overview of the "example-service-assurance-ip-connectivity" module. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ 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]]></artwork> </figure> </t>]]></sourcecode> <t> 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. </t> </section> <sectiontitle="IS-ISnumbered="true" toc="default"> <name>IS-IS Module TreeView">View</name> <t> The following tree diagram <xreftarget="RFC8340"/>target="RFC8340" format="default"/> provides an overview of the "example-service-assurance-is-is" module. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: example-service-assurance-is-is augment /sain:subservices/sain:subservice/sain:parameter: +--rw parameters +--rw instance-name string]]></artwork> </figure> </t>]]></sourcecode> <t> The parameter of this subservice is the name of the IS-IS instance to assure. </t> </section> <sectiontitle="Globalanchor="global_tree_view" numbered="true" toc="default"> <name>Global TreeView" anchor="global_tree_view">View</name> <t> The following tree diagram <xreftarget="RFC8340"/>target="RFC8340" format="default"/> provides an overview of the "ietf-service-assurance", "ietf-service-assurance-device", "example-service-assurance-device-acme","example-service-assurance-ip-connectivity""example-service-assurance-ip-connectivity", and "example-service-assurance-is-is" modules. </t><t> <figure> <artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-service-assurance +--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! | | +--rw contact string | +--rw (parameter) | | +--:(service-instance-parameter) | | | +--rw service-instance-parameter | | | +--rw service string | | | +--rw instance-name 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 int8 | +--ro symptoms-history-start? | | yang:date-and-time | +--ro symptoms | | +--ro symptom* [start-date-time agent-id symptom-id] | | +--ro symptom-id leafref | | +--ro agent-id -> /agents/agent/id | | +--ro health-score-weight? uint8 | | +--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 leafref | +--rw dependency-type? identityref +--ro agents | +--ro agent* [id] | +--ro id string | +--ro symptoms* [id] | +--ro id string | +--ro description string +--ro assured-services +--ro assured-service* [service] +--ro service leafref +--ro instances* [name] +--ro name leafref +--ro subservices* [type id] +--ro type -> /subservices/subservice/type +--ro id leafref]]></artwork> </figure> </t>]]></sourcecode> </section> <sectiontitle="IPnumbered="true" toc="default"> <name>IP Connectivity YANGModule"> <figure> <artwork><![CDATA[Module</name> <sourcecode type="yang"><![CDATA[ module example-service-assurance-ip-connectivity { yang-version 1.1; 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 sain; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } organization "IETF OPSAWG Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; description "This example module augments the ietf-service-assurance module to add support for the subservice ip-connectivity.ChecksIt checks whether theipIP connectivity between twoipIP addresses belonging to two network devices is healthy."; revision2022-08-102023-06-02 { description "Initialversion";version."; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } identity ip-connectivity-type { base sain:subservice-base; description "Checks connectivity between two IP addresses."; } augment "/sain:subservices/sain:subservice/sain:parameter" { when "derived-from-or-self(sain:type, 'ip-connectivity-type')"; description "Augments the parameter choice from the ietf-service-assurance module with a case specific to the ip-connectivity subservice."; container parameters { description "Parameters for the ip-connectivity subservicetype";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 "Address at the first end of the connection."; } leaf device2 { type string; mandatory true; 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."; } } } }]]></artwork> </figure>]]></sourcecode> </section> <sectiontitle="IS-IS YANG Module"> <figure> <artwork><![CDATA[numbered="true" toc="default"> <name>IS-IS YANG Module</name> <sourcecode type="yang"><![CDATA[ module example-service-assurance-is-is { yang-version 1.1; namespace "urn:example:example-service-assurance-is-is"; prefix example-is-is; import ietf-service-assurance { prefix sain; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } organization "IETF OPSAWG Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; description "This example module augments the ietf-service-assurance module to add support for the subservice is-is.ChecksIt checks whether an IS-IS instance is healthy."; revision2022-08-102023-06-02 { description "Initialversion";version."; reference "RFCxxxx:9418: YANG Modules for Service Assurance"; } identity is-is-type { base sain:subservice-base; description "Health of IS-IS routing protocol."; } augment "/sain:subservices/sain:subservice/sain:parameter" { when "derived-from-or-self(sain:type, 'is-is-type')"; description "Augments the parameter choice from the ietf-service-assurance module with a case specific to the is-is subservice."; container parameters { description "Parameters for the is-is subservice type."; leaf instance-name { type string; mandatory true; description "The instance to monitor."; } } } }]]></artwork> </figure>]]></sourcecode> </section> </section> <sectiontitle="Exampleanchor="example_instances" numbered="true" toc="default"> <name>Example of a YANGinstance" anchor="example_instances">Instance</name> <t> This section contains an example of a YANG instance thatconformconforms to the YANG modules. The validity of this data instance has been checked using <eref target="https://yangson.labs.nic.cz/">yangson</eref>.brackets="angle">yangson</eref>. Yangson requires a YANG library <xreftarget="RFC8525"/>target="RFC8525" format="default"/> to define the complete model against which the data instance must be validated.We provide inIn <xref target="yang_library_for_validation"/>format="default"/>, we provide the JSON libraryfile,file named "ietf-service-assurance-library.json",thatwhich we used for validation. </t> <t>WeBelow, we providebelowthe contents of the file"example_configuration_instance.json""example_configuration_instance.json", which contains the configuration data that modelstheFigure 2 fromSection 3.1 of<xreftarget="I-D.ietf-opsawg-service-assurance-architecture" />.target="RFC9417" section="3.1" sectionFormat="of" format="default"/>. 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 thisdraftdocument reside in the current folder. </t><figure> <artwork><![CDATA[<sourcecode type="json"><![CDATA[ { "ietf-service-assurance:subservices": { "subservice": [ { "type": "service-instance-type", "id": "simple-tunnel/example", "service-instance-parameter": { "service": "simple-tunnel", "instance-name": "example" }, "dependencies": { "dependency": [ { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer1/tunnel0", "dependency-type": "impacting" }, { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer2/tunnel9", "dependency-type": "impacting" }, { "type": "example-service-assurance-ip-connectivity:ip-connectivity-type", "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", "dependency-type": "impacting" } ] } }, { "type": "example-service-assurance-ip-connectivity:ip-connectivity-type", "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", "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-type", "id": "interface/peer1/physical0", "dependency-type": "impacting" }, { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer2/physical5", "dependency-type": "impacting" }, { "type": "example-service-assurance-is-is:is-is-type", "id": "is-is/instance1", "dependency-type": "impacting" } ] } }, { "type": "example-service-assurance-is-is:is-is-type", "id": "is-is/instance1", "example-service-assurance-is-is:parameters": { "instance-name": "instance1" } }, { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer1/tunnel0", "ietf-service-assurance-interface:parameters": { "device": "Peer1", "interface": "tunnel0" }, "dependencies": { "dependency": [ { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer1/physical0", "dependency-type": "impacting" } ] } }, { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer1/physical0", "ietf-service-assurance-interface:parameters": { "device": "Peer1", "interface": "physical0" }, "dependencies": { "dependency": [ { "type": "ietf-service-assurance-device:device-type", "id": "interface/peer1", "dependency-type": "impacting" } ] } }, { "type": "ietf-service-assurance-device:device-type", "id": "interface/peer1", "ietf-service-assurance-device:parameters": { "device": "Peer1" } }, { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer2/tunnel9", "ietf-service-assurance-interface:parameters": { "device": "Peer2", "interface": "tunnel9" }, "dependencies": { "dependency": [ { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer2/physical5", "dependency-type": "impacting" } ] } }, { "type": "ietf-service-assurance-interface:interface-type", "id": "interface/peer2/physical5", "ietf-service-assurance-interface:parameters": { "device": "Peer2", "interface": "physical5" }, "dependencies": { "dependency": [ { "type": "ietf-service-assurance-device:device-type", "id": "interface/peer2", "dependency-type": "impacting" } ] } }, { "type": "ietf-service-assurance-device:device-type", "id": "interface/peer2", "ietf-service-assurance-device:parameters": { "device": "Peer2" } } ] } }]]></artwork> </figure>]]></sourcecode> </section> <sectiontitle="YANGanchor="yang_library_for_validation" numbered="true" toc="default"> <name>YANG Library for ServiceAssurance" anchor="yang_library_for_validation">Assurance</name> <t> This section provides the JSON encoding of the YANG library <xreftarget="RFC8525"/> listingtarget="RFC8525" format="default"/> that lists all modules defined in thisdraftdocument and their dependencies. This library can be used to validate data instances using yangson, as explained in the previous section. </t><figure> <artwork><![CDATA[<sourcecode type="json"><![CDATA[ { "ietf-yang-library:modules-state": { "module-set-id":"ietf-service-assurance@2022-08-10","ietf-service-assurance@2023-06-02", "module": [ { "name": "ietf-service-assurance", "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance", "revision":"2022-08-10","2023-06-02", "conformance-type": "implement" }, { "name": "ietf-service-assurance-device", "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", "revision":"2022-08-10","2023-06-02", "conformance-type": "implement" }, { "name": "ietf-service-assurance-interface", "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", "revision":"2022-08-10","2023-06-02", "conformance-type": "implement" }, { "name": "example-service-assurance-device-acme", "namespace": "urn:example:example-service-assurance-device-acme", "revision":"2022-08-10","2023-06-02", "conformance-type": "implement" }, { "name": "example-service-assurance-is-is", "namespace": "urn:example:example-service-assurance-is-is", "revision":"2022-08-10","2023-06-02", "conformance-type": "implement" }, { "name": "example-service-assurance-ip-connectivity", "namespace": "urn:example:example-service-assurance-ip-connectivity", "revision":"2022-08-10","2023-06-02", "conformance-type": "implement" }, { "name": "ietf-yang-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "revision":"2021-04-14","2013-07-05", "conformance-type": "import" }, { "name": "ietf-inet-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", "revision":"2021-02-22","2013-07-05", "conformance-type": "import" } ] } }]]></artwork> </figure>]]></sourcecode> </section> <sectiontitle="Changes between revisions"> <t>[[RFC editor: please remove this section before publication.]]</t> <t>v09 - v10 <list style="symbols"> <t>Address comments from Last Call</t> </list> </t> <t>v07 - v08 <list style="symbols"> <t>Address comments from Rob Wilton’s AD review</t> </list> </t> <t>v06 - v07 <list style="symbols"> <t>Addressed early YANG doctor comments from version -06: changed -idty for -type or -base in identity names and removed "under-maintenance" leaf </t> <t>Add new list of services with the corresponding subservices</t> <t>Remove assurance-graph-version and state the limitations of having only the current graph available in the module.</t> <t>Added new list of agents to store symptom and guarantee unicity of symptom ids </t> <t>Added security consideration for readable nodes</t> <t>Added section on rejecting circular dependencies</t> </list> </t> <t>v05 - v06 <list style="symbols"> <t>Remove revision history in modules</t> <t>Present elements in order of the tree for the main module</t> <t>Rewriting and rewording for clarity</t> <t>Made parameters mandatory for the subservices</t> </list> </t> <t>v04 - v05 <list style="symbols"> <t>Remove Guidelines section </t> <t>Move informative parts (examples) to appendix</t> <t>Minor text edits and reformulations</t> </list> </t> <t>v03 - v04 <list style="symbols"> <t> Fix YANG errors </t> <t> Change is-is and ip-connectivity subservices from ietf to example.</t> <t> Mention that models are NMDA compliant </t> <t> Fix typos, reformulate for clarity </t> </list> </t> <t>v02 - v03 <list style="symbols"> <t>Change counter32 to counter64 to avoid resetting too frequently </t> <t>Explain why relation between health-score and symptom’s health-score-weight is not defined and how it could be defined</t> </list> </t> <t>v01 - v02 <list style="symbols"> <t>Explicitly represent the fact that the health-score could not be computed (value -1)</t> </list> </t> <t>v00 - v01 <list style="symbols"> <t>Added needed subservice to model example from architecture draft</t> <t>Added guideline section for naming models</t> <t>Added data instance examples and validation procedure</t> <t>Added the "parameters" container in the interface YANG module to correct a bug.</t> </list> </t> </section> <section title="Acknowledgements" numbered="no">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thankJan Lindblad<contact fullname="Jan Lindblad"/> for his help during the design of these YANG modules. The authors would like to thankStephane Litkowski, Charles Eckel, Mohamed Boucadair, Tom Petch, Dhruv Dhody and Rob Wilton<contact fullname="Stephane Litkowski"/>, <contact fullname="Charles Eckel"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Tom Petch"/>, <contact fullname="Dhruv Dhody"/>, and <contact fullname="Rob Wilton"/> for their reviews. </t> </section> </back> </rfc> <!-- Local Variables: --> <!-- fill-column:72 --> <!-- End: -->