One document matched: draft-lhotka-netmod-routing-cfg-00.xml
<?xml version="1.0"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc ipr="trust200902" category="std"
docName="draft-lhotka-netmod-routing-cfg-00">
<front>
<title abbrev="YANG Routing Configuration">A YANG Data Model for
Routing Configuration</title>
<author initials="L." surname="Lhotka" fullname="Ladislav Lhotka">
<organization>CESNET</organization>
<address>
<email>lhotka@cesnet.cz</email>
</address>
</author>
<date day="03" month="March" year="2011"/>
<area>Operations and Management</area>
<workgroup>NETMOD</workgroup>
<abstract>
<t>This document contains a specification of a core YANG data
model for IP routing configuration. It is expected that this
module will serve as a basis for further development of data
models for individual routing protocols and other related
functions. The present data model defines the building blocks for
such configurations - routes and routing tables, routing protocol
instances, route filters and route pipes.</t>
</abstract>
</front>
<middle>
<section anchor="sec.introduction" title="Introduction">
<t>The NETCONF Data Modeling Language (NETMOD) Working Group has
completed the essential specifications for the YANG data modeling
language <xref target="RFC6020"/>, common data types <xref
target="RFC6021"/>, and the corresponding data modeling
environment and tools <xref target="RFC6087"/>, <xref
target="RFC6110"/>. The new NETMOD WG charter puts emphasis on the
development of a set of core YANG data models for the following
subsystems:
<list style="numbers">
<t>core system data model,</t>
<t anchor="it.ifmodel">core interface data model,</t>
<t anchor="it.rout">core routing data model.</t>
</list>
The initial version of the core interface data model (item <xref
format="counter" target="it.ifmodel"/>) was already published
<xref target="YANG-IF"/>.</t>
<t>This document contains an initial specification for item <xref
format="counter" target="it.rout"/>, namely the "ietf-routing"
YANG module representing the core routing data model. While the
module can be directly used for simple devices with static
routing, its main purpose is to provide basic building blocks for
more complicated setups involving multiple routing protocols and
advanced functions, such as route filtering and policy routing. To
this end, it is expected that this module will be augmented by
numerous modules developed by other IETF working groups.</t>
</section>
<section anchor="term-not" title="Terminology and 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="RFC2119"/>.</t>
<t>The following terms are defined in <xref target="RFC4741"/>:
<list style="symbols">
<t>client</t>
<t>datastore</t>
<t>message</t>
<t>operation</t>
<t>server</t>
</list></t>
<t>The following terms are defined in <xref target="RFC6020"/>:
<list style="symbols">
<t>augment</t>
<t>configuration data</t>
<t>container</t>
<t>data model</t>
<t>data node</t>
<t>data tree</t>
<t>data type</t>
<t>feature</t>
<t>grouping</t>
<t>identity</t>
<t>instance identifier</t>
<t>leaf-list</t>
<t>list</t>
<t>mandatory node</t>
<t>module</t>
<t>operational state data</t>
<t>RPC operation</t>
<t>submodule</t>
</list></t>
<t>The following terms are defined in <xref target="XML-INFOSET"/>:
<list style="symbols">
<t>attribute</t>
<t>document</t>
<t>document element</t>
<t>element</t>
<t>information set</t>
<t>namespace</t>
</list></t>
</section>
<section anchor="sec.objectives" title="Objectives">
<t>The initial design of the core routing data model was driven by
the following main objectives:
<list style="symbols">
<t>The data model should be suitable for the common address
families, in particular IPv4 and IPv6.</t>
<t>Simple routing setups, such as static routing, should be
configurable in a simple way, ideally without any need to define
additional YANG modules.</t>
<t>On the other hand, the framework defined by the module must
allow for complicated setups involving multiple routing tables
and multiple routing protocols, as well as controlled
redistributions of routing information.</t>
<t>Device vendors will want to map the data models built on this
generic framework to their proprietary data models and
configuration interfaces. Therefore, the framework should be
flexible enough to facilitate such a mapping and accommodate
data models with different logic.</t>
</list>
</t>
</section>
<section anchor="sec.design"
title="Design of the Routing Data Model">
<t>The "ietf-routing" YANG module presented in <xref
target="sec.module"/> defines a data modeling framework with
several essential components: routes, routing tables, routing
protocol instances, route filters and route pipes. By combining
these components in various ways, and filling them with
appropriate content models defined in other modules, a broad range
of routing setups can be covered.</t>
<figure anchor="fig.exsetup"
title="Example setup of the routing subsystem">
<artwork><![CDATA[
+------------+
| kernel FIB |
+------------+
^ |
| v
+---+ +---+
| F | | F |
+---+ +---+
^ |
| v
+--------------+ +---+ +--------------+
+--------+ | |<---| F |<---| |
| static | +---+ | main | +---+ | additional |
| routes |--->| F |--->| routing | | routing |
+--------+ +---+ | table | +---+ | table |
| |--->| F |--->| |
+--------------+ +---+ +--------------+
^ | ^ |
| v | v
+---+ +---+ +---+ +---+
| F | | F | | F | | F |
+---+ +---+ +---+ +---+
^ | ^ |
| v | v
+----------+ +----------+
| routing | | routing |
| protocol | | protocol |
+----------+ +----------+
]]></artwork>
</figure>
<t><xref target="fig.exsetup"/> shows an example of a more
complicated setup:
<list style="symbols">
<t>Along with the main routing table, which must always be
present, an additional routing table is defined.</t>
<t>Each routing protocol instance, including the static
pseudo-protocol instance, is connected to exactly one routing
table with which it can exchange routes (in both directions,
except for the static pseudo-protocol).</t>
<t>Routing tables may also be connected to each other through
route pipes and exchange routes in one or both directions.</t>
<t>The main routing table exchanges routes with the forwarding
information base (FIB) in the operating system kernel as
follows: active routes from the main routing table are installed
in the FIB and used for packet forwarding, and automatic routes
set up by the kernel (for example, direct routes to connected
networks) are passed to the main routing table.</t>
<t>Route exchanges along all connections may be controlled by
means of route filters denoted by "F" in the figure.</t>
</list></t>
<t>All configuration and operational state data defined by the
"ietf-routing" module apear inside the "routing" container. The
following subsections describe the individual components of the
core routing framework.</t>
<section anchor="sec.route" title="Route">
<t>Routes are basic units of information in a routing
system. The "ietf-routing" module defines only the following
essential route parameters:
<list style="symbols">
<t>route-type - permitted values are "unicast" (default), "multicast"
and "anycast".</t>
<t>destination-prefix - IP prefix specifying the set of
destination addresses for which the route may be used. This
parameter is mandatory.</t>
<t>next-hop - IP address of the adjacent router or host to
which packets with destination addresses belonging to
destination-prefix should be sent.</t>
<t>outgoing-interface - network interface that should be used
for sending packets with destination addresses belonging to
destination-prefix.</t>
</list>
</t>
<t>The above list of route parameters is sufficient for a
simple static route configuration. It is expected that future
modules defining routing protocols will add other route
attributes such as metrics or preferences.</t>
<t>Routes are used in both configuration data, for example as
manually configured static routes, as well as in operational
state data, for example as entries in routing tables.</t>
</section>
<section anchor="sec.rtables" title="Routing Tables">
<t>Routing tables are lists of routes complemented with
administrative data, namely:
<list style="symbols">
<t>source-protocol - name of the routing protocol from which
the route arrived.</t>
<t>last-modified - date and time of last modification, or
installation, of the route.</t>
</list></t>
<t>In the core routing data model, routing tables are
represented as operational state data. Routing protocol
operations result in route additions, removals and
modifications. This also includes manipulations via the "static"
pseudo-protocol.</t>
<t>The data model also defines an RPC operation, "delete-route"
which allows the client to immediately delete a specified route
from a routing table.</t>
<t>Every compliant implementation MUST automatically configure
the main routing table. Additional routing tables MAY be
configured by adding their unique names to the
"configured-routing-tables" leaf-list.
</t>
</section>
<section anchor="sec.proto"
title="Routing Protocol Instances">
<t>The "ietf-routing" module provides an open-ended framework for
defining multiple routing protocol instances. Each of them is
identified by a unique name and MUST be assigned a type from a
selection which includes all routing protocol types supported by
the server, such as RIP, OSPF or BGP.</t>
<t>Each routing protocol instance is connected to exactly one
routing table. By default, every routing protocol instance is
connected to the main routing table, but any routing protocol
instance can be configured to use a different routing table,
provided such an extra table is configured.</t>
<t>Routes learned from the network by a routing protocol
instance are passed to the connected routing table and vice
versa - routes appearing in a routing table may be passed to any
routing protocol connected to the table and advertised by that
protocol to the network.</t>
<t>Two independent route filters (see <xref
target="sec.filters"/>) may be defined for a routing protocol
instance to control the exchange of routes in both directions
between the routing protocol instance and the connected routing
table:
<list style="symbols">
<t>import filter controls which routes are passed from a
routing protocol instance to the routing table,</t>
<t>export filter controls which routes the routing protocol
instance may receive from the connected routing table.</t>
</list>
Note that, for historical reasons, the terms import and export
are used from the viewpoint of a routing table.</t>
<t>The "ietf-routing" module defines two special routing
protocols - "direct" and "static". Both are in fact
pseudo-protocols, which means that they are confined to the
local server and do not exchange any routing information with
neighboring routers. Routes from both "direct" and "static"
protocol instances are passed to the connected routing table
(subject to route filters, if any), but an exchange in the
opposite direction is not allowed.</t>
<t>The "direct" pseudo-protocol MUST exist in exactly one
instance in any server implementation. It is the source for
routes to directly connected networks (so-called direct
routes). Such routes are supplied by the operating system kernel
based on the detected and configured network interfaces, and
they usually appear in the main routing table. However, using
the framework defined in this document, the target routing table
for direct routes can be changed by connecting the "direct"
protocol instance to a non-default routing table, and the direct
routes can also be filtered before they appear in the routing
table.</t>
<t>The "static" routing pseudo-protocol allows for specifying
routes manually. It can be configured in zero or more instances,
although typically one instance suffices.</t>
<section anchor="sec.newproto"
title="Defining New Routing Protocols">
<t>It is expected that other YANG modules will create data
models for additional routing protocol types. In order to do
so, the new module has to define the protocol-specific
information and fit it to the core routing framework in the
following way:
<list style="symbols">
<t>A new identity MUST be defined for the routing protocol
and its base identity set to "routing-protocol", or to an
identity derived from "routing-protocol".</t>
<t>Additional route attributes MAY be defined. Their
definitions have to be inserted as operational state data by
augmenting the definition of "route" under
"routing-table". Naturally, routes (including the extra
attributes) may be used in configuration data, too, as
demonstrated by the "static" pseudo-protocol.</t>
<t>The recommended way of defining configuration data
specific to the new protocol is to augment the
"routing-protocol-instance" list entry with a container that
encapsulates the configuration hierarchy of the new
protocol. The 'augment' statement SHOULD be made conditional
by using a 'when' substatement requiring that the new nodes
be used only if the "type" leaf node is equal to the new
protocol's identity.</t>
</list></t>
<t>The above steps are implemented by the example YANG module
for the RIP routing protocol in <xref target="app.rip"/>. In
particular, the module first defines a new identity for the
RIP protocol:</t>
<figure>
<artwork><![CDATA[
identity rip {
base rt:routing-protocol;
description "Identity for the RIP routing protocol.";
}]]></artwork>
</figure>
<t>RIP-specific configuration data are then integrated
into the "routing-protocol-instance" node by using the
following 'augment' statement, which applies only for routing
protocol instances whose type is "rip":</t>
<figure>
<artwork><![CDATA[
augment "/rt:routing/rt:routing-protocol-instances/" +
"rt:routing-protocol-instance" {
container rip-configuration {
when "../rt:type='rip'";
...
}
}]]></artwork>
</figure>
</section>
</section>
<section anchor="sec.pipes" title="Route Pipes">
<t>Route pipes are unidirectional links connecting pairs of
routing tables that allow for passing routes from one routing
table to another. Each route pipe is identified by a unique name
and has two mandatory parameters, "origin" and "recipient", that
specify the two routing tables that are being connected.</t>
<t>The transport of routes from the "origin" table to the
"recipient" table may be controlled by means of a route filter
(see <xref target="sec.filters"/>). If no filter is defined, all
routes present in the "origin" table MUST also appear in the
"recipient" table.</t>
</section>
<section anchor="sec.filters" title="Route Filters">
<t>The "ietf-routing" module provides a skeleton for defining
route filters that can be used to restrict the set of routes
being exchanged between a routing protocol instance and a
routing table, or between two routing tables connected through a
route pipe. Route filters may also manipulate routes, i.e., add,
delete, or modify their properties.</t>
<t>By itself, the route filtering framework defined in the
"ietf-routing" module allows to establish only the two
extreme routing policies in which either all routes are allowed
or all routes are denied. It is expected that a real route
filtering framework (or several alternative frameworks) will be
developed separately.</t>
<t>Each route filter is identified by a unique name. Its type
may be specified by the "type" identity reference - this opens
the space for multiple route filtering framework
implementations. The only route filter type defined in the
"ietf-routing" module carries the default "route-filter"
identity, and represents the "deny all" route filtering
policy.</t>
</section>
</section>
<section anchor="sec.module"
title="Core Routing YANG Module">
<figure>
<artwork><![CDATA[<CODE BEGINS> file "ietf-routing@2011-03-03.yang"
module ietf-routing {
namespace "urn:ietf:params:xml:ns:yang:ietf-routing";
prefix rt;
import ietf-yang-types {
prefix yang;
}
import ietf-inet-types {
prefix inet;
}
import ietf-interfaces {
prefix if;
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens
<mailto:david.kessens@nsn.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Ladislav Lhotka
<mailto:lhotka@cesnet.cz>";
description
"This module contains YANG definitions for basic
configuration of IP routing.
It is immediately usable for a device that needs just a single
routing table populated with static routes.
On the other hand, the framework is designed to handle arbitrarily
complex configurations with any number of routing tables and
various routing protocols (in multiple instances).
Every compliant implementation MUST support IPv4 unicast routing
and implement at least one (main) routing table, which is
connected to the OS kernel forwarding information base.";
revision 2011-03-03;
/* Features */
feature ipv6-routing {
description
"This feature MUST be advertised by devices supporting IPv6
routing. Such a device MUST implement at least one extra routing
table to which all IPv6 unicast routing protocols are connected
by default.";
}
feature ipv4-multicast-routing {
description
"This feature MUST be set by devices supporting IPv4
multicast routing. Such a device MUST implement at least one
extra routing table to which all IPv6 multicast routing
protocols are connected by default.";
}
feature ipv6-multicast-routing {
description
"This feature MUST be set by devices supporting IPv6
multicast routing. Such a device MUST implement at least one
extra routing table to which all IPv6 multicast routing
protocols are connected by default.";
}
/* Identities */
identity address-family {
description
"Base identity from which address family identities are
derived.";
}
identity af-ipv4 {
base address-family;
description
"IPv4 address family.";
}
identity af-ipv6 {
base address-family;
description
"IPv6 address family.";
}
identity routing-protocol {
description
"Base identity from which routing protocol identities are
derived.";
}
identity direct {
base routing-protocol;
description
"Identity for the pseudo-protocol providing routes to
directly connected networks. An implementation MUST preconfigure
an instance of this pseudo-protocol.";
}
identity static {
base routing-protocol;
description
"Identity for static routing pseudo-protocol.";
}
identity route-filter {
description
"Base identity for route filters. It also represents the
empty route filter that blocks everything.";
}
identity route-type {
description
"Base identity for route types.";
}
identity unicast {
base route-type;
description
"Unicast route type.";
}
identity multicast {
base route-type;
description
"Multicast route type.";
}
identity anycast {
base route-type;
description
"Anycast route type.";
}
/* Type definitions */
typedef routing-table-ref {
type leafref {
path "/routing/configured-routing-tables/name";
}
description
"This type represents a reference to a configured routing
table.";
}
typedef routing-protocol-instance-ref {
type leafref {
path "/routing/routing-protocol-instances/" +
"routing-protocol-instance/name";
}
description
"This type represents a reference to a configured routing
protocol instance.";
}
typedef route-filter-ref {
type leafref {
path "/routing/route-filters/route-filter/name";
}
description
"This type represents a reference to a configured route
filter.";
}
/* Groupings */
grouping ip-route-content {
description
"Components of an IP route.";
leaf type {
type identityref {
base route-type;
}
default "unicast";
}
leaf destination-prefix {
type inet:ip-prefix;
mandatory true;
description
"The set of destination addresses for which the route may
be used.";
}
leaf next-hop {
type inet:ip-address;
description
"IP address of the host or router to which packets whose
address matches 'destination-prefix' are to be forwarded.";
}
leaf outgoing-interface {
type if:interface-ref;
description
"Name of the outgoing interface. This parameter is mainly
used in direct routes.";
}
}
rpc delete-route {
description
"This operation deletes a route with given parameters from
a specified routing table. <ok> is returned by the server
upon successful completion.";
input {
container route {
description
"All routes that match this parameter MUST be deleted
from the target routing table.";
uses ip-route-content;
}
leaf routing-table {
type routing-table-ref;
description
"This parameter specifies the target routing
table.";
}
}
}
/* Data tree */
container routing {
description
"IP routing parameters.";
container configured-routing-tables {
description
"Names of configured routing tables. Their contents are
available as operational state data under 'routing-tables'. At
least one (main) table MUST be configured for every supported
address family. This default routing table is usually
connected to the main kernel forwarding table.";
leaf-list name {
type string;
min-elements 1;
}
}
container routing-protocol-instances {
description
"Container for configured routing protocol instances.
Every implementation MUST preconfigure the 'direct'
pseudo-protocol instance providing the routes to directly
connected networks.";
list routing-protocol-instance {
key "name";
container static-routes {
when "../type='static'";
description
"Configuration of a 'static' pseudo-protocol instance
consists of a list of routes.";
list static-route {
key "id";
leaf id {
type string;
}
leaf description {
type string;
}
uses ip-route-content;
}
}
leaf name {
type string;
}
leaf description {
type string;
}
leaf address-family {
type identityref {
base address-family;
}
default "af-ipv4";
description
"Address family used by the routing protocol instance.";
}
leaf type {
type identityref {
base routing-protocol;
}
mandatory true;
description
"Type of the routing protocol.";
}
leaf routing-table {
type routing-table-ref;
description
"The routing table to which the protocol instance is
connected. By default it is the main routing table for the
given address family.";
}
leaf import-filter {
type route-filter-ref;
description
"Reference to a route filter that is used for
filtering routes passed from this routing protocol instance
to the routing table specified by the 'routing-table'
sibling node. If this leaf is not present, the behavior is
protocol-specific, but typically it means that all routes
are accepted.";
}
leaf export-filter {
type route-filter-ref;
description
"Reference to a route filter that is used for
filtering routes passed from the routing table specified
by the 'routing-table' sibling to this routing protocol
instance. If this leaf is not present, the behavior is
protocol-specific - typically it means that all routes
are accepted, except for the 'direct' and 'static'
pseudo-protocols which accept no routes from
anywhere.";
}
}
}
container route-pipes {
description
"Route pipes facilitate transport of routes between pairs
of routing tables.";
list route-pipe {
key "name";
description
"A route-pipe is a unidirectional connection between
'origin' and 'recipient'.";
leaf name {
type string;
}
leaf description {
type string;
}
leaf origin {
type routing-table-ref;
mandatory true;
description
"The originating routing-table.";
}
leaf recipient {
type routing-table-ref;
mandatory true;
description
"The receiving routing-table.";
}
leaf route-filter {
type route-filter-ref;
description
"All routes passing through the route pipe are filtered by
the route filter referred to by this leaf. If it is not
present, all routes from 'origin' are passed to
'destination'.";
}
}
}
container route-filters {
description
"Non-trivial route filters are expected to be defined in
other modules.";
list route-filter {
key "name";
description
"A route filter is used for filtering routes between
routing protocol instances and routing tables (import
filter) and vice versa (export filter), and in route pipes
that connect pairs of routing tables.";
leaf name {
type string;
}
leaf description {
type string;
}
leaf type {
type identityref {
base route-filter;
}
default "route-filter";
description
"Type of the route-filter. The default value
represents an all-blocking filter.";
}
}
}
/* Operational state data */
container routing-tables {
config false;
description
"Routing tables and their contents.";
list routing-table {
min-elements 1;
description
"Exactly one routing table MUST be present for every 'name'
entry appearing in '/routing/configured-routing-tables'.";
leaf name {
type routing-table-ref;
}
leaf address-family {
type identityref {
base address-family;
}
default "af-ipv4";
description
"Address family of all routes in the routing table.";
}
list route {
leaf source-protocol {
type routing-protocol-instance-ref;
description
"Protocol instance from which the route comes.";
}
leaf last-modified {
type yang:date-and-time;
description
"Time stamp of the last modification of the
route. If the route was never modified, it is the time
when the route was inserted to the routing table.";
}
uses ip-route-content;
}
}
}
}
}
<CODE ENDS>]]></artwork>
</figure>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document requests the following registration of
a namespace URI in the IETF XML registry <xref
target="RFC3688"/>:</t>
<figure>
<artwork>
-----------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-routing
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
-----------------------------------------------------
</artwork>
</figure>
</section>
<section anchor="sec-cons" title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The author wishes to thank the following individuals who
provided helpful suggestions and/or comments on this document:
TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to
Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization/>
</author>
<date year='1997' month='March' />
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723'
target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
</reference>
<reference anchor='RFC3688'>
<front>
<title>The IETF XML Registry</title>
<author initials='M.' surname='Mealling' fullname='M. Mealling'>
<organization/></author>
<date year='2004' month='January' />
</front>
<seriesInfo name='BCP' value='81' />
<seriesInfo name='RFC' value='3688' />
<format type='TXT' octets='17325'
target='ftp://ftp.isi.edu/in-notes/rfc3688.txt' />
</reference>
<reference anchor='RFC4741'>
<front>
<title>NETCONF Configuration Protocol</title>
<author initials='R.' surname='Enns' fullname='R. Enns'>
<organization /></author>
<date year='2006' month='December' />
</front>
<seriesInfo name='RFC' value='4741' />
<format type='TXT' octets='173914'
target='http://www.ietf.org/rfc/rfc4741.txt' />
</reference>
<reference anchor='XML-INFOSET'
target='http://www.w3.org/TR/2004/REC-xml-infoset-20040204'>
<front>
<title>XML Information Set (Second Edition)</title>
<author initials='R.' surname='Tobin' fullname='Richard Tobin'>
<organization />
</author>
<author initials='J.' surname='Cowan' fullname='John Cowan'>
<organization />
</author>
<date month='February' day='4' year='2004' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation'
value='REC-xml-infoset-20040204' />
<format type='HTML'
target='http://www.w3.org/TR/2004/REC-xml-infoset-20040204' />
</reference>
<reference anchor='RFC6020'>
<front>
<title>YANG - A Data Modeling Language for Network
Configuration Protocol (NETCONF)</title>
<author role="editor" initials='M' surname='Bjorklund'
fullname='Martin Bjorklund'>
<organization>Tail-f Systems</organization>
</author>
<date month='September' year='2010' />
</front>
<seriesInfo name='RFC' value='6020'/>
<format type='HTML'
target='http://tools.ietf.org/html/rfc6020' />
</reference>
<reference anchor='RFC6021'>
<front>
<title>Common YANG Data Types</title>
<author role="editor" initials='J.' surname='Schoenwaelder'
fullname='Juergen Schoenwaelder'>
<organization />
</author>
<date month='September' year='2010' />
</front>
<seriesInfo name='RFC'
value='6021' />
<format type='HTML'
target='http://tools.ietf.org/html/rfc6021'/>
</reference>
<reference anchor='YANG-IF'>
<front>
<title>A YANG Data Model for Interface Configuration</title>
<author initials='M' surname='Bjorklund'
fullname='Martin Bjorklund'>
<organization />
</author>
<date month='December' day='8' year='2010' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-bjorklund-netmod-interfaces-cfg-00' />
<format type='HTML'
target='http://tools.ietf.org/html/draft-bjorklund-netmod-interfaces-cfg-00' />
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC6087'>
<front>
<title>Guidelines for Authors and Reviewers of YANG Data Model
Documents</title>
<author initials='A.' surname='Bierman'
fullname='Andy Bierman'>
<organization />
</author>
<date month='January' year='2011' />
</front>
<seriesInfo name='RFC'
value='6087' />
<format type='HTML'
target='http://tools.ietf.org/html/rfc6087'/>
</reference>
<reference anchor='RFC6110'>
<front>
<title>Mapping YANG to Document Schema Definition Languages
and Validating NETCONF Content</title>
<author role="editor" initials='L.' surname='Lhotka'
fullname='Ladislav Lhotka'>
<organization />
</author>
<date month='February' year='2011' />
</front>
<seriesInfo name='RFC'
value='6110' />
<format type='HTML'
target='http://tools.ietf.org/html/rfc6110'/>
</reference>
</references>
<section anchor="app.rip"
title="Example Module for Routing Information Protocol">
<t>This appendix demonstrates how the "ietf-routing" module can be
extended to support a new routing protocol. <xref
target="app.rip-yang"/> contains a YANG module that is used for
this purpose. It is intended only as an illustration and not as a
real definition of a data model for the RIP routing protocol. This
module also imports the "ietf-interfaces" module defined in <xref
target="YANG-IF"/>.</t>
<t><xref target="app.rip-xml"/> then contains a complete instance
XML document - a reply to the NETCONF <get> message from a
server that uses the RIP protocol as well as static routing. A
route filter is also defined in order to prevent static routes to
private networks from being redistributed to RIP. The instance
document also uses data nodes from the two example YANG modules
"ex-ethernet" and "ex-ip" defined in <xref target="YANG-IF"/>.</t>
<section anchor="app.rip-yang"
title="Example YANG Module for Routing Information
Protocol">
<figure>
<artwork>
<![CDATA[module example-rip {
namespace "http://example.com/rip";
prefix rip;
import ietf-interfaces {
prefix if;
}
import ietf-routing {
prefix rt;
}
identity rip {
base rt:routing-protocol;
description
"Identity for the RIP routing protocol.";
}
typedef rip-metric {
type uint8 {
range "0..16";
}
}
augment "/rt:routing/rt:routing-protocol-instances/" +
"rt:routing-protocol-instance" {
when "rt:type='rip:rip'";
container rip-configuration {
container rip-interfaces {
list rip-interface {
key "name";
leaf name {
type if:interface-ref;
}
leaf enabled {
type boolean;
default "true";
}
leaf metric {
type rip-metric;
default "1";
}
/* Additional per-interface RIP configuration */
}
}
leaf update-interval {
type uint8 {
range "10..60";
}
units "seconds";
default "30";
description
"Time interval between periodic updates.";
}
/* Additional RIP configuration */
}
}
augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:route" {
when "../../../rt:routing-protocol-instances/" +
"rt:routing-protocol-instance[rt:name=" +
"current()/rt:source-protocol]/rt:type='rip:rip'";
description
"RIP-specific route components.";
leaf metric {
type rip-metric;
}
leaf tag {
type uint16;
default "0";
description
"This leaf may be used to carry additional info, e.g. AS
number.";
}
}
}
]]></artwork>
</figure>
</section>
<section anchor="app.rip-xml"
title="Sample Reply to the NETCONF <get> Message">
<figure>
<artwork>
<![CDATA[<?xml version="1.0" encoding="utf-8"?>
<nc:rpc-reply
message-id="101"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:eth="http://example.com/ethernet"
xmlns:ip="http://example.com/ip"
xmlns:rip="http://example.com/rip"
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<nc:data>
<if:interfaces>
<if:interface>
<if:name>eth0</if:name>
<if:type>eth:ethernet</if:type>
<if:location>05:00.0</if:location>
<ip:ip>
<ip:address>
<ip:ip>192.0.2.1</ip:ip>
<ip:prefix-length>24</ip:prefix-length>
</ip:address>
</ip:ip>
</if:interface>
<if:interface>
<if:name>eth1</if:name>
<if:type>eth:ethernet</if:type>
<if:location>05:00.1</if:location>
<ip:ip>
<ip:address>
<ip:ip>192.168.1.1</ip:ip>
<ip:prefix-length>24</ip:prefix-length>
</ip:address>
</ip:ip>
</if:interface>
</if:interfaces>
<routing>
<configured-routing-tables>
<name>rt0</name>
</configured-routing-tables>
<routing-protocol-instances>
<routing-protocol-instance>
<name>direct</name>
<type>direct</type>
</routing-protocol-instance>
<routing-protocol-instance>
<name>st0</name>
<description>
Static routing is used for the internal network.
</description>
<type>static</type>
<static-routes>
<static-route>
<id>id-6378</id>
<destination-prefix>192.168.2.0/24</destination-prefix>
<next-hop>192.168.1.254</next-hop>
</static-route>
</static-routes>
</routing-protocol-instance>
<routing-protocol-instance>
<name>rip0</name>
<type>rip:rip</type>
<export-filter>to-rip</export-filter>
<rip:rip-configuration>
<rip:rip-interfaces>
<rip:rip-interface>
<rip:name>eth0</rip:name>
</rip:rip-interface>
</rip:rip-interfaces>
</rip:rip-configuration>
</routing-protocol-instance>
</routing-protocol-instances>
<route-filters>
<route-filter>
<name>to-rip</name>
<description>
Block redistribution of static routes.
</description>
</route-filter>
</route-filters>
<routing-tables>
<routing-table>
<name>rt0</name>
<route>
<destination-prefix>192.168.1.0/24</destination-prefix>
<source-protocol>direct</source-protocol>
<outgoing-interface>eth0</outgoing-interface>
<last-modified>2010-02-24T17:11:23+01:00</last-modified>
</route>
<route>
<destination-prefix>192.168.2.0/24</destination-prefix>
<source-protocol>st0</source-protocol>
<next-hop>192.168.1.254</next-hop>
<rip:tag>64500</rip:tag>
<last-modified>2010-02-24T17:11:27+01:00</last-modified>
</route>
<route>
<destination-prefix>0.0.0.0/0</destination-prefix>
<next-hop>192.0.2.2</next-hop>
<rip:metric>2</rip:metric>
<rip:tag>64500</rip:tag>
<source-protocol>rip0</source-protocol>
<last-modified>2010-03-03T13:00:23+01:00</last-modified>
</route>
</routing-table>
</routing-tables>
</routing>
</nc:data>
</nc:rpc-reply>]]></artwork>
</figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:37:41 |