[要約] RFC 9418 は、サービスの保証を表現するためのYANGモジュールを定義しており、サービスを分解してサブサービスとして表現します。目的は、Intent-Based Networking Architectureにおけるサービスの保証を実装するためのアーキテクチャを提供することです。
Internet Engineering Task Force (IETF) B. Claise
Request for Comments: 9418 J. Quilbeuf
Category: Standards Track Huawei
ISSN: 2070-1721 P. Lucente
NTT
P. Fasano
TIM S.p.A
T. Arumugam
Consultant
July 2023
This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices. The companion document, "Service Assurance for Intent-Based Networking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services.
このドキュメントは、保証グラフを表すためのYangモジュールを指定します。これらのグラフは、属と呼ばれる原子保証要素に分解することにより、特定のサービスの保証を表しています。コンパニオンドキュメント「Intentベースのネットワーキングアーキテクチャのサービス保証」（RFC 9417）は、そのようなサービスの保証を実装するためのアーキテクチャを提示します。
The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
このドキュメントのYangデータモデルは、RFC 8342で定義されているネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9418.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9418で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. YANG Modules Overview
3. Base IETF Service Assurance YANG Module
3.1. Concepts
3.2. Tree View
3.3. YANG Module
3.4. Rejecting Circular Dependencies
4. Guidelines for Defining New Subservice Types
5. Subservice Augmentation: "ietf-service-assurance-device" YANG
Module
5.1. Tree View
5.2. Concepts
5.3. YANG Module
6. Subservice Augmentation: "ietf-service-assurance-interface"
YANG Module
6.1. Tree View
6.2. Concepts
6.3. YANG Module
7. Security Considerations
8. IANA Considerations
8.1. The IETF XML Registry
8.2. The YANG Module Names Registry
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Vendor-Specific Subservice Augmentation:
"example-service-assurance-device-acme" YANG Module
A.1. Tree View
A.2. Concepts
A.3. YANG Module
Appendix B. Further Augmentations: IP Connectivity and IS-IS
Subservices
B.1. IP Connectivity Module Tree View
B.2. IS-IS Module Tree View
B.3. Global Tree View
B.4. IP Connectivity YANG Module
B.5. IS-IS YANG Module
Appendix C. Example of a YANG Instance
Appendix D. YANG Library for Service Assurance
Acknowledgements
Authors' Addresses
[RFC9417] describes an architecture and a set of involved components for service assurance, called Service Assurance for Intent-based Networking (SAIN). This document complements the architecture by specifying a data model for the interfaces between components. More specifically, the document provides YANG modules for the purpose of service assurance in a format that is:
[RFC9417]は、意図ベースのネットワーキング（SAIN）のサービス保証と呼ばれるサービス保証のためのアーキテクチャと関連するコンポーネントのセットについて説明しています。このドキュメントは、コンポーネント間のインターフェイスのデータモデルを指定することにより、アーキテクチャを補完します。より具体的には、このドキュメントは、次の形式でサービス保証を目的としてYangモジュールを提供します。
* machine readable,
* 読みやすいマシン、
* vendor independent, and
* ベンダー独立、および
* augmentable such that SAIN agents from Figure 1 of [RFC9417] can support and expose new subservices to SAIN orchestrators and collectors.
* [RFC9417]の図1のSAINエージェントが、新しいサブサービスをSain Orchestrators and Collectorsにサポートおよび暴露できるように拡張可能です。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The terms used in this document are defined in [RFC9417].
このドキュメントで使用される用語は、[RFC9417]で定義されています。
The meanings of the symbols in the tree diagrams are defined in [RFC8340].
ツリー図のシンボルの意味は、[RFC8340]で定義されています。
The main YANG module, "ietf-service-assurance" (Section 3), defines objects for assuring network services based on their decomposition into so-called subservices. The subservices are hierarchically organized by dependencies. The subservices, along with the dependencies, constitute an assurance graph. This module should be supported by an agent that is able to interact with the devices in order to produce the health statuses and symptoms for each subservice in an assurance graph. This module is intended for the following use cases:
メインのYangモジュール「IETF-Service Assurance」（セクション3）は、いわゆるサブサービスへの分解に基づいてネットワークサービスを保証するためのオブジェクトを定義しています。サブサービスは、依存関係によって階層的に編成されています。サブサービスは、依存関係とともに、保証グラフを構成します。このモジュールは、保証グラフで各サブサービスの健康状態と症状を生成するために、デバイスと対話できるエージェントによってサポートされる必要があります。このモジュールは、次のユースケースを対象としています。
* 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 types.
- 依存関係：サブサービス間の依存関係をそのタイプとともに構成します。
* Assurance telemetry: Export the assurance graph with health statuses and symptoms for each node.
* 保証テレメトリー：各ノードの健康状態と症状で保証グラフをエクスポートします。
The module is also intended to be exported by the SAIN collector that aggregates the output of several SAIN agents to provide the global assurance graph. In that case, only the telemetry export use case is considered.
このモジュールは、いくつかのSAINエージェントの出力を集約してグローバルな保証グラフを提供するSainコレクターによってエクスポートされることも目的としています。その場合、テレメトリーエクスポートユースケースのみが考慮されます。
The modules presented in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].
このドキュメントで提示されたモジュールは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。
The second YANG module, "ietf-service-assurance-device" (Section 5), augments the "ietf-service-assurance" module by adding support for the device subservice. Additional subservice types might be added following a similar approach.
2番目のYangモジュール「IETF-Service-Assurance-Device」（セクション5）は、デバイスサブサービスのサポートを追加することにより、「IETF-Service-Assurance」モジュールを増強します。同様のアプローチに従って、追加のサブサービスタイプが追加される場合があります。
The third YANG module, "ietf-service-assurance-interface" (Section 6), augments the "ietf-service-assurance" module as well by adding support for the interface subservice.
3番目のYangモジュール「IETF-Service-Assurance-Interface」（セクション6）は、インターフェイスサブサービスのサポートを追加することにより、「IETF-Service-Assurance」モジュールを増強します。
We provide additional examples in the appendix. The module "example-service-assurance-device-acme" (Appendix A) augments the "ietf-service-assurance-device" module to customize it for devices of the fictional Acme Corporation. Additional vendor-specific parameters might be added following a similar approach. We also provide the modules "example-service-assurance-ip-connectivity" and "example-service-assurance-is-is" (Appendix B) to model the example in Figure 2 from Section 3.1 of [RFC9417].
付録に追加の例を示します。モジュール「Example-Service-Assurance-Device-Acme」（付録A）は、「IETF-Service-Assurance-Device」モジュールを拡張して、架空のACMEコーポレーションのデバイス用にカスタマイズします。同様のアプローチに従って、追加のベンダー固有のパラメーターが追加される場合があります。また、[RFC9417]のセクション3.1の図2の例をモデル化するために、「サンプルアシュアランス-IP接続性」および「サンプルサービスアシュアランスIS-IS」（付録B）（付録B）モジュールを提供します。
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:
「IETF-Service-Assurance」Yangモジュールは、独立して保証される一連のサブサービスを想定しています。サブサービスは、特定のサービスインスタンスが依存するネットワークシステムの機能またはサブパートです。サブサービスタイプの例には、以下が含まれます。
* 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".
* デバイス：デバイスが健康であるかどうか、そうでない場合、症状は何ですか？このようなサブサービスは、CPU、RAM、または成分コンテンツアドレス可能なメモリ（TCAM）などのデバイスリソースを監視する場合があります。潜在的な症状は、「CPU過負荷」、「RAMからの外」、または「TCAMから」です。
* 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接続性：2つのIPアドレスが2つのデバイスにバインドされている場合、それらの間のIP接続の品質はどれくらいですか？潜在的な症状は、「利用可能なルートなし」または「等しいコストのマルチパス（ECMP）の不均衡」です。
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.
デバイスサブサービスのインスタンスは、ネットワークシステムのサブパート、つまり特定のデバイスを表しています。IP接続性サブサービスのインスタンスは、ネットワークの機能、つまり2つのデバイス上の2つの特定のIPアドレス間の接続を表しています。どちらの場合も、これらのサブサービスは他のサブサービスに依存する場合があります。たとえば、接続性は、ルーティングシステムを表すサブサービスとECMPを表すサブサービスに依存する場合があります。
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.
上記の2つの例には、インスタンスの1つを完全に特徴付けるために、さまざまなパラメーターセットが必要です。デバイスサブサービスのインスタンスは、監視するデバイスを識別できる単一のパラメーターによって完全に特徴付けられます。IP接続性のサブサービスの場合、インスタンスを完全に特性化するには、少なくともリンクの両端のデバイスとIPアドレスが必要です。
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.
このセクションに示されている基本モデルは、サービスインスタンスを表す単一のタイプのサブサービスを指定します。このようなノードは、対応するサービスインスタンスの保証グラフに対して開始点またはルートを表すため、保証グラフで特定の役割を果たします。サービスインスタンスを完全に識別するために必要なパラメーターは、サービスの名前とサービスインスタンスの名前です。デバイスやIP接続性などの他のタイプのサブサービスをサポートするために、「IETF-Service-Assuransurance」モジュールを増強することを目的としています。
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.
依存関係はリストとしてモデル化されています。つまり、各サブサービスにはその依存関係への参照のリストが含まれています。サブサービスインスタンスに依存関係がない場合、そのリストは空になる可能性があります。
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.
サービスインスタンスとその依存関係をサブサービスの観点から指定することにより、グローバル保証グラフを定義します。その保証グラフは、保証されたサービスインスタンスのすべての個々の保証グラフをマージした結果です。各サブサービスインスタンスは、いくつかのサービスインスタンスに依存していても、グローバル保証グラフに1回のみ表示されると予想されます。たとえば、デバイスサブサービスのインスタンスは、対応するデバイスに依存するすべてのサービスインスタンスの依存関係です。特定のサービスインスタンスの保証グラフは、特定のサービスインスタンスから始まる依存関係を通じてグローバル保証グラフを通過することによって得られるサブグラフです。
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.
このようなグラフで構成された保証エージェントは、構成された各サブサービスに対して、サブサービスがどれほど健康であるかを示す健康状態を生成すると予想されます。サブサービスが健康でない場合、エージェントは、サブサービスが健康でない理由を説明する症状のリストを作成することが期待されます。
The following tree diagram [RFC8340] provides an overview of the "ietf-service-assurance" module.
次のツリー図[RFC8340]は、「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.
「Assurance-Graph-Last-Change」の最後の変更の日付は読み取り専用です。メンテナンスステータスを含む構成可能な属性のサブサービスと依存関係または変更によってグラフ構造が変更されるたびに更新する必要があります。このような変更は、グラフの構造変化に対応しています。最後の変更の日付は、クライアントがグラフ構造を更新する必要があるかどうかをすばやく確認するのに役立ちます。サービスまたはサブサービスに関連する健康スコアまたは症状の変更は、グラフの構造を変更せず、したがって、最後の変更の日付に影響を与えません。
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:
「サブサービス」リストには、現在サーバー（つまり、SainエージェントまたはSainコレクター）で知られているすべてのサブサービスインスタンスが含まれています。サブサービス宣言は、以下を提供する必要があります。
* a subservice type ("type"): a reference to an identity that inherits from "subservice-base", which is the base identity for any subservice type
* サブサービスタイプ（「タイプ」）：「サブサービスベース」から継承するアイデンティティへの参照。
* an id ("id"): a string uniquely identifying the subservice among those with the same type
* ID（ "id"）：同じタイプの人の間でサブサービスを一意に識別する文字列
The type and id uniquely identify a given subservice.
タイプとIDは、特定のサブサービスを一意に識別します。
The "last-change" indicates when the dependencies or maintenance status of this particular subservice were last modified.
「最後の変更」は、この特定のサブサービスの依存関係またはメンテナンスステータスが最後に変更されたことを示します。
The "label" is a human-readable description of the subservice.
「ラベル」は、サブサービスの人間が読みやすい説明です。
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.
「メンテナンスを下回っていない」容器の存在は、それらに依存するサブサービスおよびサブサービスの症状の放出を阻害します。その場合、「連絡先」を提供して、誰がどのソフトウェアがメンテナンスに責任を負っているかを示す必要があります。より詳細な議論については、[RFC9417]のセクション3.6を参照してください。
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.
「パラメーター」の選択は、現在のサブサービスタイプに固有のパラメーターを記述するために拡張することを目的としています。このベースモジュールは、サービスインスタンスを表すサブサービスタイプのみを定義します。サービスインスタンスは、「サービス」と「インスタンスネーム」の2つのパラメーターを備えた特定のタイプのサブサービスとしてモデル化する必要があります。「サービス」パラメーターは、たとえば「ポイントツーポイントL2VPN」など、ネットワークオーケストレーターで定義されているサービスの名前です。「Instance-Name」パラメーターは、特定のインスタンスに割り当てられた名前です。たとえば、そのインスタンスを使用して顧客の名前です。
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.
「ヘルススコア」には、通常0〜100の間の値が含まれており、サブサーブがどれほど健康であるかを示しています。ヘルススコアの定義で述べたように、特別な値-1を使用して、たとえばそのヘルススコアに対して値を計算できないことを指定できます。たとえば、その計算に必要なメトリックを収集できなかった場合。
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.
「症状の歴史のスタート」は、症状を報告するためのカットオフ日です。その日より前に終了した症状は、モデルではもう報告されていません。
The status of each subservice contains a list of symptoms. Each symptom is specified by:
各サブサービスのステータスには、症状のリストが含まれています。各症状は次のように指定されています。
* an identifier "symptom-id", which identifies the symptom locally to an agent,
* 識別子「症状ID」。これは、症状を局所的にエージェントに識別する、
* an agent identifier "agent-id", which identifies the agent raising the symptom,
* 症状を引き起こすエージェントを識別するエージェント識別子「エージェントID」、
* a "health-score-weight" specifying the impact to the health score incurred by this symptom,
* この症状によって生じた健康スコアへの影響を指定する「ヘルススコア重量」、
* a "start-date-time" indicating when the symptom became active, and
* 症状が活性になったことを示す「起業時」と
* a "stop-date-time" indicating when the symptom stopped being active (this field is not present if the symptom is still active).
* 症状が活動しなくなったときを示す「停止日」（症状がまだ活動している場合、このフィールドは存在しません）。
In order for the pair "agent-id" and "symptom-id" to uniquely identify a symptom, the following is necessary:
ペア「エージェント-ID」と「症状ID」が症状を一意に識別するためには、以下が必要です。
* "agent-id" MUST be unique among all agents of the system.
* 「エージェントID」は、システムのすべてのエージェントの中でユニークでなければなりません。
* "symptom-id" MUST be unique among all symptoms raised by the agent.
* 「症状ID」は、薬剤によって提起されたすべての症状の中で一意でなければなりません。
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.
「Agent-ID」と「症状ID」は、文書の後半で定義されたオブジェクトを指す葉であることに注意してください。「症状ID」と「エージェント-ID」の組み合わせは一意のキーリストとして十分ですが、「開始日」の2番目のキーは、関連する症状を整理して取得するのに役立ちます。
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:
「依存関係」リストには、現在のサブサービスの依存関係が含まれています。それらのそれぞれは、ターゲット依存関係の「タイプ」と「ID」の両方にleafrefによって指定されます。依存関係には、「依存型」フィールドに示されたタイプがあります。モデルで2つのタイプが指定されています。
* Impacting: Such a dependency indicates an impact on the health of the dependent.
* 影響：そのような依存関係は、依存関係者の健康への影響を示します。
* Informational: Such a dependency might explain why the dependent has issues but does not impact its health.
* 情報：このような依存関係は、依存者が問題を抱えているが、その健康に影響を与えない理由を説明するかもしれません。
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.
「影響」と「情報」の違いを説明するには、ネットワークインターフェイスを表すインターフェイスサブサービスを検討してください。ネットワークインターフェイスが属するデバイスがダウンした場合、ネットワークインターフェイスは「ダウン」状態にも移行します。したがって、インターフェイスサブサービスのデバイスサブサービスへの依存性は「影響を与えています」。一方、ECMP負荷のサブサービスへの依存関係は、ECMP間の負荷が長期にわたって安定したままであることをチェックするものであり、「情報」にすぎません。実際、ECMP間の負荷分布が変更されたとしても、サービスは完全に健康である可能性があります。ただし、そのような不安定性は、問題の根本原因を診断するための関連する症状かもしれません。
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.
コンテナの「エージェント」内に、リスト「エージェント」には、エージェントあたりの症状のリストが含まれています。リストのキーは「ID」です。これは、特定の保証システムのエージェント間でユニークでなければなりません。各エージェントについて、リスト「症状説明」は「説明」に「ID」をマッピングします。「ID」は、エージェントによって提起された症状の中で一意でなければなりません。
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.
コンテナの「Assured-Services」内に、リスト「Assured-Service」には、保証されたサービスインスタンスによってインデックスが付けられたサブサービスが含まれています。「サービス」リーフによって識別された各サービスタイプについて、そのサービスのすべてのインスタンスは「インスタンス」リストにリストされています。「名前」リーフで識別された各インスタンスについて、「サブサービス」リストには、その特定のインスタンスの保証グラフの一部であるすべての子孫のサブサービスが含まれています。これらの具体化されたリストは、サービスインスタンスを表すノードから開始する各サブサービスの依存関係を再帰的にクエリする代わりに、その保証グラフのサブサービスのリストを単一のクエリで取得するクエリの最適化を提供します。
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]).
現在活動的な症状のヘルススコア（「ヘルススコア」）と「ヘルススコア重量」との関係は、このドキュメントでは明示的に定義されていません。唯一の要件は、厳密に100を超える（最大値）が少なくとも1つの症状で説明する必要があることです。その要件を強制する方法は、最初に症状を検出し、検出された症状の「健康スコア重量」に基づいて健康スコアを計算することです。例として、このような計算は、活性症状の「健康スコア重量」を合計し、その値を100から減算し、結果が負の場合は値を0に変更することです。ヘルススコアと「ヘルススコア重量」の関係は、（エージェント[RFC9417]）実装者に任されています。
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.
グラフ構造の履歴を維持することは、このYangモジュールの範囲外です。保証グラフの現在のバージョンのみを取得できます。グラフ構造の履歴を維持するには、いくつかの時系列データベース（TSDB）または同様のストレージを使用する必要があります。
This model contains references to [RFC6991].
このモデルには、[RFC6991]への参照が含まれています。
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:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeu@huawei.com>";
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;
}
}
}
}
}
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.
サービスとサブサービスのステータスは、依存関係のステータスに依存するため、それらの間の循環依存関係はステータスの計算を防ぎます。SAINアーキテクチャドキュメント[RFC9417]のセクション3.1.1では、そのような依存関係がどのように表示され、どのように削除できるかについて説明します。そのような依存関係を回避する責任は、セインオーケストレーターに分類されます。ただし、このセクションでは、「IETF-Service-Assurance」モジュールをサポートするサーバーが円形の依存関係を含むデータインスタンスを受信する場合、予想される動作を指定します。
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.
ヤンの制約としての円形の依存関係が存在しないことは、XPathを使用したグラフトラバーサルアルゴリズムの実装と、現在のノードがその依存関係から到達できないことを確認することに戻ります。このような制約があっても、依存関係ループなしで2つのグラフをマージすると、依存関係ループなしでグラフが生じるという保証はありません。実際、[RFC9417]のセクション3.1.1は、依存性ループなしで2つのグラフをマージすると、依存性ループを備えたグラフをもたらす例を示しています。
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.
したがって、「IETF-Service-Assurance」モジュールを実装するサーバーは、グラフが変更されるたびに依存関係ループがないことを確認する必要があります。依存関係ループを作成する変更を拒否する必要があります。
The base YANG module defined in Section 3.3 only defines a single type of subservice that represent service instances. As explained above, this model is meant to be augmented so that a variety of subservices can be used in the assurance graph. In this section, we propose some guidelines for specifying such extensions at IETF.
セクション3.3で定義されているベースヤンモジュールは、サービスインスタンスを表す単一のタイプのサブサービスのみを定義します。上で説明したように、このモデルは、保証グラフでさまざまなサブサービスを使用できるように拡張することを目的としています。このセクションでは、IETFでこのような拡張機能を指定するためのいくつかのガイドラインを提案します。
The mechanism to add a new subservice type is to define a new module for that subservice. The module name should start with "ietf-service-assurance-". The namespace of the module should start with "urn:ietf:params:xml:ns:yang:ietf-service-assurance-". The prefix of the module should start with "sain-". For instance, the subservice type representing the assurance of a device should have:
新しいサブサービスタイプを追加するメカニズムは、そのサブサービスの新しいモジュールを定義することです。モジュール名は、「IETF-Service-Assurance-」で始まる必要があります。モジュールの名前空間は、「urn：ietf：params：xml：ns：yang：ietf-service-assurance-」から始める必要があります。モジュールの接頭辞は、「sain-」から始める必要があります。たとえば、デバイスの保証を表すサブサービスタイプには次のものがあります。
* the name "ietf-service-assurance-device",
* 「ietf-service-assulsurance-device」という名前、
* the namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", and
* 名前空間「urn：ietf：params：xml：ns：yang：ietf-service-assurance-device」、および
* the prefix "sain-device".
* 接頭辞「sain-device」。
The new module should define:
新しいモジュールは定義する必要があります。
* a new identity to represent the new type and
* 新しいタイプを表すための新しいアイデンティティ
* the parameters fully specifying an instance of the new subservice type.
* 新しいサブサービスタイプのインスタンスを完全に指定するパラメーター。
The new identity should be based on the "subservice-base" identity. The name of the identity should end with "-type", for instance, "device-type".
新しいアイデンティティは、「サブサービスベース」アイデンティティに基づいている必要があります。アイデンティティの名前は、「-Type」、たとえば「デバイスタイプ」で終了する必要があります。
The parameters should be defined in a container named "parameters" that augments the choice "/subservices/subservice/parameter" from the main module. The augmentation should be restricted to cases where the type of the subservice matches the identity representing the new service type.
パラメーターは、メインモジュールからの選択を補強する「パラメーター」/サブサービス/サブサービス/パラメーター」という名前のコンテナで定義する必要があります。増強は、サブサービスのタイプが新しいサービスタイプを表すアイデンティティと一致する場合に制限する必要があります。
We define two subservice types in the next sections: the "device" subservice type is defined in Section 5 and the "interface" subservice type is defined is Section 6. These subservices can be taken as examples of the rules defined in this section.
次のセクションで2つのサブサービスタイプを定義します。「デバイス」サブサービスタイプはセクション5で定義され、「インターフェイス」サブサービスタイプはセクション6です。これらのサブサービスは、このセクションで定義されているルールの例として使用できます。
Vendors can specify their own subservices types by defining the corresponding modules in their own namespace. An example of such a vendor-specific module is specified in Appendix A. Vendors can also augment existing IETF-specified subservices to add their own vendor-specific information.
ベンダーは、自分の名前空間で対応するモジュールを定義することにより、独自のサブサービスタイプを指定できます。このようなベンダー固有のモジュールの例は、付録Aに指定されています。ベンダーは、既存のIETF指定のサブサービスを強化して、独自のベンダー固有の情報を追加することもできます。
The following tree diagram [RFC8340] provides an overview of the "ietf-service-assurance-device" module.
次のツリー図[RFC8340]は、「IETF-Service-Assurance-Device」モジュールの概要を示しています。
module: ietf-service-assurance-device
augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters
+--rw device string
A complete tree view of the base module with all augmenting modules presented in this document is available in Appendix B.3.
このドキュメントに示されているすべての拡張モジュールを備えたベースモジュールの完全なツリービューは、付録B.3に入手できます。
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 its type and expected parameters. Let us illustrate the example of the new device subservice type. As the name implies, it monitors and reports the device health, along with some symptoms in case of degradation.
サブサービスの数は時間とともに増加するため、Yangモジュールは拡張可能になるように設計されています。新しいサブサービスタイプには、そのタイプと予想されるパラメーターの正確な仕様が必要です。新しいデバイスサブサービスタイプの例を説明しましょう。名前が示すように、それは劣化の場合のいくつかの症状とともに、デバイスの健康を監視および報告します。
For our device subservice definition, the new identity "device-type" 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.
デバイスのサブサービス定義では、新しいID「デバイスタイプ」が、サブサービスのベースアイデンティティからの継承として指定されています。これは、保証エージェントに、現在デバイスの健康を保証していることを示しています。
The typical parameter for the configuration of the device subservice is the name of the device that we want to assure. By augmenting the parameter choice from the "ietf-service-assurance" YANG module for the case of the "device-type" subservice type, this new parameter is specified.
デバイスサブサービスの構成の典型的なパラメーターは、保証するデバイスの名前です。「Device-Type」サブサービスタイプの場合の「IETF-Service Assulsurance」Yangモジュールからパラメーター選択を拡張することにより、この新しいパラメーターが指定されています。
module ietf-service-assurance-device {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-device";
prefix sain-device;
import ietf-service-assurance {
prefix sain;
reference
"RFC 9418: YANG Modules for Service Assurance";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This module augments the ietf-service-assurance module with
support of the device subservice.
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 revision.";
reference
"RFC 9418: YANG Modules for Service Assurance";
}
identity device-type {
base sain:subservice-base;
description
"Identity of device subservice.";
}
augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'device-type')";
description
"Augments the parameter choice from the ietf-service-assurance
module with a case specific to the device subservice.";
container parameters {
description
"Parameters for the device subservice type.";
leaf device {
type string;
mandatory true;
description
"Identifier of the device to monitor. The
identifier (e.g., device id, hostname, or management IP)
depends on the context.";
}
}
}
}
The following tree diagram [RFC8340] provides an overview of the "ietf-service-assurance-interface" data model.
次のツリー図[RFC8340]は、「IETF-Service-Assurance-Interface」データモデルの概要を示しています。
module: ietf-service-assurance-interface
augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters
+--rw device string
+--rw interface string
A complete tree view of the base module with all augmenting modules presented in this document is available in Appendix B.3.
このドキュメントに示されているすべての拡張モジュールを備えたベースモジュールの完全なツリービューは、付録B.3に入手できます。
For the interface subservice definition, the new interface-type 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 an interface.
インターフェイスサブサービス定義の場合、新しいインターフェイスタイプは、サブサービスのベースアイデンティティからの継承として指定されています。これは、保証エージェントに、私たちが現在インターフェイスの健康を保証していることを示しています。
The parameters for the configuration of the interface subservice are the name of the device and, on that specific device, a specific interface. These parameters are aligned with the "ietf-interfaces" model described in [RFC8343], where the name of the interface is the only key needed to identify an interface on a given device. By augmenting the parameter choice from the "ietf-service-assurance" YANG module for the case of the interface-type subservice type, those two new parameters are specified.
インターフェイスサブサービスの構成のパラメーターは、デバイスの名前であり、その特定のデバイスでは、特定のインターフェイスです。これらのパラメーターは、[RFC8343]で説明されている「IETFインターフェイス」モデルに整合しています。インターフェイスの名前は、特定のデバイス上のインターフェイスを識別するために必要な唯一の鍵です。インターフェイスタイプのサブサービスタイプの場合の「IETF-Service Assursurance」Yangモジュールからパラメーター選択を拡張することにより、これら2つの新しいパラメーターが指定されています。
module ietf-service-assurance-interface {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface";
prefix sain-interface;
import ietf-service-assurance {
prefix sain;
reference
"RFC 9418: YANG Modules for Service Assurance";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This module extends the ietf-service-assurance module to add
support for the interface subservice.
It checks whether an interface is healthy.
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 revision.";
reference
"RFC 9418: YANG Modules for Service Assurance";
}
identity interface-type {
base sain:subservice-base;
description
"Checks whether an interface is healthy.";
}
augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'interface-type')";
description
"Augments the parameter choice from ietf-service-assurance
module with a case specific to the interface subservice.";
container parameters {
description
"Parameters for the interface subservice type.";
leaf device {
type string;
mandatory true;
description
"Device supporting the interface.";
}
leaf interface {
type string;
mandatory true;
description
"Name of the interface.";
}
}
}
}
The YANG modules specified in this document define 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].
このドキュメントで指定されたYangモジュールは、NetConf [RFC6241]やRestConf [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義しています。最低のネットコン層は安全な輸送層であり、実装から実装の安全な輸送は安全なシェル（SSH）[RFC6242]です。最も低いRESTCONF層はHTTPSであり、実装対象の安全な輸送は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.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に設定されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。
There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
これらのYangモジュールには、書き込み可能/クリエーション/削除可能な（つまり、デフォルトである構成）。これらのデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしにこれらのデータノードに操作を書き込む（例：編集config）は、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノードとその感度/脆弱性です。
* /subservices/subservice : By modifying this subtree, one can modify the structure of the assurance graph, which could alter the status of the services reported by the assurance framework. On one hand, modifications can cause the assurance system to report a service as broken when it is actually healthy (false positive), resulting in engineers or automation software losing time and potentially causing real issues by doing unnecessary modifications on the network. On the other hand, modifications could prevent the assurance system from reporting actual issues (false negative), resulting in failures that could have been avoided. Depending on the service, the impact of these avoidable failures could be Service-Level Agreement (SLA) violations fees or disruption of emergency calls.
* /サブサービス/サブサービス：このサブツリーを変更することにより、保証グラフの構造を変更できます。これにより、保証フレームワークによって報告されたサービスのステータスが変更されます。一方では、修正により、保証システムが実際に健康であるときに壊れたものとしてサービスを報告する可能性があり、エンジニアまたは自動化ソフトウェアが時間を失い、ネットワーク上で不必要な変更を行うことで実際の問題を引き起こす可能性があります。一方、変更により、保証システムが実際の問題を報告するのを防ぐ可能性があり（偽陰性）、避けられる可能性のある障害が発生する可能性があります。サービスに応じて、これらの回避可能な障害の影響は、サービスレベル契約（SLA）違反手数料または緊急電話の混乱になる可能性があります。
Some readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
これらのYangモジュールのいくつかの読み取り可能なデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（GET、GetConfig、または通知を介して）を制御することが重要です。これらは、サブツリーとデータノードとその感度/脆弱性です。
* /subservices/subservice
* /サブサービス/サブサービス
* /agents/agent
* /エージェント/エージェント
* /assured-services/assured-service
* /ASSURED-SERVICES/ASSURED-SERVICE
Each of these subtrees contains information about services, subservices, or possible symptoms raised by the agents. The information contained in this subtree might give information about the underlying network as well as services deployed for the customers. For instance, a customer might be given access to monitor their services status (e.g., via model-driven telemetry). In that example, the customer access should be restricted to nodes representing their services so as not to divulge information about the underlying network structure or others customers services.
これらのサブツリーにはそれぞれ、エージェントによって提起されたサービス、サブサービス、または可能な症状に関する情報が含まれています。このサブツリーに含まれる情報は、顧客向けに展開されているサービスだけでなく、基礎となるネットワークに関する情報を提供する場合があります。たとえば、顧客には、サービスステータスを監視するためにアクセスできる場合があります（例：モデル駆動型テレメトリを介して）。その例では、顧客のアクセスは、基礎となるネットワーク構造またはその他の顧客サービスに関する情報を漏らさないように、サービスを表すノードに制限する必要があります。
IANA has registered the following three URIs in the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XMLレジストリ」[RFC3688]に次の3つのURIを登録しました。
URI:
URI：
urn:ietf:params:xml:ns:yang:ietf-service-assurance
urn：ietf：params：xml：ns：yang：ietf-service-assurance
Registrant Contact:
登録者の連絡先：
The OPSAWG WG of the IETF.
IETFのopsawg wg。
XML:
XML：
N/A; the requested URI is an XML namespace.
n/a;要求されたURIはXMLネームスペースです。
URI:
URI：
urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
urn：ietf：params：xml：ns：yang：ietf-service-assurance-device
Registrant Contact:
登録者の連絡先：
The OPSAWG WG of the IETF.
IETFのopsawg wg。
XML:
XML：
N/A; the requested URI is an XML namespace.
n/a;要求されたURIはXMLネームスペースです。
URI:
URI：
urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
urn：ietf：params：xml：ns：yang：ietf-service-assurance-interface
Registrant Contact:
登録者の連絡先：
The OPSAWG WG of the IETF.
IETFのopsawg wg。
XML:
XML：
N/A; the requested URI is an XML namespace.
n/a;要求されたURIはXMLネームスペースです。
IANA has registered the following three YANG modules in the "YANG Module Names" registry [RFC7950]:
IANAは、「Yangモジュール名」レジストリ[RFC7950]に次の3つのYangモジュールを登録しました。
name:
名前：
ietf-service-assurance
ietf-service-Assurance
namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-service-assurance
urn：ietf：params：xml：ns：yang：ietf-service-assurance
prefix:
プレフィックス：
sain
セイン
reference:
参照：
RFC 9418
RFC 9418
name:
名前：
ietf-service-assurance-device
IETF-Service-Assurance-Device
namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
urn：ietf：params：xml：ns：yang：ietf-service-assurance-device
prefix:
プレフィックス：
sain-device
sain-device
reference:
参照：
RFC 9418
RFC 9418
name:
名前：
ietf-service-assurance-interface
ietf-service-assurance-interface
namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
urn：ietf：params：xml：ns：yang：ietf-service-assurance-interface
prefix:
プレフィックス：
sain-interface
sain-interface
reference:
参照：
RFC 9418
RFC 9418
These modules are not maintained by IANA.
これらのモジュールはIANAによって維持されていません。
[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>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[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>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
Arumugam, "Service Assurance for Intent-Based Networking
Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,
<https://www.rfc-editor.org/info/rfc9417>.
[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>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>.
The following tree diagram [RFC8340] provides an overview of the "example-service-assurance-device-acme" module.
次のツリー図[RFC8340]は、「サンプルサービスアシュアランスデバイスACME」モジュールの概要を示しています。
module: example-service-assurance-device-acme
augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters
+--rw device string
+--rw acme-specific-parameter string
A complete tree view of the base module with all augmenting modules presented in this document is available in Appendix B.3.
このドキュメントに示されているすべての拡張モジュールを備えたベースモジュールの完全なツリービューは、付録B.3に入手できます。
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 custom support for the device subservice specific to the Acme Corporation. The specific version adds a new parameter named "acme-specific-parameter". It's an implementation choice to either derive a new specific identity from the "subservice-base" identity defined in the "ietf-service-assurance" module or to augment the parameters from the "ietf-service-assurance-device" module; here, we choose to create a new identity.
状況によっては、ベンダー固有のサブサービスタイプが必要になる場合があります。このベンダー固有の実装の例として、このセクションでは、ACME Corporationに固有のデバイスサブサービスのカスタムサポートを追加する「IETF-Service-Assurance-Device」モジュールを強化する方法を示します。特定のバージョンは、「ACME固有のパラメーター」という名前の新しいパラメーターを追加します。「IETF-Service-Assursurance」モジュールで定義された「サブサービスベース」IDから新しい特定のIDを導き出すか、「IETF-Service-Assurance-Device」モジュールからパラメーターを拡張するかのいずれかが実装の選択です。ここでは、新しいアイデンティティを作成することを選択します。
module example-service-assurance-device-acme {
yang-version 1.1;
namespace "urn:example:example-service-assurance-device-acme";
prefix example-device-acme;
import ietf-service-assurance {
prefix sain;
reference
"RFC 9418: YANG Modules for Service Assurance";
}
import ietf-service-assurance-device {
prefix sain-device;
reference
"RFC 9418: YANG Modules for Service Assurance";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This example module extends the ietf-service-assurance-device
module to add specific support for devices of the Acme
Corporation. ";
revision 2023-07-11 {
description
"Initial revision.";
reference
"RFC 9418: YANG Modules for Service Assurance";
}
identity device-acme-type {
base sain-device:device-type;
description
"Network device is healthy.";
}
augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'device-acme-type')";
description
"Augments the parameter choice from the ietf-service-assurance
module with a case specific to the device-acme subservice.";
container parameters {
description
"Parameters for the device-acme subservice type.";
leaf device {
type string;
mandatory true;
description
"The device to monitor.";
}
leaf acme-specific-parameter {
type string;
mandatory true;
description
"The Acme-Corporation-specific parameter.";
}
}
}
}
In this section, we provide two additional YANG modules to completely cover the example in Figure 2 from Section 3.1 of [RFC9417]. The two missing subservice types are IP connectivity and the Intermediate System to Intermediate System (IS-IS) routing protocol. These modules are presented as examples; some future work is needed to propose a more complete version.
このセクションでは、[RFC9417]のセクション3.1の図2の例を完全にカバーするために、2つの追加のYangモジュールを提供します。2つの不足しているサブサービスタイプは、IP接続と中間システムから中間システム（IS-IS）ルーティングプロトコルです。これらのモジュールは例として提示されます。より完全なバージョンを提案するには、いくつかの将来の作業が必要です。
That subservice represents the unicast connectivity between two IP addresses located on two different devices. Such a subservice could report symptoms such as "No route found". The following tree diagram [RFC8340] provides an overview of the "example-service-assurance-ip-connectivity" module.
このサブサービスは、2つの異なるデバイスにある2つのIPアドレス間のユニキャスト接続を表します。このようなサブサービスは、「ルートが見つかりません」などの症状を報告する可能性があります。次のツリー図[RFC8340]は、「サンプルサービスアシュアランス-IP接続性」モジュールの概要を示しています。
module: example-service-assurance-ip-connectivity
augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters
+--rw device1 string
+--rw address1 inet:ip-address
+--rw device2 string
+--rw address2 inet:ip-address
To specify the connectivity that we are interested in, we specify two IP addresses and two devices. The subservice assures that the connectivity between IP address 1 on device 1 and IP address 2 on device 2 is healthy.
関心のある接続性を指定するには、2つのIPアドレスと2つのデバイスを指定します。このサブサービスは、デバイス1のIPアドレス1とデバイス2のIPアドレス2間の接続性が健全であることを保証します。
The following tree diagram [RFC8340] provides an overview of the "example-service-assurance-is-is" module.
次のツリー図[RFC8340]は、「Example-Service-Assurance-IS-IS」モジュールの概要を示しています。
module: example-service-assurance-is-is
augment /sain:subservices/sain:subservice/sain:parameter:
+--rw parameters
+--rw instance-name string
The parameter of this subservice is the name of the IS-IS instance to assure.
このサブサービスのパラメーターは、保証するIS-ISインスタンスの名前です。
The following tree diagram [RFC8340] provides an overview of the "ietf-service-assurance", "ietf-service-assurance-device", "example-service-assurance-device-acme", "example-service-assurance-ip-connectivity", and "example-service-assurance-is-is" modules.
次のツリー図[RFC8340]は、「IETF-Service Assursurance」、「IETF-Service-Assurence-Device」、「Example-Service-Assurance-Device-Acme」、「Example-Service-Assurance-IPの概要」を示しています。-connectivity "、および「semple-service-assurance-is」モジュール。
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
| | +--:(example-ip-connectivity:parameters)
| | | +--rw example-ip-connectivity:parameters
| | | +--rw example-ip-connectivity:device1 string
| | | +--rw example-ip-connectivity:address1
| | | | inet:ip-address
| | | +--rw example-ip-connectivity:device2 string
| | | +--rw example-ip-connectivity:address2
| | | inet:ip-address
| | +--:(example-is-is:parameters)
| | | +--rw example-is-is:parameters
| | | +--rw example-is-is:instance-name string
| | +--:(sain-device:parameters)
| | | +--rw sain-device:parameters
| | | +--rw sain-device:device string
| | +--:(example-device-acme:parameters)
| | | +--rw example-device-acme:parameters
| | | +--rw example-device-acme:device
| | | | string
| | | +--rw example-device-acme:acme-specific-parameter
| | | string
| | +--:(sain-interface:parameters)
| | +--rw sain-interface:parameters
| | +--rw sain-interface:device string
| | +--rw sain-interface:interface 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
module example-service-assurance-ip-connectivity {
yang-version 1.1;
namespace "urn:example:example-service-assurance-ip-connectivity";
prefix example-ip-connectivity;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-service-assurance {
prefix sain;
reference
"RFC 9418: YANG Modules for Service Assurance";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This example module augments the ietf-service-assurance module
to add support for the subservice ip-connectivity.
It checks whether the IP connectivity between two IP addresses
belonging to two network devices is healthy.";
revision 2023-07-11 {
description
"Initial version.";
reference
"RFC 9418: YANG Modules for Service Assurance";
}
identity ip-connectivity-type {
base sain:subservice-base;
description
"Checks connectivity between two IP addresses.";
}
augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'ip-connectivity-type')";
description
"Augments the parameter choice from the ietf-service-assurance
module with a case specific to the ip-connectivity
subservice.";
container parameters {
description
"Parameters for the ip-connectivity subservice type.";
leaf device1 {
type string;
mandatory true;
description
"Device at the first end of the connection.";
}
leaf address1 {
type inet:ip-address;
mandatory true;
description
"Address at the first end of the connection.";
}
leaf device2 {
type string;
mandatory true;
description
"Device at the second end of the connection.";
}
leaf address2 {
type inet:ip-address;
mandatory true;
description
"Address at the second end of the connection.";
}
}
}
}
module example-service-assurance-is-is {
yang-version 1.1;
namespace "urn:example:example-service-assurance-is-is";
prefix example-is-is;
import ietf-service-assurance {
prefix sain;
reference
"RFC 9418: YANG Modules for Service Assurance";
}
organization
"IETF OPSAWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Author: Benoit Claise <mailto:benoit.claise@huawei.com>
Author: Jean Quilbeuf <mailto:jean.quilbeuf@huawei.com>";
description
"This example module augments the ietf-service-assurance module
to add support for the subservice is-is.
It checks whether an IS-IS instance is healthy.";
revision 2023-07-11 {
description
"Initial version.";
reference
"RFC 9418: YANG Modules for Service Assurance";
}
identity is-is-type {
base sain:subservice-base;
description
"Health of IS-IS routing protocol.";
}
augment "/sain:subservices/sain:subservice/sain:parameter" {
when "derived-from-or-self(sain:type, 'is-is-type')";
description
"Augments the parameter choice from the ietf-service-assurance
module with a case specific to the is-is subservice.";
container parameters {
description
"Parameters for the is-is subservice type.";
leaf instance-name {
type string;
mandatory true;
description
"The instance to monitor.";
}
}
}
}
This section contains an example of a YANG instance that conforms to the YANG modules. The validity of this data instance has been checked using yangson <https://yangson.labs.nic.cz/>. Yangson requires a YANG library [RFC8525] to define the complete model against which the data instance must be validated. In Appendix D, we provide the JSON library file named "ietf-service-assurance-library.json", which we used for validation.
このセクションには、ヤンモジュールに準拠するヤンインスタンスの例が含まれています。このデータインスタンスの有効性は、Yangson <https://yangson.labs.nic.cz/>を使用してチェックされています。Yangsonは、データインスタンスを検証する必要がある完全なモデルを定義するために、Yang Library [RFC8525]を要求しています。付録Dでは、検証に使用した「IETF-Service-Assurance-Library.json」という名前のJSONライブラリファイルを提供します。
Below, we provide the contents of the file "example_configuration_instance.json", which contains the configuration data that models Figure 2 from Section 3.1 of [RFC9417]. The instance can be validated with yangson by using the invocation "yangson -v example_configuration_instance.json ietf-service-assurance-library.json", assuming all the files (YANG and JSON) defined in this document reside in the current folder.
以下に、[RFC9417]のセクション3.1の図2をモデル化する構成データを含むファイル「example_configuration_instance.json」の内容を示します。インスタンスは、このドキュメントで定義されているすべてのファイル（YangおよびJSON）が現在のフォルダーに存在すると仮定して、「Yangson -v emple_configuration_instance.json ietf-service-assurance-library.json」を呼び出してYangsonで検証できます。
{
"ietf-service-assurance:subservices": {
"subservice": [
{
"type": "service-instance-type",
"id": "simple-tunnel/example",
"service-instance-parameter": {
"service": "simple-tunnel",
"instance-name": "example"
},
"dependencies": {
"dependency": [
{
"type":
"ietf-service-assurance-interface:interface-type",
"id": "interface/peer1/tunnel0",
"dependency-type": "impacting"
},
{
"type":
"ietf-service-assurance-interface:interface-type",
"id": "interface/peer2/tunnel9",
"dependency-type": "impacting"
},
{
"type":
"example-service-assurance-ip-connectivity:ip-connectivity-type",
"id":
"connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
"dependency-type": "impacting"
}
]
}
},
{
"type":
"example-service-assurance-ip-connectivity:ip-connectivity-type",
"id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
"example-service-assurance-ip-connectivity:parameters": {
"device1": "Peer1",
"address1": "2001:db8::1",
"device2": "Peer2",
"address2": "2001:db8::2"
},
"dependencies": {
"dependency": [
{
"type":
"ietf-service-assurance-interface:interface-type",
"id": "interface/peer1/physical0",
"dependency-type": "impacting"
},
{
"type":
"ietf-service-assurance-interface:interface-type",
"id": "interface/peer2/physical5",
"dependency-type": "impacting"
},
{
"type": "example-service-assurance-is-is:is-is-type",
"id": "is-is/instance1",
"dependency-type": "impacting"
}
]
}
},
{
"type": "example-service-assurance-is-is:is-is-type",
"id": "is-is/instance1",
"example-service-assurance-is-is:parameters": {
"instance-name": "instance1"
}
},
{
"type": "ietf-service-assurance-interface:interface-type",
"id": "interface/peer1/tunnel0",
"ietf-service-assurance-interface:parameters": {
"device": "Peer1",
"interface": "tunnel0"
},
"dependencies": {
"dependency": [
{
"type":
"ietf-service-assurance-interface:interface-type",
"id": "interface/peer1/physical0",
"dependency-type": "impacting"
}
]
}
},
{
"type": "ietf-service-assurance-interface:interface-type",
"id": "interface/peer1/physical0",
"ietf-service-assurance-interface:parameters": {
"device": "Peer1",
"interface": "physical0"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-device:device-type",
"id": "interface/peer1",
"dependency-type": "impacting"
}
]
}
},
{
"type": "ietf-service-assurance-device:device-type",
"id": "interface/peer1",
"ietf-service-assurance-device:parameters": {
"device": "Peer1"
}
},
{
"type": "ietf-service-assurance-interface:interface-type",
"id": "interface/peer2/tunnel9",
"ietf-service-assurance-interface:parameters": {
"device": "Peer2",
"interface": "tunnel9"
},
"dependencies": {
"dependency": [
{
"type":
"ietf-service-assurance-interface:interface-type",
"id": "interface/peer2/physical5",
"dependency-type": "impacting"
}
]
}
},
{
"type": "ietf-service-assurance-interface:interface-type",
"id": "interface/peer2/physical5",
"ietf-service-assurance-interface:parameters": {
"device": "Peer2",
"interface": "physical5"
},
"dependencies": {
"dependency": [
{
"type": "ietf-service-assurance-device:device-type",
"id": "interface/peer2",
"dependency-type": "impacting"
}
]
}
},
{
"type": "ietf-service-assurance-device:device-type",
"id": "interface/peer2",
"ietf-service-assurance-device:parameters": {
"device": "Peer2"
}
}
]
}
}
This section provides the JSON encoding of the YANG library [RFC8525] that lists all modules defined in this document and their dependencies. This library can be used to validate data instances using yangson, as explained in the previous section.
このセクションでは、このドキュメントで定義されているすべてのモジュールとその依存関係をリストするYang Library [RFC8525]のJSONエンコードを提供します。このライブラリは、前のセクションで説明したように、Yangsonを使用してデータインスタンスを検証するために使用できます。
{
"ietf-yang-library:modules-state": {
"module-set-id": "ietf-service-assurance@2023-07-11",
"module": [
{
"name": "ietf-service-assurance",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-service-assurance",
"revision": "2023-07-11",
"conformance-type": "implement"
},
{
"name": "ietf-service-assurance-device",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-device",
"revision": "2023-07-11",
"conformance-type": "implement"
},
{
"name": "ietf-service-assurance-interface",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface",
"revision": "2023-07-11",
"conformance-type": "implement"
},
{
"name": "example-service-assurance-device-acme",
"namespace":
"urn:example:example-service-assurance-device-acme",
"revision": "2023-07-11",
"conformance-type": "implement"
},
{
"name": "example-service-assurance-is-is",
"namespace": "urn:example:example-service-assurance-is-is",
"revision": "2023-07-11",
"conformance-type": "implement"
},
{
"name": "example-service-assurance-ip-connectivity",
"namespace":
"urn:example:example-service-assurance-ip-connectivity",
"revision": "2023-07-11",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"revision": "2013-07-05",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"revision": "2013-07-05",
"conformance-type": "import"
}
]
}
}
The authors would like to thank Jan Lindblad for his help during the design of these YANG modules. The authors would like to thank Stephane Litkowski, Charles Eckel, Mohamed Boucadair, Tom Petch, Dhruv Dhody, and Rob Wilton for their reviews.
著者は、これらのYangモジュールの設計中にJan Lindbladの助けに感謝したいと思います。著者は、ステファン・リトコフスキー、チャールズ・エッケル、モハメド・ブーカデア、トム・ペッチ、ドルフ・ドディ、ロブ・ウィルトンのレビューに感謝したいと思います。
Benoit Claise
Huawei
Email: benoit.claise@huawei.com
Jean Quilbeuf
Huawei
Email: jean.quilbeuf@huawei.com
Paolo Lucente
NTT
Siriusdreef 70-72
2132 Hoofddorp
Netherlands
Email: paolo@ntt.net
Paolo Fasano
TIM S.p.A
via G. Reiss Romoli, 274
10148 Torino
Italy
Email: paolo2.fasano@telecomitalia.it
Thangavelu Arumugam
Consultant
Milpitas, California
United States of America
Email: thangavelu@yahoo.com