3. Base IETF Service Assurance YANG Module (3. Basis-IETF-Service-Assurance-YANG-Modul)
3. Base IETF Service Assurance YANG Module (3. Basis-IETF-Service-Assurance-YANG-Modul)
3.1. Concepts (3.1. Konzepte)
The "ietf-service-assurance" YANG module assumes a set of subservices to be assured independently. A subservice is a feature or a subpart of the network system that a given service instance depends on. Examples of subservice types include the following:
Das "ietf-service-assurance" YANG-Modul geht von einer Reihe von Subservices aus, die unabhängig voneinander gesichert werden sollen. Ein Subservice ist ein Merkmal oder ein Teil des Netzwerksystems, von dem eine bestimmte Serviceinstanz abhängt. Beispiele für Subservice-Typen sind:
-
device: Whether a device is healthy, and if not, what are the symptoms? Such a subservice might monitor the device resources, such as CPU, RAM, or Ternary Content-Addressable Memory (TCAM). Potential symptoms are "CPU overloaded", "Out of RAM", or "Out of TCAM".
-
device: Ob ein Gerät gesund ist, und wenn nicht, was sind die Symptome? Ein solcher Subservice könnte die Geräteressourcen überwachen, wie CPU, RAM oder Ternary Content-Addressable Memory (TCAM). Potenzielle Symptome sind "CPU überlastet", "Kein RAM mehr" oder "Kein TCAM mehr".
-
ip-connectivity: Given two IP addresses bound to two devices, what is the quality of the IP connectivity between them? Potential symptoms are "No route available" or "Equal-Cost Multipaths (ECMPs) imbalance".
-
ip-connectivity: Gegeben zwei IP-Adressen, die an zwei Geräte gebunden sind, wie ist die Qualität der IP-Konnektivität zwischen ihnen? Potenzielle Symptome sind "Keine Route verfügbar" oder "Ungleichgewicht bei Equal-Cost Multipaths (ECMPs)".
An instance of the device subservice is representing a subpart of the network system, namely a specific device. An instance of the ip-connectivity subservice is representing a feature of the network, namely the connectivity between two specific IP addresses on two devices. In both cases, these subservices might depend on other subservices, for instance, the connectivity might depend on a subservice representing the routing system and on a subservice representing ECMPs.
Eine Instanz des Geräte-Subservices repräsentiert einen Teil des Netzwerksystems, nämlich ein bestimmtes Gerät. Eine Instanz des IP-Konnektivitäts-Subservices repräsentiert ein Merkmal des Netzwerks, nämlich die Konnektivität zwischen zwei bestimmten IP-Adressen auf zwei Geräten. In beiden Fällen können diese Subservices von anderen Subservices abhängen, zum Beispiel könnte die Konnektivität von einem Subservice abhängen, der das Routingsystem repräsentiert, und von einem Subservice, der ECMPs repräsentiert.
The two example subservices presented above need different sets of parameters to fully characterize one of their instances. An instance of the device subservice is fully characterized by a single parameter allowing to identify the device to monitor. For the ip-connectivity subservice, at least the device and IP address for both ends of the link are needed to fully characterize an instance.
Die beiden oben vorgestellten Beispiel-Subservices benötigen unterschiedliche Parametersätze, um eine ihrer Instanzen vollständig zu charakterisieren. Eine Instanz des Geräte-Subservices wird durch einen einzigen Parameter vollständig charakterisiert, der es ermöglicht, das zu überwachende Gerät zu identifizieren. Für den IP-Konnektivitäts-Subservice werden mindestens das Gerät und die IP-Adresse für beide Enden der Verbindung benötigt, um eine Instanz vollständig zu charakterisieren.
The base model presented in this section specifies a single type of subservice, which represents service instances. Such nodes play a particular role in the assurance graph because they represent the starting point, or root, for the assurance graph of the corresponding service instance. The parameters required to fully identify a service instance are the name of the service and the name of the service instance. To support other types of subservices, such as device or ip-connectivity, the "ietf-service-assurance" module is intended to be augmented.
Das in diesem Abschnitt vorgestellte Basismodell spezifiziert einen einzigen Typ von Subservice, der Serviceinstanzen repräsentiert. Solche Knoten spielen im Assurance-Graphen eine besondere Rolle, da sie den Startpunkt oder die Wurzel für den Assurance-Graphen der entsprechenden Serviceinstanz darstellen. Die zur vollständigen Identifizierung einer Serviceinstanz erforderlichen Parameter sind der Name des Dienstes und der Name der Serviceinstanz. Um andere Arten von Subservices wie Gerät oder IP-Konnektivität zu unterstützen, ist das Modul "ietf-service-assurance" zur Erweiterung vorgesehen.
The dependencies are modeled as a list, i.e., each subservice contains a list of references to its dependencies. That list can be empty if the subservice instance does not have any dependencies.
Die Abhängigkeiten werden als Liste modelliert, d. h. jeder Subservice enthält eine Liste von Referenzen auf seine Abhängigkeiten. Diese Liste kann leer sein, wenn die Subservice-Instanz keine Abhängigkeiten hat.
By specifying service instances and their dependencies in terms of subservices, one defines a global assurance graph. That assurance graph is the result of merging all the individual assurance graphs for the assured service instances. Each subservice instance is expected to appear only once in the global assurance graph even if several service instances depend on it. For example, an instance of the device subservice is a dependency of every service instance that relies on the corresponding device. The assurance graph of a specific service instance is the subgraph obtained by traversing the global assurance graph through the dependencies, starting from the specific service instance.
Indem man Serviceinstanzen und ihre Abhängigkeiten in Bezug auf Subservices spezifiziert, definiert man einen globalen Assurance-Graphen. Dieser Assurance-Graph ist das Ergebnis der Zusammenführung aller individuellen Assurance-Graphen für die gesicherten Serviceinstanzen. Es wird erwartet, dass jede Subservice-Instanz nur einmal im globalen Assurance-Graphen erscheint, auch wenn mehrere Serviceinstanzen davon abhängen. Beispielsweise ist eine Instanz des Geräte-Subservices eine Abhängigkeit jeder Serviceinstanz, die auf das entsprechende Gerät angewiesen ist. Der Assurance-Graph einer bestimmten Serviceinstanz ist der Teilgraph, der durch Durchlaufen des globalen Assurance-Graphen durch die Abhängigkeiten erhalten wird, beginnend bei der spezifischen Serviceinstanz.
An assurance agent configured with such a graph is expected to produce, for each configured subservice, a health status that indicates how healthy the subservice is. If the subservice is not healthy, the agent is expected to produce a list of symptoms explaining why the subservice is not healthy.
Von einem mit einem solchen Graphen konfigurierten Assurance-Agenten wird erwartet, dass er für jeden konfigurierten Subservice einen Gesundheitsstatus erstellt, der angibt, wie gesund der Subservice ist. Wenn der Subservice nicht gesund ist, wird vom Agenten erwartet, dass er eine Liste von Symptomen erstellt, die erklären, warum der Subservice nicht gesund ist.
3.2. Tree View (3.2. Baumansicht)
The following tree diagram [RFC8340] provides an overview of the "ietf-service-assurance" module.
Das folgende Baumdiagramm [RFC8340] gibt einen Überblick über das Modul "ietf-service-assurance".
module: ietf-service-assurance
+--ro assurance-graph-last-change yang:date-and-time
+--rw subservices
| +--rw subservice* [type id]
| +--rw type identityref
| +--rw id string
| +--ro last-change? yang:date-and-time
| +--ro label? string
| +--rw under-maintenance!
| | +--rw contact string
| +--rw (parameter)
| | +--:(service-instance-parameter)
| | +--rw service-instance-parameter
| | +--rw service string
| | +--rw instance-name string
| +--ro health-score int8
| +--ro symptoms-history-start? yang:date-and-time
| +--ro symptoms
| | +--ro symptom* [start-date-time agent-id symptom-id]
| | +--ro symptom-id leafref
| | +--ro agent-id -> /agents/agent/id
| | +--ro health-score-weight? uint8
| | +--ro start-date-time yang:date-and-time
| | +--ro stop-date-time? yang:date-and-time
| +--rw dependencies
| +--rw dependency* [type id]
| +--rw type
| | -> /subservices/subservice/type
| +--rw id leafref
| +--rw dependency-type? identityref
+--ro agents
| +--ro agent* [id]
| +--ro id string
| +--ro symptoms* [id]
| +--ro id string
| +--ro description string
+--ro assured-services
+--ro assured-service* [service]
+--ro service leafref
+--ro instances* [name]
+--ro name leafref
+--ro subservices* [type id]
+--ro type -> /subservices/subservice/type
+--ro id leafref
The date of the last change in "assurance-graph-last-change" is read only. It must be updated each time the graph structure is changed by addition or deletion of subservices and dependencies or modifications of their configurable attributes, including their maintenance statuses. Such modifications correspond to a structural change in the graph. The date of the last change is useful for a client to quickly check if there is a need to update the graph structure. A change in the health score or symptoms associated to a service or subservice does not change the structure of the graph, and thus has no effect on the date of the last change.
Das Datum der letzten Änderung in "assurance-graph-last-change" ist schreibgeschützt. Es muss jedes Mal aktualisiert werden, wenn die Graphstruktur durch Hinzufügen oder Löschen von Subservices und Abhängigkeiten oder Änderungen ihrer konfigurierbaren Attribute, einschließlich ihrer Wartungsstatus, geändert wird. Solche Änderungen entsprechen einer strukturellen Änderung im Graphen. Das Datum der letzten Änderung ist nützlich für einen Client, um schnell zu prüfen, ob die Graphstruktur aktualisiert werden muss. Eine Änderung des Gesundheits-Scores oder der Symptome, die einem Service oder Subservice zugeordnet sind, ändert die Struktur des Graphen nicht und hat daher keine Auswirkungen auf das Datum der letzten Änderung.
The "subservices" list contains all the subservice instances currently known by the server (i.e., SAIN agent or SAIN collector). A subservice declaration MUST provide the following:
Die Liste "subservices" enthält alle Subservice-Instanzen, die dem Server (d. h. SAIN-Agent oder SAIN-Kollektor) derzeit bekannt sind. Eine Subservice-Deklaration MUSS Folgendes bereitstellen:
-
a subservice type ("type"): a reference to an identity that inherits from "subservice-base", which is the base identity for any subservice type
-
einen Subservice-Typ ("type"): eine Referenz auf eine Identität, die von "subservice-base" erbt, was die Basisidentität für jeden Subservice-Typ ist
-
an id ("id"): a string uniquely identifying the subservice among those with the same type
-
eine ID ("id"): eine Zeichenfolge, die den Subservice unter denen desselben Typs eindeutig identifiziert
The type and id uniquely identify a given subservice.
Typ und ID identifizieren einen bestimmten Subservice eindeutig.
The "last-change" indicates when the dependencies or maintenance status of this particular subservice were last modified.
"last-change" gibt an, wann die Abhängigkeiten oder der Wartungsstatus dieses bestimmten Subservices zuletzt geändert wurden.
The "label" is a human-readable description of the subservice.
Das "label" ist eine menschenlesbare Beschreibung des Subservices.
The presence of the "under-maintenance" container inhibits the emission of symptoms for the subservice and subservices that depend on them. In that case, a "contact" MUST be provided to indicate who or which software is responsible for the maintenance. See Section 3.6 of [RFC9417] for a more detailed discussion.
Das Vorhandensein des Containers "under-maintenance" verhindert die Ausgabe von Symptomen für den Subservice und Subservices, die davon abhängen. In diesem Fall MUSS ein "contact" angegeben werden, um anzugeben, wer oder welche Software für die Wartung verantwortlich ist. Siehe Abschnitt 3.6 von [RFC9417] für eine detailliertere Diskussion.
The "parameter" choice is intended to be augmented in order to describe parameters that are specific to the current subservice type. This base module defines only the subservice type representing service instances. Service instances MUST be modeled as a particular type of subservice with two parameters: "service" and "instance-name". The "service" parameter is the name of the service defined in the network orchestrator, for instance, "point-to-point-l2vpn". The "instance-name" parameter is the name assigned to the particular instance to be assured, for instance, the name of the customer using that instance.
Die Auswahl "parameter" soll erweitert werden, um Parameter zu beschreiben, die spezifisch für den aktuellen Subservice-Typ sind. Dieses Basismodul definiert nur den Subservice-Typ, der Serviceinstanzen repräsentiert. Serviceinstanzen MÜSSEN als ein bestimmter Typ von Subservice mit zwei Parametern modelliert werden: "service" und "instance-name". Der Parameter "service" ist der Name des im Netzwerk-Orchestrator definierten Dienstes, zum Beispiel "point-to-point-l2vpn". Der Parameter "instance-name" ist der Name, der der bestimmten zu sichernden Instanz zugewiesen ist, zum Beispiel der Name des Kunden, der diese Instanz nutzt.
The "health-score" contains a value normally between 0 and 100, indicating how healthy the subservice is. As mentioned in the health score definition, the special value -1 can be used to specify that no value could be computed for that health score, for instance, if some metric needed for that computation could not be collected.
Der "health-score" enthält einen Wert normalerweise zwischen 0 und 100, der angibt, wie gesund der Subservice ist. Wie in der Definition des Gesundheits-Scores erwähnt, kann der spezielle Wert -1 verwendet werden, um anzugeben, dass kein Wert für diesen Gesundheits-Score berechnet werden konnte, zum Beispiel, wenn eine für diese Berechnung benötigte Metrik nicht gesammelt werden konnte.
The "symptoms-history-start" is the cutoff date for reporting symptoms. Symptoms that were terminated before that date are not reported anymore in the model.
Der "symptoms-history-start" ist das Stichtagsdatum für die Meldung von Symptomen. Symptome, die vor diesem Datum beendet wurden, werden im Modell nicht mehr gemeldet.
The status of each subservice contains a list of symptoms. Each symptom is specified by:
Der Status jedes Subservices enthält eine Liste von Symptomen. Jedes Symptom wird spezifiziert durch:
-
an identifier "symptom-id", which identifies the symptom locally to an agent,
-
einen Bezeichner "symptom-id", der das Symptom lokal für einen Agenten identifiziert,
-
an agent identifier "agent-id", which identifies the agent raising the symptom,
-
einen Agentenbezeichner "agent-id", der den Agenten identifiziert, der das Symptom meldet,
-
a "health-score-weight" specifying the impact to the health score incurred by this symptom,
-
ein "health-score-weight", das die Auswirkung auf den Gesundheits-Score angibt, die durch dieses Symptom verursacht wird,
-
a "start-date-time" indicating when the symptom became active, and
-
eine "start-date-time", die angibt, wann das Symptom aktiv wurde, und
-
a "stop-date-time" indicating when the symptom stopped being active (this field is not present if the symptom is still active).
-
eine "stop-date-time", die angibt, wann das Symptom aufhörte, aktiv zu sein (dieses Feld ist nicht vorhanden, wenn das Symptom noch aktiv ist).
In order for the pair "agent-id" and "symptom-id" to uniquely identify a symptom, the following is necessary:
Damit das Paar "agent-id" und "symptom-id" ein Symptom eindeutig identifiziert, ist Folgendes erforderlich:
-
"agent-id" MUST be unique among all agents of the system.
-
"agent-id" MUSS unter allen Agenten des Systems eindeutig sein.
-
"symptom-id" MUST be unique among all symptoms raised by the agent.
-
"symptom-id" MUSS unter allen vom Agenten gemeldeten Symptomen eindeutig sein.
Note that "agent-id" and "symptom-id" are leafrefs pointing to the objects defined later in the document. While the combination of "symptom-id" and "agent-id" is sufficient as a unique key list, the "start-date-time" second key helps to sort and retrieve relevant symptoms.
Beachten Sie, dass "agent-id" und "symptom-id" leafrefs sind, die auf die später im Dokument definierten Objekte verweisen. Während die Kombination aus "symptom-id" und "agent-id" als eindeutige Schlüsselliste ausreicht, hilft der zweite Schlüssel "start-date-time" beim Sortieren und Abrufen relevanter Symptome.
The "dependency" list contains the dependencies for the current subservice. Each of them is specified by a leafref to both "type" and "id" of the target dependencies. A dependency has a type indicated in the "dependency-type" field. Two types are specified in the model:
Die Liste "dependency" enthält die Abhängigkeiten für den aktuellen Subservice. Jede von ihnen wird durch einen leafref sowohl auf "type" als auch auf "id" der Zielabhängigkeiten spezifiziert. Eine Abhängigkeit hat einen Typ, der im Feld "dependency-type" angegeben ist. Im Modell sind zwei Typen spezifiziert:
-
Impacting: Such a dependency indicates an impact on the health of the dependent.
-
Impacting (Auswirkend): Eine solche Abhängigkeit zeigt eine Auswirkung auf die Gesundheit des Abhängigen an.
-
Informational: Such a dependency might explain why the dependent has issues but does not impact its health.
-
Informational (Informativ): Eine solche Abhängigkeit könnte erklären, warum der Abhängige Probleme hat, wirkt sich jedoch nicht auf seine Gesundheit aus.
To illustrate the difference between "impacting" and "informational", consider the interface subservice representing a network interface. If the device to which the network interface belongs goes down, the network interface will transition to a "down" state as well. Therefore, the dependency of the interface subservice towards the device subservice is "impacting". On the other hand, a dependency towards the ecmp-load subservice, which checks that the load between ECMPs remains stable throughout time, is only "informational". Indeed, services might be perfectly healthy even if the load distribution between ECMPs changed. However, such an instability might be a relevant symptom for diagnosing the root cause of a problem.
Um den Unterschied zwischen "impacting" und "informational" zu veranschaulichen, betrachten Sie den Schnittstellen-Subservice, der eine Netzwerkschnittstelle repräsentiert. Wenn das Gerät, zu dem die Netzwerkschnittstelle gehört, ausfällt, wechselt auch die Netzwerkschnittstelle in einen "down"-Zustand. Daher ist die Abhängigkeit des Schnittstellen-Subservices vom Geräte-Subservice "impacting". Andererseits ist eine Abhängigkeit vom ecmp-load-Subservice, der prüft, ob die Last zwischen ECMPs über die Zeit stabil bleibt, nur "informational". Tatsächlich können Dienste vollkommen gesund sein, auch wenn sich die Lastverteilung zwischen ECMPs geändert hat. Eine solche Instabilität könnte jedoch ein relevantes Symptom für die Diagnose der Ursache eines Problems sein.
Within the container "agents", the list "agent" contains the list of symptoms per agent. The key of the list is the "id", which MUST be unique among agents of a given assurance system. For each agent, the list "symptoms-description" maps an "id" to its "description". The "id" MUST be unique among the symptoms raised by the agent.
Im Container "agents" enthält die Liste "agent" die Liste der Symptome pro Agent. Der Schlüssel der Liste ist die "id", die unter Agenten eines gegebenen Assurance-Systems eindeutig sein MUSS. Für jeden Agenten ordnet die Liste "symptoms-description" eine "id" ihrer "description" zu. Die "id" MUSS unter den vom Agenten gemeldeten Symptomen eindeutig sein.
Within the container "assured-services", the list "assured-service" contains the subservices indexed by assured service instances. For each service type identified by the "service" leaf, all instances of that service are listed in the "instances" list. For each instance identified by the "name" leaf, the "subservices" list contains all descendant subservices that are part of the assurance graph for that specific instance. These imbricated lists provide a query optimization to get the list of subservices in that assurance graph in a single query instead of recursively querying the dependencies of each subservice, starting from the node representing the service instance.
Im Container "assured-services" enthält die Liste "assured-service" die Subservices, indiziert nach gesicherten Serviceinstanzen. Für jeden durch das "service"-Leaf identifizierten Servicetyp werden alle Instanzen dieses Dienstes in der "instances"-Liste aufgeführt. Für jede durch das "name"-Leaf identifizierte Instanz enthält die "subservices"-Liste alle nachgeordneten Subservices, die Teil des Assurance-Graphen für diese spezifische Instanz sind. Diese verschachtelten Listen bieten eine Abfrageoptimierung, um die Liste der Subservices in diesem Assurance-Graphen in einer einzigen Abfrage zu erhalten, anstatt die Abhängigkeiten jedes Subservices rekursiv abzufragen, beginnend beim Knoten, der die Serviceinstanz repräsentiert.
The relation between the health score ("health-score") and the "health-score-weight" of the currently active symptoms is not explicitly defined in this document. The only requirement is that a health score that is strictly smaller than 100 (the maximal value) 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, such a computation could be to sum the "health-score-weight" of the active symptoms, subtract that value from 100, and change the value to 0 if the result is negative. The relation between health score and "health-score-weight" is left to the implementor (of an agent [RFC9417]).
Die Beziehung zwischen dem Gesundheits-Score ("health-score") und dem "health-score-weight" der aktuell aktiven Symptome ist in diesem Dokument nicht explizit definiert. Die einzige Anforderung ist, dass ein Gesundheits-Score, der streng kleiner als 100 (der Maximalwert) ist, durch mindestens ein Symptom erklärt werden muss. Eine Möglichkeit, diese Anforderung durchzusetzen, besteht darin, zuerst Symptome zu erkennen und dann den Gesundheits-Score basierend auf dem "health-score-weight" der erkannten Symptome zu berechnen. Ein Beispiel für eine solche Berechnung wäre, das "health-score-weight" der aktiven Symptome zu summieren, diesen Wert von 100 abzuziehen und den Wert auf 0 zu ändern, wenn das Ergebnis negativ ist. Die Beziehung zwischen Gesundheits-Score und "health-score-weight" bleibt dem Implementierer (eines Agenten [RFC9417]) überlassen.
Keeping the history of the graph structure is out of scope for this YANG module. Only the current version of the assurance graph can be fetched. In order to keep the history of the graph structure, some time-series database (TSDB) or similar storage must be used.
Das Speichern der Historie der Graphstruktur liegt außerhalb des Geltungsbereichs dieses YANG-Moduls. Nur die aktuelle Version des Assurance-Graphen kann abgerufen werden. Um die Historie der Graphstruktur zu speichern, muss eine Zeitreihendatenbank (TSDB) oder ein ähnlicher Speicher verwendet werden.
3.3. YANG Module (3.3. YANG-Modul)
This model contains references to [RFC6991].
Dieses Modell enthält Referenzen auf [RFC6991].
<CODE BEGINS> file "[email protected]"
module ietf-service-assurance {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";
prefix sain;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:[email protected]>
Author: Benoit Claise <mailto:[email protected]>
Author: Jean Quilbeuf <mailto:[email protected]>";
description
"This module defines objects for assuring services based on their
decomposition into so-called subservices, according to the
Service Assurance for Intent-based Networking (SAIN)
architecture.
The subservices hierarchically organized by dependencies
constitute an assurance graph. This module should be supported
by an assurance agent that is able to interact with the devices
in order to produce the health status and symptoms for each
subservice in the assurance graph.
This module is intended for the following use cases:
* Assurance graph 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 statuses of the
subservices, along with the observed symptoms.
Copyright (c) 2023 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 Revised 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 9418; see the
RFC itself for full legal notices. ";
revision 2023-07-11 {
description
"Initial version.";
reference
"RFC 9418: YANG Modules for Service Assurance";
}
identity subservice-base {
description
"Base identity for subservice types.";
}
identity service-instance-type {
base subservice-base;
description
"Specific type of subservice that represents a service
instance. Instance of this type will depend on other
subservices to build the top of the assurance graph.";
}
identity dependency-type {
description
"Base identity for representing dependency types.";
}
identity informational {
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 {
base dependency-type;
description
"Indicates that the status of the dependency directly impacts
the status of the dependent.";
}
grouping subservice-reference {
description
"Reference to a specific subservice identified by its type and
identifier. This grouping is only for internal use in this
module.";
leaf type {
type leafref {
path "/subservices/subservice/type";
}
description
"The type of the subservice to refer to (e.g., device).";
}
leaf id {
type leafref {
path "/subservices/subservice[type=current()/../type]/id";
}
description
"The identifier of the subservice to refer to.";
}
}
grouping subservice-dependency {
description
"Represents a dependency to another subservice. This grouping
is only for internal use in this module";
uses subservice-reference;
leaf dependency-type {
type identityref {
base dependency-type;
}
description
"Represents the type of dependency (e.g., informational or
impacting).";
}
}
leaf assurance-graph-last-change {
type yang:date-and-time;
config false;
mandatory true;
description
"Time and date at which the assurance graph last changed after
any structural changes (dependencies and/or maintenance
windows parameters) are applied to the subservice(s). The
time and date must be the same or more recent than the most
recent value of any changed subservices last-change time and
date.";
}
container subservices {
description
"Root container for the subservices.";
list subservice {
key "type id";
description
"List of configured subservices.";
leaf type {
type identityref {
base subservice-base;
}
description
"Type of the subservice identifying the type of the part
or functionality that is being assured by this list
entry, for instance, interface, device, or
ip-connectivity.";
}
leaf id {
type string;
description
"Identifier of the subservice instance. Must be unique
among subservices of the same type.";
}
leaf last-change {
type yang:date-and-time;
config false;
description
"Date and time at which the structure for this
subservice instance last changed, i.e., dependencies
and/or maintenance windows parameters.";
}
leaf label {
type string;
config false;
description
"Label of the subservice, i.e., text describing what the
subservice is to be displayed on a human interface.
It is not intended for random end users but for
network/system/software engineers that are able to
interpret it. Therefore, no mechanism for language
tagging is needed.";
}
container under-maintenance {
presence "true";
description
"The presence of this container indicates that the current
subservice is under maintenance.";
leaf contact {
type string;
mandatory true;
description
"A string used to model an administratively assigned name
of the resource that is performing maintenance.
It is suggested that this freeform field, which could be
a URI, contains one or more of the following: IP
address, management station name, network manager's
name, location, and/or phone number. It might even
contain the expected maintenance time.
In some cases, the agent itself will be the owner of an
entry. In these cases, this string shall be set to a
string starting with 'monitor'.";
}
}
choice parameter {
mandatory true;
description
"Specify the required parameters per subservice type. Each
module augmenting this module with a new subservice type
that is a new identity based on subservice-base should
augment this choice as well by adding a container
available only if the current subservice type is
the newly added identity.";
container service-instance-parameter {
when "derived-from-or-self(../type,
'sain:service-instance-type')";
description
"Specify the parameters of a service instance.";
leaf service {
type string;
mandatory true;
description
"Name of the service.";
}
leaf instance-name {
type string;
mandatory true;
description
"Name of the instance for that service.";
}
}
// Other modules can augment their own cases into here.
}
leaf health-score {
type int8 {
range "-1 .. 100";
}
config false;
mandatory true;
description
"Score value of the subservice health. A value of 100
means that the 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. The special value
-1 means that the health score could not be computed.";
}
leaf symptoms-history-start {
type yang:date-and-time;
config false;
description
"Date and time at which the symptom's history starts for
this subservice instance, either because the subservice
instance started at that date and time or because the
symptoms before that were removed due to a garbage
collection process.";
}
container symptoms {
config false;
description
"Symptoms for the subservice.";
list symptom {
key "start-date-time agent-id symptom-id";
unique "agent-id symptom-id";
description
"List of symptoms of the subservice. While the
start-date-time key is not necessary per se, this would
get the entries sorted by start-date-time for easy
consumption.";
leaf symptom-id {
type leafref {
path "/agents/agent[id=current()/../agent-id]"
+ "/symptoms/id";
}
description
"Identifier of the symptom to be interpreted according
to the agent identified by the agent-id.";
}
leaf agent-id {
type leafref {
path "/agents/agent/id";
}
description
"Identifier of the agent raising the current symptom.";
}
leaf health-score-weight {
type uint8 {
range "0 .. 100";
}
description
"The weight to the health score incurred by this
symptom. The higher 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 with a
health-score-weight larger than 0.";
}
leaf start-date-time {
type yang:date-and-time;
description
"Date and time at which the symptom was detected.";
}
leaf stop-date-time {
type yang:date-and-time;
description
"Date and time at which the symptom stopped being
detected. Must be after the start-date-time. If the
symptom is ongoing, this field should not be
populated.";
}
}
}
container dependencies {
description
"Indicates the set of dependencies of the current
subservice, along with their types.";
list dependency {
key "type id";
description
"List of dependencies of the subservice.";
uses subservice-dependency;
}
}
}
}
container agents {
config false;
description
"Container for the list of agents' symptoms.";
list agent {
key "id";
description
"Contains symptoms of each agent involved in computing the
health status of the current graph. This list acts as a
glossary for understanding the symptom ids returned by each
agent.";
leaf id {
type string;
description
"Id of the agent for which we are defining the symptoms.
This identifier must be unique among all agents.";
}
list symptoms {
key "id";
description
"List of symptoms raised by the current agent that is
identified by the symptom-id.";
leaf id {
type string;
description
"Id of the symptom for the current agent. The agent must
guarantee the unicity of this identifier.";
}
leaf description {
type string;
mandatory true;
description
"Description of the symptom, i.e., text describing what
the symptom is, is to be computer consumable and
displayed on a human interface.
It is not intended for random end users but for
network/system/software engineers that are able to
interpret it. Therefore, no mechanism for language
tagging is needed.";
}
}
}
}
container assured-services {
config false;
description
"Container for the index of assured services.";
list assured-service {
key "service";
description
"Service instances that are currently part of the assurance
graph. The list must contain an entry for every service
that is currently present in the assurance graph. This list
presents an alternate access to the graph stored in
subservices that optimizes querying the assurance graph of
a specific service instance.";
leaf service {
type leafref {
path "/subservices/subservice/service-instance-parameter/"
+ "service";
}
description
"Name of the service.";
}
list instances {
key "name";
description
"Instances of the service. The list must contain
an entry for every instance of the parent service.";
leaf name {
type leafref {
path "/subservices/subservice/service-instance-parameter"
+ "/instance-name";
}
description
"Name of the service instance. The leafref must point to
a service-instance-parameter whose service leaf matches
the parent service.";
}
list subservices {
key "type id";
description
"Subservices that appear in the assurance graph of the
current service instance.
The list must contain the subservice corresponding to
the service instance, i.e., the subservice that
matches the service and instance-name keys.
For every subservice in the list, all subservices listed
as dependencies must also appear in the list.";
uses subservice-reference;
}
}
}
}
}
<CODE ENDS>
3.4. Rejecting Circular Dependencies (3.4. Ablehnung zirkulärer Abhängigkeiten)
The statuses of services and subservices depend on the statuses of their dependencies, and thus circular dependencies between them prevent the computation of statuses. Section 3.1.1 of the SAIN architecture document [RFC9417] discusses how such dependencies appear and how they could be removed. The responsibility of avoiding such dependencies falls to the SAIN orchestrator. However, we specify in this section the expected behavior when a server supporting the "ietf-service-assurance" module receives a data instance containing circular dependencies.
Die Status von Diensten und Subservices hängen von den Status ihrer Abhängigkeiten ab, und daher verhindern zirkuläre Abhängigkeiten zwischen ihnen die Berechnung der Status. Abschnitt 3.1.1 des SAIN-Architekturdokuments [RFC9417] erörtert, wie solche Abhängigkeiten entstehen und wie sie entfernt werden könnten. Die Verantwortung für die Vermeidung solcher Abhängigkeiten liegt beim SAIN-Orchestrator. In diesem Abschnitt spezifizieren wir jedoch das erwartete Verhalten, wenn ein Server, der das Modul "ietf-service-assurance" unterstützt, eine Dateninstanz empfängt, die zirkuläre Abhängigkeiten enthält.
Enforcing the absence of circular dependencies as a YANG constraint falls back to implementing a graph traversal algorithm with XPath and checking that the current node is not reachable from its dependencies. Even with such a constraint, there is no guarantee that merging two graphs without dependency loops will result in a graph without dependency loops. Indeed, Section 3.1.1 of [RFC9417] presents an example where merging two graphs without dependency loops results in a graph with a dependency loop.
Die Durchsetzung der Abwesenheit zirkulärer Abhängigkeiten als YANG-Constraint läuft darauf hinaus, einen Graphendurchlaufalgorithmus mit XPath zu implementieren und zu prüfen, ob der aktuelle Knoten von seinen Abhängigkeiten aus nicht erreichbar ist. Selbst mit einer solchen Einschränkung gibt es keine Garantie, dass das Zusammenführen von zwei Graphen ohne Abhängigkeitsschleifen zu einem Graphen ohne Abhängigkeitsschleifen führt. Tatsächlich zeigt Abschnitt 3.1.1 von [RFC9417] ein Beispiel, bei dem das Zusammenführen von zwei Graphen ohne Abhängigkeitsschleifen zu einem Graphen mit einer Abhängigkeitsschleife führt.
Therefore, a server implementing the "ietf-service-assurance" module MUST check that there is no dependency loop whenever the graph is modified. A modification creating a dependency loop MUST be rejected.
Daher MUSS ein Server, der das Modul "ietf-service-assurance" implementiert, jedes Mal prüfen, ob eine Abhängigkeitsschleife vorliegt, wenn der Graph geändert wird. Eine Änderung, die eine Abhängigkeitsschleife erzeugt, MUSS abgelehnt werden.