idnits 2.17.1 draft-ietf-netmod-routing-cfg-18.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 2402 has weird spacing: '...ference rou...' == Line 2406 has weird spacing: '...-family ide...' -- The document date (April 17, 2015) is 3291 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) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track A. Lindem 5 Expires: October 19, 2015 Cisco Systems 6 April 17, 2015 8 A YANG Data Model for Routing Management 9 draft-ietf-netmod-routing-cfg-18 11 Abstract 13 This document contains a specification of three YANG modules. 14 Together they form the core routing data model which serves as a 15 framework for configuring and managing a routing subsystem. It is 16 expected that these modules will be augmented by additional YANG 17 modules defining data models for routing protocols, route filters and 18 other functions. The core routing data model provides common 19 building blocks for such extensions - routing instances, routes, 20 routing information bases (RIB), and routing protocols. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 19, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 58 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 59 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 61 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. The Design of the Core Routing Data Model . . . . . . . . . . 6 63 4.1. System-Controlled and User-Controlled List Entries . . . 8 64 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Routing Instance . . . . . . . . . . . . . . . . . . . . 9 66 5.1.1. Parameters of IPv6 Routing Instance Interfaces . . . 9 67 5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.3. Routing Information Base (RIB) . . . . . . . . . . . . . 11 69 5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 11 70 5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 12 71 5.4.2. Defining New Routing Protocols . . . . . . . . . . . 12 72 5.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 13 73 6. Interactions with Other YANG Modules . . . . . . . . . . . . 13 74 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 13 75 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 76 7. Routing Management YANG Module . . . . . . . . . . . . . . . 14 77 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 29 78 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 34 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 81 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 49 84 13.2. Informative References . . . . . . . . . . . . . . . . . 49 85 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 50 86 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 50 87 A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 52 88 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 52 89 Appendix C. Example: Adding a New Routing Protocol . . . . . . . 53 90 Appendix D. Example: NETCONF Reply . . . . . . . . . . . . 55 91 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 62 92 E.1. Changes Between Versions -17 and -18 . . . . . . . . . . 62 93 E.2. Changes Between Versions -16 and -17 . . . . . . . . . . 63 94 E.3. Changes Between Versions -15 and -16 . . . . . . . . . . 63 95 E.4. Changes Between Versions -14 and -15 . . . . . . . . . . 64 96 E.5. Changes Between Versions -13 and -14 . . . . . . . . . . 64 97 E.6. Changes Between Versions -12 and -13 . . . . . . . . . . 64 98 E.7. Changes Between Versions -11 and -12 . . . . . . . . . . 65 99 E.8. Changes Between Versions -10 and -11 . . . . . . . . . . 65 100 E.9. Changes Between Versions -09 and -10 . . . . . . . . . . 65 101 E.10. Changes Between Versions -08 and -09 . . . . . . . . . . 66 102 E.11. Changes Between Versions -07 and -08 . . . . . . . . . . 66 103 E.12. Changes Between Versions -06 and -07 . . . . . . . . . . 66 104 E.13. Changes Between Versions -05 and -06 . . . . . . . . . . 66 105 E.14. Changes Between Versions -04 and -05 . . . . . . . . . . 67 106 E.15. Changes Between Versions -03 and -04 . . . . . . . . . . 68 107 E.16. Changes Between Versions -02 and -03 . . . . . . . . . . 68 108 E.17. Changes Between Versions -01 and -02 . . . . . . . . . . 69 109 E.18. Changes Between Versions -00 and -01 . . . . . . . . . . 69 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 112 1. Introduction 114 This document contains a specification of the following YANG modules: 116 o Module "ietf-routing" provides generic components of a routing 117 data model. 119 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 120 module with additional data specific to IPv4 unicast. 122 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 123 module with additional data specific to IPv6 unicast, including 124 the router configuration variables required by [RFC4861]. 126 These modules together define the so-called core routing data model, 127 which is intended as a basis for future data model development 128 covering more sophisticated routing systems. While these three 129 modules can be directly used for simple IP devices with static 130 routing (see Appendix B), their main purpose is to provide essential 131 building blocks for more complicated data models involving multiple 132 routing protocols, multicast routing, additional address families, 133 and advanced functions such as route filtering or policy routing. To 134 this end, it is expected that the core routing data model will be 135 augmented by numerous modules developed by other IETF working groups. 137 2. Terminology and Notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 The following terms are defined in [RFC6241]: 145 o client, 147 o message, 149 o protocol operation, 151 o server. 153 The following terms are defined in [RFC6020]: 155 o augment, 157 o configuration data, 159 o data model, 161 o data node, 163 o feature, 165 o mandatory node, 167 o module, 169 o schema tree, 171 o state data, 173 o RPC operation. 175 2.1. Glossary of New Terms 177 core routing data model: YANG data model comprising "ietf-routing", 178 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 179 modules. 181 direct route: a route to a directly connected network. 183 routing information base (RIB): An object containing a list of 184 routes together with other information. See Section 5.3 for 185 details. 187 system-controlled entry: An entry of a list in state data ("config 188 false") that is created by the system independently of what has 189 been explicitly configured. See Section 4.1 for details. 191 user-controlled entry: An entry of a list in state data ("config 192 false") that is created and deleted as a direct consequence of 193 certain configuration changes. See Section 4.1 for details. 195 2.2. Tree Diagrams 197 A simplified graphical representation of the complete data tree is 198 presented in Appendix A, and similar diagrams of its various subtrees 199 appear in the main text. 201 The meaning of the symbols in these diagrams is as follows: 203 o Brackets "[" and "]" enclose list keys. 205 o Curly braces "{" and "}" contain names of optional features that 206 make the corresponding node conditional. 208 o Abbreviations before data node names: "rw" means configuration 209 (read-write), "ro" state data (read-only), "-x" RPC operations, 210 and "-n" notifications. 212 o Symbols after data node names: "?" means an optional node, "!" a 213 container with presence, and "*" denotes a "list" or "leaf-list". 215 o Parentheses enclose choice and case nodes, and case nodes are also 216 marked with a colon (":"). 218 o Ellipsis ("...") stands for contents of subtrees that are not 219 shown. 221 2.3. Prefixes in Data Node Names 223 In this document, names of data nodes, RPC operations and other data 224 model objects are often used without a prefix, as long as it is clear 225 from the context in which YANG module each name is defined. 226 Otherwise, names are prefixed using the standard prefix associated 227 with the corresponding YANG module, as shown in Table 1. 229 +--------+---------------------------+-----------+ 230 | Prefix | YANG module | Reference | 231 +--------+---------------------------+-----------+ 232 | if | ietf-interfaces | [RFC7223] | 233 | ip | ietf-ip | [RFC7277] | 234 | rt | ietf-routing | Section 7 | 235 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 236 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 237 | yang | ietf-yang-types | [RFC6991] | 238 | inet | ietf-inet-types | [RFC6991] | 239 +--------+---------------------------+-----------+ 241 Table 1: Prefixes and corresponding YANG modules 243 3. Objectives 245 The initial design of the core routing data model was driven by the 246 following objectives: 248 o The data model should be suitable for the common address families, 249 in particular IPv4 and IPv6, and for unicast and multicast 250 routing, as well as Multiprotocol Label Switching (MPLS). 252 o A simple IP routing system, such as one that uses only static 253 routing, should be configurable in a simple way, ideally without 254 any need to develop additional YANG modules. 256 o On the other hand, the core routing framework must allow for 257 complicated implementations involving multiple routing information 258 bases (RIB) and multiple routing protocols, as well as controlled 259 redistributions of routing information. 261 o Device vendors will want to map the data models built on this 262 generic framework to their proprietary data models and 263 configuration interfaces. Therefore, the framework should be 264 flexible enough to facilitate such a mapping and accommodate data 265 models with different logic. 267 4. The Design of the Core Routing Data Model 269 The core routing data model consists of three YANG modules. The 270 first module, "ietf-routing", defines the generic components of a 271 routing system. The other two modules, "ietf-ipv4-unicast-routing" 272 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 273 with additional data nodes that are needed for IPv4 and IPv6 unicast 274 routing, respectively. Figures 1 and 2 show abridged views of the 275 configuration and state data hierarchies. See Appendix A for the 276 complete data trees. 278 +--rw routing 279 +--rw routing-instance* [name] 280 +--rw name 281 +--rw type? 282 +--rw enabled? 283 +--rw router-id? 284 +--rw description? 285 +--rw interfaces 286 | +--rw interface* 287 +--rw routing-protocols 288 | +--rw routing-protocol* [type name] 289 | +--rw type 290 | +--rw name 291 | +--rw description? 292 | +--rw enabled? 293 | +--rw route-preference? 294 | +--rw static-routes 295 | ... 296 +--rw ribs 297 +--rw rib* [name] 298 +--rw name 299 +--rw address-family? 300 +--rw description? 302 Figure 1: Configuration data hierarchy. 304 +--ro routing-state 305 +--ro routing-instance* [name] 306 +--ro name 307 +--ro type? 308 +--ro router-id? 309 +--ro interfaces 310 | +--ro interface* 311 +--ro routing-protocols 312 | +--ro routing-protocol* [type name] 313 | +--ro type 314 | +--ro name 315 | +--ro route-preference 316 +--ro ribs 317 +--ro rib* [name] 318 +--ro name 319 +--ro address-family 320 +--ro default-rib? 321 +--ro routes 322 ... 324 Figure 2: State data hierarchy. 326 As can be seen from Figures 1 and 2, the core routing data model 327 introduces several generic components of a routing framework: routing 328 instances, RIBs containing lists of routes, and routing protocols. 329 Section 5 describes these components in more detail. 331 4.1. System-Controlled and User-Controlled List Entries 333 The core routing data model defines several lists in the schema tree, 334 for example "routing-instance" or "rib", that have to be populated 335 with at least one entry in any properly functioning device, and 336 additional entries may be configured by a client. 338 In such a list, the server creates the required item as a so-called 339 system-controlled entry in state data, i.e., inside the "routing- 340 state" container. 342 Additional entries may be created in the configuration by a client, 343 e.g., via the NETCONF protocol. These are so-called user-controlled 344 entries. If the server accepts a configured user-controlled entry, 345 then this entry also appears in the state data version of the list. 347 Corresponding entries in both versions of the list (in state data and 348 configuration) have the same value of the list key. 350 The user may also provide supplemental configuration of system- 351 controlled entries. To do so, the user creates a new entry in the 352 configuration with the desired contents. In order to bind this entry 353 with the corresponding entry in the state data list, the key of the 354 configuration entry has to be set to the same value as the key of the 355 state entry. 357 An example can be seen in Appendix D: the "/routing-state/routing- 358 instance" list has a single system-controlled entry whose "name" key 359 has the value "rtr0". This entry is configured by the "/routing/ 360 routing-instance" entry whose "name" key is also "rtr0". 362 Deleting a user-controlled entry from the configuration list results 363 in the removal of the corresponding entry in the state data list. In 364 contrast, if a system-controlled entry is deleted from the 365 configuration list, only the extra configuration specified in that 366 entry is removed but the corresponding state data entry remains in 367 the list. 369 5. Basic Building Blocks 371 This section describes the essential components of the core routing 372 data model. 374 5.1. Routing Instance 376 The core routing data model supports one or more routing instances 377 appearing as entries of the "routing-instance" list. Each routing 378 instance has separate configuration and state data under 379 "/rt:routing/rt:routing-instance" and "/rt:routing-state/rt:routing- 380 instance", respectively. 382 The semantics of the term "routing instance" is deliberately left 383 undefined. It is expected that future YANG modules will define data 384 models for specific types of routing instances, such as VRF (virtual 385 routing and forwarding) instances that are used for BGP/MPLS virtual 386 private networks [RFC4364]. For each type of routing instance, an 387 identity derived from "rt:routing-instance" SHALL be defined. This 388 identity is then referred to by the value of the "type" leaf (a child 389 node of "routing-instance" list). 391 Each network layer interface has to be assigned to one or more 392 routing instances in order to be able to participate in packet 393 forwarding, routing protocols and other operations of those routing 394 instances. The assignment is accomplished by placing a corresponding 395 (system- or user-controlled) entry in the leaf-list of routing 396 instance interfaces ("rt:interface"). Each entry is the name of a 397 configured network layer interface, see the "ietf-interfaces" 398 module [RFC7223]. 400 5.1.1. Parameters of IPv6 Routing Instance Interfaces 402 YANG module "ietf-ipv6-unicast-routing" (Section 9) augments the 403 configuration and state data of interfaces with definitions of the 404 following variables as required by [RFC4861], sec. 6.2.1: 406 o send-advertisements, 408 o max-rtr-adv-interval, 410 o min-rtr-adv-interval, 412 o managed-flag, 414 o other-config-flag, 416 o link-mtu, 418 o reachable-time, 420 o retrans-timer, 421 o cur-hop-limit, 423 o default-lifetime, 425 o prefix-list: a list of prefixes to be advertised. 427 The following parameters are associated with each prefix in the 428 list: 430 * valid-lifetime, 432 * on-link-flag, 434 * preferred-lifetime, 436 * autonomous-flag. 438 NOTES: 440 1. The "IsRouter" flag, which is also required by [RFC4861], is 441 implemented in the "ietf-ip" module [RFC7277] (leaf 442 "ip:forwarding"). 444 2. The original specification [RFC4861] allows the implementations 445 to decide whether the "valid-lifetime" and "preferred-lifetime" 446 parameters remain the same in consecutive advertisements, or 447 decrement in real time. However, the latter behavior seems 448 problematic because the values might be reset again to the 449 (higher) configured values after a configuration is reloaded. 450 Moreover, no implementation is known to use the decrementing 451 behavior. The "ietf-ipv6-unicast-routing" module therefore 452 assumes the former behavior with constant values. 454 5.2. Route 456 Routes are basic elements of information in a routing system. The 457 core routing data model defines only the following minimal set of 458 route attributes: 460 o "destination-prefix": IP prefix specifying the set of destination 461 addresses for which the route may be used. This attribute is 462 mandatory. 464 o "route-preference": an integer value (also known as administrative 465 distance) that is used for selecting a preferred route among 466 routes with the same destination prefix. A lower value means a 467 more preferred route. 469 o "next-hop": determines the action to be performed with a packet. 471 Routes are primarily state data that appear as entries of RIBs 472 (Section 5.3) but they may also be found in configuration data, for 473 example as manually configured static routes. In the latter case, 474 configurable route attributes are generally a subset of route 475 attributes described above. 477 5.3. Routing Information Base (RIB) 479 Every routing instance manages one or more routing information bases 480 (RIB). A RIB is a list of routes complemented with administrative 481 data. Each RIB contains only routes of one address family. An 482 address family is represented by an identity derived from the 483 "rt:address-family" base identity. 485 In the core routing data model, RIBs are state data represented as 486 entries of the list "/routing-state/routing-instance/ribs/rib". The 487 contents of RIBs are controlled and manipulated by routing protocol 488 operations which may result in route additions, removals and 489 modifications. This also includes manipulations via the "static" 490 and/or "direct" pseudo-protocols, see Section 5.4.1. 492 Each routing instance has, for every supported address family, one 493 RIB marked as the so-called default RIB. Its role is explained in 494 Section 5.4. 496 Simple router implementations that do not advertise the feature 497 "multiple-ribs" will typically create one system-controlled RIB per 498 routing instance and supported address family, and mark it as the 499 default RIB. 501 More complex router implementations advertising the "multiple-ribs" 502 feature support multiple RIBs per address family that can be used for 503 policy routing and other purposes. 505 5.4. Routing Protocol 507 The core routing data model provides an open-ended framework for 508 defining multiple routing protocol instances within a routing 509 instance. Each routing protocol instance MUST be assigned a type, 510 which is an identity derived from the "rt:routing-protocol" base 511 identity. The core routing data model defines two identities for the 512 direct and static pseudo-protocols (Section 5.4.1). 514 Multiple routing protocol instances of the same type MAY be 515 configured within the same routing instance. 517 5.4.1. Routing Pseudo-Protocols 519 The core routing data model defines two special routing protocol 520 types - "direct" and "static". Both are in fact pseudo-protocols, 521 which means they are confined to the local device and do not exchange 522 any routing information with adjacent routers. 524 Every routing instance MUST implement exactly one instance of the 525 "direct" pseudo-protocol type. It is the source of direct routes for 526 all configured address families. Direct routes are normally supplied 527 by the operating system kernel, based on the configuration of network 528 interface addresses, see Section 6.2. Direct routes MUST be 529 installed in default RIBs of all supported address families. 531 A pseudo-protocol of the type "static" allows for specifying routes 532 manually. It MAY be configured in zero or multiple instances, 533 although a typical configuration will have exactly one instance per 534 routing instance. 536 5.4.2. Defining New Routing Protocols 538 It is expected that future YANG modules will create data models for 539 additional routing protocol types. Such a new module has to define 540 the protocol-specific configuration and state data, and it has to fit 541 it into the core routing framework in the following way: 543 o A new identity MUST be defined for the routing protocol and its 544 base identity MUST be set to "rt:routing-protocol", or to an 545 identity derived from "rt:routing-protocol". 547 o Additional route attributes MAY be defined, preferably in one 548 place by means of defining a YANG grouping. The new attributes 549 have to be inserted by augmenting the definitions of the nodes 551 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 553 and 555 /rt:fib-route/rt:output/rt:route, 557 and possibly other places in the configuration, state data, 558 notifications, and RPC input or output. 560 o Configuration parameters and/or state data for the new protocol 561 can be defined by augmenting the "routing-protocol" data node 562 under both "/routing" and "/routing-state". 564 o Per-interface configuration, including activation of the routing 565 protocol on individual interfaces, can use references to entries 566 in the leaf-list of routing instance's interfaces (rt:interface). 568 By using the "when" statement, the augmented configuration parameters 569 and state data specific to the new protocol SHOULD be made 570 conditional and valid only if the value of "rt:type" or "rt:source- 571 protocol" is equal to the new protocol's identity. It is also 572 RECOMMENDED that protocol-specific data nodes be encapsulated in 573 appropriately named containers. 575 The above steps are implemented by the example YANG module for the 576 RIP routing protocol in Appendix C. 578 5.5. RPC Operations 580 The "ietf-routing" module defines one RPC operation: 582 o fib-route: query a routing instance for the active route in the 583 Forwarding Information Base (FIB). It is the route that is 584 currently used for sending datagrams to a destination host whose 585 address is passed as an input parameter. 587 6. Interactions with Other YANG Modules 589 The semantics of the core routing data model also depends on several 590 configuration parameters that are defined in other YANG modules. 592 6.1. Module "ietf-interfaces" 594 The following boolean switch is defined in the "ietf-interfaces" YANG 595 module [RFC7223]: 597 /if:interfaces/if:interface/if:enabled 599 If this switch is set to "false" for a network layer interface, 600 the device MUST behave exactly as if that interface was not 601 assigned to any routing instance at all. 603 6.2. Module "ietf-ip" 605 The following boolean switches are defined in the "ietf-ip" YANG 606 module [RFC7277]: 608 /if:interfaces/if:interface/ip:ipv4/ip:enabled 609 If this switch is set to "false" for a network layer interface, 610 then all IPv4 routing functions related to that interface MUST be 611 disabled. 613 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 615 If this switch is set to "false" for a network layer interface, 616 then the forwarding of IPv4 datagrams to and from this interface 617 MUST be disabled. However, the interface may participate in other 618 IPv4 routing functions, such as routing protocols. 620 /if:interfaces/if:interface/ip:ipv6/ip:enabled 622 If this switch is set to "false" for a network layer interface, 623 then all IPv6 routing functions related to that interface MUST be 624 disabled. 626 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 628 If this switch is set to "false" for a network layer interface, 629 then the forwarding of IPv6 datagrams to and from this interface 630 MUST be disabled. However, the interface may participate in other 631 IPv6 routing functions, such as routing protocols. 633 In addition, the "ietf-ip" module allows for configuring IPv4 and 634 IPv6 addresses and network prefixes or masks on network layer 635 interfaces. Configuration of these parameters on an enabled 636 interface MUST result in an immediate creation of the corresponding 637 direct route. The destination prefix of this route is set according 638 to the configured IP address and network prefix/mask, and the 639 interface is set as the outgoing interface for that route. 641 7. Routing Management YANG Module 643 RFC Editor: In this section, replace all occurrences of 'XXXX' with 644 the actual RFC number and all occurrences of the revision date below 645 with the date of RFC publication (and remove this note). 647 file "ietf-routing@2015-04-17.yang" 649 module ietf-routing { 651 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 653 prefix "rt"; 655 import ietf-yang-types { 656 prefix "yang"; 658 } 660 import ietf-interfaces { 661 prefix "if"; 662 } 664 organization 665 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 667 contact 668 "WG Web: 669 WG List: 671 WG Chair: Thomas Nadeau 672 674 WG Chair: Juergen Schoenwaelder 675 677 Editor: Ladislav Lhotka 678 "; 680 description 681 "This YANG module defines essential components for the management 682 of a routing subsystem. 684 Copyright (c) 2014 IETF Trust and the persons identified as 685 authors of the code. All rights reserved. 687 Redistribution and use in source and binary forms, with or 688 without modification, is permitted pursuant to, and subject to 689 the license terms contained in, the Simplified BSD License set 690 forth in Section 4.c of the IETF Trust's Legal Provisions 691 Relating to IETF Documents 692 (http://trustee.ietf.org/license-info). 694 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 695 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 696 'OPTIONAL' in the module text are to be interpreted as described 697 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 699 This version of this YANG module is part of RFC XXXX 700 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 701 full legal notices."; 703 revision 2015-04-17 { 704 description 705 "Initial revision."; 707 reference 708 "RFC XXXX: A YANG Data Model for Routing Management"; 709 } 711 /* Features */ 713 feature multiple-ribs { 714 description 715 "This feature indicates that the server supports user-defined 716 RIBs. 718 Servers that do not advertise this feature SHOULD provide 719 exactly one system-controlled RIB per routing-instance and 720 supported address family and make them also the default RIBs. 721 These RIBs then appear as entries of the list 722 /routing-state/routing-instance/ribs/rib."; 723 } 725 feature router-id { 726 description 727 "This feature indicates that the server supports configuration 728 of an explicit 32-bit router ID that is used by some routing 729 protocols. 731 Servers that do not advertise this feature set a router ID 732 algorithmically, usually to one of configured IPv4 addresses. 733 However, this algorithm is implementation-specific."; 734 } 736 /* Identities */ 738 identity address-family { 739 description 740 "Base identity from which identities describing address 741 families are derived."; 742 } 744 identity ipv4 { 745 base address-family; 746 description 747 "This identity represents IPv4 address family."; 748 } 750 identity ipv6 { 751 base address-family; 752 description 753 "This identity represents IPv6 address family."; 754 } 755 identity routing-instance { 756 description 757 "Base identity from which identities describing routing 758 instance types are derived."; 759 } 761 identity default-routing-instance { 762 base routing-instance; 763 description 764 "This identity represents either a default routing instance, or 765 the only routing instance on systems that do not support 766 multiple instances."; 767 } 769 identity routing-protocol { 770 description 771 "Base identity from which routing protocol identities are 772 derived."; 773 } 775 identity direct { 776 base routing-protocol; 777 description 778 "Routing pseudo-protocol that provides routes to directly 779 connected networks."; 780 } 782 identity static { 783 base routing-protocol; 784 description 785 "Static routing pseudo-protocol."; 786 } 788 /* Type Definitions */ 790 typedef routing-instance-ref { 791 type leafref { 792 path "/rt:routing/rt:routing-instance/rt:name"; 793 } 794 description 795 "This type is used for leafs that reference a routing instance 796 configuration."; 797 } 799 typedef routing-instance-state-ref { 800 type leafref { 801 path "/rt:routing-state/rt:routing-instance/rt:name"; 802 } 803 description 804 "This type is used for leafs that reference state data of a 805 routing instance."; 806 } 808 typedef route-preference { 809 type uint32; 810 description 811 "This type is used for route preferences."; 812 } 814 /* Groupings */ 816 grouping address-family { 817 description 818 "This grouping provides a leaf identifying an address 819 family."; 820 leaf address-family { 821 type identityref { 822 base address-family; 823 } 824 mandatory "true"; 825 description 826 "Address family."; 827 } 828 } 830 grouping router-id { 831 description 832 "This grouping provides router ID."; 833 leaf router-id { 834 type yang:dotted-quad; 835 description 836 "A 32-bit number in the form of a dotted quad that is used by 837 some routing protocols identifying a router."; 838 reference 839 "RFC 2328: OSPF Version 2."; 840 } 841 } 843 grouping special-next-hop { 844 description 845 "This grouping provides a leaf with an enumeration of special 846 next-hops."; 847 leaf special-next-hop { 848 type enumeration { 849 enum blackhole { 850 description 851 "Silently discard the packet."; 852 } 853 enum unreachable { 854 description 855 "Discard the packet and notify the sender with an error 856 message indicating that the destination host is 857 unreachable."; 858 } 859 enum prohibit { 860 description 861 "Discard the packet and notify the sender with an error 862 message indicating that the communication is 863 administratively prohibited."; 864 } 865 enum receive { 866 description 867 "The packet will be received by the local system."; 868 } 869 } 870 description 871 "Special next-hop options."; 872 } 873 } 875 grouping next-hop-content { 876 description 877 "Generic parameters of next-hops in static routes."; 878 choice next-hop-options { 879 mandatory "true"; 880 description 881 "Options for next-hops in static routes. 883 It is expected that other cases will be added through 884 augments from other modules, e.g., for Equal-Cost Multipath 885 routing (ECMP)."; 886 case simple-next-hop { 887 description 888 "Simple next-hop is specified as an outgoing interface, 889 next-hop address or both. 891 Address-family-specific modules are expected to provide 892 'next-hop-address' leaf via augmentation."; 893 leaf outgoing-interface { 894 type leafref { 895 path "/rt:routing/rt:routing-instance/rt:interfaces/" 896 + "rt:interface"; 897 } 898 description 899 "Name of the outgoing interface."; 900 } 901 } 902 case special-next-hop { 903 uses special-next-hop; 904 } 905 } 906 } 908 grouping next-hop-state-content { 909 description 910 "Generic parameters of next-hops in state data."; 911 choice next-hop-options { 912 mandatory "true"; 913 description 914 "Options for next-hops in state data. 916 It is expected that other cases will be added through 917 augments from other modules, e.g., for ECMP or recursive 918 next-hops."; 919 case simple-next-hop { 920 description 921 "Simple next-hop is specified as an outgoing interface, 922 next-hop address or both. 924 Address-family-specific modules are expected to provide 925 'next-hop-address' leaf via augmentation."; 926 leaf outgoing-interface { 927 type leafref { 928 path "/rt:routing-state/rt:routing-instance/" 929 + "rt:interfaces/rt:interface"; 930 } 931 description 932 "Name of the outgoing interface."; 933 } 934 } 935 case special-next-hop { 936 uses special-next-hop; 937 } 938 } 939 } 941 grouping route-metadata { 942 description 943 "Common route metadata."; 944 leaf source-protocol { 945 type identityref { 946 base routing-protocol; 948 } 949 mandatory "true"; 950 description 951 "Type of the routing protocol from which the route 952 originated."; 953 } 954 leaf active { 955 type empty; 956 description 957 "Presence of this leaf indicates that the route is preferred 958 among all routes in the same RIB that have the same 959 destination prefix."; 960 } 961 leaf last-updated { 962 type yang:date-and-time; 963 description 964 "Time stamp of the last modification of the route. If the 965 route was never modified, it is the time when the route was 966 inserted into the RIB."; 967 } 968 } 970 /* State data */ 972 augment "/if:interfaces-state/if:interface" { 973 description 974 "This augment adds a wrapped leaf-list to interface state 975 data."; 976 leaf routing-instance { 977 type routing-instance-state-ref; 978 must "../if:name=/rt:routing-state/" 979 + "rt:routing-instance[rt:name=current()]/rt:interfaces/" 980 + "rt:interface" { 981 error-message 982 "The interface is not assigned to the routing instance."; 983 description 984 "The reference must mirror a corresponding assignment under 985 routing-instance."; 986 } 987 description 988 "The name of the routing instance to which the interface is 989 assigned."; 990 } 991 } 993 container routing-state { 994 config "false"; 995 description 996 "State data of the routing subsystem."; 997 list routing-instance { 998 key "name"; 999 min-elements "1"; 1000 description 1001 "Each list entry is a container for state data of a routing 1002 instance. 1004 An implementation MUST support routing instance(s) of the 1005 type 'rt:default-routing-instance', and MAY support other 1006 types. An implementation MAY restrict the number of routing 1007 instances of each supported type. 1009 An implementation SHOULD create at least one 1010 system-controlled instance, and MAY allow the clients to 1011 create user-controlled routing instances in 1012 configuration."; 1013 leaf name { 1014 type string; 1015 description 1016 "The name of the routing instance. 1018 For system-controlled instances the name is persistent, 1019 i.e., it SHOULD NOT change across reboots."; 1020 } 1021 leaf type { 1022 type identityref { 1023 base routing-instance; 1024 } 1025 description 1026 "The routing instance type."; 1027 } 1028 uses router-id { 1029 description 1030 "Global router ID. 1032 It may be either configured or assigned algorithmically by 1033 the implementation."; 1034 } 1035 container interfaces { 1036 description 1037 "Network layer interfaces belonging to the routing 1038 instance."; 1039 leaf-list interface { 1040 type if:interface-state-ref; 1041 description 1042 "Each entry is a reference to the name of a configured 1043 network layer interface."; 1045 } 1046 } 1047 container routing-protocols { 1048 description 1049 "Container for the list of routing protocol instances."; 1050 list routing-protocol { 1051 key "type name"; 1052 description 1053 "State data of a routing protocol instance. 1055 An implementation MUST provide exactly one 1056 system-controlled instance of the type 'direct'. Other 1057 instances MAY be created by configuration."; 1058 leaf type { 1059 type identityref { 1060 base routing-protocol; 1061 } 1062 description 1063 "Type of the routing protocol."; 1064 } 1065 leaf name { 1066 type string; 1067 description 1068 "The name of the routing protocol instance. 1070 For system-controlled instances this name is 1071 persistent, i.e., it SHOULD NOT change across 1072 reboots."; 1073 } 1074 leaf route-preference { 1075 type route-preference; 1076 mandatory "true"; 1077 description 1078 "The value of route preference (administrative 1079 distance) assigned to all routes generated by the 1080 routing protocol instance. A lower value means a more 1081 preferred route."; 1082 } 1083 } 1084 } 1085 container ribs { 1086 description 1087 "Container for RIBs."; 1088 list rib { 1089 key "name"; 1090 min-elements "1"; 1091 description 1092 "Each entry represents a RIB identified by the 'name' 1093 key. All routes in a RIB MUST belong to the same address 1094 family. 1096 For each routing instance, an implementation SHOULD 1097 provide one system-controlled default RIB for each 1098 supported address family."; 1099 leaf name { 1100 type string; 1101 description 1102 "The name of the RIB."; 1103 } 1104 uses address-family; 1105 leaf default-rib { 1106 if-feature multiple-ribs; 1107 type boolean; 1108 default "true"; 1109 description 1110 "This flag has the value of 'true' if and only if the 1111 RIB is the default RIB for the given address family. 1113 A default RIB always receives direct routes. By 1114 default it also receives routes from all routing 1115 protocols."; 1116 } 1117 container routes { 1118 description 1119 "Current content of the RIB."; 1120 list route { 1121 description 1122 "A RIB route entry. This data node MUST be augmented 1123 with information specific for routes of each address 1124 family."; 1125 leaf route-preference { 1126 type route-preference; 1127 description 1128 "This route attribute, also known as administrative 1129 distance, allows for selecting the preferred route 1130 among routes with the same destination prefix. A 1131 smaller value means a more preferred route."; 1132 } 1133 container next-hop { 1134 description 1135 "Route's next-hop attribute."; 1136 uses next-hop-state-content; 1137 } 1138 uses route-metadata; 1139 } 1140 } 1142 } 1143 } 1144 } 1145 } 1147 /* Configuration Data */ 1149 container routing { 1150 description 1151 "Configuration parameters for the routing subsystem."; 1152 list routing-instance { 1153 key "name"; 1154 description 1155 "Configuration of a routing instance."; 1156 leaf name { 1157 type string; 1158 description 1159 "The name of the routing instance. 1161 For system-controlled entries, the value of this leaf must 1162 be the same as the name of the corresponding entry in 1163 state data. 1165 For user-controlled entries, an arbitrary name can be 1166 used."; 1167 } 1168 leaf type { 1169 type identityref { 1170 base routing-instance; 1171 } 1172 default "rt:default-routing-instance"; 1173 description 1174 "The type of the routing instance."; 1175 } 1176 leaf enabled { 1177 type boolean; 1178 default "true"; 1179 description 1180 "Enable/disable the routing instance. 1182 If this parameter is false, the parent routing instance is 1183 disabled and does not appear in state data, despite any 1184 other configuration that might be present."; 1185 } 1186 uses router-id { 1187 if-feature router-id; 1188 description 1189 "Configuration of the global router ID. Routing protocols 1190 that use router ID can use this parameter or override it 1191 with another value."; 1192 } 1193 leaf description { 1194 type string; 1195 description 1196 "Textual description of the routing instance."; 1197 } 1198 container interfaces { 1199 description 1200 "Assignment of the routing instance's interfaces."; 1201 leaf-list interface { 1202 type if:interface-ref; 1203 description 1204 "The name of a configured network layer interface to be 1205 assigned to the routing-instance."; 1206 } 1207 } 1208 container routing-protocols { 1209 description 1210 "Configuration of routing protocol instances."; 1211 list routing-protocol { 1212 key "type name"; 1213 description 1214 "Each entry contains configuration of a routing protocol 1215 instance."; 1216 leaf type { 1217 type identityref { 1218 base routing-protocol; 1219 } 1220 description 1221 "Type of the routing protocol - an identity derived 1222 from the 'routing-protocol' base identity."; 1223 } 1224 leaf name { 1225 type string; 1226 description 1227 "An arbitrary name of the routing protocol instance."; 1228 } 1229 leaf description { 1230 type string; 1231 description 1232 "Textual description of the routing protocol 1233 instance."; 1234 } 1235 leaf enabled { 1236 type boolean; 1237 default "true"; 1238 description 1239 "Enable/disable the routing protocol instance. 1241 If this parameter is false, the parent routing 1242 protocol instance is disabled and does not appear in 1243 state data, despite any other configuration that might 1244 be present."; 1245 } 1246 leaf route-preference { 1247 type route-preference; 1248 description 1249 "The value of route preference (administrative 1250 distance). 1252 The default value depends on the routing protocol 1253 type, and may also be implementation-dependent."; 1254 } 1255 container static-routes { 1256 when "../type='rt:static'" { 1257 description 1258 "This container is only valid for the 'static' 1259 routing protocol."; 1260 } 1261 description 1262 "Configuration of the 'static' pseudo-protocol. 1264 Address-family-specific modules augment this node with 1265 their lists of routes."; 1266 } 1267 } 1268 } 1269 container ribs { 1270 description 1271 "Configuration of RIBs."; 1272 list rib { 1273 key "name"; 1274 description 1275 "Each entry contains configuration for a RIB identified 1276 by the 'name' key. 1278 Entries having the same key as a system-controlled entry 1279 of the list /routing-state/routing-instance/ribs/rib are 1280 used for configuring parameters of that entry. Other 1281 entries define additional user-controlled RIBs."; 1282 leaf name { 1283 type string; 1284 description 1285 "The name of the RIB. 1287 For system-controlled entries, the value of this leaf 1288 must be the same as the name of the corresponding 1289 entry in state data. 1291 For user-controlled entries, an arbitrary name can be 1292 used."; 1293 } 1294 uses address-family { 1295 description 1296 "Address family of the RIB. 1298 It is mandatory for user-controlled RIBs. For 1299 system-controlled RIBs it can be omitted, otherwise it 1300 must match the address family of the corresponding 1301 state entry."; 1302 refine "address-family" { 1303 mandatory "false"; 1304 } 1305 } 1306 leaf description { 1307 type string; 1308 description 1309 "Textual description of the RIB."; 1310 } 1311 } 1312 } 1313 } 1314 } 1316 /* RPC operations */ 1318 rpc fib-route { 1319 description 1320 "Return the active FIB route that a routing-instance uses for 1321 sending packets to a destination address."; 1322 input { 1323 leaf routing-instance-name { 1324 type routing-instance-state-ref; 1325 mandatory "true"; 1326 description 1327 "Name of the routing instance whose forwarding information 1328 base is being queried. 1330 If the routing instance with name equal to the value of 1331 this parameter doesn't exist, then this operation SHALL 1332 fail with error-tag 'data-missing' and error-app-tag 1333 'routing-instance-not-found'."; 1334 } 1335 container destination-address { 1336 description 1337 "Network layer destination address. 1339 Address family specific modules MUST augment this 1340 container with a leaf named 'address'."; 1341 uses address-family; 1342 } 1343 } 1344 output { 1345 container route { 1346 description 1347 "The active FIB route for the specified destination. 1349 If the routing instance has no active FIB route for the 1350 destination address, no output is returned - the server 1351 SHALL send an containing a single element 1352 . 1354 Address family specific modules MUST augment this list 1355 with appropriate route contents."; 1356 uses address-family; 1357 container next-hop { 1358 description 1359 "Route's next-hop attribute."; 1360 uses next-hop-state-content; 1361 } 1362 uses route-metadata; 1363 } 1364 } 1365 } 1366 } 1368 1370 8. IPv4 Unicast Routing Management YANG Module 1372 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1373 the actual RFC number and all occurrences of the revision date below 1374 with the date of RFC publication (and remove this note). 1376 file "ietf-ipv4-unicast-routing@2015-04-17.yang" 1378 module ietf-ipv4-unicast-routing { 1380 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1382 prefix "v4ur"; 1383 import ietf-routing { 1384 prefix "rt"; 1385 } 1387 import ietf-inet-types { 1388 prefix "inet"; 1389 } 1391 organization 1392 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1394 contact 1395 "WG Web: 1396 WG List: 1398 WG Chair: Thomas Nadeau 1399 1401 WG Chair: Juergen Schoenwaelder 1402 1404 Editor: Ladislav Lhotka 1405 "; 1407 description 1408 "This YANG module augments the 'ietf-routing' module with basic 1409 configuration and state data for IPv4 unicast routing. 1411 Copyright (c) 2014 IETF Trust and the persons identified as 1412 authors of the code. All rights reserved. 1414 Redistribution and use in source and binary forms, with or 1415 without modification, is permitted pursuant to, and subject to 1416 the license terms contained in, the Simplified BSD License set 1417 forth in Section 4.c of the IETF Trust's Legal Provisions 1418 Relating to IETF Documents 1419 (http://trustee.ietf.org/license-info). 1421 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1422 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1423 'OPTIONAL' in the module text are to be interpreted as described 1424 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1426 This version of this YANG module is part of RFC XXXX 1427 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1428 full legal notices."; 1430 revision 2015-04-17 { 1431 description 1432 "Initial revision."; 1433 reference 1434 "RFC XXXX: A YANG Data Model for Routing Management"; 1435 } 1437 /* Identities */ 1439 identity ipv4-unicast { 1440 base rt:ipv4; 1441 description 1442 "This identity represents the IPv4 unicast address family."; 1443 } 1445 /* State data */ 1447 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 1448 + "rt:routes/rt:route" { 1449 when "../../rt:address-family = 'v4ur:ipv4-unicast'" { 1450 description 1451 "This augment is valid only for IPv4 unicast."; 1452 } 1453 description 1454 "This leaf augments an IPv4 unicast route."; 1455 leaf destination-prefix { 1456 type inet:ipv4-prefix; 1457 description 1458 "IPv4 destination prefix."; 1459 } 1460 } 1462 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 1463 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 1464 + "rt:simple-next-hop" { 1465 when "../../../rt:address-family = 'v4ur:ipv4-unicast'" { 1466 description 1467 "This augment is valid only for IPv4 unicast."; 1468 } 1469 description 1470 "This leaf augments the 'simple-next-hop' case of IPv4 unicast 1471 routes."; 1472 leaf next-hop-address { 1473 type inet:ipv4-address; 1474 description 1475 "IPv4 address of the next-hop."; 1476 } 1477 } 1478 /* Configuration data */ 1480 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 1481 + "rt:routing-protocol/rt:static-routes" { 1482 description 1483 "This augment defines the configuration of the 'static' 1484 pseudo-protocol with data specific to IPv4 unicast."; 1485 container ipv4 { 1486 description 1487 "Configuration of a 'static' pseudo-protocol instance 1488 consists of a list of routes."; 1489 list route { 1490 key "destination-prefix"; 1491 ordered-by "user"; 1492 description 1493 "A user-ordered list of static routes."; 1494 leaf destination-prefix { 1495 type inet:ipv4-prefix; 1496 mandatory "true"; 1497 description 1498 "IPv4 destination prefix."; 1499 } 1500 leaf description { 1501 type string; 1502 description 1503 "Textual description of the route."; 1504 } 1505 container next-hop { 1506 description 1507 "Configuration of next-hop."; 1508 uses rt:next-hop-content { 1509 augment "next-hop-options" { 1510 description 1511 "Add next-hop address case."; 1512 leaf next-hop-address { 1513 type inet:ipv4-address; 1514 description 1515 "IPv4 address of the next-hop."; 1516 } 1517 } 1518 } 1519 } 1520 } 1521 } 1522 } 1524 /* RPC operations */ 1525 augment "/rt:fib-route/rt:input/rt:destination-address" { 1526 when "rt:address-family='v4ur:ipv4-unicast'" { 1527 description 1528 "This augment is valid only for IPv4 unicast."; 1529 } 1530 description 1531 "This leaf augments the 'rt:destination-address' parameter of 1532 the 'rt:fib-route' operation."; 1533 leaf address { 1534 type inet:ipv4-address; 1535 description 1536 "IPv4 destination address."; 1537 } 1538 } 1540 augment "/rt:fib-route/rt:output/rt:route" { 1541 when "rt:address-family='v4ur:ipv4-unicast'" { 1542 description 1543 "This augment is valid only for IPv4 unicast."; 1544 } 1545 description 1546 "This leaf augments the reply to the 'rt:fib-route' 1547 operation."; 1548 leaf destination-prefix { 1549 type inet:ipv4-prefix; 1550 description 1551 "IPv4 destination prefix."; 1552 } 1553 } 1555 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 1556 + "rt:next-hop-options/rt:simple-next-hop" { 1557 when "../rt:address-family='v4ur:ipv4-unicast'" { 1558 description 1559 "This augment is valid only for IPv4 unicast."; 1560 } 1561 description 1562 "This leaf augments the 'simple-next-hop' case in the reply to 1563 the 'rt:fib-route' operation."; 1564 leaf next-hop-address { 1565 type inet:ipv4-address; 1566 description 1567 "IPv4 address of the next-hop."; 1568 } 1569 } 1570 } 1572 1574 9. IPv6 Unicast Routing Management YANG Module 1576 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1577 the actual RFC number and all occurrences of the revision date below 1578 with the date of RFC publication (and remove this note). 1580 file "ietf-ipv6-unicast-routing@2015-04-17.yang" 1582 module ietf-ipv6-unicast-routing { 1584 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1586 prefix "v6ur"; 1588 import ietf-routing { 1589 prefix "rt"; 1590 } 1592 import ietf-inet-types { 1593 prefix "inet"; 1594 } 1596 import ietf-interfaces { 1597 prefix "if"; 1598 } 1600 import ietf-ip { 1601 prefix "ip"; 1602 } 1604 organization 1605 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1607 contact 1608 "WG Web: 1609 WG List: 1611 WG Chair: Thomas Nadeau 1612 1614 WG Chair: Juergen Schoenwaelder 1615 1617 Editor: Ladislav Lhotka 1618 "; 1620 description 1621 "This YANG module augments the 'ietf-routing' module with basic 1622 configuration and state data for IPv6 unicast routing. 1624 Copyright (c) 2014 IETF Trust and the persons identified as 1625 authors of the code. All rights reserved. 1627 Redistribution and use in source and binary forms, with or 1628 without modification, is permitted pursuant to, and subject to 1629 the license terms contained in, the Simplified BSD License set 1630 forth in Section 4.c of the IETF Trust's Legal Provisions 1631 Relating to IETF Documents 1632 (http://trustee.ietf.org/license-info). 1634 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1635 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1636 'OPTIONAL' in the module text are to be interpreted as described 1637 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1639 This version of this YANG module is part of RFC XXXX 1640 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1641 full legal notices."; 1643 revision 2015-04-17 { 1644 description 1645 "Initial revision."; 1646 reference 1647 "RFC XXXX: A YANG Data Model for Routing Management"; 1648 } 1650 /* Identities */ 1652 identity ipv6-unicast { 1653 base rt:ipv6; 1654 description 1655 "This identity represents the IPv6 unicast address family."; 1656 } 1658 /* State data */ 1660 augment "/if:interfaces-state/if:interface/ip:ipv6" { 1661 description 1662 "Augment interface state data with IPv6-specific parameters of 1663 router interfaces."; 1664 container ipv6-router-advertisements { 1665 description 1666 "Parameters of IPv6 Router Advertisements."; 1667 leaf send-advertisements { 1668 type boolean; 1669 description 1670 "A flag indicating whether or not the router sends periodic 1671 Router Advertisements and responds to Router 1672 Solicitations."; 1673 } 1674 leaf max-rtr-adv-interval { 1675 type uint16 { 1676 range "4..1800"; 1677 } 1678 units "seconds"; 1679 description 1680 "The maximum time allowed between sending unsolicited 1681 multicast Router Advertisements from the interface."; 1682 } 1683 leaf min-rtr-adv-interval { 1684 type uint16 { 1685 range "3..1350"; 1686 } 1687 units "seconds"; 1688 description 1689 "The minimum time allowed between sending unsolicited 1690 multicast Router Advertisements from the interface."; 1691 } 1692 leaf managed-flag { 1693 type boolean; 1694 description 1695 "The value that is placed in the 'Managed address 1696 configuration' flag field in the Router Advertisement."; 1697 } 1698 leaf other-config-flag { 1699 type boolean; 1700 description 1701 "The value that is placed in the 'Other configuration' flag 1702 field in the Router Advertisement."; 1703 } 1704 leaf link-mtu { 1705 type uint32; 1706 description 1707 "The value that is placed in MTU options sent by the 1708 router. A value of zero indicates that no MTU options are 1709 sent."; 1710 } 1711 leaf reachable-time { 1712 type uint32 { 1713 range "0..3600000"; 1714 } 1715 units "milliseconds"; 1716 description 1717 "The value that is placed in the Reachable Time field in 1718 the Router Advertisement messages sent by the router. A 1719 value of zero means unspecified (by this router)."; 1720 } 1721 leaf retrans-timer { 1722 type uint32; 1723 units "milliseconds"; 1724 description 1725 "The value that is placed in the Retrans Timer field in the 1726 Router Advertisement messages sent by the router. A value 1727 of zero means unspecified (by this router)."; 1728 } 1729 leaf cur-hop-limit { 1730 type uint8; 1731 description 1732 "The value that is placed in the Cur Hop Limit field in the 1733 Router Advertisement messages sent by the router. A value 1734 of zero means unspecified (by this router)."; 1735 } 1736 leaf default-lifetime { 1737 type uint16 { 1738 range "0..9000"; 1739 } 1740 units "seconds"; 1741 description 1742 "The value that is placed in the Router Lifetime field of 1743 Router Advertisements sent from the interface, in seconds. 1744 A value of zero indicates that the router is not to be 1745 used as a default router."; 1746 } 1747 container prefix-list { 1748 description 1749 "A list of prefixes that are placed in Prefix Information 1750 options in Router Advertisement messages sent from the 1751 interface. 1753 By default, these are all prefixes that the router 1754 advertises via routing protocols as being on-link for the 1755 interface from which the advertisement is sent."; 1756 list prefix { 1757 key "prefix-spec"; 1758 description 1759 "Advertised prefix entry and its parameters."; 1760 leaf prefix-spec { 1761 type inet:ipv6-prefix; 1762 description 1763 "IPv6 address prefix."; 1764 } 1765 leaf valid-lifetime { 1766 type uint32; 1767 units "seconds"; 1768 description 1769 "The value that is placed in the Valid Lifetime in the 1770 Prefix Information option. The designated value of all 1771 1's (0xffffffff) represents infinity. 1773 An implementation SHOULD keep this value constant in 1774 consecutive advertisements except when it is 1775 explicitly changed in configuration."; 1776 } 1777 leaf on-link-flag { 1778 type boolean; 1779 description 1780 "The value that is placed in the on-link flag ('L-bit') 1781 field in the Prefix Information option."; 1782 } 1783 leaf preferred-lifetime { 1784 type uint32; 1785 units "seconds"; 1786 description 1787 "The value that is placed in the Preferred Lifetime in 1788 the Prefix Information option, in seconds. The 1789 designated value of all 1's (0xffffffff) represents 1790 infinity. 1792 An implementation SHOULD keep this value constant in 1793 consecutive advertisements except when it is 1794 explicitly changed in configuration."; 1795 } 1796 leaf autonomous-flag { 1797 type boolean; 1798 description 1799 "The value that is placed in the Autonomous Flag field 1800 in the Prefix Information option."; 1801 } 1802 } 1803 } 1804 } 1805 } 1807 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 1808 + "rt:routes/rt:route" { 1809 when "../../rt:address-family = 'v6ur:ipv6-unicast'" { 1810 description 1811 "This augment is valid only for IPv6 unicast."; 1812 } 1813 description 1814 "This leaf augments an IPv6 unicast route."; 1815 leaf destination-prefix { 1816 type inet:ipv6-prefix; 1817 description 1818 "IPv6 destination prefix."; 1819 } 1820 } 1822 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 1823 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 1824 + "rt:simple-next-hop" { 1825 when "../../../rt:address-family = 'v6ur:ipv6-unicast'" { 1826 description 1827 "This augment is valid only for IPv6 unicast."; 1828 } 1829 description 1830 "This leaf augments the 'simple-next-hop' case of IPv6 unicast 1831 routes."; 1832 leaf next-hop-address { 1833 type inet:ipv6-address; 1834 description 1835 "IPv6 address of the next-hop."; 1836 } 1837 } 1839 /* Configuration data */ 1841 augment "/if:interfaces/if:interface/ip:ipv6" { 1842 description 1843 "Augment interface configuration with IPv6-specific parameters 1844 of router interfaces."; 1845 container ipv6-router-advertisements { 1846 description 1847 "Configuration of IPv6 Router Advertisements."; 1848 leaf send-advertisements { 1849 type boolean; 1850 default "false"; 1851 description 1852 "A flag indicating whether or not the router sends periodic 1853 Router Advertisements and responds to Router 1854 Solicitations."; 1855 reference 1856 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1857 AdvSendAdvertisements."; 1858 } 1859 leaf max-rtr-adv-interval { 1860 type uint16 { 1861 range "4..1800"; 1863 } 1864 units "seconds"; 1865 default "600"; 1866 description 1867 "The maximum time allowed between sending unsolicited 1868 multicast Router Advertisements from the interface."; 1869 reference 1870 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1871 MaxRtrAdvInterval."; 1872 } 1873 leaf min-rtr-adv-interval { 1874 type uint16 { 1875 range "3..1350"; 1876 } 1877 units "seconds"; 1878 must ". <= 0.75 * ../max-rtr-adv-interval" { 1879 description 1880 "The value MUST NOT be greater than 75 % of 1881 'max-rtr-adv-interval'."; 1882 } 1883 description 1884 "The minimum time allowed between sending unsolicited 1885 multicast Router Advertisements from the interface. 1887 The default value to be used operationally if this leaf is 1888 not configured is determined as follows: 1890 - if max-rtr-adv-interval >= 9 seconds, the default value 1891 is 0.33 * max-rtr-adv-interval; 1893 - otherwise it is 0.75 * max-rtr-adv-interval."; 1894 reference 1895 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1896 MinRtrAdvInterval."; 1897 } 1898 leaf managed-flag { 1899 type boolean; 1900 default "false"; 1901 description 1902 "The value to be placed in the 'Managed address 1903 configuration' flag field in the Router Advertisement."; 1904 reference 1905 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1906 AdvManagedFlag."; 1907 } 1908 leaf other-config-flag { 1909 type boolean; 1910 default "false"; 1911 description 1912 "The value to be placed in the 'Other configuration' flag 1913 field in the Router Advertisement."; 1914 reference 1915 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1916 AdvOtherConfigFlag."; 1917 } 1918 leaf link-mtu { 1919 type uint32; 1920 default "0"; 1921 description 1922 "The value to be placed in MTU options sent by the router. 1923 A value of zero indicates that no MTU options are sent."; 1924 reference 1925 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1926 AdvLinkMTU."; 1927 } 1928 leaf reachable-time { 1929 type uint32 { 1930 range "0..3600000"; 1931 } 1932 units "milliseconds"; 1933 default "0"; 1934 description 1935 "The value to be placed in the Reachable Time field in the 1936 Router Advertisement messages sent by the router. A value 1937 of zero means unspecified (by this router)."; 1938 reference 1939 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1940 AdvReachableTime."; 1941 } 1942 leaf retrans-timer { 1943 type uint32; 1944 units "milliseconds"; 1945 default "0"; 1946 description 1947 "The value to be placed in the Retrans Timer field in the 1948 Router Advertisement messages sent by the router. A value 1949 of zero means unspecified (by this router)."; 1950 reference 1951 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1952 AdvRetransTimer."; 1953 } 1954 leaf cur-hop-limit { 1955 type uint8; 1956 description 1957 "The value to be placed in the Cur Hop Limit field in the 1958 Router Advertisement messages sent by the router. A value 1959 of zero means unspecified (by this router). 1961 If this parameter is not configured, the device SHOULD use 1962 the value specified in IANA Assigned Numbers that was in 1963 effect at the time of implementation."; 1964 reference 1965 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1966 AdvCurHopLimit. 1968 IANA: IP Parameters, 1969 http://www.iana.org/assignments/ip-parameters"; 1970 } 1971 leaf default-lifetime { 1972 type uint16 { 1973 range "0..9000"; 1974 } 1975 units "seconds"; 1976 description 1977 "The value to be placed in the Router Lifetime field of 1978 Router Advertisements sent from the interface, in seconds. 1979 It MUST be either zero or between max-rtr-adv-interval and 1980 9000 seconds. A value of zero indicates that the router is 1981 not to be used as a default router. These limits may be 1982 overridden by specific documents that describe how IPv6 1983 operates over different link layers. 1985 If this parameter is not configured, the device SHOULD use 1986 a value of 3 * max-rtr-adv-interval."; 1987 reference 1988 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1989 AdvDefaultLifeTime."; 1990 } 1991 container prefix-list { 1992 description 1993 "Configuration of prefixes to be placed in Prefix 1994 Information options in Router Advertisement messages sent 1995 from the interface. 1997 Prefixes that are advertised by default but do not have 1998 their entries in the child 'prefix' list are advertised 1999 with the default values of all parameters. 2001 The link-local prefix SHOULD NOT be included in the list 2002 of advertised prefixes."; 2003 reference 2004 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2005 AdvPrefixList."; 2006 list prefix { 2007 key "prefix-spec"; 2008 description 2009 "Configuration of an advertised prefix entry."; 2010 leaf prefix-spec { 2011 type inet:ipv6-prefix; 2012 description 2013 "IPv6 address prefix."; 2014 } 2015 choice control-adv-prefixes { 2016 default "advertise"; 2017 description 2018 "The prefix either may be explicitly removed from the 2019 set of advertised prefixes, or parameters with which 2020 it is advertised may be specified (default case)."; 2021 leaf no-advertise { 2022 type empty; 2023 description 2024 "The prefix will not be advertised. 2026 This can be used for removing the prefix from the 2027 default set of advertised prefixes."; 2028 } 2029 case advertise { 2030 leaf valid-lifetime { 2031 type uint32; 2032 units "seconds"; 2033 default "2592000"; 2034 description 2035 "The value to be placed in the Valid Lifetime in 2036 the Prefix Information option. The designated 2037 value of all 1's (0xffffffff) represents 2038 infinity."; 2039 reference 2040 "RFC 4861: Neighbor Discovery for IP version 6 2041 (IPv6) - AdvValidLifetime."; 2042 } 2043 leaf on-link-flag { 2044 type boolean; 2045 default "true"; 2046 description 2047 "The value to be placed in the on-link flag 2048 ('L-bit') field in the Prefix Information 2049 option."; 2050 reference 2051 "RFC 4861: Neighbor Discovery for IP version 6 2052 (IPv6) - AdvOnLinkFlag."; 2053 } 2054 leaf preferred-lifetime { 2055 type uint32; 2056 units "seconds"; 2057 must ". <= ../valid-lifetime" { 2058 description 2059 "This value MUST NOT be greater than 2060 valid-lifetime."; 2061 } 2062 default "604800"; 2063 description 2064 "The value to be placed in the Preferred Lifetime 2065 in the Prefix Information option. The designated 2066 value of all 1's (0xffffffff) represents 2067 infinity."; 2068 reference 2069 "RFC 4861: Neighbor Discovery for IP version 6 2070 (IPv6) - AdvPreferredLifetime."; 2071 } 2072 leaf autonomous-flag { 2073 type boolean; 2074 default "true"; 2075 description 2076 "The value to be placed in the Autonomous Flag 2077 field in the Prefix Information option."; 2078 reference 2079 "RFC 4861: Neighbor Discovery for IP version 6 2080 (IPv6) - AdvAutonomousFlag."; 2081 } 2082 } 2083 } 2084 } 2085 } 2086 } 2087 } 2089 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2090 + "rt:routing-protocol/rt:static-routes" { 2091 description 2092 "This augment defines the configuration of the 'static' 2093 pseudo-protocol with data specific to IPv6 unicast."; 2094 container ipv6 { 2095 description 2096 "Configuration of a 'static' pseudo-protocol instance 2097 consists of a list of routes."; 2098 list route { 2099 key "destination-prefix"; 2100 ordered-by "user"; 2101 description 2102 "A user-ordered list of static routes."; 2104 leaf destination-prefix { 2105 type inet:ipv6-prefix; 2106 mandatory "true"; 2107 description 2108 "IPv6 destination prefix."; 2109 } 2110 leaf description { 2111 type string; 2112 description 2113 "Textual description of the route."; 2114 } 2115 container next-hop { 2116 description 2117 "Configuration of next-hop."; 2118 uses rt:next-hop-content { 2119 augment "next-hop-options" { 2120 description 2121 "Add next-hop address case."; 2122 leaf next-hop-address { 2123 type inet:ipv6-address; 2124 description 2125 "IPv6 address of the next-hop."; 2126 } 2127 } 2128 } 2129 } 2130 } 2131 } 2132 } 2134 /* RPC operations */ 2136 augment "/rt:fib-route/rt:input/rt:destination-address" { 2137 when "rt:address-family='v6ur:ipv6-unicast'" { 2138 description 2139 "This augment is valid only for IPv6 unicast."; 2140 } 2141 description 2142 "This leaf augments the 'rt:destination-address' parameter of 2143 the 'rt:fib-route' operation."; 2144 leaf address { 2145 type inet:ipv6-address; 2146 description 2147 "IPv6 destination address."; 2148 } 2149 } 2151 augment "/rt:fib-route/rt:output/rt:route" { 2152 when "rt:address-family='v6ur:ipv6-unicast'" { 2153 description 2154 "This augment is valid only for IPv6 unicast."; 2155 } 2156 description 2157 "This leaf augments the reply to the 'rt:fib-route' 2158 operation."; 2159 leaf destination-prefix { 2160 type inet:ipv6-prefix; 2161 description 2162 "IPv6 destination prefix."; 2163 } 2164 } 2166 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 2167 + "rt:next-hop-options/rt:simple-next-hop" { 2168 when "../rt:address-family='v6ur:ipv6-unicast'" { 2169 description 2170 "This augment is valid only for IPv6 unicast."; 2171 } 2172 description 2173 "This leaf augments the 'simple-next-hop' case in the reply to 2174 the 'rt:fib-route' operation."; 2175 leaf next-hop-address { 2176 type inet:ipv6-address; 2177 description 2178 "IPv6 address of the next-hop."; 2179 } 2180 } 2181 } 2183 2185 10. IANA Considerations 2187 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2188 actual RFC number (and remove this note). 2190 This document registers the following namespace URIs in the IETF XML 2191 registry [RFC3688]: 2193 -------------------------------------------------------------------- 2194 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2196 Registrant Contact: The IESG. 2198 XML: N/A, the requested URI is an XML namespace. 2199 -------------------------------------------------------------------- 2201 -------------------------------------------------------------------- 2202 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2204 Registrant Contact: The IESG. 2206 XML: N/A, the requested URI is an XML namespace. 2207 -------------------------------------------------------------------- 2209 -------------------------------------------------------------------- 2210 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2212 Registrant Contact: The IESG. 2214 XML: N/A, the requested URI is an XML namespace. 2215 -------------------------------------------------------------------- 2217 This document registers the following YANG modules in the YANG Module 2218 Names registry [RFC6020]: 2220 -------------------------------------------------------------------- 2221 name: ietf-routing 2222 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2223 prefix: rt 2224 reference: RFC XXXX 2225 -------------------------------------------------------------------- 2227 -------------------------------------------------------------------- 2228 name: ietf-ipv4-unicast-routing 2229 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2230 prefix: v4ur 2231 reference: RFC XXXX 2232 -------------------------------------------------------------------- 2234 -------------------------------------------------------------------- 2235 name: ietf-ipv6-unicast-routing 2236 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2237 prefix: v6ur 2238 reference: RFC XXXX 2239 -------------------------------------------------------------------- 2241 11. Security Considerations 2243 Configuration and state data conforming to the core routing data 2244 model (defined in this document) are designed to be accessed via the 2245 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2246 transport layer and the mandatory-to-implement secure transport is 2247 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 2248 the means to restrict access for particular NETCONF users to a pre- 2249 configured subset of all available NETCONF protocol operations and 2250 content. 2252 A number of data nodes defined in the YANG modules belonging to the 2253 configuration part of the core routing data model are 2254 writable/creatable/deletable (i.e., "config true" in YANG terms, 2255 which is the default). These data nodes may be considered sensitive 2256 or vulnerable in some network environments. Write operations to 2257 these data nodes, such as "edit-config", can have negative effects on 2258 the network if the protocol operations are not properly protected. 2260 The vulnerable "config true" subtrees and data nodes are the 2261 following: 2263 /routing/routing-instance/interfaces/interface: This list assigns a 2264 network layer interface to a routing instance and may also specify 2265 interface parameters related to routing. 2267 /routing/routing-instance/routing-protocols/routing-protocol: This 2268 list specifies the routing protocols configured on a device. 2270 /routing/routing-instance/ribs/rib: This list specifies the RIBs 2271 configured for the device. 2273 Unauthorized access to any of these lists can adversely affect the 2274 routing subsystem of both the local device and the network. This may 2275 lead to network malfunctions, delivery of packets to inappropriate 2276 destinations and other problems. 2278 12. Acknowledgments 2280 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 2281 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 2282 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 2283 Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, 2284 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- 2285 Kit Yeung and Jeffrey Zhang for their helpful comments and 2286 suggestions. 2288 13. References 2290 13.1. Normative References 2292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2293 Requirement Levels", BCP 14, RFC 2119, March 1997. 2295 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2296 January 2004. 2298 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2299 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2300 September 2007. 2302 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2303 Network Configuration Protocol (NETCONF)", RFC 6020, 2304 October 2010. 2306 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2307 Bierman, "Network Configuration Protocol (NETCONF)", RFC 2308 6241, June 2011. 2310 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 2311 July 2013. 2313 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2314 Management", RFC 7223, May 2014. 2316 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 2317 7277, June 2014. 2319 13.2. Informative References 2321 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2322 Networks (VPNs)", RFC 4364, February 2006. 2324 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2325 Data Model Documents", RFC 6087, January 2011. 2327 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2328 Shell (SSH)", RFC 6242, June 2011. 2330 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2331 Protocol (NETCONF) Access Control Model", RFC 6536, March 2332 2012. 2334 Appendix A. The Complete Data Trees 2336 This appendix presents the complete configuration and state data 2337 trees of the core routing data model. See Section 2.2 for an 2338 explanation of the symbols used. Data type of every leaf node is 2339 shown near the right end of the corresponding line. 2341 A.1. Configuration Data 2342 +--rw routing 2343 +--rw routing-instance* [name] 2344 +--rw name string 2345 +--rw type? identityref 2346 +--rw enabled? boolean 2347 +--rw router-id? yang:dotted-quad 2348 +--rw description? string 2349 +--rw interfaces 2350 | +--rw interface* if:interface-ref 2351 +--rw routing-protocols 2352 | +--rw routing-protocol* [type name] 2353 | +--rw type identityref 2354 | +--rw name string 2355 | +--rw description? string 2356 | +--rw enabled? boolean 2357 | +--rw route-preference? route-preference 2358 | +--rw static-routes 2359 | +--rw v6ur:ipv6 2360 | | +--rw v6ur:route* [destination-prefix] 2361 | | +--rw v6ur:destination-prefix inet:ipv6-prefix 2362 | | +--rw v6ur:description? string 2363 | | +--rw v6ur:next-hop 2364 | | +--rw (next-hop-options) 2365 | | +--:(simple-next-hop) 2366 | | | +--rw v6ur:outgoing-interface? 2367 | | +--:(special-next-hop) 2368 | | | +--rw v6ur:special-next-hop? 2369 | | +--:(next-hop-address) 2370 | | +--rw v6ur:next-hop-address? 2371 | +--rw v4ur:ipv4 2372 | +--rw v4ur:route* [destination-prefix] 2373 | +--rw v4ur:destination-prefix inet:ipv4-prefix 2374 | +--rw v4ur:description? string 2375 | +--rw v4ur:next-hop 2376 | +--rw (next-hop-options) 2377 | +--:(simple-next-hop) 2378 | | +--rw v4ur:outgoing-interface? 2379 | +--:(special-next-hop) 2380 | | +--rw v4ur:special-next-hop? 2381 | +--:(next-hop-address) 2382 | +--rw v4ur:next-hop-address? 2383 +--rw ribs 2384 +--rw rib* [name] 2385 +--rw name string 2386 +--rw address-family? identityref 2387 +--rw description? string 2389 A.2. State Data 2391 +--ro routing-state 2392 +--ro routing-instance* [name] 2393 +--ro name string 2394 +--ro type? identityref 2395 +--ro router-id? yang:dotted-quad 2396 +--ro interfaces 2397 | +--ro interface* if:interface-state-ref 2398 +--ro routing-protocols 2399 | +--ro routing-protocol* [type name] 2400 | +--ro type identityref 2401 | +--ro name string 2402 | +--ro route-preference route-preference 2403 +--ro ribs 2404 +--ro rib* [name] 2405 +--ro name string 2406 +--ro address-family identityref 2407 +--ro default-rib? boolean {multiple-ribs}? 2408 +--ro routes 2409 +--ro route* 2410 +--ro route-preference? route-preference 2411 +--ro next-hop 2412 | +--ro (next-hop-options) 2413 | +--:(simple-next-hop) 2414 | | +--ro outgoing-interface? 2415 | | +--ro v6ur:next-hop-address? 2416 | | +--ro v4ur:next-hop-address? 2417 | +--:(special-next-hop) 2418 | +--ro special-next-hop? enumeration 2419 +--ro source-protocol identityref 2420 +--ro active? empty 2421 +--ro last-updated? yang:date-and-time 2422 +--ro v6ur:destination-prefix? inet:ipv6-prefix 2423 +--ro v4ur:destination-prefix? inet:ipv4-prefix 2425 Appendix B. Minimum Implementation 2427 Some parts and options of the core routing model, such as user- 2428 defined routing tables, are intended only for advanced routers. This 2429 appendix gives basic non-normative guidelines for implementing a bare 2430 minimum of available functions. Such an implementation may be used 2431 for hosts or very simple routers. 2433 A minimum implementation will provide a single system-controlled 2434 routing instance, and will not allow clients to create any user- 2435 controlled instances. 2437 Typically, the feature "multiple-ribs" will not be supported. This 2438 means that a single system-controlled RIB is available for each 2439 supported address family - IPv4, IPv6 or both. These RIBs must be 2440 the default RIBs. No user-controlled RIBs are allowed. 2442 In addition to the mandatory instance of the "direct" pseudo- 2443 protocol, a minimum implementation should support configuring 2444 instance(s) of the "static" pseudo-protocol. 2446 Platforms with severely constrained resources may use deviations for 2447 restricting the data model, e.g., limiting the number of "static" 2448 routing protocol instances. 2450 Appendix C. Example: Adding a New Routing Protocol 2452 This appendix demonstrates how the core routing data model can be 2453 extended to support a new routing protocol. The YANG module 2454 "example-rip" shown below is intended as an illustration rather than 2455 a real definition of a data model for the RIP routing protocol. For 2456 the sake of brevity, this module does not obey all the guidelines 2457 specified in [RFC6087]. See also Section 5.4.2. 2459 module example-rip { 2461 namespace "http://example.com/rip"; 2463 prefix "rip"; 2465 import ietf-routing { 2466 prefix "rt"; 2467 } 2469 identity rip { 2470 base rt:routing-protocol; 2471 description 2472 "Identity for the RIP routing protocol."; 2473 } 2475 typedef rip-metric { 2476 type uint8 { 2477 range "0..16"; 2478 } 2479 } 2481 grouping route-content { 2482 description 2483 "This grouping defines RIP-specific route attributes."; 2484 leaf metric { 2485 type rip-metric; 2486 } 2487 leaf tag { 2488 type uint16; 2489 default "0"; 2490 description 2491 "This leaf may be used to carry additional info, e.g. AS 2492 number."; 2493 } 2494 } 2496 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 2497 + "rt:routes/rt:route" { 2498 when "rt:source-protocol = 'rip:rip'" { 2499 description 2500 "This augment is only valid for a routes whose source 2501 protocol is RIP."; 2502 } 2503 description 2504 "RIP-specific route attributes."; 2505 uses route-content; 2506 } 2508 augment "/rt:fib-route/rt:output/rt:route" { 2509 description 2510 "RIP-specific route attributes in the output of 'active-route' 2511 RPC."; 2512 uses route-content; 2513 } 2515 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2516 + "rt:routing-protocol" { 2517 when "rt:type = 'rip:rip'" { 2518 description 2519 "This augment is only valid for a routing protocol instance 2520 of type 'rip'."; 2521 } 2522 container rip { 2523 description 2524 "RIP instance configuration."; 2525 container interfaces { 2526 description 2527 "Per-interface RIP configuration."; 2528 list interface { 2529 key "name"; 2530 description 2531 "RIP is enabled on interfaces that have an entry in this 2532 list, unless 'enabled' is set to 'false' for that 2533 entry."; 2534 leaf name { 2535 type leafref { 2536 path "../../../../../../rt:interfaces/rt:interface"; 2537 } 2538 } 2539 leaf enabled { 2540 type boolean; 2541 default "true"; 2542 } 2543 leaf metric { 2544 type rip-metric; 2545 default "1"; 2546 } 2547 } 2548 } 2549 leaf update-interval { 2550 type uint8 { 2551 range "10..60"; 2552 } 2553 units "seconds"; 2554 default "30"; 2555 description 2556 "Time interval between periodic updates."; 2557 } 2558 } 2559 } 2560 } 2562 Appendix D. Example: NETCONF Reply 2564 This section contains a sample reply to the NETCONF message, 2565 which could be sent by a server supporting (i.e., advertising them in 2566 the NETCONF message) the following YANG modules: 2568 o ietf-interfaces [RFC7223], 2570 o ietf-ip [RFC7277], 2572 o ietf-routing (Section 7), 2574 o ietf-ipv4-unicast-routing (Section 8), 2576 o ietf-ipv6-unicast-routing (Section 9). 2578 We assume a simple network set-up as shown in Figure 3: router "A" 2579 uses static default routes with the "ISP" router as the next-hop. 2581 IPv6 router advertisements are configured only on the "eth1" 2582 interface and disabled on the upstream "eth0" interface. 2584 +-----------------+ 2585 | | 2586 | Router ISP | 2587 | | 2588 +--------+--------+ 2589 |2001:db8:0:1::2 2590 |192.0.2.2 2591 | 2592 | 2593 |2001:db8:0:1::1 2594 eth0|192.0.2.1 2595 +--------+--------+ 2596 | | 2597 | Router A | 2598 | | 2599 +--------+--------+ 2600 eth1|198.51.100.1 2601 |2001:db8:0:2::1 2602 | 2604 Figure 3: Example network configuration 2606 A reply to the NETCONF message sent by router "A" would then be 2607 as follows: 2609 2610 2619 2620 2621 2622 eth0 2623 ianaift:ethernetCsmacd 2624 2625 Uplink to ISP. 2626 2627 2628 2629 192.0.2.1 2630 24 2631 2632 true 2633 2634 2635 2636 2001:0db8:0:1::1 2637 64 2638 2639 true 2640 2641 false 2642 2643 2644 2645 2646 eth1 2647 ianaift:ethernetCsmacd 2648 2649 Interface to the internal network. 2650 2651 2652 2653 198.51.100.1 2654 24 2655 2656 true 2657 2658 2659 2660 2001:0db8:0:2::1 2661 64 2662 2663 true 2664 2665 false 2666 2667 2668 2669 2670 2671 2672 eth0 2673 ianaift:ethernetCsmacd 2674 00:0C:42:E5:B1:E9 2675 up 2676 rtr0 2677 2678 2679 2014-10-24T17:11:27+00:58 2680 2681 2682 2683 true 2684 1500 2685 2686 192.0.2.1 2687 24 2688 2689 2690 2691 true 2692 1500 2693 2694 2001:0db8:0:1::1 2695 64 2696 2697 2698 true 2699 2700 2701 2001:db8:0:2::/64 2702 2703 2704 2705 2706 2707 2708 eth1 2709 ianaift:ethernetCsmacd 2710 00:0C:42:E5:B1:EA 2711 up 2712 rtr0 2713 2714 2715 2014-10-24T17:11:27+00:59 2716 2717 2718 2719 true 2720 1500 2721 2722 198.51.100.1 2723 24 2724 2726 2727 2728 true 2729 1500 2730 2731 2001:0db8:0:2::1 2732 64 2733 2734 2735 true 2736 2737 2738 2001:db8:0:2::/64 2739 2740 2741 2742 2743 2744 2745 2746 2747 rtr0 2748 Router A 2749 192.0.2.1 2750 2751 eth0 2752 eth1 2753 2754 2755 2756 rt:static 2757 st0 2758 2759 Static routing is used for the internal network. 2760 2761 2762 2763 2764 2765 0.0.0.0/0 2766 2767 2768 192.0.2.2 2769 2770 2771 2772 2773 2774 ::/0 2775 2776 2777 2001:db8:0:1::2 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 rtr0 2790 2791 eth0 2792 eth1 2793 2794 2795 2796 rt:static 2797 st0 2798 5 2799 2800 2801 2802 2803 ipv4-master 2804 v4ur:ipv4-unicast 2805 true 2806 2807 2808 2809 192.0.2.1/24 2810 2811 2812 eth0 2813 2814 0 2815 rt:direct 2816 2014-10-24T17:11:27+01:00 2817 2818 2819 2820 198.51.100.0/24 2821 2822 2823 eth1 2824 2825 rt:direct 2826 0 2827 2014-10-24T17:11:27+01:00 2828 2829 2830 0.0.0.0/0 2831 rt:static 2832 5 2833 2834 192.0.2.2 2835 2836 2014-10-24T18:02:45+01:00 2837 2838 2839 2840 2841 ipv6-master 2842 v6ur:ipv6-unicast 2843 true 2844 2845 2846 2847 2001:db8:0:1::/64 2848 2849 2850 eth0 2851 2852 rt:direct 2853 0 2854 2014-10-24T17:11:27+01:00 2855 2856 2857 2858 2001:db8:0:2::/64 2859 2860 2861 eth1 2862 2863 rt:direct 2864 0 2865 2014-10-24T17:11:27+01:00 2866 2867 2868 ::/0 2869 2870 2871 2001:db8:0:1::2 2872 2873 2874 rt:static 2875 5 2876 2014-10-24T18:02:45+01:00 2877 2878 2879 2880 2881 2882 2883 2884 2886 Appendix E. Change Log 2888 RFC Editor: Remove this section upon publication as an RFC. 2890 E.1. Changes Between Versions -17 and -18 2892 o The container "ribs" was moved under "routing-instance" (in both 2893 "routing" and "routing-state"). 2895 o Typedefs "rib-ref" and "rib-state-ref" were removed. 2897 o Removed "recipient-ribs" (both state and configuration). 2899 o Removed "connected-ribs" from "routing-protocol" (both state and 2900 configuration). 2902 o Configuration and state data for IPv6 RA were moved under 2903 "if:interface" and "if:interface-state". 2905 o Assignment of interfaces to routing instances now use leaf-list 2906 rather than list (both config and state). The opposite reference 2907 from "if:interface" to "rt:routing-instance" was changed to a 2908 single leaf (an interface cannot belong to multiple routing 2909 instances). 2911 o Specification of a default RIB is now a simple flag under "rib" 2912 (both config and state). 2914 o Default RIBs are marked by a flag in state data. 2916 E.2. Changes Between Versions -16 and -17 2918 o Added Acee as a co-author. 2920 o Removed all traces of route filters. 2922 o Removed numeric IDs of list entries in state data. 2924 o Removed all next-hop cases except "simple-next-hop" and "special- 2925 next-hop". 2927 o Removed feature "multipath-routes". 2929 o Augmented "ietf-interfaces" module with a leaf-list of leafrefs 2930 pointing form state data of an interface entry to the routing 2931 instance(s) to which the interface is assigned. 2933 E.3. Changes Between Versions -15 and -16 2935 o Added 'type' as the second key component of 'routing-protocol', 2936 both in configuration and state data. 2938 o The restriction of no more than one connected RIB per address 2939 family was removed. 2941 o Removed the 'id' key of routes in RIBs. This list has no keys 2942 anymore. 2944 o Remove the 'id' key from static routes and make 'destination- 2945 prefix' the only key. 2947 o Added 'route-preference' as a new attribute of routes in RIB. 2949 o Added 'active' as a new attribute of routes in RIBs. 2951 o Renamed RPC operation 'active-route' to 'fib-route'. 2953 o Added 'route-preference' as a new parameter of routing protocol 2954 instances, both in configuration and state data. 2956 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 2957 routing-instance'. 2959 o Added next-hop lists to state data. 2961 o Added two cases for specifying next-hops indirectly - via a new 2962 RIB or a recursive list of next-hops. 2964 o Reorganized next-hop in static routes. 2966 o Removed all 'if-feature' statements from state data. 2968 E.4. Changes Between Versions -14 and -15 2970 o Removed all defaults from state data. 2972 o Removed default from 'cur-hop-limit' in config. 2974 E.5. Changes Between Versions -13 and -14 2976 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 2977 feature. 2979 o Removed default value of 'cur-hop-limit' in state data. 2981 o Moved parts of descriptions and all references on IPv6 RA 2982 parameters from state data to configuration. 2984 o Added reference to RFC 6536 in the Security section. 2986 E.6. Changes Between Versions -12 and -13 2988 o Wrote appendix about minimum implementation. 2990 o Remove "when" statement for IPv6 router interface state data - it 2991 was dependent on a config value that may not be present. 2993 o Extra container for the next-hop list. 2995 o Names rather than numeric ids are used for referring to list 2996 entries in state data. 2998 o Numeric ids are always declared as mandatory and unique. Their 2999 description states that they are ephemeral. 3001 o Descriptions of "name" keys in state data lists are required to be 3002 persistent. 3004 o 3006 o Removed "if-feature multiple-ribs;" from connected-ribs. 3008 o "rib-name" instead of "name" is used as the name of leafref nodes. 3010 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3011 in node names and text. 3013 E.7. Changes Between Versions -11 and -12 3015 o Removed feature "advanced-router" and introduced two features 3016 instead: "multiple-ribs" and "multipath-routes". 3018 o Unified the keys of config and state versions of "routing- 3019 instance" and "rib" lists. 3021 o Numerical identifiers of state list entries are not keys anymore, 3022 but they are constrained using the "unique" statement. 3024 o Updated acknowledgements. 3026 E.8. Changes Between Versions -10 and -11 3028 o Migrated address families from IANA enumerations to identities. 3030 o Terminology and node names aligned with the I2RS RIB model: router 3031 -> routing instance, routing table -> RIB. 3033 o Introduced uint64 keys for state lists: routing-instance, rib, 3034 route, nexthop. 3036 o Described the relationship between system-controlled and user- 3037 controlled list entries. 3039 o Feature "user-defined-routing-tables" changed into "advanced- 3040 router". 3042 o Made nexthop into a choice in order to allow for nexthop-list 3043 (I2RS requirement). 3045 o Added nexthop-list with entries having priorities (backup) and 3046 weights (load balancing). 3048 o Updated bibliography references. 3050 E.9. Changes Between Versions -09 and -10 3052 o Added subtree for state data ("/routing-state"). 3054 o Terms "system-controlled entry" and "user-controlled entry" 3055 defined and used. 3057 o New feature "user-defined-routing-tables". Nodes that are useful 3058 only with user-defined routing tables are now conditional. 3060 o Added grouping "router-id". 3062 o In routing tables, "source-protocol" attribute of routes now 3063 reports only protocol type, and its datatype is "identityref". 3065 o Renamed "main-routing-table" to "default-routing-table". 3067 E.10. Changes Between Versions -08 and -09 3069 o Fixed "must" expresion for "connected-routing-table". 3071 o Simplified "must" expression for "main-routing-table". 3073 o Moved per-interface configuration of a new routing protocol under 3074 'routing-protocol'. This also affects the 'example-rip' module. 3076 E.11. Changes Between Versions -07 and -08 3078 o Changed reference from RFC6021 to RFC6021bis. 3080 E.12. Changes Between Versions -06 and -07 3082 o The contents of in Appendix D was updated: "eth[01]" 3083 is used as the value of "location", and "forwarding" is on for 3084 both interfaces and both IPv4 and IPv6. 3086 o The "must" expression for "main-routing-table" was modified to 3087 avoid redundant error messages reporting address family mismatch 3088 when "name" points to a non-existent routing table. 3090 o The default behavior for IPv6 RA prefix advertisements was 3091 clarified. 3093 o Changed type of "rt:router-id" to "ip:dotted-quad". 3095 o Type of "rt:router-id" changed to "yang:dotted-quad". 3097 o Fixed missing prefixes in XPath expressions. 3099 E.13. Changes Between Versions -05 and -06 3101 o Document title changed: "Configuration" was replaced by 3102 "Management". 3104 o New typedefs "routing-table-ref" and "route-filter-ref". 3106 o Double slashes "//" were removed from XPath expressions and 3107 replaced with the single "/". 3109 o Removed uniqueness requirement for "router-id". 3111 o Complete data tree is now in Appendix A. 3113 o Changed type of "source-protocol" from "leafref" to "string". 3115 o Clarified the relationship between routing protocol instances and 3116 connected routing tables. 3118 o Added a must constraint saying that a routing table connected to 3119 the direct pseudo-protocol must not be a main routing table. 3121 E.14. Changes Between Versions -04 and -05 3123 o Routing tables are now global, i.e., "routing-tables" is a child 3124 of "routing" rather than "router". 3126 o "must" statement for "static-routes" changed to "when". 3128 o Added "main-routing-tables" containing references to main routing 3129 tables for each address family. 3131 o Removed the defaults for "address-family" and "safi" and made them 3132 mandatory. 3134 o Removed the default for route-filter/type and made this leaf 3135 mandatory. 3137 o If there is no active route for a given destination, the "active- 3138 route" RPC returns no output. 3140 o Added "enabled" switch under "routing-protocol". 3142 o Added "router-type" identity and "type" leaf under "router". 3144 o Route attribute "age" changed to "last-updated", its type is 3145 "yang:date-and-time". 3147 o The "direct" pseudo-protocol is always connected to main routing 3148 tables. 3150 o Entries in the list of connected routing tables renamed from 3151 "routing-table" to "connected-routing-table". 3153 o Added "must" constraint saying that a routing table must not be 3154 its own recipient. 3156 E.15. Changes Between Versions -03 and -04 3158 o Changed "error-tag" for both RPC operations from "missing element" 3159 to "data-missing". 3161 o Removed the decrementing behavior for advertised IPv6 prefix 3162 parameters "valid-lifetime" and "preferred-lifetime". 3164 o Changed the key of the static route lists from "seqno" to "id" 3165 because the routes needn't be sorted. 3167 o Added 'must' constraint saying that "preferred-lifetime" must not 3168 be greater than "valid-lifetime". 3170 E.16. Changes Between Versions -02 and -03 3172 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3174 o Removed forwarding table. 3176 o RPC "get-route" changed to "active-route". Its output is a list 3177 of routes (for multi-path routing). 3179 o New RPC "route-count". 3181 o For both RPCs, specification of negative responses was added. 3183 o Relaxed separation of router instances. 3185 o Assignment of interfaces to router instances needn't be disjoint. 3187 o Route filters are now global. 3189 o Added "allow-all-route-filter" for symmetry. 3191 o Added Section 6 about interactions with "ietf-interfaces" and 3192 "ietf-ip". 3194 o Added "router-id" leaf. 3196 o Specified the names for IPv4/IPv6 unicast main routing tables. 3198 o Route parameter "last-modified" changed to "age". 3200 o Added container "recipient-routing-tables". 3202 E.17. Changes Between Versions -01 and -02 3204 o Added module "ietf-ipv6-unicast-routing". 3206 o The example in Appendix D now uses IP addresses from blocks 3207 reserved for documentation. 3209 o Direct routes appear by default in the forwarding table. 3211 o Network layer interfaces must be assigned to a router instance. 3212 Additional interface configuration may be present. 3214 o The "when" statement is only used with "augment", "must" is used 3215 elsewhere. 3217 o Additional "must" statements were added. 3219 o The "route-content" grouping for IPv4 and IPv6 unicast now 3220 includes the material from the "ietf-routing" version via "uses 3221 rt:route-content". 3223 o Explanation of symbols in the tree representation of data model 3224 hierarchy. 3226 E.18. Changes Between Versions -00 and -01 3228 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3230 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3231 safi" module. 3233 o Names of some data nodes were changed, in particular "routing- 3234 process" is now "router". 3236 o The restriction of a single AFN/SAFI per router was lifted. 3238 o RPC operation "delete-route" was removed. 3240 o Illegal XPath references from "get-route" to the datastore were 3241 fixed. 3243 o Section "Security Considerations" was written. 3245 Authors' Addresses 3246 Ladislav Lhotka 3247 CZ.NIC 3249 Email: lhotka@nic.cz 3251 Acee Lindem 3252 Cisco Systems 3254 Email: acee@cisco.com