NETCONF Working Group Q. Wu Internet-Draft C. Feng Intended status: Standards Track Huawei Expires: September 10, 2019 March 9, 2019 NMDA protocol operation Backwards-Compatibility with Legacy Devices draft-wu-netconf-nmda-compatibility-01 Abstract NMDA architectural framework eliminates the need to duplicate data structures to provide separate configuration and operational state sections and uses different datastores and new protocol operations to distinct configuration from operation state. However when non-NMDA clients communicate with NMDA aware server, it is not clear whether the NMDA aware server can use existing operation to return the same results with as non-NMDA-aware server does. This document identifies some of the major challenges, and provides solutions that are able to mitigate those challenges and smooth the migration towards NMDA deployment. 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 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 September 10, 2019. Copyright Notice Copyright (c) 2019 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 Wu & Feng Expires September 10, 2019 [Page 1] Internet-Draft NMDA Backwards-Compatibility March 2019 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. NMDA Client vs Non-NMDA Client . . . . . . . . . . . . . 4 2.2. NETCONF Server Back-Compatibility . . . . . . . . . . . . 4 2.3. Feed System Configuration Back into Running Datastore . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Client NMDA Support . . . . . . . . . . . . . . . . . . . 5 3.2. Default handling Behaviour . . . . . . . . . . . . . . . 5 3.2.1. Default-Handling Basic Modes . . . . . . . . . . . . 5 3.2.2. get/get-config Operation . . . . . . . . . . . . . . 6 3.2.3. get-data Operation . . . . . . . . . . . . . . . . . 7 3.3. Protocol Operation Clarification . . . . . . . . . . . . 7 3.3.1. . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. . . . . . . . . . . . . . . . . . . . . 7 3.3.3. . . . . . . . . . . . . . . . . . . . . 8 3.3.4. . . . . . . . . . . . . . . . . . . . . . 8 3.3.5. . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction NMDA architectural framework introduces additional datastores for systems that support more advanced processing chains converting configuration to operational state. It eliminates the need to duplicate data structures to provide separate configuration and operational state sections and uses different datastores and new protocol operations (e.g.,, to distinct configuration from operation state). However when a NMDA client communicates with NMDA aware server, it is not clear whether the NMDA aware server can return the same results Wu & Feng Expires September 10, 2019 [Page 2] Internet-Draft NMDA Backwards-Compatibility March 2019 with to non-NMDA clients as non-NMDA-aware server does since the system configuration and default configuration originally part of conventional configuration datastores have been explicitly separated and moved to operational state datastore under NMDA architecture. Also it is not clear whether the server should maintain protocol operation backwards-compatibility when the NMDA aware server is upgraded from non-NMDA-aware server to NMDA aware server. NMDA Transition Guidelines in section 4.23.3 of [RFC8407] only provides guidelines to transform non-NMDA compliant model into NMDA compatible model, but doesn't provide guidelines on whether existing NETCONF protocol operations such as get/get-config/edit-config change semantics when they are exchanged between the non NMDA client and the NMDA arware server. This document identifies some of the major challenges, and provides solutions that are able to address those challenges which provide smooth migration towards NMDA deployment. o Use protocol operation to indicate whether the client NMDA support. o An extension to Default handling Behaviour. o Protocol Operation Clarification. 1.1. Terminology 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. The following terms are defined in [RFC8342] and are not redefined here: o startup configuration datastore o candiate configuration datastore o running configuration datastore o intended configuration datastore o operational state datastore Wu & Feng Expires September 10, 2019 [Page 3] Internet-Draft NMDA Backwards-Compatibility March 2019 The following terms are defined in this document: Server Protocol Operation Backwards-Compatibility: The client can use the same protocol operation to get the same results from both NMDA compliant server and Non NMDA server. 2. Problems 2.1. NMDA Client vs Non-NMDA Client When a server is upgraded to NMDA aware server and needs to support both NMDA client and non-NMDA clients, there is no standards-based way for the server to know whether the client supports NMDA. 2.2. NETCONF Server Back-Compatibility When a server is upgraded to NMDA server and needs to support both NMDA client and non-NMDA clients, without NETCONF server protocol operation backwards-comability, a NMDA server can return the results with to non-NMDA clients different from non-NMDA-aware server does. Since in some cases ('report-all' Retrieval Mode or client set Explicit Mode) default configuration originally part of conventional configuration datastores have been explicitly separated and moved to operational state datastore, so does the system configuration. For non-NMDA client, the configuration retrieved by on the running datastore will be reduced without including system configuration and default configuration set by the server. Non-NMDA client also has no way to retrieve system configuration without new operations support on operational state datstore. 2.3. Feed System Configuration Back into Running Datastore As we know, the system configuration and default configuration originally part of conventional configuration datastores before NMDA is introduced have been separated and moved to operational state datastore. When further configuration is needed within the system configuration, e.g., configure IP address of the interface after such interface configuration (i.e.,system configuration) is auto-created, such auto-created interface configuration needs to set by the client since it doesn't exist in the conventional configuration datastore. The effect is the same as feed auto-created interface configuration into running datastore and make it become client set configuration. After the interface configuration is applied, it will be merged with the other existing system configuration in the operational state datastore. Wu & Feng Expires September 10, 2019 [Page 4] Internet-Draft NMDA Backwards-Compatibility March 2019 3. Solution 3.1. Client NMDA Support When a NMDA aware sever needs to support both NMDA client and non- NMDA clients, server NMDA support can be advertised to the client via capability identifier :yang-library:1.1 to the client. Client NMDA support should be indicated by protocol operations. If // operation is recieved from the client, the server should assume the client is Non-NMDA client. If / operation is recieved from the client, the server should assume the client is NMDA client. Editor-Note: There are three ways to Indicate client support on NMDA: 1. Define capability identifier for client NMDA support and advertising this capability identifier to the server; 2. Use new or old protocol operation to indicate client NMDA support; 3. Use whether module type is NMDA aware to indicate client NMDA support ; Either advertising capability identifier to the server or using module type to indicate client NMDA support adds server implementation complexity. We argue to use protocol operation to indicate whether the client support NMDA. 3.2. Default handling Behaviour With-default capability defined in [RFC6243] is designed for conventional configuration datatore. As described in [I-D.ietf- netconf-nmda-netconf], semantics for "with-defaults" in operations is the same as for , as described in section 4.5.2 of [RFC6243]. However when the NMDA is introduced, the default configuration is clearly separated from conventional configuration datastore, the semantics of "with-defaults" parameter have made a few changes. 3.2.1. Default-Handling Basic Modes A NMDA aware server still supports three basic modes defined in [RFC6243] for handling default data. In addition to 'report-all' Retrieval Mode, the 'report-all' basic mode should be also treated in the same way as 'explicit' basic model in case of NMDA since the default configuration has been moved to operational state datastore and therefore the NMDA aware server should not consider the default Wu & Feng Expires September 10, 2019 [Page 5] Internet-Draft NMDA Backwards-Compatibility March 2019 configuration is part of conventional configuration datastore unless it is explicitly set by the client. 3.2.1.1. 'report-all' Basic Mode Retrieval When the data is retrieved from a server using the 'report-all' basic mode, and the parameter is not present, data nodes MUST be reported if explicitly set by the client, even if they contain the schema default value. 3.2.1.2. 'report-all' and Behaviour For backwards compatibility consideration, the server consider the default data part of conventional configuration datastore. A valid 'create' operation attribute for a data node that has been set by a client to its schema default value MUST fail with a 'data-exists' error-tag. A valid 'delete' operation attribute for a data node that has been set by a client to its schema default value MUST succeed. 3.2.1.3. 'report-all' Behaviour If the 'with-defaults' capability is supported by the server, the 'report-all' basic mode, defined in section 3.2.1.1, is supported for operations that target conventional configuration datastores. A valid 'create' operation attribute for a data node that has been set by a client to its schema default value MUST succeed. A valid 'delete' operation attribute for a data node that has been set by a client to its schema default value MUST fail with a 'data-missing' error-tag. Since the default configuration doesn't exist in the conventional configuration datastore, the default configuration MUST be created without error being returned, irrespectively "with-defaults" parameter being set to basic-mode, trim or report-all. 3.2.2. get/get-config Operation For backwards compatibility consideration, when the basic mode is set to 'report-all' or 'with-defaults' capability parameter is set to report all, the NMDA aware server should return all the data based on filtering selection criteria including all the data from conventional configuration datastore and default configuration from operational state datastore. Wu & Feng Expires September 10, 2019 [Page 6] Internet-Draft NMDA Backwards-Compatibility March 2019 3.2.3. get-data Operation When the basic mode is set to report-all or 'with-defaults' capability parameter is set to report all, the NMDA aware server should return all the data based on filtering selection criteria including all the data from conventional configuration datastore, but not include default configuration from operational state datastore unless they are explicitly set by the client. 3.3. Protocol Operation Clarification 3.3.1. As described in [RFC6241], the NETCONF operation returns the contents of together with the operational state. If the client supports NMDA and sends request to the NMDA aware server, the server should assume the client is non-NMDA client and retrieve specified configuration from running configuration and system configuration from operational state datastore and return it together with the system configuration to the client in . If the client doesn't support NMDA and sends request to the NMDA aware server, the server should retrieve running configuration and system configuration from operational state datastore and return the same results as it retrieves from non-NMDA aware server. For default handling basic modes, please refer to Section 3.2.2. 3.3.2. As described in [RFC6241], the NETCONF operation can be used to retrieve all or part of a specified configuration datastore. If the client supports NMDA and sends request to the NMDA aware Server, the server should assume the client is non-NMDA client and retrieve specified configuration from together with the system configuration. If the client doesn't support NMDA and send request to the NMDA aware server, the server should retrieve configuration together with the system configuration and return the same result as it retrieves from non-NMDA aware server. For default handling basic modes, please refer to Section 3.2.2. Wu & Feng Expires September 10, 2019 [Page 7] Internet-Draft NMDA Backwards-Compatibility March 2019 3.3.3. As described in [RFC6241], the NETCONF operation can be used to load all or part of a specified configuration to the specified target configuration datastore. If the client sends request to the NMDA aware server and wants to have further configuration based on the system configuration,(e.g.,configure IP address within auto-created physical interface configuration), the server should create IP address configuration corresponding to specific physical interface without error to be returned to the client as long as IP address configuration is validated. The effect is the same as the physical interface has already been part of conventional configuration datastore. If the system configuration is set by the client sending operation request, the error should be returned as if the system configuration has already been part of conventional configuration datastore. For default handling basic modes, please refer to Section 3.2.1.2. 3.3.4. As described in [I-D.ietf-netconf-nmda-netconf], the operation retrieves data from a specific NMDA datastore,similar to NETCONF's operation defined in [RFC6241]. If the client sends request with specified target configuration datastore set to the running datastore, the server should assume the client is NMDA client and retrieve specified configuration from without system configuration set by the server since the system configuration is separated from conventional configuration datastore. For default handling basic modes, please refer to Section 3.2.3. 3.3.5. As described in [I-D.ietf-netconf-nmda-netconf], the NETCONF operation can be used to load all or part of a specified configuration to the specified target configuration datastore. For the NMDA client sending operation request with specified target configuration datastore set to the configuration datastore such as running datastore, since the system configuration is separated from conventional configuration datastore, if the NMDA client wants to use system configuration or configure other parameter (e.g., IP address) within system configuration(e.g., auto-created Wu & Feng Expires September 10, 2019 [Page 8] Internet-Draft NMDA Backwards-Compatibility March 2019 interface configuration), Explicitly creating the system configuration by the client MUST be allowed without error being returned. 4. IANA Considerations There is no IANA action in this document. 5. Security Considerations This document does not introduce any security vulnerability besides one defined in [RFC6241] [I-D.ietf-netconf-nmda-netconf]. 6. Acknowledgements Thanks Robert Wilton,Guangying Zheng,Shouchuan Yang,Dan Qu, Ye Niu to discuss NMDA comability issues on existing protocol operation and provide important input to this document. 7. Contributors Michael Wang Huawei Technologies, Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China Email: wangzitao@huawei.com 8. References 8.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, . [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, . Wu & Feng Expires September 10, 2019 [Page 9] Internet-Draft NMDA Backwards-Compatibility March 2019 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . 8.2. Informative References [I-D.ietf-netconf-nmda-netconf] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "NETCONF Extensions to Support the Network Management Datastore Architecture", draft-ietf-netconf- nmda-netconf-08 (work in progress), October 2018. Authors' Addresses Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Chong Feng Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: frank.fengchong@huawei.com Wu & Feng Expires September 10, 2019 [Page 10]