draft-ietf-opsawg-service-assurance-yang-00.txt   draft-ietf-opsawg-service-assurance-yang-01.txt 
OPSAWG B. Claise OPSAWG B. Claise
Internet-Draft Huawei Internet-Draft J. Quilbeuf
Intended status: Standards Track J. Quilbeuf Intended status: Standards Track Huawei
Expires: November 22, 2021 Independent Expires: January 3, 2022 P. Lucente
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.
May 21, 2021 July 2, 2021
YANG Modules for Service Assurance YANG Modules for Service Assurance
draft-ietf-opsawg-service-assurance-yang-00 draft-ietf-opsawg-service-assurance-yang-01
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 38 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 November 22, 2021. This Internet-Draft will expire on January 3, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 16
described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7
5. Subservice Extension: ietf-service-assurance-device YANG 5. Subservice Extension: ietf-service-assurance-device YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 13 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 14
5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16
6. Subservice Extension: ietf-service-assurance-interface YANG 6. Subservice Extension: ietf-service-assurance-interface YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 17 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18
6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20
7. Vendor-specific Subservice Extension: example-service- 7. Vendor-specific Subservice Extension: example-service-
assurance-device-acme YANG module . . . . . . . . . . . . . . 19 assurance-device-acme YANG module . . . . . . . . . . . . . . 22
7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 20 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22
7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 23
7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Further Extensions: IP Connectivity and IS-IS subservices . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26
9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 24 8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26
9.2. The YANG Module Names Registry . . . . . . . . . . . . . 25 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 26
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 9. Guidelines for Specific Subservice Extension . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 26 9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes between revisions . . . . . . . . . . . . . 26 9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33
9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34
11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Example of YANG instances . . . . . . . . . . . . . 36
Appendix B. YANG Library for Service Assurance . . . . . . . . . 40
Appendix C. Changes between revisions . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terms used in this document are defined in draft-claise-opsawg- The terms used in this document are defined in
service-assurance-architecture IETF draft. [I-D.ietf-opsawg-service-assurance-architecture]
2. Introduction 2. Introduction
The "Service Assurance for Intent-based Networking Architecture" The "Service Assurance for Intent-based Networking Architecture"
draft-claise-opsawg-service-assurance-architecture, specifies the draft-ietf-opsawg-service-assurance-architecture, specifies the
framework 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 o machine readable
o vendor independent o vendor independent
o augmentable o augmentable
skipping to change at page 4, line 10 skipping to change at page 4, line 19
subservices, along with their type. subservices, along with their type.
o Assurance telemetry: export the health status of the subservices, o 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, example-service-assurance-device-acme, extends The third YANG module, ietf-service-assurance-device, is another
the ietf-service-assurance-device module as an example to add support example that extends the ietf-service-assurance-device module. This
for the subservice DeviceHealthy, with specifics for the fictional extension adds support for the subservice InterfaceHealthy.
ACME Corporation. Additional vendor-specific parameters might be
added the same way. The fourth YANG module, example-service-assurance-device-acme,
extends the ietf-service-assurance-device module as an example to add
support for the subservice DeviceHealthy, with specifics for the
fictional ACME Corporation. Additional vendor-specific parameters
might be added the same way.
Finally, the modules ietf-service-assurance-ip-connectivity and ietf-
service-assurance-is-is are provided to completely model the example
from the SAIN architecture draft
[I-D.ietf-opsawg-service-assurance-architecture].
4. Base ietf-service-assurance YANG module 4. Base ietf-service-assurance YANG module
4.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 data model. ietf-service-assurance data model.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter32 +--ro assurance-graph-version yang:counter32
skipping to change at page 4, line 37 skipping to change at page 5, line 19
+--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? uint8 +--ro health-score? uint8
+--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
skipping to change at page 5, line 27 skipping to change at page 6, line 12
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.
The symptoms are listed for each subservice. Each symptom is The status of each subservice contains a list of symptoms. Each
specified by a unique id and contains a health-score-weight (the symptom is specified by a unique id and contains a health-score-
impact to the health score incurred by this symptom), a label (text weight (the impact to the health score incurred by this symptom), a
describing what the symptom is), and dates and times at which the label (text describing what the symptom is), and dates and times at
symptom was detected and stopped being detected. While the unique id which the symptom was detected and stopped being detected. While the
is sufficient as an unique key list, the start-date-time second key unique id is sufficient as an unique key list, the start-date-time
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.
In order to declare a subservice MUST provide: A subservice declaration MUST provide:
o A type: identity inheriting of the base identity for subservice, o A type: identity inheriting of the base identity for subservice,
o An id: string uniquely identifying the subservice among those with o An id: string uniquely identifying the subservice among those with
the same identity, the same identity,
o Some parameters, which should be specified in an augmenting model, o One or more parameters, which should be specified in an augmenting
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 o 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 o 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.
skipping to change at page 6, line 33 skipping to change at page 7, line 17
Service instances MUST be modeled as a particular type of subservice Service instances MUST be modeled as a particular type of subservice
with two parameters, a type and an instance name. The type is the with two parameters, a type and an instance name. The type is the
name of the service defined in the network orchestrator, for instance name of the service defined in the network orchestrator, for instance
"point-to-point-l2vpn". The instance name is the name assigned to "point-to-point-l2vpn". The instance name is the name assigned to
the particular instance that we are assuring, for instance the name the particular instance that we are assuring, for instance the name
of the customer using that instance. of the customer using that instance.
The "under-maintenance" and "maintenance-contact" flags inhibit the The "under-maintenance" and "maintenance-contact" flags inhibit the
emission of symptoms for that subservice and subservices that depend emission of symptoms for that subservice and subservices that depend
on them. See Section 3.7 of on them. See Section 3.7 of
[draft-claise-opsawg-service-assurance-architecture] for a more [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed
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 4.3. YANG Module
<CODE BEGINS> file "ietf-service-assurance@2020-01-13.yang" <CODE BEGINS> file "ietf-service-assurance@2021-06-28.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;
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Benoit Claise <mailto:bclaise@cisco.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jquilbeu@cisco.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 SAIN
(Service Assurance for Intent-based Networking) architecture. (Service Assurance for Intent-based Networking) architecture.
The subservices hierarchically organised by dependencies constitute an The subservices hierarchically organised by dependencies constitute an
assurance graph. This module should be supported by an assurance agent, assurance graph. This module should be supported by an assurance agent,
able to interact with the devices in order to produce a health status able to interact with the devices in order to produce a health status
and symptoms for each subservice in the assurance graph. 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 specifying
their types and parameters. their types and parameters.
* dependencies: configure the dependencies between the subservices, * dependencies: configure the dependencies between the subservices,
along with their type. along with their type.
* Assurance telemetry: export the health status of the subservices, along * Assurance telemetry: export the health status of the subservices, along
with the observed symptoms. 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)2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Copyright (c)2021 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 Redistribution and use in source and binary forms, with or
RFC itself for full legal notices. without modification, is permitted pursuant to, and subject
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).
TO DO: This version of this YANG module is part of RFC XXXX; see the
- Better type (IETF or OC) for device-id, interface-id, etc. RFC itself for full legal notices.
- Have a YANG module for IETF and one for OC?"; TO DO:
- Better type (IETF or OC) for device-id, interface-id, etc.
- Have a YANG module for IETF and one for OC?";
revision 2021-06-28 {
description
"Made service-instance parameters mandatory.";
reference
"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
"RFC xxxx: Title to be completed"; "RFC xxxx: Title to be completed";
}
}
revision 2019-11-16 { revision 2019-11-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: Title to be completed";
} }
identity subservice-idty { identity subservice-idty {
description description
"Root identity for all subservice types."; "Root identity for all subservice types.";
skipping to change at page 11, line 24 skipping to change at page 12, line 15
} }
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 subservice is to
be displayed on a human interface."; 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 subservice is under
maintenance. Under this circumstance, the subservice symptoms and the maintenance. Under this circumstance, the subservice symptoms and the
symptoms of its dependencies in the assurance graph should not be taken symptoms of its dependencies in the assurance graph should not be taken
into account. Instead, the subservice should send a 'Under Maintenance' 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 the
maintenance-contact variable. 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 the
resource that changed the under-maintenance value to 'true. resource that changed the under-maintenance value to 'true.
It is suggested that this name contain one or more of the following:
IP address, management station name, network manager's name, location,
or phone number. In some cases the agent itself will be the owner of
an entry. In these cases, this string shall be set to a string
starting with 'monitor'.";
It is suggested that this name contain one or more of the following:
IP address, management station name, network manager's name, location,
or phone number. In some cases the agent itself will be the owner of
an entry. In these cases, this string shall be set to a string
starting with 'monitor'.";
} }
choice parameter { 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, 'service-assurance: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;
description "Name of the service."; mandatory true;
description
"Name of the service.";
} }
leaf instance-name{ leaf instance-name {
type string; type string;
description "Name of the instance for that service."; mandatory true;
description
"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 uint8 {
range "0 .. 100"; range "0 .. 100";
} }
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;
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 that
were removed due to a garbage collection process."; 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 key is not
necessary per se, this would get the entries sorted by start-date-time necessary per se, this would get the entries sorted by start-date-time
for easy consumption."; 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.";
skipping to change at page 13, line 32 skipping to change at page 14, line 27
<CODE ENDS> <CODE ENDS>
5. Subservice Extension: ietf-service-assurance-device YANG module 5. Subservice Extension: ietf-service-assurance-device YANG module
5.1. Tree View 5.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-device 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 /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw device-idty +--rw parameters
+--rw device? string +--rw device string
5.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 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:counter32 +--ro assurance-graph-version yang:counter32
+--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:device-idty) | +--:(service-assurance-device:parameters)
| +--rw service-assurance-device:device-idty | +--rw service-assurance-device:parameters
| +--rw service-assurance-device:device? string | +--rw service-assurance-device:device string
+--ro health-score? uint8 +--ro health-score? uint8
+--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 -> /subservices/subservice/type
skipping to change at page 14, line 48 skipping to change at page 15, line 48
5.3. Concepts 5.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 device-idty is For our DeviceHealthy subservice definition, the new identity device-
specified, as an inheritance from the base identity for subservices. idty is specified, as an inheritance from the base identity for
This indicates to the assurance agent that we are now assuring the subservices. This indicates to the assurance agent that we are now
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 5.4. YANG Module
<CODE BEGINS> file "ietf-service-assurance-device@2020-01-13.yang" <CODE BEGINS> file "ietf-service-assurance-device@2021-06-28.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 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device";
prefix service-assurance-device; prefix service-assurance-device;
import ietf-service-assurance { import ietf-service-assurance {
prefix "service-assurance"; prefix service-assurance;
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Benoit Claise <mailto:bclaise@cisco.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jquilbeu@cisco.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) 2020 IETF Trust and the persons identified as Copyright (c) 2021 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 Simplified 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 {
description
"Renamed the container for parameters.";
reference
"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
"RFC xxxx: Title to be completed"; "RFC xxxx: Title to be completed";
} }
revision 2019-11-16 { revision 2019-11-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: Title to be completed";
} }
identity device-idty { identity device-idty {
base service-assurance:subservice-idty; base service-assurance:subservice-idty;
description "Network Device is healthy."; description
"Network Device is healthy.";
} }
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
description description
"Specify the required parameters for a new subservice type"; "Specify the required parameters for a new subservice type";
container device-idty{ container parameters {
when "derived-from-or-self(../service-assurance:type, 'device-idty')"; when "derived-from-or-self(../service-assurance:type, 'device-idty')";
description description
"Specify the required parameters for the device-idty subservice type"; "Specify the required parameters for the device-idty subservice type";
leaf device {
leaf device { type string;
type string; mandatory true;
description "The device to monitor."; description
} "The device to monitor.";
} }
}
} }
} }
<CODE ENDS> <CODE ENDS>
6. Subservice Extension: ietf-service-assurance-interface YANG module 6. Subservice Extension: ietf-service-assurance-interface YANG module
6.1. Tree View 6.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
skipping to change at page 17, line 6 skipping to change at page 18, line 13
<CODE ENDS> <CODE ENDS>
6. Subservice Extension: ietf-service-assurance-interface YANG module 6. Subservice Extension: ietf-service-assurance-interface YANG module
6.1. Tree View 6.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-interface data model. ietf-service-assurance-interface data model.
module: ietf-service-assurance-interface module: ietf-service-assurance-interface
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw device? string +--rw parameters
+--rw interface? string +--rw device string
+--rw interface string
6.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 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:counter32 +--ro assurance-graph-version yang:counter32
+--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:device-idty) | +--:(service-assurance-interface:parameters)
| | +--rw service-assurance-device:device-idty | | +--rw service-assurance-interface:parameters
| | +--rw service-assurance-device:device? string | | +--rw service-assurance-interface:device string
| +--:(service-assurance-interface:device) | | +--rw service-assurance-interface:interface string
| | +--rw service-assurance-interface:device? string | +--:(service-assurance-device:parameters)
| +--:(service-assurance-interface:interface) | +--rw service-assurance-device:parameters
| +--rw service-assurance-interface:interface? string | +--rw service-assurance-device:device string
+--ro health-score? uint8 +--ro health-score? uint8
+--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 -> /subservices/subservice/type
+--rw id -> /subservices/subservice[type=current()/../type]/id +--rw id -> /subservices/subservice[type=current()/../type]/id
+--rw dependency-type? identityref +--rw dependency-type? identityref
6.3. Concepts 6.3. Concepts
For our InterafaceHealthy 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 parameter are specified.
6.4. YANG Module 6.4. YANG Module
<CODE BEGINS> file "ietf-service-assurance-interface@2020-01-13.yang" <CODE BEGINS> file "ietf-service-assurance-interface@2021-06-28.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 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface";
prefix service-assurance-interface; prefix service-assurance-interface;
import ietf-service-assurance { import ietf-service-assurance {
prefix "service-assurance"; prefix 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:bclaise@cisco.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jquilbeu@cisco.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.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', Checks whether an interface 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) 2020 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) 2021 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 Redistribution and use in source and binary forms, with or
set forth in Section 4.c of the IETF Trust's Legal Provisions without modification, is permitted pursuant to, and subject
Relating to IETF Documents to the license terms contained in, the Simplified BSD License
(https://trustee.ietf.org/license-info). 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 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 {
description
"Regroup parameters in a container.";
reference
"RFC xxxx: Title to be completed";
}
revision 2020-01-13 { revision 2020-01-13 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: Title to be completed";
} }
identity interface-idty { identity interface-idty {
base service-assurance:subservice-idty; base service-assurance:subservice-idty;
description "Checks whether an interface is healthy."; description
"Checks whether an interface is healthy.";
} }
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
when "derived-from-or-self(service-assurance:type, 'interface-idty')"; description
description "Specify the required parameters for the interface-idty subservice type";
"Specify the required parameters for the interface-idty subservice type"; container parameters {
when "derived-from-or-self(../service-assurance:type, 'interface-idty')";
leaf device { description
type string; "Required parameters for the interface-idty subservice type";
description "Device supporting the interface."; leaf device {
} type string;
leaf interface { mandatory true;
type string; description
description "Name of the interface."; "Device supporting the interface.";
} }
leaf interface {
type string;
mandatory true;
description
"Name of the interface.";
}
}
} }
} }
<CODE ENDS> <CODE ENDS>
7. Vendor-specific Subservice Extension: example-service-assurance- 7. Vendor-specific Subservice Extension: example-service-assurance-
device-acme YANG module device-acme YANG module
7.1. Tree View 7.1. Tree View
skipping to change at page 20, line 6 skipping to change at page 22, line 14
7. Vendor-specific Subservice Extension: example-service-assurance- 7. Vendor-specific Subservice Extension: example-service-assurance-
device-acme YANG module device-acme YANG module
7.1. Tree View 7.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 /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw acme-device-idty +--rw parameters
+--rw device? string +--rw device string
+--rw acme-specific-parameter? string +--rw acme-specific-parameter string
7.2. Complete Tree View 7.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:counter32 +--ro assurance-graph-version yang:counter32
+--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:device-idty) | +--:(service-assurance-device:parameters)
| | +--rw service-assurance-device:device-idty | | +--rw service-assurance-device:parameters
| | +--rw service-assurance-device:device? string | | +--rw service-assurance-device:device string
| +--:(service-assurance-interface:device) | +--:(example-service-assurance-device-acme:parameters)
| | +--rw service-assurance-interface:device? string | | +--rw example-service-assurance-device-acme:parameters
| +--:(service-assurance-interface:interface) | | +--rw example-service-assurance-device-acme:device string
| | +--rw service-assurance-interface:interface? string | | +--rw example-service-assurance-device-acme:acme-specific-parameter string
| +--:(example-service-assurance-device-acme:acme-device-idty) | +--:(service-assurance-interface:parameters)
| +--rw example-service-assurance-device-acme:acme-device-idty | +--rw service-assurance-interface:parameters
| +--rw example-service-assurance-device-acme:device? string | +--rw service-assurance-interface:device string
| +--rw example-service-assurance-device-acme:acme-specific-parameter? string | +--rw service-assurance-interface:interface string
+--ro health-score? uint8 +--ro health-score? uint8
+--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 -> /subservices/subservice/type
skipping to change at page 22, line 15 skipping to change at page 24, line 15
Corporation. The new parameter is acme-specific-parameter. Corporation. The new parameter is acme-specific-parameter.
7.4. YANG Module 7.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-service-assurance-device-acme;
import ietf-service-assurance { import ietf-service-assurance {
prefix "service-assurance"; prefix service-assurance;
} }
import ietf-service-assurance-device { import ietf-service-assurance-device {
prefix "service-assurance-device"; prefix service-assurance-device;
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/> "WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Author: Benoit Claise <mailto:bclaise@cisco.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jquilbeu@cisco.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 add
support for the subservice DeviceHealthy, specific to the ACME Corporation. 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) 2019 IETF Trust and the persons identified as Copyright (c) 2021 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 Simplified 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 {
description
"Renamed the parameters container.";
reference
"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
"RFC xxxx: Title to be completed"; "RFC xxxx: Title to be completed";
} }
revision 2019-11-16 { revision 2019-11-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC xxxx: Title to be completed"; "RFC xxxx: Title to be completed";
} }
identity device-acme-idty { identity device-acme-idty {
base service-assurance-device:device-idty; base service-assurance-device:device-idty;
description "Network Device is healthy."; description
"Network Device is healthy.";
} }
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
description description
"Specify the required parameters for a new subservice type"; "Specify the required parameters for a new subservice type";
container acme-device-idty{ container parameters {
when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')"; when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')";
description description
"Specify the required parameters for the device-acme-idty subservice type"; "Specify the required parameters for the device-acme-idty subservice type";
leaf device {
type string;
mandatory true;
description
"The device to monitor.";
}
leaf acme-specific-parameter {
type string;
mandatory true;
description
"The ACME Corporation sepcific parameter.";
}
}
}
leaf device { }
type string;
description "The device to monitor.";
}
leaf acme-specific-parameter { 8. Further Extensions: IP Connectivity and IS-IS subservices
type string;
description "The ACME Corporation sepcific parameter."; 8.1. IP Connectivity Tree View
}
} The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-ip-connectivity data model.
module: ietf-service-assurance-ip-connectivity
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw parameters
+--rw device1 string
+--rw address1 inet:ip-address
+--rw device2 string
+--rw address2 inet:ip-address
To specify the connectivity that we are interested in, we specify two
IP addresses and two devices. The subservice assures that the
connectivity between IP address 1 on device 1 and IP address 2 on
device 2 is healthy.
8.2. IS-IS Tree View
The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-is-is data model.
module: ietf-service-assurance-is-is
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw parameters
+--rw instance-name string
The parameter of this subservice is the name of the IS-IS instance to
assure.
8.3. Global Tree View
The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance, ietf-service-assurance-device, example-
service-assurance-device-acme, ietf-service-assurance-ip-connectivity
and ietf-service-assurance-is-is data models.
module: ietf-service-assurance
+--ro assurance-graph-version yang:counter32
+--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? uint8
+--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-
connectivity@2021-06-28.yang"
module ietf-service-assurance-ip-connectivity {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-ip-connectivity";
prefix service-assurance-ip-connectivity;
import ietf-inet-types {
prefix inet;
}
import ietf-service-assurance {
prefix service-assurance;
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This module extends the ietf-service-assurance module to add
support for the subservice ip-connectivity.
Checks whether the ip connectivity between two ip addresses
belonging to two network devices is healthy.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
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 {
description
"Initial revision.";
reference
"RFC xxxx: Title to be completed";
}
identity ip-connectivity-idty {
base service-assurance:subservice-idty;
description
"Checks connectivity between two IP addresses.";
}
augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
description
"Specify the required parameters for the ip-connectivity-idty subservice type";
container parameters {
when "derived-from-or-self(../service-assurance:type, 'ip-connectivity-idty')";
description
"Required parameters for the ip-connectivity-idty subservice type";
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.";
}
}
} }
} }
8. Security Considerations <CODE ENDS>
8.5. IS-IS YANG Module
<CODE BEGINS> file "ietf-service-assurance-is-is@2021-06-28.yang"
module ietf-service-assurance-is-is {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is";
prefix service-assurance-is-is;
import ietf-service-assurance {
prefix service-assurance;
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
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.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
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 {
description
"Initial revision.";
reference
"RFC xxxx: Title to be completed";
}
identity is-is-idty {
base service-assurance:subservice-idty;
description
"Health of IS-IS routing protocol.";
}
augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
description
"Specify the required parameters for a new subservice type";
container parameters {
when "derived-from-or-self(../service-assurance:type, 'is-is-idty')";
description
"Specify the required parameters for the IS-IS subservice type";
leaf instance-name {
type string;
mandatory true;
description
"The instance to monitor.";
}
}
}
}
<CODE ENDS>
9. Guidelines for Specific Subservice Extension
The base YANG module defined in Section 4.3 only defines a single
type of subservices that represent service instances. As explained
above, this model is meant to be augmented so that a variety of
subservices can be used in the assurance graph. In this section, we
propose some guidelines in order to build theses extensions.
First, the specific subservice must be given an adequate unique short
name that will be used to form longer names (e.g. module name, prefix
...) appearing in the YANG module. The short name identifies the
type of subpart of feature that the subservice will represent, for
instance if the subservice will assure the health of a network
interafce then "interface" is an adequate short name. If the
subservice will assure the IS-IS routing protocol, then "is-is" is an
adequate short name. The short name must be in kebab-case.
In this section, by subservice YANG module, we mean "YANG module that
extends ieft-service-assurance in order to define a specific
subservice".
9.1. Module Name
For subservice YANG modules vetted by the IETF, the module name
should be "ieft-service-assurance-" followed by the short name. For
instance, "ietf-service-assurance-interface" or "ietf-service-
assurance-is-is".
For subservice YANG module that are directly provided by vendors, we
propose that they use the company in the prefix. For example, the
prefix for the company "acme" would be "acme-assurance-" and the YANG
modules would be "acme-assurance-interface", "acme-assurance-is-is",
etc.
9.2. Module Namespace
For subservice YANG modules vetted by the IETF, the module namespace
should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-"
followed by the short name. For instance,
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is".
For subservice YANG module that are directly provided by vendors, a
similar pattern can be used with the prefix being a namespace
controlled by the vendor.
9.3. Module Prefix
For subservice YANG modules vetted by the IETF, the module prefix
should be "service-assurance-" followed by the short name. For
instance, "service-assurance-interface" or "service-assurance-is-is".
For subservice YANG module that are directly provided by vendors, the
same pattern can be used provided it does not conflict with an
imported prefix.
9.4. Subservice Specific Identity
Each auqment specific to a subservice must define an identity
representing the type of subpart or features of the network system
that are assured by the subservice. As required in the "ietf-
service-assurance" module (see Section 4.3), that identity must be
based on the "subservice-idty" identity.
For subservice YANG modules vetted by the IETF, the subservice
specific identity should be the short name of the subservice followed
by "-idty". For instance, "interface-idty" or "is-is-identity".
For subservice YANG module that are directly provided by vendors, the
same pattern can be used.
9.5. Parameters
For subservice YANG modules vetted by the IETF, the parameters
specific to the subservice should be placed in a container named
"parameters". That container must be used to augment the "parameter"
choice from the module "ietf-service-assurance" (see Section 4.3 and
that augment must be guarded so that it is effective only for
subservice instance whose type is the subservice specific identity
from Section 9.4.
For subservice YANG module that are directly provided by vendors, the
same pattern can be used.
10. 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 24, line 30 skipping to change at page 34, line 15
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
o /subservices/subservice/type o /subservices/subservice/type
o /subservices/subservice/id o /subservices/subservice/id
o /subservices/subservice/under-maintenance o /subservices/subservice/under-maintenance
o /subservices/subservice/maintenance-contact o /subservices/subservice/maintenance-contact
9. IANA Considerations 11. IANA Considerations
9.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
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.
9.2. The YANG Module Names Registry 11.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
10. Open Issues 12. Open Issues
-None -None
11. References 13. References
11.1. Normative References 13.1. Normative References
[draft-claise-opsawg-service-assurance-architecture] [I-D.ietf-opsawg-service-assurance-architecture]
Claise, B. and J. Quilbeuf, "draft-claise-opsawg-service- Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
assurance-architecture", 2020. Arumugam, "draft-claise-opsawg-service-assurance-
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 26, line 18 skipping to change at page 36, line 14
[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>.
[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>.
11.2. Informative References 13.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>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<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>.
Appendix A. Changes between revisions 13.3. URIs
v04 - v05 [1] https://yangson.labs.nic.cz/
o Added the concept of symptoms-history-start Appendix A. Example of YANG instances
o Changed label to description, under symptoms. This was confusing This section contains examples of YANG instances that conform to the
as there was two labels in the models YANG modules. The validity of these data instances has been checked
using yangson [1]. Yangson requires a YANG library [RFC7895] to
define the complete model against which the data instance must be
validated. We provide in Appendix B the JSON library file, named
"ietf-service-assurance-library.json", that we used for validation.
v03 - v04 We provide below the contents of the file
"example_configuration_instance.json" which contains the
configuration data that models the Figure 2 of
o Add the interface subservice, with two parameters [I-D.ietf-opsawg-service-assurance-architecture]. The instance can
be validated with yangson by using the invocation "yangson -v
example_configuration_instance.json ietf-service-assurance-
library.json", assuming all the files (YANG and JSON) defined in this
draft reside in the current folder.
v02 - v03 <CODE BEGINS> file "example_configuration_instance.json"
o Added the maintenace window concepts {
v01 - v02 "ietf-service-assurance:subservices": {
"subservice": [
{
"type": "service-instance-idty",
"id": "simple-tunnel/example",
"service-instance-parameter": {
"service": "simple-tunnel",
"instance-name": "example"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/tunnel0",
"dependency-type": "impacting-dependency"
},
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer2/tunnel9",
"dependency-type": "impacting-dependency"
},
{
"type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty",
"id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
"dependency-type": "impacting-dependency"
}
]
}
},
{
"type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty",
"id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
"ietf-service-assurance-ip-connectivity:parameters": {
"device1": "Peer1",
"address1": "2001:db8::1",
"device2": "Peer2",
"address2": "2001:db8::2"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/physical0",
"dependency-type": "impacting-dependency"
},
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer2/physical5",
"dependency-type": "impacting-dependency"
},
{
"type": "ietf-service-assurance-is-is:is-is-idty",
"id": "is-is/instance1",
"dependency-type": "impacting-dependency"
}
]
}
},
{
"type": "ietf-service-assurance-is-is:is-is-idty",
"id": "is-is/instance1",
"ietf-service-assurance-is-is:parameters": {
"instance-name": "instance1"
}
},
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/tunnel0",
"ietf-service-assurance-interface:parameters": {
"device": "Peer1",
"interface": "tunnel0"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/physical0",
"dependency-type": "impacting-dependency"
}
]
}
},
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer1/physical0",
"ietf-service-assurance-interface:parameters": {
"device": "Peer1",
"interface": "physical0"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-device:device-idty",
"id": "interface/peer1",
"dependency-type": "impacting-dependency"
}
]
}
},
{
"type": "ietf-service-assurance-device:device-idty",
"id": "interface/peer1",
"ietf-service-assurance-device:parameters": {
"device": "Peer1"
}
},
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer2/tunnel9",
"ietf-service-assurance-interface:parameters": {
"device": "Peer2",
"interface": "tunnel9"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer2/physical5",
"dependency-type": "impacting-dependency"
}
]
}
},
{
"type": "ietf-service-assurance-interface:interface-idty",
"id": "interface/peer2/physical5",
"ietf-service-assurance-interface:parameters": {
"device": "Peer2",
"interface": "physical5"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-device:device-idty",
"id": "interface/peer2",
"dependency-type": "impacting-dependency"
}
]
}
},
{
"type": "ietf-service-assurance-device:device-idty",
"id": "interface/peer2",
"ietf-service-assurance-device:parameters": {
"device": "Peer2"
}
}
]
}
}
o Improved leaf naming <CODE ENDS>
o Clarified some concepts: symptoms, dependency Appendix B. YANG Library for Service Assurance
This section provides the JSON encoding of the YANG library [RFC7895]
listing all modules defined in this draft and their dependencies.
This library can be used to validate data instances using yangson, as
explained in the previous section.
<CODE BEGINS> file "ietf-service-assurance-library.json"
{
"ietf-yang-library:modules-state": {
"module-set-id": "ietf-service-assurance@2020-01-13",
"module": [
{
"name": "ietf-service-assurance",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance",
"revision": "2021-06-28",
"conformance-type": "implement"
},
{
"name": "ietf-service-assurance-device",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device",
"revision": "2021-06-28",
"conformance-type": "implement"
},
{
"name": "ietf-service-assurance-interface",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface",
"revision": "2021-06-28",
"conformance-type": "implement"
},
{
"name": "example-service-assurance-device-acme",
"namespace": "urn:example:example-service-assurance-device-acme",
"revision": "2021-06-28",
"conformance-type": "implement"
},
{
"name": "ietf-service-assurance-is-is",
"namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-is-is",
"revision": "2021-06-28",
"conformance-type": "implement"
},
{
"name": "ietf-service-assurance-ip-connectivity",
"namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-ip-connectivity",
"revision": "2021-06-28",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"revision": "2021-04-14",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"revision": "2021-02-22",
"conformance-type": "import"
}
]
}
}
<CODE ENDS>
Appendix C. Changes between revisions
v00 - v01 v00 - v01
o Terminology clarifications o Added needed subservice to model example from architecture draft
o Provide example of impacting versus impacted dependencies o Added guideline section for naming models
o Added data instance examples and validation procedure
o Added the "parameters" container in the interface YANG module to
correct a bug.
Acknowledgements Acknowledgements
The authors would like to thank Jan Lindblad for his help during the The authors would like to thank Jan Lindblad for his help during the
design of these YANG modules. The authors would like to thank design of these YANG modules. The authors would like to thank
Stephane Litkowski and Charles Eckel for their reviews. Stephane Litkowski and Charles Eckel 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
Independent Huawei
Email: jean@quilbeuf.net Email: jean.quilbeuf@huawei.com
Paolo Lucente Paolo Lucente
NTT NTT
Siriusdreef 70-72 Siriusdreef 70-72
Hoofddorp, WT 2132 Hoofddorp, WT 2132
Netherlands Netherlands
Email: paolo@ntt.net Email: paolo@ntt.net
Paolo Fasano Paolo Fasano
 End of changes. 123 change blocks. 
326 lines changed or deleted 979 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/