draft-ietf-netmod-rfc8022bis-11.txt   rfc8349.txt 
NETMOD Working Group L. Lhotka Internet Engineering Task Force (IETF) L. Lhotka
Internet-Draft CZ.NIC Request for Comments: 8349 CZ.NIC
Obsoletes: 8022 (if approved) A. Lindem Obsoletes: 8022 A. Lindem
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: July 30, 2018 Y. Qu ISSN: 2070-1721 Y. Qu
Huawei Huawei
January 26, 2018 March 2018
A YANG Data Model for Routing Management (NMDA Version) A YANG Data Model for Routing Management (NMDA Version)
draft-ietf-netmod-rfc8022bis-11
Abstract Abstract
This document contains a specification of three YANG modules and one This document specifies three YANG modules and one submodule.
submodule. Together they form the core routing data model that Together, they form the core routing data model that serves as a
serves as a framework for configuring and managing a routing framework for configuring and managing a routing subsystem. It is
subsystem. It is expected that these modules will be augmented by expected that these modules will be augmented by additional YANG
additional YANG modules defining data models for control-plane modules defining data models for control-plane protocols, route
protocols, route filters, and other functions. The core routing data filters, and other functions. The core routing data model provides
model provides common building blocks for such extensions -- routes, common building blocks for such extensions -- routes, Routing
Routing Information Bases (RIBs), and control-plane protocols. Information Bases (RIBs), and control-plane protocols.
The YANG modules in this document conform to the Network Management The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA). This document obsoletes RFC 8022. Datastore Architecture (NMDA). This document obsoletes RFC 8022.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on July 30, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8349.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5
2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Design of the Core Routing Data Model . . . . . . . . . . 6 4. The Design of the Core Routing Data Model . . . . . . . . . . 7
4.1. System-Controlled and User-Controlled List Entries . . . 7 4.1. System-Controlled and User-Controlled List Entries . . . 8
5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 8 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 9
5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Routes . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9 5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 10
5.3. Control-Plane Protocol . . . . . . . . . . . . . . . . . 9 5.3. Control-Plane Protocol . . . . . . . . . . . . . . . . . 11
5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10 5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 11
5.3.2. Defining New Control-Plane Protocols . . . . . . . . 10 5.3.2. Defining New Control-Plane Protocols . . . . . . . . 11
5.4. Parameters of IPv6 Router Advertisements . . . . . . . . 11 5.4. Parameters of IPv6 Router Advertisements . . . . . . . . 12
6. Interactions with Other YANG Modules . . . . . . . . . . . . 12 6. Interactions with Other YANG Modules . . . . . . . . . . . . 13
6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 12 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 13
6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 12 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 14
7. Routing Management YANG Module . . . . . . . . . . . . . . . 13 7. Routing Management YANG Module . . . . . . . . . . . . . . . 15
8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 27 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 29
9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 35 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 37
9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 44 9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
11. Security Considerations . . . . . . . . . . . . . . . . . . . 55 11. Security Considerations . . . . . . . . . . . . . . . . . . . 57
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
12.1. Normative References . . . . . . . . . . . . . . . . . . 56 12.1. Normative References . . . . . . . . . . . . . . . . . . 58
12.2. Informative References . . . . . . . . . . . . . . . . . 58 12.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. The Complete Schema Tree . . . . . . . . . . . . . . 59 Appendix A. The Complete Schema Tree . . . . . . . . . . . . . . 61
Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 64 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 66
Appendix C. Example: Adding a New Control-Plane Protocol . . . . 64 Appendix C. Example: Adding a New Control-Plane Protocol . . . . 67
Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 67 Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 70
Appendix E. NETCONF Get Data Reply Example . . . . . . . . . . . 73 Appendix E. NETCONF Get Data Reply Example . . . . . . . . . . . 77
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
This document contains a specification of the following YANG modules: This document specifies the following YANG modules:
o The "ietf-routing" module provides generic components of a routing o The "ietf-routing" module provides generic components of a routing
data model. data model.
o The "ietf-ipv4-unicast-routing" module augments the "ietf-routing" o The "ietf-ipv4-unicast-routing" module augments the "ietf-routing"
module with additional data specific to IPv4 unicast. module with additional data specific to IPv4 unicast.
o The "ietf-ipv6-unicast-routing" module augments the "ietf-routing" o The "ietf-ipv6-unicast-routing" module augments the "ietf-routing"
module with additional data specific to IPv6 unicast. Its module with additional data specific to IPv6 unicast. Its
submodule "ietf-ipv6-router-advertisements" also augments the submodule, "ietf-ipv6-router-advertisements", also augments the
"ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and "ietf- "ietf-interfaces" [RFC8343] and "ietf-ip" [RFC8344] modules with
ip" [I-D.ietf-netmod-rfc7277bis] modules with IPv6 router IPv6 router configuration variables required by [RFC4861].
configuration variables required by [RFC4861].
These modules together define the so-called core routing data model, These modules together define the core routing data model, which is
which is intended as a basis for future data model development intended as a basis for future data model development covering
covering more-sophisticated routing systems. While these three more-sophisticated routing systems. While these three modules can be
modules can be directly used for simple IP devices with static directly used for simple IP devices with static routing (see
routing (see Appendix B), their main purpose is to provide essential Appendix B), their main purpose is to provide essential building
building blocks for more-complicated data models involving multiple blocks for more-complicated data models involving multiple
control-plane protocols, multicast routing, additional address control-plane protocols, multicast routing, additional address
families, and advanced functions such as route filtering or policy families, and advanced functions such as route filtering or policy
routing. To this end, it is expected that the core routing data routing. To this end, it is expected that the core routing data
model will be augmented by numerous modules developed by various IETF model will be augmented by numerous modules developed by various IETF
working groups. working groups.
The YANG modules in this document conform to the Network Management The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores]. Datastore Architecture (NMDA) [RFC8342]. This document obsoletes
This document obsoletes RFC 8022 [RFC8022]. RFC 8022 [RFC8022].
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined in The following terms are defined in [RFC8342]:
[I-D.ietf-netmod-revised-datastores]:
o client o client
o server o server
o configuration
o configuration
o system state o system state
o operational state o operational state
o intended configuration o intended configuration
The following terms are defined in [RFC7950]: The following terms are defined in [RFC7950]:
o action o action
o augment o augment
o container o container
o container with presence
o data model o data model
o data node o data node
o feature o feature
o leaf o leaf
o list o list
o mandatory node o mandatory node
o module o module
o presence container
o schema tree o schema tree
o RPC (Remote Procedure Call) operation o RPC (Remote Procedure Call) operation
2.1. Glossary of New Terms 2.1. Glossary of New Terms
core routing data model: YANG data model comprising "ietf-routing", core routing data model: YANG data model comprising "ietf-routing",
"ietf-ipv4-unicast-routing", and "ietf-ipv6-unicast-routing" "ietf-ipv4-unicast-routing", and "ietf-ipv6-unicast-routing"
modules. modules.
direct route: a route to a directly connected network. direct route: A route to a directly connected network.
Routing Information Base (RIB): An object containing a list of Routing Information Base (RIB): An object containing a list of
routes together with other information. See Section 5.2 for routes, together with other information. See Section 5.2 for
details. details.
system-controlled entry: An entry of a list in operational state system-controlled entry: An entry in a list in the operational state
("config false") that is created by the system independently of ("config false") that is created by the system independently of
what has been explicitly configured. See Section 4.1 for details. what has been explicitly configured. See Section 4.1 for details.
user-controlled entry: An entry of a list in operational state user-controlled entry: An entry in a list in the operational state
("config false") that is created and deleted as a direct ("config false") that is created and deleted as a direct
consequence of certain configuration changes. See Section 4.1 for consequence of certain configuration changes. See Section 4.1 for
details. details.
2.2. Tree Diagrams 2.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[I-D.ietf-netmod-yang-tree-diagrams]. [RFC8340].
2.3. Prefixes in Data Node Names 2.3. Prefixes in Data Node Names
In this document, names of data nodes, actions, and other data model In this document, names of data nodes, actions, and other data model
objects are often used without a prefix, as long as it is clear from objects are often used without a prefix, as long as it is clear from
the context in which YANG module each name is defined. Otherwise, the context in which YANG module each name is defined. Otherwise,
names are prefixed using the standard prefix associated with the names are prefixed using the standard prefix associated with the
corresponding YANG module, as shown in Table 1. corresponding YANG module, as shown in Table 1.
+--------+---------------------------+------------------------------+ +--------+---------------------------+-----------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+--------+---------------------------+------------------------------+ +--------+---------------------------+-----------+
| if | ietf-interfaces | [I-D.ietf-netmod-rfc7223bis] | | if | ietf-interfaces | [RFC8343] |
| ip | ietf-ip | [I-D.ietf-netmod-rfc7277bis] | | ip | ietf-ip | [RFC8344] |
| rt | ietf-routing | Section 7 | | rt | ietf-routing | Section 7 |
| v4ur | ietf-ipv4-unicast-routing | Section 8 | | v4ur | ietf-ipv4-unicast-routing | Section 8 |
| v6ur | ietf-ipv6-unicast-routing | Section 9 | | v6ur | ietf-ipv6-unicast-routing | Section 9 |
| yang | ietf-yang-types | [RFC6991] | | yang | ietf-yang-types | [RFC6991] |
| inet | ietf-inet-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] |
+--------+---------------------------+------------------------------+ +--------+---------------------------+-----------+
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
routing, as well as Multiprotocol Label Switching (MPLS). routing, as well as Multiprotocol Label Switching (MPLS).
o A simple IP routing system, such as one that uses only static o A simple IP routing system, such as one that uses only static
routing, should be configurable in a simple way, ideally without routing, should be configurable in a simple way, ideally without
any need to develop additional YANG modules. any need to develop additional YANG modules.
o On the other hand, the core routing framework must allow for o On the other hand, the core routing framework must allow for
complicated implementations involving multiple Routing Information complicated implementations involving multiple RIBs and multiple
Bases (RIBs) and multiple control-plane protocols, as well as control-plane protocols, as well as controlled redistributions of
controlled redistributions of routing information. routing information.
o Because device vendors will want to map the data models built on o Because device vendors will want to map the data models built on
this generic framework to their proprietary data models and this generic framework to their proprietary data models and
configuration interfaces, the framework should be flexible enough configuration interfaces, the framework should be flexible enough
to facilitate that and accommodate data models with different to facilitate such mapping and accommodate data models with
logic. 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 and one The core routing data model consists of three YANG modules and one
submodule. The first module, "ietf-routing", defines the generic submodule. The first module, "ietf-routing", defines the generic
components of a routing system. The other two modules, "ietf-ipv4- components of a routing system. The other two modules --
unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" --
routing" module with additional data nodes that are needed for IPv4 augment the "ietf-routing" module with additional data nodes that are
and IPv6 unicast routing, respectively. The "ietf-ipv6-unicast- needed for IPv4 and IPv6 unicast routing, respectively. The
routing" module has a submodule, "ietf-ipv6-router-advertisements", "ietf-ipv6-unicast-routing" module has a submodule,
that augments the "ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and "ietf-ipv6-router-advertisements", that augments the
"ietf-ip" [I-D.ietf-netmod-rfc7277bis] modules with configuration "ietf-interfaces" [RFC8343] and "ietf-ip" [RFC8344] modules with
variables for IPv6 router advertisements as required by [RFC4861]. configuration variables for IPv6 Router Advertisements as required by
[RFC4861].
Figure 1 shows abridged views of the hierarchies. See Appendix A Figure 1 shows abridged views of the hierarchies. See Appendix A for
for the complete data trees. the complete data trees.
+--rw routing +--rw routing
+--rw router-id? yang:dotted-quad +--rw router-id? yang:dotted-quad
+--ro interfaces +--ro interfaces
| +--ro interface* if:interface-ref | +--ro interface* if:interface-ref
+--rw control-plane-protocols +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name] | +--rw control-plane-protocol* [type name]
| +--rw type identityref | +--rw type identityref
| +--rw name string | +--rw name string
| +--rw description? string | +--rw description? string
skipping to change at page 7, line 49 skipping to change at page 9, line 5
containing lists of routes, and control-plane protocols. Section 5 containing lists of routes, and control-plane protocols. Section 5
describes these components in more detail. describes these components in more detail.
4.1. System-Controlled and User-Controlled List Entries 4.1. System-Controlled and User-Controlled List Entries
The core routing data model defines several lists in the schema tree, The core routing data model defines several lists in the schema tree,
such as "rib", that have to be populated with at least one entry in such as "rib", that have to be populated with at least one entry in
any properly functioning device, and additional entries may be any properly functioning device, and additional entries may be
configured by a client. configured by a client.
In such a list, the server creates the required item as a so-called In such a list, the server creates the required item as a
system-controlled entry in the operational state, i.e., inside read- "system-controlled entry" in the operational state, i.e., inside
only lists in the "routing" container. read-only lists in the "routing" container.
An example can be seen in Appendix D: the "/routing/ribs/rib" list An example can be seen in Appendix D: the "/routing/ribs/rib" list
has two system-controlled entries named "ipv4-master" and has two system-controlled entries -- "ipv4-master" and "ipv6-master".
"ipv6-master".
Additional entries may be created in the configuration by a client, Additional entries called "user-controlled entries" may be created in
e.g., via the NETCONF protocol. These are so-called user-controlled the configuration by a client, e.g., via the Network Configuration
entries. If the server accepts a configured user-controlled entry, Protocol (NETCONF). If the server accepts a configured
then this entry also appears in the operational state version of the user-controlled entry, then this entry also appears in the
list. operational state version of the list.
Corresponding entries in both versions of the list (in the intended Corresponding entries in both versions of the list (in the intended
configuration and the operational state) configuration and the operational state) [RFC8342] have the same
[I-D.ietf-netmod-revised-datastores] have the same value of the list value of the list key.
key.
A client may also provide supplemental configuration of system- A client may also provide supplemental configuration of system-
controlled entries. To do so, the client creates a new entry in the controlled entries. To do so, the client creates a new entry in the
configuration with the desired contents. In order to bind this entry configuration with the desired contents. In order to bind this entry
to the corresponding entry in the operational state, the key of the to the corresponding entry in the operational state, the key of the
configuration entry has to be set to the same value as the key of the configuration entry has to be set to the same value as the key of the
operational state entry. operational state entry.
Deleting a user-controlled entry from the intended configuration Deleting a user-controlled entry from the intended configuration
results in the removal of the corresponding entry in the operational results in the removal of the corresponding entry in the operational
state list. In contrast, if client deletes a system-controlled entry state list. In contrast, if a client deletes a system-controlled
from the intended configuration, only the extra configuration entry from the intended configuration, only the extra configuration
specified in that entry is removed but the corresponding operational specified in that entry is removed; the corresponding operational
state entry is not removed. state entry is not removed.
5. Basic Building Blocks 5. Basic Building Blocks
This section describes the essential components of the core routing This section describes the essential components of the core routing
data model. data model.
5.1. Route 5.1. Routes
Routes are basic elements of information in a routing system. The Routes are basic elements of information in a routing system. The
core routing data model defines only the following minimal set of core routing data model defines only the following minimal set of
route attributes: route attributes:
o "destination-prefix": address prefix specifying the set of o "destination-prefix": address prefix specifying the set of
destination addresses for which the route may be used. This destination addresses for which the route may be used. This
attribute is mandatory. attribute is mandatory.
o "route-preference": an integer value (also known as administrative o "route-preference": an integer value (also known as
distance) that is used for selecting a preferred route among "administrative distance") that is used for selecting a preferred
routes with the same destination prefix. A lower value means a route among routes with the same destination prefix. A lower
more preferred route. value indicates a route that is more preferred.
o "next-hop": determines the outgoing interface and/or next-hop o "next-hop": determines the outgoing interface and/or next-hop
address(es), or a special operation to be performed with a packet. address(es), or a special operation to be performed on a packet.
Routes are primarily system state that appear as entries of RIBs Routes are primarily system state and appear as entries in RIBs
(Section 5.2) but they may also be found in configuration data, for (Section 5.2), but they may also be found in configuration data --
example, as manually configured static routes. In the latter case, for example, as manually configured static routes. In the latter
configurable route attributes are generally a subset of attributes case, configurable route attributes are generally a subset of
defined for RIB routes. attributes defined for RIB routes.
5.2. Routing Information Base (RIB) 5.2. Routing Information Base (RIB)
Every implementation of the core routing data model manages one or Every implementation of the core routing data model manages one or
more Routing Information Bases (RIBs). A RIB is a list of routes more RIBs. A RIB is a list of routes complemented with
complemented with administrative data. Each RIB contains only routes administrative data. Each RIB contains only routes of one address
of one address family. An address family is represented by an family. An address family is represented by an identity derived from
identity derived from the "rt:address-family" base identity. the "rt:address-family" base identity.
In the core routing data model, RIBs are represented as entries of In the core routing data model, RIBs are represented as entries in
the list "/routing/ribs/rib" in the operational state. The contents the list "/routing/ribs/rib" in the operational state. The contents
of RIBs are controlled and manipulated by control-plane protocol of RIBs are controlled and manipulated by control-plane protocol
operations that may result in route additions, removals, and operations that may result in route additions, removals, and
modifications. This also includes manipulations via the "static" modifications. This also includes manipulations via the "static"
and/or "direct" pseudo-protocols; see Section 5.3.1. and/or "direct" pseudo-protocols; see Section 5.3.1.
For every supported address family, exactly one RIB MUST be marked as For every supported address family, exactly one RIB MUST be marked as
the so-called default RIB to which control-plane protocols place the "default RIB", in which control-plane protocols place their
their routes by default. routes by default.
Simple router implementations that do not advertise the feature Simple router implementations that do not advertise the
"multiple-ribs" will typically create one system-controlled RIB per "multiple-ribs" feature will typically create one system-controlled
supported address family and mark it as the default RIB. RIB per supported address family and mark it as the default RIB.
More-complex router implementations advertising the "multiple-ribs" More-complex router implementations advertising the "multiple-ribs"
feature support multiple RIBs per address family that can be used for feature support multiple RIBs per address family that can be used for
policy routing and other purposes. policy routing and other purposes.
The following action (see Section 7.15 of [RFC7950]) is defined for The following action (see Section 7.15 of [RFC7950]) is defined for
the "rib" list: the "rib" list:
o active-route -- return the active RIB route for the destination o active-route -- return the active RIB route for the destination
address that is specified as the action's input parameter. address that is specified as the action's input parameter.
5.3. Control-Plane Protocol 5.3. Control-Plane Protocol
The core routing data model provides an open-ended framework for The core routing data model provides an open-ended framework for
defining multiple control-plane protocol instances, e.g., for Layer 3 defining multiple control-plane protocol instances, e.g., for Layer 3
routing protocols. Each control-plane protocol instance MUST be routing protocols. Each control-plane protocol instance MUST be
assigned a type, which is an identity derived from the assigned a type, which is an identity derived from the
"rt:control-plane-protocol" base identity. The core routing data "rt:control-plane-protocol" base identity. The core routing data
model defines two identities for the direct and static pseudo- model defines two identities for the "direct" and "static"
protocols (Section 5.3.1). pseudo-protocols (Section 5.3.1).
Multiple control-plane protocol instances of the same type MAY be Multiple control-plane protocol instances of the same type MAY be
configured. configured.
5.3.1. Routing Pseudo-Protocols 5.3.1. Routing Pseudo-Protocols
The core routing data model defines two special routing protocol The core routing data model defines two special routing protocol
types -- "direct" and "static". Both are in fact pseudo-protocols, types -- "direct" and "static". Both are in fact pseudo-protocols,
which means that they are confined to the local device and do not which means that they are confined to the local device and do not
exchange any routing information with adjacent routers. exchange any routing information with adjacent routers.
skipping to change at page 10, line 31 skipping to change at page 11, line 38
routes are normally supplied by the operating system kernel, based on routes are normally supplied by the operating system kernel, based on
the configuration of network interface addresses; see Section 6.2. the configuration of network interface addresses; see Section 6.2.
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 configuration will have exactly one instance. although a typical configuration will have exactly one instance.
5.3.2. Defining New Control-Plane Protocols 5.3.2. Defining New Control-Plane 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 control-plane protocol types. Such a new module has to additional control-plane protocol types. Such new modules will have
define the protocol-specific data nodes, and it has to integrate into to define the protocol-specific data nodes, and they will have to
the core routing framework in the following way: integrate into the core routing framework in the following way:
o A new identity MUST be defined for the control-plane protocol, and o A new identity MUST be defined for the control-plane protocol, and
its base identity MUST be set to "rt:control-plane-protocol" or to its base identity MUST be set to "rt:control-plane-protocol" or to
an identity derived from "rt:control-plane-protocol". an identity derived from "rt:control-plane-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 by augmenting the definitions of the node have to be inserted by augmenting the definitions of the node
/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
skipping to change at page 11, line 13 skipping to change at page 12, line 27
new protocol SHOULD be made conditional and valid only if the value new protocol SHOULD be made conditional and valid only if the value
of "rt:type" or "rt:source-protocol" is equal to (or derived from) of "rt:type" or "rt:source-protocol" is equal to (or derived from)
the new protocol's identity. the new protocol's identity.
It is also RECOMMENDED that protocol-specific data nodes be It is also RECOMMENDED that protocol-specific data nodes be
encapsulated in an appropriately named container with presence. Such encapsulated in an appropriately named container with presence. Such
a container may contain mandatory data nodes that are otherwise a container may contain mandatory data nodes that are otherwise
forbidden at the top level of an augment. forbidden at the top level of an augment.
The above steps are implemented by the example YANG module for the The above steps are implemented by the example YANG module for the
Routing Information Protocol (RIP) in Appendix C. Routing Information Protocol (RIP); see Appendix C.
5.4. Parameters of IPv6 Router Advertisements 5.4. Parameters of IPv6 Router Advertisements
YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is The YANG module "ietf-ipv6-router-advertisements" (Section 9.1),
a submodule of the "ietf-ipv6-unicast-routing" module, augments the which is a submodule of the "ietf-ipv6-unicast-routing" module,
schema tree of IPv6 interfaces with definitions of the following augments the schema tree of IPv6 interfaces with definitions of the
variables as required by Section 6.2.1 of [RFC4861]: following variables as required by Section 6.2.1 of [RFC4861]:
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
skipping to change at page 11, line 39 skipping to change at page 13, line 4
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. o prefix-list: a list of prefixes to be advertised.
The following parameters are associated with each prefix in the The following parameters are associated with each prefix in
list: the list:
* valid-lifetime * valid-lifetime
* on-link-flag * on-link-flag
* preferred-lifetime * preferred-lifetime
* autonomous-flag * autonomous-flag
NOTES: NOTES:
1. The "IsRouter" flag, which is also required by [RFC4861], is 1. The "IsRouter" flag, which is also required by [RFC4861], is
implemented in the "ietf-ip" module [I-D.ietf-netmod-rfc7277bis] implemented in the "ietf-ip" module [RFC8344] (leaf
(leaf "ip:forwarding"). "ip:forwarding").
2. The original specification [RFC4861] allows the implementations 2. The Neighbor Discovery specification [RFC4861] allows the
to decide whether the "valid-lifetime" and "preferred-lifetime" implementations to decide whether the "valid-lifetime" and
parameters remain the same in consecutive advertisements or "preferred-lifetime" parameters remain the same in consecutive
decrement in real time. However, the latter behavior seems advertisements or decrement in real time. However, the latter
problematic because the values might be reset again to the behavior seems problematic because the values might be reset
(higher) configured values after a configuration is reloaded. again to the (higher) configured values after a configuration is
Moreover, no implementation is known to use the decrementing reloaded. Moreover, no implementation is known to use the
behavior. The "ietf-ipv6-router-advertisements" submodule decrementing behavior. The "ietf-ipv6-router-advertisements"
therefore stipulates the former behavior with constant values. submodule therefore stipulates the former behavior with constant
values.
6. Interactions with Other YANG Modules 6. 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 depends on several
configuration parameters that are defined in other YANG modules. configuration parameters that are defined in other YANG modules.
6.1. Module "ietf-interfaces" 6.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 [I-D.ietf-netmod-rfc7223bis]: module [RFC8343]:
/if:interfaces/if:interface/if:enabled /if:interfaces/if:interface/if:enabled
If this switch is set to "false" for a network-layer interface, If this switch is set to "false" for a network-layer interface,
then all routing and forwarding functions MUST be disabled on this then all routing and forwarding functions MUST be disabled on this
interface. interface.
6.2. Module "ietf-ip" 6.2. Module "ietf-ip"
The following boolean switches are defined in the "ietf-ip" YANG The following boolean switches are defined in the "ietf-ip" YANG
module [I-D.ietf-netmod-rfc7277bis]: module [RFC8344]:
/if:interfaces/if:interface/ip:ipv4/ip:enabled /if:interfaces/if:interface/ip:ipv4/ip:enabled
If this switch is set to "false" for a network-layer interface, If this switch is set to "false" for a network-layer interface,
then all IPv4 routing and forwarding functions MUST be disabled on then all IPv4 routing and forwarding functions MUST be disabled on
this interface. this interface.
/if:interfaces/if:interface/ip:ipv4/ip:forwarding /if:interfaces/if:interface/ip:ipv4/ip:forwarding
If this switch is set to "false" for a network-layer interface, If this switch is set to "false" for a network-layer interface,
then the forwarding of IPv4 datagrams through this interface MUST then the forwarding of IPv4 datagrams through this interface MUST
be disabled. However, the interface MAY participate in other IPv4 be disabled. However, the interface MAY participate in other IPv4
routing functions, such as routing protocols. routing functions, such as routing protocols.
/if:interfaces/if:interface/ip:ipv6/ip:enabled /if:interfaces/if:interface/ip:ipv6/ip:enabled
If this switch is set to "false" for a network-layer interface, If this switch is set to "false" for a network-layer interface,
then all IPv6 routing and forwarding functions MUST be disabled on then all IPv6 routing and forwarding functions MUST be disabled on
this interface. this interface.
skipping to change at page 13, line 32 skipping to change at page 15, line 7
In addition, the "ietf-ip" module allows for configuring IPv4 and In addition, the "ietf-ip" module allows for configuring IPv4 and
IPv6 addresses and network prefixes or masks on network-layer IPv6 addresses and network prefixes or masks on network-layer
interfaces. Configuration of these parameters on an enabled interfaces. Configuration of these parameters on an enabled
interface MUST result in an immediate creation of the corresponding interface MUST result in an immediate creation of the corresponding
direct route. The destination prefix of this route is set according direct route. The destination prefix of this route is set according
to the configured IP address and network prefix/mask, and the to the configured IP address and network prefix/mask, and the
interface is set as the outgoing interface for that route. interface is set as the outgoing interface for that route.
7. Routing Management YANG Module 7. Routing Management YANG Module
<CODE BEGINS> file "ietf-routing@2018-01-25.yang" <CODE BEGINS> file "ietf-routing@2018-03-13.yang"
module ietf-routing { module ietf-routing {
yang-version "1.1"; yang-version "1.1";
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-yang-types {
prefix "yang"; prefix "yang";
} }
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix "if";
description description
"A Network Management Datastore Architecture (NMDA) "An 'ietf-interfaces' module version that is compatible with
compatible version of the ietf-interfaces module the Network Management Datastore Architecture (NMDA)
is required."; is required.";
} }
organization organization
"IETF NETMOD - Networking Modeling Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:rtgwg@ietf.org> WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz> <mailto:lhotka@nic.cz>
Acee Lindem Acee Lindem
<mailto:acee@cisco.com> <mailto:acee@cisco.com>
Yingzhen Qu Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>"; <mailto:yingzhen.qu@huawei.com>";
description description
"This YANG module defines essential components for the management "This YANG module defines essential components for the management
of a routing subsystem. The model fully conforms to the Network of a routing subsystem. The model fully conforms to the Network
Management Datastore Architecture (NMDA). Management Datastore Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2018 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as 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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set 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). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8349; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC XXXX";
revision 2018-01-25 { revision 2018-03-13 {
description description
"Network Management Datastore Architecture (NMDA) Revision"; "Network Management Datastore Architecture (NMDA) revision.";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)"; (NMDA Version)";
} }
revision 2016-11-04 { revision 2016-11-04 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8022: A YANG Data Model for Routing Management"; "RFC 8022: A YANG Data Model for Routing Management";
} }
/* Features */ /* Features */
feature multiple-ribs { feature multiple-ribs {
description description
"This feature indicates that the server supports user-defined "This feature indicates that the server supports
RIBs. user-defined RIBs.
Servers that do not advertise this feature SHOULD provide Servers that do not advertise this feature SHOULD provide
exactly one system-controlled RIB per supported address family exactly one system-controlled RIB per supported address family
and make it also the default RIB. This RIB then appears as an and also make it the default RIB. This RIB then appears as an
entry of the list /routing/ribs/rib."; entry in the list '/routing/ribs/rib'.";
} }
feature router-id { feature router-id {
description description
"This feature indicates that the server supports of an explicit "This feature indicates that the server supports an explicit
32-bit router ID that is used by some routing protocols. 32-bit router ID that is used by some routing protocols.
Servers that do not advertise this feature set a router ID Servers that do not advertise this feature set a router ID
algorithmically, usually to one of the configured IPv4 algorithmically, usually to one of the configured IPv4
addresses. However, this algorithm is implementation addresses. However, this algorithm is implementation
specific."; specific.";
} }
/* Identities */ /* Identities */
skipping to change at page 15, line 31 skipping to change at page 17, line 4
specific."; specific.";
} }
/* Identities */ /* Identities */
identity address-family { identity address-family {
description description
"Base identity from which identities describing address "Base identity from which identities describing address
families are derived."; families are derived.";
} }
identity ipv4 { identity ipv4 {
base address-family; base address-family;
description description
"This identity represents IPv4 address family."; "This identity represents an IPv4 address family.";
} }
identity ipv6 { identity ipv6 {
base address-family; base address-family;
description description
"This identity represents IPv6 address family."; "This identity represents an IPv6 address family.";
} }
identity control-plane-protocol { identity control-plane-protocol {
description description
"Base identity from which control-plane protocol identities are "Base identity from which control-plane protocol identities are
derived."; derived.";
} }
identity routing-protocol { identity routing-protocol {
base control-plane-protocol; base control-plane-protocol;
skipping to change at page 16, line 19 skipping to change at page 17, line 39
identity direct { identity direct {
base routing-protocol; base routing-protocol;
description description
"Routing pseudo-protocol that provides routes to directly "Routing pseudo-protocol that provides routes to directly
connected networks."; connected networks.";
} }
identity static { identity static {
base routing-protocol; base routing-protocol;
description description
"Static routing pseudo-protocol."; "'Static' routing pseudo-protocol.";
} }
/* Type Definitions */ /* Type Definitions */
typedef route-preference { typedef route-preference {
type uint32; type uint32;
description description
"This type is used for route preferences."; "This type is used for route preferences.";
} }
skipping to change at page 16, line 31 skipping to change at page 18, line 4
/* Type Definitions */ /* Type Definitions */
typedef route-preference { typedef route-preference {
type uint32; type uint32;
description description
"This type is used for route preferences."; "This type is used for route preferences.";
} }
/* Groupings */ /* Groupings */
grouping address-family { grouping address-family {
description description
"This grouping provides a leaf identifying an address "This grouping provides a leaf identifying an address
family."; family.";
leaf address-family { leaf address-family {
type identityref { type identityref {
base address-family; base address-family;
} }
mandatory "true"; mandatory true;
description description
"Address family."; "Address family.";
} }
} }
grouping router-id { grouping router-id {
description description
"This grouping provides router ID."; "This grouping provides a router ID.";
leaf router-id { leaf router-id {
type yang:dotted-quad; type yang:dotted-quad;
description description
"A 32-bit number in the form of a dotted quad that is used by "A 32-bit number in the form of a dotted quad that is used by
some routing protocols identifying a router."; some routing protocols identifying a router.";
reference reference
"RFC 2328: OSPF Version 2."; "RFC 2328: OSPF Version 2";
} }
} }
grouping special-next-hop { grouping special-next-hop {
description description
"This grouping provides a leaf with an enumeration of special "This grouping provides a leaf with an enumeration of special
next hops."; next hops.";
leaf special-next-hop { leaf special-next-hop {
type enumeration { type enumeration {
enum blackhole { enum blackhole {
skipping to change at page 17, line 47 skipping to change at page 19, line 20
} }
description description
"Options for special next hops."; "Options for special next hops.";
} }
} }
grouping next-hop-content { grouping next-hop-content {
description description
"Generic parameters of next hops in static routes."; "Generic parameters of next hops in static routes.";
choice next-hop-options { choice next-hop-options {
mandatory "true"; mandatory true;
description description
"Options for next hops in static routes. "Options for next hops in static routes.
It is expected that further cases will be added through It is expected that further cases will be added through
augments from other modules."; augments from other modules.";
case simple-next-hop { case simple-next-hop {
description description
"This case represents a simple next hop consisting of the "This case represents a simple next hop consisting of the
next-hop address and/or outgoing interface. next-hop address and/or outgoing interface.
skipping to change at page 18, line 25 skipping to change at page 19, line 46
description description
"Name of the outgoing interface."; "Name of the outgoing interface.";
} }
} }
case special-next-hop { case special-next-hop {
uses special-next-hop; uses special-next-hop;
} }
case next-hop-list { case next-hop-list {
container next-hop-list { container next-hop-list {
description description
"Container for multiple next-hops."; "Container for multiple next hops.";
list next-hop { list next-hop {
key "index"; key "index";
description description
"An entry of a next-hop list. "An entry in a next-hop list.
Modules for address families MUST augment this list Modules for address families MUST augment this list
with a leaf containing a next-hop address of that with a leaf containing a next-hop address of that
address family."; address family.";
leaf index { leaf index {
type string; type string;
description description
"A user-specified identifier utilized to uniquely "A user-specified identifier utilized to uniquely
reference the next-hop entry in the next-hop list. reference the next-hop entry in the next-hop list.
The value of this index has no semantic meaning The value of this index has no semantic meaning
skipping to change at page 19, line 4 skipping to change at page 20, line 24
leaf outgoing-interface { leaf outgoing-interface {
type if:interface-ref; type if:interface-ref;
description description
"Name of the outgoing interface."; "Name of the outgoing interface.";
} }
} }
} }
} }
} }
} }
grouping next-hop-state-content { grouping next-hop-state-content {
description description
"Generic state parameters of next hops."; "Generic state parameters of next hops.";
choice next-hop-options { choice next-hop-options {
mandatory "true"; mandatory true;
description description
"Options for next hops. "Options for next hops.
It is expected that further cases will be added through It is expected that further cases will be added through
augments from other modules, e.g., for recursive augments from other modules, e.g., for recursive
next hops."; next hops.";
case simple-next-hop { case simple-next-hop {
description description
"This case represents a simple next hop consisting of the "This case represents a simple next hop consisting of the
next-hop address and/or outgoing interface. next-hop address and/or outgoing interface.
skipping to change at page 19, line 31 skipping to change at page 21, line 4
leaf containing a next-hop address of that address leaf containing a next-hop address of that address
family."; family.";
leaf outgoing-interface { leaf outgoing-interface {
type if:interface-ref; type if:interface-ref;
description description
"Name of the outgoing interface."; "Name of the outgoing interface.";
} }
} }
case special-next-hop { case special-next-hop {
uses special-next-hop; uses special-next-hop;
} }
case next-hop-list { case next-hop-list {
container next-hop-list { container next-hop-list {
description description
"Container for multiple next hops."; "Container for multiple next hops.";
list next-hop { list next-hop {
description description
"An entry of a next-hop list. "An entry in a next-hop list.
Modules for address families MUST augment this list Modules for address families MUST augment this list
with a leaf containing a next-hop address of that with a leaf containing a next-hop address of that
address family."; address family.";
leaf outgoing-interface { leaf outgoing-interface {
type if:interface-ref; type if:interface-ref;
description description
"Name of the outgoing interface."; "Name of the outgoing interface.";
} }
} }
skipping to change at page 20, line 4 skipping to change at page 21, line 26
address family."; address family.";
leaf outgoing-interface { leaf outgoing-interface {
type if:interface-ref; type if:interface-ref;
description description
"Name of the outgoing interface."; "Name of the outgoing interface.";
} }
} }
} }
} }
} }
} }
grouping route-metadata { grouping route-metadata {
description description
"Common route metadata."; "Common route metadata.";
leaf source-protocol { leaf source-protocol {
type identityref { type identityref {
base routing-protocol; base routing-protocol;
} }
mandatory "true"; mandatory true;
description description
"Type of the routing protocol from which the route "Type of the routing protocol from which the route
originated."; originated.";
} }
leaf active { leaf active {
type empty; type empty;
description description
"Presence of this leaf indicates that the route is preferred "The presence of this leaf indicates that the route is
among all routes in the same RIB that have the same preferred among all routes in the same RIB that have the
destination prefix."; same destination prefix.";
} }
leaf last-updated { leaf last-updated {
type yang:date-and-time; type yang:date-and-time;
description description
"Time stamp of the last modification of the route. If the "Timestamp of the last modification of the route. If the
route was never modified, it is the time when the route was route was never modified, it is the time when the route was
inserted into the RIB."; inserted into the RIB.";
} }
} }
/* Data nodes */ /* Data nodes */
container routing { container routing {
description description
"Configuration parameters for the routing subsystem."; "Configuration parameters for the routing subsystem.";
uses router-id { uses router-id {
if-feature "router-id"; if-feature "router-id";
skipping to change at page 20, line 44 skipping to change at page 22, line 17
/* Data nodes */ /* Data nodes */
container routing { container routing {
description description
"Configuration parameters for the routing subsystem."; "Configuration parameters for the routing subsystem.";
uses router-id { uses router-id {
if-feature "router-id"; if-feature "router-id";
description description
"Support for the global router ID. Routing protocols "Support for the global router ID. Routing protocols
that use router ID can use this parameter or override it that use a router ID can use this parameter or override it
with another value."; with another value.";
} }
container interfaces { container interfaces {
config "false"; config false;
description description
"Network-layer interfaces used for routing."; "Network-layer interfaces used for routing.";
leaf-list interface { leaf-list interface {
type if:interface-ref; type if:interface-ref;
description description
"Each entry is a reference to the name of a configured "Each entry is a reference to the name of a configured
network-layer interface."; network-layer interface.";
} }
} }
container control-plane-protocols { container control-plane-protocols {
skipping to change at page 21, line 21 skipping to change at page 22, line 43
"Support for control-plane protocol instances."; "Support for control-plane protocol instances.";
list control-plane-protocol { list control-plane-protocol {
key "type name"; key "type name";
description description
"Each entry contains a control-plane protocol instance."; "Each entry contains a control-plane protocol instance.";
leaf type { leaf type {
type identityref { type identityref {
base control-plane-protocol; base control-plane-protocol;
} }
description description
"Type of the control-plane protocol - an identity derived "Type of the control-plane protocol -- an identity
from the 'control-plane-protocol' base identity."; derived from the 'control-plane-protocol'
base identity.";
} }
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name of the control-plane protocol "An arbitrary name of the control-plane protocol
instance."; instance.";
} }
leaf description { leaf description {
type string; type string;
description description
skipping to change at page 22, line 8 skipping to change at page 23, line 30
their lists of routes."; their lists of routes.";
} }
} }
} }
container ribs { container ribs {
description description
"Support for RIBs."; "Support for RIBs.";
list rib { list rib {
key "name"; key "name";
description description
"Each entry contains configuration for a RIB identified by "Each entry contains a configuration for a RIB identified
the 'name' key. by the 'name' key.
Entries having the same key as a system-controlled entry Entries having the same key as a system-controlled entry
of the list /routing/ribs/rib are used for in the list '/routing/ribs/rib' are used for
configuring parameters of that entry. Other entries configuring parameters of that entry. Other entries
define additional user-controlled RIBs."; define additional user-controlled RIBs.";
leaf name { leaf name {
type string; type string;
description description
"The name of the RIB. "The name of the RIB.
For system-controlled entries, the value of this leaf For system-controlled entries, the value of this leaf
must be the same as the name of the corresponding entry must be the same as the name of the corresponding entry
in operational state. in the operational state.
For user-controlled entries, an arbitrary name can be For user-controlled entries, an arbitrary name can be
used."; used.";
} }
uses address-family { uses address-family {
description description
"The address family of the system-controlled RIB."; "The address family of the system-controlled RIB.";
} }
leaf default-rib { leaf default-rib {
if-feature "multiple-ribs"; if-feature "multiple-ribs";
type boolean; type boolean;
default "true"; default "true";
config "false"; config false;
description description
"This flag has the value of 'true' if and only if the RIB "This flag has the value of 'true' if and only if the RIB
is the default RIB for the given address family. is the default RIB for the given address family.
By default, control-plane protocols place their routes By default, control-plane protocols place their routes
in the default RIBs."; in the default RIBs.";
} }
container routes { container routes {
config "false"; config false;
description description
"Current content of the RIB."; "Current contents of the RIB.";
list route { list route {
description description
"A RIB route entry. This data node MUST be augmented "A RIB route entry. This data node MUST be augmented
with information specific for routes of each address with information specific to routes of each address
family."; family.";
leaf route-preference { leaf route-preference {
type route-preference; type route-preference;
description description
"This route attribute, also known as administrative "This route attribute, also known as 'administrative
distance, allows for selecting the preferred route distance', allows for selecting the preferred route
among routes with the same destination prefix. A among routes with the same destination prefix. A
smaller value means a more preferred route."; smaller value indicates a route that is
more preferred.";
} }
container next-hop { container next-hop {
description description
"Route's next-hop attribute."; "Route's next-hop attribute.";
uses next-hop-state-content; uses next-hop-state-content;
} }
uses route-metadata; uses route-metadata;
} }
} }
action active-route { action active-route {
skipping to change at page 24, line 4 skipping to change at page 25, line 27
} }
uses route-metadata; uses route-metadata;
} }
} }
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the RIB."; "Textual description of the RIB.";
} }
} }
} }
} }
/* /*
* The subsequent data nodes are obviated and obsoleted by the * The subsequent data nodes are obviated and obsoleted
* "Network Management Architecture" as described in * by the Network Management Datastore Architecture
* draft-ietf-netmod-revised-datastores. * as described in RFC 8342.
*/ */
container routing-state { container routing-state {
config false; config false;
status obsolete; status obsolete;
description description
"State data of the routing subsystem."; "State data of the routing subsystem.";
uses router-id { uses router-id {
status obsolete; status obsolete;
description description
"Global router ID. "Global router ID.
skipping to change at page 25, line 19 skipping to change at page 26, line 41
status obsolete; status obsolete;
description description
"Type of the control-plane protocol."; "Type of the control-plane protocol.";
} }
leaf name { leaf name {
type string; type string;
status obsolete; status obsolete;
description description
"The name of the control-plane protocol instance. "The name of the control-plane protocol instance.
For system-controlled instances this name is For system-controlled instances, this name is
persistent, i.e., it SHOULD NOT change across persistent, i.e., it SHOULD NOT change across
reboots."; reboots.";
} }
} }
} }
container ribs { container ribs {
status obsolete; status obsolete;
description description
"Container for RIBs."; "Container for RIBs.";
list rib { list rib {
key "name"; key "name";
min-elements 1; min-elements 1;
status obsolete; status obsolete;
description description
"Each entry represents a RIB identified by the 'name' "Each entry represents a RIB identified by the 'name'
key. All routes in a RIB MUST belong to the same address key. All routes in a RIB MUST belong to the same address
family. family.
An implementation SHOULD provide one system-controlled An implementation SHOULD provide one system-controlled
default RIB for each supported address family."; default RIB for each supported address family.";
leaf name { leaf name {
type string; type string;
status obsolete; status obsolete;
description description
"The name of the RIB."; "The name of the RIB.";
} }
skipping to change at page 26, line 17 skipping to change at page 27, line 40
description description
"This flag has the value of 'true' if and only if the "This flag has the value of 'true' if and only if the
RIB is the default RIB for the given address family. RIB is the default RIB for the given address family.
By default, control-plane protocols place their routes By default, control-plane protocols place their routes
in the default RIBs."; in the default RIBs.";
} }
container routes { container routes {
status obsolete; status obsolete;
description description
"Current content of the RIB."; "Current contents of the RIB.";
list route { list route {
status obsolete; status obsolete;
description description
"A RIB route entry. This data node MUST be augmented "A RIB route entry. This data node MUST be augmented
with information specific for routes of each address with information specific to routes of each address
family."; family.";
leaf route-preference { leaf route-preference {
type route-preference; type route-preference;
status obsolete; status obsolete;
description description
"This route attribute, also known as administrative "This route attribute, also known as 'administrative
distance, allows for selecting the preferred route distance', allows for selecting the preferred route
among routes with the same destination prefix. A among routes with the same destination prefix. A
smaller value means a more preferred route."; smaller value indicates a route that is
more preferred.";
} }
container next-hop { container next-hop {
status obsolete; status obsolete;
description description
"Route's next-hop attribute."; "Route's next-hop attribute.";
uses next-hop-state-content { uses next-hop-state-content {
status obsolete; status obsolete;
description description
"Route's next-hop attribute operational state."; "Route's next-hop attribute operational state.";
} }
skipping to change at page 27, line 35 skipping to change at page 29, line 11
"Route's next-hop attribute."; "Route's next-hop attribute.";
uses next-hop-state-content { uses next-hop-state-content {
status obsolete; status obsolete;
description description
"Active route state data."; "Active route state data.";
} }
} }
uses route-metadata { uses route-metadata {
status obsolete; status obsolete;
description description
"Active route metadata."; "Active route metadata.";
} }
} }
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
8. IPv4 Unicast Routing Management YANG Module 8. IPv4 Unicast Routing Management YANG Module
<CODE BEGINS> file "ietf-ipv4-unicast-routing@2018-01-25.yang" <CODE BEGINS> file "ietf-ipv4-unicast-routing@2018-03-13.yang"
module ietf-ipv4-unicast-routing { module ietf-ipv4-unicast-routing {
yang-version "1.1"; yang-version "1.1";
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing";
prefix "v4ur"; prefix "v4ur";
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
description description
"A Network Management Datastore Architecture (NMDA) "An 'ietf-routing' module version that is compatible with
compatible version of the ietf-routing module the Network Management Datastore Architecture (NMDA)
is required."; is required.";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
organization organization
"IETF NETMOD - Networking Modeling Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:rtgwg@ietf.org> WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz> <mailto:lhotka@nic.cz>
Acee Lindem Acee Lindem
<mailto:acee@cisco.com> <mailto:acee@cisco.com>
Yingzhen Qu Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>"; <mailto:yingzhen.qu@huawei.com>";
description description
"This YANG module augments the 'ietf-routing' module with basic "This YANG module augments the 'ietf-routing' module with basic
parameters for IPv4 unicast routing. The model fully conforms parameters for IPv4 unicast routing. The model fully conforms
to the Network Management Datastore Architecture (NMDA). to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2018 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as 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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set 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). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8349; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC XXXX";
revision 2018-01-25 { revision 2018-03-13 {
description description
"Network Management Datastore Architecture (NMDA) Revision"; "Network Management Datastore Architecture (NMDA) revision.";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)"; (NMDA Version)";
} }
revision 2016-11-04 { revision 2016-11-04 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8022: A YANG Data Model for Routing Management"; "RFC 8022: A YANG Data Model for Routing Management";
} }
/* Identities */ /* Identities */
skipping to change at page 29, line 48 skipping to change at page 31, line 25
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
when "derived-from-or-self(../../../rt:address-family, " when "derived-from-or-self(../../../rt:address-family, "
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
description description
"Augment 'simple-next-hop' case in IPv4 unicast routes."; "Augments the 'simple-next-hop' case in IPv4 unicast routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+ "rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop" {
skipping to change at page 30, line 22 skipping to change at page 31, line 47
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
description description
"This leaf augments the 'next-hop-list' case of IPv4 unicast "This leaf augments the 'next-hop-list' case of IPv4 unicast
routes."; routes.";
leaf address { leaf address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next-hop."; "IPv4 address of the next hop.";
} }
} }
augment augment
"/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" {
when "derived-from-or-self(../rt:address-family, " when "derived-from-or-self(../rt:address-family, "
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast RIBs."; "This augment is valid only for IPv4 unicast RIBs.";
} }
skipping to change at page 31, line 21 skipping to change at page 32, line 46
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:simple-next-hop" { + "rt:simple-next-hop" {
when "derived-from-or-self(../../../rt:address-family, " when "derived-from-or-self(../../../rt:address-family, "
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
description description
"Augment 'simple-next-hop' case in the reply to the "Augments the 'simple-next-hop' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
when "derived-from-or-self(../../../../../rt:address-family, " when "derived-from-or-self(../../../../../rt:address-family, "
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
skipping to change at page 31, line 39 skipping to change at page 33, line 17
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
when "derived-from-or-self(../../../../../rt:address-family, " when "derived-from-or-self(../../../../../rt:address-family, "
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
description description
"Augment 'next-hop-list' case in the reply to the "Augments the 'next-hop-list' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:static-routes" { + "rt:control-plane-protocol/rt:static-routes" {
skipping to change at page 32, line 15 skipping to change at page 33, line 41
container ipv4 { container ipv4 {
description description
"Support for a 'static' pseudo-protocol instance "Support for a 'static' pseudo-protocol instance
consists of a list of routes."; consists of a list of routes.";
list route { list route {
key "destination-prefix"; key "destination-prefix";
description description
"A list of static routes."; "A list of static routes.";
leaf destination-prefix { leaf destination-prefix {
type inet:ipv4-prefix; type inet:ipv4-prefix;
mandatory "true"; mandatory true;
description description
"IPv4 destination prefix."; "IPv4 destination prefix.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route."; "Textual description of the route.";
} }
container next-hop { container next-hop {
description description
skipping to change at page 32, line 27 skipping to change at page 34, line 4
"IPv4 destination prefix."; "IPv4 destination prefix.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route."; "Textual description of the route.";
} }
container next-hop { container next-hop {
description description
"Support for next-hop."; "Support for next-hop.";
uses rt:next-hop-content { uses rt:next-hop-content {
augment "next-hop-options/simple-next-hop" { augment "next-hop-options/simple-next-hop" {
description description
"Augment 'simple-next-hop' case in IPv4 static "Augments the 'simple-next-hop' case in IPv4 static
routes."; routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
augment "next-hop-options/next-hop-list/next-hop-list/" augment "next-hop-options/next-hop-list/next-hop-list/"
+ "next-hop" { + "next-hop" {
description description
"Augment 'next-hop-list' case in IPv4 static "Augments the 'next-hop-list' case in IPv4 static
routes."; routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
} }
} }
} }
skipping to change at page 33, line 4 skipping to change at page 34, line 30
routes."; routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
} }
} }
} }
} }
} }
/* /*
* The subsequent data nodes are obviated and obsoleted by the * The subsequent data nodes are obviated and obsoleted
* "Network Management Architecture" as described in * by the Network Management Datastore Architecture
* draft-ietf-netmod-revised-datastores. * as described in RFC 8342.
*/ */
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
when "derived-from-or-self(../../rt:address-family, " when "derived-from-or-self(../../rt:address-family, "
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
status obsolete; status obsolete;
description description
"This leaf augments an IPv4 unicast route."; "This leaf augments an IPv4 unicast route.";
skipping to change at page 33, line 38 skipping to change at page 35, line 15
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
when "derived-from-or-self( when "derived-from-or-self(
../../../rt:address-family, 'v4ur:ipv4-unicast')" { ../../../rt:address-family, 'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
status obsolete; status obsolete;
description description
"Augment 'simple-next-hop' case in IPv4 unicast routes."; "Augments the 'simple-next-hop' case in IPv4 unicast routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
status obsolete; status obsolete;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+ "rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop" {
skipping to change at page 34, line 4 skipping to change at page 35, line 30
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+ "rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop" {
when "derived-from-or-self(../../../../../rt:address-family, when "derived-from-or-self(../../../../../rt:address-family,
'v4ur:ipv4-unicast')" { 'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
status obsolete; status obsolete;
description description
"This leaf augments the 'next-hop-list' case of IPv4 unicast "This leaf augments the 'next-hop-list' case of IPv4 unicast
routes."; routes.";
leaf address { leaf address {
type inet:ipv4-address; type inet:ipv4-address;
status obsolete; status obsolete;
description description
"IPv4 address of the next-hop."; "IPv4 address of the next hop.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+ "rt:input" { + "rt:input" {
when "derived-from-or-self(../rt:address-family, when "derived-from-or-self(../rt:address-family,
'v4ur:ipv4-unicast')" { 'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast RIBs."; "This augment is valid only for IPv4 unicast RIBs.";
} }
status obsolete; status obsolete;
description description
"This augment adds the input parameter of the 'active-route' "This augment adds the input parameter of the 'active-route'
action."; action.";
leaf destination-address { leaf destination-address {
type inet:ipv4-address; type inet:ipv4-address;
status obsolete; status obsolete;
description description
"IPv4 destination address."; "IPv4 destination address.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route" { + "rt:output/rt:route" {
when "derived-from-or-self(../../rt:address-family, when "derived-from-or-self(../../rt:address-family,
skipping to change at page 35, line 14 skipping to change at page 36, line 40
augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:simple-next-hop" { + "rt:simple-next-hop" {
when "derived-from-or-self(../../../rt:address-family, when "derived-from-or-self(../../../rt:address-family,
'v4ur:ipv4-unicast')" { 'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
status obsolete; status obsolete;
description description
"Augment 'simple-next-hop' case in the reply to the "Augments the 'simple-next-hop' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
status obsolete; status obsolete;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
when "derived-from-or-self(../../../../../rt:address-family, when "derived-from-or-self(../../../../../rt:address-family,
'v4ur:ipv4-unicast')" { 'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
status obsolete; status obsolete;
description description
"Augment 'next-hop-list' case in the reply to the "Augments the 'next-hop-list' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv4-address; type inet:ipv4-address;
status obsolete; status obsolete;
description description
"IPv4 address of the next hop."; "IPv4 address of the next hop.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
9. IPv6 Unicast Routing Management YANG Module 9. IPv6 Unicast Routing Management YANG Module
<CODE BEGINS> file "ietf-ipv6-unicast-routing@2018-01-25.yang" <CODE BEGINS> file "ietf-ipv6-unicast-routing@2018-03-13.yang"
module ietf-ipv6-unicast-routing { module ietf-ipv6-unicast-routing {
yang-version "1.1"; yang-version "1.1";
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing";
prefix "v6ur"; prefix "v6ur";
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
description description
"A Network Management Datastore Architecture (NMDA) "An 'ietf-routing' module version that is compatible with
compatible version of the ietf-routing module the Network Management Datastore Architecture (NMDA)
is required."; is required.";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
description description
"A Network Management Datastore Architecture (NMDA) "An 'ietf-interfaces' module version that is compatible with
compatible version of the ietf-interfaces module the Network Management Datastore Architecture (NMDA)
is required."; is required.";
} }
include ietf-ipv6-router-advertisements { include ietf-ipv6-router-advertisements {
revision-date 2018-01-25; revision-date 2018-03-13;
} }
organization organization
"IETF NETMOD - Networking Modeling Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:rtgwg@ietf.org> WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz> <mailto:lhotka@nic.cz>
Acee Lindem Acee Lindem
<mailto:acee@cisco.com> <mailto:acee@cisco.com>
Yingzhen Qu Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>"; <mailto:yingzhen.qu@huawei.com>";
description description
"This YANG module augments the 'ietf-routing' module with basic "This YANG module augments the 'ietf-routing' module with basic
parameters for IPv6 unicast routing. The model fully conforms parameters for IPv6 unicast routing. The model fully conforms
to the Network Management Datastore Architecture (NMDA). to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2018 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as 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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set 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). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8349; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC XXXX";
revision 2018-01-25 { revision 2018-03-13 {
description description
"Network Management Datastore Architecture (NMDA) revision"; "Network Management Datastore Architecture (NMDA) revision.";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)"; (NMDA Version)";
} }
/* Identities */ /* Identities */
revision 2016-11-04 { revision 2016-11-04 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8022: A YANG Data Model for Routing Management"; "RFC 8022: A YANG Data Model for Routing Management";
} }
skipping to change at page 38, line 4 skipping to change at page 39, line 29
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"IPv6 destination prefix."; "IPv6 destination prefix.";
} }
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
when "derived-from-or-self(../../../rt:address-family, " when "derived-from-or-self(../../../rt:address-family, "
+ "'v6ur:ipv6-unicast')" { + "'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
description description
"Augment 'simple-next-hop' case in IPv6 unicast routes."; "Augments the 'simple-next-hop' case in IPv6 unicast routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+ "rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop" {
skipping to change at page 39, line 27 skipping to change at page 41, line 4
} }
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:simple-next-hop" { + "rt:simple-next-hop" {
when "derived-from-or-self(../../../rt:address-family, " when "derived-from-or-self(../../../rt:address-family, "
+ "'v6ur:ipv6-unicast')" { + "'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
description description
"Augment 'simple-next-hop' case in the reply to the "Augments the 'simple-next-hop' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
when "derived-from-or-self(../../../../../rt:address-family, " when "derived-from-or-self(../../../../../rt:address-family, "
+ "'v6ur:ipv6-unicast')" { + "'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
description description
"Augment 'next-hop-list' case in the reply to the "Augments the 'next-hop-list' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
/* Data node augmentations */ /* Data node augmentations */
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/rt:static-routes" { + "rt:control-plane-protocol/rt:static-routes" {
description description
"This augment defines the Support for the 'static' "This augment defines the 'static' pseudo-protocol
pseudo-protocol with data specific to IPv6 unicast."; with data specific to IPv6 unicast.";
container ipv6 { container ipv6 {
description description
"Support for a 'static' pseudo-protocol instance "Support for a 'static' pseudo-protocol instance
consists of a list of routes."; consists of a list of routes.";
list route { list route {
key "destination-prefix"; key "destination-prefix";
description description
"A list of static routes."; "A list of static routes.";
leaf destination-prefix { leaf destination-prefix {
type inet:ipv6-prefix; type inet:ipv6-prefix;
mandatory "true"; mandatory true;
description description
"IPv6 destination prefix."; "IPv6 destination prefix.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of the route."; "Textual description of the route.";
} }
container next-hop { container next-hop {
description description
"Support for next-hop."; "Next hop for the route.";
uses rt:next-hop-content { uses rt:next-hop-content {
augment "next-hop-options/simple-next-hop" { augment "next-hop-options/simple-next-hop" {
description description
"Augment 'simple-next-hop' case in IPv6 static "Augments the 'simple-next-hop' case in IPv6 static
routes."; routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
augment "next-hop-options/next-hop-list/next-hop-list/" augment "next-hop-options/next-hop-list/next-hop-list/"
+ "next-hop" { + "next-hop" {
description description
"Augment 'next-hop-list' case in IPv6 static "Augments the 'next-hop-list' case in IPv6 static
routes."; routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
} }
} }
} }
} }
} }
/* /*
* The subsequent data nodes are obviated and obsoleted by the * The subsequent data nodes are obviated and obsoleted
* "Network Management Architecture" as described in * by the Network Management Datastore Architecture
* draft-ietf-netmod-revised-datastores. * as described in RFC 8342.
*/ */
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
when "derived-from-or-self(../../rt:address-family, when "derived-from-or-self(../../rt:address-family,
'v6ur:ipv6-unicast')" { 'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
status obsolete; status obsolete;
description description
"This leaf augments an IPv6 unicast route."; "This leaf augments an IPv6 unicast route.";
leaf destination-prefix { leaf destination-prefix {
type inet:ipv6-prefix; type inet:ipv6-prefix;
status obsolete; status obsolete;
description description
"IPv6 destination prefix."; "IPv6 destination prefix.";
} }
skipping to change at page 41, line 47 skipping to change at page 43, line 25
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
when "derived-from-or-self(../../../rt:address-family, when "derived-from-or-self(../../../rt:address-family,
'v6ur:ipv6-unicast')" { 'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
status obsolete; status obsolete;
description description
"Augment 'simple-next-hop' case in IPv6 unicast routes."; "Augments the 'simple-next-hop' case in IPv6 unicast routes.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
status obsolete; status obsolete;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+ "rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop" {
skipping to change at page 42, line 47 skipping to change at page 44, line 24
leaf destination-address { leaf destination-address {
type inet:ipv6-address; type inet:ipv6-address;
status obsolete; status obsolete;
description description
"IPv6 destination address."; "IPv6 destination address.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route" { + "rt:output/rt:route" {
when "derived-from-or-self(../../rt:address-family, when "derived-from-or-self(../../rt:address-family,
'v6ur:ipv6-unicast')" { 'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
status obsolete; status obsolete;
description description
"This augment adds the destination prefix to the reply of the "This augment adds the destination prefix to the reply of the
'active-route' action."; 'active-route' action.";
leaf destination-prefix { leaf destination-prefix {
type inet:ipv6-prefix; type inet:ipv6-prefix;
status obsolete; status obsolete;
skipping to change at page 43, line 24 skipping to change at page 44, line 49
augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:simple-next-hop" { + "rt:simple-next-hop" {
when "derived-from-or-self(../../../rt:address-family, when "derived-from-or-self(../../../rt:address-family,
'v6ur:ipv6-unicast')" { 'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
status obsolete; status obsolete;
description description
"Augment 'simple-next-hop' case in the reply to the "Augments the 'simple-next-hop' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
status obsolete; status obsolete;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/"
+ "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
when "derived-from-or-self(../../../../../rt:address-family, when "derived-from-or-self(../../../../../rt:address-family,
'v6ur:ipv6-unicast')" { 'v6ur:ipv6-unicast')" {
description description
"This augment is valid only for IPv6 unicast."; "This augment is valid only for IPv6 unicast.";
} }
status obsolete; status obsolete;
description description
"Augment 'next-hop-list' case in the reply to the "Augments the 'next-hop-list' case in the reply to the
'active-route' action."; 'active-route' action.";
leaf next-hop-address { leaf next-hop-address {
type inet:ipv6-address; type inet:ipv6-address;
status obsolete; status obsolete;
description description
"IPv6 address of the next hop."; "IPv6 address of the next hop.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
9.1. IPv6 Router Advertisements Submodule 9.1. IPv6 Router Advertisements Submodule
<CODE BEGINS> file "ietf-ipv6-router-advertisements@2018-01-25.yang" <CODE BEGINS> file "ietf-ipv6-router-advertisements@2018-03-13.yang"
submodule ietf-ipv6-router-advertisements { submodule ietf-ipv6-router-advertisements {
yang-version "1.1"; yang-version "1.1";
belongs-to ietf-ipv6-unicast-routing { belongs-to ietf-ipv6-unicast-routing {
prefix "v6ur"; prefix "v6ur";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix "if";
description description
"A Network Management Datastore Architecture (NMDA) "An 'ietf-interfaces' module version that is compatible with
compatible version of the ietf-interfaces module the Network Management Datastore Architecture (NMDA)
is required."; is required.";
} }
import ietf-ip { import ietf-ip {
prefix "ip"; prefix "ip";
description description
"A Network Management Datastore Architecture (NMDA) "An 'ietf-ip' module version that is compatible with
compatible version of the ietf-ip module is the Network Management Datastore Architecture (NMDA)
required."; is required.";
} }
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:rtgwg@ietf.org> WG List: <mailto:rtgwg@ietf.org>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz> <mailto:lhotka@nic.cz>
Acee Lindem Acee Lindem
<mailto:acee@cisco.com> <mailto:acee@cisco.com>
Yingzhen Qu Yingzhen Qu
<mailto:yingzhen.qu@huawei.com>"; <mailto:yingzhen.qu@huawei.com>";
description description
"This YANG module augments the 'ietf-ip' module with "This YANG module augments the 'ietf-ip' module with
parameters for IPv6 router advertisements. The model fully parameters for IPv6 Router Advertisements. The model fully
conforms to the Network Management Datastore conforms to the Network Management Datastore
Architecture (NMDA). Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2018 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as 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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set 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). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8349; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";
revision 2018-01-25 { revision 2018-03-13 {
description description
"Network Management Datastore Architecture (NMDA) Revision"; "Network Management Datastore Architecture (NMDA) revision.";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)"; (NMDA Version)";
} }
revision 2016-11-04 { revision 2016-11-04 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8022: A YANG Data Model for Routing Management"; "RFC 8022: A YANG Data Model for Routing Management";
} }
augment "/if:interfaces/if:interface/ip:ipv6" { augment "/if:interfaces/if:interface/ip:ipv6" {
description description
"Augment interface configuration with parameters of IPv6 "Augments interface configuration with parameters of IPv6
router advertisements."; Router Advertisements.";
container ipv6-router-advertisements { container ipv6-router-advertisements {
description description
"Support for IPv6 Router Advertisements."; "Support for IPv6 Router Advertisements.";
leaf send-advertisements { leaf send-advertisements {
type boolean; type boolean;
default "false"; default "false";
description description
"A flag indicating whether or not the router sends "A flag indicating whether or not the router sends
periodic Router Advertisements and responds to periodic Router Advertisements and responds to
Router Solicitations."; Router Solicitations.";
skipping to change at page 46, line 4 skipping to change at page 47, line 32
container ipv6-router-advertisements { container ipv6-router-advertisements {
description description
"Support for IPv6 Router Advertisements."; "Support for IPv6 Router Advertisements.";
leaf send-advertisements { leaf send-advertisements {
type boolean; type boolean;
default "false"; default "false";
description description
"A flag indicating whether or not the router sends "A flag indicating whether or not the router sends
periodic Router Advertisements and responds to periodic Router Advertisements and responds to
Router Solicitations."; Router Solicitations.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvSendAdvertisements."; - AdvSendAdvertisements";
} }
leaf max-rtr-adv-interval { leaf max-rtr-adv-interval {
type uint16 { type uint16 {
range "4..65535"; range "4..65535";
} }
units "seconds"; units "seconds";
default "600"; default "600";
description description
"The maximum time allowed between sending unsolicited "The maximum time allowed between sending unsolicited
multicast Router Advertisements from the interface."; multicast Router Advertisements from the interface.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
MaxRtrAdvInterval."; - MaxRtrAdvInterval";
} }
leaf min-rtr-adv-interval { leaf min-rtr-adv-interval {
type uint16 { type uint16 {
range "3..1350"; range "3..1350";
} }
units "seconds"; units "seconds";
must ". <= 0.75 * ../max-rtr-adv-interval" { must ". <= 0.75 * ../max-rtr-adv-interval" {
description description
"The value MUST NOT be greater than 75% of "The value MUST NOT be greater than 75% of
'max-rtr-adv-interval'."; 'max-rtr-adv-interval'.";
} }
description description
"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.
skipping to change at page 46, line 44 skipping to change at page 48, line 24
multicast Router Advertisements from the interface. multicast Router Advertisements from the interface.
The default value to be used operationally if this The default value to be used operationally if this
leaf is not configured is determined as follows: leaf is not configured is determined as follows:
- if max-rtr-adv-interval >= 9 seconds, the default - if max-rtr-adv-interval >= 9 seconds, the default
value is 0.33 * max-rtr-adv-interval; value is 0.33 * max-rtr-adv-interval;
- otherwise, it is 0.75 * max-rtr-adv-interval."; - otherwise, it is 0.75 * max-rtr-adv-interval.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
MinRtrAdvInterval."; - MinRtrAdvInterval";
} }
leaf managed-flag { leaf managed-flag {
type boolean; type boolean;
default "false"; default "false";
description description
"The value to be placed in the 'Managed address "The value to be placed in the 'Managed address
configuration' flag field in the Router configuration' flag field in the Router
Advertisement."; Advertisement.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvManagedFlag."; - AdvManagedFlag";
} }
leaf other-config-flag { leaf other-config-flag {
type boolean; type boolean;
default "false"; default "false";
description description
"The value to be placed in the 'Other configuration' "The value to be placed in the 'Other configuration'
flag field in the Router Advertisement."; flag field in the Router Advertisement.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvOtherConfigFlag."; - AdvOtherConfigFlag";
} }
leaf link-mtu { leaf link-mtu {
type uint32; type uint32;
default "0"; default "0";
description description
"The value to be placed in MTU options sent by the "The value to be placed in MTU options sent by the
router. A value of zero indicates that no MTU options router. A value of zero indicates that no MTU options
are sent."; are sent.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvLinkMTU."; - AdvLinkMTU";
} }
leaf reachable-time { leaf reachable-time {
type uint32 { type uint32 {
range "0..3600000"; range "0..3600000";
} }
units "milliseconds"; units "milliseconds";
default "0"; default "0";
description description
"The value to be placed in the Reachable Time field in "The value to be placed in the Reachable Time field in
the Router Advertisement messages sent by the router. the Router Advertisement messages sent by the router.
A value of zero means unspecified (by this router)."; A value of zero means unspecified (by this router).";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvReachableTime."; - AdvReachableTime";
} }
leaf retrans-timer { leaf retrans-timer {
type uint32; type uint32;
units "milliseconds"; units "milliseconds";
default "0"; default "0";
description description
"The value to be placed in the Retrans Timer field in "The value to be placed in the Retrans Timer field in
the Router Advertisement messages sent by the router. the Router Advertisement messages sent by the router.
A value of zero means unspecified (by this router)."; A value of zero means unspecified (by this router).";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvRetransTimer."; - AdvRetransTimer";
} }
leaf cur-hop-limit { leaf cur-hop-limit {
type uint8; type uint8;
description description
"The value to be placed in the Cur Hop Limit field in "The value to be placed in the Cur Hop Limit field in
the Router Advertisement messages sent by the router. the Router Advertisement messages sent by the router.
A value of zero means unspecified (by this router). A value of zero means unspecified (by this router).
If this parameter is not configured, the device SHOULD If this parameter is not configured, the device SHOULD
use the value specified in IANA Assigned Numbers that use the IANA-specified value for the default IPv4
was in effect at the time of implementation."; Time to Live (TTL) parameter that was in effect at the
time of implementation.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by
AdvCurHopLimit. an On-line Database
RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
- AdvCurHopLimit
IANA: IP Parameters, IANA: IP Parameters
http://www.iana.org/assignments/ip-parameters"; (https://www.iana.org/assignments/ip-parameters)";
} }
leaf default-lifetime { leaf default-lifetime {
type uint16 { type uint16 {
range "0..65535"; range "0..65535";
} }
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 Router Advertisements sent from the interface, in
seconds. It MUST be either zero or between seconds. It MUST be either zero or between
max-rtr-adv-interval and 9000 seconds. A value of zero max-rtr-adv-interval and 9000 seconds. A value of zero
default indicates that the router is not to be used as indicates that the router is not to be used as a
a router. These limits may be overridden by specific default router. These limits may be overridden by
documents that describe how IPv6 operates over specific documents that describe how IPv6 operates over
different link layers. different link layers.
If this parameter is not configured, the device SHOULD If this parameter is not configured, the device SHOULD
use a value of 3 * max-rtr-adv-interval."; use a value of 3 * max-rtr-adv-interval.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvDefaultLifeTime."; - AdvDefaultLifetime";
} }
container prefix-list { container prefix-list {
description description
"Support for prefixes to be placed in Prefix "Support for prefixes to be placed in Prefix
Information options in Router Advertisement messages Information options in Router Advertisement messages
sent from the interface. sent from the interface.
Prefixes that are advertised by default but do not Prefixes that are advertised by default but do not
have their entries in the child 'prefix' list are have their entries in the child 'prefix' list are
advertised with the default values of all parameters. advertised with the default values of all parameters.
The link-local prefix SHOULD NOT be included in the The link-local prefix SHOULD NOT be included in the
list of advertised prefixes."; list of advertised prefixes.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
AdvPrefixList."; - AdvPrefixList";
list prefix { list prefix {
key "prefix-spec"; key "prefix-spec";
description description
"Support for an advertised prefix entry."; "Support for an advertised prefix entry.";
leaf prefix-spec { leaf prefix-spec {
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"IPv6 address prefix."; "IPv6 address prefix.";
} }
choice control-adv-prefixes { choice control-adv-prefixes {
default "advertise"; default "advertise";
description description
"Either the prefix is explicitly removed from the "Either (1) the prefix is explicitly removed from the
set of advertised prefixes, or the parameters with set of advertised prefixes or (2) the parameters with
which it is advertised are specified (default which the prefix is advertised are specified (default
case)."; case).";
leaf no-advertise { leaf no-advertise {
type empty; type empty;
description description
"The prefix will not be advertised. "The prefix will not be advertised.
This can be used for removing the prefix from This can be used for removing the prefix from
the default set of advertised prefixes."; the default set of advertised prefixes.";
} }
case advertise { case advertise {
skipping to change at page 49, line 50 skipping to change at page 51, line 31
type uint32; type uint32;
units "seconds"; units "seconds";
default "2592000"; default "2592000";
description description
"The value to be placed in the Valid Lifetime "The value to be placed in the Valid Lifetime
in the Prefix Information option. The in the Prefix Information option. The
designated value of all 1's (0xffffffff) designated value of all 1's (0xffffffff)
represents infinity."; represents infinity.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 "RFC 4861: Neighbor Discovery for IP version 6
(IPv6) - AdvValidLifetime."; (IPv6) - AdvValidLifetime";
} }
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.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 "RFC 4861: Neighbor Discovery for IP version 6
(IPv6) - AdvOnLinkFlag."; (IPv6) - AdvOnLinkFlag";
} }
leaf preferred-lifetime { leaf preferred-lifetime {
type uint32; type uint32;
units "seconds"; units "seconds";
must ". <= ../valid-lifetime" { must ". <= ../valid-lifetime" {
description description
"This value MUST NOT be greater than "This value MUST NOT be greater than
valid-lifetime."; valid-lifetime.";
} }
default "604800"; default "604800";
description description
"The value to be placed in the Preferred "The value to be placed in the Preferred
Lifetime in the Prefix Information option. Lifetime in the Prefix Information option.
The designated value of all 1's (0xffffffff) The designated value of all 1's (0xffffffff)
represents infinity."; represents infinity.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 "RFC 4861: Neighbor Discovery for IP version 6
(IPv6) - AdvPreferredLifetime."; (IPv6) - AdvPreferredLifetime";
} }
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.";
reference reference
"RFC 4861: Neighbor Discovery for IP version 6 "RFC 4861: Neighbor Discovery for IP version 6
(IPv6) - AdvAutonomousFlag."; (IPv6) - AdvAutonomousFlag";
} }
} }
} }
} }
} }
} }
} }
/* /*
* The subsequent data nodes are obviated and obsoleted by the * The subsequent data nodes are obviated and obsoleted
* "Network Management Architecture" as described in * by the Network Management Datastore Architecture
* draft-ietf-netmod-revised-datastores. * as described in RFC 8342.
*/ */
augment "/if:interfaces-state/if:interface/ip:ipv6" { augment "/if:interfaces-state/if:interface/ip:ipv6" {
status obsolete; status obsolete;
description description
"Augment interface state data with parameters of IPv6 router "Augments interface state data with parameters of IPv6
advertisements."; Router Advertisements.";
container ipv6-router-advertisements { container ipv6-router-advertisements {
status obsolete; status obsolete;
description description
"Parameters of IPv6 Router Advertisements."; "Parameters of IPv6 Router Advertisements.";
leaf send-advertisements { leaf send-advertisements {
type boolean; type boolean;
status obsolete; status obsolete;
description description
"A flag indicating whether or not the router sends periodic "A flag indicating whether or not the router sends
Router Advertisements and responds to Router periodic Router Advertisements and responds to
Solicitations."; Router Solicitations.";
} }
leaf max-rtr-adv-interval { leaf max-rtr-adv-interval {
type uint16 { type uint16 {
range "4..1800"; range "4..1800";
} }
units "seconds"; units "seconds";
status obsolete; status obsolete;
description description
"The maximum time allowed between sending unsolicited "The maximum time allowed between sending unsolicited
multicast Router Advertisements from the interface."; multicast Router Advertisements from the interface.";
skipping to change at page 52, line 14 skipping to change at page 53, line 45
status obsolete; status obsolete;
description description
"The value that is placed in the 'Other configuration' flag "The value that is placed in the 'Other configuration' flag
field in the Router Advertisement."; field in the Router Advertisement.";
} }
leaf link-mtu { leaf link-mtu {
type uint32; type uint32;
status obsolete; status obsolete;
description description
"The value that is placed in MTU options sent by the "The value that is placed in MTU options sent by the
router. A value of zero indicates that no MTU options are router. A value of zero indicates that no MTU options
sent."; are sent.";
} }
leaf reachable-time { leaf reachable-time {
type uint32 { type uint32 {
range "0..3600000"; range "0..3600000";
} }
units "milliseconds"; units "milliseconds";
status obsolete; status obsolete;
description description
"The value that is placed in the Reachable Time field in "The value that is placed in the Reachable Time field in
the Router Advertisement messages sent by the router. A the Router Advertisement messages sent by the router. A
skipping to change at page 53, line 40 skipping to change at page 55, line 22
leaf valid-lifetime { leaf valid-lifetime {
type uint32; type uint32;
units "seconds"; units "seconds";
status obsolete; status obsolete;
description description
"The value that is placed in the Valid Lifetime in the "The value that is placed in the Valid Lifetime in the
Prefix Information option. The designated value of Prefix Information option. The designated value of
all 1's (0xffffffff) represents infinity. all 1's (0xffffffff) represents infinity.
An implementation SHOULD keep this value constant in An implementation SHOULD keep this value constant in
consecutive advertisements except when it is consecutive advertisements, except when it is
explicitly changed in configuration."; explicitly changed in configuration.";
} }
leaf on-link-flag { leaf on-link-flag {
type boolean; type boolean;
status obsolete; status obsolete;
description description
"The value that is placed in the on-link flag ('L-bit') "The value that is placed in the on-link flag ('L-bit')
field in the Prefix Information option."; field in the Prefix Information option.";
} }
leaf preferred-lifetime { leaf preferred-lifetime {
type uint32; type uint32;
units "seconds"; units "seconds";
status obsolete; status obsolete;
description description
"The value that is placed in the Preferred Lifetime in "The value that is placed in the Preferred Lifetime in
the Prefix Information option, in seconds. The the Prefix Information option, in seconds. The
designated value of all 1's (0xffffffff) represents designated value of all 1's (0xffffffff) represents
infinity. infinity.
An implementation SHOULD keep this value constant in An implementation SHOULD keep this value constant in
consecutive advertisements except when it is consecutive advertisements, except when it is
explicitly changed in configuration."; explicitly changed in configuration.";
} }
leaf autonomous-flag { leaf autonomous-flag {
type boolean; type boolean;
status obsolete; status obsolete;
description description
"The value that is placed in the Autonomous Flag field "The value that is placed in the Autonomous Flag field
in the Prefix Information option."; in the Prefix Information option.";
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
10. IANA Considerations 10. IANA Considerations
[RFC8022] registered the following namespace URIs in the "IETF XML [RFC8022] registered the following namespace URIs in the "IETF XML
Registry" [RFC3688]: Registry" [RFC3688]. IANA has updated the references to refer to
this document.
URI: urn:ietf:params:xml:ns:yang:ietf-routing URI: urn:ietf:params:xml:ns:yang:ietf-routing
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
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.
[RFC8022] registered the following YANG modules in the "YANG Module [RFC8022] registered the following YANG modules in the "YANG Module
Names" registry [RFC6020]: Names" registry [RFC6020]. IANA has updated (1) the modules per this
document and (2) the references to refer to this document.
Name: ietf-routing
Namespace: urn:ietf:params:xml:ns:yang:ietf-routing
Prefix: rt
Reference: RFC 8022
Name: ietf-ipv4-unicast-routing Name: ietf-routing
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-routing
Prefix: v4ur Prefix: rt
Reference: RFC 8022 Reference: RFC 8349
Name: ietf-ipv6-unicast-routing Name: ietf-ipv4-unicast-routing
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
Prefix: v6ur Prefix: v4ur
Reference: RFC 8022 Reference: RFC 8349
Name: ietf-ipv6-unicast-routing
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing
Prefix: v6ur
Reference: RFC 8349
This document registers the following YANG submodule in the "YANG This document registers the following YANG submodule in the "YANG
Module Names" registry [RFC6020]: Module Names" registry [RFC6020]:
Name: ietf-ipv6-router-advertisements Name: ietf-ipv6-router-advertisements
Module: ietf-ipv6-unicast-routing Module: ietf-ipv6-unicast-routing
Reference: RFC 8022 Reference: RFC 8349
11. Security Considerations 11. Security Considerations
The YANG modules specified in this document define a schema for data The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC5246].
The NETCONF access control model [RFC6536] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in these YANG modules that
writable/creatable/deletable (i.e., config true, which is the are writable/creatable/deletable (i.e., config true, 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 (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/routing/control-plane-protocols/control-plane-protocol: This list /routing/control-plane-protocols/control-plane-protocol: This list
specifies the control-plane protocols configured on a device. specifies the control-plane protocols configured on a device.
/routing/ribs/rib: This list specifies the RIBs configured for the /routing/ribs/rib: This list specifies the RIBs configured for the
device. device.
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in these YANG modules may be
sensitive or vulnerable in some network environments. It is thus considered sensitive or vulnerable in some network environments. It
important to control read access (e.g., via get, get-config, or is thus important to control read access (e.g., via get, get-config,
notification) to these data nodes. These are the subtrees and data or notification) to these data nodes. These are the subtrees and
nodes and their sensitivity/vulnerability: data nodes and their sensitivity/vulnerability:
/routing/control-plane-protocols/control-plane-protocol: This list /routing/control-plane-protocols/control-plane-protocol: This list
specifies the control-plane protocols configured on a device. specifies the control-plane protocols configured on a device.
Refer to the control plane models for a list of sensitive Refer to the control-plane models for a list of sensitive
information. information.
/routing/ribs/rib: This list specifies the RIB and their contents /routing/ribs/rib: This list specifies the RIBs and their contents
for the device. Access to this information may disclose the for the device. Access to this information may disclose the
network topology and or other information. network topology and/or other information.
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the
operations and their sensitivity/vulnerability:
/routing/ribs/rib/active-route: The output from this RPC operation
returns the route that is being used for a specified destination.
Access to this information may disclose the network topology or
relationship (e.g., client/provider). Additionally, the routes
used by a network device may be used to mount a subsequent attack
on traffic traversing the network device.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004,
editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[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,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc- DOI 10.17487/RFC4861, September 2007,
editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc- DOI 10.17487/RFC5246, August 2008,
editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- DOI 10.17487/RFC6020, October 2010,
editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Protocol (NETCONF) Access Control Model", RFC 6536, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
DOI 10.17487/RFC6536, March 2012, <https://www.rfc- <https://www.rfc-editor.org/info/rfc6242>.
editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[I-D.ietf-netmod-rfc7223bis]
Bjorklund, M., "A YANG Data Model for Interface
Management", draft-ietf-netmod-rfc7223bis-03 (work in
progress), January 2018.
[I-D.ietf-netmod-rfc7277bis]
Bjorklund, M., "A YANG Data Model for IP Management",
draft-ietf-netmod-rfc7277bis-03 (work in progress),
January 2018.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, DOI 10.17487/RFC8022, November Management", RFC 8022, DOI 10.17487/RFC8022,
2016, <https://www.rfc-editor.org/info/rfc8022>. November 2016, <https://www.rfc-editor.org/info/rfc8022>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, RFC 2119 Key Words", BCP 14, RFC 8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-netmod-revised-datastores] [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Access Control Model", STD 91, RFC 8341,
and R. Wilton, "Network Management Datastore DOI 10.17487/RFC8341, March 2018,
Architecture", draft-ietf-netmod-revised-datastores-10 <https://www.rfc-editor.org/info/rfc8341>.
(work in progress), January 2018.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", World Wide Web Consortium Recommendation
REC-xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-netmod-rfc6087bis] [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
Bierman, A., "Guidelines for Authors and Reviewers of YANG RFC 7224, DOI 10.17487/RFC7224, May 2014,
Data Model Documents", draft-ietf-netmod-rfc6087bis-16 <https://www.rfc-editor.org/info/rfc7224>.
(work in progress), January 2018.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<https://www.rfc-editor.org/info/rfc7895>. <https://www.rfc-editor.org/info/rfc7895>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[I-D.ietf-netmod-yang-tree-diagrams] [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
ietf-netmod-yang-tree-diagrams-05 (work in progress), <https://www.rfc-editor.org/info/rfc8340>.
January 2018.
[YANG-Guidelines]
Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", Work in Progress,
draft-ietf-netmod-rfc6087bis-20, March 2018.
Appendix A. The Complete Schema Tree Appendix A. The Complete Schema Tree
This appendix presents the complete tree of the core routing data This appendix presents the complete tree of the core routing data
model. See Section 2.2 for an explanation of the symbols used. The model. See [RFC8340] for an explanation of the symbols used. The
data type of every leaf node is shown near the right end of the data type of every leaf node is shown near the right end of the
corresponding line. corresponding line.
module: ietf-routing module: ietf-routing
+--rw routing +--rw routing
| +--rw router-id? yang:dotted-quad | +--rw router-id? yang:dotted-quad
| +--ro interfaces | +--ro interfaces
| | +--ro interface* if:interface-ref | | +--ro interface* if:interface-ref
| +--rw control-plane-protocols | +--rw control-plane-protocols
| | +--rw control-plane-protocol* [type name] | | +--rw control-plane-protocol* [type name]
skipping to change at page 64, line 21 skipping to change at page 66, line 34
o--ro prefix-list o--ro prefix-list
o--ro prefix* [prefix-spec] o--ro prefix* [prefix-spec]
o--ro prefix-spec inet:ipv6-prefix o--ro prefix-spec inet:ipv6-prefix
o--ro valid-lifetime? uint32 o--ro valid-lifetime? uint32
o--ro on-link-flag? boolean o--ro on-link-flag? boolean
o--ro preferred-lifetime? uint32 o--ro preferred-lifetime? uint32
o--ro autonomous-flag? boolean o--ro autonomous-flag? boolean
Appendix B. Minimum Implementation Appendix B. Minimum Implementation
Some parts and options of the core routing model, such as user- Some parts and options of the core routing model, such as
defined RIBs, are intended only for advanced routers. This appendix user-defined RIBs, are intended only for advanced routers. This
gives basic non-normative guidelines for implementing a bare minimum appendix gives basic non-normative guidelines for implementing a bare
of available functions. Such an implementation may be used for hosts minimum of available functions. Such an implementation may be used
or very simple routers. for hosts or very simple routers.
A minimum implementation does not support the feature A minimum implementation does not support the "multiple-ribs"
"multiple-ribs". This means that a single system-controlled RIB is feature. This means that a single system-controlled RIB is available
available for each supported address family -- IPv4, IPv6, or both. for each supported address family -- IPv4, IPv6, or both. These RIBs
These RIBs are also the default RIBs. No user-controlled RIBs are are also the default RIBs. No user-controlled RIBs are allowed.
allowed.
In addition to the mandatory instance of the "direct" pseudo- In addition to the mandatory instance of the "direct"
protocol, a minimum implementation should support configuring pseudo-protocol, a minimum implementation should support configuring
instance(s) of the "static" pseudo-protocol. instance(s) of the "static" pseudo-protocol.
For hosts that are never intended to act as routers, the ability to For hosts that are never intended to act as routers, the ability to
turn on sending IPv6 router advertisements (Section 5.4) should be turn on sending IPv6 Router Advertisements (Section 5.4) should be
removed. removed.
Platforms with severely constrained resources may use deviations for Platforms with severely constrained resources may use deviations for
restricting the data model, e.g., limiting the number of "static" restricting the data model, e.g., limiting the number of "static"
control-plane protocol instances. control-plane protocol instances.
Appendix C. Example: Adding a New Control-Plane Protocol Appendix C. Example: Adding a New Control-Plane 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 control-plane protocol. The YANG module extended to support a new control-plane protocol. The YANG module
"example-rip" shown below is intended as an illustration rather than "example-rip" shown below is intended as an illustration rather than
a real definition of a data model for the Routing Information a real definition of a data model for the Routing Information
Protocol (RIP). For the sake of brevity, this module does not obey Protocol (RIP). For the sake of brevity, this module does not obey
all the guidelines specified in [I-D.ietf-netmod-rfc6087bis]. See all the guidelines specified in [YANG-Guidelines]. See also
also Section 5.3.2. Section 5.3.2.
module example-rip { module example-rip {
yang-version "1.1"; yang-version "1.1";
namespace "http://example.com/rip"; namespace "http://example.com/rip";
prefix "rip"; prefix "rip";
import ietf-interfaces { import ietf-interfaces {
prefix "if"; prefix "if";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
} }
skipping to change at page 65, line 45 skipping to change at page 68, line 14
grouping route-content { grouping route-content {
description description
"This grouping defines RIP-specific route attributes."; "This grouping defines RIP-specific route attributes.";
leaf metric { leaf metric {
type rip-metric; type rip-metric;
} }
leaf tag { leaf tag {
type uint16; type uint16;
default "0"; default "0";
description description
"This leaf may be used to carry additional info, e.g., "This leaf may be used to carry additional information,
autonomous system (AS) number."; e.g., an autonomous system (AS) number.";
} }
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
when "derived-from-or-self(rt:source-protocol, 'rip:rip')" { when "derived-from-or-self(rt:source-protocol, 'rip:rip')" {
description description
"This augment is only valid for a route whose source "This augment is only valid for a route whose source
protocol is RIP."; protocol is RIP.";
} }
description description
"RIP-specific route attributes."; "RIP-specific route attributes.";
uses route-content; uses route-content;
} }
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route" { + "rt:output/rt:route" {
description description
"RIP-specific route attributes in the output of 'active-route' "RIP-specific route attributes in the output of an
RPC."; 'active-route' RPC.";
uses route-content; uses route-content;
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol" { + "rt:control-plane-protocol" {
when "derived-from-or-self(rt:type,'rip:rip')" { when "derived-from-or-self(rt:type,'rip:rip')" {
description description
"This augment is only valid for a routing protocol instance "This augment is only valid for a routing protocol instance
of type 'rip'."; of type 'rip'.";
} }
container rip { container rip {
presence "RIP configuration"; presence
"RIP configuration";
description description
"RIP instance configuration."; "RIP instance configuration.";
container interfaces { container interfaces {
description description
"Per-interface RIP configuration."; "Per-interface RIP configuration.";
list interface { list interface {
key "name"; key "name";
description description
"RIP is enabled on interfaces that have an entry in this "RIP is enabled on interfaces that have an entry in this
list, unless 'enabled' is set to 'false' for that list, unless 'enabled' is set to 'false' for that
skipping to change at page 67, line 23 skipping to change at page 70, line 8
description description
"Time interval between periodic updates."; "Time interval between periodic updates.";
} }
} }
} }
} }
Appendix D. Data Tree Example Appendix D. Data Tree Example
This section contains an example of an instance data tree from the This section contains an example of an instance data tree from the
operational state, in the JSON encoding [RFC7951]. The data conforms operational state, in JSON encoding [RFC7951]. (This example
to a data model that is defined by the following YANG library includes "iana-if-type", which is defined in [RFC7224].)
specification [RFC7895]:
The data conforms to a data model that is defined by the following
YANG library specification [RFC7895]:
{ {
"ietf-yang-library:modules-state": { "ietf-yang-library:modules-state": {
"module-set-id": "c2e1f54169aa7f36e1a6e8d0865d441d3600f9c4", "module-set-id": "c2e1f54169aa7f36e1a6e8d0865d441d3600f9c4",
"module": [ "module": [
{ {
"name": "ietf-routing", "name": "ietf-routing",
"revision": "2018-01-25", "revision": "2018-03-13",
"feature": [ "feature": [
"multiple-ribs", "multiple-ribs",
"router-id" "router-id"
], ],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ipv4-unicast-routing", "name": "ietf-ipv4-unicast-routing",
"revision": "2018-01-25", "revision": "2018-03-13",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ipv6-unicast-routing", "name": "ietf-ipv6-unicast-routing",
"revision": "2018-01-25", "revision": "2018-03-13",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing", "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing",
"conformance-type": "implement", "conformance-type": "implement",
"submodule": [ "submodule": [
{ {
"name": "ietf-ipv6-router-advertisements", "name": "ietf-ipv6-router-advertisements",
"revision": "2018-01-25" "revision": "2018-03-13"
} }
] ]
}, },
{ {
"name": "ietf-interfaces", "name": "ietf-interfaces",
"revision": "2017-12-16", "revision": "2018-02-20",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-inet-types", "name": "ietf-inet-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"revision": "2013-07-15", "revision": "2013-07-15",
"conformance-type": "import" "conformance-type": "import"
}, },
{ {
"name": "ietf-yang-types", "name": "ietf-yang-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
skipping to change at page 68, line 39 skipping to change at page 71, line 26
"conformance-type": "import" "conformance-type": "import"
}, },
{ {
"name": "iana-if-type", "name": "iana-if-type",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"revision": "2014-05-08", "revision": "2014-05-08",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ip", "name": "ietf-ip",
"revision": "2017-12-16", "revision": "2018-02-22",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement" "conformance-type": "implement"
} }
] ]
} }
} }
A simple network setup as shown in Figure 2 is assumed: router "A" A simple network setup as shown in Figure 2 is assumed: 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.
IPv6 router advertisements are configured only on the "eth1" IPv6 Router Advertisements are configured only on the "eth1"
interface and disabled on the upstream "eth0" interface. interface and disabled on the upstream "eth0" interface.
+-----------------+ +-----------------+
| | | |
| Router ISP | | Router ISP |
| | | |
+--------+--------+ +--------+--------+
|2001:db8:0:1::2 |2001:db8:0:1::2
|192.0.2.2 |192.0.2.2
| |
skipping to change at page 73, line 46 skipping to change at page 77, line 7
] ]
} }
} }
] ]
} }
} }
} }
Appendix E. NETCONF Get Data Reply Example Appendix E. NETCONF Get Data Reply Example
This section gives an example of an XML reply to the NETCONF <get- This section gives an example of an XML [W3C.REC-xml-20081126] reply
data> request for <operational> for a device that implements the to the NETCONF <get-data> request for <operational> for a device that
example data models above. implements the example data models above.
<rpc-reply <rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101"> message-id="101">
<data> <data>
<routing <routing
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing" xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<router-id or:origin="or:intended">192.0.2.1</router-id> <router-id or:origin="or:intended">192.0.2.1</router-id>
<control-plane-protocols or:origin="or:intended"> <control-plane-protocols or:origin="or:intended">
<control-plane-protocol> <control-plane-protocol>
<type>ietf-routing:static</type> <type>ietf-routing:static</type>
<name></name> <name>static-routing-protocol</name>
<static-routes> <static-routes>
<ietf-ipv4-unicast-routing:ipv4> <ietf-ipv4-unicast-routing:ipv4>
<route> <route>
<destination-prefix>0.0.0.0/0</destination-prefix> <destination-prefix>0.0.0.0/0</destination-prefix>
<next-hop> <next-hop>
<next-hop-address>192.0.2.2</next-hop-address> <next-hop-address>192.0.2.2</next-hop-address>
</next-hop> </next-hop>
</route> </route>
</ietf-ipv4-unicast-routing:ipv4> </ietf-ipv4-unicast-routing:ipv4>
<ietf-ipv6-unicast-routing:ipv6> <ietf-ipv6-unicast-routing:ipv6>
skipping to change at page 76, line 35 skipping to change at page 80, line 8
</routes> </routes>
</rib> </rib>
</ribs> </ribs>
</routing> </routing>
</data> </data>
</rpc-reply> </rpc-reply>
Acknowledgments Acknowledgments
The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean
Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, Bogdanovic, Joe Clarke, Francis Dupont, Jeff Haas, Joel Halpern,
David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane Wes Hardaker, Jia He, Sriganesh Kini, Suresh Krishnan,
Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, David Lamparter, Xiang Li, Stephane Litkowski, Andrew McGregor,
Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Jan Medved, Thomas Morin, Tom Petch, Bruno Rijsman,
Derek Man-Kit Yeung, Jeffrey Zhang, Vladimir Vassilev, Rob Wilton, Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Vladimir Vassilev,
Joe Clark, Jia He, Suresh Krishnan, and Francis Dupont for their Rob Wilton, Yi Yang, Derek Man-Kit Yeung, and Jeffrey Zhang for their
helpful comments and suggestions. helpful comments and suggestions.
Authors' Addresses Authors' Addresses
Ladislav Lhotka Ladislav Lhotka
CZ.NIC CZ.NIC
EMail: lhotka@nic.cz Email: lhotka@nic.cz
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
EMail: acee@cisco.com Email: acee@cisco.com
Yingzhen Qu Yingzhen Qu
Huawei Huawei
2330 Central Expressway 2330 Central Expressway
Santa Clara CA 95050 Santa Clara, CA 95050
USA United States of America
EMail: yingzhen.qu@huawei.com Email: yingzhen.qu@huawei.com
 End of changes. 278 change blocks. 
506 lines changed or deleted 534 lines changed or added

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