[要約] RFC 8969は、YANGを使用してサービスとネットワーク管理を自動化するためのフレームワークを提供します。この文書の目的は、効率的な運用と迅速なサービス展開を支援するための標準化された方法を確立することです。主に、ネットワークの設定、監視、および管理を自動化する際に利用されます。
Internet Engineering Task Force (IETF) Q. Wu, Ed.
Request for Comments: 8969 Huawei
Category: Informational M. Boucadair, Ed.
ISSN: 2070-1721 Orange
D. Lopez
Telefonica I+D
C. Xie
China Telecom
L. Geng
China Mobile
January 2021
A Framework for Automating Service and Network Management with YANG
ヤンとサービスとネットワーク管理を自動化するためのフレームワーク
Abstract
概要
Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.
データモデルは、サービスとネットワークを表すためのプログラム的なアプローチを提供します。具体的には、ネットワークおよびサービスコンポーネントの構成情報、および監視および追跡される状態情報を導き出すために使用することができます。データモデルは、サービスとネットワーク管理ライフサイクル（例えば、サービスインスタンス化、サービスプロビジョニング、サービス最適化、サービス監視、サービス診断、およびサービス保証）の間に使用できます。データモデルはネットワーク管理の自動化においても機器であり、それらは適応的および決定論的サービスの作成、配信、および保守のための閉ループ制御を提供することができる。
This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.
この文書では、Yangモデリング技術を利用するサービスとネットワーク管理の自動化のためのフレームワークについて説明します。このフレームワークは、データモデルの原点に関係なく、ネットワークオペレータの観点から描画されます。したがって、IETFの外側に発生するヤンモジュールを収容することができます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc8969.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8969で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology and Abbreviations
2.1. Terminology
2.2. Abbreviations
3. Architectural Concepts and Goals
3.1. Data Models: Layering and Representation
3.2. Automation of Service Delivery Procedures
3.3. Service Fulfillment Automation
3.4. YANG Module Integration
4. Functional Blocks and Interactions
4.1. Service Life-Cycle Management Procedure
4.1.1. Service Exposure
4.1.2. Service Creation/Modification
4.1.3. Service Assurance
4.1.4. Service Optimization
4.1.5. Service Diagnosis
4.1.6. Service Decommission
4.2. Service Fulfillment Management Procedure
4.2.1. Intended Configuration Provision
4.2.2. Configuration Validation
4.2.3. Performance Monitoring
4.2.4. Fault Diagnostic
4.3. Multi-layer/Multi-domain Service Mapping
4.4. Service Decomposition
5. YANG Data Model Integration Examples
5.1. L2VPN/L3VPN Service Delivery
5.2. VN Life-Cycle Management
5.3. Event-Based Telemetry in the Device Self Management
6. Security Considerations
6.1. Service Level
6.2. Network Level
6.3. Device Level
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Layered YANG Module Examples Overview
A.1. Service Models: Definition and Samples
A.2. Schema Mount
A.3. Network Models: Samples
A.4. Device Models: Samples
A.4.1. Model Composition
A.4.2. Device Management
A.4.3. Interface Management
A.4.4. Some Device Model Examples
Acknowledgements
Contributors
Authors' Addresses
Service management systems usually comprise service activation/ provision and service operation. Current service delivery procedures, from the processing of customer requirements and orders to service delivery and operation, typically assume the manipulation of data sequentially into multiple Operations Support System (OSS) or Business Support System (BSS) applications that may be managed by different departments within the service provider's organization (e.g., billing factory, design factory, network operation center). Many of these applications have been developed in house over the years and operate in a silo mode. As a result:
サービス管理システムは通常、サービス起動/提供およびサービス操作を含む。顧客の要求の処理とサービス配信と運用への注文からの現在のサービス提供手順は、通常、さまざまな部門によって管理される可能性がある複数の運用サポートシステム（OSS）またはビジネスサポートシステム（BSS）アプリケーションに順次データの操作を想定しています。サービスプロバイダの組織（Billing Factory、Design Factory、Network Operation Center）。これらのアプリケーションの多くは、長年にわたり社内で開発され、サイロモードで動作しています。結果として：
* The lack of standard data input/output (i.e., data model) raises many challenges in system integration and often results in manual configuration tasks.
* 標準データ入出力（すなわち、データモデル）の欠如は、システム統合において多くの課題を提起し、マニュアル構成タスクをもたらすことが多い。
* Service fulfillment systems might have a limited visibility on the network state and may therefore have a slow response to network changes.
* サービスフルフィルメントシステムは、ネットワーク状態に対する可視性が限られており、したがってネットワークの変更に対する応答が遅くなる可能性があります。
Software-Defined Networking (SDN) becomes crucial to address these challenges. SDN techniques are meant to automate the overall service delivery procedures and typically rely upon standard data models. These models are used not only to reflect service providers' savoir faire, but also to dynamically instantiate and enforce a set of service-inferred policies that best accommodate what has been defined and possibly negotiated with the customer. [RFC7149] provides a first tentative attempt to rationalize that service provider's view on the SDN space by identifying concrete technical domains that need to be considered and for which solutions can be provided. These include:
ソフトウェア定義ネットワーク（SDN）はこれらの課題に対処するために重要になります。SDN技術は、全体的なサービス配信手順を自動化し、通常は標準データモデルに依存することを意味します。これらのモデルは、サービスプロバイダのSavoir Faireを反映するだけでなく、定義されているものとおそらく顧客と交渉していることに最もよく対応する一連のサービス推定ポリシーを動的にインスタンス化して強制することも使用されています。[RFC7149]検討する必要がある具体的な技術的なドメインを特定することによって、SDN空間でサービスプロバイダーのビューを識別し、その解決策を提供することができる具体的な技術ドメインを識別することによって、SDN空間のビューを合理化する最初の暫定的な試みを提供します。これらは以下のとおりです。
* Techniques for the dynamic discovery of topology, devices, and capabilities, along with relevant information and data models that are meant to precisely document such topology, devices, and their capabilities.
* トポロジ、デバイス、および機能の動的発見のためのテクニック、そのようなトポロジ、デバイス、およびそれらの機能を正確に文書化することを意図している関連情報およびデータモデル。
* Techniques for exposing network services [RFC8309] and their characteristics.
* ネットワークサービス[RFC8309]を公開するためのテクニックとその特性
* Techniques used by service-derived dynamic resource allocation and policy enforcement schemes, so that networks can be programmed accordingly.
* サービス由来の動的リソース割り当ておよびポリシー執行方式によって使用されるテクニックは、ネットワークをそれに応じてプログラムすることができる。
* Dynamic feedback mechanisms that are meant to assess how efficiently a given policy (or a set thereof) is enforced from a service fulfillment and assurance perspective.
* 動的フィードバックメカニズムは、与えられたポリシー（またはそのセット）がサービスの履行および保証の観点からどの程度効率的にどの程度効率的かを評価することを意味しています。
Models are key for each of the four technical items above. Service and network management automation is an important step to improve the agility of network operations. Models are also important to ease integrating multi-vendor solutions.
モデルは上記の4つの技術項目のそれぞれの鍵です。サービスとネットワーク管理の自動化は、ネットワーク操作の敏捷性を向上させるための重要なステップです。モデルはマルチベンダーソリューションの統合を和らげることも重要です。
YANG module [RFC7950] developers have taken both top-down and bottom-up approaches to develop modules [RFC8199] and to establish a mapping between a network technology and customer requirements at the top or abstracting common constructs from various network technologies at the bottom. At the time of writing this document (2020), there are many YANG data models, including configuration and service models, that have been specified or are being specified by the IETF. They cover many of the networking protocols and techniques. However, how these models work together to configure a function, manage a set of devices involved in a service, or provide a service is something that is not currently documented either within the IETF or other Standards Development Organizations (SDOs).
Yang Module [RFC7950]開発者は、モジュール[RFC8199]を開発するためのトップダウンとボトムアップアプローチの両方を取り、上位のネットワーク技術と顧客の要件との間のマッピングを確立したり、下部のさまざまなネットワーク技術からの共通の構成要素との間のマッピングを確立しました。この文書を書くとき（2020）は、指定されているか、またはIETFによって指定されている、構成およびサービスモデルを含む多くのYANDデータモデルがある。彼らはネットワーキングプロトコルと技術の多くをカバーしています。ただし、これらのモデルはどのように機能して機能を構成するか、サービスに含まれるデバイスのセットを管理するか、またはサービスを提供することです。
Many of the YANG modules listed in this document are used to exchange data between NETCONF/RESTCONF clients and servers [RFC6241][RFC8040]. Nevertheless, YANG is a transport-independent data modeling language. It can thus be used independently of NETCONF/RESTCONF. For example, YANG can be used to define abstract data structures [RFC8791] that can be manipulated by other protocols (e.g., [DOTS-DDOS]).
この文書に記載されているYangモジュールの多くは、NetConf / Restconfクライアントとサーバー[RFC6241] [RFC8040]の間でデータを交換するために使用されます。それにもかかわらず、ヤンは輸送に依存しないデータモデリング言語です。したがって、NetConf / RESTCONFとは無関係に使用できます。たとえば、Yangを使用して、他のプロトコル（例えば、[DOTS-DDOS]）によって操作できる抽象データ構造[RFC8791]を定義できます。
This document describes an architectural framework for service and network management automation (Section 3) that takes advantage of YANG modeling technologies and investigates how YANG data models at different layers interact with each other (e.g., Service Mapping, model composition) in the context of service delivery and fulfillment (Section 4). Concretely, the following benefits can be provided:
この文書では、Yangモデリング技術を利用するサービスとネットワーク管理の自動化のためのアーキテクチャフレームワーク（セクション3）について説明し、サービスのコンテキストで異なる層でのYANDデータモデル（サービスマッピング、モデル構成）を調べます。配達と充実（セクション4）。具体的には、以下の利点を提供することができます。
* Vendor-agnostic interfaces managing a service and the underlying network are allowed.
* サービスの管理と基盤となるネットワークを管理するベンダのアジナルのインターフェイスは許可されています。
* Movement from deployment schemes where vendor-specific network managers are required to a scheme where the entities that are responsible for orchestrating and controlling services and network resources provided by multi-vendor devices are unified is allowed.
* ベンダー固有のネットワークマネージャが、マルチベンダーデバイスによって提供されたサービスおよび制御サービスおよびネットワークリソースが統一されている担当者が許可されている展開スキームからの移動は許可されています。
* Data inheritance and reusability among the various architecture layers thus promoting a network-wise provisioning instead of device-specific configuration is eased.
* さまざまなアーキテクチャ層の間のデータ継承と再利用可能性により、デバイス固有の設定の代わりにネットワーク上のプロビジョニングを促進することが緩和されます。
* Dynamically feeding a decision-making process (e.g., Controllers, Orchestrators) with notifications that will trigger appropriate actions, allowing that decision-making process to continuously adjust a network (and thus the involved resources) to deliver the service that conforms to the intended parameters (service objectives) is allowed.
* 意図的な行動を引き起こすことで、意図的なパラメータに準拠したサービスを提供するために、意思決定プロセス（例えば、コントローラ、オーケストレータなど）を動的に供給し、意思決定プロセスを継続的に調整することを可能にします。（サービス目標）が許可されています。
This framework is drawn from a network operator perspective irrespective of the origin of a data model; it can also accommodate YANG modules that are developed outside the IETF. The document covers service models that are used by an operator to expose its services and capture service requirements from the customers (including other operators). Nevertheless, the document does not elaborate on the communication protocol(s) that makes use of these service models in order to request and deliver a service. Such considerations are out of scope.
このフレームワークは、データモデルの原点に関係なく、ネットワークオペレータの観点から描画されます。IETFの外側に発生したYangモジュールを収容することもできます。この文書では、顧客からのサービスとサービス要件を顧客（他の演算子を含む）からのサービス要件を露出させるためにオペレータが使用するサービスモデルをカバーしています。それにもかかわらず、この文書は、サービスを要求して配信するためにこれらのサービスモデルを利用する通信プロトコルについて詳しく述べていない。そのような考慮事項は範囲外です。
The document identifies a list of use cases to exemplify the proposed approach (Section 5), but it does not claim nor aim to be exhaustive. Appendix A lists some examples to illustrate the layered YANG modules view.
この文書は、提案されたアプローチを例示するためのユースケースのリストを識別する（第5節）が、それは網羅的であることを主張していないこともありません。付録A階層化されたYANGモジュールビューを説明するためのいくつかの例を示します。
The following terms are defined in [RFC8309] and [RFC8199] and are not redefined here:
以下の用語は[RFC8309]と[RFC8199]で定義されており、ここでは再定義されていません。
* Network Operator
* ネットワーク事業者
* Customer
* お客様
* Service
* サービス
* Data Model
* データ・モデル
* Service Model
* サービスモデル
* Network Element Model
* ネットワーク要素モデル
In addition, the document makes use of the following terms:
さらに、この文書は以下の用語を利用しています。
Network Model: Describes a network-level abstraction (or a subset of aspects of a network infrastructure), including devices and their subsystems, and relevant protocols operating at the link and network layers across multiple devices. This model corresponds to the network configuration model discussed in [RFC8309].
ネットワークモデル：デバイスとそのサブシステムを含むネットワークレベルの抽象化（またはネットワークインフラストラクチャの側面のサブセット）、および複数のデバイスにわたるリンク層とネットワーク層で動作する関連プロトコルについて説明します。このモデルは[RFC8309]で説明したネットワーク構成モデルに対応しています。
It can be used by a network operator to allocate resources (e.g., tunnel resource, topology resource) for the service or schedule resources to meet the service requirements defined in a service model.
サービスモデルで定義されているサービス要件を満たすために、サービスまたはスケジュールリソースのリソース（例えば、トンネルリソース、トポロジリソース）を割り当てるためにネットワークオペレータによって使用できます。
Network Domain: Refers to a network partitioning that is usually followed by network operators to delimit parts of their network. "access network" and "core network" are examples of network domains.
ネットワークドメイン：通常、ネットワークの一部を区切るためのネットワーク演算子が続くネットワークパーティション化を指します。「アクセスネットワーク」と「コアネットワーク」は、ネットワークドメインの例です。
Device Model: Refers to the Network Element YANG data model described in [RFC8199] or the device configuration model discussed in [RFC8309].
デバイスモデル：[RFC8199]で説明されているネットワーク要素YANGデータモデルまたは[RFC8309]で説明したデバイス構成モデルを指します。
Device models are also used to refer to model a function embedded in a device (e.g., Network Address Translation (NAT) [RFC8512], Access Control Lists (ACLs) [RFC8519]).
デバイスモデルは、デバイスに埋め込まれた機能A機能（例えば、ネットワークアドレス変換（NAT）[RFC8512]、アクセス制御リスト（ACL）[RFC8519]）を指すためにも使用されます。
Pipe: Refers to a communication scope where only one-to-one (1:1) communications are allowed. The scope can be identified between ingress and egress nodes, two service sites, etc.
PIPE：1対1の通信のみが許可されている通信スコープを指します。スコープは、入力と出力ノード、2つのサービスサイトなどの間で識別できます。
Hose: Refers to a communication scope where one-to-many (1:N) communications are allowed (e.g., one site to multiple sites).
ホース：1対多（1：N）通信が許可されている通信範囲を指す（例えば、1つのサイトから複数のサイトへのサイト）。
Funnel: Refers to a communication scope where many-to-one (N:1) communications are allowed.
漏斗：多対1（N：1）通信が許可されている通信範囲を指す。
The following abbreviations are used in the document:
以下の略語が文書で使用されています。
ACL Access Control List AS Autonomous System AP Access Point CE Customer Edge DBE Data Border Element E2E End-to-End ECA Event Condition Action L2VPN Layer 2 Virtual Private Network L3VPN Layer 3 Virtual Private Network L3SM L3VPN Service Model L3NM L3VPN Network Model NAT Network Address Translation OAM Operations, Administration, and Maintenance OWD One-Way Delay PE Provider Edge PM Performance Monitoring QoS Quality of Service RD Route Distinguisher RT Route Target SBE Session Border Element SDN Software-Defined Networking SP Service Provider TE Traffic Engineering VN Virtual Network VPN Virtual Private Network VRF Virtual Routing and Forwarding
ACL ACCES CONTROR LIST AS APアクセスポイントCEカスタマーエッジDBEデータ境界要素E2EエンドツーエンドECAイベント条件アクションL2VPNレイヤ2仮想プライベートネットワークL3VPNレイヤ3仮想プライベートネットワークL3SM L3VPNサービスモデルL3NM L3VPNネットワークモデルNATネットワークアドレス翻訳OAMの操作、管理、メンテナンスOWD一元遅延PEプロバイダーエッジPMのパフォーマンス監視QOSサービス品質RDルート識別器RTルートターゲットSBEセッションボーダーエレメントSDNソフトウェア定義ネットワークSPサービスプロバイダTEトラフィックエンジニアリングVN仮想ネットワークVPN仮想プライベートネットワークVRF仮想ルーティングと転送
As described in Section 2 of [RFC8199], layering of modules allows for better reusability of lower-layer modules by higher-level modules while limiting duplication of features across layers.
[RFC8199]のセクション2に記載されているように、モジュールの階層化により、層間の機能の重複を制限しながら、高レベルのモジュールによる下層モジュールのより良い再利用性を可能にします。
Data models in the context of network management can be classified into service, network, and device models. Different service models may rely on the same set of network and/or device models.
ネットワーク管理の文脈におけるデータモデルは、サービス、ネットワーク、およびデバイスモデルに分類できます。さまざまなサービスモデルは、同じネットワークモデルおよび/またはデバイスモデルに依存する可能性があります。
Service models traditionally follow a top-down approach and are mostly customer-facing YANG modules providing a common model construct for higher-level network services (e.g., Layer 3 Virtual Private Network (L3VPN)). Such modules can be mapped to network technology-specific modules at lower layers (e.g., tunnel, routing, Quality of Service (QoS), security). For example, service models can be used to characterize the network service(s) to be ensured between service nodes (ingress/egress) such as:
サービスモデルは伝統的にトップダウンアプローチに従っており、主に顧客向けのYANGモジュールであり、高レベルのネットワークサービス（例えば、レイヤ3仮想プライベートネットワーク（L3VPN））のための一般的なモデル構築物を提供します。そのようなモジュールは、下位層（例えば、トンネル、ルーティング、サービス品質（QoS）、セキュリティ）でネットワーク技術固有のモジュールにマッピングすることができる。例えば、サービスモデルを使用して、次のようなサービスノード（入力/出力）間で保証されるネットワークサービスを特徴付けることができます。
* the communication scope (pipe, hose, funnel, etc.), * the directionality (inbound/outbound), * the traffic performance guarantees expressed using metrics such as One-Way Delay (OWD) [RFC7679] or One-Way Loss [RFC7680]; a summary of performance metrics maintained by IANA can be found in [IPPM], * link capacity [RFC5136] [METRIC-METHOD], * etc.
* 通信範囲（パイプ、ホース、漏斗など）、*方向性（入荷/アウトバウンド）、*一方向遅延（OWD）[RFC7679]または一方向損失などのメトリックを使用して表現されたトラフィック性能保証[RFC7680]]IANAによって維持されるパフォーマンスメトリックの概要は、[IPPM]、* Link Capacity [RFC5136] [メトリック方法]、*などにあります。
Figure 1 depicts the example of a Voice over IP (VoIP) service that relies upon connectivity services offered by a network operator. In this example, the VoIP service is offered to the network operator's customers by Service Provider 1 (SP1). In order to provide global VoIP reachability, SP1 Service Site interconnects with other Service Providers service sites typically by interconnecting Session Border Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. For other VoIP destinations, sessions are forwarded over the Internet. These connectivity services can be captured in a YANG service model that reflects the service attributes that are shown in Figure 2. This example follows the IP Connectivity Provisioning Profile template defined in [RFC7297].
図1は、ネットワーク事業者によって提供される接続サービスに依存する音声over IP（VoIP）サービスの例を示す。この例では、VoIPサービスはサービスプロバイダ1（SP1）によってネットワークオペレータの顧客に提供されています。グローバルVoIP到達可能性を提供するために、SP1サービスサイトのSP1サービスサイトは、セッション枠要素（SBES）とデータ境界要素（DBES）[RFC5486] [RFC6406]を相互接続することによって、通常、他のサービスプロバイダのサービスサイトと相互接続されています。他のVoIP宛先の場合、セッションはインターネット上で転送されます。これらの接続サービスは、図2に示すサービス属性を反映したYANGサービスモデルでキャプチャできます。この例では、[RFC7297]で定義されているIP接続プロビジョニングプロファイルテンプレートに従います。
,--,--,--. ,--,--,--.
,-' SP1 `-. ,-' SP2 `-.
( Service Site ) ( Service Site )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
x | o * * |
(2)x | o * * |
,x-,--o-*-. (1) ,--,*-,--.
,-' x o * * * * * * * * * `-.
( x o +----( Internet )
User---(x x x o o o o o o o o o o o o o o o o o o
`-. ,-' `-. ,-' (3)
`--'--'--' `--'--'--'
Network Operator
**** (1) Inter-SP connectivity
xxxx (2) Customer-to-SP connectivity
oooo (3) SP to any destination connectivity
Figure 1: An Example of Service Connectivity Components
図1：サービス接続コンポーネントの例
In reference to Figure 2, "Full traffic performance guarantees class" refers to a service class where all traffic performance metrics included in the service model (OWD, loss, delay variation) are guaranteed, while "Delay traffic performance guarantees class" refers to a service class where only OWD is guaranteed.
図2を参照して、「フルトラフィックパフォーマンス保証クラス」とは、サービスモデル（OWD、損失、遅延変動）に含まれるすべてのトラフィックパフォーマンスメトリックが保証されているサービスクラスとは、「遅延トラフィックパフォーマンス保証」とは、OWDだけが保証されているサービスクラス。
Connectivity: Scope and Guarantees (1) Inter-SP connectivity - Pipe scope from the local to the remote SBE/DBE - Full traffic performance guarantees class (2) Customer-to-SP connectivity - Hose/Funnel scope connecting the local SBE/DBE to the customer access points - Full traffic performance guarantees class (3) SP to any destination connectivity - Hose/Funnel scope from the local SBE/DBE to the Internet gateway - Delay traffic performance guarantees class Flow Identification * Destination IP address (SBE, DBE) * DSCP marking Traffic Isolation * VPN Routing & Forwarding * Routing rule to exclude some ASes from the inter-domain paths Notifications (including feedback) * Statistics on aggregate traffic to adjust capacity * Failures * Planned maintenance operations * Triggered by thresholds
接続性：スコープと保証（1）SP間接続 - ローカルからリモートへのパイプスコープ/ DBE - フルトラフィック性能保証クラス（2）顧客からSP接続性 - ホース/ファンネルスコープローカルSBE / DBEの接続顧客アクセスポイント - フルトラフィックパフォーマンスを保証するクラス（3）SPへの宛先接続 - ローカルSBE / DBEからインターネットゲートウェイへのホース/ファンネルスコープ - 遅延トラフィック性能の保証クラスフロー識別*宛先IPアドレス（SBE、DBE* DSCPマーキングトラフィックアイソレーション* VPNルーティングと転送*ルーティングルールドメイン間パスからのASを除外する（フィードバックを含む）※アグリゲートトラフィックに関する統計*障害*計画メンテナンス操作*しきい値によってトリガーされました*
Figure 2: Sample Attributes Captured in a Service Model
図2：サービスモデルでキャプチャされたサンプル属性
Network models are mainly network-resource-facing modules; they describe various aspects of a network infrastructure, including devices and their subsystems, and relevant protocols operating at the link and network layers across multiple devices (e.g., network topology and traffic-engineering tunnel modules).
ネットワークモデルは主にネットワークリソース対向モジュールです。それらは、デバイスおよびそれらのサブシステムを含むネットワークインフラストラクチャの様々な態様、および複数の装置にわたるリンク層およびネットワーク層で動作する関連プロトコル（例えば、ネットワークトポロジおよびトラフィックエンジニアリングトンネルモジュール）を説明する。
Device (and function) models usually follow a bottom-up approach and are mostly technology-specific modules used to realize a service (e.g., BGP, ACL).
デバイス（および機能）モデルは通常ボトムアップアプローチに従い、サービスを実現するために使用される技術固有のモジュール（例えば、BGP、ACL）です。
Each level maintains a view of the supported YANG modules provided by lower levels (see for example, Appendix A). Mechanisms such as the YANG library [RFC8525] can be used to expose which YANG modules are supported by nodes in lower levels.
各レベルは、下位レベルによって提供されるサポートされているYangモジュールのビューを維持します（例えば、付録Aを参照）。Yang Library [RFC8525]などのメカニズムを使用して、どのYANDモジュールがノードで低レベルでサポートされているかを露出させることができます。
Figure 3 illustrates the overall layering model. The reader may refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and "Controller" elements. All these elements (i.e., Orchestrator(s), Controller(s), device(s)) are under the responsibility of the same operator.
図3は全体的な階層化モデルを示しています。リーダーは、「Orchestrator」と「コントローラ」要素の概要については、[RFC8309]のセクション4を参照することができます。これらすべての要素（すなわち、Orchestrator（S）、コントローラ）は、同じ演算子の責任を受けている。
+-----------------------------------------------------------------+
| Hierarchy Abstraction |
| |
| +-----------------------+ Service Model |
| | Orchestrator | (Customer Oriented) |
| |+---------------------+| Scope: "1:1" Pipe model |
| || Service Modeling || |
| |+---------------------+| |
| | | Bidirectional |
| |+---------------------+| +-+ Capacity, OWD +-+ |
| ||Service Orchestration|| | +----------------+ | |
| |+---------------------+| +-+ +-+ |
| +-----------------------+ Ingress Egress |
| |
| |
| +-----------------------+ Network Model |
| | Controller | (Operator Oriented) |
| |+---------------------+| +-+ +--+ +---+ +-+ |
| || Network Modeling || | | | | | | | | |
| |+---------------------+| | o----o--o----o---o---o | |
| | | +-+ +--+ +---+ +-+ |
| |+---------------------+| src dst |
| ||Network Orchestration|| L3VPN over TE |
| |+---------------------+| Instance Name/Access Interface |
| +-----------------------+ Protocol Type/Capacity/RD/RT/... |
| |
| |
| +-----------------------+ Device Model |
| | Device | |
| |+--------------------+ | |
| || Device Modeling | | Interface add, BGP Peer, |
| |+--------------------+ | Tunnel ID, QoS/TE, ... |
| +-----------------------+ |
+-----------------------------------------------------------------+
Figure 3: Layering and Representation within a Network Operator
図3：ネットワーク事業者内の階層化と表現
A composite service offered by a network operator may rely on services from other operators. In such a case, the network operator acts as a customer to request services from other networks. The operators providing these services will then follow the layering depicted in Figure 3. The mapping between a composite service and a third-party service is maintained at the orchestration level. From a data-plane perspective, appropriate traffic steering policies (e.g., Service Function Chaining [RFC7665]) are managed by the network controllers to guide how/when a third-party service is invoked for flows bound to a composite service.
ネットワーク事業者によって提供される複合サービスは、他のオペレータからのサービスに依存する可能性があります。そのような場合、ネットワーク事業者は他のネットワークからサービスを要求するための顧客として機能します。これらのサービスを提供するオペレータは、図3に示す階層化に従うことになります。コンポジットサービスとサードパーティのサービスとの間のマッピングはオーケストレーションレベルに維持されます。データプレーンの観点からは、適切なトラフィック操作ポリシー（例えば、サービス機能チェーン[RFC7665]）がネットワークコントローラによって管理されて、コンポジットサービスにバインドされたフローに対してサードパーティサービスが呼び出されるかをガイドします。
The layering model depicted in Figure 3 does not make any assumption about the location of the various entities (e.g., Controller, Orchestrator) within the network. As such, the architecture does not preclude deployments where, for example, the Controller is embedded on a device that hosts other functions that are controlled via YANG modules.
図3に示す階層モデルは、ネットワーク内の様々なエンティティ（例えば、コントローラ、オーケストレータ）の位置に関する任意の仮定を行わない。したがって、アーキテクチャは、例えば、コントローラがyangモジュールを介して制御される他の機能をホストするデバイスに埋め込まれている展開を排除しません。
In order to ease the mapping between layers and data reuse, this document focuses on service models that are modeled using YANG. Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 does not preclude service models to be modeled using data modeling languages other than YANG.
レイヤーとデータの再利用の間のマッピングを簡単にするために、このドキュメントはYangを使用してモデル化されているサービスモデルに焦点を当てています。それにもかかわらず、[RFC8309]のセクション3に完全に準拠している図3は、ヤン以外のデータモデリング言語を使用してモデル化されるサービスモデルを妨げるものではありません。
Service models can be used by a network operator to expose its services to its customers. Exposing such models allows automation of the activation of service orders and thus the service delivery. One or more monolithic service models can be used in the context of a composite service activation request (e.g., delivery of a caching infrastructure over a VPN). Such models are used to feed a decision-making intelligence to adequately accommodate customer needs.
サービスモデルは、ネットワーク事業者がそのサービスを顧客に公開するために使用することができます。そのようなモデルを公開することで、サービス指図の活性化、したがってサービス提供の自動化が可能です。1つまたは複数のモノリシックサービスモデルは、複合サービス活性化要求（例えば、VPN上のキャッシングインフラストラクチャの配信）の文脈で使用することができる。そのようなモデルは、顧客のニーズを適切に収容するための意思決定の知性を養うために使用されます。
Also, such models may be used jointly with services that require dynamic invocation. An example is provided by the service modules defined by the DOTS WG to dynamically trigger requests to handle Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service filtering request modeled using [RFC8783] will be translated into device-specific filtering (e.g., ACLs defined in [RFC8519]) that fulfills the service request.
また、動的呼び出しを必要とするサービスと共同で使用することもできます。例は、Dots WGによって定義されたサービスモジュールによって、分散サービス拒否（DDOS）攻撃[RFC8783]を処理するための要求を動的にトリガーします。[RFC8783]を使用してモデル化されたサービスフィルタリング要求は、サービス要求を満たすデバイス固有のフィルタリング（例えば、[RFC8519]で定義されているACL）に変換されます。
Network models can be derived from service models and used to provision, monitor, and instantiate the service. Also, they are used to provide life-cycle management of network resources. Doing so is meant to:
ネットワークモデルは、サービスモデルから派生し、サービスを提供、監視、およびインスタンス化するために使用できます。また、ネットワークリソースのライフサイクル管理を提供するために使用されます。そうすることは次のとおりです。
* expose network resources to customers (including other network operators) to provide service fulfillment and assurance.
* サービスの履行と保証を提供するために、ネットワークリソース（他のネットワーク事業者を含む）にネットワークリソースを公開します。
* allow customers (or network operators) to dynamically adjust the network resources based on service requirements as described in service models (e.g., Figure 2) and the current network performance information described in the telemetry modules.
* 顧客（またはネットワーク事業者）は、サービスモデル（例えば図2）および遠隔測定モジュールに記載されている現在のネットワーク性能情報をサービス要件に基づいて動的にネットワークリソースを動的に調整することを可能にする。
Note that it is out of the scope of this document to elaborate on the communication protocols that are used to implement the interface between the service ordering (customer) and service order handling (provider).
この文書の範囲外は、サービス順序付け（顧客）とサービス指図処理（プロバイダ）との間のインターフェースを実装するために使用される通信プロトコルを詳しく説明することに注意してください。
To operate a service, the settings of the parameters in the device models are derived from service models and/or network models and are used to:
サービスを操作するために、デバイスモデル内のパラメータの設定は、サービスモデルおよび/またはネットワークモデルから派生しており、以下のものに使用されます。
* Provision each involved network function/device with the proper configuration information.
* それぞれのネットワーク機能/デバイスを適切な構成情報で提供します。
* Operate the network based on service requirements as described in the service model(s) and local operational guidelines.
* サービスモデルと現地の運用ガイドラインに記載されているサービス要件に基づいてネットワークを操作します。
In addition, the operational state including configuration that is in effect together with statistics should be exposed to upper layers to provide better network visibility and assess to what extent the derived low-level modules are consistent with the upper-level inputs.
さらに、統計とともに有効な構成を含む操作状態は、ネットワークの可視性を向上させ、派生低レベルモジュールが上位レベルの入力と一致する範囲で評価するために上位層にさらされるべきです。
Filters are enforced on the notifications that are communicated to Service layers. The type and frequency of notifications may be agreed upon in the service model.
サービス層に通信される通知にフィルタが適用されます。通知の種類と頻度は、サービスモデルで合意されてもよい。
Note that it is important to correlate telemetry data with configuration data to be used for closed loops at the different stages of service delivery, from resource allocation to service operation, in particular.
さまざまなサービス配信段階で、リソース割り当てからサービス操作まで、テレメトリデータとコンフィギュレーションデータをコンフィギュレーションデータと相関させることが重要です。
To support top-down service delivery, YANG modules at different levels or at the same level need to be integrated for proper service delivery (including proper network setup). For example, the service parameters captured in service models need to be decomposed into a set of configuration/notification parameters that may be specific to one or more technologies; these technology-specific parameters are grouped together to define technology-specific device-level models or network-level models.
トップダウンサービス配信をサポートするためには、さまざまなレベルまたは同じレベルのYangモジュールを適切なサービス提供（適切なネットワーク設定を含む）のために統合する必要があります。たとえば、サービスモデルでキャプチャされたサービスパラメータは、1つ以上のテクノロジに固有の可能性がある一連の構成/通知パラメータに分解する必要があります。これらのテクノロジ固有のパラメータは、テクノロジ固有のデバイスレベルのモデルまたはネットワークレベルのモデルを定義するためにグループ化されています。
In addition, these technology-specific device or network models can be further integrated with each other using the schema mount mechanism [RFC8528] to provision each involved network function/ device or each involved network domain to support newly added modules or features. A collection of integrated device models can be loaded and validated during implementation.
さらに、これらの技術固有のデバイスまたはネットワークモデルは、スキーママウントメカニズム[RFC8528]を使用して互いにさらに統合することができ、それぞれのネットワーク機能/デバイス、またはそれぞれの関係するネットワークドメインまたはそれぞれのInells Interned Networkドメインを提供して、新しく追加されたモジュールまたは機能をサポートします。統合デバイスモデルのコレクションは、実装中にロードおよび検証できます。
High-level policies can be defined at service or network models (e.g., "Autonomous System Number (ASN) Exclude" in the example depicted in Figure 2). Device models will be tweaked accordingly to provide policy-based management. Policies can also be used for telemetry automation, e.g., policies that contain conditions to trigger the generation and pushing of new telemetry data.
高レベルのポリシーは、図2に示す例では、サービスまたはネットワークモデル（例えば、「自律システム番号（ASN）除外」で定義することができる。デバイスモデルは、ポリシーベースの管理を提供するためにそれに応じて調整されます。ポリシーは、テレメトリ自動化、例えば、新しいテレメトリデータの生成とプッシュを引き起こす条件を含むポリシーにも使用できます。
The architectural considerations described in Section 3 lead to the life-cycle management architecture illustrated in Figure 4 and described in the following subsections.
セクション3に記載されているアーキテクチャ上の考慮事項は、図4に示すライフサイクル管理アーキテクチャにつながり、以下のサブセクションで説明しています。
+------------------+
............... | |
Service level | |
V |
E2E E2E E2E E2E
Service --> Service ---------> Service ------------> Service
Exposure Creation ^ Optimization ^ Diagnosis
/Modification | | |
^ | |Diff | |
E2E | | | E2E | |
Service ----+ | | Service | |
Decommission | +------ Assurance --+ |
| ^ |
Multi-layer | | |
Multi-domain | | |
Service Mapping| | |
............... |<-----------------+ | |
Network level | | +-------+ v
V | | Specific
Specific Specific | Service
Service --------> Service <--+ | Diagnosis
Creation ^ Optimization | | |
/Modification | | | |
| |Diff | | |
| | Specific --+ | |
Service | | Service | |
Decomposition | +----- Assurance ----+ |
| ^ |
............... | | Aggregation |
Device level | +------------+ |
V | |
Service Intent | v
Fulfillment Config ----> Config ----> Performance ----> Fault
Provision Validation Monitoring Diagnostic
Figure 4: Service and Network Life-Cycle Management
図4：サービスとネットワークライフサイクル管理
Service life-cycle management includes end-to-end service life-cycle management at the service level and technology-specific network life-cycle management at the network level.
サービスライフサイクル管理には、ネットワークレベルでのサービスレベルおよび技術固有のネットワークライフサイクル管理におけるエンドツーエンドのサービスライフサイクル管理が含まれています。
The end-to-end service life-cycle management is technology-independent service management and spans across multiple network domains and/or multiple layers while technology-specific service life-cycle management is technology domain-specific or layer-specific service life-cycle management.
エンドツーエンドのサービスライフサイクル管理は、テクノロジ固有のサービスライフサイクル管理がテクノロジ固有のサービスまたはレイヤ固有のサービスライフサイクルである間、複数のネットワークドメインおよび/または複数のレイヤーにわたるテクノロジ独立サービス管理とスパンです。管理。
A service in the context of this document (sometimes called "Network Service") is some form of connectivity between customer sites and the Internet or between customer sites across the operator's network and across the Internet.
この文書のコンテキストでのサービス（「ネットワークサービス」とも呼ばれる）は、顧客サイトとインターネット間、またはオペレータのネットワーク全体の顧客サイトとインターネット間の顧客サイト間の一種の接続性です。
Service exposure is used to capture services offered to customers (ordering and order handling). One example is that a customer can use an L3VPN Service Model (L3SM) to request L3VPN service by providing the abstract technical characterization of the intended service between customer sites.
サービス露出は、顧客に提供されるサービスをキャプチャするために使用されます（順序付けと注文処理）。一例は、顧客が顧客サイト間で意図されたサービスの抽象的な技術的特徴を提供することによってL3VPNサービスモデル（L3SM）を使用することができることである。
Service model catalogs can be created to expose the various services and the information needed to invoke/order a given service.
サービスモデルカタログは、さまざまなサービスと特定のサービスを呼び出すのに必要な情報を公開するために作成できます。
A customer is usually unaware of the technology that the network operator has available to deliver the service, so the customer does not make requests specific to the underlying technology but is limited to making requests specific to the service that is to be delivered. This service request can be filled using a service model.
顧客は通常、ネットワーク事業者がサービスを提供することができる技術を認識しているため、顧客は基礎となる技術に固有の要求を行わないが、配信されるサービスに固有の要求をすることに限定されています。このサービス要求はサービスモデルを使用して埋めることができます。
Upon receiving a service request, and assuming that appropriate authentication and authorization checks have been made with success, the service Orchestrator/management system should verify whether the service requirements in the service request can be met (i.e., whether there are sufficient resources that can be allocated with the requested guarantees).
サービス要求を受信すると、適切な認証および許可検査が成功を収めて行われたと仮定して、サービス要求/管理システムは、サービス要求内のサービス要件を満たすことができるかどうかを検証するべきである（すなわち、得ることができる十分なリソースがあるかどうか）。要求された保証で割り当てられています。
If the request is accepted, the service Orchestrator/management system maps such a service request to its view. This view can be described as a technology-specific network model or a set of technology-specific device models, and this mapping may include a choice of which networks and technologies to use depending on which service features have been requested.
要求が受け入れられると、サービスオーケストレータ/管理システムはそのようなサービス要求をそのビューにマッピングする。このビューは、テクノロジ固有のネットワークモデルまたは一連のテクノロジ固有のデバイスモデルとして説明することができ、このマッピングはどのサービス機能が要求されているかに応じて使用するネットワークおよびテクノロジの選択を含み得る。
In addition, a customer may require a change in the underlying network infrastructure to adapt to new customers' needs and service requirements (e.g., service a new customer site, add a new access link, or provide disjoint paths). This service modification can be issued following the same service model used by the service request.
さらに、顧客は、基礎となるネットワークインフラストラクチャの変更を必要とし、新しい顧客のニーズとサービス要件に適応するために（例えば、新しい顧客サイトにサービスを提供し、新しいアクセスリンクを追加する、または廃棄されたパスを提供する）。このサービスの変更は、サービス要求によって使用されるのと同じサービスモデルに従って発行されます。
Withdrawing a service is discussed in Section 4.1.6.
サービスを撤回することについては、4.1.6項で説明します。
The performance measurement telemetry (Section 4.2.3) can be used to provide service assurance at service and/or network levels. The performance measurement telemetry model can tie with service or network models to monitor network performance or Service Level Agreements.
性能測定テレメトリ（セクション4.2.3）を使用して、サービス保証をサービスおよび/またはネットワークレベルに提供することができます。パフォーマンス測定テレメトリモデルは、ネットワークのパフォーマンスまたはサービスレベル契約を監視するために、サービスまたはネットワークモデルと結びつけることができます。
Service optimization is a technique that gets the configuration of the network updated due to network changes, incident mitigation, or new service requirements. One example is once a tunnel or a VPN is set up, performance monitoring information or telemetry information per tunnel (or per VPN) can be collected and fed into the management system. If the network performance doesn't meet the service requirements, the management system can create new VPN policies capturing network service requirements and populate them into the network.
サービスの最適化は、ネットワークの変更、インシデント緩和、または新しいサービス要件によって更新されたネットワークの構成を取得する技術です。一例は、トンネルまたはVPNが設定されると、パフォーマンス監視情報またはトンネルあたりのテレメトリ情報（またはVPNごと）を収集して管理システムに供給することができる。ネットワークパフォーマンスがサービス要件を満たしていない場合、管理システムはネットワークサービスの要件をキャプチャしてネットワークに移入する新しいVPNポリシーを作成できます。
Both network performance information and policies can be modeled using YANG. With Policy-based management, self-configuration and self-optimization behavior can be specified and implemented.
ネットワークパフォーマンス情報とポリシーの両方をYangを使用してモデル化することができます。ポリシーベースの管理では、自己構成と自己最適化の動作を指定して実装できます。
The overall service optimization is managed at the service level, while the network level is responsible for the optimization of the specific network services it provides.
全体的なサービス最適化はサービスレベルで管理されていますが、ネットワークレベルはそれが提供する特定のネットワークサービスの最適化を担当します。
Operations, Administration, and Maintenance (OAM) are important networking functions for service diagnosis that allow network operators to:
操作、管理、および保守（OAM）は、ネットワーク事業者が次のようにするためのサービス診断のための重要なネットワーク機能です。
* monitor network communications (i.e., reachability verification and Continuity Check)
* ネットワーク通信を監視する（すなわち、到達可能性検証および継続確認）
* troubleshoot failures (i.e., fault verification and localization)
* 障害のトラブルシューティング（すなわち、障害検証とローカライゼーション）
* monitor service level agreements and performance (i.e., performance management)
* サービスレベル契約とパフォーマンスを監視する（すなわち、パフォーマンス管理）
When the network is down, service diagnosis should be in place to pinpoint the problem and provide recommendations (or instructions) for network recovery.
ネットワークが停止すると、問題を特定し、ネットワーク回復のための推奨事項（または説明）を提供するためのサービス診断が施されている必要があります。
The service diagnosis information can be modeled as technology-independent Remote Procedure Call (RPC) operations for OAM protocols and technology-independent abstraction of key OAM constructs for OAM protocols [RFC8531][RFC8533]. These models can be used to provide consistent configuration, reporting, and presentation for the OAM mechanisms used to manage the network.
サービス診断情報は、OAMプロトコルのための技術に依存しないリモートプロシージャコール（RPC）操作と、OAMプロトコルのための主要OAM構成要素の抽象化（RFC8531] [RFC8533]。これらのモデルは、ネットワークの管理に使用されるOAMメカニズムの一貫した構成、報告、および表示を提供するために使用できます。
Refer to Section 4.2.4 for the device-specific side.
デバイス固有のサイドのセクション4.2.4を参照してください。
Service decommission allows a customer to stop the service by removing the service from active status, thus releasing the network resources that were allocated to the service. Customers can also use the service model to withdraw the subscription to a service.
サービス廃止契約により、サービスをアクティブ状態から削除することで、顧客がサービスを停止させることができ、したがってサービスに割り当てられたネットワークリソースを解放できます。顧客はサービスモデルを使用してサービスを登録することもできます。
Intended configuration at the device level is derived from network models at the network level or service models at the service level and represents the configuration that the system attempts to apply. Take L3SM as a service model example to deliver an L3VPN service; there is a need to map the L3VPN service view defined in the service model into a detailed intended configuration view defined by specific configuration models for network elements. The configuration information includes:
デバイスレベルでの意図された設定は、サービスレベルでネットワークレベルまたはサービスモデルのネットワークモデルから導出され、システムが適用しようとする構成を表します。L3VPNサービスを提供するサービスモデル例としてL3SMを取ります。サービスモデルで定義されているL3VPNサービスビューをネットワーク要素の特定の構成モデルによって定義された詳細な設定ビューにマッピングする必要があります。構成情報には以下が含まれます。
* Virtual Routing and Forwarding (VRF) definition, including VPN policy expression
* VPNポリシー式を含む仮想ルーティングと転送（VRF）定義
* Physical Interface(s)
* 物理インタフェース
* IP layer (IPv4, IPv6)
* IP層（IPv4、IPv6）
* QoS features such as classification, profiles, etc.
* 分類、プロファイルなどのQoS機能
* Routing protocols: support of configuration of all protocols listed in a service request, as well as routing policies associated with those protocols
* ルーティングプロトコル：サービス要求にリストされているすべてのプロトコルの構成、およびそれらのプロトコルに関連付けられているルーティングポリシーのサポート
* Multicast support
* マルチキャストサポート
* Address sharing
* アドレス共有
* Security (e.g., access control, authentication, encryption)
* セキュリティ（例えば、アクセス制御、認証、暗号化）
These specific configuration models can be used to configure Provider Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP policy model can be used to establish VPN membership between sites and VPN service topology.
これらの特定の構成モデルは、サイト内のプロバイダエッジ（PE）およびカスタマーエッジ（CE）デバイス、例えばBGPポリシーモデルを使用して、サイトとVPNサービストポロジ間のVPNメンバーシップを確立することができます。
Note that in networks with legacy devices (that support proprietary modules or do not support YANG at all), an adaptation layer is likely to be required at the network level so that these devices can be involved in the delivery of the network services.
従来のデバイス（専用モジュールをサポートするか、全くサポートしていない）ネットワークでは、これらのデバイスがネットワークサービスの配信に関与できるように、ネットワークレベルで適応層が必要とされる可能性があります。
This interface is also used to handle service withdrawal (Section 4.1.6).
このインタフェースはサービス撤回を処理するためにも使用されます（セクション4.1.6）。
Configuration validation is used to validate intended configuration and ensure the configuration takes effect.
設定検証は、意図された設定を検証し、設定が有効になることを確認するために使用されます。
For example, if a customer creates an interface "eth-0/0/0" but the interface does not physically exist at this point, then configuration data appears in the <intended> status but does not appear in the <operational> datastore. More details about <intended> and <operational> datastores can be found in Section 5.1 of [RFC8342].
たとえば、顧客がインターフェイスを「eth-0 / 0/0 / 0」に作成した場合、インタフェースは物理的に存在しない場合、構成データは<対象>ステータスに表示されますが、<演算>データストアには表示されません。<意図>と<演算>データストアの詳細については、[RFC8342]のセクション5.1にあります。
When a configuration is in effect in a device, the <operational> datastore holds the complete operational state of the device, including learned, system, default configuration, and system state. However, the configurations and state of a particular device do not have visibility on the whole network, nor can they show how packets are going to be forwarded through the entire network. Therefore, it becomes more difficult to operate the entire network without understanding the current status of the network.
構成がデバイスで有効な場合、<演算>データストアは、学習、システム、デフォルト設定、およびシステム状態など、デバイスの完全な動作状態を保持します。ただし、特定のデバイスの構成と状態はネットワーク全体の可視性を持たず、パケット全体を通してパケットがどのように転送されるかを示すこともできません。したがって、ネットワークの現在の状態を理解せずにネットワーク全体を操作することが困難になる。
The management system should subscribe to updates of a YANG datastore in all the network devices for performance monitoring purposes and build a full topological visibility of the network by aggregating (and filtering) these operational states from different sources.
管理システムは、パフォーマンス監視の目的で、すべてのネットワークデバイスのYANGデータストアの更新をサブスクライブし、これらの操作状態を異なるソースから集約する（およびフィルタリング）することによってネットワークの完全なトポロジーの可視性を構築する必要があります。
When configuration is in effect in a device, some devices may be misconfigured (e.g., device links are not consistent in both sides of the network connection) or network resources might be misallocated. Therefore, services may be negatively affected without knowing the root cause in the network.
構成がデバイスで有効になっている場合、いくつかのデバイスが誤って設定されていてもよい（例えば、ネットワーク接続の両側ではデバイスリンクが一致しない）、またはネットワークリソースが誤って割り当てられている可能性がある。したがって、ネットワーク内の根本原因を知らずに、サービスが悪影響を受ける可能性があります。
Technology-dependent nodes and RPC commands are defined in technology-specific YANG data models, which can use and extend the base model described in Section 4.1.5 to deal with these issues.
テクノロジ依存ノードとRPCコマンドは、セクション4.1.5に記載されているベースモデルを使用してこれらの問題に対処するためのベースモデルを使用および拡張できる技術固有のYANDデータモデルで定義されています。
These RPC commands received in the technology-dependent node can be used to trigger technology-specific OAM message exchanges for fault verification and fault isolation. For example, Transparent Interconnection of Lots of Links (TRILL) Multi-destination Tree Verification (MTV) RPC command [TRILL-YANG-OAM] can be used to trigger Multi-Destination Tree Verification Messages (MTVMs) defined in [RFC7455] to verify TRILL distribution tree integrity.
テクノロジ依存ノードで受信されたこれらのRPCコマンドは、障害検証と障害分離のためのテクノロジ固有のOAMメッセージ交換をトリガするために使用できます。たとえば、ロットのLinks（Trill）マルチデスティネーションツリー検証（MTV）RPCコマンド[TRILL-YANG-OAM]の透過的な相互接続を使用して、[RFC7455]で定義されているマルチ宛先ツリー検証メッセージ（MTVMS）を検証するために使用できます。流通植樹の整合性の整合性。
Multi-layer/Multi-domain Service Mapping allows the mapping of an end-to-end abstract view of the service segmented at different layers and/or different network domains into domain-specific views.
マルチレイヤ/マルチドメインサービスマッピングにより、異なるレイヤーおよび/または異なるネットワークドメインでセグメント化されたサービスのエンドツーエンドの抽象ビューをドメイン固有のビューにマッピングできます。
One example is to map service parameters in the L3SM into configuration parameters such as Route Distinguisher (RD), Route Target (RT), and VRF in the L3VPN Network Model (L3NM).
1つの例は、L3SM内のサービスパラメータを、L3VPNネットワークモデル（L3NM）内のルート識別器（RD）、経路ターゲット（RT）、およびVRFなどの構成パラメータにマッピングすることです。
Another example is to map service parameters in the L3SM into Traffic Engineered (TE) tunnel parameters (e.g., Tunnel ID) in TE model and Virtual Network (VN) parameters (e.g., Access Point (AP) list and VN members) in the YANG data model for VN operation [ACTN-VN-YANG].
別の例は、ヤンのTEモデルおよび仮想ネットワーク（VN）パラメータ（例えば、アクセスポイント（AP）リストおよびVNメンバー）のトラフィックエンジニア（TE）トンネルパラメータ（例えば、トンネルID）にL3SM内のサービスパラメータをマッピングすることです。VN操作のデータモデル[ACTN-VN-YANG]。
Service Decomposition allows to decompose service models at the service level or network models at the network level into a set of device models at the device level. These device models may be tied to specific device types or classified into a collection of related YANG modules based on service types and features offered, and they may load at the implementation time before configuration is loaded and validated.
サービス分解により、ネットワークレベルでサービスレベルまたはネットワークモデルでサービスモデルをデバイスレベルで一連のデバイスモデルに分解できます。これらのデバイスモデルは、特定のデバイスタイプに関連付けられたり、提供されるサービスの種類や機能に基づいて関連するYANGモジュールの集まりに分類されたり、構成がロードされ検証される前に、実装時にロードされる可能性があります。
The following subsections provide some YANG data model integration examples.
以下のサブセクションでは、いくつかのYANDデータモデル統合例を提供します。
In reference to Figure 5, the following steps are performed to deliver the L3VPN service within the network management automation architecture defined in Section 4:
図5を参照して、セクション4で定義されているネットワーク管理オートメーションアーキテクチャ内でL3VPNサービスを配信するために次の手順を実行します。
1. The Customer requests to create two sites (as per Service Creation in Section 4.1.2) relying upon L3SM with each site having one network access connectivity, for example:
1. 顧客は、1つのネットワークアクセス接続を持つ各サイトでL3SMに依存する2つのサイトの作成要求があります。
* Site A: network-access A, link-capacity = 20 Mbps, class "foo", guaranteed-capacity-percent = 10, average-one-way-delay = 70 ms.
* サイトA：ネットワークアクセスA、Link-Capacity = 20 Mbps、クラス "foo"、保証容量 - パーセント= 10、平均1方向遅延= 70ミリ秒。
* Site B: network-access B, link-capacity = 30 Mbps, class "foo1", guaranteed-capacity-percent = 15, average-one-way-delay = 60 ms.
* サイトB：ネットワークアクセスB、リンク容量= 30 Mbps、クラス "foo 1"、保証容量 - パーセント= 15、平均1方向遅延= 60 ms。
2. The Orchestrator extracts the service parameters from the L3SM. Then, it uses them as input to the Service Mapping in Section 4.3 to translate them into orchestrated configuration parameters (e.g., RD, RT, and VRF) that are part of the L3NM specified in [OPSAWG-L3SM-L3NM].
2. オーケストラはL3SMからサービスパラメータを抽出します。その後、セクション4.3のサービスマッピングへの入力としてそれらを使用して、[opsawg-l3sm-l3nm]で指定されたL3nmの一部であるL3nmの一部であるOrchestrated設定パラメータ（例えば、RD、RT、VRF）に変換します。
3. The Controller takes the orchestrated configuration parameters in the L3NM and translates them into an orchestrated (Service Decomposition in Section 4.4) configuration of network elements that are part of, e.g., BGP, QoS, Network Instance, IP management, and interface models.
3. コントローラは、L3NM内のオーケストレーション設定パラメータを取り、それらを、例えばBGP、QoS、ネットワークインスタンス、IP管理、およびインターフェースモデルの一部であるネットワーク要素の構成（4.4節のサービス分解）の構成にそれらを変換します。
[UNI-TOPOLOGY] can be used for representing, managing, and controlling the User Network Interface (UNI) topology.
[UNI-Topology]ユーザーネットワークインターフェイス（UNI）トポロジの表現、管理、および制御に使用できます。
L3SM |
Service |
Model |
+------------------------+------------------------+
| +--------V--------+ |
| | Service Mapping | |
| +--------+--------+ |
| Orchestrator | |
+------------------------+------------------------+
L3NM | ^ UNI Topology Model
Network | |
Model | |
+------------------------+------------------------+
| +-----------V-----------+ |
| | Service Decomposition | |
| +--++---------------++--+ |
| || || |
| Controller || || |
+---------------++---------------++---------------+
|| ||
|| BGP, ||
|| QoS, ||
|| Interface, ||
+------------+| NI, |+------------+
| | IP | |
+--+--+ +--+--+ +--+--+ +--+--+
| CE1 +-------+ PE1 | | PE2 +-------+ CE2 |
+-----+ +-----+ +-----+ +-----+
Figure 5: L3VPN Service Delivery Example (Current)
図5：L3VPNサービス提供例（現在）
L3NM inherits some of the data elements from the L3SM. Nevertheless, the L3NM as designed in [OPSAWG-L3SM-L3NM] does not expose some information to the above layer such as the capabilities of an underlying network (which can be used to drive service order handling) or notifications (to notify subscribers about specific events or degradations as per agreed SLAs). Some of this information can be provided using, e.g., [OPSAWG-YANG-VPN]. A target overall model is depicted in Figure 6.
L3NMはL3SMからデータ要素の一部を継承します。それにもかかわらず、[opsawg-l3sm-l3nm]で設計されたL3nmは、基礎となるネットワークの機能（サービス順序処理を駆動するために使用することができる）または通知（特定のことについて購読者に通知するために）のような情報を上記のレイヤーに公開しません。同意されたSLAに対するイベントまたは劣化）。この情報のいくつかは、例えば[Opsawg-Yang-VPN]を使用して提供することができる。ターゲット全体モデルを図6に示します。
L3SM | ^
Service | | Notifications
Model | |
+------------------------+------------------------+
| +--------V--------+ |
| | Service Mapping | |
| +--------+--------+ |
| Orchestrator | |
+------------------------+------------------------+
L3NM | ^ UNI Topology Model
Network| | L3NM Notifications
Model | | L3NM Capabilities
+------------------------+------------------------+
| +-----------V-----------+ |
| | Service Decomposition | |
| +--++---------------++--+ |
| || || |
| Controller || || |
+---------------++---------------++---------------+
|| ||
|| BGP, ||
|| QoS, ||
|| Interface, ||
+------------+| NI, |+------------+
| | IP | |
+--+--+ +--+--+ +--+--+ +--+--+
| CE1 +-------+ PE1 | | PE2 +-------+ CE2 |
+-----+ +-----+ +-----+ +-----+
Figure 6: L3VPN Service Delivery Example (Target)
図6：L3VPNサービス提供例（ターゲット）
Note that a similar analysis can be performed for Layer 2 VPNs (L2VPNs). An L2VPN Service Model (L2SM) is defined in [RFC8466], while the YANG L2VPN Network Model (L2NM) is specified in [OPSAWG-L2NM].
なお、レイヤ2 VPN（L2VPN）についても同様の分析を行うことができる。L2VPNサービスモデル（L2SM）は[RFC8466]で定義されていますが、yang l2vpnネットワークモデル（L2nm）は[Opsawg-L2nm]に指定されています。
In reference to Figure 7, the following steps are performed to deliver the VN service within the network management automation architecture defined in Section 4:
図7を参照して、セクション4で定義されているネットワーク管理オートメーションアーキテクチャ内でVNサービスを配信するために次のステップが実行されます。
1. A customer makes a request (Service Exposure in Section 4.1.1) to create a VN. The association between the VN, APs, and VN members is defined in the VN YANG model [ACTN-VN-YANG].
1. 顧客はVNを作成するために要求（セクション4.1.1のサービスエクスポージャー）を作成します。VN、APS、およびVNメンバー間の関連付けは、VN Yang Model [Actn-Vn-Yang]で定義されています。
2. The Orchestrator creates the single abstract node topology based on the information captured in the request.
2. Orchestratorは、要求に取り込まれた情報に基づいて単一の抽象ノードトポロジを作成します。
3. The customer exchanges with the Orchestrator the connectivity matrix on the abstract node topology and explicit paths using the TE topology model [RFC8795]. This information can be used to instantiate the VN and set up tunnels between source and destination endpoints (Service Creation in Section 4.1.2).
3. 顧客は、抽象ノードトポロジとTEトポロジモデル[RFC8795]を使用した抽象ノードトポロジと明示的パスの接続マトリックスとの交換。この情報は、VNをインスタンス化し、送信元と宛先のエンドポイント（セクション4.1.2のサービス作成）の間でトンネルを設定できます。
4. In order to provide service assurance (Service Optimization in Section 4.1.4), the telemetry model that augments the VN model and corresponding TE tunnel model can be used by the Orchestrator to subscribe to performance measurement data. The Controller will then notify the Orchestrator with all the parameter changes and network performance changes related to the VN topology and the tunnels [TEAS-ACTN-PM].
4. サービス保証（セクション4.1.4のサービスの最適化）を提供するために、VNモデルと対応するTEトンネルモデルを強化するテレメトリモデルを使用して、パフォーマンス測定データを購読することができます。次に、コントローラは、VNトポロジとトンネル[TEAS-ACTN-PM]に関連するすべてのパラメータの変更とネットワーク性能の変更をorchestratorに通知します。
|
VN |
Service |
Model |
+----------------------|--------------------------+
| Orchestrator | |
| +--------V--------+ |
| | Service Mapping | |
| +-----------------+ |
+----------------------+--------------------^-----+
TE | Telemetry |
Tunnel | Model |
Model | |
+----------------------V--------------------+-----+
| Controller |
| |
+-------------------------------------------------+
+-----+ +-----+ +-----+ +-----+
| CE1 +------+ PE1 | | PE2 +------+ CE2 |
+-----+ +-----+ +-----+ +-----+
Figure 7: A VN Service Delivery Example
図7：VNサービス提供例
In reference to Figure 8, the following steps are performed to monitor state changes of managed resources in a network device and provide device self management within the network management automation architecture defined in Section 4:
図8を参照すると、ネットワークデバイス内の管理対象リソースの状態変化を監視し、セクション4で定義されているネットワーク管理自動化アーキテクチャ内でデバイス自己管理を提供するために次のステップが実行されます。
1. To control which state a network device should be in or is allowed to be in at any given time, a set of conditions and actions are defined and correlated with network events (e.g., allow the NETCONF server to send updates only when the value exceeds a certain threshold for the first time, but not again until the threshold is cleared), which constitute an Event Condition Action (ECA) policy or an event-driven policy control logic that can be executed on the device (e.g., [EVENT-YANG]).
1. ネットワークデバイスがどのような状態にあるか、またはどのような時刻にあるべきかを制御するために、一連の条件とアクションがネットワークイベントと定義され相関しています（たとえば、NetConfサーバが値がを超える場合にのみ更新を送信できるようにします。イベント条件アクション（ECA）ポリシーまたはデバイス上で実行できるイベント駆動型ポリシー制御ロジックを構成する、まず閾値がクリアされるまで、もう一度のしきい値がクリアされるだけではありません。）。
2. To provide a rapid autonomic response that can exhibit self-management properties, the Controller pushes the ECA policy to the network device and delegates the network control logic to the network device.
2. 自己管理プロパティを示すことができる迅速な自律神経応答を提供するために、コントローラはECAポリシーをネットワークデバイスにプッシュし、ネットワーク制御ロジックをネットワークデバイスに委任する。
3. The network device uses the ECA model to subscribe to the event source, e.g., an event stream or datastore state data conveyed to the server via YANG-Push subscription [RFC8641], monitors state parameters, and takes simple and instant actions when an associated event condition on state parameters is met. ECA notifications can be generated as the result of actions based on event stream subscription or datastore subscription (model-driven telemetry operation discussed in Section 4.2.3).
3. ネットワークデバイスは、ECAモデルを使用して、イベントストリームまたはデータストア状態データ、例えば、Yang-Pushサブスクリプション[RFC8641]、監視状態パラメータを監視し、関連するイベントを監視し、簡単でインスタントアクションを取ります。状態の状態パラメータが満たされています。ECA通知は、イベントストリームサブスクリプションまたはデータストアの購読またはデータストアの購読（モデル駆動テレメトリ操作）に基づくアクションの結果として生成できます（セクション4.2.3）。
+----------------+
| <----+
| Controller | |
+-------+--------+ |
| |
| |
ECA | | ECA
Model | | Notification
| |
| |
+------------V-------------+-----+
|Device | |
| +-------+ +---------+ +--+---+ |
| | Event +-> Event +->Event | |
| | Source| |Condition| |Action| |
| +-------+ +---------+ +------+ |
+--------------------------------+
Figure 8: Event-Based Telemetry
図8：イベントベースのテレメトリ
Many of the YANG modules cited 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]などのネットワーク管理プロトコルを介してアクセスするように設計されているデータのスキーマを定義します。最低のNetConfレイヤーはセキュアトランスポート層で、必須の実装セキュアトランスポートはSecure Shell（SSH）[RFC6242]です。最低のRETCONFレイヤーはhttpsで、必須のセキュアトランスポートはTLS [RFC8446]です。
The NETCONF access control model [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.
NETCONFアクセス制御モデル[RFC8341]は、特定のNETCONFまたはRESTCONFユーザへのアクセスを制限する手段を、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前設定されたサブセットに制限するための手段を提供します。
Security considerations specific to each of the technologies and protocols listed in the document are discussed in the specification documents of each of these protocols.
文書に記載されている各技術およびプロトコルに固有のセキュリティ上の考慮事項は、これらの各プロトコルの仕様書に記載されている。
In order to prevent leaking sensitive information and the "confused deputy" problem [Hardy] in general, special care should be considered when translating between the various layers in Section 4 or when aggregating data retrieved from various sources. Authorization and authentication checks should be performed to ensure that data is available to an authorized entity. The network operator must enforce means to protect privacy-related information included in customer-facing models.
漏洩機密情報と「混乱した副」問題[Hardy]一般的に、セクション4の様々なレイヤ間またはさまざまなソースから取得したデータを集約するときに特別な注意を考慮する必要があります。データが許可されたエンティティで利用可能であることを確認するために、許可および認証チェックを実行する必要があります。ネットワーク事業者は、顧客向けモデルに含まれるプライバシー関連情報を保護するための手段を強制する必要があります。
To detect misalignment between layers that might be induced by misbehaving nodes, upper layers should continuously monitor the perceived service (Section 4.1.4) and should proceed with checks to assess that the provided service complies with the expected service and that the data reported by an underlying layer is matching the perceived service by the above layer. Such checks are the responsibility of the service diagnosis (Section 4.1.5).
誤動率ノードによって誘発される可能性がある層の間のずれを検出するために、上位層は知覚サービスを継続的に監視し（4.1.4項）、提供されたサービスが予想されるサービスに準拠し、データが報告されたデータに準拠していることを確認するためのチェックを進めるべきである。基礎となるレイヤは、認識されたサービスと上のレイヤーによって一致しています。そのようなチェックはサービス診断の責任です（4.1.5項）。
When a YANG module includes security-related parameters, it is recommended to include the relevant information as part of the service assurance to track the correct functioning of the security mechanisms.
YANGモジュールがセキュリティ関連のパラメータを含む場合、セキュリティメカニズムの正しい機能を追跡するためにサービス保証の一部として関連情報を含めることをお勧めします。
Additional considerations are discussed in the following subsections.
以下のサブセクションでさらなる考慮事項について説明します。
A provider may rely on services offered by other providers to build composite services. Appropriate mechanisms should be enabled by the provider to monitor and detect a service disruption from these providers. The characterization of a service disruption (including mean time between failures and mean time to repair), the escalation procedure, and penalties are usually documented in contractual agreements (e.g., as described in Section 2.1 of [RFC4176]). Misbehaving peer providers will thus be identified and appropriate countermeasures will be applied.
プロバイダは、コンポジットサービスを構築するために他のプロバイダによって提供されるサービスに頼るかもしれません。これらのプロバイダからのサービスの混乱を監視および検出するために、プロバイダによって適切なメカニズムを有効にする必要があります。サービス中断の特徴（故障間の平均時間と修復までの時間を含む）、エスカレーション手順、および罰金は通常、契約上の協定（例えば、[RFC4176]のセクション2.1で説明されているように）記載されています。したがって、ピアプロバイダの不正行為を特定し、適切な対策が適用されます。
The communication protocols that make use of a service model between a customer and an operator are out of scope. Relevant security considerations should be discussed in the specification documents of these protocols.
顧客とオペレータとの間でサービスモデルを利用する通信プロトコルは範囲外である。関連するセキュリティ上の考慮事項は、これらのプロトコルの仕様書類で説明する必要があります。
Security considerations specific to the network level are listed below:
ネットワークレベルに固有のセキュリティ上の考慮事項を以下に示します。
* A controller may create forwarding loops by misconfiguring the underlying network nodes. It is recommended to proceed with tests to check the status of forwarding paths regularly or whenever changes are made to routing or forwarding processes. Such checks may be triggered from the service level owing to the means discussed in Section 4.1.5.
* 下にあるネットワークノードを構成することによって、コントローラが転送ループを作成することができる。テストを続行するには、パスを定期的に、またはルーティングまたは転送プロセスに変更が加えられたときはいつでも転送パスのステータスを確認することをお勧めします。そのようなチェックは、セクション4.1.5で説明されている手段のためにサービスレベルから引き起こされるかもしれません。
* Some service models may include a traffic isolation clause that is passed down to the network level so that appropriate technology-specific actions must be enforced at the underlying network (and thus involved network devices) to avoid that such traffic is accessible to non-authorized parties. In particular, network models may indicate whether encryption is enabled and, if so, expose a list of supported encryption schemes and parameters. Refer, for example, to the encryption feature defined in [OPSAWG-VPN-COMMON] and its use in [OPSAWG-L3SM-L3NM].
* 一部のサービスモデルには、そのようなトラフィックが許可されていない当事者にアクセス可能であることを回避するために、適切なテクノロジ固有のアクションを基礎となるネットワーク（またはネットワークデバイス）で適切なネットワークで強制されなければならないトラフィック分離句を含めることができます。。特に、ネットワークモデルは、暗号化が有効になっているかどうかを示し、そうである場合には、サポートされている暗号化方式とパラメータのリストを公開します。たとえば、[opsawg-vpn-common]で定義されている暗号化機能と[Opsawg-L3SM-L3nm]で参照してください。
Network operators should monitor and audit their networks to detect misbehaving nodes and abnormal behaviors. For example, OAM, as discussed in Section 4.1.5, can be used for that purpose.
ネットワーク事業者は、誤動作のノードと異常な行動を検出するためにネットワークを監視および監査する必要があります。たとえば、4.1.5項で説明したように、OAMをその目的に使用できます。
Access to some data requires specific access privilege levels. Devices must check that a required access privilege is provided before granting access to specific data or performing specific actions.
一部のデータへのアクセスは特定のアクセス権限を必要とします。特定のデータへのアクセスを許可するか、特定のアクションを実行する前に、デバイスが必要なアクセス権限が提供されていることを確認する必要があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>.
[RFC6241]、R.Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<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>.
[RFC6242] Wasserman、M.、「Secure Shell（SSH）のNetConfプロトコル（SSH）の使用（SSH）、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ED。、「Yang 1.1データモデリング言語」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<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>.
[RFC8040] Bierman、A.、Bjorklund、M.、K。Watsen、 "Restconf Protoction"、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https：//www.rfc-editor.org/info/rfc8040>。
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341] Bierman、A.およびM.Bjorklund、「ネットワーク構成アクセス制御モデル」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https：//www.rfc-editor.org/info/rfc8341>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[ACTN-VN-YANG] Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. Yoon, "A YANG Data Model for VN Operation", Work in Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-10, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-10>.
[ACTN-VN-Yang] Lee、Y.、Dhody、D.、Ceccarelli、D.、Bryskin、I.、および「a yang operationのためのヤンデータモデル」、進行中、インターネットドラフト、ドラフト-ietf-teas-actn-vn-yang-10,2020、<https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-10>
[BFD-YANG] Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", Work in Progress, Internet-Draft, draft-ietf-bfd-yang-17, 2 August 2018, <https://tools.ietf.org/html/draft-ietf-bfd-yang-17>.
[BFD-YANG] Rahman、R.、Zheng、L.、Jethanandani、M.、Palhagatti、S.、およびG. Mirsky、「双方向転送検出のためのYangデータモデル（BFD）」、進行中の作業、インターネットドラフト、ドラフトIETF-BFD-YANG-17,28月2日、<https://tools.ietf.org/html/draft-ietf-bfd-yang-17>。
[DOTS-DDOS] Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Work in Progress, Internet-Draft, draft-ietf-dots-rfc8782-bis-04, 3 December 2020, <https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-04>.
[DOTS-DDOS] Boucadair、M.、Shallow、J.、およびT.Reddy.k、「分散サービス拒否オープン脅威シグナリング（ドット）信号チャネル仕様」、進行中の作業、インターネットドラフト、ドラフト - IETF-DOTS-RFC8782-BIS-04,22月3日、<https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-04>。
[EVENT-YANG] Wu, Q., Bryskin, I., Birkholz, H., Liu, X., and B. Claise, "A YANG Data model for ECA Policy Management", Work in Progress, Internet-Draft, draft-wwx-netmod-event-yang-10, 1 November 2020, <https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10>.
[イベントヤン]呉、Q.、Bryskin、I。、Birkholz、H.、Liu、X.、B. Claise、「ECA政策管理のためのYangデータモデル」、進行中の作業、インターネットドラフト、ドラフト-wwx-netmod-event-yang-10,11月1日、<https：//tools.ietf.org/html/draft-wwx-netmod-event-yang-10>
[EVPN-YANG] Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., and J. Rabadan, "Yang Data Model for EVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-yang-07, 11 March 2019, <https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-07>.
[Evpn-Yang]ブッケ、P.、Shah、H.、Hussain、I.、Tiruveedhula、K.、およびJ. Rabadan、「EVPNのヤンデータモデル」、進行中の作業、インターネットドラフト、ドラフトIETF-Bess-Evpn-Yang-07,2019、<https：//tools.ietf.org/html/draft-ietf-bess-evpn-yang-07>
[Hardy] Hardy, N., "The Confused Deputy: (or why capabilities might have been invented)", DOI 10.1145/54289.871709, October 1988, <https://dl.acm.org/doi/10.1145/54289.871709>.
[Hardy] Hardy、N.、「混乱した副:(または機能が発明されている可能性があるかも）」、DOI 10.1145 / 54289.871709、<https：//dl.acm.org/doi/10.1145/54289.871709>。
[IDR-BGP-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-10, 15 November 2020, <https://tools.ietf.org/html/draft-ietf-idr-bgp-model-10>.
[IDR-BGP-MODER] Jethanandani、M.、Patel、K.、HAAS、S、およびJ.HAAS、「サービスプロバイダネットワークのためのBGP Yangモデル」、進行中の作業、インターネットドラフト、ドラフトIETF-IDR-bgp-model-10、2020年11月15日、<https：//tools.ietf.org/html/draft-ietf-idr-bgp-model-10>。
[IPPM] IANA, "Performance Metrics", March 2020, <https://www.iana.org/assignments/performance-metrics/ performance-metrics.xhtml>.
[IPPM] IANA、「パフォーマンスメトリクス」、2020年3月、<https：//www.iana.org/assignments/performance-metrics/ performance-metrics.xhtml>。
[L2VPN-YANG] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based L2VPN", Work in Progress, Internet-Draft, draft-ietf-bess-l2vpn-yang-10, 2 July 2019, <https://tools.ietf.org/html/ draft-ietf-bess-l2vpn-yang-10>.
[L2VPN-YANG] Shah、H.、Brissette、P.、Chen、I.、Hussain、I.、B.、K.Tiruveedula、「MPLSベースL2VPNのYangデータモデル」、進行中の作業、2019年7月2日、<https://tools.ietf.org/html/ romft-ietf-bess-l2vpn-yang-l2vpn-yang-l2vpn-yang-l2vpn-yang-l2vpn-yang-10>。
[L3VPN-YANG] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model for BGP/MPLS L3 VPNs", Work in Progress, Internet-Draft, draft-ietf-bess-l3vpn-yang-04, 19 October 2018, <https://tools.ietf.org/html/draft-ietf-bess-l3vpn-yang-04>.
[L3VPN-Yang] Jain、D.、Patel、K.、Brissette、P.、Li、Z.、Zhuang、S.、Liu、X、Haas、J.、Esale、S.、B. Wen、「BGP / MPLS L3 VPNのYangデータモデル」、進行中の作業、インターネットドラフト、ドラフト-IETF-BESS-L3VPN-YANG-04、2018年10月19日、<https：//tools.ietf.org/html/draft-ietf-bess-l3vpn-yang-04>。
[METRIC-METHOD] Morton, A., Geib, R., and L. Ciavattone, "Metrics and Methods for One-way IP Capacity", Work in Progress, Internet-Draft, draft-ietf-ippm-capacity-metric-method-04, 10 September 2020, <https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-04>.
[メトリック法]モートン、A。、GEIB、R.、およびL.Ciavattone、「一方向IP容量のための測定基準および方法」、進行中の作業、インターネットドラフト、ドラフト - IETF-IPPM-CAPAITIC-Metric-Method-04,2020 2020年9月10日、<https：//tools.ietf.org/html/draft-ietf-itpm-capacity-metric-method-04>。
[MVPN-YANG] Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP IP VPNs", Work in Progress, Internet-Draft, draft-ietf-bess-mvpn-yang-04, 30 June 2020, <https://tools.ietf.org/html/draft-ietf-bess-mvpn-yang-04>.
[MVPN-Yang] Liu、Y.、Guo、F.、Litkowski、S.、Liu、X.、Kebakumar、R.、M.シバクマル、「MPLS / BGP IP VPNのマルチキャストのYangデータモデル」、作業進行中、インターネットドラフト、romp-ietf-bess-mvpn-yang-04,2020年6月30日、<https：//tools.ietf.org/html/draft-ietf-bess-mvpn-yang-04>。
[NETMOD-MODEL] Clarke, J. and B. Claise, "YANG module for yangcatalog.org", Work in Progress, Internet-Draft, draft-clacla-netmod-model-catalog-03, 3 April 2018, <https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-03>.
[NetMod-Model] Clarke、J.およびB. B. Claise、「Yangcatalog.org」、進行中の作業、インターネットドラフト、ドラフトCLACLA-NETMOD-MODEL-CATALOG-03、<https：//tools.ietf.org/html/draft-clacla-netmod-model-catalog-03>。
[OPSAWG-L2NM] Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., Jalil, L., and J. Ma, "A Layer 2 VPN Network YANG Model", Work in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-01, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-01>.
[Opsawg-L2NM] Barguil、S.、Dios、OGD、Boucadair、M.、Munoz、LA、Jalil、L.、およびJ. MA、「A層2 VPNネットワークヤンモデル」、進行中の作業、インターネットドラフト、draft-ietf-opsawgg-l2nm-01,2020、<https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-01>
[OPSAWG-L3SM-L3NM] Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05, 16 October 2020, <https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05>.
[Opsawg-L3SM-L3NM] Barguil、S.、Dios、OGD、Boucadair、M.、Munoz、LA、A. Aguado、「レイヤ3 VPNネットワークYangモデル」、進行中の作業、インターネットドラフト、ドラフト - IETF-Opsawg-L3SM-L3NM-05,2020、<https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05>。
[OPSAWG-VPN-COMMON] Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A Layer 2/3 VPN Common YANG Model", Work in Progress, Internet-Draft, draft-ietf-opsawg-vpn-common-03, 14 January 2021, <https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-03>.
[Opsawg-vpn-common] Barguil、S.、Dios、OGD、Boucadair、M.、およびQ.呉、「レイヤ2/3 VPN共通ヤンモデル」、進行中の作業、インターネットドラフト、ドラフト - IETF-Opsawg-vpn-common-03,14 1月14日、<https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-03>。
[OPSAWG-YANG-VPN] Wu, B., Wu, Q., Boucadair, M., Dios, O. G. D., Wen, B., Liu, C., and H. Xu, "A YANG Model for Network and VPN Service Performance Monitoring", Work in Progress, Internet-Draft, draft-www-opsawg-yang-vpn-service-pm-03, 21 January 2021, <https://tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-pm-03>.
[Opsawg-Yang-VPN] Wu、B.、Wu、Q.、Boucadair、M.、Dios、OGD、ウェン、B.、Liu、C、H. XU、「ネットワークのためのヤンモデルとVPNサービスパフォーマンスモニタリング、進行中の作業、インターネットドラフト、ドラフトwww-opsawg-yang-vpn-service-pm-03,201月21日、<https：//tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-PM-03>。
[PIM-YANG] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, Y., and F. Hu, "A YANG Data Model for Protocol Independent Multicast (PIM)", Work in Progress, Internet-Draft, draft-ietf-pim-yang-17, 19 May 2018, <https://tools.ietf.org/html/draft-ietf-pim-yang-17>.
[PIM-YANG] Liu、X.、McAllister、P.、Peter、A.、Sivakumar、M.、Liu、Y.、およびF. HU、「プロトコル独立マルチキャスト（PIM）のヤンデータモデル」、作業進行中、インターネットドラフト、Draft-IETF-PIM-YANG-17、2018年5月19日、<https：//tools.ietf.org/html/draft-ietf-pim-yang-17>。
[QOS-MODEL] Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., and I. Chen, "YANG Model for QoS", Work in Progress, Internet-Draft, draft-ietf-rtgwg-qos-model-02, 9 July 2020, <https://tools.ietf.org/html/draft-ietf-rtgwg-qos-model-02>.
[QoS-MODEL] Choudhary、A.、Jethanandani、M.、Strahle、N.、Aries、E.、およびI。、「QoSのヤンモデル」、進行中の作業、インターネットドラフト、ドラフト-IETF-RTGWG-qos-model-02,2020、<https://tools.ietf.org/html/draft-ietf-rtgwg-qos-model-02>。
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005, <https://www.rfc-editor.org/info/rfc4176>.
[RFC4176] El Mghazli、Y、Ed。、Nadeau、T.、Boucadair、M.、Chan、K.、およびA. Gonguet、「レイヤ3仮想プライベートネットワーク（L3VPN）操作と管理のためのフレームワーク」、RFC 4176、DOI 10.17487 / RFC4176、2005年10月、<https://www.rfc-editor.org/info/rfc4176>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.
[RFC4664]アンダーソン、L.、ED。E.ローゼン、「レイヤ2仮想プライベートネットワーク（L2VPNS）」、RFC 4664、DOI 10.17487 / RFC4664、2006年9月、<https://www.rfc-editor.org/info/rfc4664>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、ED。そして、rekhter、ed。、 "Virtual Private Lan Service（VPLS）、「自動検出およびシグナリングのためのBGPを使用したVPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<https：//www.rfc-editor.org/情報/ RFC4761>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M.、Ed。V. Kompella、ed。、「ラベル配布プロトコル（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（LDP）シグナリング（VPLS）、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<https：//www.rfc-editor.org/情報/ RFC4762>。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, <https://www.rfc-editor.org/info/rfc5136>.
[RFC5136] Chimento、P.およびJ.ISHAC、「ネットワーク容量の定義」、RFC 5136、DOI 10.17487 / RFC 5136、2008年2月、<https：//www.rfc-editor.org/info/rfc5136>。
[RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, DOI 10.17487/RFC5486, March 2009, <https://www.rfc-editor.org/info/rfc5486>.
[RFC5486] Malas、D.、ED。D. Meyer、ED。、「マルチメディアインターコネクトのためのセッションピアリング」、RFC 5486、DOI 10.17487 / RFC5486、2009年3月、<https：//www.rfc-editor.org/info/rfc5486>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D.およびD.ワード、「双方向転送検出（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>。
[RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture", RFC 6406, DOI 10.17487/RFC6406, November 2011, <https://www.rfc-editor.org/info/rfc6406>.
[RFC6406] Malas、D.、ED。J. Livingued、Ed。、「マルチメディアインターコネクトのためのセッションピアリング」、RFC 6406、DOI 10.17487 / RFC6406、2011年11月、<https：//www.rfc-editor.org/info/rfc6406>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M.およびC. Jacquenet、「ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの視点」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<https：///www.rfc-編集者。ORG / INFO / RFC7149>。
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.
[RFC7224] Bjorklund、M.、「IANAインタフェースタイプヤンモジュール」、RFC 7224、DOI 10.17487 / RFC7224、2014年5月、<https：//www.rfc-editor.org/info/rfc7224>。
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.
[RFC7276] Mizrahi、T.、Sprecher、N.、Bellagamba、E.、Y.Weingarten、「オペレーション、管理、メンテナンスの概要（OAM）ツール」、RFC 7276、DOI 10.17487 / RFC7276、2014年6月、<https://www.rfc-editor.org/info/rfc7276>。
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.
[RFC7297] Boucadair、M.、Jacquenet、C.、およびN. Wang、 "IP Connectivity Provisioning Profile（CPP）"、RFC 7297、DOI 10.17487 / RFC7297、2014年7月、<https：//www.rfc-編集者。ORG / INFO / RFC7297>。
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7317] Bierman、A.およびM.Bjorklund、「システム管理のためのYangデータモデル」、RFC 7317、DOI 10.17487 / RFC7317、2014年8月、<https://www.rfc-editor.org/info/rfc7317>。
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <https://www.rfc-editor.org/info/rfc7455>.
[RFC7455] Senevirathne、T.、Finn、N.、Salam、S.、Kumar、D.、Eastlake 3rd、D.、Aldrin、S.、およびY.Li、 "Lindsの透明な相互接続（トリル）：Fault Management "、RFC 7455、DOI 10.17487 / RFC7455、2015年3月、<https：//www.rfc-editor.org/info/rfc7455>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、ED。「サービス機能連鎖（SFC）アーキテクチャ」、RFC 7665、DOI 10.17487 / RFC7665、<https：//www.rfc-editor.org/info/rfc7665>。
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7679] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向遅延メトリック（IPPM）」、STD 81、RFC 7679、DOI 10.17487/ RFC7679、2016年1月、<https://www.rfc-editor.org/info/rfc7679>。
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7680] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向損失測定基準（IPPM）」、STD 82、RFC 7680、DOI 10.17487/ RFC7680、2016年1月、<https://www.rfc-editor.org/info/rfc7680>。
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.
[RFC8077] Martini、L.、ED。G. Heron、Ed。、「ラベル配布プロトコル（LDP）」、STD 84、RFC 8077、DOI 10.17487 / RFC8077、2017年2月、<https：//www.rfc-editor.org/情報/ RFC8077>。
[RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, August 2017, <https://www.rfc-editor.org/info/rfc8194>.
[RFC8194] Schoenwaelder、J.およびV. Bajpai、「LMAP測定エージェントのYangデータモデル」、RFC 8194、DOI 10.17487 / RFC8194、2017年8月、<https：//www.rfc-editor.org/info/rfc8194>。
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8199] Bogdanovic、D.、Claise、B.、およびC. Moberg、 "Yang Module Classification"、RFC 8199、DOI 10.17487 / RFC8199、2017年7月、<https：//www.rfc-editor.org/info/RFC8199>。
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.
[RFC8299] WU、Q。、ED。、Litkowski、S.、Tomotaki、L.、およびK.小垣、「L3VPNサービス提供のためのYangデータモデル」、RFC 8299、DOI 10.17487 / RFC8299、2018年1月、<https：//www.rfc-editor.org/info/rfc8299>。
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.
[RFC8309] WU、Q.、Liu、W.およびA. Farrel、「サービスモデルは説明しました」、RFC 8309、DOI 10.17487 / RFC8309、2018年1月、<https：//www.rfc-editor.org/info/RFC8309>。
[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>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K.、R. Wilton、「ネットワーク管理データストアアーキテクチャ（NMDA）」、RFC 8342、DOI 10.17487 / RFC8342、2018年3月、<https://www.rfc-editor.org/info/rfc8342>。
[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>.
[RFC8343] Bjorklund、M.、「インタフェース管理のためのYangデータモデル」、RFC 8343、DOI 10.17487 / RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8345] CLEMM、A.、Medved、J.、Varga、R.、Bahadur、N.、Ananthakrishnan、H.、およびX. Liu、 "ネットワークトポロジのヤンデータモデル"、RFC 8345、DOI 10.17487 / RFC8345、2018年3月、<https://www.rfc-editor.org/info/rfc8345>。
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, March 2018, <https://www.rfc-editor.org/info/rfc8346>.
[RFC8346] CLEMM、A.、Medved、J.、Varga、R.、Liu、X.、Ananthakrishnan、H.、およびN. Bahadur、「層3トポロジのYangデータモデル」、RFC 8346、DOI 10.17487 /RFC8346、2018年3月、<https://www.rfc-editor.org/info/rfc8346>。
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, <https://www.rfc-editor.org/info/rfc8348>.
[RFC8348] Bierman、A。、Bjorklund、M.、Dong、J.、およびD. Romascanu、「ハードウェア管理のためのヤンデータモデル」、RFC 8348、DOI 10.17487 / RFC8348、2018年3月、<HTTPS：// WWW.rfc-editor.org / info / rfc8348>。
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.
[RFC8349] Lhotka、Lindem、A.、およびY。QU、「ルーティング管理のためのYangデータモデル（NMDA版）」、RFC 8349、DOI 10.17487 / RFC8349、2018年3月、<https：// www。rfc-editor.org/info/rfc8349>。
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8466]ウェン、B.、Fioccola、G.、ED。、XIE、C、およびL.Jalil、「レイヤ2仮想プライベートネットワーク（L2VPN）サービス配信のためのYangデータモデル、RFC 8466、DOI 10.17487 /RFC8466、2018年10月、<https：//www.rfc-editor.org/info/rfc8466>。
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, <https://www.rfc-editor.org/info/rfc8512>.
[RFC8512] Boucadair、M.、Ed。、Sivakumar、S、Jacquenet、C、Vinapamula、S.、およびQ. WU、「ネットワークアドレス変換用Yangモジュール」（NAT）およびネットワークプレフィックス翻訳（NPT） "、RFC 8512、DOI 10.17487 / RFC8512、2019年1月、<https：//www.rfc-editor.org/info/rfc8512>。
[RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, <https://www.rfc-editor.org/info/rfc8513>.
[RFC8513] Boucadair、M.、Jacquenet、C.、S.Sivakumar、「デュアルスタックライト（DS-Lite）のYangデータモデル、RFC 8513、DOI 10.17487 / RFC8513、2019年1月、<https：//www.rfc-editor.org/info/rfc8513>。
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/info/rfc8519>.
[RFC8519] Jethanandani、M.、Agarwal、S.、Huang、L.、D.Bleair、「ネットワークアクセス制御リストのためのYangデータモデル（ACLS）」、RFC 8519、DOI 10.17487 / RFC8519、2019年3月、<HTTPS//www.rfc-editor.org/info/rfc8519>。
[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>.
[RFC8525] Bierman、A.、Bjorklund、M.、Schoenwaelder、J.、Watsen、K.、およびR. Wilton、「Yang Library」、RFC 8525、RFC8525、2019年3月、<https：// WWW.rfc-editor.org / info / rfc8525>。
[RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/info/rfc8528>.
[RFC8528] Bjorklund、M.およびL. L. L. L. L. L. L. L. L. L. L. L. L. L. yfc 8528、DOI 10.17487 / RFC8528、2019年3月、<https：//www.rfc-editor.org/info/rfc8528>。
[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Data Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, March 2019, <https://www.rfc-editor.org/info/rfc8529>.
[RFC8529] Berger、L.、Hopps、C.、Lindem、A.、Bogdanovic、D.、およびX. Liu、 "Network Instances for Network InstancesのYangデータモデル"、RFC 8529、DOI 10.17487 / RFC8529、2019年3月、<HTTPS//www.rfc-editor.org/info/rfc8529>。
[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", RFC 8530, DOI 10.17487/RFC8530, March 2019, <https://www.rfc-editor.org/info/rfc8530>.
[RFC8530] Berger、L.、Hopps、C.、Lindem、A.、Bogdanovic、D.、およびX. Liu、 "Yang Model" RFC 8530、DOI 10.17487 / RFC8530、2019年3月、<HTTPS//www.rfc-editor.org/info/rfc8530>。
[RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols", RFC 8531, DOI 10.17487/RFC8531, April 2019, <https://www.rfc-editor.org/info/rfc8531>.
[RFC8531] Kumar、D.、Wu、Q.、およびZ. Wang、「接続指向操作、管理、メンテナンス（OAM）プロトコル（OAM）プロトコルのための一般的なYangデータモデル」、RFC 8531、DOI 10.17487 / RFC8531、2019年4月、<https://www.rfc-editor.org/info/rfc8531>。
[RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8532, DOI 10.17487/RFC8532, April 2019, <https://www.rfc-editor.org/info/rfc8532>.
[RFC8532] Kumar、D.、Wang、Z.、WU、Q、ED。、Rahman、R.、およびS.Raghavan、「運用管理、管理、保守（OAM）プロトコルの一般的なYangデータモデルそれは、Connectionless Communications "、RFC 8532、DOI 10.17487 / RFC8532、2019年4月、<https://www.rfc-editor.org/info/rfc8532>。
[RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, "A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8533, DOI 10.17487/RFC8533, April 2019, <https://www.rfc-editor.org/info/rfc8533>.
[RFC8533] Kumar、D.、Wang、M.、Wu、Q、ED。、Rahman、R.、およびS.Raghavan、「運用管理、管理、および保守のための検索方法のためのYangデータモデルOAM）Connectionless Communicationsを使用するプロトコル、RFC 8533、DOI 10.17487 / RFC8533、2019年4月、<https://www.rfc-editor.org/info/rfc8533>。
[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019, <https://www.rfc-editor.org/info/rfc8632>.
[RFC8632] Vallin、S.およびM.Bjorklund、「アラーム管理のためのヤンデータモデル」、RFC 8632、DOI 10.17487 / RFC8632、2019年9月、<https：//www.rfc-editor.org/info/rfc8632>。
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC8641] CLEMM、A.およびE. VOIT、「データストア更新のヤン通知への購読」、RFC 8641、DOI 10.17487 / RFC8641、2019年9月、<https：//www.rfc-editor.org/info/rfc8641>。
[RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. Peter, "A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November 2019, <https://www.rfc-editor.org/info/rfc8652>.
[RFC8652] Liu、X.、Guo、F.、Sivakumar、M.、McAllister、P.、A. Peter、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリ（MLD）のYangデータモデル」、RFC 8652、DOI 10.17487 / RFC8652、2019年11月、<https：//www.rfc-editor.org/info/rfc8652>。
[RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data Model for Tunnel Interface Types", RFC 8675, DOI 10.17487/RFC8675, November 2019, <https://www.rfc-editor.org/info/rfc8675>.
[RFC8675] Boucadair、M.、Farrer、I。、およびR. ASATI、「トンネルインタフェースタイプのヤンタデータモデル」、RFC 8675、DOI 10.17487 / RFC8675、2019年11月、<https：//www.rfc-編集者.org / info / rfc8675>。
[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, DOI 10.17487/RFC8676, November 2019, <https://www.rfc-editor.org/info/rfc8676>.
[RFC8676] Farrer、I。、ED。そして、「IPv4-in-IPv6アドレスプラスポート（AP）ソフトワイヤー用Yangモジュール」、RFC 8676、DOI 10.17487 / RFC8676、2019年11月、<https：//ww.rfc-editor.org/情報/ RFC8676>。
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8783] Boucadair、M.、Ed。そして、「分散サービス拒否オープン脅威シグナル伝達（ドット）データチャネル仕様」、RFC 8783、DOI 10.17487 / RFC8783、<https：//www.rfc-編集者。ORG / INFO / RFC8783>。
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC8791] Bierman、A.、Björklund、M.、K。Watsen、「Yang Data Structions Extensions」、RFC 8791、DOI 10.17487 / RFC8791、2020年6月、<https：//www.rfc-editor.org/info/ RFC8791>。
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, <https://www.rfc-editor.org/info/rfc8795>.
[RFC8795] Liu、X.、Bryskin、I。、Bearam、V.、Saad、T.、Shah、H.、およびO.Gonzalez de Dios、 "Traffic Engineering（TE）トポロジのためのヤンデータモデル"、RFC 8795、DOI 10.17487 / RFC8795、2020年8月、<https://www.rfc-editor.org/info/rfc8795>。
[RFC8819] Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module Tags", RFC 8819, DOI 10.17487/RFC8819, January 2021, <https://www.rfc-editor.org/info/rfc8819>.
[RFC8819] Hopps、C、Berger、L.、およびD. Bogdanovic、 "Yang Module Tags"、RFC 8819、DOI 10.17487 / RFC8819、2021年1月、<https：//www.rfc-editor.org/info/RFC8819>。
[RFC8944] Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A YANG Data Model for Layer 2 Network Topologies", RFC 8944, DOI 10.17487/RFC8944, November 2020, <https://www.rfc-editor.org/info/rfc8944>.
[RFC8944] Dong、J.、Wei、X.、WU、Q.、Boucadair、M.、A. Liu、「LiNe 2ネットワークトポロジのYangデータモデル」、RFC 8944、DOI 10.17487 / RFC8944、2020年11月<https://www.rfc-editor.org/info/rfc8944>。
[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", RFC 8960, DOI 10.17487/RFC8960, December 2020, <https://www.rfc-editor.org/info/rfc8960>.
[RFC8960] Saad、T.、Raza、K.、Gandhi、R.、Liu、X.、およびV. Beeram、「MPLSベースのYangデータモデル」、RFC 8960、DOI 10.17487 / RFC8960、2020年12月、<https://www.rfc-editor.org/info/rfc8960>。
[RTGWG-POLICY] Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data Model for Routing Policy", Work in Progress, Internet-Draft, draft-ietf-rtgwg-policy-model-27, 10 January 2021, <https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-27>.
[RTGWG-Policy] Qu、Y、Tantsura、J.、Lindem、A.、およびX。LIU、「ルーティングポリシーのためのヤンデータモデル」、進行中の作業、インターネットドラフト、romp-ietf-rtgwg-policy-Model-27,27 1月10日、<https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-27>
[SNOOPING-YANG] Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, "A Yang Data Model for IGMP and MLD Snooping", Work in Progress, Internet-Draft, draft-ietf-pim-igmp-mld-snooping-yang-18, 14 August 2020, <https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-snooping-yang-18>.
[スヌーピングヤン] Zhao、H.、Liu、X.、Liu、Y.、Sivakumar、M.、およびA. Peter、「IGMPとMLDスヌーピングのためのヤンデータモデル」、進行中の作業、インターネットドラフト、Draft-IETF-PIM-IGMP-MLD-Snooping-Yang-18,18,14月14日、<https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-snooping-yang-18>。
[SPRING-SR-YANG] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr-yang-29, 8 December 2020, <https://tools.ietf.org/html/draft-ietf-spring-sr-yang-29>.
[Spring-SR-Yang] Litkowski、S.、Qu、Y.、Lindem、A.、Sarkar、P.、J. Tantsura、「セグメントルーティングのためのヤンデータモデル」、進行中の作業、インターネットドラフト、ドラフト-ietf-spring-sr-yang-29、2020年12月8日、<https://tools.ietf.org/html/draft-ietf-spring-sr-yang-29>。
[STAMP-YANG] Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-06, 7 October 2020, <https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-06>.
[スタンプ - ヤン] Mirsky、G.、Min、X.およびWS LUO、「シンプルな双方向アクティブ測定プロトコル（スタンプ）データモデル」、進行中の作業、インターネットドラフト、ドラフトITF-IPPMスタンプ - Yang-06、2020年10月7日、<https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-06>。
[TEAS-ACTN-PM] Lee, Y., Dhody, D., Karunanithi, S., Vilalta, R., King, D., and D. Ceccarelli, "YANG models for VN/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Work in Progress, Internet-Draft, draft-ietf-teas-actn-pm-telemetry-autonomics-04, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-teas-actn-pm-telemetry-autonomics-04>.
[ティー - actn-pm] Lee、Y.、Dhody、D.、Karunanithi、S.、Vilalta、R.、King、D.、D. Ceccarelli、「VN / TEパフォーマンスのためのYangモデル監視テレメトリおよびスケーリング意図自律工事、進行中の作業、インターネットドラフト、ドラフト - IETF-TEAS-ACTN-PM-Telemetry-Autonics-04,2020年11月2日、<https://tools.ietf.org/html/draft-ietf-teas-ACTN-PM-Telemetry-Autonomics-04>。
[TEAS-YANG-PATH-COMP] Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, "Yang model for requesting Path Computation", Work in Progress, Internet-Draft, draft-ietf-teas-yang-path-computation-11, 16 November 2020, <https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-11>.
[ティー - ヤン - パス - COMP] BUSI、I。、S.、Lopez、V.、Sharma、A.、Y。Shi、「パスの計算を要求するためのヤンモデル」、進行中、インターネットドラフト、<https://tools.ietf.org/html/draft-ietf-teas-yang-path-ietf-teas-yang-path-ietf-teas-yang-path-ietf-teas-yang-path-ietf-teas --yang-path-11>
[TEAS-YANG-RSVP] Beeram, V. P., Saad, T., Gandhi, R., Liu, X., Bryskin, I., and H. Shah, "A YANG Data Model for RSVP-TE Protocol", Work in Progress, Internet-Draft, draft-ietf-teas-yang-rsvp-te-08, 9 March 2020, <https://tools.ietf.org/html/ draft-ietf-teas-yang-rsvp-te-08>.
[ティー - ヤンRSVP] Bearam、VP、Saad、T.、Gandhi、R.、Liu、X.、Bryskin、I.、およびH. Shah、「RSVP-TEプロトコルのYangデータモデル」進捗状況、インターネットドラフト、ドラフト-IETF-TEAS-YANG-RSVP-TE-08,2020、<https：//tools.ietf.org/html/草案-IETF-TEAS-YANG-RSVP-TE-08>。
[TEAS-YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-25, 27 July 2020, <https://tools.ietf.org/html/draft-ietf-teas-yang-te-25>.
[ティー - ヤン - テ] Saad、T.、Gandhi、R.、Liu、X.、Beeram、VP、I. Bryskin、「トラフィック工学トンネルのヤンデータモデル、ラベルスイッチパスやインタフェース」、2020年7月27日、<https://tools.ietf.org/html/draft-ietf-teas-yang-te---25>。
[TRILL-YANG-OAM] Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., and W. Hao, "YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)", Work in Progress, Internet-Draft, draft-ietf-trill-yang-oam-05, 31 March 2017, <https://tools.ietf.org/html/draft-ietf-trill-yang-oam-05>.
[Trill-Yang-OAM] Kumar、D.、Senevirathne、T.、Finn、N.、Salam、S.、Xia、L.、W. Hao、 "Trill Operations、管理、保守のためのYangデータモデル（OAM）「進行中の作業、インターネットドラフト、ドラフト - IETF-TRILL-YANG-OAM-05,2017,31、<https：//tools.ietf.org/html/draft-ietf-triill-yang-oam-05>。
[TWAMP-DATA-MODEL] Civil, R., Morton, A., Rahman, R., Jethanandani, M., and K. Pentikousis, "Two-Way Active Measurement Protocol (TWAMP) Data Model", Work in Progress, Internet-Draft, draft-ietf-ippm-twamp-yang-13, 2 July 2018, <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13>.
[Twamp-Data-Model] Civil、R.、Morton、A.、Rahman、R.、Jetethanandani、M.、K. Pentikousis、「双方向アクティブ測定プロトコル（TWAMP）データモデル」、進行中の作業、インターネットドラフト、ドラフト - IETF-IPPM-Twamp-Yang-13,21月2日、<https://tools.ietf.org/html/draft-ietf-itpm-twamp-yang-13>
[UNI-TOPOLOGY] Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A YANG Model for User-Network Interface (UNI) Topologies", Work in Progress, Internet-Draft, draft-ogondio-opsawg-uni-topology-01, 2 April 2020, <https://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01>.
[Uni-Topology] Dios、OGD、Barguil、S.、Wu、Q.、およびM. Boucadair、「ユーザーネットワークインタフェースのためのYangモデル」、進行中の作業、インターネットドラフト、ドラフト - Ogondio-opsawg-uni-topology-01,14月2日、<https://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01>。
This appendix lists a set of YANG data models that can be used for the delivery of connectivity services. These models can be classified as service, network, or device models.
この付録では、接続性サービスの配信に使用できるYANDデータモデルのセットがリストされています。これらのモデルは、サービス、ネットワーク、またはデバイスモデルとして分類できます。
It is not the intent of this appendix to provide an inventory of tools and mechanisms used in specific network and service management domains; such inventory can be found in documents such as [RFC7276].
特定のネットワークおよびサービス管理ドメインで使用されるツールとメカニズムのインベントリを提供するのはこの付録の意図ではありません。そのような在庫は[RFC7276]のような文書にあります。
The reader may refer to the YANG Catalog (<https://www.yangcatalog.org>) or the public Github YANG repository (<https://github.com/YangModels/yang>) to query existing YANG models. The YANG Catalog includes some metadata to indicate the module type ('module-classification') [NETMOD-MODEL]. Note that the mechanism defined in [RFC8819] allows to associate tags with YANG modules in order to help classifying the modules.
リーダーは、既存のYangモデルを照会するために、Yangカタログ（<https://www.yangcatalog.org>）またはパブリックGitHub Yangリポジトリ（<https://github.com/yangmodels/yang>）を参照することができます。YANGカタログには、モジュールタイプ（ 'module-classification'）[netmod-model]を示すためのいくつかのメタデータが含まれています。[RFC8819]で定義されているメカニズムは、モジュールの分類を手助けするために、Yangモジュールとタグを関連付けることができます。
As described in [RFC8309], the service is "some form of connectivity between customer sites and the Internet or between customer sites across the network operator's network and across the Internet". More concretely, an IP connectivity service can be defined as the IP transfer capability characterized by a (Source Nets, Destination Nets, Guarantees, Scope) tuple where "Source Nets" is a group of unicast IP addresses, "Destination Nets" is a group of IP unicast and/or multicast addresses, and "Guarantees" reflects the guarantees (expressed, for example, in terms of QoS, performance, and availability) to properly forward traffic to the said "Destination" [RFC7297]. The "Scope" denotes the network perimeter (e.g., between Provider Edge (PE) routers or Customer Nodes) where the said guarantees need to be provided.
[RFC8309]に記載されているように、サービスは「顧客サイトとインターネット間の一種の接続性、またはネットワーク事業者のネットワーク全体とインターネット全体の顧客サイト間」です。より具体的には、IP接続サービスは、（ソースネット、宛先ネット、保証、スコープ）タプルを特徴とするIP転送機能として定義することができ、「ソースネット」はユニキャストIPアドレスのグループである「宛先ネット」はグループです。IPユニキャストアドレスおよび/またはマルチキャストアドレスのうち、「保証」は、当該「宛先」[RFC7297]にトラフィックを正しく転送するための保証（例えば、QoS、パフォーマンス、および可用性に関して表現されている）を反映しています。「スコープ」は、前記保証が提供される必要があるネットワーク周辺（例えば、プロバイダエッジ（PE）ルータまたは顧客ノード間）を意味する。
For example:
例えば：
* The L3SM [RFC8299] defines the L3VPN service ordered by a customer from a network operator.
* L3SM [RFC8299]は、ネットワーク事業者から顧客が順序付けられたL3VPNサービスを定義しています。
* The L2SM [RFC8466] defines the L2VPN service ordered by a customer from a network operator.
* L2SM [RFC8466]は、ネットワーク事業者から顧客が順序付けられたL2VPNサービスを定義しています。
* The Virtual Network (VN) model [ACTN-VN-YANG] provides a YANG data model applicable to any mode of VN operation.
* 仮想ネットワーク（VN）モデル[ACTN-VN-YANG]は、VN操作の任意のモードに適用可能なYANGデータモデルを提供します。
L2SM and L3SM are customer service models as per [RFC8309].
L2SMおよびL3SMは、[RFC8309]のカスタマーサービスモデルです。
Modularity and extensibility were among the leading design principles of the YANG data modeling language. As a result, the same YANG module can be combined with various sets of other modules and thus form a data model that is tailored to meet the requirements of a specific use case. [RFC8528] defines a mechanism, denoted "schema mount", that allows for mounting one data model consisting of any number of YANG modules at a specified location of another (parent) schema.
モジュール性と拡張性は、Yangデータモデリング言語の主要な設計原則の1つでした。その結果、同じYANDモジュールを他の様々なモジュールと組み合わせることができ、したがって、特定のユースケースの要件を満たすように調整されたデータモデルを形成することができる。[RFC8528]「スキーママウント」と呼ばれるメカニズムを定義しています。これにより、任意の数のYANGモジュールからなる1つのデータモデルを別の（親）スキーマの場所にマウントすることができます。
L2NM [OPSAWG-L2NM] and L3NM [OPSAWG-L3SM-L3NM] are examples of YANG network models.
L2NM [OPSAWG-L2NM]とL3NM [OpsaWG-L3SM-L3NM]は、YANGネットワークモデルの例です。
Figure 9 depicts a set of additional network models such as topology and tunnel models:
図9は、トポロジやトンネルモデルなどの追加のネットワークモデルのセットを示しています。
+-------------------------------+-------------------------------+
| Topology YANG modules | Tunnel YANG modules |
+-------------------------------+-------------------------------+
| +------------------+ | |
| |Network Topologies| | +------+ +-----------+ |
| | Model | | |Other | | TE Tunnel | |
| +--------+---------+ | |Tunnel| +----+------+ |
| | +---------+ | +------+ | |
| +---+Service | | +----------+---------+ |
| | |Topology | | | | | |
| | +---------+ | | | | |
| | +---------+ |+----+---+ +----+---+ +---+---+|
| +---+Layer 3 | ||MPLS-TE | |RSVP-TE | | SR-TE ||
| | |Topology | || Tunnel | | Tunnel | |Tunnel ||
| | +---------+ |+--------+ +--------+ +-------+|
| | +---------+ | |
| +---+TE | | |
| | |Topology | | |
| | +---------+ | |
| | +---------+ | |
| +---+Layer 3 | | |
| |Topology | | |
| +---------+ | |
+-------------------------------+-------------------------------+
Figure 9: Sample Resource-Facing Network Models
図9：リソース面ネットワークモデルのサンプル
Examples of topology YANG modules are listed below:
トポロジーYANGモジュールの例を以下に示します。
Network Topologies Model: [RFC8345] defines a base model for network topology and inventories. Network topology data includes link, node, and terminate-point resources.
ネットワークトポロジモデル：[RFC8345]ネットワークトポロジとインベントリのベースモデルを定義します。ネットワークトポロジデータには、リンク、ノード、および終点リソースが含まれます。
TE Topology Model: [RFC8795] defines a YANG data model for representing and manipulating TE topologies.
TEトポロジモデル：[RFC8795] TEトポロジを表現し操作するためのYangデータモデルを定義します。
This module is extended from the network topology model defined in [RFC8345] and includes content related to TE topologies. This model contains technology-agnostic TE topology building blocks that can be augmented and used by other technology-specific TE topology models.
このモジュールは[RFC8345]で定義されているネットワークトポロジモデルから拡張され、TEトポロジに関連するコンテンツを含みます。このモデルには、他のテクノロジ固有のTEトポロジモデルによって増強され使用できるテクノロジ-Annostic TEトポロジビルドブロックが含まれています。
Layer 3 Topology Model: [RFC8346] defines a YANG data model for representing and manipulating Layer 3 topologies. This model is extended from the network topology model defined in [RFC8345] and includes content related to Layer 3 topology specifics.
レイヤ3トポロジモデル：[RFC8346]レイヤ3トポロジを表現および操作するためのYANGデータモデルを定義します。このモデルは[RFC8345]で定義されているネットワークトポロジモデルから拡張され、レイヤ3トポロジの詳細に関連するコンテンツを含みます。
Layer 2 Topology Model: [RFC8944] defines a YANG data model for representing and manipulating Layer 2 topologies. This model is extended from the network topology model defined in [RFC8345] and includes content related to Layer 2 topology specifics.
レイヤ2トポロジモデル：[RFC8944]レイヤ2トポロジを表現および操作するためのYANGデータモデルを定義します。このモデルは[RFC8345]で定義されているネットワークトポロジモデルから拡張され、レイヤ2トポロジの詳細に関連するコンテンツを含みます。
Examples of tunnel YANG modules are provided below:
トンネルヤンモジュールの例を以下に示します。
Tunnel Identities: [RFC8675] defines a collection of YANG identities used as interface types for tunnel interfaces.
トンネルID：[RFC8675]トンネルインタフェースのインターフェイスタイプとして使用されるYAND IDのコレクションを定義します。
TE Tunnel Model: [TEAS-YANG-TE] defines a YANG module for the configuration and management of TE interfaces, tunnels, and LSPs.
TEトンネルモデル：[TEAS-YANG-TE] TEインターフェイス、トンネル、LSPの構成と管理のためのヤンモジュールを定義します。
Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: [TEAS-YANG-TE] augments the TE generic and MPLS-TE model(s) and defines a YANG module for SR-TE-specific data.
セグメントルーティング（SR）トラフィックエンジニアリング（TE）トンネルモデル：[TEAS-YANG-TE] TE GENERICとMPLS-TEモデルを増強し、SR-TE固有のデータ用のYANGモジュールを定義します。
MPLS-TE Model: [TEAS-YANG-TE] augments the TE generic and MPLS-TE model(s) and defines a YANG module for MPLS-TE configurations, state, RPC, and notifications.
MPLS-TEモデル：[TEAS-YANG-TE] TE GENERICとMPLS-TEモデルを増強し、MPLS-TE構成、状態、RPC、および通知用のYANGモジュールを定義します。
RSVP-TE MPLS Model: [TEAS-YANG-RSVP] augments the RSVP-TE generic module with parameters to configure and manage signaling of MPLS RSVP-TE LSPs.
RSVP-TE MPLSモデル：[TEAS-YANG-RSVP]は、MPLS RSVP-TE LSPのシグナリングを設定および管理するためのパラメータを持つRSVP-TE GENERICモジュールを強化します。
Other sample network models are listed hereafter:
その他のサンプルネットワークモデルは以下のとおりです。
Path Computation API Model: [TEAS-YANG-PATH-COMP] defines a YANG module for a stateless RPC that complements the stateful solution defined in [TEAS-YANG-TE].
パス計算APIモデル：[TEAS-YANG-PATH-COMP]は、[TEAS-YANG-TE]で定義されているステートフルソリューションを補完するステートレスRPC用のYANGモジュールを定義します。
OAM Models (including Fault Management (FM) and Performance Monitoring): [RFC8532] defines a base YANG module for the management of OAM protocols that use Connectionless Communications. [RFC8533] defines a retrieval method YANG module for connectionless OAM protocols. [RFC8531] defines a base YANG module for connection-oriented OAM protocols. These three models are intended to provide consistent reporting, configuration, and representation for connectionless OAM and connection-oriented OAM separately.
OAMモデル（FAUT MANATION（FM）とパフォーマンスモニタリングを含む）：[RFC8532]コネクションレス通信を使用するOAMプロトコルの管理のための基本ヤンモジュールを定義します。[RFC8533]コネクションレスOAMプロトコルのための検索方法YANGモジュールを定義します。[RFC8531]接続指向OAMプロトコル用のベースヤンモジュールを定義します。これら3つのモデルは、コネクションレスOAMおよび接続指向OAMの一貫したレポート、構成、および表現を別々に提供することを目的としています。
Alarm monitoring is a fundamental part of monitoring the network. Raw alarms from devices do not always tell the status of the network services or necessarily point to the root cause. [RFC8632] defines a YANG module for alarm management.
警報監視は、ネットワークを監視するための基本的な部分です。デバイスからのRAWアラームは、ネットワークサービスのステータスを必ずしも伝えたり、必ず根本原因を指すとは限りません。[RFC8632]アラーム管理用のYANGモジュールを定義します。
Network Element models (listed in Figure 10) are used to describe how a service can be implemented by activating and tweaking a set of functions (enabled in one or multiple devices, or hosted in cloud infrastructures) that are involved in the service delivery. For example, the L3VPN service will involve many PEs and require manipulating the following modules:
ネットワーク要素モデル（図10に示す）は、サービス配信に関与している関数のセットを有効にして微調整することによってサービスの実装方法を説明するために使用されます。たとえば、L3VPNサービスには多くのPEが含まれており、次のモジュールを操作する必要があります。
* Routing management [RFC8349]
* ルーティング管理[RFC8349]
* BGP [IDR-BGP-MODEL]
* BGP [IDR-BGPモデル]
* PIM [PIM-YANG]
* Pim [Pim-Yang]
* NAT management [RFC8512]
* NATマネジメント[RFC8512]
* QoS management [QOS-MODEL]
* QoS管理[QoSモデル]
* ACLs [RFC8519]
* ACLS [RFC8519]
Figure 10 uses IETF-defined data models as an example.
図10は、例としてIETF定義データモデルを使用します。
+------------------------+
+-+ Device Model |
| +------------------------+
| +------------------------+
+---------------+ | | Logical Network |
| | +-+ Element Model |
| Architecture | | +------------------------+
| | | +------------------------+
+-------+-------+ +-+ Network Instance Model |
| | +------------------------+
| | +------------------------+
| +-+ Routing Type Model |
| +------------------------+
+-------+----------+----+------+------------+-----------+------+
| | | | | | |
+-+-+ +---+---+ +----+----+ +--+--+ +----+----+ +--+--+ |
|ACL| |Routing| |Transport| | OAM | |Multicast| | PM | Others
+---+ +-+-----+ +----+----+ +--+--+ +-----+---+ +--+--+
| +-------+ | +------+ | +--------+ | +-----+ | +-----+
+-+Core | +-+ MPLS | +-+ BFD | +-+IGMP | +-+TWAMP|
| |Routing| | | Base | | +--------+ | |/MLD | | +-----+
| +-------+ | +------+ | +--------+ | +-----+ | +-----+
| +-------+ | +------+ +-+LSP Ping| | +-----+ +-+OWAMP|
+-+ BGP | +-+ MPLS | | +--------+ +-+ PIM | | +-----+
| +-------+ | | LDP | | +--------+ | +-----+ | +-----+
| +-------+ | +------+ +-+MPLS-TP | | +-----+ +-+LMAP |
+-+ ISIS | | +------+ +--------+ +-+ MVPN| +-----+
| +-------+ +-+ MPLS | +-----+
| +-------+ |Static|
+-+ OSPF | +------+
| +-------+
| +-------+
+-+ RIP |
| +-------+
| +-------+
+-+ VRRP |
| +-------+
| +-------+
+-+SR/SRv6|
| +-------+
| +-------+
+-+ISIS-SR|
| +-------+
| +-------+
+-+OSPF-SR|
+-------+
Figure 10: Network Element Models Overview
図10：ネットワーク要素モデルの概要
Logical Network Element Model: [RFC8530] defines a logical network element model that can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are Logical Systems or Logical Routers.
論理ネットワーク要素モデル：[RFC8530]ネットワークデバイスに存在する可能性がある論理リソース分割を管理するために使用できる論理ネットワーク要素モデルを定義します。論理リソース分割の一般的な業界用語の例は、論理システムまたは論理ルータです。
Network Instance Model: [RFC8529] defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VRF instances and Virtual Switch Instances (VSIs).
ネットワークインスタンスモデル：[RFC8529]ネットワークインスタンスモジュールを定義します。このモジュールは、ネットワークデバイス上に存在する可能性がある仮想リソース分割を管理するために使用できます。仮想リソース分割の一般的な業界用語の例は、VRFインスタンスと仮想スイッチインスタンス（VSI）です。
The following list enumerates some YANG modules that can be used for device management:
次のリストは、デバイス管理に使用できる一部のYANGモジュールを列挙します。
* [RFC8348] defines a YANG module for the management of hardware.
* [RFC8348]ハードウェア管理のためのヤンモジュールを定義します。
* [RFC7317] defines the "ietf-system" YANG module that provides many features such as the configuration and the monitoring of system or system control operations (e.g., shutdown, restart, and setting time) identification.
* [RFC7317]構成やシステム制御操作（例えば、シャットダウン、再起動、および設定時間）の識別など、多くの機能を提供する「IETFシステム」Yangモジュールを定義します。
* [RFC8341] defines a network configuration access control YANG module.
* [RFC8341]ネットワーク構成アクセス制御YANGモジュールを定義します。
The following provides some YANG modules that can be used for interface management:
以下は、インターフェイス管理に使用できる一部のYANGモジュールを提供します。
* [RFC7224] defines a YANG module for interface type definitions.
* [RFC7224]インターフェースタイプの定義用のYANGモジュールを定義します。
* [RFC8343] defines a YANG module for the management of network interfaces.
* [RFC8343]ネットワークインタフェースの管理のためのYANGモジュールを定義します。
The following provides an overview of some device models that can be used within a network. This list is not comprehensive.
次に、ネットワーク内で使用できるデバイスモデルの一部の概要を説明します。このリストは包括的ではありません。
L2VPN: [L2VPN-YANG] defines a YANG module for MPLS-based Layer 2 VPN services (L2VPN) [RFC4664] and includes switching between the local attachment circuits. The L2VPN model covers point-to-point Virtual Private Wire Service (VPWS) and Multipoint Virtual Private LAN Service (VPLS). These services use signaling of Pseudowires across MPLS networks using LDP [RFC8077][RFC4762] or BGP [RFC4761].
L2VPN：[L2VPN-YANG]は、MPLSベースのレイヤ2 VPNサービス（L2VPN）[RFC4664]のYANGモジュールを定義し、ローカル接続回路を切り替えることを含みます。L2VPNモデルは、ポイントツーポイント仮想プライベートワイヤサービス（VPWS）とマルチポイント仮想プライベートLANサービス（VPLS）をカバーします。これらのサービスは、LDP [RFC8077] [RFC4762]またはBGP [RFC4761]を使用して、MPLSネットワーク間で疑似回線のシグナリングを使用しています。
EVPN: [EVPN-YANG] defines a YANG module for Ethernet VPN services. The model is agnostic of the underlay. It applies to MPLS as well as to Virtual eXtensible Local Area Network (VxLAN) encapsulation. The module is also agnostic to the services, including E-LAN, E-LINE, and E-TREE services.
EVPN：[EVPN-YANG]イーサネットVPNサービス用のYANGモジュールを定義します。モデルはアンダーレイの不安定です。それはMPLS、そして仮想拡張ローカルエリアネットワーク（VXLAN）カプセル化に適用されます。モジュールは、E-LAN、電子ライン、およびE-Tree Servicesなど、サービスにも不足しています。
L3VPN: [L3VPN-YANG] defines a YANG module that can be used to configure and manage BGP L3VPNs [RFC4364]. It contains VRF-specific parameters as well as BGP-specific parameters applicable for L3VPNs.
L3VPN：[L3VPN-YANG] BGP L3VPNS [RFC4364]の設定と管理に使用できるYANGモジュールを定義します。L3VPNSに適用可能なVRF固有のパラメータとBGP固有のパラメータが含まれています。
Core Routing: [RFC8349] defines the core routing YANG data model, which is intended as a basis for future data model development covering more-sophisticated routing systems. It is expected that other Routing technology YANG modules (e.g., VRRP, RIP, ISIS, or OSPF models) will augment the Core Routing base YANG module.
コアルーティング：[RFC8349]は、より洗練されたルーティングシステムをカバーする将来のデータモデル開発の基礎として意図されているコアルーティングYANGデータモデルを定義します。他のルーティング技術YANGモジュール（例えば、VRRP、RIP、ISIS、またはOSPFモデル）がコアルーティングベースYANGモジュールを拡張することが予想されます。
MPLS: [RFC8960] defines a base model for MPLS that serves as a base framework for configuring and managing an MPLS switching subsystem. It is expected that other MPLS technology YANG modules (e.g., MPLS LSP Static, LDP, or RSVP-TE models) will augment the MPLS base YANG module.
MPLS：[RFC8960] MPLSスイッチングサブシステムを構成および管理するための基本フレームワークとして機能するMPLSのベースモデルを定義します。他のMPLSテクノロジYANGモジュール（例えば、MPLS LSP静的、LDP、またはRSVP-TEモデル）がMPLSベースYANGモジュールを拡張することが予想されます。
BGP: [IDR-BGP-MODEL] defines a YANG module for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier, and content provider operational requirements.
BGP：[IDR-BGP-MODEL]データセンター、キャリア、およびコンテンツプロバイダの運用要件に基づく、プロトコル、ポリシー、および運用面を含むBGPを構成および管理するためのYANGモジュールを定義します。
Routing Policy: [RTGWG-POLICY] defines a YANG module for configuring and managing routing policies based on operational practice. The module provides a generic policy framework that can be augmented with protocol-specific policy configuration.
ルーティングポリシー：[rtgwg-policy]運用慣行に基づいてルーティングポリシーを設定および管理するためのYANGモジュールを定義します。このモジュールは、プロトコル固有のポリシー構成で増強できる一般的なポリシーフレームワークを提供します。
SR/SRv6: [SPRING-SR-YANG] defines a YANG module for segment routing configuration and operation.
SR / SRV6：[Spring-SR-YANG]セグメントルーティング構成と操作用のYANGモジュールを定義します。
BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a network protocol that is used for liveness detection of arbitrary paths between systems. [BFD-YANG] defines a YANG module that can be used to configure and manage BFD.
BFD：双方向転送検出（BFD）[RFC5880]は、システム間の任意の経路の活性検出に使用されるネットワークプロトコルです。[BFD-YANG] BFDの設定と管理に使用できるYANGモジュールを定義します。
Multicast: [PIM-YANG] defines a YANG module that can be used to configure and manage Protocol Independent Multicast (PIM) devices.
マルチキャスト：[PIM-YANG]プロトコル独立マルチキャスト（PIM）デバイスの設定と管理に使用できるYANGモジュールを定義します。
[RFC8652] defines a YANG module that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices.
[RFC8652]インターネットグループ管理プロトコル（IGMP）とマルチキャストリスナーディスカバリ（MLD）デバイスの設定と管理に使用できるYANGモジュールを定義します。
[SNOOPING-YANG] defines a YANG module that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping devices.
[Snooping-Yang]インターネットグループ管理プロトコル（IGMP）とマルチキャストリスナーディスカバリ（MLD）スヌーピングデバイスの設定と管理に使用できるYANGモジュールを定義します。
[MVPN-YANG] defines a YANG data model to configure and manage Multicast in MPLS/BGP IP VPNs (MVPNs).
[MVPN-YANG] MPLS / BGP IP VPN（MVPN）でマルチキャストを設定および管理するためのYANGデータモデルを定義します。
PM: [TWAMP-DATA-MODEL] defines a YANG data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP).
PM：[Twamp-Data-Model]双方向アクティブ測定プロトコル（TWAMP）のクライアントおよびサーバ実装のYANGデータモデルを定義します。
[STAMP-YANG] defines the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG.
[Stamp-Yang] Yangを使用した単純な双方向アクティブ測定プロトコル（スタンプ）モードのためのセッション送信者とセッションリフレクタの実装のためのデータモデルを定義します。
[RFC8194] defines a YANG data model for Large-Scale Measurement Platforms (LMAPs).
[RFC 8194]大規模測定プラットフォーム（ランプ）のYangデータモデルを定義します。
ACL: An Access Control List (ACL) is one of the basic elements used to configure device-forwarding behavior. It is used in many networking technologies such as Policy-Based Routing, firewalls, etc. [RFC8519] describes a YANG data model of ACL basic building blocks.
ACL：アクセス制御リスト（ACL）は、デバイス転送動作の設定に使用される基本要素の1つです。ポリシーベースのルーティング、ファイアウォールなどの多くのネットワークテクノロジで使用されています[RFC8519] ACLベーシックビルディングブロックのYANGデータモデルについて説明しています。
QoS: [QOS-MODEL] describes a YANG module of Differentiated Services for configuration and operations.
QoS：[QoS-Model]は、構成および操作のために微分サービスのYANGモジュールを説明しています。
NAT: For the sake of network automation and the need for programming the Network Address Translation (NAT) function in particular, a YANG data model for configuring and managing the NAT is essential.
NAT：ネットワーク自動化のため、およびネットワークアドレス変換（NAT）機能のプログラミングの必要性のために、特にNATを構成および管理するためのYANGデータモデルが不可欠です。
[RFC8512] defines a YANG module for the NAT function covering a variety of NAT flavors such as Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAMs) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT.
[RFC8512] IPv4からIPv4へのネットワークアドレス変換（NAT44）、IPv6クライアントからIPv4サーバーへのネットワークアドレス、およびプロトコル変換などのさまざまなNATフレーバーをカスタマイズしたNAT機能用のYANGモジュールを定義します。CLAT）、ステートレスIP / ICMP変換（SIIT）、SIIT、IPv6-to-IPv6ネットワークプレフィックス変換（NPTV6）、および宛先NATの明示的アドレスマッピング（EAMS）。
[RFC8513] specifies a Dual-Stack Lite (DS-Lite) YANG module.
[RFC8513]デュアルスタックライト（DS-Lite）YANGモジュールを指定します。
Stateless Address Sharing: [RFC8676] specifies a YANG module for Address plus Port (A+P) address sharing, including Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms.
ステートレスアドレス共有：[RFC8676]は、軽量4OVER6、カプセル化を伴うアドレスとポートのマッピング（MAP-E）、翻訳を使用したアドレスとポートのマッピングのマッピングなど、アドレスプラスポート（AP）アドレス共有のYANGモジュールを指定します。）ソフトワイヤー機構
Acknowledgements
謝辞
Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and Olivier Augizeau for the review.
Joe Clark、Greg Mirsky、Homma、Brian Carpenter、Adrian Farrel、Christian Huitema、Tommy Pouly、Ines Robles、およびレビューのためのオリヴィア・オガイゾーのおかげでください。
Many thanks to Robert Wilton for the detailed AD review.
詳細な広告レビューのためにRobert Wiltonに感謝します。
Thanks to Éric Vyncke, Roman Danyliw, Erik Kline, and Benjamin Kaduk for the IESG review.
IESGレビューのために、éricVyncke、Roman Danyliw、Erik Kline、Benjamin Kadukのおかげで。
Contributors
貢献者
Christian Jacquenet Orange Rennes, 35000 France
キリスト教のジャッカレネットオレンジレンヌ、35000フランス
Email: Christian.jacquenet@orange.com
Luis Miguel Contreras Murillo Telefonica
Luis Miguel Contreras Murillo Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Oscar Gonzalez de Dios Telefonica Madrid Spain
Oscar Gonzalez de Dios Telefonica Madridスペイン
Email: oscar.gonzalezdedios@telefonica.com
Weiqiang Cheng China Mobile
Weiqiang Cheng China Mobile.
Email: chengweiqiang@chinamobile.com
Young Lee Sung Kyun Kwan University
若いリーソンジュンクワン大学
Email: younglee.tx@gmail.com
Authors' Addresses
著者の住所
Qin Wu (editor) Huawei 101 Software Avenue Yuhua District Nanjing Jiangsu, 210012 China
Qin WU（編集）Huawei 101 Software Avenue Yuhua District Nanjing Jiangsu、210012中国
Email: bill.wu@huawei.com
Mohamed Boucadair (editor) Orange Rennes 35000 France
Mohamed Boucadair（編集）オレンジレンヌ35000フランス
Email: mohamed.boucadair@orange.com
Diego R. Lopez Telefonica I+D Spain
Diego R. Lopez Telefonica I Dスペイン
Email: diego.r.lopez@telefonica.com
Chongfeng Xie China Telecom Beijing China
Chongfeng Xie China Telecom Beijing China
Email: xiechf@chinatelecom.cn
Liang Geng China Mobile
Liang Geng China Mobile.
Email: gengliang@chinamobile.com