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