| Internet-Draft | NETCONF Private Candidates | October 2022 |
| Cumming & Wills | Expires 24 April 2023 | [Page] |
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined.¶
This document addresses two specific aspects: The interaction with a private candidate over the NETCONF protocol and the methods to identify and resolve conflicts between clients.¶
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 24 April 2023.¶
Copyright (c) 2022 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
NETCONF [RFC6241] provides a mechanism for one or more
clients to make configuration changes to a device running as a NETCONF
server. Each NETCONF client has the ability to make one or more
configuration change to the servers shared candidate configuration.
As the name shared candidate suggests, all clients have access to the same candidate
configuration. This means that multiple clients may make changes to the shared
candidate prior to the configuration being committed. This behaviour may be
undesirable as one client may unwittingly commit the configuration changes made
by another client.
NETCONF provides a way to mitigate this behaviour by allowing clients
to place a lock on the shared candidate. The placing of this lock means that
no other client may make any changes until that lock is released. This behaviour
is, in many situations, also undesirable.
Many network devices already support private candidates configurations,
where a user (machine or otherwise) is able to edit a personal copy of a devices
configuration without blocking other users from doing so.
This document details the extensions to the NETCONF protocol in order to support
the use of private candidates.¶
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.¶
A session specific datastore is a configuration datastore that, unlike the candidate and running configuration datastores which have only one per system, is bound to the specific NETCONF session.¶
The candidate configuration datastore defined in [RFC6241] is referenced as the shared candidate configuration in this document.¶
A private candidate configuration is a session specific candidate configuration datastore.¶
The specific NETCONF session (and user) that created the private candidate configuration is the only session (user) that has access to it over NETCONF. Devices may expose this to other users through other interfaces but this is out of scope for this document.¶
The private candidate configuration contains a copy of the running configuration when it is created (in the same way as a branch does in a source control management system). Any changes made to it, for example, through the use of the <edit-config> operation, are made in this private candidate configuration. Obtaining this private candidate over NETCONF will display the entire configuration, including all changes made to it. Performing a <commit> operation will merge the changes from the private candidate into the running configuration (the same as a merge in source code management systems). The issue of <discard-changes> operation will revert the private candidate to the branch's initial state.¶
All changes made to this private candidate configuration are held separately from any other candidate configuration changes, whether made by other users to the shared candidate or any other private candidate, and are not visible to or accessible by anyone else.¶
The following sections describe some limitations and mitigation factors in more detail for the use of the shared candidate configuration during multi-client configuration over NETCONF.¶
Consider the following scenario:¶
In this situation, both client 1 and client 2 configurations will be committed by client 2. In a machine-to-machine environment client 2 may not have been aware of the change to item A and, if they had been aware, may have decided not to proceed.¶
In order to resolve unintended deployment of alternate users configuration changes as described above NETCONF provides the ability to lock a datastore in order to restrict other users from editing and committed changes.¶
This does resolve the specific issue above, however, it introduces another issue. Whilst one of the clients holds a lock, no other client may edit the configuration. This will result in the client failing and having to retry. Whilst this may be a desirable consequence when two clients are editing the same section of the configuration, where they are editing different sections this behaviour may hold up valid operational activity.¶
Additionally, a lock placed on the shared candidate configuration must also lock the running configuration, otherwise changes committed directly into the running datastore may conflict.¶
The use of the running configuration datastore as the target for all configuration changes does not resolve any issues regarding blocking of system access in the case a lock is taken, nor does it provide a solution for multiple NETCONF clients as each configuration change is applied immediately and the client has no knowledge of the current configuration at the point in time that they commenced the editing activity nor at the point they commit the activity.¶
[RFC5717] describes a partial lock mechanism that can be used on specific portions of the shared candidate datastore.¶
Partial locking does not solve the issues of staging a set of configuration changes such that only those changes get committed in a commit operation, nor does it solve the issue of multiple clients editing the same parts of the configuration at the same time.¶
Partial locking additionally requires that the client is aware of any interdependencies within the servers YANG models in order to lock all parts of the tree.¶
This section captures the key aspects considered when defining the private candidate solution.¶
A private candidate datastore is created when the first RPC that requires access to it is sent to the server. This could be, for example, an <edit-config>.¶
When the private candidate is created is copy of the running configuration is made and stored in it. This can be considered the same as creating a branch in a source code repository.¶
Multiple NETCONF operations may be performed on the private candidate in order to stage changes ready for a commit.¶
A key consideration is how and when the private candidate is updated by changes made to the running configuration whilst the private candidate (a separate branch) exists.¶
The following options have been considered. It is worth noting that both approaches may be supported, however, the server will need to advertise which approach is being used in a capability.¶
The private candidate is treated as a separate branch and changes made to the running configuration are not placed into the private candidate datastore except in one of the following situations:¶
This approach is similar to the standard approach for source code management systems.¶
In this model of operation it is possible for the private candidate configuration to become significantly out of sync with the running configuration should the private candidate be open for a long time without an operation being sent that causes a resync (rebase in source code control terminology).¶
A <compare> operation may be performed against the initial starting point (head) of the private candidates branch or against the running configuration.¶
Conflict detection and resolution is discussed later in this document.¶
The private candidate is treated as a separate branch, however, changes made to the running configuration and reflected in the private candidate configuration as they occur.¶
This is equivalent to the private candidate branch being routinely rebased onto the running configuration every time a change is made in the running configuration.¶
In this model of operation the following should be considered:¶
Conflict detection and resolution is discussed later in this document.¶
The most challenging aspect of private candidates is when two clients are modifying the same part of the configuration tree.¶
A conflict occurs when a private candidate configuration is committed to the running configuration datastore and the specific nodes in the tree to be modified have been changed in the running configuration after the private candidate was created.¶
If using the continual rebase mode, a conflict may also occur if a specific node (or set of nodes) in the modified private candidate configuration are updated by another client (or user) in the running configuration.¶
Conflicts occur when the intent of the NETCONF client may have been different had it had a different starting point. When a conflict occurs it is useful that the client be given the opportunity to re-evaluate its intent. Examples of conflicts include:¶
When a conflict is detected the <commit> MUST fail with a specific error message and the client SHOULD be informed which conflicts caused the failure.¶
There are two ways conflicts could be reported:¶
There are different options for resolving conflicts:¶
NETCONF sessions are able to utilize the concept of private candidates in order to streamline network operations, particularly for machine-to-machine communication.¶
Using this approach clients may improve their performance and reduce the likelihood of blocking other clients from continuing with valid operational activities.¶
One or more private candidates may exist at any one time, however, a private candidate MUST:¶
Additionally, the choice of using a shared candidate configuration datastore or a private candidate configuration datastore SHOULD be for the entire duration of the NETCONF session¶
The options provided below are not intended to be mutually exclusive and multiple options may be supported by the server.¶
When a NETCONF client connects with a server it sends a list of client capabilities.¶
In order to enable private candidate mode for the duration of the NETCONF client session the NETCONF client sends the following capability:¶
urn:ietf:netconf:pc
¶
The ability for the NETCONF server to support private candidates is optional and SHOULD be signalled in the NETCONF servers capabilities using the same capability string¶
When a server receives the client capability its mode of operation will be set to private candidates for the duration of the NETCONF session.¶
When a client makes a configuration change the <edit-config> RPC will target the candidate datastore as it does in shared candidate configuration mode.¶
All RPCs will operate in an identical manner to when operating in shared candidate configuration mode but all data sent between the client and the candidate datastore will use that sessions private candidate configuration.¶
Using this method, the use of private candidates can be made available to NMDA and non-NMDA capable servers.¶
No protocol extensions are required for the transitioning of candidates between the shared mode and the private mode and no extensions are required for the any other RPC (including <lock>)¶
The private candidate configuration datastore could be exposed as its own datastore similar to other NMDA [RFC8342] capable datastores. This datastore is called private-candidate.¶
All NMDA operations that support NMDA datastores SHOULD support the private-candidate datastore.¶
Any non-NMDA aware NETCONF operations that take a source or target (destination) may be extended to accept the new datastore.¶
The ability for the NETCONF server to support private candidates is optional and SHOULD be signalled in NMDA supporting servers as a datastore and in all NETCONF servers capabilities using the capability string:¶
urn:ietf:netconf:pc
¶
The first datastore referenced (either candidate or private-candidate) in any NETCONF operation will define which mode that NETCONF session will operate in for its duration. As an example, performing a <get-data> operation on the private-candidate datastore will switch the session into private candidate configuration mode and subsequent <edit-config> operations that reference the candidate configuration datastore will fail.¶
This section mentions a small number of operations whose behaviour is needs a special mention, other operations to be updated are detailed in the appendix.¶
The new <update> operation is provided in order to trigger the private-candidate configuration datastore to be updated (rebased in source code management terminology) with the changes from the running configuration.¶
The <edit-config> operation is updated to accept private-candidate as valid input to the <target> field.¶
The use of <edit-config> will create a private candidate configuration if one does not already exist for that NETCONF session.¶
Sending an <edit-config> request to private-candidate after one has been sent to the shared candidate datastore in the same session will fail (and visa-versa).¶
Multiple <edit-config> requests may be sent to the private-candidate datastore in a single session.¶
Performing a <lock> on the private-candidate datastore is a valid operation and will also lock the running configuration.¶
Taking a lock on this datastore will stop other session from committing any configuration changes, regardless of the datastore.¶
Other NETCONF sessions are still able to create a new private-candidate configuration datastore.¶
Performing an <unlock> on the private-candidate datastore is a valid operation. This will also unlock the running configuration. Unlocking the private-candidate datastore allows other sessions to resume <commit> functions.¶
Changes in the private-candidate datastore are not lost when the lock is released.¶
Attempting to perform a <lock> or <unlock> on any other datastore while the private-candidate datastore is locked will fail. Attempting to perform a <lock> or <unlock> on any other sessions private-candidate datastore will also fail.¶
Performing a <compare> [RFC9144] with the private-candidate datastore as either the <source> or <target> is a valid operation.¶
If <compare> is performed prior to a private candidate configuration being created, one will be created at that point.¶
The <compare> operation will be extended to allow the operation to reference the start of the private candidate's branch (head).¶
This memo includes no request to IANA.¶
This document should not affect the security of the Internet.¶
The <get> operation does not accept a datastore value and therefore this document is not applicable to this operation. The use of the get operation will not create a private candidate configuration.¶
The <get-config> operation is updated to accept private-candidate as valid input to the <source> field.¶
The use of <get-config> will create a private candidate configuration if one does not already exist for that NETCONF session.¶
The <get-data> operation accepts the private-candidate as a valid datastore.¶
The use of <get-data> will create a private candidate configuration if one does not already exist for that NETCONF session.¶
The <copy-config> operation is updated to accept private-candidate as a valid input to the <source> or <target> fields.¶
The <delete-config> operation is updated to accept private-candidate as a valid input to the <target> field.¶
The authors would like to thank Jan Lindblad, Jason Sterne and Rob Wilton for their contributions and reviews.¶