idnits 2.17.1 draft-ietf-netmod-revised-datastores-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 20, 2017) is 2316 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 informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Updates: 7950 (if approved) J. Schoenwaelder 5 Intended status: Standards Track Jacobs University 6 Expires: June 23, 2018 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 December 20, 2017 13 Network Management Datastore Architecture 14 draft-ietf-netmod-revised-datastores-09 16 Abstract 18 Datastores are a fundamental concept binding the data models written 19 in the YANG data modeling language to network management protocols 20 such as NETCONF and RESTCONF. This document defines an architectural 21 framework for datastores based on the experience gained with the 22 initial simpler model, addressing requirements that were not well 23 supported in the initial model. This document updates RFC 7950. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 23, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Original Model of Datastores . . . . . . . . . . . . . . 8 64 5. Architectural Model of Datastores . . . . . . . . . . . . . . 9 65 5.1. Conventional Configuration Datastores . . . . . . . . . . 10 66 5.1.1. The Startup Configuration Datastore () . . . 11 67 5.1.2. The Candidate Configuration Datastore () . 11 68 5.1.3. The Running Configuration Datastore () . . . 12 69 5.1.4. The Intended Configuration Datastore () . . 12 70 5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13 71 5.3. The Operational State Datastore () . . . . . 13 72 5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14 73 5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 15 74 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 75 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 76 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17 77 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17 78 6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18 79 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24 82 8.2. Updates to the YANG Module Names Registry . . . . . . . . 24 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 87 11.2. Informative References . . . . . . . . . . . . . . . . . 26 88 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27 89 A.1. Define which YANG modules can be used in the datastore . 27 90 A.2. Define which subset of YANG-modeled data applies . . . . 27 91 A.3. Define how data is actualized . . . . . . . . . . . . . . 27 92 A.4. Define which protocols can be used . . . . . . . . . . . 28 93 A.5. Define YANG identities for the datastore . . . . . . . . 28 94 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 95 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 96 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30 97 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 98 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 99 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 100 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35 101 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36 102 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36 103 C.3.2. System-provided Interface . . . . . . . . . . . . . . 37 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 106 1. Introduction 108 This document provides an architectural framework for datastores as 109 they are used by network management protocols such as NETCONF 110 [RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling 111 language. Datastores are a fundamental concept binding network 112 management data models to network management protocols. Agreement on 113 a common architectural model of datastores ensures that data models 114 can be written in a network management protocol agnostic way. This 115 architectural framework identifies a set of conceptual datastores but 116 it does not mandate that all network management protocols expose all 117 these conceptual datastores. This architecture is agnostic with 118 regard to the encoding used by network management protocols. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 2. Objectives 128 Network management data objects can often take two different values, 129 the value configured by the user or an application (configuration) 130 and the value that the device is actually using (operational state). 131 These two values may be different for a number of reasons, e.g., 132 system internal interactions with hardware, interaction with 133 protocols or other devices, or simply the time it takes to propagate 134 a configuration change to the software and hardware components of a 135 system. Furthermore, configuration and operational state data 136 objects may have different lifetimes. 138 The original model of datastores required these data objects to be 139 modeled twice in the YANG schema, as "config true" objects and as 140 "config false" objects. The convention adopted by the interfaces 141 data model ([RFC7223]) and the IP data model ([RFC7277]) was using 142 two separate branches rooted at the root of the data tree, one branch 143 for configuration data objects and one branch for operational state 144 data objects. 146 The duplication of definitions and the ad-hoc separation of 147 operational state data from configuration data leads to a number of 148 problems. Having configuration and operational state data in 149 separate branches in the data model is operationally complicated and 150 impacts the readability of module definitions. Furthermore, the 151 relationship between the branches is not machine readable and filter 152 expressions operating on configuration and on related operational 153 state are different. 155 With the revised architectural model of datastores defined in this 156 document, the data objects are defined only once in the YANG schema 157 but independent instantiations can appear in two different 158 datastores, one for configured values and one for operational state 159 values. This provides a more elegant and simpler solution to the 160 problem. 162 The revised architectural model of datastores supports additional 163 datastores for systems that support more advanced processing chains 164 converting configuration to operational state. For example, some 165 systems support configuration that is not currently used (so called 166 inactive configuration) or they support configuration templates that 167 are used to expand configuration data via a common template. 169 3. Terminology 171 This document defines the following terminology. Some of the terms 172 are revised definitions of terms originally defined in [RFC6241] and 173 [RFC7950] (see also section Section 4). The revised definitions are 174 semantically equivalent with the definitions found in [RFC6241] and 175 [RFC7950]. It is expected that the revised definitions provided in 176 this section will replace the definitions in [RFC6241] and [RFC7950] 177 when these documents are revised. 179 o datastore: A conceptual place to store and access information. A 180 datastore might be implemented, for example, using files, a 181 database, flash memory locations, or combinations thereof. A 182 datastore maps to an instantiated YANG data tree. 184 o schema node: A node in the schema tree. The formal definition is 185 in RFC 7950. 187 o datastore schema: The combined set of schema nodes for all modules 188 supported by a particular datastore, taking into consideration any 189 deviations and enabled features for that datastore. 191 o configuration: Data that is required to get a device from its 192 initial default state into a desired operational state. This data 193 is modeled in YANG using "config true" nodes. Configuration can 194 originate from different sources. 196 o configuration datastore: A datastore holding configuration. 198 o running configuration datastore: A configuration datastore holding 199 the current configuration of the device. It may include 200 configuration that requires further transformations before it can 201 be applied. This datastore is referred to as "". 203 o candidate configuration datastore: A configuration datastore that 204 can be manipulated without impacting the device's running 205 configuration datastore and that can be committed to the running 206 configuration datastore. This datastore is referred to as 207 "". 209 o startup configuration datastore: A configuration datastore holding 210 the configuration loaded by the device into the running 211 configuration datastore when it boots. This datastore is referred 212 to as "". 214 o intended configuration: Configuration that is intended to be used 215 by the device. It represents the configuration after all 216 configuration transformations to have been performed and 217 is the configuration that the system attempts to apply. 219 o intended configuration datastore: A configuration datastore 220 holding the complete intended configuration of the device. This 221 datastore is referred to as "". 223 o configuration transformation: The addition, modification or 224 removal of configuration between the and 225 datastores. Examples of configuration transformations include the 226 removal of inactive configuration and the configuration produced 227 through the expansion of templates. 229 o conventional configuration datastore: One of the following set of 230 configuration datastores: , , , and 231 . These datastores share a common datastore schema, and 232 protocol operations allow copying data between these datastores. 233 The term "conventional" is chosen as a generic umbrella term for 234 these datastores. 236 o conventional configuration: Configuration that is stored in any of 237 the conventional configuration datastores. 239 o dynamic configuration datastore: A configuration datastore holding 240 configuration obtained dynamically during the operation of a 241 device through interaction with other systems, rather than through 242 one of the conventional configuration datastores. 244 o dynamic configuration: Configuration obtained via a dynamic 245 configuration datastore. 247 o learned configuration: Configuration that has been learned via 248 protocol interactions with other systems and that is neither 249 conventional nor dynamic configuration. 251 o system configuration: Configuration that is supplied by the device 252 itself. 254 o default configuration: Configuration that is not explicitly 255 provided but for which a value defined in the data model is used. 257 o applied configuration: Configuration that is actively in use by a 258 device. Applied configuration originates from conventional, 259 dynamic, learned, system and default configuration. 261 o system state: The additional data on a system that is not 262 configuration, such as read-only status information and collected 263 statistics. System state is transient and modified by 264 interactions with internal components or other systems. System 265 state is modeled in YANG using "config false" nodes. 267 o operational state: The combination of applied configuration and 268 system state. 270 o operational state datastore: A datastore holding the complete 271 operational state of the device. This datastore is referred to as 272 "". 274 o origin: A metadata annotation indicating the origin of a data 275 item. 277 o remnant configuration: Configuration that remains part of the 278 applied configuration for a period of time after it has been 279 removed from the intended configuration or dynamic configuration. 280 The time period may be minimal, or may last until all resources 281 used by the newly-deleted configuration (e.g., network 282 connections, memory allocations, file handles) have been 283 deallocated. 285 The following additional terms are not datastore specific but 286 commonly used and thus defined here as well: 288 o client: An entity that can access YANG-defined data on a server, 289 over some network management protocol. 291 o server: An entity that provides access to YANG-defined data to a 292 client, over some network management protocol. 294 o notification: A server-initiated message indicating that a certain 295 event has been recognized by the server. 297 o remote procedure call: An operation that can be invoked by a 298 client on a server. 300 4. Background 302 NETCONF [RFC6241] provides the following definitions: 304 o datastore: A conceptual place to store and access information. A 305 datastore might be implemented, for example, using files, a 306 database, flash memory locations, or combinations thereof. 308 o configuration datastore: The datastore holding the complete set of 309 configuration that is required to get a device from its initial 310 default state into a desired operational state. 312 YANG 1.1 [RFC7950] provides the following refinements when NETCONF is 313 used with YANG (which is the usual case but note that NETCONF was 314 defined before YANG existed): 316 o datastore: When modeled with YANG, a datastore is realized as an 317 instantiated data tree. 319 o configuration datastore: When modeled with YANG, a configuration 320 datastore is realized as an instantiated data tree with 321 configuration. 323 [RFC6244] defined operational state data as follows: 325 o Operational state data is a set of data that has been obtained by 326 the system at runtime and influences the system's behavior similar 327 to configuration data. In contrast to configuration data, 328 operational state is transient and modified by interactions with 329 internal components or other systems via specialized protocols. 331 Section 4.3.3 of [RFC6244] discusses operational state and among 332 other things mentions the option to consider operational state as 333 being stored in another datastore. Section 4.4 of this document then 334 concludes that at the time of the writing, modeling state as distinct 335 leafs and distinct branches is the recommended approach. 337 Implementation experience and requests from operators 338 [I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate] 339 indicate that the datastore model initially designed for NETCONF and 340 refined by YANG needs to be extended. In particular, the notion of 341 intended configuration and applied configuration has developed. 343 4.1. Original Model of Datastores 345 The following drawing shows the original model of datastores as it is 346 currently used by NETCONF [RFC6241]: 348 +-------------+ +-----------+ 349 | | | | 350 | (ct, rw) |<---+ +--->| (ct, rw) | 351 +-------------+ | | +-----------+ 352 | | | | 353 | +-----------+ | 354 +-------->| |<--------+ 355 | (ct, rw) | 356 +-----------+ 357 | 358 v 359 operational state <--- control plane 360 (cf, ro) 362 ct = config true; cf = config false 363 rw = read-write; ro = read-only 364 boxes denote datastores 366 Figure 1 368 Note that this diagram simplifies the model: read-only (ro) and read- 369 write (rw) is to be understood at a conceptual level. In NETCONF, 370 for example, support for and is optional and 371 does not have to be writable. Furthermore, can 372 only be modified by copying to in the 373 standardized NETCONF datastore editing model. The RESTCONF protocol 374 does not expose these differences and instead provides only a 375 writable unified datastore, which hides whether edits are done 376 through or by directly modifying or via some 377 other implementation specific mechanism. RESTCONF also hides how 378 configuration is made persistent. Note that implementations may also 379 have additional datastores that can propagate changes to . 380 NETCONF explicitly mentions so called named datastores. 382 Some observations: 384 o Operational state has not been defined as a datastore although 385 there were proposals in the past to introduce an operational state 386 datastore. 388 o The NETCONF operation returns the contents of 389 together with the operational state. It is therefore necessary 390 that "config false" data is in a different branch than the "config 391 true" data if the operational state can have a different lifetime 392 compared to configuration or if configuration is not immediately 393 or successfully applied. 395 o Several implementations have proprietary mechanisms that allow 396 clients to store inactive data in . Inactive data is 397 conceptually removed before validation. 399 o Some implementations have proprietary mechanisms that allow 400 clients to define configuration templates in . These 401 templates are expanded automatically by the system, and the 402 resulting configuration is applied internally. 404 o Some operators have reported that it is essential for them to be 405 able to retrieve the configuration that has actually been 406 successfully applied, which may be a subset or a superset of the 407 configuration. 409 5. Architectural Model of Datastores 411 Below is a new conceptual model of datastores extending the original 412 model in order to reflect the experience gained with the original 413 model. 415 +-------------+ +-----------+ 416 | | | | 417 | (ct, rw) |<---+ +--->| (ct, rw) | 418 +-------------+ | | +-----------+ 419 | | | | 420 | +-----------+ | 421 +-------->| |<--------+ 422 | (ct, rw) | 423 +-----------+ 424 | 425 | // configuration transformations, 426 | // e.g., removal of nodes marked as 427 | // "inactive", expansion of 428 | // templates 429 v 430 +------------+ 431 | | // subject to validation 432 | (ct, ro) | 433 +------------+ 434 | // changes applied, subject to 435 | // local factors, e.g., missing 436 | // resources, delays 437 | 438 dynamic | +-------- learned configuration 439 configuration | +-------- system configuration 440 datastores -----+ | +-------- default configuration 441 | | | 442 v v v 443 +---------------+ 444 | | <-- system state 445 | (ct + cf, ro) | 446 +---------------+ 448 ct = config true; cf = config false 449 rw = read-write; ro = read-only 450 boxes denote named datastores 452 Figure 2 454 5.1. Conventional Configuration Datastores 456 The conventional configuration datastores are a set of configuration 457 datastores that share exactly the same datastore schema, allowing 458 data to be copied between them. The term is meant as a generic 459 umbrella description of these datastores. If a module does not 460 contain any configuration data nodes and it is not needed to satisfy 461 any imports, then it MAY be omitted from the datastore schema for the 462 conventional configuration datastores. The set of datastores 463 include: 465 o 467 o 469 o 471 o 473 Other conventional configuration datastores may be defined in future 474 documents. 476 The flow of data between these datastores is depicted in Section 5. 478 The specific protocols may define explicit operations to copy between 479 these datastores, e.g., NETCONF defines the operation. 481 5.1.1. The Startup Configuration Datastore () 483 The startup configuration datastore () is a configuration 484 datastore holding the configuration loaded by the device when it 485 boots. is only present on devices that separate the 486 startup configuration from the running configuration datastore. 488 The startup configuration datastore may not be supported by all 489 protocols or implementations. 491 On devices that support non-volatile storage, the contents of 492 will typically persist across reboots via that storage. At 493 boot time, the device loads the saved startup configuration into 494 . To save a new startup configuration, data is copied to 495 , either via implicit or explicit protocol operations. 497 5.1.2. The Candidate Configuration Datastore () 499 The candidate configuration datastore () is a 500 configuration datastore that can be manipulated without impacting the 501 device's current configuration and that can be committed to 502 . 504 The candidate configuration datastore may not be supported by all 505 protocols or implementations. 507 does not typically persist across reboots, even in the 508 presence of non-volatile storage. If is stored using 509 non-volatile storage, it is reset at boot time to the contents of 510 . 512 5.1.3. The Running Configuration Datastore () 514 The running configuration datastore () is a configuration 515 datastore that holds the complete current configuration on the 516 device. It MAY include configuration that requires further 517 transformation before it can be applied, e.g., inactive 518 configuration, or template-mechanism-oriented configuration that 519 needs further expansion. However, MUST always be a valid 520 configuration data tree, as defined in Section 8.1 of [RFC7950]. 522 MUST be supported if the device can be configured via 523 conventional configuration datastores. 525 If a device does not have a distinct and non-volatile 526 storage is available, the device will typically use that non-volatile 527 storage to allow to persist across reboots. 529 5.1.4. The Intended Configuration Datastore () 531 The intended configuration datastore () is a read-only 532 configuration datastore. It represents the configuration after all 533 configuration transformations to are performed (e.g., 534 template expansion, removal of inactive configuration), and is the 535 configuration that the system attempts to apply. 537 is tightly coupled to . Whenever data is written 538 to , then MUST also be immediately updated by 539 performing all necessary configuration transformations to the 540 contents of and then is validated. 542 MAY also be updated independently of if the 543 effect of a configuration transformation changes, but MUST 544 always be a valid configuration data tree, as defined in Section 8.1 545 of [RFC7950]. 547 For simple implementations, and are identical. 549 The contents of are also related to the "config true" 550 subset of , and hence a client can determine to what 551 extent the intended configuration is currently in use by checking 552 whether the contents of also appear in . 554 does not persist across reboots; its relationship with 555 makes that unnecessary. 557 Currently there are no standard mechanisms defined that affect 558 so that it would have different content than , 559 but this architecture allows for such mechanisms to be defined. 561 One example of such a mechanism is support for marking nodes as 562 inactive in . Inactive nodes are not copied to . 563 A second example is support for templates, which can perform 564 transformations on the configuration from to the 565 configuration written to . 567 5.2. Dynamic Configuration Datastores 569 The model recognizes the need for dynamic configuration datastores 570 that are, by definition, not part of the persistent configuration of 571 a device. In some contexts, these have been termed ephemeral 572 datastores since the information is ephemeral, i.e., lost upon 573 reboot. The dynamic configuration datastores interact with the rest 574 of the system through . 576 The datastore schema for a dynamic configuration datastore MAY differ 577 from the datastore schema used for conventional configuration 578 datastores. If a module does not contain any configuration data 579 nodes and it is not needed to satisfy any imports, then it MAY be 580 omitted from the datastore schema for the dynamic configuration 581 datastore. 583 5.3. The Operational State Datastore () 585 The operational state datastore () is a read-only 586 datastore that consists of all "config true" and "config false" nodes 587 defined in the datastore's schema. In the original NETCONF model the 588 operational state only had "config false" nodes. The reason for 589 incorporating "config true" nodes here is to be able to expose all 590 operational settings without having to replicate definitions in the 591 data models. 593 contains system state and all configuration actually 594 used by the system. This includes all applied configuration from 595 , learned configuration, system-provided configuration, and 596 default values defined by any supported data models. In addition, 597 also contains applied configuration from dynamic 598 configuration datastores. 600 The datastore schema for MUST be a superset of the 601 combined datastore schema used in all configuration datastores except 602 that configuration data nodes supported in a configuration datastore 603 MAY be omitted from if a server is not able to 604 accurately report them. 606 Requests to retrieve nodes from always return the value 607 in use if the node exists, regardless of any default value specified 608 in the YANG module. If no value is returned for a given node, then 609 this implies that the node is not used by the device. 611 The interpretation of what constitutes as being "in use" by the 612 system is dependent on both the schema definition and the device 613 implementation. Generally, functionality that is enabled and 614 operational on the system would be considered as being "in use". 615 Conversely, functionality that is neither enabled nor operational on 616 the system is considered as not being "in use", and hence SHOULD be 617 omitted from . 619 SHOULD conform to any constraints specified in the data 620 model, but given the principal aim of returning "in use" values, it 621 is possible that constraints MAY be violated under some 622 circumstances, e.g., an abnormal value is "in use", the structure of 623 a list is being modified, or due to remnant configuration (see 624 Section 5.3.1). Note, that deviations SHOULD be used when it is 625 known in advance that a device does not fully conform to the 626 schema. 628 Only semantic constraints MAY be violated, these are the YANG "when", 629 "must", "mandatory", "unique", "min-elements", and "max-elements" 630 statements; and the uniqueness of key values. 632 Syntactic constraints MUST NOT be violated, including hierarchical 633 organization, identifiers, and type-based constraints. If a node in 634 does not meet the syntactic constraints then it MUST 635 NOT be returned, and some other mechanism should be used to flag the 636 error. 638 does not persist across reboots. 640 5.3.1. Remnant Configuration 642 Changes to configuration may take time to percolate through to 643 . During this period, may contain nodes 644 for both the previous and current configuration, as closely as 645 possible tracking the current operation of the device. Such remnant 646 configuration from the previous configuration persists until the 647 system has released resources used by the newly-deleted configuration 648 (e.g., network connections, memory allocations, file handles). 650 Remnant configuration is a common example of where the semantic 651 constraints defined in the data model cannot be relied upon for 652 , since the system may have remnant configuration whose 653 constraints were valid with the previous configuration and that are 654 not valid with the current configuration. Since constraints on 655 "config false" nodes may refer to "config true" nodes, remnant 656 configuration may force the violation of those constraints. 658 5.3.2. Missing Resources 660 Configuration in can refer to resources that are not 661 available or otherwise not physically present. In these situations, 662 these parts of are not applied. The data appears in 663 but does not appear in . 665 A typical example is an interface configuration that refers to an 666 interface that is not currently present. In such a situation, the 667 interface configuration remains in but the interface 668 configuration will not appear in . 670 Note that configuration validity cannot depend on the current state 671 of such resources, since that would imply that removing a resource 672 might render the configuration invalid. This is unacceptable, 673 especially given that rebooting such a device would cause it to 674 restart with an invalid configuration. Instead we allow 675 configuration for missing resources to exist in and 676 , but it will not appear in . 678 5.3.3. System-controlled Resources 680 Sometimes resources are controlled by the device and the 681 corresponding system controlled data appears in (and disappears from) 682 dynamically. If a system controlled resource has 683 matching configuration in when it appears, the system will 684 try to apply the configuration, which causes the configuration to 685 appear in eventually (if application of the 686 configuration was successful). 688 5.3.4. Origin Metadata Annotation 690 As configuration flows into , it is conceptually marked 691 with a metadata annotation ([RFC7952]) that indicates its origin. 692 The origin applies to all configuration nodes except non-presence 693 containers. The "origin" metadata annotation is defined in 694 Section 7. The values are YANG identities. The following identities 695 are defined: 697 o origin: abstract base identity from which the other origin 698 identities are derived. 700 o intended: represents configuration provided by . 702 o dynamic: represents configuration provided by a dynamic 703 configuration datastore. 705 o system: represents configuration provided by the system itself. 706 Examples of system configuration include applied configuration for 707 an always existing loopback interface, or interface configuration 708 that is auto-created due to the hardware currently present in the 709 device. 711 o learned: represents configuration that has been learned via 712 protocol interactions with other systems, including protocols such 713 as link-layer negotiations, routing protocols, DHCP, etc. 715 o default: represents configuration using a default value specified 716 in the data model, using either values in the "default" statement 717 or any values described in the "description" statement. The 718 default origin is only used when the configuration has not been 719 provided by any other source. 721 o unknown: represents configuration for which the system cannot 722 identify the origin. 724 These identities can be further refined, e.g., there could be 725 separate identities for particular types or instances of dynamic 726 configuration datastores derived from "dynamic". 728 For all configuration data nodes in , the device SHOULD 729 report the origin that most accurately reflects the source of the 730 configuration that is in use by the system. 732 In cases where it could be ambiguous as to which origin should be 733 used, i.e. where the same data node value has originated from 734 multiple sources, then the description statement in the YANG module 735 SHOULD be used as guidance for choosing the appropriate origin. For 736 example: 738 If for a particular configuration node, the associated YANG 739 description statement indicates that a protocol negotiated value 740 overrides any configured value, then the origin would be reported as 741 "learned", even when a learned value is the same as the configured 742 value. 744 Conversely, if for a particular configuration node, the associated 745 YANG description statement indicates that a protocol negotiated value 746 does not override an explicitly configured value, then the origin 747 would be reported as "intended" even when a learned value is the same 748 as the configured value. 750 In the case that a device cannot provide an accurate origin for a 751 particular configuration data node then it SHOULD use the origin 752 "unknown". 754 6. Implications on YANG 756 6.1. XPath Context 758 This section updates section 6.4.1 of RFC 7950. 760 If a server implements the architecture defined in this document, the 761 accessible trees for some XPath contexts are refined as follows: 763 o If the XPath expression is defined in a substatement to a data 764 node that represents system state, the accessible tree is all 765 operational state in the server. The root node has all top-level 766 data nodes in all modules as children. 768 o If the XPath expression is defined in a substatement to a 769 "notification" statement, the accessible tree is the notification 770 instance and all operational state in the server. If the 771 notification is defined on the top level in a module, then the 772 root node has the node representing the notification being defined 773 and all top-level data nodes in all modules as children. 774 Otherwise, the root node has all top-level data nodes in all 775 modules as children. 777 o If the XPath expression is defined in a substatement to an "input" 778 statement in an "rpc" or "action" statement, the accessible tree 779 is the RPC or action operation instance and all operational state 780 in the server. The root node has top-level data nodes in all 781 modules as children. Additionally, for an RPC, the root node also 782 has the node representing the RPC operation being defined as a 783 child. The node representing the operation being defined has the 784 operation's input parameters as children. 786 o If the XPath expression is defined in a substatement to an 787 "output" statement in an "rpc" or "action" statement, the 788 accessible tree is the RPC or action operation instance and all 789 operational state in the server. The root node has top-level data 790 nodes in all modules as children. Additionally, for an RPC, the 791 root node also has the node representing the RPC operation being 792 defined as a child. The node representing the operation being 793 defined has the operation's output parameters as children. 795 6.2. Invocation of Actions and RPCs 797 This section updates section 7.15 of RFC 7950. 799 Actions are always invoked in the context of the operational state 800 datastore. The node for which the action is invoked MUST exist in 801 the operational state datastore. 803 Note that this document does not constrain the result of invoking an 804 RPC or action in any way. For example, an RPC might be defined to 805 modify the contents of some datastore. 807 7. YANG Modules 809 file "ietf-datastores@2017-12-20.yang" 811 module ietf-datastores { 812 yang-version 1.1; 813 namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; 814 prefix ds; 816 organization 817 "IETF Network Modeling (NETMOD) Working Group"; 819 contact 820 "WG Web: 822 WG List: 824 Author: Martin Bjorklund 825 827 Author: Juergen Schoenwaelder 828 830 Author: Phil Shafer 831 833 Author: Kent Watsen 834 836 Author: Rob Wilton 837 "; 839 description 840 "This YANG module defines two sets of identities for datastores. 841 The first identifies the datastores themselves, the second 842 identifies datastore properties. 844 Copyright (c) 2017 IETF Trust and the persons identified as 845 authors of the code. All rights reserved. 847 Redistribution and use in source and binary forms, with or 848 without modification, is permitted pursuant to, and subject to 849 the license terms contained in, the Simplified BSD License set 850 forth in Section 4.c of the IETF Trust's Legal Provisions 851 Relating to IETF Documents 852 (http://trustee.ietf.org/license-info). 854 This version of this YANG module is part of RFC XXXX 855 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 856 for full legal notices."; 858 revision 2017-12-20 { 859 description 860 "Initial revision."; 861 reference 862 "RFC XXXX: Network Management Datastore Architecture"; 863 } 865 /* 866 * Identities 867 */ 869 identity datastore { 870 description 871 "Abstract base identity for datastore identities."; 872 } 874 identity conventional { 875 base datastore; 876 description 877 "Abstract base identity for conventional configuration 878 datastores."; 879 } 881 identity running { 882 base conventional; 883 description 884 "The running configuration datastore."; 885 } 887 identity candidate { 888 base conventional; 889 description 890 "The candidate configuration datastore."; 891 } 892 identity startup { 893 base conventional; 894 description 895 "The startup configuration datastore."; 896 } 898 identity intended { 899 base conventional; 900 description 901 "The intended configuration datastore."; 902 } 904 identity dynamic { 905 base datastore; 906 description 907 "Abstract base identity for dynamic configuration datastores."; 908 } 910 identity operational { 911 base datastore; 912 description 913 "The operational state datastore."; 914 } 916 /* 917 * Type definitions 918 */ 920 typedef datastore-ref { 921 type identityref { 922 base datastore; 923 } 924 description 925 "A datastore identity reference."; 926 } 928 } 930 932 file "ietf-origin@2017-12-20.yang" 934 module ietf-origin { 935 yang-version 1.1; 936 namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; 937 prefix or; 939 import ietf-yang-metadata { 940 prefix md; 941 } 943 organization 944 "IETF Network Modeling (NETMOD) Working Group"; 946 contact 947 "WG Web: 949 WG List: 951 Author: Martin Bjorklund 952 954 Author: Juergen Schoenwaelder 955 957 Author: Phil Shafer 958 960 Author: Kent Watsen 961 963 Author: Rob Wilton 964 "; 966 description 967 "This YANG module defines an 'origin' metadata annotation, and a 968 set of identities for the origin value. 970 Copyright (c) 2017 IETF Trust and the persons identified as 971 authors of the code. All rights reserved. 973 Redistribution and use in source and binary forms, with or 974 without modification, is permitted pursuant to, and subject to 975 the license terms contained in, the Simplified BSD License set 976 forth in Section 4.c of the IETF Trust's Legal Provisions 977 Relating to IETF Documents 978 (http://trustee.ietf.org/license-info). 980 This version of this YANG module is part of RFC XXXX 981 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 982 for full legal notices."; 984 revision 2017-12-20 { 985 description 986 "Initial revision."; 987 reference 988 "RFC XXXX: Network Management Datastore Architecture"; 989 } 991 /* 992 * Identities 993 */ 995 identity origin { 996 description 997 "Abstract base identity for the origin annotation."; 998 } 1000 identity intended { 1001 base origin; 1002 description 1003 "Denotes configuration from the intended configuration 1004 datastore"; 1005 } 1007 identity dynamic { 1008 base origin; 1009 description 1010 "Denotes configuration from a dynamic configuration 1011 datastore."; 1012 } 1014 identity system { 1015 base origin; 1016 description 1017 "Denotes configuration originated by the system itself. 1019 Examples of system configuration include applied configuration 1020 for an always existing loopback interface, or interface 1021 configuration that is auto-created due to the hardware 1022 currently present in the device."; 1023 } 1025 identity learned { 1026 base origin; 1027 description 1028 "Denotes configuration learned from protocol interactions with 1029 other devices, instead of via either the intended 1030 configuration datastore or any dynamic configuration 1031 datastore. 1033 Examples of protocols that provide learned configuration 1034 include link-layer negotiations, routing protocols, and 1035 DHCP."; 1037 } 1039 identity default { 1040 base origin; 1041 description 1042 "Denotes configuration that does not have an configured or 1043 learned value, but has a default value in use. Covers both 1044 values defined in a 'default' statement, and values defined 1045 via an explanation in a 'description' statement."; 1046 } 1048 identity unknown { 1049 base origin; 1050 description 1051 "Denotes configuration for which the system cannot identify the 1052 origin."; 1053 } 1055 /* 1056 * Type definitions 1057 */ 1059 typedef origin-ref { 1060 type identityref { 1061 base origin; 1062 } 1063 description 1064 "An origin identity reference."; 1065 } 1067 /* 1068 * Metadata annotations 1069 */ 1071 md:annotation origin { 1072 type origin-ref; 1073 description 1074 "The 'origin' annotation can be present on any configuration 1075 data node in the operational state datastore. It specifies 1076 from where the node originated. If not specified for a given 1077 configuration data node then the origin is the same as the 1078 origin of its parent node in the data tree. The origin for 1079 any top level configuration data nodes must be specified."; 1080 } 1081 } 1083 1085 8. IANA Considerations 1087 8.1. Updates to the IETF XML Registry 1089 This document registers two URIs in the IETF XML registry [RFC3688]. 1090 Following the format in [RFC3688], the following registrations are 1091 requested: 1093 URI: urn:ietf:params:xml:ns:yang:ietf-datastores 1094 Registrant Contact: The IESG. 1095 XML: N/A, the requested URI is an XML namespace. 1097 URI: urn:ietf:params:xml:ns:yang:ietf-origin 1098 Registrant Contact: The IESG. 1099 XML: N/A, the requested URI is an XML namespace. 1101 8.2. Updates to the YANG Module Names Registry 1103 This document registers two YANG modules in the YANG Module Names 1104 registry [RFC6020]. Following the format in [RFC6020], the following 1105 registrations are requested: 1107 name: ietf-datastores 1108 namespace: urn:ietf:params:xml:ns:yang:ietf-datastores 1109 prefix: ds 1110 reference: RFC XXXX 1112 name: ietf-origin 1113 namespace: urn:ietf:params:xml:ns:yang:ietf-origin 1114 prefix: or 1115 reference: RFC XXXX 1117 9. Security Considerations 1119 This document discusses an architectural model of datastores for 1120 network management using NETCONF/RESTCONF and YANG. It has no 1121 security impact on the Internet. 1123 Although this document specifies several YANG modules, these modules 1124 only define identities and meta-data, hence the "YANG module security 1125 guidelines" do not apply. 1127 10. Acknowledgments 1129 This document grew out of many discussions that took place since 1130 2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational], 1131 [I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs], 1132 [I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and 1134 [RFC6244] touched on some of the problems of the original datastore 1135 model. The following people were authors to these Internet-Drafts or 1136 otherwise actively involved in the discussions that led to this 1137 document: 1139 o Lou Berger, LabN Consulting, L.L.C., 1141 o Andy Bierman, YumaWorks, 1143 o Marcus Hines, Google, 1145 o Christian Hopps, Deutsche Telekom, 1147 o Balazs Lengyel, Ericsson, 1149 o Acee Lindem, Cisco Systems, 1151 o Ladislav Lhotka, CZ.NIC, 1153 o Thomas Nadeau, Brocade Networks, 1155 o Tom Petch, Engineering Networks Ltd, 1157 o Anees Shaikh, Google, 1159 o Rob Shakir, Google, 1161 o Jason Sterne, Nokia, 1163 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 1164 Excellence project (ICT-318488) supported by the European Commission 1165 under its Seventh Framework Programme. 1167 11. References 1169 11.1. Normative References 1171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1172 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1173 RFC2119, March 1997, . 1176 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1177 and A. Bierman, Ed., "Network Configuration Protocol 1178 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1179 . 1181 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1182 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1183 . 1185 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 1186 7952, DOI 10.17487/RFC7952, August 2016, . 1189 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1190 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1191 . 1193 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1194 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1195 May 2017, . 1197 11.2. Informative References 1199 [I-D.bjorklund-netmod-operational] 1200 Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF 1201 and YANG", draft-bjorklund-netmod-operational-00 (work in 1202 progress), October 2012. 1204 [I-D.ietf-netmod-opstate-reqs] 1205 Watsen, K. and T. Nadeau, "Terminology and Requirements 1206 for Enhanced Handling of Operational State", draft-ietf- 1207 netmod-opstate-reqs-04 (work in progress), January 2016. 1209 [I-D.kwatsen-netmod-opstate] 1210 Watsen, K., Bierman, A., Bjorklund, M., and J. 1211 Schoenwaelder, "Operational State Enhancements for YANG, 1212 NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02 1213 (work in progress), February 2016. 1215 [I-D.openconfig-netmod-opstate] 1216 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 1217 of Operational State Data in YANG", draft-openconfig- 1218 netmod-opstate-01 (work in progress), July 2015. 1220 [I-D.wilton-netmod-opstate-yang] 1221 Wilton, R., ""With-config-state" Capability for NETCONF/ 1222 RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in 1223 progress), December 2015. 1225 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1226 DOI 10.17487/RFC3688, January 2004, . 1229 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1230 the Network Configuration Protocol (NETCONF)", RFC 6020, 1231 DOI 10.17487/RFC6020, October 2010, . 1234 [RFC6244] Shafer, P., "An Architecture for Network Management Using 1235 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 1236 2011, . 1238 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1239 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1240 . 1242 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 1243 7277, DOI 10.17487/RFC7277, June 2014, . 1246 Appendix A. Guidelines for Defining Datastores 1248 The definition of a new datastore in this architecture should be 1249 provided in a document (e.g., an RFC) purposed to the definition of 1250 the datastore. When it makes sense, more than one datastore may be 1251 defined in the same document (e.g., when the datastores are logically 1252 connected). Each datastore's definition should address the points 1253 specified in the sections below. 1255 A.1. Define which YANG modules can be used in the datastore 1257 Not all YANG modules may be used in all datastores. Some datastores 1258 may constrain which data models can be used in them. If it is 1259 desirable that a subset of all modules can be targeted to the 1260 datastore, then the documentation defining the datastore must 1261 indicate this. 1263 A.2. Define which subset of YANG-modeled data applies 1265 By default, the data in a datastore is modeled by all YANG statements 1266 in the available YANG modules. However, it is possible to specify 1267 criteria that YANG statements must satisfy in order to be present in 1268 a datastore. For instance, maybe only "config true" nodes, or 1269 "config false" nodes that also have a specific YANG extension, are 1270 present in the datastore. 1272 A.3. Define how data is actualized 1274 The new datastore must specify how it interacts with other 1275 datastores. 1277 For example, the diagram in Section 5 depicts dynamic configuration 1278 datastores feeding into . How this interaction occurs 1279 has to be defined by the particular dynamic configuration datastores. 1280 In some cases, it may occur implicitly, as soon as the data is put 1281 into the dynamic configuration datastore while, in other cases, an 1282 explicit action (e.g., an RPC) may be required to trigger the 1283 application of the datastore's data. 1285 A.4. Define which protocols can be used 1287 By default, it is assumed that both the NETCONF and RESTCONF 1288 protocols can be used to interact with a datastore. However, it may 1289 be that only a specific protocol can be used (e.g., ForCES) or that a 1290 subset of all protocol operations or capabilities are available 1291 (e.g., no locking or no XPath-based filtering). 1293 A.5. Define YANG identities for the datastore 1295 The datastore must be defined with a YANG identity that uses the 1296 "ds:datastore" identity, or one of its derived identities, as its 1297 base. This identity is necessary so that the datastore can be 1298 referenced in protocol operations (e.g., ). 1300 The datastore may also be defined with an identity that uses the 1301 "or:origin" identity or one its derived identities as its base. This 1302 identity is needed if the datastore interacts with so 1303 that data originating from the datastore can be identified as such 1304 via the "origin" metadata attribute defined in Section 7. 1306 An example of these guidelines in use is provided in Appendix B. 1308 Appendix B. Ephemeral Dynamic Configuration Datastore Example 1310 The section defines documentation for an example dynamic 1311 configuration datastore using the guidelines provided in Appendix A. 1312 While this example is very terse, it is expected to be that a 1313 standalone RFC would be needed when fully expanded. 1315 This example defines a dynamic configuration datastore called 1316 "ephemeral", which is loosely modeled after the work done in the I2RS 1317 working group. 1319 +--------------+---------------------------------------------------+ 1320 | Name | Value | 1321 +--------------+---------------------------------------------------+ 1322 | Name | ephemeral | 1323 | YANG modules | all (default) | 1324 | YANG nodes | all "config true" data nodes | 1325 | How applied | changes automatically propagated to | 1326 | Protocols | NC/RC (default) | 1327 | YANG Module | (see below) | 1328 +--------------+---------------------------------------------------+ 1330 The example "ephemeral" datastore properties 1332 module example-ds-ephemeral { 1333 yang-version 1.1; 1334 namespace "urn:example:ds-ephemeral"; 1335 prefix eph; 1337 import ietf-datastores { 1338 prefix ds; 1339 } 1340 import ietf-origin { 1341 prefix or; 1342 } 1344 // datastore identity 1345 identity ds-ephemeral { 1346 base ds:dynamic; 1347 description 1348 "The ephemeral dynamic configuration datastore."; 1349 } 1351 // origin identity 1352 identity or-ephemeral { 1353 base or:dynamic; 1354 description 1355 "Denotes data from the ephemeral dynamic configuration 1356 datastore."; 1357 } 1358 } 1360 Appendix C. Example Data 1362 The use of datastores is complex, and many of the subtle effects are 1363 more easily presented using examples. This section presents a series 1364 of example data models with some sample contents of the various 1365 datastores. 1367 C.1. System Example 1369 In this example, the following fictional module is used: 1371 module example-system { 1372 yang-version 1.1; 1373 namespace urn:example:system; 1374 prefix sys; 1376 import ietf-inet-types { 1377 prefix inet; 1378 } 1380 container system { 1381 leaf hostname { 1382 type string; 1383 } 1385 list interface { 1386 key name; 1388 leaf name { 1389 type string; 1390 } 1392 container auto-negotiation { 1393 leaf enabled { 1394 type boolean; 1395 default true; 1396 } 1397 leaf speed { 1398 type uint32; 1399 units mbps; 1400 description 1401 "The advertised speed, in mbps."; 1402 } 1403 } 1405 leaf speed { 1406 type uint32; 1407 units mbps; 1408 config false; 1409 description 1410 "The speed of the interface, in mbps."; 1411 } 1413 list address { 1414 key ip; 1415 leaf ip { 1416 type inet:ip-address; 1417 } 1418 leaf prefix-length { 1419 type uint8; 1420 } 1421 } 1422 } 1423 } 1424 } 1426 The operator has configured the host name and two interfaces, so the 1427 contents of are: 1429 1431 foo 1433 1434 eth0 1435 1436 1000 1437 1438
1439 2001:db8::10 1440 64 1441
1442 1444 1445 eth1 1446
1447 2001:db8::20 1448 64 1449
1450 1452 1454 The system has detected that the hardware for one of the configured 1455 interfaces ("eth1") is not yet present, so the configuration for that 1456 interface is not applied. Further, the system has received a host 1457 name and an additional IP address for "eth0" over DHCP. In addition 1458 to a default value, a loopback interface is automatically added by 1459 the system, and the result of the "speed" auto-negotiation. All of 1460 this is reflected in . Note how the origin metadata 1461 attribute for several "config true" data nodes is inherited from 1462 their parent data nodes. 1464 1468 bar 1470 1471 eth0 1472 1473 true 1474 1000 1475 1476 100 1477
1478 2001:db8::10 1479 64 1480
1481
1482 2001:db8::1:100 1483 64 1484
1485 1487 1488 lo0 1489
1490 ::1 1491 128 1492
1493 1495 1497 C.2. BGP Example 1499 Consider the following fragment of a fictional BGP module: 1501 container bgp { 1502 leaf local-as { 1503 type uint32; 1504 } 1505 leaf peer-as { 1506 type uint32; 1507 } 1508 list peer { 1509 key name; 1510 leaf name { 1511 type inet:ip-address; 1512 } 1513 leaf local-as { 1514 type uint32; 1515 description 1516 ".... Defaults to ../local-as"; 1517 } 1518 leaf peer-as { 1519 type uint32; 1520 description 1521 "... Defaults to ../peer-as"; 1522 } 1523 leaf local-port { 1524 type inet:port; 1525 } 1526 leaf remote-port { 1527 type inet:port; 1528 default 179; 1529 } 1530 leaf state { 1531 config false; 1532 type enumeration { 1533 enum init; 1534 enum established; 1535 enum closing; 1536 } 1537 } 1538 } 1539 } 1541 In this example model, both bgp/peer/local-as and bgp/peer/peer-as 1542 have complex hierarchical values, allowing the user to specify 1543 default values for all peers in a single location. 1545 The model also follows the pattern of fully integrating state 1546 ("config false") nodes with configuration ("config true") nodes. 1547 There is no separate "bgp-state" hierarchy, with the accompanying 1548 repetition of containment and naming nodes. This makes the model 1549 simpler and more readable. 1551 C.2.1. Datastores 1553 Each datastore represents differing views of these nodes. 1554 will hold the configuration provided by the operator, for example a 1555 single BGP peer. will conceptually hold the data as 1556 validated, after the removal of data not intended for validation and 1557 after any local template mechanisms are performed. 1558 will show data from as well as any "config false" nodes. 1560 C.2.2. Adding a Peer 1562 If the user configures a single BGP peer, then that peer will be 1563 visible in both and . It may also appear in 1564 , if the server supports the candidate configuration 1565 datastore. Retrieving the peer will return only the user-specified 1566 values. 1568 No time delay should exist between the appearance of the peer in 1569 and . 1571 In this scenario, we've added the following to : 1573 1574 64501 1575 64502 1576 1577 10.1.2.3 1578 1579 1581 C.2.2.1. 1583 The operational datastore will contain the fully expanded peer data, 1584 including "config false" nodes. In our example, this means the 1585 "state" node will appear. 1587 In addition, will contain the "currently in use" values 1588 for all nodes. This means that local-as and peer-as will be 1589 populated even if they are not given values in . The value 1590 of bgp/local-as will be used if bgp/peer/local-as is not provided; 1591 bgp/peer-as and bgp/peer/peer-as will have the same relationship. In 1592 the operational view, this means that every peer will have values for 1593 their local-as and peer-as, even if those values are not explicitly 1594 configured but are provided by bgp/local-as and bgp/peer-as. 1596 Each BGP peer has a TCP connection associated with it, using the 1597 values of local-port and remote-port from . If those 1598 values are not supplied, the system will select values. When the 1599 connection is established, will contain the current 1600 values for the local-port and remote-port nodes regardless of the 1601 origin. If the system has chosen the values, the "origin" attribute 1602 will be set to "system". Before the connection is established, one 1603 or both of the nodes may not appear, since the system may not yet 1604 have their values. 1606 1607 64501 1608 64502 1609 1610 10.1.2.3 1611 64501 1612 64502 1613 60794 1614 179 1615 established 1616 1617 1619 C.2.3. Removing a Peer 1621 Changes to configuration may take time to percolate through the 1622 various software components involved. During this period, it is 1623 imperative to continue to give an accurate view of the working of the 1624 device. will contain nodes for both the previous and 1625 current configuration, as closely as possible tracking the current 1626 operation of the device. 1628 Consider the scenario where a client removes a BGP peer. When a peer 1629 is removed, the operational state will continue to reflect the 1630 existence of that peer until the peer's resources are released, 1631 including closing the peer's connection. During this period, the 1632 current data values will continue to be visible in , 1633 with the "origin" attribute set to indicate the origin of the 1634 original data. 1636 1637 64501 1638 64502 1639 1640 10.1.2.3 1641 64501 1642 64502 1643 60794 1644 179 1645 closing 1646 1647 1649 Once resources are released and the connection is closed, the peer's 1650 data is removed from . 1652 C.3. Interface Example 1654 In this section, we will use this simple interface data model: 1656 container interfaces { 1657 list interface { 1658 key name; 1659 leaf name { 1660 type string; 1661 } 1662 leaf description { 1663 type string; 1664 } 1665 leaf mtu { 1666 type uint16; 1667 } 1668 leaf-list ip-address { 1669 type inet:ip-address; 1670 } 1671 } 1672 } 1674 C.3.1. Pre-provisioned Interfaces 1676 One common issue in networking devices is the support of Field 1677 Replaceable Units (FRUs) that can be inserted and removed from the 1678 device without requiring a reboot or interfering with normal 1679 operation. These FRUs are typically interface cards, and the devices 1680 support pre-provisioning of these interfaces. 1682 If a client creates an interface "et-0/0/0" but the interface does 1683 not physically exist at this point, then might contain the 1684 following: 1686 1687 1688 et-0/0/0 1689 Test interface 1690 1691 1693 Since the interface does not exist, this data does not appear in 1694 . 1696 When a FRU containing this interface is inserted, the system will 1697 detect it and process the associated configuration. 1698 will contain the data from , as well as nodes added by the 1699 system, such as the current value of the interface's MTU. 1701 1702 1703 et-0/0/0 1704 Test interface 1705 1500 1706 1707 1709 If the FRU is removed, the interface data is removed from 1710 . 1712 C.3.2. System-provided Interface 1714 Imagine if the system provides a loopback interface (named "lo0") 1715 with a default ip-address of "127.0.0.1" and a default ip-address of 1716 "::1". The system will only provide configuration for this interface 1717 if there is no data for it in . 1719 When no configuration for "lo0" appears in , then 1720 will show the system-provided data: 1722 1723 1724 lo0 1725 127.0.0.1 1726 ::1 1727 1728 1730 When configuration for "lo0" does appear in , then 1731 will show that data with the origin set to "intended". 1732 If the "ip-address" is not provided, then the system-provided value 1733 will appear as follows: 1735 1736 1737 lo0 1738 loopback 1739 127.0.0.1 1740 ::1 1741 1742 1744 Authors' Addresses 1746 Martin Bjorklund 1747 Tail-f Systems 1749 Email: mbj@tail-f.com 1751 Juergen Schoenwaelder 1752 Jacobs University 1754 Email: j.schoenwaelder@jacobs-university.de 1756 Phil Shafer 1757 Juniper Networks 1759 Email: phil@juniper.net 1761 Kent Watsen 1762 Juniper Networks 1764 Email: kwatsen@juniper.net 1766 Robert Wilton 1767 Cisco Systems 1769 Email: rwilton@cisco.com