draft-ietf-netmod-intf-ext-yang-07.txt		draft-ietf-netmod-intf-ext-yang-08.txt
	Internet Engineering Task Force R. Wilton, Ed.		Internet Engineering Task Force R. Wilton, Ed.
	Internet-Draft D. Ball		Internet-Draft D. Ball
	Intended status: Standards Track T. Singh		Intended status: Standards Track T. Singh
	Expires: September 6, 2019 Cisco Systems		Expires: May 7, 2020 Cisco Systems
	S. Sivaraj		S. Sivaraj
	Juniper Networks		Juniper Networks
	March 5, 2019		November 4, 2019
	Common Interface Extension YANG Data Models		Common Interface Extension YANG Data Models
	draft-ietf-netmod-intf-ext-yang-07		draft-ietf-netmod-intf-ext-yang-08
	Abstract		Abstract
	This document defines two YANG modules that augment the Interfaces		This document defines two YANG modules that augment the Interfaces
	data model defined in the "YANG Data Model for Interface Management"		data model defined in the "YANG Data Model for Interface Management"
	with additional configuration and operational data nodes to support		with additional configuration and operational data nodes to support
	common lower layer interface properties, such as interface MTU.		common lower layer interface properties, such as interface MTU.
	The YANG data model in this document conforms to the Network		The YANG modules in this document conform to the Network Management
	Management Datastore Architecture (NMDA) defined in RFC 8342.		Datastore Architecture (NMDA) defined in RFC 8342.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 September 6, 2019.		This Internet-Draft will expire on May 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
	2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Interface Extensions Module . . . . . . . . . . . . . . . . . 4
	3. Interfaces Common Module . . . . . . . . . . . . . . . . . . 4		2.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6		2.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7
	3.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7		2.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7
	3.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7		2.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7
	3.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7		2.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7
	3.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7		2.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8		2.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8		2.5. Maximum frame size . . . . . . . . . . . . . . . . . . . 8
	3.5. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 8		2.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 8
	3.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9		2.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9
	3.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9		3. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 9
	4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 10		4. Interface Extensions YANG Module . . . . . . . . . . . . . . 10
	5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 10		5. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 20
	6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 21		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24		6.1. Carrier delay configuration . . . . . . . . . . . . . . . 24
	7.1. Carrier delay configuration . . . . . . . . . . . . . . . 24		6.2. Dampening configuration . . . . . . . . . . . . . . . . . 25
	7.2. Dampening configuration . . . . . . . . . . . . . . . . . 25		6.3. MAC address configuration . . . . . . . . . . . . . . . . 26
	7.3. MAC address configuration . . . . . . . . . . . . . . . . 26		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 28		8.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 28
	9.1. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 28		8.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 28
	9.2. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 28		8.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 28
	9.3. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 28		8.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 28
	9.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 28		8.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 28
	9.5. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 28		8.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 28
	9.6. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 28		8.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 28
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 28		10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 29		10.1. ietf-if-extensions.yang . . . . . . . . . . . . . . . . 29
	11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 30		10.2. ietf-if-ethernet-like.yang . . . . . . . . . . . . . . . 30
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	12.1. Normative References . . . . . . . . . . . . . . . . . . 30		11.1. Normative References . . . . . . . . . . . . . . . . . . 30
	12.2. Informative References . . . . . . . . . . . . . . . . . 31		11.2. Informative References . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	This document defines two NMDA compatible [RFC8342] YANG 1.1		This document defines two NMDA compatible [RFC8342] YANG 1.1
	[RFC7950] modules for the management of network interfaces. It		[RFC7950] modules for the management of network interfaces. It
	defines various augmentations to the generic interfaces data model		defines various augmentations to the generic interfaces data model
	[RFC8343] to support configuration of lower layer interface		[RFC8343] to support configuration of lower layer interface
	properties that are common across many types of network interface.		properties that are common across many types of network interface.
	One of the aims of this draft is to provide a standard namespace and		One of the aims of this document is to provide a standard definition
	path for these configuration items regardless of the underlying		for these configuration items regardless of the underlying interface
	interface type. For example a standard namespace and path for		type. For example, a definition for configuring or reading the MAC
	configuring or reading the MAC address associated with an interface		address associated with an interface is provided that can be used for
	is provided that can be used for any interface type that uses		any interface type that uses Ethernet framing.
	Ethernet framing.
	Several of the augmentations defined here are not backed by any		Several of the augmentations defined here are not backed by any
	formal standard specification. Instead, they are for features that		formal standard specification. Instead, they are for features that
	are commonly implemented in equivalent ways by multiple independent		are commonly implemented in equivalent ways by multiple independent
	network equipment vendors. The aim of this draft is to define common		network equipment vendors. The aim of this document is to define
	paths and leaves for the configuration of these equivalent features		common paths and leaves for the configuration of these equivalent
	in a uniform way, making it easier for users of the YANG model to		features in a uniform way, making it easier for users of the YANG
	access these features in a vendor independent way. Where necessary,		model to access these features in a vendor independent way. Where
	a description of the expected behavior is also provided with the aim		necessary, a description of the expected behavior is also provided
	of ensuring vendors implementations are consistent with the specified		with the aim of ensuring vendors implementations are consistent with
	behaviour.		the specified behaviour.
	Given that the modules contain a collection of discrete features with		Given that the modules contain a collection of discrete features with
	the common theme that they generically apply to interfaces, it is		the common theme that they generically apply to interfaces, it is
	plausible that not all implementors of the YANG module will decide to		plausible that not all implementors of the YANG module will decide to
	support all features. Hence separate feature keywords are defined		support all features. Hence separate feature keywords are defined
	for each logically discrete feature to allow implementors the		for each logically discrete feature to allow implementors the
	flexibility to choose which specific parts of the model they support.		flexibility to choose which specific parts of the model they support.
	The augmentations are split into two separate YANG modules that each		The augmentations are split into two separate YANG modules that each
	focus on a particular area of functionality. The two YANG modules		focus on a particular area of functionality. The two YANG modules
	defined in this internet draft are:		defined in this document are:
	ietf-interfaces-common.yang - Defines extensions to the IETF		ietf-if-extensions.yang - Defines extensions to the IETF interface
	interface data model to support common configuration data nodes.		data model to support common configuration data nodes.
	ietf-interfaces-ethernet-like.yang - Defines a module for any		ietf-if-ethernet-like.yang - Defines a module for any
	configuration and operational data nodes that are common across		configuration and operational data nodes that are common across
	interfaces that use Ethernet framing.		interfaces that use Ethernet framing.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they		14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
	appear in all capitals, as shown here.		appear in all capitals, as shown here.
	1.2. Tree Diagrams		1.2. Tree Diagrams
	Tree diagrams used in this document follow the notation defined in		Tree diagrams used in this document follow the notation defined in
	[RFC8340].		[RFC8340].
	2. Objectives		2. Interface Extensions Module
	The aim of the YANG modules contained in this draft is to provide
	standard definitions for common interface based configuration on
	network devices.
	The expectation is that the YANG leaves that are being defined are
	fairly widely implemented by network vendors. However, the features
	described here are mostly not backed by formal standards because they
	are fairly basic in their behavior and do not need to interoperate
	with other devices. Where required a concise explanation of the
	expected behavior is also provided to ensure consistency between
	vendors.
	3. Interfaces Common Module
	The Interfaces Common module provides some basic extensions to the		The Interfaces Extensions YANG module provides some basic extensions
	IETF interfaces YANG module.		to the IETF interfaces YANG module.
	The module provides:		The module provides:
	o A carrier delay feature used to provide control over short lived		o A carrier delay feature used to provide control over short lived
	link state flaps.		link state flaps.
	o An interface link state dampening feature that is used to provide		o An interface link state dampening feature that is used to provide
	control over longer lived link state flaps.		control over longer lived link state flaps.
	o An encapsulation container and extensible choice statement for use		o An encapsulation container and extensible choice statement for use
	by any interface types that allow for configurable L2		by any interface types that allow for configurable L2
	encapsulations.		encapsulations.
	o A loopback configuration leaf that is primarily aimed at loopback		o A loopback configuration leaf that is primarily aimed at loopback
	at the physical layer.		at the physical layer.
	o MTU configuration leaves applicable to all packet/frame based		o MTU configuration leaves applicable to all packet/frame based
	interfaces.		interfaces.
	o A forwarding mode leaf to indicate the OSI layer at which the		o A forwarding mode leaf to indicate the OSI layer at which the
	interface handles traffic		interface handles traffic.
			o A generic "sub-interface" identity that an interface identity
			definition can derive from if it defines a sub-interface.
	o A parent interface leaf useable for all types of sub-interface		o A parent interface leaf useable for all types of sub-interface
	that are children of parent interfaces.		that are children of parent interfaces.
	The "ietf-interfaces-common" YANG module has the following structure:		The "ietf-if-extensions" YANG module has the following structure:
	module: ietf-interfaces-common		module: ietf-if-extensions
	augment /if:interfaces/if:interface:		augment /if:interfaces/if:interface:
	+--rw carrier-delay {carrier-delay}?		+--rw carrier-delay {carrier-delay}?
	| +--rw down? uint32		| +--rw down? uint32
	| +--rw up? uint32		| +--rw up? uint32
	| +--ro carrier-transitions? yang:counter64		| +--ro carrier-transitions? yang:counter64
	| +--ro timer-running? enumeration		| +--ro timer-running? enumeration
	+--rw dampening! {dampening}?		+--rw dampening! {dampening}?
	| +--rw half-life? uint32		| +--rw half-life? uint32
	| +--rw reuse? uint32		| +--rw reuse? uint32
	| +--rw suppress? uint32		| +--rw suppress? uint32
	| +--rw max-suppress-time? uint32		| +--rw max-suppress-time? uint32
	| +--ro penalty? uint32		| +--ro penalty? uint32
	| +--ro suppressed? boolean		| +--ro suppressed? boolean
	| +--ro time-remaining? uint32		| +--ro time-remaining? uint32
	+--rw encapsulation		+--rw encapsulation
	| +--rw (encaps-type)?		| +--rw (encaps-type)?
	+--rw loopback? identityref {loopback}?		+--rw loopback? identityref {loopback}?
	+--rw l2-mtu? uint16 {configurable-l2-mtu}?		+--rw max-frame-size? uint32 {max-frame-size}?
	+--rw forwarding-mode? identityref {forwarding-mode}?		+--ro forwarding-mode? identityref
	augment /if:interfaces/if:interface:		augment /if:interfaces/if:interface:
	+--rw parent-interface if:interface-ref {sub-interfaces}?		+--rw parent-interface if:interface-ref {sub-interfaces}?
	3.1. Carrier Delay		2.1. Carrier Delay
	The carrier delay feature augments the IETF interfaces data model		The carrier delay feature augments the IETF interfaces data model
	with configuration for a simple algorithm that is used, generally on		with configuration for a simple algorithm that is used, generally on
	physical interfaces, to suppress short transient changes in the		physical interfaces, to suppress short transient changes in the
	interface link state. It can be used in conjunction with the		interface link state. It can be used in conjunction with the
	dampening feature described in Section 3.2 to provide effective		dampening feature described in Section 2.2 to provide effective
	control of unstable links and unwanted state transitions.		control of unstable links and unwanted state transitions.
	The principle of the carrier delay feature is to use a short per		The principle of the carrier delay feature is to use a short per
	interface timer to ensure that any interface link state transition		interface timer to ensure that any interface link state transition
	that occurs and reverts back within the specified time interval is		that occurs and reverts back within the specified time interval is
	entirely suppressed without providing any signalling to any upper		entirely suppressed without providing any signalling to any upper
	layer protocols that the state transition has occurred. E.g. in the		layer protocols that the state transition has occurred. E.g. in the
	case that the link state transition is suppressed then there is no		case that the link state transition is suppressed then there is no
	change of the /if:interfaces-state/if:interface/oper-status or		change of the /if:interfaces/if:interface/oper-status or
	/if:interfaces-state/if:interfaces/last-change leaves for the		/if:interfaces/if:interfaces/last-change leaves for the interface
	interface that the feature is operating on. One obvious side effect		that the feature is operating on. One obvious side effect of using
	of using this feature that is that any state transition will always		this feature that is that any state transition will always be delayed
	be delayed by the specified time interval.		by the specified time interval.
	The configuration allows for separate timer values to be used in the		The configuration allows for separate timer values to be used in the
	suppression of down->up->down link transitions vs up->down->up link		suppression of down->up->down link transitions vs up->down->up link
	transitions.		transitions.
	The carrier delay down timer leaf specifies the amount of time that		The carrier delay down timer leaf specifies the amount of time that
	an interface that is currently in link up state must be continuously		an interface that is currently in link up state must be continuously
	down before the down state change is reported to higher level		down before the down state change is reported to higher level
	protocols. Use of this timer can cause traffic to be black holed for		protocols. Use of this timer can cause traffic to be black holed for
	the configured value and delay reconvergence after link failures,		the configured value and delay reconvergence after link failures,
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 28 ¶
	The carrier delay up timer leaf specifies the amount of time that an		The carrier delay up timer leaf specifies the amount of time that an
	interface that is currently in link down state must be continuously		interface that is currently in link down state must be continuously
	up before the down->up link state transition is reported to higher		up before the down->up link state transition is reported to higher
	level protocols. This timer is generally useful as a debounce		level protocols. This timer is generally useful as a debounce
	mechanism to ensure that a link is relatively stable before being		mechanism to ensure that a link is relatively stable before being
	brought into service. It can also be used effectively to limit the		brought into service. It can also be used effectively to limit the
	frequency at which link state transition events may occur. The		frequency at which link state transition events may occur. The
	default value for this leaf is determined by the underlying network		default value for this leaf is determined by the underlying network
	device.		device.
	3.2. Dampening		2.2. Dampening
	The dampening feature introduces a configurable exponential decay		The dampening feature introduces a configurable exponential decay
	mechanism to suppress the effects of excessive interface link state		mechanism to suppress the effects of excessive interface link state
	flapping. This feature allows the network operator to configure a		flapping. This feature allows the network operator to configure a
	device to automatically identify and selectively dampen a local		device to automatically identify and selectively dampen a local
	interface which is flapping. Dampening an interface keeps the		interface which is flapping. Dampening an interface keeps the
	interface operationally down until the interface stops flapping and		interface operationally down until the interface stops flapping and
	becomes stable. Configuring the dampening feature can improve		becomes stable. Configuring the dampening feature can improve
	convergence times and stability throughout the network by isolating		convergence times and stability throughout the network by isolating
	failures so that disturbances are not propagated, which reduces the		failures so that disturbances are not propagated, which reduces the
	utilization of system processing resources by other devices in the		utilization of system processing resources by other devices in the
	network and improves overall network stability.		network and improves overall network stability.
	The basic algorithm uses a counter that is nominally increased by		The basic algorithm uses a counter that is increased by 1000 units
	1000 units every time the underlying interface link state changes		every time the underlying interface link state changes from up to
	from up to down. If the counter increases above the suppress		down. If the counter increases above the suppress threshold then the
	threshold then the interface is kept down (and out of service) until		interface is kept down (and out of service) until either the maximum
	either the maximum suppression time is reached, or the counter has		suppression time is reached, or the counter has reduced below the
	reduced below the reuse threshold. The half-life period determines		reuse threshold. The half-life period determines that rate at which
	that rate at which the counter is periodically reduced.		the counter is periodically reduced by half.
	Implementations are not required to use a penalty of 1000 units in
	their dampening algorithm, but should ensure that the Suppress
	Threshold and Reuse Threshold values are scaled relative to the
	nominal 1000 unit penalty to ensure that the same configuration
	values provide consistent behaviour. The configurable values are
	described in more detail below.
	3.2.1. Suppress Threshold		2.2.1. Suppress Threshold
	The suppress threshold is the value of the accumulated penalty that		The suppress threshold is the value of the accumulated penalty that
	triggers the device to dampen a flapping interface. The flapping		triggers the device to dampen a flapping interface. The flapping
	interface is identified by the device and assigned a penalty for each		interface is identified by the device and assigned a penalty for each
	up to down link state change, but the interface is not automatically		up to down link state change, but the interface is not automatically
	dampened. The device tracks the penalties that a flapping interface		dampened. The device tracks the penalties that a flapping interface
	accumulates. When the accumulated penalty reaches the default or		accumulates. When the accumulated penalty reaches or exceeds the
	configured suppress threshold, the interface is placed in a dampened		suppress threshold, the interface is placed in a suppressed state.
	state.
	3.2.2. Half-Life Period		2.2.2. Half-Life Period
	The half-life period determines how fast the accumulated penalties		The half-life period determines how fast the accumulated penalties
	can decay exponentially. Any penalties that have been accumulated on		can decay exponentially. The accumulated penalty decays at a rate
	a flapping interface are reduced by half after each half-life period.		that causes its value to be reduced by half after each half-life
			period.
	3.2.3. Reuse Threshold		2.2.3. Reuse Threshold
	If, after one or more half-life periods, the accumulated penalty		If, after one or more half-life periods, the accumulated penalty
	decreases below the reuse threshold and the underlying interface link		decreases below the reuse threshold and the underlying interface link
	state is up then the interface is taken out of dampened state and		state is up then the interface is taken out of suppressed state and
	allowed to go up.		is allowed to go up.
	3.2.4. Maximum Suppress Time		2.2.4. Maximum Suppress Time
	The maximum suppress time represents the maximum amount of time an		The maximum suppress time represents the maximum amount of time an
	interface can remain dampened when a penalty is assigned to an		interface can remain dampened when a new penalty is assigned to an
	interface. The default of the maximum suppress timer is four times		interface. The default of the maximum suppress timer is four times
	the half-life period. The maximum value of the accumulated penalty		the half-life period. The maximum value of the accumulated penalty
	is calculated using the maximum suppress time, reuse threshold and		is calculated using the maximum suppress time, reuse threshold and
	half-life period.		half-life period.
	3.3. Encapsulation		2.3. Encapsulation
	The encapsulation container holds a choice node that is to be		The encapsulation container holds a choice node that is to be
	augmented with datalink layer specific encapsulations, such as HDLC,		augmented with datalink layer specific encapsulations, such as HDLC,
	PPP, or sub-interface 802.1Q tag match encapsulations. The use of a		PPP, or sub-interface 802.1Q tag match encapsulations. The use of a
	choice statement ensures that an interface can only have a single		choice statement ensures that an interface can only have a single
	datalink layer protocol configured.		datalink layer protocol configured.
	The different encapsulations themselves are defined in separate YANG		The different encapsulations themselves are defined in separate YANG
	modules defined in other documents that augument the encapsulation		modules defined in other documents that augument the encapsulation
	choice statement. For example the Ethernet specific basic 'dot1q-		choice statement. For example the Ethernet specific basic 'dot1q-
	vlan' encapsulation is defined in ietf-if-l3-vlan.yang and the		vlan' encapsulation is defined in ietf-if-l3-vlan.yang and the
	'flexible' encapsulation is defined in ietf-flexible-		'flexible' encapsulation is defined in ietf-flexible-
	encapsulation.yang, both modules from		encapsulation.yang, both modules from
	[I-D.ietf-netmod-sub-intf-vlan-model].		[I-D.ietf-netmod-sub-intf-vlan-model].
	3.4. Loopback		2.4. Loopback
	The loopback configuration leaf allows any physical interface to be		The loopback configuration leaf allows any physical interface to be
	configured to be in one of the possible following physical loopback		configured to be in one of the possible following physical loopback
	modes, i.e. internal loopback, line loopback, or use of an external		modes, i.e. internal loopback, line loopback, or use of an external
	loopback connector. The use of YANG identities allows for the model		loopback connector. The use of YANG identities allows for the model
	to be extended with other modes of loopback if required.		to be extended with other modes of loopback if required.
	The following loopback modes are defined:		The following loopback modes are defined:
	o Internal loopback - All egress traffic on the interface is		o Internal loopback - All egress traffic on the interface is
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 27 ¶
	ingress path.		ingress path.
	o Line loopback - All ingress traffic received on the interface is		o Line loopback - All ingress traffic received on the interface is
	internally looped back within the interface to the egress path.		internally looped back within the interface to the egress path.
	o Loopback Connector - The interface has a physical loopback		o Loopback Connector - The interface has a physical loopback
	connector attached that loops all egress traffic back into the		connector attached that loops all egress traffic back into the
	interface's ingress path, with equivalent semantics to internal		interface's ingress path, with equivalent semantics to internal
	loopback.		loopback.
	3.5. Layer 2 MTU		2.5. Maximum frame size
	A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the
	maximum size of a layer 2 frame that may be transmitted or received
	on an interface. The layer 2 MTU includes the overhead of the layer
	2 header and the maximum length of the payload, but excludes any
	frame check sequence (FCS) bytes. The payload MTU available to
	higher layer protocols is calculated from the l2-mtu leaf after
	taking the layer 2 header size into account.
	For Ethernet interfaces carrying 802.1Q VLAN tagged frames, the		A maximum frame size configuration leaf (max-frame-size) is provided
	l2-mtu excludes the 4-8 byte overhead of any known (e.g. explicitly		to specify the maximum size of a layer 2 frame that may be
	matched by a child sub-interface) 802.1Q VLAN tags.		transmitted or received on an interface. The value includes the
			overhead of any layer 2 header, the maximum length of the payload,
			and any frame check sequence (FCS) bytes. If configured, the max-
			frame-size leaf on an interface also restricts the max-frame-size of
			any child sub-interfaces, and the available MTU for protocols.
	3.6. Sub-interface		2.6. Sub-interface
	The sub-interface feature specifies the minimal leaves required to		The sub-interface feature specifies the minimal leaves required to
	define a child interface that is parented to another interface.		define a child interface that is parented to another interface.
	A sub-interface is a logical interface that handles a subset of the		A sub-interface is a logical interface that handles a subset of the
	traffic on the parent interface. Separate configuration leaves are		traffic on the parent interface. Separate configuration leaves are
	used to classify the subset of ingress traffic received on the parent		used to classify the subset of ingress traffic received on the parent
	interface to be processed in the context of a given sub-interface.		interface to be processed in the context of a given sub-interface.
	All egress traffic processed on a sub-interface is given to the		All egress traffic processed on a sub-interface is given to the
	parent interface for transmission. Otherwise, a sub-interface is		parent interface for transmission. Otherwise, a sub-interface is
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 17 ¶
	in this case it is useful to have a well defined leaf to cleanly		in this case it is useful to have a well defined leaf to cleanly
	identify the parent interface.		identify the parent interface.
	The model also allows for arbitrarily named sub-interfaces by having		The model also allows for arbitrarily named sub-interfaces by having
	an explicit parent-interface leaf define the child -> parent		an explicit parent-interface leaf define the child -> parent
	relationship. In this naming scenario it is also possible for		relationship. In this naming scenario it is also possible for
	implementations to allow for logical interfaces to be reparented to		implementations to allow for logical interfaces to be reparented to
	new parent interfaces without needing the sub-interface to be		new parent interfaces without needing the sub-interface to be
	destroyed and recreated.		destroyed and recreated.
	3.7. Forwarding Mode		2.7. Forwarding Mode
	The forwarding mode leaf provides additional information as to what		The forwarding mode leaf provides additional information as to what
	mode or layer an interface is logically operating and forwarding		mode or layer an interface is logically operating and forwarding
	traffic at. The implication of this leaf is that for traffic		traffic at. The implication of this leaf is that for traffic
	forwarded at a given layer that any headers for lower layers are		forwarded at a given layer that any headers for lower layers are
	stripped off before the packet is forwarded at the given layer.		stripped off before the packet is forwarded at the given layer.
	Conversely, on egress any lower layer headers must be added to the		Conversely, on egress any lower layer headers must be added to the
	packet before it is transmitted out of the interface.		packet before it is transmitted out of the interface.
	YANG Modules can conditionally use this leaf as a simple mechanism to
	determine whether particular types of configuration are valid. YANG
	modules can write 'must' statements to check whether the forwarding
	mode leaf has been configured, and if it is, then validate that the
	specified configuration is consistent with any forwarding mode that
	has also been configured. E.g., a layer 2 QoS policy YANG module
	could ensure that it is only applied to a interface forwarding
	traffic at layer 2 by checking whether the forwarding-mode leaf
	exists, and if it does then also ensure that it has been set to
	'layer-2-forwarding'.
	The following forwarding modes are defined:		The following forwarding modes are defined:
	o Optical Layer - Traffic is being forwarded at the optical layer.		o Physical - Traffic is being forwarded at the physical layer. This
	This includes DWDM or OTN based switching.		includes DWDM or OTN based switching.
	o Layer 2 - Layer 2 based forwarding, such as Ethernet/VLAN based		o Data-link - Layer 2 based forwarding, such as Ethernet/VLAN based
	switching, or L2VPN services.		switching, or L2VPN services.
	o Network Layer - Network layer based forwarding, such as IP, MPLS,		o Network - Network layer based forwarding, such as IP, MPLS, or
	or L3VPNs.		L3VPNs.
	4. Interfaces Ethernet-Like Module		3. Interfaces Ethernet-Like Module
	The Interfaces Ethernet-Like Module is a small module that contains		The Interfaces Ethernet-Like Module is a small module that contains
	all configuration and operational data that is common across		all configuration and operational data that is common across
	interface types that use Ethernet framing as their datalink layer		interface types that use Ethernet framing as their datalink layer
	encapsulation.		encapsulation.
	This module currently contains leaves for the configuration and		This module currently contains leaves for the configuration and
	reporting of the operational MAC address and the burnt-in MAC address		reporting of the operational MAC address and the burnt-in MAC address
	(BIA) associated with any interface using Ethernet framing.		(BIA) associated with any interface using Ethernet framing.
	The "ietf-interfaces-ethernet-like" YANG module has the following		The "ietf-if-ethernet-like" YANG module has the following structure:
	structure:
	module: ietf-interfaces-ethernet-like		module: ietf-if-ethernet-like
	augment /if:interfaces/if:interface:		augment /if:interfaces/if:interface:
	+--rw ethernet-like		+--rw ethernet-like
	+--rw mac-address? yang:mac-address		+--rw mac-address? yang:mac-address
			| {configurable-mac-address}?
	+--ro bia-mac-address? yang:mac-address		+--ro bia-mac-address? yang:mac-address
	+--ro statistics		augment /if:interfaces/if:interface/if:statistics:
	+--ro in-drop-unknown-dest-mac-pkts? yang:counter64		+--ro in-drop-unknown-dest-mac-pkts? yang:counter64
	5. Interfaces Common YANG Module		4. Interface Extensions YANG Module
	This YANG module augments the interface container defined in RFC 8343		This YANG module augments the interface container defined in RFC 8343
	[RFC8343].		[RFC8343].
	<CODE BEGINS> file "ietf-interfaces-common@2019-03-05.yang"		<CODE BEGINS> file "ietf-if-extensions@2019-11-04.yang"
	module ietf-interfaces-common {		module ietf-if-extensions {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-common";
	prefix if-cmn;
	import ietf-yang-types {
	prefix yang;
	}
	import ietf-interfaces {
	prefix if;
	}
	import iana-if-type {		namespace "urn:ietf:params:xml:ns:yang:ietf-if-extensions";
	prefix ianaift;
	}
	organization		prefix if-ext;
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		import ietf-yang-types {
	"WG Web: <http://tools.ietf.org/wg/netmod/>		prefix yang;
	WG List: <mailto:netmod@ietf.org>		reference "RFC 6991: Common YANG Data Types";
			}
	WG Chair: Lou Berger		import ietf-interfaces {
	<mailto:lberger@labn.net>		prefix if;
			reference
			"RFC 8343: A YANG Data Model For Interface Management";
			}
	WG Chair: Joel Jaeggli		import iana-if-type {
	<mailto:joelja@gmail.com>		prefix ianaift;
			reference "RFC 7224: IANA Interface Type YANG Module";
			}
	WG Chair: Kent Watsen		organization
	<mailto:kwatsen@juniper.net>		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	Editor: Robert Wilton		contact
	<mailto:rwilton@cisco.com>";		"WG Web: <http://tools.ietf.org/wg/netmod/>
			WG List: <mailto:netmod@ietf.org>
	description		Editor: Robert Wilton
	"This module contains common definitions for extending the IETF		<mailto:rwilton@cisco.com>";
	interface YANG model (RFC 8343) with common configurable layer 2
	properties.
	Copyright (c) 2016-2019 IETF Trust and the persons identified		description
	as authors of the code. All rights reserved.		"This module contains common definitions for extending the IETF
			interface YANG model (RFC 8343) with common configurable layer 2
			properties.
	Redistribution and use in source and binary forms, with or		Copyright (c) 2019 IETF Trust and the persons identified as
	without modification, is permitted pursuant to, and subject		authors of the code. All rights reserved.
	to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents
	(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of XXX; see the RFC		Redistribution and use in source and binary forms, with or
	itself for full legal notices.";		without modification, is permitted pursuant to, and subject to
			the license terms contained in, the Simplified BSD License set
			forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(https://trustee.ietf.org/license-info).
	revision 2019-03-05 {		This version of this YANG module is part of RFC XXXX
	description		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	"Initial version";		for full legal notices.
	reference "Internet draft: draft-ietf-netmod-intf-ext-yang-07";		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	}		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
			'MAY', and 'OPTIONAL' in this document are to be interpreted as
			described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
			they appear in all capitals, as shown here.";
	feature carrier-delay {		revision 2019-11-04 {
	description		description
	"This feature indicates that configurable interface		"Initial revision.";
	carrier delay is supported, which is a feature is used to
	limit the propagation of very short interface link state
	flaps.";
	reference "RFC XXX, Section 3.1 Carrier Delay";
	}
	feature dampening {		reference
	description		"RFC XXX, Common Interface Extension YANG Data Models";
	"This feature indicates that the device supports interface		}
	dampening, which is a feature that is used to limit the
	propagation of interface link state flaps over longer
	periods";
	reference "RFC XXX, Section 3.2 Dampening";
	}
	feature loopback {		feature carrier-delay {
	description		description
	"This feature indicates that configurable interface loopback		"This feature indicates that configurable interface
	is supported.";		carrier delay is supported, which is a feature is used to
	reference "RFC XXX, Section 3.4 Loopback";		limit the propagation of very short interface link state
	}		flaps.";
			reference "RFC XXX, Section 2.1 Carrier Delay";
			}
	feature configurable-l2-mtu {		feature dampening {
	description		description
	"This feature indicates that the device supports configuring		"This feature indicates that the device supports interface
	layer 2 MTUs on interfaces. Such MTU configurations include		dampening, which is a feature that is used to limit the
	the layer 2 header overheads (but exclude any FCS overhead).		propagation of interface link state flaps over longer
	The payload MTU available to higher layer protocols is either		periods.";
	derived from the layer 2 MTU, taking into account the size of		reference "RFC XXX, Section 2.2 Dampening";
	the layer 2 header, or is further restricted by explicit layer		}
	3 or protocol specific MTU configuration.";
	reference "RFC XXX, Section 3.5 Layer 2 MTU";
	}
	feature sub-interfaces {		feature loopback {
	description		description
	"This feature indicates that the device supports the		"This feature indicates that configurable interface loopback
	instantiation of sub-interfaces. Sub-interfaces are defined		is supported.";
	as logical child interfaces that allow features and forwarding		reference "RFC XXX, Section 2.4 Loopback";
	decisions to be applied to a subset of the traffic processed		}
	on the specified parent interface.";
	reference "RFC XXX, Section 3.6 Sub-interface";
	}
	feature forwarding-mode {		feature max-frame-size {
	description		description
	"This feature indicates that the device supports the		"This feature indicates that the device supports configuring
	configurable forwarding mode leaf";		or reporting the maximum frame size on interfaces.";
	reference "RFC XXX, Section 3.7 Forwarding Mode";		reference "RFC XXX, Section 2.5 Maximum Frame Size";
	}		}
	/*		feature sub-interfaces {
	* Define common identities to help allow interface types to be		description
	* assigned properties.		"This feature indicates that the device supports the
	*/		instantiation of sub-interfaces. Sub-interfaces are defined
	identity sub-interface {		as logical child interfaces that allow features and forwarding
	description		decisions to be applied to a subset of the traffic processed
	"Base type for generic sub-interfaces.		on the specified parent interface.";
			reference "RFC XXX, Section 2.6 Sub-interface";
			}
	New or custom interface types can derive from this type to		/*
	inherit generic sub-interface configuration";		* Define common identities to help allow interface types to be
	reference "RFC XXX, Section 3.6 Sub-interface";		* assigned properties.
	}		*/
			identity sub-interface {
			description
			"Base type for generic sub-interfaces.
	identity ethSubInterface{		New or custom interface types can derive from this type to
	base ianaift:l2vlan;		inherit generic sub-interface configuration.";
	base sub-interface;		reference "RFC XXX, Section 2.6 Sub-interface";
			}
	description		identity ethSubInterface{
	"This identity represents the child sub-interface of any		base ianaift:l2vlan;
	interface types that uses Ethernet framing (with or without		base sub-interface;
	802.1Q tagging)";		description
	}		"This identity represents the child sub-interface of any
			interface types that uses Ethernet framing (with or without
			802.1Q tagging).";
			}
	identity loopback {		identity loopback {
	description "Base identity for interface loopback options";		description "Base identity for interface loopback options";
	reference "RFC XXX, section 3.4";		reference "RFC XXX, Section 2.4";
	}		}
	identity loopback-internal {		identity internal {
	base loopback;		base loopback;
	description		description
	"All egress traffic on the interface is internally looped back		"All egress traffic on the interface is internally looped back
	within the interface to be received on the ingress path.";		within the interface to be received on the ingress path.";
	reference "RFC XXX, section 3.4";		reference "RFC XXX, Section 2.4";
	}		}
	identity loopback-line {		identity line {
	base loopback;		base loopback;
	description		description
	"All ingress traffic received on the interface is internally		"All ingress traffic received on the interface is internally
	looped back within the interface to the egress path.";		looped back within the interface to the egress path.";
	reference "RFC XXX, section 3.4";		reference "RFC XXX, Section 2.4";
	}		}
	identity loopback-connector {		identity connector {
	base loopback;		base loopback;
	description		description
	"The interface has a physical loopback connector attached		"The interface has a physical loopback connector attached that
	that loops all egress traffic back into the interface's		loops all egress traffic back into the interface's ingress
	ingress path, with equivalent semantics to loopback-internal";		path, with equivalent semantics to loopback internal.";
	reference "RFC XXX, section 3.4";		reference "RFC XXX, Section 2.4";
	}		}
	identity forwarding-mode {		identity forwarding-mode {
	description "Base identity for forwarding-mode options.";		description "Base identity for forwarding-mode options.";
	reference "RFC XXX, section 3.7";		reference "RFC XXX, Section 2.7";
	}		}
	identity optical-layer {		identity physical {
	base forwarding-mode;		base forwarding-mode;
	description		description
	"Traffic is being forwarded at the optical layer. This		"Physical layer forwarding. This includes DWDM or OTN based
	includes DWDM or OTN based switching.";		optical switching.";
	reference "RFC XXX, section 3.7";		reference "RFC XXX, Section 2.7";
	}		}
	identity layer-2-forwarding {		identity data-link {
	base forwarding-mode;		base forwarding-mode;
	description		description
	"Layer 2 based forwarding, such as Ethernet/VLAN based		"Layer 2 based forwarding, such as Ethernet/VLAN based
	switching, or L2VPN services.";		switching, or L2VPN services.";
	reference "RFC XXX, section 3.7";		reference "RFC XXX, Section 2.7";
	}		}
	identity network-layer {		identity network {
	base forwarding-mode;		base forwarding-mode;
	description		description
	"Network layer based forwarding, such as IP, MPLS, or L3VPNs.";		"Network layer based forwarding, such as IP, MPLS, or L3VPNs.";
	reference "RFC XXX, section 3.7";		reference "RFC XXX, Section 2.7";
	}		}
	/*
	* Augments the IETF interfaces model with leaves to configure
	* and monitor carrier-delay on an interface.
	*/
	augment "/if:interfaces/if:interface" {
	description
	"Augments the IETF interface model with optional common
	interface level commands that are not formally covered by any
	specific standard.";
	/*		/*
	* Defines standard YANG for the Carrier Delay feature.		* Augments the IETF interfaces model with leaves to configure
			* and monitor carrier-delay on an interface.
	*/		*/
	container carrier-delay {		augment "/if:interfaces/if:interface" {
	if-feature "carrier-delay";
	description		description
	"Holds carrier delay related feature configuration";		"Augments the IETF interface model with optional common
	leaf down {		interface level commands that are not formally covered by any
	type uint32;		specific standard.";
	units milliseconds;
	description		/*
	"Delays the propagation of a 'loss of carrier signal' event		* Defines standard YANG for the Carrier Delay feature.
	that would cause the interface state to go down, i.e. the		*/
	command allows short link flaps to be suppressed. The		container carrier-delay {
	configured value indicates the minimum time interval (in		if-feature "carrier-delay";
	milliseconds) that the carrier signal must be continuously
	down before the interface state is brought down. If not
	configured, the behaviour on loss of carrier signal is
	vendor/interface specific, but with the general
	expectation that there should be little or no delay.";
	}
	leaf up {
	type uint32;
	units milliseconds;
	description		description
	"Defines the minimum time interval (in milliseconds) that		"Holds carrier delay related feature configuration.";
	the carrier signal must be continuously present and error		leaf down {
	free before the interface state is allowed to transition		type uint32;
	from down to up. If not configured, the behaviour is		units milliseconds;
	vendor/interface specific, but with the general		description
	expectation that sufficient default delay should be used		"Delays the propagation of a 'loss of carrier signal' event
	to ensure that the interface is stable when enabled before		that would cause the interface state to go down, i.e. the
	being reported as being up. Configured values that are		command allows short link flaps to be suppressed. The
	too low for the hardware capabilties may be rejected.";		configured value indicates the minimum time interval (in
			milliseconds) that the carrier signal must be continuously
			down before the interface state is brought down. If not
			configured, the behaviour on loss of carrier signal is
			vendor/interface specific, but with the general
			expectation that there should be little or no delay.";
			}
			leaf up {
			type uint32;
			units milliseconds;
			description
			"Defines the minimum time interval (in milliseconds) that
			the carrier signal must be continuously present and error
			free before the interface state is allowed to transition
			from down to up. If not configured, the behaviour is
			vendor/interface specific, but with the general
			expectation that sufficient default delay should be used
			to ensure that the interface is stable when enabled before
			being reported as being up. Configured values that are
			too low for the hardware capabilties may be rejected.";
			}
			leaf carrier-transitions {
			type yang:counter64;
			units transitions;
			config false;
			description
			"Defines the number of times the underlying carrier state
			has changed to, or from, state up. This counter should be
			incremented even if the high layer interface state changes
			are being suppressed by a running carrier-delay timer.";
			}
			leaf timer-running {
			type enumeration {
			enum none {
			description
			"No carrier delay timer is running.";
			}
			enum up {
			description
			"Carrier-delay up timer is running. The underlying
			carrier state is up, but interface state is not
			reported as up.";
			}
			enum down {
			description
			"Carrier-delay down timer is running. Interface state
			is reported as up, but the underlying carrier state is
			actually down.";
			}
			}
			config false;
			description
			"Reports whether a carrier delay timer is actively running,
			in which case the interface state does not match the
			underlying carrier state.";
			}
			reference "RFC XXX, Section 2.1 Carrier Delay";
	}		}
	leaf carrier-transitions {		/*
	type yang:counter64;		* Augments the IETF interfaces model with a container to hold
	units transitions;		* generic interface dampening
	config false;		*/
			container dampening {
			if-feature "dampening";
			presence
			"Enable interface link flap dampening with default settings
			(that are vendor/device specific).";
	description		description
	"Defines the number of times the underlying carrier state		"Interface dampening limits the propagation of interface link
	has changed to, or from, state up. This counter should be		state flaps over longer periods.";
	incremented even if the high layer interface state changes		reference "RFC XXX, Section 2.2 Dampening";
	are being suppressed by a running carrier-delay timer.";
	}		leaf half-life {
	leaf timer-running {		type uint32;
	type enumeration {		units seconds;
	enum none {		description
	description		"The time (in seconds) after which a penalty would be half
	"No carrier delay timer is running.";		its original value. Once the interface has been assigned
	}		a penalty, the penalty is decreased at a decay rate
	enum up {		equivalent to the half-life. For some devices, the
	description		allowed values may be restricted to particular multiples
	"Carrier-delay up timer is running. The underlying		of seconds. The default value is vendor/device
	carrier state is up, but interface state is not		specific.";
	reported as up.";		reference "RFC XXX, Section 2.3.2 Half-Life Period";
	}		}
	enum down {
			leaf reuse {
			type uint32;
			description
			"Penalty value below which a stable interface is
			unsuppressed (i.e. brought up) (no units). The default
			value is vendor/device specific. The penalty value for a
			link up->down state change is 1000 units.";
			reference "RFC XXX, Section 2.2.3 Reuse Threshold";
			}
			leaf suppress {
			type uint32;
			description
			"Limit at which an interface is suppressed (i.e. held down)
			when its penalty exceeds that limit (no units). The value
			must be greater than the reuse threshold. The default
			value is vendor/device specific. The penalty value for a
			link up->down state change is 1000 units.";
			reference "RFC XXX, Section 2.2.1 Suppress Threshold";
			}
			leaf max-suppress-time {
			type uint32;
			units seconds;
			description
			"Maximum time (in seconds) that an interface can be
			suppressed before being unsuppressed if no further link
			up->down state change penalties have been applied. This
			value effectively acts as a ceiling that the penalty value
			cannot exceed. The default value is vendor/device
			specific.";
			reference "RFC XXX, Section 2.2.4 Maximum Suppress Time";
			}
			leaf penalty {
			type uint32;
			config false;
			description
			"The current penalty value for this interface. When the
			penalty value exceeds the 'suppress' leaf then the
			interface is suppressed (i.e. held down).";
			reference "RFC XXX, Section 2.2 Dampening";
			}
			leaf suppressed {
			type boolean;
			config false;
			description
			"Represents whether the interface is suppressed (i.e. held
			down) because the 'penalty' leaf value exceeds the
			'suppress' leaf.";
			reference "RFC XXX, Section 2.2 Dampening";
			}
			leaf time-remaining {
			when '../suppressed = "true"' {
	description		description
	"Carrier-delay down timer is running. Interface state		"Only suppressed interfaces have a time remaining.";
	is reported as up, but the underlying carrier state is
	actually down.";
	}		}
			type uint32;
			units seconds;
			config false;
			description
			"For a suppressed interface, this leaf represents how long
			(in seconds) that the interface will remain suppressed
			before it is allowed to go back up again.";
			reference "RFC XXX, Section 2.2 Dampening";
	}		}
	default "none";
	config false;
	description
	"Reports whether a carrier delay timer is actively running,
	in which case the interface state does not match the
	underlying carrier state.";
	}		}
			/*
			* Various types of interfaces support a configurable layer 2
			* encapsulation, any that are supported by YANG should be
			* listed here.
			*
			* Different encapsulations can hook into the common encaps-type
			* choice statement.
			*/
			container encapsulation {
			when
			"derived-from-or-self(../if:type,
			'ianaift:ethernetCsmacd') or
			derived-from-or-self(../if:type,
			'ianaift:ieee8023adLag') or
			derived-from-or-self(../if:type, 'ianaift:pos') or
			derived-from-or-self(../if:type,
			'ianaift:atmSubInterface') or
			derived-from-or-self(../if:type, 'ethSubInterface')" {
	reference "RFC XXX, Section 3.1 Carrier Delay";		description
	}		"All interface types that can have a configurable L2
			encapsulation.";
			}
	/*
	* Augments the IETF interfaces model with a container to hold
	* generic interface dampening
	*/
	container dampening {
	if-feature "dampening";
	presence
	"Enable interface link flap dampening with default settings
	(that are vendor/device specific)";
	description
	"Interface dampening limits the propagation of interface link
	state flaps over longer periods";
	reference "RFC XXX, Section 3.2 Dampening";
	leaf half-life {
	type uint32;
	units seconds;
	description		description
	"The Time (in seconds) after which a penalty reaches half		"Holds the OSI layer 2 encapsulation associated with an
	its original value. Once the interface has been assigned		interface.";
	a penalty, the penalty is decreased by half after the		choice encaps-type {
	half-life period. For some devices, the allowed values may		description
	be restricted to particular multiples of seconds. The		"Extensible choice of layer 2 encapsulations";
	default value is vendor/device specific.";		reference "RFC XXX, Section 2.3 Encapsulation";
	reference "RFC XXX, Section 3.3.2 Half-Life Period";		}
	}
	leaf reuse {
	type uint32;
	description
	"Penalty value below which a stable interface is
	unsuppressed (i.e. brought up) (no units). The default
	value is vendor/device specific. The penalty value for a
	link up->down state change is nominally 1000 units.";
	reference "RFC XXX, Section 3.2.3 Reuse Threshold";
	}		}
	leaf suppress {		/*
	type uint32;		* Various types of interfaces support loopback configuration,
	description		* any that are supported by YANG should be listed here.
	"Limit at which an interface is suppressed (i.e. held down)		*/
	when its penalty exceeds that limit (no units). The value		leaf loopback {
	must be greater than the reuse threshold. The default		when "derived-from-or-self(../if:type,
	value is vendor/device specific. The penalty value for a		'ianaift:ethernetCsmacd') or
	link up->down state change is nominally 1000 units.";		derived-from-or-self(../if:type, 'ianaift:sonet') or
	reference "RFC XXX, Section 3.2.1 Suppress Threshold";		derived-from-or-self(../if:type, 'ianaift:atm') or
			derived-from-or-self(../if:type, 'ianaift:otnOtu')" {
			description
			"All interface types that support loopback configuration.";
			}
			if-feature "loopback";
			type identityref {
			base loopback;
			}
			description "Enables traffic loopback.";
			reference "RFC XXX, Section 2.4 Loopback";
	}		}
	leaf max-suppress-time {		/*
	type uint32;		* Allows the maximum frame size to be configured or reported.
	units seconds;		*/
			leaf max-frame-size {
			if-feature "max-frame-size";
			type uint32 {
			range "64 .. max";
			}
	description		description
	"Maximum time (in seconds) that an interface can be		"The maximum size of layer 2 frames that may be transmitted
	suppressed. This value effectively acts as a ceiling that		or received on the interface (including any frame header,
	the penalty value cannot exceed. The default value is		maximum frame payload size, and frame checksum sequence).
	vendor/device specific.";
	reference "RFC XXX, Section 3.2.4 Maximum Suppress Time";
	}
	leaf penalty {		If configured, the max-frame-size also limits the maximum
	type uint32;		frame size of any child sub-interfaces. The MTU available
	config false;		to higher layer protocols is restricted to the maximum frame
	description		payload size, and MAY be further restricted by explicit
	"The current penalty value for this interface. When the		layer 3 or protocol specific MTU configuration.";
	penalty value exceeds the 'suppress' leaf then the
	interface is suppressed (i.e. held down).";
	reference "RFC XXX, Section 3.2 Dampening";
	}
	leaf suppressed {		reference "RFC XXX, Section 2.5 Maximum Frame Size";
	type boolean;
	default "false";
	config false;
	description
	"Represents whether the interface is suppressed (i.e. held
	down) because the 'penalty' leaf value exceeds the
	'suppress' leaf.";
	reference "RFC XXX, Section 3.2 Dampening";
	}		}
	leaf time-remaining {		/*
	when '../suppressed = "true"' {		* Augments the IETF interfaces model with a leaf that indicates
	description		* which mode, or layer, is being used to forward the traffic.
	"Only suppressed interfaces should have a time remaining.";		*/
			leaf forwarding-mode {
			type identityref {
			base forwarding-mode;
	}		}
	type uint32;
	units seconds;
	config false;		config false;
	description		description
	"For a suppressed interface, this leaf represents how long		"The forwarding mode that the interface is operating in.";
	(in seconds) that the interface will remain suppressed		reference "RFC XXX, Section 2.7 Forwarding Mode";
	before it is allowed to go back up again.";
	reference "RFC XXX, Section 3.2 Dampening";
	}		}
	}		}
	/*		/*
	* Various types of interfaces support a configurable layer 2		* Add generic support for sub-interfaces.
	* encapsulation, any that are supported by YANG should be
	* listed here.
	*		*
	* Different encapsulations can hook into the common encaps-type		* This should be extended to cover all interface types that are
	* choice statement.		* child interfaces of other interfaces.
	*/		*/
	container encapsulation {		augment "/if:interfaces/if:interface" {
	when		when "derived-from(if:type, 'sub-interface') or
	"derived-from-or-self(../if:type,		derived-from-or-self(if:type, 'ianaift:atmSubInterface') or
	'ianaift:ethernetCsmacd') or		derived-from-or-self(if:type, 'ianaift:frameRelay')" {
	derived-from-or-self(../if:type,
	'ianaift:ieee8023adLag') or
	derived-from-or-self(../if:type, 'ianaift:pos') or
	derived-from-or-self(../if:type,
	'ianaift:atmSubInterface') or
	derived-from-or-self(../if:type, 'ethSubInterface')" {
	description		description
	"All interface types that can have a configurable L2		"Any ianaift:types that explicitly represent sub-interfaces
	encapsulation";		or any types that derive from the sub-interface identity.";
	}		}
			if-feature "sub-interfaces";
	description		description
	"Holds the OSI layer 2 encapsulation associated with an		"Adds a parent interface field to interfaces that model
	interface";		sub-interfaces.";
	choice encaps-type {		leaf parent-interface {
	description
	"Extensible choice of layer 2 encapsulations";
	reference "RFC XXX, Section 3.3 Encapsulation";
	}
	}
	/*
	* Various types of interfaces support loopback configuration,
	* any that are supported by YANG should be listed here.
	*/
	leaf loopback {
	when "derived-from-or-self(../if:type,
	'ianaift:ethernetCsmacd') or
	derived-from-or-self(../if:type, 'ianaift:sonet') or
	derived-from-or-self(../if:type, 'ianaift:atm') or
	derived-from-or-self(../if:type, 'ianaift:otnOtu')" {
	description
	"All interface types that support loopback configuration.";
	}
	if-feature "loopback";
	type identityref {
	base loopback;
	}
	description "Enables traffic loopback.";
	reference "RFC XXX, Section 3.4 Loopback";
	}
	/*		type if:interface-ref;
	* Many types of interfaces support a configurable layer 2 MTU.
	*/
	leaf l2-mtu {
	if-feature "configurable-l2-mtu";
	type uint16 {
	range "64 .. 65535";
	}
	description
	"The maximum size of layer 2 frames that may be transmitted
	or received on the interface (excluding any FCS overhead).
	In the case of Ethernet interfaces it also excludes the
	4-8 byte overhead of any known (i.e. explicitly matched by
	a child sub-interface) 802.1Q VLAN tags.";
	reference "RFC XXX, Section 3.5 Layer 2 MTU";
	}
	/*		mandatory true;
	* Augments the IETF interfaces model with a leaf that indicates		description
	* which mode, or layer, is being used to forward the traffic.		"This is the reference to the parent interface of this
	*/		sub-interface.";
	leaf forwarding-mode {		reference "RFC XXX, Section 2.6 Sub-interface";
	if-feature "forwarding-mode";
	type identityref {
	base forwarding-mode;
	}		}
	description
	"The forwarding mode that the interface is operating in.";
	reference "RFC XXX, Section 3.7 Forwarding Mode";
	}
	}
	/*
	* Add generic support for sub-interfaces.
	*
	* This should be extended to cover all interface types that are
	* child interfaces of other interfaces.
	*/
	augment "/if:interfaces/if:interface" {
	when "derived-from(if:type, 'sub-interface') or
	derived-from-or-self(if:type, 'ianaift:atmSubInterface') or
	derived-from-or-self(if:type, 'ianaift:frameRelay')" {
	description
	"Any ianaift:types that explicitly represent sub-interfaces
	or any types that derive from the sub-interface identity";
	}
	if-feature "sub-interfaces";
	description
	"Add a parent interface field to interfaces that model
	sub-interfaces";
	leaf parent-interface {
	type if:interface-ref;
	mandatory true;
	description
	"This is the reference to the parent interface of this
	sub-interface.";
	reference "RFC XXX, Section 3.6 Sub-interface";
	}		}
	}		}
	}		<CODE ENDS>
	<CODE ENDS>
	6. Interfaces Ethernet-Like YANG Module		5. Interfaces Ethernet-Like YANG Module
	This YANG module augments the interface container defined in RFC 8343		This YANG module augments the interface container defined in RFC 8343
	[RFC8343] for Ethernet-like interfaces. This includes Ethernet		[RFC8343] for Ethernet-like interfaces. This includes Ethernet
	interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces,		interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces,
	Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces.		Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces.
	<CODE BEGINS> file "ietf-interfaces-ethernet-like@2019-03-05.yang"		<CODE BEGINS> file "ietf-if-ethernet-like@2019-11-04.yang"
	module ietf-interfaces-ethernet-like {		module ietf-if-ethernet-like {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like";		"urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like";
	prefix ethlike;		prefix ethlike;
			import ietf-interfaces {
			prefix if;
			reference
			"RFC 8343: A YANG Data Model For Interface Management";
			}
	import ietf-interfaces {		import ietf-yang-types {
	prefix if;		prefix yang;
	}		reference "RFC 6991: Common YANG Data Types";
			}
	import ietf-yang-types {		import iana-if-type {
	prefix yang;		prefix ianaift;
	}		reference "RFC 7224: IANA Interface Type YANG Module";
			}
	import iana-if-type {		organization
	prefix ianaift;		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	}
	organization		contact
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"WG Web: <http://tools.ietf.org/wg/netmod/>
			WG List: <mailto:netmod@ietf.org>
	contact		Editor: Robert Wilton
	"WG Web: <http://tools.ietf.org/wg/netmod/>		<mailto:rwilton@cisco.com>";
	WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		description
	<mailto:lberger@labn.net>		"This module contains YANG definitions for configuration for
			'Ethernet-like' interfaces. It is applicable to all interface
			types that use Ethernet framing and expose an Ethernet MAC
			layer, and includes such interfaces as physical Ethernet
			interfaces, Ethernet LAG interfaces and VLAN sub-interfaces.
	WG Chair: Joel Jaeggli		Additional interface configuration and counters for physical
	<mailto:joelja@gmail.com>		Ethernet interfaces are defined in
			ieee802-ethernet-interface.yang, as part of IEEE Std
			802.3.2-2019.
	WG Chair: Kent Watsen		Copyright (c) 2019 IETF Trust and the persons identified as
	<mailto:kwatsen@juniper.net>		authors of the code. All rights reserved.
	Editor: Robert Wilton		Redistribution and use in source and binary forms, with or
	<mailto:rwilton@cisco.com>";		without modification, is permitted pursuant to, and subject to
			the license terms contained in, the Simplified BSD License set
			forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(https://trustee.ietf.org/license-info).
	description		This version of this YANG module is part of RFC XXXX
	"This module contains YANG definitions for configuration for		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	'Ethernet-like' interfaces. It is applicable to all interface		for full legal notices.";
	types that use Ethernet framing and expose an Ethernet MAC
	layer, and includes such interfaces as physical Ethernet
	interfaces, Ethernet LAG interfaces and VLAN sub-interfaces.
	Copyright (c) 2016-2019 IETF Trust and the persons identified		revision 2019-11-04 {
	as authors of the code. All rights reserved.		description "Initial revision.";
	Redistribution and use in source and binary forms, with or		reference
	without modification, is permitted pursuant to, and subject		"RFC XXX, Common Interface Extension YANG Data Models";
	to the license terms contained in, the Simplified BSD License		}
	set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents
	(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of XXX; see the RFC		feature configurable-mac-address {
	itself for full legal notices.";		description
			"This feature indicates that MAC addresses on Ethernet-like
			interfaces can be configured.";
			reference "RFC XXX, Section 3 Interfaces Ethernet-Like Module";
			}
	revision 2019-03-05 {		/*
	description "Initial revision";		* Configuration parameters for Ethernet-like interfaces.
			*/
			augment "/if:interfaces/if:interface" {
			when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
			derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
			derived-from-or-self(if:type, 'ianaift:ifPwType')" {
			description "Applies to all Ethernet-like interfaces";
			}
			description
			"Augment the interface model with parameters for all
			Ethernet-like interfaces.";
	reference		container ethernet-like {
	"Internet draft: draft-ietf-netmod-intf-ext-yang-07";		description
	}		"Contains parameters for interfaces that use Ethernet framing
			and expose an Ethernet MAC layer.";
	/*		leaf mac-address {
	* Configuration parameters for Ethernet-like interfaces.		if-feature "configurable-mac-address";
	*/		type yang:mac-address;
	augment "/if:interfaces/if:interface" {		description
	when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or		"The MAC address of the interface. The operational value
	derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or		matches the /if:interfaces/if:interface/if:phys-address
	derived-from-or-self(if:type, 'ianaift:l2vlan') or		leaf defined in ietf-interface.yang.";
	derived-from-or-self(if:type, 'ianaift:ifPwType')" {		}
	description "Applies to all Ethernet-like interfaces";
	}
	description
	"Augment the interface model with parameters for all
	Ethernet-like interfaces";
	container ethernet-like {		leaf bia-mac-address {
	description		type yang:mac-address;
	"Contains parameters for interfaces that use Ethernet framing		config false;
	and expose an Ethernet MAC layer.";		description
	leaf mac-address {		"The 'burnt-in' MAC address. I.e the default MAC address
	type yang:mac-address;		assigned to the interface if no MAC address has been
	description		explicitly configured on it.";
	"The MAC address of the interface.";		}
	}		}
			}
	leaf bia-mac-address {		/*
	type yang:mac-address;		* Configuration parameters for Ethernet-like interfaces.
	config false;		*/
	description		augment "/if:interfaces/if:interface/if:statistics" {
	"The 'burnt-in' MAC address. I.e the default MAC address		when "derived-from-or-self(../if:type,
	assigned to the interface if no MAC address has been		'ianaift:ethernetCsmacd') or
	explicitly configured on it.";		derived-from-or-self(../if:type,
	}		'ianaift:ieee8023adLag') or
			derived-from-or-self(../if:type, 'ianaift:ifPwType')" {
			description "Applies to all Ethernet-like interfaces";
			}
			description
			"Augment the interface model statistics with additional
			counters related to Ethernet-like interfaces.";
	container statistics {		leaf in-drop-unknown-dest-mac-pkts {
	config false;		type yang:counter64;
	description		units frames;
	"Packet statistics that apply to all Ethernet-like		description
	interfaces";		"A count of the number of frames that were well formed, but
	leaf in-drop-unknown-dest-mac-pkts {		otherwise dropped because the destination MAC address did
	type yang:counter64;		not pass any ingress destination MAC address filter.
	units frames;
	description
	"A count of the number of frames that were well formed,
	but otherwise dropped because the destination MAC
	address did not pass any ingress destination MAC address
	filter.
	For consistency, frames counted against this drop		For consistency, frames counted against this drop counters
	counters are also counted against the IETF interfaces		are also counted against the IETF interfaces statistics. In
	statistics. In particular, they are included in		particular, they are included in in-octets and in-discards,
	in-octets and in-discards, but are not included in		but are not included in in-unicast-pkts, in-multicast-pkts
	in-unicast-pkts, in-multicast-pkts or in-broadcast-pkts,		or in-broadcast-pkts, because they are not delivered to a
	because they are not delivered to a higher layer.		higher layer.
	Discontinuities in the values of this counters in this		Discontinuities in the values of this counter can occur at
	container can occur at re-initialization of the		re-initialization of the management system, and at other
	management system, and at other times as indicated by		times as indicated by the value of the 'discontinuity-time'
	the value of the 'discontinuity-time' leaf defined in		leaf defined in the ietf-interfaces YANG module (RFC 8343).";
	the ietf-interfaces YANG module (RFC 8343).";		}
	}		}
	}		}
	}		<CODE ENDS>
	}
	}
	<CODE ENDS>
	7. Examples		6. Examples
	The following sections give some examples of how different parts of		The following sections give some examples of how different parts of
	the YANG modules could be used. Examples are not given for the more		the YANG modules could be used. Examples are not given for the more
	trivial configuration, or for sub-interfaces, for which examples are		trivial configuration, or for sub-interfaces, for which examples are
	contained in [I-D.ietf-netmod-sub-intf-vlan-model].		contained in [I-D.ietf-netmod-sub-intf-vlan-model].
	7.1. Carrier delay configuration		6.1. Carrier delay configuration
	The following example shows how the operational state datastore could		The following example shows how the operational state datastore could
	look like for an Ethernet interface without any carrier delay		look like for an Ethernet interface without any carrier delay
	configuration. The down leaf value of 0 indicates that link down		configuration. The down leaf value of 0 indicates that link down
	events as always propagated to high layers immediately, but an up		events as always propagated to high layers immediately, but an up
	leaf value of 50 indicates that the interface must be up and stable		leaf value of 50 indicates that the interface must be up and stable
	for at least 50 msecs before the interface is reported as being up to		for at least 50 msecs before the interface is reported as being up to
	the high layers.		the high layers.
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<interfaces		<interfaces
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"		xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
	xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"		xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
	xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common">		xmlns:if-ext="urn:ietf:params:xml:ns:yang:ietf-if-extensions">
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<type>ianaift:ethernetCsmacd</type>		<type>ianaift:ethernetCsmacd</type>
	<if-cmn:carrier-delay>		<if-ext:carrier-delay>
	<if-cmn:down>0</if-cmn:down>		<if-ext:down>0</if-ext:down>
	<if-cmn:up>50</if-cmn:up>		<if-ext:up>50</if-ext:up>
	</if-cmn:carrier-delay>		</if-ext:carrier-delay>
	</interface>		</interface>
	</interfaces>		</interfaces>
	The following example shows explicit carrier delay up and down values		The following example shows explicit carrier delay up and down values
	have been configured. A 50 msec down leaf value has been used to		have been configured. A 50 msec down leaf value has been used to
	potentially allow optical protection to recover the link before the		potentially allow optical protection to recover the link before the
	higher layer protocol state is flapped. A 1 second (1000		higher layer protocol state is flapped. A 1 second (1000
	milliseconds) up leaf value has been used to ensure that the link is		milliseconds) up leaf value has been used to ensure that the link is
	always reasonably stable before allowing traffic to be carried over		always reasonably stable before allowing traffic to be carried over
	it. This also has the benefit of greatly reducing the rate at which		it. This also has the benefit of greatly reducing the rate at which
	higher layer protocol state flaps could occur.		higher layer protocol state flaps could occur.
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<interfaces		<interfaces
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"		xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
	xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"		xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
	xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common">		xmlns:if-ext="urn:ietf:params:xml:ns:yang:ietf-if-extensions">
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<type>ianaift:ethernetCsmacd</type>		<type>ianaift:ethernetCsmacd</type>
	<if-cmn:carrier-delay>		<if-ext:carrier-delay>
	<if-cmn:down>50</if-cmn:down>		<if-ext:down>50</if-ext:down>
	<if-cmn:up>1000</if-cmn:up>		<if-ext:up>1000</if-ext:up>
	</if-cmn:carrier-delay>		</if-ext:carrier-delay>
	</interface>		</interface>
	</interfaces>		</interfaces>
	</config>		</config>
	7.2. Dampening configuration		6.2. Dampening configuration
	The following example shows what the operational state datastore may		The following example shows what the operational state datastore may
	look like for an interface configured with interface dampening. The		look like for an interface configured with interface dampening. The
	'suppressed' leaf indicates that the interface is currently		'suppressed' leaf indicates that the interface is currently
	suppressed (i.e. down) because the 'penalty' is greater than the		suppressed (i.e. down) because the 'penalty' is greater than the
	'suppress' leaf threshold. The 'time-remaining' leaf indicates that		'suppress' leaf threshold. The 'time-remaining' leaf indicates that
	the interface will remain suppressed for another 103 seconds before		the interface will remain suppressed for another 103 seconds before
	the 'penalty' is below the 'reuse' leaf value and the interface is		the 'penalty' is below the 'reuse' leaf value and the interface is
	allowed to go back up again.		allowed to go back up again.
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<interfaces		<interfaces
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"		xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
	xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">		xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<type>ianaift:ethernetCsmacd</type>		<type>ianaift:ethernetCsmacd</type>
			<oper-status>down</oper-status>
	<dampening		<dampening
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces-common">		xmlns="urn:ietf:params:xml:ns:yang:ietf-if-extensions">
	<half-life>60</half-life>		<half-life>60</half-life>
	<reuse>750</reuse>		<reuse>750</reuse>
	<suppress>2000</suppress>		<suppress>2000</suppress>
	<max-suppress-time>240</max-suppress-time>		<max-suppress-time>240</max-suppress-time>
	<penalty>2480</penalty>		<penalty>2480</penalty>
	<suppressed>true</suppressed>		<suppressed>true</suppressed>
	<time-remaining>103</time-remaining>		<time-remaining>103</time-remaining>
	</dampening>		</dampening>
	</interface>		</interface>
	</interfaces>		</interfaces>
	7.3. MAC address configuration		6.3. MAC address configuration
	The following example shows how the operational state datastore could		The following example shows how the operational state datastore could
	look like for an Ethernet interface without an explicit MAC address		look like for an Ethernet interface without an explicit MAC address
	configured. The mac-address leaf always reports the actual		configured. The mac-address leaf always reports the actual
	operational MAC address that is in use. The bia-mac-address leaf		operational MAC address that is in use. The bia-mac-address leaf
	always reports the default MAC address assigned to the hardware.		always reports the default MAC address assigned to the hardware.
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<interfaces		<interfaces
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"		xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
	xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">		xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<type>ianaift:ethernetCsmacd</type>		<type>ianaift:ethernetCsmacd</type>
			<phys-address>00:00:5E:00:53:30</phys-address>
	<ethernet-like		<ethernet-like
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like">		xmlns="urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like">
	<mac-address>00:00:5E:00:53:30</mac-address>		<mac-address>00:00:5E:00:53:30</mac-address>
	<bia-mac-address>00:00:5E:00:53:30</bia-mac-address>		<bia-mac-address>00:00:5E:00:53:30</bia-mac-address>
	</ethernet-like>		</ethernet-like>
	</interface>		</interface>
	</interfaces>		</interfaces>
	The following example shows an explicit MAC address being configured		The following example shows the intended configuration for interface
	on interface eth0.		eth0 with an explicit MAC address configured.
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<interfaces		<interfaces
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"		xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
	xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">		xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<type>ianaift:ethernetCsmacd</type>		<type>ianaift:ethernetCsmacd</type>
	<ethernet-like		<ethernet-like
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like">		xmlns="urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like">
	<mac-address>00:00:5E:00:53:35</mac-address>		<mac-address>00:00:5E:00:53:35</mac-address>
	</ethernet-like>		</ethernet-like>
	</interface>		</interface>
	</interfaces>		</interfaces>
	</config>		</config>
	After the MAC address configuration has been successfully applied,		After the MAC address configuration has been successfully applied,
	the operational state datastore reporting the interface MAC address		the operational state datastore reporting the interface MAC address
	properties would contain the following, with the mac-address leaf		properties would contain the following, with the mac-address leaf
	updated to match the configured value, but the bia-mac-address leaf		updated to match the configured value, but the bia-mac-address leaf
	retaining the same value - which should never change.		retaining the same value - which should never change.
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<interfaces		<interfaces
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"		xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
	xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">		xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<type>ianaift:ethernetCsmacd</type>		<type>ianaift:ethernetCsmacd</type>
			<phys-address>00:00:5E:00:53:35</phys-address>
	<ethernet-like		<ethernet-like
	xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like">		xmlns="urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like">
	<mac-address>00:00:5E:00:53:35</mac-address>		<mac-address>00:00:5E:00:53:35</mac-address>
	<bia-mac-address>00:00:5E:00:53:30</bia-mac-address>		<bia-mac-address>00:00:5E:00:53:30</bia-mac-address>
	</ethernet-like>		</ethernet-like>
	</interface>		</interface>
	</interfaces>		</interfaces>
	8. Acknowledgements		7. Acknowledgements
	The authors wish to thank Eric Gray, Ing-Wher Chen, Juergen		The authors wish to thank Eric Gray, Ing-Wher Chen, Jon Culver,
	Schoenwaelder, Ladislav Lhotka, Mahesh Jethanandani, Michael Zitao,		Juergen Schoenwaelder, Ladislav Lhotka, Lou Berger, Mahesh
	Neil Ketley, Qin Wu, William Lupton, Xufeng Liu, and Andy Bierman for		Jethanandani, Martin Bjorklund, Michael Zitao, Neil Ketley, Qin Wu,
	their helpful comments contributing to this draft.		William Lupton, Xufeng Liu, Andy Bierman, and Vladimir Vassilev for
			their helpful comments contributing to this document.
	9. ChangeLog		8. ChangeLog
	XXX, RFC Editor, please delete this change log before publication.		XXX, RFC Editor, please delete this change log before publication.
	9.1. Version -07		8.1. Version -08
			o Initial updates after WG LC comments.
			8.2. Version -07
	o Minor editorial updates		o Minor editorial updates
	9.2. Version -06		8.3. Version -06
	o Remove reservable-bandwidth, based on Acee's suggestion		o Remove reservable-bandwidth, based on Acee's suggestion
	o Add examples		o Add examples
	o Add additional state parameters for carrier-delay and dampening		o Add additional state parameters for carrier-delay and dampening
	9.3. Version -05		8.4. Version -05
	o Incorporate feedback from Andy Bierman		o Incorporate feedback from Andy Bierman
	9.4. Version -04		8.5. Version -04
	o Incorporate feedback from Lada, some comments left as open issues.		o Incorporate feedback from Lada, some comments left as open issues.
	9.5. Version -03		8.6. Version -03
	o Fixed incorrect module name references, and updated tree output		o Fixed incorrect module name references, and updated tree output
	9.6. Version -02		8.7. Version -02
	o Minor changes only: Fix errors in when statements, use derived-		o Minor changes only: Fix errors in when statements, use derived-
	from-or-self() for future proofing.		from-or-self() for future proofing.
	10. IANA Considerations		9. IANA Considerations
	This document defines several new YANG module and the authors		This document defines several new YANG module and the authors
	politely request that IANA assigns unique names to the two YANG		politely request that IANA assigns unique names to the two YANG
	module files contained within this draft, and also appropriate URIs		module files contained within this document, and also appropriate
	in the "IETF XML Registry".		URIs in the "IETF XML Registry".
	11. Security Considerations		10. 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 RFC 6241 [RFC6241]. The lowest NETCONF layer is		the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is
	the secure transport layer and the mandatory to implement secure		the secure transport layer and the mandatory to implement secure
	transport is SSH RFC 6242 [RFC6242]. The NETCONF access control		transport is SSH RFC 6242 [RFC6242]. The NETCONF access control
	model RFC 6536 [RFC6536] provides the means to restrict access for		model RFC 6536 [RFC6536] provides the means to restrict access for
	particular NETCONF users to a pre-configured subset of all available		particular NETCONF users to a pre-configured subset of all available
	NETCONF protocol operations and content.		NETCONF protocol operations and content.
	There are a number of data nodes defined in this YANG module which		There are a number of data nodes defined in this YANG module which
	are writable/creatable/deletable (i.e. config true, which is the		are 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) to		in some network environments. Write operations (e.g. edit-config) to
	these data nodes without proper protection can have a negative effect		these data nodes without proper protection can have a negative effect
	on network operations. These are the subtrees and data nodes and		on network operations. These are the subtrees and data nodes and
	their sensitivity/vulnerability:		their sensitivity/vulnerability:
	11.1. interfaces-common.yang		10.1. ietf-if-extensions.yang
	The interfaces-common YANG module contains various configuration		The ietf-if-extensions YANG module contains various configuration
	leaves that affect the behavior of interfaces. Modifying these		leaves that affect the behavior of interfaces. Modifying these
	leaves can cause an interface to go down, or become unreliable, or to		leaves can cause an interface to go down, or become unreliable, or to
	drop traffic forwarded over it. More specific details of the		drop traffic forwarded over it. More specific details of the
	possible failure modes are given below.		possible failure modes are given below.
	The following leaf could cause the interface to go down, and stop		The following leaf could cause the interface to go down and stop
	processing any ingress or egress traffic on the interface:		processing any ingress or egress traffic on the interface. It could
			also cause broadcast traffic storms.
	o /if:interfaces/if:interface/loopback		o /if:interfaces/if:interface/loopback
	The following leaves could cause instabilities at the interface link		The following leaves could cause instabilities at the interface link
	layer, and cause unwanted higher layer routing path changes if the		layer, and cause unwanted higher layer routing path changes if the
	leaves are modified, although they would generally only affect a		leaves are modified, although they would generally only affect a
	device that had some underlying link stability issues:		device that had some underlying link stability issues:
	o /if:interfaces/if:interface/carrier-delay/down		o /if:interfaces/if:interface/carrier-delay/down
	skipping to change at page 29, line 51 ¶		skipping to change at page 30, line 18 ¶
	o /if:interfaces/if:interface/dampening/suppress		o /if:interfaces/if:interface/dampening/suppress
	o /if:interfaces/if:interface/dampening/max-suppress-time		o /if:interfaces/if:interface/dampening/max-suppress-time
	The following leaves could cause traffic loss on the interface		The following leaves could cause traffic loss on the interface
	because the received or transmitted frames do not comply with the		because the received or transmitted frames do not comply with the
	frame matching criteria on the interface and hence would be dropped:		frame matching criteria on the interface and hence would be dropped:
	o /if:interfaces/if:interface/encapsulation		o /if:interfaces/if:interface/encapsulation
	o /if:interfaces/if:interface/l2-mtu		o /if:interfaces/if:interface/max-frame-size
	o /if:interfaces/if:interface/forwarding-mode		o /if:interfaces/if:interface/forwarding-mode
	Normally devices will not allow the parent-interface leaf to be		Changing the parent-interface leaf could cause all traffic on the
	changed after the interfce has been created. If an implementation		affected interface to be dropped. The affected leaf is:
	did allow the parent-interface leaf to be changed then it could cause
	all traffic on the affected interface to be dropped. The affected
	leaf is:
	o /if:interfaces/if:interface/parent-interface		o /if:interfaces/if:interface/parent-interface
	11.2. interfaces-ethernet-like.yang		10.2. ietf-if-ethernet-like.yang
	Generally, the configuration nodes in the interfaces-ethernet-like		Generally, the configuration nodes in the ietf-if-ethernet-like YANG
	YANG module are concerned with configuration that is common across		module are concerned with configuration that is common across all
	all types of Ethernet-like interfaces. The module currently only		types of Ethernet-like interfaces. The module currently only
	contains a node for configuring the operational MAC address to use on		contains a node for configuring the operational MAC address to use on
	an interface. Adding/modifying/deleting this leaf has the potential		an interface. Adding/modifying/deleting this leaf has the potential
	risk of causing protocol instability, excessive protocol traffic, and		risk of causing protocol instability, excessive protocol traffic, and
	general traffic loss, particularly if the configuration change caused		general traffic loss, particularly if the configuration change caused
	a duplicate MAC address to be present on the local network . The		a duplicate MAC address to be present on the local network . The
	following leaf is affected:		following leaf is affected:
	o interfaces/interface/ethernet-like/mac-address		o interfaces/interface/ethernet-like/mac-address
	12. References		11. References
	12.1. Normative References		11.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	skipping to change at page 31, line 9 ¶		skipping to change at page 31, line 22 ¶
	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture		and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,		(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.		<https://www.rfc-editor.org/info/rfc8342>.
	[RFC8343] Bjorklund, M., "A YANG Data Model for Interface		[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,		Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
	<https://www.rfc-editor.org/info/rfc8343>.		<https://www.rfc-editor.org/info/rfc8343>.
	12.2. Informative References		11.2. Informative References
	[I-D.ietf-netmod-sub-intf-vlan-model]		[I-D.ietf-netmod-sub-intf-vlan-model]
	Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.		Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
	Sivaraj, "Sub-interface VLAN YANG Data Models", draft-		Sivaraj, "Sub-interface VLAN YANG Data Models", draft-
	ietf-netmod-sub-intf-vlan-model-04 (work in progress),		ietf-netmod-sub-intf-vlan-model-05 (work in progress),
	July 2018.		March 2019.
			[IEEE802.3.2]
			IEEE WG802.3 - Ethernet Working Group, "IEEE
			802.3.2-2019", 2019.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.		<https://www.rfc-editor.org/info/rfc6242>.
	skipping to change at page 32, line 4 ¶		skipping to change at page 32, line 19 ¶
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
	Authors' Addresses		Authors' Addresses
	Robert Wilton (editor)		Robert Wilton (editor)
	Cisco Systems		Cisco Systems
	Email: rwilton@cisco.com		Email: rwilton@cisco.com
	David Ball		David Ball
	Cisco Systems		Cisco Systems
	Email: daviball@cisco.com		Email: daviball@cisco.com
	Tapraj Singh		Tapraj Singh
	Cisco Systems		Cisco Systems
	Email: tapsingh@juniper.net		Email: tapsingh@cisco.com
	Selvakumar Sivaraj		Selvakumar Sivaraj
	Juniper Networks		Juniper Networks
	Email: ssivaraj@juniper.net		Email: ssivaraj@juniper.net
End of changes. 171 change blocks.
	745 lines changed or deleted		738 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/