Will SDN Kill TRILL?

In recent years, a great deal of time has gone into developing standards--including TRILL, SPB and DCB--that enable Layer 2 multipathing and improve Ethernet's capabilities in the virtualized data center. These standards promise to enable all links to forward traffic, eliminate loops and create meshes to let traffic take the shortest path between switches.

Much digital ink has been spilled over use cases and the pros and cons of these approaches. Vendors have rolled out products, working groups have exchanged ideas, and engineers have tried to sort out just what is going on.

Now, software-defined networking (SDN) has leaped into the pool and caused lots of waves with its promise to upend traditional network design and operation. To paraphrase a question put to me on Twitter, is there a future for data center Ethernet standards such as TRILL in an SDN world? If so, how do the standards fit? If not, how will SDN recreate the promised functionality?

There's an assumption built into the question that must be explored. The assumption is that the networks of the world are going to be software defined. And by "software defined," I mean, at the least, a network whose forwarding behavior is programmed by a central controller with a holistic view of the network topology.

I believe it's possible that this is where networks are going, but even if I'm right, that transition is going to take years. SDN is in its early stages. Startups are coming out of stealth with their notion of what SDN is and what problems it can solve. Most SDN products target specific use cases and are definitely not one-size-fits-all. The OpenFlow specification, which is a core component of the centralized controller model of SDN, is running ahead of the capabilities of currently available silicon to perform all potential matching operations in hardware.

Meanwhile, big vendors are feeling out the market, determining what customers actually want out of SDN, and developing products based around those requirements. At the same time, they are working toprotect their vested interests.

If SDN ubiquity is years away, is there a fit for the emergent data center Ethernet standards? Yes, clearly.

While SDN can offer Layer 2 multipathing in the data center, is that why you should be shopping for SDN products? Not really. Customers can deploy Cisco Nexus switches with FabricPath, Brocade VDX switches with VCS, Juniper QFX switches with QFabric, or Avaya switches with VENA (to name a few approaches). They can build a Layer 2 data center topology that works like a Layer 3 routing topology. Those fabric technologies are comparatively mature and scale effectively without too much design effort, though they do require a homogenous data center network.

So why should you be shopping for SDN? Consider the following points.

[Ethan Banks is a featured speaker at Interop Las Vegas this May, including the conference session "Chopping Down the Fat Tree in the Small Data Center." Register here today.]

--Centralized controllers learn about multiple paths through the network between a given source and destination, and can create multiple forwarding entries the network switches can use to deliver traffic across multiple paths.

--ECMP and MLAG creation is a relatively trivial task for a central controller with a holistic view of the network, as there is no great distinction to be made between physical devices.

--A centralized network view makes it possible to engineer end-to-end paths for data to follow based on policies defined by a network engineer, such as latency and hop count, and not merely source and destination addresses.

In other words, because a central controller sees the network as a whole, there's no need for distributed protocols to determine a loop-free, best-path topology. An individual switch no longer has to figure out for itself how to get to a remote destination; the switch is told how to forward by the controller. "Best path" can mean whatever a network designer wants it to mean, and not what a group of protocol designers decided it meant in an RFC.

Does that mean data centers can get rid of TRILL and SPB? Think in terms of domain to answer that question. How many switches are under the central controller? What sorts of forwarding controls are required? How much of that functionality is available in silicon, and what impact does that have on switching performance? What mechanism is used to connect to other switching domains? Data center SDN doesn't have answers to all of these questions yet, and so it's hard to predict the long-term role for TRILL and SPB in the data center.

That said, in my opinion, TRILL and SPB have an immediate role to play in the data center. These are well-documented technologies with reference architectures you can buy today with support in silicon from many vendors. Assuming a service life of five to seven years for network gear, TRILL and SPB are positioned to serve you well for the duration. However, the long view of L2 multipathing is that as OpenFlow performance improves in lockstep with OpenFlow-capable silicon, forwarding techniques using OpenFlow could conceivably displace TRILL and SPB as an L2 multipathing technology.