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/