Software Defined Networking, and it’s latest incarnation SD-WAN seem to be all the rage at the moment. Having seen presentations from vendors large and small on the subject recently at Networking Field Day 10 I am still given to thinking there are a few things that get glossed-over by the vendors quite often. Foremost in my mind, is this (potentially heretical thought):
It is all very well creating virtual or ‘overlay’ networks which run over other networks to suit your purposes, but as someone famous once said, you can’t change the laws of physics. Packets must ultimately flow across a medium – wires, fibres or waves. The media doesn’t give a flying fart whether the packet is naked, or clothed in layers of MPLS or GRE headers – if that medium is congested and doesn’t support any form of packet prioritisation, your data is down the dunny.
There’s a trade-off here that perhaps not many people understand when they are shown smooth presentations by manufacturers. It seems to me that:
- Efficient use of network connectivity requires deep understanding from end to end. That’s why you employ network engineers.
- Efficient deployment of network connectivity requires abstraction and overlays to increase ease of deployment (which equals loss of understanding of lower layer protocols).
- Efficient operation of network connectivity… well… let’s hope it’ll be fine so long as nothing goes wrong.
The WAN as we know it today is a stitched together mass of string, brown paper and tape. Lots of protocols, access methods and people somehow working together to satisfy the diverse needs of billions of organisations and people. Because of this, operating a WAN can be a complicated matter. But as Matt says in his blog, although infrastructure is important, it
… should be invisible. I believe the real-world, practical point behind saying “infrastructure doesn’t matter anymore” is that we are finally getting around to practicing the absolute truth that for the vast majority of organizations, the infrastructure is not a revenue generator.
That’s the business driver, but bullet points 1 and 2 above are diametrically opposed to each other.
Cisco’s IWAN product was demonstrated to us at NFD10. Summed up quite nicely by Overlaid, it brings together their rich feature-set under a slick graphical user interface. But ultimately it uses DMVPN to abstract the underlay from the overlay (see 1:10 in this video), uses VRFs to abstract transport from service, and uses a GUI to abstract policy creation from enforcement. In the software-defined datacenter, companies such as Juniper are belatedly trying to correlate the overlay with the underlay (see this video). This is an important step forward I think, but it is only possible because the datacenter WAN is under the end-user’s control. Since the WAN will almost always be someone else’s network you’ll never get anything better than ‘multi-path best-effort’ packet forwarding. Crude – but effective for most?
Maybe we can take a long view on this. I, and many like me are from the dinosaur school of thought that likes to have everything nicely worked-out, predictable and efficient. Presumably such tugs-of-war happened when the first programming languages arrived on the computing scene. Yes, they enable great strides to be made where many hours of coding in assembler might have been required before – but the abstraction from low-level functions must surely introduce huge inefficiency? And how do we troubleshoot now everything’s obscured?
The reality of that scenario is that such technological advances enable great progress, and although they will still need troubleshooting, the advances they enable outweigh the downsides. Although SD-WAN is a difficult thing to sum up given its current nascent state (as John Herbert says in this article), we are on the road to simplicity. Your average IT manager would surely rejoice if networking were as simple as Nuage’s very nice video shows it is capable of being.