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