< draft-ietf-rtgwg-device-model-00.txt		draft-ietf-rtgwg-device-model-01.txt >
	Network Working Group A. Lindem, Ed.		Network Working Group A. Lindem, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Informational L. Berger, Ed.		Intended status: Informational L. Berger, Ed.
	Expires: February 3, 2017 LabN Consulting, L.L.C.		Expires: May 1, 2017 LabN Consulting, L.L.C.
	D. Bogdanovic		D. Bogdanovic
	C. Hopps		C. Hopps
	Deutsche Telekom		Deutsche Telekom
	August 2, 2016		October 28, 2016
	Network Device YANG Organizational Models		Network Device YANG Organizational Models
	draft-ietf-rtgwg-device-model-00		draft-ietf-rtgwg-device-model-01
	Abstract		Abstract
	This document presents an approach for organizing YANG models in a		This document presents an approach for organizing YANG models in a
	comprehensive structure that may be used to configure and operate		comprehensive structure that may be used to configure and operate
	network devices. The structure is itself represented as a YANG		network devices. The structure is itself represented as a YANG
	model, with all of the related component models logically organized		model, with all of the related component models logically organized
	in a way that is operationally intuitive, but this model is not		in a way that is operationally intuitive, but this model is not
	expected to be implemented. The identified component modules are		expected to be implemented. The identified component modules are
	expected to be defined and implemented on common network devices.		expected to be defined and implemented on common network devices.
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 3, 2017.		This Internet-Draft will expire on May 1, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	implemented. These models are defined to support the configuration		implemented. These models are defined to support the configuration
	and operation of network-devices that allow for the partitioning of		and operation of network-devices that allow for the partitioning of
	resources from both, or either, management and networking		resources from both, or either, management and networking
	perspectives. Two forms of resource partitioning are referenced:		perspectives. Two forms of resource partitioning are referenced:
	The first form provides a logical partitioning of a network device		The first form provides a logical partitioning of a network device
	where each partition is separately managed as essentially an		where each partition is separately managed as essentially an
	independent network element which is 'hosted' by the base network		independent network element which is 'hosted' by the base network
	device. These hosted network elements are referred to as logical		device. These hosted network elements are referred to as logical
	network elements, or LNEs, and are supported by the logical-network-		network elements, or LNEs, and are supported by the logical-network-
	element module defined in [LNE-MODEL]. The module is used to		element module defined in [I-D.ietf-rtgwg-lne-model]. The module is
	identify LNEs and associate resources from the network-device with		used to identify LNEs and associate resources from the network-device
	each LNE. LNEs themselves are represented in YANG as independent		with each LNE. LNEs themselves are represented in YANG as
	network devices; each accessed independently. Optionally, and when		independent network devices; each accessed independently.
	supported by the implementation, they may also be accessed from the		Optionally, and when supported by the implementation, they may also
	host system. Examples of vendor terminology for an LNE include		be accessed from the host system. Examples of vendor terminology for
	logical system or logical router, and virtual switch, chassis, or		an LNE include logical system or logical router, and virtual switch,
	fabric.		chassis, or fabric.
	The second form provides support what is commonly referred to as		The second form provides support what is commonly referred to as
	Virtual Routing and Forwarding (VRF) instances as well as Virtual		Virtual Routing and Forwarding (VRF) instances as well as Virtual
	Switch Instances (VSI), see [RFC4026]. In this form of resource		Switch Instances (VSI), see [RFC4026]. In this form of resource
	partitioning multiple control plane and forwarding/bridging instances		partitioning multiple control plane and forwarding/bridging instances
	are provided by and managed via a single (physical or logical)		are provided by and managed via a single (physical or logical)
	network device. This form of resource partitioning is referred to as		network device. This form of resource partitioning is referred to as
	Network Instances and are supported by the network-instance module		Network Instances and are supported by the network-instance module
	defined in [NI-MODEL]. Configuration and operation of each network-		defined in [I-D.ietf-rtgwg-ni-model]. Configuration and operation of
	instance is always via the network device and the network-instance		each network-instance is always via the network device and the
	module.		network-instance module.
	This document was motivated by, and derived from,		This document was motivated by, and derived from,
	[I-D.openconfig-netmod-model-structure]. The requirements from that		[I-D.openconfig-netmod-model-structure]. The requirements from that
	document have been combined with the requirements from "Consistent		document have been combined with the requirements from "Consistent
	Modeling of Operational State Data in YANG",		Modeling of Operational State Data in YANG",
	[I-D.openconfig-netmod-opstate], into "NETMOD Operational State		[I-D.openconfig-netmod-opstate], into "NETMOD Operational State
	Requirements", [I-D.ietf-netmod-opstate-reqs]. This document is		Requirements", [I-D.ietf-netmod-opstate-reqs]. This document is
	aimed at the requirement related to a common model-structure,		aimed at the requirement related to a common model-structure,
	currently Requirement 7, and also aims to provide a modeling base for		currently Requirement 7, and also aims to provide a modeling base for
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	| :+-----+-----+-----+: :+-----+-----+-----+: |		| :+-----+-----+-----+: :+-----+-----+-----+: |
	| : | | | | | | : : | | | | | | : |		| : | | | | | | : : | | | | | | : |
	| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |		| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
	| | | | | | | | | | | | | |		| | | | | | | | | | | | | |
	`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''		`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
	| | | | | | | | | | | |		| | | | | | | | | | | |
	Interfaces Interfaces		Interfaces Interfaces
	Figure 1: Module Element Relationships		Figure 1: Module Element Relationships
	A model for LNEs is described in [LNE-MODEL] and the model for		A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the
	network instances is covered in [NI-MODEL].		model for network instances is covered in [I-D.ietf-rtgwg-ni-model].
	The presented notional network device module can itself be thought of		The presented notional network device module can itself be thought of
	as a "meta-model" as it describes the relationships between		as a "meta-model" as it describes the relationships between
	individual models. We choose to represent it also as a simple YANG		individual models. We choose to represent it also as a simple YANG
	module consisting of other models, which are in fact independent top		module consisting of other models, which are in fact independent top
	level individual models. Although it is never expected to be		level individual models. Although it is never expected to be
	implemented.		implemented.
	The presented modules do not follow the hierarchy of any Particular		The presented modules do not follow the hierarchy of any Particular
	implementation, and hence is vendor-neutral. Nevertheless, the		implementation, and hence is vendor-neutral. Nevertheless, the
	structure should be familiar to network operators and also readily		structure should be familiar to network operators and also readily
	mapped to vendor implementations.		mapped to vendor implementations.
	The overall structure is:		The overall structure is:
	module: ietf-network-device		module: ietf-network-device
	+--rw modules-state [I-D.ietf-netconf-yang-library]		+--rw modules-state [RFC7895]
	|		|
	+--rw interfaces [RFC7223]		+--rw interfaces [RFC7223]
	+--rw hardware		+--rw hardware
	+--rw qos		+--rw qos
	|		|
	+--rw system-management [RFC7317 or derived]		+--rw system-management [RFC7317 or derived]
	+--rw network-services		+--rw network-services
	+--rw oam-protocols		+--rw oam-protocols
	|		|
	+--rw routing [I-D.ietf-netmod-routing-cfg]		+--rw routing [I-D.ietf-netmod-routing-cfg]
	+--rw mpls		+--rw mpls
	+--rw ieee-dot1Q		+--rw ieee-dot1Q
	|		|
	+--rw acls [I-D.ietf-netmod-acl-model]		+--rw acls [I-D.ietf-netmod-acl-model]
	+--rw key-chains [I-D.ietf-rtgwg-yang-key-chain]		+--rw key-chains [I-D.ietf-rtgwg-yang-key-chain]
	|		|
	+--rw logical-network-elements [I-D.rtgyangdt-rtgwg-lne-model]		+--rw logical-network-elements [I-D.ietf-rtgwg-lne-model]
	+--rw network-instances [I-D.rtgyangdt-rtgwg-ni-model]		+--rw network-instances [I-D.ietf-rtgwg-ni-model]
	The network device is composed of top level modules that can be used		The network device is composed of top level modules that can be used
	to configure and operate a network device. (This is a significant		to configure and operate a network device. (This is a significant
	difference from earlier versions of this document where there was a		difference from earlier versions of this document where there was a
	strict model hierarchy.) Importantly the network device structure is		strict model hierarchy.) Importantly the network device structure is
	the same for a physical network device or a logical network device,		the same for a physical network device or a logical network device,
	such as those instantiated via the logical-network-element model.		such as those instantiated via the logical-network-element model.
	Extra spacing is included to denote different types of modules		Extra spacing is included to denote different types of modules
	included.		included.
	YANG library [I-D.ietf-netconf-yang-library] is included as it used		YANG library [RFC7895] is included as it used to identify details of
	to identify details of the top level modules supported by the		the top level modules supported by the (physical or logical) network
	(physical or logical) network device. Th ability to identify		device. Th ability to identify supported modules is particularly
	supported modules is particularly important for LNEs which may have a		important for LNEs which may have a set of supported modules which
	set of supported modules which differs from the set supported by the		differs from the set supported by the host network device.
	host network device.
	The interface management model [RFC7223] is included at the top		The interface management model [RFC7223] is included at the top
	level. The hardware module is a placeholder for a future device-		level. The hardware module is a placeholder for a future device-
	specific configuration and operational state data model. For		specific configuration and operational state data model. For
	example, a common structure for the hardware model might include		example, a common structure for the hardware model might include
	chassis, line cards, and ports, but we leave this unspecified. The		chassis, line cards, and ports, but we leave this unspecified. The
	quality of service (QoS) section is also a placeholder module for		quality of service (QoS) section is also a placeholder module for
	device configuration and operational state data which relates to the		device configuration and operational state data which relates to the
	treatment of traffic across the device. This document references		treatment of traffic across the device. This document references
	augmentations to the interface module to support LNEs and NIs.		augmentations to the interface module to support LNEs and NIs.
	skipping to change at page 8, line 6 ¶		skipping to change at page 7, line 50 ¶
	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].		[RFC7223].
	The logical-network-element and network-instance modules defined in		The logical-network-element and network-instance modules defined in
	[LNE-MODEL] and [NI-MODEL] augment the existing interface management		[I-D.ietf-rtgwg-lne-model] and [I-D.ietf-rtgwg-ni-model] augment the
	model in two ways: The first, by the logical-network-element module,		existing interface management model in two ways: The first, by the
	adds an identifier which is used on physical interface types to		logical-network-element module, adds an identifier which is used on
	identify an associated LNE. The second, by the network-instance		physical interface types to identify an associated LNE. The second,
	module, adds a name which is used on interface or sub-interface types		by the network-instance module, adds a name which is used on
	to identify an associated network instance. Similarly, this name is		interface or sub-interface types to identify an associated network
	also added for IPv4 and IPv6 types, as defined in [RFC7277].		instance. Similarly, this name is also added for IPv4 and IPv6
			types, as defined in [RFC7277].
	The interface related augmentations are as follows:		The interface related augmentations are 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? string		+--rw bind-lne-name? string
	module: ietf-network-instance		module: ietf-network-instance
	augment /if:interfaces/if:interface:		augment /if:interfaces/if:interface:
	+--rw bind-network-instance-name? string		+--rw bind-network-instance-name? string
	skipping to change at page 19, line 42 ¶		skipping to change at page 19, line 42 ¶
	// notification statements		// notification statements
	}		}
	<CODE ENDS>		<CODE ENDS>
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[LNE-MODEL]		[I-D.ietf-rtgwg-lne-model]
	Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,		Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
	"Logical Network Element Model", draft-rtgyangdt-rtgwg-		"Logical Network Element Model", draft-ietf-rtgwg-lne-
	lne-model-00.txt (work in progress), May 2016.		model-00 (work in progress), June 2016.
	[NI-MODEL]		[I-D.ietf-rtgwg-ni-model]
	Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,		Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
	"Network Instance Model", draft-rtgyangdt-rtgwg-ni-model-		"Network Instance Model", draft-ietf-rtgwg-ni-model-00
	00.txt (work in progress), May 2016.		(work in progress), June 2016.
	[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,
	<http://www.rfc-editor.org/info/rfc3688>.		<http://www.rfc-editor.org/info/rfc3688>.
	[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual		[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
	Private Network (VPN) Terminology", RFC 4026,		Private Network (VPN) Terminology", RFC 4026,
	DOI 10.17487/RFC4026, March 2005,		DOI 10.17487/RFC4026, March 2005,
	<http://www.rfc-editor.org/info/rfc4026>.		<http://www.rfc-editor.org/info/rfc4026>.
	skipping to change at page 20, line 33 ¶		skipping to change at page 20, line 33 ¶
	[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",		[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
	RFC 7277, DOI 10.17487/RFC7277, June 2014,		RFC 7277, DOI 10.17487/RFC7277, June 2014,
	<http://www.rfc-editor.org/info/rfc7277>.		<http://www.rfc-editor.org/info/rfc7277>.
	[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, <http://www.rfc-editor.org/info/rfc7317>.		2014, <http://www.rfc-editor.org/info/rfc7317>.
	6.2. Informative References		6.2. Informative References
	[I-D.ietf-netconf-yang-library]		[I-D.ietf-netmod-acl-model]
	Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module		Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
	Library", draft-ietf-netconf-yang-library-05 (work in		"Network Access Control List (ACL) YANG Data Model",
	progress), April 2016.		draft-ietf-netmod-acl-model-09 (work in progress), October
			2016.
	[I-D.ietf-netmod-opstate-reqs]		[I-D.ietf-netmod-opstate-reqs]
	Watsen, K. and T. Nadeau, "Terminology and Requirements		Watsen, K. and T. Nadeau, "Terminology and Requirements
	for Enhanced Handling of Operational State", draft-ietf-		for Enhanced Handling of Operational State", draft-ietf-
	netmod-opstate-reqs-03 (work in progress), January 2016.		netmod-opstate-reqs-04 (work in progress), January 2016.
	[I-D.ietf-netmod-routing-cfg]		[I-D.ietf-netmod-routing-cfg]
	Lhotka, L. and A. Lindem, "A YANG Data Model for Routing		Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
	Management", draft-ietf-netmod-routing-cfg-20 (work in		Management", draft-ietf-netmod-routing-cfg-24 (work in
	progress), October 2015.		progress), October 2016.
			[I-D.ietf-rtgwg-yang-key-chain]
			Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, Z., and Y.
			Yang, "Routing Key Chain YANG Data Model", draft-ietf-
			rtgwg-yang-key-chain-10 (work in progress), October 2016.
	[I-D.openconfig-mpls-consolidated-model]		[I-D.openconfig-mpls-consolidated-model]
	George, J., Fang, L., eric.osborne@level3.com, e., and R.		George, J., Fang, L., eric.osborne@level3.com, e., and R.
	Shakir, "MPLS / TE Model for Service Provider Networks",		Shakir, "MPLS / TE Model for Service Provider Networks",
	draft-openconfig-mpls-consolidated-model-02 (work in		draft-openconfig-mpls-consolidated-model-02 (work in
	progress), October 2015.		progress), October 2015.
	[I-D.openconfig-netmod-model-structure]		[I-D.openconfig-netmod-model-structure]
	Shaikh, A., Shakir, R., D'Souza, K., and L. Fang,		Shaikh, A., Shakir, R., D'Souza, K., and L. Fang,
	"Operational Structure and Organization of YANG Models",		"Operational Structure and Organization of YANG Models",
	skipping to change at page 21, line 21 ¶		skipping to change at page 21, line 27 ¶
	[I-D.openconfig-netmod-opstate]		[I-D.openconfig-netmod-opstate]
	Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling		Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
	of Operational State Data in YANG", draft-openconfig-		of Operational State Data in YANG", draft-openconfig-
	netmod-opstate-01 (work in progress), July 2015.		netmod-opstate-01 (work in progress), July 2015.
	[IEEE-8021Q]		[IEEE-8021Q]
	Holness, M., "IEEE 802.1Q YANG Module Specifications",		Holness, M., "IEEE 802.1Q YANG Module Specifications",
	IEEE-Draft http://www.ieee802.org/1/files/public/docs2015/		IEEE-Draft http://www.ieee802.org/1/files/public/docs2015/
	new-mholness-yang-8021Q-0515-v04.pdf, May 2015.		new-mholness-yang-8021Q-0515-v04.pdf, May 2015.
			[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
			Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
			<http://www.rfc-editor.org/info/rfc7895>.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	This document is derived from draft-openconfig-netmod-model-		This document is derived from draft-openconfig-netmod-model-
	structure-00. We thank the Authors of that document and acknowledge		structure-00. We thank the Authors of that document and acknowledge
	their indirect contribution to this work. The authors include: Anees		their indirect contribution to this work. The authors include: Anees
	Shaikh, Rob Shakir, Kevin D'Souza, Luyuan Fang, Qin Wu, Stephane		Shaikh, Rob Shakir, Kevin D'Souza, Luyuan Fang, Qin Wu, Stephane
	Litkowski and Gang Yan.		Litkowski and Gang Yan.
	This work was discussed in and produced by the Routing Area Yang		This work was discussed in and produced by the Routing Area Yang
	Architecture design team. Members at the time of writing included		Architecture design team. Members at the time of writing included
End of changes. 19 change blocks.
	46 lines changed or deleted		56 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/