draft-ietf-opsawg-service-assurance-yang-01.txt   draft-ietf-opsawg-service-assurance-yang-02.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: January 3, 2022 P. Lucente Expires: 8 July 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.
July 2, 2021 4 January 2022
YANG Modules for Service Assurance YANG Modules for Service Assurance
draft-ietf-opsawg-service-assurance-yang-01 draft-ietf-opsawg-service-assurance-yang-02
Abstract Abstract
This document proposes YANG modules for the Service Assurance for This document proposes YANG modules for the Service Assurance for
Intent-based Networking Architecture. Intent-based Networking Architecture.
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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 3, 2022. This Internet-Draft will expire on 8 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3
4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4
4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7
5. Subservice Extension: ietf-service-assurance-device YANG 5. Subservice Extension: ietf-service-assurance-device YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 module . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 14 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15
5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16
6. Subservice Extension: ietf-service-assurance-interface YANG 6. Subservice Extension: ietf-service-assurance-interface YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 module . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18
6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20
7. Vendor-specific Subservice Extension: example-service- 7. Vendor-specific Subservice Extension:
assurance-device-acme YANG module . . . . . . . . . . . . . . 22 example-service-assurance-device-acme YANG module . . . . 22
7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22
7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 24
7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24
8. Further Extensions: IP Connectivity and IS-IS subservices . . 26 8. Further Extensions: IP Connectivity and IS-IS subservices . . 26
8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26 8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26
8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26 8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26
8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 26 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 27
8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28 8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28
8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30 8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30
9. Guidelines for Specific Subservice Extension . . . . . . . . 31 9. Guidelines for Specific Subservice Extension . . . . . . . . 32
9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32
9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32 9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32
9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 32 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 33
9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33 9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33
9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34 11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34
11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34 11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Example of YANG instances . . . . . . . . . . . . . 36 Appendix A. Example of YANG instances . . . . . . . . . . . . . 36
Appendix B. YANG Library for Service Assurance . . . . . . . . . 40 Appendix B. YANG Library for Service Assurance . . . . . . . . . 40
skipping to change at page 3, line 33 skipping to change at page 3, line 39
2. Introduction 2. Introduction
The "Service Assurance for Intent-based Networking Architecture" The "Service Assurance for Intent-based Networking Architecture"
draft-ietf-opsawg-service-assurance-architecture, specifies the draft-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:
o machine readable * machine readable
o vendor independent * vendor independent
o augmentable * augmentable
3. YANG Models Overview 3. 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:
o Assurance graph configuration: * Assurance graph configuration:
* Subservices: configure a set of subservices to assure, by - Subservices: configure a set of subservices to assure, by
specifying their types and parameters. 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.
o 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 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.
skipping to change at page 5, line 21 skipping to change at page 5, line 21
+--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? uint8 +--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]
skipping to change at page 5, line 43 skipping to change at page 5, line 43
+--rw id -> /subservices/subservice[type=current()/../type]/id +--rw id -> /subservices/subservice[type=current()/../type]/id
+--rw dependency-type? identityref +--rw dependency-type? identityref
4.2. Concepts 4.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:
o DeviceHealthy: whether a device is healthy, and if not, what are * DeviceHealthy: whether a device is healthy, and if not, what are
the symptoms. Potential symptoms are "CPU overloaded", "Out of the symptoms. Potential symptoms are "CPU overloaded", "Out of
RAM", or "Out of TCAM". RAM", or "Out of TCAM".
o ConnectivityHealthy: given two IP addresses owned by two devices, * ConnectivityHealthy: given two IP addresses owned by two devices,
what is the quality of the connection between them. Potential what is the quality of the connection between them. Potential
symptoms are "No route available" or "ECMP Imbalance". symptoms are "No route available" or "ECMP Imbalance".
The first example is a subservice representing a subpart of the The first example is a subservice representing a subpart of the
network system, while the second is a subservice representing a network system, while the second is a subservice representing a
feature of the network, In both cases, these subservices might depend feature of the network, In both cases, these subservices might depend
on other subservices, for instance, the connectivity might depend on on other subservices, for instance, the connectivity might depend on
a subservice representing the routing mechanism and on a subservice a subservice representing the routing mechanism and on a subservice
representing ECMP. representing ECMP.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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 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:
o A type: identity inheriting of the base identity for subservice, * A type: identity inheriting of the base identity for subservice,
o An id: string uniquely identifying the subservice among those with * An id: string uniquely identifying the subservice among those with
the same identity, the same identity,
o One or more parameters, which should be specified in an augmenting * One or more parameters, which should be specified in an augmenting
model, as described in the next sections. model, as described in the next sections.
The type and id uniquely identify a given subservice. They are used The type and id uniquely identify a given subservice. They are used
to indicate the dependencies. Dependencies have types as well. Two to indicate the dependencies. Dependencies have types as well. Two
types are specified in the model: types are specified in the model:
o Impacting: such a dependency indicates an impact on the health of * Impacting: such a dependency indicates an impact on the health of
the dependent, the dependent,
o Informational: such a dependency might explain why the dependent * Informational: such a dependency might explain why the dependent
has issues but does not impact its health. has issues but does not impact its health.
To illustrate the difference between "impacting" and "informational", To illustrate the difference between "impacting" and "informational",
consider the subservice InterfaceHealthy, representing a network consider the subservice InterfaceHealthy, representing a network
interface. If the device to which the network interface belongs goes interface. If the device to which the network interface belongs goes
down, the network interface will transition to a down state as well. down, the network interface will transition to a down state as well.
Therefore, the dependency of InterfaceHealthy towards DeviceHealthy Therefore, the dependency of InterfaceHealthy towards DeviceHealthy
is "impacting". On the other hand, as a the dependency towards the is "impacting". On the other hand, as a the dependency towards the
ECMPLoad subservice, which checks that the load between ECMP remains ECMPLoad subservice, which checks that the load between ECMP remains
ce remains stable throughout time, is only "informational". Indeed, ce remains stable throughout time, is only "informational". Indeed,
skipping to change at page 7, line 29 skipping to change at page 7, line 39
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 4.3. YANG Module
<CODE BEGINS> file "ietf-service-assurance@2021-06-28.yang" <CODE BEGINS> file "ietf-service-assurance@2022-01-04.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 service-assurance;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
skipping to change at page 8, line 42 skipping to change at page 8, line 50
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: TO DO:
- Better type (IETF or OC) for device-id, interface-id, etc. - Better type (IETF or OC) for device-id, interface-id, etc.
- Have a YANG module for IETF and one for OC?"; - Have a YANG module for IETF and one for OC?";
revision 2022-01-04 {
description
"Explicitely model a missing value";
reference
"RFC xxxx: Title to be completed";
}
revision 2021-06-28 { 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: Title to be completed";
} }
revision 2020-01-13 { revision 2020-01-13 {
description description
"Added the maintenance window concept."; "Added the maintenance window concept.";
reference reference
skipping to change at page 11, line 12 skipping to change at page 11, line 28
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 if more info are needed (i.e. a percentage) depending on the dependency type.
} }
leaf assurance-graph-version { leaf assurance-graph-version {
type yang:counter32; type yang:counter32;
mandatory true;
config false; config false;
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 version, after the changes
(dependencies and/or maintenance windows parameters) are applied to the subservice(s)."; (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;
mandatory true;
config false; config false;
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 changes (dependencies
and/or maintenance windows parameters) are applied to the subservice(s). These date and time and/or maintenance windows parameters) are applied to the subservice(s). These date and time
must be more recent or equal compared to the more recent value of any changed subservices must be more recent or equal compared to the more recent value of any changed subservices
last-change"; last-change";
} }
container subservices { container subservices {
description description
"Root container for the subservices."; "Root container for the subservices.";
list subservice { list subservice {
skipping to change at page 13, line 19 skipping to change at page 13, line 34
leaf instance-name { leaf instance-name {
type string; type string;
mandatory true; mandatory true;
description description
"Name of the instance for that service."; "Name of the instance for that service.";
} }
} }
// Other modules can augment their own cases into here // Other modules can augment their own cases into here
} }
leaf health-score { leaf health-score {
type uint8 { type union {
range "0 .. 100"; type uint8 {
range "0 .. 100";
}
type enumeration {
enum missing {
value -1;
description
"Explictly represent the fact that the health score is
missing. This could be used when metrics crucial to
establish the health score are not collected anymore.";
}
}
} }
config false; 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 that
subservice is healthy. A value of 0 means that the subservice is subservice is healthy. A value of 0 means that the subservice is
broken. A value between 0 and 100 means that the subservice is broken. A value between 0 and 100 means that the subservice is
degraded."; degraded.";
} }
leaf symptoms-history-start { leaf symptoms-history-start {
type yang:date-and-time; type yang:date-and-time;
skipping to change at page 15, line 24 skipping to change at page 15, line 35
+--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) | +--:(service-assurance-device:parameters)
| +--rw service-assurance-device:parameters | +--rw service-assurance-device:parameters
| +--rw service-assurance-device:device string | +--rw service-assurance-device:device string
+--ro health-score? uint8 +--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]
skipping to change at page 19, line 28 skipping to change at page 19, line 28
| | +--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) | +--:(service-assurance-interface:parameters)
| | +--rw service-assurance-interface:parameters | | +--rw service-assurance-interface:parameters
| | +--rw service-assurance-interface:device string | | +--rw service-assurance-interface:device string
| | +--rw service-assurance-interface:interface string | | +--rw service-assurance-interface:interface string
| +--:(service-assurance-device:parameters) | +--:(service-assurance-device:parameters)
| +--rw service-assurance-device:parameters | +--rw service-assurance-device:parameters
| +--rw service-assurance-device:device string | +--rw service-assurance-device:device string
+--ro health-score? uint8 +--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]
skipping to change at page 23, line 32 skipping to change at page 23, line 32
| | +--rw service-assurance-device:parameters | | +--rw service-assurance-device:parameters
| | +--rw service-assurance-device:device string | | +--rw service-assurance-device:device string
| +--:(example-service-assurance-device-acme:parameters) | +--:(example-service-assurance-device-acme:parameters)
| | +--rw 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:device string
| | +--rw example-service-assurance-device-acme:acme-specific-parameter string | | +--rw example-service-assurance-device-acme:acme-specific-parameter string
| +--:(service-assurance-interface:parameters) | +--:(service-assurance-interface:parameters)
| +--rw service-assurance-interface:parameters | +--rw service-assurance-interface:parameters
| +--rw service-assurance-interface:device string | +--rw service-assurance-interface:device string
| +--rw service-assurance-interface:interface string | +--rw service-assurance-interface:interface string
+--ro health-score? uint8 +--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]
skipping to change at page 27, line 39 skipping to change at page 27, line 48
| | +--rw service-assurance-device:parameters | | +--rw service-assurance-device:parameters
| | +--rw service-assurance-device:device string | | +--rw service-assurance-device:device string
| +--:(example-service-assurance-device-acme:parameters) | +--:(example-service-assurance-device-acme:parameters)
| | +--rw 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:device string
| | +--rw example-service-assurance-device-acme:acme-specific-parameter string | | +--rw example-service-assurance-device-acme:acme-specific-parameter string
| +--:(service-assurance-interface:parameters) | +--:(service-assurance-interface:parameters)
| +--rw service-assurance-interface:parameters | +--rw service-assurance-interface:parameters
| +--rw service-assurance-interface:device string | +--rw service-assurance-interface:device string
| +--rw service-assurance-interface:interface string | +--rw service-assurance-interface:interface string
+--ro health-score? uint8 +--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]
skipping to change at page 34, line 7 skipping to change at page 34, line 18
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/ creatable/deletable (i.e., config true, which is the writable/ creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
o /subservices/subservice/type * /subservices/subservice/type
o /subservices/subservice/id * /subservices/subservice/id
o /subservices/subservice/under-maintenance * /subservices/subservice/under-maintenance
o /subservices/subservice/maintenance-contact * /subservices/subservice/maintenance-contact
11. IANA Considerations 11. IANA Considerations
11.1. The IETF XML Registry 11.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
skipping to change at page 35, line 29 skipping to change at page 35, line 29
12. Open Issues 12. Open Issues
-None -None
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-opsawg-service-assurance-architecture] [I-D.ietf-opsawg-service-assurance-architecture]
Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V.,
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>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
skipping to change at page 36, line 37 skipping to change at page 36, line 37
<https://www.rfc-editor.org/info/rfc7895>. <https://www.rfc-editor.org/info/rfc7895>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
13.3. URIs
[1] https://yangson.labs.nic.cz/
Appendix A. Example of YANG instances Appendix A. Example of YANG instances
This section contains examples of YANG instances that conform to the This section contains examples of YANG instances that conform to the
YANG modules. The validity of these data instances has been checked YANG modules. The validity of these data instances has been checked
using yangson [1]. Yangson requires a YANG library [RFC7895] to using yangson (https://yangson.labs.nic.cz/). Yangson requires a
define the complete model against which the data instance must be YANG library [RFC7895] to define the complete model against which the
validated. We provide in Appendix B the JSON library file, named data instance must be validated. We provide in Appendix B the JSON
"ietf-service-assurance-library.json", that we used for validation. library file, named "ietf-service-assurance-library.json", that we
used for validation.
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" <CODE BEGINS> file "example_configuration_instance.json"
{ {
"ietf-service-assurance:subservices": { "ietf-service-assurance:subservices": {
skipping to change at page 41, line 46 skipping to change at page 41, line 48
] ]
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix C. Changes between revisions Appendix C. Changes between revisions
v00 - v01 v00 - v01
o Added needed subservice to model example from architecture draft * Added needed subservice to model example from architecture draft
o Added guideline section for naming models * Added guideline section for naming models
* Added data instance examples and validation procedure
o Added data instance examples and validation procedure * Added the "parameters" container in the interface YANG module to
o 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 and Charles Eckel for their reviews.
Authors' Addresses Authors' Addresses
skipping to change at page 42, line 28 skipping to change at page 42, line 30
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
Paolo Lucente Paolo Lucente
NTT NTT
Siriusdreef 70-72 Siriusdreef 70-72
Hoofddorp, WT 2132 2132 Hoofddorp
Netherlands Netherlands
Email: paolo@ntt.net Email: paolo@ntt.net
Paolo Fasano Paolo Fasano
TIM S.p.A TIM S.p.A
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
10148 Torino 10148 Torino
Italy Italy
Email: paolo2.fasano@telecomitalia.it Email: paolo2.fasano@telecomitalia.it
Thangam Arumugam Thangam Arumugam
Cisco Systems, Inc. Cisco Systems, Inc.
Milpitas (California) Milpitas (California),
United States United States
Email: tarumuga@cisco.com Email: tarumuga@cisco.com
 End of changes. 55 change blocks. 
69 lines changed or deleted 81 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/