idnits 2.17.1 draft-ietf-netmod-routing-cfg-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2173 has weird spacing: '...-family ian...' -- The document date (February 11, 2013) is 4063 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-netmod-iana-if-type-04 == Outdated reference: A later version (-03) exists of draft-ietf-netmod-rfc6021-bis-00 == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-09 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-ip-cfg-09 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 0 errors (**), 0 flaws (~~), 6 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 February 11, 2013 5 Expires: August 15, 2013 7 A YANG Data Model for Routing Management 8 draft-ietf-netmod-routing-cfg-08 10 Abstract 12 This document contains a specification of three YANG modules. 13 Together they form the core routing data model which serves as a 14 framework for configuring and managing a routing subsystem. It is 15 expected that these modules will be augmented by additional YANG 16 modules defining data models for individual routing protocols and 17 other related functions. The core routing data model provides common 18 building blocks for such extensions - router instances, routes, 19 routing tables, routing protocols and route filters. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 15, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 57 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 58 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 60 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. The Design of the Core Routing Data Model . . . . . . . . . . 8 62 4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 11 64 4.2. Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 13 66 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 15 67 4.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 15 68 4.4.2. Defining New Routing Protocols . . . . . . . . . . . . 16 69 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 17 70 4.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 18 71 5. Interactions with Other YANG Modules . . . . . . . . . . . . . 19 72 5.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 19 73 5.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 19 74 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 21 75 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 35 76 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 39 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 53 83 Appendix A. The Complete Data Tree . . . . . . . . . . . . . . . 54 84 Appendix B. Example: Adding a New Routing Protocol . . . . . . . 56 85 Appendix C. Example: NETCONF Reply . . . . . . . . . . . . 59 86 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 64 87 D.1. Changes Between Versions -07 and -08 . . . . . . . . . . . 64 88 D.2. Changes Between Versions -06 and -07 . . . . . . . . . . . 64 89 D.3. Changes Between Versions -05 and -06 . . . . . . . . . . . 64 90 D.4. Changes Between Versions -04 and -05 . . . . . . . . . . . 65 91 D.5. Changes Between Versions -03 and -04 . . . . . . . . . . . 65 92 D.6. Changes Between Versions -02 and -03 . . . . . . . . . . . 66 93 D.7. Changes Between Versions -01 and -02 . . . . . . . . . . . 66 94 D.8. Changes Between Versions -00 and -01 . . . . . . . . . . . 67 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 68 97 1. Introduction 99 This document contains a specification of the following YANG modules: 101 o Module "ietf-routing" provides generic components of a routing 102 data model. 104 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 105 module with additional data specific to IPv4 unicast. 107 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 108 module with additional data specific to IPv6 unicast, including 109 the router configuration variables required by [RFC4861]. 111 These modules together define the so-called core routing data model, 112 which is proposed as a basis for the development of data models for 113 configuration and management of more sophisticated routing systems. 114 While these three modules can be directly used for simple IP devices 115 with static routing, their main purpose is to provide essential 116 building blocks for more complicated setups involving multiple 117 routing protocols, multicast routing, additional address families, 118 and advanced functions such as route filtering or policy routing. To 119 this end, it is expected that the core routing data model will be 120 augmented by numerous modules developed by other IETF working groups. 122 2. Terminology and Notation 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 The following terms are defined in [RFC6241]: 130 o client 132 o message 134 o protocol operation 136 o server 138 The following terms are defined in [RFC6020]: 140 o augment 142 o configuration data 144 o data model 146 o data node 148 o mandatory node 150 o module 152 o state data 154 o RPC operation 156 2.1. Glossary of New Terms 158 active route: a route which is actually used for sending packets. 159 If there are multiple candidate routes with a matching destination 160 prefix, then it is up to the routing algorithm to select the 161 active route (or several active routes in the case of multi-path 162 routing). 164 core routing data model: YANG data model resulting from the 165 combination of "ietf-routing", "ietf-ipv4-unicast-routing" and 166 "ietf-ipv6-unicast-routing" modules. 168 direct route: a route to a directly connected network. 170 2.2. Tree Diagrams 172 A simplified graphical representation of the complete data tree is 173 presented in Appendix A, and similar diagrams of its various subtrees 174 appear in the main text. The meaning of the symbols in these 175 diagrams is as follows: 177 o Brackets "[" and "]" enclose list keys. 179 o Abbreviations before data node names: "rw" means configuration 180 (read-write) and "ro" state data (read-only). 182 o Symbols after data node names: "?" means an optional node and "*" 183 denotes a "leaf-list". 185 o Parentheses enclose choice and case nodes, and case nodes are also 186 marked with a colon (":"). 188 o Ellipsis ("...") stands for contents of subtrees that are not 189 shown. 191 2.3. Prefixes in Data Node Names 193 In this document, names of data nodes, RPC methods and other data 194 model objects are used mostly without a prefix, as long as it is 195 clear from the context in which YANG module each name is defined. 196 Otherwise, names are prefixed using the standard prefix associated 197 with the corresponding YANG module, as shown in Table 1. 199 +--------+---------------------------+--------------+ 200 | Prefix | YANG module | Reference | 201 +--------+---------------------------+--------------+ 202 | ianaaf | iana-afn-safi | [IANA-IF-AF] | 203 | | | | 204 | if | ietf-interfaces | [YANG-IF] | 205 | | | | 206 | ip | ietf-ip | [YANG-IP] | 207 | | | | 208 | rt | ietf-routing | Section 6 | 209 | | | | 210 | v4ur | ietf-ipv4-unicast-routing | Section 7 | 211 | | | | 212 | v6ur | ietf-ipv6-unicast-routing | Section 8 | 213 | | | | 214 | yang | ietf-yang-types | [RFC6021bis] | 215 | | | | 216 | inet | ietf-inet-types | [RFC6021bis] | 217 +--------+---------------------------+--------------+ 219 Table 1: Prefixes and corresponding YANG modules 221 3. Objectives 223 The initial design of the core routing data model was driven by the 224 following objectives: 226 o The data model should be suitable for the common address families, 227 in particular IPv4 and IPv6, and for unicast and multicast 228 routing, as well as Multiprotocol Label Switching (MPLS). 230 o Simple routing setups, such as static routing, should be 231 configurable in a simple way, ideally without any need to develop 232 additional YANG modules. 234 o On the other hand, the core routing framework must allow for 235 complicated setups involving multiple routing tables and multiple 236 routing protocols, as well as controlled redistributions of 237 routing information. 239 o Device vendors will want to map the data models built on this 240 generic framework to their proprietary data models and 241 configuration interfaces. Therefore, the framework should be 242 flexible enough to facilitate such a mapping and accommodate data 243 models with different logic. 245 4. The Design of the Core Routing Data Model 247 The core routing data model consists of three YANG modules. The 248 first module, "ietf-routing", defines the generic components of a 249 routing system. The other two modules, "ietf-ipv4-unicast-routing" 250 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 251 with additional data nodes that are needed for IPv4 and IPv6 unicast 252 routing, respectively. An abridged view of the data hierarchy is 253 given in Figure 1. See Appendix A for the complete data tree. 255 +--rw routing 256 +--rw router [name] 257 | +--rw name 258 | +--rw type? 259 | +--rw enabled? 260 | +--rw router-id? 261 | +--rw description? 262 | +--rw main-routing-tables 263 | | +--rw main-routing-table [address-family safi] 264 | | +--rw address-family 265 | | +--rw safi 266 | | +--rw name? 267 | +--rw interfaces 268 | | +--rw interface [name] 269 | | +--rw name 270 | | +--rw v6ur:ipv6-router-advertisements 271 | | ... 272 | +--rw routing-protocols 273 | +--rw routing-protocol [name] 274 | +--rw name 275 | +--rw description? 276 | +--rw enabled? 277 | +--rw type 278 | +--rw connected-routing-tables 279 | | ... 280 | +--rw static-routes 281 | ... 282 +--rw routing-tables 283 | +--rw routing-table [name] 284 | +--rw name 285 | +--rw address-family 286 | +--rw safi 287 | +--rw description? 288 | +--ro routes 289 | | +--ro route 290 | | ... 291 | +--rw recipient-routing-tables 292 | +--rw recipient-routing-table [name] 293 | ... 294 +--rw route-filters 295 +--rw route-filter [name] 296 +--rw name 297 +--rw description? 298 +--rw type 300 Figure 1: Data hierarchy of the core routing data model. 302 As can be seen from Figure 1, the core routing data model introduces 303 several generic components of a routing framework: routers, routing 304 tables containing lists of routes, routing protocols and route 305 filters. The following subsections describe these components in more 306 detail. 308 By combining the components in various ways, and possibly augmenting 309 them with appropriate contents defined in other modules, various 310 routing setups can be realized. 312 +--------+ 313 | direct | +---+ +--------------+ +---+ +--------------+ 314 | routes |--->| F |--->| |<---| F |<---| | 315 +--------+ +---+ | main | +---+ | additional | 316 | routing | | routing | 317 +--------+ +---+ | table | +---+ | table | 318 | static |--->| F |--->| |--->| F |--->| | 319 | routes | +---+ +--------------+ +---+ +--------------+ 320 +--------+ ^ | ^ | 321 | v | v 322 +---+ +---+ +---+ +---+ 323 | F | | F | | F | | F | 324 +---+ +---+ +---+ +---+ 325 ^ | ^ | 326 | v | v 327 +----------+ +----------+ 328 | routing | | routing | 329 | protocol | | protocol | 330 +----------+ +----------+ 332 Figure 2: Example setup of a routing system 334 The example in Figure 2 shows a typical (though certainly not the 335 only possible) organization of a more complex routing subsystem for a 336 single address family. Several of its features are worth mentioning: 338 o Along with the main routing table, which must always be present, 339 an additional routing table is configured. 341 o Each routing protocol instance, including the "static" and 342 "direct" pseudo-protocols, is connected to one routing table with 343 which it can exchange routes (in both directions, except for the 344 "static" and "direct" pseudo-protocols). 346 o Routing tables may also be connected to each other and exchange 347 routes in either direction (or both). 349 o Route exchanges along all connections may be controlled by means 350 of route filters, denoted by "F" in Figure 2. 352 4.1. Router 354 Each router instance in the core routing data model represents a 355 logical router. The exact semantics of this term is left to 356 implementations. For example, router instances may be completely 357 isolated virtual routers or, alternatively, they may internally share 358 certain information. 360 An implementation MAY support multiple types of logical routers 361 simultaneously. Instances of all router types are organized as 362 entries of the same flat "router" list. In order to discriminate 363 router instances belonging to different types, the "type" leaf is 364 defined as a child of the "router" node. 366 An implementation MAY pose restrictions on allowed router types and 367 on the number of supported instances for each type. For example, a 368 simple router implementation may support only one router instance of 369 the default type "standard-router". 371 Each network layer interface has to be assigned to one or more router 372 instances in order to be able to participate in packet forwarding, 373 routing protocols and other operations of those router instances. 374 The assignment is accomplished by creating a corresponding entry in 375 the list of router interfaces ("rt:interface"). The key of the list 376 entry MUST be the name of a configured network layer interface, i.e., 377 the value of a node /if:interfaces/if:interface/if:name defined in 378 the "ietf-interfaces" module [YANG-IF]. 380 In YANG terms, the list of router interfaces is modeled as the "list" 381 node rather than "leaf-list" in order to allow for adding, via 382 augmentation, other configuration or state data related to the 383 corresponding router interface. 385 Implementations MAY specify additional rules for the assignment of 386 interfaces to logical routers. For example, it may be required that 387 the sets of interfaces assigned to different logical routers be 388 disjoint. 390 4.1.1. Configuration of IPv6 Router Interfaces 392 The module "ietf-ipv6-unicast-routing" augments the definition of the 393 data node "rt:interface" with definitions of the following 394 configuration variables as required by [RFC4861], sec. 6.2.1: 396 o send-advertisements, 398 o max-rtr-adv-interval, 399 o min-rtr-adv-interval, 401 o managed-flag, 403 o other-config-flag, 405 o link-mtu, 407 o reachable-time, 409 o retrans-timer, 411 o cur-hop-limit, 413 o default-lifetime, 415 o prefix-list: a list of prefixes to be advertised. 417 The following parameters are associated with each prefix in the 418 list: 420 * valid-lifetime, 422 * on-link-flag, 424 * preferred-lifetime, 426 * autonomous-flag. 428 The definitions and descriptions of the above parameters can be found 429 in the text of the module "ietf-ipv6-unicast-routing" (Section 8). 431 NOTES: 433 1. The "IsRouter" flag, which is also required by [RFC4861], is 434 implemented in the "ietf-ip" module [YANG-IP] (leaf "ip: 435 forwarding"). 437 2. The original specification [RFC4861] allows the implementations 438 to decide whether the "valid-lifetime" and "preferred-lifetime" 439 parameters remain the same in consecutive advertisements, or 440 decrement in real time. However, the latter behavior seems 441 problematic because the values might be reset again to the 442 (higher) configured values after a configuration is reloaded. 443 Moreover, no implementation is known to use the decrementing 444 behavior. The "ietf-ipv6-unicast-routing" module therefore 445 assumes the former behavior with constant values. 447 4.2. Routes 449 Routes are basic elements of information in a routing system. The 450 core routing data model defines only the following minimal set of 451 route attributes: 453 o "dest-prefix": IP prefix specifying the set of destination 454 addresses for which the route may be used. This attribute is 455 mandatory. 457 o "next-hop": IP address of an adjacent router or host to which 458 packets with destination addresses belonging to "dest-prefix" 459 should be sent. 461 o "outgoing-interface": network interface that should be used for 462 sending packets with destination addresses belonging to "dest- 463 prefix". 465 The above list of route attributes suffices for a simple static 466 routing configuration. It is expected that future modules defining 467 routing protocols will add other route attributes such as metrics or 468 preferences. 470 Routes and their attributes are used both in configuration data, for 471 example as manually configured static routes, and in state data, for 472 example as entries in routing tables. 474 4.3. Routing Tables 476 Routing tables are lists of routes complemented with administrative 477 data, namely: 479 o "source-protocol": name of the routing protocol from which the 480 route was originally obtained. 482 o "last-updated": the date and time when the route was last updated, 483 or inserted into the routing table. 485 Each routing table must contain only routes of the same address 486 family. Address family information consists of two parameters - 487 "address-family" and "safi" (Subsequent Address Family Identifier, 488 SAFI). The permitted values for these two parameters are defined by 489 IANA and represented using YANG enumeration types "ianaaf:address- 490 family" and "ianaaf:subsequent-address-family" [IANA-IF-AF]. 492 In the core routing data model, the "routing-table" node represents 493 configuration while the descendant list of routes is defined as state 494 data. The contents of route lists are controlled and manipulated by 495 routing protocol operations which may result in route additions, 496 removals and modifications. This also includes manipulations via the 497 "static" and/or "direct" pseudo-protocols, see Section 4.4.1. 499 In order to activate an address family for use within a router 500 instance, a client configures an entry of the list /routing/router/ 501 main-routing-tables/main-routing-table. This entry contains a 502 reference to a routing table which henceforth serves as the so-called 503 main routing table for the router instance and address family. 504 Section 4.4 explains the role of main routing tables. 506 Routing tables are global, which means that a configured routing 507 table may be used by any or all router instances. 509 Server implementations MAY pose restrictions regarding the number of 510 supported routing tables, and rules for configuration and use of 511 routing tables. For example: 513 o A server may support no more than one routing table per address 514 family. 516 o Router instances (of a certain type) may not be allowed to share 517 routing tables, i.e., each routing table is used by no more than 518 one router instance. 520 For servers supporting multiple routing tables per address family, 521 additional tables can be configured by creating new entries in the 522 "routing-table" list, either as a part of factory-default 523 configuration, or by a client's action. 525 The way how a routing system uses information from routing tables for 526 actual packet forwarding is outside the scope of this document. 528 Every routing table can serve as a source of routes for other routing 529 tables. To achieve this, one or more recipient routing tables may be 530 specified in the configuration of the source routing table. 531 Optionally, a route filter may be configured for any or all recipient 532 routing tables. Such a route filter then selects and/or manipulates 533 the routes that are passed between the source and recipient routing 534 table. 536 A routing table MUST NOT appear among its own recipient routing 537 tables. A recipient routing table also MUST be of the same address 538 family as its source routing table. 540 4.4. Routing Protocols 542 The core routing data model provides an open-ended framework for 543 defining multiple routing protocol instances within each router 544 instance. Each routing protocol instance MUST be assigned a type, 545 which is an identity derived from the "rt:routing-protocol" base 546 identity. The core routing data model defines two identities for the 547 direct and static pseudo-protocols (Section 4.4.1). 549 Each routing protocol instance is connected to exactly one routing 550 table for each address family that the routing protocol instance 551 supports. Routes learned from the network by a routing protocol are 552 normally installed into the connected routing table(s) and, 553 conversely, routes from the connected routing table(s) are normally 554 injected into the routing protocol. However, routing protocol 555 implementations MAY specify rules that restrict this exchange of 556 routes in either direction (or both directions). 558 A routing table is connected to a routing protocol instance by 559 creating a corresponding entry in the "connected-routing-table" list. 560 If such an entry is not configured for an address family, then the 561 main routing table MUST be used as the connected routing table for 562 this address family. 564 In addition, two independent route filters (see Section 4.5) may be 565 configured for each connected routing table to apply client-defined 566 policies controlling the exchange of routes in both directions 567 between the routing protocol instance and the connected routing 568 table: 570 o import filter controls which routes are passed from the routing 571 protocol instance to the connected routing table, 573 o export filter controls which routes the routing protocol instance 574 receives from the connected routing table. 576 Note that the terms import and export are used from the viewpoint of 577 a routing table. 579 4.4.1. Routing Pseudo-Protocols 581 The core routing data model defines two special routing protocol 582 types - "direct" and "static". Both are in fact pseudo-protocols, 583 which means that they are confined to the local device and do not 584 exchange any routing information with neighboring routers. Routes 585 from both "direct" and "static" protocol instances are passed to the 586 connected routing table (subject to route filters, if any), but an 587 exchange in the opposite direction is not allowed. 589 Every router instance MUST implement exactly one instance of the 590 "direct" pseudo-protocol type. The name of this instance MUST also 591 be "direct". It is the source of direct routes for all configured 592 address families. Direct routes are normally supplied by the 593 operating system kernel, based on the configuration of network 594 interface addresses, see Section 5.2. The "direct" pseudo-protocol 595 MUST always be connected to the main routing tables of all supported 596 address families. Unlike other routing protocol types, this 597 connection cannot be changed in the configuration. Direct routes MAY 598 be filtered before they appear in the main routing table. 600 A pseudo-protocol of the type "static" allows for specifying routes 601 manually. It MAY be configured in zero or multiple instances, 602 although a typical configuration will have exactly one instance per 603 logical router. 605 Static routes are configured within the "static-routes" container, 606 see Figure 3. 608 +--rw static-routes 609 +--rw v4ur:ipv4 610 | +--rw v4ur:route [id] 611 | +--rw v4ur:id 612 | +--rw v4ur:description? 613 | +--rw v4ur:outgoing-interface? 614 | +--rw v4ur:dest-prefix 615 | +--rw v4ur:next-hop? 616 +--rw v6ur:ipv6 617 +--rw v6ur:route [id] 618 +--rw v6ur:id 619 +--rw v6ur:description? 620 +--rw v6ur:outgoing-interface? 621 +--rw v6ur:dest-prefix 622 +--rw v6ur:next-hop? 624 Figure 3: Structure of "static-routes" subtree. 626 4.4.2. Defining New Routing Protocols 628 It is expected that future YANG modules will create data models for 629 additional routing protocol types. Such a new module has to define 630 the protocol-specific configuration and state data, and it has to fit 631 it into the core routing framework in the following way: 633 o A new identity MUST be defined for the routing protocol and its 634 base identity MUST be set to "rt:routing-protocol", or to an 635 identity derived from "rt:routing-protocol". 637 o Additional route attributes MAY be defined, preferably in one 638 place by means of defining a YANG grouping. The new attributes 639 have to be inserted as state data by augmenting the definition of 640 the node 642 /rt:routing-tables/rt:routing-table/rt:route, 644 and possibly to other places in the configuration, state data and 645 RPC input or output. 647 o Per-interface configuration parameters can be added by augmenting 648 the data node "rt:interface" (the list of router interfaces). 650 o Other configuration parameters and state data can be defined by 651 augmenting the "routing-protocol" data node. 653 By using the "when" statement, the augmented per-interface and other 654 configuration parameters specific to the new protocol SHOULD be made 655 conditional and valid only if the value of "rt:type" is equal to the 656 new protocol's identity. It is also RECOMMENDED that the protocol- 657 specific data be encapsulated in appropriately named containers. 659 The above steps are implemented by the example YANG module for the 660 RIP routing protocol in Appendix B. 662 4.5. Route Filters 664 The core routing data model provides a skeleton for defining route 665 filters that can be used to restrict the set of routes being 666 exchanged between a routing protocol instance and a connected routing 667 table, or between a source and a recipient routing table. Route 668 filters may also manipulate routes, i.e., add, delete, or modify 669 their attributes. 671 Route filters are global, which means that a configured route filter 672 may be used by any or all router instances. 674 By itself, the route filtering framework defined in this document 675 allows for applying only two extreme routing policies which are 676 represented by the following pre-defined route filter types: 678 o "deny-all-route-filter": all routes are blocked, 680 o "allow-all-route-filter": all routes are permitted. 682 Note that the latter type is equivalent to no route filter. 684 It is expected that more comprehensive route filtering frameworks 685 will be developed separately. 687 Each route filter is identified by a name which MUST be unique within 688 the entire configuration. Its type MUST be specified by the "type" 689 identity reference - this opens the space for multiple route 690 filtering framework implementations. 692 4.6. RPC Operations 694 The "ietf-routing" module defines two RPC operations: 696 o active-route: query the routing system for the active route(s) 697 that are currently used for sending datagrams to a destination 698 host whose address is passed as an input parameter. 700 o route-count: retrieve the total number of entries in a routing 701 table. 703 5. Interactions with Other YANG Modules 705 The semantics of the core routing data model also depend on several 706 configuration parameters that are defined in other YANG modules. 708 5.1. Module "ietf-interfaces" 710 The following boolean switch is defined in the "ietf-interfaces" YANG 711 module [YANG-IF]: 713 /if:interfaces/if:interface/if:enabled 715 If this switch is set to "false" for a given network layer 716 interface, the device MUST behave exactly as if that interface was 717 not assigned to any logical router at all. 719 5.2. Module "ietf-ip" 721 The following boolean switches are defined in the "ietf-ip" YANG 722 module [YANG-IP]: 724 /if:interfaces/if:interface/ip:ipv4/ip:enabled 726 If this switch is set to "false" for a given interface, then all 727 IPv4 routing functions related to that interface MUST be disabled. 729 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 731 If this switch is set to "false" for a given interface, then the 732 forwarding of IPv4 datagrams to and from this interface MUST be 733 disabled. However, the interface may participate in other routing 734 functions, such as routing protocols. 736 /if:interfaces/if:interface/ip:ipv6/ip:enabled 738 If this switch is set to "false" for a given interface, then all 739 IPv6 routing functions related to that interface MUST be disabled. 741 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 743 If this switch is set to "false" for a given interface, then the 744 forwarding of IPv6 datagrams to and from this interface MUST be 745 disabled. However, the interface may participate in other routing 746 functions, such as routing protocols. 748 In addition, the "ietf-ip" module allows for configuring IPv4 and 749 IPv6 addresses and network prefixes or masks on network layer 750 interfaces. Configuration of these parameters on an enabled 751 interface MUST result in an immediate creation of the corresponding 752 direct route. The destination prefix of this route is set according 753 to the configured IP address and network prefix/mask, and the 754 interface is set as the outgoing interface for that route. 756 6. Routing YANG Module 758 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 759 actual RFC number and all occurrences of the revision date below with 760 the date of RFC publication (and remove this note). 762 file "ietf-routing@2013-02-11.yang" 764 module ietf-routing { 766 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 768 prefix "rt"; 770 import ietf-yang-types { 771 prefix "yang"; 772 } 774 import ietf-interfaces { 775 prefix "if"; 776 } 778 import iana-afn-safi { 779 prefix "ianaaf"; 780 } 782 organization 783 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 785 contact 786 "WG Web: 787 WG List: 789 WG Chair: David Kessens 790 792 WG Chair: Juergen Schoenwaelder 793 795 Editor: Ladislav Lhotka 796 797 "; 799 description 800 "This YANG module defines essential components that may be used 801 for configuring a routing subsystem. 803 Copyright (c) 2012 IETF Trust and the persons identified as 804 authors of the code. All rights reserved. 806 Redistribution and use in source and binary forms, with or 807 without modification, is permitted pursuant to, and subject to 808 the license terms contained in, the Simplified BSD License set 809 forth in Section 4.c of the IETF Trust's Legal Provisions 810 Relating to IETF Documents 811 (http://trustee.ietf.org/license-info). 813 This version of this YANG module is part of RFC XXXX; see the 814 RFC itself for full legal notices. 815 "; 817 revision 2013-02-11 { 818 description 819 "Initial revision."; 820 reference 821 "RFC XXXX: A YANG Data Model for Routing Management"; 822 } 824 /* Identities */ 826 identity router-type { 827 description 828 "Base identity from which router type identities are derived. 830 It is primarily intended for discriminating among different 831 types of logical routers or router virtualization. 832 "; 833 } 835 identity standard-router { 836 base router-type; 837 description 838 "This identity represents a standard router."; 839 } 841 identity routing-protocol { 842 description 843 "Base identity from which routing protocol identities are 844 derived."; 845 } 847 identity direct { 848 base routing-protocol; 849 description 850 "Routing pseudo-protocol which provides routes to directly 851 connected networks."; 853 } 855 identity static { 856 base routing-protocol; 857 description 858 "Static routing pseudo-protocol."; 859 } 861 identity route-filter { 862 description 863 "Base identity from which all route filters are derived."; 864 } 866 identity deny-all-route-filter { 867 base route-filter; 868 description 869 "Route filter that blocks all routes."; 870 } 872 identity allow-all-route-filter { 873 base route-filter; 874 description 875 "Route filter that permits all routes."; 876 } 878 /* Type Definitions */ 880 typedef router-ref { 881 type leafref { 882 path "/rt:routing/rt:router/rt:name"; 883 } 884 description 885 "This type is used for leafs that reference a router 886 instance."; 887 } 889 typedef routing-table-ref { 890 type leafref { 891 path "/rt:routing/rt:routing-tables/rt:routing-table/rt:name"; 892 } 893 description 894 "This type is used for leafs that reference a routing table."; 895 } 897 typedef route-filter-ref { 898 type leafref { 899 path "/rt:routing/rt:route-filters/rt:route-filter/rt:name"; 900 } 901 description 902 "This type is used for leafs that reference a route filter."; 903 } 905 /* Groupings */ 907 grouping afn-safi { 908 description 909 "This grouping provides two parameters specifying address 910 family and subsequent address family."; 911 leaf address-family { 912 type ianaaf:address-family; 913 mandatory "true"; 914 description 915 "Address family."; 916 } 917 leaf safi { 918 type ianaaf:subsequent-address-family; 919 mandatory "true"; 920 description 921 "Subsequent address family."; 922 } 923 } 925 grouping route-content { 926 description 927 "Generic parameters of routes."; 928 leaf outgoing-interface { 929 type if:interface-ref; 930 description 931 "Outgoing interface."; 932 } 933 } 935 /* RPC Methods */ 937 rpc active-route { 938 description 939 "Return the active route (or multiple routes, in the case of 940 multi-path routing) to a destination address. 942 Parameters 944 1. 'router-name', 946 2. 'destination-address'. 948 If the router instance with 'router-name' doesn't exist, then 949 this operation SHALL fail with error-tag 'data-missing' and 950 error-app-tag 'router-not-found'. 952 If no active route for 'destination-address' exists, no output 953 is returned - the server SHALL send an containing 954 a single element . 955 "; 956 input { 957 leaf router-name { 958 type router-ref; 959 mandatory "true"; 960 description 961 "Name of the router instance whose forwarding information 962 base is being queried."; 963 } 964 container destination-address { 965 description 966 "Network layer destination address. 968 Address family specific modules MUST augment this 969 container with a leaf named 'address'. 970 "; 971 uses afn-safi; 972 } 973 } 974 output { 975 list route { 976 description 977 "List of active routes. 979 Route contents specific for each address family is 980 expected be defined through augmenting. 981 "; 982 uses afn-safi; 983 uses route-content; 984 } 985 } 986 } 988 rpc route-count { 989 description 990 "Return the current number of routes in a routing table. 992 Parameters: 994 1. 'routing-table-name'. 996 If the routing table with the name specified in 997 'routing-table-name' doesn't exist, then this operation SHALL 998 fail with error-tag 'data-missing' and error-app-tag 999 'routing-table-not-found'. 1000 "; 1001 input { 1002 leaf routing-table { 1003 type routing-table-ref; 1004 mandatory "true"; 1005 description 1006 "Name of the routing table."; 1007 } 1008 } 1009 output { 1010 leaf number-of-routes { 1011 type uint32; 1012 mandatory "true"; 1013 description 1014 "Number of routes in the routing table."; 1015 } 1016 } 1017 } 1019 /* Data Nodes */ 1021 container routing { 1022 description 1023 "Routing parameters."; 1024 list router { 1025 key "name"; 1026 description 1027 "Each list entry is a container for configuration and state 1028 data of a single (logical) router instance. 1029 "; 1030 leaf name { 1031 type string; 1032 description 1033 "An arbitrary name of the router instance."; 1034 } 1035 leaf type { 1036 type identityref { 1037 base router-type; 1038 } 1039 default "rt:standard-router"; 1040 description 1041 "This leaf specifies the router type. 1043 It is primarily intended as a means for discriminating 1044 among different types of logical routers, route 1045 virtualization, master-slave arrangements etc., while 1046 keeping all such router instances in the same flat list. 1047 "; 1048 } 1049 leaf enabled { 1050 type boolean; 1051 default "true"; 1052 description 1053 "Enable/disable the router instance. 1055 If this parameter is false, the parent router instance is 1056 disabled, despite any other configuration that might be 1057 present. 1058 "; 1059 } 1060 leaf router-id { 1061 type yang:dotted-quad; 1062 description 1063 "Global router ID - 32-bit number in the form of a dotted 1064 quad. 1066 An implementation MAY select a value if this parameter is 1067 not configured. 1069 Routing protocols MAY override this global parameter 1070 inside their configuration. 1071 "; 1072 } 1073 leaf description { 1074 type string; 1075 description 1076 "Textual description of the router."; 1077 } 1078 container main-routing-tables { 1079 description 1080 "Main routing tables used by the router instance."; 1081 list main-routing-table { 1082 must "not(address-family!=/routing/routing-tables/" 1083 + "routing-table[name=current()/name]/" 1084 + "address-family or safi!=/routing/routing-tables/" 1085 + "routing-table[name=current()/name]/safi)" { 1086 error-message "Address family mismatch."; 1087 description 1088 "The entry's address family MUST match that of the 1089 referenced routing table."; 1090 } 1091 key "address-family safi"; 1092 description 1093 "Each list entry specifies the main routing table for one 1094 address family. 1096 The main routing table is operationally connected to all 1097 routing protocols for which a connected routing table 1098 has not been explicitly configured. 1100 The 'direct' pseudo-protocol is always connected to the 1101 main routing table. 1103 Address families that don't have their entry in this 1104 list MUST NOT be used in the rest of the router instance 1105 configuration. 1106 "; 1107 uses afn-safi; 1108 leaf name { 1109 type routing-table-ref; 1110 description 1111 "Name of an existing routing table to be used as the 1112 main routing table for the given router instance and 1113 address family."; 1114 } 1115 } 1116 } 1117 container interfaces { 1118 description 1119 "Router interface parameters."; 1120 list interface { 1121 key "name"; 1122 description 1123 "List of network layer interfaces assigned to the router 1124 instance."; 1125 leaf name { 1126 type if:interface-ref; 1127 description 1128 "A reference to the name of a configured network layer 1129 interface."; 1130 } 1131 } 1132 } 1133 container routing-protocols { 1134 description 1135 "Container for the list of configured routing protocol 1136 instances."; 1137 list routing-protocol { 1138 key "name"; 1139 description 1140 "An instance of a routing protocol."; 1142 leaf name { 1143 type string; 1144 description 1145 "An arbitrary name of the routing protocol instance."; 1146 } 1147 leaf description { 1148 type string; 1149 description 1150 "Textual description of the routing protocol 1151 instance."; 1152 } 1153 leaf enabled { 1154 type boolean; 1155 default "true"; 1156 description 1157 "Enable/disable the routing protocol instance. 1159 If this parameter is false, the parent routing 1160 protocol instance is disabled, despite any other 1161 configuration that might be present. 1162 "; 1163 } 1164 leaf type { 1165 type identityref { 1166 base routing-protocol; 1167 } 1168 mandatory "true"; 1169 description 1170 "Type of the routing protocol - an identity derived 1171 from the 'routing-protocol' base identity."; 1172 } 1173 container connected-routing-tables { 1174 description 1175 "Container for connected routing tables. 1176 "; 1177 list connected-routing-table { 1178 must "not(/routing/routing-tables/" 1179 + "routing-table[name=current()/" 1180 + "preceding-sibling::connected-routing-table/" 1181 + "name]/address-family=/routing/routing-tables/" 1182 + "routing-table[name=current()/name]/" 1183 + "address-family and /routing/routing-tables/" 1184 + "routing-table[name=current()/" 1185 + "preceding-sibling::connected-routing-table/" 1186 + "name]/safi=/routing/routing-tables/" 1187 + "routing-table[name=current()/name]/safi)" { 1188 error-message "Duplicate address family for " 1189 + "connected routing tables."; 1191 description 1192 "For each AFN/SAFI pair there MUST NOT be more than 1193 one connected routing table."; 1194 } 1195 key "name"; 1196 description 1197 "List of routing tables to which the routing protocol 1198 instance is connected (at most one routing table per 1199 address family). 1201 If no connected routing table is configured for an 1202 address family, the routing protocol MUST be 1203 operationally connected to the main routing table 1204 for that address family. 1205 "; 1206 leaf name { 1207 type routing-table-ref; 1208 must "../../../type != 'rt:direct' or " 1209 + "../../../../../main-routing-tables/ " 1210 + "main-routing-table/name=." { 1211 error-message "The 'direct' protocol can be " 1212 + "connected only to a main routing " 1213 + "table."; 1214 description 1215 "For the 'direct' pseudo-protocol, the connected 1216 routing table must always be a main routing 1217 table."; 1218 } 1219 description 1220 "Name of an existing routing table."; 1221 } 1222 leaf import-filter { 1223 type route-filter-ref; 1224 description 1225 "Reference to a route filter that is used for 1226 filtering routes passed from this routing protocol 1227 instance to the routing table specified by the 1228 'name' sibling node. 1230 If this leaf is not present, the behavior is 1231 protocol-specific, but typically it means that all 1232 routes are accepted. 1233 "; 1234 } 1235 leaf export-filter { 1236 type route-filter-ref; 1237 description 1238 "Reference to a route filter that is used for 1239 filtering routes passed from the routing table 1240 specified by the 'name' sibling node to this 1241 routing protocol instance. 1243 If this leaf is not present, the behavior is 1244 protocol-specific - typically it means that all 1245 routes are accepted. 1247 The 'direct' and 'static' pseudo-protocols accept 1248 no routes from any routing table. 1249 "; 1250 } 1251 } 1252 } 1253 container static-routes { 1254 when "../type='rt:static'" { 1255 description 1256 "This container is only valid for the 'static' 1257 routing protocol."; 1258 } 1259 description 1260 "Configuration of 'static' pseudo-protocol. 1262 Address family specific modules augment this node with 1263 their lists of routes. 1264 "; 1265 } 1266 } 1267 } 1268 } 1269 container routing-tables { 1270 description 1271 "Container for configured routing tables."; 1272 list routing-table { 1273 key "name"; 1274 description 1275 "Each entry represents a routing table identified by the 1276 'name' key. All routes in a routing table MUST belong to 1277 the same address family."; 1278 leaf name { 1279 type string; 1280 description 1281 "An arbitrary name of the routing table."; 1282 } 1283 uses afn-safi; 1284 leaf description { 1285 type string; 1286 description 1287 "Textual description of the routing table."; 1288 } 1289 container routes { 1290 config "false"; 1291 description 1292 "Current contents of the routing table (state data)."; 1293 list route { 1294 description 1295 "A routing table entry. This data node MUST be 1296 augmented with information specific for routes of each 1297 address family."; 1298 uses route-content; 1299 leaf source-protocol { 1300 type string; 1301 mandatory "true"; 1302 description 1303 'Routing protocol instance from which the route 1304 originated. 1306 It must be either "direct" or the name of a 1307 configured routing protocol instance. 1308 '; 1309 } 1310 leaf last-updated { 1311 type yang:date-and-time; 1312 description 1313 "Time stamp of the last modification of the route. If 1314 the route was never modified, it is the time when 1315 the route was inserted into the routing table."; 1316 } 1317 } 1318 } 1319 container recipient-routing-tables { 1320 description 1321 "Container for recipient routing tables."; 1322 list recipient-routing-table { 1323 must "name != ../../name" { 1324 error-message "Source and recipient routing tables " 1325 + "are identical."; 1326 description 1327 "A routing table MUST NOT appear among its recipient 1328 routing tables."; 1329 } 1330 must "/routing/routing-tables/" 1331 + "routing-table[name=current()/name]/" 1332 + "address-family=../../address-family and /routing/" 1333 + "routing-tables/routing-table[name=current()/name]/" 1334 + "safi=../../safi" { 1336 error-message "Address family mismatch."; 1337 description 1338 "Address family of the recipient routing table MUST 1339 match the source table."; 1340 } 1341 key "name"; 1342 description 1343 "List of routing tables that receive routes from this 1344 routing table."; 1345 leaf name { 1346 type routing-table-ref; 1347 description 1348 "The name of the recipient routing table."; 1349 } 1350 leaf filter { 1351 type route-filter-ref; 1352 description 1353 "A route filter which is applied to the routes passed 1354 to the recipient routing table."; 1355 } 1356 } 1357 } 1358 } 1359 } 1360 container route-filters { 1361 description 1362 "Container for configured route filters."; 1363 list route-filter { 1364 key "name"; 1365 description 1366 "Route filters are used for filtering and/or manipulating 1367 routes that are passed between a routing protocol and a 1368 routing table or vice versa, or between two routing 1369 tables. 1371 It is expected that other modules augment this list with 1372 contents specific for a particular route filter type. 1373 "; 1374 leaf name { 1375 type string; 1376 description 1377 "An arbitrary name of the route filter."; 1378 } 1379 leaf description { 1380 type string; 1381 description 1382 "Textual description of the route filter."; 1383 } 1384 leaf type { 1385 type identityref { 1386 base route-filter; 1387 } 1388 mandatory "true"; 1389 description 1390 "Type of the route-filter - an identity derived from the 1391 'route-filter' base identity."; 1392 } 1393 } 1394 } 1395 } 1396 } 1398 1400 7. IPv4 Unicast Routing YANG Module 1402 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1403 actual RFC number and all occurrences of the revision date below with 1404 the date of RFC publication (and remove this note). 1406 file "ietf-ipv4-unicast-routing@2013-02-11.yang" 1408 module ietf-ipv4-unicast-routing { 1410 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1412 prefix "v4ur"; 1414 import ietf-routing { 1415 prefix "rt"; 1416 } 1418 import ietf-inet-types { 1419 prefix "inet"; 1420 } 1422 organization 1423 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1425 contact 1426 "WG Web: 1427 WG List: 1429 WG Chair: David Kessens 1430 1432 WG Chair: Juergen Schoenwaelder 1433 1435 Editor: Ladislav Lhotka 1436 1437 "; 1439 description 1440 "This YANG module augments the 'ietf-routing' module with basic 1441 configuration and state data for IPv4 unicast routing. 1443 Copyright (c) 2012 IETF Trust and the persons identified as 1444 authors of the code. All rights reserved. 1446 Redistribution and use in source and binary forms, with or 1447 without modification, is permitted pursuant to, and subject to 1448 the license terms contained in, the Simplified BSD License set 1449 forth in Section 4.c of the IETF Trust's Legal Provisions 1450 Relating to IETF Documents 1451 (http://trustee.ietf.org/license-info). 1453 This version of this YANG module is part of RFC XXXX; see the 1454 RFC itself for full legal notices. 1455 "; 1457 revision 2013-02-11 { 1458 description 1459 "Initial revision."; 1460 reference 1461 "RFC XXXX: A YANG Data Model for Routing Management"; 1462 } 1464 /* Groupings */ 1466 grouping route-content { 1467 description 1468 "Parameters of IPv4 unicast routes."; 1469 leaf dest-prefix { 1470 type inet:ipv4-prefix; 1471 description 1472 "IPv4 destination prefix."; 1473 } 1474 leaf next-hop { 1475 type inet:ipv4-address; 1476 description 1477 "IPv4 address of the next hop."; 1478 } 1479 } 1481 /* RPC Methods */ 1483 augment "/rt:active-route/rt:input/rt:destination-address" { 1484 when "rt:address-family='ipv4' and rt:safi='nlri-unicast'" { 1485 description 1486 "This augment is valid only for IPv4 unicast."; 1487 } 1488 description 1489 "The 'address' leaf augments the 'rt:destination-address' 1490 parameter of the 'rt:active-route' operation."; 1491 leaf address { 1492 type inet:ipv4-address; 1493 description 1494 "IPv4 destination address."; 1495 } 1497 } 1499 augment "/rt:active-route/rt:output/rt:route" { 1500 when "rt:address-family='ipv4' and rt:safi='nlri-unicast'" { 1501 description 1502 "This augment is valid only for IPv4 unicast."; 1503 } 1504 description 1505 "Contents of the reply to 'rt:active-route' operation."; 1506 uses route-content; 1507 } 1509 /* Data nodes */ 1511 augment "/rt:routing/rt:router/rt:routing-protocols/" 1512 + "rt:routing-protocol/rt:static-routes" { 1513 description 1514 "This augment defines the configuration of the 'static' 1515 pseudo-protocol with data specific for IPv4 unicast."; 1516 container ipv4 { 1517 description 1518 "Configuration of a 'static' pseudo-protocol instance 1519 consists of a list of routes."; 1520 list route { 1521 key "id"; 1522 ordered-by "user"; 1523 description 1524 "A user-ordered list of static routes."; 1525 leaf id { 1526 type uint32 { 1527 range "1..max"; 1528 } 1529 description 1530 "Numeric identifier of the route. 1532 It is not required that the routes be sorted by their 1533 'id'. 1534 "; 1535 } 1536 leaf description { 1537 type string; 1538 description 1539 "Textual description of the route."; 1540 } 1541 uses rt:route-content; 1542 uses route-content { 1543 refine "dest-prefix" { 1544 mandatory "true"; 1546 } 1547 } 1548 } 1549 } 1550 } 1552 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 1553 + "rt:route" { 1554 when "../../rt:address-family = 'ipv4' and ../../rt:safi = " 1555 + "'nlri-unicast'" { 1556 description 1557 "This augment is valid only for IPv4 unicast."; 1558 } 1559 description 1560 "This augment defines the content of IPv4 unicast routes."; 1561 uses route-content; 1562 } 1563 } 1565 1567 8. IPv6 Unicast Routing YANG Module 1569 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1570 actual RFC number and all occurrences of the revision date below with 1571 the date of RFC publication (and remove this note). 1573 file "ietf-ipv6-unicast-routing@2013-02-11.yang" 1575 module ietf-ipv6-unicast-routing { 1577 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1579 prefix "v6ur"; 1581 import ietf-routing { 1582 prefix "rt"; 1583 } 1585 import ietf-inet-types { 1586 prefix "inet"; 1587 } 1589 import ietf-interfaces { 1590 prefix "if"; 1591 } 1593 import ietf-ip { 1594 prefix "ip"; 1595 } 1597 organization 1598 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1600 contact 1601 "WG Web: 1602 WG List: 1604 WG Chair: David Kessens 1605 1607 WG Chair: Juergen Schoenwaelder 1608 1610 Editor: Ladislav Lhotka 1611 1612 "; 1614 description 1615 "This YANG module augments the 'ietf-routing' module with basic 1616 configuration and state data for IPv6 unicast routing. 1618 Copyright (c) 2012 IETF Trust and the persons identified as 1619 authors of the code. All rights reserved. 1621 Redistribution and use in source and binary forms, with or 1622 without modification, is permitted pursuant to, and subject to 1623 the license terms contained in, the Simplified BSD License set 1624 forth in Section 4.c of the IETF Trust's Legal Provisions 1625 Relating to IETF Documents 1626 (http://trustee.ietf.org/license-info). 1628 This version of this YANG module is part of RFC XXXX; see the 1629 RFC itself for full legal notices. 1630 "; 1632 revision 2013-02-11 { 1633 description 1634 "Initial revision."; 1635 reference 1636 "RFC XXXX: A YANG Data Model for Routing Management"; 1637 } 1639 /* Groupings */ 1641 grouping route-content { 1642 description 1643 "Specific parameters of IPv6 unicast routes."; 1644 leaf dest-prefix { 1645 type inet:ipv6-prefix; 1646 description 1647 "IPv6 destination prefix."; 1648 } 1649 leaf next-hop { 1650 type inet:ipv6-address; 1651 description 1652 "IPv6 address of the next hop."; 1653 } 1654 } 1656 /* RPC Methods */ 1658 augment "/rt:active-route/rt:input/rt:destination-address" { 1659 when "rt:address-family='ipv6' and rt:safi='nlri-unicast'" { 1660 description 1661 "This augment is valid only for IPv6 unicast."; 1662 } 1663 description 1664 "The 'address' leaf augments the 'rt:destination-address' 1665 parameter of the 'rt:active-route' operation."; 1666 leaf address { 1667 type inet:ipv6-address; 1668 description 1669 "IPv6 destination address."; 1670 } 1671 } 1673 augment "/rt:active-route/rt:output/rt:route" { 1674 when "rt:address-family='ipv6' and rt:safi='nlri-unicast'" { 1675 description 1676 "This augment is valid only for IPv6 unicast."; 1677 } 1678 description 1679 "Contents of the reply to 'rt:active-route' operation."; 1680 uses route-content; 1681 } 1683 /* Data nodes */ 1685 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 1686 when "/if:interfaces/if:interface[if:name=current()/rt:name]/" 1687 + "ip:ipv6/ip:enabled='true'" { 1688 description 1689 "This augment is only valid for router interfaces with 1690 enabled IPv6."; 1691 } 1692 description 1693 "IPv6-specific parameters of router interfaces."; 1694 container ipv6-router-advertisements { 1695 description 1696 "Parameters of IPv6 Router Advertisements."; 1697 leaf send-advertisements { 1698 type boolean; 1699 default "false"; 1700 description 1701 "A flag indicating whether or not the router sends periodic 1702 Router Advertisements and responds to Router 1703 Solicitations."; 1704 reference 1705 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1706 AdvSendAdvertisements."; 1707 } 1708 leaf max-rtr-adv-interval { 1709 type uint16 { 1710 range "4..1800"; 1712 } 1713 units "seconds"; 1714 default "600"; 1715 description 1716 "The maximum time allowed between sending unsolicited 1717 multicast Router Advertisements from the interface."; 1718 reference 1719 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1720 MaxRtrAdvInterval."; 1721 } 1722 leaf min-rtr-adv-interval { 1723 type uint16 { 1724 range "3..1350"; 1725 } 1726 units "seconds"; 1727 must ". <= 0.75 * ../max-rtr-adv-interval" { 1728 description 1729 "The value MUST NOT be greater than 75 % of 1730 'max-rtr-adv-interval'."; 1731 } 1732 description 1733 "The minimum time allowed between sending unsolicited 1734 multicast Router Advertisements from the interface. 1736 The default value to be used operationally if this leaf is 1737 not configured is determined as follows: 1739 - if max-rtr-adv-interval >= 9 seconds, the default value 1740 is 0.33 * max-rtr-adv-interval; 1742 - otherwise it is 0.75 * max-rtr-adv-interval. 1743 "; 1744 reference 1745 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1746 MinRtrAdvInterval."; 1747 } 1748 leaf managed-flag { 1749 type boolean; 1750 default "false"; 1751 description 1752 "The boolean value to be placed in the 'Managed address 1753 configuration' flag field in the Router Advertisement."; 1754 reference 1755 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1756 AdvManagedFlag."; 1757 } 1758 leaf other-config-flag { 1759 type boolean; 1760 default "false"; 1761 description 1762 "The boolean value to be placed in the 'Other 1763 configuration' flag field in the Router Advertisement."; 1764 reference 1765 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1766 AdvOtherConfigFlag."; 1767 } 1768 leaf link-mtu { 1769 type uint32; 1770 default "0"; 1771 description 1772 "The value to be placed in MTU options sent by the router. 1773 A value of zero indicates that no MTU options are sent."; 1774 reference 1775 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1776 AdvLinkMTU."; 1777 } 1778 leaf reachable-time { 1779 type uint32 { 1780 range "0..3600000"; 1781 } 1782 units "milliseconds"; 1783 default "0"; 1784 description 1785 "The value to be placed in the Reachable Time field in the 1786 Router Advertisement messages sent by the router. The 1787 value zero means unspecified (by this router)."; 1788 reference 1789 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1790 AdvReachableTime."; 1791 } 1792 leaf retrans-timer { 1793 type uint32; 1794 units "milliseconds"; 1795 default "0"; 1796 description 1797 "The value to be placed in the Retrans Timer field in the 1798 Router Advertisement messages sent by the router. The 1799 value zero means unspecified (by this router)."; 1800 reference 1801 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1802 AdvRetransTimer."; 1803 } 1804 leaf cur-hop-limit { 1805 type uint8; 1806 default "64"; 1807 description 1808 "The default value to be placed in the Cur Hop Limit field 1809 in the Router Advertisement messages sent by the router. 1810 The value should be set to the current diameter of the 1811 Internet. The value zero means unspecified (by this 1812 router). 1814 The default SHOULD be set to the value specified in IANA 1815 Assigned Numbers that was in effect at the time of 1816 implementation. 1817 "; 1818 reference 1819 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1820 AdvCurHopLimit. 1822 IANA: IP Parameters, 1823 http://www.iana.org/assignments/ip-parameters 1824 "; 1825 } 1826 leaf default-lifetime { 1827 type uint16 { 1828 range "0..9000"; 1829 } 1830 units "seconds"; 1831 description 1832 "The value to be placed in the Router Lifetime field of 1833 Router Advertisements sent from the interface, in seconds. 1834 MUST be either zero or between max-rtr-adv-interval and 1835 9000 seconds. A value of zero indicates that the router is 1836 not to be used as a default router. These limits may be 1837 overridden by specific documents that describe how IPv6 1838 operates over different link layers. 1840 If this parameter is not configured, a value of 3 * 1841 max-rtr-adv-interval SHOULD be used. 1842 "; 1843 reference 1844 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1845 AdvDefaultLifeTime."; 1846 } 1847 container prefix-list { 1848 description 1849 "A list of prefixes to be placed in Prefix Information 1850 options in Router Advertisement messages sent from the 1851 interface. 1853 By default, all prefixes that the router advertises via 1854 routing protocols as being on-link for the interface from 1855 which the advertisement is sent. 1857 Prefixes that do not have their entries in the child 1858 'prefix' list are advertised with the default values of 1859 all parameters. 1861 The link-local prefix SHOULD NOT be included in the list 1862 of advertised prefixes. 1863 "; 1864 reference 1865 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1866 AdvPrefixList."; 1867 list prefix { 1868 key "prefix-spec"; 1869 description 1870 "Advertised prefix entry."; 1871 leaf prefix-spec { 1872 type inet:ipv6-prefix; 1873 description 1874 "IPv6 address prefix."; 1875 } 1876 choice control-adv-prefixes { 1877 default "advertise"; 1878 description 1879 "The prefix either may be explicitly removed from the 1880 set of advertised prefixes, or parameters with which 1881 it is advertised may be specified (default case)."; 1882 leaf no-advertise { 1883 type empty; 1884 description 1885 "The prefix will not be advertised. 1887 This can be used for removing the prefix from the 1888 default set of advertised prefixes. 1889 "; 1890 } 1891 case advertise { 1892 leaf valid-lifetime { 1893 type uint32; 1894 units "seconds"; 1895 default "2592000"; 1896 description 1897 "The value to be placed in the Valid Lifetime in 1898 the Prefix Information option, in seconds. The 1899 designated value of all 1's (0xffffffff) 1900 represents infinity. 1901 "; 1902 reference 1903 "RFC 4861: Neighbor Discovery for IP version 6 1904 (IPv6) - AdvValidLifetime."; 1906 } 1907 leaf on-link-flag { 1908 type boolean; 1909 default "true"; 1910 description 1911 "The value to be placed in the on-link flag 1912 ('L-bit') field in the Prefix Information 1913 option."; 1914 reference 1915 "RFC 4861: Neighbor Discovery for IP version 6 1916 (IPv6) - AdvOnLinkFlag."; 1917 } 1918 leaf preferred-lifetime { 1919 type uint32; 1920 units "seconds"; 1921 must ". <= ../valid-lifetime" { 1922 description 1923 "This value MUST NOT be greater than 1924 valid-lifetime."; 1925 } 1926 default "604800"; 1927 description 1928 "The value to be placed in the Preferred Lifetime 1929 in the Prefix Information option, in seconds. The 1930 designated value of all 1's (0xffffffff) 1931 represents infinity. 1932 "; 1933 reference 1934 "RFC 4861: Neighbor Discovery for IP version 6 1935 (IPv6) - AdvPreferredLifetime."; 1936 } 1937 leaf autonomous-flag { 1938 type boolean; 1939 default "true"; 1940 description 1941 "The value to be placed in the Autonomous Flag 1942 field in the Prefix Information option."; 1943 reference 1944 "RFC 4861: Neighbor Discovery for IP version 6 1945 (IPv6) - AdvAutonomousFlag."; 1946 } 1947 } 1948 } 1949 } 1950 } 1951 } 1952 } 1953 augment "/rt:routing/rt:router/rt:routing-protocols/" 1954 + "rt:routing-protocol/rt:static-routes" { 1955 description 1956 "This augment defines the configuration of the 'static' 1957 pseudo-protocol with data specific for IPv6 unicast."; 1958 container ipv6 { 1959 description 1960 "Configuration of a 'static' pseudo-protocol instance 1961 consists of a list of routes."; 1962 list route { 1963 key "id"; 1964 ordered-by "user"; 1965 description 1966 "A user-ordered list of static routes."; 1967 leaf id { 1968 type uint32 { 1969 range "1..max"; 1970 } 1971 description 1972 "Numeric identifier of the route. 1974 It is not required that the routes be sorted by their 1975 'id'. 1976 "; 1977 } 1978 leaf description { 1979 type string; 1980 description 1981 "Textual description of the route."; 1982 } 1983 uses rt:route-content; 1984 uses route-content { 1985 refine "dest-prefix" { 1986 mandatory "true"; 1987 } 1988 } 1989 } 1990 } 1991 } 1993 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 1994 + "rt:route" { 1995 when "../../rt:address-family = 'ipv6' and ../../rt:safi = " 1996 + "'nlri-unicast'" { 1997 description 1998 "This augment is valid only for IPv6 unicast."; 1999 } 2000 description 2001 "This augment defines the content of IPv6 unicast routes."; 2002 uses route-content; 2003 } 2004 } 2006 2008 9. IANA Considerations 2010 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2011 actual RFC number (and remove this note). 2013 This document registers the following namespace URIs in the IETF XML 2014 registry [RFC3688]: 2016 ---------------------------------------------------------- 2017 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2019 Registrant Contact: The IESG. 2021 XML: N/A, the requested URI is an XML namespace. 2022 ---------------------------------------------------------- 2024 ---------------------------------------------------------- 2025 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2027 Registrant Contact: The IESG. 2029 XML: N/A, the requested URI is an XML namespace. 2030 ---------------------------------------------------------- 2032 ---------------------------------------------------------- 2033 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2035 Registrant Contact: The IESG. 2037 XML: N/A, the requested URI is an XML namespace. 2038 ---------------------------------------------------------- 2040 This document registers the following YANG modules in the YANG Module 2041 Names registry [RFC6020]: 2043 ------------------------------------------------------------------- 2044 name: ietf-routing 2045 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2046 prefix: rt 2047 reference: RFC XXXX 2048 ------------------------------------------------------------------- 2050 ------------------------------------------------------------------- 2051 name: ietf-ipv4-unicast-routing 2052 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2053 prefix: v4ur 2054 reference: RFC XXXX 2055 ------------------------------------------------------------------- 2057 ------------------------------------------------------------------- 2058 name: ietf-ipv6-unicast-routing 2059 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2060 prefix: v6ur 2061 reference: RFC XXXX 2062 ------------------------------------------------------------------- 2064 10. Security Considerations 2066 Configuration and state data conforming to the core routing data 2067 model (defined in this document) are designed to be accessed via the 2068 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2069 transport layer and the mandatory-to-implement secure transport is 2070 SSH [RFC6242]. 2072 A number of data nodes defined in the YANG modules belonging to the 2073 core routing data model are writable/creatable/deletable (i.e., 2074 "config true" in YANG terms, which is the default). These data nodes 2075 may be considered sensitive or vulnerable in some network 2076 environments. Write operations to these data nodes, such as "edit- 2077 config", can have negative effects on the network if the protocol 2078 operations are not properly protected. 2080 The vulnerable "config true" subtrees and data nodes are the 2081 following: 2083 /routing/router/interfaces/interface This list assigns a network 2084 layer interface to a router instance and may also specify 2085 interface parameters related to routing. 2087 /routing/router/routing-protocols/routing-protocol This list 2088 specifies the routing protocols configured on a device. 2090 /routing/route-filters/route-filter This list specifies the 2091 configured route filters which represent administrative policies 2092 for redistributing and modifying routing information. 2094 /routing/routing-tables/routing-table This list specifies the 2095 configured routing tables used by the device. 2097 Unauthorized access to any of these lists can adversely affect the 2098 routing subsystem of both the local device and the network. This may 2099 lead to network malfunctions, delivery of packets to inappropriate 2100 destinations and other problems. 2102 11. Acknowledgments 2104 The author wishes to thank Martin Bjorklund, Joel Halpern, 2105 Wes Hardaker, Andrew McGregor, Thomas Morin, Tom Petch, 2106 Bruno Rijsman, Juergen Schoenwaelder, Phil Shafer, Dave Thaler and 2107 Yi Yang for their helpful comments and suggestions. 2109 12. References 2111 12.1. Normative References 2113 [IANA-IF-AF] 2114 Bjorklund, M., "IANA Interface Type and Address Family 2115 YANG Modules", draft-ietf-netmod-iana-if-type-04 (work in 2116 progress), June 2012. 2118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2119 Requirement Levels", BCP 14, RFC 2119, March 1997. 2121 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2122 January 2004. 2124 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2125 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2126 September 2007. 2128 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2129 Network Configuration Protocol (NETCONF)", RFC 6020, 2130 September 2010. 2132 [RFC6021bis] 2133 Schoenwaelder, J., Ed., "Common YANG Data Types", 2134 draft-ietf-netmod-rfc6021-bis-00 (work in progress), 2135 February 2013. 2137 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2138 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2139 June 2011. 2141 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2142 Configuration", draft-ietf-netmod-interfaces-cfg-09 (work 2143 in progress), February 2013. 2145 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 2146 draft-ietf-netmod-ip-cfg-09 (work in progress), 2147 February 2012. 2149 12.2. Informative References 2151 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2152 Data Model Documents", RFC 6087, January 2011. 2154 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2155 Shell (SSH)", RFC 6242, June 2011. 2157 Appendix A. The Complete Data Tree 2159 This appendix presents the complete data tree of the core routing 2160 data model. See Section 2.2 for an explanation of symbols. Data 2161 type of every leaf node is shown near the right end of the 2162 corresponding line. 2164 +--rw routing 2165 +--rw router [name] 2166 | +--rw name string 2167 | +--rw type? identityref 2168 | +--rw enabled? boolean 2169 | +--rw router-id? yang:dotted-quad 2170 | +--rw description? string 2171 | +--rw main-routing-tables 2172 | | +--rw main-routing-table [address-family safi] 2173 | | +--rw address-family ianaaf:address-family 2174 | | +--rw safi ianaaf:subsequent-address-family 2175 | | +--rw name? routing-table-ref 2176 | +--rw interfaces 2177 | | +--rw interface [name] 2178 | | +--rw name if:interface-ref 2179 | | +--rw v6ur:ipv6-router-advertisements 2180 | | +--rw v6ur:send-advertisements? boolean 2181 | | +--rw v6ur:max-rtr-adv-interval? uint16 2182 | | +--rw v6ur:min-rtr-adv-interval? uint16 2183 | | +--rw v6ur:managed-flag? boolean 2184 | | +--rw v6ur:other-config-flag? boolean 2185 | | +--rw v6ur:link-mtu? uint32 2186 | | +--rw v6ur:reachable-time? uint32 2187 | | +--rw v6ur:retrans-timer? uint32 2188 | | +--rw v6ur:cur-hop-limit? uint8 2189 | | +--rw v6ur:default-lifetime? uint16 2190 | | +--rw v6ur:prefix-list 2191 | | +--rw v6ur:prefix [prefix-spec] 2192 | | +--rw v6ur:prefix-spec inet:ipv6-prefix 2193 | | +--rw (control-adv-prefixes)? 2194 | | +--:(no-advertise) 2195 | | | +--rw v6ur:no-advertise? empty 2196 | | +--:(advertise) 2197 | | +--rw v6ur:valid-lifetime? uint32 2198 | | +--rw v6ur:on-link-flag? boolean 2199 | | +--rw v6ur:preferred-lifetime? uint32 2200 | | +--rw v6ur:autonomous-flag? boolean 2201 | +--rw routing-protocols 2202 | +--rw routing-protocol [name] 2203 | +--rw name string 2204 | +--rw description? string 2205 | +--rw enabled? boolean 2206 | +--rw type identityref 2207 | +--rw connected-routing-tables 2208 | | +--rw connected-routing-table [name] 2209 | | +--rw name routing-table-ref 2210 | | +--rw import-filter? route-filter-ref 2211 | | +--rw export-filter? route-filter-ref 2212 | +--rw static-routes 2213 | +--rw v4ur:ipv4 2214 | | +--rw v4ur:route [id] 2215 | | +--rw v4ur:id uint32 2216 | | +--rw v4ur:description? string 2217 | | +--rw v4ur:outgoing-interface? if:interface-ref 2218 | | +--rw v4ur:dest-prefix inet:ipv4-prefix 2219 | | +--rw v4ur:next-hop? inet:ipv4-address 2220 | +--rw v6ur:ipv6 2221 | +--rw v6ur:route [id] 2222 | +--rw v6ur:id uint32 2223 | +--rw v6ur:description? string 2224 | +--rw v6ur:outgoing-interface? if:interface-ref 2225 | +--rw v6ur:dest-prefix inet:ipv6-prefix 2226 | +--rw v6ur:next-hop? inet:ipv6-address 2227 +--rw routing-tables 2228 | +--rw routing-table [name] 2229 | +--rw name string 2230 | +--rw address-family ianaaf:address-family 2231 | +--rw safi ianaaf:subsequent-address-family 2232 | +--rw description? string 2233 | +--ro routes 2234 | | +--ro route 2235 | | +--ro outgoing-interface? if:interface-ref 2236 | | +--ro source-protocol string 2237 | | +--ro last-updated? yang:date-and-time 2238 | | +--ro v4ur:dest-prefix? inet:ipv4-prefix 2239 | | +--ro v4ur:next-hop? inet:ipv4-address 2240 | | +--ro v6ur:dest-prefix? inet:ipv6-prefix 2241 | | +--ro v6ur:next-hop? inet:ipv6-address 2242 | +--rw recipient-routing-tables 2243 | +--rw recipient-routing-table [name] 2244 | +--rw name routing-table-ref 2245 | +--rw filter? route-filter-ref 2246 +--rw route-filters 2247 +--rw route-filter [name] 2248 +--rw name string 2249 +--rw description? string 2250 +--rw type identityref 2252 Appendix B. Example: Adding a New Routing Protocol 2254 This appendix demonstrates how the core routing data model can be 2255 extended to support a new routing protocol. The YANG module 2256 "example-rip" shown below is intended only as an illustration rather 2257 than a real definition of a data model for the RIP routing protocol. 2258 For the sake of brevity, we do not follow all the guidelines 2259 specified in [RFC6087]. See also Section 4.4.2. 2261 module example-rip { 2263 namespace "http://example.com/rip"; 2265 prefix "rip"; 2267 import ietf-routing { 2268 prefix "rt"; 2269 } 2271 identity rip { 2272 base rt:routing-protocol; 2273 description 2274 "Identity for the RIP routing protocol."; 2275 } 2277 typedef rip-metric { 2278 type uint8 { 2279 range "0..16"; 2280 } 2281 } 2283 grouping route-content { 2284 description 2285 "This grouping defines RIP-specific route attributes."; 2286 leaf metric { 2287 type rip-metric; 2288 } 2289 leaf tag { 2290 type uint16; 2291 default "0"; 2292 description 2293 "This leaf may be used to carry additional info, e.g. AS 2294 number."; 2295 } 2296 } 2298 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 2299 + "rt:route" { 2301 description 2302 "RIP-specific route attributes."; 2303 uses route-content; 2304 } 2306 augment "/rt:active-route/rt:output/rt:route" { 2307 description 2308 "RIP-specific route attributes."; 2309 uses route-content; 2310 } 2312 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 2313 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 2314 + "'rip:rip'" { 2315 description 2316 'This augment is only valid for a routing protocol instance 2317 of type "rip".'; 2318 } 2319 container rip { 2320 description 2321 "Per-interface RIP configuration."; 2322 leaf enabled { 2323 type boolean; 2324 default "true"; 2325 } 2326 leaf metric { 2327 type rip-metric; 2328 default "1"; 2329 } 2330 } 2331 } 2333 augment "/rt:routing/rt:router/rt:routing-protocols/" 2334 + "rt:routing-protocol" { 2335 when "rt:type = 'rip:rip'" { 2336 description 2337 'This augment is only valid for a routing protocol instance 2338 of type "rip".'; 2339 } 2340 container rip { 2341 description 2342 "Global RIP configuration."; 2343 leaf update-interval { 2344 type uint8 { 2345 range "10..60"; 2346 } 2347 units "seconds"; 2348 default "30"; 2349 description 2350 "Time interval between periodic updates."; 2351 } 2352 } 2353 } 2354 } 2356 Appendix C. Example: NETCONF Reply 2358 This section contains a sample reply to the NETCONF message, 2359 which could be sent by a server supporting (i.e., advertising them in 2360 the NETCONF message) the following YANG modules: 2362 o ietf-interfaces [YANG-IF], 2364 o ietf-ip [YANG-IP], 2366 o ietf-routing (Section 6), 2368 o ietf-ipv4-unicast-routing (Section 7), 2370 o ietf-ipv6-unicast-routing (Section 8). 2372 We assume a simple network setup as shown in Figure 4: router "A" 2373 uses static default routes with the "ISP" router as the next hop. 2374 IPv6 router advertisements are configured only on the "eth1" 2375 interface and disabled on the upstream "eth0" interface. 2377 +-----------------+ 2378 | | 2379 | Router ISP | 2380 | | 2381 +--------+--------+ 2382 |2001:db8:0:1::2 2383 |192.0.2.2 2384 | 2385 | 2386 |2001:db8:0:1::1 2387 eth0|192.0.2.1 2388 +--------+--------+ 2389 | | 2390 | Router A | 2391 | | 2392 +--------+--------+ 2393 eth1|198.51.100.1 2394 |2001:db8:0:2::1 2395 | 2397 Figure 4: Example network configuration 2399 A reply to the NETCONF message sent by router "A" would then be 2400 as follows: 2402 2403 2411 2412 2413 2414 eth0 2415 ethernetCsmacd 2416 eth0 2417 2418 2419 192.0.2.1 2420 24 2421 2422 true 2423 2424 2425 2426 2001:0db8:0:1::1 2427 64 2428 2429 true 2430 2431 false 2432 2433 2434 2435 2436 eth1 2437 ethernetCsmacd 2438 eth1 2439 2440 2441 198.51.100.1 2442 24 2443 2444 true 2445 2446 2447 2448 2001:0db8:0:2::1 2449 64 2450 2451 true 2452 2453 false 2454 2455 2456 2457 2458 2459 2460 rtr0 2461 192.0.2.1 2462 Router A 2463 2464 2465 ipv4 2466 nlri-unicast 2467 ipv4-unicast 2468 2469 2470 ipv6 2471 nlri-unicast 2472 ipv6-unicast 2473 2474 2475 2476 2477 eth0 2478 2479 2480 eth1 2481 2482 true 2483 2484 2485 2001:db8:0:2::/64 2486 2487 2488 2489 2490 2491 2492 2493 st0 2494 2495 Static routing is used for the internal network. 2496 2497 rt:static 2498 2499 2500 2501 1 2502 0.0.0.0/0 2503 192.0.2.2 2504 2505 2506 2507 2508 1 2509 ::/0 2510 2001:db8:0:1::2 2511 2512 2513 2514 2515 2516 2517 2518 2519 ipv4-unicast 2520 ipv4 2521 nlri-unicast 2522 2523 2524 192.0.2.1/24 2525 eth0 2526 direct 2527 2012-10-02T17:11:27+01:00 2528 2529 2530 198.51.100.0/24 2531 eth1 2532 direct 2533 2012-10-02T17:11:27+01:00 2534 2535 2536 0.0.0.0/0 2537 st0 2538 192.0.2.2 2539 2012-10-02T18:02:45+01:00 2540 2541 2542 2543 2544 ipv6-unicast 2545 ipv6 2546 nlri-unicast 2547 2548 2549 2001:db8:0:1::/64 2550 eth0 2551 direct 2552 2012-10-02T17:11:27+01:00 2553 2554 2555 2001:db8:0:2::/64 2556 eth1 2557 direct 2558 2012-10-02T17:11:27+01:00 2559 2560 2561 ::/0 2562 2001:db8:0:1::2 2563 st0 2564 2012-10-02T18:02:45+01:00 2565 2566 2567 2568 2569 2570 2571 2573 Appendix D. Change Log 2575 RFC Editor: remove this section upon publication as an RFC. 2577 D.1. Changes Between Versions -07 and -08 2579 o Changed reference from RFC6021 to RFC6021bis. 2581 D.2. Changes Between Versions -06 and -07 2583 o The contents of in Appendix C was updated: "eth[01]" 2584 is used as the value of "location", and "forwarding" is on for 2585 both interfaces and both IPv4 and IPv6. 2587 o The "must" expression for "main-routing-table" was modified to 2588 avoid redundant error messages reporting address family mismatch 2589 when "name" points to a non-existent routing table. 2591 o The default behavior for IPv6 RA prefix advertisements was 2592 clarified. 2594 o Changed type of "rt:router-id" to "ip:dotted-quad". 2596 o Type of "rt:router-id" changed to "yang:dotted-quad". 2598 o Fixed missing prefixes in XPath expressions. 2600 D.3. Changes Between Versions -05 and -06 2602 o Document title changed: "Configuration" was replaced by 2603 "Management". 2605 o New typedefs "routing-table-ref" and "route-filter-ref". 2607 o Double slashes "//" were removed from XPath expressions and 2608 replaced with the single "/". 2610 o Removed uniqueness requirement for "router-id". 2612 o Complete data tree is now in Appendix A. 2614 o Changed type of "source-protocol" from "leafref" to "string". 2616 o Clarified the relationship between routing protocol instances and 2617 connected routing tables. 2619 o Added a must constraint saying that a routing table connected to 2620 the direct pseudo-protocol must not be a main routing table. 2622 D.4. Changes Between Versions -04 and -05 2624 o Routing tables are now global, i.e., "routing-tables" is a child 2625 of "routing" rather than "router". 2627 o "must" statement for "static-routes" changed to "when". 2629 o Added "main-routing-tables" containing references to main routing 2630 tables for each address family. 2632 o Removed the defaults for "address-family" and "safi" and made them 2633 mandatory. 2635 o Removed the default for route-filter/type and made this leaf 2636 mandatory. 2638 o If there is no active route for a given destination, the "active- 2639 route" RPC returns no output. 2641 o Added "enabled" switch under "routing-protocol". 2643 o Added "router-type" identity and "type" leaf under "router". 2645 o Route attribute "age" changed to "last-updated", its type is 2646 "yang:date-and-time". 2648 o The "direct" pseudo-protocol is always connected to main routing 2649 tables. 2651 o Entries in the list of connected routing tables renamed from 2652 "routing-table" to "connected-routing-table". 2654 o Added "must" constraint saying that a routing table must not be 2655 its own recipient. 2657 D.5. Changes Between Versions -03 and -04 2659 o Changed "error-tag" for both RPC methods from "missing element" to 2660 "data-missing". 2662 o Removed the decrementing behavior for advertised IPv6 prefix 2663 parameters "valid-lifetime" and "preferred-lifetime". 2665 o Changed the key of the static route lists from "seqno" to "id" 2666 because the routes needn't be sorted. 2668 o Added 'must' constraint saying that "preferred-lifetime" must not 2669 be greater than "valid-lifetime". 2671 D.6. Changes Between Versions -02 and -03 2673 o Module "iana-afn-safi" moved to I-D "iana-if-type". 2675 o Removed forwarding table. 2677 o RPC "get-route" changed to "active-route". Its output is a list 2678 of routes (for multi-path routing). 2680 o New RPC "route-count". 2682 o For both RPCs, specification of negative responses was added. 2684 o Relaxed separation of router instances. 2686 o Assignment of interfaces to router instances needn't be disjoint. 2688 o Route filters are now global. 2690 o Added "allow-all-route-filter" for symmetry. 2692 o Added Section 5 about interactions with "ietf-interfaces" and 2693 "ietf-ip". 2695 o Added "router-id" leaf. 2697 o Specified the names for IPv4/IPv6 unicast main routing tables. 2699 o Route parameter "last-modified" changed to "age". 2701 o Added container "recipient-routing-tables". 2703 D.7. Changes Between Versions -01 and -02 2705 o Added module "ietf-ipv6-unicast-routing". 2707 o The example in Appendix C now uses IP addresses from blocks 2708 reserved for documentation. 2710 o Direct routes appear by default in the forwarding table. 2712 o Network layer interfaces must be assigned to a router instance. 2713 Additional interface configuration may be present. 2715 o The "when" statement is only used with "augment", "must" is used 2716 elsewhere. 2718 o Additional "must" statements were added. 2720 o The "route-content" grouping for IPv4 and IPv6 unicast now 2721 includes the material from the "ietf-routing" version via "uses 2722 rt:route-content". 2724 o Explanation of symbols in the tree representation of data model 2725 hierarchy. 2727 D.8. Changes Between Versions -00 and -01 2729 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2731 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2732 safi" module. 2734 o Names of some data nodes were changed, in particular "routing- 2735 process" is now "router". 2737 o The restriction of a single AFN/SAFI per router was lifted. 2739 o RPC operation "delete-route" was removed. 2741 o Illegal XPath references from "get-route" to the datastore were 2742 fixed. 2744 o Section "Security Considerations" was written. 2746 Author's Address 2748 Ladislav Lhotka 2749 CZ.NIC 2751 Email: lhotka@nic.cz