Dear $Vendor, NETCONF != SDN
Some vendors feeling the urge to SDN-wash their products claim that the ability to “program” them through NETCONF (or XMPP or whatever other similar mechanism) makes them SDN-blessed.
There might be a yet-to-be-discovered vendor out there that creatively uses NETCONF to change the device behavior in ways that cannot be achieved by CLI or GUI configuration, but most of them use NETCONF as a reliable Expect script.
More precisely: what I’ve seen being done with NETCONF or XMPP is executing CLI commands or changing device (router, switch) configuration on-the-fly using a mechanism that is slightly more reliable than a Perl script doing the same thing over an SSH session. Functionally it’s the same thing as typing the exec-level or configuration commands manually (only a bit faster and with no auto-correct).
What's missing? Few examples: you cannot change the device behavior beyond the parameters already programmed in its operating system (like you could with iRules on F5 BIG-IP). You cannot implement new functionality (apart from trivial things like configuring and removing static routes or packet/route filters). And yet some $vendors I respect call that SDN. Give me a break, I know you can do better than that.
First of all, the layering violation in the "NETCONF != SDN" phrase is... challenging. No, NETCONF envelopes around current CLIs (*cough*cisco*cough*) does not result in SDNishness. But that is, frankly, a little unfair to the protocol (NETCONF) and the modelling language (YANG). See, it would be trivial (but utterly pointless) to reimplement the OpenFlow protocol in NETCONF and YANG. Would such an exercise result in "NETCONF == SDN"?
Perhaps another interesting approach to this is to look at the canonical uses cases that are proposed in SDNland. The recurring pattern is that they require access to features below (in terms of abstraction) what's exposed through SNMP and CLI in traditional systems. There is nothing in the protocol itself, of course, that stops $vendor development teams to expose lower-level APIs through it. It's more a side-effect of what (almost) all router and switch vendor software architectures look like.
We're starting to see service provider teams and software developers warming up the potential power of this "reliable Expect script" (I'll let that rest for another blog post comment ;-) and are doing quite interesting things with it. As an example, there's a presentation on "Network Configuration Management and Service Activation" from NORDUnet available here (seems like the sound is gone for the first 5 mins): http://bit.ly/Vo2YMo No, this might not make it formally achieve SDNification, but it's an example of using software to program a NETCONF-enabled network.
However, based on how undefined SDN is, and how malleable to type-casting it is, it's probably comparable to anything, so my comparison is valid ;)
The fact of life is (although both of us know better) that most people see NETCONF as "configuration management tool". All implementations I've seen so far use NETCONF as CLI replacement, and even the new drafts appearing in NETMOD working group focus on configuration aspects.
While there's nothing that would stop NETCONF+YANG (or SOAP+XML+XSLT or REST+JSON or BGP+new-AF+communities or ...) from becoming a universal transport protocol, that's not how it's used today, and that's not what the SDNwashing marketing people are trying to sell us.
As for the "what can be done with NETCONF" - I had a fully automated web-based customer provisioning system in 1993, and it included core router and access server configuration, so I know pretty well what CAN be done if someone decides to do it. Our FlipIT service is another good example - it auto-provisions everything from customer VMs to firewalls and Cisco Call Manager.
However, yet again, even in those cases NETCONF is just a slightly more reliable transport protocol until the vendors actually implement things that are in NETMOD drafts 10 years after the NETCONF group was formed. I would call that glacial progress, but maybe I'm still young and restless.