idnits 2.17.00 (12 Aug 2021) /tmp/idnits16460/draft-ietf-netmod-routing-cfg-21.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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2251 has weird spacing: '...-prefix ine...' == Line 2263 has weird spacing: '...-prefix ine...' == Line 2294 has weird spacing: '...ro type ide...' == Line 2295 has weird spacing: '...ro name str...' == Line 2299 has weird spacing: '...-family ide...' -- The document date (March 17, 2016) is 2256 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: 3 errors (**), 0 flaws (~~), 6 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: September 10, 2016 Cisco Systems 6 March 17, 2016 8 A YANG Data Model for Routing Management 9 draft-ietf-netmod-routing-cfg-21 11 Abstract 13 This document contains a specification of three YANG modules and one 14 submodule. Together they form the core routing data model which 15 serves as a framework for configuring and managing a routing 16 subsystem. It is expected that these modules will be augmented by 17 additional YANG modules defining data models for routing protocols, 18 route filters and other functions. The core routing data model 19 provides common building blocks for such extensions - routes, routing 20 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 September 10, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 4 58 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 5 59 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 61 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. The Design of the Core Routing Data Model . . . . . . . . . . 7 63 4.1. System-Controlled and User-Controlled List Entries . . . 8 64 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9 67 5.3. Routing Protocol . . . . . . . . . . . . . . . . . . . . 10 68 5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10 69 5.3.2. Defining New Routing Protocols . . . . . . . . . . . 11 70 5.4. RPC Operations . . . . . . . . . . . . . . . . . . . . . 12 71 5.5. Parameters of IPv6 Router Advertisements . . . . . . . . 12 72 6. Interactions with Other YANG Modules . . . . . . . . . . . . 13 73 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 13 74 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 75 7. Routing Management YANG Module . . . . . . . . . . . . . . . 14 76 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 25 77 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 30 78 9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 34 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 81 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 46 84 13.2. Informative References . . . . . . . . . . . . . . . . . 47 85 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 48 86 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 48 87 A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 50 88 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 50 89 Appendix C. Example: Adding a New Routing Protocol . . . . . . . 51 90 Appendix D. Example: NETCONF Reply . . . . . . . . . . . . 53 91 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 59 92 E.1. Changes Between Versions -20 and -21 . . . . . . . . . . 59 93 E.2. Changes Between Versions -19 and -20 . . . . . . . . . . 60 94 E.3. Changes Between Versions -18 and -19 . . . . . . . . . . 60 95 E.4. Changes Between Versions -17 and -18 . . . . . . . . . . 60 96 E.5. Changes Between Versions -16 and -17 . . . . . . . . . . 61 97 E.6. Changes Between Versions -15 and -16 . . . . . . . . . . 61 98 E.7. Changes Between Versions -14 and -15 . . . . . . . . . . 62 99 E.8. Changes Between Versions -13 and -14 . . . . . . . . . . 62 100 E.9. Changes Between Versions -12 and -13 . . . . . . . . . . 62 101 E.10. Changes Between Versions -11 and -12 . . . . . . . . . . 63 102 E.11. Changes Between Versions -10 and -11 . . . . . . . . . . 63 103 E.12. Changes Between Versions -09 and -10 . . . . . . . . . . 63 104 E.13. Changes Between Versions -08 and -09 . . . . . . . . . . 64 105 E.14. Changes Between Versions -07 and -08 . . . . . . . . . . 64 106 E.15. Changes Between Versions -06 and -07 . . . . . . . . . . 64 107 E.16. Changes Between Versions -05 and -06 . . . . . . . . . . 64 108 E.17. Changes Between Versions -04 and -05 . . . . . . . . . . 65 109 E.18. Changes Between Versions -03 and -04 . . . . . . . . . . 66 110 E.19. Changes Between Versions -02 and -03 . . . . . . . . . . 66 111 E.20. Changes Between Versions -01 and -02 . . . . . . . . . . 67 112 E.21. Changes Between Versions -00 and -01 . . . . . . . . . . 67 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 115 1. Introduction 117 This document contains a specification of the following YANG modules: 119 o Module "ietf-routing" provides generic components of a routing 120 data model. 122 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 123 module with additional data specific to IPv4 unicast. 125 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 126 module with additional data specific to IPv6 unicast. Its 127 submodule "ietf-ipv6-router-advertisements" also augments the 128 "ietf-interfaces" module [RFC7223] with IPv6 router configuration 129 variables required by [RFC4861]. 131 These modules together define the so-called core routing data model, 132 which is intended as a basis for future data model development 133 covering more sophisticated routing systems. While these three 134 modules can be directly used for simple IP devices with static 135 routing (see Appendix B), their main purpose is to provide essential 136 building blocks for more complicated data models involving multiple 137 routing protocols, multicast routing, additional address families, 138 and advanced functions such as route filtering or policy routing. To 139 this end, it is expected that the core routing data model will be 140 augmented by numerous modules developed by other IETF working groups. 142 2. Terminology and Notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 The following terms are defined in [RFC6241]: 150 o client, 152 o message, 154 o protocol operation, 156 o server. 158 The following terms are defined in [RFC6020]: 160 o augment, 162 o configuration data, 164 o container, 166 o container with presence, 168 o data model, 170 o data node, 172 o feature, 174 o leaf, 176 o list, 178 o mandatory node, 180 o module, 182 o schema tree, 184 o state data, 186 o RPC operation. 188 2.1. Glossary of New Terms 190 core routing data model: YANG data model comprising "ietf-routing", 191 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 192 modules. 194 direct route: a route to a directly connected network. 196 routing information base (RIB): An object containing a list of 197 routes together with other information. See Section 5.2 for 198 details. 200 system-controlled entry: An entry of a list in state data ("config 201 false") that is created by the system independently of what has 202 been explicitly configured. See Section 4.1 for details. 204 user-controlled entry: An entry of a list in state data ("config 205 false") that is created and deleted as a direct consequence of 206 certain configuration changes. See Section 4.1 for details. 208 2.2. Tree Diagrams 210 A simplified graphical representation of the complete data tree is 211 presented in Appendix A, and similar diagrams of its various subtrees 212 appear in the main text. 214 o Brackets "[" and "]" enclose list keys. 216 o Curly braces "{" and "}" contain names of optional features that 217 make the corresponding node conditional. 219 o Abbreviations before data node names: "rw" means configuration 220 (read-write), "ro" state data (read-only), "-x" RPC operations, 221 and "-n" notifications. 223 o Symbols after data node names: "?" means an optional node, "!" a 224 container with presence, and "*" denotes a "list" or "leaf-list". 226 o Parentheses enclose choice and case nodes, and case nodes are also 227 marked with a colon (":"). 229 o Ellipsis ("...") stands for contents of subtrees that are not 230 shown. 232 2.3. Prefixes in Data Node Names 234 In this document, names of data nodes, RPC operations and other data 235 model objects are often used without a prefix, as long as it is clear 236 from the context in which YANG module each name is defined. 237 Otherwise, names are prefixed using the standard prefix associated 238 with the corresponding YANG module, as shown in Table 1. 240 +--------+---------------------------+-----------+ 241 | Prefix | YANG module | Reference | 242 +--------+---------------------------+-----------+ 243 | if | ietf-interfaces | [RFC7223] | 244 | ip | ietf-ip | [RFC7277] | 245 | rt | ietf-routing | Section 7 | 246 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 247 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 248 | yang | ietf-yang-types | [RFC6991] | 249 | inet | ietf-inet-types | [RFC6991] | 250 +--------+---------------------------+-----------+ 252 Table 1: Prefixes and corresponding YANG modules 254 3. Objectives 256 The initial design of the core routing data model was driven by the 257 following objectives: 259 o The data model should be suitable for the common address families, 260 in particular IPv4 and IPv6, and for unicast and multicast 261 routing, as well as Multiprotocol Label Switching (MPLS). 263 o A simple IP routing system, such as one that uses only static 264 routing, should be configurable in a simple way, ideally without 265 any need to develop additional YANG modules. 267 o On the other hand, the core routing framework must allow for 268 complicated implementations involving multiple routing information 269 bases (RIB) and multiple routing protocols, as well as controlled 270 redistributions of routing information. 272 o Device vendors will want to map the data models built on this 273 generic framework to their proprietary data models and 274 configuration interfaces. Therefore, the framework should be 275 flexible enough to facilitate such a mapping and accommodate data 276 models with different logic. 278 4. The Design of the Core Routing Data Model 280 The core routing data model consists of three YANG modules and one 281 submodule. The first module, "ietf-routing", defines the generic 282 components of a routing system. The other two modules, "ietf-ipv4- 283 unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- 284 routing" module with additional data nodes that are needed for IPv4 285 and IPv6 unicast routing, respectively. Module "ietf-ipv6-unicast- 286 routing" has a submodule, "ietf-ipv6-router-advertisements", that 287 defines configuration variables for IPv6 router advertisements as 288 required by [RFC4861]. Figures 1 and 2 show abridged views of the 289 configuration and state data hierarchies. See Appendix A for the 290 complete data trees. 292 +--rw routing 293 +--rw router-id? 294 +--rw routing-protocols 295 | +--rw routing-protocol* [type name] 296 | +--rw type 297 | +--rw name 298 | +--rw description? 299 | +--rw static-routes 300 | | +--rw v6ur:ipv6 301 | | | ... 302 | | +--rw v4ur:ipv4 303 | | ... 304 | +--rw rip:rip! 305 | +--rw rip:interfaces 306 | | ... 307 | +--rw rip:update-interval? 308 +--rw ribs 309 +--rw rib* [name] 310 +--rw name 311 +--rw address-family? 312 +--rw description? 314 Figure 1: Configuration data hierarchy. 316 +--ro routing-state 317 +--ro router-id? 318 +--ro interfaces 319 | +--ro interface* 320 +--ro routing-protocols 321 | +--ro routing-protocol* [type name] 322 | +--ro type 323 | +--ro name 324 +--ro ribs 325 +--ro rib* [name] 326 +--ro name 327 +--ro address-family 328 +--ro default-rib? 329 +--ro routes 330 +--ro route* 331 ... 333 Figure 2: State data hierarchy. 335 As can be seen from Figures 1 and 2, the core routing data model 336 introduces several generic components of a routing framework: routes, 337 RIBs containing lists of routes, and routing protocols. Section 5 338 describes these components in more detail. 340 4.1. System-Controlled and User-Controlled List Entries 342 The core routing data model defines several lists in the schema tree, 343 such as "rib", that have to be populated with at least one entry in 344 any properly functioning device, and additional entries may be 345 configured by a client. 347 In such a list, the server creates the required item as a so-called 348 system-controlled entry in state data, i.e., inside the "routing- 349 state" container. 351 An example can be seen in Appendix D: the "/routing-state/ribs/rib" 352 list has two system-controlled entries named "ipv4-master" and 353 "ipv6-master". 355 Additional entries may be created in the configuration by a client, 356 e.g., via the NETCONF protocol. These are so-called user-controlled 357 entries. If the server accepts a configured user-controlled entry, 358 then this entry also appears in the state data version of the list. 360 Corresponding entries in both versions of the list (in state data and 361 configuration) have the same value of the list key. 363 A client may also provide supplemental configuration of system- 364 controlled entries. To do so, the client creates a new entry in the 365 configuration with the desired contents. In order to bind this entry 366 to the corresponding entry in the state data list, the key of the 367 configuration entry has to be set to the same value as the key of the 368 state entry. 370 Deleting a user-controlled entry from the configuration list results 371 in the removal of the corresponding entry in the state data list. In 372 contrast, if a system-controlled entry is deleted from the 373 configuration list, only the extra configuration specified in that 374 entry is removed but the corresponding state data entry remains in 375 the list. 377 5. Basic Building Blocks 379 This section describes the essential components of the core routing 380 data model. 382 5.1. Route 384 Routes are basic elements of information in a routing system. The 385 core routing data model defines only the following minimal set of 386 route attributes: 388 o "destination-prefix": IP prefix specifying the set of destination 389 addresses for which the route may be used. This attribute is 390 mandatory. 392 o "route-preference": an integer value (also known as administrative 393 distance) that is used for selecting a preferred route among 394 routes with the same destination prefix. A lower value means a 395 more preferred route. 397 o "next-hop": determines the action to be performed with a packet. 399 Routes are primarily state data that appear as entries of RIBs 400 (Section 5.2) but they may also be found in configuration data, for 401 example as manually configured static routes. In the latter case, 402 configurable route attributes are generally a subset of route 403 attributes described above. 405 5.2. Routing Information Base (RIB) 407 Every implementation of the core routing data model manages one or 408 more routing information bases (RIB). A RIB is a list of routes 409 complemented with administrative data. Each RIB contains only routes 410 of one address family. An address family is represented by an 411 identity derived from the "rt:address-family" base identity. 413 In the core routing data model, RIBs are state data represented as 414 entries of the list "/routing-state/ribs/rib". The contents of RIBs 415 are controlled and manipulated by routing protocol operations which 416 may result in route additions, removals and modifications. This also 417 includes manipulations via the "static" and/or "direct" pseudo- 418 protocols, see Section 5.3.1. 420 For every supported address family, exactly one RIB MUST be marked as 421 the so-called default RIB. Its role is explained in Section 5.3. 423 Simple router implementations that do not advertise the feature 424 "multiple-ribs" will typically create one system-controlled RIB per 425 supported address family, and mark it as the default RIB. 427 More complex router implementations advertising the "multiple-ribs" 428 feature support multiple RIBs per address family that can be used for 429 policy routing and other purposes. 431 5.3. Routing Protocol 433 The core routing data model provides an open-ended framework for 434 defining multiple routing protocol instances. Each routing protocol 435 instance MUST be assigned a type, which is an identity derived from 436 the "rt:routing-protocol" base identity. The core routing data model 437 defines two identities for the direct and static pseudo-protocols 438 (Section 5.3.1). 440 Multiple routing protocol instances of the same type MAY be 441 configured. 443 5.3.1. Routing Pseudo-Protocols 445 The core routing data model defines two special routing protocol 446 types - "direct" and "static". Both are in fact pseudo-protocols, 447 which means they are confined to the local device and do not exchange 448 any routing information with adjacent routers. 450 Every implementation of the core routing data model MUST provide 451 exactly one instance of the "direct" pseudo-protocol type. It is the 452 source of direct routes for all configured address families. Direct 453 routes are normally supplied by the operating system kernel, based on 454 the configuration of network interface addresses, see Section 6.2. 455 Direct routes MUST be installed in default RIBs of all supported 456 address families. 458 A pseudo-protocol of the type "static" allows for specifying routes 459 manually. It MAY be configured in zero or multiple instances, 460 although a typical configuration will have exactly one instance. 462 5.3.2. Defining New Routing Protocols 464 It is expected that future YANG modules will create data models for 465 additional routing protocol types. Such a new module has to define 466 the protocol-specific configuration and state data, and it has to 467 integrate it into the core routing framework in the following way: 469 o A new identity MUST be defined for the routing protocol and its 470 base identity MUST be set to "rt:routing-protocol", or to an 471 identity derived from "rt:routing-protocol". 473 o Additional route attributes MAY be defined, preferably in one 474 place by means of defining a YANG grouping. The new attributes 475 have to be inserted by augmenting the definitions of the nodes 477 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 479 and 481 /rt:fib-route/rt:output/rt:route, 483 and possibly other places in the configuration, state data, 484 notifications, and RPC input or output. 486 o Configuration parameters and/or state data for the new protocol 487 can be defined by augmenting the "routing-protocol" data node 488 under both "/routing" and "/routing-state". 490 By using a "when" statement, the augmented configuration parameters 491 and state data specific to the new protocol SHOULD be made 492 conditional and valid only if the value of "rt:type" or "rt:source- 493 protocol" is equal to the new protocol's identity. 495 It is also RECOMMENDED that protocol-specific data nodes be 496 encapsulated in an appropriately named container with presence. Such 497 a container may contain mandatory data nodes that are otherwise 498 forbidden at the top level of an augment. 500 The above steps are implemented by the example YANG module for the 501 RIP routing protocol in Appendix C. 503 5.4. RPC Operations 505 The "ietf-routing" module defines one RPC operation: 507 o fib-route: query the routing system for the active route in the 508 Forwarding Information Base (FIB). It is the route that is 509 currently used for sending datagrams to a destination host whose 510 address is passed as the input parameter. 512 5.5. Parameters of IPv6 Router Advertisements 514 YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is 515 a submodule of the "ietf-ipv6-unicast-routing" module, augments the 516 configuration and state data of IPv6 interfaces with definitions of 517 the following variables as required by [RFC4861], sec. 6.2.1: 519 o send-advertisements, 521 o max-rtr-adv-interval, 523 o min-rtr-adv-interval, 525 o managed-flag, 527 o other-config-flag, 529 o link-mtu, 531 o reachable-time, 533 o retrans-timer, 535 o cur-hop-limit, 537 o default-lifetime, 539 o prefix-list: a list of prefixes to be advertised. 541 The following parameters are associated with each prefix in the 542 list: 544 * valid-lifetime, 546 * on-link-flag, 548 * preferred-lifetime, 550 * autonomous-flag. 552 NOTES: 554 1. The "IsRouter" flag, which is also required by [RFC4861], is 555 implemented in the "ietf-ip" module [RFC7277] (leaf 556 "ip:forwarding"). 558 2. The original specification [RFC4861] allows the implementations 559 to decide whether the "valid-lifetime" and "preferred-lifetime" 560 parameters remain the same in consecutive advertisements, or 561 decrement in real time. However, the latter behavior seems 562 problematic because the values might be reset again to the 563 (higher) configured values after a configuration is reloaded. 564 Moreover, no implementation is known to use the decrementing 565 behavior. The "ietf-ipv6-unicast-routing" module therefore 566 assumes the former behavior with constant values. 568 6. Interactions with Other YANG Modules 570 The semantics of the core routing data model also depends on several 571 configuration parameters that are defined in other YANG modules. 573 6.1. Module "ietf-interfaces" 575 The following boolean switch is defined in the "ietf-interfaces" YANG 576 module [RFC7223]: 578 /if:interfaces/if:interface/if:enabled 580 If this switch is set to "false" for a network layer interface, 581 then all routing and forwarding functions MUST be disabled on that 582 interface. 584 6.2. Module "ietf-ip" 586 The following boolean switches are defined in the "ietf-ip" YANG 587 module [RFC7277]: 589 /if:interfaces/if:interface/ip:ipv4/ip:enabled 591 If this switch is set to "false" for a network layer interface, 592 then all IPv4 routing and forwarding functions MUST be disabled on 593 that interface. 595 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 597 If this switch is set to "false" for a network layer interface, 598 then the forwarding of IPv4 datagrams through this interface MUST 599 be disabled. However, the interface MAY participate in other IPv4 600 routing functions, such as routing protocols. 602 /if:interfaces/if:interface/ip:ipv6/ip:enabled 604 If this switch is set to "false" for a network layer interface, 605 then all IPv6 routing and forwarding functions MUST be disabled on 606 that interface. 608 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 610 If this switch is set to "false" for a network layer interface, 611 then the forwarding of IPv6 datagrams through this interface MUST 612 be disabled. However, the interface MAY participate in other IPv6 613 routing functions, such as routing protocols. 615 In addition, the "ietf-ip" module allows for configuring IPv4 and 616 IPv6 addresses and network prefixes or masks on network layer 617 interfaces. Configuration of these parameters on an enabled 618 interface MUST result in an immediate creation of the corresponding 619 direct route. The destination prefix of this route is set according 620 to the configured IP address and network prefix/mask, and the 621 interface is set as the outgoing interface for that route. 623 7. Routing Management YANG Module 625 RFC Editor: In this section, replace all occurrences of 'XXXX' with 626 the actual RFC number and all occurrences of the revision date below 627 with the date of RFC publication (and remove this note). 629 file "ietf-routing@2016-03-09.yang" 631 module ietf-routing { 633 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 635 prefix "rt"; 637 import ietf-yang-types { 638 prefix "yang"; 639 } 641 import ietf-interfaces { 642 prefix "if"; 643 } 645 organization 646 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 648 contact 649 "WG Web: 650 WG List: 652 WG Chair: Lou Berger 653 655 WG Chair: Juergen Schoenwaelder 656 658 WG Chair: Kent Watsen 659 661 Editor: Ladislav Lhotka 662 664 Editor: Acee Lindem 665 "; 667 description 668 "This YANG module defines essential components for the management 669 of a routing subsystem. 671 Copyright (c) 2016 IETF Trust and the persons identified as 672 authors of the code. All rights reserved. 674 Redistribution and use in source and binary forms, with or 675 without modification, is permitted pursuant to, and subject to 676 the license terms contained in, the Simplified BSD License set 677 forth in Section 4.c of the IETF Trust's Legal Provisions 678 Relating to IETF Documents 679 (http://trustee.ietf.org/license-info). 681 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 682 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 683 'OPTIONAL' in the module text are to be interpreted as described 684 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 686 This version of this YANG module is part of RFC XXXX 687 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 688 full legal notices."; 690 revision 2016-03-09 { 691 description 692 "Initial revision."; 693 reference 694 "RFC XXXX: A YANG Data Model for Routing Management"; 695 } 696 /* Features */ 698 feature multiple-ribs { 699 description 700 "This feature indicates that the server supports user-defined 701 RIBs. 703 Servers that do not advertise this feature SHOULD provide 704 exactly one system-controlled RIB per supported address family 705 and make them also the default RIBs. These RIBs then appear as 706 entries of the list /routing-state/ribs/rib."; 707 } 709 feature router-id { 710 description 711 "This feature indicates that the server supports configuration 712 of an explicit 32-bit router ID that is used by some routing 713 protocols. 715 Servers that do not advertise this feature set a router ID 716 algorithmically, usually to one of configured IPv4 addresses. 717 However, this algorithm is implementation-specific."; 718 } 720 /* Identities */ 722 identity address-family { 723 description 724 "Base identity from which identities describing address 725 families are derived."; 726 } 728 identity ipv4 { 729 base address-family; 730 description 731 "This identity represents IPv4 address family."; 732 } 734 identity ipv6 { 735 base address-family; 736 description 737 "This identity represents IPv6 address family."; 738 } 740 identity routing-protocol { 741 description 742 "Base identity from which routing protocol identities are 743 derived."; 745 } 747 identity direct { 748 base routing-protocol; 749 description 750 "Routing pseudo-protocol that provides routes to directly 751 connected networks."; 752 } 754 identity static { 755 base routing-protocol; 756 description 757 "Static routing pseudo-protocol."; 758 } 760 /* Type Definitions */ 762 typedef route-preference { 763 type uint32; 764 description 765 "This type is used for route preferences."; 766 } 768 /* Groupings */ 770 grouping address-family { 771 description 772 "This grouping provides a leaf identifying an address 773 family."; 774 leaf address-family { 775 type identityref { 776 base address-family; 777 } 778 mandatory "true"; 779 description 780 "Address family."; 781 } 782 } 784 grouping router-id { 785 description 786 "This grouping provides router ID."; 787 leaf router-id { 788 type yang:dotted-quad; 789 description 790 "A 32-bit number in the form of a dotted quad that is used by 791 some routing protocols identifying a router."; 792 reference 793 "RFC 2328: OSPF Version 2."; 794 } 795 } 797 grouping special-next-hop { 798 description 799 "This grouping provides a leaf with an enumeration of special 800 next-hops."; 801 leaf special-next-hop { 802 type enumeration { 803 enum blackhole { 804 description 805 "Silently discard the packet."; 806 } 807 enum unreachable { 808 description 809 "Discard the packet and notify the sender with an error 810 message indicating that the destination host is 811 unreachable."; 812 } 813 enum prohibit { 814 description 815 "Discard the packet and notify the sender with an error 816 message indicating that the communication is 817 administratively prohibited."; 818 } 819 enum receive { 820 description 821 "The packet will be received by the local system."; 822 } 823 } 824 description 825 "Special next-hop options."; 826 } 827 } 829 grouping next-hop-content { 830 description 831 "Generic parameters of next-hops in static routes."; 832 choice next-hop-options { 833 mandatory "true"; 834 description 835 "Options for next-hops in static routes. 837 Modules for address families MUST augment this choice with 838 the 'next-hop-address' case, which is a leaf containing a 839 gateway address of that address family. 841 It is expected that further cases will be added through 842 augments from other modules, e.g., for Equal-Cost Multipath 843 routing (ECMP)."; 844 leaf outgoing-interface { 845 type if:interface-ref; 846 description 847 "Name of the outgoing interface."; 848 } 849 case special-next-hop { 850 uses special-next-hop; 851 } 852 } 853 } 855 grouping next-hop-state-content { 856 description 857 "Generic parameters of next-hops in state data."; 858 choice next-hop-options { 859 mandatory "true"; 860 description 861 "Options for next-hops in state data. 863 Modules for address families MUST augment this choice with 864 the 'next-hop-address' case, which is a leaf containing a 865 gateway address of that address family. 867 It is expected that further cases will be added through 868 augments from other modules, e.g., for ECMP or recursive 869 next-hops."; 870 leaf outgoing-interface { 871 type if:interface-state-ref; 872 description 873 "Name of the outgoing interface."; 874 } 875 case special-next-hop { 876 uses special-next-hop; 877 } 878 } 879 } 881 grouping route-metadata { 882 description 883 "Common route metadata."; 884 leaf source-protocol { 885 type identityref { 886 base routing-protocol; 887 } 888 mandatory "true"; 889 description 890 "Type of the routing protocol from which the route 891 originated."; 892 } 893 leaf active { 894 type empty; 895 description 896 "Presence of this leaf indicates that the route is preferred 897 among all routes in the same RIB that have the same 898 destination prefix."; 899 } 900 leaf last-updated { 901 type yang:date-and-time; 902 description 903 "Time stamp of the last modification of the route. If the 904 route was never modified, it is the time when the route was 905 inserted into the RIB."; 906 } 907 } 909 /* State data */ 911 container routing-state { 912 config "false"; 913 description 914 "State data of the routing subsystem."; 915 uses router-id { 916 description 917 "Global router ID. 919 It may be either configured or assigned algorithmically by 920 the implementation."; 921 } 922 container interfaces { 923 description 924 "Network layer interfaces used for routing."; 925 leaf-list interface { 926 type if:interface-state-ref; 927 description 928 "Each entry is a reference to the name of a configured 929 network layer interface."; 930 } 931 } 932 container routing-protocols { 933 description 934 "Container for the list of routing protocol instances."; 935 list routing-protocol { 936 key "type name"; 937 description 938 "State data of a routing protocol instance. 940 An implementation MUST provide exactly one 941 system-controlled instance of the type 'direct'. Other 942 instances MAY be created by configuration."; 943 leaf type { 944 type identityref { 945 base routing-protocol; 946 } 947 description 948 "Type of the routing protocol."; 949 } 950 leaf name { 951 type string; 952 description 953 "The name of the routing protocol instance. 955 For system-controlled instances this name is persistent, 956 i.e., it SHOULD NOT change across reboots."; 957 } 958 } 959 } 960 container ribs { 961 description 962 "Container for RIBs."; 963 list rib { 964 key "name"; 965 min-elements "1"; 966 description 967 "Each entry represents a RIB identified by the 'name' key. 968 All routes in a RIB MUST belong to the same address 969 family. 971 An implementation SHOULD provide one system-controlled 972 default RIB for each supported address family."; 973 leaf name { 974 type string; 975 description 976 "The name of the RIB."; 977 } 978 uses address-family; 979 leaf default-rib { 980 if-feature multiple-ribs; 981 type boolean; 982 default "true"; 983 description 984 "This flag has the value of 'true' if and only if the RIB 985 is the default RIB for the given address family. 987 A default RIB always receives direct routes. By default 988 it also receives routes from all routing protocols."; 989 } 990 container routes { 991 description 992 "Current content of the RIB."; 993 list route { 994 description 995 "A RIB route entry. This data node MUST be augmented 996 with information specific for routes of each address 997 family."; 998 leaf route-preference { 999 type route-preference; 1000 description 1001 "This route attribute, also known as administrative 1002 distance, allows for selecting the preferred route 1003 among routes with the same destination prefix. A 1004 smaller value means a more preferred route."; 1005 } 1006 container next-hop { 1007 description 1008 "Route's next-hop attribute."; 1009 uses next-hop-state-content; 1010 } 1011 uses route-metadata; 1012 } 1013 } 1014 } 1015 } 1016 } 1018 /* Configuration Data */ 1020 container routing { 1021 description 1022 "Configuration parameters for the routing subsystem."; 1023 uses router-id { 1024 if-feature router-id; 1025 description 1026 "Configuration of the global router ID. Routing protocols 1027 that use router ID can use this parameter or override it 1028 with another value."; 1029 } 1030 container routing-protocols { 1031 description 1032 "Configuration of routing protocol instances."; 1034 list routing-protocol { 1035 key "type name"; 1036 description 1037 "Each entry contains configuration of a routing protocol 1038 instance."; 1039 leaf type { 1040 type identityref { 1041 base routing-protocol; 1042 } 1043 description 1044 "Type of the routing protocol - an identity derived from 1045 the 'routing-protocol' base identity."; 1046 } 1047 leaf name { 1048 type string; 1049 description 1050 "An arbitrary name of the routing protocol instance."; 1051 } 1052 leaf description { 1053 type string; 1054 description 1055 "Textual description of the routing protocol instance."; 1056 } 1057 container static-routes { 1058 when "../type='rt:static'" { 1059 description 1060 "This container is only valid for the 'static' routing 1061 protocol."; 1062 } 1063 description 1064 "Configuration of the 'static' pseudo-protocol. 1066 Address-family-specific modules augment this node with 1067 their lists of routes."; 1068 } 1069 } 1070 } 1071 container ribs { 1072 description 1073 "Configuration of RIBs."; 1074 list rib { 1075 key "name"; 1076 description 1077 "Each entry contains configuration for a RIB identified by 1078 the 'name' key. 1080 Entries having the same key as a system-controlled entry 1081 of the list /routing-state/ribs/rib are used for 1082 configuring parameters of that entry. Other entries define 1083 additional user-controlled RIBs."; 1084 leaf name { 1085 type string; 1086 description 1087 "The name of the RIB. 1089 For system-controlled entries, the value of this leaf 1090 must be the same as the name of the corresponding entry 1091 in state data. 1093 For user-controlled entries, an arbitrary name can be 1094 used."; 1095 } 1096 uses address-family { 1097 description 1098 "Address family of the RIB. 1100 It is mandatory for user-controlled RIBs. For 1101 system-controlled RIBs it can be omitted, otherwise it 1102 must match the address family of the corresponding state 1103 entry."; 1104 refine "address-family" { 1105 mandatory "false"; 1106 } 1107 } 1108 leaf description { 1109 type string; 1110 description 1111 "Textual description of the RIB."; 1112 } 1113 } 1114 } 1115 } 1117 /* RPC operations */ 1119 rpc fib-route { 1120 description 1121 "Return the active FIB route that is used for sending packets 1122 to a destination address."; 1123 input { 1124 container destination-address { 1125 description 1126 "Network layer destination address. 1128 Address family specific modules MUST augment this 1129 container with a leaf named 'address'."; 1131 uses address-family; 1132 } 1133 } 1134 output { 1135 container route { 1136 description 1137 "The active FIB route for the specified destination. 1139 If no active FIB route exists for the destination address, 1140 no output is returned - the server SHALL send an 1141 containing a single element . 1143 Address family specific modules MUST augment this list 1144 with appropriate route contents."; 1145 uses address-family; 1146 container next-hop { 1147 description 1148 "Route's next-hop attribute."; 1149 uses next-hop-state-content; 1150 } 1151 uses route-metadata; 1152 } 1153 } 1154 } 1155 } 1157 1159 8. IPv4 Unicast Routing Management YANG Module 1161 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1162 the actual RFC number and all occurrences of the revision date below 1163 with the date of RFC publication (and remove this note). 1165 file "ietf-ipv4-unicast-routing@2016-03-09.yang" 1167 module ietf-ipv4-unicast-routing { 1169 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1171 prefix "v4ur"; 1173 import ietf-routing { 1174 prefix "rt"; 1175 } 1177 import ietf-inet-types { 1178 prefix "inet"; 1180 } 1182 organization 1183 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1185 contact 1186 "WG Web: 1187 WG List: 1189 WG Chair: Lou Berger 1190 1192 WG Chair: Juergen Schoenwaelder 1193 1195 WG Chair: Kent Watsen 1196 1198 Editor: Ladislav Lhotka 1199 1201 Editor: Acee Lindem 1202 "; 1204 description 1205 "This YANG module augments the 'ietf-routing' module with basic 1206 configuration and state data for IPv4 unicast routing. 1208 Copyright (c) 2016 IETF Trust and the persons identified as 1209 authors of the code. All rights reserved. 1211 Redistribution and use in source and binary forms, with or 1212 without modification, is permitted pursuant to, and subject to 1213 the license terms contained in, the Simplified BSD License set 1214 forth in Section 4.c of the IETF Trust's Legal Provisions 1215 Relating to IETF Documents 1216 (http://trustee.ietf.org/license-info). 1218 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1219 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1220 'OPTIONAL' in the module text are to be interpreted as described 1221 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1223 This version of this YANG module is part of RFC XXXX 1224 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1225 full legal notices."; 1227 revision 2016-03-09 { 1228 description 1229 "Initial revision."; 1230 reference 1231 "RFC XXXX: A YANG Data Model for Routing Management"; 1232 } 1234 /* Identities */ 1236 identity ipv4-unicast { 1237 base rt:ipv4; 1238 description 1239 "This identity represents the IPv4 unicast address family."; 1240 } 1242 /* State data */ 1244 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1245 when "../../rt:address-family = 'v4ur:ipv4-unicast'" { 1246 description 1247 "This augment is valid only for IPv4 unicast."; 1248 } 1249 description 1250 "This leaf augments an IPv4 unicast route."; 1251 leaf destination-prefix { 1252 type inet:ipv4-prefix; 1253 description 1254 "IPv4 destination prefix."; 1255 } 1256 } 1258 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1259 + "rt:next-hop/rt:next-hop-options" { 1260 when "../../../rt:address-family = 'v4ur:ipv4-unicast'" { 1261 description 1262 "This augment is valid only for IPv4 unicast."; 1263 } 1264 description 1265 "Augment 'next-hop-options' in IPv4 unicast routes."; 1266 leaf next-hop-address { 1267 type inet:ipv4-address; 1268 description 1269 "IPv4 address of the next-hop."; 1270 } 1271 } 1273 /* Configuration data */ 1275 augment "/rt:routing/rt:routing-protocols/rt:routing-protocol/" 1276 + "rt:static-routes" { 1277 description 1278 "This augment defines the configuration of the 'static' 1279 pseudo-protocol with data specific to IPv4 unicast."; 1280 container ipv4 { 1281 description 1282 "Configuration of a 'static' pseudo-protocol instance 1283 consists of a list of routes."; 1284 list route { 1285 key "destination-prefix"; 1286 description 1287 "A list of static routes."; 1288 leaf destination-prefix { 1289 type inet:ipv4-prefix; 1290 mandatory "true"; 1291 description 1292 "IPv4 destination prefix."; 1293 } 1294 leaf description { 1295 type string; 1296 description 1297 "Textual description of the route."; 1298 } 1299 container next-hop { 1300 description 1301 "Configuration of next-hop."; 1302 uses rt:next-hop-content { 1303 augment "next-hop-options" { 1304 description 1305 "Augment 'next-hop-options' in IPv4 static routes."; 1306 leaf next-hop-address { 1307 type inet:ipv4-address; 1308 description 1309 "IPv4 address of the next-hop."; 1310 } 1311 } 1312 } 1313 } 1314 } 1315 } 1316 } 1318 /* RPC operations */ 1320 augment "/rt:fib-route/rt:input/rt:destination-address" { 1321 when "rt:address-family='v4ur:ipv4-unicast'" { 1322 description 1323 "This augment is valid only for IPv4 unicast."; 1325 } 1326 description 1327 "This leaf augments the 'rt:destination-address' parameter of 1328 the 'rt:fib-route' operation."; 1329 leaf address { 1330 type inet:ipv4-address; 1331 description 1332 "IPv4 destination address."; 1333 } 1334 } 1336 augment "/rt:fib-route/rt:output/rt:route" { 1337 when "rt:address-family='v4ur:ipv4-unicast'" { 1338 description 1339 "This augment is valid only for IPv4 unicast."; 1340 } 1341 description 1342 "This leaf augments the reply to the 'rt:fib-route' 1343 operation."; 1344 leaf destination-prefix { 1345 type inet:ipv4-prefix; 1346 description 1347 "IPv4 destination prefix."; 1348 } 1349 } 1351 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 1352 + "rt:next-hop-options" { 1353 when "../rt:address-family='v4ur:ipv4-unicast'" { 1354 description 1355 "This augment is valid only for IPv4 unicast."; 1356 } 1357 description 1358 "Augment 'next-hop-options' in the reply to the 'rt:fib-route' 1359 operation."; 1360 leaf next-hop-address { 1361 type inet:ipv4-address; 1362 description 1363 "IPv4 address of the next-hop."; 1364 } 1365 } 1366 } 1368 1370 9. IPv6 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-ipv6-unicast-routing@2016-03-09.yang" 1378 module ietf-ipv6-unicast-routing { 1380 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1382 prefix "v6ur"; 1384 import ietf-routing { 1385 prefix "rt"; 1386 } 1388 import ietf-inet-types { 1389 prefix "inet"; 1390 } 1392 include ietf-ipv6-router-advertisements { 1393 revision-date 2016-03-09; 1394 } 1396 organization 1397 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1399 contact 1400 "WG Web: 1401 WG List: 1403 WG Chair: Lou Berger 1404 1406 WG Chair: Juergen Schoenwaelder 1407 1409 WG Chair: Kent Watsen 1410 1412 Editor: Ladislav Lhotka 1413 1415 Editor: Acee Lindem 1416 "; 1418 description 1419 "This YANG module augments the 'ietf-routing' module with basic 1420 configuration and state data for IPv6 unicast routing. 1422 Copyright (c) 2016 IETF Trust and the persons identified as 1423 authors of the code. All rights reserved. 1425 Redistribution and use in source and binary forms, with or 1426 without modification, is permitted pursuant to, and subject to 1427 the license terms contained in, the Simplified BSD License set 1428 forth in Section 4.c of the IETF Trust's Legal Provisions 1429 Relating to IETF Documents 1430 (http://trustee.ietf.org/license-info). 1432 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1433 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1434 'OPTIONAL' in the module text are to be interpreted as described 1435 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1437 This version of this YANG module is part of RFC XXXX 1438 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1439 full legal notices."; 1441 revision 2016-03-09 { 1442 description 1443 "Initial revision."; 1444 reference 1445 "RFC XXXX: A YANG Data Model for Routing Management"; 1446 } 1448 /* Identities */ 1450 identity ipv6-unicast { 1451 base rt:ipv6; 1452 description 1453 "This identity represents the IPv6 unicast address family."; 1454 } 1456 /* State data */ 1458 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1459 when "../../rt:address-family = 'v6ur:ipv6-unicast'" { 1460 description 1461 "This augment is valid only for IPv6 unicast."; 1462 } 1463 description 1464 "This leaf augments an IPv6 unicast route."; 1465 leaf destination-prefix { 1466 type inet:ipv6-prefix; 1467 description 1468 "IPv6 destination prefix."; 1469 } 1470 } 1472 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1473 + "rt:next-hop/rt:next-hop-options" { 1474 when "../../../rt:address-family = 'v6ur:ipv6-unicast'" { 1475 description 1476 "This augment is valid only for IPv6 unicast."; 1477 } 1478 description 1479 "Augment 'next-hop-options' in IPv6 unicast routes."; 1480 leaf next-hop-address { 1481 type inet:ipv6-address; 1482 description 1483 "IPv6 address of the next-hop."; 1484 } 1485 } 1487 /* Configuration data */ 1489 augment "/rt:routing/rt:routing-protocols/rt:routing-protocol/" 1490 + "rt:static-routes" { 1491 description 1492 "This augment defines the configuration of the 'static' 1493 pseudo-protocol with data specific to IPv6 unicast."; 1494 container ipv6 { 1495 description 1496 "Configuration of a 'static' pseudo-protocol instance 1497 consists of a list of routes."; 1498 list route { 1499 key "destination-prefix"; 1500 description 1501 "A list of static routes."; 1502 leaf destination-prefix { 1503 type inet:ipv6-prefix; 1504 mandatory "true"; 1505 description 1506 "IPv6 destination prefix."; 1507 } 1508 leaf description { 1509 type string; 1510 description 1511 "Textual description of the route."; 1512 } 1513 container next-hop { 1514 description 1515 "Configuration of next-hop."; 1516 uses rt:next-hop-content { 1517 augment "next-hop-options" { 1518 description 1519 "Augment 'next-hop-options' in IPv6 static routes."; 1520 leaf next-hop-address { 1521 type inet:ipv6-address; 1522 description 1523 "IPv6 address of the next-hop."; 1524 } 1525 } 1526 } 1527 } 1528 } 1529 } 1530 } 1532 /* RPC operations */ 1534 augment "/rt:fib-route/rt:input/rt:destination-address" { 1535 when "rt:address-family='v6ur:ipv6-unicast'" { 1536 description 1537 "This augment is valid only for IPv6 unicast."; 1538 } 1539 description 1540 "This leaf augments the 'rt:destination-address' parameter of 1541 the 'rt:fib-route' operation."; 1542 leaf address { 1543 type inet:ipv6-address; 1544 description 1545 "IPv6 destination address."; 1546 } 1547 } 1549 augment "/rt:fib-route/rt:output/rt:route" { 1550 when "rt:address-family='v6ur:ipv6-unicast'" { 1551 description 1552 "This augment is valid only for IPv6 unicast."; 1553 } 1554 description 1555 "This leaf augments the reply to the 'rt:fib-route' 1556 operation."; 1557 leaf destination-prefix { 1558 type inet:ipv6-prefix; 1559 description 1560 "IPv6 destination prefix."; 1561 } 1563 } 1565 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 1566 + "rt:next-hop-options" { 1567 when "../rt:address-family='v6ur:ipv6-unicast'" { 1568 description 1569 "This augment is valid only for IPv6 unicast."; 1570 } 1571 description 1572 "Augment 'next-hop-options' in the reply to the 'rt:fib-route' 1573 operation."; 1574 leaf next-hop-address { 1575 type inet:ipv6-address; 1576 description 1577 "IPv6 address of the next-hop."; 1578 } 1579 } 1580 } 1582 1584 9.1. IPv6 Router Advertisements Submodule 1586 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1587 the actual RFC number and all occurrences of the revision date below 1588 with the date of RFC publication (and remove this note). 1590 file "ietf-ipv6-router-advertisements@2016-03-09.yang" 1592 submodule ietf-ipv6-router-advertisements { 1594 belongs-to ietf-ipv6-unicast-routing { 1595 prefix "v6ur"; 1596 } 1598 import ietf-inet-types { 1599 prefix "inet"; 1600 } 1602 import ietf-interfaces { 1603 prefix "if"; 1604 } 1606 import ietf-ip { 1607 prefix "ip"; 1608 } 1610 organization 1611 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1613 contact 1614 "WG Web: 1615 WG List: 1617 WG Chair: Lou Berger 1618 1620 WG Chair: Juergen Schoenwaelder 1621 1623 WG Chair: Kent Watsen 1624 1626 Editor: Ladislav Lhotka 1627 1629 Editor: Acee Lindem 1630 "; 1632 description 1633 "This YANG module augments the 'ietf-ip' module with 1634 configuration and state data of IPv6 router advertisements. 1636 Copyright (c) 2016 IETF Trust and the persons identified as 1637 authors of the code. All rights reserved. 1639 Redistribution and use in source and binary forms, with or 1640 without modification, is permitted pursuant to, and subject to 1641 the license terms contained in, the Simplified BSD License set 1642 forth in Section 4.c of the IETF Trust's Legal Provisions 1643 Relating to IETF Documents 1644 (http://trustee.ietf.org/license-info). 1646 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1647 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1648 'OPTIONAL' in the module text are to be interpreted as described 1649 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1651 This version of this YANG module is part of RFC XXXX 1652 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1653 full legal notices."; 1655 reference 1656 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; 1658 revision 2016-03-09 { 1659 description 1660 "Initial revision."; 1661 reference 1662 "RFC XXXX: A YANG Data Model for Routing Management"; 1663 } 1665 /* State data */ 1667 augment "/if:interfaces-state/if:interface/ip:ipv6" { 1668 description 1669 "Augment interface state data with parameters of IPv6 router 1670 advertisements."; 1671 container ipv6-router-advertisements { 1672 description 1673 "Parameters of IPv6 Router Advertisements."; 1674 leaf send-advertisements { 1675 type boolean; 1676 description 1677 "A flag indicating whether or not the router sends periodic 1678 Router Advertisements and responds to Router 1679 Solicitations."; 1680 } 1681 leaf max-rtr-adv-interval { 1682 type uint16 { 1683 range "4..1800"; 1684 } 1685 units "seconds"; 1686 description 1687 "The maximum time allowed between sending unsolicited 1688 multicast Router Advertisements from the interface."; 1689 } 1690 leaf min-rtr-adv-interval { 1691 type uint16 { 1692 range "3..1350"; 1693 } 1694 units "seconds"; 1695 description 1696 "The minimum time allowed between sending unsolicited 1697 multicast Router Advertisements from the interface."; 1698 } 1699 leaf managed-flag { 1700 type boolean; 1701 description 1702 "The value that is placed in the 'Managed address 1703 configuration' flag field in the Router Advertisement."; 1704 } 1705 leaf other-config-flag { 1706 type boolean; 1707 description 1708 "The value that is placed in the 'Other configuration' flag 1709 field in the Router Advertisement."; 1710 } 1711 leaf link-mtu { 1712 type uint32; 1713 description 1714 "The value that is placed in MTU options sent by the 1715 router. A value of zero indicates that no MTU options are 1716 sent."; 1717 } 1718 leaf reachable-time { 1719 type uint32 { 1720 range "0..3600000"; 1721 } 1722 units "milliseconds"; 1723 description 1724 "The value that is placed in the Reachable Time field in 1725 the Router Advertisement messages sent by the router. A 1726 value of zero means unspecified (by this router)."; 1727 } 1728 leaf retrans-timer { 1729 type uint32; 1730 units "milliseconds"; 1731 description 1732 "The value that is placed in the Retrans Timer field in the 1733 Router Advertisement messages sent by the router. A value 1734 of zero means unspecified (by this router)."; 1735 } 1736 leaf cur-hop-limit { 1737 type uint8; 1738 description 1739 "The value that is placed in the Cur Hop Limit field in the 1740 Router Advertisement messages sent by the router. A value 1741 of zero means unspecified (by this router)."; 1742 } 1743 leaf default-lifetime { 1744 type uint16 { 1745 range "0..9000"; 1746 } 1747 units "seconds"; 1748 description 1749 "The value that is placed in the Router Lifetime field of 1750 Router Advertisements sent from the interface, in seconds. 1751 A value of zero indicates that the router is not to be 1752 used as a default router."; 1753 } 1754 container prefix-list { 1755 description 1756 "A list of prefixes that are placed in Prefix Information 1757 options in Router Advertisement messages sent from the 1758 interface. 1760 By default, these are all prefixes that the router 1761 advertises via routing protocols as being on-link for the 1762 interface from which the advertisement is sent."; 1763 list prefix { 1764 key "prefix-spec"; 1765 description 1766 "Advertised prefix entry and its parameters."; 1767 leaf prefix-spec { 1768 type inet:ipv6-prefix; 1769 description 1770 "IPv6 address prefix."; 1771 } 1772 leaf valid-lifetime { 1773 type uint32; 1774 units "seconds"; 1775 description 1776 "The value that is placed in the Valid Lifetime in the 1777 Prefix Information option. The designated value of all 1778 1's (0xffffffff) represents infinity. 1780 An implementation SHOULD keep this value constant in 1781 consecutive advertisements except when it is 1782 explicitly changed in configuration."; 1783 } 1784 leaf on-link-flag { 1785 type boolean; 1786 description 1787 "The value that is placed in the on-link flag ('L-bit') 1788 field in the Prefix Information option."; 1789 } 1790 leaf preferred-lifetime { 1791 type uint32; 1792 units "seconds"; 1793 description 1794 "The value that is placed in the Preferred Lifetime in 1795 the Prefix Information option, in seconds. The 1796 designated value of all 1's (0xffffffff) represents 1797 infinity. 1799 An implementation SHOULD keep this value constant in 1800 consecutive advertisements except when it is 1801 explicitly changed in configuration."; 1802 } 1803 leaf autonomous-flag { 1804 type boolean; 1805 description 1806 "The value that is placed in the Autonomous Flag field 1807 in the Prefix Information option."; 1808 } 1809 } 1810 } 1811 } 1812 } 1814 /* Configuration data */ 1816 augment "/if:interfaces/if:interface/ip:ipv6" { 1817 description 1818 "Augment interface configuration with parameters of IPv6 router 1819 advertisements."; 1820 container ipv6-router-advertisements { 1821 description 1822 "Configuration of IPv6 Router Advertisements."; 1823 leaf send-advertisements { 1824 type boolean; 1825 default "false"; 1826 description 1827 "A flag indicating whether or not the router sends periodic 1828 Router Advertisements and responds to Router 1829 Solicitations."; 1830 reference 1831 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1832 AdvSendAdvertisements."; 1833 } 1834 leaf max-rtr-adv-interval { 1835 type uint16 { 1836 range "4..1800"; 1837 } 1838 units "seconds"; 1839 default "600"; 1840 description 1841 "The maximum time allowed between sending unsolicited 1842 multicast Router Advertisements from the interface."; 1843 reference 1844 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1845 MaxRtrAdvInterval."; 1846 } 1847 leaf min-rtr-adv-interval { 1848 type uint16 { 1849 range "3..1350"; 1850 } 1851 units "seconds"; 1852 must ". <= 0.75 * ../max-rtr-adv-interval" { 1853 description 1854 "The value MUST NOT be greater than 75 % of 1855 'max-rtr-adv-interval'."; 1856 } 1857 description 1858 "The minimum time allowed between sending unsolicited 1859 multicast Router Advertisements from the interface. 1861 The default value to be used operationally if this leaf is 1862 not configured is determined as follows: 1864 - if max-rtr-adv-interval >= 9 seconds, the default value 1865 is 0.33 * max-rtr-adv-interval; 1867 - otherwise it is 0.75 * max-rtr-adv-interval."; 1868 reference 1869 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1870 MinRtrAdvInterval."; 1871 } 1872 leaf managed-flag { 1873 type boolean; 1874 default "false"; 1875 description 1876 "The value to be placed in the 'Managed address 1877 configuration' flag field in the Router Advertisement."; 1878 reference 1879 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1880 AdvManagedFlag."; 1881 } 1882 leaf other-config-flag { 1883 type boolean; 1884 default "false"; 1885 description 1886 "The value to be placed in the 'Other configuration' flag 1887 field in the Router Advertisement."; 1888 reference 1889 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1890 AdvOtherConfigFlag."; 1891 } 1892 leaf link-mtu { 1893 type uint32; 1894 default "0"; 1895 description 1896 "The value to be placed in MTU options sent by the router. 1897 A value of zero indicates that no MTU options are sent."; 1898 reference 1899 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1900 AdvLinkMTU."; 1901 } 1902 leaf reachable-time { 1903 type uint32 { 1904 range "0..3600000"; 1905 } 1906 units "milliseconds"; 1907 default "0"; 1908 description 1909 "The value to be placed in the Reachable Time field in the 1910 Router Advertisement messages sent by the router. A value 1911 of zero means unspecified (by this router)."; 1912 reference 1913 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1914 AdvReachableTime."; 1915 } 1916 leaf retrans-timer { 1917 type uint32; 1918 units "milliseconds"; 1919 default "0"; 1920 description 1921 "The value to be placed in the Retrans Timer field in the 1922 Router Advertisement messages sent by the router. A value 1923 of zero means unspecified (by this router)."; 1924 reference 1925 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1926 AdvRetransTimer."; 1927 } 1928 leaf cur-hop-limit { 1929 type uint8; 1930 description 1931 "The value to be placed in the Cur Hop Limit field in the 1932 Router Advertisement messages sent by the router. A value 1933 of zero means unspecified (by this router). 1935 If this parameter is not configured, the device SHOULD use 1936 the value specified in IANA Assigned Numbers that was in 1937 effect at the time of implementation."; 1938 reference 1939 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1940 AdvCurHopLimit. 1942 IANA: IP Parameters, 1943 http://www.iana.org/assignments/ip-parameters"; 1944 } 1945 leaf default-lifetime { 1946 type uint16 { 1947 range "0..9000"; 1948 } 1949 units "seconds"; 1950 description 1951 "The value to be placed in the Router Lifetime field of 1952 Router Advertisements sent from the interface, in seconds. 1953 It MUST be either zero or between max-rtr-adv-interval and 1954 9000 seconds. A value of zero indicates that the router is 1955 not to be used as a default router. These limits may be 1956 overridden by specific documents that describe how IPv6 1957 operates over different link layers. 1959 If this parameter is not configured, the device SHOULD use 1960 a value of 3 * max-rtr-adv-interval."; 1961 reference 1962 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1963 AdvDefaultLifeTime."; 1964 } 1965 container prefix-list { 1966 description 1967 "Configuration of prefixes to be placed in Prefix 1968 Information options in Router Advertisement messages sent 1969 from the interface. 1971 Prefixes that are advertised by default but do not have 1972 their entries in the child 'prefix' list are advertised 1973 with the default values of all parameters. 1975 The link-local prefix SHOULD NOT be included in the list 1976 of advertised prefixes."; 1977 reference 1978 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1979 AdvPrefixList."; 1980 list prefix { 1981 key "prefix-spec"; 1982 description 1983 "Configuration of an advertised prefix entry."; 1984 leaf prefix-spec { 1985 type inet:ipv6-prefix; 1986 description 1987 "IPv6 address prefix."; 1988 } 1989 choice control-adv-prefixes { 1990 default "advertise"; 1991 description 1992 "The prefix either may be explicitly removed from the 1993 set of advertised prefixes, or parameters with which 1994 it is advertised may be specified (default case)."; 1996 leaf no-advertise { 1997 type empty; 1998 description 1999 "The prefix will not be advertised. 2001 This can be used for removing the prefix from the 2002 default set of advertised prefixes."; 2003 } 2004 case advertise { 2005 leaf valid-lifetime { 2006 type uint32; 2007 units "seconds"; 2008 default "2592000"; 2009 description 2010 "The value to be placed in the Valid Lifetime in 2011 the Prefix Information option. The designated 2012 value of all 1's (0xffffffff) represents 2013 infinity."; 2014 reference 2015 "RFC 4861: Neighbor Discovery for IP version 6 2016 (IPv6) - AdvValidLifetime."; 2017 } 2018 leaf on-link-flag { 2019 type boolean; 2020 default "true"; 2021 description 2022 "The value to be placed in the on-link flag 2023 ('L-bit') field in the Prefix Information 2024 option."; 2025 reference 2026 "RFC 4861: Neighbor Discovery for IP version 6 2027 (IPv6) - AdvOnLinkFlag."; 2028 } 2029 leaf preferred-lifetime { 2030 type uint32; 2031 units "seconds"; 2032 must ". <= ../valid-lifetime" { 2033 description 2034 "This value MUST NOT be greater than 2035 valid-lifetime."; 2036 } 2037 default "604800"; 2038 description 2039 "The value to be placed in the Preferred Lifetime 2040 in the Prefix Information option. The designated 2041 value of all 1's (0xffffffff) represents 2042 infinity."; 2043 reference 2044 "RFC 4861: Neighbor Discovery for IP version 6 2045 (IPv6) - AdvPreferredLifetime."; 2046 } 2047 leaf autonomous-flag { 2048 type boolean; 2049 default "true"; 2050 description 2051 "The value to be placed in the Autonomous Flag 2052 field in the Prefix Information option."; 2053 reference 2054 "RFC 4861: Neighbor Discovery for IP version 6 2055 (IPv6) - AdvAutonomousFlag."; 2056 } 2057 } 2058 } 2059 } 2060 } 2061 } 2062 } 2063 } 2065 2067 10. IANA Considerations 2069 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2070 actual RFC number (and remove this note). 2072 This document registers the following namespace URIs in the IETF XML 2073 registry [RFC3688]: 2075 -------------------------------------------------------------------- 2076 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2078 Registrant Contact: The IESG. 2080 XML: N/A, the requested URI is an XML namespace. 2081 -------------------------------------------------------------------- 2083 -------------------------------------------------------------------- 2084 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2086 Registrant Contact: The IESG. 2088 XML: N/A, the requested URI is an XML namespace. 2089 -------------------------------------------------------------------- 2090 -------------------------------------------------------------------- 2091 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2093 Registrant Contact: The IESG. 2095 XML: N/A, the requested URI is an XML namespace. 2096 -------------------------------------------------------------------- 2098 This document registers the following YANG modules in the YANG Module 2099 Names registry [RFC6020]: 2101 -------------------------------------------------------------------- 2102 name: ietf-routing 2103 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2104 prefix: rt 2105 reference: RFC XXXX 2106 -------------------------------------------------------------------- 2108 -------------------------------------------------------------------- 2109 name: ietf-ipv4-unicast-routing 2110 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2111 prefix: v4ur 2112 reference: RFC XXXX 2113 -------------------------------------------------------------------- 2115 -------------------------------------------------------------------- 2116 name: ietf-ipv6-unicast-routing 2117 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2118 prefix: v6ur 2119 reference: RFC XXXX 2120 -------------------------------------------------------------------- 2122 This document registers the following YANG submodule in the YANG 2123 Module Names registry [RFC6020]: 2125 -------------------------------------------------------------------- 2126 name: ietf-ipv6-router-advertisements 2127 parent: ietf-ipv6-unicast-routing 2128 reference: RFC XXXX 2129 -------------------------------------------------------------------- 2131 11. Security Considerations 2133 Configuration and state data conforming to the core routing data 2134 model (defined in this document) are designed to be accessed via the 2135 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2136 transport layer and the mandatory-to-implement secure transport is 2137 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 2138 the means to restrict access for particular NETCONF users to a pre- 2139 configured subset of all available NETCONF protocol operations and 2140 content. 2142 A number of data nodes defined in the YANG modules belonging to the 2143 configuration part of the core routing data model are 2144 writable/creatable/deletable (i.e., "config true" in YANG terms, 2145 which is the default). These data nodes may be considered sensitive 2146 or vulnerable in some network environments. Write operations to 2147 these data nodes, such as "edit-config", can have negative effects on 2148 the network if the protocol operations are not properly protected. 2150 The vulnerable "config true" parameters and subtrees are the 2151 following: 2153 /routing/routing-protocols/routing-protocol: This list specifies the 2154 routing protocols configured on a device. 2156 /routing/ribs/rib: This list specifies the RIBs configured for the 2157 device. 2159 Unauthorised access to any of these lists can adversely affect the 2160 routing subsystem of both the local device and the network. This may 2161 lead to network malfunctions, delivery of packets to inappropriate 2162 destinations and other problems. 2164 12. Acknowledgments 2166 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 2167 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 2168 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 2169 Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, 2170 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, Derek Man- 2171 Kit Yeung and Jeffrey Zhang for their helpful comments and 2172 suggestions. 2174 13. References 2176 13.1. Normative References 2178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2179 Requirement Levels", BCP 14, RFC 2119, 2180 DOI 10.17487/RFC2119, March 1997, 2181 . 2183 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2184 DOI 10.17487/RFC3688, January 2004, 2185 . 2187 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2188 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2189 DOI 10.17487/RFC4861, September 2007, 2190 . 2192 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2193 the Network Configuration Protocol (NETCONF)", RFC 6020, 2194 DOI 10.17487/RFC6020, October 2010, 2195 . 2197 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2198 and A. Bierman, Ed., "Network Configuration Protocol 2199 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2200 . 2202 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2203 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2204 . 2206 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2207 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2208 . 2210 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 2211 RFC 7277, DOI 10.17487/RFC7277, June 2014, 2212 . 2214 13.2. Informative References 2216 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2217 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2218 January 2011, . 2220 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2221 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2222 . 2224 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2225 Protocol (NETCONF) Access Control Model", RFC 6536, 2226 DOI 10.17487/RFC6536, March 2012, 2227 . 2229 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 2230 RFC 7224, DOI 10.17487/RFC7224, May 2014, 2231 . 2233 Appendix A. The Complete Data Trees 2235 This appendix presents the complete configuration and state data 2236 trees of the core routing data model. See Section 2.2 for an 2237 explanation of the symbols used. Data type of every leaf node is 2238 shown near the right end of the corresponding line. 2240 A.1. Configuration Data 2241 +--rw routing 2242 +--rw router-id? yang:dotted-quad 2243 +--rw routing-protocols 2244 | +--rw routing-protocol* [type name] 2245 | +--rw type identityref 2246 | +--rw name string 2247 | +--rw description? string 2248 | +--rw static-routes 2249 | | +--rw v6ur:ipv6 2250 | | | +--rw v6ur:route* [destination-prefix] 2251 | | | +--rw v6ur:destination-prefix inet:ipv6-prefix 2252 | | | +--rw v6ur:description? string 2253 | | | +--rw v6ur:next-hop 2254 | | | +--rw (v6ur:next-hop-options) 2255 | | | +--:(v6ur:outgoing-interface) 2256 | | | | +--rw v6ur:outgoing-interface? if:interface-ref 2257 | | | +--:(v6ur:special-next-hop) 2258 | | | | +--rw v6ur:special-next-hop? enumeration 2259 | | | +--:(v6ur:next-hop-address) 2260 | | | +--rw v6ur:next-hop-address? inet:ipv6-address 2261 | | +--rw v4ur:ipv4 2262 | | +--rw v4ur:route* [destination-prefix] 2263 | | +--rw v4ur:destination-prefix inet:ipv4-prefix 2264 | | +--rw v4ur:description? string 2265 | | +--rw v4ur:next-hop 2266 | | +--rw (v4ur:next-hop-options) 2267 | | +--:(v4ur:outgoing-interface) 2268 | | | +--rw v4ur:outgoing-interface? if:interface-ref 2269 | | +--:(v4ur:special-next-hop) 2270 | | | +--rw v4ur:special-next-hop? enumeration 2271 | | +--:(v4ur:next-hop-address) 2272 | | +--rw v4ur:next-hop-address? inet:ipv4-address 2273 | +--rw rip:rip! 2274 | +--rw rip:interfaces 2275 | | +--rw rip:interface* [name] 2276 | | +--rw rip:name if:interface-ref 2277 | | +--rw rip:enabled? boolean 2278 | | +--rw rip:metric? rip-metric 2279 | +--rw rip:update-interval? uint8 2280 +--rw ribs 2281 +--rw rib* [name] 2282 +--rw name string 2283 +--rw address-family? identityref 2284 +--rw description? string 2286 A.2. State Data 2288 +--ro routing-state 2289 +--ro router-id? yang:dotted-quad 2290 +--ro interfaces 2291 | +--ro interface* if:interface-state-ref 2292 +--ro routing-protocols 2293 | +--ro routing-protocol* [type name] 2294 | +--ro type identityref 2295 | +--ro name string 2296 +--ro ribs 2297 +--ro rib* [name] 2298 +--ro name string 2299 +--ro address-family identityref 2300 +--ro default-rib? boolean {multiple-ribs}? 2301 +--ro routes 2302 +--ro route* 2303 +--ro route-preference? route-preference 2304 +--ro next-hop 2305 | +--ro (next-hop-options) 2306 | +--:(outgoing-interface) 2307 | | +--ro outgoing-interface? if:interface-state-ref 2308 | +--:(special-next-hop) 2309 | | +--ro special-next-hop? enumeration 2310 | +--:(v6ur:next-hop-address) 2311 | | +--ro v6ur:next-hop-address? inet:ipv6-address 2312 | +--:(v4ur:next-hop-address) 2313 | +--ro v4ur:next-hop-address? inet:ipv4-address 2314 +--ro source-protocol identityref 2315 +--ro active? empty 2316 +--ro last-updated? yang:date-and-time 2317 +--ro v6ur:destination-prefix? inet:ipv6-prefix 2318 +--ro rip:metric? rip-metric 2319 +--ro rip:tag? uint16 2320 +--ro v4ur:destination-prefix? inet:ipv4-prefix 2322 Appendix B. Minimum Implementation 2324 Some parts and options of the core routing model, such as user- 2325 defined RIBs, are intended only for advanced routers. This appendix 2326 gives basic non-normative guidelines for implementing a bare minimum 2327 of available functions. Such an implementation may be used for hosts 2328 or very simple routers. 2330 A minimum implementation does not support the feature "multiple- 2331 ribs". This means that a single system-controlled RIB is available 2332 for each supported address family - IPv4, IPv6 or both. These RIBs 2333 are also the default RIBs. No user-controlled RIBs are allowed. 2335 In addition to the mandatory instance of the "direct" pseudo- 2336 protocol, a minimum implementation should support configuring 2337 instance(s) of the "static" pseudo-protocol. 2339 Platforms with severely constrained resources may use deviations for 2340 restricting the data model, e.g., limiting the number of "static" 2341 routing protocol instances. 2343 Appendix C. Example: Adding a New Routing Protocol 2345 This appendix demonstrates how the core routing data model can be 2346 extended to support a new routing protocol. The YANG module 2347 "example-rip" shown below is intended as an illustration rather than 2348 a real definition of a data model for the RIP routing protocol. For 2349 the sake of brevity, this module does not obey all the guidelines 2350 specified in [RFC6087]. See also Section 5.3.2. 2352 module example-rip { 2354 namespace "http://example.com/rip"; 2356 prefix "rip"; 2358 import ietf-interfaces { 2359 prefix "if"; 2360 } 2362 import ietf-routing { 2363 prefix "rt"; 2364 } 2366 identity rip { 2367 base rt:routing-protocol; 2368 description 2369 "Identity for the RIP routing protocol."; 2370 } 2372 typedef rip-metric { 2373 type uint8 { 2374 range "0..16"; 2375 } 2376 } 2378 grouping route-content { 2379 description 2380 "This grouping defines RIP-specific route attributes."; 2381 leaf metric { 2382 type rip-metric; 2384 } 2385 leaf tag { 2386 type uint16; 2387 default "0"; 2388 description 2389 "This leaf may be used to carry additional info, e.g. AS 2390 number."; 2391 } 2392 } 2394 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 2395 when "rt:source-protocol = 'rip:rip'" { 2396 description 2397 "This augment is only valid for a routes whose source 2398 protocol is RIP."; 2399 } 2400 description 2401 "RIP-specific route attributes."; 2402 uses route-content; 2403 } 2405 augment "/rt:fib-route/rt:output/rt:route" { 2406 description 2407 "RIP-specific route attributes in the output of 'active-route' 2408 RPC."; 2409 uses route-content; 2410 } 2412 augment "/rt:routing/rt:routing-protocols/rt:routing-protocol" { 2413 when "rt:type = 'rip:rip'" { 2414 description 2415 "This augment is only valid for a routing protocol instance 2416 of type 'rip'."; 2417 } 2418 container rip { 2419 presence "RIP configuration"; 2420 description 2421 "RIP instance configuration."; 2422 container interfaces { 2423 description 2424 "Per-interface RIP configuration."; 2425 list interface { 2426 key "name"; 2427 description 2428 "RIP is enabled on interfaces that have an entry in this 2429 list, unless 'enabled' is set to 'false' for that 2430 entry."; 2431 leaf name { 2432 type if:interface-ref; 2433 } 2434 leaf enabled { 2435 type boolean; 2436 default "true"; 2437 } 2438 leaf metric { 2439 type rip-metric; 2440 default "1"; 2441 } 2442 } 2443 } 2444 leaf update-interval { 2445 type uint8 { 2446 range "10..60"; 2447 } 2448 units "seconds"; 2449 default "30"; 2450 description 2451 "Time interval between periodic updates."; 2452 } 2453 } 2454 } 2455 } 2457 Appendix D. Example: NETCONF Reply 2459 This section contains a sample reply to the NETCONF message, 2460 which could be sent by a server supporting (i.e., advertising them in 2461 the NETCONF message) the following YANG modules: 2463 o ietf-interfaces [RFC7223], 2465 o iana-if-type [RFC7224], 2467 o ietf-ip [RFC7277], 2469 o ietf-routing (Section 7), 2471 o ietf-ipv4-unicast-routing (Section 8), 2473 o ietf-ipv6-unicast-routing (Section 9). 2475 We assume a simple network set-up as shown in Figure 3: router "A" 2476 uses static default routes with the "ISP" router as the next-hop. 2477 IPv6 router advertisements are configured only on the "eth1" 2478 interface and disabled on the upstream "eth0" interface. 2480 +-----------------+ 2481 | | 2482 | Router ISP | 2483 | | 2484 +--------+--------+ 2485 |2001:db8:0:1::2 2486 |192.0.2.2 2487 | 2488 | 2489 |2001:db8:0:1::1 2490 eth0|192.0.2.1 2491 +--------+--------+ 2492 | | 2493 | Router A | 2494 | | 2495 +--------+--------+ 2496 eth1|198.51.100.1 2497 |2001:db8:0:2::1 2498 | 2500 Figure 3: Example network configuration 2502 A reply to the NETCONF message sent by router "A" would then be 2503 as follows: 2505 2506 2515 2516 2517 2518 eth0 2519 ianaift:ethernetCsmacd 2520 2521 Uplink to ISP. 2522 2523 2524 2525 192.0.2.1 2526 24 2527 2528 true 2529 2530 2531 2532 2001:0db8:0:1::1 2533 64 2534 2535 true 2536 2537 false 2538 2539 2540 2541 2542 eth1 2543 ianaift:ethernetCsmacd 2544 2545 Interface to the internal network. 2546 2547 2548 2549 198.51.100.1 2550 24 2551 2552 true 2553 2554 2555 2556 2001:0db8:0:2::1 2557 64 2558 2559 true 2560 2561 false 2562 2563 2564 true 2565 2566 2567 2568 2569 2570 2571 eth0 2572 ianaift:ethernetCsmacd 2573 00:0C:42:E5:B1:E9 2574 up 2575 2576 2015-10-24T17:11:27+02:00 2577 2578 2579 true 2580 1500 2581 2582 192.0.2.1 2583 24 2584 2585 2586 2587 true 2588 1500 2589 2590 2001:0db8:0:1::1 2591 64 2592 2593 2594 true 2595 2596 2597 2001:db8:0:2::/64 2598 2599 2600 2601 2602 2603 2604 eth1 2605 ianaift:ethernetCsmacd 2606 00:0C:42:E5:B1:EA 2607 up 2608 2609 2015-10-24T17:11:29+02:00 2610 2611 2612 true 2613 1500 2614 2615 198.51.100.1 2616 24 2617 2618 2619 2620 true 2621 1500 2622 2623 2001:0db8:0:2::1 2624 64 2625 2626 2627 true 2628 2629 2630 2001:db8:0:2::/64 2631 2632 2633 2634 2635 2636 2637 2638 192.0.2.1 2639 2640 2641 rt:static 2642 st0 2643 2644 Static routing is used for the internal network. 2645 2646 2647 2648 2649 0.0.0.0/0 2650 2651 192.0.2.2 2652 2653 2654 2655 2656 2657 ::/0 2658 2659 2001:db8:0:1::2 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 eth0 2670 eth1 2671 2672 2673 2674 rt:static 2675 st0 2676 2677 2678 2679 2680 ipv4-master 2681 v4ur:ipv4-unicast 2682 true 2683 2684 2685 192.0.2.1/24 2686 2687 eth0 2688 2689 0 2690 rt:direct 2691 2015-10-24T17:11:27+02:00 2692 2693 2694 198.51.100.0/24 2695 2696 eth1 2697 2698 rt:direct 2699 0 2700 2015-10-24T17:11:27+02:00 2701 2702 2703 0.0.0.0/0 2704 rt:static 2705 5 2706 2707 192.0.2.2 2708 2709 2015-10-24T18:02:45+02:00 2710 2711 2712 2713 2714 ipv6-master 2715 v6ur:ipv6-unicast 2716 true 2717 2718 2719 2001:db8:0:1::/64 2720 2721 eth0 2722 2723 rt:direct 2724 0 2725 2015-10-24T17:11:27+02:00 2726 2727 2728 2001:db8:0:2::/64 2729 2730 eth1 2731 2732 rt:direct 2733 0 2734 2015-10-24T17:11:27+02:00 2735 2736 2737 ::/0 2738 2739 2001:db8:0:1::2 2740 2741 rt:static 2742 5 2743 2015-10-24T18:02:45+02:00 2744 2745 2746 2747 2748 2749 2750 2752 2753 2754 2756 Appendix E. Change Log 2758 RFC Editor: Remove this section upon publication as an RFC. 2760 E.1. Changes Between Versions -20 and -21 2762 o Routing instances were removed. 2764 o IPv6 RA parameters were moved to the "ietf-ipv6-router- 2765 advertisements". 2767 E.2. Changes Between Versions -19 and -20 2769 o Assignment of L3 interfaces to routing instances is now part of 2770 interface configuration. 2772 o Next-hop options in configuration were aligned with state data. 2774 o It is recommended to enclose protocol-specific configuration in a 2775 presence container. 2777 E.3. Changes Between Versions -18 and -19 2779 o The leaf "route-preference" was removed from the "routing- 2780 protocol" container in both "routing" and "routing-state". 2782 o The "vrf-routing-instance" identity was added in support of a 2783 common routing-instance type in addition to the "default-routing- 2784 instance". 2786 o Removed "enabled" switch from "routing-protocol". 2788 E.4. Changes Between Versions -17 and -18 2790 o The container "ribs" was moved under "routing-instance" (in both 2791 "routing" and "routing-state"). 2793 o Typedefs "rib-ref" and "rib-state-ref" were removed. 2795 o Removed "recipient-ribs" (both state and configuration). 2797 o Removed "connected-ribs" from "routing-protocol" (both state and 2798 configuration). 2800 o Configuration and state data for IPv6 RA were moved under 2801 "if:interface" and "if:interface-state". 2803 o Assignment of interfaces to routing instances now use leaf-list 2804 rather than list (both config and state). The opposite reference 2805 from "if:interface" to "rt:routing-instance" was changed to a 2806 single leaf (an interface cannot belong to multiple routing 2807 instances). 2809 o Specification of a default RIB is now a simple flag under "rib" 2810 (both config and state). 2812 o Default RIBs are marked by a flag in state data. 2814 E.5. Changes Between Versions -16 and -17 2816 o Added Acee as a co-author. 2818 o Removed all traces of route filters. 2820 o Removed numeric IDs of list entries in state data. 2822 o Removed all next-hop cases except "simple-next-hop" and "special- 2823 next-hop". 2825 o Removed feature "multipath-routes". 2827 o Augmented "ietf-interfaces" module with a leaf-list of leafrefs 2828 pointing form state data of an interface entry to the routing 2829 instance(s) to which the interface is assigned. 2831 E.6. Changes Between Versions -15 and -16 2833 o Added 'type' as the second key component of 'routing-protocol', 2834 both in configuration and state data. 2836 o The restriction of no more than one connected RIB per address 2837 family was removed. 2839 o Removed the 'id' key of routes in RIBs. This list has no keys 2840 anymore. 2842 o Remove the 'id' key from static routes and make 'destination- 2843 prefix' the only key. 2845 o Added 'route-preference' as a new attribute of routes in RIB. 2847 o Added 'active' as a new attribute of routes in RIBs. 2849 o Renamed RPC operation 'active-route' to 'fib-route'. 2851 o Added 'route-preference' as a new parameter of routing protocol 2852 instances, both in configuration and state data. 2854 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 2855 routing-instance'. 2857 o Added next-hop lists to state data. 2859 o Added two cases for specifying next-hops indirectly - via a new 2860 RIB or a recursive list of next-hops. 2862 o Reorganized next-hop in static routes. 2864 o Removed all 'if-feature' statements from state data. 2866 E.7. Changes Between Versions -14 and -15 2868 o Removed all defaults from state data. 2870 o Removed default from 'cur-hop-limit' in config. 2872 E.8. Changes Between Versions -13 and -14 2874 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 2875 feature. 2877 o Removed default value of 'cur-hop-limit' in state data. 2879 o Moved parts of descriptions and all references on IPv6 RA 2880 parameters from state data to configuration. 2882 o Added reference to RFC 6536 in the Security section. 2884 E.9. Changes Between Versions -12 and -13 2886 o Wrote appendix about minimum implementation. 2888 o Remove "when" statement for IPv6 router interface state data - it 2889 was dependent on a config value that may not be present. 2891 o Extra container for the next-hop list. 2893 o Names rather than numeric ids are used for referring to list 2894 entries in state data. 2896 o Numeric ids are always declared as mandatory and unique. Their 2897 description states that they are ephemeral. 2899 o Descriptions of "name" keys in state data lists are required to be 2900 persistent. 2902 o 2904 o Removed "if-feature multiple-ribs;" from connected-ribs. 2906 o "rib-name" instead of "name" is used as the name of leafref nodes. 2908 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 2909 in node names and text. 2911 E.10. Changes Between Versions -11 and -12 2913 o Removed feature "advanced-router" and introduced two features 2914 instead: "multiple-ribs" and "multipath-routes". 2916 o Unified the keys of config and state versions of "routing- 2917 instance" and "rib" lists. 2919 o Numerical identifiers of state list entries are not keys anymore, 2920 but they are constrained using the "unique" statement. 2922 o Updated acknowledgements. 2924 E.11. Changes Between Versions -10 and -11 2926 o Migrated address families from IANA enumerations to identities. 2928 o Terminology and node names aligned with the I2RS RIB model: router 2929 -> routing instance, routing table -> RIB. 2931 o Introduced uint64 keys for state lists: routing-instance, rib, 2932 route, nexthop. 2934 o Described the relationship between system-controlled and user- 2935 controlled list entries. 2937 o Feature "user-defined-routing-tables" changed into "advanced- 2938 router". 2940 o Made nexthop into a choice in order to allow for nexthop-list 2941 (I2RS requirement). 2943 o Added nexthop-list with entries having priorities (backup) and 2944 weights (load balancing). 2946 o Updated bibliography references. 2948 E.12. Changes Between Versions -09 and -10 2950 o Added subtree for state data ("/routing-state"). 2952 o Terms "system-controlled entry" and "user-controlled entry" 2953 defined and used. 2955 o New feature "user-defined-routing-tables". Nodes that are useful 2956 only with user-defined routing tables are now conditional. 2958 o Added grouping "router-id". 2960 o In routing tables, "source-protocol" attribute of routes now 2961 reports only protocol type, and its datatype is "identityref". 2963 o Renamed "main-routing-table" to "default-routing-table". 2965 E.13. Changes Between Versions -08 and -09 2967 o Fixed "must" expression for "connected-routing-table". 2969 o Simplified "must" expression for "main-routing-table". 2971 o Moved per-interface configuration of a new routing protocol under 2972 'routing-protocol'. This also affects the 'example-rip' module. 2974 E.14. Changes Between Versions -07 and -08 2976 o Changed reference from RFC6021 to RFC6021bis. 2978 E.15. Changes Between Versions -06 and -07 2980 o The contents of in Appendix D was updated: "eth[01]" 2981 is used as the value of "location", and "forwarding" is on for 2982 both interfaces and both IPv4 and IPv6. 2984 o The "must" expression for "main-routing-table" was modified to 2985 avoid redundant error messages reporting address family mismatch 2986 when "name" points to a non-existent routing table. 2988 o The default behavior for IPv6 RA prefix advertisements was 2989 clarified. 2991 o Changed type of "rt:router-id" to "ip:dotted-quad". 2993 o Type of "rt:router-id" changed to "yang:dotted-quad". 2995 o Fixed missing prefixes in XPath expressions. 2997 E.16. Changes Between Versions -05 and -06 2999 o Document title changed: "Configuration" was replaced by 3000 "Management". 3002 o New typedefs "routing-table-ref" and "route-filter-ref". 3004 o Double slashes "//" were removed from XPath expressions and 3005 replaced with the single "/". 3007 o Removed uniqueness requirement for "router-id". 3009 o Complete data tree is now in Appendix A. 3011 o Changed type of "source-protocol" from "leafref" to "string". 3013 o Clarified the relationship between routing protocol instances and 3014 connected routing tables. 3016 o Added a must constraint saying that a routing table connected to 3017 the direct pseudo-protocol must not be a main routing table. 3019 E.17. Changes Between Versions -04 and -05 3021 o Routing tables are now global, i.e., "routing-tables" is a child 3022 of "routing" rather than "router". 3024 o "must" statement for "static-routes" changed to "when". 3026 o Added "main-routing-tables" containing references to main routing 3027 tables for each address family. 3029 o Removed the defaults for "address-family" and "safi" and made them 3030 mandatory. 3032 o Removed the default for route-filter/type and made this leaf 3033 mandatory. 3035 o If there is no active route for a given destination, the "active- 3036 route" RPC returns no output. 3038 o Added "enabled" switch under "routing-protocol". 3040 o Added "router-type" identity and "type" leaf under "router". 3042 o Route attribute "age" changed to "last-updated", its type is 3043 "yang:date-and-time". 3045 o The "direct" pseudo-protocol is always connected to main routing 3046 tables. 3048 o Entries in the list of connected routing tables renamed from 3049 "routing-table" to "connected-routing-table". 3051 o Added "must" constraint saying that a routing table must not be 3052 its own recipient. 3054 E.18. Changes Between Versions -03 and -04 3056 o Changed "error-tag" for both RPC operations from "missing element" 3057 to "data-missing". 3059 o Removed the decrementing behavior for advertised IPv6 prefix 3060 parameters "valid-lifetime" and "preferred-lifetime". 3062 o Changed the key of the static route lists from "seqno" to "id" 3063 because the routes needn't be sorted. 3065 o Added 'must' constraint saying that "preferred-lifetime" must not 3066 be greater than "valid-lifetime". 3068 E.19. Changes Between Versions -02 and -03 3070 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3072 o Removed forwarding table. 3074 o RPC "get-route" changed to "active-route". Its output is a list 3075 of routes (for multi-path routing). 3077 o New RPC "route-count". 3079 o For both RPCs, specification of negative responses was added. 3081 o Relaxed separation of router instances. 3083 o Assignment of interfaces to router instances needn't be disjoint. 3085 o Route filters are now global. 3087 o Added "allow-all-route-filter" for symmetry. 3089 o Added Section 6 about interactions with "ietf-interfaces" and 3090 "ietf-ip". 3092 o Added "router-id" leaf. 3094 o Specified the names for IPv4/IPv6 unicast main routing tables. 3096 o Route parameter "last-modified" changed to "age". 3098 o Added container "recipient-routing-tables". 3100 E.20. Changes Between Versions -01 and -02 3102 o Added module "ietf-ipv6-unicast-routing". 3104 o The example in Appendix D now uses IP addresses from blocks 3105 reserved for documentation. 3107 o Direct routes appear by default in the forwarding table. 3109 o Network layer interfaces must be assigned to a router instance. 3110 Additional interface configuration may be present. 3112 o The "when" statement is only used with "augment", "must" is used 3113 elsewhere. 3115 o Additional "must" statements were added. 3117 o The "route-content" grouping for IPv4 and IPv6 unicast now 3118 includes the material from the "ietf-routing" version via "uses 3119 rt:route-content". 3121 o Explanation of symbols in the tree representation of data model 3122 hierarchy. 3124 E.21. Changes Between Versions -00 and -01 3126 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3128 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3129 safi" module. 3131 o Names of some data nodes were changed, in particular "routing- 3132 process" is now "router". 3134 o The restriction of a single AFN/SAFI per router was lifted. 3136 o RPC operation "delete-route" was removed. 3138 o Illegal XPath references from "get-route" to the datastore were 3139 fixed. 3141 o Section "Security Considerations" was written. 3143 Authors' Addresses 3144 Ladislav Lhotka 3145 CZ.NIC 3147 Email: lhotka@nic.cz 3149 Acee Lindem 3150 Cisco Systems 3152 Email: acee@cisco.com