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

Re: XMLCONF Proposal

Margaret,

Thanks for the reply!  Yes, I did want to sent it to the list,
and I'll take this opportunity to apologize to the list for
mis-categorizing a couple of recent messages.

My responses are inline:

Margaret Wasserman wrote:


Hi Larry,

Thanks for the feedback.

But, did you mean to send this to the list?  I am less likely to
answer this completely than some of the more XML-saavy authors.

At 02:51 PM 5/8/2003 -0400, Larry Menten wrote:
This is very clear to express and, in this example, less disruptive of the operation
of the target protocol implementation.

In what way is this less disruptive?
For example, modifying some OSPF configuration parameters
will require the router to drop one or more adjacencies and reestablish
them. Most implementations have code to prevent the waste of network
and processing resource by repeating adjacency attempts to soon after
the last atttempt failed and code to delay reflooding the router LSA to soon
after the last change. If making a configuration change cannot be done in
one atomic operation, then the router may become unavailable throughout the
network in the routing calculation. In a large SP network, this can have large
repercussions by causing a large amount of traffic to shift from one network
egress point to another. Then, when the router LSA is reissued, all the traffic
swings back to the previous egress point.

SNMP can express these atomic operations with a PDU that represents a
mix of variable add and modify operations. The representation of the Enns
document cannot.

We need to make network management operations more robust. The Enns
spec would make it more difficult to, for example, configure a router without
disrupting the routing flow within the network because it will force repeated
modifications to, for example, the router LSA, when those changes should have
made together in one operation.
We have used this approach extensively
in the context of routing protocols and related subsystems after having explored a
representation similar to the one proposed in the Enns draft. We have found that
placing the operation with the target element is a much more powerful approach.

How/why is it more powerful?
It is more powerful because it allows the expression of a mix of add, replace, and
modify operations in a single atomic operation and expresses them in such a way
that it the entire transaction is easy to read, create, and understand. The Enns draft
would require multiple separate transactions that are each more difficult to create and
visually parse.
In short, the representation that we use can express many desirable transactions that
the Enns spec cannot and expresses these more powerful transactions in a clearer syntax.

We have avoided putting data in attributes, because that causes
parsers to use more memory during XML parsing...

We parse our transactions using SAX event driven parsing and will much less
memory alocation than would typically be required by the Enns approach that
requires the entire transaction to be created as a DOM tree in memory. The
larger memory cost that you refer to is a direct consequence of the DOM tree
representation that is forced upon the implementer by the choice of representation.

In most senses, the two representations that you sent are
eqivalent, although I agree that your representation is
more concise.

The representation that I sent expresses transaactions that cannot be expressed at all
in the Enns representation.

In addition, the representation that we use allows the transaction to be parsed incrementally.
When the start-ement event has been received for an interface element, for example,
all of the information required to modify the configuration is present at that time. If the
transaction expresses that a new interface is to be created, all of the information necessary
to do so is present before the children need to be processed. This vastly simplifies the
processing of the transaction and assures that the implementer is more likely to get it right.

As another example, it is often the case that an element of configuration has a unique
key of one or more parts. In the representation that we use, all of the components of the unique
key are in the list of attributes and we can immediately verify that the element is present for
a "get" operation, or that it is not, if the operation is add. By contrast, the Enns representation
requires that the children be searched for the element names that identify the key fields and then that
the text value of the element be extracted to acquire the value. This is unnecessarily
complicated, more expensive to process, and makes the transaction more difficult
to parse since the key fields are at down among the children of the element.

The decisions reflected in the Enns document would make it impractical to implement
the new management protocol in a SOHO class device.

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