draft-ietf-netmod-interfaces-cfg-15.txt   draft-ietf-netmod-interfaces-cfg-16.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track December 23, 2013 Intended status: Standards Track January 23, 2014
Expires: June 26, 2014 Expires: July 27, 2014
A YANG Data Model for Interface Management A YANG Data Model for Interface Management
draft-ietf-netmod-interfaces-cfg-15 draft-ietf-netmod-interfaces-cfg-16
Abstract Abstract
This document defines a YANG data model for the management of network This document defines a YANG data model for the management of network
interfaces. It is expected that interface type specific data models interfaces. It is expected that interface type specific data models
augment the generic interfaces data model defined in this document. augment the generic interfaces data model defined in this document.
The data model includes configuration data and state data (status The data model includes configuration data and state data (status
information and counters for the collection of statistics). information and counters for the collection of statistics).
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 26, 2014. This Internet-Draft will expire on July 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6
3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6 3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6
3.2. Interface References . . . . . . . . . . . . . . . . . . . 8 3.2. Interface References . . . . . . . . . . . . . . . . . . . 8
3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 8 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 8
4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 9 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 10
5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 11 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 30 Appendix A. Example: Ethernet Interface Module . . . . . . . . . 31
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 32 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 33
Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 33 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 34
Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 35 Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 36
Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 38 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 39
E.1. Router with Restricted Interface Names . . . . . . . . . . 38 E.1. Router with Restricted Interface Names . . . . . . . . . . 39
E.2. Router with Arbitrary Interface Names . . . . . . . . . . 39 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 40
E.3. Ethernet Switch with Restricted Interface Names . . . . . 40 E.3. Ethernet Switch with Restricted Interface Names . . . . . 41
E.4. Generic Host with Restricted Interface Names . . . . . . . 40 E.4. Generic Host with Restricted Interface Names . . . . . . . 41
E.5. Generic Host with Arbitrary Interface Names . . . . . . . 41 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 42
Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 43 Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 44
F.1. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 43 F.1. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 44
F.2. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 43 F.2. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 44
F.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 43 F.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 44
F.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 43 F.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 44
F.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 43 F.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 44
F.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 44 F.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 45
F.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 44 F.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 45
F.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 44 F.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 45
F.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 44 F.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 45
F.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 44 F.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document defines a YANG [RFC6020] data model for the management This document defines a YANG [RFC6020] data model for the management
of network interfaces. It is expected that interface type specific of network interfaces. It is expected that interface type specific
data models augment the generic interfaces data model defined in this data models augment the generic interfaces data model defined in this
document. document.
Network interfaces are central to the management of many Internet Network interfaces are central to the management of many Internet
protocols. Thus, it is important to establish a common data model protocols. Thus, it is important to establish a common data model
skipping to change at page 3, line 32 skipping to change at page 3, line 32
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
The following terms are used within this document: The following terms are used within this document:
o system-controlled interface: An interface is said to be system- o system-controlled interface: An interface is said to be system-
controlled if the system creates and deletes the interface controlled if the system creates and deletes the interface
independently of what has been explicitly configured. Examples independently of what has been explicitly configured. Examples
are interfaces representing physical hardware that appear and are interfaces representing physical hardware that appear and
disappear when hardware (e.g., a line card) is added or removed. disappear when hardware (e.g., a line card or hot pluggable
System-controlled interfaces may also appear if a certain wireless interface) is added or removed. System-controlled
functionality is enabled (e.g., a loopback interface might appear interfaces may also appear if a certain functionality is enabled
if the IP protocol stack is enabled). (e.g., a loopback interface might appear if the IP protocol stack
is enabled).
o user-controlled interface: An interface is said to be user- o user-controlled interface: An interface is said to be user-
controlled if the creation of the interface is controlled by controlled if the creation of the interface is controlled by
adding explicit interface configuration to the running adding explicit interface configuration to the running
configuration datastore and the removal of the interface is configuration datastore and the removal of the interface is
controlled by removing explicit interface configuration from the controlled by removing explicit interface configuration from the
running configuration datastore. Examples are VLAN interfaces running configuration datastore. Examples are VLAN interfaces
configured on a system-controlled Ethernet interface. configured on a system-controlled Ethernet interface.
The following terms are defined in [RFC6241] and are not redefined The following terms are defined in [RFC6241] and are not redefined
skipping to change at page 5, line 41 skipping to change at page 5, line 41
configuration, i.e., it should be possible to configure an configuration, i.e., it should be possible to configure an
interface whose physical interface hardware is not present on the interface whose physical interface hardware is not present on the
device. It is recommended that devices that support dynamic device. It is recommended that devices that support dynamic
addition and removal of physical interfaces also support pre- addition and removal of physical interfaces also support pre-
provisioning. provisioning.
o The data model should support both physical interfaces as well as o The data model should support both physical interfaces as well as
logical interfaces. logical interfaces.
o The data model should include read-only counters in order to o The data model should include read-only counters in order to
gather statistics for octets, packets and errors, sent and gather statistics for sent and received octets and packets,
received. received packets with errors, and packets that could not be sent
due to errors.
3. Interfaces Data Model 3. Interfaces Data Model
This document defines the YANG module "ietf-interfaces", which has This document defines the YANG module "ietf-interfaces", which has
the following structure: the following structure:
+--rw interfaces +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
| +--rw name string | +--rw name string
| +--rw description? string | +--rw description? string
skipping to change at page 8, line 8 skipping to change at page 8, line 8
When a system-controlled interface is created by the system, the When a system-controlled interface is created by the system, the
system tries to apply the interface configuration in "/interfaces/ system tries to apply the interface configuration in "/interfaces/
interface" with the same name as the new interface. If no such interface" with the same name as the new interface. If no such
interface configuration is found, or if the configured type does not interface configuration is found, or if the configured type does not
match the real interface type, the system creates the interface match the real interface type, the system creates the interface
without applying explicit configuration. without applying explicit configuration.
When a user-controlled interface is created, the configuration When a user-controlled interface is created, the configuration
determines the name of the interface. 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.
3.2. Interface References 3.2. Interface References
An interface is identified by its name, which is unique within the An interface is identified by its name, which is unique within the
server. This property is captured in the "interface-ref" and server. This property is captured in the "interface-ref" and
"interface-state-ref" typedefs, which other YANG modules SHOULD use "interface-state-ref" typedefs, which other YANG modules SHOULD use
when they need to reference a configured interface or operationally when they need to reference a configured interface or operationally
used interface, respectively. used interface, respectively.
3.3. Interface Layering 3.3. Interface Layering
skipping to change at page 9, line 25 skipping to change at page 10, line 25
support the data model defined in this document, cannot have a 1-1 support the data model defined in this document, cannot have a 1-1
mapping between the "name" leaf and ifName. mapping between the "name" leaf and ifName.
The configured "description" of an "interface" has traditionally been The configured "description" of an "interface" has traditionally been
mapped to ifAlias in some implementations. This document allows this mapped to ifAlias in some implementations. This document allows this
mapping, but implementers should be aware of the differences in the mapping, but implementers should be aware of the differences in the
value space and persistence for these objects. See the YANG module value space and persistence for these objects. See the YANG module
definition of the leaf "description" in Section 5 for details. definition of the leaf "description" in Section 5 for details.
The IF-MIB also defines the writable object ifPromiscuousMode. Since The IF-MIB also defines the writable object ifPromiscuousMode. Since
this object typically is not a configuration object, it is not mapped this object typically is not implemented as a configuration object by
to the "ietf-interfaces" module. SNMP agents, it is not mapped to the "ietf-interfaces" module.
The ifMtu object from 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.
There are a number of counters in the IF-MIB that exist in two 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 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 were added to support high-speed interfaces with a data rate greater
than 20,000,000 bits/second. Today's implementations generally than 20,000,000 bits/second. Today's implementations generally
support such high-speed interfaces and hence only 64-bit counters are support such high-speed interfaces and hence only 64-bit counters are
provided in this data model. Note that NETCONF and SNMP may differ provided in this data model. Note that NETCONF and SNMP may differ
in the time granularity in which they provide access to the counters. in the time granularity in which they provide access to the counters.
For example, it is common that SNMP implementations cache counter For example, it is common that SNMP implementations cache counter
values for some time. values for some time.
The objects ifDescr and ifConnectorPresent from IF-MIB are not mapped
to the "ietf-interfaces" module.
The following tables list the YANG data nodes with corresponding The following tables list the YANG data nodes with corresponding
objects in the IF-MIB. objects in the IF-MIB.
+------------------------------------------+------------------------+ +--------------------------------------+----------------------------+
| YANG data node in | IF-MIB object | | YANG data node in | IF-MIB object |
| /interfaces-state/interface | | | /interfaces-state/interface | |
+------------------------------------------+------------------------+ +--------------------------------------+----------------------------+
| name | ifName | | name | ifName |
| type | ifType | | type | ifType |
| admin-status | ifAdminStatus | | admin-status | ifAdminStatus |
| oper-status | ifOperStatus | | oper-status | ifOperStatus |
| last-change | ifLastChange | | last-change | ifLastChange |
| if-index | ifIndex | | if-index | ifIndex |
| link-up-down-trap-enable | ifLinkUpDownTrapEnable | | link-up-down-trap-enable | ifLinkUpDownTrapEnable |
| phys-address | ifPhysAddress | | phys-address | ifPhysAddress |
| higher-layer-if / lower-layer-if | ifStackTable | | higher-layer-if and lower-layer-if | ifStackTable |
| speed | ifSpeed | | speed | ifSpeed and ifHSpeed |
| in-octets | ifHCInOctets | | discontinuity-time | ifCounterDiscontinuityTime |
| in-unicast-pkts | ifHCInUcastPkts | | in-octets | ifHCInOctets |
| in-broadcast-pkts | ifHCInBroadcastPkts | | in-unicast-pkts | ifHCInUcastPkts |
| in-multicast-pkts | ifHCInMulticastPkts | | in-broadcast-pkts | ifHCInBroadcastPkts |
| in-discards | ifInDiscards | | in-multicast-pkts | ifHCInMulticastPkts |
| in-errors | ifInErrors | | in-discards | ifInDiscards |
| in-unknown-protos | ifInUnknownProtos | | in-errors | ifInErrors |
| out-octets | ifHCOutOctets | | in-unknown-protos | ifInUnknownProtos |
| out-unicast-pkts | ifHCOutUcastPkts | | out-octets | ifHCOutOctets |
| out-broadcast-pkts | ifHCOutBroadcastPkts | | out-unicast-pkts | ifHCOutUcastPkts |
| out-multicast-pkts | ifHCOutMulticastPkts | | out-broadcast-pkts | ifHCOutBroadcastPkts |
| out-discards | ifOutDiscards | | out-multicast-pkts | ifHCOutMulticastPkts |
| out-errors | ifOutErrors | | out-discards | ifOutDiscards |
+------------------------------------------+------------------------+ | out-errors | ifOutErrors |
+--------------------------------------+----------------------------+
YANG state data nodes and related IF-MIB objects YANG state data nodes and related IF-MIB objects
+-----------------------------------------+---------------+ +-----------------------------------------+---------------+
| YANG data node in /interfaces/interface | IF-MIB object | | YANG data node in /interfaces/interface | IF-MIB object |
+-----------------------------------------+---------------+ +-----------------------------------------+---------------+
| description | ifAlias | | description | ifAlias |
+-----------------------------------------+---------------+ +-----------------------------------------+---------------+
YANG config data nodes and related IF-MIB objects YANG config data nodes and related IF-MIB objects
 End of changes. 11 change blocks. 
71 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/