NETCONF+YANG+NETMOD versus SMI-S
With all the Puppet buzz I’m hearing and claims that “compute and storage orchestration problems have been solved” I wanted to check the reality of those claims – is it (for example) possible to create a LUN on a storage array using a standard well-defined API.
Stephen Foskett, Simon Gordon and Scott Lowe quickly pointed me in the right direction: SMI-S. Thank you!
Reality based on public information
You know I had to check whether SMI-S really delivers on its promises. It does; just check all the things you can do on block devices (and there’s plenty more). One must wonder how the storage industry got its act together and actually created a full management framework while the networking industry doesn’t even have a standard mechanism to assign an IP address to a router interface (draft-ietf-netmod-ip-cfg is still a draft). It looks like the networking experts working in IETF working groups love to reinvent heptagonal wheels.
SMI-S is based on CIM. All it does is define the CIM objects used to manage storage entities. Problem solved.
IETF has (so far) created two working groups to solve the device configuration problem:
- NETCONF group, which had to invent an XML-based protocol and a novel way of transmitting XML documents over an SSH session (which took three years), because HTTP (that everyone else is using) just wouldn’t be good enough.
- NETMOD group which had to invent a new data modeling language (YANG), and only then focus on what we really need – configuration data models that describe data structures one has to send to a device to get the job done.
Not surprisingly, SMI-S got from rough ideas to interoperability testing in three years (2000-2003) and became ANSI standard a year later (2004).
NETCONF working group started in 2003 and produced the first standards (NETCONF and NETCONF over SSH) in late 2006.
NETMOD working group started in 2008. I don’t want to believe nobody realized we actually need common data models to configure devices from multiple vendors ... but then maybe with NETCONF being a more reliable version of Expect the people who already implemented their own layer of abstraction in their home-brewed multi-vendor provisioning scripts got what they needed (reliable transport), so they stopped caring.
Anyhow, it took 2 years to develop YANG (in 2010) ... and only then NETMOD group started working on actual data models. A decade after NETCONF started, we don’t have a single usable RFC that two vendors could take to implement a common way to configure something as simple as an IP address and a mask on an interface.
It’s perfectly possible that I got it all wrong, and that nobody uses SMI-S. VMware sure doesn’t; on the other hand SMI-S is part of Windows Storage Management API in Windows Server 2012. It could also be that CMI is way too complex for real life (so NETCONF+YANG actually makes more sense), although Microsoft seems to be pretty happy using it for its management APIs. Any pointer to real-life experience with SMI-S is highly appreciated.
As for lengthy IETF standardization process, it’s no wonder initiatives like Open Networking Foundation want to initiate their own standard development process.
Yes, there are steps in the IETF process that could be optimized away, noone (hopefully) argues that.
Now, it would be very interesting to hear your opinion on the technical aspects on CIM/SMI-S (especially the CIM part) and NETCONF/YANG if you had time/interest to dive into them in more detail.
Interestingly enough I've had several requests over the last few weeks to translate CIM models (there are many of them) and also TR-69/181 models into YANG to be accessed using NETCONF (and REST). Perhaps there is some timesaving to be done here?
Also; keep an eye out for I2RS that seems to be gravitating towards NETCONF/YANG perhaps for some real technical reasons?
From http://blogs.technet.com/b/filecab/archive/2012/06/25/introduction-to-smi-s.aspx :
"Because SMI-S is an industry standard built on top of other standards and widely implemented in other environments (such as VMware® and AIX®)..."
I haven't found anything telling me how VMware uses SMI-S to discover storage or LUNs (for example), they only thing I found in the direction ESX->storage was VASA (http://www.vmware.com/products/datacenter-virtualization/vsphere/storage-api.html#awareness)
So, clear as mud, I guess. :)
Thanks for this fantastic blog :-)
Alan Yoder, SNIA Technical Council, SMI Governing Board
Check out MMS 2013 overview of VMM storage management: http://channel9.msdn.com/Events/MMS/2013/WS-B314.
Slides 70-71 lists all partners that support SMI-S http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2fvideo.ch9.ms%2fsessions%2fmms%2f2013%2fWS-B314.pptx