Looking Backward to Look Forward

“Whoever wishes to foresee the future must consult the past” -unspecified “wise men” quoted by Niccolò Machiavelli With so many articles out there telling me how SDN will change the network as we know it, I’ve been thinking about what the future holds for networking. Thus if the wisdom reported by Machiavelli is to be believed, I should reminisce a little about how things used to be. Looking Backward Around 1997, when I started in networking, the primary LAN protocols were IP, IPX/SPX, Appletalk®, and occasionally some DecNet and Banyan Vines. At the data link layer, Token Ring was slowly being edged out by FastEthernet. Within just a few years, Ethernet (cheap and easy) and IP (simple interoperability with the growing internet) were all anybody seemed to want, and the other technologies started withering on the Banyan Vine, so to speak. Ethernet network designs were changed forever by the adoption of switches (i.e. fast, multi-port bridges) in place of the old two-port bridges, repeaters, and hubs—although Spanning Tree Protocol persisted, not entirely unlike the unidentified moldy odor that permeated my rusty VW Jetta. WAN technologies got progressively faster, over time, and it became evident that making an IP routing decision for every packet passing through a router was an awful lot of work; the routing tables were growing daily and everybody looked wistfully back to the days of X.25, when end-to-end paths were predetermined and traffic was easily switched with simple table lookups. As if by magic, MPLS appeared, encapsulating IP, and ultimately, pretty much everything else with a switching-style header. More importantly for customers, MPLS unified WAN access over multiple layer 2 technologies and became a lingua franca for the wide area. WAN just got easier! Large Layer 2 domains have been a pain to deal with for many years. Even when the network is stable, STP is effective, but wastes potential bandwidth by blocking links. Ethernet fabrics (including TRILL and Shortest Path Bridging) make it easier to have the same flexible layer 2 connectivity without all the bad bits of STP. We’ve also realized that having a distributed network control plane is not only expensive, but is also inefficient because it relies on protocols to carry topology information from device to device. It’s much simpler, in some respects, to have one control plan that’s aware of the whole topology, let it determine best paths, and then just tell the network devices what to do. We now have a single point of configuration that encompasses a lot of devices; life just got easier again. Most recently, it has dawned on the industry that the typical wide area network falls into that same “distributed network” problem, and in a large enterprise with a lot of remote sites, having to configure every device separately is a big time waster. Software Defined WAN (SD WAN) aims to make it easier to manage the Wide Area Network, and might even allow for some smarter routing decisions to be made. What I’ve learned from the past is this: We are, fundamentally, lazy cheapskates. To put it another way, as consumers of network technologies, I think we are most likely to adopt the technologies that deliver the desired solution in the easiest fashion, and, ideally, at the lowest cost. The more smart decisions a solution can make autonomously (albeit within parameters I may have provided), the better. Moving Forward If I’m right, what does this mean for the future of networking? Software Defined Networking (SDN) is the Soup du jour on most vendor menus. For some, perhaps because SDN Washing is a checkbox item in the marketing plan, but for others, because the new technologies can genuinely do something we couldn’t do before. Is SDN the future? It’s going to take a while for these features to trickle down to the majority of companies, let alone to represent 100% of a company’s network inventory. Those who have a use case for adoption will likely do so because their shiny new Software Defined Network will make it easier to do business. However, even without an “SDN Compliant” sticker on the front of the chassis, most network device configuration can be automated in some way, and that is something that can benefit almost every company with a reasonably-sized network (for small networks, the cost of the time spent developing the automation will likely outweigh any operational savings). That opens the door for most of us to make our lives easier and reduce operational costs in the near term, at least until somebody installs a controller to do the work instead. I do wonder sometimes whether in 15 years’ time we’re going to look back on the SDN “revolution” and laugh as we ask ourselves what on earth we were thinking. Because even if our basic goals (easy and cheap) are consistent over time, technology moves so fast it’s hard to keep up. Today’s cutting edge SDN technology may be tomorrow’s Spanning Tree Protocol. What’s clear is that our future networks will be smarter and more functional, but with less operational effort required. Exactly how we will actually achieve those goals is yet to be seen, because one thing’s for sure: the only constant is change.