| Internet Engineering Task Force | R. Wilton, Ed. |
| Internet-Draft | Cisco Systems |
| Intended status: Standards Track | June 3, 2016 |
| Expires: December 5, 2016 |
Refined YANG datastores
draft-wilton-netmod-refined-datastores-00
The existing definition of YANG datastores supported by NETCONF only provides a loose definition of the running datastore, and no formal definition of any datastore that represents the operational state of a device. This document defines a refined datastore model with new concrete and abstract datastores to allow devices to provide a clean separation between the operator's intended configuration of a device and the actual running operational state of a device. It provides a similiar, but alternative, datastore framework to the one described in draft-schoenw-netmod-revised-datastores.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 December 5, 2016.
Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document defines a similar, but alternative architectural datastore framework to draft-schoenw-netmod-revised-datastores [I-D.schoenw-netmod-revised-datastores]. This purpose of this document is to make it easier to compare the models and approaches being described in the two different drafts. The reader is advised to also read draft-schoenw-netmod-revised-datastores [I-D.schoenw-netmod-revised-datastores] which provides a good background on why a refined NETCONF/YANG datastore model is needed.
The key aims of this definition of datastores are:
This draft does not formally address the active/inactive configuration functionality described in draft-schoenw-netmod-revised-datastores [I-D.schoenw-netmod-revised-datastores]. If supporting this functionality is required, then it is envisaged that this would be a separate optional datastore that exists between the persistent configuration datastore and the ephemeral configuration datastore.
The following terms are defined:
The following diagram illustrates how the datastores (except running) defined in this document relate to each other:
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +---------------+ |
+-------->| <persistent> |<-----+
| (ct, rw) | // subject to validation
+---------------+
|
v
+---------------+
| <ephemeral> |
| (ct, rw) |
+---------------+
|
v
+---------------+
| <intended> | // subject to validation
| (ct, ro) |
+---------------+
|
v
+---------------------+
| +---------------+ |
| | <applied cfg> | <--- actual cfg in effect
| | (ct, ro) | |
| +---------------+ |
| | |
| v |
Operational | +---------------+ |
State ==> | | <system cfg> | <--- System created config
Datastore | | (ct, ro) | |
| +---------------+ |
| | |
| v |
| +-----------------+ |
| | <system state> | <--- Config false nodes
| | (cf, ro) | |
| +-----------------+ |
+---------------------+
This document defines seven additional datastores beyond the three (candidate, startup, running) that are defined in existing RFCs! Many of these newly defined datastores are regarded as being entirely abstract datastores, and even opstate aware devices are not required to explicitly handle get requests (or YANG push notifications) on these named abstract datastores. One of the main reasons for defining these abstract datastores is to give a precise definition of the meaning of the configuration and operational data on a device, and potentially allow management agents to make queries between the different datastores (e.g. to determine if any intended configuration hasn't actually been applied, or perhaps conversely which parts of the applied configuration do not match the intended configuration).
The ten datastores can be summarized as thus:
Only the system state datastore holds config=false nodes. All other datastores defined above only hold config=true YANG schema nodes, and are represented by the same YANG schema files.
Holds candidate configuration. The definition is unchanged from existing RFCs.
Holds the saved configuration that is used by the device after reboot. The definition is unchanged from existing RFCs.
This document does not try to redefine the running configuration datastore, it aims to retain its existing (loose) definition. Some implementations regard the running configuration as solely the configuration provided by the operator to the device. Other implementations regard it as something akin to the applied configuration datastore, where, on a system without ephemeral configuration, after a configuration commit has completed, the running configuration matches the configuration provided by the operator.
In the refined datastore model described in this draft, the running configuration datastore can be considered as being logically split into the persistent, ephemeral, intended, and applied configuration datastores as illustrated in the diagram below.
---- Persistent configuration ds
/
----- Ephemeral configuration ds
Running configuration ds |
----- Intended configuration ds
\
---- Applied configuration ds
On a non-opstate aware device, the running configuration datastore is supported exactly as it is today by the existing NETCONF/YANG RFCs
For an opstate aware device, the running configuration datastore is supported as an abstract datastore.
It maintain backwards compatibility, config writes to the running configuration datastore are treated as writes to the persistent configuration datastore. Config reads (e.g. get-config) from the running configuration datastore are treated as reads from the applied configuration datastore. NETCONF get requests (or equivalent) are treated as a read on the operational state datastore.
The Persistent Configuration Datastore represents the configuration provided by the operator, that is expected to be persisted over device reboot. Writes to the persistent configuration are validated to ensure that the configuration is well formed and valid, and if so, is persisted over device reboot. The persistent configuration datastore interacts with both the candidate and startup datastores (as per the running configuration datastore on a non opstate aware device).
This datastore is only written by the operator.
The default behavior for get requests (or YANG push notifications) on this datastore is to return the configuration exactly as provided by the operator (i.e. including any explicitly configured default values and excluding any implicit YANG default values).
This document does not intend to formally define an Ephemeral Configuration Datastore. In particular, it must be noted that the ephemeral configuration datastore described here does not match that described in version -09 of draft-ietf-i2rs-ephemeral-state [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually how such a datastore (restricted to configuration only) might fit into a conceptual refined datastore model.
An Ephemeral Configuration Datastore may optionally be supported to hold any configuration that must not persist over device reboot. This datastore could be regarded as a pane of glass overlay on the persistent configuration datastore, allowing nodes in the ephemeral configuration to override, or depend on, nodes in the persistent configuration if required.
This datastore is only written by the operator.
The default behavior for get requests (or YANG push notifications) on the ephemeral configuration datastore is to return the configuration exactly as written by the operator to the ephemeral datastore (i.e. including any explicitly configured default values and excluding any implicit default values).
Multiple layers of ephemeral configuration in the ephemeral datastore could be supported.
The Intended Configuration datastore abstractly represents the net combination of the persistent configuration datastore overlaid with the optional ephemeral configuration datastore. It represents the entire combined configuration that the operator intends for the device.
This datastore is read only. It is optional as to whether the device allows the intended configuration to be directly read (or notified) as a labelled, user visible, datastore; or possibly the contents of the intended configuration datastore may only be made available as YANG meta-data annotations on one of the other datastores.
If get requests (or YANG push notifications) are supported on the intended configuration datastore then the handling of default values would be consistent with both the persistent and ephemeral configuration datastores (as described previously), i.e. the explicit operator configuration is returned.
The Operational State datastore represents all of the operational state of the device. This includes the applied configuration, any system controlled configuration, and all of the system state (i.e. config=false nodes).
Logically, the operational state datastore can be considered as being split into the applied configuration, system controlled configuration, and system state datastores as illustrated in the following diagram:
---- Applied configuration ds
/
Operational state ds |----- System controlled configuration ds
\
---- System state ds
This datastore is read only. Performing a read of the operational state datastore returns the applied configuration overlaid with system controlled configuration and system state datastores.
The default behavior for get requests (or YANG push notifications) on the operational state datastore is to explicitly return all values in effect in the system (including any values that are implicitly set by a YANG schema default).
A default NETCONF GET request can be regarded as a GET request against the operational state datastore. It should also be noted that with the exception of system controlled configuration, that if the system has converged and the configuration has been applied then a GET request for an opstate aware device and a non opstate aware device return exactly the same data. This provides backwards compatibility and an upgrade path from existing NETCONF servers.
The Applied Configuration datastore is the abstract subset of the operational state datastore that represents the actual configuration that has been applied and is in effect on the device.
For a well behaved device, after a config write operation has completed successfully the notional contents of the applied configuration datastore matches the intended configuration datastore.
Being an abstract datastore that is part of the operational state datastore it is read-only.
The contents of this datastore must be made available as part of the applied configuration datastore. It is optional as to whether the device allows the applied configuration datastore to be directly read (or notified via YANG Push) as a labelled, user visible, datastore; or possibly the contents of the applied configuration datastore may only be made available as YANG meta-data annotations on one of the other datastores (e.g. persistent, intended, or operational-state datastore).
If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicitly set by a YANG schema default).
The System Controlled Configuration Datastore is the abstract subset of the operational state datastore that represents all configuration nodes that are created by the system independently of the intended configuration. E.g. system created interfaces that hadn't been configured by the operator would logically exist in the system controlled configuration datastore whether or not they also exists in the applied configuration datastore.
This datastore uses the same YANG schema of config=true as for the intended or applied configuration datastores. Logically, nodes may exist in both the applied configuration and system controlled configuration datastores (e.g. if a system created interface had been configured).
Being an abstract datastore that is part of the operational state datastore it is read-only.
The contents of this datastore must be made available as part of the applied configuration datastore. It is optional as to whether the device allows the applied configuration datastore to be directly read (or notified via YANG Push) as a labelled, user visible, datastore; or possibly the contents of the applied configuration datastore may only be made available as YANG meta-data annotations on the operational-state datastore.
If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicit due to a YANG schema default).
The System State Abstract Datastore is the abstract subset of the operational state datastore that represents all of the operational state derived from configuration or other system defined values, and is represented by config=false nodes in the YANG schema.
Entries in this datastore can rely on the existence of entries in the applied configuration and system controlled configuration datastores, thus allowing disjoint config vs state lists to be merged together into a single list.
Being an abstract datastore that is part of the operational state datastore it is read-only.
The contents of this datastore must be made available as part of the operational state datastore. It is optional as to whether the device also allows this datastore to be directly read (or notified) as a labelled, operator visible, datastore.
If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicit due to a YANG schema default).
Configuration that cannot be applied because the system resources are missing (or have been exhausted) would logically exist in the intended configuration datastore but not the applied configuration datastore.
System controlled resources (i.e. those resources that would exist in the system regardless of configuration) always exist in the system controlled configuration datastore. They may also exist in the applied configuration datastore if they have also been configured (and the configuration successfully applied to the device).
The applied configuration datastore only represents the configuration that is applied. Generally, separate config false leaves in the system state datastore are used to represent the operational state of the device.
In the specific case that the operational value is (i) directly controlled by configuration, (ii) has exactly the same schema value space as the corresponding configuration leaf, and (iii) if configured, the operational value of the system must be the same as the applied configuration then no separate config false leaf is needed. This optimization is valid because the system state datastore leaf value would always have exactly the same lifetime and value as the corresponding configuration leaf in the applied configuration datastore.
The definition of the operational state datastore is designed to allow config false leaves to depend on either explicitly configured entities (in the applied configuration datastore) or system created entries (in the system controlled configuration) datastore. This definition facilitates the merging of separate configuration and state parts of YANG models into the same container/lists if desired.
An example are IP addresses of an interface that can originate from configuration, from DHCP, or may be dynamically auto-configured. In this case, the operational state datastore would contain all IP addresses. The explicitly configured addresses would logically exist in the applied configuration datastore. Addresses learned through DHCP or dynamically configured would logically exist in the system controlled configuration datastore. Enhanced get/notification requests with YANG metadata annotations could be used to amend the reply/notification with metadata information to indicate which datastore the entries logically exist in.
This sections describes the implications for all opstate unaware clients, which includes all existing standards compliant NETCONF/RESTCONF clients.
One of the key aims of the refined datastore model described in this draft is to minimize the impact on existing (or opstate unaware) NETCONF/RESTCONF clients and devices. The assumption of this model is that for an opstate unaware device, the persistent configuration, intended configuration and applied configuration datastores all hold exactly the same values. This is also why they are collectively labelled as the abstract running configuration datastore).
Hence, for opstate unaware clients the key change is that NETCONF/RESTCONF get requests now only returns the state from the operational-state datastore rather than returning the running configuration datastore plus all config=false nodes. This means that there are two specific changes to how get requests are handled compared to how they would be handled by existing NETCONF/RESTCONF devices:
The other potential impact is the recommendation that the standard default handling semantics for the persistent configure datastore (which is what would be returned for a get-config request against the abstract running configuration datastore) is that the exact configuration written by the client should be returned. This is exactly the same behavior as the 'explicit' retrieval mode described in With-defaults Capability for NETCONF [RFC6243].
The solution described in this document is intended to provide a viable upgrade path from an opstate unaware server to one that is opstate aware. I.e. it is feasible for an existing NETCONF/RESTCONF server to declare itself as being trivially opstate aware (treating applied configuration as the same as intended configuration) and over time refine the data it returns to provide more accurate applied configuration state.
This sections describes the implications for all opstate aware clients.
Although this draft references a total of ten datastores, the expectation is that devices will only expose a subset as explicit named datastores. Of course, devices could also expose them all as formal externally visible datastores if desired.
In particular, depending on the protocol semantics, an opstate aware device would be expected to support the following datastores/requests:
Support for operations on the following datastores would be optional:
Some of the nodes in these datastores rely on the structure and existance of nodes in the preceding datastores to be valid. Hence, get requests and YANG notifications would have to include sufficient parent nodes (and list keys) to represent a valid YANG data tree.
Rather that explicitly supporting and requiring management of all of these separate datastores, it is envisaged that optional YANG Metadata could be used to provide extra annotations to a subset of the datastores, allowing key additional information to be provided. A full solution is outside the scope of this draft, but it is envisaged that such annotations could be:
This document is not solely the authors own work, but instead represents one view from the discussions to find a consensual solution to the operational state problem. It takes ideas from many people and uses parts of solutions described in various internet drafts listed below. In particular, this document is an alternative to the revised datastore model described in draft-schoenw-netmod-revised-datastores [I-D.schoenw-netmod-revised-datastores], and reuses some of the structure and text from that document.
Work from the following internet drafts have helped form the basis of the datastore solution described in this draft:
The following people were authors to these Internet-Drafts or otherwise actively involved in the discussions that led to this document:
None
This document discusses a conceptual model of datastores for network management using NETCONF/RESTCONF and YANG. It has no security impact on the Internet.
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. |
| [RFC6243] | Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011. |
| [I-D.bjorklund-netmod-operational] | Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF and YANG", Internet-Draft draft-bjorklund-netmod-operational-00, October 2012. |
| [I-D.ietf-i2rs-ephemeral-state] | Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", Internet-Draft draft-ietf-i2rs-ephemeral-state-09, May 2016. |
| [I-D.ietf-netmod-opstate-reqs] | Watsen, K. and T. Nadeau, "Terminology and Requirements for Enhanced Handling of Operational State", Internet-Draft draft-ietf-netmod-opstate-reqs-04, January 2016. |
| [I-D.kwatsen-netmod-opstate] | Watsen, K., Bierman, A., Bjorklund, M. and J. Schönwälder, "Operational State Enhancements for YANG, NETCONF, and RESTCONF", Internet-Draft draft-kwatsen-netmod-opstate-02, February 2016. |
| [I-D.openconfig-netmod-opstate] | Shakir, R., Shaikh, A. and M. Hines, "Consistent Modeling of Operational State Data in YANG", Internet-Draft draft-openconfig-netmod-opstate-01, July 2015. |
| [I-D.schoenw-netmod-revised-datastores] | Schönwälder, J., "A Revised Conceptual Model for YANG Datastores", Internet-Draft draft-schoenw-netmod-revised-datastores-00, May 2016. |
| [I-D.wilton-netmod-opstate-yang] | Wilton, R., ""With-config-state" Capability for NETCONF/RESTCONF", Internet-Draft draft-wilton-netmod-opstate-yang-02, December 2015. |
| [RFC6244] | Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 2011. |