idnits 2.17.1 draft-ietf-netmod-routing-cfg-13.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 3093 has weird spacing: '...-family ide...' == Line 3173 has weird spacing: '...-family ide...' == Line 3177 has weird spacing: '...ib-name rib...' == Line 3195 has weird spacing: '...-family ide...' == Line 3231 has weird spacing: '...-family ide...' == (3 more instances...) -- The document date (January 10, 2014) is 3730 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) == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-15 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-ip-cfg-12 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track January 10, 2014 5 Expires: July 14, 2014 7 A YANG Data Model for Routing Management 8 draft-ietf-netmod-routing-cfg-13 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 individual routing protocols and 17 other related functions. The core routing data model provides common 18 building blocks for such extensions - routing instances, routes, 19 routing 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 July 14, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 57 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5 58 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 60 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. The Design of the Core Routing Data Model . . . . . . . . . . 9 62 4.1. System-Controlled and User-Controlled List Entries . . . . 12 63 4.2. Features of Advanced Routers . . . . . . . . . . . . . . . 13 64 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 14 65 5.1. Routing Instance . . . . . . . . . . . . . . . . . . . . . 14 66 5.1.1. Parameters of IPv6 Routing Instance Interfaces . . . . 15 67 5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 5.3. Routing Information Base (RIB) . . . . . . . . . . . . . . 16 69 5.3.1. Multiple RIBs per Address Family . . . . . . . . . . . 17 70 5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . . 17 71 5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 18 72 5.4.2. Defining New Routing Protocols . . . . . . . . . . . . 20 73 5.5. Route Filter . . . . . . . . . . . . . . . . . . . . . . . 21 74 5.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 22 75 6. Interactions with Other YANG Modules . . . . . . . . . . . . . 23 76 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 23 77 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 23 78 7. Routing Management YANG Module . . . . . . . . . . . . . . . . 25 79 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 47 80 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 54 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 71 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 85 13.1. Normative References . . . . . . . . . . . . . . . . . . . 73 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 73 87 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . . 74 88 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . . 74 89 A.2. Operational State Data . . . . . . . . . . . . . . . . . . 76 90 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 78 91 Appendix C. Example: Adding a New Routing Protocol . . . . . . . 79 92 Appendix D. Example: NETCONF Reply . . . . . . . . . . . . 82 93 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 89 94 E.1. Changes Between Versions -12 and -13 . . . . . . . . . . . 89 95 E.2. Changes Between Versions -11 and -12 . . . . . . . . . . . 89 96 E.3. Changes Between Versions -10 and -11 . . . . . . . . . . . 90 97 E.4. Changes Between Versions -09 and -10 . . . . . . . . . . . 90 98 E.5. Changes Between Versions -08 and -09 . . . . . . . . . . . 90 99 E.6. Changes Between Versions -07 and -08 . . . . . . . . . . . 91 100 E.7. Changes Between Versions -06 and -07 . . . . . . . . . . . 91 101 E.8. Changes Between Versions -05 and -06 . . . . . . . . . . . 91 102 E.9. Changes Between Versions -04 and -05 . . . . . . . . . . . 92 103 E.10. Changes Between Versions -03 and -04 . . . . . . . . . . . 92 104 E.11. Changes Between Versions -02 and -03 . . . . . . . . . . . 93 105 E.12. Changes Between Versions -01 and -02 . . . . . . . . . . . 93 106 E.13. Changes Between Versions -00 and -01 . . . . . . . . . . . 94 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 95 109 1. Introduction 111 This document contains a specification of the following YANG modules: 113 o Module "ietf-routing" provides generic components of a routing 114 data model. 116 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 117 module with additional data specific to IPv4 unicast. 119 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 120 module with additional data specific to IPv6 unicast, including 121 the router configuration variables required by [RFC4861]. 123 These modules together define the so-called core routing data model, 124 which is proposed as a basis for the development of data models for 125 configuration and management of more sophisticated routing systems. 126 While these three modules can be directly used for simple IP devices 127 with static routing (see Appendix B), their main purpose is to 128 provide essential building blocks for more complicated setups 129 involving multiple routing protocols, multicast routing, additional 130 address families, and advanced functions such as route filtering or 131 policy routing. To this end, it is expected that the core routing 132 data model will be augmented by numerous modules developed by other 133 IETF working groups. 135 2. Terminology and Notation 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 The following terms are defined in [RFC6241]: 143 o client 145 o message 147 o protocol operation 149 o server 151 The following terms are defined in [RFC6020]: 153 o augment 155 o configuration data 157 o data model 159 o data node 161 o feature 163 o mandatory node 165 o module 167 o state data 169 o RPC operation 171 2.1. Glossary of New Terms 173 active route: a route that is actually used for sending packets. If 174 there are multiple candidate routes with a matching destination 175 prefix, then it is up to the routing algorithm to select the 176 active route. 178 core routing data model: YANG data model comprising "ietf-routing", 179 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 180 modules. 182 direct route: a route to a directly connected network. 184 routing information base (RIB): An object containing a list of 185 routes together with other information. See Section 5.3 for 186 details. 188 system-controlled entry: An entry of a list in operational state 189 data ("config false") that is created by the system independently 190 of what has been explicitly configured. See Section 4.1 for 191 details. 193 user-controlled entry: An entry of a list in operational state data 194 ("config false") that is created and deleted as a direct 195 consequence of certain configuration changes. See Section 4.1 for 196 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. The meaning of the symbols in these 203 diagrams is as follows: 205 o Brackets "[" and "]" enclose list keys. 207 o Curly braces "{" and "}" contain names of optional features that 208 make the corresponding node conditional. 210 o Abbreviations before data node names: "rw" means configuration 211 (read-write) and "ro" state data (read-only). 213 o Symbols after data node names: "?" means an optional node and "*" 214 denotes a "list" or "leaf-list". 216 o Parentheses enclose choice and case nodes, and case nodes are also 217 marked with a colon (":"). 219 o Ellipsis ("...") stands for contents of subtrees that are not 220 shown. 222 2.3. Prefixes in Data Node Names 224 In this document, names of data nodes, RPC methods and other data 225 model objects are often used without a prefix, as long as it is clear 226 from the context in which YANG module each name is defined. 227 Otherwise, names are prefixed using the standard prefix associated 228 with the corresponding YANG module, as shown in Table 1. 230 +--------+---------------------------+-----------+ 231 | Prefix | YANG module | Reference | 232 +--------+---------------------------+-----------+ 233 | if | ietf-interfaces | [YANG-IF] | 234 | | | | 235 | ip | ietf-ip | [YANG-IP] | 236 | | | | 237 | rt | ietf-routing | Section 7 | 238 | | | | 239 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 240 | | | | 241 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 242 | | | | 243 | yang | ietf-yang-types | [RFC6991] | 244 | | | | 245 | inet | ietf-inet-types | [RFC6991] | 246 +--------+---------------------------+-----------+ 248 Table 1: Prefixes and corresponding YANG modules 250 3. Objectives 252 The initial design of the core routing data model was driven by the 253 following objectives: 255 o The data model should be suitable for the common address families, 256 in particular IPv4 and IPv6, and for unicast and multicast 257 routing, as well as Multiprotocol Label Switching (MPLS). 259 o Simple routing setups, such as static routing, should be 260 configurable in a simple way, ideally without any need to develop 261 additional YANG modules. 263 o On the other hand, the core routing framework must allow for 264 complicated setups involving multiple routing information bases 265 (RIB) and multiple routing protocols, as well as controlled 266 redistributions of routing information. 268 o Device vendors will want to map the data models built on this 269 generic framework to their proprietary data models and 270 configuration interfaces. Therefore, the framework should be 271 flexible enough to facilitate such a mapping and accommodate data 272 models with different logic. 274 4. The Design of the Core Routing Data Model 276 The core routing data model consists of three YANG modules. The 277 first module, "ietf-routing", defines the generic components of a 278 routing system. The other two modules, "ietf-ipv4-unicast-routing" 279 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 280 with additional data nodes that are needed for IPv4 and IPv6 unicast 281 routing, respectively. Figures 1 and 2 show abridged views of the 282 configuration and operational state data hierarchies. See Appendix A 283 for the complete data trees. 285 +--rw routing 286 +--rw routing-instance* [name] 287 | +--rw name 288 | +--rw type? 289 | +--rw enabled? 290 | +--rw router-id? 291 | +--rw description? 292 | +--rw default-ribs 293 | | +--rw default-rib* [address-family] 294 | | +--rw address-family 295 | | +--rw rib-name 296 | +--rw interfaces 297 | | +--rw interface* [name] 298 | | +--rw name 299 | | +--rw v6ur:ipv6-router-advertisements 300 | | ... 301 | +--rw routing-protocols 302 | +--rw routing-protocol* [name] 303 | +--rw name 304 | +--rw description? 305 | +--rw enabled? 306 | +--rw type 307 | +--rw connected-ribs 308 | | ... 309 | +--rw static-routes 310 | ... 311 +--rw ribs 312 | +--rw rib* [name] 313 | +--rw name 314 | +--rw address-family 315 | +--rw description? 316 | +--rw recipient-ribs 317 | +--rw recipient-rib* [rib-name] 318 | ... 319 +--rw route-filters 320 +--rw route-filter* [name] 321 +--rw name 322 +--rw description? 323 +--rw type 325 Figure 1: Configuration data hierarchy. 327 +--ro routing-state 328 +--ro routing-instance* [name] 329 | +--ro name 330 | +--ro id 331 | +--ro type? 332 | +--ro router-id? 333 | +--ro default-ribs 334 | | +--ro default-rib* [address-family] 335 | | +--ro address-family 336 | | +--ro rib-name 337 | +--ro interfaces 338 | | +--ro interface* [name] 339 | | +--ro name 340 | | +--ro v6ur:ipv6-router-advertisements 341 | | ... 342 | +--ro routing-protocols 343 | +--ro routing-protocol* [name] 344 | +--ro name 345 | +--ro type 346 | +--ro connected-ribs 347 | ... 348 +--ro ribs 349 | +--ro rib* [name] 350 | +--ro name 351 | +--ro id 352 | +--ro address-family 353 | +--ro routes 354 | | +--ro route* [id] 355 | | ... 356 | +--ro recipient-ribs 357 | +--ro recipient-rib* [rib-name] 358 | ... 359 +--ro route-filters 360 +--ro route-filter* [name] 361 +--ro name 362 +--ro type 364 Figure 2: Operational state data hierarchy. 366 As can be seen from Figures 1 and 2, the core routing data model 367 introduces several generic components of a routing framework: routing 368 instances, RIBs containing lists of routes, routing protocols and 369 route filters. The following subsections describe these components 370 in more detail. 372 By combining the components in various ways, and possibly augmenting 373 them with appropriate contents defined in other modules, various 374 routing systems can be realized. 376 +--------+ 377 | direct | +---+ +--------------+ +---+ +--------------+ 378 | routes |--->| F |--->| |<---| F |<---| | 379 +--------+ +---+ | default | +---+ | additional | 380 | RIB | | RIB | 381 +--------+ +---+ | | +---+ | | 382 | static |--->| F |--->| |--->| F |--->| | 383 | routes | +---+ +--------------+ +---+ +--------------+ 384 +--------+ ^ | ^ | 385 | v | v 386 +---+ +---+ +---+ +---+ 387 | F | | F | | F | | F | 388 +---+ +---+ +---+ +---+ 389 ^ | ^ | 390 | v | v 391 +----------+ +----------+ 392 | routing | | routing | 393 | protocol | | protocol | 394 +----------+ +----------+ 396 Figure 3: Example setup of a routing system 398 The example in Figure 3 shows a typical (though certainly not the 399 only possible) organization of a more complex routing subsystem for a 400 single address family. Several of its features are worth mentioning: 402 o Along with the default RIB, which is always present, an additional 403 RIB is configured. 405 o Each routing protocol instance, including the "static" and 406 "direct" pseudo-protocols, is connected to exactly one RIB with 407 which it can exchange routes (in both directions, except for the 408 "static" and "direct" pseudo-protocols). 410 o RIBs may also be connected to each other and exchange routes in 411 either direction (or both). 413 o Route exchanges along all connections may be controlled by means 414 of route filters, denoted by "F" in Figure 3. 416 4.1. System-Controlled and User-Controlled List Entries 418 The core routing data model defines several lists, for example 419 "routing-instance" or "rib", that have to be populated with at least 420 one entry in any properly functioning device, and additional entries 421 may be configured by the user. 423 In such a list, the server creates the required item as a so-called 424 system-controlled entry in operational state data, i.e., inside the 425 "routing-state" container. 427 Additional entries may be created in the configuration by the user 428 via the NETCONF protocol. These are so-called user-controlled 429 entries. If the server accepts a configured user-controlled entry, 430 then this entry also appears in the operational state version of the 431 list. 433 Corresponding entries in both versions of the list (in operational 434 state data and configuration) have the same value of the list key. 436 The user may also provide supplemental configuration of system- 437 controlled entries. To do so, the user creates a new entry in the 438 configuration with the desired contents. In order to bind this entry 439 with the corresponding entry in the operational state list, the key 440 of the configuration entry has to be set to the same value as the key 441 of the state entry. 443 An example can be seen in Appendix D: the "/routing-state/ 444 routing-instance" list has a single system-controlled entry whose 445 "name" key has the value "rtr0". This entry is configured by the 446 "/routing/routing-instance" entry whose "name" key is also "rtr0". 448 Deleting a user-controlled entry from the configuration list results 449 in the removal of the corresponding entry in the operational state 450 list. In contrast, if a system-controlled entry is deleted from the 451 configuration list, only the extra configuration specified in that 452 entry is removed but the corresponding operational state entry 453 remains in the list. 455 4.2. Features of Advanced Routers 457 The core routing data model attempts to address devices with 458 elementary routing functions as well as advanced routers. For simple 459 devices, some parts and options of the data model are not needed and 460 would represent unnecessary complications for the implementation. 461 Therefore, the core routing data model makes the advanced 462 functionality optional by means of two YANG features: 464 o "multiple-ribs" - indicates that the device supports multiple RIBs 465 per address family, routing protocols connected to non-default 466 RIBs, and RIBs configured as receivers of routes from other RIBs. 468 o "multipath-routes" - indicates that the device supports routes 469 with multiple next-hops. 471 See the "ietf-routing" module for details. 473 5. Basic Building Blocks 475 This section describes the essential components of the core routing 476 data model. 478 5.1. Routing Instance 480 Each routing instance in the core routing data model represents a 481 logical router. The exact semantics of this term are left to 482 implementations. For example, routing instances may be completely 483 isolated virtual routers or, alternatively, they may internally share 484 certain information. 486 A routing instance together with its operational state is represented 487 as an entry of the list "/routing-state/routing-instance", and 488 identified by a unique name. Configuration of that router instance 489 appears as an entry of the list "/routing/routing-instance". 491 An implementation MAY support multiple types of logical routers 492 simultaneously. Instances of all routing instance types are 493 organized as entries of the same flat "routing-instance" list. In 494 order to discriminate routing instances belonging to different types, 495 the "type" leaf is defined as a child of the "routing-instance" node. 497 An implementation MAY create one or more system-controlled routing 498 instances, and MAY also pose restrictions on allowed routing instance 499 types and on the number of supported instances for each type. For 500 example, a simple router implementation may support only one system- 501 controlled routing instance of the default type "rt:standard-routing- 502 instance" and may not allow creation of any user-controlled 503 instances. 505 Each network layer interface has to be assigned to one or more 506 routing instances in order to be able to participate in packet 507 forwarding, routing protocols and other operations of those routing 508 instances. The assignment is accomplished by placing a corresponding 509 (system- or user-controlled) entry in the list of routing instance 510 interfaces ("rt:interface"). The key of the list entry is the name 511 of a configured network layer interface, see the "ietf-interfaces" 512 module [YANG-IF]. 514 In YANG terms, the list of routing instance interfaces is modeled as 515 a "list" node rather than "leaf-list" in order to allow for adding, 516 via augmentation, other configuration or state data related to the 517 corresponding interface. 519 Implementations MAY specify additional rules for the assignment of 520 interfaces to routing instances. For example, it may be required 521 that the sets of interfaces assigned to different routing instances 522 be disjoint. 524 5.1.1. Parameters of IPv6 Routing Instance Interfaces 526 The module "ietf-ipv6-unicast-routing" augments the definition of the 527 data node "rt:interface", in both configuration and operational state 528 data, with definitions of the following variables as required by 529 [RFC4861], sec. 6.2.1: 531 o send-advertisements, 533 o max-rtr-adv-interval, 535 o min-rtr-adv-interval, 537 o managed-flag, 539 o other-config-flag, 541 o link-mtu, 543 o reachable-time, 545 o retrans-timer, 547 o cur-hop-limit, 549 o default-lifetime, 551 o prefix-list: a list of prefixes to be advertised. 553 The following parameters are associated with each prefix in the 554 list: 556 * valid-lifetime, 558 * on-link-flag, 560 * preferred-lifetime, 562 * autonomous-flag. 564 The definitions and descriptions of the above parameters can be found 565 in the module "ietf-ipv6-unicast-routing" (Section 9). 567 NOTES: 569 1. The "IsRouter" flag, which is also required by [RFC4861], is 570 implemented in the "ietf-ip" module [YANG-IP] (leaf "ip: 571 forwarding"). 573 2. The original specification [RFC4861] allows the implementations 574 to decide whether the "valid-lifetime" and "preferred-lifetime" 575 parameters remain the same in consecutive advertisements, or 576 decrement in real time. However, the latter behavior seems 577 problematic because the values might be reset again to the 578 (higher) configured values after a configuration is reloaded. 579 Moreover, no implementation is known to use the decrementing 580 behavior. The "ietf-ipv6-unicast-routing" module therefore 581 assumes the former behavior with constant values. 583 5.2. Route 585 Routes are basic elements of information in a routing system. The 586 core routing data model defines only the following minimal set of 587 route attributes: 589 o destination prefix: IP prefix specifying the set of destination 590 addresses for which the route may be used. This attribute is 591 mandatory. 593 o next-hop or action: outgoing interface, IP address of one or more 594 adjacent routers to which a packet should be forwarded, or a 595 special action such as discarding the packet. 597 The above list of route attributes suffices for a simple static 598 routing configuration. It is expected that future modules defining 599 routing protocols will add other route attributes such as metrics or 600 preferences. 602 Routes and their attributes are used both in configuration data, for 603 example as manually configured static routes, and in operational 604 state data, for example as entries in RIBs. 606 5.3. Routing Information Base (RIB) 608 A routing information base (RIB) is a list of routes complemented 609 with administrative data, namely: 611 o "source-protocol": type of the routing protocol from which the 612 route was originally obtained. 614 o "last-updated": the date and time when the route was last updated, 615 or inserted into the RIB. 617 Each RIB MUST contain only routes of one address family. In the data 618 model, address family is represented with an identity derived from 619 the "rt:address-family" base identity. 621 In the core routing data model, RIBs are operational state data 622 represented as entries of the list "/routing-state/ribs/rib". The 623 contents of RIBs are controlled and manipulated by routing protocol 624 operations which may result in route additions, removals and 625 modifications. This also includes manipulations via the "static" 626 and/or "direct" pseudo-protocols, see Section 5.4.1. 628 RIBs are global, which means that a RIB may be used by any or all 629 routing instances. However, an implementation MAY specify rules and 630 restrictions for sharing RIBs among routing instances. 632 Each routing instance has, for every supported address family, one 633 RIB selected as the so-called default RIB. This selection is 634 recorded in the list "default-rib". The role of default RIBs is 635 explained in Section 5.4. 637 Simple router implementations that do not advertise the feature 638 "multiple-ribs" will typically create one system-controlled RIB per 639 supported address family, and declare it as the default RIB (via a 640 system-controlled entry of the "default-rib" list). 642 5.3.1. Multiple RIBs per Address Family 644 More complex router implementations advertising the "multiple-ribs" 645 feature support multiple RIBs per address family that can be used for 646 policy routing and other purposes. Every RIB can then serve as a 647 source of routes for other RIBs of the same address family. To 648 achieve this, one or more recipient RIBs may be specified in the 649 configuration of the source RIB. Optionally, a route filter may be 650 configured for any or all recipient RIBs. Such a route filter then 651 selects and/or manipulates the routes that are passed between the 652 source and recipient RIB. 654 A RIB MUST NOT appear among its own recipient RIBs. 656 5.4. Routing Protocol 658 The core routing data model provides an open-ended framework for 659 defining multiple routing protocol instances within a routing 660 instance. Each routing protocol instance MUST be assigned a type, 661 which is an identity derived from the "rt:routing-protocol" base 662 identity. The core routing data model defines two identities for the 663 direct and static pseudo-protocols (Section 5.4.1). 665 Each routing protocol instance is connected to exactly one RIB for 666 each address family that the routing protocol instance supports. 667 Routes learned from the network by a routing protocol are normally 668 installed into the connected RIB(s) and, conversely, routes from the 669 connected RIB(s) are normally injected into the routing protocol. 670 However, routing protocol implementations MAY specify rules that 671 restrict this exchange of routes in either direction (or both 672 directions). 674 On devices supporting the "multiple-ribs" feature, any RIB (system- 675 controlled or user-controlled) may be connected to a routing protocol 676 instance by configuring a corresponding entry in the "connected-rib" 677 list. If such an entry is not configured for an address family, then 678 the default RIB MUST be used as the connected RIB for this address 679 family. 681 In addition, two independent route filters (see Section 5.5) may be 682 configured for each connected RIB to apply user-defined policies 683 controlling the exchange of routes in both directions between the 684 routing protocol instance and the connected RIB: 686 o import filter controls which routes are passed from the routing 687 protocol instance to the connected RIB, 689 o export filter controls which routes the routing protocol instance 690 receives from the connected RIB. 692 Note that the terms import and export are used from the viewpoint of 693 a RIB. 695 5.4.1. Routing Pseudo-Protocols 697 The core routing data model defines two special routing protocol 698 types - "direct" and "static". Both are in fact pseudo-protocols, 699 which means that they are confined to the local device and do not 700 exchange any routing information with neighboring routers. Routes 701 from both "direct" and "static" protocol instances are passed to the 702 connected RIB (subject to route filters, if any), but an exchange in 703 the opposite direction is not allowed. 705 Every routing instance MUST implement exactly one instance of the 706 "direct" pseudo-protocol type. It is the source of direct routes for 707 all configured address families. Direct routes are normally supplied 708 by the operating system kernel, based on the configuration of network 709 interface addresses, see Section 6.2. The "direct" pseudo-protocol 710 MUST always be connected to the default RIBs of all supported address 711 families. Unlike other routing protocol types, this connection 712 cannot be changed in the configuration. Direct routes MAY be 713 filtered before they appear in the default RIB. 715 A pseudo-protocol of the type "static" allows for specifying routes 716 manually. It MAY be configured in zero or multiple instances, 717 although a typical configuration will have exactly one instance per 718 routing instance. 720 Static routes are configured within the "static-routes" container, 721 see Figure 4. 723 +--rw static-routes 724 +--rw v4ur:ipv4 725 | +--rw v4ur:route* [id] 726 | +--rw v4ur:id 727 | +--rw v4ur:description? 728 | +--rw v4ur:destination-prefix 729 | +--rw (next-hop-options) 730 | +--:(special-next-hop) 731 | | +--rw v4ur:special-next-hop? 732 | +--:(simple-next-hop) 733 | | +--rw v4ur:next-hop? 734 | | +--rw v4ur:outgoing-interface? 735 | +--:(next-hop-list) {rt:multipath-routes}? 736 | +--rw v4ur:next-hop-list 737 | +--rw v4ur:next-hop* [id] 738 | +--rw v4ur:id 739 | +--rw v4ur:address? 740 | +--rw v4ur:outgoing-interface? 741 | +--rw v4ur:priority? 742 | +--rw v4ur:weight? 743 +--rw v6ur:ipv6 744 +--rw v6ur:route* [id] 745 +--rw v6ur:id 746 +--rw v6ur:description? 747 +--rw v6ur:destination-prefix 748 +--rw (next-hop-options) 749 +--:(special-next-hop) 750 | +--rw v6ur:special-next-hop? 751 +--:(simple-next-hop) 752 | +--rw v6ur:next-hop? 753 | +--rw v6ur:outgoing-interface? 754 +--:(next-hop-list) {rt:multipath-routes}? 755 +--rw v6ur:next-hop-list 756 +--rw v6ur:next-hop* [id] 757 +--rw v6ur:id 758 +--rw v6ur:address? 759 +--rw v6ur:outgoing-interface? 760 +--rw v6ur:priority? 761 +--rw v6ur:weight? 763 Figure 4: Structure of "static-routes" subtree. 765 5.4.2. Defining New Routing Protocols 767 It is expected that future YANG modules will create data models for 768 additional routing protocol types. Such a new module has to define 769 the protocol-specific configuration and state data, and it has to fit 770 it into the core routing framework in the following way: 772 o A new identity MUST be defined for the routing protocol and its 773 base identity MUST be set to "rt:routing-protocol", or to an 774 identity derived from "rt:routing-protocol". 776 o Additional route attributes MAY be defined, preferably in one 777 place by means of defining a YANG grouping. The new attributes 778 have to be inserted as state data by augmenting the definitions of 779 the nodes 781 /rt:ribs/rt:rib/rt:route 783 and 785 /rt:active-route/rt:output/rt:route, 787 and possibly other places in the configuration, state data and RPC 788 input or output. 790 o Configuration parameters and/or state data for the new protocol 791 can be defined by augmenting the "routing-protocol" data node 792 under both "/routing" and "/routing-state". 794 o Per-interface configuration, including activation of the routing 795 protocol on individual interfaces, can use references to entries 796 in the list of routing instance interfaces (rt:interface). 798 By using the "when" statement, the augmented configuration parameters 799 and state data specific to the new protocol SHOULD be made 800 conditional and valid only if the value of "rt:type" or "rt:source- 801 protocol" is equal to the new protocol's identity. It is also 802 RECOMMENDED that protocol-specific data nodes be encapsulated in 803 appropriately named containers. 805 The above steps are implemented by the example YANG module for the 806 RIP routing protocol in Appendix C. 808 5.5. Route Filter 810 The core routing data model provides a skeleton for defining route 811 filters that can be used to restrict the set of routes being 812 exchanged between a routing protocol instance and a connected RIB, or 813 between a source and a recipient RIB. Route filters may also 814 manipulate routes, i.e., add, delete, or modify their attributes. 816 Route filters are global, which means that a configured route filter 817 may be used by any or all routing instances. However, an 818 implementation MAY specify rules and restrictions for sharing route 819 filters among routing instances. 821 By itself, the route filtering framework defined in this document 822 allows for applying only two extreme routing policies which are 823 represented by the following pre-defined route filter types: 825 o "deny-all-route-filter": all routes are blocked, 827 o "allow-all-route-filter": all routes are permitted. 829 The latter type is equivalent to no route filter. 831 It is expected that more comprehensive route filtering frameworks 832 will be developed separately. 834 Each route filter is identified by a unique name. Its type MUST be 835 specified by the "type" identity reference - this opens the space for 836 multiple route filtering framework implementations. 838 5.6. RPC Operations 840 The "ietf-routing" module defines two RPC operations: 842 o active-route: query a routing instance for the active route that 843 is currently used for sending datagrams to a destination host 844 whose address is passed as an input parameter. 846 o route-count: retrieve the total number of entries in a RIB. 848 6. Interactions with Other YANG Modules 850 The semantics of the core routing data model also depend on several 851 configuration parameters that are defined in other YANG modules. 853 6.1. Module "ietf-interfaces" 855 The following boolean switch is defined in the "ietf-interfaces" YANG 856 module [YANG-IF]: 858 /if:interfaces/if:interface/if:enabled 860 If this switch is set to "false" for a network layer interface, 861 the device MUST behave exactly as if that interface was not 862 assigned to any routing instance at all. 864 6.2. Module "ietf-ip" 866 The following boolean switches are defined in the "ietf-ip" YANG 867 module [YANG-IP]: 869 /if:interfaces/if:interface/ip:ipv4/ip:enabled 871 If this switch is set to "false" for a network layer interface, 872 then all IPv4 routing functions related to that interface MUST be 873 disabled. 875 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 877 If this switch is set to "false" for a network layer interface, 878 then the forwarding of IPv4 datagrams to and from this interface 879 MUST be disabled. However, the interface may participate in other 880 IPv4 routing functions, such as routing protocols. 882 /if:interfaces/if:interface/ip:ipv6/ip:enabled 884 If this switch is set to "false" for a network layer interface, 885 then all IPv6 routing functions related to that interface MUST be 886 disabled. 888 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 890 If this switch is set to "false" for a network layer interface, 891 then the forwarding of IPv6 datagrams to and from this interface 892 MUST be disabled. However, the interface may participate in other 893 IPv6 routing functions, such as routing protocols. 895 In addition, the "ietf-ip" module allows for configuring IPv4 and 896 IPv6 addresses and network prefixes or masks on network layer 897 interfaces. Configuration of these parameters on an enabled 898 interface MUST result in an immediate creation of the corresponding 899 direct route. The destination prefix of this route is set according 900 to the configured IP address and network prefix/mask, and the 901 interface is set as the outgoing interface for that route. 903 7. Routing Management YANG Module 905 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 906 actual RFC number and all occurrences of the revision date below with 907 the date of RFC publication (and remove this note). 909 file "ietf-routing@2014-01-10.yang" 911 module ietf-routing { 913 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 915 prefix "rt"; 917 import ietf-yang-types { 918 prefix "yang"; 919 } 921 import ietf-interfaces { 922 prefix "if"; 923 } 925 organization 926 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 928 contact 929 "WG Web: 930 WG List: 932 WG Chair: David Kessens 933 935 WG Chair: Juergen Schoenwaelder 936 938 Editor: Ladislav Lhotka 939 "; 941 description 942 "This YANG module defines essential components for the management 943 of a routing subsystem. 945 Copyright (c) 2013 IETF Trust and the persons identified as 946 authors of the code. All rights reserved. 948 Redistribution and use in source and binary forms, with or 949 without modification, is permitted pursuant to, and subject to 950 the license terms contained in, the Simplified BSD License set 951 forth in Section 4.c of the IETF Trust's Legal Provisions 952 Relating to IETF Documents 953 (http://trustee.ietf.org/license-info). 955 This version of this YANG module is part of RFC XXXX; see the 956 RFC itself for full legal notices."; 958 revision 2014-01-10 { 959 description 960 "Initial revision."; 961 reference 962 "RFC XXXX: A YANG Data Model for Routing Management"; 963 } 965 /* Features */ 967 feature multiple-ribs { 968 description 969 "This feature indicates that the device supports multiple RIBS 970 per address family, and the framework for passing routes 971 between RIBs. 973 Devices that do not support this feature MUST provide exactly 974 one system-controlled RIB per supported address family. These 975 RIBs then appear as entries of the list 976 /routing-state/ribs/rib."; 977 } 979 feature multipath-routes { 980 description 981 "This feature indicates that the device supports multipath 982 routes that have a list of next-hops."; 983 } 985 /* Identities */ 987 identity address-family { 988 description 989 "Base identity from which identities describing address 990 families are derived."; 991 } 993 identity ipv4 { 994 base address-family; 995 description 996 "This identity represents IPv4 address family."; 997 } 998 identity ipv6 { 999 base address-family; 1000 description 1001 "This identity represents IPv6 address family."; 1002 } 1004 identity routing-instance-type { 1005 description 1006 "Base identity from which identities describing routing 1007 instance types are derived. 1009 It is primarily intended for discriminating among different 1010 types of logical routers or router virtualization."; 1011 } 1013 identity standard-routing-instance { 1014 base routing-instance-type; 1015 description 1016 "This identity represents a default routing instance."; 1017 } 1019 identity routing-protocol { 1020 description 1021 "Base identity from which routing protocol identities are 1022 derived."; 1023 } 1025 identity direct { 1026 base routing-protocol; 1027 description 1028 "Routing pseudo-protocol which provides routes to directly 1029 connected networks."; 1030 } 1032 identity static { 1033 base routing-protocol; 1034 description 1035 "Static routing pseudo-protocol."; 1036 } 1038 identity route-filter { 1039 description 1040 "Base identity from which all route filters are derived."; 1041 } 1043 identity deny-all-route-filter { 1044 base route-filter; 1045 description 1046 "Route filter that blocks all routes."; 1047 } 1049 identity allow-all-route-filter { 1050 base route-filter; 1051 description 1052 "Route filter that permits all routes."; 1053 } 1055 /* Type Definitions */ 1057 typedef routing-instance-ref { 1058 type leafref { 1059 path "/rt:routing/rt:routing-instance/rt:name"; 1060 } 1061 description 1062 "This type is used for leafs that reference a routing instance 1063 configuration."; 1064 } 1066 typedef routing-instance-state-ref { 1067 type leafref { 1068 path "/rt:routing-state/rt:routing-instance/rt:name"; 1069 } 1070 description 1071 "This type is used for leafs that reference state data of a 1072 routing instance."; 1073 } 1075 typedef rib-ref { 1076 type leafref { 1077 path "/rt:routing/rt:ribs/rt:rib/rt:name"; 1078 } 1079 description 1080 "This type is used for leafs that reference a RIB 1081 configuration."; 1082 } 1084 typedef rib-state-ref { 1085 type leafref { 1086 path "/rt:routing-state/rt:ribs/rt:rib/rt:name"; 1087 } 1088 description 1089 "This type is used for leafs that reference a RIB in state 1090 data."; 1091 } 1093 typedef route-filter-ref { 1094 type leafref { 1095 path "/rt:routing/rt:route-filters/rt:route-filter/rt:name"; 1096 } 1097 description 1098 "This type is used for leafs that reference a route filter 1099 configuration."; 1100 } 1102 typedef route-filter-state-ref { 1103 type leafref { 1104 path "/rt:routing-state/rt:route-filters/rt:route-filter/" 1105 + "rt:name"; 1106 } 1107 description 1108 "This type is used for leafs that reference a route filter in 1109 state data."; 1110 } 1112 /* Groupings */ 1114 grouping address-family { 1115 description 1116 "This grouping provides a leaf identifying an address 1117 family."; 1118 leaf address-family { 1119 type identityref { 1120 base address-family; 1121 } 1122 mandatory "true"; 1123 description 1124 "Address family."; 1125 } 1126 } 1128 grouping state-entry-id { 1129 description 1130 "This grouping defines a unique identifier for entries in 1131 several operational state lists."; 1132 leaf id { 1133 type uint64; 1134 description 1135 "Unique numerical identifier of a list entry in operational 1136 state. It may be used by protocols or tools that inspect 1137 and/or manipulate operational state data and prefer 1138 fixed-size integers as list entry handles. 1140 These identifiers are always ephemeral, i.e., they may 1141 change after a reboot."; 1143 } 1144 } 1146 grouping router-id { 1147 description 1148 "This grouping provides the definition of router ID."; 1149 leaf router-id { 1150 type yang:dotted-quad; 1151 description 1152 "Router ID - 32-bit number in the form of a dotted quad. Some 1153 protocols use this parameter for identifying a router to its 1154 neighbors."; 1155 } 1156 } 1158 grouping outgoing-interface { 1159 description 1160 "This grouping defines the outgoing interface for use in 1161 next-hops."; 1162 leaf outgoing-interface { 1163 type leafref { 1164 path "/routing-state/routing-instance/interfaces/interface/" 1165 + "name"; 1166 } 1167 description 1168 "Name of the outgoing interface."; 1169 } 1170 } 1172 grouping special-next-hop { 1173 description 1174 "This grouping provides the leaf for specifying special 1175 next-hop options."; 1176 leaf special-next-hop { 1177 type enumeration { 1178 enum blackhole { 1179 description 1180 "Silently discard the packet."; 1181 } 1182 enum unreachable { 1183 description 1184 "Discard the packet and notify the sender with an error 1185 message indicating that the destination host is 1186 unreachable."; 1187 } 1188 enum prohibit { 1189 description 1190 "Discard the packet and notify the sender with an error 1191 message indicating that the communication is 1192 administratively prohibited."; 1193 } 1194 enum receive { 1195 description 1196 "The packet will be received by the local network 1197 device."; 1198 } 1199 } 1200 description 1201 "Special next-hop options."; 1202 } 1203 } 1205 grouping next-hop-classifiers { 1206 description 1207 "This grouping provides two next-hop classifiers."; 1208 leaf priority { 1209 type enumeration { 1210 enum primary { 1211 value "1"; 1212 description 1213 "Primary next-hop."; 1214 } 1215 enum backup { 1216 value "2"; 1217 description 1218 "Backup next-hop."; 1219 } 1220 } 1221 default "primary"; 1222 description 1223 "Simple priority for distinguishing between primary and 1224 backup next-hops. 1226 Backup next-hops are used if and only if no primary 1227 next-hops are reachable."; 1228 } 1229 leaf weight { 1230 type uint8; 1231 must ". = 0 or not(../../next-hop/weight = 0)" { 1232 error-message "Illegal combination of zero and non-zero " 1233 + "next-hop weights."; 1234 description 1235 "Next-hop weights must be either all zero (equal 1236 load-balancing) or all non-zero."; 1237 } 1238 default "0"; 1239 description 1240 "This parameter specifies the weight of the next-hop for load 1241 balancing. The number specifies the relative fraction of the 1242 traffic that will use the corresponding next-hop. 1244 The default value of 0 represents equal load-balancing. 1246 If both primary and backup next-hops are present, then the 1247 weights for each priority level are used separately."; 1248 } 1249 } 1251 grouping next-hop-content { 1252 description 1253 "Generic parameters of next-hops in routes."; 1254 choice next-hop-options { 1255 mandatory "true"; 1256 description 1257 "Options for expressing the next-hop in routes."; 1258 case special-next-hop { 1259 uses special-next-hop; 1260 } 1261 case simple-next-hop { 1262 uses outgoing-interface; 1263 } 1264 case next-hop-list { 1265 if-feature multipath-routes; 1266 container next-hop-list { 1267 list next-hop { 1268 key "id"; 1269 description 1270 "An entry of a next-hop list."; 1271 uses state-entry-id; 1272 uses outgoing-interface; 1273 uses next-hop-classifiers; 1274 } 1275 } 1276 } 1277 } 1278 } 1280 grouping route-metadata { 1281 description 1282 "Route metadata."; 1283 leaf source-protocol { 1284 type identityref { 1285 base routing-protocol; 1286 } 1287 mandatory "true"; 1288 description 1289 "Type of the routing protocol from which the route 1290 originated."; 1291 } 1292 leaf last-updated { 1293 type yang:date-and-time; 1294 description 1295 "Time stamp of the last modification of the route. If the 1296 route was never modified, it is the time when the route was 1297 inserted into the RIB."; 1298 } 1299 } 1301 /* Operational state data */ 1303 container routing-state { 1304 config "false"; 1305 description 1306 "Operational state of the routing subsystem."; 1307 list routing-instance { 1308 key "name"; 1309 unique "id"; 1310 description 1311 "Each list entry is a container for operational state data of 1312 a routing instance. 1314 An implementation MAY create one or more system-controlled 1315 instances, other user-controlled instances MAY be created by 1316 configuration."; 1317 leaf name { 1318 type string; 1319 description 1320 "The name of the routing instance. 1322 For system-controlled instances the name is persistent, 1323 i.e., it SHOULD NOT change across reboots."; 1324 } 1325 uses state-entry-id { 1326 refine "id" { 1327 mandatory "true"; 1328 } 1329 } 1330 leaf type { 1331 type identityref { 1332 base routing-instance-type; 1333 } 1334 default "rt:standard-routing-instance"; 1335 description 1336 "The routing instance type, primarily intended for 1337 discriminating among different types of logical routers, 1338 route virtualization, master-slave arrangements etc., 1339 while keeping all routing instances in the same flat 1340 list."; 1341 } 1342 uses router-id { 1343 description 1344 "Global router ID. 1346 An implementation may choose a value if none is 1347 configured. 1349 Routing protocols that use router ID MAY override this 1350 global parameter."; 1351 } 1352 container default-ribs { 1353 description 1354 "Default RIBs used by the routing instance."; 1355 list default-rib { 1356 key "address-family"; 1357 description 1358 "Each list entry specifies the default RIB for one 1359 address family. 1361 The default RIB is operationally connected to all 1362 routing protocols for which a connected RIB has not been 1363 explicitly configured. 1365 The 'direct' pseudo-protocol is always connected to the 1366 default RIBs."; 1367 uses address-family; 1368 leaf rib-name { 1369 type rib-state-ref; 1370 mandatory "true"; 1371 description 1372 "Name of an existing RIB to be used as the default RIB 1373 for the given routing instance and address family."; 1374 } 1375 } 1376 } 1377 container interfaces { 1378 description 1379 "Network layer interfaces belonging to the routing 1380 instance."; 1381 list interface { 1382 key "name"; 1383 description 1384 "List of network layer interfaces assigned to the routing 1385 instance."; 1386 leaf name { 1387 type if:interface-state-ref; 1388 description 1389 "A reference to the name of a configured network layer 1390 interface."; 1391 } 1392 } 1393 } 1394 container routing-protocols { 1395 description 1396 "Container for the list of routing protocol instances."; 1397 list routing-protocol { 1398 key "name"; 1399 description 1400 "Operational state of a routing protocol instance. 1402 An implementation MUST provide exactly one 1403 system-controlled instance of the type 'direct'. Other 1404 instances MAY be created by configuration."; 1405 leaf name { 1406 type string; 1407 description 1408 "The name of the routing protocol instance. 1410 For system-controlled instances this name is 1411 persistent, i.e., it SHOULD NOT change across 1412 reboots."; 1413 } 1414 leaf type { 1415 type identityref { 1416 base routing-protocol; 1417 } 1418 mandatory "true"; 1419 description 1420 "Type of the routing protocol."; 1421 } 1422 container connected-ribs { 1423 description 1424 "Container for connected RIBs."; 1425 list connected-rib { 1426 key "rib-name"; 1427 description 1428 "List of RIBs to which the routing protocol instance 1429 is connected (at most one RIB per address 1430 family)."; 1432 leaf rib-name { 1433 type rib-state-ref; 1434 description 1435 "Name of an existing RIB."; 1436 } 1437 leaf import-filter { 1438 type route-filter-state-ref; 1439 description 1440 "Reference to a route filter that is used for 1441 filtering routes passed from this routing protocol 1442 instance to the RIB specified by the 'rib-name' 1443 sibling node. 1445 If this leaf is not present, the behavior is 1446 protocol-specific, but typically it means that all 1447 routes are accepted."; 1448 } 1449 leaf export-filter { 1450 type route-filter-state-ref; 1451 description 1452 "Reference to a route filter that is used for 1453 filtering routes passed from the RIB specified by 1454 the 'rib-name' sibling node to this routing 1455 protocol instance. 1457 If this leaf is not present, the behavior is 1458 protocol-specific - typically it means that all 1459 routes are accepted. 1461 The 'direct' and 'static' pseudo-protocols accept 1462 no routes from any RIB."; 1463 } 1464 } 1465 } 1466 } 1467 } 1468 } 1469 container ribs { 1470 description 1471 "Container for RIBs."; 1472 list rib { 1473 key "name"; 1474 unique "id"; 1475 description 1476 "Each entry represents a RIB identified by the 'name' key. 1477 All routes in a RIB MUST belong to the same address 1478 family. 1480 The server MUST provide a system-controlled default RIB 1481 for each address family, and MAY provide other 1482 system-controlled RIBs. Additional RIBs MAY be created in 1483 the configuration."; 1484 leaf name { 1485 type string; 1486 description 1487 "The name of the RIB."; 1488 } 1489 uses state-entry-id { 1490 refine "id" { 1491 mandatory "true"; 1492 } 1493 } 1494 uses address-family; 1495 container routes { 1496 description 1497 "Current contents of the RIB."; 1498 list route { 1499 key "id"; 1500 description 1501 "A RIB route entry. This data node MUST be augmented 1502 with information specific for routes of each address 1503 family."; 1504 uses state-entry-id; 1505 uses next-hop-content; 1506 uses route-metadata; 1507 } 1508 } 1509 container recipient-ribs { 1510 if-feature multiple-ribs; 1511 description 1512 "Container for recipient RIBs."; 1513 list recipient-rib { 1514 key "rib-name"; 1515 description 1516 "List of RIBs that receive routes from this RIB."; 1517 leaf rib-name { 1518 type rib-state-ref; 1519 description 1520 "The name of the recipient RIB."; 1521 } 1522 leaf filter { 1523 type route-filter-state-ref; 1524 description 1525 "A route filter which is applied to the routes passed 1526 to the recipient RIB."; 1527 } 1529 } 1530 } 1531 } 1532 } 1533 container route-filters { 1534 description 1535 "Container for route filters."; 1536 list route-filter { 1537 key "name"; 1538 description 1539 "Route filters are used for filtering and/or manipulating 1540 routes that are passed between a routing protocol and a 1541 RIB and vice versa, or between two RIBs. 1543 It is expected that other modules augment this list with 1544 contents specific for a particular route filter type."; 1545 leaf name { 1546 type string; 1547 description 1548 "The name of the route filter."; 1549 } 1550 leaf type { 1551 type identityref { 1552 base route-filter; 1553 } 1554 mandatory "true"; 1555 description 1556 "Type of the route-filter - an identity derived from the 1557 'route-filter' base identity."; 1558 } 1559 } 1560 } 1561 } 1563 /* Configuration Data */ 1565 container routing { 1566 description 1567 "Configuration parameters for the routing subsystem."; 1568 list routing-instance { 1569 key "name"; 1570 description 1571 "Configuration of a routing instance."; 1572 leaf name { 1573 type string; 1574 description 1575 "The name of the routing instance. 1577 For system-controlled entries, the value of this leaf must 1578 be the same as the name of the corresponding entry in 1579 state data. 1581 For user-controlled entries, an arbitrary name can be 1582 used."; 1583 } 1584 leaf type { 1585 type identityref { 1586 base routing-instance-type; 1587 } 1588 default "rt:standard-routing-instance"; 1589 description 1590 "The type of the routing instance."; 1591 } 1592 leaf enabled { 1593 type boolean; 1594 default "true"; 1595 description 1596 "Enable/disable the routing instance. 1598 If this parameter is false, the parent routing instance is 1599 disabled and does not appear in operational state data, 1600 despite any other configuration that might be present."; 1601 } 1602 uses router-id { 1603 description 1604 "Configuration of the global router ID."; 1605 } 1606 leaf description { 1607 type string; 1608 description 1609 "Textual description of the routing instance."; 1610 } 1611 container default-ribs { 1612 if-feature multiple-ribs; 1613 description 1614 "Configuration of the default RIBs used by the routing 1615 instance. 1617 The default RIB for an addressed family if by default 1618 connected to all routing protocol instances supporting 1619 that address family, and always receives direct routes."; 1620 list default-rib { 1621 must "address-family=/routing/ribs/rib[name=current()/" 1622 + "rib-name]/address-family" { 1623 error-message "Address family mismatch."; 1624 description 1625 "The entry's address family MUST match that of the 1626 referenced RIB."; 1627 } 1628 key "address-family"; 1629 description 1630 "Each list entry configures the default RIB for one 1631 address family."; 1632 uses address-family; 1633 leaf rib-name { 1634 type string; 1635 mandatory "true"; 1636 description 1637 "Name of an existing RIB to be used as the default RIB 1638 for the given routing instance and address family."; 1639 } 1640 } 1641 } 1642 container interfaces { 1643 description 1644 "Configuration of the routing instance's interfaces."; 1645 list interface { 1646 key "name"; 1647 description 1648 "List of network layer interfaces assigned to the routing 1649 instance."; 1650 leaf name { 1651 type if:interface-ref; 1652 description 1653 "A reference to the name of a configured network layer 1654 interface."; 1655 } 1656 } 1657 } 1658 container routing-protocols { 1659 description 1660 "Configuration of routing protocol instances."; 1661 list routing-protocol { 1662 key "name"; 1663 description 1664 "Each entry contains configuration of a routing protocol 1665 instance."; 1666 leaf name { 1667 type string; 1668 description 1669 "An arbitrary name of the routing protocol instance."; 1670 } 1671 leaf description { 1672 type string; 1673 description 1674 "Textual description of the routing protocol 1675 instance."; 1676 } 1677 leaf enabled { 1678 type boolean; 1679 default "true"; 1680 description 1681 "Enable/disable the routing protocol instance. 1683 If this parameter is false, the parent routing 1684 protocol instance is disabled and does not appear in 1685 operational state data, despite any other 1686 configuration that might be present."; 1687 } 1688 leaf type { 1689 type identityref { 1690 base routing-protocol; 1691 } 1692 mandatory "true"; 1693 description 1694 "Type of the routing protocol - an identity derived 1695 from the 'routing-protocol' base identity."; 1696 } 1697 container connected-ribs { 1698 if-feature multiple-ribs; 1699 description 1700 "Configuration of connected RIBs."; 1701 list connected-rib { 1702 must "not(/routing/ribs/rib[name=current()/" 1703 + "preceding-sibling::connected-rib/" 1704 + "rib-name and address-family=/routing/ribs/" 1705 + "rib[name=current()/rib-name]/address-family])" { 1706 error-message 1707 "Duplicate address family for connected RIBs."; 1708 description 1709 "For each address family, there MUST NOT be more 1710 than one connected RIB."; 1711 } 1712 key "rib-name"; 1713 description 1714 "List of RIBs to which the routing protocol instance 1715 is connected (at most one RIB per address family). 1717 If no connected RIB is configured for an address 1718 family, the routing protocol is connected to the 1719 default RIB for that address family."; 1720 leaf rib-name { 1721 type rib-ref; 1722 must "../../../type != 'rt:direct' or " 1723 + "../../../../../default-ribs/ " 1724 + "default-rib/rib-name=." { 1725 error-message "The 'direct' protocol can be " 1726 + "connected only to a default RIB."; 1727 description 1728 "For the 'direct' pseudo-protocol, the connected 1729 RIB must always be a default RIB."; 1730 } 1731 description 1732 "Name of an existing RIB."; 1733 } 1734 leaf import-filter { 1735 type route-filter-ref; 1736 description 1737 "Configuration of import filter."; 1738 } 1739 leaf export-filter { 1740 type route-filter-ref; 1741 description 1742 "Configuration of export filter."; 1743 } 1744 } 1745 } 1746 container static-routes { 1747 when "../type='rt:static'" { 1748 description 1749 "This container is only valid for the 'static' 1750 routing protocol."; 1751 } 1752 description 1753 "Configuration of the 'static' pseudo-protocol. 1755 Address family specific modules augment this node with 1756 their lists of routes."; 1757 } 1758 } 1759 } 1760 } 1761 container ribs { 1762 description 1763 "Configured RIBs."; 1764 list rib { 1765 key "name"; 1766 description 1767 "Each entry represents a configured RIB identified by the 1768 'name' key. 1770 Entries having the same key as a system-controlled entry 1771 of the list /routing-state/ribs/rib are used for 1772 configuring parameters of that entry. Other entries define 1773 additional user-controlled RIBs."; 1774 leaf name { 1775 type string; 1776 description 1777 "The name of the RIB. 1779 For system-controlled entries, the value of this leaf 1780 must be the same as the name of the corresponding entry 1781 in state data. 1783 For user-controlled entries, an arbitrary name can be 1784 used."; 1785 } 1786 uses address-family; 1787 leaf description { 1788 type string; 1789 description 1790 "Textual description of the RIB."; 1791 } 1792 container recipient-ribs { 1793 if-feature multiple-ribs; 1794 description 1795 "Configuration of recipient RIBs."; 1796 list recipient-rib { 1797 must "rib-name != ../../name" { 1798 error-message 1799 "Source and recipient RIBs are identical."; 1800 description 1801 "A RIB MUST NOT appear among its recipient RIBs."; 1802 } 1803 must "/routing/ribs/rib[name=current()/rib-name]/" 1804 + "address-family=../../address-family" { 1805 error-message "Address family mismatch."; 1806 description 1807 "Address family of the recipient RIB MUST match that 1808 of the source RIB."; 1809 } 1810 key "rib-name"; 1811 description 1812 "Each entry configures a recipient RIB."; 1813 leaf rib-name { 1814 type rib-ref; 1815 description 1816 "The name of the recipient RIB."; 1817 } 1818 leaf filter { 1819 type route-filter-ref; 1820 description 1821 "A route filter which is applied to the routes passed 1822 to the recipient RIB."; 1823 } 1824 } 1825 } 1826 } 1827 } 1828 container route-filters { 1829 description 1830 "Configuration of route filters."; 1831 list route-filter { 1832 key "name"; 1833 description 1834 "Each entry configures a named route filter."; 1835 leaf name { 1836 type string; 1837 description 1838 "The name of the route filter."; 1839 } 1840 leaf description { 1841 type string; 1842 description 1843 "Textual description of the route filter."; 1844 } 1845 leaf type { 1846 type identityref { 1847 base route-filter; 1848 } 1849 mandatory "true"; 1850 description 1851 "Type of the route filter.."; 1852 } 1853 } 1854 } 1855 } 1857 /* RPC methods */ 1859 rpc active-route { 1860 description 1861 "Return the active route that a routing-instance uses for 1862 sending packets to a destination address."; 1863 input { 1864 leaf routing-instance-name { 1865 type routing-instance-state-ref; 1866 mandatory "true"; 1867 description 1868 "Name of the routing instance whose forwarding information 1869 base is being queried. 1871 If the routing instance with name equal to the value of 1872 this parameter doesn't exist, then this operation SHALL 1873 fail with error-tag 'data-missing' and error-app-tag 1874 'routing-instance-not-found'."; 1875 } 1876 container destination-address { 1877 description 1878 "Network layer destination address. 1880 Address family specific modules MUST augment this 1881 container with a leaf named 'address'."; 1882 uses address-family; 1883 } 1884 } 1885 output { 1886 container route { 1887 description 1888 "The active route for the specified destination. 1890 If the routing instance has no active route for the 1891 destination address, no output is returned - the server 1892 SHALL send an containing a single element 1893 . 1895 Address family specific modules MUST augment this list 1896 with appropriate route contents."; 1897 uses address-family; 1898 uses next-hop-content; 1899 uses route-metadata; 1900 } 1901 } 1902 } 1904 rpc route-count { 1905 description 1906 "Return the current number of routes in a RIB."; 1907 input { 1908 leaf rib-name { 1909 type rib-state-ref; 1910 mandatory "true"; 1911 description 1912 "Name of the RIB. 1914 If the RIB with name equal to the value of this parameter 1915 doesn't exist, then this operation SHALL fail with 1916 error-tag 'data-missing' and error-app-tag 1917 'rib-not-found'."; 1918 } 1919 } 1920 output { 1921 leaf number-of-routes { 1922 type uint64; 1923 mandatory "true"; 1924 description 1925 "Number of routes in the RIB."; 1926 } 1927 } 1928 } 1929 } 1931 1933 8. IPv4 Unicast Routing Management YANG Module 1935 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1936 actual RFC number and all occurrences of the revision date below with 1937 the date of RFC publication (and remove this note). 1939 file "ietf-ipv4-unicast-routing@2014-01-10.yang" 1941 module ietf-ipv4-unicast-routing { 1943 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1945 prefix "v4ur"; 1947 import ietf-routing { 1948 prefix "rt"; 1949 } 1951 import ietf-inet-types { 1952 prefix "inet"; 1953 } 1955 organization 1956 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1958 contact 1959 "WG Web: 1960 WG List: 1962 WG Chair: David Kessens 1963 1965 WG Chair: Juergen Schoenwaelder 1966 1968 Editor: Ladislav Lhotka 1969 "; 1971 description 1972 "This YANG module augments the 'ietf-routing' module with basic 1973 configuration and operational state data for IPv4 unicast 1974 routing. 1976 Copyright (c) 2013 IETF Trust and the persons identified as 1977 authors of the code. All rights reserved. 1979 Redistribution and use in source and binary forms, with or 1980 without modification, is permitted pursuant to, and subject to 1981 the license terms contained in, the Simplified BSD License set 1982 forth in Section 4.c of the IETF Trust's Legal Provisions 1983 Relating to IETF Documents 1984 (http://trustee.ietf.org/license-info). 1986 This version of this YANG module is part of RFC XXXX; see the 1987 RFC itself for full legal notices."; 1989 revision 2014-01-10 { 1990 description 1991 "Initial revision."; 1992 reference 1993 "RFC XXXX: A YANG Data Model for Routing Management"; 1994 } 1996 /* Identities */ 1998 identity ipv4-unicast { 1999 base rt:ipv4; 2000 description 2001 "This identity represents the IPv4 unicast address family."; 2002 } 2004 /* Operational state data */ 2006 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2007 when "../../rt:address-family = 'v4ur:ipv4-unicast'" { 2008 description 2009 "This augment is valid only for IPv4 unicast."; 2010 } 2011 description 2012 "This leaf augments an IPv4 unicast route."; 2013 leaf destination-prefix { 2014 type inet:ipv4-prefix; 2015 description 2016 "IPv4 destination prefix."; 2017 } 2018 } 2020 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 2021 + "rt:next-hop-options/rt:simple-next-hop" { 2022 when "../../rt:address-family = 'v4ur:ipv4-unicast'" { 2023 description 2024 "This augment is valid only for IPv4 unicast."; 2025 } 2026 description 2027 "This leaf augments the 'simple-next-hop' case of IPv4 unicast 2028 routes."; 2030 leaf next-hop { 2031 type inet:ipv4-address; 2032 description 2033 "IPv4 address of the next-hop."; 2034 } 2035 } 2037 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 2038 + "rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/" 2039 + "rt:next-hop" { 2040 when "../../../../rt:address-family = 'v4ur:ipv4-unicast'" { 2041 description 2042 "This augment is valid only for IPv4 unicast."; 2043 } 2044 if-feature rt:multipath-routes; 2045 description 2046 "This leaf augments the 'next-hop-list' case of IPv4 unicast 2047 routes."; 2048 leaf address { 2049 type inet:ipv4-address; 2050 description 2051 "IPv4 address of the next-hop."; 2052 } 2053 } 2055 /* Configuration data */ 2057 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2058 + "rt:routing-protocol/rt:static-routes" { 2059 description 2060 "This augment defines the configuration of the 'static' 2061 pseudo-protocol with data specific to IPv4 unicast."; 2062 container ipv4 { 2063 description 2064 "Configuration of a 'static' pseudo-protocol instance 2065 consists of a list of routes."; 2066 list route { 2067 key "id"; 2068 ordered-by "user"; 2069 description 2070 "A user-ordered list of static routes."; 2071 leaf id { 2072 type uint32 { 2073 range "1..max"; 2074 } 2075 description 2076 "Unique numeric identifier of the route. 2078 This value is unrelated to system-assigned 'id' 2079 parameters of routes in RIBs."; 2080 } 2081 leaf description { 2082 type string; 2083 description 2084 "Textual description of the route."; 2085 } 2086 leaf destination-prefix { 2087 type inet:ipv4-prefix; 2088 mandatory "true"; 2089 description 2090 "IPv4 destination prefix."; 2091 } 2092 choice next-hop-options { 2093 mandatory "true"; 2094 description 2095 "Options for expressing the next-hop in static routes."; 2096 case special-next-hop { 2097 uses rt:special-next-hop; 2098 } 2099 case simple-next-hop { 2100 leaf next-hop { 2101 type inet:ipv4-address; 2102 description 2103 "IPv4 address of the next-hop."; 2104 } 2105 leaf outgoing-interface { 2106 type leafref { 2107 path "../../../../../../rt:interfaces/rt:interface/" 2108 + "rt:name"; 2109 } 2110 description 2111 "Name of the outgoing interface. 2113 Only interfaces configured for the ancestor routing 2114 instance can be given."; 2115 } 2116 } 2117 case next-hop-list { 2118 if-feature rt:multipath-routes; 2119 container next-hop-list { 2120 list next-hop { 2121 key "id"; 2122 description 2123 "An entry of a next-hop list."; 2124 leaf id { 2125 type uint32; 2126 description 2127 "Unique numeric identifier of the entry. 2129 This value is unrelated to system-assigned 'id' 2130 parameters of next-hops in RIBs."; 2131 } 2132 leaf address { 2133 type inet:ipv4-address; 2134 description 2135 "IPv4 address of the next-hop."; 2136 } 2137 leaf outgoing-interface { 2138 type leafref { 2139 path "../../../../../../../../rt:interfaces/" 2140 + "rt:interface/rt:name"; 2141 } 2142 description 2143 "Name of the outgoing interface. 2145 Only interfaces configured for the ancestor 2146 routing instance can be given."; 2147 } 2148 uses rt:next-hop-classifiers; 2149 } 2150 } 2151 } 2152 } 2153 } 2154 } 2155 } 2157 /* RPC methods */ 2159 augment "/rt:active-route/rt:input/rt:destination-address" { 2160 when "rt:address-family='v4ur:ipv4-unicast'" { 2161 description 2162 "This augment is valid only for IPv4 unicast."; 2163 } 2164 description 2165 "This leaf augments the 'rt:destination-address' parameter of 2166 the 'rt:active-route' operation."; 2167 leaf address { 2168 type inet:ipv4-address; 2169 description 2170 "IPv4 destination address."; 2171 } 2172 } 2173 augment "/rt:active-route/rt:output/rt:route" { 2174 when "rt:address-family='v4ur:ipv4-unicast'" { 2175 description 2176 "This augment is valid only for IPv4 unicast."; 2177 } 2178 description 2179 "This leaf augments the reply to the 'rt:active-route' 2180 operation."; 2181 leaf destination-prefix { 2182 type inet:ipv4-prefix; 2183 description 2184 "IPv4 destination prefix."; 2185 } 2186 } 2188 augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/" 2189 + "rt:simple-next-hop" { 2190 when "rt:address-family='v4ur:ipv4-unicast'" { 2191 description 2192 "This augment is valid only for IPv4 unicast."; 2193 } 2194 description 2195 "This leaf augments the 'simple-next-hop' case in the reply to 2196 the 'rt:active-route' operation."; 2197 leaf next-hop { 2198 type inet:ipv4-address; 2199 description 2200 "IPv4 address of the next-hop."; 2201 } 2202 } 2204 augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/" 2205 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 2206 when "../../rt:address-family='v4ur:ipv4-unicast'" { 2207 description 2208 "This augment is valid only for IPv4 unicast."; 2209 } 2210 if-feature rt:multipath-routes; 2211 description 2212 "This leaf augments the 'next-hop-list' case in the reply to 2213 the 'rt:active-route' operation."; 2214 leaf address { 2215 type inet:ipv4-address; 2216 description 2217 "IPv4 address of the next-hop."; 2218 } 2219 } 2220 } 2221 2223 9. IPv6 Unicast Routing Management YANG Module 2225 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2226 actual RFC number and all occurrences of the revision date below with 2227 the date of RFC publication (and remove this note). 2229 file "ietf-ipv6-unicast-routing@2014-01-10.yang" 2231 module ietf-ipv6-unicast-routing { 2233 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 2235 prefix "v6ur"; 2237 import ietf-routing { 2238 prefix "rt"; 2239 } 2241 import ietf-inet-types { 2242 prefix "inet"; 2243 } 2245 import ietf-interfaces { 2246 prefix "if"; 2247 } 2249 import ietf-ip { 2250 prefix "ip"; 2251 } 2253 organization 2254 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 2256 contact 2257 "WG Web: 2258 WG List: 2260 WG Chair: David Kessens 2261 2263 WG Chair: Juergen Schoenwaelder 2264 2266 Editor: Ladislav Lhotka 2267 "; 2269 description 2270 "This YANG module augments the 'ietf-routing' module with basic 2271 configuration and operational state data for IPv6 unicast 2272 routing. 2274 Copyright (c) 2013 IETF Trust and the persons identified as 2275 authors of the code. All rights reserved. 2277 Redistribution and use in source and binary forms, with or 2278 without modification, is permitted pursuant to, and subject to 2279 the license terms contained in, the Simplified BSD License set 2280 forth in Section 4.c of the IETF Trust's Legal Provisions 2281 Relating to IETF Documents 2282 (http://trustee.ietf.org/license-info). 2284 This version of this YANG module is part of RFC XXXX; see the 2285 RFC itself for full legal notices."; 2287 revision 2014-01-10 { 2288 description 2289 "Initial revision."; 2290 reference 2291 "RFC XXXX: A YANG Data Model for Routing Management"; 2292 } 2294 /* Identities */ 2296 identity ipv6-unicast { 2297 base rt:ipv6; 2298 description 2299 "This identity represents the IPv6 unicast address family."; 2300 } 2302 /* Operational state data */ 2304 augment "/rt:routing-state/rt:routing-instance/rt:interfaces/" 2305 + "rt:interface" { 2306 description 2307 "IPv6-specific parameters of router interfaces."; 2308 container ipv6-router-advertisements { 2309 description 2310 "Parameters of IPv6 Router Advertisements."; 2311 leaf send-advertisements { 2312 type boolean; 2313 default "false"; 2314 description 2315 "A flag indicating whether or not the router sends periodic 2316 Router Advertisements and responds to Router 2317 Solicitations."; 2318 reference 2319 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2320 AdvSendAdvertisements."; 2321 } 2322 leaf max-rtr-adv-interval { 2323 type uint16 { 2324 range "4..1800"; 2325 } 2326 units "seconds"; 2327 default "600"; 2328 description 2329 "The maximum time allowed between sending unsolicited 2330 multicast Router Advertisements from the interface."; 2331 reference 2332 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2333 MaxRtrAdvInterval."; 2334 } 2335 leaf min-rtr-adv-interval { 2336 type uint16 { 2337 range "3..1350"; 2338 } 2339 units "seconds"; 2340 description 2341 "The minimum time allowed between sending unsolicited 2342 multicast Router Advertisements from the interface. 2344 The default value to be used operationally if this leaf is 2345 not configured is determined as follows: 2347 - if max-rtr-adv-interval >= 9 seconds, the default value 2348 is 0.33 * max-rtr-adv-interval; 2350 - otherwise it is 0.75 * max-rtr-adv-interval."; 2351 reference 2352 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2353 MinRtrAdvInterval."; 2354 } 2355 leaf managed-flag { 2356 type boolean; 2357 default "false"; 2358 description 2359 "The boolean value to be placed in the 'Managed address 2360 configuration' flag field in the Router Advertisement."; 2361 reference 2362 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2363 AdvManagedFlag."; 2364 } 2365 leaf other-config-flag { 2366 type boolean; 2367 default "false"; 2368 description 2369 "The boolean value to be placed in the 'Other 2370 configuration' flag field in the Router Advertisement."; 2371 reference 2372 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2373 AdvOtherConfigFlag."; 2374 } 2375 leaf link-mtu { 2376 type uint32; 2377 default "0"; 2378 description 2379 "The value to be placed in MTU options sent by the router. 2380 A value of zero indicates that no MTU options are sent."; 2381 reference 2382 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2383 AdvLinkMTU."; 2384 } 2385 leaf reachable-time { 2386 type uint32 { 2387 range "0..3600000"; 2388 } 2389 units "milliseconds"; 2390 default "0"; 2391 description 2392 "The value to be placed in the Reachable Time field in the 2393 Router Advertisement messages sent by the router. The 2394 value zero means unspecified (by this router)."; 2395 reference 2396 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2397 AdvReachableTime."; 2398 } 2399 leaf retrans-timer { 2400 type uint32; 2401 units "milliseconds"; 2402 default "0"; 2403 description 2404 "The value to be placed in the Retrans Timer field in the 2405 Router Advertisement messages sent by the router. The 2406 value zero means unspecified (by this router)."; 2407 reference 2408 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2409 AdvRetransTimer."; 2410 } 2411 leaf cur-hop-limit { 2412 type uint8; 2413 default "64"; 2414 description 2415 "The default value to be placed in the Cur Hop Limit field 2416 in the Router Advertisement messages sent by the router. 2417 The value should be set to the current diameter of the 2418 Internet. The value zero means unspecified (by this 2419 router). 2421 The default SHOULD be set to the value specified in IANA 2422 Assigned Numbers that was in effect at the time of 2423 implementation."; 2424 reference 2425 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2426 AdvCurHopLimit. 2428 IANA: IP Parameters, 2429 http://www.iana.org/assignments/ip-parameters"; 2430 } 2431 leaf default-lifetime { 2432 type uint16 { 2433 range "0..9000"; 2434 } 2435 units "seconds"; 2436 description 2437 "The value to be placed in the Router Lifetime field of 2438 Router Advertisements sent from the interface, in seconds. 2439 MUST be either zero or between max-rtr-adv-interval and 2440 9000 seconds. A value of zero indicates that the router is 2441 not to be used as a default router. These limits may be 2442 overridden by specific documents that describe how IPv6 2443 operates over different link layers. 2445 If this parameter is not configured, a value of 3 * 2446 max-rtr-adv-interval SHOULD be used."; 2447 reference 2448 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2449 AdvDefaultLifeTime."; 2450 } 2451 container prefix-list { 2452 description 2453 "A list of prefixes that are placed in Prefix Information 2454 options in Router Advertisement messages sent from the 2455 interface. 2457 By default, these are all prefixes that the router 2458 advertises via routing protocols as being on-link for the 2459 interface from which the advertisement is sent. 2461 The link-local prefix SHOULD NOT be included in the list 2462 of advertised prefixes."; 2464 reference 2465 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2466 AdvPrefixList."; 2467 list prefix { 2468 key "prefix-spec"; 2469 description 2470 "Advertised prefix entry with parameters."; 2471 leaf prefix-spec { 2472 type inet:ipv6-prefix; 2473 description 2474 "IPv6 address prefix."; 2475 } 2476 leaf valid-lifetime { 2477 type uint32; 2478 units "seconds"; 2479 default "2592000"; 2480 description 2481 "The value to be placed in the Valid Lifetime in the 2482 Prefix Information option. The designated value of all 2483 1's (0xffffffff) represents infinity."; 2484 reference 2485 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2486 AdvValidLifetime."; 2487 } 2488 leaf on-link-flag { 2489 type boolean; 2490 default "true"; 2491 description 2492 "The value to be placed in the on-link flag ('L-bit') 2493 field in the Prefix Information option."; 2494 reference 2495 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2496 AdvOnLinkFlag."; 2497 } 2498 leaf preferred-lifetime { 2499 type uint32; 2500 units "seconds"; 2501 default "604800"; 2502 description 2503 "The value to be placed in the Preferred Lifetime in 2504 the Prefix Information option, in seconds. The 2505 designated value of all 1's (0xffffffff) represents 2506 infinity."; 2507 reference 2508 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2509 AdvPreferredLifetime."; 2510 } 2511 leaf autonomous-flag { 2512 type boolean; 2513 default "true"; 2514 description 2515 "The value to be placed in the Autonomous Flag field in 2516 the Prefix Information option."; 2517 reference 2518 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2519 AdvAutonomousFlag."; 2520 } 2521 } 2522 } 2523 } 2524 } 2526 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2527 when "../../rt:address-family = 'v6ur:ipv6-unicast'" { 2528 description 2529 "This augment is valid only for IPv6 unicast."; 2530 } 2531 description 2532 "This leaf augments an IPv6 unicast route."; 2533 leaf destination-prefix { 2534 type inet:ipv6-prefix; 2535 description 2536 "IPv6 destination prefix."; 2537 } 2538 } 2540 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 2541 + "rt:next-hop-options/rt:simple-next-hop" { 2542 when "../../rt:address-family = 'v6ur:ipv6-unicast'" { 2543 description 2544 "This augment is valid only for IPv6 unicast."; 2545 } 2546 description 2547 "This leaf augments the 'simple-next-hop' case of IPv6 unicast 2548 routes."; 2549 leaf next-hop { 2550 type inet:ipv6-address; 2551 description 2552 "IPv6 address of the next-hop."; 2553 } 2554 } 2556 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 2557 + "rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/" 2558 + "rt:next-hop" { 2559 when "../../../../rt:address-family = 'v6ur:ipv6-unicast'" { 2560 description 2561 "This augment is valid only for IPv6 unicast."; 2562 } 2563 if-feature rt:multipath-routes; 2564 description 2565 "This leaf augments the 'next-hop-list' case of IPv6 unicast 2566 routes."; 2567 leaf address { 2568 type inet:ipv6-address; 2569 description 2570 "IPv6 address of the next-hop."; 2571 } 2572 } 2574 /* Configuration data */ 2576 augment 2577 "/rt:routing/rt:routing-instance/rt:interfaces/rt:interface" { 2578 when "/if:interfaces/if:interface[if:name=current()/rt:name]/" 2579 + "ip:ipv6/ip:enabled='true'" { 2580 description 2581 "This augment is only valid for router interfaces with 2582 enabled IPv6."; 2583 } 2584 description 2585 "Configuration of IPv6-specific parameters of router 2586 interfaces."; 2587 container ipv6-router-advertisements { 2588 description 2589 "Configuration of IPv6 Router Advertisements. 2591 See the corresponding parameters under /rt:routing-state for 2592 detailed descriptions and references."; 2593 leaf send-advertisements { 2594 type boolean; 2595 default "false"; 2596 description 2597 "A flag indicating whether or not the router sends periodic 2598 Router Advertisements and responds to Router 2599 Solicitations."; 2600 } 2601 leaf max-rtr-adv-interval { 2602 type uint16 { 2603 range "4..1800"; 2604 } 2605 units "seconds"; 2606 default "600"; 2607 description 2608 "The maximum time allowed between sending unsolicited 2609 multicast Router Advertisements from the interface."; 2610 } 2611 leaf min-rtr-adv-interval { 2612 type uint16 { 2613 range "3..1350"; 2614 } 2615 units "seconds"; 2616 must ". <= 0.75 * ../max-rtr-adv-interval" { 2617 description 2618 "The value MUST NOT be greater than 75 % of 2619 'max-rtr-adv-interval'."; 2620 } 2621 description 2622 "The minimum time allowed between sending unsolicited 2623 multicast Router Advertisements from the interface."; 2624 } 2625 leaf managed-flag { 2626 type boolean; 2627 default "false"; 2628 description 2629 "The boolean value to be placed in the 'Managed address 2630 configuration' flag field in the Router Advertisement."; 2631 } 2632 leaf other-config-flag { 2633 type boolean; 2634 default "false"; 2635 description 2636 "The boolean value to be placed in the 'Other 2637 configuration' flag field in the Router Advertisement."; 2638 } 2639 leaf link-mtu { 2640 type uint32; 2641 default "0"; 2642 description 2643 "The value to be placed in MTU options sent by the router. 2644 A value of zero indicates that no MTU options are sent."; 2645 } 2646 leaf reachable-time { 2647 type uint32 { 2648 range "0..3600000"; 2649 } 2650 units "milliseconds"; 2651 default "0"; 2652 description 2653 "The value to be placed in the Reachable Time field in the 2654 Router Advertisement messages sent by the router. The 2655 value zero means unspecified (by this router)."; 2657 } 2658 leaf retrans-timer { 2659 type uint32; 2660 units "milliseconds"; 2661 default "0"; 2662 description 2663 "The value to be placed in the Retrans Timer field in the 2664 Router Advertisement messages sent by the router. The 2665 value zero means unspecified (by this router)."; 2666 } 2667 leaf cur-hop-limit { 2668 type uint8; 2669 default "64"; 2670 description 2671 "The default value to be placed in the Cur Hop Limit field 2672 in the Router Advertisement messages sent by the 2673 router."; 2674 } 2675 leaf default-lifetime { 2676 type uint16 { 2677 range "0..9000"; 2678 } 2679 units "seconds"; 2680 description 2681 "The value to be placed in the Router Lifetime field of 2682 Router Advertisements sent from the interface, in 2683 seconds."; 2684 } 2685 container prefix-list { 2686 description 2687 "Configuration of prefixes to be placed in Prefix 2688 Information options in Router Advertisement messages sent 2689 from the interface. 2691 Prefixes that are advertised by default but do not have 2692 their entries in the child 'prefix' list are advertised 2693 with the default values of all parameters."; 2694 list prefix { 2695 key "prefix-spec"; 2696 description 2697 "Advertised prefix entry."; 2698 leaf prefix-spec { 2699 type inet:ipv6-prefix; 2700 description 2701 "IPv6 address prefix."; 2702 } 2703 choice control-adv-prefixes { 2704 default "advertise"; 2705 description 2706 "The prefix either may be explicitly removed from the 2707 set of advertised prefixes, or parameters with which 2708 it is advertised may be specified (default case)."; 2709 leaf no-advertise { 2710 type empty; 2711 description 2712 "The prefix will not be advertised. 2714 This can be used for removing the prefix from the 2715 default set of advertised prefixes."; 2716 } 2717 case advertise { 2718 leaf valid-lifetime { 2719 type uint32; 2720 units "seconds"; 2721 default "2592000"; 2722 description 2723 "The value to be placed in the Valid Lifetime in 2724 the Prefix Information option."; 2725 } 2726 leaf on-link-flag { 2727 type boolean; 2728 default "true"; 2729 description 2730 "The value to be placed in the on-link flag 2731 ('L-bit') field in the Prefix Information 2732 option."; 2733 } 2734 leaf preferred-lifetime { 2735 type uint32; 2736 units "seconds"; 2737 must ". <= ../valid-lifetime" { 2738 description 2739 "This value MUST NOT be greater than 2740 valid-lifetime."; 2741 } 2742 default "604800"; 2743 description 2744 "The value to be placed in the Preferred Lifetime 2745 in the Prefix Information option."; 2746 } 2747 leaf autonomous-flag { 2748 type boolean; 2749 default "true"; 2750 description 2751 "The value to be placed in the Autonomous Flag 2752 field in the Prefix Information option."; 2754 } 2755 } 2756 } 2757 } 2758 } 2759 } 2760 } 2762 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2763 + "rt:routing-protocol/rt:static-routes" { 2764 description 2765 "This augment defines the configuration of the 'static' 2766 pseudo-protocol with data specific to IPv6 unicast."; 2767 container ipv6 { 2768 description 2769 "Configuration of a 'static' pseudo-protocol instance 2770 consists of a list of routes."; 2771 list route { 2772 key "id"; 2773 ordered-by "user"; 2774 description 2775 "A user-ordered list of static routes."; 2776 leaf id { 2777 type uint32 { 2778 range "1..max"; 2779 } 2780 description 2781 "Unique numeric identifier of the route. 2783 This value is unrelated to system-assigned 'id' 2784 parameters of routes in RIBs."; 2785 } 2786 leaf description { 2787 type string; 2788 description 2789 "Textual description of the route."; 2790 } 2791 leaf destination-prefix { 2792 type inet:ipv6-prefix; 2793 mandatory "true"; 2794 description 2795 "IPv6 destination prefix."; 2796 } 2797 choice next-hop-options { 2798 mandatory "true"; 2799 description 2800 "Options for expressing the next-hop in static routes."; 2801 case special-next-hop { 2802 uses rt:special-next-hop; 2803 } 2804 case simple-next-hop { 2805 leaf next-hop { 2806 type inet:ipv6-address; 2807 description 2808 "IPv6 address of the next-hop."; 2809 } 2810 leaf outgoing-interface { 2811 type leafref { 2812 path "../../../../../../rt:interfaces/rt:interface/" 2813 + "rt:name"; 2814 } 2815 description 2816 "Name of the outgoing interface. 2818 Only interfaces configured for the ancestor routing 2819 instance can be given."; 2820 } 2821 } 2822 case next-hop-list { 2823 if-feature rt:multipath-routes; 2824 container next-hop-list { 2825 list next-hop { 2826 key "id"; 2827 description 2828 "An entry of a next-hop list."; 2829 leaf id { 2830 type uint32; 2831 description 2832 "Unique numeric identifier of the entry. 2834 This value is unrelated to system-assigned 'id' 2835 parameters of next-hops in RIBs."; 2836 } 2837 leaf address { 2838 type inet:ipv6-address; 2839 description 2840 "IPv6 address of the next-hop."; 2841 } 2842 leaf outgoing-interface { 2843 type leafref { 2844 path "../../../../../../../../rt:interfaces/" 2845 + "rt:interface/rt:name"; 2846 } 2847 description 2848 "Name of the outgoing interface. 2850 Only interfaces configured for the ancestor 2851 routing instance can be given."; 2852 } 2853 uses rt:next-hop-classifiers; 2854 } 2855 } 2856 } 2857 } 2858 } 2859 } 2860 } 2862 /* RPC methods */ 2864 augment "/rt:active-route/rt:input/rt:destination-address" { 2865 when "rt:address-family='v6ur:ipv6-unicast'" { 2866 description 2867 "This augment is valid only for IPv6 unicast."; 2868 } 2869 description 2870 "This leaf augments the 'rt:destination-address' parameter of 2871 the 'rt:active-route' operation."; 2872 leaf address { 2873 type inet:ipv6-address; 2874 description 2875 "IPv6 destination address."; 2876 } 2877 } 2879 augment "/rt:active-route/rt:output/rt:route" { 2880 when "rt:address-family='v6ur:ipv6-unicast'" { 2881 description 2882 "This augment is valid only for IPv6 unicast."; 2883 } 2884 description 2885 "This leaf augments the reply to the 'rt:active-route' 2886 operation."; 2887 leaf destination-prefix { 2888 type inet:ipv6-prefix; 2889 description 2890 "IPv6 destination prefix."; 2891 } 2892 } 2894 augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/" 2895 + "rt:simple-next-hop" { 2896 when "rt:address-family='v6ur:ipv6-unicast'" { 2897 description 2898 "This augment is valid only for IPv6 unicast."; 2899 } 2900 description 2901 "This leaf augments the 'simple-next-hop' case in the reply to 2902 the 'rt:active-route' operation."; 2903 leaf next-hop { 2904 type inet:ipv6-address; 2905 description 2906 "IPv6 address of the next-hop."; 2907 } 2908 } 2910 augment "/rt:active-route/rt:output/rt:route/rt:next-hop-options/" 2911 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 2912 when "../../rt:address-family='v6ur:ipv6-unicast'" { 2913 description 2914 "This augment is valid only for IPv6 unicast."; 2915 } 2916 if-feature rt:multipath-routes; 2917 description 2918 "This leaf augments the 'next-hop-list' case in the reply to 2919 the 'rt:active-route' operation."; 2920 leaf address { 2921 type inet:ipv6-address; 2922 description 2923 "IPv6 address of the next-hop."; 2924 } 2925 } 2926 } 2928 2930 10. IANA Considerations 2932 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2933 actual RFC number (and remove this note). 2935 This document registers the following namespace URIs in the IETF XML 2936 registry [RFC3688]: 2938 ---------------------------------------------------------- 2939 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2941 Registrant Contact: The IESG. 2943 XML: N/A, the requested URI is an XML namespace. 2944 ---------------------------------------------------------- 2946 ---------------------------------------------------------- 2947 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2949 Registrant Contact: The IESG. 2951 XML: N/A, the requested URI is an XML namespace. 2952 ---------------------------------------------------------- 2954 ---------------------------------------------------------- 2955 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2957 Registrant Contact: The IESG. 2959 XML: N/A, the requested URI is an XML namespace. 2960 ---------------------------------------------------------- 2962 This document registers the following YANG modules in the YANG Module 2963 Names registry [RFC6020]: 2965 ------------------------------------------------------------------- 2966 name: ietf-routing 2967 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2968 prefix: rt 2969 reference: RFC XXXX 2970 ------------------------------------------------------------------- 2972 ------------------------------------------------------------------- 2973 name: ietf-ipv4-unicast-routing 2974 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2975 prefix: v4ur 2976 reference: RFC XXXX 2977 ------------------------------------------------------------------- 2979 ------------------------------------------------------------------- 2980 name: ietf-ipv6-unicast-routing 2981 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2982 prefix: v6ur 2983 reference: RFC XXXX 2984 ------------------------------------------------------------------- 2986 11. Security Considerations 2988 Configuration and state data conforming to the core routing data 2989 model (defined in this document) are designed to be accessed via the 2990 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2991 transport layer and the mandatory-to-implement secure transport is 2992 SSH [RFC6242]. 2994 A number of data nodes defined in the YANG modules belonging to the 2995 configuration part of the core routing data model are writable/ 2996 creatable/deletable (i.e., "config true" in YANG terms, which is the 2997 default). These data nodes may be considered sensitive or vulnerable 2998 in some network environments. Write operations to these data nodes, 2999 such as "edit-config", can have negative effects on the network if 3000 the protocol operations are not properly protected. 3002 The vulnerable "config true" subtrees and data nodes are the 3003 following: 3005 /routing/routing-instance/interfaces/interface This list assigns a 3006 network layer interface to a routing instance and may also specify 3007 interface parameters related to routing. 3009 /routing/routing-instance/routing-protocols/routing-protocol This 3010 list specifies the routing protocols configured on a device. 3012 /routing/route-filters/route-filter This list specifies the 3013 configured route filters which represent administrative policies 3014 for redistributing and modifying routing information. 3016 /routing/ribs/rib This list specifies the RIBs configured for the 3017 device. 3019 Unauthorized access to any of these lists can adversely affect the 3020 routing subsystem of both the local device and the network. This may 3021 lead to network malfunctions, delivery of packets to inappropriate 3022 destinations and other problems. 3024 12. Acknowledgments 3026 The author wishes to thank Nitin Bahadur, Martin Bjorklund, 3027 Joel Halpern, Wes Hardaker, Sriganesh Kini, David Lamparter, 3028 Andrew McGregor, Jan Medved, Xiang Li, Thomas Morin, Tom Petch, 3029 Bruno Rijsman, Juergen Schoenwaelder, Phil Shafer, Dave Thaler and 3030 Yi Yang for their helpful comments and suggestions. 3032 13. References 3034 13.1. Normative References 3036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3037 Requirement Levels", BCP 14, RFC 2119, March 1997. 3039 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3040 January 2004. 3042 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3043 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3044 September 2007. 3046 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3047 Network Configuration Protocol (NETCONF)", RFC 6020, 3048 September 2010. 3050 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 3051 Bierman, "NETCONF Configuration Protocol", RFC 6241, 3052 June 2011. 3054 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3055 RFC 6991, July 2013. 3057 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 3058 Management", draft-ietf-netmod-interfaces-cfg-15 (work in 3059 progress), December 2013. 3061 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Management", 3062 draft-ietf-netmod-ip-cfg-12 (work in progress), 3063 January 2014. 3065 13.2. Informative References 3067 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 3068 Data Model Documents", RFC 6087, January 2011. 3070 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3071 Shell (SSH)", RFC 6242, June 2011. 3073 Appendix A. The Complete Data Trees 3075 This appendix presents the complete configuration and operational 3076 state data trees of the core routing data model. 3078 See Section 2.2 for an explanation of the symbols used. Data type of 3079 every leaf node is shown near the right end of the corresponding 3080 line. 3082 A.1. Configuration Data 3084 +--rw routing 3085 +--rw routing-instance* [name] 3086 | +--rw name string 3087 | +--rw type? identityref 3088 | +--rw enabled? boolean 3089 | +--rw router-id? yang:dotted-quad 3090 | +--rw description? string 3091 | +--rw default-ribs {multiple-ribs}? 3092 | | +--rw default-rib* [address-family] 3093 | | +--rw address-family identityref 3094 | | +--rw rib-name string 3095 | +--rw interfaces 3096 | | +--rw interface* [name] 3097 | | +--rw name if:interface-ref 3098 | | +--rw v6ur:ipv6-router-advertisements 3099 | | +--rw v6ur:send-advertisements? boolean 3100 | | +--rw v6ur:max-rtr-adv-interval? uint16 3101 | | +--rw v6ur:min-rtr-adv-interval? uint16 3102 | | +--rw v6ur:managed-flag? boolean 3103 | | +--rw v6ur:other-config-flag? boolean 3104 | | +--rw v6ur:link-mtu? uint32 3105 | | +--rw v6ur:reachable-time? uint32 3106 | | +--rw v6ur:retrans-timer? uint32 3107 | | +--rw v6ur:cur-hop-limit? uint8 3108 | | +--rw v6ur:default-lifetime? uint16 3109 | | +--rw v6ur:prefix-list 3110 | | +--rw v6ur:prefix* [prefix-spec] 3111 | | +--rw v6ur:prefix-spec inet:ipv6-prefix 3112 | | +--rw (control-adv-prefixes)? 3113 | | +--:(no-advertise) 3114 | | | +--rw v6ur:no-advertise? empty 3115 | | +--:(advertise) 3116 | | +--rw v6ur:valid-lifetime? uint32 3117 | | +--rw v6ur:on-link-flag? boolean 3118 | | +--rw v6ur:preferred-lifetime? uint32 3119 | | +--rw v6ur:autonomous-flag? boolean 3120 | +--rw routing-protocols 3121 | +--rw routing-protocol* [name] 3122 | +--rw name string 3123 | +--rw description? string 3124 | +--rw enabled? boolean 3125 | +--rw type identityref 3126 | +--rw connected-ribs {multiple-ribs}? 3127 | | +--rw connected-rib* [rib-name] 3128 | | +--rw rib-name rib-ref 3129 | | +--rw import-filter? route-filter-ref 3130 | | +--rw export-filter? route-filter-ref 3131 | +--rw static-routes 3132 | +--rw v4ur:ipv4 3133 | | +--rw v4ur:route* [id] 3134 | | +--rw v4ur:id uint32 3135 | | +--rw v4ur:description? string 3136 | | +--rw v4ur:destination-prefix inet:ipv4-prefix 3137 | | +--rw (next-hop-options) 3138 | | +--:(special-next-hop) 3139 | | | +--rw v4ur:special-next-hop? enumeration 3140 | | +--:(simple-next-hop) 3141 | | | +--rw v4ur:next-hop? inet:ipv4-address 3142 | | | +--rw v4ur:outgoing-interface? leafref 3143 | | +--:(next-hop-list) {rt:multipath-routes}? 3144 | | +--rw v4ur:next-hop-list 3145 | | +--rw v4ur:next-hop* [id] 3146 | | +--rw v4ur:id uint32 3147 | | +--rw v4ur:address? 3148 | | +--rw v4ur:outgoing-interface? 3149 | | +--rw v4ur:priority? enumeration 3150 | | +--rw v4ur:weight? uint8 3151 | +--rw v6ur:ipv6 3152 | +--rw v6ur:route* [id] 3153 | +--rw v6ur:id uint32 3154 | +--rw v6ur:description? string 3155 | +--rw v6ur:destination-prefix inet:ipv6-prefix 3156 | +--rw (next-hop-options) 3157 | +--:(special-next-hop) 3158 | | +--rw v6ur:special-next-hop? enumeration 3159 | +--:(simple-next-hop) 3160 | | +--rw v6ur:next-hop? inet:ipv6-address 3161 | | +--rw v6ur:outgoing-interface? leafref 3162 | +--:(next-hop-list) {rt:multipath-routes}? 3163 | +--rw v6ur:next-hop-list 3164 | +--rw v6ur:next-hop* [id] 3165 | +--rw v6ur:id uint32 3166 | +--rw v6ur:address? 3167 | +--rw v6ur:outgoing-interface? 3168 | +--rw v6ur:priority? enumeration 3169 | +--rw v6ur:weight? uint8 3170 +--rw ribs 3171 | +--rw rib* [name] 3172 | +--rw name string 3173 | +--rw address-family identityref 3174 | +--rw description? string 3175 | +--rw recipient-ribs {multiple-ribs}? 3176 | +--rw recipient-rib* [rib-name] 3177 | +--rw rib-name rib-ref 3178 | +--rw filter? route-filter-ref 3179 +--rw route-filters 3180 +--rw route-filter* [name] 3181 +--rw name string 3182 +--rw description? string 3183 +--rw type identityref 3185 A.2. Operational State Data 3187 +--ro routing-state 3188 +--ro routing-instance* [name] 3189 | +--ro name string 3190 | +--ro id uint64 3191 | +--ro type? identityref 3192 | +--ro router-id? yang:dotted-quad 3193 | +--ro default-ribs 3194 | | +--ro default-rib* [address-family] 3195 | | +--ro address-family identityref 3196 | | +--ro rib-name rib-state-ref 3197 | +--ro interfaces 3198 | | +--ro interface* [name] 3199 | | +--ro name if:interface-state-ref 3200 | | +--ro v6ur:ipv6-router-advertisements 3201 | | +--ro v6ur:send-advertisements? boolean 3202 | | +--ro v6ur:max-rtr-adv-interval? uint16 3203 | | +--ro v6ur:min-rtr-adv-interval? uint16 3204 | | +--ro v6ur:managed-flag? boolean 3205 | | +--ro v6ur:other-config-flag? boolean 3206 | | +--ro v6ur:link-mtu? uint32 3207 | | +--ro v6ur:reachable-time? uint32 3208 | | +--ro v6ur:retrans-timer? uint32 3209 | | +--ro v6ur:cur-hop-limit? uint8 3210 | | +--ro v6ur:default-lifetime? uint16 3211 | | +--ro v6ur:prefix-list 3212 | | +--ro v6ur:prefix* [prefix-spec] 3213 | | +--ro v6ur:prefix-spec inet:ipv6-prefix 3214 | | +--ro v6ur:valid-lifetime? uint32 3215 | | +--ro v6ur:on-link-flag? boolean 3216 | | +--ro v6ur:preferred-lifetime? uint32 3217 | | +--ro v6ur:autonomous-flag? boolean 3218 | +--ro routing-protocols 3219 | +--ro routing-protocol* [name] 3220 | +--ro name string 3221 | +--ro type identityref 3222 | +--ro connected-ribs 3223 | +--ro connected-rib* [rib-name] 3224 | +--ro rib-name rib-state-ref 3225 | +--ro import-filter? route-filter-state-ref 3226 | +--ro export-filter? route-filter-state-ref 3227 +--ro ribs 3228 | +--ro rib* [name] 3229 | +--ro name string 3230 | +--ro id uint64 3231 | +--ro address-family identityref 3232 | +--ro routes 3233 | | +--ro route* [id] 3234 | | +--ro id uint64 3235 | | +--ro (next-hop-options) 3236 | | | +--:(special-next-hop) 3237 | | | | +--ro special-next-hop? enumeration 3238 | | | +--:(simple-next-hop) 3239 | | | | +--ro outgoing-interface? leafref 3240 | | | | +--ro v4ur:next-hop? inet:ipv4-address 3241 | | | | +--ro v6ur:next-hop? inet:ipv6-address 3242 | | | +--:(next-hop-list) {multipath-routes}? 3243 | | | +--ro next-hop-list 3244 | | | +--ro next-hop* [id] 3245 | | | +--ro id uint64 3246 | | | +--ro outgoing-interface? leafref 3247 | | | +--ro priority? enumeration 3248 | | | +--ro weight? uint8 3249 | | | +--ro v4ur:address? inet:ipv4-address 3250 | | | +--ro v6ur:address? inet:ipv6-address 3251 | | +--ro source-protocol identityref 3252 | | +--ro last-updated? yang:date-and-time 3253 | | +--ro v4ur:destination-prefix? inet:ipv4-prefix 3254 | | +--ro v6ur:destination-prefix? inet:ipv6-prefix 3255 | +--ro recipient-ribs {multiple-ribs}? 3256 | +--ro recipient-rib* [rib-name] 3257 | +--ro rib-name rib-state-ref 3258 | +--ro filter? route-filter-state-ref 3259 +--ro route-filters 3260 +--ro route-filter* [name] 3261 +--ro name string 3262 +--ro type identityref 3264 Appendix B. Minimum Implementation 3266 Some parts and options of the core routing model, such as route 3267 filters or multiple routing tables, are intended only for advanced 3268 routers. This appendix gives basic non-normative guidelines for 3269 implementing a bare minimum of available functions. Such an 3270 implementation may be used for hosts or very simple routers. 3272 A minimum implementation will provide a single system-controlled 3273 routing instance, and will not allow clients to create any user- 3274 controlled instances. 3276 Typically, neither of the features defined in the "ietf-routing" 3277 module ("multiple-ribs" and "multipath-routes") will be supported. 3278 This means that: 3280 o A single system-controlled RIB (routing table) is available for 3281 each supported address family - IPv4, IPv6 or both. These RIBs 3282 are the default RIBs, so they will also appear as system- 3283 controlled entries of the "default-rib" list in operational state 3284 data. No user-controlled RIBs are allowed. 3286 o Each route has no more than one "next-hop", "outgoing-interface" 3287 or "special-next-hop". 3289 In addition to the mandatory instance of the "direct" pseudo- 3290 protocol, a minimum implementation should support configured 3291 instance(s) of the "static" pseudo-protocol. Even with a single RIB 3292 per address family, it may be occasionally useful to be able to 3293 configure multiple "static" instances. For example, a client may 3294 want to configure alternative sets of static routes and activate or 3295 deactivate them by means of configuring appropriate route filters 3296 ("allow-all-route-filter" or "deny-all-route-filter"). 3298 Platforms with severely constrained resources may use deviations for 3299 restricting the data model, e.g., limiting the number of "static" 3300 routing protocol instances, preventing any route filters to be 3301 configured etc. 3303 Appendix C. Example: Adding a New Routing Protocol 3305 This appendix demonstrates how the core routing data model can be 3306 extended to support a new routing protocol. The YANG module 3307 "example-rip" shown below is intended only as an illustration rather 3308 than a real definition of a data model for the RIP routing protocol. 3309 For the sake of brevity, we do not follow all the guidelines 3310 specified in [RFC6087]. See also Section 5.4.2. 3312 module example-rip { 3314 namespace "http://example.com/rip"; 3316 prefix "rip"; 3318 import ietf-routing { 3319 prefix "rt"; 3320 } 3322 identity rip { 3323 base rt:routing-protocol; 3324 description 3325 "Identity for the RIP routing protocol."; 3326 } 3328 typedef rip-metric { 3329 type uint8 { 3330 range "0..16"; 3331 } 3332 } 3334 grouping route-content { 3335 description 3336 "This grouping defines RIP-specific route attributes."; 3337 leaf metric { 3338 type rip-metric; 3339 } 3340 leaf tag { 3341 type uint16; 3342 default "0"; 3343 description 3344 "This leaf may be used to carry additional info, e.g. AS 3345 number."; 3346 } 3347 } 3349 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 3350 when "rt:source-protocol = 'rip:rip'" { 3351 description 3352 "This augment is only valid for a routes whose source 3353 protocol is RIP."; 3354 } 3355 description 3356 "RIP-specific route attributes."; 3357 uses route-content; 3358 } 3360 augment "/rt:active-route/rt:output/rt:route" { 3361 description 3362 "RIP-specific route attributes in the output of 'active-route' 3363 RPC."; 3364 uses route-content; 3365 } 3367 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 3368 + "rt:routing-protocol" { 3369 when "rt:type = 'rip:rip'" { 3370 description 3371 "This augment is only valid for a routing protocol instance 3372 of type 'rip'."; 3373 } 3374 container rip { 3375 description 3376 "RIP instance configuration."; 3377 container interfaces { 3378 description 3379 "Per-interface RIP configuration."; 3380 list interface { 3381 key "name"; 3382 description 3383 "RIP is enabled on interfaces that have an entry in this 3384 list, unless 'enabled' is set to 'false' for that 3385 entry."; 3386 leaf name { 3387 type leafref { 3388 path "../../../../../../rt:interfaces/rt:interface/" 3389 + "rt:name"; 3390 } 3391 } 3392 leaf enabled { 3393 type boolean; 3394 default "true"; 3395 } 3396 leaf metric { 3397 type rip-metric; 3398 default "1"; 3400 } 3401 } 3402 } 3403 leaf update-interval { 3404 type uint8 { 3405 range "10..60"; 3406 } 3407 units "seconds"; 3408 default "30"; 3409 description 3410 "Time interval between periodic updates."; 3411 } 3412 } 3413 } 3414 } 3416 Appendix D. Example: NETCONF Reply 3418 This section contains a sample reply to the NETCONF message, 3419 which could be sent by a server supporting (i.e., advertising them in 3420 the NETCONF message) the following YANG modules: 3422 o ietf-interfaces [YANG-IF], 3424 o ietf-ip [YANG-IP], 3426 o ietf-routing (Section 7), 3428 o ietf-ipv4-unicast-routing (Section 8), 3430 o ietf-ipv6-unicast-routing (Section 9). 3432 We assume a simple network setup as shown in Figure 5: router "A" 3433 uses static default routes with the "ISP" router as the next-hop. 3434 IPv6 router advertisements are configured only on the "eth1" 3435 interface and disabled on the upstream "eth0" interface. 3437 +-----------------+ 3438 | | 3439 | Router ISP | 3440 | | 3441 +--------+--------+ 3442 |2001:db8:0:1::2 3443 |192.0.2.2 3444 | 3445 | 3446 |2001:db8:0:1::1 3447 eth0|192.0.2.1 3448 +--------+--------+ 3449 | | 3450 | Router A | 3451 | | 3452 +--------+--------+ 3453 eth1|198.51.100.1 3454 |2001:db8:0:2::1 3455 | 3457 Figure 5: Example network configuration 3459 A reply to the NETCONF message sent by router "A" would then be 3460 as follows: 3462 3463 3472 3473 3474 3475 eth0 3476 ianaift:ethernetCsmacd 3477 3478 Uplink to ISP. 3479 3480 3481 3482 192.0.2.1 3483 24 3484 3485 true 3486 3487 3488 3489 2001:0db8:0:1::1 3490 64 3491 3492 true 3493 3494 false 3495 3496 3497 3498 3499 eth1 3500 ianaift:ethernetCsmacd 3501 3502 Interface to the internal network. 3503 3504 3505 3506 198.51.100.1 3507 24 3508 3509 true 3510 3511 3512 3513 2001:0db8:0:2::1 3514 64 3515 3516 true 3517 3518 false 3519 3520 3521 3522 3523 3524 3525 eth0 3526 ianaift:ethernetCsmacd 3527 00:0C:42:E5:B1:E9 3528 up 3529 3530 3531 2013-07-02T17:11:27+00:58 3532 3533 3534 3535 true 3536 1500 3537 3538 192.0.2.1 3539 24 3540 3541 3542 3543 true 3544 1500 3545 3546 2001:0db8:0:1::1 3547 64 3548 3549 3550 3551 3552 eth1 3553 ianaift:ethernetCsmacd 3554 up 3555 00:0C:42:E5:B1:EA 3556 3557 3558 2013-07-02T17:11:27+00:59 3559 3561 3562 3563 true 3564 1500 3565 3566 198.51.100.1 3567 24 3568 3569 3570 3571 true 3572 1500 3573 3574 2001:0db8:0:2::1 3575 64 3576 3577 3578 3579 3580 3581 3582 rtr0 3583 Router A 3584 3585 3586 eth1 3587 3588 true 3589 3590 3591 2001:db8:0:2::/64 3592 3593 3594 3595 3596 3597 3598 3599 st0 3600 3601 Static routing is used for the internal network. 3602 3603 rt:static 3604 3605 3606 3607 1 3608 0.0.0.0/0 3609 192.0.2.2 3610 3611 3612 3613 3614 1 3615 ::/0 3616 2001:db8:0:1::2 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 rtr0 3627 2718281828 3628 192.0.2.1 3629 3630 3631 v4ur:ipv4-unicast 3632 ipv4-master 3633 3634 3635 v6ur:ipv6-unicast 3636 ipv6-master 3637 3638 3639 3640 3641 eth0 3642 3643 3644 eth1 3645 3646 true 3647 3648 3649 2001:db8:0:2::/64 3650 3651 3652 3653 3654 3655 3656 3657 st0 3658 rt:static 3659 3660 3661 3662 3663 3664 ipv4-master 3665 897932384 3666 v4ur:ipv4-unicast 3667 3668 3669 626433832 3670 192.0.2.1/24 3671 eth0 3672 rt:direct 3673 2013-07-02T17:11:27+01:00 3674 3675 3676 795028841 3677 3678 198.51.100.0/24 3679 3680 eth1 3681 rt:direct 3682 2013-07-02T17:11:27+01:00 3683 3684 3685 971693993 3686 0.0.0.0/0 3687 rt:static 3688 192.0.2.2 3689 2013-07-02T18:02:45+01:00 3690 3691 3692 3693 3694 ipv6-master 3695 751058209 3696 v6ur:ipv6-unicast 3697 3698 3699 749445923 3700 3701 2001:db8:0:1::/64 3702 3703 eth0 3704 rt:direct 3705 2013-07-02T17:11:27+01:00 3706 3707 3708 78164062 3709 3710 2001:db8:0:2::/64 3711 3712 eth1 3713 rt:direct 3714 2013-07-02T17:11:27+01:00 3715 3716 3717 862089986 3718 ::/0 3719 2001:db8:0:1::2 3720 rt:static 3721 2013-07-02T18:02:45+01:00 3722 3723 3724 3725 3726 3727 3728 3730 Appendix E. Change Log 3732 RFC Editor: remove this section upon publication as an RFC. 3734 E.1. Changes Between Versions -12 and -13 3736 o Wrote appendix about minimum implementation. 3738 o Remove "when" statement for IPv6 router interface operational 3739 state - it was dependent on a config value that may not be 3740 present. 3742 o Extra container for the next-hop list. 3744 o Names rather than numeric ids are used for referring to list 3745 entries in operational state. 3747 o Numeric ids are always declared as mandatory and unique. Their 3748 description states that they are ephemeral. 3750 o Descriptions of "name" keys in operational state lists are 3751 required to be persistent. 3753 o 3755 o Removed "if-feature multiple-ribs;" from connected-ribs. 3757 o "rib-name" instead of "name" is used as the name of leafref nodes. 3759 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3760 in node names and text. 3762 E.2. Changes Between Versions -11 and -12 3764 o Removed feature "advanced-router" and introduced two features 3765 instead: "multiple-ribs" and "multipath-routes". 3767 o Unified the keys of config and state versions of "routing- 3768 instance" and "rib" lists. 3770 o Numerical identifiers of state list entries are not keys anymore, 3771 but they are constrained using the "unique" statement. 3773 o Updated acknowledgements. 3775 E.3. Changes Between Versions -10 and -11 3777 o Migrated address families from IANA enumerations to identities. 3779 o Terminology and node names aligned with the I2RS RIB model: router 3780 -> routing instance, routing table -> RIB. 3782 o Introduced uint64 keys for state lists: routing-instance, rib, 3783 route, nexthop. 3785 o Described the relationship between system-controlled and user- 3786 controlled list entries. 3788 o Feature "user-defined-routing-tables" changed into "advanced- 3789 router". 3791 o Made nexthop into a choice in order to allow for nexthop-list 3792 (I2RS requirement). 3794 o Added nexthop-list with entries having priorities (backup) and 3795 weights (load balancing). 3797 o Updated bibliography references. 3799 E.4. Changes Between Versions -09 and -10 3801 o Added subtree for operational state data ("/routing-state"). 3803 o Terms "system-controlled entry" and "user-controlled entry" 3804 defined and used. 3806 o New feature "user-defined-routing-tables". Nodes that are useful 3807 only with user-defined routing tables are now conditional. 3809 o Added grouping "router-id". 3811 o In routing tables, "source-protocol" attribute of routes now 3812 reports only protocol type, and its datatype is "identityref". 3814 o Renamed "main-routing-table" to "default-routing-table". 3816 E.5. Changes Between Versions -08 and -09 3818 o Fixed "must" expresion for "connected-routing-table". 3820 o Simplified "must" expression for "main-routing-table". 3822 o Moved per-interface configuration of a new routing protocol under 3823 'routing-protocol'. This also affects the 'example-rip' module. 3825 E.6. Changes Between Versions -07 and -08 3827 o Changed reference from RFC6021 to RFC6021bis. 3829 E.7. Changes Between Versions -06 and -07 3831 o The contents of in Appendix D was updated: "eth[01]" 3832 is used as the value of "location", and "forwarding" is on for 3833 both interfaces and both IPv4 and IPv6. 3835 o The "must" expression for "main-routing-table" was modified to 3836 avoid redundant error messages reporting address family mismatch 3837 when "name" points to a non-existent routing table. 3839 o The default behavior for IPv6 RA prefix advertisements was 3840 clarified. 3842 o Changed type of "rt:router-id" to "ip:dotted-quad". 3844 o Type of "rt:router-id" changed to "yang:dotted-quad". 3846 o Fixed missing prefixes in XPath expressions. 3848 E.8. Changes Between Versions -05 and -06 3850 o Document title changed: "Configuration" was replaced by 3851 "Management". 3853 o New typedefs "routing-table-ref" and "route-filter-ref". 3855 o Double slashes "//" were removed from XPath expressions and 3856 replaced with the single "/". 3858 o Removed uniqueness requirement for "router-id". 3860 o Complete data tree is now in Appendix A. 3862 o Changed type of "source-protocol" from "leafref" to "string". 3864 o Clarified the relationship between routing protocol instances and 3865 connected routing tables. 3867 o Added a must constraint saying that a routing table connected to 3868 the direct pseudo-protocol must not be a main routing table. 3870 E.9. Changes Between Versions -04 and -05 3872 o Routing tables are now global, i.e., "routing-tables" is a child 3873 of "routing" rather than "router". 3875 o "must" statement for "static-routes" changed to "when". 3877 o Added "main-routing-tables" containing references to main routing 3878 tables for each address family. 3880 o Removed the defaults for "address-family" and "safi" and made them 3881 mandatory. 3883 o Removed the default for route-filter/type and made this leaf 3884 mandatory. 3886 o If there is no active route for a given destination, the "active- 3887 route" RPC returns no output. 3889 o Added "enabled" switch under "routing-protocol". 3891 o Added "router-type" identity and "type" leaf under "router". 3893 o Route attribute "age" changed to "last-updated", its type is 3894 "yang:date-and-time". 3896 o The "direct" pseudo-protocol is always connected to main routing 3897 tables. 3899 o Entries in the list of connected routing tables renamed from 3900 "routing-table" to "connected-routing-table". 3902 o Added "must" constraint saying that a routing table must not be 3903 its own recipient. 3905 E.10. Changes Between Versions -03 and -04 3907 o Changed "error-tag" for both RPC methods from "missing element" to 3908 "data-missing". 3910 o Removed the decrementing behavior for advertised IPv6 prefix 3911 parameters "valid-lifetime" and "preferred-lifetime". 3913 o Changed the key of the static route lists from "seqno" to "id" 3914 because the routes needn't be sorted. 3916 o Added 'must' constraint saying that "preferred-lifetime" must not 3917 be greater than "valid-lifetime". 3919 E.11. Changes Between Versions -02 and -03 3921 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3923 o Removed forwarding table. 3925 o RPC "get-route" changed to "active-route". Its output is a list 3926 of routes (for multi-path routing). 3928 o New RPC "route-count". 3930 o For both RPCs, specification of negative responses was added. 3932 o Relaxed separation of router instances. 3934 o Assignment of interfaces to router instances needn't be disjoint. 3936 o Route filters are now global. 3938 o Added "allow-all-route-filter" for symmetry. 3940 o Added Section 6 about interactions with "ietf-interfaces" and 3941 "ietf-ip". 3943 o Added "router-id" leaf. 3945 o Specified the names for IPv4/IPv6 unicast main routing tables. 3947 o Route parameter "last-modified" changed to "age". 3949 o Added container "recipient-routing-tables". 3951 E.12. Changes Between Versions -01 and -02 3953 o Added module "ietf-ipv6-unicast-routing". 3955 o The example in Appendix D now uses IP addresses from blocks 3956 reserved for documentation. 3958 o Direct routes appear by default in the forwarding table. 3960 o Network layer interfaces must be assigned to a router instance. 3961 Additional interface configuration may be present. 3963 o The "when" statement is only used with "augment", "must" is used 3964 elsewhere. 3966 o Additional "must" statements were added. 3968 o The "route-content" grouping for IPv4 and IPv6 unicast now 3969 includes the material from the "ietf-routing" version via "uses 3970 rt:route-content". 3972 o Explanation of symbols in the tree representation of data model 3973 hierarchy. 3975 E.13. Changes Between Versions -00 and -01 3977 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3979 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3980 safi" module. 3982 o Names of some data nodes were changed, in particular "routing- 3983 process" is now "router". 3985 o The restriction of a single AFN/SAFI per router was lifted. 3987 o RPC operation "delete-route" was removed. 3989 o Illegal XPath references from "get-route" to the datastore were 3990 fixed. 3992 o Section "Security Considerations" was written. 3994 Author's Address 3996 Ladislav Lhotka 3997 CZ.NIC 3999 Email: lhotka@nic.cz