Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

How Did NETCONF Start on Software Gone Wild

A long while ago Marcel Wiget sent me an interesting email along the lines “I think you should do a Software Gone Wild podcast with Phil Shafer, the granddaddy of NETCONF

Not surprisingly, as we started discovering the history behind NETCONF we quickly figured out that all the API and automation hype being touted these days is nothing new – some engineers have been doing that stuff for almost 20 years.

Phil Shafer designed Junos to have CLI on top of internal API in 1997, and his main ideas were:

  • Everything available in operational and configuration mode is accessible to external applications via API
  • API should be release-independent and survive software upgrades

The Junos API was always there, and after it was made public in 2000, Phil tried to push this same idea through IETF. 15 years later we’re finally making some multi-vendor progress.

However, some Juniper customers quickly realized how useful that approach is: they were modifying device configurations with automation tools decades ago and there were environments where changing device configuration via CLI was a fireable offense in early 2000.

We spent the rest of the podcast discussing NETCONF history and evolution details, including:

  • Why they decided to use XML instead of JSON
  • Why is JSON easier to parse than XML?
  • Why it’s easier to troubleshoot XML documents than JSON data structures
  • Why it’s easier to extend XML than JSON
  • Why is NETCONF so watered-down compared to what Junos does
  • Why should you use NETCONF or gRPC to read operational data instead of SNMP
  • Why NETCONF won’t replace SNMP
  • What streaming telemetry is, why it makes sense and why it usually uses UDP
  • Why NETCONF notifications could be more dynamic than SNMP traps
  • Why RESTCONF appeals to programmers with only two hammers in their toolbox
  • What the difference between YANG (data model description) and XML/JSON (data model representation) is.

You’ll find them all in Episode 85 of Software Gone Wild.

2 comments:

  1. Haven't listened to it yet, but great idea! I was there when it started (including its pre-history at IETF, RFC 3535). The way in which Phil and his colleagues at Juniper shared their concept in the Netconf effort was an incredible contribution to the community. And they handled the unavoidable (even at IETF) committee-driven "improvements" (well a few probably were...) with such selfless elegance it almost drives me to tears even now :-) Huge respect!

    ReplyDelete
  2. Back from listening to this very good podcast. As expected, everything Phil says is interesting and extremely clearly expressed. I would also like to say he's totally right about everything, but there was one thing I have doubts. That's the idea that when you stream telemetrics "from the hardware" you can't use TCP. (That was Cisco's position over in the IPFIX WG, and though I really tried very hard to let me be convinced by them, I never managed to accept that. Maybe they (and Phil) are right, but at least in this case I'd be in good company (Van Jacobson's). Yes, it's harder with TCP, but it's worth the effort.)
    So: 100% of what Phil says in the podcast is super interesting and clear, (at least ;-) 99.8% of it is also right on the mark.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Sidebar