idnits 2.17.1 draft-ietf-netmod-revised-datastores-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7950, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2369 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 (==), 4 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: May 3, 2018 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 October 30, 2017 13 Network Management Datastore Architecture 14 draft-ietf-netmod-revised-datastores-06 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. 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 May 3, 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 () . . . 11 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 . . . . . . . . . . . . . . . . . . 14 74 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 75 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 76 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16 77 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16 78 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 80 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23 81 8.2. Updates to the YANG Module Names Registry . . . . . . . . 23 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 86 11.2. Informative References . . . . . . . . . . . . . . . . . 25 87 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26 88 A.1. Define which YANG modules can be used in the datastore . 27 89 A.2. Define which subset of YANG-modeled data applies . . . . 27 90 A.3. Define how data is actualized . . . . . . . . . . . . . . 27 91 A.4. Define which protocols can be used . . . . . . . . . . . 27 92 A.5. Define YANG identities for the datastore . . . . . . . . 27 93 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 94 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 95 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29 96 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 97 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 98 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 99 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35 100 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36 101 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36 102 C.3.2. System-provided Interface . . . . . . . . . . . . . . 37 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 105 1. Introduction 107 This document provides an architectural framework for datastores as 108 they are used by network management protocols such as NETCONF 109 [RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling 110 language. Datastores are a fundamental concept binding network 111 management data models to network management protocols. Agreement on 112 a common architectural model of datastores ensures that data models 113 can be written in a network management protocol agnostic way. This 114 architectural framework identifies a set of conceptual datastores but 115 it does not mandate that all network management protocols expose all 116 these conceptual datastores. This architecture is agnostic with 117 regard to the encoding used by network management protocols. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 2. Objectives 127 Network management data objects can often take two different values, 128 the value configured by the user or an application (configuration) 129 and the value that the device is actually using (operational state). 130 These two values may be different for a number of reasons, e.g., 131 system internal interactions with hardware, interaction with 132 protocols or other devices, or simply the time it takes to propagate 133 a configuration change to the software and hardware components of a 134 system. Furthermore, configuration and operational state data 135 objects may have different lifetimes. 137 The original model of datastores required these data objects to be 138 modeled twice in the YANG schema, as "config true" objects and as 139 "config false" objects. The convention adopted by the interfaces 140 data model ([RFC7223]) and the IP data model ([RFC7277]) was using 141 two separate branches rooted at the root of the data tree, one branch 142 for configuration data objects and one branch for operational state 143 data objects. 145 The duplication of definitions and the ad-hoc separation of 146 operational state data from configuration data leads to a number of 147 problems. Having configuration and operational state data in 148 separate branches in the data model is operationally complicated and 149 impacts the readability of module definitions. Furthermore, the 150 relationship between the branches is not machine readable and filter 151 expressions operating on configuration and on related operational 152 state are different. 154 With the revised architectural model of datastores defined in this 155 document, the data objects are defined only once in the YANG schema 156 but independent instantiations can appear in two different 157 datastores, one for configured values and one for operational state 158 values. This provides a more elegant and simpler solution to the 159 problem. 161 The revised architectural model of datastores supports additional 162 datastores for systems that support more advanced processing chains 163 converting configuration to operational state. For example, some 164 systems support configuration that is not currently used (so called 165 inactive configuration) or they support configuration templates that 166 are used to expand configuration data via a common template. 168 3. Terminology 170 This document defines the following terminology. Some of the terms 171 are revised definitions of terms originally defined in [RFC6241] and 172 [RFC7950] (see also section Section 4). The revised definitions are 173 semantically equivalent with the definitions found in [RFC6241] and 174 [RFC7950]. It is expected that the revised definitions provided in 175 this section will replace the definitions in [RFC6241] and [RFC7950] 176 when these documents are revised. 178 o datastore: A conceptual place to store and access information. A 179 datastore might be implemented, for example, using files, a 180 database, flash memory locations, or combinations thereof. A 181 datastore maps to an instantiated YANG data tree. 183 o schema node: A node in the schema tree. The formal definition is 184 in RFC 7950. 186 o datastore schema: The combined set of schema nodes for all modules 187 supported by a particular datastore, taking into consideration any 188 deviations and enabled features for that datastore. 190 o configuration: Data that is required to get a device from its 191 initial default state into a desired operational state. This data 192 is modeled in YANG using "config true" nodes. Configuration can 193 originate from different sources. 195 o configuration datastore: A datastore holding configuration. 197 o running configuration datastore: A configuration datastore holding 198 the current configuration of the device. It may include 199 configuration that requires further transformations before it can 200 be applied. This datastore is referred to as "". 202 o candidate configuration datastore: A configuration datastore that 203 can be manipulated without impacting the device's running 204 configuration datastore and that can be committed to the running 205 configuration datastore. This datastore is referred to as 206 "". 208 o startup configuration datastore: A configuration datastore holding 209 the configuration loaded by the device into the running 210 configuration datastore when it boots. This datastore is referred 211 to as "". 213 o intended configuration: Configuration that is intended to be used 214 by the device. It represents the configuration after all 215 configuration transformations to have been performed and 216 is the configuration that the system attempts to apply. 218 o intended configuration datastore: A configuration datastore 219 holding the complete intended configuration of the device. This 220 datastore is referred to as "". 222 o configuration transformation: The addition, modification or 223 removal of configuration between the and 224 datastores. Examples of configuration transformations include the 225 removal of inactive configuration and the configuration produced 226 through the expansion of templates. 228 o conventional configuration datastore: One of the following set of 229 configuration datastores: , , , and 230 . These datastores share a common datastore schema, and 231 protocol operations allow copying data between these datastores. 232 The term "conventional" is chosen as a generic umbrella term for 233 these datastores. 235 o conventional configuration: Configuration that is stored in any of 236 the conventional configuration datastores. 238 o dynamic configuration datastore: A configuration datastore holding 239 configuration obtained dynamically during the operation of a 240 device through interaction with other systems, rather than through 241 one of the conventional configuration datastores. 243 o dynamic configuration: Configuration obtained via a dynamic 244 configuration datastore. 246 o learned configuration: Configuration that has been learned via 247 protocol interactions with other systems and that is neither 248 conventional nor dynamic configuration. 250 o system configuration: Configuration that is supplied by the device 251 itself. 253 o default configuration: Configuration that is not explicitly 254 provided but for which a value defined in the data model is used. 256 o applied configuration: Configuration that is actively in use by a 257 device. Applied configuration originates from conventional, 258 dynamic, learned, system and default configuration. 260 o system state: The additional data on a system that is not 261 configuration, such as read-only status information and collected 262 statistics. System state is transient and modified by 263 interactions with internal components or other systems. System 264 state is modeled in YANG using "config false" nodes. 266 o operational state: The combination of applied configuration and 267 system state. 269 o operational state datastore: A datastore holding the complete 270 operational state of the device. This datastore is referred to as 271 "". 273 o origin: A metadata annotation indicating the origin of a data 274 item. 276 o remnant configuration: Configuration that remains part of the 277 applied configuration for a period of time after it has been 278 removed from the intended configuration or dynamic configuration. 279 The time period may be minimal, or may last until all resources 280 used by the newly-deleted configuration (e.g., network 281 connections, memory allocations, file handles) have been 282 deallocated. 284 The following additional terms are not datastore specific but 285 commonly used and thus defined here as well: 287 o client: An entity that can access YANG-defined data on a server, 288 over some network management protocol. 290 o server: An entity that provides access to YANG-defined data to a 291 client, over some network management protocol. 293 o notification: A server-initiated message indicating that a certain 294 event has been recognized by the server. 296 o remote procedure call: An operation that can be invoked by a 297 client on a server. 299 4. Background 301 NETCONF [RFC6241] provides the following definitions: 303 o datastore: A conceptual place to store and access information. A 304 datastore might be implemented, for example, using files, a 305 database, flash memory locations, or combinations thereof. 307 o configuration datastore: The datastore holding the complete set of 308 configuration that is required to get a device from its initial 309 default state into a desired operational state. 311 YANG 1.1 [RFC7950] provides the following refinements when NETCONF is 312 used with YANG (which is the usual case but note that NETCONF was 313 defined before YANG existed): 315 o datastore: When modeled with YANG, a datastore is realized as an 316 instantiated data tree. 318 o configuration datastore: When modeled with YANG, a configuration 319 datastore is realized as an instantiated data tree with 320 configuration. 322 [RFC6244] defined operational state data as follows: 324 o Operational state data is a set of data that has been obtained by 325 the system at runtime and influences the system's behavior similar 326 to configuration data. In contrast to configuration data, 327 operational state is transient and modified by interactions with 328 internal components or other systems via specialized protocols. 330 Section 4.3.3 of [RFC6244] discusses operational state and among 331 other things mentions the option to consider operational state as 332 being stored in another datastore. Section 4.4 of this document then 333 concludes that at the time of the writing, modeling state as distinct 334 leafs and distinct branches is the recommended approach. 336 Implementation experience and requests from operators 337 [I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate] 338 indicate that the datastore model initially designed for NETCONF and 339 refined by YANG needs to be extended. In particular, the notion of 340 intended configuration and applied configuration has developed. 342 4.1. Original Model of Datastores 344 The following drawing shows the original model of datastores as it is 345 currently used by NETCONF [RFC6241]: 347 +-------------+ +-----------+ 348 | | | | 349 | (ct, rw) |<---+ +--->| (ct, rw) | 350 +-------------+ | | +-----------+ 351 | | | | 352 | +-----------+ | 353 +-------->| |<--------+ 354 | (ct, rw) | 355 +-----------+ 356 | 357 v 358 operational state <--- control plane 359 (cf, ro) 361 ct = config true; cf = config false 362 rw = read-write; ro = read-only 363 boxes denote datastores 365 Note that this diagram simplifies the model: read-only (ro) and read- 366 write (rw) is to be understood at a conceptual level. In NETCONF, 367 for example, support for and is optional and 368 does not have to be writable. Furthermore, can 369 only be modified by copying to in the 370 standardized NETCONF datastore editing model. The RESTCONF protocol 371 does not expose these differences and instead provides only a 372 writable unified datastore, which hides whether edits are done 373 through or by directly modifying or via some 374 other implementation specific mechanism. RESTCONF also hides how 375 configuration is made persistent. Note that implementations may also 376 have additional datastores that can propagate changes to . 377 NETCONF explicitly mentions so called named datastores. 379 Some observations: 381 o Operational state has not been defined as a datastore although 382 there were proposals in the past to introduce an operational state 383 datastore. 385 o The NETCONF operation returns the contents of 386 together with the operational state. It is therefore necessary 387 that "config false" data is in a different branch than the "config 388 true" data if the operational state can have a different lifetime 389 compared to configuration or if configuration is not immediately 390 or successfully applied. 392 o Several implementations have proprietary mechanisms that allow 393 clients to store inactive data in . Inactive data is 394 conceptually removed before validation. 396 o Some implementations have proprietary mechanisms that allow 397 clients to define configuration templates in . These 398 templates are expanded automatically by the system, and the 399 resulting configuration is applied internally. 401 o Some operators have reported that it is essential for them to be 402 able to retrieve the configuration that has actually been 403 successfully applied, which may be a subset or a superset of the 404 configuration. 406 5. Architectural Model of Datastores 408 Below is a new conceptual model of datastores extending the original 409 model in order to reflect the experience gained with the original 410 model. 412 +-------------+ +-----------+ 413 | | | | 414 | (ct, rw) |<---+ +--->| (ct, rw) | 415 +-------------+ | | +-----------+ 416 | | | | 417 | +-----------+ | 418 +-------->| |<--------+ 419 | (ct, rw) | 420 +-----------+ 421 | 422 | // configuration transformations, 423 | // e.g., removal of "inactive" 424 | // nodes, expansion of templates 425 v 426 +------------+ 427 | | // subject to validation 428 | (ct, ro) | 429 +------------+ 430 | // changes applied, subject to 431 | // local factors, e.g., missing 432 | // resources, delays 433 | 434 dynamic | +-------- learned configuration 435 configuration | +-------- system configuration 436 datastores -----+ | +-------- default configuration 437 | | | 438 v v v 439 +---------------+ 440 | | <-- system state 441 | (ct + cf, ro) | 442 +---------------+ 444 ct = config true; cf = config false 445 rw = read-write; ro = read-only 446 boxes denote named datastores 448 5.1. Conventional Configuration Datastores 450 The conventional configuration datastores are a set of configuration 451 datastores that share exactly the same datastore schema, allowing 452 data to be copied between them. The term is meant as a generic 453 umbrella description of these datastores. The set of datastores 454 include: 456 o 458 o 459 o 461 o 463 Other conventional configuration datastores may be defined in future 464 documents. 466 The flow of data between these datastores is depicted in Section 5. 468 The specific protocols may define explicit operations to copy between 469 these datastores, e.g., NETCONF defines the operation. 471 5.1.1. The Startup Configuration Datastore () 473 The startup configuration datastore () is a configuration 474 datastore holding the configuration loaded by the device when it 475 boots. is only present on devices that separate the 476 startup configuration from the running configuration datastore. 478 The startup configuration datastore may not be supported by all 479 protocols or implementations. 481 On devices that support non-volatile storage, the contents of 482 will typically persist across reboots via that storage. At 483 boot time, the device loads the saved startup configuration into 484 . To save a new startup configuration, data is copied to 485 , either via implicit or explicit protocol operations. 487 5.1.2. The Candidate Configuration Datastore () 489 The candidate configuration datastore () is a 490 configuration datastore that can be manipulated without impacting the 491 device's current configuration and that can be committed to 492 . 494 The candidate configuration datastore may not be supported by all 495 protocols or implementations. 497 does not typically persist across reboots, even in the 498 presence of non-volatile storage. If is stored using 499 non-volatile storage, it is reset at boot time to the contents of 500 . 502 5.1.3. The Running Configuration Datastore () 504 The running configuration datastore () is a configuration 505 datastore that holds the complete current configuration on the 506 device. It MAY include configuration that requires further 507 transformation before it can be applied, e.g., inactive 508 configuration, or template-mechanism-oriented configuration that 509 needs further expansion. However, MUST always be a valid 510 configuration data tree, as defined in Section 8.1 of [RFC7950]. 512 MUST be supported if the device can be configured via 513 conventional configuration datastores. 515 If a device does not have a distinct and non-volatile 516 storage is available, the device will typically use that non-volatile 517 storage to allow to persist across reboots. 519 5.1.4. The Intended Configuration Datastore () 521 The intended configuration datastore () is a read-only 522 configuration datastore. It represents the configuration after all 523 configuration transformations to are performed (e.g., 524 template expansion, removal of inactive configuration), and is the 525 configuration that the system attempts to apply. 527 is tightly coupled to . Whenever data is written 528 to , then MUST also be immediately updated by 529 performing all necessary configuration transformations to the 530 contents of and then is validated. 532 MAY also be updated independently of if the 533 effect of a configuration transformation changes, but MUST 534 always be a valid configuration data tree, as defined in Section 8.1 535 of [RFC7950]. 537 For simple implementations, and are identical. 539 The contents of are also related to the "config true" 540 subset of , and hence a client can determine to what 541 extent the intended configuration is currently in use by checking 542 whether the contents of also appear in . 544 does not persist across reboots; its relationship with 545 makes that unnecessary. 547 Currently there are no standard mechanisms defined that affect 548 so that it would have different content than , 549 but this architecture allows for such mechanisms to be defined. 551 One example of such a mechanism is support for marking nodes as 552 inactive in . Inactive nodes are not copied to . 553 A second example is support for templates, which can perform 554 transformations on the configuration from to the 555 configuration written to . 557 5.2. Dynamic Configuration Datastores 559 The model recognizes the need for dynamic configuration datastores 560 that are, by definition, not part of the persistent configuration of 561 a device. In some contexts, these have been termed ephemeral 562 datastores since the information is ephemeral, i.e., lost upon 563 reboot. The dynamic configuration datastores interact with the rest 564 of the system through . 566 5.3. The Operational State Datastore () 568 The operational state datastore () is a read-only 569 datastore that consists of all "config true" and "config false" nodes 570 defined in the datastore's schema. In the original NETCONF model the 571 operational state only had "config false" nodes. The reason for 572 incorporating "config true" nodes here is to be able to expose all 573 operational settings without having to replicate definitions in the 574 data models. 576 contains system state and all configuration actually 577 used by the system. This includes all applied configuration from 578 , learned configuration, system-provided configuration, and 579 default values defined by any supported data models. In addition, 580 also contains applied configuration from dynamic 581 configuration datastores. 583 The datastore schema for MUST be a superset of the 584 combined datastore schema used in all configuration datastores except 585 that YANG nodes supported in a configuration datastore MAY be omitted 586 from if a server is not able to accurately report them. 588 Requests to retrieve nodes from always return the value 589 in use if the node exists, regardless of any default value specified 590 in the YANG module. If no value is returned for a given node, then 591 this implies that the node is not used by the device. 593 The interpretation of what constitutes as being "in use" by the 594 system is dependent on both the schema definition and the device 595 implementation. Generally, functionality that is enabled and 596 operational on the system would be considered as being "in use". 597 Conversely, functionality that is neither enabled nor operational on 598 the system is considered as not being "in use", and hence SHOULD be 599 omitted from . 601 SHOULD conform to any constraints specified in the data 602 model, but given the principal aim of returning "in use" values, it 603 is possible that constraints MAY be violated under some 604 circumstances, e.g., an abnormal value is "in use", the structure of 605 a list is being modified, or due to remnant configuration (see 606 Section 5.3.1). Note, that deviations SHOULD be used when it is 607 known in advance that a device does not fully conform to the 608 schema. 610 Only semantic constraints MAY be violated, these are the YANG "when", 611 "must", "mandatory", "unique", "min-elements", and "max-elements" 612 statements; and the uniqueness of key values. 614 Syntactic constraints MUST NOT be violated, including hierarchical 615 organization, identifiers, and type-based constraints. If a node in 616 does not meet the syntactic constraints then it MUST 617 NOT be returned, and some other mechanism should be used to flag the 618 error. 620 does not persist across reboots. 622 5.3.1. Remnant Configuration 624 Changes to configuration may take time to percolate through to 625 . During this period, may contain nodes 626 for both the previous and current configuration, as closely as 627 possible tracking the current operation of the device. Such remnant 628 configuration from the previous configuration persists until the 629 system has released resources used by the newly-deleted configuration 630 (e.g., network connections, memory allocations, file handles). 632 Remnant configuration is a common example of where the semantic 633 constraints defined in the data model cannot be relied upon for 634 , since the system may have remnant configuration whose 635 constraints were valid with the previous configuration and that are 636 not valid with the current configuration. Since constraints on 637 "config false" nodes may refer to "config true" nodes, remnant 638 configuration may force the violation of those constraints. 640 5.3.2. Missing Resources 642 Configuration in can refer to resources that are not 643 available or otherwise not physically present. In these situations, 644 these parts of are not applied. The data appears in 645 but does not appear in . 647 A typical example is an interface configuration that refers to an 648 interface that is not currently present. In such a situation, the 649 interface configuration remains in but the interface 650 configuration will not appear in . 652 Note that configuration validity cannot depend on the current state 653 of such resources, since that would imply that removing a resource 654 might render the configuration invalid. This is unacceptable, 655 especially given that rebooting such a device would cause it to 656 restart with an invalid configuration. Instead we allow 657 configuration for missing resources to exist in and 658 , but it will not appear in . 660 5.3.3. System-controlled Resources 662 Sometimes resources are controlled by the device and the 663 corresponding system controlled data appears in (and disappears from) 664 dynamically. If a system controlled resource has 665 matching configuration in when it appears, the system will 666 try to apply the configuration, which causes the configuration to 667 appear in eventually (if application of the 668 configuration was successful). 670 5.3.4. Origin Metadata Annotation 672 As configuration flows into , it is conceptually marked 673 with a metadata annotation ([RFC7952]) that indicates its origin. 674 The origin applies to all configuration nodes except non-presence 675 containers. The "origin" metadata annotation is defined in 676 Section 7. The values are YANG identities. The following identities 677 are defined: 679 o origin: abstract base identity from which the other origin 680 identities are derived. 682 o intended: represents configuration provided by . 684 o dynamic: represents configuration provided by a dynamic 685 configuration datastore. 687 o system: represents configuration provided by the system itself. 688 Examples of system configuration include applied configuration for 689 an always existing loopback interface, or interface configuration 690 that is auto-created due to the hardware currently present in the 691 device. 693 o learned: represents configuration that has been learned via 694 protocol interactions with other systems, including protocols such 695 as link-layer negotiations, routing protocols, DHCP, etc. 697 o default: represents configuration using a default value specified 698 in the data model, using either values in the "default" statement 699 or any values described in the "description" statement. The 700 default origin is only used when the configuration has not been 701 provided by any other source. 703 o unknown: represents configuration for which the system cannot 704 identify the origin. 706 These identities can be further refined, e.g., there could be 707 separate identities for particular types or instances of dynamic 708 configuration datastores derived from "dynamic". 710 For all configuration data nodes in , the device SHOULD 711 report the origin that most accurately reflects the source of the 712 configuration that is in use by the system. 714 In cases where it could be ambiguous as to which origin should be 715 used, i.e. where the same data node value has originated from 716 multiple sources, then the description statement in the YANG module 717 SHOULD be used as guidance for choosing the appropriate origin. For 718 example: 720 If for a particular configuration node, the associated YANG 721 description statement indicates that a protocol negotiated value 722 overrides any configured value, then the origin would be reported as 723 "learned", even when a learned value is the same as the configured 724 value. 726 Conversely, if for a particular configuration node, the associated 727 YANG description statement indicates that a protocol negotiated value 728 does not override an explicitly configured value, then the origin 729 would be reported as "intended" even when a learned value is the same 730 as the configured value. 732 In the case that a device cannot provide an accurate origin for a 733 particular configuration data node then it SHOULD use the origin 734 "unknown". 736 6. Implications on YANG 738 6.1. XPath Context 740 This section updates section 6.4.1 of RFC 7950. 742 If a server implements the architecture defined in this document, the 743 accessible trees for some XPath contexts are refined as follows: 745 o If the XPath expression is defined in a substatement to a data 746 node that represents system state, the accessible tree is all 747 operational state in the server. The root node has all top-level 748 data nodes in all modules as children. 750 o If the XPath expression is defined in a substatement to a 751 "notification" statement, the accessible tree is the notification 752 instance and all operational state in the server. If the 753 notification is defined on the top level in a module, then the 754 root node has the node representing the notification being defined 755 and all top-level data nodes in all modules as children. 756 Otherwise, the root node has all top-level data nodes in all 757 modules as children. 759 o If the XPath expression is defined in a substatement to an "input" 760 statement in an "rpc" or "action" statement, the accessible tree 761 is the RPC or action operation instance and all operational state 762 in the server. The root node has top-level data nodes in all 763 modules as children. Additionally, for an RPC, the root node also 764 has the node representing the RPC operation being defined as a 765 child. The node representing the operation being defined has the 766 operation's input parameters as children. 768 o If the XPath expression is defined in a substatement to an 769 "output" statement in an "rpc" or "action" statement, the 770 accessible tree is the RPC or action operation instance and all 771 operational state in the server. The root node has top-level data 772 nodes in all modules as children. Additionally, for an RPC, the 773 root node also has the node representing the RPC operation being 774 defined as a child. The node representing the operation being 775 defined has the operation's output parameters as children. 777 7. YANG Modules 779 file "ietf-datastores@2017-08-17.yang" 781 module ietf-datastores { 782 yang-version 1.1; 783 namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; 784 prefix ds; 786 organization 787 "IETF Network Modeling (NETMOD) Working Group"; 789 contact 790 "WG Web: 792 WG List: 793 Author: Martin Bjorklund 794 796 Author: Juergen Schoenwaelder 797 799 Author: Phil Shafer 800 802 Author: Kent Watsen 803 805 Author: Rob Wilton 806 "; 808 description 809 "This YANG module defines two sets of identities for datastores. 810 The first identifies the datastores themselves, the second 811 identifies datastore properties. 813 Copyright (c) 2017 IETF Trust and the persons identified as 814 authors of the code. All rights reserved. 816 Redistribution and use in source and binary forms, with or 817 without modification, is permitted pursuant to, and subject to 818 the license terms contained in, the Simplified BSD License set 819 forth in Section 4.c of the IETF Trust's Legal Provisions 820 Relating to IETF Documents 821 (http://trustee.ietf.org/license-info). 823 This version of this YANG module is part of RFC XXXX 824 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 825 for full legal notices."; 827 revision 2017-08-17 { 828 description 829 "Initial revision."; 830 reference 831 "RFC XXXX: Network Management Datastore Architecture"; 832 } 834 /* 835 * Identities 836 */ 838 identity datastore { 839 description 840 "Abstract base identity for datastore identities."; 842 } 844 identity conventional { 845 base datastore; 846 description 847 "Abstract base identity for conventional configuration 848 datastores."; 849 } 851 identity running { 852 base conventional; 853 description 854 "The running configuration datastore."; 855 } 857 identity candidate { 858 base conventional; 859 description 860 "The candidate configuration datastore."; 861 } 863 identity startup { 864 base conventional; 865 description 866 "The startup configuration datastore."; 867 } 869 identity intended { 870 base conventional; 871 description 872 "The intended configuration datastore."; 873 } 875 identity dynamic { 876 base datastore; 877 description 878 "Abstract base identity for dynamic configuration datastores."; 879 } 881 identity operational { 882 base datastore; 883 description 884 "The operational state datastore."; 885 } 887 /* 888 * Type definitions 889 */ 891 typedef datastore-ref { 892 type identityref { 893 base datastore; 894 } 895 description 896 "A datastore identity reference."; 897 } 899 } 901 903 file "ietf-origin@2017-08-17.yang" 905 module ietf-origin { 906 yang-version 1.1; 907 namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; 908 prefix or; 910 import ietf-yang-metadata { 911 prefix md; 912 } 914 organization 915 "IETF Network Modeling (NETMOD) Working Group"; 917 contact 918 "WG Web: 920 WG List: 922 Author: Martin Bjorklund 923 925 Author: Juergen Schoenwaelder 926 928 Author: Phil Shafer 929 931 Author: Kent Watsen 932 934 Author: Rob Wilton 935 "; 937 description 938 "This YANG module defines an 'origin' metadata annotation, and a 939 set of identities for the origin value. 941 Copyright (c) 2017 IETF Trust and the persons identified as 942 authors of the code. All rights reserved. 944 Redistribution and use in source and binary forms, with or 945 without modification, is permitted pursuant to, and subject to 946 the license terms contained in, the Simplified BSD License set 947 forth in Section 4.c of the IETF Trust's Legal Provisions 948 Relating to IETF Documents 949 (http://trustee.ietf.org/license-info). 951 This version of this YANG module is part of RFC XXXX 952 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 953 for full legal notices."; 955 revision 2017-08-17 { 956 description 957 "Initial revision."; 958 reference 959 "RFC XXXX: Network Management Datastore Architecture"; 960 } 962 /* 963 * Identities 964 */ 966 identity origin { 967 description 968 "Abstract base identity for the origin annotation."; 969 } 971 identity intended { 972 base origin; 973 description 974 "Denotes configuration from the intended configuration 975 datastore"; 976 } 978 identity dynamic { 979 base origin; 980 description 981 "Denotes configuration from a dynamic configuration 982 datastore."; 983 } 985 identity system { 986 base origin; 987 description 988 "Denotes configuration originated by the system itself. 990 Examples of system configuration include applied configuration 991 for an always existing loopback interface, or interface 992 configuration that is auto-created due to the hardware 993 currently present in the device."; 994 } 996 identity learned { 997 base origin; 998 description 999 "Denotes configuration learned from protocol interactions with 1000 other devices, instead of via either the intended 1001 configuration datastore or any dynamic configuration 1002 datastore. 1004 Examples of protocols that provide learned configuration 1005 include link-layer negotiations, routing protocols, and 1006 DHCP."; 1007 } 1009 identity default { 1010 base origin; 1011 description 1012 "Denotes configuration that does not have an configured or 1013 learned value, but has a default value in use. Covers both 1014 values defined in a 'default' statement, and values defined 1015 via an explanation in a 'description' statement."; 1016 } 1018 identity unknown { 1019 base origin; 1020 description 1021 "Denotes configuration for which the system cannot identify the 1022 origin."; 1023 } 1025 /* 1026 * Type definitions 1027 */ 1029 typedef origin-ref { 1030 type identityref { 1031 base origin; 1032 } 1033 description 1034 "An origin identity reference."; 1036 } 1038 /* 1039 * Metadata annotations 1040 */ 1042 md:annotation origin { 1043 type origin-ref; 1044 description 1045 "The 'origin' annotation can be present on any configuration 1046 data node in the operational datastore. It specifies from 1047 where the node originated. If not specified for a given 1048 configuration data node then the origin is the same as the 1049 origin of its parent node in the data tree. The origin for 1050 any top level configuration data nodes must be specified."; 1051 } 1052 } 1054 1056 8. IANA Considerations 1058 8.1. Updates to the IETF XML Registry 1060 This document registers two URIs in the IETF XML registry [RFC3688]. 1061 Following the format in [RFC3688], the following registrations are 1062 requested: 1064 URI: urn:ietf:params:xml:ns:yang:ietf-datastores 1065 Registrant Contact: The IESG. 1066 XML: N/A, the requested URI is an XML namespace. 1068 URI: urn:ietf:params:xml:ns:yang:ietf-origin 1069 Registrant Contact: The IESG. 1070 XML: N/A, the requested URI is an XML namespace. 1072 8.2. Updates to the YANG Module Names Registry 1074 This document registers two YANG modules in the YANG Module Names 1075 registry [RFC6020]. Following the format in [RFC6020], the the 1076 following registrations are requested: 1078 name: ietf-datastores 1079 namespace: urn:ietf:params:xml:ns:yang:ietf-datastores 1080 prefix: ds 1081 reference: RFC XXXX 1083 name: ietf-origin 1084 namespace: urn:ietf:params:xml:ns:yang:ietf-origin 1085 prefix: or 1086 reference: RFC XXXX 1088 9. Security Considerations 1090 This document discusses an architectural model of datastores for 1091 network management using NETCONF/RESTCONF and YANG. It has no 1092 security impact on the Internet. 1094 Although this document specifies several YANG modules, these modules 1095 only define identities and meta-data, hence the "YANG module security 1096 guidelines" do not apply. 1098 10. Acknowledgments 1100 This document grew out of many discussions that took place since 1101 2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational], 1102 [I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs], 1103 [I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and 1104 [RFC6244] touched on some of the problems of the original datastore 1105 model. The following people were authors to these Internet-Drafts or 1106 otherwise actively involved in the discussions that led to this 1107 document: 1109 o Lou Berger, LabN Consulting, L.L.C., 1111 o Andy Bierman, YumaWorks, 1113 o Marcus Hines, Google, 1115 o Christian Hopps, Deutsche Telekom, 1117 o Balazs Lengyel, Ericsson, 1119 o Acee Lindem, Cisco Systems, 1121 o Ladislav Lhotka, CZ.NIC, 1123 o Thomas Nadeau, Brocade Networks, 1125 o Tom Petch, Engineering Networks Ltd, 1126 o Anees Shaikh, Google, 1128 o Rob Shakir, Google, 1130 o Jason Sterne, Nokia, 1132 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 1133 Excellence project (ICT-318488) supported by the European Commission 1134 under its Seventh Framework Programme. 1136 11. References 1138 11.1. Normative References 1140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1141 Requirement Levels", BCP 14, RFC 2119, 1142 DOI 10.17487/RFC2119, March 1997, . 1145 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1146 and A. Bierman, Ed., "Network Configuration Protocol 1147 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1148 . 1150 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1151 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1152 . 1154 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1155 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1156 . 1158 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1159 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1160 . 1162 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1163 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1164 May 2017, . 1166 11.2. Informative References 1168 [I-D.bjorklund-netmod-operational] 1169 Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF 1170 and YANG", draft-bjorklund-netmod-operational-00 (work in 1171 progress), October 2012. 1173 [I-D.ietf-netmod-opstate-reqs] 1174 Watsen, K. and T. Nadeau, "Terminology and Requirements 1175 for Enhanced Handling of Operational State", draft-ietf- 1176 netmod-opstate-reqs-04 (work in progress), January 2016. 1178 [I-D.kwatsen-netmod-opstate] 1179 Watsen, K., Bierman, A., Bjorklund, M., and J. 1180 Schoenwaelder, "Operational State Enhancements for YANG, 1181 NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02 1182 (work in progress), February 2016. 1184 [I-D.openconfig-netmod-opstate] 1185 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 1186 of Operational State Data in YANG", draft-openconfig- 1187 netmod-opstate-01 (work in progress), July 2015. 1189 [I-D.wilton-netmod-opstate-yang] 1190 Wilton, R., ""With-config-state" Capability for NETCONF/ 1191 RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in 1192 progress), December 2015. 1194 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1195 DOI 10.17487/RFC3688, January 2004, . 1198 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1199 the Network Configuration Protocol (NETCONF)", RFC 6020, 1200 DOI 10.17487/RFC6020, October 2010, . 1203 [RFC6244] Shafer, P., "An Architecture for Network Management Using 1204 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 1205 2011, . 1207 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1208 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1209 . 1211 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1212 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1213 . 1215 Appendix A. Guidelines for Defining Datastores 1217 The definition of a new datastore in this architecture should be 1218 provided in a document (e.g., an RFC) purposed to the definition of 1219 the datastore. When it makes sense, more than one datastore may be 1220 defined in the same document (e.g., when the datastores are logically 1221 connected). Each datastore's definition should address the points 1222 specified in the sections below. 1224 A.1. Define which YANG modules can be used in the datastore 1226 Not all YANG modules may be used in all datastores. Some datastores 1227 may constrain which data models can be used in them. If it is 1228 desirable that a subset of all modules can be targeted to the 1229 datastore, then the documentation defining the datastore must 1230 indicate this. 1232 A.2. Define which subset of YANG-modeled data applies 1234 By default, the data in a datastore is modeled by all YANG statements 1235 in the available YANG modules. However, it is possible to specify 1236 criteria that YANG statements must satisfy in order to be present in 1237 a datastore. For instance, maybe only "config true" nodes, or 1238 "config false" nodes that also have a specific YANG extension, are 1239 present in the datastore. 1241 A.3. Define how data is actualized 1243 The new datastore must specify how it interacts with other 1244 datastores. 1246 For example, the diagram in Section 5 depicts dynamic configuration 1247 datastores feeding into . How this interaction occurs 1248 has to be defined by the particular dynamic configuration datastores. 1249 In some cases, it may occur implicitly, as soon as the data is put 1250 into the dynamic configuration datastore while, in other cases, an 1251 explicit action (e.g., an RPC) may be required to trigger the 1252 application of the datastore's data. 1254 A.4. Define which protocols can be used 1256 By default, it is assumed that both the NETCONF and RESTCONF 1257 protocols can be used to interact with a datastore. However, it may 1258 be that only a specific protocol can be used (e.g., ForCES) or that a 1259 subset of all protocol operations or capabilities are available 1260 (e.g., no locking or no XPath-based filtering). 1262 A.5. Define YANG identities for the datastore 1264 The datastore must be defined with a YANG identity that uses the 1265 "ds:datastore" identity, or one of its derived identities, as its 1266 base. This identity is necessary so that the datastore can be 1267 referenced in protocol operations (e.g., ). 1269 The datastore may also be defined with an identity that uses the 1270 "or:origin" identity or one its derived identities as its base. This 1271 identity is needed if the datastore interacts with so 1272 that data originating from the datastore can be identified as such 1273 via the "origin" metadata attribute defined in Section 7. 1275 An example of these guidelines in use is provided in Appendix B. 1277 Appendix B. Ephemeral Dynamic Configuration Datastore Example 1279 The section defines documentation for an example dynamic 1280 configuration datastore using the guidelines provided in Appendix A. 1281 While this example is very terse, it is expected to be that a 1282 standalone RFC would be needed when fully expanded. 1284 This example defines a dynamic configuration datastore called 1285 "ephemeral", which is loosely modeled after the work done in the I2RS 1286 working group. 1288 +--------------+---------------------------------------------------+ 1289 | Name | Value | 1290 +--------------+---------------------------------------------------+ 1291 | Name | ephemeral | 1292 | YANG modules | all (default) | 1293 | YANG nodes | all "config true" data nodes | 1294 | How applied | changes automatically propagated to | 1295 | Protocols | NC/RC (default) | 1296 | YANG Module | (see below) | 1297 +--------------+---------------------------------------------------+ 1299 The example "ephemeral" datastore properties 1301 module example-ds-ephemeral { 1302 yang-version 1.1; 1303 namespace "urn:example:ds-ephemeral"; 1304 prefix eph; 1306 import ietf-datastores { 1307 prefix ds; 1308 } 1309 import ietf-origin { 1310 prefix or; 1311 } 1313 // datastore identity 1314 identity ds-ephemeral { 1315 base ds:dynamic; 1316 description 1317 "The ephemeral dynamic configuration datastore."; 1318 } 1320 // origin identity 1321 identity or-ephemeral { 1322 base or:dynamic; 1323 description 1324 "Denotes data from the ephemeral dynamic configuration 1325 datastore."; 1326 } 1327 } 1329 Appendix C. Example Data 1331 The use of datastores is complex, and many of the subtle effects are 1332 more easily presented using examples. This section presents a series 1333 of example data models with some sample contents of the various 1334 datastores. 1336 C.1. System Example 1338 In this example, the following fictional module is used: 1340 module example-system { 1341 yang-version 1.1; 1342 namespace urn:example:system; 1343 prefix sys; 1345 import ietf-inet-types { 1346 prefix inet; 1347 } 1348 container system { 1349 leaf hostname { 1350 type string; 1351 } 1353 list interface { 1354 key name; 1356 leaf name { 1357 type string; 1358 } 1360 container auto-negotiation { 1361 leaf enabled { 1362 type boolean; 1363 default true; 1364 } 1365 leaf speed { 1366 type uint32; 1367 units mbps; 1368 description 1369 "The advertised speed, in mbps."; 1370 } 1371 } 1373 leaf speed { 1374 type uint32; 1375 units mbps; 1376 config false; 1377 description 1378 "The speed of the interface, in mbps."; 1379 } 1381 list address { 1382 key ip; 1384 leaf ip { 1385 type inet:ip-address; 1386 } 1387 leaf prefix-length { 1388 type uint8; 1389 } 1390 } 1391 } 1392 } 1393 } 1394 The operator has configured the host name and two interfaces, so the 1395 contents of are: 1397 1399 foo 1401 1402 eth0 1403 1404 1000 1405 1406
1407 2001:db8::10 1408 64 1409
1410 1412 1413 eth1 1414
1415 2001:db8::20 1416 64 1417
1418 1420 1422 The system has detected that the hardware for one of the configured 1423 interfaces ("eth1") is not yet present, so the configuration for that 1424 interface is not applied. Further, the system has received a host 1425 name and an additional IP address for "eth0" over DHCP. In addition 1426 to a default value, a loopback interface is automatically added by 1427 the system, and the result of the "speed" auto-negotiation. All of 1428 this is reflected in . Note how the origin metadata 1429 attribute for several "config true" data nodes is inherited from 1430 their parent data nodes. 1432 1436 bar 1438 1439 eth0 1440 1441 true 1442 1000 1443 1444 100 1445
1446 2001:db8::10 1447 64 1448
1449
1450 2001:db8::1:100 1451 64 1452
1453 1455 1456 lo0 1457
1458 ::1 1459 128 1460
1461 1463 1465 C.2. BGP Example 1467 Consider the following fragment of a fictional BGP module: 1469 container bgp { 1470 leaf local-as { 1471 type uint32; 1472 } 1473 leaf peer-as { 1474 type uint32; 1475 } 1476 list peer { 1477 key name; 1478 leaf name { 1479 type ipaddress; 1480 } 1481 leaf local-as { 1482 type uint32; 1483 description 1484 ".... Defaults to ../local-as"; 1485 } 1486 leaf peer-as { 1487 type uint32; 1488 description 1489 "... Defaults to ../peer-as"; 1490 } 1491 leaf local-port { 1492 type inet:port; 1493 } 1494 leaf remote-port { 1495 type inet:port; 1496 default 179; 1497 } 1498 leaf state { 1499 config false; 1500 type enumeration { 1501 enum init; 1502 enum established; 1503 enum closing; 1504 } 1505 } 1506 } 1507 } 1509 In this example model, both bgp/peer/local-as and bgp/peer/peer-as 1510 have complex hierarchical values, allowing the user to specify 1511 default values for all peers in a single location. 1513 The model also follows the pattern of fully integrating state 1514 ("config false") nodes with configuration ("config true") nodes. 1515 There is no separate "bgp-state" hierarchy, with the accompanying 1516 repetition of containment and naming nodes. This makes the model 1517 simpler and more readable. 1519 C.2.1. Datastores 1521 Each datastore represents differing views of these nodes. 1522 will hold the configuration provided by the operator, for example a 1523 single BGP peer. will conceptually hold the data as 1524 validated, after the removal of data not intended for validation and 1525 after any local template mechanisms are performed. 1526 will show data from as well as any "config false" nodes. 1528 C.2.2. Adding a Peer 1530 If the user configures a single BGP peer, then that peer will be 1531 visible in both and . It may also appear in 1532 , if the server supports the candidate configuration 1533 datastore. Retrieving the peer will return only the user-specified 1534 values. 1536 No time delay should exist between the appearance of the peer in 1537 and . 1539 In this scenario, we've added the following to : 1541 1542 64501 1543 64502 1544 1545 10.1.2.3 1546 1547 1549 C.2.2.1. 1551 The operational datastore will contain the fully expanded peer data, 1552 including "config false" nodes. In our example, this means the 1553 "state" node will appear. 1555 In addition, will contain the "currently in use" values 1556 for all nodes. This means that local-as and peer-as will be 1557 populated even if they are not given values in . The value 1558 of bgp/local-as will be used if bgp/peer/local-as is not provided; 1559 bgp/peer-as and bgp/peer/peer-as will have the same relationship. In 1560 the operational view, this means that every peer will have values for 1561 their local-as and peer-as, even if those values are not explicitly 1562 configured but are provided by bgp/local-as and bgp/peer-as. 1564 Each BGP peer has a TCP connection associated with it, using the 1565 values of local-port and remote-port from . If those 1566 values are not supplied, the system will select values. When the 1567 connection is established, will contain the current 1568 values for the local-port and remote-port nodes regardless of the 1569 origin. If the system has chosen the values, the "origin" attribute 1570 will be set to "system". Before the connection is established, one 1571 or both of the nodes may not appear, since the system may not yet 1572 have their values. 1574 1575 64501 1576 64502 1577 1578 10.1.2.3 1579 64501 1580 64502 1581 60794 1582 179 1583 established 1584 1585 1587 C.2.3. Removing a Peer 1589 Changes to configuration may take time to percolate through the 1590 various software components involved. During this period, it is 1591 imperative to continue to give an accurate view of the working of the 1592 device. will contain nodes for both the previous and 1593 current configuration, as closely as possible tracking the current 1594 operation of the device. 1596 Consider the scenario where a client removes a BGP peer. When a peer 1597 is removed, the operational state will continue to reflect the 1598 existence of that peer until the peer's resources are released, 1599 including closing the peer's connection. During this period, the 1600 current data values will continue to be visible in , 1601 with the "origin" attribute set to indicate the origin of the 1602 original data. 1604 1605 64501 1606 64502 1607 1608 10.1.2.3 1609 64501 1610 64502 1611 60794 1612 179 1613 closing 1614 1615 1617 Once resources are released and the connection is closed, the peer's 1618 data is removed from . 1620 C.3. Interface Example 1622 In this section, we will use this simple interface data model: 1624 container interfaces { 1625 list interface { 1626 key name; 1627 leaf name { 1628 type string; 1629 } 1630 leaf description { 1631 type string; 1632 } 1633 leaf mtu { 1634 type uint16; 1635 } 1636 leaf-list ip-address { 1637 type inet:ip-address; 1638 } 1639 } 1640 } 1642 C.3.1. Pre-provisioned Interfaces 1644 One common issue in networking devices is the support of Field 1645 Replaceable Units (FRUs) that can be inserted and removed from the 1646 device without requiring a reboot or interfering with normal 1647 operation. These FRUs are typically interface cards, and the devices 1648 support pre-provisioning of these interfaces. 1650 If a client creates an interface "et-0/0/0" but the interface does 1651 not physically exist at this point, then might contain the 1652 following: 1654 1655 1656 et-0/0/0 1657 Test interface 1658 1659 1661 Since the interface does not exist, this data does not appear in 1662 . 1664 When a FRU containing this interface is inserted, the system will 1665 detect it and process the associated configuration. 1666 will contain the data from , as well as nodes added by the 1667 system, such as the current value of the interface's MTU. 1669 1670 1671 et-0/0/0 1672 Test interface 1673 1500 1674 1675 1677 If the FRU is removed, the interface data is removed from 1678 . 1680 C.3.2. System-provided Interface 1682 Imagine if the system provides a loopback interface (named "lo0") 1683 with a default ip-address of "127.0.0.1" and a default ip-address of 1684 "::1". The system will only provide configuration for this interface 1685 if there is no data for it in . 1687 When no configuration for "lo0" appears in , then 1688 will show the system-provided data: 1690 1691 1692 lo0 1693 127.0.0.1 1694 ::1 1695 1696 1698 When configuration for "lo0" does appear in , then 1699 will show that data with the origin set to "intended". 1700 If the "ip-address" is not provided, then the system-provided value 1701 will appear as follows: 1703 1704 1705 lo0 1706 loopback 1707 127.0.0.1 1708 ::1 1709 1710 1712 Authors' Addresses 1714 Martin Bjorklund 1715 Tail-f Systems 1717 Email: mbj@tail-f.com 1719 Juergen Schoenwaelder 1720 Jacobs University 1722 Email: j.schoenwaelder@jacobs-university.de 1724 Phil Shafer 1725 Juniper Networks 1727 Email: phil@juniper.net 1729 Kent Watsen 1730 Juniper Networks 1732 Email: kwatsen@juniper.net 1734 Robert Wilton 1735 Cisco Systems 1737 Email: rwilton@cisco.com