draft-ietf-netmod-routing-cfg-15.txt		draft-ietf-netmod-routing-cfg-16.txt
	NETMOD L. Lhotka		NETMOD Working Group L. Lhotka
	Internet-Draft CZ.NIC		Internet-Draft CZ.NIC
	Intended status: Standards Track May 25, 2014		Intended status: Standards Track October 26, 2014
	Expires: November 26, 2014		Expires: April 29, 2015
	A YANG Data Model for Routing Management		A YANG Data Model for Routing Management
	draft-ietf-netmod-routing-cfg-15		draft-ietf-netmod-routing-cfg-16
	Abstract		Abstract
	This document contains a specification of three YANG modules.		This document contains a specification of three YANG modules.
	Together they form the core routing data model which serves as a		Together they form the core routing data model which serves as a
	framework for configuring and managing a routing subsystem. It is		framework for configuring and managing a routing subsystem. It is
	expected that these modules will be augmented by additional YANG		expected that these modules will be augmented by additional YANG
	modules defining data models for individual routing protocols and		modules defining data models for routing protocols and other
	other related functions. The core routing data model provides common		functions. The core routing data model provides common building
	building blocks for such extensions - routing instances, routes,		blocks for such extensions - routing instances, routes, routing
	routing information bases (RIB), routing protocols and route filters.		information bases (RIB), routing protocols and route filters.
	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 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 November 26, 2014.		This Internet-Draft will expire on April 29, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
	2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5		2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4
	2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6		2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
	3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. The Design of the Core Routing Data Model . . . . . . . . . . 9		4. The Design of the Core Routing Data Model . . . . . . . . . . 6
	4.1. System-Controlled and User-Controlled List Entries . . . . 12		4.1. System-Controlled and User-Controlled List Entries . . . 10
	4.2. Features of Advanced Routers . . . . . . . . . . . . . . . 13		4.2. Features of Advanced Routers . . . . . . . . . . . . . . 10
	5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 14		5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 11
	5.1. Routing Instance . . . . . . . . . . . . . . . . . . . . . 14		5.1. Routing Instance . . . . . . . . . . . . . . . . . . . . 11
	5.1.1. Parameters of IPv6 Routing Instance Interfaces . . . . 15		5.1.1. Parameters of IPv6 Routing Instance Interfaces . . . 12
	5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Routing Information Base (RIB) . . . . . . . . . . . . . . 16		5.3. Routing Information Base (RIB) . . . . . . . . . . . . . 14
	5.3.1. Multiple RIBs per Address Family . . . . . . . . . . . 17		5.3.1. Multiple RIBs per Address Family . . . . . . . . . . 15
	5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . . 17		5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 15
	5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 18		5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 16
	5.4.2. Defining New Routing Protocols . . . . . . . . . . . . 20		5.4.2. Defining New Routing Protocols . . . . . . . . . . . 18
	5.5. Route Filter . . . . . . . . . . . . . . . . . . . . . . . 21		5.5. Route Filter . . . . . . . . . . . . . . . . . . . . . . 19
	5.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 22		5.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . 20
	6. Interactions with Other YANG Modules . . . . . . . . . . . . . 23		6. Interactions with Other YANG Modules . . . . . . . . . . . . 20
	6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 23		6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 20
	6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 23		6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 20
	7. Routing Management YANG Module . . . . . . . . . . . . . . . . 25		7. Routing Management YANG Module . . . . . . . . . . . . . . . 21
	8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 47		8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 44
	9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 54		9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 49
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 71		11. Security Considerations . . . . . . . . . . . . . . . . . . . 64
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 73		13.1. Normative References . . . . . . . . . . . . . . . . . . 65
	13.2. Informative References . . . . . . . . . . . . . . . . . . 73		13.2. Informative References . . . . . . . . . . . . . . . . . 66
	Appendix A. The Complete Data Trees . . . . . . . . . . . . . . . 74		Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 66
	A.1. Configuration Data . . . . . . . . . . . . . . . . . . . . 74		A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 66
	A.2. Operational State Data . . . . . . . . . . . . . . . . . . 76		A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 69
	Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 78		Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 71
	Appendix C. Example: Adding a New Routing Protocol . . . . . . . 79		Appendix C. Example: Adding a New Routing Protocol . . . . . . . 72
	Appendix D. Example: NETCONF <get> Reply . . . . . . . . . . . . 82		Appendix D. Example: NETCONF <get> Reply . . . . . . . . . . . . 74
	Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 89		Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 81
	E.1. Changes Between Versions -14 and -15 . . . . . . . . . . . 89		E.1. Changes Between Versions -15 and -16 . . . . . . . . . . 81
	E.2. Changes Between Versions -13 and -14 . . . . . . . . . . . 89		E.2. Changes Between Versions -14 and -15 . . . . . . . . . . 82
	E.3. Changes Between Versions -12 and -13 . . . . . . . . . . . 89		E.3. Changes Between Versions -13 and -14 . . . . . . . . . . 82
	E.4. Changes Between Versions -11 and -12 . . . . . . . . . . . 90		E.4. Changes Between Versions -12 and -13 . . . . . . . . . . 82
	E.5. Changes Between Versions -10 and -11 . . . . . . . . . . . 90		E.5. Changes Between Versions -11 and -12 . . . . . . . . . . 83
	E.6. Changes Between Versions -09 and -10 . . . . . . . . . . . 90		E.6. Changes Between Versions -10 and -11 . . . . . . . . . . 83
	E.7. Changes Between Versions -08 and -09 . . . . . . . . . . . 91		E.7. Changes Between Versions -09 and -10 . . . . . . . . . . 84
	E.8. Changes Between Versions -07 and -08 . . . . . . . . . . . 91		E.8. Changes Between Versions -08 and -09 . . . . . . . . . . 84
	E.9. Changes Between Versions -06 and -07 . . . . . . . . . . . 91		E.9. Changes Between Versions -07 and -08 . . . . . . . . . . 84
	E.10. Changes Between Versions -05 and -06 . . . . . . . . . . . 91		E.10. Changes Between Versions -06 and -07 . . . . . . . . . . 84
	E.11. Changes Between Versions -04 and -05 . . . . . . . . . . . 92		E.11. Changes Between Versions -05 and -06 . . . . . . . . . . 85
	E.12. Changes Between Versions -03 and -04 . . . . . . . . . . . 93		E.12. Changes Between Versions -04 and -05 . . . . . . . . . . 85
	E.13. Changes Between Versions -02 and -03 . . . . . . . . . . . 93		E.13. Changes Between Versions -03 and -04 . . . . . . . . . . 86
	E.14. Changes Between Versions -01 and -02 . . . . . . . . . . . 94		E.14. Changes Between Versions -02 and -03 . . . . . . . . . . 86
	E.15. Changes Between Versions -00 and -01 . . . . . . . . . . . 94		E.15. Changes Between Versions -01 and -02 . . . . . . . . . . 87
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 95		E.16. Changes Between Versions -00 and -01 . . . . . . . . . . 87
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 88
	1. Introduction		1. Introduction
	This document contains a specification of the following YANG modules:		This document contains a specification of the following YANG modules:
	o Module "ietf-routing" provides generic components of a routing		o Module "ietf-routing" provides generic components of a routing
	data model.		data model.
	o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing"		o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing"
	module with additional data specific to IPv4 unicast.		module with additional data specific to IPv4 unicast.
	o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing"		o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing"
	module with additional data specific to IPv6 unicast, including		module with additional data specific to IPv6 unicast, including
	the router configuration variables required by [RFC4861].		the router configuration variables required by [RFC4861].
	These modules together define the so-called core routing data model,		These modules together define the so-called core routing data model,
	which is proposed as a basis for the development of data models for		which is intended as a basis for future data model development
	configuration and management of more sophisticated routing systems.		covering more sophisticated routing systems. While these three
	While these three modules can be directly used for simple IP devices		modules can be directly used for simple IP devices with static
	with static routing (see Appendix B), their main purpose is to		routing (see Appendix B), their main purpose is to provide essential
	provide essential building blocks for more complicated setups		building blocks for more complicated data models involving multiple
	involving multiple routing protocols, multicast routing, additional		routing protocols, multicast routing, additional address families,
	address families, and advanced functions such as route filtering or		and advanced functions such as route filtering or policy routing. To
	policy routing. To this end, it is expected that the core routing		this end, it is expected that the core routing data model will be
	data model will be augmented by numerous modules developed by other		augmented by numerous modules developed by other IETF working groups.
	IETF working groups.
	2. Terminology and Notation		2. Terminology and Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The following terms are defined in [RFC6241]:		The following terms are defined in [RFC6241]:
	o client		o client
	skipping to change at page 6, line 11		skipping to change at page 4, line 50
	core routing data model: YANG data model comprising "ietf-routing",		core routing data model: YANG data model comprising "ietf-routing",
	"ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing"		"ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing"
	modules.		modules.
	direct route: a route to a directly connected network.		direct route: a route to a directly connected network.
	routing information base (RIB): An object containing a list of		routing information base (RIB): An object containing a list of
	routes together with other information. See Section 5.3 for		routes together with other information. See Section 5.3 for
	details.		details.
	system-controlled entry: An entry of a list in operational state		system-controlled entry: An entry of a list in state data ("config
	data ("config false") that is created by the system independently		false") that is created by the system independently of what has
	of what has been explicitly configured. See Section 4.1 for		been explicitly configured. See Section 4.1 for details.
	details.
	user-controlled entry: An entry of a list in operational state data		user-controlled entry: An entry of a list in state data ("config
	("config false") that is created and deleted as a direct		false") that is created and deleted as a direct consequence of
	consequence of certain configuration changes. See Section 4.1 for		certain configuration changes. See Section 4.1 for details.
	details.
	2.2. Tree Diagrams		2.2. Tree Diagrams
	A simplified graphical representation of the complete data tree is		A simplified graphical representation of the complete data tree is
	presented in Appendix A, and similar diagrams of its various subtrees		presented in Appendix A, and similar diagrams of its various subtrees
	appear in the main text. The meaning of the symbols in these		appear in the main text.
	diagrams is as follows:
			The meaning of the symbols in these diagrams is as follows:
	o Brackets "[" and "]" enclose list keys.		o Brackets "[" and "]" enclose list keys.
	o Curly braces "{" and "}" contain names of optional features that		o Curly braces "{" and "}" contain names of optional features that
	make the corresponding node conditional.		make the corresponding node conditional.
	o Abbreviations before data node names: "rw" means configuration		o Abbreviations before data node names: "rw" means configuration
	(read-write), and "ro" state data (read-only).		(read-write), and "ro" state data (read-only).
	o Symbols after data node names: "?" means an optional node and "*"		o Symbols after data node names: "?" means an optional node and "*"
	skipping to change at page 7, line 9		skipping to change at page 6, line 9
	In this document, names of data nodes, RPC methods and other data		In this document, names of data nodes, RPC methods and other data
	model objects are often used without a prefix, as long as it is clear		model objects are often used without a prefix, as long as it is clear
	from the context in which YANG module each name is defined.		from the context in which YANG module each name is defined.
	Otherwise, names are prefixed using the standard prefix associated		Otherwise, names are prefixed using the standard prefix associated
	with the corresponding YANG module, as shown in Table 1.		with the corresponding YANG module, as shown in Table 1.
	+--------+---------------------------+-----------+		+--------+---------------------------+-----------+
	| Prefix | YANG module | Reference |		| Prefix | YANG module | Reference |
	+--------+---------------------------+-----------+		+--------+---------------------------+-----------+
	| if | ietf-interfaces | [RFC7223] |		| if | ietf-interfaces | [RFC7223] |
	| | | |		| ip | ietf-ip | [RFC7277] |
	| ip | ietf-ip | [YANG-IP] |
	| | | |
	| rt | ietf-routing | Section 7 |		| rt | ietf-routing | Section 7 |
	| | | |
	| v4ur | ietf-ipv4-unicast-routing | Section 8 |		| v4ur | ietf-ipv4-unicast-routing | Section 8 |
	| | | |
	| v6ur | ietf-ipv6-unicast-routing | Section 9 |		| v6ur | ietf-ipv6-unicast-routing | Section 9 |
	| | | |
	| yang | ietf-yang-types | [RFC6991] |		| yang | ietf-yang-types | [RFC6991] |
	| | | |
	| inet | ietf-inet-types | [RFC6991] |		| inet | ietf-inet-types | [RFC6991] |
	+--------+---------------------------+-----------+		+--------+---------------------------+-----------+
	Table 1: Prefixes and corresponding YANG modules		Table 1: Prefixes and corresponding YANG modules
	3. Objectives		3. Objectives
	The initial design of the core routing data model was driven by the		The initial design of the core routing data model was driven by the
	following objectives:		following objectives:
	o The data model should be suitable for the common address families,		o The data model should be suitable for the common address families,
	in particular IPv4 and IPv6, and for unicast and multicast		in particular IPv4 and IPv6, and for unicast and multicast
	routing, as well as Multiprotocol Label Switching (MPLS).		routing, as well as Multiprotocol Label Switching (MPLS).
	o Simple routing setups, such as static routing, should be		o Simple routing set-ups, such as static routing, should be
	configurable in a simple way, ideally without any need to develop		configurable in a simple way, ideally without any need to develop
	additional YANG modules.		additional YANG modules.
	o On the other hand, the core routing framework must allow for		o On the other hand, the core routing framework must allow for
	complicated setups involving multiple routing information bases		complicated set-ups involving multiple routing information bases
	(RIB) and multiple routing protocols, as well as controlled		(RIB) and multiple routing protocols, as well as controlled
	redistributions of routing information.		redistributions of routing information.
	o Device vendors will want to map the data models built on this		o Device vendors will want to map the data models built on this
	generic framework to their proprietary data models and		generic framework to their proprietary data models and
	configuration interfaces. Therefore, the framework should be		configuration interfaces. Therefore, the framework should be
	flexible enough to facilitate such a mapping and accommodate data		flexible enough to facilitate such a mapping and accommodate data
	models with different logic.		models with different logic.
	4. The Design of the Core Routing Data Model		4. The Design of the Core Routing Data Model
	The core routing data model consists of three YANG modules. The		The core routing data model consists of three YANG modules. The
	first module, "ietf-routing", defines the generic components of a		first module, "ietf-routing", defines the generic components of a
	routing system. The other two modules, "ietf-ipv4-unicast-routing"		routing system. The other two modules, "ietf-ipv4-unicast-routing"
	and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module		and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module
	with additional data nodes that are needed for IPv4 and IPv6 unicast		with additional data nodes that are needed for IPv4 and IPv6 unicast
	routing, respectively. Figures 1 and 2 show abridged views of the		routing, respectively. Figures 1 and 2 show abridged views of the
	configuration and operational state data hierarchies. See Appendix A		configuration and state data hierarchies. See Appendix A for the
	for the complete data trees.		complete data trees.
	+--rw routing		+--rw routing
	+--rw routing-instance* [name]		+--rw routing-instance* [name]
	| +--rw name		| +--rw name
	| +--rw type?		| +--rw type?
	| +--rw enabled?		| +--rw enabled?
	| +--rw router-id?		| +--rw router-id?
	| +--rw description?		| +--rw description?
	| +--rw default-ribs		| +--rw default-ribs
	| | +--rw default-rib* [address-family]		| | +--rw default-rib* [address-family]
	| | +--rw address-family		| | +--rw address-family
	| | +--rw rib-name		| | +--rw rib-name
	| +--rw interfaces		| +--rw interfaces
	| | +--rw interface* [name]		| | +--rw interface* [name]
	| | +--rw name		| | +--rw name
	| | +--rw v6ur:ipv6-router-advertisements		| | +--rw v6ur:ipv6-router-advertisements
	| | ...		| | ...
	| +--rw routing-protocols		| +--rw routing-protocols
	| +--rw routing-protocol* [name]		| +--rw routing-protocol* [type name]
			| +--rw type
	| +--rw name		| +--rw name
	| +--rw description?		| +--rw description?
	| +--rw enabled?		| +--rw enabled?
	| +--rw type		| +--rw route-preference?
	| +--rw connected-ribs		| +--rw connected-ribs
	| | ...		| | ...
	| +--rw static-routes		| +--rw static-routes
	| ...		| ...
	+--rw ribs		+--rw ribs
	| +--rw rib* [name]		| +--rw rib* [name]
	| +--rw name		| +--rw name
	| +--rw address-family		| +--rw address-family
	| +--rw description?		| +--rw description?
	| +--rw recipient-ribs		| +--rw recipient-ribs
	skipping to change at page 11, line 10		skipping to change at page 8, line 10
	+--rw description?		+--rw description?
	+--rw type		+--rw type
	Figure 1: Configuration data hierarchy.		Figure 1: Configuration data hierarchy.
	+--ro routing-state		+--ro routing-state
	+--ro routing-instance* [name]		+--ro routing-instance* [name]
	| +--ro name		| +--ro name
	| +--ro id		| +--ro id
	| +--ro type?		| +--ro type?
	| +--ro router-id?
	| +--ro default-ribs		| +--ro default-ribs
	| | +--ro default-rib* [address-family]		| | +--ro default-rib* [address-family]
	| | +--ro address-family		| | +--ro address-family
	| | +--ro rib-name		| | +--ro rib-name
	| +--ro interfaces		| +--ro interfaces
	| | +--ro interface* [name]		| | +--ro interface* [name]
	| | +--ro name		| | +--ro name
	| | +--ro v6ur:ipv6-router-advertisements		| | +--ro v6ur:ipv6-router-advertisements
	| | ...		| | ...
	| +--ro routing-protocols		| +--ro routing-protocols
	| +--ro routing-protocol* [name]		| +--ro routing-protocol* [type name]
	| +--ro name
	| +--ro type		| +--ro type
			| +--ro name
			| +--ro route-preference
	| +--ro connected-ribs		| +--ro connected-ribs
	| ...		| ...
			+--ro next-hop-lists
			| +--ro next-hop-list* [id]
			| +--ro id
			| +--ro address-family
			| +--ro next-hop*
			| +--ro (next-hop-options)
			| | ...
			| +--ro priority?
			| +--ro weight?
	+--ro ribs		+--ro ribs
	| +--ro rib* [name]		| +--ro rib* [name]
	| +--ro name		| +--ro name
	| +--ro id		| +--ro id
	| +--ro address-family		| +--ro address-family
	| +--ro routes		| +--ro routes
	| | +--ro route* [id]		| | +--ro route*
	| | ...		| | ...
	| +--ro recipient-ribs		| +--ro recipient-ribs
	| +--ro recipient-rib* [rib-name]		| +--ro recipient-rib* [rib-name]
	| ...		| ...
	+--ro route-filters		+--ro route-filters
	+--ro route-filter* [name]		+--ro route-filter* [name]
	+--ro name		+--ro name
	+--ro type		+--ro type
	Figure 2: Operational state data hierarchy.		Figure 2: State data hierarchy.
	As can be seen from Figures 1 and 2, the core routing data model		As can be seen from Figures 1 and 2, the core routing data model
	introduces several generic components of a routing framework: routing		introduces several generic components of a routing framework: routing
	instances, RIBs containing lists of routes, routing protocols and		instances, RIBs containing lists of routes, routing protocols and
	route filters. The following subsections describe these components		route filters. The following subsections describe these components
	in more detail.		in more detail.
	By combining the components in various ways, and possibly augmenting		By combining the components in various ways, and possibly augmenting
	them with appropriate contents defined in other modules, various		them with appropriate contents defined in other modules, various
	routing systems can be realized.		routing systems can be realized.
	skipping to change at page 12, line 25		skipping to change at page 9, line 35
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	| F | | F | | F | | F |		| F | | F | | F | | F |
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	^ | ^ |		^ | ^ |
	| v | v		| v | v
	+----------+ +----------+		+----------+ +----------+
	| routing | | routing |		| routing | | routing |
	| protocol | | protocol |		| protocol | | protocol |
	+----------+ +----------+		+----------+ +----------+
	Figure 3: Example setup of a routing system		Figure 3: Example set-up of a routing system
	The example in Figure 3 shows a typical (though certainly not the		The example in Figure 3 shows a typical (though certainly not the
	only possible) organization of a more complex routing subsystem for a		only possible) organization of a more complex routing subsystem for a
	single address family. Several of its features are worth mentioning:		single address family. Several of its features are worth mentioning:
	o Along with the default RIB, which is always present, an additional		o Along with the default RIB, which is always present, an additional
	RIB is configured.		RIB is configured.
	o Each routing protocol instance, including the "static" and		o Each routing protocol instance, including the "static" and
	"direct" pseudo-protocols, is connected to exactly one RIB with		"direct" pseudo-protocols, is connected to exactly one RIB with
	skipping to change at page 13, line 4		skipping to change at page 10, line 16
	of route filters, denoted by "F" in Figure 3.		of route filters, denoted by "F" in Figure 3.
	4.1. System-Controlled and User-Controlled List Entries		4.1. System-Controlled and User-Controlled List Entries
	The core routing data model defines several lists, for example		The core routing data model defines several lists, for example
	"routing-instance" or "rib", that have to be populated with at least		"routing-instance" or "rib", that have to be populated with at least
	one entry in any properly functioning device, and additional entries		one entry in any properly functioning device, and additional entries
	may be configured by the user.		may be configured by the user.
	In such a list, the server creates the required item as a so-called		In such a list, the server creates the required item as a so-called
	system-controlled entry in operational state data, i.e., inside the		system-controlled entry in state data, i.e., inside the "routing-
	"routing-state" container.		state" container.
	Additional entries may be created in the configuration by the user		Additional entries may be created in the configuration by the user,
	via the NETCONF protocol. These are so-called user-controlled		e.g., via the NETCONF protocol. These are so-called user-controlled
	entries. If the server accepts a configured user-controlled entry,		entries. If the server accepts a configured user-controlled entry,
	then this entry also appears in the operational state version of the		then this entry also appears in the state data version of the list.
	list.
	Corresponding entries in both versions of the list (in operational		Corresponding entries in both versions of the list (in state data and
	state data and configuration) have the same value of the list key.		configuration) have the same value of the list key.
	The user may also provide supplemental configuration of system-		The user may also provide supplemental configuration of system-
	controlled entries. To do so, the user creates a new entry in the		controlled entries. To do so, the user creates a new entry in the
	configuration with the desired contents. In order to bind this entry		configuration with the desired contents. In order to bind this entry
	with the corresponding entry in the operational state list, the key		with the corresponding entry in the state data list, the key of the
	of the configuration entry has to be set to the same value as the key		configuration entry has to be set to the same value as the key of the
	of the state entry.		state entry.
	An example can be seen in Appendix D: the "/routing-state/		An example can be seen in Appendix D: the "/routing-state/routing-
	routing-instance" list has a single system-controlled entry whose		instance" list has a single system-controlled entry whose "name" key
	"name" key has the value "rtr0". This entry is configured by the		has the value "rtr0". This entry is configured by the "/routing/
	"/routing/routing-instance" entry whose "name" key is also "rtr0".		routing-instance" entry whose "name" key is also "rtr0".
	Deleting a user-controlled entry from the configuration list results		Deleting a user-controlled entry from the configuration list results
	in the removal of the corresponding entry in the operational state		in the removal of the corresponding entry in the state data list. In
	list. In contrast, if a system-controlled entry is deleted from the		contrast, if a system-controlled entry is deleted from the
	configuration list, only the extra configuration specified in that		configuration list, only the extra configuration specified in that
	entry is removed but the corresponding operational state entry		entry is removed but the corresponding state data entry remains in
	remains in the list.		the list.
	4.2. Features of Advanced Routers		4.2. Features of Advanced Routers
	The core routing data model attempts to address devices with		The core routing data model attempts to address devices with
	elementary routing functions as well as advanced routers. For simple		elementary routing functions as well as advanced routers. For simple
	devices, some parts and options of the data model are not needed and		devices, some parts and options of the data model are not needed and
	would represent unnecessary complications for the implementation.		would represent unnecessary complications for the implementation.
	Therefore, the core routing data model makes the advanced		Therefore, the core routing data model makes the configuration of
	functionality optional by means of two YANG features:		some advanced functions optional to implement by means of two YANG
			features:
	o "multiple-ribs" - indicates that the device supports multiple RIBs		o "multiple-ribs" - indicates that the device supports configuration
	per address family, routing protocols connected to non-default		of user-defined RIBs, routing protocols connected to non-default
	RIBs, and RIBs configured as receivers of routes from other RIBs.		RIBs, and RIBs configured as receivers of routes from other RIBs.
	o "multipath-routes" - indicates that the device supports routes		o "multipath-routes" - indicates that the device supports
	with multiple next-hops.		configuration of routes with multiple next-hops.
	See the "ietf-routing" module for details.		See the "ietf-routing" module for details.
	5. Basic Building Blocks		5. Basic Building Blocks
	This section describes the essential components of the core routing		This section describes the essential components of the core routing
	data model.		data model.
	5.1. Routing Instance		5.1. Routing Instance
	Each routing instance in the core routing data model represents a		The core routing data model supports one or more routing instances
	logical router. The exact semantics of this term are left to		appearing as entries of the "routing-instance" list. Each routing
	implementations. For example, routing instances may be completely		instance has separate configuration and state data under
	isolated virtual routers or, alternatively, they may internally share		"/rt:routing/rt:routing-instance" and "/rt:routing-state/rt:routing-
	certain information.		instance", respectively.
	A routing instance together with its operational state is represented
	as an entry of the list "/routing-state/routing-instance", and
	identified by a unique name. Configuration of that router instance
	appears as an entry of the list "/routing/routing-instance".
	An implementation MAY support multiple types of logical routers		The semantics of the term "routing instance" is deliberately left
	simultaneously. Instances of all routing instance types are		undefined. It is expected that future YANG modules will define data
	organized as entries of the same flat "routing-instance" list. In		models for specific types of routing instances, such as VRF (virtual
	order to discriminate routing instances belonging to different types,		routing and forwarding) instances that are used for BGP/MPLS virtual
	the "type" leaf is defined as a child of the "routing-instance" node.		private networks [RFC4364]. For each type of routing instance, an
			identity derived from "rt:routing-instance" MUST be defined. This
			identity is then referred to by the value of the "type" leaf (a child
			node of "routing-instance" list).
	An implementation MAY create one or more system-controlled routing		An implementation MAY create one or more system-controlled routing
	instances, and MAY also pose restrictions on allowed routing instance		instances, and MAY also impose restrictions on types of routing
	types and on the number of supported instances for each type. For		instances that can be configured, and on the maximum number of
	example, a simple router implementation may support only one system-		supported instances for each type. For example, a simple router
	controlled routing instance of the default type "rt:standard-routing-		implementation may support only one system-controlled routing
	instance" and may not allow creation of any user-controlled		instance of the default type "rt:default-routing-instance" and may
	instances.		not allow creation of any user-controlled instances.
	Each network layer interface has to be assigned to one or more		Each network layer interface has to be assigned to one or more
	routing instances in order to be able to participate in packet		routing instances in order to be able to participate in packet
	forwarding, routing protocols and other operations of those routing		forwarding, routing protocols and other operations of those routing
	instances. The assignment is accomplished by placing a corresponding		instances. The assignment is accomplished by placing a corresponding
	(system- or user-controlled) entry in the list of routing instance		(system- or user-controlled) entry in the list of routing instance
	interfaces ("rt:interface"). The key of the list entry is the name		interfaces ("rt:interface"). The key of the list entry is the name
	of a configured network layer interface, see the "ietf-interfaces"		of a configured network layer interface, see the "ietf-interfaces"
	module [RFC7223].		module [RFC7223].
	In YANG terms, the list of routing instance interfaces is modeled as		A data model for a routing instance type MAY state additional rules
	a "list" node rather than "leaf-list" in order to allow for adding,		for the assignment of interfaces to routing instances of that type.
	via augmentation, other configuration or state data related to the		For example, it may be required that the sets of interfaces assigned
	corresponding interface.		to different routing instances of a certain type be disjoint.
	Implementations MAY specify additional rules for the assignment of
	interfaces to routing instances. For example, it may be required
	that the sets of interfaces assigned to different routing instances
	be disjoint.
	5.1.1. Parameters of IPv6 Routing Instance Interfaces		5.1.1. Parameters of IPv6 Routing Instance Interfaces
	The module "ietf-ipv6-unicast-routing" augments the definition of the		The module "ietf-ipv6-unicast-routing" augments the definition of the
	data node "rt:interface", in both configuration and operational state		data node "rt:interface", in both configuration and state data, with
	data, with definitions of the following variables as required by		definitions of the following variables as required by [RFC4861], sec.
	[RFC4861], sec. 6.2.1:		6.2.1:
	o send-advertisements,		o send-advertisements,
	o max-rtr-adv-interval,		o max-rtr-adv-interval,
	o min-rtr-adv-interval,		o min-rtr-adv-interval,
	o managed-flag,		o managed-flag,
	o other-config-flag,		o other-config-flag,
	skipping to change at page 16, line 6		skipping to change at page 13, line 11
	* preferred-lifetime,		* preferred-lifetime,
	* autonomous-flag.		* autonomous-flag.
	The definitions and descriptions of the above parameters can be found		The definitions and descriptions of the above parameters can be found
	in the module "ietf-ipv6-unicast-routing" (Section 9).		in the module "ietf-ipv6-unicast-routing" (Section 9).
	NOTES:		NOTES:
	1. The "IsRouter" flag, which is also required by [RFC4861], is		1. The "IsRouter" flag, which is also required by [RFC4861], is
	implemented in the "ietf-ip" module [YANG-IP] (leaf "ip:		implemented in the "ietf-ip" module [RFC7277] (leaf
	forwarding").		"ip:forwarding").
	2. The original specification [RFC4861] allows the implementations		2. The original specification [RFC4861] allows the implementations
	to decide whether the "valid-lifetime" and "preferred-lifetime"		to decide whether the "valid-lifetime" and "preferred-lifetime"
	parameters remain the same in consecutive advertisements, or		parameters remain the same in consecutive advertisements, or
	decrement in real time. However, the latter behavior seems		decrement in real time. However, the latter behavior seems
	problematic because the values might be reset again to the		problematic because the values might be reset again to the
	(higher) configured values after a configuration is reloaded.		(higher) configured values after a configuration is reloaded.
	Moreover, no implementation is known to use the decrementing		Moreover, no implementation is known to use the decrementing
	behavior. The "ietf-ipv6-unicast-routing" module therefore		behavior. The "ietf-ipv6-unicast-routing" module therefore
	assumes the former behavior with constant values.		assumes the former behavior with constant values.
	5.2. Route		5.2. Route
	Routes are basic elements of information in a routing system. The		Routes are basic elements of information in a routing system. The
	core routing data model defines only the following minimal set of		core routing data model defines only the following minimal set of
	route attributes:		route attributes:
	o destination prefix: IP prefix specifying the set of destination		o "destination-prefix": IP prefix specifying the set of destination
	addresses for which the route may be used. This attribute is		addresses for which the route may be used. This attribute is
	mandatory.		mandatory.
	o next-hop or action: outgoing interface, IP address of one or more		o "route-preference": an integer value (also known as administrative
	adjacent routers to which a packet should be forwarded, or a		distance) that is used for selecting a preferred route among
	special action such as discarding the packet.		routes with the same destination prefix. A lower value means a
			more preferred route.
	The above list of route attributes suffices for a simple static		o "next-hop": determines the action to be performed with a packet.
	routing configuration. It is expected that future modules defining		See below for details.
	routing protocols will add other route attributes such as metrics or
	preferences.
	Routes and their attributes are used both in configuration data, for		The choice of next-hops comprises the following cases:
	example as manually configured static routes, and in operational
	state data, for example as entries in RIBs.		o simple next-hop - IP address of the next-hop router, outgoing
			interface, or both.
			o special next-hop - a keyword indicating special packet handling,
			one of:
			* "blackhole" - silently discard the packet;
			* "unreachable" - discard the packet and notify the sender with a
			"destination unreachable" error message;
			* "prohibit" - discard the packet notify the sender with an
			"administratively prohibited" error message.
			o next-hop list reference - each next-hop list is a set of next-hops
			that may also contain a reference to another next-hop list.
			o RIB reference - a new look-up is to be performed in the specified
			RIB.
			It is expected that future modules defining routing protocols will
			add other route attributes such as metrics or preferences.
			Routes are primarily state data that appear as entries of RIBs
			(Section 5.3) but they may be also found in configuration data, for
			example as manually configured static routes. In the latter case,
			configurable route attributes are generally a subset of route
			attributes described above.
	5.3. Routing Information Base (RIB)		5.3. Routing Information Base (RIB)
	A routing information base (RIB) is a list of routes complemented		A routing information base (RIB) is a list of routes complemented
	with administrative data, namely:		with administrative data, namely:
	o "source-protocol": type of the routing protocol from which the		o "source-protocol": type of the routing protocol from which the
	route was originally obtained.		route was originally obtained.
			o "preferred": an implementation can use this empty leaf to indicate
			that the route is preferred among all routes in the same RIB that
			have the same destination prefix.
	o "last-updated": the date and time when the route was last updated,		o "last-updated": the date and time when the route was last updated,
	or inserted into the RIB.		or inserted into the RIB.
	Each RIB MUST contain only routes of one address family. In the data		Each RIB MUST contain only routes of one address family. In the data
	model, address family is represented with an identity derived from		model, address family is represented with an identity derived from
	the "rt:address-family" base identity.		the "rt:address-family" base identity.
	In the core routing data model, RIBs are operational state data		In the core routing data model, RIBs are state data represented as
	represented as entries of the list "/routing-state/ribs/rib". The		entries of the list "/routing-state/ribs/rib". The contents of RIBs
	contents of RIBs are controlled and manipulated by routing protocol		are controlled and manipulated by routing protocol operations which
	operations which may result in route additions, removals and		may result in route additions, removals and modifications. This also
	modifications. This also includes manipulations via the "static"		includes manipulations via the "static" and/or "direct" pseudo-
	and/or "direct" pseudo-protocols, see Section 5.4.1.		protocols, see Section 5.4.1.
	RIBs are global, which means that a RIB may be used by any or all		RIBs are global, which means that a RIB may be used by any or all
	routing instances. However, an implementation MAY specify rules and		routing instances. However, a data model for a routing instance type
	restrictions for sharing RIBs among routing instances.		MAY state rules and restrictions for sharing RIBs among routing
			instances of that type.
	Each routing instance has, for every supported address family, one		Each routing instance has, for every supported address family, one
	RIB selected as the so-called default RIB. This selection is		RIB selected as the so-called default RIB. This selection is
	recorded in the list "default-rib". The role of default RIBs is		recorded in the list "default-rib". The role of default RIBs is
	explained in Section 5.4.		explained in Section 5.4.
	Simple router implementations that do not advertise the feature		Simple router implementations that do not advertise the feature
	"multiple-ribs" will typically create one system-controlled RIB per		"multiple-ribs" will typically create one system-controlled RIB per
	supported address family, and declare it as the default RIB (via a		supported address family, and declare it as the default RIB (via a
	system-controlled entry of the "default-rib" list).		system-controlled entry of the "default-rib" list).
	skipping to change at page 18, line 5		skipping to change at page 15, line 43
	5.4. Routing Protocol		5.4. Routing Protocol
	The core routing data model provides an open-ended framework for		The core routing data model provides an open-ended framework for
	defining multiple routing protocol instances within a routing		defining multiple routing protocol instances within a routing
	instance. Each routing protocol instance MUST be assigned a type,		instance. Each routing protocol instance MUST be assigned a type,
	which is an identity derived from the "rt:routing-protocol" base		which is an identity derived from the "rt:routing-protocol" base
	identity. The core routing data model defines two identities for the		identity. The core routing data model defines two identities for the
	direct and static pseudo-protocols (Section 5.4.1).		direct and static pseudo-protocols (Section 5.4.1).
	Each routing protocol instance is connected to exactly one RIB for		Multiple routing protocol instances of the same type are permitted.
	each address family that the routing protocol instance supports.
	Routes learned from the network by a routing protocol are normally		Each routing protocol instance can be connected to one or more RIBs
	installed into the connected RIB(s) and, conversely, routes from the		for each address family that the routing protocol instance supports.
	connected RIB(s) are normally injected into the routing protocol.		By default, the interaction of a routing protocol instance with its
	However, routing protocol implementations MAY specify rules that		connected RIBs is governed by the following rules:
	restrict this exchange of routes in either direction (or both
	directions).		o Routes learned from the network are installed in all connected
			RIBs with a matching address family.
			o Conversely, routes from all connected RIBs are injected into the
			routing protocol instance.
			However, a data model for a routing protocol MAY impose specific
			rules for exchanging routes between routing protocol instances and
			connected RIBs.
	On devices supporting the "multiple-ribs" feature, any RIB (system-		On devices supporting the "multiple-ribs" feature, any RIB (system-
	controlled or user-controlled) may be connected to a routing protocol		controlled or user-controlled) may be connected to a routing protocol
	instance by configuring a corresponding entry in the "connected-rib"		instance by configuring a corresponding entry in the "connected-rib"
	list. If such an entry is not configured for an address family, then		list. If such an entry is not configured for an address family, then
	the default RIB MUST be used as the connected RIB for this address		the default RIB MUST be used as the connected RIB for this address
	family.		family.
	In addition, two independent route filters (see Section 5.5) may be		In addition, two independent route filters (see Section 5.5) may be
	configured for each connected RIB to apply user-defined policies		configured for each connected RIB to apply user-defined policies
	skipping to change at page 18, line 39		skipping to change at page 16, line 37
	o export filter controls which routes the routing protocol instance		o export filter controls which routes the routing protocol instance
	receives from the connected RIB.		receives from the connected RIB.
	Note that the terms import and export are used from the viewpoint of		Note that the terms import and export are used from the viewpoint of
	a RIB.		a RIB.
	5.4.1. Routing Pseudo-Protocols		5.4.1. Routing Pseudo-Protocols
	The core routing data model defines two special routing protocol		The core routing data model defines two special routing protocol
	types - "direct" and "static". Both are in fact pseudo-protocols,		types - "direct" and "static". Both are in fact pseudo-protocols,
	which means that they are confined to the local device and do not		which means they are confined to the local device and do not exchange
	exchange any routing information with neighboring routers. Routes		any routing information with adjacent routers. Routes from both
	from both "direct" and "static" protocol instances are passed to the		"direct" and "static" protocol instances are passed to the connected
	connected RIB (subject to route filters, if any), but an exchange in		RIBs (subject to route filters, if any), but an exchange in the
	the opposite direction is not allowed.		opposite direction is not allowed.
	Every routing instance MUST implement exactly one instance of the		Every routing instance MUST implement exactly one instance of the
	"direct" pseudo-protocol type. It is the source of direct routes for		"direct" pseudo-protocol type. It is the source of direct routes for
	all configured address families. Direct routes are normally supplied		all configured address families. Direct routes are normally supplied
	by the operating system kernel, based on the configuration of network		by the operating system kernel, based on the configuration of network
	interface addresses, see Section 6.2. The "direct" pseudo-protocol		interface addresses, see Section 6.2. The "direct" pseudo-protocol
	MUST always be connected to the default RIBs of all supported address		MUST always be connected to the default RIBs of all supported address
	families. Unlike other routing protocol types, this connection		families. Unlike other routing protocol types, this connection
	cannot be changed in the configuration. Direct routes MAY be		cannot be changed in the configuration. Direct routes MAY be
	filtered before they appear in the default RIB.		filtered before they appear in the default RIB.
	skipping to change at page 20, line 7		skipping to change at page 17, line 15
	A pseudo-protocol of the type "static" allows for specifying routes		A pseudo-protocol of the type "static" allows for specifying routes
	manually. It MAY be configured in zero or multiple instances,		manually. It MAY be configured in zero or multiple instances,
	although a typical configuration will have exactly one instance per		although a typical configuration will have exactly one instance per
	routing instance.		routing instance.
	Static routes are configured within the "static-routes" container,		Static routes are configured within the "static-routes" container,
	see Figure 4.		see Figure 4.
	+--rw static-routes		+--rw static-routes
	+--rw v4ur:ipv4		+--rw v4ur:ipv4
	| +--rw v4ur:route* [id]		| +--rw v4ur:route* [destination-prefix]
	| +--rw v4ur:id
	| +--rw v4ur:description?
	| +--rw v4ur:destination-prefix		| +--rw v4ur:destination-prefix
	| +--rw (next-hop-options)		| +--rw v4ur:description?
	| +--:(special-next-hop)		| +--rw v4ur:next-hop
	| | +--rw v4ur:special-next-hop?		| +--rw (simple-or-list)?
	| +--:(simple-next-hop)		| +--:(multipath-entry)
	| | +--rw v4ur:next-hop?		| | +--rw v4ur:multipath-entry* [name]
	| | +--rw v4ur:outgoing-interface?		| | +--rw v4ur:name
	| +--:(next-hop-list) {rt:multipath-routes}?		| | +--rw (next-hop-options)
	| +--rw v4ur:next-hop-list		| | | +--:(simple-next-hop)
	| +--rw v4ur:next-hop* [id]		| | | | +--rw v4ur:outgoing-interface?
	| +--rw v4ur:id		| | | +--:(special-next-hop)
	| +--rw v4ur:address?		| | | | +--rw v4ur:special-next-hop?
	| +--rw v4ur:outgoing-interface?		| | | +--:(next-hop-address)
	| +--rw v4ur:priority?		| | | +--rw v4ur:next-hop-address?
	| +--rw v4ur:weight?		| | +--rw v4ur:priority?
			| | +--rw v4ur:weight?
			| +--:(simple-next-hop)
			| +--rw (next-hop-options)
			| +--:(simple-next-hop)
			| | +--rw v4ur:outgoing-interface?
			| +--:(special-next-hop)
			| | +--rw v4ur:special-next-hop?
			| +--:(next-hop-address)
			| +--rw v4ur:next-hop-address?
	+--rw v6ur:ipv6		+--rw v6ur:ipv6
	+--rw v6ur:route* [id]		+--rw v6ur:route* [destination-prefix]
	+--rw v6ur:id
	+--rw v6ur:description?
	+--rw v6ur:destination-prefix		+--rw v6ur:destination-prefix
	+--rw (next-hop-options)		+--rw v6ur:description?
	+--:(special-next-hop)		+--rw v6ur:next-hop
	| +--rw v6ur:special-next-hop?		+--rw (simple-or-list)?
	+--:(simple-next-hop)		+--:(multipath-entry)
	| +--rw v6ur:next-hop?		| +--rw v6ur:multipath-entry* [name]
	| +--rw v6ur:outgoing-interface?		| +--rw v6ur:name
	+--:(next-hop-list) {rt:multipath-routes}?		| +--rw (next-hop-options)
	+--rw v6ur:next-hop-list		| | +--:(simple-next-hop)
	+--rw v6ur:next-hop* [id]		| | | +--rw v6ur:outgoing-interface?
	+--rw v6ur:id		| | +--:(special-next-hop)
	+--rw v6ur:address?		| | | +--rw v6ur:special-next-hop?
	+--rw v6ur:outgoing-interface?		| | +--:(next-hop-address)
	+--rw v6ur:priority?		| | +--rw v6ur:next-hop-address?
	+--rw v6ur:weight?		| +--rw v6ur:priority?
			| +--rw v6ur:weight?
			+--:(simple-next-hop)
			+--rw (next-hop-options)
			+--:(simple-next-hop)
			| +--rw v6ur:outgoing-interface?
			+--:(special-next-hop)
			| +--rw v6ur:special-next-hop?
			+--:(next-hop-address)
			+--rw v6ur:next-hop-address?
	Figure 4: Structure of "static-routes" subtree.		Figure 4: Structure of "static-routes" subtree.
			A next-hop in static routes may be configured as a simple next-hop
			(IP address, outgoing interface or both), special next-hop or a list
			of multi-path next-hop entries that is used either for backup routes
			of for equal-cost multi-path (ECMP) routing. The last option is
			available only on devices that advertise the feature "rt:multipath-
			routes". Moreover, unlike next-hop lists in state data, a list of
			next-hop entries in a static route cannot be recursive, i.e., each
			entry of that list can only be a simple or special next-hop.
	5.4.2. Defining New Routing Protocols		5.4.2. Defining New Routing Protocols
	It is expected that future YANG modules will create data models for		It is expected that future YANG modules will create data models for
	additional routing protocol types. Such a new module has to define		additional routing protocol types. Such a new module has to define
	the protocol-specific configuration and state data, and it has to fit		the protocol-specific configuration and state data, and it has to fit
	it into the core routing framework in the following way:		it into the core routing framework in the following way:
	o A new identity MUST be defined for the routing protocol and its		o A new identity MUST be defined for the routing protocol and its
	base identity MUST be set to "rt:routing-protocol", or to an		base identity MUST be set to "rt:routing-protocol", or to an
	identity derived from "rt:routing-protocol".		identity derived from "rt:routing-protocol".
	o Additional route attributes MAY be defined, preferably in one		o Additional route attributes MAY be defined, preferably in one
	place by means of defining a YANG grouping. The new attributes		place by means of defining a YANG grouping. The new attributes
	have to be inserted by augmenting the definitions of the nodes		have to be inserted by augmenting the definitions of the nodes
	/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route		/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
	and		and
	/rt:active-route/rt:output/rt:route,		/rt:fib-route/rt:output/rt:route,
	and possibly other places in the configuration, state data and RPC		and possibly other places in the configuration, state data and RPC
	input or output.		input or output.
	o Configuration parameters and/or state data for the new protocol		o Configuration parameters and/or state data for the new protocol
	can be defined by augmenting the "routing-protocol" data node		can be defined by augmenting the "routing-protocol" data node
	under both "/routing" and "/routing-state".		under both "/routing" and "/routing-state".
	o Per-interface configuration, including activation of the routing		o Per-interface configuration, including activation of the routing
	protocol on individual interfaces, can use references to entries		protocol on individual interfaces, can use references to entries
	skipping to change at page 21, line 49		skipping to change at page 19, line 32
	5.5. Route Filter		5.5. Route Filter
	The core routing data model provides a skeleton for defining route		The core routing data model provides a skeleton for defining route
	filters that can be used to restrict the set of routes being		filters that can be used to restrict the set of routes being
	exchanged between a routing protocol instance and a connected RIB, or		exchanged between a routing protocol instance and a connected RIB, or
	between a source and a recipient RIB. Route filters may also		between a source and a recipient RIB. Route filters may also
	manipulate routes, i.e., add, delete, or modify their attributes.		manipulate routes, i.e., add, delete, or modify their attributes.
	Route filters are global, which means that a configured route filter		Route filters are global, which means that a configured route filter
	may be used by any or all routing instances. However, an		may be used by any or all routing instances. However, a data model
	implementation MAY specify rules and restrictions for sharing route		for a routing instance type MAY specify rules and restrictions for
	filters among routing instances.		sharing route filters among routing instances of that type.
	By itself, the route filtering framework defined in this document		The core routing data model defines only two extreme route filtering
	allows for applying only two extreme routing policies which are		policies which are represented by the following pre-defined route
	represented by the following pre-defined route filter types:		filter types:
	o "deny-all-route-filter": all routes are blocked,		o "deny-all-route-filter": all routes are blocked,
	o "allow-all-route-filter": all routes are permitted.		o "allow-all-route-filter": all routes are permitted.
	The latter type is equivalent to no route filter.		The latter type is equivalent to no route filter.
	It is expected that more comprehensive route filtering frameworks		It is expected that more comprehensive route filtering frameworks
	will be developed separately.		will be developed separately.
	Each route filter is identified by a unique name. Its type MUST be		Each route filter entry is identified by a unique name. Its type
	specified by the "type" identity reference - this opens the space for		MUST be specified by the "type" identity reference.
	multiple route filtering framework implementations.
	5.6. RPC Operations		5.6. RPC Operations
	The "ietf-routing" module defines two RPC operations:		The "ietf-routing" module defines two RPC operations:
	o active-route: query a routing instance for the active route that		o fib-route: query a routing instance for the active route in the
	is currently used for sending datagrams to a destination host		Forwarding Information Base (FIB). It is the route that is
	whose address is passed as an input parameter.		currently used for sending datagrams to a destination host whose
			address is passed as an input parameter.
	o route-count: retrieve the total number of entries in a RIB.		o route-count: retrieve the total number of entries in a RIB.
	6. Interactions with Other YANG Modules		6. Interactions with Other YANG Modules
	The semantics of the core routing data model also depend on several		The semantics of the core routing data model also depends on several
	configuration parameters that are defined in other YANG modules.		configuration parameters that are defined in other YANG modules.
	6.1. Module "ietf-interfaces"		6.1. Module "ietf-interfaces"
	The following boolean switch is defined in the "ietf-interfaces" YANG		The following boolean switch is defined in the "ietf-interfaces" YANG
	module [RFC7223]:		module [RFC7223]:
	/if:interfaces/if:interface/if:enabled		/if:interfaces/if:interface/if:enabled
	If this switch is set to "false" for a network layer interface,		If this switch is set to "false" for a network layer interface,
	the device MUST behave exactly as if that interface was not		the device MUST behave exactly as if that interface was not
	assigned to any routing instance at all.		assigned to any routing instance at all.
	6.2. Module "ietf-ip"		6.2. Module "ietf-ip"
	The following boolean switches are defined in the "ietf-ip" YANG		The following boolean switches are defined in the "ietf-ip" YANG
	module [YANG-IP]:		module [RFC7277]:
	/if:interfaces/if:interface/ip:ipv4/ip:enabled		/if:interfaces/if:interface/ip:ipv4/ip:enabled
	If this switch is set to "false" for a network layer interface,		If this switch is set to "false" for a network layer interface,
	then all IPv4 routing functions related to that interface MUST be		then all IPv4 routing functions related to that interface MUST be
	disabled.		disabled.
	/if:interfaces/if:interface/ip:ipv4/ip:forwarding		/if:interfaces/if:interface/ip:ipv4/ip:forwarding
	If this switch is set to "false" for a network layer interface,		If this switch is set to "false" for a network layer interface,
	skipping to change at page 25, line 7		skipping to change at page 21, line 25
	In addition, the "ietf-ip" module allows for configuring IPv4 and		In addition, the "ietf-ip" module allows for configuring IPv4 and
	IPv6 addresses and network prefixes or masks on network layer		IPv6 addresses and network prefixes or masks on network layer
	interfaces. Configuration of these parameters on an enabled		interfaces. Configuration of these parameters on an enabled
	interface MUST result in an immediate creation of the corresponding		interface MUST result in an immediate creation of the corresponding
	direct route. The destination prefix of this route is set according		direct route. The destination prefix of this route is set according
	to the configured IP address and network prefix/mask, and the		to the configured IP address and network prefix/mask, and the
	interface is set as the outgoing interface for that route.		interface is set as the outgoing interface for that route.
	7. Routing Management YANG Module		7. Routing Management YANG Module
	RFC Ed.: In this section, replace all occurrences of 'XXXX' with the		RFC Editor: In this section, replace all occurrences of 'XXXX' with
	actual RFC number and all occurrences of the revision date below with		the actual RFC number and all occurrences of the revision date below
	the date of RFC publication (and remove this note).		with the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-routing@2014-05-24.yang"		<CODE BEGINS> file "routing@2014-10-26.yang"
	module ietf-routing {		module ietf-routing {
	namespace "urn:ietf:params:xml:ns:yang:ietf-routing";		namespace "urn:ietf:params:xml:ns:yang:ietf-routing";
	prefix "rt";		prefix "rt";
	import ietf-yang-types {		import ietf-yang-types {
	prefix "yang";		prefix "yang";
	}		}
	skipping to change at page 26, line 11		skipping to change at page 22, line 30
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	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 the		This version of this YANG module is part of RFC XXXX; see the
	RFC itself for full legal notices.";		RFC itself for full legal notices.";
	revision 2014-05-24 {		revision 2014-10-26 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing Management";		"RFC XXXX: A YANG Data Model for Routing Management";
	}		}
	/* Features */		/* Features */
	feature multiple-ribs {		feature multiple-ribs {
	description		description
	"This feature indicates that the device supports multiple RIBS		"This feature indicates that the server supports user-defined
	per address family, and the framework for passing routes		RIBS and the framework for passing routes between RIBs.
	between RIBs.
	Devices that do not support this feature MUST provide exactly		Servers that do not advertize this feature MUST provide
	one system-controlled RIB per supported address family. These		exactly one system-controlled RIB per supported address family
	RIBs then appear as entries of the list		and make them also the default RIBs. These RIBs then appear as
	/routing-state/ribs/rib.";		entries of the list /routing-state/ribs/rib.";
	}		}
	feature multipath-routes {		feature multipath-routes {
	description		description
	"This feature indicates that the device supports multipath		"This feature indicates that the server supports multipath
	routes that have a list of next-hops.";		routes that have a list of next-hops.";
	}		}
			feature router-id {
			description
			"This feature indicates that the server supports configuration
			of an explicit 32-bit router ID that is used by some routing
			protocols.
			Servers that do not advertize this feature set a router ID
			algorithmically, usually to one of configured IPv4 addresses.
			However, this algorithm is implementation-specific.";
			}
	/* Identities */		/* Identities */
	identity address-family {		identity address-family {
	description		description
	"Base identity from which identities describing address		"Base identity from which identities describing address
	families are derived.";		families are derived.";
	}		}
	identity ipv4 {		identity ipv4 {
	base address-family;		base address-family;
	skipping to change at page 27, line 4		skipping to change at page 23, line 32
	description		description
	"Base identity from which identities describing address		"Base identity from which identities describing address
	families are derived.";		families are derived.";
	}		}
	identity ipv4 {		identity ipv4 {
	base address-family;		base address-family;
	description		description
	"This identity represents IPv4 address family.";		"This identity represents IPv4 address family.";
	}		}
	identity ipv6 {		identity ipv6 {
	base address-family;		base address-family;
	description		description
	"This identity represents IPv6 address family.";		"This identity represents IPv6 address family.";
	}		}
	identity routing-instance-type {		identity routing-instance {
	description		description
	"Base identity from which identities describing routing		"Base identity from which identities describing routing
	instance types are derived.		instance types are derived.";
	It is primarily intended for discriminating among different
	types of logical routers or router virtualization.";
	}		}
	identity standard-routing-instance {		identity default-routing-instance {
	base routing-instance-type;		base routing-instance;
	description		description
	"This identity represents a default routing instance.";		"This identity represents either a default routing instance, or
			the only routing instance on systems that do not support
			multiple instances.";
	}		}
	identity routing-protocol {		identity routing-protocol {
	description		description
	"Base identity from which routing protocol identities are		"Base identity from which routing protocol identities are
	derived.";		derived.";
	}		}
	identity direct {		identity direct {
	base routing-protocol;		base routing-protocol;
	description		description
	"Routing pseudo-protocol which provides routes to directly		"Routing pseudo-protocol which provides routes to directly
	skipping to change at page 28, line 51		skipping to change at page 25, line 30
	typedef rib-state-ref {		typedef rib-state-ref {
	type leafref {		type leafref {
	path "/rt:routing-state/rt:ribs/rt:rib/rt:name";		path "/rt:routing-state/rt:ribs/rt:rib/rt:name";
	}		}
	description		description
	"This type is used for leafs that reference a RIB in state		"This type is used for leafs that reference a RIB in state
	data.";		data.";
	}		}
			typedef next-hop-list-ref {
			type leafref {
			path "/rt:routing-state/rt:next-hop-lists/rt:next-hop-list/"
			+ "rt:id";
			}
			description
			"This type is used for leafs that reference a next-hop list (in
			state data).";
			}
	typedef route-filter-ref {		typedef route-filter-ref {
	type leafref {		type leafref {
	path "/rt:routing/rt:route-filters/rt:route-filter/rt:name";		path "/rt:routing/rt:route-filters/rt:route-filter/rt:name";
	}		}
	description		description
	"This type is used for leafs that reference a route filter		"This type is used for leafs that reference a route filter
	configuration.";		configuration.";
	}		}
	typedef route-filter-state-ref {		typedef route-filter-state-ref {
	type leafref {		type leafref {
	path "/rt:routing-state/rt:route-filters/rt:route-filter/"		path "/rt:routing-state/rt:route-filters/rt:route-filter/"
	+ "rt:name";		+ "rt:name";
	}		}
	description		description
	"This type is used for leafs that reference a route filter in		"This type is used for leafs that reference state data of a
	state data.";		route filter.";
			}
			typedef route-preference {
			type uint32;
			description
			"This type is used for route preferences.";
	}		}
	/* Groupings */		/* Groupings */
	grouping address-family {		grouping address-family {
	description		description
	"This grouping provides a leaf identifying an address		"This grouping provides a leaf identifying an address
	family.";		family.";
	leaf address-family {		leaf address-family {
	type identityref {		type identityref {
	base address-family;		base address-family;
	}		}
	mandatory "true";		mandatory "true";
	description		description
	"Address family.";		"Address family.";
	}		}
	}		}
	grouping state-entry-id {		grouping state-entry-id {
	description		description
	"This grouping defines a unique identifier for entries in		"This grouping provides a unique identifier for entries in
	several operational state lists.";		several operational state lists.";
	leaf id {		leaf id {
	type uint64;		type uint64;
	description		description
	"Unique numerical identifier of a list entry in operational		"Unique numerical identifier of a list entry in operational
	state. It may be used by protocols or tools that inspect		state. It may be used by protocols or tools that inspect
	and/or manipulate operational state data and prefer		and/or manipulate operational state data and prefer
	fixed-size integers as list entry handles.		fixed-size integers as list entry handles.
	These identifiers are always ephemeral, i.e., they may		These identifiers are always ephemeral, i.e., they may
	skipping to change at page 30, line 4		skipping to change at page 26, line 47
	leaf id {		leaf id {
	type uint64;		type uint64;
	description		description
	"Unique numerical identifier of a list entry in operational		"Unique numerical identifier of a list entry in operational
	state. It may be used by protocols or tools that inspect		state. It may be used by protocols or tools that inspect
	and/or manipulate operational state data and prefer		and/or manipulate operational state data and prefer
	fixed-size integers as list entry handles.		fixed-size integers as list entry handles.
	These identifiers are always ephemeral, i.e., they may		These identifiers are always ephemeral, i.e., they may
	change after a reboot.";		change after a reboot.";
	}		}
	}		}
	grouping router-id {		grouping router-id {
	description		description
	"This grouping provides the definition of router ID.";		"This grouping provides router ID.";
	leaf router-id {		leaf router-id {
	type yang:dotted-quad;		type yang:dotted-quad;
	description		description
	"Router ID - 32-bit number in the form of a dotted quad. Some		"A 32-bit number in the form of a dotted quad that is used by
	protocols use this parameter for identifying a router to its		some routing protocols identifying a router.";
	neighbors.";		reference
	}		"RFC 2328: OSPF Version 2.";
	}
	grouping outgoing-interface {
	description
	"This grouping defines the outgoing interface for use in
	next-hops.";
	leaf outgoing-interface {
	type leafref {
	path "/rt:routing-state/rt:routing-instance/rt:interfaces/"
	+ "rt:interface/rt:name";
	}
	description
	"Name of the outgoing interface.";
	}
	}
	grouping special-next-hop {
	description
	"This grouping provides the leaf for specifying special
	next-hop options.";
	leaf special-next-hop {
	type enumeration {
	enum blackhole {
	description
	"Silently discard the packet.";
	}
	enum unreachable {
	description
	"Discard the packet and notify the sender with an error
	message indicating that the destination host is
	unreachable.";
	}
	enum prohibit {
	description
	"Discard the packet and notify the sender with an error
	message indicating that the communication is
	administratively prohibited.";
	}
	enum receive {
	description
	"The packet will be received by the local network
	device.";
	}
	}
	description
	"Special next-hop options.";
	}		}
	}		}
	grouping next-hop-classifiers {		grouping next-hop-classifiers {
	description		description
	"This grouping provides two next-hop classifiers.";		"This grouping provides two next-hop classifiers.";
	leaf priority {		leaf priority {
	type enumeration {		type enumeration {
	enum primary {		enum primary {
	value "1";		value "1";
	skipping to change at page 32, line 14		skipping to change at page 28, line 12
	balancing. The number specifies the relative fraction of the		balancing. The number specifies the relative fraction of the
	traffic that will use the corresponding next-hop.		traffic that will use the corresponding next-hop.
	A value of 0 represents equal load-balancing.		A value of 0 represents equal load-balancing.
	If both primary and backup next-hops are present, then the		If both primary and backup next-hops are present, then the
	weights for each priority level are used separately.";		weights for each priority level are used separately.";
	}		}
	}		}
			grouping special-next-hop {
			description
			"This grouping provides a leaf with enumeration of special
			next-hops.";
			leaf special-next-hop {
			type enumeration {
			enum blackhole {
			description
			"Silently discard the packet.";
			}
			enum unreachable {
			description
			"Discard the packet and notify the sender with an error
			message indicating that the destination host is
			unreachable.";
			}
			enum prohibit {
			description
			"Discard the packet and notify the sender with an error
			message indicating that the communication is
			administratively prohibited.";
			}
			enum receive {
			description
			"The packet will be received by the local system.";
			}
			}
			description
			"Special next-hop options.";
			}
			}
	grouping next-hop-content {		grouping next-hop-content {
	description		description
	"Generic parameters of next-hops in routes.";		"Generic parameters of next-hops in static routes.";
	choice next-hop-options {		choice next-hop-options {
	mandatory "true";		mandatory "true";
	description		description
	"Options for expressing the next-hop in routes.";		"Options for next-hops in static routes.";
			case simple-next-hop {
			description
			"Simple next-hop is specified as an outgoing interface,
			next-hop address or both.
			Address-family-specific modules are expected to provide
			'next-hop-address' leaf via augmentation.";
			leaf outgoing-interface {
			type leafref {
			path "/rt:routing/rt:routing-instance/rt:interfaces/"
			+ "rt:interface/rt:name";
			}
			description
			"Name of the outgoing interface.";
			}
			}
	case special-next-hop {		case special-next-hop {
	uses special-next-hop;		uses special-next-hop;
	}		}
	case simple-next-hop {		}
	uses outgoing-interface;		}
			grouping next-hop-state-content {
			description
			"Generic parameters of next-hops in state data.";
			choice next-hop-options {
			mandatory "true";
			description
			"Options for next-hops in state data.";
			leaf next-hop-list {
			type next-hop-list-ref;
			description
			"Reference to a next-hop list.";
	}		}
	case next-hop-list {		leaf use-rib {
	if-feature multipath-routes;		type rib-state-ref;
	container next-hop-list {		description
	description		"Reference to a RIB in which a new look-up is to be
	"Container for multiple next-hops.";		performed.";
	list next-hop {		}
	key "id";		case simple-next-hop {
	description		description
	"An entry of a next-hop list.";		"Simple next-hop is specified as an outgoing interface,
	uses state-entry-id;		next-hop address or both.
	uses outgoing-interface;
	uses next-hop-classifiers;		Address-family-specific modules are expected to provide
			'next-hop-address' leaf via augmentation.";
			leaf outgoing-interface {
			type leafref {
			path "/rt:routing-state/rt:routing-instance/"
			+ "rt:interfaces/rt:interface/rt:name";
	}		}
			description
			"Name of the outgoing interface.";
	}		}
	}		}
			case special-next-hop {
			uses special-next-hop;
			}
	}		}
	}		}
	grouping route-metadata {		grouping route-metadata {
	description		description
	"Route metadata.";		"Route metadata.";
	leaf source-protocol {		leaf source-protocol {
	type identityref {		type identityref {
	base routing-protocol;		base routing-protocol;
	}		}
	mandatory "true";		mandatory "true";
	description		description
	"Type of the routing protocol from which the route		"Type of the routing protocol from which the route
	originated.";		originated.";
	}		}
			leaf active {
			type empty;
			description
			"Presence of this leaf indicates that the route is preferred
			among all routes in the same RIB that have the same
			destination prefix.";
			}
	leaf last-updated {		leaf last-updated {
	type yang:date-and-time;		type yang:date-and-time;
	description		description
	"Time stamp of the last modification of the route. If the		"Time stamp of the last modification of the route. If the
	route was never modified, it is the time when the route was		route was never modified, it is the time when the route was
	inserted into the RIB.";		inserted into the RIB.";
	}		}
	}		}
	/* Operational state data */		/* Operational state data */
	container routing-state {		container routing-state {
	config "false";		config "false";
	description		description
	"Operational state of the routing subsystem.";		"Operational state of the routing subsystem.";
	list routing-instance {		list routing-instance {
	key "name";		key "name";
	unique "id";		unique "id";
			min-elements "1";
	description		description
	"Each list entry is a container for operational state data of		"Each list entry is a container for operational state data of
	a routing instance.		a routing instance.
	An implementation MAY create one or more system-controlled		An implementation MAY create one or more system-controlled
	instances, other user-controlled instances MAY be created by		instances, other user-controlled instances MAY be created by
	configuration.";		configuration.";
	leaf name {		leaf name {
	type string;		type string;
	description		description
	skipping to change at page 33, line 49		skipping to change at page 31, line 28
	For system-controlled instances the name is persistent,		For system-controlled instances the name is persistent,
	i.e., it SHOULD NOT change across reboots.";		i.e., it SHOULD NOT change across reboots.";
	}		}
	uses state-entry-id {		uses state-entry-id {
	refine "id" {		refine "id" {
	mandatory "true";		mandatory "true";
	}		}
	}		}
	leaf type {		leaf type {
	type identityref {		type identityref {
	base routing-instance-type;		base routing-instance;
	}		}
	description		description
	"The routing instance type, primarily intended for		"The routing instance type.";
	discriminating among different types of logical routers,
	route virtualization, master-slave arrangements etc.,
	while keeping all routing instances in the same flat
	list.";
	}
	uses router-id {
	description
	"Global router ID.
	An implementation may choose a value if none is
	configured.
	Routing protocols that use router ID MAY override this
	global parameter.";
	}		}
	container default-ribs {		container default-ribs {
	description		description
	"Default RIBs used by the routing instance.";		"Default RIBs used by the routing instance.";
	list default-rib {		list default-rib {
	key "address-family";		key "address-family";
	description		description
	"Each list entry specifies the default RIB for one		"Each list entry specifies the default RIB for one
	address family.		address family.
	skipping to change at page 35, line 18		skipping to change at page 32, line 31
	description		description
	"A reference to the name of a configured network layer		"A reference to the name of a configured network layer
	interface.";		interface.";
	}		}
	}		}
	}		}
	container routing-protocols {		container routing-protocols {
	description		description
	"Container for the list of routing protocol instances.";		"Container for the list of routing protocol instances.";
	list routing-protocol {		list routing-protocol {
	key "name";		key "type name";
	description		description
	"Operational state of a routing protocol instance.		"Operational state of a routing protocol instance.
	An implementation MUST provide exactly one		An implementation MUST provide exactly one
	system-controlled instance of the type 'direct'. Other		system-controlled instance of the type 'direct'. Other
	instances MAY be created by configuration.";		instances MAY be created by configuration.";
			leaf type {
			type identityref {
			base routing-protocol;
			}
			description
			"Type of the routing protocol.";
			}
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"The name of the routing protocol instance.		"The name of the routing protocol instance.
	For system-controlled instances this name is		For system-controlled instances this name is
	persistent, i.e., it SHOULD NOT change across		persistent, i.e., it SHOULD NOT change across
	reboots.";		reboots.";
	}		}
	leaf type {		leaf route-preference {
	type identityref {		type route-preference;
	base routing-protocol;
	}
	mandatory "true";		mandatory "true";
	description		description
	"Type of the routing protocol.";		"The value of route preference (administrative
			distance) assigned to all routes generated by the
			routing protocol instance. A lower value means a more
			preferred route.";
	}		}
	container connected-ribs {		container connected-ribs {
	description		description
	"Container for connected RIBs.";		"Container for connected RIBs.";
	list connected-rib {		list connected-rib {
	key "rib-name";		key "rib-name";
	description		description
	"List of RIBs to which the routing protocol instance		"List of RIBs to which the routing protocol instance
	is connected (at most one RIB per address		is connected.
	family).";
			By default, routes learned by the routing protocol
			instance are installed in all connected RIBs of the
			matching address family, and, conversely, all routes
			from connected RIBs are installed in the routing
			protocol instance. However, routing protocols may
			specify other rules.";
	leaf rib-name {		leaf rib-name {
	type rib-state-ref;		type rib-state-ref;
	description		description
	"Name of an existing RIB.";		"Name of an existing RIB.";
	}		}
	leaf import-filter {		leaf import-filter {
	type route-filter-state-ref;		type route-filter-state-ref;
	description		description
	"Reference to a route filter that is used for		"Reference to a route filter that is used for
	filtering routes passed from this routing protocol		filtering routes passed from this routing protocol
	skipping to change at page 36, line 40		skipping to change at page 34, line 19
	routes are accepted.		routes are accepted.
	The 'direct' and 'static' pseudo-protocols accept		The 'direct' and 'static' pseudo-protocols accept
	no routes from any RIB.";		no routes from any RIB.";
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
			container next-hop-lists {
			description
			"Container for next-hop lists.";
			list next-hop-list {
			key "id";
			description
			"Next-hop list.";
			uses state-entry-id;
			uses address-family;
			list next-hop {
			description
			"Entry in a next-hop list.";
			uses next-hop-state-content;
			uses next-hop-classifiers;
			}
			}
			}
	container ribs {		container ribs {
	description		description
	"Container for RIBs.";		"Container for RIBs.";
	list rib {		list rib {
	key "name";		key "name";
	unique "id";		unique "id";
	description		description
	"Each entry represents a RIB identified by the 'name' key.		"Each entry represents a RIB identified by the 'name' key.
	All routes in a RIB MUST belong to the same address		All routes in a RIB MUST belong to the same address
	family.		family.
	skipping to change at page 37, line 20		skipping to change at page 35, line 16
	"The name of the RIB.";		"The name of the RIB.";
	}		}
	uses state-entry-id {		uses state-entry-id {
	refine "id" {		refine "id" {
	mandatory "true";		mandatory "true";
	}		}
	}		}
	uses address-family;		uses address-family;
	container routes {		container routes {
	description		description
	"Current contents of the RIB.";		"Current content of the RIB.";
	list route {		list route {
	key "id";
	description		description
	"A RIB route entry. This data node MUST be augmented		"A RIB route entry. This data node MUST be augmented
	with information specific for routes of each address		with information specific for routes of each address
	family.";		family.";
	uses state-entry-id;		leaf route-preference {
	uses next-hop-content;		type route-preference;
			description
			"This route attribute, also known as administrative
			distance, allows for selecting the preferred route
			among routes with the same destination prefix. A
			smaller value means a more preferred route.";
			}
			container next-hop {
			description
			"Route's next-hop attribute.";
			uses next-hop-state-content;
			}
	uses route-metadata;		uses route-metadata;
	}		}
	}		}
	container recipient-ribs {		container recipient-ribs {
	if-feature multiple-ribs;
	description		description
	"Container for recipient RIBs.";		"Container for recipient RIBs.";
	list recipient-rib {		list recipient-rib {
	key "rib-name";		key "rib-name";
	description		description
	"List of RIBs that receive routes from this RIB.";		"List of RIBs that receive routes from this RIB.";
	leaf rib-name {		leaf rib-name {
	type rib-state-ref;		type rib-state-ref;
	description		description
	"The name of the recipient RIB.";		"The name of the recipient RIB.";
	skipping to change at page 39, line 12		skipping to change at page 37, line 17
	For system-controlled entries, the value of this leaf must		For system-controlled entries, the value of this leaf must
	be the same as the name of the corresponding entry in		be the same as the name of the corresponding entry in
	state data.		state data.
	For user-controlled entries, an arbitrary name can be		For user-controlled entries, an arbitrary name can be
	used.";		used.";
	}		}
	leaf type {		leaf type {
	type identityref {		type identityref {
	base routing-instance-type;		base routing-instance;
	}		}
	default "rt:standard-routing-instance";		default "rt:default-routing-instance";
	description		description
	"The type of the routing instance.";		"The type of the routing instance.";
	}		}
	leaf enabled {		leaf enabled {
	type boolean;		type boolean;
	default "true";		default "true";
	description		description
	"Enable/disable the routing instance.		"Enable/disable the routing instance.
	If this parameter is false, the parent routing instance is		If this parameter is false, the parent routing instance is
	disabled and does not appear in operational state data,		disabled and does not appear in operational state data,
	despite any other configuration that might be present.";		despite any other configuration that might be present.";
	}		}
	uses router-id {		uses router-id {
			if-feature router-id;
	description		description
	"Configuration of the global router ID.";		"Configuration of the global router ID. Routing protocols
			that use router ID can use this parameter or override it
			with another value.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the routing instance.";		"Textual description of the routing instance.";
	}		}
	container default-ribs {		container default-ribs {
	if-feature multiple-ribs;		if-feature multiple-ribs;
	description		description
	"Configuration of the default RIBs used by the routing		"Configuration of the default RIBs used by the routing
	skipping to change at page 40, line 40		skipping to change at page 38, line 48
	description		description
	"A reference to the name of a configured network layer		"A reference to the name of a configured network layer
	interface.";		interface.";
	}		}
	}		}
	}		}
	container routing-protocols {		container routing-protocols {
	description		description
	"Configuration of routing protocol instances.";		"Configuration of routing protocol instances.";
	list routing-protocol {		list routing-protocol {
	key "name";		key "type name";
	description		description
	"Each entry contains configuration of a routing protocol		"Each entry contains configuration of a routing protocol
	instance.";		instance.";
			leaf type {
			type identityref {
			base routing-protocol;
			}
			description
			"Type of the routing protocol - an identity derived
			from the 'routing-protocol' base identity.";
			}
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"An arbitrary name of the routing protocol instance.";		"An arbitrary name of the routing protocol instance.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the routing protocol		"Textual description of the routing protocol
	instance.";		instance.";
	skipping to change at page 41, line 18		skipping to change at page 39, line 35
	type boolean;		type boolean;
	default "true";		default "true";
	description		description
	"Enable/disable the routing protocol instance.		"Enable/disable the routing protocol instance.
	If this parameter is false, the parent routing		If this parameter is false, the parent routing
	protocol instance is disabled and does not appear in		protocol instance is disabled and does not appear in
	operational state data, despite any other		operational state data, despite any other
	configuration that might be present.";		configuration that might be present.";
	}		}
	leaf type {		leaf route-preference {
	type identityref {		type route-preference;
	base routing-protocol;
	}
	mandatory "true";
	description		description
	"Type of the routing protocol - an identity derived		"The value of route preference (administrative
	from the 'routing-protocol' base identity.";		distance).
			The default value depends on the routing protocol
			type, and may also be implementation-dependent.";
	}		}
	container connected-ribs {		container connected-ribs {
	description		description
	"Configuration of connected RIBs.";		"Configuration of connected RIBs.";
	list connected-rib {		list connected-rib {
	must "not(/routing/ribs/rib[name=current()/"
	+ "preceding-sibling::connected-rib/"
	+ "rib-name and address-family=/routing/ribs/"
	+ "rib[name=current()/rib-name]/address-family])" {
	error-message
	"Duplicate address family for connected RIBs.";
	description
	"For each address family, there MUST NOT be more
	than one connected RIB.";
	}
	key "rib-name";		key "rib-name";
	description		description
	"List of RIBs to which the routing protocol instance		"Each entry configures a RIB to which the routing
	is connected (at most one RIB per address family).		protocol instance is connected.
	If no connected RIB is configured for an address		If no connected RIB is configured for an address
	family, the routing protocol is connected to the		family, the routing protocol is connected to the
	default RIB for that address family.";		default RIB for that address family.";
	leaf rib-name {		leaf rib-name {
	type rib-ref;		type rib-ref;
	must "../../../type != 'rt:direct' or "		must "../../../type != 'rt:direct' or "
	+ "../../../../../default-ribs/ "		+ "../../../../../default-ribs/ "
	+ "default-rib/rib-name=." {		+ "default-rib/rib-name=." {
	error-message "The 'direct' protocol can be "		error-message "The 'direct' protocol can be "
	skipping to change at page 42, line 36		skipping to change at page 40, line 43
	}		}
	container static-routes {		container static-routes {
	when "../type='rt:static'" {		when "../type='rt:static'" {
	description		description
	"This container is only valid for the 'static'		"This container is only valid for the 'static'
	routing protocol.";		routing protocol.";
	}		}
	description		description
	"Configuration of the 'static' pseudo-protocol.		"Configuration of the 'static' pseudo-protocol.
	Address family specific modules augment this node with		Address-family-specific modules augment this node with
	their lists of routes.";		their lists of routes.";
	}		}
	}		}
	}		}
	}		}
	container ribs {		container ribs {
	description		description
	"Configured RIBs.";		"Configuration of RIBs.";
	list rib {		list rib {
	key "name";		key "name";
	description		description
	"Each entry represents a configured RIB identified by the		"Each entry represents a configured RIB identified by the
	'name' key.		'name' key.
	Entries having the same key as a system-controlled entry		Entries having the same key as a system-controlled entry
	of the list /routing-state/ribs/rib are used for		of the list /routing-state/ribs/rib are used for
	configuring parameters of that entry. Other entries define		configuring parameters of that entry. Other entries define
	additional user-controlled RIBs.";		additional user-controlled RIBs.";
	skipping to change at page 44, line 44		skipping to change at page 42, line 51
	mandatory "true";		mandatory "true";
	description		description
	"Type of the route filter..";		"Type of the route filter..";
	}		}
	}		}
	}		}
	}		}
	/* RPC methods */		/* RPC methods */
	rpc active-route {		rpc fib-route {
	description		description
	"Return the active route that a routing-instance uses for		"Return the active FIB route that a routing-instance uses for
	sending packets to a destination address.";		sending packets to a destination address.";
	input {		input {
	leaf routing-instance-name {		leaf routing-instance-name {
	type routing-instance-state-ref;		type routing-instance-state-ref;
	mandatory "true";		mandatory "true";
	description		description
	"Name of the routing instance whose forwarding information		"Name of the routing instance whose forwarding information
	base is being queried.		base is being queried.
	If the routing instance with name equal to the value of		If the routing instance with name equal to the value of
	skipping to change at page 45, line 35		skipping to change at page 43, line 41
	"The active route for the specified destination.		"The active route for the specified destination.
	If the routing instance has no active route for the		If the routing instance has no active route for the
	destination address, no output is returned - the server		destination address, no output is returned - the server
	SHALL send an <rpc-reply> containing a single element		SHALL send an <rpc-reply> containing a single element
	<ok>.		<ok>.
	Address family specific modules MUST augment this list		Address family specific modules MUST augment this list
	with appropriate route contents.";		with appropriate route contents.";
	uses address-family;		uses address-family;
	uses next-hop-content;		container next-hop {
			description
			"Route's next-hop attribute.";
			uses next-hop-state-content;
			}
	uses route-metadata;		uses route-metadata;
	}		}
	}		}
	}		}
	rpc route-count {		rpc route-count {
	description		description
	"Return the current number of routes in a RIB.";		"Return the current number of routes in a RIB.";
	input {		input {
	leaf rib-name {		leaf rib-name {
	skipping to change at page 47, line 7		skipping to change at page 44, line 34
	"Number of routes in the RIB.";		"Number of routes in the RIB.";
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	8. IPv4 Unicast Routing Management YANG Module		8. IPv4 Unicast Routing Management YANG Module
	RFC Ed.: In this section, replace all occurrences of 'XXXX' with the		RFC Editor: In this section, replace all occurrences of 'XXXX' with
	actual RFC number and all occurrences of the revision date below with		the actual RFC number and all occurrences of the revision date below
	the date of RFC publication (and remove this note).		with the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-ipv4-unicast-routing@2014-05-24.yang"		<CODE BEGINS> file "ipv4-unicast-routing@2014-10-26.yang"
	module ietf-ipv4-unicast-routing {		module ietf-ipv4-unicast-routing {
	namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing";		namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing";
	prefix "v4ur";		prefix "v4ur";
	import ietf-routing {		import ietf-routing {
	prefix "rt";		prefix "rt";
	}		}
	skipping to change at page 48, line 12		skipping to change at page 45, line 41
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	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 the		This version of this YANG module is part of RFC XXXX; see the
	RFC itself for full legal notices.";		RFC itself for full legal notices.";
	revision 2014-05-24 {		revision 2014-10-26 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing Management";		"RFC XXXX: A YANG Data Model for Routing Management";
	}		}
	/* Identities */		/* Identities */
	identity ipv4-unicast {		identity ipv4-unicast {
	base rt:ipv4;		base rt:ipv4;
	skipping to change at page 48, line 44		skipping to change at page 46, line 24
	description		description
	"This leaf augments an IPv4 unicast route.";		"This leaf augments an IPv4 unicast route.";
	leaf destination-prefix {		leaf destination-prefix {
	type inet:ipv4-prefix;		type inet:ipv4-prefix;
	description		description
	"IPv4 destination prefix.";		"IPv4 destination prefix.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
	+ "rt:next-hop-options/rt:simple-next-hop" {		+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
	when "../../rt:address-family = 'v4ur:ipv4-unicast'" {		when "../../../rt:address-family = 'v4ur:ipv4-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"This leaf augments the 'simple-next-hop' case of IPv4 unicast		"This leaf augments the 'simple-next-hop' case of IPv4 unicast
	routes.";		routes.";
			leaf next-hop-address {
	leaf next-hop {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 address of the next-hop.";		"IPv4 address of the next-hop.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"		augment "/rt:routing-state/rt:next-hop-lists/rt:next-hop-list/"
	+ "rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/"		+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
	+ "rt:next-hop" {		when "../rt:address-family = 'v4ur:ipv4-unicast'" {
	when "../../../../rt:address-family = 'v4ur:ipv4-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	if-feature rt:multipath-routes;
	description		description
	"This leaf augments the 'next-hop-list' case of IPv4 unicast		"This leaf augments next-hop list with IPv4 next-hop address.
	routes.";		routes.";
	leaf address {		leaf next-hop-address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 address of the next-hop.";		"IPv4 address of the next-hop.";
	}		}
	}		}
	/* Configuration data */		/* Configuration data */
	augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"		augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
	+ "rt:routing-protocol/rt:static-routes" {		+ "rt:routing-protocol/rt:static-routes" {
	description		description
	"This augment defines the configuration of the 'static'		"This augment defines the configuration of the 'static'
	pseudo-protocol with data specific to IPv4 unicast.";		pseudo-protocol with data specific to IPv4 unicast.";
	skipping to change at page 49, line 42		skipping to change at page 47, line 20
	augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"		augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
	+ "rt:routing-protocol/rt:static-routes" {		+ "rt:routing-protocol/rt:static-routes" {
	description		description
	"This augment defines the configuration of the 'static'		"This augment defines the configuration of the 'static'
	pseudo-protocol with data specific to IPv4 unicast.";		pseudo-protocol with data specific to IPv4 unicast.";
	container ipv4 {		container ipv4 {
	description		description
	"Configuration of a 'static' pseudo-protocol instance		"Configuration of a 'static' pseudo-protocol instance
	consists of a list of routes.";		consists of a list of routes.";
	list route {		list route {
	key "id";		key "destination-prefix";
	ordered-by "user";		ordered-by "user";
	description		description
	"A user-ordered list of static routes.";		"A user-ordered list of static routes.";
	leaf id {		leaf destination-prefix {
	type uint32 {		type inet:ipv4-prefix;
	range "1..max";		mandatory "true";
	}
	description		description
	"Unique numeric identifier of the route.		"IPv4 destination prefix.";
	This value is unrelated to system-assigned 'id'
	parameters of routes in RIBs.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the route.";		"Textual description of the route.";
	}		}
	leaf destination-prefix {		container next-hop {
	type inet:ipv4-prefix;
	mandatory "true";
	description
	"IPv4 destination prefix.";
	}
	choice next-hop-options {
	mandatory "true";
	description		description
	"Options for expressing the next-hop in static routes.";		"Configuration of next-hop.";
	case special-next-hop {		grouping next-hop-content {
	uses rt:special-next-hop;		description
	}		"Next-hop content for IPv4 unicast static routes.";
	case simple-next-hop {		uses rt:next-hop-content {
	leaf next-hop {		augment "next-hop-options" {
	type inet:ipv4-address;
	description
	"IPv4 address of the next-hop.";
	}
	leaf outgoing-interface {
	type leafref {
	path "../../../../../../rt:interfaces/rt:interface/"
	+ "rt:name";
	}
	description
	"Name of the outgoing interface.
	Only interfaces configured for the ancestor routing
	instance can be given.";
	}
	}
	case next-hop-list {
	if-feature rt:multipath-routes;
	container next-hop-list {
	description
	"Configuration of multiple next-hops.";
	list next-hop {
	key "id";
	description		description
	"An entry of a next-hop list.";		"Add next-hop address case.";
			leaf next-hop-address {
	leaf id {
	type uint32;
	description
	"Unique numeric identifier of the entry.
	This value is unrelated to system-assigned 'id'
	parameters of next-hops in RIBs.";
	}
	leaf address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 address of the next-hop.";		"IPv4 address of the next-hop.";
	}		}
	leaf outgoing-interface {
	type leafref {
	path "../../../../../../../../rt:interfaces/"
	+ "rt:interface/rt:name";
	}
	description
	"Name of the outgoing interface.
	Only interfaces configured for the ancestor
	routing instance can be given.";
	}
	uses rt:next-hop-classifiers {
	refine "priority" {
	default "primary";
	}
	refine "weight" {
	default "0";
	}
	}
	}		}
	}		}
	}		}
			choice simple-or-list {
			description
			"Options for next-hops.";
			list multipath-entry {
			if-feature rt:multipath-routes;
			key "name";
			description
			"List of alternative next-hops.";
			leaf name {
			type string;
			description
			"A unique identifier of the next-hop entry.";
			}
			uses next-hop-content;
			uses rt:next-hop-classifiers;
			}
			case simple-next-hop {
			uses next-hop-content;
			}
			}
	}		}
	}		}
	}		}
	}		}
	/* RPC methods */		/* RPC methods */
	augment "/rt:active-route/rt:input/rt:destination-address" {		augment "/rt:fib-route/rt:input/rt:destination-address" {
	when "rt:address-family='v4ur:ipv4-unicast'" {		when "rt:address-family='v4ur:ipv4-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"This leaf augments the 'rt:destination-address' parameter of		"This leaf augments the 'rt:destination-address' parameter of
	the 'rt:active-route' operation.";		the 'rt:fib-route' operation.";
	leaf address {		leaf address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 destination address.";		"IPv4 destination address.";
	}		}
	}		}
	augment "/rt:active-route/rt:output/rt:route" {		augment "/rt:fib-route/rt:output/rt:route" {
	when "rt:address-family='v4ur:ipv4-unicast'" {		when "rt:address-family='v4ur:ipv4-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"This leaf augments the reply to the 'rt:active-route'		"This leaf augments the reply to the 'rt:fib-route'
	operation.";		operation.";
	leaf destination-prefix {		leaf destination-prefix {
	type inet:ipv4-prefix;		type inet:ipv4-prefix;
	description		description
	"IPv4 destination prefix.";		"IPv4 destination prefix.";
	}		}
	}		}
	augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/"		augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/"
	+ "rt:simple-next-hop" {		+ "rt:next-hop-options/rt:simple-next-hop" {
	when "rt:address-family='v4ur:ipv4-unicast'" {		when "../rt:address-family='v4ur:ipv4-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"This leaf augments the 'simple-next-hop' case in the reply to		"This leaf augments the 'simple-next-hop' case in the reply to
	the 'rt:active-route' operation.";		the 'rt:fib-route' operation.";
	leaf next-hop {		leaf next-hop-address {
	type inet:ipv4-address;
	description
	"IPv4 address of the next-hop.";
	}
	}
	augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/"
	+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
	when "../../rt:address-family='v4ur:ipv4-unicast'" {
	description
	"This augment is valid only for IPv4 unicast.";
	}
	if-feature rt:multipath-routes;
	description
	"This leaf augments the 'next-hop-list' case in the reply to
	the 'rt:active-route' operation.";
	leaf address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 address of the next-hop.";		"IPv4 address of the next-hop.";
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	9. IPv6 Unicast Routing Management YANG Module		9. IPv6 Unicast Routing Management YANG Module
	RFC Ed.: In this section, replace all occurrences of 'XXXX' with the		RFC Editor: In this section, replace all occurrences of 'XXXX' with
	actual RFC number and all occurrences of the revision date below with		the actual RFC number and all occurrences of the revision date below
	the date of RFC publication (and remove this note).		with the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-ipv6-unicast-routing@2014-05-25.yang"		<CODE BEGINS> file "ipv6-unicast-routing@2014-10-26.yang"
	module ietf-ipv6-unicast-routing {		module ietf-ipv6-unicast-routing {
	namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing";		namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing";
	prefix "v6ur";		prefix "v6ur";
	import ietf-routing {		import ietf-routing {
	prefix "rt";		prefix "rt";
	}		}
	skipping to change at page 55, line 20		skipping to change at page 50, line 49
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	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 the		This version of this YANG module is part of RFC XXXX; see the
	RFC itself for full legal notices.";		RFC itself for full legal notices.";
	revision 2014-05-25 {		revision 2014-10-26 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing Management";		"RFC XXXX: A YANG Data Model for Routing Management";
	}		}
	/* Identities */		/* Identities */
	identity ipv6-unicast {		identity ipv6-unicast {
	base rt:ipv6;		base rt:ipv6;
	skipping to change at page 58, line 47		skipping to change at page 54, line 27
	description		description
	"This leaf augments an IPv6 unicast route.";		"This leaf augments an IPv6 unicast route.";
	leaf destination-prefix {		leaf destination-prefix {
	type inet:ipv6-prefix;		type inet:ipv6-prefix;
	description		description
	"IPv6 destination prefix.";		"IPv6 destination prefix.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
	+ "rt:next-hop-options/rt:simple-next-hop" {		+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
	when "../../rt:address-family = 'v6ur:ipv6-unicast'" {		when "../../../rt:address-family = 'v6ur:ipv6-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"This leaf augments the 'simple-next-hop' case of IPv6 unicast		"This leaf augments the 'simple-next-hop' case of IPv6 unicast
	routes.";		routes.";
	leaf next-hop {		leaf next-hop {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 address of the next-hop.";		"IPv6 address of the next-hop.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"		augment "/rt:routing-state/rt:next-hop-lists/rt:next-hop-list/"
	+ "rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/"		+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
	+ "rt:next-hop" {		when "../rt:address-family = 'v6ur:ipv6-unicast'" {
	when "../../../../rt:address-family = 'v6ur:ipv6-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	if-feature rt:multipath-routes;
	description		description
	"This leaf augments the 'next-hop-list' case of IPv6 unicast		"This leaf augments next-hop list with IPv6 next-hop address.
	routes.";		routes.";
	leaf address {		leaf next-hop-address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 address of the next-hop.";		"IPv6 address of the next-hop.";
	}		}
	}		}
	/* Configuration data */		/* Configuration data */
	augment		augment
	"/rt:routing/rt:routing-instance/rt:interfaces/rt:interface" {		"/rt:routing/rt:routing-instance/rt:interfaces/rt:interface" {
	skipping to change at page 65, line 10		skipping to change at page 60, line 36
	augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"		augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
	+ "rt:routing-protocol/rt:static-routes" {		+ "rt:routing-protocol/rt:static-routes" {
	description		description
	"This augment defines the configuration of the 'static'		"This augment defines the configuration of the 'static'
	pseudo-protocol with data specific to IPv6 unicast.";		pseudo-protocol with data specific to IPv6 unicast.";
	container ipv6 {		container ipv6 {
	description		description
	"Configuration of a 'static' pseudo-protocol instance		"Configuration of a 'static' pseudo-protocol instance
	consists of a list of routes.";		consists of a list of routes.";
	list route {		list route {
	key "id";		key "destination-prefix";
	ordered-by "user";		ordered-by "user";
	description		description
	"A user-ordered list of static routes.";		"A user-ordered list of static routes.";
	leaf id {		leaf destination-prefix {
	type uint32 {		type inet:ipv6-prefix;
	range "1..max";		mandatory "true";
	}
	description		description
	"Unique numeric identifier of the route.		"IPv6 destination prefix.";
	This value is unrelated to system-assigned 'id'
	parameters of routes in RIBs.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the route.";		"Textual description of the route.";
	}		}
	leaf destination-prefix {		container next-hop {
	type inet:ipv6-prefix;
	mandatory "true";
	description
	"IPv6 destination prefix.";
	}
	choice next-hop-options {
	mandatory "true";
	description		description
	"Options for expressing the next-hop in static routes.";		"Configuration of next-hop.";
	case special-next-hop {		grouping next-hop-content {
	uses rt:special-next-hop;		description
	}		"Next-hop content for IPv6 unicast static routes.";
	case simple-next-hop {		uses rt:next-hop-content {
	leaf next-hop {		augment "next-hop-options" {
	type inet:ipv6-address;
	description
	"IPv6 address of the next-hop.";
	}
	leaf outgoing-interface {
	type leafref {
	path "../../../../../../rt:interfaces/rt:interface/"
	+ "rt:name";
	}
	description
	"Name of the outgoing interface.
	Only interfaces configured for the ancestor routing
	instance can be given.";
	}
	}
	case next-hop-list {
	if-feature rt:multipath-routes;
	container next-hop-list {
	description
	"Configuration of multiple next-hops.";
	list next-hop {
	key "id";
	description		description
	"An entry of a next-hop list.";		"Add next-hop address case.";
	leaf id {		leaf next-hop-address {
	type uint32;
	description
	"Unique numeric identifier of the entry.
	This value is unrelated to system-assigned 'id'
	parameters of next-hops in RIBs.";
	}
	leaf address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 address of the next-hop.";		"IPv6 address of the next-hop.";
	}		}
	leaf outgoing-interface {
	type leafref {
	path "../../../../../../../../rt:interfaces/"
	+ "rt:interface/rt:name";
	}
	description
	"Name of the outgoing interface.
	Only interfaces configured for the ancestor
	routing instance can be given.";
	}
	uses rt:next-hop-classifiers {
	refine "priority" {
	default "primary";
	}
	refine "weight" {
	default "0";
	}
	}
	}		}
	}		}
	}		}
			choice simple-or-list {
			description
			"Options for next-hops.";
			list multipath-entry {
			if-feature rt:multipath-routes;
			key "name";
			description
			"List of alternative next-hops.";
			leaf name {
			type string;
			description
			"A unique identifier of the next-hop entry.";
			}
			uses next-hop-content;
			uses rt:next-hop-classifiers;
			}
			case simple-next-hop {
			uses next-hop-content;
			}
			}
	}		}
	}		}
	}		}
	}		}
	/* RPC methods */		/* RPC methods */
	augment "/rt:active-route/rt:input/rt:destination-address" {		augment "/rt:fib-route/rt:input/rt:destination-address" {
	when "rt:address-family='v6ur:ipv6-unicast'" {		when "rt:address-family='v6ur:ipv6-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"This leaf augments the 'rt:destination-address' parameter of		"This leaf augments the 'rt:destination-address' parameter of
	the 'rt:active-route' operation.";		the 'rt:fib-route' operation.";
	leaf address {		leaf address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 destination address.";		"IPv6 destination address.";
	}		}
	}		}
	augment "/rt:active-route/rt:output/rt:route" {		augment "/rt:fib-route/rt:output/rt:route" {
	when "rt:address-family='v6ur:ipv6-unicast'" {		when "rt:address-family='v6ur:ipv6-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"This leaf augments the reply to the 'rt:active-route'		"This leaf augments the reply to the 'rt:fib-route'
	operation.";		operation.";
	leaf destination-prefix {		leaf destination-prefix {
	type inet:ipv6-prefix;		type inet:ipv6-prefix;
	description		description
	"IPv6 destination prefix.";		"IPv6 destination prefix.";
	}		}
	}		}
	augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/"		augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/"
	+ "rt:simple-next-hop" {		+ "rt:next-hop-options/rt:simple-next-hop" {
	when "rt:address-family='v6ur:ipv6-unicast'" {		when "../rt:address-family='v4ur:ipv6-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"This leaf augments the 'simple-next-hop' case in the reply to		"This leaf augments the 'simple-next-hop' case in the reply to
	the 'rt:active-route' operation.";		the 'rt:fib-route' operation.";
	leaf next-hop {		leaf next-hop-address {
	type inet:ipv6-address;
	description
	"IPv6 address of the next-hop.";
	}
	}
	augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/"
	+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
	when "../../rt:address-family='v6ur:ipv6-unicast'" {
	description
	"This augment is valid only for IPv6 unicast.";
	}
	if-feature rt:multipath-routes;
	description
	"This leaf augments the 'next-hop-list' case in the reply to
	the 'rt:active-route' operation.";
	leaf address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 address of the next-hop.";		"IPv6 address of the next-hop.";
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	10. IANA Considerations		10. IANA Considerations
	skipping to change at page 71, line 17		skipping to change at page 64, line 38
	Configuration and state data conforming to the core routing data		Configuration and state data conforming to the core routing data
	model (defined in this document) are designed to be accessed via the		model (defined in this document) are designed to be accessed via the
	NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure		NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure
	transport layer and the mandatory-to-implement secure transport is		transport layer and the mandatory-to-implement secure transport is
	SSH [RFC6242]. The NETCONF access control model [RFC6536] provides		SSH [RFC6242]. The NETCONF access control model [RFC6536] provides
	the means to restrict access for particular NETCONF users to a pre-		the means to restrict access for particular NETCONF users to a pre-
	configured subset of all available NETCONF protocol operations and		configured subset of all available NETCONF protocol operations and
	content.		content.
	A number of data nodes defined in the YANG modules belonging to the		A number of data nodes defined in the YANG modules belonging to the
	configuration part of the core routing data model are writable/		configuration part of the core routing data model are
	creatable/deletable (i.e., "config true" in YANG terms, which is the		writable/creatable/deletable (i.e., "config true" in YANG terms,
	default). These data nodes may be considered sensitive or vulnerable		which is the default). These data nodes may be considered sensitive
	in some network environments. Write operations to these data nodes,		or vulnerable in some network environments. Write operations to
	such as "edit-config", can have negative effects on the network if		these data nodes, such as "edit-config", can have negative effects on
	the protocol operations are not properly protected.		the network if the protocol operations are not properly protected.
	The vulnerable "config true" subtrees and data nodes are the		The vulnerable "config true" subtrees and data nodes are the
	following:		following:
	/routing/routing-instance/interfaces/interface: This list assigns a		/routing/routing-instance/interfaces/interface: This list assigns a
	network layer interface to a routing instance and may also specify		network layer interface to a routing instance and may also specify
	interface parameters related to routing.		interface parameters related to routing.
	/routing/routing-instance/routing-protocols/routing-protocol: This		/routing/routing-instance/routing-protocols/routing-protocol: This
	list specifies the routing protocols configured on a device.		list specifies the routing protocols configured on a device.
	skipping to change at page 72, line 7		skipping to change at page 65, line 22
	/routing/ribs/rib: This list specifies the RIBs configured for the		/routing/ribs/rib: This list specifies the RIBs configured for the
	device.		device.
	Unauthorized access to any of these lists can adversely affect the		Unauthorized access to any of these lists can adversely affect the
	routing subsystem of both the local device and the network. This may		routing subsystem of both the local device and the network. This may
	lead to network malfunctions, delivery of packets to inappropriate		lead to network malfunctions, delivery of packets to inappropriate
	destinations and other problems.		destinations and other problems.
	12. Acknowledgments		12. Acknowledgments
	The author wishes to thank Nitin Bahadur, Martin Bjorklund,		The author wishes to thank Nitin Bahadur, Martin Bjorklund, Dean
	Joel Halpern, Wes Hardaker, Sriganesh Kini, David Lamparter,		Bogdanovic, Joel Halpern, Wes Hardaker, Sriganesh Kini,
	Andrew McGregor, Jan Medved, Xiang Li, Thomas Morin, Tom Petch,		David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Acee Lindem,
	Bruno Rijsman, Juergen Schoenwaelder, Phil Shafer, Dave Thaler and		Stephane Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman,
	Yi Yang for their helpful comments and suggestions.		Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man-
			Kit Yeung and Jeffrey Zhang for their helpful comments and
			suggestions.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
	Network Configuration Protocol (NETCONF)", RFC 6020,		Network Configuration Protocol (NETCONF)", RFC 6020,
	September 2010.		October 2010.
	[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.		[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
	Bierman, "NETCONF Configuration Protocol", RFC 6241,		Bierman, "Network Configuration Protocol (NETCONF)", RFC
	June 2011.		6241, June 2011.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
	RFC 6991, July 2013.		July 2013.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, May 2014.		Management", RFC 7223, May 2014.
	[YANG-IP] Bjorklund, M., "A YANG Data Model for IP Management",		[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC
	draft-ietf-netmod-ip-cfg-14 (work in progress),		7277, June 2014.
	March 2014.
	13.2. Informative References		13.2. Informative References
			[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
			Networks (VPNs)", RFC 4364, February 2006.
	[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG		[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
	Data Model Documents", RFC 6087, January 2011.		Data Model Documents", RFC 6087, January 2011.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, June 2011.		Shell (SSH)", RFC 6242, June 2011.
	[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, March
	March 2012.		2012.
	Appendix A. The Complete Data Trees		Appendix A. The Complete Data Trees
	This appendix presents the complete configuration and operational		This appendix presents the complete configuration and state data
	state data trees of the core routing data model.		trees of the core routing data model.
	See Section 2.2 for an explanation of the symbols used. Data type of		See Section 2.2 for an explanation of the symbols used. Data type of
	every leaf node is shown near the right end of the corresponding		every leaf node is shown near the right end of the corresponding
	line.		line.
	A.1. Configuration Data		A.1. Configuration Data
	+--rw routing		+--rw routing
	+--rw routing-instance* [name]		+--rw routing-instance* [name]
	| +--rw name string		| +--rw name string
	| +--rw type? identityref		| +--rw type? identityref
	| +--rw enabled? boolean		| +--rw enabled? boolean
	| +--rw router-id? yang:dotted-quad		| +--rw router-id? yang:dotted-quad
	| +--rw description? string		| +--rw description? string
	| +--rw default-ribs {multiple-ribs}?		| +--rw default-ribs {multiple-ribs}?
	| | +--rw default-rib* [address-family]		| | +--rw default-rib* [address-family]
	| | +--rw address-family identityref		| | +--rw address-family identityref
	| | +--rw rib-name string		| | +--rw rib-name string
	| +--rw interfaces		| +--rw interfaces
	| | +--rw interface* [name]		| | +--rw interface* [name]
	| | +--rw name if:interface-ref		| | +--rw name if:interface-ref
	| | +--rw v6ur:ipv6-router-advertisements		| | +--rw v6ur:ipv6-router-advertisements
	| | +--rw v6ur:send-advertisements? boolean		| | +--rw v6ur:send-advertisements? boolean
	| | +--rw v6ur:max-rtr-adv-interval? uint16		| | +--rw v6ur:max-rtr-adv-interval? uint16
	| | +--rw v6ur:min-rtr-adv-interval? uint16		| | +--rw v6ur:min-rtr-adv-interval? uint16
	| | +--rw v6ur:managed-flag? boolean		| | +--rw v6ur:managed-flag? boolean
	| | +--rw v6ur:other-config-flag? boolean		| | +--rw v6ur:other-config-flag? boolean
	| | +--rw v6ur:link-mtu? uint32		| | +--rw v6ur:link-mtu? uint32
	| | +--rw v6ur:reachable-time? uint32		| | +--rw v6ur:reachable-time? uint32
	| | +--rw v6ur:retrans-timer? uint32		| | +--rw v6ur:retrans-timer? uint32
	| | +--rw v6ur:cur-hop-limit? uint8		| | +--rw v6ur:cur-hop-limit? uint8
	| | +--rw v6ur:default-lifetime? uint16		| | +--rw v6ur:default-lifetime? uint16
	| | +--rw v6ur:prefix-list		| | +--rw v6ur:prefix-list
	| | +--rw v6ur:prefix* [prefix-spec]		| | +--rw v6ur:prefix* [prefix-spec]
	| | +--rw v6ur:prefix-spec inet:ipv6-prefix		| | +--rw v6ur:prefix-spec inet:ipv6-prefix
	| | +--rw (control-adv-prefixes)?		| | +--rw (control-adv-prefixes)?
	| | +--:(no-advertise)		| | +--:(no-advertise)
	| | | +--rw v6ur:no-advertise? empty		| | | +--rw v6ur:no-advertise? empty
	| | +--:(advertise)		| | +--:(advertise)
	| | +--rw v6ur:valid-lifetime? uint32		| | +--rw v6ur:valid-lifetime? uint32
	| | +--rw v6ur:on-link-flag? boolean		| | +--rw v6ur:on-link-flag? boolean
	| | +--rw v6ur:preferred-lifetime? uint32		| | +--rw v6ur:preferred-lifetime? uint32
	| | +--rw v6ur:autonomous-flag? boolean		| | +--rw v6ur:autonomous-flag? boolean
	| +--rw routing-protocols		| +--rw routing-protocols
	| +--rw routing-protocol* [name]		| +--rw routing-protocol* [type name]
	| +--rw name string		| +--rw type identityref
	| +--rw description? string		| +--rw name string
	| +--rw enabled? boolean		| +--rw description? string
	| +--rw type identityref		| +--rw enabled? boolean
	| +--rw connected-ribs		| +--rw route-preference? route-preference
	| | +--rw connected-rib* [rib-name]		| +--rw connected-ribs
	| | +--rw rib-name rib-ref		| | +--rw connected-rib* [rib-name]
	| | +--rw import-filter? route-filter-ref		| | +--rw rib-name rib-ref
	| | +--rw export-filter? route-filter-ref		| | +--rw import-filter? route-filter-ref
	| +--rw static-routes		| | +--rw export-filter? route-filter-ref
	| +--rw v4ur:ipv4		| +--rw static-routes
	| | +--rw v4ur:route* [id]		| +--rw v4ur:ipv4
	| | +--rw v4ur:id uint32		| | +--rw v4ur:route* [destination-prefix]
	| | +--rw v4ur:description? string		| | +--rw v4ur:destination-prefix inet:ipv4-prefix
	| | +--rw v4ur:destination-prefix inet:ipv4-prefix		| | +--rw v4ur:description? string
	| | +--rw (next-hop-options)		| | +--rw v4ur:next-hop
	| | +--:(special-next-hop)		| | +--rw (simple-or-list)?
	| | | +--rw v4ur:special-next-hop? enumeration		| | +--:(multipath-entry)
	| | +--:(simple-next-hop)		| | | +--rw v4ur:multipath-entry* [name]
	| | | +--rw v4ur:next-hop? inet:ipv4-address		| | | +--rw v4ur:name string
	| | | +--rw v4ur:outgoing-interface? leafref		| | | +--rw (next-hop-options)
	| | +--:(next-hop-list) {rt:multipath-routes}?		| | | | +--:(simple-next-hop)
	| | +--rw v4ur:next-hop-list		| | | | | +--rw v4ur:outgoing-interface?
	| | +--rw v4ur:next-hop* [id]		| | | | +--:(special-next-hop)
	| | +--rw v4ur:id uint32		| | | | | +--rw v4ur:special-next-hop?
	| | +--rw v4ur:address? inet:ipv4-address		| | | | +--:(next-hop-address)
	| | +--rw v4ur:outgoing-interface? leafref		| | | | +--rw v4ur:next-hop-address?
	| | +--rw v4ur:priority? enumeration		| | | +--rw v4ur:priority?
	| | +--rw v4ur:weight? uint8		| | | +--rw v4ur:weight? uint8
	| +--rw v6ur:ipv6		| | +--:(simple-next-hop)
	| +--rw v6ur:route* [id]		| | +--rw (next-hop-options)
	| +--rw v6ur:id uint32		| | +--:(simple-next-hop)
	| +--rw v6ur:description? string		| | | +--rw v4ur:outgoing-interface?
	| +--rw v6ur:destination-prefix inet:ipv6-prefix		| | +--:(special-next-hop)
	| +--rw (next-hop-options)		| | | +--rw v4ur:special-next-hop?
	| +--:(special-next-hop)		| | +--:(next-hop-address)
	| | +--rw v6ur:special-next-hop? enumeration		| | +--rw v4ur:next-hop-address?
	| +--:(simple-next-hop)		| +--rw v6ur:ipv6
	| | +--rw v6ur:next-hop? inet:ipv6-address		| +--rw v6ur:route* [destination-prefix]
	| | +--rw v6ur:outgoing-interface? leafref		| +--rw v6ur:destination-prefix inet:ipv6-prefix
	| +--:(next-hop-list) {rt:multipath-routes}?		| +--rw v6ur:description? string
	| +--rw v6ur:next-hop-list		| +--rw v6ur:next-hop
	| +--rw v6ur:next-hop* [id]		| +--rw (simple-or-list)?
	| +--rw v6ur:id uint32		| +--:(multipath-entry)
	| +--rw v6ur:address? inet:ipv6-address		| | +--rw v6ur:multipath-entry* [name]
	| +--rw v6ur:outgoing-interface? leafref		| | +--rw v6ur:name string
	| +--rw v6ur:priority? enumeration		| | +--rw (next-hop-options)
	| +--rw v6ur:weight? uint8		| | | +--:(simple-next-hop)
	+--rw ribs		| | | | +--rw v6ur:outgoing-interface?
	| +--rw rib* [name]		| | | +--:(special-next-hop)
	| +--rw name string		| | | | +--rw v6ur:special-next-hop?
	| +--rw address-family identityref		| | | +--:(next-hop-address)
	| +--rw description? string		| | | +--rw v6ur:next-hop-address?
	| +--rw recipient-ribs {multiple-ribs}?		| | +--rw v6ur:priority?
	| +--rw recipient-rib* [rib-name]		| | +--rw v6ur:weight? uint8
	| +--rw rib-name rib-ref		| +--:(simple-next-hop)
	| +--rw filter? route-filter-ref		| +--rw (next-hop-options)
	+--rw route-filters		| +--:(simple-next-hop)
	+--rw route-filter* [name]		| | +--rw v6ur:outgoing-interface?
	+--rw name string		| +--:(special-next-hop)
	+--rw description? string		| | +--rw v6ur:special-next-hop?
	+--rw type identityref		| +--:(next-hop-address)
			| +--rw v6ur:next-hop-address?
			+--rw ribs
			| +--rw rib* [name]
			| +--rw name string
			| +--rw address-family identityref
			| +--rw description? string
			| +--rw recipient-ribs {multiple-ribs}?
			| +--rw recipient-rib* [rib-name]
			| +--rw rib-name rib-ref
			| +--rw filter? route-filter-ref
			+--rw route-filters
			+--rw route-filter* [name]
			+--rw name string
			+--rw description? string
			+--rw type identityref
	A.2. Operational State Data		A.2. State Data
	+--ro routing-state		+--ro routing-state
	+--ro routing-instance* [name]		+--ro routing-instance* [name]
	| +--ro name string		| +--ro name string
	| +--ro id uint64		| +--ro id uint64
	| +--ro type? identityref		| +--ro type? identityref
	| +--ro router-id? yang:dotted-quad
	| +--ro default-ribs		| +--ro default-ribs
	| | +--ro default-rib* [address-family]		| | +--ro default-rib* [address-family]
	| | +--ro address-family identityref		| | +--ro address-family identityref
	| | +--ro rib-name rib-state-ref		| | +--ro rib-name rib-state-ref
	| +--ro interfaces		| +--ro interfaces
	| | +--ro interface* [name]		| | +--ro interface* [name]
	| | +--ro name if:interface-state-ref		| | +--ro name if:interface-state-ref
	| | +--ro v6ur:ipv6-router-advertisements		| | +--ro v6ur:ipv6-router-advertisements
	| | +--ro v6ur:send-advertisements? boolean		| | +--ro v6ur:send-advertisements? boolean
	| | +--ro v6ur:max-rtr-adv-interval? uint16		| | +--ro v6ur:max-rtr-adv-interval? uint16
	| | +--ro v6ur:min-rtr-adv-interval? uint16		| | +--ro v6ur:min-rtr-adv-interval? uint16
	| | +--ro v6ur:managed-flag? boolean		| | +--ro v6ur:managed-flag? boolean
	| | +--ro v6ur:other-config-flag? boolean		| | +--ro v6ur:other-config-flag? boolean
	| | +--ro v6ur:link-mtu? uint32		| | +--ro v6ur:link-mtu? uint32
	| | +--ro v6ur:reachable-time? uint32		| | +--ro v6ur:reachable-time? uint32
	| | +--ro v6ur:retrans-timer? uint32		| | +--ro v6ur:retrans-timer? uint32
	| | +--ro v6ur:cur-hop-limit? uint8		| | +--ro v6ur:cur-hop-limit? uint8
	| | +--ro v6ur:default-lifetime? uint16		| | +--ro v6ur:default-lifetime? uint16
	| | +--ro v6ur:prefix-list		| | +--ro v6ur:prefix-list
	| | +--ro v6ur:prefix* [prefix-spec]		| | +--ro v6ur:prefix* [prefix-spec]
	| | +--ro v6ur:prefix-spec inet:ipv6-prefix		| | +--ro v6ur:prefix-spec inet:ipv6-prefix
	| | +--ro v6ur:valid-lifetime? uint32		| | +--ro v6ur:valid-lifetime? uint32
	| | +--ro v6ur:on-link-flag? boolean		| | +--ro v6ur:on-link-flag? boolean
	| | +--ro v6ur:preferred-lifetime? uint32		| | +--ro v6ur:preferred-lifetime? uint32
	| | +--ro v6ur:autonomous-flag? boolean		| | +--ro v6ur:autonomous-flag? boolean
	| +--ro routing-protocols		| +--ro routing-protocols
	| +--ro routing-protocol* [name]		| +--ro routing-protocol* [type name]
	| +--ro name string		| +--ro type identityref
	| +--ro type identityref		| +--ro name string
			| +--ro route-preference route-preference
	| +--ro connected-ribs		| +--ro connected-ribs
	| +--ro connected-rib* [rib-name]		| +--ro connected-rib* [rib-name]
	| +--ro rib-name rib-state-ref		| +--ro rib-name rib-state-ref
	| +--ro import-filter? route-filter-state-ref		| +--ro import-filter? route-filter-state-ref
	| +--ro export-filter? route-filter-state-ref		| +--ro export-filter? route-filter-state-ref
			+--ro next-hop-lists
			| +--ro next-hop-list* [id]
			| +--ro id uint64
			| +--ro address-family identityref
			| +--ro next-hop*
			| +--ro (next-hop-options)
			| | +--:(next-hop-list)
			| | | +--ro next-hop-list? next-hop-list-ref
			| | +--:(use-rib)
			| | | +--ro use-rib? rib-state-ref
			| | +--:(simple-next-hop)
			| | | +--ro outgoing-interface?
			| | | +--ro v4ur:next-hop-address? inet:ipv4-address
			| | | +--ro v6ur:next-hop-address? inet:ipv6-address
			| | +--:(special-next-hop)
			| | +--ro special-next-hop? enumeration
			| +--ro priority? enumeration
			| +--ro weight? uint8
	+--ro ribs		+--ro ribs
	| +--ro rib* [name]		| +--ro rib* [name]
	| +--ro name string		| +--ro name string
	| +--ro id uint64		| +--ro id uint64
	| +--ro address-family identityref		| +--ro address-family identityref
	| +--ro routes		| +--ro routes
	| | +--ro route* [id]		| | +--ro route*
	| | +--ro id uint64		| | +--ro route-preference? route-preference
	| | +--ro (next-hop-options)		| | +--ro next-hop
	| | | +--:(special-next-hop)		| | | +--ro (next-hop-options)
	| | | | +--ro special-next-hop? enumeration		| | | +--:(next-hop-list)
	| | | +--:(simple-next-hop)		| | | | +--ro next-hop-list? next-hop-list-ref
	| | | | +--ro outgoing-interface? leafref		| | | +--:(use-rib)
	| | | | +--ro v4ur:next-hop? inet:ipv4-address		| | | | +--ro use-rib? rib-state-ref
	| | | | +--ro v6ur:next-hop? inet:ipv6-address		| | | +--:(simple-next-hop)
	| | | +--:(next-hop-list) {multipath-routes}?		| | | | +--ro outgoing-interface?
	| | | +--ro next-hop-list		| | | | +--ro v4ur:next-hop-address?
	| | | +--ro next-hop* [id]		| | | | +--ro v6ur:next-hop?
	| | | +--ro id uint64		| | | +--:(special-next-hop)
	| | | +--ro outgoing-interface? leafref		| | | +--ro special-next-hop? enumeration
	| | | +--ro priority? enumeration
	| | | +--ro weight? uint8
	| | | +--ro v4ur:address? inet:ipv4-address
	| | | +--ro v6ur:address? inet:ipv6-address
	| | +--ro source-protocol identityref		| | +--ro source-protocol identityref
			| | +--ro active? empty
	| | +--ro last-updated? yang:date-and-time		| | +--ro last-updated? yang:date-and-time
	| | +--ro v4ur:destination-prefix? inet:ipv4-prefix		| | +--ro v4ur:destination-prefix? inet:ipv4-prefix
	| | +--ro v6ur:destination-prefix? inet:ipv6-prefix		| | +--ro v6ur:destination-prefix? inet:ipv6-prefix
	| +--ro recipient-ribs {multiple-ribs}?		| +--ro recipient-ribs
	| +--ro recipient-rib* [rib-name]		| +--ro recipient-rib* [rib-name]
	| +--ro rib-name rib-state-ref		| +--ro rib-name rib-state-ref
	| +--ro filter? route-filter-state-ref		| +--ro filter? route-filter-state-ref
	+--ro route-filters		+--ro route-filters
	+--ro route-filter* [name]		+--ro route-filter* [name]
	+--ro name string		+--ro name string
	+--ro type identityref		+--ro type identityref
	Appendix B. Minimum Implementation		Appendix B. Minimum Implementation
	skipping to change at page 78, line 23		skipping to change at page 71, line 27
	A minimum implementation will provide a single system-controlled		A minimum implementation will provide a single system-controlled
	routing instance, and will not allow clients to create any user-		routing instance, and will not allow clients to create any user-
	controlled instances.		controlled instances.
	Typically, neither of the features defined in the "ietf-routing"		Typically, neither of the features defined in the "ietf-routing"
	module ("multiple-ribs" and "multipath-routes") will be supported.		module ("multiple-ribs" and "multipath-routes") will be supported.
	This means that:		This means that:
	o A single system-controlled RIB (routing table) is available for		o A single system-controlled RIB (routing table) is available for
	each supported address family - IPv4, IPv6 or both. These RIBs		each supported address family - IPv4, IPv6 or both. These RIBs
	are the default RIBs, so they will also appear as system-		are the default RIBs, so references to them will also appear as
	controlled entries of the "default-rib" list in operational state		system-controlled entries of the "default-rib" list in state data.
	data. No user-controlled RIBs are allowed.		No user-controlled RIBs are allowed.
	o Each route has no more than one "next-hop", "outgoing-interface"		o Each route has no more than one "next-hop", "outgoing-interface"
	or "special-next-hop".		or "special-next-hop".
	In addition to the mandatory instance of the "direct" pseudo-		In addition to the mandatory instance of the "direct" pseudo-
	protocol, a minimum implementation should support configured		protocol, a minimum implementation should support configured
	instance(s) of the "static" pseudo-protocol. Even with a single RIB		instance(s) of the "static" pseudo-protocol. Even with a single RIB
	per address family, it may be occasionally useful to be able to		per address family, it may be occasionally useful to be able to
	configure multiple "static" instances. For example, a client may		configure multiple "static" instances. For example, a client may
	want to configure alternative sets of static routes and activate or		want to configure alternative sets of static routes and activate or
	skipping to change at page 79, line 11		skipping to change at page 72, line 11
	restricting the data model, e.g., limiting the number of "static"		restricting the data model, e.g., limiting the number of "static"
	routing protocol instances, preventing any route filters to be		routing protocol instances, preventing any route filters to be
	configured etc.		configured etc.
	Appendix C. Example: Adding a New Routing Protocol		Appendix C. Example: Adding a New Routing Protocol
	This appendix demonstrates how the core routing data model can be		This appendix demonstrates how the core routing data model can be
	extended to support a new routing protocol. The YANG module		extended to support a new routing protocol. The YANG module
	"example-rip" shown below is intended only as an illustration rather		"example-rip" shown below is intended only as an illustration rather
	than a real definition of a data model for the RIP routing protocol.		than a real definition of a data model for the RIP routing protocol.
	For the sake of brevity, we do not follow all the guidelines		For the sake of brevity, this module does not obey all the guidelines
	specified in [RFC6087]. See also Section 5.4.2.		specified in [RFC6087]. See also Section 5.4.2.
	module example-rip {		module example-rip {
	namespace "http://example.com/rip";		namespace "http://example.com/rip";
	prefix "rip";		prefix "rip";
	import ietf-routing {		import ietf-routing {
	prefix "rt";		prefix "rt";
	skipping to change at page 82, line 13		skipping to change at page 74, line 29
	}		}
	Appendix D. Example: NETCONF <get> Reply		Appendix D. Example: NETCONF <get> Reply
	This section contains a sample reply to the NETCONF <get> message,		This section contains a sample reply to the NETCONF <get> message,
	which could be sent by a server supporting (i.e., advertising them in		which could be sent by a server supporting (i.e., advertising them in
	the NETCONF <hello> message) the following YANG modules:		the NETCONF <hello> message) the following YANG modules:
	o ietf-interfaces [RFC7223],		o ietf-interfaces [RFC7223],
	o ietf-ip [YANG-IP],		o ietf-ip [RFC7277],
	o ietf-routing (Section 7),		o ietf-routing (Section 7),
	o ietf-ipv4-unicast-routing (Section 8),		o ietf-ipv4-unicast-routing (Section 8),
	o ietf-ipv6-unicast-routing (Section 9).		o ietf-ipv6-unicast-routing (Section 9).
	We assume a simple network setup as shown in Figure 5: router "A"		We assume a simple network set-up as shown in Figure 5: router "A"
	uses static default routes with the "ISP" router as the next-hop.		uses static default routes with the "ISP" router as the next-hop.
	IPv6 router advertisements are configured only on the "eth1"		IPv6 router advertisements are configured only on the "eth1"
	interface and disabled on the upstream "eth0" interface.		interface and disabled on the upstream "eth0" interface.
	+-----------------+		+-----------------+
	| |		| |
	| Router ISP |		| Router ISP |
	| |		| |
	+--------+--------+		+--------+--------+
	|2001:db8:0:1::2		|2001:db8:0:1::2
	skipping to change at page 82, line 51		skipping to change at page 75, line 30
	+--------+--------+		+--------+--------+
	eth1|198.51.100.1		eth1|198.51.100.1
	|2001:db8:0:2::1		|2001:db8:0:2::1
	|		|
	Figure 5: Example network configuration		Figure 5: Example network configuration
	A reply to the NETCONF <get> message sent by router "A" would then be		A reply to the NETCONF <get> message sent by router "A" would then be
	as follows:		as follows:
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<rpc-reply		<rpc-reply
	message-id="101"		message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"		xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
	xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"		xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"
	xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"		xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"
	xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"		xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
	xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"		xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
	xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip"		xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip"
	xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">		xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">
	<data>		<data>
	<if:interfaces>		<if:interfaces>
	<if:interface>		<if:interface>
	<if:name>eth0</if:name>		<if:name>eth0</if:name>
	<if:type>ianaift:ethernetCsmacd</if:type>		<if:type>ianaift:ethernetCsmacd</if:type>
	<if:description>		<if:description>
	Uplink to ISP.		Uplink to ISP.
	</if:description>		</if:description>
	<ip:ipv4>		<ip:ipv4>
	<ip:address>		<ip:address>
	<ip:ip>192.0.2.1</ip:ip>		<ip:ip>192.0.2.1</ip:ip>
	<ip:prefix-length>24</ip:prefix-length>		<ip:prefix-length>24</ip:prefix-length>
	</ip:address>		</ip:address>
	<ip:forwarding>true</ip:forwarding>		<ip:forwarding>true</ip:forwarding>
	</ip:ipv4>		</ip:ipv4>
	<ip:ipv6>		<ip:ipv6>
	<ip:address>		<ip:address>
	<ip:ip>2001:0db8:0:1::1</ip:ip>		<ip:ip>2001:0db8:0:1::1</ip:ip>
	<ip:prefix-length>64</ip:prefix-length>		<ip:prefix-length>64</ip:prefix-length>
	</ip:address>		</ip:address>
	<ip:forwarding>true</ip:forwarding>		<ip:forwarding>true</ip:forwarding>
	<ip:autoconf>		<ip:autoconf>
	<ip:create-global-addresses>false</ip:create-global-addresses>		<ip:create-global-addresses>false</ip:create-global-addresses>
	</ip:autoconf>		</ip:autoconf>
	</ip:ipv6>		</ip:ipv6>
	</if:interface>		</if:interface>
	<if:interface>		<if:interface>
	<if:name>eth1</if:name>		<if:name>eth1</if:name>
	<if:type>ianaift:ethernetCsmacd</if:type>		<if:type>ianaift:ethernetCsmacd</if:type>
	<if:description>		<if:description>
	Interface to the internal network.		Interface to the internal network.
	</if:description>		</if:description>
	<ip:ipv4>		<ip:ipv4>
	<ip:address>		<ip:address>
	<ip:ip>198.51.100.1</ip:ip>		<ip:ip>198.51.100.1</ip:ip>
	<ip:prefix-length>24</ip:prefix-length>		<ip:prefix-length>24</ip:prefix-length>
	</ip:address>		</ip:address>
	<ip:forwarding>true</ip:forwarding>		<ip:forwarding>true</ip:forwarding>
	</ip:ipv4>		</ip:ipv4>
	<ip:ipv6>		<ip:ipv6>
	<ip:address>		<ip:address>
	<ip:ip>2001:0db8:0:2::1</ip:ip>		<ip:ip>2001:0db8:0:2::1</ip:ip>
	<ip:prefix-length>64</ip:prefix-length>		<ip:prefix-length>64</ip:prefix-length>
	</ip:address>		</ip:address>
	<ip:forwarding>true</ip:forwarding>		<ip:forwarding>true</ip:forwarding>
	<ip:autoconf>		<ip:autoconf>
	<ip:create-global-addresses>false</ip:create-global-addresses>		<ip:create-global-addresses>false</ip:create-global-addresses>
	</ip:autoconf>		</ip:autoconf>
	</ip:ipv6>		</ip:ipv6>
	</if:interface>		</if:interface>
	</if:interfaces>		</if:interfaces>
	<if:interfaces-state>		<if:interfaces-state>
	<if:interface>		<if:interface>
	<if:name>eth0</if:name>		<if:name>eth0</if:name>
	<if:type>ianaift:ethernetCsmacd</if:type>		<if:type>ianaift:ethernetCsmacd</if:type>
	<if:phys-address>00:0C:42:E5:B1:E9</if:phys-address>		<if:phys-address>00:0C:42:E5:B1:E9</if:phys-address>
	<if:oper-status>up</if:oper-status>		<if:oper-status>up</if:oper-status>
	<if:statistics>		<if:statistics>
	<if:discontinuity-time>
	2013-07-02T17:11:27+00:58</if:discontinuity-time>
	</if:statistics>
	<ip:ipv4>
	<ip:forwarding>true</ip:forwarding>
	<ip:mtu>1500</ip:mtu>
	<ip:address>
	<ip:ip>192.0.2.1</ip:ip>
	<ip:prefix-length>24</ip:prefix-length>
	</ip:address>
	</ip:ipv4>
	<ip:ipv6>
	<ip:forwarding>true</ip:forwarding>
	<ip:mtu>1500</ip:mtu>
	<ip:address>
	<ip:ip>2001:0db8:0:1::1</ip:ip>
	<ip:prefix-length>64</ip:prefix-length>
	</ip:address>
	</ip:ipv6>
	</if:interface>
	<if:interface>
	<if:name>eth1</if:name>
	<if:type>ianaift:ethernetCsmacd</if:type>
	<if:oper-status>up</if:oper-status>
	<if:phys-address>00:0C:42:E5:B1:EA</if:phys-address>
	<if:statistics>
	<if:discontinuity-time>		<if:discontinuity-time>
	2013-07-02T17:11:27+00:59</if:discontinuity-time>		2014-10-24T17:11:27+00:58
	</if:statistics>		</if:discontinuity-time>
	<ip:ipv4>
	<ip:forwarding>true</ip:forwarding>
	<ip:mtu>1500</ip:mtu>
	<ip:address>
	<ip:ip>198.51.100.1</ip:ip>
	<ip:prefix-length>24</ip:prefix-length>
	</ip:address>
	</ip:ipv4>
	<ip:ipv6>
	<ip:forwarding>true</ip:forwarding>
	<ip:mtu>1500</ip:mtu>
	<ip:address>
	<ip:ip>2001:0db8:0:2::1</ip:ip>
	<ip:prefix-length>64</ip:prefix-length>
	</ip:address>
	</ip:ipv6>
	</if:interface>
	</if:interfaces-state>
	<rt:routing>
	<rt:routing-instance>
	<rt:name>rtr0</rt:name>
	<rt:description>Router A</rt:description>
	<rt:interfaces>
	<rt:interface>
	<rt:name>eth1</rt:name>
	<v6ur:ipv6-router-advertisements>
	<v6ur:send-advertisements>true</v6ur:send-advertisements>
	<v6ur:prefix-list>
	<v6ur:prefix>
	<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec>
	</v6ur:prefix>
	</v6ur:prefix-list>
	</v6ur:ipv6-router-advertisements>
	</rt:interface>
	</rt:interfaces>
	<rt:routing-protocols>
	<rt:routing-protocol>
	<rt:name>st0</rt:name>
	<rt:description>
	Static routing is used for the internal network.
	</rt:description>
	<rt:type>rt:static</rt:type>
	<rt:static-routes>
	<v4ur:ipv4>
	<v4ur:route>
	<v4ur:id>1</v4ur:id>
	<v4ur:destination-prefix>0.0.0.0/0</v4ur:destination-prefix>
	<v4ur:next-hop>192.0.2.2</v4ur:next-hop>
	</v4ur:route>
	</v4ur:ipv4>
	<v6ur:ipv6>
	<v6ur:route>
	<v6ur:id>1</v6ur:id>
	<v6ur:destination-prefix>::/0</v6ur:destination-prefix>
	<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
	</v6ur:route>
	</v6ur:ipv6>
	</rt:static-routes>
	</rt:routing-protocol>
	</rt:routing-protocols>
	</rt:routing-instance>
	</rt:routing>
	<rt:routing-state>
	<rt:routing-instance>
	<rt:name>rtr0</rt:name>
	<rt:id>2718281828</rt:id>
	<rt:router-id>192.0.2.1</rt:router-id>
	<rt:default-ribs>
	<rt:default-rib>
	<rt:address-family>v4ur:ipv4-unicast</rt:address-family>
	<rt:rib-name>ipv4-master</rt:rib-name>
	</rt:default-rib>
	<rt:default-rib>
	<rt:address-family>v6ur:ipv6-unicast</rt:address-family>
	<rt:rib-name>ipv6-master</rt:rib-name>
	</rt:default-rib>
	</rt:default-ribs>
	<rt:interfaces>
	<rt:interface>
	<rt:name>eth0</rt:name>
	</rt:interface>
	<rt:interface>
	<rt:name>eth1</rt:name>
	<v6ur:ipv6-router-advertisements>
	<v6ur:send-advertisements>true</v6ur:send-advertisements>
	<v6ur:prefix-list>
	<v6ur:prefix>
	<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec>
	</v6ur:prefix>
	</v6ur:prefix-list>
	</v6ur:ipv6-router-advertisements>
	</rt:interface>
	</rt:interfaces>
	<rt:routing-protocols>
	<rt:routing-protocol>
	<rt:name>st0</rt:name>
	<rt:type>rt:static</rt:type>
	</rt:routing-protocol>		</if:statistics>
	</rt:routing-protocols>		<ip:ipv4>
	</rt:routing-instance>		<ip:forwarding>true</ip:forwarding>
	<rt:ribs>		<ip:mtu>1500</ip:mtu>
	<rt:rib>		<ip:address>
	<rt:name>ipv4-master</rt:name>		<ip:ip>192.0.2.1</ip:ip>
	<rt:id>897932384</rt:id>		<ip:prefix-length>24</ip:prefix-length>
			</ip:address>
			</ip:ipv4>
			<ip:ipv6>
			<ip:forwarding>true</ip:forwarding>
			<ip:mtu>1500</ip:mtu>
			<ip:address>
			<ip:ip>2001:0db8:0:1::1</ip:ip>
			<ip:prefix-length>64</ip:prefix-length>
			</ip:address>
			</ip:ipv6>
			</if:interface>
			<if:interface>
			<if:name>eth1</if:name>
			<if:type>ianaift:ethernetCsmacd</if:type>
			<if:oper-status>up</if:oper-status>
			<if:phys-address>00:0C:42:E5:B1:EA</if:phys-address>
			<if:statistics>
			<if:discontinuity-time>
			2014-10-24T17:11:27+00:59
			</if:discontinuity-time>
			</if:statistics>
			<ip:ipv4>
			<ip:forwarding>true</ip:forwarding>
			<ip:mtu>1500</ip:mtu>
			<ip:address>
			<ip:ip>198.51.100.1</ip:ip>
			<ip:prefix-length>24</ip:prefix-length>
			</ip:address>
			</ip:ipv4>
			<ip:ipv6>
			<ip:forwarding>true</ip:forwarding>
			<ip:mtu>1500</ip:mtu>
			<ip:address>
			<ip:ip>2001:0db8:0:2::1</ip:ip>
			<ip:prefix-length>64</ip:prefix-length>
			</ip:address>
			</ip:ipv6>
			</if:interface>
			</if:interfaces-state>
			<rt:routing>
			<rt:routing-instance>
			<rt:name>rtr0</rt:name>
			<rt:description>Router A</rt:description>
			<rt:interfaces>
			<rt:interface>
			<rt:name>eth1</rt:name>
			<v6ur:ipv6-router-advertisements>
			<v6ur:send-advertisements>true</v6ur:send-advertisements>
			<v6ur:prefix-list>
			<v6ur:prefix>
			<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec>
			</v6ur:prefix>
			</v6ur:prefix-list>
			</v6ur:ipv6-router-advertisements>
			</rt:interface>
			</rt:interfaces>
			<rt:routing-protocols>
			<rt:routing-protocol>
			<rt:type>rt:static</rt:type>
			<rt:name>st0</rt:name>
			<rt:description>
			Static routing is used for the internal network.
			</rt:description>
			<rt:static-routes>
			<v4ur:ipv4>
			<v4ur:route>
			<v4ur:destination-prefix>0.0.0.0/0</v4ur:destination-prefix>
			<v4ur:next-hop>
			<v4ur:next-hop-address>192.0.2.2</v4ur:next-hop-address>
			</v4ur:next-hop>
			</v4ur:route>
			</v4ur:ipv4>
			<v6ur:ipv6>
			<v6ur:route>
			<v6ur:destination-prefix>::/0</v6ur:destination-prefix>
			<v6ur:next-hop>
			<v6ur:next-hop-address>2001:db8:0:1::2</v6ur:next-hop-address>
			</v6ur:next-hop>
			</v6ur:route>
			</v6ur:ipv6>
			</rt:static-routes>
			</rt:routing-protocol>
			</rt:routing-protocols>
			</rt:routing-instance>
			</rt:routing>
			<rt:routing-state>
			<rt:routing-instance>
			<rt:name>rtr0</rt:name>
			<rt:id>2718281828</rt:id>
			<rt:default-ribs>
			<rt:default-rib>
	<rt:address-family>v4ur:ipv4-unicast</rt:address-family>		<rt:address-family>v4ur:ipv4-unicast</rt:address-family>
	<rt:routes>		<rt:rib-name>ipv4-master</rt:rib-name>
	<rt:route>		</rt:default-rib>
	<rt:id>626433832</rt:id>		<rt:default-rib>
	<v4ur:destination-prefix>
	192.0.2.1/24</v4ur:destination-prefix>
	<rt:outgoing-interface>eth0</rt:outgoing-interface>
	<rt:source-protocol>rt:direct</rt:source-protocol>
	<rt:last-updated>2013-07-02T17:11:27+01:00</rt:last-updated>
	</rt:route>
	<rt:route>
	<rt:id>795028841</rt:id>
	<v4ur:destination-prefix>
	198.51.100.0/24</v4ur:destination-prefix>
	<rt:outgoing-interface>eth1</rt:outgoing-interface>
	<rt:source-protocol>rt:direct</rt:source-protocol>
	<rt:last-updated>2013-07-02T17:11:27+01:00</rt:last-updated>
	</rt:route>
	<rt:route>
	<rt:id>971693993</rt:id>
	<v4ur:destination-prefix>0.0.0.0/0</v4ur:destination-prefix>
	<rt:source-protocol>rt:static</rt:source-protocol>
	<v4ur:next-hop>192.0.2.2</v4ur:next-hop>
	<rt:last-updated>2013-07-02T18:02:45+01:00</rt:last-updated>
	</rt:route>
	</rt:routes>
	</rt:rib>
	<rt:rib>
	<rt:name>ipv6-master</rt:name>
	<rt:id>751058209</rt:id>
	<rt:address-family>v6ur:ipv6-unicast</rt:address-family>		<rt:address-family>v6ur:ipv6-unicast</rt:address-family>
	<rt:routes>		<rt:rib-name>ipv6-master</rt:rib-name>
	<rt:route>		</rt:default-rib>
	<rt:id>749445923</rt:id>		</rt:default-ribs>
	<v6ur:destination-prefix>		<rt:interfaces>
	2001:db8:0:1::/64</v6ur:destination-prefix>		<rt:interface>
	<rt:outgoing-interface>eth0</rt:outgoing-interface>		<rt:name>eth0</rt:name>
	<rt:source-protocol>rt:direct</rt:source-protocol>		</rt:interface>
	<rt:last-updated>2013-07-02T17:11:27+01:00</rt:last-updated>		<rt:interface>
	</rt:route>		<rt:name>eth1</rt:name>
	<rt:route>		<v6ur:ipv6-router-advertisements>
	<rt:id>78164062</rt:id>		<v6ur:send-advertisements>true</v6ur:send-advertisements>
	<v6ur:destination-prefix>		<v6ur:prefix-list>
	2001:db8:0:2::/64</v6ur:destination-prefix>		<v6ur:prefix>
	<rt:outgoing-interface>eth1</rt:outgoing-interface>		<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec>
	<rt:source-protocol>rt:direct</rt:source-protocol>		</v6ur:prefix>
	<rt:last-updated>2013-07-02T17:11:27+01:00</rt:last-updated>		</v6ur:prefix-list>
	</rt:route>		</v6ur:ipv6-router-advertisements>
	<rt:route>		</rt:interface>
	<rt:id>862089986</rt:id>		</rt:interfaces>
	<v6ur:destination-prefix>::/0</v6ur:destination-prefix>		<rt:routing-protocols>
	<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>		<rt:routing-protocol>
	<rt:source-protocol>rt:static</rt:source-protocol>		<rt:type>rt:static</rt:type>
	<rt:last-updated>2013-07-02T18:02:45+01:00</rt:last-updated>		<rt:name>st0</rt:name>
	</rt:route>		<rt:route-preference>5</rt:route-preference>
	</rt:routes>		</rt:routing-protocol>
	</rt:rib>		</rt:routing-protocols>
	</rt:ribs>		</rt:routing-instance>
	</rt:routing-state>		<rt:ribs>
	</data>		<rt:rib>
	</rpc-reply>		<rt:name>ipv4-master</rt:name>
			<rt:id>897932384</rt:id>
			<rt:address-family>v4ur:ipv4-unicast</rt:address-family>
			<rt:routes>
			<rt:route>
			<v4ur:destination-prefix>192.0.2.1/24</v4ur:destination-prefix>
			<rt:next-hop>
			<rt:outgoing-interface>eth0</rt:outgoing-interface>
			</rt:next-hop>
			<rt:route-preference>0</rt:route-preference>
			<rt:source-protocol>rt:direct</rt:source-protocol>
			<rt:last-updated>
			2014-10-24T17:11:27+01:00
			</rt:last-updated>
			</rt:route>
			<rt:route>
			<v4ur:destination-prefix>
			198.51.100.0/24
			</v4ur:destination-prefix>
			<rt:next-hop>
			<rt:outgoing-interface>eth1</rt:outgoing-interface>
			</rt:next-hop>
			<rt:source-protocol>rt:direct</rt:source-protocol>
			<rt:route-preference>0</rt:route-preference>
			<rt:last-updated>
			2014-10-24T17:11:27+01:00
			</rt:last-updated>
			</rt:route>
			<rt:route>
			<v4ur:destination-prefix>0.0.0.0/0</v4ur:destination-prefix>
			<rt:source-protocol>rt:static</rt:source-protocol>
			<rt:route-preference>5</rt:route-preference>
			<rt:next-hop>
			<v4ur:next-hop-address>192.0.2.2</v4ur:next-hop-address>
			</rt:next-hop>
			<rt:last-updated>
			2014-10-24T18:02:45+01:00
			</rt:last-updated>
			</rt:route>
			</rt:routes>
			</rt:rib>
			<rt:rib>
			<rt:name>ipv6-master</rt:name>
			<rt:id>751058209</rt:id>
			<rt:address-family>v6ur:ipv6-unicast</rt:address-family>
			<rt:routes>
			<rt:route>
			<v6ur:destination-prefix>
			2001:db8:0:1::/64
			</v6ur:destination-prefix>
			<rt:next-hop>
			<rt:outgoing-interface>eth0</rt:outgoing-interface>
			</rt:next-hop>
			<rt:source-protocol>rt:direct</rt:source-protocol>
			<rt:route-preference>0</rt:route-preference>
			<rt:last-updated>
			2014-10-24T17:11:27+01:00
			</rt:last-updated>
			</rt:route>
			<rt:route>
			<v6ur:destination-prefix>
			2001:db8:0:2::/64
			</v6ur:destination-prefix>
			<rt:next-hop>
			<rt:outgoing-interface>eth1</rt:outgoing-interface>
			</rt:next-hop>
			<rt:source-protocol>rt:direct</rt:source-protocol>
			<rt:route-preference>0</rt:route-preference>
			<rt:last-updated>
			2014-10-24T17:11:27+01:00
			</rt:last-updated>
			</rt:route>
			<rt:route>
			<v6ur:destination-prefix>::/0</v6ur:destination-prefix>
			<rt:next-hop>
			<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
			</rt:next-hop>
			<rt:source-protocol>rt:static</rt:source-protocol>
			<rt:route-preference>5</rt:route-preference>
			<rt:last-updated>
			2014-10-24T18:02:45+01:00
			</rt:last-updated>
			</rt:route>
			</rt:routes>
			</rt:rib>
			</rt:ribs>
			</rt:routing-state>
			</data>
			</rpc-reply>
	Appendix E. Change Log		Appendix E. Change Log
	RFC Editor: remove this section upon publication as an RFC.		RFC Editor: Remove this section upon publication as an RFC.
	E.1. Changes Between Versions -14 and -15		E.1. Changes Between Versions -15 and -16
			o Added 'type' as the second key component of 'routing-protocol',
			both in configuration and state data.
			o The restriction of no more than one connected RIB per address
			family was removed.
			o Removed the 'id' key of routes in RIBs. This list has no keys
			anymore.
			o Remove the 'id' key from static routes and make 'destination-
			prefix' the only key.
			o Added 'route-preference' as a new attribute of routes in RIB.
			o Added 'active' as a new attribute of routes in RIBs.
			o Renamed RPC operation 'active-route' to 'fib-route.
			o Added 'route-preference' as a new parameter of routing protocol
			instances, both in configuration and state data.
			o Renamed identity 'rt:standard-routing-instance' to 'rt:default-
			routing-instance'.
			o Added next-hop lists to state data.
			o Added two cases for specifying next-hops indirectly - via a new
			RIB or a recursive list of next-hops.
			o Reorganized next-hop in static routes.
			o Removed all 'if-feature' statements from state data.
			E.2. Changes Between Versions -14 and -15
	o Removed all defaults from state data.		o Removed all defaults from state data.
	o Removed default from 'cur-hop-limit' in config.		o Removed default from 'cur-hop-limit' in config.
	E.2. Changes Between Versions -13 and -14		E.3. Changes Between Versions -13 and -14
	o Removed dependency of 'connected-ribs' on the 'multiple-ribs'		o Removed dependency of 'connected-ribs' on the 'multiple-ribs'
	feature.		feature.
	o Removed default value of 'cur-hop-limit' in state data.		o Removed default value of 'cur-hop-limit' in state data.
	o Moved parts of descriptions and all references on IPv6 RA		o Moved parts of descriptions and all references on IPv6 RA
	parameters from state data to configuration.		parameters from state data to configuration.
	o Added reference to RFC 6536 in the Security section.		o Added reference to RFC 6536 in the Security section.
	E.3. Changes Between Versions -12 and -13		E.4. Changes Between Versions -12 and -13
	o Wrote appendix about minimum implementation.		o Wrote appendix about minimum implementation.
	o Remove "when" statement for IPv6 router interface operational		o Remove "when" statement for IPv6 router interface state data - it
	state - it was dependent on a config value that may not be		was dependent on a config value that may not be present.
	present.
	o Extra container for the next-hop list.		o Extra container for the next-hop list.
	o Names rather than numeric ids are used for referring to list		o Names rather than numeric ids are used for referring to list
	entries in operational state.		entries in state data.
	o Numeric ids are always declared as mandatory and unique. Their		o Numeric ids are always declared as mandatory and unique. Their
	description states that they are ephemeral.		description states that they are ephemeral.
	o Descriptions of "name" keys in operational state lists are		o Descriptions of "name" keys in state data lists are required to be
	required to be persistent.		persistent.
	o		o
	o Removed "if-feature multiple-ribs;" from connected-ribs.		o Removed "if-feature multiple-ribs;" from connected-ribs.
	o "rib-name" instead of "name" is used as the name of leafref nodes.		o "rib-name" instead of "name" is used as the name of leafref nodes.
	o "next-hop" instead of "nexthop" or "gateway" used throughout, both		o "next-hop" instead of "nexthop" or "gateway" used throughout, both
	in node names and text.		in node names and text.
	E.4. Changes Between Versions -11 and -12		E.5. Changes Between Versions -11 and -12
	o Removed feature "advanced-router" and introduced two features		o Removed feature "advanced-router" and introduced two features
	instead: "multiple-ribs" and "multipath-routes".		instead: "multiple-ribs" and "multipath-routes".
	o Unified the keys of config and state versions of "routing-		o Unified the keys of config and state versions of "routing-
	instance" and "rib" lists.		instance" and "rib" lists.
	o Numerical identifiers of state list entries are not keys anymore,		o Numerical identifiers of state list entries are not keys anymore,
	but they are constrained using the "unique" statement.		but they are constrained using the "unique" statement.
	o Updated acknowledgements.		o Updated acknowledgements.
	E.5. Changes Between Versions -10 and -11		E.6. Changes Between Versions -10 and -11
	o Migrated address families from IANA enumerations to identities.		o Migrated address families from IANA enumerations to identities.
	o Terminology and node names aligned with the I2RS RIB model: router		o Terminology and node names aligned with the I2RS RIB model: router
	-> routing instance, routing table -> RIB.		-> routing instance, routing table -> RIB.
	o Introduced uint64 keys for state lists: routing-instance, rib,		o Introduced uint64 keys for state lists: routing-instance, rib,
	route, nexthop.		route, nexthop.
	o Described the relationship between system-controlled and user-		o Described the relationship between system-controlled and user-
	skipping to change at page 90, line 45		skipping to change at page 84, line 13
	router".		router".
	o Made nexthop into a choice in order to allow for nexthop-list		o Made nexthop into a choice in order to allow for nexthop-list
	(I2RS requirement).		(I2RS requirement).
	o Added nexthop-list with entries having priorities (backup) and		o Added nexthop-list with entries having priorities (backup) and
	weights (load balancing).		weights (load balancing).
	o Updated bibliography references.		o Updated bibliography references.
	E.6. Changes Between Versions -09 and -10		E.7. Changes Between Versions -09 and -10
	o Added subtree for operational state data ("/routing-state").		o Added subtree for state data ("/routing-state").
	o Terms "system-controlled entry" and "user-controlled entry"		o Terms "system-controlled entry" and "user-controlled entry"
	defined and used.		defined and used.
	o New feature "user-defined-routing-tables". Nodes that are useful		o New feature "user-defined-routing-tables". Nodes that are useful
	only with user-defined routing tables are now conditional.		only with user-defined routing tables are now conditional.
	o Added grouping "router-id".		o Added grouping "router-id".
	o In routing tables, "source-protocol" attribute of routes now		o In routing tables, "source-protocol" attribute of routes now
	reports only protocol type, and its datatype is "identityref".		reports only protocol type, and its datatype is "identityref".
	o Renamed "main-routing-table" to "default-routing-table".		o Renamed "main-routing-table" to "default-routing-table".
	E.7. Changes Between Versions -08 and -09		E.8. Changes Between Versions -08 and -09
	o Fixed "must" expresion for "connected-routing-table".		o Fixed "must" expresion for "connected-routing-table".
	o Simplified "must" expression for "main-routing-table".		o Simplified "must" expression for "main-routing-table".
	o Moved per-interface configuration of a new routing protocol under		o Moved per-interface configuration of a new routing protocol under
	'routing-protocol'. This also affects the 'example-rip' module.		'routing-protocol'. This also affects the 'example-rip' module.
	E.8. Changes Between Versions -07 and -08		E.9. Changes Between Versions -07 and -08
	o Changed reference from RFC6021 to RFC6021bis.		o Changed reference from RFC6021 to RFC6021bis.
	E.9. Changes Between Versions -06 and -07		E.10. Changes Between Versions -06 and -07
	o The contents of <get-reply> in Appendix D was updated: "eth[01]"		o The contents of <get-reply> in Appendix D was updated: "eth[01]"
	is used as the value of "location", and "forwarding" is on for		is used as the value of "location", and "forwarding" is on for
	both interfaces and both IPv4 and IPv6.		both interfaces and both IPv4 and IPv6.
	o The "must" expression for "main-routing-table" was modified to		o The "must" expression for "main-routing-table" was modified to
	avoid redundant error messages reporting address family mismatch		avoid redundant error messages reporting address family mismatch
	when "name" points to a non-existent routing table.		when "name" points to a non-existent routing table.
	o The default behavior for IPv6 RA prefix advertisements was		o The default behavior for IPv6 RA prefix advertisements was
	clarified.		clarified.
	o Changed type of "rt:router-id" to "ip:dotted-quad".		o Changed type of "rt:router-id" to "ip:dotted-quad".
	o Type of "rt:router-id" changed to "yang:dotted-quad".		o Type of "rt:router-id" changed to "yang:dotted-quad".
	o Fixed missing prefixes in XPath expressions.		o Fixed missing prefixes in XPath expressions.
	E.10. Changes Between Versions -05 and -06		E.11. Changes Between Versions -05 and -06
	o Document title changed: "Configuration" was replaced by		o Document title changed: "Configuration" was replaced by
	"Management".		"Management".
	o New typedefs "routing-table-ref" and "route-filter-ref".		o New typedefs "routing-table-ref" and "route-filter-ref".
	o Double slashes "//" were removed from XPath expressions and		o Double slashes "//" were removed from XPath expressions and
	replaced with the single "/".		replaced with the single "/".
	o Removed uniqueness requirement for "router-id".		o Removed uniqueness requirement for "router-id".
	skipping to change at page 92, line 22		skipping to change at page 85, line 36
	o Complete data tree is now in Appendix A.		o Complete data tree is now in Appendix A.
	o Changed type of "source-protocol" from "leafref" to "string".		o Changed type of "source-protocol" from "leafref" to "string".
	o Clarified the relationship between routing protocol instances and		o Clarified the relationship between routing protocol instances and
	connected routing tables.		connected routing tables.
	o Added a must constraint saying that a routing table connected to		o Added a must constraint saying that a routing table connected to
	the direct pseudo-protocol must not be a main routing table.		the direct pseudo-protocol must not be a main routing table.
	E.11. Changes Between Versions -04 and -05		E.12. Changes Between Versions -04 and -05
	o Routing tables are now global, i.e., "routing-tables" is a child		o Routing tables are now global, i.e., "routing-tables" is a child
	of "routing" rather than "router".		of "routing" rather than "router".
	o "must" statement for "static-routes" changed to "when".		o "must" statement for "static-routes" changed to "when".
	o Added "main-routing-tables" containing references to main routing		o Added "main-routing-tables" containing references to main routing
	tables for each address family.		tables for each address family.
	o Removed the defaults for "address-family" and "safi" and made them		o Removed the defaults for "address-family" and "safi" and made them
	skipping to change at page 93, line 8		skipping to change at page 86, line 24
	o The "direct" pseudo-protocol is always connected to main routing		o The "direct" pseudo-protocol is always connected to main routing
	tables.		tables.
	o Entries in the list of connected routing tables renamed from		o Entries in the list of connected routing tables renamed from
	"routing-table" to "connected-routing-table".		"routing-table" to "connected-routing-table".
	o Added "must" constraint saying that a routing table must not be		o Added "must" constraint saying that a routing table must not be
	its own recipient.		its own recipient.
	E.12. Changes Between Versions -03 and -04		E.13. Changes Between Versions -03 and -04
	o Changed "error-tag" for both RPC methods from "missing element" to		o Changed "error-tag" for both RPC methods from "missing element" to
	"data-missing".		"data-missing".
	o Removed the decrementing behavior for advertised IPv6 prefix		o Removed the decrementing behavior for advertised IPv6 prefix
	parameters "valid-lifetime" and "preferred-lifetime".		parameters "valid-lifetime" and "preferred-lifetime".
	o Changed the key of the static route lists from "seqno" to "id"		o Changed the key of the static route lists from "seqno" to "id"
	because the routes needn't be sorted.		because the routes needn't be sorted.
	o Added 'must' constraint saying that "preferred-lifetime" must not		o Added 'must' constraint saying that "preferred-lifetime" must not
	be greater than "valid-lifetime".		be greater than "valid-lifetime".
	E.13. Changes Between Versions -02 and -03		E.14. Changes Between Versions -02 and -03
	o Module "iana-afn-safi" moved to I-D "iana-if-type".		o Module "iana-afn-safi" moved to I-D "iana-if-type".
	o Removed forwarding table.		o Removed forwarding table.
	o RPC "get-route" changed to "active-route". Its output is a list		o RPC "get-route" changed to "active-route". Its output is a list
	of routes (for multi-path routing).		of routes (for multi-path routing).
	o New RPC "route-count".		o New RPC "route-count".
	skipping to change at page 94, line 7		skipping to change at page 87, line 22
	"ietf-ip".		"ietf-ip".
	o Added "router-id" leaf.		o Added "router-id" leaf.
	o Specified the names for IPv4/IPv6 unicast main routing tables.		o Specified the names for IPv4/IPv6 unicast main routing tables.
	o Route parameter "last-modified" changed to "age".		o Route parameter "last-modified" changed to "age".
	o Added container "recipient-routing-tables".		o Added container "recipient-routing-tables".
	E.14. Changes Between Versions -01 and -02		E.15. Changes Between Versions -01 and -02
	o Added module "ietf-ipv6-unicast-routing".		o Added module "ietf-ipv6-unicast-routing".
	o The example in Appendix D now uses IP addresses from blocks		o The example in Appendix D now uses IP addresses from blocks
	reserved for documentation.		reserved for documentation.
	o Direct routes appear by default in the forwarding table.		o Direct routes appear by default in the forwarding table.
	o Network layer interfaces must be assigned to a router instance.		o Network layer interfaces must be assigned to a router instance.
	Additional interface configuration may be present.		Additional interface configuration may be present.
	skipping to change at page 94, line 31		skipping to change at page 87, line 46
	o Additional "must" statements were added.		o Additional "must" statements were added.
	o The "route-content" grouping for IPv4 and IPv6 unicast now		o The "route-content" grouping for IPv4 and IPv6 unicast now
	includes the material from the "ietf-routing" version via "uses		includes the material from the "ietf-routing" version via "uses
	rt:route-content".		rt:route-content".
	o Explanation of symbols in the tree representation of data model		o Explanation of symbols in the tree representation of data model
	hierarchy.		hierarchy.
	E.15. Changes Between Versions -00 and -01		E.16. Changes Between Versions -00 and -01
	o AFN/SAFI-independent stuff was moved to the "ietf-routing" module.		o AFN/SAFI-independent stuff was moved to the "ietf-routing" module.
	o Typedefs for AFN and SAFI were placed in a separate "iana-afn-		o Typedefs for AFN and SAFI were placed in a separate "iana-afn-
	safi" module.		safi" module.
	o Names of some data nodes were changed, in particular "routing-		o Names of some data nodes were changed, in particular "routing-
	process" is now "router".		process" is now "router".
	o The restriction of a single AFN/SAFI per router was lifted.		o The restriction of a single AFN/SAFI per router was lifted.
End of changes. 218 change blocks.
	1070 lines changed or deleted		1192 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/