rfc9403.original.xml		rfc9403.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
			<!-- draft submitted in xml v3 -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc strict="no" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
	<?rfc toc="yes" ?>		std" consensus="true" ipr="trust200902" docName="draft-ietf-rtgwg-yang-rib-exten
	<?rfc symrefs="yes" ?>		d-24" number="9403" obsoletes="" updates="" xml:lang="en" tocInclude="true" symR
	<?rfc sortrefs="yes"?>		efs="true" sortRefs="true" version="3">
	<?rfc rfcedstyle="yes" ?>
	<?rfc subcompact="no" ?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
	docName="draft-ietf-rtgwg-yang-rib-extend-22" obsoletes="" updates=""
	submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRe
	fs="true"
	version="3" consensus="true">
	<!-- xml2rfc v2v3 conversion 3.17.1 -->		<!-- xml2rfc v2v3 conversion 3.17.1 -->
	<front>		<front>
	<title abbrev="YANG RIB-EXT">RIB Extension YANG Data Model</title>		<title abbrev="YANG RIB-EXT">A YANG Data Model for RIB Extensions</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-yang-rib-extend-22
	"/>		<seriesInfo name="RFC" value="9403"/>
	<author initials="A." surname="Lindem" fullname="Acee Lindem">		<author initials="A." surname="Lindem" fullname="Acee Lindem">
	<organization>LabN Consulting LLC</organization>		<organization>LabN Consulting, L.L.C.</organization>
	<address>		<address>
	<postal>		<postal>
	<street>301 Midenhall Way</street>		<street>301 Midenhall Way</street>
	<city>Cary</city>		<city>Cary</city>
	<region>NC</region>		<region>NC</region>
	<country>USA</country>		<country>United States of America</country>
	<code>27513</code>		<code>27513</code>
	</postal>		</postal>
	<email>acee.ietf@gmail.com</email>		<email>acee.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Yingzhen Qu" initials="Y" surname="Qu">		<author fullname="Yingzhen Qu" initials="Y" surname="Qu">
	<organization>Futurewei</organization>		<organization>Futurewei Technologies</organization>
	<address>		<address>
	<postal>		<postal>
	<street>2330 Central Expressway</street>		<street>2330 Central Expressway</street>
	<city>Santa Clara</city>		<city>Santa Clara</city>
	<region>CA</region>		<region>CA</region>
	<code>95050</code>		<code>95050</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<phone/>
	<email>yingzhen.qu@futurewei.com</email>		<email>yingzhen.qu@futurewei.com</email>
	</address>		</address>
	</author>		</author>
	<date/>		<date year="2023" month="November" />
			<area>rtg</area>
			<workgroup>rtgwg</workgroup>
			<keyword>configuration</keyword>
			<keyword>IPv6 Router Advertisements</keyword>
			<keyword>NETCONF</keyword>
			<keyword>RESTCONF</keyword>
			<keyword>YANG</keyword>
			<keyword>Routing</keyword>
			<keyword>RIB</keyword>
	<abstract>		<abstract>
	<t>A Routing Information Base (RIB) is a list of routes and their		<t>A Routing Information Base (RIB) is a list of routes and their
	corresponding administrative data and operational state.</t>		corresponding administrative data and operational state.</t>
	<t>RFC 8349 defines the		<t>RFC 8349 defines the
	basic building blocks for the RIB data model, and this model augments it to support		basic building blocks for the RIB data model, and this model augments it to support
	multiple next-hops (aka, paths) for each route as well as additional		multiple next hops (aka paths) for each route as well as additional
	attributes.</t>		attributes.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>This document defines a YANG <xref target="RFC7950" format="default"/>		<t>This document defines a YANG data model <xref target="RFC7950" format="
	data model which extends the RIB data model defined in the ietf-routing YANG m		default"/>
	odule		that extends the RIB data model defined in the ietf-routing YANG module
	<xref target="RFC8349" format="default"/> with more route attributes.</t>		<xref target="RFC8349" format="default"/> with more route attributes.</t>
	<t>A RIB is a collection of routes with attributes controlled and		<t>A RIB is a collection of routes with attributes controlled and
	manipulated by control-plane protocols. Each RIB contains only routes		manipulated by control plane protocols. Each RIB contains only routes
	of one address family <xref target="RFC8349" format="default"/>. Within a prot ocol,		of one address family <xref target="RFC8349" format="default"/>. Within a prot ocol,
	routes are selected based on the metrics in use by that protocol, and		routes are selected based on the metrics in use by that protocol, and
	the protocol installs the routes to RIB. The RIB selects the preferred or active		the protocol installs the routes to the RIB. The RIB selects the preferred or ac
	route by comparing the route-preference (aka, administrative distance) of		tive
	the candidate routes installed different protocols.</t>		route by comparing the route preference (aka administrative distance) of
			the candidate routes installed by different protocols.</t>
	<t>The module defined in this document extends the RIB to support more		<t>The module defined in this document extends the RIB to support more
	route attributes, such as multiple next-hops, route metrics, and		route attributes, such as multiple next hops, route metrics, and
	administrative tags.</t>		administrative tags.</t>
	<t> The YANG modules in this document conform to the Network Management		<t> The YANG modules defined and discussed in this document conform to the
	Datastore Architecture (NMDA) [RFC8342].</t>		Network Management
			Datastore Architecture (NMDA) <xref target="RFC8342"/>.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Terminology and Notation</name>		<name>Terminology and Notation</name>
	<t>The following terms are defined in <xref target="RFC8342" format="defau lt"/>:		<t>The following terms are defined in <xref target="RFC8342" format="defau lt"/>:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>configuration</li>		<li>configuration</li>
	<li>system state</li>		<li>system state</li>
	<li>operational state</li>		<li>operational state</li>
	</ul>		</ul>
	skipping to change at line 102 ¶		skipping to change at line 108 ¶
	<li>augment</li>		<li>augment</li>
	<li>container</li>		<li>container</li>
	<li>container with presence</li>		<li>container with presence</li>
	<li>data model</li>		<li>data model</li>
	<li>data node</li>		<li>data node</li>
	<li>leaf</li>		<li>leaf</li>
	<li>list</li>		<li>list</li>
	<li>mandatory node</li>		<li>mandatory node</li>
	<li>module</li>		<li>module</li>
	<li>schema tree</li>		<li>schema tree</li>
	<li>RPC (Remote Procedure Call) operation</li>
	</ul>		</ul>
	<t>The following terms are defined in <xref target="RFC8349" format="defau lt"/> Section 5.2:		<t>The following term is defined in <xref target="RFC8349" sectionFormat=" comma" section="5.2"/>:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>RIB</li>		<li>RIB</li>
	</ul>		</ul>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Tree Diagrams</name>		<name>Tree Diagrams</name>
	<t>Tree diagrams used in this document follow the notation defined in < xref target="RFC8340" format="default"/>.</t>		<t>Tree diagrams used in this document follow the notation defined in < xref target="RFC8340" format="default"/>.</t>
	</section>		</section>
	<section anchor="sec.prefixes" numbered="true" toc="default">		<section anchor="sec.prefixes" numbered="true" toc="default">
	<name>Prefixes in Data Node Names</name>		<name>Prefixes in Data Node Names</name>
	<t>In this document, names of data nodes, actions, and other		<t>In this document, names of data nodes, actions, and other
	data model objects are often used without a prefix, as long as		data model objects are often used without a prefix, as long as
	it is clear from the context in which YANG module each name is		it is clear from the context in which YANG module each name is
	defined. Otherwise, names are prefixed using the standard prefix		defined. Otherwise, names are prefixed using the standard prefix
	associated with the corresponding YANG module, as shown in <xref target= "tab.prefixes" format="default"/>.</t>		associated with the corresponding YANG module, as shown in <xref target= "tab.prefixes" format="default"/>.</t>
	<table anchor="tab.prefixes" align="center">		<table anchor="tab.prefixes" align="center">
	<name>Prefixes and Corresponding YANG Modules</name>		<name>Prefixes and Corresponding YANG Modules</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Prefix</th>		<th align="left">Prefix</th>
	<th align="left">YANG module</th>		<th align="left">YANG Module</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">if</td>		<td align="left">if</td>
	<td align="left">ietf-interfaces</td>		<td align="left">ietf-interfaces</td>
	<td align="left">		<td align="left">
	<xref target="RFC8343" format="default"/></td>		<xref target="RFC8343" format="default"/></td>
	</tr>		</tr>
	skipping to change at line 160 ¶		skipping to change at line 165 ¶
	<td align="left">ietf-ipv6-unicast-routing</td>		<td align="left">ietf-ipv6-unicast-routing</td>
	<td align="left">		<td align="left">
	<xref target="RFC8349" format="default"/></td>		<xref target="RFC8349" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">inet</td>		<td align="left">inet</td>
	<td align="left">ietf-inet-types</td>		<td align="left">ietf-inet-types</td>
	<td align="left">		<td align="left">
	<xref target="RFC6991" format="default"/></td>		<xref target="RFC6991" format="default"/></td>
	</tr>		</tr>
			<tr>
			<td align="left">ospf</td>
			<td align="left">ietf-ospf</td>
			<td align="left">
			<xref target="RFC9129" format="default"/></td>
			</tr>
			<tr>
			<td align="left">isis</td>
			<td align="left">ietf-isis</td>
			<td align="left">
			<xref target="RFC9130" format="default"/></td>
			</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Design of the Model</name>		<name>Design of the Model</name>
	<t>The YANG module defined in this document augments the ietf-routing YANG		<t>The YANG module defined in this document augments the ietf-routing,
	modules		ietf-ipv4-unicast-routing, and ietf-ipv6-unicast-routing YANG modules
	defined in <xref target="RFC8349" format="default"/>, which provide a basis		defined in <xref target="RFC8349" format="default"/>, which provide a basis
	for routing system data model development. Together with YANG modules defined in		for routing system data model development. Together with the ietf-routing YANG m
	<xref target="RFC8349" format="default"/>, a generic RIB YANG model is defined t		odule and other YANG modules defined in
	o		<xref target="RFC8349" format="default"/>, a generic RIB YANG data model is defi
	implement and monitor a RIB.</t>		ned herein to implement and monitor a RIB.
			</t>
	<t>The modules in <xref target="RFC8349" format="default"/> also define th e basic		<t>The modules in <xref target="RFC8349" format="default"/> also define th e basic
	configuration and operational state for both IPv4 and IPv6 static routes. This document		configuration and operational state for both IPv4 and IPv6 static routes. This document
	provides augmentations for static routes to support multiple next-hops		provides augmentations for static routes to support multiple next hops
	and more next-hop attributes.		and more next-hop attributes.
	</t>		</t>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Tags and Preference</name>		<name>Tags and Preferences</name>
	<t>Individual route tags are supported at both the route and next-hop le vel.		<t>Individual route tags are supported at both the route and next-hop le vel.
	A preference per next-hop is also supported for selection of the most preferred		A preference per next hop is also supported for selection of the most preferred
	reachable static route.</t>		reachable static route.</t>
	<t>The following tree snapshot shows tag and preference which augment		<t>The following tree snapshot shows tag and preference entries that aug
	static IPv4 unicast routes and IPv6 unicast routes next-hop.</t>		ment
	<artwork name="" type="" align="left" alt=""><![CDATA[		static IPv4 unicast route and IPv6 unicast route next hops.</t>
			<sourcecode type="yangtree"><![CDATA[
	augment /rt:routing/rt:control-plane-protocols		augment /rt:routing/rt:control-plane-protocols
	/rt:control-plane-protocol/rt:static-routes/v4ur:ipv4		/rt:control-plane-protocol/rt:static-routes/v4ur:ipv4
	/v4ur:route/v4ur:next-hop/v4ur:next-hop-options		/v4ur:route/v4ur:next-hop/v4ur:next-hop-options
	/v4ur:simple-next-hop:		/v4ur:simple-next-hop:
	+--rw preference? uint32		+--rw preference? uint32
	+--rw tag? uint32		+--rw tag? uint32
	augment /rt:routing/rt:control-plane-protocols		augment /rt:routing/rt:control-plane-protocols
	/rt:control-plane-protocol/rt:static-routes/v4ur:ipv4		/rt:control-plane-protocol/rt:static-routes/v4ur:ipv4
	/v4ur:route/v4ur:next-hop/v4ur:next-hop-options		/v4ur:route/v4ur:next-hop/v4ur:next-hop-options
	/v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop:		/v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop:
	skipping to change at line 208 ¶		skipping to change at line 226 ¶
	/v6ur:route/v6ur:next-hop/v6ur:next-hop-options		/v6ur:route/v6ur:next-hop/v6ur:next-hop-options
	/v6ur:simple-next-hop:		/v6ur:simple-next-hop:
	+--rw preference? uint32		+--rw preference? uint32
	+--rw tag? uint32		+--rw tag? uint32
	augment /rt:routing/rt:control-plane-protocols		augment /rt:routing/rt:control-plane-protocols
	/rt:control-plane-protocol/rt:static-routes/v6ur:ipv6		/rt:control-plane-protocol/rt:static-routes/v6ur:ipv6
	/v6ur:route/v6ur:next-hop/v6ur:next-hop-options		/v6ur:route/v6ur:next-hop/v6ur:next-hop-options
	/v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop:		/v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop:
	+--rw preference? uint32		+--rw preference? uint32
	+--rw tag? uint32		+--rw tag? uint32
	]]></artwork>		augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
			+--ro metric? uint32
			+--ro tag* uint32
			+--ro application-tag? uint32
			]]></sourcecode>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Repair Path</name>		<name>Repair Path</name>
	<t>The IP Fast Reroute (IPFRR) calculation by routing protocol		<t>The IP Fast Reroute (IPFRR) calculation by routing protocol
	pre-computes repair paths <xref target="RFC5714" format="default"/>, and the repair		precomputes repair paths <xref target="RFC5714" format="default"/>, and the repair
	paths are installed in the RIB.</t>		paths are installed in the RIB.</t>
	<t>Each route next-hop in the RIB is augmented with a repair path,		<t>Each route next hop in the RIB is augmented with a repair path
	and is shown in the following tree snapshot.</t>		and is shown in the following tree snapshot.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="yangtree"><![CDATA[
	augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route		augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
	/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:		/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
	+--ro repair-path		+--ro repair-path
	+--ro outgoing-interface? if:interface-state-ref		+--ro outgoing-interface? if:interface-state-ref
	+--ro next-hop-address? inet:ip-address-no-zone		+--ro next-hop-address? inet:ip-address-no-zone
	+--ro metric? uint32		+--ro metric? uint32
	augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route		augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
	/rt:next-hop/rt:next-hop-options/rt:next-hop-list		/rt:next-hop/rt:next-hop-options/rt:next-hop-list
	/rt:next-hop-list/rt:next-hop:		/rt:next-hop-list/rt:next-hop:
	+--ro repair-path		+--ro repair-path
	+--ro outgoing-interface? if:interface-state-ref		+--ro outgoing-interface? if:interface-state-ref
	+--ro next-hop-address? inet:ip-address-no-zone		+--ro next-hop-address? inet:ip-address-no-zone
	+--ro metric? uint32		+--ro metric? uint32
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="rib.tree" numbered="true" toc="default">		<section anchor="rib.tree" numbered="true" toc="default">
	<name>RIB Model Tree</name>		<name>RIB Model Tree</name>
	<t> The ietf-routing.yang tree with the augmentations herein is		<t> The ietf-routing.yang tree with the augmentations herein is
	included in <xref target="full-tree" format="default"/>. The meaning of the sy mbols		included in <xref target="full-tree" format="default"/>. The meanings of the s ymbols
	can be found in <xref target="RFC8340" format="default"/>.</t>		can be found in <xref target="RFC8340" format="default"/>.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>RIB Extension YANG Model</name>		<name>RIB Extension YANG Module</name>
	<sourcecode name="ietf-rib-extension@2023-06-06.yang" type="" markers="tru
	e"><![CDATA[		<t>This YANG module references <xref target="RFC6991"/>,
			<xref target="RFC8343"/>, <xref target="RFC8349"/>,
			<xref target="RFC9129"/>, <xref target="RFC9130"/>, and
			<xref target="RFC5714"/>.</t>
			<sourcecode name="ietf-rib-extension@2023-11-01.yang" type="yang" markers=
			"true"><![CDATA[
	module ietf-rib-extension {		module ietf-rib-extension {
	yang-version "1.1";		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-rib-extension";		namespace "urn:ietf:params:xml:ns:yang:ietf-rib-extension";
	prefix rib-ext;		prefix rib-ext;
	import ietf-inet-types {		import ietf-inet-types {
	prefix "inet";		prefix inet;
	reference "RFC 6991: Common YANG Data Types";		reference
			"RFC 6991: Common YANG Data Types";
	}		}
	import ietf-interfaces {		import ietf-interfaces {
	prefix "if";		prefix if;
	reference "RFC 8343: A YANG Data Model for Interface		reference
	Management (NMDA Version)";		"RFC 8343: A YANG Data Model for Interface
			Management";
	}		}
	import ietf-routing {		import ietf-routing {
	prefix "rt";		prefix rt;
	reference "RFC 8349: A YANG Data Model for Routing		reference
	Management (NMDA Version)";		"RFC 8349: A YANG Data Model for Routing
			Management (NMDA Version)";
	}		}
	import ietf-ipv4-unicast-routing {		import ietf-ipv4-unicast-routing {
	prefix "v4ur";		prefix v4ur;
	reference "RFC 8349: A YANG Data Model for Routing		reference
	Management (NMDA Version)";		"RFC 8349: A YANG Data Model for Routing
			Management (NMDA Version)";
	}		}
	import ietf-ipv6-unicast-routing {		import ietf-ipv6-unicast-routing {
	prefix "v6ur";		prefix v6ur;
	reference "RFC 8349: A YANG Data Model for Routing		reference
	Management (NMDA Version)";		"RFC 8349: A YANG Data Model for Routing
			Management (NMDA Version)";
	}		}
	organization		import ietf-ospf {
	"IETF RTGWG - Routing Working Group";		prefix ospf;
			reference "RFC 9129: YANG Data Model for the OSPF Protocol";
			}
			import ietf-isis {
			prefix isis;
			reference "RFC 9130: YANG Data Model for the IS-IS Protocol";
			}
			organization
			"IETF RTGWG (Routing Area Working Group)";
	contact		contact
	"WG Web: <https://datatracker.ietf.org/group/rtgwg/>		"WG Web: <https://datatracker.ietf.org/wg/rtgwg/>
	WG List: <mailto:rtgwg@ietf.org>		WG List: <mailto:rtgwg@ietf.org>
	Author: Acee Lindem		Author: Acee Lindem
	<mailto:acee.ietf@gmail.com>		<mailto:acee.ietf@gmail.com>
	Author: Yingzhen Qu		Author: Yingzhen Qu
	<mailto:yingzhen.qu@futurewei.com>";		<mailto:yingzhen.qu@futurewei.com>";
	description		description
	"This YANG module extends the RIB defined in the ietf-routing		"This YANG module extends the RIB defined in the ietf-routing
	YANG module with additional route attributes.		YANG module with additional route attributes.
	This YANG module conforms to the Network Management		This YANG module conforms to the Network Management
	Datastore Architecture (NDMA) as described in RFC 8342.		Datastore Architecture (NMDA) as described in RFC 8342.
	Copyright (c) 2023 IETF Trust and the persons identified as		Copyright (c) 2023 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 Revised BSD License set		the license terms contained in, the Revised 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
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX;		This version of this YANG module is part of RFC 9403; see the
	see the RFC itself for full legal notices.";		RFC itself for full legal notices.";
	revision 2023-06-06 {		revision 2023-11-01 {
	description		description
	"Initial Version";		"Initial version.";
	reference		reference
	"RFC XXXX: A YANG Data Model for RIB Extensions.";		"RFC 9403: A YANG Data Model for RIB Extensions";
	}		}
	/* Groupings */		/* Groupings */
	grouping rib-statistics {		grouping rib-statistics {
	description		description
	"Statistics grouping used for RIB augmentation.";		"Statistics grouping used for RIB augmentation.";
	container statistics {		container statistics {
	config false;		config false;
	description		description
	"Container for RIB statistics.";		"Container for RIB statistics.";
	leaf total-routes {		leaf total-routes {
	type uint32;		type uint32;
	description		description
	"Total number of routes in the RIB";		"Total number of routes in the RIB.";
	}		}
	leaf total-active-routes {		leaf total-active-routes {
	type uint32;		type uint32;
	description		description
	"Total number of active routes in the RIB. An active		"Total number of active routes in the RIB. An active
	route is the route that is preferred over other routes		route is the route that is preferred over other routes
	to the same destination prefix.";		to the same destination prefix.";
	}		}
	leaf total-route-memory {		leaf total-route-memory {
	type uint64;		type uint64;
	units "bytes";		units "bytes";
	description		description
	"Total memory for all routes in the RIB.";		"Total memory for all routes in the RIB.";
	}		}
	list protocol-statistics {		list protocol-statistics {
	skipping to change at line 359 ¶		skipping to change at line 395 ¶
	type identityref {		type identityref {
	base rt:routing-protocol;		base rt:routing-protocol;
	}		}
	description		description
	"Routing protocol installing routes in the RIB.";		"Routing protocol installing routes in the RIB.";
	}		}
	leaf routes {		leaf routes {
	type uint32;		type uint32;
	description		description
	"Total number of routes in the RIB for the routing		"Total number of routes in the RIB for the routing
	protocol identified by the 'protocol'.";		protocol identified by the 'protocol' entry.";
	}		}
	leaf active-routes {		leaf active-routes {
	type uint32;		type uint32;
	description		description
	"Total number of active routes in the RIB for the routing		"Total number of active routes in the RIB for the
	protocol for the routing protocol identified by the		routing protocol identified by the 'protocol' entry.
	'protocol'. An active route is preferred over other		An active route is preferred over other routes to the
	routes to the same destination prefix.";		same destination prefix.";
	}		}
	leaf route-memory {		leaf route-memory {
	type uint64;		type uint64;
	units "bytes";		units "bytes";
	description		description
	"Total memory for all routes in the RIB for the routing		"Total memory for all routes in the RIB for the
	protocol identified by the 'protocol'.";		routing protocol identified by the 'protocol'
			entry.";
	}		}
	}		}
	}		}
	}		}
	grouping attributes {
	description
	"Common attributes applicable to all routes.";
	leaf metric {
	type uint32;
	description
	"The metric is a numeric value indicating the cost
	of the route from the perspective of the routing
	protocol installing the route. In general, routes with
	a lower metric installed by the same routing protocol
	are lower cost to reach and are preferable to routes
	with a higher metric. However, metrics from different
	routing protocols are not comparable.";
	}
	leaf-list tag {
	type uint32;
	description
	"A tag is a 32-bit opaque value associated with the
	route that can be used for policy decisions such as
	advertisement and filtering of the route.";
	}
	leaf application-tag {
	type uint32;
	description
	"The application-specific tag is an additional tag that
	can be used by applications that require semantics and/or
	policy different from that of the tag. For example,
	the tag is usually automatically advertised in OSPF
	AS-External Link State Advertisements (LSAs) while this
	application-specific tag is not advertised implicitly.";
	}
	}
	grouping repair-path {		grouping repair-path {
	description		description
	"Grouping for IP Fast Reroute repair path.";		"Grouping for the IP Fast Reroute (IPFRR) repair path.";
	container repair-path {		container repair-path {
	description		description
	"IP Fast Reroute next-hop repair path.";		"IPFRR next-hop repair path.";
	leaf outgoing-interface {		leaf outgoing-interface {
	type if:interface-state-ref;		type if:interface-state-ref;
	description		description
	"Name of the outgoing interface.";		"Name of the outgoing interface.";
	}		}
	leaf next-hop-address {		leaf next-hop-address {
	type inet:ip-address-no-zone;		type inet:ip-address-no-zone;
	description		description
	"IP address of the next hop.";		"IP address of the next hop.";
	}		}
	leaf metric {		leaf metric {
	type uint32;		type uint32;
	description		description
	"The metric for the repair path. While the IP Fast		"The metric for the repair path. While the reroute
	Reroute re-route repair is local and the metric is		repair is local and the metric is not advertised
	not advertised externally, the metric for repair path		externally, the metric for the repair path is useful
	is useful for troubleshooting purposes.";		for troubleshooting purposes.";
	}		}
	reference		reference
	"RFC 5714: IP Fast Reroute Framework.";		"RFC 5714: IP Fast Reroute Framework";
	}		}
	}		}
	augment "/rt:routing/rt:control-plane-protocols/"		augment "/rt:routing/rt:control-plane-protocols/"
	+ "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"		+ "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"
	+ "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"		+ "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"
	+ "v4ur:simple-next-hop"		+ "v4ur:simple-next-hop" {
	{
	description		description
	"Augment 'simple-next-hop' case in IPv4 unicast route.";		"Augment 'simple-next-hop' case in IPv4 unicast route.";
	leaf preference {		leaf preference {
	type uint32;		type uint32;
	default "1";		default "1";
	description		description
	"The preference is used to select among multiple static		"The preference is used to select among multiple static
	routes. Routes with a lower preference next-hop are		routes. Routes with a lower next-hop preference value
	preferred and equal preference routes result in		are preferred, and equal-preference routes result in
	Equal-Cost-Multi-Path (ECMP) static routes.";		Equal-Cost Multipath (ECMP) static routes.";
	}		}
	leaf tag {		leaf tag {
	type uint32;		type uint32;
	default "0";		default "0";
	description		description
	"The tag is a 32-bit opaque value associated with the		"The tag is a 32-bit opaque value associated with the
	route that can be used for policy decisions such as		route that can be used for policy decisions such as
	advertisement and filtering of the route.";		advertisement and filtering of the route.";
	}		}
	}		}
	augment "/rt:routing/rt:control-plane-protocols/"		augment "/rt:routing/rt:control-plane-protocols/"
	+ "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"		+ "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"
	+ "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"		+ "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"
	+ "v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop"		+ "v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop" {
	{
	description		description
	"Augment static route configuration 'next-hop-list'.";		"Augment static route configuration 'next-hop-list'.";
	leaf preference {		leaf preference {
	type uint32;		type uint32;
	default "1";		default "1";
	description		description
	"The preference is used to select among multiple static		"The preference is used to select among multiple static
	routes. Routes with a lower preference next-hop are		routes. Routes with a lower next-hop preference value
	preferred and equal preference routes result in		are preferred, and equal-preference routes result in
	Equal-Cost-Multi-Path (ECMP) static routes.";		ECMP static routes.";
	}		}
	leaf tag {		leaf tag {
	type uint32;		type uint32;
	default "0";		default "0";
	description		description
	"The tag is a 32-bit opaque value associated with the		"The tag is a 32-bit opaque value associated with the
	route that can be used for policy decisions such as		route that can be used for policy decisions such as
	advertisement and filtering of the route.";		advertisement and filtering of the route.";
	}		}
	}		}
	augment "/rt:routing/rt:control-plane-protocols/"		augment "/rt:routing/rt:control-plane-protocols/"
	+ "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"		+ "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"
	+ "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"		+ "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"
	+ "v6ur:simple-next-hop"		+ "v6ur:simple-next-hop" {
	{
	description		description
	"Augment 'simple-next-hop' case in IPv6 unicast route.";		"Augment 'simple-next-hop' case in IPv6 unicast route.";
	leaf preference {		leaf preference {
	type uint32;		type uint32;
	default "1";		default "1";
	description		description
	"The preference is used to select among multiple static		"The preference is used to select among multiple static
	routes. Routes with a lower preference next-hop are		routes. Routes with a lower next-hop preference value
	preferred and equal preference routes result in		are preferred, and equal-preference routes result in
	Equal-Cost-Multi-Path (ECMP) static routes.";		ECMP static routes.";
	}		}
	leaf tag {		leaf tag {
	type uint32;		type uint32;
	default "0";		default "0";
	description		description
	"The tag is a 32-bit opaque value associated with the		"The tag is a 32-bit opaque value associated with the
	route that can be used for policy decisions such as		route that can be used for policy decisions such as
	advertisement and filtering of the route.";		advertisement and filtering of the route.";
	}		}
	}		}
	augment "/rt:routing/rt:control-plane-protocols/"		augment "/rt:routing/rt:control-plane-protocols/"
	+ "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"		+ "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"
	+ "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"		+ "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"
	+ "v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop"		+ "v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop" {
	{
	description		description
	"Augment static route configuration 'next-hop-list'.";		"Augment static route configuration 'next-hop-list'.";
	leaf preference {		leaf preference {
	type uint32;		type uint32;
	default "1";		default "1";
	description		description
	"The preference is used to select among multiple static		"The preference is used to select among multiple static
	routes. Routes with a lower preference next-hop are		routes. Routes with a lower next-hop preference value
	preferred and equal preference routes result in		are preferred, and equal-preference routes result in
	Equal-Cost-Multi-Path (ECMP) static routes.";		ECMP static routes.";
	}		}
	leaf tag {		leaf tag {
	type uint32;		type uint32;
	default "0";		default "0";
	description		description
	"The tag is a 32-bit opaque value associated with the		"The tag is a 32-bit opaque value associated with the
	route that can be used for policy decisions such as		route that can be used for policy decisions such as
	advertisement and filtering of the route.";		advertisement and filtering of the route.";
	}		}
	}		}
	augment "/rt:routing/rt:ribs/rt:rib"		augment "/rt:routing/rt:ribs/rt:rib" {
	{
	description		description
	"Augment a RIB with statistics.";		"Augment a RIB with statistics.";
	uses rib-statistics;		uses rib-statistics;
	}		}
	augment "/rt:routing/rt:ribs/rt:rib/"		augment "/rt:routing/rt:ribs/rt:rib/"
	+ "rt:routes/rt:route"		+ "rt:routes/rt:route" {
	{
	description		description
	"Augment a route in RIB with attributes.";		"Augment a route in the RIB with common attributes.";
	uses attributes;		leaf metric {
			when "not(derived-from("
			+ "../rt:source-protocol, 'ospf:ospf')) "
			+ "and not(derived-from( "
			+ "../rt:source-protocol, 'isis:isis'))" {
			description
			"This augmentation is only valid for routes that don't
			have OSPF or IS-IS as the source protocol. The YANG
			data models for OSPF and IS-IS already include a
			'metric' augmentation for routes.";
			}
			type uint32;
			description
			"The metric is a numeric value indicating the cost
			of the route from the perspective of the routing
			protocol installing the route. In general, routes with
			a lower metric installed by the same routing protocol
			are lower cost to reach and are preferable to routes
			with a higher metric. However, metrics from different
			routing protocols are not comparable.";
			}
			leaf-list tag {
			when "not(derived-from("
			+ "../rt:source-protocol, 'ospf:ospf')) "
			+ "and not(derived-from( "
			+ "../rt:source-protocol, 'isis:isis'))" {
			description
			"This augmentation is only valid for routes that don't
			have OSPF or IS-IS as the source protocol. The YANG
			data models for OSPF and IS-IS already include a 'tag'
			augmentation for routes.";
			}
			type uint32;
			description
			"A tag is a 32-bit opaque value associated with the
			route that can be used for policy decisions such as
			advertisement and filtering of the route.";
			}
			leaf application-tag {
			type uint32;
			description
			"The application-specific tag is an additional tag that
			can be used by applications that require semantics and/or
			policy different from that of the tag. For example,
			the tag is usually automatically advertised in OSPF
			AS-External Link State Advertisements (LSAs) while this
			application-specific tag is not advertised implicitly.";
			}
	}		}
	augment "/rt:routing/rt:ribs/rt:rib/"		augment "/rt:routing/rt:ribs/rt:rib/"
	+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"		+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
	+ "rt:simple-next-hop"		+ "rt:simple-next-hop" {
	{
	description		description
	"Augment simple-next-hop with repair-path.";		"Augment 'simple-next-hop' with 'repair-path'.";
	uses repair-path;		uses repair-path;
	}		}
	augment "/rt:routing/rt:ribs/rt:rib/"		augment "/rt:routing/rt:ribs/rt:rib/"
	+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"		+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
	+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop"		+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
	{
	description		description
	"Augment the next-hop with a repair path.";		"Augment the next hop with a repair path.";
	uses repair-path;		uses repair-path;
	}		}
	}		}
			]]></sourcecode>
	]]></sourcecode>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>The YANG module specified in this document defines a schema for		<t>The YANG module specified in this document defines a schema for data
	data that is designed to be accessed via network		that is designed to be accessed via network management protocols such
	management protocols such as NETCONF <xref target="RFC6241" format="defau		as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
	lt"/> or		The lowest NETCONF layer is the secure transport layer, and the
	RESTCONF <xref target="RFC8040" format="default"/>. The lowest NETCONF la		mandatory-to-implement secure transport is Secure Shell (SSH)
	yer is the secure transport		<xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
	layer, and the mandatory-to-implement secure transport is Secure Shell (S		mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t>
	SH)		<t>The Network Configuration Access Control Model (NACM) <xref target="RFC834
	<xref target="RFC6242" format="default"/>. The lowest RESTCONF layer is H		1"/> provides the means to restrict access for particular NETCONF or
	TTPS, and the		RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF
	mandatory-to-implement secure transport is TLS <xref target="RFC8446" for		protocol operations and content.</t>
	mat="default"/>.</t>		<t>There are a number of data nodes defined in the ietf-rib-extension.yang mo
	<t>The NETCONF access control model <xref target="RFC8341" format="default		dule that are writable/creatable/deletable (i.e., config true, which is the defa
	"/> provides the		ult). These data nodes may be considered sensitive or vulnerable in some network
	means to restrict access for particular NETCONF or RESTCONF users to a		environments. Write operations (e.g., edit-config) to these data nodes without
	pre-configured subset of all available NETCONF or RESTCONF protocol		proper protection can have a negative effect on network operations. These are th
	operations and content.</t>		e subtrees and data nodes and their sensitivity/vulnerability:</t>
	<t>There are a number of data nodes defined in ietf-rib-extensions.yang mo		<ul spacing="normal">
	dule that are
	writable/creatable/deletable (i.e., config true, which is the default).
	These data nodes may be considered sensitive or vulnerable in some network
	environments. Write operations (e.g., edit-config) to these data nodes wit
	hout
	proper protection can have a negative effect on network operations.
	These are the subtrees and data nodes and their sensitivity/vulnerability:
	</t>
	<ul empty="true" spacing="normal">
	<li>/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:preference</li>		<li>/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:preference</li>
	<li>/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:tag</li>		<li>/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:tag</li>
	<li>/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list		<li>/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list
	/v4ur:next-hop/rib-ext:preference</li>		/v4ur:next-hop/rib-ext:preference</li>
	<li>/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list		<li>/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list
	/v4ur:next-hop/rib-ext:tag</li>		/v4ur:next-hop/rib-ext:tag</li>
	<li>/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:preference</li>		<li>/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:preference</li>
	<li>/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:tag</li>		<li>/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:tag</li>
	<li>/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list		<li>/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list
	/v6ur:next-hop/rib-ext:preference</li>		/v6ur:next-hop/rib-ext:preference</li>
	<li>/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list		<li>/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list
	/v6ur:next-hop/rib-ext:tag</li>		/v6ur:next-hop/rib-ext:tag</li>
	<li>For these augmentations to ietf-routing.yang, the ability to delete,
	add, and modify IPv4 and
	IPv6 static route preference and tag would allow traffic to be misrouted.<
	/li>
	</ul>		</ul>
	<t>Some of the readable data nodes in the ietf-rib-extensions.yang module		<t indent="3">For these augmentations to ietf-routing.yang, the ability
	may be		to delete, add, and modify IPv4 and
	considered sensitive or vulnerable in some network environments. It is thu		IPv6 static route preferences and tags would allow traffic to be misrouted
	s		.</t>
	important to control read access (e.g., via get, get-config, or notificati		<t>Some of the readable data nodes in the ietf-rib-extension.yang module may
	on)		be considered sensitive or vulnerable in some network environments. It is thus
	to these data nodes. These are the subtrees and data nodes and		important to control read access (e.g., via get, get-config, or notification) to
	their sensitivity/vulnerability:		these data nodes. These are the subtrees and data nodes and their
	</t>		sensitivity/vulnerability:</t>
	<ul empty="true" spacing="normal">		<ul spacing="normal">
	<li>/rt:routing/rt:ribs/rt:rib/rib-ext:statistics</li>		<li>/rt:routing/rt:ribs/rt:rib/rib-ext:statistics</li>
	<li>/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metric</li>		<li>/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metric</li>
	<li>/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:tag</li>		<li>/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:tag</li>
	<li>/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route		<li>/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:application-ta
	/rib-ext:application-tag</li>		g</li>
	<li>/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop		<li>/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop/rib-ext
	/rib-ext:repair-path</li>		:repair-path</li>
	<li>/rt:routes/rt:route/rt:next-hop/rt:next-hop-options		<li>/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list
	/rt:next-hop-list/rt:next-hop-list/rt:next-hop/rib-ext:repair-path</li>		/rt:next-hop-list/rt:next-hop/rib-ext:repair-path</li>
	<li>The exposure of the Routing Information Base (RIB) will		</ul>
			<t indent="3">Exposing the RIB will
	expose the routing topology of the network. This may be undesirable		expose the routing topology of the network. This may be undesirable
	due to the fact that exposure may facilitate other attacks. Additionally,		due to the fact that such exposure may facilitate other attacks. Additiona lly,
	network operators may consider their topologies to be sensitive confidenti al		network operators may consider their topologies to be sensitive confidenti al
	data.</li>		data.</t>
	</ul>
	<t>All the security considerations for <xref target="RFC8349" format="defa		<t>All the security considerations for writable and readable data nodes de
	ult"/> writable and		fined in <xref target="RFC8349" format="default"/>
	readable data nodes apply to the augmentations described herein.</t>		apply to the augmentations described herein.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t> This document registers a URI in the IETF XML registry		<t> This document registers the following URI in the "IETF XML Registry"
	<xref target="RFC3688" format="default"/>. Following the format in <xref tar		<xref target="RFC3688" format="default"/>.
	get="RFC3688" format="default"/>, the following
	registration is requested to be made:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<dl spacing="compact" newline="false">
	URI: urn:ietf:params:xml:ns:yang:ietf-rib-extension		<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-rib-extension</dd>
	Registrant Contact: The IESG.		<dt>Registrant Contact:</dt><dd>The IESG.</dd>
	XML: N/A, the requested URI is an XML namespace.		<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
	]]></artwork>		</dl>
	<t>This document registers a YANG module in the YANG Module Names		<t>IANA has registered the following YANG module in the "YANG Module Names
			"
	registry <xref target="RFC6020" format="default"/>.		registry <xref target="RFC6020" format="default"/>.
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<dl spacing="compact" newline="false">
	name: ietf-rib-extension		<dt>Name:</dt><dd>ietf-rib-extension</dd>
	namespace: urn:ietf:params:xml:ns:yang:ietf-rib-extension		<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-rib-extension</dd>
	prefix: rib-ext		<dt>Prefix:</dt><dd>rib-ext</dd>
	reference: RFC XXXX		<dt>Reference:</dt><dd>RFC 9403</dd>
	]]></artwork>		</dl>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
	688" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"
	<front>		/>
	<title>The IETF XML Registry</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"
	<author fullname="M. Mealling" initials="M." surname="Mealling"/>		/>
	<date month="January" year="2004"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"
	<abstract>		/>
	<t>This document describes an IANA maintained registry for IETF st		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"
	andards which use Extensible Markup Language (XML) related items such as Namespa		/>
	ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"
	ork (RDF) Schemas.</t>		/>
	</abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"
	</front>		/>
	<seriesInfo name="BCP" value="81"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"
	<seriesInfo name="RFC" value="3688"/>		/>
	<seriesInfo name="DOI" value="10.17487/RFC3688"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"
	</reference>		/>
	<reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"
	020" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">		/>
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"
	<title>YANG - A Data Modeling Language for the Network Configuration		/>
	Protocol (NETCONF)</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"
	<author fullname="M. Bjorklund" initials="M." role="editor" surname=		/>
	"Bjorklund"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"
	<date month="October" year="2010"/>		/>
	<abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9129.xml"
	<t>YANG is a data modeling language used to model configuration an		/>
	d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9130.xml"
	F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>		/>
	</abstract>
	</front>		<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
	<seriesInfo name="RFC" value="6020"/>		008/REC-xml-20081126">
	<seriesInfo name="DOI" value="10.17487/RFC6020"/>
	</reference>
	<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
	241" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
	<front>
	<title>Network Configuration Protocol (NETCONF)</title>
	<author fullname="R. Enns" initials="R." role="editor" surname="Enns
	"/>
	<author fullname="M. Bjorklund" initials="M." role="editor" surname=
	"Bjorklund"/>
	<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
	ame="Schoenwaelder"/>
	<author fullname="A. Bierman" initials="A." role="editor" surname="B
	ierman"/>
	<date month="June" year="2011"/>
	<abstract>
	<t>The Network Configuration Protocol (NETCONF) defined in this do
	cument provides mechanisms to install, manipulate, and delete the configuration
	of network devices. It uses an Extensible Markup Language (XML)-based data enco
	ding for the configuration data as well as the protocol messages. The NETCONF p
	rotocol operations are realized as remote procedure calls (RPCs). This document
	obsoletes RFC 4741. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6241"/>
	<seriesInfo name="DOI" value="10.17487/RFC6241"/>
	</reference>
	<reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6
	242" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml">
	<front>
	<title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
	<author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
	<date month="June" year="2011"/>
	<abstract>
	<t>This document describes a method for invoking and running the N
	etwork Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as a
	n SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6242"/>
	<seriesInfo name="DOI" value="10.17487/RFC6242"/>
	</reference>
	<reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6
	991" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml">
	<front>
	<title>Common YANG Data Types</title>
	<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
	ame="Schoenwaelder"/>
	<date month="July" year="2013"/>
	<abstract>
	<t>This document introduces a collection of common data types to b
	e used with the YANG data modeling language. This document obsoletes RFC 6021.<
	/t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6991"/>
	<seriesInfo name="DOI" value="10.17487/RFC6991"/>
	</reference>
	<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
	950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
	<front>
	<title>The YANG 1.1 Data Modeling Language</title>
	<author fullname="M. Bjorklund" initials="M." role="editor" surname=
	"Bjorklund"/>
	<date month="August" year="2016"/>
	<abstract>
	<t>YANG is a data modeling language used to model configuration da
	ta, state data, Remote Procedure Calls, and notifications for network management
	protocols. This document describes the syntax and semantics of version 1.1 of
	the YANG language. YANG version 1.1 is a maintenance release of the YANG langua
	ge, addressing ambiguities and defects in the original specification. There are
	a small number of backward incompatibilities from YANG version 1. This documen
	t also specifies the YANG mappings to the Network Configuration Protocol (NETCON
	F).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7950"/>
	<seriesInfo name="DOI" value="10.17487/RFC7950"/>
	</reference>
	<reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8
	040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
	<front>
	<title>RESTCONF Protocol</title>
	<author fullname="A. Bierman" initials="A." surname="Bierman"/>
	<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
	<author fullname="K. Watsen" initials="K." surname="Watsen"/>
	<date month="January" year="2017"/>
	<abstract>
	<t>This document describes an HTTP-based protocol that provides a
	programmatic interface for accessing data defined in YANG, using the datastore c
	oncepts defined in the Network Configuration Protocol (NETCONF).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8040"/>
	<seriesInfo name="DOI" value="10.17487/RFC8040"/>
	</reference>
	<reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8
	341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
	<front>
	<title>Network Configuration Access Control Model</title>
	<author fullname="A. Bierman" initials="A." surname="Bierman"/>
	<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
	<date month="March" year="2018"/>
	<abstract>
	<t>The standardization of network configuration interfaces for use
	with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
	ires a structured and secure operating environment that promotes human usability
	and multi-vendor interoperability. There is a need for standard mechanisms to r
	estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
	red subset of all available NETCONF or RESTCONF protocol operations and content.
	This document defines such an access control model.</t>
	<t>This document obsoletes RFC 6536.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="91"/>
	<seriesInfo name="RFC" value="8341"/>
	<seriesInfo name="DOI" value="10.17487/RFC8341"/>
	</reference>
	<reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8
	342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml">
	<front>
	<title>Network Management Datastore Architecture (NMDA)</title>
	<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
	<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
	lder"/>
	<author fullname="P. Shafer" initials="P." surname="Shafer"/>
	<author fullname="K. Watsen" initials="K." surname="Watsen"/>
	<author fullname="R. Wilton" initials="R." surname="Wilton"/>
	<date month="March" year="2018"/>
	<abstract>
	<t>Datastores are a fundamental concept binding the data models wr
	itten in the YANG data modeling language to network management protocols such as
	the Network Configuration Protocol (NETCONF) and RESTCONF. This document defin
	es an architectural framework for datastores based on the experience gained with
	the initial simpler model, addressing requirements that were not well supported
	in the initial model. This document updates RFC 7950.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8342"/>
	<seriesInfo name="DOI" value="10.17487/RFC8342"/>
	</reference>
	<reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8
	343" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml">
	<front>
	<title>A YANG Data Model for Interface Management</title>
	<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
	<date month="March" year="2018"/>
	<abstract>
	<t>This document defines a YANG data model for the management of n
	etwork interfaces. It is expected that interface-type-specific data models augme
	nt the generic interfaces data model defined in this document. The data model in
	cludes definitions for configuration and system state (status information and co
	unters for the collection of statistics).</t>
	<t>The YANG data model in this document conforms to the Network Ma
	nagement Datastore Architecture (NMDA) defined in RFC 8342.</t>
	<t>This document obsoletes RFC 7223.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8343"/>
	<seriesInfo name="DOI" value="10.17487/RFC8343"/>
	</reference>
	<reference anchor="RFC8349" target="https://www.rfc-editor.org/info/rfc8
	349" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml">
	<front>
	<title>A YANG Data Model for Routing Management (NMDA Version)</titl
	e>
	<author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
	<author fullname="A. Lindem" initials="A." surname="Lindem"/>
	<author fullname="Y. Qu" initials="Y." surname="Qu"/>
	<date month="March" year="2018"/>
	<abstract>
	<t>This document specifies three YANG modules and one submodule. T
	ogether, they form the core routing data model that serves as a framework for co
	nfiguring and managing a routing subsystem. It is expected that these modules wi
	ll be augmented by additional YANG modules defining data models for control-plan
	e protocols, route filters, and other functions. The core routing data model pro
	vides common building blocks for such extensions -- routes, Routing Information
	Bases (RIBs), and control-plane protocols.</t>
	<t>The YANG modules in this document conform to the Network Manage
	ment Datastore Architecture (NMDA). This document obsoletes RFC 8022.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8349"/>
	<seriesInfo name="DOI" value="10.17487/RFC8349"/>
	</reference>
	<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
	446" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
	<front>		<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl		<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
	e>		<author initials="T." surname="Bray" fullname="Tim Bray">
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>		<organization/>
	<date month="August" year="2018"/>		</author>
	<abstract>		<author initials="J." surname="Paoli" fullname="Jean Paoli">
	<t>This document specifies version 1.3 of the Transport Layer Secu		<organization/>
	rity (TLS) protocol. TLS allows client/server applications to communicate over t		</author>
	he Internet in a way that is designed to prevent eavesdropping, tampering, and m		<author initials="M." surname="Sperberg-McQueen" fullname="Michael S
	essage forgery.</t>		perberg-McQueen">
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50		<organization/>
	77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im		</author>
	plementations.</t>		<author initials="E." surname="Maler" fullname="Eve Maler">
	</abstract>		<organization/>
			</author>
			<author initials="F." surname="Yergeau" fullname="François Yergeau">
			<organization/>
			</author>
			<date month="November" year="2008"/>
	</front>		</front>
	<seriesInfo name="RFC" value="8446"/>		<refcontent>World Wide Web Consortium Recommendation REC-xml-20081126<
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>		/refcontent>
	</reference>		</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC5714" target="https://www.rfc-editor.org/info/rfc5
	714" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml"
	<front>		/>
	<title>IP Fast Reroute Framework</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"
	<author fullname="M. Shand" initials="M." surname="Shand"/>		/>
	<author fullname="S. Bryant" initials="S." surname="Bryant"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"
	<date month="January" year="2010"/>		/>
	<abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"
	<t>This document provides a framework for the development of IP fa		/>
	st- reroute mechanisms that provide protection against link or router failure by
	invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechan
	isms are applicable to a network employing conventional IP routing and forwardin
	g. This document is not an Internet Standards Track specification; it is publis
	hed for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5714"/>
	<seriesInfo name="DOI" value="10.17487/RFC5714"/>
	</reference>
	<reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8
	340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml">
	<front>
	<title>YANG Tree Diagrams</title>
	<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
	<author fullname="L. Berger" initials="L." role="editor" surname="Be
	rger"/>
	<date month="March" year="2018"/>
	<abstract>
	<t>This document captures the current syntax used in YANG module t
	ree diagrams. The purpose of this document is to provide a single location for
	this definition. This syntax may be updated from time to time based on the evol
	ution of the YANG language.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="215"/>
	<seriesInfo name="RFC" value="8340"/>
	<seriesInfo name="DOI" value="10.17487/RFC8340"/>
	</reference>
	<reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8
	792" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml">
	<front>
	<title>Handling Long Lines in Content of Internet-Drafts and RFCs</t
	itle>
	<author fullname="K. Watsen" initials="K." surname="Watsen"/>
	<author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
	<author fullname="A. Farrel" initials="A." surname="Farrel"/>
	<author fullname="Q. Wu" initials="Q." surname="Wu"/>
	<date month="June" year="2020"/>
	<abstract>
	<t>This document defines two strategies for handling long lines in
	width-bounded text content. One strategy, called the "single backslash" strate
	gy, is based on the historical use of a single backslash ('\') character to indi
	cate where line-folding has occurred, with the continuation occurring with the f
	irst character that is not a space character (' ') on the next line. The second
	strategy, called the "double backslash" strategy, extends the first strategy by
	adding a second backslash character to identify where the continuation begins a
	nd is thereby able to handle cases not supported by the first strategy. Both st
	rategies use a self-describing header enabling automated reconstitution of the o
	riginal content.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8792"/>
	<seriesInfo name="DOI" value="10.17487/RFC8792"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="full-tree" numbered="true" toc="default">		<section anchor="full-tree" numbered="true" toc="default">
	<name>Combined Tree Diagram</name>		<name>Combined Tree Diagram</name>
	<t>This appendix includes the combined ietf-routing.yang, ietf-ipv4-unicas		<t>This appendix provides the combined ietf-routing.yang, ietf-ipv4-unicas
	t-routing.yang,		t-routing.yang,
	ietf-ipv6-unicast-routing.yang and ietf-rib-extensions.yang tree diagram.</t>		ietf-ipv6-unicast-routing.yang, and ietf-rib-extension.yang tree diagram.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="yangtree"><![CDATA[
	module: ietf-routing		module: ietf-routing
	+--rw routing		+--rw routing
	+--rw router-id? yang:dotted-quad {router-id}?		+--rw router-id? yang:dotted-quad {router-id}?
	+--ro interfaces		+--ro interfaces
	| +--ro interface* if:interface-ref		| +--ro interface* if:interface-ref
	+--rw control-plane-protocols		+--rw control-plane-protocols
	| +--rw control-plane-protocol* [type name]		| +--rw control-plane-protocol* [type name]
	| +--rw type identityref		| +--rw type identityref
	| +--rw name string		| +--rw name string
	| +--rw description? string		| +--rw description? string
	| +--rw static-routes		| +--rw static-routes
	| +--rw v4ur:ipv4		| +--rw v4ur:ipv4
	| | +--rw v4ur:route* [destination-prefix]		| | +--rw v4ur:route* [destination-prefix]
	| | +--rw v4ur:destination-prefix inet:ipv4-prefix		| | +--rw v4ur:destination-prefix inet:ipv4-prefix
	| | +--rw v4ur:description? string		| | +--rw v4ur:description? string
	| | +--rw v4ur:next-hop		| | +--rw v4ur:next-hop
	| | +--rw (v4ur:next-hop-options)		| | +--rw (v4ur:next-hop-options)
	| | +--:(v4ur:simple-next-hop)		| | +--:(v4ur:simple-next-hop)
	| | | +--rw v4ur:outgoing-interface?		| | | +--rw v4ur:outgoing-interface?
	| | | | if:interface-ref		| | | | if:interface-ref
	| | | +--rw v4ur:next-hop-address?		| | | +--rw v4ur:next-hop-address?
	| | | | inet:ipv4-address		| | | | inet:ipv4-address
	| | | +--rw rib-ext:preference? uint32		| | | +--rw rib-ext:preference? uint32
	| | | +--rw rib-ext:tag? uint32		| | | +--rw rib-ext:tag? uint32
	| | +--:(v4ur:special-next-hop)		| | +--:(v4ur:special-next-hop)
	| | | +--rw v4ur:special-next-hop? enumeration		| | | +--rw v4ur:special-next-hop? enumeration
	| | +--:(v4ur:next-hop-list)		| | +--:(v4ur:next-hop-list)
	| | +--rw v4ur:next-hop-list		| | +--rw v4ur:next-hop-list
	| | +--rw v4ur:next-hop* [index]		| | +--rw v4ur:next-hop* [index]
	| | +--rw v4ur:index string		| | +--rw v4ur:index string
	| | +--rw v4ur:outgoing-interface?		| | +--rw v4ur:outgoing-interface?
	| | | if:interface-ref		| | | if:interface-ref
	| | +--rw v4ur:next-hop-address?		| | +--rw v4ur:next-hop-address?
	| | | inet:ipv4-address		| | | inet:ipv4-address
	| | +--rw rib-ext:preference? uint32		| | +--rw rib-ext:preference? uint32
	| | +--rw rib-ext:tag? uint32		| | +--rw rib-ext:tag? uint32
	| +--rw v6ur:ipv6		| +--rw v6ur:ipv6
	| +--rw v6ur:route* [destination-prefix]		| +--rw v6ur:route* [destination-prefix]
	| +--rw v6ur:destination-prefix inet:ipv6-prefix		| +--rw v6ur:destination-prefix inet:ipv6-prefix
	| +--rw v6ur:description? string		| +--rw v6ur:description? string
	| +--rw v6ur:next-hop		| +--rw v6ur:next-hop
	| +--rw (v6ur:next-hop-options)		| +--rw (v6ur:next-hop-options)
	| +--:(v6ur:simple-next-hop)		| +--:(v6ur:simple-next-hop)
	| | +--rw v6ur:outgoing-interface?		| | +--rw v6ur:outgoing-interface?
	| | | if:interface-ref		| | | if:interface-ref
	| | +--rw v6ur:next-hop-address?		| | +--rw v6ur:next-hop-address?
	| | | inet:ipv6-address		| | | inet:ipv6-address
	| | +--rw rib-ext:preference? uint32		| | +--rw rib-ext:preference? uint32
	| | +--rw rib-ext:tag? uint32		| | +--rw rib-ext:tag? uint32
	| +--:(v6ur:special-next-hop)		| +--:(v6ur:special-next-hop)
	| | +--rw v6ur:special-next-hop? enumeration		| | +--rw v6ur:special-next-hop? enumeration
	| +--:(v6ur:next-hop-list)		| +--:(v6ur:next-hop-list)
	| +--rw v6ur:next-hop-list		| +--rw v6ur:next-hop-list
	| +--rw v6ur:next-hop* [index]		| +--rw v6ur:next-hop* [index]
	| +--rw v6ur:index string		| +--rw v6ur:index string
	| +--rw v6ur:outgoing-interface?		| +--rw v6ur:outgoing-interface?
	| | if:interface-ref		| | if:interface-ref
	| +--rw v6ur:next-hop-address?		| +--rw v6ur:next-hop-address?
	| | inet:ipv6-address		| | inet:ipv6-address
	| +--rw rib-ext:preference? uint32		| +--rw rib-ext:preference? uint32
	| +--rw rib-ext:tag? uint32		| +--rw rib-ext:tag? uint32
	+--rw ribs		+--rw ribs
	+--rw rib* [name]		+--rw rib* [name]
	+--rw name string		+--rw name string
	+--rw address-family identityref		+--rw address-family identityref
	+--ro default-rib? boolean {multiple-ribs}?		+--ro default-rib? boolean {multiple-ribs}?
	+--ro routes		+--ro routes
	| +--ro route* []		| +--ro route* []
	| +--ro route-preference? route-preference		| +--ro route-preference? route-preference
	| +--ro next-hop		| +--ro next-hop
	| | +--ro (next-hop-options)		| | +--ro (next-hop-options)
	| | +--:(simple-next-hop)		| | +--:(simple-next-hop)
	| | | +--ro outgoing-interface? if:interface-ref		| | | +--ro outgoing-interface?
	| | | +--ro v4ur:next-hop-address? inet:ipv4-address		| | | | if:interface-ref
	| | | +--ro v6ur:next-hop-address? inet:ipv6-address		| | | +--ro v4ur:next-hop-address?
	| | | +--ro rib-ext:repair-path		| | | | inet:ipv4-address
	| | | +--ro rib-ext:outgoing-interface?		| | | +--ro v6ur:next-hop-address?
	| | | | if:interface-state-ref		| | | | inet:ipv6-address
	| | | +--ro rib-ext:next-hop-address?		| | | +--ro rib-ext:repair-path
	| | | | inet:ip-address-no-zone		| | | +--ro rib-ext:outgoing-interface?
	| | | +--ro rib-ext:metric? uint32		| | | | if:interface-state-ref
	| | +--:(special-next-hop)		| | | +--ro rib-ext:next-hop-address?
	| | | +--ro special-next-hop? enumeration		| | | | inet:ip-address-no-zone
	| | +--:(next-hop-list)		| | | +--ro rib-ext:metric? uint32
	| | +--ro next-hop-list		| | +--:(special-next-hop)
	| | +--ro next-hop* []		| | | +--ro special-next-hop? enumeration
	| | +--ro outgoing-interface?		| | +--:(next-hop-list)
	| | | if:interface-ref		| | +--ro next-hop-list
	| | +--ro v4ur:address?		| | +--ro next-hop* []
	| | | inet:ipv4-address		| | +--ro outgoing-interface?
	| | +--ro v6ur:address?		| | | if:interface-ref
	| | | inet:ipv6-address		| | +--ro v4ur:address?
	| | +--ro rib-ext:repair-path		| | | inet:ipv4-address
	| | +--ro rib-ext:outgoing-interface?		| | +--ro v6ur:address?
	| | | if:interface-state-ref		| | | inet:ipv6-address
	| | +--ro rib-ext:next-hop-address?		| | +--ro rib-ext:repair-path
	| | | inet:ip-address-no-zone		| | +--ro rib-ext:outgoing-interface?
	| | +--ro rib-ext:metric? uint32		| | | if:interface-state-ref
	| +--ro source-protocol identityref		| | +--ro rib-ext:next-hop-address?
	| +--ro active? empty		| | | inet:ip-address-no-zone
	| +--ro last-updated? yang:date-and-time		| | +--ro rib-ext:metric? uint32
	| +--ro v4ur:destination-prefix? inet:ipv4-prefix		| +--ro source-protocol identityref
	| +--ro v6ur:destination-prefix? inet:ipv6-prefix		| +--ro active? empty
	| +--ro rib-ext:metric? uint32		| +--ro last-updated? yang:date-and-time
	| +--ro rib-ext:tag* uint32		| +--ro v4ur:destination-prefix? inet:ipv4-prefix
	| +--ro rib-ext:application-tag? uint32		| +--ro v6ur:destination-prefix? inet:ipv6-prefix
	+---x active-route		| +--ro rib-ext:metric? uint32
	| +---w input		| +--ro rib-ext:tag* uint32
	| | +---w v4ur:destination-address? inet:ipv4-address		| +--ro rib-ext:application-tag? uint32
	| | +---w v6ur:destination-address? inet:ipv6-address		+---x active-route
	| +--ro output		| +---w input
	| +--ro route		| | +---w v4ur:destination-address? inet:ipv4-address
	| +--ro next-hop		| | +---w v6ur:destination-address? inet:ipv6-address
	| | +--ro (next-hop-options)		| +--ro output
	| | +--:(simple-next-hop)		| +--ro route
	| | | +--ro outgoing-interface? if:interface-ref		| +--ro next-hop
	| | | +--ro v4ur:next-hop-address?		| | +--ro (next-hop-options)
	| | | | inet:ipv4-address		| | +--:(simple-next-hop)
	| | | +--ro v6ur:next-hop-address?		| | | +--ro outgoing-interface?
	| | | | inet:ipv6-address		| | | | if:interface-ref
	| | +--:(special-next-hop)		| | | +--ro v4ur:next-hop-address?
	| | | +--ro special-next-hop? enumeration		| | | | inet:ipv4-address
	| | +--:(next-hop-list)		| | | +--ro v6ur:next-hop-address?
	| | +--ro next-hop-list		| | | | inet:ipv6-address
	| | +--ro next-hop* []		| | +--:(special-next-hop)
	| | +--ro outgoing-interface?		| | | +--ro special-next-hop? enumeration
	| | | if:interface-ref		| | +--:(next-hop-list)
	| | +--ro v4ur:next-hop-address?		| | +--ro next-hop-list
	| | | inet:ipv4-address		| | +--ro next-hop* []
	| | +--ro v6ur:next-hop-address?		| | +--ro outgoing-interface?
	| | | inet:ipv6-address		| | | if:interface-ref
	| +--ro source-protocol identityref		| | +--ro v4ur:next-hop-address?
	| +--ro active? empty		| | | inet:ipv4-address
	| +--ro last-updated? yang:date-and-time		| | +--ro v6ur:next-hop-address?
	| +--ro v4ur:destination-prefix? inet:ipv4-prefix		| | | inet:ipv6-address
	| +--ro v6ur:destination-prefix? inet:ipv6-prefix		| +--ro source-protocol identityref
	+--rw description? string		| +--ro active? empty
	+--ro rib-ext:statistics		| +--ro last-updated? yang:date-and-time
	+--ro rib-ext:total-routes? uint32		| +--ro v4ur:destination-prefix? inet:ipv4-prefix
	+--ro rib-ext:total-active-routes? uint32		| +--ro v6ur:destination-prefix? inet:ipv6-prefix
	+--ro rib-ext:total-route-memory? uint64		+--rw description? string
	+--ro rib-ext:protocol-statistics* []		+--ro rib-ext:statistics
	+--ro rib-ext:protocol? identityref		+--ro rib-ext:total-routes? uint32
	+--ro rib-ext:routes? uint32		+--ro rib-ext:total-active-routes? uint32
	+--ro rib-ext:active-routes? uint32		+--ro rib-ext:total-route-memory? uint64
	+--ro rib-ext:route-memory? uint64		+--ro rib-ext:protocol-statistics* []
			+--ro rib-ext:protocol? identityref
	]]></artwork>		+--ro rib-ext:routes? uint32
			+--ro rib-ext:active-routes? uint32
			+--ro rib-ext:route-memory? uint64
			]]></sourcecode>
	</section>		</section>
	<section anchor="examples" numbered="true" toc="default">		<section anchor="examples" numbered="true" toc="default">
	<name>ietf-rib-extension.yang example</name>		<name>ietf-rib-extension.yang example</name>
	<t>The following is an XML example using the RIB extension module		<t>The following is an XML example <xref target="W3C.REC-xml-20081126"/> u
	and RFC 8349.</t>		sing the RIB extension module and RFC 8349.</t>
	<t>Note: '\' line wrapping per <xref target="RFC8792" format="default"/>.		<aside><t>Note: '\' line wrapping per <xref target="RFC8792" format="defau
	</t>		lt"/>.</t></aside>
	<artwork name="" type="" align="left" alt=""><![CDATA[
			<sourcecode type="xml"><![CDATA[
	<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">		<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
	<control-plane-protocols>		<control-plane-protocols>
	<control-plane-protocol>		<control-plane-protocol>
	<type>static</type>		<type>static</type>
	<name>static-routing-protocol</name>		<name>static-routing-protocol</name>
	<static-routes>		<static-routes>
	<ipv4 xmlns="urn:ietf:params:xml:ns:yang:\		<ipv4 xmlns="urn:ietf:params:xml:ns:yang:\
	ietf-ipv4-unicast-routing">		ietf-ipv4-unicast-routing">
	<route>		<route>
	<destination-prefix>0.0.0.0/0</destination-prefix>		<destination-prefix>0.0.0.0/0</destination-prefix>
	skipping to change at line 1107 ¶		skipping to change at line 978 ¶
	</destination-prefix>		</destination-prefix>
	<next-hop>		<next-hop>
	<next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\		<next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
	ietf-ipv4-unicast-routing">192.0.2.2</next-hop-address>		ietf-ipv4-unicast-routing">192.0.2.2</next-hop-address>
	<repair-path xmlns="urn:ietf:params:xml:ns:yang:\		<repair-path xmlns="urn:ietf:params:xml:ns:yang:\
	ietf-rib-extension">		ietf-rib-extension">
	<next-hop-address>203.0.113.1</next-hop-address>		<next-hop-address>203.0.113.1</next-hop-address>
	<metric>200</metric>		<metric>200</metric>
	</repair-path>		</repair-path>
	</next-hop>		</next-hop>
	<route-preference>110</route-preference>		<route-preference>120</route-preference>
	<source-protocol xmlns:ospf="urn:ietf:params:xml:ns:yang:\		<source-protocol xmlns:rip="urn:ietf:params:xml:ns:yang:\
	ietf-ospf">ospf:ospf</source-protocol>		ietf-rip">rip:rip</source-protocol>
	<last-updated>2015-10-24T18:02:45+02:00</last-updated>		<last-updated>2015-10-24T18:02:45+02:00</last-updated>
	</route>		</route>
	</routes>		</routes>
	</rib>		</rib>
	<rib>		<rib>
	<name>ipv6-primary</name>		<name>ipv6-primary</name>
	<address-family xmlns:v6ur="urn:ietf:params:xml:ns:yang:\		<address-family xmlns:v6ur="urn:ietf:params:xml:ns:yang:\
	ietf-ipv6-unicast-routing">v6ur:ipv6-unicast</address-family>		ietf-ipv6-unicast-routing">v6ur:ipv6-unicast</address-family>
	<default-rib>true</default-rib>		<default-rib>true</default-rib>
	<routes>		<routes>
	skipping to change at line 1146 ¶		skipping to change at line 1017 ¶
	<next-hop>		<next-hop>
	<next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\		<next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
	ietf-ipv6-unicast-routing">2001:db8:aaaa::1111\		ietf-ipv6-unicast-routing">2001:db8:aaaa::1111\
	</next-hop-address>		</next-hop-address>
	<repair-path xmlns="urn:ietf:params:xml:ns:yang:\		<repair-path xmlns="urn:ietf:params:xml:ns:yang:\
	ietf-rib-extension">		ietf-rib-extension">
	<next-hop-address>2001:db8:cccc::2222</next-hop-address>		<next-hop-address>2001:db8:cccc::2222</next-hop-address>
	<metric>200</metric>		<metric>200</metric>
	</repair-path>		</repair-path>
	</next-hop>		</next-hop>
	<route-preference>110</route-preference>		<route-preference>120</route-preference>
	<source-protocol xmlns:ospf="urn:ietf:params:xml:ns:yang:\		<source-protocol xmlns:rip="urn:ietf:params:xml:ns:yang:\
	ietf-ospf">ospf:ospf</source-protocol>		ietf-rip">rip:rip</source-protocol>
	<last-updated>2015-10-24T18:02:45+02:00</last-updated>		<last-updated>2015-10-24T18:02:45+02:00</last-updated>
	</route>		</route>
	</routes>		</routes>
	</rib>		</rib>
	</ribs>		</ribs>
	</routing>		</routing>
			]]></sourcecode>
	]]></artwork>		<t>The following is the same example using JSON format <xref target="RFC79
	<t>The following is the same example using JSON format.</t>		51"/>.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"ietf-routing:routing": {		"ietf-routing:routing": {
	"control-plane-protocols": {		"control-plane-protocols": {
	"control-plane-protocol": [		"control-plane-protocol": [
	{		{
	"type": "static",		"type": "static",
	"name": "static-routing-protocol",		"name": "static-routing-protocol",
	"static-routes": {		"static-routes": {
	"ietf-ipv4-unicast-routing:ipv4": {		"ietf-ipv4-unicast-routing:ipv4": {
	"route": [		"route": [
	skipping to change at line 1223 ¶		skipping to change at line 1093 ¶
	},		},
	{		{
	"next-hop": {		"next-hop": {
	"ietf-rib-extension:repair-path": {		"ietf-rib-extension:repair-path": {
	"next-hop-address": "203.0.113.1",		"next-hop-address": "203.0.113.1",
	"metric": 200		"metric": 200
	},		},
	"ietf-ipv4-unicast-routing:next-hop-address": \		"ietf-ipv4-unicast-routing:next-hop-address": \
	"192.0.2.2"		"192.0.2.2"
	},		},
	"route-preference": 110,		"route-preference": 120,
	"source-protocol": "ietf-ospf:ospf",		"source-protocol": "ietf-rip:rip",
	"last-updated": "2015-10-24T18:02:45+02:00",		"last-updated": "2015-10-24T18:02:45+02:00",
	"ietf-ipv4-unicast-routing:destination-prefix": \		"ietf-ipv4-unicast-routing:destination-prefix": \
	"198.51.100.0/24"		"198.51.100.0/24"
	}		}
	]		]
	}		}
	},		},
	{		{
	"name": "ipv6-primary",		"name": "ipv6-primary",
	"address-family": "ietf-ipv6-unicast-routing:ipv6-unicast",		"address-family": "ietf-ipv6-unicast-routing:ipv6-unicast",
	skipping to change at line 1257 ¶		skipping to change at line 1127 ¶
	},		},
	{		{
	"next-hop": {		"next-hop": {
	"ietf-rib-extension:repair-path": {		"ietf-rib-extension:repair-path": {
	"next-hop-address": "2001:db8:cccc::2222",		"next-hop-address": "2001:db8:cccc::2222",
	"metric": 200		"metric": 200
	},		},
	"ietf-ipv6-unicast-routing:next-hop-address": \		"ietf-ipv6-unicast-routing:next-hop-address": \
	"2001:db8:aaaa::1111"		"2001:db8:aaaa::1111"
	},		},
	"route-preference": 110,		"route-preference": 120,
	"source-protocol": "ietf-ospf:ospf",		"source-protocol": "ietf-rip:rip",
	"last-updated": "2015-10-24T18:02:45+02:00",		"last-updated": "2015-10-24T18:02:45+02:00",
	"ietf-ipv6-unicast-routing:destination-prefix": \		"ietf-ipv6-unicast-routing:destination-prefix": \
	"2001:db8:bbbb::/64"		"2001:db8:bbbb::/64"
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	}		}
			]]></sourcecode>
	]]></artwork>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="false" toc="default">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>The RFC text was produced using Marshall Rose's xml2rfc tool.</t>
	<t>		<t>
	The authors wish to thank Les Ginsberg, Krishna Deevi, and Suyoung Yoon		The authors wish to thank <contact fullname="Les Ginsberg"/>, <contact f ullname="Krishna Deevi"/>, and <contact fullname="Suyoung Yoon"/>
	for their helpful comments and suggestions.		for their helpful comments and suggestions.
	</t>		</t>
	<t>		<t>
	The authors wish to thank Tom Petch, Rob Wilton, Chris Hopps, Martin		The authors wish to thank <contact fullname="Tom Petch"/>, <contact full
	Bjorklund, Jeffrey Zhang, Eric Vyncke, Lars Eggert, and Bo Wu for		name="Rob Wilton"/>, <contact fullname="Chris Hopps"/>, <contact fullname="Marti
			n Björklund"/>, <contact fullname="Jeffrey Zhang"/>, <contact fullname="Éric Vyn
			cke"/>, <contact fullname="Lars Eggert"/>, and <contact fullname="Bo Wu"/> for
	their reviews and comments.		their reviews and comments.
	</t>		</t>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 109 change blocks.
	726 lines changed or deleted		528 lines changed or added
This html diff was produced by rfcdiff 1.48.