< draft-ietf-rtgwg-lne-model-06.txt		draft-ietf-rtgwg-lne-model-07.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: August 10, 2018 Deutsche Telekom		Expires: August 18, 2018 Deutsche Telekom
	A. Lindem		A. Lindem
	Cisco Systems		Cisco Systems
	D. Bogdanovic		D. Bogdanovic
	X. Liu		X. Liu
	Jabil		Jabil
	February 6, 2018		February 14, 2018
	YANG Logical Network Elements		YANG Model for Logical Network Elements
	draft-ietf-rtgwg-lne-model-06		draft-ietf-rtgwg-lne-model-07
	Abstract		Abstract
	This document defines a logical network element YANG module. This		This document defines a logical network element YANG module. This
	module can be used to manage the logical resource partitioning that		module can be used to manage the logical resource partitioning that
	may be present on a network device. Examples of common industry		may be present on a network device. Examples of common industry
	terms for logical resource partitioning are Logical Systems or		terms for logical resource partitioning are Logical Systems or
	Logical Routers.		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 http://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 August 10, 2018.		This Internet-Draft will expire on August 18, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 10		6. Logical Network Element Model . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. Normative References . . . . . . . . . . . . . . . . . . 14		7.1. Normative References . . . . . . . . . . . . . . . . . . 14
	7.2. Informative References . . . . . . . . . . . . . . . . . 15		7.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 17		Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 17
	B.1. Example: Host Device Managed LNE . . . . . . . . . . . . 17		B.1. Example: Host Device Managed LNE . . . . . . . . . . . . 17
	B.1.1. Configuration Data . . . . . . . . . . . . . . . . . 22		B.1.1. Configuration Data . . . . . . . . . . . . . . . . . 22
	B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 25		B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 26
	B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 36		B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 36
	B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 40		B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 40
	B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 43		B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52		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
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	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
	[I-D.ietf-netmod-rfc7223bis]. The logical-network-element module		[I-D.ietf-netmod-rfc7223bis]. The logical-network-element module
	augments existing interface management model by adding an identifier		augments existing interface management model by adding an identifier
	which is used on physical interface types to identify an associated		which is used on interfaces to identify an associated LNE.
	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 [I-D.ietf-netmod-rfc7223bis] is		The interface model defined in [I-D.ietf-netmod-rfc7223bis] is
	structured to include all interfaces in a flat list, without regard		structured to include all interfaces in a flat list, without regard
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 42 ¶
	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
	configuration are managed separately. For example, in logical		configuration are managed separately. For example, in logical
	routers or VNFs, this may correspond to establishing multiple logical		routers or VNFs, this may correspond to establishing multiple logical
	instances using a single software installation. The model supports		instances using a single software installation. The model supports
	configuration of multiple instances on a single device by creating a		configuration of multiple instances on a single device by creating a
	list of logical network elements, each with their own configuration		list of logical network elements, each with their own configuration
	and operational state related to routing and switching protocols.		and operational state related to routing and switching protocols.
	The LNE model can be represented using the tree format defined in		The LNE model can be represented as:
	[I-D.ietf-netmod-yang-tree-diagrams] as:
	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
	+--rw managed? boolean		+--rw managed? boolean
	+--rw description? string		+--rw description? string
	+--mp root		+--mp root
	augment /if:interfaces/if:interface:		augment /if:interfaces/if:interface:
	+--rw bind-lne-name?		+--rw bind-lne-name?
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 29 ¶
	/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
	particular attention as it controls whether information under the		particular attention as it controls whether information under the
	LNE mount point is accessible by both the host device and within		LNE mount point is accessible by both the host device and within
	the LNE context. There may be extra sensitivity to this leaf in		the LNE context. There may be extra sensitivity to this leaf in
	environments where an LNE is managed by a different party than the		environments where an LNE is managed by a different party than the
	host device, and that party does not wish to share LNE information		host device, and that party does not wish to share LNE information
	with the operator of the host device.		with the operator of the host device.
	/if:interfaces/if:interface/bind-lne-name: This leaf indicates the		/if:interfaces/if:interface/bind-lne-name: This leaf indicates the
	LNE instance to which an interface is assigned.		LNE instance to which an interface is assigned. Implementations
			should pay particular attention to when changes to this leaf are
			permitted as removal of an interface from an LNE can have major
			impact on the LNEs operation as it is similar to physically
			removing an interface from the device. Implementations can reject
			an reassignment using the previously described error message
			generation.
	Unauthorized access to any of these lists can adversely affect the		Unauthorized access to any of these lists can adversely affect the
	security of both the local device and the network. This may lead to		security of both the local device and the network. This may lead to
	network malfunctions, delivery of packets to inappropriate		network malfunctions, delivery of packets to inappropriate
	destinations, and other problems.		destinations, and other problems.
	5. IANA Considerations		5. IANA Considerations
	This document registers a URI in the IETF XML registry [RFC3688].		This document registers a URI in the IETF XML registry [RFC3688].
	Following the format in RFC 3688, the following registration is		Following the format in RFC 3688, the following registration is
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 18 ¶
	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@2018-02-06.yang"		<CODE BEGINS> file "ietf-logical-network-element@2018-02-14.yang"
	module ietf-logical-network-element {		module ietf-logical-network-element {
	yang-version 1.1;		yang-version 1.1;
	// namespace		// namespace
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-logical-network-element";		"urn:ietf:params:xml:ns:yang:ietf-logical-network-element";
	prefix lne;		prefix lne;
	// import some basic types		// import some basic types
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 28 ¶
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	// RFC Ed.: replace XXXX with actual RFC number and remove		// RFC Ed.: replace XXXX with actual RFC number and remove
	// this note		// this note
	// RFC Ed.: please update TBD		// RFC Ed.: please update TBD
	revision 2018-02-06 {		revision 2018-02-14 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference "RFC XXXX";		reference "RFC XXXX";
	}		}
	// top level device definition statements		// top level device definition statements
	container logical-network-elements {		container logical-network-elements {
	description		description
	"Allows a network device to support multiple logical		"Allows a network device to support multiple logical
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 6 ¶
	type string;		type string;
	description		description
	"Optionally, indicates the source of the assignment		"Optionally, indicates the source of the assignment
	failure.";		failure.";
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-netmod-rfc7223bis]		[I-D.ietf-netmod-rfc7223bis]
	Bjorklund, M., "A YANG Data Model for Interface		Bjorklund, M., "A YANG Data Model for Interface
	Management", draft-ietf-netmod-rfc7223bis-03 (work in		Management", draft-ietf-netmod-rfc7223bis-03 (work in
	progress), January 2018.		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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-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, <https://www.rfc-		DOI 10.17487/RFC3688, January 2004,
	editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008, <https://www.rfc-		DOI 10.17487/RFC5246, August 2008,
	editor.org/info/rfc5246>.		<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, <https://www.rfc-		DOI 10.17487/RFC6020, October 2010,
	editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.		<https://www.rfc-editor.org/info/rfc6242>.
	[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, <https://www.rfc-		DOI 10.17487/RFC6536, March 2012,
	editor.org/info/rfc6536>.		<https://www.rfc-editor.org/info/rfc6536>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[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>.
	7.2. Informative References		7.2. Informative References
			[I-D.ietf-netmod-entity]
			Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
			YANG Data Model for Hardware Management", draft-ietf-
			netmod-entity-08 (work in progress), January 2018.
	[I-D.ietf-netmod-rfc8022bis]		[I-D.ietf-netmod-rfc8022bis]
	Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for		Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
	Routing Management (NMDA Version)", draft-ietf-netmod-		Routing Management (NMDA Version)", draft-ietf-netmod-
	rfc8022bis-11 (work in progress), January 2018.		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-05 (work in progress),		ietf-netmod-yang-tree-diagrams-05 (work in progress),
	January 2018.		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 Model for Network Instances", draft-ietf-rtgwg-
	model-09 (work in progress), February 2018.		ni-model-10 (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",
	skipping to change at page 15, line 44 ¶		skipping to change at page 16, line 4 ¶
	[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>.
	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, John Scudder, Dan
			Romascanu and Taylor Yu.
	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.		Thanks to Alvaro Retana for IESG review.
	Appendix B. Examples		Appendix B. Examples
	skipping to change at page 17, line 20 ¶		skipping to change at page 17, line 20 ¶
	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		features of layer 2 and layer 3 interfaces
	[I-D.ietf-netmod-rfc7223bis], routing information base		[I-D.ietf-netmod-rfc7223bis], routing information base
	[I-D.ietf-netmod-rfc8022bis], and OSPF protocol. Each of these		[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 shown below. Not all possible mounted modules
			are shown. For example implementations could also mount the model
			defined in [I-D.ietf-netmod-entity].
	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
	| +--ro module* [name revision]		| +--ro module* [name revision]
	| +--ro name yang:yang-identifier		| +--ro name yang:yang-identifier
	skipping to change at page 23, line 23 ¶		skipping to change at page 23, line 23 ¶
	"interface": [		"interface": [
	{		{
	"name": "eth1",		"name": "eth1",
	"ip:ipv4": {		"ip:ipv4": {
	"address": [		"address": [
	{		{
	"ip": "192.0.2.11",		"ip": "192.0.2.11",
	"prefix-length": 24,		"prefix-length": 24,
	}		}
	]		]
			},
			"ip:ipv6": {
			"address": [
			{
			"ip": "2001:db8:0:2::11",
			"prefix-length": 64,
			}
			]
	}		}
	}		}
	]		]
	}		}
	}		}
	}		}
	},		},
	{		{
	"name": "cust2",		"name": "cust2",
	"root": {		"root": {
	skipping to change at page 24, line 44 ¶		skipping to change at page 25, line 4 ¶
	"ip": "192.0.2.11",		"ip": "192.0.2.11",
	"prefix-length": 24,		"prefix-length": 24,
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	}		}
	]		]
	},		},
	"ietf-interfaces:interfaces": {		"ietf-interfaces:interfaces": {
	"interfaces": {		"interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth0",		"name": "eth0",
	"ip:ipv4": {		"ip:ipv4": {
	"address": [		"address": [
	{		{
	"ip": "192.0.2.10",		"ip": "192.0.2.10",
	"prefix-length": 24,		"prefix-length": 24,
	}		}
	]		]
			},
			"ip:ipv6": {
			"address": [
			{
			"ip": "2001:db8:0:2::10",
			"prefix-length": 64,
			}
			]
	}		}
	},		},
	{		{
	"name": "cust1:eth1",		"name": "cust1:eth1",
	"lne:bind-lne-name": "cust1"		"lne:bind-lne-name": "cust1"
	},		},
	{		{
	"name": "cust2:eth1",		"name": "cust2:eth1",
	"lne:bind-lne-name": "cust2"		"lne:bind-lne-name": "cust2"
	}		}
End of changes. 27 change blocks.
	31 lines changed or deleted		60 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/