draft-ietf-netmod-routing-cfg-03.txt   draft-ietf-netmod-routing-cfg-04.txt 
NETMOD L. Lhotka NETMOD L. Lhotka
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track May 25, 2012 Intended status: Standards Track July 9, 2012
Expires: November 26, 2012 Expires: January 10, 2013
A YANG Data Model for Routing Configuration A YANG Data Model for Routing Configuration
draft-ietf-netmod-routing-cfg-03 draft-ietf-netmod-routing-cfg-04
Abstract Abstract
This document contains a specification of three 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
framework for configuring a routing subsystem. It is therefore framework for configuring a routing subsystem. It is therefore
expected that this module will be augmented by additional YANG expected that these modules will be augmented by additional YANG
modules defining data models for individual routing protocols and modules defining data models for individual routing protocols and
other 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 November 26, 2012. This Internet-Draft will expire on January 10, 2013.
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 42 skipping to change at page 2, line 42
8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 38 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . . 51 12.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Example: Adding a New Routing Protocol . . . . . . . 52 Appendix A. Example: Adding a New Routing Protocol . . . . . . . 52
Appendix B. Example: Reply to the NETCONF <get> Message . . . . . 55 Appendix B. Example: Reply to the NETCONF <get> Message . . . . . 55
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 60 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 60
C.1. Changes Between Versions -02 and -03 . . . . . . . . . . . 60 C.1. Changes Between Versions -03 and -04 . . . . . . . . . . . 60
C.2. Changes Between Versions -01 and -02 . . . . . . . . . . . 60 C.2. Changes Between Versions -02 and -03 . . . . . . . . . . . 60
C.3. Changes Between Versions -00 and -01 . . . . . . . . . . . 61 C.3. Changes Between Versions -01 and -02 . . . . . . . . . . . 61
C.4. Changes Between Versions -00 and -01 . . . . . . . . . . . 61
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
This document contains a specification of the following 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"
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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 router configuration variables required by [RFC4861]. the router configuration variables required by [RFC4861].
These modules together define the so-called core routing data model, These modules together define the so-called core routing data model,
which is proposed as a basis for the development of data models for which is proposed as a basis for the development of data models for
more sophisticated routing configurations. While these three modules more sophisticated routing configurations. While these three modules
can be directly used for simple IP devices with static routing, their can be directly used for simple IP devices with static routing, their
main purpose is to provide essential building blocks for more main purpose is to provide essential building blocks for more
complicated setups involving multiple routing protocols, multicast complicated setups involving multiple routing protocols, multicast
routing, additional address families, advanced functions such as routing, additional address families, and advanced functions such as
route filtering or policy routing etc. To this end, it is expected route filtering or policy routing. To this end, it is expected that
that the core routing data model will be augmented by numerous the core routing data model will be augmented by numerous modules
modules developed by other IETF working groups. developed by other IETF working groups.
2. Terminology and Notation 2. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terms are defined in [RFC6241]: The following terms are defined in [RFC6241]:
o client o client
skipping to change at page 5, line 18 skipping to change at page 5, line 18
routing). 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" and combination of "ietf-routing", "ietf-ipv4-unicast-routing" and
"ietf-ipv6-unicast-routing" 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, RPC methods and other data
prefix, as long as it is clear from the context in which YANG module model objects are used mostly without a prefix, as long as it is
each name is defined. Otherwise, names are prefixed using the clear from the context in which YANG module each name is defined.
standard prefix associated with the corresponding YANG module, as Otherwise, names are prefixed using the standard prefix associated
shown in Table 1. with the corresponding YANG module, as shown in Table 1.
+--------+---------------------------+--------------+ +--------+---------------------------+--------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+--------+---------------------------+--------------+ +--------+---------------------------+--------------+
| ianaaf | iana-afn-safi | [IANA-IF-AF] | | 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] |
| | | | | | | |
skipping to change at page 8, line 12 skipping to change at page 8, line 12
| | +--rw name | | +--rw name
| | +--rw description? | | +--rw description?
| | +--rw type | | +--rw type
| | +--rw connected-routing-tables | | +--rw connected-routing-tables
| | | +--rw routing-table [name] | | | +--rw routing-table [name]
| | | +--rw name | | | +--rw name
| | | +--rw import-filter? | | | +--rw import-filter?
| | | +--rw export-filter? | | | +--rw export-filter?
| | +--rw static-routes | | +--rw static-routes
| | +--rw v4ur:ipv4 | | +--rw v4ur:ipv4
| | | +--rw v4ur:route [seqno] | | | +--rw v4ur:route [id]
| | | +--rw v4ur:seqno | | | +--rw v4ur:id
| | | +--rw v4ur:description? | | | +--rw v4ur:description?
| | | +--rw v4ur:outgoing-interface? | | | +--rw v4ur:outgoing-interface?
| | | +--rw v4ur:dest-prefix | | | +--rw v4ur:dest-prefix
| | | +--rw v4ur:next-hop? | | | +--rw v4ur:next-hop?
| | +--rw v6ur:ipv6 | | +--rw v6ur:ipv6
| | +--rw v6ur:route [seqno] | | +--rw v6ur:route [id]
| | +--rw v6ur:seqno | | +--rw v6ur:id
| | +--rw v6ur:description? | | +--rw v6ur:description?
| | +--rw v6ur:outgoing-interface? | | +--rw v6ur:outgoing-interface?
| | +--rw v6ur:dest-prefix | | +--rw v6ur:dest-prefix
| | +--rw v6ur:next-hop? | | +--rw v6ur:next-hop?
| +--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 outgoing-interface?
| | +--ro source-protocol | | +--ro source-protocol
| | +--ro age | | +--ro age
| | +--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:dest-prefix? | | +--ro v6ur:dest-prefix?
| | +--ro v6ur:next-hop? | | +--ro v6ur:next-hop?
| +--rw recipient-routing-tables | +--rw recipient-routing-tables
| +--rw recipient-routing-table [name] | +--rw recipient-routing-table [name]
| +--rw name | +--rw name
| +--rw filter? | +--rw filter?
+--rw route-filters +--rw route-filters
+--rw route-filter [name] +--rw route-filter [name]
+--rw name +--rw name
+--rw description? +--rw description?
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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. The exact semantics of this term is left to logical router. The exact semantics of this term is left to
implementations. For example, router instances may be completely implementations. For example, router instances may be completely
isolated virtual routers or, alternatively, they may internally share isolated virtual routers or, alternatively, they may internally share
certain information. certain information.
Network layer interfaces must be assigned to a router instance in Each network layer interface must be assigned to one or more router
order to be able to participate in packet forwarding, routing instances in order to be able to participate in packet forwarding,
protocols and other operations of that router instance. The routing protocols and other operations of those router instances.
assignment is accomplished by creating a corresponding entry in the The assignment is accomplished by creating a corresponding entry in
list of router interfaces ("rt:interface"). The key of the list the list of router interfaces ("rt:interface"). The key of the list
entry MUST be the name of a configured network layer interface, i.e., entry MUST be the name of a configured network layer interface, i.e.,
the value of a node /if:interfaces/if:interface/if:name defined in the value of a node /if:interfaces/if:interface/if:name defined in
the "ietf-interfaces" module.[YANG-IF]. the "ietf-interfaces" module [YANG-IF].
Implementations MAY specify additional rules for the assignment of Implementations MAY specify additional rules for the assignment of
interfaces to logical routers. For example, it may be required that interfaces to logical routers. For example, it may be required that
the sets of interfaces assigned to different logical routers be the sets of interfaces assigned to different logical routers be
disjoint. disjoint.
Apart from the key, each entry of the "rt:interface" list MAY contain Apart from the key, each entry of the "rt:interface" list MAY contain
other configuration or operational state data related to the other configuration or operational state data related to the
corresponding router interface. corresponding router interface.
skipping to change at page 11, line 22 skipping to change at page 11, line 22
* 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], is NOTES:
implemented by the "ietf-ip" module [YANG-IP] (leaf "ip:ip-
forwarding"). 1. The "IsRouter" flag, which is also required by [RFC4861], is
implemented in the "ietf-ip" module [YANG-IP] (leaf "ip:ip-
forwarding").
2. The original specification [RFC4861] allows the implementations
to decide whether the "valid-lifetime" and "preferred-lifetime"
parameters remain the same in consecutive advertisements, or
decrement in real time. However, the latter behavior seems
problematic because the values might be reset again to the
(higher) configured values after a configuration is reloaded.
Moreover, no implementation is known to use the decrementing
behavior. The "ietf-ipv6-unicast-routing" module therefore
assumes the former behavior with constant values.
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 an adjacent router or host to which
packets with destination addresses belonging to destination-prefix packets with destination addresses belonging to "destination-
should be sent. prefix" 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 should suffice for a simple static The above list of route attributes suffices 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 both in 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 "age": number of seconds since the route was created or last o "age": number of seconds since the route was created or last
updated. updated.
Each routing table may only contain routes of the same address Each routing table may contain only routes of the same address
family. Address family information consists of two parameters - family. Address family information consists of two parameters -
"address-family" and "safi" (Subsequent Address Family Identifier, "address-family" and "safi" (Subsequent Address Family Identifier,
SAFI). The permitted values for these two parameters are defined by SAFI). The permitted values for these two parameters are defined by
IANA and translated into YANG enumeration types "ianaaf:address- IANA and represented using YANG enumeration types "ianaaf:address-
family" and "ianaaf:subsequent-address-family" [IANA-IF-AF]. 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 route lists are controlled operational state data. The contents of route lists are controlled
and manipulated by routing protocol operations which may result in and manipulated by routing protocol operations which may result in
route additions, removals and modifications. This also includes route additions, removals and modifications. This also includes
manipulations via the "static" and/or "direct" pseudo-protocols, see manipulations via the "static" and/or "direct" pseudo-protocols, see
Section 4.4.1. Section 4.4.1.
skipping to change at page 14, line 38 skipping to change at page 14, line 48
A pseudo-protocol of the type "static" 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
logical router. logical router.
4.4.2. 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. Such a new module has to define additional routing protocol types. Such a new module has to define
the protocol-specific configuration and operational state data, and the protocol-specific configuration and operational state data, and
fit it into the core routing framework in the following way : it has to 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, preferably in one o Additional route attributes MAY be defined, preferably in one
place by means of defining a YANG grouping. The new attributes place by means of defining a YANG grouping. The new attributes
have to be inserted as operational state data by augmenting the have to be inserted as operational state data by augmenting the
definition of "rt:route" inside "rt:routing-table", and possibly definition of "rt:route" inside "rt:routing-table", and possibly
to other places in the configuration, operational state data and to other places in the configuration, operational state data and
skipping to change at page 17, line 24 skipping to change at page 17, line 24
} }
leaf metric { leaf metric {
type rip-metric; type rip-metric;
default "1"; default "1";
} }
} }
} }
Finally, global RIP configuration data are integrated into the "rt: Finally, global RIP configuration data are integrated into the "rt:
routing-protocol" node by using the following "augment" statement, routing-protocol" node by using the following "augment" statement,
which is valid only for routing protocol instances whose type is which is again valid only for routing protocol instances whose type
"rip:rip": is "rip:rip":
augment "/rt:routing/rt:router/rt:routing-protocols/" augment "/rt:routing/rt:router/rt:routing-protocols/"
+ "rt:routing-protocol" { + "rt:routing-protocol" {
when "rt:type = 'rip:rip'"; when "rt:type = 'rip:rip'";
container rip { container rip {
leaf update-interval { leaf update-interval {
type uint8 { type uint8 {
range "10..60"; range "10..60";
} }
units "seconds"; units "seconds";
skipping to change at page 18, line 14 skipping to change at page 18, line 14
may be used by any or all router instances. 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 for applying only the extreme routing policies which are allows for applying only the extreme routing policies which are
represented by the following pre-defined route filter types: represented by the following pre-defined route filter types:
o "deny-all-route-filter": all routes are blocked, o "deny-all-route-filter": all routes are blocked,
o "allow-all-route-filter": all routes are permitted. o "allow-all-route-filter": all routes are permitted.
It is expected that real route filtering frameworks will be developed Note that the latter type is equivalent to no route filter.
separately.
It is expected that more comprehensive route filtering frameworks
will be developed 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 the entire configuration. Its type MUST be specified by the "type"
reference - this opens the space for multiple route filtering identity reference - this opens the space for multiple route
framework implementations. The default value for the route filter filtering framework implementations. The default value for the route
type is the identity "deny-all-route-filter". filter type is the identity "deny-all-route-filter".
4.6. RPC Operations 4.6. RPC Operations
The "ietf-routing" module defines two RPC operations: The "ietf-routing" module defines two RPC operations:
o active-route, o active-route,
o route-count. o route-count.
Their parameters and semantics are described in the following Their parameters and semantics are described in the following
skipping to change at page 19, line 11 skipping to change at page 19, line 14
destination-address: Network layer destination address for which destination-address: Network layer destination address for which
the active routes are requested. the active routes are requested.
Positive Response: One or more "route" elements containing the Positive Response: One or more "route" elements containing the
active route(s). active route(s).
Negative Response: Negative Response:
If the logical router is not found, the server sends an "rpc- If the logical router is not found, the server sends an "rpc-
error" message with "error-tag" set to "missing-element", and error" message with "error-tag" set to "data-missing", and "error-
"error-app-tag" set to "router-not-found". app-tag" set to "router-not-found".
If no route exists for the given destination address, the server If no route exists for the given destination address, the server
sends an "rpc-error" message with "error-tag" set to "data- sends an "rpc-error" message with "error-tag" set to "data-
missing" and "error-app-tag" set to "no-route". missing" and "error-app-tag" set to "no-route".
4.6.2. Operation "route-count" 4.6.2. Operation "route-count"
Description: Retrieve the total number of routes in a routing table. Description: Retrieve the total number of routes in a routing table.
Parameters: Parameters:
skipping to change at page 19, line 34 skipping to change at page 19, line 37
router-name: Name of the logical router containing the routing router-name: Name of the logical router containing the routing
table. table.
routing-table: Name of the routing table. routing-table: Name of the routing table.
Positive Response: Element "number-of-routes" containing the Positive Response: Element "number-of-routes" containing the
requested nonnegative number. requested nonnegative number.
Negative Response: If the logical router or the routing table is not Negative Response: If the logical router or the routing table is not
found, the server sends an "rpc-error" message with "error-tag" found, the server sends an "rpc-error" message with "error-tag"
set to "missing-element", and "error-app-tag" set to "router-not- set to "data-missing", and "error-app-tag" set to "router-not-
found" or "routing-table-not-found", respectively. found" or "routing-table-not-found", respectively.
5. Interactions with Other YANG Modules 5. Interactions with Other YANG Modules
The semantics of the core routing data model also depends on several The semantics of the core routing data model also depend on several
configuration parameters that are defined in other YANG modules. The configuration parameters that are defined in other YANG modules. The
following subsections describe these interactions. following subsections describe these interactions.
5.1. Module "ietf-interfaces" 5.1. Module "ietf-interfaces"
The following boolean switch is defined in the "ietf-interfaces" YANG The following boolean switch is defined in the "ietf-interfaces" YANG
module [YANG-IF]: module [YANG-IF]:
/if:interfaces/if:interface/if:enabled /if:interfaces/if:interface/if:enabled
skipping to change at page 22, line 11 skipping to change at page 22, line 11
destination prefix is set according to the configured IP address and destination prefix is set according to the configured IP address and
subnet mask, and the interface is set as the outgoing interface for subnet mask, and the interface is set as the outgoing interface for
that route. 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-05-24.yang" <CODE BEGINS> file "ietf-routing@2012-07-09.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-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
skipping to change at page 23, line 17 skipping to change at page 23, line 17
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-05-24 { revision 2012-07-09 {
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 24, line 12 skipping to change at page 24, line 12
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 { identity allow-all-route-filter {
base route-filter; base route-filter;
description description
"Route filter that permits all routes. "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
skipping to change at page 34, line 11 skipping to change at page 34, line 11
} }
<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-05-25.yang" <CODE BEGINS> file "ietf-ipv4-unicast-routing@2012-07-09.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 35, line 19 skipping to change at page 35, line 19
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-05-24 { revision 2012-07-09 {
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
skipping to change at page 36, line 34 skipping to change at page 36, line 34
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 "id";
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 id {
type uint32 { type uint32 {
range "1..max"; range "1..max";
} }
description description
"Sequential number of the route."; 'Numeric identifier of the route.
It is not required that the routes be sorted according
to their "id".
';
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route."; "Textual description of the route.";
} }
uses rt:route-content; uses rt:route-content;
uses route-content { uses route-content {
refine "dest-prefix" { refine "dest-prefix" {
mandatory "true"; mandatory "true";
} }
} }
} }
} }
} }
skipping to change at page 38, line 11 skipping to change at page 38, line 11
} }
<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-05-24.yang" <CODE BEGINS> file "ietf-ipv6-unicast-routing@2012-07-09.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 39, line 26 skipping to change at page 39, line 26
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-05-24 { revision 2012-07-09 {
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
skipping to change at page 40, line 32 skipping to change at page 40, line 32
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
description description
"Contents of the reply to 'rt:active-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:ipv6/ip:enabled='true'" { + "ip:enabled='true'" {
description description
"This augment is only valid for router interfaces with "This augment is only valid for router interfaces with
enabled IPv6. enabled IPv6.
NOTE: Parameter 'is-router' is not included, it is expected NOTE: Parameter 'is-router' is not included, it is expected
that it will be implemented by the 'ietf-ip' module. that it will be implemented by the 'ietf-ip' module.
"; ";
} }
description description
"IPv6-specific parameters of router interfaces."; "IPv6-specific parameters of router interfaces.";
skipping to change at page 44, line 19 skipping to change at page 44, line 19
case advertise { case advertise {
leaf valid-lifetime { leaf valid-lifetime {
type uint32; type uint32;
units "seconds"; units "seconds";
default "2592000"; default "2592000";
description description
"The value to be placed in the Valid Lifetime in "The value to be placed in the Valid Lifetime in
the Prefix Information option, in seconds. The the Prefix Information option, in seconds. The
designated value of all 1's (0xffffffff) designated value of all 1's (0xffffffff)
represents infinity. represents infinity.
Implementations may allow valid-lifetime to be
specified in two ways:
1. a time that decrements in real time, that is,
one that will result in a lifetime of zero at
the specified time in the future,
2. a fixed time that stays the same in consecutive
advertisements.
"; ";
} }
leaf on-link-flag { leaf on-link-flag {
type boolean; type boolean;
default "true"; default "true";
description description
"The value to be placed in the on-link flag "The value to be placed in the on-link flag
('L-bit') field in the Prefix Information ('L-bit') field in the Prefix Information
option."; option.";
} }
leaf preferred-lifetime { leaf preferred-lifetime {
type uint32; type uint32;
units "seconds"; units "seconds";
must ". <= ../valid-lifetime" {
description
"This value must not be larger than
valid-lifetime.";
}
default "604800"; default "604800";
description description
"The value to be placed in the Preferred Lifetime "The value to be placed in the Preferred Lifetime
in the Prefix Information option, in seconds. The in the Prefix Information option, in seconds. The
designated value of all 1's (0xffffffff) designated value of all 1's (0xffffffff)
represents infinity. represents infinity.
Implementations MAY allow preferred-lifetime to be
specified in two ways:
1. a time that decrements in real time, that is,
one that will result in a lifetime of zero at a
specified time in the future,
2. a fixed time that stays the same in consecutive
advertisements.
"; ";
} }
leaf autonomous-flag { leaf autonomous-flag {
type boolean; type boolean;
default "true"; default "true";
description description
"The value to be placed in the Autonomous Flag "The value to be placed in the Autonomous Flag
field in the Prefix Information option."; field in the Prefix Information option.";
} }
} }
skipping to change at page 45, line 35 skipping to change at page 45, line 21
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 "id";
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 id {
type uint32 { type uint32 {
range "1..max"; range "1..max";
} }
description description
"Sequential number of the route."; 'Numeric identifier of the route.
It is not required that the routes be sorted according
to their "id".
';
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route."; "Textual description of the route.";
} }
uses rt:route-content; uses rt:route-content;
uses route-content { uses route-content {
refine "dest-prefix" { refine "dest-prefix" {
mandatory "true"; mandatory "true";
skipping to change at page 52, line 14 skipping to change at page 52, line 14
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.2. specified in [RFC6087]. See also Section 4.4.2.
<CODE BEGINS> file "example-rip@2012-05-24.yang" <CODE BEGINS> file "example-rip@2012-07-09.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 48 skipping to change at page 55, line 48
| | | |
| Router A | | Router A |
| | | |
+--------+--------+ +--------+--------+
eth1|198.51.100.1 eth1|198.51.100.1
|2001:db8:0:2::1 |2001:db8:0:2::1
| |
Figure 3: Example network configuration Figure 3: Example network configuration
Router "A" then could send the following XML document as its reply to A reply to the NETCONF <get> message sent by router "A" would then be
the NETCONF <get> message: as follows:
<?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: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">
skipping to change at page 57, line 40 skipping to change at page 57, line 40
</rt:routing-protocol> </rt:routing-protocol>
<rt:routing-protocol> <rt:routing-protocol>
<rt:name>st0</rt:name> <rt:name>st0</rt:name>
<rt:description> <rt:description>
Static routing is used for the internal network. Static routing is used for the internal network.
</rt:description> </rt:description>
<rt:type>rt:static</rt:type> <rt:type>rt:static</rt:type>
<rt:static-routes> <rt:static-routes>
<v4ur:ipv4> <v4ur:ipv4>
<v4ur:route> <v4ur:route>
<v4ur:seqno>1</v4ur:seqno> <v4ur:id>1</v4ur:id>
<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> <v4ur:next-hop>192.0.2.2</v4ur:next-hop>
</v4ur:route> </v4ur:route>
</v4ur:ipv4> </v4ur:ipv4>
<v6ur:ipv6> <v6ur:ipv6>
<v6ur:route> <v6ur:route>
<v6ur:seqno>1</v6ur:seqno> <v6ur:id>1</v6ur:id>
<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>main-ipv4-unicast</rt:name> <rt:name>main-ipv4-unicast</rt:name>
</rt:routing-table> </rt:routing-table>
<rt:routing-table> <rt:routing-table>
skipping to change at page 60, line 9 skipping to change at page 60, line 9
</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 -02 and -03 C.1. Changes Between Versions -03 and -04
o Changed "error-tag" for both RPC methods from "missing element" to
"data-missing".
o Removed the decrementing behavior for advertised IPv6 prefix
parameters "valid-lifetime" and "preferred-lifetime".
o Changed the key of the static route lists from "seqno" to "id"
because the routes needn't be sorted.
o Added 'must' constraint saying that "preferred-lifetime" must not
be greater than "valid-lifetime".
C.2. Changes Between Versions -02 and -03
o Module "iana-afn-safi" moved to I-D "iana-if-type". o Module "iana-afn-safi" moved to I-D "iana-if-type".
o Removed forwarding table. o Removed forwarding table.
o RPC "get-route" changed to "active-route". Its output is a list o RPC "get-route" changed to "active-route". Its output is a list
of routes (for multi-path routing). of routes (for multi-path routing).
o New RPC "route-count". o New RPC "route-count".
skipping to change at page 60, line 41 skipping to change at page 61, line 7
"ietf-ip". "ietf-ip".
o Added "router-id" leaf. o Added "router-id" leaf.
o Specified the names for IPv4/IPv6 unicast main routing tables. o Specified the names for IPv4/IPv6 unicast main routing tables.
o Route parameter "last-modified" changed to "age". o Route parameter "last-modified" changed to "age".
o Added container "recipient-routing-tables". o Added container "recipient-routing-tables".
C.2. Changes Between Versions -01 and -02 C.3. 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 Network layer 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.
skipping to change at page 61, line 17 skipping to change at page 61, line 31
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.3. Changes Between Versions -00 and -01 C.4. 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. 52 change blocks. 
97 lines changed or deleted 117 lines changed or added

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