Skip to main content

NETCONF Private Candidates
draft-jgc-netconf-privcand-00

Document Type Active Internet-Draft (individual)
Authors James Cumming , Robert Wills
Last updated 2022-10-21
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jgc-netconf-privcand-00
Internet Engineering Task Force                              JG. Cumming
Internet-Draft                                                     Nokia
Intended status: Standards Track                                R. Wills
Expires: 24 April 2023                                     Cisco Systems
                                                         21 October 2022

                       NETCONF Private Candidates
                     draft-jgc-netconf-privcand-00

Abstract

   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.

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 24 April 2023.

Copyright Notice

   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

Cumming & Wills           Expires 24 April 2023                 [Page 1]
Internet-Draft         NETCONF Private Candidates           October 2022

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Definitions and terminology . . . . . . . . . . . . . . . . .   3
     2.1.  Session specific datastore  . . . . . . . . . . . . . . .   3
     2.2.  Shared candidate configuration  . . . . . . . . . . . . .   4
     2.3.  Private candidate configuration . . . . . . . . . . . . .   4
   3.  Limitations using the shared candidate configuration for
           multiple clients  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Issues  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Unintended deployment of alternate users configuration
               changes . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Current mitigation strategies . . . . . . . . . . . . . .   5
       3.2.1.  Locking the shared candidate configuration
               datastore . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Always use the running configuration datastore  . . .   5
       3.2.3.  Fine-grained locking  . . . . . . . . . . . . . . . .   5
   4.  Key choices influencing the solution  . . . . . . . . . . . .   6
     4.1.  When is a private candidate created . . . . . . . . . . .   6
     4.2.  Interaction between running and private-candidate . . . .   6
       4.2.1.  Independent private candidate branch (Static branch
               mode) . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.2.  Continually updating private candidate (Continuous
               rebase mode)  . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Defining and detecting conflicts  . . . . . . . . . . . .   8
     4.4.  Reporting unresolved conflicts to the user  . . . . . . .   8
     4.5.  Resolving conflicts . . . . . . . . . . . . . . . . . . .   9
   5.  Proposed solutions for using private candidates configurations
           with NETCONF  . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Client capability declaration . . . . . . . . . . . . . .   9
     5.2.  Private candidate datastore . . . . . . . . . . . . . . .  10
       5.2.1.  New and existing NETCONF operation interactions . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  NETCONF operations impacted  . . . . . . . . . . . .  13
     A.1.  <get> . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     A.2.  <get-config>  . . . . . . . . . . . . . . . . . . . . . .  13
     A.3.  <get-data>  . . . . . . . . . . . . . . . . . . . . . . .  13
     A.4.  <copy-config> . . . . . . . . . . . . . . . . . . . . . .  14
     A.5.  <delete-config> . . . . . . . . . . . . . . . . . . . . .  14

Cumming & Wills           Expires 24 April 2023                 [Page 2]
Internet-Draft         NETCONF Private Candidates           October 2022

   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   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.

1.1.  Requirements Language

   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.

2.  Definitions and terminology

2.1.  Session specific datastore

   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.

Cumming & Wills           Expires 24 April 2023                 [Page 3]
Internet-Draft         NETCONF Private Candidates           October 2022

2.2.  Shared candidate configuration

   The candidate configuration datastore defined in [RFC6241] is
   referenced as the shared candidate configuration in this document.

2.3.  Private candidate configuration

   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.

3.  Limitations using the shared candidate configuration for multiple
    clients

   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.

3.1.  Issues

3.1.1.  Unintended deployment of alternate users configuration changes

   Consider the following scenario:

   1.  Client 1 modifies item A in the shared candidate configuration

Cumming & Wills           Expires 24 April 2023                 [Page 4]
Internet-Draft         NETCONF Private Candidates           October 2022

   2.  Client 2 then modifies item B in the shared candidate
       configuration

   3.  Client 2 then issues a <commit> RPC

   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.

3.2.  Current mitigation strategies

3.2.1.  Locking the shared candidate configuration datastore

   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.

3.2.2.  Always use the running configuration datastore

   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.

3.2.3.  Fine-grained locking

   [RFC5717] describes a partial lock mechanism that can be used on
   specific portions of the shared candidate datastore.

Cumming & Wills           Expires 24 April 2023                 [Page 5]
Internet-Draft         NETCONF Private Candidates           October 2022

   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.

4.  Key choices influencing the solution

   This section captures the key aspects considered when defining the
   private candidate solution.

4.1.  When is a private candidate created

   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.

4.2.  Interaction between running and private-candidate

   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.

4.2.1.  Independent private candidate branch (Static branch mode)

   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:

   *  The client requests that the private candidate be refreshed using
      a new <update> operation

   *  <commit> is issued

Cumming & Wills           Expires 24 April 2023                 [Page 6]
Internet-Draft         NETCONF Private Candidates           October 2022

   *  <discard-changes> operation is sent (TBD).

   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.

4.2.2.  Continually updating private candidate (Continuous rebase mode)

   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:

   *  Because the private candidate is automatically re-synchronized
      (rebased) with the running configuration each time a change is
      made in the running configuration, the NETCONF session is unaware
      that their private candidate configuration has changed unless they
      perform one of the get operations on the private candidate and
      analyse it for changes.

   *  A <compare> operation may be performed against the initial
      starting point (head) of the private candidates branch or against
      the running configuration but these will both report the same
      results as the starting point is continually reset.

   *  The output of the <compare> operation may not match the set of
      changes made to the session's private candidate but may include
      different output due to the changes in the running configuration
      made by other sessions.

Cumming & Wills           Expires 24 April 2023                 [Page 7]
Internet-Draft         NETCONF Private Candidates           October 2022

   *  A conflict may occur in the automatic update process pushing
      changes from the running configuration into the private candidate.

   Conflict detection and resolution is discussed later in this
   document.

4.3.  Defining and detecting conflicts

   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:

   *  An interface has been deleted in the running configuration that
      existed when the private candidate was created.  A change to a
      child node of this specific interface is made in the private
      candidate using the default merge operation would, instead of
      changing the child node, both recreate the interface and then set
      the child node.

   *  A leaf has been modified in the running configuration from the
      value that it had when the private candidate was created.  The
      private candidate configuration changes that leaf to another
      value.

4.4.  Reporting unresolved conflicts to the user

   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:

   *  Using an attribute on the data node(s) that have conflicts.

Cumming & Wills           Expires 24 April 2023                 [Page 8]
Internet-Draft         NETCONF Private Candidates           October 2022

   *  As a list of flat paths (similar to how errors from a commit
      operation are reported).

4.5.  Resolving conflicts

   There are different options for resolving conflicts:

   *  The user could be required to explicitly resolve all conflicts by
      performing further operations to the private candidate.

   *  The private candidate could take precedence (equivalent to a
      <force> option).

   *  The running config could take precedence (for example, by
      cancelling changes in the private candidate if they conflict with
      changes already made to the running config).

5.  Proposed solutions for using private candidates configurations with
    NETCONF

   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:

   *  Be accessible by one client only

   *  Be visible by one client only

   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.

5.1.  Client capability declaration

   When a NETCONF client connects with a server it sends a list of
   client capabilities.

Cumming & Wills           Expires 24 April 2023                 [Page 9]
Internet-Draft         NETCONF Private Candidates           October 2022

   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>)

5.2.  Private candidate datastore

   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

Cumming & Wills           Expires 24 April 2023                [Page 10]
Internet-Draft         NETCONF Private Candidates           October 2022

   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.

5.2.1.  New and existing NETCONF operation interactions

   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.

5.2.1.1.  <update>

   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.

5.2.1.2.  <edit-config>

   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.

5.2.1.3.  <lock> and <unlock>

   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.

Cumming & Wills           Expires 24 April 2023                [Page 11]
Internet-Draft         NETCONF Private Candidates           October 2022

   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.

5.2.1.4.  <compare>

   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).

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   This document should not affect the security of the Internet.

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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Cumming & Wills           Expires 24 April 2023                [Page 12]
Internet-Draft         NETCONF Private Candidates           October 2022

   [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>.

   [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>.

   [RFC9144]  Clemm, A., Qu, Y., Tantsura, J., and A. Bierman,
              "Comparison of Network Management Datastore Architecture
              (NMDA) Datastores", RFC 9144, DOI 10.17487/RFC9144,
              December 2021, <https://www.rfc-editor.org/info/rfc9144>.

   [RFC5717]  Lengyel, B. and M. Bjorklund, "Partial Lock Remote
              Procedure Call (RPC) for NETCONF", RFC 5717,
              DOI 10.17487/RFC5717, December 2009,
              <https://www.rfc-editor.org/info/rfc5717>.

8.2.  Informative References

Appendix A.  NETCONF operations impacted

A.1.  <get>

   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.

A.2.  <get-config>

   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.

A.3.  <get-data>

   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.

Cumming & Wills           Expires 24 April 2023                [Page 13]
Internet-Draft         NETCONF Private Candidates           October 2022

A.4.  <copy-config>

   The <copy-config> operation is updated to accept private-candidate as
   a valid input to the <source> or <target> fields.

A.5.  <delete-config>

   The <delete-config> operation is updated to accept private-candidate
   as a valid input to the <target> field.

Contributors

   The authors would like to thank Jan Lindblad, Jason Sterne and Rob
   Wilton for their contributions and reviews.

Authors' Addresses

   James Cumming
   Nokia
   Email: james.cumming@nokia.com

   Robert Wills
   Cisco Systems
   Email: rowills@cisco.com

Cumming & Wills           Expires 24 April 2023                [Page 14]