Network Working Group J. Schoenwaelder, Ed.
Internet-Draft Jacobs University
Intended status: Standards Track May 12, 2016
Expires: November 13, 2016
A Revised Conceptual Model for YANG Datastores
draft-schoenw-netmod-revised-datastores-00
Abstract
Datastores are a fundamental concept binding the YANG data modeling
language to protocols transporting data defined in YANG data models,
such as NETCONF or RESTCONF. This document defines a revised
conceptual model of datastores based on the experience gained with
the initial simpler model and addressing requirements that were not
well supported in the initial model.
Status of this Memo
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 November 13, 2016.
Copyright Notice
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
Schoenwaelder Expires November 13, 2016 [Page 1]
Internet-Draft Revised Model for YANG Datastores May 2016
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Original Model of Datastores . . . . . . . . . . . . . . . . . 5
4. Revised Model of Datastores . . . . . . . . . . . . . . . . . 7
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Missing Resources . . . . . . . . . . . . . . . . . . . . 9
5.2. System-controlled Resources . . . . . . . . . . . . . . . 9
5.3. Auto-configured or Auto-negotiated Values . . . . . . . . 9
5.4. Operational State with Different Origins . . . . . . . . . 9
6. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Implications on NETCONF . . . . . . . . . . . . . . . . . 10
6.2. Implications on RESTCONF . . . . . . . . . . . . . . . . . 10
6.3. Implications on YANG . . . . . . . . . . . . . . . . . . . 10
6.4. Implications on Data Models . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Schoenwaelder Expires November 13, 2016 [Page 2]
Internet-Draft Revised Model for YANG Datastores May 2016
1. Introduction
This document provides a revised architectural framework for
datastores as they are used by network management protocols such as
NETCONF [RFC6241], RESTCONF [I-D.ietf-netconf-restconf] and the YANG
[RFC6020] data modeling language. Datastores are a fundamental
concept binding management data models to network management
protocols and agreement on a common architectural model of datastores
ensures that data models can be written in a network management
protocol agnostic way. This architectural framework identifies a set
of conceptual datastores but it does not mandate that all network
management protocols expose all these conceptual datastores.
Furthermore, the architecture does not detail how data is encoded by
network management protocols.
Schoenwaelder Expires November 13, 2016 [Page 3]
Internet-Draft Revised Model for YANG Datastores May 2016
2. Background
NETCONF [RFC6241] provides the following definitions:
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.
o configuration datastore: The datastore holding the complete set of
configuration data that is required to get a device from its
initial default state into a desired operational state.
YANG 1.1 [I-D.YANG1.1] provides the following refinements when
NETCONF is used with YANG (which is the usual case but note that
NETCONF was defined before YANG did exist):
o datastore: When modeled with YANG, a datastore is realized as an
instantiated data tree.
o configuration datastore: When modeled with YANG, a configuration
datastore is realized as an instantiated data tree with
configuration data.
RFC 6244 defined operational state data as follows:
o Operational state data is a set of data that has been obtained by
the system at runtime and influences the system's behavior similar
to configuration data. In contrast to configuration data,
operational state is transient and modified by interactions with
internal components or other systems via specialized protocols.
Section 4.3.3 of RFC 6244 discusses operational state and among other
things mentions the option to consider operational state as being
stored in another datastore. Section 4.4 of this document then
concludes that at the time of the writing, modeling state as a
separate data tree is the recommended approach.
Implementation experience and requests from operators indicate that
the datastore model initially designed for NETCONF and refined by
YANG needs to be extended. In particular, the notion of intended
configuration and applied configuration has developed. Furthermore,
separating operational state data from configuration data in a
separate branch has been found operationally complicated. The
relationship between the branches is not machine readable and filter
expressions operating on configuration data and on related
operational state data are different.
Schoenwaelder Expires November 13, 2016 [Page 4]
Internet-Draft Revised Model for YANG Datastores May 2016
3. Original Model of Datastores
The following drawing shows the original model of datastores as it is
currently used by NETCONF [RFC6241]:
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +------------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+------------+
|
v
+--------------------------------+
| operational-state |<-- control plane
| (cf, ro) |
+--------------------------------+
ct = config true; cf = config false; rw = read-write; ro = read-only
Note that read-only (ro) and read-write (rw) is to be understood at a
conceptual level. In NETCONF, for example, support for the
<candidate> and <startup> datastores is optional and <running>
datastore does not have to be writable. Furthermore, the <startup>
datastore can only be modified by copying <running> to <startup> in
NETCONF. The RESTCONF protocol does not expose these differences and
instead provides only a writable unified datastore, which hides
whether edits are done through a <candidate> datastore or by directly
modifying the <running> datastore or via some other implementation
specific mechanism. RESTCONF also hides how configuration is made
persistent. Note that implementations may also have additional
datastores that can propagate changes to the <running> datastore.
NETCONF explicitly mentions so called named datastores.
Some observations:
o Operational state has not been defined as a datastore although
there were proposals in the past to introduce an operational state
datastore.
o The NETCONF <get/> operation returns the content of the <running/>
configuration datastore together with the operational state. It
is therefore necessary that config false data is in a different
branch than the config true data. This is in particular relevant
if operational state data can have a different lifetime compared
Schoenwaelder Expires November 13, 2016 [Page 5]
Internet-Draft Revised Model for YANG Datastores May 2016
to configuration data or if configuration data is not immediately
or successfully applied.
o Several implementations have proprietary mechanism that allow
clients to store inactive data in the <running> datastore; this
inactive data is only exposed to clients that indicate that they
support the concept of inactive data; clients not indicating
support for inactive data receive the content of the <running>
datastore with the inactive data removed. Validation always
happens on the <running> datastore with inactive data removed.
o Some operators have reported that it is essential for them to be
able to retrieve the configuration that has actually been
successfully applied, which may be a subset or a superset of the
<running> configuration.
Schoenwaelder Expires November 13, 2016 [Page 6]
Internet-Draft Revised Model for YANG Datastores May 2016
4. Revised Model of Datastores
Below is a new conceptual model of datastores extending the original
model in order reflect the experience gained with the original model.
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +------------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+------------+
| // e.g., removal of 'inactive' nodes
v
+------------+
| <intended> | // subject to validation
| (ct, ro) |
+------------+
| // e.g., missing resources or delays
v
+------------+
| <applied> |
| (ct, ro) |
+------------+
| // e.g., autodiscovery of values
v
+--------------------------------+
| <operational-state> |<-- control plane and
| (ct + cf, ro) | ephemeral datastores
+--------------------------------+
ct = config true; cf = config false; rw = read-write; ro = read-only
The main changes are:
o The original <running> configuration datastore has been split into
the <running> configuration datastore and the <intended>
configuration datastore. The <intended> configuration datastore
contains the configuration that is intended to be applied to the
device. On a traditional NETCONF implementation, <running> and
<intended> are always the same. However, implementations that
support inactive configuration usually expose <running> to clients
that understand inactive configuration and they expose <intended>
to clients that do not understand inactive configuration. The
introduction of an <intended> datastore makes this difference
explicit.
Schoenwaelder Expires November 13, 2016 [Page 7]
Internet-Draft Revised Model for YANG Datastores May 2016
o A new <applied> configuration datastore has been introduced that
reflects the configuration currently active on the device. This
may be a subset or a superset of the <intended> configuration.
Possible reasons for differences are situations where intended
configuration can't be applied due to missing resources or where
configuration changes take noticeable time to become applied.
o The operational state is considered to reside in a conceptual
<operational-state> datastore. This new read-only datastore
consists of config true and config false nodes; in the original
model the operational 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.
o The model foresees ephemeral datastores that are by definition not
part of the persistent configuration of a device. These ephemeral
datastores are considered to interact with the rest of the system
like any other control-plane mechanisms (e.g., routing protocols,
discovery protocols). [XXX Note that this is different from what
is described in some of the I2RS documents. XXX]
Schoenwaelder Expires November 13, 2016 [Page 8]
Internet-Draft Revised Model for YANG Datastores May 2016
5. Discussion
5.1. Missing Resources
Sometimes some parts of <intended> configuration refer to resources
that are not present and hence parts of the <intended> configuration
cannot be applied. A typical example is an interface configuration
that refers to an interface that is not currently present. In such a
situation, the interface configuration remains in <intended> but the
interface configuration will not appear in <applied>.
5.2. System-controlled Resources
Sometimes resources are controlled by the device and such system
controlled resources appear in (and disappear from) the operational
state dynamically. If a system controlled resource has matching
configuration in <intended> when it appears, the system will try to
apply the configuration, which causes the configuration to appear in
<applied> eventually (if application of the configuration was
successful).
5.3. Auto-configured or Auto-negotiated Values
Sometimes configuration leafs support special values that instruct
the system to automatically configure a value. An example is an MTU
that is configured to 'auto' to let the system determine a suitable
MTU value. Another example is Ethernet auto-negotiation of link
speed. In such a situation, the <intended> and <applied>
configuration datastores report the value 'auto' while the
corresponding leaf in the operational state datastore will report the
actual MTU value or the auto-negotiated link speed.
Since a config true leaf may be used both for configuration and for
reporting operational state, the value set of a leaf allowed in a
configuration datastores may be different from the value set of the
corresponding leaf in the operational state datastore.
5.4. Operational State with Different Origins
Sometimes a single list is used to report operational state values
that originate from difference sources, i.e., configuration, control
plane protocols, or internal processing. 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 will report all IP addresses that are assigned to an
interface while the applied configuration datastore only lists the
successfully configured addresses that have originated from the
intended configuration datastore.
Schoenwaelder Expires November 13, 2016 [Page 9]
Internet-Draft Revised Model for YANG Datastores May 2016
6. Implications
6.1. Implications on NETCONF
o A mechanism is needed to announce support for <intended> and
<applied> configuration datastores.
o Support for <intended> and <applied> datastores should be a
feature (optional to implement).
o For systems supporting <intended> or <applied> configuration
datastores, the <get-config/> operation may be used to retrieve
data stored in these new datastores.
o A new operation should be added to retrieve the operational state
data store (e.g., <get-state/>). (In principle <get-config/>
could work but it would be a confusing name.)
o The <get/> operation will be deprecated since it returns data from
two datastores that may overlap in the revised datastore model.
o Invoking <get-config/> on <running> will return <intended> for
backwards compatibility. [XXX: How to deal with <edit-config/>
for old and new clients with inactive nodes? XXX]
6.2. Implications on RESTCONF
o The {+restconf}/data resource represents the combined
configuration and state data resources that can be accessed by a
client. This is effectively bundling <running> together with
<operational-state>, much like the <get/> operation of NETCONF.
The RESTCONF design should change such that the {+restconf}/data
resource does not return the content of multiple datastores.
Instead, it should return the <running> datastore by default.
o The "content" query parameter can be used to select whether
config, nonconfig or all data is returned. It defaults to all.
The "content" query parameter should be changed to allow the
selection of other datastores, e.g., <operational-state>.
6.3. Implications on YANG
o Some clarifications may be needed if this revised model is
adopted. YANG currently describes validation in terms of the
<running> configuration datastore while it really happens on the
<intended> configuration datastore.
Schoenwaelder Expires November 13, 2016 [Page 10]
Internet-Draft Revised Model for YANG Datastores May 2016
6.4. Implications on Data Models
o Since the NETCONF <get/> operation returns the content of the
<running/> configuration datastore and the operational state
together in one tree, data models were often forced to branch at
the top-level into a config true branch and a structurally similar
config-false branch that replicated some of the config true nodes
and added state nodes. With the revised datastore model, this is
not needed anymore since the different datastores handle the
different lifetimes of data objects and together with the
deprecation of the <get/> operation it is not possible to write
simpler models.
o There may be some differences in the value set of some objects
that are used for both configuration and state. At this point of
time, these are considered to be rare cases that can be dealt with
using text in description statements. Future versions of YANG may
consider whether it is reasonable to allow value sets of schema
nodes to be partitioned into config true and config false value
sets.
Schoenwaelder Expires November 13, 2016 [Page 11]
Internet-Draft Revised Model for YANG Datastores May 2016
7. IANA Considerations
None.
Schoenwaelder Expires November 13, 2016 [Page 12]
Internet-Draft Revised Model for YANG Datastores May 2016
8. Security Considerations
This document discusses a conceptual model of datastores for network
management using NETCONF/RESTCONF and YANG. It has no security
impact on the Internet.
Schoenwaelder Expires November 13, 2016 [Page 13]
Internet-Draft Revised Model for YANG Datastores May 2016
9. Acknowledgments
This document grew out of many discussions that took place since
2010. Several Internet-Drafts ([I-D.wilton-netmod-opstate-yang],
[I-D.bjorklund-netmod-operational], [I-D.wilton-netmod-opstate-yang],
[I-D.ietf-netmod-opstate-reqs], [I-D.kwatsen-netmod-opstate],
[I-D.openconfig-netmod-opstate]) and [RFC6244] touched on some of the
problems of the original datastore model. The following people were
authors to these Internet-Drafts or otherwise actively involved in
the discussions that led to this document:
o Andy Biermann, YumaWorks, <andy@yumaworks.com>
o Martin Bjorklund, Tail-f Systems, <mbj@tail-f.com>
o Marcus Hines, Google, <hines@google.com>
o Christian Hopps, Cisco Systems, <chopps@chopps.org>
o Acee Lindem, Cisco Systems, <acee@cisco.com>
o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>
o Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com>
o Anees Shaikh, Google, <aashaikh@google.com>
o Rob Shakir, Jive Communications, <rjs@rob.sh>
o Kent Watsen, Juniper Networks, <kwatsen@juniper.net>
o Robert Wilton, Cisco Systems, <rwilton@cisco.com>
Schoenwaelder Expires November 13, 2016 [Page 14]
Internet-Draft Revised Model for YANG Datastores May 2016
10. References
10.1. Normative References
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-13 (work in
progress), April 2016.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[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,
<http://www.rfc-editor.org/info/rfc6241>.
10.2. Informative References
[I-D.bjorklund-netmod-operational]
Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF
and YANG", draft-bjorklund-netmod-operational-00 (work in
progress), October 2012.
[I-D.ietf-netmod-opstate-reqs]
Watsen, K. and T. Nadeau, "Terminology and Requirements
for Enhanced Handling of Operational State",
draft-ietf-netmod-opstate-reqs-04 (work in progress),
January 2016.
[I-D.kwatsen-netmod-opstate]
Watsen, K., Bierman, A., Bjorklund, M., and J.
Schoenwaelder, "Operational State Enhancements for YANG,
NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02
(work in progress), February 2016.
[I-D.openconfig-netmod-opstate]
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
of Operational State Data in YANG",
draft-openconfig-netmod-opstate-01 (work in progress),
July 2015.
[I-D.wilton-netmod-opstate-yang]
Wilton, R., ""With-config-state" Capability for NETCONF/
RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in
progress), December 2015.
Schoenwaelder Expires November 13, 2016 [Page 15]
Internet-Draft Revised Model for YANG Datastores May 2016
[RFC6244] Shafer, P., "An Architecture for Network Management Using
NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244,
June 2011, <http://www.rfc-editor.org/info/rfc6244>.
Schoenwaelder Expires November 13, 2016 [Page 16]
Internet-Draft Revised Model for YANG Datastores May 2016
Author's Address
Juergen Schoenwaelder (editor)
Jacobs University
Email: j.schoenwaelder@jacobs-university.de
Schoenwaelder Expires November 13, 2016 [Page 17]