Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

reserve a seat
back to overview

Big Switch Networks might actually make sense

Big Switch Networks is one of those semi-stealthy startups that like to hint at what they’re doing without actually telling you anything, so I was very keen to meet Kyle Forster and Guido Appenzeller during the OpenFlow Symposium and asked them a simple question: “can you explain in 3 minutes what it is you’re doing?”

The answer (without any of the network virtualization mantras) was also very simple: We allow tenants in multi-tenant environments to use ports on different physical and virtual switches as a single switch.

The obvious next question: “how does that differ from MPLS/VPN or VPLS?” Honest answer: “not that much” (and they let me stew over it).

It took me a few hours, but then it hit me ... the real difference is the configuration mechanism.

Boring old world

In MPLS/VPN environment, the customer (CE-router) has no control over the configuration of the PE-router, CE-PE links or routing protocols used in the MPLS/VPN network. The only way to influence the MPLS/VPN core is through routing protocol updates.

VPLS environment is even simpler: the customer has no control whatsoever, as there’s no layer-2 control plane between hosts and adjacent bridges. If you’re extremely lucky, you might be able to pass STP BPDUs across the VPLS cloud (not sure whether that’s really good or bad) or use Ethernet OAM. Anything else – just forget it.

Entering a parallel flow-controller universe

Now imagine you could actually use CLI (for the true machos) or GUI (for iPhone addicts) and configure the ports on the PE-routers (be it layer-2 ports, layer-3 ports or SVI/RVI-like virtual layer-3 interfaces), security mechanisms (BPDU guard comes to mind) and the routing policies, all on your own, like you would own a big distributed switch (like QFabric), with zero interaction with the SP/cloud provider engineers. A smart OpenFlow controller running the Wizard-of-Oz-like magic behind the scenes could also implement resource restrictions (number of flows – be it MAC addresses, IP prefixes or other flows – per tenant).

Sounds like science fiction? Not really, that’s what Amazon VPC does today (although with limited functionality and only at layer-3), so it’s perfectly doable.

Disclaimer: Until I see the Big Switch controller in action and read the documentation, I won’t even try to claim they are anywhere close to the nirvana I’m describing. I’m just saying that we can reach that goal using OpenFlow as the technology. Once they decide to share more information with me, you’ll be the first to know.

Disclosure: Big Switch Networks indirectly covered some of my travel expenses during the OpenFlow Symposium by participating in the event, but nobody has ever asked me to write about their products or solutions. Read the full disclosure (or more precise ones by Tony Bourke or Matt Simmons).


  1. Ivan, agree with you 100%. I for one would be the macho type...and use the CLI! There have been many folks (I think you included in prior posts) out there over the past several months state you will probably not see anything you can't already do today within an OF network. Not talking about SDN apps on top. However, this is def a great example of OPERATIONAL benefits that can be realized by using a controller based OF model Really look forward to seeing this stuff in action one day too.

  2. brings up the debate about keeping the network decentralized in control plane operation in the classical sense of routing protocol PHB FSMs to handling things but give the perception of one box. Vs. the centralized controller approach to achieve the same thing. Both have their merits and demerits a fat finger on one PH device may affect a part of the decentralized but a fat finger on the controller could affect the whole virtual presented core "box". Just being "conceptual" here today. Warm in NY.

  3. don't we see "pieces" of this with LISP and PER with their "controller" like function?

  4. Not sure what "PER" is (pointers?), LISP is a completely different beast. Similar forwarding principles (there's nothing new under the sun since X.25 days), but definitely not the management/control plane perspective.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.