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

[Andy Bierman <andy at netconfcentral.com>]

rgcole01 at comcast.net wrote:
> Phil,
> 
>  
> 
> I agree that the nature of the test are tied to the change and the role
> of the device in the network.  We discuss this to some extent in the
> draft.  I think one of the challenges if to determine if it is possible
> to strongly associate tests to config objects.  I would like to think
> this is generally possible but think this is an outstanding question.
> 
>  

I think there are 4 classes of managed devices when considering
the Verified Commit Procedure:


    need to run commit     need to run test
  +--------------------+--------------------+
  |      no            |        no          |   1) not involved in verified commit
  +--------------------+--------------------+
  |      no            |        yes         |   2) just run verify test(s)
  +--------------------+--------------------+
  |      yes           |        no          |   3) just run double-commit procedure
  +--------------------+--------------------+
  |      yes           |       yes          |   4) run verify test(s) and double-commit
  +--------------------+--------------------+


I think the YANG module needs to address (2).  It currently does not.



> 
> However,  another reason for the start-verifed-commit  approach is to
> push the tests to the server.  I believe this level of testing is
> necessary and goes beyond running tests from the client application or
> inferring behavior on the server through means outside of NETCONF.  We
> list some example use cases in the appendix where active tests run from
> the server would be useful.
> 
>  
> 
> Thanks,
> 
> Bob

Andy



> ----- Original Message -----
> From: "Phil Shafer" <phil at juniper.net>
> To: "Martin Bjorklund" <mbj at tail-f.com>
> Cc: rgcole01 at comcast.net, andy at netconfcentral.com, dromasca at avaya.com,
> netconf at ietf.org
> Sent: Friday, June 26, 2009 9:52:26 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [Netconf] draft-cole-netconf-robust-config-01
> 
> Martin Bjorklund writes:
>>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?
> 
> Another thing to consider that the nature of the test are typically
> interwoven with the architecture of the network and the characteristics
> of the change.  What test do you perform when you:
> 
> (a) change a BGP export filter
> (b) change an AS number
> (c) add a BGPVPN site
> 
> (a) would only affect your peer(s), (b) could have serious impact (but
> that's what you wanted), and (c) should have no impact on existing
> peers/sites/etc.
> 
> So given that the application is making the change, and that testing
> the change is integrated with both the change and the customer
> network architecture, why not use the existing "commit confirmed"
> mechanism and have the application drive the testing of changes
> using remote RPCs to get information off the box re: the impact
> of the change?  This seems much more straight forward and was
> what we had in mind from the start.
> 
> Thanks,
>  Phil
>