Over the last couple of years, two major philosophies for SDN have evolved which I will call the overlay model, and the flow programmability model. Overlay networks are the notion of building multiple virtual networks in parallel on top of a physical network fabric, using some means of separating the virtual networks — typically an encapsulation method like VXLAN or NVGRE. Then we have the “flow programmability” model, based on the idea of programming SDN behaviors on a flow-by-flow basis into your existing (or new) physical and virtual network switches using a protocol like OpenFlow.
Lately, the overlay model has been getting a lot of attention with solutions like VMWare NSX, and the increasing support for VXLAN encapsulation in several networking and server products like Cisco UCS and a variety of switch manufacturers that hopped on board with NSX.
Personally, I still question whether overlays are SDN or whether overlays are an application enabled by SDN (like L3VPN is an application of MPLS). Regardless, this model is favored by some vendors as a means to SDN-enable your existing network, possibly just with the addition of a few “gateway appliances” which can introduce those not-yet-virtualized resources into a specific overlay.
Right around the time of Networking Field Day 6, Big Switch Networks announced they were moving away from overlay designs and embracing SDN-capable hardware switches — what I’m calling the “flow programmability” model. Again, the idea here is that you would be defining those SDN behaviors, associations, affinities, etc., by programming the actual hardware (or virtual!) switch forwarding planes via some centralized control point. Many people get excited about API-enabling this capability, but I think the concept is just as valid using a GUI or CLI on the central control-plane.
Each camp flings FUD at the other: Flow programmability vendors and OpenFlow advocates seem skeptical of the scalability of overlays that just keep getting… overlaid on top of one another. On the other hand, flow-level tracking of thousands of hosts in a central controller also seems to havepotential scalability problems. Some vendors have come up with innovative solutions to some of these scaling problems, but that’s fodder for a future blog post. (PS- I’m well aware both linked articles in this paragraph are by the venerable Ivan Pepelnjak, but he illustrates the FUD very well, even though he is not the one slinging it)
Back to Big Switch and what their change in deployment strategy might mean. Big Switch is now moving toward the flow programmability model using “bare metal” switches, running their SwitchLight software for “native SDN” capability. As you can see from this slide out of Big Switch’s presentation, they consider this a key element of the evolution of SDN.
I was amazed to learn that we’re already at SDN 2.0! It took much longer to reach Web 2.0…
Anyway, “bare metal” switches are a pretty new concept, and are a fascinating idea to me for a couple reasons:
- They decouple the hardware and software. It’s like buying an old Linksys WRT54G and then sticking DD-WRT or Tomato firmware on it. The device may have come with some firmware to provide basic functionality, but other third-party software can be loaded to unlock amazing potential. Want to try different software for a bit, and maybe revert back to what you were using? No problem, just flash and go.
- Attractive pricing. Based on some quick Google research of the models on the Hardware Compatibility List of Cumulous Networks, which is following a similar strategy to Big Switch, the prices of 1G and 10G bare metal switches aren’t earth shattering, but they’re definitely cheaper than the ones with a little picture of a famous bridge on them. More notably, they really do commoditize the switching hardware. They all use the Broadcom Trident family of ASICs, and mostly come from low-name-recognition manufacturers. But the idea is “who cares?” If you can get a better deal on a switch from vendor X this week, and vendor Y next week, that’s supposedly fine as long as they’re on the HCL.
- Physical deployment and integration becomes trivial. Just rack the switch and PXE boot it to load your desired OS on it. I bristle a bit at the idea of PXE booting network hardware (there’s a chicken-and-egg problem in there somewhere), but that model has worked spectacularly in the wireless space to make deployment of large fleets of network devices extremely easy.
Despite the interesting facets of bare metal switches, there are some non-trivial challenges that Big Switch (and similar vendors) will need to address:
- Hardware acceptance: convincing customers that bare metal or white box switches are just as good as the brand-name switches they’ve been buying for years.
- Support: Approved hardware compatibility lists certainly help, but as I pointed out in some quotes in this article on TechTarget, I think network vendors need to be cautious about getting into finger-pointing matches that can arise when the hardware and software package isn’t produced, integrated, and tested by a single vendor. Solid compatibility testing programs may take time to mature.
- Investment: Pure overlays offer an easy entry for the curious. You can build an overlay network using software products and bag the experiment just as easily. While more big-name switches are starting to include some sort of OpenFlow capability, if you don’t have the right switch model you may have to convince the person in charge of the purse strings that this idea is worth pursuing which may mean more upfront work to build a business case versus a “try and see” model that may be easier to test with overlay SDN.
Overall, the concept of controller-based fleets of bare metal switches will require a fairly drastic mind-shift, but if Big Switch can convince customers that their controller platform and the bare metal switch concept is sound, it could really shake up the networking market. This is the SDN that the big 3 (or 4 or 5) switch manufacturers are nervous about.
To learn more about Big Switch’s products and strategies, be sure to watch their presentations from NFD6:Source: http://herdingpackets.net/2013/10/24/big-switch-networks-and-the-possible-future-of-networking-hardware/