Henk left a wonderful comment on my SDN will not solve real-life enterprise problems blog post. He started with a bit of sarcasm:

SDN will give more control and flexibility over the network to the customer/user/network-admin. They will be able to program their equipment themselves, they will be able to tweak routing algorithms in the central controller. They get APIs to hook into the heart of the intelligence. They get more config-knobs. It's gonna be awesome.

However, he thinks (and I agree) that this vision doesn’t make sense:

If you truly want to prevent what happened at United, the exact opposite is needed. Less config. Less knobs. Less tweaks. Less "smart stuff" invented by individuals or individual customers.

Unfortunately I don’t believe we’ll ever see a world with fewer tweaks and nerd knobs, and here are at least a few reasons why:

• Machoism inherent in networking – aka I Can Get the Job Done no Matter What. I can fix whatever problem is caused by broken applications by adding another layer of indirection and duct tape – be it NAT, PBR, GRE, VXLAN, OTV, LISP, SDN… because if I do that, I’m the hero (actually not – you just created massive technical debt) whereas if I tell the application people to fix their applications, I’m a department on NO.
• I know I can stretch this thing (or maybe it’s growing organically). Running a country-wide bridged network? Why not (yeah, one of them crashed badly in mid-90s). Running a 300-router IS-IS area? Sure (it actually works). Running a 5000-router network on OSPF instead of using BGP as the core protocol? Sure, why should we consider the proper tools for the job at hand if we hold a hammer?

• Network designs based on whitepapers instead of understanding of technologies used in the design. I can’t tell you how many broken designs I’ve seen – and most of them were broken because architects creating them didn’t understand how the underlying technologies really work. The truly sad part is that most of these designs work in PoC labs, and break only when faced with large-scale deployment, when the easiest way to fix them is to yell at your vendor to (A) fix their bugs and (B) give you yet another nerd knob to make your broken thing work.
• Unique snowflakes. Instead of using cookie-cutter designs, we prefer to carefully craft unique snowflakes that magically integrate the legacy stuff that should have been dead years ago with the next-generation technologies… and every unique snowflake needs at least a nerd knob or two to make it work.

Henk concluded his comment with another perfectly valid observation:

I bet half the configuration commands in today's routers could be removed.

And that will never happen for a simple reason: it would break too many existing networks… and as long as the nerd knobs are available, an overzealous engineer will inevitably use them and create an almost-permanent vendor lock-in.

Homework: Don’t be like that. Resist the siren song of nerd knobs. Make your designs and configurations as simple as possible. Your network (and people running it) will thank you.

Taking the next step: Once you clean up and simplify your configurations, it’s easy to automate them. The Ansible for Networking Engineers webinar includes a case study that gives you a step-by-step description of the whole process.