idnits 2.17.1 draft-ietf-netmod-rfc8022bis-05.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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC8022, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2802 has weird spacing: '...-family ide...' == Line 2874 has weird spacing: '...ro type ide...' == Line 2875 has weird spacing: '...ro name str...' == Line 2879 has weird spacing: '...-family ide...' -- The document date (December 20, 2017) is 2318 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-03) exists of draft-ietf-netmod-rfc7223bis-01 == Outdated reference: A later version (-03) exists of draft-ietf-netmod-rfc7277bis-01 ** Obsolete normative reference: RFC 8022 (Obsoleted by RFC 8349) == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-07 == Outdated reference: A later version (-20) exists of draft-ietf-netmod-rfc6087bis-15 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 Summary: 3 errors (**), 0 flaws (~~), 10 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: June 23, 2018 Cisco Systems 6 Y. Qu 7 Huawei 8 December 20, 2017 10 A YANG Data Model for Routing Management (NDMA Version) 11 draft-ietf-netmod-rfc8022bis-05 13 Abstract 15 This document contains a specification of three YANG modules and one 16 submodule. Together they form the core routing data model that 17 serves as a framework for configuring and managing a routing 18 subsystem. It is expected that these modules will be augmented by 19 additional YANG modules defining data models for control-plane 20 protocols, route filters, and other functions. The core routing data 21 model provides common building blocks for such extensions -- routes, 22 Routing Information Bases (RIBs), and control-plane protocols. 24 The main difference from the first version is that this version fully 25 conforms to the Network Management Datastore Architecture (NMDA). 26 Consequently, this document obsoletes RFC 8022. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 23, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 64 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 65 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 67 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. The Design of the Core Routing Data Model . . . . . . . . . . 6 69 4.1. System-Controlled and User-Controlled List Entries . . . 7 70 5. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. Routing Information Base (RIB) . . . . . . . . . . . . . 9 73 5.3. Control-Plane Protocol . . . . . . . . . . . . . . . . . 9 74 5.3.1. Routing Pseudo-Protocols . . . . . . . . . . . . . . 10 75 5.3.2. Defining New Control-Plane Protocols . . . . . . . . 10 76 5.4. Parameters of IPv6 Router Advertisements . . . . . . . . 11 77 6. Interactions with Other YANG Modules . . . . . . . . . . . . 12 78 6.1. Module "ietf-interfaces" . . . . . . . . . . . . . . . . 12 79 6.2. Module "ietf-ip" . . . . . . . . . . . . . . . . . . . . 12 80 7. Routing Management YANG Module . . . . . . . . . . . . . . . 13 81 8. IPv4 Unicast Routing Management YANG Module . . . . . . . . . 28 82 9. IPv6 Unicast Routing Management YANG Module . . . . . . . . . 36 83 9.1. IPv6 Router Advertisements Submodule . . . . . . . . . . 44 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 55 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 56 88 12.2. Informative References . . . . . . . . . . . . . . . . . 57 89 Appendix A. The Complete Schema Tree . . . . . . . . . . . . . . 59 90 Appendix B. Minimum Implementation . . . . . . . . . . . . . . . 64 91 Appendix C. Example: Adding a New Control-Plane Protocol . . . . 64 92 Appendix D. Data Tree Example . . . . . . . . . . . . . . . . . 67 93 Appendix E. NETCONF Get Data Reply Example . . . . . . . . . . . 73 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 97 1. Introduction 99 This document contains a specification of the following YANG modules: 101 o The "ietf-routing" module provides generic components of a routing 102 data model. 104 o The "ietf-ipv4-unicast-routing" module augments the "ietf-routing" 105 module with additional data specific to IPv4 unicast. 107 o The "ietf-ipv6-unicast-routing" module augments the "ietf-routing" 108 module with additional data specific to IPv6 unicast. Its 109 submodule "ietf-ipv6-router-advertisements" also augments the 110 "ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and "ietf- 111 ip" [I-D.ietf-netmod-rfc7277bis] modules with IPv6 router 112 configuration variables required by [RFC4861]. 114 These modules together define the so-called core routing data model, 115 which is intended as a basis for future data model development 116 covering more-sophisticated routing systems. While these three 117 modules can be directly used for simple IP devices with static 118 routing (see Appendix B), their main purpose is to provide essential 119 building blocks for more-complicated data models involving multiple 120 control-plane protocols, multicast routing, additional address 121 families, and advanced functions such as route filtering or policy 122 routing. To this end, it is expected that the core routing data 123 model will be augmented by numerous modules developed by various IETF 124 working groups. 126 The main difference from the first version is that this version fully 127 conforms to the Network Management Datastore Architecture (NMDA) 128 [I-D.ietf-netmod-revised-datastores]. Consequently, this document 129 obsoletes RFC 8022 [RFC8022]. 131 2. Terminology and Notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The following terms are defined in 138 [I-D.ietf-netmod-revised-datastores]: 140 o client 141 o server 143 o configuration 145 o system state 147 o operational state 149 o intended configuration 151 The following terms are defined in [RFC7950]: 153 o action 155 o augment 157 o container 159 o container with presence 161 o data model 163 o data node 165 o feature 167 o leaf 169 o list 171 o mandatory node 173 o module 175 o schema tree 177 o state data 179 o RPC (Remote Procedure Call) operation 181 2.1. Glossary of New Terms 183 core routing data model: YANG data model comprising "ietf-routing", 184 "ietf-ipv4-unicast-routing", and "ietf-ipv6-unicast-routing" 185 modules. 187 direct route: a route to a directly connected network. 189 Routing Information Base (RIB): An object containing a list of 190 routes together with other information. See Section 5.2 for 191 details. 193 system-controlled entry: An entry of a list in operational state 194 ("config false") that is created by the system independently of 195 what has been explicitly configured. See Section 4.1 for details. 197 user-controlled entry: An entry of a list in operational state data 198 ("config false") that is created and deleted as a direct 199 consequence of certain configuration changes. See Section 4.1 for 200 details. 202 2.2. Tree Diagrams 204 Tree diagrams used in this document follow the notation defined in 205 [I-D.ietf-netmod-yang-tree-diagrams]. 207 2.3. Prefixes in Data Node Names 209 In this document, names of data nodes, actions, and other data model 210 objects are often used without a prefix, as long as it is clear from 211 the context in which YANG module each name is defined. Otherwise, 212 names are prefixed using the standard prefix associated with the 213 corresponding YANG module, as shown in Table 1. 215 +--------+---------------------------+------------------------------+ 216 | Prefix | YANG module | Reference | 217 +--------+---------------------------+------------------------------+ 218 | if | ietf-interfaces | [I-D.ietf-netmod-rfc7223bis] | 219 | ip | ietf-ip | [I-D.ietf-netmod-rfc7277bis] | 220 | rt | ietf-routing | Section 7 | 221 | v4ur | ietf-ipv4-unicast-routing | Section 8 | 222 | v6ur | ietf-ipv6-unicast-routing | Section 9 | 223 | yang | ietf-yang-types | [RFC6991] | 224 | inet | ietf-inet-types | [RFC6991] | 225 +--------+---------------------------+------------------------------+ 227 Table 1: Prefixes and Corresponding YANG Modules 229 3. Objectives 231 The initial design of the core routing data model was driven by the 232 following objectives: 234 o The data model should be suitable for the common address families 235 -- in particular, IPv4 and IPv6 -- and for unicast and multicast 236 routing, as well as Multiprotocol Label Switching (MPLS). 238 o A simple IP routing system, such as one that uses only static 239 routing, should be configurable in a simple way, ideally without 240 any need to develop additional YANG modules. 242 o On the other hand, the core routing framework must allow for 243 complicated implementations involving multiple Routing Information 244 Bases (RIBs) and multiple control-plane protocols, as well as 245 controlled redistributions of routing information. 247 o Because device vendors will want to map the data models built on 248 this generic framework to their proprietary data models and 249 configuration interfaces, the framework should be flexible enough 250 to facilitate that and accommodate data models with different 251 logic. 253 4. The Design of the Core Routing Data Model 255 The core routing data model consists of three YANG modules and one 256 submodule. The first module, "ietf-routing", defines the generic 257 components of a routing system. The other two modules, "ietf-ipv4- 258 unicast-routing" and "ietf-ipv6-unicast-routing", augment the "ietf- 259 routing" module with additional data nodes that are needed for IPv4 260 and IPv6 unicast routing, respectively. The "ietf-ipv6-unicast- 261 routing" module has a submodule, "ietf-ipv6-router-advertisements", 262 that augments the "ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and 263 "ietf-ip" [I-D.ietf-netmod-rfc7277bis] modules with configuration 264 variables for IPv6 router advertisements as required by [RFC4861]. 266 Figure 1 shows abridged views of the hierarchies. See Appendix A 267 for the complete data trees. 269 +--rw routing 270 +--rw router-id? yang:dotted-quad 271 +--ro interfaces 272 | +--ro interface* if:interface-ref 273 +--rw control-plane-protocols 274 | +--rw control-plane-protocol* [type name] 275 | +--rw type identityref 276 | +--rw name string 277 | +--rw description? string 278 | +--rw static-routes 279 | +--rw v4ur:ipv4 280 | | ... 281 | +--rw v6ur:ipv6 282 | ... 283 +--rw ribs 284 +--rw rib* [name] 285 +--rw name string 286 +--rw address-family? identityref 287 +--ro default-rib? boolean {multiple-ribs}? 288 +--ro routes 289 | +--ro route* 290 | ... 291 +---x active-route 292 | +---w input 293 | | +---w v4ur:destination-address? inet:ipv4-address 294 | | +---w v6ur:destination-address? inet:ipv6-address 295 | +--ro output 296 | ... 297 +--rw description? string 299 Figure 1: Data Hierarchy 301 As can be seen from Figure 1, the core routing data model introduces 302 several generic components of a routing framework: routes, RIBs 303 containing lists of routes, and control-plane protocols. Section 5 304 describes these components in more detail. 306 4.1. System-Controlled and User-Controlled List Entries 308 The core routing data model defines several lists in the schema tree, 309 such as "rib", that have to be populated with at least one entry in 310 any properly functioning device, and additional entries may be 311 configured by a client. 313 In such a list, the server creates the required item as a so-called 314 system-controlled entry in state data in the operational state 315 datastore [I-D.ietf-netmod-revised-datastores], i.e., inside read- 316 only lists in the "routing" container. 318 An example can be seen in Appendix D: the "/routing/ribs/rib" list 319 has two system-controlled entries named "ipv4-master" and 320 "ipv6-master". 322 Additional entries may be created in the configuration by a client, 323 e.g., via the NETCONF protocol. These are so-called user-controlled 324 entries. If the server accepts a configured user-controlled entry, 325 then this entry also appears in the state data version of the list. 327 Corresponding entries in both versions of the list (in operational 328 state datastore and intended datastore 329 [I-D.ietf-netmod-revised-datastores] have the same value of the list 330 key. 332 A client may also provide supplemental configuration of system- 333 controlled entries. To do so, the client creates a new entry in the 334 configuration with the desired contents. In order to bind this entry 335 to the corresponding entry in the state data list in the operational 336 state datastore, the key of the configuration entry has to be set to 337 the same value as the key of the state entry. 339 Deleting a user-controlled entry from the configuration list results 340 in the removal of the corresponding entry in the state data list. In 341 contrast, if client delets a system-controlled entry from the 342 configuration list in the intended datastore, only the extra 343 configuration specified in that entry is removed but the 344 corresponding state data entry remains in the list in the operational 345 datastore. 347 5. Basic Building Blocks 349 This section describes the essential components of the core routing 350 data model. 352 5.1. Route 354 Routes are basic elements of information in a routing system. The 355 core routing data model defines only the following minimal set of 356 route attributes: 358 o "destination-prefix": address prefix specifying the set of 359 destination addresses for which the route may be used. This 360 attribute is mandatory. 362 o "route-preference": an integer value (also known as administrative 363 distance) that is used for selecting a preferred route among 364 routes with the same destination prefix. A lower value means a 365 more preferred route. 367 o "next-hop": determines the outgoing interface and/or next-hop 368 address(es), or a special operation to be performed with a packet. 370 Routes are primarily state data that appear as entries of RIBs 371 (Section 5.2) but they may also be found in configuration data, for 372 example, as manually configured static routes. In the latter case, 373 configurable route attributes are generally a subset of attributes 374 defined for RIB routes. 376 5.2. Routing Information Base (RIB) 378 Every implementation of the core routing data model manages one or 379 more Routing Information Bases (RIBs). A RIB is a list of routes 380 complemented with administrative data. Each RIB contains only routes 381 of one address family. An address family is represented by an 382 identity derived from the "rt:address-family" base identity. 384 In the core routing data model, RIBs are state data represented as 385 entries of the list "/routing/ribs/rib" in the operational state 386 datastore [I-D.ietf-netmod-revised-datastores]. The contents of RIBs 387 are controlled and manipulated by control-plane protocol operations 388 that may result in route additions, removals, and modifications. 389 This also includes manipulations via the "static" and/or "direct" 390 pseudo-protocols; see Section 5.3.1. 392 For every supported address family, exactly one RIB MUST be marked as 393 the so-called default RIB to which control-plane protocols place 394 their routes by default. 396 Simple router implementations that do not advertise the feature 397 "multiple-ribs" will typically create one system-controlled RIB per 398 supported address family and mark it as the default RIB. 400 More-complex router implementations advertising the "multiple-ribs" 401 feature support multiple RIBs per address family that can be used for 402 policy routing and other purposes. 404 The following action (see Section 7.15 of [RFC7950]) is defined for 405 the "rib" list: 407 o active-route -- return the active RIB route for the destination 408 address that is specified as the action's input parameter. 410 5.3. Control-Plane Protocol 412 The core routing data model provides an open-ended framework for 413 defining multiple control-plane protocol instances, e.g., for Layer 3 414 routing protocols. Each control-plane protocol instance MUST be 415 assigned a type, which is an identity derived from the 416 "rt:control-plane-protocol" base identity. The core routing data 417 model defines two identities for the direct and static pseudo- 418 protocols (Section 5.3.1). 420 Multiple control-plane protocol instances of the same type MAY be 421 configured. 423 5.3.1. Routing Pseudo-Protocols 425 The core routing data model defines two special routing protocol 426 types -- "direct" and "static". Both are in fact pseudo-protocols, 427 which means that they are confined to the local device and do not 428 exchange any routing information with adjacent routers. 430 Every implementation of the core routing data model MUST provide 431 exactly one instance of the "direct" pseudo-protocol type. It is the 432 source of direct routes for all configured address families. Direct 433 routes are normally supplied by the operating system kernel, based on 434 the configuration of network interface addresses; see Section 6.2. 436 A pseudo-protocol of the type "static" allows for specifying routes 437 manually. It MAY be configured in zero or multiple instances, 438 although a typical configuration will have exactly one instance. 440 5.3.2. Defining New Control-Plane Protocols 442 It is expected that future YANG modules will create data models for 443 additional control-plane protocol types. Such a new module has to 444 define the protocol-specific configuration and state data, and it has 445 to integrate it into the core routing framework in the following way: 447 o A new identity MUST be defined for the control-plane protocol, and 448 its base identity MUST be set to "rt:control-plane-protocol" or to 449 an identity derived from "rt:control-plane-protocol". 451 o Additional route attributes MAY be defined, preferably in one 452 place by means of defining a YANG grouping. The new attributes 453 have to be inserted by augmenting the definitions of the node 455 /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route 457 and possibly other places in the configuration, state data, 458 notifications, and input/output parameters of actions or RPC 459 operations. 461 o Configuration parameters and/or state data for the new protocol 462 can be defined by augmenting the "control-plane-protocol" data 463 node under "/routing". 465 By using a "when" statement, the augmented configuration parameters 466 and state data specific to the new protocol SHOULD be made 467 conditional and valid only if the value of "rt:type" or 468 "rt:source-protocol" is equal to (or derived from) the new protocol's 469 identity. 471 It is also RECOMMENDED that protocol-specific data nodes be 472 encapsulated in an appropriately named container with presence. Such 473 a container may contain mandatory data nodes that are otherwise 474 forbidden at the top level of an augment. 476 The above steps are implemented by the example YANG module for the 477 Routing Information Protocol (RIP) in Appendix C. 479 5.4. Parameters of IPv6 Router Advertisements 481 YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is 482 a submodule of the "ietf-ipv6-unicast-routing" module, augments the 483 configuration and state data of IPv6 interfaces with definitions of 484 the following variables as required by Section 6.2.1 of [RFC4861]: 486 o send-advertisements 488 o max-rtr-adv-interval 490 o min-rtr-adv-interval 492 o managed-flag 494 o other-config-flag 496 o link-mtu 498 o reachable-time 500 o retrans-timer 502 o cur-hop-limit 504 o default-lifetime 506 o prefix-list: a list of prefixes to be advertised. 508 The following parameters are associated with each prefix in the 509 list: 511 * valid-lifetime 513 * on-link-flag 515 * preferred-lifetime 517 * autonomous-flag 519 NOTES: 521 1. The "IsRouter" flag, which is also required by [RFC4861], is 522 implemented in the "ietf-ip" module [I-D.ietf-netmod-rfc7277bis] 523 (leaf "ip:forwarding"). 525 2. The original specification [RFC4861] allows the implementations 526 to decide whether the "valid-lifetime" and "preferred-lifetime" 527 parameters remain the same in consecutive advertisements or 528 decrement in real time. However, the latter behavior seems 529 problematic because the values might be reset again to the 530 (higher) configured values after a configuration is reloaded. 531 Moreover, no implementation is known to use the decrementing 532 behavior. The "ietf-ipv6-router-advertisements" submodule 533 therefore stipulates the former behavior with constant values. 535 6. Interactions with Other YANG Modules 537 The semantics of the core routing data model also depends on several 538 configuration parameters that are defined in other YANG modules. 540 6.1. Module "ietf-interfaces" 542 The following boolean switch is defined in the "ietf-interfaces" YANG 543 module [I-D.ietf-netmod-rfc7223bis]: 545 /if:interfaces/if:interface/if:enabled 547 If this switch is set to "false" for a network-layer interface, 548 then all routing and forwarding functions MUST be disabled on this 549 interface. 551 6.2. Module "ietf-ip" 553 The following boolean switches are defined in the "ietf-ip" YANG 554 module [I-D.ietf-netmod-rfc7277bis]: 556 /if:interfaces/if:interface/ip:ipv4/ip:enabled 558 If this switch is set to "false" for a network-layer interface, 559 then all IPv4 routing and forwarding functions MUST be disabled on 560 this interface. 562 /if:interfaces/if:interface/ip:ipv4/ip:forwarding 564 If this switch is set to "false" for a network-layer interface, 565 then the forwarding of IPv4 datagrams through this interface MUST 566 be disabled. However, the interface MAY participate in other IPv4 567 routing functions, such as routing protocols. 569 /if:interfaces/if:interface/ip:ipv6/ip:enabled 571 If this switch is set to "false" for a network-layer interface, 572 then all IPv6 routing and forwarding functions MUST be disabled on 573 this interface. 575 /if:interfaces/if:interface/ip:ipv6/ip:forwarding 577 If this switch is set to "false" for a network-layer interface, 578 then the forwarding of IPv6 datagrams through this interface MUST 579 be disabled. However, the interface MAY participate in other IPv6 580 routing functions, such as routing protocols. 582 In addition, the "ietf-ip" module allows for configuring IPv4 and 583 IPv6 addresses and network prefixes or masks on network-layer 584 interfaces. Configuration of these parameters on an enabled 585 interface MUST result in an immediate creation of the corresponding 586 direct route. The destination prefix of this route is set according 587 to the configured IP address and network prefix/mask, and the 588 interface is set as the outgoing interface for that route. 590 7. Routing Management YANG Module 592 file "ietf-routing@2017-12-20.yang" 593 module ietf-routing { 594 yang-version "1.1"; 595 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 596 prefix "rt"; 598 import ietf-yang-types { 599 prefix "yang"; 600 } 602 import ietf-interfaces { 603 prefix "if"; 604 description "A Network Management Datastore Architecture (NDMA) 605 compatible version of the ietf-interfaces module 606 is required."; 607 } 609 organization 610 "IETF NETMOD - Networking Modeling Working Group"; 611 contact 612 "WG Web: 613 WG List: 615 Editor: Ladislav Lhotka 616 617 Acee Lindem 618 619 Yingzhen Qu 620 "; 622 description 623 "This YANG module defines essential components for the management 624 of a routing subsystem. The model fully conforms to the Network 625 Management Datastore Architecture (NMDA). 627 Copyright (c) 2017 IETF Trust and the persons 628 identified as authors of the code. All rights reserved. 630 Redistribution and use in source and binary forms, with or 631 without modification, is permitted pursuant to, and subject 632 to the license terms contained in, the Simplified BSD License 633 set forth in Section 4.c of the IETF Trust's Legal Provisions 634 Relating to IETF Documents 635 (http://trustee.ietf.org/license-info). 637 This version of this YANG module is part of RFC XXXX; see 638 the RFC itself for full legal notices."; 639 reference "RFC XXXX"; 641 revision 2017-12-20 { 642 description 643 "Network Managment Datastore Architecture (NDMA) Revision"; 644 reference 645 "RFC XXXX: A YANG Data Model for Routing Management 646 (NDMA Version)"; 647 } 649 revision 2016-11-04 { 650 description 651 "Initial revision."; 653 reference 654 "RFC 8022: A YANG Data Model for Routing Management"; 655 } 657 /* Features */ 658 feature multiple-ribs { 659 description 660 "This feature indicates that the server supports user-defined 661 RIBs. 663 Servers that do not advertise this feature SHOULD provide 664 exactly one system-controlled RIB per supported address family 665 and make it also the default RIB. This RIB then appears as an 666 entry of the list /routing/ribs/rib."; 667 } 669 feature router-id { 670 description 671 "This feature indicates that the server supports configuration 672 of an explicit 32-bit router ID that is used by some routing 673 protocols. 675 Servers that do not advertise this feature set a router ID 676 algorithmically, usually to one of the configured IPv4 677 addresses. However, this algorithm is implementation 678 specific."; 679 } 681 /* Identities */ 683 identity address-family { 684 description 685 "Base identity from which identities describing address 686 families are derived."; 687 } 689 identity ipv4 { 690 base address-family; 691 description 692 "This identity represents IPv4 address family."; 693 } 695 identity ipv6 { 696 base address-family; 697 description 698 "This identity represents IPv6 address family."; 699 } 700 identity control-plane-protocol { 701 description 702 "Base identity from which control-plane protocol identities are 703 derived."; 704 } 706 identity routing-protocol { 707 base control-plane-protocol; 708 description 709 "Identity from which Layer 3 routing protocol identities are 710 derived."; 711 } 713 identity direct { 714 base routing-protocol; 715 description 716 "Routing pseudo-protocol that provides routes to directly 717 connected networks."; 718 } 720 identity static { 721 base routing-protocol; 722 description 723 "Static routing pseudo-protocol."; 724 } 726 /* Type Definitions */ 728 typedef route-preference { 729 type uint32; 730 description 731 "This type is used for route preferences."; 732 } 734 /* Groupings */ 736 grouping address-family { 737 description 738 "This grouping provides a leaf identifying an address 739 family."; 740 leaf address-family { 741 type identityref { 742 base address-family; 743 } 744 mandatory "true"; 745 description 746 "Address family."; 747 } 749 } 751 grouping router-id { 752 description 753 "This grouping provides router ID."; 754 leaf router-id { 755 type yang:dotted-quad; 756 description 757 "A 32-bit number in the form of a dotted quad that is used by 758 some routing protocols identifying a router."; 759 reference 760 "RFC 2328: OSPF Version 2."; 761 } 762 } 764 grouping special-next-hop { 765 description 766 "This grouping provides a leaf with an enumeration of special 767 next hops."; 768 leaf special-next-hop { 769 type enumeration { 770 enum blackhole { 771 description 772 "Silently discard the packet."; 773 } 774 enum unreachable { 775 description 776 "Discard the packet and notify the sender with an error 777 message indicating that the destination host is 778 unreachable."; 779 } 780 enum prohibit { 781 description 782 "Discard the packet and notify the sender with an error 783 message indicating that the communication is 784 administratively prohibited."; 785 } 786 enum receive { 787 description 788 "The packet will be received by the local system."; 789 } 790 } 791 description 792 "Options for special next hops."; 793 } 794 } 796 grouping next-hop-content { 797 description 798 "Generic parameters of next hops in static routes."; 799 choice next-hop-options { 800 mandatory "true"; 801 description 802 "Options for next hops in static routes. 804 It is expected that further cases will be added through 805 augments from other modules."; 806 case simple-next-hop { 807 description 808 "This case represents a simple next hop consisting of the 809 next-hop address and/or outgoing interface. 811 Modules for address families MUST augment this case with a 812 leaf containing a next-hop address of that address 813 family."; 814 leaf outgoing-interface { 815 type if:interface-ref; 816 description 817 "Name of the outgoing interface."; 818 } 819 } 820 case special-next-hop { 821 uses special-next-hop; 822 } 823 case next-hop-list { 824 container next-hop-list { 825 description 826 "Container for multiple next-hops."; 827 list next-hop { 828 key "index"; 829 description 830 "An entry of a next-hop list. 832 Modules for address families MUST augment this list 833 with a leaf containing a next-hop address of that 834 address family."; 835 leaf index { 836 type string; 837 description 838 "A user-specified identifier utilized to uniquely 839 reference the next-hop entry in the next-hop list. 840 The value of this index has no semantic meaning 841 other than for referencing the entry."; 842 } 843 leaf outgoing-interface { 844 type if:interface-ref; 845 description 846 "Name of the outgoing interface."; 847 } 848 } 849 } 850 } 851 } 852 } 854 grouping next-hop-state-content { 855 description 856 "Generic parameters of next hops in state data."; 857 choice next-hop-options { 858 mandatory "true"; 859 description 860 "Options for next hops in state data. 862 It is expected that further cases will be added through 863 augments from other modules, e.g., for recursive 864 next hops."; 865 case simple-next-hop { 866 description 867 "This case represents a simple next hop consisting of the 868 next-hop address and/or outgoing interface. 870 Modules for address families MUST augment this case with a 871 leaf containing a next-hop address of that address 872 family."; 873 leaf outgoing-interface { 874 type if:interface-ref; 875 description 876 "Name of the outgoing interface."; 877 } 878 } 879 case special-next-hop { 880 uses special-next-hop; 881 } 882 case next-hop-list { 883 container next-hop-list { 884 description 885 "Container for multiple next hops."; 886 list next-hop { 887 description 888 "An entry of a next-hop list. 890 Modules for address families MUST augment this list 891 with a leaf containing a next-hop address of that 892 address family."; 894 leaf outgoing-interface { 895 type if:interface-ref; 896 description 897 "Name of the outgoing interface."; 898 } 899 } 900 } 901 } 902 } 903 } 905 grouping route-metadata { 906 description 907 "Common route metadata."; 908 leaf source-protocol { 909 type identityref { 910 base routing-protocol; 911 } 912 mandatory "true"; 913 description 914 "Type of the routing protocol from which the route 915 originated."; 916 } 917 leaf active { 918 type empty; 919 description 920 "Presence of this leaf indicates that the route is preferred 921 among all routes in the same RIB that have the same 922 destination prefix."; 923 } 924 leaf last-updated { 925 type yang:date-and-time; 926 description 927 "Time stamp of the last modification of the route. If the 928 route was never modified, it is the time when the route was 929 inserted into the RIB."; 930 } 931 } 933 /* Data nodes */ 935 container routing { 936 description 937 "Configuration parameters for the routing subsystem."; 938 uses router-id { 939 if-feature "router-id"; 940 description 941 "Configuration of the global router ID. Routing protocols 942 that use router ID can use this parameter or override it 943 with another value."; 944 } 945 container interfaces { 946 config "false"; 947 description 948 "Network-layer interfaces used for routing."; 949 leaf-list interface { 950 type if:interface-ref; 951 description 952 "Each entry is a reference to the name of a configured 953 network-layer interface."; 954 } 955 } 956 container control-plane-protocols { 957 description 958 "Configuration of control-plane protocol instances."; 959 list control-plane-protocol { 960 key "type name"; 961 description 962 "Each entry contains configuration of a control-plane 963 protocol instance."; 964 leaf type { 965 type identityref { 966 base control-plane-protocol; 967 } 968 description 969 "Type of the control-plane protocol - an identity derived 970 from the 'control-plane-protocol' base identity."; 971 } 972 leaf name { 973 type string; 974 description 975 "An arbitrary name of the control-plane protocol 976 instance."; 977 } 978 leaf description { 979 type string; 980 description 981 "Textual description of the control-plane protocol 982 instance."; 983 } 984 container static-routes { 985 when "derived-from-or-self(../type, 'rt:static')" { 986 description 987 "This container is only valid for the 'static' routing 988 protocol."; 989 } 990 description 991 "Configuration of the 'static' pseudo-protocol. 993 Address-family-specific modules augment this node with 994 their lists of routes."; 995 } 996 } 997 } 998 container ribs { 999 description 1000 "Configuration of RIBs."; 1001 list rib { 1002 key "name"; 1003 description 1004 "Each entry contains configuration for a RIB identified by 1005 the 'name' key. 1007 Entries having the same key as a system-controlled entry 1008 of the list /routing/ribs/rib are used for 1009 configuring parameters of that entry. Other entries 1010 define additional user-controlled RIBs."; 1011 leaf name { 1012 type string; 1013 description 1014 "The name of the RIB. 1016 For system-controlled entries, the value of this leaf 1017 must be the same as the name of the corresponding entry 1018 in state data. 1020 For user-controlled entries, an arbitrary name can be 1021 used."; 1022 } 1023 uses address-family { 1024 description 1025 "The address family of the system-controlled RIB."; 1026 } 1028 leaf default-rib { 1029 if-feature "multiple-ribs"; 1030 type boolean; 1031 default "true"; 1032 config "false"; 1033 description 1034 "This flag has the value of 'true' if and only if the RIB 1035 is the default RIB for the given address family. 1037 By default, control-plane protocols place their routes 1038 in the default RIBs."; 1039 } 1040 container routes { 1041 config "false"; 1042 description 1043 "Current content of the RIB."; 1044 list route { 1045 description 1046 "A RIB route entry. This data node MUST be augmented 1047 with information specific for routes of each address 1048 family."; 1049 leaf route-preference { 1050 type route-preference; 1051 description 1052 "This route attribute, also known as administrative 1053 distance, allows for selecting the preferred route 1054 among routes with the same destination prefix. A 1055 smaller value means a more preferred route."; 1056 } 1057 container next-hop { 1058 description 1059 "Route's next-hop attribute."; 1060 uses next-hop-state-content; 1061 } 1062 uses route-metadata; 1063 } 1064 } 1065 action active-route { 1066 description 1067 "Return the active RIB route that is used for the 1068 destination address. 1070 Address-family-specific modules MUST augment input 1071 parameters with a leaf named 'destination-address'."; 1072 output { 1073 container route { 1074 description 1075 "The active RIB route for the specified destination. 1077 If no route exists in the RIB for the destination 1078 address, no output is returned. 1080 Address-family-specific modules MUST augment this 1081 container with appropriate route contents."; 1082 container next-hop { 1083 description 1084 "Route's next-hop attribute."; 1085 uses next-hop-state-content; 1087 } 1088 uses route-metadata; 1089 } 1090 } 1091 } 1092 leaf description { 1093 type string; 1094 description 1095 "Textual description of the RIB."; 1096 } 1097 } 1098 } 1099 } 1101 /* Obsolete State Data */ 1103 container routing-state { 1104 config false; 1105 status obsolete; 1106 description 1107 "State data of the routing subsystem."; 1108 uses router-id { 1109 status obsolete; 1110 description 1111 "Global router ID. 1113 It may be either configured or assigned algorithmically by 1114 the implementation."; 1115 } 1116 container interfaces { 1117 status obsolete; 1118 description 1119 "Network-layer interfaces used for routing."; 1120 leaf-list interface { 1121 type if:interface-state-ref; 1122 status obsolete; 1123 description 1124 "Each entry is a reference to the name of a configured 1125 network-layer interface."; 1126 } 1127 } 1128 container control-plane-protocols { 1129 status obsolete; 1130 description 1131 "Container for the list of routing protocol instances."; 1132 list control-plane-protocol { 1133 key "type name"; 1134 status obsolete; 1135 description 1136 "State data of a control-plane protocol instance. 1138 An implementation MUST provide exactly one 1139 system-controlled instance of the 'direct' 1140 pseudo-protocol. Instances of other control-plane 1141 protocols MAY be created by configuration."; 1142 leaf type { 1143 type identityref { 1144 base control-plane-protocol; 1145 } 1146 status obsolete; 1147 description 1148 "Type of the control-plane protocol."; 1149 } 1150 leaf name { 1151 type string; 1152 status obsolete; 1153 description 1154 "The name of the control-plane protocol instance. 1156 For system-controlled instances this name is 1157 persistent, i.e., it SHOULD NOT change across 1158 reboots."; 1159 } 1160 } 1161 } 1162 container ribs { 1163 status obsolete; 1164 description 1165 "Container for RIBs."; 1166 list rib { 1167 key "name"; 1168 min-elements 1; 1169 status obsolete; 1170 description 1171 "Each entry represents a RIB identified by the 'name' 1172 key. All routes in a RIB MUST belong to the same address 1173 family. 1175 An implementation SHOULD provide one system-controlled 1176 default RIB for each supported address family."; 1177 leaf name { 1178 type string; 1179 status obsolete; 1180 description 1181 "The name of the RIB."; 1182 } 1183 uses address-family { 1184 status obsolete; 1185 description 1186 "The address family of the RIB."; 1187 } 1188 leaf default-rib { 1189 if-feature "multiple-ribs"; 1190 type boolean; 1191 default "true"; 1192 status obsolete; 1193 description 1194 "This flag has the value of 'true' if and only if the 1195 RIB is the default RIB for the given address family. 1197 By default, control-plane protocols place their routes 1198 in the default RIBs."; 1199 } 1200 container routes { 1201 status obsolete; 1202 description 1203 "Current content of the RIB."; 1204 list route { 1205 status obsolete; 1206 description 1207 "A RIB route entry. This data node MUST be augmented 1208 with information specific for routes of each address 1209 family."; 1210 leaf route-preference { 1211 type route-preference; 1212 status obsolete; 1213 description 1214 "This route attribute, also known as administrative 1215 distance, allows for selecting the preferred route 1216 among routes with the same destination prefix. A 1217 smaller value means a more preferred route."; 1218 } 1219 container next-hop { 1220 status obsolete; 1221 description 1222 "Route's next-hop attribute."; 1223 uses next-hop-state-content { 1224 status obsolete; 1225 description 1226 "Route's next-hop attribute operational state."; 1227 } 1228 } 1229 uses route-metadata { 1230 status obsolete; 1231 description 1232 "Route metadata."; 1233 } 1234 } 1235 } 1236 action active-route { 1237 status obsolete; 1238 description 1239 "Return the active RIB route that is used for the 1240 destination address. 1242 Address-family-specific modules MUST augment input 1243 parameters with a leaf named 'destination-address'."; 1244 output { 1245 container route { 1246 status obsolete; 1247 description 1248 "The active RIB route for the specified 1249 destination. 1251 If no route exists in the RIB for the destination 1252 address, no output is returned. 1254 Address-family-specific modules MUST augment this 1255 container with appropriate route contents."; 1256 container next-hop { 1257 status obsolete; 1258 description 1259 "Route's next-hop attribute."; 1260 uses next-hop-state-content { 1261 status obsolete; 1262 description 1263 "Active route state data."; 1264 } 1265 } 1266 uses route-metadata { 1267 status obsolete; 1268 description 1269 "Active route metadata."; 1270 } 1271 } 1272 } 1273 } 1274 } 1275 } 1276 } 1277 } 1278 1280 8. IPv4 Unicast Routing Management YANG Module 1282 file "ietf-ipv4-unicast-routing@2017-12-20.yang" 1283 module ietf-ipv4-unicast-routing { 1284 yang-version "1.1"; 1285 namespace 1286 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1287 prefix "v4ur"; 1289 import ietf-routing { 1290 prefix "rt"; 1291 description "A Network Management Datastore Architecture (NDMA) 1292 compatible version of the ietf-routing module 1293 is required."; 1294 } 1296 import ietf-inet-types { 1297 prefix "inet"; 1298 } 1299 organization 1300 "IETF NETMOD - Networking Modeling Working Group"; 1301 contact 1302 "WG Web: 1303 WG List: 1305 Editor: Ladislav Lhotka 1306 1307 Acee Lindem 1308 1309 Yingzhen Qu 1310 "; 1312 description 1313 "This YANG module augments the 'ietf-routing' module with basic 1314 configuration and state data for IPv4 unicast routing. The 1315 model fully conforms to the Network Management Datastore 1316 Architecture (NMDA). 1318 Copyright (c) 2017 IETF Trust and the persons 1319 identified as authors of the code. All rights reserved. 1321 Redistribution and use in source and binary forms, with or 1322 without modification, is permitted pursuant to, and subject 1323 to the license terms contained in, the Simplified BSD License 1324 set forth in Section 4.c of the IETF Trust's Legal Provisions 1325 Relating to IETF Documents 1326 (http://trustee.ietf.org/license-info). 1327 This version of this YANG module is part of RFC XXXX; see 1328 the RFC itself for full legal notices."; 1329 reference "RFC XXXX"; 1331 revision 2017-12-20 { 1332 description 1333 "Network Managment Datastore Architecture (NDMA) Revision"; 1334 reference 1335 "RFC XXXX: A YANG Data Model for Routing Management 1336 (NDMA Version)"; 1337 } 1339 revision 2016-11-04 { 1340 description 1341 "Initial revision."; 1342 reference 1343 "RFC 8022: A YANG Data Model for Routing Management"; 1344 } 1346 /* Identities */ 1348 identity ipv4-unicast { 1349 base rt:ipv4; 1350 description 1351 "This identity represents the IPv4 unicast address family."; 1352 } 1354 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { 1355 when "derived-from-or-self(../../rt:address-family, " 1356 + "'v4ur:ipv4-unicast')" { 1357 description 1358 "This augment is valid only for IPv4 unicast."; 1359 } 1360 description 1361 "This leaf augments an IPv4 unicast route."; 1362 leaf destination-prefix { 1363 type inet:ipv4-prefix; 1364 description 1365 "IPv4 destination prefix."; 1366 } 1367 } 1369 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1370 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1371 when "derived-from-or-self(../../../rt:address-family, " 1372 + "'v4ur:ipv4-unicast')" { 1373 description 1374 "This augment is valid only for IPv4 unicast."; 1376 } 1377 description 1378 "Augment 'simple-next-hop' case in IPv4 unicast routes."; 1379 leaf next-hop-address { 1380 type inet:ipv4-address; 1381 description 1382 "IPv4 address of the next hop."; 1383 } 1384 } 1386 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1387 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1388 + "rt:next-hop-list/rt:next-hop" { 1389 when "derived-from-or-self(../../../../../rt:address-family, " 1390 + "'v4ur:ipv4-unicast')" { 1391 description 1392 "This augment is valid only for IPv4 unicast."; 1393 } 1394 description 1395 "This leaf augments the 'next-hop-list' case of IPv4 unicast 1396 routes."; 1397 leaf address { 1398 type inet:ipv4-address; 1399 description 1400 "IPv4 address of the next-hop."; 1401 } 1402 } 1404 augment 1405 "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { 1406 when "derived-from-or-self(../rt:address-family, " 1407 + "'v4ur:ipv4-unicast')" { 1408 description 1409 "This augment is valid only for IPv4 unicast RIBs."; 1410 } 1411 description 1412 "This augment adds the input parameter of the 'active-route' 1413 action."; 1414 leaf destination-address { 1415 type inet:ipv4-address; 1416 description 1417 "IPv4 destination address."; 1418 } 1419 } 1421 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1422 + "rt:output/rt:route" { 1423 when "derived-from-or-self(../../rt:address-family, " 1424 + "'v4ur:ipv4-unicast')" { 1425 description 1426 "This augment is valid only for IPv4 unicast."; 1427 } 1428 description 1429 "This augment adds the destination prefix to the reply of the 1430 'active-route' action."; 1431 leaf destination-prefix { 1432 type inet:ipv4-prefix; 1433 description 1434 "IPv4 destination prefix."; 1435 } 1436 } 1438 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1439 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1440 + "rt:simple-next-hop" { 1441 when "derived-from-or-self(../../../rt:address-family, " 1442 + "'v4ur:ipv4-unicast')" { 1443 description 1444 "This augment is valid only for IPv4 unicast."; 1445 } 1446 description 1447 "Augment 'simple-next-hop' case in the reply to the 1448 'active-route' action."; 1449 leaf next-hop-address { 1450 type inet:ipv4-address; 1451 description 1452 "IPv4 address of the next hop."; 1453 } 1454 } 1456 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1457 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1458 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1459 when "derived-from-or-self(../../../../../rt:address-family, " 1460 + "'v4ur:ipv4-unicast')" { 1461 description 1462 "This augment is valid only for IPv4 unicast."; 1463 } 1464 description 1465 "Augment 'next-hop-list' case in the reply to the 1466 'active-route' action."; 1467 leaf next-hop-address { 1468 type inet:ipv4-address; 1469 description 1470 "IPv4 address of the next hop."; 1471 } 1473 } 1475 augment "/rt:routing/rt:control-plane-protocols/" 1476 + "rt:control-plane-protocol/rt:static-routes" { 1477 description 1478 "This augment defines the configuration of the 'static' 1479 pseudo-protocol with data specific to IPv4 unicast."; 1480 container ipv4 { 1481 description 1482 "Configuration of a 'static' pseudo-protocol instance 1483 consists of a list of routes."; 1484 list route { 1485 key "destination-prefix"; 1486 description 1487 "A list of static routes."; 1488 leaf destination-prefix { 1489 type inet:ipv4-prefix; 1490 mandatory "true"; 1491 description 1492 "IPv4 destination prefix."; 1493 } 1494 leaf description { 1495 type string; 1496 description 1497 "Textual description of the route."; 1498 } 1499 container next-hop { 1500 description 1501 "Configuration of next-hop."; 1502 uses rt:next-hop-content { 1503 augment "next-hop-options/simple-next-hop" { 1504 description 1505 "Augment 'simple-next-hop' case in IPv4 static 1506 routes."; 1507 leaf next-hop-address { 1508 type inet:ipv4-address; 1509 description 1510 "IPv4 address of the next hop."; 1511 } 1512 } 1513 augment "next-hop-options/next-hop-list/next-hop-list/" 1514 + "next-hop" { 1515 description 1516 "Augment 'next-hop-list' case in IPv4 static 1517 routes."; 1518 leaf next-hop-address { 1519 type inet:ipv4-address; 1520 description 1521 "IPv4 address of the next hop."; 1522 } 1523 } 1524 } 1525 } 1526 } 1527 } 1528 } 1530 /* Obsolete State Data */ 1532 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1533 when "derived-from-or-self(../../rt:address-family, " 1534 + "'v4ur:ipv4-unicast')" { 1535 description 1536 "This augment is valid only for IPv4 unicast."; 1537 } 1538 status obsolete; 1539 description 1540 "This leaf augments an IPv4 unicast route."; 1541 leaf destination-prefix { 1542 type inet:ipv4-prefix; 1543 status obsolete; 1544 description 1545 "IPv4 destination prefix."; 1546 } 1547 } 1548 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1549 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1550 when "derived-from-or-self( 1551 ../../../rt:address-family, 'v4ur:ipv4-unicast')" { 1552 description 1553 "This augment is valid only for IPv4 unicast."; 1554 } 1555 status obsolete; 1556 description 1557 "Augment 'simple-next-hop' case in IPv4 unicast routes."; 1558 leaf next-hop-address { 1559 type inet:ipv4-address; 1560 status obsolete; 1561 description 1562 "IPv4 address of the next hop."; 1563 } 1564 } 1565 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1566 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1567 + "rt:next-hop-list/rt:next-hop" { 1568 when "derived-from-or-self(../../../../../rt:address-family, 1569 'v4ur:ipv4-unicast')" { 1570 description 1571 "This augment is valid only for IPv4 unicast."; 1572 } 1573 status obsolete; 1574 description 1575 "This leaf augments the 'next-hop-list' case of IPv4 unicast 1576 routes."; 1577 leaf address { 1578 type inet:ipv4-address; 1579 status obsolete; 1580 description 1581 "IPv4 address of the next-hop."; 1582 } 1583 } 1584 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1585 + "rt:input" { 1586 when "derived-from-or-self(../rt:address-family, 1587 'v4ur:ipv4-unicast')" { 1588 description 1589 "This augment is valid only for IPv4 unicast RIBs."; 1590 } 1591 status obsolete; 1592 description 1593 "This augment adds the input parameter of the 'active-route' 1594 action."; 1595 leaf destination-address { 1596 type inet:ipv4-address; 1597 status obsolete; 1598 description 1599 "IPv4 destination address."; 1600 } 1601 } 1602 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1603 + "rt:output/rt:route" { 1604 when "derived-from-or-self(../../rt:address-family, 1605 'v4ur:ipv4-unicast')" { 1606 description 1607 "This augment is valid only for IPv4 unicast."; 1608 } 1609 status obsolete; 1610 description 1611 "This augment adds the destination prefix to the reply of the 1612 'active-route' action."; 1613 leaf destination-prefix { 1614 type inet:ipv4-prefix; 1615 status obsolete; 1616 description 1617 "IPv4 destination prefix."; 1618 } 1619 } 1620 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1621 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1622 + "rt:simple-next-hop" { 1623 when "derived-from-or-self(../../../rt:address-family, 1624 'v4ur:ipv4-unicast')" { 1625 description 1626 "This augment is valid only for IPv4 unicast."; 1627 } 1628 status obsolete; 1629 description 1630 "Augment 'simple-next-hop' case in the reply to the 1631 'active-route' action."; 1632 leaf next-hop-address { 1633 type inet:ipv4-address; 1634 status obsolete; 1635 description 1636 "IPv4 address of the next hop."; 1637 } 1638 } 1639 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1640 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1641 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1642 when "derived-from-or-self(../../../../../rt:address-family, 1643 'v4ur:ipv4-unicast')" { 1644 description 1645 "This augment is valid only for IPv4 unicast."; 1646 } 1647 status obsolete; 1648 description 1649 "Augment 'next-hop-list' case in the reply to the 1650 'active-route' action."; 1651 leaf next-hop-address { 1652 type inet:ipv4-address; 1653 status obsolete; 1654 description 1655 "IPv4 address of the next hop."; 1656 } 1657 } 1658 } 1659 1661 9. IPv6 Unicast Routing Management YANG Module 1663 file "ietf-ipv6-unicast-routing@2017-12-20.yang" 1664 module ietf-ipv6-unicast-routing { 1665 yang-version "1.1"; 1666 namespace 1667 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1668 prefix "v6ur"; 1670 import ietf-routing { 1671 prefix "rt"; 1672 description "A Network Management Datastore Architecture (NDMA) 1673 compatible version of the ietf-routing module 1674 is required."; 1675 } 1677 import ietf-inet-types { 1678 prefix "inet"; 1679 description "A Network Management Datastore Architecture (NDMA) 1680 compatible version of the ietf-interfaces module 1681 is required."; 1682 } 1684 include ietf-ipv6-router-advertisements { 1685 revision-date 2017-12-20; 1686 } 1688 organization 1689 "IETF NETMOD - Networking Modeling Working Group"; 1690 contact 1691 "WG Web: 1692 WG List: 1694 Editor: Ladislav Lhotka 1695 1696 Acee Lindem 1697 1698 Yingzhen Qu 1699 "; 1701 description 1702 "This YANG module augments the 'ietf-routing' module with basic 1703 configuration and state data for IPv6 unicast routing. The 1704 model fully conforms to the Network Management Datastore 1705 Architecture (NMDA). 1707 Copyright (c) 2017 IETF Trust and the persons 1708 identified as authors of the code. All rights reserved. 1710 Redistribution and use in source and binary forms, with or 1711 without modification, is permitted pursuant to, and subject 1712 to the license terms contained in, the Simplified BSD License 1713 set forth in Section 4.c of the IETF Trust's Legal Provisions 1714 Relating to IETF Documents 1715 (http://trustee.ietf.org/license-info). 1717 This version of this YANG module is part of RFC XXXX; see 1718 the RFC itself for full legal notices."; 1719 reference "RFC XXXX"; 1721 revision 2017-12-20 { 1722 description 1723 "Network Managment Datastore Architecture (NDMA) revision"; 1724 reference 1725 "RFC XXXX: A YANG Data Model for Routing Management 1726 (NDMA Version)"; 1727 } 1729 /* Identities */ 1731 revision 2016-11-04 { 1732 description 1733 "Initial revision."; 1734 reference 1735 "RFC 8022: A YANG Data Model for Routing Management"; 1736 } 1738 identity ipv6-unicast { 1739 base rt:ipv6; 1740 description 1741 "This identity represents the IPv6 unicast address family."; 1742 } 1744 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { 1745 when "derived-from-or-self(../../rt:address-family, " 1746 + "'v6ur:ipv6-unicast')" { 1747 description 1748 "This augment is valid only for IPv6 unicast."; 1749 } 1750 description 1751 "This leaf augments an IPv6 unicast route."; 1752 leaf destination-prefix { 1753 type inet:ipv6-prefix; 1754 description 1755 "IPv6 destination prefix."; 1756 } 1757 } 1758 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1759 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1760 when "derived-from-or-self(../../../rt:address-family, " 1761 + "'v6ur:ipv6-unicast')" { 1762 description 1763 "This augment is valid only for IPv6 unicast."; 1764 } 1765 description 1766 "Augment 'simple-next-hop' case in IPv6 unicast routes."; 1767 leaf next-hop-address { 1768 type inet:ipv6-address; 1769 description 1770 "IPv6 address of the next hop."; 1771 } 1772 } 1774 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 1775 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1776 + "rt:next-hop-list/rt:next-hop" { 1777 when "derived-from-or-self(../../../../../rt:address-family, " 1778 + "'v6ur:ipv6-unicast')" { 1779 description 1780 "This augment is valid only for IPv6 unicast."; 1781 } 1782 description 1783 "This leaf augments the 'next-hop-list' case of IPv6 unicast 1784 routes."; 1785 leaf address { 1786 type inet:ipv6-address; 1787 description 1788 "IPv6 address of the next hop."; 1789 } 1790 } 1792 augment 1793 "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { 1794 when "derived-from-or-self(../rt:address-family, " 1795 + "'v6ur:ipv6-unicast')" { 1796 description 1797 "This augment is valid only for IPv6 unicast RIBs."; 1798 } 1799 description 1800 "This augment adds the input parameter of the 'active-route' 1801 action."; 1802 leaf destination-address { 1803 type inet:ipv6-address; 1804 description 1805 "IPv6 destination address."; 1807 } 1808 } 1810 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1811 + "rt:output/rt:route" { 1812 when "derived-from-or-self(../../rt:address-family, " 1813 + "'v6ur:ipv6-unicast')" { 1814 description 1815 "This augment is valid only for IPv6 unicast."; 1816 } 1817 description 1818 "This augment adds the destination prefix to the reply of the 1819 'active-route' action."; 1820 leaf destination-prefix { 1821 type inet:ipv6-prefix; 1822 description 1823 "IPv6 destination prefix."; 1824 } 1825 } 1827 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1828 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1829 + "rt:simple-next-hop" { 1830 when "derived-from-or-self(../../../rt:address-family, " 1831 + "'v6ur:ipv6-unicast')" { 1832 description 1833 "This augment is valid only for IPv6 unicast."; 1834 } 1835 description 1836 "Augment 'simple-next-hop' case in the reply to the 1837 'active-route' action."; 1838 leaf next-hop-address { 1839 type inet:ipv6-address; 1840 description 1841 "IPv6 address of the next hop."; 1842 } 1843 } 1845 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 1846 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 1847 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 1848 when "derived-from-or-self(../../../../../rt:address-family, " 1849 + "'v6ur:ipv6-unicast')" { 1850 description 1851 "This augment is valid only for IPv6 unicast."; 1852 } 1853 description 1854 "Augment 'next-hop-list' case in the reply to the 1855 'active-route' action."; 1856 leaf next-hop-address { 1857 type inet:ipv6-address; 1858 description 1859 "IPv6 address of the next hop."; 1860 } 1861 } 1863 /* Data node augmentations */ 1865 augment "/rt:routing/rt:control-plane-protocols/" 1866 + "rt:control-plane-protocol/rt:static-routes" { 1867 description 1868 "This augment defines the configuration of the 'static' 1869 pseudo-protocol with data specific to IPv6 unicast."; 1870 container ipv6 { 1871 description 1872 "Configuration of a 'static' pseudo-protocol instance 1873 consists of a list of routes."; 1874 list route { 1875 key "destination-prefix"; 1876 description 1877 "A list of static routes."; 1878 leaf destination-prefix { 1879 type inet:ipv6-prefix; 1880 mandatory "true"; 1881 description 1882 "IPv6 destination prefix."; 1883 } 1884 leaf description { 1885 type string; 1886 description 1887 "Textual description of the route."; 1888 } 1889 container next-hop { 1890 description 1891 "Configuration of next-hop."; 1892 uses rt:next-hop-content { 1893 augment "next-hop-options/simple-next-hop" { 1894 description 1895 "Augment 'simple-next-hop' case in IPv6 static 1896 routes."; 1897 leaf next-hop-address { 1898 type inet:ipv6-address; 1899 description 1900 "IPv6 address of the next hop."; 1901 } 1902 } 1903 augment "next-hop-options/next-hop-list/next-hop-list/" 1904 + "next-hop" { 1905 description 1906 "Augment 'next-hop-list' case in IPv6 static 1907 routes."; 1908 leaf next-hop-address { 1909 type inet:ipv6-address; 1910 description 1911 "IPv6 address of the next hop."; 1912 } 1913 } 1914 } 1915 } 1916 } 1917 } 1918 } 1920 /* Obsolete State Data */ 1922 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { 1923 when "derived-from-or-self(../../rt:address-family, 1924 'v6ur:ipv6-unicast')" { 1925 description 1926 "This augment is valid only for IPv6 unicast."; 1927 } 1928 status obsolete; 1929 description 1930 "This leaf augments an IPv6 unicast route."; 1931 leaf destination-prefix { 1932 type inet:ipv6-prefix; 1933 status obsolete; 1934 description 1935 "IPv6 destination prefix."; 1936 } 1937 } 1938 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1939 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 1940 when "derived-from-or-self(../../../rt:address-family, 1941 'v6ur:ipv6-unicast')" { 1942 description 1943 "This augment is valid only for IPv6 unicast."; 1944 } 1945 status obsolete; 1946 description 1947 "Augment 'simple-next-hop' case in IPv6 unicast routes."; 1948 leaf next-hop-address { 1949 type inet:ipv6-address; 1950 status obsolete; 1951 description 1952 "IPv6 address of the next hop."; 1953 } 1954 } 1955 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/" 1956 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 1957 + "rt:next-hop-list/rt:next-hop" { 1958 when "derived-from-or-self(../../../../../rt:address-family, 1959 'v6ur:ipv6-unicast')" { 1960 description 1961 "This augment is valid only for IPv6 unicast."; 1962 } 1963 status obsolete; 1964 description 1965 "This leaf augments the 'next-hop-list' case of IPv6 unicast 1966 routes."; 1967 leaf address { 1968 type inet:ipv6-address; 1969 status obsolete; 1970 description 1971 "IPv6 address of the next hop."; 1972 } 1973 } 1974 augment "/rt:routing-state/rt:ribs/rt:rib/" 1975 + "rt:active-route/rt:input" { 1976 when "derived-from-or-self(../rt:address-family, 1977 'v6ur:ipv6-unicast')" { 1978 description 1979 "This augment is valid only for IPv6 unicast RIBs."; 1980 } 1981 status obsolete; 1982 description 1983 "This augment adds the input parameter of the 'active-route' 1984 action."; 1985 leaf destination-address { 1986 type inet:ipv6-address; 1987 status obsolete; 1988 description 1989 "IPv6 destination address."; 1990 } 1991 } 1992 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 1993 + "rt:output/rt:route" { 1994 when "derived-from-or-self(../../rt:address-family, 1995 'v6ur:ipv6-unicast')" { 1996 description 1997 "This augment is valid only for IPv6 unicast."; 1998 } 1999 status obsolete; 2000 description 2001 "This augment adds the destination prefix to the reply of the 2002 'active-route' action."; 2003 leaf destination-prefix { 2004 type inet:ipv6-prefix; 2005 status obsolete; 2006 description 2007 "IPv6 destination prefix."; 2008 } 2009 } 2010 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 2011 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 2012 + "rt:simple-next-hop" { 2013 when "derived-from-or-self(../../../rt:address-family, 2014 'v6ur:ipv6-unicast')" { 2015 description 2016 "This augment is valid only for IPv6 unicast."; 2017 } 2018 status obsolete; 2019 description 2020 "Augment 'simple-next-hop' case in the reply to the 2021 'active-route' action."; 2022 leaf next-hop-address { 2023 type inet:ipv6-address; 2024 status obsolete; 2025 description 2026 "IPv6 address of the next hop."; 2027 } 2028 } 2029 augment "/rt:routing-state/rt:ribs/rt:rib/rt:active-route/" 2030 + "rt:output/rt:route/rt:next-hop/rt:next-hop-options/" 2031 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" { 2032 when "derived-from-or-self(../../../../../rt:address-family, 2033 'v6ur:ipv6-unicast')" { 2034 description 2035 "This augment is valid only for IPv6 unicast."; 2036 } 2037 status obsolete; 2038 description 2039 "Augment 'next-hop-list' case in the reply to the 2040 'active-route' action."; 2041 leaf next-hop-address { 2042 type inet:ipv6-address; 2043 status obsolete; 2044 description 2045 "IPv6 address of the next hop."; 2046 } 2048 } 2049 } 2050 2052 9.1. IPv6 Router Advertisements Submodule 2054 file "ietf-ipv6-router-advertisements@2017-12-20.yang" 2055 submodule ietf-ipv6-router-advertisements { 2056 yang-version "1.1"; 2058 belongs-to ietf-ipv6-unicast-routing { 2059 prefix "v6ur"; 2060 } 2062 import ietf-inet-types { 2063 prefix "inet"; 2064 } 2066 import ietf-interfaces { 2067 prefix "if"; 2068 description "A Network Management Datastore Architecture (NDMA) 2069 compatible version of the ietf-interfaces module 2070 is required."; 2071 } 2073 import ietf-ip { 2074 prefix "ip"; 2075 description "A Network Management Datastore Architecture (NDMA) 2076 compatible version of the ietf-ip module is 2077 required."; 2078 } 2080 organization 2081 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 2082 contact 2083 "WG Web: 2084 WG List: 2086 Editor: Ladislav Lhotka 2087 2088 Acee Lindem 2089 2090 Yingzhen Qu 2091 "; 2093 description 2094 "This YANG module augments the 'ietf-ip' module with 2095 configuration and state data of IPv6 router advertisements. 2097 The model fully conforms to the Network Management Datastore 2098 Architecture (NMDA). 2100 Copyright (c) 2017 IETF Trust and the persons 2101 identified as authors of the code. All rights reserved. 2103 Redistribution and use in source and binary forms, with or 2104 without modification, is permitted pursuant to, and subject 2105 to the license terms contained in, the Simplified BSD License 2106 set forth in Section 4.c of the IETF Trust's Legal Provisions 2107 Relating to IETF Documents 2108 (http://trustee.ietf.org/license-info). 2110 This version of this YANG module is part of RFC XXXX; see 2111 the RFC itself for full legal notices."; 2112 reference 2113 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)."; 2115 revision 2017-12-20 { 2116 description 2117 "Network Managment Datastore Architecture (NDMA) Revision"; 2118 reference 2119 "RFC XXXX: A YANG Data Model for Routing Management 2120 (NDMA Version)"; 2121 } 2123 revision 2016-11-04 { 2124 description 2125 "Initial revision."; 2126 reference 2127 "RFC 8022: A YANG Data Model for Routing Management"; 2128 } 2130 augment "/if:interfaces/if:interface/ip:ipv6" { 2131 description 2132 "Augment interface configuration with parameters of IPv6 2133 router advertisements."; 2134 container ipv6-router-advertisements { 2135 description 2136 "Configuration of IPv6 Router Advertisements."; 2137 leaf send-advertisements { 2138 type boolean; 2139 default "false"; 2140 description 2141 "A flag indicating whether or not the router sends 2142 periodic Router Advertisements and responds to 2143 Router Solicitations."; 2144 reference 2145 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2146 AdvSendAdvertisements."; 2147 } 2148 leaf max-rtr-adv-interval { 2149 type uint16 { 2150 range "4..1800"; 2151 } 2152 units "seconds"; 2153 default "600"; 2154 description 2155 "The maximum time allowed between sending unsolicited 2156 multicast Router Advertisements from the interface."; 2157 reference 2158 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2159 MaxRtrAdvInterval."; 2160 } 2161 leaf min-rtr-adv-interval { 2162 type uint16 { 2163 range "3..1350"; 2164 } 2165 units "seconds"; 2166 must ". <= 0.75 * ../max-rtr-adv-interval" { 2167 description 2168 "The value MUST NOT be greater than 75% of 2169 'max-rtr-adv-interval'."; 2170 } 2171 description 2172 "The minimum time allowed between sending unsolicited 2173 multicast Router Advertisements from the interface. 2175 The default value to be used operationally if this 2176 leaf is not configured is determined as follows: 2178 - if max-rtr-adv-interval >= 9 seconds, the default 2179 value is 0.33 * max-rtr-adv-interval; 2181 - otherwise, it is 0.75 * max-rtr-adv-interval."; 2182 reference 2183 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2184 MinRtrAdvInterval."; 2185 } 2186 leaf managed-flag { 2187 type boolean; 2188 default "false"; 2189 description 2190 "The value to be placed in the 'Managed address 2191 configuration' flag field in the Router 2192 Advertisement."; 2194 reference 2195 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2196 AdvManagedFlag."; 2197 } 2198 leaf other-config-flag { 2199 type boolean; 2200 default "false"; 2201 description 2202 "The value to be placed in the 'Other configuration' 2203 flag field in the Router Advertisement."; 2204 reference 2205 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2206 AdvOtherConfigFlag."; 2207 } 2208 leaf link-mtu { 2209 type uint32; 2210 default "0"; 2211 description 2212 "The value to be placed in MTU options sent by the 2213 router. A value of zero indicates that no MTU options 2214 are sent."; 2215 reference 2216 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2217 AdvLinkMTU."; 2218 } 2219 leaf reachable-time { 2220 type uint32 { 2221 range "0..3600000"; 2222 } 2223 units "milliseconds"; 2224 default "0"; 2225 description 2226 "The value to be placed in the Reachable Time field in 2227 the Router Advertisement messages sent by the router. 2228 A value of zero means unspecified (by this router)."; 2229 reference 2230 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2231 AdvReachableTime."; 2232 } 2233 leaf retrans-timer { 2234 type uint32; 2235 units "milliseconds"; 2236 default "0"; 2237 description 2238 "The value to be placed in the Retrans Timer field in 2239 the Router Advertisement messages sent by the router. 2240 A value of zero means unspecified (by this router)."; 2241 reference 2242 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2243 AdvRetransTimer."; 2244 } 2245 leaf cur-hop-limit { 2246 type uint8; 2247 description 2248 "The value to be placed in the Cur Hop Limit field in 2249 the Router Advertisement messages sent by the router. 2250 A value of zero means unspecified (by this router). 2252 If this parameter is not configured, the device SHOULD 2253 use the value specified in IANA Assigned Numbers that 2254 was in effect at the time of implementation."; 2255 reference 2256 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2257 AdvCurHopLimit. 2259 IANA: IP Parameters, 2260 http://www.iana.org/assignments/ip-parameters"; 2261 } 2262 leaf default-lifetime { 2263 type uint16 { 2264 range "0..9000"; 2265 } 2266 units "seconds"; 2267 description 2268 "The value to be placed in the Router Lifetime field of 2269 Router Advertisements sent from the interface, in 2270 seconds. It MUST be either zero or between 2271 max-rtr-adv-interval and 9000 seconds. A value of zero 2272 default indicates that the router is not to be used as 2273 a router. These limits may be overridden by specific 2274 documents that describe how IPv6 operates over 2275 different link layers. 2277 If this parameter is not configured, the device SHOULD 2278 use a value of 3 * max-rtr-adv-interval."; 2279 reference 2280 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2281 AdvDefaultLifeTime."; 2282 } 2283 container prefix-list { 2284 description 2285 "Configuration of prefixes to be placed in Prefix 2286 Information options in Router Advertisement messages 2287 sent from the interface. 2289 Prefixes that are advertised by default but do not 2290 have their entries in the child 'prefix' list are 2291 advertised with the default values of all parameters. 2293 The link-local prefix SHOULD NOT be included in the 2294 list of advertised prefixes."; 2295 reference 2296 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 2297 AdvPrefixList."; 2298 list prefix { 2299 key "prefix-spec"; 2300 description 2301 "Configuration of an advertised prefix entry."; 2302 leaf prefix-spec { 2303 type inet:ipv6-prefix; 2304 description 2305 "IPv6 address prefix."; 2306 } 2307 choice control-adv-prefixes { 2308 default "advertise"; 2309 description 2310 "Either the prefix is explicitly removed from the 2311 set of advertised prefixes, or the parameters with 2312 which it is advertised are specified (default 2313 case)."; 2314 leaf no-advertise { 2315 type empty; 2316 description 2317 "The prefix will not be advertised. 2319 This can be used for removing the prefix from 2320 the default set of advertised prefixes."; 2321 } 2322 case advertise { 2323 leaf valid-lifetime { 2324 type uint32; 2325 units "seconds"; 2326 default "2592000"; 2327 description 2328 "The value to be placed in the Valid Lifetime 2329 in the Prefix Information option. The 2330 designated value of all 1's (0xffffffff) 2331 represents infinity."; 2332 reference 2333 "RFC 4861: Neighbor Discovery for IP version 6 2334 (IPv6) - AdvValidLifetime."; 2335 } 2336 leaf on-link-flag { 2337 type boolean; 2338 default "true"; 2339 description 2340 "The value to be placed in the on-link flag 2341 ('L-bit') field in the Prefix Information 2342 option."; 2343 reference 2344 "RFC 4861: Neighbor Discovery for IP version 6 2345 (IPv6) - AdvOnLinkFlag."; 2346 } 2347 leaf preferred-lifetime { 2348 type uint32; 2349 units "seconds"; 2350 must ". <= ../valid-lifetime" { 2351 description 2352 "This value MUST NOT be greater than 2353 valid-lifetime."; 2354 } 2355 default "604800"; 2356 description 2357 "The value to be placed in the Preferred 2358 Lifetime in the Prefix Information option. 2359 The designated value of all 1's (0xffffffff) 2360 represents infinity."; 2361 reference 2362 "RFC 4861: Neighbor Discovery for IP version 6 2363 (IPv6) - AdvPreferredLifetime."; 2364 } 2365 leaf autonomous-flag { 2366 type boolean; 2367 default "true"; 2368 description 2369 "The value to be placed in the Autonomous Flag 2370 field in the Prefix Information option."; 2371 reference 2372 "RFC 4861: Neighbor Discovery for IP version 6 2373 (IPv6) - AdvAutonomousFlag."; 2374 } 2375 } 2376 } 2377 } 2378 } 2379 } 2380 } 2382 /* Obsolete State Data */ 2384 augment "/if:interfaces-state/if:interface/ip:ipv6" { 2385 status obsolete; 2386 description 2387 "Augment interface state data with parameters of IPv6 router 2388 advertisements."; 2389 container ipv6-router-advertisements { 2390 status obsolete; 2391 description 2392 "Parameters of IPv6 Router Advertisements."; 2393 leaf send-advertisements { 2394 type boolean; 2395 status obsolete; 2396 description 2397 "A flag indicating whether or not the router sends periodic 2398 Router Advertisements and responds to Router 2399 Solicitations."; 2400 } 2401 leaf max-rtr-adv-interval { 2402 type uint16 { 2403 range "4..1800"; 2404 } 2405 units "seconds"; 2406 status obsolete; 2407 description 2408 "The maximum time allowed between sending unsolicited 2409 multicast Router Advertisements from the interface."; 2410 } 2411 leaf min-rtr-adv-interval { 2412 type uint16 { 2413 range "3..1350"; 2414 } 2415 units "seconds"; 2416 status obsolete; 2417 description 2418 "The minimum time allowed between sending unsolicited 2419 multicast Router Advertisements from the interface."; 2420 } 2421 leaf managed-flag { 2422 type boolean; 2423 status obsolete; 2424 description 2425 "The value that is placed in the 'Managed address 2426 configuration' flag field in the Router Advertisement."; 2427 } 2428 leaf other-config-flag { 2429 type boolean; 2430 status obsolete; 2431 description 2432 "The value that is placed in the 'Other configuration' flag 2433 field in the Router Advertisement."; 2435 } 2436 leaf link-mtu { 2437 type uint32; 2438 status obsolete; 2439 description 2440 "The value that is placed in MTU options sent by the 2441 router. A value of zero indicates that no MTU options are 2442 sent."; 2443 } 2444 leaf reachable-time { 2445 type uint32 { 2446 range "0..3600000"; 2447 } 2448 units "milliseconds"; 2449 status obsolete; 2450 description 2451 "The value that is placed in the Reachable Time field in 2452 the Router Advertisement messages sent by the router. A 2453 value of zero means unspecified (by this router)."; 2454 } 2455 leaf retrans-timer { 2456 type uint32; 2457 units "milliseconds"; 2458 status obsolete; 2459 description 2460 "The value that is placed in the Retrans Timer field in the 2461 Router Advertisement messages sent by the router. A value 2462 of zero means unspecified (by this router)."; 2463 } 2464 leaf cur-hop-limit { 2465 type uint8; 2466 status obsolete; 2467 description 2468 "The value that is placed in the Cur Hop Limit field in the 2469 Router Advertisement messages sent by the router. A value 2470 of zero means unspecified (by this router)."; 2471 } 2472 leaf default-lifetime { 2473 type uint16 { 2474 range "0..9000"; 2475 } 2476 units "seconds"; 2477 status obsolete; 2478 description 2479 "The value that is placed in the Router Lifetime field of 2480 Router Advertisements sent from the interface, in seconds. 2481 A value of zero indicates that the router is not to be 2482 used as a default router."; 2484 } 2485 container prefix-list { 2486 status obsolete; 2487 description 2488 "A list of prefixes that are placed in Prefix Information 2489 options in Router Advertisement messages sent from the 2490 interface. 2492 By default, these are all prefixes that the router 2493 advertises via routing protocols as being on-link for the 2494 interface from which the advertisement is sent."; 2495 list prefix { 2496 key "prefix-spec"; 2497 status obsolete; 2498 description 2499 "Advertised prefix entry and its parameters."; 2500 leaf prefix-spec { 2501 type inet:ipv6-prefix; 2502 status obsolete; 2503 description 2504 "IPv6 address prefix."; 2505 } 2506 leaf valid-lifetime { 2507 type uint32; 2508 units "seconds"; 2509 status obsolete; 2510 description 2511 "The value that is placed in the Valid Lifetime in the 2512 Prefix Information option. The designated value of 2513 all 1's (0xffffffff) represents infinity. 2515 An implementation SHOULD keep this value constant in 2516 consecutive advertisements except when it is 2517 explicitly changed in configuration."; 2518 } 2519 leaf on-link-flag { 2520 type boolean; 2521 status obsolete; 2522 description 2523 "The value that is placed in the on-link flag ('L-bit') 2524 field in the Prefix Information option."; 2525 } 2526 leaf preferred-lifetime { 2527 type uint32; 2528 units "seconds"; 2529 status obsolete; 2530 description 2531 "The value that is placed in the Preferred Lifetime in 2532 the Prefix Information option, in seconds. The 2533 designated value of all 1's (0xffffffff) represents 2534 infinity. 2536 An implementation SHOULD keep this value constant in 2537 consecutive advertisements except when it is 2538 explicitly changed in configuration."; 2539 } 2540 leaf autonomous-flag { 2541 type boolean; 2542 status obsolete; 2543 description 2544 "The value that is placed in the Autonomous Flag field 2545 in the Prefix Information option."; 2546 } 2547 } 2548 } 2549 } 2550 } 2551 } 2552 2554 10. IANA Considerations 2556 [RFC8022] registered the following namespace URIs in the "IETF XML 2557 Registry" [RFC3688]: 2559 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2560 Registrant Contact: The IESG. 2561 XML: N/A; the requested URI is an XML namespace. 2563 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2564 Registrant Contact: The IESG. 2565 XML: N/A; the requested URI is an XML namespace. 2567 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2568 Registrant Contact: The IESG. 2569 XML: N/A; the requested URI is an XML namespace. 2571 [RFC8022] registered the following YANG modules in the "YANG Module 2572 Names" registry [RFC6020]: 2574 Name: ietf-routing 2575 Namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2576 Prefix: rt 2577 Reference: RFC 8022 2578 Name: ietf-ipv4-unicast-routing 2579 Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2580 Prefix: v4ur 2581 Reference: RFC 8022 2583 Name: ietf-ipv6-unicast-routing 2584 Namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2585 Prefix: v6ur 2586 Reference: RFC 8022 2588 This document registers the following YANG submodule in the "YANG 2589 Module Names" registry [RFC6020]: 2591 Name: ietf-ipv6-router-advertisements 2592 Module: ietf-ipv6-unicast-routing 2593 Reference: RFC 8022 2595 11. Security Considerations 2597 The YANG module specified in this document defines a schedma for data 2598 that is designed to be accessed via network management protocols such 2599 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 2600 is the secure transport layer, and the mandatory-to-implement secure 2601 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 2602 is HTTPS, and the mandatory-to-implement secure transport is TLS 2603 [RFC5246]. 2605 The NETCONF access control model [RFC6536] provides the means to 2606 restrict access for particular NETCONF or RESTCONF users to a 2607 preconfigured subset of all available NETCONF or RESTCONF protocol 2608 operations and content. 2610 There are a number of data nodes defined in this YANG module that are 2611 writable/creatable/deletable (i.e., config true, which is the 2612 default). These data nodes may be considered sensitive or vulnerable 2613 in some network environments. Write operations (e.g., edit-config) 2614 to these data nodes without proper protection can have a negative 2615 effect on network operations. These are the subtrees and data nodes 2616 and their sensitivity/vulnerability: 2618 /routing/control-plane-protocols/control-plane-protocol: This list 2619 specifies the control-plane protocols configured on a device. 2621 /routing/ribs/rib: This list specifies the RIBs configured for the 2622 device. 2624 Some of the readable data nodes in this YANG module may be considered 2625 sensitive or vulnerable in some network environments. It is thus 2626 important to control read access (e.g., via get, get-config, or 2627 notification) to these data nodes. These are the subtrees and data 2628 nodes and their sensitivity/vulnerability: 2630 /routing/control-plane-protocols/control-plane-protocol: This list 2631 specifies the control-plane protocols configured on a device. 2632 Refer to the control plane models for a list of sensitive 2633 information. 2635 /routing/ribs/rib: This list specifies the RIB and their contents 2636 for the device. Access to this information may disclose the 2637 network topology and or other information. 2639 12. References 2641 12.1. Normative References 2643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2644 Requirement Levels", BCP 14, RFC 2119, 2645 DOI 10.17487/RFC2119, March 1997, . 2648 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2649 DOI 10.17487/RFC3688, January 2004, . 2652 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2653 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2654 DOI 10.17487/RFC4861, September 2007, . 2657 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2658 (TLS) Protocol Version 1.2", RFC 5246, 2659 DOI 10.17487/RFC5246, August 2008, . 2662 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2663 the Network Configuration Protocol (NETCONF)", RFC 6020, 2664 DOI 10.17487/RFC6020, October 2010, . 2667 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2668 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2669 . 2671 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2672 and A. Bierman, Ed., "Network Configuration Protocol 2673 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2674 . 2676 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2677 Protocol (NETCONF) Access Control Model", RFC 6536, 2678 DOI 10.17487/RFC6536, March 2012, . 2681 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2682 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2683 . 2685 [I-D.ietf-netmod-rfc7223bis] 2686 Bjorklund, M., "A YANG Data Model for Interface 2687 Management", draft-ietf-netmod-rfc7223bis-01 (work in 2688 progress), December 2017. 2690 [I-D.ietf-netmod-rfc7277bis] 2691 Bjorklund, M., "A YANG Data Model for IP Management", 2692 draft-ietf-netmod-rfc7277bis-01 (work in progress), 2693 December 2017. 2695 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2696 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2697 . 2699 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 2700 Management", RFC 8022, DOI 10.17487/RFC8022, November 2701 2016, . 2703 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2704 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2705 . 2707 [I-D.ietf-netmod-revised-datastores] 2708 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2709 and R. Wilton, "Network Management Datastore 2710 Architecture", draft-ietf-netmod-revised-datastores-07 2711 (work in progress), November 2017. 2713 12.2. Informative References 2715 [I-D.ietf-netmod-rfc6087bis] 2716 Bierman, A., "Guidelines for Authors and Reviewers of YANG 2717 Data Model Documents", draft-ietf-netmod-rfc6087bis-15 2718 (work in progress), December 2017. 2720 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 2721 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 2722 . 2724 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2725 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2726 . 2728 [I-D.ietf-netmod-yang-tree-diagrams] 2729 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 2730 ietf-netmod-yang-tree-diagrams-02 (work in progress), 2731 October 2017. 2733 Appendix A. The Complete Schema Tree 2735 This appendix presents the complete tree of the core routing data 2736 model. See Section 2.2 for an explanation of the symbols used. The 2737 data type of every leaf node is shown near the right end of the 2738 corresponding line. 2740 module: ietf-routing 2741 +--rw routing 2742 | +--rw router-id? yang:dotted-quad 2743 | +--ro interfaces 2744 | | +--ro interface* if:interface-ref 2745 | +--rw control-plane-protocols 2746 | | +--rw control-plane-protocol* [type name] 2747 | | +--rw type identityref 2748 | | +--rw name string 2749 | | +--rw description? string 2750 | | +--rw static-routes 2751 | | +--rw v4ur:ipv4 2752 | | | +--rw v4ur:route* [destination-prefix] 2753 | | | +--rw v4ur:destination-prefix 2754 | | | | inet:ipv4-prefix 2755 | | | +--rw v4ur:description? string 2756 | | | +--rw v4ur:next-hop 2757 | | | +--rw (v4ur:next-hop-options) 2758 | | | +--:(v4ur:simple-next-hop) 2759 | | | | +--rw v4ur:outgoing-interface? 2760 | | | | | if:interface-ref 2761 | | | | +--rw v4ur:next-hop-address? 2762 | | | | inet:ipv4-address 2763 | | | +--:(v4ur:special-next-hop) 2764 | | | | +--rw v4ur:special-next-hop? 2765 | | | | enumeration 2766 | | | +--:(v4ur:next-hop-list) 2767 | | | +--rw v4ur:next-hop-list 2768 | | | +--rw v4ur:next-hop* [index] 2769 | | | +--rw v4ur:index 2770 | | | | string 2771 | | | +--rw v4ur:outgoing-interface? 2772 | | | | if:interface-ref 2773 | | | +--rw v4ur:next-hop-address? 2774 | | | inet:ipv4-address 2775 | | +--rw v6ur:ipv6 2776 | | +--rw v6ur:route* [destination-prefix] 2777 | | +--rw v6ur:destination-prefix 2778 | | | inet:ipv6-prefix 2779 | | +--rw v6ur:description? string 2780 | | +--rw v6ur:next-hop 2781 | | +--rw (v6ur:next-hop-options) 2782 | | +--:(v6ur:simple-next-hop) 2783 | | | +--rw v6ur:outgoing-interface? 2784 | | | | if:interface-ref 2785 | | | +--rw v6ur:next-hop-address? 2786 | | | inet:ipv6-address 2787 | | +--:(v6ur:special-next-hop) 2788 | | | +--rw v6ur:special-next-hop? 2789 | | | enumeration 2790 | | +--:(v6ur:next-hop-list) 2791 | | +--rw v6ur:next-hop-list 2792 | | +--rw v6ur:next-hop* [index] 2793 | | +--rw v6ur:index 2794 | | | string 2795 | | +--rw v6ur:outgoing-interface? 2796 | | | if:interface-ref 2797 | | +--rw v6ur:next-hop-address? 2798 | | inet:ipv6-address 2799 | +--rw ribs 2800 | +--rw rib* [name] 2801 | +--rw name string 2802 | +--rw address-family identityref 2803 | +--ro default-rib? boolean {multiple-ribs}? 2804 | +--ro routes 2805 | | +--ro route* 2806 | | +--ro route-preference? route-preference 2807 | | +--ro next-hop 2808 | | | +--ro (next-hop-options) 2809 | | | +--:(simple-next-hop) 2810 | | | | +--ro outgoing-interface? 2811 | | | | | if:interface-ref 2812 | | | | +--ro v4ur:next-hop-address? 2813 | | | | | inet:ipv4-address 2814 | | | | +--ro v6ur:next-hop-address? 2815 | | | | inet:ipv6-address 2816 | | | +--:(special-next-hop) 2817 | | | | +--ro special-next-hop? enumeration 2818 | | | +--:(next-hop-list) 2819 | | | +--ro next-hop-list 2820 | | | +--ro next-hop* 2821 | | | +--ro outgoing-interface? 2822 | | | | if:interface-ref 2823 | | | +--ro v4ur:address? 2824 | | | | inet:ipv4-address 2825 | | | +--ro v6ur:address? 2826 | | | inet:ipv6-address 2827 | | +--ro source-protocol identityref 2828 | | +--ro active? empty 2829 | | +--ro last-updated? yang:date-and-time 2830 | | +--ro v4ur:destination-prefix? inet:ipv4-prefix 2831 | | +--ro v6ur:destination-prefix? inet:ipv6-prefix 2832 | +---x active-route 2833 | | +---w input 2834 | | | +---w v4ur:destination-address? inet:ipv4-address 2835 | | | +---w v6ur:destination-address? inet:ipv6-address 2836 | | +--ro output 2837 | | +--ro route 2838 | | +--ro next-hop 2839 | | | +--ro (next-hop-options) 2840 | | | +--:(simple-next-hop) 2841 | | | | +--ro outgoing-interface? 2842 | | | | | if:interface-ref 2843 | | | | +--ro v4ur:next-hop-address? 2844 | | | | | inet:ipv4-address 2845 | | | | +--ro v6ur:next-hop-address? 2846 | | | | inet:ipv6-address 2847 | | | +--:(special-next-hop) 2848 | | | | +--ro special-next-hop? 2849 | | | | enumeration 2850 | | | +--:(next-hop-list) 2851 | | | +--ro next-hop-list 2852 | | | +--ro next-hop* 2853 | | | +--ro outgoing-interface? 2854 | | | | if:interface-ref 2855 | | | +--ro v4ur:next-hop-address? 2856 | | | | inet:ipv4-address 2857 | | | +--ro v6ur:next-hop-address? 2858 | | | inet:ipv6-address 2859 | | +--ro source-protocol identityref 2860 | | +--ro active? empty 2861 | | +--ro last-updated? 2862 | | | yang:date-and-time 2863 | | +--ro v4ur:destination-prefix? 2864 | | | inet:ipv4-prefix 2865 | | +--ro v6ur:destination-prefix? 2866 | | inet:ipv6-prefix 2867 | +--rw description? string 2868 o--ro routing-state 2869 +--ro router-id? yang:dotted-quad 2870 o--ro interfaces 2871 | o--ro interface* if:interface-state-ref 2872 o--ro control-plane-protocols 2873 | o--ro control-plane-protocol* [type name] 2874 | o--ro type identityref 2875 | o--ro name string 2876 o--ro ribs 2877 o--ro rib* [name] 2878 o--ro name string 2879 +--ro address-family identityref 2880 o--ro default-rib? boolean {multiple-ribs}? 2881 o--ro routes 2882 | o--ro route* 2883 | o--ro route-preference? route-preference 2884 | o--ro next-hop 2885 | | +--ro (next-hop-options) 2886 | | +--:(simple-next-hop) 2887 | | | +--ro outgoing-interface? 2888 | | | | if:interface-ref 2889 | | | o--ro v4ur:next-hop-address? 2890 | | | | inet:ipv4-address 2891 | | | o--ro v6ur:next-hop-address? 2892 | | | inet:ipv6-address 2893 | | +--:(special-next-hop) 2894 | | | +--ro special-next-hop? enumeration 2895 | | +--:(next-hop-list) 2896 | | +--ro next-hop-list 2897 | | +--ro next-hop* 2898 | | +--ro outgoing-interface? 2899 | | | if:interface-ref 2900 | | o--ro v4ur:address? 2901 | | | inet:ipv4-address 2902 | | o--ro v6ur:address? 2903 | | inet:ipv6-address 2904 | +--ro source-protocol identityref 2905 | +--ro active? empty 2906 | +--ro last-updated? yang:date-and-time 2907 | o--ro v4ur:destination-prefix? inet:ipv4-prefix 2908 | o--ro v6ur:destination-prefix? inet:ipv6-prefix 2909 o---x active-route 2910 +---w input 2911 | o---w v4ur:destination-address? inet:ipv4-address 2912 | o---w v6ur:destination-address? inet:ipv6-address 2913 +--ro output 2914 o--ro route 2915 o--ro next-hop 2916 | +--ro (next-hop-options) 2917 | +--:(simple-next-hop) 2918 | | +--ro outgoing-interface? 2919 | | | if:interface-ref 2920 | | o--ro v4ur:next-hop-address? 2921 | | | inet:ipv4-address 2922 | | o--ro v6ur:next-hop-address? 2923 | | inet:ipv6-address 2924 | +--:(special-next-hop) 2925 | | +--ro special-next-hop? 2926 | | enumeration 2927 | +--:(next-hop-list) 2928 | +--ro next-hop-list 2929 | +--ro next-hop* 2930 | +--ro outgoing-interface? 2931 | | if:interface-ref 2932 | o--ro v4ur:next-hop-address? 2933 | | inet:ipv4-address 2934 | o--ro v6ur:next-hop-address? 2935 | inet:ipv6-address 2936 +--ro source-protocol identityref 2937 +--ro active? empty 2938 +--ro last-updated? 2939 | yang:date-and-time 2940 o--ro v4ur:destination-prefix? 2941 | inet:ipv4-prefix 2942 o--ro v6ur:destination-prefix? 2943 inet:ipv6-prefix 2944 module: ietf-ipv6-unicast-routing 2945 augment /if:interfaces/if:interface/ip:ipv6: 2946 +--rw ipv6-router-advertisements 2947 +--rw send-advertisements? boolean 2948 +--rw max-rtr-adv-interval? uint16 2949 +--rw min-rtr-adv-interval? uint16 2950 +--rw managed-flag? boolean 2951 +--rw other-config-flag? boolean 2952 +--rw link-mtu? uint32 2953 +--rw reachable-time? uint32 2954 +--rw retrans-timer? uint32 2955 +--rw cur-hop-limit? uint8 2956 +--rw default-lifetime? uint16 2957 +--rw prefix-list 2958 +--rw prefix* [prefix-spec] 2959 +--rw prefix-spec inet:ipv6-prefix 2960 +--rw (control-adv-prefixes)? 2961 +--:(no-advertise) 2962 | +--rw no-advertise? empty 2963 +--:(advertise) 2964 +--rw valid-lifetime? uint32 2965 +--rw on-link-flag? boolean 2966 +--rw preferred-lifetime? uint32 2967 +--rw autonomous-flag? boolean 2968 augment /if:interfaces-state/if:interface/ip:ipv6: 2969 o--ro ipv6-router-advertisements 2970 o--ro send-advertisements? boolean 2971 o--ro max-rtr-adv-interval? uint16 2972 o--ro min-rtr-adv-interval? uint16 2973 o--ro managed-flag? boolean 2974 o--ro other-config-flag? boolean 2975 o--ro link-mtu? uint32 2976 o--ro reachable-time? uint32 2977 o--ro retrans-timer? uint32 2978 o--ro cur-hop-limit? uint8 2979 o--ro default-lifetime? uint16 2980 o--ro prefix-list 2981 o--ro prefix* [prefix-spec] 2982 o--ro prefix-spec inet:ipv6-prefix 2983 o--ro valid-lifetime? uint32 2984 o--ro on-link-flag? boolean 2985 o--ro preferred-lifetime? uint32 2986 o--ro autonomous-flag? boolean 2988 Appendix B. Minimum Implementation 2990 Some parts and options of the core routing model, such as user- 2991 defined RIBs, are intended only for advanced routers. This appendix 2992 gives basic non-normative guidelines for implementing a bare minimum 2993 of available functions. Such an implementation may be used for hosts 2994 or very simple routers. 2996 A minimum implementation does not support the feature 2997 "multiple-ribs". This means that a single system-controlled RIB is 2998 available for each supported address family -- IPv4, IPv6, or both. 2999 These RIBs are also the default RIBs. No user-controlled RIBs are 3000 allowed. 3002 In addition to the mandatory instance of the "direct" pseudo- 3003 protocol, a minimum implementation should support configuring 3004 instance(s) of the "static" pseudo-protocol. 3006 For hosts that are never intended to act as routers, the ability to 3007 turn on sending IPv6 router advertisements (Section 5.4) should be 3008 removed. 3010 Platforms with severely constrained resources may use deviations for 3011 restricting the data model, e.g., limiting the number of "static" 3012 control-plane protocol instances. 3014 Appendix C. Example: Adding a New Control-Plane Protocol 3016 This appendix demonstrates how the core routing data model can be 3017 extended to support a new control-plane protocol. The YANG module 3018 "example-rip" shown below is intended as an illustration rather than 3019 a real definition of a data model for the Routing Information 3020 Protocol (RIP). For the sake of brevity, this module does not obey 3021 all the guidelines specified in [I-D.ietf-netmod-rfc6087bis]. See 3022 also Section 5.3.2. 3024 module example-rip { 3026 yang-version "1.1"; 3028 namespace "http://example.com/rip"; 3030 prefix "rip"; 3032 import ietf-interfaces { 3033 prefix "if"; 3034 } 3036 import ietf-routing { 3037 prefix "rt"; 3038 } 3040 identity rip { 3041 base rt:routing-protocol; 3042 description 3043 "Identity for the Routing Information Protocol (RIP)."; 3044 } 3046 typedef rip-metric { 3047 type uint8 { 3048 range "0..16"; 3049 } 3050 } 3052 grouping route-content { 3053 description 3054 "This grouping defines RIP-specific route attributes."; 3055 leaf metric { 3056 type rip-metric; 3057 } 3058 leaf tag { 3059 type uint16; 3060 default "0"; 3061 description 3062 "This leaf may be used to carry additional info, e.g., 3063 autonomous system (AS) number."; 3064 } 3065 } 3067 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { 3068 when "derived-from-or-self(rt:source-protocol, 'rip:rip')" { 3069 description 3070 "This augment is only valid for a route whose source 3071 protocol is RIP."; 3072 } 3073 description 3074 "RIP-specific route attributes."; 3075 uses route-content; 3076 } 3078 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 3079 + "rt:output/rt:route" { 3080 description 3081 "RIP-specific route attributes in the output of 'active-route' 3082 RPC."; 3083 uses route-content; 3084 } 3086 augment "/rt:routing/rt:control-plane-protocols/" 3087 + "rt:control-plane-protocol" { 3088 when "derived-from-or-self(rt:type,'rip:rip')" { 3089 description 3090 "This augment is only valid for a routing protocol instance 3091 of type 'rip'."; 3092 } 3093 container rip { 3094 presence "RIP configuration"; 3095 description 3096 "RIP instance configuration."; 3097 container interfaces { 3098 description 3099 "Per-interface RIP configuration."; 3100 list interface { 3101 key "name"; 3102 description 3103 "RIP is enabled on interfaces that have an entry in this 3104 list, unless 'enabled' is set to 'false' for that 3105 entry."; 3106 leaf name { 3107 type if:interface-ref; 3108 } 3109 leaf enabled { 3110 type boolean; 3111 default "true"; 3112 } 3113 leaf metric { 3114 type rip-metric; 3115 default "1"; 3116 } 3118 } 3119 } 3120 leaf update-interval { 3121 type uint8 { 3122 range "10..60"; 3123 } 3124 units "seconds"; 3125 default "30"; 3126 description 3127 "Time interval between periodic updates."; 3128 } 3129 } 3130 } 3131 } 3133 Appendix D. Data Tree Example 3135 This section contains an example of an instance data tree in the JSON 3136 encoding [RFC7951], containing both configuration and state data. 3137 The data conforms to a data model that is defined by the following 3138 YANG library specification [RFC7895]: 3140 { 3141 "ietf-yang-library:modules-state": { 3142 "module-set-id": "c2e1f54169aa7f36e1a6e8d0865d441d3600f9c4", 3143 "module": [ 3144 { 3145 "name": "ietf-routing", 3146 "revision": "2017-12-20", 3147 "feature": [ 3148 "multiple-ribs", 3149 "router-id" 3150 ], 3151 "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing", 3152 "conformance-type": "implement" 3153 }, 3154 { 3155 "name": "ietf-ipv4-unicast-routing", 3156 "revision": "2017-12-20", 3157 "namespace": 3158 "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing", 3159 "conformance-type": "implement" 3160 }, 3161 { 3162 "name": "ietf-ipv6-unicast-routing", 3163 "revision": "2017-12-20", 3164 "namespace": 3165 "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing-3", 3167 "conformance-type": "implement" 3168 }, 3169 { 3170 "name": "ietf-interfaces", 3171 "revision": "2017-12-16", 3172 "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", 3173 "conformance-type": "implement" 3174 }, 3175 { 3176 "name": "ietf-inet-types", 3177 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", 3178 "revision": "2013-07-15", 3179 "conformance-type": "import" 3180 }, 3181 { 3182 "name": "ietf-yang-types", 3183 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", 3184 "revision": "2013-07-15", 3185 "conformance-type": "import" 3186 }, 3187 { 3188 "name": "iana-if-type", 3189 "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", 3190 "revision": "", 3191 "conformance-type": "implement" 3192 }, 3193 { 3194 "name": "ietf-ip", 3195 "revision": "2017-12-16", 3196 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", 3197 "conformance-type": "implement" 3198 } 3199 ] 3200 } 3201 } 3203 A simple network setup as shown in Figure 2 is assumed: router "A" 3204 uses static default routes with the "ISP" router as the next hop. 3205 IPv6 router advertisements are configured only on the "eth1" 3206 interface and disabled on the upstream "eth0" interface. 3208 +-----------------+ 3209 | | 3210 | Router ISP | 3211 | | 3212 +--------+--------+ 3213 |2001:db8:0:1::2 3214 |192.0.2.2 3215 | 3216 | 3217 |2001:db8:0:1::1 3218 eth0|192.0.2.1 3219 +--------+--------+ 3220 | | 3221 | Router A | 3222 | | 3223 +--------+--------+ 3224 eth1|198.51.100.1 3225 |2001:db8:0:2::1 3226 | 3228 Figure 2: Example of Network Configuration 3230 The instance data tree could then be as follows: 3232 { 3233 "ietf-interfaces:interfaces": { 3234 "interface": [ 3235 { 3236 "name": "eth0", 3237 "type": "iana-if-type:ethernetCsmacd", 3238 "description": "Uplink to ISP.", 3239 "phys-address": "00:0C:42:E5:B1:E9", 3240 "oper-status": "up", 3241 "statistics": { 3242 "discontinuity-time": "2015-10-24T17:11:27+02:00" 3243 }, 3244 "ietf-ip:ipv4": { 3245 "forwarding": true, 3246 "mtu": 1500, 3247 "address": [ 3248 { 3249 "ip": "192.0.2.1", 3250 "prefix-length": 24 3251 } 3252 ], 3253 }, 3254 "ietf-ip:ipv6": { 3255 "forwarding": true, 3256 "mtu": 1500, 3257 "address": [ 3258 { 3259 "ip": "2001:0db8:0:1::1", 3260 "prefix-length": 64 3261 } 3262 ], 3263 "autoconf": { 3264 "create-global-addresses": false 3265 } 3266 "ietf-ipv6-unicast-routing: 3267 ipv6-router-advertisements": { 3268 "send-advertisements": false 3269 } 3270 } 3271 }, 3272 { 3273 "name": "eth1", 3274 "type": "iana-if-type:ethernetCsmacd", 3275 "description": "Interface to the internal network.", 3276 "phys-address": "00:0C:42:E5:B1:EA", 3277 "oper-status": "up", 3278 "statistics": { 3279 "discontinuity-time": "2015-10-24T17:11:29+02:00" 3280 }, 3281 "ietf-ip:ipv4": { 3282 "forwarding": true, 3283 "mtu": 1500, 3284 "address": [ 3285 { 3286 "ip": "198.51.100.1", 3287 "prefix-length": 24 3288 } 3289 ], 3290 }, 3291 "ietf-ip:ipv6": { 3292 "forwarding": true, 3293 "mtu": 1500, 3294 "address": [ 3295 { 3296 "ip": "2001:0db8:0:2::1", 3297 "prefix-length": 64 3298 } 3299 ], 3300 "autoconf": { 3301 "create-global-addresses": false 3302 }, 3303 "ietf-ipv6-unicast-routing: 3305 ipv6-router-advertisements": { 3306 "send-advertisements": true, 3307 "prefix-list": { 3308 "prefix": [ 3309 { 3310 "prefix-spec": "2001:db8:0:2::/64" 3311 } 3312 ] 3313 } 3314 } 3315 } 3316 } 3317 ] 3318 }, 3320 "ietf-routing:routing": { 3321 "router-id": "192.0.2.1", 3322 "control-plane-protocols": { 3323 "control-plane-protocol": [ 3324 { 3325 "type": "ietf-routing:static", 3326 "name": "st0", 3327 "description": 3328 "Static routing is used for the internal network.", 3329 "static-routes": { 3330 "ietf-ipv4-unicast-routing:ipv4": { 3331 "route": [ 3332 { 3333 "destination-prefix": "0.0.0.0/0", 3334 "next-hop": { 3335 "next-hop-address": "192.0.2.2" 3336 } 3337 } 3338 ] 3339 }, 3340 "ietf-ipv6-unicast-routing:ipv6": { 3341 "route": [ 3342 { 3343 "destination-prefix": "::/0", 3344 "next-hop": { 3345 "next-hop-address": "2001:db8:0:1::2" 3346 } 3347 } 3348 ] 3349 } 3350 } 3351 } 3352 ] 3354 } 3355 "ribs": { 3356 "rib": [ 3357 { 3358 "name": "ipv4-master", 3359 "address-family": 3360 "ietf-ipv4-unicast-routing:ipv4-unicast", 3361 "default-rib": true, 3362 "routes": { 3363 "route": [ 3364 { 3365 "ietf-ipv4-unicast-routing:destination-prefix": 3366 "192.0.2.1/24", 3367 "next-hop": { 3368 "outgoing-interface": "eth0" 3369 }, 3370 "route-preference": 0, 3371 "source-protocol": "ietf-routing:direct", 3372 "last-updated": "2015-10-24T17:11:27+02:00" 3373 }, 3374 { 3375 "ietf-ipv4-unicast-routing:destination-prefix": 3376 "198.51.100.0/24", 3377 "next-hop": { 3378 "outgoing-interface": "eth1" 3379 }, 3380 "source-protocol": "ietf-routing:direct", 3381 "route-preference": 0, 3382 "last-updated": "2015-10-24T17:11:27+02:00" 3383 }, 3384 { 3385 "ietf-ipv4-unicast-routing:destination-prefix": 3386 "0.0.0.0/0", 3387 "source-protocol": "ietf-routing:static", 3388 "route-preference": 5, 3389 "next-hop": { 3390 "ietf-ipv4-unicast-routing:next-hop-address": 3391 "192.0.2.2" 3392 }, 3393 "last-updated": "2015-10-24T18:02:45+02:00" 3394 } 3395 ] 3396 } 3397 }, 3398 { 3399 "name": "ipv6-master", 3400 "address-family": 3401 "ietf-ipv6-unicast-routing:ipv6-unicast", 3403 "default-rib": true, 3404 "routes": { 3405 "route": [ 3406 { 3407 "ietf-ipv6-unicast-routing:destination-prefix": 3408 "2001:db8:0:1::/64", 3409 "next-hop": { 3410 "outgoing-interface": "eth0" 3411 }, 3412 "source-protocol": "ietf-routing:direct", 3413 "route-preference": 0, 3414 "last-updated": "2015-10-24T17:11:27+02:00" 3415 }, 3416 { 3417 "ietf-ipv6-unicast-routing:destination-prefix": 3418 "2001:db8:0:2::/64", 3419 "next-hop": { 3420 "outgoing-interface": "eth1" 3421 }, 3422 "source-protocol": "ietf-routing:direct", 3423 "route-preference": 0, 3424 "last-updated": "2015-10-24T17:11:27+02:00" 3425 }, 3426 { 3427 "ietf-ipv6-unicast-routing:destination-prefix": 3428 "::/0", 3429 "next-hop": { 3430 "ietf-ipv6-unicast-routing:next-hop-address": 3431 "2001:db8:0:1::2" 3432 }, 3433 "source-protocol": "ietf-routing:static", 3434 "route-preference": 5, 3435 "last-updated": "2015-10-24T18:02:45+02:00" 3436 } 3437 ] 3438 } 3439 } 3440 ] 3441 } 3442 }, 3443 } 3445 Appendix E. NETCONF Get Data Reply Example 3447 This section gives an example of an XML reply to the NETCONF request for for a device that implements the 3449 example data models above. 3451 3454 3455 3459 192.0.2.1 3460 3461 3462 ietf-routing:static 3463 3464 3465 3466 3467 0.0.0.0/0 3468 3469 192.0.2.2 3470 3471 3472 3473 3474 3475 ::/0 3476 3477 2001:db8:0:1::2 3478 3479 3480 3481 3482 3483 3485 3486 3487 ipv4-master 3488 3489 ietf-ipv4-unicast-routing:ipv4-unicast 3490 3491 true 3492 3493 3494 3495 192.0.2.1/24 3496 3497 3498 eth0 3500 3501 0 3502 ietf-routing:direct 3503 2015-10-24T17:11:27+02:00 3504 3505 3506 3507 198.51.100.0/24 3508 3509 3510 eth1 3511 3512 0 3513 ietf-routing:direct 3514 2015-10-24T17:11:27+02:00 3515 3516 3517 0.0.0.0/0 3518 3519 3520 192.0.2.2 3521 3522 3523 5 3524 ietf-routing:static 3525 2015-10-24T18:02:45+02:00 3526 3527 3528 3529 3530 ipv6-master 3531 3532 ietf-ipv6-unicast-routing:ipv6-unicast 3533 3534 true 3535 3536 3537 3538 2001:db8:0:1::/64 3539 3540 3541 eth0 3542 3543 0 3544 ietf-routing:direct 3545 2015-10-24T17:11:27+02:00 3546 3547 3548 3549 2001:db8:0:2::/64 3550 3551 3552 eth1 3553 3554 0 3555 ietf-routing:direct 3556 2015-10-24T17:11:27+02:00 3557 3558 3559 ::/0 3560 3561 3562 3563 2001:db8:0:1::2 3564 3565 3566 5 3567 ietf-routing:static 3568 2015-10-24T18:02:45+02:00 3569 3570 3571 3572 3573 3574 3575 3577 Acknowledgments 3579 The authors wish to thank Nitin Bahadur, Martin Bjorklund, Dean 3580 Bogdanovic, Jeff Haas, Joel Halpern, Wes Hardaker, Sriganesh Kini, 3581 David Lamparter, Andrew McGregor, Jan Medved, Xiang Li, Stephane 3582 Litkowski, Thomas Morin, Tom Petch, Bruno Rijsman, 3583 Juergen Schoenwaelder, Phil Shafer, Dave Thaler, Yi Yang, 3584 Derek Man-Kit Yeung, Jeffrey Zhang, Vladimir Vassilev, and Rob Wilton 3585 for their helpful comments and suggestions. 3587 Authors' Addresses 3589 Ladislav Lhotka 3590 CZ.NIC 3592 EMail: lhotka@nic.cz 3593 Acee Lindem 3594 Cisco Systems 3596 EMail: acee@cisco.com 3598 Yingzhen Qu 3599 Huawei 3600 2330 Central Expressway 3601 Santa Clara CA 95050 3602 USA 3604 EMail: yingzhen.qu@huawei.com