One document matched: draft-acee-rtgwg-yang-rib-extend-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-acee-rtgwg-yang-rib-extend-00.txt" >
<front>
<title abbrev="YANG RIB Extensions">YANG Data Model for RIB Extensions</title>
<author initials='A.' surname="Lindem" fullname='Acee Lindem'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>301 Midenhall Way</street>
<city>Cary</city> <region>NC</region>
<country>USA</country>
<code>27513</code>
</postal>
<email>acee@cisco.com</email>
</address>
</author>
<author initials='Y.' surname="Qu" fullname='Yingzhen Qu'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city> <region>CA</region>
<country>USA</country>
<code>95134</code>
</postal>
<email>yiqu@cisco.com</email>
</address>
</author>
<date/>
<abstract>
<t>The Routing Information Base (RIB) is a list of routes and their
corresponding administrative data and operational state.</t>
<t>The document <xref target="ROUTING-CFG"/> defines the
basic building blocks for RIB, and this model augments it to support
multiple next-hops (aka, paths) for each route as well as additional
attributes.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document defines a YANG, <xref target="YANG"/>, data model which extends
the generic data model for RIB by augmenting the ietf-routing model as
defined in <xref target="ROUTING-CFG"/>.</t>
<t>RIB is a collection of best routes from all routing protocols. Within a protocol
routes are selected based on the metrics in use by that protocol, and
the protocol install its best routes to RIB. RIB selects the best route
by comparing the route preference (aka, administrative distance) of
the associated protocol.</t>
<t>The augmentations described herein extend the RIB to support
multiple paths per route, route metrics, and administrative tags.</t>
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC-KEYWORDS"/>.</t>
</section>
</section>
<section title="Design of the Model">
<t>The YANG definitions in this document augment the ietf-routing model
defined in <xref target="ROUTING-CFG"/>, which provides a basis
for routing system data model development. Together with modules defined in
<xref target="ROUTING-CFG"/>, a generic RIB Yang model is defined to
implement and monitor RIB.</t>
<t>The models in <xref target="ROUTING-CFG"/> also define the basic
configuration and operational state for both IPv4 and IPv6 static routes and this document
also provides augmentations for static routes to support multiple next-hop
and more next-hop attributes.
</t>
<section title=" RIB next-hop dampening">
<t>A feature "next-hop-dampen" is defined. Implementations that support
this feature can enable/disable RIB dampening.</t>
</section>
<section title="Multiple next-hops">
<t>Both Ipv4 and IPv6 static route configuration defined in
<xref target="ROUTING-CFG"/> have been augmented with a multi-next-hop
option.</t>
<t>A static route/prefix can be configured to have multiple
next-hops, each with their own tag and route preference.</t>
<t>In RIB, a route may have multiple next-hops. They can be either equal cost
multiple paths (ECMP), or they may have different metrics.</t>
</section>
<section title="Repair path">
<t>The loop-free alternate (LFA) Fast Reroute (FRR) pre-computes repair
paths by routing protocols, and RIB stores the best repair path.</t>
<t>A repair path is augmented in RIB operation state for each path.</t>
</section>
</section>
<section anchor="rib.tree" title="RIB Extensions Model Tree">
<t>A simplified graphical representation of the augmentations described herein
is included below.</t>
<t>The meaning of the symbols in this diagrams is as follows:
<list style="symbols">
<t>Brackets "[" and "]" enclose list keys.</t>
<t>Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional.</t>
<t>Abbreviations before data node names: "rw" means configuration
(read-write), "ro" state data (read-only), "-x" RPC operations, and
"-n" notifications.</t>
<t>Symbols after data node names: "?" means an optional node, "!" a
container with presence, and "*" denotes a "list" or "leaf-list".</t>
<t>Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":").</t>
<t>Ellipsis ("...") stands for contents of subtrees that are not
shown.</t>
</list></t>
<figure>
<artwork>
module: ietf-rib-extension
augment /rt:routing/rt:routing-instance/rt:routing-protocols/
rt:routing-protocol/rt:static-routes/v4ur:ipv4/v4ur:route/
v4ur:next-hop/v4ur:next-hop-options:
+--:(multi-next-hop)
+--rw next-hop-entries* [interface address]
+--rw interface string
+--rw address inet:ipv4-address
+--rw preference? uint32
+--rw tag? uint32
augment /rt:routing/rt:routing-instance/rt:routing-protocols/
rt:routing-protocol/rt:static-routes/v6ur:ipv6/v6ur:route/
v6ur:next-hop/v6ur:next-hop-options:
+--:(multi-next-hop)
+--rw next-hop-entries* [interface address]
+--rw interface string
+--rw address inet:ipv6-address
+--rw preference? uint32
+--rw tag? uint32
augment /rt:routing/rt:routing-instance/rt:ribs/rt:rib:
+--rw next-hop-dampen-enable? boolean {next-hop-dampen}?
augment /rt:routing-state/rt:routing-instance/rt:ribs/rt:rib:
+--ro next-hop-dampen-enable? boolean
augment /rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/rt:routes/
rt:route:
+--ro metric? uint32
+--ro tag? uint32
augment /rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/rt:routes/
rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
+--ro metric? uint32
+--ro tag? uint32
+--ro repair-path
+--ro interface? leafref
+--ro address? inet:ip-address
+--ro metric? uint32
+--ro tag? uint32
augment /rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/rt:routes/
rt:route/rt:next-hop/rt:next-hop-options/rt:special-next-hop:
+--ro metric? uint32
+--ro tag? uint32
+--ro repair-path
+--ro interface? leafref
+--ro address? inet:ip-address
+--ro metric? uint32
+--ro tag? uint32
augment /rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/rt:routes/
rt:route/rt:next-hop/rt:next-hop-options:
+--:(multi-paths)
+--ro path-entries*
+--ro interface? leafref
+--ro address? inet:ip-address
+--ro metric? uint32
+--ro tag? uint32
+--ro repair-path
+--ro interface? leafref
+--ro address? inet:ip-address
+--ro metric? uint32
+--ro tag? uint32
</artwork>
</figure>
</section>
<section title="RIB Extensions YANG Model">
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "ietf-rib-extension@2015-10-16.yang"
module ietf-rib-extension {
namespace "urn:ietf:params:xml:ns:yang:ietf-rib-extension";
prefix rib;
import ietf-inet-types {
prefix "inet";
}
import ietf-routing {
prefix "rt";
}
import ietf-ipv4-unicast-routing {
prefix "v4ur";
}
import ietf-ipv6-unicast-routing {
prefix "v6ur";
}
organization
"Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
USA";
contact
"Acee Lindem - acee@cisco.com
Yingzhen QU - yiqu@cisco.com";
description
"This YANG module extends the generic data model for
RIB by augmenting the ietf-netmod-routing-cfg
model. It is intended that the module will be extended
by vendors to define vendor-specific RIB parameters.
";
revision 2015-10-16 {
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for RIB Extensions.";
}
feature next-hop-dampen {
description
"RIB next-hop dampening.";
}
grouping next-hop {
description
"Next-hop grouping.";
leaf interface {
type leafref {
path "/rt:routing-state/rt:routing-instance/rt:interfaces/"
+ "rt:interface";
}
description
"Outgoing interface.";
}
leaf address {
type inet:ip-address;
description
"Address of the next-hop.";
}
}
grouping attributes {
description
"Common attributes applicable to all paths.";
leaf metric {
type uint32;
description "route metric.";
}
leaf tag {
type uint32;
description "route tag.";
}
}
grouping path-attribute {
description
"Path attribute grouping.";
uses attributes;
container repair-path {
uses next-hop;
uses attributes;
description
"The IP Fast ReRoute (IPFRR) repair path.";
}
}
augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
+ "rt:routing-protocol/rt:static-routes/v4ur:ipv4/"
+ "v4ur:route/v4ur:next-hop/v4ur:next-hop-options"
{
description
"Augment recursive static route configuration.";
case multi-next-hop {
description
"Multiple next-hop options";
list next-hop-entries {
key "interface address";
leaf interface {
type string;
description
"Outgoing interface name.";
}
leaf address {
type inet:ipv4-address;
description
"Address of the next-hop.";
}
leaf preference {
type uint32;
default "1";
description "route preference.";
}
leaf tag {
type uint32;
default "0";
description "route tag.";
}
description
"List of multiple next hops.";
}
}
}
augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
+ "rt:routing-protocol/rt:static-routes/v6ur:ipv6/"
+ "v6ur:route/v6ur:next-hop/v6ur:next-hop-options"
{
description
"Augment recursive static route configuration.";
case multi-next-hop {
description
"Multiple next-hop options";
list next-hop-entries {
key "interface address";
leaf interface {
type string;
description
"Outgoing interface name.";
}
leaf address {
type inet:ipv6-address;
description
"Address of the next-hop.";
}
leaf preference {
type uint32;
default "1";
description "route preference.";
}
leaf tag {
type uint32;
default "0";
description "tag for this path.";
}
description
"List of multipath.";
}
}
}
augment "/rt:routing/rt:routing-instance/rt:ribs/rt:rib"
{
description
"Augment configuration for RIB dampening enable/disable.";
leaf next-hop-dampen-enable {
if-feature next-hop-dampen;
type boolean;
default true;
description "Enable rib next-hop dampening.";
}
}
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib"
{
description
"Augment operation state for RIB dampening enable/disable.";
leaf next-hop-dampen-enable {
type boolean;
description "Rib next-hop dampening state.";
}
}
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/"
+ "rt:routes/rt:route"
{
description
"Augment a route in RIB with tag.";
uses attributes;
}
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/"
+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:simple-next-hop"
{
description
"Add more parameters to a path.";
uses path-attribute;
}
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/"
+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:special-next-hop"
{
description
"Add more parameters to a path.";
uses path-attribute;
}
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/"
+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options"
{
description
"This case augments the 'next-hop-options' in the routing
model.";
case multi-paths {
description
"ecmp";
list path-entries {
uses next-hop;
uses path-attribute;
description
"List of multipaths.";
}
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section title="Security Considerations">
<t>The YANG model augmentations defined herein do not introduce any
security issues other than those already discussed in <xref target="ROUTING-CFG"/>,
and <xref target="NETCONF"/>. If confidentiality is desired, the underlying NETCONF communication
should be utilized as described in <xref target="NETCONF-SSH"/>.</t>
</section>
<section title="IANA Considerations">
<t> This document registers a URI in the IETF XML registry
<xref target="XML-REGISTRY"/>. Following the format in RFC 3688, the following
registration is requested to be made:
<list>
<t>URI: urn:ietf:params:xml:ns:yang:ietf-rib</t>
<t> Registrant Contact: The IESG.</t>
<t> XML: N/A, the requested URI is an XML namespace.</t>
<t>This document registers a YANG module in the YANG Module Names
registry <xref target="YANG"/>.</t>
<t>name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-rib
prefix: ietf-rib reference: RFC XXXX</t>
</list></t>
</section>
</middle>
<?rfc needLines="20"?>
<back>
<references title="Normative References">
<reference anchor="RFC-KEYWORDS">
<front>
<title>Key words for use in RFC's to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="YANG">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="Martin Bjorklund">
<organization>Tail-F Systems</organization>
</author>
<date month="October" year="2010" />
</front>
<seriesInfo name="RFC" value="6020" />
</reference>
<reference anchor="ROUTING-CFG">
<front>
<title>A YANG Data Model for Routing Management</title>
<author initials="L." surname="Lhothka" fullname="Lada Lhotka">
<organization>CZ.NIC</organization>
</author>
<author initials="A." surname="Lindem" fullname="Acee Lindem">
<organization>Cisco Systems</organization>
</author>
<date month="May" year="2015" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-routing-cfg-17.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="NETCONF">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="Rob Enns">
<organization>Juniper Networks</organization>
</author>
<author initials="M." surname="Bjorklund" fullname="Martin Bjorklund">
<organization>Tail-F Systems</organization>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
<organization>Jacobs University</organization>
</author>
<author initials="A." surname="Bierman" fullname="Andy Bierman">
<organization>Brocade</organization>
</author>
<date month="June" year="2011" />
</front>
<seriesInfo name="RFC" value="6241" />
</reference>
<reference anchor="NETCONF-SSH">
<front>
<title>Using NETCONF Protocol over Secure Shell (SSH)</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security, LLC</organization>
</author>
<date month="June" year="2011" />
</front>
<seriesInfo name="RFC" value="6242" />
</reference>
<reference anchor="XML-REGISTRY">
<front>
<title>The IETF XML Registry</title>
<author initials="M." surname="Mealling" fullname="Michael Mealling">
<organization>Verisign, Inc</organization>
</author>
<date month="January" year="2004" />
</front>
<seriesInfo name="BCP" value="81" />
<seriesInfo name="RFC" value="3688" />
</reference>
</references>
<?rfc needLines="100"?>
<section title="Acknowledgments">
<t>The RFC text was produced using Marshall Rose's xml2rfc tool.</t>
<t>The authors wish to thank Les Ginsberg, Krishna Deevi and Suyoung Yoon
for their helpful comments and suggestions.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:13 |