More SDN, More Network Design

A recent post in a LinkedIn forum asked whether the introduction of SDN would signal the end for network designers. Can the centralised intelligence of the SDN controller render slow, fallible, human planners and designers obsolete?

I remember the same question being asked when service providers started to roll-out IP.

Before IP, network design was a precise and laborious task. Switching points were limited and expensive. Resources, like timeslots and ports, were dedicated to individual services or circuits. You had to spend a lot of time planning the network topology and designing services to follow a specific, fixed route from A to B.

IP was going to make life much easier for designers. Because IP is smart, IP can find its own paths for packets, and IP can work around outages, IP traffic simply shares resources from the big pool of network capacity.

But, of course, the complexity of a CSP network and the fact that IP devices are unaware of cost, QoS, or business objectives when making routing decisions means that design is still necessary for carrier IP networks. IP devices will do what they can the get traffic from A to B, but without guidance or design the best they can do if find the ‘shortest path’ using simple Dijkstra path computes. Protocols like OSPF, ISIS, BGP allow some further design of the topology that IP devices then work within, but each device remains unaware of any objective other than forwarding data packets to the next hop.

A combination of ‘dumb’ path computes  and size/complexity leading to unpredictable resource utilisation during high-traffic or failure conditions means that carrier IP networks demand a great deal of design.

The same will apply to SDN enabled networks.

Yes, SDN will mean the network can do more, in real time, to ensure the delivery of services. The intelligence of the SDN controller can implement more policies and rules beyond simple Dijkstra path computes. The SDN controller could, for example, be aware of how demand varies through the day, prioritising routes to better balance load and increase service quality.

That would be nice. But there is still a need to design a network in such a way that SDN can function effectively. The usual challenges of avoiding overbuild/underbuild of capacity remain. The need to ensure that there are alternative or resilient routes through the network under failure conditions remains. These things can only be ensured, efficiently, with good network design.

Look at it another way: SDN gives you more ways to design topologies and design routes. You’re going to need to do more design to leverage SDN’s capabilities.