--- 1/draft-ietf-netmod-interfaces-cfg-13.txt 2013-12-09 14:58:06.381115842 -0800 +++ 2/draft-ietf-netmod-interfaces-cfg-14.txt 2013-12-09 14:58:06.453116891 -0800 @@ -1,43 +1,43 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems -Intended status: Standards Track November 7, 2013 -Expires: May 11, 2014 +Intended status: Standards Track December 7, 2013 +Expires: June 10, 2014 A YANG Data Model for Interface Management - draft-ietf-netmod-interfaces-cfg-13 + draft-ietf-netmod-interfaces-cfg-14 Abstract This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. - The data model includes configuration data, state data and counters - for the collection of statistics. + The data model includes configuration data and state data (status + information and counters for the collection of statistics). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 11, 2014. + This Internet-Draft will expire on June 10, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -92,22 +92,22 @@ This document defines a YANG [RFC6020] data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. Network interfaces are central to the management of many Internet protocols. Thus, it is important to establish a common data model for how interfaces are identified, configured, and monitored. - The data model includes configuration data, state data and counters - for the collection of statistics. + The data model includes configuration data and state data (status + information and counters for the collection of statistics). 1.1. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. The following terms are used within this document: @@ -140,20 +140,22 @@ The following terms are defined in [RFC6020] and are not redefined here: o augment o data model o data node + o presence container + 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). @@ -287,25 +289,25 @@ For system-controlled interfaces, the "name" is the device-specific name of the interface. The 'config false' list "/interfaces-state/ interface" contains all existing interfaces on the device. If the device supports arbitrarily named user-controlled interfaces, the NETCONF server advertises the feature "arbitrary-names". If the device does not advertise this feature, the names of user-controlled interfaces MUST match the device's naming scheme. How a client can learn the naming scheme of such devices is outside the scope of this - document. + document. See Appendix E.1 and Appendix E.2 for examples. When a system-controlled interface is created by the system, the - system tries to apply the interface configuration in /interfaces/ - interface with the same name as the new interface. If no such + system tries to apply the interface configuration in "/interfaces/ + interface" with the same name as the new interface. If no such interface configuration is found, or if the configured type does not match the real interface type, the system creates the interface without applying explicit configuration. When a user-controlled interface is created, the configuration determines the name of the interface. 3.2. Interface References An interface is identified by its name, which is unique within the @@ -339,100 +341,113 @@ type if:interface-ref; must "/if:interfaces/if:interface[if:name = current()]" + "/if:type = 'ianaift:ethernetCsmacd'" { description "The type of a slave interface must be ethernet"; } } // other bonding config params, failover times etc. } - Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", - represent a read-only view of the interface layering hierarchy. + While the interface layering is configured in type specific models, + two generic state data leaf-lists, "higher-layer-if" and + "lower-layer-if", represent a read-only view of the interface + layering hierarchy. 4. Relationship to the IF-MIB If the device implements IF-MIB [RFC2863], each entry in the "/interfaces-state/interface" list is typically mapped to one ifEntry. The "if-index" leaf MUST contain the value of the corresponding ifEntry's ifIndex. In most cases, the "name" of an "interface" entry is mapped to - ifName. ifName is defined as an DisplayString [RFC2579] which uses a - 7-bit ASCII character set. An implementation MUST restrict the - allowed values for "name" to match the restrictions of ifName. + ifName. ifName is defined as a DisplayString [RFC2579] which uses a + 7-bit ASCII character set. An implementation that performs this + mapping MUST restrict the allowed values for "name" to match the + restrictions of ifName. The IF-MIB allows two different ifEntries to have the same ifName. Devices that support this feature, and also support the data model defined in this document, cannot have a 1-1 mapping between the "name" leaf and ifName. 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 this object typically is not a configuration object, it is not mapped 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. + versions; one with 32 bits and one with 64 bits. The 64-bit versions + were added to support high-speed interfaces with a data rate greater + than 20,000,000 bits/second. Today's implementations generally + support such high-speed interfaces and hence only 64-bit counters are + provided in this data model. Note that NETCONF and SNMP may differ + in the time granularity in which they provide access to the counters. + For example, it is common that SNMP implementations cache counter + values for some time. - The following table lists the YANG data nodes with corresponding + The following tables list the YANG data nodes with corresponding objects in the IF-MIB. - +----------------------------------+------------------------+ - | YANG data node | IF-MIB object | - +----------------------------------+------------------------+ - | /interfaces-state/interface | ifEntry | - | /interfaces-state/name | ifName | - | description | ifAlias | + +------------------------------------------+------------------------+ + | YANG data node in | IF-MIB object | + | /interfaces-state/interface | | + +------------------------------------------+------------------------+ + | name | ifName | | type | ifType | - | enabled / admin-status | ifAdminStatus | + | admin-status | ifAdminStatus | | oper-status | ifOperStatus | | last-change | ifLastChange | | if-index | ifIndex | | link-up-down-trap-enable | ifLinkUpDownTrapEnable | | phys-address | ifPhysAddress | | higher-layer-if / lower-layer-if | ifStackTable | | speed | ifSpeed | | in-octets | ifHCInOctets | | in-unicast-pkts | ifHCInUcastPkts | | in-broadcast-pkts | ifHCInBroadcastPkts | | in-multicast-pkts | ifHCInMulticastPkts | | in-discards | ifInDiscards | | in-errors | ifInErrors | | in-unknown-protos | ifInUnknownProtos | | out-octets | ifHCOutOctets | | out-unicast-pkts | ifHCOutUcastPkts | | out-broadcast-pkts | ifHCOutBroadcastPkts | | out-multicast-pkts | ifHCOutMulticastPkts | | out-discards | ifOutDiscards | | out-errors | ifOutErrors | - +----------------------------------+------------------------+ + +------------------------------------------+------------------------+ - YANG data nodes and related IF-MIB objects + YANG state data nodes and related IF-MIB objects + + +-----------------------------------------+---------------+ + | YANG data node in /interfaces/interface | IF-MIB object | + +-----------------------------------------+---------------+ + | description | ifAlias | + +-----------------------------------------+---------------+ + + YANG config data nodes and related IF-MIB objects 5. Interfaces YANG Module This YANG module imports typedefs from [RFC6991]. RFC Ed.: update the date below with the date of RFC publication and remove this note. - file "ietf-interfaces@2013-11-07.yang" + file "ietf-interfaces@2013-12-06.yang" module ietf-interfaces { namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; prefix if; import ietf-yang-types { prefix yang; } @@ -466,21 +481,21 @@ Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: update the date below with the date of RFC publication // and remove this note. - revision 2013-07-04 { + revision 2013-12-06 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Interface Management"; } /* * Typedefs */ @@ -550,21 +565,21 @@ description "The list of configured interfaces on the device. The operational state of an interface is available in the /interfaces-state/interface list. If the configuration of a system-controlled interface cannot be used by the system (e.g., the interface hardware present does not match the interface type), then the configuration is not applied to the system-controlled interface shown in the - /interfaces-state/interface list. If the the configuration + /interfaces-state/interface list. If the configuration of a user-controlled interface cannot be used by the system, the configured interface is not instantiated in the /interfaces-state/interface list."; leaf name { type string; description "The name of the interface. A device MAY restrict the allowed values for this leaf,