Vendor Neutral
And then Bilbo held the router up to the light and wondered aloud… Whatever is, vendor neutral?
Vendor neutral certainly receives a lot of play in the world of network engineering. You might have even heard the words come out of my mouth during my case study on the Telepost Greenland network at Interop a couple of weeks ago. Maybe even more than once.
But what does vendor neutral actually mean?
Does it really mean, “Can I buy my next piece of equipment from any vendor I like, and not worry about it working in my network?” Or, perhaps, “Can I buy my next piece of equipment from any vendor I like, and not worry about it disrupting my network management and operations?” The second question is the harder, in the real world — and one we’re not likely to get an answer to any time soon.
What about an open API into every piece of equipment in your network? That would be nice — but how do we get from where we are today to that nirvana? We’ve had the drive towards a MIB based interface, a common set of command line configuration constructs, several API driven attempts around TCL, PERL, and other languages, a drive based on XML (encompassing things like BEEP), and — most recently — the drive based on the YANG modeling language and NETCONF.
After 20 years in the networking industry, and seeing the many false starts in this direction, I have to ask — where have we gone wrong? We’ve put many years of work into designing and building common mechanisms to talk to our networking devices across vendors — to find a vendor neutral way to design, build, and manage networks — and still we’re back to the same old CLI. Sure, we’re bound to get a GUI before it’s all over with, but anyone can look at the world of GUIs and realize that’s not going to solve the problem.
Why, when the underlying constructs are so similar across so many different types of devices, when the actions that can be actually be affected on a single packet passing along the wire are seemingly so few, do we still have this vendor neutral problem?
It would be easy enough to blame the vendors — after all, if you’re a vendor, vendor neutral isn’t exactly something you’re going to sell, is it? “Sure, feel free to buy my competitor’s gear — I’ve spent hours making certain it’ll all work together,” is not something you expect your vendor’s sales rep to actually say, is it? It would be easy enough to blame the customers, too — “the reason you don’t get vendor neutral is because you don’t condition what you buy on it!”
But as easy as it is to play the blame game, my Mom (hi Mom! at least somebody reads my blog!) always taught me to fix the problem, not the blame.
If we turn to the PC market as a rather imperfect example (yes, I’ve been here before), why is it you can buy a computer with a range of processors, hard drives, and memory manufactured by different companies, and it all works? Well, it might not work perfectly, but it will — generally — work.
The basis for this type of market is, I think, that the software makers are at least nominally separated from the hardware makers. They’re forced, by the arrangement of the market, to work with one another across an API. For the coder, making software that works across a wide range of hardware platforms increases profit — and for the chip maker, making hardware that will support a wide range of software increases profit. Hence both sides are encouraged — even demanded — to play to a middle range where their interests overlap.
Vendor neutral, in the computer world, doesn’t mean I don’t use a particular brand of software, nor a particular brand of hardware. I don’t just “own a generic white colored laptop,” I own a Lenovo X1 Carbon. I don’t just “use a generic word processing program,” I use Word, WordPress, NotePad++, Dreamweaver, and a few other tools to manipulate text. It doesn’t mean everything is interchangeable. In other words, vendor neutral doesn’t mean, “I don’t care which vendor I use.”
What it does mean is — “I can use a range of hardware vendors with this software, and I can use a range of software vendors with that hardware.” And, in so doing, I can still get what I need done, done. It means I can buy servers from two different companies and still manage them in a way that makes sense.
Looking at the networking market, we have nothing like this today — and perhaps that’s what the problem is. There is little reason for a networking vendor to make their software “the best,” if they’re selling on port counts. There’s little reason for a networking vendor to make their hardware “the best,” if they’re selling on software features. There’s little emphasis on selling software that will run across an entire ecosystem if you can only run it on the vendor’s hardware in the first place.
This does seem to be changing. Ericsson, where I work, is productizing IPOS so it will run in the overlay or the underlay, on a wide array of hardware. This doesn’t mean Ericsson is going to stop selling hardware — to the contrary, Ericsson is just coming out with a new line of routers, and ramping up some new (interesting) silicon. But they are separating software from hardware in a way that might prove useful towards making the words vendor neutral mean something. Cisco’s “secret white box play” seems to be running down the same path, as well as Juniper’s recent partnership with a white box player to bring JunOS to different hardware platforms.
By dividing the software and hardware piece of the networking world, we might actually get to something like what we mean when we say, “vendor neutral.”