--- 1/draft-ietf-netmod-nmda-diff-04.txt 2020-09-15 15:13:08.754330500 -0700 +++ 2/draft-ietf-netmod-nmda-diff-05.txt 2020-09-15 15:13:08.778330837 -0700 @@ -1,22 +1,22 @@ Network Working Group A. Clemm Internet-Draft Y. Qu Intended status: Standards Track Futurewei -Expires: January 14, 2021 J. Tantsura +Expires: March 19, 2021 J. Tantsura Apstra A. Bierman YumaWorks - July 13, 2020 + September 15, 2020 Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-04 + draft-ietf-netmod-nmda-diff-05 Abstract This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -24,21 +24,21 @@ 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 https://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 January 14, 2021. + This Internet-Draft will expire on March 19, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,24 +53,24 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 4. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 4 5. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 6 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Performance Considerations . . . . . . . . . . . . . . . . . 13 8. Possible Future Extensions . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. Updates to the IETF XML Registry . . . . . . . . . . . . 14 - 9.2. Updates to the YANG Module Names Registry . . . . . . . . 15 + 9.2. Updates to the YANG Module Names Registry . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The revised Network Management Datastore Architecture (NMDA) [RFC8342] introduces a set of new datastores that each hold YANG- defined data [RFC7950] and represent a different "viewpoint" on the data that is maintained by a server. New YANG datastores that are @@ -230,39 +230,44 @@ +--ro target target-resource-offset +--ro point? target-resource-offset +--ro where? enumeration +--ro value? +--ro source-value? Structure of ietf-nmda-compare 5. YANG Data Model - file "ietf-nmda-compare@2019-11-04.yang" + file "ietf-nmda-compare@2020-09-15.yang" module ietf-nmda-compare { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare"; - prefix cp; + prefix cmp; import ietf-yang-types { prefix yang; + reference "RFC 6991: Common YANG Data Types"; } import ietf-datastores { prefix ds; + reference "RFC 8342: Network Management Datastore + Architecture (NMDA)"; } import ietf-yang-patch { prefix ypatch; + reference "RFC 8072: YANG Patch Media Type"; } import ietf-netconf { prefix nc; + reference "RFC6241: Network Configuration Protocol (NETCONF)"; } organization "IETF"; contact "WG Web: WG List: Author: Alexander Clemm @@ -291,21 +296,21 @@ 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 (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2019-11-04 { + revision 2020-09-15 { description "Initial revision"; reference "RFC XXXX: Comparison of NMDA datastores"; } /* RPC */ rpc compare { description "NMDA compare operation."; @@ -357,20 +362,21 @@ target datastore to retrieve."; reference "RFC 6241, Section 6."; } leaf xpath-filter { if-feature nc:xpath; type yang:xpath1.0; description "This parameter contains an XPath expression identifying the portions of the target datastore to retrieve."; + reference "RFC 6021: Common YANG Data Types"; } } } output { choice compare-response { description "Comparison results."; leaf no-matches { type empty; description @@ -392,37 +398,38 @@ when "../operation = 'delete'" + "or ../operation = 'merge'" + "or ../operation = 'move'" + "or ../operation = 'replace'" + "or ../operation = 'remove'"; description "The anydata 'value' is only used for 'delete', 'move', 'merge', 'replace', and 'remove' operations."; } + reference "RFC 8072: YANG Patch Media Type"; } } } } } } } 6. Example The following example compares the difference between and for a subtree under "interfaces". The subtree - contains objects that are defined in a YANG data model for the - management of interfaces defined in [RFC8343]. The excerpt of the - data model whose instantiation is basis of the comparison is as - follows: + contains a subset of objects that are defined in a YANG data model + for the management of interfaces defined in [RFC8343]. The excerpt + of the data model whose instantiation is basis of the comparison is + as follows: container interfaces { description "Interface parameters."; list interface { key "name"; leaf name { type string; description "The name of the interface". @@ -437,159 +444,160 @@ default "true"; description "This leaf contains the configured, desired state of the interface.";" } } } The contents of and datastores: - + //INTENDED + eth0 false ip interface - - + + + //OPERATIONAL + + eth0 true + + does not contain object "description" that is contained + in . Another object, "enabled", has differences in values, + being "true" in and "false" in . A third + object, "name", is the same in both cases. The origin of the objects + in is "learned", which may help explain the + discrepancies. - contains one object that was not contained in - , "preference". Another object, "explicit-router-id", has - differences in values. A third object, "enable", is the same in both - cases. - - RPC request to compare (source of the comparison) with (target of the comparison): ds:operational ds:intended \ - /if:interfaces\ + xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"> + /if:interfaces RPC reply, when a difference is detected: interface status - diff between operational and intended + + diff between operational (source) and intended (target) + 1 replace /ietf-interfaces:interface=eth0/enabled - true + false - false + true 2 create /ietf-interfaces:interface=eth0/description - ip interface + ip interface The same request in RESTCONF (using JSON format): POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1 Host: example.com Content-Type: application/yang-data+json Accept: application/yang-d { "ietf-nmda-compare:input" { - "source" : "ietf-datastores:operational", - "target" : "ietf-datastores:intended". + "source" : "ietf-datastores:operational" + "target" : "ietf-datastores:intended" "xpath-filter" : \ "/ietf-interfaces:interfaces" } } The same response in RESTCONF (using JSON format): HTTP/1.1 200 OK Date: Thu, 26 Jan 2019 20:56:30 GMT Server: example-server Content-Type: application/yang-d { "ietf-nmda-compare:output" : { "differences" : { "ietf-yang-patch:yang-patch" : { "patch-id" : "interface status", - "comment" : "diff between operational and intended", + "comment" : "diff between intended (source) and operational", "edit" : [ { "edit-id" : "1", "operation" : "replace", "target" : "/ietf-interfaces:interface=eth0/enabled", "value" : { - "ietf-interfaces:interface/enabled" : "true" - "@ietf-interfaces:interface/enabled" : { - "ietf-origin:origin" : "ietf-origin:system" - } - "source-value" : { "ietf-interfaces:interface/enabled" : "false" + }, + "source-value" : { + "ietf-interfaces:interface/enabled" : "true", "@ietf-interfaces:interface/enabled" : { - "ietf-origin:origin" : "ietf-origin:intended" + "ietf-origin:origin" : "ietf-origin:learned" + } } "edit-id" : "2", "operation" : "create", "target" : "/ietf-interfaces:interface=eth0/description", "value" : { "ietf-interface:interface/description" : "ip interface" - "@ietf-interface:interfaces/description" : { - "ietf-origin:origin" : "ietf-origin:intended" } } ] } } } } 7. Performance Considerations The compare operation can be computationally expensive. While responsible client applications are expected to use the operation responsibly and sparingly only when warranted, implementations need to be aware of the fact that excessive invocation of this operation will burden system resources and need to ensure that system performance will not be adversely impacted. One possibility for an implementation to mitigate against such a possibility is to limit the - number of requests that is served to a client in any one time - interval, rejecting requests made at a higher frequency than the - implementation can reasonably sustain. + number of requests that is served to a client, or to any number of + clients, in any one time interval, rejecting requests made at a + higher frequency than the implementation can reasonably sustain. 8. Possible Future Extensions It is conceivable to extend the compare operation with a number of possible additional features in the future. Specifically, it is possible to define an extension with an optional feature for dampening. This will allow clients to specify a minimum time period for which a difference must persist for it to be reported. This will enable clients to distinguish between @@ -624,24 +632,23 @@ XML: N/A, the requested URI is an XML namespace. 9.2. Updates to the YANG Module Names Registry This document registers a YANG module in the YANG Module Names registry [RFC7950]. Following the format in [RFC7950], the following registration is requested: name: ietf-nmda-compare - namespace: urn:ietf:params:xml:ns:yang:ietf-nmda-compare - prefix: cp + prefix: cmp reference: RFC XXXX 10. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer @@ -665,25 +672,24 @@ ways. For one, they can implement the NETCONF access control model in order to require proper authorization for requests to be made. Second, server implementations can limit the number of requests that they serve to a client in any one time interval, rejecting requests made at a higher frequency than the implementation can reasonably sustain. 11. Acknowledgments We thank Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou - Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka, and Tim Carey for - valuable feedback and suggestions. + Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka, Tim Carey, and + Reshad Rahman for valuable feedback and suggestions. 12. References - 12.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, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . @@ -690,20 +696,24 @@ [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, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch Media Type", RFC 8072, DOI 10.17487/RFC8072, February