draft-ietf-opsawg-service-assurance-yang-02.txt   draft-ietf-opsawg-service-assurance-yang-03.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: 8 July 2022 P. Lucente Expires: 26 September 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.
4 January 2022 25 March 2022
YANG Modules for Service Assurance YANG Modules for Service Assurance
draft-ietf-opsawg-service-assurance-yang-02 draft-ietf-opsawg-service-assurance-yang-03
Abstract Abstract
This document proposes YANG modules for the Service Assurance for This document proposes YANG modules for the Service Assurance for
Intent-based Networking Architecture. Intent-based Networking Architecture.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 July 2022. This Internet-Draft will expire on 26 September 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 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3
4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4
4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7
5. Subservice Extension: ietf-service-assurance-device YANG 5. Subservice Extension: ietf-service-assurance-device YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . 14 module . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15
5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17
6. Subservice Extension: ietf-service-assurance-interface YANG 6. Subservice Extension: ietf-service-assurance-interface YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . 18 module . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 19
6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21
7. Vendor-specific Subservice Extension: 7. Vendor-specific Subservice Extension:
example-service-assurance-device-acme YANG module . . . . 22 example-service-assurance-device-acme YANG module . . . . 23
7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22 7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 23
7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25
8. Further Extensions: IP Connectivity and IS-IS subservices . . 26 8. Further Extensions: IP Connectivity and IS-IS subservices . . 27
8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26 8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 27
8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26 8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 27
8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 27 8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 28
8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28 8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 29
8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30 8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 31
9. Guidelines for Specific Subservice Extension . . . . . . . . 32 9. Guidelines for Specific Subservice Extension . . . . . . . . 33
9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 33
9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32 9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 33
9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 33 9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 34
9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33 9.4. Subservice Specific Identity . . . . . . . . . . . . . . 34
9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 34
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34 11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 35
11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34 11.2. The YANG Module Names Registry . . . . . . . . . . . . . 35
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Example of YANG instances . . . . . . . . . . . . . 36 Appendix A. Example of YANG instances . . . . . . . . . . . . . 37
Appendix B. YANG Library for Service Assurance . . . . . . . . . 40 Appendix B. YANG Library for Service Assurance . . . . . . . . . 41
Appendix C. Changes between revisions . . . . . . . . . . . . . 41 Appendix C. Changes between revisions . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 The terms used in this document are defined in
[I-D.ietf-opsawg-service-assurance-architecture] [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-ietf-opsawg-service-assurance-architecture, specifies the [I-D.ietf-opsawg-service-assurance-architecture], specifies the
architecture and all of its components for service assurance. This architecture and all of its components for service assurance. This
document complements the architecture by providing open interfaces document complements the architecture by providing open interfaces
between components. More specifically, the goal is to provide YANG between components. More specifically, the goal is to provide YANG
modules for the purpose of service assurance in a format that is: modules for the purpose of service assurance in a format that is:
* machine readable * machine readable
* vendor independent * vendor independent
* augmentable * augmentable
skipping to change at page 5, line 6 skipping to change at page 5, line 6
[I-D.ietf-opsawg-service-assurance-architecture]. [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:counter64
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
+--rw subservice* [type id] +--rw subservice* [type id]
+--rw type identityref +--rw type identityref
+--rw id string +--rw id string
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
skipping to change at page 6, line 20 skipping to change at page 6, line 20
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-
weight (the impact to the health score incurred by this symptom), a weight (the impact to the health score incurred by this symptom), a
label (text describing what the symptom is), and dates and times at label (text describing what the symptom is), and dates and times at
which the symptom was detected and stopped being detected. While the which the symptom was detected and stopped being detected. While the
unique id is sufficient as an unique key list, the start-date-time unique id is sufficient as an unique key list, the start-date-time
second key help sorting and retrieving relevant symptoms. second key help sorting and retrieving relevant symptoms.
The relation between the health score and the health-score-weight of
the currently active symptoms is not explictely defined in this
draft. The only requirement is that a non-maximal score must be
explained by at least one symptom. A way to enforce that requirement
is to first detect symptoms and then compute the health score based
on the health-score-weight of the detected symptoms. As an example,
this computation could be to sum the health-score-weight of the
active symptoms, substract that value from 100 and change the value
to 0 if negative. The relation between health-score and health-
score-weight is left to the implementor (of an agent
[I-D.ietf-opsawg-service-assurance-architecture]). To consider for
implementing this relation: the health-score is mostly for humans,
the symptoms are what the closed loop automation can build on.
The assurance of a given service instance can be obtained by The assurance of a given service instance can be obtained by
composing the assurance of the subservices that it depends on, via composing the assurance of the subservices that it depends on, via
the dependency relations. the dependency relations.
A subservice declaration MUST provide: A subservice declaration MUST provide:
* A type: identity inheriting of the base identity for subservice, * A type: identity inheriting of the base identity for subservice,
* An id: string uniquely identifying the subservice among those with * An id: string uniquely identifying the subservice among those with
the same identity, the same identity,
skipping to change at page 11, line 27 skipping to change at page 11, line 32
type identityref { type identityref {
base dependency-type; base dependency-type;
} }
description description
"Represents the type of dependency (i.e. informational, impacting)."; "Represents the type of dependency (i.e. informational, impacting).";
} }
// augment here if more info are needed (i.e. a percentage) depending on the dependency type. // augment here if more info are needed (i.e. a percentage) depending on the dependency type.
} }
leaf assurance-graph-version { leaf assurance-graph-version {
type yang:counter32; type yang:counter64;
config false; config false;
mandatory true; mandatory true;
description description
"The assurance graph version, which increases by 1 for each new version, after the changes "The assurance graph version, which increases by 1 for each new version, after the changes
(dependencies and/or maintenance windows parameters) are applied to the subservice(s)."; (dependencies and/or maintenance windows parameters) are applied to the subservice(s).";
} }
leaf assurance-graph-last-change { leaf assurance-graph-last-change {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
mandatory true; mandatory true;
skipping to change at page 15, line 17 skipping to change at page 16, line 6
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw parameters +--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:counter64
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
+--rw subservice* [type id] +--rw subservice* [type id]
+--rw type identityref +--rw type identityref
+--rw id string +--rw id string
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
skipping to change at page 19, line 6 skipping to change at page 20, line 6
+--rw device string +--rw device string
+--rw interface 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:counter64
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
+--rw subservice* [type id] +--rw subservice* [type id]
+--rw type identityref +--rw type identityref
+--rw id string +--rw id string
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
skipping to change at page 23, line 6 skipping to change at page 24, line 6
+--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:counter64
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
+--rw subservice* [type id] +--rw subservice* [type id]
+--rw type identityref +--rw type identityref
+--rw id string +--rw id string
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
skipping to change at page 27, line 13 skipping to change at page 28, line 13
assure. assure.
8.3. Global Tree View 8.3. Global Tree View
The following tree diagram [RFC8340] provides an overview of the The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance, ietf-service-assurance-device, example- ietf-service-assurance, ietf-service-assurance-device, example-
service-assurance-device-acme, ietf-service-assurance-ip-connectivity service-assurance-device-acme, ietf-service-assurance-ip-connectivity
and ietf-service-assurance-is-is data models. and ietf-service-assurance-is-is data models.
module: ietf-service-assurance module: ietf-service-assurance
+--ro assurance-graph-version yang:counter32 +--ro assurance-graph-version yang:counter64
+--ro assurance-graph-last-change yang:date-and-time +--ro assurance-graph-last-change yang:date-and-time
+--rw subservices +--rw subservices
+--rw subservice* [type id] +--rw subservice* [type id]
+--rw type identityref +--rw type identityref
+--rw id string +--rw id string
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro label? string +--ro label? string
+--rw under-maintenance? boolean +--rw under-maintenance? boolean
+--rw maintenance-contact string +--rw maintenance-contact string
+--rw (parameter)? +--rw (parameter)?
skipping to change at page 41, line 46 skipping to change at page 42, line 46
"conformance-type": "import" "conformance-type": "import"
} }
] ]
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix C. Changes between revisions Appendix C. Changes between revisions
v02 - v03
* Change counter32 to counter64 to avoid resetting too frequently
* Explain why relation between health-score and symptom's health-
score-weight is not defined and how it could be defined
v01 - v02
* Explicitly represent the fact that the health-score could not be
computed (value -1)
v00 - v01 v00 - v01
* Added needed subservice to model example from architecture draft * Added needed subservice to model example from architecture draft
* Added guideline section for naming models * Added guideline section for naming models
* Added data instance examples and validation procedure * Added data instance examples and validation procedure
* Added the "parameters" container in the interface YANG module to * Added the "parameters" container in the interface YANG module to
correct a bug. correct a bug.
Acknowledgements Acknowledgements
The authors would like to thank Jan Lindblad for his help during the The authors would like to thank Jan Lindblad for his help during the
design of these YANG modules. The authors would like to thank design of these YANG modules. The authors would like to thank
Stephane Litkowski and Charles Eckel for their reviews. Stephane Litkowski and Charles Eckel for their reviews.
 End of changes. 19 change blocks. 
49 lines changed or deleted 76 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/