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