< draft-ietf-rtgwg-lne-model-05.txt		draft-ietf-rtgwg-lne-model-06.txt >
	Network Working Group L. Berger		Network Working Group L. Berger
	Internet-Draft LabN Consulting, L.L.C.		Internet-Draft LabN Consulting, L.L.C.
	Intended status: Standards Track C. Hopps		Intended status: Standards Track C. Hopps
	Expires: June 7, 2018 Deutsche Telekom		Expires: August 10, 2018 Deutsche Telekom
	A. Lindem		A. Lindem
	Cisco Systems		Cisco Systems
	D. Bogdanovic		D. Bogdanovic
	X. Liu		X. Liu
	Jabil		Jabil
	December 4, 2017		February 6, 2018
	YANG Logical Network Elements		YANG Logical Network Elements
	draft-ietf-rtgwg-lne-model-05		draft-ietf-rtgwg-lne-model-06
	Abstract		Abstract
	This document defines a logical network element module. This module		This document defines a logical network element YANG module. This
	can be used to manage the logical resource partitioning that may be		module can be used to manage the logical resource partitioning that
	present on a network device. Examples of common industry terms for		may be present on a network device. Examples of common industry
	logical resource partitioning are Logical Systems or Logical Routers.		terms for logical resource partitioning are Logical Systems or
			Logical Routers.
	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 http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 7, 2018.		This Internet-Draft will expire on August 10, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Logical Network Elements . . . . . . . . . . . . . . . . . . 5		3. Logical Network Elements . . . . . . . . . . . . . . . . . . 5
	3.1. LNE Instantiation and Resource Assignment . . . . . . . . 6		3.1. LNE Instantiation and Resource Assignment . . . . . . . . 6
	3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 7		3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 7
	3.3. LNE Management - Host Network Device View . . . . . . . . 7		3.3. LNE Management - Host Network Device View . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Logical Network Element Model . . . . . . . . . . . . . . . . 9		6. Logical Network Element Model . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . 14
	7.2. Informative References . . . . . . . . . . . . . . . . . 14		7.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 17
	B.1. Example: Host Device Managed LNE . . . . . . . . . . . . 15		B.1. Example: Host Device Managed LNE . . . . . . . . . . . . 17
	B.1.1. Configuration Data . . . . . . . . . . . . . . . . . 19		B.1.1. Configuration Data . . . . . . . . . . . . . . . . . 22
	B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 23		B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 25
	B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 33		B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 36
	B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 36		B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 40
	B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 39		B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	This document defines a YANG [RFC6020] module to support the creation		This document defines a YANG [RFC6020] module to support the creation
	of logical network elements on a network device. A logical network		of logical network elements on a network device. A logical network
	element (LNE) is an independently managed virtual device made up of		element (LNE) is an independently managed virtual device made up of
	resources allocated to it from the host or parent network device. An		resources allocated to it from the host or parent network device. An
	LNE running on a host network device conceptually parallels a virtual		LNE running on a host network device conceptually parallels a virtual
	machine running on a host system. Using host-virtualization		machine running on a host system. Using host-virtualization
	terminology one could refer to an LNE as a "Guest", and the		terminology one could refer to an LNE as a "Guest", and the
	containing network-device as the "Host". While LNEs may be		containing network-device as the "Host". While LNEs may be
	implemented via host-virtualization technologies this is not a		implemented via host-virtualization technologies this is not a
	requirement.		requirement.
	This document also defines the necessary augmentations for allocating		This document also defines the necessary augmentations for allocating
	host resources to a given LNE. As the interface management model		host resources to a given LNE. As the interface management model
	[RFC7223] is the only a module that currently defines host resources,
	this document currently defines only a single augmentation to cover		[I-D.ietf-netmod-rfc7223bis] is the only a module that currently
	the assignment of interfaces to an LNE. Future modules that define		defines host resources, this document currently defines only a single
	support for the control of host device resources are expected to,		augmentation to cover the assignment of interfaces to an LNE. Future
	where appropriate, provide parallel support for the assignment of		modules that define support for the control of host device resources
	controlled resources to LNEs.		are expected to, where appropriate, provide parallel support for the
			assignment of controlled resources to LNEs.
	As each LNE is an independently managed device, each will have its		As each LNE is an independently managed device, each will have its
	own set of YANG modeled data that is independent of the host device		own set of YANG modeled data that is independent of the host device
	and other LNEs. For example, multiple LNEs may all have their own		and other LNEs. For example, multiple LNEs may all have their own
	"Tunnel0" interface defined which will not conflict with each other		"Tunnel0" interface defined which will not conflict with each other
	and will not exist in the host's interface model. An LNE will have		and will not exist in the host's interface model. An LNE will have
	its own management interfaces possibly including independent		its own management interfaces possibly including independent
	instances of netconf/restconf/etc servers to support configuration of		instances of netconf/restconf/etc servers to support configuration of
	their YANG models. As an example of this independence, an		their YANG models. As an example of this independence, an
	implementation may choose to completely rename assigned interfaces,		implementation may choose to completely rename assigned interfaces,
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 37 ¶
	supported, such access is accomplished through a yang-schema-mount		supported, such access is accomplished through a yang-schema-mount
	mount point [I-D.ietf-netmod-schema-mount] under which the root level		mount point [I-D.ietf-netmod-schema-mount] under which the root level
	LNE YANG models may be accessed.		LNE YANG models may be accessed.
	Examples of vendor terminology for an LNE include logical system or		Examples of vendor terminology for an LNE include logical system or
	logical router, and virtual switch, chassis, or fabric.		logical router, and virtual switch, chassis, or fabric.
	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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	Readers are expected to be familiar with terms and concepts of YANG		Readers are expected to be familiar with terms and concepts of YANG
	[RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount].		[RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount].
	This document uses the graphical representation of data models		This document uses the graphical representation of data models
	defined in [I-D.ietf-netmod-yang-tree-diagrams].		defined in [I-D.ietf-netmod-yang-tree-diagrams].
	2. Overview		2. Overview
	In this document, we consider network devices that support protocols		In this document, we consider network devices that support protocols
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 36 ¶
	| | | | | | | | | | | | | |		| | | | | | | | | | | | | |
	''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''		''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
	| | | | | | | | | | | |		| | | | | | | | | | | |
	Interfaces Interfaces		Interfaces Interfaces
	Figure 1: Module Element Relationships		Figure 1: Module Element Relationships
	A model for LNEs is described in Section 3 and the model for NIs is		A model for LNEs is described in Section 3 and the model for NIs is
	covered in [I-D.ietf-rtgwg-ni-model].		covered in [I-D.ietf-rtgwg-ni-model].
	The interface management model [RFC7223] is an existing model that is		The interface management model [I-D.ietf-netmod-rfc7223bis] is an
	impacted by the definition of LNEs and network instances. This		existing model that is impacted by the definition of LNEs and network
	document and [I-D.ietf-rtgwg-ni-model] define augmentations to the		instances. This document and [I-D.ietf-rtgwg-ni-model] define
	interface module to support LNEs and NIs. Similar elements, although		augmentations to the interface module to support LNEs and NIs.
	perhaps only for LNEs, may also need to be included as part of the		Similar elements, although perhaps only for LNEs, may also need to be
	definition of the future hardware and QoS modules.		included as part of the definition of the future hardware and QoS
			modules.
	Interfaces are a crucial part of any network device's configuration		Interfaces are a crucial part of any network device's configuration
	and operational state. They generally include a combination of raw		and operational state. They generally include a combination of raw
	physical interfaces, link-layer interfaces, addressing configuration,		physical interfaces, link-layer interfaces, addressing configuration,
	and logical interfaces that may not be tied to any physical		and logical interfaces that may not be tied to any physical
	interface. Several system services, and layer 2 and layer 3		interface. Several system services, and layer 2 and layer 3
	protocols may also associate configuration or operational state data		protocols may also associate configuration or operational state data
	with different types of interfaces (these relationships are not shown		with different types of interfaces (these relationships are not shown
	for simplicity). The interface management model is defined by		for simplicity). The interface management model is defined by
	[RFC7223]. The logical-network-element module augments existing		[I-D.ietf-netmod-rfc7223bis]. The logical-network-element module
	interface management model by adding an identifier which is used on		augments existing interface management model by adding an identifier
	physical interface types to identify an associated LNE.		which is used on physical interface types to identify an associated
			LNE.
	The interface related augmentation is as follows:		The interface related augmentation is as follows:
	module: ietf-logical-network-element		module: ietf-logical-network-element
	augment /if:interfaces/if:interface:		augment /if:interfaces/if:interface:
	+--rw bind-lne-name? ->		+--rw bind-lne-name? ->
	/logical-network-elements/logical-network-element/name		/logical-network-elements/logical-network-element/name
	The interface model defined in [RFC7223] is structured to include all		The interface model defined in [I-D.ietf-netmod-rfc7223bis] is
	interfaces in a flat list, without regard to logical assignment of		structured to include all interfaces in a flat list, without regard
	resources supported on the device. The bind-lne-name and leaf		to logical assignment of resources supported on the device. The
	provides the association between an interface and its associated LNE.		bind-lne-name and leaf provides the association between an interface
	Note that as currently defined, to assign an interface to both an LNE		and its associated LNE. Note that as currently defined, to assign an
	and NI, the interface would first be assigned to the LNE and then		interface to both an LNE and NI, the interface would first be
	within that LNE's interface module, the LNE's representation of that		assigned to the LNE and then within that LNE's interface module, the
	interface would be assigned to an NI using the mechanisms defined in		LNE's representation of that interface would be assigned to an NI
	[I-D.ietf-rtgwg-ni-model].		using the mechanisms defined in [I-D.ietf-rtgwg-ni-model].
	3. Logical Network Elements		3. Logical Network Elements
	Logical network elements support the ability of some devices to		Logical network elements support the ability of some devices to
	partition resources into independent logical routers and/or switches.		partition resources into independent logical routers and/or switches.
	Device support for multiple logical network elements is		Device support for multiple logical network elements is
	implementation specific. Systems without such capabilities need not		implementation specific. Systems without such capabilities need not
	include support for the logical-network-element module. In physical		include support for the logical-network-element module. In physical
	devices, some hardware features are shared across partitions, but		devices, some hardware features are shared across partitions, but
	control plane (e.g., routing) protocol instances, tables, and		control plane (e.g., routing) protocol instances, tables, and
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	+--ro error-info? string		+--ro error-info? string
	'name' identifies the logical network element. 'managed' indicates		'name' identifies the logical network element. 'managed' indicates
	if the server providing the host network device will provide the		if the server providing the host network device will provide the
	client LNE information via the 'root' structure. The root of an		client LNE information via the 'root' structure. The root of an
	LNE's specific data is the schema mount point 'root'. bind-lne-name		LNE's specific data is the schema mount point 'root'. bind-lne-name
	is used to associated an interface with an LNE and bind-lne-name-		is used to associated an interface with an LNE and bind-lne-name-
	failed is used in certain failure cases.		failed is used in certain failure cases.
	An LNE root MUST contain at least the YANG library [RFC7895] and		An LNE root MUST contain at least the YANG library [RFC7895] and
	Interfaces [RFC7223] modules.		Interfaces [I-D.ietf-netmod-rfc7223bis] modules.
	3.1. LNE Instantiation and Resource Assignment		3.1. LNE Instantiation and Resource Assignment
	Logical network elements may be controlled by clients using existing		Logical network elements may be controlled by clients using existing
	list operations. When list entries are created, a new LNE is		list operations. When list entries are created, a new LNE is
	instantiated. The models mounted under an LNE root are expected to		instantiated. The models mounted under an LNE root are expected to
	be dependent on the server implementation. When a list entry is		be dependent on the server implementation. When a list entry is
	deleted, an existing LNE is destroyed. For more information, see		deleted, an existing LNE is destroyed. For more information, see
	[RFC7950] Section 7.8.6.		[RFC7950] Section 7.8.6.
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	failed. It is possible for the assignment to fail while processing		failed. It is possible for the assignment to fail while processing
	the set, or after asynchronous processing. Error notification in the		the set, or after asynchronous processing. Error notification in the
	latter case is supported via a notification.		latter case is supported via a notification.
	On a successful interface assignment to an LNE, an implementation		On a successful interface assignment to an LNE, an implementation
	MUST also make the resource available to the LNE by providing a		MUST also make the resource available to the LNE by providing a
	system created interface to the LNE. The name of the system created		system created interface to the LNE. The name of the system created
	interface is a local matter and may be identical or completely		interface is a local matter and may be identical or completely
	different, and mapped from and to, the name used in the context of		different, and mapped from and to, the name used in the context of
	the host device. The system created interface SHOULD be exposed via		the host device. The system created interface SHOULD be exposed via
	the LNE-specific instance of the interfaces module [RFC7223].		the LNE-specific instance of the interfaces module
			[I-D.ietf-netmod-rfc7223bis].
	3.2. LNE Management - LNE View		3.2. LNE Management - LNE View
	Each LNE instance is expected to support management functions from		Each LNE instance is expected to support management functions from
	within the context of the LNE root, via a server that provides		within the context of the LNE root, via a server that provides
	information with the LNE's root exposed as device root. Management		information with the LNE's root exposed as device root. Management
	functions operating within the context of an LNE are accessed through		functions operating within the context of an LNE are accessed through
	the LNE's standard management interfaces, e.g., NETCONF and SNMP.		the LNE's standard management interfaces, e.g., NETCONF and SNMP.
	Initial configuration, much like the initial configuration of the		Initial configuration, much like the initial configuration of the
	host device, is a local implementation matter.		host device, is a local implementation matter.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	Beyond the two modules that will always be present for an LNE, as an		Beyond the two modules that will always be present for an LNE, as an
	LNE is a network device itself, all modules that may be present at		LNE is a network device itself, all modules that may be present at
	the top level network device MAY also be present for the LNE. The		the top level network device MAY also be present for the LNE. The
	list of available modules is expected to be implementation dependent.		list of available modules is expected to be implementation dependent.
	As is the method used by an implementation to support LNEs.		As is the method used by an implementation to support LNEs.
	Appendix B provide example uses of LNEs.		Appendix B provide example uses of LNEs.
	4. Security Considerations		4. Security Considerations
			The YANG modules specified in this document define a schema for data
			that is designed to be accessed via network management protocols such
			as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
			is the secure transport layer, and the mandatory-to-implement secure
			transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
			is HTTPS, and the mandatory-to-implement secure transport is TLS
			[RFC5246].
			The NETCONF access control model [RFC6536] provides the means to
			restrict access for particular NETCONF or RESTCONF users to a
			preconfigured subset of all available NETCONF or RESTCONF protocol
			operations and content.
	LNE information represents device and network configuration		LNE information represents device and network configuration
	information. As such, the security of this information is important,		information. As such, the security of this information is important,
	but it is fundamentally no different than any other interface or		but it is fundamentally no different than any other interface or
	device configuration information that has already been covered in		device configuration information that has already been covered in
	other documents such as [RFC7223], [RFC7317] and [RFC8022].		other documents such as [I-D.ietf-netmod-rfc7223bis], [RFC7317] and
			[I-D.ietf-netmod-rfc8022bis].
	The vulnerable "config true" parameters and subtrees are the		The vulnerable "config true" parameters and subtrees are the
	following:		following:
	/logical-network-elements/logical-network-element: This list		/logical-network-elements/logical-network-element: This list
	specifies the logical network element and the related logical		specifies the logical network element and the related logical
	device configuration.		device configuration.
	/logical-network-elements/logical-network-element/managed: While		/logical-network-elements/logical-network-element/managed: While
	this leaf is contained in the previous list, it is worth		this leaf is contained in the previous list, it is worth
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 15 ¶
	name: ietf-logical-network-element		name: ietf-logical-network-element
	namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element		namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element
	prefix: lne		prefix: lne
	reference: RFC XXXX		reference: RFC XXXX
	6. Logical Network Element Model		6. Logical Network Element Model
	The structure of the model defined in this document is described by		The structure of the model defined in this document is described by
	the YANG module below.		the YANG module below.
	<CODE BEGINS> file "ietf-logical-network-element@2017-12-04.yang"		<CODE BEGINS> file "ietf-logical-network-element@2018-02-06.yang"
	module ietf-logical-network-element {		module ietf-logical-network-element {
	yang-version 1.1;		yang-version 1.1;
	// namespace		// namespace
	namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element";
	prefix lne;
	// import some basic types		namespace
			"urn:ietf:params:xml:ns:yang:ietf-logical-network-element";
			prefix lne;
	import ietf-interfaces {		// import some basic types
	prefix if;
	reference "RFC 7223: A YANG Data Model for Interface Management";
	}
	import ietf-yang-schema-mount {
	prefix yangmnt;
	reference "draft-ietf-netmod-schema-mount: YANG Schema Mount";
	// RFC Ed.: Please replace this draft name with the corresponding
	// RFC number
	}
	organization		import ietf-interfaces {
	"IETF Routing Area (rtgwg) Working Group";		prefix if;
	contact		reference "draft-ietf-netmod-rfc7223bis:
	"WG Web: <http://tools.ietf.org/wg/rtgwg/>		A YANG Data Model for Interface Management";
	WG List: <mailto:rtgwg@ietf.org>		}
			import ietf-yang-schema-mount {
			prefix yangmnt;
			reference "draft-ietf-netmod-schema-mount: YANG Schema Mount";
			// RFC Ed.: Please replace this draft name with the corresponding
			// RFC number
			}
	Author: Lou Berger		organization
	<mailto:lberger@labn.net>		"IETF Routing Area (rtgwg) Working Group";
	Author: Christan Hopps		contact
	<mailto:chopps@chopps.org>		"WG Web: <http://tools.ietf.org/wg/rtgwg/>
	Author: Acee Lindem		WG List: <mailto:rtgwg@ietf.org>
	<mailto:acee@cisco.com>
	Author: Dean Bogdanovic
	<mailto:ivandean@gmail.com>";
	description
	"This module is used to support multiple logical network
	elements on a single physical or virtual system.
	Copyright (c) 2017 IETF Trust and the persons		Author: Lou Berger
	identified as authors of the code. All rights reserved.		<mailto:lberger@labn.net>
			Author: Christan Hopps
			<mailto:chopps@chopps.org>
			Author: Acee Lindem
			<mailto:acee@cisco.com>
			Author: Dean Bogdanovic
			<mailto:ivandean@gmail.com>";
	Redistribution and use in source and binary forms, with or		description
	without modification, is permitted pursuant to, and subject		"This module is used to support multiple logical network
	to the license terms contained in, the Simplified BSD License		elements on a single physical or virtual system.
	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 RFC XXXX; see		Copyright (c) 2017 IETF Trust and the persons
	the RFC itself for full legal notices.";		identified as authors of the code. All rights reserved.
	// RFC Ed.: replace XXXX with actual RFC number and remove		Redistribution and use in source and binary forms, with or
	// this note		without modification, is permitted pursuant to, and subject
	// RFC Ed.: please update TBD		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).
	revision 2017-12-04 {		This version of this YANG module is part of RFC XXXX; see
	description		the RFC itself for full legal notices.";
	"Initial revision.";
	reference "RFC TBD";
	}
	// top level device definition statements		// RFC Ed.: replace XXXX with actual RFC number and remove
			// this note
			// RFC Ed.: please update TBD
	container logical-network-elements {		revision 2018-02-06 {
	description
	"Allows a network device to support multiple logical
	network element (device) instances.";
	list logical-network-element {
	key "name";
	description		description
	"List of logical network elements.";		"Initial revision.";
	leaf name {		reference "RFC XXXX";
	type string;		}
	description
	"Device-wide unique identifier for the		// top level device definition statements
	logical network element.";
	}		container logical-network-elements {
	leaf managed {		description
	type boolean;		"Allows a network device to support multiple logical
	default "true";		network element (device) instances.";
	description		list logical-network-element {
	"True if the host can access LNE information		key "name";
	using the root mount point. This value
	my not be modifiable in all implementations.";
	}
	leaf description {
	type string;
	description
	"Description of the logical network element.";
	}
	container "root" {
	description		description
	"Container for mount point.";		"List of logical network elements.";
	yangmnt:mount-point "root" {		leaf name {
			type string;
	description		description
	"Root for models supported per logical		"Device-wide unique identifier for the
	network element. This mount point may or may not		logical network element.";
	be inline based on the server implementation. It		}
	SHALL always contain a YANG library and interfaces		leaf managed {
	instance.		type boolean;
			default "true";
			description
			"True if the host can access LNE information
			using the root mount point. This value
			my not be modifiable in all implementations.";
			}
			leaf description {
			type string;
			description
			"Description of the logical network element.";
			}
			container "root" {
			description
			"Container for mount point.";
			yangmnt:mount-point "root" {
			description
			"Root for models supported per logical
			network element. This mount point may or may not
			be inline based on the server implementation. It
			SHALL always contain a YANG library and interfaces
			instance.
	When the associated 'managed' leaf is 'false' any		When the associated 'managed' leaf is 'false' any
	operation that attempts to access information below		operation that attempts to access information below
	the root SHALL fail with an error-tag of		the root SHALL fail with an error-tag of
	'access-denied' and an error-app-tag of		'access-denied' and an error-app-tag of
	'lne-not-managed'.";		'lne-not-managed'.";
			}
	}		}
	}		}
	}		}
	}
	// augment statements		// augment statements
	augment "/if:interfaces/if:interface" {		augment "/if:interfaces/if:interface" {
	description		description
	"Add a node for the identification of the logical network		"Add a node for the identification of the logical network
	element associated with an interface. Applies to interfaces		element associated with an interface. Applies to
	that can be assigned on a per logical network element basis.		interfaces that can be assigned on a per logical network
			element basis.
	Note that a standard error will be returned if the		Note that a standard error will be returned if the
	identified leafref isn't present. If an interfaces cannot		identified leafref isn't present. If an interfaces
	be assigned for any other reason, the operation SHALL fail		cannot be assigned for any other reason, the operation
	with an error-tag of 'operation-failed' and an error-app-tag		SHALL fail with an error-tag of 'operation-failed' and an
	of 'lne-assignment-failed'. A meaningful error-info that		error-app-tag of 'lne-assignment-failed'. A meaningful
	indicates the source of the assignment failure SHOULD also		error-info that indicates the source of the assignment
	be provided.";		failure SHOULD also be provided.";
	leaf bind-lne-name {		leaf bind-lne-name {
	type leafref {		type leafref {
	path "/logical-network-elements/logical-network-element/name";		path
			"/logical-network-elements/logical-network-element/name";
			}
			description
			"Logical network element ID to which interface is bound.";
	}		}
	description
	"Logical network element ID to which interface is bound.";
	}		}
	}
	// notification statements		// notification statements
	notification bind-lne-name-failed {		notification bind-lne-name-failed {
	description
	"Indicates an error in the association of an interface to an
	LNE. Only generated after success is initially returned when
	bind-lne-name is set.";
	leaf name {
	type leafref {
	path "/if:interfaces/if:interface/if:name";
	}
	mandatory true;
	description		description
	"Contains the interface name associated with the		"Indicates an error in the association of an interface to an
	failure.";		LNE. Only generated after success is initially returned when
	}		bind-lne-name is set.";
	leaf bind-lne-name {		leaf name {
	type leafref {		type leafref {
	path "/if:interfaces/if:interface/lne:bind-lne-name";		path "/if:interfaces/if:interface/if:name";
			}
			mandatory true;
			description
			"Contains the interface name associated with the
			failure.";
			}
			leaf bind-lne-name {
			type leafref {
			path "/if:interfaces/if:interface/lne:bind-lne-name";
			}
			mandatory true;
			description
			"Contains the bind-lne-name associated with the
			failure.";
			}
			leaf error-info {
			type string;
			description
			"Optionally, indicates the source of the assignment
			failure.";
	}		}
	mandatory true;
	description
	"Contains the bind-lne-name associated with the
	failure.";
	}
	leaf error-info {
	type string;
	description
	"Optionally, indicates the source of the assignment
	failure.";
	}		}
	}		}
	}		<CODE ENDS>
	<CODE ENDS>
	7. References		7. References
	7.1. Normative References		7.1. Normative References
			[I-D.ietf-netmod-rfc7223bis]
			Bjorklund, M., "A YANG Data Model for Interface
			Management", draft-ietf-netmod-rfc7223bis-03 (work in
			progress), January 2018.
	[I-D.ietf-netmod-schema-mount]		[I-D.ietf-netmod-schema-mount]
	Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-		Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
	ietf-netmod-schema-mount-08 (work in progress), October		ietf-netmod-schema-mount-08 (work in progress), October
	2017.		2017.
	[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-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3688>.		editor.org/info/rfc3688>.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246,
			DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
			editor.org/info/rfc5246>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6020>.		editor.org/info/rfc6020>.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,		and A. Bierman, Ed., "Network Configuration Protocol
	<https://www.rfc-editor.org/info/rfc7223>.		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<https://www.rfc-editor.org/info/rfc6241>.
			[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
			Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
			<https://www.rfc-editor.org/info/rfc6242>.
			[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
			Protocol (NETCONF) Access Control Model", RFC 6536,
			DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
			editor.org/info/rfc6536>.
			[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
			Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
			<https://www.rfc-editor.org/info/rfc8040>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
			[I-D.ietf-netmod-rfc8022bis]
			Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
			Routing Management (NMDA Version)", draft-ietf-netmod-
			rfc8022bis-11 (work in progress), January 2018.
	[I-D.ietf-netmod-yang-tree-diagrams]		[I-D.ietf-netmod-yang-tree-diagrams]
	Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-		Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
	ietf-netmod-yang-tree-diagrams-02 (work in progress),		ietf-netmod-yang-tree-diagrams-05 (work in progress),
	October 2017.		January 2018.
	[I-D.ietf-rtgwg-device-model]		[I-D.ietf-rtgwg-device-model]
	Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,		Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
	"Network Device YANG Logical Organization", draft-ietf-		"Network Device YANG Logical Organization", draft-ietf-
	rtgwg-device-model-02 (work in progress), March 2017.		rtgwg-device-model-02 (work in progress), March 2017.
	[I-D.ietf-rtgwg-ni-model]		[I-D.ietf-rtgwg-ni-model]
	Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.		Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
	Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-		Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
	model-04 (work in progress), September 2017.		model-09 (work in progress), February 2018.
	[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for		[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
	System Management", RFC 7317, DOI 10.17487/RFC7317, August		System Management", RFC 7317, DOI 10.17487/RFC7317, August
	2014, <https://www.rfc-editor.org/info/rfc7317>.		2014, <https://www.rfc-editor.org/info/rfc7317>.
	[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module		[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
	Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,		Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
	<https://www.rfc-editor.org/info/rfc7895>.		<https://www.rfc-editor.org/info/rfc7895>.
	[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>.
	[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
	Management", RFC 8022, DOI 10.17487/RFC8022, November
	2016, <https://www.rfc-editor.org/info/rfc8022>.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The Routing Area Yang Architecture design team members included Acee		The Routing Area Yang Architecture design team members included Acee
	Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger,		Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger,
	Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review		Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review
	comments were also received by Martin Bjorklund and John Scudder.		comments were also received by Martin Bjorklund and John Scudder.
	This document was motivated by, and derived from,		This document was motivated by, and derived from,
	[I-D.ietf-rtgwg-device-model].		[I-D.ietf-rtgwg-device-model].
	The RFC text was produced using Marshall Rose's xml2rfc tool.		The RFC text was produced using Marshall Rose's xml2rfc tool.
			Thanks to Alvaro Retana for IESG review.
	Appendix B. Examples		Appendix B. Examples
	The following subsections provide example uses of LNEs.		The following subsections provide example uses of LNEs.
	B.1. Example: Host Device Managed LNE		B.1. Example: Host Device Managed LNE
	This section describes an example of the LNE model using schema mount		This section describes an example of the LNE model using schema mount
	to achieve the parent management. An example device supports		to achieve the parent management. An example device supports
	multiple instances of LNEs (logical routers), each of which supports		multiple instances of LNEs (logical routers), each of which supports
	features of layer 2 and layer 3 interfaces [RFC7223], routing		features of layer 2 and layer 3 interfaces
	information base [RFC8022], and OSPF protocol. Each of these		[I-D.ietf-netmod-rfc7223bis], routing information base
			[I-D.ietf-netmod-rfc8022bis], and OSPF protocol. Each of these
	features is specified by a YANG model, and they are combined using		features is specified by a YANG model, and they are combined using
	YANG Schema Mount as follows:		YANG Schema Mount as follows:
	module: ietf-logical-network-element		module: ietf-logical-network-element
	+--rw logical-network-elements		+--rw logical-network-elements
	+--rw logical-network-element* [name]		+--rw logical-network-element* [name]
	+--rw name string		+--rw name string
	+--mp root		+--mp root
	+--ro yanglib:modules-state/		+--ro yanglib:modules-state/
	| +--ro module-set-id string		| +--ro module-set-id string
	skipping to change at page 15, line 42 ¶		skipping to change at page 17, line 45 ¶
	| +--rw user-authentication-order* identityref		| +--rw user-authentication-order* identityref
	| +--rw user* [name] {local-users}?		| +--rw user* [name] {local-users}?
	| +--rw name string		| +--rw name string
	| +--rw password? ianach:crypt-hash		| +--rw password? ianach:crypt-hash
	| +--rw authorized-key* [name]		| +--rw authorized-key* [name]
	| +--rw name string		| +--rw name string
	| +--rw algorithm string		| +--rw algorithm string
	| +--rw key-data binary		| +--rw key-data binary
	+--ro sys:system-state/		+--ro sys:system-state/
	| ...		| ...
	+--ro rt:routing-state/
	| +--ro router-id? yang:dotted-quad
	| +--ro control-plane-protocols
	| +--ro control-plane-protocol* [type name]
	| +--ro ospf:ospf/
	| +--ro instance* [af]
	| ...
	+--rw rt:routing/		+--rw rt:routing/
	| +--rw router-id? yang:dotted-quad		| +--rw router-id? yang:dotted-quad
	| +--rw control-plane-protocols		| +--rw control-plane-protocols
	| +--rw control-plane-protocol* [type name]		| +--rw control-plane-protocol* [type name]
	| +--rw ospf:ospf/		| +--rw ospf:ospf/
	| +--rw instance* [af]		| +--rw instance* [af]
	| +--rw areas		| +--rw areas
	| +--rw area* [area-id]		| +--rw area* [area-id]
	| +--rw interfaces		| +--rw interfaces
	| +--rw interface* [name]		| +--rw interface* [name]
	| +--rw name if:interface-ref		| +--rw name if:interface-ref
	| +--rw cost? uint16		| +--rw cost? uint16
	+--rw if:interfaces/		+--rw if:interfaces/
	| +--rw interface* [name]		+--rw interface* [name]
	| +--rw name string		+--rw name string
	| +--rw ip:ipv4!/		+--rw ip:ipv4!/
	| | +--rw address* [ip]		| +--rw address* [ip]
	| | ...
	+--ro if:interfaces-state/
	+--ro interface* [name]
	+--ro name string
	+--ro ip:ipv4!/
	| +--ro address* [ip]
	| ...		| ...
	module: ietf-interfaces		module: ietf-interfaces
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		+--rw interface* [name]
	| +--rw name string		+--rw name string
	| +--rw lne:bind-lne-name? string		+--rw lne:bind-lne-name? string
	+--ro interfaces-state
	+--ro interface* [name]
	+--ro name string
	+--ro oper-status enumeration		+--ro oper-status enumeration
	module: ietf-yang-library		module: ietf-yang-library
	+--ro modules-state		+--ro modules-state
	+--ro module-set-id string		+--ro module-set-id string
	+--ro module* [name revision]		+--ro module* [name revision]
	+--ro name yang:yang-identifier		+--ro name yang:yang-identifier
	module: ietf-system		module: ietf-system
	+--rw system		+--rw system
	skipping to change at page 19, line 13 ¶		skipping to change at page 21, line 26 ¶
	| +--rw user-authentication-order* identityref		| +--rw user-authentication-order* identityref
	| +--rw user* [name] {local-users}?		| +--rw user* [name] {local-users}?
	| +--rw name string		| +--rw name string
	| +--rw password? ianach:crypt-hash		| +--rw password? ianach:crypt-hash
	| +--rw authorized-key* [name]		| +--rw authorized-key* [name]
	| +--rw name string		| +--rw name string
	| +--rw algorithm string		| +--rw algorithm string
	| +--rw key-data binary		| +--rw key-data binary
	+--ro system-state		+--ro system-state
	+--ro platform		+--ro platform
	| +--ro os-name? string		+--ro os-name? string
	| +--ro os-release? string		+--ro os-release? string
	module: ietf-routing		module: ietf-routing
	+--ro routing-state		rw-- routing
	| +--ro router-id? yang:dotted-quad
	| +--ro control-plane-protocols
	| | +--ro control-plane-protocol* [type name]
	| | +--ro ospf:ospf/
	| | +--ro instance* [af]
	+--rw routing
	+--rw router-id? yang:dotted-quad		+--rw router-id? yang:dotted-quad
	+--rw control-plane-protocols		+--rw control-plane-protocols
	+--rw control-plane-protocol* [type name]		+--rw control-plane-protocol* [type name]
	+--rw ospf:ospf/		+--rw ospf:ospf/
	+--rw instance* [af]		+--rw instance* [af]
	+--rw areas		+--rw areas
	+--rw area* [area-id]		+--rw area* [area-id]
	+--rw interfaces		+--rw interfaces
	+--rw interface* [name]		+--rw interface* [name]
	+--rw name if:interface-ref		+--rw name if:interface-ref
	+--rw cost? uint16		+--rw cost? uint16
	module: ietf-interfaces		module: ietf-interfaces
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		+--rw interface* [name]
	| +--rw name string		+--rw name string
	+--ro interfaces-state		+--ro oper-status enumeration
	+--ro interface* [name]
	+--ro name string
	+--ro oper-status enumeration
	B.1.1. Configuration Data		B.1.1. Configuration Data
	The following shows an example where two customer specific LNEs are		The following shows an example where two customer specific LNEs are
	configured:		configured:
	{		{
	"ietf-logical-network-element:logical-network-elements": {		"ietf-logical-network-element:logical-network-elements": {
	"logical-network-element": [		"logical-network-element": [
	{		{
	skipping to change at page 25, line 24 ¶		skipping to change at page 27, line 31 ¶
	}		}
	]		]
	}		}
	"ietf-system:system-state": {		"ietf-system:system-state": {
	"ietf-system:system-state": {		"ietf-system:system-state": {
	"platform": {		"platform": {
	"os-name": "NetworkOS"		"os-name": "NetworkOS"
	}		}
	}		}
	},		},
	"ietf-routing:routing-state": {		"ietf-routing:routing": {
	"router-id": "192.0.2.1",		"router-id": "192.0.2.1",
	"control-plane-protocols": {		"control-plane-protocols": {
	"control-plane-protocol": [		"control-plane-protocol": [
	{		{
	"type": "ietf-routing:ospf",		"type": "ietf-routing:ospf",
	"name": "1",		"name": "1",
	"ietf-ospf:ospf": {		"ietf-ospf:ospf": {
	"instance": [		"instance": [
	{		{
	"af": "ipv4",		"af": "ipv4",
	skipping to change at page 25, line 45 ¶		skipping to change at page 28, line 4 ¶
	"areas": {		"areas": {
	"area": [		"area": [
	{		{
	"area-id": "203.0.113.1",		"area-id": "203.0.113.1",
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"cost": 10		"cost": 10
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	},		},
	"ietf-interfaces:interfaces-state": {		"ietf-interfaces:interfaces": {
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"oper-status": "up",		"oper-status": "up",
	"phys-address": "00:01:02:A1:B1:C1",		"phys-address": "00:01:02:A1:B1:C1",
	"statistics": {		"statistics": {
	"discontinuity-time": "2017-06-26T12:34:56-05:00"		"discontinuity-time": "2017-06-26T12:34:56-05:00"
	},		},
	skipping to change at page 28, line 20 ¶		skipping to change at page 30, line 27 ¶
	}		}
	]		]
	}		}
	"ietf-system:system-state": {		"ietf-system:system-state": {
	"ietf-system:system-state": {		"ietf-system:system-state": {
	"platform": {		"platform": {
	"os-name": "NetworkOS"		"os-name": "NetworkOS"
	}		}
	}		}
	},		},
	"ietf-routing:routing-state": {		"ietf-routing:routing": {
	"router-id": "192.0.2.2",		"router-id": "192.0.2.2",
	"control-plane-protocols": {		"control-plane-protocols": {
	"control-plane-protocol": [		"control-plane-protocol": [
	{		{
	"type": "ietf-routing:ospf",		"type": "ietf-routing:ospf",
	"name": "1",		"name": "1",
	"ietf-ospf:ospf": {		"ietf-ospf:ospf": {
	"instance": [		"instance": [
	{		{
	"af": "ipv4",		"af": "ipv4",
	skipping to change at page 28, line 45 ¶		skipping to change at page 31, line 4 ¶
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"cost": 10		"cost": 10
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	"ietf-interfaces:interfaces-state": {		"ietf-interfaces:interfaces": {
	"interfaces": {		"interfaces": {
	{		{
	"name": "eth1",		"name": "eth1",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"oper-status": "up",		"oper-status": "up",
	"phys-address": "00:01:02:A1:B1:C2",		"phys-address": "00:01:02:A1:B1:C2",
	"statistics": {		"statistics": {
	"discontinuity-time": "2017-06-26T12:34:56-05:00"		"discontinuity-time": "2017-06-26T12:34:56-05:00"
	},		},
	"ip:ipv4": {		"ip:ipv4": {
	skipping to change at page 29, line 32 ¶		skipping to change at page 31, line 39 ¶
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	}		}
	]		]
	},		},
	"ietf-interfaces:interfaces-state": {		"ietf-interfaces:interfaces": {
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth0",		"name": "eth0",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"oper-status": "up",		"oper-status": "up",
	"phys-address": "00:01:02:A1:B1:C0",		"phys-address": "00:01:02:A1:B1:C0",
	"statistics": {		"statistics": {
	"discontinuity-time": "2017-06-26T12:34:56-05:00"		"discontinuity-time": "2017-06-26T12:34:56-05:00"
	},		},
	skipping to change at page 33, line 47 ¶		skipping to change at page 36, line 10 ¶
	}		}
	]		]
	}		}
	}		}
	B.2. Example: Self Managed LNE		B.2. Example: Self Managed LNE
	This section describes an example of the LNE model using schema mount		This section describes an example of the LNE model using schema mount
	to achieve child independent management. An example device supports		to achieve child independent management. An example device supports
	multiple instances of LNEs (logical routers), each of them has the		multiple instances of LNEs (logical routers), each of them has the
	features of layer 2 and layer 3 interfaces [RFC7223], routing		features of layer 2 and layer 3 interfaces
	information base [RFC8022], and the OSPF protocol. Each of these		[I-D.ietf-netmod-rfc7223bis], routing information base
			[I-D.ietf-netmod-rfc8022bis], and the OSPF protocol. Each of these
	features is specified by a YANG model, and they are put together by		features is specified by a YANG model, and they are put together by
	the YANG Schema Mount as following:		the YANG Schema Mount as following:
	module: ietf-logical-network-element		module: ietf-logical-network-element
	+--rw logical-network-elements		+--rw logical-network-elements
	+--rw logical-network-element* [name]		+--rw logical-network-element* [name]
	+--rw name string		+--rw name string
	+--mp root		+--mp root
	// The internal modules of the LNE are not visible to		// The internal modules of the LNE are not visible to
	// the parament management.		// the parament management.
	// The child manages its modules, including ietf-routing		// The child manages its modules, including ietf-routing
	// and ietf-interfaces		// and ietf-interfaces
	module: ietf-interfaces		module: ietf-interfaces
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		+--rw interface* [name]
	| +--rw name string		+--rw name string
	| +--rw lne:bind-lne-name? string		+--rw lne:bind-lne-name? string
	+--ro interfaces-state
	+--ro interface* [name]
	+--ro name string
	+--ro oper-status enumeration		+--ro oper-status enumeration
	module: ietf-yang-library		module: ietf-yang-library
	+--ro modules-state		+--ro modules-state
	+--ro module-set-id string		+--ro module-set-id string
	+--ro module* [name revision]		+--ro module* [name revision]
	+--ro name yang:yang-identifier		+--ro name yang:yang-identifier
	module: ietf-system		module: ietf-system
	+--rw system		+--rw system
	skipping to change at page 35, line 50 ¶		skipping to change at page 39, line 30 ¶
	| +--rw authorized-key* [name]		| +--rw authorized-key* [name]
	| +--rw name string		| +--rw name string
	| +--rw algorithm string		| +--rw algorithm string
	| +--rw key-data binary		| +--rw key-data binary
	+--ro system-state		+--ro system-state
	+--ro platform		+--ro platform
	| +--ro os-name? string		| +--ro os-name? string
	| +--ro os-release? string		| +--ro os-release? string
	module: ietf-routing		module: ietf-routing
	+--ro routing-state
	| +--ro router-id? yang:dotted-quad
	| +--ro control-plane-protocols
	| | +--ro control-plane-protocol* [type name]
	| | +--ro ospf:ospf/
	| | +--ro instance* [af]
	+--rw routing		+--rw routing
	+--rw router-id? yang:dotted-quad		+--rw router-id? yang:dotted-quad
	+--rw control-plane-protocols		+--rw control-plane-protocols
	+--rw control-plane-protocol* [type name]		+--rw control-plane-protocol* [type name]
	+--rw ospf:ospf/		+--rw ospf:ospf/
	+--rw instance* [af]		+--rw instance* [af]
	+--rw areas		+--rw areas
	+--rw area* [area-id]		+--rw area* [area-id]
	+--rw interfaces		+--rw interfaces
	+--rw interface* [name]		+--rw interface* [name]
	+--rw name if:interface-ref		+--rw name if:interface-ref
	+--rw cost? uint16		+--rw cost? uint16
	module: ietf-interfaces		module: ietf-interfaces
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		+--rw interface* [name]
	| +--rw name string		+--rw name string
	+--ro interfaces-state		+--ro oper-status enumeration
	+--ro interface* [name]
	+--ro name string
	+--ro oper-status enumeration
	B.2.1. Configuration Data		B.2.1. Configuration Data
	Each of the child virtual routers is managed through its own sessions		Each of the child virtual routers is managed through its own sessions
	and configuration data.		and configuration data.
	B.2.1.1. Logical Network Element 'vnf1'		B.2.1.1. Logical Network Element 'vnf1'
	The following shows an example configuration data for the LNE name		The following shows an example configuration data for the LNE name
	"vnf1":		"vnf1":
	skipping to change at page 40, line 4 ¶		skipping to change at page 43, line 31 ¶
	"root": {		"root": {
	}		}
	},		},
	{		{
	"name": "vnf2",		"name": "vnf2",
	"root": {		"root": {
	}		}
	}		}
	]		]
	},		},
	"ietf-interfaces:interfaces-state": {
			"ietf-interfaces:interfaces": {
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth0",		"name": "eth0",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"oper-status": "up",		"oper-status": "up",
	"phys-address": "00:01:02:A1:B1:C0",		"phys-address": "00:01:02:A1:B1:C0",
	"statistics": {		"statistics": {
	"discontinuity-time": "2017-06-26T12:34:56-05:00"		"discontinuity-time": "2017-06-26T12:34:56-05:00"
	},		},
	skipping to change at page 44, line 24 ¶		skipping to change at page 48, line 4 ¶
	},		},
	{		{
	"name": "ietf-yang-types",		"name": "ietf-yang-types",
	"revision": "2013-07-15",		"revision": "2013-07-15",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-yang-types",		"urn:ietf:params:xml:ns:yang:ietf-yang-types",
	"conformance-type": "import"		"conformance-type": "import"
	}		}
	]		]
	},		},
	"ietf-system:system-state": {		"ietf-system:system-state": {
	"platform": {		"platform": {
	"os-name": "NetworkOS"		"os-name": "NetworkOS"
	}		}
	},		},
	"ietf-routing:routing-state": {		"ietf-routing:routing": {
	"router-id": "192.0.2.1",		"router-id": "192.0.2.1",
	"control-plane-protocols": {		"control-plane-protocols": {
	"control-plane-protocol": [		"control-plane-protocol": [
	{		{
	"type": "ietf-routing:ospf",		"type": "ietf-routing:ospf",
	"name": "1",		"name": "1",
	"ietf-ospf:ospf": {		"ietf-ospf:ospf": {
	"instance": [		"instance": [
	{		{
	"af": "ipv4",		"af": "ipv4",
	skipping to change at page 45, line 4 ¶		skipping to change at page 48, line 31 ¶
	"areas": {		"areas": {
	"area": [		"area": [
	{		{
	"area-id": "203.0.113.1",		"area-id": "203.0.113.1",
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"cost": 10		"cost": 10
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	},		},
	"ietf-interfaces:interfaces-state": {		"ietf-interfaces:interfaces": {
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"oper-status": "up",		"oper-status": "up",
	"phys-address": "00:01:02:A1:B1:C1",		"phys-address": "00:01:02:A1:B1:C1",
	"statistics": {		"statistics": {
	"discontinuity-time": "2017-06-26T12:34:56-05:00"		"discontinuity-time": "2017-06-26T12:34:56-05:00"
	},		},
	skipping to change at page 47, line 31 ¶		skipping to change at page 51, line 9 ¶
	}		}
	]		]
	},		},
	"ietf-system:system-state": {		"ietf-system:system-state": {
	"platform": {		"platform": {
	"os-name": "NetworkOS"		"os-name": "NetworkOS"
	}		}
	},		},
	"ietf-routing:routing-state": {		"ietf-routing:routing": {
	"router-id": "192.0.2.2",		"router-id": "192.0.2.2",
	"control-plane-protocols": {		"control-plane-protocols": {
	"control-plane-protocol": [		"control-plane-protocol": [
	{		{
	"type": "ietf-routing:ospf",		"type": "ietf-routing:ospf",
	"name": "1",		"name": "1",
	"ietf-ospf:ospf": {		"ietf-ospf:ospf": {
	"instance": [		"instance": [
	{		{
	"af": "ipv4",		"af": "ipv4",
	skipping to change at page 48, line 4 ¶		skipping to change at page 51, line 31 ¶
	"area": [		"area": [
	{		{
	"area-id": "203.0.113.1",		"area-id": "203.0.113.1",
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"cost": 10		"cost": 10
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	},		},
	"ietf-interfaces:interfaces-state": {		"ietf-interfaces:interfaces": {
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"oper-status": "up",		"oper-status": "up",
	"phys-address": "00:01:02:A1:B1:C2",		"phys-address": "00:01:02:A1:B1:C2",
	"statistics": {		"statistics": {
	"discontinuity-time": "2017-06-26T12:34:56-05:00"		"discontinuity-time": "2017-06-26T12:34:56-05:00"
	},		},
End of changes. 86 change blocks.
	284 lines changed or deleted		304 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/