Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 7223 Tail-f Systems
Category: Standards Track May 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 7223 Tail-f Systems
Category: Standards Track May 2014
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 configuration data and state data (status information and counters for the collection of statistics).
本文件定义了网络接口管理的数据模型。预计接口类型特定的数据模型将扩展本文档中定义的通用接口数据模型。数据模型包括配置数据和状态数据（用于收集统计数据的状态信息和计数器）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7223.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7223.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Tree Diagrams ..............................................4
2. Objectives ......................................................4
3. Interfaces Data Model ...........................................5
3.1. The Interface Lists ........................................6
3.2. Interface References .......................................7
3.3. Interface Layering .........................................7
4. Relationship to the IF-MIB ......................................8
5. Interfaces YANG Module .........................................11
6. IANA Considerations ............................................26
7. Security Considerations ........................................26
8. Acknowledgments ................................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................28
Appendix A. Example: Ethernet Interface Module ....................29
Appendix B. Example: Ethernet Bonding Interface Module ............30
Appendix C. Example: VLAN Interface Module ........................31
Appendix D. Example: NETCONF <get> Reply ..........................32
Appendix E. Examples: Interface Naming Schemes ....................35
E.1. Router with Restricted Interface Names .....................35
E.2. Router with Arbitrary Interface Names ......................36
E.3. Ethernet Switch with Restricted Interface Names ............37
E.4. Generic Host with Restricted Interface Names ...............38
E.5. Generic Host with Arbitrary Interface Names ................39
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Tree Diagrams ..............................................4
2. Objectives ......................................................4
3. Interfaces Data Model ...........................................5
3.1. The Interface Lists ........................................6
3.2. Interface References .......................................7
3.3. Interface Layering .........................................7
4. Relationship to the IF-MIB ......................................8
5. Interfaces YANG Module .........................................11
6. IANA Considerations ............................................26
7. Security Considerations ........................................26
8. Acknowledgments ................................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................28
Appendix A. Example: Ethernet Interface Module ....................29
Appendix B. Example: Ethernet Bonding Interface Module ............30
Appendix C. Example: VLAN Interface Module ........................31
Appendix D. Example: NETCONF <get> Reply ..........................32
Appendix E. Examples: Interface Naming Schemes ....................35
E.1. Router with Restricted Interface Names .....................35
E.2. Router with Arbitrary Interface Names ......................36
E.3. Ethernet Switch with Restricted Interface Names ............37
E.4. Generic Host with Restricted Interface Names ...............38
E.5. Generic Host with Arbitrary Interface Names ................39
This document defines a YANG [RFC6020] 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.
本文件定义了用于管理网络接口的YANG[RFC6020]数据模型。预计接口类型特定的数据模型将扩展本文档中定义的通用接口数据模型。
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).
数据模型包括配置数据和状态数据（用于收集统计数据的状态信息和计数器）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14[RFC2119]中的说明进行解释。
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 running configuration datastore and the removal of the interface is controlled by removing explicit interface configuration from the running configuration datastore. Examples are VLAN interfaces configured on a system-controlled Ethernet interface.
o 用户控制接口：如果通过向运行配置数据存储添加显式接口配置来控制接口的创建，并且通过从运行配置数据存储中删除显式接口配置来控制接口的删除，则称接口为用户控制。例如，在系统控制的以太网接口上配置VLAN接口。
The following terms are defined in [RFC6241] and are not redefined here:
[RFC6241]中定义了以下术语，此处未重新定义：
o client
o 客户
o configuration data
o 配置数据
o server
o 服务器
o state data
o 状态数据
The following terms are defined in [RFC6020] and are not redefined here:
[RFC6020]中定义了以下术语，此处未重新定义：
o augment
o 加强
o data model
o 数据模型
o data node
o 数据节点
o presence container
o 存在容器
A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows:
本文件中使用了数据模型的简化图形表示。这些图表中符号的含义如下：
o Brackets "[" and "]" enclose list keys.
o 括号“[”和“]”包含列表键。
o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" means state data (read-only).
o 数据节点名称前的缩写：“rw”表示配置（读写），“ro”表示状态数据（只读）。
o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list.
o 数据节点名称后的符号：“？”表示可选节点，“！”表示状态容器，“*”表示列表和叶列表。
o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
o 括号括住选项和事例节点，事例节点也用冒号（“：”）标记。
o Ellipsis ("...") stands for contents of subtrees that are not shown.
o 省略号（“…”）表示未显示的子树的内容。
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）简单分层，其中一个接口分层在另一个接口之上；（2）更复杂的场景，其中一个接口由N个其他接口聚合而成，或者N个接口在另一个接口上多路复用。
o The data model should support the pre-provisioning of interface configuration, i.e., 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:
本文件定义了模块“ietf接口”，其结构如下：
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw description? string
| +--rw type identityref
| +--rw enabled? boolean
| +--rw link-up-down-trap-enable? enumeration
+--ro interfaces-state
+--ro interface* [name]
+--ro name string
+--ro type identityref
+--ro admin-status enumeration
+--ro oper-status enumeration
+--ro last-change? yang:date-and-time
+--ro if-index int32
+--ro phys-address? yang:phys-address
+--ro higher-layer-if* interface-state-ref
+--ro lower-layer-if* interface-state-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
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw description? string
| +--rw type identityref
| +--rw enabled? boolean
| +--rw link-up-down-trap-enable? enumeration
+--ro interfaces-state
+--ro interface* [name]
+--ro name string
+--ro type identityref
+--ro admin-status enumeration
+--ro oper-status enumeration
+--ro last-change? yang:date-and-time
+--ro if-index int32
+--ro phys-address? yang:phys-address
+--ro higher-layer-if* interface-state-ref
+--ro lower-layer-if* interface-state-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
+--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. Each interface in the list is identified by its name. Furthermore, each interface has a mandatory "type" leaf.
本文档中提供的接口数据模型使用接口的平面列表。列表中的每个接口都由其名称标识。此外，每个接口都有一个强制的“类型”叶。
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定义”注册表中定义接口类型的标识。
There is one list of configured interfaces ("/interfaces/interface"), and a separate list for the operational state of all interfaces ("/interfaces-state/interface").
有一个已配置接口列表（“/interfaces/interface”），还有一个单独的所有接口操作状态列表（“/interfaces state/interface”）。
It is expected that interface-type-specific data models augment the interface lists 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.
作为这种接口类型特定增强的一个例子，请考虑这个杨氏片段。有关更完整的示例，请参见附录a。
import interfaces {
prefix "if";
}
import iana-if-type {
prefix ianaift;
}
import interfaces {
prefix "if";
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
leaf duplex {
...
}
}
}
container ethernet {
leaf duplex {
...
}
}
}
For system-controlled interfaces, the "name" is the device-specific name of the interface. The 'config false' list "/interfaces-state/interface" contains all existing interfaces on the device.
对于系统控制接口，“名称”是接口的设备特定名称。“config false”列表“/接口状态/接口”包含设备上的所有现有接口。
If the device supports arbitrarily named user-controlled interfaces, the Network Configuration Protocol (NETCONF) server advertises the "arbitrary-names" feature. If the device 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 E.1 and E.2 for examples.
如果设备支持任意命名的用户控制接口，则网络配置协议（NETCONF）服务器会播发“任意名称”功能。如果设备未公布此功能，则用户控制接口的名称必须与设备的命名方案匹配。客户如何了解此类设备的命名方案超出了本文档的范围。示例见附录E.1和E.2。
When a system-controlled interface is created by the system, the system tries to apply the interface configuration in "/interfaces/ interface" 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.
当系统创建系统控制的接口时，系统尝试在“/interfaces/interface”中应用与新接口同名的接口配置。如果未找到此类接口配置，或者如果配置的类型与实际接口类型不匹配，则系统将在不应用显式配置的情况下创建接口。
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" and "interface-state-ref" typedefs, which other YANG modules SHOULD use when they need to reference a configured interface or operationally used interface, respectively.
接口由其名称标识，该名称在服务器中是唯一的。此属性在“interface ref”和“interface state ref”typedefs中捕获，当其他模块需要分别引用配置接口或操作使用的接口时，应使用这些属性。
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.
对于如何将接口配置为在其他接口之上分层，没有通用机制。预期特定于接口类型的模型通过使用“interface ref”类型引用较低的层来定义自己的接口分层数据节点。
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;
}
import interfaces {
prefix "if";
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ieee8023adLag'";
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.
}
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.
虽然接口分层是在接口类型特定的模型中配置的，但两个通用状态数据叶列表“较高层if”和“较低层if”表示接口分层层次结构的只读视图。
If the device implements the IF-MIB [RFC2863], each entry in the "/ interfaces-state/interface" list is typically mapped to one ifEntry. The "if-index" leaf MUST contain the value of the corresponding ifEntry's ifIndex.
如果设备实现If-MIB[RFC2863]，则“/interfaces state/interface”列表中的每个条目通常映射到一个ifEntry。“if index”叶必须包含相应ifEntry的ifIndex值。
In most cases, the "name" of an "/interfaces-state/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 state/interface”条目的“name”映射到ifName。IF-MIB允许两个不同的IFENTRY具有相同的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.
在某些实现中，“接口”的配置“描述”传统上映射到IFALIA。本文档允许这种映射，但是实现者应该知道这些对象在值空间和持久性方面的差异。有关详细信息，请参见第5节叶“说明”的模块定义。
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还定义了可写对象IFPROMISCUUSMODE。由于SNMP代理通常不会将此对象实现为配置对象，因此不会将其映射到“ietf接口”模块。
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接口”模块。预计特定于接口类型的模块通过扩展“ietf接口”模型提供特定于接口类型的MTU LEAF。
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, and hence only 64-bit counters are provided in this data model. Note that NETCONF and SNMP 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位的。添加64位版本是为了支持数据速率大于20000000位/秒的高速接口。今天的实现通常支持这种高速接口，因此在这个数据模型中只提供64位计数器。请注意，NETCONF和SNMP在提供对计数器的访问的时间粒度上可能有所不同。例如，SNMP实现通常会将计数器值缓存一段时间。
The objects ifDescr and ifConnectorPresent from the IF-MIB are not mapped to the "ietf-interfaces" module.
来自IF-MIB的对象ifDescr和ifConnectorPresent未映射到“ietf接口”模块。
The following tables list the YANG data nodes with corresponding objects in the IF-MIB.
下表列出了IF-MIB中具有相应对象的数据节点。
+--------------------------------------+----------------------------+
| YANG data node in /interfaces- | IF-MIB object |
| state/interface | |
+--------------------------------------+----------------------------+
| name | ifName |
| type | ifType |
| 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 node in /interfaces- | IF-MIB object |
| state/interface | |
+--------------------------------------+----------------------------+
| name | ifName |
| type | ifType |
| 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 State Data Nodes and Related IF-MIB Objects
YANG State数据节点和相关的IF-MIB对象
+-----------------------------------------+---------------+
| YANG data node in /interfaces/interface | IF-MIB object |
+-----------------------------------------+---------------+
| description | ifAlias |
+-----------------------------------------+---------------+
+-----------------------------------------+---------------+
| YANG data node in /interfaces/interface | IF-MIB object |
+-----------------------------------------+---------------+
| description | ifAlias |
+-----------------------------------------+---------------+
YANG Config Data Nodes and Related IF-MIB Objects
配置数据节点和相关的IF-MIB对象
This YANG module imports typedefs from [RFC6991].
此模块从[RFC6991]导入typedefs。
<CODE BEGINS> file "ietf-interfaces@2014-05-08.yang"
<CODE BEGINS> file "ietf-interfaces@2014-05-08.yang"
module ietf-interfaces {
模块ietf接口{
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if;
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if;
import ietf-yang-types {
prefix yang;
}
import ietf-yang-types {
prefix yang;
}
organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
组织“IETF NETMOD（NETCONF数据建模语言）工作组”；
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: Thomas Nadeau
<mailto:tnadeau@lucidvision.com>
WG Chair: Thomas Nadeau
<mailto:tnadeau@lucidvision.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>";
Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>";
description "This module contains a collection of YANG definitions for managing network interfaces.
description“此模块包含用于管理网络接口的定义集合。
Copyright (c) 2014 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2014 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 7223; see the RFC itself for full legal notices.";
该模块的此版本是RFC 7223的一部分；有关完整的法律通知，请参见RFC本身。“；
revision 2014-05-08 {
description
"Initial revision.";
reference
"RFC 7223: 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
*/
/*
* 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
configured interfaces.";
}
typedef interface-ref {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
description
"This type is used by data models that need to reference
configured interfaces.";
}
typedef interface-state-ref {
type leafref {
path "/if:interfaces-state/if:interface/if:name";
}
description
"This type is used by data models that need to reference
the operationally present interfaces.";
}
typedef interface-state-ref {
type leafref {
path "/if:interfaces-state/if:interface/if:name";
}
description
"This type is used by data models that need to reference
the operationally present interfaces.";
}
/*
* Identities
*/
/*
* Identities
*/
identity interface-type {
description
"Base identity from which specific interface types are
derived.";
}
identity interface-type {
description
"Base identity from which specific interface types are
derived.";
}
/*
* Features
*/
/*
* Features
*/
feature arbitrary-names {
description
"This feature indicates that the device allows user-controlled
interfaces to be named arbitrarily.";
}
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 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";
}
feature if-mib {
description
"This feature indicates that the device implements
the IF-MIB.";
reference
"RFC 2863: The Interfaces Group MIB";
}
/*
* Configuration data nodes
*/
/*
* Configuration data nodes
*/
container interfaces {
description
"Interface configuration parameters.";
container interfaces {
description
"Interface configuration parameters.";
list interface {
key "name";
list interface {
key "name";
description "The list of configured interfaces on the device.
description“设备上已配置接口的列表。
The operational state of an interface is available in the
/interfaces-state/interface list. 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
/interfaces-state/interface list. If the configuration
of a user-controlled interface cannot be used by the system,
the configured interface is not instantiated in the
/interfaces-state/interface list.";
The operational state of an interface is available in the
/interfaces-state/interface list. 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
/interfaces-state/interface list. If the configuration
of a user-controlled interface cannot be used by the system,
the configured interface is not instantiated in the
/interfaces-state/interface list.";
leaf name {
type string;
description
"The name of the interface.
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. The 'config false' list /interfaces-state/interface contains the currently existing interfaces on the device.
对于系统控制接口，此叶是接口的设备特定名称。“config false”列表/接口状态/接口包含设备上当前存在的接口。
If a client tries to create configuration for a system-controlled interface that is not present in the /interfaces-state/interface list, 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 NETCONF server MUST reply with an rpc-error with the error-tag 'invalid-value' in this case.
如果客户机尝试为/interfaces state/interface列表中不存在的系统控制接口创建配置，则如果实现不支持接口的预配置，或者如果名称指的是系统中永远不可能存在的接口，则服务器可能会拒绝该请求。在这种情况下，NETCONF服务器必须使用带有错误标记“无效值”的rpc错误进行回复。
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
/interface-state/interface list.";
}
When a configured user-controlled interface is created by
the system, it is instantiated with the same name in the
/interface-state/interface list.";
}
leaf description {
type string;
description
"A textual description of the interface.
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对象。这样的实现需要使用某种机制来处理此leaf和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 datastore.
由于ifAlias被定义为存储在非易失性存储中，MIB实现必须将ifAlias映射到持久存储的数据存储中的“description”值。
Specifically, if the device supports ':startup', when ifAlias is read the device MUST return the value of 'description' in the 'startup' datastore, and when it is written, it MUST be written to the 'running' and 'startup' datastores. Note that it is up to the implementation to
具体而言，如果设备支持“：startup”，则读取ifAlias时，设备必须在“startup”数据存储中返回“description”值，写入时，必须将其写入“running”和“startup”数据存储。请注意，这取决于实现
decide whether to modify this single leaf in 'startup' or perform an implicit copy-config from 'running' to 'startup'.
决定是在“startup”中修改此单个叶，还是执行从“running”到“startup”的隐式复制配置。
If the device does not support ':startup', ifAlias MUST
be mapped to the 'description' leaf in the 'running'
datastore.";
reference
"RFC 2863: The Interfaces Group MIB - ifAlias";
}
If the device does not support ':startup', ifAlias MUST
be mapped to the 'description' leaf in the 'running'
datastore.";
reference
"RFC 2863: The Interfaces Group MIB - ifAlias";
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
description
"The type of the interface.
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";
}
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.
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 'running' datastore to set IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry has been initialized, as described in RFC 2863.
实现IF-MIB的系统使用“正在运行”数据存储中此叶的值，在初始化ifEntry后将IF-MIB.ifAdminStatus设置为“向上”或“向下”，如RFC 2863中所述。
Changes in this leaf in the 'running' datastore are
reflected in ifAdminStatus, but if ifAdminStatus is
changed over SNMP, this leaf is not affected.";
reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus";
}
Changes in this leaf in the 'running' datastore are
reflected in ifAdminStatus, but if ifAdminStatus is
changed over SNMP, this leaf is not affected.";
reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus";
}
leaf link-up-down-trap-enable {
if-feature if-mib;
type enumeration {
enum enabled {
value 1;
}
enum disabled {
value 2;
}
}
description
"Controls whether linkUp/linkDown SNMP notifications
should be generated for this interface.
leaf link-up-down-trap-enable {
if-feature if-mib;
type enumeration {
enum enabled {
value 1;
}
enum disabled {
value 2;
}
}
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";
}
}
}
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";
}
}
}
/*
* Operational state data nodes
*/
/*
* Operational state data nodes
*/
container interfaces-state {
config false;
description
"Data nodes for the operational state of interfaces.";
container interfaces-state {
config false;
description
"Data nodes for the operational state of interfaces.";
list interface {
key "name";
list interface {
key "name";
description "The list of interfaces on the device.
description“设备上的接口列表。
System-controlled interfaces created by the system are always present in this list, whether they are configured or not.";
由系统创建的系统控制接口始终存在于此列表中，无论它们是否已配置。“；
leaf name {
type string;
description
"The name of the interface.
leaf name {
type string;
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";
}
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;
description
"The type of the interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
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.";
}
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;
description
"The desired state of the interface.
enum testing {
value 3;
description
"In some test mode.";
}
}
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";
}
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.";
}
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;
description
"The current operational state of the interface.
enum lower-layer-down {
value 7;
description
"Down due to state of lower-layer interface(s).";
}
}
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";
}
This leaf has the same semantics as ifOperStatus.";
reference
"RFC 2863: The Interfaces Group MIB - ifOperStatus";
}
leaf last-change {
type yang:date-and-time;
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 last-change {
type yang:date-and-time;
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;
description
"The ifIndex value for the ifEntry represented by this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifIndex";
}
leaf if-index {
if-feature if-mib;
type int32 {
range "1..2147483647";
}
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;
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
leaf phys-address {
type yang:phys-address;
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";
}
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;
description
"A list of references to interfaces layered on top of this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf-list higher-layer-if {
type interface-state-ref;
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;
description
"A list of references to interfaces layered underneath this
interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifStackTable";
}
leaf-list lower-layer-if {
type interface-state-ref;
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";
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";
}
leaf speed {
type yang:gauge64;
units "bits/second";
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 {
description
"A collection of interface-related statistics objects.";
container statistics {
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 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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
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.
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";
}
}
}
}
}
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
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].
本文件在“阳模块名称”注册表[RFC6020]中注册阳模块。
name: ietf-interfaces
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces
prefix: if
reference: RFC 7223
name: ietf-interfaces
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces
prefix: if
reference: RFC 7223
The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content.
本备忘录中定义的模块旨在通过NETCONF协议[RFC6241]访问。最低的NETCONF层是安全传输层，实现安全传输的必需层是SSH[RFC6242]。NETCONF访问控制模型[RFC6536]提供了将特定NETCONF用户的访问限制为所有可用NETCONF协议操作和内容的预配置子集的方法。
There are a number of data nodes defined in the YANG module which 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>)
YANG模块中定义了许多数据节点，这些节点是可写/可创建/可删除的（即config true，这是默认值）。在某些网络环境中，这些数据节点可能被视为敏感或易受攻击。写入操作（例如，<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:
对这些数据节点不进行适当的保护可能会对网络运行产生负面影响。这些是子树和数据节点及其敏感性/漏洞：
/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/enabled: This leaf controls whether an interface is enabled or not. Unauthorized access to this leaf could cause the device to ignore packets it should receive and process.
/接口/接口/已启用：此叶控制接口是否已启用。未经授权访问此叶可能会导致设备忽略其应接收和处理的数据包。
The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav Lhotka, and Juergen Schoenwaelder for their helpful comments.
作者希望感谢亚历山大·克莱姆、佩尔·海德兰、拉迪斯拉夫·洛特卡和尤尔根·舍恩瓦埃尔德的有益评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020]Bjorklund，M.“YANG-网络配置协议（NETCONF）的数据建模语言”，RFC6020，2010年10月。
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013.
[RFC6991]Schoenwaeld，J.，“常见的杨氏数据类型”，RFC 69912013年7月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]Enns，R.，Bjorklund，M.，Schoenwaeld，J.，和A.Bierman，“网络配置协议（NETCONF）”，RFC 62412011年6月。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011.
[RFC6242]Wasserman，M.“在安全Shell（SSH）上使用NETCONF协议”，RFC6242，2011年6月。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012.
[RFC6536]Bierman，A.和M.Bjorklund，“网络配置协议（NETCONF）访问控制模型”，RFC 65362012年3月。
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, May 2014.
[RFC7224]Bjorklund，M.，“IANA接口类型YANG模块”，RFC 72242014年5月。
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 ex-ethernet {
namespace "http://example.com/ethernet";
prefix "eth";
module ex-ethernet {
namespace "http://example.com/ethernet";
prefix "eth";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
// configuration parameters for Ethernet interfaces
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
// configuration parameters for Ethernet interfaces
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
choice transmission-params {
case auto {
leaf auto-negotiate {
type empty;
}
}
case manual {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
container ethernet {
choice transmission-params {
case auto {
leaf auto-negotiate {
type empty;
}
}
case manual {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
leaf speed {
type enumeration {
enum "10Mb";
enum "100Mb";
enum "1Gb";
enum "10Gb";
}
}
}
}
// other Ethernet-specific params...
}
}
leaf speed {
type enumeration {
enum "10Mb";
enum "100Mb";
enum "1Gb";
enum "10Gb";
}
}
}
}
// other Ethernet-specific params...
}
}
// operational state parameters for Ethernet interfaces
augment "/if:interfaces-state/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
// operational state parameters for Ethernet interfaces
augment "/if:interfaces-state/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
// other Ethernet-specific params...
}
}
}
container ethernet {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
// 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.
本节给出了如何定义接口分层的示例。定义了将多个以太网接口连接到一个逻辑接口的以太网连接接口。
module ex-ethernet-bonding {
namespace "http://example.com/ethernet-bonding";
prefix "bond";
module ex-ethernet-bonding {
namespace "http://example.com/ethernet-bonding";
prefix "bond";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ieee8023adLag'";
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.
}
}
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 ex-vlan {
namespace "http://example.com/vlan";
prefix "vlan";
module ex-vlan {
namespace "http://example.com/vlan";
prefix "vlan";
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
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:ethernetCsmacd' or
if:type = 'ianaift:ieee8023adLag'";
leaf vlan-tagging {
type boolean;
default false;
}
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan'";
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.";
}
}
}
}
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> Reply
Appendix D. Example: NETCONF <get> Reply
This section gives an example of a reply to the NETCONF <get> request for a device that implements the example data models above.
本节给出了对实现上述示例数据模型的设备的NETCONF<get>请求的回复示例。
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<data>
<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">
<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>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</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>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>
<interface>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<enabled>true</enabled>
</interface>
</interfaces>
</interfaces>
<interfaces-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<interfaces-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<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>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<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>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>7</if-index>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<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>
</interface>
<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>
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<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>
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<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>
</interface>
<!-- This interface is not configured -->
<interface>
<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>
<!-- This interface is not configured -->
<interface>
<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>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>1</if-index>
<statistics>
<interface>
<name>lo1</name>
<type>ianaift:softwareLoopback</type>
<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>
<discontinuity-time>
2013-04-01T03:00:00+00:00
</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
</interfaces-state>
</data>
</rpc-reply>
</interfaces-state>
</data>
</rpc-reply>
Appendix E. Examples: Interface Naming Schemes
附录E.示例：接口命名方案
This section gives examples of some implementation strategies.
本节给出了一些实施策略的示例。
The examples make use of the example data model "ex-vlan" (see Appendix C) to show how user-controlled interfaces can be configured.
这些示例使用示例数据模型“ex 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.
在本例中，路由器支持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 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.
假定操作员知道此命名方案。实现根据接口名称自动初始化“type”的值。
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>
<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:
当服务器处理此请求时，它会将叶“type”设置为“ianaift:ethernetCsmacd”。因此，如果客户机在上面的<edit config>之后执行<get config>，它将获得：
<interface>
<name>fastethernet-1/0</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
<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>
<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>
<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 E.1.
物理接口的配置如附录E.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>
<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:
如有必要，操作员可以将名为“acme interface”的配置移到另一个物理接口上，该物理接口的<edit config>包含：
<interface nc:operation="merge">
<name>acme-interface</name>
<vlan:base-interface>fastethernet-1/1</vlan:base-interface>
</interface>
<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:
操作员可以通过发送包含以下内容的<edit config>，来配置物理界面：
<interface nc:operation="create">
<name>6</name>
</interface>
<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:
当服务器处理此请求时，它会将叶“type”设置为“ianaift:ethernetCsmacd”。因此，如果客户机在上面的<edit config>之后执行<get config>，它将获得：
<interface>
<name>6</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
<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>".
VLAN接口的名称限制为“<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>
<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:
当服务器处理此请求时，它会将叶“type”设置为“ianaift:ethernetCsmacd”。因此，如果客户机在上面的<edit config>之后执行<get config>，它将获得：
<interface>
<name>eth8</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
<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>
<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.
在本例中，通用主机具有由内核命名的接口。系统通过操作系统分配给接口的名称来标识物理接口。
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 E.4.
物理接口的配置如附录E.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>
<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>
<interface nc:operation="merge">
<name>acme-interface</name>
<vlan:base-interface>eth3</vlan:base-interface>
</interface>
Author's Address
作者地址
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-f系统
EMail: mbj@tail-f.com
EMail: mbj@tail-f.com