idnits 2.17.1 draft-ietf-netmod-routing-cfg-20.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 2353 has weird spacing: '...-prefix inet:...' == Line 2365 has weird spacing: '...-prefix inet:...' == Line 2391 has weird spacing: '...ro type ide...' == Line 2392 has weird spacing: '...ro name str...' == Line 2396 has weird spacing: '...-family ide...' -- The document date (October 16, 2015) is 3112 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 2313, 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 (~~), 7 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: April 18, 2016 Cisco Systems 6 October 16, 2015 8 A YANG Data Model for Routing Management 9 draft-ietf-netmod-routing-cfg-20 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 April 18, 2016. 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 . . . . . . . . . . . . . . . . . . . . 8 66 5.1.1. Parameters of IPv6 Router Interfaces . . . . . . . . 9 67 5.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.3. Routing Information Base (RIB) . . . . . . . . . . . . . 11 69 5.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 11 70 5.4.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 12 71 5.4.2. Defining New Routing Protocols . . . . . . . . . . . 12 72 5.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 13 73 6. Interactions with Other YANG Modules . . . . . . . . . . . . 13 74 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 13 75 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 13 76 7. Routing Management YANG Module . . . . . . . . . . . . . . . 14 77 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 29 78 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 33 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 81 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 48 84 13.2. Informative References . . . . . . . . . . . . . . . . . 49 85 Appendix A. The Complete Data Trees . . . . . . . . . . . . . . 49 86 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 49 87 A.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 50 88 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 51 89 Appendix C. Example: Adding a New Routing Protocol . . . . . . . 52 90 Appendix D. Example: NETCONF Reply . . . . . . . . . . . . 54 91 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 61 92 E.1. Changes Between Versions -19 and -20 . . . . . . . . . . 61 93 E.2. Changes Between Versions -18 and -19 . . . . . . . . . . 61 94 E.3. Changes Between Versions -17 and -18 . . . . . . . . . . 61 95 E.4. Changes Between Versions -16 and -17 . . . . . . . . . . 62 96 E.5. Changes Between Versions -15 and -16 . . . . . . . . . . 62 97 E.6. Changes Between Versions -14 and -15 . . . . . . . . . . 63 98 E.7. Changes Between Versions -13 and -14 . . . . . . . . . . 63 99 E.8. Changes Between Versions -12 and -13 . . . . . . . . . . 63 100 E.9. Changes Between Versions -11 and -12 . . . . . . . . . . 64 101 E.10. Changes Between Versions -10 and -11 . . . . . . . . . . 64 102 E.11. Changes Between Versions -09 and -10 . . . . . . . . . . 65 103 E.12. Changes Between Versions -08 and -09 . . . . . . . . . . 65 104 E.13. Changes Between Versions -07 and -08 . . . . . . . . . . 65 105 E.14. Changes Between Versions -06 and -07 . . . . . . . . . . 65 106 E.15. Changes Between Versions -05 and -06 . . . . . . . . . . 66 107 E.16. Changes Between Versions -04 and -05 . . . . . . . . . . 66 108 E.17. Changes Between Versions -03 and -04 . . . . . . . . . . 67 109 E.18. Changes Between Versions -02 and -03 . . . . . . . . . . 67 110 E.19. Changes Between Versions -01 and -02 . . . . . . . . . . 68 111 E.20. Changes Between Versions -00 and -01 . . . . . . . . . . 68 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 114 1. Introduction 116 This document contains a specification of the following YANG modules: 118 o Module "ietf-routing" provides generic components of a routing 119 data model. 121 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 122 module with additional data specific to IPv4 unicast. 124 o Module "ietf-ipv6-unicast-routing" augments the "ietf-routing" 125 module with additional data specific to IPv6 unicast. It also 126 augments the "ietf-interfaces" module [RFC7223] with IPv6 router 127 configuration variables required by [RFC4861]. 129 These modules together define the so-called core routing data model, 130 which is intended as a basis for future data model development 131 covering more sophisticated routing systems. While these three 132 modules can be directly used for simple IP devices with static 133 routing (see Appendix B), their main purpose is to provide essential 134 building blocks for more complicated data models involving multiple 135 routing protocols, multicast routing, additional address families, 136 and advanced functions such as route filtering or policy routing. To 137 this end, it is expected that the core routing data model will be 138 augmented by numerous modules developed by other IETF working groups. 140 2. Terminology and Notation 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 The following terms are defined in [RFC6241]: 148 o client, 150 o message, 152 o protocol operation, 154 o server. 156 The following terms are defined in [RFC6020]: 158 o augment, 160 o configuration data, 162 o container, 164 o container with presence, 166 o data model, 168 o data node, 170 o feature, 172 o leaf, 174 o list, 176 o mandatory node, 178 o module, 180 o schema tree, 182 o state data, 184 o RPC operation. 186 2.1. Glossary of New Terms 188 core routing data model: YANG data model comprising "ietf-routing", 189 "ietf-ipv4-unicast-routing" and "ietf-ipv6-unicast-routing" 190 modules. 192 direct route: a route to a directly connected network. 194 routing information base (RIB): An object containing a list of 195 routes together with other information. See Section 5.3 for 196 details. 198 system-controlled entry: An entry of a list in state data ("config 199 false") that is created by the system independently of what has 200 been explicitly configured. See Section 4.1 for details. 202 user-controlled entry: An entry of a list in state data ("config 203 false") that is created and deleted as a direct consequence of 204 certain configuration changes. See Section 4.1 for details. 206 2.2. Tree Diagrams 208 A simplified graphical representation of the complete data tree is 209 presented in Appendix A, and similar diagrams of its various subtrees 210 appear in the main text. 212 o Brackets "[" and "]" enclose list keys. 214 o Curly braces "{" and "}" contain names of optional features that 215 make the corresponding node conditional. 217 o Abbreviations before data node names: "rw" means configuration 218 (read-write), "ro" state data (read-only), "-x" RPC operations, 219 and "-n" notifications. 221 o Symbols after data node names: "?" means an optional node, "!" a 222 container with presence, and "*" denotes a "list" or "leaf-list". 224 o Parentheses enclose choice and case nodes, and case nodes are also 225 marked with a colon (":"). 227 o Ellipsis ("...") stands for contents of subtrees that are not 228 shown. 230 2.3. Prefixes in Data Node Names 232 In this document, names of data nodes, RPC operations and other data 233 model objects are often used without a prefix, as long as it is clear 234 from the context in which YANG module each name is defined. 235 Otherwise, names are prefixed using the standard prefix associated 236 with the corresponding YANG module, as shown in Table 1. 238 +--------+---------------------------+-----------+ 239 | Prefix | YANG module | Reference | 240 +--------+---------------------------+-----------+ 241 | if | ietf-interfaces | [RFC7223] | 242 | ip | ietf-ip | [RFC7277] | 243 | rt | ietf-routing | Section 7 | 244 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 245 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 246 | yang | ietf-yang-types | [RFC6991] | 247 | inet | ietf-inet-types | [RFC6991] | 248 +--------+---------------------------+-----------+ 250 Table 1: Prefixes and corresponding YANG modules 252 3. Objectives 254 The initial design of the core routing data model was driven by the 255 following objectives: 257 o The data model should be suitable for the common address families, 258 in particular IPv4 and IPv6, and for unicast and multicast 259 routing, as well as Multiprotocol Label Switching (MPLS). 261 o A simple IP routing system, such as one that uses only static 262 routing, should be configurable in a simple way, ideally without 263 any need to develop additional YANG modules. 265 o On the other hand, the core routing framework must allow for 266 complicated implementations involving multiple routing information 267 bases (RIB) and multiple routing protocols, as well as controlled 268 redistributions of routing information. 270 o Device vendors will want to map the data models built on this 271 generic framework to their proprietary data models and 272 configuration interfaces. Therefore, the framework should be 273 flexible enough to facilitate such a mapping and accommodate data 274 models with different logic. 276 4. The Design of the Core Routing Data Model 278 The core routing data model consists of three YANG modules. The 279 first module, "ietf-routing", defines the generic components of a 280 routing system. The other two modules, "ietf-ipv4-unicast-routing" 281 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 282 with additional data nodes that are needed for IPv4 and IPv6 unicast 283 routing, respectively. Figures 1 and 2 show abridged views of the 284 configuration and state data hierarchies. See Appendix A for the 285 complete data trees. 287 +--rw routing 288 +--rw routing-instance* [name] 289 +--rw name 290 +--rw type? 291 +--rw enabled? 292 +--rw router-id? 293 +--rw description? 294 +--rw routing-protocols 295 | +--rw routing-protocol* [type name] 296 | +--rw type 297 | +--rw name 298 | +--rw description? 299 | +--rw static-routes 300 | ... 301 +--rw ribs 302 +--rw rib* [name] 303 +--rw name 304 +--rw address-family? 305 +--rw description? 307 Figure 1: Configuration data hierarchy. 309 +--ro routing-state 310 +--ro routing-instance* [name] 311 +--ro name 312 +--ro type? 313 +--ro router-id? 314 +--ro interfaces 315 | +--ro interface* 316 +--ro routing-protocols 317 | +--ro routing-protocol* [type name] 318 | +--ro type 319 | +--ro name 320 +--ro ribs 321 +--ro rib* [name] 322 +--ro name 323 +--ro address-family 324 +--ro default-rib? 325 +--ro routes 326 ... 328 Figure 2: State data hierarchy. 330 As can be seen from Figures 1 and 2, the core routing data model 331 introduces several generic components of a routing framework: routing 332 instances, RIBs containing lists of routes, and routing protocols. 333 Section 5 describes these components in more detail. 335 4.1. System-Controlled and User-Controlled List Entries 337 The core routing data model defines several lists in the schema tree, 338 for example "routing-instance" or "rib", that have to be populated 339 with at least one entry in any properly functioning device, and 340 additional entries may be configured by a client. 342 In such a list, the server creates the required item as a so-called 343 system-controlled entry in state data, i.e., inside the "routing- 344 state" container. 346 Additional entries may be created in the configuration by a client, 347 e.g., via the NETCONF protocol. These are so-called user-controlled 348 entries. If the server accepts a configured user-controlled entry, 349 then this entry also appears in the state data version of the list. 351 Corresponding entries in both versions of the list (in state data and 352 configuration) have the same value of the list key. 354 A client may also provide supplemental configuration of system- 355 controlled entries. To do so, the client creates a new entry in the 356 configuration with the desired contents. In order to bind this entry 357 to the corresponding entry in the state data list, the key of the 358 configuration entry has to be set to the same value as the key of the 359 state entry. 361 An example can be seen in Appendix D: the "/routing-state/routing- 362 instance" list has a single system-controlled entry whose "name" key 363 has the value "rtr0". This entry is configured by the "/routing/ 364 routing-instance" entry whose "name" key is also "rtr0". 366 Deleting a user-controlled entry from the configuration list results 367 in the removal of the corresponding entry in the state data list. In 368 contrast, if a system-controlled entry is deleted from the 369 configuration list, only the extra configuration specified in that 370 entry is removed but the corresponding state data entry remains in 371 the list. 373 5. Basic Building Blocks 375 This section describes the essential components of the core routing 376 data model. 378 5.1. Routing Instance 380 The core routing data model supports one or more routing instances 381 appearing as entries of the "routing-instance" list. Each routing 382 instance has separate configuration and state data under 383 "/rt:routing/rt:routing-instance" and "/rt:routing-state/rt:routing- 384 instance", respectively. 386 No attempt has been made to define the semantics for every type of 387 routing instance. The core routing data model defines identities for 388 two ubiquitous routing instance types: 390 o "default-routing-instance" - this routing instance type represents 391 the default (or only) routing instance. All implementations MUST 392 provide one and only one system-controlled routing instance of 393 this type. 395 o "vrf-routing-instance" - this routing instance type represents VRF 396 (virtual routing and forwarding) routing instances that are used 397 for virtual private networks (VPN) including BGP/MPLS 398 VPN_[RFC4364]. 400 It is expected that future YANG modules will define other types of 401 routing instances. For every such type, an identity derived from 402 "rt:routing-instance" SHALL be defined. This identity is then 403 referred to by the value of the "type" leaf (a child node of 404 "routing-instance" list). 406 By default, all network layer interfaces are assigned to the routing 407 instance of the "default-routing-instance" type. This can be changed 408 by configuring the "rt:routing-instance" leaf in the interface 409 configuration. 411 5.1.1. Parameters of IPv6 Router Interfaces 413 YANG module "ietf-ipv6-unicast-routing" (Section 9) augments the 414 configuration and state data of IPv6 interfaces with definitions of 415 the following variables as required by [RFC4861], sec. 6.2.1: 417 o send-advertisements, 419 o max-rtr-adv-interval, 421 o min-rtr-adv-interval, 423 o managed-flag, 425 o other-config-flag, 427 o link-mtu, 429 o reachable-time, 430 o retrans-timer, 432 o cur-hop-limit, 434 o default-lifetime, 436 o prefix-list: a list of prefixes to be advertised. 438 The following parameters are associated with each prefix in the 439 list: 441 * valid-lifetime, 443 * on-link-flag, 445 * preferred-lifetime, 447 * autonomous-flag. 449 NOTES: 451 1. The "IsRouter" flag, which is also required by [RFC4861], is 452 implemented in the "ietf-ip" module [RFC7277] (leaf 453 "ip:forwarding"). 455 2. The original specification [RFC4861] allows the implementations 456 to decide whether the "valid-lifetime" and "preferred-lifetime" 457 parameters remain the same in consecutive advertisements, or 458 decrement in real time. However, the latter behavior seems 459 problematic because the values might be reset again to the 460 (higher) configured values after a configuration is reloaded. 461 Moreover, no implementation is known to use the decrementing 462 behavior. The "ietf-ipv6-unicast-routing" module therefore 463 assumes the former behavior with constant values. 465 5.2. Route 467 Routes are basic elements of information in a routing system. The 468 core routing data model defines only the following minimal set of 469 route attributes: 471 o "destination-prefix": IP prefix specifying the set of destination 472 addresses for which the route may be used. This attribute is 473 mandatory. 475 o "route-preference": an integer value (also known as administrative 476 distance) that is used for selecting a preferred route among 477 routes with the same destination prefix. A lower value means a 478 more preferred route. 480 o "next-hop": determines the action to be performed with a packet. 482 Routes are primarily state data that appear as entries of RIBs 483 (Section 5.3) but they may also be found in configuration data, for 484 example as manually configured static routes. In the latter case, 485 configurable route attributes are generally a subset of route 486 attributes described above. 488 5.3. Routing Information Base (RIB) 490 Every routing instance manages one or more routing information bases 491 (RIB). A RIB is a list of routes complemented with administrative 492 data. Each RIB contains only routes of one address family. An 493 address family is represented by an identity derived from the 494 "rt:address-family" base identity. 496 In the core routing data model, RIBs are state data represented as 497 entries of the list "/routing-state/routing-instance/ribs/rib". The 498 contents of RIBs are controlled and manipulated by routing protocol 499 operations which may result in route additions, removals and 500 modifications. This also includes manipulations via the "static" 501 and/or "direct" pseudo-protocols, see Section 5.4.1. 503 Each routing instance has, for every supported address family, one 504 RIB marked as the so-called default RIB. Its role is explained in 505 Section 5.4. 507 Simple router implementations that do not advertise the feature 508 "multiple-ribs" will typically create one system-controlled RIB per 509 routing instance and supported address family, and mark it as the 510 default RIB. 512 More complex router implementations advertising the "multiple-ribs" 513 feature support multiple RIBs per address family that can be used for 514 policy routing and other purposes. 516 5.4. Routing Protocol 518 The core routing data model provides an open-ended framework for 519 defining multiple routing protocol instances within a routing 520 instance. Each routing protocol instance MUST be assigned a type, 521 which is an identity derived from the "rt:routing-protocol" base 522 identity. The core routing data model defines two identities for the 523 direct and static pseudo-protocols (Section 5.4.1). 525 Multiple routing protocol instances of the same type MAY be 526 configured within the same routing instance. 528 5.4.1. Routing Pseudo-Protocols 530 The core routing data model defines two special routing protocol 531 types - "direct" and "static". Both are in fact pseudo-protocols, 532 which means they are confined to the local device and do not exchange 533 any routing information with adjacent routers. 535 Every routing instance MUST implement exactly one instance of the 536 "direct" pseudo-protocol type. It is the source of direct routes for 537 all configured address families. Direct routes are normally supplied 538 by the operating system kernel, based on the configuration of network 539 interface addresses, see Section 6.2. Direct routes MUST be 540 installed in default RIBs of all supported address families. 542 A pseudo-protocol of the type "static" allows for specifying routes 543 manually. It MAY be configured in zero or multiple instances, 544 although a typical configuration will have exactly one instance per 545 routing instance. 547 5.4.2. Defining New Routing Protocols 549 It is expected that future YANG modules will create data models for 550 additional routing protocol types. Such a new module has to define 551 the protocol-specific configuration and state data, and it has to fit 552 it into the core routing framework in the following way: 554 o A new identity MUST be defined for the routing protocol and its 555 base identity MUST be set to "rt:routing-protocol", or to an 556 identity derived from "rt:routing-protocol". 558 o Additional route attributes MAY be defined, preferably in one 559 place by means of defining a YANG grouping. The new attributes 560 have to be inserted by augmenting the definitions of the nodes 562 /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 564 and 566 /rt:fib-route/rt:output/rt:route, 568 and possibly other places in the configuration, state data, 569 notifications, and RPC input or output. 571 o Configuration parameters and/or state data for the new protocol 572 can be defined by augmenting the "routing-protocol" data node 573 under both "/routing" and "/routing-state". 575 By using a "when" statement, the augmented configuration parameters 576 and state data specific to the new protocol SHOULD be made 577 conditional and valid only if the value of "rt:type" or "rt:source- 578 protocol" is equal to the new protocol's identity. 580 It is also RECOMMENDED that protocol-specific data nodes be 581 encapsulated in an appropriately named container with presence. Such 582 a container may contain mandatory data nodes that are otherwise 583 forbidden at the top level of an augment. 585 The above steps are implemented by the example YANG module for the 586 RIP routing protocol in Appendix C. 588 5.5. RPC Operations 590 The "ietf-routing" module defines one RPC operation: 592 o fib-route: query a routing instance for the active route in the 593 Forwarding Information Base (FIB). It is the route that is 594 currently used for sending datagrams to a destination host whose 595 address is passed as an input parameter. 597 6. Interactions with Other YANG Modules 599 The semantics of the core routing data model also depends on several 600 configuration parameters that are defined in other YANG modules. 602 6.1. Module "ietf-interfaces" 604 The following boolean switch is defined in the "ietf-interfaces" YANG 605 module [RFC7223]: 607 /if:interfaces/if:interface/if:enabled 609 If this switch is set to "false" for a network layer interface, 610 then all routing and forwarding functions MUST be disabled on that 611 interface. 613 6.2. Module "ietf-ip" 615 The following boolean switches are defined in the "ietf-ip" YANG 616 module [RFC7277]: 618 /if:interfaces/if:interface/ip:ipv4/ip:enabled 619 If this switch is set to "false" for a network layer interface, 620 then all IPv4 routing and forwarding functions MUST be disabled on 621 that interface. 623 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 625 If this switch is set to "false" for a network layer interface, 626 then the forwarding of IPv4 datagrams through this interface MUST 627 be disabled. However, the interface MAY participate in other IPv4 628 routing functions, such as routing protocols. 630 /if:interfaces/if:interface/ip:ipv6/ip:enabled 632 If this switch is set to "false" for a network layer interface, 633 then all IPv6 routing and forwarding functions MUST be disabled on 634 that interface. 636 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 638 If this switch is set to "false" for a network layer interface, 639 then the forwarding of IPv6 datagrams through this interface MUST 640 be disabled. However, the interface MAY participate in other IPv6 641 routing functions, such as routing protocols. 643 In addition, the "ietf-ip" module allows for configuring IPv4 and 644 IPv6 addresses and network prefixes or masks on network layer 645 interfaces. Configuration of these parameters on an enabled 646 interface MUST result in an immediate creation of the corresponding 647 direct route. The destination prefix of this route is set according 648 to the configured IP address and network prefix/mask, and the 649 interface is set as the outgoing interface for that route. 651 7. Routing Management YANG Module 653 RFC Editor: In this section, replace all occurrences of 'XXXX' with 654 the actual RFC number and all occurrences of the revision date below 655 with the date of RFC publication (and remove this note). 657 file "ietf-routing@2015-10-16.yang" 659 module ietf-routing { 661 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 663 prefix "rt"; 665 import ietf-yang-types { 666 prefix "yang"; 668 } 670 import ietf-interfaces { 671 prefix "if"; 672 } 674 organization 675 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 677 contact 678 "WG Web: 679 WG List: 681 WG Chair: Thomas Nadeau 682 684 WG Chair: Juergen Schoenwaelder 685 687 WG Chair: Kent Watsen 688 690 Editor: Ladislav Lhotka 691 "; 693 description 694 "This YANG module defines essential components for the management 695 of a routing subsystem. 697 Copyright (c) 2015 IETF Trust and the persons identified as 698 authors of the code. All rights reserved. 700 Redistribution and use in source and binary forms, with or 701 without modification, is permitted pursuant to, and subject to 702 the license terms contained in, the Simplified BSD License set 703 forth in Section 4.c of the IETF Trust's Legal Provisions 704 Relating to IETF Documents 705 (http://trustee.ietf.org/license-info). 707 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 708 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 709 'OPTIONAL' in the module text are to be interpreted as described 710 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 712 This version of this YANG module is part of RFC XXXX 713 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 714 full legal notices."; 716 revision 2015-10-16 { 717 description 718 "Initial revision."; 719 reference 720 "RFC XXXX: A YANG Data Model for Routing Management"; 721 } 723 /* Features */ 725 feature multiple-ribs { 726 description 727 "This feature indicates that the server supports user-defined 728 RIBs. 730 Servers that do not advertise this feature SHOULD provide 731 exactly one system-controlled RIB per routing-instance and 732 supported address family and make them also the default RIBs. 733 These RIBs then appear as entries of the list 734 /routing-state/routing-instance/ribs/rib."; 735 } 737 feature router-id { 738 description 739 "This feature indicates that the server supports configuration 740 of an explicit 32-bit router ID that is used by some routing 741 protocols. 743 Servers that do not advertise this feature set a router ID 744 algorithmically, usually to one of configured IPv4 addresses. 745 However, this algorithm is implementation-specific."; 746 } 748 /* Identities */ 750 identity address-family { 751 description 752 "Base identity from which identities describing address 753 families are derived."; 754 } 756 identity ipv4 { 757 base address-family; 758 description 759 "This identity represents IPv4 address family."; 760 } 762 identity ipv6 { 763 base address-family; 764 description 765 "This identity represents IPv6 address family."; 766 } 768 identity routing-instance { 769 description 770 "Base identity from which identities describing routing 771 instance types are derived."; 772 } 774 identity default-routing-instance { 775 base routing-instance; 776 description 777 "This identity represents either a default routing instance, or 778 the only routing instance on systems that do not support 779 multiple instances."; 780 } 782 identity vrf-routing-instance { 783 base routing-instance; 784 description 785 "This identity represents a VRF routing instance. The type is 786 distinct from the default-routing-instance. There may be 787 multiple vrf-routing-interfaces."; 788 } 790 identity routing-protocol { 791 description 792 "Base identity from which routing protocol identities are 793 derived."; 794 } 796 identity direct { 797 base routing-protocol; 798 description 799 "Routing pseudo-protocol that provides routes to directly 800 connected networks."; 801 } 803 identity static { 804 base routing-protocol; 805 description 806 "Static routing pseudo-protocol."; 807 } 809 /* Type Definitions */ 811 typedef routing-instance-ref { 812 type leafref { 813 path "/rt:routing/rt:routing-instance/rt:name"; 814 } 815 description 816 "This type is used for leafs that reference a routing instance 817 configuration."; 818 } 820 typedef routing-instance-state-ref { 821 type leafref { 822 path "/rt:routing-state/rt:routing-instance/rt:name"; 823 } 824 description 825 "This type is used for leafs that reference state data of a 826 routing instance."; 827 } 829 typedef route-preference { 830 type uint32; 831 description 832 "This type is used for route preferences."; 833 } 835 /* Groupings */ 837 grouping address-family { 838 description 839 "This grouping provides a leaf identifying an address 840 family."; 841 leaf address-family { 842 type identityref { 843 base address-family; 844 } 845 mandatory "true"; 846 description 847 "Address family."; 848 } 849 } 851 grouping router-id { 852 description 853 "This grouping provides router ID."; 854 leaf router-id { 855 type yang:dotted-quad; 856 description 857 "A 32-bit number in the form of a dotted quad that is used by 858 some routing protocols identifying a router."; 859 reference 860 "RFC 2328: OSPF Version 2."; 861 } 862 } 864 grouping special-next-hop { 865 description 866 "This grouping provides a leaf with an enumeration of special 867 next-hops."; 868 leaf special-next-hop { 869 type enumeration { 870 enum blackhole { 871 description 872 "Silently discard the packet."; 873 } 874 enum unreachable { 875 description 876 "Discard the packet and notify the sender with an error 877 message indicating that the destination host is 878 unreachable."; 879 } 880 enum prohibit { 881 description 882 "Discard the packet and notify the sender with an error 883 message indicating that the communication is 884 administratively prohibited."; 885 } 886 enum receive { 887 description 888 "The packet will be received by the local system."; 889 } 890 } 891 description 892 "Special next-hop options."; 893 } 894 } 896 grouping next-hop-content { 897 description 898 "Generic parameters of next-hops in static routes."; 899 choice next-hop-options { 900 mandatory "true"; 901 description 902 "Options for next-hops in static routes. 904 Modules for address families MUST augment this choice with 905 the 'next-hop-address' case, which is a leaf containing a 906 gateway address of that address family. 908 It is expected that further cases will be added through 909 augments from other modules, e.g., for Equal-Cost Multipath 910 routing (ECMP)."; 911 leaf outgoing-interface { 912 type if:interface-ref; 913 description 914 "Name of the outgoing interface."; 915 } 916 case special-next-hop { 917 uses special-next-hop; 918 } 919 } 920 } 922 grouping next-hop-state-content { 923 description 924 "Generic parameters of next-hops in state data."; 925 choice next-hop-options { 926 mandatory "true"; 927 description 928 "Options for next-hops in state data. 930 Modules for address families MUST augment this choice with 931 the 'next-hop-address' case, which is a leaf containing a 932 gateway address of that address family. 934 It is expected that further cases will be added through 935 augments from other modules, e.g., for ECMP or recursive 936 next-hops."; 937 leaf outgoing-interface { 938 type if:interface-state-ref; 939 description 940 "Name of the outgoing interface."; 941 } 942 case special-next-hop { 943 uses special-next-hop; 944 } 945 } 946 } 948 grouping route-metadata { 949 description 950 "Common route metadata."; 951 leaf source-protocol { 952 type identityref { 953 base routing-protocol; 954 } 955 mandatory "true"; 956 description 957 "Type of the routing protocol from which the route 958 originated."; 959 } 960 leaf active { 961 type empty; 962 description 963 "Presence of this leaf indicates that the route is preferred 964 among all routes in the same RIB that have the same 965 destination prefix."; 966 } 967 leaf last-updated { 968 type yang:date-and-time; 969 description 970 "Time stamp of the last modification of the route. If the 971 route was never modified, it is the time when the route was 972 inserted into the RIB."; 973 } 974 } 976 /* State data */ 978 augment "/if:interfaces-state/if:interface" { 979 description 980 "This augment adds a reference to the routing-instance to which 981 the interface is assigned."; 982 leaf routing-instance { 983 type routing-instance-state-ref; 984 description 985 "The name of the routing instance to which the interface is 986 assigned."; 987 } 988 } 990 container routing-state { 991 config "false"; 992 description 993 "State data of the routing subsystem."; 994 list routing-instance { 995 key "name"; 996 min-elements "1"; 997 description 998 "Each list entry is a container for state data of a routing 999 instance. 1001 An implementation MUST provide one and only one 1002 system-controlled routing instance(s) of the type 1003 'rt:default-routing-instance', and MAY support other types. 1005 An implementation MAY restrict the number of routing 1006 instances of each supported type."; 1007 leaf name { 1008 type string; 1009 description 1010 "The name of the routing instance. 1012 For system-controlled instances the name SHOULD be 1013 persistent, i.e., it doesn't change after a reboot."; 1014 } 1015 leaf type { 1016 type identityref { 1017 base routing-instance; 1018 } 1019 description 1020 "The routing instance type."; 1021 } 1022 uses router-id { 1023 description 1024 "Global router ID. 1026 It may be either configured or assigned algorithmically by 1027 the implementation."; 1028 } 1029 container interfaces { 1030 description 1031 "Network layer interfaces belonging to the routing 1032 instance."; 1033 leaf-list interface { 1034 type if:interface-state-ref; 1035 must "../../name = /if:interfaces-state/" 1036 + "if:interface[if:name=current()]/" 1037 + "rt:routing-instance" { 1038 error-message 1039 "Routing instance is not assigned to the interface."; 1040 description 1041 "This reference must mirror a corresponding assignment 1042 of the ancestor routing-instance to the interface."; 1043 } 1044 description 1045 "Each entry is a reference to the name of a configured 1046 network layer interface."; 1047 } 1048 } 1049 container routing-protocols { 1050 description 1051 "Container for the list of routing protocol instances."; 1052 list routing-protocol { 1053 key "type name"; 1054 description 1055 "State data of a routing protocol instance. 1057 An implementation MUST provide exactly one 1058 system-controlled instance of the type 'direct'. Other 1059 instances MAY be created by configuration."; 1060 leaf type { 1061 type identityref { 1062 base routing-protocol; 1063 } 1064 description 1065 "Type of the routing protocol."; 1066 } 1067 leaf name { 1068 type string; 1069 description 1070 "The name of the routing protocol instance. 1072 For system-controlled instances this name is 1073 persistent, i.e., it SHOULD NOT change across 1074 reboots."; 1075 } 1076 } 1077 } 1078 container ribs { 1079 description 1080 "Container for RIBs."; 1081 list rib { 1082 key "name"; 1083 min-elements "1"; 1084 description 1085 "Each entry represents a RIB identified by the 'name' 1086 key. All routes in a RIB MUST belong to the same address 1087 family. 1089 For each routing instance, an implementation SHOULD 1090 provide one system-controlled default RIB for each 1091 supported address family."; 1092 leaf name { 1093 type string; 1094 description 1095 "The name of the RIB."; 1096 } 1097 uses address-family; 1098 leaf default-rib { 1099 if-feature multiple-ribs; 1100 type boolean; 1101 default "true"; 1102 description 1103 "This flag has the value of 'true' if and only if the 1104 RIB is the default RIB for the given address family. 1106 A default RIB always receives direct routes. By 1107 default it also receives routes from all routing 1108 protocols."; 1109 } 1110 container routes { 1111 description 1112 "Current content of the RIB."; 1113 list route { 1114 description 1115 "A RIB route entry. This data node MUST be augmented 1116 with information specific for routes of each address 1117 family."; 1118 leaf route-preference { 1119 type route-preference; 1120 description 1121 "This route attribute, also known as administrative 1122 distance, allows for selecting the preferred route 1123 among routes with the same destination prefix. A 1124 smaller value means a more preferred route."; 1125 } 1126 container next-hop { 1127 description 1128 "Route's next-hop attribute."; 1129 uses next-hop-state-content; 1130 } 1131 uses route-metadata; 1132 } 1133 } 1134 } 1135 } 1136 } 1137 } 1139 /* Configuration Data */ 1141 augment "/if:interfaces/if:interface" { 1142 description 1143 "This augment adds a routing-instance reference to interface 1144 configuration."; 1145 leaf routing-instance { 1146 type routing-instance-ref; 1147 description 1148 "The name of the routing instance to which the interface is 1149 to be assigned. 1151 By default, all network layer interfaces belong to the 1152 routing-instance of the 'default-routing-instance' type."; 1153 } 1154 } 1156 container routing { 1157 description 1158 "Configuration parameters for the routing subsystem."; 1159 list routing-instance { 1160 key "name"; 1161 description 1162 "Configuration of a routing instance."; 1163 leaf name { 1164 type string; 1165 description 1166 "The name of the routing instance. 1168 For system-controlled entries, the value of this leaf must 1169 be the same as the name of the corresponding entry in 1170 state data. 1172 For user-controlled entries, an arbitrary name can be 1173 used."; 1174 } 1175 leaf type { 1176 type identityref { 1177 base routing-instance; 1178 } 1179 default "rt:default-routing-instance"; 1180 description 1181 "The type of the routing instance."; 1182 } 1183 leaf enabled { 1184 type boolean; 1185 default "true"; 1186 description 1187 "Enable/disable the routing instance. 1189 If this parameter is false, the parent routing instance is 1190 disabled and does not appear in state data, despite any 1191 other configuration that might be present."; 1192 } 1193 uses router-id { 1194 if-feature router-id; 1195 description 1196 "Configuration of the global router ID. Routing protocols 1197 that use router ID can use this parameter or override it 1198 with another value."; 1199 } 1200 leaf description { 1201 type string; 1202 description 1203 "Textual description of the routing instance."; 1204 } 1205 container routing-protocols { 1206 description 1207 "Configuration of routing protocol instances."; 1208 list routing-protocol { 1209 key "type name"; 1210 description 1211 "Each entry contains configuration of a routing protocol 1212 instance."; 1213 leaf type { 1214 type identityref { 1215 base routing-protocol; 1216 } 1217 description 1218 "Type of the routing protocol - an identity derived 1219 from the 'routing-protocol' base identity."; 1220 } 1221 leaf name { 1222 type string; 1223 description 1224 "An arbitrary name of the routing protocol instance."; 1225 } 1226 leaf description { 1227 type string; 1228 description 1229 "Textual description of the routing protocol 1230 instance."; 1231 } 1232 container static-routes { 1233 when "../type='rt:static'" { 1234 description 1235 "This container is only valid for the 'static' 1236 routing protocol."; 1237 } 1238 description 1239 "Configuration of the 'static' pseudo-protocol. 1241 Address-family-specific modules augment this node with 1242 their lists of routes."; 1243 } 1244 } 1246 } 1247 container ribs { 1248 description 1249 "Configuration of RIBs."; 1250 list rib { 1251 key "name"; 1252 description 1253 "Each entry contains configuration for a RIB identified 1254 by the 'name' key. 1256 Entries having the same key as a system-controlled entry 1257 of the list /routing-state/routing-instance/ribs/rib are 1258 used for configuring parameters of that entry. Other 1259 entries define additional user-controlled RIBs."; 1260 leaf name { 1261 type string; 1262 description 1263 "The name of the RIB. 1265 For system-controlled entries, the value of this leaf 1266 must be the same as the name of the corresponding 1267 entry in state data. 1269 For user-controlled entries, an arbitrary name can be 1270 used."; 1271 } 1272 uses address-family { 1273 description 1274 "Address family of the RIB. 1276 It is mandatory for user-controlled RIBs. For 1277 system-controlled RIBs it can be omitted, otherwise it 1278 must match the address family of the corresponding 1279 state entry."; 1280 refine "address-family" { 1281 mandatory "false"; 1282 } 1283 } 1284 leaf description { 1285 type string; 1286 description 1287 "Textual description of the RIB."; 1288 } 1289 } 1290 } 1291 } 1292 } 1293 /* RPC operations */ 1295 rpc fib-route { 1296 description 1297 "Return the active FIB route that a routing-instance uses for 1298 sending packets to a destination address."; 1299 input { 1300 leaf routing-instance-name { 1301 type routing-instance-state-ref; 1302 mandatory "true"; 1303 description 1304 "Name of the routing instance whose forwarding information 1305 base is being queried. 1307 If the routing instance with name equal to the value of 1308 this parameter doesn't exist, then this operation SHALL 1309 fail with error-tag 'data-missing' and error-app-tag 1310 'routing-instance-not-found'."; 1311 } 1312 container destination-address { 1313 description 1314 "Network layer destination address. 1316 Address family specific modules MUST augment this 1317 container with a leaf named 'address'."; 1318 uses address-family; 1319 } 1320 } 1321 output { 1322 container route { 1323 description 1324 "The active FIB route for the specified destination. 1326 If the routing instance has no active FIB route for the 1327 destination address, no output is returned - the server 1328 SHALL send an containing a single element 1329 . 1331 Address family specific modules MUST augment this list 1332 with appropriate route contents."; 1333 uses address-family; 1334 container next-hop { 1335 description 1336 "Route's next-hop attribute."; 1337 uses next-hop-state-content; 1338 } 1339 uses route-metadata; 1340 } 1342 } 1343 } 1344 } 1346 1348 8. IPv4 Unicast Routing Management YANG Module 1350 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1351 the actual RFC number and all occurrences of the revision date below 1352 with the date of RFC publication (and remove this note). 1354 file "ietf-ipv4-unicast-routing@2015-10-16.yang" 1356 module ietf-ipv4-unicast-routing { 1358 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1360 prefix "v4ur"; 1362 import ietf-routing { 1363 prefix "rt"; 1364 } 1366 import ietf-inet-types { 1367 prefix "inet"; 1368 } 1370 organization 1371 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1373 contact 1374 "WG Web: 1375 WG List: 1377 WG Chair: Thomas Nadeau 1378 1380 WG Chair: Juergen Schoenwaelder 1381 1383 WG Chair: Kent Watsen 1384 1386 Editor: Ladislav Lhotka 1387 "; 1389 description 1390 "This YANG module augments the 'ietf-routing' module with basic 1391 configuration and state data for IPv4 unicast routing. 1393 Copyright (c) 2015 IETF Trust and the persons identified as 1394 authors of the code. All rights reserved. 1396 Redistribution and use in source and binary forms, with or 1397 without modification, is permitted pursuant to, and subject to 1398 the license terms contained in, the Simplified BSD License set 1399 forth in Section 4.c of the IETF Trust's Legal Provisions 1400 Relating to IETF Documents 1401 (http://trustee.ietf.org/license-info). 1403 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1404 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1405 'OPTIONAL' in the module text are to be interpreted as described 1406 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1408 This version of this YANG module is part of RFC XXXX 1409 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1410 full legal notices."; 1412 revision 2015-10-16 { 1413 description 1414 "Initial revision."; 1415 reference 1416 "RFC XXXX: A YANG Data Model for Routing Management"; 1417 } 1419 /* Identities */ 1421 identity ipv4-unicast { 1422 base rt:ipv4; 1423 description 1424 "This identity represents the IPv4 unicast address family."; 1425 } 1427 /* State data */ 1429 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 1430 + "rt:routes/rt:route" { 1431 when "../../rt:address-family = 'v4ur:ipv4-unicast'" { 1432 description 1433 "This augment is valid only for IPv4 unicast."; 1434 } 1435 description 1436 "This leaf augments an IPv4 unicast route."; 1437 leaf destination-prefix { 1438 type inet:ipv4-prefix; 1439 description 1440 "IPv4 destination prefix."; 1441 } 1442 } 1444 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 1445 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options" { 1446 when "../../../rt:address-family = 'v4ur:ipv4-unicast'" { 1447 description 1448 "This augment is valid only for IPv4 unicast."; 1449 } 1450 description 1451 "Augment 'next-hop-options' in IPv4 unicast routes."; 1452 leaf next-hop-address { 1453 type inet:ipv4-address; 1454 description 1455 "IPv4 address of the next-hop."; 1456 } 1457 } 1459 /* Configuration data */ 1461 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 1462 + "rt:routing-protocol/rt:static-routes" { 1463 description 1464 "This augment defines the configuration of the 'static' 1465 pseudo-protocol with data specific to IPv4 unicast."; 1466 container ipv4 { 1467 description 1468 "Configuration of a 'static' pseudo-protocol instance 1469 consists of a list of routes."; 1470 list route { 1471 key "destination-prefix"; 1472 description 1473 "A list of static routes."; 1474 leaf destination-prefix { 1475 type inet:ipv4-prefix; 1476 mandatory "true"; 1477 description 1478 "IPv4 destination prefix."; 1479 } 1480 leaf description { 1481 type string; 1482 description 1483 "Textual description of the route."; 1484 } 1485 container next-hop { 1486 description 1487 "Configuration of next-hop."; 1488 uses rt:next-hop-content { 1489 augment "next-hop-options" { 1490 description 1491 "Augment 'next-hop-options' in IPv4 static routes."; 1492 leaf next-hop-address { 1493 type inet:ipv4-address; 1494 description 1495 "IPv4 address of the next-hop."; 1496 } 1497 } 1498 } 1499 } 1500 } 1501 } 1502 } 1504 /* RPC operations */ 1506 augment "/rt:fib-route/rt:input/rt:destination-address" { 1507 when "rt:address-family='v4ur:ipv4-unicast'" { 1508 description 1509 "This augment is valid only for IPv4 unicast."; 1510 } 1511 description 1512 "This leaf augments the 'rt:destination-address' parameter of 1513 the 'rt:fib-route' operation."; 1514 leaf address { 1515 type inet:ipv4-address; 1516 description 1517 "IPv4 destination address."; 1518 } 1519 } 1521 augment "/rt:fib-route/rt:output/rt:route" { 1522 when "rt:address-family='v4ur:ipv4-unicast'" { 1523 description 1524 "This augment is valid only for IPv4 unicast."; 1525 } 1526 description 1527 "This leaf augments the reply to the 'rt:fib-route' 1528 operation."; 1529 leaf destination-prefix { 1530 type inet:ipv4-prefix; 1531 description 1532 "IPv4 destination prefix."; 1533 } 1535 } 1537 augment "/rt:fib-route/rt:output/rt:route/rt:next-hop/" 1538 + "rt:next-hop-options" { 1539 when "../rt:address-family='v4ur:ipv4-unicast'" { 1540 description 1541 "This augment is valid only for IPv4 unicast."; 1542 } 1543 description 1544 "Augment 'next-hop-options' in the reply to the 'rt:fib-route' 1545 operation."; 1546 leaf next-hop-address { 1547 type inet:ipv4-address; 1548 description 1549 "IPv4 address of the next-hop."; 1550 } 1551 } 1552 } 1554 1556 9. IPv6 Unicast Routing Management YANG Module 1558 RFC Editor: In this section, replace all occurrences of 'XXXX' with 1559 the actual RFC number and all occurrences of the revision date below 1560 with the date of RFC publication (and remove this note). 1562 file "ietf-ipv6-unicast-routing@2015-10-16.yang" 1564 module ietf-ipv6-unicast-routing { 1566 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1568 prefix "v6ur"; 1570 import ietf-routing { 1571 prefix "rt"; 1572 } 1574 import ietf-inet-types { 1575 prefix "inet"; 1576 } 1578 import ietf-interfaces { 1579 prefix "if"; 1580 } 1582 import ietf-ip { 1583 prefix "ip"; 1584 } 1586 organization 1587 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1589 contact 1590 "WG Web: 1591 WG List: 1593 WG Chair: Thomas Nadeau 1594 1596 WG Chair: Juergen Schoenwaelder 1597 1599 WG Chair: Kent Watsen 1600 1602 Editor: Ladislav Lhotka 1603 "; 1605 description 1606 "This YANG module augments the 'ietf-routing' module with basic 1607 configuration and state data for IPv6 unicast routing. 1609 Copyright (c) 2015 IETF Trust and the persons identified as 1610 authors of the code. All rights reserved. 1612 Redistribution and use in source and binary forms, with or 1613 without modification, is permitted pursuant to, and subject to 1614 the license terms contained in, the Simplified BSD License set 1615 forth in Section 4.c of the IETF Trust's Legal Provisions 1616 Relating to IETF Documents 1617 (http://trustee.ietf.org/license-info). 1619 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1620 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 1621 'OPTIONAL' in the module text are to be interpreted as described 1622 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 1624 This version of this YANG module is part of RFC XXXX 1625 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 1626 full legal notices."; 1628 revision 2015-10-16 { 1629 description 1630 "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 } 1808 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 1809 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options" { 1810 when "../../../rt:address-family = 'v6ur:ipv6-unicast'" { 1811 description 1812 "This augment is valid only for IPv6 unicast."; 1813 } 1814 description 1815 "Augment 'next-hop-options' in IPv6 unicast routes."; 1816 leaf next-hop-address { 1817 type inet:ipv6-address; 1818 description 1819 "IPv6 address of the next-hop."; 1820 } 1821 } 1823 /* Configuration data */ 1824 augment "/if:interfaces/if:interface/ip:ipv6" { 1825 description 1826 "Augment interface configuration with IPv6-specific parameters 1827 of router interfaces."; 1828 container ipv6-router-advertisements { 1829 description 1830 "Configuration of IPv6 Router Advertisements."; 1831 leaf send-advertisements { 1832 type boolean; 1833 default "false"; 1834 description 1835 "A flag indicating whether or not the router sends periodic 1836 Router Advertisements and responds to Router 1837 Solicitations."; 1838 reference 1839 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1840 AdvSendAdvertisements."; 1841 } 1842 leaf max-rtr-adv-interval { 1843 type uint16 { 1844 range "4..1800"; 1845 } 1846 units "seconds"; 1847 default "600"; 1848 description 1849 "The maximum time allowed between sending unsolicited 1850 multicast Router Advertisements from the interface."; 1851 reference 1852 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1853 MaxRtrAdvInterval."; 1854 } 1855 leaf min-rtr-adv-interval { 1856 type uint16 { 1857 range "3..1350"; 1858 } 1859 units "seconds"; 1860 must ". <= 0.75 * ../max-rtr-adv-interval" { 1861 description 1862 "The value MUST NOT be greater than 75 % of 1863 'max-rtr-adv-interval'."; 1864 } 1865 description 1866 "The minimum time allowed between sending unsolicited 1867 multicast Router Advertisements from the interface. 1869 The default value to be used operationally if this leaf is 1870 not configured is determined as follows: 1872 - if max-rtr-adv-interval >= 9 seconds, the default value 1873 is 0.33 * max-rtr-adv-interval; 1875 - otherwise it is 0.75 * max-rtr-adv-interval."; 1876 reference 1877 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1878 MinRtrAdvInterval."; 1879 } 1880 leaf managed-flag { 1881 type boolean; 1882 default "false"; 1883 description 1884 "The value to be placed in the 'Managed address 1885 configuration' flag field in the Router Advertisement."; 1886 reference 1887 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1888 AdvManagedFlag."; 1889 } 1890 leaf other-config-flag { 1891 type boolean; 1892 default "false"; 1893 description 1894 "The value to be placed in the 'Other configuration' flag 1895 field in the Router Advertisement."; 1896 reference 1897 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1898 AdvOtherConfigFlag."; 1899 } 1900 leaf link-mtu { 1901 type uint32; 1902 default "0"; 1903 description 1904 "The value to be placed in MTU options sent by the router. 1905 A value of zero indicates that no MTU options are sent."; 1906 reference 1907 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1908 AdvLinkMTU."; 1909 } 1910 leaf reachable-time { 1911 type uint32 { 1912 range "0..3600000"; 1913 } 1914 units "milliseconds"; 1915 default "0"; 1916 description 1917 "The value to be placed in the Reachable Time field in the 1918 Router Advertisement messages sent by the router. A value 1919 of zero means unspecified (by this router)."; 1921 reference 1922 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1923 AdvReachableTime."; 1924 } 1925 leaf retrans-timer { 1926 type uint32; 1927 units "milliseconds"; 1928 default "0"; 1929 description 1930 "The value to be placed in the Retrans Timer field in the 1931 Router Advertisement messages sent by the router. A value 1932 of zero means unspecified (by this router)."; 1933 reference 1934 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1935 AdvRetransTimer."; 1936 } 1937 leaf cur-hop-limit { 1938 type uint8; 1939 description 1940 "The value to be placed in the Cur Hop Limit field in the 1941 Router Advertisement messages sent by the router. A value 1942 of zero means unspecified (by this router). 1944 If this parameter is not configured, the device SHOULD use 1945 the value specified in IANA Assigned Numbers that was in 1946 effect at the time of implementation."; 1947 reference 1948 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1949 AdvCurHopLimit. 1951 IANA: IP Parameters, 1952 http://www.iana.org/assignments/ip-parameters"; 1953 } 1954 leaf default-lifetime { 1955 type uint16 { 1956 range "0..9000"; 1957 } 1958 units "seconds"; 1959 description 1960 "The value to be placed in the Router Lifetime field of 1961 Router Advertisements sent from the interface, in seconds. 1962 It MUST be either zero or between max-rtr-adv-interval and 1963 9000 seconds. A value of zero indicates that the router is 1964 not to be used as a default router. These limits may be 1965 overridden by specific documents that describe how IPv6 1966 operates over different link layers. 1968 If this parameter is not configured, the device SHOULD use 1969 a value of 3 * max-rtr-adv-interval."; 1970 reference 1971 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1972 AdvDefaultLifeTime."; 1973 } 1974 container prefix-list { 1975 description 1976 "Configuration of prefixes to be placed in Prefix 1977 Information options in Router Advertisement messages sent 1978 from the interface. 1980 Prefixes that are advertised by default but do not have 1981 their entries in the child 'prefix' list are advertised 1982 with the default values of all parameters. 1984 The link-local prefix SHOULD NOT be included in the list 1985 of advertised prefixes."; 1986 reference 1987 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 1988 AdvPrefixList."; 1989 list prefix { 1990 key "prefix-spec"; 1991 description 1992 "Configuration of an advertised prefix entry."; 1993 leaf prefix-spec { 1994 type inet:ipv6-prefix; 1995 description 1996 "IPv6 address prefix."; 1997 } 1998 choice control-adv-prefixes { 1999 default "advertise"; 2000 description 2001 "The prefix either may be explicitly removed from the 2002 set of advertised prefixes, or parameters with which 2003 it is advertised may be specified (default case)."; 2004 leaf no-advertise { 2005 type empty; 2006 description 2007 "The prefix will not be advertised. 2009 This can be used for removing the prefix from the 2010 default set of advertised prefixes."; 2011 } 2012 case advertise { 2013 leaf valid-lifetime { 2014 type uint32; 2015 units "seconds"; 2016 default "2592000"; 2017 description 2018 "The value to be placed in the Valid Lifetime in 2019 the Prefix Information option. The designated 2020 value of all 1's (0xffffffff) represents 2021 infinity."; 2022 reference 2023 "RFC 4861: Neighbor Discovery for IP version 6 2024 (IPv6) - AdvValidLifetime."; 2025 } 2026 leaf on-link-flag { 2027 type boolean; 2028 default "true"; 2029 description 2030 "The value to be placed in the on-link flag 2031 ('L-bit') field in the Prefix Information 2032 option."; 2033 reference 2034 "RFC 4861: Neighbor Discovery for IP version 6 2035 (IPv6) - AdvOnLinkFlag."; 2036 } 2037 leaf preferred-lifetime { 2038 type uint32; 2039 units "seconds"; 2040 must ". <= ../valid-lifetime" { 2041 description 2042 "This value MUST NOT be greater than 2043 valid-lifetime."; 2044 } 2045 default "604800"; 2046 description 2047 "The value to be placed in the Preferred Lifetime 2048 in the Prefix Information option. The designated 2049 value of all 1's (0xffffffff) represents 2050 infinity."; 2051 reference 2052 "RFC 4861: Neighbor Discovery for IP version 6 2053 (IPv6) - AdvPreferredLifetime."; 2054 } 2055 leaf autonomous-flag { 2056 type boolean; 2057 default "true"; 2058 description 2059 "The value to be placed in the Autonomous Flag 2060 field in the Prefix Information option."; 2061 reference 2062 "RFC 4861: Neighbor Discovery for IP version 6 2063 (IPv6) - AdvAutonomousFlag."; 2064 } 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 description 2085 "A list of static routes."; 2086 leaf destination-prefix { 2087 type inet:ipv6-prefix; 2088 mandatory "true"; 2089 description 2090 "IPv6 destination prefix."; 2091 } 2092 leaf description { 2093 type string; 2094 description 2095 "Textual description of the route."; 2096 } 2097 container next-hop { 2098 description 2099 "Configuration of next-hop."; 2100 uses rt:next-hop-content { 2101 augment "next-hop-options" { 2102 description 2103 "Augment 'next-hop-options' in IPv6 static routes."; 2104 leaf next-hop-address { 2105 type inet:ipv6-address; 2106 description 2107 "IPv6 address of the next-hop."; 2108 } 2109 } 2110 } 2111 } 2112 } 2113 } 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" { 2151 when "../rt:address-family='v6ur:ipv6-unicast'" { 2152 description 2153 "This augment is valid only for IPv6 unicast."; 2154 } 2155 description 2156 "Augment 'next-hop-options' in the reply to the 'rt:fib-route' 2157 operation."; 2158 leaf next-hop-address { 2159 type inet:ipv6-address; 2160 description 2161 "IPv6 address of the next-hop."; 2162 } 2164 } 2165 } 2167 2169 10. IANA Considerations 2171 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2172 actual RFC number (and remove this note). 2174 This document registers the following namespace URIs in the IETF XML 2175 registry [RFC3688]: 2177 -------------------------------------------------------------------- 2178 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2180 Registrant Contact: The IESG. 2182 XML: N/A, the requested URI is an XML namespace. 2183 -------------------------------------------------------------------- 2185 -------------------------------------------------------------------- 2186 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2188 Registrant Contact: The IESG. 2190 XML: N/A, the requested URI is an XML namespace. 2191 -------------------------------------------------------------------- 2193 -------------------------------------------------------------------- 2194 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2196 Registrant Contact: The IESG. 2198 XML: N/A, the requested URI is an XML namespace. 2199 -------------------------------------------------------------------- 2201 This document registers the following YANG modules in the YANG Module 2202 Names registry [RFC6020]: 2204 -------------------------------------------------------------------- 2205 name: ietf-routing 2206 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2207 prefix: rt 2208 reference: RFC XXXX 2209 -------------------------------------------------------------------- 2211 -------------------------------------------------------------------- 2212 name: ietf-ipv4-unicast-routing 2213 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2214 prefix: v4ur 2215 reference: RFC XXXX 2216 -------------------------------------------------------------------- 2218 -------------------------------------------------------------------- 2219 name: ietf-ipv6-unicast-routing 2220 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2221 prefix: v6ur 2222 reference: RFC XXXX 2223 -------------------------------------------------------------------- 2225 11. Security Considerations 2227 Configuration and state data conforming to the core routing data 2228 model (defined in this document) are designed to be accessed via the 2229 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 2230 transport layer and the mandatory-to-implement secure transport is 2231 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 2232 the means to restrict access for particular NETCONF users to a pre- 2233 configured subset of all available NETCONF protocol operations and 2234 content. 2236 A number of data nodes defined in the YANG modules belonging to the 2237 configuration part of the core routing data model are 2238 writable/creatable/deletable (i.e., "config true" in YANG terms, 2239 which is the default). These data nodes may be considered sensitive 2240 or vulnerable in some network environments. Write operations to 2241 these data nodes, such as "edit-config", can have negative effects on 2242 the network if the protocol operations are not properly protected. 2244 The vulnerable "config true" parameters and subtrees are the 2245 following: 2247 /if:interfaces/if:interface/rt:routing-instance: This leaf assigns a 2248 network layer interface to a routing instance. 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 Unauthorised 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, DOI 10.17487/ 2277 RFC2119, March 1997, 2278 . 2280 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2281 DOI 10.17487/RFC3688, January 2004, 2282 . 2284 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2285 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2286 DOI 10.17487/RFC4861, September 2007, 2287 . 2289 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2290 the Network Configuration Protocol (NETCONF)", RFC 6020, 2291 DOI 10.17487/RFC6020, October 2010, 2292 . 2294 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2295 and A. Bierman, Ed., "Network Configuration Protocol 2296 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2297 . 2299 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 2300 6991, DOI 10.17487/RFC6991, July 2013, 2301 . 2303 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 2304 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 2305 . 2307 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 2308 7277, DOI 10.17487/RFC7277, June 2014, 2309 . 2311 13.2. Informative References 2313 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2314 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2315 2006, . 2317 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2318 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 2319 January 2011, . 2321 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2322 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2323 . 2325 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2326 Protocol (NETCONF) Access Control Model", RFC 6536, DOI 2327 10.17487/RFC6536, March 2012, 2328 . 2330 Appendix A. The Complete Data Trees 2332 This appendix presents the complete configuration and state data 2333 trees of the core routing data model. See Section 2.2 for an 2334 explanation of the symbols used. Data type of every leaf node is 2335 shown near the right end of the corresponding line. 2337 A.1. Configuration Data 2338 +--rw routing 2339 +--rw routing-instance* [name] 2340 +--rw name string 2341 +--rw type? identityref 2342 +--rw enabled? boolean 2343 +--rw router-id? yang:dotted-quad 2344 +--rw description? string 2345 +--rw routing-protocols 2346 | +--rw routing-protocol* [type name] 2347 | +--rw type identityref 2348 | +--rw name string 2349 | +--rw description? string 2350 | +--rw static-routes 2351 | +--rw v6ur:ipv6 2352 | | +--rw v6ur:route* [destination-prefix] 2353 | | +--rw v6ur:destination-prefix inet:ipv6-prefix 2354 | | +--rw v6ur:description? string 2355 | | +--rw v6ur:next-hop 2356 | | +--rw (next-hop-options) 2357 | | +--:(outgoing-interface) 2358 | | | +--rw v6ur:outgoing-interface? 2359 | | +--:(special-next-hop) 2360 | | | +--rw v6ur:special-next-hop? 2361 | | +--:(next-hop-address) 2362 | | +--rw v6ur:next-hop-address? 2363 | +--rw v4ur:ipv4 2364 | +--rw v4ur:route* [destination-prefix] 2365 | +--rw v4ur:destination-prefix inet:ipv4-prefix 2366 | +--rw v4ur:description? string 2367 | +--rw v4ur:next-hop 2368 | +--rw (next-hop-options) 2369 | +--:(outgoing-interface) 2370 | | +--rw v4ur:outgoing-interface? 2371 | +--:(special-next-hop) 2372 | | +--rw v4ur:special-next-hop? 2373 | +--:(next-hop-address) 2374 | +--rw v4ur:next-hop-address? 2375 +--rw ribs 2376 +--rw rib* [name] 2377 +--rw name string 2378 +--rw address-family? identityref 2379 +--rw description? string 2381 A.2. State Data 2382 +--ro routing-state 2383 +--ro routing-instance* [name] 2384 +--ro name string 2385 +--ro type? identityref 2386 +--ro router-id? yang:dotted-quad 2387 +--ro interfaces 2388 | +--ro interface* if:interface-state-ref 2389 +--ro routing-protocols 2390 | +--ro routing-protocol* [type name] 2391 | +--ro type identityref 2392 | +--ro name string 2393 +--ro ribs 2394 +--ro rib* [name] 2395 +--ro name string 2396 +--ro address-family identityref 2397 +--ro default-rib? boolean {multiple-ribs}? 2398 +--ro routes 2399 +--ro route* 2400 +--ro route-preference? route-preference 2401 +--ro next-hop 2402 | +--ro (next-hop-options) 2403 | +--:(outgoing-interface) 2404 | | +--ro outgoing-interface? 2405 | +--:(special-next-hop) 2406 | | +--ro special-next-hop? enumeration 2407 | +--:(next-hop-address) 2408 | | +--ro v6ur:next-hop-address? 2409 | +--:(next-hop-address) 2410 | +--ro v4ur:next-hop-address? 2411 +--ro source-protocol identityref 2412 +--ro active? empty 2413 +--ro last-updated? yang:date-and-time 2414 +--ro v6ur:destination-prefix? inet:ipv6-prefix 2415 +--ro v4ur:destination-prefix? inet:ipv4-prefix 2417 Appendix B. Minimum Implementation 2419 Some parts and options of the core routing model, such as user- 2420 defined RIBs, are intended only for advanced routers. This appendix 2421 gives basic non-normative guidelines for implementing a bare minimum 2422 of available functions. Such an implementation may be used for hosts 2423 or very simple routers. 2425 A minimum implementation provides a single system-controlled routing 2426 instance of the type "default-routing-instance", and will not allow 2427 clients to create any user-controlled instances. 2429 Typically, the feature "multiple-ribs" will not be supported. This 2430 means that a single system-controlled RIB is available for each 2431 supported address family - IPv4, IPv6 or both. These RIBs must be 2432 the default RIBs. No user-controlled RIBs are allowed. 2434 In addition to the mandatory instance of the "direct" pseudo- 2435 protocol, a minimum implementation should support configuring 2436 instance(s) of the "static" pseudo-protocol. 2438 Platforms with severely constrained resources may use deviations for 2439 restricting the data model, e.g., limiting the number of "static" 2440 routing protocol instances. 2442 Appendix C. Example: Adding a New Routing Protocol 2444 This appendix demonstrates how the core routing data model can be 2445 extended to support a new routing protocol. The YANG module 2446 "example-rip" shown below is intended as an illustration rather than 2447 a real definition of a data model for the RIP routing protocol. For 2448 the sake of brevity, this module does not obey all the guidelines 2449 specified in [RFC6087]. See also Section 5.4.2. 2451 module example-rip { 2453 namespace "http://example.com/rip"; 2455 prefix "rip"; 2457 import ietf-interfaces { 2458 prefix "if"; 2459 } 2461 import ietf-routing { 2462 prefix "rt"; 2463 } 2465 identity rip { 2466 base rt:routing-protocol; 2467 description 2468 "Identity for the RIP routing protocol."; 2469 } 2471 typedef rip-metric { 2472 type uint8 { 2473 range "0..16"; 2474 } 2475 } 2476 grouping route-content { 2477 description 2478 "This grouping defines RIP-specific route attributes."; 2479 leaf metric { 2480 type rip-metric; 2481 } 2482 leaf tag { 2483 type uint16; 2484 default "0"; 2485 description 2486 "This leaf may be used to carry additional info, e.g. AS 2487 number."; 2488 } 2489 } 2491 augment "/rt:routing-state/rt:routing-instance/rt:ribs/rt:rib/" 2492 + "rt:routes/rt:route" { 2493 when "rt:source-protocol = 'rip:rip'" { 2494 description 2495 "This augment is only valid for a routes whose source 2496 protocol is RIP."; 2497 } 2498 description 2499 "RIP-specific route attributes."; 2500 uses route-content; 2501 } 2503 augment "/rt:fib-route/rt:output/rt:route" { 2504 description 2505 "RIP-specific route attributes in the output of 'active-route' 2506 RPC."; 2507 uses route-content; 2508 } 2510 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" 2511 + "rt:routing-protocol" { 2512 when "rt:type = 'rip:rip'" { 2513 description 2514 "This augment is only valid for a routing protocol instance 2515 of type 'rip'."; 2516 } 2517 container rip { 2518 presence "RIP configuration"; 2519 description 2520 "RIP instance configuration."; 2521 container interfaces { 2522 description 2523 "Per-interface RIP configuration."; 2525 list interface { 2526 key "name"; 2527 description 2528 "RIP is enabled on interfaces that have an entry in this 2529 list, unless 'enabled' is set to 'false' for that 2530 entry."; 2531 leaf name { 2532 type if:interface-ref; 2533 } 2534 leaf enabled { 2535 type boolean; 2536 default "true"; 2537 } 2538 leaf metric { 2539 type rip-metric; 2540 default "1"; 2541 } 2542 } 2543 } 2544 leaf update-interval { 2545 type uint8 { 2546 range "10..60"; 2547 } 2548 units "seconds"; 2549 default "30"; 2550 description 2551 "Time interval between periodic updates."; 2552 } 2553 } 2554 } 2555 } 2557 Appendix D. Example: NETCONF Reply 2559 This section contains a sample reply to the NETCONF message, 2560 which could be sent by a server supporting (i.e., advertising them in 2561 the NETCONF message) the following YANG modules: 2563 o ietf-interfaces [RFC7223], 2565 o ietf-ip [RFC7277], 2567 o ietf-routing (Section 7), 2569 o ietf-ipv4-unicast-routing (Section 8), 2571 o ietf-ipv6-unicast-routing (Section 9). 2573 We assume a simple network set-up as shown in Figure 3: router "A" 2574 uses static default routes with the "ISP" router as the next-hop. 2575 IPv6 router advertisements are configured only on the "eth1" 2576 interface and disabled on the upstream "eth0" interface. 2578 +-----------------+ 2579 | | 2580 | Router ISP | 2581 | | 2582 +--------+--------+ 2583 |2001:db8:0:1::2 2584 |192.0.2.2 2585 | 2586 | 2587 |2001:db8:0:1::1 2588 eth0|192.0.2.1 2589 +--------+--------+ 2590 | | 2591 | Router A | 2592 | | 2593 +--------+--------+ 2594 eth1|198.51.100.1 2595 |2001:db8:0:2::1 2596 | 2598 Figure 3: Example network configuration 2600 A reply to the NETCONF message sent by router "A" would then be 2601 as follows: 2603 2604 2613 2614 2615 2616 eth0 2617 ianaift:ethernetCsmacd 2618 2619 Uplink to ISP. 2620 2621 rtr0 2622 2623 2624 192.0.2.1 2625 24 2626 2627 true 2628 2629 2630 2631 2001:0db8:0:1::1 2632 64 2633 2634 true 2635 2636 false 2637 2638 2639 2640 2641 eth1 2642 ianaift:ethernetCsmacd 2643 2644 Interface to the internal network. 2645 2646 rtr0 2647 2648 2649 198.51.100.1 2650 24 2651 2652 true 2653 2654 2655 2656 2001:0db8:0:2::1 2657 64 2658 2659 true 2660 2661 false 2662 2663 2664 2665 2666 2667 2668 eth0 2669 ianaift:ethernetCsmacd 2670 00:0C:42:E5:B1:E9 2671 up 2672 rtr0 2673 2674 2675 2015-10-24T17:11:27+02:00 2676 2677 2678 2679 true 2680 1500 2681 2682 192.0.2.1 2683 24 2684 2685 2686 2687 true 2688 1500 2689 2690 2001:0db8:0:1::1 2691 64 2692 2693 2694 true 2695 2696 2697 2001:db8:0:2::/64 2698 2699 2700 2701 2702 2703 2704 eth1 2705 ianaift:ethernetCsmacd 2706 00:0C:42:E5:B1:EA 2707 up 2708 rtr0 2709 2710 2711 2015-10-24T17:11:29+02:00 2712 2713 2714 2715 true 2716 1500 2717 2718 198.51.100.1 2719 24 2720 2721 2722 2723 true 2724 1500 2725 2726 2001:0db8:0:2::1 2727 64 2728 2729 2730 true 2731 2732 2733 2001:db8:0:2::/64 2734 2735 2736 2737 2738 2739 2740 2741 2742 rtr0 2743 Router A 2744 192.0.2.1 2745 2746 2747 rt:static 2748 st0 2749 2750 Static routing is used for the internal network. 2751 2752 2753 2754 2755 2756 0.0.0.0/0 2757 2758 2759 192.0.2.2 2760 2761 2762 2763 2764 2765 ::/0 2766 2767 2768 2001:db8:0:1::2 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 rtr0 2781 2782 eth0 2783 eth1 2784 2785 2786 2787 rt:static 2788 st0 2789 2790 2791 2792 2793 ipv4-master 2794 v4ur:ipv4-unicast 2795 true 2796 2797 2798 2799 192.0.2.1/24 2800 2801 2802 eth0 2803 2804 0 2805 rt:direct 2806 2015-10-24T17:11:27+02:00 2807 2808 2809 2810 198.51.100.0/24 2811 2812 2813 eth1 2814 2815 rt:direct 2816 0 2817 2015-10-24T17:11:27+02:00 2818 2819 2820 0.0.0.0/0 2821 rt:static 2822 5 2823 2824 192.0.2.2 2825 2826 2015-10-24T18:02:45+02:00 2827 2828 2829 2830 2831 ipv6-master 2832 v6ur:ipv6-unicast 2833 true 2834 2835 2836 2837 2001:db8:0:1::/64 2838 2839 2840 eth0 2841 2842 rt:direct 2843 0 2844 2015-10-24T17:11:27+02:00 2845 2846 2847 2848 2001:db8:0:2::/64 2849 2850 2851 eth1 2852 2853 rt:direct 2854 0 2855 2015-10-24T17:11:27+02:00 2856 2857 2858 ::/0 2859 2860 2861 2001:db8:0:1::2 2862 2863 2864 rt:static 2865 5 2866 2015-10-24T18:02:45+02:00 2867 2868 2869 2870 2871 2872 2873 2874 2876 Appendix E. Change Log 2878 RFC Editor: Remove this section upon publication as an RFC. 2880 E.1. Changes Between Versions -19 and -20 2882 o Assignment of L3 interfaces to routing instances is now part of 2883 interface configuration. 2885 o Next-hop options in configuration were aligned with state data. 2887 o It is recommended to enclose protocol-specific configuration in a 2888 presence container. 2890 E.2. Changes Between Versions -18 and -19 2892 o The leaf "route-preference" was removed from the "routing- 2893 protocol" container in both "routing" and "routing-state". 2895 o The "vrf-routing-instance" identity was added in support of a 2896 common routing-instance type in addition to the "default-routing- 2897 instance". 2899 o Removed "enabled" switch from "routing-protocol". 2901 E.3. Changes Between Versions -17 and -18 2903 o The container "ribs" was moved under "routing-instance" (in both 2904 "routing" and "routing-state"). 2906 o Typedefs "rib-ref" and "rib-state-ref" were removed. 2908 o Removed "recipient-ribs" (both state and configuration). 2910 o Removed "connected-ribs" from "routing-protocol" (both state and 2911 configuration). 2913 o Configuration and state data for IPv6 RA were moved under 2914 "if:interface" and "if:interface-state". 2916 o Assignment of interfaces to routing instances now use leaf-list 2917 rather than list (both config and state). The opposite reference 2918 from "if:interface" to "rt:routing-instance" was changed to a 2919 single leaf (an interface cannot belong to multiple routing 2920 instances). 2922 o Specification of a default RIB is now a simple flag under "rib" 2923 (both config and state). 2925 o Default RIBs are marked by a flag in state data. 2927 E.4. Changes Between Versions -16 and -17 2929 o Added Acee as a co-author. 2931 o Removed all traces of route filters. 2933 o Removed numeric IDs of list entries in state data. 2935 o Removed all next-hop cases except "simple-next-hop" and "special- 2936 next-hop". 2938 o Removed feature "multipath-routes". 2940 o Augmented "ietf-interfaces" module with a leaf-list of leafrefs 2941 pointing form state data of an interface entry to the routing 2942 instance(s) to which the interface is assigned. 2944 E.5. Changes Between Versions -15 and -16 2946 o Added 'type' as the second key component of 'routing-protocol', 2947 both in configuration and state data. 2949 o The restriction of no more than one connected RIB per address 2950 family was removed. 2952 o Removed the 'id' key of routes in RIBs. This list has no keys 2953 anymore. 2955 o Remove the 'id' key from static routes and make 'destination- 2956 prefix' the only key. 2958 o Added 'route-preference' as a new attribute of routes in RIB. 2960 o Added 'active' as a new attribute of routes in RIBs. 2962 o Renamed RPC operation 'active-route' to 'fib-route'. 2964 o Added 'route-preference' as a new parameter of routing protocol 2965 instances, both in configuration and state data. 2967 o Renamed identity 'rt:standard-routing-instance' to 'rt:default- 2968 routing-instance'. 2970 o Added next-hop lists to state data. 2972 o Added two cases for specifying next-hops indirectly - via a new 2973 RIB or a recursive list of next-hops. 2975 o Reorganized next-hop in static routes. 2977 o Removed all 'if-feature' statements from state data. 2979 E.6. Changes Between Versions -14 and -15 2981 o Removed all defaults from state data. 2983 o Removed default from 'cur-hop-limit' in config. 2985 E.7. Changes Between Versions -13 and -14 2987 o Removed dependency of 'connected-ribs' on the 'multiple-ribs' 2988 feature. 2990 o Removed default value of 'cur-hop-limit' in state data. 2992 o Moved parts of descriptions and all references on IPv6 RA 2993 parameters from state data to configuration. 2995 o Added reference to RFC 6536 in the Security section. 2997 E.8. Changes Between Versions -12 and -13 2999 o Wrote appendix about minimum implementation. 3001 o Remove "when" statement for IPv6 router interface state data - it 3002 was dependent on a config value that may not be present. 3004 o Extra container for the next-hop list. 3006 o Names rather than numeric ids are used for referring to list 3007 entries in state data. 3009 o Numeric ids are always declared as mandatory and unique. Their 3010 description states that they are ephemeral. 3012 o Descriptions of "name" keys in state data lists are required to be 3013 persistent. 3015 o 3017 o Removed "if-feature multiple-ribs;" from connected-ribs. 3019 o "rib-name" instead of "name" is used as the name of leafref nodes. 3021 o "next-hop" instead of "nexthop" or "gateway" used throughout, both 3022 in node names and text. 3024 E.9. Changes Between Versions -11 and -12 3026 o Removed feature "advanced-router" and introduced two features 3027 instead: "multiple-ribs" and "multipath-routes". 3029 o Unified the keys of config and state versions of "routing- 3030 instance" and "rib" lists. 3032 o Numerical identifiers of state list entries are not keys anymore, 3033 but they are constrained using the "unique" statement. 3035 o Updated acknowledgements. 3037 E.10. Changes Between Versions -10 and -11 3039 o Migrated address families from IANA enumerations to identities. 3041 o Terminology and node names aligned with the I2RS RIB model: router 3042 -> routing instance, routing table -> RIB. 3044 o Introduced uint64 keys for state lists: routing-instance, rib, 3045 route, nexthop. 3047 o Described the relationship between system-controlled and user- 3048 controlled list entries. 3050 o Feature "user-defined-routing-tables" changed into "advanced- 3051 router". 3053 o Made nexthop into a choice in order to allow for nexthop-list 3054 (I2RS requirement). 3056 o Added nexthop-list with entries having priorities (backup) and 3057 weights (load balancing). 3059 o Updated bibliography references. 3061 E.11. Changes Between Versions -09 and -10 3063 o Added subtree for state data ("/routing-state"). 3065 o Terms "system-controlled entry" and "user-controlled entry" 3066 defined and used. 3068 o New feature "user-defined-routing-tables". Nodes that are useful 3069 only with user-defined routing tables are now conditional. 3071 o Added grouping "router-id". 3073 o In routing tables, "source-protocol" attribute of routes now 3074 reports only protocol type, and its datatype is "identityref". 3076 o Renamed "main-routing-table" to "default-routing-table". 3078 E.12. Changes Between Versions -08 and -09 3080 o Fixed "must" expression for "connected-routing-table". 3082 o Simplified "must" expression for "main-routing-table". 3084 o Moved per-interface configuration of a new routing protocol under 3085 'routing-protocol'. This also affects the 'example-rip' module. 3087 E.13. Changes Between Versions -07 and -08 3089 o Changed reference from RFC6021 to RFC6021bis. 3091 E.14. Changes Between Versions -06 and -07 3093 o The contents of in Appendix D was updated: "eth[01]" 3094 is used as the value of "location", and "forwarding" is on for 3095 both interfaces and both IPv4 and IPv6. 3097 o The "must" expression for "main-routing-table" was modified to 3098 avoid redundant error messages reporting address family mismatch 3099 when "name" points to a non-existent routing table. 3101 o The default behavior for IPv6 RA prefix advertisements was 3102 clarified. 3104 o Changed type of "rt:router-id" to "ip:dotted-quad". 3106 o Type of "rt:router-id" changed to "yang:dotted-quad". 3108 o Fixed missing prefixes in XPath expressions. 3110 E.15. Changes Between Versions -05 and -06 3112 o Document title changed: "Configuration" was replaced by 3113 "Management". 3115 o New typedefs "routing-table-ref" and "route-filter-ref". 3117 o Double slashes "//" were removed from XPath expressions and 3118 replaced with the single "/". 3120 o Removed uniqueness requirement for "router-id". 3122 o Complete data tree is now in Appendix A. 3124 o Changed type of "source-protocol" from "leafref" to "string". 3126 o Clarified the relationship between routing protocol instances and 3127 connected routing tables. 3129 o Added a must constraint saying that a routing table connected to 3130 the direct pseudo-protocol must not be a main routing table. 3132 E.16. Changes Between Versions -04 and -05 3134 o Routing tables are now global, i.e., "routing-tables" is a child 3135 of "routing" rather than "router". 3137 o "must" statement for "static-routes" changed to "when". 3139 o Added "main-routing-tables" containing references to main routing 3140 tables for each address family. 3142 o Removed the defaults for "address-family" and "safi" and made them 3143 mandatory. 3145 o Removed the default for route-filter/type and made this leaf 3146 mandatory. 3148 o If there is no active route for a given destination, the "active- 3149 route" RPC returns no output. 3151 o Added "enabled" switch under "routing-protocol". 3153 o Added "router-type" identity and "type" leaf under "router". 3155 o Route attribute "age" changed to "last-updated", its type is 3156 "yang:date-and-time". 3158 o The "direct" pseudo-protocol is always connected to main routing 3159 tables. 3161 o Entries in the list of connected routing tables renamed from 3162 "routing-table" to "connected-routing-table". 3164 o Added "must" constraint saying that a routing table must not be 3165 its own recipient. 3167 E.17. Changes Between Versions -03 and -04 3169 o Changed "error-tag" for both RPC operations from "missing element" 3170 to "data-missing". 3172 o Removed the decrementing behavior for advertised IPv6 prefix 3173 parameters "valid-lifetime" and "preferred-lifetime". 3175 o Changed the key of the static route lists from "seqno" to "id" 3176 because the routes needn't be sorted. 3178 o Added 'must' constraint saying that "preferred-lifetime" must not 3179 be greater than "valid-lifetime". 3181 E.18. Changes Between Versions -02 and -03 3183 o Module "iana-afn-safi" moved to I-D "iana-if-type". 3185 o Removed forwarding table. 3187 o RPC "get-route" changed to "active-route". Its output is a list 3188 of routes (for multi-path routing). 3190 o New RPC "route-count". 3192 o For both RPCs, specification of negative responses was added. 3194 o Relaxed separation of router instances. 3196 o Assignment of interfaces to router instances needn't be disjoint. 3198 o Route filters are now global. 3200 o Added "allow-all-route-filter" for symmetry. 3202 o Added Section 6 about interactions with "ietf-interfaces" and 3203 "ietf-ip". 3205 o Added "router-id" leaf. 3207 o Specified the names for IPv4/IPv6 unicast main routing tables. 3209 o Route parameter "last-modified" changed to "age". 3211 o Added container "recipient-routing-tables". 3213 E.19. Changes Between Versions -01 and -02 3215 o Added module "ietf-ipv6-unicast-routing". 3217 o The example in Appendix D now uses IP addresses from blocks 3218 reserved for documentation. 3220 o Direct routes appear by default in the forwarding table. 3222 o Network layer interfaces must be assigned to a router instance. 3223 Additional interface configuration may be present. 3225 o The "when" statement is only used with "augment", "must" is used 3226 elsewhere. 3228 o Additional "must" statements were added. 3230 o The "route-content" grouping for IPv4 and IPv6 unicast now 3231 includes the material from the "ietf-routing" version via "uses 3232 rt:route-content". 3234 o Explanation of symbols in the tree representation of data model 3235 hierarchy. 3237 E.20. Changes Between Versions -00 and -01 3239 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 3241 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 3242 safi" module. 3244 o Names of some data nodes were changed, in particular "routing- 3245 process" is now "router". 3247 o The restriction of a single AFN/SAFI per router was lifted. 3249 o RPC operation "delete-route" was removed. 3251 o Illegal XPath references from "get-route" to the datastore were 3252 fixed. 3254 o Section "Security Considerations" was written. 3256 Authors' Addresses 3258 Ladislav Lhotka 3259 CZ.NIC 3261 Email: lhotka@nic.cz 3263 Acee Lindem 3264 Cisco Systems 3266 Email: acee@cisco.com