< draft-ietf-netmod-routing-cfg-23.txt		draft-ietf-netmod-routing-cfg-24.txt >
	NETMOD Working Group L. Lhotka		NETMOD Working Group L. Lhotka
	Internet-Draft CZ.NIC		Internet-Draft CZ.NIC
	Intended status: Standards Track A. Lindem		Intended status: Standards Track A. Lindem
	Expires: February 19, 2017 Cisco Systems		Expires: April 23, 2017 Cisco Systems
	August 18, 2016		October 20, 2016
	A YANG Data Model for Routing Management		A YANG Data Model for Routing Management
	draft-ietf-netmod-routing-cfg-23		draft-ietf-netmod-routing-cfg-24
	Abstract		Abstract
	This document contains a specification of three YANG modules and one		This document contains a specification of three YANG modules and one
	submodule. Together they form the core routing data model which		submodule. Together they form the core routing data model which
	serves as a framework for configuring and managing a routing		serves as a framework for configuring and managing a routing
	subsystem. It is expected that these modules will be augmented by		subsystem. It is expected that these modules will be augmented by
	additional YANG modules defining data models for control plane		additional YANG modules defining data models for control plane
	protocols, route filters and other functions. The core routing data		protocols, route filters and other functions. The core routing data
	model provides common building blocks for such extensions -- routes,		model provides common building blocks for such extensions -- routes,
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 19, 2017.		This Internet-Draft will expire on April 23, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 47 ¶		skipping to change at page 2, line 47 ¶
	13.1. Normative References . . . . . . . . . . . . . . . . . . 50		13.1. Normative References . . . . . . . . . . . . . . . . . . 50
	13.2. Informative References . . . . . . . . . . . . . . . . . 50		13.2. Informative References . . . . . . . . . . . . . . . . . 50
	Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 51		Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 51
	A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 51		A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 51
	A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 53		A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 53
	Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 54		Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 54
	Appendix C. Example: Adding a New Control Plane Protocol . . . . 54		Appendix C. Example: Adding a New Control Plane Protocol . . . . 54
	Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 57		Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 57
	Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 65		Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 65
	E.1. Changes Between Versions -22 and -23 . . . . . . . . . . 65		E.1. Changes Between Versions -22 and -23 . . . . . . . . . . 65
	E.2. Changes Between Versions -21 and -22 . . . . . . . . . . 65		E.2. Changes Between Versions -22 and -23 . . . . . . . . . . 65
	E.3. Changes Between Versions -20 and -21 . . . . . . . . . . 65		E.3. Changes Between Versions -21 and -22 . . . . . . . . . . 65
	E.4. Changes Between Versions -19 and -20 . . . . . . . . . . 66		E.4. Changes Between Versions -20 and -21 . . . . . . . . . . 66
	E.5. Changes Between Versions -18 and -19 . . . . . . . . . . 66		E.5. Changes Between Versions -19 and -20 . . . . . . . . . . 66
	E.6. Changes Between Versions -17 and -18 . . . . . . . . . . 66		E.6. Changes Between Versions -18 and -19 . . . . . . . . . . 66
	E.7. Changes Between Versions -16 and -17 . . . . . . . . . . 67		E.7. Changes Between Versions -17 and -18 . . . . . . . . . . 66
	E.8. Changes Between Versions -15 and -16 . . . . . . . . . . 67		E.8. Changes Between Versions -16 and -17 . . . . . . . . . . 67
	E.9. Changes Between Versions -14 and -15 . . . . . . . . . . 68		E.9. Changes Between Versions -15 and -16 . . . . . . . . . . 67
	E.10. Changes Between Versions -13 and -14 . . . . . . . . . . 68		E.10. Changes Between Versions -14 and -15 . . . . . . . . . . 68
	E.11. Changes Between Versions -12 and -13 . . . . . . . . . . 68		E.11. Changes Between Versions -13 and -14 . . . . . . . . . . 68
	E.12. Changes Between Versions -11 and -12 . . . . . . . . . . 69		E.12. Changes Between Versions -12 and -13 . . . . . . . . . . 68
	E.13. Changes Between Versions -10 and -11 . . . . . . . . . . 69		E.13. Changes Between Versions -11 and -12 . . . . . . . . . . 69
	E.14. Changes Between Versions -09 and -10 . . . . . . . . . . 69		E.14. Changes Between Versions -10 and -11 . . . . . . . . . . 69
	E.15. Changes Between Versions -08 and -09 . . . . . . . . . . 70		E.15. Changes Between Versions -09 and -10 . . . . . . . . . . 69
	E.16. Changes Between Versions -07 and -08 . . . . . . . . . . 70		E.16. Changes Between Versions -08 and -09 . . . . . . . . . . 70
	E.17. Changes Between Versions -06 and -07 . . . . . . . . . . 70		E.17. Changes Between Versions -07 and -08 . . . . . . . . . . 70
	E.18. Changes Between Versions -05 and -06 . . . . . . . . . . 70		E.18. Changes Between Versions -06 and -07 . . . . . . . . . . 70
	E.19. Changes Between Versions -04 and -05 . . . . . . . . . . 71		E.19. Changes Between Versions -05 and -06 . . . . . . . . . . 70
	E.20. Changes Between Versions -03 and -04 . . . . . . . . . . 72		E.20. Changes Between Versions -04 and -05 . . . . . . . . . . 71
	E.21. Changes Between Versions -02 and -03 . . . . . . . . . . 72		E.21. Changes Between Versions -03 and -04 . . . . . . . . . . 72
	E.22. Changes Between Versions -01 and -02 . . . . . . . . . . 73		E.22. Changes Between Versions -02 and -03 . . . . . . . . . . 72
	E.23. Changes Between Versions -00 and -01 . . . . . . . . . . 73		E.23. Changes Between Versions -01 and -02 . . . . . . . . . . 73
			E.24. Changes Between Versions -00 and -01 . . . . . . . . . . 73
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
	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"
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	The following terms are defined in [RFC6241]:		The following terms are defined in [RFC6241]:
	o client,		o client,
	o message,		o message,
	o protocol operation,		o protocol operation,
	o server.		o server.
	The following terms are defined in [I-D.ietf-netmod-rfc6020bis]:		The following terms are defined in [RFC7950]:
	o action,		o action,
	o augment,		o augment,
	o configuration data,		o configuration data,
	o container,		o container,
	o container with presence,		o container with presence,
	skipping to change at page 10, line 25 ¶		skipping to change at page 10, line 25 ¶
	the so-called default RIB. Its role is explained in Section 5.3.		the so-called default RIB. Its role is explained in Section 5.3.
	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 mark it as the default RIB.		supported address family, and mark it as the default RIB.
	More complex router implementations advertising the "multiple-ribs"		More complex router implementations advertising the "multiple-ribs"
	feature support multiple RIBs per address family that can be used for		feature support multiple RIBs per address family that can be used for
	policy routing and other purposes.		policy routing and other purposes.
	The following action (see Section 7.15 of		The following action (see Section 7.15 of [RFC7950]) is defined for
	[I-D.ietf-netmod-rfc6020bis]) is defined for the "rib" list:		the "rib" list:
	o active-route -- return the active RIB route for the destination		o active-route -- return the active RIB route for the destination
	address that is specified as the action's input parameter.		address that is specified as the action's input parameter.
	5.3. Control Plane Protocol		5.3. Control Plane 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 control plane protocol instances, e.g., for Layer 3		defining multiple control plane protocol instances, e.g., for Layer 3
	routing protocols. Each control plane protocol instance MUST be		routing protocols. Each control plane protocol instance MUST be
	assigned a type, which is an identity derived from the "rt:control-		assigned a type, which is an identity derived from the "rt:control-
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 29 ¶
	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 Editor: In this section, replace all occurrences of 'XXXX' with		RFC Editor: In this section, replace all occurrences of 'XXXX' with
	the actual RFC number and all occurrences of the revision date below		the actual RFC number and all occurrences of the revision date below
	with the date of RFC publication (and remove this note).		with the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-routing@2016-08-18.yang"		<CODE BEGINS> file "ietf-routing@2016-10-20.yang"
	module ietf-routing {		module ietf-routing {
	yang-version "1.1";		yang-version "1.1";
	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 {
	skipping to change at page 14, line 51 ¶		skipping to change at page 14, line 51 ¶
	}		}
	import ietf-interfaces {		import ietf-interfaces {
	prefix "if";		prefix "if";
	}		}
	organization		organization
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <https://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		WG Chair: Lou Berger
	<mailto:lberger@labn.net>		<mailto:lberger@labn.net>
	WG Chair: Kent Watsen		WG Chair: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>		<mailto:lhotka@nic.cz>
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	of a routing subsystem.		of a routing subsystem.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2016 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	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).		(https://trustee.ietf.org/license-info).
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
	'OPTIONAL' in the module text are to be interpreted as described		'OPTIONAL' in the module text are to be interpreted as described
	in RFC 2119 (http://tools.ietf.org/html/rfc2119).		in RFC 2119 (https://tools.ietf.org/html/rfc2119).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for		(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
	full legal notices.";		full legal notices.";
	revision 2016-08-18 {		revision 2016-10-20 {
	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
	skipping to change at page 26, line 39 ¶		skipping to change at page 26, line 39 ¶
	}		}
	<CODE ENDS>		<CODE ENDS>
	8. IPv4 Unicast Routing Management YANG Module		8. IPv4 Unicast Routing Management YANG Module
	RFC Editor: In this section, replace all occurrences of 'XXXX' with		RFC Editor: In this section, replace all occurrences of 'XXXX' with
	the actual RFC number and all occurrences of the revision date below		the actual RFC number and all occurrences of the revision date below
	with 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@2016-08-18.yang"		<CODE BEGINS> file "ietf-ipv4-unicast-routing@2016-10-20.yang"
	module ietf-ipv4-unicast-routing {		module ietf-ipv4-unicast-routing {
	yang-version "1.1";		yang-version "1.1";
	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";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix "inet";		prefix "inet";
	}		}
	organization		organization
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <https://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		WG Chair: Lou Berger
	<mailto:lberger@labn.net>		<mailto:lberger@labn.net>
	WG Chair: Kent Watsen		WG Chair: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>		<mailto:lhotka@nic.cz>
	skipping to change at page 27, line 39 ¶		skipping to change at page 27, line 39 ¶
	configuration and state data for IPv4 unicast routing.		configuration and state data for IPv4 unicast routing.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2016 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	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).		(https://trustee.ietf.org/license-info).
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
	'OPTIONAL' in the module text are to be interpreted as described		'OPTIONAL' in the module text are to be interpreted as described
	in RFC 2119 (http://tools.ietf.org/html/rfc2119).		in RFC 2119 (https://tools.ietf.org/html/rfc2119).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for		(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
	full legal notices.";		full legal notices.";
	revision 2016-08-18 {		revision 2016-10-20 {
	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 29, line 22 ¶		skipping to change at page 29, line 22 ¶
	routes.";		routes.";
	leaf address {		leaf address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 address of the next-hop.";		"IPv4 address of the next-hop.";
	}		}
	}		}
	augment		augment
	"/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" {		"/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" {
	when "derived-from-or-self(../../rt:address-family, "		when "derived-from-or-self(../rt:address-family, "
	+ "'v4ur:ipv4-unicast')" {		+ "'v4ur:ipv4-unicast')" {
	description		description
	"This augment is valid only for IPv4 unicast RIBs.";		"This augment is valid only for IPv4 unicast RIBs.";
	}		}
	description		description
	"This augment adds the input parameter of the 'active-route'		"This augment adds the input parameter of the 'active-route'
	action.";		action.";
	leaf destination-address {		leaf destination-address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 destination address.";		"IPv4 destination address.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
	+ "rt:output/rt:route" {		+ "rt:output/rt:route" {
	when "derived-from-or-self(../../../rt:address-family, "		when "derived-from-or-self(../../rt:address-family, "
	+ "'v4ur:ipv4-unicast')" {		+ "'v4ur:ipv4-unicast')" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"This augment adds the destination prefix to the reply of the		"This augment adds the destination prefix to the reply of the
	'active-route' action.";		'active-route' action.";
	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:active-route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
	+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"		+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
	+ "rt:simple-next-hop" {		+ "rt:simple-next-hop" {
	when "derived-from-or-self(../../../../rt:address-family, "		when "derived-from-or-self(../../../rt:address-family, "
	+ "'v4ur:ipv4-unicast')" {		+ "'v4ur:ipv4-unicast')" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"Augment 'simple-next-hop' case in the reply to the		"Augment 'simple-next-hop' case in the reply to the
	'active-route' action.";		'active-route' action.";
	leaf next-hop-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.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
	+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"		+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
	+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {		+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
	when "derived-from-or-self(../../../../../../rt:address-family, "		when "derived-from-or-self(../../../../../rt:address-family, "
	+ "'v4ur:ipv4-unicast')" {		+ "'v4ur:ipv4-unicast')" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"Augment 'next-hop-list' case in the reply to the		"Augment 'next-hop-list' case in the reply to the
	'active-route' action.";		'active-route' action.";
	leaf next-hop-address {		leaf next-hop-address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	skipping to change at page 32, line 12 ¶		skipping to change at page 32, line 12 ¶
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	9. IPv6 Unicast Routing Management YANG Module		9. IPv6 Unicast Routing Management YANG Module
	RFC Editor: In this section, replace all occurrences of 'XXXX' with		RFC Editor: In this section, replace all occurrences of 'XXXX' with
	the actual RFC number and all occurrences of the revision date below		the actual RFC number and all occurrences of the revision date below
	with 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@2016-08-18.yang"		<CODE BEGINS> file "ietf-ipv6-unicast-routing@2016-10-20.yang"
	module ietf-ipv6-unicast-routing {		module ietf-ipv6-unicast-routing {
	yang-version "1.1";		yang-version "1.1";
	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";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix "inet";		prefix "inet";
	}		}
	include ietf-ipv6-router-advertisements {		include ietf-ipv6-router-advertisements {
	revision-date 2016-08-18;		revision-date 2016-10-20;
	}		}
	organization		organization
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <https://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		WG Chair: Lou Berger
	<mailto:lberger@labn.net>		<mailto:lberger@labn.net>
	WG Chair: Kent Watsen		WG Chair: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>		<mailto:lhotka@nic.cz>
	Editor: Acee Lindem		Editor: Acee Lindem
	<mailto:acee@cisco.com>";		<mailto:acee@cisco.com>";
	description		description
	"This YANG module augments the 'ietf-routing' module with basic		"This YANG module augments the 'ietf-routing' module with basic
	configuration and state data for IPv6 unicast routing.		configuration and state data for IPv6 unicast routing.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2016 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	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).		(https://trustee.ietf.org/license-info).
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
	'OPTIONAL' in the module text are to be interpreted as described		'OPTIONAL' in the module text are to be interpreted as described
	in RFC 2119 (http://tools.ietf.org/html/rfc2119).		in RFC 2119 (https://tools.ietf.org/html/rfc2119).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for		(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
	full legal notices.";		full legal notices.";
	revision 2016-08-18 {		revision 2016-10-20 {
	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 34, line 48 ¶		skipping to change at page 34, line 48 ¶
	routes.";		routes.";
	leaf address {		leaf address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 address of the next-hop.";		"IPv6 address of the next-hop.";
	}		}
	}		}
	augment		augment
	"/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" {		"/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input" {
	when "derived-from-or-self(../../rt:address-family, "		when "derived-from-or-self(../rt:address-family, "
	+ "'v6ur:ipv6-unicast')" {		+ "'v6ur:ipv6-unicast')" {
	description		description
	"This augment is valid only for IPv6 unicast RIBs.";		"This augment is valid only for IPv6 unicast RIBs.";
	}		}
	description		description
	"This augment adds the input parameter of the 'active-route'		"This augment adds the input parameter of the 'active-route'
	action.";		action.";
	leaf destination-address {		leaf destination-address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 destination address.";		"IPv6 destination address.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
	+ "rt:output/rt:route" {		+ "rt:output/rt:route" {
	when "derived-from-or-self(../../../rt:address-family, "		when "derived-from-or-self(../../rt:address-family, "
	+ "'v6ur:ipv6-unicast')" {		+ "'v6ur:ipv6-unicast')" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"This augment adds the destination prefix to the reply of the		"This augment adds the destination prefix to the reply of the
	'active-route' action.";		'active-route' action.";
	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:active-route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
	+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"		+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
	+ "rt:simple-next-hop" {		+ "rt:simple-next-hop" {
	when "derived-from-or-self(../../../../rt:address-family, "		when "derived-from-or-self(../../../rt:address-family, "
	+ "'v6ur:ipv6-unicast')" {		+ "'v6ur:ipv6-unicast')" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"Augment 'simple-next-hop' case in the reply to the		"Augment 'simple-next-hop' case in the reply to the
	'active-route' action.";		'active-route' action.";
	leaf next-hop-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.";
	}		}
	}		}
	augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"		augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
	+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"		+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
	+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {		+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
	when "derived-from-or-self(../../../../../../rt:address-family, "		when "derived-from-or-self(../../../../../rt:address-family, "
	+ "'v6ur:ipv6-unicast')" {		+ "'v6ur:ipv6-unicast')" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"Augment 'next-hop-list' case in the reply to the		"Augment 'next-hop-list' case in the reply to the
	'active-route' action.";		'active-route' action.";
	leaf next-hop-address {		leaf next-hop-address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	skipping to change at page 37, line 37 ¶		skipping to change at page 37, line 37 ¶
	}		}
	<CODE ENDS>		<CODE ENDS>
	9.1. IPv6 Router Advertisements Submodule		9.1. IPv6 Router Advertisements Submodule
	RFC Editor: In this section, replace all occurrences of 'XXXX' with		RFC Editor: In this section, replace all occurrences of 'XXXX' with
	the actual RFC number and all occurrences of the revision date below		the actual RFC number and all occurrences of the revision date below
	with the date of RFC publication (and remove this note).		with the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-ipv6-router-advertisements@2016-08-18.yang"		<CODE BEGINS> file "ietf-ipv6-router-advertisements@2016-10-20.yang"
	submodule ietf-ipv6-router-advertisements {		submodule ietf-ipv6-router-advertisements {
	yang-version "1.1";		yang-version "1.1";
	belongs-to ietf-ipv6-unicast-routing {		belongs-to ietf-ipv6-unicast-routing {
	prefix "v6ur";		prefix "v6ur";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	skipping to change at page 38, line 15 ¶		skipping to change at page 38, line 15 ¶
	}		}
	import ietf-ip {		import ietf-ip {
	prefix "ip";		prefix "ip";
	}		}
	organization		organization
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netmod/>		"WG Web: <https://tools.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		WG Chair: Lou Berger
	<mailto:lberger@labn.net>		<mailto:lberger@labn.net>
	WG Chair: Kent Watsen		WG Chair: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>		<mailto:lhotka@nic.cz>
	skipping to change at page 38, line 42 ¶		skipping to change at page 38, line 42 ¶
	configuration and state data of IPv6 router advertisements.		configuration and state data of IPv6 router advertisements.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2016 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	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).		(https://trustee.ietf.org/license-info).
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
	'OPTIONAL' in the module text are to be interpreted as described		'OPTIONAL' in the module text are to be interpreted as described
	in RFC 2119 (http://tools.ietf.org/html/rfc2119).		in RFC 2119 (https://tools.ietf.org/html/rfc2119).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for		(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
	full legal notices.";		full legal notices.";
	reference		reference
	"RFC 4861: Neighbor Discovery for IP version 6 (IPv6).";		"RFC 4861: Neighbor Discovery for IP version 6 (IPv6).";
	revision 2016-08-18 {		revision 2016-10-20 {
	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";
	}		}
	/* State data */		/* State data */
	augment "/if:interfaces-state/if:interface/ip:ipv6" {		augment "/if:interfaces-state/if:interface/ip:ipv6" {
	description		description
	skipping to change at page 50, line 6 ¶		skipping to change at page 50, line 6 ¶
	Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini,		Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini,
	David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane		David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane
	Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman,		Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman,
	Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man-		Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man-
	Kit Yeung and Jeffrey Zhang for their helpful comments and		Kit Yeung and Jeffrey Zhang for their helpful comments and
	suggestions.		suggestions.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-netmod-rfc6020bis]
	Bjorklund, M., "The YANG 1.1 Data Modeling Language",
	draft-ietf-netmod-rfc6020bis-14 (work in progress), June
	2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc3688>.		editor.org/info/rfc3688>.
	[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,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc4861>.		editor.org/info/rfc4861>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6020>.		editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<http://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<http://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,		Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
	<http://www.rfc-editor.org/info/rfc7223>.		<https://www.rfc-editor.org/info/rfc7223>.
	[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",		[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
	RFC 7277, DOI 10.17487/RFC7277, June 2014,		RFC 7277, DOI 10.17487/RFC7277, June 2014,
	<http://www.rfc-editor.org/info/rfc7277>.		<https://www.rfc-editor.org/info/rfc7277>.
	13.2. Informative References		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
			RFC 7950, DOI 10.17487/RFC7950, August 2016,
			<https://www.rfc-editor.org/info/rfc7950>.
	[I-D.ietf-netmod-yang-json]		13.2. Informative References
	Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	draft-ietf-netmod-yang-json-10 (work in progress), March
	2016.
	[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, DOI 10.17487/RFC6087,		Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
	January 2011, <http://www.rfc-editor.org/info/rfc6087>.		January 2011, <https://www.rfc-editor.org/info/rfc6087>.
	[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
	Protocol (NETCONF) Access Control Model", RFC 6536,		Protocol (NETCONF) Access Control Model", RFC 6536,
	DOI 10.17487/RFC6536, March 2012,		DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6536>.		editor.org/info/rfc6536>.
	[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module		[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
	Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,		Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
	<http://www.rfc-editor.org/info/rfc7895>.		<https://www.rfc-editor.org/info/rfc7895>.
			[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
			RFC 7951, DOI 10.17487/RFC7951, August 2016,
			<https://www.rfc-editor.org/info/rfc7951>.
	Appendix A. The Complete Data Trees		Appendix A. The Complete Data Trees
	This appendix presents the complete configuration and state data		This appendix presents the complete configuration and state data
	trees of the core routing data model. See Section 2.2 for an		trees of the core routing data model. See Section 2.2 for an
	explanation of the symbols used. Data type of every leaf node is		explanation of the symbols used. Data type of every leaf node is
	shown near the right end of the corresponding line.		shown near the right end of the corresponding line.
	A.1. Configuration Data		A.1. Configuration Data
	+--rw routing		+--rw routing
	skipping to change at page 57, line 15 ¶		skipping to change at page 57, line 15 ¶
	description		description
	"Time interval between periodic updates.";		"Time interval between periodic updates.";
	}		}
	}		}
	}		}
	}		}
	Appendix D. Data Tree Example		Appendix D. Data Tree Example
	This section contains an example instance data tree in the JSON		This section contains an example instance data tree in the JSON
	encoding [I-D.ietf-netmod-yang-json], containing both configuration		encoding [RFC7951], containing both configuration and state data.
	and state data. The data conforms to a data model that is defined by		The data conforms to a data model that is defined by the following
	the following YANG library specification [RFC7895]:		YANG library specification [RFC7895]:
	{		{
	"ietf-yang-library:modules-state": {		"ietf-yang-library:modules-state": {
	"module-set-id": "3e9be92f252db56fe912cd61a6f516ecf2f46315",		"module-set-id": "3e9be92f252db56fe912cd61a6f516ecf2f46315",
	"module": [		"module": [
	{		{
	"name": "ietf-routing",		"name": "ietf-routing",
	"revision": "2016-08-18",		"revision": "2016-10-20",
	"feature": [		"feature": [
	"multiple-ribs",		"multiple-ribs",
	"router-id"		"router-id"
	],		],
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",		"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-ipv4-unicast-routing",		"name": "ietf-ipv4-unicast-routing",
	"revision": "2016-08-18",		"revision": "2016-10-20",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",		"urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-ipv6-unicast-routing",		"name": "ietf-ipv6-unicast-routing",
	"revision": "2016-08-18",		"revision": "2016-10-20",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing",		"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing",
	"conformance-type": "implement",		"conformance-type": "implement",
	"submodule": [		"submodule": [
	{		{
	"name": "ietf-ipv6-router-advertisements",		"name": "ietf-ipv6-router-advertisements",
	"revision": "2016-08-18"		"revision": "2016-10-20"
	}		}
	]		]
	},		},
	{		{
	"name": "ietf-interfaces",		"name": "ietf-interfaces",
	"revision": "2014-05-08",		"revision": "2014-05-08",
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",		"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	skipping to change at page 65, line 25 ¶		skipping to change at page 65, line 25 ¶
	}		}
	}		}
	}		}
	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 -22 and -23		E.1. Changes Between Versions -22 and -23
			o Fix paths in "when" expressions due to errata 4749 of RFC 7950.
			E.2. Changes Between Versions -22 and -23
	o Removed "route-tag" feature.		o Removed "route-tag" feature.
	o Removed next-hop classifiers.		o Removed next-hop classifiers.
	o Fixed invalid when expressions in augments.		o Fixed invalid when expressions in augments.
	o In simple-next-hop, an address, outgoing interface or both can be		o In simple-next-hop, an address, outgoing interface or both can be
	specified.		specified.
	o RPC "fib-route" changed into RIB action "active-route".		o RPC "fib-route" changed into RIB action "active-route".
	o The requirement that direct routes be always placed in default		o The requirement that direct routes be always placed in default
	RIBs.		RIBs.
	E.2. Changes Between Versions -21 and -22		E.3. Changes Between Versions -21 and -22
	o Added "next-hop-list" as a new case of the "next-hop-options"		o Added "next-hop-list" as a new case of the "next-hop-options"
	choice.		choice.
	o Renamed "routing protocol" to "control plane protocol" in both the		o Renamed "routing protocol" to "control plane protocol" in both the
	YANG modules and I-D text.		YANG modules and I-D text.
	E.3. Changes Between Versions -20 and -21		E.4. Changes Between Versions -20 and -21
	o Routing instances were removed.		o Routing instances were removed.
	o IPv6 RA parameters were moved to the "ietf-ipv6-router-		o IPv6 RA parameters were moved to the "ietf-ipv6-router-
	advertisements".		advertisements".
	E.4. Changes Between Versions -19 and -20		E.5. Changes Between Versions -19 and -20
	o Assignment of L3 interfaces to routing instances is now part of		o Assignment of L3 interfaces to routing instances is now part of
	interface configuration.		interface configuration.
	o Next-hop options in configuration were aligned with state data.		o Next-hop options in configuration were aligned with state data.
	o It is recommended to enclose protocol-specific configuration in a		o It is recommended to enclose protocol-specific configuration in a
	presence container.		presence container.
	E.5. Changes Between Versions -18 and -19		E.6. Changes Between Versions -18 and -19
	o The leaf "route-preference" was removed from the "routing-		o The leaf "route-preference" was removed from the "routing-
	protocol" container in both "routing" and "routing-state".		protocol" container in both "routing" and "routing-state".
	o The "vrf-routing-instance" identity was added in support of a		o The "vrf-routing-instance" identity was added in support of a
	common routing-instance type in addition to the "default-routing-		common routing-instance type in addition to the "default-routing-
	instance".		instance".
	o Removed "enabled" switch from "routing-protocol".		o Removed "enabled" switch from "routing-protocol".
	E.6. Changes Between Versions -17 and -18		E.7. Changes Between Versions -17 and -18
	o The container "ribs" was moved under "routing-instance" (in both		o The container "ribs" was moved under "routing-instance" (in both
	"routing" and "routing-state").		"routing" and "routing-state").
	o Typedefs "rib-ref" and "rib-state-ref" were removed.		o Typedefs "rib-ref" and "rib-state-ref" were removed.
	o Removed "recipient-ribs" (both state and configuration).		o Removed "recipient-ribs" (both state and configuration).
	o Removed "connected-ribs" from "routing-protocol" (both state and		o Removed "connected-ribs" from "routing-protocol" (both state and
	configuration).		configuration).
	skipping to change at page 67, line 7 ¶		skipping to change at page 67, line 10 ¶
	rather than list (both config and state). The opposite reference		rather than list (both config and state). The opposite reference
	from "if:interface" to "rt:routing-instance" was changed to a		from "if:interface" to "rt:routing-instance" was changed to a
	single leaf (an interface cannot belong to multiple routing		single leaf (an interface cannot belong to multiple routing
	instances).		instances).
	o Specification of a default RIB is now a simple flag under "rib"		o Specification of a default RIB is now a simple flag under "rib"
	(both config and state).		(both config and state).
	o Default RIBs are marked by a flag in state data.		o Default RIBs are marked by a flag in state data.
	E.7. Changes Between Versions -16 and -17		E.8. Changes Between Versions -16 and -17
	o Added Acee as a co-author.		o Added Acee as a co-author.
	o Removed all traces of route filters.		o Removed all traces of route filters.
	o Removed numeric IDs of list entries in state data.		o Removed numeric IDs of list entries in state data.
	o Removed all next-hop cases except "simple-next-hop" and "special-		o Removed all next-hop cases except "simple-next-hop" and "special-
	next-hop".		next-hop".
	o Removed feature "multipath-routes".		o Removed feature "multipath-routes".
	o Augmented "ietf-interfaces" module with a leaf-list of leafrefs		o Augmented "ietf-interfaces" module with a leaf-list of leafrefs
	pointing form state data of an interface entry to the routing		pointing form state data of an interface entry to the routing
	instance(s) to which the interface is assigned.		instance(s) to which the interface is assigned.
	E.8. Changes Between Versions -15 and -16		E.9. Changes Between Versions -15 and -16
	o Added 'type' as the second key component of 'routing-protocol',		o Added 'type' as the second key component of 'routing-protocol',
	both in configuration and state data.		both in configuration and state data.
	o The restriction of no more than one connected RIB per address		o The restriction of no more than one connected RIB per address
	family was removed.		family was removed.
	o Removed the 'id' key of routes in RIBs. This list has no keys		o Removed the 'id' key of routes in RIBs. This list has no keys
	anymore.		anymore.
	skipping to change at page 68, line 12 ¶		skipping to change at page 68, line 14 ¶
	o Added next-hop lists to state data.		o Added next-hop lists to state data.
	o Added two cases for specifying next-hops indirectly - via a new		o Added two cases for specifying next-hops indirectly - via a new
	RIB or a recursive list of next-hops.		RIB or a recursive list of next-hops.
	o Reorganized next-hop in static routes.		o Reorganized next-hop in static routes.
	o Removed all 'if-feature' statements from state data.		o Removed all 'if-feature' statements from state data.
	E.9. Changes Between Versions -14 and -15		E.10. 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.10. Changes Between Versions -13 and -14		E.11. 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.11. Changes Between Versions -12 and -13		E.12. 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 state data - it		o Remove "when" statement for IPv6 router interface state data - it
	was dependent on a config value that may not be present.		was dependent on a config value that may not be 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 state data.		entries in state data.
	skipping to change at page 69, line 8 ¶		skipping to change at page 69, line 10 ¶
	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.12. Changes Between Versions -11 and -12		E.13. 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.13. Changes Between Versions -10 and -11		E.14. 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 69, line 45 ¶		skipping to change at page 69, line 47 ¶
	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.14. Changes Between Versions -09 and -10		E.15. Changes Between Versions -09 and -10
	o Added subtree for 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.15. Changes Between Versions -08 and -09		E.16. Changes Between Versions -08 and -09
	o Fixed "must" expression for "connected-routing-table".		o Fixed "must" expression 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.16. Changes Between Versions -07 and -08		E.17. Changes Between Versions -07 and -08
	o Changed reference from RFC6021 to RFC6021bis.		o Changed reference from RFC6021 to RFC6021bis.
	E.17. Changes Between Versions -06 and -07		E.18. 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.18. Changes Between Versions -05 and -06		E.19. 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 71, line 20 ¶		skipping to change at page 71, line 20 ¶
	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.19. Changes Between Versions -04 and -05		E.20. 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 72, line 8 ¶		skipping to change at page 72, line 8 ¶
	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.20. Changes Between Versions -03 and -04		E.21. Changes Between Versions -03 and -04
	o Changed "error-tag" for both RPC operations from "missing element"		o Changed "error-tag" for both RPC operations from "missing element"
	to "data-missing".		to "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.21. Changes Between Versions -02 and -03		E.22. 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 73, line 5 ¶		skipping to change at page 73, line 5 ¶
	"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.22. Changes Between Versions -01 and -02		E.23. 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 73, line 29 ¶		skipping to change at page 73, line 29 ¶
	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.23. Changes Between Versions -00 and -01		E.24. 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. 82 change blocks.
	118 lines changed or deleted		121 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/