[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation of configuration and control - good or bad?
At 07:41 AM 5/15/2003, Larry Menten wrote:
It is somewhat difficult to figure out the transactions that
would occur without some examples or XML definitions.
IMO, the <edit-config> operation in the Enns draft should
be split into 3 operations: <create-config>, <edit-config>
and <delete-config>. (I know there's already a <delete-config>
but it's parameters and semantics need to be changed to align
with <edit-config>.)
There is value in having PDU-level and data-model level operations.
I'm not at all convinced this makes implementations easier,
smaller, faster, etc. Can you provide some examples that
demonstrate these improvements?
Andy
>Short form:
>
>In additions to the other issues I have expressed with the Enns spec,
>the model of configuration proposed in the Enns document
>separates configuration from control, resulting in:
>
>- more code in both the manager and agent
>- more processing expense for both the manager and agent
>- less robust management
>- less functionality
>- less intelligible transactions
>
>Long form:
>
>The specification proposed in the Enns document reflects a particular model
>for device management. The idea presented is that the configuration operations
>be modeled as direct modifications to a tree of configuration information.
>One acquires a subtree, locking the target configuration if robustness is desired,
>modifies the subtree to express the desired operation as a replacement, merging,
>or overlay of the target subtree and presents the resulting transaction to the target
>system. Examination of the contents of the transaction is not sufficient to understand
>what operations are to take place, but only what the target end-state of some aspect of
>the configuration is to be. Since the transaction operations are limited to replace, merge,
>and overlay, it is necessary to acquire the current state before expressing the operation
>and to lock the state of the target configuration between when the state is acquired and the
>modification performed. Also, since the representation of an operation such as delete depends
>upon the preceeding state of the subtree, the deletion of an element, such as an interface,
>will be expressed differently each time it is performed, reflecting the state of the tree before the
>operation.
>
>My own experiments with this model suggest that the easiest way to implement this approach is
>to modify the target tree, validate the result using a DTD or XML-Schema and a validating parser,
>and then present the result to the system, or target subsystems as a configuration file that is to be
>read and validated as a proposed replacement configuration by the target system/subsystem. If the
>validation succeeds, then the set is performed. The statement in the proposed guidelines that
>recommends that elements for which more than one sibling instance can appear should be collected
>in an element representing the array suggests to me that they might be using an object serialization/restoration
>design pattern to construct the candidate configuration data structures from the configuration file.
>
>This explains the objection to including operation commands within the tree representing the transaction.
>To my mind, the part of the tree leading up to the operation code represented the identification of the target,
>and the children of the element containing the operation code represented a subtree to be added
>or inserted as a replacement for the named target. The tree, in my model represents a specification of
>one or more operations on the target configuration. In the Enns model,
>the entire contents of the tree
>become part of the replacement configuration tree and persist as a configuration file.
>
>
>I have already brought up a number of issues with this approach and issues, in particular, with the
>operations of overlay, merge, and replace. To my mind this makes the management operation
>complicated and error prone. It is more complicated to create the transaction contents, and it is
>necessary to know what the existing contents are to do a simple operation such as delete. Futhermore,
>locking is required if the operation is to be robust and concurrent management operations not lost.
>
>Another consequence of this approach is the separation of control operations from configuration
>modifications. Is this a virtue or a fault? To my mind, it is a fault. In my opinion, it is desireable
>to be able to request control operations with configuration steps. For example, request that an
>LSA database be purged or not purged or that an OSPF adjacency be dropped or not dropped
>when the configuration operation is performed. In the Enns model, this cannot be intelligibly expressed
>as a component of an atomic operation. Furthermore, the separation of the processing of the control
>operations from the configuration operations requires more code and requires the duplication of the
>object hierarchy in different code within the target system.
>
>Again, the result is
>- more code
>- more processing expense
>- less robust management
>- less functionality
>- less intelligible transactions
>
>
>Larry
>
>
>Andy Bierman wrote:
>
>>At 11:04 AM 5/14/2003, Larry Menten wrote:
>>
>>
>>>Keith,
>>>
>>>I also made the point that the transaction representation
>>>proposed in Enns does not support the expression of setting multiple variables in a single atomic transaction
>>>unless they happen to reside in the same target subtree.
>>>
>>
>>This is not the intent. The contents of a <config> subtree
>>can be multiple subtrees from multiple namespaces. The examples
>>are kept simple and only show one, but the protocol is
>>not limited to one.
>>
>>BTW, I agree with the comment below that precise (and consistent)
>>naming is an important aspect of the data model design. It's
>>probably out of scope for the netconf WG though.
>>
>>
>>
>>
>>>This, too, impacts the protocol.
>>>
>>>Larry
>>>
>>
>>Andy
>>
>>
>>
>>
>>
>>
>>>Allen, Keith wrote:
>>>
>>>
>>>>Larry Menten writes:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>In my opinion, there is a very big flaw in a representation that
>>>>>does not provide for precise naming of the target of the operation.
>>>>>
>>>>I agree. In fact, I brought this issue up a few weeks ago. It's a tough one, though. Having been involved in network management standards work before, I would estimate that 50% of the time of a network management standards group gets spent on naming-related issues. I think this group was hoping to put those issues in the hands of the information model developers. I'm concerned, though, that it impacts the protocol and needs to be addressed here.
>>>>
>>>>
>>>>
>>>>
>>>>Keith Allen
>>>>
>>>>SBC Technology Resources
>>>>
>>>>9505 Arboretum Blvd.
>>>>
>>>>Austin,TX 78759
>>>>
>>>>(512) 372-5741
>>>>
>>>><mailto:kallen@tri.sbc.com>kallen@tri.sbc.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Larry Menten [<mailto:lmenten@lucent.com>mailto:lmenten@lucent.com] Sent: Wednesday, May 14, 2003 9:23 AM
>>>>To: netconf
>>>>Subject: Re: Is DOM vs SAX a red herring?
>>>>
>>>>
>>>>
>>>>Keith,
>>>>
>>>>In my opinion, there is a very big flaw in a representation that
>>>>does not provide for precise naming of the target of the operation.
>>>>You cannot, for example, request that a particular interface instance
>>>>be deleted. Instead, you must request the replacement of the parent
>>>>element with a new configuration that omits the child. This requires that
>>>>you acquire the complete config of the parent element and requires that
>>>>you include that complete config, without mistake, in the transaction request.
>>>>So what happens if someone has created an interface between when you
>>>>acquired the config of the area and formulated your request to replace the
>>>>config? You wipe out the interface config without even knowing that you did
>>>>so. That, to my mind is a serious flaw.
>>>>
>>>>Another flaw, to my mind, is that it is not clear what is being requested. Is it the
>>>>creation of an OSFP instance and an OSPF area and an interface and an MD5 key? Or is it
>>>>just the creation of just the key? If you make a mistake in providing the ID of the OSPF instance
>>>>you will accidentally create an instance that you did not intend to create. It is far
>>>>to easy to make a serious configuration mistake.
>>>>
>>>>In my opinion, the XPath spec of the target, or the nested elements that
>>>>lead up to the op="delete", specify the target and are not part of the target
>>>>configuration data. The transaction that operates on the device configuration
>>>>should be distinguished from what you will get from a request to serialize
>>>>the configuration state. (get-config) Doing configuration by merging
>>>>or overlaying config trees seems simple on the surface. But it is a bad model for
>>>>device configuration. If you cannot safely request that, for example, an interface be deleted
>>>>without risking the silent destruction of someone else's configuration changes, the
>>>>design is flawed.
>>>>
>>>>Larry
>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Larry Menten Lucent Technologies/Bell Laboratories
>>>>
>>>>Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA
>>>-- Larry Menten Lucent Technologies/Bell Laboratories
>>>Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA
>>
>>
>
>--
>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/>