draft-ietf-opsawg-service-assurance-yang-04.txt   draft-ietf-opsawg-service-assurance-yang-05.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: 27 October 2022 P. Lucente Expires: 31 October 2022 P. Lucente
NTT NTT
P. Fasano P. Fasano
TIM S.p.A TIM S.p.A
T. Arumugam T. Arumugam
Cisco Systems, Inc. Cisco Systems, Inc.
25 April 2022 29 April 2022
YANG Modules for Service Assurance YANG Modules for Service Assurance
draft-ietf-opsawg-service-assurance-yang-04 draft-ietf-opsawg-service-assurance-yang-05
Abstract Abstract
This document specifies YANG modules representing assurance graphs. This document specifies YANG modules representing assurance graphs.
These graphs represent the assurance of a given service by These graphs represent the assurance of a given service by
decomposing it into atomic assurance elements called subservices. A decomposing it into atomic assurance elements called subservices. A
companion RFC, Service Assurance for Intent-based Networking companion RFC, Service Assurance for Intent-based Networking
Architecture, presents an architecture for implementing the assurance Architecture, presents an architecture for implementing the assurance
of such services. of such services.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 27 October 2022. This Internet-Draft will expire on 31 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 4.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15
4.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17
5. Subservice Extension: ietf-service-assurance-interface YANG 5. Subservice Extension: ietf-service-assurance-interface YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . 19 module . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19
5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21
6. Vendor-specific Subservice Extension: 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
example-service-assurance-device-acme YANG module . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 24
6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 23 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 24
6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Further Extensions: IP Connectivity and IS-IS subservices . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
7.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . 25
7.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Vendor-specific Subservice Extension:
7.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 28 example-service-assurance-device-acme YANG module . . . . 26
7.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29 A.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 26
7.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 32 A.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 26
8. Guidelines for Specific Subservice Extension . . . . . . . . 33 A.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 34 A.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Further Extensions: IP Connectivity and IS-IS
8.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 34 subservices . . . . . . . . . . . . . . . . . . . . . . . 30
8.4. Subservice Specific Identity . . . . . . . . . . . . . . 35 B.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 30
8.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 35 B.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 31
B.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 B.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 B.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 35
10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 36 Appendix C. Example of YANG instances . . . . . . . . . . . . . 37
10.2. The YANG Module Names Registry . . . . . . . . . . . . . 36 Appendix D. YANG Library for Service Assurance . . . . . . . . . 40
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix E. Changes between revisions . . . . . . . . . . . . . 42
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Example of YANG instances . . . . . . . . . . . . . 38
Appendix B. YANG Library for Service Assurance . . . . . . . . . 42
Appendix C. Changes between revisions . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The "Service Assurance for Intent-based Networking Architecture" The "Service Assurance for Intent-based Networking Architecture"
[I-D.ietf-opsawg-service-assurance-architecture], specifies the [I-D.ietf-opsawg-service-assurance-architecture], specifies the
architecture and all of its components for service assurance. This architecture and all of its components for service assurance. This
document complements the architecture by providing open interfaces document complements the architecture by providing open interfaces
between components. More specifically, the goal is to provide YANG between components. More specifically, the goal is to provide YANG
modules for the purpose of service assurance in a format that is: modules for the purpose of service assurance in a format that is:
skipping to change at page 4, line 25 skipping to change at page 4, line 21
* Assurance telemetry: export the health status of the subservices, * Assurance telemetry: export the health status of the subservices,
along with the observed symptoms. along with the observed symptoms.
The main module represents the configuration (subservice and The main module represents the configuration (subservice and
dependencies) and operational data (health status and symptoms) in a dependencies) and operational data (health status and symptoms) in a
single tree. Other modules follows the same pattern. Thus, the single tree. Other modules follows the same pattern. Thus, the
modules presented in this document conform to the Network Management modules presented in this document conform to the Network Management
Datastore Architecture defined in [RFC8342]. Datastore Architecture defined in [RFC8342].
The second YANG module, ietf-service-assurance-device, extends the The second YANG module, ietf-service-assurance-device, extends the
ietf-service-assurance module to add support for the subservice ietf-service-assurance module to add support for the device
DeviceHealthy. Additional subservice types might be added the same subservice. Additional subservice types might be added the same way.
way.
The third YANG module, ietf-service-assurance-device, is another
example that extends the ietf-service-assurance-device module. This
extension adds support for the subservice InterfaceHealthy.
The fourth YANG module, example-service-assurance-device-acme, The third YANG module, ietf-service-assurance-interface, is another
extends the ietf-service-assurance-device module as an example to add example that extends the ietf-service-assurance module. This
support for the subservice DeviceHealthy, with specifics for the extension adds support for the interface subservice.
fictional ACME Corporation. Additional vendor-specific parameters
might be added the same way.
Finally, the modules example-service-assurance-ip-connectivity and We provide additional examples in the appendix. The module example-
example-service-assurance-is-is are provided to completely model the service-assurance-device-acme extends the ietf-service-assurance-
example from the SAIN architecture draft device module to customize it for devices of the fictional ACME
Corporation. Additional vendor-specific parameters might be added
the same way. We also provide the modules example-service-assurance-
ip-connectivity and example-service-assurance-is-is to completely
model the example from the SAIN architecture draft
[I-D.ietf-opsawg-service-assurance-architecture]. [I-D.ietf-opsawg-service-assurance-architecture].
3. Base ietf-service-assurance YANG module 3. Base ietf-service-assurance YANG module
3.1. Tree View 3.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance data model. ietf-service-assurance data model.
module: ietf-service-assurance module: ietf-service-assurance
skipping to change at page 5, line 44 skipping to change at page 5, line 44
+--rw id leafref +--rw id leafref
+--rw dependency-type? identityref +--rw dependency-type? identityref
3.2. Concepts 3.2. Concepts
The ietf-service-assurance YANG model assumes an identified number of The ietf-service-assurance YANG model assumes an identified number of
subservices, to be assured independently. A subservice is a feature subservices, to be assured independently. A subservice is a feature
or a subpart of the network system that a given service instance or a subpart of the network system that a given service instance
might depend on. Example of subservices include: might depend on. Example of subservices include:
* DeviceHealthy: whether a device is healthy, and if not, what are * device: whether a device is healthy, and if not, what are the
the symptoms. Potential symptoms are "CPU overloaded", "Out of symptoms. Potential symptoms are "CPU overloaded", "Out of RAM",
RAM", or "Out of TCAM". or "Out of TCAM".
* ConnectivityHealthy: given two IP addresses owned by two devices, * ip-connectivity: given two IP addresses owned by two devices, what
what is the quality of the connection between them. Potential is the quality of the connection between them. Potential symptoms
symptoms are "No route available" or "ECMP Imbalance". 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 status of each subservice contains a list of symptoms. Each The status of each subservice contains a list of symptoms. Each
symptom is specified by a unique id and contains a health-score- symptom is specified by a unique id and contains a health-score-
skipping to change at page 7, line 12 skipping to change at page 7, line 12
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:
* Impacting: such a dependency indicates an impact on the health of * Impacting: such a dependency indicates an impact on the health of
the dependent, the dependent,
* Informational: such a dependency might explain why the dependent * Informational: such a dependency might explain why the dependent
has issues but does not impact its health. has issues but does not impact its health.
To illustrate the difference between "impacting" and "informational", To illustrate the difference between "impacting" and "informational",
consider the subservice InterfaceHealthy, representing a network consider the interface subservice, representing a network interface.
interface. If the device to which the network interface belongs goes If the device to which the network interface belongs goes down, the
down, the network interface will transition to a down state as well. network interface will transition to a down state as well.
Therefore, the dependency of InterfaceHealthy towards DeviceHealthy Therefore, the dependency of the interface subservice towards the
is "impacting". On the other hand, as a the dependency towards the device subservice is "impacting". On the other hand, a dependency
ECMPLoad subservice, which checks that the load between ECMP remains towards the ecmp-load subservice, which checks that the load between
ce remains stable throughout time, is only "informational". Indeed, ECMP remains stable throughout time, is only "informational".
services might be perfectly healthy even if the load distribution Indeed, services might be perfectly healthy even if the load
between ECMP changed. However, such an instability might be a distribution between ECMP changed. However, such an instability
relevant symptom for diagnosing the root cause of a problem. might be a relevant symptom for diagnosing the root cause of a
problem.
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 to be assured, for instance the name of the
of the customer using that instance. 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
[I-D.ietf-opsawg-service-assurance-architecture] for a more detailed [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed
discussion. discussion.
By specifying service instances and their dependencies in terms of By specifying service instances and their dependencies in terms of
subservices, one defines the whole assurance to apply for them. An subservices, one defines the whole assurance to apply for them. An
assurance agent supporting this model should then produce telemetry assurance agent supporting this model should then produce telemetry
skipping to change at page 11, line 19 skipping to change at page 11, line 26
} }
grouping subservice-dependency { grouping subservice-dependency {
description description
"Represent a dependency to another subservice."; "Represent a dependency to another subservice.";
leaf type { leaf type {
type leafref { type leafref {
path "/subservices/subservice/type"; path "/subservices/subservice/type";
} }
description description
"The type of the subservice to refer to (e.g. DeviceHealthy)."; "The type of the subservice to refer to (e.g. device).";
} }
leaf id { leaf id {
type leafref { type leafref {
path "/subservices/subservice[type=current()/../type]/id"; path "/subservices/subservice[type=current()/../type]/id";
} }
description description
"The identifier of the subservice to refer to."; "The identifier of the subservice to refer to.";
} }
leaf dependency-type { leaf dependency-type {
type identityref { type identityref {
skipping to change at page 12, line 25 skipping to change at page 12, line 31
"Root container for the subservices."; "Root container for the subservices.";
list subservice { list subservice {
key "type id"; key "type id";
description description
"List of subservice configured."; "List of subservice configured.";
leaf type { leaf type {
type identityref { type identityref {
base subservice-idty; base subservice-idty;
} }
description description
"Name of the subservice, e.g. DeviceHealthy."; "Type of the subservice, for instance device or interface.";
} }
leaf id { leaf id {
type string; type string;
description description
"Unique identifier of the subservice instance, for each "Unique identifier of the subservice instance, for each
type."; type.";
} }
leaf last-change { leaf last-change {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
skipping to change at page 16, line 45 skipping to change at page 16, line 45
+--rw type +--rw type
| -> /subservices/subservice/type | -> /subservices/subservice/type
+--rw id leafref +--rw id leafref
+--rw dependency-type? identityref +--rw dependency-type? identityref
4.3. Concepts 4.3. Concepts
As the number of subservices will grow over time, the YANG module is As the number of subservices will grow over time, the YANG module is
designed to be extensible. A new subservice type requires the designed to be extensible. A new subservice type requires the
precise specifications of its type and expected parameters. Let us precise specifications of its type and expected parameters. Let us
illustrate the example of the new DeviceHealthy subservice type. As illustrate the example of the new device subservice type. As the
the name implies, it monitors and reports the device health, along name implies, it monitors and reports the device health, along with
with some symptoms in case of degradation. some symptoms in case of degradation.
For our DeviceHealthy subservice definition, the new identity device- For our device subservice definition, the new identity device-idty is
idty is specified, as an inheritance from the base identity for specified, as an inheritance from the base identity for subservices.
subservices. This indicates to the assurance agent that we are now This indicates to the assurance agent that we are now assuring the
assuring the health of a device. health of a device.
The typical parameter for the configuration of the DeviceHealthy The typical parameter for the configuration of the device subservice
subservice is the name of the device that we want to assure. By is the name of the device that we want to assure. By augmenting the
augmenting the parameter choice from ietf-service-assurance YANG parameter choice from ietf-service-assurance YANG module for the case
module for the case of the device-idty subservice type, this new of the device-idty subservice type, this new parameter is specified.
parameter is specified.
4.4. YANG Module 4.4. YANG Module
<CODE BEGINS> file "ietf-service-assurance-device@2022-04-07.yang" <CODE BEGINS> file "ietf-service-assurance-device@2022-04-07.yang"
module ietf-service-assurance-device { module ietf-service-assurance-device {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device";
prefix sain-device; prefix sain-device;
skipping to change at page 17, line 41 skipping to change at page 17, line 40
organization organization
"IETF OPSAWG Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description description
"This module extends the ietf-service-assurance module to add "This module extends the ietf-service-assurance module to add
support for the subservice DeviceHealthy. support for the device subservice.
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.
skipping to change at page 20, line 46 skipping to change at page 20, line 46
| +--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 +--rw type
| -> /subservices/subservice/type | -> /subservices/subservice/type
+--rw id leafref +--rw id leafref
+--rw dependency-type? identityref +--rw dependency-type? identityref
5.3. Concepts 5.3. Concepts
For our InterfaceHealthy subservice definition, the new interface- For our interface subservice definition, the new interface-idty is
idty is specified, as an inheritance from the base identity for specified, as an inheritance from the base identity for subservices.
subservices. This indicates to the assurance agent that we are now This indicates to the assurance agent that we are now assuring the
assuring the health of an interface. health of an interface.
The typical parameters for the configuration of the InterfaceHealthy The typical parameters for the configuration of the interface
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 parameters are specified. subservice type, those two new parameters are specified.
5.4. YANG Module 5.4. YANG Module
<CODE BEGINS> file "ietf-service-assurance-interface@2022-04-07.yang" <CODE BEGINS> file "ietf-service-assurance-interface@2022-04-07.yang"
module ietf-service-assurance-interface { module ietf-service-assurance-interface {
skipping to change at page 21, line 36 skipping to change at page 21, line 36
organization organization
"IETF OPSAWG Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description description
"This module extends the ietf-service-assurance module to add "This module extends the ietf-service-assurance module to add
support for the subservice InterfaceHealthy. support for the interface subservice.
Checks whether an interface is healthy. Checks whether an interface is healthy.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 23, line 16 skipping to change at page 23, line 16
mandatory true; mandatory true;
description description
"Name of the interface."; "Name of the interface.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6. Vendor-specific Subservice Extension: example-service-assurance- 6. Security Considerations
device-acme YANG module
6.1. Tree View The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are
writable/ creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
* /subservices/subservice/type
* /subservices/subservice/id
* /subservices/subservice/under-maintenance
* /subservices/subservice/maintenance-contact
7. IANA Considerations
7.1. The IETF XML Registry
This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registrations are
requested:
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
7.2. The YANG Module Names Registry
This document registers three YANG modules in the YANG Module Names
registry [RFC7950]. Following the format in [RFC7950], the the
following registrations are requested:
name: ietf-service-assurance
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance
prefix: sain
reference: RFC XXXX
name: ietf-service-assurance-device
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
prefix: sain-device
reference: RFC XXXX
name: ietf-service-assurance-interface
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
prefix: sain-interface
reference: RFC XXXX
8. Open Issues
-None
9. References
9.1. Normative References
[I-D.ietf-opsawg-service-assurance-architecture]
Claise, B., Quilbeuf, J., Lopez, D. R., Voyer, D., and T.
Arumugam, "Service Assurance for Intent-based Networking
Architecture", Work in Progress, Internet-Draft, draft-
ietf-opsawg-service-assurance-architecture-03, 7 March
2022, <https://www.ietf.org/archive/id/draft-ietf-opsawg-
service-assurance-architecture-03.txt>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Appendix A. Vendor-specific Subservice Extension: example-service-
assurance-device-acme YANG module
A.1. Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
example-service-assurance-device-acme data model. example-service-assurance-device-acme data model.
module: example-service-assurance-device-acme module: example-service-assurance-device-acme
augment /sain:subservices/sain:subservice/sain:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw device string +--rw device string
+--rw acme-specific-parameter string +--rw acme-specific-parameter string
6.2. Complete Tree View A.2. Complete Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance, ietf-service-assurance-device, and example- ietf-service-assurance, ietf-service-assurance-device, and example-
service-assurance-device-acme data models. service-assurance-device-acme data models.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter64 +--ro assurance-graph-version yang:counter64
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
+--rw subservice* [type id] +--rw subservice* [type id]
skipping to change at page 25, line 5 skipping to change at page 28, line 5
| +--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 +--rw type
| -> /subservices/subservice/type | -> /subservices/subservice/type
+--rw id leafref +--rw id leafref
+--rw dependency-type? identityref +--rw dependency-type? identityref
6.3. Concepts A.3. Concepts
Under some circumstances, vendor-specific subservice types might be Under some circumstances, vendor-specific subservice types might be
required. As an example of this vendor-specific implementation, this required. As an example of this vendor-specific implementation, this
section shows how to augment the ietf-service-assurance-device module section shows how to augment the ietf-service-assurance-device module
to add support for the subservice DeviceHealthy, specific to the ACME to add custom support for the device subservice, specific to the ACME
Corporation. The new parameter is acme-specific-parameter. Corporation. The specific version adds a new parameter, named acme-
specific-parameter.
6.4. YANG Module A.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-device-acme; prefix example-device-acme;
import ietf-service-assurance { import ietf-service-assurance {
prefix sain; prefix sain;
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC xxxx: YANG Modules for Service Assurance";
} }
import ietf-service-assurance-device { import ietf-service-assurance-device {
prefix sain-device; prefix sain-device;
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC xxxx: YANG Modules for Service Assurance";
} }
organization organization
"IETF OPSAWG Working Group"; "IETF OPSAWG Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com> Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>"; Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description description
"This module extends the ietf-service-assurance-device module to "This module extends the ietf-service-assurance-device module to
add support for the subservice DeviceHealthy, specific to the ACME add specific support for devices of ACME Corporation.
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) 2022 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. "; RFC itself for full legal notices. ";
revision 2022-04-07 { revision 2022-04-07 {
description description
"Fix mandatory in augment error by moving when clause. "Fix mandatory in augment error by moving when clause.
Shorten prefix. Shorten prefix.
Fix module description"; Fix module description";
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC xxxx: YANG Modules for Service Assurance";
} }
revision 2021-06-28 { revision 2021-06-28 {
description description
"Renamed the parameters container."; "Renamed the parameters container.";
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC xxxx: YANG Modules for Service Assurance";
} }
revision 2020-01-13 { revision 2020-01-13 {
description description
"Added the maintenance window concept."; "Added the maintenance window concept.";
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC xxxx: YANG Modules for Service Assurance";
} }
revision 2019-11-16 { revision 2019-11-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC xxxx: YANG Modules for Service Assurance";
} }
identity device-acme-idty { identity device-acme-idty {
base sain-device:device-idty; base sain-device:device-idty;
description description
"Network Device is healthy."; "Network Device is healthy.";
} }
augment "/sain:subservices/sain:subservice/sain:parameter" { augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'device-acme-idty')"; when "derived-from-or-self(sain:type, 'device-acme-idty')";
description
"Specify the required parameters for a new subservice type";
container parameters {
description description
"Specify the required parameters for the device-acme-idty "Specify the required parameters for a new subservice type";
subservice type"; container parameters {
leaf device {
type string;
mandatory true;
description
"The device to monitor.";
}
leaf acme-specific-parameter {
type string;
mandatory true;
description description
"The ACME Corporation sepcific parameter."; "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.";
}
} }
} }
} }
}
7. Further Extensions: IP Connectivity and IS-IS subservices Appendix B. Further Extensions: IP Connectivity and IS-IS subservices
In this section, we provide two additional YANG models to completely In this section, we provide two additional YANG models to completely
cover the example from Figure 2 in cover the example from Figure 2 in
[I-D.ietf-opsawg-service-assurance-architecture]. The complete [I-D.ietf-opsawg-service-assurance-architecture]. The complete
normalization of these modules is to be done in future work. normalization of these modules is to be done in future work.
7.1. IP Connectivity Tree View B.1. IP Connectivity Tree View
That subservice represents the unicast connectivity between two IP That subservice represents the unicast connectivity between two IP
addresses located on to different devices. Such a subservice could addresses located on to different devices. Such a subservice could
report symptoms such as "No route found". The following tree diagram report symptoms such as "No route found". The following tree diagram
[RFC8340] provides an overview of the example-service-assurance-ip- [RFC8340] provides an overview of the example-service-assurance-ip-
connectivity data model. connectivity data model.
module: example-service-assurance-ip-connectivity module: example-service-assurance-ip-connectivity
augment /sain:subservices/sain:subservice/sain:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
skipping to change at page 28, line 10 skipping to change at page 31, line 10
+--rw device1 string +--rw device1 string
+--rw address1 inet:ip-address +--rw address1 inet:ip-address
+--rw device2 string +--rw device2 string
+--rw address2 inet:ip-address +--rw address2 inet:ip-address
To specify the connectivity that we are interested in, we specify two To specify the connectivity that we are interested in, we specify two
IP addresses and two devices. The subservice assures that the IP addresses and two devices. The subservice assures that the
connectivity between IP address 1 on device 1 and IP address 2 on connectivity between IP address 1 on device 1 and IP address 2 on
device 2 is healthy. device 2 is healthy.
7.2. IS-IS Tree View B.2. IS-IS Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
example-service-assurance-is-is data model. example-service-assurance-is-is data model.
module: example-service-assurance-is-is module: example-service-assurance-is-is
augment /sain:subservices/sain:subservice/sain:parameter: augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters +--rw parameters
+--rw instance-name string +--rw instance-name string
The parameter of this subservice is the name of the IS-IS instance to The parameter of this subservice is the name of the IS-IS instance to
assure. assure.
7.3. Global Tree View B.3. Global Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance, ietf-service-assurance-device, example- ietf-service-assurance, ietf-service-assurance-device, example-
service-assurance-device-acme, example-service-assurance-ip- service-assurance-device-acme, example-service-assurance-ip-
connectivity and example-service-assurance-is-is data models. connectivity and example-service-assurance-is-is data models.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter64 +--ro assurance-graph-version yang:counter64
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
skipping to change at page 29, line 41 skipping to change at page 32, line 41
| +--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 +--rw type
| -> /subservices/subservice/type | -> /subservices/subservice/type
+--rw id leafref +--rw id leafref
+--rw dependency-type? identityref +--rw dependency-type? identityref
7.4. IP Connectivity YANG Module B.4. IP Connectivity YANG Module
module example-service-assurance-ip-connectivity { module example-service-assurance-ip-connectivity {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:example-service-assurance-ip-connectivity"; namespace "urn:example:example-service-assurance-ip-connectivity";
prefix example-ip-connectivity; prefix example-ip-connectivity;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
skipping to change at page 32, line 8 skipping to change at page 35, line 8
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"Address at the second end of the connection."; "Address at the second end of the connection.";
} }
} }
} }
} }
7.5. IS-IS YANG Module B.5. IS-IS YANG Module
module example-service-assurance-is-is { module example-service-assurance-is-is {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:example-service-assurance-is-is"; namespace "urn:example:example-service-assurance-is-is";
prefix example-is-is; prefix example-is-is;
import ietf-service-assurance { import ietf-service-assurance {
prefix sain; prefix sain;
reference reference
"RFC xxxx: YANG Modules for Service Assurance"; "RFC xxxx: YANG Modules for Service Assurance";
skipping to change at page 33, line 45 skipping to change at page 37, line 5
leaf instance-name { leaf instance-name {
type string; type string;
mandatory true; mandatory true;
description description
"The instance to monitor."; "The instance to monitor.";
} }
} }
} }
} }
8. Guidelines for Specific Subservice Extension Appendix C. Example of YANG instances
The base YANG module defined in Section 3.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
interface then "interface" is an adequate short name. If the
subservice will assure the IS-IS routing protocol, then "is-is" is an
adequate short name. The short name must be in kebab-case.
In this section, by subservice YANG module, we mean "YANG module that
extends ietf-service-assurance in order to define a specific
subservice".
8.1. Module Name
For subservice YANG modules vetted by the IETF, the module name
should be "ietf-service-assurance-" followed by the short name. For
instance, "ietf-service-assurance-interface" or "ietf-service-
assurance-is-is".
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.
8.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:example-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.
8.3. Module Prefix
For subservice YANG modules vetted by the IETF, the module prefix
should be "sain-" followed by the short name. For instance, "sain-
interface" or "sain-is-is".
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.
8.4. Subservice Specific Identity
Each augment specific to a subservice must define an identity
representing the type of subpart or features of the network system
that are assured by the subservice. As required in the "ietf-
service-assurance" module (see Section 3.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.
8.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 3.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 8.4.
For subservice YANG module that are directly provided by vendors, the
same pattern can be used.
9. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are
writable/ creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
* /subservices/subservice/type
* /subservices/subservice/id
* /subservices/subservice/under-maintenance
* /subservices/subservice/maintenance-contact
10. IANA Considerations
10.1. The IETF XML Registry
This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registrations are
requested:
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
10.2. The YANG Module Names Registry
This document registers three YANG modules in the YANG Module Names
registry [RFC7950]. Following the format in [RFC7950], the the
following registrations are requested:
name: ietf-service-assurance
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance
prefix: inc
reference: RFC XXXX
name: ietf-service-assurance-device
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
prefix: inc
reference: RFC XXXX
name: ietf-service-assurance-interface
namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
prefix: inc
reference: RFC XXXX
11. Open Issues
-None
12. References
12.1. Normative References
[I-D.ietf-opsawg-service-assurance-architecture]
Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V.,
and T.A. Arumugam, "draft-claise-opsawg-service-assurance-
architecture", 2020.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
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 (https://yangson.labs.nic.cz/). Yangson requires a using yangson (https://yangson.labs.nic.cz/). Yangson requires a
YANG library [RFC7895] to define the complete model against which the YANG library [RFC7895] to define the complete model against which the
data instance must be validated. We provide in Appendix B the JSON data instance must be validated. We provide in Appendix D the JSON
library file, named "ietf-service-assurance-library.json", that we library file, named "ietf-service-assurance-library.json", that we
used for validation. 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
skipping to change at page 42, line 23 skipping to change at page 40, line 34
"type": "ietf-service-assurance-device:device-idty", "type": "ietf-service-assurance-device:device-idty",
"id": "interface/peer2", "id": "interface/peer2",
"ietf-service-assurance-device:parameters": { "ietf-service-assurance-device:parameters": {
"device": "Peer2" "device": "Peer2"
} }
} }
] ]
} }
} }
Appendix B. YANG Library for Service Assurance Appendix D. YANG Library for Service Assurance
This section provides the JSON encoding of the YANG library [RFC7895] This section provides the JSON encoding of the YANG library [RFC7895]
listing all modules defined in this draft and their dependencies. listing all modules defined in this draft and their dependencies.
This library can be used to validate data instances using yangson, as This library can be used to validate data instances using yangson, as
explained in the previous section. explained in the previous section.
{ {
"ietf-yang-library:modules-state": { "ietf-yang-library:modules-state": {
"module-set-id": "ietf-service-assurance@2022-04-07", "module-set-id": "ietf-service-assurance@2022-04-07",
"module": [ "module": [
skipping to change at page 43, line 42 skipping to change at page 42, line 4
"revision": "2021-04-14", "revision": "2021-04-14",
"conformance-type": "import" "conformance-type": "import"
}, },
{ {
"name": "ietf-inet-types", "name": "ietf-inet-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"revision": "2021-02-22", "revision": "2021-02-22",
"conformance-type": "import" "conformance-type": "import"
} }
] ]
} }
} }
Appendix C. Changes between revisions Appendix E. Changes between revisions
v04 - v05
* Remove Guidelines section
* Move informative parts (examples) to appendix
* Minor text edits and reformulations
v03 - v04 v03 - v04
* Fix YANG errors * Fix YANG errors
* Change is-is and ip-connectivity subservices from ietf to example. * Change is-is and ip-connectivity subservices from ietf to example.
* Mention that models are NMDA compliant * Mention that models are NMDA compliant
* Fix typos, reformulate for clarity * Fix typos, reformulate for clarity
v02 - v03 v02 - v03
* Change counter32 to counter64 to avoid resetting too frequently * Change counter32 to counter64 to avoid resetting too frequently
 End of changes. 53 change blocks. 
422 lines changed or deleted 341 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/