draft-ietf-netmod-routing-cfg-20.txt | draft-ietf-netmod-routing-cfg-21.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: April 18, 2016 Cisco Systems | Expires: September 10, 2016 Cisco Systems | |||
October 16, 2015 | March 17, 2016 | |||
A YANG Data Model for Routing Management | A YANG Data Model for Routing Management | |||
draft-ietf-netmod-routing-cfg-20 | draft-ietf-netmod-routing-cfg-21 | |||
Abstract | Abstract | |||
This document contains a specification of three YANG modules. | This document contains a specification of three YANG modules and one | |||
Together they form the core routing data model which serves as a | submodule. Together they form the core routing data model which | |||
framework for configuring and managing a routing subsystem. It is | serves as a framework for configuring and managing a routing | |||
expected that these modules will be augmented by additional YANG | subsystem. It is expected that these modules will be augmented by | |||
modules defining data models for routing protocols, route filters and | additional YANG modules defining data models for routing protocols, | |||
other functions. The core routing data model provides common | route filters and other functions. The core routing data model | |||
building blocks for such extensions - routing instances, routes, | provides common building blocks for such extensions - routes, routing | |||
routing information bases (RIB), and routing protocols. | information bases (RIB), and routing protocols. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on April 18, 2016. | This Internet-Draft will expire on September 10, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 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 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 | 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 | |||
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 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 . . . 8 | 4.1. System-Controlled and User-Controlled List Entries . . . 8 | |||
5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 8 | 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 9 | |||
5.1. Routing Instance . . . . . . . . . . . . . . . . . . . . 8 | 5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.1.1. Parameters of IPv6 Router Interfaces . . . . . . . . 9 | 5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9 | |||
5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.3. Routing Protocol . . . . . . . . . . . . . . . . . . . . 10 | |||
5.3. Routing Information Base (RIB) . . . . . . . . . . . . . 11 | 5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10 | |||
5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 11 | 5.3.2. Defining New Routing Protocols . . . . . . . . . . . 11 | |||
5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 12 | 5.4. RPC Operations . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.4.2. Defining New Routing Protocols . . . . . . . . . . . 12 | 5.5. Parameters of IPv6 Router Advertisements . . . . . . . . 12 | |||
5.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 13 | ||||
6. Interactions with Other YANG Modules . . . . . . . . . . . . 13 | 6. Interactions with Other YANG Modules . . . . . . . . . . . . 13 | |||
6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 13 | 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 13 | |||
6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 | 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Routing Management YANG Module . . . . . . . . . . . . . . . 14 | 7. Routing Management YANG Module . . . . . . . . . . . . . . . 14 | |||
8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 29 | 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 25 | |||
9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 33 | 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 30 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 | 9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 34 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 | |||
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 48 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 49 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 46 | |||
Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 49 | 13.2. Informative References . . . . . . . . . . . . . . . . . 47 | |||
A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 49 | Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 48 | |||
A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 48 | ||||
A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 50 | A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 50 | |||
Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 51 | Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 50 | |||
Appendix C. Example: Adding a New Routing Protocol . . . . . . . 52 | Appendix C. Example: Adding a New Routing Protocol . . . . . . . 51 | |||
Appendix D. Example: NETCONF <get> Reply . . . . . . . . . . . . 54 | Appendix D. Example: NETCONF <get> Reply . . . . . . . . . . . . 53 | |||
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 61 | Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 59 | |||
E.1. Changes Between Versions -19 and -20 . . . . . . . . . . 61 | E.1. Changes Between Versions -20 and -21 . . . . . . . . . . 59 | |||
E.2. Changes Between Versions -18 and -19 . . . . . . . . . . 61 | E.2. Changes Between Versions -19 and -20 . . . . . . . . . . 60 | |||
E.3. Changes Between Versions -17 and -18 . . . . . . . . . . 61 | E.3. Changes Between Versions -18 and -19 . . . . . . . . . . 60 | |||
E.4. Changes Between Versions -16 and -17 . . . . . . . . . . 62 | E.4. Changes Between Versions -17 and -18 . . . . . . . . . . 60 | |||
E.5. Changes Between Versions -15 and -16 . . . . . . . . . . 62 | E.5. Changes Between Versions -16 and -17 . . . . . . . . . . 61 | |||
E.6. Changes Between Versions -14 and -15 . . . . . . . . . . 63 | E.6. Changes Between Versions -15 and -16 . . . . . . . . . . 61 | |||
E.7. Changes Between Versions -13 and -14 . . . . . . . . . . 63 | E.7. Changes Between Versions -14 and -15 . . . . . . . . . . 62 | |||
E.8. Changes Between Versions -12 and -13 . . . . . . . . . . 63 | E.8. Changes Between Versions -13 and -14 . . . . . . . . . . 62 | |||
E.9. Changes Between Versions -11 and -12 . . . . . . . . . . 64 | E.9. Changes Between Versions -12 and -13 . . . . . . . . . . 62 | |||
E.10. Changes Between Versions -10 and -11 . . . . . . . . . . 64 | E.10. Changes Between Versions -11 and -12 . . . . . . . . . . 63 | |||
E.11. Changes Between Versions -09 and -10 . . . . . . . . . . 65 | E.11. Changes Between Versions -10 and -11 . . . . . . . . . . 63 | |||
E.12. Changes Between Versions -08 and -09 . . . . . . . . . . 65 | E.12. Changes Between Versions -09 and -10 . . . . . . . . . . 63 | |||
E.13. Changes Between Versions -07 and -08 . . . . . . . . . . 65 | E.13. Changes Between Versions -08 and -09 . . . . . . . . . . 64 | |||
E.14. Changes Between Versions -06 and -07 . . . . . . . . . . 65 | E.14. Changes Between Versions -07 and -08 . . . . . . . . . . 64 | |||
E.15. Changes Between Versions -05 and -06 . . . . . . . . . . 66 | E.15. Changes Between Versions -06 and -07 . . . . . . . . . . 64 | |||
E.16. Changes Between Versions -04 and -05 . . . . . . . . . . 66 | E.16. Changes Between Versions -05 and -06 . . . . . . . . . . 64 | |||
E.17. Changes Between Versions -03 and -04 . . . . . . . . . . 67 | E.17. Changes Between Versions -04 and -05 . . . . . . . . . . 65 | |||
E.18. Changes Between Versions -02 and -03 . . . . . . . . . . 67 | E.18. Changes Between Versions -03 and -04 . . . . . . . . . . 66 | |||
E.19. Changes Between Versions -01 and -02 . . . . . . . . . . 68 | E.19. Changes Between Versions -02 and -03 . . . . . . . . . . 66 | |||
E.20. Changes Between Versions -00 and -01 . . . . . . . . . . 68 | E.20. Changes Between Versions -01 and -02 . . . . . . . . . . 67 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 | E.21. Changes Between Versions -00 and -01 . . . . . . . . . . 67 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 | ||||
1. Introduction | 1. Introduction | |||
This document contains a specification of the following YANG modules: | This document contains a specification of the following YANG modules: | |||
o Module "ietf-routing" provides generic components of a routing | o Module "ietf-routing" provides generic components of a routing | |||
data model. | data model. | |||
o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" | o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" | |||
module with additional data specific to IPv4 unicast. | module with additional data specific to IPv4 unicast. | |||
o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" | o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" | |||
module with additional data specific to IPv6 unicast. It also | module with additional data specific to IPv6 unicast. Its | |||
augments the "ietf-interfaces" module [RFC7223] with IPv6 router | submodule "ietf-ipv6-router-advertisements" also augments the | |||
configuration variables required by [RFC4861]. | "ietf-interfaces" module [RFC7223] 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 | |||
routing protocols, multicast routing, additional address families, | routing protocols, multicast routing, additional address families, | |||
and advanced functions such as route filtering or policy routing. To | and advanced functions such as route filtering or policy routing. To | |||
this end, it is expected that the core routing data model will be | this end, it is expected that the core routing data model will be | |||
skipping to change at page 5, line 6 ¶ | skipping to change at page 5, line 14 ¶ | |||
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.3 for | routes together with other information. See Section 5.2 for | |||
details. | details. | |||
system-controlled entry: An entry of a list in state data ("config | system-controlled entry: An entry of a list in state data ("config | |||
false") that is created by the system independently of what has | false") that is created by the system independently of what has | |||
been explicitly configured. See Section 4.1 for details. | been explicitly configured. See Section 4.1 for details. | |||
user-controlled entry: An entry of a list in state data ("config | user-controlled entry: An entry of a list in state data ("config | |||
false") that is created and deleted as a direct consequence of | false") that is created and deleted as a direct consequence of | |||
certain configuration changes. See Section 4.1 for details. | certain configuration changes. See Section 4.1 for details. | |||
skipping to change at page 6, line 45 ¶ | skipping to change at page 7, line 7 ¶ | |||
redistributions of routing information. | redistributions of routing information. | |||
o Device vendors will want to map the data models built on this | o Device vendors will want to map the data models built on this | |||
generic framework to their proprietary data models and | generic framework to their proprietary data models and | |||
configuration interfaces. Therefore, the framework should be | configuration interfaces. Therefore, the framework should be | |||
flexible enough to facilitate such a mapping and accommodate data | flexible enough to facilitate such a mapping and accommodate data | |||
models with different logic. | models with different logic. | |||
4. The Design of the Core Routing Data Model | 4. The Design of the Core Routing Data Model | |||
The core routing data model consists of three YANG modules. The | The core routing data model consists of three YANG modules and one | |||
first module, "ietf-routing", defines the generic components of a | submodule. The first module, "ietf-routing", defines the generic | |||
routing system. The other two modules, "ietf-ipv4-unicast-routing" | components of a routing system. The other two modules, "ietf-ipv4- | |||
and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module | unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- | |||
with additional data nodes that are needed for IPv4 and IPv6 unicast | routing" module with additional data nodes that are needed for IPv4 | |||
routing, respectively. Figures 1 and 2 show abridged views of the | and IPv6 unicast routing, respectively. Module "ietf-ipv6-unicast- | |||
routing" has a submodule, "ietf-ipv6-router-advertisements", that | ||||
defines configuration variables for IPv6 router advertisements as | ||||
required by [RFC4861]. Figures 1 and 2 show abridged views of the | ||||
configuration and state data hierarchies. See Appendix A for the | configuration and state data hierarchies. See Appendix A for the | |||
complete data trees. | complete data trees. | |||
+--rw routing | +--rw routing | |||
+--rw routing-instance* [name] | +--rw router-id? | |||
+--rw name | +--rw routing-protocols | |||
+--rw type? | | +--rw routing-protocol* [type name] | |||
+--rw enabled? | | +--rw type | |||
+--rw router-id? | | +--rw name | |||
+--rw description? | | +--rw description? | |||
+--rw routing-protocols | | +--rw static-routes | |||
| +--rw routing-protocol* [type name] | | | +--rw v6ur:ipv6 | |||
| +--rw type | | | | ... | |||
| +--rw name | | | +--rw v4ur:ipv4 | |||
| +--rw description? | | | ... | |||
| +--rw static-routes | | +--rw rip:rip! | |||
| ... | | +--rw rip:interfaces | |||
+--rw ribs | | | ... | |||
+--rw rib* [name] | | +--rw rip:update-interval? | |||
+--rw name | +--rw ribs | |||
+--rw address-family? | +--rw rib* [name] | |||
+--rw description? | +--rw name | |||
+--rw address-family? | ||||
+--rw description? | ||||
Figure 1: Configuration data hierarchy. | Figure 1: Configuration data hierarchy. | |||
+--ro routing-state | +--ro routing-state | |||
+--ro routing-instance* [name] | +--ro router-id? | |||
+--ro name | +--ro interfaces | |||
+--ro type? | | +--ro interface* | |||
+--ro router-id? | +--ro routing-protocols | |||
+--ro interfaces | | +--ro routing-protocol* [type name] | |||
| +--ro interface* | | +--ro type | |||
+--ro routing-protocols | | +--ro name | |||
| +--ro routing-protocol* [type name] | +--ro ribs | |||
| +--ro type | +--ro rib* [name] | |||
| +--ro name | +--ro name | |||
+--ro ribs | +--ro address-family | |||
+--ro rib* [name] | +--ro default-rib? | |||
+--ro name | +--ro routes | |||
+--ro address-family | +--ro route* | |||
+--ro default-rib? | ||||
+--ro routes | ||||
... | ... | |||
Figure 2: State data hierarchy. | Figure 2: State data hierarchy. | |||
As can be seen from Figures 1 and 2, the core routing data model | As can be seen from Figures 1 and 2, the core routing data model | |||
introduces several generic components of a routing framework: routing | introduces several generic components of a routing framework: routes, | |||
instances, RIBs containing lists of routes, and routing protocols. | RIBs containing lists of routes, and routing protocols. Section 5 | |||
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, | |||
for example "routing-instance" or "rib", that have to be populated | such as "rib", that have to be populated with at least one entry in | |||
with at least one entry in any properly functioning device, and | any properly functioning device, and additional entries may be | |||
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, i.e., inside the "routing- | system-controlled entry in state data, i.e., inside the "routing- | |||
state" container. | state" container. | |||
An example can be seen in Appendix D: the "/routing-state/ribs/rib" | ||||
list has two system-controlled entries named "ipv4-master" and | ||||
"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 state data and | Corresponding entries in both versions of the list (in state data and | |||
configuration) have the same value of the list key. | configuration) 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, the key of the | to the corresponding entry in the state data list, 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 | |||
state entry. | state entry. | |||
An example can be seen in Appendix D: the "/routing-state/routing- | ||||
instance" list has a single system-controlled entry whose "name" key | ||||
has the value "rtr0". This entry is configured by the "/routing/ | ||||
routing-instance" entry whose "name" key is also "rtr0". | ||||
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 a system-controlled entry is deleted from the | contrast, if a system-controlled entry is deleted from the | |||
configuration list, only the extra configuration specified in that | configuration list, only the extra configuration specified in that | |||
entry is removed but the corresponding state data entry remains in | entry is removed but the corresponding state data entry remains in | |||
the list. | the list. | |||
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. Routing Instance | 5.1. Route | |||
The core routing data model supports one or more routing instances | ||||
appearing as entries of the "routing-instance" list. Each routing | ||||
instance has separate configuration and state data under | ||||
"/rt:routing/rt:routing-instance" and "/rt:routing-state/rt:routing- | ||||
instance", respectively. | ||||
No attempt has been made to define the semantics for every type of | ||||
routing instance. The core routing data model defines identities for | ||||
two ubiquitous routing instance types: | ||||
o "default-routing-instance" - this routing instance type represents | ||||
the default (or only) routing instance. All implementations MUST | ||||
provide one and only one system-controlled routing instance of | ||||
this type. | ||||
o "vrf-routing-instance" - this routing instance type represents VRF | ||||
(virtual routing and forwarding) routing instances that are used | ||||
for virtual private networks (VPN) including BGP/MPLS | ||||
VPN_[RFC4364]. | ||||
It is expected that future YANG modules will define other types of | ||||
routing instances. For every such type, an identity derived from | ||||
"rt:routing-instance" SHALL be defined. This identity is then | ||||
referred to by the value of the "type" leaf (a child node of | ||||
"routing-instance" list). | ||||
By default, all network layer interfaces are assigned to the routing | ||||
instance of the "default-routing-instance" type. This can be changed | ||||
by configuring the "rt:routing-instance" leaf in the interface | ||||
configuration. | ||||
5.1.1. Parameters of IPv6 Router Interfaces | ||||
YANG module "ietf-ipv6-unicast-routing" (Section 9) augments the | ||||
configuration and state data of IPv6 interfaces with definitions of | ||||
the following variables as required by [RFC4861], sec. 6.2.1: | ||||
o send-advertisements, | ||||
o max-rtr-adv-interval, | ||||
o min-rtr-adv-interval, | ||||
o managed-flag, | ||||
o other-config-flag, | ||||
o link-mtu, | ||||
o reachable-time, | ||||
o retrans-timer, | ||||
o cur-hop-limit, | ||||
o default-lifetime, | ||||
o prefix-list: a list of prefixes to be advertised. | ||||
The following parameters are associated with each prefix in the | ||||
list: | ||||
* valid-lifetime, | ||||
* on-link-flag, | ||||
* preferred-lifetime, | ||||
* autonomous-flag. | ||||
NOTES: | ||||
1. The "IsRouter" flag, which is also required by [RFC4861], is | ||||
implemented in the "ietf-ip" module [RFC7277] (leaf | ||||
"ip:forwarding"). | ||||
2. The original specification [RFC4861] allows the implementations | ||||
to decide whether the "valid-lifetime" and "preferred-lifetime" | ||||
parameters remain the same in consecutive advertisements, or | ||||
decrement in real time. However, the latter behavior seems | ||||
problematic because the values might be reset again to the | ||||
(higher) configured values after a configuration is reloaded. | ||||
Moreover, no implementation is known to use the decrementing | ||||
behavior. The "ietf-ipv6-unicast-routing" module therefore | ||||
assumes the former behavior with constant values. | ||||
5.2. Route | ||||
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": IP prefix specifying the set of destination | o "destination-prefix": IP prefix specifying the set of destination | |||
addresses for which the route may be used. This attribute is | addresses for which the route may be used. This attribute is | |||
mandatory. | mandatory. | |||
o "route-preference": an integer value (also known as administrative | o "route-preference": an integer value (also known as administrative | |||
distance) that is used for selecting a preferred route among | distance) that is used for selecting a preferred route among | |||
routes with the same destination prefix. A lower value means a | routes with the same destination prefix. A lower value means a | |||
more preferred route. | more preferred route. | |||
o "next-hop": determines the action to be performed with a packet. | o "next-hop": determines the action to be performed with a packet. | |||
Routes are primarily state data that appear as entries of RIBs | Routes are primarily state data that appear as entries of RIBs | |||
(Section 5.3) but they may also be found in configuration data, for | (Section 5.2) but they may also be found in configuration data, for | |||
example as manually configured static routes. In the latter case, | example as manually configured static routes. In the latter case, | |||
configurable route attributes are generally a subset of route | configurable route attributes are generally a subset of route | |||
attributes described above. | attributes described above. | |||
5.3. Routing Information Base (RIB) | 5.2. Routing Information Base (RIB) | |||
Every routing instance manages one or more routing information bases | Every implementation of the core routing data model manages one or | |||
(RIB). A RIB is a list of routes complemented with administrative | more routing information bases (RIB). A RIB is a list of routes | |||
data. Each RIB contains only routes of one address family. An | complemented with administrative data. Each RIB contains only routes | |||
address family is represented by an identity derived from the | of one address family. An address family is represented by an | |||
"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-state/routing-instance/ribs/rib". The | entries of the list "/routing-state/ribs/rib". The contents of RIBs | |||
contents of RIBs are controlled and manipulated by routing protocol | are controlled and manipulated by routing protocol operations which | |||
operations which may result in route additions, removals and | may result in route additions, removals and modifications. This also | |||
modifications. This also includes manipulations via the "static" | includes manipulations via the "static" and/or "direct" pseudo- | |||
and/or "direct" pseudo-protocols, see Section 5.4.1. | protocols, see Section 5.3.1. | |||
Each routing instance has, for every supported address family, one | For every supported address family, exactly one RIB MUST be marked as | |||
RIB marked as the so-called default RIB. Its role is explained in | the so-called default RIB. Its role is explained in Section 5.3. | |||
Section 5.4. | ||||
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 | |||
routing instance and supported address family, and mark it as the | supported address family, and mark it as the default RIB. | |||
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. | |||
5.4. Routing Protocol | 5.3. Routing 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 routing protocol instances within a routing | defining multiple routing protocol instances. Each routing protocol | |||
instance. Each routing protocol instance MUST be assigned a type, | instance MUST be assigned a type, which is an identity derived from | |||
which is an identity derived from the "rt:routing-protocol" base | the "rt:routing-protocol" base identity. The core routing data model | |||
identity. The core routing data model defines two identities for the | defines two identities for the direct and static pseudo-protocols | |||
direct and static pseudo-protocols (Section 5.4.1). | (Section 5.3.1). | |||
Multiple routing protocol instances of the same type MAY be | Multiple routing protocol instances of the same type MAY be | |||
configured within the same routing instance. | configured. | |||
5.4.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 they are confined to the local device and do not exchange | which means they are confined to the local device and do not exchange | |||
any routing information with adjacent routers. | any routing information with adjacent routers. | |||
Every routing instance MUST implement exactly one instance of the | Every implementation of the core routing data model MUST provide | |||
"direct" pseudo-protocol type. It is the source of direct routes for | exactly one instance of the "direct" pseudo-protocol type. It is the | |||
all configured address families. Direct routes are normally supplied | source of direct routes for all configured address families. Direct | |||
by the operating system kernel, based on the configuration of network | routes are normally supplied by the operating system kernel, based on | |||
interface addresses, see Section 6.2. Direct routes MUST be | the configuration of network interface addresses, see Section 6.2. | |||
installed in default RIBs of all supported address families. | Direct routes MUST be installed in default RIBs of all supported | |||
address families. | ||||
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 per | although a typical configuration will have exactly one instance. | |||
routing instance. | ||||
5.4.2. Defining New Routing Protocols | 5.3.2. Defining New Routing Protocols | |||
It is expected that future YANG modules will create data models for | It is expected that future YANG modules will create data models for | |||
additional routing protocol types. Such a new module has to define | additional routing protocol types. Such a new module has to define | |||
the protocol-specific configuration and state data, and it has to fit | the protocol-specific configuration and state data, and it has to | |||
it into the core routing framework in the following way: | integrate it into the core routing framework in the following way: | |||
o A new identity MUST be defined for the routing protocol and its | o A new identity MUST be defined for the routing protocol and its | |||
base identity MUST be set to "rt:routing-protocol", or to an | base identity MUST be set to "rt:routing-protocol", or to an | |||
identity derived from "rt:routing-protocol". | identity derived from "rt:routing-protocol". | |||
o Additional route attributes MAY be defined, preferably in one | o Additional route attributes MAY be defined, preferably in one | |||
place by means of defining a YANG grouping. The new attributes | place by means of defining a YANG grouping. The new attributes | |||
have to be inserted by augmenting the definitions of the nodes | have to be inserted by augmenting the definitions of the nodes | |||
/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route | /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route | |||
skipping to change at page 13, line 22 ¶ | skipping to change at page 12, line 5 ¶ | |||
protocol" is equal to the new protocol's identity. | protocol" is equal to 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 | |||
RIP routing protocol in Appendix C. | RIP routing protocol in Appendix C. | |||
5.5. RPC Operations | 5.4. RPC Operations | |||
The "ietf-routing" module defines one RPC operation: | The "ietf-routing" module defines one RPC operation: | |||
o fib-route: query a routing instance for the active route in the | o fib-route: query the routing system for the active route in the | |||
Forwarding Information Base (FIB). It is the route that is | Forwarding Information Base (FIB). It is the route that is | |||
currently used for sending datagrams to a destination host whose | currently used for sending datagrams to a destination host whose | |||
address is passed as an input parameter. | address is passed as the input parameter. | |||
5.5. Parameters of IPv6 Router Advertisements | ||||
YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is | ||||
a submodule of the "ietf-ipv6-unicast-routing" module, augments the | ||||
configuration and state data of IPv6 interfaces with definitions of | ||||
the following variables as required by [RFC4861], sec. 6.2.1: | ||||
o send-advertisements, | ||||
o max-rtr-adv-interval, | ||||
o min-rtr-adv-interval, | ||||
o managed-flag, | ||||
o other-config-flag, | ||||
o link-mtu, | ||||
o reachable-time, | ||||
o retrans-timer, | ||||
o cur-hop-limit, | ||||
o default-lifetime, | ||||
o prefix-list: a list of prefixes to be advertised. | ||||
The following parameters are associated with each prefix in the | ||||
list: | ||||
* valid-lifetime, | ||||
* on-link-flag, | ||||
* preferred-lifetime, | ||||
* autonomous-flag. | ||||
NOTES: | ||||
1. The "IsRouter" flag, which is also required by [RFC4861], is | ||||
implemented in the "ietf-ip" module [RFC7277] (leaf | ||||
"ip:forwarding"). | ||||
2. The original specification [RFC4861] allows the implementations | ||||
to decide whether the "valid-lifetime" and "preferred-lifetime" | ||||
parameters remain the same in consecutive advertisements, or | ||||
decrement in real time. However, the latter behavior seems | ||||
problematic because the values might be reset again to the | ||||
(higher) configured values after a configuration is reloaded. | ||||
Moreover, no implementation is known to use the decrementing | ||||
behavior. The "ietf-ipv6-unicast-routing" module therefore | ||||
assumes the former behavior with constant values. | ||||
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 [RFC7223]: | |||
skipping to change at page 14, line 42 ¶ | skipping to change at page 14, line 34 ¶ | |||
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 | |||
RFC Editor: In this section, replace all occurrences of 'XXXX' with | RFC Editor: In this section, replace all occurrences of 'XXXX' with | |||
the actual RFC number and all occurrences of the revision date below | the actual RFC number and all occurrences of the revision date below | |||
with the date of RFC publication (and remove this note). | with the date of RFC publication (and remove this note). | |||
<CODE BEGINS> file "ietf-routing@2015-10-16.yang" | <CODE BEGINS> file "ietf-routing@2016-03-09.yang" | |||
module ietf-routing { | module ietf-routing { | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; | namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; | |||
prefix "rt"; | prefix "rt"; | |||
import ietf-yang-types { | import ietf-yang-types { | |||
prefix "yang"; | prefix "yang"; | |||
} | } | |||
import ietf-interfaces { | import ietf-interfaces { | |||
prefix "if"; | prefix "if"; | |||
} | } | |||
organization | organization | |||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | |||
contact | contact | |||
skipping to change at page 15, line 18 ¶ | skipping to change at page 15, line 9 ¶ | |||
prefix "if"; | prefix "if"; | |||
} | } | |||
organization | organization | |||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | |||
contact | contact | |||
"WG Web: <http://tools.ietf.org/wg/netmod/> | "WG Web: <http://tools.ietf.org/wg/netmod/> | |||
WG List: <mailto:netmod@ietf.org> | WG List: <mailto:netmod@ietf.org> | |||
WG Chair: Thomas Nadeau | WG Chair: Lou Berger | |||
<mailto:tnadeau@lucidvision.com> | <mailto:lberger@labn.net> | |||
WG Chair: Juergen Schoenwaelder | WG Chair: Juergen Schoenwaelder | |||
<mailto:j.schoenwaelder@jacobs-university.de> | <mailto:j.schoenwaelder@jacobs-university.de> | |||
WG Chair: Kent Watsen | WG Chair: Kent Watsen | |||
<mailto:kwatsen@juniper.net> | <mailto:kwatsen@juniper.net> | |||
Editor: Ladislav Lhotka | Editor: Ladislav Lhotka | |||
<mailto:lhotka@nic.cz>"; | <mailto:lhotka@nic.cz> | |||
Editor: Acee Lindem | ||||
<mailto:acee@cisco.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. | |||
Copyright (c) 2015 IETF Trust and the persons identified as | Copyright (c) 2016 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject to | without modification, is permitted pursuant to, and subject to | |||
the license terms contained in, the Simplified BSD License set | the license terms contained in, the Simplified BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info). | |||
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | |||
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and | NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and | |||
'OPTIONAL' in the module text are to be interpreted as described | 'OPTIONAL' in the module text are to be interpreted as described | |||
in RFC 2119 (http://tools.ietf.org/html/rfc2119). | in RFC 2119 (http://tools.ietf.org/html/rfc2119). | |||
This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC XXXX | |||
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for | (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for | |||
full legal notices."; | full legal notices."; | |||
revision 2015-10-16 { | revision 2016-03-09 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: A YANG Data Model for Routing Management"; | "RFC XXXX: 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 user-defined | |||
RIBs. | 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 routing-instance and | exactly one system-controlled RIB per supported address family | |||
supported address family and make them also the default RIBs. | and make them also the default RIBs. These RIBs then appear as | |||
These RIBs then appear as entries of the list | entries of the list /routing-state/ribs/rib."; | |||
/routing-state/routing-instance/ribs/rib."; | ||||
} | } | |||
feature router-id { | feature router-id { | |||
description | description | |||
"This feature indicates that the server supports configuration | "This feature indicates that the server supports configuration | |||
of an explicit 32-bit router ID that is used by some routing | of an explicit 32-bit router ID that is used by some routing | |||
protocols. | 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 configured IPv4 addresses. | algorithmically, usually to one of configured IPv4 addresses. | |||
skipping to change at page 17, line 8 ¶ | skipping to change at page 16, line 48 ¶ | |||
description | description | |||
"This identity represents IPv4 address family."; | "This identity represents IPv4 address family."; | |||
} | } | |||
identity ipv6 { | identity ipv6 { | |||
base address-family; | base address-family; | |||
description | description | |||
"This identity represents IPv6 address family."; | "This identity represents IPv6 address family."; | |||
} | } | |||
identity routing-instance { | ||||
description | ||||
"Base identity from which identities describing routing | ||||
instance types are derived."; | ||||
} | ||||
identity default-routing-instance { | ||||
base routing-instance; | ||||
description | ||||
"This identity represents either a default routing instance, or | ||||
the only routing instance on systems that do not support | ||||
multiple instances."; | ||||
} | ||||
identity vrf-routing-instance { | ||||
base routing-instance; | ||||
description | ||||
"This identity represents a VRF routing instance. The type is | ||||
distinct from the default-routing-instance. There may be | ||||
multiple vrf-routing-interfaces."; | ||||
} | ||||
identity routing-protocol { | identity routing-protocol { | |||
description | description | |||
"Base identity from which routing protocol identities are | "Base identity from which routing protocol identities are | |||
derived."; | derived."; | |||
} | } | |||
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 { | |||
skipping to change at page 17, line 51 ¶ | skipping to change at page 17, line 22 ¶ | |||
} | } | |||
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 routing-instance-ref { | ||||
type leafref { | ||||
path "/rt:routing/rt:routing-instance/rt:name"; | ||||
} | ||||
description | ||||
"This type is used for leafs that reference a routing instance | ||||
configuration."; | ||||
} | ||||
typedef routing-instance-state-ref { | ||||
type leafref { | ||||
path "/rt:routing-state/rt:routing-instance/rt:name"; | ||||
} | ||||
description | ||||
"This type is used for leafs that reference state data of a | ||||
routing instance."; | ||||
} | ||||
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 | |||
skipping to change at page 21, line 26 ¶ | skipping to change at page 20, line 26 ¶ | |||
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."; | |||
} | } | |||
} | } | |||
/* State data */ | /* State data */ | |||
augment "/if:interfaces-state/if:interface" { | ||||
description | ||||
"This augment adds a reference to the routing-instance to which | ||||
the interface is assigned."; | ||||
leaf routing-instance { | ||||
type routing-instance-state-ref; | ||||
description | ||||
"The name of the routing instance to which the interface is | ||||
assigned."; | ||||
} | ||||
} | ||||
container routing-state { | container routing-state { | |||
config "false"; | config "false"; | |||
description | description | |||
"State data of the routing subsystem."; | "State data of the routing subsystem."; | |||
list routing-instance { | uses router-id { | |||
key "name"; | ||||
min-elements "1"; | ||||
description | description | |||
"Each list entry is a container for state data of a routing | "Global router ID. | |||
instance. | ||||
An implementation MUST provide one and only one | ||||
system-controlled routing instance(s) of the type | ||||
'rt:default-routing-instance', and MAY support other types. | ||||
An implementation MAY restrict the number of routing | ||||
instances of each supported type."; | ||||
leaf name { | ||||
type string; | ||||
description | ||||
"The name of the routing instance. | ||||
For system-controlled instances the name SHOULD be | It may be either configured or assigned algorithmically by | |||
persistent, i.e., it doesn't change after a reboot."; | the implementation."; | |||
} | } | |||
leaf type { | container interfaces { | |||
type identityref { | description | |||
base routing-instance; | "Network layer interfaces used for routing."; | |||
} | leaf-list interface { | |||
type if:interface-state-ref; | ||||
description | description | |||
"The routing instance type."; | "Each entry is a reference to the name of a configured | |||
network layer interface."; | ||||
} | } | |||
uses router-id { | } | |||
container routing-protocols { | ||||
description | ||||
"Container for the list of routing protocol instances."; | ||||
list routing-protocol { | ||||
key "type name"; | ||||
description | description | |||
"Global router ID. | "State data of a routing protocol instance. | |||
It may be either configured or assigned algorithmically by | An implementation MUST provide exactly one | |||
the implementation."; | system-controlled instance of the type 'direct'. Other | |||
} | instances MAY be created by configuration."; | |||
container interfaces { | leaf type { | |||
description | type identityref { | |||
"Network layer interfaces belonging to the routing | base routing-protocol; | |||
instance."; | ||||
leaf-list interface { | ||||
type if:interface-state-ref; | ||||
must "../../name = /if:interfaces-state/" | ||||
+ "if:interface[if:name=current()]/" | ||||
+ "rt:routing-instance" { | ||||
error-message | ||||
"Routing instance is not assigned to the interface."; | ||||
description | ||||
"This reference must mirror a corresponding assignment | ||||
of the ancestor routing-instance to the interface."; | ||||
} | } | |||
description | description | |||
"Each entry is a reference to the name of a configured | "Type of the routing protocol."; | |||
network layer interface."; | ||||
} | } | |||
} | leaf name { | |||
container routing-protocols { | type string; | |||
description | ||||
"Container for the list of routing protocol instances."; | ||||
list routing-protocol { | ||||
key "type name"; | ||||
description | description | |||
"State data of a routing protocol instance. | "The name of the routing protocol instance. | |||
An implementation MUST provide exactly one | ||||
system-controlled instance of the type 'direct'. Other | ||||
instances MAY be created by configuration."; | ||||
leaf type { | ||||
type identityref { | ||||
base routing-protocol; | ||||
} | ||||
description | ||||
"Type of the routing protocol."; | ||||
} | ||||
leaf name { | ||||
type string; | ||||
description | ||||
"The name of the routing protocol instance. | ||||
For system-controlled instances this name is | For system-controlled instances this name is persistent, | |||
persistent, i.e., it SHOULD NOT change across | i.e., it SHOULD NOT change across reboots."; | |||
reboots."; | ||||
} | ||||
} | } | |||
} | } | |||
container ribs { | } | |||
container ribs { | ||||
description | ||||
"Container for RIBs."; | ||||
list rib { | ||||
key "name"; | ||||
min-elements "1"; | ||||
description | description | |||
"Container for RIBs."; | "Each entry represents a RIB identified by the 'name' key. | |||
list rib { | All routes in a RIB MUST belong to the same address | |||
key "name"; | family. | |||
min-elements "1"; | ||||
description | ||||
"Each entry represents a RIB identified by the 'name' | ||||
key. All routes in a RIB MUST belong to the same address | ||||
family. | ||||
For each routing instance, an implementation SHOULD | An implementation SHOULD provide one system-controlled | |||
provide one system-controlled default RIB for each | default RIB for each supported address family."; | |||
supported address family."; | leaf name { | |||
leaf name { | type string; | |||
type string; | description | |||
description | "The name of the RIB."; | |||
"The name of the RIB."; | } | |||
} | uses address-family; | |||
uses address-family; | leaf default-rib { | |||
leaf default-rib { | if-feature multiple-ribs; | |||
if-feature multiple-ribs; | type boolean; | |||
type boolean; | default "true"; | |||
default "true"; | 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 | is the default RIB for the given address family. | |||
RIB is the default RIB for the given address family. | ||||
A default RIB always receives direct routes. By | A default RIB always receives direct routes. By default | |||
default it also receives routes from all routing | it also receives routes from all routing protocols."; | |||
protocols."; | } | |||
} | container routes { | |||
container routes { | description | |||
"Current content of the RIB."; | ||||
list route { | ||||
description | description | |||
"Current content of the RIB."; | "A RIB route entry. This data node MUST be augmented | |||
list route { | with information specific for routes of each address | |||
family."; | ||||
leaf route-preference { | ||||
type route-preference; | ||||
description | description | |||
"A RIB route entry. This data node MUST be augmented | "This route attribute, also known as administrative | |||
with information specific for routes of each address | distance, allows for selecting the preferred route | |||
family."; | among routes with the same destination prefix. A | |||
leaf route-preference { | smaller value means a more preferred route."; | |||
type route-preference; | } | |||
description | container next-hop { | |||
"This route attribute, also known as administrative | description | |||
distance, allows for selecting the preferred route | "Route's next-hop attribute."; | |||
among routes with the same destination prefix. A | uses next-hop-state-content; | |||
smaller value means a more preferred route."; | ||||
} | ||||
container next-hop { | ||||
description | ||||
"Route's next-hop attribute."; | ||||
uses next-hop-state-content; | ||||
} | ||||
uses route-metadata; | ||||
} | } | |||
uses route-metadata; | ||||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
/* Configuration Data */ | /* Configuration Data */ | |||
augment "/if:interfaces/if:interface" { | ||||
description | ||||
"This augment adds a routing-instance reference to interface | ||||
configuration."; | ||||
leaf routing-instance { | ||||
type routing-instance-ref; | ||||
description | ||||
"The name of the routing instance to which the interface is | ||||
to be assigned. | ||||
By default, all network layer interfaces belong to the | ||||
routing-instance of the 'default-routing-instance' type."; | ||||
} | ||||
} | ||||
container routing { | container routing { | |||
description | description | |||
"Configuration parameters for the routing subsystem."; | "Configuration parameters for the routing subsystem."; | |||
list routing-instance { | uses router-id { | |||
key "name"; | if-feature router-id; | |||
description | description | |||
"Configuration of a routing instance."; | "Configuration of the global router ID. Routing protocols | |||
leaf name { | that use router ID can use this parameter or override it | |||
type string; | with another value."; | |||
description | } | |||
"The name of the routing instance. | container routing-protocols { | |||
description | ||||
For system-controlled entries, the value of this leaf must | "Configuration of routing protocol instances."; | |||
be the same as the name of the corresponding entry in | ||||
state data. | ||||
For user-controlled entries, an arbitrary name can be | ||||
used."; | ||||
} | ||||
leaf type { | ||||
type identityref { | ||||
base routing-instance; | ||||
} | ||||
default "rt:default-routing-instance"; | ||||
description | ||||
"The type of the routing instance."; | ||||
} | ||||
leaf enabled { | ||||
type boolean; | ||||
default "true"; | ||||
description | ||||
"Enable/disable the routing instance. | ||||
If this parameter is false, the parent routing instance is | list routing-protocol { | |||
disabled and does not appear in state data, despite any | key "type name"; | |||
other configuration that might be present."; | ||||
} | ||||
uses router-id { | ||||
if-feature router-id; | ||||
description | ||||
"Configuration of the global router ID. Routing protocols | ||||
that use router ID can use this parameter or override it | ||||
with another value."; | ||||
} | ||||
leaf description { | ||||
type string; | ||||
description | ||||
"Textual description of the routing instance."; | ||||
} | ||||
container routing-protocols { | ||||
description | description | |||
"Configuration of routing protocol instances."; | "Each entry contains configuration of a routing protocol | |||
list routing-protocol { | instance."; | |||
key "type name"; | leaf type { | |||
description | type identityref { | |||
"Each entry contains configuration of a routing protocol | base routing-protocol; | |||
instance."; | ||||
leaf type { | ||||
type identityref { | ||||
base routing-protocol; | ||||
} | ||||
description | ||||
"Type of the routing protocol - an identity derived | ||||
from the 'routing-protocol' base identity."; | ||||
} | ||||
leaf name { | ||||
type string; | ||||
description | ||||
"An arbitrary name of the routing protocol instance."; | ||||
} | } | |||
leaf description { | description | |||
type string; | "Type of the routing protocol - an identity derived from | |||
the 'routing-protocol' base identity."; | ||||
} | ||||
leaf name { | ||||
type string; | ||||
description | ||||
"An arbitrary name of the routing protocol instance."; | ||||
} | ||||
leaf description { | ||||
type string; | ||||
description | ||||
"Textual description of the routing protocol instance."; | ||||
} | ||||
container static-routes { | ||||
when "../type='rt:static'" { | ||||
description | description | |||
"Textual description of the routing protocol | "This container is only valid for the 'static' routing | |||
instance."; | protocol."; | |||
} | } | |||
container static-routes { | description | |||
when "../type='rt:static'" { | "Configuration of the 'static' pseudo-protocol. | |||
description | ||||
"This container is only valid for the 'static' | ||||
routing protocol."; | ||||
} | ||||
description | ||||
"Configuration of the 'static' pseudo-protocol. | ||||
Address-family-specific modules augment this node with | Address-family-specific modules augment this node with | |||
their lists of routes."; | their lists of routes."; | |||
} | ||||
} | } | |||
} | } | |||
container ribs { | } | |||
container ribs { | ||||
description | ||||
"Configuration of RIBs."; | ||||
list rib { | ||||
key "name"; | ||||
description | description | |||
"Configuration of RIBs."; | "Each entry contains configuration for a RIB identified by | |||
list rib { | the 'name' key. | |||
key "name"; | ||||
description | ||||
"Each entry contains configuration for a RIB identified | ||||
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-state/routing-instance/ribs/rib are | of the list /routing-state/ribs/rib are used for | |||
used for configuring parameters of that entry. Other | configuring parameters of that entry. Other entries define | |||
entries define additional user-controlled RIBs."; | 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 | must be the same as the name of the corresponding entry | |||
entry in state data. | in state data. | |||
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 | |||
"Address family of the RIB. | "Address family of the RIB. | |||
It is mandatory for user-controlled RIBs. For | It is mandatory for user-controlled RIBs. For | |||
system-controlled RIBs it can be omitted, otherwise it | system-controlled RIBs it can be omitted, otherwise it | |||
must match the address family of the corresponding | must match the address family of the corresponding state | |||
state entry."; | entry."; | |||
refine "address-family" { | refine "address-family" { | |||
mandatory "false"; | mandatory "false"; | |||
} | ||||
} | ||||
leaf description { | ||||
type string; | ||||
description | ||||
"Textual description of the RIB."; | ||||
} | } | |||
} | } | |||
leaf description { | ||||
type string; | ||||
description | ||||
"Textual description of the RIB."; | ||||
} | ||||
} | } | |||
} | } | |||
} | } | |||
/* RPC operations */ | /* RPC operations */ | |||
rpc fib-route { | rpc fib-route { | |||
description | description | |||
"Return the active FIB route that a routing-instance uses for | "Return the active FIB route that is used for sending packets | |||
sending packets to a destination address."; | to a destination address."; | |||
input { | input { | |||
leaf routing-instance-name { | ||||
type routing-instance-state-ref; | ||||
mandatory "true"; | ||||
description | ||||
"Name of the routing instance whose forwarding information | ||||
base is being queried. | ||||
If the routing instance with name equal to the value of | ||||
this parameter doesn't exist, then this operation SHALL | ||||
fail with error-tag 'data-missing' and error-app-tag | ||||
'routing-instance-not-found'."; | ||||
} | ||||
container destination-address { | container destination-address { | |||
description | description | |||
"Network layer destination address. | "Network layer destination address. | |||
Address family specific modules MUST augment this | Address family specific modules MUST augment this | |||
container with a leaf named 'address'."; | container with a leaf named 'address'."; | |||
uses address-family; | uses address-family; | |||
} | } | |||
} | } | |||
output { | output { | |||
container route { | container route { | |||
description | description | |||
"The active FIB route for the specified destination. | "The active FIB route for the specified destination. | |||
If the routing instance has no active FIB route for the | If no active FIB route exists for the destination address, | |||
destination address, no output is returned - the server | no output is returned - the server SHALL send an | |||
SHALL send an <rpc-reply> containing a single element | <rpc-reply> containing a single element <ok>. | |||
<ok>. | ||||
Address family specific modules MUST augment this list | Address family specific modules MUST augment this list | |||
with appropriate route contents."; | with appropriate route contents."; | |||
uses address-family; | uses address-family; | |||
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; | |||
skipping to change at page 29, line 17 ¶ | skipping to change at page 25, line 39 ¶ | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
8. IPv4 Unicast Routing Management YANG Module | 8. IPv4 Unicast Routing Management YANG Module | |||
RFC Editor: In this section, replace all occurrences of 'XXXX' with | RFC Editor: In this section, replace all occurrences of 'XXXX' with | |||
the actual RFC number and all occurrences of the revision date below | the actual RFC number and all occurrences of the revision date below | |||
with the date of RFC publication (and remove this note). | with the date of RFC publication (and remove this note). | |||
<CODE BEGINS> file "ietf-ipv4-unicast-routing@2015-10-16.yang" | <CODE BEGINS> file "ietf-ipv4-unicast-routing@2016-03-09.yang" | |||
module ietf-ipv4-unicast-routing { | module ietf-ipv4-unicast-routing { | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; | namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; | |||
prefix "v4ur"; | prefix "v4ur"; | |||
import ietf-routing { | import ietf-routing { | |||
prefix "rt"; | prefix "rt"; | |||
} | } | |||
skipping to change at page 29, line 31 ¶ | skipping to change at page 26, line 4 ¶ | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; | namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; | |||
prefix "v4ur"; | prefix "v4ur"; | |||
import ietf-routing { | import ietf-routing { | |||
prefix "rt"; | prefix "rt"; | |||
} | } | |||
import ietf-inet-types { | import ietf-inet-types { | |||
prefix "inet"; | prefix "inet"; | |||
} | } | |||
organization | organization | |||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | |||
contact | contact | |||
"WG Web: <http://tools.ietf.org/wg/netmod/> | "WG Web: <http://tools.ietf.org/wg/netmod/> | |||
WG List: <mailto:netmod@ietf.org> | WG List: <mailto:netmod@ietf.org> | |||
WG Chair: Thomas Nadeau | WG Chair: Lou Berger | |||
<mailto:tnadeau@lucidvision.com> | <mailto:lberger@labn.net> | |||
WG Chair: Juergen Schoenwaelder | WG Chair: Juergen Schoenwaelder | |||
<mailto:j.schoenwaelder@jacobs-university.de> | <mailto:j.schoenwaelder@jacobs-university.de> | |||
WG Chair: Kent Watsen | WG Chair: Kent Watsen | |||
<mailto:kwatsen@juniper.net> | <mailto:kwatsen@juniper.net> | |||
Editor: Ladislav Lhotka | Editor: Ladislav Lhotka | |||
<mailto:lhotka@nic.cz>"; | <mailto:lhotka@nic.cz> | |||
Editor: Acee Lindem | ||||
<mailto:acee@cisco.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. | |||
Copyright (c) 2015 IETF Trust and the persons identified as | Copyright (c) 2016 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject to | without modification, is permitted pursuant to, and subject to | |||
the license terms contained in, the Simplified BSD License set | the license terms contained in, the Simplified BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info). | |||
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | |||
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and | NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and | |||
'OPTIONAL' in the module text are to be interpreted as described | 'OPTIONAL' in the module text are to be interpreted as described | |||
in RFC 2119 (http://tools.ietf.org/html/rfc2119). | in RFC 2119 (http://tools.ietf.org/html/rfc2119). | |||
This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC XXXX | |||
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for | (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for | |||
full legal notices."; | full legal notices."; | |||
revision 2015-10-16 { | revision 2016-03-09 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: A YANG Data Model for Routing Management"; | "RFC XXXX: A YANG Data Model for Routing Management"; | |||
} | } | |||
/* Identities */ | /* Identities */ | |||
identity ipv4-unicast { | identity ipv4-unicast { | |||
base rt:ipv4; | base rt:ipv4; | |||
description | description | |||
"This identity represents the IPv4 unicast address family."; | "This identity represents the IPv4 unicast address family."; | |||
} | } | |||
/* State data */ | /* State data */ | |||
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" | augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { | |||
+ "rt:routes/rt:route" { | ||||
when "../../rt:address-family = 'v4ur:ipv4-unicast'" { | when "../../rt:address-family = '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 an IPv4 unicast route."; | "This leaf augments an IPv4 unicast route."; | |||
leaf destination-prefix { | leaf destination-prefix { | |||
type inet:ipv4-prefix; | type inet:ipv4-prefix; | |||
description | description | |||
"IPv4 destination prefix."; | "IPv4 destination prefix."; | |||
} | } | |||
} | } | |||
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" | augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" | |||
+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options" { | + "rt:next-hop/rt:next-hop-options" { | |||
when "../../../rt:address-family = 'v4ur:ipv4-unicast'" { | when "../../../rt:address-family = '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-options' in IPv4 unicast routes."; | "Augment 'next-hop-options' 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."; | |||
} | } | |||
} | } | |||
/* Configuration data */ | /* Configuration data */ | |||
augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" | augment "/rt:routing/rt:routing-protocols/rt:routing-protocol/" | |||
+ "rt:routing-protocol/rt:static-routes" { | + "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 IPv4 unicast."; | pseudo-protocol with data specific to IPv4 unicast."; | |||
container ipv4 { | container ipv4 { | |||
description | description | |||
"Configuration of a 'static' pseudo-protocol instance | "Configuration of a 'static' pseudo-protocol instance | |||
consists of a list of routes."; | consists of a list of routes."; | |||
list route { | list route { | |||
key "destination-prefix"; | key "destination-prefix"; | |||
description | description | |||
skipping to change at page 33, line 32 ¶ | skipping to change at page 30, line 11 ¶ | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
9. IPv6 Unicast Routing Management YANG Module | 9. IPv6 Unicast Routing Management YANG Module | |||
RFC Editor: In this section, replace all occurrences of 'XXXX' with | RFC Editor: In this section, replace all occurrences of 'XXXX' with | |||
the actual RFC number and all occurrences of the revision date below | the actual RFC number and all occurrences of the revision date below | |||
with the date of RFC publication (and remove this note). | with the date of RFC publication (and remove this note). | |||
<CODE BEGINS> file "ietf-ipv6-unicast-routing@2015-10-16.yang" | <CODE BEGINS> file "ietf-ipv6-unicast-routing@2016-03-09.yang" | |||
module ietf-ipv6-unicast-routing { | module ietf-ipv6-unicast-routing { | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; | namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; | |||
prefix "v6ur"; | prefix "v6ur"; | |||
import ietf-routing { | import ietf-routing { | |||
prefix "rt"; | prefix "rt"; | |||
} | } | |||
import ietf-inet-types { | import ietf-inet-types { | |||
prefix "inet"; | prefix "inet"; | |||
} | } | |||
import ietf-interfaces { | include ietf-ipv6-router-advertisements { | |||
prefix "if"; | revision-date 2016-03-09; | |||
} | ||||
import ietf-ip { | ||||
prefix "ip"; | ||||
} | } | |||
organization | organization | |||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | |||
contact | contact | |||
"WG Web: <http://tools.ietf.org/wg/netmod/> | "WG Web: <http://tools.ietf.org/wg/netmod/> | |||
WG List: <mailto:netmod@ietf.org> | WG List: <mailto:netmod@ietf.org> | |||
WG Chair: Thomas Nadeau | WG Chair: Lou Berger | |||
<mailto:tnadeau@lucidvision.com> | <mailto:lberger@labn.net> | |||
WG Chair: Juergen Schoenwaelder | WG Chair: Juergen Schoenwaelder | |||
<mailto:j.schoenwaelder@jacobs-university.de> | <mailto:j.schoenwaelder@jacobs-university.de> | |||
WG Chair: Kent Watsen | WG Chair: Kent Watsen | |||
<mailto:kwatsen@juniper.net> | <mailto:kwatsen@juniper.net> | |||
Editor: Ladislav Lhotka | Editor: Ladislav Lhotka | |||
<mailto:lhotka@nic.cz>"; | <mailto:lhotka@nic.cz> | |||
Editor: Acee Lindem | ||||
<mailto:acee@cisco.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. | |||
Copyright (c) 2015 IETF Trust and the persons identified as | Copyright (c) 2016 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject to | without modification, is permitted pursuant to, and subject to | |||
the license terms contained in, the Simplified BSD License set | the license terms contained in, the Simplified BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info). | |||
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | |||
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and | NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and | |||
'OPTIONAL' in the module text are to be interpreted as described | 'OPTIONAL' in the module text are to be interpreted as described | |||
in RFC 2119 (http://tools.ietf.org/html/rfc2119). | in RFC 2119 (http://tools.ietf.org/html/rfc2119). | |||
This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC XXXX | |||
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for | (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for | |||
full legal notices."; | full legal notices."; | |||
revision 2015-10-16 { | revision 2016-03-09 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: A YANG Data Model for Routing Management"; | "RFC XXXX: A YANG Data Model for Routing Management"; | |||
} | } | |||
/* Identities */ | /* Identities */ | |||
identity ipv6-unicast { | identity ipv6-unicast { | |||
base rt:ipv6; | base rt:ipv6; | |||
description | description | |||
"This identity represents the IPv6 unicast address family."; | "This identity represents the IPv6 unicast address family."; | |||
skipping to change at page 35, line 19 ¶ | skipping to change at page 31, line 45 ¶ | |||
/* Identities */ | /* Identities */ | |||
identity ipv6-unicast { | identity ipv6-unicast { | |||
base rt:ipv6; | base rt:ipv6; | |||
description | description | |||
"This identity represents the IPv6 unicast address family."; | "This identity represents the IPv6 unicast address family."; | |||
} | } | |||
/* State data */ | /* State data */ | |||
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { | ||||
when "../../rt:address-family = 'v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"This leaf augments an IPv6 unicast route."; | ||||
leaf destination-prefix { | ||||
type inet:ipv6-prefix; | ||||
description | ||||
"IPv6 destination prefix."; | ||||
} | ||||
} | ||||
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" | ||||
+ "rt:next-hop/rt:next-hop-options" { | ||||
when "../../../rt:address-family = 'v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"Augment 'next-hop-options' in IPv6 unicast routes."; | ||||
leaf next-hop-address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 address of the next-hop."; | ||||
} | ||||
} | ||||
/* Configuration data */ | ||||
augment "/rt:routing/rt:routing-protocols/rt:routing-protocol/" | ||||
+ "rt:static-routes" { | ||||
description | ||||
"This augment defines the configuration of the 'static' | ||||
pseudo-protocol with data specific to IPv6 unicast."; | ||||
container ipv6 { | ||||
description | ||||
"Configuration of a 'static' pseudo-protocol instance | ||||
consists of a list of routes."; | ||||
list route { | ||||
key "destination-prefix"; | ||||
description | ||||
"A list of static routes."; | ||||
leaf destination-prefix { | ||||
type inet:ipv6-prefix; | ||||
mandatory "true"; | ||||
description | ||||
"IPv6 destination prefix."; | ||||
} | ||||
leaf description { | ||||
type string; | ||||
description | ||||
"Textual description of the route."; | ||||
} | ||||
container next-hop { | ||||
description | ||||
"Configuration of next-hop."; | ||||
uses rt:next-hop-content { | ||||
augment "next-hop-options" { | ||||
description | ||||
"Augment 'next-hop-options' in IPv6 static routes."; | ||||
leaf next-hop-address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 address of the next-hop."; | ||||
} | ||||
} | ||||
} | ||||
} | ||||
} | ||||
} | ||||
} | ||||
/* RPC operations */ | ||||
augment "/rt:fib-route/rt:input/rt:destination-address" { | ||||
when "rt:address-family='v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"This leaf augments the 'rt:destination-address' parameter of | ||||
the 'rt:fib-route' operation."; | ||||
leaf address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 destination address."; | ||||
} | ||||
} | ||||
augment "/rt:fib-route/rt:output/rt:route" { | ||||
when "rt:address-family='v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"This leaf augments the reply to the 'rt:fib-route' | ||||
operation."; | ||||
leaf destination-prefix { | ||||
type inet:ipv6-prefix; | ||||
description | ||||
"IPv6 destination prefix."; | ||||
} | ||||
} | ||||
augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" | ||||
+ "rt:next-hop-options" { | ||||
when "../rt:address-family='v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"Augment 'next-hop-options' in the reply to the 'rt:fib-route' | ||||
operation."; | ||||
leaf next-hop-address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 address of the next-hop."; | ||||
} | ||||
} | ||||
} | ||||
<CODE ENDS> | ||||
9.1. IPv6 Router Advertisements Submodule | ||||
RFC Editor: In this section, replace all occurrences of 'XXXX' with | ||||
the actual RFC number and all occurrences of the revision date below | ||||
with the date of RFC publication (and remove this note). | ||||
<CODE BEGINS> file "ietf-ipv6-router-advertisements@2016-03-09.yang" | ||||
submodule ietf-ipv6-router-advertisements { | ||||
belongs-to ietf-ipv6-unicast-routing { | ||||
prefix "v6ur"; | ||||
} | ||||
import ietf-inet-types { | ||||
prefix "inet"; | ||||
} | ||||
import ietf-interfaces { | ||||
prefix "if"; | ||||
} | ||||
import ietf-ip { | ||||
prefix "ip"; | ||||
} | ||||
organization | ||||
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; | ||||
contact | ||||
"WG Web: <http://tools.ietf.org/wg/netmod/> | ||||
WG List: <mailto:netmod@ietf.org> | ||||
WG Chair: Lou Berger | ||||
<mailto:lberger@labn.net> | ||||
WG Chair: Juergen Schoenwaelder | ||||
<mailto:j.schoenwaelder@jacobs-university.de> | ||||
WG Chair: Kent Watsen | ||||
<mailto:kwatsen@juniper.net> | ||||
Editor: Ladislav Lhotka | ||||
<mailto:lhotka@nic.cz> | ||||
Editor: Acee Lindem | ||||
<mailto:acee@cisco.com>"; | ||||
description | ||||
"This YANG module augments the 'ietf-ip' module with | ||||
configuration and state data of IPv6 router advertisements. | ||||
Copyright (c) 2016 IETF Trust and the persons identified as | ||||
authors of the code. All rights reserved. | ||||
Redistribution and use in source and binary forms, with or | ||||
without modification, is permitted pursuant to, and subject to | ||||
the license terms contained in, the Simplified BSD License set | ||||
forth in Section 4.c of the IETF Trust's Legal Provisions | ||||
Relating to IETF Documents | ||||
(http://trustee.ietf.org/license-info). | ||||
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | ||||
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and | ||||
'OPTIONAL' in the module text are to be interpreted as described | ||||
in RFC 2119 (http://tools.ietf.org/html/rfc2119). | ||||
This version of this YANG module is part of RFC XXXX | ||||
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for | ||||
full legal notices."; | ||||
reference | ||||
"RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; | ||||
revision 2016-03-09 { | ||||
description | ||||
"Initial revision."; | ||||
reference | ||||
"RFC XXXX: A YANG Data Model for Routing Management"; | ||||
} | ||||
/* State data */ | ||||
augment "/if:interfaces-state/if:interface/ip:ipv6" { | augment "/if:interfaces-state/if:interface/ip:ipv6" { | |||
description | description | |||
"Augment interface state data with IPv6-specific parameters of | "Augment interface state data with parameters of IPv6 router | |||
router interfaces."; | advertisements."; | |||
container ipv6-router-advertisements { | container ipv6-router-advertisements { | |||
description | description | |||
"Parameters of IPv6 Router Advertisements."; | "Parameters of IPv6 Router Advertisements."; | |||
leaf send-advertisements { | leaf send-advertisements { | |||
type boolean; | type boolean; | |||
description | description | |||
"A flag indicating whether or not the router sends periodic | "A flag indicating whether or not the router sends periodic | |||
Router Advertisements and responds to Router | Router Advertisements and responds to Router | |||
Solicitations."; | Solicitations."; | |||
} | } | |||
skipping to change at page 38, line 21 ¶ | skipping to change at page 39, line 15 ¶ | |||
type boolean; | type boolean; | |||
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."; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" | ||||
+ "rt:routes/rt:route" { | ||||
when "../../rt:address-family = 'v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"This leaf augments an IPv6 unicast route."; | ||||
leaf destination-prefix { | ||||
type inet:ipv6-prefix; | ||||
description | ||||
"IPv6 destination prefix."; | ||||
} | ||||
} | ||||
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" | ||||
+ "rt:routes/rt:route/rt:next-hop/rt:next-hop-options" { | ||||
when "../../../rt:address-family = 'v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"Augment 'next-hop-options' in IPv6 unicast routes."; | ||||
leaf next-hop-address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 address of the next-hop."; | ||||
} | ||||
} | ||||
/* Configuration data */ | /* Configuration data */ | |||
augment "/if:interfaces/if:interface/ip:ipv6" { | augment "/if:interfaces/if:interface/ip:ipv6" { | |||
description | description | |||
"Augment interface configuration with IPv6-specific parameters | "Augment interface configuration with parameters of IPv6 router | |||
of router interfaces."; | advertisements."; | |||
container ipv6-router-advertisements { | container ipv6-router-advertisements { | |||
description | description | |||
"Configuration of IPv6 Router Advertisements."; | "Configuration of 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 periodic | "A flag indicating whether or not the router sends periodic | |||
Router Advertisements and responds to Router | Router Advertisements and responds to Router | |||
Solicitations."; | Solicitations."; | |||
skipping to change at page 44, line 4 ¶ | skipping to change at page 44, line 17 ¶ | |||
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."; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" | ||||
+ "rt:routing-protocol/rt:static-routes" { | ||||
description | ||||
"This augment defines the configuration of the 'static' | ||||
pseudo-protocol with data specific to IPv6 unicast."; | ||||
container ipv6 { | ||||
description | ||||
"Configuration of a 'static' pseudo-protocol instance | ||||
consists of a list of routes."; | ||||
list route { | ||||
key "destination-prefix"; | ||||
description | ||||
"A list of static routes."; | ||||
leaf destination-prefix { | ||||
type inet:ipv6-prefix; | ||||
mandatory "true"; | ||||
description | ||||
"IPv6 destination prefix."; | ||||
} | ||||
leaf description { | ||||
type string; | ||||
description | ||||
"Textual description of the route."; | ||||
} | ||||
container next-hop { | ||||
description | ||||
"Configuration of next-hop."; | ||||
uses rt:next-hop-content { | ||||
augment "next-hop-options" { | ||||
description | ||||
"Augment 'next-hop-options' in IPv6 static routes."; | ||||
leaf next-hop-address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 address of the next-hop."; | ||||
} | ||||
} | ||||
} | ||||
} | ||||
} | ||||
} | ||||
} | ||||
/* RPC operations */ | ||||
augment "/rt:fib-route/rt:input/rt:destination-address" { | ||||
when "rt:address-family='v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"This leaf augments the 'rt:destination-address' parameter of | ||||
the 'rt:fib-route' operation."; | ||||
leaf address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 destination address."; | ||||
} | ||||
} | ||||
augment "/rt:fib-route/rt:output/rt:route" { | ||||
when "rt:address-family='v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"This leaf augments the reply to the 'rt:fib-route' | ||||
operation."; | ||||
leaf destination-prefix { | ||||
type inet:ipv6-prefix; | ||||
description | ||||
"IPv6 destination prefix."; | ||||
} | ||||
} | ||||
augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" | ||||
+ "rt:next-hop-options" { | ||||
when "../rt:address-family='v6ur:ipv6-unicast'" { | ||||
description | ||||
"This augment is valid only for IPv6 unicast."; | ||||
} | ||||
description | ||||
"Augment 'next-hop-options' in the reply to the 'rt:fib-route' | ||||
operation."; | ||||
leaf next-hop-address { | ||||
type inet:ipv6-address; | ||||
description | ||||
"IPv6 address of the next-hop."; | ||||
} | ||||
} | ||||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
10. IANA Considerations | 10. IANA Considerations | |||
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the | RFC Ed.: In this section, replace all occurrences of 'XXXX' with the | |||
actual RFC number (and remove this note). | actual RFC number (and remove this note). | |||
This document registers the following namespace URIs in the IETF XML | This document registers the following namespace URIs in the IETF XML | |||
skipping to change at page 47, line 26 ¶ | skipping to change at page 45, line 36 ¶ | |||
reference: RFC XXXX | reference: RFC XXXX | |||
-------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
-------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
name: ietf-ipv6-unicast-routing | name: ietf-ipv6-unicast-routing | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing | namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing | |||
prefix: v6ur | prefix: v6ur | |||
reference: RFC XXXX | reference: RFC XXXX | |||
-------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
This document registers the following YANG submodule in the YANG | ||||
Module Names registry [RFC6020]: | ||||
-------------------------------------------------------------------- | ||||
name: ietf-ipv6-router-advertisements | ||||
parent: ietf-ipv6-unicast-routing | ||||
reference: RFC XXXX | ||||
-------------------------------------------------------------------- | ||||
11. Security Considerations | 11. Security Considerations | |||
Configuration and state data conforming to the core routing data | Configuration and state data conforming to the core routing data | |||
model (defined in this document) are designed to be accessed via the | model (defined in this document) are designed to be accessed via the | |||
NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure | NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure | |||
transport layer and the mandatory-to-implement secure transport is | transport layer and the mandatory-to-implement secure transport is | |||
SSH [RFC6242]. The NETCONF access control model [RFC6536] provides | SSH [RFC6242]. The NETCONF access control model [RFC6536] provides | |||
the means to restrict access for particular NETCONF users to a pre- | the means to restrict access for particular NETCONF users to a pre- | |||
configured subset of all available NETCONF protocol operations and | configured subset of all available NETCONF protocol operations and | |||
content. | content. | |||
skipping to change at page 47, line 48 ¶ | skipping to change at page 46, line 19 ¶ | |||
configuration part of the core routing data model are | configuration part of the core routing data model are | |||
writable/creatable/deletable (i.e., "config true" in YANG terms, | writable/creatable/deletable (i.e., "config true" in YANG terms, | |||
which is the default). These data nodes may be considered sensitive | which is the default). These data nodes may be considered sensitive | |||
or vulnerable in some network environments. Write operations to | or vulnerable in some network environments. Write operations to | |||
these data nodes, such as "edit-config", can have negative effects on | these data nodes, such as "edit-config", can have negative effects on | |||
the network if the protocol operations are not properly protected. | the network if the protocol operations are not properly protected. | |||
The vulnerable "config true" parameters and subtrees are the | The vulnerable "config true" parameters and subtrees are the | |||
following: | following: | |||
/if:interfaces/if:interface/rt:routing-instance: This leaf assigns a | /routing/routing-protocols/routing-protocol: This list specifies the | |||
network layer interface to a routing instance. | routing protocols configured on a device. | |||
/routing/routing-instance/routing-protocols/routing-protocol: This | ||||
list specifies the routing protocols configured on a device. | ||||
/routing/routing-instance/ribs/rib: This list specifies the RIBs | /routing/ribs/rib: This list specifies the RIBs configured for the | |||
configured for the device. | device. | |||
Unauthorised access to any of these lists can adversely affect the | Unauthorised access to any of these lists can adversely affect the | |||
routing subsystem of both the local device and the network. This may | routing subsystem of both the local device and the network. This may | |||
lead to network malfunctions, delivery of packets to inappropriate | lead to network malfunctions, delivery of packets to inappropriate | |||
destinations and other problems. | destinations and other problems. | |||
12. Acknowledgments | 12. 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, | |||
skipping to change at page 48, line 28 ¶ | skipping to change at page 46, line 45 ¶ | |||
Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, | Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, | |||
Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- | Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- | |||
Kit Yeung and Jeffrey Zhang for their helpful comments and | Kit Yeung and Jeffrey Zhang for their helpful comments and | |||
suggestions. | suggestions. | |||
13. References | 13. References | |||
13.1. Normative References | 13.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, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, | |||
RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://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, | DOI 10.17487/RFC3688, January 2004, | |||
<http://www.rfc-editor.org/info/rfc3688>. | <http://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, | DOI 10.17487/RFC4861, September 2007, | |||
<http://www.rfc-editor.org/info/rfc4861>. | <http://www.rfc-editor.org/info/rfc4861>. | |||
skipping to change at page 49, line 5 ¶ | skipping to change at page 47, line 20 ¶ | |||
[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, | DOI 10.17487/RFC6020, October 2010, | |||
<http://www.rfc-editor.org/info/rfc6020>. | <http://www.rfc-editor.org/info/rfc6020>. | |||
[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, | |||
<http://www.rfc-editor.org/info/rfc6241>. | <http://www.rfc-editor.org/info/rfc6241>. | |||
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC | [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", | |||
6991, DOI 10.17487/RFC6991, July 2013, | RFC 6991, DOI 10.17487/RFC6991, July 2013, | |||
<http://www.rfc-editor.org/info/rfc6991>. | <http://www.rfc-editor.org/info/rfc6991>. | |||
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface | [RFC7223] Bjorklund, M., "A YANG Data Model for Interface | |||
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, | Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, | |||
<http://www.rfc-editor.org/info/rfc7223>. | <http://www.rfc-editor.org/info/rfc7223>. | |||
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC | [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", | |||
7277, DOI 10.17487/RFC7277, June 2014, | RFC 7277, DOI 10.17487/RFC7277, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7277>. | <http://www.rfc-editor.org/info/rfc7277>. | |||
13.2. Informative References | 13.2. Informative References | |||
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | ||||
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February | ||||
2006, <http://www.rfc-editor.org/info/rfc4364>. | ||||
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG | [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG | |||
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, | Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, | |||
January 2011, <http://www.rfc-editor.org/info/rfc6087>. | January 2011, <http://www.rfc-editor.org/info/rfc6087>. | |||
[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, | |||
<http://www.rfc-editor.org/info/rfc6242>. | <http://www.rfc-editor.org/info/rfc6242>. | |||
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration | [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration | |||
Protocol (NETCONF) Access Control Model", RFC 6536, DOI | Protocol (NETCONF) Access Control Model", RFC 6536, | |||
10.17487/RFC6536, March 2012, | DOI 10.17487/RFC6536, March 2012, | |||
<http://www.rfc-editor.org/info/rfc6536>. | <http://www.rfc-editor.org/info/rfc6536>. | |||
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", | ||||
RFC 7224, DOI 10.17487/RFC7224, May 2014, | ||||
<http://www.rfc-editor.org/info/rfc7224>. | ||||
Appendix A. The Complete Data Trees | Appendix A. The Complete Data Trees | |||
This appendix presents the complete configuration and state data | This appendix presents the complete configuration and state data | |||
trees of the core routing data model. See Section 2.2 for an | trees of the core routing data model. See Section 2.2 for an | |||
explanation of the symbols used. Data type of every leaf node is | explanation of the symbols used. Data type of every leaf node is | |||
shown near the right end of the corresponding line. | shown near the right end of the corresponding line. | |||
A.1. Configuration Data | A.1. Configuration Data | |||
+--rw routing | +--rw routing | |||
+--rw routing-instance* [name] | +--rw router-id? yang:dotted-quad | |||
+--rw name string | +--rw routing-protocols | |||
+--rw type? identityref | | +--rw routing-protocol* [type name] | |||
+--rw enabled? boolean | | +--rw type identityref | |||
+--rw router-id? yang:dotted-quad | | +--rw name string | |||
+--rw description? string | | +--rw description? string | |||
+--rw routing-protocols | | +--rw static-routes | |||
| +--rw routing-protocol* [type name] | | | +--rw v6ur:ipv6 | |||
| +--rw type identityref | | | | +--rw v6ur:route* [destination-prefix] | |||
| +--rw name string | | | | +--rw v6ur:destination-prefix inet:ipv6-prefix | |||
| +--rw description? string | | | | +--rw v6ur:description? string | |||
| +--rw static-routes | | | | +--rw v6ur:next-hop | |||
| +--rw v6ur:ipv6 | | | | +--rw (v6ur:next-hop-options) | |||
| | +--rw v6ur:route* [destination-prefix] | | | | +--:(v6ur:outgoing-interface) | |||
| | +--rw v6ur:destination-prefix inet:ipv6-prefix | | | | | +--rw v6ur:outgoing-interface? if:interface-ref | |||
| | +--rw v6ur:description? string | | | | +--:(v6ur:special-next-hop) | |||
| | +--rw v6ur:next-hop | | | | | +--rw v6ur:special-next-hop? enumeration | |||
| | +--rw (next-hop-options) | | | | +--:(v6ur:next-hop-address) | |||
| | +--:(outgoing-interface) | | | | +--rw v6ur:next-hop-address? inet:ipv6-address | |||
| | | +--rw v6ur:outgoing-interface? | | | +--rw v4ur:ipv4 | |||
| | +--:(special-next-hop) | | | +--rw v4ur:route* [destination-prefix] | |||
| | | +--rw v6ur:special-next-hop? | | | +--rw v4ur:destination-prefix inet:ipv4-prefix | |||
| | +--:(next-hop-address) | | | +--rw v4ur:description? string | |||
| | +--rw v6ur:next-hop-address? | | | +--rw v4ur:next-hop | |||
| +--rw v4ur:ipv4 | | | +--rw (v4ur:next-hop-options) | |||
| +--rw v4ur:route* [destination-prefix] | | | +--:(v4ur:outgoing-interface) | |||
| +--rw v4ur:destination-prefix inet:ipv4-prefix | | | | +--rw v4ur:outgoing-interface? if:interface-ref | |||
| +--rw v4ur:description? string | | | +--:(v4ur:special-next-hop) | |||
| +--rw v4ur:next-hop | | | | +--rw v4ur:special-next-hop? enumeration | |||
| +--rw (next-hop-options) | | | +--:(v4ur:next-hop-address) | |||
| +--:(outgoing-interface) | | | +--rw v4ur:next-hop-address? inet:ipv4-address | |||
| | +--rw v4ur:outgoing-interface? | | +--rw rip:rip! | |||
| +--:(special-next-hop) | | +--rw rip:interfaces | |||
| | +--rw v4ur:special-next-hop? | | | +--rw rip:interface* [name] | |||
| +--:(next-hop-address) | | | +--rw rip:name if:interface-ref | |||
| +--rw v4ur:next-hop-address? | | | +--rw rip:enabled? boolean | |||
+--rw ribs | | | +--rw rip:metric? rip-metric | |||
+--rw rib* [name] | | +--rw rip:update-interval? uint8 | |||
+--rw name string | +--rw ribs | |||
+--rw address-family? identityref | +--rw rib* [name] | |||
+--rw description? string | +--rw name string | |||
+--rw address-family? identityref | ||||
+--rw description? string | ||||
A.2. State Data | A.2. State Data | |||
+--ro routing-state | ||||
+--ro routing-instance* [name] | +--ro routing-state | |||
+--ro name string | +--ro router-id? yang:dotted-quad | |||
+--ro type? identityref | +--ro interfaces | |||
+--ro router-id? yang:dotted-quad | | +--ro interface* if:interface-state-ref | |||
+--ro interfaces | +--ro routing-protocols | |||
| +--ro interface* if:interface-state-ref | | +--ro routing-protocol* [type name] | |||
+--ro routing-protocols | | +--ro type identityref | |||
| +--ro routing-protocol* [type name] | | +--ro name string | |||
| +--ro type identityref | +--ro ribs | |||
| +--ro name string | +--ro rib* [name] | |||
+--ro ribs | +--ro name string | |||
+--ro rib* [name] | +--ro address-family identityref | |||
+--ro name string | +--ro default-rib? boolean {multiple-ribs}? | |||
+--ro address-family identityref | +--ro routes | |||
+--ro default-rib? boolean {multiple-ribs}? | +--ro route* | |||
+--ro routes | +--ro route-preference? route-preference | |||
+--ro route* | +--ro next-hop | |||
+--ro route-preference? route-preference | | +--ro (next-hop-options) | |||
+--ro next-hop | | +--:(outgoing-interface) | |||
| +--ro (next-hop-options) | | | +--ro outgoing-interface? if:interface-state-ref | |||
| +--:(outgoing-interface) | | +--:(special-next-hop) | |||
| | +--ro outgoing-interface? | | | +--ro special-next-hop? enumeration | |||
| +--:(special-next-hop) | | +--:(v6ur:next-hop-address) | |||
| | +--ro special-next-hop? enumeration | | | +--ro v6ur:next-hop-address? inet:ipv6-address | |||
| +--:(next-hop-address) | | +--:(v4ur:next-hop-address) | |||
| | +--ro v6ur:next-hop-address? | | +--ro v4ur:next-hop-address? inet:ipv4-address | |||
| +--:(next-hop-address) | +--ro source-protocol identityref | |||
| +--ro v4ur:next-hop-address? | +--ro active? empty | |||
+--ro source-protocol identityref | +--ro last-updated? yang:date-and-time | |||
+--ro active? empty | +--ro v6ur:destination-prefix? inet:ipv6-prefix | |||
+--ro last-updated? yang:date-and-time | +--ro rip:metric? rip-metric | |||
+--ro v6ur:destination-prefix? inet:ipv6-prefix | +--ro rip:tag? uint16 | |||
+--ro v4ur:destination-prefix? inet:ipv4-prefix | +--ro v4ur:destination-prefix? inet:ipv4-prefix | |||
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 provides a single system-controlled routing | A minimum implementation does not support the feature "multiple- | |||
instance of the type "default-routing-instance", and will not allow | ribs". This means that a single system-controlled RIB is available | |||
clients to create any user-controlled instances. | for each supported address family - IPv4, IPv6 or both. These RIBs | |||
are also the default RIBs. No user-controlled RIBs are allowed. | ||||
Typically, the feature "multiple-ribs" will not be supported. This | ||||
means that a single system-controlled RIB is available for each | ||||
supported address family - IPv4, IPv6 or both. These RIBs must be | ||||
the default RIBs. No user-controlled RIBs are allowed. | ||||
In addition to the mandatory instance of the "direct" pseudo- | In addition to the mandatory instance of the "direct" pseudo- | |||
protocol, a minimum implementation should support configuring | protocol, a minimum implementation should support configuring | |||
instance(s) of the "static" pseudo-protocol. | instance(s) of the "static" pseudo-protocol. | |||
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" | |||
routing protocol instances. | routing protocol instances. | |||
Appendix C. Example: Adding a New Routing Protocol | Appendix C. Example: Adding a New Routing Protocol | |||
This appendix demonstrates how the core routing data model can be | This appendix demonstrates how the core routing data model can be | |||
extended to support a new routing protocol. The YANG module | extended to support a new routing protocol. The YANG module | |||
"example-rip" shown below is intended 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 RIP routing protocol. For | a real definition of a data model for the RIP routing protocol. For | |||
the sake of brevity, this module does not obey all the guidelines | the sake of brevity, this module does not obey all the guidelines | |||
specified in [RFC6087]. See also Section 5.4.2. | specified in [RFC6087]. See also Section 5.3.2. | |||
module example-rip { | module example-rip { | |||
namespace "http://example.com/rip"; | namespace "http://example.com/rip"; | |||
prefix "rip"; | prefix "rip"; | |||
import ietf-interfaces { | import ietf-interfaces { | |||
prefix "if"; | prefix "if"; | |||
} | } | |||
skipping to change at page 53, line 19 ¶ | skipping to change at page 52, line 15 ¶ | |||
} | } | |||
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. AS | "This leaf may be used to carry additional info, e.g. AS | |||
number."; | number."; | |||
} | } | |||
} | } | |||
augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" | augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { | |||
+ "rt:routes/rt:route" { | ||||
when "rt:source-protocol = 'rip:rip'" { | when "rt:source-protocol = 'rip:rip'" { | |||
description | description | |||
"This augment is only valid for a routes whose source | "This augment is only valid for a routes 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:fib-route/rt:output/rt:route" { | augment "/rt:fib-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 'active-route' | |||
RPC."; | RPC."; | |||
uses route-content; | uses route-content; | |||
} | } | |||
augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" | augment "/rt:routing/rt:routing-protocols/rt:routing-protocol" { | |||
+ "rt:routing-protocol" { | ||||
when "rt:type = 'rip:rip'" { | when "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 { | |||
skipping to change at page 54, line 45 ¶ | skipping to change at page 53, line 37 ¶ | |||
} | } | |||
Appendix D. Example: NETCONF <get> Reply | Appendix D. Example: NETCONF <get> Reply | |||
This section contains a sample reply to the NETCONF <get> message, | This section contains a sample reply to the NETCONF <get> message, | |||
which could be sent by a server supporting (i.e., advertising them in | which could be sent by a server supporting (i.e., advertising them in | |||
the NETCONF <hello> message) the following YANG modules: | the NETCONF <hello> message) the following YANG modules: | |||
o ietf-interfaces [RFC7223], | o ietf-interfaces [RFC7223], | |||
o iana-if-type [RFC7224], | ||||
o ietf-ip [RFC7277], | o ietf-ip [RFC7277], | |||
o ietf-routing (Section 7), | o ietf-routing (Section 7), | |||
o ietf-ipv4-unicast-routing (Section 8), | o ietf-ipv4-unicast-routing (Section 8), | |||
o ietf-ipv6-unicast-routing (Section 9). | o ietf-ipv6-unicast-routing (Section 9). | |||
We assume a simple network set-up as shown in Figure 3: router "A" | We assume a simple network set-up as shown in Figure 3: router "A" | |||
uses static default routes with the "ISP" router as the next-hop. | uses static default routes with the "ISP" router as the next-hop. | |||
skipping to change at page 55, line 35 ¶ | skipping to change at page 54, line 30 ¶ | |||
+--------+--------+ | +--------+--------+ | |||
eth1|198.51.100.1 | eth1|198.51.100.1 | |||
|2001:db8:0:2::1 | |2001:db8:0:2::1 | |||
| | | | |||
Figure 3: Example network configuration | Figure 3: Example network configuration | |||
A reply to the NETCONF <get> message sent by router "A" would then be | A reply to the NETCONF <get> message sent by router "A" would then be | |||
as follows: | as follows: | |||
<?xml version="1.0"?> | <?xml version="1.0"?> | |||
<rpc-reply | <rpc-reply | |||
message-id="101" | message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | |||
xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing" | xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing" | |||
xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing" | xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing" | |||
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces" | xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces" | |||
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" | xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" | |||
xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip" | xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip" | |||
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"> | xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"> | |||
<data> | <data> | |||
<if:interfaces> | <if:interfaces> | |||
<if:interface> | <if:interface> | |||
<if:name>eth0</if:name> | <if:name>eth0</if:name> | |||
<if:type>ianaift:ethernetCsmacd</if:type> | <if:type>ianaift:ethernetCsmacd</if:type> | |||
<if:description> | <if:description> | |||
Uplink to ISP. | Uplink to ISP. | |||
</if:description> | </if:description> | |||
<rt:routing-instance>rtr0</rt:routing-instance> | <ip:ipv4> | |||
<ip:ipv4> | <ip:address> | |||
<ip:address> | <ip:ip>192.0.2.1</ip:ip> | |||
<ip:ip>192.0.2.1</ip:ip> | <ip:prefix-length>24</ip:prefix-length> | |||
<ip:prefix-length>24</ip:prefix-length> | </ip:address> | |||
</ip:address> | <ip:forwarding>true</ip:forwarding> | |||
<ip:forwarding>true</ip:forwarding> | </ip:ipv4> | |||
</ip:ipv4> | <ip:ipv6> | |||
<ip:ipv6> | <ip:address> | |||
<ip:address> | <ip:ip>2001:0db8:0:1::1</ip:ip> | |||
<ip:ip>2001:0db8:0:1::1</ip:ip> | <ip:prefix-length>64</ip:prefix-length> | |||
<ip:prefix-length>64</ip:prefix-length> | </ip:address> | |||
</ip:address> | <ip:forwarding>true</ip:forwarding> | |||
<ip:forwarding>true</ip:forwarding> | <ip:autoconf> | |||
<ip:autoconf> | <ip:create-global-addresses>false</ip:create-global-addresses> | |||
<ip:create-global-addresses>false</ip:create-global-addresses> | </ip:autoconf> | |||
</ip:autoconf> | </ip:ipv6> | |||
</ip:ipv6> | </if:interface> | |||
</if:interface> | <if:interface> | |||
<if:interface> | <if:name>eth1</if:name> | |||
<if:name>eth1</if:name> | <if:type>ianaift:ethernetCsmacd</if:type> | |||
<if:type>ianaift:ethernetCsmacd</if:type> | <if:description> | |||
<if:description> | Interface to the internal network. | |||
Interface to the internal network. | </if:description> | |||
</if:description> | <ip:ipv4> | |||
<rt:routing-instance>rtr0</rt:routing-instance> | <ip:address> | |||
<ip:ipv4> | <ip:ip>198.51.100.1</ip:ip> | |||
<ip:address> | <ip:prefix-length>24</ip:prefix-length> | |||
<ip:ip>198.51.100.1</ip:ip> | </ip:address> | |||
<ip:prefix-length>24</ip:prefix-length> | <ip:forwarding>true</ip:forwarding> | |||
</ip:address> | </ip:ipv4> | |||
<ip:forwarding>true</ip:forwarding> | <ip:ipv6> | |||
</ip:ipv4> | <ip:address> | |||
<ip:ipv6> | <ip:ip>2001:0db8:0:2::1</ip:ip> | |||
<ip:address> | <ip:prefix-length>64</ip:prefix-length> | |||
<ip:ip>2001:0db8:0:2::1</ip:ip> | </ip:address> | |||
<ip:prefix-length>64</ip:prefix-length> | <ip:forwarding>true</ip:forwarding> | |||
</ip:address> | <ip:autoconf> | |||
<ip:forwarding>true</ip:forwarding> | <ip:create-global-addresses>false</ip:create-global-addresses> | |||
<ip:autoconf> | </ip:autoconf> | |||
<ip:create-global-addresses>false</ip:create-global-addresses> | <v6ur:ipv6-router-advertisements> | |||
</ip:autoconf> | <v6ur:send-advertisements>true</v6ur:send-advertisements> | |||
</ip:ipv6> | </v6ur:ipv6-router-advertisements> | |||
</if:interface> | </ip:ipv6> | |||
</if:interfaces> | </if:interface> | |||
<if:interfaces-state> | </if:interfaces> | |||
<if:interface> | <if:interfaces-state> | |||
<if:name>eth0</if:name> | <if:interface> | |||
<if:type>ianaift:ethernetCsmacd</if:type> | <if:name>eth0</if:name> | |||
<if:phys-address>00:0C:42:E5:B1:E9</if:phys-address> | <if:type>ianaift:ethernetCsmacd</if:type> | |||
<if:oper-status>up</if:oper-status> | <if:phys-address>00:0C:42:E5:B1:E9</if:phys-address> | |||
<rt:routing-instance>rtr0</rt:routing-instance> | <if:oper-status>up</if:oper-status> | |||
<if:statistics> | <if:statistics> | |||
<if:discontinuity-time> | <if:discontinuity-time>2015-10-24T17:11:27+02:00</if:discontinuity-time> | |||
2015-10-24T17:11:27+02:00 | </if:statistics> | |||
</if:discontinuity-time> | <ip:ipv4> | |||
</if:statistics> | <ip:forwarding>true</ip:forwarding> | |||
<ip:ipv4> | <ip:mtu>1500</ip:mtu> | |||
<ip:forwarding>true</ip:forwarding> | <ip:address> | |||
<ip:mtu>1500</ip:mtu> | <ip:ip>192.0.2.1</ip:ip> | |||
<ip:address> | <ip:prefix-length>24</ip:prefix-length> | |||
<ip:ip>192.0.2.1</ip:ip> | </ip:address> | |||
<ip:prefix-length>24</ip:prefix-length> | </ip:ipv4> | |||
</ip:address> | <ip:ipv6> | |||
</ip:ipv4> | <ip:forwarding>true</ip:forwarding> | |||
<ip:ipv6> | <ip:mtu>1500</ip:mtu> | |||
<ip:forwarding>true</ip:forwarding> | <ip:address> | |||
<ip:mtu>1500</ip:mtu> | <ip:ip>2001:0db8:0:1::1</ip:ip> | |||
<ip:address> | <ip:prefix-length>64</ip:prefix-length> | |||
<ip:ip>2001:0db8:0:1::1</ip:ip> | </ip:address> | |||
<ip:prefix-length>64</ip:prefix-length> | <v6ur:ipv6-router-advertisements> | |||
</ip:address> | <v6ur:send-advertisements>true</v6ur:send-advertisements> | |||
<v6ur:ipv6-router-advertisements> | <v6ur:prefix-list> | |||
<v6ur:send-advertisements>true</v6ur:send-advertisements> | <v6ur:prefix> | |||
<v6ur:prefix-list> | <v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec> | |||
<v6ur:prefix> | </v6ur:prefix> | |||
<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec> | </v6ur:prefix-list> | |||
</v6ur:prefix> | </v6ur:ipv6-router-advertisements> | |||
</v6ur:prefix-list> | </ip:ipv6> | |||
</v6ur:ipv6-router-advertisements> | </if:interface> | |||
</ip:ipv6> | <if:interface> | |||
</if:interface> | <if:name>eth1</if:name> | |||
<if:interface> | <if:type>ianaift:ethernetCsmacd</if:type> | |||
<if:name>eth1</if:name> | <if:phys-address>00:0C:42:E5:B1:EA</if:phys-address> | |||
<if:type>ianaift:ethernetCsmacd</if:type> | <if:oper-status>up</if:oper-status> | |||
<if:phys-address>00:0C:42:E5:B1:EA</if:phys-address> | <if:statistics> | |||
<if:oper-status>up</if:oper-status> | <if:discontinuity-time>2015-10-24T17:11:29+02:00</if:discontinuity-time> | |||
<rt:routing-instance>rtr0</rt:routing-instance> | </if:statistics> | |||
<if:statistics> | <ip:ipv4> | |||
<if:discontinuity-time> | <ip:forwarding>true</ip:forwarding> | |||
2015-10-24T17:11:29+02:00 | <ip:mtu>1500</ip:mtu> | |||
</if:discontinuity-time> | <ip:address> | |||
</if:statistics> | <ip:ip>198.51.100.1</ip:ip> | |||
<ip:ipv4> | <ip:prefix-length>24</ip:prefix-length> | |||
<ip:forwarding>true</ip:forwarding> | </ip:address> | |||
<ip:mtu>1500</ip:mtu> | </ip:ipv4> | |||
<ip:address> | <ip:ipv6> | |||
<ip:ip>198.51.100.1</ip:ip> | <ip:forwarding>true</ip:forwarding> | |||
<ip:prefix-length>24</ip:prefix-length> | <ip:mtu>1500</ip:mtu> | |||
</ip:address> | <ip:address> | |||
</ip:ipv4> | <ip:ip>2001:0db8:0:2::1</ip:ip> | |||
<ip:ipv6> | <ip:prefix-length>64</ip:prefix-length> | |||
<ip:forwarding>true</ip:forwarding> | </ip:address> | |||
<ip:mtu>1500</ip:mtu> | <v6ur:ipv6-router-advertisements> | |||
<ip:address> | <v6ur:send-advertisements>true</v6ur:send-advertisements> | |||
<ip:ip>2001:0db8:0:2::1</ip:ip> | <v6ur:prefix-list> | |||
<ip:prefix-length>64</ip:prefix-length> | <v6ur:prefix> | |||
</ip:address> | <v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec> | |||
<v6ur:ipv6-router-advertisements> | </v6ur:prefix> | |||
<v6ur:send-advertisements>true</v6ur:send-advertisements> | </v6ur:prefix-list> | |||
<v6ur:prefix-list> | </v6ur:ipv6-router-advertisements> | |||
<v6ur:prefix> | </ip:ipv6> | |||
<v6ur:prefix-spec>2001:db8:0:2::/64</v6ur:prefix-spec> | </if:interface> | |||
</v6ur:prefix> | </if:interfaces-state> | |||
</v6ur:prefix-list> | <rt:routing> | |||
</v6ur:ipv6-router-advertisements> | <rt:router-id>192.0.2.1</rt:router-id> | |||
</ip:ipv6> | <rt:routing-protocols> | |||
</if:interface> | <rt:routing-protocol> | |||
</if:interfaces-state> | <rt:type>rt:static</rt:type> | |||
<rt:routing> | <rt:name>st0</rt:name> | |||
<rt:routing-instance> | <rt:description> | |||
<rt:name>rtr0</rt:name> | Static routing is used for the internal network. | |||
<rt:description>Router A</rt:description> | </rt:description> | |||
<rt:router-id>192.0.2.1</rt:router-id> | <rt:static-routes> | |||
<rt:routing-protocols> | <v4ur:ipv4> | |||
<rt:routing-protocol> | <v4ur:route> | |||
<rt:type>rt:static</rt:type> | <v4ur:destination-prefix>0.0.0.0/0</v4ur:destination-prefix> | |||
<rt:name>st0</rt:name> | <v4ur:next-hop> | |||
<rt:description> | <v4ur:next-hop-address>192.0.2.2</v4ur:next-hop-address> | |||
Static routing is used for the internal network. | </v4ur:next-hop> | |||
</rt:description> | </v4ur:route> | |||
<rt:static-routes> | </v4ur:ipv4> | |||
<v4ur:ipv4> | <v6ur:ipv6> | |||
<v4ur:route> | <v6ur:route> | |||
<v4ur:destination-prefix> | <v6ur:destination-prefix>::/0</v6ur:destination-prefix> | |||
0.0.0.0/0 | <v6ur:next-hop> | |||
</v4ur:destination-prefix> | <v6ur:next-hop-address>2001:db8:0:1::2</v6ur:next-hop-address> | |||
<v4ur:next-hop> | </v6ur:next-hop> | |||
<v4ur:next-hop-address>192.0.2.2</v4ur:next-hop-address> | </v6ur:route> | |||
</v4ur:next-hop> | </v6ur:ipv6> | |||
</v4ur:route> | </rt:static-routes> | |||
</v4ur:ipv4> | </rt:routing-protocol> | |||
<v6ur:ipv6> | </rt:routing-protocols> | |||
<v6ur:route> | </rt:routing> | |||
<v6ur:destination-prefix>::/0</v6ur:destination-prefix> | <rt:routing-state> | |||
<v6ur:next-hop> | <rt:interfaces> | |||
<v6ur:next-hop-address> | <rt:interface>eth0</rt:interface> | |||
2001:db8:0:1::2 | <rt:interface>eth1</rt:interface> | |||
</v6ur:next-hop-address> | </rt:interfaces> | |||
</v6ur:next-hop> | <rt:routing-protocols> | |||
</v6ur:route> | <rt:routing-protocol> | |||
</v6ur:ipv6> | <rt:type>rt:static</rt:type> | |||
</rt:static-routes> | <rt:name>st0</rt:name> | |||
</rt:routing-protocol> | </rt:routing-protocol> | |||
</rt:routing-protocols> | </rt:routing-protocols> | |||
</rt:routing-instance> | <rt:ribs> | |||
</rt:routing> | <rt:rib> | |||
<rt:routing-state> | <rt:name>ipv4-master</rt:name> | |||
<rt:routing-instance> | <rt:address-family>v4ur:ipv4-unicast</rt:address-family> | |||
<rt:name>rtr0</rt:name> | <rt:default-rib>true</rt:default-rib> | |||
<rt:interfaces> | <rt:routes> | |||
<rt:interface>eth0</rt:interface> | <rt:route> | |||
<rt:interface>eth1</rt:interface> | <v4ur:destination-prefix>192.0.2.1/24</v4ur:destination-prefix> | |||
</rt:interfaces> | <rt:next-hop> | |||
<rt:routing-protocols> | <rt:outgoing-interface>eth0</rt:outgoing-interface> | |||
<rt:routing-protocol> | </rt:next-hop> | |||
<rt:type>rt:static</rt:type> | <rt:route-preference>0</rt:route-preference> | |||
<rt:name>st0</rt:name> | <rt:source-protocol>rt:direct</rt:source-protocol> | |||
</rt:routing-protocol> | <rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | |||
</rt:routing-protocols> | </rt:route> | |||
<rt:ribs> | <rt:route> | |||
<rt:rib> | <v4ur:destination-prefix>198.51.100.0/24</v4ur:destination-prefix> | |||
<rt:name>ipv4-master</rt:name> | <rt:next-hop> | |||
<rt:address-family>v4ur:ipv4-unicast</rt:address-family> | <rt:outgoing-interface>eth1</rt:outgoing-interface> | |||
<rt:default-rib>true</rt:default-rib> | </rt:next-hop> | |||
<rt:routes> | <rt:source-protocol>rt:direct</rt:source-protocol> | |||
<rt:route> | <rt:route-preference>0</rt:route-preference> | |||
<v4ur:destination-prefix> | <rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | |||
192.0.2.1/24 | </rt:route> | |||
</v4ur:destination-prefix> | <rt:route> | |||
<rt:next-hop> | <v4ur:destination-prefix>0.0.0.0/0</v4ur:destination-prefix> | |||
<rt:outgoing-interface>eth0</rt:outgoing-interface> | <rt:source-protocol>rt:static</rt:source-protocol> | |||
</rt:next-hop> | <rt:route-preference>5</rt:route-preference> | |||
<rt:route-preference>0</rt:route-preference> | <rt:next-hop> | |||
<rt:source-protocol>rt:direct</rt:source-protocol> | <v4ur:next-hop-address>192.0.2.2</v4ur:next-hop-address> | |||
<rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | </rt:next-hop> | |||
</rt:route> | <rt:last-updated>2015-10-24T18:02:45+02:00</rt:last-updated> | |||
<rt:route> | </rt:route> | |||
<v4ur:destination-prefix> | </rt:routes> | |||
198.51.100.0/24 | </rt:rib> | |||
</v4ur:destination-prefix> | <rt:rib> | |||
<rt:next-hop> | <rt:name>ipv6-master</rt:name> | |||
<rt:outgoing-interface>eth1</rt:outgoing-interface> | <rt:address-family>v6ur:ipv6-unicast</rt:address-family> | |||
</rt:next-hop> | <rt:default-rib>true</rt:default-rib> | |||
<rt:source-protocol>rt:direct</rt:source-protocol> | <rt:routes> | |||
<rt:route-preference>0</rt:route-preference> | <rt:route> | |||
<rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | <v6ur:destination-prefix>2001:db8:0:1::/64</v6ur:destination-prefix> | |||
</rt:route> | <rt:next-hop> | |||
<rt:route> | <rt:outgoing-interface>eth0</rt:outgoing-interface> | |||
<v4ur:destination-prefix>0.0.0.0/0</v4ur:destination-prefix> | </rt:next-hop> | |||
<rt:source-protocol>rt:static</rt:source-protocol> | <rt:source-protocol>rt:direct</rt:source-protocol> | |||
<rt:route-preference>5</rt:route-preference> | <rt:route-preference>0</rt:route-preference> | |||
<rt:next-hop> | <rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | |||
<v4ur:next-hop-address>192.0.2.2</v4ur:next-hop-address> | </rt:route> | |||
</rt:next-hop> | <rt:route> | |||
<rt:last-updated>2015-10-24T18:02:45+02:00</rt:last-updated> | <v6ur:destination-prefix>2001:db8:0:2::/64</v6ur:destination-prefix> | |||
</rt:route> | <rt:next-hop> | |||
</rt:routes> | <rt:outgoing-interface>eth1</rt:outgoing-interface> | |||
</rt:rib> | </rt:next-hop> | |||
<rt:rib> | <rt:source-protocol>rt:direct</rt:source-protocol> | |||
<rt:name>ipv6-master</rt:name> | <rt:route-preference>0</rt:route-preference> | |||
<rt:address-family>v6ur:ipv6-unicast</rt:address-family> | <rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | |||
<rt:default-rib>true</rt:default-rib> | </rt:route> | |||
<rt:routes> | <rt:route> | |||
<rt:route> | <v6ur:destination-prefix>::/0</v6ur:destination-prefix> | |||
<v6ur:destination-prefix> | <rt:next-hop> | |||
2001:db8:0:1::/64 | <v6ur:next-hop-address>2001:db8:0:1::2</v6ur:next-hop-address> | |||
</v6ur:destination-prefix> | </rt:next-hop> | |||
<rt:next-hop> | <rt:source-protocol>rt:static</rt:source-protocol> | |||
<rt:outgoing-interface>eth0</rt:outgoing-interface> | <rt:route-preference>5</rt:route-preference> | |||
</rt:next-hop> | <rt:last-updated>2015-10-24T18:02:45+02:00</rt:last-updated> | |||
<rt:source-protocol>rt:direct</rt:source-protocol> | </rt:route> | |||
<rt:route-preference>0</rt:route-preference> | </rt:routes> | |||
<rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | </rt:rib> | |||
</rt:route> | </rt:ribs> | |||
<rt:route> | </rt:routing-state> | |||
<v6ur:destination-prefix> | </data> | |||
2001:db8:0:2::/64 | </rpc-reply> | |||
</v6ur:destination-prefix> | ||||
<rt:next-hop> | <!-- Local Variables: --> | |||
<rt:outgoing-interface>eth1</rt:outgoing-interface> | <!-- nxml-child-indent: 1 --> | |||
</rt:next-hop> | <!-- End: --> | |||
<rt:source-protocol>rt:direct</rt:source-protocol> | ||||
<rt:route-preference>0</rt:route-preference> | ||||
<rt:last-updated>2015-10-24T17:11:27+02:00</rt:last-updated> | ||||
</rt:route> | ||||
<rt:route> | ||||
<v6ur:destination-prefix>::/0</v6ur:destination-prefix> | ||||
<rt:next-hop> | ||||
<v6ur:next-hop-address> | ||||
2001:db8:0:1::2 | ||||
</v6ur:next-hop-address> | ||||
</rt:next-hop> | ||||
<rt:source-protocol>rt:static</rt:source-protocol> | ||||
<rt:route-preference>5</rt:route-preference> | ||||
<rt:last-updated>2015-10-24T18:02:45+02:00</rt:last-updated> | ||||
</rt:route> | ||||
</rt:routes> | ||||
</rt:rib> | ||||
</rt:ribs> | ||||
</rt:routing-instance> | ||||
</rt:routing-state> | ||||
</data> | ||||
</rpc-reply> | ||||
Appendix E. Change Log | Appendix E. Change Log | |||
RFC Editor: Remove this section upon publication as an RFC. | RFC Editor: Remove this section upon publication as an RFC. | |||
E.1. Changes Between Versions -19 and -20 | E.1. Changes Between Versions -20 and -21 | |||
o Routing instances were removed. | ||||
o IPv6 RA parameters were moved to the "ietf-ipv6-router- | ||||
advertisements". | ||||
E.2. Changes Between Versions -19 and -20 | ||||
o Assignment of L3 interfaces to routing instances is now part of | o Assignment of L3 interfaces to routing instances is now part of | |||
interface configuration. | interface configuration. | |||
o Next-hop options in configuration were aligned with state data. | o Next-hop options in configuration were aligned with state data. | |||
o It is recommended to enclose protocol-specific configuration in a | o It is recommended to enclose protocol-specific configuration in a | |||
presence container. | presence container. | |||
E.2. Changes Between Versions -18 and -19 | E.3. Changes Between Versions -18 and -19 | |||
o The leaf "route-preference" was removed from the "routing- | o The leaf "route-preference" was removed from the "routing- | |||
protocol" container in both "routing" and "routing-state". | protocol" container in both "routing" and "routing-state". | |||
o The "vrf-routing-instance" identity was added in support of a | o The "vrf-routing-instance" identity was added in support of a | |||
common routing-instance type in addition to the "default-routing- | common routing-instance type in addition to the "default-routing- | |||
instance". | instance". | |||
o Removed "enabled" switch from "routing-protocol". | o Removed "enabled" switch from "routing-protocol". | |||
E.3. Changes Between Versions -17 and -18 | E.4. Changes Between Versions -17 and -18 | |||
o The container "ribs" was moved under "routing-instance" (in both | o The container "ribs" was moved under "routing-instance" (in both | |||
"routing" and "routing-state"). | "routing" and "routing-state"). | |||
o Typedefs "rib-ref" and "rib-state-ref" were removed. | o Typedefs "rib-ref" and "rib-state-ref" were removed. | |||
o Removed "recipient-ribs" (both state and configuration). | o Removed "recipient-ribs" (both state and configuration). | |||
o Removed "connected-ribs" from "routing-protocol" (both state and | o Removed "connected-ribs" from "routing-protocol" (both state and | |||
configuration). | configuration). | |||
skipping to change at page 62, line 22 ¶ | skipping to change at page 61, line 5 ¶ | |||
rather than list (both config and state). The opposite reference | rather than list (both config and state). The opposite reference | |||
from "if:interface" to "rt:routing-instance" was changed to a | from "if:interface" to "rt:routing-instance" was changed to a | |||
single leaf (an interface cannot belong to multiple routing | single leaf (an interface cannot belong to multiple routing | |||
instances). | instances). | |||
o Specification of a default RIB is now a simple flag under "rib" | o Specification of a default RIB is now a simple flag under "rib" | |||
(both config and state). | (both config and state). | |||
o Default RIBs are marked by a flag in state data. | o Default RIBs are marked by a flag in state data. | |||
E.4. Changes Between Versions -16 and -17 | E.5. Changes Between Versions -16 and -17 | |||
o Added Acee as a co-author. | o Added Acee as a co-author. | |||
o Removed all traces of route filters. | o Removed all traces of route filters. | |||
o Removed numeric IDs of list entries in state data. | o Removed numeric IDs of list entries in state data. | |||
o Removed all next-hop cases except "simple-next-hop" and "special- | o Removed all next-hop cases except "simple-next-hop" and "special- | |||
next-hop". | next-hop". | |||
o Removed feature "multipath-routes". | o Removed feature "multipath-routes". | |||
o Augmented "ietf-interfaces" module with a leaf-list of leafrefs | o Augmented "ietf-interfaces" module with a leaf-list of leafrefs | |||
pointing form state data of an interface entry to the routing | pointing form state data of an interface entry to the routing | |||
instance(s) to which the interface is assigned. | instance(s) to which the interface is assigned. | |||
E.5. Changes Between Versions -15 and -16 | E.6. Changes Between Versions -15 and -16 | |||
o Added 'type' as the second key component of 'routing-protocol', | o Added 'type' as the second key component of 'routing-protocol', | |||
both in configuration and state data. | both in configuration and state data. | |||
o The restriction of no more than one connected RIB per address | o The restriction of no more than one connected RIB per address | |||
family was removed. | family was removed. | |||
o Removed the 'id' key of routes in RIBs. This list has no keys | o Removed the 'id' key of routes in RIBs. This list has no keys | |||
anymore. | anymore. | |||
skipping to change at page 63, line 26 ¶ | skipping to change at page 62, line 9 ¶ | |||
o Added next-hop lists to state data. | o Added next-hop lists to state data. | |||
o Added two cases for specifying next-hops indirectly - via a new | o Added two cases for specifying next-hops indirectly - via a new | |||
RIB or a recursive list of next-hops. | RIB or a recursive list of next-hops. | |||
o Reorganized next-hop in static routes. | o Reorganized next-hop in static routes. | |||
o Removed all 'if-feature' statements from state data. | o Removed all 'if-feature' statements from state data. | |||
E.6. Changes Between Versions -14 and -15 | E.7. Changes Between Versions -14 and -15 | |||
o Removed all defaults from state data. | o Removed all defaults from state data. | |||
o Removed default from 'cur-hop-limit' in config. | o Removed default from 'cur-hop-limit' in config. | |||
E.7. Changes Between Versions -13 and -14 | E.8. Changes Between Versions -13 and -14 | |||
o Removed dependency of 'connected-ribs' on the 'multiple-ribs' | o Removed dependency of 'connected-ribs' on the 'multiple-ribs' | |||
feature. | feature. | |||
o Removed default value of 'cur-hop-limit' in state data. | o Removed default value of 'cur-hop-limit' in state data. | |||
o Moved parts of descriptions and all references on IPv6 RA | o Moved parts of descriptions and all references on IPv6 RA | |||
parameters from state data to configuration. | parameters from state data to configuration. | |||
o Added reference to RFC 6536 in the Security section. | o Added reference to RFC 6536 in the Security section. | |||
E.8. Changes Between Versions -12 and -13 | E.9. Changes Between Versions -12 and -13 | |||
o Wrote appendix about minimum implementation. | o Wrote appendix about minimum implementation. | |||
o Remove "when" statement for IPv6 router interface state data - it | o Remove "when" statement for IPv6 router interface state data - it | |||
was dependent on a config value that may not be present. | was dependent on a config value that may not be present. | |||
o Extra container for the next-hop list. | o Extra container for the next-hop list. | |||
o Names rather than numeric ids are used for referring to list | o Names rather than numeric ids are used for referring to list | |||
entries in state data. | entries in state data. | |||
skipping to change at page 64, line 23 ¶ | skipping to change at page 63, line 5 ¶ | |||
o | o | |||
o Removed "if-feature multiple-ribs;" from connected-ribs. | o Removed "if-feature multiple-ribs;" from connected-ribs. | |||
o "rib-name" instead of "name" is used as the name of leafref nodes. | o "rib-name" instead of "name" is used as the name of leafref nodes. | |||
o "next-hop" instead of "nexthop" or "gateway" used throughout, both | o "next-hop" instead of "nexthop" or "gateway" used throughout, both | |||
in node names and text. | in node names and text. | |||
E.9. Changes Between Versions -11 and -12 | E.10. Changes Between Versions -11 and -12 | |||
o Removed feature "advanced-router" and introduced two features | o Removed feature "advanced-router" and introduced two features | |||
instead: "multiple-ribs" and "multipath-routes". | instead: "multiple-ribs" and "multipath-routes". | |||
o Unified the keys of config and state versions of "routing- | o Unified the keys of config and state versions of "routing- | |||
instance" and "rib" lists. | instance" and "rib" lists. | |||
o Numerical identifiers of state list entries are not keys anymore, | o Numerical identifiers of state list entries are not keys anymore, | |||
but they are constrained using the "unique" statement. | but they are constrained using the "unique" statement. | |||
o Updated acknowledgements. | o Updated acknowledgements. | |||
E.10. Changes Between Versions -10 and -11 | E.11. Changes Between Versions -10 and -11 | |||
o Migrated address families from IANA enumerations to identities. | o Migrated address families from IANA enumerations to identities. | |||
o Terminology and node names aligned with the I2RS RIB model: router | o Terminology and node names aligned with the I2RS RIB model: router | |||
-> routing instance, routing table -> RIB. | -> routing instance, routing table -> RIB. | |||
o Introduced uint64 keys for state lists: routing-instance, rib, | o Introduced uint64 keys for state lists: routing-instance, rib, | |||
route, nexthop. | route, nexthop. | |||
o Described the relationship between system-controlled and user- | o Described the relationship between system-controlled and user- | |||
skipping to change at page 65, line 13 ¶ | skipping to change at page 63, line 42 ¶ | |||
router". | router". | |||
o Made nexthop into a choice in order to allow for nexthop-list | o Made nexthop into a choice in order to allow for nexthop-list | |||
(I2RS requirement). | (I2RS requirement). | |||
o Added nexthop-list with entries having priorities (backup) and | o Added nexthop-list with entries having priorities (backup) and | |||
weights (load balancing). | weights (load balancing). | |||
o Updated bibliography references. | o Updated bibliography references. | |||
E.11. Changes Between Versions -09 and -10 | E.12. Changes Between Versions -09 and -10 | |||
o Added subtree for state data ("/routing-state"). | o Added subtree for state data ("/routing-state"). | |||
o Terms "system-controlled entry" and "user-controlled entry" | o Terms "system-controlled entry" and "user-controlled entry" | |||
defined and used. | defined and used. | |||
o New feature "user-defined-routing-tables". Nodes that are useful | o New feature "user-defined-routing-tables". Nodes that are useful | |||
only with user-defined routing tables are now conditional. | only with user-defined routing tables are now conditional. | |||
o Added grouping "router-id". | o Added grouping "router-id". | |||
o In routing tables, "source-protocol" attribute of routes now | o In routing tables, "source-protocol" attribute of routes now | |||
reports only protocol type, and its datatype is "identityref". | reports only protocol type, and its datatype is "identityref". | |||
o Renamed "main-routing-table" to "default-routing-table". | o Renamed "main-routing-table" to "default-routing-table". | |||
E.12. Changes Between Versions -08 and -09 | E.13. Changes Between Versions -08 and -09 | |||
o Fixed "must" expression for "connected-routing-table". | o Fixed "must" expression for "connected-routing-table". | |||
o Simplified "must" expression for "main-routing-table". | o Simplified "must" expression for "main-routing-table". | |||
o Moved per-interface configuration of a new routing protocol under | o Moved per-interface configuration of a new routing protocol under | |||
'routing-protocol'. This also affects the 'example-rip' module. | 'routing-protocol'. This also affects the 'example-rip' module. | |||
E.13. Changes Between Versions -07 and -08 | E.14. Changes Between Versions -07 and -08 | |||
o Changed reference from RFC6021 to RFC6021bis. | o Changed reference from RFC6021 to RFC6021bis. | |||
E.14. Changes Between Versions -06 and -07 | E.15. Changes Between Versions -06 and -07 | |||
o The contents of <get-reply> in Appendix D was updated: "eth[01]" | o The contents of <get-reply> in Appendix D was updated: "eth[01]" | |||
is used as the value of "location", and "forwarding" is on for | is used as the value of "location", and "forwarding" is on for | |||
both interfaces and both IPv4 and IPv6. | both interfaces and both IPv4 and IPv6. | |||
o The "must" expression for "main-routing-table" was modified to | o The "must" expression for "main-routing-table" was modified to | |||
avoid redundant error messages reporting address family mismatch | avoid redundant error messages reporting address family mismatch | |||
when "name" points to a non-existent routing table. | when "name" points to a non-existent routing table. | |||
o The default behavior for IPv6 RA prefix advertisements was | o The default behavior for IPv6 RA prefix advertisements was | |||
clarified. | clarified. | |||
o Changed type of "rt:router-id" to "ip:dotted-quad". | o Changed type of "rt:router-id" to "ip:dotted-quad". | |||
o Type of "rt:router-id" changed to "yang:dotted-quad". | o Type of "rt:router-id" changed to "yang:dotted-quad". | |||
o Fixed missing prefixes in XPath expressions. | o Fixed missing prefixes in XPath expressions. | |||
E.15. Changes Between Versions -05 and -06 | E.16. Changes Between Versions -05 and -06 | |||
o Document title changed: "Configuration" was replaced by | o Document title changed: "Configuration" was replaced by | |||
"Management". | "Management". | |||
o New typedefs "routing-table-ref" and "route-filter-ref". | o New typedefs "routing-table-ref" and "route-filter-ref". | |||
o Double slashes "//" were removed from XPath expressions and | o Double slashes "//" were removed from XPath expressions and | |||
replaced with the single "/". | replaced with the single "/". | |||
o Removed uniqueness requirement for "router-id". | o Removed uniqueness requirement for "router-id". | |||
skipping to change at page 66, line 36 ¶ | skipping to change at page 65, line 15 ¶ | |||
o Complete data tree is now in Appendix A. | o Complete data tree is now in Appendix A. | |||
o Changed type of "source-protocol" from "leafref" to "string". | o Changed type of "source-protocol" from "leafref" to "string". | |||
o Clarified the relationship between routing protocol instances and | o Clarified the relationship between routing protocol instances and | |||
connected routing tables. | connected routing tables. | |||
o Added a must constraint saying that a routing table connected to | o Added a must constraint saying that a routing table connected to | |||
the direct pseudo-protocol must not be a main routing table. | the direct pseudo-protocol must not be a main routing table. | |||
E.16. Changes Between Versions -04 and -05 | E.17. Changes Between Versions -04 and -05 | |||
o Routing tables are now global, i.e., "routing-tables" is a child | o Routing tables are now global, i.e., "routing-tables" is a child | |||
of "routing" rather than "router". | of "routing" rather than "router". | |||
o "must" statement for "static-routes" changed to "when". | o "must" statement for "static-routes" changed to "when". | |||
o Added "main-routing-tables" containing references to main routing | o Added "main-routing-tables" containing references to main routing | |||
tables for each address family. | tables for each address family. | |||
o Removed the defaults for "address-family" and "safi" and made them | o Removed the defaults for "address-family" and "safi" and made them | |||
skipping to change at page 67, line 24 ¶ | skipping to change at page 66, line 5 ¶ | |||
o The "direct" pseudo-protocol is always connected to main routing | o The "direct" pseudo-protocol is always connected to main routing | |||
tables. | tables. | |||
o Entries in the list of connected routing tables renamed from | o Entries in the list of connected routing tables renamed from | |||
"routing-table" to "connected-routing-table". | "routing-table" to "connected-routing-table". | |||
o Added "must" constraint saying that a routing table must not be | o Added "must" constraint saying that a routing table must not be | |||
its own recipient. | its own recipient. | |||
E.17. Changes Between Versions -03 and -04 | E.18. Changes Between Versions -03 and -04 | |||
o Changed "error-tag" for both RPC operations from "missing element" | o Changed "error-tag" for both RPC operations from "missing element" | |||
to "data-missing". | to "data-missing". | |||
o Removed the decrementing behavior for advertised IPv6 prefix | o Removed the decrementing behavior for advertised IPv6 prefix | |||
parameters "valid-lifetime" and "preferred-lifetime". | parameters "valid-lifetime" and "preferred-lifetime". | |||
o Changed the key of the static route lists from "seqno" to "id" | o Changed the key of the static route lists from "seqno" to "id" | |||
because the routes needn't be sorted. | because the routes needn't be sorted. | |||
o Added 'must' constraint saying that "preferred-lifetime" must not | o Added 'must' constraint saying that "preferred-lifetime" must not | |||
be greater than "valid-lifetime". | be greater than "valid-lifetime". | |||
E.18. Changes Between Versions -02 and -03 | E.19. Changes Between Versions -02 and -03 | |||
o Module "iana-afn-safi" moved to I-D "iana-if-type". | o Module "iana-afn-safi" moved to I-D "iana-if-type". | |||
o Removed forwarding table. | o Removed forwarding table. | |||
o RPC "get-route" changed to "active-route". Its output is a list | o RPC "get-route" changed to "active-route". Its output is a list | |||
of routes (for multi-path routing). | of routes (for multi-path routing). | |||
o New RPC "route-count". | o New RPC "route-count". | |||
skipping to change at page 68, line 22 ¶ | skipping to change at page 67, line 5 ¶ | |||
"ietf-ip". | "ietf-ip". | |||
o Added "router-id" leaf. | o Added "router-id" leaf. | |||
o Specified the names for IPv4/IPv6 unicast main routing tables. | o Specified the names for IPv4/IPv6 unicast main routing tables. | |||
o Route parameter "last-modified" changed to "age". | o Route parameter "last-modified" changed to "age". | |||
o Added container "recipient-routing-tables". | o Added container "recipient-routing-tables". | |||
E.19. Changes Between Versions -01 and -02 | E.20. Changes Between Versions -01 and -02 | |||
o Added module "ietf-ipv6-unicast-routing". | o Added module "ietf-ipv6-unicast-routing". | |||
o The example in Appendix D now uses IP addresses from blocks | o The example in Appendix D now uses IP addresses from blocks | |||
reserved for documentation. | reserved for documentation. | |||
o Direct routes appear by default in the forwarding table. | o Direct routes appear by default in the forwarding table. | |||
o Network layer interfaces must be assigned to a router instance. | o Network layer interfaces must be assigned to a router instance. | |||
Additional interface configuration may be present. | Additional interface configuration may be present. | |||
skipping to change at page 68, line 46 ¶ | skipping to change at page 67, line 29 ¶ | |||
o Additional "must" statements were added. | o Additional "must" statements were added. | |||
o The "route-content" grouping for IPv4 and IPv6 unicast now | o The "route-content" grouping for IPv4 and IPv6 unicast now | |||
includes the material from the "ietf-routing" version via "uses | includes the material from the "ietf-routing" version via "uses | |||
rt:route-content". | rt:route-content". | |||
o Explanation of symbols in the tree representation of data model | o Explanation of symbols in the tree representation of data model | |||
hierarchy. | hierarchy. | |||
E.20. Changes Between Versions -00 and -01 | E.21. Changes Between Versions -00 and -01 | |||
o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. | o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. | |||
o Typedefs for AFN and SAFI were placed in a separate "iana-afn- | o Typedefs for AFN and SAFI were placed in a separate "iana-afn- | |||
safi" module. | safi" module. | |||
o Names of some data nodes were changed, in particular "routing- | o Names of some data nodes were changed, in particular "routing- | |||
process" is now "router". | process" is now "router". | |||
o The restriction of a single AFN/SAFI per router was lifted. | o The restriction of a single AFN/SAFI per router was lifted. | |||
End of changes. 150 change blocks. | ||||
1128 lines changed or deleted | 1015 lines changed or added | |||
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |