I originally posted this just over a year ago (Feb 5, 2013) on my corporate blog. I’m reposting here now because the subject of “master controllers” and federation is coming up again more insistently as users begin to think through how to implement a controller-based architecture. I expect to be writing more on this soon.
As we enter the second(ish) Year of SDN, we’ve gone from irrational exuberance to some semblance of reality, with some first-generation products starting to come to market now. That will inevitably drive more reality, on the user side, but an embrace of reality may take a bit longer on the vendor side. I say that because there are still plenty of “whoever wins the controller wars wins all” notions being promulgated in various forums.
If the world were inevitably going to go all-SDN, all-the-time…there might be something to this line of thinking. But there’s no real reason to reinvent standard networking protocols and functions just for the sake of implementing them in a controller and lots of reasons not to, so hybrid networking devices that support standard forwarding mechanisms and SDN mechanisms for handling specific types of flows or requirements will likely see the most adoption.
But of course what’s happened is that the fear that controllers might disrupt everything has led many networking players to conclude they must have their own in order to control their own destiny. I think that’s unfortunate, for reasons I’ll explain more fully sometime in a separate post. But the net result is that today’s discrete controllers will wind up going one of two ways:
- Down, coupled ever more tightly into existing network operating systems, until eventually they will simply be part of OSes with better northbound APIs than before. This will be especially true of “house” controllers from existing networking vendors.
- Up, as platforms for emerging ecosystems of network applications. There’s nothing to prevent house controllers from moving in this direction, and for major vendors to develop their own developer ecosystems (well, nothing but mindset and institutional support for such), but I believe that the continued existence and health of third-party controllers is vitally important here.
I’m dubious that independent controller vendors will exist for long without an aggressive push towards developing both a clearly stated OEM strategy and a strong developer ecosystem. Sadly, since Nicira’s eye-popping exit, several have been openly positioning themselves to be “the next Nicira” rather than making such bids for longevity.
Now, there’s immense value to be derived from making networks programmable in a fine-grained way, and also in network OS’s becoming app development platforms. But a controller in itself is not all that interesting.
What will be extremely important in the long run is horizontal inter-controller interoperability. Most of the industry focus is currently on defining northbound APIs, eg between controllers and applications—because there’s gold in them thar applications, and because controllers without prêt à porter applications will have little mass appeal.
That said, there exists a recently expired IETF draft describing an architecture, and very notionally, a protocol (SDNi) for governing east-west controller exchanges, led by Huawei. A nice summary of that draft and a related one governing L4-7 services can be found here, with further analysis from Brent Salisbury here. A slightly newer draft, this one led by Alcatel, describes controller federation based on NVo3, with a nod to underlay awareness (Sec 4.3). Both drafts assume heterogeneous controllers, but there is in fact no reason similar mechanisms could not be used to manage multiple same-type controllers, rather than proprietary exchange mechanisms.
Curt Beckmann, as I was kicking this topic around with him, made this comment:
Since we don’t have any interoperable single-domain stuff yet, maybe we should work on that? And then build on that. We’re necessarily in a “design by committee” reality here, and single-domain is already super hard…Now, even in single domain I think there’s value in having east-west standardization…Top-down federation can do the job (but it can’t do it for cross-domain). So, first I think we do the top down single domain, then east-west single domain, then east-west multi-domain.”
This proposal for a phased approach makes plenty of sense, in that it allows controller providers to work out one set of APIs at a time. At the same time, it would be problematic to get too far down the path of replicating the existing top-down operating model with more layers. True fabrics with east-west sharing such as VCS have already proven this model to be more efficient at a machine level, as well as less conflict-prone and more manageable from the perspective of human operators. Better to keep what will need to be routine exchanges as low in the stack as possible, and focus on how to automate them as much as possible.
In fact, keeping these exchanges at lower levels actually plays to the natural strengths of existing networking vendors—including those building their own controllers—whereas pushing intelligence and management ever northward does the opposite. If SDN genuinely takes off, at some point certain vendors will be forced to acknowledge that their envisioned walled garden is a fantasy; controller heterogeneity is inevitable. Moreover, SDN domains will be multiple rather than vast for the foreseeable future, necessitating easy inter-controller exchanges even within homogeneous environments.