[j-nsp] EX-series automation, NETCONF woes

[Ross Vandegrift]

On Wed, Jan 28, 2009 at 11:00:27AM -0500, Joe Abley wrote:
> On 27 Jan 2009, at 16:23, Ross Vandegrift wrote:
> >3) XML is far more complicated than SNMP with marginal benefits to a
> >switching environment.
> 
> This whole message was a great read, and I'm glad you took the time to  
> write it. On this particular point, though, I think you need to  
> compare apples with apples.
> 
> XML is a data representation; SNMP is a protocol. It would make more  
> sense to compare XML with ASN.1, in which case I'd assert ASN.1 is far  
> more complicated -- to the extent that you don't think about  
> constructing or parsing PDUs by hand, and instead use tools to do the  
> job for you.

Well, that's a fair enough point, but not really what I am getting at.
I'm really concerned about the consequences of using XML vs. ASN.1 and
how this affects the naming of things I need to find.

Using ASN.1 with SNMP, I always know how to reach the table of
interfaces.  This is defined in the IF-MIB: .1.3.6.1.2.1.2.2.  All of
devices that implement the IF-MIB use this fixed name.  This makes it
easy for the developer to know where to go for specific information.

In XML with NETCONF, the namespaces mean that names of things aren't
fixed.  For example, on an EX switch with JUNOS 9.2R2, my interfaces
are found under the XML element named:
"<http://xml.juniper.net/junos/9.2R2/junos-interface:interfaces>".
Now let's upgrade to JUNOS 9.3R2.  The same interfaces, in the same
configuration, are now collected under:
"<http://xml.juniper.net/junos/9.3R2/junos-interface:interfaces>".

See how the name in the tag changed based on the version?  XML parsers
enforce proper use of namespaces to maintain document structure.  You
can't search for the "<interfaces>" tag because there is no such tag!
You have to search in a namespace, and that means writing code that
generates version-specific naming for JUNOS.

I'm not saying that ASN.1 is necessarily simpler.  But because the
namespace is global, implementation of ASN.1 in SNMP forces vendors to
produce consistent names.  NETCONF fails to enforce that, permitting
vendors to run wild with their own names and come up with schemes that
are difficult to handle programmatically.

> If you take the same approach with NETCONF and use tools to generate,  
> validate and parse request and response documents, then I'd suggest  
> that the difference in complexity boils down to how good your tools are.

Yup - and that's been my approach.  I have a library that abstracts
out the hacks I had to do to parse the serialized XML before I give
it to the XML toolkits.  It's ugly, but it does work.

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie