Grumpy Monday: HP and OpenFlow

HP has recently released OpenFlow support on a few more switches and some people think it’s a big deal. It just might be if you’re a researcher with limited grant budget (which seems to be one of the major OpenFlow use cases today); for everyone else, it’s a meh. Lacking a commercial-grade OpenFlow controller supported by HP (or at least tested with HP switches), OpenFlow on HP switches remains a shiny new toy.

You know that OpenFlow protocol provides nothing more than a standardized way to program a device’s forwarding plane with a remote controller. When you deploy OpenFlow, you move the network intelligence from switches to controllers. That’s definitely an annoying proposition if you invested a lot in the embedded software like Cisco did; however you look at it, OpenFlow-enabling your switches just for the sake of having OpenFlow API inevitable dumbs them in the long run.

Offering OpenFlow-enabled switches probably makes sense to three categories of vendors:

  • Vendors that excel in low-cost manufacturing based on merchant silicon. These vendors might want to avoid the R&D costs associated with developing proper switch software, offer OpenFlow interface, and hope that someone else will develop the controller;
  • Vendors that want to disrupt the landscape and use OpenFlow to offer new controller-based functionality that cannot be implemented with standard protocols. NEC and BigSwitch clearly fall in that category.
  • Vendors that combine OpenFlow with other technologies in interesting and innovative ways. For example, Juniper uses OpenFlow to push traffic into traffic engineering tunnels or VRFs.

HP? None of the above. They claim they’ve been working on OpenFlow technology for years, but when they talk about it, they use baseline open-source controllers to demonstrate the supposed benefits of OpenFlow (as they did at the recent PLNOG event, where the presenter tried to demo HP switches working with NOX controller). That’s an extremely disappointing approach coming from a company that created a landmark network management system and still has remarkably good offering in this space.

So, when HP launches an OpenFlow controller with functionality you can’t get everywhere else (or at least with functionality you can’t get from existing networking devices and protocols), please let me know. In the meantime, releasing OpenFlow support on yet another low-cost switch sounds like buzzword-surfing or residual-value-extraction strategy to me.


  1. Ivan, you're not being grumpy!!!! You speak facts - the truth.
  2. Hey Ivan, when referring to HP still having a "remarkably good offering in this space" - are you talking about IMC (from the H3C acquisition), or NNM+related products (i.e. the current iteration of what started out as Openview) ?

    Just wondering, it wasn't clear to me from the link you gave there. Wasn't sure if they showed you IMC at the Net FieldDay or not.
  3. Couldn't find the product name in my notes - yes, it was IMC. Thank you!
  4. IMC is an interesting product. I've been doing a bit of work with it recently. There's a lot to like about it, but there's still quite a few rough edges. What I do like is the extensibility. Right now a lot of the device management stuff is just TCL/expect under the hood, but it's a framework, and I would expect you could easily change that to use something like NETCONF.

    Would be nice if they would get around to releasing the list of supported devices - it's not publicly available currently. Hopefully later this year. Right now, you have to try it out, and fix up the expect scripts yourself. That's part of what I've been doing the last week, trying to get ASA configs managed by IMC. As I said though, it's extensible, and there's nothing stopping you going and making those changes yourself. Makes a pleasant change to some other products I've been using, where you need to wait for a patch to support a new device.
Add comment