draft-ietf-netmod-routing-cfg-02.txt		draft-ietf-netmod-routing-cfg-03.txt
	NETMOD L. Lhotka		NETMOD L. Lhotka
	Internet-Draft CZ.NIC		Internet-Draft CZ.NIC
	Intended status: Standards Track February 20, 2012		Intended status: Standards Track May 25, 2012
	Expires: August 23, 2012		Expires: November 26, 2012
	A YANG Data Model for Routing Configuration		A YANG Data Model for Routing Configuration
	draft-ietf-netmod-routing-cfg-02		draft-ietf-netmod-routing-cfg-03
	Abstract		Abstract
	This document contains a specification of four 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
	basis for configuring a routing subsystem. It is therefore expected		framework for configuring a routing subsystem. It is therefore
	that this module will be augmented by additional YANG modules		expected that this module will be augmented by additional YANG
	defining data models for individual routing protocols and other		modules defining data models for individual routing protocols and
	related functions. The core routing data model provides common		other related functions. The core routing data model provides common
	building blocks for such configurations - router instances, routes,		building blocks for such configurations - router instances, routes,
	routing tables, routing protocols and route filters.		routing tables, 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 August 23, 2012.		This Internet-Draft will expire on November 26, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 21		skipping to change at page 2, line 21
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4		2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4
	2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4		2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4
	2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5		2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
	3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. The Design of the Core Routing Data Model . . . . . . . . . . 7		4. The Design of the Core Routing Data Model . . . . . . . . . . 7
	4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 10		4.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 10
	4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 12		4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 12
	4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 13		4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 13
	4.4.1. Defining New Routing Protocols . . . . . . . . . . . . 14		4.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 14
			4.4.2. Defining New Routing Protocols . . . . . . . . . . . . 14
	4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 17		4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 17
	4.6. RPC Operation . . . . . . . . . . . . . . . . . . . . . . 18		4.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 18
	5. IANA AFN and SAFI YANG Module . . . . . . . . . . . . . . . . 19		4.6.1. Operation "active-route" . . . . . . . . . . . . . . . 18
	6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 27		4.6.2. Operation "route-count" . . . . . . . . . . . . . . . 19
	7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 37		5. Interactions with Other YANG Modules . . . . . . . . . . . . . 20
	8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 41		5.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49		5.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 20
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 51		6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 22
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52		7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 34
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53		8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 38
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 53		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
	12.2. Informative References . . . . . . . . . . . . . . . . . . 53		10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
	Appendix A. Example: Adding a New Routing Protocol . . . . . . . 54		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
	Appendix B. Example: Reply to the NETCONF <get> Message . . . . . 57		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 63		12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
	C.1. Changes Between Versions -01 and -02 . . . . . . . . . . . 63		12.2. Informative References . . . . . . . . . . . . . . . . . . 51
	C.2. Changes Between Versions -00 and -01 . . . . . . . . . . . 63		Appendix A. Example: Adding a New Routing Protocol . . . . . . . 52
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64		Appendix B. Example: Reply to the NETCONF <get> Message . . . . . 55
			Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 60
			C.1. Changes Between Versions -02 and -03 . . . . . . . . . . . 60
			C.2. Changes Between Versions -01 and -02 . . . . . . . . . . . 60
			C.3. Changes Between Versions -00 and -01 . . . . . . . . . . . 61
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62
	1. Introduction		1. Introduction
	This document contains a specification of four 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 configuration variables required by [RFC4861].		the router configuration variables required by [RFC4861].
	o Module "iana-afn-safi" contains two type definitions translating
	IANA registries "Address Family Numbers" [IANA-AFN] and
	"Subsequent Address Family Identifiers" [IANA-SAFI] to YANG
	enumerations.
	The first three modules together define the so-called core routing		These modules together define the so-called core routing data model,
	data model. This data model will serve as a basis for the		which is proposed as a basis for the development of data models for
	development of data models for more sophisticated routing		more sophisticated routing configurations. While these three modules
	configurations. While these three modules can be directly used for		can be directly used for simple IP devices with static routing, their
	simple IP devices with static routing, their main purpose is to		main purpose is to provide essential building blocks for more
	provide essential building blocks for more complicated setups		complicated setups involving multiple routing protocols, multicast
	involving multiple routing protocols, multicast routing, additional		routing, additional address families, advanced functions such as
	address families, advanced functions such as route filtering or		route filtering or policy routing etc. To this end, it is expected
	policy routing etc. To this end, it is expected that the core		that the core routing data model will be augmented by numerous
	routing data model will be augmented by numerous modules developed by		modules developed by other IETF working groups.
	other 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
	o message		o message
	o operation		o protocol operation
	o server		o server
	The following terms are defined in [RFC6020]:		The following terms are defined in [RFC6020]:
	o augment		o augment
	o configuration data		o configuration data
	o container		o container
	skipping to change at page 5, line 4		skipping to change at page 5, line 4
	o module		o module
	o operational state data		o operational state data
	o prefix		o prefix
	o RPC operation		o RPC operation
	2.1. Glossary of New Terms		2.1. Glossary of New Terms
	active route: a route which is actually used for packet forwarding.		active route: a route which is actually used for sending packets.
	If there are multiple candidate routes with a matching destination		If there are multiple candidate routes with a matching destination
	prefix, then it is up to the routing algorithm to select the		prefix, then it is up to the routing algorithm to select the
	active route.		active route (or several active routes in the case of multi-path
			routing).
	core routing data model: YANG data model resulting from the		core routing data model: YANG data model resulting from the
	combination of "ietf-routing", "ietf-ipv4-unicast-routing-cfg" and		combination of "ietf-routing", "ietf-ipv4-unicast-routing" and
	"ietf-ipv6-unicast-routing-cfg" modules.		"ietf-ipv6-unicast-routing" modules.
	direct route: a route to a directly connected network.		direct route: a route to a directly connected network.
	2.2. Prefixes in Data Node Names		2.2. Prefixes in Data Node Names
	In this document, names of data nodes are used mostly without a		In this document, names of data nodes are used mostly without a
	prefix, as long as it is clear from the context in which YANG module		prefix, as long as it is clear from the context in which YANG module
	each name is defined. Otherwise, names are prefixed with their		each name is defined. Otherwise, names are prefixed using the
	standard prefix associated with the corresponding YANG module, as		standard prefix associated with the corresponding YANG module, as
	shown in Table 1.		shown in Table 1.
	+--------+---------------------------+------------+		+--------+---------------------------+--------------+
	| Prefix | YANG module | Reference |		| Prefix | YANG module | Reference |
	+--------+---------------------------+------------+		+--------+---------------------------+--------------+
	| eth | ex-ethernet | [YANG-IF] |		| ianaaf | iana-afn-safi | [IANA-IF-AF] |
	| | | |		| | | |
	| if | ietf-interfaces | [YANG-IF] |		| if | ietf-interfaces | [YANG-IF] |
	| | | |		| | | |
	| ip | ietf-ip | [YANG-IP] |		| ip | ietf-ip | [YANG-IP] |
	| | | |		| | | |
	| rip | example-rip | Appendix A |		| rip | example-rip | Appendix A |
	| | | |		| | | |
	| rt | ietf-routing | Section 6 |		| rt | ietf-routing | Section 6 |
	| | | |		| | | |
	| v4ur | ietf-ipv4-unicast-routing | Section 7 |		| v4ur | ietf-ipv4-unicast-routing | Section 7 |
	| | | |		| | | |
	| v6ur | ietf-ipv6-unicast-routing | Section 8 |		| v6ur | ietf-ipv6-unicast-routing | Section 8 |
	| | | |		| | | |
	| yang | ietf-yang-types | [RFC6021] |		| yang | ietf-yang-types | [RFC6021] |
	| | | |		| | | |
	| inet | ietf-inet-types | [RFC6021] |		| inet | ietf-inet-types | [RFC6021] |
	+--------+---------------------------+------------+		+--------+---------------------------+--------------+
	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
	skipping to change at page 7, line 13		skipping to change at page 7, line 13
	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. The combined data hierarchy is shown in		routing, respectively. The combined data hierarchy is shown in
	Figure 1, where brackets contain list keys and question marks		Figure 1, where brackets enclose list keys, "rw" means configuration,
	indicate optional data nodes. Nodes that represent configuration are		"ro" operational state data, and "?" means optional node.
	labeled with "rw" while operational state data have the "ro" label.		Parentheses enclose choice and case nodes, and case nodes are also
			marked with a colon (":").
	+--rw routing		+--rw routing
	+--rw router [name]		+--rw router [name]
	+--rw name		| +--rw name
	+--rw description?		| +--rw router-id?
	+--rw enabled?		| +--rw description?
	+--rw interfaces		| +--rw enabled?
	| +--rw interface [name]		| +--rw interfaces
	| +--rw name		| | +--rw interface [name]
	| +--rw v6ur:ipv6-router-advertisements		| | +--rw name
	| +--rw v6ur:send-advertisements?		| | +--rw v6ur:ipv6-router-advertisements
	| +--rw v6ur:max-rtr-adv-interval?		| | +--rw v6ur:send-advertisements?
	| +--rw v6ur:min-rtr-adv-interval?		| | +--rw v6ur:max-rtr-adv-interval?
	| +--rw v6ur:managed-flag?		| | +--rw v6ur:min-rtr-adv-interval?
	| +--rw v6ur:other-config-flag?		| | +--rw v6ur:managed-flag?
	| +--rw v6ur:link-mtu?		| | +--rw v6ur:other-config-flag?
	| +--rw v6ur:reachable-time?		| | +--rw v6ur:link-mtu?
	| +--rw v6ur:retrans-timer?		| | +--rw v6ur:reachable-time?
	| +--rw v6ur:cur-hop-limit?		| | +--rw v6ur:retrans-timer?
	| +--rw v6ur:default-lifetime?		| | +--rw v6ur:cur-hop-limit?
	| +--rw v6ur:prefix-list		| | +--rw v6ur:default-lifetime?
	| +--rw v6ur:prefix [seqno]		| | +--rw v6ur:prefix-list
	| +--rw v6ur:seqno		| | +--rw v6ur:prefix [prefix-spec]
	| +--rw v6ur:prefix-spec?		| | +--rw v6ur:prefix-spec
	| +--rw v6ur:valid-lifetime?		| | +--rw (control-adv-prefixes)?
	| +--rw v6ur:on-link-flag?		| | +--:(no-advertise)
	| +--rw v6ur:preferred-lifetime?		| | | +--rw v6ur:no-advertise?
	| +--rw v6ur:autonomous-flag?		| | +--:(advertise)
	+--rw routing-protocols		| | +--rw v6ur:valid-lifetime?
	| +--rw routing-protocol [name]		| | +--rw v6ur:on-link-flag?
	| +--rw name		| | +--rw v6ur:preferred-lifetime?
	| +--rw description?		| | +--rw v6ur:autonomous-flag?
	| +--rw type		| +--rw routing-protocols
	| +--rw connected-routing-tables		| | +--rw routing-protocol [name]
	| | +--rw routing-table [name]		| | +--rw name
	| | +--rw name		| | +--rw description?
	| | +--rw import-filter?		| | +--rw type
	| | +--rw export-filter?		| | +--rw connected-routing-tables
	| +--rw static-routes		| | | +--rw routing-table [name]
	| +--rw v4ur:ipv4		| | | +--rw name
	| | +--rw v4ur:route [seqno]		| | | +--rw import-filter?
	| | +--rw v4ur:seqno		| | | +--rw export-filter?
	| | +--rw v4ur:description?		| | +--rw static-routes
	| | +--rw v4ur:outgoing-interface?		| | +--rw v4ur:ipv4
	| | +--rw v4ur:dest-prefix?		| | | +--rw v4ur:route [seqno]
	| | +--rw v4ur:next-hop?		| | | +--rw v4ur:seqno
	| +--rw v6ur:ipv6		| | | +--rw v4ur:description?
	| +--rw v6ur:route [seqno]		| | | +--rw v4ur:outgoing-interface?
	| +--rw v6ur:seqno		| | | +--rw v4ur:dest-prefix
	| +--rw v6ur:description?		| | | +--rw v4ur:next-hop?
	| +--rw v6ur:outgoing-interface?		| | +--rw v6ur:ipv6
	| +--rw v6ur:dest-prefix?		| | +--rw v6ur:route [seqno]
	| +--rw v6ur:next-hop?		| | +--rw v6ur:seqno
	+--rw route-filters		| | +--rw v6ur:description?
	| +--rw route-filter [name]		| | +--rw v6ur:outgoing-interface?
	| +--rw name		| | +--rw v6ur:dest-prefix
	| +--rw description?		| | +--rw v6ur:next-hop?
	| +--rw type?		| +--rw routing-tables
	+--rw routing-tables		| +--rw routing-table [name]
	+--rw routing-table [name]		| +--rw name
	+--rw name		| +--rw address-family?
	+--rw address-family?		| +--rw safi?
	+--rw safi?		| +--rw description?
	+--rw description?		| +--ro routes
	+--ro routes		| | +--ro route
	| +--ro route		| | +--ro source-protocol
	| +--ro source-protocol?		| | +--ro age
	| +--ro last-modified?		| | +--ro v4ur:outgoing-interface?
	| +--ro v4ur:outgoing-interface?		| | +--ro v4ur:dest-prefix?
	| +--ro v4ur:dest-prefix?		| | +--ro v4ur:next-hop?
	| +--ro v4ur:next-hop?		| | +--ro v6ur:outgoing-interface?
	| +--ro v6ur:outgoing-interface?		| | +--ro v6ur:dest-prefix?
	| +--ro v6ur:dest-prefix?		| | +--ro v6ur:next-hop?
	| +--ro v6ur:next-hop?		| +--rw recipient-routing-tables
	+--rw recipient-routing-tables [recipient-name]		| +--rw recipient-routing-table [name]
	+--rw recipient-name		| +--rw name
	+--rw filter?		| +--rw filter?
			+--rw route-filters
			+--rw route-filter [name]
			+--rw name
			+--rw description?
			+--rw type?
	Figure 1: Data hierarchy of the core routing data model.		Figure 1: Data hierarchy of the core routing data model.
	As can be seen from Figure 1, the core routing data model introduces		As can be seen from Figure 1, the core routing data model introduces
	several generic components of a routing framework: routers, routing		several generic components of a routing framework: routers, routing
	tables containing routes, routing protocols, route filters and RPC		tables containing routes, routing protocols and route filters. The
	operations. The following subsections describe these components in		following subsections describe these components in more detail.
	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 setups can be realized.		routing setups can be realized.
	+--------+ +------------+		+--------+
	| direct | +---+ | |		| direct | +---+ +--------------+ +---+ +--------------+
	| routes |--->| F |--->| FIB |		| routes |--->| F |--->| |<---| F |<---| |
	+--------+ +---+ | |		+--------+ +---+ | main | +---+ | additional |
	+------------+		| routing | | routing |
	^
	|
	+---+
	| F |
	+---+
	^
	|
	+--------------+ +---+ +--------------+
	+--------+ | |<---| F |<---| |
	| static | +---+ | main | +---+ | additional |
	| routes |--->| F |--->| routing | | routing |
	+--------+ +---+ | table | +---+ | table |		+--------+ +---+ | table | +---+ | table |
	| |--->| F |--->| |		| static |--->| F |--->| |--->| F |--->| |
	+--------------+ +---+ +--------------+		| routes | +---+ +--------------+ +---+ +--------------+
	^ | ^ |		+--------+ ^ | ^ |
	| v | v		| v | v
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	| F | | F | | F | | F |		| F | | F | | F | | F |
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	^ | ^ |		^ | ^ |
	| v | v		| v | v
	+----------+ +----------+		+----------+ +----------+
	| routing | | routing |		| routing | | routing |
	| protocol | | protocol |		| protocol | | protocol |
	+----------+ +----------+		+----------+ +----------+
	Figure 2: Example setup of the routing subsystem		Figure 2: Example setup of the routing subsystem
	The example in Figure 2 shows a typical (though certainly not the		The example in Figure 2 shows a typical (though certainly not the
	only possible) organization of a more complex routing subsystem.		only possible) organization of a more complex routing subsystem for a
	Several of its features are worth mentioning:		single address family. Several of its features are worth mentioning:
	o Along with the main routing table, which must always be present,		o Along with the main routing table, which must always be present,
	an additional routing table is configured.		an additional routing table 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 routing		"direct" pseudo-protocols, is connected to one routing table with
	table with which it can exchange routes (in both directions,		which it can exchange routes (in both directions, except for the
	except for the "static" and "direct" pseudo-protocols).		"static" and "direct" pseudo-protocols).
	o Routing tables may also be connected to each other and exchange		o Routing tables may also be connected to each other and exchange
	routes in either direction (or both).		routes in either direction (or both).
	o The forwarding information base (FIB) is a special routing table
	which must always be present. Typically, the FIB contains the
	"direct" routes for all configured interfaces and also receives
	the active routes from the main routing table. The operating
	system kernel uses this information for packet forwarding.
	o Route exchanges along all connections may be controlled by means		o Route exchanges along all connections may be controlled by means
	of route filters, denoted by "F" in Figure 2.		of route filters, denoted by "F" in Figure 2.
	4.1. Router		4.1. Router
	Each router instance in the core routing data model represents a		Each router instance in the core routing data model represents a
	(logical) router whose configuration and operation is independent of		logical router. The exact semantics of this term is left to
	other router instances. Although it it not enforced by the data		implementations. For example, router instances may be completely
	model, different router instances normally do not internally share		isolated virtual routers or, alternatively, they may internally share
	any data. They may, however, communicate with each other via routing		certain information.
	protocols.
	Logical network interfaces must be assigned to a router instance in		Network layer interfaces must be assigned to a router instance in
	order to be able to participate in packet forwarding, routing		order to be able to participate in packet forwarding, routing
	protocols and other operations of that router instance. The		protocols and other operations of that router instance. The
	assignment is accomplished by creating a corresponding entry in the		assignment is accomplished by creating a corresponding entry in the
	list of router interfaces ("/router/interfaces/interface"). The key		list of router interfaces ("rt:interface"). The key of the list
	of the list entry MUST be the name of a configured logical interface.		entry MUST be the name of a configured network layer interface, i.e.,
	A logical interface MUST NOT be assigned to more than one router		the value of a node /if:interfaces/if:interface/if:name defined in
	instance.		the "ietf-interfaces" module.[YANG-IF].
	Apart from the key, each entry of the "/router/interfaces/interface"		Implementations MAY specify additional rules for the assignment of
	list MAY contain other configuration or operational state data		interfaces to logical routers. For example, it may be required that
	related to the corresponding logical interface.		the sets of interfaces assigned to different logical routers be
			disjoint.
			Apart from the key, each entry of the "rt:interface" list MAY contain
			other configuration or operational state data related to the
			corresponding router interface.
	4.1.1. Configuration of IPv6 Router Interfaces		4.1.1. Configuration of IPv6 Router 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 "/router/interfaces/interface" with definitions of the		data node "rt:interface" with definitions of the following
	following configuration variables as required by [RFC4861], sec.		configuration variables as required by [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,
	o link-mtu,		o link-mtu,
	o reachable-time,		o reachable-time,
	skipping to change at page 11, line 34		skipping to change at page 11, line 22
	* on-link-flag,		* on-link-flag,
	* 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 text of the module "ietf-ipv6-unicast-routing" (Section 8).		in the text of the module "ietf-ipv6-unicast-routing" (Section 8).
	NOTE: The "IsRouter" flag, which is also required by [RFC4861], was		NOTE: The "IsRouter" flag, which is also required by [RFC4861], is
	omitted. Is is expected that this variable will be implemented in		implemented by the "ietf-ip" module [YANG-IP] (leaf "ip:ip-
	another module, either "ietf-interfaces" or "ietf-ip".		forwarding").
	4.2. Route		4.2. Route
	Routes are basic units of information in a routing system. The core		Routes are basic units of information in a routing system. The core
	routing data model defines only the following minimal set of route		routing data model defines only the following minimal set of route
	attributes:		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 - IP address of the adjacent router or host to which		o "next-hop": IP address of the adjacent router or host to which
	packets with destination addresses belonging to destination-prefix		packets with destination addresses belonging to destination-prefix
	should be sent.		should be sent.
	o outgoing-interface - network interface that should be used for		o "outgoing-interface": network interface that should be used for
	sending packets with destination addresses belonging to		sending packets with destination addresses belonging to
	destination-prefix.		destination-prefix.
	The above list of route attributes is sufficient for a simple static		The above list of route attributes should suffice for a simple static
	routing configuration. It is expected that future modules defining		routing configuration. It is expected that future modules defining
	routing protocols will add other route attributes such as metrics or		routing protocols will add other route attributes such as metrics or
	preferences.		preferences.
	Routes and their attributes are used in both configuration data, for		Routes and their attributes are used both in configuration data, for
	example as manually configured static routes, and in operational		example as manually configured static routes, and in operational
	state data, for example as entries in routing tables.		state data, for example as entries in routing tables.
	4.3. Routing Tables		4.3. Routing Tables
	Routing tables are lists of routes complemented with administrative		Routing tables are lists of routes complemented with administrative
	data, namely:		data, namely:
	o source-protocol - name of the routing protocol from which the		o "source-protocol": name of the routing protocol from which the
	route was originally obtained.		route was originally obtained.
	o last-modified - date and time of last modification, or		o "age": number of seconds since the route was created or last
	installation, of the route.		updated.
	Each routing table may only contain routes of the same address family		Each routing table may only contain routes of the same address
	(AFN and SAFI).		family. Address family information consists of two parameters -
			"address-family" and "safi" (Subsequent Address Family Identifier,
			SAFI). The permitted values for these two parameters are defined by
			IANA and translated into YANG enumeration types "ianaaf:address-
			family" and "ianaaf:subsequent-address-family" [IANA-IF-AF].
	In the core routing data model, the "routing-table" node represents		In the core routing data model, the "routing-table" node represents
	configuration while the descendant list of routes is defined as		configuration while the descendant list of routes is defined as
	operational state data. The contents of such lists are controlled by		operational state data. The contents of route lists are controlled
	routing protocol operations which may result in route additions,		and manipulated by routing protocol operations which may result in
	removals and modifications. This also includes manipulations via the		route additions, removals and modifications. This also includes
	"static" pseudo-protocol.		manipulations via the "static" and/or "direct" pseudo-protocols, see
			Section 4.4.1.
	At least the following two routing tables MUST be configured for each		One routing table MUST be present for each router instance and each
	router instance and each supported AFN/SAFI pair:		address family supported by that router instance. It is the so-
			called main routing table to which all routing protocol instances
			supporting the given address family SHOULD be connected by default.
			For the two address families that are part of the core routing data
			model, the names of the main routing tables SHOULD be as follows:
	1. Forwarding information base (FIB) contains active routes that are		o "main-ipv4-unicast" for IPv4 unicast,
	used by the operating system kernel for forwarding datagrams.
	2. Main routing table to which all routing protocol instances are		o "main-ipv6-unicast" for IPv6 unicast.
	connected by default, with the exception of the "direct" pseudo-
	protocol (Section 4.4): direct routes only appear in the FIB
	table by default.
	The main routing table SHOULD serve as the default source of active		Additional routing tables MAY be configured by creating new entries
	routes for the FIB.		in the "routing-table" list, either as a part of factory-default
			configuration, or by a client's action.
	One or more additional routing tables MAY be configured by creating		The naming scheme for additional routing tables, as well as
	new entries in the "routing-table" list, either being a part of		restrictions on the number and configurability of routing tables are
	factory-default configuration or configured by the client.		implementation-specific.
	The naming scheme for routing tables, as well as restrictions on the		The way how the routing system uses information from routing tables
	number and configurability of routing tables are implementation-		is outside the scope of this document. Typically, implementations
	specific.		will either use a forwarding table, or perform a direct look-up in
			the main routing table in conjunction with a route cache.
	Every routing table can serve as a source of routes for other routing		Every routing table can serve as a source of routes for other routing
	tables. To achieve this, one or more recipient routing tables may be		tables. To achieve this, one or more recipient routing tables may be
	specified in the configuration of the source routing table. In		specified in the configuration of the source routing table. In
	addition, a route filter may be configured for each recipient routing		addition, a route filter may be configured for each recipient routing
	table, which selects and/or manipulates the routes that are passed on		table, which selects and/or manipulates the routes that are passed on
	between the source and recipient routing table.		between the source and recipient routing table.
	4.4. Routing Protocols		4.4. Routing Protocols
	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. Each of them is		defining multiple routing protocol instances. Each of them is
	identified by a name, which MUST be unique within a router instance.		identified by a name, which MUST be unique within a router instance.
	Each protocol MUST be assigned a type, which MUST be an identity		Each protocol MUST be assigned a type, which MUST be an identity
	derived from the "rt:routing-protocol" base identity. The core		derived from the "rt:routing-protocol" base identity. The core
	routing data model defines two identities for the "direct" and		routing data model defines two identities for the direct and static
	"static" pseudo-protocols.		pseudo-protocols (Section 4.4.1).
	Each routing protocol instance is connected to exactly one routing		Each routing protocol instance is connected to exactly one routing
	table. By default, every routing protocol instance SHOULD be		table for each address family that the routing protocol instance
	connected to the main routing table. An implementation MAY allow any		supports. By default, every routing protocol instance SHOULD be
	or all routing protocol instances to be configured to use a different		connected to the main routing table or tables. An implementation MAY
	routing table.		allow any or all routing protocol instances to be configured to use a
			different routing table.
	Routes learned from the network by a routing protocol are passed to		Routes learned from the network by a routing protocol are passed to
	the connected routing table and vice versa - routes appearing in a		the connected routing table(s) and vice versa - routes appearing in a
	routing table are passed to all routing protocols connected to the		routing table are passed to all routing protocols connected to the
	table (except "direct" and "static" pseudo-protocols) and advertised		table (except "direct" and "static" pseudo-protocols) and may be
	by that protocol to the network.		advertised by that protocol to the network.
	Two independent route filters (see Section 4.5) may be defined for a		Two independent route filters (see Section 4.5) may be defined for a
	routing protocol instance to control the exchange of routes in both		routing protocol instance to control the exchange of routes in both
	directions between the routing protocol instance and the connected		directions between the routing protocol instance and the connected
	routing table:		routing table:
	o import filter controls which routes are passed from a routing		o import filter controls which routes are passed from a routing
	protocol instance to the routing table,		protocol instance to the routing table,
	o export filter controls which routes the routing protocol instance		o export filter controls which routes the routing protocol instance
	may receive from the connected routing table.		may receive from the connected routing table.
	Note that, for historical reasons, the terms import and export are		Note that, for historical reasons, the terms import and export are
	used from the viewpoint of a routing table.		used from the viewpoint of a routing table.
	The core routing data model defines two special routing protocols -		4.4.1. Routing Pseudo-Protocols
	"direct" and "static". Both are in fact pseudo-protocols, which
	means that they are confined to the local device and do not exchange		The core routing data model defines two special routing protocol
	any routing information with neighboring routers. Routes from both		types - "direct" and "static". Both are in fact pseudo-protocols,
	"direct" and "static" protocol instances are passed to the connected		which means that they are confined to the local device and do not
	routing table (subject to route filters, if any), but an exchange in		exchange any routing information with neighboring routers. Routes
	the opposite direction is not allowed.		from both "direct" and "static" protocol instances are passed to the
			connected routing table (subject to route filters, if any), but an
			exchange in the opposite direction is not allowed.
	Every router instance MUST contain exactly one instance of the		Every router instance MUST contain exactly one instance of the
	"direct" pseudo-protocol. It is the source of direct routes which		"direct" pseudo-protocol type. The name of this instance MUST also
	are normally supplied by the operating system kernel, based on the		be "direct". It is the source of direct routes for all configured
	detected and configured network interfaces, and they SHOULD by		address families. Direct routes are normally supplied by the
	default appear in the FIB routing table. However, using the		operating system kernel, based on the configuration of network
	framework defined in this document, the target routing table for		interface addresses, see Section 5.2. Direct routes SHOULD by
	direct routes MAY be changed by connecting the "direct" protocol		default appear in the main routing table for each configured address
	instance to a non-default routing table. Direct routes can also be		family. However, using the framework defined in this document, the
	filtered before they appear in the routing table.		target routing table for direct routes MAY be changed by connecting
			the "direct" protocol instance to a non-default routing table.
			Direct routes can also be filtered before they appear in the routing
			table.
	The "static" routing pseudo-protocol 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 implementation will have exactly one instance per		although a typical implementation will have exactly one instance per
	router.		logical router.
	4.4.1. Defining New Routing Protocols		4.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. In order to do so, the new module		additional routing protocol types. Such a new module has to define
	has to define the protocol-specific information and fit it into the		the protocol-specific configuration and operational state data, and
	core routing framework in the following way :		fit 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. Their definitions		o Additional route attributes MAY be defined, preferably in one
	then have to be inserted as operational state data by augmenting		place by means of defining a YANG grouping. The new attributes
	the definition of "rt:route" inside "rt:routing-table", and		have to be inserted as operational state data by augmenting the
	possibly to other places in the configuration, operational state		definition of "rt:route" inside "rt:routing-table", and possibly
	data and RPC input or output.		to other places in the configuration, operational state data and
			RPC input or output.
	o Per-interface configuration parameters can be added by augmenting		o Per-interface configuration parameters can be added by augmenting
	the data node "rt:interface" (the list of router interfaces).		the data node "rt:interface" (the list of router interfaces).
	o Other configuration parameters can be defined by augmenting the		o Other configuration parameters and operational state data can be
	"routing-protocol" data node. By using the "when" statement, this		defined by augmenting the "routing-protocol" data node. By using
	augment SHOULD be made conditional and valid only if the value of		the "when" statement, this augment SHOULD be made conditional and
	the "rt:type" child leaf equals to the new protocol's identity.		valid only if the value of the "rt:type" child leaf equals to the
			new protocol's identity.
	It is recommended that both per-interface and other configuration		It is RECOMMENDED that both per-interface and other configuration
	data specific to the new protocol be encapsulated in an appropriately		data specific to the new protocol be encapsulated in an appropriately
	named container.		named container.
	The above steps are implemented by the example YANG module for the		The above steps are implemented by the example YANG module for the
	RIP routing protocol in Appendix A. First, the module defines a new		RIP routing protocol in Appendix A. First, the module defines a new
	identity for the RIP protocol:		identity for the RIP protocol:
	identity rip {		identity rip {
	base rt:routing-protocol;		base rt:routing-protocol;
	description "Identity for the RIP routing protocol.";		description "Identity for the RIP routing protocol.";
	}		}
	New route attributes specific to the RIP protocol ("metric" and		New route attributes specific to the RIP protocol ("metric" and
	"tag") are defined in a grouping and then added to the route		"tag") are defined in a grouping and then added to the route
	definitions appearing in "routing-table" and in the output part of		definitions appearing in "routing-table" and in the output part of
	the "get-route" RPC method:		the "active-route" RPC method:
	grouping route-content {		grouping route-content {
	description		description
	"RIP-specific route content.";		"RIP-specific route content.";
	leaf metric {		leaf metric {
	type rip-metric;		type rip-metric;
	}		}
	leaf tag {		leaf tag {
	type uint16;		type uint16;
	default "0";		default "0";
	skipping to change at page 16, line 34		skipping to change at page 16, line 34
	+ "rt:type='rip:rip'" {		+ "rt:type='rip:rip'" {
	description		description
	"This augment is only valid if the source protocol from which		"This augment is only valid if the source protocol from which
	the route originated is RIP.";		the route originated is RIP.";
	}		}
	description		description
	"RIP-specific route components.";		"RIP-specific route components.";
	uses route-content;		uses route-content;
	}		}
	augment "/rt:get-route/rt:output/rt:route" {		augment "/rt:active-route/rt:output/rt:route" {
	description		description
	"Add RIP-specific route content.";		"Add RIP-specific route content.";
	uses route-content;		uses route-content;
	}		}
	Per-interface configuration data are defined by the following		Per-interface configuration data are defined by the following
	"augment" statement:		"augment" statement:
	augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {		augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {
	when "../../rt:routing-protocols/rt:routing-protocol/rt:type = "		when "../../rt:routing-protocols/rt:routing-protocol/rt:type = "
	skipping to change at page 17, line 50		skipping to change at page 17, line 50
	}		}
	}		}
	4.5. Route Filters		4.5. Route Filters
	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 routing		exchanged between a routing protocol instance and a connected routing
	table, or between a source and a recipient routing table. Route		table, or between a source and a recipient routing table. Route
	filters may also manipulate routes, i.e., add, delete, or modify		filters may also manipulate routes, i.e., add, delete, or modify
	their properties.		their attributes.
			Route filters are global, which means that a configured route filter
			may be used by any or all router instances.
	By itself, the route filtering framework defined in this document		By itself, the route filtering framework defined in this document
	allows to establish only the two extreme routing policies in which		allows for applying only the extreme routing policies which are
	either all routes are allowed or all routes are rejected. It is		represented by the following pre-defined route filter types:
	expected that real route filtering frameworks will be developed
			o "deny-all-route-filter": all routes are blocked,
			o "allow-all-route-filter": all routes are permitted.
			It is expected that real route filtering frameworks will be developed
	separately.		separately.
	Each route filter is identified by a name which MUST be unique within		Each route filter is identified by a name which MUST be unique within
	a router instance. Its type MUST be specified by the "type" identity		a router instance. Its type MUST be specified by the "type" identity
	reference - this opens the space for multiple route filtering		reference - this opens the space for multiple route filtering
	framework implementations. The default value for route filter type		framework implementations. The default value for the route filter
	is the identity "deny-all-route-filter" defined in the "ietf-routing"		type is the identity "deny-all-route-filter".
	module, which represents a route filtering policy in which all routes
	are rejected.
	4.6. RPC Operation		4.6. RPC Operations
	The "ietf-routing" module defines the "get-route" RPC operation. It		The "ietf-routing" module defines two RPC operations:
	is used for querying the forwarding information base of a router
	instance. The first input parameter is the name of the router
	instance whose FIB is to be queried, and the second parameter is a
	destination address. Modules for particular address families are
	expected to augment the "destination-address" container with the
	"address" leaf, as it is done in the "ietf-ipv4-unicast-routing" and
	"ietf-ipv6-unicast-routing" modules.
	The server replies with an active route which is used for forwarding		o active-route,
	datagrams to the destination address within the selected router
	instance. Again, modules for particular address families are
	expected to augment the definition of output parameters with AFN/
	SAFI-specific contents.
	5. IANA AFN and SAFI YANG Module		o route-count.
	RFC Ed.: In this section, replace all occurrences of 'XXXX' with the		Their parameters and semantics are described in the following
	actual RFC number and all occurrences of the revision date below with		subsections.
	the date of RFC publication (and remove this note).
	<CODE BEGINS> file "iana-afn-safi@2012-02-20.yang"		4.6.1. Operation "active-route"
	module iana-afn-safi {		Description: Retrieve one or more active routes from the forwarding
			information base (FIB) of a router instance, i.e., the route(s)
			that are currently used by that router instance for sending
			datagrams to the destination whose address is provided as an input
			parameter.
	namespace "urn:ietf:params:xml:ns:yang:iana-afn-safi";		Parameters:
	prefix "ianaaf";		router-name: Name of the router instance whose FIB is to be
			queried.
	organization		destination-address: Network layer destination address for which
	"IANA";		the active routes are requested.
	contact		Positive Response: One or more "route" elements containing the
	"Internet Assigned Numbers Authority		active route(s).
	Postal:		Negative Response:
	ICANN
	4676 Admiralty Way, Suite 330
	Marina del Rey, CA 90292
	U. S. A.
	Tel: +1 310 823 9358		If the logical router is not found, the server sends an "rpc-
	E-Mail: iana&iana.org		error" message with "error-tag" set to "missing-element", and
	";		"error-app-tag" set to "router-not-found".
	description		If no route exists for the given destination address, the server
	"This YANG module provides two typedefs containing YANG		sends an "rpc-error" message with "error-tag" set to "data-
	definitions for the following IANA-registered enumerations:		missing" and "error-app-tag" set to "no-route".
	- Address Family Numbers (AFN)		4.6.2. Operation "route-count"
	- Subsequent Address Family Identifiers (SAFI)		Description: Retrieve the total number of routes in a routing table.
	The latest revision of this YANG module can be obtained from the		Parameters:
	IANA web site.
	Copyright (c) 2012 IETF Trust and the persons identified as		router-name: Name of the logical router containing the routing
	authors of the code. All rights reserved.		table.
	Redistribution and use in source and binary forms, with or		routing-table: Name of the routing table.
	without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents
	(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see the		Positive Response: Element "number-of-routes" containing the
	RFC itself for full legal notices.		requested nonnegative number.
	";
	revision 2012-02-20 {		Negative Response: If the logical router or the routing table is not
	description		found, the server sends an "rpc-error" message with "error-tag"
	"Initial revision.";		set to "missing-element", and "error-app-tag" set to "router-not-
	reference		found" or "routing-table-not-found", respectively.
	"RFC XXXX: A YANG Data Model for Routing Configuration";
	}
	typedef address-family {		5. Interactions with Other YANG Modules
	type enumeration {
	enum other {
	value "0";
	description
	"none of the following";
	}
	enum ipV4 {
	value "1";
	description
	"IP Version 4";
	}
	enum ipV6 {
	value "2";
	description
	"IP Version 6";
	}
	enum nsap {
	value "3";
	description
	"NSAP";
	}
	enum hdlc {
	value "4";
	description
	"(8-bit multidrop)";
	}
	enum bbn1822 {
	value "5";
	description
	"BBN Report 1822";
	}
	enum all802 {
	value "6";
	description
	"(includes all 802 media plus Ethernet 'canonical
	format')";
	}
	enum e163 {
	value "7";
	description
	"E.163";
	}
	enum e164 {
	value "8";
	description
	"(SMDS, FrameRelay, ATM)";
	}
	enum f69 {
	value "9";
	description
	"(Telex)";
	}
	enum x121 {
	value "10";
	description
	"(X.25, Frame Relay)";
	}
	enum ipx {
	value "11";
	description
	"IPX (Internet Protocol Exchange)";
	}
	enum appleTalk {
	value "12";
	description
	"Apple Talk";
	}
	enum decnetIV {
	value "13";
	description
	"DEC Net Phase IV";
	}
	enum banyanVines {
	value "14";
	description
	"Banyan Vines";
	}
	enum e164withNsap {
	value "15";
	description
	"(E.164 with NSAP format subaddress)";
	}
	enum dns {
	value "16";
	description
	"(Domain Name System)";
	}
	enum distinguishedName {
	value "17";
	description
	"(Distinguished Name, per X.500)";
	}
	enum asNumber {
	value "18";
	description
	"(16-bit quantity, per the AS number space)";
	}
	enum xtpOverIPv4 {
	value "19";
	description
	"XTP over IP version 4";
	}
	enum xtpOverIpv6 {
	value "20";
	description
	"XTP over IP version 6";
	}
	enum xtpNativeModeXTP {
	value "21";
	description
	"XTP native mode XTP";
	}
	enum fibreChannelWWPN {
	value "22";
	description
	"Fibre Channel World-Wide Port Name";
	}
	enum fibreChannelWWNN {
	value "23";
	description
	"Fibre Channel World-Wide Node Name";
	}
	enum gwid {
	value "24";
	description
	"Gateway Identifier";
	}
	enum afi {
	value "25";
	description
	"AFI for L2VPN";
	}
	}
	description
	"This typedef is a YANG enumeration of IANA-registered address
	family numbers (AFN).";
	reference
	"Address Family Numbers. IANA, 2011-01-20.
	<http://www.iana.org/assignments/address-family-numbers/
	address-family-numbers.xml>
	IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS		The semantics of the core routing data model also depends on several
	<http://www.iana.org/assignments/ianaaddressfamilynumbers-mib>		configuration parameters that are defined in other YANG modules. The
	";		following subsections describe these interactions.
	}
	typedef subsequent-address-family {		5.1. Module "ietf-interfaces"
	type enumeration {
	enum nlri-unicast {
	value "1";
	description
	"Network Layer Reachability Information used for unicast
	forwarding";
	reference
	"RFC4760";
	}
	enum nlri-multicast {
	value "2";
	description
	"Network Layer Reachability Information used for multicast
	forwarding";
	reference
	"RFC4760";
	}
	enum nlri-mpls {
	value "4";
	description
	"Network Layer Reachability Information (NLRI) with MPLS
	Labels";
	reference
	"RFC3107";
	}
	enum mcast-vpn {
	value "5";
	description
	"MCAST-VPN";
	reference		The following boolean switch is defined in the "ietf-interfaces" YANG
	"draft-ietf-l3vpn-2547bis-mcast-bgp-08";		module [YANG-IF]:
	}
	enum nlri-dynamic-ms-pw {
	value "6";
	status "obsolete";
	description
	"Network Layer Reachability Information used for Dynamic
	Placement of Multi-Segment Pseudowires (TEMPORARY -
	Expires 2008-08-23)";
	reference
	"draft-ietf-pwe3-dynamic-ms-pw-13";
	}
	enum tunnel-safi {
	value "64";
	description
	"Tunnel SAFI";
	reference
	"draft-nalawade-kapoor-tunnel-safi-05";
	}
	enum vpls {
	value "65";
	description
	"Virtual Private LAN Service (VPLS)";
	reference
	"RFC4761, RFC6074";
	}
	enum bgp-mdt {
	value "66";
	description
	"BGP MDT SAFI";
	reference
	"RFC6037";
	}
	enum bgp-4over6 {
	value "67";
	description
	"BGP 4over6 SAFI";
	reference
	"RFC5747";
	}
	enum bgp-6over4 {
	value "68";
	description
	"BGP 6over4 SAFI";
	reference
	"mailto:cuiyong&tsinghua.edu.cn";
	}
	enum l1vpn-auto-discovery {
	value "69";
	description
	"Layer-1 VPN auto-discovery information";
	reference
	"draft-ietf-l1vpn-bgp-auto-discovery-05";
	}
	enum mpls-vpn {
	value "128";
	description
	"MPLS-labeled VPN address";
	reference
	"RFC4364";
	}
	enum multicast-bgp-mpls-vpn {
	value "129";
	description
	"Multicast for BGP/MPLS IP Virtual Private Networks
	(VPNs)";
	reference
	"draft-ietf-l3vpn-2547bis-mcast-10,
	draft-ietf-l3vpn-2547bis-mcast-10";
	}
	enum route-target-constraints {
	value "132";
	description
	"Route Target constraints";
	reference
	"RFC4684";
	}
	enum ipv4-diss-flow {
	value "133";
	description
	"IPv4 dissemination of flow specification rules";
	reference
	"RFC5575";
	}
	enum vpnv4-diss-flow {
	value "134";
	description
	"IPv4 dissemination of flow specification rules";
	reference
	"RFC5575";
	}
	enum vpn-auto-discovery {
	value "140";
	description
	"VPN auto-discovery";
	reference		/if:interfaces/if:interface/if:enabled
	"draft-ietf-l3vpn-bgpvpn-auto-09";
	}
	}
	description
	"This typedef is a YANG enumeration of IANA-registered
	subsequent address family identifiers (SAFI).";
	reference
	"Subsequent Address Family Identifiers (SAFI) Parameters. IANA,
	2011-03-04. <http://www.iana.org/assignments/safi-namespace/
	safi-namespace.xml>
	";
	}
	}
	<CODE ENDS>		If this switch is set to "false" for a given network layer
			interface, the device MUST behave exactly as if that interface was
			not assigned to any logical router at all.
			5.2. Module "ietf-ip"
			The following boolean switches are defined in the "ietf-ip" YANG
			module [YANG-IP]:
			/if:interfaces/if:interface/ip:ipv4/ip:enabled
			If this switch is set to "false" for a given interface, then all
			IPv4 routing functions related to that interface MUST be disabled.
			/if:interfaces/if:interface/ip:ipv4/ip:ip-forwarding
			If this switch is set to "false" for a given interface, then the
			forwarding of IPv4 datagrams to and from this interface MUST be
			disabled. However, the interface may participate in other routing
			functions, such as routing protocols.
			/if:interfaces/if:interface/ip:ipv6/ip:enabled
			If this switch is set to "false" for a given interface, then all
			IPv6 routing functions related to that interface MUST be disabled.
			/if:interfaces/if:interface/ip:ipv6/ip:ip-forwarding
			If this switch is set to "false" for a given interface, then the
			forwarding of IPv6 datagrams to and from this interface MUST be
			disabled. However, the interface may participate in other routing
			functions, such as routing protocols.
			In addition, the "ietf-ip" module allows for configuring IPv4 and
			IPv6 addresses and subnet masks. Configuration of these parameters
			on an enabled interface MUST result in an immediate creation of the
			corresponding direct route (usually in the main routing table). Its
			destination prefix is set according to the configured IP address and
			subnet mask, and the interface is set as the outgoing interface for
			that route.
	6. Routing YANG Module		6. Routing YANG Module
	RFC Ed.: In this section, replace all occurrences of 'XXXX' with the		RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
	actual RFC number and all occurrences of the revision date below with		actual RFC number and all occurrences of the revision date below with
	the date of RFC publication (and remove this note).		the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-routing@2012-02-20.yang"		<CODE BEGINS> file "ietf-routing@2012-05-24.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-inet-types {
	prefix "yang";		prefix "inet";
	}		}
	import ietf-interfaces {		import ietf-interfaces {
	prefix "if";		prefix "if";
	}		}
	import iana-afn-safi {		import iana-afn-safi {
	prefix "ianaaf";		prefix "ianaaf";
	}		}
	skipping to change at page 27, line 49		skipping to change at page 22, line 49
	<mailto:david.kessens@nsn.com>		<mailto:david.kessens@nsn.com>
	WG Chair: Juergen Schoenwaelder		WG Chair: Juergen Schoenwaelder
	<mailto:j.schoenwaelder@jacobs-university.de>		<mailto:j.schoenwaelder@jacobs-university.de>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>		<mailto:lhotka@nic.cz>
	";		";
	description		description
	"This module contains YANG definitions of essential components		"This YANG module defines essential components that may be used
	that may be used for configuring a routing subsystem.		for configuring a routing subsystem.
	Copyright (c) 2012 IETF Trust and the persons identified as		Copyright (c) 2012 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).		(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 2012-02-20 {		revision 2012-05-24 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing Configuration";		"RFC XXXX: A YANG Data Model for Routing Configuration";
	}		}
	/* Identities */		/* Identities */
	identity routing-protocol {		identity routing-protocol {
	description		description
	skipping to change at page 29, line 8		skipping to change at page 24, line 8
	description		description
	"Base identity from which all route filters are derived.";		"Base identity from which all route filters are derived.";
	}		}
	identity deny-all-route-filter {		identity deny-all-route-filter {
	base route-filter;		base route-filter;
	description		description
	"Route filter that blocks all routes.";		"Route filter that blocks all routes.";
	}		}
			identity allow-all-route-filter {
			base route-filter;
			description
			"Route filter that permits all routes.
			Note that use of this filter is equivalent to no filter at
			all.
			";
			}
	/* Type Definitions */		/* Type Definitions */
	typedef router-ref {		typedef router-ref {
	type leafref {		type leafref {
	path "/rt:routing/rt:router/rt:name";		path "/rt:routing/rt:router/rt:name";
	}		}
	description		description
	"This type is used for leafs that reference a router		"This type is used for leafs that reference a router
	instance.";		instance.";
	}		}
	/* Groupings */		/* Groupings */
	grouping afn-safi {		grouping afn-safi {
	leaf address-family {		leaf address-family {
	type ianaaf:address-family;		type ianaaf:address-family;
	default "ipV4";		default "ipv4";
	description		description
	"Address family of routes in the routing table.";		"Address family of routes in the routing table.";
	}		}
	leaf safi {		leaf safi {
	type ianaaf:subsequent-address-family;		type ianaaf:subsequent-address-family;
	default "nlri-unicast";		default "nlri-unicast";
	description		description
	"Subsequent address family identifier of routes in the		"Subsequent address family identifier of routes in the
	routing table.";		routing table.";
	}		}
	skipping to change at page 30, line 4		skipping to change at page 25, line 14
	"Generic parameters of routes.		"Generic parameters of routes.
	A module for an address family should define a specific		A module for an address family should define a specific
	version of this grouping containing 'uses rt:route-content'.		version of this grouping containing 'uses rt:route-content'.
	";		";
	leaf outgoing-interface {		leaf outgoing-interface {
	type if:interface-ref;		type if:interface-ref;
	description		description
	"Outgoing interface.";		"Outgoing interface.";
	}		}
	}		}
	/* RPC Methods */		/* RPC Methods */
	rpc get-route {		rpc active-route {
	description		description
	"Query the forwarding information base of a router instance		"Return the active route (or multiple routes, in the case of
	whose name is given as the first parameter 'router-name'. The		multi-path routing) to a destination address.
	second parameter 'destination-address' should be augmented in
	order to support destination addresses of all supported		Parameters
	address families. The server returns the route which is
	currently used for forwarding datagrams to that destination		1. 'router-name',
	address, or an error message, if no such route exists.";
			2. 'destination-address'.
			If the logical router with 'router-name' doesn't exist, then
			this operation will fail with error-tag 'missing-element' and
			error-app-tag 'router-not-found'.
			If there is no active route for 'destination-address', then
			this operation will fail with error-tag 'data-missing' and
			error-app-tag 'no-route'.
			";
	input {		input {
	leaf router-name {		leaf router-name {
	type router-ref;		type router-ref;
	mandatory "true";		mandatory "true";
	description		description
	"First parameter: name of the router instance whose		"Name of the router instance whose forwarding information
	forwarding information base is queried.";		base is being queried.";
	}		}
	container destination-address {		container destination-address {
	uses afn-safi;		uses afn-safi;
	description		description
	"Second parameter: destination address.		"Network layer destination address.
	AFN/SAFI-specific modules must augment this container with		AFN/SAFI-specific modules must augment this container with
	a leaf named 'address'.		a leaf named 'address'.
	";		";
	}		}
	}		}
	output {		output {
	container route {		list route {
			min-elements "1";
	uses afn-safi;		uses afn-safi;
			uses route-content;
	description		description
	"Contents of the reply specific for each address family		"Route contents specific for each address family should be
	should be defined through augmenting.";		defined through augmenting.";
			}
			}
			}
			rpc route-count {
			description
			"Return the current number of routes in a routing table.
			Parameters:
			1. 'router-name',
			2. 'routing-table-name'.
			If the logical router with 'router-name' doesn't exist, then
			this operation will fail with error-tag 'missing-element' and
			error-app-tag 'router-not-found'.
			If the routing table with 'routing-table-name' doesn't exist,
			then this operation will fail with error-tag 'missing-element'
			and error-app-tag 'routing-table-not-found'.
			";
			input {
			leaf router-name {
			type router-ref;
			mandatory "true";
			description
			"Name of the router instance containing the routing
			table.";
			}
			leaf routing-table {
			type leafref {
			path "/routing/router/routing-tables/routing-table/name";
			}
			mandatory "true";
			description
			"Name of the routing table.";
			}
			}
			output {
			leaf number-of-routes {
			type uint32;
			mandatory "true";
			description
			"Number of routes in the routing table.";
	}		}
	}		}
	}		}
	/* Data Nodes */		/* Data Nodes */
	container routing {		container routing {
	description		description
	"Routing parameters.";		"Routing parameters.";
	list router {		list router {
	key "name";		key "name";
	unique "interfaces/interface/name";		unique "router-id";
	description		description
	"Each list entry is a container for configuration and		'Each list entry is a container for configuration and
	operational state data of a single (logical) router.";		operational state data of a single (logical) router.
			Network layer interfaces assigned to the router must have
			their entries in the "interfaces" list.
			';
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"The unique router name.";		"The unique router name.";
	}		}
			leaf router-id {
			type inet:ipv4-address;
			description
			"Global router ID in the form of an IPv4 address.
			An implementation may select a value if this parameter is
			not configured.
			Routing protocols may override this global parameter
			inside their configuration.
			";
			}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the router.";		"Textual description of the router.";
	}		}
	leaf enabled {		leaf enabled {
	type boolean;		type boolean;
	default "true";		default "true";
	description		description
	"Enable or disable the router. The default value is 'true',		"Enable the router. The default value is 'true'.
	which means that the router is enabled.";
			If this parameter is false, the parent router instance is
			disabled, despite any other configuration that might be
			present.
			";
	}		}
	container interfaces {		container interfaces {
	description		description
	"Router interface parameters.";		"Router interface parameters.";
	list interface {		list interface {
	key "name";		key "name";
	description		description
	"List of logical interfaces assigned to the router		"List of network layer interfaces assigned to the router
	instance. Any logical interface can only be assigned to		instance.";
	one router instance.";
	leaf name {		leaf name {
	type if:interface-ref;		type if:interface-ref;
	description		description
	"A reference to the name of a configured logical		"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 configured routing protocol		"Container for the list of configured routing protocol
	instances.";		instances.";
	list routing-protocol {		list routing-protocol {
	key "name";		key "name";
	skipping to change at page 32, line 27		skipping to change at page 29, line 17
	mandatory "true";		mandatory "true";
	description		description
	"Type of the routing protocol - an identity derived		"Type of the routing protocol - an identity derived
	from the 'routing-protocol' base identity.";		from the 'routing-protocol' base identity.";
	}		}
	container connected-routing-tables {		container connected-routing-tables {
	description		description
	"Container for connected routing tables.";		"Container for connected routing tables.";
	list routing-table {		list routing-table {
	must "not(../../../../routing-tables/"		must "not(../../../../routing-tables/"
	+ "routing-table[current()/"		+ "routing-table[rt:name=current()/"
	+ "preceding-sibling::routing-table/name]/"		+ "preceding-sibling::routing-table/name]/"
	+ "address-family=../../../../routing-tables/"		+ "address-family=../../../../routing-tables/"
	+ "routing-table[current()/name]/"		+ "routing-table[rt:name=current()/name]/"
	+ "address-family and ../../../../routing-tables/"		+ "address-family and ../../../../routing-tables/"
	+ "routing-table[current()/"		+ "routing-table[rt:name=current()/"
	+ "preceding-sibling::routing-table/name]/safi=../"		+ "preceding-sibling::routing-table/name]/safi=../"
	+ "../../../routing-tables/routing-table[current()/"		+ "../../../routing-tables/"
	+ "name]/safi)" {		+ "routing-table[rt:name=current()/name]/safi)" {
	error-message		error-message "Each routing protocol may have no "
	"Each routing protocol may have no more than one		+ "more than one connected routing "
	connected routing table for each AFN and SAFI.";		+ "table for each AFN and SAFI.";
	description		description
	"For each AFN/SAFI pair there may be at most one		"For each AFN/SAFI pair there may be at most one
	connected routing table.";		connected routing table.";
	}		}
	key "name";		key "name";
	description		description
	"List of routing tables to which the routing protocol		"List of routing tables to which the routing protocol
	instance is connected.		instance is connected.
	Implementation may provide default routing tables		If no connected routing table is defined for an
	for some AFN/SAFI pairs, which are used if the		address family, the routing protocol should be
	corresponding entry is not configured.		connected by default to the main routing table for
			that address family.
	";		";
	leaf name {		leaf name {
	type leafref {		type leafref {
	path "../../../../../routing-tables/routing-table/"		path "../../../../../routing-tables/routing-table/"
	+ "name";		+ "name";
	}		}
	description		description
	"Reference to an existing routing table.";		"Reference to an existing routing table.";
	}		}
	leaf import-filter {		leaf import-filter {
	type leafref {		type leafref {
	skipping to change at page 33, line 15		skipping to change at page 30, line 5
	leaf name {		leaf name {
	type leafref {		type leafref {
	path "../../../../../routing-tables/routing-table/"		path "../../../../../routing-tables/routing-table/"
	+ "name";		+ "name";
	}		}
	description		description
	"Reference to an existing routing table.";		"Reference to an existing routing table.";
	}		}
	leaf import-filter {		leaf import-filter {
	type leafref {		type leafref {
	path "../../../../../route-filters/route-filter/"		path "/routing/route-filters/route-filter/name";
	+ "name";
	}		}
	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
	instance to the routing table specified by the		instance to the routing table specified by the
	'name' sibling node. If this leaf is not present,		'name' sibling node. If this leaf is not present,
	the behavior is protocol-specific, but typically		the behavior is protocol-specific, but typically
	it means that all routes are accepted.";		it means that all routes are accepted.";
	}		}
	leaf export-filter {		leaf export-filter {
	type leafref {		type leafref {
	path "../../../../../route-filters/route-filter/"		path "/routing/route-filters/route-filter/name";
	+ "name";
	}		}
	description		description
	"Reference to a route filter that is used for		"Reference to a route filter that is used for
	filtering routes passed from the routing table		filtering routes passed from the routing table
	specified by the 'name' sibling node to this		specified by the 'name' sibling node to this
	routing protocol instance. If this leaf is not		routing protocol instance. If this leaf is not
	present, the behavior is protocol-specific -		present, the behavior is protocol-specific -
	typically it means that all routes are accepted,		typically it means that all routes are accepted,
	except for the 'direct' and 'static'		except for the 'direct' and 'static'
	pseudo-protocols which accept no routes from any		pseudo-protocols which accept no routes from any
	routing table.";		routing table.";
	}		}
	}		}
	}		}
	container static-routes {		container static-routes {
	must "../type='static'" {		must "../type='rt:static'" {
	error-message		error-message "Static routes may be configured only "
	"Static routes may be configured only for 'static'		+ "for 'static' routing protocol.";
	routing protocol.";
	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 'static' pseudo-protocol.";		"Configuration of 'static' pseudo-protocol.";
	}		}
	}		}
	}		}
	container route-filters {
	description
	"Container for configured route filters.";
	list route-filter {
	key "name";
	description
	"Route filters are used for filtering and/or manipulating
	routes that are passed between a routing protocol and a
	routing table or vice versa, or between two routing
	tables. It is expected that other modules augment this
	list with contents specific for a particular route
	filter type.";
	leaf name {
	type string;
	description
	"The name of the route filter.";
	}
	leaf description {
	type string;
	description
	"Textual description of the route filter.";
	}
	leaf type {
	type identityref {
	base route-filter;
	}
	default "deny-all-route-filter";
	description
	"Type of the route-filter - an identity derived from
	the 'route-filter' base identity. The default value
	represents an all-blocking filter.";
	}
	}
	}
	container routing-tables {		container routing-tables {
	description		description
	"Container for configured routing tables.";		"Container for configured routing tables.";
	list routing-table {		list routing-table {
	key "name";		key "name";
	description		description
	"Each entry represents a routing table identified by the		"Each entry represents a routing table identified by the
	'name' key. All routes in a routing table must have the		'name' key. All routes in a routing table must have the
	same AFN and SAFI.";		same AFN and SAFI.";
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"The name of the routing table.";		"The name of the routing table.";
	}		}
	uses afn-safi;		uses afn-safi;
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the routing table.";		"Textual description of the routing table.";
	skipping to change at page 35, line 26		skipping to change at page 31, line 27
	container routes {		container routes {
	config "false";		config "false";
	description		description
	"Current contents of the routing table (operational		"Current contents of the routing table (operational
	state data).";		state data).";
	list route {		list route {
	description		description
	"A routing table entry. This data node must augmented		"A routing table entry. This data node must augmented
	with information specific for routes of each address		with information specific for routes of each address
	family.";		family.";
			uses route-content;
	leaf source-protocol {		leaf source-protocol {
	type leafref {		type leafref {
	path "../../../../../routing-protocols/"		path "/routing/router/routing-protocols/"
	+ "routing-protocol/name";		+ "routing-protocol/name";
	}		}
			mandatory "true";
	description		description
	"The name of the routing protocol instance from		"The name of the routing protocol instance from
	which the route comes. This routing protocol must		which the route comes. This routing protocol must
	be configured (automatically or manually) in the		be configured (automatically or manually) in the
	device.";		device.";
	}		}
	leaf last-modified {		leaf age {
	type yang:date-and-time;		type uint32;
			units "seconds";
			mandatory "true";
	description		description
	"Time stamp of the last modification of the route.		"The number of seconds since the parent route was
	If the route was never modified, it is the time		created or last updated.";
	when the route was inserted to the routing
	table.";
	}		}
	}		}
	}		}
	list recipient-routing-tables {		container recipient-routing-tables {
	key "recipient-name";
	description		description
	"A list of routing tables that receive routes from this		"Container for recipient routing tables.";
	routing table.";		list recipient-routing-table {
	leaf recipient-name {		key "name";
	type leafref {
	path "../../../routing-table/name";
	}
	description		description
	"The name of the recipient routing table.";		"A list of routing tables that receive routes from
	}		this routing table.";
	leaf filter {		leaf name {
	type leafref {		type leafref {
	path "../../../../route-filters/route-filter/name";		path "/routing/router/routing-tables/"
			+ "routing-table/name";
			}
			description
			"The name of the recipient routing table.";
			}
			leaf filter {
			type leafref {
			path "/routing/route-filters/route-filter/name";
			}
			description
			"A route filter which is applied to the routes
			passed on to the recipient routing table.";
	}		}
	description
	"A route filter which is applied to the routes passed
	on to the recipient routing table.";
	}		}
	}		}
	}		}
	}		}
	}		}
			container route-filters {
			description
			"Container for configured route filters.";
			list route-filter {
			key "name";
			description
			"Route filters are used for filtering and/or manipulating
			routes that are passed between a routing protocol and a
			routing table or vice versa, or between two routing
			tables. It is expected that other modules augment this
			list with contents specific for a particular route filter
			type.";
			leaf name {
			type string;
			description
			"The name of the route filter.";
			}
			leaf description {
			type string;
			description
			"Textual description of the route filter.";
			}
			leaf type {
			type identityref {
			base route-filter;
			}
			default "rt:deny-all-route-filter";
			description
			"Type of the route-filter - an identity derived from the
			'route-filter' base identity. The default value
			represents an all-blocking filter.";
			}
			}
			}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	7. IPv4 Unicast Routing YANG Module		7. IPv4 Unicast Routing YANG Module
	RFC Ed.: In this section, replace all occurrences of 'XXXX' with the		RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
	actual RFC number and all occurrences of the revision date below with		actual RFC number and all occurrences of the revision date below with
	the date of RFC publication (and remove this note).		the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-ipv4-unicast-routing@2012-02-20.yang"		<CODE BEGINS> file "ietf-ipv4-unicast-routing@2012-05-25.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 37, line 45		skipping to change at page 34, line 45
	<mailto:david.kessens@nsn.com>		<mailto:david.kessens@nsn.com>
	WG Chair: Juergen Schoenwaelder		WG Chair: Juergen Schoenwaelder
	<mailto:j.schoenwaelder@jacobs-university.de>		<mailto:j.schoenwaelder@jacobs-university.de>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>		<mailto:lhotka@nic.cz>
	";		";
	description		description
	"This module augments the 'ietf-routing' module with YANG		"This YANG module augments the 'ietf-routing' module with basic
	definitions for basic configuration of IPv4 unicast routing.		configuration and operational state data for IPv4 unicast
			routing.
			Every implementation must preconfigure a routing table with the
			name 'main-ipv4-unicast', which is the main routing table for
			IPv4 unicast.
	Copyright (c) 2012 IETF Trust and the persons identified as		Copyright (c) 2012 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).		(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 2012-02-20 {		revision 2012-05-24 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing Configuration";		"RFC XXXX: A YANG Data Model for Routing Configuration";
	}		}
	/* Groupings */		/* Groupings */
	grouping route-content {		grouping route-content {
	description		description
	"Parameters of IPv4 unicast routes.";		"Parameters of IPv4 unicast routes.";
	uses rt:route-content;
	leaf dest-prefix {		leaf dest-prefix {
	type inet:ipv4-prefix;		type inet:ipv4-prefix;
	description		description
	"IPv4 destination prefix.";		"IPv4 destination prefix.";
	}		}
	leaf next-hop {		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.";
	}		}
	}		}
	/* RPC Methods */		/* RPC Methods */
	augment "/rt:get-route/rt:input/rt:destination-address" {		augment "/rt:active-route/rt:input/rt:destination-address" {
	when "address-family='ipV4' and safi='nlri-unicast'" {		when "address-family='ipv4' and safi='nlri-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"The 'address' leaf augments the 'rt:destination-address'		"The 'address' leaf augments the 'rt:destination-address'
	parameter of the 'rt:get-route' operation.";		parameter of the 'rt:active-route' operation.";
	leaf address {		leaf address {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"IPv4 destination address.";		"IPv4 destination address.";
	}		}
	}		}
	augment "/rt:get-route/rt:output/rt:route" {		augment "/rt:active-route/rt:output/rt:route" {
	when "address-family='ipV4' and safi='nlri-unicast'" {		when "address-family='ipv4' and safi='nlri-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"Contents of the reply to 'rt:get-route' operation.";		"Contents of the reply to 'rt:active-route' operation.";
	uses route-content;		uses route-content;
	}		}
	/* Data nodes */		/* Data nodes */
	augment "/rt:routing/rt:router/rt:routing-protocols/"		augment "/rt:routing/rt:router/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 for IPv4 unicast.";		pseudo-protocol with data specific for 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 "seqno";		key "seqno";
	ordered-by "user";		ordered-by "user";
	description		description
	"A user-ordered list of static routes.";		"A user-ordered list of static routes.";
	leaf seqno {		leaf seqno {
	type uint16;		type uint32 {
			range "1..max";
			}
	description		description
	"Sequential number of the route.";		"Sequential number of the route.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the route.";		"Textual description of the route.";
	}		}
	uses route-content;		uses rt:route-content;
			uses route-content {
			refine "dest-prefix" {
			mandatory "true";
			}
			}
	}		}
	}		}
	}		}
	augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"		augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
	+ "rt:routes/rt:route" {		+ "rt:routes/rt:route" {
	when "../../rt:address-family='ipV4' and "		when "../../rt:address-family='ipv4' and "
	+ "../../rt:safi='nlri-unicast'" {		+ "../../rt:safi='nlri-unicast'" {
	description		description
	"This augment is valid only for IPv4 unicast.";		"This augment is valid only for IPv4 unicast.";
	}		}
	description		description
	"This augment defines the content of IPv4 unicast routes.";		"This augment defines the content of IPv4 unicast routes.";
	uses route-content;		uses route-content;
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	skipping to change at page 41, line 11		skipping to change at page 38, line 11
	}		}
	<CODE ENDS>		<CODE ENDS>
	8. IPv6 Unicast Routing YANG Module		8. IPv6 Unicast Routing YANG Module
	RFC Ed.: In this section, replace all occurrences of 'XXXX' with the		RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
	actual RFC number and all occurrences of the revision date below with		actual RFC number and all occurrences of the revision date below with
	the date of RFC publication (and remove this note).		the date of RFC publication (and remove this note).
	<CODE BEGINS> file "ietf-ipv6-unicast-routing@2012-02-20.yang"		<CODE BEGINS> file "ietf-ipv6-unicast-routing@2012-05-24.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 42, line 4		skipping to change at page 39, line 4
	<mailto:david.kessens@nsn.com>		<mailto:david.kessens@nsn.com>
	WG Chair: Juergen Schoenwaelder		WG Chair: Juergen Schoenwaelder
	<mailto:j.schoenwaelder@jacobs-university.de>		<mailto:j.schoenwaelder@jacobs-university.de>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>		<mailto:lhotka@nic.cz>
	";		";
	description		description
	"This module augments the 'ietf-routing' module with YANG		"This YANG module augments the 'ietf-routing' module with basic
	definitions for basic configuration of IPv6 unicast routing.		configuration and operational state data for IPv6 unicast
			routing.
			Every implementation must preconfigure a routing table with the
			name 'main-ipv6-unicast', which is the main routing table for
			IPv6 unicast.
	Copyright (c) 2012 IETF Trust and the persons identified as		Copyright (c) 2012 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).		(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 2012-02-20 {		revision 2012-05-24 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing Configuration";		"RFC XXXX: A YANG Data Model for Routing Configuration";
	}		}
	/* Groupings */		/* Groupings */
	grouping route-content {		grouping route-content {
	description		description
	"Specific parameters of IPv6 unicast routes.";		"Specific parameters of IPv6 unicast routes.";
	uses rt:route-content;
	leaf dest-prefix {		leaf dest-prefix {
	type inet:ipv6-prefix;		type inet:ipv6-prefix;
	description		description
	"IPv6 destination prefix.";		"IPv6 destination prefix.";
	}		}
	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.";
	}		}
	}		}
	/* RPC Methods */		/* RPC Methods */
			augment "/rt:active-route/rt:input/rt:destination-address" {
	augment "/rt:get-route/rt:input/rt:destination-address" {		when "address-family='ipv6' and safi='nlri-unicast'" {
	when "address-family='ipV6' and safi='nlri-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"The 'address' leaf augments the 'rt:destination-address'		"The 'address' leaf augments the 'rt:destination-address'
	parameter of the 'rt:get-route' operation.";		parameter of the 'rt:active-route' operation.";
	leaf address {		leaf address {
	type inet:ipv6-address;		type inet:ipv6-address;
	description		description
	"IPv6 destination address.";		"IPv6 destination address.";
	}		}
	}		}
	augment "/rt:get-route/rt:output/rt:route" {		augment "/rt:active-route/rt:output/rt:route" {
	when "address-family='ipV6' and safi='nlri-unicast'" {		when "address-family='ipv6' and safi='nlri-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"Contents of the reply to 'rt:get-route' operation.";		"Contents of the reply to 'rt:active-route' operation.";
	uses route-content;		uses route-content;
	}		}
	/* Data nodes */		/* Data nodes */
	augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {		augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {
	when "/if:interfaces/if:interface[name=current()/name] "		when "/if:interfaces/if:interface[name=current()/name] "
	+ "/ip:ipv6/ip:enabled='true'" {		+ "/ip:ipv6/ip:enabled='true'" {
	description		description
	"This augment is only valid for router interfaces with		"This augment is only valid for router interfaces with
	skipping to change at page 44, line 34		skipping to change at page 41, line 39
	"The minimum time allowed between sending unsolicited		"The minimum time allowed between sending unsolicited
	multicast Router Advertisements from the interface.		multicast Router Advertisements from the interface.
	Must be no greater than 0.75 * max-rtr-adv-interval.		Must be no greater than 0.75 * max-rtr-adv-interval.
	Its default value is dynamic:		Its default value is dynamic:
	- if max-rtr-adv-interval >= 9 seconds, the default value		- if max-rtr-adv-interval >= 9 seconds, the default value
	is 0.33 * max-rtr-adv-interval;		is 0.33 * max-rtr-adv-interval;
	- otherwise it is max-rtr-adv-interval.		- otherwise it is 0.75 * max-rtr-adv-interval.
	";		";
	}		}
	leaf managed-flag {		leaf managed-flag {
	type boolean;		type boolean;
	default "false";		default "false";
	description		description
	"The boolean value to be placed in the 'Managed address		"The boolean value to be placed in the 'Managed address
	configuration' flag field in the Router Advertisement.";		configuration' flag field in the Router Advertisement.";
	}		}
	leaf other-config-flag {		leaf other-config-flag {
	skipping to change at page 46, line 8		skipping to change at page 43, line 12
	http://www.iana.org/assignments/ip-parameters";		http://www.iana.org/assignments/ip-parameters";
	}		}
	leaf default-lifetime {		leaf default-lifetime {
	type uint16 {		type uint16 {
	range "0..9000";		range "0..9000";
	}		}
	units "seconds";		units "seconds";
	description		description
	"The value to be placed in the Router Lifetime field of		"The value to be placed in the Router Lifetime field of
	Router Advertisements sent from the interface, in seconds.		Router Advertisements sent from the interface, in seconds.
	MUST be either zero or between MaxRtrAdvInterval and 9000		MUST be either zero or between max-rtr-adv-interval and
	seconds. A value of zero indicates that the router is not		9000 seconds. A value of zero indicates that the router is
	to be used as a default router. These limits may be		not to be used as a default router. These limits may be
	overridden by specific documents that describe how IPv6		overridden by specific documents that describe how IPv6
	operates over different link layers.		operates over different link layers.
	The default value is dynamic and should be set to 3 *		The default value is dynamic and should be set to 3 *
	max-rtr-adv-interval.		max-rtr-adv-interval.
	";		";
	}		}
	container prefix-list {		container prefix-list {
	description		description
	"A list of prefixes to be placed in Prefix Information		"A list of prefixes to be placed in Prefix Information
	options in Router Advertisement messages sent from the		options in Router Advertisement messages sent from the
	interface.		interface.
	Default: all prefixes that the router advertises via		By default, all prefixes that the router advertises via
	routing protocols as being on-link for the interface from		routing protocols as being on-link for the interface from
	which the advertisement is sent. The link-local prefix		which the advertisement is sent. The link-local prefix
	should not be included in the list of advertised prefixes.		should not be included in the list of advertised prefixes.
	";		";
	list prefix {		list prefix {
	key "seqno";		key "prefix-spec";
	unique "prefix-spec";
	description		description
	"Advertised prefix entry.";		"Advertised prefix entry.";
	leaf seqno {
	type uint8;
	description
	"Sequential number of the entry.";
	}
	leaf prefix-spec {		leaf prefix-spec {
	type inet:ipv6-prefix;		type inet:ipv6-prefix;
	description		description
	"IPv6 address prefix.";		"IPv6 address prefix.";
	}		}
	leaf valid-lifetime {		choice control-adv-prefixes {
	type uint32;		default "advertise";
	units "seconds";
	default "2592000";
	description		description
	"The value to be placed in the Valid Lifetime in the		"The prefix either may be explicitly removed from the
	Prefix Information option, in seconds. The designated		set of advertised prefixes, or parameters with which
	value of all 1's (0xffffffff) represents infinity.		it is advertised may be specified (default case).";
			leaf no-advertise {
			type empty;
			description
			"The prefix will not be advertised.
	Implementations may allow valid-lifetime to be		This may be used for removing the prefix from the
	specified in two ways:		default set of advertised prefixes.
			";
			}
			case advertise {
			leaf valid-lifetime {
			type uint32;
			units "seconds";
			default "2592000";
			description
			"The value to be placed in the Valid Lifetime in
			the Prefix Information option, in seconds. The
			designated value of all 1's (0xffffffff)
			represents infinity.
	1. a time that decrements in real time, that is, one		Implementations may allow valid-lifetime to be
	that will result in a Lifetime of zero at the		specified in two ways:
	specified time in the future,
	2. a fixed time that stays the same in consecutive		1. a time that decrements in real time, that is,
	advertisements.		one that will result in a lifetime of zero at
	";		the specified time in the future,
	}
	leaf on-link-flag {
	type boolean;
	default "true";
	description
	"The value to be placed in the on-link flag ('L-bit')
	field in the Prefix Information option.";
	}
	leaf preferred-lifetime {
	type uint32;
	units "seconds";
	default "604800";
	description
	"The value to be placed in the Preferred Lifetime in
	the Prefix Information option, in seconds. The
	designated value of all 1's (0xffffffff) represents
	infinity.
	Implementations MAY allow AdvPreferredLifetime to be		2. a fixed time that stays the same in consecutive
	specified in two ways:		advertisements.
			";
			}
			leaf on-link-flag {
			type boolean;
			default "true";
			description
			"The value to be placed in the on-link flag
			('L-bit') field in the Prefix Information
			option.";
			}
			leaf preferred-lifetime {
			type uint32;
			units "seconds";
			default "604800";
			description
			"The value to be placed in the Preferred Lifetime
			in the Prefix Information option, in seconds. The
			designated value of all 1's (0xffffffff)
			represents infinity.
	1. a time that decrements in real time, that is, one		Implementations MAY allow preferred-lifetime to be
	that will result in a Lifetime of zero at a		specified in two ways:
	specified time in the future,
	2. a fixed time that stays the same in consecutive		1. a time that decrements in real time, that is,
	advertisements.		one that will result in a lifetime of zero at a
	";		specified time in the future,
	}
	leaf autonomous-flag {		2. a fixed time that stays the same in consecutive
	type boolean;		advertisements.
	default "true";		";
	description		}
	"The value to be placed in the Autonomous Flag field in		leaf autonomous-flag {
	the Prefix Information option.";		type boolean;
			default "true";
			description
			"The value to be placed in the Autonomous Flag
			field in the Prefix Information option.";
			}
			}
	}		}
	}		}
	}		}
	}		}
	}		}
	augment "/rt:routing/rt:router/rt:routing-protocols/"		augment "/rt:routing/rt:router/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 for IPv6 unicast.";		pseudo-protocol with data specific for IPv6 unicast.";
	container ipv6 {		container ipv6 {
	description		description
	skipping to change at page 48, line 23		skipping to change at page 45, line 40
	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 "seqno";		key "seqno";
	ordered-by "user";		ordered-by "user";
	description		description
	"A user-ordered list of static routes.";		"A user-ordered list of static routes.";
	leaf seqno {		leaf seqno {
	type uint16;		type uint32 {
			range "1..max";
			}
	description		description
	"Sequential number of the route.";		"Sequential number of the route.";
	}		}
	leaf description {		leaf description {
	type string;		type string;
	description		description
	"Textual description of the route.";		"Textual description of the route.";
	}		}
	uses route-content;		uses rt:route-content;
			uses route-content {
			refine "dest-prefix" {
			mandatory "true";
			}
			}
	}		}
	}		}
	}		}
	augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"		augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
	+ "rt:routes/rt:route" {		+ "rt:routes/rt:route" {
	when "../../rt:address-family='ipV6' and "		when "../../rt:address-family='ipv6' and "
	+ "../../rt:safi='nlri-unicast'" {		+ "../../rt:safi='nlri-unicast'" {
	description		description
	"This augment is valid only for IPv6 unicast.";		"This augment is valid only for IPv6 unicast.";
	}		}
	description		description
	"This augment defines the content of IPv6 unicast routes.";		"This augment defines the content of IPv6 unicast routes.";
	uses route-content;		uses route-content;
	}		}
	}		}
	skipping to change at page 49, line 37		skipping to change at page 47, line 37
	----------------------------------------------------------		----------------------------------------------------------
	----------------------------------------------------------		----------------------------------------------------------
	URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing		URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	----------------------------------------------------------		----------------------------------------------------------
	----------------------------------------------------------
	URI: urn:ietf:params:xml:ns:yang:iana-afn-safi
	Registrant Contact: IANA.
	XML: N/A, the requested URI is an XML namespace.
	----------------------------------------------------------
	This document registers the following YANG modules in the YANG Module		This document registers the following YANG modules in the YANG Module
	Names registry [RFC6020]:		Names registry [RFC6020]:
	-------------------------------------------------------------------		-------------------------------------------------------------------
	name: ietf-routing		name: ietf-routing
	namespace: urn:ietf:params:xml:ns:yang:ietf-routing		namespace: urn:ietf:params:xml:ns:yang:ietf-routing
	prefix: rt		prefix: rt
	reference: RFC XXXX		reference: RFC XXXX
	-------------------------------------------------------------------		-------------------------------------------------------------------
	skipping to change at page 50, line 26		skipping to change at page 49, line 5
	reference: RFC XXXX		reference: RFC XXXX
	-------------------------------------------------------------------		-------------------------------------------------------------------
	-------------------------------------------------------------------		-------------------------------------------------------------------
	name: ietf-ipv6-unicast-routing		name: 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
	reference: RFC XXXX		reference: RFC XXXX
	-------------------------------------------------------------------		-------------------------------------------------------------------
	-------------------------------------------------------------------
	name: iana-afn-safi
	namespace: urn:ietf:params:xml:ns:yang:iana-afn-safi
	prefix: ianaaf
	reference: RFC XXXX
	-------------------------------------------------------------------
	10. Security Considerations		10. Security Considerations
	The YANG modules defined in this document are designed to be accessed		The YANG modules defined in this document are designed to be accessed
	via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the		via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
	secure transport layer and the mandatory-to-implement secure		secure transport layer and the mandatory-to-implement secure
	transport is SSH [RFC6242].		transport is SSH [RFC6242].
	A number of data nodes defined in the YANG modules are writable/		A number of data nodes defined in the YANG modules are writable/
	creatable/deletable (i.e., "config true" in YANG terms, which is the		creatable/deletable (i.e., "config true" in YANG terms, which is the
	default). These data nodes may be considered sensitive or vulnerable		default). These data nodes may be considered sensitive or vulnerable
	in some network environments. Write operations to these data nodes,		in some network environments. Write operations to these data nodes,
	such as "edit-config", can have negative effects on the network if		such as "edit-config", can have negative effects on the network if
	the operations are not properly protected.		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:
	/rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a		/rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a
	logical interface to a router instance and may also specify		network layer interface to a router instance and may also specify
	interface parameters related to routing.		interface parameters related to routing.
	/rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This		/rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This
	list specifies the routing protocols configured on a device.		list specifies the routing protocols configured on a device.
	/rt:routing/rt:router/rt:route-filters/rt:route-filter This list		/rt:routing/rt:router/rt:route-filters/rt:route-filter This list
	specifies the configured route filters which represent the		specifies the configured route filters which represent the
	administrative policies for redistributing and modifying routing		administrative policies for redistributing and modifying routing
	information.		information.
	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.
	11. Acknowledgments		11. Acknowledgments
	The author wishes to thank Martin Bjorklund, Joel Halpern, Tom Petch		The author wishes to thank Martin Bjorklund, Joel Halpern, Thomas
	and Juergen Schoenwaelder for their helpful comments and suggestions.		Morin, Tom Petch, Juergen Schoenwaelder, Dave Thaler and Yi Yang for
			their helpful comments and suggestions.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[IANA-AFN]		[IANA-IF-AF]
	IANA, "Address Family Numbers.", January 2011.		Bjorklund, M., "IANA Interface Type and Address Family
			YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in
	[IANA-SAFI]		progress), April 2012.
	IANA, "Subsequent Address Family Identifiers (SAFI)
	Parameters.", March 2011.
	[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.
	skipping to change at page 53, line 38		skipping to change at page 51, line 36
	September 2010.		September 2010.
	[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6021, September 2010.		RFC 6021, September 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, "NETCONF Configuration Protocol", RFC 6241,
	June 2011.		June 2011.
	[YANG-IF] Bjorklund, M., "A YANG Data Model for Interface		[YANG-IF] Bjorklund, M., "A YANG Data Model for Interface
	Configuration", draft-ietf-netmod-interfaces-cfg-03 (work		Configuration", draft-ietf-netmod-interfaces-cfg-04 (work
	in progress), February 2012.		in progress), April 2012.
	[YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration",		[YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration",
	draft-ietf-netmod-ip-cfg-02 (work in progress),		draft-ietf-netmod-ip-cfg-03 (work in progress),
	February 2012.		April 2012.
	12.2. Informative References		12.2. Informative References
	[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.
	Appendix A. Example: Adding a New Routing Protocol		Appendix A. 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, we do not follow all the guidelines
	specified in [RFC6087]. See also Section 4.4.1.		specified in [RFC6087]. See also Section 4.4.2.
	<CODE BEGINS> file "example-rip@2012-02-20.yang"		<CODE BEGINS> file "example-rip@2012-05-24.yang"
	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 55, line 18		skipping to change at page 53, line 18
	+ "rt:type='rip:rip'" {		+ "rt:type='rip:rip'" {
	description		description
	"This augment is only valid if the source protocol from which		"This augment is only valid if the source protocol from which
	the route originated is RIP.";		the route originated is RIP.";
	}		}
	description		description
	"RIP-specific route components.";		"RIP-specific route components.";
	uses route-content;		uses route-content;
	}		}
	augment "/rt:get-route/rt:output/rt:route" {		augment "/rt:active-route/rt:output/rt:route" {
	description		description
	"Add RIP-specific route content.";		"Add RIP-specific route content.";
	uses route-content;		uses route-content;
	}		}
	augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {		augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {
	when "../../rt:routing-protocols/rt:routing-protocol/rt:type = "		when "../../rt:routing-protocols/rt:routing-protocol/rt:type = "
	+ "'rip:rip'";		+ "'rip:rip'";
	container rip {		container rip {
	description		description
	skipping to change at page 57, line 13		skipping to change at page 55, line 13
	<CODE ENDS>		<CODE ENDS>
	Appendix B. Example: Reply to the NETCONF <get> Message		Appendix B. Example: Reply to the NETCONF <get> Message
	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 [YANG-IF],		o ietf-interfaces [YANG-IF],
	o ex-ethernet [YANG-IF],
	o ietf-ip [YANG-IP],		o ietf-ip [YANG-IP],
	o ietf-routing (Section 6),		o ietf-routing (Section 6),
	o ietf-ipv4-unicast-routing (Section 7),		o ietf-ipv4-unicast-routing (Section 7),
	o ietf-ipv6-unicast-routing (Section 8).		o ietf-ipv6-unicast-routing (Section 8).
	We assume a simple network setup as shown in Figure 3: router "A"		We assume a simple network setup as shown in Figure 3: 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.
	skipping to change at page 58, line 12		skipping to change at page 56, line 9
	Router "A" then could send the following XML document as its reply to		Router "A" then could send the following XML document as its reply to
	the NETCONF <get> message:		the NETCONF <get> message:
	<?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:eth="http://example.com/ethernet"
	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>ethernetCsmacd</if:type>		<if:type>ethernetCsmacd</if:type>
	<if:location>05:00.0</if:location>		<if:location>05:00.0</if:location>
	<ip:ipv4>		<ip:ipv4>
	<ip:address>		<ip:address>
	skipping to change at page 59, line 22		skipping to change at page 57, line 20
	<rt:interfaces>		<rt:interfaces>
	<rt:interface>		<rt:interface>
	<rt:name>eth0</rt:name>		<rt:name>eth0</rt:name>
	</rt:interface>		</rt:interface>
	<rt:interface>		<rt:interface>
	<rt:name>eth1</rt:name>		<rt:name>eth1</rt:name>
	<v6ur:ipv6-router-advertisements>		<v6ur:ipv6-router-advertisements>
	<v6ur:send-advertisements>true</v6ur:send-advertisements>		<v6ur:send-advertisements>true</v6ur:send-advertisements>
	<v6ur:prefix-list>		<v6ur:prefix-list>
	<v6ur:prefix>		<v6ur:prefix>
	<v6ur:seqno>1</v6ur:seqno>
	<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec>		<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec>
	</v6ur:prefix>		</v6ur:prefix>
	</v6ur:prefix-list>		</v6ur:prefix-list>
	</v6ur:ipv6-router-advertisements>		</v6ur:ipv6-router-advertisements>
	</rt:interface>		</rt:interface>
	</rt:interfaces>		</rt:interfaces>
	<rt:routing-protocols>		<rt:routing-protocols>
	<rt:routing-protocol>		<rt:routing-protocol>
	<rt:name>direct</rt:name>		<rt:name>direct</rt:name>
	<rt:type>rt:direct</rt:type>		<rt:type>rt:direct</rt:type>
	skipping to change at page 60, line 10		skipping to change at page 58, line 6
	<v6ur:ipv6>		<v6ur:ipv6>
	<v6ur:route>		<v6ur:route>
	<v6ur:seqno>1</v6ur:seqno>		<v6ur:seqno>1</v6ur:seqno>
	<v6ur:dest-prefix>::/0</v6ur:dest-prefix>		<v6ur:dest-prefix>::/0</v6ur:dest-prefix>
	<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>		<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
	</v6ur:route>		</v6ur:route>
	</v6ur:ipv6>		</v6ur:ipv6>
	</rt:static-routes>		</rt:static-routes>
	<rt:connected-routing-tables>		<rt:connected-routing-tables>
	<rt:routing-table>		<rt:routing-table>
	<rt:name>ipv4-unicast-main</rt:name>		<rt:name>main-ipv4-unicast</rt:name>
	</rt:routing-table>		</rt:routing-table>
	<rt:routing-table>		<rt:routing-table>
	<rt:name>ipv6-unicast-main</rt:name>		<rt:name>main-ipv6-unicast</rt:name>
	</rt:routing-table>		</rt:routing-table>
	</rt:connected-routing-tables>		</rt:connected-routing-tables>
	</rt:routing-protocol>		</rt:routing-protocol>
	</rt:routing-protocols>		</rt:routing-protocols>
	<rt:routing-tables>		<rt:routing-tables>
	<rt:routing-table>		<rt:routing-table>
	<rt:name>ipv4-unicast-fib</rt:name>		<rt:name>main-ipv4-unicast</rt:name>
	<rt:routes>		<rt:routes>
	<rt:route>		<rt:route>
	<v4ur:dest-prefix>192.0.2.1/24</v4ur:dest-prefix>		<v4ur:dest-prefix>192.0.2.1/24</v4ur:dest-prefix>
	<v4ur:outgoing-interface>eth0</v4ur:outgoing-interface>		<rt:outgoing-interface>eth0</rt:outgoing-interface>
	<rt:source-protocol>direct</rt:source-protocol>		<rt:source-protocol>direct</rt:source-protocol>
	<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified>		<rt:age>3512</rt:age>
	</rt:route>		</rt:route>
	<rt:route>		<rt:route>
	<v4ur:dest-prefix>198.51.100.0/24</v4ur:dest-prefix>		<v4ur:dest-prefix>198.51.100.0/24</v4ur:dest-prefix>
	<v4ur:outgoing-interface>eth1</v4ur:outgoing-interface>		<rt:outgoing-interface>eth1</rt:outgoing-interface>
	<rt:source-protocol>direct</rt:source-protocol>		<rt:source-protocol>direct</rt:source-protocol>
	<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified>		<rt:age>3512</rt:age>
	</rt:route>		</rt:route>
	<rt:route>		<rt:route>
	<v4ur:dest-prefix>0.0.0.0/0</v4ur:dest-prefix>		<v4ur:dest-prefix>0.0.0.0/0</v4ur:dest-prefix>
	<v4ur:next-hop>192.0.2.2</v4ur:next-hop>
	<rt:source-protocol>st0</rt:source-protocol>		<rt:source-protocol>st0</rt:source-protocol>
	<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified>		<v4ur:next-hop>192.0.2.2</v4ur:next-hop>
			<rt:age>2551</rt:age>
	</rt:route>		</rt:route>
	</rt:routes>		</rt:routes>
	</rt:routing-table>		</rt:routing-table>
	<rt:routing-table>		<rt:routing-table>
	<rt:name>ipv6-unicast-fib</rt:name>		<rt:name>main-ipv6-unicast</rt:name>
	<rt:address-family>ipV6</rt:address-family>		<rt:address-family>ipv6</rt:address-family>
	<rt:safi>nlri-unicast</rt:safi>		<rt:safi>nlri-unicast</rt:safi>
	<rt:routes>		<rt:routes>
	<rt:route>		<rt:route>
	<v6ur:dest-prefix>2001:db8:0:1::/64</v6ur:dest-prefix>		<v6ur:dest-prefix>2001:db8:0:1::/64</v6ur:dest-prefix>
	<v6ur:outgoing-interface>eth0</v6ur:outgoing-interface>		<rt:outgoing-interface>eth0</rt:outgoing-interface>
	<rt:source-protocol>direct</rt:source-protocol>		<rt:source-protocol>direct</rt:source-protocol>
	<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified>		<rt:age>3513</rt:age>
	</rt:route>		</rt:route>
	<rt:route>		<rt:route>
	<v6ur:dest-prefix>2001:db8:0:2::/64</v6ur:dest-prefix>		<v6ur:dest-prefix>2001:db8:0:2::/64</v6ur:dest-prefix>
	<v6ur:outgoing-interface>eth1</v6ur:outgoing-interface>		<rt:outgoing-interface>eth1</rt:outgoing-interface>
	<rt:source-protocol>direct</rt:source-protocol>		<rt:source-protocol>direct</rt:source-protocol>
	<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified>		<rt:age>3513</rt:age>
	</rt:route>
	<rt:route>
	<v6ur:dest-prefix>::/0</v6ur:dest-prefix>
	<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
	<rt:source-protocol>st0</rt:source-protocol>
	<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified>
	</rt:route>
	</rt:routes>
	</rt:routing-table>
	<rt:routing-table>
	<rt:name>ipv4-unicast-main</rt:name>
	<rt:recipient-routing-tables>
	<rt:recipient-name>ipv4-unicast-fib</rt:recipient-name>
	</rt:recipient-routing-tables>
	<rt:routes>
	<rt:route>
	<v4ur:dest-prefix>0.0.0.0/0</v4ur:dest-prefix>
	<rt:source-protocol>st0</rt:source-protocol>
	<v4ur:next-hop>192.0.2.2</v4ur:next-hop>
	<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified>
	</rt:route>		</rt:route>
	</rt:routes>
	</rt:routing-table>
	<rt:routing-table>
	<rt:name>ipv6-unicast-main</rt:name>
	<rt:address-family>ipV6</rt:address-family>
	<rt:safi>nlri-unicast</rt:safi>
	<rt:recipient-routing-tables>
	<rt:recipient-name>ipv6-unicast-fib</rt:recipient-name>
	</rt:recipient-routing-tables>
	<rt:routes>
	<rt:route>		<rt:route>
	<v6ur:dest-prefix>::/0</v6ur:dest-prefix>		<v6ur:dest-prefix>::/0</v6ur:dest-prefix>
	<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>		<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
	<rt:source-protocol>st0</rt:source-protocol>		<rt:source-protocol>st0</rt:source-protocol>
	<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified>		<rt:age>2550</rt:age>
	</rt:route>		</rt:route>
	</rt:routes>		</rt:routes>
	</rt:routing-table>		</rt:routing-table>
	</rt:routing-tables>		</rt:routing-tables>
	</rt:router>		</rt:router>
	</rt:routing>		</rt:routing>
	</data>		</data>
	</rpc-reply>		</rpc-reply>
	Appendix C. Change Log		Appendix C. Change Log
	RFC Editor: remove this section upon publication as an RFC.		RFC Editor: remove this section upon publication as an RFC.
	C.1. Changes Between Versions -01 and -02		C.1. Changes Between Versions -02 and -03
			o Module "iana-afn-safi" moved to I-D "iana-if-type".
			o Removed forwarding table.
			o RPC "get-route" changed to "active-route". Its output is a list
			of routes (for multi-path routing).
			o New RPC "route-count".
			o For both RPCs, specification of negative responses was added.
			o Relaxed separation of router instances.
			o Assignment of interfaces to router instances needn't be disjoint.
			o Route filters are now global.
			o Added "allow-all-route-filter" for symmetry.
			o Added Section 5 about interactions with "ietf-interfaces" and
			"ietf-ip".
			o Added "router-id" leaf.
			o Specified the names for IPv4/IPv6 unicast main routing tables.
			o Route parameter "last-modified" changed to "age".
			o Added container "recipient-routing-tables".
			C.2. 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 B now uses IP addresses from blocks		o The example in Appendix B now uses IP addresses from blocks
	reserved for documentation.		reserved for documentation.
	o Direct routes appear by default in the FIB table.		o Direct routes appear by default in the FIB table.
	o Logical 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.
	o The "when" statement is only used with "augment", "must" is used		o The "when" statement is only used with "augment", "must" is used
	elsewhere.		elsewhere.
	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.
	C.2. Changes Between Versions -00 and -01		C.3. 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. 207 change blocks.
	913 lines changed or deleted		773 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/