More than a decade after the Open Networking Foundation started the OpenFlow/SDN hype (the blog post was written in 2022), OpenFlow remains a niche tool, and SDN means whatever you want it to mean.
I would call that result a dismal failure; for whatever reason the (former) SDN evangelists tend to disagree with me and try to paint the SDN world in rosy colors. Judge for yourself ;)
… updated on Friday, May 20, 2022 10:20 UTC
Is OpenFlow Still Kicking?
Continuing the how real is the decade-old SDN hype thread, let’s try to figure out if anyone still uses OpenFlow. OpenFlow was declared dead by the troubadour of the SDN movement in 2016, so it looks like the question is moot. However, nothing ever dies in networking (including hop-by-hop IPv6 extension headers), so here we go.
Why Would One Use OpenFlow?
Ignoring for the moment the embarrassing we solved the global load balancing with per-flow forwarding academic blunders1, OpenFlow wasn’t the worst tool for programming forwarding exceptions (ACL/PBR) into TCAM.
I wouldn’t be surprised to find it used to implement programmable patch panels, sometimes known as access switches or virtual circuit switching in service provider networks. Even in those cases, smart engineers would probably combine circuit-programming capabilities of OpenFlow with local control plane that would detect failures and trigger failovers.
Is Anyone Still Supporting OpenFlow?
OpenFlow hype started in large data centers, so I first checked whether Arista2 still supports it. EOS 4.28.0F User Manual does mention OpenFlow, but the implementation hasn’t changed in years – EOS supports only OpenFlow 1.0 on ancient 7050/7050X switches. It looks like nobody large enough to interest Arista is asking for an OpenFlow implementation on a data center forwarding ASIC designed in the last decade.
Arista isn’t the only vendor dealing with the remnants of the OpenFlow hype. It looks like Alcatel Lucent also supports OpenFlow 1.3 on old hardware, and I’m positive there are other vendors that have to do the same. On the other hand, Broadcom seem to have stopped their OF-DPA efforts; the latest commit in the OF-DPA repository was made 6 years ago.
Could we then declare OpenFlow a relic of the past? Maybe not. Another interesting source of information is the Faucet SDN controller3. I looked at them in 2019 when preparing for a chat with Nick Buraglio, and found them to be pretty conservative – their vendor-specific documentation always includes whatever they thought would work reasonably well4.
Their vendor list didn’t change much over the years. NoviFlow has been there forever5, I was pleasantly surprised to see Aruba switches on the list, and totally shocked to see Cisco Catalyst 9000 – OpenFlow has been implemented in IOS XE. Looks like there’s a very large customer out there using OpenFlow on Catalyst switches.
Production Deployments
Readers of my blog sent me pointers to three publicly-known OpenFlow production deployments:
- Telstra is using OpenFlow and a homegrown SDN controller in their WAN network. More details, source code.
- While Google seems to be pushing P4 in Open Networking Foundation, they’re still talking about OpenFlow controllers running their B4 network. Have to figure out what the latest article is all about; the OpenFlow hype they generated almost exactly a decade ago was just a router built from pizza box switches and tons of
duct tapeexternal cables. - Comcast deployed OpenFlow-based leaf-and-spine fabrics in 20196. The Trellis reference design claims to be based on OF-DPA7, and considering Broadcom’s lack of interest in OF-DPA (see above), I have a funny feeling that someone desperately tried to justify a wrong choice they made. According to a later paper, that deployment is used in 25 leaf-and-spine fabrics and services 160K subscribers. Comcast has over 34 million subscribers, so the whole thing looks like another Terastream project to me8.
- ESnet was at one time running OpenFlow-based network built from Brocade MLX switches. I have no idea whether they’re still doing it, but that would be as relevant as COBOL on IBM 370 mainframes.
Have I missed something?
Is anyone else actively supporting OpenFlow? I’d love to hear from you – your comments (preferably including links to documentation) would be most welcome. In case you want to send me a private message, you already have my email address if you have an ipSpace.net subscription, or if you’re subscribed to my SDN/automation mailing list, and there’s the Contact Us form for everyone else.
Revision History
- 2022-05-20
- Added information based on user responses
- OpenFlow support on ALE switches
- Broadcom dropping OF-DPA
- Comcast Trellis deployment
-
See also: spherical cow in vacuum ↩︎
-
I’m assuming a second vendor in a large-enough market segment would be interested in implementing things customers want to buy. ↩︎
-
The only SDN controller I’m aware of that wasn’t started as a marketing exercise. ↩︎
-
Faucet is using a multi-table pipeline, which means that you can’t use it with switches that don’t support OpenFlow 1.3… and if your boxes don’t support OpenFlow 1.3 in 2022, I really don’t want to hear about them. ↩︎
-
It looks like NoviFlow pivoted away from hardware. OpenFlow switches are listed under legacy network switching products on their website, but their OpenFlow agent seems to be running on whitebox switches using Barefoot/Intel Tofino chipset or Mellanox NPUs. ↩︎
-
That would be three years after OpenFlow was declared dead. Were they trying to revive a dead horse instead of flogging it? ↩︎
-
Or maybe ONF is just super-sloppy updating their materials to reflect their own announcements, which is also telling us something. ↩︎
-
Terastream generated huge amount of publicity when it was announced in 2012. The hype continued in 2018, but for whatever incomprehensible reason, its demise in 2021 wasn’t made public. German journalists had to pry the information from Deutsche Telekom. ↩︎
Arista might not do much with OF in EOS, but take a look at their Converged Cloud Fabric and DANZ Monitoring Fabric offerings (both from their Big Switch acquisition). They're running OF under the hood and CCF is an incredibly simple way to build out a small to medium multitenant data center with a minimal crew.
I know Big Switch had an interesting solution that started working well once they deviated from the OpenFlow orthodoxy, but I honestly never understood why Arista acquired them, or why a company selling premium data center switches with their own network operating system (and doing really well in that market segment) would at the same time promote a completely different solution running on whitebox switches.
It looks like ALE is supporting OpenFlow 1.3.1 on the latest AOS version 8.8 (https://support.alcadis.nl/Support_files/Alcatel-Lucent/OmniSwitch//OS6900/Manuals/OS6900%20AOS%208.8.R02/OS6900%20AOS%208.8.R02%20ZIP%20All%20Manuals.zip > AOS8.8.R02 Specifications Guide.pdf) The switch that support it are quite old but still being sold.
I was contacted by a recruiter from a satellite internet company, which asked for 5 years of open flow experience! I couldn't believe my eyes. Take a look! https://jobs.lever.co/kepler/8aaab099-22b2-49d7-bdb9-757adfc383be
It's not exactly the brightest job ad I've seen, but there have been worse. It seems like they're looking for someone who understands controller-based networking (as opposed to being a box-by-box CLI jockey). And yeah, there are better ways of saying that than "OpenFlow or equivalent"
controller-based networking was my definition of "SDN," unfortunately all of the marketing wonks in the industry got hold of the term and mudddled it into whatever it means today (is an SDWAN and SDN? I would say "no").
controller-based networks made a lot of sense if you could build them out of low-cost gear (e.g. whiteboxes) that didn't require a huge code-base of "everything on BGP" - for this Openflow was a pretty good answer and they made a pretty easy, automated way to build a service based on VLAN that rivalled the utterly ridiculous complexity of MP-BGP networks.
The Telstra network (RIP) resold cloud services and NFV's based on internal Openstack's. It was a pretty innovative undertaking (had it's own open-source controller too).
Oh well, I guess the world deserves the EVPN-VxLAN crap that everyone is deploying in DC's now and the SDWANs that will destroy the MPLS market soon.
I believe HP/Aruba does. I see it in show and config options on their larger chassis switches 5400r J9851A KB.16.08.0001 2019-21 family. I recall HP was big on OpenFlow, not sure if they removed with their newer systems as of this post's date. Also, seen on Dell stack switches running OS6.
I am doing some freelance projects, All use OpenFlow and ryu controller. SDN in academic works is synonymous with OpenFlow :-)
What about Google's Andromeda network virtualization? It seems very 'open' about the use of OpenFlow (please pardon the pun).
https://www.usenix.org/system/files/conference/nsdi18/nsdi18-dalton.pdf
Thanks for the pointer. I addressed the viability of using OpenFlow to program virtual switches in 2014:
https://blog.ipspace.net/2014/06/is-openflow-best-tool-for-overlay.html
I'm guessing Google still uses OpenFlow because (it looks like) they started with Onyx and Open vSwitch, but the article makes it very clear they extended OpenFlow in several ways.
If you look closely at some of their docs, Juniper supported Openflow on the MX routers for a time. It was a bit of a secret, but when Google asks for a router at their border... JNPR never made it past support for OF1.3 (i think).
Of course it never got anywhere (apart from making the quota for the Google account team at Juniper)
ESnet's OSCARS service provides an abstraction with respect to the overlay technology used, but under the hood it currently signals VPLS with RSVP, some as ERO's with scheduled traffic guarantees and so on.
Internet2 did have a very sizable deployment of openflow on MLX which may have been what you were thinking of. I believe they have been doing EVPN on modern kit for a few years now.
Thanks a million. A few things make a bit more sense now ;)