[Netconf] :candidate, :writable-running and RESTCONF edits

"Jonathan Hansford" <jonathan@hansfords.net> Thu, 22 December 2016 12:12 UTC

Return-Path: <jonathan@hansfords.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2E5129959 for <netconf@ietfa.amsl.com>; Thu, 22 Dec 2016 04:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYWeWq0-vCCC for <netconf@ietfa.amsl.com>; Thu, 22 Dec 2016 04:12:32 -0800 (PST)
Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201A5129952 for <netconf@ietf.org>; Thu, 22 Dec 2016 04:12:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e79LZYV8B4bSSWVlr/P+J2yepg7RBe+L9VijyZLhV3Q=; b=oWODwsG281BBv5D3vhoqqjC672 x09+T/pyIYcatgB7HxmDN6d+yVdfm0idGYGDLVXIWFDObq0oEdNG2lYivYkJDJLKk/GfTtHRbShku McEbErmkxnJGf79XYmH86ATYyf6GbbtedfyzLGxQqtmNCugdXGqW6S1CZICkL2fOjjq4FAhd7N6EZ 5Z7xvSFuiSzzQVoD4xvSqYDRRc4wLXLpfxtTuOlb8cKAhruf9C+w8OgMf/8F3LDpuZL5CrCvyDGwA Lpx04bCJ/8VPA9rpRvvtra+GgFqXt7NNnVmf44BaCAH5XYz+4JaIXxKpl0TERdgxAnhpcjhSgilkv Xvzro02Q==;
Received: from hansfords.plus.com ([84.92.116.209]:39884 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from <jonathan@hansfords.net>) id 1cK2EW-001IQy-TQ for netconf@ietf.org; Thu, 22 Dec 2016 12:12:29 +0000
From: Jonathan Hansford <jonathan@hansfords.net>
To: 'Netconf' <netconf@ietf.org>
Date: Thu, 22 Dec 2016 12:12:30 -0000
Message-ID: <016301d25c4c$ab7754c0$0265fe40$@hansfords.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01D25C4C.AB79C5C0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdJb+2dYNiDGrFcrRNO/H9B8RvAZTg==
Content-Language: en-gb
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0tTkecbhi1eHmcrZNUvKZIK-zgs>
Subject: [Netconf] :candidate, :writable-running and RESTCONF edits
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2016 12:12:36 -0000

draft-ietf-netconf-restconf-18, page 13 states "If the NETCONF server
supports :writable-running, all edits to configuration nodes in
{+restconf}/data are performed in the running configuration datastore.
Otherwise, if the device supports :candidate, all edits to configuration
nodes in {+restconf}/data are performed in the candidate configuration
datastore."

 

I have been reading through the mail archive on the relationship between
:writable-running and :candidate (see excerpts below) and my understanding
is as follows:

 

For a NETCONF client to be able to update the configuration of a server, the
server must support :writable-running and/or :candidate.

A NETCONF server can support both :writable-running and :candidate, indeed
there appear to be some in the wild that do, but there is a measure of
unease about this, with the suggestion by some the combination should be
deprecated.

 

Based on the text from the draft (above) it would appear that, should a
NETCONF server support both capabilities, all RESTCONF edits should be
performed in the running configuration datastore. Is that considered the
lesser of two evils, the other being that all RESTCONF edits should be
performed in the candidate configuration datastore, or was the possibility
overlooked? My gut feel is that it would be safer to use the candidate
configuration datastore and that the two paragraphs in the draft should be
the other way around, i.e. "If the NETCONF server supports :candidate, all
edits to configuration nodes in {+restconf}/data are performed in the
candidate configuration datastore. Otherwise, if the device supports
:writable-running, all edits to configuration nodes in {+restconf}/data are
performed in the running configuration datastore."

 

Jonathan

 

---

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg00005.html> "Re:
NETCONF modelled in UML" Andy Bierman (Jun 01 2004) states: "We . thought we
should keep the #candidate and #writable-running capabilities independent.
maybe we should make these capabilities mutually exclusive."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03915.html>
"[Netconf] partial-lock feedback" Phil Shafer (Nov 13 2008) states: "There's
some logic that says the intersection of boxes with :writable-running and
:candidate is (or should be) nil."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03918.html> "Re:
[Netconf] partial-lock feedback" Balazs Lengyel (Nov 17 2008) states: "It is
not stated anywhere that you can't have candidate and writable-running
together."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03960.html>
"[Netconf] :candidate vs :writable-running" Tomasz Mikolajczyk (Nov 28
2008), quotes from http://www.netconfcentral.com/netconf_docs that: "Agent
platforms which support the :candidate capability usually do not also
support the :writable-running  capability, since mixing direct edits to
<running/>  would defeat the purpose of using this scratchpad database to
collect and validate changes before applying them." This text persists,
though "Agent platforms" has been replaced with "Server platforms".

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03985.html> "Re:
[Netconf] :candidate vs :writable-running" Martin Bjorklund (Dec 01 2008)
states: "I don't know about others, but I do know that many (most?) of our
customers have both :candidate and :writable-running.  By having both, you
give the choice to the client application - either make sure you're alone
and work with the candidate or edit running directly. Some changes might be
easier to just edit to running."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg03995.html> "Re:
[Netconf] lock/unlock on candidate" Martin Bjorklund (Dec 01 2008) states:
"This is only an issue if the box supports :candidate and
:writable-running."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04436.html> "Re:
[Netconf] issue with draft-ietf-netconf-partial-lock-07.txt" Kent Watsen
(Mar 18 2009) states: "can devices advertize both :candidate and
:writable-running?  - aren't those capabilities mutually exclusive?"

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04437.html> "Re:
[Netconf] issue with draft-ietf-netconf-partial-lock-07.txt" Martin
Bjorklund (Mar 18 2009) states: "There's nothing in 4741 that says that they
are mutually exclusive. And I don't think they should be.  Some devices
already support this combination."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04582.html> "Re:
[Netconf] :writable-running" WashamFan (May 11 2009) states: "Given session
A with :candidate and session B with :writable-running, it is beneficial for
session A to lock both <candidate> and <running> for consistency."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04822.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Andy Bierman (Jul 25
2009) states: "every agent MUST have exactly 1 database that can be the
target of an <edit-config> operation. (Writing to both <candidate> and
<running> does not work!) therefore the agent MUST support the :candidate
OR: writable-running capabilities, but not both"

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04823.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Phil Shafer (Jul 25
2009) states: "I think Martin's code support this (both)."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04826.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Martin Bjorklund (Jul
25 2009) states: "Yes it does.  I agree that other combinations are more
useful, but also this combination works. If you can copy from candidate to
url X, and from url X to running, why not copy from candidate to running
directly?  (and IMO it means just that).  It only works if you have a
candidate AND :writable-running of course."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04828.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Andy Bierman (Jul 25
2009) states: "I think the standard is poorly specified in this entire
area."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04832.html> "Re:
[Netconf] Comments :draft-ietf-netconf-4741bis-01.txt" Martin Bjorklund (Jul
26 2009) states: "<commit> has more parameters than <copy-config>, so I
think it must be kept.  Also, you cannot copy-config to running unless
:writable-running is advertised, so <commit> is needed."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04860.html>
"[Netconf] :writable-running and :candidate" Andy Bierman (Aug 01 2009)
states: "I asked (in email) how the :candidate and :writable-running
capabilities can possibly be supported on the same agent. I never got an
answer. I do not understand how the candidate database stays in synch with
the running database if user B can write to running while user A has the
candidate locked.  Also what happens to the edits made by user A when user B
issues a <commit>? Are the changes just made to running undone (they were
not in the candidate, so they must be undone, right?) Is this part of the
intended database architecture or not? And if user A does a copy-config from
a locked candidate to running? That is allowed of course."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04875.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Andy Bierman (Aug 03
2009) states: "IMO, :candidate and :writable-running do not work together.
They almost work together, and only go horribly wrong sometimes.  If that's
good enough for the NETCONF database architecture, then I guess there is
nothing to fix."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04961.html> "Re:
[Netconf] :writable-running and :candidate" Phil Shafer (Aug 08 2009), in
reply to Andy Bierman's previous email comment "I asked (in email) how the
:candidate and :writable-running capabilities can possibly be supported on
the same agent. I never got an answer.", states: "I believe I answered you,
saying that tail-f's sw does this."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04964.html> "Re:
[Netconf] :writable-running and :candidate" Andy Bierman (Aug 08 2009)
states: "I asked for clarifications on the standard, for specific
corner-cases that IMO indicate that this combination is not supported by the
standard. The thread reached a conclusion that even though any changes made
to running will get wiped-out as soon as the candidate is committed, this is
how the standard is intended to work. I can't imagine that an operator or
NMS developer using :writable-running would reach the same conclusion, but
that's their problem -- not an IETF standards problem, right?"

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04988.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Phil Shafer (Aug 10 2009)
states: "I don't support :writable-running, just :candidate, and the
interaction between the two isn't clear.  Martin, how does this work on your
sw?"

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg04999.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Martin Bjorklund (Aug 11
2009) states: "There is no magic going on just because the box is configured
to use both :candidate and :writable-running.  Each operation behaves the
same regardless of the other capabilities.  So <discard-changes> resets
candidate to the contents of running, and <commit> replaces running with the
contents of candidate. I agree that it is a burden on the client software to
support all different combinations of (startup, writable-running,
candidate), and a server developer that has a choice should carefully
consider which combination to implement."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg05005.html> "Re:
[Netconf] Fw: Database Architecture OK or NOT-OK?" Juergen Schoenwaelder
(Aug 11 2009) states: "The candidate design does not work with
:writeable-running unless we find a more precise definition how to determine
whether candidate is in a "good shape" or not."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg07289.html> "Re:
[Netconf] NACM issue?" Martin Bjorklund (Jan 11 2012) states ".only if
:writable-running and :candidate is advertised at the same time, and I think
we have agreed that this is a Bad Idea."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg08275.html> "Re:
[Netconf] The <running> configuration datastore and :writable-running"
Juergen Schoenwaelder (Aug 08 2013) states: "Implementing NETCONF read-only
has obviously little value for real configuration management. The reason why
we have :writable-running and :candidate is that some major vendors use very
different models when it comes to making configuration changes and as such
you will see implementations that either announce :writable-running or
:candidate or :writable-running and :candidate together."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg08276.html> "Re:
[Netconf] The <running> configuration datastore and :writable-running" Andy
Bierman (Aug 08 2013) states: ":candidate and :writable-running together
should be considered deprecated. This is a degenerate use-case for
concurrent transactions.  The WG should standardize this properly at some
point in the future, so clients can use a predictable standard transaction
model."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg11468.html> "Re:
[Netconf] <lock> in a server that supports both writable-running and
candidate" Andy Bierman (Jul 14 2016) states: "The reason nobody implements
:candidate and :writable-running together is because there is no way to
synch the candidate if running has been changed underneath it."

 

 <https://www.ietf.org/mail-archive/web/netconf/current/msg11473.html> "Re:
[Netconf] <lock> in a server that supports both writable-running and
candidate" Sterne, Jason (Nokia - CA) (Jul 14 2016) states: "Nokia SR OS
supports both writable-running and candidate.  And yes it is complex to
manage.  The two datastores can't be simply treated independently and some
locking/coherency mechanisms are needed between them."