idnits 2.17.1 draft-ietf-netmod-routing-cfg-06.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 2168 has weird spacing: '...-family ian...' -- The document date (November 15, 2012) is 4180 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 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-08 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-ip-cfg-07 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 1 error (**), 0 flaws (~~), 5 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 November 15, 2012 5 Expires: May 19, 2013 7 A YANG Data Model for Routing Management 8 draft-ietf-netmod-routing-cfg-06 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 May 19, 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. 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 -05 and -06 . . . . . . . . . . . 64 88 D.2. Changes Between Versions -04 and -05 . . . . . . . . . . . 64 89 D.3. Changes Between Versions -03 and -04 . . . . . . . . . . . 65 90 D.4. Changes Between Versions -02 and -03 . . . . . . . . . . . 65 91 D.5. Changes Between Versions -01 and -02 . . . . . . . . . . . 66 92 D.6. Changes Between Versions -00 and -01 . . . . . . . . . . . 66 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 68 95 1. Introduction 97 This document contains a specification of the following YANG modules: 99 o Module "ietf-routing" provides generic components of a routing 100 data model. 102 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 103 module with additional data specific to IPv4 unicast. 105 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 106 module with additional data specific to IPv6 unicast, including 107 the router configuration variables required by [RFC4861]. 109 These modules together define the so-called core routing data model, 110 which is proposed as a basis for the development of data models for 111 configuration and management of more sophisticated routing systems. 112 While these three modules can be directly used for simple IP devices 113 with static routing, their main purpose is to provide essential 114 building blocks for more complicated setups involving multiple 115 routing protocols, multicast routing, additional address families, 116 and advanced functions such as route filtering or policy routing. To 117 this end, it is expected that the core routing data model will be 118 augmented by numerous modules developed by other IETF working groups. 120 2. Terminology and Notation 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 The following terms are defined in [RFC6241]: 128 o client 130 o message 132 o protocol operation 134 o server 136 The following terms are defined in [RFC6020]: 138 o augment 140 o configuration data 142 o data model 144 o data node 146 o mandatory node 148 o module 150 o state data 152 o RPC operation 154 2.1. Glossary of New Terms 156 active route: a route which is actually used for sending packets. 157 If there are multiple candidate routes with a matching destination 158 prefix, then it is up to the routing algorithm to select the 159 active route (or several active routes in the case of multi-path 160 routing). 162 core routing data model: YANG data model resulting from the 163 combination of "ietf-routing", "ietf-ipv4-unicast-routing" and 164 "ietf-ipv6-unicast-routing" modules. 166 direct route: a route to a directly connected network. 168 2.2. Tree Diagrams 170 A simplified graphical representation of the complete data tree is 171 presented in Appendix A, and similar diagrams of its various subtrees 172 appear in the main text. The meaning of the symbols in these 173 diagrams is as follows: 175 o Brackets "[" and "]" enclose list keys. 177 o Abbreviations before data node names: "rw" means configuration 178 (read-write) and "ro" state data (read-only). 180 o Symbols after data node names: "?" means an optional node and "*" 181 denotes a "leaf-list". 183 o Parentheses enclose choice and case nodes, and case nodes are also 184 marked with a colon (":"). 186 o Ellipsis ("...") stands for contents of subtrees that are not 187 shown. 189 2.3. Prefixes in Data Node Names 191 In this document, names of data nodes, RPC methods and other data 192 model objects are used mostly without a prefix, as long as it is 193 clear from the context in which YANG module each name is defined. 194 Otherwise, names are prefixed using the standard prefix associated 195 with the corresponding YANG module, as shown in Table 1. 197 +--------+---------------------------+--------------+ 198 | Prefix | YANG module | Reference | 199 +--------+---------------------------+--------------+ 200 | ianaaf | iana-afn-safi | [IANA-IF-AF] | 201 | | | | 202 | if | ietf-interfaces | [YANG-IF] | 203 | | | | 204 | ip | ietf-ip | [YANG-IP] | 205 | | | | 206 | rip | example-rip | Appendix B | 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 | [RFC6021] | 215 | | | | 216 | inet | ietf-inet-types | [RFC6021] | 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 "destination-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 "destination- 459 prefix" should be sent. 461 o "outgoing-interface": network interface that should be used for 462 sending packets with destination addresses belonging to 463 "destination-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. Consequently, configuration of 539 recipient routing tables makes sense only for servers supporting 540 multiple routing tables per address family. Servers supporting only 541 one routing table per address family MAY therefore decide to remove 542 the container "recipient-routing-tables", together with its contents, 543 from the data model. 545 4.4. Routing Protocols 547 The core routing data model provides an open-ended framework for 548 defining multiple routing protocol instances within each router 549 instance. Each routing protocol instance MUST be assigned a type, 550 which is an identity derived from the "rt:routing-protocol" base 551 identity. The core routing data model defines two identities for the 552 direct and static pseudo-protocols (Section 4.4.1). 554 Each routing protocol instance is connected to exactly one routing 555 table for each address family that the routing protocol instance 556 supports. Routes learned from the network by a routing protocol are 557 normally installed into the connected routing table(s) and, 558 conversely, routes from the connected routing table(s) are normally 559 injected into the routing protocol. However, routing protocol 560 implementations MAY specify rules that restrict this exchange of 561 routes in either direction (or both directions). 563 A routing table is connected to a routing protocol instance by 564 creating a corresponding entry in the "connected-routing-table" list. 565 If such an entry is not configured for an address family, then the 566 main routing table MUST be used as the connected routing table for 567 this address family. 569 In addition, two independent route filters (see Section 4.5) may be 570 configured for each connected routing table to apply client-defined 571 policies controlling the exchange of routes in both directions 572 between the routing protocol instance and the connected routing 573 table: 575 o import filter controls which routes are passed from the routing 576 protocol instance to the connected routing table, 578 o export filter controls which routes the routing protocol instance 579 receives from the connected routing table. 581 Note that the terms import and export are used from the viewpoint of 582 a routing table. 584 4.4.1. Routing Pseudo-Protocols 586 The core routing data model defines two special routing protocol 587 types - "direct" and "static". Both are in fact pseudo-protocols, 588 which means that they are confined to the local device and do not 589 exchange any routing information with neighboring routers. Routes 590 from both "direct" and "static" protocol instances are passed to the 591 connected routing table (subject to route filters, if any), but an 592 exchange in the opposite direction is not allowed. 594 Every router instance MUST implement exactly one instance of the 595 "direct" pseudo-protocol type. The name of this instance MUST also 596 be "direct". It is the source of direct routes for all configured 597 address families. Direct routes are normally supplied by the 598 operating system kernel, based on the configuration of network 599 interface addresses, see Section 5.2. The "direct" pseudo-protocol 600 MUST always be connected to the main routing tables of all supported 601 address families. Unlike other routing protocol types, this 602 connection cannot be changed in the configuration. Direct routes MAY 603 be filtered before they appear in the main routing table. 605 A pseudo-protocol of the type "static" allows for specifying routes 606 manually. It MAY be configured in zero or multiple instances, 607 although a typical configuration will have exactly one instance per 608 logical router. 610 Static routes are configured within the "static-routes" container, 611 see Figure 3. 613 +--rw static-routes 614 +--rw v4ur:ipv4 615 | +--rw v4ur:route [id] 616 | +--rw v4ur:id 617 | +--rw v4ur:description? 618 | +--rw v4ur:outgoing-interface? 619 | +--rw v4ur:dest-prefix 620 | +--rw v4ur:next-hop? 621 +--rw v6ur:ipv6 622 +--rw v6ur:route [id] 623 +--rw v6ur:id 624 +--rw v6ur:description? 625 +--rw v6ur:outgoing-interface? 626 +--rw v6ur:dest-prefix 627 +--rw v6ur:next-hop? 629 Figure 3: Structure of "static-routes" subtree. 631 4.4.2. Defining New Routing Protocols 633 It is expected that future YANG modules will create data models for 634 additional routing protocol types. Such a new module has to define 635 the protocol-specific configuration and state data, and it has to fit 636 it into the core routing framework in the following way: 638 o A new identity MUST be defined for the routing protocol and its 639 base identity MUST be set to "rt:routing-protocol", or to an 640 identity derived from "rt:routing-protocol". 642 o Additional route attributes MAY be defined, preferably in one 643 place by means of defining a YANG grouping. The new attributes 644 have to be inserted as state data by augmenting the definition of 645 the node 647 /rt:routing-tables/rt:routing-table/rt:route, 649 and possibly to other places in the configuration, state data and 650 RPC input or output. 652 o Per-interface configuration parameters can be added by augmenting 653 the data node "rt:interface" (the list of router interfaces). 655 o Other configuration parameters and state data can be defined by 656 augmenting the "routing-protocol" data node. 658 By using the "when" statement, the augmented per-interface and other 659 configuration parameters specific to the new protocol SHOULD be made 660 conditional and valid only if the value of "rt:type" is equal to the 661 new protocol's identity. It is also RECOMMENDED that the protocol- 662 specific data be encapsulated in appropriately named containers. 664 The above steps are implemented by the example YANG module for the 665 RIP routing protocol in Appendix B. 667 4.5. Route Filters 669 The core routing data model provides a skeleton for defining route 670 filters that can be used to restrict the set of routes being 671 exchanged between a routing protocol instance and a connected routing 672 table, or between a source and a recipient routing table. Route 673 filters may also manipulate routes, i.e., add, delete, or modify 674 their attributes. 676 Route filters are global, which means that a configured route filter 677 may be used by any or all router instances. 679 By itself, the route filtering framework defined in this document 680 allows for applying only two extreme routing policies which are 681 represented by the following pre-defined route filter types: 683 o "deny-all-route-filter": all routes are blocked, 684 o "allow-all-route-filter": all routes are permitted. 686 Note that the latter type is equivalent to no route filter. 688 It is expected that more comprehensive route filtering frameworks 689 will be developed separately. 691 Each route filter is identified by a name which MUST be unique within 692 the entire configuration. Its type MUST be specified by the "type" 693 identity reference - this opens the space for multiple route 694 filtering framework implementations. The default value for the route 695 filter type is the identity "deny-all-route-filter". 697 4.6. RPC Operations 699 The "ietf-routing" module defines two RPC operations: 701 o active-route: query the routing system for the active route(s) 702 that are currently used for sending datagrams to a destination 703 host whose address is passed as an input parameter. 705 o route-count: retrieve the total number of entries in a routing 706 table. 708 5. Interactions with Other YANG Modules 710 The semantics of the core routing data model also depend on several 711 configuration parameters that are defined in other YANG modules. 713 5.1. Module "ietf-interfaces" 715 The following boolean switch is defined in the "ietf-interfaces" YANG 716 module [YANG-IF]: 718 /if:interfaces/if:interface/if:enabled 720 If this switch is set to "false" for a given network layer 721 interface, the device MUST behave exactly as if that interface was 722 not assigned to any logical router at all. 724 5.2. Module "ietf-ip" 726 The following boolean switches are defined in the "ietf-ip" YANG 727 module [YANG-IP]: 729 /if:interfaces/if:interface/ip:ipv4/ip:enabled 731 If this switch is set to "false" for a given interface, then all 732 IPv4 routing functions related to that interface MUST be disabled. 734 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 736 If this switch is set to "false" for a given interface, then the 737 forwarding of IPv4 datagrams to and from this interface MUST be 738 disabled. However, the interface may participate in other routing 739 functions, such as routing protocols. 741 /if:interfaces/if:interface/ip:ipv6/ip:enabled 743 If this switch is set to "false" for a given interface, then all 744 IPv6 routing functions related to that interface MUST be disabled. 746 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 748 If this switch is set to "false" for a given interface, then the 749 forwarding of IPv6 datagrams to and from this interface MUST be 750 disabled. However, the interface may participate in other routing 751 functions, such as routing protocols. 753 In addition, the "ietf-ip" module allows for configuring IPv4 and 754 IPv6 addresses and subnet masks on network layer interfaces. 755 Configuration of these parameters on an enabled interface MUST result 756 in an immediate creation of the corresponding direct route. The 757 destination prefix of this route is set according to the configured 758 IP address and subnet mask, and the interface is set as the outgoing 759 interface for that route. 761 6. Routing YANG Module 763 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 764 actual RFC number and all occurrences of the revision date below with 765 the date of RFC publication (and remove this note). 767 file "ietf-routing@2012-11-15.yang" 769 module ietf-routing { 771 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 773 prefix "rt"; 775 import ietf-yang-types { 776 prefix "yang"; 777 } 779 import ietf-inet-types { 780 prefix "inet"; 781 } 783 import ietf-interfaces { 784 prefix "if"; 785 } 787 import iana-afn-safi { 788 prefix "ianaaf"; 789 } 791 organization 792 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 794 contact 795 "WG Web: 796 WG List: 798 WG Chair: David Kessens 799 801 WG Chair: Juergen Schoenwaelder 802 804 Editor: Ladislav Lhotka 805 806 "; 808 description 809 "This YANG module defines essential components that may be used 810 for configuring a routing subsystem. 812 Copyright (c) 2012 IETF Trust and the persons identified as 813 authors of the code. All rights reserved. 815 Redistribution and use in source and binary forms, with or 816 without modification, is permitted pursuant to, and subject to 817 the license terms contained in, the Simplified BSD License set 818 forth in Section 4.c of the IETF Trust's Legal Provisions 819 Relating to IETF Documents 820 (http://trustee.ietf.org/license-info). 822 This version of this YANG module is part of RFC XXXX; see the 823 RFC itself for full legal notices. 824 "; 826 revision 2012-11-15 { 827 description 828 "Initial revision."; 829 reference 830 "RFC XXXX: A YANG Data Model for Routing Management"; 831 } 833 /* Identities */ 835 identity router-type { 836 description 837 "Base identity from which router type identities are derived. 839 It is primarily intended for discriminating among different 840 types of logical routers or router virtualization. 841 "; 842 } 844 identity standard-router { 845 base router-type; 846 description 847 "This identity represents a standard router."; 848 } 850 identity routing-protocol { 851 description 852 "Base identity from which routing protocol identities are 853 derived."; 854 } 856 identity direct { 857 base routing-protocol; 858 description 859 "Routing pseudo-protocol which provides routes to directly 860 connected networks."; 861 } 863 identity static { 864 base routing-protocol; 865 description 866 "Static routing pseudo-protocol."; 867 } 869 identity route-filter { 870 description 871 "Base identity from which all route filters are derived."; 872 } 874 identity deny-all-route-filter { 875 base route-filter; 876 description 877 "Route filter that blocks all routes."; 878 } 880 identity allow-all-route-filter { 881 base route-filter; 882 description 883 "Route filter that permits all routes."; 884 } 886 /* Type Definitions */ 888 typedef router-ref { 889 type leafref { 890 path "/rt:routing/rt:router/rt:name"; 891 } 892 description 893 "This type is used for leafs that reference a router 894 instance."; 895 } 897 typedef routing-table-ref { 898 type leafref { 899 path "/rt:routing/rt:routing-tables/rt:routing-table/rt:name"; 900 } 901 description 902 "This type is used for leafs that reference a routing table."; 903 } 904 typedef route-filter-ref { 905 type leafref { 906 path "/rt:routing/rt:route-filters/rt:route-filter/rt:name"; 907 } 908 description 909 "This type is used for leafs that reference a route filter."; 910 } 912 /* Groupings */ 914 grouping afn-safi { 915 leaf address-family { 916 type ianaaf:address-family; 917 mandatory "true"; 918 description 919 "Address family."; 920 } 921 leaf safi { 922 type ianaaf:subsequent-address-family; 923 mandatory "true"; 924 description 925 "Subsequent address family."; 926 } 927 description 928 "This grouping provides two parameters specifying address 929 family and subsequent address family."; 930 } 932 grouping route-content { 933 description 934 "Generic parameters of routes."; 935 leaf outgoing-interface { 936 type if:interface-ref; 937 description 938 "Outgoing interface."; 939 } 940 } 942 /* RPC Methods */ 944 rpc active-route { 945 description 946 "Return the active route (or multiple routes, in the case of 947 multi-path routing) to a destination address. 949 Parameters 951 1. 'router-name', 952 2. 'destination-address'. 954 If the router instance with 'router-name' doesn't exist, then 955 this operation SHALL fail with error-tag 'data-missing' and 956 error-app-tag 'router-not-found'. 958 If no active route for 'destination-address' exists, no output 959 is returned - the server SHALL send an containing 960 a single element . 961 "; 962 input { 963 leaf router-name { 964 type router-ref; 965 mandatory "true"; 966 description 967 "Name of the router instance whose forwarding information 968 base is being queried."; 969 } 970 container destination-address { 971 uses afn-safi; 972 description 973 "Network layer destination address. 975 Address family specific modules MUST augment this 976 container with a leaf named 'address'. 977 "; 978 } 979 } 980 output { 981 list route { 982 uses afn-safi; 983 uses route-content; 984 description 985 "List of active routes. 987 Route contents specific for each address family is 988 expected be defined through augmenting. 989 "; 990 } 991 } 992 } 994 rpc route-count { 995 description 996 "Return the current number of routes in a routing table. 998 Parameters: 1000 1. 'routing-table-name'. 1002 If the routing table with the name specified in 1003 'routing-table-name' doesn't exist, then this operation SHALL 1004 fail with error-tag 'data-missing' and error-app-tag 1005 'routing-table-not-found'. 1006 "; 1007 input { 1008 leaf routing-table { 1009 type routing-table-ref; 1010 mandatory "true"; 1011 description 1012 "Name of the routing table."; 1013 } 1014 } 1015 output { 1016 leaf number-of-routes { 1017 type uint32; 1018 mandatory "true"; 1019 description 1020 "Number of routes in the routing table."; 1021 } 1022 } 1023 } 1025 /* Data Nodes */ 1027 container routing { 1028 description 1029 "Routing parameters."; 1030 list router { 1031 key "name"; 1032 description 1033 "Each list entry is a container for configuration and state 1034 data of a single (logical) router instance. 1035 "; 1036 leaf name { 1037 type string; 1038 description 1039 "An arbitrary name of the router instance."; 1040 } 1041 leaf type { 1042 type identityref { 1043 base router-type; 1044 } 1045 default "rt:standard-router"; 1046 description 1047 "This leaf specifies the router type. 1049 It is primarily intended as a means for discriminating 1050 among different types of logical routers, route 1051 virtualization, master-slave arrangements etc., while 1052 keeping all such router instances in the same flat list. 1053 "; 1054 } 1055 leaf enabled { 1056 type boolean; 1057 default "true"; 1058 description 1059 "Enable/disable the router instance. 1061 If this parameter is false, the parent router instance is 1062 disabled, despite any other configuration that might be 1063 present. 1064 "; 1065 } 1066 leaf router-id { 1067 type inet:ipv4-address; 1068 description 1069 "Global router ID in the form of an IPv4 address. 1071 An implementation MAY select a value if this parameter is 1072 not configured. 1074 Routing protocols MAY override this global parameter 1075 inside their configuration. 1076 "; 1077 } 1078 leaf description { 1079 type string; 1080 description 1081 "Textual description of the router."; 1082 } 1083 container main-routing-tables { 1084 description 1085 "Main routing tables used by the router instance."; 1086 list main-routing-table { 1087 must "address-family=/routing/routing-tables/" 1088 + "routing-table[name=current()/name]/" 1089 + "address-family and safi=/routing/routing-tables/" 1090 + "routing-table[name=current()/name]/safi" { 1091 error-message "Address family mismatch."; 1092 description 1093 "The entry's address family MUST match that of the 1094 referenced routing table."; 1095 } 1096 key "address-family safi"; 1097 description 1098 "Each list entry specifies the main routing table for one 1099 address family. 1101 The main routing table is operationally connected to all 1102 routing protocols for which a connected routing table 1103 has not been explicitly configured. 1105 The 'direct' pseudo-protocol is always connected to the 1106 main routing table. 1108 Address families that don't have their entry in this 1109 list MUST NOT be used in the rest of the router instance 1110 configuration. 1111 "; 1112 uses afn-safi; 1113 leaf name { 1114 type routing-table-ref; 1115 description 1116 "Name of an existing routing table to be used as the 1117 main routing table for the given router instance and 1118 address family."; 1119 } 1120 } 1121 } 1122 container interfaces { 1123 description 1124 "Router interface parameters."; 1125 list interface { 1126 key "name"; 1127 description 1128 "List of network layer interfaces assigned to the router 1129 instance."; 1130 leaf name { 1131 type if:interface-ref; 1132 description 1133 "A reference to the name of a configured network layer 1134 interface."; 1135 } 1136 } 1137 } 1138 container routing-protocols { 1139 description 1140 "Container for the list of configured routing protocol 1141 instances."; 1142 list routing-protocol { 1143 key "name"; 1144 description 1145 "An instance of a routing protocol."; 1146 leaf name { 1147 type string; 1148 description 1149 "An arbitrary name of the routing protocol instance."; 1150 } 1151 leaf description { 1152 type string; 1153 description 1154 "Textual description of the routing protocol 1155 instance."; 1156 } 1157 leaf enabled { 1158 type boolean; 1159 default "true"; 1160 description 1161 "Enable/disable the routing protocol instance. 1163 If this parameter is false, the parent routing 1164 protocol instance is disabled, despite any other 1165 configuration that might be present. 1166 "; 1167 } 1168 leaf type { 1169 type identityref { 1170 base routing-protocol; 1171 } 1172 mandatory "true"; 1173 description 1174 "Type of the routing protocol - an identity derived 1175 from the 'routing-protocol' base identity."; 1176 } 1177 container connected-routing-tables { 1178 description 1179 "Container for connected routing tables."; 1180 list connected-routing-table { 1181 must "not(/routing/routing-tables/" 1182 + "routing-table[name=current()/" 1183 + "preceding-sibling::connected-routing-table/" 1184 + "name]/address-family=/routing/routing-tables/" 1185 + "routing-table[name=current()/name]/" 1186 + "address-family and /routing/routing-tables/" 1187 + "routing-table[name=current()/" 1188 + "preceding-sibling::connected-routing-table/" 1189 + "name]/safi=/routing/routing-tables/" 1190 + "routing-table[name=current()/name]/safi)" { 1191 error-message "Duplicate address family for " 1192 + "connected routing tables."; 1194 description 1195 "For each AFN/SAFI pair there MUST NOT be more than 1196 one connected routing table."; 1197 } 1198 key "name"; 1199 description 1200 "List of routing tables to which the routing protocol 1201 instance is connected (at most one routing table per 1202 address family). 1204 If no connected routing table is configured for an 1205 address family, the routing protocol MUST be 1206 operationally connected to the main routing table 1207 for that address family. 1208 "; 1209 leaf name { 1210 must "../../../type != 'rt:direct' or " 1211 + "../../../../../main-routing-tables/ " 1212 + "main-routing-table/name=." { 1213 error-message "The 'direct' protocol can be " 1214 + "connected only to a main routing " 1215 + "table."; 1216 description 1217 "For the 'direct' pseudo-protocol, the connected 1218 routing table must always be a main routing 1219 table."; 1220 } 1221 type routing-table-ref; 1222 description 1223 "Name of an existing routing table."; 1224 } 1225 leaf import-filter { 1226 type route-filter-ref; 1227 description 1228 "Reference to a route filter that is used for 1229 filtering routes passed from this routing protocol 1230 instance to the routing table specified by the 1231 'name' sibling node. 1233 If this leaf is not present, the behavior is 1234 protocol-specific, but typically it means that all 1235 routes are accepted. 1236 "; 1237 } 1238 leaf export-filter { 1239 type route-filter-ref; 1240 description 1241 "Reference to a route filter that is used for 1242 filtering routes passed from the routing table 1243 specified by the 'name' sibling node to this 1244 routing protocol instance. 1246 If this leaf is not present, the behavior is 1247 protocol-specific - typically it means that all 1248 routes are accepted. 1250 The 'direct' and 'static' pseudo-protocols accept 1251 no routes from any routing table. 1252 "; 1253 } 1254 } 1255 } 1256 container static-routes { 1257 when "../type='rt:static'" { 1258 description 1259 "This container is only valid for the 'static' 1260 routing protocol."; 1261 } 1262 description 1263 "Configuration of 'static' pseudo-protocol. 1265 Address family specific modules augment this node with 1266 their lists of routes. 1267 "; 1268 } 1269 } 1270 } 1271 } 1272 container routing-tables { 1273 description 1274 "Container for configured routing tables."; 1275 list routing-table { 1276 key "name"; 1277 description 1278 "Each entry represents a routing table identified by the 1279 'name' key. All routes in a routing table MUST belong to 1280 the same address family."; 1281 leaf name { 1282 type string; 1283 description 1284 "An arbitrary name of the routing table."; 1285 } 1286 uses afn-safi; 1287 leaf description { 1288 type string; 1289 description 1290 "Textual description of the routing table."; 1291 } 1292 container routes { 1293 config "false"; 1294 description 1295 "Current contents of the routing table (state data)."; 1296 list route { 1297 description 1298 "A routing table entry. This data node MUST be 1299 augmented with information specific for routes of each 1300 address family."; 1301 uses route-content; 1302 leaf source-protocol { 1303 type string; 1304 mandatory "true"; 1305 description 1306 'Routing protocol instance from which the route 1307 originated. 1309 It must be either "direct" or the name of a 1310 configured routing protocol instance. 1311 '; 1312 } 1313 leaf last-updated { 1314 type yang:date-and-time; 1315 description 1316 "Time stamp of the last modification of the route. If 1317 the route was never modified, it is the time when 1318 the route was inserted into the routing table."; 1319 } 1320 } 1321 } 1322 container recipient-routing-tables { 1323 description 1324 "Container for recipient routing tables."; 1325 list recipient-routing-table { 1326 must "name != ../../name" { 1327 error-message "Source and recipient routing tables " 1328 + "are identical."; 1329 description 1330 "A routing table MUST NOT appear among its recipient 1331 routing tables."; 1332 } 1333 must "/routing/routing-tables/" 1334 + "routing-table[name=current()/name]/" 1335 + "address-family=../../address-family and /routing/" 1336 + "routing-tables/routing-table[name=current()/name]/" 1337 + "safi=../../safi" { 1339 error-message "Address family mismatch."; 1340 description 1341 "Address family of the recipient routing table MUST 1342 match the source table."; 1343 } 1344 key "name"; 1345 description 1346 "List of routing tables that receive routes from this 1347 routing table."; 1348 leaf name { 1349 type routing-table-ref; 1350 description 1351 "The name of the recipient routing table."; 1352 } 1353 leaf filter { 1354 type route-filter-ref; 1355 description 1356 "A route filter which is applied to the routes passed 1357 to the recipient routing table."; 1358 } 1359 } 1360 } 1361 } 1362 } 1363 container route-filters { 1364 description 1365 "Container for configured route filters."; 1366 list route-filter { 1367 key "name"; 1368 description 1369 "Route filters are used for filtering and/or manipulating 1370 routes that are passed between a routing protocol and a 1371 routing table or vice versa, or between two routing 1372 tables. 1374 It is expected that other modules augment this list with 1375 contents specific for a particular route filter type. 1376 "; 1377 leaf name { 1378 type string; 1379 description 1380 "An arbitrary name of the route filter."; 1381 } 1382 leaf description { 1383 type string; 1384 description 1385 "Textual description of the route filter."; 1386 } 1387 leaf type { 1388 type identityref { 1389 base route-filter; 1390 } 1391 mandatory "true"; 1392 description 1393 "Type of the route-filter - an identity derived from the 1394 'route-filter' base identity."; 1395 } 1396 } 1397 } 1398 } 1399 } 1401 1403 7. IPv4 Unicast Routing YANG Module 1405 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1406 actual RFC number and all occurrences of the revision date below with 1407 the date of RFC publication (and remove this note). 1409 file "ietf-ipv4-unicast-routing@2012-11-15.yang" 1411 module ietf-ipv4-unicast-routing { 1413 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1415 prefix "v4ur"; 1417 import ietf-routing { 1418 prefix "rt"; 1419 } 1421 import ietf-inet-types { 1422 prefix "inet"; 1423 } 1425 organization 1426 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1428 contact 1429 "WG Web: 1430 WG List: 1432 WG Chair: David Kessens 1433 1435 WG Chair: Juergen Schoenwaelder 1436 1438 Editor: Ladislav Lhotka 1439 1440 "; 1442 description 1443 "This YANG module augments the 'ietf-routing' module with basic 1444 configuration and state data for IPv4 unicast routing. 1446 Copyright (c) 2012 IETF Trust and the persons identified as 1447 authors of the code. All rights reserved. 1449 Redistribution and use in source and binary forms, with or 1450 without modification, is permitted pursuant to, and subject to 1451 the license terms contained in, the Simplified BSD License set 1452 forth in Section 4.c of the IETF Trust's Legal Provisions 1453 Relating to IETF Documents 1454 (http://trustee.ietf.org/license-info). 1456 This version of this YANG module is part of RFC XXXX; see the 1457 RFC itself for full legal notices. 1458 "; 1460 revision 2012-11-15 { 1461 description 1462 "Initial revision."; 1463 reference 1464 "RFC XXXX: A YANG Data Model for Routing Management"; 1465 } 1467 /* Groupings */ 1469 grouping route-content { 1470 description 1471 "Parameters of IPv4 unicast routes."; 1472 leaf dest-prefix { 1473 type inet:ipv4-prefix; 1474 description 1475 "IPv4 destination prefix."; 1476 } 1477 leaf next-hop { 1478 type inet:ipv4-address; 1479 description 1480 "IPv4 address of the next hop."; 1481 } 1482 } 1484 /* RPC Methods */ 1486 augment "/rt:active-route/rt:input/rt:destination-address" { 1487 when "address-family='ipv4' and safi='nlri-unicast'" { 1488 description 1489 "This augment is valid only for IPv4 unicast."; 1490 } 1491 description 1492 "The 'address' leaf augments the 'rt:destination-address' 1493 parameter of the 'rt:active-route' operation."; 1494 leaf address { 1495 type inet:ipv4-address; 1496 description 1497 "IPv4 destination address."; 1498 } 1500 } 1502 augment "/rt:active-route/rt:output/rt:route" { 1503 when "address-family='ipv4' and safi='nlri-unicast'" { 1504 description 1505 "This augment is valid only for IPv4 unicast."; 1506 } 1507 description 1508 "Contents of the reply to 'rt:active-route' operation."; 1509 uses route-content; 1510 } 1512 /* Data nodes */ 1514 augment "/rt:routing/rt:router/rt:routing-protocols/" 1515 + "rt:routing-protocol/rt:static-routes" { 1516 description 1517 "This augment defines the configuration of the 'static' 1518 pseudo-protocol with data specific for IPv4 unicast."; 1519 container ipv4 { 1520 description 1521 "Configuration of a 'static' pseudo-protocol instance 1522 consists of a list of routes."; 1523 list route { 1524 key "id"; 1525 ordered-by "user"; 1526 description 1527 "A user-ordered list of static routes."; 1528 leaf id { 1529 type uint32 { 1530 range "1..max"; 1531 } 1532 description 1533 "Numeric identifier of the route. 1535 It is not required that the routes be sorted by their 1536 'id'. 1537 "; 1538 } 1539 leaf description { 1540 type string; 1541 description 1542 "Textual description of the route."; 1543 } 1544 uses rt:route-content; 1545 uses route-content { 1546 refine "dest-prefix" { 1547 mandatory "true"; 1549 } 1550 } 1551 } 1552 } 1553 } 1555 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 1556 + "rt:route" { 1557 when "../../rt:address-family = 'ipv4' and ../../rt:safi = " 1558 + "'nlri-unicast'" { 1559 description 1560 "This augment is valid only for IPv4 unicast."; 1561 } 1562 description 1563 "This augment defines the content of IPv4 unicast routes."; 1564 uses route-content; 1565 } 1566 } 1568 1570 8. IPv6 Unicast Routing YANG Module 1572 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1573 actual RFC number and all occurrences of the revision date below with 1574 the date of RFC publication (and remove this note). 1576 file "ietf-ipv6-unicast-routing@2012-11-15.yang" 1578 module ietf-ipv6-unicast-routing { 1580 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1582 prefix "v6ur"; 1584 import ietf-routing { 1585 prefix "rt"; 1586 } 1588 import ietf-inet-types { 1589 prefix "inet"; 1590 } 1592 import ietf-interfaces { 1593 prefix "if"; 1594 } 1596 import ietf-ip { 1597 prefix "ip"; 1598 } 1600 organization 1601 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1603 contact 1604 "WG Web: 1605 WG List: 1607 WG Chair: David Kessens 1608 1610 WG Chair: Juergen Schoenwaelder 1611 1613 Editor: Ladislav Lhotka 1614 1615 "; 1617 description 1618 "This YANG module augments the 'ietf-routing' module with basic 1619 configuration and state data for IPv6 unicast routing. 1621 Copyright (c) 2012 IETF Trust and the persons identified as 1622 authors of the code. All rights reserved. 1624 Redistribution and use in source and binary forms, with or 1625 without modification, is permitted pursuant to, and subject to 1626 the license terms contained in, the Simplified BSD License set 1627 forth in Section 4.c of the IETF Trust's Legal Provisions 1628 Relating to IETF Documents 1629 (http://trustee.ietf.org/license-info). 1631 This version of this YANG module is part of RFC XXXX; see the 1632 RFC itself for full legal notices. 1633 "; 1635 revision 2012-11-15 { 1636 description 1637 "Initial revision."; 1638 reference 1639 "RFC XXXX: A YANG Data Model for Routing Management"; 1640 } 1642 /* Groupings */ 1644 grouping route-content { 1645 description 1646 "Specific parameters of IPv6 unicast routes."; 1647 leaf dest-prefix { 1648 type inet:ipv6-prefix; 1649 description 1650 "IPv6 destination prefix."; 1651 } 1652 leaf next-hop { 1653 type inet:ipv6-address; 1654 description 1655 "IPv6 address of the next hop."; 1656 } 1657 } 1659 /* RPC Methods */ 1661 augment "/rt:active-route/rt:input/rt:destination-address" { 1662 when "address-family='ipv6' and safi='nlri-unicast'" { 1663 description 1664 "This augment is valid only for IPv6 unicast."; 1665 } 1666 description 1667 "The 'address' leaf augments the 'rt:destination-address' 1668 parameter of the 'rt:active-route' operation."; 1669 leaf address { 1670 type inet:ipv6-address; 1671 description 1672 "IPv6 destination address."; 1673 } 1674 } 1676 augment "/rt:active-route/rt:output/rt:route" { 1677 when "address-family='ipv6' and safi='nlri-unicast'" { 1678 description 1679 "This augment is valid only for IPv6 unicast."; 1680 } 1681 description 1682 "Contents of the reply to 'rt:active-route' operation."; 1683 uses route-content; 1684 } 1686 /* Data nodes */ 1688 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 1689 when "/if:interfaces/if:interface[name=current()/name]/ip:ipv6/" 1690 + "ip:enabled='true'" { 1691 description 1692 "This augment is only valid for router interfaces with 1693 enabled IPv6."; 1694 } 1695 description 1696 "IPv6-specific parameters of router interfaces."; 1697 container ipv6-router-advertisements { 1698 description 1699 "Parameters of IPv6 Router Advertisements."; 1700 leaf send-advertisements { 1701 type boolean; 1702 default "false"; 1703 description 1704 "A flag indicating whether or not the router sends periodic 1705 Router Advertisements and responds to Router 1706 Solicitations."; 1707 reference 1708 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1709 AdvSendAdvertisements."; 1710 } 1711 leaf max-rtr-adv-interval { 1712 type uint16 { 1713 range "4..1800"; 1715 } 1716 units "seconds"; 1717 default "600"; 1718 description 1719 "The maximum time allowed between sending unsolicited 1720 multicast Router Advertisements from the interface."; 1721 reference 1722 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1723 MaxRtrAdvInterval."; 1724 } 1725 leaf min-rtr-adv-interval { 1726 type uint16 { 1727 range "3..1350"; 1728 } 1729 must ". <= 0.75 * ../max-rtr-adv-interval" { 1730 description 1731 "The value MUST NOT be greater than 75 % of 1732 'max-rtr-adv-interval'."; 1733 } 1734 units "seconds"; 1735 description 1736 "The minimum time allowed between sending unsolicited 1737 multicast Router Advertisements from the interface. 1739 The default value to be used operationally if this leaf is 1740 not configured is determined as follows: 1742 - if max-rtr-adv-interval >= 9 seconds, the default value 1743 is 0.33 * max-rtr-adv-interval; 1745 - otherwise it is 0.75 * max-rtr-adv-interval. 1746 "; 1747 reference 1748 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1749 MinRtrAdvInterval."; 1750 } 1751 leaf managed-flag { 1752 type boolean; 1753 default "false"; 1754 description 1755 "The boolean value to be placed in the 'Managed address 1756 configuration' flag field in the Router Advertisement."; 1757 reference 1758 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1759 AdvManagedFlag."; 1760 } 1761 leaf other-config-flag { 1762 type boolean; 1763 default "false"; 1764 description 1765 "The boolean value to be placed in the 'Other 1766 configuration' flag field in the Router Advertisement."; 1767 reference 1768 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1769 AdvOtherConfigFlag."; 1770 } 1771 leaf link-mtu { 1772 type uint32; 1773 default "0"; 1774 description 1775 "The value to be placed in MTU options sent by the router. 1776 A value of zero indicates that no MTU options are sent."; 1777 reference 1778 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1779 AdvLinkMTU."; 1780 } 1781 leaf reachable-time { 1782 type uint32 { 1783 range "0..3600000"; 1784 } 1785 units "milliseconds"; 1786 default "0"; 1787 description 1788 "The value to be placed in the Reachable Time field in the 1789 Router Advertisement messages sent by the router. The 1790 value zero means unspecified (by this router)."; 1791 reference 1792 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1793 AdvReachableTime."; 1794 } 1795 leaf retrans-timer { 1796 type uint32; 1797 units "milliseconds"; 1798 default "0"; 1799 description 1800 "The value to be placed in the Retrans Timer field in the 1801 Router Advertisement messages sent by the router. The 1802 value zero means unspecified (by this router)."; 1803 reference 1804 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1805 AdvRetransTimer."; 1806 } 1807 leaf cur-hop-limit { 1808 type uint8; 1809 default "64"; 1810 description 1811 "The default value to be placed in the Cur Hop Limit field 1812 in the Router Advertisement messages sent by the router. 1813 The value should be set to the current diameter of the 1814 Internet. The value zero means unspecified (by this 1815 router). 1817 The default SHOULD be set to the value specified in IANA 1818 Assigned Numbers that was in effect at the time of 1819 implementation. 1820 "; 1821 reference 1822 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1823 AdvCurHopLimit. 1825 IANA: IP Parameters, 1826 http://www.iana.org/assignments/ip-parameters 1827 "; 1828 } 1829 leaf default-lifetime { 1830 type uint16 { 1831 range "0..9000"; 1832 } 1833 units "seconds"; 1834 description 1835 "The value to be placed in the Router Lifetime field of 1836 Router Advertisements sent from the interface, in seconds. 1837 MUST be either zero or between max-rtr-adv-interval and 1838 9000 seconds. A value of zero indicates that the router is 1839 not to be used as a default router. These limits may be 1840 overridden by specific documents that describe how IPv6 1841 operates over different link layers. 1843 The default value is dynamic and SHOULD be set to 3 * 1844 max-rtr-adv-interval. 1845 "; 1846 reference 1847 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1848 AdvDefaultLifeTime."; 1849 } 1850 container prefix-list { 1851 description 1852 "A list of prefixes to be placed in Prefix Information 1853 options in Router Advertisement messages sent from the 1854 interface. 1856 By default, all prefixes that the router advertises via 1857 routing protocols as being on-link for the interface from 1858 which the advertisement is sent. The link-local prefix 1859 SHOULD NOT be included in the list of advertised prefixes. 1860 "; 1861 reference 1862 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1863 AdvPrefixList."; 1864 list prefix { 1865 key "prefix-spec"; 1866 description 1867 "Advertised prefix entry."; 1868 leaf prefix-spec { 1869 type inet:ipv6-prefix; 1870 description 1871 "IPv6 address prefix."; 1872 } 1873 choice control-adv-prefixes { 1874 default "advertise"; 1875 description 1876 "The prefix either may be explicitly removed from the 1877 set of advertised prefixes, or parameters with which 1878 it is advertised may be specified (default case)."; 1879 leaf no-advertise { 1880 type empty; 1881 description 1882 "The prefix will not be advertised. 1884 This can be used for removing the prefix from the 1885 default set of advertised prefixes. 1886 "; 1887 } 1888 case advertise { 1889 leaf valid-lifetime { 1890 type uint32; 1891 units "seconds"; 1892 default "2592000"; 1893 description 1894 "The value to be placed in the Valid Lifetime in 1895 the Prefix Information option, in seconds. The 1896 designated value of all 1's (0xffffffff) 1897 represents infinity. 1898 "; 1899 reference 1900 "RFC 4861: Neighbor Discovery for IP version 6 1901 (IPv6) - AdvValidLifetime."; 1902 } 1903 leaf on-link-flag { 1904 type boolean; 1905 default "true"; 1906 description 1907 "The value to be placed in the on-link flag 1908 ('L-bit') field in the Prefix Information 1909 option."; 1910 reference 1911 "RFC 4861: Neighbor Discovery for IP version 6 1912 (IPv6) - AdvOnLinkFlag."; 1913 } 1914 leaf preferred-lifetime { 1915 type uint32; 1916 units "seconds"; 1917 must ". <= ../valid-lifetime" { 1918 description 1919 "This value MUST NOT be greater than 1920 valid-lifetime."; 1921 } 1922 default "604800"; 1923 description 1924 "The value to be placed in the Preferred Lifetime 1925 in the Prefix Information option, in seconds. The 1926 designated value of all 1's (0xffffffff) 1927 represents infinity. 1928 "; 1929 reference 1930 "RFC 4861: Neighbor Discovery for IP version 6 1931 (IPv6) - AdvPreferredLifetime."; 1932 } 1933 leaf autonomous-flag { 1934 type boolean; 1935 default "true"; 1936 description 1937 "The value to be placed in the Autonomous Flag 1938 field in the Prefix Information option."; 1939 reference 1940 "RFC 4861: Neighbor Discovery for IP version 6 1941 (IPv6) - AdvAutonomousFlag."; 1942 } 1943 } 1944 } 1945 } 1946 } 1947 } 1948 } 1950 augment "/rt:routing/rt:router/rt:routing-protocols/" 1951 + "rt:routing-protocol/rt:static-routes" { 1952 description 1953 "This augment defines the configuration of the 'static' 1954 pseudo-protocol with data specific for IPv6 unicast."; 1956 container ipv6 { 1957 description 1958 "Configuration of a 'static' pseudo-protocol instance 1959 consists of a list of routes."; 1960 list route { 1961 key "id"; 1962 ordered-by "user"; 1963 description 1964 "A user-ordered list of static routes."; 1965 leaf id { 1966 type uint32 { 1967 range "1..max"; 1968 } 1969 description 1970 "Numeric identifier of the route. 1972 It is not required that the routes be sorted by their 1973 'id'. 1974 "; 1975 } 1976 leaf description { 1977 type string; 1978 description 1979 "Textual description of the route."; 1980 } 1981 uses rt:route-content; 1982 uses route-content { 1983 refine "dest-prefix" { 1984 mandatory "true"; 1985 } 1986 } 1987 } 1988 } 1989 } 1991 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 1992 + "rt:route" { 1993 when "../../rt:address-family = 'ipv6' and ../../rt:safi = " 1994 + "'nlri-unicast'" { 1995 description 1996 "This augment is valid only for IPv6 unicast."; 1997 } 1998 description 1999 "This augment defines the content of IPv6 unicast routes."; 2000 uses route-content; 2001 } 2002 } 2003 2005 9. IANA Considerations 2007 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2008 actual RFC number (and remove this note). 2010 This document registers the following namespace URIs in the IETF XML 2011 registry [RFC3688]: 2013 ---------------------------------------------------------- 2014 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2016 Registrant Contact: The IESG. 2018 XML: N/A, the requested URI is an XML namespace. 2019 ---------------------------------------------------------- 2021 ---------------------------------------------------------- 2022 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2024 Registrant Contact: The IESG. 2026 XML: N/A, the requested URI is an XML namespace. 2027 ---------------------------------------------------------- 2029 ---------------------------------------------------------- 2030 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2032 Registrant Contact: The IESG. 2034 XML: N/A, the requested URI is an XML namespace. 2035 ---------------------------------------------------------- 2037 This document registers the following YANG modules in the YANG Module 2038 Names registry [RFC6020]: 2040 ------------------------------------------------------------------- 2041 name: ietf-routing 2042 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2043 prefix: rt 2044 reference: RFC XXXX 2045 ------------------------------------------------------------------- 2047 ------------------------------------------------------------------- 2048 name: ietf-ipv4-unicast-routing 2049 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2050 prefix: v4ur 2051 reference: RFC XXXX 2052 ------------------------------------------------------------------- 2054 ------------------------------------------------------------------- 2055 name: ietf-ipv6-unicast-routing 2056 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2057 prefix: v6ur 2058 reference: RFC XXXX 2059 ------------------------------------------------------------------- 2061 10. Security Considerations 2063 Configuration and state data conforming to the core routing data 2064 model (defined in this document) are designed to be accessed via the 2065 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2066 transport layer and the mandatory-to-implement secure transport is 2067 SSH [RFC6242]. 2069 A number of data nodes defined in the YANG modules belonging to the 2070 core routing data model are writable/creatable/deletable (i.e., 2071 "config true" in YANG terms, which is the default). These data nodes 2072 may be considered sensitive or vulnerable in some network 2073 environments. Write operations to these data nodes, such as "edit- 2074 config", can have negative effects on the network if the protocol 2075 operations are not properly protected. 2077 The vulnerable "config true" subtrees and data nodes are the 2078 following: 2080 /routing/router/interfaces/interface This list assigns a network 2081 layer interface to a router instance and may also specify 2082 interface parameters related to routing. 2084 /routing/router/routing-protocols/routing-protocol This list 2085 specifies the routing protocols configured on a device. 2087 /routing/route-filters/route-filter This list specifies the 2088 configured route filters which represent administrative policies 2089 for redistributing and modifying routing information. 2091 /routing/routing-tables/routing-table This list specifies the 2092 configured routing tables used by the device. 2094 Unauthorized access to any of these lists can adversely affect the 2095 routing subsystem of both the local device and the network. This may 2096 lead to network malfunctions, delivery of packets to inappropriate 2097 destinations and other problems. 2099 11. Acknowledgments 2101 The author wishes to thank Martin Bjorklund, Joel Halpern, 2102 Wes Hardaker, Andrew McGregor, Thomas Morin, Tom Petch, 2103 Bruno Rijsman, Juergen Schoenwaelder, Phil Shafer, Dave Thaler and 2104 Yi Yang for their helpful comments and suggestions. 2106 12. References 2108 12.1. Normative References 2110 [IANA-IF-AF] 2111 Bjorklund, M., "IANA Interface Type and Address Family 2112 YANG Modules", draft-ietf-netmod-iana-if-type-04 (work in 2113 progress), June 2012. 2115 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2116 Requirement Levels", BCP 14, RFC 2119, March 1997. 2118 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2119 January 2004. 2121 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2122 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2123 September 2007. 2125 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2126 Network Configuration Protocol (NETCONF)", RFC 6020, 2127 September 2010. 2129 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 2130 RFC 6021, September 2010. 2132 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2133 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2134 June 2011. 2136 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2137 Configuration", draft-ietf-netmod-interfaces-cfg-08 (work 2138 in progress), November 2012. 2140 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 2141 draft-ietf-netmod-ip-cfg-07 (work in progress), 2142 November 2012. 2144 12.2. Informative References 2146 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2147 Data Model Documents", RFC 6087, January 2011. 2149 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2150 Shell (SSH)", RFC 6242, June 2011. 2152 Appendix A. The Complete Data Tree 2154 This appendix presents the complete data tree of the core routing 2155 data model. See Section 2.2 for an explanation of symbols. Data 2156 type of every leaf node is shown near the right end of the 2157 corresponding line. 2159 +--rw routing 2160 +--rw router [name] 2161 | +--rw name string 2162 | +--rw type? identityref 2163 | +--rw enabled? boolean 2164 | +--rw router-id? inet:ipv4-address 2165 | +--rw description? string 2166 | +--rw main-routing-tables 2167 | | +--rw main-routing-table [address-family safi] 2168 | | +--rw address-family ianaaf:address-family 2169 | | +--rw safi ianaaf:subsequent-address-family 2170 | | +--rw name? routing-table-ref 2171 | +--rw interfaces 2172 | | +--rw interface [name] 2173 | | +--rw name if:interface-ref 2174 | | +--rw v6ur:ipv6-router-advertisements 2175 | | +--rw v6ur:send-advertisements? boolean 2176 | | +--rw v6ur:max-rtr-adv-interval? uint16 2177 | | +--rw v6ur:min-rtr-adv-interval? uint16 2178 | | +--rw v6ur:managed-flag? boolean 2179 | | +--rw v6ur:other-config-flag? boolean 2180 | | +--rw v6ur:link-mtu? uint32 2181 | | +--rw v6ur:reachable-time? uint32 2182 | | +--rw v6ur:retrans-timer? uint32 2183 | | +--rw v6ur:cur-hop-limit? uint8 2184 | | +--rw v6ur:default-lifetime? uint16 2185 | | +--rw v6ur:prefix-list 2186 | | +--rw v6ur:prefix [prefix-spec] 2187 | | +--rw v6ur:prefix-spec inet:ipv6-prefix 2188 | | +--rw (control-adv-prefixes)? 2189 | | +--:(no-advertise) 2190 | | | +--rw v6ur:no-advertise? empty 2191 | | +--:(advertise) 2192 | | +--rw v6ur:valid-lifetime? uint32 2193 | | +--rw v6ur:on-link-flag? boolean 2194 | | +--rw v6ur:preferred-lifetime? uint32 2195 | | +--rw v6ur:autonomous-flag? boolean 2196 | +--rw routing-protocols 2197 | +--rw routing-protocol [name] 2198 | +--rw name string 2199 | +--rw description? string 2200 | +--rw enabled? boolean 2201 | +--rw type identityref 2202 | +--rw connected-routing-tables 2203 | | +--rw connected-routing-table [name] 2204 | | +--rw name routing-table-ref 2205 | | +--rw import-filter? route-filter-ref 2206 | | +--rw export-filter? route-filter-ref 2207 | +--rw static-routes 2208 | +--rw v4ur:ipv4 2209 | | +--rw v4ur:route [id] 2210 | | +--rw v4ur:id uint32 2211 | | +--rw v4ur:description? string 2212 | | +--rw v4ur:outgoing-interface? if:interface-ref 2213 | | +--rw v4ur:dest-prefix inet:ipv4-prefix 2214 | | +--rw v4ur:next-hop? inet:ipv4-address 2215 | +--rw v6ur:ipv6 2216 | +--rw v6ur:route [id] 2217 | +--rw v6ur:id uint32 2218 | +--rw v6ur:description? string 2219 | +--rw v6ur:outgoing-interface? if:interface-ref 2220 | +--rw v6ur:dest-prefix inet:ipv6-prefix 2221 | +--rw v6ur:next-hop? inet:ipv6-address 2222 +--rw routing-tables 2223 | +--rw routing-table [name] 2224 | +--rw name string 2225 | +--rw address-family ianaaf:address-family 2226 | +--rw safi ianaaf:subsequent-address-family 2227 | +--rw description? string 2228 | +--ro routes 2229 | | +--ro route 2230 | | +--ro outgoing-interface? if:interface-ref 2231 | | +--ro source-protocol string 2232 | | +--ro last-updated? yang:date-and-time 2233 | | +--ro v4ur:dest-prefix? inet:ipv4-prefix 2234 | | +--ro v4ur:next-hop? inet:ipv4-address 2235 | | +--ro v6ur:dest-prefix? inet:ipv6-prefix 2236 | | +--ro v6ur:next-hop? inet:ipv6-address 2237 | +--rw recipient-routing-tables 2238 | +--rw recipient-routing-table [name] 2239 | +--rw name routing-table-ref 2240 | +--rw filter? route-filter-ref 2241 +--rw route-filters 2242 +--rw route-filter [name] 2243 +--rw name string 2244 +--rw description? string 2245 +--rw type identityref 2247 Appendix B. Example: Adding a New Routing Protocol 2249 This appendix demonstrates how the core routing data model can be 2250 extended to support a new routing protocol. The YANG module 2251 "example-rip" shown below is intended only as an illustration rather 2252 than a real definition of a data model for the RIP routing protocol. 2253 For the sake of brevity, we do not follow all the guidelines 2254 specified in [RFC6087]. See also Section 4.4.2. 2256 module example-rip { 2258 namespace "http://example.com/rip"; 2260 prefix "rip"; 2262 import ietf-routing { 2263 prefix "rt"; 2264 } 2266 identity rip { 2267 base rt:routing-protocol; 2268 description 2269 "Identity for the RIP routing protocol."; 2270 } 2272 typedef rip-metric { 2273 type uint8 { 2274 range "0..16"; 2275 } 2276 } 2278 grouping route-content { 2279 description 2280 "This grouping defines RIP-specific route attributes."; 2281 leaf metric { 2282 type rip-metric; 2283 } 2284 leaf tag { 2285 type uint16; 2286 default "0"; 2287 description 2288 "This leaf may be used to carry additional info, e.g. AS 2289 number."; 2290 } 2291 } 2293 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 2294 + "rt:route" { 2296 description 2297 "RIP-specific route attributes."; 2298 uses route-content; 2299 } 2301 augment "/rt:active-route/rt:output/rt:route" { 2302 description 2303 "RIP-specific route attributes."; 2304 uses route-content; 2305 } 2307 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 2308 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 2309 + "'rip:rip'" { 2310 description 2311 'This augment is only valid for a routing protocol instance 2312 of type "rip".'; 2313 } 2314 container rip { 2315 description 2316 "Per-interface RIP configuration."; 2317 leaf enabled { 2318 type boolean; 2319 default "true"; 2320 } 2321 leaf metric { 2322 type rip-metric; 2323 default "1"; 2324 } 2325 } 2326 } 2328 augment "/rt:routing/rt:router/rt:routing-protocols/" 2329 + "rt:routing-protocol" { 2330 when "rt:type = 'rip:rip'" { 2331 description 2332 'This augment is only valid for a routing protocol instance 2333 of type "rip".'; 2334 } 2335 container rip { 2336 description 2337 "Global RIP configuration."; 2338 leaf update-interval { 2339 type uint8 { 2340 range "10..60"; 2341 } 2342 units "seconds"; 2343 default "30"; 2344 description 2345 "Time interval between periodic updates."; 2346 } 2347 } 2348 } 2349 } 2351 Appendix C. Example: NETCONF Reply 2353 This section contains a sample reply to the NETCONF message, 2354 which could be sent by a server supporting (i.e., advertising them in 2355 the NETCONF message) the following YANG modules: 2357 o ietf-interfaces [YANG-IF], 2359 o ietf-ip [YANG-IP], 2361 o ietf-routing (Section 6), 2363 o ietf-ipv4-unicast-routing (Section 7), 2365 o ietf-ipv6-unicast-routing (Section 8). 2367 We assume a simple network setup as shown in Figure 4: router "A" 2368 uses static default routes with the "ISP" router as the next hop. 2369 IPv6 router advertisements are configured only on the "eth1" 2370 interface and disabled on the upstream "eth0" interface. 2372 +-----------------+ 2373 | | 2374 | Router ISP | 2375 | | 2376 +--------+--------+ 2377 |2001:db8:0:1::2 2378 |192.0.2.2 2379 | 2380 | 2381 |2001:db8:0:1::1 2382 eth0|192.0.2.1 2383 +--------+--------+ 2384 | | 2385 | Router A | 2386 | | 2387 +--------+--------+ 2388 eth1|198.51.100.1 2389 |2001:db8:0:2::1 2390 | 2392 Figure 4: Example network configuration 2394 A reply to the NETCONF message sent by router "A" would then be 2395 as follows: 2397 2398 2406 2407 2408 2409 eth0 2410 ethernetCsmacd 2411 05:00.0 2412 2413 2414 192.0.2.1 2415 24 2416 2417 2418 2419 2420 2001:0db8:0:1::1 2421 64 2422 2423 2424 false 2425 2426 2427 2428 2429 eth1 2430 ethernetCsmacd 2431 05:00.1 2432 2433 2434 198.51.100.1 2435 24 2436 2437 2438 2439 2440 2001:0db8:0:2::1 2441 64 2442 2443 2444 false 2445 2446 2448 2449 2450 2451 2452 rtr0 2453 192.0.2.1 2454 Router A 2455 2456 2457 ipv4 2458 nlri-unicast 2459 ipv4-unicast 2460 2461 2462 ipv6 2463 nlri-unicast 2464 ipv6-unicast 2465 2466 2467 2468 2469 eth0 2470 2471 2472 eth1 2473 2474 true 2475 2476 2477 2001:db8:0:2::/64 2478 2479 2480 2481 2482 2483 2484 2485 st0 2486 2487 Static routing is used for the internal network. 2488 2489 rt:static 2490 2491 2492 2493 1 2494 0.0.0.0/0 2495 192.0.2.2 2497 2498 2499 2500 2501 1 2502 ::/0 2503 2001:db8:0:1::2 2504 2505 2506 2507 2508 2509 2510 2511 2512 ipv4-unicast 2513 ipv4 2514 nlri-unicast 2515 2516 2517 192.0.2.1/24 2518 eth0 2519 direct 2520 2012-10-02T17:11:27+01:00 2521 2522 2523 198.51.100.0/24 2524 eth1 2525 direct 2526 2012-10-02T17:11:27+01:00 2527 2528 2529 0.0.0.0/0 2530 st0 2531 192.0.2.2 2532 2012-10-02T18:02:45+01:00 2533 2534 2535 2536 2537 ipv6-unicast 2538 ipv6 2539 nlri-unicast 2540 2541 2542 2001:db8:0:1::/64 2543 eth0 2544 direct 2545 2012-10-02T17:11:27+01:00 2546 2547 2548 2001:db8:0:2::/64 2549 eth1 2550 direct 2551 2012-10-02T17:11:27+01:00 2552 2553 2554 ::/0 2555 2001:db8:0:1::2 2556 st0 2557 2012-10-02T18:02:45+01:00 2558 2559 2560 2561 2562 2563 2564 2566 Appendix D. Change Log 2568 RFC Editor: remove this section upon publication as an RFC. 2570 D.1. Changes Between Versions -05 and -06 2572 o Document title changed: "Configuration" was replaced by 2573 "Management". 2575 o New typedefs "routing-table-ref" and "route-filter-ref". 2577 o Double slashes "//" were removed from XPath expressions and 2578 replaced with the single "/". 2580 o Removed uniqueness requirement for "router-id". 2582 o Complete data tree is now in Appendix A. 2584 o Changed type of "source-protocol" from "leafref" to "string". 2586 o Clarified the relationship between routing protocol instances and 2587 connected routing tables. 2589 o Added a must constraint saying that a routing table connected to 2590 the direct pseudo-protocol must not be a main routing table. 2592 D.2. Changes Between Versions -04 and -05 2594 o Routing tables are now global, i.e., "routing-tables" is a child 2595 of "routing" rather than "router". 2597 o "must" statement for "static-routes" changed to "when". 2599 o Added "main-routing-tables" containing references to main routing 2600 tables for each address family. 2602 o Removed the defaults for "address-family" and "safi" and made them 2603 mandatory. 2605 o Removed the default for route-filter/type and made this leaf 2606 mandatory. 2608 o If there is no active route for a given destination, the "active- 2609 route" RPC returns no output. 2611 o Added "enabled" switch under "routing-protocol". 2613 o Added "router-type" identity and "type" leaf under "router". 2615 o Route attribute "age" changed to "last-updated", its type is 2616 "yang:date-and-time". 2618 o The "direct" pseudo-protocol is always connected to main routing 2619 tables. 2621 o Entries in the list of connected routing tables renamed from 2622 "routing-table" to "connected-routing-table". 2624 o Added "must" constraint saying that a routing table must not be 2625 its own recipient. 2627 D.3. Changes Between Versions -03 and -04 2629 o Changed "error-tag" for both RPC methods from "missing element" to 2630 "data-missing". 2632 o Removed the decrementing behavior for advertised IPv6 prefix 2633 parameters "valid-lifetime" and "preferred-lifetime". 2635 o Changed the key of the static route lists from "seqno" to "id" 2636 because the routes needn't be sorted. 2638 o Added 'must' constraint saying that "preferred-lifetime" must not 2639 be greater than "valid-lifetime". 2641 D.4. Changes Between Versions -02 and -03 2643 o Module "iana-afn-safi" moved to I-D "iana-if-type". 2645 o Removed forwarding table. 2647 o RPC "get-route" changed to "active-route". Its output is a list 2648 of routes (for multi-path routing). 2650 o New RPC "route-count". 2652 o For both RPCs, specification of negative responses was added. 2654 o Relaxed separation of router instances. 2656 o Assignment of interfaces to router instances needn't be disjoint. 2658 o Route filters are now global. 2660 o Added "allow-all-route-filter" for symmetry. 2662 o Added Section 5 about interactions with "ietf-interfaces" and 2663 "ietf-ip". 2665 o Added "router-id" leaf. 2667 o Specified the names for IPv4/IPv6 unicast main routing tables. 2669 o Route parameter "last-modified" changed to "age". 2671 o Added container "recipient-routing-tables". 2673 D.5. Changes Between Versions -01 and -02 2675 o Added module "ietf-ipv6-unicast-routing". 2677 o The example in Appendix C now uses IP addresses from blocks 2678 reserved for documentation. 2680 o Direct routes appear by default in the forwarding table. 2682 o Network layer interfaces must be assigned to a router instance. 2683 Additional interface configuration may be present. 2685 o The "when" statement is only used with "augment", "must" is used 2686 elsewhere. 2688 o Additional "must" statements were added. 2690 o The "route-content" grouping for IPv4 and IPv6 unicast now 2691 includes the material from the "ietf-routing" version via "uses 2692 rt:route-content". 2694 o Explanation of symbols in the tree representation of data model 2695 hierarchy. 2697 D.6. Changes Between Versions -00 and -01 2699 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2701 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2702 safi" module. 2704 o Names of some data nodes were changed, in particular "routing- 2705 process" is now "router". 2707 o The restriction of a single AFN/SAFI per router was lifted. 2709 o RPC operation "delete-route" was removed. 2711 o Illegal XPath references from "get-route" to the datastore were 2712 fixed. 2714 o Section "Security Considerations" was written. 2716 Author's Address 2718 Ladislav Lhotka 2719 CZ.NIC 2721 Email: lhotka@nic.cz