draft-ietf-netmod-revised-datastores-05.txt   draft-ietf-netmod-revised-datastores-06.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Updates: 7950 (if approved) J. Schoenwaelder Updates: 7950 (if approved) J. Schoenwaelder
Intended status: Standards Track Jacobs University Intended status: Standards Track Jacobs University
Expires: April 21, 2018 P. Shafer Expires: May 3, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
October 18, 2017 October 30, 2017
Network Management Datastore Architecture Network Management Datastore Architecture
draft-ietf-netmod-revised-datastores-05 draft-ietf-netmod-revised-datastores-06
Abstract Abstract
Datastores are a fundamental concept binding the data models written Datastores are a fundamental concept binding the data models written
in the YANG data modeling language to network management protocols in the YANG data modeling language to network management protocols
such as NETCONF and RESTCONF. This document defines an architectural such as NETCONF and RESTCONF. This document defines an architectural
framework for datastores based on the experience gained with the framework for datastores based on the experience gained with the
initial simpler model, addressing requirements that were not well initial simpler model, addressing requirements that were not well
supported in the initial model. supported in the initial model.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14 5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14
5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14 5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14
5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15
5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15
6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16
6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23
8.2. Updates to the YANG Module Names Registry . . . . . . . . 23 8.2. Updates to the YANG Module Names Registry . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26
A.1. Define which YANG modules can be used in the datastore . 26 A.1. Define which YANG modules can be used in the datastore . 27
A.2. Define which subset of YANG-modeled data applies . . . . 27 A.2. Define which subset of YANG-modeled data applies . . . . 27
A.3. Define how data is actualized . . . . . . . . . . . . . . 27 A.3. Define how data is actualized . . . . . . . . . . . . . . 27
A.4. Define which protocols can be used . . . . . . . . . . . 27 A.4. Define which protocols can be used . . . . . . . . . . . 27
A.5. Define YANG identities for the datastore . . . . . . . . 27 A.5. Define YANG identities for the datastore . . . . . . . . 27
Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28
Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29
C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29
C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32
C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34
C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34
skipping to change at page 4, line 43 skipping to change at page 4, line 43
semantically equivalent with the definitions found in [RFC6241] and semantically equivalent with the definitions found in [RFC6241] and
[RFC7950]. It is expected that the revised definitions provided in [RFC7950]. It is expected that the revised definitions provided in
this section will replace the definitions in [RFC6241] and [RFC7950] this section will replace the definitions in [RFC6241] and [RFC7950]
when these documents are revised. when these documents are revised.
o datastore: A conceptual place to store and access information. A o datastore: A conceptual place to store and access information. A
datastore might be implemented, for example, using files, a datastore might be implemented, for example, using files, a
database, flash memory locations, or combinations thereof. A database, flash memory locations, or combinations thereof. A
datastore maps to an instantiated YANG data tree. datastore maps to an instantiated YANG data tree.
o schema node: A node in the schema tree. The formal definition is
in RFC 7950.
o datastore schema: The combined set of schema nodes for all modules
supported by a particular datastore, taking into consideration any
deviations and enabled features for that datastore.
o configuration: Data that is required to get a device from its o configuration: Data that is required to get a device from its
initial default state into a desired operational state. This data initial default state into a desired operational state. This data
is modeled in YANG using "config true" nodes. Configuration can is modeled in YANG using "config true" nodes. Configuration can
originate from different sources. originate from different sources.
o configuration datastore: A datastore holding configuration. o configuration datastore: A datastore holding configuration.
o running configuration datastore: A configuration datastore holding o running configuration datastore: A configuration datastore holding
the current configuration of the device. It may include the current configuration of the device. It may include
configuration that requires further transformations before it can configuration that requires further transformations before it can
skipping to change at page 5, line 35 skipping to change at page 5, line 42
datastore is referred to as "<intended>". datastore is referred to as "<intended>".
o configuration transformation: The addition, modification or o configuration transformation: The addition, modification or
removal of configuration between the <running> and <intended> removal of configuration between the <running> and <intended>
datastores. Examples of configuration transformations include the datastores. Examples of configuration transformations include the
removal of inactive configuration and the configuration produced removal of inactive configuration and the configuration produced
through the expansion of templates. through the expansion of templates.
o conventional configuration datastore: One of the following set of o conventional configuration datastore: One of the following set of
configuration datastores: <running>, <startup>, <candidate>, and configuration datastores: <running>, <startup>, <candidate>, and
<intended>. These datastores share a common schema, and protocol <intended>. These datastores share a common datastore schema, and
operations allow copying data between these datastores. The term protocol operations allow copying data between these datastores.
"conventional" is chosen as a generic umbrella term for these The term "conventional" is chosen as a generic umbrella term for
datastores. these datastores.
o conventional configuration: Configuration that is stored in any of o conventional configuration: Configuration that is stored in any of
the conventional configuration datastores. the conventional configuration datastores.
o dynamic configuration datastore: A configuration datastore holding o dynamic configuration datastore: A configuration datastore holding
configuration obtained dynamically during the operation of a configuration obtained dynamically during the operation of a
device through interaction with other systems, rather than through device through interaction with other systems, rather than through
one of the conventional configuration datastores. one of the conventional configuration datastores.
o dynamic configuration: Configuration obtained via a dynamic o dynamic configuration: Configuration obtained via a dynamic
skipping to change at page 10, line 44 skipping to change at page 10, line 44
| (ct + cf, ro) | | (ct + cf, ro) |
+---------------+ +---------------+
ct = config true; cf = config false ct = config true; cf = config false
rw = read-write; ro = read-only rw = read-write; ro = read-only
boxes denote named datastores boxes denote named datastores
5.1. Conventional Configuration Datastores 5.1. Conventional Configuration Datastores
The conventional configuration datastores are a set of configuration The conventional configuration datastores are a set of configuration
datastores that share exactly the same schema, allowing data to be datastores that share exactly the same datastore schema, allowing
copied between them. The term is meant as a generic umbrella data to be copied between them. The term is meant as a generic
description of these datastores. The set of datastores include: umbrella description of these datastores. The set of datastores
include:
o <running> o <running>
o <candidate> o <candidate>
o <startup> o <startup>
o <intended> o <intended>
Other conventional configuration datastores may be defined in future Other conventional configuration datastores may be defined in future
documents. documents.
The flow of data between these datastores is depicted in Section 5. The flow of data between these datastores is depicted in Section 5.
The specific protocols may define explicit operations to copy between The specific protocols may define explicit operations to copy between
these datastores, e.g., NETCONF defines the <copy-config> operation. these datastores, e.g., NETCONF defines the <copy-config> operation.
skipping to change at page 13, line 18 skipping to change at page 13, line 20
that are, by definition, not part of the persistent configuration of that are, by definition, not part of the persistent configuration of
a device. In some contexts, these have been termed ephemeral a device. In some contexts, these have been termed ephemeral
datastores since the information is ephemeral, i.e., lost upon datastores since the information is ephemeral, i.e., lost upon
reboot. The dynamic configuration datastores interact with the rest reboot. The dynamic configuration datastores interact with the rest
of the system through <operational>. of the system through <operational>.
5.3. The Operational State Datastore (<operational>) 5.3. The Operational State Datastore (<operational>)
The operational state datastore (<operational>) is a read-only The operational state datastore (<operational>) is a read-only
datastore that consists of all "config true" and "config false" nodes datastore that consists of all "config true" and "config false" nodes
defined in the schema. In the original NETCONF model the operational defined in the datastore's schema. In the original NETCONF model the
state only had "config false" nodes. The reason for incorporating operational state only had "config false" nodes. The reason for
"config true" nodes here is to be able to expose all operational incorporating "config true" nodes here is to be able to expose all
settings without having to replicate definitions in the data models. operational settings without having to replicate definitions in the
data models.
<operational> contains system state and all configuration actually <operational> contains system state and all configuration actually
used by the system. This includes all applied configuration from used by the system. This includes all applied configuration from
<intended>, learned configuration, system-provided configuration, and <intended>, learned configuration, system-provided configuration, and
default values defined by any supported data models. In addition, default values defined by any supported data models. In addition,
<operational> also contains applied configuration from dynamic <operational> also contains applied configuration from dynamic
configuration datastores. configuration datastores.
The datastore schema for <operational> MUST be a superset of the
combined datastore schema used in all configuration datastores except
that YANG nodes supported in a configuration datastore MAY be omitted
from <operational> if a server is not able to accurately report them.
Requests to retrieve nodes from <operational> always return the value Requests to retrieve nodes from <operational> always return the value
in use if the node exists, regardless of any default value specified 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 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. this implies that the node is not used by the device.
The interpretation of what constitutes as being "in use" by the The interpretation of what constitutes as being "in use" by the
system is dependent on both the schema definition and the device system is dependent on both the schema definition and the device
implementation. Generally, functionality that is enabled and implementation. Generally, functionality that is enabled and
operational on the system would be considered as being "in use". operational on the system would be considered as being "in use".
Conversely, functionality that is neither enabled nor operational on Conversely, functionality that is neither enabled nor operational on
 End of changes. 14 change blocks. 
19 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/