idnits 2.17.1 draft-ietf-netmod-routing-cfg-10.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 2682 has weird spacing: '...-family ian...' == Line 2761 has weird spacing: '...-family ian...' == Line 2814 has weird spacing: '...ro name str...' == Line 2815 has weird spacing: '...ro type ide...' -- The document date (July 13, 2013) is 3941 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-12 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-ip-cfg-09 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track July 13, 2013 5 Expires: January 14, 2014 7 A YANG Data Model for Routing Management 8 draft-ietf-netmod-routing-cfg-10 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 - router instances, routes, 19 routing tables, 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 January 14, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 57 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5 58 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 60 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. The Design of the Core Routing Data Model . . . . . . . . . . 9 62 4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 4.1.1. Parameters of IPv6 Router Interfaces . . . . . . . . . 13 64 4.2. Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 15 66 4.3.1. User-Defined Routing Tables . . . . . . . . . . . . . 16 67 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 17 68 4.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 17 69 4.4.2. Defining New Routing Protocols . . . . . . . . . . . . 18 70 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 19 71 4.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 20 72 5. Interactions with Other YANG Modules . . . . . . . . . . . . . 21 73 5.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 21 74 5.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 21 75 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 23 76 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 42 77 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 46 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 61 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 63 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 63 84 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . . 64 85 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . . 64 86 A.2. Operational State Data . . . . . . . . . . . . . . . . . . 65 87 Appendix B. Example: Adding a New Routing Protocol . . . . . . . 68 88 Appendix C. Example: NETCONF Reply . . . . . . . . . . . . 71 89 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 77 90 D.1. Changes Between Versions -09 and -10 . . . . . . . . . . . 77 91 D.2. Changes Between Versions -08 and -09 . . . . . . . . . . . 77 92 D.3. Changes Between Versions -07 and -08 . . . . . . . . . . . 77 93 D.4. Changes Between Versions -06 and -07 . . . . . . . . . . . 77 94 D.5. Changes Between Versions -05 and -06 . . . . . . . . . . . 78 95 D.6. Changes Between Versions -04 and -05 . . . . . . . . . . . 78 96 D.7. Changes Between Versions -03 and -04 . . . . . . . . . . . 79 97 D.8. Changes Between Versions -02 and -03 . . . . . . . . . . . 79 98 D.9. Changes Between Versions -01 and -02 . . . . . . . . . . . 80 99 D.10. Changes Between Versions -00 and -01 . . . . . . . . . . . 80 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 82 102 1. Introduction 104 This document contains a specification of the following YANG modules: 106 o Module "ietf-routing" provides generic components of a routing 107 data model. 109 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 110 module with additional data specific to IPv4 unicast. 112 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 113 module with additional data specific to IPv6 unicast, including 114 the router configuration variables required by [RFC4861]. 116 These modules together define the so-called core routing data model, 117 which is proposed as a basis for the development of data models for 118 configuration and management of more sophisticated routing systems. 119 While these three modules can be directly used for simple IP devices 120 with static routing, their main purpose is to provide essential 121 building blocks for more complicated setups involving multiple 122 routing protocols, multicast routing, additional address families, 123 and advanced functions such as route filtering or policy routing. To 124 this end, it is expected that the core routing data model will be 125 augmented by numerous modules developed by other IETF working groups. 127 2. Terminology and Notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 The following terms are defined in [RFC6241]: 135 o client 137 o message 139 o protocol operation 141 o server 143 The following terms are defined in [RFC6020]: 145 o augment 147 o configuration data 149 o data model 151 o data node 153 o feature 155 o mandatory node 157 o module 159 o state data 161 o RPC operation 163 2.1. Glossary of New Terms 165 active route: a route that is actually used for sending packets. If 166 there are multiple candidate routes with a matching destination 167 prefix, then it is up to the routing algorithm to select the 168 active route (or several active routes in the case of multi-path 169 routing). 171 core routing data model: YANG data model resulting from the 172 combination of "ietf-routing", "ietf-ipv4-unicast-routing" and 173 "ietf-ipv6-unicast-routing" modules. 175 direct route: a route to a directly connected network. 177 system-controlled entry: An entry of a list in operational state 178 data ("config false") that is created by the system independently 179 of what has been explicitly configured. An example is the default 180 routing table. A client cannot cause this entry to be deleted but 181 may be able to configure it. 183 user-controlled entry: An entry of a list in operational state data 184 ("config false") that is created and deleted as a direct 185 consequence of certain configuration changes. An example is an 186 additional user-defined routing table. 188 2.2. Tree Diagrams 190 A simplified graphical representation of the complete data tree is 191 presented in Appendix A, and similar diagrams of its various subtrees 192 appear in the main text. The meaning of the symbols in these 193 diagrams is as follows: 195 o Brackets "[" and "]" enclose list keys. 197 o Abbreviations before data node names: "rw" means configuration 198 (read-write) and "ro" state data (read-only). 200 o Symbols after data node names: "?" means an optional node and "*" 201 denotes a "list" or "leaf-list". 203 o Parentheses enclose choice and case nodes, and case nodes are also 204 marked with a colon (":"). 206 o Ellipsis ("...") stands for contents of subtrees that are not 207 shown. 209 2.3. Prefixes in Data Node Names 211 In this document, names of data nodes, RPC methods and other data 212 model objects are used mostly without a prefix, as long as it is 213 clear from the context in which YANG module each name is defined. 214 Otherwise, names are prefixed using the standard prefix associated 215 with the corresponding YANG module, as shown in Table 1. 217 +--------+---------------------------+--------------+ 218 | Prefix | YANG module | Reference | 219 +--------+---------------------------+--------------+ 220 | ianaaf | iana-afn-safi | [IANA-AF] | 221 | | | | 222 | if | ietf-interfaces | [YANG-IF] | 223 | | | | 224 | ip | ietf-ip | [YANG-IP] | 225 | | | | 226 | rt | ietf-routing | Section 6 | 227 | | | | 228 | v4ur | ietf-ipv4-unicast-routing | Section 7 | 229 | | | | 230 | v6ur | ietf-ipv6-unicast-routing | Section 8 | 231 | | | | 232 | yang | ietf-yang-types | [RFC6021bis] | 233 | | | | 234 | inet | ietf-inet-types | [RFC6021bis] | 235 +--------+---------------------------+--------------+ 237 Table 1: Prefixes and corresponding YANG modules 239 3. Objectives 241 The initial design of the core routing data model was driven by the 242 following objectives: 244 o The data model should be suitable for the common address families, 245 in particular IPv4 and IPv6, and for unicast and multicast 246 routing, as well as Multiprotocol Label Switching (MPLS). 248 o Simple routing setups, such as static routing, should be 249 configurable in a simple way, ideally without any need to develop 250 additional YANG modules. 252 o On the other hand, the core routing framework must allow for 253 complicated setups involving multiple routing tables and multiple 254 routing protocols, as well as controlled redistributions of 255 routing information. 257 o Device vendors will want to map the data models built on this 258 generic framework to their proprietary data models and 259 configuration interfaces. Therefore, the framework should be 260 flexible enough to facilitate such a mapping and accommodate data 261 models with different logic. 263 4. The Design of the Core Routing Data Model 265 The core routing data model consists of three YANG modules. The 266 first module, "ietf-routing", defines the generic components of a 267 routing system. The other two modules, "ietf-ipv4-unicast-routing" 268 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 269 with additional data nodes that are needed for IPv4 and IPv6 unicast 270 routing, respectively. Figures 1 and 2 show abridged views of the 271 configuration and operational state data hierarchies. See Appendix A 272 for the complete data trees. 274 +--rw routing 275 +--rw router* [name] 276 | +--rw name 277 | +--rw type? 278 | +--rw enabled? 279 | +--rw router-id? 280 | +--rw description? 281 | +--rw default-routing-tables 282 | | +--rw default-routing-table* [address-family safi] 283 | | +--rw address-family 284 | | +--rw safi 285 | | +--rw name 286 | +--rw interfaces 287 | | +--rw interface* [name] 288 | | +--rw name 289 | | +--rw v6ur:ipv6-router-advertisements 290 | | ... 291 | +--rw routing-protocols 292 | +--rw routing-protocol* [name] 293 | +--rw name 294 | +--rw description? 295 | +--rw enabled? 296 | +--rw type 297 | +--rw connected-routing-tables 298 | | ... 299 | +--rw static-routes 300 | ... 301 +--rw routing-tables 302 | +--rw routing-table* [name] 303 | +--rw name 304 | +--rw address-family 305 | +--rw safi 306 | +--rw description? 307 | +--rw recipient-routing-tables 308 | +--rw recipient-routing-table* [name] 309 | ... 310 +--rw route-filters 311 +--rw route-filter* [name] 312 +--rw name 313 +--rw description? 314 +--rw type 316 Figure 1: Configuration data hierarchy. 318 +--ro routing-state 319 +--ro router* [name] 320 | +--ro name 321 | +--ro type? 322 | +--ro router-id? 323 | +--ro default-routing-tables 324 | | +--ro default-routing-table* [address-family safi] 325 | | +--ro address-family 326 | | +--ro safi 327 | | +--ro name 328 | +--ro interfaces 329 | | +--ro interface* [name] 330 | | +--ro name 331 | | +--ro v6ur:ipv6-router-advertisements 332 | | ... 333 | +--ro routing-protocols 334 | +--ro routing-protocol* [name] 335 | +--ro name 336 | +--ro type 337 | +--ro connected-routing-tables 338 | ... 339 +--ro routing-tables 340 | +--ro routing-table* [name] 341 | +--ro name 342 | +--ro address-family 343 | +--ro safi 344 | +--ro routes 345 | | +--ro route* 346 | | ... 347 | +--ro recipient-routing-tables 348 | +--ro recipient-routing-table* [name] 349 | ... 350 +--ro route-filters 351 +--ro route-filter* [name] 352 +--ro name 353 +--ro type 355 Figure 2: Operational state data hierarchy. 357 As can be seen from Figures 1 and 2, the core routing data model 358 introduces several generic components of a routing framework: 359 routers, routing tables containing lists of routes, routing protocols 360 and route filters. The following subsections describe these 361 components in more detail. 363 By combining the components in various ways, and possibly augmenting 364 them with appropriate contents defined in other modules, various 365 routing systems can be realized. 367 +--------+ 368 | direct | +---+ +--------------+ +---+ +--------------+ 369 | routes |--->| F |--->| |<---| F |<---| | 370 +--------+ +---+ | default | +---+ | additional | 371 | routing | | routing | 372 +--------+ +---+ | table | +---+ | table | 373 | static |--->| F |--->| |--->| F |--->| | 374 | routes | +---+ +--------------+ +---+ +--------------+ 375 +--------+ ^ | ^ | 376 | v | v 377 +---+ +---+ +---+ +---+ 378 | F | | F | | F | | F | 379 +---+ +---+ +---+ +---+ 380 ^ | ^ | 381 | v | v 382 +----------+ +----------+ 383 | routing | | routing | 384 | protocol | | protocol | 385 +----------+ +----------+ 387 Figure 3: Example setup of a routing system 389 The example in Figure 3 shows a typical (though certainly not the 390 only possible) organization of a more complex routing subsystem for a 391 single address family. Several of its features are worth mentioning: 393 o Along with the default routing table, which is always present, an 394 additional routing table is configured. 396 o Each routing protocol instance, including the "static" and 397 "direct" pseudo-protocols, is connected to one routing table with 398 which it can exchange routes (in both directions, except for the 399 "static" and "direct" pseudo-protocols). 401 o Routing tables may also be connected to each other and exchange 402 routes in either direction (or both). 404 o Route exchanges along all connections may be controlled by means 405 of route filters, denoted by "F" in Figure 3. 407 4.1. Router 409 Each router instance in the core routing data model represents a 410 logical router. The exact semantics of this term is left to 411 implementations. For example, router instances may be completely 412 isolated virtual routers or, alternatively, they may internally share 413 certain information. 415 A router instance together with its operational status is represented 416 as an entry of the list "/routing-state/router", and identified by a 417 unique name. Configuration of that router instance appears as entry 418 of the list "/routing/router" whose key is the router instance name. 420 An implementation MAY support multiple types of logical routers 421 simultaneously. Instances of all router types are organized as 422 entries of the same flat "router" list. In order to discriminate 423 router instances belonging to different types, the "type" leaf is 424 defined as a child of the "router" node. 426 An implementation MAY create one or more system-controlled router 427 entries, and MAY also pose restrictions on allowed router types and 428 on the number of supported instances for each type. For example, a 429 simple router implementation may support only one system-controlled 430 router instance of the default type "standard-router" and may not 431 allow creation of any user-controlled instances. 433 Each network layer interface has to be assigned to one or more router 434 instances in order to be able to participate in packet forwarding, 435 routing protocols and other operations of those router instances. 436 The assignment is accomplished by creating a corresponding entry in 437 the list of router interfaces ("rt:interface"). The key of the list 438 entry is the name of a configured network layer interface, see the 439 "ietf-interfaces" module [YANG-IF]. 441 In YANG terms, the list of router interfaces is modeled as the "list" 442 node rather than "leaf-list" in order to allow for adding, via 443 augmentation, other configuration or state data related to the 444 corresponding router interface. 446 Implementations MAY specify additional rules for the assignment of 447 interfaces to logical routers. For example, it may be required that 448 the sets of interfaces assigned to different logical routers be 449 disjoint. 451 4.1.1. Parameters of IPv6 Router Interfaces 453 The module "ietf-ipv6-unicast-routing" augments the definition of the 454 data node "rt:interface", in both configuration and operational state 455 data, with definitions of the following variables as required by 456 [RFC4861], sec. 6.2.1: 458 o send-advertisements, 460 o max-rtr-adv-interval, 461 o min-rtr-adv-interval, 463 o managed-flag, 465 o other-config-flag, 467 o link-mtu, 469 o reachable-time, 471 o retrans-timer, 473 o cur-hop-limit, 475 o default-lifetime, 477 o prefix-list: a list of prefixes to be advertised. 479 The following parameters are associated with each prefix in the 480 list: 482 * valid-lifetime, 484 * on-link-flag, 486 * preferred-lifetime, 488 * autonomous-flag. 490 The definitions and descriptions of the above parameters can be found 491 in the text of the module "ietf-ipv6-unicast-routing" (Section 8). 493 NOTES: 495 1. The "IsRouter" flag, which is also required by [RFC4861], is 496 implemented in the "ietf-ip" module [YANG-IP] (leaf "ip: 497 forwarding"). 499 2. The original specification [RFC4861] allows the implementations 500 to decide whether the "valid-lifetime" and "preferred-lifetime" 501 parameters remain the same in consecutive advertisements, or 502 decrement in real time. However, the latter behavior seems 503 problematic because the values might be reset again to the 504 (higher) configured values after a configuration is reloaded. 505 Moreover, no implementation is known to use the decrementing 506 behavior. The "ietf-ipv6-unicast-routing" module therefore 507 assumes the former behavior with constant values. 509 4.2. Routes 511 Routes are basic elements of information in a routing system. The 512 core routing data model defines only the following minimal set of 513 route attributes: 515 o "dest-prefix": IP prefix specifying the set of destination 516 addresses for which the route may be used. This attribute is 517 mandatory. 519 o "next-hop": IP address of an adjacent router or host to which 520 packets with destination addresses belonging to "dest-prefix" 521 should be sent. 523 o "outgoing-interface": network interface that should be used for 524 sending packets with destination addresses belonging to "dest- 525 prefix". 527 The above list of route attributes suffices for a simple static 528 routing configuration. It is expected that future modules defining 529 routing protocols will add other route attributes such as metrics or 530 preferences. 532 Routes and their attributes are used both in configuration data, for 533 example as manually configured static routes, and in operational 534 state data, for example as entries in routing tables. 536 4.3. Routing Tables 538 Routing tables are lists of routes complemented with administrative 539 data, namely: 541 o "source-protocol": type of the routing protocol from which the 542 route was originally obtained. 544 o "last-updated": the date and time when the route was last updated, 545 or inserted into the routing table. 547 Each routing table must contain only routes of the same address 548 family. Address family information consists of two parameters - 549 "address-family" and "safi" (Subsequent Address Family Identifier, 550 SAFI). The permitted values for these two parameters are defined by 551 IANA and represented using YANG enumeration datatypes "ianaaf: 552 address-family" and "ianaaf:subsequent-address-family" [IANA-AF]. 554 In the core routing data model, routing tables are operational state 555 data represented as entries of the list "/routing-state/ 556 routing-tables/routing-table". The contents of routing tables are 557 controlled and manipulated by routing protocol operations which may 558 result in route additions, removals and modifications. This also 559 includes manipulations via the "static" and/or "direct" pseudo- 560 protocols, see Section 4.4.1. 562 Routing tables are global, which means that a routing table may be 563 used by any or all router instances. However, an implementation MAY 564 specify rules and restrictions for sharing routing tables among 565 router instances. 567 Each router instance must have, for every supported address family, 568 one routing table selected as the so-called default routing table. 569 This selection is recorded in the list "default-routing-table". The 570 role of default routing tables is explained in Section 4.4. 572 Simple router implementations will typically create one system- 573 controlled routing table per supported address family, and declare it 574 as a default routing table (via a system-controlled entry of the 575 "default-routing-table" list). 577 4.3.1. User-Defined Routing Tables 579 More complex router implementations allow for multiple routing tables 580 per address family that are used for policy routing and other 581 purposes. If it is the case, the NETCONF server SHALL advertise the 582 feature "user-defined-routing-tables". This feature activates 583 additional nodes in both configuration and operational state data, 584 and enables the client to: 586 o Configure new user-controlled routing tables by creating entries 587 in the "/routing/routing-tables/routing-table" list. 589 o Configure any (system-controlled or user-controlled) routing table 590 as the default routing table for an address family. 592 o Connect a routing protocol instance to a non-default routing table 593 (see Section 4.4). 595 o Configure a routing table as a recipient routing table of another 596 routing table (see below). 598 Every routing table can serve as a source of routes for other routing 599 tables of the same address family. To achieve this, one or more 600 recipient routing tables may be specified in the configuration of the 601 source routing table. Optionally, a route filter may be configured 602 for any or all recipient routing tables. Such a route filter then 603 selects and/or manipulates the routes that are passed between the 604 source and recipient routing table. 606 A routing table MUST NOT appear among its own recipient routing 607 tables. 609 4.4. Routing Protocols 611 The core routing data model provides an open-ended framework for 612 defining multiple routing protocol instances within a router 613 instance. Each routing protocol instance MUST be assigned a type, 614 which is an identity derived from the "rt:routing-protocol" base 615 identity. The core routing data model defines two identities for the 616 direct and static pseudo-protocols (Section 4.4.1). 618 Each routing protocol instance is connected to exactly one routing 619 table for each address family that the routing protocol instance 620 supports. Routes learned from the network by a routing protocol are 621 normally installed into the connected routing table(s) and, 622 conversely, routes from the connected routing table(s) are normally 623 injected into the routing protocol. However, routing protocol 624 implementations MAY specify rules that restrict this exchange of 625 routes in either direction (or both directions). 627 On devices supporting the "user-defined-routing-tables" feature, a 628 routing table (system-controlled or user-controlled) is connected to 629 a routing protocol instance by configuring a corresponding entry in 630 the "connected-routing-table" list. If such an entry is not 631 configured for an address family, then the default routing table MUST 632 be used as the connected routing table for this address family. 634 In addition, two independent route filters (see Section 4.5) may be 635 configured for each connected routing table to apply client-defined 636 policies controlling the exchange of routes in both directions 637 between the routing protocol instance and the connected routing 638 table: 640 o import filter controls which routes are passed from the routing 641 protocol instance to the connected routing table, 643 o export filter controls which routes the routing protocol instance 644 receives from the connected routing table. 646 Note that the terms import and export are used from the viewpoint of 647 a routing table. 649 4.4.1. Routing Pseudo-Protocols 651 The core routing data model defines two special routing protocol 652 types - "direct" and "static". Both are in fact pseudo-protocols, 653 which means that they are confined to the local device and do not 654 exchange any routing information with neighboring routers. Routes 655 from both "direct" and "static" protocol instances are passed to the 656 connected routing table (subject to route filters, if any), but an 657 exchange in the opposite direction is not allowed. 659 Every router instance MUST implement exactly one instance of the 660 "direct" pseudo-protocol type. The name of this instance MUST also 661 be "direct". It is the source of direct routes for all configured 662 address families. Direct routes are normally supplied by the 663 operating system kernel, based on the configuration of network 664 interface addresses, see Section 5.2. The "direct" pseudo-protocol 665 MUST always be connected to the default routing tables of all 666 supported address families. Unlike other routing protocol types, 667 this connection cannot be changed in the configuration. Direct 668 routes MAY be filtered before they appear in the default routing 669 table. 671 A pseudo-protocol of the type "static" allows for specifying routes 672 manually. It MAY be configured in zero or multiple instances, 673 although a typical configuration will have exactly one instance per 674 logical router. 676 Static routes are configured within the "static-routes" container, 677 see Figure 4. 679 +--rw static-routes 680 +--rw v4ur:ipv4 681 | +--rw v4ur:route* [id] 682 | +--rw v4ur:id 683 | +--rw v4ur:description? 684 | +--rw v4ur:outgoing-interface? 685 | +--rw v4ur:dest-prefix 686 | +--rw v4ur:next-hop? 687 +--rw v6ur:ipv6 688 +--rw v6ur:route* [id] 689 +--rw v6ur:id 690 +--rw v6ur:description? 691 +--rw v6ur:outgoing-interface? 692 +--rw v6ur:dest-prefix 693 +--rw v6ur:next-hop? 695 Figure 4: Structure of "static-routes" subtree. 697 4.4.2. Defining New Routing Protocols 699 It is expected that future YANG modules will create data models for 700 additional routing protocol types. Such a new module has to define 701 the protocol-specific configuration and state data, and it has to fit 702 it into the core routing framework in the following way: 704 o A new identity MUST be defined for the routing protocol and its 705 base identity MUST be set to "rt:routing-protocol", or to an 706 identity derived from "rt:routing-protocol". 708 o Additional route attributes MAY be defined, preferably in one 709 place by means of defining a YANG grouping. The new attributes 710 have to be inserted as state data by augmenting the definitions of 711 the nodes 713 /rt:routing-tables/rt:routing-table/rt:route 715 and 717 /rt:active-route/rt:output/rt:route, 719 and possibly other places in the configuration, state data and RPC 720 input or output. 722 o Configuration parameters and/or state data for the new protocol 723 can be defined by augmenting the "routing-protocol" data node 724 under both "/routing" and "/routing-state". 726 o Per-interface configuration, including activation of the routing 727 protocol on individual interfaces, can use references to entries 728 in the list of router interfaces (rt:interface). 730 By using the "when" statement, the augmented configuration parameters 731 and state data specific to the new protocol SHOULD be made 732 conditional and valid only if the value of "rt:type" or "rt:source- 733 protocol" is equal to the new protocol's identity. It is also 734 RECOMMENDED that the protocol-specific data be encapsulated in 735 appropriately named containers. 737 The above steps are implemented by the example YANG module for the 738 RIP routing protocol in Appendix B. 740 4.5. Route Filters 742 The core routing data model provides a skeleton for defining route 743 filters that can be used to restrict the set of routes being 744 exchanged between a routing protocol instance and a connected routing 745 table, or between a source and a recipient routing table. Route 746 filters may also manipulate routes, i.e., add, delete, or modify 747 their attributes. 749 Route filters are global, which means that a configured route filter 750 may be used by any or all router instances. However, an 751 implementation MAY specify rules and restrictions for sharing route 752 filters among router instances. 754 By itself, the route filtering framework defined in this document 755 allows for applying only two extreme routing policies which are 756 represented by the following pre-defined route filter types: 758 o "deny-all-route-filter": all routes are blocked, 760 o "allow-all-route-filter": all routes are permitted. 762 The latter type is equivalent to no route filter. 764 It is expected that more comprehensive route filtering frameworks 765 will be developed separately. 767 Each route filter is identified by a unique name. Its type MUST be 768 specified by the "type" identity reference - this opens the space for 769 multiple route filtering framework implementations. 771 4.6. RPC Operations 773 The "ietf-routing" module defines two RPC operations: 775 o active-route: query the routing system for the active route(s) 776 that are currently used for sending datagrams to a destination 777 host whose address is passed as an input parameter. 779 o route-count: retrieve the total number of entries in a routing 780 table. 782 5. Interactions with Other YANG Modules 784 The semantics of the core routing data model also depend on several 785 configuration parameters that are defined in other YANG modules. 787 5.1. Module "ietf-interfaces" 789 The following boolean switch is defined in the "ietf-interfaces" YANG 790 module [YANG-IF]: 792 /if:interfaces/if:interface/if:enabled 794 If this switch is set to "false" for a given network layer 795 interface, the device MUST behave exactly as if that interface was 796 not assigned to any logical router at all. 798 5.2. Module "ietf-ip" 800 The following boolean switches are defined in the "ietf-ip" YANG 801 module [YANG-IP]: 803 /if:interfaces/if:interface/ip:ipv4/ip:enabled 805 If this switch is set to "false" for a given interface, then all 806 IPv4 routing functions related to that interface MUST be disabled. 808 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 810 If this switch is set to "false" for a given interface, then the 811 forwarding of IPv4 datagrams to and from this interface MUST be 812 disabled. However, the interface may participate in other routing 813 functions, such as routing protocols. 815 /if:interfaces/if:interface/ip:ipv6/ip:enabled 817 If this switch is set to "false" for a given interface, then all 818 IPv6 routing functions related to that interface MUST be disabled. 820 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 822 If this switch is set to "false" for a given interface, then the 823 forwarding of IPv6 datagrams to and from this interface MUST be 824 disabled. However, the interface may participate in other routing 825 functions, such as routing protocols. 827 In addition, the "ietf-ip" module allows for configuring IPv4 and 828 IPv6 addresses and network prefixes or masks on network layer 829 interfaces. Configuration of these parameters on an enabled 830 interface MUST result in an immediate creation of the corresponding 831 direct route. The destination prefix of this route is set according 832 to the configured IP address and network prefix/mask, and the 833 interface is set as the outgoing interface for that route. 835 6. Routing YANG Module 837 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 838 actual RFC number and all occurrences of the revision date below with 839 the date of RFC publication (and remove this note). 841 file "ietf-routing@2013-07-13.yang" 843 module ietf-routing { 845 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 847 prefix "rt"; 849 import ietf-yang-types { 850 prefix "yang"; 851 } 853 import ietf-interfaces { 854 prefix "if"; 855 } 857 import iana-afn-safi { 858 prefix "ianaaf"; 859 } 861 organization 862 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 864 contact 865 "WG Web: 866 WG List: 868 WG Chair: David Kessens 869 871 WG Chair: Juergen Schoenwaelder 872 874 Editor: Ladislav Lhotka 875 876 "; 878 description 879 "This YANG module defines essential components for the management 880 of a routing subsystem. 882 Copyright (c) 2013 IETF Trust and the persons identified as 883 authors of the code. All rights reserved. 885 Redistribution and use in source and binary forms, with or 886 without modification, is permitted pursuant to, and subject to 887 the license terms contained in, the Simplified BSD License set 888 forth in Section 4.c of the IETF Trust's Legal Provisions 889 Relating to IETF Documents 890 (http://trustee.ietf.org/license-info). 892 This version of this YANG module is part of RFC XXXX; see the 893 RFC itself for full legal notices. 894 "; 896 revision 2013-07-13 { 897 description 898 "Initial revision."; 899 reference 900 "RFC XXXX: A YANG Data Model for Routing Management"; 901 } 903 /* Features */ 905 feature user-defined-routing-tables { 906 description 907 "Indicates that the device supports additional routing tables 908 defined by the user. 910 Devices that do not support this feature MUST provide exactly 911 one routing table per supported address family. These routing 912 tables then appear as entries of the list 913 /routing-state/routing-tables/routing-table. 914 "; 915 } 917 /* Identities */ 919 identity router-type { 920 description 921 "Base identity from which router type identities are derived. 923 It is primarily intended for discriminating among different 924 types of logical routers or router virtualization. 925 "; 926 } 928 identity standard-router { 929 base router-type; 930 description 931 "This identity represents a standard router."; 932 } 934 identity routing-protocol { 935 description 936 "Base identity from which routing protocol identities are 937 derived."; 938 } 940 identity direct { 941 base routing-protocol; 942 description 943 "Routing pseudo-protocol which provides routes to directly 944 connected networks."; 945 } 947 identity static { 948 base routing-protocol; 949 description 950 "Static routing pseudo-protocol."; 951 } 953 identity route-filter { 954 description 955 "Base identity from which all route filters are derived."; 956 } 958 identity deny-all-route-filter { 959 base route-filter; 960 description 961 "Route filter that blocks all routes."; 962 } 964 identity allow-all-route-filter { 965 base route-filter; 966 description 967 "Route filter that permits all routes."; 968 } 970 /* Type Definitions */ 972 typedef router-ref { 973 type leafref { 974 path "/rt:routing/rt:router/rt:name"; 975 } 976 description 977 "This type is used for leafs that reference a router instance 978 configuration."; 980 } 982 typedef router-state-ref { 983 type leafref { 984 path "/rt:routing-state/rt:router/rt:name"; 985 } 986 description 987 "This type is used for leafs that reference state data of a 988 router instance."; 989 } 991 typedef routing-table-ref { 992 type leafref { 993 path "/rt:routing/rt:routing-tables/rt:routing-table/rt:name"; 994 } 995 description 996 "This type is used for leafs that reference a routing table 997 configuration."; 998 } 1000 typedef routing-table-state-ref { 1001 type leafref { 1002 path "/rt:routing-state/rt:routing-tables/rt:routing-table/" 1003 + "rt:name"; 1004 } 1005 description 1006 "This type is used for leafs that reference a routing table in 1007 state data."; 1008 } 1010 typedef route-filter-ref { 1011 type leafref { 1012 path "/rt:routing/rt:route-filters/rt:route-filter/rt:name"; 1013 } 1014 description 1015 "This type is used for leafs that reference a route filter 1016 configuration."; 1017 } 1019 typedef route-filter-state-ref { 1020 type leafref { 1021 path "/rt:routing-state/rt:route-filters/rt:route-filter/" 1022 + "rt:name"; 1023 } 1024 description 1025 "This type is used for leafs that reference a route filter in 1026 state data."; 1027 } 1028 /* Groupings */ 1030 grouping afn-safi { 1031 description 1032 "This grouping provides two parameters specifying address 1033 family and subsequent address family."; 1034 leaf address-family { 1035 type ianaaf:address-family; 1036 mandatory "true"; 1037 description 1038 "Address family."; 1039 } 1040 leaf safi { 1041 type ianaaf:subsequent-address-family; 1042 mandatory "true"; 1043 description 1044 "Subsequent address family."; 1045 } 1046 } 1048 grouping router-id { 1049 description 1050 "This grouping provides the definition of router ID."; 1051 leaf router-id { 1052 type yang:dotted-quad; 1053 description 1054 "Router ID - 32-bit number in the form of a dotted quad."; 1055 } 1056 } 1058 grouping route-content { 1059 description 1060 "Generic parameters of static routes (configuration)."; 1061 leaf outgoing-interface { 1062 type if:interface-ref; 1063 description 1064 "Outgoing interface."; 1065 } 1066 } 1068 grouping route-state-content { 1069 description 1070 "Generic parameters of routes in state data."; 1071 leaf outgoing-interface { 1072 type if:interface-state-ref; 1073 description 1074 "Outgoing interface."; 1075 } 1077 } 1079 /* RPC Methods */ 1081 rpc active-route { 1082 description 1083 "Return the active route (or multiple routes, in the case of 1084 multi-path routing) to a destination address. 1086 Parameters 1088 1. 'router-name', 1090 2. 'destination-address'. 1092 If the router instance with 'router-name' doesn't exist, then 1093 this operation SHALL fail with error-tag 'data-missing' and 1094 error-app-tag 'router-not-found'. 1096 If no active route for 'destination-address' exists, no output 1097 is returned - the server SHALL send an containing 1098 a single element . 1099 "; 1100 input { 1101 leaf router-name { 1102 type router-state-ref; 1103 mandatory "true"; 1104 description 1105 "Name of the router instance whose forwarding information 1106 base is being queried."; 1107 } 1108 container destination-address { 1109 description 1110 "Network layer destination address. 1112 Address family specific modules MUST augment this 1113 container with a leaf named 'address'. 1114 "; 1115 uses afn-safi; 1116 } 1117 } 1118 output { 1119 list route { 1120 description 1121 "List of active routes. 1123 Route contents specific for each address family is 1124 expected be defined through augmenting. 1126 "; 1127 uses afn-safi; 1128 uses route-content; 1129 } 1130 } 1131 } 1133 rpc route-count { 1134 description 1135 "Return the current number of routes in a routing table. 1137 Parameters: 1139 1. 'routing-table-name'. 1141 If the routing table with the name specified in 1142 'routing-table-name' doesn't exist, then this operation SHALL 1143 fail with error-tag 'data-missing' and error-app-tag 1144 'routing-table-not-found'. 1145 "; 1146 input { 1147 leaf routing-table { 1148 type routing-table-state-ref; 1149 mandatory "true"; 1150 description 1151 "Name of the routing table."; 1152 } 1153 } 1154 output { 1155 leaf number-of-routes { 1156 type uint32; 1157 mandatory "true"; 1158 description 1159 "Number of routes in the routing table."; 1160 } 1161 } 1162 } 1164 /* Operational state data */ 1166 container routing-state { 1167 config "false"; 1168 description 1169 "Operational state of the routing subsystem."; 1170 list router { 1171 key "name"; 1172 description 1173 "Each list entry is a container for operational state data of 1174 a router instance. 1176 An implementation MAY create one or more instances on its 1177 own, other instances MAY be created by configuration. 1178 "; 1179 leaf name { 1180 type string; 1181 description 1182 "The name of the router instance."; 1183 } 1184 leaf type { 1185 type identityref { 1186 base router-type; 1187 } 1188 default "rt:standard-router"; 1189 description 1190 "The router type, primarily intended for discriminating 1191 among different types of logical routers, route 1192 virtualization, master-slave arrangements etc., while 1193 keeping all router instances in the same flat list. 1194 "; 1195 } 1196 uses router-id { 1197 description 1198 "Global router ID. 1200 An implementation may choose a value if none is 1201 configured. 1203 Routing protocols MAY override this global parameter. 1204 "; 1205 } 1206 container default-routing-tables { 1207 description 1208 "Default routing tables used by the router instance."; 1209 list default-routing-table { 1210 key "address-family safi"; 1211 description 1212 "Each list entry specifies the default routing table for 1213 one address family. 1215 The default routing table is operationally connected to 1216 all routing protocols for which a connected routing 1217 table has not been explicitly configured. 1219 The 'direct' pseudo-protocol is always connected to the 1220 default routing tables. 1221 "; 1223 uses afn-safi; 1224 leaf name { 1225 type routing-table-state-ref; 1226 mandatory "true"; 1227 description 1228 "Name of an existing routing table to be used as the 1229 default routing table for the given router instance 1230 and address family."; 1231 } 1232 } 1233 } 1234 container interfaces { 1235 description 1236 "Router interfaces."; 1237 list interface { 1238 key "name"; 1239 description 1240 "List of network layer interfaces assigned to the router 1241 instance."; 1242 leaf name { 1243 type if:interface-state-ref; 1244 description 1245 "A reference to the name of a configured network layer 1246 interface."; 1247 } 1248 } 1249 } 1250 container routing-protocols { 1251 description 1252 "Container for the list of routing protocol instances."; 1253 list routing-protocol { 1254 key "name"; 1255 description 1256 "Operational state of a routing protocol instance. 1257 "; 1258 leaf name { 1259 type string; 1260 description 1261 "The name of the routing protocol instance."; 1262 } 1263 leaf type { 1264 type identityref { 1265 base routing-protocol; 1266 } 1267 mandatory "true"; 1268 description 1269 "Type of the routing protocol."; 1270 } 1271 container connected-routing-tables { 1272 if-feature user-defined-routing-tables; 1273 description 1274 "Container for connected routing tables. 1275 "; 1276 list connected-routing-table { 1277 key "name"; 1278 description 1279 "List of routing tables to which the routing protocol 1280 instance is connected (at most one routing table per 1281 address family). 1282 "; 1283 leaf name { 1284 type routing-table-state-ref; 1285 description 1286 "Name of an existing routing table."; 1287 } 1288 leaf import-filter { 1289 type route-filter-state-ref; 1290 description 1291 "Reference to a route filter that is used for 1292 filtering routes passed from this routing protocol 1293 instance to the routing table specified by the 1294 'name' sibling node. 1296 If this leaf is not present, the behavior is 1297 protocol-specific, but typically it means that all 1298 routes are accepted. 1299 "; 1300 } 1301 leaf export-filter { 1302 type route-filter-state-ref; 1303 description 1304 "Reference to a route filter that is used for 1305 filtering routes passed from the routing table 1306 specified by the 'name' sibling node to this 1307 routing protocol instance. 1309 If this leaf is not present, the behavior is 1310 protocol-specific - typically it means that all 1311 routes are accepted. 1313 The 'direct' and 'static' pseudo-protocols accept 1314 no routes from any routing table. 1315 "; 1316 } 1317 } 1318 } 1320 } 1321 } 1322 } 1323 container routing-tables { 1324 description 1325 "Container for routing tables."; 1326 list routing-table { 1327 key "name"; 1328 description 1329 "Each entry represents a routing table identified by the 1330 'name' key. All routes in a routing table MUST belong to 1331 the same address family. 1333 The server MUST create the default routing table for each 1334 address family, and MAY create other routing tables. 1335 Additional routing tables MAY be created in the 1336 configuration. 1337 "; 1338 leaf name { 1339 type string; 1340 description 1341 "The name of the routing table."; 1342 } 1343 uses afn-safi; 1344 container routes { 1345 description 1346 "Current contents of the routing table."; 1347 list route { 1348 description 1349 "A routing table entry. This data node MUST be 1350 augmented with information specific for routes of each 1351 address family."; 1352 uses route-state-content; 1353 leaf source-protocol { 1354 type identityref { 1355 base routing-protocol; 1356 } 1357 mandatory "true"; 1358 description 1359 "Type of the routing protocol from which the route 1360 originated."; 1361 } 1362 leaf last-updated { 1363 type yang:date-and-time; 1364 description 1365 "Time stamp of the last modification of the route. If 1366 the route was never modified, it is the time when 1367 the route was inserted into the routing table."; 1369 } 1370 } 1371 } 1372 container recipient-routing-tables { 1373 if-feature user-defined-routing-tables; 1374 description 1375 "Container for recipient routing tables."; 1376 list recipient-routing-table { 1377 key "name"; 1378 description 1379 "List of routing tables that receive routes from this 1380 routing table."; 1381 leaf name { 1382 type routing-table-state-ref; 1383 description 1384 "The name of the recipient routing table."; 1385 } 1386 leaf filter { 1387 type route-filter-state-ref; 1388 description 1389 "A route filter which is applied to the routes passed 1390 to the recipient routing table."; 1391 } 1392 } 1393 } 1394 } 1395 } 1396 container route-filters { 1397 description 1398 "Container for route filters."; 1399 list route-filter { 1400 key "name"; 1401 description 1402 "Route filters are used for filtering and/or manipulating 1403 routes that are passed between a routing protocol and a 1404 routing table and vice versa, or between two routing 1405 tables. 1407 It is expected that other modules augment this list with 1408 contents specific for a particular route filter type. 1409 "; 1410 leaf name { 1411 type string; 1412 description 1413 "The name of the route filter."; 1414 } 1415 leaf type { 1416 type identityref { 1417 base route-filter; 1418 } 1419 mandatory "true"; 1420 description 1421 "Type of the route-filter - an identity derived from the 1422 'route-filter' base identity."; 1423 } 1424 } 1425 } 1426 } 1428 /* Configuration Data */ 1430 container routing { 1431 description 1432 "Configuration parameters for the routing subsystem."; 1433 list router { 1434 key "name"; 1435 description 1436 "Configuration of a router instance. 1437 "; 1438 leaf name { 1439 type string; 1440 description 1441 "The name of the router instance. 1443 The names for system-created router instances are assigned 1444 by the system. The same name then has to be used in the 1445 configuration. 1447 An arbitrary name may be chosen if the router instance is 1448 created in the configuration. 1449 "; 1450 } 1451 leaf type { 1452 type identityref { 1453 base router-type; 1454 } 1455 default "rt:standard-router"; 1456 description 1457 "The router type."; 1458 } 1459 leaf enabled { 1460 type boolean; 1461 default "true"; 1462 description 1463 "Enable/disable the router instance. 1465 If this parameter is false, the parent router instance is 1466 disabled and does not appear in operational state data, 1467 despite any other configuration that might be present. 1468 "; 1469 } 1470 uses router-id { 1471 description 1472 "Configuration of the global router ID."; 1473 } 1474 leaf description { 1475 type string; 1476 description 1477 "Textual description of the router instance."; 1478 } 1479 container default-routing-tables { 1480 if-feature user-defined-routing-tables; 1481 description 1482 "Configuration of the default routing tables used by the 1483 router instance. 1485 The default routing table for an addressed family if by 1486 default connected to all routing protocol instances 1487 supporting that address family, and always receives direct 1488 routes. 1489 "; 1490 list default-routing-table { 1491 must "address-family=/routing/routing-tables/" 1492 + "routing-table[name=current()/name]/" 1493 + "address-family and safi=/routing/routing-tables/" 1494 + "routing-table[name=current()/name]/safi" { 1495 error-message "Address family mismatch."; 1496 description 1497 "The entry's address family MUST match that of the 1498 referenced routing table."; 1499 } 1500 key "address-family safi"; 1501 description 1502 "Each list entry configures the default routing table for 1503 one address family."; 1504 uses afn-safi; 1505 leaf name { 1506 type string; 1507 mandatory "true"; 1508 description 1509 "Name of an existing routing table to be used as the 1510 default routing table for the given router instance 1511 and address family."; 1512 } 1514 } 1515 } 1516 container interfaces { 1517 description 1518 "Configuration of router interface parameters."; 1519 list interface { 1520 key "name"; 1521 description 1522 "List of network layer interfaces assigned to the router 1523 instance."; 1524 leaf name { 1525 type if:interface-ref; 1526 description 1527 "A reference to the name of a configured network layer 1528 interface."; 1529 } 1530 } 1531 } 1532 container routing-protocols { 1533 description 1534 "Configuration of routing protocol instances."; 1535 list routing-protocol { 1536 key "name"; 1537 description 1538 "Each entry contains configuration of a routing protocol 1539 instance."; 1540 leaf name { 1541 type string; 1542 description 1543 "An arbitrary name of the routing protocol instance."; 1544 } 1545 leaf description { 1546 type string; 1547 description 1548 "Textual description of the routing protocol 1549 instance."; 1550 } 1551 leaf enabled { 1552 type boolean; 1553 default "true"; 1554 description 1555 "Enable/disable the routing protocol instance. 1557 If this parameter is false, the parent routing 1558 protocol instance is disabled and does not appear in 1559 operational state data, despite any other 1560 configuration that might be present. 1561 "; 1563 } 1564 leaf type { 1565 type identityref { 1566 base routing-protocol; 1567 } 1568 mandatory "true"; 1569 description 1570 "Type of the routing protocol - an identity derived 1571 from the 'routing-protocol' base identity."; 1572 } 1573 container connected-routing-tables { 1574 if-feature user-defined-routing-tables; 1575 description 1576 "Configuration of connected routing tables. 1577 "; 1578 list connected-routing-table { 1579 must "not(/routing/routing-tables/" 1580 + "routing-table[name=current()/" 1581 + "preceding-sibling::connected-routing-table/" 1582 + "name and address-family=/routing/routing-tables/" 1583 + "routing-table[name=current()/name]/" 1584 + "address-family and safi=/routing/routing-tables/" 1585 + "routing-table[name=current()/name]/safi])" { 1586 error-message "Duplicate address family for " 1587 + "connected routing tables."; 1588 description 1589 "For each AFN/SAFI pair there MUST NOT be more than 1590 one connected routing table."; 1591 } 1592 key "name"; 1593 description 1594 "List of routing tables to which the routing protocol 1595 instance is connected (at most one routing table per 1596 address family). 1598 If no connected routing table is configured for an 1599 address family, the routing protocol is connected to 1600 the default routing table for that address family. 1601 "; 1602 leaf name { 1603 type routing-table-ref; 1604 must "../../../type != 'rt:direct' or " 1605 + "../../../../../default-routing-tables/ " 1606 + "default-routing-table/name=." { 1607 error-message "The 'direct' protocol can be " 1608 + "connected only to a default " 1609 + "routing table."; 1610 description 1611 "For the 'direct' pseudo-protocol, the connected 1612 routing table must always be a default routing 1613 table."; 1614 } 1615 description 1616 "Name of an existing routing table."; 1617 } 1618 leaf import-filter { 1619 type route-filter-ref; 1620 description 1621 "Configuration of import filter."; 1622 } 1623 leaf export-filter { 1624 type route-filter-ref; 1625 description 1626 "Configuration of export filter."; 1627 } 1628 } 1629 } 1630 container static-routes { 1631 when "../type='rt:static'" { 1632 description 1633 "This container is only valid for the 'static' 1634 routing protocol."; 1635 } 1636 description 1637 "Configuration of the 'static' pseudo-protocol. 1639 Address family specific modules augment this node with 1640 their lists of routes. 1641 "; 1642 } 1643 } 1644 } 1645 } 1646 container routing-tables { 1647 description 1648 "Configured routing tables."; 1649 list routing-table { 1650 key "name"; 1651 description 1652 "Each entry represents a configured routing table 1653 identified by the 'name' key. 1655 Entries having the same key as a system-provided entry of 1656 the list /routing-state/routing-tables/routing-tables are 1657 used for configuring parameters of that entry. Other 1658 entries define additional user-provided routing tables. 1660 "; 1661 leaf name { 1662 type string; 1663 description 1664 "The name of the routing table."; 1665 } 1666 uses afn-safi; 1667 leaf description { 1668 type string; 1669 description 1670 "Textual description of the routing table."; 1671 } 1672 container recipient-routing-tables { 1673 if-feature user-defined-routing-tables; 1674 description 1675 "Configuration of recipient routing tables."; 1676 list recipient-routing-table { 1677 must "name != ../../name" { 1678 error-message "Source and recipient routing tables " 1679 + "are identical."; 1680 description 1681 "A routing table MUST NOT appear among its recipient 1682 routing tables."; 1683 } 1684 must "/routing/routing-tables/" 1685 + "routing-table[name=current()/name]/" 1686 + "address-family=../../address-family and /routing/" 1687 + "routing-tables/routing-table[name=current()/name]/" 1688 + "safi=../../safi" { 1689 error-message "Address family mismatch."; 1690 description 1691 "Address family of the recipient routing table MUST 1692 match the source table."; 1693 } 1694 key "name"; 1695 description 1696 "Each entry configures a recipient routing table."; 1697 leaf name { 1698 type routing-table-ref; 1699 description 1700 "The name of the recipient routing table."; 1701 } 1702 leaf filter { 1703 type route-filter-ref; 1704 description 1705 "A route filter which is applied to the routes passed 1706 to the recipient routing table."; 1707 } 1709 } 1710 } 1711 } 1712 } 1713 container route-filters { 1714 description 1715 "Configuration of route filters."; 1716 list route-filter { 1717 key "name"; 1718 description 1719 "Each entry configures a named route filter."; 1720 leaf name { 1721 type string; 1722 description 1723 "The name of the route filter."; 1724 } 1725 leaf description { 1726 type string; 1727 description 1728 "Textual description of the route filter."; 1729 } 1730 leaf type { 1731 type identityref { 1732 base route-filter; 1733 } 1734 mandatory "true"; 1735 description 1736 "Type of the route filter.."; 1737 } 1738 } 1739 } 1740 } 1741 } 1743 1745 7. IPv4 Unicast Routing YANG Module 1747 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1748 actual RFC number and all occurrences of the revision date below with 1749 the date of RFC publication (and remove this note). 1751 file "ietf-ipv4-unicast-routing@2013-07-13.yang" 1753 module ietf-ipv4-unicast-routing { 1755 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1757 prefix "v4ur"; 1759 import ietf-routing { 1760 prefix "rt"; 1761 } 1763 import ietf-inet-types { 1764 prefix "inet"; 1765 } 1767 organization 1768 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1770 contact 1771 "WG Web: 1772 WG List: 1774 WG Chair: David Kessens 1775 1777 WG Chair: Juergen Schoenwaelder 1778 1780 Editor: Ladislav Lhotka 1781 1782 "; 1784 description 1785 "This YANG module augments the 'ietf-routing' module with basic 1786 configuration and operational state data for IPv4 unicast 1787 routing. 1789 Copyright (c) 2013 IETF Trust and the persons identified as 1790 authors of the code. All rights reserved. 1792 Redistribution and use in source and binary forms, with or 1793 without modification, is permitted pursuant to, and subject to 1794 the license terms contained in, the Simplified BSD License set 1795 forth in Section 4.c of the IETF Trust's Legal Provisions 1796 Relating to IETF Documents 1797 (http://trustee.ietf.org/license-info). 1799 This version of this YANG module is part of RFC XXXX; see the 1800 RFC itself for full legal notices. 1801 "; 1803 revision 2013-07-13 { 1804 description 1805 "Initial revision."; 1806 reference 1807 "RFC XXXX: A YANG Data Model for Routing Management"; 1808 } 1810 /* Groupings */ 1812 grouping route-content { 1813 description 1814 "Parameters of IPv4 unicast routes."; 1815 leaf dest-prefix { 1816 type inet:ipv4-prefix; 1817 description 1818 "IPv4 destination prefix."; 1819 } 1820 leaf next-hop { 1821 type inet:ipv4-address; 1822 description 1823 "IPv4 address of the next hop."; 1824 } 1825 } 1827 /* RPC Methods */ 1829 augment "/rt:active-route/rt:input/rt:destination-address" { 1830 when "rt:address-family='ipv4' and rt:safi='nlri-unicast'" { 1831 description 1832 "This augment is valid only for IPv4 unicast."; 1833 } 1834 description 1835 "The 'address' leaf augments the 'rt:destination-address' 1836 parameter of the 'rt:active-route' operation."; 1837 leaf address { 1838 type inet:ipv4-address; 1839 description 1840 "IPv4 destination address."; 1842 } 1843 } 1845 augment "/rt:active-route/rt:output/rt:route" { 1846 when "rt:address-family='ipv4' and rt:safi='nlri-unicast'" { 1847 description 1848 "This augment is valid only for IPv4 unicast."; 1849 } 1850 description 1851 "Contents of the reply to 'rt:active-route' operation."; 1852 uses route-content; 1853 } 1855 /* Operational state */ 1857 augment "/rt:routing-state/rt:routing-tables/rt:routing-table/" 1858 + "rt:routes/rt:route" { 1859 when "../../rt:address-family = 'ipv4' and ../../rt:safi = " 1860 + "'nlri-unicast'" { 1861 description 1862 "This augment is valid only for IPv4 unicast."; 1863 } 1864 description 1865 "This augment defines the content of IPv4 unicast routes."; 1866 uses route-content; 1867 } 1869 /* Configuration */ 1871 augment "/rt:routing/rt:router/rt:routing-protocols/" 1872 + "rt:routing-protocol/rt:static-routes" { 1873 description 1874 "This augment defines the configuration of the 'static' 1875 pseudo-protocol with data specific for IPv4 unicast."; 1876 container ipv4 { 1877 description 1878 "Configuration of a 'static' pseudo-protocol instance 1879 consists of a list of routes."; 1880 list route { 1881 key "id"; 1882 ordered-by "user"; 1883 description 1884 "A user-ordered list of static routes."; 1885 leaf id { 1886 type uint32 { 1887 range "1..max"; 1888 } 1889 description 1890 "Numeric identifier of the route. 1892 It is not required that the routes be sorted by their 1893 'id'. 1894 "; 1895 } 1896 leaf description { 1897 type string; 1898 description 1899 "Textual description of the route."; 1900 } 1901 uses rt:route-content; 1902 uses route-content { 1903 refine "dest-prefix" { 1904 mandatory "true"; 1905 } 1906 } 1907 } 1908 } 1909 } 1910 } 1912 1914 8. IPv6 Unicast Routing YANG Module 1916 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1917 actual RFC number and all occurrences of the revision date below with 1918 the date of RFC publication (and remove this note). 1920 file "ietf-ipv6-unicast-routing@2013-07-13.yang" 1922 module ietf-ipv6-unicast-routing { 1924 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1926 prefix "v6ur"; 1928 import ietf-routing { 1929 prefix "rt"; 1930 } 1932 import ietf-inet-types { 1933 prefix "inet"; 1934 } 1936 import ietf-interfaces { 1937 prefix "if"; 1938 } 1940 import ietf-ip { 1941 prefix "ip"; 1942 } 1944 organization 1945 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1947 contact 1948 "WG Web: 1949 WG List: 1951 WG Chair: David Kessens 1952 1954 WG Chair: Juergen Schoenwaelder 1955 1957 Editor: Ladislav Lhotka 1958 1959 "; 1961 description 1962 "This YANG module augments the 'ietf-routing' module with basic 1963 configuration and operational state data for IPv6 unicast 1964 routing. 1966 Copyright (c) 2013 IETF Trust and the persons identified as 1967 authors of the code. All rights reserved. 1969 Redistribution and use in source and binary forms, with or 1970 without modification, is permitted pursuant to, and subject to 1971 the license terms contained in, the Simplified BSD License set 1972 forth in Section 4.c of the IETF Trust's Legal Provisions 1973 Relating to IETF Documents 1974 (http://trustee.ietf.org/license-info). 1976 This version of this YANG module is part of RFC XXXX; see the 1977 RFC itself for full legal notices. 1978 "; 1980 revision 2013-07-13 { 1981 description 1982 "Initial revision."; 1983 reference 1984 "RFC XXXX: A YANG Data Model for Routing Management"; 1985 } 1987 /* Groupings */ 1989 grouping route-content { 1990 description 1991 "Specific parameters of IPv6 unicast routes."; 1992 leaf dest-prefix { 1993 type inet:ipv6-prefix; 1994 description 1995 "IPv6 destination prefix."; 1996 } 1997 leaf next-hop { 1998 type inet:ipv6-address; 1999 description 2000 "IPv6 address of the next hop."; 2001 } 2002 } 2004 /* RPC Methods */ 2006 augment "/rt:active-route/rt:input/rt:destination-address" { 2007 when "rt:address-family='ipv6' and rt:safi='nlri-unicast'" { 2008 description 2009 "This augment is valid only for IPv6 unicast."; 2011 } 2012 description 2013 "The 'address' leaf augments the 'rt:destination-address' 2014 parameter of the 'rt:active-route' operation."; 2015 leaf address { 2016 type inet:ipv6-address; 2017 description 2018 "IPv6 destination address."; 2019 } 2020 } 2022 augment "/rt:active-route/rt:output/rt:route" { 2023 when "rt:address-family='ipv6' and rt:safi='nlri-unicast'" { 2024 description 2025 "This augment is valid only for IPv6 unicast."; 2026 } 2027 description 2028 "Contents of the reply to 'rt:active-route' operation."; 2029 uses route-content; 2030 } 2032 /* Operational state data */ 2034 augment "/rt:routing-state/rt:router/rt:interfaces/rt:interface" { 2035 when "/if:interfaces/if:interface[if:name=current()/rt:name]/" 2036 + "ip:ipv6/ip:enabled='true'" { 2037 description 2038 "This augment is only valid for router interfaces with 2039 enabled IPv6."; 2040 } 2041 description 2042 "IPv6-specific parameters of router interfaces."; 2043 container ipv6-router-advertisements { 2044 description 2045 "Parameters of IPv6 Router Advertisements."; 2046 leaf send-advertisements { 2047 type boolean; 2048 default "false"; 2049 description 2050 "A flag indicating whether or not the router sends periodic 2051 Router Advertisements and responds to Router 2052 Solicitations."; 2053 reference 2054 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2055 AdvSendAdvertisements."; 2056 } 2057 leaf max-rtr-adv-interval { 2058 type uint16 { 2059 range "4..1800"; 2060 } 2061 units "seconds"; 2062 default "600"; 2063 description 2064 "The maximum time allowed between sending unsolicited 2065 multicast Router Advertisements from the interface."; 2066 reference 2067 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2068 MaxRtrAdvInterval."; 2069 } 2070 leaf min-rtr-adv-interval { 2071 type uint16 { 2072 range "3..1350"; 2073 } 2074 units "seconds"; 2075 description 2076 "The minimum time allowed between sending unsolicited 2077 multicast Router Advertisements from the interface. 2079 The default value to be used operationally if this leaf is 2080 not configured is determined as follows: 2082 - if max-rtr-adv-interval >= 9 seconds, the default value 2083 is 0.33 * max-rtr-adv-interval; 2085 - otherwise it is 0.75 * max-rtr-adv-interval. 2086 "; 2087 reference 2088 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2089 MinRtrAdvInterval."; 2090 } 2091 leaf managed-flag { 2092 type boolean; 2093 default "false"; 2094 description 2095 "The boolean value to be placed in the 'Managed address 2096 configuration' flag field in the Router Advertisement."; 2097 reference 2098 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2099 AdvManagedFlag."; 2100 } 2101 leaf other-config-flag { 2102 type boolean; 2103 default "false"; 2104 description 2105 "The boolean value to be placed in the 'Other 2106 configuration' flag field in the Router Advertisement."; 2108 reference 2109 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2110 AdvOtherConfigFlag."; 2111 } 2112 leaf link-mtu { 2113 type uint32; 2114 default "0"; 2115 description 2116 "The value to be placed in MTU options sent by the router. 2117 A value of zero indicates that no MTU options are sent."; 2118 reference 2119 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2120 AdvLinkMTU."; 2121 } 2122 leaf reachable-time { 2123 type uint32 { 2124 range "0..3600000"; 2125 } 2126 units "milliseconds"; 2127 default "0"; 2128 description 2129 "The value to be placed in the Reachable Time field in the 2130 Router Advertisement messages sent by the router. The 2131 value zero means unspecified (by this router)."; 2132 reference 2133 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2134 AdvReachableTime."; 2135 } 2136 leaf retrans-timer { 2137 type uint32; 2138 units "milliseconds"; 2139 default "0"; 2140 description 2141 "The value to be placed in the Retrans Timer field in the 2142 Router Advertisement messages sent by the router. The 2143 value zero means unspecified (by this router)."; 2144 reference 2145 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2146 AdvRetransTimer."; 2147 } 2148 leaf cur-hop-limit { 2149 type uint8; 2150 default "64"; 2151 description 2152 "The default value to be placed in the Cur Hop Limit field 2153 in the Router Advertisement messages sent by the router. 2154 The value should be set to the current diameter of the 2155 Internet. The value zero means unspecified (by this 2156 router). 2158 The default SHOULD be set to the value specified in IANA 2159 Assigned Numbers that was in effect at the time of 2160 implementation. 2161 "; 2162 reference 2163 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2164 AdvCurHopLimit. 2166 IANA: IP Parameters, 2167 http://www.iana.org/assignments/ip-parameters 2168 "; 2169 } 2170 leaf default-lifetime { 2171 type uint16 { 2172 range "0..9000"; 2173 } 2174 units "seconds"; 2175 description 2176 "The value to be placed in the Router Lifetime field of 2177 Router Advertisements sent from the interface, in seconds. 2178 MUST be either zero or between max-rtr-adv-interval and 2179 9000 seconds. A value of zero indicates that the router is 2180 not to be used as a default router. These limits may be 2181 overridden by specific documents that describe how IPv6 2182 operates over different link layers. 2184 If this parameter is not configured, a value of 3 * 2185 max-rtr-adv-interval SHOULD be used. 2186 "; 2187 reference 2188 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2189 AdvDefaultLifeTime."; 2190 } 2191 container prefix-list { 2192 description 2193 "A list of prefixes that are placed in Prefix Information 2194 options in Router Advertisement messages sent from the 2195 interface. 2197 By default, these are all prefixes that the router 2198 advertises via routing protocols as being on-link for the 2199 interface from which the advertisement is sent. 2201 The link-local prefix SHOULD NOT be included in the list 2202 of advertised prefixes. 2203 "; 2205 reference 2206 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2207 AdvPrefixList."; 2208 list prefix { 2209 key "prefix-spec"; 2210 description 2211 "Advertised prefix entry with parameters."; 2212 leaf prefix-spec { 2213 type inet:ipv6-prefix; 2214 description 2215 "IPv6 address prefix."; 2216 } 2217 leaf valid-lifetime { 2218 type uint32; 2219 units "seconds"; 2220 default "2592000"; 2221 description 2222 "The value to be placed in the Valid Lifetime in the 2223 Prefix Information option. The designated value of all 2224 1's (0xffffffff) represents infinity. 2225 "; 2226 reference 2227 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2228 AdvValidLifetime."; 2229 } 2230 leaf on-link-flag { 2231 type boolean; 2232 default "true"; 2233 description 2234 "The value to be placed in the on-link flag ('L-bit') 2235 field in the Prefix Information option."; 2236 reference 2237 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2238 AdvOnLinkFlag."; 2239 } 2240 leaf preferred-lifetime { 2241 type uint32; 2242 units "seconds"; 2243 default "604800"; 2244 description 2245 "The value to be placed in the Preferred Lifetime in 2246 the Prefix Information option, in seconds. The 2247 designated value of all 1's (0xffffffff) represents 2248 infinity."; 2249 reference 2250 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2251 AdvPreferredLifetime."; 2252 } 2253 leaf autonomous-flag { 2254 type boolean; 2255 default "true"; 2256 description 2257 "The value to be placed in the Autonomous Flag field in 2258 the Prefix Information option."; 2259 reference 2260 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2261 AdvAutonomousFlag."; 2262 } 2263 } 2264 } 2265 } 2266 } 2268 augment "/rt:routing-state/rt:routing-tables/rt:routing-table/" 2269 + "rt:routes/rt:route" { 2270 when "../../rt:address-family = 'ipv6' and ../../rt:safi = " 2271 + "'nlri-unicast'" { 2272 description 2273 "This augment is valid only for IPv6 unicast."; 2274 } 2275 description 2276 "This augment defines the content of IPv6 unicast routes."; 2277 uses route-content; 2278 } 2280 /* Configuration */ 2282 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 2283 when "/if:interfaces/if:interface[if:name=current()/rt:name]/" 2284 + "ip:ipv6/ip:enabled='true'" { 2285 description 2286 "This augment is only valid for router interfaces with 2287 enabled IPv6."; 2288 } 2289 description 2290 "Configuration of IPv6-specific parameters of router 2291 interfaces."; 2292 container ipv6-router-advertisements { 2293 description 2294 "Configuration of IPv6 Router Advertisements. 2296 See the corresponding parameters under /rt:routing-state for 2297 detailed descriptions and references. 2298 "; 2299 leaf send-advertisements { 2300 type boolean; 2301 default "false"; 2302 description 2303 "A flag indicating whether or not the router sends periodic 2304 Router Advertisements and responds to Router 2305 Solicitations."; 2306 } 2307 leaf max-rtr-adv-interval { 2308 type uint16 { 2309 range "4..1800"; 2310 } 2311 units "seconds"; 2312 default "600"; 2313 description 2314 "The maximum time allowed between sending unsolicited 2315 multicast Router Advertisements from the interface."; 2316 } 2317 leaf min-rtr-adv-interval { 2318 type uint16 { 2319 range "3..1350"; 2320 } 2321 units "seconds"; 2322 must ". <= 0.75 * ../max-rtr-adv-interval" { 2323 description 2324 "The value MUST NOT be greater than 75 % of 2325 'max-rtr-adv-interval'."; 2326 } 2327 description 2328 "The minimum time allowed between sending unsolicited 2329 multicast Router Advertisements from the interface. 2330 "; 2331 } 2332 leaf managed-flag { 2333 type boolean; 2334 default "false"; 2335 description 2336 "The boolean value to be placed in the 'Managed address 2337 configuration' flag field in the Router Advertisement."; 2338 } 2339 leaf other-config-flag { 2340 type boolean; 2341 default "false"; 2342 description 2343 "The boolean value to be placed in the 'Other 2344 configuration' flag field in the Router Advertisement."; 2345 } 2346 leaf link-mtu { 2347 type uint32; 2348 default "0"; 2349 description 2350 "The value to be placed in MTU options sent by the router. 2351 A value of zero indicates that no MTU options are sent."; 2352 } 2353 leaf reachable-time { 2354 type uint32 { 2355 range "0..3600000"; 2356 } 2357 units "milliseconds"; 2358 default "0"; 2359 description 2360 "The value to be placed in the Reachable Time field in the 2361 Router Advertisement messages sent by the router. The 2362 value zero means unspecified (by this router)."; 2363 } 2364 leaf retrans-timer { 2365 type uint32; 2366 units "milliseconds"; 2367 default "0"; 2368 description 2369 "The value to be placed in the Retrans Timer field in the 2370 Router Advertisement messages sent by the router. The 2371 value zero means unspecified (by this router)."; 2372 } 2373 leaf cur-hop-limit { 2374 type uint8; 2375 default "64"; 2376 description 2377 "The default value to be placed in the Cur Hop Limit field 2378 in the Router Advertisement messages sent by the router. 2379 "; 2380 } 2381 leaf default-lifetime { 2382 type uint16 { 2383 range "0..9000"; 2384 } 2385 units "seconds"; 2386 description 2387 "The value to be placed in the Router Lifetime field of 2388 Router Advertisements sent from the interface, in seconds. 2389 "; 2390 } 2391 container prefix-list { 2392 description 2393 "Configuration of prefixes to be placed in Prefix 2394 Information options in Router Advertisement messages sent 2395 from the interface. 2397 Prefixes that are advertised by default but do not have 2398 their entries in the child 'prefix' list are advertised 2399 with the default values of all parameters. 2400 "; 2401 list prefix { 2402 key "prefix-spec"; 2403 description 2404 "Advertised prefix entry."; 2405 leaf prefix-spec { 2406 type inet:ipv6-prefix; 2407 description 2408 "IPv6 address prefix."; 2409 } 2410 choice control-adv-prefixes { 2411 default "advertise"; 2412 description 2413 "The prefix either may be explicitly removed from the 2414 set of advertised prefixes, or parameters with which 2415 it is advertised may be specified (default case)."; 2416 leaf no-advertise { 2417 type empty; 2418 description 2419 "The prefix will not be advertised. 2421 This can be used for removing the prefix from the 2422 default set of advertised prefixes. 2423 "; 2424 } 2425 case advertise { 2426 leaf valid-lifetime { 2427 type uint32; 2428 units "seconds"; 2429 default "2592000"; 2430 description 2431 "The value to be placed in the Valid Lifetime in 2432 the Prefix Information option."; 2433 } 2434 leaf on-link-flag { 2435 type boolean; 2436 default "true"; 2437 description 2438 "The value to be placed in the on-link flag 2439 ('L-bit') field in the Prefix Information 2440 option."; 2441 } 2442 leaf preferred-lifetime { 2443 type uint32; 2444 units "seconds"; 2445 must ". <= ../valid-lifetime" { 2446 description 2447 "This value MUST NOT be greater than 2448 valid-lifetime."; 2449 } 2450 default "604800"; 2451 description 2452 "The value to be placed in the Preferred Lifetime 2453 in the Prefix Information option."; 2454 } 2455 leaf autonomous-flag { 2456 type boolean; 2457 default "true"; 2458 description 2459 "The value to be placed in the Autonomous Flag 2460 field in the Prefix Information option."; 2461 } 2462 } 2463 } 2464 } 2465 } 2466 } 2467 } 2469 augment "/rt:routing/rt:router/rt:routing-protocols/" 2470 + "rt:routing-protocol/rt:static-routes" { 2471 description 2472 "This augment defines the configuration of the 'static' 2473 pseudo-protocol with data specific for IPv6 unicast."; 2474 container ipv6 { 2475 description 2476 "Configuration of a 'static' pseudo-protocol instance 2477 consists of a list of routes."; 2478 list route { 2479 key "id"; 2480 ordered-by "user"; 2481 description 2482 "A user-ordered list of static routes."; 2483 leaf id { 2484 type uint32 { 2485 range "1..max"; 2486 } 2487 description 2488 "Numeric identifier of the route. 2490 It is not required that the routes be sorted by their 2491 'id'. 2492 "; 2494 } 2495 leaf description { 2496 type string; 2497 description 2498 "Textual description of the route."; 2499 } 2500 uses rt:route-content; 2501 uses route-content { 2502 refine "dest-prefix" { 2503 mandatory "true"; 2504 } 2505 } 2506 } 2507 } 2508 } 2509 } 2511 2513 9. IANA Considerations 2515 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2516 actual RFC number (and remove this note). 2518 This document registers the following namespace URIs in the IETF XML 2519 registry [RFC3688]: 2521 ---------------------------------------------------------- 2522 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2524 Registrant Contact: The IESG. 2526 XML: N/A, the requested URI is an XML namespace. 2527 ---------------------------------------------------------- 2529 ---------------------------------------------------------- 2530 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2532 Registrant Contact: The IESG. 2534 XML: N/A, the requested URI is an XML namespace. 2535 ---------------------------------------------------------- 2537 ---------------------------------------------------------- 2538 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2540 Registrant Contact: The IESG. 2542 XML: N/A, the requested URI is an XML namespace. 2543 ---------------------------------------------------------- 2545 This document registers the following YANG modules in the YANG Module 2546 Names registry [RFC6020]: 2548 ------------------------------------------------------------------- 2549 name: ietf-routing 2550 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2551 prefix: rt 2552 reference: RFC XXXX 2553 ------------------------------------------------------------------- 2555 ------------------------------------------------------------------- 2556 name: ietf-ipv4-unicast-routing 2557 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2558 prefix: v4ur 2559 reference: RFC XXXX 2560 ------------------------------------------------------------------- 2562 ------------------------------------------------------------------- 2563 name: ietf-ipv6-unicast-routing 2564 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2565 prefix: v6ur 2566 reference: RFC XXXX 2567 ------------------------------------------------------------------- 2569 10. Security Considerations 2571 Configuration and state data conforming to the core routing data 2572 model (defined in this document) are designed to be accessed via the 2573 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2574 transport layer and the mandatory-to-implement secure transport is 2575 SSH [RFC6242]. 2577 A number of data nodes defined in the YANG modules belonging to the 2578 configuration part of the core routing data model are writable/ 2579 creatable/deletable (i.e., "config true" in YANG terms, which is the 2580 default). These data nodes may be considered sensitive or vulnerable 2581 in some network environments. Write operations to these data nodes, 2582 such as "edit-config", can have negative effects on the network if 2583 the protocol operations are not properly protected. 2585 The vulnerable "config true" subtrees and data nodes are the 2586 following: 2588 /routing/router/interfaces/interface This list assigns a network 2589 layer interface to a router instance and may also specify 2590 interface parameters related to routing. 2592 /routing/router/routing-protocols/routing-protocol This list 2593 specifies the routing protocols configured on a device. 2595 /routing/route-filters/route-filter This list specifies the 2596 configured route filters which represent administrative policies 2597 for redistributing and modifying routing information. 2599 /routing/routing-tables/routing-table This list specifies the 2600 configured routing tables used by the device. 2602 Unauthorized access to any of these lists can adversely affect the 2603 routing subsystem of both the local device and the network. This may 2604 lead to network malfunctions, delivery of packets to inappropriate 2605 destinations and other problems. 2607 11. Acknowledgments 2609 The author wishes to thank Martin Bjorklund, Joel Halpern, 2610 Wes Hardaker, Andrew McGregor, Xiang Li, Thomas Morin, Tom Petch, 2611 Bruno Rijsman, Juergen Schoenwaelder, Phil Shafer, Dave Thaler and 2612 Yi Yang for their helpful comments and suggestions. 2614 12. References 2616 12.1. Normative References 2618 [IANA-AF] Bjorklund, M., "IANA Address Family Numbers and Subsequent 2619 Address Family Identifiers YANG Module", 2620 draft-ietf-netmod-iana-afn-safi-00 (work in progress), 2621 July 2013. 2623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2624 Requirement Levels", BCP 14, RFC 2119, March 1997. 2626 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2627 January 2004. 2629 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2630 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2631 September 2007. 2633 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2634 Network Configuration Protocol (NETCONF)", RFC 6020, 2635 September 2010. 2637 [RFC6021bis] 2638 Schoenwaelder, J., Ed., "Common YANG Data Types", 2639 draft-ietf-netmod-rfc6021-bis-03 (work in progress), 2640 May 2013. 2642 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2643 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2644 June 2011. 2646 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2647 Management", draft-ietf-netmod-interfaces-cfg-12 (work in 2648 progress), July 2013. 2650 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Management", 2651 draft-ietf-netmod-ip-cfg-09 (work in progress), 2652 February 2013. 2654 12.2. Informative References 2656 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2657 Data Model Documents", RFC 6087, January 2011. 2659 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2660 Shell (SSH)", RFC 6242, June 2011. 2662 Appendix A. The Complete Data Trees 2664 This appendix presents the complete configuration and operational 2665 state data trees of the core routing data model. 2667 See Section 2.2 for an explanation of the symbols used. Data type of 2668 every leaf node is shown near the right end of the corresponding 2669 line. 2671 A.1. Configuration Data 2673 +--rw routing 2674 +--rw router* [name] 2675 | +--rw name string 2676 | +--rw type? identityref 2677 | +--rw enabled? boolean 2678 | +--rw router-id? yang:dotted-quad 2679 | +--rw description? string 2680 | +--rw default-routing-tables 2681 | | +--rw default-routing-table* [address-family safi] 2682 | | +--rw address-family ianaaf:address-family 2683 | | +--rw safi ianaaf:subsequent-address-family 2684 | | +--rw name string 2685 | +--rw interfaces 2686 | | +--rw interface* [name] 2687 | | +--rw name if:interface-ref 2688 | | +--rw v6ur:ipv6-router-advertisements 2689 | | +--rw v6ur:send-advertisements? boolean 2690 | | +--rw v6ur:max-rtr-adv-interval? uint16 2691 | | +--rw v6ur:min-rtr-adv-interval? uint16 2692 | | +--rw v6ur:managed-flag? boolean 2693 | | +--rw v6ur:other-config-flag? boolean 2694 | | +--rw v6ur:link-mtu? uint32 2695 | | +--rw v6ur:reachable-time? uint32 2696 | | +--rw v6ur:retrans-timer? uint32 2697 | | +--rw v6ur:cur-hop-limit? uint8 2698 | | +--rw v6ur:default-lifetime? uint16 2699 | | +--rw v6ur:prefix-list 2700 | | +--rw v6ur:prefix* [prefix-spec] 2701 | | +--rw v6ur:prefix-spec inet:ipv6-prefix 2702 | | +--rw (control-adv-prefixes)? 2703 | | +--:(no-advertise) 2704 | | | +--rw v6ur:no-advertise? empty 2705 | | +--:(advertise) 2706 | | +--rw v6ur:valid-lifetime? uint32 2707 | | +--rw v6ur:on-link-flag? boolean 2708 | | +--rw v6ur:preferred-lifetime? uint32 2709 | | +--rw v6ur:autonomous-flag? boolean 2710 | +--rw routing-protocols 2711 | +--rw routing-protocol* [name] 2712 | +--rw name string 2713 | +--rw description? string 2714 | +--rw enabled? boolean 2715 | +--rw type identityref 2716 | +--rw connected-routing-tables 2717 | | +--rw connected-routing-table* [name] 2718 | | +--rw name routing-table-ref 2719 | | +--rw import-filter? route-filter-ref 2720 | | +--rw export-filter? route-filter-ref 2721 | +--rw static-routes 2722 | +--rw v4ur:ipv4 2723 | | +--rw v4ur:route* [id] 2724 | | +--rw v4ur:id uint32 2725 | | +--rw v4ur:description? string 2726 | | +--rw v4ur:outgoing-interface? if:interface-ref 2727 | | +--rw v4ur:dest-prefix inet:ipv4-prefix 2728 | | +--rw v4ur:next-hop? inet:ipv4-address 2729 | +--rw v6ur:ipv6 2730 | +--rw v6ur:route* [id] 2731 | +--rw v6ur:id uint32 2732 | +--rw v6ur:description? string 2733 | +--rw v6ur:outgoing-interface? if:interface-ref 2734 | +--rw v6ur:dest-prefix inet:ipv6-prefix 2735 | +--rw v6ur:next-hop? inet:ipv6-address 2736 +--rw routing-tables 2737 | +--rw routing-table* [name] 2738 | +--rw name string 2739 | +--rw address-family ianaaf:address-family 2740 | +--rw safi ianaaf:subsequent-address-family 2741 | +--rw description? string 2742 | +--rw recipient-routing-tables 2743 | +--rw recipient-routing-table* [name] 2744 | +--rw name routing-table-ref 2745 | +--rw filter? route-filter-ref 2746 +--rw route-filters 2747 +--rw route-filter* [name] 2748 +--rw name string 2749 +--rw description? string 2750 +--rw type identityref 2752 A.2. Operational State Data 2754 +--ro routing-state 2755 +--ro router* [name] 2756 | +--ro name string 2757 | +--ro type? identityref 2758 | +--ro router-id? yang:dotted-quad 2759 | +--ro default-routing-tables 2760 | | +--ro default-routing-table* [address-family safi] 2761 | | +--ro address-family ianaaf:address-family 2762 | | +--ro safi ianaaf:subsequent-address-family 2763 | | +--ro name routing-table-state-ref 2764 | +--ro interfaces 2765 | | +--ro interface* [name] 2766 | | +--ro name if:interface-state-ref 2767 | | +--ro v6ur:ipv6-router-advertisements 2768 | | +--ro v6ur:send-advertisements? boolean 2769 | | +--ro v6ur:max-rtr-adv-interval? uint16 2770 | | +--ro v6ur:min-rtr-adv-interval? uint16 2771 | | +--ro v6ur:managed-flag? boolean 2772 | | +--ro v6ur:other-config-flag? boolean 2773 | | +--ro v6ur:link-mtu? uint32 2774 | | +--ro v6ur:reachable-time? uint32 2775 | | +--ro v6ur:retrans-timer? uint32 2776 | | +--ro v6ur:cur-hop-limit? uint8 2777 | | +--ro v6ur:default-lifetime? uint16 2778 | | +--ro v6ur:prefix-list 2779 | | +--ro v6ur:prefix* [prefix-spec] 2780 | | +--ro v6ur:prefix-spec inet:ipv6-prefix 2781 | | +--ro v6ur:valid-lifetime? uint32 2782 | | +--ro v6ur:on-link-flag? boolean 2783 | | +--ro v6ur:preferred-lifetime? uint32 2784 | | +--ro v6ur:autonomous-flag? boolean 2785 | +--ro routing-protocols 2786 | +--ro routing-protocol* [name] 2787 | +--ro name string 2788 | +--ro type identityref 2789 | +--ro connected-routing-tables 2790 | +--ro connected-routing-table* [name] 2791 | +--ro name routing-table-state-ref 2792 | +--ro import-filter? route-filter-state-ref 2793 | +--ro export-filter? route-filter-state-ref 2794 +--ro routing-tables 2795 | +--ro routing-table* [name] 2796 | +--ro name string 2797 | +--ro address-family ianaaf:address-family 2798 | +--ro safi ianaaf:subsequent-address-family 2799 | +--ro routes 2800 | | +--ro route* 2801 | | +--ro outgoing-interface? if:interface-state-ref 2802 | | +--ro source-protocol identityref 2803 | | +--ro last-updated? yang:date-and-time 2804 | | +--ro v4ur:dest-prefix? inet:ipv4-prefix 2805 | | +--ro v4ur:next-hop? inet:ipv4-address 2806 | | +--ro v6ur:dest-prefix? inet:ipv6-prefix 2807 | | +--ro v6ur:next-hop? inet:ipv6-address 2808 | +--ro recipient-routing-tables 2809 | +--ro recipient-routing-table* [name] 2810 | +--ro name routing-table-state-ref 2811 | +--ro filter? route-filter-state-ref 2812 +--ro route-filters 2813 +--ro route-filter* [name] 2814 +--ro name string 2815 +--ro type identityref 2817 Appendix B. Example: Adding a New Routing Protocol 2819 This appendix demonstrates how the core routing data model can be 2820 extended to support a new routing protocol. The YANG module 2821 "example-rip" shown below is intended only as an illustration rather 2822 than a real definition of a data model for the RIP routing protocol. 2823 For the sake of brevity, we do not follow all the guidelines 2824 specified in [RFC6087]. See also Section 4.4.2. 2826 module example-rip { 2828 namespace "http://example.com/rip"; 2830 prefix "rip"; 2832 import ietf-routing { 2833 prefix "rt"; 2834 } 2836 identity rip { 2837 base rt:routing-protocol; 2838 description 2839 "Identity for the RIP routing protocol."; 2840 } 2842 typedef rip-metric { 2843 type uint8 { 2844 range "0..16"; 2845 } 2846 } 2848 grouping route-content { 2849 description 2850 "This grouping defines RIP-specific route attributes."; 2851 leaf metric { 2852 type rip-metric; 2853 } 2854 leaf tag { 2855 type uint16; 2856 default "0"; 2857 description 2858 "This leaf may be used to carry additional info, e.g. AS 2859 number."; 2860 } 2861 } 2863 augment "/rt:routing-state/rt:routing-tables/rt:routing-table/" 2864 + "rt:routes/rt:route" { 2866 when "rt:source-protocol = 'rip:rip'" { 2867 description 2868 "This augment is only valid for a routes whose source 2869 protocol is RIP."; 2870 } 2871 description 2872 "RIP-specific route attributes."; 2873 uses route-content; 2874 } 2876 augment "/rt:active-route/rt:output/rt:route" { 2877 description 2878 "RIP-specific route attributes in the output of 'active-route' 2879 RPC."; 2880 uses route-content; 2881 } 2883 augment "/rt:routing/rt:router/rt:routing-protocols/" 2884 + "rt:routing-protocol" { 2885 when "rt:type = 'rip:rip'" { 2886 description 2887 "This augment is only valid for a routing protocol instance 2888 of type 'rip'."; 2889 } 2890 container rip { 2891 description 2892 "RIP instance configuration."; 2893 container interfaces { 2894 description 2895 "Per-interface RIP configuration."; 2896 list interface { 2897 key "name"; 2898 description 2899 "RIP is enabled on interfaces that have an entry in this 2900 list, unless 'enabled' is set to 'false' for that 2901 entry."; 2902 leaf name { 2903 type leafref { 2904 path "../../../../../../rt:interfaces/rt:interface/" 2905 + "rt:name"; 2906 } 2907 } 2908 leaf enabled { 2909 type boolean; 2910 default "true"; 2911 } 2912 leaf metric { 2913 type rip-metric; 2914 default "1"; 2915 } 2916 } 2917 } 2918 leaf update-interval { 2919 type uint8 { 2920 range "10..60"; 2921 } 2922 units "seconds"; 2923 default "30"; 2924 description 2925 "Time interval between periodic updates."; 2926 } 2927 } 2928 } 2929 } 2931 Appendix C. Example: NETCONF Reply 2933 This section contains a sample reply to the NETCONF message, 2934 which could be sent by a server supporting (i.e., advertising them in 2935 the NETCONF message) the following YANG modules: 2937 o ietf-interfaces [YANG-IF], 2939 o ietf-ip [YANG-IP], 2941 o ietf-routing (Section 6), 2943 o ietf-ipv4-unicast-routing (Section 7), 2945 o ietf-ipv6-unicast-routing (Section 8). 2947 We assume a simple network setup as shown in Figure 5: router "A" 2948 uses static default routes with the "ISP" router as the next hop. 2949 IPv6 router advertisements are configured only on the "eth1" 2950 interface and disabled on the upstream "eth0" interface. 2952 +-----------------+ 2953 | | 2954 | Router ISP | 2955 | | 2956 +--------+--------+ 2957 |2001:db8:0:1::2 2958 |192.0.2.2 2959 | 2960 | 2961 |2001:db8:0:1::1 2962 eth0|192.0.2.1 2963 +--------+--------+ 2964 | | 2965 | Router A | 2966 | | 2967 +--------+--------+ 2968 eth1|198.51.100.1 2969 |2001:db8:0:2::1 2970 | 2972 Figure 5: Example network configuration 2974 A reply to the NETCONF message sent by router "A" would then be 2975 as follows: 2977 2978 2986 2987 2988 2989 eth0 2990 ethernetCsmacd 2991 2992 Uplink to ISP. 2993 2994 2995 2996 192.0.2.1 2997 24 2998 2999 true 3000 3001 3002 3003 2001:0db8:0:1::1 3004 64 3005 3006 true 3007 3008 false 3009 3010 3011 3012 3013 eth1 3014 ethernetCsmacd 3015 3016 Interface to the internal network. 3017 3018 3019 3020 198.51.100.1 3021 24 3022 3023 true 3024 3025 3026 3027 2001:0db8:0:2::1 3028 64 3029 3030 true 3031 3032 false 3033 3034 3035 3036 3037 3038 3039 eth0 3040 ethernetCsmacd 3041 00:0C:42:E5:B1:E9 3042 up 3043 3044 3045 2013-07-02T17:11:27+00:58 3046 3047 3048 3049 3050 eth1 3051 ethernetCsmacd 3052 up 3053 00:0C:42:E5:B1:EA 3054 3055 3056 2013-07-02T17:11:27+00:59 3057 3058 3059 3060 3061 3062 3063 rtr0 3064 Router A 3065 3066 3067 eth1 3068 3069 true 3070 3071 3072 2001:db8:0:2::/64 3073 3074 3076 3077 3078 3079 3080 3081 st0 3082 3083 Static routing is used for the internal network. 3084 3085 rt:static 3086 3087 3088 3089 1 3090 0.0.0.0/0 3091 192.0.2.2 3092 3093 3094 3095 3096 1 3097 ::/0 3098 2001:db8:0:1::2 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 rtr0 3109 192.0.2.1 3110 3111 3112 ipv4 3113 nlri-unicast 3114 ipv4-unicast 3115 3116 3117 ipv6 3118 nlri-unicast 3119 ipv6-unicast 3120 3121 3122 3123 3124 eth0 3125 3126 3127 eth1 3128 3129 true 3130 3131 3132 2001:db8:0:2::/64 3133 3134 3135 3136 3137 3138 3139 3140 st0 3141 rt:static 3142 3143 3144 3145 3146 3147 ipv4-unicast 3148 ipv4 3149 nlri-unicast 3150 3151 3152 192.0.2.1/24 3153 eth0 3154 rt:direct 3155 2013-07-02T17:11:27+01:00 3156 3157 3158 198.51.100.0/24 3159 eth1 3160 rt:direct 3161 2013-07-02T17:11:27+01:00 3162 3163 3164 0.0.0.0/0 3165 rt:static 3166 192.0.2.2 3167 2013-07-02T18:02:45+01:00 3168 3169 3170 3171 3172 ipv6-unicast 3173 ipv6 3174 nlri-unicast 3175 3176 3177 2001:db8:0:1::/64 3178 eth0 3179 rt:direct 3180 2013-07-02T17:11:27+01:00 3181 3182 3183 2001:db8:0:2::/64 3184 eth1 3185 rt:direct 3186 2013-07-02T17:11:27+01:00 3187 3188 3189 ::/0 3190 2001:db8:0:1::2 3191 rt:static 3192 2013-07-02T18:02:45+01:00 3193 3194 3195 3196 3197 3198 3199 3201 Appendix D. Change Log 3203 RFC Editor: remove this section upon publication as an RFC. 3205 D.1. Changes Between Versions -09 and -10 3207 o Added subtree for operational state data ("/routing-state"). 3209 o Terms "system-controlled entry" and "user-controlled entry" 3210 defined and used. 3212 o New feature "user-defined-routing-tables". Nodes that are useful 3213 only with user-defined routing tables are now conditional. 3215 o Added grouping "router-id". 3217 o In routing tables, "source-protocol" attribute of routes now 3218 reports only protocol type, and its datatype is "identityref". 3220 o Renamed "main-routing-table" to "default-routing-table". 3222 D.2. Changes Between Versions -08 and -09 3224 o Fixed "must" expresion for "connected-routing-table". 3226 o Simplified "must" expression for "main-routing-table". 3228 o Moved per-interface configuration of a new routing protocol under 3229 'routing-protocol'. This also affects the 'example-rip' module. 3231 D.3. Changes Between Versions -07 and -08 3233 o Changed reference from RFC6021 to RFC6021bis. 3235 D.4. Changes Between Versions -06 and -07 3237 o The contents of in Appendix C was updated: "eth[01]" 3238 is used as the value of "location", and "forwarding" is on for 3239 both interfaces and both IPv4 and IPv6. 3241 o The "must" expression for "main-routing-table" was modified to 3242 avoid redundant error messages reporting address family mismatch 3243 when "name" points to a non-existent routing table. 3245 o The default behavior for IPv6 RA prefix advertisements was 3246 clarified. 3248 o Changed type of "rt:router-id" to "ip:dotted-quad". 3250 o Type of "rt:router-id" changed to "yang:dotted-quad". 3252 o Fixed missing prefixes in XPath expressions. 3254 D.5. Changes Between Versions -05 and -06 3256 o Document title changed: "Configuration" was replaced by 3257 "Management". 3259 o New typedefs "routing-table-ref" and "route-filter-ref". 3261 o Double slashes "//" were removed from XPath expressions and 3262 replaced with the single "/". 3264 o Removed uniqueness requirement for "router-id". 3266 o Complete data tree is now in Appendix A. 3268 o Changed type of "source-protocol" from "leafref" to "string". 3270 o Clarified the relationship between routing protocol instances and 3271 connected routing tables. 3273 o Added a must constraint saying that a routing table connected to 3274 the direct pseudo-protocol must not be a main routing table. 3276 D.6. Changes Between Versions -04 and -05 3278 o Routing tables are now global, i.e., "routing-tables" is a child 3279 of "routing" rather than "router". 3281 o "must" statement for "static-routes" changed to "when". 3283 o Added "main-routing-tables" containing references to main routing 3284 tables for each address family. 3286 o Removed the defaults for "address-family" and "safi" and made them 3287 mandatory. 3289 o Removed the default for route-filter/type and made this leaf 3290 mandatory. 3292 o If there is no active route for a given destination, the "active- 3293 route" RPC returns no output. 3295 o Added "enabled" switch under "routing-protocol". 3297 o Added "router-type" identity and "type" leaf under "router". 3299 o Route attribute "age" changed to "last-updated", its type is 3300 "yang:date-and-time". 3302 o The "direct" pseudo-protocol is always connected to main routing 3303 tables. 3305 o Entries in the list of connected routing tables renamed from 3306 "routing-table" to "connected-routing-table". 3308 o Added "must" constraint saying that a routing table must not be 3309 its own recipient. 3311 D.7. Changes Between Versions -03 and -04 3313 o Changed "error-tag" for both RPC methods from "missing element" to 3314 "data-missing". 3316 o Removed the decrementing behavior for advertised IPv6 prefix 3317 parameters "valid-lifetime" and "preferred-lifetime". 3319 o Changed the key of the static route lists from "seqno" to "id" 3320 because the routes needn't be sorted. 3322 o Added 'must' constraint saying that "preferred-lifetime" must not 3323 be greater than "valid-lifetime". 3325 D.8. Changes Between Versions -02 and -03 3327 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3329 o Removed forwarding table. 3331 o RPC "get-route" changed to "active-route". Its output is a list 3332 of routes (for multi-path routing). 3334 o New RPC "route-count". 3336 o For both RPCs, specification of negative responses was added. 3338 o Relaxed separation of router instances. 3340 o Assignment of interfaces to router instances needn't be disjoint. 3342 o Route filters are now global. 3344 o Added "allow-all-route-filter" for symmetry. 3346 o Added Section 5 about interactions with "ietf-interfaces" and 3347 "ietf-ip". 3349 o Added "router-id" leaf. 3351 o Specified the names for IPv4/IPv6 unicast main routing tables. 3353 o Route parameter "last-modified" changed to "age". 3355 o Added container "recipient-routing-tables". 3357 D.9. Changes Between Versions -01 and -02 3359 o Added module "ietf-ipv6-unicast-routing". 3361 o The example in Appendix C now uses IP addresses from blocks 3362 reserved for documentation. 3364 o Direct routes appear by default in the forwarding table. 3366 o Network layer interfaces must be assigned to a router instance. 3367 Additional interface configuration may be present. 3369 o The "when" statement is only used with "augment", "must" is used 3370 elsewhere. 3372 o Additional "must" statements were added. 3374 o The "route-content" grouping for IPv4 and IPv6 unicast now 3375 includes the material from the "ietf-routing" version via "uses 3376 rt:route-content". 3378 o Explanation of symbols in the tree representation of data model 3379 hierarchy. 3381 D.10. Changes Between Versions -00 and -01 3383 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3385 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3386 safi" module. 3388 o Names of some data nodes were changed, in particular "routing- 3389 process" is now "router". 3391 o The restriction of a single AFN/SAFI per router was lifted. 3393 o RPC operation "delete-route" was removed. 3395 o Illegal XPath references from "get-route" to the datastore were 3396 fixed. 3398 o Section "Security Considerations" was written. 3400 Author's Address 3402 Ladislav Lhotka 3403 CZ.NIC 3405 Email: lhotka@nic.cz