[要約] RFC 8529は、ネットワークインスタンスのYANGデータモデルに関する規格であり、ネットワーク機器の設定や管理を効率化するための標準化を目的としています。
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 8529 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 Data Model for Network Instances
ネットワークインスタンスのYANGデータモデル
Abstract
概要
This document 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 VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).
このドキュメントでは、ネットワークインスタンスモジュールを定義します。このモジュールを使用して、ネットワークデバイスに存在する可能性のある仮想リソースのパーティションを管理できます。仮想リソース分割の一般的な業界用語の例は、VPNルーティングおよび転送（VRF）インスタンスおよび仮想スイッチインスタンス（VSI）です。
The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
このドキュメントの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/rfc8529.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8529で入手できます。
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. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6
3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 7
3.1.1. Well-Known Mount Points . . . . . . . . . . . . . . . 8
3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 9
3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
3.3. Network Instance Management . . . . . . . . . . . . . . . 11
3.4. Network Instance Instantiation . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Example NI Usage . . . . . . . . . . . . . . . . . . 25
A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 25
A.2. State Data - Non-NMDA Version . . . . . . . . . . . . . . 28
A.3. State Data - NMDA Version . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
This document defines the second of two new modules that are defined to support the configuration and operation of network devices that allow for the partitioning of resources from both, or either, management and networking perspectives. Both leverage the YANG functionality enabled by YANG Schema Mount [RFC8528].
このドキュメントでは、管理とネットワークの両方またはいずれかの観点からリソースを分割できるようにするネットワークデバイスの構成と操作をサポートするために定義された2つの新しいモジュールの2番目を定義します。どちらも、YANGスキーママウント[RFC8528]によって有効になるYANG機能を利用します。
The YANG data model in this document conforms to the Network Management Datastore Architecture defined in [RFC8342].
このドキュメントのYANGデータモデルは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャに準拠しています。
The first form of resource partitioning provides a logical partitioning of a network device where each partition is separately managed as essentially an independent network element that is "hosted" by the base network device. These hosted network elements are referred to as logical network elements, or LNEs, and are supported by the logical-network-element module defined in [RFC8530]. That module is used to identify LNEs and associate resources from the network device with each LNE. LNEs themselves are represented in YANG as independent network devices; each is accessed independently. Examples of vendor terminology for an LNE include logical system or logical router and virtual switch, chassis, or fabric.
リソースパーティションの最初の形式は、ネットワークデバイスの論理パーティションを提供します。各パーティションは、基本ネットワークデバイスによって「ホストされる」本質的に独立したネットワーク要素として個別に管理されます。これらのホストされたネットワーク要素は、論理ネットワーク要素、またはLNEと呼ばれ、[RFC8530]で定義されているlogical-network-elementモジュールでサポートされています。そのモジュールは、LNEを識別し、ネットワークデバイスからのリソースを各LNEに関連付けるために使用されます。 LNE自体は、YANGでは独立したネットワークデバイスとして表されます。それぞれが独立してアクセスされます。 LNEのベンダー用語の例には、論理システムまたは論理ルーターおよび仮想スイッチ、シャーシ、またはファブリックが含まれます。
The second form, which is defined in this document, provides support for what are commonly referred to as VPN Routing and Forwarding (VRF) instances as well as Virtual Switch Instances (VSI); see [RFC4026] and [RFC4664]. In this form of resource partitioning, multiple control-plane and forwarding/bridging instances are provided by and managed through a single (physical or logical) network device. This form of resource partitioning is referred to as a Network Instance (NI) and is supported by the network instance module defined below. Configuration and operation of each network instance is always via the network device and the network instance module.
このドキュメントで定義されている2番目の形式は、一般にVPNルーティングおよび転送（VRF）インスタンスと仮想スイッチインスタンス（VSI）と呼ばれるものをサポートします。 [RFC4026]と[RFC4664]を参照してください。このリソース分割の形式では、複数のコントロールプレーンと転送/ブリッジングのインスタンスが、単一の（物理または論理）ネットワークデバイスによって提供および管理されます。この形式のリソース分割は、ネットワークインスタンス（NI）と呼ばれ、以下で定義されるネットワークインスタンスモジュールによってサポートされます。各ネットワークインスタンスの構成と操作は、常にネットワークデバイスとネットワークインスタンスモジュールを介して行われます。
One notable difference between the LNE model and the NI model is that the NI model provides a framework for VRF and VSI management. This document envisions the separate definition of models specific to VRF and VSI -- i.e., L3 and L2 VPN -- technology. An example of such can be found in the emerging L3VPN model defined in [YANG-L3VPN] and the examples discussed below.
LNEモデルとNIモデルの注目すべき違いの1つは、NIモデルがVRFおよびVSI管理のフレームワークを提供することです。このドキュメントでは、VRFとVSIに固有のモデル（L3およびL2 VPN）テクノロジーの個別の定義を想定しています。そのような例は、[YANG-L3VPN]で定義された新しいL3VPNモデルと、以下で説明する例にあります。
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 [RFC8340].
このドキュメントは、[RFC8340]で定義されたデータモデルのグラフィック表現を使用します。
In this document, we consider network devices that support protocols and functions defined within the IETF -- 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 logical network elements (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 VRF and VSI functions, which are referred to below as network instances (NIs). This breakdown is represented in Figure 1.
このドキュメントでは、ルーター、ファイアウォール、ホストなど、IETF内で定義されたプロトコルと機能をサポートするネットワークデバイスについて検討します。そのようなデバイスは、物理的または仮想的である可能性があります。たとえば、カスタムハードウェアを備えたクラシックルーター、または仮想ネットワーク機能（VNF）を実装するサーバーベースの仮想マシン内にあるルーターなどです。各デバイスは、リソースを論理ネットワーク要素（LNE）に分割し、それぞれが管理された論理デバイスを提供します。 LNEのベンダー用語の例には、論理システムまたは論理ルーターおよび仮想スイッチ、シャーシ、またはファブリックが含まれます。各LNEは、以下ではネットワークインスタンス（NI）と呼ばれるVRFおよびVSI機能もサポートします。この内訳を図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 [RFC8530], and the model for NIs is covered in Section 3 of this document.
LNEのモデルは[RFC8530]で説明されており、NIのモデルはこのドキュメントのセクション3で説明されています。
The current interface management model [RFC8343] is impacted by the definition of LNEs and NIs. This document and [RFC8530] define augmentations to the interface module to support LNEs and NIs.
現在のインターフェース管理モデル[RFC8343]は、LNEとNIの定義に影響されます。このドキュメントと[RFC8530]は、LNEとNIをサポートするためのインターフェースモジュールの拡張を定義しています。
The network instance model supports the configuration of VRFs and VSIs. Each instance is supported by information that relates to the device -- for example, the route target used when advertising VRF routes via the mechanisms defined in [RFC4364], and information that relates to the internal operation of the NI, such as for routing protocols [RFC8349] and OSPF [YANG-OSPF]. This document defines the network instance module that provides a basis for the management of both types of information.
ネットワークインスタンスモデルは、VRFとVSIの設定をサポートしています。各インスタンスは、[RFC4364]で定義されたメカニズムを介してVRFルートをアドバタイズするときに使用されるルートターゲットなど、デバイスに関連する情報と、ルーティングプロトコルなど、NIの内部操作に関連する情報によってサポートされます[RFC8349]およびOSPF [YANG-OSPF]。このドキュメントでは、両方のタイプの情報を管理するための基礎を提供するネットワークインスタンスモジュールを定義します。
NI information that relates to the device, including the assignment of interfaces to NIs, is defined as part of this document. The defined module also provides a placeholder for the definition of NI-technology-specific information both at the device level and for NI internal operation. Information related to NI internal operation is supported via schema mount [RFC8528] and mounting appropriate modules under the mount point. Well-known mount points are defined for L3VPN, L2VPN, and L2+L3VPN NI types.
NIへのインターフェースの割り当てを含む、デバイスに関連するNI情報は、このドキュメントの一部として定義されています。定義されたモジュールは、デバイスレベルとNI内部操作の両方でNIテクノロジー固有の情報を定義するためのプレースホルダーも提供します。 NIの内部操作に関連する情報は、スキーママウント[RFC8528]を介してサポートされ、マウントポイントの下に適切なモジュールをマウントします。 L3VPN、L2VPN、およびL2 + L3VPN NIタイプには、既知のマウントポイントが定義されています。
The network instance container is used to represent VRFs and VSIs. VRFs and VSIs are commonly used to isolate routing and switching domains -- for example, to create virtual private networks, each with their own active protocols and routing/switching policies. The model supports both core/provider and virtual instances. Core/provider instance information is accessible at the top level of the server, while virtual instance information is accessible under the root schema mount points.
ネットワークインスタンスコンテナは、VRFとVSIを表すために使用されます。 VRFとVSIは、ルーティングドメインとスイッチングドメインを分離するために一般的に使用されます。たとえば、それぞれ独自のアクティブなプロトコルとルーティング/スイッチングポリシーを持つ仮想プライベートネットワークを作成します。モデルはコア/プロバイダーと仮想インスタンスの両方をサポートします。コア/プロバイダーインスタンス情報にはサーバーのトップレベルでアクセスでき、仮想インスタンス情報にはルートスキーママウントポイントの下でアクセスできます。
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
+--rw (root-type)
+--:(vrf-root)
| +--mp vrf-root
+--:(vsi-root)
| +--mp vsi-root
+--:(vv-root)
+--mp vv-root
augment /if:interfaces/if:interface:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-ni-name? -> /network-instances/network-instance/name
notifications:
+---n bind-ni-name-failed
+--ro name -> /if:interfaces/interface/name
+--ro interface
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ni:bind-ni-name
+--ro ipv4
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name
+--ro ipv6
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name
+--ro error-info? string
A network instance is identified by a "name" string. This string is used both as an index within the network instance module and to associate resources with a network instance, as shown above in the interface augmentation. The ni-type and root-type choice statements are used to support different types of L2 and L3 VPN technologies. The bind-ni-name-failed notification is used in certain failure cases.
ネットワークインスタンスは、「名前」文字列によって識別されます。この文字列は、ネットワークインターフェイスモジュール内のインデックスとしても、リソースをネットワークインスタンスに関連付けるためにも使用されます。 ni-typeおよびroot-type選択ステートメントは、さまざまなタイプのL2およびL3 VPNテクノロジーをサポートするために使用されます。 bind-ni-name-failed通知は、特定の失敗の場合に使用されます。
The network instance module is structured to facilitate the definition of information models for specific types of VRFs and VSIs using augmentations. For example, the information needed to support L2VPN, such as VPLS and EVPN, are likely to be quite different. Example models under development that could be restructured to take advantage on NIs include models for L3VPNs [YANG-L3VPN] and L2VPNs [YANG-L2VPN].
ネットワークインスタンスモジュールは、拡張を使用して特定のタイプのVRFおよびVSIの情報モデルの定義を容易にするように構造化されています。たとえば、VPLSやEVPNなどのL2VPNをサポートするために必要な情報は、かなり異なる可能性があります。 NIで利用できるように再構築できる開発中のサンプルモデルには、L3VPN [YANG-L3VPN]およびL2VPN [YANG-L2VPN]のモデルが含まれます。
Documents defining new YANG data models for the support of specific types of network instances should augment the network instance module. The basic structure that should be used for such augmentations includes a case statement with containers for configuration and state data and, when needed, a type-specific mount point. Generally, NI types are expected to not need to define type-specific mount points but rather reuse one of the well-known mount points, as defined in the next section. The following is an example type-specific augmentation:
特定のタイプのネットワークインスタンスをサポートするための新しいYANGデータモデルを定義するドキュメントは、ネットワークインスタンスモジュールを補強する必要があります。このような拡張に使用する必要のある基本的な構造には、構成および状態データのコンテナーを含むcaseステートメントと、必要に応じて、タイプ固有のマウントポイントが含まれます。一般に、NIタイプでは、タイプ固有のマウントポイントを定義する必要はなく、次のセクションで定義するように、既知のマウントポイントの1つを再利用する必要があります。次に、タイプ固有の拡張の例を示します。
augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn {
container l3vpn {
...
}
container l3vpn-state {
...
}
}
}
YANG Schema Mount [RFC8528] identifies mount points by name within a module. This definition allows for the definition of mount points whose schema can be shared across NI types. As discussed above, ni-types largely differ in the configuration information needed in the core/top-level instance to support the NI, rather than in the information represented within an NI. This allows the use of shared mount points across certain NI types.
YANGスキーママウント[RFC8528]は、モジュール内の名前でマウントポイントを識別します。この定義により、NIタイプ間でスキーマを共有できるマウントポイントを定義できます。上記で説明したように、niタイプは、NI内で表される情報ではなく、NIをサポートするためにコア/トップレベルインスタンスで必要な構成情報が大きく異なります。これにより、特定のNIタイプで共有マウントポイントを使用できます。
The expectation is that there are actually very few different schemas that need to be defined to support NIs for an implementation. In particular, it is expected that the following three forms of NI schema are needed, and each can be defined with a well-known mount point that can be reused by future modules defining NI types.
実装のためにNIをサポートするために定義する必要があるスキーマは実際には非常に少ないと予想されます。特に、次の3つの形式のNIスキーマが必要であり、それぞれが既知のマウントポイントで定義され、NIタイプを定義する将来のモジュールで再利用できます。
The three well-known mount points are:
よく知られている3つのマウントポイントは次のとおりです。
vrf-root vrf-root is intended for use with L3VPN-type NI types.
vrf-root vrf-rootは、L3VPNタイプのNIタイプで使用するためのものです。
vsi-root vsi-root is intended for use with L2VPN-type Ni types.
vsi-root vsi-rootは、L2VPNタイプのNiタイプで使用するためのものです。
vv-root vv-root is intended for use with NI types that simultaneously support L2VPN bridging and L3VPN routing capabilities.
vv-root vv-rootは、L2VPNブリッジングとL3VPNルーティング機能を同時にサポートするNIタイプでの使用を目的としています。
Future model definitions should use the above mount points whenever possible. When a well-known mount point isn't appropriate, a model may define a type-specific mount point via augmentation.
今後のモデル定義では、可能な場合は常に上記のマウントポイントを使用する必要があります。既知のマウントポイントが適切でない場合、モデルは、拡張によってタイプ固有のマウントポイントを定義する場合があります。
The following is an example of an L3VPN VRF using a hypothetical augmentation to the network instance schema defined in [YANG-L3VPN]. More detailed examples can be found in Appendix A.
以下は、[YANG-L3VPN]で定義されたネットワークインスタンススキーマに架空の拡張を使用したL3VPN VRFの例です。より詳細な例は付録Aにあります。
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
| +--:(l3vpn)
| +--rw l3vpn:l3vpn
| | ... // config data
| +--ro l3vpn:l3vpn-state
| | ... // state data
+--rw (root-type)
+--:(vrf-root)
+--mp vrf-root
+--rw rt:routing/
| +--rw router-id? yang:dotted-quad
| +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf
| +--rw area* [area-id]
| +--rw interfaces
| +--rw interface* [name]
| +--rw name if:interface-ref
| +--rw cost? uint16
+--ro if:interfaces@
| ...
This shows YANG Routing Management [RFC8349] and YANG OSPF [YANG-OSPF] as mounted modules. The mounted modules can reference interface information via a parent-reference to the containers defined in [RFC8343].
これは、マウントされたモジュールとしてのYANGルーティング管理[RFC8349]とYANG OSPF [YANG-OSPF]を示しています。マウントされたモジュールは、[RFC8343]で定義されたコンテナへの親参照を介してインターフェース情報を参照できます。
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].
インターフェイスは、ネットワークデバイスの構成と動作状態の重要な部分です。これらには通常、未加工の物理インターフェイス、リンク層インターフェイス、アドレス指定構成、および物理インターフェイスに関連付けられていない可能性のある論理インターフェイスの組み合わせが含まれます。いくつかのシステムサービスとレイヤ2およびレイヤ3プロトコルは、構成または動作状態データをさまざまなタイプのインターフェイスに関連付ける場合もあります（これらの関係は簡略化のために示されていない）。インターフェース管理モデルは[RFC8343]によって定義されています。
As shown below, the network instance module augments the existing interface management model by adding a name that is used on interface or sub-interface types to identify an associated network instance. Similarly, this name is also added for IPv4 and IPv6 types, as defined in [RFC8344].
以下に示すように、ネットワークインスタンスモジュールは、関連するネットワークインスタンスを識別するためにインターフェイスまたはサブインターフェイスタイプで使用される名前を追加することにより、既存のインターフェイス管理モデルを拡張します。同様に、この名前は、[RFC8344]で定義されているように、IPv4およびIPv6タイプにも追加されます。
The following is an example of envisioned usage. The interfaces container includes a number of commonly used components as examples:
以下は想定される使用例です。インターフェースコンテナには、一般的に使用されるいくつかのコンポーネントが例として含まれています。
module: ietf-interfaces
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw ip:ipv4!
| | +--rw ip:enabled? boolean
| | +--rw ip:forwarding? boolean
| | +--rw ip:mtu? uint16
| | +--rw ip:address* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw (ip:subnet)
| | | +--:(ip:prefix-length)
| | | | +--rw ip:prefix-length? uint8
| | | +--:(ip:netmask)
| | | +--rw ip:netmask? yang:dotted-quad
| | +--rw ip:neighbor* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw ip:link-layer-address yang:phys-address
| | +--rw ni:bind-network-instance-name? string
| +--rw ni:bind-network-instance-name? string
The "ietf-interfaces" module [RFC8343] is structured to include all interfaces in a flat list, without regard to virtual instances (e.g., VRFs) supported on the device. The bind-network-instance-name leaf provides the association between an interface and its associated NI (e.g., VRF or VSI). Note that as currently defined, to assign an interface to both an LNE and an NI, the interface would first be assigned to the LNE using the mechanisms defined in [RFC8530] and then, within that LNE's interface module, the LNE's representation of that interface would be assigned to an NI.
「ietf-interfaces」モジュール[RFC8343]は、デバイスでサポートされる仮想インスタンス（VRFなど）に関係なく、フラットリストにすべてのインターフェースを含めるように構成されています。 bind-network-instance-nameリーフは、インターフェースとそれに関連付けられたNI（VRFやVSIなど）の間の関連付けを提供します。現在定義されているように、LNEとNIの両方にインターフェイスを割り当てるには、[RFC8530]で定義されているメカニズムを使用してインターフェイスを最初にLNEに割り当て、そのLNEのインターフェイスモジュール内で、そのインターフェイスのLNEの表現をNIに割り当てられます。
Modules that may be used to represent network instance information will be available under the "root" mount point specific to the ni-type. The "shared-schema" method defined in the "ietf-yang-schema-mount" module [RFC8528] MUST be used to identify accessible modules. A future version of this document could relax this requirement. Mounted modules SHOULD be defined with access, via the appropriate schema mount parent-references [RFC8528], to device resources such as interfaces. An implementation MAY choose to restrict parent-referenced information to information related to a specific instance. For example, it might only allow references to interfaces that have a "bind-network-instance-name" that is identical to the instance's "name".
ネットワークインスタンス情報を表すために使用できるモジュールは、niタイプに固有の「ルート」マウントポイントで使用できます。 「ietf-yang-schema-mount」モジュール[RFC8528]で定義された「共有スキーマ」メソッドは、アクセス可能なモジュールを識別するために使用されなければなりません。このドキュメントの将来のバージョンでは、この要件を緩和する可能性があります。マウントされたモジュールは、適切なスキーママウントの親参照[RFC8528]を介して、インターフェースなどのデバイスリソースにアクセスできるように定義する必要があります（SHOULD）。実装は、親参照情報を特定のインスタンスに関連する情報に制限することを選択できます。たとえば、インスタンスの「名前」と同じ「bind-network-instance-name」を持つインターフェースへの参照のみを許可する場合があります。
All modules that represent control-plane and data-plane information may be present at the "root" mount point and accessible via paths modified per [RFC8528]. The list of available modules is expected to be implementation dependent, as is the method used by an implementation to support NIs.
コントロールプレーンとデータプレーンの情報を表すすべてのモジュールは、「ルート」マウントポイントに存在し、[RFC8528]に従って変更されたパスを介してアクセスできます。使用可能なモジュールのリストは、NIをサポートするために実装で使用される方法と同様に、実装に依存すると予想されます。
For example, the following could be used to define the data organization of the example NI shown in Section 3.1.2:
たとえば、以下を使用して、セクション3.1.2に示すサンプルNIのデータ構成を定義できます。
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
Module data identified according to the ietf-yang-schema-mount module will be instantiated under the mount point identified under "mount-point". These modules will be able to reference information for nodes belonging to top-level modules that are identified under "parent-reference". Parent-referenced information is available to clients via their top-level paths only and not under the associated mount point.
ietf-yang-schema-mountモジュールに従って識別されたモジュールデータは、「mount-point」で識別されたマウントポイントの下にインスタンス化されます。これらのモジュールは、「親参照」で識別される最上位モジュールに属するノードの情報を参照できます。親参照情報は、関連するマウントポイントの下ではなく、トップレベルパスのみを介してクライアントが利用できます。
To allow a client to understand the previously mentioned instance restrictions on parent-referenced information, an implementation MAY represent such restrictions in the "parent-reference" leaf-list. For example:
クライアントが前述の親参照情報に関するインスタンスの制限を理解できるように、実装はそのような制限を「親参照」リーフリストで表すことができます。例えば：
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]"
]
}
}
],
The same such "parent-reference" restrictions for non-NMDA implementations can be represented based on [RFC8343] and [RFC8344] as:
非NMDA実装に対する同じような「親参照」制限は、[RFC8343]および[RFC8344]に基づいて次のように表すことができます。
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface
[if:name = /if:interfaces/if:interface
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv4
[if:name = /if:interfaces/if:interface/ip:ipv4
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv6
[if:name = /if:interfaces/if:interface/ip:ipv6
[ni:bind-ni-name = current()/../ni:name]/if:name]"
]
}
}
],
Network instances may be controlled by clients using existing list operations. When a list entry is created, a new instance is instantiated. The models mounted under an NI root are expected to be dependent on the server implementation. When a list entry is deleted, an existing network instance is destroyed. For more information, see Section 7.8.6 of [RFC7950].
ネットワークインスタンスは、既存のリスト操作を使用してクライアントによって制御される場合があります。リストエントリが作成されると、新しいインスタンスがインスタンス化されます。 NIルートの下にマウントされたモデルは、サーバーの実装に依存すると予想されます。リストエントリが削除されると、既存のネットワークインスタンスは破棄されます。詳細については、[RFC7950]のセクション7.8.6を参照してください。
Once instantiated, host network device resources can be associated with the new NI. As previously mentioned, this document augments ietf-interfaces with the bind-ni-name leaf to support such associations for interfaces. When a bind-ni-name is set to a valid NI name, an implementation MUST take whatever steps are internally necessary to assign the interface to the NI 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 operation or after asynchronous processing. Error notification in the latter case is supported via a notification.
インスタンス化されると、ホストネットワークデバイスリソースを新しいNIに関連付けることができます。前述したように、このドキュメントでは、ietf-interfacesにbind-ni-nameリーフを追加して、そのようなインターフェイスの関連付けをサポートしています。 bind-ni-nameが有効なNI名に設定されている場合、実装はインターフェイスをNIに割り当てるために内部的に必要な手順を実行するか、割り当てが失敗した理由を示すエラーメッセージ（以下で定義）を提供する必要があります。セット操作の処理中または非同期処理の後で、割り当てが失敗する可能性があります。後者の場合のエラー通知は、通知を介してサポートされます。
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プロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
There are two different sets of security considerations to consider in the context of this document. One set is security related to information contained within mounted modules. The security considerations for mounted modules are not substantively changed based on the information being accessible within the context of an NI. For example, when considering the modules defined in [RFC8349], the security considerations identified in that document are equally applicable, whether those modules are accessed at a server's root or under an NI instance's root node.
このドキュメントのコンテキストで考慮すべきセキュリティの考慮事項の2つの異なるセットがあります。 1つのセットは、マウントされたモジュールに含まれる情報に関連するセキュリティです。取り付けられたモジュールのセキュリティに関する考慮事項は、NIのコンテキスト内でアクセス可能な情報に基づいて実質的に変更されることはありません。たとえば、[RFC8349]で定義されたモジュールを検討する場合、それらのモジュールがサーバーのルートでアクセスされるか、NIインスタンスのルートノードの下でアクセスされるかにかかわらず、そのドキュメントで識別されるセキュリティの考慮事項は等しく適用されます。
The second area for consideration is information contained in the NI module itself. NI information represents network configuration and route distribution policy information. As such, the security of this information is important, but it is fundamentally no different than any other interface or routing configuration information that has already been covered in [RFC8343] and [RFC8349].
考慮すべき2番目の領域は、NIモジュール自体に含まれる情報です。 NI情報は、ネットワーク構成とルート配布ポリシー情報を表します。そのため、この情報のセキュリティは重要ですが、[RFC8343]と[RFC8349]ですでにカバーされている他のインターフェイスまたはルーティング構成情報と基本的に違いはありません。
The vulnerable "config true" parameters and subtrees are the following:
脆弱な「config true」パラメータとサブツリーは次のとおりです。
/network-instances/network-instance: This list specifies the network instances and the related control plane protocols configured on a device.
/ network-instances / network-instance：このリストは、デバイスに構成されているネットワークインスタンスと関連するコントロールプレーンプロトコルを指定します。
/if:interfaces/if:interface/*/bind-network-instance-name: This leaf indicates the NI instance to which an interface is assigned.
/ if：interfaces / if：interface / * / bind-network-instance-name：このリーフは、インターフェースが割り当てられているNIインスタンスを示します。
Unauthorized access to any of these lists can adversely affect the routing subsystem 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-network-instance
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
XML：N / A、要求されたURIはXML名前空間です。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]にYANGモジュールを登録しています。
name: ietf-network-instance
namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
prefix: ni
reference: RFC 8529
The structure of the model defined in this document is described by the YANG module below.
このドキュメントで定義されているモデルの構造は、以下のYANGモジュールで説明されています。
<CODE BEGINS> file "ietf-network-instance@2019-01-21.yang"
module ietf-network-instance {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";
prefix ni;
// import some basic types
//いくつかの基本タイプをインポートします
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
import ietf-ip {
prefix ip;
reference
"RFC 8344: A YANG Data Model for IP 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 network instances within a single physical or virtual device. Network instances are commonly known as VRFs (VPN Routing and Forwarding) and VSIs (Virtual Switching Instances).
作成者：Lou Berger <mailto：lberger@labn.net>作成者：Christian Hopps <mailto：chopps@chopps.org>作成者：Acee Lindem <mailto：acee@cisco.com>作成者：Dean Bogdanovic <mailto：ivandean @ gmail。 com> ";説明"このモジュールは、単一の物理デバイスまたは仮想デバイス内の複数のネットワークインスタンスをサポートするために使用されます。ネットワークインスタンスは、一般的にVRF（VPNルーティングおよび転送）およびVSI（仮想スイッチングインスタンス）として知られています。
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの 'は、ここに示すように、BCP 14（RFC 2119）（RFC 8174）で説明されているように解釈されます。
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 (https://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETF文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8529; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 8529の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2019-01-21 {
description
"Initial revision.";
reference
"RFC 8529";
}
// top-level device definition statements
//トップレベルのデバイス定義ステートメント
container network-instances {
description
"Network instances, each of which consists of
VRFs and/or VSIs.";
reference
"RFC 8349: A YANG Data Model for Routing Management";
list network-instance {
key "name";
description
"List of network instances.";
leaf name {
type string;
mandatory true;
description
"device-scoped identifier for the network
instance.";
}
leaf enabled {
type boolean;
default "true";
description
"Flag indicating whether or not the network
instance is enabled.";
}
leaf description {
type string;
description
"Description of the network instance
and its intended purpose.";
}
choice ni-type {
description
"This node serves as an anchor point for different types
of network instances. Each 'case' is expected to
differ in terms of the information needed in the
parent/core to support the NI and may differ in their
mounted-schema definition. When the mounted schema is
not expected to be the same for a specific type of NI,
a mount point should be defined.";
}
choice root-type {
mandatory true;
description
"Well-known mount points.";
container vrf-root {
description
"Container for mount point.";
yangmnt:mount-point "vrf-root" {
description
"Root for L3VPN-type models. This will typically
not be an inline-type mount point.";
}
}
container vsi-root {
description
"Container for mount point.";
yangmnt:mount-point "vsi-root" {
description
"Root for L2VPN-type models. This will typically
not be an inline-type mount point.";
}
}
container vv-root {
description
"Container for mount point.";
yangmnt:mount-point "vv-root" {
description
"Root models that support both L2VPN-type bridging
and L3VPN-type routing. This will typically
not be an inline-type mount point.";
}
}
}
}
}
// augment statements
//ステートメントを拡張します
augment "/if:interfaces/if:interface" { description "Add a node for the identification of the network instance associated with the information configured on a interface.
「/ if：interfaces / if：interface」を拡張します{description "インターフェースに構成された情報に関連付けられたネットワークインスタンスを識別するためのノードを追加します。
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 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which an interface is bound.";
}
}
augment "/if:interfaces/if:interface/ip:ipv4" {
description
"Add a node for the identification of the network
instance associated with the information configured
on an IPv4 interface.
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 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which IPv4 interface is bound.";
}
}
augment "/if:interfaces/if:interface/ip:ipv6" {
description
"Add a node for the identification of the network
instance associated with the information configured
on an IPv6 interface.
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 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description
"Network instance to which IPv6 interface is bound.";
}
}
// notification statements
//通知ステートメント
notification bind-ni-name-failed { description "Indicates an error in the association of an interface to an NI. Only generated after success is initially returned when bind-ni-name is set.
notification bind-ni-name-failed {description "NIへのインターフェースの関連付けにエラーがあることを示します。bind-ni-nameが設定されている場合、最初に成功した後にのみ生成されます。
Note: Some errors may need to be reported for multiple associations, e.g., a single error may need to be reported for an IPv4 and an IPv6 bind-ni-name.
注：複数の関連付けについていくつかのエラーを報告する必要がある場合があります。たとえば、IPv4とIPv6のbind-ni-nameについて単一のエラーを報告する必要がある場合があります。
At least one container with a bind-ni-name leaf MUST be
included in this notification.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Contains the interface name associated with the
failure.";
}
container interface {
description
"Generic interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface"
+ "/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv4 {
description
"IPv4 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv4/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv6 {
description
"IPv6 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ip:ipv6"
+ "/ni:bind-ni-name";
}
description
"Contains the bind-ni-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>。
[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>。
[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>。
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.
[RFC8344] Bjorklund、M。、「IP管理用のYANGデータモデル」、RFC 8344、DOI 10.17487 / RFC8344、2018年3月、<https://www.rfc-editor.org/info/rfc8344>。
[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>。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4026] Andersson、L。およびT. Madsen、「Provider Provisioned Virtual Private Network（VPN）Terminology」、RFC 4026、DOI 10.17487 / RFC4026、2005年3月、<https://www.rfc-editor.org/info/ rfc4026>。
[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 Virtual Private Networks（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。、エド。 E.ローゼン編、「レイヤー2仮想プライベートネットワーク（L2VPNs）のフレームワーク」、RFC 4664、DOI 10.17487 / RFC4664、2006年9月、<https://www.rfc-editor.org/info/rfc4664>。
[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>。
[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>。
[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.
[RFC8530] Berger、L.、Hopps、C.、Lindem、A.、Bogdanovic、D。、およびX. Liu、「YANG Model for Logical Network Elements」、RFC 8530、DOI 10.17487 / RFC8530、March 2019。
[YANG-L2VPN] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-09, October 2018.
[YANG-L2VPN] Shah、H.、Brissette、P.、Chen、I.、Hussain、I.、Wen、B。、およびK. Tiruveedhula、「MPLSベースのL2VPNのYANGデータモデル」、Work in Progress、 draft-ietf-bess-l2vpn-yang-09、2018年10月。
[YANG-L3VPN] 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, draft-ietf-bess-l3vpn-yang-04, October 2018.
[YANG-L3VPN] Jain、D.、Patel、K.、Brissette、P.、Li、Z.、Zhuang、S.、Liu、X.、Haas、J.、Esale、S.、B。Wen、 「BGP / MPLS L3 VPNのヤンデータモデル」、作業中、draft-ietf-bess-l3vpn-yang-04、2018年10月。
[YANG-NETWORK] 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.
[YANG-NETWORK] Lindem、A.、Berger、L.、Bogdanovic、D。、およびC. Hopps、「Network Device YANG Logical Organization」、Work in Progress、draft-ietf-rtgwg-device-model-02、3月2017。
[YANG-OSPF] 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.
[YANG-OSPF] Yeung、D.、Qu、Y.、Zhang、Z.、Chen、I。、およびA. Lindem、「OSPFプロトコルのYANGデータモデル」、Work in Progress、draft-ietf-ospf-yang 2019年1月21日。
The following subsections provide example uses of NIs.
以下のサブセクションでは、NIの使用例を示します。
The following shows an example where two customer-specific network instances are configured:
以下は、2つの顧客固有のネットワークインスタンスが構成されている例を示しています。
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"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
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"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": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"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": "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
}
]
},
"ietf-network-instance:bind-network-instance-name": "vrf-red"
},
{
"name": "eth2",
"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
}
]
}, "ietf-network-instance:bind-network-instance-name": "vrf-blue" } ] },
}、 "ietf-network-instance：bind-network-instance-name"： "vrf-blue"}]}、
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
}
}
The following shows state data for the configuration example above based on [RFC8343], [RFC8344], and [RFC8349].
以下は、[RFC8343]、[RFC8344]、および[RFC8349]に基づく上記の構成例の状態データを示しています。
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"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"
}
]
},
"ietf-routing:routing-state": {
"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
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"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"
}
]
},
"ietf-routing:routing-state": {
"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": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
｝、
"ietf-interfaces:interfaces-state": {
"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": "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": "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-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
},
"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": "2018-07-03",
"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": "2018-02-20",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"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": "2019-01-04",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"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-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
}
The following shows state data for the configuration example above based on [RFC8343], [RFC8344], and [RFC8349].
以下は、[RFC8343]、[RFC8344]、および[RFC8349]に基づく上記の構成例の状態データを示しています。
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-yang-library:yang-library": {
"content-id": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"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
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-yang-library:yang-library": {
"checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"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"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"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": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"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": "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": "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-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
},
｝、
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-yang-library:yang-library": {
"content-id": "75a43df9bd56b92aacc156a2958fbe12312fb285",
"module-set": [
{
"name": "host-modules",
"module": [
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
}
],
"import-only-module": [
{
"name": "iana-if-type",
"revision": "2018-07-03",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "host-schema",
"module-set": [ "host-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "host-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "host-schema"
}
]
},
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
}
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. Martin Bjorklund and John Scudder provided useful review comments.
ルーティングエリアのヤンアーキテクチャデザインチームメンバーには、Acee Lindem、Anees Shaikh、Christian Hopps、Dean Bogdanovic、Lou Berger、Qin Wu、Rob Shakir、Stephane Litkowski、Yan Gangが含まれています。 Martin BjorklundとJohn Scudderは、有用なレビューコメントを提供しました。
This document was motivated by, and derived from, "Network Device YANG Logical Organization" [YANG-NETWORK].
このドキュメントは、「ネットワークデバイスYANG論理編成」[YANG-NETWORK]に基づいて作成されました。
Thanks for Area Director and IETF last-call comments from Alia Atlas, Liang Xia, Benoit Claise, and Adam Roach.
Alia Atlas、Liang Xia、Benoit Claise、Adam RoachからのエリアディレクターとIETFの最後のコメントに感謝します。
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