idnits 2.17.1 draft-ietf-netmod-routing-cfg-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2653 has weird spacing: '...-family ide...' == Line 2689 has weird spacing: '...ib-name rib...' == Line 2693 has weird spacing: '...-prefix ine...' == Line 2705 has weird spacing: '...-prefix ine...' == Line 2718 has weird spacing: '...-family ide...' == (6 more instances...) -- The document date (March 04, 2015) is 3339 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track A. Lindem 5 Expires: September 5, 2015 Cisco Systems 6 March 04, 2015 8 A YANG Data Model for Routing Management 9 draft-ietf-netmod-routing-cfg-17 11 Abstract 13 This document contains a specification of three YANG modules. 14 Together they form the core routing data model which serves as a 15 framework for configuring and managing a routing subsystem. It is 16 expected that these modules will be augmented by additional YANG 17 modules defining data models for routing protocols and other 18 functions. The core routing data model provides common building 19 blocks for such extensions - routing instances, routes, routing 20 information bases (RIB), and routing protocols. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 5, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 58 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 59 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 61 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. The Design of the Core Routing Data Model . . . . . . . . . . 6 63 4.1. System-Controlled and User-Controlled List Entries . . . 9 64 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Routing Instance . . . . . . . . . . . . . . . . . . . . 10 66 5.1.1. Parameters of IPv6 Routing Instance Interfaces . . . 11 67 5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.3. Routing Information Base (RIB) . . . . . . . . . . . . . 13 69 5.3.1. Multiple RIBs per Address Family . . . . . . . . . . 14 70 5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 14 71 5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 15 72 5.4.2. Defining New Routing Protocols . . . . . . . . . . . 15 73 5.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 16 74 6. Interactions with Other YANG Modules . . . . . . . . . . . . 17 75 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 17 76 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 17 77 7. Routing Management YANG Module . . . . . . . . . . . . . . . 18 78 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 36 79 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 40 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 82 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 55 85 13.2. Informative References . . . . . . . . . . . . . . . . . 56 86 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 56 87 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 56 88 A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 58 89 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 59 90 Appendix C. Example: Adding a New Routing Protocol . . . . . . . 60 91 Appendix D. Example: NETCONF Reply . . . . . . . . . . . . 62 92 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 69 93 E.1. Changes Between Versions -16 and -17 . . . . . . . . . . 69 94 E.2. Changes Between Versions -15 and -16 . . . . . . . . . . 69 95 E.3. Changes Between Versions -14 and -15 . . . . . . . . . . 70 96 E.4. Changes Between Versions -13 and -14 . . . . . . . . . . 70 97 E.5. Changes Between Versions -12 and -13 . . . . . . . . . . 70 98 E.6. Changes Between Versions -11 and -12 . . . . . . . . . . 71 99 E.7. Changes Between Versions -10 and -11 . . . . . . . . . . 71 100 E.8. Changes Between Versions -09 and -10 . . . . . . . . . . 72 101 E.9. Changes Between Versions -08 and -09 . . . . . . . . . . 72 102 E.10. Changes Between Versions -07 and -08 . . . . . . . . . . 72 103 E.11. Changes Between Versions -06 and -07 . . . . . . . . . . 72 104 E.12. Changes Between Versions -05 and -06 . . . . . . . . . . 73 105 E.13. Changes Between Versions -04 and -05 . . . . . . . . . . 73 106 E.14. Changes Between Versions -03 and -04 . . . . . . . . . . 74 107 E.15. Changes Between Versions -02 and -03 . . . . . . . . . . 74 108 E.16. Changes Between Versions -01 and -02 . . . . . . . . . . 75 109 E.17. Changes Between Versions -00 and -01 . . . . . . . . . . 75 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 112 1. Introduction 114 This document contains a specification of the following YANG modules: 116 o Module "ietf-routing" provides generic components of a routing 117 data model. 119 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 120 module with additional data specific to IPv4 unicast. 122 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 123 module with additional data specific to IPv6 unicast, including 124 the router configuration variables required by [RFC4861]. 126 These modules together define the so-called core routing data model, 127 which is intended as a basis for future data model development 128 covering more sophisticated routing systems. While these three 129 modules can be directly used for simple IP devices with static 130 routing (see Appendix B), their main purpose is to provide essential 131 building blocks for more complicated data models involving multiple 132 routing protocols, multicast routing, additional address families, 133 and advanced functions such as route filtering or policy routing. To 134 this end, it is expected that the core routing data model will be 135 augmented by numerous modules developed by other IETF working groups. 137 2. Terminology and Notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 The following terms are defined in [RFC6241]: 145 o client 147 o message 149 o protocol operation 151 o server 153 The following terms are defined in [RFC6020]: 155 o augment 157 o configuration data 159 o data model 161 o data node 163 o feature 165 o mandatory node 167 o module 169 o state data 171 o RPC operation 173 2.1. Glossary of New Terms 175 core routing data model: YANG data model comprising "ietf-routing", 176 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 177 modules. 179 direct route: a route to a directly connected network. 181 routing information base (RIB): An object containing a list of 182 routes together with other information. See Section 5.3 for 183 details. 185 system-controlled entry: An entry of a list in state data ("config 186 false") that is created by the system independently of what has 187 been explicitly configured. See Section 4.1 for details. 189 user-controlled entry: An entry of a list in state data ("config 190 false") that is created and deleted as a direct consequence of 191 certain configuration changes. See Section 4.1 for details. 193 2.2. Tree Diagrams 195 A simplified graphical representation of the complete data tree is 196 presented in Appendix A, and similar diagrams of its various subtrees 197 appear in the main text. 199 The meaning of the symbols in these diagrams is as follows: 201 o Brackets "[" and "]" enclose list keys. 203 o Curly braces "{" and "}" contain names of optional features that 204 make the corresponding node conditional. 206 o Abbreviations before data node names: "rw" means configuration 207 (read-write), "ro" state data (read-only), "-x" RPC operations, 208 and "-n" notifications. 210 o Symbols after data node names: "?" means an optional node, "!" a 211 container with presence, and "*" denotes a "list" or "leaf-list". 213 o Parentheses enclose choice and case nodes, and case nodes are also 214 marked with a colon (":"). 216 o Ellipsis ("...") stands for contents of subtrees that are not 217 shown. 219 2.3. Prefixes in Data Node Names 221 In this document, names of data nodes, RPC operations and other data 222 model objects are often used without a prefix, as long as it is clear 223 from the context in which YANG module each name is defined. 224 Otherwise, names are prefixed using the standard prefix associated 225 with the corresponding YANG module, as shown in Table 1. 227 +--------+---------------------------+-----------+ 228 | Prefix | YANG module | Reference | 229 +--------+---------------------------+-----------+ 230 | if | ietf-interfaces | [RFC7223] | 231 | ip | ietf-ip | [RFC7277] | 232 | rt | ietf-routing | Section 7 | 233 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 234 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 235 | yang | ietf-yang-types | [RFC6991] | 236 | inet | ietf-inet-types | [RFC6991] | 237 +--------+---------------------------+-----------+ 239 Table 1: Prefixes and corresponding YANG modules 241 3. Objectives 243 The initial design of the core routing data model was driven by the 244 following objectives: 246 o The data model should be suitable for the common address families, 247 in particular IPv4 and IPv6, and for unicast and multicast 248 routing, as well as Multiprotocol Label Switching (MPLS). 250 o Simple routing set-ups, such as static routing, should be 251 configurable in a simple way, ideally without any need to develop 252 additional YANG modules. 254 o On the other hand, the core routing framework must allow for 255 complicated set-ups involving multiple routing information bases 256 (RIB) and multiple routing protocols, as well as controlled 257 redistributions of routing information. 259 o Device vendors will want to map the data models built on this 260 generic framework to their proprietary data models and 261 configuration interfaces. Therefore, the framework should be 262 flexible enough to facilitate such a mapping and accommodate data 263 models with different logic. 265 4. The Design of the Core Routing Data Model 267 The core routing data model consists of three YANG modules. The 268 first module, "ietf-routing", defines the generic components of a 269 routing system. The other two modules, "ietf-ipv4-unicast-routing" 270 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 271 with additional data nodes that are needed for IPv4 and IPv6 unicast 272 routing, respectively. Figures 1 and 2 show abridged views of the 273 configuration and state data hierarchies. See Appendix A for the 274 complete data trees. 276 +--rw routing 277 +--rw routing-instance* [name] 278 | +--rw name 279 | +--rw type? 280 | +--rw enabled? 281 | +--rw router-id? 282 | +--rw description? 283 | +--rw default-ribs 284 | | +--rw default-rib* [address-family] 285 | | +--rw address-family 286 | | +--rw rib-name 287 | +--rw interfaces 288 | | +--rw interface* [name] 289 | | +--rw name 290 | | +--rw v6ur:ipv6-router-advertisements 291 | | ... 292 | +--rw routing-protocols 293 | +--rw routing-protocol* [type name] 294 | +--rw type 295 | +--rw name 296 | +--rw description? 297 | +--rw enabled? 298 | +--rw route-preference? 299 | +--rw connected-ribs 300 | | ... 301 | +--rw static-routes 302 | ... 303 +--rw ribs 304 +--rw rib* [name] 305 +--rw name 306 +--rw address-family 307 +--rw description? 308 +--rw recipient-ribs 309 +--rw recipient-rib* [rib-name] 310 ... 312 Figure 1: Configuration data hierarchy. 314 +--ro routing-state 315 +--ro routing-instance* [name] 316 | +--ro name 317 | +--ro type? 318 | +--ro default-ribs 319 | | +--ro default-rib* [address-family] 320 | | +--ro address-family 321 | | +--ro rib-name 322 | +--ro interfaces 323 | | +--ro interface* [name] 324 | | +--ro name 325 | | +--ro v6ur:ipv6-router-advertisements 326 | | ... 327 | +--ro routing-protocols 328 | +--ro routing-protocol* [type name] 329 | +--ro type 330 | +--ro name 331 | +--ro route-preference 332 | +--ro connected-ribs 333 | ... 334 +--ro ribs 335 +--ro rib* [name] 336 +--ro name 337 +--ro address-family 338 +--ro routes 339 | +--ro route* 340 | ... 341 +--ro recipient-ribs 342 +--ro recipient-rib* [rib-name] 343 ... 345 Figure 2: State data hierarchy. 347 As can be seen from Figures 1 and 2, the core routing data model 348 introduces several generic components of a routing framework: routing 349 instances, RIBs containing lists of routes, and routing protocols. 350 The following subsections describe these components in more detail. 352 By combining the components in various ways, and possibly augmenting 353 them with appropriate contents defined in other modules, various 354 routing systems can be realized. 356 +--------+ 357 | direct | +--------------+ +--------------+ 358 | routes |------>| |<------| | 359 +--------+ | default | | additional | 360 | RIB | | RIB | 361 +--------+ | | | | 362 | static |------>| |------>| | 363 | routes | +--------------+ +--------------+ 364 +--------+ ^ | ^ | 365 | | | | 366 | v | v 367 +----------+ +----------+ 368 | routing | | routing | 369 | protocol | | protocol | 370 +----------+ +----------+ 372 Figure 3: Example set-up of a routing system 374 The example in Figure 3 shows a typical (though certainly not the 375 only possible) organization of a more complex routing subsystem for a 376 single address family. Several of its features are worth mentioning: 378 o Along with the default RIB, which is always present, an additional 379 RIB is configured. 381 o Each routing protocol instance, including the "static" and 382 "direct" pseudo-protocols, is connected to one or more RIBs with 383 which it can exchange routes (in both directions, except for the 384 "static" and "direct" pseudo-protocols). 386 o RIBs may also be connected to each other and exchange routes in 387 either direction (or both). 389 4.1. System-Controlled and User-Controlled List Entries 391 The core routing data model defines several lists, for example 392 "routing-instance" or "rib", that have to be populated with at least 393 one entry in any properly functioning device, and additional entries 394 may be configured by the user. 396 In such a list, the server creates the required item as a so-called 397 system-controlled entry in state data, i.e., inside the "routing- 398 state" container. 400 Additional entries may be created in the configuration by the user, 401 e.g., via the NETCONF protocol. These are so-called user-controlled 402 entries. If the server accepts a configured user-controlled entry, 403 then this entry also appears in the state data version of the list. 405 Corresponding entries in both versions of the list (in state data and 406 configuration) have the same value of the list key. 408 The user may also provide supplemental configuration of system- 409 controlled entries. To do so, the user creates a new entry in the 410 configuration with the desired contents. In order to bind this entry 411 with the corresponding entry in the state data list, the key of the 412 configuration entry has to be set to the same value as the key of the 413 state entry. 415 An example can be seen in Appendix D: the "/routing-state/routing- 416 instance" list has a single system-controlled entry whose "name" key 417 has the value "rtr0". This entry is configured by the "/routing/ 418 routing-instance" entry whose "name" key is also "rtr0". 420 Deleting a user-controlled entry from the configuration list results 421 in the removal of the corresponding entry in the state data list. In 422 contrast, if a system-controlled entry is deleted from the 423 configuration list, only the extra configuration specified in that 424 entry is removed but the corresponding state data entry remains in 425 the list. 427 5. Basic Building Blocks 429 This section describes the essential components of the core routing 430 data model. 432 5.1. Routing Instance 434 The core routing data model supports one or more routing instances 435 appearing as entries of the "routing-instance" list. Each routing 436 instance has separate configuration and state data under 437 "/rt:routing/rt:routing-instance" and "/rt:routing-state/rt:routing- 438 instance", respectively. 440 The semantics of the term "routing instance" is deliberately left 441 undefined. It is expected that future YANG modules will define data 442 models for specific types of routing instances, such as VRF (virtual 443 routing and forwarding) instances that are used for BGP/MPLS virtual 444 private networks [RFC4364]. For each type of routing instance, an 445 identity derived from "rt:routing-instance" MUST be defined. This 446 identity is then referred to by the value of the "type" leaf (a child 447 node of "routing-instance" list). 449 An implementation MAY create one or more system-controlled routing 450 instances, and MAY also impose restrictions on types of routing 451 instances that can be configured, and on the maximum number of 452 supported instances for each type. For example, a simple router 453 implementation may support only one system-controlled routing 454 instance of the default type "rt:default-routing-instance" and may 455 not allow creation of any user-controlled instances. 457 Each network layer interface has to be assigned to one or more 458 routing instances in order to be able to participate in packet 459 forwarding, routing protocols and other operations of those routing 460 instances. The assignment is accomplished by placing a corresponding 461 (system- or user-controlled) entry in the list of routing instance 462 interfaces ("rt:interface"). The key of the list entry is the name 463 of a configured network layer interface, see the "ietf-interfaces" 464 module [RFC7223]. 466 A data model for a routing instance type MAY state additional rules 467 for the assignment of interfaces to routing instances of that type. 468 For example, it may be required that the sets of interfaces assigned 469 to different routing instances of a certain type be disjoint. 471 5.1.1. Parameters of IPv6 Routing Instance Interfaces 473 The module "ietf-ipv6-unicast-routing" augments the definition of the 474 data node "rt:interface", in both configuration and state data, with 475 definitions of the following variables as required by [RFC4861], sec. 476 6.2.1: 478 o send-advertisements, 480 o max-rtr-adv-interval, 482 o min-rtr-adv-interval, 484 o managed-flag, 486 o other-config-flag, 488 o link-mtu, 490 o reachable-time, 492 o retrans-timer, 494 o cur-hop-limit, 496 o default-lifetime, 498 o prefix-list: a list of prefixes to be advertised. 500 The following parameters are associated with each prefix in the 501 list: 503 * valid-lifetime, 505 * on-link-flag, 507 * preferred-lifetime, 509 * autonomous-flag. 511 The definitions and descriptions of the above parameters can be found 512 in the module "ietf-ipv6-unicast-routing" (Section 9). 514 NOTES: 516 1. The "IsRouter" flag, which is also required by [RFC4861], is 517 implemented in the "ietf-ip" module [RFC7277] (leaf 518 "ip:forwarding"). 520 2. The original specification [RFC4861] allows the implementations 521 to decide whether the "valid-lifetime" and "preferred-lifetime" 522 parameters remain the same in consecutive advertisements, or 523 decrement in real time. However, the latter behavior seems 524 problematic because the values might be reset again to the 525 (higher) configured values after a configuration is reloaded. 526 Moreover, no implementation is known to use the decrementing 527 behavior. The "ietf-ipv6-unicast-routing" module therefore 528 assumes the former behavior with constant values. 530 5.2. Route 532 Routes are basic elements of information in a routing system. The 533 core routing data model defines only the following minimal set of 534 route attributes: 536 o "destination-prefix": IP prefix specifying the set of destination 537 addresses for which the route may be used. This attribute is 538 mandatory. 540 o "route-preference": an integer value (also known as administrative 541 distance) that is used for selecting a preferred route among 542 routes with the same destination prefix. A lower value means a 543 more preferred route. 545 o "next-hop": determines the action to be performed with a packet. 546 See below for details. 548 The choice of next-hops comprises the following cases: 550 o simple next-hop - IP address of the next-hop router, outgoing 551 interface, or both. 553 o special next-hop - a keyword indicating special packet handling, 554 one of: 556 * "blackhole" - silently discard the packet; 558 * "unreachable" - discard the packet and notify the sender with a 559 "destination unreachable" error message; 561 * "prohibit" - discard the packet notify the sender with an 562 "administratively prohibited" error message. 564 It is expected that future YANG modules defining will augment routes 565 with more complex next-hop types, or additional attributes such as 566 metrics. 568 Routes are primarily state data that appear as entries of RIBs 569 (Section 5.3) but they may also be found in configuration data, for 570 example as manually configured static routes. In the latter case, 571 configurable route attributes are generally a subset of route 572 attributes described above. 574 5.3. Routing Information Base (RIB) 576 A routing information base (RIB) is a list of routes complemented 577 with administrative data, namely: 579 o "source-protocol": type of the routing protocol from which the 580 route was originally obtained. 582 o "active": an implementation can use this empty leaf to indicate 583 that the route is preferred among all routes in the same RIB that 584 have the same destination prefix. 586 o "last-updated": the date and time when the route was last updated, 587 or inserted into the RIB. 589 Each RIB MUST contain only routes of one address family. An address 590 family is represented by an identity derived from the "rt:address- 591 family" base identity. 593 In the core routing data model, RIBs are state data represented as 594 entries of the list "/routing-state/ribs/rib". The contents of RIBs 595 are controlled and manipulated by routing protocol operations which 596 may result in route additions, removals and modifications. This also 597 includes manipulations via the "static" and/or "direct" pseudo- 598 protocols, see Section 5.4.1. 600 RIBs are global, which means that a RIB may be used by any or all 601 routing instances. However, a data model for a routing instance type 602 MAY state rules and restrictions for sharing RIBs among routing 603 instances of that type. 605 Each routing instance has, for every supported address family, one 606 RIB selected as the so-called default RIB. This selection is 607 recorded in the list "default-rib". The role of default RIBs is 608 explained in Section 5.4. 610 Simple router implementations that do not advertise the feature 611 "multiple-ribs" will typically create one system-controlled RIB per 612 supported address family, and declare it as the default RIB (via a 613 system-controlled entry of the "default-rib" list). 615 5.3.1. Multiple RIBs per Address Family 617 More complex router implementations advertising the "multiple-ribs" 618 feature support multiple RIBs per address family that can be used for 619 policy routing and other purposes. Every RIB can then serve as a 620 source of routes for other RIBs of the same address family. To 621 achieve this, one or more recipient RIBs may be specified in the 622 configuration of the source RIB. 624 A RIB MUST NOT appear among its own recipient RIBs. 626 5.4. Routing Protocol 628 The core routing data model provides an open-ended framework for 629 defining multiple routing protocol instances within a routing 630 instance. Each routing protocol instance MUST be assigned a type, 631 which is an identity derived from the "rt:routing-protocol" base 632 identity. The core routing data model defines two identities for the 633 direct and static pseudo-protocols (Section 5.4.1). 635 Multiple routing protocol instances of the same type MAY be 636 configured within the same routing instance. 638 Each routing protocol instance can be connected to one or more RIBs 639 for each address family that the routing protocol instance supports. 640 By default, the interaction of a routing protocol instance with its 641 connected RIBs is governed by the following rules: 643 o Routes learned from the network are installed in all connected 644 RIBs with a matching address family. 646 o Conversely, routes from all connected RIBs are injected into the 647 routing protocol instance. 649 However, a data model for a routing protocol MAY impose specific 650 rules for exchanging routes between routing protocol instances and 651 connected RIBs. 653 On devices supporting the "multiple-ribs" feature, any RIB (system- 654 controlled or user-controlled) may be connected to a routing protocol 655 instance by configuring a corresponding entry in the "connected-rib" 656 list. If such an entry is not configured for an address family, then 657 the default RIB MUST be used as the connected RIB for this address 658 family. 660 5.4.1. Routing Pseudo-Protocols 662 The core routing data model defines two special routing protocol 663 types - "direct" and "static". Both are in fact pseudo-protocols, 664 which means they are confined to the local device and do not exchange 665 any routing information with adjacent routers. Routes from both 666 "direct" and "static" protocol instances are passed to the connected 667 RIBs, but an exchange in the opposite direction is not allowed. 669 Every routing instance MUST implement exactly one instance of the 670 "direct" pseudo-protocol type. It is the source of direct routes for 671 all configured address families. Direct routes are normally supplied 672 by the operating system kernel, based on the configuration of network 673 interface addresses, see Section 6.2. The "direct" pseudo-protocol 674 MUST always be connected to the default RIBs of all supported address 675 families. Unlike other routing protocol types, this connection 676 cannot be changed in the configuration. 678 A pseudo-protocol of the type "static" allows for specifying routes 679 manually. It MAY be configured in zero or multiple instances, 680 although a typical configuration will have exactly one instance per 681 routing instance. 683 5.4.2. Defining New Routing Protocols 685 It is expected that future YANG modules will create data models for 686 additional routing protocol types. Such a new module has to define 687 the protocol-specific configuration and state data, and it has to fit 688 it into the core routing framework in the following way: 690 o A new identity MUST be defined for the routing protocol and its 691 base identity MUST be set to "rt:routing-protocol", or to an 692 identity derived from "rt:routing-protocol". 694 o Additional route attributes MAY be defined, preferably in one 695 place by means of defining a YANG grouping. The new attributes 696 have to be inserted by augmenting the definitions of the nodes 698 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 700 and 702 /rt:fib-route/rt:output/rt:route, 704 and possibly other places in the configuration, state data, 705 notifications, and RPC input or output. 707 o Configuration parameters and/or state data for the new protocol 708 can be defined by augmenting the "routing-protocol" data node 709 under both "/routing" and "/routing-state". 711 o Per-interface configuration, including activation of the routing 712 protocol on individual interfaces, can use references to entries 713 in the list of routing instance interfaces (rt:interface). 715 By using the "when" statement, the augmented configuration parameters 716 and state data specific to the new protocol SHOULD be made 717 conditional and valid only if the value of "rt:type" or "rt:source- 718 protocol" is equal to the new protocol's identity. It is also 719 RECOMMENDED that protocol-specific data nodes be encapsulated in 720 appropriately named containers. 722 The above steps are implemented by the example YANG module for the 723 RIP routing protocol in Appendix C. 725 5.5. RPC Operations 727 The "ietf-routing" module defines two RPC operations: 729 o fib-route: query a routing instance for the active route in the 730 Forwarding Information Base (FIB). It is the route that is 731 currently used for sending datagrams to a destination host whose 732 address is passed as an input parameter. 734 o route-count: retrieve the total number of entries in a RIB. 736 6. Interactions with Other YANG Modules 738 The semantics of the core routing data model also depends on several 739 configuration parameters that are defined in other YANG modules. 741 6.1. Module "ietf-interfaces" 743 The following boolean switch is defined in the "ietf-interfaces" YANG 744 module [RFC7223]: 746 /if:interfaces/if:interface/if:enabled 748 If this switch is set to "false" for a network layer interface, 749 the device MUST behave exactly as if that interface was not 750 assigned to any routing instance at all. 752 6.2. Module "ietf-ip" 754 The following boolean switches are defined in the "ietf-ip" YANG 755 module [RFC7277]: 757 /if:interfaces/if:interface/ip:ipv4/ip:enabled 759 If this switch is set to "false" for a network layer interface, 760 then all IPv4 routing functions related to that interface MUST be 761 disabled. 763 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 765 If this switch is set to "false" for a network layer interface, 766 then the forwarding of IPv4 datagrams to and from this interface 767 MUST be disabled. However, the interface may participate in other 768 IPv4 routing functions, such as routing protocols. 770 /if:interfaces/if:interface/ip:ipv6/ip:enabled 772 If this switch is set to "false" for a network layer interface, 773 then all IPv6 routing functions related to that interface MUST be 774 disabled. 776 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 778 If this switch is set to "false" for a network layer interface, 779 then the forwarding of IPv6 datagrams to and from this interface 780 MUST be disabled. However, the interface may participate in other 781 IPv6 routing functions, such as routing protocols. 783 In addition, the "ietf-ip" module allows for configuring IPv4 and 784 IPv6 addresses and network prefixes or masks on network layer 785 interfaces. Configuration of these parameters on an enabled 786 interface MUST result in an immediate creation of the corresponding 787 direct route. The destination prefix of this route is set according 788 to the configured IP address and network prefix/mask, and the 789 interface is set as the outgoing interface for that route. 791 7. Routing Management YANG Module 793 RFC Editor: In this section, replace all occurrences of 'XXXX' with 794 the actual RFC number and all occurrences of the revision date below 795 with the date of RFC publication (and remove this note). 797 file "ietf-routing@2015-03-04.yang" 799 module ietf-routing { 801 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 803 prefix "rt"; 805 import ietf-yang-types { 806 prefix "yang"; 807 } 809 import ietf-interfaces { 810 prefix "if"; 811 } 813 organization 814 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 816 contact 817 "WG Web: 818 WG List: 820 WG Chair: Thomas Nadeau 821 823 WG Chair: Juergen Schoenwaelder 824 826 Editor: Ladislav Lhotka 827 "; 829 description 830 "This YANG module defines essential components for the management 831 of a routing subsystem. 833 Copyright (c) 2014 IETF Trust and the persons identified as 834 authors of the code. All rights reserved. 836 Redistribution and use in source and binary forms, with or 837 without modification, is permitted pursuant to, and subject to 838 the license terms contained in, the Simplified BSD License set 839 forth in Section 4.c of the IETF Trust's Legal Provisions 840 Relating to IETF Documents 841 (http://trustee.ietf.org/license-info). 843 This version of this YANG module is part of RFC XXXX; see the 844 RFC itself for full legal notices."; 846 revision 2015-03-04 { 847 description 848 "Initial revision."; 849 reference 850 "RFC XXXX: A YANG Data Model for Routing Management"; 851 } 853 /* Features */ 855 feature multiple-ribs { 856 description 857 "This feature indicates that the server supports user-defined 858 RIBS and the framework for passing routes between RIBs. 860 Servers that do not advertise this feature MUST provide 861 exactly one system-controlled RIB per supported address family 862 and make them also the default RIBs. These RIBs then appear as 863 entries of the list /routing-state/ribs/rib."; 864 } 866 feature router-id { 867 description 868 "This feature indicates that the server supports configuration 869 of an explicit 32-bit router ID that is used by some routing 870 protocols. 872 Servers that do not advertise this feature set a router ID 873 algorithmically, usually to one of configured IPv4 addresses. 874 However, this algorithm is implementation-specific."; 875 } 877 /* Identities */ 878 identity address-family { 879 description 880 "Base identity from which identities describing address 881 families are derived."; 882 } 884 identity ipv4 { 885 base address-family; 886 description 887 "This identity represents IPv4 address family."; 888 } 890 identity ipv6 { 891 base address-family; 892 description 893 "This identity represents IPv6 address family."; 894 } 896 identity routing-instance { 897 description 898 "Base identity from which identities describing routing 899 instance types are derived."; 900 } 902 identity default-routing-instance { 903 base routing-instance; 904 description 905 "This identity represents either a default routing instance, or 906 the only routing instance on systems that do not support 907 multiple instances."; 908 } 910 identity routing-protocol { 911 description 912 "Base identity from which routing protocol identities are 913 derived."; 914 } 916 identity direct { 917 base routing-protocol; 918 description 919 "Routing pseudo-protocol that provides routes to directly 920 connected networks."; 921 } 923 identity static { 924 base routing-protocol; 925 description 926 "Static routing pseudo-protocol."; 927 } 929 /* Type Definitions */ 931 typedef routing-instance-ref { 932 type leafref { 933 path "/rt:routing/rt:routing-instance/rt:name"; 934 } 935 description 936 "This type is used for leafs that reference a routing instance 937 configuration."; 938 } 940 typedef routing-instance-state-ref { 941 type leafref { 942 path "/rt:routing-state/rt:routing-instance/rt:name"; 943 } 944 description 945 "This type is used for leafs that reference state data of a 946 routing instance."; 947 } 949 typedef rib-ref { 950 type leafref { 951 path "/rt:routing/rt:ribs/rt:rib/rt:name"; 952 } 953 description 954 "This type is used for leafs that reference a RIB 955 configuration."; 956 } 958 typedef rib-state-ref { 959 type leafref { 960 path "/rt:routing-state/rt:ribs/rt:rib/rt:name"; 961 } 962 description 963 "This type is used for leafs that reference a RIB in state 964 data."; 965 } 967 typedef route-preference { 968 type uint32; 969 description 970 "This type is used for route preferences."; 971 } 973 /* Groupings */ 974 grouping address-family { 975 description 976 "This grouping provides a leaf identifying an address 977 family."; 978 leaf address-family { 979 type identityref { 980 base address-family; 981 } 982 mandatory "true"; 983 description 984 "Address family."; 985 } 986 } 988 grouping router-id { 989 description 990 "This grouping provides router ID."; 991 leaf router-id { 992 type yang:dotted-quad; 993 description 994 "A 32-bit number in the form of a dotted quad that is used by 995 some routing protocols identifying a router."; 996 reference 997 "RFC 2328: OSPF Version 2."; 998 } 999 } 1001 grouping special-next-hop { 1002 description 1003 "This grouping provides a leaf with an enumeration of special 1004 next-hops."; 1005 leaf special-next-hop { 1006 type enumeration { 1007 enum blackhole { 1008 description 1009 "Silently discard the packet."; 1010 } 1011 enum unreachable { 1012 description 1013 "Discard the packet and notify the sender with an error 1014 message indicating that the destination host is 1015 unreachable."; 1016 } 1017 enum prohibit { 1018 description 1019 "Discard the packet and notify the sender with an error 1020 message indicating that the communication is 1021 administratively prohibited."; 1023 } 1024 enum receive { 1025 description 1026 "The packet will be received by the local system."; 1027 } 1028 } 1029 description 1030 "Special next-hop options."; 1031 } 1032 } 1034 grouping next-hop-content { 1035 description 1036 "Generic parameters of next-hops in static routes."; 1037 choice next-hop-options { 1038 mandatory "true"; 1039 description 1040 "Options for next-hops in static routes. 1042 It is expected that other cases will be added through 1043 augments from other modules, e.g., for ECMP."; 1044 case simple-next-hop { 1045 description 1046 "Simple next-hop is specified as an outgoing interface, 1047 next-hop address or both. 1049 Address-family-specific modules are expected to provide 1050 'next-hop-address' leaf via augmentation."; 1051 leaf outgoing-interface { 1052 type leafref { 1053 path "/rt:routing/rt:routing-instance/rt:interfaces/" 1054 + "rt:interface/rt:name"; 1055 } 1056 description 1057 "Name of the outgoing interface."; 1058 } 1059 } 1060 case special-next-hop { 1061 uses special-next-hop; 1062 } 1063 } 1064 } 1066 grouping next-hop-state-content { 1067 description 1068 "Generic parameters of next-hops in state data."; 1069 choice next-hop-options { 1070 mandatory "true"; 1071 description 1072 "Options for next-hops in state data. 1074 It is expected that other cases will be added through 1075 augments from other modules, e.g., for ECMP or recursive 1076 next-hops."; 1077 case simple-next-hop { 1078 description 1079 "Simple next-hop is specified as an outgoing interface, 1080 next-hop address or both. 1082 Address-family-specific modules are expected to provide 1083 'next-hop-address' leaf via augmentation."; 1084 leaf outgoing-interface { 1085 type leafref { 1086 path "/rt:routing-state/rt:routing-instance/" 1087 + "rt:interfaces/rt:interface/rt:name"; 1088 } 1089 description 1090 "Name of the outgoing interface."; 1091 } 1092 } 1093 case special-next-hop { 1094 uses special-next-hop; 1095 } 1096 } 1097 } 1099 grouping route-metadata { 1100 description 1101 "Common route metadata."; 1102 leaf source-protocol { 1103 type identityref { 1104 base routing-protocol; 1105 } 1106 mandatory "true"; 1107 description 1108 "Type of the routing protocol from which the route 1109 originated."; 1110 } 1111 leaf active { 1112 type empty; 1113 description 1114 "Presence of this leaf indicates that the route is preferred 1115 among all routes in the same RIB that have the same 1116 destination prefix."; 1117 } 1118 leaf last-updated { 1119 type yang:date-and-time; 1120 description 1121 "Time stamp of the last modification of the route. If the 1122 route was never modified, it is the time when the route was 1123 inserted into the RIB."; 1124 } 1125 } 1127 /* State data */ 1129 augment "/if:interfaces-state/if:interface" { 1130 description 1131 "This augment adds a wrapped leaf-list to interface state 1132 data."; 1133 container routing-instances { 1134 description 1135 "The enclosed leaf-list provides references to all routing 1136 instances to which the parent interface is assigned. 1138 The assignments are configured as a part of routing-instance 1139 configuration (module ietf-routing)."; 1140 leaf-list routing-instance { 1141 type routing-instance-state-ref; 1142 must "../../if:name=/rt:routing-state/" 1143 + "rt:routing-instance[rt:name=current()]/rt:interfaces/" 1144 + "rt:interface/rt:name" { 1145 error-message "The interface is not assigned to the " 1146 + "routing instance."; 1147 description 1148 "The reference must mirror a corresponding assignment 1149 under routing-instance."; 1150 } 1151 description 1152 "Reference to a routing instance."; 1153 } 1154 } 1155 } 1157 container routing-state { 1158 config "false"; 1159 description 1160 "State data of the routing subsystem."; 1161 list routing-instance { 1162 key "name"; 1163 min-elements "1"; 1164 description 1165 "Each list entry is a container for state data of a routing 1166 instance. 1168 An implementation MAY create one or more system-controlled 1169 instances, other user-controlled instances MAY be created by 1170 configuration."; 1171 leaf name { 1172 type string; 1173 description 1174 "The name of the routing instance. 1176 For system-controlled instances the name is persistent, 1177 i.e., it SHOULD NOT change across reboots."; 1178 } 1179 leaf type { 1180 type identityref { 1181 base routing-instance; 1182 } 1183 description 1184 "The routing instance type."; 1185 } 1186 container default-ribs { 1187 description 1188 "Default RIBs used by the routing instance."; 1189 list default-rib { 1190 key "address-family"; 1191 description 1192 "Each list entry specifies the default RIB for one 1193 address family. 1195 The default RIB is operationally connected to all 1196 routing protocols for which a connected RIB has not been 1197 explicitly configured. 1199 The 'direct' pseudo-protocol is always connected to the 1200 default RIBs."; 1201 uses address-family; 1202 leaf rib-name { 1203 type rib-state-ref; 1204 mandatory "true"; 1205 description 1206 "Name of an existing RIB to be used as the default RIB 1207 for the given routing instance and address family."; 1208 } 1209 } 1210 } 1211 container interfaces { 1212 description 1213 "Network layer interfaces belonging to the routing 1214 instance."; 1215 list interface { 1216 key "name"; 1217 description 1218 "List of network layer interfaces assigned to the routing 1219 instance."; 1220 leaf name { 1221 type if:interface-state-ref; 1222 description 1223 "A reference to the name of a configured network layer 1224 interface."; 1225 } 1226 } 1227 } 1228 container routing-protocols { 1229 description 1230 "Container for the list of routing protocol instances."; 1231 list routing-protocol { 1232 key "type name"; 1233 description 1234 "State data of a routing protocol instance. 1236 An implementation MUST provide exactly one 1237 system-controlled instance of the type 'direct'. Other 1238 instances MAY be created by configuration."; 1239 leaf type { 1240 type identityref { 1241 base routing-protocol; 1242 } 1243 description 1244 "Type of the routing protocol."; 1245 } 1246 leaf name { 1247 type string; 1248 description 1249 "The name of the routing protocol instance. 1251 For system-controlled instances this name is 1252 persistent, i.e., it SHOULD NOT change across 1253 reboots."; 1254 } 1255 leaf route-preference { 1256 type route-preference; 1257 mandatory "true"; 1258 description 1259 "The value of route preference (administrative 1260 distance) assigned to all routes generated by the 1261 routing protocol instance. A lower value means a more 1262 preferred route."; 1263 } 1264 container connected-ribs { 1265 description 1266 "Container for connected RIBs."; 1267 list connected-rib { 1268 key "rib-name"; 1269 description 1270 "List of RIBs to which the routing protocol instance 1271 is connected. 1273 By default, routes learned by the routing protocol 1274 instance are installed in all connected RIBs of the 1275 matching address family, and, conversely, all routes 1276 from connected RIBs are installed in the routing 1277 protocol instance. However, routing protocols may 1278 specify other rules."; 1279 leaf rib-name { 1280 type rib-state-ref; 1281 description 1282 "Name of an existing RIB."; 1283 } 1284 } 1285 } 1286 } 1287 } 1288 } 1289 container ribs { 1290 description 1291 "Container for RIBs."; 1292 list rib { 1293 key "name"; 1294 description 1295 "Each entry represents a RIB identified by the 'name' key. 1296 All routes in a RIB MUST belong to the same address 1297 family. 1299 The server MUST provide a system-controlled default RIB 1300 for each supported address family, and MAY provide other 1301 system-controlled RIBs. Additional RIBs MAY be created in 1302 the configuration."; 1303 leaf name { 1304 type string; 1305 description 1306 "The name of the RIB."; 1307 } 1308 uses address-family; 1309 container routes { 1310 description 1311 "Current content of the RIB."; 1313 list route { 1314 description 1315 "A RIB route entry. This data node MUST be augmented 1316 with information specific for routes of each address 1317 family."; 1318 leaf route-preference { 1319 type route-preference; 1320 description 1321 "This route attribute, also known as administrative 1322 distance, allows for selecting the preferred route 1323 among routes with the same destination prefix. A 1324 smaller value means a more preferred route."; 1325 } 1326 container next-hop { 1327 description 1328 "Route's next-hop attribute."; 1329 uses next-hop-state-content; 1330 } 1331 uses route-metadata; 1332 } 1333 } 1334 container recipient-ribs { 1335 description 1336 "Container for recipient RIBs."; 1337 list recipient-rib { 1338 key "rib-name"; 1339 description 1340 "List of RIBs that receive routes from this RIB."; 1341 leaf rib-name { 1342 type rib-state-ref; 1343 description 1344 "The name of the recipient RIB."; 1345 } 1346 } 1347 } 1348 } 1349 } 1350 } 1352 /* Configuration Data */ 1354 container routing { 1355 description 1356 "Configuration parameters for the routing subsystem."; 1357 list routing-instance { 1358 key "name"; 1359 description 1360 "Configuration of a routing instance."; 1362 leaf name { 1363 type string; 1364 description 1365 "The name of the routing instance. 1367 For system-controlled entries, the value of this leaf must 1368 be the same as the name of the corresponding entry in 1369 state data. 1371 For user-controlled entries, an arbitrary name can be 1372 used."; 1373 } 1374 leaf type { 1375 type identityref { 1376 base routing-instance; 1377 } 1378 default "rt:default-routing-instance"; 1379 description 1380 "The type of the routing instance."; 1381 } 1382 leaf enabled { 1383 type boolean; 1384 default "true"; 1385 description 1386 "Enable/disable the routing instance. 1388 If this parameter is false, the parent routing instance is 1389 disabled and does not appear in state data, despite any 1390 other configuration that might be present."; 1391 } 1392 uses router-id { 1393 if-feature router-id; 1394 description 1395 "Configuration of the global router ID. Routing protocols 1396 that use router ID can use this parameter or override it 1397 with another value."; 1398 } 1399 leaf description { 1400 type string; 1401 description 1402 "Textual description of the routing instance."; 1403 } 1404 container default-ribs { 1405 if-feature multiple-ribs; 1406 description 1407 "Configuration of the default RIBs used by the routing 1408 instance. 1410 The default RIB for an addressed family if by default 1411 connected to all routing protocol instances supporting 1412 that address family, and always receives direct routes."; 1413 list default-rib { 1414 must "address-family=/routing/ribs/rib[name=current()/" 1415 + "rib-name]/address-family" { 1416 error-message "Address family mismatch."; 1417 description 1418 "The entry's address family MUST match that of the 1419 referenced RIB."; 1420 } 1421 key "address-family"; 1422 description 1423 "Each list entry configures the default RIB for one 1424 address family."; 1425 uses address-family; 1426 leaf rib-name { 1427 type string; 1428 mandatory "true"; 1429 description 1430 "Name of an existing RIB to be used as the default RIB 1431 for the given routing instance and address family."; 1432 } 1433 } 1434 } 1435 container interfaces { 1436 description 1437 "Configuration of the routing instance's interfaces."; 1438 list interface { 1439 key "name"; 1440 description 1441 "List of network layer interfaces assigned to the routing 1442 instance."; 1443 leaf name { 1444 type if:interface-ref; 1445 description 1446 "A reference to the name of a configured network layer 1447 interface."; 1448 } 1449 } 1450 } 1451 container routing-protocols { 1452 description 1453 "Configuration of routing protocol instances."; 1454 list routing-protocol { 1455 key "type name"; 1456 description 1457 "Each entry contains configuration of a routing protocol 1458 instance."; 1459 leaf type { 1460 type identityref { 1461 base routing-protocol; 1462 } 1463 description 1464 "Type of the routing protocol - an identity derived 1465 from the 'routing-protocol' base identity."; 1466 } 1467 leaf name { 1468 type string; 1469 description 1470 "An arbitrary name of the routing protocol instance."; 1471 } 1472 leaf description { 1473 type string; 1474 description 1475 "Textual description of the routing protocol 1476 instance."; 1477 } 1478 leaf enabled { 1479 type boolean; 1480 default "true"; 1481 description 1482 "Enable/disable the routing protocol instance. 1484 If this parameter is false, the parent routing 1485 protocol instance is disabled and does not appear in 1486 state data, despite any other configuration that might 1487 be present."; 1488 } 1489 leaf route-preference { 1490 type route-preference; 1491 description 1492 "The value of route preference (administrative 1493 distance). 1495 The default value depends on the routing protocol 1496 type, and may also be implementation-dependent."; 1497 } 1498 container connected-ribs { 1499 description 1500 "Configuration of connected RIBs."; 1501 list connected-rib { 1502 key "rib-name"; 1503 description 1504 "Each entry configures a RIB to which the routing 1505 protocol instance is connected. 1507 If no connected RIB is configured for an address 1508 family, the routing protocol is connected to the 1509 default RIB for that address family."; 1510 leaf rib-name { 1511 type rib-ref; 1512 must "../../../type != 'rt:direct' or " 1513 + "../../../../../default-ribs/ " 1514 + "default-rib/rib-name=." { 1515 error-message "The 'direct' protocol can be " 1516 + "connected only to a default RIB."; 1517 description 1518 "For the 'direct' pseudo-protocol, the connected 1519 RIB must always be a default RIB."; 1520 } 1521 description 1522 "Name of an existing RIB."; 1523 } 1524 } 1525 } 1526 container static-routes { 1527 when "../type='rt:static'" { 1528 description 1529 "This container is only valid for the 'static' 1530 routing protocol."; 1531 } 1532 description 1533 "Configuration of the 'static' pseudo-protocol. 1535 Address-family-specific modules augment this node with 1536 their lists of routes."; 1537 } 1538 } 1539 } 1540 } 1541 container ribs { 1542 description 1543 "Configuration of RIBs."; 1544 list rib { 1545 key "name"; 1546 description 1547 "Each entry represents a configured RIB identified by the 1548 'name' key. 1550 Entries having the same key as a system-controlled entry 1551 of the list /routing-state/ribs/rib are used for 1552 configuring parameters of that entry. Other entries define 1553 additional user-controlled RIBs."; 1554 leaf name { 1555 type string; 1556 description 1557 "The name of the RIB. 1559 For system-controlled entries, the value of this leaf 1560 must be the same as the name of the corresponding entry 1561 in state data. 1563 For user-controlled entries, an arbitrary name can be 1564 used."; 1565 } 1566 uses address-family; 1567 leaf description { 1568 type string; 1569 description 1570 "Textual description of the RIB."; 1571 } 1572 container recipient-ribs { 1573 if-feature multiple-ribs; 1574 description 1575 "Configuration of recipient RIBs."; 1576 list recipient-rib { 1577 must "rib-name != ../../name" { 1578 error-message 1579 "Source and recipient RIBs are identical."; 1580 description 1581 "A RIB MUST NOT appear among its recipient RIBs."; 1582 } 1583 must "/routing/ribs/rib[name=current()/rib-name]/" 1584 + "address-family=../../address-family" { 1585 error-message "Address family mismatch."; 1586 description 1587 "Address family of the recipient RIB MUST match that 1588 of the source RIB."; 1589 } 1590 key "rib-name"; 1591 description 1592 "Each entry configures a recipient RIB."; 1593 leaf rib-name { 1594 type rib-ref; 1595 description 1596 "The name of the recipient RIB."; 1597 } 1598 } 1599 } 1600 } 1601 } 1602 } 1603 /* RPC operations */ 1605 rpc fib-route { 1606 description 1607 "Return the active FIB route that a routing-instance uses for 1608 sending packets to a destination address."; 1609 input { 1610 leaf routing-instance-name { 1611 type routing-instance-state-ref; 1612 mandatory "true"; 1613 description 1614 "Name of the routing instance whose forwarding information 1615 base is being queried. 1617 If the routing instance with name equal to the value of 1618 this parameter doesn't exist, then this operation SHALL 1619 fail with error-tag 'data-missing' and error-app-tag 1620 'routing-instance-not-found'."; 1621 } 1622 container destination-address { 1623 description 1624 "Network layer destination address. 1626 Address family specific modules MUST augment this 1627 container with a leaf named 'address'."; 1628 uses address-family; 1629 } 1630 } 1631 output { 1632 container route { 1633 description 1634 "The active FIB route for the specified destination. 1636 If the routing instance has no active FIB route for the 1637 destination address, no output is returned - the server 1638 SHALL send an containing a single element 1639 . 1641 Address family specific modules MUST augment this list 1642 with appropriate route contents."; 1643 uses address-family; 1644 container next-hop { 1645 description 1646 "Route's next-hop attribute."; 1647 uses next-hop-state-content; 1648 } 1649 uses route-metadata; 1650 } 1652 } 1653 } 1655 rpc route-count { 1656 description 1657 "Return the current number of routes in a RIB."; 1658 input { 1659 leaf rib-name { 1660 type rib-state-ref; 1661 mandatory "true"; 1662 description 1663 "Name of the RIB. 1665 If the RIB with name equal to the value of this parameter 1666 doesn't exist, then this operation SHALL fail with 1667 error-tag 'data-missing' and error-app-tag 1668 'rib-not-found'."; 1669 } 1670 } 1671 output { 1672 leaf number-of-routes { 1673 type uint64; 1674 mandatory "true"; 1675 description 1676 "Number of routes in the RIB."; 1677 } 1678 } 1679 } 1680 } 1682 1684 8. IPv4 Unicast Routing Management YANG Module 1686 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1687 the actual RFC number and all occurrences of the revision date below 1688 with the date of RFC publication (and remove this note). 1690 file "ietf-ipv4-unicast-routing@2015-02-10.yang" 1692 module ietf-ipv4-unicast-routing { 1694 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1696 prefix "v4ur"; 1698 import ietf-routing { 1699 prefix "rt"; 1701 } 1703 import ietf-inet-types { 1704 prefix "inet"; 1705 } 1707 organization 1708 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1710 contact 1711 "WG Web: 1712 WG List: 1714 WG Chair: Thomas Nadeau 1715 1717 WG Chair: Juergen Schoenwaelder 1718 1720 Editor: Ladislav Lhotka 1721 "; 1723 description 1724 "This YANG module augments the 'ietf-routing' module with basic 1725 configuration and state data for IPv4 unicast routing. 1727 Copyright (c) 2014 IETF Trust and the persons identified as 1728 authors of the code. All rights reserved. 1730 Redistribution and use in source and binary forms, with or 1731 without modification, is permitted pursuant to, and subject to 1732 the license terms contained in, the Simplified BSD License set 1733 forth in Section 4.c of the IETF Trust's Legal Provisions 1734 Relating to IETF Documents 1735 (http://trustee.ietf.org/license-info). 1737 This version of this YANG module is part of RFC XXXX; see the 1738 RFC itself for full legal notices."; 1740 revision 2015-02-10 { 1741 description 1742 "Initial revision."; 1743 reference 1744 "RFC XXXX: A YANG Data Model for Routing Management"; 1745 } 1747 /* Identities */ 1748 identity ipv4-unicast { 1749 base rt:ipv4; 1750 description 1751 "This identity represents the IPv4 unicast address family."; 1752 } 1754 /* State data */ 1756 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1757 when "../../rt:address-family = 'v4ur:ipv4-unicast'" { 1758 description 1759 "This augment is valid only for IPv4 unicast."; 1760 } 1761 description 1762 "This leaf augments an IPv4 unicast route."; 1763 leaf destination-prefix { 1764 type inet:ipv4-prefix; 1765 description 1766 "IPv4 destination prefix."; 1767 } 1768 } 1770 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1771 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1772 when "../../../rt:address-family = 'v4ur:ipv4-unicast'" { 1773 description 1774 "This augment is valid only for IPv4 unicast."; 1775 } 1776 description 1777 "This leaf augments the 'simple-next-hop' case of IPv4 unicast 1778 routes."; 1779 leaf next-hop-address { 1780 type inet:ipv4-address; 1781 description 1782 "IPv4 address of the next-hop."; 1783 } 1784 } 1786 /* Configuration data */ 1788 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 1789 + "rt:routing-protocol/rt:static-routes" { 1790 description 1791 "This augment defines the configuration of the 'static' 1792 pseudo-protocol with data specific to IPv4 unicast."; 1793 container ipv4 { 1794 description 1795 "Configuration of a 'static' pseudo-protocol instance 1796 consists of a list of routes."; 1797 list route { 1798 key "destination-prefix"; 1799 ordered-by "user"; 1800 description 1801 "A user-ordered list of static routes."; 1802 leaf destination-prefix { 1803 type inet:ipv4-prefix; 1804 mandatory "true"; 1805 description 1806 "IPv4 destination prefix."; 1807 } 1808 leaf description { 1809 type string; 1810 description 1811 "Textual description of the route."; 1812 } 1813 container next-hop { 1814 description 1815 "Configuration of next-hop."; 1816 uses rt:next-hop-content { 1817 augment "next-hop-options" { 1818 description 1819 "Add next-hop address case."; 1820 leaf next-hop-address { 1821 type inet:ipv4-address; 1822 description 1823 "IPv4 address of the next-hop."; 1824 } 1825 } 1826 } 1827 } 1828 } 1829 } 1830 } 1832 /* RPC operations */ 1834 augment "/rt:fib-route/rt:input/rt:destination-address" { 1835 when "rt:address-family='v4ur:ipv4-unicast'" { 1836 description 1837 "This augment is valid only for IPv4 unicast."; 1838 } 1839 description 1840 "This leaf augments the 'rt:destination-address' parameter of 1841 the 'rt:fib-route' operation."; 1842 leaf address { 1843 type inet:ipv4-address; 1844 description 1845 "IPv4 destination address."; 1846 } 1847 } 1849 augment "/rt:fib-route/rt:output/rt:route" { 1850 when "rt:address-family='v4ur:ipv4-unicast'" { 1851 description 1852 "This augment is valid only for IPv4 unicast."; 1853 } 1854 description 1855 "This leaf augments the reply to the 'rt:fib-route' 1856 operation."; 1857 leaf destination-prefix { 1858 type inet:ipv4-prefix; 1859 description 1860 "IPv4 destination prefix."; 1861 } 1862 } 1864 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 1865 + "rt:next-hop-options/rt:simple-next-hop" { 1866 when "../rt:address-family='v4ur:ipv4-unicast'" { 1867 description 1868 "This augment is valid only for IPv4 unicast."; 1869 } 1870 description 1871 "This leaf augments the 'simple-next-hop' case in the reply to 1872 the 'rt:fib-route' operation."; 1873 leaf next-hop-address { 1874 type inet:ipv4-address; 1875 description 1876 "IPv4 address of the next-hop."; 1877 } 1878 } 1879 } 1881 1883 9. IPv6 Unicast Routing Management YANG Module 1885 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1886 the actual RFC number and all occurrences of the revision date below 1887 with the date of RFC publication (and remove this note). 1889 file "ietf-ipv6-unicast-routing@2015-02-10.yang" 1891 module ietf-ipv6-unicast-routing { 1892 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1894 prefix "v6ur"; 1896 import ietf-routing { 1897 prefix "rt"; 1898 } 1900 import ietf-inet-types { 1901 prefix "inet"; 1902 } 1904 import ietf-interfaces { 1905 prefix "if"; 1906 } 1908 import ietf-ip { 1909 prefix "ip"; 1910 } 1912 organization 1913 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1915 contact 1916 "WG Web: 1917 WG List: 1919 WG Chair: Thomas Nadeau 1920 1922 WG Chair: Juergen Schoenwaelder 1923 1925 Editor: Ladislav Lhotka 1926 "; 1928 description 1929 "This YANG module augments the 'ietf-routing' module with basic 1930 configuration and state data for IPv6 unicast routing. 1932 Copyright (c) 2014 IETF Trust and the persons identified as 1933 authors of the code. All rights reserved. 1935 Redistribution and use in source and binary forms, with or 1936 without modification, is permitted pursuant to, and subject to 1937 the license terms contained in, the Simplified BSD License set 1938 forth in Section 4.c of the IETF Trust's Legal Provisions 1939 Relating to IETF Documents 1940 (http://trustee.ietf.org/license-info). 1942 This version of this YANG module is part of RFC XXXX; see the 1943 RFC itself for full legal notices."; 1945 revision 2015-02-10 { 1946 description 1947 "Initial revision."; 1948 reference 1949 "RFC XXXX: A YANG Data Model for Routing Management"; 1950 } 1952 /* Identities */ 1954 identity ipv6-unicast { 1955 base rt:ipv6; 1956 description 1957 "This identity represents the IPv6 unicast address family."; 1958 } 1960 /* State data */ 1962 augment "/rt:routing-state/rt:routing-instance/rt:interfaces/" 1963 + "rt:interface" { 1964 description 1965 "IPv6-specific parameters of router interfaces."; 1966 container ipv6-router-advertisements { 1967 description 1968 "Parameters of IPv6 Router Advertisements."; 1969 leaf send-advertisements { 1970 type boolean; 1971 description 1972 "A flag indicating whether or not the router sends periodic 1973 Router Advertisements and responds to Router 1974 Solicitations."; 1975 } 1976 leaf max-rtr-adv-interval { 1977 type uint16 { 1978 range "4..1800"; 1979 } 1980 units "seconds"; 1981 description 1982 "The maximum time allowed between sending unsolicited 1983 multicast Router Advertisements from the interface."; 1984 } 1985 leaf min-rtr-adv-interval { 1986 type uint16 { 1987 range "3..1350"; 1989 } 1990 units "seconds"; 1991 description 1992 "The minimum time allowed between sending unsolicited 1993 multicast Router Advertisements from the interface."; 1994 } 1995 leaf managed-flag { 1996 type boolean; 1997 description 1998 "The value that is placed in the 'Managed address 1999 configuration' flag field in the Router Advertisement."; 2000 } 2001 leaf other-config-flag { 2002 type boolean; 2003 description 2004 "The value that is placed in the 'Other configuration' flag 2005 field in the Router Advertisement."; 2006 } 2007 leaf link-mtu { 2008 type uint32; 2009 description 2010 "The value that is placed in MTU options sent by the 2011 router. A value of zero indicates that no MTU options are 2012 sent."; 2013 } 2014 leaf reachable-time { 2015 type uint32 { 2016 range "0..3600000"; 2017 } 2018 units "milliseconds"; 2019 description 2020 "The value that is placed in the Reachable Time field in 2021 the Router Advertisement messages sent by the router. A 2022 value of zero means unspecified (by this router)."; 2023 } 2024 leaf retrans-timer { 2025 type uint32; 2026 units "milliseconds"; 2027 description 2028 "The value that is placed in the Retrans Timer field in the 2029 Router Advertisement messages sent by the router. A value 2030 of zero means unspecified (by this router)."; 2031 } 2032 leaf cur-hop-limit { 2033 type uint8; 2034 description 2035 "The value that is placed in the Cur Hop Limit field in the 2036 Router Advertisement messages sent by the router. A value 2037 of zero means unspecified (by this router)."; 2038 } 2039 leaf default-lifetime { 2040 type uint16 { 2041 range "0..9000"; 2042 } 2043 units "seconds"; 2044 description 2045 "The value that is placed in the Router Lifetime field of 2046 Router Advertisements sent from the interface, in seconds. 2047 A value of zero indicates that the router is not to be 2048 used as a default router."; 2049 } 2050 container prefix-list { 2051 description 2052 "A list of prefixes that are placed in Prefix Information 2053 options in Router Advertisement messages sent from the 2054 interface. 2056 By default, these are all prefixes that the router 2057 advertises via routing protocols as being on-link for the 2058 interface from which the advertisement is sent."; 2059 list prefix { 2060 key "prefix-spec"; 2061 description 2062 "Advertised prefix entry and its parameters."; 2063 leaf prefix-spec { 2064 type inet:ipv6-prefix; 2065 description 2066 "IPv6 address prefix."; 2067 } 2068 leaf valid-lifetime { 2069 type uint32; 2070 units "seconds"; 2071 description 2072 "The value that is placed in the Valid Lifetime in the 2073 Prefix Information option. The designated value of all 2074 1's (0xffffffff) represents infinity."; 2075 } 2076 leaf on-link-flag { 2077 type boolean; 2078 description 2079 "The value that is placed in the on-link flag ('L-bit') 2080 field in the Prefix Information option."; 2081 } 2082 leaf preferred-lifetime { 2083 type uint32; 2084 units "seconds"; 2085 description 2086 "The value that is placed in the Preferred Lifetime in 2087 the Prefix Information option, in seconds. The 2088 designated value of all 1's (0xffffffff) represents 2089 infinity."; 2090 } 2091 leaf autonomous-flag { 2092 type boolean; 2093 description 2094 "The value that is placed in the Autonomous Flag field 2095 in the Prefix Information option."; 2096 } 2097 } 2098 } 2099 } 2100 } 2102 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2103 when "../../rt:address-family = 'v6ur:ipv6-unicast'" { 2104 description 2105 "This augment is valid only for IPv6 unicast."; 2106 } 2107 description 2108 "This leaf augments an IPv6 unicast route."; 2109 leaf destination-prefix { 2110 type inet:ipv6-prefix; 2111 description 2112 "IPv6 destination prefix."; 2113 } 2114 } 2116 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 2117 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 2118 when "../../../rt:address-family = 'v6ur:ipv6-unicast'" { 2119 description 2120 "This augment is valid only for IPv6 unicast."; 2121 } 2122 description 2123 "This leaf augments the 'simple-next-hop' case of IPv6 unicast 2124 routes."; 2125 leaf next-hop-address { 2126 type inet:ipv6-address; 2127 description 2128 "IPv6 address of the next-hop."; 2129 } 2130 } 2132 /* Configuration data */ 2133 augment 2134 "/rt:routing/rt:routing-instance/rt:interfaces/rt:interface" { 2135 when "/if:interfaces/if:interface[if:name=current()/rt:name]/" 2136 + "ip:ipv6/ip:enabled='true'" { 2137 description 2138 "This augment is only valid for router interfaces with 2139 enabled IPv6."; 2140 } 2141 description 2142 "Configuration of IPv6-specific parameters of router 2143 interfaces."; 2144 container ipv6-router-advertisements { 2145 description 2146 "Configuration of IPv6 Router Advertisements."; 2147 leaf send-advertisements { 2148 type boolean; 2149 default "false"; 2150 description 2151 "A flag indicating whether or not the router sends periodic 2152 Router Advertisements and responds to Router 2153 Solicitations."; 2154 reference 2155 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2156 AdvSendAdvertisements."; 2157 } 2158 leaf max-rtr-adv-interval { 2159 type uint16 { 2160 range "4..1800"; 2161 } 2162 units "seconds"; 2163 default "600"; 2164 description 2165 "The maximum time allowed between sending unsolicited 2166 multicast Router Advertisements from the interface."; 2167 reference 2168 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2169 MaxRtrAdvInterval."; 2170 } 2171 leaf min-rtr-adv-interval { 2172 type uint16 { 2173 range "3..1350"; 2174 } 2175 units "seconds"; 2176 must ". <= 0.75 * ../max-rtr-adv-interval" { 2177 description 2178 "The value MUST NOT be greater than 75 % of 2179 'max-rtr-adv-interval'."; 2180 } 2181 description 2182 "The minimum time allowed between sending unsolicited 2183 multicast Router Advertisements from the interface. 2185 The default value to be used operationally if this leaf is 2186 not configured is determined as follows: 2188 - if max-rtr-adv-interval >= 9 seconds, the default value 2189 is 0.33 * max-rtr-adv-interval; 2191 - otherwise it is 0.75 * max-rtr-adv-interval."; 2192 reference 2193 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2194 MinRtrAdvInterval."; 2195 } 2196 leaf managed-flag { 2197 type boolean; 2198 default "false"; 2199 description 2200 "The value to be placed in the 'Managed address 2201 configuration' flag field in the Router Advertisement."; 2202 reference 2203 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2204 AdvManagedFlag."; 2205 } 2206 leaf other-config-flag { 2207 type boolean; 2208 default "false"; 2209 description 2210 "The value to be placed in the 'Other configuration' flag 2211 field in the Router Advertisement."; 2212 reference 2213 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2214 AdvOtherConfigFlag."; 2215 } 2216 leaf link-mtu { 2217 type uint32; 2218 default "0"; 2219 description 2220 "The value to be placed in MTU options sent by the router. 2221 A value of zero indicates that no MTU options are sent."; 2222 reference 2223 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2224 AdvLinkMTU."; 2225 } 2226 leaf reachable-time { 2227 type uint32 { 2228 range "0..3600000"; 2230 } 2231 units "milliseconds"; 2232 default "0"; 2233 description 2234 "The value to be placed in the Reachable Time field in the 2235 Router Advertisement messages sent by the router. A value 2236 of zero means unspecified (by this router)."; 2237 reference 2238 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2239 AdvReachableTime."; 2240 } 2241 leaf retrans-timer { 2242 type uint32; 2243 units "milliseconds"; 2244 default "0"; 2245 description 2246 "The value to be placed in the Retrans Timer field in the 2247 Router Advertisement messages sent by the router. A value 2248 of zero means unspecified (by this router)."; 2249 reference 2250 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2251 AdvRetransTimer."; 2252 } 2253 leaf cur-hop-limit { 2254 type uint8; 2255 description 2256 "The value to be placed in the Cur Hop Limit field in the 2257 Router Advertisement messages sent by the router. A value 2258 of zero means unspecified (by this router). 2260 If this parameter is not configured, the device SHOULD use 2261 the value specified in IANA Assigned Numbers that was in 2262 effect at the time of implementation."; 2263 reference 2264 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2265 AdvCurHopLimit. 2267 IANA: IP Parameters, 2268 http://www.iana.org/assignments/ip-parameters"; 2269 } 2270 leaf default-lifetime { 2271 type uint16 { 2272 range "0..9000"; 2273 } 2274 units "seconds"; 2275 description 2276 "The value to be placed in the Router Lifetime field of 2277 Router Advertisements sent from the interface, in seconds. 2279 It MUST be either zero or between max-rtr-adv-interval and 2280 9000 seconds. A value of zero indicates that the router is 2281 not to be used as a default router. These limits may be 2282 overridden by specific documents that describe how IPv6 2283 operates over different link layers. 2285 If this parameter is not configured, the device SHOULD use 2286 a value of 3 * max-rtr-adv-interval."; 2287 reference 2288 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2289 AdvDefaultLifeTime."; 2290 } 2291 container prefix-list { 2292 description 2293 "Configuration of prefixes to be placed in Prefix 2294 Information options in Router Advertisement messages sent 2295 from the interface. 2297 Prefixes that are advertised by default but do not have 2298 their entries in the child 'prefix' list are advertised 2299 with the default values of all parameters. 2301 The link-local prefix SHOULD NOT be included in the list 2302 of advertised prefixes."; 2303 reference 2304 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2305 AdvPrefixList."; 2306 list prefix { 2307 key "prefix-spec"; 2308 description 2309 "Configuration of an advertised prefix entry."; 2310 leaf prefix-spec { 2311 type inet:ipv6-prefix; 2312 description 2313 "IPv6 address prefix."; 2314 } 2315 choice control-adv-prefixes { 2316 default "advertise"; 2317 description 2318 "The prefix either may be explicitly removed from the 2319 set of advertised prefixes, or parameters with which 2320 it is advertised may be specified (default case)."; 2321 leaf no-advertise { 2322 type empty; 2323 description 2324 "The prefix will not be advertised. 2326 This can be used for removing the prefix from the 2327 default set of advertised prefixes."; 2328 } 2329 case advertise { 2330 leaf valid-lifetime { 2331 type uint32; 2332 units "seconds"; 2333 default "2592000"; 2334 description 2335 "The value to be placed in the Valid Lifetime in 2336 the Prefix Information option. The designated 2337 value of all 1's (0xffffffff) represents 2338 infinity."; 2339 reference 2340 "RFC 4861: Neighbor Discovery for IP version 6 2341 (IPv6) - AdvValidLifetime."; 2342 } 2343 leaf on-link-flag { 2344 type boolean; 2345 default "true"; 2346 description 2347 "The value to be placed in the on-link flag 2348 ('L-bit') field in the Prefix Information 2349 option."; 2350 reference 2351 "RFC 4861: Neighbor Discovery for IP version 6 2352 (IPv6) - AdvOnLinkFlag."; 2353 } 2354 leaf preferred-lifetime { 2355 type uint32; 2356 units "seconds"; 2357 must ". <= ../valid-lifetime" { 2358 description 2359 "This value MUST NOT be greater than 2360 valid-lifetime."; 2361 } 2362 default "604800"; 2363 description 2364 "The value to be placed in the Preferred Lifetime 2365 in the Prefix Information option. The designated 2366 value of all 1's (0xffffffff) represents 2367 infinity."; 2368 reference 2369 "RFC 4861: Neighbor Discovery for IP version 6 2370 (IPv6) - AdvPreferredLifetime."; 2371 } 2372 leaf autonomous-flag { 2373 type boolean; 2374 default "true"; 2375 description 2376 "The value to be placed in the Autonomous Flag 2377 field in the Prefix Information option."; 2378 reference 2379 "RFC 4861: Neighbor Discovery for IP version 6 2380 (IPv6) - AdvAutonomousFlag."; 2381 } 2382 } 2383 } 2384 } 2385 } 2386 } 2387 } 2389 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2390 + "rt:routing-protocol/rt:static-routes" { 2391 description 2392 "This augment defines the configuration of the 'static' 2393 pseudo-protocol with data specific to IPv6 unicast."; 2394 container ipv6 { 2395 description 2396 "Configuration of a 'static' pseudo-protocol instance 2397 consists of a list of routes."; 2398 list route { 2399 key "destination-prefix"; 2400 ordered-by "user"; 2401 description 2402 "A user-ordered list of static routes."; 2403 leaf destination-prefix { 2404 type inet:ipv6-prefix; 2405 mandatory "true"; 2406 description 2407 "IPv6 destination prefix."; 2408 } 2409 leaf description { 2410 type string; 2411 description 2412 "Textual description of the route."; 2413 } 2414 container next-hop { 2415 description 2416 "Configuration of next-hop."; 2417 uses rt:next-hop-content { 2418 augment "next-hop-options" { 2419 description 2420 "Add next-hop address case."; 2421 leaf next-hop-address { 2422 type inet:ipv6-address; 2423 description 2424 "IPv6 address of the next-hop."; 2425 } 2426 } 2427 } 2428 } 2429 } 2430 } 2431 } 2433 /* RPC operations */ 2435 augment "/rt:fib-route/rt:input/rt:destination-address" { 2436 when "rt:address-family='v6ur:ipv6-unicast'" { 2437 description 2438 "This augment is valid only for IPv6 unicast."; 2439 } 2440 description 2441 "This leaf augments the 'rt:destination-address' parameter of 2442 the 'rt:fib-route' operation."; 2443 leaf address { 2444 type inet:ipv6-address; 2445 description 2446 "IPv6 destination address."; 2447 } 2448 } 2450 augment "/rt:fib-route/rt:output/rt:route" { 2451 when "rt:address-family='v6ur:ipv6-unicast'" { 2452 description 2453 "This augment is valid only for IPv6 unicast."; 2454 } 2455 description 2456 "This leaf augments the reply to the 'rt:fib-route' 2457 operation."; 2458 leaf destination-prefix { 2459 type inet:ipv6-prefix; 2460 description 2461 "IPv6 destination prefix."; 2462 } 2463 } 2465 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 2466 + "rt:next-hop-options/rt:simple-next-hop" { 2467 when "../rt:address-family='v6ur:ipv6-unicast'" { 2468 description 2469 "This augment is valid only for IPv6 unicast."; 2470 } 2471 description 2472 "This leaf augments the 'simple-next-hop' case in the reply to 2473 the 'rt:fib-route' operation."; 2474 leaf next-hop-address { 2475 type inet:ipv6-address; 2476 description 2477 "IPv6 address of the next-hop."; 2478 } 2479 } 2480 } 2482 2484 10. IANA Considerations 2486 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2487 actual RFC number (and remove this note). 2489 This document registers the following namespace URIs in the IETF XML 2490 registry [RFC3688]: 2492 ---------------------------------------------------------- 2493 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2495 Registrant Contact: The IESG. 2497 XML: N/A, the requested URI is an XML namespace. 2498 ---------------------------------------------------------- 2500 ---------------------------------------------------------- 2501 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2503 Registrant Contact: The IESG. 2505 XML: N/A, the requested URI is an XML namespace. 2506 ---------------------------------------------------------- 2508 ---------------------------------------------------------- 2509 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2511 Registrant Contact: The IESG. 2513 XML: N/A, the requested URI is an XML namespace. 2514 ---------------------------------------------------------- 2516 This document registers the following YANG modules in the YANG Module 2517 Names registry [RFC6020]: 2519 ------------------------------------------------------------------- 2520 name: ietf-routing 2521 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2522 prefix: rt 2523 reference: RFC XXXX 2524 ------------------------------------------------------------------- 2526 ------------------------------------------------------------------- 2527 name: ietf-ipv4-unicast-routing 2528 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2529 prefix: v4ur 2530 reference: RFC XXXX 2531 ------------------------------------------------------------------- 2533 ------------------------------------------------------------------- 2534 name: ietf-ipv6-unicast-routing 2535 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2536 prefix: v6ur 2537 reference: RFC XXXX 2538 ------------------------------------------------------------------- 2540 11. Security Considerations 2542 Configuration and state data conforming to the core routing data 2543 model (defined in this document) are designed to be accessed via the 2544 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2545 transport layer and the mandatory-to-implement secure transport is 2546 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 2547 the means to restrict access for particular NETCONF users to a pre- 2548 configured subset of all available NETCONF protocol operations and 2549 content. 2551 A number of data nodes defined in the YANG modules belonging to the 2552 configuration part of the core routing data model are 2553 writable/creatable/deletable (i.e., "config true" in YANG terms, 2554 which is the default). These data nodes may be considered sensitive 2555 or vulnerable in some network environments. Write operations to 2556 these data nodes, such as "edit-config", can have negative effects on 2557 the network if the protocol operations are not properly protected. 2559 The vulnerable "config true" subtrees and data nodes are the 2560 following: 2562 /routing/routing-instance/interfaces/interface: This list assigns a 2563 network layer interface to a routing instance and may also specify 2564 interface parameters related to routing. 2566 /routing/routing-instance/routing-protocols/routing-protocol: This 2567 list specifies the routing protocols configured on a device. 2569 /routing/ribs/rib: This list specifies the RIBs configured for the 2570 device. 2572 Unauthorized access to any of these lists can adversely affect the 2573 routing subsystem of both the local device and the network. This may 2574 lead to network malfunctions, delivery of packets to inappropriate 2575 destinations and other problems. 2577 12. Acknowledgments 2579 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 2580 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 2581 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 2582 Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, 2583 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- 2584 Kit Yeung and Jeffrey Zhang for their helpful comments and 2585 suggestions. 2587 13. References 2589 13.1. Normative References 2591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2592 Requirement Levels", BCP 14, RFC 2119, March 1997. 2594 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2595 January 2004. 2597 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2598 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2599 September 2007. 2601 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2602 Network Configuration Protocol (NETCONF)", RFC 6020, 2603 October 2010. 2605 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2606 Bierman, "Network Configuration Protocol (NETCONF)", RFC 2607 6241, June 2011. 2609 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 2610 July 2013. 2612 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2613 Management", RFC 7223, May 2014. 2615 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 2616 7277, June 2014. 2618 13.2. Informative References 2620 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2621 Networks (VPNs)", RFC 4364, February 2006. 2623 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2624 Data Model Documents", RFC 6087, January 2011. 2626 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2627 Shell (SSH)", RFC 6242, June 2011. 2629 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2630 Protocol (NETCONF) Access Control Model", RFC 6536, March 2631 2012. 2633 Appendix A. The Complete Data Trees 2635 This appendix presents the complete configuration and state data 2636 trees of the core routing data model. 2638 See Section 2.2 for an explanation of the symbols used. Data type of 2639 every leaf node is shown near the right end of the corresponding 2640 line. 2642 A.1. Configuration Data 2644 +--rw routing 2645 +--rw routing-instance* [name] 2646 | +--rw name string 2647 | +--rw type? identityref 2648 | +--rw enabled? boolean 2649 | +--rw router-id? yang:dotted-quad 2650 | +--rw description? string 2651 | +--rw default-ribs {multiple-ribs}? 2652 | | +--rw default-rib* [address-family] 2653 | | +--rw address-family identityref 2654 | | +--rw rib-name string 2655 | +--rw interfaces 2656 | | +--rw interface* [name] 2657 | | +--rw name if:interface-ref 2658 | | +--rw v6ur:ipv6-router-advertisements 2659 | | +--rw v6ur:send-advertisements? boolean 2660 | | +--rw v6ur:max-rtr-adv-interval? uint16 2661 | | +--rw v6ur:min-rtr-adv-interval? uint16 2662 | | +--rw v6ur:managed-flag? boolean 2663 | | +--rw v6ur:other-config-flag? boolean 2664 | | +--rw v6ur:link-mtu? uint32 2665 | | +--rw v6ur:reachable-time? uint32 2666 | | +--rw v6ur:retrans-timer? uint32 2667 | | +--rw v6ur:cur-hop-limit? uint8 2668 | | +--rw v6ur:default-lifetime? uint16 2669 | | +--rw v6ur:prefix-list 2670 | | +--rw v6ur:prefix* [prefix-spec] 2671 | | +--rw v6ur:prefix-spec inet:ipv6-prefix 2672 | | +--rw (control-adv-prefixes)? 2673 | | +--:(no-advertise) 2674 | | | +--rw v6ur:no-advertise? empty 2675 | | +--:(advertise) 2676 | | +--rw v6ur:valid-lifetime? uint32 2677 | | +--rw v6ur:on-link-flag? boolean 2678 | | +--rw v6ur:preferred-lifetime? uint32 2679 | | +--rw v6ur:autonomous-flag? boolean 2680 | +--rw routing-protocols 2681 | +--rw routing-protocol* [type name] 2682 | +--rw type identityref 2683 | +--rw name string 2684 | +--rw description? string 2685 | +--rw enabled? boolean 2686 | +--rw route-preference? route-preference 2687 | +--rw connected-ribs 2688 | | +--rw connected-rib* [rib-name] 2689 | | +--rw rib-name rib-ref 2690 | +--rw static-routes 2691 | +--rw v6ur:ipv6 2692 | | +--rw v6ur:route* [destination-prefix] 2693 | | +--rw v6ur:destination-prefix inet:ipv6-prefix 2694 | | +--rw v6ur:description? string 2695 | | +--rw v6ur:next-hop 2696 | | +--rw (next-hop-options) 2697 | | +--:(simple-next-hop) 2698 | | | +--rw v6ur:outgoing-interface? 2699 | | +--:(special-next-hop) 2700 | | | +--rw v6ur:special-next-hop? enumeration 2701 | | +--:(next-hop-address) 2702 | | +--rw v6ur:next-hop-address? 2703 | +--rw v4ur:ipv4 2704 | +--rw v4ur:route* [destination-prefix] 2705 | +--rw v4ur:destination-prefix inet:ipv4-prefix 2706 | +--rw v4ur:description? string 2707 | +--rw v4ur:next-hop 2708 | +--rw (next-hop-options) 2709 | +--:(simple-next-hop) 2710 | | +--rw v4ur:outgoing-interface? 2711 | +--:(special-next-hop) 2712 | | +--rw v4ur:special-next-hop? enumeration 2713 | +--:(next-hop-address) 2714 | +--rw v4ur:next-hop-address? 2715 +--rw ribs 2716 +--rw rib* [name] 2717 +--rw name string 2718 +--rw address-family identityref 2719 +--rw description? string 2720 +--rw recipient-ribs {multiple-ribs}? 2721 +--rw recipient-rib* [rib-name] 2722 +--rw rib-name rib-ref 2724 A.2. State Data 2726 +--ro routing-state 2727 +--ro routing-instance* [name] 2728 | +--ro name string 2729 | +--ro type? identityref 2730 | +--ro default-ribs 2731 | | +--ro default-rib* [address-family] 2732 | | +--ro address-family identityref 2733 | | +--ro rib-name rib-state-ref 2734 | +--ro interfaces 2735 | | +--ro interface* [name] 2736 | | +--ro name if:interface-state-ref 2737 | | +--ro v6ur:ipv6-router-advertisements 2738 | | +--ro v6ur:send-advertisements? boolean 2739 | | +--ro v6ur:max-rtr-adv-interval? uint16 2740 | | +--ro v6ur:min-rtr-adv-interval? uint16 2741 | | +--ro v6ur:managed-flag? boolean 2742 | | +--ro v6ur:other-config-flag? boolean 2743 | | +--ro v6ur:link-mtu? uint32 2744 | | +--ro v6ur:reachable-time? uint32 2745 | | +--ro v6ur:retrans-timer? uint32 2746 | | +--ro v6ur:cur-hop-limit? uint8 2747 | | +--ro v6ur:default-lifetime? uint16 2748 | | +--ro v6ur:prefix-list 2749 | | +--ro v6ur:prefix* [prefix-spec] 2750 | | +--ro v6ur:prefix-spec inet:ipv6-prefix 2751 | | +--ro v6ur:valid-lifetime? uint32 2752 | | +--ro v6ur:on-link-flag? boolean 2753 | | +--ro v6ur:preferred-lifetime? uint32 2754 | | +--ro v6ur:autonomous-flag? boolean 2755 | +--ro routing-protocols 2756 | +--ro routing-protocol* [type name] 2757 | +--ro type identityref 2758 | +--ro name string 2759 | +--ro route-preference route-preference 2760 | +--ro connected-ribs 2761 | +--ro connected-rib* [rib-name] 2762 | +--ro rib-name rib-state-ref 2763 +--ro ribs 2764 +--ro rib* [name] 2765 +--ro name string 2766 +--ro address-family identityref 2767 +--ro routes 2768 | +--ro route* 2769 | +--ro route-preference? route-preference 2770 | +--ro next-hop 2771 | | +--ro (next-hop-options) 2772 | | +--:(simple-next-hop) 2773 | | | +--ro outgoing-interface? 2774 | | | +--ro v6ur:next-hop-address? inet:ipv6-address 2775 | | | +--ro v4ur:next-hop-address? inet:ipv4-address 2776 | | +--:(special-next-hop) 2777 | | +--ro special-next-hop? enumeration 2778 | +--ro source-protocol identityref 2779 | +--ro active? empty 2780 | +--ro last-updated? yang:date-and-time 2781 | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2782 | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2783 +--ro recipient-ribs 2784 +--ro recipient-rib* [rib-name] 2785 +--ro rib-name rib-state-ref 2787 Appendix B. Minimum Implementation 2789 Some parts and options of the core routing model, such as user- 2790 defined routing tables, are intended only for advanced routers. This 2791 appendix gives basic non-normative guidelines for implementing a bare 2792 minimum of available functions. Such an implementation may be used 2793 for hosts or very simple routers. 2795 A minimum implementation will provide a single system-controlled 2796 routing instance, and will not allow clients to create any user- 2797 controlled instances. 2799 Typically, the feature "multiple-ribs" will not be supported. This 2800 means that a single system-controlled RIB is available for each 2801 supported address family - IPv4, IPv6 or both. These RIBs must be 2802 the default RIBs, so references to them will also appear as system- 2803 controlled entries of the "default-rib" list in state data. No user- 2804 controlled RIBs are allowed. 2806 In addition to the mandatory instance of the "direct" pseudo- 2807 protocol, a minimum implementation should support configured 2808 instance(s) of the "static" pseudo-protocol. Even with a single RIB 2809 per address family, it may be occasionally useful to be able to 2810 configure multiple "static" instances. For example, a client may 2811 want to configure alternative sets of static routes and activate or 2812 deactivate them by means of connnecting the default RIB to the 2813 corresponding "static" instance. 2815 Platforms with severely constrained resources may use deviations for 2816 restricting the data model, e.g., limiting the number of "static" 2817 routing protocol instances. 2819 Appendix C. Example: Adding a New Routing Protocol 2821 This appendix demonstrates how the core routing data model can be 2822 extended to support a new routing protocol. The YANG module 2823 "example-rip" shown below is intended only as an illustration rather 2824 than a real definition of a data model for the RIP routing protocol. 2825 For the sake of brevity, this module does not obey all the guidelines 2826 specified in [RFC6087]. See also Section 5.4.2. 2828 module example-rip { 2830 namespace "http://example.com/rip"; 2832 prefix "rip"; 2834 import ietf-routing { 2835 prefix "rt"; 2836 } 2838 identity rip { 2839 base rt:routing-protocol; 2840 description 2841 "Identity for the RIP routing protocol."; 2842 } 2844 typedef rip-metric { 2845 type uint8 { 2846 range "0..16"; 2847 } 2848 } 2850 grouping route-content { 2851 description 2852 "This grouping defines RIP-specific route attributes."; 2853 leaf metric { 2854 type rip-metric; 2855 } 2856 leaf tag { 2857 type uint16; 2858 default "0"; 2859 description 2860 "This leaf may be used to carry additional info, e.g. AS 2861 number."; 2862 } 2863 } 2865 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2866 when "rt:source-protocol = 'rip:rip'" { 2867 description 2868 "This augment is only valid for a routes whose source 2869 protocol is RIP."; 2870 } 2871 description 2872 "RIP-specific route attributes."; 2873 uses route-content; 2874 } 2876 augment "/rt:active-route/rt:output/rt:route" { 2877 description 2878 "RIP-specific route attributes in the output of 'active-route' 2879 RPC."; 2880 uses route-content; 2881 } 2883 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2884 + "rt:routing-protocol" { 2885 when "rt:type = 'rip:rip'" { 2886 description 2887 "This augment is only valid for a routing protocol instance 2888 of type 'rip'."; 2889 } 2890 container rip { 2891 description 2892 "RIP instance configuration."; 2893 container interfaces { 2894 description 2895 "Per-interface RIP configuration."; 2896 list interface { 2897 key "name"; 2898 description 2899 "RIP is enabled on interfaces that have an entry in this 2900 list, unless 'enabled' is set to 'false' for that 2901 entry."; 2903 leaf name { 2904 type leafref { 2905 path "../../../../../../rt:interfaces/rt:interface/" 2906 + "rt:name"; 2907 } 2908 } 2909 leaf enabled { 2910 type boolean; 2911 default "true"; 2912 } 2913 leaf metric { 2914 type rip-metric; 2915 default "1"; 2916 } 2917 } 2918 } 2919 leaf update-interval { 2920 type uint8 { 2921 range "10..60"; 2922 } 2923 units "seconds"; 2924 default "30"; 2925 description 2926 "Time interval between periodic updates."; 2927 } 2928 } 2929 } 2930 } 2932 Appendix D. Example: NETCONF Reply 2934 This section contains a sample reply to the NETCONF message, 2935 which could be sent by a server supporting (i.e., advertising them in 2936 the NETCONF message) the following YANG modules: 2938 o ietf-interfaces [RFC7223], 2940 o ietf-ip [RFC7277], 2942 o ietf-routing (Section 7), 2944 o ietf-ipv4-unicast-routing (Section 8), 2946 o ietf-ipv6-unicast-routing (Section 9). 2948 We assume a simple network set-up as shown in Figure 4: router "A" 2949 uses static default routes with the "ISP" router as the next-hop. 2951 IPv6 router advertisements are configured only on the "eth1" 2952 interface and disabled on the upstream "eth0" interface. 2954 +-----------------+ 2955 | | 2956 | Router ISP | 2957 | | 2958 +--------+--------+ 2959 |2001:db8:0:1::2 2960 |192.0.2.2 2961 | 2962 | 2963 |2001:db8:0:1::1 2964 eth0|192.0.2.1 2965 +--------+--------+ 2966 | | 2967 | Router A | 2968 | | 2969 +--------+--------+ 2970 eth1|198.51.100.1 2971 |2001:db8:0:2::1 2972 | 2974 Figure 4: Example network configuration 2976 A reply to the NETCONF message sent by router "A" would then be 2977 as follows: 2979 2980 2989 2990 2991 2992 eth0 2993 ianaift:ethernetCsmacd 2994 2995 Uplink to ISP. 2996 2997 2998 2999 192.0.2.1 3000 24 3001 3002 true 3003 3004 3005 3006 2001:0db8:0:1::1 3007 64 3008 3009 true 3010 3011 false 3012 3013 3014 3015 3016 eth1 3017 ianaift:ethernetCsmacd 3018 3019 Interface to the internal network. 3020 3021 3022 3023 198.51.100.1 3024 24 3025 3026 true 3027 3028 3029 3030 2001:0db8:0:2::1 3031 64 3032 3033 true 3034 3035 false 3036 3037 3038 3039 3040 3041 3042 eth0 3043 ianaift:ethernetCsmacd 3044 00:0C:42:E5:B1:E9 3045 up 3046 3047 3048 2014-10-24T17:11:27+00:58 3049 3050 3051 3052 true 3053 1500 3054 3055 192.0.2.1 3056 24 3057 3058 3059 3060 true 3061 1500 3062 3063 2001:0db8:0:1::1 3064 64 3065 3066 3067 3068 3069 eth1 3070 ianaift:ethernetCsmacd 3071 up 3072 00:0C:42:E5:B1:EA 3073 3074 3075 2014-10-24T17:11:27+00:59 3076 3077 3078 3079 true 3080 1500 3081 3082 198.51.100.1 3083 24 3084 3085 3086 3087 true 3088 1500 3089 3090 2001:0db8:0:2::1 3091 64 3092 3093 3094 3096 3097 3098 3099 rtr0 3100 Router A 3101 3102 3103 eth1 3104 3105 true 3106 3107 3108 2001:db8:0:2::/64 3109 3110 3111 3112 3113 3114 3115 3116 rt:static 3117 st0 3118 3119 Static routing is used for the internal network. 3120 3121 3122 3123 3124 0.0.0.0/0 3125 3126 192.0.2.2 3127 3128 3129 3130 3131 3132 ::/0 3133 3134 2001:db8:0:1::2 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 rtr0 3146 3147 3148 v4ur:ipv4-unicast 3149 ipv4-master 3150 3151 3152 v6ur:ipv6-unicast 3153 ipv6-master 3154 3155 3156 3157 3158 eth0 3159 3160 3161 eth1 3162 3163 true 3164 3165 3166 2001:db8:0:2::/64 3167 3168 3169 3170 3171 3172 3173 3174 rt:static 3175 st0 3176 5 3177 3178 3179 3180 3181 3182 ipv4-master 3183 v4ur:ipv4-unicast 3184 3185 3186 192.0.2.1/24 3187 3188 eth0 3189 3190 0 3191 rt:direct 3192 2014-10-24T17:11:27+01:00 3193 3194 3195 198.51.100.0/24 3196 3197 eth1 3198 3199 rt:direct 3200 0 3201 2014-10-24T17:11:27+01:00 3202 3203 3204 0.0.0.0/0 3205 rt:static 3206 5 3207 3208 192.0.2.2 3209 3210 2014-10-24T18:02:45+01:00 3211 3212 3213 3214 3215 ipv6-master 3216 v6ur:ipv6-unicast 3217 3218 3219 3220 2001:db8:0:1::/64 3221 3222 3223 eth0 3224 3225 rt:direct 3226 0 3227 2014-10-24T17:11:27+01:00 3228 3229 3230 3231 2001:db8:0:2::/64 3232 3233 3234 eth1 3235 3236 rt:direct 3237 0 3238 2014-10-24T17:11:27+01:00 3239 3240 3241 ::/0 3242 3243 2001:db8:0:1::2 3244 3245 rt:static 3246 5 3247 2014-10-24T18:02:45+01:00 3248 3249 3250 3251 3252 3253 3254 3256 Appendix E. Change Log 3258 RFC Editor: Remove this section upon publication as an RFC. 3260 E.1. Changes Between Versions -16 and -17 3262 o Added Acee as a co-author. 3264 o Removed all traces of route filters. 3266 o Removed numeric IDs of list entries in state data. 3268 o Removed all next-hop cases except "simple-next-hop" and "special- 3269 next-hop". 3271 o Removed feature "multipath-routes". 3273 o Augmented "ietf-interfaces" module with a leaf-list of leafrefs 3274 pointing form state data of an interface entry to the routing 3275 instance(s) to which the interface is assigned. 3277 E.2. Changes Between Versions -15 and -16 3279 o Added 'type' as the second key component of 'routing-protocol', 3280 both in configuration and state data. 3282 o The restriction of no more than one connected RIB per address 3283 family was removed. 3285 o Removed the 'id' key of routes in RIBs. This list has no keys 3286 anymore. 3288 o Remove the 'id' key from static routes and make 'destination- 3289 prefix' the only key. 3291 o Added 'route-preference' as a new attribute of routes in RIB. 3293 o Added 'active' as a new attribute of routes in RIBs. 3295 o Renamed RPC operation 'active-route' to 'fib-route'. 3297 o Added 'route-preference' as a new parameter of routing protocol 3298 instances, both in configuration and state data. 3300 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 3301 routing-instance'. 3303 o Added next-hop lists to state data. 3305 o Added two cases for specifying next-hops indirectly - via a new 3306 RIB or a recursive list of next-hops. 3308 o Reorganized next-hop in static routes. 3310 o Removed all 'if-feature' statements from state data. 3312 E.3. Changes Between Versions -14 and -15 3314 o Removed all defaults from state data. 3316 o Removed default from 'cur-hop-limit' in config. 3318 E.4. Changes Between Versions -13 and -14 3320 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 3321 feature. 3323 o Removed default value of 'cur-hop-limit' in state data. 3325 o Moved parts of descriptions and all references on IPv6 RA 3326 parameters from state data to configuration. 3328 o Added reference to RFC 6536 in the Security section. 3330 E.5. Changes Between Versions -12 and -13 3332 o Wrote appendix about minimum implementation. 3334 o Remove "when" statement for IPv6 router interface state data - it 3335 was dependent on a config value that may not be present. 3337 o Extra container for the next-hop list. 3339 o Names rather than numeric ids are used for referring to list 3340 entries in state data. 3342 o Numeric ids are always declared as mandatory and unique. Their 3343 description states that they are ephemeral. 3345 o Descriptions of "name" keys in state data lists are required to be 3346 persistent. 3348 o 3350 o Removed "if-feature multiple-ribs;" from connected-ribs. 3352 o "rib-name" instead of "name" is used as the name of leafref nodes. 3354 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3355 in node names and text. 3357 E.6. Changes Between Versions -11 and -12 3359 o Removed feature "advanced-router" and introduced two features 3360 instead: "multiple-ribs" and "multipath-routes". 3362 o Unified the keys of config and state versions of "routing- 3363 instance" and "rib" lists. 3365 o Numerical identifiers of state list entries are not keys anymore, 3366 but they are constrained using the "unique" statement. 3368 o Updated acknowledgements. 3370 E.7. Changes Between Versions -10 and -11 3372 o Migrated address families from IANA enumerations to identities. 3374 o Terminology and node names aligned with the I2RS RIB model: router 3375 -> routing instance, routing table -> RIB. 3377 o Introduced uint64 keys for state lists: routing-instance, rib, 3378 route, nexthop. 3380 o Described the relationship between system-controlled and user- 3381 controlled list entries. 3383 o Feature "user-defined-routing-tables" changed into "advanced- 3384 router". 3386 o Made nexthop into a choice in order to allow for nexthop-list 3387 (I2RS requirement). 3389 o Added nexthop-list with entries having priorities (backup) and 3390 weights (load balancing). 3392 o Updated bibliography references. 3394 E.8. Changes Between Versions -09 and -10 3396 o Added subtree for state data ("/routing-state"). 3398 o Terms "system-controlled entry" and "user-controlled entry" 3399 defined and used. 3401 o New feature "user-defined-routing-tables". Nodes that are useful 3402 only with user-defined routing tables are now conditional. 3404 o Added grouping "router-id". 3406 o In routing tables, "source-protocol" attribute of routes now 3407 reports only protocol type, and its datatype is "identityref". 3409 o Renamed "main-routing-table" to "default-routing-table". 3411 E.9. Changes Between Versions -08 and -09 3413 o Fixed "must" expresion for "connected-routing-table". 3415 o Simplified "must" expression for "main-routing-table". 3417 o Moved per-interface configuration of a new routing protocol under 3418 'routing-protocol'. This also affects the 'example-rip' module. 3420 E.10. Changes Between Versions -07 and -08 3422 o Changed reference from RFC6021 to RFC6021bis. 3424 E.11. Changes Between Versions -06 and -07 3426 o The contents of in Appendix D was updated: "eth[01]" 3427 is used as the value of "location", and "forwarding" is on for 3428 both interfaces and both IPv4 and IPv6. 3430 o The "must" expression for "main-routing-table" was modified to 3431 avoid redundant error messages reporting address family mismatch 3432 when "name" points to a non-existent routing table. 3434 o The default behavior for IPv6 RA prefix advertisements was 3435 clarified. 3437 o Changed type of "rt:router-id" to "ip:dotted-quad". 3439 o Type of "rt:router-id" changed to "yang:dotted-quad". 3441 o Fixed missing prefixes in XPath expressions. 3443 E.12. Changes Between Versions -05 and -06 3445 o Document title changed: "Configuration" was replaced by 3446 "Management". 3448 o New typedefs "routing-table-ref" and "route-filter-ref". 3450 o Double slashes "//" were removed from XPath expressions and 3451 replaced with the single "/". 3453 o Removed uniqueness requirement for "router-id". 3455 o Complete data tree is now in Appendix A. 3457 o Changed type of "source-protocol" from "leafref" to "string". 3459 o Clarified the relationship between routing protocol instances and 3460 connected routing tables. 3462 o Added a must constraint saying that a routing table connected to 3463 the direct pseudo-protocol must not be a main routing table. 3465 E.13. Changes Between Versions -04 and -05 3467 o Routing tables are now global, i.e., "routing-tables" is a child 3468 of "routing" rather than "router". 3470 o "must" statement for "static-routes" changed to "when". 3472 o Added "main-routing-tables" containing references to main routing 3473 tables for each address family. 3475 o Removed the defaults for "address-family" and "safi" and made them 3476 mandatory. 3478 o Removed the default for route-filter/type and made this leaf 3479 mandatory. 3481 o If there is no active route for a given destination, the "active- 3482 route" RPC returns no output. 3484 o Added "enabled" switch under "routing-protocol". 3486 o Added "router-type" identity and "type" leaf under "router". 3488 o Route attribute "age" changed to "last-updated", its type is 3489 "yang:date-and-time". 3491 o The "direct" pseudo-protocol is always connected to main routing 3492 tables. 3494 o Entries in the list of connected routing tables renamed from 3495 "routing-table" to "connected-routing-table". 3497 o Added "must" constraint saying that a routing table must not be 3498 its own recipient. 3500 E.14. Changes Between Versions -03 and -04 3502 o Changed "error-tag" for both RPC operations from "missing element" 3503 to "data-missing". 3505 o Removed the decrementing behavior for advertised IPv6 prefix 3506 parameters "valid-lifetime" and "preferred-lifetime". 3508 o Changed the key of the static route lists from "seqno" to "id" 3509 because the routes needn't be sorted. 3511 o Added 'must' constraint saying that "preferred-lifetime" must not 3512 be greater than "valid-lifetime". 3514 E.15. Changes Between Versions -02 and -03 3516 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3518 o Removed forwarding table. 3520 o RPC "get-route" changed to "active-route". Its output is a list 3521 of routes (for multi-path routing). 3523 o New RPC "route-count". 3525 o For both RPCs, specification of negative responses was added. 3527 o Relaxed separation of router instances. 3529 o Assignment of interfaces to router instances needn't be disjoint. 3531 o Route filters are now global. 3533 o Added "allow-all-route-filter" for symmetry. 3535 o Added Section 6 about interactions with "ietf-interfaces" and 3536 "ietf-ip". 3538 o Added "router-id" leaf. 3540 o Specified the names for IPv4/IPv6 unicast main routing tables. 3542 o Route parameter "last-modified" changed to "age". 3544 o Added container "recipient-routing-tables". 3546 E.16. Changes Between Versions -01 and -02 3548 o Added module "ietf-ipv6-unicast-routing". 3550 o The example in Appendix D now uses IP addresses from blocks 3551 reserved for documentation. 3553 o Direct routes appear by default in the forwarding table. 3555 o Network layer interfaces must be assigned to a router instance. 3556 Additional interface configuration may be present. 3558 o The "when" statement is only used with "augment", "must" is used 3559 elsewhere. 3561 o Additional "must" statements were added. 3563 o The "route-content" grouping for IPv4 and IPv6 unicast now 3564 includes the material from the "ietf-routing" version via "uses 3565 rt:route-content". 3567 o Explanation of symbols in the tree representation of data model 3568 hierarchy. 3570 E.17. Changes Between Versions -00 and -01 3572 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3574 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3575 safi" module. 3577 o Names of some data nodes were changed, in particular "routing- 3578 process" is now "router". 3580 o The restriction of a single AFN/SAFI per router was lifted. 3582 o RPC operation "delete-route" was removed. 3584 o Illegal XPath references from "get-route" to the datastore were 3585 fixed. 3587 o Section "Security Considerations" was written. 3589 Authors' Addresses 3591 Ladislav Lhotka 3592 CZ.NIC 3594 Email: lhotka@nic.cz 3596 Acee Lindem 3597 Cisco Systems 3599 Email: acee@cisco.com