Subject: Questions on Confirmed commit

From: Balazs Lengyel <[email-masked]>
Date: Tue, 17 Jul 2007 12:41:45 +0200

Hello,
What happens in the following sequence:

1) Operator A modifies the candidate datastore
2) Operator A successfully uses confirmed commit on candidate
3) Operator B successfully locks the running datastore
4) The confirmed commit times out

5a) The locked running datastore is reverted to the previous version even though it's locked

5b) Nothing as due to the locked the running datastore can not be changed

------------------------------------------------

When the node revert it's configuration due to an expired confirmed commit will it restore the 
candidate datastore. to it's previous state as well or only the running datastore?

------------------------------------------------

The base RFC state the manager can explicitly restore the configuration to its state before 
the confirmed commit was issued. How?

Balazs

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Johan Rydberg <[email-masked]>
Date: Wed, 25 Jul 2007 17:25:56 +0200

Balazs Lengyel skrev:

> The base RFC state the manager can explicitly restore the configuration 
> to its state before the confirmed commit was issued. How?

As I understand the RFC, this is done by keeping a copy of the running
configuration, as before the confirmed commit.  If the manager wants to
cancel a confirmed commit he/she has to load the candidate with the old
running configuration and issue a confirming commit.

Others do different interpretations:

 From [1] :

   To delay the rollback again (past the original rollback deadline),
   emit the <confirmed/> tag (enclosed in the <commit> tag element)
   again before the deadline passes. Include the <confirm-timeout> tag
   element to specify how long to delay the next rollback, or omit that
   tag element to use the default of 10 minutes. The rollback can be
   delayed repeatedly in this way.

So using that you could do another new <confirmed/> commit with a
timeout of zero seconds, to revert the state.

But I think that contradicts 8.4.1:

   Note that any commit operation, including a commit which introduces
   additional changes to the configuration, will serve as a confirming
   commit.

I interpret that as every configuration will copy <candidate/> to
<running/>, even if there already is a pending confirmed commit.

[1]
https://www.juniper.net/techpubs/software/junos/junos80/netconf80-guide/html/summary-netconf-tags4.html#1350982

~j