I have been remiss in writing in the last year, the reasons are unimportant, but regardless, I’ve been paying very close attention. It’s 2017 and it is SOAPBOX time again!  SDN has been a “thing” since ~2008, with the publication and popularization of the OpenFlow protocol. It’s 2017. How much has this industry changing technology is running outside of the hyper scale data centers?  We’ve seen companies rise and companies disappear. The promise of SDN is multi-faceted, but aside from automation and orchestration, the draw for many architects and engineers is the idea of modular control and data planes. The switching pieces in the data center work - for the most part. The promise of SDN may work for the hyperscalers - but what that does that mean for everyone else other than better cloud services? I’m going to discount enterprise, mostly, because enterprise, frankly, is slow to change and glacial when it comes to adopting new internal technologies, but that only serves to prove my point - it’s not there yet. That leaves my favorite subject: service providers - and I don’t mean SD-WAN (that’s something completely different and  don’t accept the name as correct). The idea of taking a routing stack and a forwarding plane and breaking them apart, making them interchangeable and modular. This requires a few elemental attributes:

  • A strong routing stack including the venerable legacy protocols such as mBGP, IS-IS, LDP, etc.
  • Full support of the routed stack (IPv4 and IPv6)
  • A robust hardware platform with appropriate buffers
  • A way to couple the two in a stable and supportable way

This sounds simple. It’s not. Think about this from the perspective of the commercial UNIX systems of 20 years ago. The custom hardware did not always have compatibility with the software packages that the engineers needed to run on them. The implementations were clunky and sometimes half-done. Features didn’t always work. Updates were staggered, haphazard, and slow. This is what SDN has felt like for me for the past few years. Sure, if you’re in the data center and you want a single vendor solution - maybe. In my world that’s not ever the case, and I assert that if things don’t interoperate then they are incomplete. Where am I going with this rambling, nonsensical drivel? Hardware features and software features have a history of not matching when something is new and SDN has been the embodiment of that. If I look back on the work I’ve done in the SDN space, and at the risk of being captain obvious, the lessons learned that come to mind from my experience designing, coordinating, building, and running actual production SDN networks are pretty easy to point out.

  • Centralized control doesn’t scale well geographically (or arguably at all).
  • Topology information is difficult to track in a timely manner in the WAN. See bullet 1. 
  • Re-inventing protocols stinks
  • Most of the issues revolve around scaling and support
  • Scaling is hard
  • All hardware is most certainly not created equally

The elephant in the room is that WAN gear is different. It’s historically been custom ASICs, sometimes FPGAs, and always has deep buffers. It also has a longer mean time before replacement. This is incongruent with the think buffered data center switches that most folks experiment with if they ever make it past mininet. Want to understand buffering and why it is necessary? Read up here, it’s the best resource I’ve ever found on buffers of tons and tons of gear. The cliff’s notes are that when networks have a longer RTT, they need more buffering. TL/DR? Don’t use a freaking data center switch as your border router. Just because it can run BGP doesn’t mean it should. Now that I’ve seemingly called all of the babies ugly, let me shine a bit of light. I do have hope for some SDN. I think it exists now in the form of segment routing. Because we’ve seen the trying to turn an aircraft carrier on a dime is not easy, we can learn from it. There are a handful of solid SDN based WAN boxes out there and they bring strong offerings.