idnits 2.17.1 draft-ietf-netmod-revised-datastores-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 18, 2017) is 2375 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: April 21, 2018 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 October 18, 2017 13 Network Management Datastore Architecture 14 draft-ietf-netmod-revised-datastores-05 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 April 21, 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 . . . . . . . . . . . . . . . . . . . 23 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 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 . 26 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 configuration: Data that is required to get a device from its 184 initial default state into a desired operational state. This data 185 is modeled in YANG using "config true" nodes. Configuration can 186 originate from different sources. 188 o configuration datastore: A datastore holding configuration. 190 o running configuration datastore: A configuration datastore holding 191 the current configuration of the device. It may include 192 configuration that requires further transformations before it can 193 be applied. This datastore is referred to as "". 195 o candidate configuration datastore: A configuration datastore that 196 can be manipulated without impacting the device's running 197 configuration datastore and that can be committed to the running 198 configuration datastore. This datastore is referred to as 199 "". 201 o startup configuration datastore: A configuration datastore holding 202 the configuration loaded by the device into the running 203 configuration datastore when it boots. This datastore is referred 204 to as "". 206 o intended configuration: Configuration that is intended to be used 207 by the device. It represents the configuration after all 208 configuration transformations to have been performed and 209 is the configuration that the system attempts to apply. 211 o intended configuration datastore: A configuration datastore 212 holding the complete intended configuration of the device. This 213 datastore is referred to as "". 215 o configuration transformation: The addition, modification or 216 removal of configuration between the and 217 datastores. Examples of configuration transformations include the 218 removal of inactive configuration and the configuration produced 219 through the expansion of templates. 221 o conventional configuration datastore: One of the following set of 222 configuration datastores: , , , and 223 . These datastores share a common schema, and protocol 224 operations allow copying data between these datastores. The term 225 "conventional" is chosen as a generic umbrella term for these 226 datastores. 228 o conventional configuration: Configuration that is stored in any of 229 the conventional configuration datastores. 231 o dynamic configuration datastore: A configuration datastore holding 232 configuration obtained dynamically during the operation of a 233 device through interaction with other systems, rather than through 234 one of the conventional configuration datastores. 236 o dynamic configuration: Configuration obtained via a dynamic 237 configuration datastore. 239 o learned configuration: Configuration that has been learned via 240 protocol interactions with other systems and that is neither 241 conventional nor dynamic configuration. 243 o system configuration: Configuration that is supplied by the device 244 itself. 246 o default configuration: Configuration that is not explicitly 247 provided but for which a value defined in the data model is used. 249 o applied configuration: Configuration that is actively in use by a 250 device. Applied configuration originates from conventional, 251 dynamic, learned, system and default configuration. 253 o system state: The additional data on a system that is not 254 configuration, such as read-only status information and collected 255 statistics. System state is transient and modified by 256 interactions with internal components or other systems. System 257 state is modeled in YANG using "config false" nodes. 259 o operational state: The combination of applied configuration and 260 system state. 262 o operational state datastore: A datastore holding the complete 263 operational state of the device. This datastore is referred to as 264 "". 266 o origin: A metadata annotation indicating the origin of a data 267 item. 269 o remnant configuration: Configuration that remains part of the 270 applied configuration for a period of time after it has been 271 removed from the intended configuration or dynamic configuration. 272 The time period may be minimal, or may last until all resources 273 used by the newly-deleted configuration (e.g., network 274 connections, memory allocations, file handles) have been 275 deallocated. 277 The following additional terms are not datastore specific but 278 commonly used and thus defined here as well: 280 o client: An entity that can access YANG-defined data on a server, 281 over some network management protocol. 283 o server: An entity that provides access to YANG-defined data to a 284 client, over some network management protocol. 286 o notification: A server-initiated message indicating that a certain 287 event has been recognized by the server. 289 o remote procedure call: An operation that can be invoked by a 290 client on a server. 292 4. Background 294 NETCONF [RFC6241] provides the following definitions: 296 o datastore: A conceptual place to store and access information. A 297 datastore might be implemented, for example, using files, a 298 database, flash memory locations, or combinations thereof. 300 o configuration datastore: The datastore holding the complete set of 301 configuration that is required to get a device from its initial 302 default state into a desired operational state. 304 YANG 1.1 [RFC7950] provides the following refinements when NETCONF is 305 used with YANG (which is the usual case but note that NETCONF was 306 defined before YANG existed): 308 o datastore: When modeled with YANG, a datastore is realized as an 309 instantiated data tree. 311 o configuration datastore: When modeled with YANG, a configuration 312 datastore is realized as an instantiated data tree with 313 configuration. 315 [RFC6244] defined operational state data as follows: 317 o Operational state data is a set of data that has been obtained by 318 the system at runtime and influences the system's behavior similar 319 to configuration data. In contrast to configuration data, 320 operational state is transient and modified by interactions with 321 internal components or other systems via specialized protocols. 323 Section 4.3.3 of [RFC6244] discusses operational state and among 324 other things mentions the option to consider operational state as 325 being stored in another datastore. Section 4.4 of this document then 326 concludes that at the time of the writing, modeling state as distinct 327 leafs and distinct branches is the recommended approach. 329 Implementation experience and requests from operators 330 [I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate] 331 indicate that the datastore model initially designed for NETCONF and 332 refined by YANG needs to be extended. In particular, the notion of 333 intended configuration and applied configuration has developed. 335 4.1. Original Model of Datastores 337 The following drawing shows the original model of datastores as it is 338 currently used by NETCONF [RFC6241]: 340 +-------------+ +-----------+ 341 | | | | 342 | (ct, rw) |<---+ +--->| (ct, rw) | 343 +-------------+ | | +-----------+ 344 | | | | 345 | +-----------+ | 346 +-------->| |<--------+ 347 | (ct, rw) | 348 +-----------+ 349 | 350 v 351 operational state <--- control plane 352 (cf, ro) 354 ct = config true; cf = config false 355 rw = read-write; ro = read-only 356 boxes denote datastores 358 Note that this diagram simplifies the model: read-only (ro) and read- 359 write (rw) is to be understood at a conceptual level. In NETCONF, 360 for example, support for and is optional and 361 does not have to be writable. Furthermore, can 362 only be modified by copying to in the 363 standardized NETCONF datastore editing model. The RESTCONF protocol 364 does not expose these differences and instead provides only a 365 writable unified datastore, which hides whether edits are done 366 through or by directly modifying or via some 367 other implementation specific mechanism. RESTCONF also hides how 368 configuration is made persistent. Note that implementations may also 369 have additional datastores that can propagate changes to . 370 NETCONF explicitly mentions so called named datastores. 372 Some observations: 374 o Operational state has not been defined as a datastore although 375 there were proposals in the past to introduce an operational state 376 datastore. 378 o The NETCONF operation returns the contents of 379 together with the operational state. It is therefore necessary 380 that "config false" data is in a different branch than the "config 381 true" data if the operational state can have a different lifetime 382 compared to configuration or if configuration is not immediately 383 or successfully applied. 385 o Several implementations have proprietary mechanisms that allow 386 clients to store inactive data in . Inactive data is 387 conceptually removed before validation. 389 o Some implementations have proprietary mechanisms that allow 390 clients to define configuration templates in . These 391 templates are expanded automatically by the system, and the 392 resulting configuration is applied internally. 394 o Some operators have reported that it is essential for them to be 395 able to retrieve the configuration that has actually been 396 successfully applied, which may be a subset or a superset of the 397 configuration. 399 5. Architectural Model of Datastores 401 Below is a new conceptual model of datastores extending the original 402 model in order to reflect the experience gained with the original 403 model. 405 +-------------+ +-----------+ 406 | | | | 407 | (ct, rw) |<---+ +--->| (ct, rw) | 408 +-------------+ | | +-----------+ 409 | | | | 410 | +-----------+ | 411 +-------->| |<--------+ 412 | (ct, rw) | 413 +-----------+ 414 | 415 | // configuration transformations, 416 | // e.g., removal of "inactive" 417 | // nodes, expansion of templates 418 v 419 +------------+ 420 | | // subject to validation 421 | (ct, ro) | 422 +------------+ 423 | // changes applied, subject to 424 | // local factors, e.g., missing 425 | // resources, delays 426 | 427 dynamic | +-------- learned configuration 428 configuration | +-------- system configuration 429 datastores -----+ | +-------- default configuration 430 | | | 431 v v v 432 +---------------+ 433 | | <-- system state 434 | (ct + cf, ro) | 435 +---------------+ 437 ct = config true; cf = config false 438 rw = read-write; ro = read-only 439 boxes denote named datastores 441 5.1. Conventional Configuration Datastores 443 The conventional configuration datastores are a set of configuration 444 datastores that share exactly the same schema, allowing data to be 445 copied between them. The term is meant as a generic umbrella 446 description of these datastores. The set of datastores include: 448 o 450 o 452 o 453 o 455 Other conventional configuration datastores may be defined in future 456 documents. 458 The flow of data between these datastores is depicted in Section 5. 460 The specific protocols may define explicit operations to copy between 461 these datastores, e.g., NETCONF defines the operation. 463 5.1.1. The Startup Configuration Datastore () 465 The startup configuration datastore () is a configuration 466 datastore holding the configuration loaded by the device when it 467 boots. is only present on devices that separate the 468 startup configuration from the running configuration datastore. 470 The startup configuration datastore may not be supported by all 471 protocols or implementations. 473 On devices that support non-volatile storage, the contents of 474 will typically persist across reboots via that storage. At 475 boot time, the device loads the saved startup configuration into 476 . To save a new startup configuration, data is copied to 477 , either via implicit or explicit protocol operations. 479 5.1.2. The Candidate Configuration Datastore () 481 The candidate configuration datastore () is a 482 configuration datastore that can be manipulated without impacting the 483 device's current configuration and that can be committed to 484 . 486 The candidate configuration datastore may not be supported by all 487 protocols or implementations. 489 does not typically persist across reboots, even in the 490 presence of non-volatile storage. If is stored using 491 non-volatile storage, it is reset at boot time to the contents of 492 . 494 5.1.3. The Running Configuration Datastore () 496 The running configuration datastore () is a configuration 497 datastore that holds the complete current configuration on the 498 device. It MAY include configuration that requires further 499 transformation before it can be applied, e.g., inactive 500 configuration, or template-mechanism-oriented configuration that 501 needs further expansion. However, MUST always be a valid 502 configuration data tree, as defined in Section 8.1 of [RFC7950]. 504 MUST be supported if the device can be configured via 505 conventional configuration datastores. 507 If a device does not have a distinct and non-volatile 508 storage is available, the device will typically use that non-volatile 509 storage to allow to persist across reboots. 511 5.1.4. The Intended Configuration Datastore () 513 The intended configuration datastore () is a read-only 514 configuration datastore. It represents the configuration after all 515 configuration transformations to are performed (e.g., 516 template expansion, removal of inactive configuration), and is the 517 configuration that the system attempts to apply. 519 is tightly coupled to . Whenever data is written 520 to , then MUST also be immediately updated by 521 performing all necessary configuration transformations to the 522 contents of and then is validated. 524 MAY also be updated independently of if the 525 effect of a configuration transformation changes, but MUST 526 always be a valid configuration data tree, as defined in Section 8.1 527 of [RFC7950]. 529 For simple implementations, and are identical. 531 The contents of are also related to the "config true" 532 subset of , and hence a client can determine to what 533 extent the intended configuration is currently in use by checking 534 whether the contents of also appear in . 536 does not persist across reboots; its relationship with 537 makes that unnecessary. 539 Currently there are no standard mechanisms defined that affect 540 so that it would have different content than , 541 but this architecture allows for such mechanisms to be defined. 543 One example of such a mechanism is support for marking nodes as 544 inactive in . Inactive nodes are not copied to . 545 A second example is support for templates, which can perform 546 transformations on the configuration from to the 547 configuration written to . 549 5.2. Dynamic Configuration Datastores 551 The model recognizes the need for dynamic configuration datastores 552 that are, by definition, not part of the persistent configuration of 553 a device. In some contexts, these have been termed ephemeral 554 datastores since the information is ephemeral, i.e., lost upon 555 reboot. The dynamic configuration datastores interact with the rest 556 of the system through . 558 5.3. The Operational State Datastore () 560 The operational state datastore () is a read-only 561 datastore that consists of all "config true" and "config false" nodes 562 defined in the schema. In the original NETCONF model the operational 563 state only had "config false" nodes. The reason for incorporating 564 "config true" nodes here is to be able to expose all operational 565 settings without having to replicate definitions in the data models. 567 contains system state and all configuration actually 568 used by the system. This includes all applied configuration from 569 , learned configuration, system-provided configuration, and 570 default values defined by any supported data models. In addition, 571 also contains applied configuration from dynamic 572 configuration datastores. 574 Requests to retrieve nodes from always return the value 575 in use if the node exists, regardless of any default value specified 576 in the YANG module. If no value is returned for a given node, then 577 this implies that the node is not used by the device. 579 The interpretation of what constitutes as being "in use" by the 580 system is dependent on both the schema definition and the device 581 implementation. Generally, functionality that is enabled and 582 operational on the system would be considered as being "in use". 583 Conversely, functionality that is neither enabled nor operational on 584 the system is considered as not being "in use", and hence SHOULD be 585 omitted from . 587 SHOULD conform to any constraints specified in the data 588 model, but given the principal aim of returning "in use" values, it 589 is possible that constraints MAY be violated under some 590 circumstances, e.g., an abnormal value is "in use", the structure of 591 a list is being modified, or due to remnant configuration (see 592 Section 5.3.1). Note, that deviations SHOULD be used when it is 593 known in advance that a device does not fully conform to the 594 schema. 596 Only semantic constraints MAY be violated, these are the YANG "when", 597 "must", "mandatory", "unique", "min-elements", and "max-elements" 598 statements; and the uniqueness of key values. 600 Syntactic constraints MUST NOT be violated, including hierarchical 601 organization, identifiers, and type-based constraints. If a node in 602 does not meet the syntactic constraints then it MUST 603 NOT be returned, and some other mechanism should be used to flag the 604 error. 606 does not persist across reboots. 608 5.3.1. Remnant Configuration 610 Changes to configuration may take time to percolate through to 611 . During this period, may contain nodes 612 for both the previous and current configuration, as closely as 613 possible tracking the current operation of the device. Such remnant 614 configuration from the previous configuration persists until the 615 system has released resources used by the newly-deleted configuration 616 (e.g., network connections, memory allocations, file handles). 618 Remnant configuration is a common example of where the semantic 619 constraints defined in the data model cannot be relied upon for 620 , since the system may have remnant configuration whose 621 constraints were valid with the previous configuration and that are 622 not valid with the current configuration. Since constraints on 623 "config false" nodes may refer to "config true" nodes, remnant 624 configuration may force the violation of those constraints. 626 5.3.2. Missing Resources 628 Configuration in can refer to resources that are not 629 available or otherwise not physically present. In these situations, 630 these parts of are not applied. The data appears in 631 but does not appear in . 633 A typical example is an interface configuration that refers to an 634 interface that is not currently present. In such a situation, the 635 interface configuration remains in but the interface 636 configuration will not appear in . 638 Note that configuration validity cannot depend on the current state 639 of such resources, since that would imply that removing a resource 640 might render the configuration invalid. This is unacceptable, 641 especially given that rebooting such a device would cause it to 642 restart with an invalid configuration. Instead we allow 643 configuration for missing resources to exist in and 644 , but it will not appear in . 646 5.3.3. System-controlled Resources 648 Sometimes resources are controlled by the device and the 649 corresponding system controlled data appears in (and disappears from) 650 dynamically. If a system controlled resource has 651 matching configuration in when it appears, the system will 652 try to apply the configuration, which causes the configuration to 653 appear in eventually (if application of the 654 configuration was successful). 656 5.3.4. Origin Metadata Annotation 658 As configuration flows into , it is conceptually marked 659 with a metadata annotation ([RFC7952]) that indicates its origin. 660 The origin applies to all configuration nodes except non-presence 661 containers. The "origin" metadata annotation is defined in 662 Section 7. The values are YANG identities. The following identities 663 are defined: 665 o origin: abstract base identity from which the other origin 666 identities are derived. 668 o intended: represents configuration provided by . 670 o dynamic: represents configuration provided by a dynamic 671 configuration datastore. 673 o system: represents configuration provided by the system itself. 674 Examples of system configuration include applied configuration for 675 an always existing loopback interface, or interface configuration 676 that is auto-created due to the hardware currently present in the 677 device. 679 o learned: represents configuration that has been learned via 680 protocol interactions with other systems, including protocols such 681 as link-layer negotiations, routing protocols, DHCP, etc. 683 o default: represents configuration using a default value specified 684 in the data model, using either values in the "default" statement 685 or any values described in the "description" statement. The 686 default origin is only used when the configuration has not been 687 provided by any other source. 689 o unknown: represents configuration for which the system cannot 690 identify the origin. 692 These identities can be further refined, e.g., there could be 693 separate identities for particular types or instances of dynamic 694 configuration datastores derived from "dynamic". 696 For all configuration data nodes in , the device SHOULD 697 report the origin that most accurately reflects the source of the 698 configuration that is in use by the system. 700 In cases where it could be ambiguous as to which origin should be 701 used, i.e. where the same data node value has originated from 702 multiple sources, then the description statement in the YANG module 703 SHOULD be used as guidance for choosing the appropriate origin. For 704 example: 706 If for a particular configuration node, the associated YANG 707 description statement indicates that a protocol negotiated value 708 overrides any configured value, then the origin would be reported as 709 "learned", even when a learned value is the same as the configured 710 value. 712 Conversely, if for a particular configuration node, the associated 713 YANG description statement indicates that a protocol negotiated value 714 does not override an explicitly configured value, then the origin 715 would be reported as "intended" even when a learned value is the same 716 as the configured value. 718 In the case that a device cannot provide an accurate origin for a 719 particular configuration data node then it SHOULD use the origin 720 "unknown". 722 6. Implications on YANG 724 6.1. XPath Context 726 This section updates section 6.4.1 of RFC 7950. 728 If a server implements the architecture defined in this document, the 729 accessible trees for some XPath contexts are refined as follows: 731 o If the XPath expression is defined in a substatement to a data 732 node that represents system state, the accessible tree is all 733 operational state in the server. The root node has all top-level 734 data nodes in all modules as children. 736 o If the XPath expression is defined in a substatement to a 737 "notification" statement, the accessible tree is the notification 738 instance and all operational state in the server. If the 739 notification is defined on the top level in a module, then the 740 root node has the node representing the notification being defined 741 and all top-level data nodes in all modules as children. 742 Otherwise, the root node has all top-level data nodes in all 743 modules as children. 745 o If the XPath expression is defined in a substatement to an "input" 746 statement in an "rpc" or "action" statement, the accessible tree 747 is the RPC or action operation instance and all operational state 748 in the server. The root node has top-level data nodes in all 749 modules as children. Additionally, for an RPC, the root node also 750 has the node representing the RPC operation being defined as a 751 child. The node representing the operation being defined has the 752 operation's input parameters as children. 754 o If the XPath expression is defined in a substatement to an 755 "output" statement in an "rpc" or "action" statement, the 756 accessible tree is the RPC or action operation instance and all 757 operational state in the server. The root node has top-level data 758 nodes in all modules as children. Additionally, for an RPC, the 759 root node also has the node representing the RPC operation being 760 defined as a child. The node representing the operation being 761 defined has the operation's output parameters as children. 763 7. YANG Modules 765 file "ietf-datastores@2017-08-17.yang" 767 module ietf-datastores { 768 yang-version 1.1; 769 namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; 770 prefix ds; 772 organization 773 "IETF Network Modeling (NETMOD) Working Group"; 775 contact 776 "WG Web: 778 WG List: 780 Author: Martin Bjorklund 781 783 Author: Juergen Schoenwaelder 784 786 Author: Phil Shafer 787 789 Author: Kent Watsen 790 792 Author: Rob Wilton 793 "; 795 description 796 "This YANG module defines two sets of identities for datastores. 797 The first identifies the datastores themselves, the second 798 identifies datastore properties. 800 Copyright (c) 2017 IETF Trust and the persons identified as 801 authors of the code. All rights reserved. 803 Redistribution and use in source and binary forms, with or 804 without modification, is permitted pursuant to, and subject to 805 the license terms contained in, the Simplified BSD License set 806 forth in Section 4.c of the IETF Trust's Legal Provisions 807 Relating to IETF Documents 808 (http://trustee.ietf.org/license-info). 810 This version of this YANG module is part of RFC XXXX 811 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 812 for full legal notices."; 814 revision 2017-08-17 { 815 description 816 "Initial revision."; 817 reference 818 "RFC XXXX: Network Management Datastore Architecture"; 819 } 821 /* 822 * Identities 823 */ 825 identity datastore { 826 description 827 "Abstract base identity for datastore identities."; 828 } 830 identity conventional { 831 base datastore; 832 description 833 "Abstract base identity for conventional configuration 834 datastores."; 835 } 836 identity running { 837 base conventional; 838 description 839 "The running configuration datastore."; 840 } 842 identity candidate { 843 base conventional; 844 description 845 "The candidate configuration datastore."; 846 } 848 identity startup { 849 base conventional; 850 description 851 "The startup configuration datastore."; 852 } 854 identity intended { 855 base conventional; 856 description 857 "The intended configuration datastore."; 858 } 860 identity dynamic { 861 base datastore; 862 description 863 "Abstract base identity for dynamic configuration datastores."; 864 } 866 identity operational { 867 base datastore; 868 description 869 "The operational state datastore."; 870 } 872 /* 873 * Type definitions 874 */ 876 typedef datastore-ref { 877 type identityref { 878 base datastore; 879 } 880 description 881 "A datastore identity reference."; 882 } 884 } 886 888 file "ietf-origin@2017-08-17.yang" 890 module ietf-origin { 891 yang-version 1.1; 892 namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; 893 prefix or; 895 import ietf-yang-metadata { 896 prefix md; 897 } 899 organization 900 "IETF Network Modeling (NETMOD) Working Group"; 902 contact 903 "WG Web: 905 WG List: 907 Author: Martin Bjorklund 908 910 Author: Juergen Schoenwaelder 911 913 Author: Phil Shafer 914 916 Author: Kent Watsen 917 919 Author: Rob Wilton 920 "; 922 description 923 "This YANG module defines an 'origin' metadata annotation, and a 924 set of identities for the origin value. 926 Copyright (c) 2017 IETF Trust and the persons identified as 927 authors of the code. All rights reserved. 929 Redistribution and use in source and binary forms, with or 930 without modification, is permitted pursuant to, and subject to 931 the license terms contained in, the Simplified BSD License set 932 forth in Section 4.c of the IETF Trust's Legal Provisions 933 Relating to IETF Documents 934 (http://trustee.ietf.org/license-info). 936 This version of this YANG module is part of RFC XXXX 937 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 938 for full legal notices."; 940 revision 2017-08-17 { 941 description 942 "Initial revision."; 943 reference 944 "RFC XXXX: Network Management Datastore Architecture"; 945 } 947 /* 948 * Identities 949 */ 951 identity origin { 952 description 953 "Abstract base identity for the origin annotation."; 954 } 956 identity intended { 957 base origin; 958 description 959 "Denotes configuration from the intended configuration 960 datastore"; 961 } 963 identity dynamic { 964 base origin; 965 description 966 "Denotes configuration from a dynamic configuration 967 datastore."; 968 } 970 identity system { 971 base origin; 972 description 973 "Denotes configuration originated by the system itself. 975 Examples of system configuration include applied configuration 976 for an always existing loopback interface, or interface 977 configuration that is auto-created due to the hardware 978 currently present in the device."; 979 } 980 identity learned { 981 base origin; 982 description 983 "Denotes configuration learned from protocol interactions with 984 other devices, instead of via either the intended 985 configuration datastore or any dynamic configuration 986 datastore. 988 Examples of protocols that provide learned configuration 989 include link-layer negotiations, routing protocols, and 990 DHCP."; 991 } 993 identity default { 994 base origin; 995 description 996 "Denotes configuration that does not have an configured or 997 learned value, but has a default value in use. Covers both 998 values defined in a 'default' statement, and values defined 999 via an explanation in a 'description' statement."; 1000 } 1002 identity unknown { 1003 base origin; 1004 description 1005 "Denotes configuration for which the system cannot identify the 1006 origin."; 1007 } 1009 /* 1010 * Type definitions 1011 */ 1013 typedef origin-ref { 1014 type identityref { 1015 base origin; 1016 } 1017 description 1018 "An origin identity reference."; 1019 } 1021 /* 1022 * Metadata annotations 1023 */ 1025 md:annotation origin { 1026 type origin-ref; 1027 description 1028 "The 'origin' annotation can be present on any configuration 1029 data node in the operational datastore. It specifies from 1030 where the node originated. If not specified for a given 1031 configuration data node then the origin is the same as the 1032 origin of its parent node in the data tree. The origin for 1033 any top level configuration data nodes must be specified."; 1034 } 1035 } 1037 1039 8. IANA Considerations 1041 8.1. Updates to the IETF XML Registry 1043 This document registers two URIs in the IETF XML registry [RFC3688]. 1044 Following the format in [RFC3688], the following registrations are 1045 requested: 1047 URI: urn:ietf:params:xml:ns:yang:ietf-datastores 1048 Registrant Contact: The IESG. 1049 XML: N/A, the requested URI is an XML namespace. 1051 URI: urn:ietf:params:xml:ns:yang:ietf-origin 1052 Registrant Contact: The IESG. 1053 XML: N/A, the requested URI is an XML namespace. 1055 8.2. Updates to the YANG Module Names Registry 1057 This document registers two YANG modules in the YANG Module Names 1058 registry [RFC6020]. Following the format in [RFC6020], the the 1059 following registrations are requested: 1061 name: ietf-datastores 1062 namespace: urn:ietf:params:xml:ns:yang:ietf-datastores 1063 prefix: ds 1064 reference: RFC XXXX 1066 name: ietf-origin 1067 namespace: urn:ietf:params:xml:ns:yang:ietf-origin 1068 prefix: or 1069 reference: RFC XXXX 1071 9. Security Considerations 1073 This document discusses an architectural model of datastores for 1074 network management using NETCONF/RESTCONF and YANG. It has no 1075 security impact on the Internet. 1077 Although this document specifies several YANG modules, these modules 1078 only define identities and meta-data, hence the "YANG module security 1079 guidelines" do not apply. 1081 10. Acknowledgments 1083 This document grew out of many discussions that took place since 1084 2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational], 1085 [I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs], 1086 [I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and 1087 [RFC6244] touched on some of the problems of the original datastore 1088 model. The following people were authors to these Internet-Drafts or 1089 otherwise actively involved in the discussions that led to this 1090 document: 1092 o Lou Berger, LabN Consulting, L.L.C., 1094 o Andy Bierman, YumaWorks, 1096 o Marcus Hines, Google, 1098 o Christian Hopps, Deutsche Telekom, 1100 o Balazs Lengyel, Ericsson, 1102 o Acee Lindem, Cisco Systems, 1104 o Ladislav Lhotka, CZ.NIC, 1106 o Thomas Nadeau, Brocade Networks, 1108 o Tom Petch, Engineering Networks Ltd, 1110 o Anees Shaikh, Google, 1112 o Rob Shakir, Google, 1114 o Jason Sterne, Nokia, 1116 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 1117 Excellence project (ICT-318488) supported by the European Commission 1118 under its Seventh Framework Programme. 1120 11. References 1121 11.1. Normative References 1123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1124 Requirement Levels", BCP 14, RFC 2119, 1125 DOI 10.17487/RFC2119, March 1997, . 1128 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1129 and A. Bierman, Ed., "Network Configuration Protocol 1130 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1131 . 1133 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1134 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1135 . 1137 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1138 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1139 . 1141 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1142 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1143 . 1145 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1146 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1147 May 2017, . 1149 11.2. Informative References 1151 [I-D.bjorklund-netmod-operational] 1152 Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF 1153 and YANG", draft-bjorklund-netmod-operational-00 (work in 1154 progress), October 2012. 1156 [I-D.ietf-netmod-opstate-reqs] 1157 Watsen, K. and T. Nadeau, "Terminology and Requirements 1158 for Enhanced Handling of Operational State", draft-ietf- 1159 netmod-opstate-reqs-04 (work in progress), January 2016. 1161 [I-D.kwatsen-netmod-opstate] 1162 Watsen, K., Bierman, A., Bjorklund, M., and J. 1163 Schoenwaelder, "Operational State Enhancements for YANG, 1164 NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02 1165 (work in progress), February 2016. 1167 [I-D.openconfig-netmod-opstate] 1168 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 1169 of Operational State Data in YANG", draft-openconfig- 1170 netmod-opstate-01 (work in progress), July 2015. 1172 [I-D.wilton-netmod-opstate-yang] 1173 Wilton, R., ""With-config-state" Capability for NETCONF/ 1174 RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in 1175 progress), December 2015. 1177 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1178 DOI 10.17487/RFC3688, January 2004, . 1181 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1182 the Network Configuration Protocol (NETCONF)", RFC 6020, 1183 DOI 10.17487/RFC6020, October 2010, . 1186 [RFC6244] Shafer, P., "An Architecture for Network Management Using 1187 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 1188 2011, . 1190 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1191 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1192 . 1194 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1195 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1196 . 1198 Appendix A. Guidelines for Defining Datastores 1200 The definition of a new datastore in this architecture should be 1201 provided in a document (e.g., an RFC) purposed to the definition of 1202 the datastore. When it makes sense, more than one datastore may be 1203 defined in the same document (e.g., when the datastores are logically 1204 connected). Each datastore's definition should address the points 1205 specified in the sections below. 1207 A.1. Define which YANG modules can be used in the datastore 1209 Not all YANG modules may be used in all datastores. Some datastores 1210 may constrain which data models can be used in them. If it is 1211 desirable that a subset of all modules can be targeted to the 1212 datastore, then the documentation defining the datastore must 1213 indicate this. 1215 A.2. Define which subset of YANG-modeled data applies 1217 By default, the data in a datastore is modeled by all YANG statements 1218 in the available YANG modules. However, it is possible to specify 1219 criteria that YANG statements must satisfy in order to be present in 1220 a datastore. For instance, maybe only "config true" nodes, or 1221 "config false" nodes that also have a specific YANG extension, are 1222 present in the datastore. 1224 A.3. Define how data is actualized 1226 The new datastore must specify how it interacts with other 1227 datastores. 1229 For example, the diagram in Section 5 depicts dynamic configuration 1230 datastores feeding into . How this interaction occurs 1231 has to be defined by the particular dynamic configuration datastores. 1232 In some cases, it may occur implicitly, as soon as the data is put 1233 into the dynamic configuration datastore while, in other cases, an 1234 explicit action (e.g., an RPC) may be required to trigger the 1235 application of the datastore's data. 1237 A.4. Define which protocols can be used 1239 By default, it is assumed that both the NETCONF and RESTCONF 1240 protocols can be used to interact with a datastore. However, it may 1241 be that only a specific protocol can be used (e.g., ForCES) or that a 1242 subset of all protocol operations or capabilities are available 1243 (e.g., no locking or no XPath-based filtering). 1245 A.5. Define YANG identities for the datastore 1247 The datastore must be defined with a YANG identity that uses the 1248 "ds:datastore" identity, or one of its derived identities, as its 1249 base. This identity is necessary so that the datastore can be 1250 referenced in protocol operations (e.g., ). 1252 The datastore may also be defined with an identity that uses the 1253 "or:origin" identity or one its derived identities as its base. This 1254 identity is needed if the datastore interacts with so 1255 that data originating from the datastore can be identified as such 1256 via the "origin" metadata attribute defined in Section 7. 1258 An example of these guidelines in use is provided in Appendix B. 1260 Appendix B. Ephemeral Dynamic Configuration Datastore Example 1262 The section defines documentation for an example dynamic 1263 configuration datastore using the guidelines provided in Appendix A. 1264 While this example is very terse, it is expected to be that a 1265 standalone RFC would be needed when fully expanded. 1267 This example defines a dynamic configuration datastore called 1268 "ephemeral", which is loosely modeled after the work done in the I2RS 1269 working group. 1271 +--------------+---------------------------------------------------+ 1272 | Name | Value | 1273 +--------------+---------------------------------------------------+ 1274 | Name | ephemeral | 1275 | YANG modules | all (default) | 1276 | YANG nodes | all "config true" data nodes | 1277 | How applied | changes automatically propagated to | 1278 | Protocols | NC/RC (default) | 1279 | YANG Module | (see below) | 1280 +--------------+---------------------------------------------------+ 1282 The example "ephemeral" datastore properties 1284 module example-ds-ephemeral { 1285 yang-version 1.1; 1286 namespace "urn:example:ds-ephemeral"; 1287 prefix eph; 1289 import ietf-datastores { 1290 prefix ds; 1291 } 1292 import ietf-origin { 1293 prefix or; 1294 } 1296 // datastore identity 1297 identity ds-ephemeral { 1298 base ds:dynamic; 1299 description 1300 "The ephemeral dynamic configuration datastore."; 1301 } 1303 // origin identity 1304 identity or-ephemeral { 1305 base or:dynamic; 1306 description 1307 "Denotes data from the ephemeral dynamic configuration 1308 datastore."; 1309 } 1310 } 1312 Appendix C. Example Data 1314 The use of datastores is complex, and many of the subtle effects are 1315 more easily presented using examples. This section presents a series 1316 of example data models with some sample contents of the various 1317 datastores. 1319 C.1. System Example 1321 In this example, the following fictional module is used: 1323 module example-system { 1324 yang-version 1.1; 1325 namespace urn:example:system; 1326 prefix sys; 1328 import ietf-inet-types { 1329 prefix inet; 1330 } 1331 container system { 1332 leaf hostname { 1333 type string; 1334 } 1336 list interface { 1337 key name; 1339 leaf name { 1340 type string; 1341 } 1343 container auto-negotiation { 1344 leaf enabled { 1345 type boolean; 1346 default true; 1347 } 1348 leaf speed { 1349 type uint32; 1350 units mbps; 1351 description 1352 "The advertised speed, in mbps."; 1353 } 1354 } 1356 leaf speed { 1357 type uint32; 1358 units mbps; 1359 config false; 1360 description 1361 "The speed of the interface, in mbps."; 1362 } 1364 list address { 1365 key ip; 1367 leaf ip { 1368 type inet:ip-address; 1369 } 1370 leaf prefix-length { 1371 type uint8; 1372 } 1373 } 1374 } 1375 } 1376 } 1377 The operator has configured the host name and two interfaces, so the 1378 contents of are: 1380 1382 foo 1384 1385 eth0 1386 1387 1000 1388 1389
1390 2001:db8::10 1391 64 1392
1393 1395 1396 eth1 1397
1398 2001:db8::20 1399 64 1400
1401 1403 1405 The system has detected that the hardware for one of the configured 1406 interfaces ("eth1") is not yet present, so the configuration for that 1407 interface is not applied. Further, the system has received a host 1408 name and an additional IP address for "eth0" over DHCP. In addition 1409 to a default value, a loopback interface is automatically added by 1410 the system, and the result of the "speed" auto-negotiation. All of 1411 this is reflected in . Note how the origin metadata 1412 attribute for several "config true" data nodes is inherited from 1413 their parent data nodes. 1415 1419 bar 1421 1422 eth0 1423 1424 true 1425 1000 1426 1427 100 1428
1429 2001:db8::10 1430 64 1431
1432
1433 2001:db8::1:100 1434 64 1435
1436 1438 1439 lo0 1440
1441 ::1 1442 128 1443
1444 1446 1448 C.2. BGP Example 1450 Consider the following fragment of a fictional BGP module: 1452 container bgp { 1453 leaf local-as { 1454 type uint32; 1455 } 1456 leaf peer-as { 1457 type uint32; 1458 } 1459 list peer { 1460 key name; 1461 leaf name { 1462 type ipaddress; 1463 } 1464 leaf local-as { 1465 type uint32; 1466 description 1467 ".... Defaults to ../local-as"; 1468 } 1469 leaf peer-as { 1470 type uint32; 1471 description 1472 "... Defaults to ../peer-as"; 1473 } 1474 leaf local-port { 1475 type inet:port; 1476 } 1477 leaf remote-port { 1478 type inet:port; 1479 default 179; 1480 } 1481 leaf state { 1482 config false; 1483 type enumeration { 1484 enum init; 1485 enum established; 1486 enum closing; 1487 } 1488 } 1489 } 1490 } 1492 In this example model, both bgp/peer/local-as and bgp/peer/peer-as 1493 have complex hierarchical values, allowing the user to specify 1494 default values for all peers in a single location. 1496 The model also follows the pattern of fully integrating state 1497 ("config false") nodes with configuration ("config true") nodes. 1498 There is no separate "bgp-state" hierarchy, with the accompanying 1499 repetition of containment and naming nodes. This makes the model 1500 simpler and more readable. 1502 C.2.1. Datastores 1504 Each datastore represents differing views of these nodes. 1505 will hold the configuration provided by the operator, for example a 1506 single BGP peer. will conceptually hold the data as 1507 validated, after the removal of data not intended for validation and 1508 after any local template mechanisms are performed. 1509 will show data from as well as any "config false" nodes. 1511 C.2.2. Adding a Peer 1513 If the user configures a single BGP peer, then that peer will be 1514 visible in both and . It may also appear in 1515 , if the server supports the candidate configuration 1516 datastore. Retrieving the peer will return only the user-specified 1517 values. 1519 No time delay should exist between the appearance of the peer in 1520 and . 1522 In this scenario, we've added the following to : 1524 1525 64501 1526 64502 1527 1528 10.1.2.3 1529 1530 1532 C.2.2.1. 1534 The operational datastore will contain the fully expanded peer data, 1535 including "config false" nodes. In our example, this means the 1536 "state" node will appear. 1538 In addition, will contain the "currently in use" values 1539 for all nodes. This means that local-as and peer-as will be 1540 populated even if they are not given values in . The value 1541 of bgp/local-as will be used if bgp/peer/local-as is not provided; 1542 bgp/peer-as and bgp/peer/peer-as will have the same relationship. In 1543 the operational view, this means that every peer will have values for 1544 their local-as and peer-as, even if those values are not explicitly 1545 configured but are provided by bgp/local-as and bgp/peer-as. 1547 Each BGP peer has a TCP connection associated with it, using the 1548 values of local-port and remote-port from . If those 1549 values are not supplied, the system will select values. When the 1550 connection is established, will contain the current 1551 values for the local-port and remote-port nodes regardless of the 1552 origin. If the system has chosen the values, the "origin" attribute 1553 will be set to "system". Before the connection is established, one 1554 or both of the nodes may not appear, since the system may not yet 1555 have their values. 1557 1558 64501 1559 64502 1560 1561 10.1.2.3 1562 64501 1563 64502 1564 60794 1565 179 1566 established 1567 1568 1570 C.2.3. Removing a Peer 1572 Changes to configuration may take time to percolate through the 1573 various software components involved. During this period, it is 1574 imperative to continue to give an accurate view of the working of the 1575 device. will contain nodes for both the previous and 1576 current configuration, as closely as possible tracking the current 1577 operation of the device. 1579 Consider the scenario where a client removes a BGP peer. When a peer 1580 is removed, the operational state will continue to reflect the 1581 existence of that peer until the peer's resources are released, 1582 including closing the peer's connection. During this period, the 1583 current data values will continue to be visible in , 1584 with the "origin" attribute set to indicate the origin of the 1585 original data. 1587 1588 64501 1589 64502 1590 1591 10.1.2.3 1592 64501 1593 64502 1594 60794 1595 179 1596 closing 1597 1598 1600 Once resources are released and the connection is closed, the peer's 1601 data is removed from . 1603 C.3. Interface Example 1605 In this section, we will use this simple interface data model: 1607 container interfaces { 1608 list interface { 1609 key name; 1610 leaf name { 1611 type string; 1612 } 1613 leaf description { 1614 type string; 1615 } 1616 leaf mtu { 1617 type uint16; 1618 } 1619 leaf-list ip-address { 1620 type inet:ip-address; 1621 } 1622 } 1623 } 1625 C.3.1. Pre-provisioned Interfaces 1627 One common issue in networking devices is the support of Field 1628 Replaceable Units (FRUs) that can be inserted and removed from the 1629 device without requiring a reboot or interfering with normal 1630 operation. These FRUs are typically interface cards, and the devices 1631 support pre-provisioning of these interfaces. 1633 If a client creates an interface "et-0/0/0" but the interface does 1634 not physically exist at this point, then might contain the 1635 following: 1637 1638 1639 et-0/0/0 1640 Test interface 1641 1642 1644 Since the interface does not exist, this data does not appear in 1645 . 1647 When a FRU containing this interface is inserted, the system will 1648 detect it and process the associated configuration. 1649 will contain the data from , as well as nodes added by the 1650 system, such as the current value of the interface's MTU. 1652 1653 1654 et-0/0/0 1655 Test interface 1656 1500 1657 1658 1660 If the FRU is removed, the interface data is removed from 1661 . 1663 C.3.2. System-provided Interface 1665 Imagine if the system provides a loopback interface (named "lo0") 1666 with a default ip-address of "127.0.0.1" and a default ip-address of 1667 "::1". The system will only provide configuration for this interface 1668 if there is no data for it in . 1670 When no configuration for "lo0" appears in , then 1671 will show the system-provided data: 1673 1674 1675 lo0 1676 127.0.0.1 1677 ::1 1678 1679 1681 When configuration for "lo0" does appear in , then 1682 will show that data with the origin set to "intended". 1683 If the "ip-address" is not provided, then the system-provided value 1684 will appear as follows: 1686 1687 1688 lo0 1689 loopback 1690 127.0.0.1 1691 ::1 1692 1693 1695 Authors' Addresses 1697 Martin Bjorklund 1698 Tail-f Systems 1700 Email: mbj@tail-f.com 1702 Juergen Schoenwaelder 1703 Jacobs University 1705 Email: j.schoenwaelder@jacobs-university.de 1707 Phil Shafer 1708 Juniper Networks 1710 Email: phil@juniper.net 1712 Kent Watsen 1713 Juniper Networks 1715 Email: kwatsen@juniper.net 1717 Robert Wilton 1718 Cisco Systems 1720 Email: rwilton@cisco.com