Re: [Netconf] draft-cole-netconf-robust-config-01

[Andy Bierman <andy at netconfcentral.com>]

Martin Bjorklund wrote:
> Hi,
> 
> I have read this document, and I think the ideas presented are very
> interesting.
> 
> But I have a comment on the solution you have chosen to trigger the
> tests.  It seems you have re-invented confirmed commit, with some
> additional parameters.  IMO, the existing confirmed commit operation
> is well suited for the things you want to do (maybe it was even
> designed to be able to handle this kind of use case).  Why don't you
> simply add a new operation <start-test> that can be used to trigger
> the tests at the server when the conrimed commit is active?  This
> would look like:


I prefer the design of the verified commit over the confirmed commit.

  1) using the same command multiple times to do different things
     is confusing and prone to errors (user B's first <commit>
     can actually be used as user A's 2nd commit.  That's broken.)

  2) there is no way to cancel a confirmed-commit, other than
     by dropping the session.  This is not very clean.

  3) the lack of notifications makes confirmed commit harder to
     use in a network-wide config change.

  4) overloading the <commit> operation with more modes is more
     confusing than using a new operation.


Andy

> 
>             +------------------------------>
>              Sets up <candidate> config
> 
>             +------------------------------>
>              Sets up test control
> 
>    ---      +------------------------------>
>     |        Sends <commit> <confirmed>
>    (set             - timeout
>     timeout)
>     |        <-----------------------------+
>     |                              reply(OK)
>     |      +------------------------------>
>     |        Sends <start-test>
>     |         - test-template:instanceID
>     |        <-----------------------------+
>     |                              reply(OK)
>    (running                                  (run server-side tests)
>     client-side
>     tests)
>     |                                        (server-side test success)
>     |        <-----------------------------+
>     |         <verifiedCommitStatus = good> notification
>     |
>     |
>     |        +----------------------------->
>     |         Sends <commit> (confirming)
>     |
>     |        <-----------------------------+
>     |                              reply(OK)
>     |
>    ---
> 
> 
> One advantage of this is that is can also be used on servers that have
> startup instead of candidate, (with the normal disadvantages of this
> design):
> 
>    make changes to running
>    set up test control
>    <start-test>
>    if test-ok: copy running to startup
>    if test-fail: revert running
> 
> 
> 
> /martin
>