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