< draft-ietf-netmod-routing-cfg-02.txt   draft-ietf-netmod-routing-cfg-03.txt >
NETMOD L. Lhotka NETMOD L. Lhotka
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track February 20, 2012 Intended status: Standards Track May 25, 2012
Expires: August 23, 2012 Expires: November 26, 2012
A YANG Data Model for Routing Configuration A YANG Data Model for Routing Configuration
draft-ietf-netmod-routing-cfg-02 draft-ietf-netmod-routing-cfg-03
Abstract Abstract
This document contains a specification of four YANG modules. This document contains a specification of three YANG modules.
Together they form the core routing data model which serves as a Together they form the core routing data model which serves as a
basis for configuring a routing subsystem. It is therefore expected framework for configuring a routing subsystem. It is therefore
that this module will be augmented by additional YANG modules expected that this module will be augmented by additional YANG
defining data models for individual routing protocols and other modules defining data models for individual routing protocols and
related functions. The core routing data model provides common other related functions. The core routing data model provides common
building blocks for such configurations - router instances, routes, building blocks for such configurations - router instances, routes,
routing tables, routing protocols and route filters. routing tables, routing protocols and route 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 August 23, 2012. This Internet-Draft will expire on November 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 21 skipping to change at page 2, line 21
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. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 10 4.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 10
4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 13 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 13
4.4.1. Defining New Routing Protocols . . . . . . . . . . . . 14 4.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 14
4.4.2. Defining New Routing Protocols . . . . . . . . . . . . 14
4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 17
4.6. RPC Operation . . . . . . . . . . . . . . . . . . . . . . 18 4.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 18
5. IANA AFN and SAFI YANG Module . . . . . . . . . . . . . . . . 19 4.6.1. Operation "active-route" . . . . . . . . . . . . . . . 18
6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 27 4.6.2. Operation "route-count" . . . . . . . . . . . . . . . 19
7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 37 5. Interactions with Other YANG Modules . . . . . . . . . . . . . 20
8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 41 5.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 5.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . . 53 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
Appendix A. Example: Adding a New Routing Protocol . . . . . . . 54 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix B. Example: Reply to the NETCONF <get> Message . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 63 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
C.1. Changes Between Versions -01 and -02 . . . . . . . . . . . 63 12.2. Informative References . . . . . . . . . . . . . . . . . . 51
C.2. Changes Between Versions -00 and -01 . . . . . . . . . . . 63 Appendix A. Example: Adding a New Routing Protocol . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 Appendix B. Example: Reply to the NETCONF <get> Message . . . . . 55
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 60
C.1. Changes Between Versions -02 and -03 . . . . . . . . . . . 60
C.2. Changes Between Versions -01 and -02 . . . . . . . . . . . 60
C.3. Changes Between Versions -00 and -01 . . . . . . . . . . . 61
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
This document contains a specification of four YANG modules: This document contains a specification of the following YANG modules:
o Module "ietf-routing" provides generic components of a routing o Module "ietf-routing" provides generic components of a routing
data model. data model.
o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing"
module with additional data specific to IPv4 unicast. module with additional data specific to IPv4 unicast.
o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing"
module with additional data specific to IPv6 unicast, including module with additional data specific to IPv6 unicast, including
the configuration variables required by [RFC4861]. the router configuration variables required by [RFC4861].
o Module "iana-afn-safi" contains two type definitions translating
IANA registries "Address Family Numbers" [IANA-AFN] and
"Subsequent Address Family Identifiers" [IANA-SAFI] to YANG
enumerations.
The first three modules together define the so-called core routing These modules together define the so-called core routing data model,
data model. This data model will serve as a basis for the which is proposed as a basis for the development of data models for
development of data models for more sophisticated routing more sophisticated routing configurations. While these three modules
configurations. While these three modules can be directly used for can be directly used for simple IP devices with static routing, their
simple IP devices with static routing, their main purpose is to main purpose is to provide essential building blocks for more
provide essential building blocks for more complicated setups complicated setups involving multiple routing protocols, multicast
involving multiple routing protocols, multicast routing, additional routing, additional address families, advanced functions such as
address families, advanced functions such as route filtering or route filtering or policy routing etc. To this end, it is expected
policy routing etc. To this end, it is expected that the core that the core routing data model will be augmented by numerous
routing data model will be augmented by numerous modules developed by modules developed by other IETF working groups.
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 [RFC6241]: The following terms are defined in [RFC6241]:
o client o client
o message o message
o operation o protocol operation
o server o server
The following terms are defined in [RFC6020]: The following terms are defined in [RFC6020]:
o augment o augment
o configuration data o configuration data
o container o container
skipping to change at page 5, line 4 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. active route: a route which is actually used for sending packets.
If there are multiple candidate routes with a matching destination If there are multiple candidate routes with a matching destination
prefix, then it is up to the routing algorithm to select the prefix, then it is up to the routing algorithm to select the
active route. active route (or several active routes in the case of multi-path
routing).
core routing data model: YANG data model resulting from the core routing data model: YANG data model resulting from the
combination of "ietf-routing", "ietf-ipv4-unicast-routing-cfg" and combination of "ietf-routing", "ietf-ipv4-unicast-routing" and
"ietf-ipv6-unicast-routing-cfg" modules. "ietf-ipv6-unicast-routing" modules.
direct route: a route to a directly connected network. direct route: a route to a directly connected network.
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 their each name is defined. Otherwise, names are prefixed using the
standard prefix associated with the corresponding YANG module, as standard prefix associated with the corresponding YANG module, as
shown in Table 1. shown in Table 1.
+--------+---------------------------+------------+ +--------+---------------------------+--------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+--------+---------------------------+------------+ +--------+---------------------------+--------------+
| eth | ex-ethernet | [YANG-IF] | | ianaaf | iana-afn-safi | [IANA-IF-AF] |
| | | | | | | |
| if | ietf-interfaces | [YANG-IF] | | if | ietf-interfaces | [YANG-IF] |
| | | | | | | |
| ip | ietf-ip | [YANG-IP] | | ip | ietf-ip | [YANG-IP] |
| | | | | | | |
| rip | example-rip | Appendix A | | rip | example-rip | Appendix A |
| | | | | | | |
| rt | ietf-routing | Section 6 | | rt | ietf-routing | Section 6 |
| | | | | | | |
| v4ur | ietf-ipv4-unicast-routing | Section 7 | | v4ur | ietf-ipv4-unicast-routing | Section 7 |
| | | | | | | |
| v6ur | ietf-ipv6-unicast-routing | Section 8 | | v6ur | ietf-ipv6-unicast-routing | Section 8 |
| | | | | | | |
| yang | ietf-yang-types | [RFC6021] | | yang | ietf-yang-types | [RFC6021] |
| | | | | | | |
| inet | ietf-inet-types | [RFC6021] | | inet | ietf-inet-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 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 in particular IPv4 and IPv6, and for unicast and multicast
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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 three YANG modules. The The core routing data model consists of three YANG modules. The
first module, "ietf-routing", defines the generic components of a first module, "ietf-routing", defines the generic components of a
routing system. The other two modules, "ietf-ipv4-unicast-routing" routing system. The other two modules, "ietf-ipv4-unicast-routing"
and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module
with additional data nodes that are needed for IPv4 and IPv6 unicast with additional data nodes that are needed for IPv4 and IPv6 unicast
routing, respectively. The combined data hierarchy is shown in routing, respectively. The combined data hierarchy is shown in
Figure 1, where brackets contain list keys and question marks Figure 1, where brackets enclose list keys, "rw" means configuration,
indicate optional data nodes. Nodes that represent configuration are "ro" operational state data, and "?" means optional node.
labeled with "rw" while operational state data have the "ro" label. Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
+--rw routing +--rw routing
+--rw router [name] +--rw router [name]
+--rw name | +--rw name
+--rw description? | +--rw router-id?
+--rw enabled? | +--rw description?
+--rw interfaces | +--rw enabled?
| +--rw interface [name] | +--rw interfaces
| +--rw name | | +--rw interface [name]
| +--rw v6ur:ipv6-router-advertisements | | +--rw name
| +--rw v6ur:send-advertisements? | | +--rw v6ur:ipv6-router-advertisements
| +--rw v6ur:max-rtr-adv-interval? | | +--rw v6ur:send-advertisements?
| +--rw v6ur:min-rtr-adv-interval? | | +--rw v6ur:max-rtr-adv-interval?
| +--rw v6ur:managed-flag? | | +--rw v6ur:min-rtr-adv-interval?
| +--rw v6ur:other-config-flag? | | +--rw v6ur:managed-flag?
| +--rw v6ur:link-mtu? | | +--rw v6ur:other-config-flag?
| +--rw v6ur:reachable-time? | | +--rw v6ur:link-mtu?
| +--rw v6ur:retrans-timer? | | +--rw v6ur:reachable-time?
| +--rw v6ur:cur-hop-limit? | | +--rw v6ur:retrans-timer?
| +--rw v6ur:default-lifetime? | | +--rw v6ur:cur-hop-limit?
| +--rw v6ur:prefix-list | | +--rw v6ur:default-lifetime?
| +--rw v6ur:prefix [seqno] | | +--rw v6ur:prefix-list
| +--rw v6ur:seqno | | +--rw v6ur:prefix [prefix-spec]
| +--rw v6ur:prefix-spec? | | +--rw v6ur:prefix-spec
| +--rw v6ur:valid-lifetime? | | +--rw (control-adv-prefixes)?
| +--rw v6ur:on-link-flag? | | +--:(no-advertise)
| +--rw v6ur:preferred-lifetime? | | | +--rw v6ur:no-advertise?
| +--rw v6ur:autonomous-flag? | | +--:(advertise)
+--rw routing-protocols | | +--rw v6ur:valid-lifetime?
| +--rw routing-protocol [name] | | +--rw v6ur:on-link-flag?
| +--rw name | | +--rw v6ur:preferred-lifetime?
| +--rw description? | | +--rw v6ur:autonomous-flag?
| +--rw type | +--rw routing-protocols
| +--rw connected-routing-tables | | +--rw routing-protocol [name]
| | +--rw routing-table [name] | | +--rw name
| | +--rw name | | +--rw description?
| | +--rw import-filter? | | +--rw type
| | +--rw export-filter? | | +--rw connected-routing-tables
| +--rw static-routes | | | +--rw routing-table [name]
| +--rw v4ur:ipv4 | | | +--rw name
| | +--rw v4ur:route [seqno] | | | +--rw import-filter?
| | +--rw v4ur:seqno | | | +--rw export-filter?
| | +--rw v4ur:description? | | +--rw static-routes
| | +--rw v4ur:outgoing-interface? | | +--rw v4ur:ipv4
| | +--rw v4ur:dest-prefix? | | | +--rw v4ur:route [seqno]
| | +--rw v4ur:next-hop? | | | +--rw v4ur:seqno
| +--rw v6ur:ipv6 | | | +--rw v4ur:description?
| +--rw v6ur:route [seqno] | | | +--rw v4ur:outgoing-interface?
| +--rw v6ur:seqno | | | +--rw v4ur:dest-prefix
| +--rw v6ur:description? | | | +--rw v4ur:next-hop?
| +--rw v6ur:outgoing-interface? | | +--rw v6ur:ipv6
| +--rw v6ur:dest-prefix? | | +--rw v6ur:route [seqno]
| +--rw v6ur:next-hop? | | +--rw v6ur:seqno
+--rw route-filters | | +--rw v6ur:description?
| +--rw route-filter [name] | | +--rw v6ur:outgoing-interface?
| +--rw name | | +--rw v6ur:dest-prefix
| +--rw description? | | +--rw v6ur:next-hop?
| +--rw type? | +--rw routing-tables
+--rw routing-tables | +--rw routing-table [name]
+--rw routing-table [name] | +--rw name
+--rw name | +--rw address-family?
+--rw address-family? | +--rw safi?
+--rw safi? | +--rw description?
+--rw description? | +--ro routes
+--ro routes | | +--ro route
| +--ro route | | +--ro source-protocol
| +--ro source-protocol? | | +--ro age
| +--ro last-modified? | | +--ro v4ur:outgoing-interface?
| +--ro v4ur:outgoing-interface? | | +--ro v4ur:dest-prefix?
| +--ro v4ur:dest-prefix? | | +--ro v4ur:next-hop?
| +--ro v4ur:next-hop? | | +--ro v6ur:outgoing-interface?
| +--ro v6ur:outgoing-interface? | | +--ro v6ur:dest-prefix?
| +--ro v6ur:dest-prefix? | | +--ro v6ur:next-hop?
| +--ro v6ur:next-hop? | +--rw recipient-routing-tables
+--rw recipient-routing-tables [recipient-name] | +--rw recipient-routing-table [name]
+--rw recipient-name | +--rw name
+--rw filter? | +--rw filter?
+--rw route-filters
+--rw route-filter [name]
+--rw name
+--rw description?
+--rw type?
Figure 1: Data hierarchy of the core routing data model. Figure 1: Data hierarchy of the core routing data model.
As can be seen from Figure 1, the core routing data model introduces As can be seen from Figure 1, the core routing data model introduces
several generic components of a routing framework: routers, routing several generic components of a routing framework: routers, routing
tables containing routes, routing protocols, route filters and RPC tables containing routes, routing protocols and route filters. The
operations. The following subsections describe these components in following subsections describe these components in more detail.
more detail.
By combining the components in various ways, and possibly augmenting By combining the components in various ways, and possibly augmenting
them with appropriate contents defined in other modules, various them with appropriate contents defined in other modules, various
routing setups can be realized. routing setups can be realized.
+--------+ +------------+ +--------+
| direct | +---+ | | | direct | +---+ +--------------+ +---+ +--------------+
| routes |--->| F |--->| FIB | | routes |--->| F |--->| |<---| F |<---| |
+--------+ +---+ | | +--------+ +---+ | main | +---+ | additional |
+------------+ | routing | | routing |
^
|
+---+
| F |
+---+
^
|
+--------------+ +---+ +--------------+
+--------+ | |<---| F |<---| |
| static | +---+ | main | +---+ | additional |
| routes |--->| F |--->| routing | | routing |
+--------+ +---+ | table | +---+ | table | +--------+ +---+ | table | +---+ | table |
| |--->| F |--->| | | static |--->| F |--->| |--->| F |--->| |
+--------------+ +---+ +--------------+ | routes | +---+ +--------------+ +---+ +--------------+
^ | ^ | +--------+ ^ | ^ |
| v | v | v | v
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| F | | F | | F | | F | | F | | F | | F | | F |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
^ | ^ | ^ | ^ |
| v | v | v | v
+----------+ +----------+ +----------+ +----------+
| routing | | routing | | routing | | routing |
| protocol | | protocol | | protocol | | protocol |
+----------+ +----------+ +----------+ +----------+
Figure 2: Example setup of the routing subsystem Figure 2: Example setup of the routing subsystem
The example in Figure 2 shows a typical (though certainly not the The example in Figure 2 shows a typical (though certainly not the
only possible) organization of a more complex routing subsystem. only possible) organization of a more complex routing subsystem for a
Several of its features are worth mentioning: single address family. 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 configured. 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-protocols, is connected to exactly one routing "direct" pseudo-protocols, is connected to one routing table with
table with which it can exchange routes (in both directions, which it can exchange routes (in both directions, except for the
except for the "static" and "direct" pseudo-protocols). "static" and "direct" pseudo-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 either direction (or both). routes in either direction (or both).
o The forwarding information base (FIB) is a special routing table
which must always be present. Typically, the FIB contains the
"direct" routes for all configured interfaces and also receives
the active routes from the main routing table. The operating
system 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 Figure 2. of route filters, denoted by "F" in Figure 2.
4.1. Router 4.1. Router
Each router instance in the core routing data model represents a Each router instance in the core routing data model represents a
(logical) router whose configuration and operation is independent of logical router. The exact semantics of this term is left to
other router instances. Although it it not enforced by the data implementations. For example, router instances may be completely
model, different router instances normally do not internally share isolated virtual routers or, alternatively, they may internally share
any data. They may, however, communicate with each other via routing certain information.
protocols.
Logical network interfaces must be assigned to a router instance in Network layer interfaces must be assigned to a router instance in
order to be able to participate in packet forwarding, routing order to be able to participate in packet forwarding, routing
protocols and other operations of that router instance. The protocols and other operations of that router instance. The
assignment is accomplished by creating a corresponding entry in the assignment is accomplished by creating a corresponding entry in the
list of router interfaces ("/router/interfaces/interface"). The key list of router interfaces ("rt:interface"). The key of the list
of the list entry MUST be the name of a configured logical interface. entry MUST be the name of a configured network layer interface, i.e.,
A logical interface MUST NOT be assigned to more than one router the value of a node /if:interfaces/if:interface/if:name defined in
instance. the "ietf-interfaces" module.[YANG-IF].
Apart from the key, each entry of the "/router/interfaces/interface" Implementations MAY specify additional rules for the assignment of
list MAY contain other configuration or operational state data interfaces to logical routers. For example, it may be required that
related to the corresponding logical interface. the sets of interfaces assigned to different logical routers be
disjoint.
Apart from the key, each entry of the "rt:interface" list MAY contain
other configuration or operational state data related to the
corresponding router interface.
4.1.1. Configuration of IPv6 Router Interfaces 4.1.1. Configuration of IPv6 Router Interfaces
The module "ietf-ipv6-unicast-routing" augments the definition of the The module "ietf-ipv6-unicast-routing" augments the definition of the
data node "/router/interfaces/interface" with definitions of the data node "rt:interface" with definitions of the following
following configuration variables as required by [RFC4861], sec. configuration variables as required by [RFC4861], sec. 6.2.1:
6.2.1:
o send-advertisements, o send-advertisements,
o max-rtr-adv-interval, o max-rtr-adv-interval,
o min-rtr-adv-interval, o min-rtr-adv-interval,
o managed-flag, o managed-flag,
o other-config-flag, o other-config-flag,
o link-mtu, o link-mtu,
o reachable-time, o reachable-time,
skipping to change at page 11, line 15 skipping to change at page 11, line 4
o managed-flag, o managed-flag,
o other-config-flag, o other-config-flag,
o link-mtu, o link-mtu,
o reachable-time, o reachable-time,
o retrans-timer, o retrans-timer,
o cur-hop-limit, o cur-hop-limit,
o default-lifetime, o default-lifetime,
o prefix-list: a list of prefixes to be advertised. The following o prefix-list: a list of prefixes to be advertised. The following
parameters are associated with each prefix in the list: parameters are associated with each prefix in the list:
* valid-lifetime, * valid-lifetime,
* on-link-flag, * on-link-flag,
* preferred-lifetime, * preferred-lifetime,
* autonomous-flag. * autonomous-flag.
The definitions and descriptions of the above parameters can be found The definitions and descriptions of the above parameters can be found
in the text of the module "ietf-ipv6-unicast-routing" (Section 8). in the text of the module "ietf-ipv6-unicast-routing" (Section 8).
NOTE: The "IsRouter" flag, which is also required by [RFC4861], was NOTE: The "IsRouter" flag, which is also required by [RFC4861], is
omitted. Is is expected that this variable will be implemented in implemented by the "ietf-ip" module [YANG-IP] (leaf "ip:ip-
another module, either "ietf-interfaces" or "ietf-ip". forwarding").
4.2. Route 4.2. Route
Routes are basic units of information in a routing system. The core Routes are basic units of information in a routing system. The core
routing data model defines only the following minimal set of route routing data model defines only the following minimal set of route
attributes: 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 should suffice 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 both in configuration data, for
example as manually configured static routes, and in operational example as manually configured static routes, and in operational
state data, for example as entries in routing tables. state data, for example as entries in routing tables.
4.3. 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 "age": number of seconds since the route was created or last
installation, of the route. updated.
Each routing table may only contain routes of the same address family Each routing table may only contain routes of the same address
(AFN and SAFI). family. Address family information consists of two parameters -
"address-family" and "safi" (Subsequent Address Family Identifier,
SAFI). The permitted values for these two parameters are defined by
IANA and translated into YANG enumeration types "ianaaf:address-
family" and "ianaaf:subsequent-address-family" [IANA-IF-AF].
In the core routing data model, the "routing-table" node represents In the core routing data model, the "routing-table" node represents
configuration while the descendant list of routes is defined as configuration while the descendant list of routes is defined as
operational state data. The contents of such lists are controlled by operational state data. The contents of route lists are controlled
routing protocol operations which may result in route additions, and manipulated by routing protocol operations which may result in
removals and modifications. This also includes manipulations via the route additions, removals and modifications. This also includes
"static" pseudo-protocol. manipulations via the "static" and/or "direct" pseudo-protocols, see
Section 4.4.1.
At least the following two routing tables MUST be configured for each One routing table MUST be present for each router instance and each
router instance and each supported AFN/SAFI pair: address family supported by that router instance. It is the so-
called main routing table to which all routing protocol instances
supporting the given address family SHOULD be connected by default.
For the two address families that are part of the core routing data
model, the names of the main routing tables SHOULD be as follows:
1. Forwarding information base (FIB) contains active routes that are o "main-ipv4-unicast" for IPv4 unicast,
used by the operating system kernel for forwarding datagrams.
2. Main routing table to which all routing protocol instances are o "main-ipv6-unicast" for IPv6 unicast.
connected by default, with the exception of the "direct" pseudo-
protocol (Section 4.4): direct routes only appear in the FIB
table by default.
The main routing table SHOULD serve as the default source of active Additional routing tables MAY be configured by creating new entries
routes for the FIB. in the "routing-table" list, either as a part of factory-default
configuration, or by a client's action.
One or more additional routing tables MAY be configured by creating The naming scheme for additional routing tables, as well as
new entries in the "routing-table" list, either being a part of restrictions on the number and configurability of routing tables are
factory-default configuration or configured by the client. implementation-specific.
The naming scheme for routing tables, as well as restrictions on the The way how the routing system uses information from routing tables
number and configurability of routing tables are implementation- is outside the scope of this document. Typically, implementations
specific. will either use a forwarding table, or perform a direct look-up in
the main routing table in conjunction with a route cache.
Every routing table can serve as a source of routes for other routing 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 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.4. Routing Protocols 4.4. Routing Protocols
The core routing data model provides an open-ended framework for The core routing data model provides an open-ended framework for
defining multiple routing protocol instances. Each of them is defining multiple routing protocol instances. Each of them is
identified by a name, which MUST be unique within a router instance. identified by a name, which MUST be unique within a router instance.
Each protocol MUST be assigned a type, which MUST be an identity Each protocol MUST be assigned a type, which MUST be an identity
derived from the "rt:routing-protocol" base identity. The core derived from the "rt:routing-protocol" base identity. The core
routing data model defines two identities for the "direct" and routing data model defines two identities for the direct and static
"static" pseudo-protocols. pseudo-protocols (Section 4.4.1).
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 SHOULD be table for each address family that the routing protocol instance
connected to the main routing table. An implementation MAY allow any supports. By default, every routing protocol instance SHOULD be
or all routing protocol instances to be configured to use a different connected to the main routing table or tables. An implementation MAY
routing table. allow any or all routing protocol instances to be configured to use a
different routing table.
Routes learned from the network by a routing protocol are passed to Routes learned from the network by a routing protocol are passed to
the connected routing table and vice versa - routes appearing in a the connected routing table(s) and vice versa - routes appearing in a
routing table are passed to all routing protocols connected to the routing table are passed to all routing protocols connected to the
table (except "direct" and "static" pseudo-protocols) and advertised table (except "direct" and "static" pseudo-protocols) and may be
by that protocol to the network. advertised by that protocol to the network.
Two independent route filters (see Section 4.5) 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 core routing data model defines two special routing protocols - 4.4.1. Routing Pseudo-Protocols
"direct" and "static". Both are in fact pseudo-protocols, which
means that they are confined to the local device and do not exchange The core routing data model defines two special routing protocol
any routing information with neighboring routers. Routes from both types - "direct" and "static". Both are in fact pseudo-protocols,
"direct" and "static" protocol instances are passed to the connected which means that they are confined to the local device and do not
routing table (subject to route filters, if any), but an exchange in exchange any routing information with neighboring routers. Routes
the opposite direction is not allowed. from both "direct" and "static" protocol instances are passed to the
connected routing table (subject to route filters, if any), but an
exchange in the opposite direction is not allowed.
Every router instance 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 direct routes which "direct" pseudo-protocol type. The name of this instance MUST also
are normally supplied by the operating system kernel, based on the be "direct". It is the source of direct routes for all configured
detected and configured network interfaces, and they SHOULD by address families. Direct routes are normally supplied by the
default appear in the FIB routing table. However, using the operating system kernel, based on the configuration of network
framework defined in this document, the target routing table for interface addresses, see Section 5.2. Direct routes SHOULD by
direct routes MAY be changed by connecting the "direct" protocol default appear in the main routing table for each configured address
instance to a non-default routing table. Direct routes can also be family. However, using the framework defined in this document, the
filtered before they appear in the routing table. target routing table for direct routes MAY be changed by connecting
the "direct" protocol instance to a non-default routing table.
Direct routes can also be filtered before they appear in the routing
table.
The "static" routing pseudo-protocol allows for specifying routes A pseudo-protocol of the type "static" allows for specifying routes
manually. It MAY be configured in zero or multiple instances, manually. It MAY be configured in zero or multiple instances,
although a typical implementation will have exactly one instance per although a typical implementation will have exactly one instance per
router. logical router.
4.4.1. Defining New Routing Protocols 4.4.2. 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. Such a new module has to define
has to define the protocol-specific information and fit it into the the protocol-specific configuration and operational state data, and
core routing framework in the following way : fit it into the 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 MUST be set to "rt:routing-protocol", or to an base identity MUST be set to "rt:routing-protocol", or to an
identity 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, preferably in one
then have to be inserted as operational state data by augmenting place by means of defining a YANG grouping. The new attributes
the definition of "rt:route" inside "rt:routing-table", and have to be inserted as operational state data by augmenting the
possibly to other places in the configuration, operational state definition of "rt:route" inside "rt:routing-table", and possibly
data and RPC input or output. to other places in the configuration, operational state data and
RPC input or output.
o Per-interface configuration parameters can be added by augmenting o Per-interface configuration parameters can be added by augmenting
the data node "rt:interface" (the list of router interfaces). the data node "rt:interface" (the list of router interfaces).
o Other configuration parameters can be defined by augmenting the o Other configuration parameters and operational state data can be
"routing-protocol" data node. By using the "when" statement, this defined by augmenting the "routing-protocol" data node. By using
augment SHOULD be made conditional and valid only if the value of the "when" statement, this augment SHOULD be made conditional and
the "rt:type" child leaf equals to the new protocol's identity. valid only if the value of the "rt:type" child leaf equals to the
new protocol's identity.
It is recommended that both per-interface and other configuration It is RECOMMENDED that both per-interface and other configuration
data specific to the new protocol be encapsulated in an appropriately data specific to the new protocol be encapsulated in an appropriately
named container. named container.
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.";
} }
New route attributes specific to the RIP protocol ("metric" and New route attributes specific to the RIP protocol ("metric" and
"tag") are defined in a grouping and then added to the route "tag") are defined in a grouping and then added to the route
definitions appearing in "routing-table" and in the output part of definitions appearing in "routing-table" and in the output part of
the "get-route" RPC method: the "active-route" RPC method:
grouping route-content { grouping route-content {
description description
"RIP-specific route content."; "RIP-specific route content.";
leaf metric { leaf metric {
type rip-metric; type rip-metric;
} }
leaf tag { leaf tag {
type uint16; type uint16;
default "0"; default "0";
skipping to change at page 16, line 34 skipping to change at page 16, line 34
+ "rt:type='rip:rip'" { + "rt:type='rip:rip'" {
description description
"This augment is only valid if the source protocol from which "This augment is only valid if the source protocol from which
the route originated is RIP."; the route originated is RIP.";
} }
description description
"RIP-specific route components."; "RIP-specific route components.";
uses route-content; uses route-content;
} }
augment "/rt:get-route/rt:output/rt:route" { augment "/rt:active-route/rt:output/rt:route" {
description description
"Add RIP-specific route content."; "Add RIP-specific route content.";
uses route-content; uses route-content;
} }
Per-interface configuration data are defined by the following Per-interface configuration data are defined by the following
"augment" statement: "augment" statement:
augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {
when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " when "../../rt:routing-protocols/rt:routing-protocol/rt:type = "
skipping to change at page 17, line 50 skipping to change at page 17, line 50
} }
} }
4.5. Route Filters 4.5. Route Filters
The core routing data model provides a skeleton for defining route The core routing data model provides a skeleton for defining route
filters that can be used to restrict the set of routes being filters that can be used to restrict the set of routes being
exchanged between a routing protocol instance and a connected routing exchanged between a routing protocol instance and a connected routing
table, or between a source and a recipient routing table. Route table, or between a source and a recipient routing table. Route
filters may also manipulate routes, i.e., add, delete, or modify filters may also manipulate routes, i.e., add, delete, or modify
their properties. their attributes.
Route filters are global, which means that a configured route filter
may be used by any or all router instances.
By itself, the route filtering framework defined in this document By itself, the route filtering framework defined in this document
allows to establish only the two extreme routing policies in which allows for applying only the extreme routing policies which are
either all routes are allowed or all routes are rejected. It is represented by the following pre-defined route filter types:
expected that real route filtering frameworks will be developed
o "deny-all-route-filter": all routes are blocked,
o "allow-all-route-filter": all routes are permitted.
It is expected that real route filtering frameworks will be developed
separately. separately.
Each route filter is identified by a name which MUST be unique within 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 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 the route filter
is the identity "deny-all-route-filter" defined in the "ietf-routing" type is the identity "deny-all-route-filter".
module, which represents a route filtering policy in which all routes
are rejected.
4.6. RPC Operation 4.6. RPC Operations
The "ietf-routing" module defines the "get-route" RPC operation. It The "ietf-routing" module defines two RPC operations:
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" and
"ietf-ipv6-unicast-routing" modules.
The server replies with an active route which is used for forwarding o active-route,
datagrams to the destination address within the selected router
instance. Again, modules for particular address families are
expected to augment the definition of output parameters with AFN/
SAFI-specific contents.
5. IANA AFN and SAFI YANG Module o route-count.
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the Their parameters and semantics are described in the following
actual RFC number and all occurrences of the revision date below with subsections.
the date of RFC publication (and remove this note).
<CODE BEGINS> file "iana-afn-safi@2012-02-20.yang" 4.6.1. Operation "active-route"
module iana-afn-safi { Description: Retrieve one or more active routes from the forwarding
information base (FIB) of a router instance, i.e., the route(s)
that are currently used by that router instance for sending
datagrams to the destination whose address is provided as an input
parameter.
namespace "urn:ietf:params:xml:ns:yang:iana-afn-safi"; Parameters:
prefix "ianaaf"; router-name: Name of the router instance whose FIB is to be
queried.
organization destination-address: Network layer destination address for which
"IANA"; the active routes are requested.
contact Positive Response: One or more "route" elements containing the
"Internet Assigned Numbers Authority active route(s).
Postal: Negative Response:
ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
U. S. A.
Tel: +1 310 823 9358 If the logical router is not found, the server sends an "rpc-
E-Mail: iana&iana.org error" message with "error-tag" set to "missing-element", and
"; "error-app-tag" set to "router-not-found".
description If no route exists for the given destination address, the server
"This YANG module provides two typedefs containing YANG sends an "rpc-error" message with "error-tag" set to "data-
definitions for the following IANA-registered enumerations: missing" and "error-app-tag" set to "no-route".
- Address Family Numbers (AFN) 4.6.2. Operation "route-count"
- Subsequent Address Family Identifiers (SAFI) Description: Retrieve the total number of routes in a routing table.
The latest revision of this YANG module can be obtained from the Parameters:
IANA web site.
Copyright (c) 2012 IETF Trust and the persons identified as router-name: Name of the logical router containing the routing
authors of the code. All rights reserved. table.
Redistribution and use in source and binary forms, with or routing-table: Name of the routing table.
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 Positive Response: Element "number-of-routes" containing the
RFC itself for full legal notices. requested nonnegative number.
";
revision 2012-02-20 { Negative Response: If the logical router or the routing table is not
description found, the server sends an "rpc-error" message with "error-tag"
"Initial revision."; set to "missing-element", and "error-app-tag" set to "router-not-
reference found" or "routing-table-not-found", respectively.
"RFC XXXX: A YANG Data Model for Routing Configuration";
}
typedef address-family { 5. Interactions with Other YANG Modules
type enumeration {
enum other {
value "0";
description
"none of the following";
}
enum ipV4 {
value "1";
description
"IP Version 4";
}
enum ipV6 {
value "2";
description
"IP Version 6";
}
enum nsap {
value "3";
description
"NSAP";
}
enum hdlc {
value "4";
description
"(8-bit multidrop)";
}
enum bbn1822 {
value "5";
description
"BBN Report 1822";
}
enum all802 {
value "6";
description
"(includes all 802 media plus Ethernet 'canonical
format')";
}
enum e163 {
value "7";
description
"E.163";
}
enum e164 {
value "8";
description
"(SMDS, FrameRelay, ATM)";
}
enum f69 {
value "9";
description
"(Telex)";
}
enum x121 {
value "10";
description
"(X.25, Frame Relay)";
}
enum ipx {
value "11";
description
"IPX (Internet Protocol Exchange)";
}
enum appleTalk {
value "12";
description
"Apple Talk";
}
enum decnetIV {
value "13";
description
"DEC Net Phase IV";
}
enum banyanVines {
value "14";
description
"Banyan Vines";
}
enum e164withNsap {
value "15";
description
"(E.164 with NSAP format subaddress)";
}
enum dns {
value "16";
description
"(Domain Name System)";
}
enum distinguishedName {
value "17";
description
"(Distinguished Name, per X.500)";
}
enum asNumber {
value "18";
description
"(16-bit quantity, per the AS number space)";
}
enum xtpOverIPv4 {
value "19";
description
"XTP over IP version 4";
}
enum xtpOverIpv6 {
value "20";
description
"XTP over IP version 6";
}
enum xtpNativeModeXTP {
value "21";
description
"XTP native mode XTP";
}
enum fibreChannelWWPN {
value "22";
description
"Fibre Channel World-Wide Port Name";
}
enum fibreChannelWWNN {
value "23";
description
"Fibre Channel World-Wide Node Name";
}
enum gwid {
value "24";
description
"Gateway Identifier";
}
enum afi {
value "25";
description
"AFI for L2VPN";
}
}
description
"This typedef is a YANG enumeration of IANA-registered address
family numbers (AFN).";
reference
"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 The semantics of the core routing data model also depends on several
<http://www.iana.org/assignments/ianaaddressfamilynumbers-mib> configuration parameters that are defined in other YANG modules. The
"; following subsections describe these interactions.
}
typedef subsequent-address-family { 5.1. Module "ietf-interfaces"
type enumeration {
enum nlri-unicast {
value "1";
description
"Network Layer Reachability Information used for unicast
forwarding";
reference
"RFC4760";
}
enum nlri-multicast {
value "2";
description
"Network Layer Reachability Information used for multicast
forwarding";
reference
"RFC4760";
}
enum nlri-mpls {
value "4";
description
"Network Layer Reachability Information (NLRI) with MPLS
Labels";
reference
"RFC3107";
}
enum mcast-vpn {
value "5";
description
"MCAST-VPN";
reference The following boolean switch is defined in the "ietf-interfaces" YANG
"draft-ietf-l3vpn-2547bis-mcast-bgp-08"; module [YANG-IF]:
}
enum nlri-dynamic-ms-pw {
value "6";
status "obsolete";
description
"Network Layer Reachability Information used for Dynamic
Placement of Multi-Segment Pseudowires (TEMPORARY -
Expires 2008-08-23)";
reference
"draft-ietf-pwe3-dynamic-ms-pw-13";
}
enum tunnel-safi {
value "64";
description
"Tunnel SAFI";
reference
"draft-nalawade-kapoor-tunnel-safi-05";
}
enum vpls {
value "65";
description
"Virtual Private LAN Service (VPLS)";
reference
"RFC4761, RFC6074";
}
enum bgp-mdt {
value "66";
description
"BGP MDT SAFI";
reference
"RFC6037";
}
enum bgp-4over6 {
value "67";
description
"BGP 4over6 SAFI";
reference
"RFC5747";
}
enum bgp-6over4 {
value "68";
description
"BGP 6over4 SAFI";
reference
"mailto:cuiyong&tsinghua.edu.cn";
}
enum l1vpn-auto-discovery {
value "69";
description
"Layer-1 VPN auto-discovery information";
reference
"draft-ietf-l1vpn-bgp-auto-discovery-05";
}
enum mpls-vpn {
value "128";
description
"MPLS-labeled VPN address";
reference
"RFC4364";
}
enum multicast-bgp-mpls-vpn {
value "129";
description
"Multicast for BGP/MPLS IP Virtual Private Networks
(VPNs)";
reference
"draft-ietf-l3vpn-2547bis-mcast-10,
draft-ietf-l3vpn-2547bis-mcast-10";
}
enum route-target-constraints {
value "132";
description
"Route Target constraints";
reference
"RFC4684";
}
enum ipv4-diss-flow {
value "133";
description
"IPv4 dissemination of flow specification rules";
reference
"RFC5575";
}
enum vpnv4-diss-flow {
value "134";
description
"IPv4 dissemination of flow specification rules";
reference
"RFC5575";
}
enum vpn-auto-discovery {
value "140";
description
"VPN auto-discovery";
reference /if:interfaces/if:interface/if:enabled
"draft-ietf-l3vpn-bgpvpn-auto-09";
}
}
description
"This typedef is a YANG enumeration of IANA-registered
subsequent address family identifiers (SAFI).";
reference
"Subsequent Address Family Identifiers (SAFI) Parameters. IANA,
2011-03-04. <http://www.iana.org/assignments/safi-namespace/
safi-namespace.xml>
";
}
}
<CODE ENDS> If this switch is set to "false" for a given network layer
interface, the device MUST behave exactly as if that interface was
not assigned to any logical router at all.
5.2. Module "ietf-ip"
The following boolean switches are defined in the "ietf-ip" YANG
module [YANG-IP]:
/if:interfaces/if:interface/ip:ipv4/ip:enabled
If this switch is set to "false" for a given interface, then all
IPv4 routing functions related to that interface MUST be disabled.
/if:interfaces/if:interface/ip:ipv4/ip:ip-forwarding
If this switch is set to "false" for a given interface, then the
forwarding of IPv4 datagrams to and from this interface MUST be
disabled. However, the interface may participate in other routing
functions, such as routing protocols.
/if:interfaces/if:interface/ip:ipv6/ip:enabled
If this switch is set to "false" for a given interface, then all
IPv6 routing functions related to that interface MUST be disabled.
/if:interfaces/if:interface/ip:ipv6/ip:ip-forwarding
If this switch is set to "false" for a given interface, then the
forwarding of IPv6 datagrams to and from this interface MUST be
disabled. However, the interface may participate in other routing
functions, such as routing protocols.
In addition, the "ietf-ip" module allows for configuring IPv4 and
IPv6 addresses and subnet masks. Configuration of these parameters
on an enabled interface MUST result in an immediate creation of the
corresponding direct route (usually in the main routing table). Its
destination prefix is set according to the configured IP address and
subnet mask, and the interface is set as the outgoing interface for
that route.
6. Routing YANG Module 6. Routing YANG Module
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number and all occurrences of the revision date below with actual RFC number and all occurrences of the revision date below with
the date of RFC publication (and remove this note). the date of RFC publication (and remove this note).
<CODE BEGINS> file "ietf-routing@2012-02-20.yang" <CODE BEGINS> file "ietf-routing@2012-05-24.yang"
module ietf-routing { module ietf-routing {
namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; namespace "urn:ietf:params:xml:ns:yang:ietf-routing";
prefix "rt"; prefix "rt";
import ietf-yang-types { import ietf-inet-types {
prefix "yang"; prefix "inet";
} }
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix "if";
} }
import iana-afn-safi { import iana-afn-safi {
prefix "ianaaf"; prefix "ianaaf";
} }
skipping to change at page 27, line 49 skipping to change at page 22, line 49
<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@nic.cz> <mailto:lhotka@nic.cz>
"; ";
description description
"This module contains YANG definitions of essential components "This YANG module defines essential components that may be used
that may be used for configuring a routing subsystem. for configuring a routing subsystem.
Copyright (c) 2012 IETF Trust and the persons identified as Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices.
"; ";
revision 2012-02-20 { revision 2012-05-24 {
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";
} }
/* Identities */ /* Identities */
identity routing-protocol { identity routing-protocol {
description description
skipping to change at page 29, line 8 skipping to change at page 24, line 8
description description
"Base identity from which all route filters are derived."; "Base identity from which all route filters are derived.";
} }
identity deny-all-route-filter { identity deny-all-route-filter {
base route-filter; base route-filter;
description description
"Route filter that blocks all routes."; "Route filter that blocks all routes.";
} }
identity allow-all-route-filter {
base route-filter;
description
"Route filter that permits all routes.
Note that use of this filter is equivalent to no filter at
all.
";
}
/* Type Definitions */ /* Type Definitions */
typedef router-ref { typedef router-ref {
type leafref { type leafref {
path "/rt:routing/rt:router/rt:name"; path "/rt:routing/rt:router/rt:name";
} }
description description
"This type is used for leafs that reference a router "This type is used for leafs that reference a router
instance."; instance.";
} }
/* Groupings */ /* Groupings */
grouping afn-safi { grouping afn-safi {
leaf address-family { leaf address-family {
type ianaaf:address-family; type ianaaf:address-family;
default "ipV4"; default "ipv4";
description description
"Address family of routes in the routing table."; "Address family of routes in the routing table.";
} }
leaf safi { leaf safi {
type ianaaf:subsequent-address-family; type ianaaf:subsequent-address-family;
default "nlri-unicast"; default "nlri-unicast";
description description
"Subsequent address family identifier of routes in the "Subsequent address family identifier of routes in the
routing table."; routing table.";
} }
skipping to change at page 30, line 4 skipping to change at page 25, line 14
"Generic parameters of routes. "Generic parameters of routes.
A module for an address family should define a specific A module for an address family should define a specific
version of this grouping containing 'uses rt:route-content'. version of this grouping containing 'uses rt:route-content'.
"; ";
leaf outgoing-interface { leaf outgoing-interface {
type if:interface-ref; type if:interface-ref;
description description
"Outgoing interface."; "Outgoing interface.";
} }
} }
/* RPC Methods */ /* RPC Methods */
rpc get-route { rpc active-route {
description description
"Query the forwarding information base of a router instance "Return the active route (or multiple routes, in the case of
whose name is given as the first parameter 'router-name'. The multi-path routing) to a destination address.
second parameter 'destination-address' should be augmented in
order to support destination addresses of all supported Parameters
address families. The server returns the route which is
currently used for forwarding datagrams to that destination 1. 'router-name',
address, or an error message, if no such route exists.";
2. 'destination-address'.
If the logical router with 'router-name' doesn't exist, then
this operation will fail with error-tag 'missing-element' and
error-app-tag 'router-not-found'.
If there is no active route for 'destination-address', then
this operation will fail with error-tag 'data-missing' and
error-app-tag 'no-route'.
";
input { input {
leaf router-name { leaf router-name {
type router-ref; type router-ref;
mandatory "true"; mandatory "true";
description description
"First parameter: name of the router instance whose "Name of the router instance whose forwarding information
forwarding information base is queried."; base is being queried.";
} }
container destination-address { container destination-address {
uses afn-safi; uses afn-safi;
description description
"Second parameter: destination address. "Network layer destination address.
AFN/SAFI-specific modules must augment this container with AFN/SAFI-specific modules must augment this container with
a leaf named 'address'. a leaf named 'address'.
"; ";
} }
} }
output { output {
container route { list route {
min-elements "1";
uses afn-safi; uses afn-safi;
uses route-content;
description description
"Contents of the reply specific for each address family "Route contents specific for each address family should be
should be defined through augmenting."; defined through augmenting.";
}
}
}
rpc route-count {
description
"Return the current number of routes in a routing table.
Parameters:
1. 'router-name',
2. 'routing-table-name'.
If the logical router with 'router-name' doesn't exist, then
this operation will fail with error-tag 'missing-element' and
error-app-tag 'router-not-found'.
If the routing table with 'routing-table-name' doesn't exist,
then this operation will fail with error-tag 'missing-element'
and error-app-tag 'routing-table-not-found'.
";
input {
leaf router-name {
type router-ref;
mandatory "true";
description
"Name of the router instance containing the routing
table.";
}
leaf routing-table {
type leafref {
path "/routing/router/routing-tables/routing-table/name";
}
mandatory "true";
description
"Name of the routing table.";
}
}
output {
leaf number-of-routes {
type uint32;
mandatory "true";
description
"Number of routes in the routing table.";
} }
} }
} }
/* Data Nodes */ /* Data Nodes */
container routing { container routing {
description description
"Routing parameters."; "Routing parameters.";
list router { list router {
key "name"; key "name";
unique "interfaces/interface/name"; unique "router-id";
description description
"Each list entry is a container for configuration and 'Each list entry is a container for configuration and
operational state data of a single (logical) router."; operational state data of a single (logical) router.
Network layer interfaces assigned to the router must have
their entries in the "interfaces" list.
';
leaf name { leaf name {
type string; type string;
description description
"The unique router name."; "The unique router name.";
} }
leaf router-id {
type inet:ipv4-address;
description
"Global router ID in the form of an IPv4 address.
An implementation may select a value if this parameter is
not configured.
Routing protocols may override this global parameter
inside their configuration.
";
}
leaf description { leaf description {
type string; type string;
description description
"Textual description of the router."; "Textual description of the router.";
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
default "true"; default "true";
description description
"Enable or disable the router. The default value is 'true', "Enable the router. The default value is 'true'.
which means that the router is enabled.";
If this parameter is false, the parent router instance is
disabled, despite any other configuration that might be
present.
";
} }
container interfaces { container interfaces {
description description
"Router interface parameters."; "Router interface parameters.";
list interface { list interface {
key "name"; key "name";
description description
"List of logical interfaces assigned to the router "List of network layer interfaces assigned to the router
instance. Any logical interface can only be assigned to instance.";
one router instance.";
leaf name { leaf name {
type if:interface-ref; type if:interface-ref;
description description
"A reference to the name of a configured logical "A reference to the name of a configured network layer
interface."; interface.";
} }
} }
} }
container routing-protocols { 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 { list routing-protocol {
key "name"; key "name";
skipping to change at page 32, line 27 skipping to change at page 29, line 17
mandatory "true"; mandatory "true";
description description
"Type of the routing protocol - an identity derived "Type of the routing protocol - an identity derived
from the 'routing-protocol' base identity."; from the 'routing-protocol' base identity.";
} }
container connected-routing-tables { container connected-routing-tables {
description description
"Container for connected routing tables."; "Container for connected routing tables.";
list routing-table { list routing-table {
must "not(../../../../routing-tables/" must "not(../../../../routing-tables/"
+ "routing-table[current()/" + "routing-table[rt:name=current()/"
+ "preceding-sibling::routing-table/name]/" + "preceding-sibling::routing-table/name]/"
+ "address-family=../../../../routing-tables/" + "address-family=../../../../routing-tables/"
+ "routing-table[current()/name]/" + "routing-table[rt:name=current()/name]/"
+ "address-family and ../../../../routing-tables/" + "address-family and ../../../../routing-tables/"
+ "routing-table[current()/" + "routing-table[rt:name=current()/"
+ "preceding-sibling::routing-table/name]/safi=../" + "preceding-sibling::routing-table/name]/safi=../"
+ "../../../routing-tables/routing-table[current()/" + "../../../routing-tables/"
+ "name]/safi)" { + "routing-table[rt:name=current()/name]/safi)" {
error-message error-message "Each routing protocol may have no "
"Each routing protocol may have no more than one + "more than one connected routing "
connected routing table for each AFN and SAFI."; + "table for each AFN and SAFI.";
description description
"For each AFN/SAFI pair there may be at most one "For each AFN/SAFI pair there may be at most one
connected routing table."; connected routing table.";
} }
key "name"; key "name";
description description
"List of routing tables to which the routing protocol "List of routing tables to which the routing protocol
instance is connected. instance is connected.
Implementation may provide default routing tables If no connected routing table is defined for an
for some AFN/SAFI pairs, which are used if the address family, the routing protocol should be
corresponding entry is not configured. connected by default to the main routing table for
that address family.
"; ";
leaf name { leaf name {
type leafref { type leafref {
path "../../../../../routing-tables/routing-table/" path "../../../../../routing-tables/routing-table/"
+ "name"; + "name";
} }
description description
"Reference to an existing routing table."; "Reference to an existing routing table.";
} }
leaf import-filter { leaf import-filter {
type leafref { type leafref {
path "../../../../../route-filters/route-filter/" path "/routing/route-filters/route-filter/name";
+ "name";
} }
description description
"Reference to a route filter that is used for "Reference to a route filter that is used for
filtering routes passed from this routing protocol filtering routes passed from this routing protocol
instance to the routing table specified by the instance to the routing table specified by the
'name' sibling node. If this leaf is not present, 'name' sibling node. If this leaf is not present,
the behavior is protocol-specific, but typically the behavior is protocol-specific, but typically
it means that all routes are accepted."; it means that all routes are accepted.";
} }
leaf export-filter { leaf export-filter {
type leafref { type leafref {
path "../../../../../route-filters/route-filter/" path "/routing/route-filters/route-filter/name";
+ "name";
} }
description description
"Reference to a route filter that is used for "Reference to a route filter that is used for
filtering routes passed from the routing table filtering routes passed from the routing table
specified by the 'name' sibling node to this specified by the 'name' sibling node to this
routing protocol instance. If this leaf is not routing protocol instance. If this leaf is not
present, the behavior is protocol-specific - present, the behavior is protocol-specific -
typically it means that all routes are accepted, typically it means that all routes are accepted,
except for the 'direct' and 'static' except for the 'direct' and 'static'
pseudo-protocols which accept no routes from any pseudo-protocols which accept no routes from any
routing table."; routing table.";
} }
} }
} }
container static-routes { container static-routes {
must "../type='static'" { must "../type='rt:static'" {
error-message error-message "Static routes may be configured only "
"Static routes may be configured only for 'static' + "for 'static' routing protocol.";
routing protocol.";
description description
"This container is only valid for the 'static' "This container is only valid for the 'static'
routing protocol."; routing protocol.";
} }
description description
"Configuration of 'static' pseudo-protocol."; "Configuration of 'static' pseudo-protocol.";
} }
} }
} }
container route-filters {
description
"Container for configured route filters.";
list route-filter {
key "name";
description
"Route filters are used for filtering and/or manipulating
routes that are passed between a routing protocol and a
routing table or vice versa, or between two routing
tables. It is expected that other modules augment this
list with contents specific for a particular route
filter type.";
leaf name {
type string;
description
"The name of the route filter.";
}
leaf description {
type string;
description
"Textual description of the route filter.";
}
leaf type {
type identityref {
base route-filter;
}
default "deny-all-route-filter";
description
"Type of the route-filter - an identity derived from
the 'route-filter' base identity. The default value
represents an all-blocking filter.";
}
}
}
container routing-tables { container routing-tables {
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 routing table identified by the "Each entry represents a routing table identified by the
'name' key. All routes in a routing table must have the 'name' key. All routes in a routing table must have the
same AFN and SAFI."; same AFN and SAFI.";
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; 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.";
skipping to change at page 35, line 26 skipping to change at page 31, line 27
container routes { container routes {
config "false"; config "false";
description description
"Current contents of the routing table (operational "Current contents of the routing table (operational
state data)."; state data).";
list route { list route {
description description
"A routing table entry. This data node must augmented "A routing table entry. This data node must augmented
with information specific for routes of each address with information specific for routes of each address
family."; family.";
uses route-content;
leaf source-protocol { leaf source-protocol {
type leafref { type leafref {
path "../../../../../routing-protocols/" path "/routing/router/routing-protocols/"
+ "routing-protocol/name"; + "routing-protocol/name";
} }
mandatory "true";
description description
"The name of the routing protocol instance from "The name of the routing protocol instance from
which the route comes. This routing protocol must which the route comes. This routing protocol must
be configured (automatically or manually) in the be configured (automatically or manually) in the
device."; device.";
} }
leaf last-modified { leaf age {
type yang:date-and-time; type uint32;
units "seconds";
mandatory "true";
description description
"Time stamp of the last modification of the route. "The number of seconds since the parent route was
If the route was never modified, it is the time created or last updated.";
when the route was inserted to the routing
table.";
} }
} }
} }
list recipient-routing-tables { container recipient-routing-tables {
key "recipient-name";
description description
"A list of routing tables that receive routes from this "Container for recipient routing tables.";
routing table."; list recipient-routing-table {
leaf recipient-name { key "name";
type leafref {
path "../../../routing-table/name";
}
description description
"The name of the recipient routing table."; "A list of routing tables that receive routes from
} this routing table.";
leaf filter { leaf name {
type leafref { type leafref {
path "../../../../route-filters/route-filter/name"; path "/routing/router/routing-tables/"
+ "routing-table/name";
}
description
"The name of the recipient routing table.";
}
leaf filter {
type leafref {
path "/routing/route-filters/route-filter/name";
}
description
"A route filter which is applied to the routes
passed on to the recipient routing table.";
} }
description
"A route filter which is applied to the routes passed
on to the recipient routing table.";
} }
} }
} }
} }
} }
container route-filters {
description
"Container for configured route filters.";
list route-filter {
key "name";
description
"Route filters are used for filtering and/or manipulating
routes that are passed between a routing protocol and a
routing table or vice versa, or between two routing
tables. It is expected that other modules augment this
list with contents specific for a particular route filter
type.";
leaf name {
type string;
description
"The name of the route filter.";
}
leaf description {
type string;
description
"Textual description of the route filter.";
}
leaf type {
type identityref {
base route-filter;
}
default "rt:deny-all-route-filter";
description
"Type of the route-filter - an identity derived from the
'route-filter' base identity. The default value
represents an all-blocking filter.";
}
}
}
} }
} }
<CODE ENDS> <CODE ENDS>
7. IPv4 Unicast Routing YANG Module 7. IPv4 Unicast Routing YANG Module
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number and all occurrences of the revision date below with actual RFC number and all occurrences of the revision date below with
the date of RFC publication (and remove this note). the date of RFC publication (and remove this note).
<CODE BEGINS> file "ietf-ipv4-unicast-routing@2012-02-20.yang" <CODE BEGINS> file "ietf-ipv4-unicast-routing@2012-05-25.yang"
module ietf-ipv4-unicast-routing { module 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";
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
} }
skipping to change at page 37, line 45 skipping to change at page 34, line 45
<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@nic.cz> <mailto:lhotka@nic.cz>
"; ";
description description
"This module augments the 'ietf-routing' module with YANG "This YANG module augments the 'ietf-routing' module with basic
definitions for basic configuration of IPv4 unicast routing. configuration and operational state data for IPv4 unicast
routing.
Every implementation must preconfigure a routing table with the
name 'main-ipv4-unicast', which is the main routing table for
IPv4 unicast.
Copyright (c) 2012 IETF Trust and the persons identified as Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices.
"; ";
revision 2012-02-20 { revision 2012-05-24 {
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 */ /* Groupings */
grouping route-content { grouping route-content {
description description
"Parameters of IPv4 unicast routes."; "Parameters of IPv4 unicast routes.";
uses rt:route-content;
leaf dest-prefix { leaf dest-prefix {
type inet:ipv4-prefix; type inet:ipv4-prefix;
description description
"IPv4 destination prefix."; "IPv4 destination prefix.";
} }
leaf next-hop { leaf next-hop {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
/* RPC Methods */ /* RPC Methods */
augment "/rt:get-route/rt:input/rt:destination-address" { augment "/rt:active-route/rt:input/rt:destination-address" {
when "address-family='ipV4' and safi='nlri-unicast'" { when "address-family='ipv4' and safi='nlri-unicast'" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
description description
"The 'address' leaf augments the 'rt:destination-address' "The 'address' leaf augments the 'rt:destination-address'
parameter of the 'rt:get-route' operation."; parameter of the 'rt:active-route' operation.";
leaf address { leaf address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 destination address."; "IPv4 destination address.";
} }
} }
augment "/rt:get-route/rt:output/rt:route" { augment "/rt:active-route/rt:output/rt:route" {
when "address-family='ipV4' and safi='nlri-unicast'" { when "address-family='ipv4' and safi='nlri-unicast'" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
description description
"Contents of the reply to 'rt:get-route' operation."; "Contents of the reply to 'rt:active-route' operation.";
uses route-content; uses route-content;
} }
/* Data nodes */ /* Data nodes */
augment "/rt:routing/rt:router/rt:routing-protocols/" augment "/rt:routing/rt:router/rt:routing-protocols/"
+ "rt:routing-protocol/rt:static-routes" { + "rt:routing-protocol/rt:static-routes" {
description description
"This augment defines the configuration of the 'static' "This augment defines the configuration of the 'static'
pseudo-protocol with data specific for IPv4 unicast."; pseudo-protocol with data specific for IPv4 unicast.";
container ipv4 { container ipv4 {
description description
"Configuration of a 'static' pseudo-protocol instance "Configuration of a 'static' pseudo-protocol instance
consists of a list of routes."; consists of a list of routes.";
list route { list route {
key "seqno"; key "seqno";
ordered-by "user"; ordered-by "user";
description description
"A user-ordered list of static routes."; "A user-ordered list of static routes.";
leaf seqno { leaf seqno {
type uint16; type uint32 {
range "1..max";
}
description description
"Sequential number of the route."; "Sequential number of the route.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route."; "Textual description of the route.";
} }
uses route-content; uses rt:route-content;
uses route-content {
refine "dest-prefix" {
mandatory "true";
}
}
} }
} }
} }
augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
+ "rt:routes/rt:route" { + "rt:routes/rt:route" {
when "../../rt:address-family='ipV4' and " when "../../rt:address-family='ipv4' and "
+ "../../rt:safi='nlri-unicast'" { + "../../rt:safi='nlri-unicast'" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
description description
"This augment defines the content of IPv4 unicast routes."; "This augment defines the content of IPv4 unicast routes.";
uses route-content; uses route-content;
} }
} }
<CODE ENDS> <CODE ENDS>
8. IPv6 Unicast Routing YANG Module 8. IPv6 Unicast Routing YANG Module
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number and all occurrences of the revision date below with actual RFC number and all occurrences of the revision date below with
the date of RFC publication (and remove this note). the date of RFC publication (and remove this note).
<CODE BEGINS> file "ietf-ipv6-unicast-routing@2012-02-20.yang" <CODE BEGINS> file "ietf-ipv6-unicast-routing@2012-05-24.yang"
module ietf-ipv6-unicast-routing { module ietf-ipv6-unicast-routing {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing";
prefix "v6ur"; prefix "v6ur";
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
} }
skipping to change at page 42, line 4 skipping to change at page 39, line 4
<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@nic.cz> <mailto:lhotka@nic.cz>
"; ";
description description
"This module augments the 'ietf-routing' module with YANG "This YANG module augments the 'ietf-routing' module with basic
definitions for basic configuration of IPv6 unicast routing. configuration and operational state data for IPv6 unicast
routing.
Every implementation must preconfigure a routing table with the
name 'main-ipv6-unicast', which is the main routing table for
IPv6 unicast.
Copyright (c) 2012 IETF Trust and the persons identified as Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices.
"; ";
revision 2012-02-20 { revision 2012-05-24 {
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 */ /* Groupings */
grouping route-content { grouping route-content {
description description
"Specific parameters of IPv6 unicast routes."; "Specific parameters of IPv6 unicast routes.";
uses rt:route-content;
leaf dest-prefix { leaf dest-prefix {
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"IPv6 destination prefix."; "IPv6 destination prefix.";
} }
leaf next-hop { leaf next-hop {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
/* RPC Methods */ /* RPC Methods */
augment "/rt:active-route/rt:input/rt:destination-address" {
augment "/rt:get-route/rt:input/rt:destination-address" { when "address-family='ipv6' and safi='nlri-unicast'" {
when "address-family='ipV6' and safi='nlri-unicast'" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
description description
"The 'address' leaf augments the 'rt:destination-address' "The 'address' leaf augments the 'rt:destination-address'
parameter of the 'rt:get-route' operation."; parameter of the 'rt:active-route' operation.";
leaf address { leaf address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 destination address."; "IPv6 destination address.";
} }
} }
augment "/rt:get-route/rt:output/rt:route" { augment "/rt:active-route/rt:output/rt:route" {
when "address-family='ipV6' and safi='nlri-unicast'" { when "address-family='ipv6' and safi='nlri-unicast'" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
description description
"Contents of the reply to 'rt:get-route' operation."; "Contents of the reply to 'rt:active-route' operation.";
uses route-content; uses route-content;
} }
/* Data nodes */ /* Data nodes */
augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {
when "/if:interfaces/if:interface[name=current()/name] " when "/if:interfaces/if:interface[name=current()/name] "
+ "/ip:ipv6/ip:enabled='true'" { + "/ip:ipv6/ip:enabled='true'" {
description description
"This augment is only valid for router interfaces with "This augment is only valid for router interfaces with
skipping to change at page 44, line 34 skipping to change at page 41, line 39
"The minimum time allowed between sending unsolicited "The minimum time allowed between sending unsolicited
multicast Router Advertisements from the interface. multicast Router Advertisements from the interface.
Must be no greater than 0.75 * max-rtr-adv-interval. Must be no greater than 0.75 * max-rtr-adv-interval.
Its default value is dynamic: Its default value is dynamic:
- if max-rtr-adv-interval >= 9 seconds, the default value - if max-rtr-adv-interval >= 9 seconds, the default value
is 0.33 * max-rtr-adv-interval; is 0.33 * max-rtr-adv-interval;
- otherwise it is max-rtr-adv-interval. - otherwise it is 0.75 * max-rtr-adv-interval.
"; ";
} }
leaf managed-flag { leaf managed-flag {
type boolean; type boolean;
default "false"; default "false";
description description
"The boolean value to be placed in the 'Managed address "The boolean value to be placed in the 'Managed address
configuration' flag field in the Router Advertisement."; configuration' flag field in the Router Advertisement.";
} }
leaf other-config-flag { leaf other-config-flag {
skipping to change at page 46, line 8 skipping to change at page 43, line 12
http://www.iana.org/assignments/ip-parameters"; http://www.iana.org/assignments/ip-parameters";
} }
leaf default-lifetime { leaf default-lifetime {
type uint16 { type uint16 {
range "0..9000"; range "0..9000";
} }
units "seconds"; units "seconds";
description description
"The value to be placed in the Router Lifetime field of "The value to be placed in the Router Lifetime field of
Router Advertisements sent from the interface, in seconds. Router Advertisements sent from the interface, in seconds.
MUST be either zero or between MaxRtrAdvInterval and 9000 MUST be either zero or between max-rtr-adv-interval and
seconds. A value of zero indicates that the router is not 9000 seconds. A value of zero indicates that the router is
to be used as a default router. These limits may be not to be used as a default router. These limits may be
overridden by specific documents that describe how IPv6 overridden by specific documents that describe how IPv6
operates over different link layers. operates over different link layers.
The default value is dynamic and should be set to 3 * The default value is dynamic and should be set to 3 *
max-rtr-adv-interval. max-rtr-adv-interval.
"; ";
} }
container prefix-list { container prefix-list {
description description
"A list of prefixes to be placed in Prefix Information "A list of prefixes to be placed in Prefix Information
options in Router Advertisement messages sent from the options in Router Advertisement messages sent from the
interface. interface.
Default: all prefixes that the router advertises via By default, all prefixes that the router advertises via
routing protocols as being on-link for the interface from routing protocols as being on-link for the interface from
which the advertisement is sent. The link-local prefix which the advertisement is sent. The link-local prefix
should not be included in the list of advertised prefixes. should not be included in the list of advertised prefixes.
"; ";
list prefix { list prefix {
key "seqno"; key "prefix-spec";
unique "prefix-spec";
description description
"Advertised prefix entry."; "Advertised prefix entry.";
leaf seqno {
type uint8;
description
"Sequential number of the entry.";
}
leaf prefix-spec { leaf prefix-spec {
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"IPv6 address prefix."; "IPv6 address prefix.";
} }
leaf valid-lifetime { choice control-adv-prefixes {
type uint32; default "advertise";
units "seconds";
default "2592000";
description description
"The value to be placed in the Valid Lifetime in the "The prefix either may be explicitly removed from the
Prefix Information option, in seconds. The designated set of advertised prefixes, or parameters with which
value of all 1's (0xffffffff) represents infinity. it is advertised may be specified (default case).";
leaf no-advertise {
type empty;
description
"The prefix will not be advertised.
Implementations may allow valid-lifetime to be This may be used for removing the prefix from the
specified in two ways: default set of advertised prefixes.
";
}
case advertise {
leaf valid-lifetime {
type uint32;
units "seconds";
default "2592000";
description
"The value to be placed in the Valid Lifetime in
the Prefix Information option, in seconds. The
designated value of all 1's (0xffffffff)
represents infinity.
1. a time that decrements in real time, that is, one Implementations may allow valid-lifetime to be
that will result in a Lifetime of zero at the specified in two ways:
specified time in the future,
2. a fixed time that stays the same in consecutive 1. a time that decrements in real time, that is,
advertisements. one that will result in a lifetime of zero at
"; the specified time in the future,
}
leaf on-link-flag {
type boolean;
default "true";
description
"The value to be placed in the on-link flag ('L-bit')
field in the Prefix Information option.";
}
leaf preferred-lifetime {
type uint32;
units "seconds";
default "604800";
description
"The value to be placed in the Preferred Lifetime in
the Prefix Information option, in seconds. The
designated value of all 1's (0xffffffff) represents
infinity.
Implementations MAY allow AdvPreferredLifetime to be 2. a fixed time that stays the same in consecutive
specified in two ways: advertisements.
";
}
leaf on-link-flag {
type boolean;
default "true";
description
"The value to be placed in the on-link flag
('L-bit') field in the Prefix Information
option.";
}
leaf preferred-lifetime {
type uint32;
units "seconds";
default "604800";
description
"The value to be placed in the Preferred Lifetime
in the Prefix Information option, in seconds. The
designated value of all 1's (0xffffffff)
represents infinity.
1. a time that decrements in real time, that is, one Implementations MAY allow preferred-lifetime to be
that will result in a Lifetime of zero at a specified in two ways:
specified time in the future,
2. a fixed time that stays the same in consecutive 1. a time that decrements in real time, that is,
advertisements. one that will result in a lifetime of zero at a
"; specified time in the future,
}
leaf autonomous-flag { 2. a fixed time that stays the same in consecutive
type boolean; advertisements.
default "true"; ";
description }
"The value to be placed in the Autonomous Flag field in leaf autonomous-flag {
the Prefix Information option."; type boolean;
default "true";
description
"The value to be placed in the Autonomous Flag
field in the Prefix Information option.";
}
}
} }
} }
} }
} }
} }
augment "/rt:routing/rt:router/rt:routing-protocols/" augment "/rt:routing/rt:router/rt:routing-protocols/"
+ "rt:routing-protocol/rt:static-routes" { + "rt:routing-protocol/rt:static-routes" {
description description
"This augment defines the configuration of the 'static' "This augment defines the configuration of the 'static'
pseudo-protocol with data specific for IPv6 unicast."; pseudo-protocol with data specific for IPv6 unicast.";
container ipv6 { container ipv6 {
description description
"Configuration of a 'static' pseudo-protocol instance "Configuration of a 'static' pseudo-protocol instance
consists of a list of routes."; consists of a list of routes.";
list route { list route {
key "seqno"; key "seqno";
ordered-by "user"; ordered-by "user";
description description
"A user-ordered list of static routes."; "A user-ordered list of static routes.";
leaf seqno { leaf seqno {
type uint16; type uint32 {
range "1..max";
}
description description
"Sequential number of the route."; "Sequential number of the route.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route."; "Textual description of the route.";
} }
uses route-content; uses rt:route-content;
uses route-content {
refine "dest-prefix" {
mandatory "true";
}
}
} }
} }
} }
augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/"
+ "rt:routes/rt:route" { + "rt:routes/rt:route" {
when "../../rt:address-family='ipV6' and " when "../../rt:address-family='ipv6' and "
+ "../../rt:safi='nlri-unicast'" { + "../../rt:safi='nlri-unicast'" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
description description
"This augment defines the content of IPv6 unicast routes."; "This augment defines the content of IPv6 unicast routes.";
uses route-content; uses route-content;
} }
} }
skipping to change at page 49, line 37 skipping to change at page 47, line 37
---------------------------------------------------------- ----------------------------------------------------------
---------------------------------------------------------- ----------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-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.
---------------------------------------------------------- ----------------------------------------------------------
----------------------------------------------------------
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 This document registers the following YANG modules in the YANG Module
Names registry [RFC6020]: 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
------------------------------------------------------------------- -------------------------------------------------------------------
skipping to change at page 50, line 26 skipping to change at page 49, line 5
reference: RFC XXXX reference: RFC XXXX
------------------------------------------------------------------- -------------------------------------------------------------------
------------------------------------------------------------------- -------------------------------------------------------------------
name: ietf-ipv6-unicast-routing name: ietf-ipv6-unicast-routing
namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing
prefix: v6ur prefix: v6ur
reference: RFC XXXX reference: RFC XXXX
------------------------------------------------------------------- -------------------------------------------------------------------
-------------------------------------------------------------------
name: iana-afn-safi
namespace: urn:ietf:params:xml:ns:yang:iana-afn-safi
prefix: ianaaf
reference: RFC XXXX
-------------------------------------------------------------------
10. Security Considerations 10. Security Considerations
The YANG modules defined in this document are designed to be accessed The YANG modules defined in this document are designed to be accessed
via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure secure transport layer and the mandatory-to-implement secure
transport is SSH [RFC6242]. transport is SSH [RFC6242].
A number of data nodes defined in the YANG modules are writable/ A number of data nodes defined in the YANG modules are writable/
creatable/deletable (i.e., "config true" in YANG terms, which is the creatable/deletable (i.e., "config true" in YANG terms, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations to these data nodes, in some network environments. Write operations to these data nodes,
such as "edit-config", can have negative effects on the network if such as "edit-config", can have negative effects on the network if
the operations are not properly protected. the protocol operations are not properly protected.
The vulnerable "config true" subtrees and data nodes are the The vulnerable "config true" subtrees and data nodes are the
following: following:
/rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a /rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a
logical interface to a router instance and may also specify network layer interface to a router instance and may also specify
interface parameters related to routing. interface parameters related to routing.
/rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This /rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This
list specifies the routing protocols configured on a device. list specifies the routing protocols configured on a device.
/rt:routing/rt:router/rt:route-filters/rt:route-filter This list /rt:routing/rt:router/rt:route-filters/rt:route-filter This list
specifies the configured route filters which represent the specifies the configured route filters which represent the
administrative policies for redistributing and modifying routing administrative policies for redistributing and modifying routing
information. information.
Unauthorized access to any of these lists can adversely affect the Unauthorized access to any of these lists can adversely affect the
routing subsystem of both the local device and the network. This may routing subsystem of both the local device and the network. This may
lead to network malfunctions, delivery of packets to inappropriate lead to network malfunctions, delivery of packets to inappropriate
destinations and other problems. destinations and other problems.
11. Acknowledgments 11. Acknowledgments
The author wishes to thank Martin Bjorklund, Joel Halpern, Tom Petch The author wishes to thank Martin Bjorklund, Joel Halpern, Thomas
and Juergen Schoenwaelder for their helpful comments and suggestions. Morin, Tom Petch, Juergen Schoenwaelder, Dave Thaler and Yi Yang for
their helpful comments and suggestions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[IANA-AFN] [IANA-IF-AF]
IANA, "Address Family Numbers.", January 2011. Bjorklund, M., "IANA Interface Type and Address Family
YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in
[IANA-SAFI] progress), April 2012.
IANA, "Subsequent Address Family Identifiers (SAFI)
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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
skipping to change at page 53, line 38 skipping to change at page 51, line 36
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. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "NETCONF Configuration Protocol", RFC 6241, Bierman, "NETCONF Configuration Protocol", RFC 6241,
June 2011. June 2011.
[YANG-IF] Bjorklund, M., "A YANG Data Model for Interface [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface
Configuration", draft-ietf-netmod-interfaces-cfg-03 (work Configuration", draft-ietf-netmod-interfaces-cfg-04 (work
in progress), February 2012. in progress), April 2012.
[YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration",
draft-ietf-netmod-ip-cfg-02 (work in progress), draft-ietf-netmod-ip-cfg-03 (work in progress),
February 2012. April 2012.
12.2. Informative References 12.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 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. 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. The YANG module extended to support a new routing protocol. The YANG module
"example-rip" shown below is intended only as an illustration rather "example-rip" shown below is intended only as an illustration rather
than a real definition of a data model for the RIP routing protocol. than a real definition of a data model for the RIP routing protocol.
For the sake of brevity, we do not follow all the guidelines For the sake of brevity, we do not follow all the guidelines
specified in [RFC6087]. See also Section 4.4.1. specified in [RFC6087]. See also Section 4.4.2.
<CODE BEGINS> file "example-rip@2012-02-20.yang" <CODE BEGINS> file "example-rip@2012-05-24.yang"
module example-rip { module example-rip {
namespace "http://example.com/rip"; namespace "http://example.com/rip";
prefix "rip"; prefix "rip";
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
} }
skipping to change at page 55, line 18 skipping to change at page 53, line 18
+ "rt:type='rip:rip'" { + "rt:type='rip:rip'" {
description description
"This augment is only valid if the source protocol from which "This augment is only valid if the source protocol from which
the route originated is RIP."; the route originated is RIP.";
} }
description description
"RIP-specific route components."; "RIP-specific route components.";
uses route-content; uses route-content;
} }
augment "/rt:get-route/rt:output/rt:route" { augment "/rt:active-route/rt:output/rt:route" {
description description
"Add RIP-specific route content."; "Add RIP-specific route content.";
uses route-content; uses route-content;
} }
augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { augment "/rt:routing/rt:router/rt:interfaces/rt:interface" {
when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " when "../../rt:routing-protocols/rt:routing-protocol/rt:type = "
+ "'rip:rip'"; + "'rip:rip'";
container rip { container rip {
description description
skipping to change at page 57, line 13 skipping to change at page 55, line 13
<CODE ENDS> <CODE ENDS>
Appendix B. Example: Reply to the NETCONF <get> Message Appendix B. Example: 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 (i.e., advertising them in which could be sent by a server supporting (i.e., advertising them in
the NETCONF <hello> message) the following YANG modules: the NETCONF <hello> message) the following YANG modules:
o ietf-interfaces [YANG-IF], o ietf-interfaces [YANG-IF],
o ex-ethernet [YANG-IF],
o ietf-ip [YANG-IP], o ietf-ip [YANG-IP],
o ietf-routing (Section 6), o ietf-routing (Section 6),
o ietf-ipv4-unicast-routing (Section 7), o ietf-ipv4-unicast-routing (Section 7),
o ietf-ipv6-unicast-routing (Section 8). o ietf-ipv6-unicast-routing (Section 8).
We assume a simple network setup as shown in Figure 3: router "A" We assume a simple network setup as shown in Figure 3: router "A"
uses static default routes with the "ISP" router as the next hop. uses static default routes with the "ISP" router as the next hop.
skipping to change at page 58, line 12 skipping to change at page 56, line 9
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"?>
<rpc-reply <rpc-reply
message-id="101" message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing" xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"
xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing" xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"
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:ip="urn:ietf:params:xml:ns:yang:ietf-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">
<data> <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:ipv4> <ip:ipv4>
<ip:address> <ip:address>
skipping to change at page 59, line 7 skipping to change at page 57, line 4
</ip:ipv4> </ip:ipv4>
<ip:ipv6> <ip:ipv6>
<ip:address> <ip:address>
<ip:ip>2001:0db8:0:2::1</ip:ip> <ip:ip>2001:0db8:0:2::1</ip:ip>
<ip:prefix-length>64</ip:prefix-length> <ip:prefix-length>64</ip:prefix-length>
</ip:address> </ip:address>
<ip:autoconf> <ip:autoconf>
<ip:create-global-addresses>false</ip:create-global-addresses> <ip:create-global-addresses>false</ip:create-global-addresses>
</ip:autoconf> </ip:autoconf>
</ip:ipv6> </ip:ipv6>
</if:interface> </if:interface>
</if:interfaces> </if:interfaces>
<rt:routing> <rt:routing>
<rt:router> <rt:router>
<rt:name>rtr0</rt:name> <rt:name>rtr0</rt:name>
<rt:interfaces> <rt:interfaces>
<rt:interface> <rt:interface>
<rt:name>eth0</rt:name> <rt:name>eth0</rt:name>
</rt:interface> </rt:interface>
<rt:interface> <rt:interface>
<rt:name>eth1</rt:name> <rt:name>eth1</rt:name>
<v6ur:ipv6-router-advertisements> <v6ur:ipv6-router-advertisements>
<v6ur:send-advertisements>true</v6ur:send-advertisements> <v6ur:send-advertisements>true</v6ur:send-advertisements>
<v6ur:prefix-list> <v6ur:prefix-list>
<v6ur:prefix> <v6ur:prefix>
<v6ur:seqno>1</v6ur:seqno>
<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec> <v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec>
</v6ur:prefix> </v6ur:prefix>
</v6ur:prefix-list> </v6ur:prefix-list>
</v6ur:ipv6-router-advertisements> </v6ur:ipv6-router-advertisements>
</rt:interface> </rt:interface>
</rt:interfaces> </rt:interfaces>
<rt:routing-protocols> <rt:routing-protocols>
<rt:routing-protocol> <rt:routing-protocol>
<rt:name>direct</rt:name> <rt:name>direct</rt:name>
<rt:type>rt:direct</rt:type> <rt:type>rt:direct</rt:type>
skipping to change at page 60, line 10 skipping to change at page 58, line 6
<v6ur:ipv6> <v6ur:ipv6>
<v6ur:route> <v6ur:route>
<v6ur:seqno>1</v6ur:seqno> <v6ur:seqno>1</v6ur:seqno>
<v6ur:dest-prefix>::/0</v6ur:dest-prefix> <v6ur:dest-prefix>::/0</v6ur:dest-prefix>
<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop> <v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
</v6ur:route> </v6ur:route>
</v6ur:ipv6> </v6ur:ipv6>
</rt:static-routes> </rt:static-routes>
<rt:connected-routing-tables> <rt:connected-routing-tables>
<rt:routing-table> <rt:routing-table>
<rt:name>ipv4-unicast-main</rt:name> <rt:name>main-ipv4-unicast</rt:name>
</rt:routing-table> </rt:routing-table>
<rt:routing-table> <rt:routing-table>
<rt:name>ipv6-unicast-main</rt:name> <rt:name>main-ipv6-unicast</rt:name>
</rt:routing-table> </rt:routing-table>
</rt:connected-routing-tables> </rt:connected-routing-tables>
</rt:routing-protocol> </rt:routing-protocol>
</rt:routing-protocols> </rt:routing-protocols>
<rt:routing-tables> <rt:routing-tables>
<rt:routing-table> <rt:routing-table>
<rt:name>ipv4-unicast-fib</rt:name> <rt:name>main-ipv4-unicast</rt:name>
<rt:routes> <rt:routes>
<rt:route> <rt:route>
<v4ur:dest-prefix>192.0.2.1/24</v4ur:dest-prefix> <v4ur:dest-prefix>192.0.2.1/24</v4ur:dest-prefix>
<v4ur:outgoing-interface>eth0</v4ur:outgoing-interface> <rt:outgoing-interface>eth0</rt:outgoing-interface>
<rt:source-protocol>direct</rt:source-protocol> <rt:source-protocol>direct</rt:source-protocol>
<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified> <rt:age>3512</rt:age>
</rt:route> </rt:route>
<rt:route> <rt:route>
<v4ur:dest-prefix>198.51.100.0/24</v4ur:dest-prefix> <v4ur:dest-prefix>198.51.100.0/24</v4ur:dest-prefix>
<v4ur:outgoing-interface>eth1</v4ur:outgoing-interface> <rt:outgoing-interface>eth1</rt:outgoing-interface>
<rt:source-protocol>direct</rt:source-protocol> <rt:source-protocol>direct</rt:source-protocol>
<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified> <rt:age>3512</rt:age>
</rt:route> </rt:route>
<rt:route> <rt:route>
<v4ur:dest-prefix>0.0.0.0/0</v4ur:dest-prefix> <v4ur:dest-prefix>0.0.0.0/0</v4ur:dest-prefix>
<v4ur:next-hop>192.0.2.2</v4ur:next-hop>
<rt:source-protocol>st0</rt:source-protocol> <rt:source-protocol>st0</rt:source-protocol>
<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified> <v4ur:next-hop>192.0.2.2</v4ur:next-hop>
<rt:age>2551</rt:age>
</rt:route> </rt:route>
</rt:routes> </rt:routes>
</rt:routing-table> </rt:routing-table>
<rt:routing-table> <rt:routing-table>
<rt:name>ipv6-unicast-fib</rt:name> <rt:name>main-ipv6-unicast</rt:name>
<rt:address-family>ipV6</rt:address-family> <rt:address-family>ipv6</rt:address-family>
<rt:safi>nlri-unicast</rt:safi> <rt:safi>nlri-unicast</rt:safi>
<rt:routes> <rt:routes>
<rt:route> <rt:route>
<v6ur:dest-prefix>2001:db8:0:1::/64</v6ur:dest-prefix> <v6ur:dest-prefix>2001:db8:0:1::/64</v6ur:dest-prefix>
<v6ur:outgoing-interface>eth0</v6ur:outgoing-interface> <rt:outgoing-interface>eth0</rt:outgoing-interface>
<rt:source-protocol>direct</rt:source-protocol> <rt:source-protocol>direct</rt:source-protocol>
<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified> <rt:age>3513</rt:age>
</rt:route> </rt:route>
<rt:route> <rt:route>
<v6ur:dest-prefix>2001:db8:0:2::/64</v6ur:dest-prefix> <v6ur:dest-prefix>2001:db8:0:2::/64</v6ur:dest-prefix>
<v6ur:outgoing-interface>eth1</v6ur:outgoing-interface> <rt:outgoing-interface>eth1</rt:outgoing-interface>
<rt:source-protocol>direct</rt:source-protocol> <rt:source-protocol>direct</rt:source-protocol>
<rt:last-modified>2012-02-20T17:11:27+01:00</rt:last-modified> <rt:age>3513</rt:age>
</rt:route>
<rt:route>
<v6ur:dest-prefix>::/0</v6ur:dest-prefix>
<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
<rt:source-protocol>st0</rt:source-protocol>
<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified>
</rt:route>
</rt:routes>
</rt:routing-table>
<rt:routing-table>
<rt:name>ipv4-unicast-main</rt:name>
<rt:recipient-routing-tables>
<rt:recipient-name>ipv4-unicast-fib</rt:recipient-name>
</rt:recipient-routing-tables>
<rt:routes>
<rt:route>
<v4ur:dest-prefix>0.0.0.0/0</v4ur:dest-prefix>
<rt:source-protocol>st0</rt:source-protocol>
<v4ur:next-hop>192.0.2.2</v4ur:next-hop>
<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified>
</rt:route> </rt:route>
</rt:routes>
</rt:routing-table>
<rt:routing-table>
<rt:name>ipv6-unicast-main</rt:name>
<rt:address-family>ipV6</rt:address-family>
<rt:safi>nlri-unicast</rt:safi>
<rt:recipient-routing-tables>
<rt:recipient-name>ipv6-unicast-fib</rt:recipient-name>
</rt:recipient-routing-tables>
<rt:routes>
<rt:route> <rt:route>
<v6ur:dest-prefix>::/0</v6ur:dest-prefix> <v6ur:dest-prefix>::/0</v6ur:dest-prefix>
<v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop> <v6ur:next-hop>2001:db8:0:1::2</v6ur:next-hop>
<rt:source-protocol>st0</rt:source-protocol> <rt:source-protocol>st0</rt:source-protocol>
<rt:last-modified>2012-02-20T18:02:45+01:00</rt:last-modified> <rt:age>2550</rt:age>
</rt:route> </rt:route>
</rt:routes> </rt:routes>
</rt:routing-table> </rt:routing-table>
</rt:routing-tables> </rt:routing-tables>
</rt:router> </rt:router>
</rt:routing> </rt:routing>
</data> </data>
</rpc-reply> </rpc-reply>
Appendix C. Change Log Appendix C. Change Log
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
C.1. Changes Between Versions -01 and -02 C.1. Changes Between Versions -02 and -03
o Module "iana-afn-safi" moved to I-D "iana-if-type".
o Removed forwarding table.
o RPC "get-route" changed to "active-route". Its output is a list
of routes (for multi-path routing).
o New RPC "route-count".
o For both RPCs, specification of negative responses was added.
o Relaxed separation of router instances.
o Assignment of interfaces to router instances needn't be disjoint.
o Route filters are now global.
o Added "allow-all-route-filter" for symmetry.
o Added Section 5 about interactions with "ietf-interfaces" and
"ietf-ip".
o Added "router-id" leaf.
o Specified the names for IPv4/IPv6 unicast main routing tables.
o Route parameter "last-modified" changed to "age".
o Added container "recipient-routing-tables".
C.2. Changes Between Versions -01 and -02
o Added module "ietf-ipv6-unicast-routing". o Added module "ietf-ipv6-unicast-routing".
o The example in Appendix B now uses IP addresses from blocks o The example in Appendix B now uses IP addresses from blocks
reserved for documentation. reserved for documentation.
o Direct routes appear by default in the FIB table. o Direct routes appear by default in the FIB table.
o Logical interfaces must be assigned to a router instance. o Network layer interfaces must be assigned to a router instance.
Additional interface configuration may be present. Additional interface configuration may be present.
o The "when" statement is only used with "augment", "must" is used o The "when" statement is only used with "augment", "must" is used
elsewhere. elsewhere.
o Additional "must" statements were added. o Additional "must" statements were added.
o The "route-content" grouping for IPv4 and IPv6 unicast now o The "route-content" grouping for IPv4 and IPv6 unicast now
includes the material from the "ietf-routing" version via "uses includes the material from the "ietf-routing" version via "uses
rt:route-content". rt:route-content".
o Explanation of symbols in the tree representation of data model o Explanation of symbols in the tree representation of data model
hierarchy. hierarchy.
C.2. Changes Between Versions -00 and -01 C.3. Changes Between Versions -00 and -01
o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 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- o Typedefs for AFN and SAFI were placed in a separate "iana-afn-
safi" module. safi" module.
o Names of some data nodes were changed, in particular "routing- o Names of some data nodes were changed, in particular "routing-
process" is now "router". process" is now "router".
o The restriction of a single AFN/SAFI per router was lifted. o The restriction of a single AFN/SAFI per router was lifted.
 End of changes. 209 change blocks. 
914 lines changed or deleted 774 lines changed or added

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