[要約] RFC 8530は、論理ネットワーク要素のYANGモデルに関する規格であり、ネットワーク要素の構成と管理を効率化するために設計されています。このRFCの目的は、ネットワーク要素の標準化された表現と相互運用性の向上を提供することです。
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 8530 C. Hopps
Category: Standards Track LabN Consulting, L.L.C.
ISSN: 2070-1721 A. Lindem
Cisco Systems
D. Bogdanovic
X. Liu
Volta Networks
March 2019
YANG Model for Logical Network Elements
論理ネットワーク要素のYANGモデル
Abstract
概要
This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture (NMDA). This module 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. The YANG model in this document conforms with NMDA as defined in RFC 8342.
このドキュメントでは、ネットワーク管理データストアアーキテクチャ（NMDA）に準拠する論理ネットワーク要素（LNE）YANGモジュールを定義します。このモジュールを使用して、ネットワークデバイスに存在する可能性のある論理リソースのパーティションを管理できます。論理リソースのパーティション分割に関する一般的な業界用語の例は、論理システムまたは論理ルーターです。このドキュメントのYANGモデルは、RFC 8342で定義されているNMDAに準拠しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8530.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8530で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Logical Network Elements . . . . . . . . . . . . . . . . . . 5
3.1. LNE Instantiation and Resource Assignment . . . . . . . . 6
3.2. LNE Management -- LNE View . . . . . . . . . . . . . . . 7
3.3. LNE Management -- Host Network Device View . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Logical Network Element Model . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
A.1. Example: Host-Device-Managed LNE . . . . . . . . . . . . 17
A.1.1. Configuration Data . . . . . . . . . . . . . . . . . 21
A.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 25
A.2. Example: Self-Managed LNE . . . . . . . . . . . . . . . . 33
A.2.1. Configuration Data . . . . . . . . . . . . . . . . . 36
A.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
This document defines an NMDA-compliant YANG module [RFC6020] to support the creation of logical network elements (LNEs) on a network device. An LNE is an independently managed virtual device made up of resources allocated to it from the host or parent network device. An LNE running on a host network device conceptually parallels a virtual machine running on a host system. Using host-virtualization terminology, one could refer to an LNE as a "Guest" and the containing network device as the "Host". While LNEs may be implemented via host-virtualization technologies, this is not a requirement. The YANG model in this document conforms with the Network Management Datastore Architecture defined in [RFC8342].
このドキュメントでは、NMDA準拠のYANGモジュール[RFC6020]を定義して、ネットワークデバイスでの論理ネットワーク要素（LNE）の作成をサポートしています。 LNEは、ホストまたは親ネットワークデバイスから割り当てられたリソースで構成される、独立して管理される仮想デバイスです。ホストネットワークデバイスで実行されているLNEは、概念的にはホストシステムで実行されている仮想マシンに対応しています。ホスト仮想化の用語を使用すると、LNEを「ゲスト」と呼び、包含ネットワークデバイスを「ホスト」と呼ぶことができます。 LNEはホスト仮想化テクノロジーを介して実装できますが、これは必須ではありません。このドキュメントのYANGモデルは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャに準拠しています。
This document also defines the necessary augmentations for allocating host resources to a given LNE. As the interface management model [RFC8343] is the only module that currently defines host resources, this document currently defines only a single augmentation to cover the assignment of interfaces to an LNE. Future modules that define support for the control of host device resources are expected to, where appropriate, provide parallel support for the assignment of controlled resources to LNEs.
このドキュメントでは、特定のLNEにホストリソースを割り当てるために必要な拡張も定義しています。インターフェイス管理モデル[RFC8343]は現在ホストリソースを定義している唯一のモジュールであるため、このドキュメントでは現在、LNEへのインターフェイスの割り当てをカバーする単一の拡張のみを定義しています。ホストデバイスリソースの制御のサポートを定義する将来のモジュールは、必要に応じて、LNEへの制御されたリソースの割り当ての並列サポートを提供することが期待されます。
As each LNE is an independently managed device, each will have its own set of YANG-modeled data that is independent of the host device and other LNEs. For example, multiple LNEs may all have their own "Tunnel0" interface defined, which will not conflict with each other and will not exist in the host's interface model. An LNE will have its own management interfaces, possibly including independent instances of NETCONF/RESTCONF/etc servers to support the configuration of their YANG models. As an example of this independence, an implementation may choose to completely rename assigned interfaces; so, on the host, the assigned interface might be called "Ethernet0/1" while within the LNE it might be called "eth1".
各LNEは独立して管理されるデバイスであるため、ホストデバイスや他のLNEから独立した独自のYANGモデルデータセットを持ちます。たとえば、複数のLNEにはすべて独自の「Tunnel0」インターフェイスが定義されている場合があります。これは互いに競合せず、ホストのインターフェイスモデルに存在しません。 LNEには独自の管理インターフェイスがあり、おそらくNETCONF / RESTCONF / etcサーバーの独立したインスタンスを含めて、YANGモデルの構成をサポートします。この独立性の例として、実装は割り当てられたインターフェースの名前を完全に変更することを選択できます。したがって、ホストでは、割り当てられたインターフェイスは「Ethernet0 / 1」と呼ばれ、LNE内では「eth1」と呼ばれる場合があります。
In addition to standard management interfaces, a host device implementation may support accessing LNE configuration and operational YANG models directly from the host system. When supported, such access is accomplished through a yang-schema-mount mount point [RFC8528] under which the root-level LNE YANG models may be accessed.
標準の管理インターフェイスに加えて、ホストデバイスの実装では、ホストシステムから直接LNE構成および運用YANGモデルにアクセスできます。サポートされている場合、このようなアクセスは、ルートレベルのLNE YANGモデルにアクセスできるyang-schema-mountマウントポイント[RFC8528]を介して行われます。
Examples of vendor terminology for an LNE include logical system or logical router and virtual switch, chassis, or fabric.
LNEのベンダー用語の例には、論理システムまたは論理ルーターおよび仮想スイッチ、シャーシ、またはファブリックが含まれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Readers are expected to be familiar with terms and concepts of YANG [RFC7950] and YANG Schema Mount [RFC8528].
読者は、YANG [RFC7950]とYANGスキーママウント[RFC8528]の用語と概念に精通している必要があります。
This document uses the graphical representation of data models defined in YANG Tree Diagrams [RFC8340].
このドキュメントでは、YANGツリー図[RFC8340]で定義されたデータモデルのグラフィカル表現を使用しています。
In this document, we consider network devices that support protocols and functions defined within the IETF Routing Area, e.g., routers, firewalls, and hosts. Such devices may be physical or virtual, e.g., a classic router with custom hardware or one residing within a server-based virtual machine implementing a virtual network function (VNF). Each device may subdivide their resources into LNEs, each of which provides a managed logical device. Examples of vendor terminology for an LNE include logical system or logical router and virtual switch, chassis, or fabric. Each LNE may also support VPN Routing and Forwarding (VRF) and Virtual Switching Instance (VSI) functions, which are referred to below as Network Instances (NIs). This breakdown is represented in Figure 1.
このドキュメントでは、ルーター、ファイアウォール、ホストなど、IETFルーティングエリア内で定義されたプロトコルと機能をサポートするネットワークデバイスについて検討します。そのようなデバイスは、物理的または仮想的である可能性があります。たとえば、カスタムハードウェアを備えたクラシックルーター、または仮想ネットワーク機能（VNF）を実装するサーバーベースの仮想マシン内にあるルーターなどです。各デバイスは、リソースをLNEに分割し、それぞれが管理対象の論理デバイスを提供します。 LNEのベンダー用語の例には、論理システムまたは論理ルーターおよび仮想スイッチ、シャーシ、またはファブリックが含まれます。各LNEは、VPNルーティングおよび転送（VRF）および仮想スイッチングインスタンス（VSI）機能もサポートします。これらは、以下ではネットワークインスタンス（NI）と呼ばれます。この内訳を図1に示します。
,'''''''''''''''''''''''''''''''''''''''''''''''.
| Network Device (Physical or Virtual) |
| ..................... ..................... |
| : Logical Network : : Logical Network : |
| : Element : : Element : |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| :| Net | Net | Net |: :| Net | Net | Net |: |
| :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: |
| :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | |
''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | |
Interfaces Interfaces
Figure 1: Module Element Relationships
図1：モジュール要素の関係
A model for LNEs is described in Section 3, and the model for NIs is covered in [RFC8529].
LNEのモデルはセクション3で説明されており、NIのモデルは[RFC8529]でカバーされています。
The interface management model [RFC8343] is an existing model that is impacted by the definition of LNEs and NIs. This document and [RFC8529] define augmentations to the interface model to support LNEs and NIs. Similar elements, although perhaps only for LNEs, may also need to be included as part of the definition of the future hardware and QoS modules.
インターフェース管理モデル[RFC8343]は、LNEとNIの定義の影響を受ける既存のモデルです。このドキュメントと[RFC8529]は、LNEとNIをサポートするためのインターフェースモデルの拡張を定義しています。同様の要素は、おそらくLNE専用ですが、将来のハードウェアおよびQoSモジュールの定義の一部として含める必要がある場合もあります。
Interfaces are a crucial part of any network device's configuration and operational state. They generally include a combination of raw physical interfaces, link-layer interfaces, addressing configuration, and logical interfaces that may not be tied to any physical interface. Several system services, and Layer 2 and Layer 3 protocols, may also associate configuration or operational state data with different types of interfaces (these relationships are not shown for simplicity). The interface management model is defined by [RFC8343]. The logical-network-element module augments existing interface management models by adding an identifier that is used on interfaces to identify an associated LNE.
インターフェイスは、ネットワークデバイスの構成と動作状態の重要な部分です。これらには通常、未加工の物理インターフェイス、リンク層インターフェイス、アドレス指定構成、および物理インターフェイスに関連付けられていない可能性のある論理インターフェイスの組み合わせが含まれます。いくつかのシステムサービス、およびレイヤ2およびレイヤ3プロトコルは、構成または動作状態データをさまざまなタイプのインターフェイスに関連付ける場合もあります（これらの関係は、簡略化のために示されていない）。インターフェース管理モデルは[RFC8343]によって定義されています。 logical-network-elementモジュールは、関連するLNEを識別するためにインターフェイスで使用される識別子を追加することにより、既存のインターフェイス管理モデルを強化します。
The interface-related augmentation is as follows:
インターフェース関連の拡張は次のとおりです。
module: ietf-logical-network-element
augment /if:interfaces/if:interface:
+--rw bind-lne-name? ->
/logical-network-elements/logical-network-element/name
The interface model defined in [RFC8343] is structured to include all interfaces in a flat list, without regard to logical assignment of resources supported on the device. The bind-lne-name and leaf provides the association between an interface and its associated LNE. Note that as currently defined, to assign an interface to both an LNE and NI, the interface would first be assigned to the LNE and then within that LNE's interface model, the LNE's representation of that interface would be assigned to an NI using the mechanisms defined in [RFC8529].
[RFC8343]で定義されているインターフェイスモデルは、デバイスでサポートされるリソースの論理割り当てに関係なく、すべてのインターフェイスをフラットリストに含めるように構成されています。 bind-lne-nameとリーフは、インターフェイスとそれに関連付けられたLNE間の関連付けを提供します。現在定義されているように、インターフェースをLNEとNIの両方に割り当てるには、まずインターフェースをLNEに割り当て、次にそのLNEのインターフェースモデル内で、定義されたメカニズムを使用してそのインターフェースのLNEの表現をNIに割り当てます。 [RFC8529]。
Logical network elements support the ability of some devices to partition resources into independent logical routers and/or switches. Device support for multiple logical network elements is implementation specific. Systems without such capabilities need not include support for the logical-network-element module. In physical devices, some hardware features are shared across partitions, but control-plane (e.g., routing) protocol instances, tables, and configuration are managed separately. For example, in logical routers or VNFs, this may correspond to establishing multiple logical instances using a single software installation. The model supports configuration of multiple instances on a single device by creating a list of logical network elements, each with their own configuration and operational state related to routing and switching protocols.
論理ネットワーク要素は、いくつかのデバイスがリソースを独立した論理ルーターやスイッチに分割する機能をサポートします。複数の論理ネットワーク要素のデバイスサポートは実装固有です。そのような機能のないシステムでは、logical-network-elementモジュールのサポートを含める必要はありません。物理デバイスでは、一部のハードウェア機能はパーティション間で共有されますが、コントロールプレーン（ルーティングなど）のプロトコルインスタンス、テーブル、および構成は個別に管理されます。たとえば、論理ルーターまたはVNFでは、これは単一のソフトウェアインストールを使用して複数の論理インスタンスを確立することに対応する場合があります。モデルは、それぞれが独自の構成とルーティングおよびスイッチングプロトコルに関連する動作状態を持つ論理ネットワーク要素のリストを作成することにより、単一のデバイス上の複数のインスタンスの構成をサポートします。
The LNE model can be represented as:
ONEモデルは次のように表すことができます。
module: ietf-logical-network-element
+--rw logical-network-elements
+--rw logical-network-element* [name]
+--rw name string
+--rw managed? boolean
+--rw description? string
+--mp root
augment /if:interfaces/if:interface:
+--rw bind-lne-name?
-> /logical-network-elements/logical-network-element/name
notifications:
+---n bind-lne-name-failed
+--ro name -> /if:interfaces/interface/name
+--ro bind-lne-name
| -> /if:interfaces/interface/lne:bind-lne-name
+--ro error-info? string
'name' identifies the logical network element. 'managed' indicates if the server providing the host network device will provide the client LNE information via the 'root' structure. The root of an LNE's specific data is the schema mount point 'root'. bind-lne-name is used to associate an interface with an LNE, and bind-lne-name-failed is used in certain failure cases.
「名前」は論理ネットワーク要素を識別します。 「managed」は、ホストネットワークデバイスを提供するサーバーが「root」構造を介してクライアントLNE情報を提供するかどうかを示します。 LNEの特定のデータのルートは、スキーママウントポイント「ルート」です。 bind-lne-nameはインターフェイスをLNEに関連付けるために使用され、bind-lne-name-failedは特定の失敗の場合に使用されます。
An LNE root MUST contain at least the YANG library [RFC7895] and interface module [RFC8343].
LNEルートには、少なくともYANGライブラリ[RFC7895]とインターフェイスモジュール[RFC8343]が含まれている必要があります。
Logical network elements may be controlled by clients using existing list operations. When list entries are created, a new LNE is instantiated. The models mounted under an LNE root are expected to be dependent on the server implementation. When a list entry is deleted, an existing LNE is destroyed. For more information, see [RFC7950], Section 7.8.6.
論理ネットワーク要素は、既存のリスト操作を使用してクライアントによって制御できます。リストエントリが作成されると、新しいLNEがインスタンス化されます。 LNEルートの下にマウントされたモデルは、サーバーの実装に依存すると予想されます。リストエントリが削除されると、既存のLNEは破棄されます。詳細については、[RFC7950]のセクション7.8.6を参照してください。
Once instantiated, host network device resources can be associated with the new LNE. As previously mentioned, this document augments ietf-interfaces with the bind-lne-name leaf to support such associations for interfaces. When a bind-lne-name is set to a valid LNE name, an implementation MUST take whatever steps are internally necessary to assign the interface to the LNE or provide an error message (defined below) with an indication of why the assignment failed. It is possible for the assignment to fail while processing the set, or after asynchronous processing. Error notification in the latter case is supported via a notification.
インスタンス化されると、ホストネットワークデバイスリソースを新しいLNEに関連付けることができます。前述のように、このドキュメントでは、ietf-interfacesにbind-lne-nameリーフを追加して、そのようなインターフェイスの関連付けをサポートしています。 bind-lne-nameが有効なLNE名に設定されている場合、実装はインターフェイスをLNEに割り当てるために内部で必要な手順を実行するか、割り当てが失敗した理由を示すエラーメッセージ（以下で定義）を提供する必要があります。セットの処理中、または非同期処理後に割り当てが失敗する可能性があります。後者の場合のエラー通知は、通知を介してサポートされます。
On a successful interface assignment to an LNE, an implementation MUST also make the resource available to the LNE by providing a system-created interface to the LNE. The name of the system-created interface is a local matter and may be identical or completely different and mapped from and to the name used in the context of the host device. The system-created interface SHOULD be exposed via the LNE-specific instance of the interface model [RFC8343].
LNEへのインターフェース割り当てが成功した場合、実装は、LNEへのシステム作成インターフェースを提供することにより、LNEがリソースを利用できるようにする必要もあります。システムで作成されたインターフェースの名前はローカルの問題であり、同一または完全に異なる可能性があり、ホストデバイスのコンテキストで使用される名前との間でマッピングされます。システムによって作成されたインターフェースは、インターフェースモデルのLNE固有のインスタンス[RFC8343]を介して公開する必要があります（SHOULD）。
Each LNE instance is expected to support management functions from within the context of the LNE root, via a server that provides information with the LNE's root exposed as the device root. Management functions operating within the context of an LNE are accessed through the LNE's standard management interfaces, e.g., NETCONF and SNMP. Initial configuration, much like the initial configuration of the host device, is a local implementation matter.
各LNEインスタンスは、LNEのルートがデバイスルートとして公開されている情報を提供するサーバーを介して、LNEルートのコンテキスト内から管理機能をサポートすることが期待されています。 LNEのコンテキスト内で動作する管理機能には、NETCONFやSNMPなどのLNEの標準管理インターフェースを介してアクセスします。ホストデバイスの初期構成と同様に、初期構成はローカル実装の問題です。
When accessing an LNE via the LNE's management interface, a network device representation will be presented, but its scope will be limited to the specific LNE. Normal YANG/NETCONF mechanisms, together with the required YANG library [RFC7895] instance, can be used to identify the available modules. Each supported module will be presented as a top-level module. Only LNE-associated resources will be reflected in resource-related modules, e.g., interfaces, hardware, and perhaps QoS. From the management perspective, there will be no difference between the available LNE view (information) and a physical network device.
LNEの管理インターフェイスを介してLNEにアクセスすると、ネットワークデバイスの表現が表示されますが、その範囲は特定のLNEに制限されます。通常のYANG / NETCONFメカニズムと、必要なYANGライブラリ[RFC7895]インスタンスを使用して、使用可能なモジュールを識別できます。サポートされている各モジュールは、最上位モジュールとして表示されます。 LNEに関連付けられたリソースのみが、リソース関連のモジュール（インターフェース、ハードウェア、おそらくQoSなど）に反映されます。管理の観点からは、利用可能なLNEビュー（情報）と物理ネットワークデバイスの間に違いはありません。
There are multiple implementation approaches possible to enable a network device to support the logical-network-element module and multiple LNEs. Some approaches will allow the management functions operating at the network device level to access LNE configuration and operational information, while others will not. Similarly, even when LNE management from the network device is supported by the implementation, it may be prohibited by user policy.
ネットワークデバイスがlogical-network-elementモジュールと複数のLNEをサポートできるようにするには、複数の実装方法があります。一部のアプローチでは、ネットワークデバイスレベルで動作する管理機能がLNEの設定と運用情報にアクセスできるようにしますが、そうでないものもあります。同様に、ネットワークデバイスからのLNE管理が実装によってサポートされている場合でも、ユーザーポリシーによって禁止されている場合があります。
Independent of the method selected by an implementation, the 'managed' boolean mentioned above is used to indicate when LNE management from the network device context is possible. When the 'managed' boolean is 'false', the LNE cannot be managed by the host system and can only be managed from within the context of the LNE as described in Section 3.2. Attempts to access information below a root node whose associated 'managed' boolean is set to 'false' MUST result in the error message indicated below. In some implementations, it may not be possible to change this value. For example, when an LNE is implemented using virtual machine and traditional hypervisor technologies, it is likely that this value will be restricted to a 'false' value.
実装によって選択された方法に関係なく、上記の「管理された」ブール値は、ネットワークデバイスコンテキストからのLNE管理が可能な場合を示すために使用されます。 「管理された」ブール値が「false」の場合、LNEはホストシステムで管理できず、セクション3.2で説明されているように、LNEのコンテキスト内からのみ管理できます。関連する「管理」ブール値が「false」に設定されているルートノードの下の情報にアクセスしようとすると、以下に示すエラーメッセージが発生する必要があります。一部の実装では、この値を変更できない場合があります。たとえば、仮想マシンと従来のハイパーバイザーテクノロジーを使用してLNEが実装されている場合、この値は「false」の値に制限される可能性があります。
It is an implementation choice if the information can be accessed and modified from within the context of the LNE, or even the context of the host device. When the 'managed' boolean is 'true', LNE information SHALL be accessible from the context of the host device. When the associated schema-mount definition has the 'config' leaf set to 'true', then LNE information SHALL also be modifiable from the context of the host device. When LNE information is available from both the host device and from within the context of the LNE, the same information MUST be made available via the 'root' element, with paths modified as described in [RFC8528].
LNEのコンテキスト内から、またはホストデバイスのコンテキスト内からでも情報にアクセスして変更できる場合、これは実装の選択です。 「管理された」ブール値が「true」の場合、LNE情報はホストデバイスのコンテキストからアクセス可能である必要があります。関連するスキーママウント定義の「config」リーフが「true」に設定されている場合、LNE情報もホストデバイスのコンテキストから変更可能である必要があります。ホストデバイスとLNEのコンテキストの両方からLNE情報が利用可能な場合、[RFC8528]で説明されているようにパスを変更して、同じ情報を「ルート」要素を介して利用可能にする必要があります。
An implementation MAY represent an LNE's schema using either the 'inline' or the 'shared-schema' approaches defined in [RFC8528]. The choice of which to use is completely an implementation choice. The inline approach is anticipated to be generally used in the cases where the 'managed' boolean will always be 'false'. The 'shared-schema' approach is expected to be most useful in the case where all LNEs share the same schema. When 'shared-schema' is used with an LNE mount point, the YANG library rooted in the LNE's mount point MUST match the associated schema defined according to the ietf-yang-schema-mount module.
[RFC8528]で定義されている「インライン」または「共有スキーマ」アプローチのいずれかを使用して、実装はLNEのスキーマを表す場合があります。どちらを使用するかの選択は、完全に実装の選択です。インラインアプローチは、「管理された」ブール値が常に「false」になる場合に一般的に使用されると予想されます。 「共有スキーマ」アプローチは、すべてのLNEが同じスキーマを共有する場合に最も有用であると予想されます。 「共有スキーマ」をLNEマウントポイントで使用する場合、LNEのマウントポイントをルートとするYANGライブラリは、ietf-yang-schema-mountモジュールに従って定義された関連スキーマと一致する必要があります。
Beyond the two modules that will always be present for an LNE, as an LNE is a network device itself, all modules that may be present at the top-level network device MAY also be present for the LNE. The list of available modules is expected to be implementation dependent, as is the method used by an implementation to support LNEs. Appendix A provides example uses of LNEs.
LNEはネットワークデバイス自体であるため、LNEに常に存在する2つのモジュールを超えて、最上位のネットワークデバイスに存在する可能性のあるすべてのモジュールがLNEにも存在する場合があります。利用可能なモジュールのリストは、LNEをサポートするために実装によって使用される方法と同様に、実装に依存することが予想されます。付録Aでは、LNEの使用例を示します。
The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されているYANGモジュールは、NETCONF [RFC6241]やRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義します。最下位のNETCONFレイヤーはセキュアなトランスポートレイヤーであり、実装に必須のセキュアなトランスポートはセキュアシェル（SSH）です[RFC6242]。最下位のRESTCONFレイヤーはHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC8446]です。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、特定のNETCONFまたはRESTCONFユーザーのアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
LNE information represents device and network configuration information. As such, the security of this information is important, but it is fundamentally no different than any other interface or device configuration information that has already been covered in other documents such as [RFC8343], [RFC7317], and [RFC8349].
LNE情報は、デバイスとネットワークの構成情報を表します。したがって、この情報のセキュリティは重要ですが、[RFC8343]、[RFC7317]、[RFC8349]などの他のドキュメントですでにカバーされている他のインターフェイスまたはデバイス構成情報と基本的に違いはありません。
The vulnerable "config true" parameters and subtrees are the following:
脆弱な「config true」パラメータとサブツリーは次のとおりです。
/logical-network-elements/logical-network-element: This list specifies the logical network element and the related logical device configuration.
/ logical-network-elements / logical-network-element：このリストは、論理ネットワーク要素と関連する論理デバイス構成を指定します。
/logical-network-elements/logical-network-element/managed: While this leaf is contained in the previous list, it is worth particular attention as it controls whether information under the LNE mount point is accessible by both the host device and within the LNE context. There may be extra sensitivity to this leaf in environments where an LNE is managed by a different party than the host device, and that party does not wish to share LNE information with the operator of the host device.
/ logical-network-elements / logical-network-element / managed：このリーフは前のリストに含まれていますが、LNEマウントポイントの下の情報にホストデバイスと内部の両方からアクセスできるかどうかを制御するため、特に注意する必要がありますLNEコンテキスト。 LNEがホストデバイスとは異なる関係者によって管理されており、その関係者がLNE情報をホストデバイスのオペレーターと共有することを望まない環境では、このリーフに対する特別な機密性がある場合があります。
/if:interfaces/if:interface/bind-lne-name: This leaf indicates the LNE instance to which an interface is assigned. Implementations should pay particular attention to when changes to this leaf are permitted as removal of an interface from an LNE can have a major impact on the LNE's operation as it is similar to physically removing an interface from the device. Implementations can reject a reassignment using the previously described error message generation.
/ if：interfaces / if：interface / bind-lne-name：このリーフは、インターフェースが割り当てられているLNEインスタンスを示します。 LNEからのインターフェースの削除は、デバイスからインターフェースを物理的に削除するのと同様に、LNEの動作に大きな影響を与える可能性があるため、実装ではこのリーフへの変更が許可されるタイミングに特に注意する必要があります。実装では、前述のエラーメッセージ生成を使用して再割り当てを拒否できます。
Unauthorized access to any of these lists can adversely affect the security of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems.
これらのリストへの不正アクセスは、ローカルデバイスとネットワークの両方のセキュリティに悪影響を及ぼす可能性があります。これにより、ネットワークの誤動作、不適切な宛先へのパケットの配信、その他の問題が発生する可能性があります。
This document registers a URI in the "IETF XML Registry" [RFC3688].
このドキュメントは、「IETF XMLレジストリ」[RFC3688]にURIを登録します。
URI: urn:ietf:params:xml:ns:yang:ietf-logical-network-element Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-logical-network-element登録者の連絡先：IESG。 XML：N / A、要求されたURIはXML名前空間です。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]にYANGモジュールを登録しています。
name: ietf-logical-network-element
namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element
prefix: lne
reference: RFC 8530
The structure of the model defined in this document is described by the YANG module below.
このドキュメントで定義されているモデルの構造は、以下のYANGモジュールで説明されています。
<CODE BEGINS> file "ietf-logical-network-element@2019-01-25.yang"
module ietf-logical-network-element {
yang-version 1.1;
// namespace
//名前空間
namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element";
prefix lne;
// import some basic types
//いくつかの基本タイプをインポートします
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
import ietf-yang-schema-mount {
prefix yangmnt;
reference
"RFC 8528: YANG Schema Mount";
}
organization
"IETF Routing Area (rtgwg) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/rtgwg/>
WG List: <mailto:rtgwg@ietf.org>
Author: Lou Berger
<mailto:lberger@labn.net>
Author: Christian Hopps
<mailto:chopps@chopps.org>
Author: Acee Lindem
<mailto:acee@cisco.com>
Author: Dean Bogdanovic <mailto:ivandean@gmail.com>"; description "This module is used to support multiple logical network elements on a single physical or virtual system.
著者：Dean Bogdanovic <mailto：ivandean@gmail.com> ";説明"このモジュールは、単一の物理システムまたは仮想システムで複数の論理ネットワーク要素をサポートするために使用されます。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2019 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETF文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8530; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 8530の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2019-01-25 {
description
"Initial revision.";
reference
"RFC 8530: YANG Model for Logical Network Elements";
}
// top level device definition statements
//トップレベルのデバイス定義ステートメント
container logical-network-elements {
description
"Allows a network device to support multiple logical
network element (device) instances.";
list logical-network-element {
key "name";
description
"List of logical network elements.";
leaf name {
type string;
description
"Device-wide unique identifier for the
logical network element.";
}
leaf managed {
type boolean;
default "true";
description
"True if the host can access LNE information
using the root mount point. This value
may not be modifiable in all implementations.";
}
leaf description {
type string;
description
"Description of the logical network element.";
}
container root {
description
"Container for mount point.";
yangmnt:mount-point "root" {
description
"Root for models supported per logical
network element. This mount point may or may not
be inline based on the server implementation. It
SHALL always contain a YANG library and interfaces
instance.
When the associated 'managed' leaf is 'false', any
operation that attempts to access information below
the root SHALL fail with an error-tag of
'access-denied' and an error-app-tag of
'lne-not-managed'.";
}
}
}
}
// augment statements
//ステートメントを拡張します
augment "/if:interfaces/if:interface" {
description
"Add a node for the identification of the logical network
element associated with an interface. Applies to interfaces that can be assigned per logical network element.
インターフェースに関連付けられた要素。論理ネットワーク要素ごとに割り当てることができるインターフェイスに適用されます。
Note that a standard error will be returned if the
identified leafref isn't present. If an interface
cannot be assigned for any other reason, the operation
SHALL fail with an error-tag of 'operation-failed' and an
error-app-tag of 'lne-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-lne-name {
type leafref {
path "/logical-network-elements/logical-network-element/name";
}
description
"Logical network element ID to which the interface is
bound.";
}
}
// notification statements
//通知ステートメント
notification bind-lne-name-failed {
description
"Indicates an error in the association of an interface to an
LNE. Only generated after success is initially returned
when bind-lne-name is set.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Contains the interface name associated with the
failure.";
}
leaf bind-lne-name {
type leafref {
path "/if:interfaces/if:interface/lne:bind-lne-name";
}
mandatory true;
description
"Contains the bind-lne-name associated with the
failure.";
}
leaf error-info {
type string;
description
"Optionally, indicates the source of the assignment
failure.";
}
}
}
<CODE ENDS>
<コード終了>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-editor。 org / info / rfc6020>。
[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] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（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。、「Using the NETCONF Protocol over Secure Shell（SSH）」、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[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プロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341] Bierman、A。およびM. Bjorklund、「Network Configuration Access Control Model」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https://www.rfc-editor.org/info/rfc8341 >。
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K。、およびR. Wilton、「Network Management Datastore Architecture（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。、「A YANG Data Model for Interface Management」、RFC 8343、DOI 10.17487 / RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[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。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[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. Lhotka、「YANG Schema Mount」、RFC 8528、DOI 10.17487 / RFC8528、2019年3月、<https://www.rfc-editor.org/info/rfc8528>。
[DEVICE-MODEL] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, "Network Device YANG Logical Organization", Work in Progress, draft-ietf-rtgwg-device-model-02, March 2017.
[デバイスモデル]リンデムA.、バーガーL.、ボグダノビッチD.、C。ホップス、「ネットワークデバイスYANG論理編成」、作業中、draft-ietf-rtgwg-device-model-02、3月2017。
[OSPF-YANG] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for OSPF Protocol", Work in Progress, draft-ietf-ospf-yang-21, January 2019.
[OSPF-YANG] Yeung、D.、Qu、Y.、Zhang、Z.、Chen、I。、およびA. Lindem、「OSPFプロトコルのYANGデータモデル」、Work in Progress、draft-ietf-ospf-yang 2019年1月21日。
[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> 。
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, <https://www.rfc-editor.org/info/rfc7895>.
[RFC7895] Bierman、A.、Bjorklund、M。、およびK. Watsen、「YANG Module Library」、RFC 7895、DOI 10.17487 / RFC7895、2016年6月、<https://www.rfc-editor.org/info/ rfc7895>。
[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。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund、M。およびL. Berger、編、「YANG Tree Diagrams」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https://www.rfc-editor.org/info/ rfc8340>。
[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、「A Hardware Data Model for Hardware Management」、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、L.、Lindem、A。、およびY. Qu、「ルーティング管理用のYANGデータモデル（NMDAバージョン）」、RFC 8349、DOI 10.17487 / RFC8349、2018年3月、<https：// www。 rfc-editor.org/info/rfc8349>。
[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、「ネットワークインスタンスのYANGデータモデル」、RFC 8529、DOI 10.17487 / RFC8529、2019年3月、<https ：//www.rfc-editor.org/info/rfc8529>。
The following subsections provide example uses of LNEs.
以下のサブセクションでは、LINEの使用例を示します。
This section describes an example of the LNE model using schema mount to achieve the parent management. An example device supports multiple instances of LNEs (logical routers), each of which supports features of Layer 2 and Layer 3 interfaces [RFC8343], a routing information base [RFC8349], and the OSPF protocol [OSPF-YANG]. Each of these features is specified by a YANG model, and they are combined using the YANG schema mount as shown below. Not all possible mounted modules are shown. For example, implementations could also mount the model defined in [RFC8348].
このセクションでは、スキーママウントを使用して親管理を実現するLNEモデルの例について説明します。サンプルデバイスは、LNE（論理ルーター）の複数のインスタンスをサポートします。各インスタンスは、レイヤー2およびレイヤー3インターフェイス[RFC8343]、ルーティング情報ベース[RFC8349]、およびOSPFプロトコル[OSPF-YANG]の機能をサポートします。これらの各機能はYANGモデルで指定されており、次に示すように、YANGスキーママウントを使用して結合されます。取り付け可能なすべてのモジュールが示されているわけではありません。たとえば、実装は[RFC8348]で定義されたモデルをマウントすることもできます。
module: ietf-logical-network-element
+--rw logical-network-elements
+--rw logical-network-element* [name]
+--rw name string
+--mp root
+--ro yanglib:modules-state/
| +--ro module-set-id string
| +--ro module* [name revision]
| +--ro name yang:yang-identifier
+--rw sys:system/
| +--rw contact? string
| +--rw hostname? inet:domain-name
| +--rw authentication {authentication}?
| +--rw user-authentication-order* identityref
| +--rw user* [name] {local-users}?
| +--rw name string
| +--rw password? ianach:crypt-hash
| +--rw authorized-key* [name]
| +--rw name string
| +--rw algorithm string
| +--rw key-data binary
+--ro sys:system-state/
| ...
+--rw rt:routing/
| +--rw router-id? yang:dotted-quad
| +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf/
| +--rw areas
| +--rw area* [area-id]
| +--rw interfaces
| +--rw interface* [name]
| +--rw name if:interface-ref
| +--rw cost? uint16
+--rw if:interfaces/
+--rw interface* [name]
+--rw name string
+--rw ip:ipv4!/
| +--rw address* [ip]
| ...
module: ietf-interfaces
+--rw interfaces
+--rw interface* [name]
+--rw name string
+--rw lne:bind-lne-name? string
+--ro oper-status enumeration
module: ietf-yang-library
+--ro modules-state
+--ro module-set-id string
+--ro module* [name revision]
+--ro name yang:yang-identifier
module: ietf-system
+--rw system
| +--rw contact? string
| +--rw hostname? inet:domain-name
| +--rw authentication {authentication}?
| +--rw user-authentication-order* identityref
| +--rw user* [name] {local-users}?
| +--rw name string
| +--rw password? ianach:crypt-hash
| +--rw authorized-key* [name]
| +--rw name string
| +--rw algorithm string
| +--rw key-data binary
+--ro system-state
+--ro platform
| +--ro os-name? string
| +--ro os-release? string
To realize the above schema, the example device implements the following schema mount instance:
上記のスキーマを実現するために、サンプルデバイスは次のスキーママウントインスタンスを実装しています。
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-logical-network-element",
"label": "root",
"shared-schema": {}
}
]
}
By using the implementation of the YANG schema mount, an operator can
create instances of logical routers. An interface can be assigned to
a logical router, so that the logical router has the permission to
access this interface. The OSPF protocol can then be enabled on this
assigned interface.
For this implementation, a parent management session has access to the schemas of both the parent hosting system and the child logical routers. In addition, each child logical router can grant its own management sessions, which have the following schema:
この実装では、親管理セッションは、親ホスティングシステムと子論理ルーターの両方のスキーマにアクセスできます。さらに、各子論理ルーターは、次のスキーマを持つ独自の管理セッションを許可できます。
module: ietf-yang-library
+--ro modules-state
+--ro module-set-id string
+--ro module* [name revision]
+--ro name yang:yang-identifier
module: ietf-system
+--rw system
| +--rw contact? string
| +--rw hostname? inet:domain-name
| +--rw authentication {authentication}?
| +--rw user-authentication-order* identityref
| +--rw user* [name] {local-users}?
| +--rw name string
| +--rw password? ianach:crypt-hash
| +--rw authorized-key* [name]
| +--rw name string
| +--rw algorithm string
| +--rw key-data binary
+--ro system-state
+--ro platform
+--ro os-name? string
+--ro os-release? string
module: ietf-routing
rw-- routing
+--rw router-id? yang:dotted-quad
+--rw control-plane-protocols
+--rw control-plane-protocol* [type name]
+--rw ospf:ospf/
+--rw areas
+--rw area* [area-id]
+--rw interfaces
+--rw interface* [name]
+--rw name if:interface-ref
+--rw cost? uint16
module: ietf-interfaces
+--rw interfaces
+--rw interface* [name]
+--rw name string
+--ro oper-status enumeration
The following shows an example where two customer-specific LNEs are configured:
次に、2つの顧客固有のLNEが設定されている例を示します。
{
"ietf-logical-network-element:logical-network-elements": {
"logical-network-element": [
{
"name": "cust1",
"root": {
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
}
}
},
{
"name": "cust2",
"root": {
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
}
}
]
}
}
}
]
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "cust1:eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-logical-network-element:bind-lne-name": "cust1"
},
{
"name": "cust2:eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-logical-network-element:bind-lne-name": "cust2"
}
]
},
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "root",
"password": "$0$password"
}
]
}
}
}
The following shows possible state data associated with the above configuration data:
以下は、上記の構成データに関連付けられた可能な状態データを示しています。
{
"ietf-logical-network-element:logical-network-elements": {
"logical-network-element": [
{
"name": "cust1",
"root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
}
}
},
{
"name": "cust2",
"root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
}
}
]
}
}
}
]
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "cust1:eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-logical-network-element:bind-lne-name": "cust1"
},
{
"name": "cust2:eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-logical-network-element:bind-lne-name": "cust2"
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-logical-network-element",
"revision": "2017-03-13",
"feature": [
"bind-lne-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2017-05-16",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-logical-network-element",
"label": "root",
"shared-schema": {}
}
]
}
}
This section describes an example of the LNE model using schema mount to achieve child-independent management. An example device supports multiple instances of LNEs (logical routers), each of which has the features of Layer 2 and Layer 3 interfaces [RFC8343], a routing information base [RFC8349], and the OSPF protocol. Each of these features is specified by a YANG model, and they are put together by the YANG schema mount as follows:
このセクションでは、スキーママウントを使用して子に依存しない管理を実現するLNEモデルの例について説明します。サンプルデバイスは、LNE（論理ルーター）の複数のインスタンスをサポートします。各インスタンスには、レイヤー2およびレイヤー3インターフェイス[RFC8343]、ルーティング情報ベース[RFC8349]、およびOSPFプロトコルの機能があります。これらの機能はそれぞれYANGモデルで指定されており、YANGスキーママウントによって次のようにまとめられます。
module: ietf-logical-network-element
+--rw logical-network-elements
+--rw logical-network-element* [name]
+--rw name string
+--mp root
// The internal modules of the LNE are not visible to
// the parent management.
// The child manages its modules, including ietf-routing
// and ietf-interfaces
module: ietf-interfaces
+--rw interfaces
+--rw interface* [name]
+--rw name string
+--rw lne:bind-lne-name? string
+--ro oper-status enumeration
module: ietf-yang-library
+--ro modules-state
+--ro module-set-id string
+--ro module* [name revision]
+--ro name yang:yang-identifier
module: ietf-system
+--rw system
| +--rw contact? string
| +--rw hostname? inet:domain-name
| +--rw authentication {authentication}?
| +--rw user-authentication-order* identityref
| +--rw user* [name] {local-users}?
| +--rw name string
| +--rw password? ianach:crypt-hash
| +--rw authorized-key* [name]
| +--rw name string
| +--rw algorithm string
| +--rw key-data binary
+--ro system-state
+--ro platform
| +--ro os-name? string
| +--ro os-release? string
To realize the above schema, the device implements the following schema mount instance:
上記のスキーマを実現するために、デバイスは次のスキーママウントインスタンスを実装します。
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-logical-network-element",
"label": "root",
"inline": {}
}
]
}
By using the implementation of the YANG schema mount, an operator can create instances of logical routers, each with their logical router-specific inline modules. An interface can be assigned to a logical router, so that the logical router has the permission to access this interface. The OSPF protocol can then be enabled on this assigned interface. Each logical router independently manages its own set of modules, which may or may not be the same as other logical routers. The following is an example of schema set implemented on one particular logical router:
オペレーターは、YANGスキーママウントの実装を使用して、論理ルーター固有のインラインモジュールを持つ論理ルーターのインスタンスを作成できます。インターフェースを論理ルーターに割り当てることができるため、論理ルーターはこのインターフェースにアクセスする権限を持ちます。次に、この割り当てられたインターフェイスでOSPFプロトコルを有効にできます。各論理ルーターは、独自のモジュールセットを個別に管理します。モジュールのセットは、他の論理ルーターと同じであってもなくてもかまいません。以下は、特定の1つの論理ルーターに実装されたスキーマセットの例です。
module: ietf-yang-library
+--ro modules-state
+--ro module-set-id string
+--ro module* [name revision]
+--ro name yang:yang-identifier
module: ietf-system
+--rw system
| +--rw contact? string
| +--rw hostname? inet:domain-name
| +--rw authentication {authentication}?
| +--rw user-authentication-order* identityref
| +--rw user* [name] {local-users}?
| +--rw name string
| +--rw password? ianach:crypt-hash
| +--rw authorized-key* [name]
| +--rw name string
| +--rw algorithm string
| +--rw key-data binary
+--ro system-state
+--ro platform
| +--ro os-name? string
| +--ro os-release? string
module: ietf-routing
+--rw routing
+--rw router-id? yang:dotted-quad
+--rw control-plane-protocols
+--rw control-plane-protocol* [type name]
+--rw ospf:ospf/
+--rw areas
+--rw area* [area-id]
+--rw interfaces
+--rw interface* [name]
+--rw name if:interface-ref
+--rw cost? uint16
module: ietf-interfaces
+--rw interfaces
+--rw interface* [name]
+--rw name string
+--ro oper-status enumeration
Each of the child virtual routers is managed through its own sessions and configuration data.
子仮想ルーターはそれぞれ、独自のセッションと構成データを通じて管理されます。
The following shows an example of configuration data for the LNE name "vnf1":
次に、LNE名「vnf1」の構成データの例を示します。
{
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
}
}
]
}
}
The following shows an example of configuration data for the LNE name "vnf2":
LNE名「vnf2」の構成データの例を以下に示します。
{
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
}
}
]
}
}
The following sections show possible state data associated with the above configuration data. Note that there are three views: the host device's view and each of the LNE's views.
以下のセクションでは、上記の構成データに関連付けられた可能な状態データを示します。ホストデバイスのビューと各LNEのビューの3つのビューがあることに注意してください。
The following shows state data for the device hosting the example LNEs:
以下は、サンプルLINEをホストするデバイスの状態データを示しています。
{
"ietf-logical-network-element:logical-network-elements": {
"logical-network-element": [
{
"name": "vnf1",
"root": {
}
},
{
"name": "vnf2",
"root": {
}
}
]
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
}
},
{
"name": "vnf1:eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-logical-network-element:bind-lne-name": "vnf1"
},
{
"name": "vnf2:eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-logical-network-element:bind-lne-name": "vnf2"
}
] },
」 ｝、
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-logical-network-element",
"revision": "2017-03-13",
"feature": [
"bind-lne-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2017-05-16",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-logical-network-element",
"label": "root",
"inline": {}
}
]
}
}
The following shows state data for the example LNE with the name "vnf1":
以下に、「vnf1」という名前のサンプルLNEの状態データを示します。
{
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
}
}
]
}
}
The following shows state data for the example LNE with the name "vnf2":
次に、「vnf2」という名前のサンプルLNEの状態データを示します。
{
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
}
}
]
}
}
Acknowledgments
謝辞
The Routing Area Yang Architecture design team members included Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review comments were also received by Martin Bjorklund, John Scudder, Dan Romascanu, and Taylor Yu.
ルーティングエリアのヤンアーキテクチャデザインチームメンバーには、Acee Lindem、Anees Shaikh、Christian Hopps、Dean Bogdanovic、Lou Berger、Qin Wu、Rob Shakir、Stephane Litkowski、Yan Gangが含まれています。有用なレビューコメントは、Martin Bjorklund、John Scudder、Dan Romascanu、Taylor Yuも受け取りました。
This document was motivated by, and derived from "Network Device YANG Logical Organization" [DEVICE-MODEL].
このドキュメントは「Network Device YANG Logical Organization」[DEVICE-MODEL]によって動機付けられ、作成されました。
Thanks to Alvaro Retana for the IESG review.
IESGレビューを提供してくれたAlvaro Retanaに感謝します。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C.
Lou Berger LabNコンサルティング、L.L.C。
Email: lberger@labn.net
Christian Hopps LabN Consulting, L.L.C.
クリスチャンホップスLabNコンサルティング、L.L.C。
Email: chopps@chopps.org
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States of America
Acee Lindem Cisco Systems 301 Midenhall Way Cary、NC 27513アメリカ合衆国
Email: acee@cisco.com
Dean Bogdanovic Volta Networks
Dean Bogdanovic Volta Networks
Email: ivandean@gmail.com
Xufeng Liu Volta Networks
X U Feng L IU Voltaネットワーク
Email: xufeng.liu.ietf@gmail.com