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

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

RFC 6241, Section 8.2.4.1 states, 'If the running or candidate 
configuration is currently locked by a different session, the <commit> 
operation MUST fail with an <error-tag> value of "in-use".' So if the 
new client acquires a lock on <candidate>, the original client cannot 
<commit> to <running>. So that fixes one of the issues below.

Section 8.3.5.2 states, 'When a client fails with outstanding changes to 
the candidate configuration, recovery can be difficult.  To facilitate 
easy recovery, any outstanding changes are discarded when the lock is 
released, whether explicitly with the <unlock> operation or implicitly 
from session failure.' So this means <candidate> would revert. Section 
8.4.1 also states, 'If the device reboots for any reason before the 
confirm timeout expires, the server MUST restore the configuration to 
its state before the confirmed commit was issued.' However, earlier in 
Section 8.4.1 it states, 'If the session issuing the confirmed commit is 
terminated for any reason before the confirm timeout expires, the server 
MUST restore the configuration to its state before the confirmed commit 
was issued, unless the confirmed commit also included a <persist> 
element.', Section 8.4.5.1 states the persist parameter makes 'the 
confirmed commit survive a session termination, and set a token on the 
ongoing confirmed commit' and its description in Appendix C states, 
'This parameter is used to make a confirmed commit persistent.  A 
persistent confirmed commit is not aborted if the NETCONF session 
terminates.  The only way to abort a persistent confirmed commit is to 
let the timer expire, or to use the <cancel-commit> operation.'

So it is the persist-id that is the cause of all the problems, not just 
the use of confirmed commit as I previously stated. But is there a way 
to resolve the outstanding issues around the use of the persist-id?

Thanks

------ Original Message ------
From: "Jonathan Hansford" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Sent: 14/01/2019 12:50:38
Subject: [Netconf] Is there a problem with confirmed commits?

>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
>
>
>--------------------------------------------------------------------------------
>Avast logo
><https://www.avast.com/antivirus>
>				This email has been checked for viruses by Avast antivirus 
>software. 				
>www.avast.com <https://www.avast.com/antivirus>
>
>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus