Re: Questions on Confirmed commit

[Martin Bjorklund <mbj@tail-f.com>]

[resent]

Johan Rydberg <johan.rydberg@edgeware.tv> 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

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