draft-ietf-netmod-interfaces-cfg-10.txt   draft-ietf-netmod-interfaces-cfg-11.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 April 19, 2013 Intended status: Standards Track May 15, 2013
Expires: October 21, 2013 Expires: November 16, 2013
A YANG Data Model for Interface Management A YANG Data Model for Interface Management
draft-ietf-netmod-interfaces-cfg-10 draft-ietf-netmod-interfaces-cfg-11
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, state data and counters
for the collection of statistics.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 21, 2013. This Internet-Draft will expire on November 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 5 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The interface List . . . . . . . . . . . . . . . . . . . . 5 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6
3.2. Interface References . . . . . . . . . . . . . . . . . . . 6 3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6
3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 6 3.2. Interface References . . . . . . . . . . . . . . . . . . . 7
4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 7
5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 10 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 29 Appendix A. Example: Ethernet Interface Module . . . . . . . . . 30
Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 30 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 32
Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 31 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 33
Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 32 Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 34
E.1. Router with Restricted Interface Names . . . . . . . . . . 32 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 37
E.2. Router with Arbitrary Interface Names . . . . . . . . . . 33 E.1. Router with Restricted Interface Names . . . . . . . . . . 37
E.3. Ethernet Switch with Restricted Interface Names . . . . . 33 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 38
E.4. Generic Host with Restricted Interface Names . . . . . . . 34 E.3. Ethernet Switch with Restricted Interface Names . . . . . 39
E.5. Generic Host with Arbitrary Interface Names . . . . . . . 35 E.4. Generic Host with Restricted Interface Names . . . . . . . 39
Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 37 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 40
F.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 42
F.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 37 F.1. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 42
F.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 37 F.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 42
F.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 37 F.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 42
F.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 37 F.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 42
F.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 37 F.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 42
F.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 38 F.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 43
F.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 38 F.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 F.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 43
F.9. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
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
for how interfaces are identified and configured. for how interfaces are identified, configured, and monitored.
The data model includes configuration data, state data and counters
for the collection of statistics.
1.1. Terminology 1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 defined in [RFC6241] and are not redefined The following terms are defined in [RFC6241] and are not redefined
here: here:
o client o client
o configuration data
o server o server
o state data
The following terms are defined in [RFC6020] and are not redefined The following terms are defined in [RFC6020] and are not redefined
here: here:
o augment o augment
o data model o data model
o data node o data node
1.2. Tree Diagrams
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 Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node and "*"
denotes a "list" and "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
2. Objectives 2. Objectives
This section describes some of the design objectives for the model This section describes some of the design objectives for the model
presented in Section 5. presented in Section 5.
o It is recognized that existing implementations will have to map o It is recognized that existing implementations will have to map
the interface data model defined in this memo to their proprietary the interface data model defined in this memo to their proprietary
native data model. The data model should be simple to facilitate native data model. The data model should be simple to facilitate
such mappings. such mappings.
skipping to change at page 4, line 26 skipping to change at page 5, line 26
as-is, without requiring a mapping to a different native model. as-is, without requiring a mapping to a different native model.
o References to interfaces should be as simple as possible, o References to interfaces should be as simple as possible,
preferably by using a single leafref. preferably by using a single leafref.
o The mapping to ifIndex [RFC2863] used by SNMP to identify o The mapping to ifIndex [RFC2863] used by SNMP to identify
interfaces must be clear. interfaces must be clear.
o The model must support interface layering, both simple layering o The model must support interface layering, both simple layering
where one interface is layered on top of exactly one other where one interface is layered on top of exactly one other
interface, and more complex scenarios where one interface is interface, and more complex scenarios where one interface results
aggregated over N other interfaces, or when N interfaces are from the aggregation of N other interfaces, or when N interfaces
multiplexed over one other interface. are multiplexed over one other interface.
o The data model should support the pre-provisioning of interface o The data model should support the pre-provisioning of interface
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
logical interfaces.
o The data model should include read-only counters in order to
gather statistics for octets, packets and errors, sent and
received.
3. Interfaces Data Model 3. Interfaces Data Model
The data model in the module "ietf-interfaces" has the following This document defines the YANG module "ietf-interfaces", which has
structure, where square brackets are used to enclose a list's keys, the following structure:
"?" means that the leaf is optional, and "*" denotes a leaf-list:
+--rw interfaces +--rw interfaces
+--rw interface [name] | +--rw interface* [name]
+--rw name string | +--rw name string
+--rw description? string | +--rw description? string
+--rw type ianaift:iana-if-type | +--rw type ianaift:iana-if-type
+--rw location? string | +--rw enabled? boolean
+--rw enabled? boolean | +--rw link-up-down-trap-enable? enumeration
+--ro oper-status? enumeration +--ro interfaces-state
+--ro last-change? yang:date-and-time +--ro interface* [name]
+--ro if-index? int32 +--ro name string
+--rw link-up-down-trap-enable? enumeration +--ro type ianaift:iana-if-type
+--ro phys-address? yang:phys-address +--ro admin-status enumeration
+--ro higher-layer-if* interface-ref +--ro oper-status enumeration
+--ro lower-layer-if* interface-ref +--ro last-change? yang:date-and-time
+--ro speed? yang:gauge64 +--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 statistics
+--ro discontinuity-time? yang:date-and-time +--ro discontinuity-time yang:date-and-time
+--ro in-octets? yang:counter64 +--ro in-octets? yang:counter64
+--ro in-unicast-pkts? yang:counter64 +--ro in-unicast-pkts? yang:counter64
+--ro in-broadcast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64
+--ro in-multicast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64
+--ro in-discards? yang:counter32 +--ro in-discards? yang:counter32
+--ro in-errors? yang:counter32 +--ro in-errors? yang:counter32
+--ro in-unknown-protos? yang:counter32 +--ro in-unknown-protos? yang:counter32
+--ro out-octets? yang:counter64 +--ro out-octets? yang:counter64
+--ro out-unicast-pkts? yang:counter64 +--ro out-unicast-pkts? yang:counter64
+--ro out-broadcast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64
+--ro out-multicast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64
+--ro out-discards? yang:counter32 +--ro out-discards? yang:counter32
+--ro out-errors? yang:counter32 +--ro out-errors? yang:counter32
3.1. The interface List 3.1. The interface Lists
The data model for interfaces presented in this document uses a flat The data model for interfaces presented in this document uses a flat
list of interfaces. Each interface in the list is identified by its list of interfaces. Each interface in the list is identified by its
name. Furthermore, each interface has a mandatory "type" leaf, and name. Furthermore, each interface has a mandatory "type" leaf.
an optional "location" leaf. The combination of "type" and
"location" is unique within the interface list. There is one list of configured interfaces ("/interfaces/interface"),
and a separate list for the operational state of all interfaces
("/interfaces-state/interface").
It is expected that interface type specific data models augment the It is expected that interface type specific data models augment the
interface list, and use the "type" leaf to make the augmentation interface lists, and use the "type" leaf to make the augmentation
conditional. conditional.
As an example of such an interface type specific augmentation, As an example of such an interface type specific augmentation,
consider this YANG snippet. For a more complete example, see consider this YANG snippet. For a more complete example, see
Appendix A. Appendix A.
import interfaces { import interfaces {
prefix "if"; prefix "if";
} }
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
when "if:type = 'ethernetCsmacd'"; when "if:type = 'ethernetCsmacd'";
container ethernet { container ethernet {
leaf duplex { leaf duplex {
... ...
} }
} }
} }
The "location" leaf is a string. It is optional in the data model, For physical interfaces, the "name" is the device-specific name of
but if the type represents a physical interface, it is mandatory. the interface. It is used to identify the physical hardware
The format of this string is device- and type-dependent. The device interface. The 'config false' list "/interfaces-state/interface"
uses the location string to identify the physical or logical entity contains all currently existing interfaces on the device.
that the configuration applies to. For example, if a device has a
single array of 8 ethernet ports, the location can be one of the
strings "1" to "8". As another example, if a device has N cards of M
ports, the location can be on the form "n/m", such as "1/0".
How a client can learn which types and locations are present on a If the device supports arbitrarily named logical interfaces, the
certain device is outside the scope of this document. NETCONF server advertises the feature "arbitrary-names". If the
device does not advertise this feature, the names of logical
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.
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" typedef, server. This property is captured in the "interface-ref" and
which other YANG modules SHOULD use when they need to reference an "interface-state-ref" typedefs, which other YANG modules SHOULD use
existing interface. when they need to reference a configured interface or operationally
used interface, respectively.
3.3. Interface Layering 3.3. Interface Layering
There is no generic mechanism for how an interface is configured to There is no generic mechanism for how an interface is configured to
be layered on top of some other interface. It is expected that be layered on top of some other interface. It is expected that
interface type specific models define their own data nodes for interface type specific models define their own data nodes for
interface layering, by using "interface-ref" types to reference lower interface layering, by using "interface-ref" types to reference lower
layers. layers.
Below is an example of a model with such nodes. For a more complete Below is an example of a model with such nodes. For a more complete
skipping to change at page 8, line 8 skipping to change at page 9, line 8
} }
// other bonding config params, failover times etc. // other bonding config params, failover times etc.
} }
Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
represent a read-only view of the interface layering hierarchy. represent a read-only view of the interface layering hierarchy.
4. Relationship to the IF-MIB 4. Relationship to the IF-MIB
If the device implements IF-MIB [RFC2863], each entry in the If the device implements IF-MIB [RFC2863], each entry in the
"interface" list is typically mapped to one ifEntry. The "if-index" "/interfaces-state/interface" list is typically mapped to one
leaf MUST contain the value of the corresponding ifEntry's ifIndex. ifEntry. The "if-index" leaf MUST contain the value of the
corresponding ifEntry's ifIndex.
In most cases, the "name" of an "interface" entry is mapped to In most cases, the "name" of an "interface" entry is mapped to
ifName. ifName is defined as an DisplayString [RFC2579] which uses a ifName. ifName is defined as an DisplayString [RFC2579] which uses a
7-bit ASCII character set. An implementation MAY restrict the 7-bit ASCII character set. An implementation MUST restrict the
allowed values for "name" to match the restrictions of ifName. allowed values for "name" to match the restrictions of ifName.
The IF-MIB allows two different ifEntries to have the same ifName. The IF-MIB allows two different ifEntries to have the same ifName.
Devices that support this feature, and also support the configuration Devices that support this feature, and also support the data model
of these interfaces using the "interface" list, cannot have a 1-1 defined in this document, cannot have a 1-1 mapping between the
mapping between the "name" leaf and ifName. "name" leaf and ifName.
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.
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 a configuration object, it is not mapped
to the "ietf-interfaces" module. to the "ietf-interfaces" module.
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 YANG module
contains the 64 bits counters only. 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.
The following table lists the YANG data nodes with corresponding The following table lists the YANG data nodes with corresponding
objects in the IF-MIB. objects in the IF-MIB.
+----------------------------------+------------------------+ +----------------------------------+------------------------+
| YANG data node | IF-MIB object | | YANG data node | IF-MIB object |
+----------------------------------+------------------------+ +----------------------------------+------------------------+
| interface | ifEntry | | interface | ifEntry |
| name | ifName | | name | ifName |
| description | ifAlias | | description | ifAlias |
| type | ifType | | type | ifType |
| enabled | ifAdminStatus | | enabled / 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 / lower-layer-if | ifStackTable |
| speed | ifSpeed | | speed | ifSpeed |
| in-octets | ifHCInOctets | | in-octets | ifHCInOctets |
| in-unicast-pkts | ifHCInUcastPkts | | in-unicast-pkts | ifHCInUcastPkts |
| in-broadcast-pkts | ifHCInBroadcastPkts | | in-broadcast-pkts | ifHCInBroadcastPkts |
skipping to change at page 9, line 35 skipping to change at page 10, line 35
| in-errors | ifInErrors | | in-errors | ifInErrors |
| in-unknown-protos | ifInUnknownProtos | | in-unknown-protos | ifInUnknownProtos |
| out-octets | ifHCOutOctets | | out-octets | ifHCOutOctets |
| out-unicast-pkts | ifHCOutUcastPkts | | out-unicast-pkts | ifHCOutUcastPkts |
| out-broadcast-pkts | ifHCOutBroadcastPkts | | out-broadcast-pkts | ifHCOutBroadcastPkts |
| out-multicast-pkts | ifHCOutMulticastPkts | | out-multicast-pkts | ifHCOutMulticastPkts |
| out-discards | ifOutDiscards | | out-discards | ifOutDiscards |
| out-errors | ifOutErrors | | out-errors | ifOutErrors |
+----------------------------------+------------------------+ +----------------------------------+------------------------+
Mapping of YANG data nodes to IF-MIB objects YANG data nodes and related IF-MIB objects
5. Interfaces YANG Module 5. Interfaces YANG Module
This YANG module imports a typedef from This YANG module imports typedefs from [I-D.ietf-netmod-rfc6021-bis]
[I-D.ietf-netmod-iana-if-type]. and [I-D.ietf-netmod-iana-if-type].
RFC Ed.: update the date below with the date of RFC publication and RFC Ed.: update the date below with the date of RFC publication and
remove this note. remove this note.
<CODE BEGINS> file "ietf-interfaces@2013-02-06.yang" <CODE BEGINS> file "ietf-interfaces@2013-05-15.yang"
module ietf-interfaces { module ietf-interfaces {
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
prefix if; prefix if;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import iana-if-type { import iana-if-type {
skipping to change at page 10, line 47 skipping to change at page 11, line 47
WG Chair: Juergen Schoenwaelder WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de> <mailto:j.schoenwaelder@jacobs-university.de>
Editor: Martin Bjorklund Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>"; <mailto:mbj@tail-f.com>";
description description
"This module contains a collection of YANG definitions for "This module contains a collection of YANG definitions for
managing network interfaces. managing network interfaces.
Copyright (c) 2012 IETF Trust and the persons identified as Copyright (c) 2013 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this // RFC Ed.: replace XXXX with actual RFC number and remove this
// note. // note.
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
revision 2013-02-06 { revision 2013-05-15 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for Interface Management"; "RFC XXXX: A YANG Data Model for Interface Management";
} }
/* Typedefs */ /* Typedefs */
typedef interface-ref { typedef interface-ref {
type leafref { type leafref {
path "/if:interfaces/if:interface/if:name"; path "/if:interfaces/if:interface/if:name";
} }
description description
"This type is used by data models that need to reference "This type is used by data models that need to reference
interfaces."; 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.";
} }
/* Features */ /* Features */
feature arbitrary-names { feature arbitrary-names {
description description
"This feature indicates that the server allows interfaces to "This feature indicates that the device allows logical
be named arbitrarily."; interfaces to be named arbitrarily.";
}
feature pre-provisioning {
description
"This feature indicates that the device supports
pre-provisioning of interface configuration, i.e., it is
possible to configure an interface whose physical interface
hardware is not present on the device.";
} }
feature if-mib { feature if-mib {
description description
"This feature indicates that the server implements IF-MIB."; "This feature indicates that the device implements IF-MIB.";
reference reference
"RFC 2863: The Interfaces Group MIB"; "RFC 2863: The Interfaces Group MIB";
} }
/* Data nodes */ /* Data nodes */
container interfaces { container interfaces {
description description
"Interface parameters."; "Interface configuration parameters.";
list interface { list interface {
key "name"; key "name";
unique "type location";
description description
"The list of interfaces on the device."; "The list of configured interfaces on the device.
leaf name { The operational state of an interface is available in the
/interfaces-state/interface list. If the configuration of a
physical interface cannot be used by the system (e.g., the
physical interface present is not matching the interface
type), then the configuration is not applied to the physical
interface shown in the /interfaces-state/interface list. If
the the configuration of a logical interface cannot be used
by the system, the configured interface is not instantiated
in the /interfaces-state/interface list.";
leaf name {
type string; type string;
description description
"The name of the interface. "The name of the interface.
A device MAY restrict the allowed values for this leaf, A device MAY restrict the allowed values for this leaf,
possibly depending on the type and location. possibly depending on the type of the interface.
If the device allows arbitrarily named interfaces, the For physical interfaces, this leaf is the device-specific
feature 'arbitrary-names' is advertised. name of the interface. The 'config false' list
/interfaces-state/interface contains the currently
existing interfaces on the device.
If a client tries to create configuration for a physical
interface that is not present, 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.
If the device supports pre-provisioning of interface
configuration, the feature 'pre-provisioning' is
advertised.
If the device allows arbitrarily named logical interfaces,
the feature 'arbitrary-names' is advertised.
When a configured logical interface is created by the
system, it is instantiated in the
/interface-state/interface list. Since the name in that
list MAY be mapped to ifName by an implementation, such an
implementation MUST restrict the allowed values for this
leaf so that it matches the restrictions of ifName.
This leaf MAY be mapped to ifName by an implementation.
Such an implementation MAY restrict the allowed values for
this leaf so that it matches the restrictions of ifName.
If a NETCONF server that implements this restriction is If a NETCONF server that implements this restriction is
sent a value that doesn't match the restriction, it MUST sent a value that doesn't match the restriction, it MUST
reply with an rpc-error with the error-tag reply with an rpc-error with the error-tag
'invalid-value'."; 'invalid-value'.";
reference
"RFC 2863: The Interfaces Group MIB - ifName";
} }
leaf description { leaf description {
type string; type string;
description description
"A textual description of the interface. "A textual description of the interface.
This leaf MAY be mapped to ifAlias by an implementation. This leaf MAY be mapped to ifAlias by an implementation.
Such an implementation MAY restrict the allowed values for Such an implementation MUST restrict the allowed values
this leaf so that it matches the restrictions of ifAlias. for this leaf so that it matches the restrictions of
ifAlias.
If a NETCONF server that implements this restriction is If a NETCONF server that implements this restriction is
sent a value that doesn't match the restriction, it MUST sent a value that doesn't match the restriction, it MUST
reply with an rpc-error with the error-tag reply with an rpc-error with the error-tag
'invalid-value'."; 'invalid-value'.
Since ifAlias is defined to be stored in non-volatile
storage, the SNMP implementation MUST map ifAlias to the
value of 'description' in the persistently stored
datastore.
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 if
it modifies this single leaf in 'startup', or if it
performs an implicit copy-config from 'running' to
'startup'.
If the device does not support ':startup', ifAlias MUST
be mapped to the 'description' leaf in the 'running'
datastore.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifAlias"; "RFC 2863: The Interfaces Group MIB - ifAlias";
} }
leaf type { leaf type {
type ianaift:iana-if-type; type ianaift:iana-if-type;
mandatory true; mandatory true;
description description
"The type of the interface. "The type of the interface.
When an interface entry is created, a server MAY When an interface entry is created, a server MAY
initialize the type leaf with a valid value, e.g., if it initialize the type leaf with a valid value, e.g., if it
is possible to derive the type from the name of the is possible to derive the type from the name of the
interface."; 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 reference
"RFC 2863: The Interfaces Group MIB - ifType"; "RFC 2863: The Interfaces Group MIB - ifType";
} }
leaf location { 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.
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.
If this node is not configured, the value 'enabled' is
operationally used by the server for interfaces which 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";
}
}
}
container interfaces-state {
config false;
description
"Data nodes for the operational state of interfaces.";
list interface {
key "name";
description
"The list of interfaces on the device.
Physical interfaces detected by the system are always
present in this list, if they are configured or not.";
leaf name {
type string; type string;
description description
"The device-specific location of the interface of a "The name of the interface.
particular type. The format of the location string
depends on the interface type and the device. If a
NETCONF server is sent a value that doesn't match this
format, it MUST reply with an rpc-error with the error-tag
'invalid-value'.
If the interface's type represents a physical interface, This leaf MAY be mapped to ifName by an implementation.
this leaf MUST be set. Such an implementation MUST restrict the values
for this leaf so that it matches the restrictions of
ifName.";
reference
"RFC 2863: The Interfaces Group MIB - ifName";
}
When an interface entry is created, a server MAY leaf type {
initialize the location leaf with a valid value, e.g., if type ianaift:iana-if-type;
it is possible to derive the location from the name of mandatory true;
the interface."; description
"The type of the interface.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
} }
leaf enabled { leaf admin-status {
type boolean; if-feature if-mib;
default "true"; 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 description
"The desired state of the interface. "The desired state of the interface.
This leaf contains the configured, desired state of the This leaf has the same semantics as ifAdminStatus.";
interface. Systems that implement the IF-MIB use the
value of this leaf to set IF-MIB.ifAdminStatus to 'up' or
'down' after an ifEntry has been initialized, as described
in RFC 2863.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifAdminStatus"; "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
} }
leaf oper-status { leaf oper-status {
type enumeration { type enumeration {
enum up { enum up {
value 1; value 1;
description description
"Ready to pass packets."; "Ready to pass packets.";
} }
skipping to change at page 14, line 43 skipping to change at page 18, line 43
value 6; value 6;
description description
"Some component (typically hardware) is missing."; "Some component (typically hardware) is missing.";
} }
enum lower-layer-down { enum lower-layer-down {
value 7; value 7;
description description
"Down due to state of lower-layer interface(s)."; "Down due to state of lower-layer interface(s).";
} }
} }
config false; mandatory true;
description description
"The current operational state of the interface. "The current operational state of the interface.
If 'enabled' is 'false' then 'oper-status' This leaf has the same semantics as ifOperStatus.";
should be 'down'. If 'enabled' is changed to 'true'
then 'oper-status' should change to 'up' if the interface
is ready to transmit and receive network traffic; it
should change to 'dormant' if the interface is waiting for
external actions (such as a serial line waiting for an
incoming connection); it should remain in the 'down' state
if and only if there is a fault that prevents it from
going to the 'up' state; it should remain in the
'not-present' state if the interface has missing
(typically, hardware) components.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifOperStatus"; "RFC 2863: The Interfaces Group MIB - ifOperStatus";
} }
leaf last-change { leaf last-change {
type yang:date-and-time; type yang:date-and-time;
config false;
description description
"The time the interface entered its current operational "The time the interface entered its current operational
state. If the current state was entered prior to the state. If the current state was entered prior to the
last re-initialization of the local network management last re-initialization of the local network management
subsystem, then this node is not present."; subsystem, then this node is not present.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifLastChange"; "RFC 2863: The Interfaces Group MIB - ifLastChange";
} }
leaf if-index { leaf if-index {
if-feature if-mib; if-feature if-mib;
type int32 { type int32 {
range "1..2147483647"; range "1..2147483647";
} }
config false; mandatory true;
description description
"The ifIndex value for the ifEntry represented by this "The ifIndex value for the ifEntry represented by this
interface. interface.";
Media-specific modules must specify how the type is
mapped to entries in the ifTable.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifIndex"; "RFC 2863: The Interfaces Group MIB - ifIndex";
} }
leaf link-up-down-trap-enable {
if-feature if-mib;
type enumeration {
enum enabled {
value 1;
}
enum disabled {
value 2;
}
}
description
"Indicates 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 which do
not operate on top of any other interface (i.e., there are
no 'lower-layer-if' entries), and 'disabled' otherwise.";
reference
"RFC 2863: The Interfaces Group MIB -
ifLinkUpDownTrapEnable";
}
leaf phys-address { leaf phys-address {
type yang:phys-address; type yang:phys-address;
config false;
description description
"The interface's address at its protocol sub-layer. For "The interface's address at its protocol sub-layer. For
example, for an 802.x interface, this object normally example, for an 802.x interface, this object normally
contains a MAC address. The interface's media-specific contains a MAC address. The interface's media-specific
modules must define the bit and byte ordering and the modules must define the bit and byte ordering and the
format of the value of this object. For interfaces that do format of the value of this object. For interfaces that do
not have such an address (e.g., a serial line), this node not have such an address (e.g., a serial line), this node
is not present."; is not present.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifPhysAddress"; "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
} }
leaf-list higher-layer-if { leaf-list higher-layer-if {
type interface-ref; type interface-state-ref;
config false;
description description
"A list of references to interfaces layered on top of this "A list of references to interfaces layered on top of this
interface."; interface.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifStackTable"; "RFC 2863: The Interfaces Group MIB - ifStackTable";
} }
leaf-list lower-layer-if { leaf-list lower-layer-if {
type interface-ref; type interface-state-ref;
config false;
description description
"A list of references to interfaces layered underneath this "A list of references to interfaces layered underneath this
interface."; interface.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifStackTable"; "RFC 2863: The Interfaces Group MIB - ifStackTable";
} }
leaf speed { leaf speed {
type yang:gauge64; type yang:gauge64;
units "bits / second"; units "bits / second";
config false;
description description
"An estimate of the interface's current bandwidth in bits "An estimate of the interface's current bandwidth in bits
per second. For interfaces which do not vary in per second. For interfaces that do not vary in
bandwidth or for those where no accurate estimation can bandwidth or for those where no accurate estimation can
be made, this node should contain the nominal bandwidth. be made, this node should contain the nominal bandwidth.
For interfaces that has no concept of bandwidth, this For interfaces that have no concept of bandwidth, this
node is not present."; node is not present.";
reference reference
"RFC 2863: The Interfaces Group MIB - "RFC 2863: The Interfaces Group MIB -
ifSpeed, ifHighSpeed"; ifSpeed, ifHighSpeed";
} }
container statistics { container statistics {
config false;
description description
"A collection of interface-related statistics objects."; "A collection of interface-related statistics objects.";
leaf discontinuity-time { leaf discontinuity-time {
type yang:date-and-time; type yang:date-and-time;
mandatory true;
description description
"The time on the most recent occasion at which any one or "The time on the most recent occasion at which any one or
more of this interface's counters suffered a more of this interface's counters suffered a
discontinuity. If no such discontinuities have occurred discontinuity. If no such discontinuities have occurred
since the last re-initialization of the local management since the last re-initialization of the local management
subsystem, then this node contains the time the local subsystem, then this node contains the time the local
management subsystem re-initialized itself."; management subsystem re-initialized itself.";
} }
leaf in-octets { leaf in-octets {
skipping to change at page 24, line 10 skipping to change at page 27, line 10
name: ietf-interfaces name: ietf-interfaces
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces
prefix: if prefix: if
reference: RFC XXXX reference: RFC XXXX
7. Security Considerations 7. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure secure transport layer and the mandatory-to-implement secure
transport is SSH [RFC6242]. 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.
There are a number of data nodes defined in the YANG module which are There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <edit-config>) in some network environments. Write operations (e.g., <edit-config>)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/interfaces/interface: This list specifies the configured interfaces /interfaces/interface: This list specifies the configured interfaces
skipping to change at page 26, line 11 skipping to change at page 29, line 11
The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav
Lhotka, and Juergen Schoenwaelder for their helpful comments. Lhotka, and Juergen Schoenwaelder for their helpful comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-netmod-iana-if-type] [I-D.ietf-netmod-iana-if-type]
Bjorklund, M., "IANA Interface Type and Address Family Bjorklund, M., "IANA Interface Type and Address Family
YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in YANG Modules", draft-ietf-netmod-iana-if-type-06 (work in
progress), April 2012. progress), April 2013.
[I-D.ietf-netmod-rfc6021-bis]
Schoenwaelder, J., "Common YANG Data Types",
draft-ietf-netmod-rfc6021-bis-02 (work in progress),
May 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
skipping to change at page 27, line 5 skipping to change at page 29, line 45
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011. RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
March 2012.
Appendix A. Example: Ethernet Interface Module Appendix A. Example: Ethernet Interface Module
This section gives a simple example of how an Ethernet interface This section gives a simple example of how an Ethernet interface
module could be defined. It demonstrates how media-specific module could be defined. It demonstrates how media-specific
configuration parameters can be conditionally augmented to the configuration parameters can be conditionally augmented to the
generic interface list. It is not intended as a complete module for 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. ethernet configuration.
module ex-ethernet { module ex-ethernet {
namespace "http://example.com/ethernet"; namespace "http://example.com/ethernet";
prefix "eth"; prefix "eth";
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
// configuration parameters for ethernet interfaces
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
when "if:type = 'ethernetCsmacd'"; when "if:type = 'ethernetCsmacd'";
container ethernet { container ethernet {
must "../if:location" {
description
"An ethernet interface must specify the physical location
of the ethernet hardware.";
}
choice transmission-params { choice transmission-params {
case auto { case auto {
leaf auto-negotiate { leaf auto-negotiate {
type empty; type empty;
} }
} }
case manual { case manual {
leaf duplex { leaf duplex {
type enumeration { type enumeration {
enum "half"; enum "half";
skipping to change at page 28, line 47 skipping to change at page 31, line 4
enum "10Mb"; enum "10Mb";
enum "100Mb"; enum "100Mb";
enum "1Gb"; enum "1Gb";
enum "10Gb"; enum "10Gb";
} }
} }
} }
} }
// other ethernet specific params... // other ethernet specific params...
} }
}
// operational state parameters for ethernet interfaces
augment "/if:interfaces-state/if:interface" {
when "if:type = 'ethernetCsmacd'";
container ethernet {
leaf duplex {
type enumeration {
enum "half";
enum "full";
}
}
// other ethernet specific params...
}
} }
} }
Appendix B. Example: Ethernet Bonding Interface Module Appendix B. Example: Ethernet Bonding Interface Module
This section gives an example of how interface layering can be This section gives an example of how interface layering can be
defined. An ethernet bonding interface is defined, which bonds defined. An ethernet bonding interface is defined, which bonds
several ethernet interfaces into one logical interface. several ethernet interfaces into one logical interface.
module ex-ethernet-bonding { module ex-ethernet-bonding {
skipping to change at page 31, line 10 skipping to change at page 34, line 10
} }
} }
} }
} }
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 This section gives an example of a reply to the NETCONF <get> request
for a device that implements the example data models above. for a device that implements the example data models above.
<rpc-reply <rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101"> message-id="101">
<data> <data>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" <interfaces
xmlns:vlan="http://example.com/vlan"> xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
<interface> xmlns:vlan="http://example.com/vlan">
<name>eth0</name>
<type>ethernetCsmacd</type> <interface>
<location>0</location> <name>eth0</name>
<enabled>true</enabled> <type>ethernetCsmacd</type>
<if-index>2</if-index> <enabled>false</enabled>
</interface> </interface>
<interface>
<name>eth1</name> <interface>
<type>ethernetCsmacd</type> <name>eth1</name>
<location>1</location> <type>ethernetCsmacd</type>
<enabled>true</enabled> <enabled>true</enabled>
<if-index>7</if-index> <vlan:vlan-tagging>true</vlan:vlan-tagging>
<vlan:vlan-tagging>true</vlan:vlan-tagging> </interface>
</interface>
<interface> <interface>
<name>eth1.10</name> <name>eth1.10</name>
<type>l2vlan</type> <type>l2vlan</type>
<enabled>true</enabled> <enabled>true</enabled>
<if-index>9</if-index> <vlan:base-interface>eth1</vlan:base-interface>
<vlan:base-interface>eth1</vlan:base-interface> <vlan:vlan-id>10</vlan:vlan-id>
<vlan:vlan-id>10</vlan:vlan-id> </interface>
</interface>
</interfaces> <interface>
</data> <name>lo1</name>
</rpc-reply> <type>softwareLoopback</type>
<enabled>true</enabled>
</interface>
</interfaces>
<interfaces-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<type>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:00Z</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>eth1</name>
<type>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:00Z</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>eth1.10</name>
<type>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:00Z</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<!-- This interface is not configured -->
<interface>
<name>eth2</name>
<type>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:00Z</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
<interface>
<name>lo1</name>
<type>softwareLoopback</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>1</if-index>
<statistics>
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time>
<!-- counters now shown here -->
</statistics>
</interface>
</interfaces-state>
</data>
</rpc-reply>
Appendix E. Examples: Interface Naming Schemes Appendix E. Examples: Interface Naming Schemes
This section gives examples of some implementation strategies. 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 logical interfaces can be configured.
E.1. Router with Restricted Interface Names E.1. Router with Restricted Interface Names
In this example, a router has support for 4 line cards, each with 8 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, 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- or and the ports on each card from 0 to 7. Each card has fast- or
gigabit-ethernet ports. gigabit-ethernet ports.
The implementation restricts the names of the interfaces to one of The device-specific names for these physical interfaces are
"fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an "fastethernet-N/M" or "gigabitethernet-N/M".
interface is a string on the form "N/M". The implementation auto-
initializes the values for "type" and "location" based on the The name of a vlan interface is restricted to the form
"<physical-interface-name>.<subinterface-number>".
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. interface name.
The NETCONF server does not advertise the 'arbitrary-names' feature The NETCONF server does not advertise the 'arbitrary-names' feature
in the <hello> message. in the <hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure a physical interface by sending an
containing: <edit-config> containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>fastethernet-1/0</name> <name>fastethernet-1/0</name>
</interface> </interface>
When the server processes this request, it will set the leaf "type" When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "1/0". Thus, if the client to "ethernetCsmacd". Thus, if the client performs a <get-config>
performs a <get-config> right after the <edit-config> above, it will right after the <edit-config> above, it will get:
get:
<interface> <interface>
<name>fastethernet-1/0</name> <name>fastethernet-1/0</name>
<type>ethernetCsmacd</type> <type>ethernetCsmacd</type>
<location>1/0</location>
</interface> </interface>
If the client tries to change the location of this interface with an The client can configure a vlan interface by sending an <edit-config>
<edit-config> containing: containing:
<interface nc:operation="create">
<name>fastethernet-1/0.10005</name>
<type>l2-vlan</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:
<interface nc:operation="merge"> <interface nc:operation="merge">
<name>fastethernet-1/0</name> <name>fastethernet-1/0</name>
<location>1/1</location> <type>tunnel</type>
</interface> </interface>
then the server will reply with an "invalid-value" error, since the then the server will reply with an "invalid-value" error, since the
new location does not match the name. new type does not match the name.
E.2. Router with Arbitrary Interface Names E.2. Router with Arbitrary Interface Names
In this example, a router has support for 4 line cards, each with 8 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, 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- or and the ports on each card from 0 to 7. Each card has fast- or
gigabit-ethernet ports. gigabit-ethernet ports.
The implementation does not restrict the interface names. This The device-specific names for these physical interfaces are
allows to more easily apply the interface configuration to a "fastethernet-N/M" or "gigabitethernet-N/M".
different physical interface. However, the additional level of
indirection also makes it a bit more complex to map interface names The implementation does not restrict the logical interface names.
found in other protocols to configuration entries. The "location" of This allows to more easily apply the interface configuration to a
an interface is a string on the form "N/M". 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 The NETCONF server advertises the 'arbitrary-names' feature in the
<hello> message. <hello> message.
An operator can configure a new interface by sending an <edit-config> Physical interfaces are configured as in Appendix E.1.
containing:
An operator can configure a logical interface by sending an
<edit-config> containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>acme-interface</name> <name>acme-interface</name>
<type>ethernetCsmacd</type> <type>l2-vlan</type>
<location>1/0</location> <vlan:base-interface>fastethernet-1/0</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface> </interface>
If necessary, the operator can move the configuration named If necessary, the operator can move the configuration named
"acme-interface" over to a different physical interface with an "acme-interface" over to a different physical interface with an
<edit-config> containing: <edit-config> containing:
<interface nc:operation="merge"> <interface nc:operation="merge">
<name>acme-interface</name> <name>acme-interface</name>
<location>2/4</location> <vlan:base-interface>fastethernet-1/1</vlan:base-interface>
</interface> </interface>
E.3. Ethernet Switch with Restricted Interface Names E.3. Ethernet Switch with Restricted Interface Names
In this example, an ethernet switch has a number of ports, each port In this example, an ethernet switch has a number of ports, each port
identified by a simple port number. identified by a simple port number.
The implementation restricts the interface names to numbers that The device-specific names for the physical interfaces are numbers
match the physical port number. that match the physical port number.
The NETCONF server does not advertise the 'arbitrary-names' feature
in the <hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure a physical interface by sending an
containing: <edit-config> containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>6</name> <name>6</name>
</interface> </interface>
When the server processes this request, it will set the leaf "type" When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "6". Thus, if the client to "ethernetCsmacd". Thus, if the client performs a <get-config>
performs a <get-config> right after the <edit-config> above, it will right after the <edit-config> above, it will get:
get:
<interface> <interface>
<name>6</name> <name>6</name>
<type>ethernetCsmacd</type> <type>ethernetCsmacd</type>
<location>6</location>
</interface> </interface>
If the client tries to change the location of this interface with an
<edit-config> containing:
<interface nc:operation="merge">
<name>6</name>
<location>5</location>
</interface>
then the server will reply with an "invalid-value" error, since the
new location does not match the name.
E.4. Generic Host with Restricted Interface Names E.4. Generic Host with Restricted Interface Names
In this example, a generic host has interfaces named by the kernel In this example, a generic host has interfaces named by the kernel.
and without easily usable location information. The system The system identifies the physical interface by the name assigned by
identifies the physical interface by the name assigned by the the operating system to the interface.
operating system to the interface.
The implementation restricts the interface name to the operating The name of a vlan interface is restricted to the form
system level name of the physical interface. "<physical-interface-name>:<vlan-number>".
The NETCONF server does not advertise the 'arbitrary-names' feature The NETCONF server does not advertise the 'arbitrary-names' feature
in the <hello> message. in the <hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure an interface by sending an <edit-config>
containing: containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>eth8</name> <name>eth8</name>
</interface> </interface>
When the server processes this request, it will set the leaf "type" When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "eth8". Thus, if the client to "ethernetCsmacd". Thus, if the client performs a <get-config>
performs a <get-config> right after the <edit-config> above, it will right after the <edit-config> above, it will get:
get:
<interface> <interface>
<name>eth8</name> <name>eth8</name>
<type>ethernetCsmacd</type> <type>ethernetCsmacd</type>
<location>eth8</location>
</interface> </interface>
If the client tries to change the location of this interface with an The client can configure a vlan interface by sending an <edit-config>
<edit-config> containing: containing:
<interface nc:operation="merge"> <interface nc:operation="create">
<name>eth8</name> <name>eth8:5</name>
<location>eth7</location> <type>l2-vlan</type>
<vlan:base-interface>eth8</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface> </interface>
then the server will reply with an "invalid-value" error, since the
new location does not match the name.
E.5. Generic Host with Arbitrary Interface Names E.5. Generic Host with Arbitrary Interface Names
In this example, a generic host has interfaces named by the kernel In this example, a generic host has interfaces named by the kernel.
and without easily usable location information. The system The system identifies the physical interface by the name assigned by
identifies the physical interface by the name assigned by the the operating system to the interface.
operating system to the interface.
The implementation does not restrict the interface name to the The implementation does not restrict the logical interface names.
operating system level name of the physical interface. This allows This allows to more easily apply the interface configuration to a
to more easily apply the interface configuration to a different different interface. However, the additional level of indirection
physical interface. However, the additional level of indirection
also makes it a bit more complex to map interface names found in also makes it a bit more complex to map interface names found in
other protocols to configuration entries. other protocols to configuration entries.
The NETCONF server advertises the 'arbitrary-names' feature in the The NETCONF server advertises the 'arbitrary-names' feature in the
<hello> message. <hello> message.
An operator can configure a new interface by sending an <edit-config> Physical interfaces are configured as in Appendix E.4.
containing:
An operator can configure a logical interface by sending an
<edit-config> containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>acme-interface</name> <name>acme-interface</name>
<type>ethernetCsmacd</type> <type>l2-vlan</type>
<location>eth4</location> <vlan:base-interface>eth8</vlan:base-interface>
<vlan:vlan-id>5</vlan:vlan-id>
</interface> </interface>
If necessary, the operator can move the configuration named If necessary, the operator can move the configuration named
"acme-interface" over to a different physical interface with an "acme-interface" over to a different physical interface with an
<edit-config> containing: <edit-config> containing:
<interface nc:operation="merge"> <interface nc:operation="merge">
<name>acme-interface</name> <name>acme-interface</name>
<location>eth3</location> <vlan:base-interface>eth3</vlan:base-interface>
</interface> </interface>
Appendix F. ChangeLog Appendix F. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
F.1. Version -08 F.1. Version -11
o Separated the operational state from the configuration.
o Removed 'location', and instead use the name to identify physical
interfaces.
o Added the feature 'pre-provisioning'.
o Made 'oper-status' and 'if-index' mandatory in the data model.
o Added 'admin-status'.
o Clarified why description can be mapped to ifAlias.
o Clarified that 64-bit counters only are used, where there exist
64-bit and 32-bit counters in IF-MIB.
o Updated Security Considerations section with a reference to NACM.
F.2. Version -08
o Removed the mtu leaf. o Removed the mtu leaf.
o Added examples of different interface naming schemes. o Added examples of different interface naming schemes.
F.2. Version -07 F.3. Version -07
o Made leaf speed config false. o Made leaf speed config false.
F.3. Version -06 F.4. Version -06
o Added oper-status leaf. o Added oper-status leaf.
o Added leaf-lists higher-layer-if and lower-layer-if, that show the o Added leaf-lists higher-layer-if and lower-layer-if, that show the
interface layering. interface layering.
o Added container statistics with counters. o Added container statistics with counters.
F.4. Version -05 F.5. Version -05
o Added an Informative References section. o Added an Informative References section.
o Updated the Security Considerations section. o Updated the Security Considerations section.
o Clarified the behavior of an NETCONF server when invalid values o Clarified the behavior of an NETCONF server when invalid values
are received. are received.
F.5. Version -04 F.6. Version -04
o Clarified why ifPromiscuousMode is not part of this data model. o Clarified why ifPromiscuousMode is not part of this data model.
o Added a table that shows the mapping between this YANG data model o Added a table that shows the mapping between this YANG data model
and IF-MIB. and IF-MIB.
F.6. Version -03 F.7. Version -03
o Added the section Relationship to the IF-MIB. o Added the section Relationship to the IF-MIB.
o Changed if-index to be a leaf instead of leaf-list. o Changed if-index to be a leaf instead of leaf-list.
o Explained the notation used in the data model tree picture. o Explained the notation used in the data model tree picture.
F.7. Version -02 F.8. Version -02
o Editorial fixes o Editorial fixes
F.8. Version -01 F.9. Version -01
o Changed leaf "if-admin-status" to leaf "enabled". o Changed leaf "if-admin-status" to leaf "enabled".
o Added Security Considerations o Added Security Considerations
Author's Address Author's Address
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
 End of changes. 113 change blocks. 
311 lines changed or deleted 600 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/