Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

SDN Disruption: Has The Pendulum Swung Too Far?

John Chambers last keynote as Cisco's CEO at Cisco Live had one clear message: “Disrupt or be disrupted,” meaning that if your company does not evolve,  it will die. In the networking industry, the ongoing theme of disruption revolves around software-defined networks (SDN).

The industry is so focused on disruption via SDN that it might be forgetting to ask the right questions. If you have been around a while, you have seen the pendulum swing back and forth from centralization to decentralization. Networking greats such as Russ White and Ivan Pepelnjak are among those who are questioning aspects of SDN and not swallowing the whole SDN mantra.

As a network architect, there are some rules or guidelines that you learn from experience or from reading networking design books such as “Optimal Routing Design” and “The Art of Network Architecture.” I will mention a few of these guidelines here; these should be applied when considering SDN and related new technologies:

  • Separate complexity from complexity
  • Don’t reinvent the wheel
  • State costs money
  • Keep intelligence at the edge of the network
  • There is always a trade-off
  • Manage the size of your failure domain

Let's start by looking at OpenFlow. It's a protocol that separates the control plane and data plane and uses a controller to program the switches with flow entries with actions how to forward or drop traffic. OpenFlow was all the rage a year ago but seems to have slowed down lately. Why? In my opinion a lot of the mistakes of flow switching in the past are being repeated.

State still costs money. State still scales worse than no state. For that reason, state should only be installed if forwarding should not be done based on ordinary forwarding rules. I see more promise in Segment Routing (SR) for such applications. OpenFlow could be used for the same purpose in non- MPLS networks, but I don’t believe in the controller-only forwarding paradigm.

Figure 1:

(Image: Igen)

Along the same line, are people considering the trade-off with SDN-related technologies? If you haven’t found any trade-offs, you haven’t looked hard enough. People want intelligent, fast and cheap -- pick two. Yes, networking hardware is getting cheaper and we are seeing white-box switches evolve but there is always a trade-off. Look for the trade-off!

The industry also is overconfident in tunnelling, I believe. VXLAN is being touted as the best thing since sliced bread. It’s just tunnelling -- an encapsulation. It’s not really interesting except for the part that we get more identifiers to use than with VLANs, which scale poorly, especially in multi-tenant networks. What we do with the tunnels is more interesting. How do you manage and get visibility into the tunnels? Is your underlay properly designed? It’s just IP, right? It’s like building a house, if you cheat with the foundation, the house won’t hold up.

I also see too much focus on fabrics. Fabrics are nice; however, they're not so nice when they fail. If you put everything into a fabric, you build a large failure domain, essentially putting all your eggs into the same basket. Once again, have you asked what the trade-off is? That doesn’t mean that fabrics aren’t useful, just that they're not the only solution.

So what’s my point?

My point is that the industry is so focused on disrupting, on being first, that I’m not sure people are asking the right questions and considering the trade-offs. I see people repeating a lot of mistakes of the past and not doing their homework properly. They are reinventing the wheel just for the sake of disrupting.

I personally believe in a more gradual transition to SDN by leveraging protocols such as BGP, EVPN, SR and MPLS. The focus should be on leveraging existing and proven protocols before inventing new protocols just for the sake of disruption. There is a lot of innovation going on, and eventually we will see great products evolve from this innovation. We have a long way to go, though.