--- 1/draft-ietf-netmod-revised-datastores-07.txt 2017-12-20 03:13:13.993978834 -0800 +++ 2/draft-ietf-netmod-revised-datastores-08.txt 2017-12-20 03:13:14.069980702 -0800 @@ -1,50 +1,50 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Updates: 7950 (if approved) J. Schoenwaelder Intended status: Standards Track Jacobs University -Expires: June 2, 2018 P. Shafer +Expires: June 23, 2018 P. Shafer K. Watsen Juniper Networks R. Wilton Cisco Systems - November 29, 2017 + December 20, 2017 Network Management Datastore Architecture - draft-ietf-netmod-revised-datastores-07 + draft-ietf-netmod-revised-datastores-08 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. + supported in the initial model. This document updates RFC 7950. 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 June 2, 2018. + This Internet-Draft will expire on June 23, 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,49 +58,49 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Original Model of Datastores . . . . . . . . . . . . . . 8 5. Architectural Model of Datastores . . . . . . . . . . . . . . 9 5.1. Conventional Configuration Datastores . . . . . . . . . . 10 5.1.1. The Startup Configuration Datastore () . . . 11 5.1.2. The Candidate Configuration Datastore () . 11 - 5.1.3. The Running Configuration Datastore () . . . 11 + 5.1.3. The Running Configuration Datastore () . . . 12 5.1.4. The Intended Configuration Datastore () . . 12 5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13 5.3. The Operational State Datastore () . . . . . 13 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.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 - 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16 - 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16 - 6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 17 + 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17 + 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17 + 6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24 8.2. Updates to the YANG Module Names Registry . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 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.3. Define how data is actualized . . . . . . . . . . . . . . 27 A.4. Define which protocols can be used . . . . . . . . . . . 28 A.5. Define YANG identities for the datastore . . . . . . . . 28 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 - C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29 + C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36 C.3.2. System-provided Interface . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction @@ -444,26 +444,29 @@ ct = config true; cf = config false rw = read-write; ro = read-only boxes denote named datastores 5.1. Conventional Configuration Datastores The conventional configuration datastores are a set of configuration datastores that share exactly the same datastore schema, allowing 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: o - o + o o Other conventional configuration datastores may be defined in future documents. The flow of data between these datastores is depicted in Section 5. The specific protocols may define explicit operations to copy between @@ -557,41 +560,49 @@ 5.2. Dynamic Configuration Datastores The model recognizes the need for dynamic configuration datastores that are, by definition, not part of the persistent configuration of a device. In some contexts, these have been termed ephemeral datastores since the information is ephemeral, i.e., lost upon reboot. The dynamic configuration datastores interact with the rest of the system through . + 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 () The operational state datastore () is a read-only datastore that consists of all "config true" and "config false" nodes defined in the datastore's schema. In the original NETCONF 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. contains system state and all configuration actually used by the system. This includes all applied configuration from , learned configuration, system-provided configuration, and default values defined by any supported data models. In addition, also contains applied configuration from dynamic configuration datastores. The datastore schema for 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 if a server is not able to accurately report them. + that configuration data nodes supported in a configuration datastore + MAY be omitted from if a server is not able to + accurately report them. 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. The interpretation of what constitutes as being "in use" by the system is dependent on both the schema definition and the device implementation. Generally, functionality that is enabled and operational on the system would be considered as being "in use". @@ -1142,36 +1156,36 @@ Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, . + Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ + RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References @@ -1212,23 +1226,23 @@ editor.org/info/rfc6020>. [RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 2011, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . - [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", - RFC 7277, DOI 10.17487/RFC7277, June 2014, - . + [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC + 7277, DOI 10.17487/RFC7277, June 2014, . Appendix A. Guidelines for Defining Datastores The definition of a new datastore in this architecture should be 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 defined in the same document (e.g., when the datastores are logically connected). Each datastore's definition should address the points specified in the sections below.