OPSAWG B. Claise
Internet-Draft J. Quilbeuf
Intended status: Standards Track Cisco Systems, Inc.
Expires: May 7, 2020 November 4, 2019
YANG Modules for Service Assurance
draft-claise-opsawg-service-assurance-yang-00
Abstract
This document proposes YANG modules for the Service Assurance for
Intent-based Networking Architecture.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Claise & Quilbeuf Expires May 7, 2020 [Page 1]
Internet-Draft YANG Modules for Service Assurance November 2019
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3
4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4
4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6
5. Subservice Extension: ietf-service-assurance-device YANG
module . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 11
5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13
6. Vendor-specific Subservice Extension: example-service-
assurance-device-acme YANG module . . . . . . . . . . . . . . 14
6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 14
6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18
8.2. The YANG Module Names Registry . . . . . . . . . . . . . 18
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The terms used in this document are defined in draft-claise-opsawg-
service-assurance-architecture IETF draft.
The terms used in this document are defined in
[draft-claise-opsawg-service-assurance-architecture].
Claise & Quilbeuf Expires May 7, 2020 [Page 2]
Internet-Draft YANG Modules for Service Assurance November 2019
2. Introduction
The "Service Assurance for Intent-based Networking Architecture"
document [draft-claise-opsawg-service-assurance-architecture],
specifies the framework and all of its components for service
assurance. This document complements the architecture by providing
open interfaces between components. More specifically, the goal is
to provide YANG modules for the purpose of service assurance in a
format that is:
o formal
o vendor independent
o augmentable
3. YANG Models Overview
The main YANG module, ietf-service-assurance, defines objects for
assuring network services based on their decomposition into so-called
subservices. The subservices are hierarchically organised by
dependencies. The subservices, along with the dependencies,
constitute an assurance tree. This module should be supported by an
agent, able to interact with the devices in order to produce a health
status and symptoms for each subservice in the assurance tree. This
module is intended for the following use cases:
o Assurance tree configuration:
* Subservices: configure a set of subservices to assure, by
specifying their types and parameters.
* Dependencies: configure the dependencies between the
subservices, along with their type.
o Assurance telemetry: export the health status of the subservices,
along with the observed symptoms.
The second YANG module, ietf-service-assurance-device, extends the
ietf-service-assurance module to add support for the subservice
DeviceHealthy. Additional subservice types might be added the same
way.
The third 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.
Claise & Quilbeuf Expires May 7, 2020 [Page 3]
Internet-Draft YANG Modules for Service Assurance November 2019
4. Base ietf-service-assurance YANG module
4.1. Tree View
The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance data model.
module: ietf-service-assurance
+--ro assurance-tree-version? yang:counter32
+--ro assurance-tree-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 (parameter)?
| +--:(service-instance-parameter)
| +--rw service-instance-parameter
| +--rw service? string
| +--rw instance-name? string
+--ro health-status? uint8
+--ro symptoms* [start-date id]
| +--ro id string
| +--ro health-status? uint8
| +--ro label? string
| +--ro start-date yang:date-and-time
| +--ro stop-date? yang:date-and-time
+--rw dependency* [type id]
+--rw type -> /subservices/subservice/type
+--rw id -> /subservices/subservice[type=current()/../type]/id
+--rw dependency-type? identityref
4.2. Concepts
The ietf-service-assurance YANG model assumes an identified number of
subservices, to be assured independently. A subservice is a feature
or a subpart of the network system that a given service instance
might depend on. Example of subservices include:
o DeviceHealthy: whether a device is healthy, and if not, what are
the symptoms. Potential symptoms are "CPU overloaded", "Out of
RAM", or "Out of TCAM".
o ConnectivityHealthy: given two IP addresses owned by two devices,
what is the quality of the connection between them. Potential
symptoms are "No route available" or "ECMP Imbalance".
Claise & Quilbeuf Expires May 7, 2020 [Page 4]
Internet-Draft YANG Modules for Service Assurance November 2019
In both cases (the first example is a subservice representing a
subpart of the network system, while the second is a subservice
representing a feature of the network), each of these subservices
might depend on other subservices, for instance, the connectivity
might depend on a subservice representing the routing mechanism and
on a subservice representing ECMP.
The assurance of a given service instance can be obtained by
composing the assurance of the subservices that it depends on, via
the dependency relations.
In order to declare a subservice MUST provide:
o A type: identity inheriting of the base identity for subservice,
o An id: string uniquely identifying the subservice among those with
the same identity,
o Some parameters, which should be specified in an augmenting model,
as described in the next sections.
The type and id uniquely identify a given subservice. They are used
to indicate the dependencies. Dependencies have types as well. Two
types are specified in the model:
o Impacting: such a dependency indicates an impact on the health of
the dependent,
o Informational: such a dependency might explain why the dependent
has issues but does not impact its health.
Service instances MUST be modeled as a particular type of subservice
with two parameters, a type and an instance name. The type is the
name of the service defined in the network orchestrator, for instance
"point-to-point-l2vpn". The instance name is the name assigned to
the particular instance that we are assuring, for instance the name
of the customer using that instance.
By specifying service instances and their dependencies in terms of
subservices, one defines the whole assurance to apply for them. An
assurance agent supporting this model should then produce telemetry
in return with, for each subservice: a health-status indicating how
healthy the subservice is and when the subservice is not healthy, a
list of symptoms explaining why the subservice is not healthy.
Claise & Quilbeuf Expires May 7, 2020 [Page 5]
Internet-Draft YANG Modules for Service Assurance November 2019
4.3. YANG Module
<CODE BEGINS> file "ietf-service-assurance@2019-10-04.yang"
module ietf-service-assurance {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";
prefix service-assurance;
import ietf-yang-types {
prefix yang;
}
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:bclaise@cisco.com>
Author: Jean Quilbeuf <mailto:jquilbeu@cisco.com>";
description
"This module defines objects for assuring network services based on
their decomposition into so-called subservices, according to the SAIN
(Service Assurance for Intent-based Networking) architecture.
The subservices hierarchically organised by dependencies constitute an
assurance tree. This module should be supported by an assurance agent,
able to interact with the devices in order to produce a health status
and symptoms for each subservice in the assurance tree.
This module is intended for the following use cases:
* Assurance tree configuration:
* subservices: configure a set of subservices to assure, by specifying
their types and parameters.
* dependencies: configure the dependencies between the subservices,
along with their type.
* Assurance telemetry: export the health status of the subservices, along
with the observed symptoms.
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) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Claise & Quilbeuf Expires May 7, 2020 [Page 6]
Internet-Draft YANG Modules for Service Assurance November 2019
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 2019-10-02 {
description
"Initial revision.";
reference
"RFC xxxx: Title to be completed";
}
identity subservice-idty {
description
"Root identity for all subservice types.";
}
identity service-instance-idty {
base subservice-idty;
description
"Identity representing a service instance.";
}
identity dependency-type {
description
"Base identity for representing dependency types.";
}
identity informational-dependency {
base dependency-type;
description
"Indicates that symptoms of the dependency might be of interest for the
dependent, but the status of the dependency should not have any
impact on the dependent.";
}
identity impacting-dependency {
base dependency-type;
description
"Indicates that the status of the dependency directly impacts the status
of the dependent.";
}
Claise & Quilbeuf Expires May 7, 2020 [Page 7]
Internet-Draft YANG Modules for Service Assurance November 2019
grouping symptom {
description
"Contains the list of symptoms for a specific subservice.";
leaf id {
type string;
description
"A unique identifier for the symptom.";
}
leaf health-status {
type uint8 {
range "0 .. 100";
}
description
"The impact to the health score incurred by this symptom. The lower the
value, the more of an impact this symptom has. If a subservice health
score is not 100, there must be at least one symptom such that the
health-status of that symptom is equal to the health score of the
subservice. In other words, there must always be a symptom explaining
why the subservice health score is lower than 100.";
}
leaf label {
type string;
description
"Label of the symptom, i.e. text describing what the symptom is, to
be computer-consumable and be displayed on a human interface.";
}
leaf start-date {
type yang:date-and-time;
description
"Date and time at which the symptom was detected.";
}
leaf stop-date {
type yang:date-and-time;
description
"Date and time at which the symptom stopped being detected.";
}
}
grouping subservice-dependency {
description
"Represent a dependency to another subservice.";
leaf type {
type leafref {
path "/subservices/subservice/type";
}
description
"The type of the subservice to refer to (e.g. DeviceHealthy).";
}
Claise & Quilbeuf Expires May 7, 2020 [Page 8]
Internet-Draft YANG Modules for Service Assurance November 2019
leaf id {
type leafref {
path "/subservices/subservice[type=current()/../type]/id";
}
description
"The identifier of the subservice to refer to.";
}
leaf dependency-type {
type identityref {
base dependency-type;
}
description
"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.
}
leaf assurance-tree-version {
type yang:counter32;
config false;
description
"The assurance tree version, which increases by 1 for each new version.";
}
leaf assurance-tree-last-change {
type yang:date-and-time;
config false;
description
"Date and time at which the assurance tree last changed.";
}
container subservices {
description
"Root container for the subservices.";
list subservice {
key "type id";
description
"List of subservice configured.";
leaf type {
type identityref {
base subservice-idty;
}
description
"Name of the subservice, e.g. DeviceHealthy.";
}
leaf id {
type string;
description
"Unique identifier of the subservice instance, for each type.";
}
Claise & Quilbeuf Expires May 7, 2020 [Page 9]
Internet-Draft YANG Modules for Service Assurance November 2019
leaf last-change {
type yang:date-and-time;
config false;
description
"Date and time at which the assurance tree for this subservice
instance last changed.";
}
leaf label {
type string;
config false;
description
"Label for displaying the subservice name in human readable form.";
}
choice parameter {
description
"Specify the required parameters per subservice type.";
container service-instance-parameter {
when "derived-from-or-self(../type, 'service-instance-idty')";
description
"Specify the parameters of a service instance.";
leaf service {
type string;
description "Name of the service.";
}
leaf instance-name{
type string;
description "Name of the instance for that service.";
}
}
// Other modules can augment their own cases into here
}
leaf health-status {
type uint8 {
range "0 .. 100";
}
config false;
description
"Score value of the subservice health, also known as the subservice
status. A value of 100 means that subservice is healthy. A value of 0 means
that the subservice is broken. A value between 0 and 100 means that the
subservice is degraded.";
}
list symptoms {
//key id;
key "start-date id";
config false;
description
"List of symptoms the subservice. While the start-date key is not
Claise & Quilbeuf Expires May 7, 2020 [Page 10]
Internet-Draft YANG Modules for Service Assurance November 2019
necessary per se, this would get the entries sorted by start-date
for easy consumption.";
uses symptom;
}
list dependency {
key "type id";
description
"List of soft dependencies of the subservice.";
uses subservice-dependency;
}
}
}
}
<CODE ENDS>
5. Subservice Extension: ietf-service-assurance-device YANG module
5.1. Tree View
The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance-device data model.
module: ietf-service-assurance-device
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw device-idty
+--rw device? string
5.2. Complete Tree View
The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance and ietf-service-assurance-device data models.
Claise & Quilbeuf Expires May 7, 2020 [Page 11]
Internet-Draft YANG Modules for Service Assurance November 2019
module: ietf-service-assurance
+--ro assurance-tree-version? yang:counter32
+--ro assurance-tree-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 (parameter)?
| +--:(service-instance-parameter)
| | +--rw service-instance-parameter
| | +--rw service? string
| | +--rw instance-name? string
| +--:(service-assurance-device:device-idty)
| +--rw service-assurance-device:device-idty
| +--rw service-assurance-device:device? string
+--ro health-status? uint8
+--ro symptoms* [start-date id]
| +--ro id string
| +--ro health-status? uint8
| +--ro label? string
| +--ro start-date yang:date-and-time
| +--ro stop-date? yang:date-and-time
+--rw dependency* [type id]
+--rw type -> /subservices/subservice/type
+--rw id -> /subservices/subservice[type=current()/../type]/id
+--rw dependency-type? identityref
5.3. Concepts
As the number of subservices will grow over time, the YANG module is
designed to be extensible. A new subservice type requires the
precise specifications of tis type and the parameters. Let us
illustrate the example of the new DeviceHealthy subservice type. As
the name implies, it monitors and reports the device health, along
with some symptoms in case of degradation.
For our DeviceHealthy subservice definitions, the new device-idty is
specified, as an inheritance from the base identity for subservices.
This indicates to the assurance agent that we are now assuring the
health of a device.
The typical parameter for the configuration of the DeviceHealthy
subservice is the name of the device that we want to assure. By
augmenting the parameter choice from ietf-service-assurance YANG
module for the case of the device-idty subservice type, this new
parameter is specified.
Claise & Quilbeuf Expires May 7, 2020 [Page 12]
Internet-Draft YANG Modules for Service Assurance November 2019
5.4. YANG Module
<CODE BEGINS> file "ietf-service-assurance-device@2019-10-04.yang"
module ietf-service-assurance-device {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device";
prefix service-assurance-device;
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:bclaise@cisco.com>
Author: Jean Quilbeuf <mailto:jquilbeu@cisco.com>";
description
"This module extends the ietf-service-assurance module to add
support for the subservice DeviceHealthy.
Network Device 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) 2019 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 2019-10-04 {
description
Claise & Quilbeuf Expires May 7, 2020 [Page 13]
Internet-Draft YANG Modules for Service Assurance November 2019
"Initial revision.";
reference
"RFC xxxx: Title to be completed";
}
identity device-idty {
base service-assurance:subservice-idty;
description "Network Device is healthy.";
}
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter {
description
"Specify the required parameters for a new subservice type";
container device-idty{
when "derived-from-or-self(../service-assurance:type, 'device-idty')";
description
"Specify the required parameters for the device-idty subservice type";
leaf device {
type string;
description "The device to monitor.";
}
}
}
}
<CODE ENDS>
6. Vendor-specific Subservice Extension: example-service-assurance-
device-acme YANG module
6.1. Tree View
The following tree diagram [RFC8340] provides an overview of the
example-service-assurance-device-acme data model.
module: example-service-assurance-device-acme
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
+--rw acme-device-idty
+--rw device? string
+--rw acme-specific-parameter? string
6.2. Complete Tree View
The following tree diagram [RFC8340] provides an overview of the
ietf-service-assurance, ietf-service-assurance-device, and example-
service-assurance-device-acme data models.
Claise & Quilbeuf Expires May 7, 2020 [Page 14]
Internet-Draft YANG Modules for Service Assurance November 2019
module: ietf-service-assurance
+--ro assurance-tree-version? yang:counter32
+--ro assurance-tree-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 (parameter)?
| +--:(service-instance-parameter)
| | +--rw service-instance-parameter
| | +--rw service? string
| | +--rw instance-name? string
| +--:(service-assurance-device:device-idty)
| | +--rw service-assurance-device:device-idty
| | +--rw service-assurance-device:device? string
| +--:(example-service-assurance-device-acme:acme-device-idty)
| +--rw example-service-assurance-device-acme:acme-device-idty
| +--rw example-service-assurance-device-acme:device? string
| +--rw example-service-assurance-device-acme:acme-specific-parameter? string
+--ro health-status? uint8
+--ro symptoms* [start-date id]
| +--ro id string
| +--ro health-status? uint8
| +--ro label? string
| +--ro start-date yang:date-and-time
| +--ro stop-date? yang:date-and-time
+--rw dependency* [type id]
+--rw type -> /subservices/subservice/type
+--rw id -> /subservices/subservice[type=current()/../type]/id
+--rw dependency-type? identityref
6.3. Concepts
Under some circumstances, vendor-specific subservice types might be
required. As an example of this vendor-specific implementation, this
section shows how to augment the ietf-service-assurance-device module
to add support for the subservice DeviceHealthy, specific to the ACME
Corporation. The new parameter is acme-specific-parameter.
6.4. YANG Module
<CODE BEGINS> file "module example-service-assurance-device-
acme@2019-10-04.yang"
module example-service-assurance-device-acme {
yang-version 1.1;
Claise & Quilbeuf Expires May 7, 2020 [Page 15]
Internet-Draft YANG Modules for Service Assurance November 2019
namespace "urn:example:example-service-assurance-device-acme";
prefix example-service-assurance-device-acme;
import ietf-service-assurance {
prefix "service-assurance";
}
import ietf-service-assurance-device {
prefix "service-assurance-device";
}
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:bclaise@cisco.com>
Author: Jean Quilbeuf <mailto:jquilbeu@cisco.com>";
description
"This module extends the ietf-service-assurance-device module to add
support for the subservice DeviceHealthy, specific to the ACME Corporation.
ACME Network Device 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) 2019 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 2019-10-04 {
description
"Initial revision.";
reference
Claise & Quilbeuf Expires May 7, 2020 [Page 16]
Internet-Draft YANG Modules for Service Assurance November 2019
"RFC xxxx: Title to be completed";
}
identity device-acme-idty {
base service-assurance-device:device-idty;
description "Network Device is healthy.";
}
augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter {
description
"Specify the required parameters for a new subservice type";
container acme-device-idty{
when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')";
description
"Specify the required parameters for the device-acme-idty subservice type";
leaf device {
type string;
description "The device to monitor.";
}
leaf acme-specific-parameter {
type string;
description "The ACME Corporation sepcific parameter.";
}
}
}
}
<CODE ENDS>
7. 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.
TO BE populated according to https://trac.ietf.org/trac/ops/wiki/
yang-security-guidelines
Claise & Quilbeuf Expires May 7, 2020 [Page 17]
Internet-Draft YANG Modules for Service Assurance November 2019
8. IANA Considerations
8.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.
8.2. The YANG Module Names Registry
This document registers two 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
9. Open Issues
-Complete the Security Considerations
10. References
10.1. Normative References
[draft-claise-opsawg-service-assurance-architecture]
Claise, B. and J. Quilbeuf, "draft-claise-opsawg-service-
assurance-architecture", 2019.
[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>.
Claise & Quilbeuf Expires May 7, 2020 [Page 18]
Internet-Draft YANG Modules for Service Assurance November 2019
[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>.
[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>.
10.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>.
[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>.
Acknowledgements
The authors would like to thank Jan Lindlab for his help during the
design of these YANG modules.
Claise & Quilbeuf Expires May 7, 2020 [Page 19]
Internet-Draft YANG Modules for Service Assurance November 2019
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Email: bclaise@cisco.com
Jean Quilbeuf
Cisco Systems, Inc.
1, rue Camille Desmoulins
92782 Issy Les Moulineaux
France
Email: jquilbeu@cisco.com
Claise & Quilbeuf Expires May 7, 2020 [Page 20]