draft-ietf-opsawg-service-assurance-yang-03.txt   draft-ietf-opsawg-service-assurance-yang-04.txt 
OPSAWG B. Claise OPSAWG B. Claise
Internet-Draft J. Quilbeuf Internet-Draft J. Quilbeuf
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: 26 September 2022 P. Lucente Expires: 27 October 2022 P. Lucente
NTT NTT
P. Fasano P. Fasano
TIM S.p.A TIM S.p.A
T. Arumugam T. Arumugam
Cisco Systems, Inc. Cisco Systems, Inc.
25 March 2022 25 April 2022
YANG Modules for Service Assurance YANG Modules for Service Assurance
draft-ietf-opsawg-service-assurance-yang-03 draft-ietf-opsawg-service-assurance-yang-04
Abstract Abstract
This document proposes YANG modules for the Service Assurance for This document specifies YANG modules representing assurance graphs.
Intent-based Networking Architecture. These graphs represent the assurance of a given service by
decomposing it into atomic assurance elements called subservices. A
companion RFC, Service Assurance for Intent-based Networking
Architecture, presents an architecture for implementing the assurance
of such services.
The YANG data models in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in RFC 8342.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 September 2022. This Internet-Draft will expire on 27 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 2. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3
4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 3. Base ietf-service-assurance YANG module . . . . . . . . . . . 4
4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7
5. Subservice Extension: ietf-service-assurance-device YANG 4. Subservice Extension: ietf-service-assurance-device YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . 15 module . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 4.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15
5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17
6. Subservice Extension: ietf-service-assurance-interface YANG 5. Subservice Extension: ietf-service-assurance-interface YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . 19 module . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19
6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21
7. Vendor-specific Subservice Extension: 6. Vendor-specific Subservice Extension:
example-service-assurance-device-acme YANG module . . . . 23 example-service-assurance-device-acme YANG module . . . . 23
7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 23 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 23
7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25
8. Further Extensions: IP Connectivity and IS-IS subservices . . 27 7. Further Extensions: IP Connectivity and IS-IS subservices . . 27
8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 27 7.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 27
8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 27 7.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 28
8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 28 7.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 28
8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29 7.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29
8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 31 7.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 32
9. Guidelines for Specific Subservice Extension . . . . . . . . 33 8. Guidelines for Specific Subservice Extension . . . . . . . . 33
9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 33 8.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 34
9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 33 8.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 34
9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 34 8.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 34
9.4. Subservice Specific Identity . . . . . . . . . . . . . . 34 8.4. Subservice Specific Identity . . . . . . . . . . . . . . 35
9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 34 8.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 35
11.2. The YANG Module Names Registry . . . . . . . . . . . . . 35
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Example of YANG instances . . . . . . . . . . . . . 37
Appendix B. YANG Library for Service Assurance . . . . . . . . . 41
Appendix C. Changes between revisions . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The terms used in this document are defined in 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
[I-D.ietf-opsawg-service-assurance-architecture] 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 36
10.2. The YANG Module Names Registry . . . . . . . . . . . . . 36
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Normative References . . . . . . . . . . . . . . . . . . 37
12.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Example of YANG instances . . . . . . . . . . . . . 38
Appendix B. YANG Library for Service Assurance . . . . . . . . . 42
Appendix C. Changes between revisions . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
2. Introduction 1. Introduction
The "Service Assurance for Intent-based Networking Architecture" The "Service Assurance for Intent-based Networking Architecture"
[I-D.ietf-opsawg-service-assurance-architecture], specifies the [I-D.ietf-opsawg-service-assurance-architecture], specifies the
architecture and all of its components for service assurance. This architecture and all of its components for service assurance. This
document complements the architecture by providing open interfaces document complements the architecture by providing open interfaces
between components. More specifically, the goal is to provide YANG between components. More specifically, the goal is to provide YANG
modules for the purpose of service assurance in a format that is: modules for the purpose of service assurance in a format that is:
* machine readable * machine readable
* vendor independent * vendor independent
* augmentable * augmentable
3. YANG Models Overview 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
13 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The terms used in this document are defined in
[I-D.ietf-opsawg-service-assurance-architecture]
2. YANG Models Overview
The main YANG module, ietf-service-assurance, defines objects for The main YANG module, ietf-service-assurance, defines objects for
assuring network services based on their decomposition into so-called assuring network services based on their decomposition into so-called
subservices. The subservices are hierarchically organised by subservices. The subservices are hierarchically organised by
dependencies. The subservices, along with the dependencies, dependencies. The subservices, along with the dependencies,
constitute an assurance graph. This module should be supported by an constitute an assurance graph. This module should be supported by an
agent, able to interact with the devices in order to produce a health agent, able to interact with the devices in order to produce a health
status and symptoms for each subservice in the assurance graph. This status and symptoms for each subservice in the assurance graph. This
module is intended for the following use cases: module is intended for the following use cases:
skipping to change at page 4, line 18 skipping to change at page 4, line 18
- 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 type.
* Assurance telemetry: export the health status of the subservices, * Assurance telemetry: export the health status of the subservices,
along with the observed symptoms. along with the observed symptoms.
The main module represents the configuration (subservice and
dependencies) and operational data (health status and symptoms) in a
single tree. Other modules follows the same pattern. Thus, the
modules presented in this document conform to the Network Management
Datastore Architecture defined in [RFC8342].
The second YANG module, ietf-service-assurance-device, extends the The second YANG module, ietf-service-assurance-device, extends the
ietf-service-assurance module to add support for the subservice ietf-service-assurance module to add support for the subservice
DeviceHealthy. Additional subservice types might be added the same DeviceHealthy. Additional subservice types might be added the same
way. way.
The third YANG module, ietf-service-assurance-device, is another The third YANG module, ietf-service-assurance-device, is another
example that extends the ietf-service-assurance-device module. This example that extends the ietf-service-assurance-device module. This
extension adds support for the subservice InterfaceHealthy. extension adds support for the subservice InterfaceHealthy.
The fourth YANG module, example-service-assurance-device-acme, The fourth YANG module, example-service-assurance-device-acme,
extends the ietf-service-assurance-device module as an example to add extends the ietf-service-assurance-device module as an example to add
support for the subservice DeviceHealthy, with specifics for the support for the subservice DeviceHealthy, with specifics for the
fictional ACME Corporation. Additional vendor-specific parameters fictional ACME Corporation. Additional vendor-specific parameters
might be added the same way. might be added the same way.
Finally, the modules ietf-service-assurance-ip-connectivity and ietf- Finally, the modules example-service-assurance-ip-connectivity and
service-assurance-is-is are provided to completely model the example example-service-assurance-is-is are provided to completely model the
from the SAIN architecture draft example from the SAIN architecture draft
[I-D.ietf-opsawg-service-assurance-architecture]. [I-D.ietf-opsawg-service-assurance-architecture].
4. Base ietf-service-assurance YANG module 3. Base ietf-service-assurance YANG module
4.1. Tree View 3.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance data model. ietf-service-assurance data model.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter64 +--ro assurance-graph-version yang:counter64
+--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? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
| +--:(service-instance-parameter) | +--:(service-instance-parameter)
| +--rw service-instance-parameter | +--rw service-instance-parameter
| +--rw service string | +--rw service string
| +--rw instance-name string | +--rw instance-name string
+--ro health-score? union +--ro health-score? union
+--ro symptoms-history-start? yang:date-and-time +--ro symptoms-history-start? yang:date-and-time
+--rw symptoms +--rw symptoms
| +--ro symptom* [start-date-time id] | +--ro symptom* [start-date-time id]
| +--ro id string | +--ro id string
| +--ro health-score-weight? uint8 | +--ro health-score-weight? uint8
| +--ro description? string | +--ro description? string
| +--ro start-date-time yang:date-and-time | +--ro start-date-time yang:date-and-time
| +--ro stop-date-time? yang:date-and-time | +--ro stop-date-time? yang:date-and-time
+--rw dependencies +--rw dependencies
+--rw dependency* [type id] +--rw dependency* [type id]
+--rw type -> /subservices/subservice/type +--rw type
+--rw id -> /subservices/subservice[type=current()/../type]/id | -> /subservices/subservice/type
+--rw dependency-type? identityref +--rw id leafref
+--rw dependency-type? identityref
4.2. Concepts 3.2. Concepts
The ietf-service-assurance YANG model assumes an identified number of The ietf-service-assurance YANG model assumes an identified number of
subservices, to be assured independently. A subservice is a feature subservices, to be assured independently. A subservice is a feature
or a subpart of the network system that a given service instance or a subpart of the network system that a given service instance
might depend on. Example of subservices include: might depend on. Example of subservices include:
* DeviceHealthy: whether a device is healthy, and if not, what are * DeviceHealthy: whether a device is healthy, and if not, what are
the symptoms. Potential symptoms are "CPU overloaded", "Out of the symptoms. Potential symptoms are "CPU overloaded", "Out of
RAM", or "Out of TCAM". RAM", or "Out of TCAM".
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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 a unique id and contains a health-score- symptom is specified by a unique id and contains a health-score-
weight (the impact to the health score incurred by this symptom), a weight (the impact to the health score incurred by this symptom), a
label (text describing what the symptom is), and dates and times at label (text describing what the symptom is), and dates and times at
which the symptom was detected and stopped being detected. While the which the symptom was detected and stopped being detected. While the
unique id is sufficient as an unique key list, the start-date-time unique id is sufficient as an unique key list, the start-date-time
second key help sorting and retrieving relevant symptoms. second key help sorting and retrieving relevant symptoms.
The relation between the health score and the health-score-weight of The relation between the health score and the health-score-weight of
the currently active symptoms is not explictely defined in this the currently active symptoms is not explicitly defined in this
draft. The only requirement is that a non-maximal score must be draft. The only requirement is that a non-maximal score must be
explained by at least one symptom. A way to enforce that requirement explained by at least one symptom. A way to enforce that requirement
is to first detect symptoms and then compute the health score based is to first detect symptoms and then compute the health score based
on the health-score-weight of the detected symptoms. As an example, on the health-score-weight of the detected symptoms. As an example,
this computation could be to sum the health-score-weight of the this computation could be to sum the health-score-weight of the
active symptoms, substract that value from 100 and change the value active symptoms, subtract that value from 100 and change the value to
to 0 if negative. The relation between health-score and health- 0 if negative. The relation between health-score and health-score-
score-weight is left to the implementor (of an agent weight is left to the implementor (of an agent
[I-D.ietf-opsawg-service-assurance-architecture]). To consider for [I-D.ietf-opsawg-service-assurance-architecture]). To consider for
implementing this relation: the health-score is mostly for humans, implementing this relation: the health-score is mostly for humans,
the symptoms are what the closed loop automation can build on. the symptoms are what the closed loop automation can build on.
The assurance of a given service instance can be obtained by The assurance of a given service instance can be obtained by
composing the assurance of the subservices that it depends on, via composing the assurance of the subservices that it depends on, via
the dependency relations. the dependency relations.
A subservice declaration MUST provide: A subservice declaration MUST provide:
skipping to change at page 7, line 43 skipping to change at page 7, line 43
[I-D.ietf-opsawg-service-assurance-architecture] for a more detailed [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed
discussion. discussion.
By specifying service instances and their dependencies in terms of By specifying service instances and their dependencies in terms of
subservices, one defines the whole assurance to apply for them. An subservices, one defines the whole assurance to apply for them. An
assurance agent supporting this model should then produce telemetry assurance agent supporting this model should then produce telemetry
in return with, for each subservice: a health-status indicating how in return with, for each subservice: a health-status indicating how
healthy the subservice is and when the subservice is not healthy, a healthy the subservice is and when the subservice is not healthy, a
list of symptoms explaining why the subservice is not healthy. list of symptoms explaining why the subservice is not healthy.
4.3. YANG Module 3.3. YANG Module
<CODE BEGINS> file "ietf-service-assurance@2022-01-04.yang" <CODE BEGINS> file "ietf-service-assurance@2022-04-07.yang"
module ietf-service-assurance { module ietf-service-assurance {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";
prefix service-assurance; prefix sain;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference
"RFC 6991: Common YANG Data Types";
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:netconf@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.quilbeu@huawei.com>"; Author: Jean Quilbeuf <mailto:jean.quilbeu@huawei.com>";
description description
"This module defines objects for assuring network services based on "This module defines objects for assuring network services based on
their decomposition into so-called subservices, according to the SAIN their decomposition into so-called subservices, according to the
(Service Assurance for Intent-based Networking) architecture. SAIN (Service Assurance for Intent-based Networking) architecture.
The subservices hierarchically organised by dependencies constitute an The subservices hierarchically organised by dependencies constitute
assurance graph. This module should be supported by an assurance agent, an assurance graph. This module should be supported by an assurance
able to interact with the devices in order to produce a health status agent, able to interact with the devices in order to produce a
and symptoms for each subservice in the assurance graph. health status and symptoms for each subservice in the assurance
graph.
This module is intended for the following use cases: This module is intended for the following use cases:
* Assurance graph configuration: * Assurance graph configuration:
* subservices: configure a set of subservices to assure, by specifying - subservices: configure a set of subservices to assure, by
their types and parameters. specifying their types and parameters.
* dependencies: configure the dependencies between the subservices, - dependencies: configure the dependencies between the
along with their type. subservices, along with their type.
* Assurance telemetry: export the health status of the subservices, along * Assurance telemetry: export the health status of the subservices,
with the observed symptoms. along with the observed symptoms.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Copyright (c)2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. 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 Simplified BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions 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 XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices. ";
TO DO:
- Better type (IETF or OC) for device-id, interface-id, etc.
- Have a YANG module for IETF and one for OC?";
revision 2022-04-07 {
description
"Shorten prefix. Fix copyright.
Fix module description";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2022-01-04 { revision 2022-01-04 {
description description
"Explicitely model a missing value"; "Explicitely model a missing value";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: YANG Modules for Service Assurance";
} }
revision 2021-06-28 { revision 2021-06-28 {
description description
"Made service-instance parameters mandatory."; "Made service-instance parameters mandatory.";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: YANG Modules for Service Assurance";
} }
revision 2020-01-13 { revision 2020-01-13 {
description description
"Added the maintenance window concept."; "Added the maintenance window concept.";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: YANG Modules for Service Assurance";
} }
revision 2019-11-16 { revision 2019-11-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: YANG Modules for Service Assurance";
} }
identity subservice-idty { identity subservice-idty {
description description
"Root identity for all subservice types."; "Root identity for all subservice types.";
} }
identity service-instance-idty { identity service-instance-idty {
base subservice-idty; base subservice-idty;
description description
skipping to change at page 10, line 4 skipping to change at page 10, line 10
} }
identity dependency-type { identity dependency-type {
description description
"Base identity for representing dependency types."; "Base identity for representing dependency types.";
} }
identity informational-dependency { identity informational-dependency {
base dependency-type; base dependency-type;
description description
"Indicates that symptoms of the dependency might be of interest for the "Indicates that symptoms of the dependency might be of interest
dependent, but the status of the dependency should not have any for the dependent, but the status of the dependency should not
impact on the dependent."; have any impact on the dependent.";
} }
identity impacting-dependency { identity impacting-dependency {
base dependency-type; base dependency-type;
description description
"Indicates that the status of the dependency directly impacts the status "Indicates that the status of the dependency directly impacts the
of the dependent."; status of the dependent.";
} }
grouping symptom { grouping symptom {
description description
"Contains the list of symptoms for a specific subservice."; "Contains the list of symptoms for a specific subservice.";
leaf id { leaf id {
type string; type string;
description description
"A unique identifier for the symptom."; "A unique identifier for the symptom.";
} }
leaf health-score-weight { leaf health-score-weight {
type uint8 { type uint8 {
range "0 .. 100"; range "0 .. 100";
} }
description description
"The weight to the health score incurred by this symptom. The higher the "The weight to the health score incurred by this symptom. The
value, the more of an impact this symptom has. If a subservice health higher the value, the more of an impact this symptom has. If a
score is not 100, there must be at least one symptom with a health subservice health score is not 100, there must be at least one
score weight larger than 0."; symptom with a health score weight larger than 0.";
} }
leaf description { leaf description {
type string; type string;
description description
"Description of the symptom, i.e. text describing what the symptom is, to "Description of the symptom, i.e. text describing what the
be computer-consumable and be displayed on a human interface. "; symptom is, to be computer-consumable and be displayed on a
human interface. ";
} }
leaf start-date-time { leaf start-date-time {
type yang:date-and-time; type yang:date-and-time;
description description
"Date and time at which the symptom was detected."; "Date and time at which the symptom was detected.";
} }
leaf stop-date-time { leaf stop-date-time {
type yang:date-and-time; type yang:date-and-time;
description description
"Date and time at which the symptom stopped being detected."; "Date and time at which the symptom stopped being detected.";
skipping to change at page 11, line 26 skipping to change at page 11, line 33
path "/subservices/subservice[type=current()/../type]/id"; path "/subservices/subservice[type=current()/../type]/id";
} }
description description
"The identifier of the subservice to refer to."; "The identifier of the subservice to refer to.";
} }
leaf dependency-type { leaf dependency-type {
type identityref { type identityref {
base dependency-type; base dependency-type;
} }
description description
"Represents the type of dependency (i.e. informational, impacting)."; "Represents the type of dependency (i.e. informational,
impacting).";
} }
// augment here if more info are needed (i.e. a percentage) depending on the dependency type. // Augment here to add parameters specific to a new dependency-type.
// For instance, a specific dependency type could keep symptom
// whose health-score-weight is larger than a given value.
} }
leaf assurance-graph-version { leaf assurance-graph-version {
type yang:counter64; type yang:counter64;
config false; config false;
mandatory true; mandatory true;
description description
"The assurance graph version, which increases by 1 for each new version, after the changes "The assurance graph version, which increases by 1 for each new
(dependencies and/or maintenance windows parameters) are applied to the subservice(s)."; version, after the changes (dependencies and/or maintenance
windows parameters) are applied to the subservice(s).";
} }
leaf assurance-graph-last-change { leaf assurance-graph-last-change {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
mandatory true; mandatory true;
description description
"Date and time at which the assurance graph last changed after the changes (dependencies "Date and time at which the assurance graph last changed after the
and/or maintenance windows parameters) are applied to the subservice(s). These date and time changes (dependencies and/or maintenance windows parameters) are
must be more recent or equal compared to the more recent value of any changed subservices applied to the subservice(s). These date and time must be more
last-change"; recent or equal compared to the more recent value of any changed
subservices last-change";
} }
container subservices { container subservices {
description description
"Root container for the subservices."; "Root container for the subservices.";
list subservice { list subservice {
key "type id"; key "type id";
description description
"List of subservice configured."; "List of subservice configured.";
leaf type { leaf type {
type identityref { type identityref {
base subservice-idty; base subservice-idty;
} }
description description
"Name of the subservice, e.g. DeviceHealthy."; "Name of the subservice, e.g. DeviceHealthy.";
skipping to change at page 12, line 19 skipping to change at page 12, line 30
leaf type { leaf type {
type identityref { type identityref {
base subservice-idty; base subservice-idty;
} }
description description
"Name of the subservice, e.g. DeviceHealthy."; "Name of the subservice, e.g. DeviceHealthy.";
} }
leaf id { leaf id {
type string; type string;
description description
"Unique identifier of the subservice instance, for each type."; "Unique identifier of the subservice instance, for each
type.";
} }
leaf last-change { leaf last-change {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
description description
"Date and time at which the assurance graph for this subservice "Date and time at which the assurance graph for this
instance last changed, i.e. dependencies and/or maintenance windows parameters."; subservice instance last changed, i.e. dependencies and/or
maintenance windows parameters.";
} }
leaf label { leaf label {
type string; type string;
config false; config false;
description description
"Label of the subservice, i.e. text describing what the subservice is to "Label of the subservice, i.e. text describing what the
be displayed on a human interface."; subservice is to be displayed on a human interface.";
} }
leaf under-maintenance { leaf under-maintenance {
type boolean; type boolean;
default "false"; default "false";
description description
"An optional flag indicating whether this particular subservice is under "An optional flag indicating whether this particular
maintenance. Under this circumstance, the subservice symptoms and the subservice is under maintenance. Under this circumstance, the
symptoms of its dependencies in the assurance graph should not be taken subservice symptoms and the symptoms of its dependencies in
into account. Instead, the subservice should send a 'Under Maintenance' the assurance graph should not be taken into account.
Instead, the subservice should send a 'Under Maintenance'
single symptom. single symptom.
The operator changing the under-maintenance value must set the The operator changing the under-maintenance value must set
maintenance-contact variable. the maintenance-contact variable.
When the subservice is not under maintenance any longer, the When the subservice is not under maintenance any longer, the
under-maintenance flag must return to its default value and under-maintenance flag must return to its default value and
the under-maintenance-owner variable deleted."; the under-maintenance-owner variable deleted.";
} }
leaf maintenance-contact { leaf maintenance-contact {
when "../under-maintenance = 'true'"; when "../under-maintenance = 'true'";
type string; type string;
mandatory true; mandatory true;
description description
"A string used to model an administratively assigned name of the "A string used to model an administratively assigned name of
resource that changed the under-maintenance value to 'true. the resource that changed the under-maintenance value to
'true'.
It is suggested that this name contain one or more of the following: It is suggested that this name contain one or more of the
IP address, management station name, network manager's name, location, following: IP address, management station name,
or phone number. In some cases the agent itself will be the owner of network manager's name, location, or phone number. In some
an entry. In these cases, this string shall be set to a string cases the agent itself will be the owner of an entry. In
starting with 'monitor'."; these cases, this string shall be set to a string starting
with 'monitor'.";
} }
choice parameter { choice parameter {
description description
"Specify the required parameters per subservice type."; "Specify the required parameters per subservice type.";
container service-instance-parameter { container service-instance-parameter {
when "derived-from-or-self(../type, 'service-assurance:service-instance-idty')"; when "derived-from-or-self(../type,
'sain:service-instance-idty')";
description description
"Specify the parameters of a service instance."; "Specify the parameters of a service instance.";
leaf service { leaf service {
type string; type string;
mandatory true; mandatory true;
description description
"Name of the service."; "Name of the service.";
} }
leaf instance-name { leaf instance-name {
type string; type string;
skipping to change at page 14, line 4 skipping to change at page 14, line 22
range "0 .. 100"; range "0 .. 100";
} }
type enumeration { type enumeration {
enum missing { enum missing {
value -1; value -1;
description description
"Explictly represent the fact that the health score is "Explictly represent the fact that the health score is
missing. This could be used when metrics crucial to missing. This could be used when metrics crucial to
establish the health score are not collected anymore."; establish the health score are not collected anymore.";
} }
} }
} }
config false; config false;
description description
"Score value of the subservice health. A value of 100 means that "Score value of the subservice health. A value of 100 means
subservice is healthy. A value of 0 means that the subservice is that subservice is healthy. A value of 0 means that the
broken. A value between 0 and 100 means that the subservice is subservice is broken. A value between 0 and 100 means that
degraded."; the subservice is degraded.";
} }
leaf symptoms-history-start { leaf symptoms-history-start {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
description description
"Date and time at which the symptoms history starts for this "Date and time at which the symptoms history starts for this
subservice instance, either because the subservice instance subservice instance, either because the subservice instance
started at that date and time or because the symptoms before that started at that date and time or because the symptoms before
were removed due to a garbage collection process."; that were removed due to a garbage collection process.";
} }
container symptoms { container symptoms {
description description
"Symptoms for the subservice."; "Symptoms for the subservice.";
list symptom { list symptom {
key "start-date-time id"; key "start-date-time id";
config false; config false;
description description
"List of symptoms the subservice. While the start-date-time key is not "List of symptoms the subservice. While the start-date-time
necessary per se, this would get the entries sorted by start-date-time key is not necessary per se, this would get the entries
for easy consumption."; sorted by start-date-time for easy consumption.";
uses symptom; uses symptom;
} }
} }
container dependencies { container dependencies {
description description
"configure the dependencies between the subservices, along with their types."; "configure the dependencies between the subservices, along
with their types.";
list dependency { list dependency {
key "type id"; key "type id";
description description
"List of soft dependencies of the subservice."; "List of soft dependencies of the subservice.";
uses subservice-dependency; uses subservice-dependency;
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. Subservice Extension: ietf-service-assurance-device YANG module 4. Subservice Extension: ietf-service-assurance-device YANG module
5.1. Tree View 4.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-device data model. ietf-service-assurance-device data model.
module: ietf-service-assurance-device module: ietf-service-assurance-device
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw device string +--rw device string
5.2. Complete Tree View 4.2. Complete 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 and ietf-service-assurance-device data models. ietf-service-assurance and ietf-service-assurance-device data models.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter64 +--ro assurance-graph-version yang:counter64
+--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? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
| +--:(service-instance-parameter) | +--:(service-instance-parameter)
| | +--rw service-instance-parameter | | +--rw service-instance-parameter
| | +--rw service string | | +--rw service string
| | +--rw instance-name string | | +--rw instance-name string
| +--:(service-assurance-device:parameters) | +--:(sain-device:parameters)
| +--rw service-assurance-device:parameters | +--rw sain-device:parameters
| +--rw service-assurance-device:device string | +--rw sain-device:device string
+--ro health-score? union +--ro health-score? union
+--ro symptoms-history-start? yang:date-and-time +--ro symptoms-history-start? yang:date-and-time
+--rw symptoms +--rw symptoms
| +--ro symptom* [start-date-time id] | +--ro symptom* [start-date-time id]
| +--ro id string | +--ro id string
| +--ro health-score-weight? uint8 | +--ro health-score-weight? uint8
| +--ro description? string | +--ro description? string
| +--ro start-date-time yang:date-and-time | +--ro start-date-time yang:date-and-time
| +--ro stop-date-time? yang:date-and-time | +--ro stop-date-time? yang:date-and-time
+--rw dependencies +--rw dependencies
+--rw dependency* [type id] +--rw dependency* [type id]
+--rw type -> /subservices/subservice/type +--rw type
+--rw id -> /subservices/subservice[type=current()/../type]/id | -> /subservices/subservice/type
+--rw dependency-type? identityref +--rw id leafref
+--rw dependency-type? identityref
5.3. Concepts 4.3. Concepts
As the number of subservices will grow over time, the YANG module is 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 DeviceHealthy subservice type. As illustrate the example of the new DeviceHealthy subservice type. As
the name implies, it monitors and reports the device health, along the name implies, it monitors and reports the device health, along
with some symptoms in case of degradation. with some symptoms in case of degradation.
For our DeviceHealthy subservice definition, the new identity device- For our DeviceHealthy subservice definition, the new identity device-
idty is specified, as an inheritance from the base identity for idty 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 DeviceHealthy The typical parameter for the configuration of the DeviceHealthy
subservice is the name of the device that we want to assure. By subservice is the name of the device that we want to assure. By
augmenting the parameter choice from ietf-service-assurance YANG augmenting the parameter choice from ietf-service-assurance YANG
module for the case of the device-idty subservice type, this new module for the case of the device-idty subservice type, this new
parameter is specified. parameter is specified.
5.4. YANG Module 4.4. YANG Module
<CODE BEGINS> file "ietf-service-assurance-device@2021-06-28.yang" <CODE BEGINS> file "ietf-service-assurance-device@2022-04-07.yang"
module ietf-service-assurance-device { module ietf-service-assurance-device {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; namespace
prefix service-assurance-device; "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device";
prefix sain-device;
import ietf-service-assurance { import ietf-service-assurance {
prefix service-assurance; prefix sain;
} reference
"RFC xxxx: YANG Modules for Service Assurance";
}
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:netconf@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 subservice DeviceHealthy. support for the subservice DeviceHealthy.
Checks whether a network device is healthy. Checks whether a network device is healthy.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. 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 Simplified BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions 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. ";
This version of this YANG module is part of RFC XXXX; see the revision 2022-04-07 {
RFC itself for full legal notices. "; description
"Fix mandatory in augment error by moving when clause.
Shorten prefix. Fix module description.
Fix module description";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2021-06-28 {
description
"Renamed the container for parameters.";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2020-01-13 {
description
"Added the maintenance window concept.";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2019-11-16 {
description
"Initial revision.";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2021-06-28 { identity device-idty {
description base sain:subservice-idty;
"Renamed the container for parameters."; description
reference "Network Device is healthy.";
"RFC xxxx: Title to be completed"; }
}
revision 2020-01-13 {
description
"Added the maintenance window concept.";
reference
"RFC xxxx: Title to be completed";
}
revision 2019-11-16 {
description
"Initial revision.";
reference
"RFC xxxx: Title to be completed";
}
identity device-idty { augment "/sain:subservices/sain:subservice/sain:parameter" {
base service-assurance:subservice-idty; when "derived-from-or-self(sain:type, 'device-idty')";
description description
"Network Device is healthy."; "Specify the required parameters for a new subservice type";
}
augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { container parameters {
description description
"Specify the required parameters for a new subservice type"; "Specify the required parameters for the device-idty
container parameters { subservice type";
when "derived-from-or-self(../service-assurance:type, 'device-idty')"; leaf device {
description type string;
"Specify the required parameters for the device-idty subservice type"; mandatory true;
leaf device { description
type string; "The device to monitor.";
mandatory true; }
description }
"The device to monitor."; }
} }
}
}
}
<CODE ENDS> <CODE ENDS>
6. Subservice Extension: ietf-service-assurance-interface YANG module 5. Subservice Extension: ietf-service-assurance-interface YANG module
6.1. Tree View 5.1. Tree View
The following tree diagram [RFC8340] provides an overview of the 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 /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw device string +--rw device string
+--rw interface string +--rw interface string
6.2. Complete Tree View 5.2. Complete 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, and ietf- ietf-service-assurance, ietf-service-assurance-device, and ietf-
service-assurance-interface data models. service-assurance-interface data models.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter64 +--ro assurance-graph-version yang:counter64
+--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? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
| +--:(service-instance-parameter) | +--:(service-instance-parameter)
| | +--rw service-instance-parameter | | +--rw service-instance-parameter
| | +--rw service string | | +--rw service string
| | +--rw instance-name string | | +--rw instance-name string
| +--:(service-assurance-interface:parameters) | +--:(sain-interface:parameters)
| | +--rw service-assurance-interface:parameters | | +--rw sain-interface:parameters
| | +--rw service-assurance-interface:device string | | +--rw sain-interface:device string
| | +--rw service-assurance-interface:interface string | | +--rw sain-interface:interface string
| +--:(service-assurance-device:parameters) | +--:(sain-device:parameters)
| +--rw service-assurance-device:parameters | +--rw sain-device:parameters
| +--rw service-assurance-device:device string | +--rw sain-device:device string
+--ro health-score? union +--ro health-score? union
+--ro symptoms-history-start? yang:date-and-time +--ro symptoms-history-start? yang:date-and-time
+--rw symptoms +--rw symptoms
| +--ro symptom* [start-date-time id] | +--ro symptom* [start-date-time id]
| +--ro id string | +--ro id string
| +--ro health-score-weight? uint8 | +--ro health-score-weight? uint8
| +--ro description? string | +--ro description? string
| +--ro start-date-time yang:date-and-time | +--ro start-date-time yang:date-and-time
| +--ro stop-date-time? yang:date-and-time | +--ro stop-date-time? yang:date-and-time
+--rw dependencies +--rw dependencies
+--rw dependency* [type id] +--rw dependency* [type id]
+--rw type -> /subservices/subservice/type +--rw type
+--rw id -> /subservices/subservice[type=current()/../type]/id | -> /subservices/subservice/type
+--rw dependency-type? identityref +--rw id leafref
+--rw dependency-type? identityref
6.3. Concepts 5.3. Concepts
For our InterfaceHealthy subservice definition, the new interface- For our InterfaceHealthy subservice definition, the new interface-
idty is specified, as an inheritance from the base identity for idty 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 an interface. assuring the health of an interface.
The typical parameters for the configuration of the InterfaceHealthy The typical parameters for the configuration of the InterfaceHealthy
subservice are the name of the device and, on that specific device, a subservice are the name of the device and, on that specific device, a
specific interface. By augmenting the parameter choice from ietf- specific interface. By augmenting the parameter choice from ietf-
service-assurance YANG module for the case of the interface-idty service-assurance YANG module for the case of the interface-idty
subservice type, those two new parameter are specified. subservice type, those two new parameters are specified.
6.4. YANG Module 5.4. YANG Module
<CODE BEGINS> file "ietf-service-assurance-interface@2021-06-28.yang" <CODE BEGINS> file "ietf-service-assurance-interface@2022-04-07.yang"
module ietf-service-assurance-interface { module ietf-service-assurance-interface {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; namespace
prefix service-assurance-interface; "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface";
prefix sain-interface;
import ietf-service-assurance { import ietf-service-assurance {
prefix service-assurance; prefix sain;
} reference
"RFC xxxx: 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 subservice InterfaceHealthy. support for the subservice InterfaceHealthy.
Checks whether an interface is healthy. Checks whether an interface is healthy.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. 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 Simplified BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions 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 XXXX; see the
RFC itself for full legal notices. "; RFC itself for full legal notices. ";
revision 2021-06-28 { revision 2022-04-07 {
description description
"Regroup parameters in a container."; "Fix mandatory in augment error by moving when clause.
reference Shorten prefix. Fix module description.
"RFC xxxx: Title to be completed"; Fix module description";
} reference
revision 2020-01-13 { "RFC xxxx: YANG Modules for Service Assurance";
description }
"Initial revision."; revision 2021-06-28 {
reference description
"RFC xxxx: Title to be completed"; "Regroup parameters in a container.";
} reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2020-01-13 {
description
"Initial revision.";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
identity interface-idty { identity interface-idty {
base service-assurance:subservice-idty; base sain:subservice-idty;
description description
"Checks whether an interface is healthy."; "Checks whether an interface is healthy.";
} }
augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { augment "/sain:subservices/sain:subservice/sain:parameter" {
description when "derived-from-or-self(sain:type, 'interface-idty')";
"Specify the required parameters for the interface-idty subservice type"; description
container parameters { "Specify the required parameters for the interface-idty
when "derived-from-or-self(../service-assurance:type, 'interface-idty')"; subservice type";
description container parameters {
"Required parameters for the interface-idty subservice type"; description
leaf device { "Required parameters for the interface-idty subservice
type string; type";
mandatory true; leaf device {
description type string;
"Device supporting the interface."; mandatory true;
} description
leaf interface { "Device supporting the interface.";
type string; }
mandatory true; leaf interface {
description type string;
"Name of the interface."; mandatory true;
} description
} "Name of the interface.";
} }
} }
}
}
<CODE ENDS> <CODE ENDS>
7. Vendor-specific Subservice Extension: example-service-assurance- 6. Vendor-specific Subservice Extension: example-service-assurance-
device-acme YANG module device-acme YANG module
7.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
example-service-assurance-device-acme data model. example-service-assurance-device-acme data model.
module: example-service-assurance-device-acme module: example-service-assurance-device-acme
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw device string +--rw device string
+--rw acme-specific-parameter string +--rw acme-specific-parameter string
7.2. Complete Tree View 6.2. Complete Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance, ietf-service-assurance-device, and example- ietf-service-assurance, ietf-service-assurance-device, and example-
service-assurance-device-acme data models. service-assurance-device-acme data models.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter64 +--ro assurance-graph-version yang:counter64
+--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? yang:date-and-time +--ro last-change?
+--ro label? string | yang:date-and-time
+--rw under-maintenance? boolean +--ro label? string
+--rw maintenance-contact string +--rw under-maintenance? boolean
+--rw (parameter)? +--rw maintenance-contact string
| +--:(service-instance-parameter) +--rw (parameter)?
| | +--rw service-instance-parameter | +--:(service-instance-parameter)
| | +--rw service string | | +--rw service-instance-parameter
| | +--rw instance-name string | | +--rw service string
| +--:(service-assurance-device:parameters) | | +--rw instance-name string
| | +--rw service-assurance-device:parameters | +--:(sain-device:parameters)
| | +--rw service-assurance-device:device string | | +--rw sain-device:parameters
| +--:(example-service-assurance-device-acme:parameters) | | +--rw sain-device:device string
| | +--rw example-service-assurance-device-acme:parameters | +--:(example-device-acme:parameters)
| | +--rw example-service-assurance-device-acme:device string | | +--rw example-device-acme:parameters
| | +--rw example-service-assurance-device-acme:acme-specific-parameter string | | +--rw example-device-acme:device
| +--:(service-assurance-interface:parameters) | | | string
| +--rw service-assurance-interface:parameters | | +--rw example-device-acme:acme-specific-parameter
| +--rw service-assurance-interface:device string | | string
| +--rw service-assurance-interface:interface string | +--:(sain-interface:parameters)
+--ro health-score? union | +--rw sain-interface:parameters
+--ro symptoms-history-start? yang:date-and-time | +--rw sain-interface:device string
+--rw symptoms | +--rw sain-interface:interface string
| +--ro symptom* [start-date-time id] +--ro health-score? union
| +--ro id string +--ro symptoms-history-start?
| +--ro health-score-weight? uint8 | yang:date-and-time
| +--ro description? string +--rw symptoms
| +--ro start-date-time yang:date-and-time | +--ro symptom* [start-date-time id]
| +--ro stop-date-time? yang:date-and-time | +--ro id string
+--rw dependencies | +--ro health-score-weight? uint8
+--rw dependency* [type id] | +--ro description? string
+--rw type -> /subservices/subservice/type | +--ro start-date-time yang:date-and-time
+--rw id -> /subservices/subservice[type=current()/../type]/id | +--ro stop-date-time? yang:date-and-time
+--rw dependency-type? identityref +--rw dependencies
+--rw dependency* [type id]
+--rw type
| -> /subservices/subservice/type
+--rw id leafref
+--rw dependency-type? identityref
7.3. Concepts 6.3. Concepts
Under some circumstances, vendor-specific subservice types might be 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 module section shows how to augment the ietf-service-assurance-device module
to add support for the subservice DeviceHealthy, specific to the ACME to add support for the subservice DeviceHealthy, specific to the ACME
Corporation. The new parameter is acme-specific-parameter. Corporation. The new parameter is acme-specific-parameter.
7.4. YANG Module 6.4. 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-service-assurance-device-acme; prefix example-device-acme;
import ietf-service-assurance { import ietf-service-assurance {
prefix service-assurance; prefix sain;
} reference
import ietf-service-assurance-device { "RFC xxxx: YANG Modules for Service Assurance";
prefix service-assurance-device; }
} import ietf-service-assurance-device {
prefix sain-device;
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:netconf@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-device module to add "This module extends the ietf-service-assurance-device module to
support for the subservice DeviceHealthy, specific to the ACME Corporation. add support for the subservice DeviceHealthy, specific to the ACME
Corporation.
ACME Network Device is healthy. ACME Network Device is healthy.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. 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 Simplified BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions 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 XXXX; see the
RFC itself for full legal notices. "; RFC itself for full legal notices. ";
revision 2021-06-28 { revision 2022-04-07 {
description description
"Renamed the parameters container."; "Fix mandatory in augment error by moving when clause.
reference Shorten prefix.
"RFC xxxx: Title to be completed"; Fix module description";
} reference
revision 2020-01-13 { "RFC xxxx: YANG Modules for Service Assurance";
description }
"Added the maintenance window concept."; revision 2021-06-28 {
reference description
"RFC xxxx: Title to be completed"; "Renamed the parameters container.";
} reference
revision 2019-11-16 { "RFC xxxx: YANG Modules for Service Assurance";
description }
"Initial revision."; revision 2020-01-13 {
reference description
"RFC xxxx: Title to be completed"; "Added the maintenance window concept.";
} reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2019-11-16 {
description
"Initial revision.";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
identity device-acme-idty { identity device-acme-idty {
base service-assurance-device:device-idty; base sain-device:device-idty;
description description
"Network Device is healthy."; "Network Device is healthy.";
} }
augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { augment "/sain:subservices/sain:subservice/sain:parameter" {
description when "derived-from-or-self(sain:type, 'device-acme-idty')";
"Specify the required parameters for a new subservice type"; description
container parameters { "Specify the required parameters for a new subservice type";
when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')"; container parameters {
description description
"Specify the required parameters for the device-acme-idty subservice type"; "Specify the required parameters for the device-acme-idty
leaf device { subservice type";
type string; leaf device {
mandatory true; type string;
description mandatory true;
"The device to monitor."; description
} "The device to monitor.";
leaf acme-specific-parameter { }
type string; leaf acme-specific-parameter {
mandatory true; type string;
description mandatory true;
"The ACME Corporation sepcific parameter."; description
} "The ACME Corporation sepcific parameter.";
} }
} }
} }
}
8. Further Extensions: IP Connectivity and IS-IS subservices 7. Further Extensions: IP Connectivity and IS-IS subservices
8.1. IP Connectivity Tree View In this section, we provide two additional YANG models to completely
cover the example from Figure 2 in
[I-D.ietf-opsawg-service-assurance-architecture]. The complete
normalization of these modules is to be done in future work.
The following tree diagram [RFC8340] provides an overview of the 7.1. IP Connectivity Tree View
ietf-service-assurance-ip-connectivity data model.
module: ietf-service-assurance-ip-connectivity That subservice represents the unicast connectivity between two IP
addresses located on to different devices. Such a subservice could
report symptoms such as "No route found". The following tree diagram
[RFC8340] provides an overview of the example-service-assurance-ip-
connectivity data model.
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: module: example-service-assurance-ip-connectivity
+--rw parameters
+--rw device1 string augment /sain:subservices/sain:subservice/sain:parameter:
+--rw address1 inet:ip-address +--rw parameters
+--rw device2 string +--rw device1 string
+--rw address2 inet:ip-address +--rw address1 inet:ip-address
+--rw device2 string
+--rw address2 inet:ip-address
To specify the connectivity that we are interested in, we specify two To specify the connectivity that we are interested in, we specify two
IP addresses and two devices. The subservice assures that the IP addresses and two devices. The subservice assures that the
connectivity between IP address 1 on device 1 and IP address 2 on connectivity between IP address 1 on device 1 and IP address 2 on
device 2 is healthy. device 2 is healthy.
8.2. IS-IS Tree View 7.2. IS-IS Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-is-is data model. example-service-assurance-is-is data model.
module: ietf-service-assurance-is-is module: example-service-assurance-is-is
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--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.
8.3. Global Tree View 7.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, ietf-service-assurance-ip-connectivity service-assurance-device-acme, example-service-assurance-ip-
and ietf-service-assurance-is-is data models. connectivity and example-service-assurance-is-is data models.
module: ietf-service-assurance
+--ro assurance-graph-version yang:counter64
+--ro assurance-graph-last-change yang:date-and-time
+--rw subservices
+--rw subservice* [type id]
+--rw type identityref
+--rw id string
+--ro last-change? yang:date-and-time
+--ro label? string
+--rw under-maintenance? boolean
+--rw maintenance-contact string
+--rw (parameter)?
| +--:(service-instance-parameter)
| | +--rw service-instance-parameter
| | +--rw service string
| | +--rw instance-name string
| +--:(service-assurance-ip-connectivity:parameters)
| | +--rw service-assurance-ip-connectivity:parameters
| | +--rw service-assurance-ip-connectivity:device1 string
| | +--rw service-assurance-ip-connectivity:address1 inet:ip-address
| | +--rw service-assurance-ip-connectivity:device2 string
| | +--rw service-assurance-ip-connectivity:address2 inet:ip-address
| +--:(service-assurance-is-is:parameters)
| | +--rw service-assurance-is-is:parameters
| | +--rw service-assurance-is-is:instance-name string
| +--:(service-assurance-device:parameters)
| | +--rw service-assurance-device:parameters
| | +--rw service-assurance-device:device string
| +--:(example-service-assurance-device-acme:parameters)
| | +--rw example-service-assurance-device-acme:parameters
| | +--rw example-service-assurance-device-acme:device string
| | +--rw example-service-assurance-device-acme:acme-specific-parameter string
| +--:(service-assurance-interface:parameters)
| +--rw service-assurance-interface:parameters
| +--rw service-assurance-interface:device string
| +--rw service-assurance-interface:interface string
+--ro health-score? union
+--ro symptoms-history-start? yang:date-and-time
+--rw symptoms
| +--ro symptom* [start-date-time id]
| +--ro id string
| +--ro health-score-weight? uint8
| +--ro description? string
| +--ro start-date-time yang:date-and-time
| +--ro stop-date-time? yang:date-and-time
+--rw dependencies
+--rw dependency* [type id]
+--rw type -> /subservices/subservice/type
+--rw id -> /subservices/subservice[type=current()/../type]/id
+--rw dependency-type? identityref
8.4. IP Connectivity YANG Module
<CODE BEGINS> file "ietf-service-assurance-ip- module: ietf-service-assurance
connectivity@2021-06-28.yang" +--ro assurance-graph-version yang:counter64
+--ro assurance-graph-last-change yang:date-and-time
+--rw subservices
+--rw subservice* [type id]
+--rw type identityref
+--rw id string
+--ro last-change?
| yang:date-and-time
+--ro label? string
+--rw under-maintenance? boolean
+--rw maintenance-contact string
+--rw (parameter)?
| +--:(service-instance-parameter)
| | +--rw service-instance-parameter
| | +--rw service string
| | +--rw instance-name string
| +--:(example-ip-connectivity:parameters)
| | +--rw example-ip-connectivity:parameters
| | +--rw example-ip-connectivity:device1 string
| | +--rw example-ip-connectivity:address1
| | | inet:ip-address
| | +--rw example-ip-connectivity:device2 string
| | +--rw example-ip-connectivity:address2
| | inet:ip-address
| +--:(example-is-is:parameters)
| | +--rw example-is-is:parameters
| | +--rw example-is-is:instance-name string
| +--:(sain-device:parameters)
| | +--rw sain-device:parameters
| | +--rw sain-device:device string
| +--:(example-device-acme:parameters)
| | +--rw example-device-acme:parameters
| | +--rw example-device-acme:device
| | | string
| | +--rw example-device-acme:acme-specific-parameter
| | string
| +--:(sain-interface:parameters)
| +--rw sain-interface:parameters
| +--rw sain-interface:device string
| +--rw sain-interface:interface string
+--ro health-score? union
+--ro symptoms-history-start?
| yang:date-and-time
+--rw symptoms
| +--ro symptom* [start-date-time id]
| +--ro id string
| +--ro health-score-weight? uint8
| +--ro description? string
| +--ro start-date-time yang:date-and-time
| +--ro stop-date-time? yang:date-and-time
+--rw dependencies
+--rw dependency* [type id]
+--rw type
| -> /subservices/subservice/type
+--rw id leafref
+--rw dependency-type? identityref
module ietf-service-assurance-ip-connectivity { 7.4. IP Connectivity YANG Module
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-ip-connectivity";
prefix service-assurance-ip-connectivity;
import ietf-inet-types { module example-service-assurance-ip-connectivity {
prefix inet; yang-version 1.1;
} namespace "urn:example:example-service-assurance-ip-connectivity";
import ietf-service-assurance { prefix example-ip-connectivity;
prefix 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 module extends the ietf-service-assurance module to add "RFC xxxx: YANG Modules for Service Assurance";
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 extends the ietf-service-assurance module to
add support for the subservice ip-connectivity.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', Checks whether the ip connectivity between two ip addresses
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', belonging to two network devices is healthy.
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
authors of the code. All rights reserved. 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
Redistribution and use in source and binary forms, with or 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
without modification, is permitted pursuant to, and subject are to be interpreted as described in BCP 14 (RFC 2119)
to the license terms contained in, the Simplified BSD License (RFC 8174) when, and only when, they appear in all
set forth in Section 4.c of the IETF Trust's Legal Provisions capitals, as shown here.
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the Copyright (c) 2022 IETF Trust and the persons identified as
RFC itself for full legal notices. "; authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
revision 2021-06-28 { This version of this YANG module is part of RFC XXXX; see the
description RFC itself for full legal notices. ";
"Initial revision.";
reference
"RFC xxxx: Title to be completed";
}
identity ip-connectivity-idty { revision 2022-04-07 {
base service-assurance:subservice-idty; description
description "Fix mandatory in augment error by moving when clause.
"Checks connectivity between two IP addresses."; Shorten prefix. Fix module description.
} Fix module description";
reference
"RFC xxxx: YANG Modules for Service Assurance";
augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { }
description revision 2021-06-28 {
"Specify the required parameters for the ip-connectivity-idty subservice type"; description
container parameters { "Initial revision.";
when "derived-from-or-self(../service-assurance:type, 'ip-connectivity-idty')"; reference
description "RFC xxxx: YANG Modules for Service Assurance";
"Required parameters for the ip-connectivity-idty subservice type"; }
leaf device1 {
type string;
mandatory true;
description
"Device at the first end of the connection.";
}
leaf address1 {
type inet:ip-address;
mandatory true;
description
"Address at the first end of the connection.";
}
leaf device2 {
type string;
mandatory true;
description
"Device at the second end of the connection.";
}
leaf address2 {
type inet:ip-address;
mandatory true;
description
"Address at the second end of the connection.";
}
}
}
}
<CODE ENDS> identity ip-connectivity-idty {
base sain:subservice-idty;
description
"Checks connectivity between two IP addresses.";
}
8.5. IS-IS YANG Module augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'ip-connectivity-idty')";
description
"Specify the required parameters for the ip-connectivity-idty
subservice type";
container parameters {
description
"Required parameters for the ip-connectivity-idty
subservice type";
leaf device1 {
type string;
mandatory true;
description
"Device at the first end of the connection.";
}
leaf address1 {
type inet:ip-address;
mandatory true;
description
"Address at the first end of the connection.";
}
leaf device2 {
type string;
mandatory true;
description
"Device at the second end of the connection.";
}
leaf address2 {
type inet:ip-address;
mandatory true;
description
"Address at the second end of the connection.";
}
}
<CODE BEGINS> file "ietf-service-assurance-is-is@2021-06-28.yang" }
}
module ietf-service-assurance-is-is { 7.5. IS-IS YANG Module
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is";
prefix service-assurance-is-is;
import ietf-service-assurance { module example-service-assurance-is-is {
prefix service-assurance; yang-version 1.1;
} namespace "urn:example:example-service-assurance-is-is";
prefix example-is-is;
organization import ietf-service-assurance {
"IETF NETCONF (Network Configuration) Working Group"; prefix sain;
contact reference
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "RFC xxxx: YANG Modules for Service Assurance";
WG List: <mailto:netconf@ietf.org> }
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This module extends the ietf-service-assurance module to add
support for the subservice IS-ISHealthy.
Checks whether an IS-IS instance is healthy. organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This module extends the ietf-service-assurance module to
add support for the subservice is-is.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', Checks whether an IS-IS instance is healthy.
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
authors of the code. All rights reserved. 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Redistribution and use in source and binary forms, with or Copyright (c) 2022 IETF Trust and the persons identified as
without modification, is permitted pursuant to, and subject authors of the code. All rights reserved.
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. ";
revision 2021-06-28 { Redistribution and use in source and binary forms, with or
description without modification, is permitted pursuant to, and subject
"Initial revision."; to the license terms contained in, the Revised BSD License
reference set forth in Section 4.c of the IETF Trust's Legal Provisions
"RFC xxxx: Title to be completed"; Relating to IETF Documents
} (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. ";
identity is-is-idty { revision 2022-04-07 {
base service-assurance:subservice-idty; description
description "Fix mandatory in augment error by moving when clause.
"Health of IS-IS routing protocol."; Shorten prefix. Fix module description.
} Fix module description";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
revision 2021-06-28 {
description
"Initial revision.";
reference
"RFC xxxx: YANG Modules for Service Assurance";
}
augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" { identity is-is-idty {
description base sain:subservice-idty;
"Specify the required parameters for a new subservice type"; description
container parameters { "Health of IS-IS routing protocol.";
when "derived-from-or-self(../service-assurance:type, 'is-is-idty')"; }
description
"Specify the required parameters for the IS-IS subservice type";
leaf instance-name {
type string;
mandatory true;
description
"The instance to monitor.";
}
}
}
}
<CODE ENDS> augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'is-is-idty')";
description
"Specify the required parameters for a new subservice
type";
container parameters {
description
"Specify the required parameters for the IS-IS subservice
type";
leaf instance-name {
type string;
mandatory true;
description
"The instance to monitor.";
}
}
}
}
9. Guidelines for Specific Subservice Extension 8. Guidelines for Specific Subservice Extension
The base YANG module defined in Section 4.3 only defines a single The base YANG module defined in Section 3.3 only defines a single
type of subservices that represent service instances. As explained type of subservices 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 in order to build theses extensions. propose some guidelines in order to build theses extensions.
First, the specific subservice must be given an adequate unique short First, the specific subservice must be given an adequate unique short
name that will be used to form longer names (e.g. module name, prefix name that will be used to form longer names (e.g. module name, prefix
...) appearing in the YANG module. The short name identifies the ...) appearing in the YANG module. The short name identifies the
type of subpart of feature that the subservice will represent, for type of subpart of feature that the subservice will represent, for
instance if the subservice will assure the health of a network instance if the subservice will assure the health of a network
interafce then "interface" is an adequate short name. If the interface then "interface" is an adequate short name. If the
subservice will assure the IS-IS routing protocol, then "is-is" is an subservice will assure the IS-IS routing protocol, then "is-is" is an
adequate short name. The short name must be in kebab-case. adequate short name. The short name must be in kebab-case.
In this section, by subservice YANG module, we mean "YANG module that In this section, by subservice YANG module, we mean "YANG module that
extends ieft-service-assurance in order to define a specific extends ietf-service-assurance in order to define a specific
subservice". subservice".
9.1. Module Name 8.1. Module Name
For subservice YANG modules vetted by the IETF, the module name For subservice YANG modules vetted by the IETF, the module name
should be "ieft-service-assurance-" followed by the short name. For should be "ietf-service-assurance-" followed by the short name. For
instance, "ietf-service-assurance-interface" or "ietf-service- instance, "ietf-service-assurance-interface" or "ietf-service-
assurance-is-is". assurance-is-is".
For subservice YANG module that are directly provided by vendors, we For subservice YANG module that are directly provided by vendors, we
propose that they use the company in the prefix. For example, the propose that they use the company in the prefix. For example, the
prefix for the company "acme" would be "acme-assurance-" and the YANG prefix for the company "acme" would be "acme-assurance-" and the YANG
modules would be "acme-assurance-interface", "acme-assurance-is-is", modules would be "acme-assurance-interface", "acme-assurance-is-is",
etc. etc.
9.2. Module Namespace 8.2. Module Namespace
For subservice YANG modules vetted by the IETF, the module namespace For subservice YANG modules vetted by the IETF, the module namespace
should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-" should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-"
followed by the short name. For instance, followed by the short name. For instance,
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is". "urn:ietf:params:xml:ns:yang:example-service-assurance-is-is".
For subservice YANG module that are directly provided by vendors, a For subservice YANG module that are directly provided by vendors, a
similar pattern can be used with the prefix being a namespace similar pattern can be used with the prefix being a namespace
controlled by the vendor. controlled by the vendor.
9.3. Module Prefix 8.3. Module Prefix
For subservice YANG modules vetted by the IETF, the module prefix For subservice YANG modules vetted by the IETF, the module prefix
should be "service-assurance-" followed by the short name. For should be "sain-" followed by the short name. For instance, "sain-
instance, "service-assurance-interface" or "service-assurance-is-is". interface" or "sain-is-is".
For subservice YANG module that are directly provided by vendors, the For subservice YANG module that are directly provided by vendors, the
same pattern can be used provided it does not conflict with an same pattern can be used provided it does not conflict with an
imported prefix. imported prefix.
9.4. Subservice Specific Identity 8.4. Subservice Specific Identity
Each auqment specific to a subservice must define an identity Each augment specific to a subservice must define an identity
representing the type of subpart or features of the network system representing the type of subpart or features of the network system
that are assured by the subservice. As required in the "ietf- that are assured by the subservice. As required in the "ietf-
service-assurance" module (see Section 4.3), that identity must be service-assurance" module (see Section 3.3), that identity must be
based on the "subservice-idty" identity. based on the "subservice-idty" identity.
For subservice YANG modules vetted by the IETF, the subservice For subservice YANG modules vetted by the IETF, the subservice
specific identity should be the short name of the subservice followed specific identity should be the short name of the subservice followed
by "-idty". For instance, "interface-idty" or "is-is-identity". by "-idty". For instance, "interface-idty" or "is-is-identity".
For subservice YANG module that are directly provided by vendors, the For subservice YANG module that are directly provided by vendors, the
same pattern can be used. same pattern can be used.
9.5. Parameters 8.5. Parameters
For subservice YANG modules vetted by the IETF, the parameters For subservice YANG modules vetted by the IETF, the parameters
specific to the subservice should be placed in a container named specific to the subservice should be placed in a container named
"parameters". That container must be used to augment the "parameter" "parameters". That container must be used to augment the "parameter"
choice from the module "ietf-service-assurance" (see Section 4.3 and choice from the module "ietf-service-assurance" (see Section 3.3 and
that augment must be guarded so that it is effective only for that augment must be guarded so that it is effective only for
subservice instance whose type is the subservice specific identity subservice instance whose type is the subservice specific identity
from Section 9.4. from Section 8.4.
For subservice YANG module that are directly provided by vendors, the For subservice YANG module that are directly provided by vendors, the
same pattern can be used. same pattern can be used.
10. Security Considerations 9. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a 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]
skipping to change at page 35, line 26 skipping to change at page 36, line 21
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
* /subservices/subservice/type * /subservices/subservice/type
* /subservices/subservice/id * /subservices/subservice/id
* /subservices/subservice/under-maintenance * /subservices/subservice/under-maintenance
* /subservices/subservice/maintenance-contact * /subservices/subservice/maintenance-contact
11. IANA Considerations 10. IANA Considerations
11.1. The IETF XML Registry 10.1. The IETF XML Registry
This document registers two URIs in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registrations are Following the format in [RFC3688], the following registrations are
requested: requested:
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF 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 NETCONF WG of the IETF. Registrant Contact: The NETCONF 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 NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
11.2. The YANG Module Names Registry 10.2. The YANG Module Names Registry
This document registers three YANG modules in the YANG Module Names This document registers three YANG modules in the YANG Module Names
registry [RFC7950]. Following the format in [RFC7950], the the registry [RFC7950]. Following the format in [RFC7950], the the
following registrations are requested: following 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: inc prefix: inc
reference: RFC XXXX reference: RFC XXXX
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: inc prefix: inc
reference: RFC XXXX reference: RFC XXXX
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-interface
prefix: inc prefix: inc
reference: RFC XXXX reference: RFC XXXX
12. Open Issues 11. Open Issues
-None -None
13. References 12. References
13.1. Normative References 12.1. Normative References
[I-D.ietf-opsawg-service-assurance-architecture] [I-D.ietf-opsawg-service-assurance-architecture]
Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V., Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V.,
and T.A. Arumugam, "draft-claise-opsawg-service-assurance- and T.A. Arumugam, "draft-claise-opsawg-service-assurance-
architecture", 2020. architecture", 2020.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 37, line 10 skipping to change at page 38, line 10
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network 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.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
13.2. Informative References 12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", 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>.
skipping to change at page 38, line 14 skipping to change at page 39, line 14
We provide below the contents of the file We provide below 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 of configuration data that models the Figure 2 of
[I-D.ietf-opsawg-service-assurance-architecture]. The instance can [I-D.ietf-opsawg-service-assurance-architecture]. The instance can
be validated with yangson by using the invocation "yangson -v be validated with yangson by using the invocation "yangson -v
example_configuration_instance.json ietf-service-assurance- example_configuration_instance.json ietf-service-assurance-
library.json", assuming all the files (YANG and JSON) defined in this library.json", assuming all the files (YANG and JSON) defined in this
draft reside in the current folder. draft reside in the current folder.
<CODE BEGINS> file "example_configuration_instance.json"
{ {
"ietf-service-assurance:subservices": { "ietf-service-assurance:subservices": {
"subservice": [ "subservice": [
{ {
"type": "service-instance-idty", "type": "service-instance-idty",
"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"
}, },
skipping to change at page 38, line 39 skipping to change at page 39, line 37
"type": "ietf-service-assurance-interface:interface-idty", "type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/tunnel0", "id": "interface/peer1/tunnel0",
"dependency-type": "impacting-dependency" "dependency-type": "impacting-dependency"
}, },
{ {
"type": "ietf-service-assurance-interface:interface-idty", "type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer2/tunnel9", "id": "interface/peer2/tunnel9",
"dependency-type": "impacting-dependency" "dependency-type": "impacting-dependency"
}, },
{ {
"type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", "type":
"example-service-assurance-ip-connectivity:ip-connectivity-idty",
"id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
"dependency-type": "impacting-dependency" "dependency-type": "impacting-dependency"
} }
] ]
} }
}, },
{ {
"type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty", "type":
"example-service-assurance-ip-connectivity:ip-connectivity-idty",
"id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2", "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
"ietf-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-idty", "type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/physical0", "id": "interface/peer1/physical0",
"dependency-type": "impacting-dependency" "dependency-type": "impacting-dependency"
}, },
{ {
"type": "ietf-service-assurance-interface:interface-idty", "type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer2/physical5", "id": "interface/peer2/physical5",
"dependency-type": "impacting-dependency" "dependency-type": "impacting-dependency"
}, },
{ {
"type": "ietf-service-assurance-is-is:is-is-idty", "type": "example-service-assurance-is-is:is-is-idty",
"id": "is-is/instance1", "id": "is-is/instance1",
"dependency-type": "impacting-dependency" "dependency-type": "impacting-dependency"
} }
] ]
} }
}, },
{ {
"type": "ietf-service-assurance-is-is:is-is-idty", "type": "example-service-assurance-is-is:is-is-idty",
"id": "is-is/instance1", "id": "is-is/instance1",
"ietf-service-assurance-is-is:parameters": { "example-service-assurance-is-is:parameters": {
"instance-name": "instance1" "instance-name": "instance1"
} }
}, },
{ {
"type": "ietf-service-assurance-interface:interface-idty", "type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/tunnel0", "id": "interface/peer1/tunnel0",
"ietf-service-assurance-interface:parameters": { "ietf-service-assurance-interface:parameters": {
"device": "Peer1", "device": "Peer1",
"interface": "tunnel0" "interface": "tunnel0"
}, },
skipping to change at page 41, line 23 skipping to change at page 42, line 23
"type": "ietf-service-assurance-device:device-idty", "type": "ietf-service-assurance-device:device-idty",
"id": "interface/peer2", "id": "interface/peer2",
"ietf-service-assurance-device:parameters": { "ietf-service-assurance-device:parameters": {
"device": "Peer2" "device": "Peer2"
} }
} }
] ]
} }
} }
<CODE ENDS>
Appendix B. YANG Library for Service Assurance Appendix B. YANG Library for Service Assurance
This section provides the JSON encoding of the YANG library [RFC7895] This section provides the JSON encoding of the YANG library [RFC7895]
listing all modules defined in this draft and their dependencies. listing all modules defined in this draft and their dependencies.
This library can be used to validate data instances using yangson, as This library can be used to validate data instances using yangson, as
explained in the previous section. explained in the previous section.
<CODE BEGINS> file "ietf-service-assurance-library.json"
{ {
"ietf-yang-library:modules-state": { "ietf-yang-library:modules-state": {
"module-set-id": "ietf-service-assurance@2020-01-13", "module-set-id": "ietf-service-assurance@2022-04-07",
"module": [ "module": [
{ {
"name": "ietf-service-assurance", "name": "ietf-service-assurance",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance", "namespace":
"revision": "2021-06-28", "urn:ietf:params:xml:ns:yang:ietf-service-assurance",
"revision": "2022-04-07",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-service-assurance-device", "name": "ietf-service-assurance-device",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", "namespace":
"revision": "2021-06-28", "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device",
"revision": "2022-04-07",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-service-assurance-interface", "name": "ietf-service-assurance-interface",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface", "namespace":
"revision": "2021-06-28", "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface",
"revision": "2022-04-07",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "example-service-assurance-device-acme", "name": "example-service-assurance-device-acme",
"namespace": "urn:example:example-service-assurance-device-acme", "namespace":
"revision": "2021-06-28", "urn:example:example-service-assurance-device-acme",
"revision": "2022-04-07",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-service-assurance-is-is", "name": "example-service-assurance-is-is",
"namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-is-is", "namespace": "urn:example:example-service-assurance-is-is",
"revision": "2021-06-28", "revision": "2022-04-07",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-service-assurance-ip-connectivity", "name": "example-service-assurance-ip-connectivity",
"namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-ip-connectivity", "namespace":
"revision": "2021-06-28", "urn:example:example-service-assurance-ip-connectivity",
"revision": "2022-04-07",
"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": "2021-04-14",
"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": "2021-02-22",
"conformance-type": "import" "conformance-type": "import"
} }
] ]
} }
} }
<CODE ENDS>
Appendix C. Changes between revisions Appendix C. Changes between revisions
v03 - v04
* Fix YANG errors
* Change is-is and ip-connectivity subservices from ietf to example.
* Mention that models are NMDA compliant
* Fix typos, reformulate for clarity
v02 - v03 v02 - v03
* Change counter32 to counter64 to avoid resetting too frequently * Change counter32 to counter64 to avoid resetting too frequently
* Explain why relation between health-score and symptom's health- * Explain why relation between health-score and symptom's health-
score-weight is not defined and how it could be defined score-weight is not defined and how it could be defined
v01 - v02 v01 - v02
* Explicitly represent the fact that the health-score could not be * Explicitly represent the fact that the health-score could not be
skipping to change at page 43, line 25 skipping to change at page 44, line 37
* Added data instance examples and validation procedure * Added data instance examples and validation procedure
* Added the "parameters" container in the interface YANG module to * Added the "parameters" container in the interface YANG module to
correct a bug. 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 and Charles Eckel for their reviews. Stephane Litkowski, Charles Eckel, Mohamed Boucadair and Tom Petch
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
 End of changes. 205 change blocks. 
855 lines changed or deleted 981 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/