< draft-ietf-rtgwg-ni-model-06.txt		draft-ietf-rtgwg-ni-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: July 20, 2018 Deutsche Telekom		Expires: August 7, 2018 Deutsche Telekom
	A. Lindem		A. Lindem
	Cisco Systems		Cisco Systems
	D. Bogdanovic		D. Bogdanovic
	X. Liu		X. Liu
	Jabil		Jabil
	January 16, 2018		February 3, 2018
	YANG Network Instances		YANG Network Instances
	draft-ietf-rtgwg-ni-model-06		draft-ietf-rtgwg-ni-model-07
	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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 July 20, 2018.		This Internet-Draft will expire on August 7, 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		(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 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	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 . . . . . . . . . . . . . . . 10
	3.4. Network Instance Instantiation . . . . . . . . . . . . . 13		3.4. Network Instance Instantiation . . . . . . . . . . . . . 12
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 14		4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6. Network Instance Model . . . . . . . . . . . . . . . . . . . 15		6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1. Normative References . . . . . . . . . . . . . . . . . . 21		7.1. Normative References . . . . . . . . . . . . . . . . . . 20
	7.2. Informative References . . . . . . . . . . . . . . . . . 22		7.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23
	Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23		Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23
	B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23		B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23
	B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26		B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	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
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 42 ¶
	| | | | | | | | | | | | | |		| | | | | | | | | | | | | |
	`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''		`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
	| | | | | | | | | | | |		| | | | | | | | | | | |
	Interfaces Interfaces		Interfaces Interfaces
	Figure 1: Module Element Relationships		Figure 1: Module Element Relationships
	A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the		A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the
	model for NIs is covered in this document in Section 3.		model for NIs is covered in this document in Section 3.
	The current interface management model [RFC7223] is impacted by the		The current interface management model [I-D.ietf-netmod-rfc7223bis]
	definition of LNEs and NIs. This document and		is impacted by the definition of LNEs and NIs. This document and
	[I-D.ietf-rtgwg-lne-model] define augmentations to the interface		[I-D.ietf-rtgwg-lne-model] define augmentations to the interface
	module to support LNEs and NIs.		module to support LNEs and NIs.
	The network instance model supports the configuration of VRFs and		The network instance model supports the configuration of VRFs and
	VSIs. Each instance is supported by information that relates to the		VSIs. Each instance is supported by information that relates to the
	device, for example the route target used when advertising VRF routes		device, for example the route target used when advertising VRF routes
	via the mechanisms defined in [RFC4364], and information that relates		via the mechanisms defined in [RFC4364], and information that relates
	to the internal operation of the NI, for example for routing		to the internal operation of the NI, for example for routing
	protocols [RFC8022] and OSPF [I-D.ietf-ospf-yang]. This document		protocols [I-D.ietf-netmod-rfc8022bis] and OSPF [I-D.ietf-ospf-yang].
	defines the network-instance module that provides a basis for the		This document defines the network-instance module that provides a
	management of both types of information.		basis for the management of both types of information.
	NI information that relates to the device, including the assignment		NI information that relates to the device, including the assignment
	of interfaces to NIs, is defined as part of this document. The		of interfaces to NIs, is defined as part of this document. The
	defined module also provides a placeholder for the definition of NI-		defined module also provides a placeholder for the definition of NI-
	technology specific information both at the device level and for NI		technology specific information both at the device level and for NI
	internal operation. Information related to NI internal operation is		internal operation. Information related to NI internal operation is
	supported via schema mount [I-D.ietf-netmod-schema-mount] and		supported via schema mount [I-D.ietf-netmod-schema-mount] and
	mounting appropriate modules under the mount point. Well known mount		mounting appropriate modules under the mount point. Well known mount
	points are defined for L3VPN, L2VPN, and L2+L3VPN NI types.		points are defined for L3VPN, L2VPN, and L2+L3VPN NI types.
	skipping to change at page 9, line 20 ¶		skipping to change at page 8, line 38 ¶
	+--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 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
	+--ro if:interfaces@		+--ro if:interfaces@
	| ...		| ...
	+--ro if:interfaces-state@
	| ...
	This shows YANG Routing Management [RFC8022] and YANG OSPF		This shows YANG Routing Management [I-D.ietf-netmod-rfc8022bis] and
	[I-D.ietf-ospf-yang] as mounted modules. The mounted modules can		YANG OSPF [I-D.ietf-ospf-yang] as mounted modules. The mounted
	reference interface information via a parent-reference to the		modules can reference interface information via a parent-reference to
	containers defined in [RFC7223].		the containers defined in [I-D.ietf-netmod-rfc7223bis].
	3.2. NIs and Interfaces		3.2. NIs and Interfaces
	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].		[I-D.ietf-netmod-rfc7223bis].
	As shown below, the network-instance module augments the existing		As shown below, the network-instance module augments the existing
	interface management model by adding a name which is used on		interface management model by adding a name which is used on
	interface or sub-interface types to identify an associated network		interface or sub-interface types to identify an associated network
	instance. Similarly, this name is also added for IPv4 and IPv6		instance. Similarly, this name is also added for IPv4 and IPv6
	types, as defined in [RFC7277].		types, as defined in [I-D.ietf-netmod-rfc7277bis].
	The following is an example of envisioned usage. The interfaces		The following is an example of envisioned usage. The interfaces
	container includes a number of commonly used components as examples:		container includes a number of commonly used components as examples:
	module: ietf-interfaces		module: ietf-interfaces
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		| +--rw interface* [name]
	| +--rw name string		| +--rw name string
	| +--rw ip:ipv4!		| +--rw ip:ipv4!
	| | +--rw ip:enabled? boolean		| | +--rw ip:enabled? boolean
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 5 ¶
	| | | +--:(ip:prefix-length)		| | | +--:(ip:prefix-length)
	| | | | +--rw ip:prefix-length? uint8		| | | | +--rw ip:prefix-length? uint8
	| | | +--:(ip:netmask)		| | | +--:(ip:netmask)
	| | | +--rw ip:netmask? yang:dotted-quad		| | | +--rw ip:netmask? yang:dotted-quad
	| | +--rw ip:neighbor* [ip]		| | +--rw ip:neighbor* [ip]
	| | | +--rw ip:ip inet:ipv4-address-no-zone		| | | +--rw ip:ip inet:ipv4-address-no-zone
	| | | +--rw ip:link-layer-address yang:phys-address		| | | +--rw ip:link-layer-address yang:phys-address
	| | +--rw ni:bind-network-instance-name? string		| | +--rw ni:bind-network-instance-name? string
	| +--rw ni:bind-network-instance-name? string		| +--rw ni:bind-network-instance-name? string
	The [RFC7223] defined interface model is structured to include all		The [I-D.ietf-netmod-rfc7223bis] defined interface model is
	interfaces in a flat list, without regard to virtual instances (e.g.,		structured to include all interfaces in a flat list, without regard
	VRFs) supported on the device. The bind-network-instance-name leaf		to virtual instances (e.g., VRFs) supported on the device. The bind-
	provides the association between an interface and its associated NI		network-instance-name leaf provides the association between an
	(e.g., VRF or VSI). Note that as currently defined, to assign an		interface and its associated NI (e.g., VRF or VSI). Note that as
	interface to both an LNE and NI, the interface would first be		currently defined, to assign an interface to both an LNE and NI, the
	assigned to the LNE using the mechanisms defined in		interface would first be assigned to the LNE using the mechanisms
	[I-D.ietf-rtgwg-lne-model] and then within that LNE's interface		defined in [I-D.ietf-rtgwg-lne-model] and then within that LNE's
	module, the LNE's representation of that interface would be assigned		interface module, the LNE's representation of that interface would be
	to an NI.		assigned to an NI.
	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
	skipping to change at page 12, line 26 ¶		skipping to change at page 11, line 26 ¶
	}		}
	]		]
	}		}
	],		],
	"schema": [		"schema": [
	{		{
	"name": "ni-schema",		"name": "ni-schema",
	"module": [		"module": [
	{		{
	"name": "ietf-routing",		"name": "ietf-routing",
	"revision": "2016-11-04",		"revision": "2018-01-25",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-routing",		"urn:ietf:params:xml:ns:yang:ietf-routing",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-ospf",		"name": "ietf-ospf",
	"revision": "2017-03-12",		"revision": "2017-10-30",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-ospf",		"urn:ietf:params:xml:ns:yang:ietf-ospf",
	"conformance-type": "implement"		"conformance-type": "implement"
	}		}
	]		]
	}		}
	]		]
	}		}
	Module data identified under "schema" will be instantiated under the		Module data identified under "schema" will be instantiated under the
	skipping to change at page 14, line 13 ¶		skipping to change at page 13, line 13 ¶
	associations for interfaces. When a bind-ni-name is set to a valid		associations for interfaces. When a bind-ni-name is set to a valid
	NI name, an implementation MUST take whatever steps are internally		NI name, an implementation MUST take whatever steps are internally
	necessary to assign the interface to the NI or provide an error		necessary to assign the interface to the NI or provide an error
	message (defined below) with an indication of why the assignment		message (defined below) with an indication of why the assignment
	failed. It is possible for the assignment to fail while processing		failed. It is possible for the assignment to fail while processing
	the set operation, or after asynchronous processing. Error		the set operation, or after asynchronous processing. Error
	notification in the latter case is supported via a notification.		notification in the latter case is supported via a notification.
	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.
	There are two different sets of security considerations to consider		There are two different sets of security considerations to consider
	in the context of this document. One set is security related to		in the context of this document. One set is security related to
	information contained within mounted modules. The security		information contained within mounted modules. The security
	considerations for mounted modules are not substantively changed		considerations for mounted modules are not substantively changed
	based on the information being accessible within the context of an		based on the information being accessible within the context of an
	NI. For example, when considering the modules defined in [RFC8022],		NI. For example, when considering the modules defined in
	the security considerations identified in that document are equally		[I-D.ietf-netmod-rfc8022bis], the security considerations identified
	applicable, whether those modules are accessed at a server's root or		in that document are equally applicable, whether those modules are
	under an NI instance's root node.		accessed at a server's root or under an NI instance's root node.
	The second area for consideration is information contained in the NI		The second area for consideration is information contained in the NI
	module itself. NI information represents network configuration and		module itself. NI information represents network configuration and
	route distribution policy information. As such, the security of this		route distribution policy information. As such, the security of this
	information is important, but it is fundamentally no different than		information is important, but it is fundamentally no different than
	any other interface or routing configuration information that has		any other interface or routing configuration information that has
	already been covered in [RFC7223] and [RFC8022].		already been covered in [I-D.ietf-netmod-rfc7223bis] 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:
	/network-instances/network-instance: This list specifies the network		/network-instances/network-instance: This list specifies the network
	instances and the related control plane protocols configured on a		instances and the related control plane protocols configured on a
	device.		device.
	/if:interfaces/if:interface/*/bind-network-instance-name: This leaf		/if:interfaces/if:interface/*/bind-network-instance-name: This leaf
	indicates the NI instance to which an interface is assigned.		indicates the NI instance to which an interface is assigned.
	skipping to change at page 15, line 24 ¶		skipping to change at page 14, line 38 ¶
	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-12-04.yang"		<CODE BEGINS> file "ietf-network-instance@2018-02-03.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 "draft-ietf-netmod-rfc7223bis: A YANG Data Model
	Management";		for Interface Management";
	}		}
	import ietf-ip {		import ietf-ip {
	prefix ip;		prefix ip;
	reference "RFC 7277: A YANG Data Model for IP Management";		reference "draft-ietf-netmod-rfc7277bis: A YANG Data Model
			for IP Management";
	}		}
	import ietf-yang-schema-mount {		import ietf-yang-schema-mount {
	prefix yangmnt;		prefix yangmnt;
	reference "draft-ietf-netmod-schema-mount: YANG Schema Mount";		reference "draft-ietf-netmod-schema-mount: YANG Schema Mount";
	// RFC Ed.: Please replace this draft name with the		// RFC Ed.: Please replace this draft name with the
	// corresponding RFC number		// corresponding RFC number
	}		}
	organization		organization
	"IETF Routing Area (rtgwg) Working Group";		"IETF Routing Area (rtgwg) Working Group";
	skipping to change at page 16, line 35 ¶		skipping to change at page 15, line 51 ¶
	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-12-04 {		revision 2018-02-03 {
	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 "draft-ietf-rtgwg-rfc8022bis - A YANG Data Model
	Management";		for Routing 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;		mandatory true;
	description		description
	"device scoped identifier for the network		"device scoped identifier for the network
	instance.";		instance.";
	skipping to change at page 21, line 4 ¶		skipping to change at page 20, line 23 ¶
	"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-rfc7223bis]
			Bjorklund, M., "A YANG Data Model for Interface
			Management", draft-ietf-netmod-rfc7223bis-03 (work in
			progress), January 2018.
			[I-D.ietf-netmod-rfc7277bis]
			Bjorklund, M., "A YANG Data Model for IP Management",
			draft-ietf-netmod-rfc7277bis-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.
	[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-04 (work in progress),		ietf-netmod-yang-tree-diagrams-05 (work in progress),
	December 2017.		January 2018.
	[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, <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, <https://www.rfc-		DOI 10.17487/RFC3688, January 2004, <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, <https://www.rfc-		DOI 10.17487/RFC6020, October 2010, <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>.
	[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	RFC 7277, DOI 10.17487/RFC7277, June 2014,		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc7277>.		<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>.
	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-07 (work in progress),		L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress),
	October 2017.		October 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-02 (work		for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-02 (work
	in progress), October 2017.		in progress), October 2017.
			[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-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-09 (work in progress), October 2017.		yang-09 (work in progress), October 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.
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 9 ¶
	[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, <https://www.rfc-		DOI 10.17487/RFC4664, September 2006, <https://www.rfc-
	editor.org/info/rfc4664>.		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,
	<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].
			Thanks for AD and IETF last call comments from Alia Atlas and Liang
			Xia.
	The RFC text was produced using Marshall Rose's xml2rfc tool.		The RFC text was produced using Marshall Rose's xml2rfc tool.
	Appendix B. Example NI usage		Appendix B. Example NI usage
	The following subsections provide example uses of NIs.		The following subsections provide example uses of NIs.
	B.1. Configuration Data		B.1. Configuration Data
	The following shows an example where two customer specific network		The following shows an example where two customer specific network
	instances are configured:		instances are configured:
End of changes. 33 change blocks.
	67 lines changed or deleted		102 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/