draft-ietf-netmod-routing-cfg-00.txt   draft-ietf-netmod-routing-cfg-01.txt 
NETMOD L. Lhotka NETMOD L. Lhotka
Internet-Draft CESNET Internet-Draft CESNET
Intended status: Standards Track April 27, 2011 Intended status: Standards Track September 23, 2011
Expires: October 29, 2011 Expires: March 26, 2012
A YANG Data Model for Routing Configuration A YANG Data Model for Routing Configuration
draft-ietf-netmod-routing-cfg-00 draft-ietf-netmod-routing-cfg-01
Abstract Abstract
This document contains a specification of two YANG modules that This document contains a specification of three YANG modules that
together provide a data model for essential configuration of a together provide a data model for essential configuration of a
routing subsystem. It is expected that this module will serve as a routing subsystem. It is expected that this module will serve as a
basis for further development of data models for individual routing basis for further development of data models for individual routing
protocols and other related functions. The present data model protocols and other related functions. The present data model
defines the building blocks for such configurations - routing defines the common building blocks for such configurations - router
processes, routes and routing tables, routing protocol instances and instances, routes, routing tables, routing protocols and route
route filters. filters.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 29, 2011. This Internet-Draft will expire on March 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4
2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Design of the Core Routing Data Model . . . . . . . . . . 7 4. The Design of the Core Routing Data Model . . . . . . . . . . 7
4.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Routing Protocol Instances . . . . . . . . . . . . . . . . 10 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Defining New Routing Protocols . . . . . . . . . . . . 11 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 12
4.4. Route Filters . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. Defining New Routing Protocols . . . . . . . . . . . . 13
4.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 15
5. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 15 4.6. RPC Operation . . . . . . . . . . . . . . . . . . . . . . 16
6. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 24 5. IANA AFN and SAFI YANG Module . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 34
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix A. Example - Adding a New Routing Protocol . . . . . . . 37 11.1. Normative References . . . . . . . . . . . . . . . . . . . 42
A.1. Example YANG Module for Routing Information Protocol . . . 37 11.2. Informative References . . . . . . . . . . . . . . . . . . 42
A.2. Sample Reply to the NETCONF <get> Message . . . . . . . . 38 Appendix A. Example - Adding a New Routing Protocol . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.1. Example YANG Module for Routing Information
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Sample Reply to the NETCONF <get> Message . . . . . . . . 45
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50
B.1. Changes Between Versions -00 and -01 . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document contains an initial specification of two YANG modules, This document contains an initial specification of three YANG
"ietf-routing" and "ietf-ipv4-unicast-routing", that together define modules:
the so-called core routing data model. This data model will serve as
a basis for the development of data models for more sophisticated o Module "ietf-routing" provides generic components of a routing
routing configurations. While these two modules can be directly used data model.
for simple IPv4-only devices with static routing, their main purpose
is to provide basic building blocks for more complicated setups o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing"
involving other address families such as IPv6, multiple routing module with additional data specific to IPv4 unicast.
protocols, and advanced functions, for example route filtering and
policy routing. To this end, it is expected that this module will be o Module "iana-afn-safi" contains two type definitions translating
augmented by numerous modules developed by other IETF working groups. IANA registries "Address Family Numbers" [IANA-AFN] and
"Subsequent Address Family Identifiers" [IANA-SAFI] to YANG
enumerations.
ED. QUESTION: Would it be possible/useful to publish the "iana-afn-
safi" module as a separate I-D, perhaps together with "iana-if-type"?
The first two modules together define the so-called core routing data
model. This data model will serve as a basis for the development of
data models for more sophisticated routing configurations. While
these two modules can be directly used for simple IPv4-only devices
with static routing, their main purpose is to provide essential
building blocks for more complicated setups involving other address
families such as IPv6, multicast routing, multiple routing protocols,
and advanced functions such as route filtering or policy routing. To
this end, it is expected that this module will be augmented by
numerous modules developed by other IETF working groups.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terms are defined in [RFC4741]: The following terms are defined in [RFC6241]:
o client o client
o message o message
o operation o operation
o server o server
The following terms are defined in [RFC6020]: The following terms are defined in [RFC6020]:
skipping to change at page 4, line 48 skipping to change at page 5, line 4
o module o module
o operational state data o operational state data
o prefix o prefix
o RPC operation o RPC operation
2.1. Glossary of New Terms 2.1. Glossary of New Terms
active route: a route which is actually used for packet forwarding.
If there are multiple candidate routes with a matching destination
prefix, then it is up to the routing algorithm to select the
active route.
o active route: a route which is actually used for packet core routing data model: YANG data model resulting from the
forwarding. If there are multiple candidate routes with the same combination of "ietf-routing" and "ietf-ipv4-unicast-routing-cfg"
destination prefix, then it is up to the routing algorithm to modules.
select the active route.
2.2. Prefixes in Data Node Names 2.2. Prefixes in Data Node Names
In this document, names of data nodes are used mostly without a In this document, names of data nodes are used mostly without a
prefix, as long as it is clear from the context in which YANG module prefix, as long as it is clear from the context in which YANG module
each name is defined. Otherwise, names are prefixed with the each name is defined. Otherwise, names are prefixed with their
standard prefixes associated with YANG modules, as shown in Table 1. standard prefix associated with the corresponding YANG module, as
shown in Table 1.
+--------+---------------------------+------------+ +--------+---------------------------+------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+--------+---------------------------+------------+ +--------+---------------------------+------------+
| eth | ex-ethernet | [YANG-IF] | | eth | ex-ethernet | [YANG-IF] |
| | | | | | | |
| if | ietf-interfaces | [YANG-IF] | | if | ietf-interfaces | [YANG-IF] |
| | | | | | | |
| inet | ietf-inet-types | [RFC6021] | | inet | ietf-inet-types | [RFC6021] |
| | | | | | | |
| ip | ex-ip | [YANG-IF] | | ip | ietf-ip | [YANG-IP] |
| | | | | | | |
| rip | example-rip | Appendix A | | rip | example-rip | Appendix A |
| | | | | | | |
| rt | ietf-routing | Section 5 | | rt | ietf-routing | Section 6 |
| | | | | | | |
| v4ur | ietf-ipv4-unicast-routing | Section 6 | | v4ur | ietf-ipv4-unicast-routing | Section 7 |
| | | | | | | |
| yang | ietf-yang-types | [RFC6021] | | yang | ietf-yang-types | [RFC6021] |
+--------+---------------------------+------------+ +--------+---------------------------+------------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and corresponding YANG modules
3. Objectives 3. Objectives
The initial design of the core routing data model was driven by the The initial design of the core routing data model was driven by the
following main objectives: following objectives:
o The data model should be suitable for the common address families, o The data model should be suitable for the common address families,
in particular IPv4 and IPv6, and for unicast and multicast routing in particular IPv4 and IPv6, and for unicast and multicast
as well as Multiprotocol Label Switching (MPLS). routing, as well as Multiprotocol Label Switching (MPLS).
o Simple routing setups, such as static routing, should be o Simple routing setups, such as static routing, should be
configurable in a simple way, ideally without any need to develop configurable in a simple way, ideally without any need to develop
additional YANG modules. additional YANG modules.
o On the other hand, the core routing framework must allow for o On the other hand, the core routing framework must allow for
complicated setups involving multiple routing tables and multiple complicated setups involving multiple routing tables and multiple
routing protocols, as well as controlled redistributions of routing protocols, as well as controlled redistributions of
routing information. routing information.
o Device vendors will want to map the data models built on this o Device vendors will want to map the data models built on this
generic framework to their proprietary data models and generic framework to their proprietary data models and
configuration interfaces. Therefore, the framework should be configuration interfaces. Therefore, the framework should be
flexible enough to facilitate such a mapping and accommodate data flexible enough to facilitate such a mapping and accommodate data
models with different logic. models with different logic.
4. The Design of the Core Routing Data Model 4. The Design of the Core Routing Data Model
The core routing data model consists of two YANG modules. The first The core routing data model consists of two YANG modules. The first
module, "ietf-routing", is rather minimal and provides only a top- module, "ietf-routing", defines the generic components of a routing
level container ("routing") and a list of routing processes. Each system. The second module, "ietf-ipv4-unicast-routing", augments the
routing process represents an instance of a (virtual) router with a "ietf-routing" module with new data nodes that are needed for IPv4
separate forwarding table (FIB, forwarding information base). For a unicast routing.
given address family, specified by an Address Family Identifier (AFI)
[IANA-AFI] and Subsequent Address Family Identifier (SAFI)
[IANA-SAFI], several independent routing processes may be configured.
The second YANG module, "ietf-ipv4-unicast-routing", provides a data The combined data hierarchy defined by both YANG modules is shown in
modeling framework for IPv4 unicast routing with several essential Figure 1.
components: routes, routing tables, routing protocol instances, route
filters and RPC operations. The following subsections provide
further details about these components.
By combining the components in various ways, and possibly filling +--rw routing
them with appropriate contents defined in other modules, a broad +--rw router [name]
range of routing setups can be covered. +--rw name
+--rw description?
+--rw enabled?
+--rw routing-protocols
| +--rw routing-protocol [name]
| +--rw name
| +--rw description?
| +--rw type
| +--rw connected-routing-tables
| | +--rw connected-routing-table [name]
| | +--rw name
| | +--rw import-filter?
| | +--rw export-filter?
| +--rw v4ur:ipv4-unicast-static-routes
| +--rw v4ur:static-route [id]
| +--rw v4ur:id
| +--rw v4ur:description?
| +--rw v4ur:destination-prefix?
| +--rw v4ur:next-hop?
| +--rw v4ur:outgoing-interface?
+--rw route-filters
| +--rw route-filter [name]
| +--rw name
| +--rw description?
| +--rw type?
+--rw routing-tables
+--rw routing-table [name]
+--rw name
+--rw address-family?
+--rw safi?
+--rw description?
+--ro routes
| +--ro route
| +--ro source-protocol?
| +--ro last-modified?
| +--ro v4ur:destination-prefix?
| +--ro v4ur:next-hop?
| +--ro v4ur:outgoing-interface?
+--rw recipient-routing-tables [recipient-name]
+--rw recipient-name
+--rw filter?
Figure 1: Data hierarchy of "ietf-routing" and "ietf-ipv4-unicast-
routing" modules.
As can be see from Figure 1, the core routing data model introduces
several generic components of a routing framework: routers, routing
tables containing routes, routing protocols, route filters and RPC
operations. The following subsections provide further details about
these components.
By combining the components in various ways, and possibly augmenting
them with appropriate contents defined in other modules, various
routing setups can be realized.
+------------+ +------------+
| FIB | | FIB |
+------------+ +------------+
^ ^
| |
+---+ +---+
| F | | F |
+---+ +---+
^ ^
skipping to change at page 8, line 34 skipping to change at page 9, line 42
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| F | | F | | F | | F | | F | | F | | F | | F |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
^ | ^ | ^ | ^ |
| v | v | v | v
+----------+ +----------+ +----------+ +----------+
| routing | | routing | | routing | | routing |
| protocol | | protocol | | protocol | | protocol |
+----------+ +----------+ +----------+ +----------+
Figure 1: Example setup of the routing subsystem Figure 2: Example setup of the routing subsystem
Figure 1 shows an example of a more complicated setup: Figure 2 shows an example of a more complicated setup. Several of
its features are worth mentioning:
o Along with the main routing table, which must always be present, o Along with the main routing table, which must always be present,
an additional routing table is defined. an additional routing table is configured.
o Each routing protocol instance, including the "static" and o Each routing protocol instance, including the "static" and
"direct" pseudo-protocol instances, is connected to exactly one "direct" pseudo-protocols, is connected to exactly one routing
routing table with which it can exchange routes (in both table with which it can exchange routes (in both directions,
directions, except for the "static" and "direct" pseudo- except for the "static" and "direct" pseudo-protocols).
protocols).
o Routing tables may also be connected to each other and exchange o Routing tables may also be connected to each other and exchange
routes in one or both directions. routes in one or both directions.
o The forwarding information base (FIB) is a special routing table o The forwarding information base (FIB) is a special routing table
which must always be present. Typically, the FIB receives the which must always be present. Typically, the FIB receives the
active routes from the main routing table and the operating system active routes from the main routing table and the operating system
kernel uses this information for packet forwarding. kernel uses this information for packet forwarding.
o Route exchanges along all connections may be controlled by means o Route exchanges along all connections may be controlled by means
of route filters, denoted by "F" in the figure. of route filters, denoted by "F" in Figure 2.
4.1. Route 4.1. Router
Routes are basic units of information in a routing system. The Each router instance in the core routing data model represents a
"ietf-ipv4-unicast-routing" module defines only the following minimal (virtual) router whose configuration and operation is independent of
set of route attributes: other router instances. Although it it not enforced by the data
model, different router instances normally do not internally share
any data. They may, however, communicate with each other via routing
protocols.
4.2. Route
Routes are basic units of information in a routing system. The core
routing data model defines only the following minimal set of route
attributes:
o destination-prefix - IP prefix specifying the set of destination o destination-prefix - IP prefix specifying the set of destination
addresses for which the route may be used. This attribute is addresses for which the route may be used. This attribute is
mandatory. mandatory.
o next-hop - IP address of the adjacent router or host to which o next-hop - IP address of the adjacent router or host to which
packets with destination addresses belonging to destination-prefix packets with destination addresses belonging to destination-prefix
should be sent. should be sent.
o outgoing-interface - network interface that should be used for o outgoing-interface - network interface that should be used for
sending packets with destination addresses belonging to sending packets with destination addresses belonging to
destination-prefix. destination-prefix.
The above list of route attributes is sufficient for a simple static The above list of route attributes is sufficient for a simple static
routing configuration. It is expected that future modules defining routing configuration. It is expected that future modules defining
routing protocols will add other route attributes such as metrics or routing protocols will add other route attributes such as metrics or
preferences. preferences.
Routes and their attributes are used in both configuration data, for Routes and their attributes are used in both configuration data, for
example as manually configured static routes, as well as in example as manually configured static routes, and in operational
operational state data, for example as entries in routing tables. state data, for example as entries in routing tables.
4.2. Routing Tables 4.3. Routing Tables
Routing tables are lists of routes complemented with administrative Routing tables are lists of routes complemented with administrative
data, namely: data, namely:
o source-protocol - name of the routing protocol from which the o source-protocol - name of the routing protocol from which the
route was originally obtained. route was originally obtained.
o last-modified - date and time of last modification, or o last-modified - date and time of last modification, or
installation, of the route. installation, of the route.
In the core routing data model, the list of routes in routing tables In the core routing data model, the contents of routing tables (list
is represented as operational state data. Routing protocol of routes) are defined as operational state data. Routing protocol
operations result in route additions, removals and modifications. operations result in route additions, removals and modifications.
This also includes manipulations via the "static" pseudo-protocol. This also includes manipulations via the "static" pseudo-protocol.
The "ietf-ipv4-unicast-routing" module requires that at least the At least the following two routing tables MUST be configured for each
following two routing tables MUST be configured for each routing router instance:
process:
o The "ipv4-unicast-fib" table is the forwarding information base 1. Forwarding information base (FIB) contains active routes that are
used by the operating system kernel for forwarding IPv4 unicast used by the operating system kernel for forwarding datagrams.
datagrams.
o The "ipv4-unicast-main" table is the main routing table. By 2. Main routing table to which all routing protocol instances are
default, all IPv4 unicast routing protocols exchange routes with connected by default.
this table, and active routes from the "ipv4-unicast-main" routing
table are installed in the "ipv4-unicast-fib" table and used for
packet forwarding.
Additional routing tables MAY be configured. The main routing table SHOULD serve as the source of active routes
for the FIB.
Every routing table MAY serve as a source of routes for other routing One or more additional routing tables MAY be configured by creating
tables. To achieve this, one or more recipient routing tables MAY be new entries in the "routing-table" list, either being a part of
factory-default configuration or configured by the client.
The naming scheme for routing tables, as well as restrictions on the
number and configurability of routing tables are implementation-
specific.
Every routing table can serve as a source of routes for other routing
tables. To achieve this, one or more recipient routing tables may be
specified in the configuration of the source routing table. In specified in the configuration of the source routing table. In
addition, a route filter may be configured for each recipient routing addition, a route filter may be configured for each recipient routing
table, which selects and/or manipulates the routes that are passed on table, which selects and/or manipulates the routes that are passed on
between the source and recipient routing table. between the source and recipient routing table.
4.3. Routing Protocol Instances 4.4. Routing Protocols
The "ietf-ipv4-unicast-routing" module provides an open-ended The core routing data model provides an open-ended framework for
framework for defining multiple routing protocol instances. Each of defining multiple routing protocol instances. Each of them is
them is identified by a name, which is unique within a routing identified by a name, which MUST be unique within a router instance,
process, and MUST be assigned a type from a selection which includes and MUST be assigned a type from a selection which includes all
all routing protocol types supported by the server, such as RIP, OSPF routing protocol types supported by the server, such as static, RIP,
or BGP. OSPF or BGP.
Each routing protocol instance is connected to exactly one routing Each routing protocol instance is connected to exactly one routing
table. By default, every routing protocol instance is connected to table. By default, every routing protocol instance is connected to
the main routing table, but any routing protocol instance can be the main routing table, but any routing protocol instance can be
configured to use a different routing table, provided such an extra configured to use a different routing table, provided such an extra
table is configured. table exists.
Routes learned from the network by a routing protocol instance are Routes learned from the network by a routing protocol are passed to
passed to the connected routing table and vice versa - routes the connected routing table and vice versa - routes appearing in a
appearing in a routing table are passed to all routing protocol routing table are passed to all routing protocols connected to the
connected to the table and advertised by that protocol to the table (except "direct" and "static" pseudo-protocols) and advertised
network. by that protocol to the network.
Two independent route filters (see Section 4.4) may be defined for a Two independent route filters (see Section 4.5) may be defined for a
routing protocol instance to control the exchange of routes in both routing protocol instance to control the exchange of routes in both
directions between the routing protocol instance and the connected directions between the routing protocol instance and the connected
routing table: routing table:
o import filter controls which routes are passed from a routing o import filter controls which routes are passed from a routing
protocol instance to the routing table, protocol instance to the routing table,
o export filter controls which routes the routing protocol instance o export filter controls which routes the routing protocol instance
may receive from the connected routing table. may receive from the connected routing table.
Note that, for historical reasons, the terms import and export are Note that, for historical reasons, the terms import and export are
used from the viewpoint of a routing table. used from the viewpoint of a routing table.
The "ietf-ipv4-unicast-routing" module defines two special routing The "ietf-routing" module defines two special routing protocols -
protocols - "direct" and "static". Both are in fact pseudo- "direct" and "static". Both are in fact pseudo-protocols, which
protocols, which means that they are confined to the local device and means that they are confined to the local device and do not exchange
do not exchange any routing information with neighboring routers. any routing information with neighboring routers. Routes from both
Routes from both "direct" and "static" protocol instances are passed "direct" and "static" protocol instances are passed to the connected
to the connected routing table (subject to route filters, if any), routing table (subject to route filters, if any), but an exchange in
but an exchange in the opposite direction is not allowed. the opposite direction is not allowed.
Every routing process MUST contain exactly one instance of the Every router instance MUST contain exactly one instance of the
"direct" pseudo-protocol. It is the source of routes to directly "direct" pseudo-protocol. It is the source of routes to directly
connected networks (so-called direct routes). Such routes are connected networks (so-called direct routes). Such routes are
supplied by the operating system kernel based on the detected and supplied by the operating system kernel, based on the detected and
configured network interfaces, and they usually appear in the main configured network interfaces, and they usually appear in the main
routing table. However, using the framework defined in this routing table. However, using the framework defined in this
document, the target routing table for direct routes can be changed document, the target routing table for direct routes can be changed
by connecting the "direct" protocol instance to a non-default routing by connecting the "direct" protocol instance to a non-default routing
table, and the direct routes can also be filtered before they appear table, and the direct routes can also be filtered before they appear
in the routing table. in the routing table.
The "static" routing pseudo-protocol allows for specifying routes The "static" routing pseudo-protocol allows for specifying routes
manually. It can be configured in zero or more instances, although manually. It MAY be configured in zero or multiple instances,
typically one instance suffices. although a typical implementation will have exactly one instance.
4.3.1. Defining New Routing Protocols 4.4.1. Defining New Routing Protocols
It is expected that future YANG modules will create data models for It is expected that future YANG modules will create data models for
additional routing protocol types. In order to do so, the new module additional routing protocol types. In order to do so, the new module
has to define the protocol-specific information and fit it to the has to define the protocol-specific information and fit it to the
core routing framework in the following way: core routing framework in the following way:
o A new identity MUST be defined for the routing protocol and its o A new identity MUST be defined for the routing protocol and its
base identity set to "rt:routing-protocol", or to an identity base identity MUST be set to "rt:routing-protocol", or to an
derived from "rt:routing-protocol". identity derived from "rt:routing-protocol".
o Additional route attributes MAY be defined. Their definitions o Additional route attributes MAY be defined. Their definitions
have to be inserted as operational state data by augmenting the then have to be inserted as operational state data by augmenting
definition of "v4ur:route" inside "v4ur:routing-table". the definition of "rt:route" inside "rt:routing-table", and
Naturally, route attributes (including the extra attributes) may possibly to other places in configuration data and RPC input or
be used in configuration data, too, as demonstrated by the output.
"static" pseudo-protocol.
o The recommended way of defining configuration data specific to the o The recommended way of defining configuration data specific to a
new protocol is to augment the "routing-protocol-instance" list new protocol is to augment the "routing-protocol" list entry with
entry with a container that encapsulates the configuration a container that encapsulates the configuration hierarchy of the
hierarchy of the new protocol. The "augment" statement SHOULD be new protocol. The "augment" statement SHOULD be made conditional
made conditional by using a "when" substatement requiring that the by using a "when" substatement requiring that the new nodes be
new nodes be used only if the "type" leaf node is equal to the new used only if the "type" leaf node is equal to the new protocol's
protocol's identity. identity.
The above steps are implemented by the example YANG module for the The above steps are implemented by the example YANG module for the
RIP routing protocol in Appendix A. First, the module defines a new RIP routing protocol in Appendix A. First, the module defines a new
identity for the RIP protocol: identity for the RIP protocol:
identity rip { identity rip {
base rt:routing-protocol; base rt:routing-protocol;
description "Identity for the RIP routing protocol."; description "Identity for the RIP routing protocol.";
} }
Second, new route attributes specific for the RIP protocol ("metric" Second, new route attributes specific for the RIP protocol ("metric"
and "tag") are added: and "tag") are defined in a grouping and then added to route
definitions appearing in "routing-table" and in the output part of
"get-route" RPC method:
augment "/rt:routing/rt:routing-process/v4ur:ipv4-unicast-routing/" grouping route-content {
+ "v4ur:routing-tables/v4ur:routing-table/" description
+ "v4ur:routes/v4ur:route" { "RIP-specific route content.";
when "../../../../v4ur:routing-protocol-instances/" leaf metric {
+ "v4ur:routing-protocol-instance[rt:name=" type rip-metric;
+ "current()/v4ur:source-protocol]/v4ur:type='rip:rip'"; }
leaf tag {
type uint16;
default "0";
description
"This leaf may be used to carry additional info, e.g. AS
number.";
}
}
augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
+ "rt:routes/rt:route" {
when "../../../../rt:routing-protocols/"
+ "rt:routing-protocol[rt:name=current()/rt:source-protocol]/"
+ "rt:type='rip:rip'" {
description
"This augment is only valid if the source protocol from which
the route originated is RIP.";
}
description description
"RIP-specific route components."; "RIP-specific route components.";
leaf metric { ... } uses route-content;
leaf tag { ... }
} }
The "when" statement is used to make sure that the new route augment "/rt:get-route/rt:output/rt:route" {
attributes are only valid when the source protocol is RIP. description
"Add RIP-specific route content.";
uses route-content;
}
Finally, RIP-specific configuration data are integrated into the The "when" substatement in the first "augment" guarantees that the
"v4ur:routing-protocol-instance" node by using the following new route attributes are only valid when the source protocol is RIP.
"augment" statement, which applies only to routing protocol instances
whose type is "rip:rip", and which is a part of a routing process
whose address family is "ipV4" and subsequent address family
identifier is "nlri-unicast":
augment "/rt:routing/rt:routing-process/v4ur:ipv4-unicast-routing/" Finally, RIP-specific configuration data are integrated into the "rt:
+ "v4ur:routing-protocol-instances/" routing-protocol" node by using the following "augment" statement,
+ "v4ur:routing-protocol-instance" { which applies only to routing protocol instances whose type is "rip:
when "v4ur:type = 'rip:rip' and ../../../rt:address-family = 'ipV4'" rip":
+ " and ../../../safi = 'nlri-unicast'";
container rip-configuration {
...
}
}
4.4. Route Filters augment "/rt:routing/rt:router/rt:routing-protocols/"
+ "rt:routing-protocol" {
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";
}
}
}
leaf update-interval {
type uint8 {
range "10..60";
}
units "seconds";
default "30";
description
"Time interval between periodic updates.";
}
}
}
The "ietf-ipv4-unicast-routing" module provides a skeleton for 4.5. Route Filters
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 a source and a recipient routing table. Route
filters may also manipulate routes, i.e., add, delete, or modify
their properties.
By itself, the route filtering framework defined in the "ietf-ipv4- The core routing data model provides a skeleton for defining route
unicast-routing" module allows to establish only the two extreme filters that can be used to restrict the set of routes being
routing policies in which either all routes are allowed or all routes exchanged between a routing protocol instance and a routing table, or
are denied. It is expected that a real route filtering framework (or between a source and a recipient routing table. Route filters may
several alternative frameworks) will be developed separately. also manipulate routes, i.e., add, delete, or modify their
properties.
Each route filter is identified by a name which is unique within a By itself, the route filtering framework defined in this document
routing process. Its type MUST be specified by the "type" identity allows to establish only the two extreme routing policies in which
either all routes are allowed or all routes are rejected. It is
expected that real route filtering framework(s) will be developed
separately.
Each route filter is identified by a name which MUST be unique within
a router instance. Its type MUST be specified by the "type" identity
reference - this opens the space for multiple route filtering reference - this opens the space for multiple route filtering
framework implementations. The default value for route filter type framework implementations. The default value for route filter type
is the identity "deny-all-route-filter" defined in the "ietf-routing" is the identity "deny-all-route-filter" defined in the "ietf-routing"
module, which represents the "deny all" route filtering policy. module, which represents a route filtering policy in which all routes
are rejected.
4.5. RPC Operations 4.6. RPC Operation
The "ietf-ipv4-unicast-routing-module" defines two RPC operations: The "ietf-routing" module defines the "get-route" RPC operation. It
is used for querying the forwarding information base of a router
instance. The first input parameter is the name of the router
instance whose FIB is to be queried, and the second parameter is a
destination address. Modules for particular address families are
expected to augment the "destination-address" container with the
"address" leaf, as it is done in the "ietf-ipv4-unicast-routing"
module.
o "delete-route" operations allows the client to immediately delete The server replies with an active route which is used for forwarding
specific route(s) from a routing table within a routing process. datagrams to the destination address within the selected router
The first input parameter of this operation is the name of the instance. Again, modules for particular address families are
routing process, the second parameter is the routing table to act expected to augment the definition of output parameters with AFN/
upon, and the third (optional) parameter is the "route" container SAFI-specific contents.
with zero or more of the following route attributes: "destination-
prefix", "next-hop" and "outgoing-interface". All routes that
match these attributes MUST be deleted from the selected routing
table. If the "route" container is missing or empty, all routes
from the selected routing table MUST be deleted.
o "get-route" is used for querying the forwarding information base 5. IANA AFN and SAFI YANG Module
of a routing process. The first input parameter is the name of a
routing process whose FIB is to be queried, and the second
parameter is an IPv4 destination address. The server replies with
an active route which is used for forwarding datagrams to the
destination address within the selected routing process.
5. Routing YANG Module RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
<CODE BEGINS> file "ietf-routing@2011-04-27.yang" actual RFC number and all occurrences of the revision date below with
the date of RFC publication (and remove this note).
module ietf-routing { <CODE BEGINS> file "iana-afn-safi@2011-09-23.yang"
namespace "urn:ietf:params:xml:ns:yang:ietf-routing";
prefix rt; module iana-afn-safi {
namespace "urn:ietf:params:xml:ns:yang:iana-afn-safi";
prefix "ianaaf";
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IANA";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "Internet Assigned Numbers Authority
WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens Postal:
<mailto:david.kessens@nsn.com> ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
U. S. A.
WG Chair: Juergen Schoenwaelder Tel: +1 310 823 9358
<mailto:j.schoenwaelder@jacobs-university.de> E-Mail: iana&iana.org
";
Editor: Ladislav Lhotka
<mailto:lhotka@cesnet.cz>";
description description
"This module contains YANG definitions for top-level containers "This YANG module provides two typedefs containing YANG
for the configuration of routing together with several type definitions for the following IANA-registered enumerations:
definitions and identities.";
revision 2011-04-27 { - Address Family Numbers (AFN)
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for Routing Configuration";
}
/* Identities */ - Subsequent Address Family Identifiers (SAFI)
identity routing-protocol { The latest revision of this YANG module can be obtained from the
description IANA web site.
"Base identity from which routing protocol identities are
derived.";
}
identity direct { Copyright (c) 2011 IETF Trust and the persons identified as
base routing-protocol; authors of the code. All rights reserved.
description
"Identity for the pseudo-protocol providing routes to directly
connected networks. An implementation MUST preconfigure
exactly one instance of this pseudo-protocol for each routing
process."; }
identity static { Redistribution and use in source and binary forms, with or
base routing-protocol; without modification, is permitted pursuant to, and subject to
description the license terms contained in, the Simplified BSD License set
"Identity for static routing pseudo-protocol."; forth in Section 4.c of the IETF Trust's Legal Provisions
} Relating to IETF Documents
(http://trustee.ietf.org/license-info).
identity route-filter { This version of this YANG module is part of RFC XXXX; see the
description RFC itself for full legal notices.
"Base identity from which all route filters are ";
derived.";
}
identity deny-all-route-filter { revision 2011-09-23 {
base route-filter;
description description
"This identity represents a route filter that blocks all "Initial revision.";
routes."; reference
"RFC XXXX: A YANG Data Model for Routing Configuration";
} }
/* Type definitions */
typedef address-family { typedef address-family {
type enumeration { type enumeration {
enum "other" { enum other {
value 0; value "0";
description description
"none of the following"; "none of the following";
} }
enum "ipV4" { enum ipV4 {
value 1; value "1";
description description
"IP Version 4"; "IP Version 4";
} }
enum "ipV6" { enum ipV6 {
value 2; value "2";
description description
"IP Version 6"; "IP Version 6";
} }
enum "nsap" { enum nsap {
value 3; value "3";
description description
"NSAP"; "NSAP";
} }
enum "hdlc" { enum hdlc {
value 4; value "4";
description description
"(8-bit multidrop)"; "(8-bit multidrop)";
} }
enum "bbn1822" { enum bbn1822 {
value 5; value "5";
description description
"BBN Report 1822"; "BBN Report 1822";
} }
enum "all802" { enum all802 {
value 6; value "6";
description description
"(includes all 802 media plus Ethernet 'canonical "(includes all 802 media plus Ethernet 'canonical
format')"; format')";
} }
enum "e163" { enum e163 {
value 7; value "7";
description
"E.163";
} }
enum "e164" { enum e164 {
value 8; value "8";
description description
"(SMDS, FrameRelay, ATM)"; "(SMDS, FrameRelay, ATM)";
} }
enum "f69" { enum f69 {
value 9; value "9";
description description
"(Telex)"; "(Telex)";
} }
enum "x121" { enum x121 {
value 10; value "10";
description description
"(X.25, Frame Relay)"; "(X.25, Frame Relay)";
} }
enum "ipx" { enum ipx {
value 11; value "11";
description description
"IPX (Internet Protocol Exchange)"; "IPX (Internet Protocol Exchange)";
} }
enum "appleTalk" { enum appleTalk {
value 12; value "12";
description description
"Apple Talk"; "Apple Talk";
} }
enum "decnetIV" { enum decnetIV {
value 13; value "13";
description description
"DEC Net Phase IV"; "DEC Net Phase IV";
} }
enum "banyanVines" { enum banyanVines {
value 14; value "14";
description description
"Banyan Vines"; "Banyan Vines";
} }
enum "e164withNsap" { enum e164withNsap {
value 15; value "15";
description description
"(E.164 with NSAP format subaddress)"; "(E.164 with NSAP format subaddress)";
} }
enum "dns" { enum dns {
value 16; value "16";
description description
"(Domain Name System)"; "(Domain Name System)";
} }
enum "distinguishedName" { enum distinguishedName {
value 17; value "17";
description description
"(Distinguished Name, per X.500)"; "(Distinguished Name, per X.500)";
} }
enum "asNumber" { enum asNumber {
value 18; value "18";
description description
"(16-bit quantity, per the AS number space)"; "(16-bit quantity, per the AS number space)";
} }
enum "xtpOverIPv4" { enum xtpOverIPv4 {
value 19; value "19";
description description
"XTP over IP version 4"; "XTP over IP version 4";
} }
enum "xtpOverIpv6" { enum xtpOverIpv6 {
value 20; value "20";
description description
"XTP over IP version 6"; "XTP over IP version 6";
} }
enum "xtpNativeModeXTP" { enum xtpNativeModeXTP {
value 21; value "21";
description description
"XTP native mode XTP"; "XTP native mode XTP";
} }
enum "fibreChannelWWPN" { enum fibreChannelWWPN {
value 22; value "22";
description description
"Fibre Channel World-Wide Port Name"; "Fibre Channel World-Wide Port Name";
} }
enum "fibreChannelWWNN" { enum fibreChannelWWNN {
value 23; value "23";
description description
"Fibre Channel World-Wide Node Name"; "Fibre Channel World-Wide Node Name";
} }
enum "gwid" { enum gwid {
value 24; value "24";
description description
"Gateway Identifier"; "Gateway Identifier";
} }
enum "afi" { enum afi {
value 25; value "25";
description description
"AFI for L2VPN"; "AFI for L2VPN";
} }
} }
description description
"This typedef is a YANG enumeration of IANA-registered "This typedef is a YANG enumeration of IANA-registered address
address families."; family numbers (AFN).";
reference reference
"http://www.iana.org/assignments/ianaaddressfamilynumbers-mib"; "Address Family Numbers. IANA, 2011-01-20.
<http://www.iana.org/assignments/address-family-numbers/
address-family-numbers.xml>
IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS
<http://www.iana.org/assignments/ianaaddressfamilynumbers-mib>
";
} }
typedef subsequent-address-family { typedef subsequent-address-family {
type enumeration { type enumeration {
enum "nlri-unicast" { enum nlri-unicast {
value 1; value "1";
description description
"Network Layer Reachability Information used for "Network Layer Reachability Information used for unicast
unicast forwarding"; forwarding";
reference "RFC4760"; reference
"RFC4760";
} }
enum "nlri-multicast" { enum nlri-multicast {
value 2; value "2";
description description
"Network Layer Reachability Information used for "Network Layer Reachability Information used for multicast
multicast forwarding"; forwarding";
reference "RFC4760"; reference
"RFC4760";
} }
enum "nlri-mpls" { enum nlri-mpls {
value 4; value "4";
description description
"Network Layer Reachability Information (NLRI) with "Network Layer Reachability Information (NLRI) with MPLS
MPLS Labels"; Labels";
reference "RFC3107"; reference
"RFC3107";
} }
enum "mcast-vpn" { enum mcast-vpn {
value 5; value "5";
description description
"MCAST-VPN"; "MCAST-VPN";
reference "draft-ietf-l3vpn-2547bis-mcast-bgp-08";
reference
"draft-ietf-l3vpn-2547bis-mcast-bgp-08";
} }
enum "nlri-dynamic-ms-pw" { enum nlri-dynamic-ms-pw {
value 6; value "6";
status obsolete; status "obsolete";
description description
"Network Layer Reachability Information used for Dynamic "Network Layer Reachability Information used for Dynamic
Placement of Multi-Segment Pseudowires (TEMPORARY - Placement of Multi-Segment Pseudowires (TEMPORARY -
Expires 2008-08-23)"; Expires 2008-08-23)";
reference "draft-ietf-pwe3-dynamic-ms-pw-13"; reference
"draft-ietf-pwe3-dynamic-ms-pw-13";
} }
enum "tunnel-safi" { enum tunnel-safi {
value 64; value "64";
description description
"Tunnel SAFI"; "Tunnel SAFI";
reference "draft-nalawade-kapoor-tunnel-safi-05"; reference
"draft-nalawade-kapoor-tunnel-safi-05";
} }
enum "vpls" { enum vpls {
value 65; value "65";
description description
"Virtual Private LAN Service (VPLS)"; "Virtual Private LAN Service (VPLS)";
reference "RFC4761, RFC6074"; reference
"RFC4761, RFC6074";
} }
enum "bgp-mdt" { enum bgp-mdt {
value 66; value "66";
description description
"BGP MDT SAFI"; "BGP MDT SAFI";
reference "RFC6037"; reference
"RFC6037";
} }
enum "bgp-4over6" { enum bgp-4over6 {
value 67; value "67";
description description
"BGP 4over6 SAFI"; "BGP 4over6 SAFI";
reference "RFC5747"; reference
"RFC5747";
} }
enum "bgp-6over4" { enum bgp-6over4 {
value 68; value "68";
description description
"BGP 6over4 SAFI"; "BGP 6over4 SAFI";
reference "mailto:cuiyong&tsinghua.edu.cn"; reference
"mailto:cuiyong&tsinghua.edu.cn";
} }
enum "l1vpn-auto-discovery" { enum l1vpn-auto-discovery {
value 69; value "69";
description description
"Layer-1 VPN auto-discovery information"; "Layer-1 VPN auto-discovery information";
reference "draft-ietf-l1vpn-bgp-auto-discovery-05"; reference
"draft-ietf-l1vpn-bgp-auto-discovery-05";
} }
enum "mpls-vpn" { enum mpls-vpn {
value 128; value "128";
description description
"MPLS-labeled VPN address"; "MPLS-labeled VPN address";
reference "RFC4364"; reference
"RFC4364";
} }
enum "multicast-bgp-mpls-vpn" { enum multicast-bgp-mpls-vpn {
value 129; value "129";
description description
"Multicast for BGP/MPLS IP Virtual Private Networks "Multicast for BGP/MPLS IP Virtual Private Networks
(VPNs)"; (VPNs)";
reference reference
"draft-ietf-l3vpn-2547bis-mcast-10, "draft-ietf-l3vpn-2547bis-mcast-10,
draft-ietf-l3vpn-2547bis-mcast-10"; draft-ietf-l3vpn-2547bis-mcast-10";
} }
enum "route-target-constraints" { enum route-target-constraints {
value 132; value "132";
description description
"Route Target constraints"; "Route Target constraints";
reference "RFC4684"; reference
"RFC4684";
} }
enum "ipv4-diss-flow" { enum ipv4-diss-flow {
value 133; value "133";
description description
"IPv4 dissemination of flow specification rules"; "IPv4 dissemination of flow specification rules";
reference "RFC5575"; reference
"RFC5575";
} }
enum "vpnv4-diss-flow" { enum vpnv4-diss-flow {
value 134; value "134";
description description
"IPv4 dissemination of flow specification rules"; "IPv4 dissemination of flow specification rules";
reference "RFC5575"; reference
"RFC5575";
} }
enum "vpn-auto-discovery" { enum vpn-auto-discovery {
value 140; value "140";
description description
"VPN auto-discovery"; "VPN auto-discovery";
reference "draft-ietf-l3vpn-bgpvpn-auto-09";
reference
"draft-ietf-l3vpn-bgpvpn-auto-09";
} }
} }
description description
"This typedef is a YANG enumeration of IANA-registered "This typedef is a YANG enumeration of IANA-registered
subsequent address families."; subsequent address family identifiers (SAFI).";
reference "http://www.iana.org/assignments/safi-namespace/" reference
+ "safi-namespace.xml"; "Subsequent Address Family Identifiers (SAFI) Parameters. IANA,
} 2011-03-04. <http://www.iana.org/assignments/safi-namespace/
safi-namespace.xml>
typedef routing-process-ref { ";
type leafref {
path "/rt:routing/rt:routing-process/rt:name";
}
description
"This type is used for leafs that reference a routing
process.";
} }
}
/* Data nodes */ <CODE ENDS>
container routing { 6. Routing YANG Module
description
"Routing parameters.";
list routing-process {
key "name";
description
"Each entry is a container for configuration and operational
state data of a single (virtual) router for a given address
family and subsequent address family identifier (SAFI). Each
entry has a unique name.
The definitions of data for a particular address family and RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
subsequent address family shall be provided via augmentation actual RFC number and all occurrences of the revision date below with
by other modules."; the date of RFC publication (and remove this note).
leaf name {
type string;
description
"The unique name of the routing process.";
}
leaf address-family {
type address-family;
default "ipV4";
description
"Address family of the routing process.";
}
leaf safi {
type subsequent-address-family;
default "nlri-unicast";
description
"Subsequent address family identifier of the routing
process.";
}
leaf description {
type string;
description
"Textual description of the routing process.";
}
leaf enabled {
type boolean;
default "true";
description
"Enable or disable the routing process. The default value
is 'true', which means that the process is enabled.";
}
} <CODE BEGINS> file "ietf-routing@2011-09-23.yang"
}
}
<CODE ENDS> module ietf-routing {
6. IPv4 Unicast Routing YANG Module namespace "urn:ietf:params:xml:ns:yang:ietf-routing";
<CODE BEGINS> file "ietf-ipv4-unicast-routing@2011-04-27.yang"
module ietf-ipv4-unicast-routing { prefix "rt";
namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing";
prefix v4ur;
import ietf-routing {
prefix rt;
}
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix "yang";
}
import ietf-inet-types {
prefix inet;
} }
import ietf-interfaces {
prefix if; import iana-afn-safi {
prefix "ianaaf";
} }
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens WG Chair: David Kessens
<mailto:david.kessens@nsn.com> <mailto:david.kessens@nsn.com>
WG Chair: Juergen Schoenwaelder WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de> <mailto:j.schoenwaelder@jacobs-university.de>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@cesnet.cz>"; <mailto:lhotka@cesnet.cz>
";
description description
"This module augments the 'ietf-routing' module with YANG "This module contains YANG definitions of essential components
definitions for basic configuration of IPv4 unicast routing. that may be used for configuring a routing subsystem.
It is immediately usable for a device that needs just a single Copyright (c) 2011 IETF Trust and the persons identified as
routing table populated with static routes. authors of the code. All rights reserved.
On the other hand, the framework is designed to handle Redistribution and use in source and binary forms, with or
arbitrarily complex configurations with any number of routing without modification, is permitted pursuant to, and subject to
tables and various routing protocols (in multiple instances)."; the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
revision 2011-04-27 { This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.
";
revision 2011-09-23 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for Routing Configuration"; "RFC XXXX: A YANG Data Model for Routing Configuration";
} }
/* Groupings */ /* Identities */
grouping routing-process-name { identity routing-protocol {
leaf routing-process-name {
type rt:routing-process-ref;
must "/rt:routing/rt:routing-process[rt:name = current()]"
+ "/rt:address-family = 'ipV4' and "
+ "/rt:routing/rt:routing-process[rt:name = current()]"
+ "/rt:safi = 'nlri-unicast'" {
description
"The referred routing process must be IPv4 unicast.";
}
description "The name of a routing process.";
}
description description
"This grouping defines the first common parameter of both "Base identity from which routing protocol identities are
RPC operations below."; derived.";
} }
/* RPC operations */ identity direct {
base routing-protocol;
description
"Routing pseudo-protocol which provides routes to directly
connected networks.";
}
rpc get-route { identity static {
base routing-protocol;
description description
"Query the forwarding information base of an IPv4 unicast "Static routing pseudo-protocol.";
routing process whose name is given as the first }
parameter. The second parameter is an IPv4 destination
address. The server returns the route which is currently used identity route-filter {
for forwarding datagrams to that destination address, or an description
error message, if no such route exists."; "Base identity from which all route filters are derived.";
input { }
uses routing-process-name;
leaf destination-address { identity deny-all-route-filter {
type inet:ipv4-address; base route-filter;
description description
"Second parameter - IPv4 destination address."; "Route filter that blocks all routes.";
} }
} /* Type Definitions */
output {
container route { typedef router-ref {
description type leafref {
"Contents of the reply."; path "/rt:routing/rt:router/rt:name";
leaf destination-prefix {
type inet:ipv4-prefix;
mandatory true;
description
"Destination prefix of the returned route.";
}
leaf next-hop {
type inet:ipv4-address;
description
"Next hop address of the returned route.";
}
leaf outgoing-interface {
type if:interface-ref;
description
"Outgoing interface of the returned route.";
}
}
} }
description
"This type is used for leafs that reference a router
instance.";
} }
rpc delete-route { /* Groupings */
grouping afn-safi {
leaf address-family {
type ianaaf:address-family;
default "ipV4";
description
"Address family of routes in the routing table.";
}
leaf safi {
type ianaaf:subsequent-address-family;
default "nlri-unicast";
description
"Subsequent address family identifier of routes in the
routing table.";
}
description description
"This grouping provides two parameters specifying address
family and subsequent address family.";
}
"Delete all routes that match the given attributes from a grouping route-content {
routing table within a routing process. description
"Generic parameters of routes.";
leaf source-protocol {
type string;
description
"The name of the routing protocol instance from which the
route comes. This routing protocol must be configured
(automatically or manually) in the device.";
}
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.";
Parameters: }
1. routing process name, }
2. routing table name,
3. Container 'route' with route attributes.
<ok> is returned by the server upon successful completion."; /* RPC Methods */
rpc get-route {
description
"Query the forwarding information base of a router instance
whose name is given as the first parameter 'router-name'. The
second parameter 'destination-address' should be augmented in
order to support destination addresses of all supported
address families. The server returns the route which is
currently used for forwarding datagrams to that destination
address, or an error message, if no such route exists.";
input { input {
uses routing-process-name; leaf router-name {
leaf routing-table { type router-ref;
type leafref { mandatory "true";
path "/rt:routing/rt:routing-process[rt:name=current()/../"
+ "routing-process-name]/ipv4-unicast-routing/"
+ "routing-tables/routing-table/name";
}
mandatory true;
description description
"First parameter."; "First parameter: name of the router instance whose
forwarding information base is queried.";
} }
container route { container destination-address {
uses afn-safi;
description description
"Second parameter. All routes matching the route "Second parameter: destination address.
attributes must be deleted from the routing table.
If this container is empty or missing, all routes AFN/SAFI-specific modules must augment this container with
from the selected routing table are deleted."; a leaf named 'address'.
leaf destination-prefix { ";
type inet:ipv4-prefix; }
description }
"Match destination prefix."; output {
} container route {
leaf next-hop { uses afn-safi;
type inet:ipv4-address; description
description "Contents of the reply specific for each address family
"Match next hop."; should be defined through augmenting.";
} uses route-content;
leaf outgoing-interface {
type if:interface-ref;
description
"Match outgoing interface.";
}
} }
} }
} }
/* Data nodes */ /* Data Nodes */
augment "/rt:routing/rt:routing-process" { container routing {
when "afi='ipV4' and safi='nlri-unicast'" {
description
"IPv4 unicast.";
}
description description
"Definitions of data nodes that augment a routing process "Routing parameters.";
for IPv4 unicast.";
container ipv4-unicast-routing { list router {
key "name";
description description
"Container for IPv4 unicast routing configuration and "Each list entry is a container for configuration and
operational state data."; operational state data of a single (logical) router.";
container routing-protocol-instances { leaf name {
type string;
description
"The unique router name.";
}
leaf description {
type string;
description
"Textual description of the router.";
}
leaf enabled {
type boolean;
default "true";
description
"Enable or disable the router. The default value is 'true',
which means that the router is enabled.";
}
container routing-protocols {
description description
"Container for the list of configured routing protocol "Container for the list of configured routing protocol
instances."; instances.";
list routing-protocol-instance { list routing-protocol {
key "name"; key "name";
description description
"An instance of a routing protocol."; "An instance of a routing protocol.";
container static-routes {
when "../type='rt:static'" {
description
"These data nodes are only valid for the static
pseudo-protocol.";
}
description
"Configuration of a 'static' pseudo-protocol
instance consists of a list of routes.";
list static-route {
key "id";
ordered-by user;
description
"An user-ordered list of static routes.";
leaf id {
type string;
description
"An identification string for the route.";
}
leaf description {
type string;
description
"Textual description of the route.";
}
leaf destination-prefix {
type inet:ipv4-prefix;
mandatory true;
description
"The destination prefix for which the route may
be used.";
}
leaf next-hop {
type inet:ipv4-address;
description
"IPv4 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 attribute
is mainly used in direct routes.";
}
}
}
leaf name { leaf name {
type string; type string;
description description
"The name of the routing protocol instance."; "The name of the routing protocol instance.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the routing protocol "Textual description of the routing protocol
instance."; instance.";
} }
leaf type { leaf type {
type identityref { type identityref {
base rt:routing-protocol; base routing-protocol;
} }
mandatory true; mandatory "true";
description description
"Type of the routing protocol - an identity derived "Type of the routing protocol - an identity derived
from the 'rt:routing-protocol' base identity."; from the 'routing-protocol' base identity.";
}
leaf routing-table {
type leafref {
path "../../../routing-tables/routing-table/name";
}
default "ipv4-unicast-main";
description
"The routing table to which the routing protocol
instance is connected. By default it is the
'ipv4-unicast-main' table.";
}
leaf import-filter {
type leafref {
path "../../../route-filters/route-filter/name";
}
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 { container connected-routing-tables {
type leafref {
path "../../../route-filters/route-filter/name";
}
description description
"Reference to a route filter that is used for filtering "Container for connected routing tables.";
routes passed from the routing table specified by the list connected-routing-table {
'routing-table' sibling to this routing protocol key "name";
instance. If this leaf is not present, the behavior is description
protocol-specific - typically it means that all routes "List of routing tables to which the routing protocol
are accepted, except for the 'direct' and 'static' instance is connected. No more than one routing
pseudo-protocols which accept no routes from any table may be configured for each AFN/SAFI pair.
routing table.";
Implementation may provide default routing tables
for some AFN/SAFI pairs, which are used if the
corresponding entry is not configured.
";
leaf name {
type leafref {
path "../../../../../routing-tables/routing-table/"
+ "name";
}
description
"This must be the name of an existing routing
table.";
}
leaf import-filter {
type leafref {
path "../../../../../route-filters/route-filter/"
+ "name";
}
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
'name' 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 leafref {
path "../../../../../route-filters/route-filter/"
+ "name";
}
description
"Reference to a route filter that is used for
filtering routes passed from the routing table
specified by the 'name' sibling node 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 any
routing table.";
}
}
} }
} }
} }
container route-filters { container route-filters {
description description
"Container for configured route filters."; "Container for configured route filters.";
list route-filter { list route-filter {
key "name"; key "name";
description description
"Route filters are used for filtering and/or manipulating "Route filters are used for filtering and/or manipulating
routes that are passed between a routing protocol and a routes that are passed between a routing protocol and a
routing table or vice versa, or between two routing routing table or vice versa, or between two routing
tables. It is expected that other modules augment this tables. It is expected that other modules augment this
list with contents specific for a particular route list with contents specific for a particular route
filter type."; filter type.";
leaf name { leaf name {
type string; type string;
description description
"The name of the route filter."; "The name of the route filter.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route filter."; "Textual description of the route filter.";
} }
leaf type { leaf type {
type identityref { type identityref {
base rt:route-filter; base route-filter;
} }
default "rt:deny-all-route-filter"; default "deny-all-route-filter";
description description
"Type of the route-filter - an identity derived "Type of the route-filter - an identity derived from
from the 'rt:route-filter' base identity. The default the 'route-filter' base identity. The default value
value represents an all-blocking filter."; represents an all-blocking filter.";
} }
} }
} }
container routing-tables { container routing-tables {
must "routing-table/name='ipv4-unicast-fib'" {
description
"IPv4 unicast forwarding information base.";
}
must "routing-table/name='ipv4-unicast-main'" {
description
"The main IPv4 unicast routing table.";
}
description description
"Container for configured routing tables."; "Container for configured routing tables.";
list routing-table { list routing-table {
key "name"; key "name";
description description
"Each entry represents a configured routing table. At "Each entry represents a routing table identified by the
least two entries with names 'ipv4-unicast-fib' and 'name' key. All routes in a routing table must have the
'ipv4-unicast-main' must exist."; same AFN and SAFI.";
container routes {
config false;
description
"Current contents of the routing table. Note that
it is operational state data.";
list route {
description
"A routing table entry.";
leaf destination-prefix {
type inet:ipv4-prefix;
description
"Destination prefix.";
}
leaf next-hop {
type inet:ipv4-address;
description
"IPv4 address of the next hop.";
}
leaf outgoing-interface {
type if:interface-ref;
description
"Name of the outgoing interface.";
}
leaf source-protocol {
type leafref {
path "../../../../../routing-protocol-instances/"
+ "routing-protocol-instance/name";
}
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.";
}
}
}
leaf name { leaf name {
type string; type string;
description description
"The name of the routing table."; "The name of the routing table.";
} }
uses afn-safi;
leaf description { leaf description {
type string; type string;
description description
"Textual description of the routing table."; "Textual description of the routing table.";
} }
container routes {
config "false";
description
"Current contents of the routing table (operational
state data).";
list route {
description
"A routing table entry. It is expected that this data
node will be augmented with information specific for
routes of each address family.";
uses route-content;
}
}
list recipient-routing-tables { list recipient-routing-tables {
key "recipient-name"; key "recipient-name";
description description
"A list of routing tables that receive routes from "A list of routing tables that receive routes from this
the parent routing table."; routing table.";
leaf recipient-name { leaf recipient-name {
type leafref { type leafref {
path "../../../routing-table/name"; path "../../../routing-table/name";
} }
description description
"The name of the recipient routing table."; "The name of the recipient routing table.";
} }
leaf filter { leaf filter {
type leafref { type leafref {
path "../../../../route-filters/route-filter/name"; path "../../../../route-filters/route-filter/name";
} }
description description
"A route filter which is applied to the routes "A route filter which is applied to the routes passed
passed on to the recipient routing table."; on to the recipient routing table.";
} }
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. IANA Considerations 7. IPv4 Unicast Routing YANG Module
This document registers the following two namespace URIs in the IETF RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
XML registry [RFC3688]: actual RFC number and all occurrences of the revision date below with
the date of RFC publication (and remove this note).
<CODE BEGINS> file "ietf-ipv4-unicast-routing@2011-09-23.yang"
module ietf-ipv4-unicast-routing {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing";
prefix "v4ur";
import ietf-routing {
prefix "rt";
}
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 augments the 'ietf-routing' module with YANG
definitions for basic configuration of IPv4 unicast routing.
Copyright (c) 2011 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.
";
revision 2011-09-23 {
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for Routing Configuration";
}
/* Groupings */
grouping route-content {
description
"Specific parameters of IPv4 unicast routes.";
leaf destination-prefix {
type inet:ipv4-prefix;
description
"IPv4 destination prefix.";
}
leaf next-hop {
type inet:ipv4-address;
description
"IPv4 address of the next hop.";
}
leaf outgoing-interface {
type if:interface-ref;
description
"Outgoing interface.";
}
}
/* RPC Methods */
augment "/rt:get-route/rt:input/rt:destination-address" {
when "address-family='ipV4' and safi='nlri-unicast'" {
description
"This augment is valid only for IPv4 unicast.";
}
description
"The 'address' leaf augments the 'rt:destination-address'
parameter of the 'rt:get-route' operation.";
leaf address {
type inet:ipv4-address;
description
"IPv4 destination address.";
}
}
augment "/rt:get-route/rt:output/rt:route" {
when "address-family='ipV4' and safi='nlri-unicast'" {
description
"This augment is valid only for IPv4 unicast.";
}
description
"Contents of the reply to 'rt:get-route' operation.";
uses route-content;
}
/* Data nodes */
augment "/rt:routing/rt:router/rt:routing-protocols/"
+ "rt:routing-protocol" {
when "rt:type='rt:static'" {
description
"The augment is only valid for the 'static'
pseudo-protocol.";
}
description
"This augment defines the configuration of the static
pseudo-protocol with data specific for IPv4 unicast.";
container ipv4-unicast-static-routes {
description
"Configuration of a 'static' pseudo-protocol instance
consists of a list of routes.";
list static-route {
key "id";
ordered-by "user";
description
"A user-ordered list of static routes.";
leaf id {
type string;
description
"An identification string for the route.";
}
leaf description {
type string;
description
"Textual description of the route.";
}
uses route-content;
}
}
}
augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
+ "rt:routes/rt:route" {
when "../../rt:address-family='ipV4' and "
+ "../../rt:safi='nlri-unicast'" {
description
"This augment is valid only for IPv4 unicast.";
}
description
"This augment defines the content of IPv4 unicast routes.";
uses route-content;
}
}
<CODE ENDS>
8. IANA Considerations
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number (and remove this note).
This document registers the following namespace URIs in the IETF XML
registry [RFC3688]:
---------------------------------------------------------- ----------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-routing URI: urn:ietf:params:xml:ns:yang:ietf-routing
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
---------------------------------------------------------- ----------------------------------------------------------
---------------------------------------------------------- ----------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
---------------------------------------------------------- ----------------------------------------------------------
This document registers two YANG modules in the YANG Module Names ----------------------------------------------------------
registry [RFC6020]: URI: urn:ietf:params:xml:ns:yang:iana-afn-safi
Registrant Contact: IANA.
XML: N/A, the requested URI is an XML namespace.
----------------------------------------------------------
This document registers the following YANG modules in the YANG Module
Names registry [RFC6020]:
------------------------------------------------------------------- -------------------------------------------------------------------
name: ietf-routing name: ietf-routing
namespace: urn:ietf:params:xml:ns:yang:ietf-routing namespace: urn:ietf:params:xml:ns:yang:ietf-routing
prefix: rt prefix: rt
reference: RFC XXXX reference: RFC XXXX
------------------------------------------------------------------- -------------------------------------------------------------------
------------------------------------------------------------------- -------------------------------------------------------------------
name: ietf-ipv4-unicast-routing name: ietf-ipv4-unicast-routing
namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
prefix: v4ur prefix: v4ur
reference: RFC XXXX reference: RFC XXXX
------------------------------------------------------------------- -------------------------------------------------------------------
8. Security Considerations -------------------------------------------------------------------
name: iana-afn-safi
namespace: urn:ietf:params:xml:ns:yang:iana-afn-safi
prefix: ianaaf
reference: RFC XXXX
-------------------------------------------------------------------
TBD. 9. Security Considerations
9. Acknowledgments The YANG modules defined in this document are designed to be accessed
via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure
transport is SSH [RFC6242].
The author wishes to thank Juergen Schoenwaelder and Martin Bjorklund A number of data nodes defined in the YANG modules are writable/
for their helpful comments and suggestions. creatable/deletable (i.e., "config true" in YANG terms, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations to these data nodes,
such as "edit-config", can have negative effects on the network if
the operations are not properly protected.
10. References The vulnerable "config true" subtrees and data nodes are the
following:
10.1. Normative References /rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This
list specifies the routing protocols configured on a device.
[IANA-AFI] /rt:routing/rt:router/rt:route-filters/rt:route-filter This list
specifies the configured route filters which represent the
administrative policies for redistributing and modifying routing
information.
Unauthorized access to any of these lists can adversely affect the
routing subsystem of both the local device and the network. This may
lead to network malfunctions, delivery of packets to inappropriate
destinations and other problems.
10. Acknowledgments
The author wishes to thank Martin Bjorklund, Joel Halpern, Tom Petch
and Juergen Schoenwaelder for their helpful comments and suggestions.
11. References
11.1. Normative References
[IANA-AFN]
IANA, "Address Family Numbers.", January 2011. IANA, "Address Family Numbers.", January 2011.
[IANA-SAFI] [IANA-SAFI]
IANA, "Subsequent Address Family Identifiers (SAFI) IANA, "Subsequent Address Family Identifiers (SAFI)
Parameters.", March 2011. Parameters.", March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
September 2010. September 2010.
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6021, September 2010. RFC 6021, September 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "NETCONF Configuration Protocol", RFC 6241,
June 2011.
[YANG-IF] Bjorklund, M., "A YANG Data Model for Interface [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface
Configuration", draft-bjorklund-netmod-interfaces-cfg-00 Configuration", draft-ietf-netmod-interfaces-cfg-02 (work
(work in progress), December 2010. in progress), September 2011.
10.2. Informative References [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration",
draft-ietf-netmod-ip-cfg-00 (work in progress),
September 2011.
11.2. Informative References
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, January 2011. Data Model Documents", RFC 6087, January 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
Appendix A. Example - Adding a New Routing Protocol Appendix A. Example - Adding a New Routing Protocol
This appendix demonstrates how the core routing data model can be This appendix demonstrates how the core routing data model can be
extended to support a new routing protocol. Appendix A.1 contains a extended to support a new routing protocol. Appendix A.1 contains
YANG module which is used for this purpose. It is intended only as the YANG module which is used for this purpose. It is intended only
an illustration and not as a real definition of a data model for the as an illustration and not as a real definition of a data model for
RIP routing protocol. Also, for the sake of brevity, we do not the RIP routing protocol. Also, for the sake of brevity, we do not
follow all the guidelines specified in [RFC6087]. follow all the guidelines specified in [RFC6087].
Appendix A.2 then contains a complete instance XML document - a reply 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 to the NETCONF <get> message from a server that uses the RIP protocol
as well as static routing. as well as static routing.
A.1. Example YANG Module for Routing Information Protocol A.1. Example YANG Module for Routing Information
Protocol
<CODE BEGINS> file "example-rip@2011-09-23.yang"
module example-rip { module example-rip {
namespace "http://example.com/rip"; namespace "http://example.com/rip";
prefix rip;
import ietf-interfaces { prefix "rip";
prefix if;
}
import ietf-routing { import ietf-routing {
prefix rt; prefix "rt";
}
import ietf-interfaces {
prefix "if";
} }
identity rip { identity rip {
base rt:routing-protocol; base rt:routing-protocol;
description description
"Identity for the RIP routing protocol."; "Identity for the RIP routing protocol.";
} }
typedef rip-metric { typedef rip-metric {
type uint8 { type uint8 {
range "0..16"; range "0..16";
} }
} }
augment "/rt:routing/rt:routing-protocol-instances/" + grouping route-content {
"rt:routing-protocol-instance" { description
when "rt:type='rip:rip'"; "RIP-specific route content.";
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.";
}
}
augment "/rt:get-route/rt:output/rt:route" {
description
"Add RIP-specific route content.";
uses route-content;
}
augment "/rt:routing/rt:router/rt:routing-protocols/"
+ "rt:routing-protocol" {
when "rt:type = 'rip:rip'";
container rip-configuration { container rip-configuration {
container rip-interfaces { container rip-interfaces {
list rip-interface { list rip-interface {
key "name"; key "name";
leaf name { leaf name {
type if:interface-ref; type if:interface-ref;
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
default "true"; default "true";
} }
leaf metric { leaf metric {
type rip-metric; type rip-metric;
default "1"; default "1";
} }
/* Additional per-interface RIP configuration */
} }
} }
leaf update-interval { leaf update-interval {
type uint8 { type uint8 {
range "10..60"; range "10..60";
} }
units "seconds"; units "seconds";
default "30"; default "30";
description description
"Time interval between periodic updates."; "Time interval between periodic updates.";
} }
/* Additional RIP configuration */
} }
} }
augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:route" { augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
when "../../../rt:routing-protocol-instances/" + + "rt:routes/rt:route" {
"rt:routing-protocol-instance[rt:name=" + when "../../../../rt:routing-protocols/"
"current()/rt:source-protocol]/rt:type='rip:rip'"; + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/"
description + "rt:type='rip:rip'" {
"RIP-specific route components.";
leaf metric {
type rip-metric;
}
leaf tag {
type uint16;
default "0";
description description
"This leaf may be used to carry additional info, e.g. AS "This augment is only valid if the source protocol from which
number."; the route originated is RIP.";
} }
description
"RIP-specific route components.";
uses route-content;
} }
} }
<CODE ENDS>
A.2. Sample Reply to the NETCONF <get> Message A.2. Sample Reply to the NETCONF <get> Message
This section contains a sample reply to the NETCONF <get> message, This section contains a sample reply to the NETCONF <get> message,
which could be sent by a server supporting (and advertizing in which could be sent by a server supporting (and advertising in the
<hello>) the following YANG modules: NETCONF <hello> message) the following YANG modules:
o ietf-interfaces [YANG-IF], o ietf-interfaces [YANG-IF],
o ex-ethernet [YANG-IF], o ex-ethernet [YANG-IF],
o ex-ip [YANG-IF], o ietf-ip [YANG-IP],
o ietf-routing (Section 5), o ietf-routing (Section 6),
o ietf-ipv4-unicast-routing (Section 6), o ietf-ipv4-unicast-routing (Section 7),
o example-rip (Appendix A.1). o example-rip (Appendix A.1).
We assume a simple network setup as shown in Figure 2: routers "ISP" We assume a simple network setup as shown in Figure 3: routers "ISP"
and "A" use RIP for exchanging routing information whereas static and "A" use RIP for exchanging routing information whereas static
routing is used in the private network. In order to avoid the routing is used in the private network. In order to avoid the
redistribution of the routes to the private subnetworks redistribution of the routes to the private subnetworks
192.168.1.0/24 and 192.168.2.0/24 in RIP, an export filter is used in 192.168.1.0/24 and 192.168.2.0/24 in RIP, an export filter is used in
the RIP protocol configuration preventing the routes from the main the RIP protocol configuration preventing the routes from the main
routing table from appearing in RIP updates. routing table from appearing in RIP updates.
+-----------------+ +-----------------+
| | | |
| Router ISP | | Router ISP |
skipping to change at page 40, line 5 skipping to change at page 46, line 31
| |
|192.168.1.254 |192.168.1.254
+--------+--------+ +--------+--------+
| | | |
| Router B | | Router B |
| | | |
+--------+--------+ +--------+--------+
|192.168.2.1 |192.168.2.1
| |
Figure 2: Example network configuration Figure 3: Example network configuration
Router "A" then could send the following XML document as its reply to Router "A" then could send the following XML document as its reply to
the NETCONF <get> message: the NETCONF <get> message:
<?xml version="1.0"?> <?xml version="1.0"?>
<nc:rpc-reply <nc:rpc-reply
message-id="101" message-id="101"
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing" xmlns="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:eth="http://example.com/ethernet" xmlns:eth="http://example.com/ethernet"
xmlns:ip="http://example.com/ip" xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip"
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing" xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:rip="http://example.com/rip"> xmlns:rip="http://example.com/rip">
<nc:data> <nc:data>
<if:interfaces> <if:interfaces>
<if:interface> <if:interface>
<if:name>eth0</if:name> <if:name>eth0</if:name>
<if:type>ethernetCsmacd</if:type> <if:type>ethernetCsmacd</if:type>
<if:location>05:00.0</if:location> <if:location>05:00.0</if:location>
<ip:ip> <ip:ipv4>
<ip:address> <ip:address>
<ip:ip>192.0.2.1</ip:ip> <ip:ip>192.0.2.1</ip:ip>
<ip:prefix-length>24</ip:prefix-length> <ip:prefix-length>24</ip:prefix-length>
</ip:address> </ip:address>
</ip:ip> </ip:ipv4>
</if:interface> </if:interface>
<if:interface> <if:interface>
<if:name>eth1</if:name> <if:name>eth1</if:name>
<if:type>ethernetCsmacd</if:type> <if:type>ethernetCsmacd</if:type>
<if:location>05:00.1</if:location> <if:location>05:00.1</if:location>
<ip:ip> <ip:ipv4>
<ip:address> <ip:address>
<ip:ip>192.168.1.1</ip:ip> <ip:ip>192.168.1.1</ip:ip>
<ip:prefix-length>24</ip:prefix-length> <ip:prefix-length>24</ip:prefix-length>
</ip:address> </ip:address>
</ip:ip> </ip:ipv4>
</if:interface> </if:interface>
</if:interfaces> </if:interfaces>
<rt:routing> <rt:routing>
<rt:routing-process> <rt:router>
<rt:name>inet-0</rt:name> <rt:name>inet-0</rt:name>
<rt:address-family>ipV4</rt:address-family> <rt:routing-protocols>
<rt:safi>nlri-unicast</rt:safi> <rt:routing-protocol>
<ipv4-unicast-routing> <rt:name>direct</rt:name>
<routing-protocol-instances> <rt:type>rt:direct</rt:type>
<routing-protocol-instance> </rt:routing-protocol>
<name>direct</name> <rt:routing-protocol>
<type>rt:direct</type> <rt:name>st0</rt:name>
</routing-protocol-instance> <rt:description>
<routing-protocol-instance> Static routing is used for the internal network.
<name>st0</name> </rt:description>
<description> <rt:type>rt:static</rt:type>
Static routing is used for the internal network. <ipv4-unicast-static-routes>
</description> <static-route>
<type>rt:static</type> <id>id-6378</id>
<static-routes> <destination-prefix>192.168.2.0/24</destination-prefix>
<static-route> <next-hop>192.168.1.254</next-hop>
<id>id-6378</id> </static-route>
<destination-prefix>192.168.2.0/24</destination-prefix> </ipv4-unicast-static-routes>
<next-hop>192.168.1.254</next-hop> </rt:routing-protocol>
</static-route> <rt:routing-protocol>
</static-routes> <rt:name>rip0</rt:name>
</routing-protocol-instance> <rt:description>
<routing-protocol-instance> RIP is used on the uplink. Static routes to the
<name>rip0</name> internal networks are not advertized in RIP.
<description> </rt:description>
RIP is used on the uplink. <rt:type>rip:rip</rt:type>
Static routes to the internal networks are not <rt:connected-routing-tables>
advertized in RIP. <rt:connected-routing-table>
</description> <rt:name>ipv4-unicast-main</rt:name>
<type>rip:rip</type> <rt:export-filter>deny-all</rt:export-filter>
<export-filter>deny-all</export-filter> </rt:connected-routing-table>
<rip:rip-configuration> </rt:connected-routing-tables>
<rip:rip-interfaces> <rip:rip-configuration>
<rip:rip-interface> <rip:rip-interfaces>
<rip:name>eth0</rip:name> <rip:rip-interface>
</rip:rip-interface> <rip:name>eth0</rip:name>
</rip:rip-interfaces> </rip:rip-interface>
</rip:rip-configuration> </rip:rip-interfaces>
</routing-protocol-instance> </rip:rip-configuration>
</routing-protocol-instances> </rt:routing-protocol>
<route-filters> </rt:routing-protocols>
<route-filter> <rt:route-filters>
<name>deny-all</name> <rt:route-filter>
</route-filter> <rt:name>deny-all</rt:name>
</route-filters> </rt:route-filter>
<routing-tables> </rt:route-filters>
<routing-table> <rt:routing-tables>
<name>ipv4-unicast-fib</name> <rt:routing-table>
<routes> <rt:name>ipv4-unicast-fib</rt:name>
<route> <rt:routes>
<destination-prefix>192.0.2.1/24</destination-prefix> <rt:route>
<source-protocol>direct</source-protocol> <destination-prefix>192.0.2.1/24</destination-prefix>
<outgoing-interface>eth0</outgoing-interface> <rt:source-protocol>direct</rt:source-protocol>
<last-modified>2010-04-01T17:11:27+01:00</last-modified> <outgoing-interface>eth0</outgoing-interface>
</route> <rt:last-modified>2011-09-23T17:11:27+01:00</rt:last-modified>
<route> </rt:route>
<destination-prefix>192.168.1.0/24</destination-prefix> <rt:route>
<source-protocol>direct</source-protocol> <destination-prefix>192.168.1.0/24</destination-prefix>
<outgoing-interface>eth1</outgoing-interface> <rt:source-protocol>direct</rt:source-protocol>
<last-modified>2010-04-01T17:11:27+01:00</last-modified> <outgoing-interface>eth1</outgoing-interface>
</route> <rt:last-modified>2011-09-23T17:11:27+01:00</rt:last-modified>
<route> </rt:route>
<destination-prefix>192.168.2.0/24</destination-prefix> <rt:route>
<source-protocol>st0</source-protocol> <destination-prefix>192.168.2.0/24</destination-prefix>
<next-hop>192.168.1.254</next-hop> <rt:source-protocol>st0</rt:source-protocol>
<last-modified>2010-04-01T17:11:32+01:00</last-modified> <next-hop>192.168.1.254</next-hop>
</route> <rt:last-modified>2011-09-23T17:11:32+01:00</rt:last-modified>
<route> </rt:route>
<destination-prefix>0.0.0.0/0</destination-prefix> <rt:route>
<source-protocol>rip0</source-protocol> <destination-prefix>0.0.0.0/0</destination-prefix>
<next-hop>192.168.1.254</next-hop> <rt:source-protocol>rip0</rt:source-protocol>
<rip:metric>2</rip:metric> <next-hop>192.0.2.2</next-hop>
<rip:tag>64500</rip:tag> <rip:metric>2</rip:metric>
<last-modified>2010-04-01T18:02:45+01:00</last-modified> <rip:tag>64500</rip:tag>
</route> <rt:last-modified>2011-09-23T18:02:45+01:00</rt:last-modified>
</routes> </rt:route>
</routing-table> </rt:routes>
<routing-table> </rt:routing-table>
<name>ipv4-unicast-main</name> <rt:routing-table>
<recipient-routing-tables> <rt:name>ipv4-unicast-main</rt:name>
<recipient-name>ipv4-unicast-fib</recipient-name> <rt:recipient-routing-tables>
</recipient-routing-tables> <rt:recipient-name>ipv4-unicast-fib</rt:recipient-name>
<routes> </rt:recipient-routing-tables>
<route> <rt:routes>
<destination-prefix>192.0.2.1/24</destination-prefix> <rt:route>
<source-protocol>direct</source-protocol> <destination-prefix>192.0.2.1/24</destination-prefix>
<outgoing-interface>eth0</outgoing-interface> <rt:source-protocol>direct</rt:source-protocol>
<last-modified>2010-04-01T17:11:27+01:00</last-modified> <outgoing-interface>eth0</outgoing-interface>
</route> <rt:last-modified>2011-09-23T17:11:27+01:00</rt:last-modified>
<route> </rt:route>
<destination-prefix>192.168.1.0/24</destination-prefix> <rt:route>
<source-protocol>direct</source-protocol> <destination-prefix>192.168.1.0/24</destination-prefix>
<outgoing-interface>eth1</outgoing-interface> <rt:source-protocol>direct</rt:source-protocol>
<last-modified>2010-04-01T17:11:27+01:00</last-modified> <outgoing-interface>eth1</outgoing-interface>
</route> <rt:last-modified>2011-09-23T17:11:27+01:00</rt:last-modified>
<route> </rt:route>
<destination-prefix>192.168.2.0/24</destination-prefix> <rt:route>
<source-protocol>st0</source-protocol> <destination-prefix>192.168.2.0/24</destination-prefix>
<next-hop>192.168.1.254</next-hop> <rt:source-protocol>st0</rt:source-protocol>
<last-modified>2010-04-01T17:11:32+01:00</last-modified> <next-hop>192.168.1.254</next-hop>
<rt:last-modified>2011-09-23T17:11:32+01:00</rt:last-modified>
</route> </rt:route>
<route> <rt:route>
<destination-prefix>0.0.0.0/0</destination-prefix> <destination-prefix>0.0.0.0/0</destination-prefix>
<source-protocol>rip0</source-protocol> <rt:source-protocol>rip0</rt:source-protocol>
<next-hop>192.168.1.254</next-hop> <next-hop>192.0.2.2</next-hop>
<rip:metric>2</rip:metric> <rip:metric>2</rip:metric>
<rip:tag>64500</rip:tag> <rip:tag>64500</rip:tag>
<last-modified>2010-04-01T18:02:45+01:00</last-modified> <rt:last-modified>2011-09-23T18:02:45+01:00</rt:last-modified>
</route> </rt:route>
</routes> </rt:routes>
</routing-table> </rt:routing-table>
</routing-tables> </rt:routing-tables>
</ipv4-unicast-routing> </rt:router>
</rt:routing-process>
</rt:routing> </rt:routing>
</nc:data> </nc:data>
</nc:rpc-reply> </nc:rpc-reply>
Appendix B. Change Log
RFC Editor: remove this section upon publication as an RFC.
B.1. Changes Between Versions -00 and -01
o AFN/SAFI-independent stuff was moved to the "ietf-routing" module.
o Typedefs for AFN and SAFI were placed in a separate "iana-afn-
safi" module.
o Names of some data nodes were changed, in particular "routing-
process" is now "router".
o The restriction of a single AFN/SAFI per router was lifted.
o RPC operation "delete-route" was removed.
o Illegal XPath references from "get-route" to the datastore were
fixed.
o Section "Security Considerations" was written.
Author's Address Author's Address
Ladislav Lhotka Ladislav Lhotka
CESNET CESNET
Email: lhotka@cesnet.cz Email: lhotka@cesnet.cz
 End of changes. 244 change blocks. 
907 lines changed or deleted 1230 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/