Re: [Netconf] Is there a problem with confirmed commits?

["Jonathan Hansford" <[e-mail]>]

If a persistent confirmed commit has not timed out, the running 
configuration datastore will be the same as the candidate and 
<discard-changes> won't change its contents. Any edit of candidate will 
be based on the configuration resulting from the persistent confirmed 
commit.

If the persistent confirmed commit has timed out, the running 
configuration datastore will have reverted and <discard-changes> will 
change candidate. Any edit of candidate in this case will be based on 
the configuration prior to the start of the persistent confirmed commit.

------ Original Message ------
From: "Juergen Schoenwaelder" <[e-mail]>
To: "Jonathan Hansford" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 14/01/2019 13:50:56
Subject: Re: [Netconf] Is there a problem with confirmed commits?

>Hi,
>
>I have not yet understood where you see a problem. In general,
><candidate/> contains arbitrary stuff and hence it is the client's
>responsibility to clear any arbitrary stuff found in <candidate/>
>after obtaining a lock. If does not really matter whether there has
>been a failed confirmed commit before or something else. I think the
>general safe pattern is:
>
>lock(candidate)
>discard_changes()
>push_whatever_needed()
>commit()
>unlock(candidate)
>
>If you do a confirmed commit and the session disappears, then the lock
>will disappear as well. But I do not think this creates a race
>condition, or I am just not yet seeing it. Perhaps it helps to write
>down the sequence of actions that leads to a race.
>
>/js
>
>On Mon, Jan 14, 2019 at 12:50:38PM +0000, Jonathan Hansford wrote:
>>  Hi,
>>
>>  No one seems to be responding to my email and proposed erratum around
>>  the subject of confirmed commits (apart from Martin), but I would really
>>  like to know it I am missing something here. As far as I can tell,
>>  session termination during a confirmed commit leads to unpredictable
>>  behaviour and I would like to know whether anyone is using confirmed
>>  commits and how (if at all) they address the issues outlined below. My
>>  assumptions are that locks are used and :writable-running is not
>>  supported.
>>
>>  If the <candidate> and <running> configuration datastores are locked to
>>  prevent concurrent access, and a confirmed commit sequence is
>>  interrupted by the session terminating, the locks will automatically be
>>  released but the server MUST NOT accept a lock on <running> from any
>>  session if another session has an ongoing confirmed <commit>.
>>  Consequently, after session termination no client can acquire a <lock>
>>  on <running>, not even the one that initiated the confirmed <commit>,
>>  until after the confirmed <commit> has timed out. However, if the
>>  confirmed <commit> included the <persist> parameter, the original client
>>  could still issue a <commit> using the persist-id to complete the
>>  sequence prior to the timeout, even without a lock.
>>
>>  Of course, the problem now is the race for the new lock on <candidate>.
>>  If the original client is successful then all is good. But if a new
>>  client locks <candidate> before the timeout on the confirmed commit,
>>  whether or not they precede <lock> with <discard-changes>, <candidate>
>>  will be the same as <running> and the new client will pick up everything
>>  from the previous session. However, the client won’t be able to lock
>>  <running> until after the timeout, at which point <running> reverts but
>>  <candidate> still represents the previous session. If the client tries
>>  to lock <candidate> after the timeout, <running> will have reverted and
>>  the lock will only be granted after a <discard-changes> which will cause
>>  the <candidate> to revert. So, depending on when the lock on <candidate>
>>  occurs relative to the confirmed commit timeout, the client could be
>>  editing <candidate> in one of two states. Further, before the timeout on
>>  the confirmed commit, even if the new client has locked candidate, the
>>  original client could still issue a confirming commit (they don’t need a
>>  lock on <candidate> to do so) which would persistently commit any edits
>>  made by the new client. NOTE: it is not the use of the persist-id that
>>  introduces this behaviour; a new client would have the same problem even
>>  if a confirmed commit was not intended to persist beyond a session
>>  termination.
>>
>>  If the server also supports the :startup capability then, if the session
>>  termination was due to the server rebooting, the behaviour above would
>>  be further complicated by <running> now containing the configuration
>>  from the <startup> configuration datastore.
>>
>>  Am I right?
>>
>>  Jonathan
>>
>>  ---
>>  This email has been checked for viruses by Avast antivirus software.
>>  https://www.avast.com/antivirus
>
>>  _______________________________________________
>>  Netconf mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/netconf
>
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   [phone]         <https://www.jacobs-university.de/>