idnits 2.17.1 draft-ietf-netmod-routing-cfg-09.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 2176 has weird spacing: '...-family ian...' -- The document date (February 23, 2013) is 4079 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 23, 2013 5 Expires: August 27, 2013 7 A YANG Data Model for Routing Management 8 draft-ietf-netmod-routing-cfg-09 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 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 57 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5 58 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 60 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. The Design of the Core Routing Data Model . . . . . . . . . . 9 62 4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 4.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 12 64 4.2. Routes . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 14 66 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 16 67 4.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . . 16 68 4.4.2. Defining New Routing Protocols . . . . . . . . . . . . 17 69 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 18 70 4.6. RPC Operations . . . . . . . . . . . . . . . . . . . . . . 19 71 5. Interactions with Other YANG Modules . . . . . . . . . . . . . 20 72 5.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . . 20 73 5.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . . 20 74 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 22 75 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 36 76 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 40 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 52 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 54 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 54 83 Appendix A. The Complete Data Tree . . . . . . . . . . . . . . . 55 84 Appendix B. Example: Adding a New Routing Protocol . . . . . . . 57 85 Appendix C. Example: NETCONF Reply . . . . . . . . . . . . 60 86 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 65 87 D.1. Changes Between Versions -08 and -09 . . . . . . . . . . . 65 88 D.2. Changes Between Versions -07 and -08 . . . . . . . . . . . 65 89 D.3. Changes Between Versions -06 and -07 . . . . . . . . . . . 65 90 D.4. Changes Between Versions -05 and -06 . . . . . . . . . . . 65 91 D.5. Changes Between Versions -04 and -05 . . . . . . . . . . . 66 92 D.6. Changes Between Versions -03 and -04 . . . . . . . . . . . 67 93 D.7. Changes Between Versions -02 and -03 . . . . . . . . . . . 67 94 D.8. Changes Between Versions -01 and -02 . . . . . . . . . . . 68 95 D.9. Changes Between Versions -00 and -01 . . . . . . . . . . . 68 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 69 99 1. Introduction 101 This document contains a specification of the following YANG modules: 103 o Module "ietf-routing" provides generic components of a routing 104 data model. 106 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 107 module with additional data specific to IPv4 unicast. 109 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 110 module with additional data specific to IPv6 unicast, including 111 the router configuration variables required by [RFC4861]. 113 These modules together define the so-called core routing data model, 114 which is proposed as a basis for the development of data models for 115 configuration and management of more sophisticated routing systems. 116 While these three modules can be directly used for simple IP devices 117 with static routing, their main purpose is to provide essential 118 building blocks for more complicated setups involving multiple 119 routing protocols, multicast routing, additional address families, 120 and advanced functions such as route filtering or policy routing. To 121 this end, it is expected that the core routing data model will be 122 augmented by numerous modules developed by other IETF working groups. 124 2. Terminology and Notation 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 The following terms are defined in [RFC6241]: 132 o client 134 o message 136 o protocol operation 138 o server 140 The following terms are defined in [RFC6020]: 142 o augment 144 o configuration data 146 o data model 148 o data node 150 o mandatory node 152 o module 154 o state data 156 o RPC operation 158 2.1. Glossary of New Terms 160 active route: a route that is actually used for sending packets. If 161 there are multiple candidate routes with a matching destination 162 prefix, then it is up to the routing algorithm to select the 163 active route (or several active routes in the case of multi-path 164 routing). 166 core routing data model: YANG data model resulting from the 167 combination of "ietf-routing", "ietf-ipv4-unicast-routing" and 168 "ietf-ipv6-unicast-routing" modules. 170 direct route: a route to a directly connected network. 172 2.2. Tree Diagrams 174 A simplified graphical representation of the complete data tree is 175 presented in Appendix A, and similar diagrams of its various subtrees 176 appear in the main text. The meaning of the symbols in these 177 diagrams is as follows: 179 o Brackets "[" and "]" enclose list keys. 181 o Abbreviations before data node names: "rw" means configuration 182 (read-write) and "ro" state data (read-only). 184 o Symbols after data node names: "?" means an optional node and "*" 185 denotes a "leaf-list". 187 o Parentheses enclose choice and case nodes, and case nodes are also 188 marked with a colon (":"). 190 o Ellipsis ("...") stands for contents of subtrees that are not 191 shown. 193 2.3. Prefixes in Data Node Names 195 In this document, names of data nodes, RPC methods and other data 196 model objects are used mostly without a prefix, as long as it is 197 clear from the context in which YANG module each name is defined. 198 Otherwise, names are prefixed using the standard prefix associated 199 with the corresponding YANG module, as shown in Table 1. 201 +--------+---------------------------+--------------+ 202 | Prefix | YANG module | Reference | 203 +--------+---------------------------+--------------+ 204 | ianaaf | iana-afn-safi | [IANA-IF-AF] | 205 | | | | 206 | if | ietf-interfaces | [YANG-IF] | 207 | | | | 208 | ip | ietf-ip | [YANG-IP] | 209 | | | | 210 | rt | ietf-routing | Section 6 | 211 | | | | 212 | v4ur | ietf-ipv4-unicast-routing | Section 7 | 213 | | | | 214 | v6ur | ietf-ipv6-unicast-routing | Section 8 | 215 | | | | 216 | yang | ietf-yang-types | [RFC6021bis] | 217 | | | | 218 | inet | ietf-inet-types | [RFC6021bis] | 219 +--------+---------------------------+--------------+ 221 Table 1: Prefixes and corresponding YANG modules 223 3. Objectives 225 The initial design of the core routing data model was driven by the 226 following objectives: 228 o The data model should be suitable for the common address families, 229 in particular IPv4 and IPv6, and for unicast and multicast 230 routing, as well as Multiprotocol Label Switching (MPLS). 232 o Simple routing setups, such as static routing, should be 233 configurable in a simple way, ideally without any need to develop 234 additional YANG modules. 236 o On the other hand, the core routing framework must allow for 237 complicated setups involving multiple routing tables and multiple 238 routing protocols, as well as controlled redistributions of 239 routing information. 241 o Device vendors will want to map the data models built on this 242 generic framework to their proprietary data models and 243 configuration interfaces. Therefore, the framework should be 244 flexible enough to facilitate such a mapping and accommodate data 245 models with different logic. 247 4. The Design of the Core Routing Data Model 249 The core routing data model consists of three YANG modules. The 250 first module, "ietf-routing", defines the generic components of a 251 routing system. The other two modules, "ietf-ipv4-unicast-routing" 252 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 253 with additional data nodes that are needed for IPv4 and IPv6 unicast 254 routing, respectively. An abridged view of the data hierarchy is 255 shown in Figure 1. See Appendix A for the complete data tree. 257 +--rw routing 258 +--rw router [name] 259 | +--rw name 260 | +--rw type? 261 | +--rw enabled? 262 | +--rw router-id? 263 | +--rw description? 264 | +--rw main-routing-tables 265 | | +--rw main-routing-table [address-family safi] 266 | | +--rw address-family 267 | | +--rw safi 268 | | +--rw name? 269 | +--rw interfaces 270 | | +--rw interface [name] 271 | | +--rw name 272 | | +--rw v6ur:ipv6-router-advertisements 273 | | ... 274 | +--rw routing-protocols 275 | +--rw routing-protocol [name] 276 | +--rw name 277 | +--rw description? 278 | +--rw enabled? 279 | +--rw type 280 | +--rw connected-routing-tables 281 | | ... 282 | +--rw static-routes 283 | ... 284 +--rw routing-tables 285 | +--rw routing-table [name] 286 | +--rw name 287 | +--rw address-family 288 | +--rw safi 289 | +--rw description? 290 | +--ro routes 291 | | +--ro route 292 | | ... 293 | +--rw recipient-routing-tables 294 | +--rw recipient-routing-table [name] 295 | ... 296 +--rw route-filters 297 +--rw route-filter [name] 298 +--rw name 299 +--rw description? 300 +--rw type 302 Figure 1: Data hierarchy of the core routing data model. 304 As can be seen from Figure 1, the core routing data model introduces 305 several generic components of a routing framework: routers, routing 306 tables containing lists of routes, routing protocols and route 307 filters. The following subsections describe these components in more 308 detail. 310 By combining the components in various ways, and possibly augmenting 311 them with appropriate contents defined in other modules, various 312 routing setups can be realized. 314 +--------+ 315 | direct | +---+ +--------------+ +---+ +--------------+ 316 | routes |--->| F |--->| |<---| F |<---| | 317 +--------+ +---+ | main | +---+ | additional | 318 | routing | | routing | 319 +--------+ +---+ | table | +---+ | table | 320 | static |--->| F |--->| |--->| F |--->| | 321 | routes | +---+ +--------------+ +---+ +--------------+ 322 +--------+ ^ | ^ | 323 | v | v 324 +---+ +---+ +---+ +---+ 325 | F | | F | | F | | F | 326 +---+ +---+ +---+ +---+ 327 ^ | ^ | 328 | v | v 329 +----------+ +----------+ 330 | routing | | routing | 331 | protocol | | protocol | 332 +----------+ +----------+ 334 Figure 2: Example setup of a routing system 336 The example in Figure 2 shows a typical (though certainly not the 337 only possible) organization of a more complex routing subsystem for a 338 single address family. Several of its features are worth mentioning: 340 o Along with the main routing table, which must always be present, 341 an additional routing table is configured. 343 o Each routing protocol instance, including the "static" and 344 "direct" pseudo-protocols, is connected to one routing table with 345 which it can exchange routes (in both directions, except for the 346 "static" and "direct" pseudo-protocols). 348 o Routing tables may also be connected to each other and exchange 349 routes in either direction (or both). 351 o Route exchanges along all connections may be controlled by means 352 of route filters, denoted by "F" in Figure 2. 354 4.1. Router 356 Each router instance in the core routing data model represents a 357 logical router. The exact semantics of this term is left to 358 implementations. For example, router instances may be completely 359 isolated virtual routers or, alternatively, they may internally share 360 certain information. 362 An implementation MAY support multiple types of logical routers 363 simultaneously. Instances of all router types are organized as 364 entries of the same flat "router" list. In order to discriminate 365 router instances belonging to different types, the "type" leaf is 366 defined as a child of the "router" node. 368 An implementation MAY pose restrictions on allowed router types and 369 on the number of supported instances for each type. For example, a 370 simple router implementation may support only one router instance of 371 the default type "standard-router". 373 Each network layer interface has to be assigned to one or more router 374 instances in order to be able to participate in packet forwarding, 375 routing protocols and other operations of those router instances. 376 The assignment is accomplished by creating a corresponding entry in 377 the list of router interfaces ("rt:interface"). The key of the list 378 entry is the name of a configured network layer interface, i.e., the 379 value of a node /if:interfaces/if:interface/if:name defined in the 380 "ietf-interfaces" module [YANG-IF]. 382 In YANG terms, the list of router interfaces is modeled as the "list" 383 node rather than "leaf-list" in order to allow for adding, via 384 augmentation, other configuration or state data related to the 385 corresponding router interface. 387 Implementations MAY specify additional rules for the assignment of 388 interfaces to logical routers. For example, it may be required that 389 the sets of interfaces assigned to different logical routers be 390 disjoint. 392 4.1.1. Configuration of IPv6 Router Interfaces 394 The module "ietf-ipv6-unicast-routing" augments the definition of the 395 data node "rt:interface" with definitions of the following 396 configuration variables as required by [RFC4861], sec. 6.2.1: 398 o send-advertisements, 400 o max-rtr-adv-interval, 401 o min-rtr-adv-interval, 403 o managed-flag, 405 o other-config-flag, 407 o link-mtu, 409 o reachable-time, 411 o retrans-timer, 413 o cur-hop-limit, 415 o default-lifetime, 417 o prefix-list: a list of prefixes to be advertised. 419 The following parameters are associated with each prefix in the 420 list: 422 * valid-lifetime, 424 * on-link-flag, 426 * preferred-lifetime, 428 * autonomous-flag. 430 The definitions and descriptions of the above parameters can be found 431 in the text of the module "ietf-ipv6-unicast-routing" (Section 8). 433 NOTES: 435 1. The "IsRouter" flag, which is also required by [RFC4861], is 436 implemented in the "ietf-ip" module [YANG-IP] (leaf "ip: 437 forwarding"). 439 2. The original specification [RFC4861] allows the implementations 440 to decide whether the "valid-lifetime" and "preferred-lifetime" 441 parameters remain the same in consecutive advertisements, or 442 decrement in real time. However, the latter behavior seems 443 problematic because the values might be reset again to the 444 (higher) configured values after a configuration is reloaded. 445 Moreover, no implementation is known to use the decrementing 446 behavior. The "ietf-ipv6-unicast-routing" module therefore 447 assumes the former behavior with constant values. 449 4.2. Routes 451 Routes are basic elements of information in a routing system. The 452 core routing data model defines only the following minimal set of 453 route attributes: 455 o "dest-prefix": IP prefix specifying the set of destination 456 addresses for which the route may be used. This attribute is 457 mandatory. 459 o "next-hop": IP address of an adjacent router or host to which 460 packets with destination addresses belonging to "dest-prefix" 461 should be sent. 463 o "outgoing-interface": network interface that should be used for 464 sending packets with destination addresses belonging to "dest- 465 prefix". 467 The above list of route attributes suffices for a simple static 468 routing configuration. It is expected that future modules defining 469 routing protocols will add other route attributes such as metrics or 470 preferences. 472 Routes and their attributes are used both in configuration data, for 473 example as manually configured static routes, and in state data, for 474 example as entries in routing tables. 476 4.3. Routing Tables 478 Routing tables are lists of routes complemented with administrative 479 data, namely: 481 o "source-protocol": name of the routing protocol from which the 482 route was originally obtained. 484 o "last-updated": the date and time when the route was last updated, 485 or inserted into the routing table. 487 Each routing table must contain only routes of the same address 488 family. Address family information consists of two parameters - 489 "address-family" and "safi" (Subsequent Address Family Identifier, 490 SAFI). The permitted values for these two parameters are defined by 491 IANA and represented using YANG enumeration types "ianaaf:address- 492 family" and "ianaaf:subsequent-address-family" [IANA-IF-AF]. 494 In the core routing data model, the "routing-table" node represents 495 configuration while the descendant list of routes is defined as state 496 data. The contents of route lists are controlled and manipulated by 497 routing protocol operations which may result in route additions, 498 removals and modifications. This also includes manipulations via the 499 "static" and/or "direct" pseudo-protocols, see Section 4.4.1. 501 In order to activate an address family for use within a router 502 instance, a client configures an entry of the list /routing/router/ 503 main-routing-tables/main-routing-table. This entry contains a 504 reference to a routing table which henceforth serves as the so-called 505 main routing table for the router instance and address family. 506 Section 4.4 explains the role of main routing tables. 508 Routing tables are global, which means that a configured routing 509 table may be used by any or all router instances. 511 Server implementations MAY pose restrictions regarding the number of 512 supported routing tables, and rules for configuration and use of 513 routing tables. For example: 515 o A server may support no more than one routing table per address 516 family. 518 o Router instances (of a certain type) may not be allowed to share 519 routing tables, i.e., each routing table is used by no more than 520 one router instance. 522 For servers supporting multiple routing tables per address family, 523 additional tables can be configured by creating new entries in the 524 "routing-table" list, either as a part of factory-default 525 configuration, or by a client's action. 527 The way how a routing system uses information from routing tables for 528 actual packet forwarding is outside the scope of this document. 530 Every routing table can serve as a source of routes for other routing 531 tables. To achieve this, one or more recipient routing tables may be 532 specified in the configuration of the source routing table. 533 Optionally, a route filter may be configured for any or all recipient 534 routing tables. Such a route filter then selects and/or manipulates 535 the routes that are passed between the source and recipient routing 536 table. 538 A routing table MUST NOT appear among its own recipient routing 539 tables. A recipient routing table also MUST be of the same address 540 family as its source routing table. 542 4.4. Routing Protocols 544 The core routing data model provides an open-ended framework for 545 defining multiple routing protocol instances within each router 546 instance. Each routing protocol instance MUST be assigned a type, 547 which is an identity derived from the "rt:routing-protocol" base 548 identity. The core routing data model defines two identities for the 549 direct and static pseudo-protocols (Section 4.4.1). 551 Each routing protocol instance is connected to exactly one routing 552 table for each address family that the routing protocol instance 553 supports. Routes learned from the network by a routing protocol are 554 normally installed into the connected routing table(s) and, 555 conversely, routes from the connected routing table(s) are normally 556 injected into the routing protocol. However, routing protocol 557 implementations MAY specify rules that restrict this exchange of 558 routes in either direction (or both directions). 560 A routing table is connected to a routing protocol instance by 561 creating a corresponding entry in the "connected-routing-table" list. 562 If such an entry is not configured for an address family, then the 563 main routing table MUST be used as the connected routing table for 564 this address family. 566 In addition, two independent route filters (see Section 4.5) may be 567 configured for each connected routing table to apply client-defined 568 policies controlling the exchange of routes in both directions 569 between the routing protocol instance and the connected routing 570 table: 572 o import filter controls which routes are passed from the routing 573 protocol instance to the connected routing table, 575 o export filter controls which routes the routing protocol instance 576 receives from the connected routing table. 578 Note that the terms import and export are used from the viewpoint of 579 a routing table. 581 4.4.1. Routing Pseudo-Protocols 583 The core routing data model defines two special routing protocol 584 types - "direct" and "static". Both are in fact pseudo-protocols, 585 which means that they are confined to the local device and do not 586 exchange any routing information with neighboring routers. Routes 587 from both "direct" and "static" protocol instances are passed to the 588 connected routing table (subject to route filters, if any), but an 589 exchange in the opposite direction is not allowed. 591 Every router instance MUST implement exactly one instance of the 592 "direct" pseudo-protocol type. The name of this instance MUST also 593 be "direct". It is the source of direct routes for all configured 594 address families. Direct routes are normally supplied by the 595 operating system kernel, based on the configuration of network 596 interface addresses, see Section 5.2. The "direct" pseudo-protocol 597 MUST always be connected to the main routing tables of all supported 598 address families. Unlike other routing protocol types, this 599 connection cannot be changed in the configuration. Direct routes MAY 600 be filtered before they appear in the main routing table. 602 A pseudo-protocol of the type "static" allows for specifying routes 603 manually. It MAY be configured in zero or multiple instances, 604 although a typical configuration will have exactly one instance per 605 logical router. 607 Static routes are configured within the "static-routes" container, 608 see Figure 3. 610 +--rw static-routes 611 +--rw v4ur:ipv4 612 | +--rw v4ur:route [id] 613 | +--rw v4ur:id 614 | +--rw v4ur:description? 615 | +--rw v4ur:outgoing-interface? 616 | +--rw v4ur:dest-prefix 617 | +--rw v4ur:next-hop? 618 +--rw v6ur:ipv6 619 +--rw v6ur:route [id] 620 +--rw v6ur:id 621 +--rw v6ur:description? 622 +--rw v6ur:outgoing-interface? 623 +--rw v6ur:dest-prefix 624 +--rw v6ur:next-hop? 626 Figure 3: Structure of "static-routes" subtree. 628 4.4.2. Defining New Routing Protocols 630 It is expected that future YANG modules will create data models for 631 additional routing protocol types. Such a new module has to define 632 the protocol-specific configuration and state data, and it has to fit 633 it into the core routing framework in the following way: 635 o A new identity MUST be defined for the routing protocol and its 636 base identity MUST be set to "rt:routing-protocol", or to an 637 identity derived from "rt:routing-protocol". 639 o Additional route attributes MAY be defined, preferably in one 640 place by means of defining a YANG grouping. The new attributes 641 have to be inserted as state data by augmenting the definitions of 642 the nodes 644 /rt:routing-tables/rt:routing-table/rt:route 646 and 648 /rt:active-route/rt:output/rt:route, 650 and possibly other places in the configuration, state data and RPC 651 input or output. 653 o Configuration parameters and state data for the new protocol can 654 be defined by augmenting the "routing-protocol" data node. 656 o Per-interface configuration, including activation of the routing 657 protocol on individual interfaces, can use references to entries 658 in the list of router interfaces (rt:interface). 660 By using the "when" statement, the augmented configuration parameters 661 and state data specific to the new protocol SHOULD be made 662 conditional and valid only if the value of "rt:type" is equal to the 663 new protocol's identity. It is also RECOMMENDED that the protocol- 664 specific data be encapsulated in appropriately named containers. 666 The above steps are implemented by the example YANG module for the 667 RIP routing protocol in Appendix B. 669 4.5. Route Filters 671 The core routing data model provides a skeleton for defining route 672 filters that can be used to restrict the set of routes being 673 exchanged between a routing protocol instance and a connected routing 674 table, or between a source and a recipient routing table. Route 675 filters may also manipulate routes, i.e., add, delete, or modify 676 their attributes. 678 Route filters are global, which means that a configured route filter 679 may be used by any or all router instances. 681 By itself, the route filtering framework defined in this document 682 allows for applying only two extreme routing policies which are 683 represented by the following pre-defined route filter types: 685 o "deny-all-route-filter": all routes are blocked, 686 o "allow-all-route-filter": all routes are permitted. 688 Note that the latter type is equivalent to no route filter. 690 It is expected that more comprehensive route filtering frameworks 691 will be developed separately. 693 Each route filter is identified by a name which MUST be unique within 694 the entire configuration. Its type MUST be specified by the "type" 695 identity reference - this opens the space for multiple route 696 filtering framework implementations. 698 4.6. RPC Operations 700 The "ietf-routing" module defines two RPC operations: 702 o active-route: query the routing system for the active route(s) 703 that are currently used for sending datagrams to a destination 704 host whose address is passed as an input parameter. 706 o route-count: retrieve the total number of entries in a routing 707 table. 709 5. Interactions with Other YANG Modules 711 The semantics of the core routing data model also depend on several 712 configuration parameters that are defined in other YANG modules. 714 5.1. Module "ietf-interfaces" 716 The following boolean switch is defined in the "ietf-interfaces" YANG 717 module [YANG-IF]: 719 /if:interfaces/if:interface/if:enabled 721 If this switch is set to "false" for a given network layer 722 interface, the device MUST behave exactly as if that interface was 723 not assigned to any logical router at all. 725 5.2. Module "ietf-ip" 727 The following boolean switches are defined in the "ietf-ip" YANG 728 module [YANG-IP]: 730 /if:interfaces/if:interface/ip:ipv4/ip:enabled 732 If this switch is set to "false" for a given interface, then all 733 IPv4 routing functions related to that interface MUST be disabled. 735 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 737 If this switch is set to "false" for a given interface, then the 738 forwarding of IPv4 datagrams to and from this interface MUST be 739 disabled. However, the interface may participate in other routing 740 functions, such as routing protocols. 742 /if:interfaces/if:interface/ip:ipv6/ip:enabled 744 If this switch is set to "false" for a given interface, then all 745 IPv6 routing functions related to that interface MUST be disabled. 747 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 749 If this switch is set to "false" for a given interface, then the 750 forwarding of IPv6 datagrams to and from this interface MUST be 751 disabled. However, the interface may participate in other routing 752 functions, such as routing protocols. 754 In addition, the "ietf-ip" module allows for configuring IPv4 and 755 IPv6 addresses and network prefixes or masks on network layer 756 interfaces. Configuration of these parameters on an enabled 757 interface MUST result in an immediate creation of the corresponding 758 direct route. The destination prefix of this route is set according 759 to the configured IP address and network prefix/mask, and the 760 interface is set as the outgoing interface for that route. 762 6. Routing YANG Module 764 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 765 actual RFC number and all occurrences of the revision date below with 766 the date of RFC publication (and remove this note). 768 file "ietf-routing@2013-02-23.yang" 770 module ietf-routing { 772 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 774 prefix "rt"; 776 import ietf-yang-types { 777 prefix "yang"; 778 } 780 import ietf-interfaces { 781 prefix "if"; 782 } 784 import iana-afn-safi { 785 prefix "ianaaf"; 786 } 788 organization 789 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 791 contact 792 "WG Web: 793 WG List: 795 WG Chair: David Kessens 796 798 WG Chair: Juergen Schoenwaelder 799 801 Editor: Ladislav Lhotka 802 803 "; 805 description 806 "This YANG module defines essential components that may be used 807 for configuring a routing subsystem. 809 Copyright (c) 2012 IETF Trust and the persons identified as 810 authors of the code. All rights reserved. 812 Redistribution and use in source and binary forms, with or 813 without modification, is permitted pursuant to, and subject to 814 the license terms contained in, the Simplified BSD License set 815 forth in Section 4.c of the IETF Trust's Legal Provisions 816 Relating to IETF Documents 817 (http://trustee.ietf.org/license-info). 819 This version of this YANG module is part of RFC XXXX; see the 820 RFC itself for full legal notices. 821 "; 823 revision 2013-02-23 { 824 description 825 "Initial revision."; 826 reference 827 "RFC XXXX: A YANG Data Model for Routing Management"; 828 } 830 /* Identities */ 832 identity router-type { 833 description 834 "Base identity from which router type identities are derived. 836 It is primarily intended for discriminating among different 837 types of logical routers or router virtualization. 838 "; 839 } 841 identity standard-router { 842 base router-type; 843 description 844 "This identity represents a standard router."; 845 } 847 identity routing-protocol { 848 description 849 "Base identity from which routing protocol identities are 850 derived."; 851 } 853 identity direct { 854 base routing-protocol; 855 description 856 "Routing pseudo-protocol which provides routes to directly 857 connected networks."; 859 } 861 identity static { 862 base routing-protocol; 863 description 864 "Static routing pseudo-protocol."; 865 } 867 identity route-filter { 868 description 869 "Base identity from which all route filters are derived."; 870 } 872 identity deny-all-route-filter { 873 base route-filter; 874 description 875 "Route filter that blocks all routes."; 876 } 878 identity allow-all-route-filter { 879 base route-filter; 880 description 881 "Route filter that permits all routes."; 882 } 884 /* Type Definitions */ 886 typedef router-ref { 887 type leafref { 888 path "/rt:routing/rt:router/rt:name"; 889 } 890 description 891 "This type is used for leafs that reference a router 892 instance."; 893 } 895 typedef routing-table-ref { 896 type leafref { 897 path "/rt:routing/rt:routing-tables/rt:routing-table/rt:name"; 898 } 899 description 900 "This type is used for leafs that reference a routing table."; 901 } 903 typedef route-filter-ref { 904 type leafref { 905 path "/rt:routing/rt:route-filters/rt:route-filter/rt:name"; 906 } 907 description 908 "This type is used for leafs that reference a route filter."; 909 } 911 /* Groupings */ 913 grouping afn-safi { 914 description 915 "This grouping provides two parameters specifying address 916 family and subsequent address family."; 917 leaf address-family { 918 type ianaaf:address-family; 919 mandatory "true"; 920 description 921 "Address family."; 922 } 923 leaf safi { 924 type ianaaf:subsequent-address-family; 925 mandatory "true"; 926 description 927 "Subsequent address family."; 928 } 929 } 931 grouping route-content { 932 description 933 "Generic parameters of routes."; 934 leaf outgoing-interface { 935 type if:interface-ref; 936 description 937 "Outgoing interface."; 938 } 939 } 941 /* RPC Methods */ 943 rpc active-route { 944 description 945 "Return the active route (or multiple routes, in the case of 946 multi-path routing) to a destination address. 948 Parameters 950 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 description 972 "Network layer destination address. 974 Address family specific modules MUST augment this 975 container with a leaf named 'address'. 976 "; 977 uses afn-safi; 978 } 979 } 980 output { 981 list route { 982 description 983 "List of active routes. 985 Route contents specific for each address family is 986 expected be defined through augmenting. 987 "; 988 uses afn-safi; 989 uses route-content; 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 yang:dotted-quad; 1068 description 1069 "Global router ID - 32-bit number in the form of a dotted 1070 quad. 1072 An implementation MAY select a value if this parameter is 1073 not configured. 1075 Routing protocols MAY override this global parameter 1076 inside their configuration. 1077 "; 1078 } 1079 leaf description { 1080 type string; 1081 description 1082 "Textual description of the router."; 1083 } 1084 container main-routing-tables { 1085 description 1086 "Main routing tables used by the router instance."; 1087 list main-routing-table { 1088 must "address-family=/routing/routing-tables/" 1089 + "routing-table[name=current()/name]/" 1090 + "address-family and safi=/routing/routing-tables/" 1091 + "routing-table[name=current()/name]/safi" { 1092 error-message "Address family mismatch."; 1093 description 1094 "The entry's address family MUST match that of the 1095 referenced routing table."; 1096 } 1097 key "address-family safi"; 1098 description 1099 "Each list entry specifies the main routing table for one 1100 address family. 1102 The main routing table is operationally connected to all 1103 routing protocols for which a connected routing table 1104 has not been explicitly configured. 1106 The 'direct' pseudo-protocol is always connected to the 1107 main routing table. 1109 Address families that don't have their entry in this 1110 list MUST NOT be used in the rest of the router instance 1111 configuration. 1112 "; 1113 uses afn-safi; 1114 leaf name { 1115 type routing-table-ref; 1116 description 1117 "Name of an existing routing table to be used as the 1118 main routing table for the given router instance and 1119 address family."; 1120 } 1121 } 1122 } 1123 container interfaces { 1124 description 1125 "Router interface parameters."; 1126 list interface { 1127 key "name"; 1128 description 1129 "List of network layer interfaces assigned to the router 1130 instance."; 1131 leaf name { 1132 type if:interface-ref; 1133 description 1134 "A reference to the name of a configured network layer 1135 interface."; 1136 } 1137 } 1138 } 1139 container routing-protocols { 1140 description 1141 "Container for the list of configured routing protocol 1142 instances."; 1143 list routing-protocol { 1144 key "name"; 1145 description 1146 "An instance of a routing protocol."; 1148 leaf name { 1149 type string; 1150 description 1151 "An arbitrary name of the routing protocol instance."; 1152 } 1153 leaf description { 1154 type string; 1155 description 1156 "Textual description of the routing protocol 1157 instance."; 1158 } 1159 leaf enabled { 1160 type boolean; 1161 default "true"; 1162 description 1163 "Enable/disable the routing protocol instance. 1165 If this parameter is false, the parent routing 1166 protocol instance is disabled, despite any other 1167 configuration that might be present. 1168 "; 1169 } 1170 leaf type { 1171 type identityref { 1172 base routing-protocol; 1173 } 1174 mandatory "true"; 1175 description 1176 "Type of the routing protocol - an identity derived 1177 from the 'routing-protocol' base identity."; 1178 } 1179 container connected-routing-tables { 1180 description 1181 "Container for connected routing tables. 1182 "; 1183 list connected-routing-table { 1184 must "not(/routing/routing-tables/" 1185 + "routing-table[name=current()/" 1186 + "preceding-sibling::connected-routing-table/" 1187 + "name and address-family=/routing/routing-tables/" 1188 + "routing-table[name=current()/name]/" 1189 + "address-family and safi=/routing/routing-tables/" 1190 + "routing-table[name=current()/name]/safi])" { 1191 error-message "Duplicate address family for " 1192 + "connected routing tables."; 1193 description 1194 "For each AFN/SAFI pair there MUST NOT be more than 1195 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 type routing-table-ref; 1211 must "../../../type != 'rt:direct' or " 1212 + "../../../../../main-routing-tables/ " 1213 + "main-routing-table/name=." { 1214 error-message "The 'direct' protocol can be " 1215 + "connected only to a main routing " 1216 + "table."; 1217 description 1218 "For the 'direct' pseudo-protocol, the connected 1219 routing table must always be a main routing 1220 table."; 1221 } 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" { 1338 error-message "Address family mismatch."; 1339 description 1340 "Address family of the recipient routing table MUST 1341 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 and 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@2013-02-23.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 2013-02-23 { 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 "rt:address-family='ipv4' and rt: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 "rt:address-family='ipv4' and rt: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@2013-02-23.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 2013-02-23 { 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 "rt:address-family='ipv6' and rt: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 "rt:address-family='ipv6' and rt: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[if:name=current()/rt:name]/" 1690 + "ip:ipv6/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 units "seconds"; 1730 must ". <= 0.75 * ../max-rtr-adv-interval" { 1731 description 1732 "The value MUST NOT be greater than 75 % of 1733 'max-rtr-adv-interval'."; 1734 } 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 If this parameter is not configured, a value of 3 * 1844 max-rtr-adv-interval SHOULD be used. 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. 1860 Prefixes that do not have their entries in the child 1861 'prefix' list are advertised with the default values of 1862 all parameters. 1864 The link-local prefix SHOULD NOT be included in the list 1865 of advertised prefixes. 1866 "; 1867 reference 1868 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1869 AdvPrefixList."; 1870 list prefix { 1871 key "prefix-spec"; 1872 description 1873 "Advertised prefix entry."; 1874 leaf prefix-spec { 1875 type inet:ipv6-prefix; 1876 description 1877 "IPv6 address prefix."; 1878 } 1879 choice control-adv-prefixes { 1880 default "advertise"; 1881 description 1882 "The prefix either may be explicitly removed from the 1883 set of advertised prefixes, or parameters with which 1884 it is advertised may be specified (default case)."; 1885 leaf no-advertise { 1886 type empty; 1887 description 1888 "The prefix will not be advertised. 1890 This can be used for removing the prefix from the 1891 default set of advertised prefixes. 1892 "; 1893 } 1894 case advertise { 1895 leaf valid-lifetime { 1896 type uint32; 1897 units "seconds"; 1898 default "2592000"; 1899 description 1900 "The value to be placed in the Valid Lifetime in 1901 the Prefix Information option, in seconds. The 1902 designated value of all 1's (0xffffffff) 1903 represents infinity. 1904 "; 1905 reference 1906 "RFC 4861: Neighbor Discovery for IP version 6 1907 (IPv6) - AdvValidLifetime."; 1909 } 1910 leaf on-link-flag { 1911 type boolean; 1912 default "true"; 1913 description 1914 "The value to be placed in the on-link flag 1915 ('L-bit') field in the Prefix Information 1916 option."; 1917 reference 1918 "RFC 4861: Neighbor Discovery for IP version 6 1919 (IPv6) - AdvOnLinkFlag."; 1920 } 1921 leaf preferred-lifetime { 1922 type uint32; 1923 units "seconds"; 1924 must ". <= ../valid-lifetime" { 1925 description 1926 "This value MUST NOT be greater than 1927 valid-lifetime."; 1928 } 1929 default "604800"; 1930 description 1931 "The value to be placed in the Preferred Lifetime 1932 in the Prefix Information option, in seconds. The 1933 designated value of all 1's (0xffffffff) 1934 represents infinity. 1935 "; 1936 reference 1937 "RFC 4861: Neighbor Discovery for IP version 6 1938 (IPv6) - AdvPreferredLifetime."; 1939 } 1940 leaf autonomous-flag { 1941 type boolean; 1942 default "true"; 1943 description 1944 "The value to be placed in the Autonomous Flag 1945 field in the Prefix Information option."; 1946 reference 1947 "RFC 4861: Neighbor Discovery for IP version 6 1948 (IPv6) - AdvAutonomousFlag."; 1949 } 1950 } 1951 } 1952 } 1953 } 1954 } 1955 } 1956 augment "/rt:routing/rt:router/rt:routing-protocols/" 1957 + "rt:routing-protocol/rt:static-routes" { 1958 description 1959 "This augment defines the configuration of the 'static' 1960 pseudo-protocol with data specific for IPv6 unicast."; 1961 container ipv6 { 1962 description 1963 "Configuration of a 'static' pseudo-protocol instance 1964 consists of a list of routes."; 1965 list route { 1966 key "id"; 1967 ordered-by "user"; 1968 description 1969 "A user-ordered list of static routes."; 1970 leaf id { 1971 type uint32 { 1972 range "1..max"; 1973 } 1974 description 1975 "Numeric identifier of the route. 1977 It is not required that the routes be sorted by their 1978 'id'. 1979 "; 1980 } 1981 leaf description { 1982 type string; 1983 description 1984 "Textual description of the route."; 1985 } 1986 uses rt:route-content; 1987 uses route-content { 1988 refine "dest-prefix" { 1989 mandatory "true"; 1990 } 1991 } 1992 } 1993 } 1994 } 1996 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 1997 + "rt:route" { 1998 when "../../rt:address-family = 'ipv6' and ../../rt:safi = " 1999 + "'nlri-unicast'" { 2000 description 2001 "This augment is valid only for IPv6 unicast."; 2002 } 2003 description 2004 "This augment defines the content of IPv6 unicast routes."; 2005 uses route-content; 2006 } 2007 } 2009 2011 9. IANA Considerations 2013 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2014 actual RFC number (and remove this note). 2016 This document registers the following namespace URIs in the IETF XML 2017 registry [RFC3688]: 2019 ---------------------------------------------------------- 2020 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2022 Registrant Contact: The IESG. 2024 XML: N/A, the requested URI is an XML namespace. 2025 ---------------------------------------------------------- 2027 ---------------------------------------------------------- 2028 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2030 Registrant Contact: The IESG. 2032 XML: N/A, the requested URI is an XML namespace. 2033 ---------------------------------------------------------- 2035 ---------------------------------------------------------- 2036 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2038 Registrant Contact: The IESG. 2040 XML: N/A, the requested URI is an XML namespace. 2041 ---------------------------------------------------------- 2043 This document registers the following YANG modules in the YANG Module 2044 Names registry [RFC6020]: 2046 ------------------------------------------------------------------- 2047 name: ietf-routing 2048 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2049 prefix: rt 2050 reference: RFC XXXX 2051 ------------------------------------------------------------------- 2053 ------------------------------------------------------------------- 2054 name: ietf-ipv4-unicast-routing 2055 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2056 prefix: v4ur 2057 reference: RFC XXXX 2058 ------------------------------------------------------------------- 2060 ------------------------------------------------------------------- 2061 name: ietf-ipv6-unicast-routing 2062 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2063 prefix: v6ur 2064 reference: RFC XXXX 2065 ------------------------------------------------------------------- 2067 10. Security Considerations 2069 Configuration and state data conforming to the core routing data 2070 model (defined in this document) are designed to be accessed via the 2071 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2072 transport layer and the mandatory-to-implement secure transport is 2073 SSH [RFC6242]. 2075 A number of data nodes defined in the YANG modules belonging to the 2076 core routing data model are writable/creatable/deletable (i.e., 2077 "config true" in YANG terms, which is the default). These data nodes 2078 may be considered sensitive or vulnerable in some network 2079 environments. Write operations to these data nodes, such as "edit- 2080 config", can have negative effects on the network if the protocol 2081 operations are not properly protected. 2083 The vulnerable "config true" subtrees and data nodes are the 2084 following: 2086 /routing/router/interfaces/interface This list assigns a network 2087 layer interface to a router instance and may also specify 2088 interface parameters related to routing. 2090 /routing/router/routing-protocols/routing-protocol This list 2091 specifies the routing protocols configured on a device. 2093 /routing/route-filters/route-filter This list specifies the 2094 configured route filters which represent administrative policies 2095 for redistributing and modifying routing information. 2097 /routing/routing-tables/routing-table This list specifies the 2098 configured routing tables used by the device. 2100 Unauthorized access to any of these lists can adversely affect the 2101 routing subsystem of both the local device and the network. This may 2102 lead to network malfunctions, delivery of packets to inappropriate 2103 destinations and other problems. 2105 11. Acknowledgments 2107 The author wishes to thank Martin Bjorklund, Joel Halpern, 2108 Wes Hardaker, Andrew McGregor, Thomas Morin, Tom Petch, 2109 Bruno Rijsman, Juergen Schoenwaelder, Phil Shafer, Dave Thaler and 2110 Yi Yang for their helpful comments and suggestions. 2112 12. References 2114 12.1. Normative References 2116 [IANA-IF-AF] 2117 Bjorklund, M., "IANA Interface Type and Address Family 2118 YANG Modules", draft-ietf-netmod-iana-if-type-04 (work in 2119 progress), June 2012. 2121 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2122 Requirement Levels", BCP 14, RFC 2119, March 1997. 2124 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2125 January 2004. 2127 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2128 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2129 September 2007. 2131 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2132 Network Configuration Protocol (NETCONF)", RFC 6020, 2133 September 2010. 2135 [RFC6021bis] 2136 Schoenwaelder, J., Ed., "Common YANG Data Types", 2137 draft-ietf-netmod-rfc6021-bis-00 (work in progress), 2138 February 2013. 2140 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2141 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2142 June 2011. 2144 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2145 Configuration", draft-ietf-netmod-interfaces-cfg-09 (work 2146 in progress), February 2013. 2148 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 2149 draft-ietf-netmod-ip-cfg-09 (work in progress), 2150 February 2013. 2152 12.2. Informative References 2154 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2155 Data Model Documents", RFC 6087, January 2011. 2157 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2158 Shell (SSH)", RFC 6242, June 2011. 2160 Appendix A. The Complete Data Tree 2162 This appendix presents the complete data tree of the core routing 2163 data model. See Section 2.2 for an explanation of symbols. Data 2164 type of every leaf node is shown near the right end of the 2165 corresponding line. 2167 +--rw routing 2168 +--rw router [name] 2169 | +--rw name string 2170 | +--rw type? identityref 2171 | +--rw enabled? boolean 2172 | +--rw router-id? yang:dotted-quad 2173 | +--rw description? string 2174 | +--rw main-routing-tables 2175 | | +--rw main-routing-table [address-family safi] 2176 | | +--rw address-family ianaaf:address-family 2177 | | +--rw safi ianaaf:subsequent-address-family 2178 | | +--rw name? routing-table-ref 2179 | +--rw interfaces 2180 | | +--rw interface [name] 2181 | | +--rw name if:interface-ref 2182 | | +--rw v6ur:ipv6-router-advertisements 2183 | | +--rw v6ur:send-advertisements? boolean 2184 | | +--rw v6ur:max-rtr-adv-interval? uint16 2185 | | +--rw v6ur:min-rtr-adv-interval? uint16 2186 | | +--rw v6ur:managed-flag? boolean 2187 | | +--rw v6ur:other-config-flag? boolean 2188 | | +--rw v6ur:link-mtu? uint32 2189 | | +--rw v6ur:reachable-time? uint32 2190 | | +--rw v6ur:retrans-timer? uint32 2191 | | +--rw v6ur:cur-hop-limit? uint8 2192 | | +--rw v6ur:default-lifetime? uint16 2193 | | +--rw v6ur:prefix-list 2194 | | +--rw v6ur:prefix [prefix-spec] 2195 | | +--rw v6ur:prefix-spec inet:ipv6-prefix 2196 | | +--rw (control-adv-prefixes)? 2197 | | +--:(no-advertise) 2198 | | | +--rw v6ur:no-advertise? empty 2199 | | +--:(advertise) 2200 | | +--rw v6ur:valid-lifetime? uint32 2201 | | +--rw v6ur:on-link-flag? boolean 2202 | | +--rw v6ur:preferred-lifetime? uint32 2203 | | +--rw v6ur:autonomous-flag? boolean 2204 | +--rw routing-protocols 2205 | +--rw routing-protocol [name] 2206 | +--rw name string 2207 | +--rw description? string 2208 | +--rw enabled? boolean 2209 | +--rw type identityref 2210 | +--rw connected-routing-tables 2211 | | +--rw connected-routing-table [name] 2212 | | +--rw name routing-table-ref 2213 | | +--rw import-filter? route-filter-ref 2214 | | +--rw export-filter? route-filter-ref 2215 | +--rw static-routes 2216 | +--rw v4ur:ipv4 2217 | | +--rw v4ur:route [id] 2218 | | +--rw v4ur:id uint32 2219 | | +--rw v4ur:description? string 2220 | | +--rw v4ur:outgoing-interface? if:interface-ref 2221 | | +--rw v4ur:dest-prefix inet:ipv4-prefix 2222 | | +--rw v4ur:next-hop? inet:ipv4-address 2223 | +--rw v6ur:ipv6 2224 | +--rw v6ur:route [id] 2225 | +--rw v6ur:id uint32 2226 | +--rw v6ur:description? string 2227 | +--rw v6ur:outgoing-interface? if:interface-ref 2228 | +--rw v6ur:dest-prefix inet:ipv6-prefix 2229 | +--rw v6ur:next-hop? inet:ipv6-address 2230 +--rw routing-tables 2231 | +--rw routing-table [name] 2232 | +--rw name string 2233 | +--rw address-family ianaaf:address-family 2234 | +--rw safi ianaaf:subsequent-address-family 2235 | +--rw description? string 2236 | +--ro routes 2237 | | +--ro route 2238 | | +--ro outgoing-interface? if:interface-ref 2239 | | +--ro source-protocol string 2240 | | +--ro last-updated? yang:date-and-time 2241 | | +--ro v4ur:dest-prefix? inet:ipv4-prefix 2242 | | +--ro v4ur:next-hop? inet:ipv4-address 2243 | | +--ro v6ur:dest-prefix? inet:ipv6-prefix 2244 | | +--ro v6ur:next-hop? inet:ipv6-address 2245 | +--rw recipient-routing-tables 2246 | +--rw recipient-routing-table [name] 2247 | +--rw name routing-table-ref 2248 | +--rw filter? route-filter-ref 2249 +--rw route-filters 2250 +--rw route-filter [name] 2251 +--rw name string 2252 +--rw description? string 2253 +--rw type identityref 2255 Appendix B. Example: Adding a New Routing Protocol 2257 This appendix demonstrates how the core routing data model can be 2258 extended to support a new routing protocol. The YANG module 2259 "example-rip" shown below is intended only as an illustration rather 2260 than a real definition of a data model for the RIP routing protocol. 2261 For the sake of brevity, we do not follow all the guidelines 2262 specified in [RFC6087]. See also Section 4.4.2. 2264 module example-rip { 2266 namespace "http://example.com/rip"; 2268 prefix "rip"; 2270 import ietf-routing { 2271 prefix "rt"; 2272 } 2274 identity rip { 2275 base rt:routing-protocol; 2276 description 2277 "Identity for the RIP routing protocol."; 2278 } 2280 typedef rip-metric { 2281 type uint8 { 2282 range "0..16"; 2283 } 2284 } 2286 grouping route-content { 2287 description 2288 "This grouping defines RIP-specific route attributes."; 2289 leaf metric { 2290 type rip-metric; 2291 } 2292 leaf tag { 2293 type uint16; 2294 default "0"; 2295 description 2296 "This leaf may be used to carry additional info, e.g. AS 2297 number."; 2298 } 2299 } 2301 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:routes/" 2302 + "rt:route" { 2304 description 2305 "RIP-specific route attributes."; 2306 uses route-content; 2307 } 2309 augment "/rt:active-route/rt:output/rt:route" { 2310 description 2311 "RIP-specific route attributes in the output of 'active-route' 2312 RPC."; 2313 uses route-content; 2314 } 2316 augment "/rt:routing/rt:router/rt:routing-protocols/" 2317 + "rt:routing-protocol" { 2318 when "rt:type = 'rip:rip'" { 2319 description 2320 'This augment is only valid for a routing protocol instance 2321 of type "rip".'; 2322 } 2323 container rip { 2324 description 2325 "RIP instance configuration."; 2326 container interfaces { 2327 description 2328 "Per-interface RIP configuration."; 2329 list interface { 2330 key "name"; 2331 description 2332 "RIP is enabled on interfaces that have an entry in this 2333 list, unless 'enabled' is set to 'false' for that 2334 entry."; 2335 leaf name { 2336 type leafref { 2337 path "../../../../../../rt:interfaces/rt:interface/" 2338 + "rt:name"; 2339 } 2340 } 2341 leaf enabled { 2342 type boolean; 2343 default "true"; 2344 } 2345 leaf metric { 2346 type rip-metric; 2347 default "1"; 2348 } 2349 } 2350 } 2351 leaf update-interval { 2352 type uint8 { 2353 range "10..60"; 2354 } 2355 units "seconds"; 2356 default "30"; 2357 description 2358 "Time interval between periodic updates."; 2359 } 2360 } 2361 } 2362 } 2364 Appendix C. Example: NETCONF Reply 2366 This section contains a sample reply to the NETCONF message, 2367 which could be sent by a server supporting (i.e., advertising them in 2368 the NETCONF message) the following YANG modules: 2370 o ietf-interfaces [YANG-IF], 2372 o ietf-ip [YANG-IP], 2374 o ietf-routing (Section 6), 2376 o ietf-ipv4-unicast-routing (Section 7), 2378 o ietf-ipv6-unicast-routing (Section 8). 2380 We assume a simple network setup as shown in Figure 4: router "A" 2381 uses static default routes with the "ISP" router as the next hop. 2382 IPv6 router advertisements are configured only on the "eth1" 2383 interface and disabled on the upstream "eth0" interface. 2385 +-----------------+ 2386 | | 2387 | Router ISP | 2388 | | 2389 +--------+--------+ 2390 |2001:db8:0:1::2 2391 |192.0.2.2 2392 | 2393 | 2394 |2001:db8:0:1::1 2395 eth0|192.0.2.1 2396 +--------+--------+ 2397 | | 2398 | Router A | 2399 | | 2400 +--------+--------+ 2401 eth1|198.51.100.1 2402 |2001:db8:0:2::1 2403 | 2405 Figure 4: Example network configuration 2407 A reply to the NETCONF message sent by router "A" would then be 2408 as follows: 2410 2411 2419 2420 2421 2422 eth0 2423 ethernetCsmacd 2424 eth0 2425 2426 2427 192.0.2.1 2428 24 2429 2430 true 2431 2432 2433 2434 2001:0db8:0:1::1 2435 64 2436 2437 true 2438 2439 false 2440 2441 2442 2443 2444 eth1 2445 ethernetCsmacd 2446 eth1 2447 2448 2449 198.51.100.1 2450 24 2451 2452 true 2453 2454 2455 2456 2001:0db8:0:2::1 2457 64 2458 2459 true 2460 2461 false 2462 2463 2464 2465 2466 2467 2468 rtr0 2469 192.0.2.1 2470 Router A 2471 2472 2473 ipv4 2474 nlri-unicast 2475 ipv4-unicast 2476 2477 2478 ipv6 2479 nlri-unicast 2480 ipv6-unicast 2481 2482 2483 2484 2485 eth0 2486 2487 2488 eth1 2489 2490 true 2491 2492 2493 2001:db8:0:2::/64 2494 2495 2496 2497 2498 2499 2500 2501 st0 2502 2503 Static routing is used for the internal network. 2504 2505 rt:static 2506 2507 2508 2509 1 2510 0.0.0.0/0 2511 192.0.2.2 2512 2513 2514 2515 2516 1 2517 ::/0 2518 2001:db8:0:1::2 2519 2520 2521 2522 2523 2524 2525 2526 2527 ipv4-unicast 2528 ipv4 2529 nlri-unicast 2530 2531 2532 192.0.2.1/24 2533 eth0 2534 direct 2535 2012-10-02T17:11:27+01:00 2536 2537 2538 198.51.100.0/24 2539 eth1 2540 direct 2541 2012-10-02T17:11:27+01:00 2542 2543 2544 0.0.0.0/0 2545 st0 2546 192.0.2.2 2547 2012-10-02T18:02:45+01:00 2548 2549 2550 2551 2552 ipv6-unicast 2553 ipv6 2554 nlri-unicast 2555 2556 2557 2001:db8:0:1::/64 2558 eth0 2559 direct 2560 2012-10-02T17:11:27+01:00 2561 2562 2563 2001:db8:0:2::/64 2564 eth1 2565 direct 2566 2012-10-02T17:11:27+01:00 2567 2568 2569 ::/0 2570 2001:db8:0:1::2 2571 st0 2572 2012-10-02T18:02:45+01:00 2573 2574 2575 2576 2577 2578 2579 2581 Appendix D. Change Log 2583 RFC Editor: remove this section upon publication as an RFC. 2585 D.1. Changes Between Versions -08 and -09 2587 o Fixed "must" expresion for "connected-routing-table". 2589 o Simplified "must" expression for "main-routing-table". 2591 o Moved per-interface configuration of a new routing protocol under 2592 'routing-protocol'. This also affects the 'example-rip' module. 2594 D.2. Changes Between Versions -07 and -08 2596 o Changed reference from RFC6021 to RFC6021bis. 2598 D.3. Changes Between Versions -06 and -07 2600 o The contents of in Appendix C was updated: "eth[01]" 2601 is used as the value of "location", and "forwarding" is on for 2602 both interfaces and both IPv4 and IPv6. 2604 o The "must" expression for "main-routing-table" was modified to 2605 avoid redundant error messages reporting address family mismatch 2606 when "name" points to a non-existent routing table. 2608 o The default behavior for IPv6 RA prefix advertisements was 2609 clarified. 2611 o Changed type of "rt:router-id" to "ip:dotted-quad". 2613 o Type of "rt:router-id" changed to "yang:dotted-quad". 2615 o Fixed missing prefixes in XPath expressions. 2617 D.4. Changes Between Versions -05 and -06 2619 o Document title changed: "Configuration" was replaced by 2620 "Management". 2622 o New typedefs "routing-table-ref" and "route-filter-ref". 2624 o Double slashes "//" were removed from XPath expressions and 2625 replaced with the single "/". 2627 o Removed uniqueness requirement for "router-id". 2629 o Complete data tree is now in Appendix A. 2631 o Changed type of "source-protocol" from "leafref" to "string". 2633 o Clarified the relationship between routing protocol instances and 2634 connected routing tables. 2636 o Added a must constraint saying that a routing table connected to 2637 the direct pseudo-protocol must not be a main routing table. 2639 D.5. Changes Between Versions -04 and -05 2641 o Routing tables are now global, i.e., "routing-tables" is a child 2642 of "routing" rather than "router". 2644 o "must" statement for "static-routes" changed to "when". 2646 o Added "main-routing-tables" containing references to main routing 2647 tables for each address family. 2649 o Removed the defaults for "address-family" and "safi" and made them 2650 mandatory. 2652 o Removed the default for route-filter/type and made this leaf 2653 mandatory. 2655 o If there is no active route for a given destination, the "active- 2656 route" RPC returns no output. 2658 o Added "enabled" switch under "routing-protocol". 2660 o Added "router-type" identity and "type" leaf under "router". 2662 o Route attribute "age" changed to "last-updated", its type is 2663 "yang:date-and-time". 2665 o The "direct" pseudo-protocol is always connected to main routing 2666 tables. 2668 o Entries in the list of connected routing tables renamed from 2669 "routing-table" to "connected-routing-table". 2671 o Added "must" constraint saying that a routing table must not be 2672 its own recipient. 2674 D.6. Changes Between Versions -03 and -04 2676 o Changed "error-tag" for both RPC methods from "missing element" to 2677 "data-missing". 2679 o Removed the decrementing behavior for advertised IPv6 prefix 2680 parameters "valid-lifetime" and "preferred-lifetime". 2682 o Changed the key of the static route lists from "seqno" to "id" 2683 because the routes needn't be sorted. 2685 o Added 'must' constraint saying that "preferred-lifetime" must not 2686 be greater than "valid-lifetime". 2688 D.7. Changes Between Versions -02 and -03 2690 o Module "iana-afn-safi" moved to I-D "iana-if-type". 2692 o Removed forwarding table. 2694 o RPC "get-route" changed to "active-route". Its output is a list 2695 of routes (for multi-path routing). 2697 o New RPC "route-count". 2699 o For both RPCs, specification of negative responses was added. 2701 o Relaxed separation of router instances. 2703 o Assignment of interfaces to router instances needn't be disjoint. 2705 o Route filters are now global. 2707 o Added "allow-all-route-filter" for symmetry. 2709 o Added Section 5 about interactions with "ietf-interfaces" and 2710 "ietf-ip". 2712 o Added "router-id" leaf. 2714 o Specified the names for IPv4/IPv6 unicast main routing tables. 2716 o Route parameter "last-modified" changed to "age". 2718 o Added container "recipient-routing-tables". 2720 D.8. Changes Between Versions -01 and -02 2722 o Added module "ietf-ipv6-unicast-routing". 2724 o The example in Appendix C now uses IP addresses from blocks 2725 reserved for documentation. 2727 o Direct routes appear by default in the forwarding table. 2729 o Network layer interfaces must be assigned to a router instance. 2730 Additional interface configuration may be present. 2732 o The "when" statement is only used with "augment", "must" is used 2733 elsewhere. 2735 o Additional "must" statements were added. 2737 o The "route-content" grouping for IPv4 and IPv6 unicast now 2738 includes the material from the "ietf-routing" version via "uses 2739 rt:route-content". 2741 o Explanation of symbols in the tree representation of data model 2742 hierarchy. 2744 D.9. Changes Between Versions -00 and -01 2746 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2748 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2749 safi" module. 2751 o Names of some data nodes were changed, in particular "routing- 2752 process" is now "router". 2754 o The restriction of a single AFN/SAFI per router was lifted. 2756 o RPC operation "delete-route" was removed. 2758 o Illegal XPath references from "get-route" to the datastore were 2759 fixed. 2761 o Section "Security Considerations" was written. 2763 Author's Address 2765 Ladislav Lhotka 2766 CZ.NIC 2768 Email: lhotka@nic.cz