I’m a networker, and I’ve got questions. What is SDN? Is Puppet and Chef on a switch SDN? Is OpenStack controlling switch VLANs SDN? What about VXLAN? Or if I use a script to control API’s on a router – is that SDN? If my IDS automatically quarantines devices via remote device management – is that SDN? What about that BASH script I wrote to dynamically forward certain packet types?
Currently the median definition of SDN is full separation of the control plane and data plane of network devices. The median technology of SDN equals OpenFlow. The problem? None of the above scenarios fit this definition.
The only thing clearly defined about Software Defined Networking (SDN) is if you want your product marketed as something innovative, SDN needs to be attached to the datasheet. We’re seeing SDN permeate all aspects of networking – security, WAN, and campus and it’s getting less and less clear every day. The good news is there are a myriad of actual problems it can help with, but boiling down the marketing babble to actionable technology is an art. I’ve been thinking about it a different way, and it comes down to software.
I’m a believer in reusing techniques, thoughts, and concepts between disciplines. We’re on the cusp of taking what we do in the networking world and using software tools and methodologies to improve those processes – and it’s really exciting. It’s proven by now, if you give the web a chance, they will turn your business into an HTML5 application. (mail, real estate, ticket sales, commerce, transportation, retail, finance, etc) Let’s accept that now as an industry, and start applying it to networking.
Maria Popova said “… in order for us to truly create and contribute to the world, we have to be able to connect countless dots, to cross-pollinate ideas from a wealth of disciplines, to combine and recombine these pieces and build new castles.”
Software Influnced Networking
I propose a Three Letter Acronym – Software Influenced Networking (SIN). Software Influenced Networking applies ideas native to software engineering to network engineering. Examples include saving networking configuration like code, testing configuration like code, emulating software architectures in the network, and applying software design concepts to network design. Yes, it’s amorphous. Yes, it’s foreign – but it’s also punny because it’s a SIN. I’m half joking, half serious.
This would reduce the friction on the currently argued Software Defined Networking definition – the true separation of control plane and data plane separation. By definition this is a more hostile term to networking because the whole concept is defined by software. We rip all of our well-known features out of devices for them to be defined by a controller. The value of recreating all control planes features somewhere else is arguable, but is now constrained to this idea.
By contrast, Software Influenced Networking impacts through influence rather than definition. The network as we know it maintains intact, but we interact with it in a different way. It’s orchestrated through a higher level system that pushes flags and API calls. We maintain device autonomy without a rip-and-replace, but without the ‘wow’ factor of centralizing all processing. We can take decades old tried and true software processes and apply them to networking. Let’s use the tools that work so great in software, and start fixing network management tools.
If device configuration (IOS CLI) is a form of a programming language, and our network devices are forms of a server, and our network functions are forms of applications – we’ve been developers for a very long time. Just shitty ones. Not that it’s our fault, but as those lines blur and CLI’s become API calls, devices run or expose Linux shells, and our appliances turn into application VM’s it is increasingly hard to hide our horrid development practices. The first step to recovery is understanding that what we’ve been doing is effectively development. The network function is our application, Vendor CLI is our programming language, and the network OS is our platform. When this development is compared to modern software development, there’s a gigantic gap.
This is the concept of infrastructure as code, though typically I’ve seen it used in the context of operating system infrastructure with configuration management tools. I think it could use a broadening of scope, with the same original idea.
Recently solved gaps leading to this change:
- Testing network changes reliably has been impossible due to hardware costs. These costs are reducing as we virtualize services and find ways to break apart large scale-up systems.
- Network speed and agility has not been highly valued over reliability since it wasn’t a significant bottleneck in the service delivery process. Now that Cloud, DevOps, Automation and the likes have sped up computing, storage, and virtualization – networking is sticking out.
- The software world didn’t have any hooks into infrastructure to utilize. The configuration management tools couldn’t run agent on network devices, there were no real network service API’s, and a general lack of tooling and interface layers created challenges. These weren’t prevalent until the last few years. Unless you liked writing expect scripts.
Break it down
The wide swath of software is scary, powerful, dynamic, and cavernous at the same time. There’s so much we can apply to networking – think how many times we test production CLI code changes versus our application developer counterparts. Concepts we should take influence from:
- Software Development Life Cycle (SDLC) concepts with Waterfall, Agile, XP
- Testing Methodologies / QA – Test Driven Development, Continuous Integration/Deployment
- Code (config) sharing / Bug tracking (Case management)
- Philosophies – DevOps, Open-Source
- Tools – More than I can count and there’s 20 more available tomorrow.
- Application Architectures – Microservices / Distributed services
Each of these has applications to networking – and to infrastructure as a whole. Examples:
- Building applications along with their network code together in the lifecycle
- Emulating and testing network or network function changes in a QA environment with automated metrics proving feasibility (CI/CD for networking)
- Moving to a model where network changes are done through git, pushed through a toolchain, and then moved to production infrastructure – as opposed to SSH’ing in and clobbering around and then backing up the configuration later.
- The huge opportunity of sharing network toolchains, configurations, and scripts
- Extending the reach of Configuration Management tools to network switches (Puppet, Chef, Ansible, Salt)
- Using VXLAN overlays to create ‘micronetworks’ to match accompanying microsegmented applications
- Use of device level API’s to provide services rather than ticketing queues or manual processes.
The Grumpy Stuff
These aren’t new inventions by any means – they are being worked on by different people within different companies. However they’re not getting quite the fanfare that things like OpenFlow controllers are getting.
The debate comes down to who is more equipped to handle this transition – the people with the software knowledge (tools, processes, languages, philosophy) or network experts (dinosaurs who know all the dependencies, complexity, and caveats). There’s a huge gap in the middle which is why this is so much fun and NPUG is getting such good traction, though the answer is surely not binary.
How about a mildly edited double entendre to close it out?
“You will always be fond of me. I represent to you all the SINs you never had the courage to commit.” -Oscar Wilde
I’m not expecting for a new acronym to hit the trade rags, but I hope it will help you segment what we can do with software in addition to the traditional SDN definition with it’s narrow lens. But it’d be a SIN not to think about it. Maybe you’ll become a SIN’ner too. Ok, I’ll stop.