RE: netconf WG charter proposal

[Andy Bierman <abierman@cisco.com>]

At 04:56 PM 4/5/2003 -0700, John Strassner wrote:

>Sorry, I'm lost. 
>
>Randy (not the other), did you mean to say that an 'external' system provide a transaction model... (you have a stray "can not" in your query).
>
>Andy, regarding locking, are you saying that if the device doesn't support locking, then the NMS can't help? If so, I agree with you. However, regarding rollback, you've lost me.
>
>First, you seem to be assuming that removing a config change consists of removing commands that were added to get back to its original pristine state. However, there are some devices that will insert additional commands in response to a command being received. How do you get around that?

I'm not assuming any specific implementation strategy for rollback.
The high-level concept is easy to describe, not so easy to implement
in all cases.  


>Second, embedded rollbacks exacerbate the problem - they most certainly do not make them simpler. How do you roll back to an embedded save point, for example?

I disagree.  Again the concept is simple.  Apply this blob
of config. If any of it fails, then revert back to the config
in place just before the config blob was applied.  The save
point is not arbitrary in this use case.


>Finally, I do agree with your sentiments on conformance. The WG should be cognizant of it, but not get bogged down in creating conformance statements yet.
>
>
>regards, 
>John 
>  

Andy


>John Strassner 
>Chief Strategy Officer 
>Intelliden Corporation 
>90 South Cascade Avenue 
>Colorado Springs, CO  80903  USA 
>phone: +1.719.785.0648 
>  FAX: +1.719.785.0644 
>email: john.strassner@intelliden.com 
>
>-----Original Message----- 
>From: Andy Bierman [<mailto:abierman@cisco.com>mailto:abierman@cisco.com] 
>Sent: Saturday, April 05, 2003 11:08 AM 
>To: Randy Bush 
>Cc: xmlconf@ops.ietf.org 
>Subject: RE: netconf WG charter proposal 
>
>At 05:32 AM 4/5/2003 -0800, Randy Bush wrote: 
>>> There are alternatives to these features today -- the NMS application 
>>> has to provide rollback or check for multiple config-writers.  I 
>>> agree a device is more manageable if these are embedded features.  I 
>>> would prefer to see multiple conformance levels rather than one bar, 
>>> set way too high. 
>> 
>>can an 'external' system can not provide a transaction model if the 
>>devices do not have the primitive mechanisms needed to implement it? 
>
>locking: no. 
>An NMS can (at best) detect that additional config changes have 
>occurred, examine those changes, and determine if conflicts exist.  (The source code control model) 
>
>rollback: maybe 
>An NMS can retrieve the device config at any time, and save it before applying new config. If the new config does not create the desired network state, the NMS can re-apply the old config. This may or may not require service disruption, depending on
>
>the device and specific config changes applied.   If the new 
>config causes the device to crash, then devices which have 
>a distinct startup config will revert to the last saved config upon reboot.  If the new config causes the device to wedge, then OOB management via the console port is required.
>
>Note that embedded rollback only makes things easier on the 
>NMS in the first case, not the other two cases. 
>
>I don't care that much about the conformance details right 
>now. Perhaps WG consensus will turn out to be that this is 
>a mandatory feature that all devices must support.  I think 
>we should focus on the technical details first and worry 
>about conformance details towards the end of the process. 
>
>>randy 
>
>Andy 
>
>-- 
>to unsubscribe send a message to xmlconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
>
>archive: <<http://ops.ietf.org/lists/xmlconf/>http://ops.ietf.org/lists/xmlconf/> 


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