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

[Andy Bierman <andy at netconfcentral.com>]

Martin Bjorklund wrote:
> Andy Bierman <andy at netconfcentral.com> wrote:
>> 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.
> 
> If you think the current confirmed commit is broken, it should be
> fixed.  I don't like the idea of introducing new partly overlapping,
> partly different operations in an ad-hoc manner.  I think it would be
> better to fix confirmed commit (if necessary), and use it for this
> function as well.  [this should be discussed in a separate thread]
> 

I don't want to introduce an incompatible version of
the protocol.  The charter already assumes in advance
that there are no problems worthy of a new protocol version.

But you will tell me that we could just introduce :confirmed-commit.1.1,
so I guess it doesn't matter.  But I am not so sure the complexity on
the NMS is less in the long run if we do this.  A lot of capabilities
interact.  So now we have to document how every version of every
capability interacts with every other, for all time.  Sounds hard.
This is probably why most protocol WGs just version the entire protocol,
and not arbitrarily small subsets of it. (hint)



>>   3) the lack of notifications makes confirmed commit harder to
>>      use in a network-wide config change.
> 
> But you have solved that with your new operation.  The <start-test>
> operation would still generate notifications as in your proposal.  I
> think this is a good idea.


I kept saying I wanted some notification content. :-)
The details of the partial status updates and how
a real template gets used instead of the 'anyxml'
for <extendedStatus>, depending on the test type.

The idea is that a test could return whatever it wants,
even the direct output of unix ping or traceroute commands,
if that was all that was available.

There should probably be distinct <commitStarted> and <commitComplete>
notifications.  There is no 'start' now, and the current complete is
for the tests (but if it worked, it can be assumed the 2nd commit
worked too.  But maybe not, so that's why a <commitComplete>
notification will tell the operator for sure.

The notification replay log could be searched for

  <commitStarted>
    ... bunch of verification tests reporting status and completion ...
  <commitComplete>

That way, different commits in the log could be determined easily.


> 
>>   4) overloading the <commit> operation with more modes is more
>>      confusing than using a new operation.
> 
> The idea is that <commit> is not modified at all.  The new
> <start-test> operation is orthogonal to <commit>.  The idea is that
> the client uses <start-test> in the confirm time window, just like it
> can do other tests before issuing the confirming commit.
> 


Well, using a <complete-verified-commit> operation instead of <commit> again,
and adding a <cancel-verified-commit> operation are certainly different.
Except for that part, it is the same as confirmed-commit,
with some tests on the side to help the operator decide
whether to save or rollback the changes.

The tests need to be independent to support case (2)
I mentioned before.  The operator needs to get baseline
numbers (for example), so running the verification tests
outside the context of a commit is important.


> 
> /martin
> 

Andy