[要約] RFC 8345は、ネットワークトポロジーのためのYANGデータモデルを提供するものであり、ネットワークトポロジーの表現と操作を標準化することを目的としています。
Internet Engineering Task Force (IETF) A. Clemm
Request for Comments: 8345 Huawei
Category: Standards Track J. Medved
ISSN: 2070-1721 Cisco
R. Varga
Pantheon Technologies SRO
N. Bahadur
Bracket Computing
H. Ananthakrishnan
Packet Design
X. Liu
Jabil
March 2018
A YANG Data Model for Network Topologies
ネットワークトポロジのYANGデータモデル
Abstract
概要
This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.
このドキュメントでは、ネットワーク/サービストポロジーとインベントリーの抽象（汎用、または基本）YANGデータモデルを定義します。データモデルは、他のより具体的なトポロジおよびインベントリデータモデルのテクノロジー固有の詳細で拡張される基本モデルとして機能します。
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/rfc8345.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8345で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 ....................................................4
2. Key Words .......................................................8
3. Definitions and Abbreviations ...................................9
4. Model Structure Details .........................................9
4.1. Base Network Model .........................................9
4.2. Base Network Topology Data Model ..........................12
4.3. Extending the Data Model ..................................13
4.4. Discussion and Selected Design Decisions ..................14
4.4.1. Container Structure ................................14
4.4.2. Underlay Hierarchies and Mappings ..................14
4.4.3. Dealing with Changes in Underlay Networks ..........15
4.4.4. Use of Groupings ...................................15
4.4.5. Cardinality and Directionality of Links ............16
4.4.6. Multihoming and Link Aggregation ...................16
4.4.7. Mapping Redundancy .................................16
4.4.8. Typing .............................................17
4.4.9. Representing the Same Device in Multiple Networks ..17
4.4.10. Supporting Client-Configured and
System-Controlled Network Topologies ..............18
4.4.11. Identifiers of String or URI Type .................19
5. Interactions with Other YANG Modules ...........................19
6. YANG Modules ...................................................20
6.1. Defining the Abstract Network: ietf-network ...............20
6.2. Creating Abstract Network Topology:
ietf-network-topology .....................................25
7. IANA Considerations ............................................32
8. Security Considerations ........................................33
9. References .....................................................35
9.1. Normative References ......................................35
9.2. Informative References ....................................36
Appendix A. Model Use Cases .......................................38
A.1. Fetching Topology from a Network Element ...................38
A.2. Modifying TE Topology Imported from an Optical Controller ..38
A.3. Annotating Topology for Local Computation ..................39
A.4. SDN Controller-Based Configuration of Overlays on Top of
Underlays ..................................................39
Appendix B. Companion YANG Data Models for Implementations Not
Compliant with NMDA ...................................39
B.1. YANG Module for Network State ..............................40
B.2. YANG Module for Network Topology State .....................45
Appendix C. An Example ............................................52
Acknowledgments ...................................................56
Contributors ......................................................56
Authors' Addresses ................................................57
This document introduces an abstract (base) YANG [RFC7950] data model [RFC3444] to represent networks and topologies. The data model is divided into two parts: The first part of the data model defines a network data model that enables the definition of network hierarchies, or network stacks (i.e., networks that are layered on top of each other) and maintenance of an inventory of nodes contained in a network. The second part of the data model augments the basic network data model with information to describe topology information. Specifically, it adds the concepts of "links" and "termination points" to describe how nodes in a network are connected to each other. Moreover, the data model introduces vertical layering relationships between networks that can be augmented to cover both network inventories and network/service topologies.
このドキュメントでは、ネットワークとトポロジを表すための抽象（ベース）YANG [RFC7950]データモデル[RFC3444]を紹介します。データモデルは2つの部分に分かれています。データモデルの最初の部分は、ネットワーク階層またはネットワークスタック（つまり、相互に階層化されたネットワーク）の定義とインベントリのメンテナンスを可能にするネットワークデータモデルを定義します。ネットワークに含まれるノードの数。データモデルの2番目の部分では、トポロジー情報を説明するための情報で基本的なネットワークデータモデルを拡張します。具体的には、「リンク」および「終端点」の概念を追加して、ネットワーク内のノードが相互に接続される方法を説明します。さらに、データモデルは、ネットワークインベントリとネットワーク/サービストポロジの両方をカバーするように拡張できるネットワーク間の垂直階層関係を導入します。
Although it would be possible to combine both parts into a single data model, the separation facilitates integration of network topology and network inventory data models, because it allows network inventory information to be augmented separately, and without concern for topology, into the network data model.
両方の部分を1つのデータモデルに結合することは可能ですが、分離により、ネットワークトポロジとネットワークインベントリデータモデルの統合が容易になります。これにより、ネットワークインベントリ情報を個別に、トポロジに関係なくネットワークデータモデルに追加できるためです。 。
The data model can be augmented to describe the specifics of particular types of networks and topologies. For example, an augmenting data model can provide network node information with attributes that are specific to a particular network type. Examples of augmenting models include data models for Layer 2 network topologies; Layer 3 network topologies such as unicast IGP, IS-IS [RFC1195], and OSPF [RFC2328]; traffic engineering (TE) data [RFC3209]; or any of the variety of transport and service topologies. Information specific to particular network types will be captured in separate, technology-specific data models.
データモデルを拡張して、特定のタイプのネットワークとトポロジの詳細を記述することができます。たとえば、拡張データモデルは、特定のネットワークタイプに固有の属性を持つネットワークノード情報を提供できます。拡張モデルの例には、レイヤー2ネットワークトポロジのデータモデルが含まれます。ユニキャストIGP、IS-IS [RFC1195]、OSPF [RFC2328]などのレイヤー3ネットワークトポロジ。トラフィックエンジニアリング（TE）データ[RFC3209];または、さまざまなトランスポートおよびサービストポロジのいずれか。特定のネットワークタイプに固有の情報は、テクノロジー固有の個別のデータモデルに取り込まれます。
The basic data models introduced in this document are generic in nature and can be applied to many network and service topologies and inventories. The data models allow applications to operate on an inventory or topology of any network at a generic level, where the specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type comes into play and the data model is augmented, the instantiated data still adheres to the same structure and is represented in a consistent fashion. This also facilitates the representation of network hierarchies and dependencies between different network components and network types.
このドキュメントで紹介する基本的なデータモデルは、本質的に一般的なものであり、多くのネットワークおよびサービストポロジとインベントリに適用できます。データモデルを使用すると、特定のインベントリ/トポロジタイプの詳細が不要な汎用レベルで、アプリケーションがネットワークのインベントリまたはトポロジを操作できるようになります。同時に、ネットワークタイプに固有のデータが機能し、データモデルが拡張される場合でも、インスタンス化されたデータは同じ構造に準拠し、一貫した方法で表されます。これにより、ネットワーク階層の表現や、異なるネットワークコンポーネントとネットワークタイプ間の依存関係も容易になります。
The abstract (base) network YANG module introduced in this document, entitled "ietf-network" (Section 6.1), contains a list of abstract network nodes and defines the concept of "network hierarchy" (network stack). The abstract network node can be augmented in inventory and topology data models with inventory-specific and topology-specific attributes. The network hierarchy (stack) allows any given network to have one or more "supporting networks". The relationship between the base network data model, the inventory data models, and the topology data models is shown in Figure 1 (dotted lines in the figure denote possible augmentations to models defined in this document).
このドキュメントで紹介する「ietf-network」というタイトルの抽象（ベース）ネットワークYANGモジュール（セクション6.1）には、抽象ネットワークノードのリストが含まれ、「ネットワーク階層」（ネットワークスタック）の概念が定義されています。抽象ネットワークノードは、インベントリ固有およびトポロジ固有の属性を持つインベントリおよびトポロジデータモデルで拡張できます。ネットワーク階層（スタック）により、特定のネットワークに1つ以上の「サポートネットワーク」を持たせることができます。基本ネットワークデータモデル、インベントリデータモデル、およびトポロジデータモデルの関係を図1に示します（図の点線は、このドキュメントで定義されているモデルの可能な拡張を示しています）。
+------------------------+
| |
| Abstract Network Model |
| |
+------------------------+
|
+-------+-------+
| |
V V
+------------+ ..............
| Abstract | : Inventory :
| Topology | : Model(s) :
| Model | : :
+------------+ ''''''''''''''
|
+-------------+-------------+-------------+
| | | |
V V V V
............ ............ ............ ............
: L1 : : L2 : : L3 : : Service :
: Topology : : Topology : : Topology : : Topology :
: Model : : Model : : Model : : Model :
'''''''''''' '''''''''''' '''''''''''' ''''''''''''
Figure 1: The Network Data Model Structure
図1：ネットワークデータモデルの構造
The network-topology YANG module introduced in this document, entitled "ietf-network-topology" (Section 6.2), defines a generic topology data model at its most general level of abstraction. The module defines a topology graph and components from which it is composed: nodes, edges, and termination points. Nodes (from the "ietf-network" module) represent graph vertices and links represent graph edges. Nodes also contain termination points that anchor the links. A network can contain multiple topologies -- for example, topologies at different layers and overlay topologies. The data model therefore allows relationships between topologies, as well as dependencies between nodes and termination points across topologies, to be captured. An example of a topology stack is shown in Figure 2.
このドキュメントで紹介する「ietf-network-topology」というタイトルのネットワークトポロジーYANGモジュール（セクション6.2）は、最も一般的な抽象化レベルで一般的なトポロジーデータモデルを定義します。このモジュールは、トポロジグラフとそれを構成するコンポーネント（ノード、エッジ、および終端点）を定義します。 「ietf-network」モジュールのノードはグラフの頂点を表し、リンクはグラフのエッジを表します。ノードには、リンクを固定する終端点も含まれます。ネットワークには複数のトポロジを含めることができます。たとえば、異なるレイヤーのトポロジやオーバーレイトポロジなどです。したがって、データモデルを使用すると、トポロジ間の関係や、トポロジ間のノードと終端ポイント間の依存関係をキャプチャできます。トポロジスタックの例を図2に示します。
+---------------------------------------+
/ _[X1]_ "Service" /
/ _/ : \_ /
/ _/ : \_ /
/ _/ : \_ /
/ / : \ /
/ [X2]__________________[X3] /
+---------:--------------:------:-------+
: : :
+----:--------------:----:--------------+
/ : : : "L3" /
/ : : : /
/ : : : /
/ [Y1]_____________[Y2] /
/ * * * /
/ * * * /
+--------------*-------------*--*-------+
* * *
+--------*----------*----*--------------+
/ [Z1]_______________[Z2] "Optical" /
/ \_ * _/ /
/ \_ * _/ /
/ \_ * _/ /
/ \ * / /
/ [Z] /
+---------------------------------------+
Figure 2: Topology Hierarchy (Stack) Example
図2：トポロジー階層（スタック）の例
Figure 2 shows three topology levels. At the top, the "Service" topology shows relationships between service entities, such as service functions in a service chain. The "L3" topology shows network elements at Layer 3 (IP), and the "Optical" topology shows network elements at Layer 1. Service functions in the "Service" topology are mapped onto network elements in the "L3" topology, which in turn are mapped onto network elements in the "Optical" topology. Two service functions (X1 and X3) are mapped onto a single L3 network element (Y2); this could happen, for example, if two service functions reside in the same Virtual Machine (VM) (or server) and share the same set of network interfaces. A single "L3" network element (Y2) is mapped onto two "Optical" network elements (Z2 and Z). This could happen, for example, if a single IP router attaches to multiple Reconfigurable Optical Add/Drop Multiplexers (ROADMs) in the optical domain.
図2は、3つのトポロジレベルを示しています。上部にある「サービス」トポロジは、サービスチェーン内のサービス機能など、サービスエンティティ間の関係を示しています。 「L3」トポロジはレイヤ3（IP）のネットワーク要素を示し、「光」トポロジはレイヤ1のネットワーク要素を示します。「サービス」トポロジのサービス機能は、「L3」トポロジのネットワーク要素にマッピングされます。ターンは、「光学」トポロジーのネットワーク要素にマッピングされます。 2つのサービス機能（X1およびX3）は、単一のL3ネットワーク要素（Y2）にマップされます。これは、たとえば、2つのサービス機能が同じ仮想マシン（VM）（またはサーバー）に存在し、同じネットワークインターフェイスのセットを共有している場合に発生する可能性があります。単一の「L3」ネットワーク要素（Y2）は、2つの「光」ネットワーク要素（Z2およびZ）にマッピングされます。これは、たとえば、単一のIPルーターが光ドメイン内の複数の再構成可能な光アド/ドロップマルチプレクサー（ROADM）に接続されている場合に発生する可能性があります。
Another example of a service topology stack is shown in Figure 3.
サービストポロジスタックの別の例を図3に示します。
VPN1 VPN2
+---------------------+ +---------------------+
/ [Y5]... / / [Z5]______[Z3] /
/ / \ : / / : \_ / : /
/ / \ : / / : \_ / : /
/ / \ : / / : \ / : /
/ [Y4]____[Y1] : / / : [Z2] : /
+------:-------:---:--+ +---:---------:-----:-+
: : : : : :
: : : : : :
: +-------:---:-----:------------:-----:-----+
: / [X1]__:___:___________[X2] : /
:/ / \_ : : _____/ / : /
: / \_ : _____/ / : /
/: / \: / / : /
/ : / [X5] / : /
/ : / __/ \__ / : /
/ : / ___/ \__ / : /
/ : / ___/ \ / : /
/ [X4]__________________[X3]..: /
+------------------------------------------+
L3 Topology
Figure 3: Topology Hierarchy (Stack) Example
図3：トポロジー階層（スタック）の例
Figure 3 shows two VPN service topologies (VPN1 and VPN2) instantiated over a common L3 topology. Each VPN service topology is mapped onto a subset of nodes from the common L3 topology.
図3は、一般的なL3トポロジでインスタンス化された2つのVPNサービストポロジ（VPN1とVPN2）を示しています。各VPNサービストポロジは、共通のL3トポロジからノードのサブセットにマッピングされます。
There are multiple applications for such a data model. For example, within the context of Interface to the Routing System (I2RS), nodes within the network can use the data model to capture their understanding of the overall network topology and expose it to a network controller. A network controller can then use the instantiated topology data to compare and reconcile its own view of the network topology with that of the network elements that it controls. Alternatively, nodes within the network could propagate this understanding to compare and reconcile this understanding either among themselves or with the help of a controller. Beyond the network element and the immediate context of I2RS itself, a network controller might even use the data model to represent its view of the topology that it controls and expose it to applications north of itself. Further use cases where the data model can be applied are described in [USECASE-REQS].
このようなデータモデルには複数のアプリケーションがあります。たとえば、ルーティングシステムへのインターフェイス（I2RS）のコンテキスト内では、ネットワーク内のノードはデータモデルを使用して、ネットワークトポロジ全体の理解を取り込み、それをネットワークコントローラーに公開できます。次に、ネットワークコントローラーは、インスタンス化されたトポロジデータを使用して、ネットワークトポロジーの独自のビューを、それが制御するネットワーク要素のビューと比較および調整できます。あるいは、ネットワーク内のノードがこの理解を伝播し、ノード間またはコントローラーの助けを借りてこの理解を比較および調整できます。ネットワーク要素とI2RS自体の直接のコンテキスト以外に、ネットワークコントローラーはデータモデルを使用して、制御するトポロジのビューを表し、それ自体の北にあるアプリケーションに公開する場合もあります。データモデルを適用できるその他のユースケースは、[USECASE-REQS]で説明されています。
In this data model, a network is categorized as either system controlled or not. If a network is system controlled, then it is automatically populated by the server and represents dynamically learned information that can be read from the operational state datastore. The data model can also be used to create or modify network topologies that might be associated with an inventory model or with an overlay network. Such a network is not system controlled; rather, it is configured by a client.
このデータモデルでは、ネットワークはシステム制御または非制御のいずれかに分類されます。ネットワークがシステム制御の場合、サーバーによって自動的に入力され、動作状態データストアから読み取ることができる動的に学習された情報を表します。データモデルは、インベントリモデルまたはオーバーレイネットワークに関連付けられている可能性のあるネットワークトポロジの作成または変更にも使用できます。このようなネットワークはシステム制御されません。むしろ、クライアントによって構成されます。
The data model allows a network to refer to a supporting network, supporting nodes, supporting links, etc. The data model also allows the layering of a network that is configured on top of a network that is system controlled. This permits the configuration of overlay networks on top of networks that are discovered. Specifically, this data model is structured to support being implemented as part of the ephemeral datastore [RFC8342], the requirements for which are defined in Section 3 of [RFC8242]. This allows network topology data that is written, i.e., configured by a client and not system controlled, to refer to dynamically learned data that is controlled by the system, not configured by a client. A simple use case might involve creating an overlay network that is supported by the dynamically discovered IP-routed network topology. When an implementation places written data for this data model in the ephemeral datastore, such a network MAY refer to another network that is system controlled.
データモデルにより、ネットワークはサポートネットワーク、サポートノード、サポートリンクなどを参照できます。また、データモデルにより、システム制御のネットワーク上に構成されたネットワークの階層化も可能になります。これにより、検出されたネットワークの上にオーバーレイネットワークを設定できます。具体的には、このデータモデルは、エフェメラルデータストア[RFC8342]の一部として実装されることをサポートするように構成されており、その要件は[RFC8242]のセクション3で定義されています。これにより、書き込まれる、つまりシステム制御ではなくクライアントによって構成されたネットワークトポロジデータが、クライアントによって構成されていない、システムによって制御される動的に学習されたデータを参照できるようになります。簡単な使用例としては、動的に検出されたIPルーティングネットワークトポロジによってサポートされるオーバーレイネットワークの作成が含まれる場合があります。実装がこのデータモデルの書き込まれたデータを一時データストアに配置する場合、そのようなネットワークは、システム制御されている別のネットワークを参照する場合があります。
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]で説明されているように解釈されます。
Datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. A datastore maps to an instantiated YANG data tree (definition from [RFC8342]).
データストア：情報を保存してアクセスするための概念的な場所。データストアは、たとえば、ファイル、データベース、フラッシュメモリの場所、またはそれらの組み合わせを使用して実装できます。データストアは、インスタンス化されたYANGデータツリーにマップされます（[RFC8342]からの定義）。
Data subtree: An instantiated data node and the data nodes that are hierarchically contained within it.
データサブツリー：インスタンス化されたデータノードと、その中に階層的に含まれているデータノード。
IGP: Interior Gateway Protocol.
IGP：Interior Gateway Protocol。
IS-IS: Intermediate System to Intermediate System.
IS-IS：Intermediate System to Intermediate System。
OSPF: Open Shortest Path First (a link-state routing protocol).
OSPF：Open Shortest Path First（リンクステートルーティングプロトコル）。
SDN: Software-Defined Networking.
SDN：Software-Defined Networking。
URI: Uniform Resource Identifier.
うり： うにふぉｒｍ れそうｒせ いでんちふぃえｒ。
VM: Virtual Machine.
VM：仮想マシン。
The abstract (base) network data model is defined in the "ietf-network" module. Its structure is shown in Figure 4. The notation syntax follows the syntax used in [RFC8340].
抽象（ベース）ネットワークデータモデルは、「ietf-network」モジュールで定義されています。その構造を図4に示します。表記法の構文は、[RFC8340]で使用される構文に従います。
module: ietf-network
+--rw networks
+--rw network* [network-id]
+--rw network-id network-id
+--rw network-types
+--rw supporting-network* [network-ref]
| +--rw network-ref -> /networks/network/network-id
+--rw node* [node-id]
+--rw node-id node-id
+--rw supporting-node* [network-ref node-ref]
+--rw network-ref
| -> ../../../supporting-network/network-ref
+--rw node-ref -> /networks/network/node/node-id
Figure 4: The Structure of the Abstract (Base) Network Data Model
図4：抽象（ベース）ネットワークデータモデルの構造
The data model contains a container with a list of networks. Each network is captured in its own list entry, distinguished via a network-id.
データモデルには、ネットワークのリストを含むコンテナが含まれています。各ネットワークは、ネットワークIDによって区別される独自のリストエントリにキャプチャされます。
A network has a certain type, such as L2, L3, OSPF, or IS-IS. A network can even have multiple types simultaneously. The type or types are captured underneath the container "network-types". In this model, it serves merely as an augmentation target; network-specific modules will later introduce new data nodes to represent new network types below this target, i.e., will insert them below "network-types" via YANG augmentation.
ネットワークには、L2、L3、OSPF、IS-ISなどの特定のタイプがあります。ネットワークは同時に複数のタイプを持つことさえできます。 1つまたは複数のタイプは、コンテナ「ネットワークタイプ」の下にキャプチャされます。このモデルでは、これは単に拡張ターゲットとして機能します。ネットワーク固有のモジュールは、このターゲットの下に新しいネットワークタイプを表す新しいデータノードを後で導入します。つまり、YANG拡張を介して「ネットワークタイプ」の下にそれらを挿入します。
When a network is of a certain type, it will contain a corresponding data node. Network types SHOULD always be represented using presence containers, not leafs of type "empty". This allows the representation of hierarchies of network subtypes within the instance information. For example, an instance of an OSPF network (which, at the same time, is a Layer 3 unicast IGP network) would contain underneath "network-types" another presence container "l3-unicast-igp-network", which in turn would contain a presence container "ospf-network". Actual examples of this pattern can be found in [RFC8346].
ネットワークが特定のタイプである場合、対応するデータノードが含まれます。ネットワークタイプは、「空」タイプのリーフではなく、常にプレゼンスコンテナを使用して表現する必要があります。これにより、インスタンス情報内のネットワークサブタイプの階層を表すことができます。たとえば、OSPFネットワーク（同時に、レイヤー3ユニキャストIGPネットワーク）のインスタンスには、「network-types」の下に別のプレゼンスコンテナー「l3-unicast-igp-network」が含まれます。プレゼンスコンテナ「ospf-network」が含まれています。このパターンの実際の例は、[RFC8346]にあります。
A network can in turn be part of a hierarchy of networks, building on top of other networks. Any such networks are captured in the list "supporting-network". A supporting network is, in effect, an underlay network.
ネットワークは、ネットワークの階層の一部になり、他のネットワークの上に構築できます。このようなネットワークはすべて、「supporting-network」リストに含まれています。サポートネットワークは、実際にはアンダーレイネットワークです。
Furthermore, a network contains an inventory of nodes that are part of the network. The nodes of a network are captured in their own list. Each node is identified relative to its containing network by a node-id.
さらに、ネットワークには、ネットワークの一部であるノードのインベントリが含まれています。ネットワークのノードは、独自のリストにキャプチャされます。各ノードは、それを含むネットワークに対してノードIDで識別されます。
It should be noted that a node does not exist independently of a network; instead, it is a part of the network that contains it. In cases where the same device or entity takes part in multiple networks, or at multiple layers of a networking stack, the same device or entity will be represented by multiple nodes, one for each network. In other words, the node represents an abstraction of the device for the particular network of which it is a part. To indicate that the same entity or device is part of multiple topologies or networks, it is possible to create one "physical" network with a list of nodes for each of the devices or entities. This (physical) network -- the nodes (entities) in that network -- can then be referred to as an underlay network and as nodes from the other (logical) networks and nodes, respectively. Note that the data model allows for the definition of more than one underlay network (and node), allowing for simultaneous representation of layered network topologies and service topologies, and their physical instantiation.
ノードはネットワークとは独立して存在しないことに注意してください。代わりに、それを含むネットワークの一部です。同じデバイスまたはエンティティが複数のネットワーク、またはネットワークスタックの複数のレイヤーに参加する場合、同じデバイスまたはエンティティは、ネットワークごとに1つずつ、複数のノードで表されます。言い換えると、ノードは、それが属する特定のネットワークのデバイスの抽象化を表します。同じエンティティまたはデバイスが複数のトポロジまたはネットワークの一部であることを示すために、各デバイスまたはエンティティのノードのリストを使用して1つの「物理」ネットワークを作成できます。この（物理）ネットワーク-そのネットワーク内のノード（エンティティ）-は、アンダーレイネットワークと、他の（論理）ネットワークとノードのノードとそれぞれ呼ばれます。データモデルでは複数のアンダーレイネットワーク（およびノード）を定義できるため、レイヤードネットワークトポロジとサービストポロジ、およびそれらの物理的なインスタンス化を同時に表現できることに注意してください。
Similar to a network, a node can be supported by other nodes and map onto one or more other nodes in an underlay network. This is captured in the list "supporting-node". The resulting hierarchy of nodes also allows for the representation of device stacks, where a node at one level is supported by a set of nodes at an underlying level. For example:
ネットワークと同様に、ノードは他のノードによってサポートされ、アンダーレイネットワーク内の1つ以上の他のノードにマップできます。これは、リスト「supporting-node」に取り込まれます。結果として得られるノードの階層により、デバイススタックの表現も可能になります。1つのレベルのノードは、基礎となるレベルのノードのセットによってサポートされます。例えば：
o a "router" node might be supported by a node representing a route processor and separate nodes for various line cards and service modules,
o 「ルーター」ノードは、ルートプロセッサを表すノードと、さまざまなラインカードおよびサービスモジュールの個別のノードによってサポートされる場合があります。
o a virtual router might be supported or hosted on a physical device represented by a separate node,
o 仮想ルーターは、別のノードで表される物理デバイスでサポートまたはホストされている場合があります。
and so on.
等々。
Network data of a network at a particular layer can come into being in one of two ways: (1) the network data is configured by client applications -- for example, in the case of overlay networks that are configured by an SDN Controller application, or (2) the network data is automatically controlled by the system, in the case of networks that can be discovered. It is possible for a configured (overlay) network to refer to a (discovered) underlay network.
特定のレイヤーのネットワークのネットワークデータは、次の2つの方法のいずれかで発生します。（1）ネットワークデータはクライアントアプリケーションによって構成されます。たとえば、SDNコントローラーアプリケーションによって構成されたオーバーレイネットワークの場合、または（2）検出可能なネットワークの場合、ネットワークデータはシステムによって自動的に制御されます。構成された（オーバーレイ）ネットワークが（発見された）アンダーレイネットワークを参照する可能性があります。
The revised datastore architecture [RFC8342] is used to account for those possibilities. Specifically, for each network, the origin of its data is indicated per the "origin" metadata [RFC7952] annotation (as defined in [RFC8342]) -- "intended" for data that was configured by a client application and "learned" for data that is discovered. Network data that is discovered is automatically populated as part of the operational state datastore. Network data that is configured is part of the configuration and intended datastores, respectively. Configured network data that is actually in effect is, in addition, reflected in the operational state datastore. Data in the operational state datastore will always have complete referential integrity. Should a configured data item (such as a node) have a dangling reference that refers to a non-existing data item (such as a supporting node), the configured data item will automatically be removed from the operational state datastore and thus only appear in the intended datastore. It will be up to the client application (such as an SDN Controller) to resolve the situation and ensure that the reference to the supporting resources is configured properly.
改訂されたデータストアアーキテクチャ[RFC8342]は、これらの可能性を説明するために使用されます。具体的には、各ネットワークのデータの出所は、「[origin]」メタデータ[RFC7952]アノテーション（[RFC8342]で定義）ごとに示されます。クライアントアプリケーションによって構成され、「学習」されたデータの「意図」発見されたデータ。検出されたネットワークデータは、動作状態データストアの一部として自動的に入力されます。構成されたネットワークデータは、それぞれ構成および意図されたデータストアの一部です。さらに、実際に有効な構成済みネットワークデータは、運用状態データストアに反映されます。運用状態データストア内のデータは、常に完全な参照整合性を備えています。構成されたデータアイテム（ノードなど）に、存在しないデータアイテム（サポートノードなど）を参照するダングリングリファレンスがある場合、構成されたデータアイテムは動作状態データストアから自動的に削除され、目的のデータストア。状況を解決し、サポートするリソースへの参照が適切に構成されていることを確認するのは、クライアントアプリケーション（SDNコントローラーなど）です。
The abstract (base) network topology data model is defined in the "ietf-network-topology" module. It builds on the network data model defined in the "ietf-network" module, augmenting it with links (defining how nodes are connected) and termination points (which anchor the links and are contained in nodes). The structure of the network topology module is shown in Figure 5. The notation syntax follows the syntax used in [RFC8340].
抽象（ベース）ネットワークトポロジデータモデルは、「ietf-network-topology」モジュールで定義されています。これは、「ietf-network」モジュールで定義されたネットワークデータモデルに基づいて構築され、リンク（ノードの接続方法を定義）と終端ポイント（リンクを固定し、ノードに含まれます）で拡張します。ネットワークトポロジモジュールの構造を図5に示します。表記法の構文は、[RFC8340]で使用されている構文に従います。
module: ietf-network-topology
augment /nw:networks/nw:network:
+--rw link* [link-id]
+--rw link-id link-id
+--rw source
| +--rw source-node? -> ../../../nw:node/node-id
| +--rw source-tp? leafref
+--rw destination
| +--rw dest-node? -> ../../../nw:node/node-id
| +--rw dest-tp? leafref
+--rw supporting-link* [network-ref link-ref]
+--rw network-ref
| -> ../../../nw:supporting-network/network-ref
+--rw link-ref leafref
augment /nw:networks/nw:network/nw:node:
+--rw termination-point* [tp-id]
+--rw tp-id tp-id
+--rw supporting-termination-point*
[network-ref node-ref tp-ref]
+--rw network-ref
| -> ../../../nw:supporting-node/network-ref
+--rw node-ref
| -> ../../../nw:supporting-node/node-ref
+--rw tp-ref leafref
Figure 5: The Structure of the Abstract (Base) Network Topology Data Model
図5：抽象（ベース）ネットワークトポロジデータモデルの構造
A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface.
ノードには、リンクの終端に使用される終端ポイントのリストがあります。ターミネーションポイントの例としては、物理ポートまたは論理ポート、より一般的にはインターフェイスがあります。
Like a node, a termination point can in turn be supported by an underlying termination point, contained in the supporting node of the underlay network.
ノードと同様に、終端ポイントは、アンダーレイネットワークのサポートノードに含まれる、基礎となる終端ポイントによってサポートされます。
A link is identified by a link-id that uniquely identifies the link within a given topology. Links are point-to-point and unidirectional. Accordingly, a link contains a source and a destination. Both source and destination reference a corresponding node, as well as a termination point on that node. Similar to a node, a link can map onto one or more links (which are terminated by the corresponding underlay termination points) in an underlay topology. This is captured in the list "supporting-link".
リンクは、特定のトポロジー内のリンクを一意に識別するlink-idによって識別されます。リンクはポイントツーポイントで単方向です。したがって、リンクにはソースと宛先が含まれます。送信元と宛先の両方が、対応するノードとそのノードの終端ポイントを参照します。ノードと同様に、リンクは、アンダーレイトポロジの1つ以上のリンク（対応するアンダーレイターミネーションポイントによって終端される）にマップできます。これは「supporting-link」リストに含まれています。
In order to derive a data model for a specific type of network, the base data model can be extended. This can be done roughly as follows: a new YANG module for the new network type is introduced. In this module, a number of augmentations are defined against the "ietf-network" and "ietf-network-topology" modules.
特定のタイプのネットワークのデータモデルを導出するために、基本データモデルを拡張できます。これはおおまかに次のように実行できます。新しいネットワークタイプ用の新しいYANGモジュールが導入されています。このモジュールでは、「ietf-network」および「ietf-network-topology」モジュールに対して、いくつかの拡張機能が定義されています。
We start with augmentations against the "ietf-network" module. First, a new network type needs to be defined; this is done by defining a presence container that represents the new network type. The new network type is inserted, by means of augmentation, below the network-types container. Subsequently, data nodes for any node parameters that are specific to a network type are defined and augmented into the node list. The new data nodes can be defined as conditional ("when") on the presence of the corresponding network type in the containing network. In cases where there are any requirements or restrictions in terms of network hierarchies, such as when a network of a new network type requires a specific type of underlay network, it is possible to define corresponding constraints as well and augment the supporting-network list accordingly. However, care should be taken to avoid excessive definitions of constraints.
「ietf-network」モジュールに対する拡張から始めます。まず、新しいネットワークタイプを定義する必要があります。これは、新しいネットワークタイプを表すプレゼンスコンテナを定義することによって行われます。新しいネットワークタイプは、ネットワークタイプコンテナの下に、拡張によって挿入されます。その後、ネットワークタイプに固有のノードパラメータのデータノードが定義され、ノードリストに追加されます。新しいデータノードは、包含ネットワークに対応するネットワークタイプが存在する場合の条件付き（「いつ」）として定義できます。新しいネットワークタイプのネットワークが特定のタイプのアンダーレイネットワークを必要とする場合など、ネットワーク階層に関して要件または制限がある場合、対応する制約を定義し、それに応じてサポートネットワークリストを追加することができます。 。ただし、制約を過度に定義しないように注意する必要があります。
Subsequently, augmentations are defined against the "ietf-network-topology" module. Data nodes are defined for link parameters, as well as termination point parameters, that are specific to the new network type. Those data nodes are inserted via augmentation into the link and termination-point lists, respectively. Again, data nodes can be defined as conditional on the presence of the corresponding network type in the containing network, by adding a corresponding "when" statement.
その後、「ietf-network-topology」モジュールに対して拡張が定義されます。データノードは、新しいネットワークタイプに固有のリンクパラメーターと終端ポイントパラメーターに対して定義されます。これらのデータノードは、オーグメンテーションを介してリンクリストとターミネーションポイントリストにそれぞれ挿入されます。繰り返しになりますが、データノードは、対応する「when」ステートメントを追加することで、包含ネットワークに対応するネットワークタイプが存在することを条件として定義できます。
It is possible, but not required, to group data nodes for a given network type under a dedicated container. Doing so introduces additional structure but lengthens data node path names.
専用コンテナの下で、特定のネットワークタイプのデータノードをグループ化することは可能ですが、必須ではありません。これにより、追加の構造が導入されますが、データノードのパス名が長くなります。
In cases where a hierarchy of network types is defined, augmentations can in turn be applied against augmenting modules, with the module of a network whose type is more specific augmenting the module of a network whose type is more general.
ネットワークタイプの階層が定義されている場合、拡張モジュールに対して拡張が適用され、タイプがより具体的なネットワークのモジュールが、より一般的なタイプのネットワークのモジュールを拡張します。
Rather than maintaining lists in separate containers, the data model is kept relatively flat in terms of its containment structure. Lists of nodes, links, termination points, and supporting nodes; supporting links; and supporting termination points are not kept in separate containers. Therefore, path identifiers that are used to refer to specific nodes -- in management operations or in specifications of constraints -- can remain relatively compact. Of course, this means that there is no separate structure in instance information that separates elements of different lists from one another. Such a structure is semantically not required, but it might provide enhanced "human readability" in some cases.
リストを別々のコンテナーに保持するのではなく、データモデルは、その包含構造の点で比較的フラットに保たれます。ノード、リンク、終端ポイント、およびサポートノードのリスト。サポートリンク;また、サポートする終端ポイントは別のコンテナに保存されません。したがって、特定のノードを参照するために使用されるパス識別子（管理操作または制約の仕様）は、比較的コンパクトなままです。もちろん、これは、異なるリストの要素を互いに分離するインスタンス情報に別個の構造がないことを意味します。このような構造は意味的には必須ではありませんが、場合によっては「人間の読みやすさ」を向上させることができます。
To minimize assumptions regarding what a particular entity might actually represent, mappings between networks, nodes, links, and termination points are kept strictly generic. For example, no assumptions are made regarding whether a termination point actually refers to an interface or whether a node refers to a specific "system" or device; the data model at this generic level makes no provisions for these.
特定のエンティティが実際に何を表すかに関する想定を最小限に抑えるために、ネットワーク、ノード、リンク、および終端ポイント間のマッピングは、厳密に一般的に保たれます。たとえば、ターミネーションポイントが実際にインターフェイスを参照するかどうか、またはノードが特定の「システム」またはデバイスを参照するかどうかについては想定されていません。このジェネリックレベルのデータモデルでは、これらの規定はありません。
Where additional specifics about mappings between upper and lower layers are required, the information can be captured in augmenting modules. For example, to express that a termination point in a particular network type maps to an interface, an augmenting module can introduce an augmentation to the termination point. The augmentation introduces a leaf of type "interface-ref". That leaf references the corresponding interface [RFC8343]. Similarly, if a node maps to a particular device or network element, an augmenting module can augment the node data with a leaf that references the network element.
上位層と下位層の間のマッピングに関する追加の詳細が必要な場合は、情報を拡張モジュールに取り込むことができます。たとえば、特定のネットワークタイプの終端ポイントがインターフェイスにマッピングされることを表現するために、拡張モジュールは、終端ポイントに拡張を導入できます。拡張により、「interface-ref」タイプのリーフが導入されます。そのリーフは対応するインターフェース[RFC8343]を参照します。同様に、ノードが特定のデバイスまたはネットワーク要素にマップする場合、拡張モジュールは、ネットワーク要素を参照するリーフでノードデータを拡張できます。
It is possible for links at one level of a hierarchy to map to multiple links at another level of the hierarchy. For example, a VPN topology might model VPN tunnels as links. Where a VPN tunnel maps to a path that is composed of a chain of several links, the link will contain a list of those supporting links. Likewise, it is possible for a link at one level of a hierarchy to aggregate a bundle of links at another level of the hierarchy.
階層の1つのレベルのリンクを、階層の別のレベルの複数のリンクにマップすることができます。たとえば、VPNトポロジでは、VPNトンネルをリンクとしてモデル化できます。 VPNトンネルが複数のリンクのチェーンで構成されるパスにマップする場合、リンクにはそれらのサポートリンクのリストが含まれます。同様に、階層の1つのレベルにあるリンクが、階層の別のレベルにあるリンクのバンドルを集約することも可能です。
It is possible for a network to undergo churn even as other networks are layered on top of it. When a supporting node, link, or termination point is deleted, the supporting leafrefs in the overlay will be left dangling. To allow for this possibility, the data model makes use of the "require-instance" construct of YANG 1.1 [RFC7950].
他のネットワークがその上に階層化されている場合でも、ネットワークがチャーンされる可能性があります。サポートするノード、リンク、または終端点が削除されると、オーバーレイのサポートするリーフ参照はぶら下がったままになります。この可能性を考慮して、データモデルは、YANG 1.1 [RFC7950]の「require-instance」構成を利用します。
A dangling leafref of a configured object leaves the corresponding instance in a state in which it lacks referential integrity, effectively rendering it nonoperational. Any corresponding object instance is therefore removed from the operational state datastore until the situation has been resolved, i.e., until either (1) the supporting object is added to the operational state datastore or (2) the instance is reconfigured to refer to another object that is actually reflected in the operational state datastore. It will remain part of the intended datastore.
構成されたオブジェクトのぶら下がっているleafrefは、対応するインスタンスを参照整合性に欠けた状態のままにし、事実上動作不能にします。したがって、対応するオブジェクトインスタンスは、状況が解決されるまで、つまり、（1）サポートオブジェクトが運用状態データストアに追加されるか、（2）インスタンスが再構成されて別のオブジェクトを参照するまで、運用状態データストアから削除されます。実際に運用状態データストアに反映されます。意図したデータストアの一部のままになります。
It is the responsibility of the application maintaining the overlay to deal with the possibility of churn in the underlay network. When a server receives a request to configure an overlay network, it SHOULD validate whether supporting nodes / links / termination points refer to nodes in the underlay that actually exist, i.e., verify that the nodes are reflected in the operational state datastore. Configuration requests in which supporting nodes / links / termination points refer to objects currently not in existence SHOULD be rejected. It is the responsibility of the application to update the overlay when a supporting node / link / termination point is deleted at a later point in time. For this purpose, an application might subscribe to updates when changes to the underlay occur -- for example, using mechanisms defined in [YANG-Push].
アンダーレイネットワークでのチャーンの可能性に対処するのは、オーバーレイを維持するアプリケーションの責任です。サーバーがオーバーレイネットワークを構成するリクエストを受信すると、サポートするノード/リンク/終端ポイントが実際に存在するアンダーレイ内のノードを参照しているかどうかを検証する必要があります。つまり、ノードが運用状態データストアに反映されていることを確認します。サポートノード/リンク/終端ポイントが現在存在しないオブジェクトを参照している構成要求は拒否されるべきです（SHOULD）。後でサポートノード/リンク/終端ポイントが削除されたときにオーバーレイを更新するのは、アプリケーションの責任です。この目的のために、たとえば[YANG-Push]で定義されたメカニズムを使用して、アンダーレイが変更されたときにアプリケーションが更新をサブスクライブする場合があります。
The data model makes use of groupings instead of simply defining data nodes "inline". This makes it easier to include the corresponding data nodes in notifications, which then do not need to respecify each data node that is to be included. The trade-off is that it makes the specification of constraints more complex, because constraints involving data nodes outside the grouping need to be specified in conjunction with a "uses" statement where the grouping is applied. This also means that constraints and XML Path Language (XPath) statements need to be specified in such a way that they navigate "down" first and select entire sets of nodes, as opposed to being able to simply specify them against individual data nodes.
データモデルは、単に「インライン」でデータノードを定義するのではなく、グループ化を利用します。これにより、対応するデータノードを通知に簡単に含めることができます。通知に含める各データノードを再指定する必要はありません。グループ化が適用される "uses"ステートメントと組み合わせてグループ化の外側のデータノードを含む制約を指定する必要があるため、トレードオフは制約の指定をより複雑にすることです。これは、制約とXMLパス言語（XPath）ステートメントは、個々のデータノードに対して単純に指定できるのではなく、最初に「下に」ナビゲートしてノードのセット全体を選択するように指定する必要があることも意味します。
The topology data model includes links that are point-to-point and unidirectional. It does not directly support multipoint and bidirectional links. Although this may appear as a limitation, the decision to do so keeps the data model simple and generic, and it allows it to be very easily subjected to applications that make use of graph algorithms. Bidirectional connections can be represented through pairs of unidirectional links. Multipoint networks can be represented through pseudonodes (similar to IS-IS, for example). By introducing hierarchies of nodes with nodes at one level mapping onto a set of other nodes at another level and by introducing new links for nodes at that level, topologies with connections representing non-point-to-point communication patterns can be represented.
トポロジデータモデルには、ポイントツーポイントで単方向のリンクが含まれています。マルチポイントおよび双方向リンクを直接サポートしていません。これは制限事項のように見えるかもしれませんが、そうすることの決定により、データモデルが単純かつ汎用的になり、グラフアルゴリズムを利用するアプリケーションに非常に簡単に適用できるようになります。双方向接続は、単方向リンクのペアを介して表すことができます。マルチポイントネットワークは、疑似ノードを介して表すことができます（たとえば、IS-ISと同様）。あるレベルのノードを別のレベルの他のノードのセットにマッピングするノードの階層を導入し、そのレベルのノードに新しいリンクを導入することにより、非ポイントツーポイントの通信パターンを表す接続を持つトポロジを表すことができます。
Links are terminated by a single termination point, not sets of termination points. Connections involving multihoming or link aggregation schemes need to be represented using multiple point-to-point links and then defining a link at a higher layer that is supported by those individual links.
リンクは、一連の終端ポイントではなく、単一の終端ポイントによって終端されます。マルチホーミングまたはリンク集約方式を含む接続は、複数のポイントツーポイントリンクを使用して表現し、それらの個々のリンクでサポートされる上位層でリンクを定義する必要があります。
In a hierarchy of networks, there are nodes mapping to nodes, links mapping to links, and termination points mapping to termination points. Some of this information is redundant. Specifically, if the mapping of a link to one or more other links is known and the termination points of each link are known, the mapping information for the termination points can be derived via transitive closure and does not have to be explicitly configured. Nonetheless, in order to not constrain applications regarding which mappings they want to configure and which should be derived, the data model provides the option to configure this information explicitly. The data model includes integrity constraints to allow for validating for consistency.
ネットワークの階層には、ノードへのノードマッピング、リンクへのリンクマッピング、および終端ポイントへの終端ポイントマッピングがあります。この情報の一部は冗長です。具体的には、1つ以上の他のリンクへのリンクのマッピングが既知で、各リンクの終端ポイントが既知である場合、終端ポイントのマッピング情報は推移的閉包を介して導出でき、明示的に構成する必要はありません。それでも、アプリケーションがどのマッピングを構成し、どのマッピングを導出するかをアプリケーションに制約しないために、データモデルはこの情報を明示的に構成するオプションを提供します。データモデルには整合性の制約が含まれており、整合性を検証できます。
A network's network types are represented using a container that contains a data node for each of its network types. A network can encompass several types of networks simultaneously; hence, a container is used instead of a case construct, with each network type in turn represented by a dedicated presence container. The reason for not simply using an empty leaf, or (even more simply) even doing away with the network container and just using a leaf-list of "network-type" instead, is to be able to represent "class hierarchies" of network types, with one network type "refining" the other. Containers specific to a network type are to be defined in the network-specific modules, augmenting the network-types container.
ネットワークのネットワークタイプは、各ネットワークタイプのデータノードを含むコンテナを使用して表されます。ネットワークは、いくつかのタイプのネットワークを同時に包含することができます。したがって、ケースコンストラクトの代わりにコンテナが使用され、各ネットワークタイプは専用のプレゼンスコンテナで表されます。空のリーフを単に使用するのではなく、または（さらに簡単に）ネットワークコンテナを廃止して、代わりに「ネットワークタイプ」のリーフリストを使用する理由は、ネットワークの「クラス階層」を表すことができるためです。タイプ。一方のネットワークタイプが他方を「リファイン」します。ネットワークタイプ固有のコンテナーは、ネットワーク固有のモジュールで定義され、ネットワークタイプコンテナーを拡張します。
One common requirement concerns the ability to indicate that the same device can be part of multiple networks and topologies. However, the data model defines a node as relative to the network that contains it. The same node cannot be part of multiple topologies. In many cases, a node will be the abstraction of a particular device in a network. To reflect that the same device is part of multiple topologies, the following approach might be chosen: a new type of network to represent a "physical" (or "device") network is introduced, with nodes representing devices. This network forms an underlay network for logical networks above it, with nodes of the logical network mapping onto nodes in the physical network.
一般的な要件の1つは、同じデバイスが複数のネットワークとトポロジの一部になることができることを示す機能に関係しています。ただし、データモデルはノードを、それを含むネットワークに関連するものとして定義します。同じノードを複数のトポロジの一部にすることはできません。多くの場合、ノードはネットワーク内の特定のデバイスを抽象化したものになります。同じデバイスが複数のトポロジの一部であることを反映するには、次のアプローチを選択できます。「物理」（または「デバイス」）ネットワークを表す新しいタイプのネットワークが導入され、ノードがデバイスを表します。このネットワークは、その上の論理ネットワークのアンダーレイネットワークを形成し、論理ネットワークのノードが物理ネットワークのノードにマッピングされます。
This scenario is depicted in Figure 6. This figure depicts three networks with two nodes each. A physical network ("P" in the figure) consists of an inventory of two nodes (D1 and D2), each representing a device. A second network, X, has a third network, Y, as its underlay. Both X and Y also have the physical network (P) as their underlay. X1 has both Y1 and D1 as underlay nodes, while Y1 has D1 as its underlay node. Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as its underlay node. The fact that X1 and Y1 are both instantiated on the same physical node (D1) can be easily seen.
このシナリオを図6に示します。この図は、それぞれ2つのノードを持つ3つのネットワークを示しています。物理ネットワーク（図の「P」）は、それぞれがデバイスを表す2つのノード（D1とD2）のインベントリで構成されています。 2番目のネットワークXには、そのアンダーレイとして3番目のネットワークYがあります。 XとYの両方に、アンダーレイとして物理ネットワーク（P）もあります。 X1にはY1とD1の両方がアンダーレイノードとしてあり、Y1にはD1がアンダーレイノードとしてあります。同様に、X2にはY2とD2の両方がアンダーレイノードとしてあり、Y2にはD2がアンダーレイノードとしてあります。 X1とY1の両方が同じ物理ノード（D1）でインスタンス化されているという事実は容易に理解できます。
+---------------------+
/ [X1]____[X2] / X(Service Overlay)
+----:--:----:--------+
..: :..: :
........: ....: : :....
+-----:-------------:--+ : :...
/ [Y1]____[Y2]....: / :.. :
+------|-------|-------+ :.. :...
Y(L3) | +---------------------:-----+ :
| +----:----|-:----------+
+------------------------/---[D1] [D2] /
+----------------------+
P (Physical Network)
Figure 6: Topology Hierarchy Example - Multiple Underlays
図6：トポロジ階層の例-複数のアンダーレイ
In the case of a physical network, nodes represent physical devices and termination points represent physical ports. It should be noted that it is also possible to augment the data model for a physical network type, defining augmentations that have nodes reference system information and termination points reference physical interfaces, in order to provide a bridge between network and device models.
物理ネットワークの場合、ノードは物理デバイスを表し、終端点は物理ポートを表します。ネットワークモデルとデバイスモデルの間にブリッジを提供するために、物理ネットワークタイプのデータモデルを拡張して、ノードがシステム情報を参照し、終端ポイントが物理インターフェースを参照する拡張を定義することもできることに注意してください。
4.4.10. Supporting Client-Configured and System-Controlled Network Topologies
4.4.10. クライアント構成およびシステム制御のネットワークトポロジのサポート
YANG requires data nodes to be designated as either configuration data ("config true") or operational data ("config false"), but not both, yet it is important to have all network information, including vertical cross-network dependencies, captured in one coherent data model. In most cases, network topology information about a network is discovered; the topology is considered a property of the network that is reflected in the data model. That said, certain types of topologies need to also be configurable by an application, e.g., in the case of overlay topologies.
YANGでは、データノードを構成データ（ "config true"）または運用データ（ "config false"）のいずれかとして指定する必要がありますが、両方ではありませんが、垂直のネットワーク間依存関係を含むすべてのネットワーク情報を、 1つの一貫したデータモデル。ほとんどの場合、ネットワークに関するネットワークトポロジ情報が検出されます。トポロジは、データモデルに反映されるネットワークのプロパティと見なされます。とはいえ、オーバーレイトポロジーの場合など、特定のタイプのトポロジーもアプリケーションで構成可能である必要があります。
The YANG data model for network topologies designates all data as "config true". The distinction between data that is actually configured and data that is in effect, including network data that is discovered, is provided through the datastores introduced as part of the Network Management Datastore Architecture (NMDA) [RFC8342]. Network topology data that is discovered is automatically populated as part of the operational state datastore, i.e., <operational>. It is "system controlled". Network topology that is configured is instantiated as part of a configuration datastore, e.g., <intended>. Only when it has actually taken effect will it also be instantiated as part of the operational state datastore, i.e., <operational>.
ネットワークトポロジのYANGデータモデルは、すべてのデータを「config true」として指定します。実際に構成されたデータと有効なデータ（発見されたネットワークデータを含む）の違いは、ネットワーク管理データストアアーキテクチャ（NMDA）[RFC8342]の一部として導入されたデータストアを通じて提供されます。検出されたネットワークトポロジデータは、動作状態データストアの一部として自動的に入力されます（<operational>など）。 「システム制御」です。構成されているネットワークトポロジは、構成データストアの一部としてインスタンス化されます（<intended>など）。実際に有効になった場合にのみ、運用状態データストアの一部としてインスタンス化されます（つまり、<operational>）。
In general, a configured network topology will refer to an underlay topology and include layering information, such as the supporting node(s) underlying a node, supporting link(s) underlying a link, and supporting termination point(s) underlying a termination point. The supporting objects must be instantiated in the operational state datastore in order for the dependent overlay object to be reflected in the operational state datastore. Should a configured data item (such as a node) have a dangling reference that refers to a nonexistent data item (such as a supporting node), the configured data item will automatically be removed from <operational> and show up only in <intended>. It will be up to the client application to resolve the situation and ensure that the reference to the supporting resources is configured properly.
一般に、構成されたネットワークトポロジは、アンダーレイトポロジを参照し、ノードの基礎となるサポートノード、リンクの基礎となるサポートリンク、終端ポイントの基礎となるサポートターミネーションポイントなどのレイヤー情報を含みます。 。依存オーバーレイオブジェクトが動作状態データストアに反映されるようにするには、サポートオブジェクトを動作状態データストアにインスタンス化する必要があります。構成されたデータアイテム（ノードなど）に、存在しないデータアイテム（サポートノードなど）を参照するぶら下がり参照がある場合、構成されたデータアイテムは<operational>から自動的に削除され、<intended>にのみ表示されます。状況を解決し、サポートするリソースへの参照が適切に構成されていることを確認するのは、クライアントアプリケーション次第です。
For each network, the origin of its data is indicated per the "origin" metadata [RFC7952] annotation defined in [RFC8342]. In general, the origin of discovered network data is "learned"; the origin of configured network data is "intended".
各ネットワークについて、そのデータの出所は、[RFC8342]で定義されている「origin」メタデータ[RFC7952]アノテーションに従って示されます。一般に、発見されたネットワークデータの起源は「学習」されます。設定されたネットワークデータの起源は「意図された」ものです。
The current data model defines identifiers of nodes, networks, links, and termination points as URIs. Alternatively, they could have been defined as strings.
現在のデータモデルは、ノード、ネットワーク、リンク、および終端ポイントの識別子をURIとして定義しています。または、文字列として定義することもできます。
The case for strings is that they will be easier to implement. The reason for choosing URIs is that the topology / node / termination point exists in a larger context; hence, it is useful to be able to correlate identifiers across systems. Although strings -- being the universal data type -- are easier for human beings, they also muddle things. What typically happens is that strings have some structure that is magically assigned, and the knowledge of this structure has to be communicated to each system working with the data. A URI makes the structure explicit and also attaches additional semantics: the URI, unlike a free-form string, can be fed into a URI resolver, which can point to additional resources associated with the URI. This property is important when the topology data is integrated into a larger and more complex system.
文字列の場合は、実装が簡単になるということです。 URIを選択する理由は、トポロジ/ノード/終端点がより大きなコンテキストに存在するためです。したがって、システム間で識別子を関連付けることができると便利です。文字列-ユニバーサルデータタイプであるため-は人間にとっては簡単ですが、文字列を混乱させることにもなります。通常発生するのは、文字列に魔法のように割り当てられた構造があり、この構造の知識をデータを処理する各システムに伝達する必要があることです。 URIは構造を明示的にし、追加のセマンティクスも付加します。URIは、自由形式の文字列とは異なり、URIリゾルバーにフィードでき、URIに関連付けられた追加のリソースを指すことができます。このプロパティは、トポロジデータがより大きくより複雑なシステムに統合される場合に重要です。
The data model makes use of data types that have been defined in [RFC6991].
データモデルは、[RFC6991]で定義されているデータ型を利用します。
This is a protocol-independent YANG data model with topology information. It is separate from, and not linked with, data models that are used to configure routing protocols or routing information. This includes, for example, the "ietf-routing" YANG module [RFC8022].
これは、トポロジー情報を含む、プロトコルに依存しないYANGデータモデルです。ルーティングプロトコルやルーティング情報の構成に使用されるデータモデルとは別のものであり、リンクされていません。これには、たとえば、「ietf-routing」YANGモジュール[RFC8022]が含まれます。
The data model obeys the requirements for the ephemeral state as specified in [RFC8242]. For ephemeral topology data that is system controlled, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the operational state datastore without relying on a configuration datastore.
データモデルは、[RFC8242]で指定されている一時的な状態の要件に従います。システムで制御される一時的なトポロジデータの場合、トポロジ情報の維持を担当するプロセスは、構成データストアに依存することなく、ルーティングプロセス（OSPFなど）から運用状態データストアに情報をロードします。
<CODE BEGINS> file "ietf-network@2018-02-26.yang"
module ietf-network {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nw;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
組織「IETF I2RS（ルーティングシステムへのインターフェイス）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base data model for a collection of nodes in a network. Node definitions are further used in network topologies and inventories.
説明「このモジュールは、ネットワーク内のノードのコレクションに共通の基本データモデルを定義します。ノード定義は、ネットワークトポロジおよびインベントリでさらに使用されます。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2018 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 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
typedef node-id {
type inet:uri;
description
"Identifier for a node. The precise structure of the node-id
will be up to the implementation. For example, some
implementations MAY pick a URI that includes the network-id
as part of the path. The identifier SHOULD be chosen
such that the same node in a real network topology will
always be identified through the same identifier, even if
the data model is instantiated in separate datastores. An
implementation MAY choose to capture semantics in the
identifier -- for example, to indicate the type of node.";
}
typedef network-id {
type inet:uri;
description
"Identifier for a network. The precise structure of the
network-id will be up to the implementation. The identifier
SHOULD be chosen such that the same network will always be
identified through the same identifier, even if the data model
is instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier -- for example,
to indicate the type of network.";
}
grouping network-ref {
description
"Contains the information necessary to reference a network --
for example, an underlay network.";
leaf network-ref {
type leafref {
path "/nw:networks/nw:network/nw:network-id";
require-instance false;
}
description
"Used to reference a network -- for example, an underlay
network.";
}
}
grouping node-ref {
description
"Contains the information necessary to reference a node.";
leaf node-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nw:node/nw:node-id";
require-instance false;
}
description
"Used to reference a node.
Nodes are identified relative to the network that
contains them.";
}
uses network-ref;
}
container networks {
description
"Serves as a top-level container for a list of networks.";
list network {
key "network-id";
description
"Describes a network.
A network typically contains an inventory of nodes,
topological information (augmented through the
network-topology data model), and layering information.";
leaf network-id {
type network-id;
description
"Identifies a network.";
}
container network-types {
description
"Serves as an augmentation target.
The network type is indicated through corresponding
presence containers augmented into this container.";
}
list supporting-network {
key "network-ref";
description
"An underlay network, used to represent layered network
topologies.";
leaf network-ref {
type leafref {
path "/nw:networks/nw:network/nw:network-id";
require-instance false;
}
description
"References the underlay network.";
}
}
list node {
key "node-id";
description
"The inventory of nodes of this network.";
leaf node-id {
type node-id;
description
"Uniquely identifies a node within the containing
network.";
}
list supporting-node {
key "network-ref node-ref";
description
"Represents another node that is in an underlay network
and that supports this node. Used to represent layering
structure.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-network/nw:network-ref";
require-instance false;
}
description
"References the underlay network of which the
underlay node is a part.";
}
leaf node-ref {
type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id";
require-instance false;
}
description
"References the underlay node itself.";
}
}
}
}
}
}
<CODE ENDS>
<コード終了>
<CODE BEGINS> file "ietf-network-topology@2018-02-26.yang"
module ietf-network-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix nt;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
組織「IETF I2RS（ルーティングシステムへのインターフェイス）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base model for a network topology, augmenting the base network data model with links to connect nodes, as well as termination points to terminate links on nodes.
説明「このモジュールは、ネットワークトポロジの共通基本モデルを定義し、ノードを接続するためのリンク、およびノード上のリンクを終端するための終端ポイントで基本ネットワークデータモデルを拡張します。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2018 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 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
typedef link-id {
type inet:uri;
description
"An identifier for a link in a topology. The precise
structure of the link-id will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the
same identifier, even if the data model is instantiated in
separate datastores. An implementation MAY choose to capture
semantics in the identifier -- for example, to indicate the
type of link and/or the type of topology of which the link is
a part.";
}
typedef tp-id {
type inet:uri;
description
"An identifier for termination points on a node. The precise
structure of the tp-id will be up to the implementation.
The identifier SHOULD be chosen such that the same termination
point in a real network topology will always be identified
through the same identifier, even if the data model is
instantiated in separate datastores. An implementation MAY
choose to capture semantics in the identifier -- for example,
to indicate the type of termination point and/or the type of
node that contains the termination point.";
}
grouping link-ref {
description
"This grouping can be used to reference a link in a specific
network. Although it is not used in this module, it is
defined here for the convenience of augmenting modules.";
leaf link-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nt:link/nt:link-id";
require-instance false;
}
description
"A type for an absolute reference to a link instance.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw:network-ref;
}
grouping tp-ref {
description
"This grouping can be used to reference a termination point
in a specific node. Although it is not used in this module,
it is defined here for the convenience of augmenting
modules.";
leaf tp-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/../"+
"network-ref]/nw:node[nw:node-id=current()/../"+
"node-ref]/nt:termination-point/nt:tp-id";
require-instance false;
}
description
"A type for an absolute reference to a termination point.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw:node-ref;
}
augment "/nw:networks/nw:network" {
description
"Add links to the network data model.";
list link {
key "link-id";
description
"A network link connects a local (source) node and
a remote (destination) node via a set of the respective
node's termination points. It is possible to have several
links between the same source and destination nodes.
Likewise, a link could potentially be re-homed between
termination points. Therefore, in order to ensure that we
would always know to distinguish between links, every link
is identified by a dedicated link identifier. Note that a
link models a point-to-point link, not a multipoint link.";
leaf link-id {
type link-id;
description
"The identifier of a link in the topology.
A link is specific to a topology to which it belongs.";
}
container source {
description
"This container holds the logical source of a particular
link.";
leaf source-node {
type leafref {
path "../../../nw:node/nw:node-id";
require-instance false;
}
description
"Source node identifier. Must be in the same topology.";
}
leaf source-tp {
type leafref {
path "../../../nw:node[nw:node-id=current()/../"+
"source-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the source node
and terminates the link.";
}
}
container destination {
description
"This container holds the logical destination of a
particular link.";
leaf dest-node {
type leafref {
path "../../../nw:node/nw:node-id";
require-instance false;
}
description
"Destination node identifier. Must be in the same
network.";
}
leaf dest-tp {
type leafref {
path "../../../nw:node[nw:node-id=current()/../"+
"dest-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the
destination node and terminates the link.";
}
}
list supporting-link {
key "network-ref link-ref";
description
"Identifies the link or links on which this link depends.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-network/nw:network-ref";
require-instance false;
}
description
"This leaf identifies in which underlay topology
the supporting link is present.";
}
leaf link-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/"+
"../network-ref]/link/link-id";
require-instance false;
}
description
"This leaf identifies a link that is a part
of this link's underlay. Reference loops in which
a link identifies itself as its underlay, either
directly or transitively, are not allowed.";
}
}
}
}
augment "/nw:networks/nw:network/nw:node" {
description
"Augments termination points that terminate links.
Termination points can ultimately be mapped to interfaces.";
list termination-point {
key "tp-id";
description
"A termination point can terminate a link.
Depending on the type of topology, a termination point
could, for example, refer to a port or an interface.";
leaf tp-id {
type tp-id;
description
"Termination point identifier.";
}
list supporting-termination-point {
key "network-ref node-ref tp-ref";
description
"This list identifies any termination points on which a
given termination point depends or onto which it maps.
Those termination points will themselves be contained
in a supporting node. This dependency information can be
inferred from the dependencies between links. Therefore,
this item is not separately configurable. Hence, no
corresponding constraint needs to be articulated.
The corresponding information is simply provided by the
implementing system.";
leaf network-ref {
type leafref {
path "../../../nw:supporting-node/nw:network-ref";
require-instance false;
}
description
"This leaf identifies in which topology the
supporting termination point is present.";
}
leaf node-ref {
type leafref {
path "../../../nw:supporting-node/nw:node-ref";
require-instance false;
}
description
"This leaf identifies in which node the supporting
termination point is present.";
}
leaf tp-ref {
type leafref {
path "/nw:networks/nw:network[nw:network-id=current()/"+
"../network-ref]/nw:node[nw:node-id=current()/../"+
"node-ref]/termination-point/tp-id";
require-instance false;
}
description
"Reference to the underlay node (the underlay node must
be in a different topology).";
}
}
}
}
}
<CODE ENDS>
<コード終了>
This document registers the following namespace URIs in the "IETF XML Registry" [RFC3688]:
このドキュメントでは、「IETF XMLレジストリ」[RFC3688]に次の名前空間URIを登録しています。
URI: urn:ietf:params:xml:ns:yang:ietf-network Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-network登録者の連絡先：IESG。 XML：なし。要求されたURIはXML名前空間です。
URI: urn:ietf:params:xml:ns:yang:ietf-network-topology Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-network-topology登録者の連絡先：IESG。 XML：なし。要求されたURIはXML名前空間です。
URI: urn:ietf:params:xml:ns:yang:ietf-network-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-network-state登録者の連絡先：IESG。 XML：なし。要求されたURIはXML名前空間です。
URI: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-network-topology-state登録者の連絡先：IESG。 XML：なし。要求されたURIはXML名前空間です。
This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]:
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]に次のYANGモジュールを登録しています。
Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nw
Reference: RFC 8345
Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: nt
Reference: RFC 8345
Name: ietf-network-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state
Prefix: nw-s
Reference: RFC 8345
Name: ietf-network-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state
Prefix: nt-s
Reference: RFC 8345
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 [RFC5246].
このドキュメントで指定されているYANGモジュールは、NETCONF [RFC6241]やRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義します。最下位のNETCONFレイヤーはセキュアなトランスポートレイヤーであり、実装に必須のセキュアなトランスポートはセキュアシェル（SSH）です[RFC6242]。最も低いRESTCONF層はHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC5246]です。
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
NETCONFアクセス制御モデル[RFC8341]は、特定のNETCONFまたはRESTCONFユーザーのアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
The network topology and inventory created by these modules reveal information about the structure of networks that could be very helpful to an attacker. As a privacy consideration, although there is no personally identifiable information defined in these modules, it is possible that some node identifiers may be associated with devices that are in turn associated with specific users.
これらのモジュールによって作成されたネットワークトポロジとインベントリは、攻撃者にとって非常に役立つ可能性があるネットワークの構造に関する情報を明らかにします。プライバシーに関する考慮事項として、これらのモジュールでは個人を特定できる情報は定義されていませんが、一部のノード識別子が特定のユーザーに関連付けられているデバイスに関連付けられている可能性があります。
The YANG modules define information that can be configurable in certain instances -- for example, in the case of overlay topologies that can be created by client applications. In such cases, a malicious client could introduce topologies that are undesired. Specifically, a malicious client could attempt to remove or add a node, a link, or a termination point by creating or deleting corresponding elements in node, link, or termination point lists, respectively. In the case of a topology that is learned, the server will automatically prohibit such misconfiguration attempts. In the case of a topology that is configured, i.e., whose origin is "intended", the undesired configuration could become effective and be reflected in the operational state datastore, leading to disruption of services provided via this topology. For example, the topology could be "cut" or could be configured in a suboptimal way, leading to increased consumption of resources in the underlay network due to the routing and bandwidth utilization inefficiencies that would result. Likewise, it could lead to degradation of service levels as well as possible disruption of service. For those reasons, it is important that the NETCONF access control model be vigorously applied to prevent topology misconfiguration by unauthorized clients.
YANGモジュールは、クライアントアプリケーションで作成できるオーバーレイトポロジの場合など、特定のインスタンスで構成可能な情報を定義します。このような場合、悪意のあるクライアントが望ましくないトポロジーを導入する可能性があります。具体的には、悪意のあるクライアントは、ノード、リンク、または終端ポイントのリストでそれぞれ対応する要素を作成または削除することにより、ノード、リンク、または終端ポイントを削除または追加しようとする可能性があります。学習されたトポロジの場合、サーバーはそのような誤構成の試行を自動的に禁止します。構成された、つまりその起源が「意図された」トポロジの場合、不要な構成が有効になり、運用状態のデータストアに反映され、このトポロジを介して提供されるサービスが中断する可能性があります。たとえば、トポロジが「カット」されたり、次善の方法で設定されたりすると、ルーティングと帯域幅の非効率が原因で、アンダーレイネットワークのリソースの消費が増加します。同様に、サービスレベルの低下やサービスの中断につながる可能性があります。これらの理由により、許可されていないクライアントによるトポロジの設定ミスを防ぐために、NETCONFアクセスコントロールモデルを積極的に適用することが重要です。
There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
これらのYANGモジュールには、書き込み/作成/削除が可能なデータノードがいくつか定義されています（つまり、config true、デフォルトです）。これらのデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。適切な保護なしにこれらのデータノードに書き込み操作（edit-configなど）を行うと、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
In the "ietf-network" module:
「ietf-network」モジュールで：
o network: A malicious client could attempt to remove or add a network in an effort to remove an overlay topology or to create an unauthorized overlay.
o ネットワーク：悪意のあるクライアントがネットワークを削除または追加して、オーバーレイトポロジを削除したり、不正なオーバーレイを作成したりする可能性があります。
o supporting network: A malicious client could attempt to disrupt the logical structure of the model, resulting in a lack of overall data integrity and making it more difficult to, for example, troubleshoot problems rooted in the layering of network topologies.
o サポートするネットワーク：悪意のあるクライアントがモデルの論理構造を破壊しようとする可能性があり、その結果、全体的なデータの整合性が失われ、たとえばネットワークトポロジの階層化に起因する問題のトラブルシューティングが困難になります。
o node: A malicious client could attempt to remove or add a node from the network -- for example, in order to sabotage the topology of a network overlay.
o ノード：悪意のあるクライアントがネットワークからノードを削除または追加しようとする可能性があります。たとえば、ネットワークオーバーレイのトポロジを妨害するためです。
o supporting node: A malicious client could attempt to change the supporting node in order to sabotage the layering of an overlay.
o サポートノード：悪意のあるクライアントがオーバーレイのレイヤー化を妨害するためにサポートノードを変更しようとする可能性があります。
In the "ietf-network-topology" module:
「ietf-network-topology」モジュールで：
o link: A malicious client could attempt to remove a link from a topology, add a new link, manipulate the way the link is layered over supporting links, or modify the source or destination of the link. In each case, the structure of the topology would be sabotaged, and this scenario could, for example, result in an overlay topology that is less than optimal.
o リンク：悪意のあるクライアントは、トポロジからリンクを削除したり、新しいリンクを追加したり、サポートリンク上にリンクを重ねる方法を操作したり、リンクのソースまたは宛先を変更したりする可能性があります。いずれの場合も、トポロジの構造が妨害され、このシナリオでは、たとえば、オーバーレイトポロジが最適ではなくなる可能性があります。
o termination point: A malicious client could attempt to remove termination points from a node, add "phantom" termination points to a node, or change the layering dependencies of termination points, again in an effort to sabotage the integrity of a topology and potentially disrupt orderly operations of an overlay.
o ターミネーションポイント：悪意のあるクライアントがノードからターミネーションポイントを削除したり、ノードに「ファントム」ターミネーションポイントを追加したり、ターミネーションポイントの階層化依存関係を変更したりして、トポロジの整合性を妨害し、秩序だった秩序を乱す可能性があります。オーバーレイの操作。
[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>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[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>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[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>。
[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>。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<https://www.rfc-editor.org/ info / rfc1195>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「情報モデルとデータモデルの違いについて」、RFC 3444、DOI 10.17487 / RFC3444、2003年1月、<https://www.rfc-editor.org/info/ rfc3444>。
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.
[RFC7951] Lhotka、L。、「YANGでモデル化されたデータのJSONエンコーディング」、RFC 7951、DOI 10.17487 / RFC7951、2016年8月、<https://www.rfc-editor.org/info/rfc7951>。
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.
[RFC7952] Lhotka、L。、「YANGでのメタデータの定義と使用」、RFC 7952、DOI 10.17487 / RFC7952、2016年8月、<https://www.rfc-editor.org/info/rfc7952>。
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>.
[RFC8022] Lhotka、L。およびA. Lindem、「ルーティング管理のためのYANGデータモデル」、RFC 8022、DOI 10.17487 / RFC8022、2016年11月、<https://www.rfc-editor.org/info/rfc8022> 。
[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System (I2RS) Ephemeral State Requirements", RFC 8242, DOI 10.17487/RFC8242, September 2017, <https://www.rfc-editor.org/info/rfc8242>.
[RFC8242] Haas、J。およびS. Hares、「Interface to the Routing System（I2RS）Ephemeral State Requirements」、RFC 8242、DOI 10.17487 / RFC8242、2017年9月、<https://www.rfc-editor.org/ info / rfc8242>。
[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>。
[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>。
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, March 2018, <https://www.rfc-editor.org/info/rfc8346>.
[RFC8346] Clemm、A.、Medved、J.、Varga、R.、Liu、X.、Ananthakrishnan、H。、およびN. Bahadur、「レイヤー3トポロジのYANGデータモデル」、RFC 8346、DOI 10.17487 / RFC8346、2018年3月、<https://www.rfc-editor.org/info/rfc8346>。
[USECASE-REQS] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Work in Progress, draft-ietf-i2rs-usecase-reqs-summary-03, November 2016.
[USECASE-REQS] Hares、S.およびM. Chen、「Summary of I2RS Use Case Requirements」、Work in Progress、draft-ietf-i2rs-usecase-reqs-summary-03、2016年11月。
[YANG-Push] Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore Subscription", Work in Progress, draft-ietf-netconf-yang-push-15, February 2018.
[YANG-Push] Clemm、A.、Voit、E.、Gonzalez Prieto、A.、Tripathy、A.、Nilsen-Nygaard、E.、Bierman、A。、およびB. Lengyel、「YANG Datastore Subscription」、Work進行中、draft-ietf-netconf-yang-push-15、2018年2月。
In its simplest form, topology is learned by a network element (e.g., a router) through its participation in peering protocols (IS-IS, BGP, etc.). This learned topology can then be exported (e.g., to a Network Management System) for external utilization. Typically, any network element in a domain can be queried for its topology and be expected to return the same result.
最も単純な形式では、トポロジは、ピアリングプロトコル（IS-IS、BGPなど）への参加を通じてネットワーク要素（ルーターなど）によって学習されます。この学習されたトポロジは、外部で使用するために（ネットワーク管理システムなどに）エクスポートできます。通常、ドメイン内のすべてのネットワーク要素は、そのトポロジーを照会することができ、同じ結果を返すことが期待されます。
In a slightly more complex form, the network element may be a controller. It could be a network element with satellite or subtended devices hanging off of it, or it could be a controller in the more classical sense -- that is, a special device designated to orchestrate the activities of a number of other devices (e.g., an Optical Controller). In this case, the controller device is logically a singleton and must be queried distinctly.
もう少し複雑な形式では、ネットワーク要素はコントローラである場合があります。それは、衛星またはサブテンドデバイスがぶら下がっているネットワーク要素であるか、またはより古典的な意味でのコントローラーである可能性があります-つまり、他の多くのデバイスのアクティビティを調整するように指定された特別なデバイス（たとえば、光コントローラ）。この場合、コントローラーデバイスは論理的にシングルトンであり、個別にクエリする必要があります。
It is worth noting that controllers can be built on top of other controllers to establish a topology incorporating all of the domains within an entire network.
コントローラーを他のコントローラーの上に構築して、ネットワーク全体のすべてのドメインを組み込んだトポロジーを確立できることに注意してください。
In all of the cases above, the topology learned by the network element is considered to be operational state data. That is, the data is accumulated purely by the network element's interactions with other systems and is subject to change dynamically without input or consent.
上記のすべてのケースで、ネットワーク要素によって学習されたトポロジは、動作状態データと見なされます。つまり、データはネットワーク要素と他のシステムとの相互作用によって純粋に蓄積され、入力や同意なしに動的に変更される可能性があります。
Consider a scenario where an Optical Controller presents its topology, in abstract TE terms, to a client packet controller. This customized topology (which gets merged into the client's native topology) contains sufficient information for the path-computing client to select paths across the optical domain according to its policies. If the client determines (at any given point in time) that this imported topology does not cater exactly to its requirements, it may decide to request modifications to the topology. Such customization requests may include the addition or deletion of topological elements or the modification of attributes associated with existing topological elements. From the perspective of the Optical Controller, these requests translate into configuration changes to the exported abstract topology.
光コントローラがトポロジを抽象TE用語でクライアントパケットコントローラに提示するシナリオを考えます。このカスタマイズされたトポロジ（クライアントのネイティブトポロジにマージされます）には、パス計算クライアントがそのポリシーに従って光ドメイン全体のパスを選択するための十分な情報が含まれています。クライアントは、このインポートされたトポロジが要件に正確に対応していないと（ある時点で）判断した場合、トポロジの変更を要求することを決定する場合があります。このようなカスタマイズ要求には、トポロジ要素の追加または削除、または既存のトポロジ要素に関連付けられている属性の変更が含まれる場合があります。光コントローラーの観点から見ると、これらの要求は、エクスポートされた抽象トポロジーの構成変更に変換されます。
In certain scenarios, the topology learned by a controller needs to be augmented with additional attributes before running a computation algorithm on it. Consider the case where a path-computation application on the controller needs to take the geographic coordinates of the nodes into account while computing paths on the learned topology. If the learned topology does not contain these coordinates, then these additional attributes must be configured on the corresponding topological elements.
特定のシナリオでは、計算アルゴリズムを実行する前に、コントローラーによって学習されたトポロジに追加の属性を追加する必要があります。学習したトポロジー上のパスを計算する際に、コントローラー上のパス計算アプリケーションがノードの地理座標を考慮する必要がある場合を考えます。学習したトポロジにこれらの座標が含まれていない場合、これらの追加の属性を対応するトポロジ要素で構成する必要があります。
In this scenario, an SDN Controller (for example, Open Daylight) maintains a view of the topology of the network that it controls based on information that it discovers from the network. In addition, it provides an application in which it configures and maintains an overlay topology.
このシナリオでは、SDNコントローラー（たとえば、Open Daylight）は、ネットワークから検出した情報に基づいて制御するネットワークのトポロジのビューを維持します。さらに、オーバーレイトポロジを構成および維持するアプリケーションを提供します。
The SDN Controller thus maintains two roles:
したがって、SDNコントローラーは2つの役割を維持します。
o It is a client to the network.
o これはネットワークのクライアントです。
o It is a server to its own northbound applications and clients, e.g., an Operations Support System (OSS).
o これは、独自のノースバウンドアプリケーションとクライアント、たとえば、運用サポートシステム（OSS）へのサーバーです。
In other words, one system's client (or controller, in this case) may be another system's server (or managed system).
つまり、あるシステムのクライアント（またはこの場合はコントローラー）が別のシステムのサーバー（または管理対象システム）になる場合があります。
In this scenario, the SDN Controller maintains a consolidated data model of multiple layers of topology. This includes the lower layers of the network topology, built from information that is discovered from the network. It also includes upper layers of topology overlay, configurable by the controller's client, i.e., the OSS. To the OSS, the lower topology layers constitute "read-only" information. The upper topology layers need to be read-writable.
このシナリオでは、SDNコントローラーは、トポロジの複数のレイヤーの統合データモデルを維持します。これには、ネットワークから検出された情報から構築された、ネットワークトポロジの下位層が含まれます。また、コントローラのクライアント、つまりOSSによって構成可能なトポロジオーバーレイの上位層も含まれます。 OSSにとって、下位のトポロジレイヤーは「読み取り専用」情報を構成します。上位トポロジレイヤーは、読み取り/書き込み可能である必要があります。
Appendix B. Companion YANG Data Models for Implementations Not Compliant with NMDA
付録B. NMDAに準拠していない実装のコンパニオンYANGデータモデル
The YANG modules defined in this document are designed to be used in conjunction with implementations that support the Network Management Datastore Architecture (NMDA) as defined in [RFC8342]. In order to allow implementations to use the data model even in cases when NMDA is not supported, the following two companion modules -- "ietf-network-state" and "ietf-network-topology-state" -- are defined; they represent the operational state of networks and network topologies, respectively. These modules mirror the "ietf-network" and "ietf-network-topology" modules (defined in Sections 6.1 and 6.2 of this document); however, in the case of these modules, all data nodes are non-configurable. They represent state that comes into being by either (1) learning topology information from the network or (2) applying configuration from the mirrored modules.
このドキュメントで定義されているYANGモジュールは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャ（NMDA）をサポートする実装と組み合わせて使用するように設計されています。 NMDAがサポートされていない場合でも実装でデータモデルを使用できるようにするために、次の2つのコンパニオンモジュール（「ietf-network-state」と「ietf-network-topology-state」）が定義されています。これらは、それぞれネットワークの動作状態とネットワークトポロジを表します。これらのモジュールは、「ietf-network」および「ietf-network-topology」モジュール（このドキュメントのセクション6.1および6.2で定義）を反映しています。ただし、これらのモジュールの場合、すべてのデータノードは構成できません。これらは、（1）ネットワークからトポロジー情報を学習するか、（2）ミラーリングされたモジュールから構成を適用することによって、実際の状態を表します。
The "ietf-network-state" and "ietf-network-topology-state" companion modules are redundant and SHOULD NOT be supported by implementations that support NMDA; therefore, we define these modules in Appendices B.1 and B.2 (below) instead of the main body of this document.
「ietf-network-state」および「ietf-network-topology-state」コンパニオンモジュールは冗長であり、NMDAをサポートする実装ではサポートされるべきではありません。したがって、これらのモジュールは、このドキュメントの本文ではなく、付録B.1およびB.2（下記）で定義します。
As the structure of both modules mirrors that of their underlying modules, the YANG tree is not depicted separately.
両方のモジュールの構造はそれらの基礎となるモジュールの構造を反映しているため、YANGツリーは個別に描かれていません。
<CODE BEGINS> file "ietf-network-state@2018-02-26.yang"
module ietf-network-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
prefix nw-s;
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
組織「IETF I2RS（ルーティングシステムへのインターフェイス）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base data model for a collection of nodes in a network. Node definitions are further used in network topologies and inventories. It represents information that either (1) is learned and automatically populated or (2) results from applying network information that has been configured per the 'ietf-network' data model, mirroring the corresponding data nodes in this data model.
説明「このモジュールは、ネットワーク内のノードのコレクションの共通ベースデータモデルを定義します。ノード定義は、ネットワークトポロジとインベントリでさらに使用されます。これは、（1）学習して自動的に入力されるか、または（2）適用の結果である情報を表します「ietf-network」データモデルごとに構成されたネットワーク情報。このデータモデルの対応するデータノードをミラーリングします。
The data model mirrors 'ietf-network' but contains only read-only state data. The data model is not needed when the underlying implementation infrastructure supports the Network Management Datastore Architecture (NMDA).
データモデルは「ietf-network」を反映していますが、読み取り専用の状態データのみが含まれています。基盤となる実装インフラストラクチャがネットワーク管理データストアアーキテクチャ（NMDA）をサポートしている場合、データモデルは必要ありません。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2018 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 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
grouping network-ref {
description
"Contains the information necessary to reference a network --
for example, an underlay network.";
leaf network-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:network-id";
require-instance false;
}
description
"Used to reference a network -- for example, an underlay
network.";
}
}
grouping node-ref {
description
"Contains the information necessary to reference a node.";
leaf node-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Used to reference a node.
Nodes are identified relative to the network that
contains them.";
}
uses network-ref;
}
container networks {
config false;
description
"Serves as a top-level container for a list of networks.";
list network {
key "network-id";
description
"Describes a network.
A network typically contains an inventory of nodes,
topological information (augmented through the
network-topology data model), and layering information.";
container network-types {
description
"Serves as an augmentation target.
The network type is indicated through corresponding
presence containers augmented into this container.";
}
leaf network-id {
type nw:network-id;
description
"Identifies a network.";
}
list supporting-network {
key "network-ref";
description
"An underlay network, used to represent layered network
topologies.";
leaf network-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:network-id";
require-instance false;
}
description
"References the underlay network.";
}
}
list node {
key "node-id";
description
"The inventory of nodes of this network.";
leaf node-id {
type nw:node-id;
description
"Uniquely identifies a node within the containing
network.";
}
list supporting-node {
key "network-ref node-ref";
description
"Represents another node that is in an underlay network
and that supports this node. Used to represent layering
structure.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-network/nw-s:network-ref";
require-instance false;
}
description
"References the underlay network of which the
underlay node is a part.";
}
leaf node-ref {
type leafref {
path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
require-instance false;
}
description
"References the underlay node itself.";
}
}
}
}
}
}
<CODE ENDS>
<コード終了>
<CODE BEGINS> file "ietf-network-topology-state@2018-02-26.yang"
module ietf-network-topology-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
prefix nt-s;
import ietf-network-state {
prefix nw-s;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
organization "IETF I2RS (Interface to the Routing System) Working Group";
組織「IETF I2RS（ルーティングシステムへのインターフェイス）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.tech>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description "This module defines a common base data model for network topology state, representing topology that either (1) is learned or (2) results from applying topology that has been configured per the 'ietf-network-topology' data model, mirroring the corresponding data nodes in this data model. It augments the base network state data model with links to connect nodes, as well as termination points to terminate links on nodes.
説明「このモジュールは、ネットワークトポロジー状態の共通ベースデータモデルを定義し、（1）が学習された、または（2）「ietf-network-topology」データモデルごとに構成されたトポロジーを適用した結果のトポロジーを反映して、このデータモデル内の対応するデータノード。これは、ノードを接続するためのリンクと、ノード上のリンクを終端するための終端点で基本ネットワーク状態データモデルを補強します。
The data model mirrors 'ietf-network-topology' but contains only read-only state data. The data model is not needed when the underlying implementation infrastructure supports the Network Management Datastore Architecture (NMDA).
データモデルは「ietf-network-topology」を反映していますが、読み取り専用の状態データのみが含まれています。基盤となる実装インフラストラクチャがネットワーク管理データストアアーキテクチャ（NMDA）をサポートしている場合、データモデルは必要ありません。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2018 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 8345;
see the RFC itself for full legal notices.";
revision 2018-02-26 {
description
"Initial revision.";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
grouping link-ref {
description
"References a link in a specific network. Although this
grouping is not used in this module, it is defined here for
the convenience of augmenting modules.";
leaf link-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nt-s:link/nt-s:link-id";
require-instance false;
}
description
"A type for an absolute reference to a link instance.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw-s:network-ref;
}
grouping tp-ref {
description
"References a termination point in a specific node. Although
this grouping is not used in this module, it is defined here
for the convenience of augmenting modules.";
leaf tp-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
"/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
"node-ref]/nt-s:termination-point/nt-s:tp-id";
require-instance false;
}
description
"A type for an absolute reference to a termination point.
(This type should not be used for relative references.
In such a case, a relative path should be used instead.)";
}
uses nw-s:node-ref;
}
augment "/nw-s:networks/nw-s:network" {
description
"Add links to the network data model.";
list link {
key "link-id";
description
"A network link connects a local (source) node and
a remote (destination) node via a set of the respective
node's termination points. It is possible to have several
links between the same source and destination nodes.
Likewise, a link could potentially be re-homed between
termination points. Therefore, in order to ensure that we
would always know to distinguish between links, every link
is identified by a dedicated link identifier. Note that a
link models a point-to-point link, not a multipoint link.";
container source {
description
"This container holds the logical source of a particular
link.";
leaf source-node {
type leafref {
path "../../../nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Source node identifier. Must be in the same topology.";
}
leaf source-tp {
type leafref {
path "../../../nw-s:node[nw-s:node-id=current()/../"+
"source-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the source node
and terminates the link.";
}
}
container destination {
description
"This container holds the logical destination of a
particular link.";
leaf dest-node {
type leafref {
path "../../../nw-s:node/nw-s:node-id";
require-instance false;
}
description
"Destination node identifier. Must be in the same
network.";
}
leaf dest-tp {
type leafref {
path "../../../nw-s:node[nw-s:node-id=current()/../"+
"dest-node]/termination-point/tp-id";
require-instance false;
}
description
"This termination point is located within the
destination node and terminates the link.";
}
}
leaf link-id {
type nt:link-id;
description
"The identifier of a link in the topology.
A link is specific to a topology to which it belongs.";
}
list supporting-link {
key "network-ref link-ref";
description
"Identifies the link or links on which this link depends.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-network/nw-s:network-ref";
require-instance false;
}
description
"This leaf identifies in which underlay topology
the supporting link is present.";
}
leaf link-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id="+
"current()/../network-ref]/link/link-id";
require-instance false;
}
description
"This leaf identifies a link that is a part
of this link's underlay. Reference loops in which
a link identifies itself as its underlay, either
directly or transitively, are not allowed.";
}
}
}
}
augment "/nw-s:networks/nw-s:network/nw-s:node" {
description
"Augments termination points that terminate links.
Termination points can ultimately be mapped to interfaces.";
list termination-point {
key "tp-id";
description
"A termination point can terminate a link.
Depending on the type of topology, a termination point
could, for example, refer to a port or an interface.";
leaf tp-id {
type nt:tp-id;
description
"Termination point identifier.";
}
list supporting-termination-point {
key "network-ref node-ref tp-ref";
description
"This list identifies any termination points on which a
given termination point depends or onto which it maps.
Those termination points will themselves be contained
in a supporting node. This dependency information can be
inferred from the dependencies between links. Therefore,
this item is not separately configurable. Hence, no
corresponding constraint needs to be articulated.
The corresponding information is simply provided by the
implementing system.";
leaf network-ref {
type leafref {
path "../../../nw-s:supporting-node/nw-s:network-ref";
require-instance false;
}
description
"This leaf identifies in which topology the
supporting termination point is present.";
}
leaf node-ref {
type leafref {
path "../../../nw-s:supporting-node/nw-s:node-ref";
require-instance false;
}
description
"This leaf identifies in which node the supporting
termination point is present.";
}
leaf tp-ref {
type leafref {
path "/nw-s:networks/nw-s:network[nw-s:network-id="+
"current()/../network-ref]/nw-s:node[nw-s:node-id="+
"current()/../node-ref]/termination-point/tp-id";
require-instance false;
}
description
"Reference to the underlay node (the underlay node must
be in a different topology).";
}
}
}
}
}
<CODE ENDS>
<コード終了>
This section contains an example of an instance data tree in JSON encoding [RFC7951]. The example instantiates "ietf-network-topology" (and "ietf-network", which "ietf-network-topology" augments) for the topology depicted in Figure 7. There are three nodes: D1, D2, and D3. D1 has three termination points (1-0-1, 1-2-1, and 1-3-1). D2 has three termination points as well (2-1-1, 2-0-1, and 2-3-1). D3 has two termination points (3-1-1 and 3-2-1). In addition, there are six links, two between each pair of nodes with one going in each direction.
このセクションには、JSONエンコード[RFC7951]のインスタンスデータツリーの例が含まれています。この例では、図7に示すトポロジの「ietf-network-topology」（および「ietf-network-topology」が拡張する「ietf-network」）をインスタンス化します。D1、D2、およびD3の3つのノードがあります。 D1には3つの終端ポイントがあります（1-0-1、1-2-1、および1-3-1）。 D2にも3つの終端ポイントがあります（2-1-1、2-0-1、および2-3-1）。 D3には2つの終端ポイントがあります（3-1-1および3-2-1）。さらに、6つのリンクがあり、ノードの各ペア間に2つ、各方向に1つずつあります。
+------------+ +------------+
| D1 | | D2 |
/-\ /-\ /-\ /-\
| | 1-0-1 | |---------------->| | 2-1-1 | |
| | 1-2-1 | |<----------------| | 2-0-1 | |
\-/ 1-3-1 \-/ \-/ 2-3-1 \-/
| /----\ | | /----\ |
+---| |---+ +---| |---+
\----/ \----/
A | A |
| | | |
| | | |
| | +------------+ | |
| | | D3 | | |
| | /-\ /-\ | |
| +----->| | 3-1-1 | |-------+ |
+---------| | 3-2-1 | |<---------+
\-/ \-/
| |
+------------+
Figure 7: A Network Topology Example
図7：ネットワークトポロジの例
The corresponding instance data tree is depicted in Figure 8:
対応するインスタンスデータツリーを図8に示します。
{
"ietf-network:networks": {
"network": [
{
"network-types": {
},
"network-id": "otn-hc",
"node": [
{
"node-id": "D1",
"termination-point": [
{
"tp-id": "1-0-1"
},
{
"tp-id": "1-2-1"
},
{
"tp-id": "1-3-1"
}
]
},
{
"node-id": "D2",
"termination-point": [
{
"tp-id": "2-0-1"
},
{
"tp-id": "2-1-1"
},
{
"tp-id": "2-3-1"
}
]
},
{
"node-id": "D3",
"termination-point": [
{
"tp-id": "3-1-1"
},
{
"tp-id": "3-2-1"
}
]
}
],
"ietf-network-topology:link": [
{
"link-id": "D1,1-2-1,D2,2-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-1-1"
}
},
{
"link-id": "D2,2-1-1,D1,1-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-2-1"
}
},
{
"link-id": "D1,1-3-1,D3,3-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-3-1"
}
"destination": {
"dest-node": "D3",
"dest-tp": "3-1-1"
}
},
{
"link-id": "D3,3-1-1,D1,1-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-1-1"
}
"destination": {
"dest-node": "D1",
"dest-tp": "1-3-1"
}
},
{
"link-id": "D2,2-3-1,D3,3-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-3-1"
}
"destination": {
"dest-node": "D3",
"dest-tp": "3-2-1"
}
},
{
"link-id": "D3,3-2-1,D2,2-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-2-1"
}
"destination": {
"dest-node": "D2",
"dest-tp": "2-3-1"
}
}
]
}
]
}
}
Figure 8: Instance Data Tree
図8：インスタンスデータツリー
Acknowledgments
謝辞
We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Alia Atlas, Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, Qin Wu, and Xian Zhang.
Alia Atlas、Andy Bierman、Martin Bjorklund、Igor Bryskin、Benoit Claise、Susan Hares、Ladislav Lhotka、Carlos Pignataro、Juergen Schoenwaelder、Robert Wilton、Qin Wu、および西安張。
Contributors
貢献者
More people contributed to the data model presented in this paper than can be listed in the "Authors' Addresses" section. Additional contributors include:
この文書で提示されているデータモデルには、「著者のアドレス」セクションに記載されているよりも多くの人々が貢献しました。追加の貢献者は次のとおりです。
o Vishnu Pavan Beeram, Juniper
o Vishnu Pavan Beeram、ジュニパー
o Ken Gray, Cisco
o ケン・グレイ、シスコ
o Tom Nadeau, Brocade
o トム・ナドー、ブロケード
o Tony Tkacik
o トニー・トック
o Kent Watsen, Juniper
o ジュニパーのケントワッセン
o Aleksandr Zhdankin, Cisco
o Alexander Zhdankin、Cisco
Authors' Addresses
著者のアドレス
Alexander Clemm Huawei USA - Futurewei Technologies Inc. Santa Clara, CA United States of America
Alexander Clemm Huawei USA-Futurewei Technologies Inc.カリフォルニア州サンタクララアメリカ合衆国
Email: ludwig@clemm.org, alexander.clemm@huawei.com
Jan Medved Cisco
Jan Medved Cisco
Email: jmedved@cisco.com
Robert Varga Pantheon Technologies SRO
Robert Varga Pantheon Technologies SRO
Email: robert.varga@pantheon.tech
Nitin Bahadur Bracket Computing
Nitin Bahadurブラケットコンピューティング
Email: nitin_bahadur@yahoo.com
Hariharan Ananthakrishnan Packet Design
Hariharan Ananthakrishnanパケットデザイン
Email: hari@packetdesign.com
Xufeng Liu Jabil
X U Feng L IU JA比率
Email: xufeng.liu.ietf@gmail.com