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