Rant: Our Vendor Partners Dont Have an SDN Vision

There is an old saying “A man with his eyes fixed on Heaven doesn’t see where he is walking”. It’s an almost perfect description of how the major vendors are approaching Software Defined Networking. The consistent message from all the vendors and especially Cisco, Juniper and Brocade, is that there are “no use cases for SDN“. In the last three months, it’s been constantly repeated statement both publicly and privately during briefings. This beggars belief that vendors can’t see immediate needs that deliver long term gains. So I’m going to have a go at it.

Watching Heaven

1126962 cheshire matterhorn 2

I suspect that the root of this problem is the big companies want to solve big problems. And by solving big problems they figure that they can make big revenue. Alright, I get that. It’s understandable that large organisations need a constant revenue stream to feed the insatiable maws of their shareholders. However, the vendors re also missing the most real and immediate problem of networking today. Simply, Networking is too hard.

Vendors haven’t developed tools or solutions that keep the complexity of networking under control. I feel that complexity can be reduced to this: “I don’t have big problems, I have lots of small problems.” By and large, networking has solved most of the big problems. Scaleable WANs, routing, redundancy, security (mostly/ongoing), speed / bandwidth are all more or less in hand. What I’m left with are piles of operational problems. Small, niggly problems that are costing a lot of money.

You can have debates about addressing complexity and how to attack it, but it nearly always boils down to this: start small.

Small Problems – VLAN provisioning

Here is the my smallest and yet most expensive problem: VLAN provisioning. In a data centre or campus network, I need to provision network ports with VLAN allocation.  Today, some poor schmuck has to decide which VLAN is needed for a given port the configure the VLAN on the access switch, then on every distribution switch in the path, then on the core switch, and then on EVERY trunk port and port channel that it is in the path. That requires an engineer to identify the path using hand made diagrams, then login at the CLI and verify the configuration on every device.

It’s 2012. I’m still doing it by hand. 

Why can’t I have an SDN application acccept the request to configure a port in a VLAN, then analyse the switch path across the network and suggest a proposed configuration across the network ? Why not a button that would deploy this configuration ? Why not a graphical interface that shows a dynamic map of VLANs by mouseover on a web page 1

Can you conceive how much money this would save Data Centre operations teams ? A guaranteed analysis and repeatable process for provisioning VLANs should become reliable over time, then consistently repeatable and finally a routine network change. Today, every VLAN provision is a Cat1 change for STP risk and costs thousands of dollars in incidental costs for a single VLAN propagation.

How can vendors not see this as an obvious use case ? How can vendors not want to help their customers with this problem ? Equally, there are dozens of similar use cases that could easily be solved by vendors with a simple open source project and just a small amount of resources.

Big Problems need a Small Start

Vendors have announced that they will provide APIs in their respective device OS’s . But there is zero evidence that vendors are planning to help their customers with SDN software. The major vendors can’t even formulate a strategy that will help customers use this new technology by providing leadership and vision.

How many times have you sat through a vendor presentation where they declaim loudly their market leadership and industry first features, or what about their market knowledge. Right now, all we are seeing is mute ignorance. Here is the message we get today : “All right, you want SDN ? Oh alright, stop whining. We will give you some APIs and programmatic access. We are done. Your turn“.

That’s not leadership or visionary. That’s reaction to the customer demands.

The EtherealMind View

The vendors need to stop thinking about billion dollar revenues, focus on core competencies and solve the smaller problems that really affect day to day operation. You know, the ones that haven’t been solved in the last decade. The ones that have lost the the trust of the server admins, storage teams and the managers. In my experience, CIO’s aren’t investing in networks because of the constant problems and hassle. Have you heard the that joke about “Does it hurt when you press there ? Yes ? Well, don’t press it”. This applies to networking. The CIO doesn’t understand networking at all because it’s too removed from his experience but he/she certainly knows they don’t want to have more massive failures. It’s reasonably common for a single network failure to impact the entire business. This impact is freezing network changes to point of stagnation. In my daily work, it’s difficult to convince to exectives to invest and upgrade because the fear is palpable. The Network Is A Problem.

We need to urgently get away from twiddling fingers and work on software driven network configuration and management for consistency, repeatability, automation and operational cost management. We need to reduce the impact of change management and risk driven design, so that we can move the network from being “necessary” to the realm of critical infrastructure. Network architects need the ability to improve the architecture and deliver business benefits. We ned to return to Network Engineering instead of building with Lego blocks.

Take your Eyes off Heaven

Vendors, here is the apparently non-obvious reward. Once we are using SDN tools for day to day operations, the fundamental software components will be in place. We will have the latest OS versions installed with the new features. We might have developed trust in your new APIs for the little things. Then we will be able to dream of bigger things. We can imagine tackling bigger projects. And our execs and managers will be able to trust us. They will believe we can deliver a network that can be changed. Then we can implement those big dreams in a couple of years time.

The Networking market has been let down by the major vendors and this lack of vision repeatedly in the last decade. Network Management and Automation is a wasteland of failed opportunities. We have to hope that startups and sundry open source projects can fill the gap in the next few years. I say that the big vendors, our so-called “partners” certainly aren’t offering innovation, vision, or even a competent debate on the future of SDN and Networking.


  1. for example, a list of VLANs on the side of a web page. Mouseover a VLAN number and a highlighted path would be overlaid on the network topology.  ↩

PS: Here is a screen capture of Cisco Open Network Environment web page on launch day. Telling, isn’t it ?

Compare it with the page today


Cisco Open Network Environment  Cisco Systems

  • dualband

    I’ve been excited hearing about the development of OpenFlow and the creation of the ONF. Network engineering needs to be more open not proprietary. That’s why Cisco’s “SDN” announcement really disappointed me. Especially since I am looking to migrate to Cisco from Avaya/Nortel (after they bombed on the Nortel acquisition). We are locked in with proprietary SMLT architecture right now, which prevents us from doing trivial things like multicast. The idea of being locked into Cisco One does not impress me. I’m looking more towards Big Switch Networks to be honest, since we are faced with a lift and replace any way. Juniper has fantastic hardware and software, but they are wicked expensive for a small/medium Enterprise, and most switches are overkill for our needs. Anyone else but me notice how all the switches are geared towards huge network operations these days? I don’t require 48 10G ports per switch, or terabit backplane speeds. Like Greg says, I have a lot of small problems that need to be resolved, and most of all I need network segment isolation without managing 600 ACLs and 1500 VLANs,….Manually! Good luck with those big cloud customers Juniper and Cisco, I’m sure they will bring you much profit, I’m going to hold out for startups to get products to market before I make a decision. I’ve been stuck with crap for so long, a couple more years won’t matter.

  • dbknill

    Let me start by saying 2 things: (1) Greg, it was a pleasure to meet you last week in the meatspace at Cisco Live, and (2) I feel really sorry for anyone who configures lots of VLANs on a regular basis.

    I generally agree with your sentiment in this post. I can think of another glaring use case: LAN/WAN QoS configurations. At least as of a year ago, I could count on two fingers how many vendors had a packaged solution in place in order to provision QoS on a Router or Switch through a GUI interface, and even then it wasn’t end-to-end. I don’t think much as changed since then.

    When it comes to automation of network configurations, it does seem that we’re still in the stone age. It would seem that the incumbent networking vendors won’t really start making this happen until they are forced to do so through potential loss of business (i.e. customers absolutely demand these capabilities). The ability to operate a network does seem to be an after-thought in most device purchase decisions.

    That said, even if there is a strong business driver, it does seem like it’s still pretty complicated. One thing that seems to be relatively apparent to me is that the control plane must be centralized to some extent to provide enough abstraction so that automation can be made much easier. Art Fewell has an article that explains this fairly well in his NW article titled “Cisco ONE: Proof that Cisco doesn’t get SDN’s” (his opinion – not necessarily mine) . He used an example of how difficult a wireless network was to manage with Autonomous Access Points, and moving the network to a controller-based solution (i.e. Centralized Control Plane) made management substantially easier. I’m sure this point has been made many times.

    We’ll see. It doesn’t seem to me that adding a few APIs are going to make a substantial difference for automating network configuration. Centralizing the control plane will.

    • http://twitter.com/northlandboy Lindsay Hill

      “…the incumbent networking vendors won’t really start making this happen until they are forced to do so through potential loss of business (i.e. customers absolutely demand these capabilities)”

      I think this might be getting to the heart of the matter. It’s not just the vendors, it’s the customers. How many network engineers actually have the skills, and the longer term vision, to recognise that they can’t continue to operate the way they always have? How many have you seen that will cut and paste the same config repeatedly, with even simple scripting outside of their realm? How many of them will demand better network management/orchestration? They just do what they do, the way they’ve always done it.

      There’s more to it of course. I feel a Packet Pushers blog post coming on…

  • Francesco

    We don’t have to wait SDN for VLAN Provisioning… GARRP?

  • Albert Rider

    Greg, I am curious why you feel that SDN is required to automate VLAN provisioning. There is a variety of ways to automate VLAN provisioning via existing set of NMS tools. How do you think SPs have been doing this for years?

    If that’s the case of re-labeling good network management practices as “SDN” – that’s fine. But it’s really just a game of spin and buzzwords.. Similar to us now having re-labeling our internal networks as “Private Clouds” to make our management happy.

  • Flintstone

    Don’t forget Cabletron’s Securefast Vlan Manager was doing just that 15 years ago.

    In reply

    “Why can’t I have an SDN application acccept the request to configure a
    port in a VLAN, then analyse the switch path across the network and
    suggest a proposed configuration across the network ? Why not a button
    that would deploy this configuration ? Why not a graphical interface
    that shows a dynamic map of VLANs by mouseover on a web page”


  • hartley231

    In fairness he was talking about Openflow 1.0*, but it looks like you can add Arista to the “no or limited use case” vendor list.


    * not sure why the industry isn’t collectively talking about 1.1, 1.2 or 1.3 considering the dramatic changes from 1.0

    • http://etherealmind.com Etherealmind

      The differences between OpenFlow 1.0 and 1.3 is to subtle for most people to be able to discuss.

  • Pingback: Will Engineers Hold Networking Back?()

  • mike

    “The vendors need to stop thinking about billion dollar revenues”

    Good luck with this one.

  • Pingback: Software is the Hard Part « The Data Center Overlords()

  • Pingback: Response: Distributed? Centralized? Both? – Cisco Blog on OnePK and SDN — EtherealMind()

  • Pingback: Big Vendor Head Shuffles at the SDN Curling Rink — EtherealMind()

  • Pingback: Software Defined Networking & OpenFlow – So Far and So Future — EtherealMind()