draft-ietf-netmod-revised-datastores-07.txt   draft-ietf-netmod-revised-datastores-08.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: June 2, 2018 P. Shafer Expires: June 23, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
November 29, 2017 December 20, 2017
Network Management Datastore Architecture Network Management Datastore Architecture
draft-ietf-netmod-revised-datastores-07 draft-ietf-netmod-revised-datastores-08
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. This document updates RFC 7950.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 2, 2018. This Internet-Draft will expire on June 23, 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 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Original Model of Datastores . . . . . . . . . . . . . . 8 4.1. Original Model of Datastores . . . . . . . . . . . . . . 8
5. Architectural Model of Datastores . . . . . . . . . . . . . . 9 5. Architectural Model of Datastores . . . . . . . . . . . . . . 9
5.1. Conventional Configuration Datastores . . . . . . . . . . 10 5.1. Conventional Configuration Datastores . . . . . . . . . . 10
5.1.1. The Startup Configuration Datastore (<startup>) . . . 11 5.1.1. The Startup Configuration Datastore (<startup>) . . . 11
5.1.2. The Candidate Configuration Datastore (<candidate>) . 11 5.1.2. The Candidate Configuration Datastore (<candidate>) . 11
5.1.3. The Running Configuration Datastore (<running>) . . . 11 5.1.3. The Running Configuration Datastore (<running>) . . . 12
5.1.4. The Intended Configuration Datastore (<intended>) . . 12 5.1.4. The Intended Configuration Datastore (<intended>) . . 12
5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13 5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13
5.3. The Operational State Datastore (<operational>) . . . . . 13 5.3. The Operational State Datastore (<operational>) . . . . . 13
5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14 5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14
5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14 5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . 17
6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 17 6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24
8.2. Updates to the YANG Module Names Registry . . . . . . . . 24 8.2. Updates to the YANG Module Names Registry . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27
A.1. Define which YANG modules can be used in the datastore . 27 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 . . . . . . . . . . . 28 A.4. Define which protocols can be used . . . . . . . . . . . 28
A.5. Define YANG identities for the datastore . . . . . . . . 28 A.5. Define YANG identities for the datastore . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . 30
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
C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35
C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36
C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36
C.3.2. System-provided Interface . . . . . . . . . . . . . . 37 C.3.2. System-provided Interface . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
skipping to change at page 10, line 46 skipping to change at page 10, line 46
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 datastore schema, allowing datastores that share exactly the same datastore schema, allowing
data to be copied between them. The term is meant as a generic data to be copied between them. The term is meant as a generic
umbrella description of these datastores. The set of datastores umbrella description of these datastores. If a module does not
contain any configuration data nodes and it is not needed to satisfy
any imports, then it MAY be omitted from the datastore schema for the
conventional configuration datastores. The set of datastores
include: 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
skipping to change at page 13, line 16 skipping to change at page 13, line 20
5.2. Dynamic Configuration Datastores 5.2. Dynamic Configuration Datastores
The model recognizes the need for dynamic configuration datastores The model recognizes the need for dynamic configuration datastores
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>.
The datastore schema for a dynamic configuration datastore MAY differ
from the datastore schema used for conventional configuration
datastores. If a module does not contain any configuration data
nodes and it is not needed to satisfy any imports, then it MAY be
omitted from the datastore schema for the dynamic configuration
datastore.
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 datastore's schema. In the original NETCONF model the defined in the datastore's schema. In the original NETCONF model the
operational state only had "config false" nodes. The reason for operational state only had "config false" nodes. The reason for
incorporating "config true" nodes here is to be able to expose all incorporating "config true" nodes here is to be able to expose all
operational settings without having to replicate definitions in the operational settings without having to replicate definitions in the
data models. 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 The datastore schema for <operational> MUST be a superset of the
combined datastore schema used in all configuration datastores except combined datastore schema used in all configuration datastores except
that YANG nodes supported in a configuration datastore MAY be omitted that configuration data nodes supported in a configuration datastore
from <operational> if a server is not able to accurately report them. 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".
skipping to change at page 25, line 33 skipping to change at page 25, line 43
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Juergen Schoenwaelder was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme. under its Seventh Framework Programme.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- RFC2119, March 1997, <https://www.rfc-editor.org/info/
editor.org/info/rfc2119>. rfc2119>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC
RFC 7952, DOI 10.17487/RFC7952, August 2016, 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7952>. editor.org/info/rfc7952>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
skipping to change at page 27, line 9 skipping to change at page 27, line 18
editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC6244] Shafer, P., "An Architecture for Network Management Using [RFC6244] Shafer, P., "An Architecture for Network Management Using
NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June
2011, <https://www.rfc-editor.org/info/rfc6244>. 2011, <https://www.rfc-editor.org/info/rfc6244>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC
RFC 7277, DOI 10.17487/RFC7277, June 2014, 7277, DOI 10.17487/RFC7277, June 2014, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7277>. editor.org/info/rfc7277>.
Appendix A. Guidelines for Defining Datastores Appendix A. Guidelines for Defining Datastores
The definition of a new datastore in this architecture should be The definition of a new datastore in this architecture should be
provided in a document (e.g., an RFC) purposed to the definition of provided in a document (e.g., an RFC) purposed to the definition of
the datastore. When it makes sense, more than one datastore may be the datastore. When it makes sense, more than one datastore may be
defined in the same document (e.g., when the datastores are logically defined in the same document (e.g., when the datastores are logically
connected). Each datastore's definition should address the points connected). Each datastore's definition should address the points
specified in the sections below. specified in the sections below.
 End of changes. 18 change blocks. 
26 lines changed or deleted 37 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/