[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Netconf! Part Deux
I've been away for a bit (and will be out next week also),
so I'm still catching up on the netconf mailing list, but I'm
amazed that we're still having the same discussions. I don't
know that I can add anything that hasn't been said repeatedly
in the past, but here's my take.....
(I) Attributes .vs. Elements
The attribute .vs. element discussion has been repeated here and in
other xml-oriented circle, but it always ends up at the same spot.
It's mostly a subtle distinction. Attributes introduce restrictions
that I personally don't like (lack of ordering, forced uniqueness,
namespace idiocy) but there is nothing fundamentally different
between:
<foo goo="a" boo="b"/>
and:
<foo>
<goo>a</goo>
<boo>b</boo>
</foo>
It's mostly a trade-off between brevity and expandability. Since
netconf (and xml) is meant for machine-to-machine data exchange,
brevity is pointless and future growth is everything.
Even on the brevity front, attributes start to lose when you introduce
namespaces, since a new namespace ('xmlns="foo"') does not change the
namespace for attributes. Compare:
<foo xmlns="foo" xmlns:foo="foo" foo:goo="a" foo:boo="b"/>
and:
<foo xmlns="foo">
<goo>a</goo>
<boo>b</boo>
</foo>
In any case, the choice of encoding data with attributes or elements
is a distinct topic from attribute-based operations.
(II) Attribute-based Operations
Most of the recent discussion has been about shifting from
attribute-based operations (ABO) to more "object oriented verbs" (OOV).
I don't see the win, since the target audience isn't after full-blown
object-oriented technology. The requirement is more like that of 'diff'
and 'patch', so that a configuration database can be easily modified.
ABO attributes are comparable to the '+', '-', and '!' tags
at the front of the diff lines. Data is marked with the operation
that should be performed, giving a simple mechanism for expressing the
desired change.
Consider the case where you want to change the address of an
interface. Since multiple addresses are supported, you really need to
delete the old one and add the new one. With ABO, this is simple:
<configuration>
<interfaces>
<interface>
<name>so-0/0/0</name>
<unit>
<name>0</name>
<family>
<inet>
<address delete="delete">
<name>10.1.1.1/24</name>
</address>
<address> <!-- adding a new one -->
<name>10.2.2.2/24</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
The equivalent in OOV is more verbose:
<delete>
<configuration>
<interfaces>
<interface>
<name>so-0/0/0</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.1.1.1/24</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
</delete>
<create>
<configuration>
<interfaces>
<interface>
<name>so-0/0/0</name>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.2.2.2/24</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
</create>
Not only is the OOV version more repetitive (making it harder to
generate and maintain), but the desired goal (changing the interface
address) is harder to discern from the XML. Imagine writing an xsl
template that has to generate both hierarchies rather than allowing
the normal xsl descent to emit your enclosing elements.
Somewhere in the discussion, the comment was made that we're "not
likely to add more verbs anytime soon". I strongly disagree, since
we'll need verbs to adjust the order (insert), activate and deactivate
sub-trees, renaming, copying, etc. I'd expect that all the operations
one can do under the CLI will find their way into the API.
(III) The Cost of Using XPath
Another topic was the cost of using XPath, mostly looking at the on-box
foot-print. But the real thing you lose with XPath is the ability to
use XML Schema (and/or friends) to validate what's going into and
out of the device.
Consider the following example:
> <modify>
> <target xmlns="http://example.com/xsd/foo.1";>
> /chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/duplex-mode
> </target>
> <value>auto</value>
> </modify>
> <create>
> <target xmlns="http://example.com/xsd/foo.1";>
> /chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/filters/ip-filters/ip-filter[@instance-id='1']
> </target>
> <value>
> <action>permit</action>
> <direction>both</direction>
> <address>
> <addr-type>ipv4</addr-type>
> <addr>192.168.1.1</addr>
> </address>
> </value>
> </create>
Neither the 'target' nor the 'value' elements can be validated against
an XML schema. The type for 'target' has to be xsd:string (not sure
what the namespace is meant to achieve), and the type for 'value' has
to be xsd:any, allowing any xml content. My app can't self-check the
configuration that I'm going to send to the device.
In addition, my app needs to be able to transform element hierarchies
(as returned by <get-config>) into XPath expressions.
In contrast, handling XML trees is simpler. Pulling subtrees out and
validating them is trivial.
(IV) The Third-leg Principle
One of my core beliefs about NETCONF is that it must leverage the CLI
implementation as much as possible. Vendor developer resources are
limited and developers do the CLI implementation first, followed at
some point by an SNMP MIB. If NETCONF is an additional expense, it
will fail. The trick is leveraging the developer's initial expense
developing for the CLI to also cover NETCONF. The farther the netconf
model drifts from the native model, the farther we drift toward the
Swamp of Unimplemented RFCs.
So that's my thoughts. We've had these discussions before and always
come to the same conclusions, so most of the above has been said before.
Apologies for the repetition, and for the delay in commenting.
Thanks,
Phil
--
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/>