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

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 wrote:
Keith,

To represent the transaction in multiple parts the target has to be identified.
We have used XPath expressions for this purpose as in the following example:

<transaction id="29">
        <deleteRequest opId="2" select="/root/configuration/protocol/ospf/area[@id='0']" />
        <deleteRequest opId="1" select="/root/configuration/protocol/ospf/area[@id='3']" />
        <addRequest opId="3" select="/root/configuration/protocol/ospf">
            <area id="4">
                <interface id="ge-2/2">
                    <authentication-key>
                        <keyname>gargoyle</keyname>
                        <key-id>3</key-id>
                    </authentication-key>
                    <metric>1</metric>
                    <hello-interval>10</hello-interval>
                    <dead-interval>40</dead-interval>
                    <retransmit-interval>10</retransmit-interval>
                    <transit-delay>5</transit-delay>
                </interface>
            </area>
        </addRequest>
        <addRequest opId="4" select="/root/configuration/protocol/ospf/area[@id='2']/interface[@id='ge-1/5']">
            <dead-interval>40</dead-interval>
        </addRequest>
        <addRequest opId="5" select="/root/configuration/protocol/is-is">
            <area id="5"></area>
        </addRequest>
        <addRequest opId="6" select="/root/configuration/protocol/ospf/area[@id='1']">
            <label-switched-path id="to-SFO">
                <metric>15</metric>
            </label-switched-path>
        </addRequest>
        <replaceRequest opId="7" select="/root/configuration/protocol/ospf/area[@id='6']/label-switched-path[@id='to-SFO']">
            <metric>20</metric>
        </replaceRequest>
    </transaction>

Larry


Allen, Keith wrote:

All,

 

The modeling discussions that have been going on here lately have been interesting, and I don't necessarily want to stop them.  I think they are indicative of the kind of heavy work that needs to be done.  However, I do think they are largely outside the charter of this group, which was going to focus on the protocol used to operate upon an XML configuration model.

 

I thought Larry raised an interesting point with his proposal to include an "op" attribute in the information model elements with values like "overwrite" or "insert," but I am a little troubled by the mixing of protocol operation data with the information model.  For example, if you did a dump of an XML configuration file, these attributes would not make sense.  I'm not saying that I couldn't be convinced of their necessity, just that I am uneasy.  I was thinking, therefore, of alternatives that would meet Larry's goal of not having to send separate protocol messages to combine inserts and overwrites.  I do think it is important that the protocol flexibly support the ability to invoke multiple or complicated changes with a single operation.  How about something like the following:

 

<edit-config>

            <operation-group order="sequential">

                        <operation type="insert>

                                    ...xml snippet to be inserted in config...

                        </operation>

                        <operation type="overwrite">

                                    ... xml snippet to be overwritten...

                        </operation>

            </operation-group>

</edit-config>

 

This shows individual operations, which can have different semantics - insert or overwrite (is there anything else).  Also, the operations can be grouped together and ordered sequentially or any order.

 

 

Keith Allen

SBC Technology Resources

9505 Arboretum Blvd.

Austin,TX 78759

(512) 372-5741

kallen@tri.sbc.com

 

 
<transaction id="29">
        <deleteRequest opId="2" select="/root/configuration/protocol/ospf/area[@id='0']" />
        <deleteRequest opId="1" select="/root/configuration/protocol/ospf/area[@id='3']" />
        <addRequest opId="3" select="/root/configuration/protocol/ospf">
            <area id="4">
                <interface id="ge-2/2">
                    <authentication-key>
                        <keyname>gargoyle</keyname>
                        <key-id>3</key-id>
                    </authentication-key>
                    <metric>1</metric>
                    <hello-interval>10</hello-interval>
                    <dead-interval>40</dead-interval>
                    <retransmit-interval>10</retransmit-interval>
                    <transit-delay>5</transit-delay>
                </interface>
            </area>
        </addRequest>
        <addRequest opId="4" select="/root/configuration/protocol/ospf/area[@id='2']/interface[@id='ge-1/5']">
            <dead-interval>40</dead-interval>
        </addRequest>
        <addRequest opId="5" select="/root/configuration/protocol/is-is">
            <area id="5"></area>
        </addRequest>
        <addRequest opId="6" select="/root/configuration/protocol/ospf/area[@id='1']">
            <label-switched-path id="to-SFO">
                <metric>15</metric>
            </label-switched-path>
        </addRequest>
        <replaceRequest opId="7" select="/root/configuration/protocol/ospf/area[@id='6']/label-switched-path[@id='to-SFO']">
            <metric>20</metric>
        </replaceRequest>
    </transaction>

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