idnits 2.17.00 (12 Aug 2021) /tmp/idnits6422/draft-ietf-netmod-routing-cfg-03.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 (May 25, 2012) is 3648 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: draft-ietf-netmod-iana-if-type has been published as RFC 7224 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: draft-ietf-netmod-interfaces-cfg has been published as RFC 7223 == Outdated reference: draft-ietf-netmod-ip-cfg has been published as RFC 7277 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) 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 May 25, 2012 5 Expires: November 26, 2012 7 A YANG Data Model for Routing Configuration 8 draft-ietf-netmod-routing-cfg-03 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 this module 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 November 26, 2012. 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 -02 and -03 . . . . . . . . . . . 60 88 C.2. Changes Between Versions -01 and -02 . . . . . . . . . . . 60 89 C.3. Changes Between Versions -00 and -01 . . . . . . . . . . . 61 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 92 1. Introduction 94 This document contains a specification of the following YANG modules: 96 o Module "ietf-routing" provides generic components of a routing 97 data model. 99 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 100 module with additional data specific to IPv4 unicast. 102 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 103 module with additional data specific to IPv6 unicast, including 104 the router configuration variables required by [RFC4861]. 106 These modules together define the so-called core routing data model, 107 which is proposed as a basis for the development of data models for 108 more sophisticated routing configurations. While these three modules 109 can be directly used for simple IP devices with static routing, their 110 main purpose is to provide essential building blocks for more 111 complicated setups involving multiple routing protocols, multicast 112 routing, additional address families, advanced functions such as 113 route filtering or policy routing etc. To this end, it is expected 114 that the core routing data model will be augmented by numerous 115 modules developed by other IETF working groups. 117 2. Terminology and Notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 The following terms are defined in [RFC6241]: 125 o client 127 o message 129 o protocol operation 131 o server 133 The following terms are defined in [RFC6020]: 135 o augment 137 o configuration data 139 o container 141 o data model 143 o data node 145 o data type 147 o identity 149 o mandatory node 151 o module 153 o operational state data 155 o prefix 157 o RPC operation 159 2.1. Glossary of New Terms 160 active route: a route which is actually used for sending packets. 161 If there are multiple candidate routes with a matching destination 162 prefix, then it is up to the routing algorithm to select the 163 active route (or several active routes in the case of multi-path 164 routing). 166 core routing data model: YANG data model resulting from the 167 combination of "ietf-routing", "ietf-ipv4-unicast-routing" and 168 "ietf-ipv6-unicast-routing" modules. 170 direct route: a route to a directly connected network. 172 2.2. Prefixes in Data Node Names 174 In this document, names of data nodes are used mostly without a 175 prefix, as long as it is clear from the context in which YANG module 176 each name is defined. Otherwise, names are prefixed using the 177 standard prefix associated with the corresponding YANG module, as 178 shown in Table 1. 180 +--------+---------------------------+--------------+ 181 | Prefix | YANG module | Reference | 182 +--------+---------------------------+--------------+ 183 | ianaaf | iana-afn-safi | [IANA-IF-AF] | 184 | | | | 185 | if | ietf-interfaces | [YANG-IF] | 186 | | | | 187 | ip | ietf-ip | [YANG-IP] | 188 | | | | 189 | rip | example-rip | Appendix A | 190 | | | | 191 | rt | ietf-routing | Section 6 | 192 | | | | 193 | v4ur | ietf-ipv4-unicast-routing | Section 7 | 194 | | | | 195 | v6ur | ietf-ipv6-unicast-routing | Section 8 | 196 | | | | 197 | yang | ietf-yang-types | [RFC6021] | 198 | | | | 199 | inet | ietf-inet-types | [RFC6021] | 200 +--------+---------------------------+--------------+ 202 Table 1: Prefixes and corresponding YANG modules 204 3. Objectives 206 The initial design of the core routing data model was driven by the 207 following objectives: 209 o The data model should be suitable for the common address families, 210 in particular IPv4 and IPv6, and for unicast and multicast 211 routing, as well as Multiprotocol Label Switching (MPLS). 213 o Simple routing setups, such as static routing, should be 214 configurable in a simple way, ideally without any need to develop 215 additional YANG modules. 217 o On the other hand, the core routing framework must allow for 218 complicated setups involving multiple routing tables and multiple 219 routing protocols, as well as controlled redistributions of 220 routing information. 222 o Device vendors will want to map the data models built on this 223 generic framework to their proprietary data models and 224 configuration interfaces. Therefore, the framework should be 225 flexible enough to facilitate such a mapping and accommodate data 226 models with different logic. 228 4. The Design of the Core Routing Data Model 230 The core routing data model consists of three YANG modules. The 231 first module, "ietf-routing", defines the generic components of a 232 routing system. The other two modules, "ietf-ipv4-unicast-routing" 233 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 234 with additional data nodes that are needed for IPv4 and IPv6 unicast 235 routing, respectively. The combined data hierarchy is shown in 236 Figure 1, where brackets enclose list keys, "rw" means configuration, 237 "ro" operational state data, and "?" means optional node. 238 Parentheses enclose choice and case nodes, and case nodes are also 239 marked with a colon (":"). 241 +--rw routing 242 +--rw router [name] 243 | +--rw name 244 | +--rw router-id? 245 | +--rw description? 246 | +--rw enabled? 247 | +--rw interfaces 248 | | +--rw interface [name] 249 | | +--rw name 250 | | +--rw v6ur:ipv6-router-advertisements 251 | | +--rw v6ur:send-advertisements? 252 | | +--rw v6ur:max-rtr-adv-interval? 253 | | +--rw v6ur:min-rtr-adv-interval? 254 | | +--rw v6ur:managed-flag? 255 | | +--rw v6ur:other-config-flag? 256 | | +--rw v6ur:link-mtu? 257 | | +--rw v6ur:reachable-time? 258 | | +--rw v6ur:retrans-timer? 259 | | +--rw v6ur:cur-hop-limit? 260 | | +--rw v6ur:default-lifetime? 261 | | +--rw v6ur:prefix-list 262 | | +--rw v6ur:prefix [prefix-spec] 263 | | +--rw v6ur:prefix-spec 264 | | +--rw (control-adv-prefixes)? 265 | | +--:(no-advertise) 266 | | | +--rw v6ur:no-advertise? 267 | | +--:(advertise) 268 | | +--rw v6ur:valid-lifetime? 269 | | +--rw v6ur:on-link-flag? 270 | | +--rw v6ur:preferred-lifetime? 271 | | +--rw v6ur:autonomous-flag? 272 | +--rw routing-protocols 273 | | +--rw routing-protocol [name] 274 | | +--rw name 275 | | +--rw description? 276 | | +--rw type 277 | | +--rw connected-routing-tables 278 | | | +--rw routing-table [name] 279 | | | +--rw name 280 | | | +--rw import-filter? 281 | | | +--rw export-filter? 282 | | +--rw static-routes 283 | | +--rw v4ur:ipv4 284 | | | +--rw v4ur:route [seqno] 285 | | | +--rw v4ur:seqno 286 | | | +--rw v4ur:description? 287 | | | +--rw v4ur:outgoing-interface? 288 | | | +--rw v4ur:dest-prefix 289 | | | +--rw v4ur:next-hop? 290 | | +--rw v6ur:ipv6 291 | | +--rw v6ur:route [seqno] 292 | | +--rw v6ur:seqno 293 | | +--rw v6ur:description? 294 | | +--rw v6ur:outgoing-interface? 295 | | +--rw v6ur:dest-prefix 296 | | +--rw v6ur:next-hop? 297 | +--rw routing-tables 298 | +--rw routing-table [name] 299 | +--rw name 300 | +--rw address-family? 301 | +--rw safi? 302 | +--rw description? 303 | +--ro routes 304 | | +--ro route 305 | | +--ro source-protocol 306 | | +--ro age 307 | | +--ro v4ur:outgoing-interface? 308 | | +--ro v4ur:dest-prefix? 309 | | +--ro v4ur:next-hop? 310 | | +--ro v6ur:outgoing-interface? 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 Network layer interfaces must be assigned to a router instance in 383 order to be able to participate in packet forwarding, routing 384 protocols and other operations of that router instance. The 385 assignment is accomplished by creating a corresponding entry in the 386 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 NOTE: The "IsRouter" flag, which is also required by [RFC4861], is 440 implemented by the "ietf-ip" module [YANG-IP] (leaf "ip:ip- 441 forwarding"). 443 4.2. Route 445 Routes are basic units of information in a routing system. The core 446 routing data model defines only the following minimal set of route 447 attributes: 449 o "destination-prefix": IP prefix specifying the set of destination 450 addresses for which the route may be used. This attribute is 451 mandatory. 453 o "next-hop": IP address of the adjacent router or host to which 454 packets with destination addresses belonging to destination-prefix 455 should be sent. 457 o "outgoing-interface": network interface that should be used for 458 sending packets with destination addresses belonging to 459 destination-prefix. 461 The above list of route attributes should suffice for a simple static 462 routing configuration. It is expected that future modules defining 463 routing protocols will add other route attributes such as metrics or 464 preferences. 466 Routes and their attributes are used both in configuration data, for 467 example as manually configured static routes, and in operational 468 state data, for example as entries in routing tables. 470 4.3. Routing Tables 472 Routing tables are lists of routes complemented with administrative 473 data, namely: 475 o "source-protocol": name of the routing protocol from which the 476 route was originally obtained. 478 o "age": number of seconds since the route was created or last 479 updated. 481 Each routing table may only contain routes of the same address 482 family. Address family information consists of two parameters - 483 "address-family" and "safi" (Subsequent Address Family Identifier, 484 SAFI). The permitted values for these two parameters are defined by 485 IANA and translated into YANG enumeration types "ianaaf:address- 486 family" and "ianaaf:subsequent-address-family" [IANA-IF-AF]. 488 In the core routing data model, the "routing-table" node represents 489 configuration while the descendant list of routes is defined as 490 operational state data. The contents of route lists are controlled 491 and manipulated by routing protocol operations which may result in 492 route additions, removals and modifications. This also includes 493 manipulations via the "static" and/or "direct" pseudo-protocols, see 494 Section 4.4.1. 496 One routing table MUST be present for each router instance and each 497 address family supported by that router instance. It is the so- 498 called main routing table to which all routing protocol instances 499 supporting the given address family SHOULD be connected by default. 500 For the two address families that are part of the core routing data 501 model, the names of the main routing tables SHOULD be as follows: 503 o "main-ipv4-unicast" for IPv4 unicast, 505 o "main-ipv6-unicast" for IPv6 unicast. 507 Additional routing tables MAY be configured by creating new entries 508 in the "routing-table" list, either as a part of factory-default 509 configuration, or by a client's action. 511 The naming scheme for additional routing tables, as well as 512 restrictions on the number and configurability of routing tables are 513 implementation-specific. 515 The way how the routing system uses information from routing tables 516 is outside the scope of this document. Typically, implementations 517 will either use a forwarding table, or perform a direct look-up in 518 the main routing table in conjunction with a route cache. 520 Every routing table can serve as a source of routes for other routing 521 tables. To achieve this, one or more recipient routing tables may be 522 specified in the configuration of the source routing table. In 523 addition, a route filter may be configured for each recipient routing 524 table, which selects and/or manipulates the routes that are passed on 525 between the source and recipient routing table. 527 4.4. Routing Protocols 529 The core routing data model provides an open-ended framework for 530 defining multiple routing protocol instances. Each of them is 531 identified by a name, which MUST be unique within a router instance. 532 Each protocol MUST be assigned a type, which MUST be an identity 533 derived from the "rt:routing-protocol" base identity. The core 534 routing data model defines two identities for the direct and static 535 pseudo-protocols (Section 4.4.1). 537 Each routing protocol instance is connected to exactly one routing 538 table for each address family that the routing protocol instance 539 supports. By default, every routing protocol instance SHOULD be 540 connected to the main routing table or tables. An implementation MAY 541 allow any or all routing protocol instances to be configured to use a 542 different routing table. 544 Routes learned from the network by a routing protocol are passed to 545 the connected routing table(s) and vice versa - routes appearing in a 546 routing table are passed to all routing protocols connected to the 547 table (except "direct" and "static" pseudo-protocols) and may be 548 advertised by that protocol to the network. 550 Two independent route filters (see Section 4.5) may be defined for a 551 routing protocol instance to control the exchange of routes in both 552 directions between the routing protocol instance and the connected 553 routing table: 555 o import filter controls which routes are passed from a routing 556 protocol instance to the routing table, 558 o export filter controls which routes the routing protocol instance 559 may receive from the connected routing table. 561 Note that, for historical reasons, the terms import and export are 562 used from the viewpoint of a routing table. 564 4.4.1. Routing Pseudo-Protocols 566 The core routing data model defines two special routing protocol 567 types - "direct" and "static". Both are in fact pseudo-protocols, 568 which means that they are confined to the local device and do not 569 exchange any routing information with neighboring routers. Routes 570 from both "direct" and "static" protocol instances are passed to the 571 connected routing table (subject to route filters, if any), but an 572 exchange in the opposite direction is not allowed. 574 Every router instance MUST contain exactly one instance of the 575 "direct" pseudo-protocol type. The name of this instance MUST also 576 be "direct". It is the source of direct routes for all configured 577 address families. Direct routes are normally supplied by the 578 operating system kernel, based on the configuration of network 579 interface addresses, see Section 5.2. Direct routes SHOULD by 580 default appear in the main routing table for each configured address 581 family. However, using the framework defined in this document, the 582 target routing table for direct routes MAY be changed by connecting 583 the "direct" protocol instance to a non-default routing table. 584 Direct routes can also be filtered before they appear in the routing 585 table. 587 A pseudo-protocol of the type "static" allows for specifying routes 588 manually. It MAY be configured in zero or multiple instances, 589 although a typical implementation will have exactly one instance per 590 logical router. 592 4.4.2. Defining New Routing Protocols 594 It is expected that future YANG modules will create data models for 595 additional routing protocol types. Such a new module has to define 596 the protocol-specific configuration and operational state data, and 597 fit it into the core routing framework in the following way : 599 o A new identity MUST be defined for the routing protocol and its 600 base identity MUST be set to "rt:routing-protocol", or to an 601 identity derived from "rt:routing-protocol". 603 o Additional route attributes MAY be defined, preferably in one 604 place by means of defining a YANG grouping. The new attributes 605 have to be inserted as operational state data by augmenting the 606 definition of "rt:route" inside "rt:routing-table", and possibly 607 to other places in the configuration, operational state data and 608 RPC input or output. 610 o Per-interface configuration parameters can be added by augmenting 611 the data node "rt:interface" (the list of router interfaces). 613 o Other configuration parameters and operational state data can be 614 defined by augmenting the "routing-protocol" data node. By using 615 the "when" statement, this augment SHOULD be made conditional and 616 valid only if the value of the "rt:type" child leaf equals to the 617 new protocol's identity. 619 It is RECOMMENDED that both per-interface and other configuration 620 data specific to the new protocol be encapsulated in an appropriately 621 named container. 623 The above steps are implemented by the example YANG module for the 624 RIP routing protocol in Appendix A. First, the module defines a new 625 identity for the RIP protocol: 627 identity rip { 628 base rt:routing-protocol; 629 description "Identity for the RIP routing protocol."; 630 } 632 New route attributes specific to the RIP protocol ("metric" and 633 "tag") are defined in a grouping and then added to the route 634 definitions appearing in "routing-table" and in the output part of 635 the "active-route" RPC method: 637 grouping route-content { 638 description 639 "RIP-specific route content."; 640 leaf metric { 641 type rip-metric; 642 } 643 leaf tag { 644 type uint16; 645 default "0"; 646 description 647 "This leaf may be used to carry additional info, e.g. AS 648 number."; 649 } 650 } 652 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 653 + "rt:routes/rt:route" { 654 when "../../../../rt:routing-protocols/" 655 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 656 + "rt:type='rip:rip'" { 657 description 658 "This augment is only valid if the source protocol from which 659 the route originated is RIP."; 660 } 661 description 662 "RIP-specific route components."; 663 uses route-content; 664 } 666 augment "/rt:active-route/rt:output/rt:route" { 667 description 668 "Add RIP-specific route content."; 669 uses route-content; 670 } 672 Per-interface configuration data are defined by the following 673 "augment" statement: 675 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 676 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 677 + "'rip:rip'"; 678 container rip { 679 description 680 "Per-interface RIP configuration."; 681 leaf enabled { 682 type boolean; 683 default "true"; 684 } 685 leaf metric { 686 type rip-metric; 687 default "1"; 688 } 689 } 690 } 692 Finally, global RIP configuration data are integrated into the "rt: 693 routing-protocol" node by using the following "augment" statement, 694 which is valid only for routing protocol instances whose type is 695 "rip:rip": 697 augment "/rt:routing/rt:router/rt:routing-protocols/" 698 + "rt:routing-protocol" { 699 when "rt:type = 'rip:rip'"; 700 container rip { 701 leaf update-interval { 702 type uint8 { 703 range "10..60"; 704 } 705 units "seconds"; 706 default "30"; 707 description 708 "Time interval between periodic updates."; 709 } 710 } 711 } 713 4.5. Route Filters 715 The core routing data model provides a skeleton for defining route 716 filters that can be used to restrict the set of routes being 717 exchanged between a routing protocol instance and a connected routing 718 table, or between a source and a recipient routing table. Route 719 filters may also manipulate routes, i.e., add, delete, or modify 720 their attributes. 722 Route filters are global, which means that a configured route filter 723 may be used by any or all router instances. 725 By itself, the route filtering framework defined in this document 726 allows for applying only the extreme routing policies which are 727 represented by the following pre-defined route filter types: 729 o "deny-all-route-filter": all routes are blocked, 731 o "allow-all-route-filter": all routes are permitted. 733 It is expected that real route filtering frameworks will be developed 734 separately. 736 Each route filter is identified by a name which MUST be unique within 737 a router instance. Its type MUST be specified by the "type" identity 738 reference - this opens the space for multiple route filtering 739 framework implementations. The default value for the route filter 740 type is the identity "deny-all-route-filter". 742 4.6. RPC Operations 744 The "ietf-routing" module defines two RPC operations: 746 o active-route, 748 o route-count. 750 Their parameters and semantics are described in the following 751 subsections. 753 4.6.1. Operation "active-route" 755 Description: Retrieve one or more active routes from the forwarding 756 information base (FIB) of a router instance, i.e., the route(s) 757 that are currently used by that router instance for sending 758 datagrams to the destination whose address is provided as an input 759 parameter. 761 Parameters: 763 router-name: Name of the router instance whose FIB is to be 764 queried. 766 destination-address: Network layer destination address for which 767 the active routes are requested. 769 Positive Response: One or more "route" elements containing the 770 active route(s). 772 Negative Response: 774 If the logical router is not found, the server sends an "rpc- 775 error" message with "error-tag" set to "missing-element", and 776 "error-app-tag" set to "router-not-found". 778 If no route exists for the given destination address, the server 779 sends an "rpc-error" message with "error-tag" set to "data- 780 missing" and "error-app-tag" set to "no-route". 782 4.6.2. Operation "route-count" 784 Description: Retrieve the total number of routes in a routing table. 786 Parameters: 788 router-name: Name of the logical router containing the routing 789 table. 791 routing-table: Name of the routing table. 793 Positive Response: Element "number-of-routes" containing the 794 requested nonnegative number. 796 Negative Response: If the logical router or the routing table is not 797 found, the server sends an "rpc-error" message with "error-tag" 798 set to "missing-element", and "error-app-tag" set to "router-not- 799 found" or "routing-table-not-found", respectively. 801 5. Interactions with Other YANG Modules 803 The semantics of the core routing data model also depends on several 804 configuration parameters that are defined in other YANG modules. The 805 following subsections describe these interactions. 807 5.1. Module "ietf-interfaces" 809 The following boolean switch is defined in the "ietf-interfaces" YANG 810 module [YANG-IF]: 812 /if:interfaces/if:interface/if:enabled 814 If this switch is set to "false" for a given network layer 815 interface, the device MUST behave exactly as if that interface was 816 not assigned to any logical router at all. 818 5.2. Module "ietf-ip" 820 The following boolean switches are defined in the "ietf-ip" YANG 821 module [YANG-IP]: 823 /if:interfaces/if:interface/ip:ipv4/ip:enabled 825 If this switch is set to "false" for a given interface, then all 826 IPv4 routing functions related to that interface MUST be disabled. 828 /if:interfaces/if:interface/ip:ipv4/ip:ip-forwarding 830 If this switch is set to "false" for a given interface, then the 831 forwarding of IPv4 datagrams to and from this interface MUST be 832 disabled. However, the interface may participate in other routing 833 functions, such as routing protocols. 835 /if:interfaces/if:interface/ip:ipv6/ip:enabled 837 If this switch is set to "false" for a given interface, then all 838 IPv6 routing functions related to that interface MUST be disabled. 840 /if:interfaces/if:interface/ip:ipv6/ip:ip-forwarding 842 If this switch is set to "false" for a given interface, then the 843 forwarding of IPv6 datagrams to and from this interface MUST be 844 disabled. However, the interface may participate in other routing 845 functions, such as routing protocols. 847 In addition, the "ietf-ip" module allows for configuring IPv4 and 848 IPv6 addresses and subnet masks. Configuration of these parameters 849 on an enabled interface MUST result in an immediate creation of the 850 corresponding direct route (usually in the main routing table). Its 851 destination prefix is set according to the configured IP address and 852 subnet mask, and the interface is set as the outgoing interface for 853 that route. 855 6. Routing YANG Module 857 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 858 actual RFC number and all occurrences of the revision date below with 859 the date of RFC publication (and remove this note). 861 file "ietf-routing@2012-05-24.yang" 863 module ietf-routing { 865 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 867 prefix "rt"; 869 import ietf-inet-types { 870 prefix "inet"; 871 } 873 import ietf-interfaces { 874 prefix "if"; 875 } 877 import iana-afn-safi { 878 prefix "ianaaf"; 879 } 881 organization 882 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 884 contact 885 "WG Web: 886 WG List: 888 WG Chair: David Kessens 889 891 WG Chair: Juergen Schoenwaelder 892 894 Editor: Ladislav Lhotka 895 896 "; 898 description 899 "This YANG module defines essential components that may be used 900 for configuring a routing subsystem. 902 Copyright (c) 2012 IETF Trust and the persons identified as 903 authors of the code. All rights reserved. 905 Redistribution and use in source and binary forms, with or 906 without modification, is permitted pursuant to, and subject to 907 the license terms contained in, the Simplified BSD License set 908 forth in Section 4.c of the IETF Trust's Legal Provisions 909 Relating to IETF Documents 910 (http://trustee.ietf.org/license-info). 912 This version of this YANG module is part of RFC XXXX; see the 913 RFC itself for full legal notices. 914 "; 916 revision 2012-05-24 { 917 description 918 "Initial revision."; 919 reference 920 "RFC XXXX: A YANG Data Model for Routing Configuration"; 921 } 923 /* Identities */ 925 identity routing-protocol { 926 description 927 "Base identity from which routing protocol identities are 928 derived."; 929 } 931 identity direct { 932 base routing-protocol; 933 description 934 "Routing pseudo-protocol which provides routes to directly 935 connected networks."; 936 } 938 identity static { 939 base routing-protocol; 940 description 941 "Static routing pseudo-protocol."; 942 } 944 identity route-filter { 945 description 946 "Base identity from which all route filters are derived."; 947 } 949 identity deny-all-route-filter { 950 base route-filter; 951 description 952 "Route filter that blocks all routes."; 953 } 955 identity allow-all-route-filter { 956 base route-filter; 957 description 958 "Route filter that permits all routes. 960 Note that use of this filter is equivalent to no filter at 961 all. 962 "; 963 } 965 /* Type Definitions */ 967 typedef router-ref { 968 type leafref { 969 path "/rt:routing/rt:router/rt:name"; 970 } 971 description 972 "This type is used for leafs that reference a router 973 instance."; 974 } 976 /* Groupings */ 978 grouping afn-safi { 979 leaf address-family { 980 type ianaaf:address-family; 981 default "ipv4"; 982 description 983 "Address family of routes in the routing table."; 984 } 985 leaf safi { 986 type ianaaf:subsequent-address-family; 987 default "nlri-unicast"; 988 description 989 "Subsequent address family identifier of routes in the 990 routing table."; 991 } 992 description 993 "This grouping provides two parameters specifying address 994 family and subsequent address family."; 995 } 997 grouping route-content { 998 description 999 "Generic parameters of routes. 1001 A module for an address family should define a specific 1002 version of this grouping containing 'uses rt:route-content'. 1003 "; 1004 leaf outgoing-interface { 1005 type if:interface-ref; 1006 description 1007 "Outgoing interface."; 1008 } 1009 } 1011 /* RPC Methods */ 1013 rpc active-route { 1014 description 1015 "Return the active route (or multiple routes, in the case of 1016 multi-path routing) to a destination address. 1018 Parameters 1020 1. 'router-name', 1022 2. 'destination-address'. 1024 If the logical router with 'router-name' doesn't exist, then 1025 this operation will fail with error-tag 'missing-element' and 1026 error-app-tag 'router-not-found'. 1028 If there is no active route for 'destination-address', then 1029 this operation will fail with error-tag 'data-missing' and 1030 error-app-tag 'no-route'. 1031 "; 1032 input { 1033 leaf router-name { 1034 type router-ref; 1035 mandatory "true"; 1036 description 1037 "Name of the router instance whose forwarding information 1038 base is being queried."; 1039 } 1040 container destination-address { 1041 uses afn-safi; 1042 description 1043 "Network layer destination address. 1045 AFN/SAFI-specific modules must augment this container with 1046 a leaf named 'address'. 1048 "; 1049 } 1050 } 1051 output { 1052 list route { 1053 min-elements "1"; 1054 uses afn-safi; 1055 uses route-content; 1056 description 1057 "Route contents specific for each address family should be 1058 defined through augmenting."; 1059 } 1060 } 1061 } 1063 rpc route-count { 1064 description 1065 "Return the current number of routes in a routing table. 1067 Parameters: 1069 1. 'router-name', 1071 2. 'routing-table-name'. 1073 If the logical router with 'router-name' doesn't exist, then 1074 this operation will fail with error-tag 'missing-element' and 1075 error-app-tag 'router-not-found'. 1077 If the routing table with 'routing-table-name' doesn't exist, 1078 then this operation will fail with error-tag 'missing-element' 1079 and error-app-tag 'routing-table-not-found'. 1080 "; 1081 input { 1082 leaf router-name { 1083 type router-ref; 1084 mandatory "true"; 1085 description 1086 "Name of the router instance containing the routing 1087 table."; 1088 } 1089 leaf routing-table { 1090 type leafref { 1091 path "/routing/router/routing-tables/routing-table/name"; 1092 } 1093 mandatory "true"; 1094 description 1095 "Name of the routing table."; 1097 } 1098 } 1099 output { 1100 leaf number-of-routes { 1101 type uint32; 1102 mandatory "true"; 1103 description 1104 "Number of routes in the routing table."; 1105 } 1106 } 1107 } 1109 /* Data Nodes */ 1111 container routing { 1112 description 1113 "Routing parameters."; 1114 list router { 1115 key "name"; 1116 unique "router-id"; 1117 description 1118 'Each list entry is a container for configuration and 1119 operational state data of a single (logical) router. 1121 Network layer interfaces assigned to the router must have 1122 their entries in the "interfaces" list. 1123 '; 1124 leaf name { 1125 type string; 1126 description 1127 "The unique router name."; 1128 } 1129 leaf router-id { 1130 type inet:ipv4-address; 1131 description 1132 "Global router ID in the form of an IPv4 address. 1134 An implementation may select a value if this parameter is 1135 not configured. 1137 Routing protocols may override this global parameter 1138 inside their configuration. 1139 "; 1140 } 1141 leaf description { 1142 type string; 1143 description 1144 "Textual description of the router."; 1146 } 1147 leaf enabled { 1148 type boolean; 1149 default "true"; 1150 description 1151 "Enable the router. The default value is 'true'. 1153 If this parameter is false, the parent router instance is 1154 disabled, despite any other configuration that might be 1155 present. 1156 "; 1157 } 1158 container interfaces { 1159 description 1160 "Router interface parameters."; 1161 list interface { 1162 key "name"; 1163 description 1164 "List of network layer interfaces assigned to the router 1165 instance."; 1166 leaf name { 1167 type if:interface-ref; 1168 description 1169 "A reference to the name of a configured network layer 1170 interface."; 1171 } 1172 } 1173 } 1174 container routing-protocols { 1175 description 1176 "Container for the list of configured routing protocol 1177 instances."; 1178 list routing-protocol { 1179 key "name"; 1180 description 1181 "An instance of a routing protocol."; 1182 leaf name { 1183 type string; 1184 description 1185 "The name of the routing protocol instance."; 1186 } 1187 leaf description { 1188 type string; 1189 description 1190 "Textual description of the routing protocol 1191 instance."; 1192 } 1193 leaf type { 1194 type identityref { 1195 base routing-protocol; 1196 } 1197 mandatory "true"; 1198 description 1199 "Type of the routing protocol - an identity derived 1200 from the 'routing-protocol' base identity."; 1201 } 1202 container connected-routing-tables { 1203 description 1204 "Container for connected routing tables."; 1205 list routing-table { 1206 must "not(../../../../routing-tables/" 1207 + "routing-table[rt:name=current()/" 1208 + "preceding-sibling::routing-table/name]/" 1209 + "address-family=../../../../routing-tables/" 1210 + "routing-table[rt:name=current()/name]/" 1211 + "address-family and ../../../../routing-tables/" 1212 + "routing-table[rt:name=current()/" 1213 + "preceding-sibling::routing-table/name]/safi=../" 1214 + "../../../routing-tables/" 1215 + "routing-table[rt:name=current()/name]/safi)" { 1216 error-message "Each routing protocol may have no " 1217 + "more than one connected routing " 1218 + "table for each AFN and SAFI."; 1219 description 1220 "For each AFN/SAFI pair there may be at most one 1221 connected routing table."; 1222 } 1223 key "name"; 1224 description 1225 "List of routing tables to which the routing protocol 1226 instance is connected. 1228 If no connected routing table is defined for an 1229 address family, the routing protocol should be 1230 connected by default to the main routing table for 1231 that address family. 1232 "; 1233 leaf name { 1234 type leafref { 1235 path "../../../../../routing-tables/routing-table/" 1236 + "name"; 1237 } 1238 description 1239 "Reference to an existing routing table."; 1240 } 1241 leaf import-filter { 1242 type leafref { 1243 path "/routing/route-filters/route-filter/name"; 1244 } 1245 description 1246 "Reference to a route filter that is used for 1247 filtering routes passed from this routing protocol 1248 instance to the routing table specified by the 1249 'name' sibling node. If this leaf is not present, 1250 the behavior is protocol-specific, but typically 1251 it means that all routes are accepted."; 1252 } 1253 leaf export-filter { 1254 type leafref { 1255 path "/routing/route-filters/route-filter/name"; 1256 } 1257 description 1258 "Reference to a route filter that is used for 1259 filtering routes passed from the routing table 1260 specified by the 'name' sibling node to this 1261 routing protocol instance. If this leaf is not 1262 present, the behavior is protocol-specific - 1263 typically it means that all routes are accepted, 1264 except for the 'direct' and 'static' 1265 pseudo-protocols which accept no routes from any 1266 routing table."; 1267 } 1268 } 1269 } 1270 container static-routes { 1271 must "../type='rt:static'" { 1272 error-message "Static routes may be configured only " 1273 + "for 'static' routing protocol."; 1274 description 1275 "This container is only valid for the 'static' 1276 routing protocol."; 1277 } 1278 description 1279 "Configuration of 'static' pseudo-protocol."; 1280 } 1281 } 1282 } 1283 container routing-tables { 1284 description 1285 "Container for configured routing tables."; 1286 list routing-table { 1287 key "name"; 1288 description 1289 "Each entry represents a routing table identified by the 1290 'name' key. All routes in a routing table must have the 1291 same AFN and SAFI."; 1292 leaf name { 1293 type string; 1294 description 1295 "The name of the routing table."; 1296 } 1297 uses afn-safi; 1298 leaf description { 1299 type string; 1300 description 1301 "Textual description of the routing table."; 1302 } 1303 container routes { 1304 config "false"; 1305 description 1306 "Current contents of the routing table (operational 1307 state data)."; 1308 list route { 1309 description 1310 "A routing table entry. This data node must augmented 1311 with information specific for routes of each address 1312 family."; 1313 uses route-content; 1314 leaf source-protocol { 1315 type leafref { 1316 path "/routing/router/routing-protocols/" 1317 + "routing-protocol/name"; 1318 } 1319 mandatory "true"; 1320 description 1321 "The name of the routing protocol instance from 1322 which the route comes. This routing protocol must 1323 be configured (automatically or manually) in the 1324 device."; 1325 } 1326 leaf age { 1327 type uint32; 1328 units "seconds"; 1329 mandatory "true"; 1330 description 1331 "The number of seconds since the parent route was 1332 created or last updated."; 1333 } 1334 } 1335 } 1336 container recipient-routing-tables { 1337 description 1338 "Container for recipient routing tables."; 1339 list recipient-routing-table { 1340 key "name"; 1341 description 1342 "A list of routing tables that receive routes from 1343 this routing table."; 1344 leaf name { 1345 type leafref { 1346 path "/routing/router/routing-tables/" 1347 + "routing-table/name"; 1348 } 1349 description 1350 "The name of the recipient routing table."; 1351 } 1352 leaf filter { 1353 type leafref { 1354 path "/routing/route-filters/route-filter/name"; 1355 } 1356 description 1357 "A route filter which is applied to the routes 1358 passed on to the recipient routing table."; 1359 } 1360 } 1361 } 1362 } 1363 } 1364 } 1365 container route-filters { 1366 description 1367 "Container for configured route filters."; 1368 list route-filter { 1369 key "name"; 1370 description 1371 "Route filters are used for filtering and/or manipulating 1372 routes that are passed between a routing protocol and a 1373 routing table or vice versa, or between two routing 1374 tables. It is expected that other modules augment this 1375 list with contents specific for a particular route filter 1376 type."; 1377 leaf name { 1378 type string; 1379 description 1380 "The name of the route filter."; 1381 } 1382 leaf description { 1383 type string; 1384 description 1385 "Textual description of the route filter."; 1387 } 1388 leaf type { 1389 type identityref { 1390 base route-filter; 1391 } 1392 default "rt:deny-all-route-filter"; 1393 description 1394 "Type of the route-filter - an identity derived from the 1395 'route-filter' base identity. The default value 1396 represents an all-blocking filter."; 1397 } 1398 } 1399 } 1400 } 1401 } 1403 1405 7. IPv4 Unicast Routing YANG Module 1407 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1408 actual RFC number and all occurrences of the revision date below with 1409 the date of RFC publication (and remove this note). 1411 file "ietf-ipv4-unicast-routing@2012-05-25.yang" 1413 module ietf-ipv4-unicast-routing { 1415 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1417 prefix "v4ur"; 1419 import ietf-routing { 1420 prefix "rt"; 1421 } 1423 import ietf-inet-types { 1424 prefix "inet"; 1425 } 1427 organization 1428 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1430 contact 1431 "WG Web: 1432 WG List: 1434 WG Chair: David Kessens 1435 1437 WG Chair: Juergen Schoenwaelder 1438 1440 Editor: Ladislav Lhotka 1441 1442 "; 1444 description 1445 "This YANG module augments the 'ietf-routing' module with basic 1446 configuration and operational state data for IPv4 unicast 1447 routing. 1449 Every implementation must preconfigure a routing table with the 1450 name 'main-ipv4-unicast', which is the main routing table for 1451 IPv4 unicast. 1453 Copyright (c) 2012 IETF Trust and the persons identified as 1454 authors of the code. All rights reserved. 1456 Redistribution and use in source and binary forms, with or 1457 without modification, is permitted pursuant to, and subject to 1458 the license terms contained in, the Simplified BSD License set 1459 forth in Section 4.c of the IETF Trust's Legal Provisions 1460 Relating to IETF Documents 1461 (http://trustee.ietf.org/license-info). 1463 This version of this YANG module is part of RFC XXXX; see the 1464 RFC itself for full legal notices. 1465 "; 1467 revision 2012-05-24 { 1468 description 1469 "Initial revision."; 1470 reference 1471 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1472 } 1474 /* Groupings */ 1476 grouping route-content { 1477 description 1478 "Parameters of IPv4 unicast routes."; 1479 leaf dest-prefix { 1480 type inet:ipv4-prefix; 1481 description 1482 "IPv4 destination prefix."; 1483 } 1484 leaf next-hop { 1485 type inet:ipv4-address; 1486 description 1487 "IPv4 address of the next hop."; 1488 } 1489 } 1491 /* RPC Methods */ 1493 augment "/rt:active-route/rt:input/rt:destination-address" { 1494 when "address-family='ipv4' and safi='nlri-unicast'" { 1495 description 1496 "This augment is valid only for IPv4 unicast."; 1497 } 1498 description 1499 "The 'address' leaf augments the 'rt:destination-address' 1500 parameter of the 'rt:active-route' operation."; 1502 leaf address { 1503 type inet:ipv4-address; 1504 description 1505 "IPv4 destination address."; 1506 } 1507 } 1509 augment "/rt:active-route/rt:output/rt:route" { 1510 when "address-family='ipv4' and safi='nlri-unicast'" { 1511 description 1512 "This augment is valid only for IPv4 unicast."; 1513 } 1514 description 1515 "Contents of the reply to 'rt:active-route' operation."; 1516 uses route-content; 1517 } 1519 /* Data nodes */ 1521 augment "/rt:routing/rt:router/rt:routing-protocols/" 1522 + "rt:routing-protocol/rt:static-routes" { 1523 description 1524 "This augment defines the configuration of the 'static' 1525 pseudo-protocol with data specific for IPv4 unicast."; 1526 container ipv4 { 1527 description 1528 "Configuration of a 'static' pseudo-protocol instance 1529 consists of a list of routes."; 1530 list route { 1531 key "seqno"; 1532 ordered-by "user"; 1533 description 1534 "A user-ordered list of static routes."; 1535 leaf seqno { 1536 type uint32 { 1537 range "1..max"; 1538 } 1539 description 1540 "Sequential number of the route."; 1541 } 1542 leaf description { 1543 type string; 1544 description 1545 "Textual description of the route."; 1546 } 1547 uses rt:route-content; 1548 uses route-content { 1549 refine "dest-prefix" { 1550 mandatory "true"; 1551 } 1552 } 1553 } 1554 } 1555 } 1557 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 1558 + "rt:routes/rt:route" { 1559 when "../../rt:address-family='ipv4' and " 1560 + "../../rt:safi='nlri-unicast'" { 1561 description 1562 "This augment is valid only for IPv4 unicast."; 1563 } 1564 description 1565 "This augment defines the content of IPv4 unicast routes."; 1566 uses route-content; 1567 } 1568 } 1570 1572 8. IPv6 Unicast Routing YANG Module 1574 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1575 actual RFC number and all occurrences of the revision date below with 1576 the date of RFC publication (and remove this note). 1578 file "ietf-ipv6-unicast-routing@2012-05-24.yang" 1580 module ietf-ipv6-unicast-routing { 1582 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1584 prefix "v6ur"; 1586 import ietf-routing { 1587 prefix "rt"; 1588 } 1590 import ietf-inet-types { 1591 prefix "inet"; 1592 } 1594 import ietf-interfaces { 1595 prefix "if"; 1596 } 1598 import ietf-ip { 1599 prefix "ip"; 1600 } 1602 organization 1603 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1605 contact 1606 "WG Web: 1607 WG List: 1609 WG Chair: David Kessens 1610 1612 WG Chair: Juergen Schoenwaelder 1613 1615 Editor: Ladislav Lhotka 1616 1617 "; 1619 description 1620 "This YANG module augments the 'ietf-routing' module with basic 1621 configuration and operational state data for IPv6 unicast 1622 routing. 1624 Every implementation must preconfigure a routing table with the 1625 name 'main-ipv6-unicast', which is the main routing table for 1626 IPv6 unicast. 1628 Copyright (c) 2012 IETF Trust and the persons identified as 1629 authors of the code. All rights reserved. 1631 Redistribution and use in source and binary forms, with or 1632 without modification, is permitted pursuant to, and subject to 1633 the license terms contained in, the Simplified BSD License set 1634 forth in Section 4.c of the IETF Trust's Legal Provisions 1635 Relating to IETF Documents 1636 (http://trustee.ietf.org/license-info). 1638 This version of this YANG module is part of RFC XXXX; see the 1639 RFC itself for full legal notices. 1640 "; 1642 revision 2012-05-24 { 1643 description 1644 "Initial revision."; 1645 reference 1646 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1647 } 1649 /* Groupings */ 1651 grouping route-content { 1652 description 1653 "Specific parameters of IPv6 unicast routes."; 1654 leaf dest-prefix { 1655 type inet:ipv6-prefix; 1656 description 1657 "IPv6 destination prefix."; 1658 } 1659 leaf next-hop { 1660 type inet:ipv6-address; 1661 description 1662 "IPv6 address of the next hop."; 1663 } 1664 } 1666 /* RPC Methods */ 1667 augment "/rt:active-route/rt:input/rt:destination-address" { 1668 when "address-family='ipv6' and safi='nlri-unicast'" { 1669 description 1670 "This augment is valid only for IPv6 unicast."; 1671 } 1672 description 1673 "The 'address' leaf augments the 'rt:destination-address' 1674 parameter of the 'rt:active-route' operation."; 1675 leaf address { 1676 type inet:ipv6-address; 1677 description 1678 "IPv6 destination address."; 1679 } 1680 } 1682 augment "/rt:active-route/rt:output/rt:route" { 1683 when "address-family='ipv6' and safi='nlri-unicast'" { 1684 description 1685 "This augment is valid only for IPv6 unicast."; 1686 } 1687 description 1688 "Contents of the reply to 'rt:active-route' operation."; 1689 uses route-content; 1690 } 1692 /* Data nodes */ 1694 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 1695 when "/if:interfaces/if:interface[name=current()/name] " 1696 + "/ip:ipv6/ip:enabled='true'" { 1697 description 1698 "This augment is only valid for router interfaces with 1699 enabled IPv6. 1701 NOTE: Parameter 'is-router' is not included, it is expected 1702 that it will be implemented by the 'ietf-ip' module. 1703 "; 1704 } 1705 description 1706 "IPv6-specific parameters of router interfaces."; 1707 container ipv6-router-advertisements { 1708 description 1709 "Parameters of IPv6 Router Advertisements."; 1710 reference 1711 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6). 1713 RFC 4862: IPv6 Stateless Address Autoconfiguration. 1714 "; 1716 leaf send-advertisements { 1717 type boolean; 1718 default "false"; 1719 description 1720 "A flag indicating whether or not the router sends periodic 1721 Router Advertisements and responds to Router 1722 Solicitations."; 1723 } 1724 leaf max-rtr-adv-interval { 1725 type uint16 { 1726 range "4..1800"; 1727 } 1728 units "seconds"; 1729 default "600"; 1730 description 1731 "The maximum time allowed between sending unsolicited 1732 multicast Router Advertisements from the interface."; 1733 } 1734 leaf min-rtr-adv-interval { 1735 type uint16 { 1736 range "3..1350"; 1737 } 1738 units "seconds"; 1739 description 1740 "The minimum time allowed between sending unsolicited 1741 multicast Router Advertisements from the interface. 1743 Must be no greater than 0.75 * max-rtr-adv-interval. 1745 Its default value is dynamic: 1747 - if max-rtr-adv-interval >= 9 seconds, the default value 1748 is 0.33 * max-rtr-adv-interval; 1750 - otherwise it is 0.75 * max-rtr-adv-interval. 1751 "; 1752 } 1753 leaf managed-flag { 1754 type boolean; 1755 default "false"; 1756 description 1757 "The boolean value to be placed in the 'Managed address 1758 configuration' flag field in the Router Advertisement."; 1759 } 1760 leaf other-config-flag { 1761 type boolean; 1762 default "false"; 1763 description 1764 "The boolean value to be placed in the 'Other 1765 configuration' flag field in the Router Advertisement."; 1766 } 1767 leaf link-mtu { 1768 type uint32; 1769 default "0"; 1770 description 1771 "The value to be placed in MTU options sent by the router. 1772 A value of zero indicates that no MTU options are sent."; 1773 } 1774 leaf reachable-time { 1775 type uint32 { 1776 range "0..3600000"; 1777 } 1778 units "milliseconds"; 1779 default "0"; 1780 description 1781 "The value to be placed in the Reachable Time field in the 1782 Router Advertisement messages sent by the router. The 1783 value zero means unspecified (by this router)."; 1784 } 1785 leaf retrans-timer { 1786 type uint32; 1787 units "milliseconds"; 1788 default "0"; 1789 description 1790 "The value to be placed in the Retrans Timer field in the 1791 Router Advertisement messages sent by the router. The 1792 value zero means unspecified (by this router)."; 1793 } 1794 leaf cur-hop-limit { 1795 type uint8; 1796 default "64"; 1797 description 1798 "The default value to be placed in the Cur Hop Limit field 1799 in the Router Advertisement messages sent by the router. 1800 The value should be set to the current diameter of the 1801 Internet. The value zero means unspecified (by this 1802 router). 1804 The default should be set to the value specified in IANA 1805 Assigned Numbers that was in effect at the time of 1806 implementation. 1807 "; 1808 reference 1809 "IANA: IP Parameters, 1810 http://www.iana.org/assignments/ip-parameters"; 1811 } 1812 leaf default-lifetime { 1813 type uint16 { 1814 range "0..9000"; 1815 } 1816 units "seconds"; 1817 description 1818 "The value to be placed in the Router Lifetime field of 1819 Router Advertisements sent from the interface, in seconds. 1820 MUST be either zero or between max-rtr-adv-interval and 1821 9000 seconds. A value of zero indicates that the router is 1822 not to be used as a default router. These limits may be 1823 overridden by specific documents that describe how IPv6 1824 operates over different link layers. 1826 The default value is dynamic and should be set to 3 * 1827 max-rtr-adv-interval. 1828 "; 1829 } 1830 container prefix-list { 1831 description 1832 "A list of prefixes to be placed in Prefix Information 1833 options in Router Advertisement messages sent from the 1834 interface. 1836 By default, all prefixes that the router advertises via 1837 routing protocols as being on-link for the interface from 1838 which the advertisement is sent. The link-local prefix 1839 should not be included in the list of advertised prefixes. 1840 "; 1841 list prefix { 1842 key "prefix-spec"; 1843 description 1844 "Advertised prefix entry."; 1845 leaf prefix-spec { 1846 type inet:ipv6-prefix; 1847 description 1848 "IPv6 address prefix."; 1849 } 1850 choice control-adv-prefixes { 1851 default "advertise"; 1852 description 1853 "The prefix either may be explicitly removed from the 1854 set of advertised prefixes, or parameters with which 1855 it is advertised may be specified (default case)."; 1856 leaf no-advertise { 1857 type empty; 1858 description 1859 "The prefix will not be advertised. 1861 This may be used for removing the prefix from the 1862 default set of advertised prefixes. 1863 "; 1864 } 1865 case advertise { 1866 leaf valid-lifetime { 1867 type uint32; 1868 units "seconds"; 1869 default "2592000"; 1870 description 1871 "The value to be placed in the Valid Lifetime in 1872 the Prefix Information option, in seconds. The 1873 designated value of all 1's (0xffffffff) 1874 represents infinity. 1876 Implementations may allow valid-lifetime to be 1877 specified in two ways: 1879 1. a time that decrements in real time, that is, 1880 one that will result in a lifetime of zero at 1881 the specified time in the future, 1883 2. a fixed time that stays the same in consecutive 1884 advertisements. 1885 "; 1886 } 1887 leaf on-link-flag { 1888 type boolean; 1889 default "true"; 1890 description 1891 "The value to be placed in the on-link flag 1892 ('L-bit') field in the Prefix Information 1893 option."; 1894 } 1895 leaf preferred-lifetime { 1896 type uint32; 1897 units "seconds"; 1898 default "604800"; 1899 description 1900 "The value to be placed in the Preferred Lifetime 1901 in the Prefix Information option, in seconds. The 1902 designated value of all 1's (0xffffffff) 1903 represents infinity. 1905 Implementations MAY allow preferred-lifetime to be 1906 specified in two ways: 1908 1. a time that decrements in real time, that is, 1909 one that will result in a lifetime of zero at a 1910 specified time in the future, 1912 2. a fixed time that stays the same in consecutive 1913 advertisements. 1914 "; 1915 } 1916 leaf autonomous-flag { 1917 type boolean; 1918 default "true"; 1919 description 1920 "The value to be placed in the Autonomous Flag 1921 field in the Prefix Information option."; 1922 } 1923 } 1924 } 1925 } 1926 } 1927 } 1928 } 1930 augment "/rt:routing/rt:router/rt:routing-protocols/" 1931 + "rt:routing-protocol/rt:static-routes" { 1932 description 1933 "This augment defines the configuration of the 'static' 1934 pseudo-protocol with data specific for IPv6 unicast."; 1935 container ipv6 { 1936 description 1937 "Configuration of a 'static' pseudo-protocol instance 1938 consists of a list of routes."; 1939 list route { 1940 key "seqno"; 1941 ordered-by "user"; 1942 description 1943 "A user-ordered list of static routes."; 1944 leaf seqno { 1945 type uint32 { 1946 range "1..max"; 1947 } 1948 description 1949 "Sequential number of the route."; 1950 } 1951 leaf description { 1952 type string; 1953 description 1954 "Textual description of the route."; 1955 } 1956 uses rt:route-content; 1957 uses route-content { 1958 refine "dest-prefix" { 1959 mandatory "true"; 1960 } 1961 } 1962 } 1963 } 1964 } 1966 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 1967 + "rt:routes/rt:route" { 1968 when "../../rt:address-family='ipv6' and " 1969 + "../../rt:safi='nlri-unicast'" { 1970 description 1971 "This augment is valid only for IPv6 unicast."; 1972 } 1973 description 1974 "This augment defines the content of IPv6 unicast routes."; 1975 uses route-content; 1976 } 1977 } 1979 1981 9. IANA Considerations 1983 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1984 actual RFC number (and remove this note). 1986 This document registers the following namespace URIs in the IETF XML 1987 registry [RFC3688]: 1989 ---------------------------------------------------------- 1990 URI: urn:ietf:params:xml:ns:yang:ietf-routing 1992 Registrant Contact: The IESG. 1994 XML: N/A, the requested URI is an XML namespace. 1995 ---------------------------------------------------------- 1997 ---------------------------------------------------------- 1998 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2000 Registrant Contact: The IESG. 2002 XML: N/A, the requested URI is an XML namespace. 2003 ---------------------------------------------------------- 2005 ---------------------------------------------------------- 2006 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2008 Registrant Contact: The IESG. 2010 XML: N/A, the requested URI is an XML namespace. 2011 ---------------------------------------------------------- 2013 This document registers the following YANG modules in the YANG Module 2014 Names registry [RFC6020]: 2016 ------------------------------------------------------------------- 2017 name: ietf-routing 2018 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2019 prefix: rt 2020 reference: RFC XXXX 2021 ------------------------------------------------------------------- 2023 ------------------------------------------------------------------- 2024 name: ietf-ipv4-unicast-routing 2025 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2026 prefix: v4ur 2027 reference: RFC XXXX 2028 ------------------------------------------------------------------- 2030 ------------------------------------------------------------------- 2031 name: ietf-ipv6-unicast-routing 2032 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2033 prefix: v6ur 2034 reference: RFC XXXX 2035 ------------------------------------------------------------------- 2037 10. Security Considerations 2039 The YANG modules defined in this document are designed to be accessed 2040 via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 2041 secure transport layer and the mandatory-to-implement secure 2042 transport is SSH [RFC6242]. 2044 A number of data nodes defined in the YANG modules are writable/ 2045 creatable/deletable (i.e., "config true" in YANG terms, which is the 2046 default). These data nodes may be considered sensitive or vulnerable 2047 in some network environments. Write operations to these data nodes, 2048 such as "edit-config", can have negative effects on the network if 2049 the protocol operations are not properly protected. 2051 The vulnerable "config true" subtrees and data nodes are the 2052 following: 2054 /rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a 2055 network layer interface to a router instance and may also specify 2056 interface parameters related to routing. 2058 /rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This 2059 list specifies the routing protocols configured on a device. 2061 /rt:routing/rt:router/rt:route-filters/rt:route-filter This list 2062 specifies the configured route filters which represent the 2063 administrative policies for redistributing and modifying routing 2064 information. 2066 Unauthorized access to any of these lists can adversely affect the 2067 routing subsystem of both the local device and the network. This may 2068 lead to network malfunctions, delivery of packets to inappropriate 2069 destinations and other problems. 2071 11. Acknowledgments 2073 The author wishes to thank Martin Bjorklund, Joel Halpern, Thomas 2074 Morin, Tom Petch, Juergen Schoenwaelder, Dave Thaler and Yi Yang for 2075 their helpful comments and suggestions. 2077 12. References 2079 12.1. Normative References 2081 [IANA-IF-AF] 2082 Bjorklund, M., "IANA Interface Type and Address Family 2083 YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in 2084 progress), April 2012. 2086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2087 Requirement Levels", BCP 14, RFC 2119, March 1997. 2089 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2090 January 2004. 2092 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2093 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2094 September 2007. 2096 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2097 Network Configuration Protocol (NETCONF)", RFC 6020, 2098 September 2010. 2100 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 2101 RFC 6021, September 2010. 2103 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2104 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2105 June 2011. 2107 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2108 Configuration", draft-ietf-netmod-interfaces-cfg-04 (work 2109 in progress), April 2012. 2111 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 2112 draft-ietf-netmod-ip-cfg-03 (work in progress), 2113 April 2012. 2115 12.2. Informative References 2117 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2118 Data Model Documents", RFC 6087, January 2011. 2120 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2121 Shell (SSH)", RFC 6242, June 2011. 2123 Appendix A. Example: Adding a New Routing Protocol 2125 This appendix demonstrates how the core routing data model can be 2126 extended to support a new routing protocol. The YANG module 2127 "example-rip" shown below is intended only as an illustration rather 2128 than a real definition of a data model for the RIP routing protocol. 2129 For the sake of brevity, we do not follow all the guidelines 2130 specified in [RFC6087]. See also Section 4.4.2. 2132 file "example-rip@2012-05-24.yang" 2134 module example-rip { 2136 namespace "http://example.com/rip"; 2138 prefix "rip"; 2140 import ietf-routing { 2141 prefix "rt"; 2142 } 2144 identity rip { 2145 base rt:routing-protocol; 2146 description 2147 "Identity for the RIP routing protocol."; 2148 } 2150 typedef rip-metric { 2151 type uint8 { 2152 range "0..16"; 2153 } 2154 } 2156 grouping route-content { 2157 description 2158 "RIP-specific route content."; 2159 leaf metric { 2160 type rip-metric; 2161 } 2162 leaf tag { 2163 type uint16; 2164 default "0"; 2165 description 2166 "This leaf may be used to carry additional info, e.g. AS 2167 number."; 2168 } 2169 } 2170 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 2171 + "rt:routes/rt:route" { 2172 when "../../../../rt:routing-protocols/" 2173 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 2174 + "rt:type='rip:rip'" { 2175 description 2176 "This augment is only valid if the source protocol from which 2177 the route originated is RIP."; 2178 } 2179 description 2180 "RIP-specific route components."; 2181 uses route-content; 2182 } 2184 augment "/rt:active-route/rt:output/rt:route" { 2185 description 2186 "Add RIP-specific route content."; 2187 uses route-content; 2188 } 2190 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 2191 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 2192 + "'rip:rip'"; 2193 container rip { 2194 description 2195 "Per-interface RIP configuration."; 2196 leaf enabled { 2197 type boolean; 2198 default "true"; 2199 } 2200 leaf metric { 2201 type rip-metric; 2202 default "1"; 2203 } 2204 } 2205 } 2207 augment "/rt:routing/rt:router/rt:routing-protocols/" 2208 + "rt:routing-protocol" { 2209 when "rt:type = 'rip:rip'"; 2210 container rip { 2211 leaf update-interval { 2212 type uint8 { 2213 range "10..60"; 2214 } 2215 units "seconds"; 2216 default "30"; 2217 description 2218 "Time interval between periodic updates."; 2219 } 2220 } 2221 } 2222 } 2224 2226 Appendix B. Example: Reply to the NETCONF Message 2228 This section contains a sample reply to the NETCONF message, 2229 which could be sent by a server supporting (i.e., advertising them in 2230 the NETCONF message) the following YANG modules: 2232 o ietf-interfaces [YANG-IF], 2234 o ietf-ip [YANG-IP], 2236 o ietf-routing (Section 6), 2238 o ietf-ipv4-unicast-routing (Section 7), 2240 o ietf-ipv6-unicast-routing (Section 8). 2242 We assume a simple network setup as shown in Figure 3: router "A" 2243 uses static default routes with the "ISP" router as the next hop. 2244 IPv6 router advertisements are configured only on the "eth1" 2245 interface and disabled on the upstream "eth0" interface. 2247 +-----------------+ 2248 | | 2249 | Router ISP | 2250 | | 2251 +--------+--------+ 2252 |2001:db8:0:1::2 2253 |192.0.2.2 2254 | 2255 | 2256 |2001:db8:0:1::1 2257 eth0|192.0.2.1 2258 +--------+--------+ 2259 | | 2260 | Router A | 2261 | | 2262 +--------+--------+ 2263 eth1|198.51.100.1 2264 |2001:db8:0:2::1 2265 | 2267 Figure 3: Example network configuration 2269 Router "A" then could send the following XML document as its reply to 2270 the NETCONF message: 2272 2273 2281 2282 2283 2284 eth0 2285 ethernetCsmacd 2286 05:00.0 2287 2288 2289 192.0.2.1 2290 24 2291 2292 2293 2294 2295 2001:0db8:0:1::1 2296 64 2297 2298 2299 false 2300 2301 2302 2303 2304 eth1 2305 ethernetCsmacd 2306 05:00.1 2307 2308 2309 198.51.100.1 2310 24 2311 2312 2313 2314 2315 2001:0db8:0:2::1 2316 64 2317 2318 2319 false 2320 2321 2323 2324 2325 2326 2327 rtr0 2328 2329 2330 eth0 2331 2332 2333 eth1 2334 2335 true 2336 2337 2338 2001:db8:0:2::/64 2339 2340 2341 2342 2343 2344 2345 2346 direct 2347 rt:direct 2348 2349 2350 st0 2351 2352 Static routing is used for the internal network. 2353 2354 rt:static 2355 2356 2357 2358 1 2359 0.0.0.0/0 2360 192.0.2.2 2361 2362 2363 2364 2365 1 2366 ::/0 2367 2001:db8:0:1::2 2368 2369 2370 2371 2372 2373 main-ipv4-unicast 2374 2375 2376 main-ipv6-unicast 2377 2378 2379 2380 2381 2382 2383 main-ipv4-unicast 2384 2385 2386 192.0.2.1/24 2387 eth0 2388 direct 2389 3512 2390 2391 2392 198.51.100.0/24 2393 eth1 2394 direct 2395 3512 2396 2397 2398 0.0.0.0/0 2399 st0 2400 192.0.2.2 2401 2551 2402 2403 2404 2405 2406 main-ipv6-unicast 2407 ipv6 2408 nlri-unicast 2409 2410 2411 2001:db8:0:1::/64 2412 eth0 2413 direct 2414 3513 2415 2416 2417 2001:db8:0:2::/64 2418 eth1 2419 direct 2420 3513 2421 2422 2423 ::/0 2424 2001:db8:0:1::2 2425 st0 2426 2550 2427 2428 2429 2430 2431 2432 2433 2434 2436 Appendix C. Change Log 2438 RFC Editor: remove this section upon publication as an RFC. 2440 C.1. Changes Between Versions -02 and -03 2442 o Module "iana-afn-safi" moved to I-D "iana-if-type". 2444 o Removed forwarding table. 2446 o RPC "get-route" changed to "active-route". Its output is a list 2447 of routes (for multi-path routing). 2449 o New RPC "route-count". 2451 o For both RPCs, specification of negative responses was added. 2453 o Relaxed separation of router instances. 2455 o Assignment of interfaces to router instances needn't be disjoint. 2457 o Route filters are now global. 2459 o Added "allow-all-route-filter" for symmetry. 2461 o Added Section 5 about interactions with "ietf-interfaces" and 2462 "ietf-ip". 2464 o Added "router-id" leaf. 2466 o Specified the names for IPv4/IPv6 unicast main routing tables. 2468 o Route parameter "last-modified" changed to "age". 2470 o Added container "recipient-routing-tables". 2472 C.2. Changes Between Versions -01 and -02 2474 o Added module "ietf-ipv6-unicast-routing". 2476 o The example in Appendix B now uses IP addresses from blocks 2477 reserved for documentation. 2479 o Direct routes appear by default in the FIB table. 2481 o Network layer interfaces must be assigned to a router instance. 2482 Additional interface configuration may be present. 2484 o The "when" statement is only used with "augment", "must" is used 2485 elsewhere. 2487 o Additional "must" statements were added. 2489 o The "route-content" grouping for IPv4 and IPv6 unicast now 2490 includes the material from the "ietf-routing" version via "uses 2491 rt:route-content". 2493 o Explanation of symbols in the tree representation of data model 2494 hierarchy. 2496 C.3. Changes Between Versions -00 and -01 2498 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2500 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2501 safi" module. 2503 o Names of some data nodes were changed, in particular "routing- 2504 process" is now "router". 2506 o The restriction of a single AFN/SAFI per router was lifted. 2508 o RPC operation "delete-route" was removed. 2510 o Illegal XPath references from "get-route" to the datastore were 2511 fixed. 2513 o Section "Security Considerations" was written. 2515 Author's Address 2517 Ladislav Lhotka 2518 CZ.NIC 2520 Email: lhotka@nic.cz