--- 1/draft-ietf-netmod-revised-datastores-09.txt 2018-01-12 16:13:19.425983548 -0800 +++ 2/draft-ietf-netmod-revised-datastores-10.txt 2018-01-12 16:13:19.501985379 -0800 @@ -1,24 +1,24 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Updates: 7950 (if approved) J. Schoenwaelder Intended status: Standards Track Jacobs University -Expires: June 23, 2018 P. Shafer +Expires: July 17, 2018 P. Shafer K. Watsen Juniper Networks R. Wilton Cisco Systems - December 20, 2017 + January 13, 2018 Network Management Datastore Architecture - draft-ietf-netmod-revised-datastores-09 + draft-ietf-netmod-revised-datastores-10 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. This document updates RFC 7950. @@ -30,25 +30,25 @@ 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 23, 2018. + This Internet-Draft will expire on July 17, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 @@ -74,56 +74,60 @@ 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 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 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 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.2. Define which subset of YANG-modeled data applies . . . . 28 + A.3. Define how data is actualized . . . . . . . . . . . . . . 28 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 + Appendix B. Ephemeral Dynamic Configuration Datastore Example . 29 + Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 30 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 + C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 33 + C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 35 + C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 35 + C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 36 + C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 37 + C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 37 + C.3.2. System-provided Interface . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This document provides an architectural framework for datastores as they are used by network management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling language. Datastores are a fundamental concept binding network management data models to network management protocols. 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. This architecture is agnostic with regard to the encoding used by network management protocols. + This document updates RFC 7950 by refining the definition of the + accessible tree for some XPath context (see Section 6.1) and the + invocation context of operations (see Section 6.2). + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Objectives Network management data objects can often take two different values, the value configured by the user or an application (configuration) @@ -147,23 +151,23 @@ operational state data from configuration data leads to a number of problems. Having configuration and operational state data in separate branches in the data model is operationally complicated and impacts the readability of module definitions. Furthermore, the relationship between the branches is not machine readable and filter expressions operating on configuration and on related operational state are different. With the revised architectural model of datastores defined in this document, the data objects are defined only once in the YANG schema - but independent instantiations can appear in two different - datastores, one for configured values and one for operational state - values. This provides a more elegant and simpler solution to the + but independent instantiations can appear in different datastores, + e.g., one for a configured value and another for an operationally + used value. This provides a more elegant and simpler solution to the problem. The revised architectural model of datastores supports additional datastores for systems that support more advanced processing chains converting configuration to operational state. For example, some systems support configuration that is not currently used (so called inactive configuration) or they support configuration templates that are used to expand configuration data via a common template. 3. Terminology @@ -323,21 +327,21 @@ [RFC6244] 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 [RFC6244] 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 + being stored in another datastore. Section 4.4 of [RFC6244] then concludes that at the time of the writing, modeling state as distinct leafs and distinct branches is the recommended approach. Implementation experience and requests from operators [I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate] 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. 4.1. Original Model of Datastores @@ -505,26 +509,26 @@ protocols or implementations. does not typically persist across reboots, even in the presence of non-volatile storage. If is stored using non-volatile storage, it is reset at boot time to the contents of . 5.1.3. The Running Configuration Datastore () The running configuration datastore () is a configuration - datastore that holds the complete current configuration on the - device. It MAY include configuration that requires further - transformation before it can be applied, e.g., inactive - configuration, or template-mechanism-oriented configuration that - needs further expansion. However, MUST always be a valid - configuration data tree, as defined in Section 8.1 of [RFC7950]. + datastore that holds the current configuration of the device. It MAY + include configuration that requires further transformation before it + can be applied, e.g., inactive configuration, or template-mechanism- + oriented configuration that needs further expansion. However, + MUST always be a valid configuration data tree, as defined + in Section 8.1 of [RFC7950]. MUST be supported if the device can be configured via conventional configuration datastores. If a device does not have a distinct and non-volatile storage is available, the device will typically use that non-volatile storage to allow to persist across reboots. 5.1.4. The Intended Configuration Datastore () @@ -799,21 +803,21 @@ Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore. Note that this document does not constrain the result of invoking an RPC or action in any way. For example, an RPC might be defined to modify the contents of some datastore. 7. YANG Modules - file "ietf-datastores@2017-12-20.yang" + file "ietf-datastores@2018-01-11.yang" module ietf-datastores { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; prefix ds; organization "IETF Network Modeling (NETMOD) Working Group"; contact @@ -834,35 +838,35 @@ Author: Rob Wilton "; description "This YANG module defines two sets of identities for datastores. The first identifies the datastores themselves, the second identifies datastore properties. - Copyright (c) 2017 IETF Trust and the persons identified as + Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself for full legal notices."; - revision 2017-12-20 { + revision 2018-01-11 { description "Initial revision."; reference "RFC XXXX: Network Management Datastore Architecture"; } /* * Identities */ @@ -922,21 +926,21 @@ base datastore; } description "A datastore identity reference."; } } - file "ietf-origin@2017-12-20.yang" + file "ietf-origin@2018-01-11.yang" module ietf-origin { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; prefix or; import ietf-yang-metadata { prefix md; } @@ -960,35 +964,35 @@ Author: Kent Watsen Author: Rob Wilton "; description "This YANG module defines an 'origin' metadata annotation, and a set of identities for the origin value. - Copyright (c) 2017 IETF Trust and the persons identified as + Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself for full legal notices."; - revision 2017-12-20 { + revision 2018-01-11 { description "Initial revision."; reference "RFC XXXX: Network Management Datastore Architecture"; } /* * Identities */ @@ -1114,30 +1118,38 @@ prefix: or reference: RFC XXXX 9. Security Considerations This document discusses an architectural model of datastores for network management using NETCONF/RESTCONF and YANG. It has no security impact on the Internet. Although this document specifies several YANG modules, these modules - only define identities and meta-data, hence the "YANG module security - guidelines" do not apply. + only define identities and a metadata annotation, hence the "YANG + module security guidelines" do not apply. + + The origin metadata annotation exposes the origin of values in the + applied configuration. Origin information may provide hints that + certain control plane protocols are active on a device. Since origin + information is tied to applied configuration values, it is only + accessible to clients that have the permissions to read the applied + configuration values. Security administrators should consider the + sensitivity of origin information while defining access control + rules. 10. Acknowledgments This document grew out of many discussions that took place since 2010. Several Internet-Drafts ([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 Lou Berger, LabN Consulting, L.L.C., o Andy Bierman, YumaWorks, o Marcus Hines, Google, @@ -1172,22 +1183,22 @@ 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, - . + 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, . [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 @@ -1415,27 +1426,26 @@ leaf ip { type inet:ip-address; } leaf prefix-length { type uint8; } } } } } - The operator has configured the host name and two interfaces, so the contents of are: - foo + foo.example.com eth0 1000
2001:db8::10 64
@@ -1458,21 +1468,21 @@ to a default value, a loopback interface is automatically added by the system, and the result of the "speed" auto-negotiation. All of this is reflected in . Note how the origin metadata attribute for several "config true" data nodes is inherited from their parent data nodes. - bar + bar.example.com eth0 true 1000 100
2001:db8::10 @@ -1567,21 +1577,21 @@ No time delay should exist between the appearance of the peer in and . In this scenario, we've added the following to : 64501 64502 - 10.1.2.3 + 2001:db8::2:3 C.2.2.1. The operational datastore will contain the fully expanded peer data, including "config false" nodes. In our example, this means the "state" node will appear. In addition, will contain the "currently in use" values @@ -1600,21 +1610,21 @@ values for the local-port and remote-port nodes regardless of the origin. If the system has chosen the values, the "origin" attribute will be set to "system". Before the connection is established, one or both of the nodes may not appear, since the system may not yet have their values. 64501 64502 - 10.1.2.3 + 2001:db8::2:3 64501 64502 60794 179 established C.2.3. Removing a Peer @@ -1630,21 +1640,21 @@ existence of that peer until the peer's resources are released, including closing the peer's connection. During this period, the current data values will continue to be visible in , with the "origin" attribute set to indicate the origin of the original data. 64501 64502 - 10.1.2.3 + 2001:db8::2:3 64501 64502 60794 179 closing Once resources are released and the connection is closed, the peer's data is removed from .