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

Hi,

On Thu, Dec 22, 2016 at 4:12 AM, Jonathan Hansford <jonathan@hansfords.net>
wrote:

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

This seems OK, but we do not support candidate and running as targets at
the same time,
so I do not know how it impacts the implementation to add this constraint.

I do not agree that the strict text in RFC 6241 actually supports this
editing mode.
If it does, then following the spec would lead to an implementation where
the candidate would clobber edits made in running.  There is no text that
seems
to support automatic update of candidate after the edit to running. There
is certainly
no text that describes how edit conflicts in candidate are resolved.

> Jonathan
>
>
>

Andy

> ---
>
>
>
> "Re: NETCONF modelled in UML"
> <https://www.ietf.org/mail-archive/web/netconf/current/msg00005.html>
> 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.”
>
>
>
> "[Netconf] partial-lock feedback"
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03915.html>
> 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.”
>
>
>
> "Re: [Netconf] partial-lock feedback"
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03918.html>
> Balazs Lengyel (Nov 17 2008) states: “It is not stated anywhere that you
> can't have candidate and writable-running together.”
>
>
>
> “[Netconf] :candidate vs :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03960.html>
> 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”.
>
>
>
> “Re: [Netconf] :candidate vs :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03985.html>
> 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.”
>
>
>
> “Re: [Netconf] lock/unlock on candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg03995.html>
> Martin Bjorklund (Dec 01 2008) states: “This is only an issue if the box
> supports :candidate and :writable-running.”
>
>
>
> “Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04436.html>
> Kent Watsen (Mar 18 2009) states: “can devices advertize both :candidate
> and :writable-running?  - aren't those capabilities mutually exclusive?”
>
>
>
> “Re: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04437.html>
> 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.”
>
>
>
> “Re: [Netconf] :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04582.html>
> 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.”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04822.html>
> 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”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04823.html>
> Phil Shafer (Jul 25 2009) states: “I think Martin's code support this
> (both).”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04826.html>
> 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.”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04828.html>
> Andy Bierman (Jul 25 2009) states: “I think the standard is poorly
> specified in this entire area.”
>
>
>
> “Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04832.html>
> 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.”
>
>
>
> “[Netconf] :writable-running and :candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04860.html>
> 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.”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04875.html>
> 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.”
>
>
>
> “Re: [Netconf] :writable-running and :candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04961.html>
> 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.”
>
>
>
> “Re: [Netconf] :writable-running and :candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04964.html>
> 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?”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04988.html>
> 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?”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg04999.html>
> 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.”
>
>
>
> “Re: [Netconf] Fw: Database Architecture OK or NOT-OK?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg05005.html>
> 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.”
>
>
>
> “Re: [Netconf] NACM issue?”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg07289.html>
> 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.”
>
>
>
> “Re: [Netconf] The <running> configuration datastore and :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg08275.html>
> 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.”
>
>
>
> “Re: [Netconf] The <running> configuration datastore and :writable-running”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg08276.html>
> 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.”
>
>
>
> “Re: [Netconf] <lock> in a server that supports both writable-running and
> candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg11468.html>
> 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.”
>
>
>
> “Re: [Netconf] <lock> in a server that supports both writable-running and
> candidate”
> <https://www.ietf.org/mail-archive/web/netconf/current/msg11473.html>
> 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.”
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>