[j-nsp] NETCONF in Junos

[Phil Mayers]

On 24/12/2015 09:10, Phil Shafer wrote:

> The real value is that the API comes for free, since it's using the
> same internal plumbing.  This means that when a feature ships in
> the CLI, it's immediately available in the API.  No lag.  No
> additional cost.  No missing bits.  It's literally all there (with
> the exception of terminal-oriented commands like "monitor interface",
> etc).

I keep having to explain to other vendors and fellow engineers why this 
approach is so valuable, and so inherently superior to off-box 
middleware "API" solutions or obfuscated "SDK" blobs.

What's the cause of the few/occasional commands where "| dis xml rpc" 
doesn't work (e.g. "show virtual-chassis | display xml rpc")? I'm 
assuming CLI must know how to format it as XML to send it to MGD.

In the example I've given I think that command might be an alias to 
"show virtual-chassis status" as the output is identical and "| dis xml 
rpc" does work there. I've come across a few others, but memory is 
failing me this close to Christmas!

> Sorry if this got a bit long, but honestly it was a soft pitch and
> I couldn't resist bragging about my baby.  ;^)

You should be justly proud of it. JunOS has its faults, but it's API and 
config model are the best in the industry by a very large margin IMO.

FWIW the only two things I can cite as dislikes are the 
infinite-stream-of-XML for Junoscript (solved in Netconf of course) and 
the somewhat inexplicable embeddeing of the running software version (as 
opposed to a semantic version) into the various /junos-* XML namespaces, 
which makes them a bit of a bore to process with a namespace-strict XML 
library.

But both of those are trivial to resolve, compared to (say) running 
expect against an ever-changing human-readable CLI!

Cheers,
Phil