< draft-ietf-rtgwg-ni-model-03.txt		draft-ietf-rtgwg-ni-model-04.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: January 4, 2018 Deutsche Telekom		Expires: March 30, 2018 Deutsche Telekom
	A. Lindem		A. Lindem
	Cisco Systems		Cisco Systems
	D. Bogdanovic		D. Bogdanovic
	X. Liu		X. Liu
	Jabil		Jabil
	July 3, 2017		September 26, 2017
	YANG Network Instances		YANG Network Instances
	draft-ietf-rtgwg-ni-model-03		draft-ietf-rtgwg-ni-model-04
	Abstract		Abstract
	This document defines a network instance module. This module can be		This document defines a network instance module. This module can be
	used to manage the virtual resource partitioning that may be present		used to manage the virtual resource partitioning that may be present
	on a network device. Examples of common industry terms for virtual		on a network device. Examples of common industry terms for virtual
	resource partitioning are Virtual Routing and Forwarding (VRF)		resource partitioning are Virtual Routing and Forwarding (VRF)
	instances and Virtual Switch Instances (VSIs).		instances and Virtual Switch Instances (VSIs).
	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 January 4, 2018.		This Internet-Draft will expire on March 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	1.2. Status of Work and Open Issues . . . . . . . . . . . . . 3		1.2. Status of Work and Open Issues . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5		3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6		3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6
	3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7		3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7
	3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8		3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8
	3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9		3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
	3.3. Network Instance Management . . . . . . . . . . . . . . . 11		3.3. Network Instance Management . . . . . . . . . . . . . . . 11
	3.4. Network Instance Instantiation . . . . . . . . . . . . . 13		3.4. Network Instance Instantiation . . . . . . . . . . . . . 13
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 13		4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14		6. Network Instance Model . . . . . . . . . . . . . . . . . . . 15
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Normative References . . . . . . . . . . . . . . . . . . 20		7.1. Normative References . . . . . . . . . . . . . . . . . . 21
	7.2. Informative References . . . . . . . . . . . . . . . . . 21		7.2. Informative References . . . . . . . . . . . . . . . . . 22
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23
	Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 22		Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23
	B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 22		B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23
	B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 25		B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	This document defines the second of two new modules that are defined		This document defines the second of two new modules that are defined
	to support the configuration and operation of network-devices that		to support the configuration and operation of network-devices that
	allow for the partitioning of resources from both, or either,		allow for the partitioning of resources from both, or either,
	management and networking perspectives. Both leverage the YANG		management and networking perspectives. Both leverage the YANG
	functionality enabled by YANG Schema Mount		functionality enabled by YANG Schema Mount
	[I-D.ietf-netmod-schema-mount].		[I-D.ietf-netmod-schema-mount].
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 12 ¶
	The NI model can be represented using the tree format defined in		The NI model can be represented using the tree format defined in
	[I-D.ietf-netmod-yang-tree-diagrams] as:		[I-D.ietf-netmod-yang-tree-diagrams] as:
	module: ietf-network-instance		module: ietf-network-instance
	+--rw network-instances		+--rw network-instances
	+--rw network-instance* [name]		+--rw network-instance* [name]
	+--rw name string		+--rw name string
	+--rw enabled? boolean		+--rw enabled? boolean
	+--rw description? string		+--rw description? string
	+--rw (ni-type)?		+--rw (ni-type)?
	+--rw (root-type)?		+--rw (root-type)
	+--:(vrf-root)		+--:(vrf-root)
	| +--mp vrf-root?		| +--mp vrf-root
	+--:(vsi-root)		+--:(vsi-root)
	| +--mp vsi-root?		| +--mp vsi-root
	+--:(vv-root)		+--:(vv-root)
	+--mp vv-root?		+--mp vv-root
	augment /if:interfaces/if:interface:		augment /if:interfaces/if:interface:
	+--rw bind-ni-name? -> /network-instances/network-instance/name		+--rw bind-ni-name? -> /network-instances/network-instance/name
	augment /if:interfaces/if:interface/ip:ipv4:		augment /if:interfaces/if:interface/ip:ipv4:
	+--rw bind-ni-name? -> /network-instances/network-instance/name		+--rw bind-ni-name? -> /network-instances/network-instance/name
	augment /if:interfaces/if:interface/ip:ipv6:		augment /if:interfaces/if:interface/ip:ipv6:
	+--rw bind-ni-name? -> /network-instances/network-instance/name		+--rw bind-ni-name? -> /network-instances/network-instance/name
	notifications:		notifications:
	+---n bind-ni-name-failed		+---n bind-ni-name-failed
	+--ro name -> /if:interfaces/interface/name		+--ro name -> /if:interfaces/interface/name
	skipping to change at page 9, line 17 ¶		skipping to change at page 9, line 17 ¶
	+--rw network-instance* [name]		+--rw network-instance* [name]
	+--rw name string		+--rw name string
	+--rw enabled? boolean		+--rw enabled? boolean
	+--rw description? string		+--rw description? string
	+--rw (ni-type)?		+--rw (ni-type)?
	| +--:(l3vpn)		| +--:(l3vpn)
	| +--rw l3vpn:l3vpn		| +--rw l3vpn:l3vpn
	| | ... // config data		| | ... // config data
	| +--ro l3vpn:l3vpn-state		| +--ro l3vpn:l3vpn-state
	| | ... // state data		| | ... // state data
	+--rw (root-type)?		+--rw (root-type)
	+--:(vrf-root)		+--:(vrf-root)
	+--mp vrf-root		+--mp vrf-root
	+--ro rt:routing-state/		+--ro rt:routing-state/
	| +--ro router-id? yang:dotted-quad		| +--ro router-id? yang:dotted-quad
	| +--ro control-plane-protocols		| +--ro control-plane-protocols
	| +--ro control-plane-protocol* [type name]		| +--ro control-plane-protocol* [type name]
	| +--ro ospf:ospf/		| +--ro ospf:ospf/
	| +--ro instance* [af]		| +--ro instance* [af]
	+--rw rt:routing/		+--rw rt:routing/
	| +--rw router-id? yang:dotted-quad		| +--rw router-id? yang:dotted-quad
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 15 ¶
	3.3. Network Instance Management		3.3. Network Instance Management
	Modules that may be used to represent network instance information		Modules that may be used to represent network instance information
	will be available under the ni-type specific 'root' mount point. The		will be available under the ni-type specific 'root' mount point. The
	use-schema mechanism defined as part of the Schema Mount module		use-schema mechanism defined as part of the Schema Mount module
	[I-D.ietf-netmod-schema-mount] MUST be used with the module defined		[I-D.ietf-netmod-schema-mount] MUST be used with the module defined
	in this document to identify accessible modules. A future version of		in this document to identify accessible modules. A future version of
	this document could relax this requirement. Mounted modules in the		this document could relax this requirement. Mounted modules in the
	non-inline case SHOULD be defined with access, via the appropriate		non-inline case SHOULD be defined with access, via the appropriate
	schema mount parent-references [I-D.ietf-netmod-schema-mount], to		schema mount parent-references [I-D.ietf-netmod-schema-mount], to
	device resources such as interfaces.		device resources such as interfaces. An implementation MAY choose to
			restrict parent referenced information to information related to a
			specific instance, e.g., only allowing references to interfaces that
			have a "bind-network-instance-name" which is identical to the
			instance's "name".
	All modules that represent control-plane and data-plane information		All modules that represent control-plane and data-plane information
	may be present at the 'root' mount point, and be accessible via paths		may be present at the 'root' mount point, and be accessible via paths
	modified per [I-D.ietf-netmod-schema-mount]. The list of available		modified per [I-D.ietf-netmod-schema-mount]. The list of available
	modules is expected to be implementation dependent, as is the method		modules is expected to be implementation dependent, as is the method
	used by an implementation to support NIs.		used by an implementation to support NIs.
	For example, the following could be used to define the data		For example, the following could be used to define the data
	organization of the example NI shown in Section 3.1.2:		organization of the example NI shown in Section 3.1.2:
	skipping to change at page 13, line 5 ¶		skipping to change at page 12, line 50 ¶
	]		]
	}		}
	Module data identified under "schema" will be instantiated under the		Module data identified under "schema" will be instantiated under the
	mount point identified under "mount-point". These modules will be		mount point identified under "mount-point". These modules will be
	able to reference information for nodes belonging to top-level		able to reference information for nodes belonging to top-level
	modules that are identified under "parent-reference". Parent		modules that are identified under "parent-reference". Parent
	referenced information is available to clients via their top level		referenced information is available to clients via their top level
	paths only, and not under the associated mount point.		paths only, and not under the associated mount point.
			To allow a client to understand the previously mentioned instance
			restrictions on parent referenced information, an implementation MAY
			represent such restrictions in the "parent-reference" leaf-list. For
			example:
			"namespace": [
			{
			"prefix": "if",
			"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
			},
			{
			"prefix": "ni",
			"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
			}
			],
			"mount-point": [
			{
			"parent-reference": [
			"/if:interfaces/if:interface
			[ni:bind-network-instance-name = current()/../ni:name]",
			"/if:interfaces-state/if:interface
			[if:name = /if:interfaces/if:interface
			[ni:bind-ni-name = current()/../ni:name]/if:name]",
			"/if:interfaces/if:interface/ip:ipv4
			[ni:bind-network-instance-name = current()/../ni:name]",
			"/if:interfaces-state/if:interface/ip:ipv4
			[if:name = /if:interfaces/if:interface/ip:ipv4
			[ni:bind-ni-name = current()/../ni:name]/if:name]",
			"/if:interfaces/if:interface/ip:ipv6
			[ni:bind-network-instance-name = current()/../ni:name]",
			"/if:interfaces-state/if:interface/ip:ipv6
			[if:name = /if:interfaces/if:interface/ip:ipv4
			[ni:bind-ni-name = current()/../ni:name]/if:name]",
			]
			}
			],
	3.4. Network Instance Instantiation		3.4. Network Instance Instantiation
	Network instances may be controlled by clients using existing list		Network instances may be controlled by clients using existing list
	operations. When a list entry is created, a new instance is		operations. When a list entry is created, a new instance is
	instantiated. The models mounted under an NI root are expected to be		instantiated. The models mounted under an NI root are expected to be
	dependent on the server implementation. When a list entry is		dependent on the server implementation. When a list entry is
	deleted, an existing network instance is destroyed. For more		deleted, an existing network instance is destroyed. For more
	information, see [RFC7950] Section 7.8.6.		information, see [RFC7950] Section 7.8.6.
	Once instantiated, host network device resources can be associated		Once instantiated, host network device resources can be associated
	skipping to change at page 14, line 35 ¶		skipping to change at page 15, line 24 ¶
	name: ietf-network-instance		name: ietf-network-instance
	namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance		namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
	prefix: ni		prefix: ni
	reference: RFC XXXX		reference: RFC XXXX
	6. Network Instance Model		6. Network Instance 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-network-instance@2017-07-03.yang"		<CODE BEGINS> file "ietf-network-instance@2017-09-27.yang"
	module ietf-network-instance {		module ietf-network-instance {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";		namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";
	prefix ni;		prefix ni;
	// import some basic types		// import some basic types
	import ietf-interfaces {		import ietf-interfaces {
	prefix if;		prefix if;
	reference "RFC 7223: A YANG Data Model for Interface		reference "RFC 7223: A YANG Data Model for Interface
	skipping to change at page 15, line 47 ¶		skipping to change at page 16, line 35 ¶
	Relating to IETF Documents		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 2017-07-02 {		revision 2017-09-27 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference "RFC TBD";		reference "RFC TBD";
	}		}
	// top level device definition statements		// top level device definition statements
	container network-instances {		container network-instances {
	description		description
	"Network instances each of which consists of a		"Network instances each of which consists of a
	VRFs (virtual routing and forwarding) and/or		VRFs (virtual routing and forwarding) and/or
	VSIs (virtual switching instances).";		VSIs (virtual switching instances).";
	reference "RFC 8022 - A YANG Data Model for Routing		reference "RFC 8022 - A YANG Data Model for Routing
	Management";		Management";
	list network-instance {		list network-instance {
	key "name";		key "name";
	description		description
	"List of network-instances.";		"List of network-instances.";
	leaf name {		leaf name {
	type string;		type string;
			mandatory true;
	description		description
	"device scoped identifier for the network		"device scoped identifier for the network
	instance.";		instance.";
	}		}
	leaf enabled {		leaf enabled {
	type boolean;		type boolean;
	default "true";		default "true";
	description		description
	"Flag indicating whether or not the network		"Flag indicating whether or not the network
	instance is enabled.";		instance is enabled.";
	skipping to change at page 16, line 47 ¶		skipping to change at page 17, line 37 ¶
	description		description
	"This node serves as an anchor point for different types		"This node serves as an anchor point for different types
	of network instances. Each 'case' is expected to		of network instances. Each 'case' is expected to
	differ in terms of the information needed in the		differ in terms of the information needed in the
	parent/core to support the NI, and may differ in their		parent/core to support the NI, and may differ in their
	mounted schema definition. When the mounted schema is		mounted schema definition. When the mounted schema is
	not expected to be the same for a specific type of NI		not expected to be the same for a specific type of NI
	a mount point should be defined.";		a mount point should be defined.";
	}		}
	choice root-type {		choice root-type {
			mandatory true;
	description		description
	"Well known mount points.";		"Well known mount points.";
	yangmnt:mount-point "vrf-root" {		container vrf-root {
	description		description
	"Root for L3VPN type models. This will typically		"Container for mount point.";
	not be an inline type mount point.";		yangmnt:mount-point "vrf-root" {
			description
			"Root for L3VPN type models. This will typically
			not be an inline type mount point.";
			}
	}		}
	yangmnt:mount-point "vsi-root" {		container vsi-root {
	description		description
	"Root for L2VPN type models. This will typically		"Container for mount point.";
	not be an inline type mount point.";
			yangmnt:mount-point "vsi-root" {
			description
			"Root for L2VPN type models. This will typically
			not be an inline type mount point.";
			}
	}		}
	yangmnt:mount-point "vv-root" {		container vv-root {
	description		description
	"Root models that support both L2VPN type bridging		"Container for mount point.";
	and L3VPN type routing. This will typically		yangmnt:mount-point "vv-root" {
	not be an inline type mount point.";		description
			"Root models that support both L2VPN type bridging
			and L3VPN type routing. This will typically
			not be an inline type mount point.";
			}
	}		}
	}		}
	}		}
	}		}
	// augment statements		// augment statements
	augment "/if:interfaces/if:interface" {		augment "/if:interfaces/if:interface" {
	description		description
	"Add a node for the identification of the network		"Add a node for the identification of the network
	skipping to change at page 19, line 51 ¶		skipping to change at page 21, line 4 ¶
	"IPv6 interface type.";		"IPv6 interface type.";
	leaf bind-ni-name {		leaf bind-ni-name {
	type leafref {		type leafref {
	path "/if:interfaces/if:interface"		path "/if:interfaces/if:interface"
	+ "/ip:ipv6/ni:bind-ni-name";		+ "/ip:ipv6/ni:bind-ni-name";
	}		}
	description		description
	"Contains the bind-ni-name associated with the		"Contains the bind-ni-name associated with the
	failure.";		failure.";
	}		}
	}		}
	leaf error-info {		leaf error-info {
	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-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-05 (work in progress), May 2017.		ietf-netmod-schema-mount-06 (work in progress), July 2017.
	[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-01 (work in progress), June		ietf-netmod-yang-tree-diagrams-01 (work in progress), June
	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,
	<http://www.rfc-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,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[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,
	<http://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,		Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
	<http://www.rfc-editor.org/info/rfc7223>.		<https://www.rfc-editor.org/info/rfc7223>.
	[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>.		<https://www.rfc-editor.org/info/rfc7277>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-bess-l2vpn-yang]		[I-D.ietf-bess-l2vpn-yang]
	Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,		Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
	and K. Tiruveedhula, "YANG Data Model for MPLS-based		and K. Tiruveedhula, "YANG Data Model for MPLS-based
	L2VPN", draft-ietf-bess-l2vpn-yang-05 (work in progress),		L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress),
	March 2017.		June 2017.
	[I-D.ietf-bess-l3vpn-yang]		[I-D.ietf-bess-l3vpn-yang]
	Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,		Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
	Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model		Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
	for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-01 (work		for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-01 (work
	in progress), April 2017.		in progress), April 2017.
	[I-D.ietf-ospf-yang]		[I-D.ietf-ospf-yang]
	Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,		Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
	"Yang Data Model for OSPF Protocol", draft-ietf-ospf-		"Yang Data Model for OSPF Protocol", draft-ietf-ospf-
	yang-08 (work in progress), July 2017.		yang-08 (work in progress), July 2017.
	[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-lne-model]		[I-D.ietf-rtgwg-lne-model]
	Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,		Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
	"YANG Logical Network Elements", draft-ietf-rtgwg-lne-		Liu, "YANG Logical Network Elements", draft-ietf-rtgwg-
	model-02 (work in progress), March 2017.		lne-model-03 (work in progress), July 2017.
	[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>.		<https://www.rfc-editor.org/info/rfc4026>.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <http://www.rfc-editor.org/info/rfc4364>.		2006, <https://www.rfc-editor.org/info/rfc4364>.
	[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer		[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
	2 Virtual Private Networks (L2VPNs)", RFC 4664,		2 Virtual Private Networks (L2VPNs)", RFC 4664,
	DOI 10.17487/RFC4664, September 2006,		DOI 10.17487/RFC4664, September 2006,
	<http://www.rfc-editor.org/info/rfc4664>.		<https://www.rfc-editor.org/info/rfc4664>.
	[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,
	<http://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		[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
	Management", RFC 8022, DOI 10.17487/RFC8022, November		Management", RFC 8022, DOI 10.17487/RFC8022, November
	2016, <http://www.rfc-editor.org/info/rfc8022>.		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].
End of changes. 40 change blocks.
	50 lines changed or deleted		108 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/