Re: Questions on Confirmed commit

[Johan Rydberg <johan.rydberg@edgeware.tv>]

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


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