[要約] RFC 8343は、インターフェース管理のためのYANGデータモデルを提供するものであり、ネットワークデバイスのインターフェースの設定と監視を効率化することを目的としています。
Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 8343 Tail-f Systems
Obsoletes: 7223 March 2018
Category: Standards Track
ISSN: 2070-1721
A YANG Data Model for Interface Management
インターフェース管理のためのYANGデータモデル
Abstract
概要
This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).
このドキュメントは、ネットワークインターフェースの管理のためのYANGデータモデルを定義します。インターフェイスタイプ固有のデータモデルは、このドキュメントで定義されている一般的なインターフェイスデータモデルを補強することが期待されています。データモデルには、構成とシステム状態の定義（統計情報の収集のためのステータス情報とカウンター）が含まれます。
The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
このドキュメントのYANGデータモデルは、RFC 8342で定義されているネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。
This document obsoletes RFC 7223.
このドキュメントはRFC 7223を廃止します。
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/rfc8343.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8343で入手できます。
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 ....................................................3
1.1. Summary of Changes from RFC 7223 ...........................3
1.2. Terminology ................................................3
1.3. Tree Diagrams ..............................................4
2. Objectives ......................................................5
3. Interfaces Data Model ...........................................5
3.1. The Interface List .........................................6
3.2. Interface References .......................................8
3.3. Interface Layering .........................................8
4. Relationship to the IF-MIB ......................................9
5. Interfaces YANG Module .........................................10
6. IANA Considerations ............................................34
7. Security Considerations ........................................35
8. References .....................................................36
8.1. Normative References ......................................36
8.2. Informative References ....................................37
Appendix A. Example: Ethernet Interface Module ...................38
Appendix B. Example: Ethernet Bonding Interface Module ...........39
Appendix C. Example: VLAN Interface Module .......................40
Appendix D. Example: NETCONF <get-config> Reply ..................41
Appendix E. Example: NETCONF <get-data> Reply ....................42
Appendix F. Examples: Interface Naming Schemes ...................44
F.1. Router with Restricted Interface Names ....................44
F.2. Router with Arbitrary Interface Names .....................45
F.3. Ethernet Switch with Restricted Interface Names ...........46
F.4. Generic Host with Restricted Interface Names ..............47
F.5. Generic Host with Arbitrary Interface Names ...............48
Acknowledgments ...................................................49
Author's Address ..................................................49
This document defines a YANG data model [RFC7950] for the management of network interfaces. It is expected that interface-type-specific data models will augment the generic interfaces data model defined in this document.
このドキュメントは、ネットワークインターフェースの管理のためのYANGデータモデル[RFC7950]を定義します。インターフェイスタイプ固有のデータモデルは、このドキュメントで定義されている一般的なインターフェイスデータモデルを補強することが期待されています。
Network interfaces are central to the management of many Internet protocols. Thus, it is important to establish a common data model for how interfaces are identified, configured, and monitored.
ネットワークインターフェイスは、多くのインターネットプロトコルの管理の中核です。したがって、インターフェースの識別、構成、および監視方法に関する共通のデータモデルを確立することが重要です。
The data model includes configuration data and state data (status information and counters for the collection of statistics).
データモデルには、構成データと状態データ（統計情報を収集するためのステータス情報とカウンター）が含まれます。
This version of the interfaces data model supports the Network Management Datastore Architecture (NMDA) [RFC8342].
このバージョンのインターフェースデータモデルは、ネットワーク管理データストアアーキテクチャ（NMDA）[RFC8342]をサポートしています。
The "/interfaces-state" subtree with "config false" data nodes is deprecated. All "config false" data nodes are now present in the "/interfaces" subtree.
「config false」データノードを持つ「/ interfaces-state」サブツリーは非推奨になりました。すべての「config false」データノードが「/ interfaces」サブツリーに存在するようになりました。
Servers that do not implement NMDA, or that wish to support clients that do not implement NMDA, MAY implement the deprecated "/interfaces-state" tree.
NMDAを実装していないサーバー、またはNMDAを実装していないクライアントをサポートしたいサーバーは、非推奨の「/ interfaces-state」ツリーを実装できます（MAY）。
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]で説明されているように解釈されます。
The following terms are used within this document:
このドキュメントでは、次の用語が使用されています。
o system-controlled interface: An interface is said to be system-controlled if the system creates and deletes the interface independently of what has been explicitly configured. Examples are interfaces representing physical hardware that appear and disappear when hardware (e.g., a line card or hot-pluggable wireless interface) is added or removed. System-controlled interfaces may also appear if a certain functionality is enabled (e.g., a loopback interface might appear if the IP protocol stack is enabled).
o システム制御インターフェース：明示的に構成されたものとは無関係にシステムがインターフェースを作成および削除する場合、インターフェースはシステム制御であると言います。例としては、ハードウェア（ラインカードやホットプラグ可能なワイヤレスインターフェイスなど）が追加または削除されると表示および非表示になる物理ハードウェアを表すインターフェイスがあります。システム制御のインターフェースは、特定の機能が有効になっている場合にも表示されることがあります（たとえば、IPプロトコルスタックが有効になっている場合、ループバックインターフェースが表示されることがあります）。
o user-controlled interface: An interface is said to be user-controlled if the creation of the interface is controlled by adding explicit interface configuration to the intended configuration and the removal of the interface is controlled by removing explicit interface configuration from the intended configuration. Examples are VLAN interfaces configured on a system-controlled Ethernet interface.
o ユーザー制御インターフェース：意図した構成に明示的なインターフェース構成を追加してインターフェースの作成を制御し、意図した構成から明示的なインターフェース構成を削除してインターフェースの削除を制御する場合、インターフェースはユーザー制御であるといいます。例は、システム制御のイーサネットインターフェイスに設定されたVLANインターフェイスです。
The following terms are defined in [RFC8342] and are not redefined here:
以下の用語は[RFC8342]で定義されており、ここでは再定義されません。
o client
o クライアント
o server
o サーバ
o configuration
o 構成
o system state
o システム状態
o operational state
o 稼働状態
o intended configuration
o 意図した構成
o running configuration datastore
o 実行構成データストア
o operational state datastore
o 運用状態データストア
The following terms are defined in [RFC7950] and are not redefined here:
以下の用語は[RFC7950]で定義されており、ここでは再定義されません。
o augment
o 増強
o data model
o データ・モデル
o data node
o だた ので
Tree diagrams used in this document follow the notation defined in [RFC8340].
このドキュメントで使用されるツリー図は、[RFC8340]で定義された表記に従います。
This section describes some of the design objectives for the model presented in Section 5.
このセクションでは、セクション5で示したモデルの設計目標のいくつかについて説明します。
o It is recognized that existing implementations will have to map the interface data model defined in this memo to their proprietary native data model. To facilitate such mappings, the data model should be simple.
o 既存の実装では、このメモで定義されたインターフェースデータモデルを独自のネイティブデータモデルにマップする必要があることが認識されています。このようなマッピングを容易にするために、データモデルは単純である必要があります。
o The data model should be suitable for new implementations to use as is, without requiring a mapping to a different native model.
o データモデルは、別のネイティブモデルへのマッピングを必要とせずに、新しい実装をそのまま使用するのに適している必要があります。
o References to interfaces should be as simple as possible, preferably by using a single leafref.
o インターフェースへの参照は、できれば単一のleafrefを使用することにより、可能な限りシンプルにする必要があります。
o The mapping to ifIndex [RFC2863] used by the Simple Network Management Protocol (SNMP) to identify interfaces must be clear.
o インターフェイスを識別するために簡易ネットワーク管理プロトコル（SNMP）が使用するifIndex [RFC2863]へのマッピングは明確でなければなりません。
o The model must support interface layering: both (1) simple layering, where one interface is layered on top of exactly one other interface, and (2) more complex scenarios, where one interface results from the aggregation of N other interfaces or when N interfaces are multiplexed over one other interface.
o モデルは、インターフェイスの階層化をサポートする必要があります。（1）1つのインターフェイスが他の1つのインターフェイスの上に階層化される単純な階層化と、（2）1つのインターフェイスが他のN個のインターフェイスの集約から生じる、またはN個のインターフェイスがある場合のより複雑なシナリオ他の1つのインターフェースで多重化されます。
o The data model should support the pre-provisioning of interface configuration; that is, it should be possible to configure an interface whose physical interface hardware is not present on the device. It is recommended that devices that support dynamic addition and removal of physical interfaces also support pre-provisioning.
o データモデルは、インターフェース構成の事前プロビジョニングをサポートする必要があります。つまり、物理インターフェイスハードウェアがデバイス上に存在しないインターフェイスを設定できるはずです。物理インターフェイスの動的な追加と削除をサポートするデバイスは、事前プロビジョニングもサポートすることをお勧めします。
o The data model should support physical interfaces as well as logical interfaces.
o データモデルは、物理インターフェイスと論理インターフェイスをサポートする必要があります。
o The data model should include read-only counters in order to gather statistics for sent and received octets and packets, received packets with errors, and packets that could not be sent due to errors.
o データモデルには、送受信オクテットとパケット、エラーのある受信パケット、およびエラーが原因で送信できなかったパケットの統計を収集するために、読み取り専用カウンターを含める必要があります。
This document defines the YANG module "ietf-interfaces", which has
the following structure, excluding the deprecated "/interfaces-state"
subtree:
module: ietf-interfaces
+--rw interfaces
+--rw interface* [name]
+--rw name string
+--rw description? string
+--rw type identityref
+--rw enabled? boolean
+--rw link-up-down-trap-enable? enumeration {if-mib}?
+--ro admin-status enumeration {if-mib}?
+--ro oper-status enumeration
+--ro last-change? yang:date-and-time
+--ro if-index int32 {if-mib}?
+--ro phys-address? yang:phys-address
+--ro higher-layer-if* interface-ref
+--ro lower-layer-if* interface-ref
+--ro speed? yang:gauge64
+--ro statistics
+--ro discontinuity-time yang:date-and-time
+--ro in-octets? yang:counter64
+--ro in-unicast-pkts? yang:counter64
+--ro in-broadcast-pkts? yang:counter64
+--ro in-multicast-pkts? yang:counter64
+--ro in-discards? yang:counter32
+--ro in-errors? yang:counter32
+--ro in-unknown-protos? yang:counter32
+--ro out-octets? yang:counter64
+--ro out-unicast-pkts? yang:counter64
+--ro out-broadcast-pkts? yang:counter64
+--ro out-multicast-pkts? yang:counter64
+--ro out-discards? yang:counter32
+--ro out-errors? yang:counter32
The data model for interfaces presented in this document uses a flat list of interfaces ("/interfaces/interface"). Each interface in the list is identified by its name. Furthermore, each interface has a mandatory "type" leaf.
このドキュメントで紹介するインターフェースのデータモデルでは、インターフェースのフラットリスト（ "/ interfaces / interface"）を使用しています。リスト内の各インターフェースは、その名前で識別されます。さらに、各インターフェースには必須の「タイプ」リーフがあります。
The "iana-if-type" module [RFC7224] defines YANG identities for the interface types in the IANA-maintained "ifType definitions" registry.
「iana-if-type」モジュール[RFC7224]は、IANAが管理する「ifType定義」レジストリでインターフェースタイプのYANG IDを定義します。
It is expected that interface-type-specific data models augment the interface list and possibly use the "type" leaf to make the augmentation conditional.
インターフェースタイプ固有のデータモデルがインターフェースリストを拡張し、「タイプ」リーフを使用して拡張を条件付きにすることが期待されます。
As an example of such an interface-type-specific augmentation, consider this YANG snippet. For a more complete example, see Appendix A.
このようなインターフェースタイプ固有の拡張の例として、このYANGスニペットを考えてみましょう。より完全な例については、付録Aを参照してください。
import interfaces {
prefix "if";
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
leaf duplex {
...
}
}
}
For system-controlled interfaces, the "name" is the device-specific name of the interface.
システム制御のインターフェースの場合、「名前」はインターフェースのデバイス固有の名前です。
If the device supports arbitrarily named user-controlled interfaces, then the server will advertise the "arbitrary-names" feature. If the server does not advertise this feature, the names of user-controlled interfaces MUST match the device's naming scheme. How a client can learn the naming scheme of such devices is outside the scope of this document. See Appendices F.1 and F.2 for examples.
デバイスが任意の名前のユーザー制御インターフェースをサポートしている場合、サーバーは「任意の名前」機能をアドバタイズします。サーバーがこの機能をアドバタイズしない場合、ユーザー制御のインターフェースの名前は、デバイスの命名方式と一致する必要があります。クライアントがこのようなデバイスの命名方式を学習する方法は、このドキュメントの範囲外です。例については、付録F.1およびF.2を参照してください。
When a system-controlled interface is created in the operational state by the system, the system tries to apply the interface configuration in the intended configuration with the same name as the new interface. If no such interface configuration is found, or if the configured type does not match the real interface type, the system creates the interface without applying explicit configuration.
システム制御のインターフェースがシステムによって操作可能な状態で作成されると、システムは、新しいインターフェースと同じ名前の意図された構成にインターフェース構成を適用しようとします。そのようなインターフェイス設定が見つからない場合、または設定されたタイプが実際のインターフェイスタイプと一致しない場合、システムは明示的な設定を適用せずにインターフェイスを作成します。
When a user-controlled interface is created, the configuration determines the name of the interface.
ユーザー制御のインターフェースが作成されると、構成によってインターフェースの名前が決まります。
Depending on the operating system and the physical attachment point to which a network interface may be attached or removed, it may be impossible for an implementation to provide predictable and consistent names for system-controlled interfaces across insertion/ removal cycles as well as in anticipation of initial insertion. The ability to provide configurations for such interfaces is therefore dependent on the implementation and cannot be assumed in all cases.
オペレーティングシステムと、ネットワークインターフェイスが接続または削除される可能性のある物理的な接続ポイントによっては、実装がシステム制御のインターフェイスに予測可能な一貫性のある名前を挿入/削除サイクル全体で提供することや、最初の挿入。したがって、そのようなインターフェースの構成を提供する機能は実装に依存し、すべてのケースで想定できるわけではありません。
An interface is identified by its name, which is unique within the server. This property is captured in the "interface-ref" typedef, which other YANG modules SHOULD use when they need to reference an interface.
インターフェイスは、サーバー内で一意の名前で識別されます。このプロパティは、 "interface-ref" typedefにキャプチャされます。他のYANGモジュールは、インターフェイスを参照する必要があるときに使用する必要があります。
There is no generic mechanism for how an interface is configured to be layered on top of some other interface. It is expected that interface-type-specific models define their own data nodes for interface layering by using "interface-ref" types to reference lower layers.
インターフェイスを他のインターフェイスの上に重ねるように設定するための一般的なメカニズムはありません。インターフェースタイプ固有のモデルは、「インターフェース参照」タイプを使用して下位レイヤーを参照することにより、インターフェースレイヤー用に独自のデータノードを定義することが期待されます。
Below is an example of a model with such nodes. For a more complete example, see Appendix B.
以下は、そのようなノードを持つモデルの例です。より完全な例については、付録Bを参照してください。
import interfaces {
prefix "if";
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ieee8023adLag'";
leaf-list slave-if {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'ianaift:ethernetCsmacd'" {
description
"The type of a slave interface must be
'ethernetCsmacd'.";
}
}
// other bonding config params, failover times, etc.
}
While the interface layering is configured in interface-type-specific models, two generic state data leaf-lists, "higher-layer-if" and "lower-layer-if", represent a read-only view of the interface layering hierarchy.
インターフェイスレイヤーはインターフェイスタイプ固有のモデルで構成されますが、2つの一般的な状態データのリーフリスト「higher-layer-if」と「lower-layer-if」は、インターフェイスレイヤー階層の読み取り専用ビューを表します。
If the device implements the IF-MIB [RFC2863], each entry in the "/interfaces/interface" list in the operational state is typically mapped to one ifEntry. The "if-index" leaf MUST contain the value of the corresponding ifEntry's ifIndex.
デバイスがIF-MIB [RFC2863]を実装している場合、動作状態の「/ interfaces / interface」リストの各エントリは通常、1つのifEntryにマッピングされます。 「if-index」リーフには、対応するifEntryのifIndexの値が含まれている必要があります。
In most cases, the "name" of an "/interfaces/interface" entry is mapped to ifName. The IF-MIB allows two different ifEntries to have the same ifName. Devices that support this feature and also support the data model defined in this document cannot have a 1-1 mapping between the "name" leaf and ifName.
ほとんどの場合、「/ interfaces / interface」エントリの「名前」はifNameにマッピングされます。 IF-MIBでは、2つの異なるifEntriesが同じifNameを持つことができます。この機能をサポートし、このドキュメントで定義されているデータモデルもサポートするデバイスは、「name」リーフとifNameを1-1でマッピングできません。
The configured "description" of an "interface" has traditionally been mapped to ifAlias in some implementations. This document allows this mapping, but implementers should be aware of the differences in the value space and persistence for these objects. See the YANG module definition of the leaf "description" in Section 5 for details.
「インターフェース」の構成された「説明」は、一部の実装では伝統的にifAliasにマップされていました。このドキュメントではこのマッピングを許可していますが、実装者はこれらのオブジェクトの値空間と永続性の違いに注意する必要があります。詳細については、セクション5のリーフ「説明」のYANGモジュール定義を参照してください。
The IF-MIB also defines the writable object ifPromiscuousMode. Since this object typically is not implemented as a configuration object by SNMP agents, it is not mapped to the "ietf-interfaces" module.
IF-MIBは、書き込み可能なオブジェクトifPromiscuousModeも定義します。このオブジェクトは通常、SNMPエージェントによって構成オブジェクトとして実装されていないため、「ietf-interfaces」モジュールにマップされません。
The ifMtu object from the IF-MIB is not mapped to the "ietf-interfaces" module. It is expected that interface-type-specific YANG modules provide interface-type-specific MTU leafs by augmenting the "ietf-interfaces" model.
IF-MIBのifMtuオブジェクトは、「ietf-interfaces」モジュールにマップされていません。インターフェースタイプ固有のYANGモジュールは、「ietf-interfaces」モデルを拡張することにより、インターフェースタイプ固有のMTUリーフを提供することが期待されています。
There are a number of counters in the IF-MIB that exist in two versions: one with 32 bits and one with 64 bits. The 64-bit versions were added to support high-speed interfaces with a data rate greater than 20,000,000 bits/second. Today's implementations generally support such high-speed interfaces; hence, only 64-bit counters are provided in this data model. Note that the server that implements this module and an SNMP agent may differ in the time granularity in which they provide access to the counters. For example, it is common that SNMP implementations cache counter values for some time.
IF-MIBには、32ビットと64ビットの2つのバージョンに存在する多数のカウンターがあります。 64ビットバージョンは、20,000,000ビット/秒を超えるデータレートの高速インターフェイスをサポートするために追加されました。今日の実装は、一般にそのような高速インターフェースをサポートしています。したがって、このデータモデルでは64ビットカウンターのみが提供されます。このモジュールを実装するサーバーとSNMPエージェントは、カウンターへのアクセスを提供する時間の細かさが異なる場合があることに注意してください。たとえば、SNMP実装では、しばらくの間カウンタ値をキャッシュするのが一般的です。
The objects ifDescr and ifConnectorPresent from the IF-MIB are not mapped to the "ietf-interfaces" module.
IF-MIBのオブジェクトifDescrおよびifConnectorPresentは、「ietf-interfaces」モジュールにマップされません。
The following table lists the YANG data nodes with corresponding objects in the IF-MIB.
次の表に、IF-MIB内の対応するオブジェクトを含むYANGデータノードを示します。
+--------------------------------------+----------------------------+
| YANG data node in | IF-MIB object |
| /interfaces/interface | |
+--------------------------------------+----------------------------+
| name | ifName |
| type | ifType |
| description | ifAlias |
| admin-status | ifAdminStatus |
| oper-status | ifOperStatus |
| last-change | ifLastChange |
| if-index | ifIndex |
| link-up-down-trap-enable | ifLinkUpDownTrapEnable |
| phys-address | ifPhysAddress |
| higher-layer-if and lower-layer-if | ifStackTable |
| speed | ifSpeed and ifHighSpeed |
| discontinuity-time | ifCounterDiscontinuityTime |
| in-octets | ifHCInOctets |
| in-unicast-pkts | ifHCInUcastPkts |
| in-broadcast-pkts | ifHCInBroadcastPkts |
| in-multicast-pkts | ifHCInMulticastPkts |
| in-discards | ifInDiscards |
| in-errors | ifInErrors |
| in-unknown-protos | ifInUnknownProtos |
| out-octets | ifHCOutOctets |
| out-unicast-pkts | ifHCOutUcastPkts |
| out-broadcast-pkts | ifHCOutBroadcastPkts |
| out-multicast-pkts | ifHCOutMulticastPkts |
| out-discards | ifOutDiscards |
| out-errors | ifOutErrors |
+--------------------------------------+----------------------------+
YANG Data Nodes and Related IF-MIB Objects
YANGデータノードと関連するIF-MIBオブジェクト
This YANG module imports typedefs from [RFC6991].
このYANGモジュールは、[RFC6991]からtypedefをインポートします。
<CODE BEGINS> file "ietf-interfaces@2018-02-20.yang"
module ietf-interfaces {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if;
import ietf-yang-types {
prefix yang;
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>";
description "This module contains a collection of YANG definitions for managing network interfaces.
説明「このモジュールには、ネットワークインターフェースを管理するためのYANG定義のコレクションが含まれています。
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 8343; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 8343の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2018-02-20 {
description
"Updated to support NMDA.";
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
revision 2014-05-08 {
description
"Initial revision.";
reference
"RFC 7223: A YANG Data Model for Interface Management";
}
/*
* Typedefs
*/
typedef interface-ref {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
description
"This type is used by data models that need to reference
interfaces.";
}
/*
* Identities
*/
identity interface-type {
description
"Base identity from which specific interface types are
derived.";
}
/*
* Features
*/
feature arbitrary-names {
description
"This feature indicates that the device allows user-controlled
interfaces to be named arbitrarily.";
}
feature pre-provisioning {
description
"This feature indicates that the device supports
pre-provisioning of interface configuration, i.e., it is
possible to configure an interface whose physical interface
hardware is not present on the device.";
}
feature if-mib {
description
"This feature indicates that the device implements
the IF-MIB.";
reference
"RFC 2863: The Interfaces Group MIB";
}
/*
* Data nodes
*/
container interfaces {
description
"Interface parameters.";
list interface {
key "name";
description "The list of interfaces on the device.
説明 "デバイス上のインターフェースのリスト。
The status of an interface is available in this list in the operational state. If the configuration of a system-controlled interface cannot be used by the system (e.g., the interface hardware present does not match the interface type), then the configuration is not applied to the system-controlled interface shown in the operational state. If the configuration of a user-controlled interface cannot be used by the system, the configured interface is not instantiated in the operational state.
インターフェイスのステータスは、動作状態のこのリストに表示されます。システムが制御するインターフェースの構成をシステムが使用できない場合（たとえば、存在するインターフェースハードウェアがインターフェースタイプと一致しない場合）、構成は動作状態で表示されるシステム制御のインターフェースには適用されません。システムがユーザー制御インターフェースの構成を使用できない場合、構成されたインターフェースは稼働状態でインスタンス化されません。
System-controlled interfaces created by the system are always present in this list in the operational state, whether or not they are configured.";
システムによって作成されたシステム制御のインターフェイスは、構成されているかどうかに関係なく、動作状態のこのリストに常に存在します。 ";
leaf name {
type string;
description
"The name of the interface.
A device MAY restrict the allowed values for this leaf, possibly depending on the type of the interface. For system-controlled interfaces, this leaf is the device-specific name of the interface.
デバイスは、おそらくインターフェースのタイプに応じて、このリーフに許可される値を制限してもよい（MAY）。システム制御のインターフェースの場合、このリーフはインターフェースのデバイス固有の名前です。
If a client tries to create configuration for a system-controlled interface that is not present in the operational state, the server MAY reject the request if the implementation does not support pre-provisioning of interfaces or if the name refers to an interface that can never exist in the system. A Network Configuration Protocol (NETCONF) server MUST reply with an rpc-error with the error-tag 'invalid-value' in this case.
動作状態にないシステム制御インターフェースの構成をクライアントが作成しようとした場合、実装がインターフェースの事前プロビジョニングをサポートしていない場合、または名前が参照できないインターフェースを参照している場合、サーバーはリクエストを拒否することができます（MAY）。システムに存在します。この場合、ネットワーク構成プロトコル（NETCONF）サーバーは、rpc-errorでエラータグ 'invalid-value'を返信する必要があります。
If the device supports pre-provisioning of interface configuration, the 'pre-provisioning' feature is advertised.
デバイスがインターフェイス構成の事前プロビジョニングをサポートしている場合、「事前プロビジョニング」機能がアドバタイズされます。
If the device allows arbitrarily named user-controlled interfaces, the 'arbitrary-names' feature is advertised.
デバイスが任意の名前のユーザー制御インターフェイスを許可している場合、「任意の名前」機能がアドバタイズされます。
When a configured user-controlled interface is created by the system, it is instantiated with the same name in the operational state.
構成されたユーザー制御インターフェースがシステムによって作成されると、操作状態で同じ名前でインスタンス化されます。
A server implementation MAY map this leaf to the ifName
MIB object. Such an implementation needs to use some
mechanism to handle the differences in size and characters
allowed between this leaf and ifName. The definition of
such a mechanism is outside the scope of this document.";
reference
"RFC 2863: The Interfaces Group MIB - ifName";
}
leaf description {
type string;
description
"A textual description of the interface.
A server implementation MAY map this leaf to the ifAlias MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and ifAlias. The definition of such a mechanism is outside the scope of this document.
サーバー実装は、このリーフをifAlias MIBオブジェクトにマップしてもよい（MAY）。このような実装では、このリーフとifAliasの間で許可されるサイズと文字の違いを処理するために、何らかのメカニズムを使用する必要があります。このようなメカニズムの定義は、このドキュメントの範囲外です。
Since ifAlias is defined to be stored in non-volatile
storage, the MIB implementation MUST map ifAlias to the
value of 'description' in the persistently stored
configuration.";
reference
"RFC 2863: The Interfaces Group MIB - ifAlias";
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
description
"The type of the interface.
When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface.
インターフェースエントリが作成されると、サーバーはタイプリーフを有効な値で初期化できます（例：インターフェースの名前からタイプを導出できる場合）。
If a client tries to set the type of an interface to a
value that can never be used by the system, e.g., if the
type is not supported or if the type does not match the
name of the interface, the server MUST reject the request.
A NETCONF server MUST reply with an rpc-error with the
error-tag 'invalid-value' in this case.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
}
leaf enabled {
type boolean;
default "true";
description
"This leaf contains the configured, desired state of the
interface.
Systems that implement the IF-MIB use the value of this leaf in the intended configuration to set IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry has been initialized, as described in RFC 2863.
IF-MIBを実装するシステムは、RFC 2863で説明されているように、ifEntryが初期化された後、意図した構成でこのリーフの値を使用してIF-MIB.ifAdminStatusを「up」または「down」に設定します。
Changes in this leaf in the intended configuration are
reflected in ifAdminStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus";
}
leaf link-up-down-trap-enable {
if-feature if-mib;
type enumeration {
enum enabled {
value 1;
description
"The device will generate linkUp/linkDown SNMP
notifications for this interface.";
}
enum disabled {
value 2;
description
"The device will not generate linkUp/linkDown SNMP
notifications for this interface.";
}
}
description
"Controls whether linkUp/linkDown SNMP notifications
should be generated for this interface.
If this node is not configured, the value 'enabled' is
operationally used by the server for interfaces that do
not operate on top of any other interface (i.e., there are
no 'lower-layer-if' entries), and 'disabled' otherwise.";
reference
"RFC 2863: The Interfaces Group MIB -
ifLinkUpDownTrapEnable";
}
leaf admin-status {
if-feature if-mib;
type enumeration {
enum up {
value 1;
description
"Ready to pass packets.";
}
enum down {
value 2;
description
"Not ready to pass packets and not in some test mode.";
}
enum testing {
value 3;
description
"In some test mode.";
}
}
config false;
mandatory true;
description
"The desired state of the interface.
This leaf has the same read semantics as ifAdminStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus";
}
leaf oper-status {
type enumeration {
enum up {
value 1;
description
"Ready to pass packets.";
}
enum down {
value 2;
description
"The interface does not pass any packets.";
}
enum testing {
value 3;
description
"In some test mode. No operational packets can
be passed.";
}
enum unknown {
value 4;
description
"Status cannot be determined for some reason.";
}
enum dormant {
value 5;
description
"Waiting for some external event.";
}
enum not-present {
value 6;
description
"Some component (typically hardware) is missing.";
}
enum lower-layer-down {
value 7;
description
"Down due to state of lower-layer interface(s).";
}
}
config false;
mandatory true;
description
"The current operational state of the interface.
This leaf has the same semantics as ifOperStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifOperStatus";
}
leaf last-change {
type yang:date-and-time;
config false;
description
"The time the interface entered its current operational
state. If the current state was entered prior to the
last re-initialization of the local network management
subsystem, then this node is not present.";
reference
"RFC 2863: The Interfaces Group MIB - ifLastChange";
}
leaf if-index {
if-feature if-mib;
type int32 {
range "1..2147483647";
}
config false;
mandatory true;
description
"The ifIndex value for the ifEntry represented by this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifIndex";
}
leaf phys-address {
type yang:phys-address;
config false;
description
"The interface's address at its protocol sub-layer. For
example, for an 802.x interface, this object normally
contains a Media Access Control (MAC) address. The
interface's media-specific modules must define the bit
and byte ordering and the format of the value of this
object. For interfaces that do not have such an address
(e.g., a serial line), this node is not present.";
reference
"RFC 2863: The Interfaces Group MIB - ifPhysAddress";
}
leaf-list higher-layer-if {
type interface-ref;
config false;
description
"A list of references to interfaces layered on top of this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf-list lower-layer-if {
type interface-ref;
config false;
description
"A list of references to interfaces layered underneath this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf speed {
type yang:gauge64;
units "bits/second";
config false;
description
"An estimate of the interface's current bandwidth in bits
per second. For interfaces that do not vary in
bandwidth or for those where no accurate estimation can
be made, this node should contain the nominal bandwidth.
For interfaces that have no concept of bandwidth, this
node is not present.";
reference
"RFC 2863: The Interfaces Group MIB -
ifSpeed, ifHighSpeed";
}
container statistics {
config false;
description
"A collection of interface-related statistics objects.";
leaf discontinuity-time {
type yang:date-and-time;
mandatory true;
description
"The time on the most recent occasion at which any one or
more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management
subsystem, then this node contains the time the local
management subsystem re-initialized itself.";
}
leaf in-octets {
type yang:counter64;
description
"The total number of octets received on the interface,
including framing characters.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCInOctets";
}
leaf in-unicast-pkts {
type yang:counter64;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were not addressed to a
multicast or broadcast address at this sub-layer.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
}
leaf in-broadcast-pkts {
type yang:counter64;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were addressed to a broadcast
address at this sub-layer.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCInBroadcastPkts";
}
leaf in-multicast-pkts {
type yang:counter64;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were addressed to a multicast
address at this sub-layer. For a MAC-layer protocol,
this includes both Group and Functional addresses.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCInMulticastPkts";
}
leaf in-discards {
type yang:counter32;
description
"The number of inbound packets that were chosen to be
discarded even though no errors had been detected to
prevent their being deliverable to a higher-layer
protocol. One possible reason for discarding such a
packet could be to free up buffer space.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInDiscards";
}
leaf in-errors {
type yang:counter32;
description
"For packet-oriented interfaces, the number of inbound
packets that contained errors preventing them from being
deliverable to a higher-layer protocol. For character-
oriented or fixed-length interfaces, the number of
inbound transmission units that contained errors
preventing them from being deliverable to a higher-layer
protocol.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInErrors";
}
leaf in-unknown-protos {
type yang:counter32;
description "For packet-oriented interfaces, the number of packets received via the interface that were discarded because of an unknown or unsupported protocol. For character-oriented or fixed-length interfaces that support protocol multiplexing, the number of transmission units received via the interface that were discarded because of an unknown or unsupported protocol. For any interface that does not support protocol multiplexing, this counter is not present.
説明「パケット指向のインターフェースの場合、不明またはサポートされていないプロトコルのために破棄された、インターフェースを介して受信されたパケットの数。プロトコルの多重化をサポートする文字指向または固定長のインターフェースの場合、インターフェースを介して受信された伝送ユニットの数プロトコルが不明またはサポートされていないために破棄されましたプロトコルの多重化をサポートしていないインターフェイスの場合、このカウンターは表示されません。
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInUnknownProtos";
}
leaf out-octets {
type yang:counter64;
description
"The total number of octets transmitted out of the
interface, including framing characters.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCOutOctets";
}
leaf out-unicast-pkts {
type yang:counter64;
description
"The total number of packets that higher-level protocols
requested be transmitted and that were not addressed
to a multicast or broadcast address at this sub-layer,
including those that were discarded or not sent.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts";
}
｝
leaf out-broadcast-pkts {
type yang:counter64;
description
"The total number of packets that higher-level protocols
requested be transmitted and that were addressed to a
broadcast address at this sub-layer, including those
that were discarded or not sent.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCOutBroadcastPkts";
}
leaf out-multicast-pkts {
type yang:counter64;
description
"The total number of packets that higher-level protocols
requested be transmitted and that were addressed to a
multicast address at this sub-layer, including those
that were discarded or not sent. For a MAC-layer
protocol, this includes both Group and Functional
addresses.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCOutMulticastPkts";
}
leaf out-discards {
type yang:counter32;
description
"The number of outbound packets that were chosen to be
discarded even though no errors had been detected to
prevent their being transmitted. One possible reason
for discarding such a packet could be to free up buffer
space.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifOutDiscards";
}
leaf out-errors {
type yang:counter32;
description
"For packet-oriented interfaces, the number of outbound
packets that could not be transmitted because of errors.
For character-oriented or fixed-length interfaces, the
number of outbound transmission units that could not be
transmitted because of errors.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifOutErrors";
}
}
}
}
/*
* Legacy typedefs
*/
typedef interface-state-ref {
type leafref {
path "/if:interfaces-state/if:interface/if:name";
}
status deprecated;
description
"This type is used by data models that need to reference
the operationally present interfaces.";
}
/*
* Legacy operational state data nodes
*/
container interfaces-state {
コンテナーインターフェイス状態{
config false;
status deprecated;
description
"Data nodes for the operational state of interfaces.";
list interface {
key "name";
status deprecated;
description "The list of interfaces on the device.
説明 "デバイス上のインターフェースのリスト。
System-controlled interfaces created by the system are always present in this list, whether or not they are configured.";
システムによって作成されたシステム制御のインターフェースは、構成されているかどうかにかかわらず、常にこのリストに表示されます。 ";
leaf name {
type string;
status deprecated;
description
"The name of the interface.
A server implementation MAY map this leaf to the ifName
MIB object. Such an implementation needs to use some
mechanism to handle the differences in size and characters
allowed between this leaf and ifName. The definition of
such a mechanism is outside the scope of this document.";
reference
"RFC 2863: The Interfaces Group MIB - ifName";
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
status deprecated;
description
"The type of the interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
}
leaf admin-status {
if-feature if-mib;
type enumeration {
enum up {
value 1;
description
"Ready to pass packets.";
}
enum down {
value 2;
description
"Not ready to pass packets and not in some test mode.";
}
enum testing {
value 3;
description
"In some test mode.";
}
}
mandatory true;
status deprecated;
description
"The desired state of the interface.
This leaf has the same read semantics as ifAdminStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus";
}
leaf oper-status {
type enumeration {
enum up {
value 1;
description
"Ready to pass packets.";
}
enum down {
value 2;
description
"The interface does not pass any packets.";
}
enum testing {
value 3;
description
"In some test mode. No operational packets can
be passed.";
}
enum unknown {
value 4;
description
"Status cannot be determined for some reason.";
}
enum dormant {
value 5;
description
"Waiting for some external event.";
}
enum not-present {
value 6;
description
"Some component (typically hardware) is missing.";
}
enum lower-layer-down {
value 7;
description
"Down due to state of lower-layer interface(s).";
}
}
mandatory true;
status deprecated;
description
"The current operational state of the interface.
This leaf has the same semantics as ifOperStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifOperStatus";
}
leaf last-change {
type yang:date-and-time;
status deprecated;
description
"The time the interface entered its current operational
state. If the current state was entered prior to the
last re-initialization of the local network management
subsystem, then this node is not present.";
reference
"RFC 2863: The Interfaces Group MIB - ifLastChange";
}
leaf if-index {
if-feature if-mib;
type int32 {
range "1..2147483647";
}
mandatory true;
status deprecated;
description
"The ifIndex value for the ifEntry represented by this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifIndex";
}
leaf phys-address {
type yang:phys-address;
status deprecated;
description
"The interface's address at its protocol sub-layer. For
example, for an 802.x interface, this object normally
contains a Media Access Control (MAC) address. The
interface's media-specific modules must define the bit
and byte ordering and the format of the value of this
object. For interfaces that do not have such an address
(e.g., a serial line), this node is not present.";
reference
"RFC 2863: The Interfaces Group MIB - ifPhysAddress";
}
leaf-list higher-layer-if {
type interface-state-ref;
status deprecated;
description
"A list of references to interfaces layered on top of this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf-list lower-layer-if {
type interface-state-ref;
status deprecated;
description
"A list of references to interfaces layered underneath this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf speed {
type yang:gauge64;
units "bits/second";
status deprecated;
description
"An estimate of the interface's current bandwidth in bits
per second. For interfaces that do not vary in
bandwidth or for those where no accurate estimation can
be made, this node should contain the nominal bandwidth.
For interfaces that have no concept of bandwidth, this
node is not present.";
reference
"RFC 2863: The Interfaces Group MIB -
ifSpeed, ifHighSpeed";
}
container statistics {
status deprecated;
description
"A collection of interface-related statistics objects.";
leaf discontinuity-time {
type yang:date-and-time;
mandatory true;
status deprecated;
description
"The time on the most recent occasion at which any one or
more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management
subsystem, then this node contains the time the local
management subsystem re-initialized itself.";
}
leaf in-octets {
type yang:counter64;
status deprecated;
description
"The total number of octets received on the interface,
including framing characters.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCInOctets";
}
leaf in-unicast-pkts {
type yang:counter64;
status deprecated;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were not addressed to a
multicast or broadcast address at this sub-layer.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
}
leaf in-broadcast-pkts {
type yang:counter64;
status deprecated;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were addressed to a broadcast
address at this sub-layer.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCInBroadcastPkts";
}
leaf in-multicast-pkts {
type yang:counter64;
status deprecated;
description
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, that were addressed to a multicast
address at this sub-layer. For a MAC-layer protocol,
this includes both Group and Functional addresses.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCInMulticastPkts";
}
leaf in-discards {
type yang:counter32;
status deprecated;
description "The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.
説明「上位層プロトコルへの配信を妨げるエラーが検出されなかったにもかかわらず、破棄するように選択されたインバウンドパケットの数。このようなパケットを破棄する理由の1つとして、バッファースペースを解放することが考えられます。
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInDiscards";
}
leaf in-errors {
type yang:counter32;
status deprecated;
description
"For packet-oriented interfaces, the number of inbound
packets that contained errors preventing them from being
deliverable to a higher-layer protocol. For character-
oriented or fixed-length interfaces, the number of
inbound transmission units that contained errors
preventing them from being deliverable to a higher-layer
protocol.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInErrors";
}
leaf in-unknown-protos {
type yang:counter32;
status deprecated;
description
"For packet-oriented interfaces, the number of packets
received via the interface that were discarded because
of an unknown or unsupported protocol. For
character-oriented or fixed-length interfaces that
support protocol multiplexing, the number of
transmission units received via the interface that were
discarded because of an unknown or unsupported protocol.
For any interface that does not support protocol
multiplexing, this counter is not present.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifInUnknownProtos";
}
leaf out-octets {
type yang:counter64;
status deprecated;
description
"The total number of octets transmitted out of the
interface, including framing characters.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCOutOctets";
}
leaf out-unicast-pkts {
type yang:counter64;
status deprecated;
description
"The total number of packets that higher-level protocols
requested be transmitted and that were not addressed
to a multicast or broadcast address at this sub-layer,
including those that were discarded or not sent.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts";
}
leaf out-broadcast-pkts {
type yang:counter64;
status deprecated;
description "The total number of packets that higher-level protocols requested be transmitted and that were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent.
説明「上位プロトコルが送信を要求し、このサブレイヤーでブロードキャストアドレスにアドレス指定されたパケットの総数（破棄されたパケットまたは送信されなかったパケットを含む）。
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCOutBroadcastPkts";
}
leaf out-multicast-pkts {
type yang:counter64;
status deprecated;
description
"The total number of packets that higher-level protocols
requested be transmitted and that were addressed to a
multicast address at this sub-layer, including those
that were discarded or not sent. For a MAC-layer
protocol, this includes both Group and Functional
addresses.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB -
ifHCOutMulticastPkts";
}
leaf out-discards {
type yang:counter32;
status deprecated;
description
"The number of outbound packets that were chosen to be
discarded even though no errors had been detected to
prevent their being transmitted. One possible reason
for discarding such a packet could be to free up buffer
space.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifOutDiscards";
}
leaf out-errors {
type yang:counter32;
status deprecated;
description
"For packet-oriented interfaces, the number of outbound
packets that could not be transmitted because of errors.
For character-oriented or fixed-length interfaces, the
number of outbound transmission units that could not be
transmitted because of errors.
Discontinuities in the value of this counter can occur
at re-initialization of the management system and at
other times as indicated by the value of
'discontinuity-time'.";
reference
"RFC 2863: The Interfaces Group MIB - ifOutErrors";
}
}
}
}
}
<CODE ENDS>
<コード終了>
This document registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following registration has been made.
このドキュメントは、「IETF XMLレジストリ」[RFC3688]にURIを登録します。 RFC 3688のフォーマットに従って、次の登録が行われました。
URI: urn:ietf:params:xml:ns:yang:ietf-interfaces
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
XML：N / A、要求されたURIはXML名前空間です。
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]にYANGモジュールを登録しています。
name: ietf-interfaces
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces
prefix: if
reference: RFC 8343
The YANG module specified in this document defines 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プロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
There are a number of data nodes defined in this YANG module 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など）を行うと、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
/interfaces/interface: This list specifies the configured interfaces on a device. Unauthorized access to this list could cause the device to ignore packets it should receive and process.
/ interfaces / interface：このリストは、デバイスに構成されたインターフェースを指定します。このリストへの不正アクセスは、デバイスが受信して処理する必要のあるパケットを無視する原因になる可能性があります。
/interfaces/interface/enabled: This leaf controls whether or not an interface is enabled. Unauthorized access to this leaf could cause the device to ignore packets it should receive and process.
/ interfaces / interface / enabled：このリーフは、インターフェースを有効にするかどうかを制御します。このリーフへの不正アクセスは、デバイスが受信して処理する必要があるパケットを無視する原因となる可能性があります。
[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>。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, <https://www.rfc-editor.org/info/rfc2863>.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、DOI 10.17487 / RFC2863、2000年6月、<https://www.rfc-editor.org/info/rfc2863>。
[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>。
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.
[RFC7224] Bjorklund、M。、「IANA Interface Type YANG Module」、RFC 7224、DOI 10.17487 / RFC7224、2014年5月、<https://www.rfc-editor.org/info/rfc7224>。
[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>。
Appendix A. Example: Ethernet Interface Module
付録A.例：イーサネットインターフェイスモジュール
This section gives a simple example of how an Ethernet interface module could be defined. It demonstrates how media-specific configuration parameters can be conditionally augmented to the generic interface list. It also shows how operational state parameters can be conditionally augmented to the operational interface list. The example is not intended as a complete module for Ethernet configuration.
このセクションでは、イーサネットインターフェイスモジュールを定義する簡単な例を示します。メディア固有の構成パラメーターを条件付きで汎用インターフェースリストに追加する方法を示します。また、操作状態パラメーターを条件付きで操作インターフェースリストに追加する方法も示します。この例は、イーサネット構成用の完全なモジュールを意図したものではありません。
module example-ethernet {
namespace "http://example.com/ethernet";
prefix "eth";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
// configuration and state parameters for Ethernet interfaces
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
container transmission {
choice transmission-params {
case auto {
leaf auto-negotiate {
type empty;
}
}
case manual {
container manual {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
leaf speed {
type enumeration {
enum "10Mb";
enum "100Mb";
enum "1Gb";
enum "10Gb";
}
}
}
}
}
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
config false;
}
}
// other Ethernet-specific params...
}
}
}
Appendix B. Example: Ethernet Bonding Interface Module
付録B.例：イーサネットボンディングインターフェイスモジュール
This section gives an example of how interface layering can be defined. An Ethernet bonding interface that bonds several Ethernet interfaces into one logical interface is defined.
このセクションでは、インターフェイスの階層化を定義する方法の例を示します。複数のイーサネットインターフェイスを1つの論理インターフェイスに結合するイーサネットボンディングインターフェイスが定義されています。
module example-ethernet-bonding {
namespace "http://example.com/ethernet-bonding";
prefix "bond";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ieee8023adLag'";
leaf-list slave-if {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'ianaift:ethernetCsmacd'" {
description
"The type of a slave interface must be 'ethernetCsmacd'.";
}
}
leaf bonding-mode {
type enumeration {
enum round-robin;
enum active-backup;
enum broadcast;
}
}
// other bonding config params, failover times, etc.
}
}
Appendix C. Example: VLAN Interface Module
付録C.例：VLANインターフェイスモジュール
This section gives an example of how a VLAN interface module can be defined.
このセクションでは、VLANインターフェイスモジュールを定義する方法の例を示します。
module example-vlan {
namespace "http://example.com/vlan";
prefix "vlan";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd' or
if:type = 'ianaift:ieee8023adLag'";
leaf vlan-tagging {
type boolean;
default false;
}
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan'";
leaf base-interface {
type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]"
+ "/vlan:vlan-tagging = 'true'" {
description
"The base interface must have VLAN tagging enabled.";
}
}
leaf vlan-id {
type uint16 {
range "1..4094";
}
must "../base-interface" {
description
"If a vlan-id is defined, a base-interface must
be specified.";
}
}
}
}
Appendix D. Example: NETCONF <get-config> Reply
This section gives an example of a reply to the NETCONF <get-config> request for the running configuration datastore for a device that implements the example data models above.
このセクションでは、上記のサンプルデータモデルを実装するデバイスの実行コンフィギュレーションデータストアに対するNETCONF <get-config>リクエストへの応答の例を示します。
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<data>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:vlan="http://example.com/vlan">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>false</enabled>
</interface>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<vlan:vlan-tagging>true</vlan:vlan-tagging>
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<enabled>true</enabled>
<vlan:base-interface>eth1</vlan:base-interface>
<vlan:vlan-id>10</vlan:vlan-id>
</interface>
<interface>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<enabled>true</enabled>
</interface>
</interfaces>
</data>
</rpc-reply>
Appendix E. Example: NETCONF <get-data> Reply
This section gives an example of a reply to the NETCONF <get-data> request for the operational state datastore for a device that implements the example data models above.
このセクションでは、上記のデータモデルの例を実装するデバイスの動作状態データストアのNETCONF <get-data>要求に対する応答の例を示します。
This example uses the "origin" annotation, which is defined in the module "ietf-origin" [RFC8342].
この例では、モジュール「ietf-origin」[RFC8342]で定義されている「origin」アノテーションを使用しています。
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:vlan="http://example.com/vlan"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<interface or:origin="or:intended">
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>false</enabled>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
<if-index>2</if-index>
<phys-address>00:01:02:03:04:05</phys-address>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface or:origin="or:intended">
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>7</if-index>
<phys-address>00:01:02:03:04:06</phys-address>
<higher-layer-if>eth1.10</higher-layer-if>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
<vlan:vlan-tagging>true</vlan:vlan-tagging>
</interface>
<interface or:origin="or:intended">
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<enabled>true</enabled>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>9</if-index>
<lower-layer-if>eth1</lower-layer-if>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
<vlan:base-interface>eth1</vlan:base-interface>
<vlan:vlan-id>10</vlan:vlan-id>
</interface>
<!-- This interface is not configured -->
<interface or:origin="or:system">
<name>eth2</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
<if-index>8</if-index>
<phys-address>00:01:02:03:04:07</phys-address>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface or:origin="or:intended">
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<enabled>true</enabled>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>1</if-index>
<statistics>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
</interfaces>
</data>
</rpc-reply>
Appendix F. Examples: Interface Naming Schemes
付録F.例：インターフェース命名スキーム
This section gives examples of some implementation strategies.
このセクションでは、いくつかの実装戦略の例を示します。
The examples make use of the example data model "example-vlan" (see Appendix C) to show how user-controlled interfaces can be configured.
この例では、サンプルデータモデル「example-vlan」（付録Cを参照）を使用して、ユーザー制御のインターフェースを構成する方法を示しています。
In this example, a router has support for 4 line cards, each with 8 ports. The slots for the cards are physically numbered from 0 to 3, and the ports on each card from 0 to 7. Each card has Fast Ethernet or Gigabit Ethernet ports.
In this example, a router has support for 4 line cards, each with 8 ports. The slots for the cards are physically numbered from 0 to 3, and the ports on each card from 0 to 7. Each card has Fast Ethernet or Gigabit Ethernet ports.
The device-specific names for these physical interfaces are "fastethernet-N/M" or "gigabitethernet-N/M".
これらの物理インターフェイスのデバイス固有の名前は、「fastethernet-N / M」または「gigabitethernet-N / M」です。
The name of a VLAN interface is restricted to the form "<physical-interface-name>.<subinterface-number>".
VLANインターフェースの名前は、「<物理インターフェース名>。<サブインターフェース番号>」の形式に制限されています。
It is assumed that the operator is aware of this naming scheme. The implementation auto-initializes the value for "type" based on the interface name.
オペレーターはこの命名方式を知っていると想定されます。実装は、インターフェイス名に基づいて「タイプ」の値を自動初期化します。
The NETCONF server does not advertise the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージ内の「任意の名前」機能を通知しません。
An operator can configure a physical interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信することにより、物理インターフェースを構成できます。
<interface nc:operation="create">
<name>fastethernet-1/0</name>
</interface>
When the server processes this request, it will set the leaf "type" to "ianaift:ethernetCsmacd". Thus, if the client performs a <get-config> right after the <edit-config> above, it will get:
サーバーはこのリクエストを処理するときに、リーフの「タイプ」を「ianaift：ethernetCsmacd」に設定します。したがって、クライアントが上記の<edit-config>の直後に<get-config>を実行すると、次のようになります。
<interface>
<name>fastethernet-1/0</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
The client can configure a VLAN interface by sending an <edit-config> containing:
クライアントは、以下を含む<edit-config>を送信することにより、VLANインターフェイスを構成できます。
<interface nc:operation="create">
<name>fastethernet-1/0.10005</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>fastethernet-1/0</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
If the client tries to change the type of the physical interface with an <edit-config> containing:
クライアントが以下を含む<edit-config>を使用して物理インターフェースのタイプを変更しようとした場合：
<interface nc:operation="merge">
<name>fastethernet-1/0</name>
<type>ianaift:tunnel</type>
</interface>
then the server will reply with an "invalid-value" error, since the new type does not match the name.
新しいタイプは名前と一致しないため、サーバーは「無効な値」エラーで応答します。
In this example, a router has support for 4 line cards, each with 8 ports. The slots for the cards are physically numbered from 0 to 3, and the ports on each card from 0 to 7. Each card has Fast Ethernet or Gigabit Ethernet ports.
この例では、ルーターは4つのラインカードをサポートしており、それぞれに8つのポートがあります。カードのスロットには、物理的に0〜3の番号が付けられており、各カードのポートには0〜7の番号が付けられています。各カードには、ファストイーサネットポートまたはギガビットイーサネットポートがあります。
The device-specific names for these physical interfaces are "fastethernet-N/M" or "gigabitethernet-N/M".
これらの物理インターフェイスのデバイス固有の名前は、「fastethernet-N / M」または「gigabitethernet-N / M」です。
The implementation does not restrict the user-controlled interface names. This allows an operator to more easily apply the interface configuration to a different interface. However, the additional level of indirection also makes it a bit more complex to map interface names found in other protocols to configuration entries.
この実装は、ユーザー制御のインターフェース名を制限しません。これにより、オペレーターはインターフェース構成を別のインターフェースに簡単に適用できます。ただし、追加レベルの間接指定により、他のプロトコルにあるインターフェース名を構成エントリーにマップするのが少し複雑になります。
The NETCONF server advertises the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージで「任意の名前」機能を通知します。
Physical interfaces are configured as in Appendix F.1.
物理インターフェイスは、付録F.1のように構成されます。
An operator can configure a VLAN interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信して、VLANインターフェースを構成できます。
<interface nc:operation="create">
<name>acme-interface</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>fastethernet-1/0</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
If necessary, the operator can move the configuration named "acme-interface" over to a different physical interface with an <edit-config> containing:
If necessary, the operator can move the configuration named "acme-interface" over to a different physical interface with an <edit-config> containing:
<interface nc:operation="merge">
<name>acme-interface</name>
<vlan:base-interface>fastethernet-1/1</vlan:base-interface>
</interface>
In this example, an Ethernet switch has a number of ports, each identified by a simple port number.
この例では、イーサネットスイッチには多数のポートがあり、それぞれが単純なポート番号で識別されます。
The device-specific names for the physical interfaces are numbers that match the physical port number.
物理インターフェイスのデバイス固有の名前は、物理ポート番号と一致する番号です。
An operator can configure a physical interface by sending an <edit-config> containing:
An operator can configure a physical interface by sending an <edit-config> containing:
<interface nc:operation="create">
<name>6</name>
</interface>
When the server processes this request, it will set the leaf "type" to "ianaift:ethernetCsmacd". Thus, if the client performs a <get-config> right after the <edit-config> above, it will get:
サーバーはこのリクエストを処理するときに、リーフの「タイプ」を「ianaift：ethernetCsmacd」に設定します。したがって、クライアントが上記の<edit-config>の直後に<get-config>を実行すると、次のようになります。
<interface>
<name>6</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
In this example, a generic host has interfaces named by the kernel. The system identifies the physical interface by the name assigned by the operating system to the interface.
この例では、汎用ホストには、カーネルによって名前が付けられたインターフェースがあります。システムは、オペレーティングシステムによってインターフェイスに割り当てられた名前で物理インターフェイスを識別します。
The name of a VLAN interface is restricted to the form "<physical-interface-name>:<vlan-number>".
The name of a VLAN interface is restricted to the form "<physical-interface-name>:<vlan-number>".
The NETCONF server does not advertise the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージ内の「任意の名前」機能を通知しません。
An operator can configure an interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信してインターフェースを構成できます。
<interface nc:operation="create">
<name>eth8</name>
</interface>
When the server processes this request, it will set the leaf "type" to "ianaift:ethernetCsmacd". Thus, if the client performs a <get-config> right after the <edit-config> above, it will get:
When the server processes this request, it will set the leaf "type" to "ianaift:ethernetCsmacd". Thus, if the client performs a <get-config> right after the <edit-config> above, it will get:
<interface>
<name>eth8</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
The client can configure a VLAN interface by sending an <edit-config> containing:
クライアントは、以下を含む<edit-config>を送信することにより、VLANインターフェイスを構成できます。
<interface nc:operation="create">
<name>eth8:5</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>eth8</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
In this example, a generic host has interfaces named by the kernel. The system identifies the physical interface by the name assigned by the operating system to the interface.
In this example, a generic host has interfaces named by the kernel. The system identifies the physical interface by the name assigned by the operating system to the interface.
The implementation does not restrict the user-controlled interface names. This allows an operator to more easily apply the interface configuration to a different interface. However, the additional level of indirection also makes it a bit more complex to map interface names found in other protocols to configuration entries.
この実装は、ユーザー制御のインターフェース名を制限しません。これにより、オペレーターはインターフェース構成を別のインターフェースに簡単に適用できます。ただし、追加レベルの間接指定により、他のプロトコルにあるインターフェース名を構成エントリーにマップするのが少し複雑になります。
The NETCONF server advertises the "arbitrary-names" feature in the <hello> message.
NETCONFサーバーは、<hello>メッセージで「任意の名前」機能を通知します。
Physical interfaces are configured as in Appendix F.4.
物理インターフェイスは、付録F.4のように構成されます。
An operator can configure a VLAN interface by sending an <edit-config> containing:
オペレーターは、以下を含む<edit-config>を送信して、VLANインターフェースを構成できます。
<interface nc:operation="create">
<name>acme-interface</name>
<type>ianaift:l2vlan</type>
<vlan:base-interface>eth8</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface>
If necessary, the operator can move the configuration named "acme-interface" over to a different physical interface with an <edit-config> containing:
必要に応じて、オペレーターは、「acme-interface」という名前の構成を、以下を含む<edit-config>を使用して別の物理インターフェースに移動できます。
<interface nc:operation="merge">
<name>acme-interface</name>
<vlan:base-interface>eth3</vlan:base-interface>
</interface>
Acknowledgments
謝辞
The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav Lhotka, and Juergen Schoenwaelder for their helpful comments.
著者は、有益なコメントを提供してくれたAlexander Clemm、Per Hedeland、Ladislav Lhotka、およびJuergen Schoenwaelderに感謝します。
Author's Address
著者のアドレス
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-fシステム
Email: mbj@tail-f.com