[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Separation of configuration and control - good or bad?


Andy Bierman wrote:
At 12:18 PM 5/15/2003, Larry Menten wrote:

Andy,

I was thinking of the merge/replace/overlay scheme that seems to have
a different processing mode, altogether. The approach that we
use is similar to yours, however, in the context of a cntrol message
it is only the attributes that identify the target element that are meaningful.

For example, if the idea is to "reset" an ospf area, attributes associated
with area characteristics (default stub cost, ...) would represent an error if they
were encountered. The validation of the two trees is different.

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

I will do one that represents the XPath approach.


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


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