Subject: Re: Questions on Confirmed commit

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Aug 2007 14:39:34 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> 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

I think you found an interesting case, and this should be clarified if
we ever see a rfc4741bis.

Anyway, I think that 5a must not happen - if the db is locked it
cannot be modified.  And 5b must not happen either, since it
contradicts the semantics of confirmed commit.  So, I think that 3
should not be allowed.  Essentially this would mean that when a user
invokes a confirmed commit it takes an (implicit) lock.

> ------------------------------------------------
> 
> 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?

Just running.

/martin

--
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: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Aug 2007 10:59:27 +0200 (CEST)

[resent]

Johan Rydberg <[email-masked]> wrote:
> 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.

But it also says:

   The confirming commit can itself include
   a <confirmed> parameter.

I.e. a confirming commit can at the same time be a confirmed commit.

Note that the way it's defined is that running is reverted _unless_ a
confirming commit is sent, not that the changes are made persistent
when a confirming commit is sent.  So I think that the text in the rfc
is consistent with the junos interpretation.

Thus, a confirming confirmed commit with a zero timeout will
explicitly revert running.  But unfortunately, zero is not allowed, so
you have to use a 1 second delay:

  <commit>
    <confirmed/>
    <confirm-timeout>1</confirm-timeout>
  </commit>

In any case this is not IMO crystal clear from the text.  So the
question is if the behaviour described above was the intention?
Otherwise I'm sure we can find an interpretation of the current text
which is consistent with the intention ;)

/martin

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Aug 2007 14:54:51 +0200 (CEST)

But it also says:

  <commit>
    <confirmed/>

/martin