--- 1/draft-ietf-netmod-revised-datastores-02.txt 2017-07-03 11:14:13.035878121 -0700 +++ 2/draft-ietf-netmod-revised-datastores-03.txt 2017-07-03 11:14:13.099879634 -0700 @@ -1,24 +1,24 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Intended status: Standards Track J. Schoenwaelder -Expires: November 12, 2017 Jacobs University +Expires: January 4, 2018 Jacobs University P. Shafer K. Watsen Juniper Networks R. Wilton Cisco Systems - May 11, 2017 + July 3, 2017 Network Management Datastore Architecture - draft-ietf-netmod-revised-datastores-02 + draft-ietf-netmod-revised-datastores-03 Abstract Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 12, 2017. + This Internet-Draft will expire on January 4, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,54 +58,54 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Original Model of Datastores . . . . . . . . . . . . . . 6 4. Architectural Model of Datastores . . . . . . . . . . . . . . 8 4.1. The Startup Configuration Datastore () . . . . . 9 4.2. The Candidate Configuration Datastore () . . . 10 4.3. The Running Configuration Datastore () . . . . . 10 4.4. The Intended Configuration Datastore () . . . . 10 - 4.5. Conventional Configuration Datastores . . . . . . . . . . 10 + 4.5. Conventional Configuration Datastores . . . . . . . . . . 11 4.6. Dynamic Datastores . . . . . . . . . . . . . . . . . . . 11 4.7. The Operational State Datastore () . . . . . 11 4.7.1. Missing Resources . . . . . . . . . . . . . . . . . . 12 - 4.7.2. System-controlled Resources . . . . . . . . . . . . . 12 - 4.7.3. Origin Metadata Annotation . . . . . . . . . . . . . 12 + 4.7.2. System-controlled Resources . . . . . . . . . . . . . 13 + 4.7.3. Origin Metadata Annotation . . . . . . . . . . . . . 13 5. Implications on YANG . . . . . . . . . . . . . . . . . . . . 14 5.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 14 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 7.1. Updates to the IETF XML Registry . . . . . . . . . . . . 20 - 7.2. Updates to the YANG Module Names Registry . . . . . . . . 20 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 10.2. Informative References . . . . . . . . . . . . . . . . . 22 - Appendix A. Guidelines for Defining Datastores . . . . . . . . . 23 - A.1. Define which YANG modules can be used in the datastore . 23 - A.2. Define which subset of YANG-modeled data applies . . . . 23 - A.3. Define how data is actualized . . . . . . . . . . . . . . 23 - A.4. Define which protocols can be used . . . . . . . . . . . 23 - A.5. Define YANG identities for the datastore . . . . . . . . 24 - Appendix B. Ephemeral Dynamic Datastore Example . . . . . . . . 24 - Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 25 - C.1. System Example . . . . . . . . . . . . . . . . . . . . . 26 - C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 28 - C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 30 - C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 30 - C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 31 - C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 32 - C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 32 - C.3.2. System-provided Interface . . . . . . . . . . . . . . 33 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 7.1. Updates to the IETF XML Registry . . . . . . . . . . . . 21 + 7.2. Updates to the YANG Module Names Registry . . . . . . . . 22 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 10.2. Informative References . . . . . . . . . . . . . . . . . 23 + Appendix A. Guidelines for Defining Datastores . . . . . . . . . 24 + A.1. Define which YANG modules can be used in the datastore . 24 + A.2. Define which subset of YANG-modeled data applies . . . . 25 + A.3. Define how data is actualized . . . . . . . . . . . . . . 25 + A.4. Define which protocols can be used . . . . . . . . . . . 25 + A.5. Define YANG identities for the datastore . . . . . . . . 25 + Appendix B. Ephemeral Dynamic Datastore Example . . . . . . . . 25 + Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 27 + C.1. System Example . . . . . . . . . . . . . . . . . . . . . 27 + C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 29 + C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 31 + C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 31 + C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 32 + C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 33 + C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 33 + C.3.2. System-provided Interface . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction This document provides an architectural framework for datastores as they are used by network management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling language. Datastores are a fundamental concept binding network management data models to network management protocols. Agreement on a common architectural model of datastores ensures that data models can be written in a network management protocol agnostic way. This @@ -116,23 +116,24 @@ 2. Terminology This document defines the following terms: o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. A datastore maps to an instantiated YANG data tree. - o configuration: Data that determines how a device behaves. This - data is modeled in YANG using "config true" nodes. Configuration - can originate from different sources. + o configuration: Data that is required to get a device from its + initial default state into a desired operational state. This data + is modeled in YANG using "config true" nodes. Configuration can + originate from different sources. o configuration datastore: A datastore holding configuration. o running configuration datastore: A configuration datastore holding the current configuration of the device. It may include inactive configuration or template-mechanism-oriented configuration that require further expansion. This datastore is commonly referred to as "". o candidate configuration datastore: A configuration datastore that @@ -390,47 +391,65 @@ The startup configuration datastore () is an optional configuration datastore holding the configuration loaded by the device when it boots. is only present on devices that separate the startup configuration from the running configuration datastore. The startup configuration datastore may not be supported by all protocols or implementations. + On devices that support non-volatile storage, the contents of + will typically persist across reboots via that storage. At + boot time, the device loads the saved startup configuration into + . To save a new startup configuration, data is copied to + , either via implicit or explicit protocol operations. + 4.2. The Candidate Configuration Datastore () The candidate configuration datastore () is an optional configuration datastore that can be manipulated without impacting the device's current configuration and that can be committed to . The candidate configuration datastore may not be supported by all protocols or implementations. + does not typically persist across reboots, even in the + presence of non-volatile storage. If is stored using + non-volatile storage, it should be reset at boot time to the contents + of . + 4.3. The Running Configuration Datastore () The running configuration datastore () holds the complete current configuration on the device. It may include inactive configuration or template-mechanism-oriented configuration that require further expansion. + If a device does not have a distinct and non-volatile is + available, the device will typically use that non-volatile storage to + allow to persist across reboots. + 4.4. The Intended Configuration Datastore () The intended configuration datastore () is a read-only configuration datastore. It is tightly coupled to . When data is written to , the data that is to be validated is also conceptually written to . Validation is performed on the contents of . For simple implementations, and are identical. + does not persist across reboots; its relationship with + makes that unnecessary. + Currently there are no standard mechanisms defined that affect so that it would have different contents than , but this architecture allows for such mechanisms to be defined. One example of such a mechanism is support for marking nodes as inactive in . Inactive nodes are not copied to , and are thus not taken into account when validating the configuration. Another example is support for templates. Templates are expanded @@ -476,20 +496,27 @@ state only had "config false" nodes. The reason for incorporating "config true" nodes here is to be able to expose all operational settings without having to replicate definitions in the data models. contains system state and all configuration actually used by the system. This includes all applied configuration from , system-provided configuration, and default values defined by any supported data models. In addition, also contains applied data from dynamic datastores. + Requests to retrieve nodes from always return the value + in use if the node exists, regardless of any default value specified + in the YANG module. If no value is returned for a given node, then + this implies that the node is not used by the device. + + does not persist across reboots. + Changes to configuration may take time to percolate through to . During this period, may contain nodes for both the previous and current configuration, as closely as possible tracking the current operation of the device. Such remnant configuration from the previous configuration persists until the system has released resources used by the newly-deleted configuration (e.g., network connections, memory allocations, file handles). As a result of remnant configuration, the semantic constraints defined in the data model cannot be relied upon for , @@ -660,23 +687,23 @@ Author: Phil Shafer Author: Kent Watsen Author: Rob Wilton "; description - "This YANG module defines a set of identities for datastores. - These identities can be used to identify datastores in protocol - operations. + "This YANG module defines two sets of identities for datastores. + The first identifies the datastores themselves, the second + identifies are for datastore protperties. Copyright (c) 2017 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). @@ -700,27 +727,20 @@ description "Abstract base identity for datastore identities."; } identity conventional { base datastore; description "Abstract base identity for conventional configuration datastores."; } - - identity dynamic { - base datastore; - description - "Abstract base identity for dynamic datastores."; - } - identity running { base conventional; description "The running configuration datastore."; } identity candidate { base conventional; description "The candidate configuration datastore."; @@ -723,35 +743,89 @@ identity candidate { base conventional; description "The candidate configuration datastore."; } identity startup { base conventional; description "The startup configuration datastore."; - } identity intended { base conventional; description "The intended configuration datastore."; } + identity dynamic { + base datastore; + description + "Abstract base identity for dynamic datastores."; + } + identity operational { base datastore; description "The operational state datastore."; } + identity property { + description + "Abstract base identity for datastore identities."; + } + + identity writable { + base property; + description + "Used on the 'running' datastore to indicate that it can be + written to."; + + } + + identity auto-persist { + base property; + description + "Used on the 'running' datastore to indicate that writes to + it will be automatically persisted. + + If the 'startup' datastore is also supported, clients may + query its contents to ensure its synchronization. + + If the 'startup' datastore is not supported, and this + property is not set, then clients must use a mechanism + provided by the protocol to explicitly persist the + 'running' datastore's contents."; + } + + identity rollback-on-error { + base property; + description + "Used on either the 'running' or 'candidate' datastores to + indicate that clients may request atomic update behavior."; + } + + identity confirmed-commit { + base property; + description + "Used on the 'candidate' datastore to indicate that + clients may request confirmed-commit update behavior."; + } + + identity validate { + base property; + description + "Used on the 'candidate' datastore to indicate that + clients may request datastore validation."; + } + } file "ietf-origin@2017-04-26.yang" module ietf-origin { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; prefix or; @@ -962,22 +1036,22 @@ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . - [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC - 7952, DOI 10.17487/RFC7952, August 2016, + [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", + RFC 7952, DOI 10.17487/RFC7952, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . 10.2. Informative References [I-D.bjorklund-netmod-operational] Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF @@ -1242,25 +1316,25 @@ eth0 true 1000 100
2001:db8::10 - 32 + 64
2001:db8::1:100 - 32 + 64
lo0
::1 128
@@ -1364,22 +1438,22 @@ the operational view, this means that every peer will have values for their local-as and peer-as, even if those values are not explicitly configured but are provided by bgp/local-as and bgp/peer-as. Each BGP peer has a TCP connection associated with it, using the values of local-port and remote-port from . If those values are not supplied, the system will select values. When the connection is established, will contain the current values for the local-port and remote-port nodes regardless of the origin. If the system has chosen the values, the "origin" attribute - will be set to "operational". Before the connection is established, - one or both of the nodes may not appear, since the system may not yet + will be set to "system". Before the connection is established, one + or both of the nodes may not appear, since the system may not yet have their values. 64642 65000 10.1.2.3 64642 65000 60794 @@ -1404,22 +1478,22 @@ with the "origin" attribute set to indicate the origin of the original data. 64642 65000 10.1.2.3 64642 65000 - 60794 - 179 + 60794 + 179 Once resources are released and the connection is closed, the peer's data is removed from . C.3. Interface Example In this section, we'll use this simple interface data model: @@ -1525,14 +1599,14 @@ Phil Shafer Juniper Networks Email: phil@juniper.net Kent Watsen Juniper Networks Email: kwatsen@juniper.net - Rob Wilton + Robert Wilton Cisco Systems Email: rwilton@cisco.com