[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation of configuration and control - good or bad?
At 12:18 PM 5/15/2003, Larry Menten wrote:
>Andy,
I still don't see big differences or understand the
"two separate XML trees" argument.
In any scheme, the device being configured will have
to figure out which exact spot in its internal representation
of the configuration the incoming request applies to.
This is no different than CLI or SNMP. I don't see
where the code doubles for one scheme vs. another.
Examples would really help me understand this better.
In our code, the component-specific callback routines
are somewhat decoupled from the XML representation.
E.g., whether the 'operation=create' parameter is
outside the data-model, an embedded element, or an
attribute doesn't matter that much, because the XML
will get converted to a C structure before the method
routine is called. There would not be multiple method
routines, based on the XML structure. The details of
the C structure would change, though. In any case,
these are implementation details, and the different choices
I've seen do not have a huge impact on the overall code size or
complexity.
This is not to say that the granularity of the protocol
operations (outside the data model, nested above the
elements, or embedded as attributes within the data model
elements) does not have an impact on code complexity.
This complexity is greatly impacted by the 'stop-on-error'
and 'all-or-none' type of options in the <eidt-config> operation.
Hopefully we can summarize the different protocol operation
proposals soon. It would help to see the same simple example
used to demonstrate each proposal. Anyone want to attempt
that summary yet?
Andy
>If control operations (clear LSDB,...) are separated
>from configuration operations (change retransmit-interval),
>then two different kinds of transaction must be expressed.
>This will require twice as much text to represent the transaction
>since the subtree must be duplicated.
>
>The configuration operations will be parsed by code that
>interprets configuration operations, control operations will
>be processed by code that can interpret control operations.
>
>This is necessary because the config operations create a persistent
>config state file while the control operations are not retained in
>state.
>
>There is more text to exchange in the transaction, more text to parse,
>and two different parsers to implement. Assume that the purpose of the
>control operation is closely related to the config operation. The two
>closely related operations are now in separate XML trees in the transaction
>and it is now less obvious upon reading the transaction that the two operations
>are closely related.
>Furthermore, the management code must accommodate a different syntax for these
>control command. More code.
>
>Larry
>
>
>Andy Bierman wrote:
>
>>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/>
>>
>
>--
>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/>