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