draft-ietf-netmod-sub-intf-vlan-model-04.txt		draft-ietf-netmod-sub-intf-vlan-model-05.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: Informational T. Singh		Intended status: Standards Track T. Singh
	Expires: January 3, 2019 Cisco Systems		Expires: September 7, 2019 Cisco Systems
	S. Sivaraj		S. Sivaraj
	Juniper Networks		Juniper Networks
	July 2, 2018		March 6, 2019
	Sub-interface VLAN YANG Data Models		Sub-interface VLAN YANG Data Models
	draft-ietf-netmod-sub-intf-vlan-model-04		draft-ietf-netmod-sub-intf-vlan-model-05
	Abstract		Abstract
	This document defines YANG modules to add support for classifying		This document defines YANG modules to add support for classifying
	traffic received on interfaces as Ethernet/VLAN framed packets to		traffic received on interfaces as Ethernet/VLAN framed packets to
	sub-interfaces based on the fields available in the Ethernet/VLAN		sub-interfaces based on the fields available in the Ethernet/VLAN
	frame headers. These modules allow configuration of Layer 3 and		frame headers. These modules allow configuration of Layer 3 and
	Layer 2 sub-interfaces (e.g. attachment circuits) that can		Layer 2 sub-interfaces (e.g. attachment circuits) that can
	interoperate with IETF based forwarding protocols; such as IP and		interoperate with IETF based forwarding protocols; such as IP and
	L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The		L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The
	sub-interfaces also interoperate with VLAN tagged traffic orginating		sub-interfaces also interoperate with VLAN tagged traffic orginating
	from an IEEE 802.1Q compliant bridge. Primarily the classification		from an IEEE 802.1Q compliant bridge.
	is based on VLAN identifiers in the 802.1Q VLAN tags, but the model
	also has support for matching on some other layer 2 frame header
	fields and is designed to be extensible to match on other arbitrary
	header fields.
	The model differs from an IEEE 802.1Q bridge model in that the		The model differs from an IEEE 802.1Q bridge model in that the
	configuration is interface/sub-interface based as opposed to being		configuration is interface/sub-interface based as opposed to being
	based on membership of an 802.1Q VLAN bridge.		based on membership of an 802.1Q VLAN bridge.
			The YANG data models in this document conforms to the Network
			Management 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 January 3, 2019.		This Internet-Draft will expire on September 7, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
	2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4		2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4
	2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4		3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 4
	3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 5
	4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5		4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5
	5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7		5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7
	6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10		6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10
	7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19		7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19		7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19
	7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21		7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23		9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	9.1. WG version -04 . . . . . . . . . . . . . . . . . . . . . 23		9.1. WG version -05 . . . . . . . . . . . . . . . . . . . . . 24
	9.2. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24		9.2. WG version -04 . . . . . . . . . . . . . . . . . . . . . 24
	9.3. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24		9.3. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24
	9.4. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24		9.4. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24
	9.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24		9.5. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24
	9.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 24		9.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		9.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 25
			10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 25		11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25		11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25
	11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 25		11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 26
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
	12.1. Normative References . . . . . . . . . . . . . . . . . . 27		12.1. Normative References . . . . . . . . . . . . . . . . . . 28
	12.2. Informative References . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29		Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29
	A.1. Sub-interface based configuration model overview . . . . 29		A.1. Sub-interface based configuration model overview . . . . 29
	A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30		A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30
	A.3. Possible Overlap Between the Two Models . . . . . . . . . 30		A.3. Possible Overlap Between the Two Models . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	This document defines two YANG [RFC7950] modules that augment the		This document defines two YANG [RFC7950] modules that augment the
	encapsulation choice YANG element defined in Interface Extensions		encapsulation choice YANG element defined in Interface Extensions
	YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data		YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data
	model defined in [RFC8343]. The two modules provide configuration		model defined in [RFC8343]. The two modules provide configuration
	nodes to support classification of Ethernet/VLAN traffic to sub-		nodes to support classification of Ethernet/VLAN traffic to sub-
	interfaces, that can have interface based feature and service		interfaces, that can have interface based feature and service
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	Sub-interface: A sub-interface is a small augmentation of a regular		Sub-interface: A sub-interface is a small augmentation of a regular
	interface in the standard YANG module for Interface Management that		interface in the standard YANG module for Interface Management that
	represents a subset of the traffic handled by its parent interface.		represents a subset of the traffic handled by its parent interface.
	As such, it supports both configuration and operational data using		As such, it supports both configuration and operational data using
	any other YANG models that augment or reference interfaces in the		any other YANG models that augment or reference interfaces in the
	normal way. It is defined in Interface Extensions YANG		normal way. It is defined in Interface Extensions YANG
	[I-D.ietf-netmod-intf-ext-yang].		[I-D.ietf-netmod-intf-ext-yang].
	1.2. Tree Diagrams		1.2. Tree Diagrams
	A simplified graphical representation of the data model is used in		Tree diagrams used in this document follow the notation defined in
	this document. The meaning of the symbols in these diagrams is as		[RFC8340].
	follows:
	o Brackets "[" and "]" enclose list keys.
	o Abbreviations before data node names: "rw" means configuration
	(read-write), and "ro" means state data (read-only).
	o Symbols after data node names: "?" means an optional node, "!"
	means a presence container, and "*" denotes a list or leaf-list.
	o Parentheses enclose choice and case nodes, and case nodes are also
	marked with a colon (":").
	o Ellipsis ("...") stands for contents of subtrees that are not
	shown.
	2. Objectives		2. Objectives
	The primary aim of the YANG modules contained in this draft is to		The primary aim of the YANG modules contained in this draft is to
	provide the core model that is required to implement VLAN transport		provide the core model that is required to implement VLAN transport
	services on router based devices that is fully compatible with IEEE		services on router based devices that is fully compatible with IEEE
	802.1Q compliant bridges.		802.1Q compliant bridges.
	A secondary aim is for the modules to be structured in such a way		A secondary aim is for the modules to be structured in such a way
	that they can be cleanly extended in future.		that they can be cleanly extended in future.
	2.1. Interoperability with IEEE 802.1Q compliant bridges		2.1. Interoperability with IEEE 802.1Q compliant bridges
	The modules defined in this document are designed to fully		The modules defined in this document are designed to fully
	interoperate with IEEE 802.1Q compliant bridges. In particular, the		interoperate with IEEE 802.1Q compliant bridges. In particular, the
	models are restricted to only matching, adding, or rewriting the		models are restricted to only matching, adding, or rewriting the
	802.1Q VLAN tags in frames in ways that are compatible with IEEE		802.1Q VLAN tags in frames in ways that are compatible with IEEE
	802.1Q compliant bridges.		802.1Q compliant bridges.
	2.2. Extensibility
	The modules are structured in such a way that they can be sensibly
	extended. In particular:
	The tag stack is represented as a list to allow a tag stack of
	more than two tags to be supported if necessary in future.
	The tag stack list elements allow other models, or vendors, to
	include additional forms of tag matching and rewriting. The
	intention, however, is that it should not be necessary to have any
	vendor specific extensions to any of the YANG models defined in
	this document to implement standard Ethernet and VLAN services.
	3. L3 Interface VLAN Model		3. L3 Interface VLAN Model
	The L3 Interface VLAN model provides appropriate leaves for		The L3 Interface VLAN model provides appropriate leaves for
	termination of an 802.1Q VLAN tagged segment to a sub-interface based		termination of an 802.1Q VLAN tagged segment to a sub-interface based
	L3 service. It allows for termination of traffic with up to two		L3 service. It allows for termination of traffic with up to two
	802.1Q VLAN tags.		802.1Q VLAN tags.
	The "if-l3-vlan" YANG module has the following structure:		The "if-l3-vlan" YANG module has the following structure:
	module: ietf-if-l3-vlan		module: ietf-if-l3-vlan
	augment /if:interfaces/if:interface/if-cmn:encapsulation/		augment /if:interfaces/if:interface/if-cmn:encapsulation/
	if-cmn:encaps-type:		if-cmn:encaps-type:
	+--:(dot1q-vlan)		+--:(dot1q-vlan)
	+--rw dot1q-vlan		+--rw dot1q-vlan
	+--rw outer-tag!		+--rw outer-tag
	| +--rw tag-type dot1q-tag-type		| +--rw tag-type dot1q-tag-type
	| +--rw vlan-id ieee:vlanid		| +--rw vlan-id vlanid
	+--rw second-tag!		+--rw second-tag!
	+--rw tag-type dot1q-tag-type		+--rw tag-type dot1q-tag-type
	+--rw vlan-id ieee:vlanid		+--rw vlan-id vlanid
	4. Flexible Encapsulation Model		4. Flexible Encapsulation Model
	The Flexible Encapsulation model is designed to allow for the		The Flexible Encapsulation model is designed to allow for the
	flexible provisioning of layer 2 services. It provides the		flexible provisioning of layer 2 services. It provides the
	capability to classify Ethernet/VLAN frames received on an Ethernet		capability to classify Ethernet/VLAN frames received on an Ethernet
	trunk interface to sub-interfaces based on the fields available in		trunk interface to sub-interfaces based on the fields available in
	the layer 2 headers. Once classified to sub-interfaces, it provides		the layer 2 headers. Once classified to sub-interfaces, it provides
	the capability to selectively modify fields within the layer 2		the capability to selectively modify fields within the layer 2
	headers before the frame is handed off to the appropriate forwarding		headers before the frame is handed off to the appropriate forwarding
	skipping to change at page 6, line 11 ¶		skipping to change at page 5, line 31 ¶
	data frames as they are processed on the interface. It defines a set		data frames as they are processed on the interface. It defines a set
	of standard tag manipulations that allow for the insertion, removal,		of standard tag manipulations that allow for the insertion, removal,
	or rewrite of one or two 802.1Q VLAN tags. The expectation is that		or rewrite of one or two 802.1Q VLAN tags. The expectation is that
	manipulations are generally implemented in a symmetrical fashion,		manipulations are generally implemented in a symmetrical fashion,
	i.e. if a manipulation is performed on ingress traffic on an		i.e. if a manipulation is performed on ingress traffic on an
	interface then the reverse manipulation is always performed on egress		interface then the reverse manipulation is always performed on egress
	traffic out of the same interface. However, the model also allows		traffic out of the same interface. However, the model also allows
	for asymmetrical rewrites, which may be required to implement some		for asymmetrical rewrites, which may be required to implement some
	forwarding models (such as E-Tree).		forwarding models (such as E-Tree).
	The structure of the model is currently limited to matching or
	rewriting a maximum of two 802.1Q tags in the frame header but has
	been designed to be easily extensible to matching/rewriting three or
	more VLAN tags in future, if required.
	The final aim for the model design is for it to be cleanly extensible		The final aim for the model design is for it to be cleanly extensible
	to add in additional match and rewrite criteria of the layer 2		to add in additional match and rewrite criteria of the layer 2
	header, such as matching on the source or destination MAC address,		header, such as matching on the source or destination MAC address,
	PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame		PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame
	payload. Rewrites can also be extended to allow for modification of		payload. Rewrites can also be extended to allow for modification of
	other fields within the layer 2 frame header.		other fields within the layer 2 frame header.
	The "flexible-encapsulation" YANG module has the following structure:		The "flexible-encapsulation" YANG module has the following structure:
	module: ietf-flexible-encapsulation		module: ietf-flexible-encapsulation
	augment /if:interfaces/if:interface/if-cmn:encapsulation/		augment /if:interfaces/if:interface/if-cmn:encapsulation/
	if-cmn:encaps-type:		if-cmn:encaps-type:
	+--:(flexible)		+--:(flexible)
	+--rw flexible		+--rw flexible
	+--rw match		+--rw match
	| +--rw (match-type)		| +--rw (match-type)
	| +--:(default)		| +--:(default)
	| | +--rw default? empty		| | +--rw default? empty
	| +--:(untagged)		| +--:(untagged)
	| | +--rw untagged? empty		| | +--rw untagged? empty
	| +--:(dot1q-priority-tagged)		| +--:(dot1q-priority-tagged)
	| | +--rw dot1q-priority-tagged		| | +--rw dot1q-priority-tagged
	| | +--rw tag-type? dot1q-types:dot1q-tag-type		| | +--rw tag-type dot1q-types:dot1q-tag-type
	| +--:(dot1q-vlan-tagged)		| +--:(dot1q-vlan-tagged)
	| +--rw dot1q-vlan-tagged		| +--rw dot1q-vlan-tagged
	| +--rw outer-tag!		| +--rw outer-tag
	| | +--rw tag-type dot1q-tag-type		| | +--rw tag-type dot1q-tag-type
	| | +--rw vlan-id union		| | +--rw vlan-id union
	| +--rw second-tag!		| +--rw second-tag!
	| | +--rw tag-type dot1q-tag-type		| | +--rw tag-type dot1q-tag-type
	| | +--rw vlan-id union		| | +--rw vlan-id union
	| +--rw match-exact-tags? empty		| +--rw match-exact-tags? empty
	+--rw rewrite {flexible-rewrites}?		+--rw rewrite {flexible-rewrites}?
	| +--rw (direction)?		| +--rw (direction)?
	| +--:(symmetrical)		| +--:(symmetrical)
	| | +--rw symmetrical		| | +--rw symmetrical
	| | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?		| | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
	| | +--rw pop-tags? uint8		| | +--rw pop-tags? uint8
	| | +--rw push-tags		| | +--rw push-tags!
	| | +--rw outer-tag!		| | +--rw outer-tag
	| | | +--rw tag-type dot1q-tag-type		| | | +--rw tag-type dot1q-tag-type
	| | | +--rw vlan-id ieee:vlanid		| | | +--rw vlan-id vlanid
	| | +--rw second-tag!		| | +--rw second-tag!
	| | +--rw tag-type dot1q-tag-type		| | +--rw tag-type dot1q-tag-type
	| | +--rw vlan-id ieee:vlanid		| | +--rw vlan-id vlanid
	| +--:(asymmetrical) {asymmetric-rewrites}?		| +--:(asymmetrical) {asymmetric-rewrites}?
	| +--rw ingress		| +--rw ingress
	| | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?		| | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
	| | +--rw pop-tags? uint8		| | +--rw pop-tags? uint8
	| | +--rw push-tags		| | +--rw push-tags!
	| | +--rw outer-tag!		| | +--rw outer-tag
	| | | +--rw tag-type dot1q-tag-type		| | | +--rw tag-type dot1q-tag-type
	| | | +--rw vlan-id ieee:vlanid		| | | +--rw vlan-id vlanid
	| | +--rw second-tag!		| | +--rw second-tag!
	| | +--rw tag-type dot1q-tag-type		| | +--rw tag-type dot1q-tag-type
	| | +--rw vlan-id ieee:vlanid		| | +--rw vlan-id vlanid
	| +--rw egress		| +--rw egress
	| +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?		| +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
	| +--rw pop-tags? uint8		| +--rw pop-tags? uint8
	| +--rw push-tags		| +--rw push-tags!
	| +--rw outer-tag!		| +--rw outer-tag
	| | +--rw tag-type dot1q-tag-type		| | +--rw tag-type dot1q-tag-type
	| | +--rw vlan-id ieee:vlanid		| | +--rw vlan-id vlanid
	| +--rw second-tag!		| +--rw second-tag!
	| +--rw tag-type dot1q-tag-type		| +--rw tag-type dot1q-tag-type
	| +--rw vlan-id ieee:vlanid		| +--rw vlan-id vlanid
	+--rw local-traffic-default-encaps!		+--rw local-traffic-default-encaps!
	+--rw outer-tag!		+--rw outer-tag
	| +--rw tag-type dot1q-tag-type		| +--rw tag-type dot1q-tag-type
	| +--rw vlan-id ieee:vlanid		| +--rw vlan-id vlanid
	+--rw second-tag!		+--rw second-tag!
	+--rw tag-type dot1q-tag-type		+--rw tag-type dot1q-tag-type
	+--rw vlan-id ieee:vlanid		+--rw vlan-id vlanid
	5. L3 Interface VLAN YANG Module		5. L3 Interface VLAN YANG Module
	This YANG module augments the encapsultion container defined in		This YANG module augments the encapsultion container defined in
	Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].		Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].
	<CODE BEGINS> file "ietf-if-l3-vlan@2017-10-30.yang"		<CODE BEGINS> file "ietf-if-l3-vlan@2019-03-05.yang"
	module ietf-if-l3-vlan {		module ietf-if-l3-vlan {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan";		namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan";
	prefix if-l3-vlan;		prefix if-l3-vlan;
	import ietf-interfaces {		import ietf-interfaces {
	prefix if;		prefix if;
	}		}
	skipping to change at page 8, line 36 ¶		skipping to change at page 7, line 48 ¶
	organization		organization
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <http://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		WG Chair: Lou Berger
	<mailto:lberger@labn.net>		<mailto:lberger@labn.net>
			WG Chair: Joel Jaeggli
			<mailto:joelja@gmail.com>
	WG Chair: Kent Watsen		WG Chair: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Editor: Robert Wilton		Editor: Robert Wilton
	<mailto:rwilton@cisco.com>";		<mailto:rwilton@cisco.com>";
	description		description
	"This YANG module models L3 VLAN sub-interfaces";		"This YANG module models L3 VLAN sub-interfaces";
	revision 2017-10-30 {		revision 2019-03-05 {
	description "Latest draft revision";		description "Latest draft revision";
	reference		reference
	"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-03";		"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-05";
	}		}
	/*		/*
	* Add support for the 802.1Q VLAN encapsulation syntax on layer 3		* Add support for the 802.1Q VLAN encapsulation syntax on layer 3
	* terminated VLAN sub-interfaces.		* terminated VLAN sub-interfaces.
	*/		*/
	augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +		augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
	"if-cmn:encaps-type" {		"if-cmn:encaps-type" {
	when		when
	"derived-from-or-self(../if:type,		"derived-from-or-self(../if:type,
	'ianaift:ethernetCsmacd') or		'ianaift:ethernetCsmacd') or
	derived-from-or-self(../if:type,		derived-from-or-self(../if:type,
	skipping to change at page 9, line 27 ¶		skipping to change at page 8, line 44 ¶
	description		description
	"Applies only to Ethernet-like interfaces and		"Applies only to Ethernet-like interfaces and
	sub-interfaces";		sub-interfaces";
	}		}
	description		description
	"Augment the generic interface encapsulation with an		"Augment the generic interface encapsulation with an
	basic 802.1Q VLAN encapsulation for sub-interfaces.";		basic 802.1Q VLAN encapsulation for sub-interfaces.";
	/*		/*
	* Matches a single VLAN Id, or pair of VLAN Ids to classify		* Matches a single VLAN Id, or a pair of VLAN Ids to classify
	* traffic into an L3 service.		* traffic into an L3 service.
	*/		*/
	case dot1q-vlan {		case dot1q-vlan {
	container dot1q-vlan {		container dot1q-vlan {
	must		must
	'count(../../if-cmn:forwarding-mode) = 0 or ' +		'count(../../if-cmn:forwarding-mode) = 0 or ' +
	'derived-from-or-self(../../if-cmn:forwarding-mode,' +		'derived-from-or-self(../../if-cmn:forwarding-mode,' +
	'"if-cmn:layer-3-forwarding")' {		'"if-cmn:layer-3-forwarding")' {
	error-message		error-message
	"If the interface forwarding-mode leaf is set then it		"If the interface forwarding-mode leaf is set then it
	must be set to an identity that derives from		must be set to an identity that derives from
	layer-3-forwarding";		layer-3-forwarding";
	description		description
	"The forwarding-mode leaf on an interface can		"The forwarding-mode leaf on an interface can
	optionally be used to enforce consistency of		optionally be used to enforce consistency of
	configuration";		configuration";
	}		}
	skipping to change at page 9, line 50 ¶		skipping to change at page 9, line 19 ¶
	description		description
	"The forwarding-mode leaf on an interface can		"The forwarding-mode leaf on an interface can
	optionally be used to enforce consistency of		optionally be used to enforce consistency of
	configuration";		configuration";
	}		}
	description		description
	"Match VLAN tagged frames with specific VLAN Ids";		"Match VLAN tagged frames with specific VLAN Ids";
	container outer-tag {		container outer-tag {
	presence "The outermost VLAN tag exists";		must
			'tag-type = "dot1q-types:s-vlan" or ' +
			'tag-type = "dot1q-types:c-vlan"' {
			error-message
			"Only C-VLAN and S-VLAN tags can be matched";
			description
			"For IEEE 802.1Q interoperability, only C-VLAN and
			S-VLAN tags can be matched";
			}
	description		description
	"Classifies traffic using the outermost VLAN tag on the		"Classifies traffic using the outermost VLAN tag on the
	frame.";		frame.";
	uses dot1q-types:dot1q-tag-classifier-grouping;		uses dot1q-types:dot1q-tag-classifier-grouping;
	}		}
	container second-tag {		container second-tag {
	must		must
	'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +		'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +
	skipping to change at page 10, line 28 ¶		skipping to change at page 10, line 7 ¶
	specified and of S-VLAN type and the second outermost		specified and of S-VLAN type and the second outermost
	tag must be of C-VLAN tag type";		tag must be of C-VLAN tag type";
	description		description
	"For IEEE 802.1Q interoperability, when matching two		"For IEEE 802.1Q interoperability, when matching two
	tags, it is required that the outermost tag exists and		tags, it is required that the outermost tag exists and
	is an S-VLAN, and the second outermost tag is a		is an S-VLAN, and the second outermost tag is a
	C-VLAN";		C-VLAN";
	}		}
	presence "The second outermost VLAN tag exists";		presence "Also classify on the second outermost VLAN tag";
	description		description
	"Classifies traffic using the second outermost VLAN tag		"Classifies traffic using the second outermost VLAN tag
	on the frame.";		on the frame.";
	uses dot1q-types:dot1q-tag-classifier-grouping;		uses dot1q-types:dot1q-tag-classifier-grouping;
	}		}
	}		}
	}		}
	}		}
	skipping to change at page 11, line 5 ¶		skipping to change at page 10, line 29 ¶
	<CODE ENDS>		<CODE ENDS>
	6. Flexible Encapsulation YANG Module		6. Flexible Encapsulation YANG Module
	This YANG module augments the encapsultion container defined in		This YANG module augments the encapsultion container defined in
	Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].		Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].
	This YANG module also augments the interface container defined in		This YANG module also augments the interface container defined in
	[RFC8343].		[RFC8343].
	<CODE BEGINS> file "ietf-flexible-encapsulation@2017-10-30.yang"		<CODE BEGINS> file "ietf-flexible-encapsulation@2019-03-05.yang"
	module ietf-flexible-encapsulation {		module ietf-flexible-encapsulation {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation";		"urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation";
	prefix flex;		prefix flex;
	import ietf-interfaces {		import ietf-interfaces {
	prefix if;		prefix if;
	}		}
	skipping to change at page 11, line 39 ¶		skipping to change at page 11, line 17 ¶
	organization		organization
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <http://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		WG Chair: Lou Berger
	<mailto:lberger@labn.net>		<mailto:lberger@labn.net>
			WG Chair: Joel Jaeggli
			<mailto:joelja@gmail.com>
	WG Chair: Kent Watsen		WG Chair: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Editor: Robert Wilton		Editor: Robert Wilton
	<mailto:rwilton@cisco.com>";		<mailto:rwilton@cisco.com>";
	description		description
	"This YANG module describes interface configuration for flexible		"This YANG module describes interface configuration for flexible
	VLAN matches and rewrites.";		VLAN matches and rewrites.";
	revision 2017-10-30 {		revision 2019-03-05 {
	description "Latest draft revision";		description "Latest draft revision";
	reference		reference
	"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-03";		"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-05";
	}		}
	feature flexible-rewrites {		feature flexible-rewrites {
	description		description
	"This feature indicates whether the network element supports		"This feature indicates whether the network element supports
	specifying flexible rewrite operations";		specifying flexible rewrite operations";
	}		}
	feature asymmetric-rewrites {		feature asymmetric-rewrites {
	description		description
	skipping to change at page 13, line 28 ¶		skipping to change at page 13, line 10 ¶
	} // case untagged		} // case untagged
	case dot1q-priority-tagged {		case dot1q-priority-tagged {
	description		description
	"Match 802.1Q priority tagged Ethernet frames only";		"Match 802.1Q priority tagged Ethernet frames only";
	container dot1q-priority-tagged {		container dot1q-priority-tagged {
	description "802.1Q priority tag match";		description "802.1Q priority tag match";
	leaf tag-type {		leaf tag-type {
	type dot1q-types:dot1q-tag-type;		type dot1q-types:dot1q-tag-type;
			mandatory true;
	description "The 802.1Q tag type of matched priority		description "The 802.1Q tag type of matched priority
	tagged packets";		tagged packets";
	}		}
	}		}
	}		}
	case dot1q-vlan-tagged {		case dot1q-vlan-tagged {
	container dot1q-vlan-tagged {		container dot1q-vlan-tagged {
	description "Matches VLAN tagged frames";		description "Matches VLAN tagged frames";
	container outer-tag {		container outer-tag {
	presence "The outermost VLAN tag exists";		must
			'tag-type = "dot1q-types:s-vlan" or ' +
			'tag-type = "dot1q-types:c-vlan"' {
			error-message
			"Only C-VLAN and S-VLAN tags can be matched";
			description
			"For IEEE 802.1Q interoperability, only C-VLAN and
			S-VLAN tags can be matched";
			}
	description		description
	"Classifies traffic using the outermost VLAN tag on the		"Classifies traffic using the outermost VLAN tag on the
	frame.";		frame.";
	uses		uses
	'dot1q-types:'+		'dot1q-types:'+
	'dot1q-tag-ranges-or-any-classifier-grouping';		'dot1q-tag-ranges-or-any-classifier-grouping';
	}		}
	skipping to change at page 14, line 19 ¶		skipping to change at page 14, line 12 ¶
	specified and of S-VLAN type and the second		specified and of S-VLAN type and the second
	outermost tag must be of C-VLAN tag type";		outermost tag must be of C-VLAN tag type";
	description		description
	"For IEEE 802.1Q interoperability, when matching two		"For IEEE 802.1Q interoperability, when matching two
	tags, it is required that the outermost tag exists		tags, it is required that the outermost tag exists
	and is an S-VLAN, and the second outermost tag is a		and is an S-VLAN, and the second outermost tag is a
	C-VLAN";		C-VLAN";
	}		}
	presence "The second outermost VLAN tag exists";		presence "Also classify on the second VLAN tag";
	description		description
	"Classifies traffic using the second outermost VLAN tag		"Classifies traffic using the second outermost VLAN tag
	on the frame.";		on the frame.";
	uses		uses
	'dot1q-types:'+		'dot1q-types:'+
	'dot1q-tag-ranges-or-any-classifier-grouping';		'dot1q-tag-ranges-or-any-classifier-grouping';
	}		}
	skipping to change at page 15, line 12 ¶		skipping to change at page 15, line 4 ¶
	description "Flexible rewrite";		description "Flexible rewrite";
	leaf pop-tags {		leaf pop-tags {
	type uint8 {		type uint8 {
	range 1..2;		range 1..2;
	}		}
	description "The number of tags to pop (or translate if used in		description "The number of tags to pop (or translate if used in
	conjunction with push-tags)";		conjunction with push-tags)";
	}		}
	container push-tags {		container push-tags {
			presence
			"802.1Q tags are pushed or translated";
	description "The 802.1Q tags to push (or translate if used in		description "The 802.1Q tags to push (or translate if used in
	conjunction with pop-tags)";		conjunction with pop-tags)";
	container outer-tag {		container outer-tag {
	presence		must
	"Indicates existence of the outermost VLAN tag to		'tag-type = "dot1q-types:s-vlan" or ' +
	push/rewrite";		'tag-type = "dot1q-types:c-vlan"' {
			error-message
			"Only C-VLAN and S-VLAN tags can be pushed";
			description
			"For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN
			tags can be pushed";
			}
	description		description
	"The outermost VLAN tag to push onto the frame.";		"The outermost VLAN tag to push onto the frame.";
	uses dot1q-types:dot1q-tag-classifier-grouping;		uses dot1q-types:dot1q-tag-classifier-grouping;
	}		}
	container second-tag {		container second-tag {
	must		must
	'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +		'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +
	'tag-type = "dot1q-types:c-vlan"' {		'tag-type = "dot1q-types:c-vlan"' {
	error-message		error-message
	"When pushing/rewriting two tags, the outermost tag must be		"When pushing/rewriting two tags, the outermost tag must
	specified and of S-VLAN type and the second outermost tag		be specified and of S-VLAN type and the second outermost
	must be of C-VLAN tag type";		tag must be of C-VLAN tag type";
	description		description
	"For IEEE 802.1Q interoperability, when pushing two tags,		"For IEEE 802.1Q interoperability, when pushing two tags,
	it is required that the outermost tag exists and is an		it is required that the outermost tag exists and is an
	S-VLAN, and the second outermost tag is a C-VLAN";		S-VLAN, and the second outermost tag is a C-VLAN";
	}		}
	presence		presence
	"Indicates existence of a second outermost VLAN tag to		"In addition to the first tag, also push/rewrite a second
	push/rewrite.";		VLAN tag.";
	description		description
	"The second outermost VLAN tag to push onto the frame.";		"The second outermost VLAN tag to push onto the frame.";
	uses dot1q-types:dot1q-tag-classifier-grouping;		uses dot1q-types:dot1q-tag-classifier-grouping;
	}		}
	}
			}
	}		}
	/*		/*
	* Grouping for all flexible rewrites of fields in the L2 header.		* Grouping for all flexible rewrites of fields in the L2 header.
	*		*
	* This currently only includes flexible tag rewrites, but is		* This currently only includes flexible tag rewrites, but is
	* designed to be extensible to cover rewrites of other fields in		* designed to be extensible to cover rewrites of other fields in
	* the L2 header if required.		* the L2 header if required.
	*/		*/
	grouping flexible-rewrite {		grouping flexible-rewrite {
	skipping to change at page 18, line 31 ¶		skipping to change at page 18, line 32 ¶
	*/		*/
	container local-traffic-default-encaps {		container local-traffic-default-encaps {
	presence		presence
	"A local traffic default encapsulation has been		"A local traffic default encapsulation has been
	specified";		specified";
	description		description
	"The 802.1Q VLAN tags to use by default for locally		"The 802.1Q VLAN tags to use by default for locally
	sourced traffic";		sourced traffic";
	container outer-tag {		container outer-tag {
	presence		must
	"Indicates existence of the outermost VLAN tag";		'tag-type = "dot1q-types:s-vlan" or ' +
			'tag-type = "dot1q-types:c-vlan"' {
			error-message
			"Only C-VLAN and S-VLAN tags can be matched";
			description
			"For IEEE 802.1Q interoperability, only C-VLAN and
			S-VLAN tags can be matched";
			}
	description		description
	"The outermost VLAN tag for locally sourced traffic";		"The outermost VLAN tag for locally sourced traffic";
	uses dot1q-types:dot1q-tag-classifier-grouping;		uses dot1q-types:dot1q-tag-classifier-grouping;
	}		}
	container second-tag {		container second-tag {
	must		must
	'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +		'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +
	skipping to change at page 23, line 43 ¶		skipping to change at page 24, line 7 ¶
	Parsons, and Dan Romascanu for their help progressing this draft.		Parsons, and Dan Romascanu for their help progressing this draft.
	The authors would also like to thank Alex Campbell, Eric Gray, Giles		The authors would also like to thank Alex Campbell, Eric Gray, Giles
	Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton,		Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton,
	John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir		John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir
	Vassilev, and members of the IEEE 802.1 WG for their helpful reviews		Vassilev, and members of the IEEE 802.1 WG for their helpful reviews
	and feedback on this draft.		and feedback on this draft.
	9. ChangeLog		9. ChangeLog
	9.1. WG version -04		XXX, RFC Editor, please delete this change log before publication.
			9.1. WG version -05
			o Incorporate feedback from IEEE 802.1 WG, John Messenger in
			particular.
			o Adding must contraints to ensure outer tags are always matched to
			C-VLAN and S-VLAN tags.
			o Fixed bug where second tag could be matched without outer tag, and
			where tags must not be specified.
			9.2. WG version -04
	o Added examples		o Added examples
	9.2. WG version -03		9.3. WG version -03
	o Fix namespace bug in XPath identity references, removed extraneous		o Fix namespace bug in XPath identity references, removed extraneous
	'dot1q-tag' containers.		'dot1q-tag' containers.
	9.3. WG version -02		9.4. WG version -02
	o Use explicit containers for outer and inner tags rather than		o Use explicit containers for outer and inner tags rather than
	lists.		lists.
	9.4. WG version -01		9.5. WG version -01
	o Tweaked the abstract.		o Tweaked the abstract.
	o Removed unnecessary feature for the L3 sub-interface module.		o Removed unnecessary feature for the L3 sub-interface module.
	o Update the 802.1Qcp type references.		o Update the 802.1Qcp type references.
	o Remove extra tag container for L3 sub-interfaces YANG.		o Remove extra tag container for L3 sub-interfaces YANG.
	9.5. Version -04		9.6. Version -04
	o IEEE 802.1 specific types have been removed from the draft. These		o IEEE 802.1 specific types have been removed from the draft. These
	are now referenced from the 802.1Qcp draft YANG modules.		are now referenced from the 802.1Qcp draft YANG modules.
	o Fixed errors in the xpath expressions.		o Fixed errors in the xpath expressions.
	9.6. Version -03		9.7. Version -03
	o Incorporates feedback received from presenting to the IEEE 802.1		o Incorporates feedback received from presenting to the IEEE 802.1
	WG.		WG.
	o Updates the modules for double tag matches/rewrites to restrict		o Updates the modules for double tag matches/rewrites to restrict
	the outer tag type to S-VLAN and inner tag type to C-VLAN.		the outer tag type to S-VLAN and inner tag type to C-VLAN.
	o Updates the introduction to indicate primary use case is for IETF		o Updates the introduction to indicate primary use case is for IETF
	forwarding protocols.		forwarding protocols.
	o Updates the objectives to make IEEE 802.1Q bridge interoperability		o Updates the objectives to make IEEE 802.1Q bridge interoperability
	a key objective.		a key objective.
	10. IANA Considerations		10. IANA Considerations
	This document defines several new YANG module and the authors		This document defines two new YANG module and the authors politely
	politely request that IANA assigns unique names to the YANG module		request that IANA assigns unique names to the YANG module files
	files contained within this draft, and also appropriate URIs in the		contained within this draft, and also appropriate URIs in the "IETF
	"IETF XML Registry".		XML Registry".
	11. Security Considerations		11. 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.
	skipping to change at page 27, line 38 ¶		skipping to change at page 28, line 12 ¶
	o second-tag/vlan-id		o second-tag/vlan-id
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-netmod-intf-ext-yang]		[I-D.ietf-netmod-intf-ext-yang]
	Wilton, R., Ball, D., tsingh@juniper.net, t., and S.		Wilton, R., Ball, D., tsingh@juniper.net, t., and S.
	Sivaraj, "Common Interface Extension YANG Data Models",		Sivaraj, "Common Interface Extension YANG Data Models",
	draft-ietf-netmod-intf-ext-yang-05 (work in progress),		draft-ietf-netmod-intf-ext-yang-07 (work in progress),
	July 2017.		March 2019.
	[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>.
	[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",		[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
	RFC 7224, DOI 10.17487/RFC7224, May 2014,		RFC 7224, DOI 10.17487/RFC7224, May 2014,
	<https://www.rfc-editor.org/info/rfc7224>.		<https://www.rfc-editor.org/info/rfc7224>.
	skipping to change at page 28, line 15 ¶		skipping to change at page 28, line 38 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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		12.2. Informative References
	[dot1Qcp] Holness, M., "802.1Qcp Bridges and Bridged Networks -		[dot1Qcp] Holness, M., "IEEE 802.1Qcp-2018 Bridges and Bridged
	Amendment: YANG Data Model", 2018.		Networks - Amendment: YANG Data Model", 2018.
	[I-D.ietf-bess-l2vpn-yang]		[I-D.ietf-bess-l2vpn-yang]
	Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,		Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
	and K. Tiruveedhula, "YANG Data Model for MPLS-based		and K. Tiruveedhula, "YANG Data Model for MPLS-based
	L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress),		L2VPN", draft-ietf-bess-l2vpn-yang-09 (work in progress),
	February 2018.		October 2018.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <https://www.rfc-editor.org/info/rfc2460>.		December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,		[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
	"Encapsulation Methods for Transport of Ethernet over MPLS		"Encapsulation Methods for Transport of Ethernet over MPLS
	Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,		Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
	<https://www.rfc-editor.org/info/rfc4448>.		<https://www.rfc-editor.org/info/rfc4448>.
	skipping to change at page 29, line 10 ¶		skipping to change at page 29, line 34 ¶
	[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>.
	[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
	Protocol (NETCONF) Access Control Model", RFC 6536,		Protocol (NETCONF) Access Control Model", RFC 6536,
	DOI 10.17487/RFC6536, March 2012,		DOI 10.17487/RFC6536, March 2012,
	<https://www.rfc-editor.org/info/rfc6536>.		<https://www.rfc-editor.org/info/rfc6536>.
			[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
			BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
			<https://www.rfc-editor.org/info/rfc8340>.
	Appendix A. Comparison with the IEEE 802.1Q Configuration Model		Appendix A. Comparison with the IEEE 802.1Q Configuration Model
	In addition to the sub-interface based YANG model proposed here, the		In addition to the sub-interface based YANG model proposed here, the
	IEEE 802.1Q working group is also developing a YANG model for the		IEEE 802.1Q working group has developed a YANG model for the
	configuration of 802.1Q VLANs. This raises the valid question as to		configuration of 802.1Q VLANs. This raises the valid question as to
	whether the models overlap and whether it is necessary or beneficial		whether the models overlap and whether it is necessary or beneficial
	to have two different models for superficially similar constructs.		to have two different models for superficially similar constructs.
	This section aims to answer that question by summarizing and		This section aims to answer that question by summarizing and
	comparing the two models.		comparing the two models.
	A.1. Sub-interface based configuration model overview		A.1. Sub-interface based configuration model overview
	The key features of the sub-interface based configuration model can		The key features of the sub-interface based configuration model can
	be summarized as:		be summarized as:
End of changes. 69 change blocks.
	125 lines changed or deleted		155 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/