[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation of configuration and control - good or bad?
Rob Enns wrote:
On Fri, May 16, 2003 at 04:34:01PM -0400, Larry Menten wrote:
Phil Shafer wrote:
Larry Menten writes:
The Enns model is one in which
configuration is expressed as the transformation of a document. This is
why
you must lock the document before you operate on it.
Regardless of the configuration change you are making, locking the
device seems like a requirement. This seems independent of your
view of configuration-as-tree .vs. configuration-as-hierarchy
.vs. configuration-as-set-of-strings. If you can't lock it,
you can't prevent other sources of configuration (applications or
users) from turning your change from benign to dangerous.
I disagree. It should be safe to, for example, delete an OSPF interface
instance
without having to lock the config to do so.
Why is this not safe with xmlconf?
It happens to make sense to be able to lock a configuration, in a world
with or without xmlconf. But I don't believe the draft requires it.
As the draft is currently expressed, locking is required to avoid
deleting someone else's "add interface" operation while you do a
"delete interface" operation on the same ospf area.
You cannot tell from reading an transaction expressed per your draft
whether the purpose of the operation is to create an entire area
configuration, complete with fully configured interface instances,
or simply to delete a single interface instance. Very odd.
But adding a delete operation is not enough to make the scheme workable.
For example, if you wish to add an element or element subtree, you must
use the merge operation. This operation does not distinguish between
an intent to modify the descendents of an existing object, and the wish
to create a new object. You cannot express what it is that you really
intend to do.
Consequently, if the object exists, you will probably get a result
that you did not intend with no error message to warn that this has
occurred. Too my mind, very bad.
Also consider an operation that is supposed to create an OSPF area of
type NSSA and assume that an "Extern" area with the desired id already
exists.
You might choose to reject the command with a corner-case error code.
requires extra code in the manager to deal with. Or you might let
the operation take place, causing an existing area and all associated
adjacencies to be taken down. You might not have been aware that the
area ID was already in use and now you have made a big mess. And since
there is not error response, you do not even know you have made a big mess.
The requirement for locking
is an
artifact of the Enns representation and not inherent to the delete
operation.
Does the SOHO device you're considering permit only one management
session at a time?
Multiple. The representations that I have offered do not require a
get-before-set to be used safely, and explicitly express the intention to:
- add an object that does not already exist,
- delete an object that must already exist,
- replace an object that must already exist, or
- merge attributes or child-objects of a object that must already exist.
These are safe operations in an environment with multiple management
sessions.
The Enns spec works only if you wish to:
- ignore the current configuration state
- force it into a new one, and
- not be warned of consequences.
The Enns spec turns a benign change into a dangerous one. Just my point.
The protocol spec tries to accomodate the known device configuration
models (single cfg store+immediate operations, candidate
config+commit+rollback, etc) and not inhibit development of new ones.
But it doesn't change the basic rules of interaction with devices
offering a given model.
Can you explain why identifying the target of an operation using
a tag hierarchy as in the draft is dangerous and requires locking,
while using an xpath subset equivalent does not?
As expressed in your draft, the intended target cannot be descerned.
The operation to create an OSPF instance, and OSPF area within the
instance, an interface instance within the area, and an MD5 key within
the new interface is expressed exactly the same as a request to add an
MD5 key to an existing interface within an existing area within an existing
ospf instance.
That is very dangerous.
That is a consequence of your representation configuration commands. To
configure the target safely, you must lock it, get the config, verify your
understanding of the current config, and concoct a transaction to
perform the
desired operation.
One cannot tell from the transactions specified in your spec what the
transaction is supposed to do and so the device agent cannot help you
to avoid a bad mistake. You have "dumbed down" the device agent.
A request to add an MD5 key is exactly the same as a request to create
an OSFP instance. How odd.
Thanks,
Larry
thanks,
Rob
Thanks,
Phil
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
Thanks,
Larry
--
Larry Menten Lucent Technologies/Bell Laboratories
Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
Larry Menten Lucent Technologies/Bell Laboratories
Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>