NETMOD L. Lhotka
Internet-Draft CESNET
Intended status: Standards Track March 03, 2011
Expires: September 4, 2011
A YANG Data Model for Routing Configuration
draft-lhotka-netmod-routing-cfg-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Lhotka Expires September 4, 2011 [Page 1]
Internet-Draft YANG Routing Configuration March 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Design of the Routing Data Model . . . . . . . . . . . . . . . 7
4.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Routing Protocol Instances . . . . . . . . . . . . . . . . 9
4.3.1. Defining New Routing Protocols . . . . . . . . . . . . 10
4.4. Route Pipes . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 12
5. Core Routing YANG Module . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Example Module for Routing Information Protocol . . . 26
A.1. Example YANG Module for Routing Information Protocol . . . 26
A.2. Sample Reply to the NETCONF <get> Message . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Lhotka Expires September 4, 2011 [Page 2]
Internet-Draft YANG Routing Configuration March 2011
1. Introduction
The NETCONF Data Modeling Language (NETMOD) Working Group has
completed the essential specifications for the YANG data modeling
language [RFC6020], common data types [RFC6021], and the
corresponding data modeling environment and tools [RFC6087],
[RFC6110]. The new NETMOD WG charter puts emphasis on the
development of a set of core YANG data models for the following
subsystems:
1. core system data model,
2. core interface data model,
3. core routing data model.
The initial version of the core interface data model (item 2) was
already published [YANG-IF].
This document contains an initial specification for item 3, 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.
Lhotka Expires September 4, 2011 [Page 3]
Internet-Draft YANG Routing Configuration March 2011
2. Terminology and Notation
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 [RFC2119].
The following terms are defined in [RFC4741]:
o client
o datastore
o message
o operation
o server
The following terms are defined in [RFC6020]:
o augment
o configuration data
o container
o data model
o data node
o data tree
o data type
o feature
o grouping
o identity
o instance identifier
o leaf-list
o list
o mandatory node
Lhotka Expires September 4, 2011 [Page 4]
Internet-Draft YANG Routing Configuration March 2011
o module
o operational state data
o RPC operation
o submodule
The following terms are defined in [XML-INFOSET]:
o attribute
o document
o document element
o element
o information set
o namespace
Lhotka Expires September 4, 2011 [Page 5]
Internet-Draft YANG Routing Configuration March 2011
3. Objectives
The initial design of the core routing data model was driven by the
following main objectives:
o The data model should be suitable for the common address families,
in particular IPv4 and IPv6.
o Simple routing setups, such as static routing, should be
configurable in a simple way, ideally without any need to define
additional YANG modules.
o 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.
o 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.
Lhotka Expires September 4, 2011 [Page 6]
Internet-Draft YANG Routing Configuration March 2011
4. Design of the Routing Data Model
The "ietf-routing" YANG module presented in Section 5 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.
+------------+
| 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 |
+----------+ +----------+
Figure 1: Example setup of the routing subsystem
Figure 1 shows an example of a more complicated setup:
o Along with the main routing table, which must always be present,
an additional routing table is defined.
o 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
Lhotka Expires September 4, 2011 [Page 7]
Internet-Draft YANG Routing Configuration March 2011
static pseudo-protocol).
o Routing tables may also be connected to each other through route
pipes and exchange routes in one or both directions.
o 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.
o Route exchanges along all connections may be controlled by means
of route filters denoted by "F" in the figure.
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.
4.1. Route
Routes are basic units of information in a routing system. The
"ietf-routing" module defines only the following essential route
parameters:
o route-type - permitted values are "unicast" (default), "multicast"
and "anycast".
o destination-prefix - IP prefix specifying the set of destination
addresses for which the route may be used. This parameter is
mandatory.
o next-hop - IP address of the adjacent router or host to which
packets with destination addresses belonging to destination-prefix
should be sent.
o outgoing-interface - network interface that should be used for
sending packets with destination addresses belonging to
destination-prefix.
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.
Routes are used in both configuration data, for example as manually
configured static routes, as well as in operational state data, for
Lhotka Expires September 4, 2011 [Page 8]
Internet-Draft YANG Routing Configuration March 2011
example as entries in routing tables.
4.2. Routing Tables
Routing tables are lists of routes complemented with administrative
data, namely:
o source-protocol - name of the routing protocol from which the
route arrived.
o last-modified - date and time of last modification, or
installation, of the route.
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.
The data model also defines an RPC operation, "delete-route" which
allows the client to immediately delete a specified route from a
routing table.
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.
4.3. Routing Protocol Instances
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.
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.
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.
Two independent route filters (see Section 4.5) may be defined for a
routing protocol instance to control the exchange of routes in both
Lhotka Expires September 4, 2011 [Page 9]
Internet-Draft YANG Routing Configuration March 2011
directions between the routing protocol instance and the connected
routing table:
o import filter controls which routes are passed from a routing
protocol instance to the routing table,
o export filter controls which routes the routing protocol instance
may receive from the connected routing table.
Note that, for historical reasons, the terms import and export are
used from the viewpoint of a routing table.
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.
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.
The "static" routing pseudo-protocol allows for specifying routes
manually. It can be configured in zero or more instances, although
typically one instance suffices.
4.3.1. Defining New Routing Protocols
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:
o 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".
o Additional route attributes MAY be defined. Their definitions
have to be inserted as operational state data by augmenting the
Lhotka Expires September 4, 2011 [Page 10]
Internet-Draft YANG Routing Configuration March 2011
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.
o 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.
The above steps are implemented by the example YANG module for the
RIP routing protocol in Appendix A. In particular, the module first
defines a new identity for the RIP protocol:
identity rip {
base rt:routing-protocol;
description "Identity for the RIP routing protocol.";
}
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":
augment "/rt:routing/rt:routing-protocol-instances/" +
"rt:routing-protocol-instance" {
container rip-configuration {
when "../rt:type='rip'";
...
}
}
4.4. Route Pipes
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.
The transport of routes from the "origin" table to the "recipient"
table may be controlled by means of a route filter (see Section 4.5).
If no filter is defined, all routes present in the "origin" table
MUST also appear in the "recipient" table.
Lhotka Expires September 4, 2011 [Page 11]
Internet-Draft YANG Routing Configuration March 2011
4.5. Route Filters
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.
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.
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.
Lhotka Expires September 4, 2011 [Page 12]
Internet-Draft YANG Routing Configuration March 2011
5. Core Routing YANG Module
<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.";
Lhotka Expires September 4, 2011 [Page 13]
Internet-Draft YANG Routing Configuration March 2011
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.";
}
Lhotka Expires September 4, 2011 [Page 14]
Internet-Draft YANG Routing Configuration March 2011
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.";
}
Lhotka Expires September 4, 2011 [Page 15]
Internet-Draft YANG Routing Configuration March 2011
/* 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.";
}
Lhotka Expires September 4, 2011 [Page 16]
Internet-Draft YANG Routing Configuration March 2011
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 {
Lhotka Expires September 4, 2011 [Page 17]
Internet-Draft YANG Routing Configuration March 2011
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;
Lhotka Expires September 4, 2011 [Page 18]
Internet-Draft YANG Routing Configuration March 2011
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;
Lhotka Expires September 4, 2011 [Page 19]
Internet-Draft YANG Routing Configuration March 2011
}
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.";
Lhotka Expires September 4, 2011 [Page 20]
Internet-Draft YANG Routing Configuration March 2011
}
}
}
/* 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>
Lhotka Expires September 4, 2011 [Page 21]
Internet-Draft YANG Routing Configuration March 2011
6. IANA Considerations
This document requests the following registration of a namespace URI
in the IETF XML registry [RFC3688]:
-----------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-routing
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
-----------------------------------------------------
Lhotka Expires September 4, 2011 [Page 22]
Internet-Draft YANG Routing Configuration March 2011
7. Security Considerations
TBD.
Lhotka Expires September 4, 2011 [Page 23]
Internet-Draft YANG Routing Configuration March 2011
8. Acknowledgments
The author wishes to thank the following individuals who provided
helpful suggestions and/or comments on this document: TBD.
Lhotka Expires September 4, 2011 [Page 24]
Internet-Draft YANG Routing Configuration March 2011
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020,
September 2010.
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6021, September 2010.
[XML-INFOSET]
Tobin, R. and J. Cowan, "XML Information Set (Second
Edition)", World Wide Web Consortium Recommendation REC-
xml-infoset-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[YANG-IF] Bjorklund, M., "A YANG Data Model for Interface
Configuration", draft-bjorklund-netmod-interfaces-cfg-00
(work in progress), December 2010.
9.2. Informative References
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, January 2011.
[RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema
Definition Languages and Validating NETCONF Content",
RFC 6110, February 2011.
Lhotka Expires September 4, 2011 [Page 25]
Internet-Draft YANG Routing Configuration March 2011
Appendix A. Example Module for Routing Information Protocol
This appendix demonstrates how the "ietf-routing" module can be
extended to support a new routing protocol. Appendix A.1 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 [YANG-IF].
Appendix A.2 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 [YANG-IF].
A.1. Example YANG Module for Routing Information Protocol
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";
Lhotka Expires September 4, 2011 [Page 26]
Internet-Draft YANG Routing Configuration March 2011
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.";
}
}
}
A.2. Sample Reply to the NETCONF <get> Message
<?xml version="1.0" encoding="utf-8"?>
Lhotka Expires September 4, 2011 [Page 27]
Internet-Draft YANG Routing Configuration March 2011
<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>
Lhotka Expires September 4, 2011 [Page 28]
Internet-Draft YANG Routing Configuration March 2011
<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>
Lhotka Expires September 4, 2011 [Page 29]
Internet-Draft YANG Routing Configuration March 2011
<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>
Lhotka Expires September 4, 2011 [Page 30]
Internet-Draft YANG Routing Configuration March 2011
Author's Address
Ladislav Lhotka
CESNET
Email: lhotka@cesnet.cz
Lhotka Expires September 4, 2011 [Page 31]