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