idnits 2.17.00 (12 Aug 2021) /tmp/idnits7997/draft-ietf-netmod-routing-cfg-05.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 (October 4, 2012) is 3516 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 October 4, 2012 5 Expires: April 7, 2013 7 A YANG Data Model for Routing Configuration 8 draft-ietf-netmod-routing-cfg-05 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 April 7, 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 . . . . . . . 11 63 4.2. Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 12 65 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 14 66 4.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 15 67 4.4.2. Defining New Routing Protocols . . . . . . . . . . . . 15 68 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 18 69 4.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 19 70 5. Interactions with Other YANG Modules . . . . . . . . . . . . . 20 71 5.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 20 72 5.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 20 73 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 22 74 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 36 75 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 40 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 80 12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 81 12.2. Informative References . . . . . . . . . . . . . . . . . . 53 82 Appendix A. Example: Adding a New Routing Protocol . . . . . . . 54 83 Appendix B. Example: NETCONF Reply . . . . . . . . . . . . 56 84 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 61 85 C.1. Changes Between Versions -04 and -05 . . . . . . . . . . . 61 86 C.2. Changes Between Versions -03 and -04 . . . . . . . . . . . 61 87 C.3. Changes Between Versions -02 and -03 . . . . . . . . . . . 62 88 C.4. Changes Between Versions -01 and -02 . . . . . . . . . . . 62 89 C.5. Changes Between Versions -00 and -01 . . . . . . . . . . . 63 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 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, and advanced functions such as 113 route filtering or policy routing. To this end, it is expected that 114 the core routing data model will be augmented by numerous modules 115 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, RPC methods and other data 175 model objects are used mostly without a prefix, as long as it is 176 clear from the context in which YANG module each name is defined. 177 Otherwise, names are prefixed using the standard prefix associated 178 with the corresponding YANG module, as 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 type? 245 | +--rw enabled? 246 | +--rw router-id? 247 | +--rw description? 248 | +--rw main-routing-tables 249 | | +--rw main-routing-table [address-family safi] 250 | | +--rw address-family 251 | | +--rw safi 252 | | +--rw name? 253 | +--rw interfaces 254 | | +--rw interface [name] 255 | | +--rw name 256 | | +--rw v6ur:ipv6-router-advertisements 257 | | +--rw v6ur:send-advertisements? 258 | | +--rw v6ur:max-rtr-adv-interval? 259 | | +--rw v6ur:min-rtr-adv-interval? 260 | | +--rw v6ur:managed-flag? 261 | | +--rw v6ur:other-config-flag? 262 | | +--rw v6ur:link-mtu? 263 | | +--rw v6ur:reachable-time? 264 | | +--rw v6ur:retrans-timer? 265 | | +--rw v6ur:cur-hop-limit? 266 | | +--rw v6ur:default-lifetime? 267 | | +--rw v6ur:prefix-list 268 | | +--rw v6ur:prefix [prefix-spec] 269 | | +--rw v6ur:prefix-spec 270 | | +--rw (control-adv-prefixes)? 271 | | +--:(no-advertise) 272 | | | +--rw v6ur:no-advertise? 273 | | +--:(advertise) 274 | | +--rw v6ur:valid-lifetime? 275 | | +--rw v6ur:on-link-flag? 276 | | +--rw v6ur:preferred-lifetime? 277 | | +--rw v6ur:autonomous-flag? 278 | +--rw routing-protocols 279 | +--rw routing-protocol [name] 280 | +--rw name 281 | +--rw description? 282 | +--rw enabled? 283 | +--rw type 284 | +--rw connected-routing-tables 285 | | +--rw connected-routing-table [name] 286 | | +--rw name 287 | | +--rw import-filter? 288 | | +--rw export-filter? 289 | +--rw static-routes 290 | +--rw v4ur:ipv4 291 | | +--rw v4ur:route [id] 292 | | +--rw v4ur:id 293 | | +--rw v4ur:description? 294 | | +--rw v4ur:outgoing-interface? 295 | | +--rw v4ur:dest-prefix 296 | | +--rw v4ur:next-hop? 297 | +--rw v6ur:ipv6 298 | +--rw v6ur:route [id] 299 | +--rw v6ur:id 300 | +--rw v6ur:description? 301 | +--rw v6ur:outgoing-interface? 302 | +--rw v6ur:dest-prefix 303 | +--rw v6ur:next-hop? 304 +--rw routing-tables 305 | +--rw routing-table [name] 306 | +--rw name 307 | +--rw address-family 308 | +--rw safi 309 | +--rw description? 310 | +--ro routes 311 | | +--ro route 312 | | +--ro outgoing-interface? 313 | | +--ro source-protocol 314 | | +--ro last-updated? 315 | | +--ro v4ur:dest-prefix? 316 | | +--ro v4ur:next-hop? 317 | | +--ro v6ur:dest-prefix? 318 | | +--ro v6ur:next-hop? 319 | +--rw recipient-routing-tables 320 | +--rw recipient-routing-table [name] 321 | +--rw name 322 | +--rw filter? 323 | 324 | 325 +--rw route-filters 326 +--rw route-filter [name] 327 +--rw name 328 +--rw description? 329 +--rw type 331 Figure 1: Data hierarchy of the core routing data model. 333 As can be seen from Figure 1, the core routing data model introduces 334 several generic components of a routing framework: routers, routing 335 tables containing routes, routing protocols and route filters. The 336 following subsections describe these components in more detail. 338 By combining the components in various ways, and possibly augmenting 339 them with appropriate contents defined in other modules, various 340 routing setups can be realized. 342 +--------+ 343 | direct | +---+ +--------------+ +---+ +--------------+ 344 | routes |--->| F |--->| |<---| F |<---| | 345 +--------+ +---+ | main | +---+ | additional | 346 | routing | | routing | 347 +--------+ +---+ | table | +---+ | table | 348 | static |--->| F |--->| |--->| F |--->| | 349 | routes | +---+ +--------------+ +---+ +--------------+ 350 +--------+ ^ | ^ | 351 | v | v 352 +---+ +---+ +---+ +---+ 353 | F | | F | | F | | F | 354 +---+ +---+ +---+ +---+ 355 ^ | ^ | 356 | v | v 357 +----------+ +----------+ 358 | routing | | routing | 359 | protocol | | protocol | 360 +----------+ +----------+ 362 Figure 2: Example setup of the routing subsystem 364 The example in Figure 2 shows a typical (though certainly not the 365 only possible) organization of a more complex routing subsystem for a 366 single address family. Several of its features are worth mentioning: 368 o Along with the main routing table, which must always be present, 369 an additional routing table is configured. 371 o Each routing protocol instance, including the "static" and 372 "direct" pseudo-protocols, is connected to one routing table with 373 which it can exchange routes (in both directions, except for the 374 "static" and "direct" pseudo-protocols). 376 o Routing tables may also be connected to each other and exchange 377 routes in either direction (or both). 379 o Route exchanges along all connections may be controlled by means 380 of route filters, denoted by "F" in Figure 2. 382 4.1. Router 384 Each router instance in the core routing data model represents a 385 logical router. The exact semantics of this term is left to 386 implementations. For example, router instances may be completely 387 isolated virtual routers or, alternatively, they may internally share 388 certain information. 390 An implementation MAY support multiple types of logical routers 391 simultaneously. Instances of all router types are organized as 392 entries of the same flat "router" list. In order to distinguish 393 router instances belonging to the same type, the "type" leaf is 394 defined as a child of the "router" node. 396 An implementation MAY pose restrictions on allowed router types and 397 on the number of supported instances for each type. For example, a 398 simple router implementation may support only one router instance of 399 the default type "standard-router". 401 Each network layer interface has to be assigned to one or more router 402 instances in order to be able to participate in packet forwarding, 403 routing protocols and other operations of those router instances. 404 The assignment is accomplished by creating a corresponding entry in 405 the list of router interfaces ("rt:interface"). The key of the list 406 entry MUST be the name of a configured network layer interface, i.e., 407 the value of a node /if:interfaces/if:interface/if:name defined in 408 the "ietf-interfaces" module [YANG-IF]. 410 In YANG terms, the list of router interfaces is modeled as the "list" 411 node rather than "leaf-list" in order to allow for adding, via 412 augmentation, other configuration or operational state data related 413 to the corresponding router interface. 415 Implementations MAY specify additional rules for the assignment of 416 interfaces to logical routers. For example, it may be required that 417 the sets of interfaces assigned to different logical routers be 418 disjoint. 420 4.1.1. Configuration of IPv6 Router Interfaces 422 The module "ietf-ipv6-unicast-routing" augments the definition of the 423 data node "rt:interface" with definitions of the following 424 configuration variables as required by [RFC4861], sec. 6.2.1: 426 o send-advertisements, 428 o max-rtr-adv-interval, 430 o min-rtr-adv-interval, 432 o managed-flag, 434 o other-config-flag, 436 o link-mtu, 438 o reachable-time, 440 o retrans-timer, 442 o cur-hop-limit, 444 o default-lifetime, 446 o prefix-list: a list of prefixes to be advertised. The following 447 parameters are associated with each prefix in the list: 449 * valid-lifetime, 451 * on-link-flag, 453 * preferred-lifetime, 455 * autonomous-flag. 457 The definitions and descriptions of the above parameters can be found 458 in the text of the module "ietf-ipv6-unicast-routing" (Section 8). 460 NOTES: 462 1. The "IsRouter" flag, which is also required by [RFC4861], is 463 implemented in the "ietf-ip" module [YANG-IP] (leaf "ip:ip- 464 forwarding"). 466 2. The original specification [RFC4861] allows the implementations 467 to decide whether the "valid-lifetime" and "preferred-lifetime" 468 parameters remain the same in consecutive advertisements, or 469 decrement in real time. However, the latter behavior seems 470 problematic because the values might be reset again to the 471 (higher) configured values after a configuration is reloaded. 472 Moreover, no implementation is known to use the decrementing 473 behavior. The "ietf-ipv6-unicast-routing" module therefore 474 assumes the former behavior with constant values. 476 4.2. Routes 478 Routes are basic units of information in a routing system. The core 479 routing data model defines only the following minimal set of route 480 attributes: 482 o "destination-prefix": IP prefix specifying the set of destination 483 addresses for which the route may be used. This attribute is 484 mandatory. 486 o "next-hop": IP address of an adjacent router or host to which 487 packets with destination addresses belonging to "destination- 488 prefix" should be sent. 490 o "outgoing-interface": network interface that should be used for 491 sending packets with destination addresses belonging to 492 "destination-prefix". 494 The above list of route attributes suffices for a simple static 495 routing configuration. It is expected that future modules defining 496 routing protocols will add other route attributes such as metrics or 497 preferences. 499 Routes and their attributes are used both in configuration data, for 500 example as manually configured static routes, and in operational 501 state data, for example as entries in routing tables. 503 4.3. Routing Tables 505 Routing tables are lists of routes complemented with administrative 506 data, namely: 508 o "source-protocol": name of the routing protocol from which the 509 route was originally obtained. 511 o "last-updated": the date and time when the route was last updated, 512 or inserted into the routing table. 514 Each routing table may contain only routes of the same address 515 family. Address family information consists of two parameters - 516 "address-family" and "safi" (Subsequent Address Family Identifier, 517 SAFI). The permitted values for these two parameters are defined by 518 IANA and represented using YANG enumeration types "ianaaf:address- 519 family" and "ianaaf:subsequent-address-family" [IANA-IF-AF]. 521 In the core routing data model, the "routing-table" node represents 522 configuration while the descendant list of routes is defined as 523 operational state data. The contents of route lists are controlled 524 and manipulated by routing protocol operations which may result in 525 route additions, removals and modifications. This also includes 526 manipulations via the "static" and/or "direct" pseudo-protocols, see 527 Section 4.4.1. 529 One or more routing tables MUST be configured for each address family 530 supported by the server. Each router instance MUST designate, for 531 every address family that the router instance supports, exactly one 532 routing table as its main routing table. This is accomplished by 533 creating an entry in the "main-routing-table" list, which contains a 534 reference to the routing table that is selected as main. 536 Main routing tables serve the following purposes: 538 o The router instance always installs direct routes for an address 539 family to that address family's main routing table. 541 o By default, a routing protocol SHOULD be connected to the main 542 routing table of each address family supported by that routing 543 protocol. See Section 4.4 for further explanation. 545 Routing tables are global, which means that a configured routing 546 table may be used by any or all router instances. 548 Server implementations MAY pose restrictions regarding the number of 549 supported routing tables, and rules for configuration and use of 550 routing tables. For example: 552 o A server may support no more than one routing table per address 553 family. 555 o Router instances (of a certain type) may not be allowed to share 556 routing tables, i.e., each routing table is used by no more than 557 one router instance. 559 For servers supporting multiple routing tables per address family, 560 additional tables can be configured by creating new entries in the 561 "routing-table" list, either as a part of factory-default 562 configuration, or by a client's action. 564 The way how the routing system uses information from routing tables 565 for actual packet forwarding is outside the scope of this document. 567 Every routing table can serve as a source of routes for other routing 568 tables. To achieve this, one or more recipient routing tables may be 569 specified in the configuration of the source routing table. 570 Optionally, a route filter may be configured for any or all recipient 571 routing tables. Such a route filter then selects and/or manipulates 572 the routes that are passed on between the source and recipient 573 routing table. 575 A routing table MUST NOT appear among its own recipient routing 576 tables. A recipient routing table also MUST be of the same address 577 family as its source routing table.Consequently, configuration of 578 recipient routing tables makes sense only for servers supporting 579 multiple routing tables per address family. Servers supporting only 580 one routing table per address family MAY therefore decide to remove 581 the container "recipient-routing-tables", together with its contents, 582 from the data model. 584 4.4. Routing Protocols 586 The core routing data model provides an open-ended framework for 587 defining multiple routing protocol instances within each router 588 instance. Each routing protocol instance MUST be assigned a type, 589 which is an identity derived from the "rt:routing-protocol" base 590 identity. The core routing data model defines two identities for the 591 direct and static pseudo-protocols (Section 4.4.1). 593 Each routing protocol instance is connected to exactly one routing 594 table for each address family that the routing protocol instance 595 supports. By default, every routing protocol instance SHOULD be 596 connected to the main routing table or tables. An implementation MAY 597 allow any or all routing protocol instances to be configured to use a 598 different routing table. 600 Routes learned from the network by a routing protocol are passed to 601 the connected routing table(s) and vice versa, subject to routing 602 protocol specific rules and restrictions. 604 In addition, two independent route filters (see Section 4.5) may be 605 defined for a routing protocol instance to control the exchange of 606 routes in both directions between the routing protocol instance and 607 the connected routing table: 609 o import filter controls which routes are passed from a routing 610 protocol instance to the connected routing table, 612 o export filter controls which routes the routing protocol instance 613 may receive from the connected routing table. 615 Note that, for historical reasons, the terms import and export are 616 used from the viewpoint of a routing table. 618 4.4.1. Routing Pseudo-Protocols 620 The core routing data model defines two special routing protocol 621 types - "direct" and "static". Both are in fact pseudo-protocols, 622 which means that they are confined to the local device and do not 623 exchange any routing information with neighboring routers. Routes 624 from both "direct" and "static" protocol instances are passed to the 625 connected routing table (subject to route filters, if any), but an 626 exchange in the opposite direction is not allowed. 628 Every router instance MUST implement exactly one instance of the 629 "direct" pseudo-protocol type. The name of this instance MUST also 630 be "direct". It is the source of direct routes for all configured 631 address families. Direct routes are normally supplied by the 632 operating system kernel, based on the configuration of network 633 interface addresses, see Section 5.2. The "direct" pseudoprotocol 634 MUST always be connected to the main routing tables of all supported 635 address families. This means that direct routes are always installed 636 in the main routing tables. However, direct routes MAY be filtered 637 before they appear in the main routing table. 639 A pseudo-protocol of the type "static" allows for specifying routes 640 manually. It MAY be configured in zero or multiple instances, 641 although a typical configuration will have exactly one instance per 642 logical router. 644 4.4.2. Defining New Routing Protocols 646 It is expected that future YANG modules will create data models for 647 additional routing protocol types. Such a new module has to define 648 the protocol-specific configuration and operational state data, and 649 it has to fit it into the core routing framework in the following 650 way: 652 o A new identity MUST be defined for the routing protocol and its 653 base identity MUST be set to "rt:routing-protocol", or to an 654 identity derived from "rt:routing-protocol". 656 o Additional route attributes MAY be defined, preferably in one 657 place by means of defining a YANG grouping. The new attributes 658 have to be inserted as operational state data by augmenting the 659 definition of the node 660 /rt:routing-tables/rt:routing-table/rt:route, 662 and possibly to other places in the configuration, operational 663 state data and RPC input or output. 665 o Per-interface configuration parameters can be added by augmenting 666 the data node "rt:interface" (the list of router interfaces). 668 o Other configuration parameters and operational state data can be 669 defined by augmenting the "routing-protocol" data node. 671 By using the "when" statement, the augmented per-interface and other 672 configuration parameters specific to the new protocol SHOULD be made 673 conditional and valid only if the value of "rt:type" is equal to the 674 new protocol's identity. It is also RECOMMENDED that the protocol- 675 specific data be encapsulated in appropriately named containers. 677 The above steps are implemented by the example YANG module for the 678 RIP routing protocol in Appendix A. First, the module defines a new 679 identity for the RIP protocol: 681 identity rip { 682 base rt:routing-protocol; 683 description "Identity for the RIP routing protocol."; 684 } 686 New route attributes specific to the RIP protocol ("metric" and 687 "tag") are defined in a grouping and then added to the route 688 definitions appearing in "routing-table" and in the output part of 689 the "active-route" RPC method: 691 grouping route-content { 692 description 693 "RIP-specific route content."; 694 leaf metric { 695 type rip-metric; 696 } 697 leaf tag { 698 type uint16; 699 default "0"; 700 description 701 "This leaf may be used to carry additional info, e.g. AS 702 number."; 703 } 704 } 706 augment "/rt:routing/rt:routing-tables/rt:routing-table/" 707 + "rt:routes/rt:route" { 708 description 709 "RIP-specific route components."; 710 uses route-content; 711 } 713 augment "/rt:active-route/rt:output/rt:route" { 714 description 715 "Add RIP-specific route content."; 716 uses route-content; 717 } 719 Per-interface configuration data are defined by the following 720 "augment" statement: 722 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 723 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 724 + "'rip:rip'"; 725 container rip { 726 description 727 "Per-interface RIP configuration."; 728 leaf enabled { 729 type boolean; 730 default "true"; 731 } 732 leaf metric { 733 type rip-metric; 734 default "1"; 735 } 736 } 737 } 738 Finally, global RIP configuration data are integrated into the "rt: 739 routing-protocol" node by using the following "augment" statement, 740 which is again valid only for routing protocol instances whose type 741 is "rip:rip": 743 augment "/rt:routing/rt:router/rt:routing-protocols/" 744 + "rt:routing-protocol" { 745 when "rt:type = 'rip:rip'"; 746 container rip { 747 leaf update-interval { 748 type uint8 { 749 range "10..60"; 750 } 751 units "seconds"; 752 default "30"; 753 description 754 "Time interval between periodic updates."; 755 } 756 } 757 } 759 4.5. Route Filters 761 The core routing data model provides a skeleton for defining route 762 filters that can be used to restrict the set of routes being 763 exchanged between a routing protocol instance and a connected routing 764 table, or between a source and a recipient routing table. Route 765 filters may also manipulate routes, i.e., add, delete, or modify 766 their attributes. 768 Route filters are global, which means that a configured route filter 769 may be used by any or all router instances. 771 By itself, the route filtering framework defined in this document 772 allows for applying only two extreme routing policies which are 773 represented by the following pre-defined route filter types: 775 o "deny-all-route-filter": all routes are blocked, 777 o "allow-all-route-filter": all routes are permitted. 779 Note that the latter type is equivalent to no route filter. 781 It is expected that more comprehensive route filtering frameworks 782 will be developed separately. 784 Each route filter is identified by a name which MUST be unique within 785 the entire configuration. Its type MUST be specified by the "type" 786 identity reference - this opens the space for multiple route 787 filtering framework implementations. The default value for the route 788 filter type is the identity "deny-all-route-filter". 790 4.6. RPC Operations 792 The "ietf-routing" module defines two RPC operations: 794 o active-route: query the routing system for the active route(s) 795 that are currently used for sending datagrams to a destination 796 host whose address is passed as an input parameter. 798 o route-count: retrieve the total number of entries in a routing 799 table. 801 5. Interactions with Other YANG Modules 803 The semantics of the core routing data model also depend on several 804 configuration parameters that are defined in other YANG modules. The 805 following subsections describe these interactions. 807 In all cases, the relevant parts of the core routing data model are 808 disabled but MUST NOT be deleted from the configuration by the 809 server. 811 5.1. Module "ietf-interfaces" 813 The following boolean switch is defined in the "ietf-interfaces" YANG 814 module [YANG-IF]: 816 /if:interfaces/if:interface/if:enabled 818 If this switch is set to "false" for a given network layer 819 interface, the device MUST behave exactly as if that interface was 820 not assigned to any logical router at all. 822 5.2. Module "ietf-ip" 824 The following boolean switches are defined in the "ietf-ip" YANG 825 module [YANG-IP]: 827 /if:interfaces/if:interface/ip:ipv4/ip:enabled 829 If this switch is set to "false" for a given interface, then all 830 IPv4 routing functions related to that interface MUST be disabled. 832 /if:interfaces/if:interface/ip:ipv4/ip:ip-forwarding 834 If this switch is set to "false" for a given interface, then the 835 forwarding of IPv4 datagrams to and from this interface MUST be 836 disabled. However, the interface may participate in other routing 837 functions, such as routing protocols. 839 /if:interfaces/if:interface/ip:ipv6/ip:enabled 841 If this switch is set to "false" for a given interface, then all 842 IPv6 routing functions related to that interface MUST be disabled. 844 /if:interfaces/if:interface/ip:ipv6/ip:ip-forwarding 846 If this switch is set to "false" for a given interface, then the 847 forwarding of IPv6 datagrams to and from this interface MUST be 848 disabled. However, the interface may participate in other routing 849 functions, such as routing protocols. 851 In addition, the "ietf-ip" module allows for configuring IPv4 and 852 IPv6 addresses and subnet masks on network layer interfaces. 853 Configuration of these parameters on an enabled interface MUST result 854 in an immediate creation of the corresponding direct route (usually 855 in the main routing table). Its destination prefix is set according 856 to the configured IP address and subnet mask, and the interface is 857 set as the outgoing interface for that route. 859 6. Routing YANG Module 861 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 862 actual RFC number and all occurrences of the revision date below with 863 the date of RFC publication (and remove this note). 865 file "ietf-routing@2012-10-04.yang" 867 module ietf-routing { 869 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 871 prefix "rt"; 873 import ietf-yang-types { 874 prefix "yang"; 875 } 877 import ietf-inet-types { 878 prefix "inet"; 879 } 881 import ietf-interfaces { 882 prefix "if"; 883 } 885 import iana-afn-safi { 886 prefix "ianaaf"; 887 } 889 organization 890 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 892 contact 893 "WG Web: 894 WG List: 896 WG Chair: David Kessens 897 899 WG Chair: Juergen Schoenwaelder 900 902 Editor: Ladislav Lhotka 903 904 "; 906 description 907 "This YANG module defines essential components that may be used 908 for configuring a routing subsystem. 910 Copyright (c) 2012 IETF Trust and the persons identified as 911 authors of the code. All rights reserved. 913 Redistribution and use in source and binary forms, with or 914 without modification, is permitted pursuant to, and subject to 915 the license terms contained in, the Simplified BSD License set 916 forth in Section 4.c of the IETF Trust's Legal Provisions 917 Relating to IETF Documents 918 (http://trustee.ietf.org/license-info). 920 This version of this YANG module is part of RFC XXXX; see the 921 RFC itself for full legal notices. 922 "; 924 revision 2012-10-04 { 925 description 926 "Initial revision."; 927 reference 928 "RFC XXXX: A YANG Data Model for Routing Configuration"; 929 } 931 /* Identities */ 933 identity router-type { 934 description 935 "Base identity from which router type identities are derived. 937 It is primarily intended for discriminating among different 938 types of logical routers or router virtualization. 939 "; 940 } 942 identity standard-router { 943 base router-type; 944 description 945 "This identity represents a standard router."; 946 } 948 identity routing-protocol { 949 description 950 "Base identity from which routing protocol identities are 951 derived."; 952 } 954 identity direct { 955 base routing-protocol; 956 description 957 "Routing pseudo-protocol which provides routes to directly 958 connected networks."; 959 } 961 identity static { 962 base routing-protocol; 963 description 964 "Static routing pseudo-protocol."; 965 } 967 identity route-filter { 968 description 969 "Base identity from which all route filters are derived."; 970 } 972 identity deny-all-route-filter { 973 base route-filter; 974 description 975 "Route filter that blocks all routes."; 976 } 978 identity allow-all-route-filter { 979 base route-filter; 980 description 981 "Route filter that permits all routes. 982 "; 983 } 985 /* Type Definitions */ 987 typedef router-ref { 988 type leafref { 989 path "/rt:routing/rt:router/rt:name"; 990 } 991 description 992 "This type is used for leafs that reference a router 993 instance."; 994 } 996 /* Groupings */ 998 grouping afn-safi { 999 leaf address-family { 1000 type ianaaf:address-family; 1001 mandatory "true"; 1002 description 1003 "Address family of routes in the routing table."; 1004 } 1005 leaf safi { 1006 type ianaaf:subsequent-address-family; 1007 mandatory "true"; 1008 description 1009 "Subsequent address family identifier of routes in the 1010 routing table."; 1011 } 1012 description 1013 "This grouping provides two parameters specifying address 1014 family and subsequent address family."; 1015 } 1017 grouping route-content { 1018 description 1019 "Generic parameters of routes."; 1020 leaf outgoing-interface { 1021 type if:interface-ref; 1022 description 1023 "Outgoing interface."; 1024 } 1025 } 1027 /* RPC Methods */ 1029 rpc active-route { 1030 description 1031 "Return the active route (or multiple routes, in the case of 1032 multi-path routing) to a destination address. 1034 Parameters 1036 1. 'router-name', 1038 2. 'destination-address'. 1040 If the router instance with 'router-name' doesn't exist, then 1041 this operation shall fail with error-tag 'data-missing' and 1042 error-app-tag 'router-not-found'. 1044 If no active route for 'destination-address' exists, no output 1045 is returned - the server shall send an containing 1046 a single element . 1047 "; 1048 input { 1049 leaf router-name { 1050 type router-ref; 1051 mandatory "true"; 1052 description 1053 "Name of the router instance whose forwarding information 1054 base is being queried."; 1055 } 1056 container destination-address { 1057 uses afn-safi; 1058 description 1059 "Network layer destination address. 1061 Address family specific modules must augment this 1062 container with a leaf named 'address'. 1063 "; 1064 } 1065 } 1066 output { 1067 list route { 1068 uses afn-safi; 1069 uses route-content; 1070 description 1071 "Route contents specific for each address family should be 1072 defined through augmenting."; 1073 } 1074 } 1075 } 1077 rpc route-count { 1078 description 1079 "Return the current number of routes in a routing table. 1081 Parameters: 1083 1. 'routing-table-name'. 1085 If the routing table with the name specified in 1086 'routing-table-name' doesn't exist, then this operation shall 1087 fail with error-tag 'data-missing' and error-app-tag 1088 'routing-table-not-found'. 1089 "; 1090 input { 1091 leaf routing-table { 1092 type leafref { 1093 path "/routing/routing-tables/routing-table/name"; 1094 } 1095 mandatory "true"; 1096 description 1097 "Name of the routing table."; 1098 } 1100 } 1101 output { 1102 leaf number-of-routes { 1103 type uint32; 1104 mandatory "true"; 1105 description 1106 "Number of routes in the routing table."; 1107 } 1108 } 1109 } 1111 /* Data Nodes */ 1113 container routing { 1114 description 1115 "Routing parameters."; 1116 list router { 1117 key "name"; 1118 unique "router-id"; 1119 description 1120 "Each list entry is a container for configuration and 1121 operational state data of a single (logical) router. 1123 Network layer interfaces assigned to the router must have 1124 their entries in the 'interfaces' list. 1125 "; 1126 leaf name { 1127 type string; 1128 description 1129 "An arbitrary name of the router instance."; 1130 } 1131 leaf type { 1132 type identityref { 1133 base router-type; 1134 } 1135 default "rt:standard-router"; 1136 description 1137 "This leaf specifies the router type. 1139 It is primarily intended as a means for discriminating 1140 among different types of logical routers, route 1141 virtualization, master-slave arrangements etc., while 1142 keeping all such router instances in the same flat list. 1144 Standard router instances should use the default value. 1145 "; 1146 } 1147 leaf enabled { 1148 type boolean; 1149 default "true"; 1150 description 1151 "Enable/disable the router instance. 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 leaf router-id { 1159 type inet:ipv4-address; 1160 description 1161 "Global router ID in the form of an IPv4 address. 1163 An implementation may select a value if this parameter is 1164 not configured. 1166 Routing protocols may override this global parameter 1167 inside their configuration. 1168 "; 1169 } 1170 leaf description { 1171 type string; 1172 description 1173 "Textual description of the router."; 1174 } 1175 container main-routing-tables { 1176 description 1177 "Main routing tables used by the router instance."; 1178 list main-routing-table { 1179 must "address-family=//routing/routing-tables/" 1180 + "routing-table[name=current()/name]/" 1181 + "address-family and safi=//routing/routing-tables/" 1182 + "routing-table[name=current()/name]/safi" { 1183 error-message "Address family mismatch."; 1184 description 1185 "The entry's address family must match that of the 1186 referenced routing table."; 1187 } 1188 key "address-family safi"; 1189 description 1190 "Each list entry specifies the main routing table for one 1191 address family. 1193 The main routing table receives direct routes, and all 1194 routing protocols should be connected to the main 1195 routing table(s) by default. 1197 Address families that don't have their entry in this 1198 list must not be used in the rest of the router instance 1199 configuration. 1200 "; 1201 uses afn-safi; 1202 leaf name { 1203 type leafref { 1204 path "/routing/routing-tables/routing-table/name"; 1205 } 1206 description 1207 "Name of an existing routing table to be used as the 1208 main routing table for the given router and address 1209 family."; 1210 } 1211 } 1212 } 1213 container interfaces { 1214 description 1215 "Router interface parameters."; 1216 list interface { 1217 key "name"; 1218 description 1219 "List of network layer interfaces assigned to the router 1220 instance."; 1221 leaf name { 1222 type if:interface-ref; 1223 description 1224 "A reference to the name of a configured network layer 1225 interface."; 1226 } 1227 } 1228 } 1229 container routing-protocols { 1230 description 1231 "Container for the list of configured routing protocol 1232 instances."; 1233 list routing-protocol { 1234 key "name"; 1235 description 1236 "An instance of a routing protocol."; 1237 leaf name { 1238 type string; 1239 description 1240 "An arbitrary name of the routing protocol instance."; 1241 } 1242 leaf description { 1243 type string; 1244 description 1245 "Textual description of the routing protocol 1246 instance."; 1247 } 1248 leaf enabled { 1249 type boolean; 1250 default "true"; 1251 description 1252 "Enable/disable the routing protocol instance. 1254 If this parameter is false, the parent routing 1255 protocol instance is disabled, despite any other 1256 configuration that might be present. 1257 "; 1258 } 1259 leaf type { 1260 type identityref { 1261 base routing-protocol; 1262 } 1263 mandatory "true"; 1264 description 1265 "Type of the routing protocol - an identity derived 1266 from the 'routing-protocol' base identity."; 1267 } 1268 container connected-routing-tables { 1269 description 1270 "Container for connected routing tables."; 1271 list connected-routing-table { 1272 must "not(//routing/routing-tables/" 1273 + "routing-table[name=current()/" 1274 + "preceding-sibling::connected-routing-table/" 1275 + "name]/address-family=//routing/routing-tables/" 1276 + "routing-table[name=current()/name]/" 1277 + "address-family and //routing/routing-tables/" 1278 + "routing-table[name=current()/" 1279 + "preceding-sibling::connected-routing-table/" 1280 + "name]/safi=//routing/routing-tables/" 1281 + "routing-table[name=current()/name]/safi)" { 1282 error-message "Duplicate address family for " 1283 + "connected routing table."; 1284 description 1285 "For each AFN/SAFI pair there may be at most one 1286 connected routing table."; 1287 } 1288 key "name"; 1289 description 1290 "List of routing tables to which the routing protocol 1291 instance is connected. 1293 If no connected routing table is defined for an 1294 address family, the routing protocol should be 1295 connected by default to the main routing table for 1296 that address family. 1297 "; 1298 leaf name { 1299 type leafref { 1300 path "/routing/routing-tables/routing-table/name"; 1301 } 1302 description 1303 "Name of an existing routing table."; 1304 } 1305 leaf import-filter { 1306 type leafref { 1307 path "/routing/route-filters/route-filter/name"; 1308 } 1309 description 1310 "Reference to a route filter that is used for 1311 filtering routes passed from this routing protocol 1312 instance to the routing table specified by the 1313 'name' sibling node. 1315 If this leaf is not present, the behavior is 1316 protocol-specific, but typically it means that all 1317 routes are accepted. 1318 "; 1319 } 1320 leaf export-filter { 1321 type leafref { 1322 path "/routing/route-filters/route-filter/name"; 1323 } 1324 description 1325 "Reference to a route filter that is used for 1326 filtering routes passed from the routing table 1327 specified by the 'name' sibling node to this 1328 routing protocol instance. 1330 If this leaf is not present, the behavior is 1331 protocol-specific - typically it means that all 1332 routes are accepted. 1334 The 'direct' and 'static' pseudo-protocols accept 1335 no routes from any routing table. 1336 "; 1337 } 1338 } 1339 } 1340 container static-routes { 1341 when "../type='rt:static'" { 1342 description 1343 "This container is only valid for the 'static' 1344 routing protocol."; 1345 } 1346 description 1347 "Configuration of 'static' pseudo-protocol. 1349 Address family specific modules should augment this 1350 node with lists of routes. 1351 "; 1352 } 1353 } 1354 } 1355 } 1356 container routing-tables { 1357 description 1358 "Container for configured routing tables."; 1359 list routing-table { 1360 key "name"; 1361 description 1362 "Each entry represents a routing table identified by the 1363 'name' key. All routes in a routing table must have the 1364 same AFN and SAFI."; 1365 leaf name { 1366 type string; 1367 description 1368 "An arbitrary name of the routing table."; 1369 } 1370 uses afn-safi; 1371 leaf description { 1372 type string; 1373 description 1374 "Textual description of the routing table."; 1375 } 1376 container routes { 1377 config "false"; 1378 description 1379 "Current contents of the routing table (operational state 1380 data)."; 1381 list route { 1382 description 1383 "A routing table entry. This data node must augmented 1384 with information specific for routes of each address 1385 family."; 1386 uses route-content; 1387 leaf source-protocol { 1388 type leafref { 1389 path "/routing/router/routing-protocols/" 1390 + "routing-protocol/name"; 1391 } 1392 mandatory "true"; 1393 description 1394 "The name of an existing routing protocol instance 1395 from which the route comes."; 1396 } 1397 leaf last-updated { 1398 type yang:date-and-time; 1399 description 1400 "Time stamp of the last modification of the route. If 1401 the route was never modified, it is the time when 1402 the route was inserted into the routing table."; 1403 } 1404 } 1405 } 1406 container recipient-routing-tables { 1407 description 1408 "Container for recipient routing tables."; 1409 list recipient-routing-table { 1410 must "name != ../../name" { 1411 error-message "Source and recipient routing tables " 1412 + "are identical."; 1413 description 1414 "A routing table must not appear among its recipient 1415 routing tables."; 1416 } 1417 must "//routing/routing-tables/" 1418 + "routing-table[name=current()/name]/" 1419 + "address-family=../../address-family and //routing/" 1420 + "routing-tables/routing-table[name=current()/name]/" 1421 + "safi=../../safi" { 1422 error-message "Address family mismatch."; 1423 description 1424 "Address family of the recipient routing table must 1425 match the source table."; 1426 } 1427 key "name"; 1428 description 1429 "List of routing tables that receive routes from this 1430 routing table."; 1431 leaf name { 1432 type leafref { 1433 path "/routing/routing-tables/routing-table/name"; 1434 } 1435 description 1436 "The name of the recipient routing table."; 1438 } 1439 leaf filter { 1440 type leafref { 1441 path "/routing/route-filters/route-filter/name"; 1442 } 1443 description 1444 "A route filter which is applied to the routes passed 1445 on to the recipient routing table."; 1446 } 1447 } 1448 } 1449 } 1450 } 1451 container route-filters { 1452 description 1453 "Container for configured route filters."; 1454 list route-filter { 1455 key "name"; 1456 description 1457 "Route filters are used for filtering and/or manipulating 1458 routes that are passed between a routing protocol and a 1459 routing table or vice versa, or between two routing 1460 tables. 1462 It is expected that other modules augment this list with 1463 contents specific for a particular route filter type. 1464 "; 1465 leaf name { 1466 type string; 1467 description 1468 "An arbitrary name of the route filter."; 1469 } 1470 leaf description { 1471 type string; 1472 description 1473 "Textual description of the route filter."; 1474 } 1475 leaf type { 1476 type identityref { 1477 base route-filter; 1478 } 1479 mandatory "true"; 1480 description 1481 "Type of the route-filter - an identity derived from the 1482 'route-filter' base identity."; 1483 } 1484 } 1485 } 1487 } 1488 } 1490 1492 7. IPv4 Unicast Routing YANG Module 1494 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1495 actual RFC number and all occurrences of the revision date below with 1496 the date of RFC publication (and remove this note). 1498 file "ietf-ipv4-unicast-routing@2012-10-04.yang" 1500 module ietf-ipv4-unicast-routing { 1502 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1504 prefix "v4ur"; 1506 import ietf-routing { 1507 prefix "rt"; 1508 } 1510 import ietf-inet-types { 1511 prefix "inet"; 1512 } 1514 organization 1515 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1517 contact 1518 "WG Web: 1519 WG List: 1521 WG Chair: David Kessens 1522 1524 WG Chair: Juergen Schoenwaelder 1525 1527 Editor: Ladislav Lhotka 1528 1529 "; 1531 description 1532 "This YANG module augments the 'ietf-routing' module with basic 1533 configuration and operational state data for IPv4 unicast 1534 routing. 1536 Copyright (c) 2012 IETF Trust and the persons identified as 1537 authors of the code. All rights reserved. 1539 Redistribution and use in source and binary forms, with or 1540 without modification, is permitted pursuant to, and subject to 1541 the license terms contained in, the Simplified BSD License set 1542 forth in Section 4.c of the IETF Trust's Legal Provisions 1543 Relating to IETF Documents 1544 (http://trustee.ietf.org/license-info). 1546 This version of this YANG module is part of RFC XXXX; see the 1547 RFC itself for full legal notices. 1548 "; 1550 revision 2012-10-04 { 1551 description 1552 "Initial revision."; 1553 reference 1554 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1555 } 1557 /* Groupings */ 1559 grouping route-content { 1560 description 1561 "Parameters of IPv4 unicast routes."; 1562 leaf dest-prefix { 1563 type inet:ipv4-prefix; 1564 description 1565 "IPv4 destination prefix."; 1566 } 1567 leaf next-hop { 1568 type inet:ipv4-address; 1569 description 1570 "IPv4 address of the next hop."; 1571 } 1572 } 1574 /* RPC Methods */ 1576 augment "/rt:active-route/rt:input/rt:destination-address" { 1577 when "address-family='ipv4' and safi='nlri-unicast'" { 1578 description 1579 "This augment is valid only for IPv4 unicast."; 1580 } 1581 description 1582 "The 'address' leaf augments the 'rt:destination-address' 1583 parameter of the 'rt:active-route' operation."; 1584 leaf address { 1585 type inet:ipv4-address; 1586 description 1587 "IPv4 destination address."; 1589 } 1590 } 1592 augment "/rt:active-route/rt:output/rt:route" { 1593 when "address-family='ipv4' and safi='nlri-unicast'" { 1594 description 1595 "This augment is valid only for IPv4 unicast."; 1596 } 1597 description 1598 "Contents of the reply to 'rt:active-route' operation."; 1599 uses route-content; 1600 } 1602 /* Data nodes */ 1604 augment "/rt:routing/rt:router/rt:routing-protocols/" 1605 + "rt:routing-protocol/rt:static-routes" { 1606 description 1607 "This augment defines the configuration of the 'static' 1608 pseudo-protocol with data specific for IPv4 unicast."; 1609 container ipv4 { 1610 description 1611 "Configuration of a 'static' pseudo-protocol instance 1612 consists of a list of routes."; 1613 list route { 1614 key "id"; 1615 ordered-by "user"; 1616 description 1617 "A user-ordered list of static routes."; 1618 leaf id { 1619 type uint32 { 1620 range "1..max"; 1621 } 1622 description 1623 "Numeric identifier of the route. 1625 It is not required that the routes be sorted by their 1626 'id'. 1627 "; 1628 } 1629 leaf description { 1630 type string; 1631 description 1632 "Textual description of the route."; 1633 } 1634 uses rt:route-content; 1635 uses route-content { 1636 refine "dest-prefix" { 1637 mandatory "true"; 1638 } 1639 } 1640 } 1641 } 1642 } 1644 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 1645 + "rt:route" { 1646 when "../../rt:address-family='ipv4' and " 1647 + "../../rt:safi='nlri-unicast'" { 1648 description 1649 "This augment is valid only for IPv4 unicast."; 1650 } 1651 description 1652 "This augment defines the content of IPv4 unicast routes."; 1653 uses route-content; 1654 } 1655 } 1657 1659 8. IPv6 Unicast Routing YANG Module 1661 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1662 actual RFC number and all occurrences of the revision date below with 1663 the date of RFC publication (and remove this note). 1665 file "ietf-ipv6-unicast-routing@2012-10-04.yang" 1667 module ietf-ipv6-unicast-routing { 1669 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1671 prefix "v6ur"; 1673 import ietf-routing { 1674 prefix "rt"; 1675 } 1677 import ietf-inet-types { 1678 prefix "inet"; 1679 } 1681 import ietf-interfaces { 1682 prefix "if"; 1683 } 1685 import ietf-ip { 1686 prefix "ip"; 1687 } 1689 organization 1690 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1692 contact 1693 "WG Web: 1694 WG List: 1696 WG Chair: David Kessens 1697 1699 WG Chair: Juergen Schoenwaelder 1700 1702 Editor: Ladislav Lhotka 1703 1704 "; 1706 description 1707 "This YANG module augments the 'ietf-routing' module with basic 1708 configuration and operational state data for IPv6 unicast 1709 routing. 1711 Copyright (c) 2012 IETF Trust and the persons identified as 1712 authors of the code. All rights reserved. 1714 Redistribution and use in source and binary forms, with or 1715 without modification, is permitted pursuant to, and subject to 1716 the license terms contained in, the Simplified BSD License set 1717 forth in Section 4.c of the IETF Trust's Legal Provisions 1718 Relating to IETF Documents 1719 (http://trustee.ietf.org/license-info). 1721 This version of this YANG module is part of RFC XXXX; see the 1722 RFC itself for full legal notices. 1723 "; 1725 revision 2012-10-04 { 1726 description 1727 "Initial revision."; 1728 reference 1729 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1730 } 1732 /* Groupings */ 1734 grouping route-content { 1735 description 1736 "Specific parameters of IPv6 unicast routes."; 1737 leaf dest-prefix { 1738 type inet:ipv6-prefix; 1739 description 1740 "IPv6 destination prefix."; 1741 } 1742 leaf next-hop { 1743 type inet:ipv6-address; 1744 description 1745 "IPv6 address of the next hop."; 1746 } 1747 } 1749 /* RPC Methods */ 1751 augment "/rt:active-route/rt:input/rt:destination-address" { 1752 when "address-family='ipv6' and safi='nlri-unicast'" { 1753 description 1754 "This augment is valid only for IPv6 unicast."; 1756 } 1757 description 1758 "The 'address' leaf augments the 'rt:destination-address' 1759 parameter of the 'rt:active-route' operation."; 1760 leaf address { 1761 type inet:ipv6-address; 1762 description 1763 "IPv6 destination address."; 1764 } 1765 } 1767 augment "/rt:active-route/rt:output/rt:route" { 1768 when "address-family='ipv6' and safi='nlri-unicast'" { 1769 description 1770 "This augment is valid only for IPv6 unicast."; 1771 } 1772 description 1773 "Contents of the reply to 'rt:active-route' operation."; 1774 uses route-content; 1775 } 1777 /* Data nodes */ 1779 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 1780 when "/if:interfaces/if:interface[name=current()/name]/ip:ipv6/" 1781 + "ip:enabled='true'" { 1782 description 1783 "This augment is only valid for router interfaces with 1784 enabled IPv6."; 1785 } 1786 description 1787 "IPv6-specific parameters of router interfaces."; 1788 container ipv6-router-advertisements { 1789 description 1790 "Parameters of IPv6 Router Advertisements."; 1791 reference 1792 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; 1793 leaf send-advertisements { 1794 type boolean; 1795 default "false"; 1796 description 1797 "A flag indicating whether or not the router sends periodic 1798 Router Advertisements and responds to Router 1799 Solicitations."; 1800 } 1801 leaf max-rtr-adv-interval { 1802 type uint16 { 1803 range "4..1800"; 1805 } 1806 units "seconds"; 1807 default "600"; 1808 description 1809 "The maximum time allowed between sending unsolicited 1810 multicast Router Advertisements from the interface."; 1811 } 1812 leaf min-rtr-adv-interval { 1813 type uint16 { 1814 range "3..1350"; 1815 } 1816 must ". <= 0.75 * ../max-rtr-adv-interval" { 1817 description 1818 "The value must be no greater than 1819 3/4*max-rtr-adv-interval."; 1820 } 1821 units "seconds"; 1822 description 1823 "The minimum time allowed between sending unsolicited 1824 multicast Router Advertisements from the interface. 1826 Must be no greater than 0.75 * max-rtr-adv-interval. 1828 Its default value is dynamic: 1830 - if max-rtr-adv-interval >= 9 seconds, the default value 1831 is 0.33 * max-rtr-adv-interval; 1833 - otherwise it is 0.75 * max-rtr-adv-interval. 1834 "; 1835 } 1836 leaf managed-flag { 1837 type boolean; 1838 default "false"; 1839 description 1840 "The boolean value to be placed in the 'Managed address 1841 configuration' flag field in the Router Advertisement."; 1842 } 1843 leaf other-config-flag { 1844 type boolean; 1845 default "false"; 1846 description 1847 "The boolean value to be placed in the 'Other 1848 configuration' flag field in the Router Advertisement."; 1849 } 1850 leaf link-mtu { 1851 type uint32; 1852 default "0"; 1853 description 1854 "The value to be placed in MTU options sent by the router. 1855 A value of zero indicates that no MTU options are sent."; 1856 } 1857 leaf reachable-time { 1858 type uint32 { 1859 range "0..3600000"; 1860 } 1861 units "milliseconds"; 1862 default "0"; 1863 description 1864 "The value to be placed in the Reachable Time field in the 1865 Router Advertisement messages sent by the router. The 1866 value zero means unspecified (by this router)."; 1867 } 1868 leaf retrans-timer { 1869 type uint32; 1870 units "milliseconds"; 1871 default "0"; 1872 description 1873 "The value to be placed in the Retrans Timer field in the 1874 Router Advertisement messages sent by the router. The 1875 value zero means unspecified (by this router)."; 1876 } 1877 leaf cur-hop-limit { 1878 type uint8; 1879 default "64"; 1880 description 1881 "The default value to be placed in the Cur Hop Limit field 1882 in the Router Advertisement messages sent by the router. 1883 The value should be set to the current diameter of the 1884 Internet. The value zero means unspecified (by this 1885 router). 1887 The default should be set to the value specified in IANA 1888 Assigned Numbers that was in effect at the time of 1889 implementation. 1890 "; 1891 reference 1892 "IANA: IP Parameters, 1893 http://www.iana.org/assignments/ip-parameters"; 1894 } 1895 leaf default-lifetime { 1896 type uint16 { 1897 range "0..9000"; 1898 } 1899 units "seconds"; 1900 description 1901 "The value to be placed in the Router Lifetime field of 1902 Router Advertisements sent from the interface, in seconds. 1903 MUST be either zero or between max-rtr-adv-interval and 1904 9000 seconds. A value of zero indicates that the router is 1905 not to be used as a default router. These limits may be 1906 overridden by specific documents that describe how IPv6 1907 operates over different link layers. 1909 The default value is dynamic and should be set to 3 * 1910 max-rtr-adv-interval. 1911 "; 1912 } 1913 container prefix-list { 1914 description 1915 "A list of prefixes to be placed in Prefix Information 1916 options in Router Advertisement messages sent from the 1917 interface. 1919 By default, all prefixes that the router advertises via 1920 routing protocols as being on-link for the interface from 1921 which the advertisement is sent. The link-local prefix 1922 should not be included in the list of advertised prefixes. 1923 "; 1924 list prefix { 1925 key "prefix-spec"; 1926 description 1927 "Advertised prefix entry."; 1928 leaf prefix-spec { 1929 type inet:ipv6-prefix; 1930 description 1931 "IPv6 address prefix."; 1932 } 1933 choice control-adv-prefixes { 1934 default "advertise"; 1935 description 1936 "The prefix either may be explicitly removed from the 1937 set of advertised prefixes, or parameters with which 1938 it is advertised may be specified (default case)."; 1939 leaf no-advertise { 1940 type empty; 1941 description 1942 "The prefix will not be advertised. 1944 This may be used for removing the prefix from the 1945 default set of advertised prefixes. 1946 "; 1947 } 1948 case advertise { 1949 leaf valid-lifetime { 1950 type uint32; 1951 units "seconds"; 1952 default "2592000"; 1953 description 1954 "The value to be placed in the Valid Lifetime in 1955 the Prefix Information option, in seconds. The 1956 designated value of all 1's (0xffffffff) 1957 represents infinity. 1958 "; 1959 } 1960 leaf on-link-flag { 1961 type boolean; 1962 default "true"; 1963 description 1964 "The value to be placed in the on-link flag 1965 ('L-bit') field in the Prefix Information 1966 option."; 1967 } 1968 leaf preferred-lifetime { 1969 type uint32; 1970 units "seconds"; 1971 must ". <= ../valid-lifetime" { 1972 description 1973 "This value must not be larger than 1974 valid-lifetime."; 1975 } 1976 default "604800"; 1977 description 1978 "The value to be placed in the Preferred Lifetime 1979 in the Prefix Information option, in seconds. The 1980 designated value of all 1's (0xffffffff) 1981 represents infinity. 1982 "; 1983 } 1984 leaf autonomous-flag { 1985 type boolean; 1986 default "true"; 1987 description 1988 "The value to be placed in the Autonomous Flag 1989 field in the Prefix Information option."; 1990 } 1991 } 1992 } 1993 } 1994 } 1995 } 1996 } 1997 augment "/rt:routing/rt:router/rt:routing-protocols/" 1998 + "rt:routing-protocol/rt:static-routes" { 1999 description 2000 "This augment defines the configuration of the 'static' 2001 pseudo-protocol with data specific for IPv6 unicast."; 2002 container ipv6 { 2003 description 2004 "Configuration of a 'static' pseudo-protocol instance 2005 consists of a list of routes."; 2006 list route { 2007 key "id"; 2008 ordered-by "user"; 2009 description 2010 "A user-ordered list of static routes."; 2011 leaf id { 2012 type uint32 { 2013 range "1..max"; 2014 } 2015 description 2016 "Numeric identifier of the route. 2018 It is not required that the routes be sorted by their 2019 'id'. 2020 "; 2021 } 2022 leaf description { 2023 type string; 2024 description 2025 "Textual description of the route."; 2026 } 2027 uses rt:route-content; 2028 uses route-content { 2029 refine "dest-prefix" { 2030 mandatory "true"; 2031 } 2032 } 2033 } 2034 } 2035 } 2037 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 2038 + "rt:route" { 2039 when "../../rt:address-family='ipv6' and " 2040 + "../../rt:safi='nlri-unicast'" { 2041 description 2042 "This augment is valid only for IPv6 unicast."; 2043 } 2044 description 2045 "This augment defines the content of IPv6 unicast routes."; 2046 uses route-content; 2047 } 2048 } 2050 2052 9. IANA Considerations 2054 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2055 actual RFC number (and remove this note). 2057 This document registers the following namespace URIs in the IETF XML 2058 registry [RFC3688]: 2060 ---------------------------------------------------------- 2061 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2063 Registrant Contact: The IESG. 2065 XML: N/A, the requested URI is an XML namespace. 2066 ---------------------------------------------------------- 2068 ---------------------------------------------------------- 2069 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2071 Registrant Contact: The IESG. 2073 XML: N/A, the requested URI is an XML namespace. 2074 ---------------------------------------------------------- 2076 ---------------------------------------------------------- 2077 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2079 Registrant Contact: The IESG. 2081 XML: N/A, the requested URI is an XML namespace. 2082 ---------------------------------------------------------- 2084 This document registers the following YANG modules in the YANG Module 2085 Names registry [RFC6020]: 2087 ------------------------------------------------------------------- 2088 name: ietf-routing 2089 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2090 prefix: rt 2091 reference: RFC XXXX 2092 ------------------------------------------------------------------- 2094 ------------------------------------------------------------------- 2095 name: ietf-ipv4-unicast-routing 2096 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2097 prefix: v4ur 2098 reference: RFC XXXX 2099 ------------------------------------------------------------------- 2101 ------------------------------------------------------------------- 2102 name: ietf-ipv6-unicast-routing 2103 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2104 prefix: v6ur 2105 reference: RFC XXXX 2106 ------------------------------------------------------------------- 2108 10. Security Considerations 2110 The YANG modules defined in this document are designed to be accessed 2111 via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 2112 secure transport layer and the mandatory-to-implement secure 2113 transport is SSH [RFC6242]. 2115 A number of data nodes defined in the YANG modules are writable/ 2116 creatable/deletable (i.e., "config true" in YANG terms, which is the 2117 default). These data nodes may be considered sensitive or vulnerable 2118 in some network environments. Write operations to these data nodes, 2119 such as "edit-config", can have negative effects on the network if 2120 the protocol operations are not properly protected. 2122 The vulnerable "config true" subtrees and data nodes are the 2123 following: 2125 /rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a 2126 network layer interface to a router instance and may also specify 2127 interface parameters related to routing. 2129 /rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This 2130 list specifies the routing protocols configured on a device. 2132 /rt:routing/rt:route-filters/rt:route-filter This list specifies the 2133 configured route filters which represent administrative policies 2134 for redistributing and modifying routing information. 2136 Unauthorized access to any of these lists can adversely affect the 2137 routing subsystem of both the local device and the network. This may 2138 lead to network malfunctions, delivery of packets to inappropriate 2139 destinations and other problems. 2141 11. Acknowledgments 2143 The author wishes to thank Martin Bjorklund, Joel Halpern, 2144 Wes Hardaker, Andrew McGregor, Thomas Morin, Tom Petch, 2145 Juergen Schoenwaelder, Phil Shafer, Dave Thaler and Yi Yang for their 2146 helpful comments and suggestions. 2148 12. References 2150 12.1. Normative References 2152 [IANA-IF-AF] 2153 Bjorklund, M., "IANA Interface Type and Address Family 2154 YANG Modules", draft-ietf-netmod-iana-if-type-04 (work in 2155 progress), June 2012. 2157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2158 Requirement Levels", BCP 14, RFC 2119, March 1997. 2160 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2161 January 2004. 2163 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2164 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2165 September 2007. 2167 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2168 Network Configuration Protocol (NETCONF)", RFC 6020, 2169 September 2010. 2171 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 2172 RFC 6021, September 2010. 2174 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2175 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2176 June 2011. 2178 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2179 Configuration", draft-ietf-netmod-interfaces-cfg-06 (work 2180 in progress), September 2012. 2182 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 2183 draft-ietf-netmod-ip-cfg-06 (work in progress), 2184 September 2012. 2186 12.2. Informative References 2188 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2189 Data Model Documents", RFC 6087, January 2011. 2191 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2192 Shell (SSH)", RFC 6242, June 2011. 2194 Appendix A. Example: Adding a New Routing Protocol 2196 This appendix demonstrates how the core routing data model can be 2197 extended to support a new routing protocol. The YANG module 2198 "example-rip" shown below is intended only as an illustration rather 2199 than a real definition of a data model for the RIP routing protocol. 2200 For the sake of brevity, we do not follow all the guidelines 2201 specified in [RFC6087]. See also Section 4.4.2. 2203 file "example-rip@2012-10-04.yang" 2205 module example-rip { 2207 namespace "http://example.com/rip"; 2209 prefix "rip"; 2211 import ietf-routing { 2212 prefix "rt"; 2213 } 2215 identity rip { 2216 base rt:routing-protocol; 2217 description 2218 "Identity for the RIP routing protocol."; 2219 } 2221 typedef rip-metric { 2222 type uint8 { 2223 range "0..16"; 2224 } 2225 } 2227 grouping route-content { 2228 description 2229 "RIP-specific route content."; 2230 leaf metric { 2231 type rip-metric; 2232 } 2233 leaf tag { 2234 type uint16; 2235 default "0"; 2236 description 2237 "This leaf may be used to carry additional info, e.g. AS 2238 number."; 2239 } 2240 } 2241 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 2242 + "rt:route" { 2243 description 2244 "RIP-specific route components."; 2245 uses route-content; 2246 } 2248 augment "/rt:active-route/rt:output/rt:route" { 2249 description 2250 "Add RIP-specific route content."; 2251 uses route-content; 2252 } 2254 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 2255 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 2256 + "'rip:rip'"; 2257 container rip { 2258 description 2259 "Per-interface RIP configuration."; 2260 leaf enabled { 2261 type boolean; 2262 default "true"; 2263 } 2264 leaf metric { 2265 type rip-metric; 2266 default "1"; 2267 } 2268 } 2269 } 2271 augment "/rt:routing/rt:router/rt:routing-protocols/" 2272 + "rt:routing-protocol" { 2273 when "rt:type = 'rip:rip'"; 2274 container rip { 2275 leaf update-interval { 2276 type uint8 { 2277 range "10..60"; 2278 } 2279 units "seconds"; 2280 default "30"; 2281 description 2282 "Time interval between periodic updates."; 2283 } 2284 } 2285 } 2286 } 2288 2290 Appendix B. Example: NETCONF Reply 2292 This section contains a sample reply to the NETCONF message, 2293 which could be sent by a server supporting (i.e., advertising them in 2294 the NETCONF message) the following YANG modules: 2296 o ietf-interfaces [YANG-IF], 2298 o ietf-ip [YANG-IP], 2300 o ietf-routing (Section 6), 2302 o ietf-ipv4-unicast-routing (Section 7), 2304 o ietf-ipv6-unicast-routing (Section 8). 2306 We assume a simple network setup as shown in Figure 3: router "A" 2307 uses static default routes with the "ISP" router as the next hop. 2308 IPv6 router advertisements are configured only on the "eth1" 2309 interface and disabled on the upstream "eth0" interface. 2311 +-----------------+ 2312 | | 2313 | Router ISP | 2314 | | 2315 +--------+--------+ 2316 |2001:db8:0:1::2 2317 |192.0.2.2 2318 | 2319 | 2320 |2001:db8:0:1::1 2321 eth0|192.0.2.1 2322 +--------+--------+ 2323 | | 2324 | Router A | 2325 | | 2326 +--------+--------+ 2327 eth1|198.51.100.1 2328 |2001:db8:0:2::1 2329 | 2331 Figure 3: Example network configuration 2333 A reply to the NETCONF message sent by router "A" would then be 2334 as follows: 2336 2337 2345 2346 2347 2348 eth0 2349 ethernetCsmacd 2350 05:00.0 2351 2352 2353 192.0.2.1 2354 24 2355 2356 2357 2358 2359 2001:0db8:0:1::1 2360 64 2361 2362 2363 false 2364 2365 2366 2367 2368 eth1 2369 ethernetCsmacd 2370 05:00.1 2371 2372 2373 198.51.100.1 2374 24 2375 2376 2377 2378 2379 2001:0db8:0:2::1 2380 64 2381 2382 2383 false 2384 2385 2387 2388 2389 2390 2391 rtr0 2392 192.0.2.1 2393 Router A 2394 2395 2396 ipv4 2397 nlri-unicast 2398 ipv4-unicast 2399 2400 2401 ipv6 2402 nlri-unicast 2403 ipv6-unicast 2404 2405 2406 2407 2408 eth0 2409 2410 2411 eth1 2412 2413 true 2414 2415 2416 2001:db8:0:2::/64 2417 2418 2419 2420 2421 2422 2423 2424 direct 2425 rt:direct 2426 2427 2428 st0 2429 2430 Static routing is used for the internal network. 2431 2432 rt:static 2433 2434 2435 2436 1 2437 0.0.0.0/0 2438 192.0.2.2 2439 2440 2441 2442 2443 1 2444 ::/0 2445 2001:db8:0:1::2 2446 2447 2448 2449 2450 2451 ipv4-unicast 2452 2453 2454 ipv6-unicast 2455 2456 2457 2458 2459 2460 2461 2462 ipv4-unicast 2463 ipv4 2464 nlri-unicast 2465 2466 2467 192.0.2.1/24 2468 eth0 2469 direct 2470 2012-10-02T17:11:27+01:00 2471 2472 2473 198.51.100.0/24 2474 eth1 2475 direct 2476 2012-10-02T17:11:27+01:00 2477 2478 2479 0.0.0.0/0 2480 st0 2481 192.0.2.2 2482 2012-10-02T18:02:45+01:00 2484 2485 2486 2487 2488 ipv6-unicast 2489 ipv6 2490 nlri-unicast 2491 2492 2493 2001:db8:0:1::/64 2494 eth0 2495 direct 2496 2012-10-02T17:11:27+01:00 2497 2498 2499 2001:db8:0:2::/64 2500 eth1 2501 direct 2502 2012-10-02T17:11:27+01:00 2503 2504 2505 ::/0 2506 2001:db8:0:1::2 2507 st0 2508 2012-10-02T18:02:45+01:00 2509 2510 2511 2512 2513 2514 2515 2517 Appendix C. Change Log 2519 RFC Editor: remove this section upon publication as an RFC. 2521 C.1. Changes Between Versions -04 and -05 2523 o Routing tables are now global, i.e., "routing-tables" is a child 2524 of "routing" rather than "router". 2526 o "must" statement for "static-routes" changed to "when". 2528 o Added "main-routing-tables" containing references to main routing 2529 tables for each address family. 2531 o Removed the defaults for "address-family" and "safi" and made them 2532 mandatory. 2534 o Removed the default for route-filter/type and made this leaf 2535 mandatory. 2537 o If there is no active route for a given destination, the "active- 2538 route" RPC returns no output. 2540 o Added "enabled" switch under "routing-protocol". 2542 o Added "router-type" identity and "type" leaf under "router". 2544 o Route attribute "age" changed to "last-updated", its type is 2545 "yang:date-and-time". 2547 o The "direct" pseudo-protocol is always connected to main routing 2548 tables. 2550 o Entries in the list of connected routing tables renamed from 2551 "routing-table" to "connected-routing-table". 2553 o Added "must" constraint saying that a routing table must not be 2554 its own recipient. 2556 C.2. Changes Between Versions -03 and -04 2558 o Changed "error-tag" for both RPC methods from "missing element" to 2559 "data-missing". 2561 o Removed the decrementing behavior for advertised IPv6 prefix 2562 parameters "valid-lifetime" and "preferred-lifetime". 2564 o Changed the key of the static route lists from "seqno" to "id" 2565 because the routes needn't be sorted. 2567 o Added 'must' constraint saying that "preferred-lifetime" must not 2568 be greater than "valid-lifetime". 2570 C.3. Changes Between Versions -02 and -03 2572 o Module "iana-afn-safi" moved to I-D "iana-if-type". 2574 o Removed forwarding table. 2576 o RPC "get-route" changed to "active-route". Its output is a list 2577 of routes (for multi-path routing). 2579 o New RPC "route-count". 2581 o For both RPCs, specification of negative responses was added. 2583 o Relaxed separation of router instances. 2585 o Assignment of interfaces to router instances needn't be disjoint. 2587 o Route filters are now global. 2589 o Added "allow-all-route-filter" for symmetry. 2591 o Added Section 5 about interactions with "ietf-interfaces" and 2592 "ietf-ip". 2594 o Added "router-id" leaf. 2596 o Specified the names for IPv4/IPv6 unicast main routing tables. 2598 o Route parameter "last-modified" changed to "age". 2600 o Added container "recipient-routing-tables". 2602 C.4. Changes Between Versions -01 and -02 2604 o Added module "ietf-ipv6-unicast-routing". 2606 o The example in Appendix B now uses IP addresses from blocks 2607 reserved for documentation. 2609 o Direct routes appear by default in the forwarding table. 2611 o Network layer interfaces must be assigned to a router instance. 2612 Additional interface configuration may be present. 2614 o The "when" statement is only used with "augment", "must" is used 2615 elsewhere. 2617 o Additional "must" statements were added. 2619 o The "route-content" grouping for IPv4 and IPv6 unicast now 2620 includes the material from the "ietf-routing" version via "uses 2621 rt:route-content". 2623 o Explanation of symbols in the tree representation of data model 2624 hierarchy. 2626 C.5. Changes Between Versions -00 and -01 2628 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2630 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2631 safi" module. 2633 o Names of some data nodes were changed, in particular "routing- 2634 process" is now "router". 2636 o The restriction of a single AFN/SAFI per router was lifted. 2638 o RPC operation "delete-route" was removed. 2640 o Illegal XPath references from "get-route" to the datastore were 2641 fixed. 2643 o Section "Security Considerations" was written. 2645 Author's Address 2647 Ladislav Lhotka 2648 CZ.NIC 2650 Email: lhotka@nic.cz