[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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 <rpc-reply> 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.  <get> . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.2.  <get-config>  . . . . . . . . . . . . . . . . . . . .   7
       3.3.3.  <edit-config> . . . . . . . . . . . . . . . . . . . .   8
       3.3.4.  <get-data>  . . . . . . . . . . . . . . . . . . . . .   8
       3.3.5.  <edit-data> . . . . . . . . . . . . . . . . . . . . .   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.,<get-data>,<edit-data> 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 <rpc-reply> 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 <rpc-reply> 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
   <get-config> 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 <get>/<get-
   config>/<edit-config> operation is recieved from the client, the
   server should assume the client is Non-NMDA client.  If <get-
   data>/<edit-data> 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 <edit-data>
   operations is the same as for <edit-config>, 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 <with-defaults> 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' <edit-config> and <copy-config> 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' <edit-data> 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
   <edit-data> 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.  <get>

   As described in [RFC6241], the NETCONF <get> operation returns the
   contents of <running> together with the operational state.

   If the client supports NMDA and sends <get> 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 <rpc-reply>.

   If the client doesn't support NMDA and sends <get> 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.  <get-config>

   As described in [RFC6241], the NETCONF <get-config> operation can be
   used to retrieve all or part of a specified configuration datastore.

   If the client supports NMDA and sends <get-config> request to the
   NMDA aware Server, the server should assume the client is non-NMDA
   client and retrieve specified configuration from <running> together
   with the system configuration.

   If the client doesn't support NMDA and send <get-config> request to
   the NMDA aware server, the server should retrieve <running>
   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.  <edit-config>

   As described in [RFC6241], the NETCONF <edit-config> operation can be
   used to load all or part of a specified configuration to the
   specified target configuration datastore.

   If the client sends <edit-config> 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
   <edit-config>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.  <get-data>

   As described in [I-D.ietf-netconf-nmda-netconf], the <get-data>
   operation retrieves data from a specific NMDA datastore,similar to
   NETCONF's <get-config> operation defined in [RFC6241].

   If the client sends <get-data> 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 <running> 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.  <edit-data>

   As described in [I-D.ietf-netconf-nmda-netconf], the NETCONF <edit-
   data> operation can be used to load all or part of a specified
   configuration to the specified target configuration datastore.

   For the NMDA client sending <edit-data> 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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.





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,
              <https://www.rfc-editor.org/info/rfc8342>.

   [RFC8407]  Bierman, A., "Guidelines for Authors and Reviewers of
              Documents Containing YANG Data Models", BCP 216, RFC 8407,
              DOI 10.17487/RFC8407, October 2018,
              <https://www.rfc-editor.org/info/rfc8407>.

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/