NETCONF Working Group Q. Wu
Internet-Draft C. Feng
Intended status: Standards Track Huawei
Expires: June 22, 2019 December 19, 2018
NMDA Backwards-Compatibility with Legacy Devices
draft-wu-netconf-nmda-compatibility-00
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 a server
needs to support both NMDA client and non-NMDA clients, it is not
clear whether a NMDA compliant 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 June 22, 2019.
Copyright Notice
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
Wu & Feng Expires June 22, 2019 [Page 1]
Internet-Draft NMDA Backwards-Compatibility December 2018
(https://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
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Client Support on NMDA . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 6
3.3. Protocol Operation Clarification . . . . . . . . . . . . 6
3.3.1. <get> . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. <get-config> . . . . . . . . . . . . . . . . . . . . 7
3.3.3. <edit-config> . . . . . . . . . . . . . . . . . . . . 7
3.3.4. <get-data> . . . . . . . . . . . . . . . . . . . . . 8
3.3.5. <edit-data> . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 server needs to support both NMDA client and non-NMDA
clients, it is not clear whether a NMDA compliant server can return
Wu & Feng Expires June 22, 2019 [Page 2]
Internet-Draft NMDA Backwards-Compatibility December 2018
the same results 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 separated and moved to operational state
datastore. Also it is not clear whether the server should maintain
backwards-compatibility when the server is upgraded from non-NMDA-
aware server to NMDA compliant 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
changes behaviour or semantics when they are exchanged between the
client and the 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.
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
The following terms are defined in this document:
Server Backwards-Compatibility: The client can use the same
protocol operation to get the same results from both NMDA
compliant server and Non NMDA server.
Wu & Feng Expires June 22, 2019 [Page 3]
Internet-Draft NMDA Backwards-Compatibility December 2018
2. Problems
2.1. NMDA Client vs Non-NMDA Client
When a server is upgraded to NMDA compliant server and needs to
support both NMDA client and non-NMDA clients, there is no way for
the server to know whether the client supports NMDA.
2.2. NETCONF Server Back-Compatibility
When a server is upgraded to NMDA compliant server and needs to
support both NMDA client and non-NMDA clients, without NETCONF server
backwards-comability, a NMDA compliant server can return the results
with <rpc-reply> to non-NMDA clients different from non-NMDA-aware
server does. Since the system configuration and default
configuration originally part of conventional configuration
datastores have been separated and moved to operational state
datastore. 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 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. The
effect is the same as feeding 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 current system configuration in the operational state datastore.
3. Solution
3.1. Client Support on NMDA
When a sever needs to support both NMDA client and non-NMDA clients,
server support on NMDA can be advertised to the client via capability
identifier :yang-library:1.1 to the client. Client support on NMDA
can 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-
Wu & Feng Expires June 22, 2019 [Page 4]
Internet-Draft NMDA Backwards-Compatibility December 2018
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 support on NMDA and
advertising this capability identifier to the server;
2. Use new or old protocol operation to indicate client support on
NMDA;
3. Use whether module type is NMDA compliant to indicate client
support on NMDA;
Either advertising capability identifier to the server or using
module type to indicate client support on NMDA 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. When NMDA is introduced, [I-
D.ietf-netconf-nmda-netconf] defines with-operational-defaults
capability and applies "with-defaults" parameter to <get-data>
operations that target <operational>. However when default
configuration is separated from conventional configuration datastore,
the behaviour and semantics of "with-defaults" parameter also make a
few changes.
3.2.1. Default-Handling Basic Modes
A server still supports three basic modes defined in [RFC6243] for
handling default data. The' report-all' basic mode should be treated
in the same way as 'explicit' basic model since default configuration
has been moved to operational state datastore and therefore the
server should not consider the default 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 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.
Wu & Feng Expires June 22, 2019 [Page 5]
Internet-Draft NMDA Backwards-Compatibility December 2018
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
server 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 server 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 server to its schema default value MUST succeed. A valid
'delete' operation attribute for a data node that has been set by a
server to its schema default value MUST fail with a 'data-missing'
error-tag.
3.2.2. get/get-config Operation
For backwards compatibility consideration, when the basic mode is set
to 'report-all' or "with-defaults" parameter is set to report all,
the 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.
3.2.3. get-data Operation
When the basic mode is set to report-all or "with-defaults" parameter
is set to report all, the 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 both the client and the server support NMDA and the client sends
<get> request, the server should assume the client is non-NMDA client
Wu & Feng Expires June 22, 2019 [Page 6]
Internet-Draft NMDA Backwards-Compatibility December 2018
and retrieve running configuration and device state from operational
state datastore and return it together with the system configuration
to the client in <rpc-reply>.
If the server supports NMDA and the client doesn't support NMDA, when
the client sends <get> request, the server should retrieve running
configuration and device state 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 both the client and the server support NMDA and the client sends
<get-config> request, the server should assume the client is non-NMDA
client and retrieve specified configuration from <running> together
with system configuration.
If the server supports NMDA and the client doesn't support NMDA, when
the client send <get-config> request, the server should retrieve
specified configuration from <running> together with 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.
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 wants to have further configuration based on system
configuration,(e.g.,configure IP address within auto-created physical
interface configuration),the server should create corresponding
physical interface with IP address configuration without error to be
returned to the client as long as IP address configuration is valid.
The effect is the same as the physical interface has already been
part of conventional configuration datastore. If the system
configuration is set by client sending <edit-config>operation
request, the error should be returned as if the system configuration
is part of conventional configuration datastore.
For default handling basic modes, please refer to Section 3.2.1.2.
Wu & Feng Expires June 22, 2019 [Page 7]
Internet-Draft NMDA Backwards-Compatibility December 2018
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 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
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 NMDA client sending <edit-data> operation request with specified
target configuration datastore set to configuration datastore such as
running datastore, since system configuration is separated from
conventional configuration datastore, if the client wants to use
system configuration or configure other parameter(e.g., IP address)
within system configuration(e.g., auto-created interface
configuration), Explicitly creating system configuration by the
client MUST be allowed without error being returned. For default
configuration, since it 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.
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.
Wu & Feng Expires June 22, 2019 [Page 8]
Internet-Draft NMDA Backwards-Compatibility December 2018
7. References
7.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>.
[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>.
7.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
Wu & Feng Expires June 22, 2019 [Page 9]
Internet-Draft NMDA Backwards-Compatibility December 2018
Chong Feng
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: frank.fengchong@huawei.com
Wu & Feng Expires June 22, 2019 [Page 10]