idnits 2.17.1 draft-ietf-netmod-routing-cfg-16.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 3133 has weird spacing: '...-family ide...' == Line 3228 has weird spacing: '...-family ide...' == Line 3232 has weird spacing: '...ib-name rib...' == Line 3249 has weird spacing: '...-family ide...' == Line 3276 has weird spacing: '...ference rou...' == (5 more instances...) -- The document date (October 26, 2014) is 3463 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 October 26, 2014 5 Expires: April 29, 2015 7 A YANG Data Model for Routing Management 8 draft-ietf-netmod-routing-cfg-16 10 Abstract 12 This document contains a specification of three YANG modules. 13 Together they form the core routing data model which serves as a 14 framework for configuring and managing a routing subsystem. It is 15 expected that these modules will be augmented by additional YANG 16 modules defining data models for routing protocols and other 17 functions. The core routing data model provides common building 18 blocks for such extensions - routing instances, routes, routing 19 information bases (RIB), routing protocols and route filters. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 29, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 57 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 58 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 60 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. The Design of the Core Routing Data Model . . . . . . . . . . 6 62 4.1. System-Controlled and User-Controlled List Entries . . . 10 63 4.2. Features of Advanced Routers . . . . . . . . . . . . . . 10 64 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 11 65 5.1. Routing Instance . . . . . . . . . . . . . . . . . . . . 11 66 5.1.1. Parameters of IPv6 Routing Instance Interfaces . . . 12 67 5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 5.3. Routing Information Base (RIB) . . . . . . . . . . . . . 14 69 5.3.1. Multiple RIBs per Address Family . . . . . . . . . . 15 70 5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 15 71 5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 16 72 5.4.2. Defining New Routing Protocols . . . . . . . . . . . 18 73 5.5. Route Filter . . . . . . . . . . . . . . . . . . . . . . 19 74 5.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . 20 75 6. Interactions with Other YANG Modules . . . . . . . . . . . . 20 76 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 20 77 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 20 78 7. Routing Management YANG Module . . . . . . . . . . . . . . . 21 79 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 44 80 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 49 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 64 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 65 86 13.2. Informative References . . . . . . . . . . . . . . . . . 66 87 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 66 88 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 66 89 A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 69 90 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 71 91 Appendix C. Example: Adding a New Routing Protocol . . . . . . . 72 92 Appendix D. Example: NETCONF Reply . . . . . . . . . . . . 74 93 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 81 94 E.1. Changes Between Versions -15 and -16 . . . . . . . . . . 81 95 E.2. Changes Between Versions -14 and -15 . . . . . . . . . . 82 96 E.3. Changes Between Versions -13 and -14 . . . . . . . . . . 82 97 E.4. Changes Between Versions -12 and -13 . . . . . . . . . . 82 98 E.5. Changes Between Versions -11 and -12 . . . . . . . . . . 83 99 E.6. Changes Between Versions -10 and -11 . . . . . . . . . . 83 100 E.7. Changes Between Versions -09 and -10 . . . . . . . . . . 84 101 E.8. Changes Between Versions -08 and -09 . . . . . . . . . . 84 102 E.9. Changes Between Versions -07 and -08 . . . . . . . . . . 84 103 E.10. Changes Between Versions -06 and -07 . . . . . . . . . . 84 104 E.11. Changes Between Versions -05 and -06 . . . . . . . . . . 85 105 E.12. Changes Between Versions -04 and -05 . . . . . . . . . . 85 106 E.13. Changes Between Versions -03 and -04 . . . . . . . . . . 86 107 E.14. Changes Between Versions -02 and -03 . . . . . . . . . . 86 108 E.15. Changes Between Versions -01 and -02 . . . . . . . . . . 87 109 E.16. Changes Between Versions -00 and -01 . . . . . . . . . . 87 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 88 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 active route: a route that is actually used for sending packets. If 176 there are multiple candidate routes with a matching destination 177 prefix, then it is up to the routing algorithm to select the 178 active route. 180 core routing data model: YANG data model comprising "ietf-routing", 181 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 182 modules. 184 direct route: a route to a directly connected network. 186 routing information base (RIB): An object containing a list of 187 routes together with other information. See Section 5.3 for 188 details. 190 system-controlled entry: An entry of a list in state data ("config 191 false") that is created by the system independently of what has 192 been explicitly configured. See Section 4.1 for details. 194 user-controlled entry: An entry of a list in state data ("config 195 false") that is created and deleted as a direct consequence of 196 certain configuration changes. See Section 4.1 for details. 198 2.2. Tree Diagrams 200 A simplified graphical representation of the complete data tree is 201 presented in Appendix A, and similar diagrams of its various subtrees 202 appear in the main text. 204 The meaning of the symbols in these diagrams is as follows: 206 o Brackets "[" and "]" enclose list keys. 208 o Curly braces "{" and "}" contain names of optional features that 209 make the corresponding node conditional. 211 o Abbreviations before data node names: "rw" means configuration 212 (read-write), and "ro" state data (read-only). 214 o Symbols after data node names: "?" means an optional node and "*" 215 denotes a "list" or "leaf-list". 217 o Parentheses enclose choice and case nodes, and case nodes are also 218 marked with a colon (":"). 220 o Ellipsis ("...") stands for contents of subtrees that are not 221 shown. 223 2.3. Prefixes in Data Node Names 225 In this document, names of data nodes, RPC methods and other data 226 model objects are often used without a prefix, as long as it is clear 227 from the context in which YANG module each name is defined. 228 Otherwise, names are prefixed using the standard prefix associated 229 with the corresponding YANG module, as shown in Table 1. 231 +--------+---------------------------+-----------+ 232 | Prefix | YANG module | Reference | 233 +--------+---------------------------+-----------+ 234 | if | ietf-interfaces | [RFC7223] | 235 | ip | ietf-ip | [RFC7277] | 236 | rt | ietf-routing | Section 7 | 237 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 238 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 239 | yang | ietf-yang-types | [RFC6991] | 240 | inet | ietf-inet-types | [RFC6991] | 241 +--------+---------------------------+-----------+ 243 Table 1: Prefixes and corresponding YANG modules 245 3. Objectives 247 The initial design of the core routing data model was driven by the 248 following objectives: 250 o The data model should be suitable for the common address families, 251 in particular IPv4 and IPv6, and for unicast and multicast 252 routing, as well as Multiprotocol Label Switching (MPLS). 254 o Simple routing set-ups, such as static routing, should be 255 configurable in a simple way, ideally without any need to develop 256 additional YANG modules. 258 o On the other hand, the core routing framework must allow for 259 complicated set-ups involving multiple routing information bases 260 (RIB) and multiple routing protocols, as well as controlled 261 redistributions of routing information. 263 o Device vendors will want to map the data models built on this 264 generic framework to their proprietary data models and 265 configuration interfaces. Therefore, the framework should be 266 flexible enough to facilitate such a mapping and accommodate data 267 models with different logic. 269 4. The Design of the Core Routing Data Model 271 The core routing data model consists of three YANG modules. The 272 first module, "ietf-routing", defines the generic components of a 273 routing system. The other two modules, "ietf-ipv4-unicast-routing" 274 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 275 with additional data nodes that are needed for IPv4 and IPv6 unicast 276 routing, respectively. Figures 1 and 2 show abridged views of the 277 configuration and state data hierarchies. See Appendix A for the 278 complete data trees. 280 +--rw routing 281 +--rw routing-instance* [name] 282 | +--rw name 283 | +--rw type? 284 | +--rw enabled? 285 | +--rw router-id? 286 | +--rw description? 287 | +--rw default-ribs 288 | | +--rw default-rib* [address-family] 289 | | +--rw address-family 290 | | +--rw rib-name 291 | +--rw interfaces 292 | | +--rw interface* [name] 293 | | +--rw name 294 | | +--rw v6ur:ipv6-router-advertisements 295 | | ... 296 | +--rw routing-protocols 297 | +--rw routing-protocol* [type name] 298 | +--rw type 299 | +--rw name 300 | +--rw description? 301 | +--rw enabled? 302 | +--rw route-preference? 303 | +--rw connected-ribs 304 | | ... 305 | +--rw static-routes 306 | ... 307 +--rw ribs 308 | +--rw rib* [name] 309 | +--rw name 310 | +--rw address-family 311 | +--rw description? 312 | +--rw recipient-ribs 313 | +--rw recipient-rib* [rib-name] 314 | ... 315 +--rw route-filters 316 +--rw route-filter* [name] 317 +--rw name 318 +--rw description? 319 +--rw type 321 Figure 1: Configuration data hierarchy. 323 +--ro routing-state 324 +--ro routing-instance* [name] 325 | +--ro name 326 | +--ro id 327 | +--ro type? 328 | +--ro default-ribs 329 | | +--ro default-rib* [address-family] 330 | | +--ro address-family 331 | | +--ro rib-name 332 | +--ro interfaces 333 | | +--ro interface* [name] 334 | | +--ro name 335 | | +--ro v6ur:ipv6-router-advertisements 336 | | ... 337 | +--ro routing-protocols 338 | +--ro routing-protocol* [type name] 339 | +--ro type 340 | +--ro name 341 | +--ro route-preference 342 | +--ro connected-ribs 343 | ... 344 +--ro next-hop-lists 345 | +--ro next-hop-list* [id] 346 | +--ro id 347 | +--ro address-family 348 | +--ro next-hop* 349 | +--ro (next-hop-options) 350 | | ... 351 | +--ro priority? 352 | +--ro weight? 353 +--ro ribs 354 | +--ro rib* [name] 355 | +--ro name 356 | +--ro id 357 | +--ro address-family 358 | +--ro routes 359 | | +--ro route* 360 | | ... 361 | +--ro recipient-ribs 362 | +--ro recipient-rib* [rib-name] 363 | ... 364 +--ro route-filters 365 +--ro route-filter* [name] 366 +--ro name 367 +--ro type 369 Figure 2: State data hierarchy. 371 As can be seen from Figures 1 and 2, the core routing data model 372 introduces several generic components of a routing framework: routing 373 instances, RIBs containing lists of routes, routing protocols and 374 route filters. The following subsections describe these components 375 in more detail. 377 By combining the components in various ways, and possibly augmenting 378 them with appropriate contents defined in other modules, various 379 routing systems can be realized. 381 +--------+ 382 | direct | +---+ +--------------+ +---+ +--------------+ 383 | routes |--->| F |--->| |<---| F |<---| | 384 +--------+ +---+ | default | +---+ | additional | 385 | RIB | | RIB | 386 +--------+ +---+ | | +---+ | | 387 | static |--->| F |--->| |--->| F |--->| | 388 | routes | +---+ +--------------+ +---+ +--------------+ 389 +--------+ ^ | ^ | 390 | v | v 391 +---+ +---+ +---+ +---+ 392 | F | | F | | F | | F | 393 +---+ +---+ +---+ +---+ 394 ^ | ^ | 395 | v | v 396 +----------+ +----------+ 397 | routing | | routing | 398 | protocol | | protocol | 399 +----------+ +----------+ 401 Figure 3: Example set-up of a routing system 403 The example in Figure 3 shows a typical (though certainly not the 404 only possible) organization of a more complex routing subsystem for a 405 single address family. Several of its features are worth mentioning: 407 o Along with the default RIB, which is always present, an additional 408 RIB is configured. 410 o Each routing protocol instance, including the "static" and 411 "direct" pseudo-protocols, is connected to exactly one RIB with 412 which it can exchange routes (in both directions, except for the 413 "static" and "direct" pseudo-protocols). 415 o RIBs may also be connected to each other and exchange routes in 416 either direction (or both). 418 o Route exchanges along all connections may be controlled by means 419 of route filters, denoted by "F" in Figure 3. 421 4.1. System-Controlled and User-Controlled List Entries 423 The core routing data model defines several lists, for example 424 "routing-instance" or "rib", that have to be populated with at least 425 one entry in any properly functioning device, and additional entries 426 may be configured by the user. 428 In such a list, the server creates the required item as a so-called 429 system-controlled entry in state data, i.e., inside the "routing- 430 state" container. 432 Additional entries may be created in the configuration by the user, 433 e.g., via the NETCONF protocol. These are so-called user-controlled 434 entries. If the server accepts a configured user-controlled entry, 435 then this entry also appears in the state data version of the list. 437 Corresponding entries in both versions of the list (in state data and 438 configuration) have the same value of the list key. 440 The user may also provide supplemental configuration of system- 441 controlled entries. To do so, the user creates a new entry in the 442 configuration with the desired contents. In order to bind this entry 443 with the corresponding entry in the state data list, the key of the 444 configuration entry has to be set to the same value as the key of the 445 state entry. 447 An example can be seen in Appendix D: the "/routing-state/routing- 448 instance" list has a single system-controlled entry whose "name" key 449 has the value "rtr0". This entry is configured by the "/routing/ 450 routing-instance" entry whose "name" key is also "rtr0". 452 Deleting a user-controlled entry from the configuration list results 453 in the removal of the corresponding entry in the state data list. In 454 contrast, if a system-controlled entry is deleted from the 455 configuration list, only the extra configuration specified in that 456 entry is removed but the corresponding state data entry remains in 457 the list. 459 4.2. Features of Advanced Routers 461 The core routing data model attempts to address devices with 462 elementary routing functions as well as advanced routers. For simple 463 devices, some parts and options of the data model are not needed and 464 would represent unnecessary complications for the implementation. 465 Therefore, the core routing data model makes the configuration of 466 some advanced functions optional to implement by means of two YANG 467 features: 469 o "multiple-ribs" - indicates that the device supports configuration 470 of user-defined RIBs, routing protocols connected to non-default 471 RIBs, and RIBs configured as receivers of routes from other RIBs. 473 o "multipath-routes" - indicates that the device supports 474 configuration of routes with multiple next-hops. 476 See the "ietf-routing" module for details. 478 5. Basic Building Blocks 480 This section describes the essential components of the core routing 481 data model. 483 5.1. Routing Instance 485 The core routing data model supports one or more routing instances 486 appearing as entries of the "routing-instance" list. Each routing 487 instance has separate configuration and state data under 488 "/rt:routing/rt:routing-instance" and "/rt:routing-state/rt:routing- 489 instance", respectively. 491 The semantics of the term "routing instance" is deliberately left 492 undefined. It is expected that future YANG modules will define data 493 models for specific types of routing instances, such as VRF (virtual 494 routing and forwarding) instances that are used for BGP/MPLS virtual 495 private networks [RFC4364]. For each type of routing instance, an 496 identity derived from "rt:routing-instance" MUST be defined. This 497 identity is then referred to by the value of the "type" leaf (a child 498 node of "routing-instance" list). 500 An implementation MAY create one or more system-controlled routing 501 instances, and MAY also impose restrictions on types of routing 502 instances that can be configured, and on the maximum number of 503 supported instances for each type. For example, a simple router 504 implementation may support only one system-controlled routing 505 instance of the default type "rt:default-routing-instance" and may 506 not allow creation of any user-controlled instances. 508 Each network layer interface has to be assigned to one or more 509 routing instances in order to be able to participate in packet 510 forwarding, routing protocols and other operations of those routing 511 instances. The assignment is accomplished by placing a corresponding 512 (system- or user-controlled) entry in the list of routing instance 513 interfaces ("rt:interface"). The key of the list entry is the name 514 of a configured network layer interface, see the "ietf-interfaces" 515 module [RFC7223]. 517 A data model for a routing instance type MAY state additional rules 518 for the assignment of interfaces to routing instances of that type. 519 For example, it may be required that the sets of interfaces assigned 520 to different routing instances of a certain type be disjoint. 522 5.1.1. Parameters of IPv6 Routing Instance Interfaces 524 The module "ietf-ipv6-unicast-routing" augments the definition of the 525 data node "rt:interface", in both configuration and state data, with 526 definitions of the following variables as required by [RFC4861], sec. 527 6.2.1: 529 o send-advertisements, 531 o max-rtr-adv-interval, 533 o min-rtr-adv-interval, 535 o managed-flag, 537 o other-config-flag, 539 o link-mtu, 541 o reachable-time, 543 o retrans-timer, 545 o cur-hop-limit, 547 o default-lifetime, 549 o prefix-list: a list of prefixes to be advertised. 551 The following parameters are associated with each prefix in the 552 list: 554 * valid-lifetime, 556 * on-link-flag, 558 * preferred-lifetime, 560 * autonomous-flag. 562 The definitions and descriptions of the above parameters can be found 563 in the module "ietf-ipv6-unicast-routing" (Section 9). 565 NOTES: 567 1. The "IsRouter" flag, which is also required by [RFC4861], is 568 implemented in the "ietf-ip" module [RFC7277] (leaf 569 "ip:forwarding"). 571 2. The original specification [RFC4861] allows the implementations 572 to decide whether the "valid-lifetime" and "preferred-lifetime" 573 parameters remain the same in consecutive advertisements, or 574 decrement in real time. However, the latter behavior seems 575 problematic because the values might be reset again to the 576 (higher) configured values after a configuration is reloaded. 577 Moreover, no implementation is known to use the decrementing 578 behavior. The "ietf-ipv6-unicast-routing" module therefore 579 assumes the former behavior with constant values. 581 5.2. Route 583 Routes are basic elements of information in a routing system. The 584 core routing data model defines only the following minimal set of 585 route attributes: 587 o "destination-prefix": IP prefix specifying the set of destination 588 addresses for which the route may be used. This attribute is 589 mandatory. 591 o "route-preference": an integer value (also known as administrative 592 distance) that is used for selecting a preferred route among 593 routes with the same destination prefix. A lower value means a 594 more preferred route. 596 o "next-hop": determines the action to be performed with a packet. 597 See below for details. 599 The choice of next-hops comprises the following cases: 601 o simple next-hop - IP address of the next-hop router, outgoing 602 interface, or both. 604 o special next-hop - a keyword indicating special packet handling, 605 one of: 607 * "blackhole" - silently discard the packet; 608 * "unreachable" - discard the packet and notify the sender with a 609 "destination unreachable" error message; 611 * "prohibit" - discard the packet notify the sender with an 612 "administratively prohibited" error message. 614 o next-hop list reference - each next-hop list is a set of next-hops 615 that may also contain a reference to another next-hop list. 617 o RIB reference - a new look-up is to be performed in the specified 618 RIB. 620 It is expected that future modules defining routing protocols will 621 add other route attributes such as metrics or preferences. 623 Routes are primarily state data that appear as entries of RIBs 624 (Section 5.3) but they may be also found in configuration data, for 625 example as manually configured static routes. In the latter case, 626 configurable route attributes are generally a subset of route 627 attributes described above. 629 5.3. Routing Information Base (RIB) 631 A routing information base (RIB) is a list of routes complemented 632 with administrative data, namely: 634 o "source-protocol": type of the routing protocol from which the 635 route was originally obtained. 637 o "preferred": an implementation can use this empty leaf to indicate 638 that the route is preferred among all routes in the same RIB that 639 have the same destination prefix. 641 o "last-updated": the date and time when the route was last updated, 642 or inserted into the RIB. 644 Each RIB MUST contain only routes of one address family. In the data 645 model, address family is represented with an identity derived from 646 the "rt:address-family" base identity. 648 In the core routing data model, RIBs are state data represented as 649 entries of the list "/routing-state/ribs/rib". The contents of RIBs 650 are controlled and manipulated by routing protocol operations which 651 may result in route additions, removals and modifications. This also 652 includes manipulations via the "static" and/or "direct" pseudo- 653 protocols, see Section 5.4.1. 655 RIBs are global, which means that a RIB may be used by any or all 656 routing instances. However, a data model for a routing instance type 657 MAY state rules and restrictions for sharing RIBs among routing 658 instances of that type. 660 Each routing instance has, for every supported address family, one 661 RIB selected as the so-called default RIB. This selection is 662 recorded in the list "default-rib". The role of default RIBs is 663 explained in Section 5.4. 665 Simple router implementations that do not advertise the feature 666 "multiple-ribs" will typically create one system-controlled RIB per 667 supported address family, and declare it as the default RIB (via a 668 system-controlled entry of the "default-rib" list). 670 5.3.1. Multiple RIBs per Address Family 672 More complex router implementations advertising the "multiple-ribs" 673 feature support multiple RIBs per address family that can be used for 674 policy routing and other purposes. Every RIB can then serve as a 675 source of routes for other RIBs of the same address family. To 676 achieve this, one or more recipient RIBs may be specified in the 677 configuration of the source RIB. Optionally, a route filter may be 678 configured for any or all recipient RIBs. Such a route filter then 679 selects and/or manipulates the routes that are passed between the 680 source and recipient RIB. 682 A RIB MUST NOT appear among its own recipient RIBs. 684 5.4. Routing Protocol 686 The core routing data model provides an open-ended framework for 687 defining multiple routing protocol instances within a routing 688 instance. Each routing protocol instance MUST be assigned a type, 689 which is an identity derived from the "rt:routing-protocol" base 690 identity. The core routing data model defines two identities for the 691 direct and static pseudo-protocols (Section 5.4.1). 693 Multiple routing protocol instances of the same type are permitted. 695 Each routing protocol instance can be connected to one or more RIBs 696 for each address family that the routing protocol instance supports. 697 By default, the interaction of a routing protocol instance with its 698 connected RIBs is governed by the following rules: 700 o Routes learned from the network are installed in all connected 701 RIBs with a matching address family. 703 o Conversely, routes from all connected RIBs are injected into the 704 routing protocol instance. 706 However, a data model for a routing protocol MAY impose specific 707 rules for exchanging routes between routing protocol instances and 708 connected RIBs. 710 On devices supporting the "multiple-ribs" feature, any RIB (system- 711 controlled or user-controlled) may be connected to a routing protocol 712 instance by configuring a corresponding entry in the "connected-rib" 713 list. If such an entry is not configured for an address family, then 714 the default RIB MUST be used as the connected RIB for this address 715 family. 717 In addition, two independent route filters (see Section 5.5) may be 718 configured for each connected RIB to apply user-defined policies 719 controlling the exchange of routes in both directions between the 720 routing protocol instance and the connected RIB: 722 o import filter controls which routes are passed from the routing 723 protocol instance to the connected RIB, 725 o export filter controls which routes the routing protocol instance 726 receives from the connected RIB. 728 Note that the terms import and export are used from the viewpoint of 729 a RIB. 731 5.4.1. Routing Pseudo-Protocols 733 The core routing data model defines two special routing protocol 734 types - "direct" and "static". Both are in fact pseudo-protocols, 735 which means they are confined to the local device and do not exchange 736 any routing information with adjacent routers. Routes from both 737 "direct" and "static" protocol instances are passed to the connected 738 RIBs (subject to route filters, if any), but an exchange in the 739 opposite direction is not allowed. 741 Every routing instance MUST implement exactly one instance of the 742 "direct" pseudo-protocol type. It is the source of direct routes for 743 all configured address families. Direct routes are normally supplied 744 by the operating system kernel, based on the configuration of network 745 interface addresses, see Section 6.2. The "direct" pseudo-protocol 746 MUST always be connected to the default RIBs of all supported address 747 families. Unlike other routing protocol types, this connection 748 cannot be changed in the configuration. Direct routes MAY be 749 filtered before they appear in the default RIB. 751 A pseudo-protocol of the type "static" allows for specifying routes 752 manually. It MAY be configured in zero or multiple instances, 753 although a typical configuration will have exactly one instance per 754 routing instance. 756 Static routes are configured within the "static-routes" container, 757 see Figure 4. 759 +--rw static-routes 760 +--rw v4ur:ipv4 761 | +--rw v4ur:route* [destination-prefix] 762 | +--rw v4ur:destination-prefix 763 | +--rw v4ur:description? 764 | +--rw v4ur:next-hop 765 | +--rw (simple-or-list)? 766 | +--:(multipath-entry) 767 | | +--rw v4ur:multipath-entry* [name] 768 | | +--rw v4ur:name 769 | | +--rw (next-hop-options) 770 | | | +--:(simple-next-hop) 771 | | | | +--rw v4ur:outgoing-interface? 772 | | | +--:(special-next-hop) 773 | | | | +--rw v4ur:special-next-hop? 774 | | | +--:(next-hop-address) 775 | | | +--rw v4ur:next-hop-address? 776 | | +--rw v4ur:priority? 777 | | +--rw v4ur:weight? 778 | +--:(simple-next-hop) 779 | +--rw (next-hop-options) 780 | +--:(simple-next-hop) 781 | | +--rw v4ur:outgoing-interface? 782 | +--:(special-next-hop) 783 | | +--rw v4ur:special-next-hop? 784 | +--:(next-hop-address) 785 | +--rw v4ur:next-hop-address? 786 +--rw v6ur:ipv6 787 +--rw v6ur:route* [destination-prefix] 788 +--rw v6ur:destination-prefix 789 +--rw v6ur:description? 790 +--rw v6ur:next-hop 791 +--rw (simple-or-list)? 792 +--:(multipath-entry) 793 | +--rw v6ur:multipath-entry* [name] 794 | +--rw v6ur:name 795 | +--rw (next-hop-options) 796 | | +--:(simple-next-hop) 797 | | | +--rw v6ur:outgoing-interface? 798 | | +--:(special-next-hop) 799 | | | +--rw v6ur:special-next-hop? 800 | | +--:(next-hop-address) 801 | | +--rw v6ur:next-hop-address? 802 | +--rw v6ur:priority? 803 | +--rw v6ur:weight? 804 +--:(simple-next-hop) 805 +--rw (next-hop-options) 806 +--:(simple-next-hop) 807 | +--rw v6ur:outgoing-interface? 808 +--:(special-next-hop) 809 | +--rw v6ur:special-next-hop? 810 +--:(next-hop-address) 811 +--rw v6ur:next-hop-address? 813 Figure 4: Structure of "static-routes" subtree. 815 A next-hop in static routes may be configured as a simple next-hop 816 (IP address, outgoing interface or both), special next-hop or a list 817 of multi-path next-hop entries that is used either for backup routes 818 of for equal-cost multi-path (ECMP) routing. The last option is 819 available only on devices that advertise the feature "rt:multipath- 820 routes". Moreover, unlike next-hop lists in state data, a list of 821 next-hop entries in a static route cannot be recursive, i.e., each 822 entry of that list can only be a simple or special next-hop. 824 5.4.2. Defining New Routing Protocols 826 It is expected that future YANG modules will create data models for 827 additional routing protocol types. Such a new module has to define 828 the protocol-specific configuration and state data, and it has to fit 829 it into the core routing framework in the following way: 831 o A new identity MUST be defined for the routing protocol and its 832 base identity MUST be set to "rt:routing-protocol", or to an 833 identity derived from "rt:routing-protocol". 835 o Additional route attributes MAY be defined, preferably in one 836 place by means of defining a YANG grouping. The new attributes 837 have to be inserted by augmenting the definitions of the nodes 839 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 841 and 843 /rt:fib-route/rt:output/rt:route, 845 and possibly other places in the configuration, state data and RPC 846 input or output. 848 o Configuration parameters and/or state data for the new protocol 849 can be defined by augmenting the "routing-protocol" data node 850 under both "/routing" and "/routing-state". 852 o Per-interface configuration, including activation of the routing 853 protocol on individual interfaces, can use references to entries 854 in the list of routing instance interfaces (rt:interface). 856 By using the "when" statement, the augmented configuration parameters 857 and state data specific to the new protocol SHOULD be made 858 conditional and valid only if the value of "rt:type" or "rt:source- 859 protocol" is equal to the new protocol's identity. It is also 860 RECOMMENDED that protocol-specific data nodes be encapsulated in 861 appropriately named containers. 863 The above steps are implemented by the example YANG module for the 864 RIP routing protocol in Appendix C. 866 5.5. Route Filter 868 The core routing data model provides a skeleton for defining route 869 filters that can be used to restrict the set of routes being 870 exchanged between a routing protocol instance and a connected RIB, or 871 between a source and a recipient RIB. Route filters may also 872 manipulate routes, i.e., add, delete, or modify their attributes. 874 Route filters are global, which means that a configured route filter 875 may be used by any or all routing instances. However, a data model 876 for a routing instance type MAY specify rules and restrictions for 877 sharing route filters among routing instances of that type. 879 The core routing data model defines only two extreme route filtering 880 policies which are represented by the following pre-defined route 881 filter types: 883 o "deny-all-route-filter": all routes are blocked, 885 o "allow-all-route-filter": all routes are permitted. 887 The latter type is equivalent to no route filter. 889 It is expected that more comprehensive route filtering frameworks 890 will be developed separately. 892 Each route filter entry is identified by a unique name. Its type 893 MUST be specified by the "type" identity reference. 895 5.6. RPC Operations 897 The "ietf-routing" module defines two RPC operations: 899 o fib-route: query a routing instance for the active route in the 900 Forwarding Information Base (FIB). It is the route that is 901 currently used for sending datagrams to a destination host whose 902 address is passed as an input parameter. 904 o route-count: retrieve the total number of entries in a RIB. 906 6. Interactions with Other YANG Modules 908 The semantics of the core routing data model also depends on several 909 configuration parameters that are defined in other YANG modules. 911 6.1. Module "ietf-interfaces" 913 The following boolean switch is defined in the "ietf-interfaces" YANG 914 module [RFC7223]: 916 /if:interfaces/if:interface/if:enabled 918 If this switch is set to "false" for a network layer interface, 919 the device MUST behave exactly as if that interface was not 920 assigned to any routing instance at all. 922 6.2. Module "ietf-ip" 924 The following boolean switches are defined in the "ietf-ip" YANG 925 module [RFC7277]: 927 /if:interfaces/if:interface/ip:ipv4/ip:enabled 929 If this switch is set to "false" for a network layer interface, 930 then all IPv4 routing functions related to that interface MUST be 931 disabled. 933 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 935 If this switch is set to "false" for a network layer interface, 936 then the forwarding of IPv4 datagrams to and from this interface 937 MUST be disabled. However, the interface may participate in other 938 IPv4 routing functions, such as routing protocols. 940 /if:interfaces/if:interface/ip:ipv6/ip:enabled 941 If this switch is set to "false" for a network layer interface, 942 then all IPv6 routing functions related to that interface MUST be 943 disabled. 945 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 947 If this switch is set to "false" for a network layer interface, 948 then the forwarding of IPv6 datagrams to and from this interface 949 MUST be disabled. However, the interface may participate in other 950 IPv6 routing functions, such as routing protocols. 952 In addition, the "ietf-ip" module allows for configuring IPv4 and 953 IPv6 addresses and network prefixes or masks on network layer 954 interfaces. Configuration of these parameters on an enabled 955 interface MUST result in an immediate creation of the corresponding 956 direct route. The destination prefix of this route is set according 957 to the configured IP address and network prefix/mask, and the 958 interface is set as the outgoing interface for that route. 960 7. Routing Management YANG Module 962 RFC Editor: In this section, replace all occurrences of 'XXXX' with 963 the actual RFC number and all occurrences of the revision date below 964 with the date of RFC publication (and remove this note). 966 file "routing@2014-10-26.yang" 968 module ietf-routing { 970 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 972 prefix "rt"; 974 import ietf-yang-types { 975 prefix "yang"; 976 } 978 import ietf-interfaces { 979 prefix "if"; 980 } 982 organization 983 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 985 contact 986 "WG Web: 987 WG List: 988 WG Chair: Thomas Nadeau 989 991 WG Chair: Juergen Schoenwaelder 992 994 Editor: Ladislav Lhotka 995 "; 997 description 998 "This YANG module defines essential components for the management 999 of a routing subsystem. 1001 Copyright (c) 2014 IETF Trust and the persons identified as 1002 authors of the code. All rights reserved. 1004 Redistribution and use in source and binary forms, with or 1005 without modification, is permitted pursuant to, and subject to 1006 the license terms contained in, the Simplified BSD License set 1007 forth in Section 4.c of the IETF Trust's Legal Provisions 1008 Relating to IETF Documents 1009 (http://trustee.ietf.org/license-info). 1011 This version of this YANG module is part of RFC XXXX; see the 1012 RFC itself for full legal notices."; 1014 revision 2014-10-26 { 1015 description 1016 "Initial revision."; 1017 reference 1018 "RFC XXXX: A YANG Data Model for Routing Management"; 1019 } 1021 /* Features */ 1023 feature multiple-ribs { 1024 description 1025 "This feature indicates that the server supports user-defined 1026 RIBS and the framework for passing routes between RIBs. 1028 Servers that do not advertize this feature MUST provide 1029 exactly one system-controlled RIB per supported address family 1030 and make them also the default RIBs. These RIBs then appear as 1031 entries of the list /routing-state/ribs/rib."; 1032 } 1034 feature multipath-routes { 1035 description 1036 "This feature indicates that the server supports multipath 1037 routes that have a list of next-hops."; 1038 } 1040 feature router-id { 1041 description 1042 "This feature indicates that the server supports configuration 1043 of an explicit 32-bit router ID that is used by some routing 1044 protocols. 1046 Servers that do not advertize this feature set a router ID 1047 algorithmically, usually to one of configured IPv4 addresses. 1048 However, this algorithm is implementation-specific."; 1049 } 1051 /* Identities */ 1053 identity address-family { 1054 description 1055 "Base identity from which identities describing address 1056 families are derived."; 1057 } 1059 identity ipv4 { 1060 base address-family; 1061 description 1062 "This identity represents IPv4 address family."; 1063 } 1065 identity ipv6 { 1066 base address-family; 1067 description 1068 "This identity represents IPv6 address family."; 1069 } 1071 identity routing-instance { 1072 description 1073 "Base identity from which identities describing routing 1074 instance types are derived."; 1075 } 1077 identity default-routing-instance { 1078 base routing-instance; 1079 description 1080 "This identity represents either a default routing instance, or 1081 the only routing instance on systems that do not support 1082 multiple instances."; 1083 } 1084 identity routing-protocol { 1085 description 1086 "Base identity from which routing protocol identities are 1087 derived."; 1088 } 1090 identity direct { 1091 base routing-protocol; 1092 description 1093 "Routing pseudo-protocol which provides routes to directly 1094 connected networks."; 1095 } 1097 identity static { 1098 base routing-protocol; 1099 description 1100 "Static routing pseudo-protocol."; 1101 } 1103 identity route-filter { 1104 description 1105 "Base identity from which all route filters are derived."; 1106 } 1108 identity deny-all-route-filter { 1109 base route-filter; 1110 description 1111 "Route filter that blocks all routes."; 1112 } 1114 identity allow-all-route-filter { 1115 base route-filter; 1116 description 1117 "Route filter that permits all routes."; 1118 } 1120 /* Type Definitions */ 1122 typedef routing-instance-ref { 1123 type leafref { 1124 path "/rt:routing/rt:routing-instance/rt:name"; 1125 } 1126 description 1127 "This type is used for leafs that reference a routing instance 1128 configuration."; 1129 } 1131 typedef routing-instance-state-ref { 1132 type leafref { 1133 path "/rt:routing-state/rt:routing-instance/rt:name"; 1134 } 1135 description 1136 "This type is used for leafs that reference state data of a 1137 routing instance."; 1138 } 1140 typedef rib-ref { 1141 type leafref { 1142 path "/rt:routing/rt:ribs/rt:rib/rt:name"; 1143 } 1144 description 1145 "This type is used for leafs that reference a RIB 1146 configuration."; 1147 } 1149 typedef rib-state-ref { 1150 type leafref { 1151 path "/rt:routing-state/rt:ribs/rt:rib/rt:name"; 1152 } 1153 description 1154 "This type is used for leafs that reference a RIB in state 1155 data."; 1156 } 1158 typedef next-hop-list-ref { 1159 type leafref { 1160 path "/rt:routing-state/rt:next-hop-lists/rt:next-hop-list/" 1161 + "rt:id"; 1162 } 1163 description 1164 "This type is used for leafs that reference a next-hop list (in 1165 state data)."; 1166 } 1168 typedef route-filter-ref { 1169 type leafref { 1170 path "/rt:routing/rt:route-filters/rt:route-filter/rt:name"; 1171 } 1172 description 1173 "This type is used for leafs that reference a route filter 1174 configuration."; 1175 } 1177 typedef route-filter-state-ref { 1178 type leafref { 1179 path "/rt:routing-state/rt:route-filters/rt:route-filter/" 1180 + "rt:name"; 1181 } 1182 description 1183 "This type is used for leafs that reference state data of a 1184 route filter."; 1185 } 1187 typedef route-preference { 1188 type uint32; 1189 description 1190 "This type is used for route preferences."; 1191 } 1193 /* Groupings */ 1195 grouping address-family { 1196 description 1197 "This grouping provides a leaf identifying an address 1198 family."; 1199 leaf address-family { 1200 type identityref { 1201 base address-family; 1202 } 1203 mandatory "true"; 1204 description 1205 "Address family."; 1206 } 1207 } 1209 grouping state-entry-id { 1210 description 1211 "This grouping provides a unique identifier for entries in 1212 several operational state lists."; 1213 leaf id { 1214 type uint64; 1215 description 1216 "Unique numerical identifier of a list entry in operational 1217 state. It may be used by protocols or tools that inspect 1218 and/or manipulate operational state data and prefer 1219 fixed-size integers as list entry handles. 1221 These identifiers are always ephemeral, i.e., they may 1222 change after a reboot."; 1223 } 1224 } 1226 grouping router-id { 1227 description 1228 "This grouping provides router ID."; 1229 leaf router-id { 1230 type yang:dotted-quad; 1231 description 1232 "A 32-bit number in the form of a dotted quad that is used by 1233 some routing protocols identifying a router."; 1234 reference 1235 "RFC 2328: OSPF Version 2."; 1236 } 1237 } 1239 grouping next-hop-classifiers { 1240 description 1241 "This grouping provides two next-hop classifiers."; 1242 leaf priority { 1243 type enumeration { 1244 enum primary { 1245 value "1"; 1246 description 1247 "Primary next-hop."; 1248 } 1249 enum backup { 1250 value "2"; 1251 description 1252 "Backup next-hop."; 1253 } 1254 } 1255 description 1256 "Simple priority for distinguishing between primary and 1257 backup next-hops. 1259 Backup next-hops are used if and only if no primary 1260 next-hops are reachable."; 1261 } 1262 leaf weight { 1263 type uint8; 1264 must ". = 0 or not(../../next-hop/weight = 0)" { 1265 error-message "Illegal combination of zero and non-zero " 1266 + "next-hop weights."; 1267 description 1268 "Next-hop weights must be either all zero (equal 1269 load-balancing) or all non-zero."; 1270 } 1271 description 1272 "This parameter specifies the weight of the next-hop for load 1273 balancing. The number specifies the relative fraction of the 1274 traffic that will use the corresponding next-hop. 1276 A value of 0 represents equal load-balancing. 1278 If both primary and backup next-hops are present, then the 1279 weights for each priority level are used separately."; 1280 } 1281 } 1283 grouping special-next-hop { 1284 description 1285 "This grouping provides a leaf with enumeration of special 1286 next-hops."; 1287 leaf special-next-hop { 1288 type enumeration { 1289 enum blackhole { 1290 description 1291 "Silently discard the packet."; 1292 } 1293 enum unreachable { 1294 description 1295 "Discard the packet and notify the sender with an error 1296 message indicating that the destination host is 1297 unreachable."; 1298 } 1299 enum prohibit { 1300 description 1301 "Discard the packet and notify the sender with an error 1302 message indicating that the communication is 1303 administratively prohibited."; 1304 } 1305 enum receive { 1306 description 1307 "The packet will be received by the local system."; 1308 } 1309 } 1310 description 1311 "Special next-hop options."; 1312 } 1313 } 1315 grouping next-hop-content { 1316 description 1317 "Generic parameters of next-hops in static routes."; 1318 choice next-hop-options { 1319 mandatory "true"; 1320 description 1321 "Options for next-hops in static routes."; 1322 case simple-next-hop { 1323 description 1324 "Simple next-hop is specified as an outgoing interface, 1325 next-hop address or both. 1327 Address-family-specific modules are expected to provide 1328 'next-hop-address' leaf via augmentation."; 1329 leaf outgoing-interface { 1330 type leafref { 1331 path "/rt:routing/rt:routing-instance/rt:interfaces/" 1332 + "rt:interface/rt:name"; 1333 } 1334 description 1335 "Name of the outgoing interface."; 1336 } 1337 } 1338 case special-next-hop { 1339 uses special-next-hop; 1340 } 1341 } 1342 } 1344 grouping next-hop-state-content { 1345 description 1346 "Generic parameters of next-hops in state data."; 1347 choice next-hop-options { 1348 mandatory "true"; 1349 description 1350 "Options for next-hops in state data."; 1351 leaf next-hop-list { 1352 type next-hop-list-ref; 1353 description 1354 "Reference to a next-hop list."; 1355 } 1356 leaf use-rib { 1357 type rib-state-ref; 1358 description 1359 "Reference to a RIB in which a new look-up is to be 1360 performed."; 1361 } 1362 case simple-next-hop { 1363 description 1364 "Simple next-hop is specified as an outgoing interface, 1365 next-hop address or both. 1367 Address-family-specific modules are expected to provide 1368 'next-hop-address' leaf via augmentation."; 1369 leaf outgoing-interface { 1370 type leafref { 1371 path "/rt:routing-state/rt:routing-instance/" 1372 + "rt:interfaces/rt:interface/rt:name"; 1373 } 1374 description 1375 "Name of the outgoing interface."; 1376 } 1377 } 1378 case special-next-hop { 1379 uses special-next-hop; 1380 } 1381 } 1382 } 1384 grouping route-metadata { 1385 description 1386 "Route metadata."; 1387 leaf source-protocol { 1388 type identityref { 1389 base routing-protocol; 1390 } 1391 mandatory "true"; 1392 description 1393 "Type of the routing protocol from which the route 1394 originated."; 1395 } 1396 leaf active { 1397 type empty; 1398 description 1399 "Presence of this leaf indicates that the route is preferred 1400 among all routes in the same RIB that have the same 1401 destination prefix."; 1402 } 1403 leaf last-updated { 1404 type yang:date-and-time; 1405 description 1406 "Time stamp of the last modification of the route. If the 1407 route was never modified, it is the time when the route was 1408 inserted into the RIB."; 1409 } 1410 } 1412 /* Operational state data */ 1414 container routing-state { 1415 config "false"; 1416 description 1417 "Operational state of the routing subsystem."; 1418 list routing-instance { 1419 key "name"; 1420 unique "id"; 1421 min-elements "1"; 1422 description 1423 "Each list entry is a container for operational state data of 1424 a routing instance. 1426 An implementation MAY create one or more system-controlled 1427 instances, other user-controlled instances MAY be created by 1428 configuration."; 1429 leaf name { 1430 type string; 1431 description 1432 "The name of the routing instance. 1434 For system-controlled instances the name is persistent, 1435 i.e., it SHOULD NOT change across reboots."; 1436 } 1437 uses state-entry-id { 1438 refine "id" { 1439 mandatory "true"; 1440 } 1441 } 1442 leaf type { 1443 type identityref { 1444 base routing-instance; 1445 } 1446 description 1447 "The routing instance type."; 1448 } 1449 container default-ribs { 1450 description 1451 "Default RIBs used by the routing instance."; 1452 list default-rib { 1453 key "address-family"; 1454 description 1455 "Each list entry specifies the default RIB for one 1456 address family. 1458 The default RIB is operationally connected to all 1459 routing protocols for which a connected RIB has not been 1460 explicitly configured. 1462 The 'direct' pseudo-protocol is always connected to the 1463 default RIBs."; 1464 uses address-family; 1465 leaf rib-name { 1466 type rib-state-ref; 1467 mandatory "true"; 1468 description 1469 "Name of an existing RIB to be used as the default RIB 1470 for the given routing instance and address family."; 1471 } 1472 } 1473 } 1474 container interfaces { 1475 description 1476 "Network layer interfaces belonging to the routing 1477 instance."; 1478 list interface { 1479 key "name"; 1480 description 1481 "List of network layer interfaces assigned to the routing 1482 instance."; 1483 leaf name { 1484 type if:interface-state-ref; 1485 description 1486 "A reference to the name of a configured network layer 1487 interface."; 1488 } 1489 } 1490 } 1491 container routing-protocols { 1492 description 1493 "Container for the list of routing protocol instances."; 1494 list routing-protocol { 1495 key "type name"; 1496 description 1497 "Operational state of a routing protocol instance. 1499 An implementation MUST provide exactly one 1500 system-controlled instance of the type 'direct'. Other 1501 instances MAY be created by configuration."; 1502 leaf type { 1503 type identityref { 1504 base routing-protocol; 1505 } 1506 description 1507 "Type of the routing protocol."; 1508 } 1509 leaf name { 1510 type string; 1511 description 1512 "The name of the routing protocol instance. 1514 For system-controlled instances this name is 1515 persistent, i.e., it SHOULD NOT change across 1516 reboots."; 1517 } 1518 leaf route-preference { 1519 type route-preference; 1520 mandatory "true"; 1521 description 1522 "The value of route preference (administrative 1523 distance) assigned to all routes generated by the 1524 routing protocol instance. A lower value means a more 1525 preferred route."; 1526 } 1527 container connected-ribs { 1528 description 1529 "Container for connected RIBs."; 1530 list connected-rib { 1531 key "rib-name"; 1532 description 1533 "List of RIBs to which the routing protocol instance 1534 is connected. 1536 By default, routes learned by the routing protocol 1537 instance are installed in all connected RIBs of the 1538 matching address family, and, conversely, all routes 1539 from connected RIBs are installed in the routing 1540 protocol instance. However, routing protocols may 1541 specify other rules."; 1542 leaf rib-name { 1543 type rib-state-ref; 1544 description 1545 "Name of an existing RIB."; 1546 } 1547 leaf import-filter { 1548 type route-filter-state-ref; 1549 description 1550 "Reference to a route filter that is used for 1551 filtering routes passed from this routing protocol 1552 instance to the RIB specified by the 'rib-name' 1553 sibling node. 1555 If this leaf is not present, the behavior is 1556 protocol-specific, but typically it means that all 1557 routes are accepted."; 1558 } 1559 leaf export-filter { 1560 type route-filter-state-ref; 1561 description 1562 "Reference to a route filter that is used for 1563 filtering routes passed from the RIB specified by 1564 the 'rib-name' sibling node to this routing 1565 protocol instance. 1567 If this leaf is not present, the behavior is 1568 protocol-specific - typically it means that all 1569 routes are accepted. 1571 The 'direct' and 'static' pseudo-protocols accept 1572 no routes from any RIB."; 1573 } 1574 } 1575 } 1576 } 1577 } 1578 } 1579 container next-hop-lists { 1580 description 1581 "Container for next-hop lists."; 1582 list next-hop-list { 1583 key "id"; 1584 description 1585 "Next-hop list."; 1586 uses state-entry-id; 1587 uses address-family; 1588 list next-hop { 1589 description 1590 "Entry in a next-hop list."; 1591 uses next-hop-state-content; 1592 uses next-hop-classifiers; 1593 } 1594 } 1595 } 1596 container ribs { 1597 description 1598 "Container for RIBs."; 1599 list rib { 1600 key "name"; 1601 unique "id"; 1602 description 1603 "Each entry represents a RIB identified by the 'name' key. 1604 All routes in a RIB MUST belong to the same address 1605 family. 1607 The server MUST provide a system-controlled default RIB 1608 for each address family, and MAY provide other 1609 system-controlled RIBs. Additional RIBs MAY be created in 1610 the configuration."; 1611 leaf name { 1612 type string; 1613 description 1614 "The name of the RIB."; 1615 } 1616 uses state-entry-id { 1617 refine "id" { 1618 mandatory "true"; 1619 } 1620 } 1621 uses address-family; 1622 container routes { 1623 description 1624 "Current content of the RIB."; 1625 list route { 1626 description 1627 "A RIB route entry. This data node MUST be augmented 1628 with information specific for routes of each address 1629 family."; 1630 leaf route-preference { 1631 type route-preference; 1632 description 1633 "This route attribute, also known as administrative 1634 distance, allows for selecting the preferred route 1635 among routes with the same destination prefix. A 1636 smaller value means a more preferred route."; 1637 } 1638 container next-hop { 1639 description 1640 "Route's next-hop attribute."; 1641 uses next-hop-state-content; 1642 } 1643 uses route-metadata; 1644 } 1645 } 1646 container recipient-ribs { 1647 description 1648 "Container for recipient RIBs."; 1649 list recipient-rib { 1650 key "rib-name"; 1651 description 1652 "List of RIBs that receive routes from this RIB."; 1653 leaf rib-name { 1654 type rib-state-ref; 1655 description 1656 "The name of the recipient RIB."; 1657 } 1658 leaf filter { 1659 type route-filter-state-ref; 1660 description 1661 "A route filter which is applied to the routes passed 1662 to the recipient RIB."; 1663 } 1664 } 1665 } 1666 } 1667 } 1668 container route-filters { 1669 description 1670 "Container for route filters."; 1671 list route-filter { 1672 key "name"; 1673 description 1674 "Route filters are used for filtering and/or manipulating 1675 routes that are passed between a routing protocol and a 1676 RIB and vice versa, or between two RIBs. 1678 It is expected that other modules augment this list with 1679 contents specific for a particular route filter type."; 1680 leaf name { 1681 type string; 1682 description 1683 "The name of the route filter."; 1684 } 1685 leaf type { 1686 type identityref { 1687 base route-filter; 1688 } 1689 mandatory "true"; 1690 description 1691 "Type of the route-filter - an identity derived from the 1692 'route-filter' base identity."; 1693 } 1694 } 1695 } 1696 } 1698 /* Configuration Data */ 1700 container routing { 1701 description 1702 "Configuration parameters for the routing subsystem."; 1703 list routing-instance { 1704 key "name"; 1705 description 1706 "Configuration of a routing instance."; 1707 leaf name { 1708 type string; 1709 description 1710 "The name of the routing instance. 1712 For system-controlled entries, the value of this leaf must 1713 be the same as the name of the corresponding entry in 1714 state data. 1716 For user-controlled entries, an arbitrary name can be 1717 used."; 1718 } 1719 leaf type { 1720 type identityref { 1721 base routing-instance; 1722 } 1723 default "rt:default-routing-instance"; 1724 description 1725 "The type of the routing instance."; 1726 } 1727 leaf enabled { 1728 type boolean; 1729 default "true"; 1730 description 1731 "Enable/disable the routing instance. 1733 If this parameter is false, the parent routing instance is 1734 disabled and does not appear in operational state data, 1735 despite any other configuration that might be present."; 1736 } 1737 uses router-id { 1738 if-feature router-id; 1739 description 1740 "Configuration of the global router ID. Routing protocols 1741 that use router ID can use this parameter or override it 1742 with another value."; 1743 } 1744 leaf description { 1745 type string; 1746 description 1747 "Textual description of the routing instance."; 1748 } 1749 container default-ribs { 1750 if-feature multiple-ribs; 1751 description 1752 "Configuration of the default RIBs used by the routing 1753 instance. 1755 The default RIB for an addressed family if by default 1756 connected to all routing protocol instances supporting 1757 that address family, and always receives direct routes."; 1758 list default-rib { 1759 must "address-family=/routing/ribs/rib[name=current()/" 1760 + "rib-name]/address-family" { 1761 error-message "Address family mismatch."; 1762 description 1763 "The entry's address family MUST match that of the 1764 referenced RIB."; 1765 } 1766 key "address-family"; 1767 description 1768 "Each list entry configures the default RIB for one 1769 address family."; 1770 uses address-family; 1771 leaf rib-name { 1772 type string; 1773 mandatory "true"; 1774 description 1775 "Name of an existing RIB to be used as the default RIB 1776 for the given routing instance and address family."; 1777 } 1778 } 1779 } 1780 container interfaces { 1781 description 1782 "Configuration of the routing instance's interfaces."; 1783 list interface { 1784 key "name"; 1785 description 1786 "List of network layer interfaces assigned to the routing 1787 instance."; 1788 leaf name { 1789 type if:interface-ref; 1790 description 1791 "A reference to the name of a configured network layer 1792 interface."; 1793 } 1794 } 1795 } 1796 container routing-protocols { 1797 description 1798 "Configuration of routing protocol instances."; 1799 list routing-protocol { 1800 key "type name"; 1801 description 1802 "Each entry contains configuration of a routing protocol 1803 instance."; 1805 leaf type { 1806 type identityref { 1807 base routing-protocol; 1808 } 1809 description 1810 "Type of the routing protocol - an identity derived 1811 from the 'routing-protocol' base identity."; 1812 } 1813 leaf name { 1814 type string; 1815 description 1816 "An arbitrary name of the routing protocol instance."; 1817 } 1818 leaf description { 1819 type string; 1820 description 1821 "Textual description of the routing protocol 1822 instance."; 1823 } 1824 leaf enabled { 1825 type boolean; 1826 default "true"; 1827 description 1828 "Enable/disable the routing protocol instance. 1830 If this parameter is false, the parent routing 1831 protocol instance is disabled and does not appear in 1832 operational state data, despite any other 1833 configuration that might be present."; 1834 } 1835 leaf route-preference { 1836 type route-preference; 1837 description 1838 "The value of route preference (administrative 1839 distance). 1841 The default value depends on the routing protocol 1842 type, and may also be implementation-dependent."; 1843 } 1844 container connected-ribs { 1845 description 1846 "Configuration of connected RIBs."; 1847 list connected-rib { 1848 key "rib-name"; 1849 description 1850 "Each entry configures a RIB to which the routing 1851 protocol instance is connected. 1853 If no connected RIB is configured for an address 1854 family, the routing protocol is connected to the 1855 default RIB for that address family."; 1856 leaf rib-name { 1857 type rib-ref; 1858 must "../../../type != 'rt:direct' or " 1859 + "../../../../../default-ribs/ " 1860 + "default-rib/rib-name=." { 1861 error-message "The 'direct' protocol can be " 1862 + "connected only to a default RIB."; 1863 description 1864 "For the 'direct' pseudo-protocol, the connected 1865 RIB must always be a default RIB."; 1866 } 1867 description 1868 "Name of an existing RIB."; 1869 } 1870 leaf import-filter { 1871 type route-filter-ref; 1872 description 1873 "Configuration of import filter."; 1874 } 1875 leaf export-filter { 1876 type route-filter-ref; 1877 description 1878 "Configuration of export filter."; 1879 } 1880 } 1881 } 1882 container static-routes { 1883 when "../type='rt:static'" { 1884 description 1885 "This container is only valid for the 'static' 1886 routing protocol."; 1887 } 1888 description 1889 "Configuration of the 'static' pseudo-protocol. 1891 Address-family-specific modules augment this node with 1892 their lists of routes."; 1893 } 1894 } 1895 } 1896 } 1897 container ribs { 1898 description 1899 "Configuration of RIBs."; 1900 list rib { 1901 key "name"; 1902 description 1903 "Each entry represents a configured RIB identified by the 1904 'name' key. 1906 Entries having the same key as a system-controlled entry 1907 of the list /routing-state/ribs/rib are used for 1908 configuring parameters of that entry. Other entries define 1909 additional user-controlled RIBs."; 1910 leaf name { 1911 type string; 1912 description 1913 "The name of the RIB. 1915 For system-controlled entries, the value of this leaf 1916 must be the same as the name of the corresponding entry 1917 in state data. 1919 For user-controlled entries, an arbitrary name can be 1920 used."; 1921 } 1922 uses address-family; 1923 leaf description { 1924 type string; 1925 description 1926 "Textual description of the RIB."; 1927 } 1928 container recipient-ribs { 1929 if-feature multiple-ribs; 1930 description 1931 "Configuration of recipient RIBs."; 1932 list recipient-rib { 1933 must "rib-name != ../../name" { 1934 error-message 1935 "Source and recipient RIBs are identical."; 1936 description 1937 "A RIB MUST NOT appear among its recipient RIBs."; 1938 } 1939 must "/routing/ribs/rib[name=current()/rib-name]/" 1940 + "address-family=../../address-family" { 1941 error-message "Address family mismatch."; 1942 description 1943 "Address family of the recipient RIB MUST match that 1944 of the source RIB."; 1945 } 1946 key "rib-name"; 1947 description 1948 "Each entry configures a recipient RIB."; 1950 leaf rib-name { 1951 type rib-ref; 1952 description 1953 "The name of the recipient RIB."; 1954 } 1955 leaf filter { 1956 type route-filter-ref; 1957 description 1958 "A route filter which is applied to the routes passed 1959 to the recipient RIB."; 1960 } 1961 } 1962 } 1963 } 1964 } 1965 container route-filters { 1966 description 1967 "Configuration of route filters."; 1968 list route-filter { 1969 key "name"; 1970 description 1971 "Each entry configures a named route filter."; 1972 leaf name { 1973 type string; 1974 description 1975 "The name of the route filter."; 1976 } 1977 leaf description { 1978 type string; 1979 description 1980 "Textual description of the route filter."; 1981 } 1982 leaf type { 1983 type identityref { 1984 base route-filter; 1985 } 1986 mandatory "true"; 1987 description 1988 "Type of the route filter.."; 1989 } 1990 } 1991 } 1992 } 1994 /* RPC methods */ 1996 rpc fib-route { 1997 description 1998 "Return the active FIB route that a routing-instance uses for 1999 sending packets to a destination address."; 2000 input { 2001 leaf routing-instance-name { 2002 type routing-instance-state-ref; 2003 mandatory "true"; 2004 description 2005 "Name of the routing instance whose forwarding information 2006 base is being queried. 2008 If the routing instance with name equal to the value of 2009 this parameter doesn't exist, then this operation SHALL 2010 fail with error-tag 'data-missing' and error-app-tag 2011 'routing-instance-not-found'."; 2012 } 2013 container destination-address { 2014 description 2015 "Network layer destination address. 2017 Address family specific modules MUST augment this 2018 container with a leaf named 'address'."; 2019 uses address-family; 2020 } 2021 } 2022 output { 2023 container route { 2024 description 2025 "The active route for the specified destination. 2027 If the routing instance has no active route for the 2028 destination address, no output is returned - the server 2029 SHALL send an containing a single element 2030 . 2032 Address family specific modules MUST augment this list 2033 with appropriate route contents."; 2034 uses address-family; 2035 container next-hop { 2036 description 2037 "Route's next-hop attribute."; 2038 uses next-hop-state-content; 2039 } 2040 uses route-metadata; 2041 } 2042 } 2043 } 2045 rpc route-count { 2046 description 2047 "Return the current number of routes in a RIB."; 2048 input { 2049 leaf rib-name { 2050 type rib-state-ref; 2051 mandatory "true"; 2052 description 2053 "Name of the RIB. 2055 If the RIB with name equal to the value of this parameter 2056 doesn't exist, then this operation SHALL fail with 2057 error-tag 'data-missing' and error-app-tag 2058 'rib-not-found'."; 2059 } 2060 } 2061 output { 2062 leaf number-of-routes { 2063 type uint64; 2064 mandatory "true"; 2065 description 2066 "Number of routes in the RIB."; 2067 } 2068 } 2069 } 2070 } 2072 2074 8. IPv4 Unicast Routing Management YANG Module 2076 RFC Editor: In this section, replace all occurrences of 'XXXX' with 2077 the actual RFC number and all occurrences of the revision date below 2078 with the date of RFC publication (and remove this note). 2080 file "ipv4-unicast-routing@2014-10-26.yang" 2082 module ietf-ipv4-unicast-routing { 2084 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 2086 prefix "v4ur"; 2088 import ietf-routing { 2089 prefix "rt"; 2090 } 2092 import ietf-inet-types { 2093 prefix "inet"; 2095 } 2097 organization 2098 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 2100 contact 2101 "WG Web: 2102 WG List: 2104 WG Chair: Thomas Nadeau 2105 2107 WG Chair: Juergen Schoenwaelder 2108 2110 Editor: Ladislav Lhotka 2111 "; 2113 description 2114 "This YANG module augments the 'ietf-routing' module with basic 2115 configuration and operational state data for IPv4 unicast 2116 routing. 2118 Copyright (c) 2014 IETF Trust and the persons identified as 2119 authors of the code. All rights reserved. 2121 Redistribution and use in source and binary forms, with or 2122 without modification, is permitted pursuant to, and subject to 2123 the license terms contained in, the Simplified BSD License set 2124 forth in Section 4.c of the IETF Trust's Legal Provisions 2125 Relating to IETF Documents 2126 (http://trustee.ietf.org/license-info). 2128 This version of this YANG module is part of RFC XXXX; see the 2129 RFC itself for full legal notices."; 2131 revision 2014-10-26 { 2132 description 2133 "Initial revision."; 2134 reference 2135 "RFC XXXX: A YANG Data Model for Routing Management"; 2136 } 2138 /* Identities */ 2140 identity ipv4-unicast { 2141 base rt:ipv4; 2142 description 2143 "This identity represents the IPv4 unicast address family."; 2144 } 2146 /* Operational state data */ 2148 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2149 when "../../rt:address-family = 'v4ur:ipv4-unicast'" { 2150 description 2151 "This augment is valid only for IPv4 unicast."; 2152 } 2153 description 2154 "This leaf augments an IPv4 unicast route."; 2155 leaf destination-prefix { 2156 type inet:ipv4-prefix; 2157 description 2158 "IPv4 destination prefix."; 2159 } 2160 } 2162 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 2163 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 2164 when "../../../rt:address-family = 'v4ur:ipv4-unicast'" { 2165 description 2166 "This augment is valid only for IPv4 unicast."; 2167 } 2168 description 2169 "This leaf augments the 'simple-next-hop' case of IPv4 unicast 2170 routes."; 2171 leaf next-hop-address { 2172 type inet:ipv4-address; 2173 description 2174 "IPv4 address of the next-hop."; 2175 } 2176 } 2178 augment "/rt:routing-state/rt:next-hop-lists/rt:next-hop-list/" 2179 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 2180 when "../rt:address-family = 'v4ur:ipv4-unicast'" { 2181 description 2182 "This augment is valid only for IPv4 unicast."; 2183 } 2184 description 2185 "This leaf augments next-hop list with IPv4 next-hop address. 2186 routes."; 2187 leaf next-hop-address { 2188 type inet:ipv4-address; 2189 description 2190 "IPv4 address of the next-hop."; 2192 } 2193 } 2195 /* Configuration data */ 2197 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2198 + "rt:routing-protocol/rt:static-routes" { 2199 description 2200 "This augment defines the configuration of the 'static' 2201 pseudo-protocol with data specific to IPv4 unicast."; 2202 container ipv4 { 2203 description 2204 "Configuration of a 'static' pseudo-protocol instance 2205 consists of a list of routes."; 2206 list route { 2207 key "destination-prefix"; 2208 ordered-by "user"; 2209 description 2210 "A user-ordered list of static routes."; 2211 leaf destination-prefix { 2212 type inet:ipv4-prefix; 2213 mandatory "true"; 2214 description 2215 "IPv4 destination prefix."; 2216 } 2217 leaf description { 2218 type string; 2219 description 2220 "Textual description of the route."; 2221 } 2222 container next-hop { 2223 description 2224 "Configuration of next-hop."; 2225 grouping next-hop-content { 2226 description 2227 "Next-hop content for IPv4 unicast static routes."; 2228 uses rt:next-hop-content { 2229 augment "next-hop-options" { 2230 description 2231 "Add next-hop address case."; 2232 leaf next-hop-address { 2233 type inet:ipv4-address; 2234 description 2235 "IPv4 address of the next-hop."; 2236 } 2237 } 2238 } 2239 } 2240 choice simple-or-list { 2241 description 2242 "Options for next-hops."; 2243 list multipath-entry { 2244 if-feature rt:multipath-routes; 2245 key "name"; 2246 description 2247 "List of alternative next-hops."; 2248 leaf name { 2249 type string; 2250 description 2251 "A unique identifier of the next-hop entry."; 2252 } 2253 uses next-hop-content; 2254 uses rt:next-hop-classifiers; 2255 } 2256 case simple-next-hop { 2257 uses next-hop-content; 2258 } 2259 } 2260 } 2261 } 2262 } 2263 } 2265 /* RPC methods */ 2267 augment "/rt:fib-route/rt:input/rt:destination-address" { 2268 when "rt:address-family='v4ur:ipv4-unicast'" { 2269 description 2270 "This augment is valid only for IPv4 unicast."; 2271 } 2272 description 2273 "This leaf augments the 'rt:destination-address' parameter of 2274 the 'rt:fib-route' operation."; 2275 leaf address { 2276 type inet:ipv4-address; 2277 description 2278 "IPv4 destination address."; 2279 } 2280 } 2282 augment "/rt:fib-route/rt:output/rt:route" { 2283 when "rt:address-family='v4ur:ipv4-unicast'" { 2284 description 2285 "This augment is valid only for IPv4 unicast."; 2286 } 2287 description 2288 "This leaf augments the reply to the 'rt:fib-route' 2289 operation."; 2290 leaf destination-prefix { 2291 type inet:ipv4-prefix; 2292 description 2293 "IPv4 destination prefix."; 2294 } 2295 } 2297 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 2298 + "rt:next-hop-options/rt:simple-next-hop" { 2299 when "../rt:address-family='v4ur:ipv4-unicast'" { 2300 description 2301 "This augment is valid only for IPv4 unicast."; 2302 } 2303 description 2304 "This leaf augments the 'simple-next-hop' case in the reply to 2305 the 'rt:fib-route' operation."; 2306 leaf next-hop-address { 2307 type inet:ipv4-address; 2308 description 2309 "IPv4 address of the next-hop."; 2310 } 2311 } 2312 } 2314 2316 9. IPv6 Unicast Routing Management YANG Module 2318 RFC Editor: In this section, replace all occurrences of 'XXXX' with 2319 the actual RFC number and all occurrences of the revision date below 2320 with the date of RFC publication (and remove this note). 2322 file "ipv6-unicast-routing@2014-10-26.yang" 2324 module ietf-ipv6-unicast-routing { 2326 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 2328 prefix "v6ur"; 2330 import ietf-routing { 2331 prefix "rt"; 2332 } 2334 import ietf-inet-types { 2335 prefix "inet"; 2337 } 2339 import ietf-interfaces { 2340 prefix "if"; 2341 } 2343 import ietf-ip { 2344 prefix "ip"; 2345 } 2347 organization 2348 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 2350 contact 2351 "WG Web: 2352 WG List: 2354 WG Chair: Thomas Nadeau 2355 2357 WG Chair: Juergen Schoenwaelder 2358 2360 Editor: Ladislav Lhotka 2361 "; 2363 description 2364 "This YANG module augments the 'ietf-routing' module with basic 2365 configuration and operational state data for IPv6 unicast 2366 routing. 2368 Copyright (c) 2014 IETF Trust and the persons identified as 2369 authors of the code. All rights reserved. 2371 Redistribution and use in source and binary forms, with or 2372 without modification, is permitted pursuant to, and subject to 2373 the license terms contained in, the Simplified BSD License set 2374 forth in Section 4.c of the IETF Trust's Legal Provisions 2375 Relating to IETF Documents 2376 (http://trustee.ietf.org/license-info). 2378 This version of this YANG module is part of RFC XXXX; see the 2379 RFC itself for full legal notices."; 2381 revision 2014-10-26 { 2382 description 2383 "Initial revision."; 2384 reference 2385 "RFC XXXX: A YANG Data Model for Routing Management"; 2386 } 2388 /* Identities */ 2390 identity ipv6-unicast { 2391 base rt:ipv6; 2392 description 2393 "This identity represents the IPv6 unicast address family."; 2394 } 2396 /* Operational state data */ 2398 augment "/rt:routing-state/rt:routing-instance/rt:interfaces/" 2399 + "rt:interface" { 2400 description 2401 "IPv6-specific parameters of router interfaces."; 2402 container ipv6-router-advertisements { 2403 description 2404 "Parameters of IPv6 Router Advertisements."; 2405 leaf send-advertisements { 2406 type boolean; 2407 description 2408 "A flag indicating whether or not the router sends periodic 2409 Router Advertisements and responds to Router 2410 Solicitations."; 2411 } 2412 leaf max-rtr-adv-interval { 2413 type uint16 { 2414 range "4..1800"; 2415 } 2416 units "seconds"; 2417 description 2418 "The maximum time allowed between sending unsolicited 2419 multicast Router Advertisements from the interface."; 2420 } 2421 leaf min-rtr-adv-interval { 2422 type uint16 { 2423 range "3..1350"; 2424 } 2425 units "seconds"; 2426 description 2427 "The minimum time allowed between sending unsolicited 2428 multicast Router Advertisements from the interface."; 2429 } 2430 leaf managed-flag { 2431 type boolean; 2432 description 2433 "The value that is placed in the 'Managed address 2434 configuration' flag field in the Router Advertisement."; 2435 } 2436 leaf other-config-flag { 2437 type boolean; 2438 description 2439 "The value that is placed in the 'Other configuration' flag 2440 field in the Router Advertisement."; 2441 } 2442 leaf link-mtu { 2443 type uint32; 2444 description 2445 "The value that is placed in MTU options sent by the 2446 router. A value of zero indicates that no MTU options are 2447 sent."; 2448 } 2449 leaf reachable-time { 2450 type uint32 { 2451 range "0..3600000"; 2452 } 2453 units "milliseconds"; 2454 description 2455 "The value that is placed in the Reachable Time field in 2456 the Router Advertisement messages sent by the router. A 2457 value of zero means unspecified (by this router)."; 2458 } 2459 leaf retrans-timer { 2460 type uint32; 2461 units "milliseconds"; 2462 description 2463 "The value that is placed in the Retrans Timer field in the 2464 Router Advertisement messages sent by the router. A value 2465 of zero means unspecified (by this router)."; 2466 } 2467 leaf cur-hop-limit { 2468 type uint8; 2469 description 2470 "The value that is placed in the Cur Hop Limit field in the 2471 Router Advertisement messages sent by the router. A value 2472 of zero means unspecified (by this router)."; 2473 } 2474 leaf default-lifetime { 2475 type uint16 { 2476 range "0..9000"; 2477 } 2478 units "seconds"; 2479 description 2480 "The value that is placed in the Router Lifetime field of 2481 Router Advertisements sent from the interface, in seconds. 2482 A value of zero indicates that the router is not to be 2483 used as a default router."; 2484 } 2485 container prefix-list { 2486 description 2487 "A list of prefixes that are placed in Prefix Information 2488 options in Router Advertisement messages sent from the 2489 interface. 2491 By default, these are all prefixes that the router 2492 advertises via routing protocols as being on-link for the 2493 interface from which the advertisement is sent."; 2494 list prefix { 2495 key "prefix-spec"; 2496 description 2497 "Advertised prefix entry and its parameters."; 2498 leaf prefix-spec { 2499 type inet:ipv6-prefix; 2500 description 2501 "IPv6 address prefix."; 2502 } 2503 leaf valid-lifetime { 2504 type uint32; 2505 units "seconds"; 2506 description 2507 "The value that is placed in the Valid Lifetime in the 2508 Prefix Information option. The designated value of all 2509 1's (0xffffffff) represents infinity."; 2510 } 2511 leaf on-link-flag { 2512 type boolean; 2513 description 2514 "The value that is placed in the on-link flag ('L-bit') 2515 field in the Prefix Information option."; 2516 } 2517 leaf preferred-lifetime { 2518 type uint32; 2519 units "seconds"; 2520 description 2521 "The value that is placed in the Preferred Lifetime in 2522 the Prefix Information option, in seconds. The 2523 designated value of all 1's (0xffffffff) represents 2524 infinity."; 2525 } 2526 leaf autonomous-flag { 2527 type boolean; 2528 description 2529 "The value that is placed in the Autonomous Flag field 2530 in the Prefix Information option."; 2531 } 2532 } 2533 } 2534 } 2535 } 2537 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2538 when "../../rt:address-family = 'v6ur:ipv6-unicast'" { 2539 description 2540 "This augment is valid only for IPv6 unicast."; 2541 } 2542 description 2543 "This leaf augments an IPv6 unicast route."; 2544 leaf destination-prefix { 2545 type inet:ipv6-prefix; 2546 description 2547 "IPv6 destination prefix."; 2548 } 2549 } 2551 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 2552 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 2553 when "../../../rt:address-family = 'v6ur:ipv6-unicast'" { 2554 description 2555 "This augment is valid only for IPv6 unicast."; 2556 } 2557 description 2558 "This leaf augments the 'simple-next-hop' case of IPv6 unicast 2559 routes."; 2560 leaf next-hop { 2561 type inet:ipv6-address; 2562 description 2563 "IPv6 address of the next-hop."; 2564 } 2565 } 2567 augment "/rt:routing-state/rt:next-hop-lists/rt:next-hop-list/" 2568 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 2569 when "../rt:address-family = 'v6ur:ipv6-unicast'" { 2570 description 2571 "This augment is valid only for IPv6 unicast."; 2572 } 2573 description 2574 "This leaf augments next-hop list with IPv6 next-hop address. 2575 routes."; 2576 leaf next-hop-address { 2577 type inet:ipv6-address; 2578 description 2579 "IPv6 address of the next-hop."; 2580 } 2581 } 2583 /* Configuration data */ 2585 augment 2586 "/rt:routing/rt:routing-instance/rt:interfaces/rt:interface" { 2587 when "/if:interfaces/if:interface[if:name=current()/rt:name]/" 2588 + "ip:ipv6/ip:enabled='true'" { 2589 description 2590 "This augment is only valid for router interfaces with 2591 enabled IPv6."; 2592 } 2593 description 2594 "Configuration of IPv6-specific parameters of router 2595 interfaces."; 2596 container ipv6-router-advertisements { 2597 description 2598 "Configuration of IPv6 Router Advertisements."; 2599 leaf send-advertisements { 2600 type boolean; 2601 default "false"; 2602 description 2603 "A flag indicating whether or not the router sends periodic 2604 Router Advertisements and responds to Router 2605 Solicitations."; 2606 reference 2607 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2608 AdvSendAdvertisements."; 2609 } 2610 leaf max-rtr-adv-interval { 2611 type uint16 { 2612 range "4..1800"; 2613 } 2614 units "seconds"; 2615 default "600"; 2616 description 2617 "The maximum time allowed between sending unsolicited 2618 multicast Router Advertisements from the interface."; 2619 reference 2620 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2621 MaxRtrAdvInterval."; 2622 } 2623 leaf min-rtr-adv-interval { 2624 type uint16 { 2625 range "3..1350"; 2626 } 2627 units "seconds"; 2628 must ". <= 0.75 * ../max-rtr-adv-interval" { 2629 description 2630 "The value MUST NOT be greater than 75 % of 2631 'max-rtr-adv-interval'."; 2632 } 2633 description 2634 "The minimum time allowed between sending unsolicited 2635 multicast Router Advertisements from the interface. 2637 The default value to be used operationally if this leaf is 2638 not configured is determined as follows: 2640 - if max-rtr-adv-interval >= 9 seconds, the default value 2641 is 0.33 * max-rtr-adv-interval; 2643 - otherwise it is 0.75 * max-rtr-adv-interval."; 2644 reference 2645 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2646 MinRtrAdvInterval."; 2647 } 2648 leaf managed-flag { 2649 type boolean; 2650 default "false"; 2651 description 2652 "The value to be placed in the 'Managed address 2653 configuration' flag field in the Router Advertisement."; 2654 reference 2655 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2656 AdvManagedFlag."; 2657 } 2658 leaf other-config-flag { 2659 type boolean; 2660 default "false"; 2661 description 2662 "The value to be placed in the 'Other configuration' flag 2663 field in the Router Advertisement."; 2664 reference 2665 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2666 AdvOtherConfigFlag."; 2667 } 2668 leaf link-mtu { 2669 type uint32; 2670 default "0"; 2671 description 2672 "The value to be placed in MTU options sent by the router. 2674 A value of zero indicates that no MTU options are sent."; 2675 reference 2676 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2677 AdvLinkMTU."; 2678 } 2679 leaf reachable-time { 2680 type uint32 { 2681 range "0..3600000"; 2682 } 2683 units "milliseconds"; 2684 default "0"; 2685 description 2686 "The value to be placed in the Reachable Time field in the 2687 Router Advertisement messages sent by the router. A value 2688 of zero means unspecified (by this router)."; 2689 reference 2690 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2691 AdvReachableTime."; 2692 } 2693 leaf retrans-timer { 2694 type uint32; 2695 units "milliseconds"; 2696 default "0"; 2697 description 2698 "The value to be placed in the Retrans Timer field in the 2699 Router Advertisement messages sent by the router. A value 2700 of zero means unspecified (by this router)."; 2701 reference 2702 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2703 AdvRetransTimer."; 2704 } 2705 leaf cur-hop-limit { 2706 type uint8; 2707 description 2708 "The value to be placed in the Cur Hop Limit field in the 2709 Router Advertisement messages sent by the router. A value 2710 of zero means unspecified (by this router). 2712 If this parameter is not configured, the device SHOULD use 2713 the value specified in IANA Assigned Numbers that was in 2714 effect at the time of implementation."; 2715 reference 2716 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2717 AdvCurHopLimit. 2719 IANA: IP Parameters, 2720 http://www.iana.org/assignments/ip-parameters"; 2721 } 2722 leaf default-lifetime { 2723 type uint16 { 2724 range "0..9000"; 2725 } 2726 units "seconds"; 2727 description 2728 "The value to be placed in the Router Lifetime field of 2729 Router Advertisements sent from the interface, in seconds. 2730 It MUST be either zero or between max-rtr-adv-interval and 2731 9000 seconds. A value of zero indicates that the router is 2732 not to be used as a default router. These limits may be 2733 overridden by specific documents that describe how IPv6 2734 operates over different link layers. 2736 If this parameter is not configured, the device SHOULD use 2737 a value of 3 * max-rtr-adv-interval."; 2738 reference 2739 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2740 AdvDefaultLifeTime."; 2741 } 2742 container prefix-list { 2743 description 2744 "Configuration of prefixes to be placed in Prefix 2745 Information options in Router Advertisement messages sent 2746 from the interface. 2748 Prefixes that are advertised by default but do not have 2749 their entries in the child 'prefix' list are advertised 2750 with the default values of all parameters. 2752 The link-local prefix SHOULD NOT be included in the list 2753 of advertised prefixes."; 2754 reference 2755 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2756 AdvPrefixList."; 2757 list prefix { 2758 key "prefix-spec"; 2759 description 2760 "Configuration of an advertised prefix entry."; 2761 leaf prefix-spec { 2762 type inet:ipv6-prefix; 2763 description 2764 "IPv6 address prefix."; 2765 } 2766 choice control-adv-prefixes { 2767 default "advertise"; 2768 description 2769 "The prefix either may be explicitly removed from the 2770 set of advertised prefixes, or parameters with which 2771 it is advertised may be specified (default case)."; 2772 leaf no-advertise { 2773 type empty; 2774 description 2775 "The prefix will not be advertised. 2777 This can be used for removing the prefix from the 2778 default set of advertised prefixes."; 2779 } 2780 case advertise { 2781 leaf valid-lifetime { 2782 type uint32; 2783 units "seconds"; 2784 default "2592000"; 2785 description 2786 "The value to be placed in the Valid Lifetime in 2787 the Prefix Information option. The designated 2788 value of all 1's (0xffffffff) represents 2789 infinity."; 2790 reference 2791 "RFC 4861: Neighbor Discovery for IP version 6 2792 (IPv6) - AdvValidLifetime."; 2793 } 2794 leaf on-link-flag { 2795 type boolean; 2796 default "true"; 2797 description 2798 "The value to be placed in the on-link flag 2799 ('L-bit') field in the Prefix Information 2800 option."; 2801 reference 2802 "RFC 4861: Neighbor Discovery for IP version 6 2803 (IPv6) - AdvOnLinkFlag."; 2804 } 2805 leaf preferred-lifetime { 2806 type uint32; 2807 units "seconds"; 2808 must ". <= ../valid-lifetime" { 2809 description 2810 "This value MUST NOT be greater than 2811 valid-lifetime."; 2812 } 2813 default "604800"; 2814 description 2815 "The value to be placed in the Preferred Lifetime 2816 in the Prefix Information option. The designated 2817 value of all 1's (0xffffffff) represents 2818 infinity."; 2819 reference 2820 "RFC 4861: Neighbor Discovery for IP version 6 2821 (IPv6) - AdvPreferredLifetime."; 2822 } 2823 leaf autonomous-flag { 2824 type boolean; 2825 default "true"; 2826 description 2827 "The value to be placed in the Autonomous Flag 2828 field in the Prefix Information option."; 2829 reference 2830 "RFC 4861: Neighbor Discovery for IP version 6 2831 (IPv6) - AdvAutonomousFlag."; 2832 } 2833 } 2834 } 2835 } 2836 } 2837 } 2838 } 2840 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2841 + "rt:routing-protocol/rt:static-routes" { 2842 description 2843 "This augment defines the configuration of the 'static' 2844 pseudo-protocol with data specific to IPv6 unicast."; 2845 container ipv6 { 2846 description 2847 "Configuration of a 'static' pseudo-protocol instance 2848 consists of a list of routes."; 2849 list route { 2850 key "destination-prefix"; 2851 ordered-by "user"; 2852 description 2853 "A user-ordered list of static routes."; 2854 leaf destination-prefix { 2855 type inet:ipv6-prefix; 2856 mandatory "true"; 2857 description 2858 "IPv6 destination prefix."; 2859 } 2860 leaf description { 2861 type string; 2862 description 2863 "Textual description of the route."; 2864 } 2865 container next-hop { 2866 description 2867 "Configuration of next-hop."; 2868 grouping next-hop-content { 2869 description 2870 "Next-hop content for IPv6 unicast static routes."; 2871 uses rt:next-hop-content { 2872 augment "next-hop-options" { 2873 description 2874 "Add next-hop address case."; 2875 leaf next-hop-address { 2876 type inet:ipv6-address; 2877 description 2878 "IPv6 address of the next-hop."; 2879 } 2880 } 2881 } 2882 } 2883 choice simple-or-list { 2884 description 2885 "Options for next-hops."; 2886 list multipath-entry { 2887 if-feature rt:multipath-routes; 2888 key "name"; 2889 description 2890 "List of alternative next-hops."; 2891 leaf name { 2892 type string; 2893 description 2894 "A unique identifier of the next-hop entry."; 2895 } 2896 uses next-hop-content; 2897 uses rt:next-hop-classifiers; 2898 } 2899 case simple-next-hop { 2900 uses next-hop-content; 2901 } 2902 } 2903 } 2904 } 2905 } 2906 } 2908 /* RPC methods */ 2910 augment "/rt:fib-route/rt:input/rt:destination-address" { 2911 when "rt:address-family='v6ur:ipv6-unicast'" { 2912 description 2913 "This augment is valid only for IPv6 unicast."; 2915 } 2916 description 2917 "This leaf augments the 'rt:destination-address' parameter of 2918 the 'rt:fib-route' operation."; 2919 leaf address { 2920 type inet:ipv6-address; 2921 description 2922 "IPv6 destination address."; 2923 } 2924 } 2926 augment "/rt:fib-route/rt:output/rt:route" { 2927 when "rt:address-family='v6ur:ipv6-unicast'" { 2928 description 2929 "This augment is valid only for IPv6 unicast."; 2930 } 2931 description 2932 "This leaf augments the reply to the 'rt:fib-route' 2933 operation."; 2934 leaf destination-prefix { 2935 type inet:ipv6-prefix; 2936 description 2937 "IPv6 destination prefix."; 2938 } 2939 } 2941 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 2942 + "rt:next-hop-options/rt:simple-next-hop" { 2943 when "../rt:address-family='v4ur:ipv6-unicast'" { 2944 description 2945 "This augment is valid only for IPv6 unicast."; 2946 } 2947 description 2948 "This leaf augments the 'simple-next-hop' case in the reply to 2949 the 'rt:fib-route' operation."; 2950 leaf next-hop-address { 2951 type inet:ipv6-address; 2952 description 2953 "IPv6 address of the next-hop."; 2954 } 2955 } 2956 } 2958 2960 10. IANA Considerations 2962 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2963 actual RFC number (and remove this note). 2965 This document registers the following namespace URIs in the IETF XML 2966 registry [RFC3688]: 2968 ---------------------------------------------------------- 2969 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2971 Registrant Contact: The IESG. 2973 XML: N/A, the requested URI is an XML namespace. 2974 ---------------------------------------------------------- 2976 ---------------------------------------------------------- 2977 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2979 Registrant Contact: The IESG. 2981 XML: N/A, the requested URI is an XML namespace. 2982 ---------------------------------------------------------- 2984 ---------------------------------------------------------- 2985 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2987 Registrant Contact: The IESG. 2989 XML: N/A, the requested URI is an XML namespace. 2990 ---------------------------------------------------------- 2992 This document registers the following YANG modules in the YANG Module 2993 Names registry [RFC6020]: 2995 ------------------------------------------------------------------- 2996 name: ietf-routing 2997 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2998 prefix: rt 2999 reference: RFC XXXX 3000 ------------------------------------------------------------------- 3002 ------------------------------------------------------------------- 3003 name: ietf-ipv4-unicast-routing 3004 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 3005 prefix: v4ur 3006 reference: RFC XXXX 3007 ------------------------------------------------------------------- 3009 ------------------------------------------------------------------- 3010 name: ietf-ipv6-unicast-routing 3011 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 3012 prefix: v6ur 3013 reference: RFC XXXX 3014 ------------------------------------------------------------------- 3016 11. Security Considerations 3018 Configuration and state data conforming to the core routing data 3019 model (defined in this document) are designed to be accessed via the 3020 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 3021 transport layer and the mandatory-to-implement secure transport is 3022 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 3023 the means to restrict access for particular NETCONF users to a pre- 3024 configured subset of all available NETCONF protocol operations and 3025 content. 3027 A number of data nodes defined in the YANG modules belonging to the 3028 configuration part of the core routing data model are 3029 writable/creatable/deletable (i.e., "config true" in YANG terms, 3030 which is the default). These data nodes may be considered sensitive 3031 or vulnerable in some network environments. Write operations to 3032 these data nodes, such as "edit-config", can have negative effects on 3033 the network if the protocol operations are not properly protected. 3035 The vulnerable "config true" subtrees and data nodes are the 3036 following: 3038 /routing/routing-instance/interfaces/interface: This list assigns a 3039 network layer interface to a routing instance and may also specify 3040 interface parameters related to routing. 3042 /routing/routing-instance/routing-protocols/routing-protocol: This 3043 list specifies the routing protocols configured on a device. 3045 /routing/route-filters/route-filter: This list specifies the 3046 configured route filters which represent administrative policies 3047 for redistributing and modifying routing information. 3049 /routing/ribs/rib: This list specifies the RIBs configured for the 3050 device. 3052 Unauthorized access to any of these lists can adversely affect the 3053 routing subsystem of both the local device and the network. This may 3054 lead to network malfunctions, delivery of packets to inappropriate 3055 destinations and other problems. 3057 12. Acknowledgments 3059 The author wishes to thank Nitin Bahadur, Martin Bjorklund, Dean 3060 Bogdanovic, Joel Halpern, Wes Hardaker, Sriganesh Kini, 3061 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Acee Lindem, 3062 Stephane Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, 3063 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- 3064 Kit Yeung and Jeffrey Zhang for their helpful comments and 3065 suggestions. 3067 13. References 3069 13.1. Normative References 3071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3072 Requirement Levels", BCP 14, RFC 2119, March 1997. 3074 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3075 January 2004. 3077 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3078 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3079 September 2007. 3081 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 3082 Network Configuration Protocol (NETCONF)", RFC 6020, 3083 October 2010. 3085 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 3086 Bierman, "Network Configuration Protocol (NETCONF)", RFC 3087 6241, June 2011. 3089 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 3090 July 2013. 3092 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 3093 Management", RFC 7223, May 2014. 3095 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 3096 7277, June 2014. 3098 13.2. Informative References 3100 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 3101 Networks (VPNs)", RFC 4364, February 2006. 3103 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 3104 Data Model Documents", RFC 6087, January 2011. 3106 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3107 Shell (SSH)", RFC 6242, June 2011. 3109 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 3110 Protocol (NETCONF) Access Control Model", RFC 6536, March 3111 2012. 3113 Appendix A. The Complete Data Trees 3115 This appendix presents the complete configuration and state data 3116 trees of the core routing data model. 3118 See Section 2.2 for an explanation of the symbols used. Data type of 3119 every leaf node is shown near the right end of the corresponding 3120 line. 3122 A.1. Configuration Data 3124 +--rw routing 3125 +--rw routing-instance* [name] 3126 | +--rw name string 3127 | +--rw type? identityref 3128 | +--rw enabled? boolean 3129 | +--rw router-id? yang:dotted-quad 3130 | +--rw description? string 3131 | +--rw default-ribs {multiple-ribs}? 3132 | | +--rw default-rib* [address-family] 3133 | | +--rw address-family identityref 3134 | | +--rw rib-name string 3135 | +--rw interfaces 3136 | | +--rw interface* [name] 3137 | | +--rw name if:interface-ref 3138 | | +--rw v6ur:ipv6-router-advertisements 3139 | | +--rw v6ur:send-advertisements? boolean 3140 | | +--rw v6ur:max-rtr-adv-interval? uint16 3141 | | +--rw v6ur:min-rtr-adv-interval? uint16 3142 | | +--rw v6ur:managed-flag? boolean 3143 | | +--rw v6ur:other-config-flag? boolean 3144 | | +--rw v6ur:link-mtu? uint32 3145 | | +--rw v6ur:reachable-time? uint32 3146 | | +--rw v6ur:retrans-timer? uint32 3147 | | +--rw v6ur:cur-hop-limit? uint8 3148 | | +--rw v6ur:default-lifetime? uint16 3149 | | +--rw v6ur:prefix-list 3150 | | +--rw v6ur:prefix* [prefix-spec] 3151 | | +--rw v6ur:prefix-spec inet:ipv6-prefix 3152 | | +--rw (control-adv-prefixes)? 3153 | | +--:(no-advertise) 3154 | | | +--rw v6ur:no-advertise? empty 3155 | | +--:(advertise) 3156 | | +--rw v6ur:valid-lifetime? uint32 3157 | | +--rw v6ur:on-link-flag? boolean 3158 | | +--rw v6ur:preferred-lifetime? uint32 3159 | | +--rw v6ur:autonomous-flag? boolean 3160 | +--rw routing-protocols 3161 | +--rw routing-protocol* [type name] 3162 | +--rw type identityref 3163 | +--rw name string 3164 | +--rw description? string 3165 | +--rw enabled? boolean 3166 | +--rw route-preference? route-preference 3167 | +--rw connected-ribs 3168 | | +--rw connected-rib* [rib-name] 3169 | | +--rw rib-name rib-ref 3170 | | +--rw import-filter? route-filter-ref 3171 | | +--rw export-filter? route-filter-ref 3172 | +--rw static-routes 3173 | +--rw v4ur:ipv4 3174 | | +--rw v4ur:route* [destination-prefix] 3175 | | +--rw v4ur:destination-prefix inet:ipv4-prefix 3176 | | +--rw v4ur:description? string 3177 | | +--rw v4ur:next-hop 3178 | | +--rw (simple-or-list)? 3179 | | +--:(multipath-entry) 3180 | | | +--rw v4ur:multipath-entry* [name] 3181 | | | +--rw v4ur:name string 3182 | | | +--rw (next-hop-options) 3183 | | | | +--:(simple-next-hop) 3184 | | | | | +--rw v4ur:outgoing-interface? 3185 | | | | +--:(special-next-hop) 3186 | | | | | +--rw v4ur:special-next-hop? 3187 | | | | +--:(next-hop-address) 3188 | | | | +--rw v4ur:next-hop-address? 3189 | | | +--rw v4ur:priority? 3190 | | | +--rw v4ur:weight? uint8 3191 | | +--:(simple-next-hop) 3192 | | +--rw (next-hop-options) 3193 | | +--:(simple-next-hop) 3194 | | | +--rw v4ur:outgoing-interface? 3195 | | +--:(special-next-hop) 3196 | | | +--rw v4ur:special-next-hop? 3197 | | +--:(next-hop-address) 3198 | | +--rw v4ur:next-hop-address? 3199 | +--rw v6ur:ipv6 3200 | +--rw v6ur:route* [destination-prefix] 3201 | +--rw v6ur:destination-prefix inet:ipv6-prefix 3202 | +--rw v6ur:description? string 3203 | +--rw v6ur:next-hop 3204 | +--rw (simple-or-list)? 3205 | +--:(multipath-entry) 3206 | | +--rw v6ur:multipath-entry* [name] 3207 | | +--rw v6ur:name string 3208 | | +--rw (next-hop-options) 3209 | | | +--:(simple-next-hop) 3210 | | | | +--rw v6ur:outgoing-interface? 3211 | | | +--:(special-next-hop) 3212 | | | | +--rw v6ur:special-next-hop? 3213 | | | +--:(next-hop-address) 3214 | | | +--rw v6ur:next-hop-address? 3215 | | +--rw v6ur:priority? 3216 | | +--rw v6ur:weight? uint8 3217 | +--:(simple-next-hop) 3218 | +--rw (next-hop-options) 3219 | +--:(simple-next-hop) 3220 | | +--rw v6ur:outgoing-interface? 3221 | +--:(special-next-hop) 3222 | | +--rw v6ur:special-next-hop? 3223 | +--:(next-hop-address) 3224 | +--rw v6ur:next-hop-address? 3225 +--rw ribs 3226 | +--rw rib* [name] 3227 | +--rw name string 3228 | +--rw address-family identityref 3229 | +--rw description? string 3230 | +--rw recipient-ribs {multiple-ribs}? 3231 | +--rw recipient-rib* [rib-name] 3232 | +--rw rib-name rib-ref 3233 | +--rw filter? route-filter-ref 3234 +--rw route-filters 3235 +--rw route-filter* [name] 3236 +--rw name string 3237 +--rw description? string 3238 +--rw type identityref 3240 A.2. State Data 3242 +--ro routing-state 3243 +--ro routing-instance* [name] 3244 | +--ro name string 3245 | +--ro id uint64 3246 | +--ro type? identityref 3247 | +--ro default-ribs 3248 | | +--ro default-rib* [address-family] 3249 | | +--ro address-family identityref 3250 | | +--ro rib-name rib-state-ref 3251 | +--ro interfaces 3252 | | +--ro interface* [name] 3253 | | +--ro name if:interface-state-ref 3254 | | +--ro v6ur:ipv6-router-advertisements 3255 | | +--ro v6ur:send-advertisements? boolean 3256 | | +--ro v6ur:max-rtr-adv-interval? uint16 3257 | | +--ro v6ur:min-rtr-adv-interval? uint16 3258 | | +--ro v6ur:managed-flag? boolean 3259 | | +--ro v6ur:other-config-flag? boolean 3260 | | +--ro v6ur:link-mtu? uint32 3261 | | +--ro v6ur:reachable-time? uint32 3262 | | +--ro v6ur:retrans-timer? uint32 3263 | | +--ro v6ur:cur-hop-limit? uint8 3264 | | +--ro v6ur:default-lifetime? uint16 3265 | | +--ro v6ur:prefix-list 3266 | | +--ro v6ur:prefix* [prefix-spec] 3267 | | +--ro v6ur:prefix-spec inet:ipv6-prefix 3268 | | +--ro v6ur:valid-lifetime? uint32 3269 | | +--ro v6ur:on-link-flag? boolean 3270 | | +--ro v6ur:preferred-lifetime? uint32 3271 | | +--ro v6ur:autonomous-flag? boolean 3272 | +--ro routing-protocols 3273 | +--ro routing-protocol* [type name] 3274 | +--ro type identityref 3275 | +--ro name string 3276 | +--ro route-preference route-preference 3277 | +--ro connected-ribs 3278 | +--ro connected-rib* [rib-name] 3279 | +--ro rib-name rib-state-ref 3280 | +--ro import-filter? route-filter-state-ref 3281 | +--ro export-filter? route-filter-state-ref 3282 +--ro next-hop-lists 3283 | +--ro next-hop-list* [id] 3284 | +--ro id uint64 3285 | +--ro address-family identityref 3286 | +--ro next-hop* 3287 | +--ro (next-hop-options) 3288 | | +--:(next-hop-list) 3289 | | | +--ro next-hop-list? next-hop-list-ref 3290 | | +--:(use-rib) 3291 | | | +--ro use-rib? rib-state-ref 3292 | | +--:(simple-next-hop) 3293 | | | +--ro outgoing-interface? 3294 | | | +--ro v4ur:next-hop-address? inet:ipv4-address 3295 | | | +--ro v6ur:next-hop-address? inet:ipv6-address 3296 | | +--:(special-next-hop) 3297 | | +--ro special-next-hop? enumeration 3298 | +--ro priority? enumeration 3299 | +--ro weight? uint8 3300 +--ro ribs 3301 | +--ro rib* [name] 3302 | +--ro name string 3303 | +--ro id uint64 3304 | +--ro address-family identityref 3305 | +--ro routes 3306 | | +--ro route* 3307 | | +--ro route-preference? route-preference 3308 | | +--ro next-hop 3309 | | | +--ro (next-hop-options) 3310 | | | +--:(next-hop-list) 3311 | | | | +--ro next-hop-list? next-hop-list-ref 3312 | | | +--:(use-rib) 3313 | | | | +--ro use-rib? rib-state-ref 3314 | | | +--:(simple-next-hop) 3315 | | | | +--ro outgoing-interface? 3316 | | | | +--ro v4ur:next-hop-address? 3317 | | | | +--ro v6ur:next-hop? 3318 | | | +--:(special-next-hop) 3319 | | | +--ro special-next-hop? enumeration 3320 | | +--ro source-protocol identityref 3321 | | +--ro active? empty 3322 | | +--ro last-updated? yang:date-and-time 3323 | | +--ro v4ur:destination-prefix? inet:ipv4-prefix 3324 | | +--ro v6ur:destination-prefix? inet:ipv6-prefix 3325 | +--ro recipient-ribs 3326 | +--ro recipient-rib* [rib-name] 3327 | +--ro rib-name rib-state-ref 3328 | +--ro filter? route-filter-state-ref 3329 +--ro route-filters 3330 +--ro route-filter* [name] 3331 +--ro name string 3332 +--ro type identityref 3334 Appendix B. Minimum Implementation 3336 Some parts and options of the core routing model, such as route 3337 filters or multiple routing tables, are intended only for advanced 3338 routers. This appendix gives basic non-normative guidelines for 3339 implementing a bare minimum of available functions. Such an 3340 implementation may be used for hosts or very simple routers. 3342 A minimum implementation will provide a single system-controlled 3343 routing instance, and will not allow clients to create any user- 3344 controlled instances. 3346 Typically, neither of the features defined in the "ietf-routing" 3347 module ("multiple-ribs" and "multipath-routes") will be supported. 3348 This means that: 3350 o A single system-controlled RIB (routing table) is available for 3351 each supported address family - IPv4, IPv6 or both. These RIBs 3352 are the default RIBs, so references to them will also appear as 3353 system-controlled entries of the "default-rib" list in state data. 3354 No user-controlled RIBs are allowed. 3356 o Each route has no more than one "next-hop", "outgoing-interface" 3357 or "special-next-hop". 3359 In addition to the mandatory instance of the "direct" pseudo- 3360 protocol, a minimum implementation should support configured 3361 instance(s) of the "static" pseudo-protocol. Even with a single RIB 3362 per address family, it may be occasionally useful to be able to 3363 configure multiple "static" instances. For example, a client may 3364 want to configure alternative sets of static routes and activate or 3365 deactivate them by means of configuring appropriate route filters 3366 ("allow-all-route-filter" or "deny-all-route-filter"). 3368 Platforms with severely constrained resources may use deviations for 3369 restricting the data model, e.g., limiting the number of "static" 3370 routing protocol instances, preventing any route filters to be 3371 configured etc. 3373 Appendix C. Example: Adding a New Routing Protocol 3375 This appendix demonstrates how the core routing data model can be 3376 extended to support a new routing protocol. The YANG module 3377 "example-rip" shown below is intended only as an illustration rather 3378 than a real definition of a data model for the RIP routing protocol. 3379 For the sake of brevity, this module does not obey all the guidelines 3380 specified in [RFC6087]. See also Section 5.4.2. 3382 module example-rip { 3384 namespace "http://example.com/rip"; 3386 prefix "rip"; 3388 import ietf-routing { 3389 prefix "rt"; 3390 } 3392 identity rip { 3393 base rt:routing-protocol; 3394 description 3395 "Identity for the RIP routing protocol."; 3396 } 3398 typedef rip-metric { 3399 type uint8 { 3400 range "0..16"; 3401 } 3402 } 3404 grouping route-content { 3405 description 3406 "This grouping defines RIP-specific route attributes."; 3407 leaf metric { 3408 type rip-metric; 3409 } 3410 leaf tag { 3411 type uint16; 3412 default "0"; 3413 description 3414 "This leaf may be used to carry additional info, e.g. AS 3415 number."; 3416 } 3417 } 3419 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 3420 when "rt:source-protocol = 'rip:rip'" { 3421 description 3422 "This augment is only valid for a routes whose source 3423 protocol is RIP."; 3424 } 3425 description 3426 "RIP-specific route attributes."; 3427 uses route-content; 3428 } 3430 augment "/rt:active-route/rt:output/rt:route" { 3431 description 3432 "RIP-specific route attributes in the output of 'active-route' 3433 RPC."; 3434 uses route-content; 3435 } 3437 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 3438 + "rt:routing-protocol" { 3439 when "rt:type = 'rip:rip'" { 3440 description 3441 "This augment is only valid for a routing protocol instance 3442 of type 'rip'."; 3443 } 3444 container rip { 3445 description 3446 "RIP instance configuration."; 3447 container interfaces { 3448 description 3449 "Per-interface RIP configuration."; 3450 list interface { 3451 key "name"; 3452 description 3453 "RIP is enabled on interfaces that have an entry in this 3454 list, unless 'enabled' is set to 'false' for that 3455 entry."; 3456 leaf name { 3457 type leafref { 3458 path "../../../../../../rt:interfaces/rt:interface/" 3459 + "rt:name"; 3460 } 3461 } 3462 leaf enabled { 3463 type boolean; 3464 default "true"; 3465 } 3466 leaf metric { 3467 type rip-metric; 3468 default "1"; 3470 } 3471 } 3472 } 3473 leaf update-interval { 3474 type uint8 { 3475 range "10..60"; 3476 } 3477 units "seconds"; 3478 default "30"; 3479 description 3480 "Time interval between periodic updates."; 3481 } 3482 } 3483 } 3484 } 3486 Appendix D. Example: NETCONF Reply 3488 This section contains a sample reply to the NETCONF message, 3489 which could be sent by a server supporting (i.e., advertising them in 3490 the NETCONF message) the following YANG modules: 3492 o ietf-interfaces [RFC7223], 3494 o ietf-ip [RFC7277], 3496 o ietf-routing (Section 7), 3498 o ietf-ipv4-unicast-routing (Section 8), 3500 o ietf-ipv6-unicast-routing (Section 9). 3502 We assume a simple network set-up as shown in Figure 5: router "A" 3503 uses static default routes with the "ISP" router as the next-hop. 3504 IPv6 router advertisements are configured only on the "eth1" 3505 interface and disabled on the upstream "eth0" interface. 3507 +-----------------+ 3508 | | 3509 | Router ISP | 3510 | | 3511 +--------+--------+ 3512 |2001:db8:0:1::2 3513 |192.0.2.2 3514 | 3515 | 3516 |2001:db8:0:1::1 3517 eth0|192.0.2.1 3518 +--------+--------+ 3519 | | 3520 | Router A | 3521 | | 3522 +--------+--------+ 3523 eth1|198.51.100.1 3524 |2001:db8:0:2::1 3525 | 3527 Figure 5: Example network configuration 3529 A reply to the NETCONF message sent by router "A" would then be 3530 as follows: 3532 3533 3542 3543 3544 3545 eth0 3546 ianaift:ethernetCsmacd 3547 3548 Uplink to ISP. 3549 3550 3551 3552 192.0.2.1 3553 24 3554 3555 true 3556 3557 3558 3559 2001:0db8:0:1::1 3560 64 3561 3562 true 3563 3564 false 3565 3566 3567 3568 3569 eth1 3570 ianaift:ethernetCsmacd 3571 3572 Interface to the internal network. 3573 3574 3575 3576 198.51.100.1 3577 24 3578 3579 true 3580 3581 3582 3583 2001:0db8:0:2::1 3584 64 3585 3586 true 3587 3588 false 3589 3590 3591 3592 3593 3594 3595 eth0 3596 ianaift:ethernetCsmacd 3597 00:0C:42:E5:B1:E9 3598 up 3599 3600 3601 2014-10-24T17:11:27+00:58 3602 3604 3605 3606 true 3607 1500 3608 3609 192.0.2.1 3610 24 3611 3612 3613 3614 true 3615 1500 3616 3617 2001:0db8:0:1::1 3618 64 3619 3620 3621 3622 3623 eth1 3624 ianaift:ethernetCsmacd 3625 up 3626 00:0C:42:E5:B1:EA 3627 3628 3629 2014-10-24T17:11:27+00:59 3630 3631 3632 3633 true 3634 1500 3635 3636 198.51.100.1 3637 24 3638 3639 3640 3641 true 3642 1500 3643 3644 2001:0db8:0:2::1 3645 64 3646 3647 3648 3649 3650 3651 3652 rtr0 3653 Router A 3654 3655 3656 eth1 3657 3658 true 3659 3660 3661 2001:db8:0:2::/64 3662 3663 3664 3665 3666 3667 3668 3669 rt:static 3670 st0 3671 3672 Static routing is used for the internal network. 3673 3674 3675 3676 3677 0.0.0.0/0 3678 3679 192.0.2.2 3680 3681 3682 3683 3684 3685 ::/0 3686 3687 2001:db8:0:1::2 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 rtr0 3699 2718281828 3700 3701 3702 v4ur:ipv4-unicast 3703 ipv4-master 3704 3705 3706 v6ur:ipv6-unicast 3707 ipv6-master 3708 3709 3710 3711 3712 eth0 3713 3714 3715 eth1 3716 3717 true 3718 3719 3720 2001:db8:0:2::/64 3721 3722 3723 3724 3725 3726 3727 3728 rt:static 3729 st0 3730 5 3731 3732 3733 3734 3735 3736 ipv4-master 3737 897932384 3738 v4ur:ipv4-unicast 3739 3740 3741 192.0.2.1/24 3742 3743 eth0 3744 3745 0 3746 rt:direct 3747 3749 2014-10-24T17:11:27+01:00 3750 3751 3752 3753 3754 198.51.100.0/24 3755 3756 3757 eth1 3758 3759 rt:direct 3760 0 3761 3762 2014-10-24T17:11:27+01:00 3763 3764 3765 3766 0.0.0.0/0 3767 rt:static 3768 5 3769 3770 192.0.2.2 3771 3772 3773 2014-10-24T18:02:45+01:00 3774 3775 3776 3777 3778 3779 ipv6-master 3780 751058209 3781 v6ur:ipv6-unicast 3782 3783 3784 3785 2001:db8:0:1::/64 3786 3787 3788 eth0 3789 3790 rt:direct 3791 0 3792 3793 2014-10-24T17:11:27+01:00 3794 3795 3796 3798 3799 2001:db8:0:2::/64 3800 3801 3802 eth1 3803 3804 rt:direct 3805 0 3806 3807 2014-10-24T17:11:27+01:00 3808 3809 3810 3811 ::/0 3812 3813 2001:db8:0:1::2 3814 3815 rt:static 3816 5 3817 3818 2014-10-24T18:02:45+01:00 3819 3820 3821 3822 3823 3824 3825 3826 3828 Appendix E. Change Log 3830 RFC Editor: Remove this section upon publication as an RFC. 3832 E.1. Changes Between Versions -15 and -16 3834 o Added 'type' as the second key component of 'routing-protocol', 3835 both in configuration and state data. 3837 o The restriction of no more than one connected RIB per address 3838 family was removed. 3840 o Removed the 'id' key of routes in RIBs. This list has no keys 3841 anymore. 3843 o Remove the 'id' key from static routes and make 'destination- 3844 prefix' the only key. 3846 o Added 'route-preference' as a new attribute of routes in RIB. 3848 o Added 'active' as a new attribute of routes in RIBs. 3850 o Renamed RPC operation 'active-route' to 'fib-route. 3852 o Added 'route-preference' as a new parameter of routing protocol 3853 instances, both in configuration and state data. 3855 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 3856 routing-instance'. 3858 o Added next-hop lists to state data. 3860 o Added two cases for specifying next-hops indirectly - via a new 3861 RIB or a recursive list of next-hops. 3863 o Reorganized next-hop in static routes. 3865 o Removed all 'if-feature' statements from state data. 3867 E.2. Changes Between Versions -14 and -15 3869 o Removed all defaults from state data. 3871 o Removed default from 'cur-hop-limit' in config. 3873 E.3. Changes Between Versions -13 and -14 3875 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 3876 feature. 3878 o Removed default value of 'cur-hop-limit' in state data. 3880 o Moved parts of descriptions and all references on IPv6 RA 3881 parameters from state data to configuration. 3883 o Added reference to RFC 6536 in the Security section. 3885 E.4. Changes Between Versions -12 and -13 3887 o Wrote appendix about minimum implementation. 3889 o Remove "when" statement for IPv6 router interface state data - it 3890 was dependent on a config value that may not be present. 3892 o Extra container for the next-hop list. 3894 o Names rather than numeric ids are used for referring to list 3895 entries in state data. 3897 o Numeric ids are always declared as mandatory and unique. Their 3898 description states that they are ephemeral. 3900 o Descriptions of "name" keys in state data lists are required to be 3901 persistent. 3903 o 3905 o Removed "if-feature multiple-ribs;" from connected-ribs. 3907 o "rib-name" instead of "name" is used as the name of leafref nodes. 3909 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3910 in node names and text. 3912 E.5. Changes Between Versions -11 and -12 3914 o Removed feature "advanced-router" and introduced two features 3915 instead: "multiple-ribs" and "multipath-routes". 3917 o Unified the keys of config and state versions of "routing- 3918 instance" and "rib" lists. 3920 o Numerical identifiers of state list entries are not keys anymore, 3921 but they are constrained using the "unique" statement. 3923 o Updated acknowledgements. 3925 E.6. Changes Between Versions -10 and -11 3927 o Migrated address families from IANA enumerations to identities. 3929 o Terminology and node names aligned with the I2RS RIB model: router 3930 -> routing instance, routing table -> RIB. 3932 o Introduced uint64 keys for state lists: routing-instance, rib, 3933 route, nexthop. 3935 o Described the relationship between system-controlled and user- 3936 controlled list entries. 3938 o Feature "user-defined-routing-tables" changed into "advanced- 3939 router". 3941 o Made nexthop into a choice in order to allow for nexthop-list 3942 (I2RS requirement). 3944 o Added nexthop-list with entries having priorities (backup) and 3945 weights (load balancing). 3947 o Updated bibliography references. 3949 E.7. Changes Between Versions -09 and -10 3951 o Added subtree for state data ("/routing-state"). 3953 o Terms "system-controlled entry" and "user-controlled entry" 3954 defined and used. 3956 o New feature "user-defined-routing-tables". Nodes that are useful 3957 only with user-defined routing tables are now conditional. 3959 o Added grouping "router-id". 3961 o In routing tables, "source-protocol" attribute of routes now 3962 reports only protocol type, and its datatype is "identityref". 3964 o Renamed "main-routing-table" to "default-routing-table". 3966 E.8. Changes Between Versions -08 and -09 3968 o Fixed "must" expresion for "connected-routing-table". 3970 o Simplified "must" expression for "main-routing-table". 3972 o Moved per-interface configuration of a new routing protocol under 3973 'routing-protocol'. This also affects the 'example-rip' module. 3975 E.9. Changes Between Versions -07 and -08 3977 o Changed reference from RFC6021 to RFC6021bis. 3979 E.10. Changes Between Versions -06 and -07 3981 o The contents of in Appendix D was updated: "eth[01]" 3982 is used as the value of "location", and "forwarding" is on for 3983 both interfaces and both IPv4 and IPv6. 3985 o The "must" expression for "main-routing-table" was modified to 3986 avoid redundant error messages reporting address family mismatch 3987 when "name" points to a non-existent routing table. 3989 o The default behavior for IPv6 RA prefix advertisements was 3990 clarified. 3992 o Changed type of "rt:router-id" to "ip:dotted-quad". 3994 o Type of "rt:router-id" changed to "yang:dotted-quad". 3996 o Fixed missing prefixes in XPath expressions. 3998 E.11. Changes Between Versions -05 and -06 4000 o Document title changed: "Configuration" was replaced by 4001 "Management". 4003 o New typedefs "routing-table-ref" and "route-filter-ref". 4005 o Double slashes "//" were removed from XPath expressions and 4006 replaced with the single "/". 4008 o Removed uniqueness requirement for "router-id". 4010 o Complete data tree is now in Appendix A. 4012 o Changed type of "source-protocol" from "leafref" to "string". 4014 o Clarified the relationship between routing protocol instances and 4015 connected routing tables. 4017 o Added a must constraint saying that a routing table connected to 4018 the direct pseudo-protocol must not be a main routing table. 4020 E.12. Changes Between Versions -04 and -05 4022 o Routing tables are now global, i.e., "routing-tables" is a child 4023 of "routing" rather than "router". 4025 o "must" statement for "static-routes" changed to "when". 4027 o Added "main-routing-tables" containing references to main routing 4028 tables for each address family. 4030 o Removed the defaults for "address-family" and "safi" and made them 4031 mandatory. 4033 o Removed the default for route-filter/type and made this leaf 4034 mandatory. 4036 o If there is no active route for a given destination, the "active- 4037 route" RPC returns no output. 4039 o Added "enabled" switch under "routing-protocol". 4041 o Added "router-type" identity and "type" leaf under "router". 4043 o Route attribute "age" changed to "last-updated", its type is 4044 "yang:date-and-time". 4046 o The "direct" pseudo-protocol is always connected to main routing 4047 tables. 4049 o Entries in the list of connected routing tables renamed from 4050 "routing-table" to "connected-routing-table". 4052 o Added "must" constraint saying that a routing table must not be 4053 its own recipient. 4055 E.13. Changes Between Versions -03 and -04 4057 o Changed "error-tag" for both RPC methods from "missing element" to 4058 "data-missing". 4060 o Removed the decrementing behavior for advertised IPv6 prefix 4061 parameters "valid-lifetime" and "preferred-lifetime". 4063 o Changed the key of the static route lists from "seqno" to "id" 4064 because the routes needn't be sorted. 4066 o Added 'must' constraint saying that "preferred-lifetime" must not 4067 be greater than "valid-lifetime". 4069 E.14. Changes Between Versions -02 and -03 4071 o Module "iana-afn-safi" moved to I-D "iana-if-type". 4073 o Removed forwarding table. 4075 o RPC "get-route" changed to "active-route". Its output is a list 4076 of routes (for multi-path routing). 4078 o New RPC "route-count". 4080 o For both RPCs, specification of negative responses was added. 4082 o Relaxed separation of router instances. 4084 o Assignment of interfaces to router instances needn't be disjoint. 4086 o Route filters are now global. 4088 o Added "allow-all-route-filter" for symmetry. 4090 o Added Section 6 about interactions with "ietf-interfaces" and 4091 "ietf-ip". 4093 o Added "router-id" leaf. 4095 o Specified the names for IPv4/IPv6 unicast main routing tables. 4097 o Route parameter "last-modified" changed to "age". 4099 o Added container "recipient-routing-tables". 4101 E.15. Changes Between Versions -01 and -02 4103 o Added module "ietf-ipv6-unicast-routing". 4105 o The example in Appendix D now uses IP addresses from blocks 4106 reserved for documentation. 4108 o Direct routes appear by default in the forwarding table. 4110 o Network layer interfaces must be assigned to a router instance. 4111 Additional interface configuration may be present. 4113 o The "when" statement is only used with "augment", "must" is used 4114 elsewhere. 4116 o Additional "must" statements were added. 4118 o The "route-content" grouping for IPv4 and IPv6 unicast now 4119 includes the material from the "ietf-routing" version via "uses 4120 rt:route-content". 4122 o Explanation of symbols in the tree representation of data model 4123 hierarchy. 4125 E.16. Changes Between Versions -00 and -01 4127 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 4129 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 4130 safi" module. 4132 o Names of some data nodes were changed, in particular "routing- 4133 process" is now "router". 4135 o The restriction of a single AFN/SAFI per router was lifted. 4137 o RPC operation "delete-route" was removed. 4139 o Illegal XPath references from "get-route" to the datastore were 4140 fixed. 4142 o Section "Security Considerations" was written. 4144 Author's Address 4146 Ladislav Lhotka 4147 CZ.NIC 4149 Email: lhotka@nic.cz