rfc9418.original   rfc9418.txt 
OPSAWG B. Claise Internet Engineering Task Force (IETF) B. Claise
Internet-Draft J. Quilbeuf Request for Comments: 9418 J. Quilbeuf
Intended status: Standards Track Huawei Category: Standards Track Huawei
Expires: 7 July 2023 P. Lucente ISSN: 2070-1721 P. Lucente
NTT NTT
P. Fasano P. Fasano
TIM S.p.A TIM S.p.A
T. Arumugam T. Arumugam
Cisco Systems, Inc. Consultant
3 January 2023 June 2023
YANG Modules for Service Assurance A YANG Data Model for Service Assurance
draft-ietf-opsawg-service-assurance-yang-11
Abstract Abstract
This document specifies YANG modules for representing assurance This document specifies YANG modules for representing assurance
graphs. These graphs represent the assurance of a given service by graphs. These graphs represent the assurance of a given service by
decomposing it into atomic assurance elements called subservices. A decomposing it into atomic assurance elements called subservices.
companion document, Service Assurance for Intent-based Networking The companion document, "Service Assurance for Intent-Based
Architecture, presents an architecture for implementing the assurance Networking Architecture" (RFC 9417), presents an architecture for
of such services. implementing the assurance of such services.
The YANG data models in this document conforms to the Network The YANG data models in this document conform to the Network
Management Datastore Architecture (NMDA) defined in RFC 8342. Management Datastore Architecture (NMDA) defined in RFC 8342.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 July 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9418.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. YANG Modules Overview . . . . . . . . . . . . . . . . . . . . 3 2. YANG Modules Overview
3. Base IETF Service Assurance YANG Module . . . . . . . . . . . 4 3. Base IETF Service Assurance YANG Module
3.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Concepts
3.2. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Tree View
3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. YANG Module
3.4. Rejecting Circular Dependencies . . . . . . . . . . . . . 20 3.4. Rejecting Circular Dependencies
4. Guidelines for Defining New Subservice Types . . . . . . . . 20 4. Guidelines for Defining New Subservice Types
5. Subservice Augmentation: ietf-service-assurance-device YANG 5. Subservice Augmentation: "ietf-service-assurance-device" YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . 21 Module
5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Tree View
5.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Concepts
5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. YANG Module
6. Subservice Augmentation: ietf-service-assurance-interface YANG 6. Subservice Augmentation: "ietf-service-assurance-interface"
module . . . . . . . . . . . . . . . . . . . . . . . . . 24 YANG Module
6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Tree View
6.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Concepts
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. YANG Module
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 27 8.1. The IETF XML Registry
8.2. The YANG Module Names Registry . . . . . . . . . . . . . 28 8.2. The YANG Module Names Registry
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 28 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 30 9.2. Informative References
Appendix A. Vendor-specific Subservice Augmentation: Appendix A. Vendor-Specific Subservice Augmentation:
example-service-assurance-device-acme YANG module . . . . 30 "example-service-assurance-device-acme" YANG Module
A.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 30 A.1. Tree View
A.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. Concepts
A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 31 A.3. YANG Module
Appendix B. Further Augmentations: IP Connectivity and IS-IS Appendix B. Further Augmentations: IP Connectivity and IS-IS
subservices . . . . . . . . . . . . . . . . . . . . . . . 32 Subservices
B.1. IP Connectivity Module Tree View . . . . . . . . . . . . 32 B.1. IP Connectivity Module Tree View
B.2. IS-IS Module Tree View . . . . . . . . . . . . . . . . . 33 B.2. IS-IS Module Tree View
B.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 33 B.3. Global Tree View
B.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 35 B.4. IP Connectivity YANG Module
B.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 37 B.5. IS-IS YANG Module
Appendix C. Example of YANG instance . . . . . . . . . . . . . . 38 Appendix C. Example of a YANG Instance
Appendix D. YANG Library for Service Assurance . . . . . . . . . 41 Appendix D. YANG Library for Service Assurance
Appendix E. Changes between revisions . . . . . . . . . . . . . 43 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
[I-D.ietf-opsawg-service-assurance-architecture] describes an [RFC9417] describes an architecture and a set of involved components
architecture and a set of involved components for service assurance, for service assurance, called Service Assurance for Intent-based
called Service Assurance for Intent-Based Networking (SAIN). This Networking (SAIN). This document complements the architecture by
document complements the architecture by specifying a data model for specifying a data model for the interfaces between components. More
the interfaces between components. More specifically, the document specifically, the document provides YANG modules for the purpose of
provides YANG modules for the purpose of service assurance in a service assurance in a format that is:
format that is:
* machine-readable * machine readable,
* vendor independent * vendor independent, and
* augmentable such that SAIN agents from Figure 1 of * augmentable such that SAIN agents from Figure 1 of [RFC9417] can
[I-D.ietf-opsawg-service-assurance-architecture] can support and support and expose new subservices to SAIN orchestrators and
expose new subservices to SAIN orchestrators and collectors. collectors.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terms used in this document are defined in The terms used in this document are defined in [RFC9417].
[I-D.ietf-opsawg-service-assurance-architecture].
The meanings of the symbols in the tree diagrams are defined in The meanings of the symbols in the tree diagrams are defined in
[RFC8340]. [RFC8340].
2. YANG Modules Overview 2. YANG Modules Overview
The main YANG module, "ietf-service-assurance" (Section 3), defines The main YANG module, "ietf-service-assurance" (Section 3), defines
objects for assuring network services based on their decomposition objects for assuring network services based on their decomposition
into so-called subservices. The subservices are hierarchically into so-called subservices. The subservices are hierarchically
organized by dependencies. The subservices, along with the organized by dependencies. The subservices, along with the
dependencies, constitute an assurance graph. This module should be dependencies, constitute an assurance graph. This module should be
supported by an agent, able to interact with the devices in order to supported by an agent that is able to interact with the devices in
produce a health status and symptoms for each subservice in an order to produce the health statuses and symptoms for each subservice
assurance graph. This module is intended for the following use in an assurance graph. This module is intended for the following use
cases: cases:
* Assurance graph configuration: * Assurance graph configuration:
- Subservices: configure a set of subservices to assure, by - Subservices: Configure a set of subservices to assure by
specifying their types and parameters. specifying their types and parameters.
- Dependencies: configure the dependencies between the - Dependencies: Configure the dependencies between the
subservices, along with their type. subservices, along with their types.
* Assurance telemetry: export the assurance graph with health status * Assurance telemetry: Export the assurance graph with health
and symptoms for each node. statuses and symptoms for each node.
The module is also intended to be exported by the SAIN collector The module is also intended to be exported by the SAIN collector that
which aggregates the output of several SAIN agents to provide the aggregates the output of several SAIN agents to provide the global
global assurance graph. In that case, only the telemetry export use assurance graph. In that case, only the telemetry export use case is
case is considered. considered.
The modules presented in this document conform to the Network The modules presented in this document conform to the Network
Management Datastore Architecture defined in [RFC8342]. Management Datastore Architecture (NMDA) defined in [RFC8342].
The second YANG module, "ietf-service-assurance-device" (Section 5), The second YANG module, "ietf-service-assurance-device" (Section 5),
augments the "ietf-service-assurance" module by adding support for augments the "ietf-service-assurance" module by adding support for
the device subservice. Additional subservice types might be added the device subservice. Additional subservice types might be added
following a similar approach. following a similar approach.
The third YANG module, "ietf-service-assurance-interface" The third YANG module, "ietf-service-assurance-interface"
(Section 6), augments the "ietf-service-assurance" module as well, by (Section 6), augments the "ietf-service-assurance" module as well by
adding support for the interface subservice. adding support for the interface subservice.
We provide additional examples in the appendix. The module "example- We provide additional examples in the appendix. The module "example-
service-assurance-device-acme" (Appendix A) augments the "ietf- service-assurance-device-acme" (Appendix A) augments the "ietf-
service-assurance-device" module to customize it for devices of the service-assurance-device" module to customize it for devices of the
fictional ACME Corporation. Additional vendor-specific parameters fictional Acme Corporation. Additional vendor-specific parameters
might be added following a similar approach. We also provide the might be added following a similar approach. We also provide the
modules "example-service-assurance-ip-connectivity" and "example- modules "example-service-assurance-ip-connectivity" and "example-
service-assurance-is-is" (Appendix B) to model the example in service-assurance-is-is" (Appendix B) to model the example in
Figure 2 from Section 3.1 of Figure 2 from Section 3.1 of [RFC9417].
[I-D.ietf-opsawg-service-assurance-architecture].
3. Base IETF Service Assurance YANG Module 3. Base IETF Service Assurance YANG Module
3.1. Concepts 3.1. Concepts
The "ietf-service-assurance" YANG module assumes a set of The "ietf-service-assurance" YANG module assumes a set of subservices
subservices, to be assured independently. A subservice is a feature to be assured independently. A subservice is a feature or a subpart
or a subpart of the network system that a given service instance of the network system that a given service instance depends on.
depends on. Examples of subservice types include: Examples of subservice types include the following:
* device: whether a device is healthy, and if not, what are the * device: Whether a device is healthy, and if not, what are the
symptoms. Such a subservice might monitor the device resources symptoms? Such a subservice might monitor the device resources,
such as CPU, RAM or Ternary Content-Addressable Memory (TCAM). such as CPU, RAM, or Ternary Content-Addressable Memory (TCAM).
Potential symptoms are "CPU overloaded", "Out of RAM", or "Out of Potential symptoms are "CPU overloaded", "Out of RAM", or "Out of
TCAM". TCAM".
* ip-connectivity: given two IP addresses bound to two devices, what * ip-connectivity: Given two IP addresses bound to two devices, what
is the quality of the IP connectivity between them. Potential is the quality of the IP connectivity between them? Potential
symptoms are "No route available" or "Equal Cost Multiple Paths symptoms are "No route available" or "Equal-Cost Multipaths
(ECMP) Imbalance". (ECMPs) imbalance".
An instance of the device subservice is representing a subpart of the An instance of the device subservice is representing a subpart of the
network system, namely a specific device. An instance of the ip- network system, namely a specific device. An instance of the ip-
connectivity subservice representing a feature of the network, namely connectivity subservice is representing a feature of the network,
the connectivity between two specific IP addresses on two devices. namely the connectivity between two specific IP addresses on two
In both cases, these subservices might depend on other subservices, devices. In both cases, these subservices might depend on other
for instance, the connectivity might depend on a subservice subservices, for instance, the connectivity might depend on a
representing the routing system and on a subservice representing subservice representing the routing system and on a subservice
ECMP. representing ECMPs.
The two example subservices presented above need different sets of The two example subservices presented above need different sets of
parameters to fully characterize one of their instance. An instance parameters to fully characterize one of their instances. An instance
of the device subservice is fully characterized by a single parameter of the device subservice is fully characterized by a single parameter
allowing to identify the device to monitor. For ip-connectivity allowing to identify the device to monitor. For the ip-connectivity
subservice, at least the device and IP address for both ends of the subservice, at least the device and IP address for both ends of the
link are needed to fully characterize an instance. link are needed to fully characterize an instance.
The base model presented in this section specifies a single type of The base model presented in this section specifies a single type of
subservice, which represents service instances. Such nodes play a subservice, which represents service instances. Such nodes play a
particular role in the assurance graph because they represent the particular role in the assurance graph because they represent the
starting point, or root, for the assurance graph of the corresponding starting point, or root, for the assurance graph of the corresponding
service instance. The parameters required to fully identify a service instance. The parameters required to fully identify a
service instance are the name of the service and the name of the service instance are the name of the service and the name of the
service instance. To support other types of subservice such as service instance. To support other types of subservices, such as
'device' or 'ip-connectivity', the "ietf-service-assurance" module is device or ip-connectivity, the "ietf-service-assurance" module is
intended to be augmented. intended to be augmented.
The dependencies are modelled as a list: each subservice contains a The dependencies are modeled as a list, i.e., each subservice
list of references to its dependencies. That list can be empty if contains a list of references to its dependencies. That list can be
the subservice instance does not have any dependencies. empty if the subservice instance does not have any dependencies.
By specifying service instances and their dependencies in terms of By specifying service instances and their dependencies in terms of
subservices, one defines a global assurance graph. That assurance subservices, one defines a global assurance graph. That assurance
graph is the result of merging all the individual assurance graphs graph is the result of merging all the individual assurance graphs
for the assured service instances. Each subservice instance is for the assured service instances. Each subservice instance is
expected to appear only one in the global assurance graph even if expected to appear only once in the global assurance graph even if
several service instances depend on it. For example, an instance of several service instances depend on it. For example, an instance of
the device subservice is a dependency of every service instance that the device subservice is a dependency of every service instance that
rely on the corresponding device. The assurance graph of a specific relies on the corresponding device. The assurance graph of a
service instance is the subgraph obtained by traversing the global specific service instance is the subgraph obtained by traversing the
assurance graph through the dependencies starting from the specific global assurance graph through the dependencies, starting from the
service instance. specific service instance.
An assurance agent configured with such a graph is expected to An assurance agent configured with such a graph is expected to
produce, for each configured subservice: a health-status indicating produce, for each configured subservice, a health status that
how healthy the subservice is and when the subservice is not healthy, indicates how healthy the subservice is. If the the subservice is
a list of symptoms explaining why the subservice is not healthy. not healthy, the agent is expected to produce a list of symptoms
explaining why the subservice is not healthy.
3.2. Tree View 3.2. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
"ietf-service-assurance" module. "ietf-service-assurance" module.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
| +--rw subservice* [type id] | +--rw subservice* [type id]
skipping to change at page 8, line 5 skipping to change at line 298
| +--ro description string | +--ro description string
+--ro assured-services +--ro assured-services
+--ro assured-service* [service] +--ro assured-service* [service]
+--ro service leafref +--ro service leafref
+--ro instances* [name] +--ro instances* [name]
+--ro name leafref +--ro name leafref
+--ro subservices* [type id] +--ro subservices* [type id]
+--ro type -> /subservices/subservice/type +--ro type -> /subservices/subservice/type
+--ro id leafref +--ro id leafref
The date of last change "assurance-graph-last-change" is read only. The date of the last change in "assurance-graph-last-change" is read
It must be updated each time the graph structure is changed by only. It must be updated each time the graph structure is changed by
addition or deletion of subservices, dependencies or modification of addition or deletion of subservices and dependencies or modifications
their configurable attributes, including their maintenance status. of their configurable attributes, including their maintenance
Such modifications correspond to a structural change in the graph. statuses. Such modifications correspond to a structural change in
The date of last change is useful for a client to quickly check if the graph. The date of the last change is useful for a client to
there is a need to update the graph structure. A change in the quickly check if there is a need to update the graph structure. A
health-score or symptoms associated to a service or subservice does change in the health score or symptoms associated to a service or
not change the structure of the graph and thus has no effect on the subservice does not change the structure of the graph, and thus has
date of last change. no effect on the date of the last change.
The "subservice" list contains all the subservice instances currently The "subservices" list contains all the subservice instances
known by the server (i.e. SAIN agent or SAIN collector). A currently known by the server (i.e., SAIN agent or SAIN collector).
subservice declaration MUST provide: A subservice declaration MUST provide the following:
* A subservice type ("type"): reference to an identity that inherits * a subservice type ("type"): a reference to an identity that
from "subservice-base", which is the base identity for any inherits from "subservice-base", which is the base identity for
subservice type. any subservice type
* An id ("id"): string uniquely identifying the subservice among * an id ("id"): a string uniquely identifying the subservice among
those with the same type, those with the same type
The type and id uniquely identify a given subservice. The type and id uniquely identify a given subservice.
The "last-change" indicates when the dependencies or maintenance The "last-change" indicates when the dependencies or maintenance
status of this particular subservice were last modified. status of this particular subservice were last modified.
The "label" is a human-readable description of the subservice. The "label" is a human-readable description of the subservice.
The presence of "under-maintenance" container inhibits the emission The presence of the "under-maintenance" container inhibits the
of symptoms for that subservice and subservices that depend on them. emission of symptoms for the subservice and subservices that depend
In that case, a "contact" MUST be provided to indicate who or which on them. In that case, a "contact" MUST be provided to indicate who
software is responsible for the maintenance. See Section 3.6 of or which software is responsible for the maintenance. See
[I-D.ietf-opsawg-service-assurance-architecture] for a more detailed Section 3.6 of [RFC9417] for a more detailed discussion.
discussion.
The "parameter" choice is intended to be augmented in order to The "parameter" choice is intended to be augmented in order to
describe parameters that are specific to the current subservice type. describe parameters that are specific to the current subservice type.
This base module defines only the subservice type representing This base module defines only the subservice type representing
service instances. Service instances MUST be modeled as a particular service instances. Service instances MUST be modeled as a particular
type of subservice with two parameters, "service" and "instance- type of subservice with two parameters: "service" and "instance-
name". The "service" parameter is the name of the service defined in name". The "service" parameter is the name of the service defined in
the network orchestrator, for instance "point-to-point-l2vpn". The the network orchestrator, for instance, "point-to-point-l2vpn". The
"instance-name" parameter is the name assigned to the particular "instance-name" parameter is the name assigned to the particular
instance to be assured, for instance the name of the customer using instance to be assured, for instance, the name of the customer using
that instance. that instance.
The "health-score" contains a value normally between 0 and 100 The "health-score" contains a value normally between 0 and 100,
indicating how healthy the subservice is. As mentioned in the indicating how healthy the subservice is. As mentioned in the health
health-score definition, the special value -1 can be used to specify score definition, the special value -1 can be used to specify that no
that no value could be computed for that health-score, for instance value could be computed for that health score, for instance, if some
if some metric needed for that computation could not be collected. metric needed for that computation could not be collected.
The "symptoms-history-start" is the cutoff date for reporting The "symptoms-history-start" is the cutoff date for reporting
symptoms. Symptoms that were terminated before that date are not symptoms. Symptoms that were terminated before that date are not
reported anymore in the model. reported anymore in the model.
The status of each subservice contains a list of symptoms. Each The status of each subservice contains a list of symptoms. Each
symptom is specified by symptom is specified by:
* an identifier "symptom-id" which identifies the symptom locally to * an identifier "symptom-id", which identifies the symptom locally
an agent, to an agent,
* an agent identifier "agent-id" which identifies the agent raising * an agent identifier "agent-id", which identifies the agent raising
the symptom, the symptom,
* a "health-score-weight" specifying the impact to the health score * a "health-score-weight" specifying the impact to the health score
incurred by this symptom, incurred by this symptom,
* a "start-date-time" indicating when the symptom became active and * a "start-date-time" indicating when the symptom became active, and
* a "stop-date-time" indicating when the symptom stopped being * a "stop-date-time" indicating when the symptom stopped being
active, that field is not present if the symptom is still active. active (this field is not present if the symptom is still active).
In order for the pair "agent-id" and "symptom-id" to uniquely In order for the pair "agent-id" and "symptom-id" to uniquely
identify a symptom, the following is necessary: identify a symptom, the following is necessary:
* The "agent-id" MUST be unique among all agents of the system * "agent-id" MUST be unique among all agents of the system.
* The "symptom-id" MUST be unique among all symptoms raised by the * "symptom-id" MUST be unique among all symptoms raised by the
agent agent.
Note that "agent-id" and "symptom-id" are leafrefs pointing to the Note that "agent-id" and "symptom-id" are leafrefs pointing to the
objects defined later in the document. While the combination of objects defined later in the document. While the combination of
"symptom-id" and "agent-id" is sufficient as a unique key list, the "symptom-id" and "agent-id" is sufficient as a unique key list, the
"start-date-time" second key helps to sort and retrieve relevant "start-date-time" second key helps to sort and retrieve relevant
symptoms. symptoms.
The "dependency" list contains the dependencies for the current The "dependency" list contains the dependencies for the current
subservice. Each of them is specified by a leafref to both "type" subservice. Each of them is specified by a leafref to both "type"
and "id" of the target dependencies. A dependency has a type and "id" of the target dependencies. A dependency has a type
indicated in the "dependency-type" field. Two types are specified in indicated in the "dependency-type" field. Two types are specified in
the model: the model:
* Impacting: such a dependency indicates an impact on the health of * Impacting: Such a dependency indicates an impact on the health of
the dependent, the dependent.
* Informational: such a dependency might explain why the dependent * Informational: Such a dependency might explain why the dependent
has issues but does not impact its health. has issues but does not impact its health.
To illustrate the difference between "impacting" and "informational", To illustrate the difference between "impacting" and "informational",
consider the interface subservice, representing a network interface. consider the interface subservice representing a network interface.
If the device to which the network interface belongs goes down, the If the device to which the network interface belongs goes down, the
network interface will transition to a "down" state as well. network interface will transition to a "down" state as well.
Therefore, the dependency of the interface subservice towards the Therefore, the dependency of the interface subservice towards the
device subservice is "impacting". On the other hand, a dependency device subservice is "impacting". On the other hand, a dependency
towards the ecmp-load subservice, which checks that the load between towards the ecmp-load subservice, which checks that the load between
ECMP remains stable throughout time, is only "informational". ECMPs remains stable throughout time, is only "informational".
Indeed, services might be perfectly healthy even if the load Indeed, services might be perfectly healthy even if the load
distribution between ECMP changed. However, such an instability distribution between ECMPs changed. However, such an instability
might be a relevant symptom for diagnosing the root cause of a might be a relevant symptom for diagnosing the root cause of a
problem. problem.
Within the container "agents", the list "agent" contains the list of Within the container "agents", the list "agent" contains the list of
symptoms per agent. The key of the list is the "id", which MUST be symptoms per agent. The key of the list is the "id", which MUST be
unique among agents of a given assurance system. For each agent, the unique among agents of a given assurance system. For each agent, the
list "symptoms-description" maps an "id" to its "description". The list "symptoms-description" maps an "id" to its "description". The
"id" MUST be unique among the symptoms raised by the agent. "id" MUST be unique among the symptoms raised by the agent.
Within the container "assured-services", the list "assured-service" Within the container "assured-services", the list "assured-service"
contains the subservices indexed by assured service instances. For contains the subservices indexed by assured service instances. For
each service type, identified by the "service" leaf, all instances of each service type identified by the "service" leaf, all instances of
that service are listed in the "instances" list. For each instance, that service are listed in the "instances" list. For each instance
identified by the "name" leaf, the "subservices" list contains all identified by the "name" leaf, the "subservices" list contains all
descendant subservices that are part of the assurance graph for that descendant subservices that are part of the assurance graph for that
specific instance. These imbricated lists provide a query specific instance. These imbricated lists provide a query
optimization to get the list of subservices in that assurance graph optimization to get the list of subservices in that assurance graph
in a single query, instead of recursively querying the dependencies in a single query instead of recursively querying the dependencies of
of each subservice, starting from the node representing the service each subservice, starting from the node representing the service
instance. instance.
The relation between the health score ("health-score") and the The relation between the health score ("health-score") and the
health-score-weight of the currently active symptoms is not "health-score-weight" of the currently active symptoms is not
explicitly defined in this document. The only requirement is that a explicitly defined in this document. The only requirement is that a
health score that is strictly smaller than 100 (the maximal value) health score that is strictly smaller than 100 (the maximal value)
must be explained by at least one symptom. A way to enforce that must be explained by at least one symptom. A way to enforce that
requirement is to first detect symptoms and then compute the health requirement is to first detect symptoms and then compute the health
score based on the health-score-weight of the detected symptoms. As score based on the "health-score-weight" of the detected symptoms.
an example, such a computation could be to sum the health-score- As an example, such a computation could be to sum the "health-score-
weight of the active symptoms, subtract that value from 100 and weight" of the active symptoms, subtract that value from 100, and
change the value to 0 if negative. The relation between health-score change the value to 0 if the result is negative. The relation
and health-score-weight is left to the implementor (of an agent between health score and "health-score-weight" is left to the
[I-D.ietf-opsawg-service-assurance-architecture]). implementor (of an agent [RFC9417]).
Keeping the history of the graph structure is out of scope for this 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 YANG module. Only the current version of the assurance graph can be
fetched. In order to keep the history of the graph structure, some fetched. In order to keep the history of the graph structure, some
time-series database (TSDB) or similar storage must be used. time-series database (TSDB) or similar storage must be used.
3.3. YANG Module 3.3. YANG Module
<CODE BEGINS> file "ietf-service-assurance@2022-08-10.yang" This model contains references to [RFC6991].
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 the SAIN
(Service Assurance for Intent-based Networking) architecture.
The subservices hierarchically organised by dependencies constitute <CODE BEGINS> file "ietf-service-assurance@2023-06-02.yang"
an assurance graph. This module should be supported by an assurance module ietf-service-assurance {
agent, able to interact with the devices in order to produce a yang-version 1.1;
health status and symptoms for each subservice in the assurance namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";
graph. prefix sain;
This module is intended for the following use cases: import ietf-yang-types {
* Assurance graph configuration: prefix yang;
- subservices: configure a set of subservices to assure, by reference
specifying their types and parameters. "RFC 6991: Common YANG Data Types";
- 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.
Copyright (c) 2022 IETF Trust and the persons identified as organization
authors of the code. All rights reserved. "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 the
Service Assurance for Intent-based Networking (SAIN)
architecture.
Redistribution and use in source and binary forms, with or The subservices hierarchically organized by dependencies
without modification, is permitted pursuant to, and subject constitute an assurance graph. This module should be supported
to the license terms contained in, the Revised BSD License by an assurance agent that is able to interact with the devices
set forth in Section 4.c of the IETF Trust's Legal Provisions in order to produce the health status and symptoms for each
Relating to IETF Documents subservice in the assurance graph.
(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-08-10 { This module is intended for the following use cases:
description * Assurance graph configuration:
"Initial version."; - Subservices: Configure a set of subservices to assure by
reference specifying their types and parameters.
"RFC xxxx: YANG Modules for Service Assurance"; - Dependencies: Configure the dependencies between the
} subservices, along with their type.
* Assurance telemetry: Export the health statuses of the
subservices, along with the observed symptoms.
identity subservice-base { Copyright (c) 2023 IETF Trust and the persons identified as
description authors of the code. All rights reserved.
"Base identity for subservice types.";
}
identity service-instance-type { Redistribution and use in source and binary forms, with or
base subservice-base; without modification, is permitted pursuant to, and subject
description to the license terms contained in, the Revised BSD License
"Specific type of subservice that represents a service set forth in Section 4.c of the IETF Trust's Legal Provisions
instance. Instance of this type will depend on other subservices Relating to IETF Documents
to build the top of the assurance graph."; (https://trustee.ietf.org/license-info).
}
identity dependency-type { This version of this YANG module is part of RFC 9418; see the
description RFC itself for full legal notices. ";
"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 { revision 2023-06-02 {
base dependency-type; description
description "Initial version.";
"Indicates that the status of the dependency directly impacts the reference
status of the dependent."; "RFC 9418: YANG Modules for Service Assurance";
} }
grouping subservice-reference { identity subservice-base {
description description
"Reference to a specific subservice, identified by its type and "Base identity for subservice types.";
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 { identity service-instance-type {
description base subservice-base;
"Represents a dependency to another subservice. This grouping description
is only for internal use in this module"; "Specific type of subservice that represents a service
uses subservice-reference; instance. Instance of this type will depend on other
leaf dependency-type { subservices to build the top of the assurance graph.";
type identityref { }
base dependency-type;
}
description
"Represents the type of dependency (e.g., informational,
impacting).";
} identity dependency-type {
} description
"Base identity for representing dependency types.";
}
leaf assurance-graph-last-change { identity informational {
type yang:date-and-time; base dependency-type;
config false; description
mandatory true; "Indicates that symptoms of the dependency might be of interest
description for the dependent, but the status of the dependency should not
"Time and date at which the assurance graph last changed after any have any impact on the dependent.";
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 the subservice, identifying the type of the part
or functionality that is being assured by this list entry.
For instance 'interface', 'device', '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 identity impacting {
network/system/software engineers that are able to interpret base dependency-type;
it. Therefore, no mechanism for language tagging is needed."; description
} "Indicates that the status of the dependency directly impacts
container under-maintenance { the status of the dependent.";
presence "true"; }
description
"The presence of this container indicates that the current
subservice is under 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 grouping subservice-reference {
URI, contains one or more of the following: IP address, description
management station name, network manager's name, location, "Reference to a specific subservice identified by its type and
or phone number. It might even contain the expected identifier. This grouping is only for internal use in this
maintenance time. 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.";
}
}
In some cases the agent itself will be the owner of an grouping subservice-dependency {
entry. In these cases, this string shall be set to a string description
starting with 'monitor'."; "Represents a dependency to another subservice. This grouping
} is only for internal use in this module";
} uses subservice-reference;
choice parameter { leaf dependency-type {
mandatory true; type identityref {
description base dependency-type;
"Specify the required parameters per subservice type. Each }
module augmenting this module with a new subservice type, description
that is a new identity based on subservice-base should "Represents the type of dependency (e.g., informational or
augment this choice as well, by adding a container impacting).";
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 into here
}
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 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
the health-score could not be computed.";
}
leaf symptoms-history-start {
type yang:date-and-time;
config false;
description
"Date and time at which the symptom’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 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";
} leaf assurance-graph-last-change {
description type yang:date-and-time;
"Identifier of the symptom, to be interpreted according config false;
to the agent identified by the agent-id."; mandatory true;
} description
leaf agent-id { "Time and date at which the assurance graph last changed after
type leafref { any structural changes (dependencies and/or maintenance
path "/agents/agent/id"; windows parameters) are applied to the subservice(s). The
} time and date must be the same or more recent than the most
description recent value of any changed subservices last-change time and
"Identifier of the agent raising the current symptom."; date.";
} }
leaf health-score-weight { container subservices {
type uint8 { description
range "0 .. 100"; "Root container for the subservices.";
} list subservice {
description key "type id";
"The weight to the health score incurred by this symptom. description
The higher the value, the more of an impact this symptom "List of configured subservices.";
has. If a subservice health score is not 100, there must leaf type {
be at least one symptom with a health score weight type identityref {
larger than 0."; base subservice-base;
} }
leaf start-date-time { description
type yang:date-and-time; "Type of the subservice identifying the type of the part
description or functionality that is being assured by this list
"Date and time at which the symptom was detected."; entry, for instance, interface, device, or
} ip-connectivity.";
leaf stop-date-time { }
type yang:date-and-time; leaf id {
description type string;
"Date and time at which the symptom stopped being description
detected. must be after the start-date-time. If the "Identifier of the subservice instance. Must be unique
symptom is ongoing, this field should not be populated."; among subservices of the same type.";
} }
} leaf last-change {
} type yang:date-and-time;
container dependencies { config false;
description description
"Indicates the set of dependencies of the current subservice, "Date and time at which the structure for this
along with their types."; subservice instance last changed, i.e., dependencies
list dependency { and/or maintenance windows parameters.";
key "type id"; }
description leaf label {
"List of dependencies of the subservice."; type string;
uses subservice-dependency; 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
container agents { interpret it. Therefore, no mechanism for language
config false; tagging is needed.";
description }
"Container for the list of agents’s symptoms"; container under-maintenance {
list agent { presence "true";
key "id"; description
description "The presence of this container indicates that the current
"Contains symptoms of each agent involved in computing the subservice is under maintenance.";
health status of the current graph. This list acts as a leaf contact {
glossary for understanding the symptom ids returned by each type string;
agent."; mandatory true;
leaf id { description
type string; "A string used to model an administratively assigned name
description of the resource that is performing maintenance.
"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 current agent, identified
by their 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, to be computer-consumable and be displayed on a
human interface.
It is not intended for random end users but for It is suggested that this freeform field, which could be
network/system/software engineers that are able to a URI, contains one or more of the following: IP
interpret it. Therefore, no mechanism for language tagging address, management station name, network manager's
is needed."; name, location, and/or phone number. It might even
} contain the expected maintenance time.
}
}
}
container assured-services {
config false;
description
"Container for the index of assured 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
/subservices 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/"
+ "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 In some cases, the agent itself will be the owner of an
service instance, that is the subservice that matches the entry. In these cases, this string shall be set to a
service and instance-name keys. string starting with 'monitor'.";
}
}
choice parameter {
mandatory true;
description
"Specify the required parameters per subservice type. Each
module augmenting this module with a new subservice type
that is a new identity based on subservice-base should
augment this choice as 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 into here.
}
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 the health score could not be computed.";
}
leaf symptoms-history-start {
type yang:date-and-time;
config false;
description
"Date and time at which the symptom'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 the 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 a
health-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. Must 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 of 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 current agent that is
identified by the 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 be computer consumable and
displayed on a human interface.
For every subservice in the list, all subservices listed as It is not intended for random end users but for
dependencies must also appear in the list."; network/system/software engineers that are able to
uses subservice-reference; interpret it. Therefore, no mechanism for language
tagging is needed.";
}
}
}
}
container assured-services {
config false;
description
"Container for the index of assured 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
subservices 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"
+ "/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, i.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;
}
}
}
}
}
<CODE ENDS> <CODE ENDS>
3.4. Rejecting Circular Dependencies 3.4. Rejecting Circular Dependencies
The statuses of services and subservices depend on the statuses of The statuses of services and subservices depend on the statuses of
their dependencies, and thus circular dependencies between them their dependencies, and thus circular dependencies between them
prevents the computation of statuses. The SAIN architecture document prevent the computation of statuses. Section 3.1.1 of the SAIN
[I-D.ietf-opsawg-service-assurance-architecture] discusses in architecture document [RFC9417] discusses how such dependencies
Section 3.1.1 how such dependencies appear and how they could be appear and how they could be removed. The responsibility of avoiding
removed. The responsibility of avoiding such dependencies falls to such dependencies falls to the SAIN orchestrator. However, we
the SAIN orchestrator. However, we specify in this section the specify in this section the expected behavior when a server
expected behavior when a server supporting the ietf-service-assurance supporting the "ietf-service-assurance" module receives a data
module receives a data instance containing circular dependencies. instance containing circular dependencies.
Enforcing the absence of circular dependencies as a YANG constraint Enforcing the absence of circular dependencies as a YANG constraint
falls back to implementing a graph traversal algorithm with XPath and falls back to implementing a graph traversal algorithm with XPath and
checking that the current node is not reachable from its checking that the current node is not reachable from its
dependencies. Even with such a constraint, there is no guarantee dependencies. Even with such a constraint, there is no guarantee
that merging two graphs without dependency loops will result in a that merging two graphs without dependency loops will result in a
graph without dependency loops. Indeed, the Section 3.1.1 of graph without dependency loops. Indeed, Section 3.1.1 of [RFC9417]
[I-D.ietf-opsawg-service-assurance-architecture] presents an example presents an example where merging two graphs without dependency loops
where merging two graphs without dependency loops results in a graph results in a graph with a dependency loop.
with a dependency loop.
Therefore, a server implementing the ietf-service-assurance module Therefore, a server implementing the "ietf-service-assurance" module
MUST check that there is no dependency loop whenever the graph is MUST check that there is no dependency loop whenever the graph is
modified. A modification creating a dependency loop MUST be modified. A modification creating a dependency loop MUST be
rejected. rejected.
4. Guidelines for Defining New Subservice Types 4. Guidelines for Defining New Subservice Types
The base YANG module defined in Section 3.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 type of subservice that represent service instances. As explained
above, this model is meant to be augmented so that a variety of 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 subservices can be used in the assurance graph. In this section, we
propose some guidelines for specifying such extensions at IETF. propose some guidelines for specifying such extensions at IETF.
The mechanism to add a new subservice type is to define a new module The mechanism to add a new subservice type is to define a new module
for that subservice. The module name should start with "ietf- for that subservice. The module name should start with "ietf-
service-assurance-". The namespace of the module should start with service-assurance-". The namespace of the module should start with
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-". The prefix of "urn:ietf:params:xml:ns:yang:ietf-service-assurance-". The prefix of
the module should start with "sain-". For instance, the subservice the module should start with "sain-". For instance, the subservice
type representing the assurance of a device should have: type representing the assurance of a device should have:
* the name "ietf-service-assurance-device", * the name "ietf-service-assurance-device",
* the namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance- * the namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-
device", device", and
* and the prefix "sain-device". * the prefix "sain-device".
The new module should define: The new module should define:
* A new identity to represent the new type. * a new identity to represent the new type and
* The parameters fully specifying an instance of the new subservice * the parameters fully specifying an instance of the new subservice
type. type.
The new identity should be based on the "subservice-base" identity. The new identity should be based on the "subservice-base" identity.
The name of the identity should end with "-type", for instance The name of the identity should end with "-type", for instance,
"device-type". "device-type".
The parameters should be defined in a container named "parameters" The parameters should be defined in a container named "parameters"
augmenting of the choice "/subservices/subservice/parameter" from the that augments the choice "/subservices/subservice/parameter" from the
main module. The augmentation should be restricted to cases where main module. The augmentation should be restricted to cases where
the type of the subservice matches the identity representing the new the type of the subservice matches the identity representing the new
service type. service type.
We define two subservice types in the next sections: the "device" We define two subservice types in the next sections: the "device"
subservice type is defined in Section 5 and the "interface" subservice type is defined in Section 5 and the "interface"
subservice type is defined is Section 6. These subservices can be subservice type is defined is Section 6. These subservices can be
taken as examples of the rules defined in this section. taken as examples of the rules defined in this section.
Vendors can specify their own subservices types by defining the Vendors can specify their own subservices types by defining the
corresponding modules in their own namespace. An example of such a corresponding modules in their own namespace. An example of such a
vendor-specific module is specified in Appendix Appendix A. Vendors vendor-specific module is specified in Appendix A. Vendors can also
can also augment existing IETF-specified subservices to add their own augment existing IETF-specified subservices to add their own vendor-
vendor-specific information. specific information.
5. Subservice Augmentation: ietf-service-assurance-device YANG module 5. Subservice Augmentation: "ietf-service-assurance-device" YANG Module
5.1. Tree View 5.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
"ietf-service-assurance-device" module. "ietf-service-assurance-device" module.
module: ietf-service-assurance-device module: ietf-service-assurance-device
augment /sain:subservices/sain:subservice/sain:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw device string +--rw device string
A complete tree view of the base module with all augmenting modules A complete tree view of the base module with all augmenting modules
presented in this draft is available in Appendix B.3. presented in this document is available in Appendix B.3.
5.2. Concepts 5.2. Concepts
As the number of subservices will grow over time, the YANG module is As the number of subservices will grow over time, the YANG module is
designed to be extensible. A new subservice type requires the designed to be extensible. A new subservice type requires the
precise specifications of its type and expected parameters. Let us precise specifications of its type and expected parameters. Let us
illustrate the example of the new device subservice type. As the illustrate the example of the new device subservice type. As the
name implies, it monitors and reports the device health, along with name implies, it monitors and reports the device health, along with
some symptoms in case of degradation. some symptoms in case of degradation.
For our device subservice definition, the new identity "device-type" For our device subservice definition, the new identity "device-type"
is specified, as an inheritance from the base identity for is specified as an inheritance from the base identity for
subservices. This indicates to the assurance agent that we are now subservices. This indicates to the assurance agent that we are now
assuring the health of a device. assuring the health of a device.
The typical parameter for the configuration of the device subservice The typical parameter for the configuration of the device subservice
is the name of the device that we want to assure. By augmenting the 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 parameter choice from the "ietf-service-assurance" YANG module for
of the "device-type" subservice type, this new parameter is the case of the "device-type" subservice type, this new parameter is
specified. specified.
5.3. YANG Module 5.3. YANG Module
<CODE BEGINS> file "ietf-service-assurance-device@2022-08-10.yang" <CODE BEGINS> file "ietf-service-assurance-device@2023-06-02.yang"
module ietf-service-assurance-device {
module ietf-service-assurance-device { yang-version 1.1;
yang-version 1.1; namespace
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device";
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; prefix sain-device;
prefix sain-device;
import ietf-service-assurance {
prefix sain;
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
organization import ietf-service-assurance {
"IETF OPSAWG Working Group"; prefix sain;
reference
"RFC 9418: YANG Modules for Service Assurance";
}
contact organization
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "IETF OPSAWG Working Group";
WG List: <mailto:opsawg@ietf.org> contact
Author: Benoit Claise <mailto:benoit.claise@huawei.com> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; WG List: <mailto:opsawg@ietf.org>
description Author: Benoit Claise <mailto:benoit.claise@huawei.com>
"This module augments the ietf-service-assurance module with support Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
of the device subservice. description
"This module augments the ietf-service-assurance module with
support of the device subservice.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised 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 set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (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-08-10 { This version of this YANG module is part of RFC 9418; see the
description RFC itself for full legal notices. ";
"Initial revision.";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
identity device-type { revision 2023-06-02 {
base sain:subservice-base; description
description "Initial revision.";
"Identity of device subservice."; reference
} "RFC 9418: YANG Modules for Service Assurance";
}
augment "/sain:subservices/sain:subservice/sain:parameter" { identity device-type {
when "derived-from-or-self(sain:type, 'device-type')"; base sain:subservice-base;
description description
"Augments the parameter choice from ietf-service-assurance "Identity of device subservice.";
module with a case specific to the device subservice."; }
container parameters {
description
"Parameters for the device subservice type";
leaf device {
type string;
mandatory true;
description
"Identifier of the device to monitor. The
identifier (e.g. device id, hostname, management IP)
depends on the context.";
}
}
}
}
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 subservice type.";
leaf device {
type string;
mandatory true;
description
"Identifier of the device to monitor. The
identifier (e.g., device id, hostname, or management IP)
depends on the context.";
}
}
}
}
<CODE ENDS> <CODE ENDS>
6. Subservice Augmentation: ietf-service-assurance-interface YANG 6. Subservice Augmentation: "ietf-service-assurance-interface" YANG
module Module
6.1. Tree View 6.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-interface data model. "ietf-service-assurance-interface" data model.
module: ietf-service-assurance-interface module: ietf-service-assurance-interface
augment /sain:subservices/sain:subservice/sain:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw device string +--rw device string
+--rw interface string +--rw interface string
A complete tree view of the base module with all augmenting modules A complete tree view of the base module with all augmenting modules
presented in this draft is available in Appendix B.3. presented in this document is available in Appendix B.3.
6.2. Concepts 6.2. Concepts
For the interface subservice definition, the new interface-type is For the interface subservice definition, the new interface-type is
specified, as an inheritance from the base identity for subservices. specified as an inheritance from the base identity for subservices.
This indicates to the assurance agent that we are now assuring the This indicates to the assurance agent that we are now assuring the
health of an interface. health of an interface.
The parameters for the configuration of the interface subservice are The parameters for the configuration of the interface subservice are
the name of the device and, on that specific device, a specific the name of the device and, on that specific device, a specific
interface. These parameters are aligned with the ietf-interfaces interface. These parameters are aligned with the "ietf-interfaces"
model described in [RFC8343] where the name of the interface is the model described in [RFC8343], where the name of the interface is the
only key needed to identify an interface on a given device. By only key needed to identify an interface on a given device. By
augmenting the parameter choice from ietf-service-assurance YANG augmenting the parameter choice from the "ietf-service-assurance"
module for the case of the interface-type subservice type, those two YANG module for the case of the interface-type subservice type, those
new parameters are specified. two new parameters are specified.
6.3. YANG Module 6.3. YANG Module
<CODE BEGINS> file "ietf-service-assurance-interface@2022-08-10.yang" <CODE BEGINS> file "ietf-service-assurance-interface@2023-06-02.yang"
module ietf-service-assurance-interface { module ietf-service-assurance-interface {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface";
prefix sain-interface; prefix sain-interface;
import ietf-service-assurance { import ietf-service-assurance {
prefix sain; prefix sain;
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC 9418: YANG Modules for Service Assurance";
} }
organization organization
"IETF OPSAWG Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description description
"This module extends the ietf-service-assurance module to add "This module extends the ietf-service-assurance module to add
support for the interface subservice. support for the interface subservice.
Checks whether an interface is healthy. It checks whether an interface is healthy.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised 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 set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9418; see the
RFC itself for full legal notices. "; RFC itself for full legal notices. ";
revision 2022-08-10 { revision 2023-06-02 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC 9418: YANG Modules for Service Assurance";
} }
identity interface-type { identity interface-type {
base sain:subservice-base; base sain:subservice-base;
description description
"Checks whether an interface is healthy."; "Checks whether an interface is healthy.";
} }
augment "/sain:subservices/sain:subservice/sain:parameter" { augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'interface-type')"; when "derived-from-or-self(sain:type, 'interface-type')";
description description
"Augments the parameter choice from ietf-service-assurance "Augments the parameter choice from ietf-service-assurance
module with a case specific to the interface subservice."; module with a case specific to the interface subservice.";
container parameters { container parameters {
description description
"Parameters for the interface subservice type."; "Parameters for the interface subservice type.";
skipping to change at page 26, line 30 skipping to change at line 1172
} }
leaf interface { leaf interface {
type string; type string;
mandatory true; mandatory true;
description description
"Name of the interface."; "Name of the interface.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. Security Considerations 7. Security Considerations
The YANG module specified in this document defines a schema for data The YANG modules specified in this document define schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446]. [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in these YANG modules that
writable/ creatable/deletable (i.e., config true, which is the are writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
* /subservices/subservice : By modifying this subtree, one can * /subservices/subservice : By modifying this subtree, one can
modify the structure of the assurance graph which could alter the modify the structure of the assurance graph, which could alter the
status of the services reported by the assurance framework. On status of the services reported by the assurance framework. On
one hand, modifications can cause the assurance system to report a one hand, modifications can cause the assurance system to report a
service as broken when it is actually healthy (false positive), service as broken when it is actually healthy (false positive),
resulting in engineers or automation software losing time, and resulting in engineers or automation software losing time and
potentially cause real issues by doing unnecessary modifications potentially causing real issues by doing unnecessary modifications
on the network. On the other hand, modifications could prevent on the network. On the other hand, modifications could prevent
the assurance system to report actual issues (false negative), the assurance system from reporting actual issues (false
resulting in failures that could have been avoided. Depending on negative), resulting in failures that could have been avoided.
the service, the impact of these avoidable failures could be SLA Depending on the service, the impact of these avoidable failures
violations fees or disruption of emergency calls. could be Service-Level Agreement (SLA) violations fees or
disruption of emergency calls.
Some readable data nodes in this YANG module may be considered Some readable data nodes in these YANG modules may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
* /subservices/subservice * /subservices/subservice
* /agents/agent * /agents/agent
* /assured-services/assured-service * /assured-services/assured-service
Each of these subtrees contains information about services, Each of these subtrees contains information about services,
subservices or possible symptoms raised by the agents. The subservices, or possible symptoms raised by the agents. The
information contained in this subtree might give information about information contained in this subtree might give information about
the underlying network as well as services deployed for the the underlying network as well as services deployed for the
customers. For instance, a customer might be given access to monitor customers. For instance, a customer might be given access to monitor
their services status (e.g. via model-driven telemetry). In that their services status (e.g., via model-driven telemetry). In that
example, the customer access should be restricted to nodes example, the customer access should be restricted to nodes
representing their services, so as not to divulge information about representing their services so as not to divulge information about
the underlying network structure or others customers services. the underlying network structure or others customers services.
8. IANA Considerations 8. IANA Considerations
8.1. The IETF XML Registry 8.1. The IETF XML Registry
This document registers 3 URIs in the IETF XML registry [RFC3688]. IANA has registered the following three URIs in the "IETF XML
Following the format in [RFC3688], the following registrations are Registry" [RFC3688]:
requested:
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance
Registrant Contact: The OPSAWG WG of the IETF. Registrant Contact: The OPSAWG WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
Registrant Contact: The OPSAWG WG of the IETF. Registrant Contact: The OPSAWG WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
Registrant Contact: The OPSAWG WG of the IETF. Registrant Contact: The OPSAWG WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
8.2. The YANG Module Names Registry 8.2. The YANG Module Names Registry
This document registers three YANG modules in the YANG Module Names IANA has registered the following three YANG modules in the "YANG
registry [RFC7950]. Following the format in [RFC7950], the following Module Names" registry [RFC7950]:
registrations are requested:
name: ietf-service-assurance name: ietf-service-assurance
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance
prefix: sain prefix: sain
reference: RFC XXXX reference: RFC 9418
name: ietf-service-assurance-device name: ietf-service-assurance-device
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
prefix: sain-device prefix: sain-device
reference: RFC XXXX reference: RFC 9418
name: ietf-service-assurance-interface name: ietf-service-assurance-interface
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-
prefix: sain-interface interface
reference: RFC XXXX prefix: sain-interface
reference: RFC 9418
All these modules are not maintained by IANA. These modules are not maintained by IANA.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-opsawg-service-assurance-architecture] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Claise, B., Quilbeuf, J., Lopez, D. R., Voyer, D., and T. Requirement Levels", BCP 14, RFC 2119,
Arumugam, "Service Assurance for Intent-based Networking
Architecture", Work in Progress, Internet-Draft, draft-
ietf-opsawg-service-assurance-architecture-13, 3 January
2023, <https://datatracker.ietf.org/api/v1/doc/document/
draft-ietf-opsawg-service-assurance-architecture/>.
[RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M. and RFC Publisher, "The IETF XML Registry", [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Bierman, A., Ed., and RFC Publisher, "Network and A. Bierman, Ed., "Network Configuration Protocol
Configuration Protocol (NETCONF)", RFC 6241, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M. and RFC Publisher, "Using the NETCONF [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Protocol over Secure Shell (SSH)", RFC 6242, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed. and RFC Publisher, "Common YANG [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed. and RFC Publisher, "The YANG 1.1 Data [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August RFC 7950, DOI 10.17487/RFC7950, August 2016,
2016, <https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., Watsen, K., and RFC Publisher, [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
"RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
January 2017, <https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
DOI 10.17487/RFC8174, May 2017, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A., Bjorklund, M., and RFC Publisher, "Network [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Configuration Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
Wilton, R., and RFC Publisher, "Network Management and R. Wilton, "Network Management Datastore Architecture
Datastore Architecture (NMDA)", RFC 8342, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E. and RFC Publisher, "The Transport Layer [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Security (TLS) Protocol Version 1.3", RFC 8446, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
Arumugam, "Service Assurance for Intent-Based Networking
Architecture", RFC 9417, DOI 10.17487/RFC9417, June 2023,
<https://www.rfc-editor.org/info/rfc9417>.
9.2. Informative References 9.2. Informative References
[RFC8340] Bjorklund, M., Berger, L., Ed., and RFC Publisher, "YANG [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
March 2018, <https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8343] Bjorklund, M. and RFC Publisher, "A YANG Data Model for [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Interface Management", RFC 8343, DOI 10.17487/RFC8343, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
March 2018, <https://www.rfc-editor.org/info/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
Wilton, R., and RFC Publisher, "YANG Library", RFC 8525, and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019, DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>. <https://www.rfc-editor.org/info/rfc8525>.
Appendix A. Vendor-specific Subservice Augmentation: example-service- Appendix A. Vendor-Specific Subservice Augmentation: "example-service-
assurance-device-acme YANG module assurance-device-acme" YANG Module
A.1. Tree View A.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
"example-service-assurance-device-acme" module. "example-service-assurance-device-acme" module.
module: example-service-assurance-device-acme module: example-service-assurance-device-acme
augment /sain:subservices/sain:subservice/sain:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw device string +--rw device string
+--rw acme-specific-parameter string +--rw acme-specific-parameter string
A complete tree view of the base module with all augmenting modules A complete tree view of the base module with all augmenting modules
presented in this draft is available in Appendix B.3. presented in this document is available in Appendix B.3.
A.2. Concepts A.2. Concepts
Under some circumstances, vendor-specific subservice types might be Under some circumstances, vendor-specific subservice types might be
required. As an example of this vendor-specific implementation, this required. As an example of this vendor-specific implementation, this
section shows how to augment the "ietf-service-assurance-device" section shows how to augment the "ietf-service-assurance-device"
module to add custom support for the device subservice, specific to module to add custom support for the device subservice specific to
the ACME Corporation. The specific version adds a new parameter, the Acme Corporation. The specific version adds a new parameter
named "acme-specific-parameter". It's an implementation choice to named "acme-specific-parameter". It's an implementation choice to
either derive a new specific identity from the "subservice-base" either derive a new specific identity from the "subservice-base"
identity defined in ietf-service-assurance or to augment the identity defined in the "ietf-service-assurance" module or to augment
parameters from ietf-service-assurance-device, here we choose to the parameters from the "ietf-service-assurance-device" module; here,
create a new identity. we choose to create a new identity.
A.3. YANG Module A.3. YANG Module
module example-service-assurance-device-acme { module example-service-assurance-device-acme {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:example-service-assurance-device-acme"; namespace "urn:example:example-service-assurance-device-acme";
prefix example-device-acme; prefix example-device-acme;
import ietf-service-assurance {
prefix sain;
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
import ietf-service-assurance-device {
prefix sain-device;
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
organization import ietf-service-assurance {
"IETF OPSAWG Working Group"; prefix sain;
contact reference
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "RFC 9418: YANG Modules for Service Assurance";
WG List: <mailto:opsawg@ietf.org> }
Author: Benoit Claise <mailto:benoit.claise@huawei.com> import ietf-service-assurance-device {
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; prefix sain-device;
description reference
"This example module extends the ietf-service-assurance-device "RFC 9418: YANG Modules for Service Assurance";
module to add specific support for devices of ACME Corporation. "; }
revision 2022-08-10 { 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 description
"Initial revision"; "This example module extends the ietf-service-assurance-device
reference module to add specific support for devices of the Acme
"RFC xxxx: YANG Modules for Service Assurance"; Corporation. ";
}
identity device-acme-type { revision 2023-06-02 {
base sain-device:device-type; description
description "Initial revision.";
"Network Device is healthy."; reference
} "RFC 9418: YANG Modules for Service Assurance";
}
augment "/sain:subservices/sain:subservice/sain:parameter" { identity device-acme-type {
when "derived-from-or-self(sain:type, 'device-acme-type')"; base sain-device:device-type;
description
"Augments the parameter choice from ietf-service-assurance
module with a case specific to the device-acme subservice.";
container parameters {
description description
"Parameters for the device-acme subservice type"; "Network device is healthy.";
leaf device { }
type string;
mandatory true; augment "/sain:subservices/sain:subservice/sain:parameter" {
description when "derived-from-or-self(sain:type, 'device-acme-type')";
"The device to monitor."; description
} "Augments the parameter choice from the ietf-service-assurance
leaf acme-specific-parameter { module with a case specific to the device-acme subservice.";
type string; container parameters {
mandatory true;
description description
"The ACME Corporation specific parameter."; "Parameters for the device-acme 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-specific parameter.";
}
} }
} }
} }
}
Appendix B. Further Augmentations: IP Connectivity and IS-IS Appendix B. Further Augmentations: IP Connectivity and IS-IS
subservices Subservices
In this section, we provide two additional YANG modules to completely In this section, we provide two additional YANG modules to completely
cover the example in Figure 2 from Section 3.1 of cover the example in Figure 2 from Section 3.1 of [RFC9417]. The two
[I-D.ietf-opsawg-service-assurance-architecture]. The two missing missing subservice types are IP connectivity and the Intermediate
subservice types are IP Connectivity and the Intermediate System to System to Intermediate System (IS-IS) routing protocol. These
Intermediate System (IS-IS) routing protocol. These modules are modules are presented as examples; some future work is needed to
presented as examples, some future work is needed to propose a more propose a more complete version.
complete version.
B.1. IP Connectivity Module Tree View B.1. IP Connectivity Module Tree View
That subservice represents the unicast connectivity between two IP That subservice represents the unicast connectivity between two IP
addresses located on two different devices. Such a subservice could addresses located on two different devices. Such a subservice could
report symptoms such as "No route found". The following tree diagram report symptoms such as "No route found". The following tree diagram
[RFC8340] provides an overview of the "example-service-assurance-ip- [RFC8340] provides an overview of the "example-service-assurance-ip-
connectivity" module. connectivity" module.
module: example-service-assurance-ip-connectivity module: example-service-assurance-ip-connectivity
skipping to change at page 33, line 38 skipping to change at line 1496
+--rw instance-name string +--rw instance-name string
The parameter of this subservice is the name of the IS-IS instance to The parameter of this subservice is the name of the IS-IS instance to
assure. assure.
B.3. Global Tree View B.3. Global Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
"ietf-service-assurance", "ietf-service-assurance-device", "example- "ietf-service-assurance", "ietf-service-assurance-device", "example-
service-assurance-device-acme", "example-service-assurance-ip- service-assurance-device-acme", "example-service-assurance-ip-
connectivity" and "example-service-assurance-is-is" modules. connectivity", and "example-service-assurance-is-is" modules.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
| +--rw subservice* [type id] | +--rw subservice* [type id]
| +--rw type identityref | +--rw type identityref
| +--rw id string | +--rw id string
| +--ro last-change? | +--ro last-change?
| | yang:date-and-time | | yang:date-and-time
| +--ro label? string | +--ro label? string
skipping to change at page 35, line 18 skipping to change at line 1571
+--ro assured-service* [service] +--ro assured-service* [service]
+--ro service leafref +--ro service leafref
+--ro instances* [name] +--ro instances* [name]
+--ro name leafref +--ro name leafref
+--ro subservices* [type id] +--ro subservices* [type id]
+--ro type -> /subservices/subservice/type +--ro type -> /subservices/subservice/type
+--ro id leafref +--ro id leafref
B.4. IP Connectivity YANG Module B.4. IP Connectivity YANG Module
module example-service-assurance-ip-connectivity { module example-service-assurance-ip-connectivity {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:example-service-assurance-ip-connectivity"; namespace "urn:example:example-service-assurance-ip-connectivity";
prefix example-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
"RFC xxxx: YANG Modules for Service Assurance";
}
organization import ietf-inet-types {
"IETF OPSAWG Working Group"; prefix inet;
contact reference
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "RFC 6991: Common YANG Data Types";
WG List: <mailto:opsawg@ietf.org> }
Author: Benoit Claise <mailto:benoit.claise@huawei.com> import ietf-service-assurance {
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; prefix sain;
description reference
"This example module augments the ietf-service-assurance module to "RFC 9418: YANG Modules for Service Assurance";
add support for the subservice ip-connectivity. }
Checks whether the ip connectivity between two ip addresses organization
belonging to two network devices is healthy."; "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.
revision 2022-08-10 { It checks whether the IP connectivity between two IP addresses
description belonging to two network devices is healthy.";
"Initial version";
reference revision 2023-06-02 {
"RFC xxxx: YANG Modules for Service Assurance"; description
} "Initial version.";
reference
"RFC 9418: YANG Modules for Service Assurance";
}
identity ip-connectivity-type { identity ip-connectivity-type {
base sain:subservice-base; base sain:subservice-base;
description description
"Checks connectivity between two IP addresses."; "Checks connectivity between two IP addresses.";
} }
augment "/sain:subservices/sain:subservice/sain:parameter" { augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'ip-connectivity-type')"; when "derived-from-or-self(sain:type, 'ip-connectivity-type')";
description description
"Augments the parameter choice from ietf-service-assurance "Augments the parameter choice from the ietf-service-assurance
module with a case specific to the ip-connectivity module with a case specific to the ip-connectivity
subservice."; subservice.";
container parameters { container parameters {
description description
"Parameters for the ip-connectivity subservice type"; "Parameters for the ip-connectivity subservice type.";
leaf device1 { leaf device1 {
type string; type string;
mandatory true; mandatory true;
description description
"Device at the first end of the connection."; "Device at the first end of the connection.";
} }
leaf address1 { leaf address1 {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"Address at the first end of the connection."; "Address at the first end of the connection.";
} }
leaf device2 { leaf device2 {
type string; type string;
mandatory true; mandatory true;
description description
"Device at the second end of the connection."; "Device at the second end of the connection.";
} }
leaf address2 { leaf address2 {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"Address at the second end of the connection."; "Address at the second end of the connection.";
} }
} }
} }
} }
B.5. IS-IS YANG Module B.5. IS-IS YANG Module
module example-service-assurance-is-is { module example-service-assurance-is-is {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:example-service-assurance-is-is"; namespace "urn:example:example-service-assurance-is-is";
prefix example-is-is; prefix example-is-is;
import ietf-service-assurance { import ietf-service-assurance {
prefix sain; prefix sain;
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC 9418: YANG Modules for Service Assurance";
} }
organization organization
"IETF OPSAWG Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description description
"This example module augments the ietf-service-assurance module to "This example module augments the ietf-service-assurance module
add support for the subservice is-is. to add support for the subservice is-is.
Checks whether an IS-IS instance is healthy."; It checks whether an IS-IS instance is healthy.";
revision 2022-08-10 { revision 2023-06-02 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC 9418: YANG Modules for Service Assurance";
} }
identity is-is-type { identity is-is-type {
base sain:subservice-base; base sain:subservice-base;
description description
"Health of IS-IS routing protocol."; "Health of IS-IS routing protocol.";
} }
augment "/sain:subservices/sain:subservice/sain:parameter" { augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'is-is-type')"; when "derived-from-or-self(sain:type, 'is-is-type')";
description description
"Augments the parameter choice from ietf-service-assurance "Augments the parameter choice from the ietf-service-assurance
module with a case specific to the is-is subservice."; module with a case specific to the is-is subservice.";
container parameters { container parameters {
description description
"Parameters for the is-is subservice type."; "Parameters for the is-is subservice type.";
leaf instance-name { leaf instance-name {
type string; type string;
mandatory true; mandatory true;
description description
"The instance to monitor."; "The instance to monitor.";
} }
} }
} }
} }
Appendix C. Example of YANG instance Appendix C. Example of a YANG Instance
This section contains an example of YANG instance that conform to the This section contains an example of a YANG instance that conforms to
YANG modules. The validity of this data instance has been checked the YANG modules. The validity of this data instance has been
using yangson (https://yangson.labs.nic.cz/). Yangson requires a checked using yangson <https://yangson.labs.nic.cz/>. Yangson
YANG library [RFC8525] to define the complete model against which the requires a YANG library [RFC8525] to define the complete model
data instance must be validated. We provide in Appendix D the JSON against which the data instance must be validated. In Appendix D, we
library file, named "ietf-service-assurance-library.json", that we provide the JSON library file named "ietf-service-assurance-
used for validation. library.json", which we used for validation.
We provide below the contents of the file Below, we provide the contents of the file
"example_configuration_instance.json" which contains the "example_configuration_instance.json", which contains the
configuration data that models the Figure 2 from Section 3.1 of configuration data that models Figure 2 from Section 3.1 of
[I-D.ietf-opsawg-service-assurance-architecture]. The instance can [RFC9417]. The instance can be validated with yangson by using the
be validated with yangson by using the invocation "yangson -v invocation "yangson -v example_configuration_instance.json ietf-
example_configuration_instance.json ietf-service-assurance- service-assurance-library.json", assuming all the files (YANG and
library.json", assuming all the files (YANG and JSON) defined in this JSON) defined in this document reside in the current folder.
draft reside in the current folder.
{ {
"ietf-service-assurance:subservices": { "ietf-service-assurance:subservices": {
"subservice": [ "subservice": [
{ {
"type": "service-instance-type", "type": "service-instance-type",
"id": "simple-tunnel/example", "id": "simple-tunnel/example",
"service-instance-parameter": { "service-instance-parameter": {
"service": "simple-tunnel", "service": "simple-tunnel",
"instance-name": "example" "instance-name": "example"
}, },
"dependencies": { "dependencies": {
"dependency": [ "dependency": [
{ {
"type": "ietf-service-assurance-interface:interface-type", "type":
"id": "interface/peer1/tunnel0", "ietf-service-assurance-interface:interface-type",
"dependency-type": "impacting" "id": "interface/peer1/tunnel0",
}, "dependency-type": "impacting"
{ },
"type": "ietf-service-assurance-interface:interface-type", {
"id": "interface/peer2/tunnel9", "type":
"dependency-type": "impacting" "ietf-service-assurance-interface:interface-type",
}, "id": "interface/peer2/tunnel9",
{ "dependency-type": "impacting"
"type": },
{
"type":
"example-service-assurance-ip-connectivity:ip-connectivity-type", "example-service-assurance-ip-connectivity:ip-connectivity-type",
"id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", "id":
"dependency-type": "impacting" "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
} "dependency-type": "impacting"
] }
} ]
}, }
{ },
"type": {
"type":
"example-service-assurance-ip-connectivity:ip-connectivity-type", "example-service-assurance-ip-connectivity:ip-connectivity-type",
"id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
"example-service-assurance-ip-connectivity:parameters": { "example-service-assurance-ip-connectivity:parameters": {
"device1": "Peer1", "device1": "Peer1",
"address1": "2001:db8::1", "address1": "2001:db8::1",
"device2": "Peer2", "device2": "Peer2",
"address2": "2001:db8::2" "address2": "2001:db8::2"
}, },
"dependencies": { "dependencies": {
"dependency": [ "dependency": [
{ {
"type": "ietf-service-assurance-interface:interface-type", "type":
"id": "interface/peer1/physical0", "ietf-service-assurance-interface:interface-type",
"dependency-type": "impacting" "id": "interface/peer1/physical0",
}, "dependency-type": "impacting"
{ },
"type": "ietf-service-assurance-interface:interface-type", {
"id": "interface/peer2/physical5", "type":
"dependency-type": "impacting" "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",
] "dependency-type": "impacting"
} }
}, ]
{ }
"type": "example-service-assurance-is-is:is-is-type", },
"id": "is-is/instance1", {
"example-service-assurance-is-is:parameters": { "type": "example-service-assurance-is-is:is-is-type",
"instance-name": "instance1" "id": "is-is/instance1",
} "example-service-assurance-is-is:parameters": {
"instance-name": "instance1"
}, }
{ },
"type": "ietf-service-assurance-interface:interface-type", {
"id": "interface/peer1/tunnel0", "type": "ietf-service-assurance-interface:interface-type",
"ietf-service-assurance-interface:parameters": { "id": "interface/peer1/tunnel0",
"device": "Peer1", "ietf-service-assurance-interface:parameters": {
"interface": "tunnel0" "device": "Peer1",
}, "interface": "tunnel0"
"dependencies": { },
"dependency": [ "dependencies": {
{ "dependency": [
"type": "ietf-service-assurance-interface:interface-type", {
"id": "interface/peer1/physical0", "type":
"dependency-type": "impacting" "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": { "type": "ietf-service-assurance-interface:interface-type",
"device": "Peer1", "id": "interface/peer1/physical0",
"interface": "physical0" "ietf-service-assurance-interface:parameters": {
}, "device": "Peer1",
"dependencies": { "interface": "physical0"
"dependency": [ },
{ "dependencies": {
"type": "ietf-service-assurance-device:device-type", "dependency": [
"id": "interface/peer1", {
"dependency-type": "impacting" "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": { "type": "ietf-service-assurance-device:device-type",
"device": "Peer1" "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": { "type": "ietf-service-assurance-interface:interface-type",
"device": "Peer2", "id": "interface/peer2/tunnel9",
"interface": "tunnel9" "ietf-service-assurance-interface:parameters": {
"device": "Peer2",
}, "interface": "tunnel9"
"dependencies": { },
"dependency": [ "dependencies": {
{ "dependency": [
"type": "ietf-service-assurance-interface:interface-type", {
"id": "interface/peer2/physical5", "type":
"dependency-type": "impacting" "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": { "type": "ietf-service-assurance-interface:interface-type",
"device": "Peer2", "id": "interface/peer2/physical5",
"interface": "physical5" "ietf-service-assurance-interface:parameters": {
}, "device": "Peer2",
"dependencies": { "interface": "physical5"
"dependency": [ },
{ "dependencies": {
"type": "ietf-service-assurance-device:device-type", "dependency": [
"id": "interface/peer2", {
"dependency-type": "impacting" "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": { "type": "ietf-service-assurance-device:device-type",
"device": "Peer2" "id": "interface/peer2",
} "ietf-service-assurance-device:parameters": {
} "device": "Peer2"
] }
} }
} ]
}
}
Appendix D. YANG Library for Service Assurance Appendix D. YANG Library for Service Assurance
This section provides the JSON encoding of the YANG library [RFC8525] This section provides the JSON encoding of the YANG library [RFC8525]
listing all modules defined in this draft and their dependencies. that lists all modules defined in this document and their
This library can be used to validate data instances using yangson, as dependencies. This library can be used to validate data instances
explained in the previous section. using yangson, as explained in the previous section.
{ {
"ietf-yang-library:modules-state": { "ietf-yang-library:modules-state": {
"module-set-id": "ietf-service-assurance@2022-08-10", "module-set-id": "ietf-service-assurance@2023-06-02",
"module": [ "module": [
{ {
"name": "ietf-service-assurance", "name": "ietf-service-assurance",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-service-assurance", "urn:ietf:params:xml:ns:yang:ietf-service-assurance",
"revision": "2022-08-10", "revision": "2023-06-02",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-service-assurance-device", "name": "ietf-service-assurance-device",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device",
"revision": "2022-08-10", "revision": "2023-06-02",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-service-assurance-interface", "name": "ietf-service-assurance-interface",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface",
"revision": "2022-08-10", "revision": "2023-06-02",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "example-service-assurance-device-acme", "name": "example-service-assurance-device-acme",
"namespace": "namespace":
"urn:example:example-service-assurance-device-acme", "urn:example:example-service-assurance-device-acme",
"revision": "2022-08-10", "revision": "2023-06-02",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "example-service-assurance-is-is", "name": "example-service-assurance-is-is",
"namespace": "urn:example:example-service-assurance-is-is", "namespace": "urn:example:example-service-assurance-is-is",
"revision": "2022-08-10", "revision": "2023-06-02",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "example-service-assurance-ip-connectivity", "name": "example-service-assurance-ip-connectivity",
"namespace": "namespace":
"urn:example:example-service-assurance-ip-connectivity", "urn:example:example-service-assurance-ip-connectivity",
"revision": "2022-08-10", "revision": "2023-06-02",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-yang-types", "name": "ietf-yang-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"revision": "2021-04-14", "revision": "2013-07-05",
"conformance-type": "import" "conformance-type": "import"
}, },
{ {
"name": "ietf-inet-types", "name": "ietf-inet-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"revision": "2021-02-22", "revision": "2013-07-05",
"conformance-type": "import" "conformance-type": "import"
} }
] ]
} }
} }
Appendix E. Changes between revisions
[[RFC editor: please remove this section before publication.]]
v09 - v10
* Address comments from Last Call
v07 - v08
* Address comments from Rob Wilton's AD review
v06 - v07
* Addressed early YANG doctor comments from version -06: changed
-idty for -type or -base in identity names and removed "under-
maintenance" leaf
* Add new list of services with the corresponding subservices
* Remove assurance-graph-version and state the limitations of having
only the current graph available in the module.
* Added new list of agents to store symptom and guarantee unicity of
symptom ids
* Added security consideration for readable nodes
* Added section on rejecting circular dependencies
v05 - v06
* Remove revision history in modules
* Present elements in order of the tree for the main module
* Rewriting and rewording for clarity
* Made parameters mandatory for the subservices
v04 - v05
* Remove Guidelines section
* Move informative parts (examples) to appendix
* Minor text edits and reformulations
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
computed (value -1)
v00 - v01
* Added needed subservice to model example from architecture draft
* Added guideline section for naming models
* Added data instance examples and validation procedure
* Added the "parameters" container in the interface YANG module to
correct a bug.
Acknowledgements Acknowledgements
The authors would like to thank Jan Lindblad for his help during the The authors would like to thank Jan Lindblad for his help during the
design of these YANG modules. The authors would like to thank design of these YANG modules. The authors would like to thank
Stephane Litkowski, Charles Eckel, Mohamed Boucadair, Tom Petch, Stephane Litkowski, Charles Eckel, Mohamed Boucadair, Tom Petch,
Dhruv Dhody and Rob Wilton for their reviews. Dhruv Dhody, and Rob Wilton for their reviews.
Authors' Addresses Authors' Addresses
Benoit Claise Benoit Claise
Huawei Huawei
Email: benoit.claise@huawei.com Email: benoit.claise@huawei.com
Jean Quilbeuf Jean Quilbeuf
Huawei Huawei
Email: jean.quilbeuf@huawei.com Email: jean.quilbeuf@huawei.com
skipping to change at page 45, line 37 skipping to change at line 1987
Email: paolo@ntt.net Email: paolo@ntt.net
Paolo Fasano Paolo Fasano
TIM S.p.A TIM S.p.A
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
10148 Torino 10148 Torino
Italy Italy
Email: paolo2.fasano@telecomitalia.it Email: paolo2.fasano@telecomitalia.it
Thangam Arumugam Thangam Arumugam
Cisco Systems, Inc. Consultant
Milpitas (California), Milpitas, California
United States United States of America
Email: tarumuga@cisco.com Email: thangavelu@yahoo.com
 End of changes. 201 change blocks. 
1295 lines changed or deleted 1204 lines changed or added

This html diff was produced by rfcdiff 1.48.