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