idnits 2.17.1 draft-ietf-netmod-routing-cfg-04.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 -- The document date (July 9, 2012) is 4306 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 (-10) exists of draft-ietf-netmod-iana-if-type-02 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-04 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-ip-cfg-03 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 1 error (**), 0 flaws (~~), 4 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 9, 2012 5 Expires: January 10, 2013 7 A YANG Data Model for Routing Configuration 8 draft-ietf-netmod-routing-cfg-04 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 a routing subsystem. It is therefore 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 configurations - 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 10, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 57 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 58 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 59 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. The Design of the Core Routing Data Model . . . . . . . . . . 7 61 4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 10 63 4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 12 65 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 13 66 4.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 14 67 4.4.2. Defining New Routing Protocols . . . . . . . . . . . . 14 68 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 17 69 4.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 18 70 4.6.1. Operation "active-route" . . . . . . . . . . . . . . . 18 71 4.6.2. Operation "route-count" . . . . . . . . . . . . . . . 19 72 5. Interactions with Other YANG Modules . . . . . . . . . . . . . 20 73 5.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 20 74 5.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 20 75 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 22 76 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 34 77 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 38 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 84 Appendix A. Example: Adding a New Routing Protocol . . . . . . . 52 85 Appendix B. Example: Reply to the NETCONF Message . . . . . 55 86 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 60 87 C.1. Changes Between Versions -03 and -04 . . . . . . . . . . . 60 88 C.2. Changes Between Versions -02 and -03 . . . . . . . . . . . 60 89 C.3. Changes Between Versions -01 and -02 . . . . . . . . . . . 61 90 C.4. Changes Between Versions -00 and -01 . . . . . . . . . . . 61 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 93 1. Introduction 95 This document contains a specification of the following YANG modules: 97 o Module "ietf-routing" provides generic components of a routing 98 data model. 100 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 101 module with additional data specific to IPv4 unicast. 103 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 104 module with additional data specific to IPv6 unicast, including 105 the router configuration variables required by [RFC4861]. 107 These modules together define the so-called core routing data model, 108 which is proposed as a basis for the development of data models for 109 more sophisticated routing configurations. While these three modules 110 can be directly used for simple IP devices with static routing, their 111 main purpose is to provide essential building blocks for more 112 complicated setups involving multiple routing protocols, multicast 113 routing, additional address families, and advanced functions such as 114 route filtering or policy routing. To this end, it is expected that 115 the core routing data model will be augmented by numerous modules 116 developed by other IETF working groups. 118 2. Terminology and Notation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 The following terms are defined in [RFC6241]: 126 o client 128 o message 130 o protocol operation 132 o server 134 The following terms are defined in [RFC6020]: 136 o augment 138 o configuration data 140 o container 142 o data model 144 o data node 146 o data type 148 o identity 150 o mandatory node 152 o module 154 o operational state data 156 o prefix 158 o RPC operation 160 2.1. Glossary of New Terms 161 active route: a route which is actually used for sending packets. 162 If there are multiple candidate routes with a matching destination 163 prefix, then it is up to the routing algorithm to select the 164 active route (or several active routes in the case of multi-path 165 routing). 167 core routing data model: YANG data model resulting from the 168 combination of "ietf-routing", "ietf-ipv4-unicast-routing" and 169 "ietf-ipv6-unicast-routing" modules. 171 direct route: a route to a directly connected network. 173 2.2. Prefixes in Data Node Names 175 In this document, names of data nodes, RPC methods and other data 176 model objects are used mostly without a prefix, as long as it is 177 clear from the context in which YANG module each name is defined. 178 Otherwise, names are prefixed using the standard prefix associated 179 with the corresponding YANG module, as shown in Table 1. 181 +--------+---------------------------+--------------+ 182 | Prefix | YANG module | Reference | 183 +--------+---------------------------+--------------+ 184 | ianaaf | iana-afn-safi | [IANA-IF-AF] | 185 | | | | 186 | if | ietf-interfaces | [YANG-IF] | 187 | | | | 188 | ip | ietf-ip | [YANG-IP] | 189 | | | | 190 | rip | example-rip | Appendix A | 191 | | | | 192 | rt | ietf-routing | Section 6 | 193 | | | | 194 | v4ur | ietf-ipv4-unicast-routing | Section 7 | 195 | | | | 196 | v6ur | ietf-ipv6-unicast-routing | Section 8 | 197 | | | | 198 | yang | ietf-yang-types | [RFC6021] | 199 | | | | 200 | inet | ietf-inet-types | [RFC6021] | 201 +--------+---------------------------+--------------+ 203 Table 1: Prefixes and corresponding YANG modules 205 3. Objectives 207 The initial design of the core routing data model was driven by the 208 following objectives: 210 o The data model should be suitable for the common address families, 211 in particular IPv4 and IPv6, and for unicast and multicast 212 routing, as well as Multiprotocol Label Switching (MPLS). 214 o Simple routing setups, such as static routing, should be 215 configurable in a simple way, ideally without any need to develop 216 additional YANG modules. 218 o On the other hand, the core routing framework must allow for 219 complicated setups involving multiple routing tables and multiple 220 routing protocols, as well as controlled redistributions of 221 routing information. 223 o Device vendors will want to map the data models built on this 224 generic framework to their proprietary data models and 225 configuration interfaces. Therefore, the framework should be 226 flexible enough to facilitate such a mapping and accommodate data 227 models with different logic. 229 4. The Design of the Core Routing Data Model 231 The core routing data model consists of three YANG modules. The 232 first module, "ietf-routing", defines the generic components of a 233 routing system. The other two modules, "ietf-ipv4-unicast-routing" 234 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 235 with additional data nodes that are needed for IPv4 and IPv6 unicast 236 routing, respectively. The combined data hierarchy is shown in 237 Figure 1, where brackets enclose list keys, "rw" means configuration, 238 "ro" operational state data, and "?" means optional node. 239 Parentheses enclose choice and case nodes, and case nodes are also 240 marked with a colon (":"). 242 +--rw routing 243 +--rw router [name] 244 | +--rw name 245 | +--rw router-id? 246 | +--rw description? 247 | +--rw enabled? 248 | +--rw interfaces 249 | | +--rw interface [name] 250 | | +--rw name 251 | | +--rw v6ur:ipv6-router-advertisements 252 | | +--rw v6ur:send-advertisements? 253 | | +--rw v6ur:max-rtr-adv-interval? 254 | | +--rw v6ur:min-rtr-adv-interval? 255 | | +--rw v6ur:managed-flag? 256 | | +--rw v6ur:other-config-flag? 257 | | +--rw v6ur:link-mtu? 258 | | +--rw v6ur:reachable-time? 259 | | +--rw v6ur:retrans-timer? 260 | | +--rw v6ur:cur-hop-limit? 261 | | +--rw v6ur:default-lifetime? 262 | | +--rw v6ur:prefix-list 263 | | +--rw v6ur:prefix [prefix-spec] 264 | | +--rw v6ur:prefix-spec 265 | | +--rw (control-adv-prefixes)? 266 | | +--:(no-advertise) 267 | | | +--rw v6ur:no-advertise? 268 | | +--:(advertise) 269 | | +--rw v6ur:valid-lifetime? 270 | | +--rw v6ur:on-link-flag? 271 | | +--rw v6ur:preferred-lifetime? 272 | | +--rw v6ur:autonomous-flag? 273 | +--rw routing-protocols 274 | | +--rw routing-protocol [name] 275 | | +--rw name 276 | | +--rw description? 277 | | +--rw type 278 | | +--rw connected-routing-tables 279 | | | +--rw routing-table [name] 280 | | | +--rw name 281 | | | +--rw import-filter? 282 | | | +--rw export-filter? 283 | | +--rw static-routes 284 | | +--rw v4ur:ipv4 285 | | | +--rw v4ur:route [id] 286 | | | +--rw v4ur:id 287 | | | +--rw v4ur:description? 288 | | | +--rw v4ur:outgoing-interface? 289 | | | +--rw v4ur:dest-prefix 290 | | | +--rw v4ur:next-hop? 291 | | +--rw v6ur:ipv6 292 | | +--rw v6ur:route [id] 293 | | +--rw v6ur:id 294 | | +--rw v6ur:description? 295 | | +--rw v6ur:outgoing-interface? 296 | | +--rw v6ur:dest-prefix 297 | | +--rw v6ur:next-hop? 298 | +--rw routing-tables 299 | +--rw routing-table [name] 300 | +--rw name 301 | +--rw address-family? 302 | +--rw safi? 303 | +--rw description? 304 | +--ro routes 305 | | +--ro route 306 | | +--ro outgoing-interface? 307 | | +--ro source-protocol 308 | | +--ro age 309 | | +--ro v4ur:dest-prefix? 310 | | +--ro v4ur:next-hop? 311 | | +--ro v6ur:dest-prefix? 312 | | +--ro v6ur:next-hop? 313 | +--rw recipient-routing-tables 314 | +--rw recipient-routing-table [name] 315 | +--rw name 316 | +--rw filter? 317 +--rw route-filters 318 +--rw route-filter [name] 319 +--rw name 320 +--rw description? 321 +--rw type? 323 Figure 1: Data hierarchy of the core routing data model. 325 As can be seen from Figure 1, the core routing data model introduces 326 several generic components of a routing framework: routers, routing 327 tables containing routes, routing protocols and route filters. The 328 following subsections describe these components in more detail. 330 By combining the components in various ways, and possibly augmenting 331 them with appropriate contents defined in other modules, various 332 routing setups can be realized. 334 +--------+ 335 | direct | +---+ +--------------+ +---+ +--------------+ 336 | routes |--->| F |--->| |<---| F |<---| | 337 +--------+ +---+ | main | +---+ | additional | 338 | routing | | routing | 339 +--------+ +---+ | table | +---+ | table | 340 | static |--->| F |--->| |--->| F |--->| | 341 | routes | +---+ +--------------+ +---+ +--------------+ 342 +--------+ ^ | ^ | 343 | v | v 344 +---+ +---+ +---+ +---+ 345 | F | | F | | F | | F | 346 +---+ +---+ +---+ +---+ 347 ^ | ^ | 348 | v | v 349 +----------+ +----------+ 350 | routing | | routing | 351 | protocol | | protocol | 352 +----------+ +----------+ 354 Figure 2: Example setup of the routing subsystem 356 The example in Figure 2 shows a typical (though certainly not the 357 only possible) organization of a more complex routing subsystem for a 358 single address family. Several of its features are worth mentioning: 360 o Along with the main routing table, which must always be present, 361 an additional routing table is configured. 363 o Each routing protocol instance, including the "static" and 364 "direct" pseudo-protocols, is connected to one routing table with 365 which it can exchange routes (in both directions, except for the 366 "static" and "direct" pseudo-protocols). 368 o Routing tables may also be connected to each other and exchange 369 routes in either direction (or both). 371 o Route exchanges along all connections may be controlled by means 372 of route filters, denoted by "F" in Figure 2. 374 4.1. Router 376 Each router instance in the core routing data model represents a 377 logical router. The exact semantics of this term is left to 378 implementations. For example, router instances may be completely 379 isolated virtual routers or, alternatively, they may internally share 380 certain information. 382 Each network layer interface must be assigned to one or more router 383 instances in order to be able to participate in packet forwarding, 384 routing protocols and other operations of those router instances. 385 The assignment is accomplished by creating a corresponding entry in 386 the list of router interfaces ("rt:interface"). The key of the list 387 entry MUST be the name of a configured network layer interface, i.e., 388 the value of a node /if:interfaces/if:interface/if:name defined in 389 the "ietf-interfaces" module [YANG-IF]. 391 Implementations MAY specify additional rules for the assignment of 392 interfaces to logical routers. For example, it may be required that 393 the sets of interfaces assigned to different logical routers be 394 disjoint. 396 Apart from the key, each entry of the "rt:interface" list MAY contain 397 other configuration or operational state data related to the 398 corresponding router interface. 400 4.1.1. Configuration of IPv6 Router Interfaces 402 The module "ietf-ipv6-unicast-routing" augments the definition of the 403 data node "rt:interface" with definitions of the following 404 configuration variables as required by [RFC4861], sec. 6.2.1: 406 o send-advertisements, 408 o max-rtr-adv-interval, 410 o min-rtr-adv-interval, 412 o managed-flag, 414 o other-config-flag, 416 o link-mtu, 418 o reachable-time, 420 o retrans-timer, 421 o cur-hop-limit, 423 o default-lifetime, 425 o prefix-list: a list of prefixes to be advertised. The following 426 parameters are associated with each prefix in the list: 428 * valid-lifetime, 430 * on-link-flag, 432 * preferred-lifetime, 434 * autonomous-flag. 436 The definitions and descriptions of the above parameters can be found 437 in the text of the module "ietf-ipv6-unicast-routing" (Section 8). 439 NOTES: 441 1. The "IsRouter" flag, which is also required by [RFC4861], is 442 implemented in the "ietf-ip" module [YANG-IP] (leaf "ip:ip- 443 forwarding"). 445 2. The original specification [RFC4861] allows the implementations 446 to decide whether the "valid-lifetime" and "preferred-lifetime" 447 parameters remain the same in consecutive advertisements, or 448 decrement in real time. However, the latter behavior seems 449 problematic because the values might be reset again to the 450 (higher) configured values after a configuration is reloaded. 451 Moreover, no implementation is known to use the decrementing 452 behavior. The "ietf-ipv6-unicast-routing" module therefore 453 assumes the former behavior with constant values. 455 4.2. Route 457 Routes are basic units of information in a routing system. The core 458 routing data model defines only the following minimal set of route 459 attributes: 461 o "destination-prefix": IP prefix specifying the set of destination 462 addresses for which the route may be used. This attribute is 463 mandatory. 465 o "next-hop": IP address of an adjacent router or host to which 466 packets with destination addresses belonging to "destination- 467 prefix" should be sent. 469 o "outgoing-interface": network interface that should be used for 470 sending packets with destination addresses belonging to 471 "destination-prefix". 473 The above list of route attributes suffices for a simple static 474 routing configuration. It is expected that future modules defining 475 routing protocols will add other route attributes such as metrics or 476 preferences. 478 Routes and their attributes are used both in configuration data, for 479 example as manually configured static routes, and in operational 480 state data, for example as entries in routing tables. 482 4.3. Routing Tables 484 Routing tables are lists of routes complemented with administrative 485 data, namely: 487 o "source-protocol": name of the routing protocol from which the 488 route was originally obtained. 490 o "age": number of seconds since the route was created or last 491 updated. 493 Each routing table may contain only routes of the same address 494 family. Address family information consists of two parameters - 495 "address-family" and "safi" (Subsequent Address Family Identifier, 496 SAFI). The permitted values for these two parameters are defined by 497 IANA and represented using YANG enumeration types "ianaaf:address- 498 family" and "ianaaf:subsequent-address-family" [IANA-IF-AF]. 500 In the core routing data model, the "routing-table" node represents 501 configuration while the descendant list of routes is defined as 502 operational state data. The contents of route lists are controlled 503 and manipulated by routing protocol operations which may result in 504 route additions, removals and modifications. This also includes 505 manipulations via the "static" and/or "direct" pseudo-protocols, see 506 Section 4.4.1. 508 One routing table MUST be present for each router instance and each 509 address family supported by that router instance. It is the so- 510 called main routing table to which all routing protocol instances 511 supporting the given address family SHOULD be connected by default. 512 For the two address families that are part of the core routing data 513 model, the names of the main routing tables SHOULD be as follows: 515 o "main-ipv4-unicast" for IPv4 unicast, 516 o "main-ipv6-unicast" for IPv6 unicast. 518 Additional routing tables MAY be configured by creating new entries 519 in the "routing-table" list, either as a part of factory-default 520 configuration, or by a client's action. 522 The naming scheme for additional routing tables, as well as 523 restrictions on the number and configurability of routing tables are 524 implementation-specific. 526 The way how the routing system uses information from routing tables 527 is outside the scope of this document. Typically, implementations 528 will either use a forwarding table, or perform a direct look-up in 529 the main routing table in conjunction with a route cache. 531 Every routing table can serve as a source of routes for other routing 532 tables. To achieve this, one or more recipient routing tables may be 533 specified in the configuration of the source routing table. In 534 addition, a route filter may be configured for each recipient routing 535 table, which selects and/or manipulates the routes that are passed on 536 between the source and recipient routing table. 538 4.4. Routing Protocols 540 The core routing data model provides an open-ended framework for 541 defining multiple routing protocol instances. Each of them is 542 identified by a name, which MUST be unique within a router instance. 543 Each protocol MUST be assigned a type, which MUST be an identity 544 derived from the "rt:routing-protocol" base identity. The core 545 routing data model defines two identities for the direct and static 546 pseudo-protocols (Section 4.4.1). 548 Each routing protocol instance is connected to exactly one routing 549 table for each address family that the routing protocol instance 550 supports. By default, every routing protocol instance SHOULD be 551 connected to the main routing table or tables. An implementation MAY 552 allow any or all routing protocol instances to be configured to use a 553 different routing table. 555 Routes learned from the network by a routing protocol are passed to 556 the connected routing table(s) and vice versa - routes appearing in a 557 routing table are passed to all routing protocols connected to the 558 table (except "direct" and "static" pseudo-protocols) and may be 559 advertised by that protocol to the network. 561 Two independent route filters (see Section 4.5) may be defined for a 562 routing protocol instance to control the exchange of routes in both 563 directions between the routing protocol instance and the connected 564 routing table: 566 o import filter controls which routes are passed from a routing 567 protocol instance to the routing table, 569 o export filter controls which routes the routing protocol instance 570 may receive from the connected routing table. 572 Note that, for historical reasons, the terms import and export are 573 used from the viewpoint of a routing table. 575 4.4.1. Routing Pseudo-Protocols 577 The core routing data model defines two special routing protocol 578 types - "direct" and "static". Both are in fact pseudo-protocols, 579 which means that they are confined to the local device and do not 580 exchange any routing information with neighboring routers. Routes 581 from both "direct" and "static" protocol instances are passed to the 582 connected routing table (subject to route filters, if any), but an 583 exchange in the opposite direction is not allowed. 585 Every router instance MUST contain exactly one instance of the 586 "direct" pseudo-protocol type. The name of this instance MUST also 587 be "direct". It is the source of direct routes for all configured 588 address families. Direct routes are normally supplied by the 589 operating system kernel, based on the configuration of network 590 interface addresses, see Section 5.2. Direct routes SHOULD by 591 default appear in the main routing table for each configured address 592 family. However, using the framework defined in this document, the 593 target routing table for direct routes MAY be changed by connecting 594 the "direct" protocol instance to a non-default routing table. 595 Direct routes can also be filtered before they appear in the routing 596 table. 598 A pseudo-protocol of the type "static" allows for specifying routes 599 manually. It MAY be configured in zero or multiple instances, 600 although a typical implementation will have exactly one instance per 601 logical router. 603 4.4.2. Defining New Routing Protocols 605 It is expected that future YANG modules will create data models for 606 additional routing protocol types. Such a new module has to define 607 the protocol-specific configuration and operational state data, and 608 it has to fit it into the core routing framework in the following 609 way: 611 o A new identity MUST be defined for the routing protocol and its 612 base identity MUST be set to "rt:routing-protocol", or to an 613 identity derived from "rt:routing-protocol". 615 o Additional route attributes MAY be defined, preferably in one 616 place by means of defining a YANG grouping. The new attributes 617 have to be inserted as operational state data by augmenting the 618 definition of "rt:route" inside "rt:routing-table", and possibly 619 to other places in the configuration, operational state data and 620 RPC input or output. 622 o Per-interface configuration parameters can be added by augmenting 623 the data node "rt:interface" (the list of router interfaces). 625 o Other configuration parameters and operational state data can be 626 defined by augmenting the "routing-protocol" data node. By using 627 the "when" statement, this augment SHOULD be made conditional and 628 valid only if the value of the "rt:type" child leaf equals to the 629 new protocol's identity. 631 It is RECOMMENDED that both per-interface and other configuration 632 data specific to the new protocol be encapsulated in an appropriately 633 named container. 635 The above steps are implemented by the example YANG module for the 636 RIP routing protocol in Appendix A. First, the module defines a new 637 identity for the RIP protocol: 639 identity rip { 640 base rt:routing-protocol; 641 description "Identity for the RIP routing protocol."; 642 } 644 New route attributes specific to the RIP protocol ("metric" and 645 "tag") are defined in a grouping and then added to the route 646 definitions appearing in "routing-table" and in the output part of 647 the "active-route" RPC method: 649 grouping route-content { 650 description 651 "RIP-specific route content."; 652 leaf metric { 653 type rip-metric; 654 } 655 leaf tag { 656 type uint16; 657 default "0"; 658 description 659 "This leaf may be used to carry additional info, e.g. AS 660 number."; 661 } 662 } 664 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 665 + "rt:routes/rt:route" { 666 when "../../../../rt:routing-protocols/" 667 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 668 + "rt:type='rip:rip'" { 669 description 670 "This augment is only valid if the source protocol from which 671 the route originated is RIP."; 672 } 673 description 674 "RIP-specific route components."; 675 uses route-content; 676 } 678 augment "/rt:active-route/rt:output/rt:route" { 679 description 680 "Add RIP-specific route content."; 681 uses route-content; 682 } 684 Per-interface configuration data are defined by the following 685 "augment" statement: 687 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 688 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 689 + "'rip:rip'"; 690 container rip { 691 description 692 "Per-interface RIP configuration."; 693 leaf enabled { 694 type boolean; 695 default "true"; 696 } 697 leaf metric { 698 type rip-metric; 699 default "1"; 700 } 701 } 702 } 704 Finally, global RIP configuration data are integrated into the "rt: 705 routing-protocol" node by using the following "augment" statement, 706 which is again valid only for routing protocol instances whose type 707 is "rip:rip": 709 augment "/rt:routing/rt:router/rt:routing-protocols/" 710 + "rt:routing-protocol" { 711 when "rt:type = 'rip:rip'"; 712 container rip { 713 leaf update-interval { 714 type uint8 { 715 range "10..60"; 716 } 717 units "seconds"; 718 default "30"; 719 description 720 "Time interval between periodic updates."; 721 } 722 } 723 } 725 4.5. Route Filters 727 The core routing data model provides a skeleton for defining route 728 filters that can be used to restrict the set of routes being 729 exchanged between a routing protocol instance and a connected routing 730 table, or between a source and a recipient routing table. Route 731 filters may also manipulate routes, i.e., add, delete, or modify 732 their attributes. 734 Route filters are global, which means that a configured route filter 735 may be used by any or all router instances. 737 By itself, the route filtering framework defined in this document 738 allows for applying only the extreme routing policies which are 739 represented by the following pre-defined route filter types: 741 o "deny-all-route-filter": all routes are blocked, 743 o "allow-all-route-filter": all routes are permitted. 745 Note that the latter type is equivalent to no route filter. 747 It is expected that more comprehensive route filtering frameworks 748 will be developed separately. 750 Each route filter is identified by a name which MUST be unique within 751 the entire configuration. Its type MUST be specified by the "type" 752 identity reference - this opens the space for multiple route 753 filtering framework implementations. The default value for the route 754 filter type is the identity "deny-all-route-filter". 756 4.6. RPC Operations 758 The "ietf-routing" module defines two RPC operations: 760 o active-route, 762 o route-count. 764 Their parameters and semantics are described in the following 765 subsections. 767 4.6.1. Operation "active-route" 769 Description: Retrieve one or more active routes from the forwarding 770 information base (FIB) of a router instance, i.e., the route(s) 771 that are currently used by that router instance for sending 772 datagrams to the destination whose address is provided as an input 773 parameter. 775 Parameters: 777 router-name: Name of the router instance whose FIB is to be 778 queried. 780 destination-address: Network layer destination address for which 781 the active routes are requested. 783 Positive Response: One or more "route" elements containing the 784 active route(s). 786 Negative Response: 788 If the logical router is not found, the server sends an "rpc- 789 error" message with "error-tag" set to "data-missing", and "error- 790 app-tag" set to "router-not-found". 792 If no route exists for the given destination address, the server 793 sends an "rpc-error" message with "error-tag" set to "data- 794 missing" and "error-app-tag" set to "no-route". 796 4.6.2. Operation "route-count" 798 Description: Retrieve the total number of routes in a routing table. 800 Parameters: 802 router-name: Name of the logical router containing the routing 803 table. 805 routing-table: Name of the routing table. 807 Positive Response: Element "number-of-routes" containing the 808 requested nonnegative number. 810 Negative Response: If the logical router or the routing table is not 811 found, the server sends an "rpc-error" message with "error-tag" 812 set to "data-missing", and "error-app-tag" set to "router-not- 813 found" or "routing-table-not-found", respectively. 815 5. Interactions with Other YANG Modules 817 The semantics of the core routing data model also depend on several 818 configuration parameters that are defined in other YANG modules. The 819 following subsections describe these interactions. 821 5.1. Module "ietf-interfaces" 823 The following boolean switch is defined in the "ietf-interfaces" YANG 824 module [YANG-IF]: 826 /if:interfaces/if:interface/if:enabled 828 If this switch is set to "false" for a given network layer 829 interface, the device MUST behave exactly as if that interface was 830 not assigned to any logical router at all. 832 5.2. Module "ietf-ip" 834 The following boolean switches are defined in the "ietf-ip" YANG 835 module [YANG-IP]: 837 /if:interfaces/if:interface/ip:ipv4/ip:enabled 839 If this switch is set to "false" for a given interface, then all 840 IPv4 routing functions related to that interface MUST be disabled. 842 /if:interfaces/if:interface/ip:ipv4/ip:ip-forwarding 844 If this switch is set to "false" for a given interface, then the 845 forwarding of IPv4 datagrams to and from this interface MUST be 846 disabled. However, the interface may participate in other routing 847 functions, such as routing protocols. 849 /if:interfaces/if:interface/ip:ipv6/ip:enabled 851 If this switch is set to "false" for a given interface, then all 852 IPv6 routing functions related to that interface MUST be disabled. 854 /if:interfaces/if:interface/ip:ipv6/ip:ip-forwarding 856 If this switch is set to "false" for a given interface, then the 857 forwarding of IPv6 datagrams to and from this interface MUST be 858 disabled. However, the interface may participate in other routing 859 functions, such as routing protocols. 861 In addition, the "ietf-ip" module allows for configuring IPv4 and 862 IPv6 addresses and subnet masks. Configuration of these parameters 863 on an enabled interface MUST result in an immediate creation of the 864 corresponding direct route (usually in the main routing table). Its 865 destination prefix is set according to the configured IP address and 866 subnet mask, and the interface is set as the outgoing interface for 867 that route. 869 6. Routing YANG Module 871 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 872 actual RFC number and all occurrences of the revision date below with 873 the date of RFC publication (and remove this note). 875 file "ietf-routing@2012-07-09.yang" 877 module ietf-routing { 879 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 881 prefix "rt"; 883 import ietf-inet-types { 884 prefix "inet"; 885 } 887 import ietf-interfaces { 888 prefix "if"; 889 } 891 import iana-afn-safi { 892 prefix "ianaaf"; 893 } 895 organization 896 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 898 contact 899 "WG Web: 900 WG List: 902 WG Chair: David Kessens 903 905 WG Chair: Juergen Schoenwaelder 906 908 Editor: Ladislav Lhotka 909 910 "; 912 description 913 "This YANG module defines essential components that may be used 914 for configuring a routing subsystem. 916 Copyright (c) 2012 IETF Trust and the persons identified as 917 authors of the code. All rights reserved. 919 Redistribution and use in source and binary forms, with or 920 without modification, is permitted pursuant to, and subject to 921 the license terms contained in, the Simplified BSD License set 922 forth in Section 4.c of the IETF Trust's Legal Provisions 923 Relating to IETF Documents 924 (http://trustee.ietf.org/license-info). 926 This version of this YANG module is part of RFC XXXX; see the 927 RFC itself for full legal notices. 928 "; 930 revision 2012-07-09 { 931 description 932 "Initial revision."; 933 reference 934 "RFC XXXX: A YANG Data Model for Routing Configuration"; 935 } 937 /* Identities */ 939 identity routing-protocol { 940 description 941 "Base identity from which routing protocol identities are 942 derived."; 943 } 945 identity direct { 946 base routing-protocol; 947 description 948 "Routing pseudo-protocol which provides routes to directly 949 connected networks."; 950 } 952 identity static { 953 base routing-protocol; 954 description 955 "Static routing pseudo-protocol."; 956 } 958 identity route-filter { 959 description 960 "Base identity from which all route filters are derived."; 961 } 963 identity deny-all-route-filter { 964 base route-filter; 965 description 966 "Route filter that blocks all routes."; 967 } 969 identity allow-all-route-filter { 970 base route-filter; 971 description 972 "Route filter that permits all routes. 973 "; 974 } 976 /* Type Definitions */ 978 typedef router-ref { 979 type leafref { 980 path "/rt:routing/rt:router/rt:name"; 981 } 982 description 983 "This type is used for leafs that reference a router 984 instance."; 985 } 987 /* Groupings */ 989 grouping afn-safi { 990 leaf address-family { 991 type ianaaf:address-family; 992 default "ipv4"; 993 description 994 "Address family of routes in the routing table."; 995 } 996 leaf safi { 997 type ianaaf:subsequent-address-family; 998 default "nlri-unicast"; 999 description 1000 "Subsequent address family identifier of routes in the 1001 routing table."; 1002 } 1003 description 1004 "This grouping provides two parameters specifying address 1005 family and subsequent address family."; 1006 } 1008 grouping route-content { 1009 description 1010 "Generic parameters of routes. 1012 A module for an address family should define a specific 1013 version of this grouping containing 'uses rt:route-content'. 1014 "; 1015 leaf outgoing-interface { 1016 type if:interface-ref; 1017 description 1018 "Outgoing interface."; 1019 } 1020 } 1022 /* RPC Methods */ 1024 rpc active-route { 1025 description 1026 "Return the active route (or multiple routes, in the case of 1027 multi-path routing) to a destination address. 1029 Parameters 1031 1. 'router-name', 1033 2. 'destination-address'. 1035 If the logical router with 'router-name' doesn't exist, then 1036 this operation will fail with error-tag 'missing-element' and 1037 error-app-tag 'router-not-found'. 1039 If there is no active route for 'destination-address', then 1040 this operation will fail with error-tag 'data-missing' and 1041 error-app-tag 'no-route'. 1042 "; 1043 input { 1044 leaf router-name { 1045 type router-ref; 1046 mandatory "true"; 1047 description 1048 "Name of the router instance whose forwarding information 1049 base is being queried."; 1050 } 1051 container destination-address { 1052 uses afn-safi; 1053 description 1054 "Network layer destination address. 1056 AFN/SAFI-specific modules must augment this container with 1057 a leaf named 'address'. 1058 "; 1059 } 1060 } 1061 output { 1062 list route { 1063 min-elements "1"; 1064 uses afn-safi; 1065 uses route-content; 1066 description 1067 "Route contents specific for each address family should be 1068 defined through augmenting."; 1069 } 1070 } 1071 } 1073 rpc route-count { 1074 description 1075 "Return the current number of routes in a routing table. 1077 Parameters: 1079 1. 'router-name', 1081 2. 'routing-table-name'. 1083 If the logical router with 'router-name' doesn't exist, then 1084 this operation will fail with error-tag 'missing-element' and 1085 error-app-tag 'router-not-found'. 1087 If the routing table with 'routing-table-name' doesn't exist, 1088 then this operation will fail with error-tag 'missing-element' 1089 and error-app-tag 'routing-table-not-found'. 1090 "; 1091 input { 1092 leaf router-name { 1093 type router-ref; 1094 mandatory "true"; 1095 description 1096 "Name of the router instance containing the routing 1097 table."; 1098 } 1099 leaf routing-table { 1100 type leafref { 1101 path "/routing/router/routing-tables/routing-table/name"; 1102 } 1103 mandatory "true"; 1104 description 1105 "Name of the routing table."; 1106 } 1107 } 1108 output { 1109 leaf number-of-routes { 1110 type uint32; 1111 mandatory "true"; 1112 description 1113 "Number of routes in the routing table."; 1114 } 1115 } 1116 } 1118 /* Data Nodes */ 1120 container routing { 1121 description 1122 "Routing parameters."; 1123 list router { 1124 key "name"; 1125 unique "router-id"; 1126 description 1127 'Each list entry is a container for configuration and 1128 operational state data of a single (logical) router. 1130 Network layer interfaces assigned to the router must have 1131 their entries in the "interfaces" list. 1132 '; 1133 leaf name { 1134 type string; 1135 description 1136 "The unique router name."; 1137 } 1138 leaf router-id { 1139 type inet:ipv4-address; 1140 description 1141 "Global router ID in the form of an IPv4 address. 1143 An implementation may select a value if this parameter is 1144 not configured. 1146 Routing protocols may override this global parameter 1147 inside their configuration. 1148 "; 1149 } 1150 leaf description { 1151 type string; 1152 description 1153 "Textual description of the router."; 1154 } 1155 leaf enabled { 1156 type boolean; 1157 default "true"; 1158 description 1159 "Enable the router. The default value is 'true'. 1161 If this parameter is false, the parent router instance is 1162 disabled, despite any other configuration that might be 1163 present. 1164 "; 1165 } 1166 container interfaces { 1167 description 1168 "Router interface parameters."; 1169 list interface { 1170 key "name"; 1171 description 1172 "List of network layer interfaces assigned to the router 1173 instance."; 1174 leaf name { 1175 type if:interface-ref; 1176 description 1177 "A reference to the name of a configured network layer 1178 interface."; 1179 } 1180 } 1181 } 1182 container routing-protocols { 1183 description 1184 "Container for the list of configured routing protocol 1185 instances."; 1186 list routing-protocol { 1187 key "name"; 1188 description 1189 "An instance of a routing protocol."; 1190 leaf name { 1191 type string; 1192 description 1193 "The name of the routing protocol instance."; 1194 } 1195 leaf description { 1196 type string; 1197 description 1198 "Textual description of the routing protocol 1199 instance."; 1200 } 1201 leaf type { 1202 type identityref { 1203 base routing-protocol; 1204 } 1205 mandatory "true"; 1206 description 1207 "Type of the routing protocol - an identity derived 1208 from the 'routing-protocol' base identity."; 1209 } 1210 container connected-routing-tables { 1211 description 1212 "Container for connected routing tables."; 1213 list routing-table { 1214 must "not(../../../../routing-tables/" 1215 + "routing-table[rt:name=current()/" 1216 + "preceding-sibling::routing-table/name]/" 1217 + "address-family=../../../../routing-tables/" 1218 + "routing-table[rt:name=current()/name]/" 1219 + "address-family and ../../../../routing-tables/" 1220 + "routing-table[rt:name=current()/" 1221 + "preceding-sibling::routing-table/name]/safi=../" 1222 + "../../../routing-tables/" 1223 + "routing-table[rt:name=current()/name]/safi)" { 1224 error-message "Each routing protocol may have no " 1225 + "more than one connected routing " 1226 + "table for each AFN and SAFI."; 1227 description 1228 "For each AFN/SAFI pair there may be at most one 1229 connected routing table."; 1230 } 1231 key "name"; 1232 description 1233 "List of routing tables to which the routing protocol 1234 instance is connected. 1236 If no connected routing table is defined for an 1237 address family, the routing protocol should be 1238 connected by default to the main routing table for 1239 that address family. 1240 "; 1241 leaf name { 1242 type leafref { 1243 path "../../../../../routing-tables/routing-table/" 1244 + "name"; 1245 } 1246 description 1247 "Reference to an existing routing table."; 1248 } 1249 leaf import-filter { 1250 type leafref { 1251 path "/routing/route-filters/route-filter/name"; 1252 } 1253 description 1254 "Reference to a route filter that is used for 1255 filtering routes passed from this routing protocol 1256 instance to the routing table specified by the 1257 'name' sibling node. If this leaf is not present, 1258 the behavior is protocol-specific, but typically 1259 it means that all routes are accepted."; 1260 } 1261 leaf export-filter { 1262 type leafref { 1263 path "/routing/route-filters/route-filter/name"; 1264 } 1265 description 1266 "Reference to a route filter that is used for 1267 filtering routes passed from the routing table 1268 specified by the 'name' sibling node to this 1269 routing protocol instance. If this leaf is not 1270 present, the behavior is protocol-specific - 1271 typically it means that all routes are accepted, 1272 except for the 'direct' and 'static' 1273 pseudo-protocols which accept no routes from any 1274 routing table."; 1275 } 1276 } 1277 } 1278 container static-routes { 1279 must "../type='rt:static'" { 1280 error-message "Static routes may be configured only " 1281 + "for 'static' routing protocol."; 1282 description 1283 "This container is only valid for the 'static' 1284 routing protocol."; 1285 } 1286 description 1287 "Configuration of 'static' pseudo-protocol."; 1288 } 1289 } 1290 } 1291 container routing-tables { 1292 description 1293 "Container for configured routing tables."; 1294 list routing-table { 1295 key "name"; 1296 description 1297 "Each entry represents a routing table identified by the 1298 'name' key. All routes in a routing table must have the 1299 same AFN and SAFI."; 1300 leaf name { 1301 type string; 1302 description 1303 "The name of the routing table."; 1304 } 1305 uses afn-safi; 1306 leaf description { 1307 type string; 1308 description 1309 "Textual description of the routing table."; 1310 } 1311 container routes { 1312 config "false"; 1313 description 1314 "Current contents of the routing table (operational 1315 state data)."; 1316 list route { 1317 description 1318 "A routing table entry. This data node must augmented 1319 with information specific for routes of each address 1320 family."; 1321 uses route-content; 1322 leaf source-protocol { 1323 type leafref { 1324 path "/routing/router/routing-protocols/" 1325 + "routing-protocol/name"; 1326 } 1327 mandatory "true"; 1328 description 1329 "The name of the routing protocol instance from 1330 which the route comes. This routing protocol must 1331 be configured (automatically or manually) in the 1332 device."; 1333 } 1334 leaf age { 1335 type uint32; 1336 units "seconds"; 1337 mandatory "true"; 1338 description 1339 "The number of seconds since the parent route was 1340 created or last updated."; 1341 } 1342 } 1343 } 1344 container recipient-routing-tables { 1345 description 1346 "Container for recipient routing tables."; 1347 list recipient-routing-table { 1348 key "name"; 1349 description 1350 "A list of routing tables that receive routes from 1351 this routing table."; 1352 leaf name { 1353 type leafref { 1354 path "/routing/router/routing-tables/" 1355 + "routing-table/name"; 1356 } 1357 description 1358 "The name of the recipient routing table."; 1359 } 1360 leaf filter { 1361 type leafref { 1362 path "/routing/route-filters/route-filter/name"; 1363 } 1364 description 1365 "A route filter which is applied to the routes 1366 passed on to the recipient routing table."; 1367 } 1368 } 1369 } 1370 } 1371 } 1372 } 1373 container route-filters { 1374 description 1375 "Container for configured route filters."; 1376 list route-filter { 1377 key "name"; 1378 description 1379 "Route filters are used for filtering and/or manipulating 1380 routes that are passed between a routing protocol and a 1381 routing table or vice versa, or between two routing 1382 tables. It is expected that other modules augment this 1383 list with contents specific for a particular route filter 1384 type."; 1385 leaf name { 1386 type string; 1387 description 1388 "The name of the route filter."; 1389 } 1390 leaf description { 1391 type string; 1392 description 1393 "Textual description of the route filter."; 1394 } 1395 leaf type { 1396 type identityref { 1397 base route-filter; 1398 } 1399 default "rt:deny-all-route-filter"; 1400 description 1401 "Type of the route-filter - an identity derived from the 1402 'route-filter' base identity. The default value 1403 represents an all-blocking filter."; 1404 } 1405 } 1406 } 1407 } 1408 } 1410 1412 7. IPv4 Unicast Routing YANG Module 1414 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1415 actual RFC number and all occurrences of the revision date below with 1416 the date of RFC publication (and remove this note). 1418 file "ietf-ipv4-unicast-routing@2012-07-09.yang" 1420 module ietf-ipv4-unicast-routing { 1422 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1424 prefix "v4ur"; 1426 import ietf-routing { 1427 prefix "rt"; 1428 } 1430 import ietf-inet-types { 1431 prefix "inet"; 1432 } 1434 organization 1435 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1437 contact 1438 "WG Web: 1439 WG List: 1441 WG Chair: David Kessens 1442 1444 WG Chair: Juergen Schoenwaelder 1445 1447 Editor: Ladislav Lhotka 1448 1449 "; 1451 description 1452 "This YANG module augments the 'ietf-routing' module with basic 1453 configuration and operational state data for IPv4 unicast 1454 routing. 1456 Every implementation must preconfigure a routing table with the 1457 name 'main-ipv4-unicast', which is the main routing table for 1458 IPv4 unicast. 1460 Copyright (c) 2012 IETF Trust and the persons identified as 1461 authors of the code. All rights reserved. 1463 Redistribution and use in source and binary forms, with or 1464 without modification, is permitted pursuant to, and subject to 1465 the license terms contained in, the Simplified BSD License set 1466 forth in Section 4.c of the IETF Trust's Legal Provisions 1467 Relating to IETF Documents 1468 (http://trustee.ietf.org/license-info). 1470 This version of this YANG module is part of RFC XXXX; see the 1471 RFC itself for full legal notices. 1472 "; 1474 revision 2012-07-09 { 1475 description 1476 "Initial revision."; 1477 reference 1478 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1479 } 1481 /* Groupings */ 1483 grouping route-content { 1484 description 1485 "Parameters of IPv4 unicast routes."; 1486 leaf dest-prefix { 1487 type inet:ipv4-prefix; 1488 description 1489 "IPv4 destination prefix."; 1490 } 1491 leaf next-hop { 1492 type inet:ipv4-address; 1493 description 1494 "IPv4 address of the next hop."; 1495 } 1496 } 1498 /* RPC Methods */ 1500 augment "/rt:active-route/rt:input/rt:destination-address" { 1501 when "address-family='ipv4' and safi='nlri-unicast'" { 1502 description 1503 "This augment is valid only for IPv4 unicast."; 1504 } 1505 description 1506 "The 'address' leaf augments the 'rt:destination-address' 1507 parameter of the 'rt:active-route' operation."; 1509 leaf address { 1510 type inet:ipv4-address; 1511 description 1512 "IPv4 destination address."; 1513 } 1514 } 1516 augment "/rt:active-route/rt:output/rt:route" { 1517 when "address-family='ipv4' and safi='nlri-unicast'" { 1518 description 1519 "This augment is valid only for IPv4 unicast."; 1520 } 1521 description 1522 "Contents of the reply to 'rt:active-route' operation."; 1523 uses route-content; 1524 } 1526 /* Data nodes */ 1528 augment "/rt:routing/rt:router/rt:routing-protocols/" 1529 + "rt:routing-protocol/rt:static-routes" { 1530 description 1531 "This augment defines the configuration of the 'static' 1532 pseudo-protocol with data specific for IPv4 unicast."; 1533 container ipv4 { 1534 description 1535 "Configuration of a 'static' pseudo-protocol instance 1536 consists of a list of routes."; 1537 list route { 1538 key "id"; 1539 ordered-by "user"; 1540 description 1541 "A user-ordered list of static routes."; 1542 leaf id { 1543 type uint32 { 1544 range "1..max"; 1545 } 1546 description 1547 'Numeric identifier of the route. 1549 It is not required that the routes be sorted according 1550 to their "id". 1551 '; 1552 } 1553 leaf description { 1554 type string; 1555 description 1556 "Textual description of the route."; 1558 } 1559 uses rt:route-content; 1560 uses route-content { 1561 refine "dest-prefix" { 1562 mandatory "true"; 1563 } 1564 } 1565 } 1566 } 1567 } 1569 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 1570 + "rt:routes/rt:route" { 1571 when "../../rt:address-family='ipv4' and " 1572 + "../../rt:safi='nlri-unicast'" { 1573 description 1574 "This augment is valid only for IPv4 unicast."; 1575 } 1576 description 1577 "This augment defines the content of IPv4 unicast routes."; 1578 uses route-content; 1579 } 1580 } 1582 1584 8. IPv6 Unicast Routing YANG Module 1586 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1587 actual RFC number and all occurrences of the revision date below with 1588 the date of RFC publication (and remove this note). 1590 file "ietf-ipv6-unicast-routing@2012-07-09.yang" 1592 module ietf-ipv6-unicast-routing { 1594 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1596 prefix "v6ur"; 1598 import ietf-routing { 1599 prefix "rt"; 1600 } 1602 import ietf-inet-types { 1603 prefix "inet"; 1604 } 1606 import ietf-interfaces { 1607 prefix "if"; 1608 } 1610 import ietf-ip { 1611 prefix "ip"; 1612 } 1614 organization 1615 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1617 contact 1618 "WG Web: 1619 WG List: 1621 WG Chair: David Kessens 1622 1624 WG Chair: Juergen Schoenwaelder 1625 1627 Editor: Ladislav Lhotka 1628 1629 "; 1631 description 1632 "This YANG module augments the 'ietf-routing' module with basic 1633 configuration and operational state data for IPv6 unicast 1634 routing. 1636 Every implementation must preconfigure a routing table with the 1637 name 'main-ipv6-unicast', which is the main routing table for 1638 IPv6 unicast. 1640 Copyright (c) 2012 IETF Trust and the persons identified as 1641 authors of the code. All rights reserved. 1643 Redistribution and use in source and binary forms, with or 1644 without modification, is permitted pursuant to, and subject to 1645 the license terms contained in, the Simplified BSD License set 1646 forth in Section 4.c of the IETF Trust's Legal Provisions 1647 Relating to IETF Documents 1648 (http://trustee.ietf.org/license-info). 1650 This version of this YANG module is part of RFC XXXX; see the 1651 RFC itself for full legal notices. 1652 "; 1654 revision 2012-07-09 { 1655 description 1656 "Initial revision."; 1657 reference 1658 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1659 } 1661 /* Groupings */ 1663 grouping route-content { 1664 description 1665 "Specific parameters of IPv6 unicast routes."; 1666 leaf dest-prefix { 1667 type inet:ipv6-prefix; 1668 description 1669 "IPv6 destination prefix."; 1670 } 1671 leaf next-hop { 1672 type inet:ipv6-address; 1673 description 1674 "IPv6 address of the next hop."; 1675 } 1676 } 1678 /* RPC Methods */ 1679 augment "/rt:active-route/rt:input/rt:destination-address" { 1680 when "address-family='ipv6' and safi='nlri-unicast'" { 1681 description 1682 "This augment is valid only for IPv6 unicast."; 1683 } 1684 description 1685 "The 'address' leaf augments the 'rt:destination-address' 1686 parameter of the 'rt:active-route' operation."; 1687 leaf address { 1688 type inet:ipv6-address; 1689 description 1690 "IPv6 destination address."; 1691 } 1692 } 1694 augment "/rt:active-route/rt:output/rt:route" { 1695 when "address-family='ipv6' and safi='nlri-unicast'" { 1696 description 1697 "This augment is valid only for IPv6 unicast."; 1698 } 1699 description 1700 "Contents of the reply to 'rt:active-route' operation."; 1701 uses route-content; 1702 } 1704 /* Data nodes */ 1706 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 1707 when "/if:interfaces/if:interface[name=current()/name]/ip:ipv6/" 1708 + "ip:enabled='true'" { 1709 description 1710 "This augment is only valid for router interfaces with 1711 enabled IPv6. 1713 NOTE: Parameter 'is-router' is not included, it is expected 1714 that it will be implemented by the 'ietf-ip' module. 1715 "; 1716 } 1717 description 1718 "IPv6-specific parameters of router interfaces."; 1719 container ipv6-router-advertisements { 1720 description 1721 "Parameters of IPv6 Router Advertisements."; 1722 reference 1723 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6). 1725 RFC 4862: IPv6 Stateless Address Autoconfiguration. 1726 "; 1728 leaf send-advertisements { 1729 type boolean; 1730 default "false"; 1731 description 1732 "A flag indicating whether or not the router sends periodic 1733 Router Advertisements and responds to Router 1734 Solicitations."; 1735 } 1736 leaf max-rtr-adv-interval { 1737 type uint16 { 1738 range "4..1800"; 1739 } 1740 units "seconds"; 1741 default "600"; 1742 description 1743 "The maximum time allowed between sending unsolicited 1744 multicast Router Advertisements from the interface."; 1745 } 1746 leaf min-rtr-adv-interval { 1747 type uint16 { 1748 range "3..1350"; 1749 } 1750 units "seconds"; 1751 description 1752 "The minimum time allowed between sending unsolicited 1753 multicast Router Advertisements from the interface. 1755 Must be no greater than 0.75 * max-rtr-adv-interval. 1757 Its default value is dynamic: 1759 - if max-rtr-adv-interval >= 9 seconds, the default value 1760 is 0.33 * max-rtr-adv-interval; 1762 - otherwise it is 0.75 * max-rtr-adv-interval. 1763 "; 1764 } 1765 leaf managed-flag { 1766 type boolean; 1767 default "false"; 1768 description 1769 "The boolean value to be placed in the 'Managed address 1770 configuration' flag field in the Router Advertisement."; 1771 } 1772 leaf other-config-flag { 1773 type boolean; 1774 default "false"; 1775 description 1776 "The boolean value to be placed in the 'Other 1777 configuration' flag field in the Router Advertisement."; 1778 } 1779 leaf link-mtu { 1780 type uint32; 1781 default "0"; 1782 description 1783 "The value to be placed in MTU options sent by the router. 1784 A value of zero indicates that no MTU options are sent."; 1785 } 1786 leaf reachable-time { 1787 type uint32 { 1788 range "0..3600000"; 1789 } 1790 units "milliseconds"; 1791 default "0"; 1792 description 1793 "The value to be placed in the Reachable Time field in the 1794 Router Advertisement messages sent by the router. The 1795 value zero means unspecified (by this router)."; 1796 } 1797 leaf retrans-timer { 1798 type uint32; 1799 units "milliseconds"; 1800 default "0"; 1801 description 1802 "The value to be placed in the Retrans Timer field in the 1803 Router Advertisement messages sent by the router. The 1804 value zero means unspecified (by this router)."; 1805 } 1806 leaf cur-hop-limit { 1807 type uint8; 1808 default "64"; 1809 description 1810 "The default value to be placed in the Cur Hop Limit field 1811 in the Router Advertisement messages sent by the router. 1812 The value should be set to the current diameter of the 1813 Internet. The value zero means unspecified (by this 1814 router). 1816 The default should be set to the value specified in IANA 1817 Assigned Numbers that was in effect at the time of 1818 implementation. 1819 "; 1820 reference 1821 "IANA: IP Parameters, 1822 http://www.iana.org/assignments/ip-parameters"; 1823 } 1824 leaf default-lifetime { 1825 type uint16 { 1826 range "0..9000"; 1827 } 1828 units "seconds"; 1829 description 1830 "The value to be placed in the Router Lifetime field of 1831 Router Advertisements sent from the interface, in seconds. 1832 MUST be either zero or between max-rtr-adv-interval and 1833 9000 seconds. A value of zero indicates that the router is 1834 not to be used as a default router. These limits may be 1835 overridden by specific documents that describe how IPv6 1836 operates over different link layers. 1838 The default value is dynamic and should be set to 3 * 1839 max-rtr-adv-interval. 1840 "; 1841 } 1842 container prefix-list { 1843 description 1844 "A list of prefixes to be placed in Prefix Information 1845 options in Router Advertisement messages sent from the 1846 interface. 1848 By default, all prefixes that the router advertises via 1849 routing protocols as being on-link for the interface from 1850 which the advertisement is sent. The link-local prefix 1851 should not be included in the list of advertised prefixes. 1852 "; 1853 list prefix { 1854 key "prefix-spec"; 1855 description 1856 "Advertised prefix entry."; 1857 leaf prefix-spec { 1858 type inet:ipv6-prefix; 1859 description 1860 "IPv6 address prefix."; 1861 } 1862 choice control-adv-prefixes { 1863 default "advertise"; 1864 description 1865 "The prefix either may be explicitly removed from the 1866 set of advertised prefixes, or parameters with which 1867 it is advertised may be specified (default case)."; 1868 leaf no-advertise { 1869 type empty; 1870 description 1871 "The prefix will not be advertised. 1873 This may be used for removing the prefix from the 1874 default set of advertised prefixes. 1875 "; 1876 } 1877 case advertise { 1878 leaf valid-lifetime { 1879 type uint32; 1880 units "seconds"; 1881 default "2592000"; 1882 description 1883 "The value to be placed in the Valid Lifetime in 1884 the Prefix Information option, in seconds. The 1885 designated value of all 1's (0xffffffff) 1886 represents infinity. 1887 "; 1888 } 1889 leaf on-link-flag { 1890 type boolean; 1891 default "true"; 1892 description 1893 "The value to be placed in the on-link flag 1894 ('L-bit') field in the Prefix Information 1895 option."; 1896 } 1897 leaf preferred-lifetime { 1898 type uint32; 1899 units "seconds"; 1900 must ". <= ../valid-lifetime" { 1901 description 1902 "This value must not be larger than 1903 valid-lifetime."; 1904 } 1905 default "604800"; 1906 description 1907 "The value to be placed in the Preferred Lifetime 1908 in the Prefix Information option, in seconds. The 1909 designated value of all 1's (0xffffffff) 1910 represents infinity. 1911 "; 1912 } 1913 leaf autonomous-flag { 1914 type boolean; 1915 default "true"; 1916 description 1917 "The value to be placed in the Autonomous Flag 1918 field in the Prefix Information option."; 1919 } 1920 } 1922 } 1923 } 1924 } 1925 } 1926 } 1928 augment "/rt:routing/rt:router/rt:routing-protocols/" 1929 + "rt:routing-protocol/rt:static-routes" { 1930 description 1931 "This augment defines the configuration of the 'static' 1932 pseudo-protocol with data specific for IPv6 unicast."; 1933 container ipv6 { 1934 description 1935 "Configuration of a 'static' pseudo-protocol instance 1936 consists of a list of routes."; 1937 list route { 1938 key "id"; 1939 ordered-by "user"; 1940 description 1941 "A user-ordered list of static routes."; 1942 leaf id { 1943 type uint32 { 1944 range "1..max"; 1945 } 1946 description 1947 'Numeric identifier of the route. 1949 It is not required that the routes be sorted according 1950 to their "id". 1951 '; 1952 } 1953 leaf description { 1954 type string; 1955 description 1956 "Textual description of the route."; 1957 } 1958 uses rt:route-content; 1959 uses route-content { 1960 refine "dest-prefix" { 1961 mandatory "true"; 1962 } 1963 } 1964 } 1965 } 1966 } 1968 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 1969 + "rt:routes/rt:route" { 1971 when "../../rt:address-family='ipv6' and " 1972 + "../../rt:safi='nlri-unicast'" { 1973 description 1974 "This augment is valid only for IPv6 unicast."; 1975 } 1976 description 1977 "This augment defines the content of IPv6 unicast routes."; 1978 uses route-content; 1979 } 1980 } 1982 1984 9. IANA Considerations 1986 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1987 actual RFC number (and remove this note). 1989 This document registers the following namespace URIs in the IETF XML 1990 registry [RFC3688]: 1992 ---------------------------------------------------------- 1993 URI: urn:ietf:params:xml:ns:yang:ietf-routing 1995 Registrant Contact: The IESG. 1997 XML: N/A, the requested URI is an XML namespace. 1998 ---------------------------------------------------------- 2000 ---------------------------------------------------------- 2001 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2003 Registrant Contact: The IESG. 2005 XML: N/A, the requested URI is an XML namespace. 2006 ---------------------------------------------------------- 2008 ---------------------------------------------------------- 2009 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2011 Registrant Contact: The IESG. 2013 XML: N/A, the requested URI is an XML namespace. 2014 ---------------------------------------------------------- 2016 This document registers the following YANG modules in the YANG Module 2017 Names registry [RFC6020]: 2019 ------------------------------------------------------------------- 2020 name: ietf-routing 2021 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2022 prefix: rt 2023 reference: RFC XXXX 2024 ------------------------------------------------------------------- 2026 ------------------------------------------------------------------- 2027 name: ietf-ipv4-unicast-routing 2028 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2029 prefix: v4ur 2030 reference: RFC XXXX 2031 ------------------------------------------------------------------- 2033 ------------------------------------------------------------------- 2034 name: ietf-ipv6-unicast-routing 2035 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2036 prefix: v6ur 2037 reference: RFC XXXX 2038 ------------------------------------------------------------------- 2040 10. Security Considerations 2042 The YANG modules defined in this document are designed to be accessed 2043 via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 2044 secure transport layer and the mandatory-to-implement secure 2045 transport is SSH [RFC6242]. 2047 A number of data nodes defined in the YANG modules are writable/ 2048 creatable/deletable (i.e., "config true" in YANG terms, which is the 2049 default). These data nodes may be considered sensitive or vulnerable 2050 in some network environments. Write operations to these data nodes, 2051 such as "edit-config", can have negative effects on the network if 2052 the protocol operations are not properly protected. 2054 The vulnerable "config true" subtrees and data nodes are the 2055 following: 2057 /rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a 2058 network layer interface to a router instance and may also specify 2059 interface parameters related to routing. 2061 /rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This 2062 list specifies the routing protocols configured on a device. 2064 /rt:routing/rt:router/rt:route-filters/rt:route-filter This list 2065 specifies the configured route filters which represent the 2066 administrative policies for redistributing and modifying routing 2067 information. 2069 Unauthorized access to any of these lists can adversely affect the 2070 routing subsystem of both the local device and the network. This may 2071 lead to network malfunctions, delivery of packets to inappropriate 2072 destinations and other problems. 2074 11. Acknowledgments 2076 The author wishes to thank Martin Bjorklund, Joel Halpern, Thomas 2077 Morin, Tom Petch, Juergen Schoenwaelder, Dave Thaler and Yi Yang for 2078 their helpful comments and suggestions. 2080 12. References 2082 12.1. Normative References 2084 [IANA-IF-AF] 2085 Bjorklund, M., "IANA Interface Type and Address Family 2086 YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in 2087 progress), April 2012. 2089 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2090 Requirement Levels", BCP 14, RFC 2119, March 1997. 2092 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2093 January 2004. 2095 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2096 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2097 September 2007. 2099 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2100 Network Configuration Protocol (NETCONF)", RFC 6020, 2101 September 2010. 2103 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 2104 RFC 6021, September 2010. 2106 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2107 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2108 June 2011. 2110 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2111 Configuration", draft-ietf-netmod-interfaces-cfg-04 (work 2112 in progress), April 2012. 2114 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 2115 draft-ietf-netmod-ip-cfg-03 (work in progress), 2116 April 2012. 2118 12.2. Informative References 2120 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2121 Data Model Documents", RFC 6087, January 2011. 2123 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2124 Shell (SSH)", RFC 6242, June 2011. 2126 Appendix A. Example: Adding a New Routing Protocol 2128 This appendix demonstrates how the core routing data model can be 2129 extended to support a new routing protocol. The YANG module 2130 "example-rip" shown below is intended only as an illustration rather 2131 than a real definition of a data model for the RIP routing protocol. 2132 For the sake of brevity, we do not follow all the guidelines 2133 specified in [RFC6087]. See also Section 4.4.2. 2135 file "example-rip@2012-07-09.yang" 2137 module example-rip { 2139 namespace "http://example.com/rip"; 2141 prefix "rip"; 2143 import ietf-routing { 2144 prefix "rt"; 2145 } 2147 identity rip { 2148 base rt:routing-protocol; 2149 description 2150 "Identity for the RIP routing protocol."; 2151 } 2153 typedef rip-metric { 2154 type uint8 { 2155 range "0..16"; 2156 } 2157 } 2159 grouping route-content { 2160 description 2161 "RIP-specific route content."; 2162 leaf metric { 2163 type rip-metric; 2164 } 2165 leaf tag { 2166 type uint16; 2167 default "0"; 2168 description 2169 "This leaf may be used to carry additional info, e.g. AS 2170 number."; 2171 } 2172 } 2173 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 2174 + "rt:routes/rt:route" { 2175 when "../../../../rt:routing-protocols/" 2176 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 2177 + "rt:type='rip:rip'" { 2178 description 2179 "This augment is only valid if the source protocol from which 2180 the route originated is RIP."; 2181 } 2182 description 2183 "RIP-specific route components."; 2184 uses route-content; 2185 } 2187 augment "/rt:active-route/rt:output/rt:route" { 2188 description 2189 "Add RIP-specific route content."; 2190 uses route-content; 2191 } 2193 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 2194 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 2195 + "'rip:rip'"; 2196 container rip { 2197 description 2198 "Per-interface RIP configuration."; 2199 leaf enabled { 2200 type boolean; 2201 default "true"; 2202 } 2203 leaf metric { 2204 type rip-metric; 2205 default "1"; 2206 } 2207 } 2208 } 2210 augment "/rt:routing/rt:router/rt:routing-protocols/" 2211 + "rt:routing-protocol" { 2212 when "rt:type = 'rip:rip'"; 2213 container rip { 2214 leaf update-interval { 2215 type uint8 { 2216 range "10..60"; 2217 } 2218 units "seconds"; 2219 default "30"; 2220 description 2221 "Time interval between periodic updates."; 2222 } 2223 } 2224 } 2225 } 2227 2229 Appendix B. Example: Reply to the NETCONF Message 2231 This section contains a sample reply to the NETCONF message, 2232 which could be sent by a server supporting (i.e., advertising them in 2233 the NETCONF message) the following YANG modules: 2235 o ietf-interfaces [YANG-IF], 2237 o ietf-ip [YANG-IP], 2239 o ietf-routing (Section 6), 2241 o ietf-ipv4-unicast-routing (Section 7), 2243 o ietf-ipv6-unicast-routing (Section 8). 2245 We assume a simple network setup as shown in Figure 3: router "A" 2246 uses static default routes with the "ISP" router as the next hop. 2247 IPv6 router advertisements are configured only on the "eth1" 2248 interface and disabled on the upstream "eth0" interface. 2250 +-----------------+ 2251 | | 2252 | Router ISP | 2253 | | 2254 +--------+--------+ 2255 |2001:db8:0:1::2 2256 |192.0.2.2 2257 | 2258 | 2259 |2001:db8:0:1::1 2260 eth0|192.0.2.1 2261 +--------+--------+ 2262 | | 2263 | Router A | 2264 | | 2265 +--------+--------+ 2266 eth1|198.51.100.1 2267 |2001:db8:0:2::1 2268 | 2270 Figure 3: Example network configuration 2272 A reply to the NETCONF message sent by router "A" would then be 2273 as follows: 2275 2276 2284 2285 2286 2287 eth0 2288 ethernetCsmacd 2289 05:00.0 2290 2291 2292 192.0.2.1 2293 24 2294 2295 2296 2297 2298 2001:0db8:0:1::1 2299 64 2300 2301 2302 false 2303 2304 2305 2306 2307 eth1 2308 ethernetCsmacd 2309 05:00.1 2310 2311 2312 198.51.100.1 2313 24 2314 2315 2316 2317 2318 2001:0db8:0:2::1 2319 64 2320 2321 2322 false 2323 2324 2326 2327 2328 2329 2330 rtr0 2331 2332 2333 eth0 2334 2335 2336 eth1 2337 2338 true 2339 2340 2341 2001:db8:0:2::/64 2342 2343 2344 2345 2346 2347 2348 2349 direct 2350 rt:direct 2351 2352 2353 st0 2354 2355 Static routing is used for the internal network. 2356 2357 rt:static 2358 2359 2360 2361 1 2362 0.0.0.0/0 2363 192.0.2.2 2364 2365 2366 2367 2368 1 2369 ::/0 2370 2001:db8:0:1::2 2371 2372 2373 2374 2375 2376 main-ipv4-unicast 2377 2378 2379 main-ipv6-unicast 2380 2381 2382 2383 2384 2385 2386 main-ipv4-unicast 2387 2388 2389 192.0.2.1/24 2390 eth0 2391 direct 2392 3512 2393 2394 2395 198.51.100.0/24 2396 eth1 2397 direct 2398 3512 2399 2400 2401 0.0.0.0/0 2402 st0 2403 192.0.2.2 2404 2551 2405 2406 2407 2408 2409 main-ipv6-unicast 2410 ipv6 2411 nlri-unicast 2412 2413 2414 2001:db8:0:1::/64 2415 eth0 2416 direct 2417 3513 2418 2419 2420 2001:db8:0:2::/64 2421 eth1 2422 direct 2423 3513 2424 2425 2426 ::/0 2427 2001:db8:0:1::2 2428 st0 2429 2550 2430 2431 2432 2433 2434 2435 2436 2437 2439 Appendix C. Change Log 2441 RFC Editor: remove this section upon publication as an RFC. 2443 C.1. Changes Between Versions -03 and -04 2445 o Changed "error-tag" for both RPC methods from "missing element" to 2446 "data-missing". 2448 o Removed the decrementing behavior for advertised IPv6 prefix 2449 parameters "valid-lifetime" and "preferred-lifetime". 2451 o Changed the key of the static route lists from "seqno" to "id" 2452 because the routes needn't be sorted. 2454 o Added 'must' constraint saying that "preferred-lifetime" must not 2455 be greater than "valid-lifetime". 2457 C.2. Changes Between Versions -02 and -03 2459 o Module "iana-afn-safi" moved to I-D "iana-if-type". 2461 o Removed forwarding table. 2463 o RPC "get-route" changed to "active-route". Its output is a list 2464 of routes (for multi-path routing). 2466 o New RPC "route-count". 2468 o For both RPCs, specification of negative responses was added. 2470 o Relaxed separation of router instances. 2472 o Assignment of interfaces to router instances needn't be disjoint. 2474 o Route filters are now global. 2476 o Added "allow-all-route-filter" for symmetry. 2478 o Added Section 5 about interactions with "ietf-interfaces" and 2479 "ietf-ip". 2481 o Added "router-id" leaf. 2483 o Specified the names for IPv4/IPv6 unicast main routing tables. 2485 o Route parameter "last-modified" changed to "age". 2487 o Added container "recipient-routing-tables". 2489 C.3. Changes Between Versions -01 and -02 2491 o Added module "ietf-ipv6-unicast-routing". 2493 o The example in Appendix B now uses IP addresses from blocks 2494 reserved for documentation. 2496 o Direct routes appear by default in the FIB table. 2498 o Network layer interfaces must be assigned to a router instance. 2499 Additional interface configuration may be present. 2501 o The "when" statement is only used with "augment", "must" is used 2502 elsewhere. 2504 o Additional "must" statements were added. 2506 o The "route-content" grouping for IPv4 and IPv6 unicast now 2507 includes the material from the "ietf-routing" version via "uses 2508 rt:route-content". 2510 o Explanation of symbols in the tree representation of data model 2511 hierarchy. 2513 C.4. Changes Between Versions -00 and -01 2515 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2517 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2518 safi" module. 2520 o Names of some data nodes were changed, in particular "routing- 2521 process" is now "router". 2523 o The restriction of a single AFN/SAFI per router was lifted. 2525 o RPC operation "delete-route" was removed. 2527 o Illegal XPath references from "get-route" to the datastore were 2528 fixed. 2530 o Section "Security Considerations" was written. 2532 Author's Address 2534 Ladislav Lhotka 2535 CZ.NIC 2537 Email: lhotka@nic.cz