< draft-ietf-netmod-rfc8022bis-04.txt   draft-ietf-netmod-rfc8022bis-05.txt >
NETMOD Working Group L. Lhotka NETMOD Working Group L. Lhotka
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track A. Lindem Intended status: Standards Track A. Lindem
Expires: June 15, 2018 Cisco Systems Expires: June 23, 2018 Cisco Systems
Y. Qu Y. Qu
Futurewei Technologies, Inc. Huawei
December 12, 2017 December 20, 2017
A YANG Data Model for Routing Management (NDMA Version) A YANG Data Model for Routing Management (NDMA Version)
draft-ietf-netmod-rfc8022bis-04 draft-ietf-netmod-rfc8022bis-05
Abstract Abstract
This document contains a specification of three YANG modules and one This document contains a specification of three YANG modules and one
submodule. Together they form the core routing data model that submodule. Together they form the core routing data model that
serves as a framework for configuring and managing a routing serves as a framework for configuring and managing a routing
subsystem. It is expected that these modules will be augmented by subsystem. It is expected that these modules will be augmented by
additional YANG modules defining data models for control-plane additional YANG modules defining data models for control-plane
protocols, route filters, and other functions. The core routing data protocols, route filters, and other functions. The core routing data
model provides common building blocks for such extensions -- routes, model provides common building blocks for such extensions -- routes,
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 15, 2018. This Internet-Draft will expire on June 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4
2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Design of the Core Routing Data Model . . . . . . . . . . 6 4. The Design of the Core Routing Data Model . . . . . . . . . . 6
4.1. System-Controlled and User-Controlled List Entries . . . 7 4.1. System-Controlled and User-Controlled List Entries . . . 7
5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 8 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 8
5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9 5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9
5.3. Control-Plane Protocol . . . . . . . . . . . . . . . . . 10 5.3. Control-Plane Protocol . . . . . . . . . . . . . . . . . 9
5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10 5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10
5.3.2. Defining New Control-Plane Protocols . . . . . . . . 10 5.3.2. Defining New Control-Plane Protocols . . . . . . . . 10
5.4. Parameters of IPv6 Router Advertisements . . . . . . . . 11 5.4. Parameters of IPv6 Router Advertisements . . . . . . . . 11
6. Interactions with Other YANG Modules . . . . . . . . . . . . 12 6. Interactions with Other YANG Modules . . . . . . . . . . . . 12
6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 12 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 12
6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 12
7. Routing Management YANG Module . . . . . . . . . . . . . . . 13 7. Routing Management YANG Module . . . . . . . . . . . . . . . 13
8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 28 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 28
9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 35 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 36
9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 43 9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 44
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 11. Security Considerations . . . . . . . . . . . . . . . . . . . 55
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.1. Normative References . . . . . . . . . . . . . . . . . . 55 12.1. Normative References . . . . . . . . . . . . . . . . . . 56
12.2. Informative References . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 58 Appendix A. The Complete Schema Tree . . . . . . . . . . . . . . 59
Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 61 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 64
Appendix C. Example: Adding a New Control-Plane Protocol . . . . 61 Appendix C. Example: Adding a New Control-Plane Protocol . . . . 64
Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 64 Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 67
Appendix E. NETCONF Get Data Reply Example . . . . . . . . . . . 70 Appendix E. NETCONF Get Data Reply Example . . . . . . . . . . . 73
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
This document contains a specification of the following YANG modules: This document contains a specification of the following YANG modules:
o 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" [RFC7223] and "ietf-ip" [RFC7277] modules with "ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and "ietf-
IPv6 router configuration variables required by [RFC4861]. ip" [I-D.ietf-netmod-rfc7277bis] modules with IPv6 router
configuration variables required by [RFC4861].
These modules together define the so-called core routing data model, These modules together define the so-called core routing data model,
which is intended as a basis for future data model development which is intended as a basis for future data model development
covering more-sophisticated routing systems. While these three covering more-sophisticated routing systems. While these three
modules can be directly used for simple IP devices with static modules can be directly used for simple IP devices with static
routing (see Appendix B), their main purpose is to provide essential routing (see Appendix B), their main purpose is to provide essential
building blocks for more-complicated data models involving multiple building 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
skipping to change at page 3, line 47 skipping to change at page 3, line 48
conforms to the Network Management Datastore Architecture (NMDA) conforms to the Network Management Datastore Architecture (NMDA)
[I-D.ietf-netmod-revised-datastores]. Consequently, this document [I-D.ietf-netmod-revised-datastores]. Consequently, this document
obsoletes RFC 8022 [RFC8022]. obsoletes 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terms are defined in [RFC6241]: The following terms are defined in
[I-D.ietf-netmod-revised-datastores]:
o client o client
o server
o message o configuration
o protocol operation
o server o system state
o operational state
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 configuration data
o container o container
o container with presence o container with presence
o data model o data model
o data node o data node
o feature o feature
skipping to change at page 5, line 16 skipping to change at page 5, line 20
("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 data user-controlled entry: An entry of a list in operational state data
("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
A simplified graphical representation of the complete data tree is Tree diagrams used in this document follow the notation defined in
presented in Appendix A, and similar diagrams of its various subtrees [I-D.ietf-netmod-yang-tree-diagrams].
appear in the main text.
o Brackets "[" and "]" enclose list keys.
o Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional.
o Abbreviations before data node names: "rw" means configuration
(read-write), "ro" state data (read-only), "-x" RPC operations or
actions, and "-n" notifications.
o Symbols after data node names: "?" means an optional node, "!" a
container with presence, and "*" denotes a "list" or "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
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 | [RFC7223] | | if | ietf-interfaces | [I-D.ietf-netmod-rfc7223bis] |
| ip | ietf-ip | [RFC7277] | | ip | ietf-ip | [I-D.ietf-netmod-rfc7277bis] |
| 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
skipping to change at page 6, line 52 skipping to change at page 6, line 29
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, "ietf-ipv4-
unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf-
routing" module with additional data nodes that are needed for IPv4 routing" module with additional data nodes that are needed for IPv4
and IPv6 unicast routing, respectively. The "ietf-ipv6-unicast- and IPv6 unicast routing, respectively. The "ietf-ipv6-unicast-
routing" module has a submodule, "ietf-ipv6-router-advertisements", routing" module has a submodule, "ietf-ipv6-router-advertisements",
that augments the "ietf-interfaces" [RFC7223] and "ietf-ip" [RFC7277] that augments the "ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and
modules with configuration variables for IPv6 router advertisements "ietf-ip" [I-D.ietf-netmod-rfc7277bis] modules with configuration
as required by [RFC4861]. 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 the complete data trees. for 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]
skipping to change at page 7, line 42 skipping to change at page 7, line 37
+---x active-route +---x active-route
| +---w input | +---w input
| | +---w v4ur:destination-address? inet:ipv4-address | | +---w v4ur:destination-address? inet:ipv4-address
| | +---w v6ur:destination-address? inet:ipv6-address | | +---w v6ur:destination-address? inet:ipv6-address
| +--ro output | +--ro output
| ... | ...
+--rw description? string +--rw description? string
Figure 1: Data Hierarchy Figure 1: Data Hierarchy
As can be seen from Figures 1, the core routing data model introduces As can be seen from Figure 1, the core routing data model introduces
several generic components of a routing framework: routes, RIBs several generic components of a routing framework: routes, RIBs
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 so-called
system-controlled entry in state data in the operational datastore system-controlled entry in state data in the operational state
[I-D.ietf-netmod-revised-datastores], i.e., inside read-only lists in datastore [I-D.ietf-netmod-revised-datastores], i.e., inside read-
the "routing" container. 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 named "ipv4-master" and
"ipv6-master". "ipv6-master".
Additional entries may be created in the configuration by a client, Additional entries may be created in the configuration by a client,
e.g., via the NETCONF protocol. These are so-called user-controlled e.g., via the NETCONF protocol. These are so-called user-controlled
entries. If the server accepts a configured user-controlled entry, entries. If the server accepts a configured user-controlled entry,
then this entry also appears in the state data version of the list. then this entry also appears in the state data version of the list.
Corresponding entries in both versions of the list (in operational Corresponding entries in both versions of the list (in operational
datastore and intended datastore [I-D.ietf-netmod-revised-datastores] state datastore and intended datastore
have the same value of the list key. [I-D.ietf-netmod-revised-datastores] have the same value of the list
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 state data list in the operational to the corresponding entry in the state data list in the operational
datastore, the key of the configuration entry has to be set to the state datastore, the key of the configuration entry has to be set to
same value as the key of the state entry. the same value as the key of the state entry.
Deleting a user-controlled entry from the configuration list results Deleting a user-controlled entry from the configuration list results
in the removal of the corresponding entry in the state data list. In in the removal of the corresponding entry in the state data list. In
contrast, if client delets a system-controlled entry from the contrast, if client delets a system-controlled entry from the
configuration list in the intended datastore, only the extra configuration list in the intended datastore, only the extra
configuration specified in that entry is removed but the configuration specified in that entry is removed but the
corresponding state data entry remains in the list in the operational corresponding state data entry remains in the list in the operational
datastore. datastore.
5. Basic Building Blocks 5. Basic Building Blocks
skipping to change at page 9, line 32 skipping to change at page 9, line 23
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 Routing Information Bases (RIBs). A RIB is a list of routes
complemented with administrative data. Each RIB contains only routes complemented with administrative data. Each RIB contains only routes
of one address family. An address family is represented by an of one address family. An address family is represented by an
identity derived from the "rt:address-family" base identity. identity derived from the "rt:address-family" base identity.
In the core routing data model, RIBs are state data represented as In the core routing data model, RIBs are state data represented as
entries of the list "/routing/ribs/rib" in the operational datastore entries of the list "/routing/ribs/rib" in the operational state
[I-D.ietf-netmod-revised-datastores]. The contents of RIBs are datastore [I-D.ietf-netmod-revised-datastores]. The contents of RIBs
controlled and manipulated by control-plane protocol operations that are controlled and manipulated by control-plane protocol operations
may result in route additions, removals, and modifications. This that may result in route additions, removals, and modifications.
also includes manipulations via the "static" and/or "direct" pseudo- This also includes manipulations via the "static" and/or "direct"
protocols; see Section 5.3.1. 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 so-called default RIB to which control-plane protocols place
their routes by default. their routes by default.
Simple router implementations that do not advertise the feature Simple router implementations that do not advertise the feature
"multiple-ribs" will typically create one system-controlled RIB per "multiple-ribs" will typically create one system-controlled RIB per
supported address family and mark it as the default RIB. 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"
skipping to change at page 12, line 4 skipping to change at page 11, line 47
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 the
list: 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 [RFC7277] (leaf implemented in the "ietf-ip" module [I-D.ietf-netmod-rfc7277bis]
"ip:forwarding"). (leaf "ip:forwarding").
2. The original specification [RFC4861] allows the implementations 2. The original specification [RFC4861] allows the implementations
to decide whether the "valid-lifetime" and "preferred-lifetime" to decide whether the "valid-lifetime" and "preferred-lifetime"
parameters remain the same in consecutive advertisements or parameters remain the same in consecutive advertisements or
decrement in real time. However, the latter behavior seems decrement in real time. However, the latter behavior seems
problematic because the values might be reset again to the problematic because the values might be reset again to the
(higher) configured values after a configuration is reloaded. (higher) configured values after a configuration is reloaded.
Moreover, no implementation is known to use the decrementing Moreover, no implementation is known to use the decrementing
behavior. The "ietf-ipv6-router-advertisements" submodule behavior. The "ietf-ipv6-router-advertisements" submodule
therefore stipulates the former behavior with constant values. 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 [RFC7223]: module [I-D.ietf-netmod-rfc7223bis]:
/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 [RFC7277]: module [I-D.ietf-netmod-rfc7277bis]:
/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,
skipping to change at page 13, line 46 skipping to change at page 13, line 41
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@2017-12-11.yang" <CODE BEGINS> file "ietf-routing@2017-12-20.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 "A Network Management Datastore Architecture (NDMA)
compatible version of the ietf-interfaces module
is required.";
} }
organization organization
"IETF NETMOD - Networking Modeling Working Group"; "IETF NETMOD - Networking Modeling Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.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. of a routing subsystem. The model fully conforms to the Network
Management Datastore Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2017 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). (http://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 XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC XXXX"; reference "RFC XXXX";
revision 2017-12-11 { revision 2017-12-20 {
description description
"Network Managment Datastore Architecture (NDMA) Revision"; "Network Managment Datastore Architecture (NDMA) Revision";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC XXXX: A YANG Data Model for Routing Management
(NDMA Version)"; (NDMA Version)";
} }
revision 2016-11-04 { revision 2016-11-04 {
description description
"Initial revision."; "Initial revision.";
skipping to change at page 15, line 42 skipping to change at page 15, line 42
/* 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 rt:address-family; base address-family;
description description
"This identity represents IPv4 address family."; "This identity represents IPv4 address family.";
} }
identity ipv6 { identity ipv6 {
base rt:address-family; base address-family;
description description
"This identity represents IPv6 address family."; "This identity represents 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 rt:control-plane-protocol; base control-plane-protocol;
description description
"Identity from which Layer 3 routing protocol identities are "Identity from which Layer 3 routing protocol identities are
derived."; derived.";
} }
identity direct { identity direct {
base rt: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 rt: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.";
} }
/* 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 rt:address-family; base address-family;
} }
mandatory "true"; mandatory "true";
description description
"Address family."; "Address family.";
} }
} }
grouping router-id { grouping router-id {
description description
skipping to change at page 20, line 21 skipping to change at page 20, line 21
} }
} }
} }
} }
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 rt: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 "Presence of this leaf indicates that the route is preferred
skipping to change at page 20, line 44 skipping to change at page 20, line 44
} }
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 "Time stamp 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.";
} }
} }
/* Configuration Data */ /* 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
"Configuration of the global router ID. Routing protocols "Configuration of the global router ID. Routing protocols
that use router ID can use this parameter or override it that use router ID can use this parameter or override it
with another value."; with another value.";
skipping to change at page 21, line 28 skipping to change at page 21, line 28
container control-plane-protocols { container control-plane-protocols {
description description
"Configuration of control-plane protocol instances."; "Configuration of control-plane protocol instances.";
list control-plane-protocol { list control-plane-protocol {
key "type name"; key "type name";
description description
"Each entry contains configuration of a control-plane "Each entry contains configuration of a control-plane
protocol instance."; protocol instance.";
leaf type { leaf type {
type identityref { type identityref {
base rt: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 derived
from the 'control-plane-protocol' base identity."; 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.";
skipping to change at page 25, line 13 skipping to change at page 25, line 13
status obsolete; status obsolete;
description description
"State data of a control-plane protocol instance. "State data of a control-plane protocol instance.
An implementation MUST provide exactly one An implementation MUST provide exactly one
system-controlled instance of the 'direct' system-controlled instance of the 'direct'
pseudo-protocol. Instances of other control-plane pseudo-protocol. Instances of other control-plane
protocols MAY be created by configuration."; protocols MAY be created by configuration.";
leaf type { leaf type {
type identityref { type identityref {
base rt:control-plane-protocol; base control-plane-protocol;
} }
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.
skipping to change at page 28, line 7 skipping to change at page 28, line 7
} }
} }
} }
} }
} }
} }
<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@2017-12-11.yang" <CODE BEGINS> file "ietf-ipv4-unicast-routing@2017-12-20.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 "A Network Management Datastore Architecture (NDMA)
compatible version of the ietf-routing module
is required.";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
organization organization
"IETF NETMOD - Networking Modeling Working Group"; "IETF NETMOD - Networking Modeling Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.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
configuration and state data for IPv4 unicast routing. configuration and state data for IPv4 unicast routing. The
model fully conforms to the Network Management Datastore
Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2017 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). (http://trustee.ietf.org/license-info).
skipping to change at page 28, line 47 skipping to change at page 29, line 4
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2017 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). (http://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 XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC XXXX"; reference "RFC XXXX";
revision 2017-12-11 { revision 2017-12-20 {
description description
"Network Managment Datastore Architecture (NDMA) Revision"; "Network Managment Datastore Architecture (NDMA) Revision";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC XXXX: A YANG Data Model for Routing Management
(NDMA Version)"; (NDMA Version)";
} }
revision 2016-11-04 { revision 2016-11-04 {
description description
"Initial revision."; "Initial revision.";
skipping to change at page 35, line 45 skipping to change at page 36, line 7
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@2017-12-11.yang" <CODE BEGINS> file "ietf-ipv6-unicast-routing@2017-12-20.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 "A Network Management Datastore Architecture (NDMA)
compatible version of the ietf-routing module
is required.";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
description "A Network Management Datastore Architecture (NDMA)
compatible version of the ietf-interfaces module
is required.";
} }
include ietf-ipv6-router-advertisements { include ietf-ipv6-router-advertisements {
revision-date 2017-12-11; revision-date 2017-12-20;
} }
organization organization
"IETF NETMOD - Networking Modeling Working Group"; "IETF NETMOD - Networking Modeling Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.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
configuration and state data for IPv6 unicast routing. configuration and state data for IPv6 unicast routing. The
model fully conforms to the Network Management Datastore
Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2017 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). (http://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 XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC XXXX"; reference "RFC XXXX";
revision 2017-12-11 { revision 2017-12-20 {
description description
"Network Managment Datastore Architecture (NDMA) revision"; "Network Managment Datastore Architecture (NDMA) revision";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC XXXX: A YANG Data Model for Routing Management
(NDMA Version)"; (NDMA Version)";
} }
/* Identities */ /* Identities */
revision 2016-11-04 { revision 2016-11-04 {
skipping to change at page 39, line 44 skipping to change at page 40, line 12
description description
"Augment 'next-hop-list' case in the reply to the "Augment '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.";
} }
} }
/* Configuration data */ /* 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 configuration of the 'static' "This augment defines the configuration of the 'static'
pseudo-protocol with data specific to IPv6 unicast."; pseudo-protocol with data specific to IPv6 unicast.";
container ipv6 { container ipv6 {
description description
"Configuration of a 'static' pseudo-protocol instance "Configuration of a 'static' pseudo-protocol instance
consists of a list of routes."; consists of a list of routes.";
skipping to change at page 43, line 35 skipping to change at page 44, line 4
status obsolete; status obsolete;
description description
"Augment 'next-hop-list' case in the reply to the "Augment '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@2017-12-11.yang" <CODE BEGINS> file "ietf-ipv6-router-advertisements@2017-12-20.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";
} }
skipping to change at page 44, line 4 skipping to change at page 44, line 22
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 "A Network Management Datastore Architecture (NDMA)
compatible version of the ietf-interfaces module
is required.";
} }
import ietf-ip { import ietf-ip {
prefix "ip"; prefix "ip";
description "A Network Management Datastore Architecture (NDMA)
compatible version of the ietf-ip module is
required.";
} }
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto: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
configuration and state data of IPv6 router advertisements. configuration and state data of IPv6 router advertisements.
The model fully conforms to the Network Management Datastore
Architecture (NMDA).
Copyright (c) 2017 IETF Trust and the persons Copyright (c) 2017 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). (http://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 XXXX; 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 2017-12-11 { revision 2017-12-20 {
description description
"Network Managment Datastore Architecture (NDMA) Revision"; "Network Managment Datastore Architecture (NDMA) Revision";
reference reference
"RFC XXXX: A YANG Data Model for Routing Management "RFC XXXX: A YANG Data Model for Routing Management
(NDMA Version)"; (NDMA 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 "Augment interface configuration with parameters of IPv6
skipping to change at page 54, line 29 skipping to change at page 55, line 4
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]:
Name: ietf-routing Name: ietf-routing
Namespace: urn:ietf:params:xml:ns:yang:ietf-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-routing
Prefix: rt Prefix: rt
Reference: RFC 8022 Reference: RFC 8022
Name: ietf-ipv4-unicast-routing Name: ietf-ipv4-unicast-routing
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
Prefix: v4ur Prefix: v4ur
Reference: RFC 8022 Reference: RFC 8022
Name: ietf-ipv6-unicast-routing Name: ietf-ipv6-unicast-routing
Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing
Prefix: v6ur Prefix: v6ur
Reference: RFC 8022 Reference: RFC 8022
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 8022
11. Security Considerations 11. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module specified in this document defines a schedma for data
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the that is designed to be accessed via network management protocols such
secure transport layer and the mandatory-to-implement secure as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
transport is SSH [RFC6242]. is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246].
There are a number of data nodes defined in this YANG module which The NETCONF access control model [RFC6536] provides the means to
are writable/creatable/deletable (i.e., config true, which is the restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in this YANG module that 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
skipping to change at page 56, line 5 skipping to change at page 56, line 35
[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, <https://www.rfc-
editor.org/info/rfc3688>. 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, <https://www.rfc-
editor.org/info/rfc4861>. editor.org/info/rfc4861>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <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, <https://www.rfc-
editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <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
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
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>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [I-D.ietf-netmod-rfc7223bis]
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Bjorklund, M., "A YANG Data Model for Interface
<https://www.rfc-editor.org/info/rfc7223>. Management", draft-ietf-netmod-rfc7223bis-01 (work in
progress), December 2017.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [I-D.ietf-netmod-rfc7277bis]
RFC 7277, DOI 10.17487/RFC7277, June 2014, Bjorklund, M., "A YANG Data Model for IP Management",
<https://www.rfc-editor.org/info/rfc7277>. draft-ietf-netmod-rfc7277bis-01 (work in progress),
December 2017.
[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, November
2016, <https://www.rfc-editor.org/info/rfc8022>. 2016, <https://www.rfc-editor.org/info/rfc8022>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-07
(work in progress), November 2017.
12.2. Informative References 12.2. Informative References
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG [I-D.ietf-netmod-rfc6087bis]
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, Bierman, A., "Guidelines for Authors and Reviewers of YANG
January 2011, <https://www.rfc-editor.org/info/rfc6087>. Data Model Documents", draft-ietf-netmod-rfc6087bis-15
(work in progress), December 2017.
[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-revised-datastores] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
and R. Wilton, "Network Management Datastore ietf-netmod-yang-tree-diagrams-02 (work in progress),
Architecture", draft-ietf-netmod-revised-datastores-07 October 2017.
(work in progress), November 2017.
Appendix A. The Complete Data Trees 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 Section 2.2 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]
| +--rw type identityref | | +--rw type identityref
| +--rw name string | | +--rw name string
| +--rw description? string | | +--rw description? string
| +--rw static-routes | | +--rw static-routes
| +--rw v4ur:ipv4 | | +--rw v4ur:ipv4
| | +--rw v4ur:route* [destination-prefix] | | | +--rw v4ur:route* [destination-prefix]
| | +--rw v4ur:destination-prefix inet:ipv4-prefix | | | +--rw v4ur:destination-prefix
| | +--rw v4ur:description? string | | | | inet:ipv4-prefix
| | +--rw v4ur:next-hop | | | +--rw v4ur:description? string
| | +--rw (v4ur:next-hop-options) | | | +--rw v4ur:next-hop
| | +--:(v4ur:simple-next-hop) | | | +--rw (v4ur:next-hop-options)
| | | +--rw v4ur:outgoing-interface? | | | +--:(v4ur:simple-next-hop)
| | | if:interface-ref | | | | +--rw v4ur:outgoing-interface?
| | | +--rw v4ur:next-hop-address? | | | | | if:interface-ref
| | | inet:ipv4-address | | | | +--rw v4ur:next-hop-address?
| | +--:(v4ur:special-next-hop) | | | | inet:ipv4-address
| | | +--rw v4ur:special-next-hop? enumeration | | | +--:(v4ur:special-next-hop)
| | +--:(v4ur:next-hop-list) | | | | +--rw v4ur:special-next-hop?
| | +--rw v4ur:next-hop-list | | | | enumeration
| | +--rw v4ur:next-hop* [index] | | | +--:(v4ur:next-hop-list)
| | +--rw v4ur:index string | | | +--rw v4ur:next-hop-list
| | +--rw v4ur:outgoing-interface? | | | +--rw v4ur:next-hop* [index]
| | if:interface-ref | | | +--rw v4ur:index
| | +--rw v4ur:next-hop-address? | | | | string
| | inet:ipv4-address | | | +--rw v4ur:outgoing-interface?
| +--rw v6ur:ipv6 | | | | if:interface-ref
| +--rw v6ur:route* [destination-prefix] | | | +--rw v4ur:next-hop-address?
| +--rw v6ur:destination-prefix inet:ipv6-prefix | | | inet:ipv4-address
| +--rw v6ur:description? string | | +--rw v6ur:ipv6
| +--rw v6ur:next-hop | | +--rw v6ur:route* [destination-prefix]
| +--rw (v6ur:next-hop-options) | | +--rw v6ur:destination-prefix
| +--:(v6ur:simple-next-hop) | | | inet:ipv6-prefix
| | +--rw v6ur:outgoing-interface? | | +--rw v6ur:description? string
| | if:interface-ref | | +--rw v6ur:next-hop
| | +--rw v6ur:next-hop-address? | | +--rw (v6ur:next-hop-options)
| | inet:ipv6-address | | +--:(v6ur:simple-next-hop)
| +--:(v6ur:special-next-hop) | | | +--rw v6ur:outgoing-interface?
| | +--rw v6ur:special-next-hop? enumeration | | | | if:interface-ref
| +--:(v6ur:next-hop-list) | | | +--rw v6ur:next-hop-address?
| +--rw v6ur:next-hop-list | | | inet:ipv6-address
| +--rw v6ur:next-hop* [index] | | +--:(v6ur:special-next-hop)
| +--rw v6ur:index string | | | +--rw v6ur:special-next-hop?
| +--rw v6ur:outgoing-interface? | | | enumeration
| if:interface-ref | | +--:(v6ur:next-hop-list)
| +--rw v6ur:next-hop-address? | | +--rw v6ur:next-hop-list
| inet:ipv6-address | | +--rw v6ur:next-hop* [index]
+--rw ribs | | +--rw v6ur:index
+--rw rib* [name] | | | string
+--rw name string | | +--rw v6ur:outgoing-interface?
+--rw address-family? identityref | | | if:interface-ref
+--ro default-rib? boolean {multiple-ribs}? | | +--rw v6ur:next-hop-address?
+--ro routes | | inet:ipv6-address
| +--ro route* | +--rw ribs
| +--ro route-preference? route-preference | +--rw rib* [name]
| +--ro next-hop | +--rw name string
| | +--ro (next-hop-options) | +--rw address-family identityref
| | +--:(simple-next-hop) | +--ro default-rib? boolean {multiple-ribs}?
| | | +--ro outgoing-interface? | +--ro routes
| | | | if:interface-ref | | +--ro route*
| | | +--ro v4ur:next-hop-address? | | +--ro route-preference? route-preference
| | | | inet:ipv4-address | | +--ro next-hop
| | | +--ro v6ur:next-hop-address? | | | +--ro (next-hop-options)
| | | inet:ipv6-address | | | +--:(simple-next-hop)
| | +--:(special-next-hop) | | | | +--ro outgoing-interface?
| | | +--ro special-next-hop? enumeration | | | | | if:interface-ref
| | +--:(next-hop-list) | | | | +--ro v4ur:next-hop-address?
| | +--ro next-hop-list | | | | | inet:ipv4-address
| | +--ro next-hop* | | | | +--ro v6ur:next-hop-address?
| | +--ro outgoing-interface? | | | | inet:ipv6-address
| | | if:interface-ref | | | +--:(special-next-hop)
| | +--ro v4ur:address? | | | | +--ro special-next-hop? enumeration
| | | inet:ipv4-address | | | +--:(next-hop-list)
| | +--ro v6ur:address? | | | +--ro next-hop-list
| | inet:ipv6-address | | | +--ro next-hop*
| +--ro source-protocol identityref | | | +--ro outgoing-interface?
| +--ro active? empty | | | | if:interface-ref
| +--ro last-updated? yang:date-and-time | | | +--ro v4ur:address?
| +--ro v4ur:destination-prefix? inet:ipv4-prefix | | | | inet:ipv4-address
| +--ro v6ur:destination-prefix? inet:ipv6-prefix | | | +--ro v6ur:address?
+---x active-route | | | inet:ipv6-address
| +---w input | | +--ro source-protocol identityref
| | +---w v4ur:destination-address? inet:ipv4-address | | +--ro active? empty
| | +---w v6ur:destination-address? inet:ipv6-address | | +--ro last-updated? yang:date-and-time
| +--ro output | | +--ro v4ur:destination-prefix? inet:ipv4-prefix
| +--ro route | | +--ro v6ur:destination-prefix? inet:ipv6-prefix
| +--ro next-hop | +---x active-route
| | +--ro (next-hop-options) | | +---w input
| | +--:(simple-next-hop) | | | +---w v4ur:destination-address? inet:ipv4-address
| | | +--ro outgoing-interface? | | | +---w v6ur:destination-address? inet:ipv6-address
| | | | if:interface-ref | | +--ro output
| | | +--ro v4ur:next-hop-address? | | +--ro route
| | | | inet:ipv4-address | | +--ro next-hop
| | | +--ro v6ur:next-hop-address? | | | +--ro (next-hop-options)
| | | inet:ipv6-address | | | +--:(simple-next-hop)
| | +--:(special-next-hop) | | | | +--ro outgoing-interface?
| | | +--ro special-next-hop? enumeration | | | | | if:interface-ref
| | +--:(next-hop-list) | | | | +--ro v4ur:next-hop-address?
| | +--ro next-hop-list | | | | | inet:ipv4-address
| | +--ro next-hop* | | | | +--ro v6ur:next-hop-address?
| | +--ro outgoing-interface? | | | | inet:ipv6-address
| | | if:interface-ref | | | +--:(special-next-hop)
| | +--ro v4ur:next-hop-address? | | | | +--ro special-next-hop?
| | | inet:ipv4-address | | | | enumeration
| | +--ro v6ur:next-hop-address? | | | +--:(next-hop-list)
| | inet:ipv6-address | | | +--ro next-hop-list
| +--ro source-protocol identityref | | | +--ro next-hop*
| +--ro active? empty | | | +--ro outgoing-interface?
| +--ro last-updated? yang:date-and-time | | | | if:interface-ref
| +--ro v4ur:destination-prefix? inet:ipv4-prefix | | | +--ro v4ur:next-hop-address?
| +--ro v6ur:destination-prefix? inet:ipv6-prefix | | | | inet:ipv4-address
+--rw description? string | | | +--ro v6ur:next-hop-address?
| | | inet:ipv6-address
| | +--ro source-protocol identityref
| | +--ro active? empty
| | +--ro last-updated?
| | | yang:date-and-time
| | +--ro v4ur:destination-prefix?
| | | inet:ipv4-prefix
| | +--ro v6ur:destination-prefix?
| | inet:ipv6-prefix
| +--rw description? string
o--ro routing-state
+--ro router-id? yang:dotted-quad
o--ro interfaces
| o--ro interface* if:interface-state-ref
o--ro control-plane-protocols
| o--ro control-plane-protocol* [type name]
| o--ro type identityref
| o--ro name string
o--ro ribs
o--ro rib* [name]
o--ro name string
+--ro address-family identityref
o--ro default-rib? boolean {multiple-ribs}?
o--ro routes
| o--ro route*
| o--ro route-preference? route-preference
| o--ro next-hop
| | +--ro (next-hop-options)
| | +--:(simple-next-hop)
| | | +--ro outgoing-interface?
| | | | if:interface-ref
| | | o--ro v4ur:next-hop-address?
| | | | inet:ipv4-address
| | | o--ro v6ur:next-hop-address?
| | | inet:ipv6-address
| | +--:(special-next-hop)
| | | +--ro special-next-hop? enumeration
| | +--:(next-hop-list)
| | +--ro next-hop-list
| | +--ro next-hop*
| | +--ro outgoing-interface?
| | | if:interface-ref
| | o--ro v4ur:address?
| | | inet:ipv4-address
| | o--ro v6ur:address?
| | inet:ipv6-address
| +--ro source-protocol identityref
| +--ro active? empty
| +--ro last-updated? yang:date-and-time
| o--ro v4ur:destination-prefix? inet:ipv4-prefix
| o--ro v6ur:destination-prefix? inet:ipv6-prefix
o---x active-route
+---w input
| o---w v4ur:destination-address? inet:ipv4-address
| o---w v6ur:destination-address? inet:ipv6-address
+--ro output
o--ro route
o--ro next-hop
| +--ro (next-hop-options)
| +--:(simple-next-hop)
| | +--ro outgoing-interface?
| | | if:interface-ref
| | o--ro v4ur:next-hop-address?
| | | inet:ipv4-address
| | o--ro v6ur:next-hop-address?
| | inet:ipv6-address
| +--:(special-next-hop)
| | +--ro special-next-hop?
| | enumeration
| +--:(next-hop-list)
| +--ro next-hop-list
| +--ro next-hop*
| +--ro outgoing-interface?
| | if:interface-ref
| o--ro v4ur:next-hop-address?
| | inet:ipv4-address
| o--ro v6ur:next-hop-address?
| inet:ipv6-address
+--ro source-protocol identityref
+--ro active? empty
+--ro last-updated?
| yang:date-and-time
o--ro v4ur:destination-prefix?
| inet:ipv4-prefix
o--ro v6ur:destination-prefix?
inet:ipv6-prefix
module: ietf-ipv6-unicast-routing module: ietf-ipv6-unicast-routing
augment /if:interfaces/if:interface/ip:ipv6: augment /if:interfaces/if:interface/ip:ipv6:
+--rw ipv6-router-advertisements +--rw ipv6-router-advertisements
+--rw send-advertisements? boolean +--rw send-advertisements? boolean
+--rw max-rtr-adv-interval? uint16 +--rw max-rtr-adv-interval? uint16
+--rw min-rtr-adv-interval? uint16 +--rw min-rtr-adv-interval? uint16
+--rw managed-flag? boolean +--rw managed-flag? boolean
+--rw other-config-flag? boolean +--rw other-config-flag? boolean
+--rw link-mtu? uint32 +--rw link-mtu? uint32
+--rw reachable-time? uint32 +--rw reachable-time? uint32
+--rw retrans-timer? uint32 +--rw retrans-timer? uint32
+--rw cur-hop-limit? uint8 +--rw cur-hop-limit? uint8
+--rw default-lifetime? uint16 +--rw default-lifetime? uint16
+--rw prefix-list +--rw prefix-list
+--rw prefix* [prefix-spec] +--rw prefix* [prefix-spec]
+--rw prefix-spec inet:ipv6-prefix +--rw prefix-spec inet:ipv6-prefix
+--rw (control-adv-prefixes)? +--rw (control-adv-prefixes)?
+--:(no-advertise) +--:(no-advertise)
| +--rw no-advertise? empty | +--rw no-advertise? empty
+--:(advertise) +--:(advertise)
+--rw valid-lifetime? uint32 +--rw valid-lifetime? uint32
+--rw on-link-flag? boolean +--rw on-link-flag? boolean
+--rw preferred-lifetime? uint32 +--rw preferred-lifetime? uint32
+--rw autonomous-flag? boolean +--rw autonomous-flag? boolean
augment /if:interfaces-state/if:interface/ip:ipv6:
o--ro ipv6-router-advertisements
o--ro send-advertisements? boolean
o--ro max-rtr-adv-interval? uint16
o--ro min-rtr-adv-interval? uint16
o--ro managed-flag? boolean
o--ro other-config-flag? boolean
o--ro link-mtu? uint32
o--ro reachable-time? uint32
o--ro retrans-timer? uint32
o--ro cur-hop-limit? uint8
o--ro default-lifetime? uint16
o--ro prefix-list
o--ro prefix* [prefix-spec]
o--ro prefix-spec inet:ipv6-prefix
o--ro valid-lifetime? uint32
o--ro on-link-flag? boolean
o--ro preferred-lifetime? uint32
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 user-
defined RIBs, are intended only for advanced routers. This appendix defined RIBs, are intended only for advanced routers. This appendix
gives basic non-normative guidelines for implementing a bare minimum gives basic non-normative guidelines for implementing a bare minimum
of available functions. Such an implementation may be used for hosts of available functions. Such an implementation may be used for hosts
or very simple routers. or very simple routers.
A minimum implementation does not support the feature A minimum implementation does not support the feature
skipping to change at page 61, line 43 skipping to change at page 65, line 4
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 [RFC6087]. See also Section 5.3.2. all the guidelines specified in [I-D.ietf-netmod-rfc6087bis]. See
also 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";
} }
identity rip { identity rip {
base rt:routing-protocol; base rt:routing-protocol;
skipping to change at page 64, line 4 skipping to change at page 67, line 16
} }
leaf update-interval { leaf update-interval {
type uint8 { type uint8 {
range "10..60"; range "10..60";
} }
units "seconds"; units "seconds";
default "30"; default "30";
description description
"Time interval between periodic updates."; "Time interval between periodic updates.";
} }
} }
} }
} }
Appendix D. Data Tree Example Appendix D. Data Tree Example
This section contains an example of an instance data tree in the JSON This section contains an example of an instance data tree in the JSON
encoding [RFC7951], containing both configuration and state data. encoding [RFC7951], containing both configuration and state data.
The data conforms to a data model that is defined by the following The data conforms to a data model that is defined by the following
YANG library specification [RFC7895]: 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": "2017-12-11", "revision": "2017-12-20",
"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": "2017-12-11", "revision": "2017-12-20",
"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": "2017-12-11", "revision": "2017-12-20",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing-3", "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing-3",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-interfaces", "name": "ietf-interfaces",
"revision": "2017-08-17", "revision": "2017-12-16",
"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"
}, },
{ {
skipping to change at page 65, line 21 skipping to change at page 68, line 33
"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": "", "revision": "",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ip", "name": "ietf-ip",
"revision": "2014-06-16", "revision": "2017-12-16",
"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"
skipping to change at page 72, line 12 skipping to change at page 75, line 12
<next-hop> <next-hop>
<outgoing-interface>eth0</outgoing-interface> <outgoing-interface>eth0</outgoing-interface>
</next-hop> </next-hop>
<route-preference>0</route-preference> <route-preference>0</route-preference>
<source-protocol>ietf-routing:direct</source-protocol> <source-protocol>ietf-routing:direct</source-protocol>
<last-updated>2015-10-24T17:11:27+02:00</last-updated> <last-updated>2015-10-24T17:11:27+02:00</last-updated>
</route> </route>
<route> <route>
<ietf-ipv4-unicast-routing:destination-prefix> <ietf-ipv4-unicast-routing:destination-prefix>
98.51.100.0/24 198.51.100.0/24
</ietf-ipv4-unicast-routing:destination-prefix> </ietf-ipv4-unicast-routing:destination-prefix>
<next-hop> <next-hop>
<outgoing-interface>eth1</outgoing-interface> <outgoing-interface>eth1</outgoing-interface>
</next-hop> </next-hop>
<route-preference>0</route-preference> <route-preference>0</route-preference>
<source-protocol>ietf-routing:direct</source-protocol> <source-protocol>ietf-routing:direct</source-protocol>
<last-updated>2015-10-24T17:11:27+02:00</last-updated> <last-updated>2015-10-24T17:11:27+02:00</last-updated>
</route> </route>
<route> <route>
<ietf-ipv4-unicast-routing:destination-prefix>0.0.0.0/0 <ietf-ipv4-unicast-routing:destination-prefix>0.0.0.0/0
skipping to change at page 73, line 38 skipping to change at page 76, line 38
</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, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini,
David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane
Litkowski, Thomas Morin, Tom Petch, Yingzhen Qu, Bruno Rijsman, Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman,
Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang,
Derek Man-Kit Yeung, Jeffrey Zhang, Vladimir Vassilev, and Rob Wilton Derek Man-Kit Yeung, Jeffrey Zhang, Vladimir Vassilev, and Rob Wilton
for their helpful comments and suggestions. for their 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
Futurewei Technologies, Inc. Huawei
2330 Central Expressway 2330 Central Expressway
Santa Clara CA 95050 Santa Clara CA 95050
USA USA
EMail: yingzhen.qu@huawei.com EMail: yingzhen.qu@huawei.com
 End of changes. 87 change blocks. 
277 lines changed or deleted 429 lines changed or added

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