The primary benefit of SDN (as claimed by its promoters) is a geek’s dream: the ability to program the network (or, more precisely, control network’s behavior through programmable tools).

Sounds great – we’ll finally be able to fix that pesky detail the vendor never wanted to implement (probably for a good reason). But should we REALLY do that?

If you’re Facebook, Yahoo or Google, the answer is obviously Yes.

If you prefer being MacGyver over having a stable network (and love being called when your masterpiece crashes at 2AM), go for it ... but what if you happen to be somewhere in the middle of the U-curve? Should you stay away from SDN until it crystalizes into mature shrink-wrapped software products or should you start getting your hands dirty?

Learning and labbing has never hurt anyone. You might not be ready to deploy OpenFlow or any other SDN tool in your network but that doesn’t mean you don’t have to know what it is and how it works. Experience never hurt anyone – if nothing else, you’ll be able to explain why things don’t work as well as marketing whitepapers claim they should.

Get a few switches that support OpenFlow: Linksys, HP Procurve or Mikrotik. Download OpenDaylight. Make them work.

Get Cisco’s CSR. Configure it with NETCONF. Connect it to a Quagga BGP daemon. Insert BGP routes into CSR’s forwarding table. Play with OnePK (once it becomes available).

Figure out what Chef and Puppet are all about. Write a few Perl or Python scripts. Get some serious Linux skills.

From Theory to Practice

You got your hands dirty in the lab. You got NETCONF running with a Cisco router and Juniper switch. You programmed an Arista switch with Python. You even got some OpenFlow entries into a switch to serve as ACLs. Your boss is not totally opposed to your ideas. Now what?

Go for the low-hanging fruit. There must be something in your environment that everyone detests doing, but it still has to be done. VLANs? ACLs? Some interesting logging and correlation stuff? You know it best. Go for it.

Make it useful. Solving the hard problem (example: configuring VLANs through NETCONF) is just half the work. Now you have to make your tool useful to everyone else. You’ll probably have to implement at least a minimal GUI (read: web page) to allow the operators to enter parameters and trigger your tool.

Aim for minimal impact. Whatever you do, start small – minimal configuration changes, minimal modifications to existing network operation. Go for solutions that you can deploy on individual non-critical devices.

Software development is more than writing code. Understanding the SDN technologies and tools and having some programming proficiency is not the end of the journey – it’s just the first step out of the Shire.

You should approach your network programmability solution like any other mission-critical software project. It needs source control, unit tests, integration and validation tests and well-defined deployment process. You will probably have to fix a bug or two, in which case revision control and regression tests become a must.

If the above paragraph sounds like Latin to you, find someone who knows more. If you have a good programming team in your environment, now’s a good time to talk to them and become their temporary apprentice.

No job is finished until the paperwork is done. Write the documentation and user instructions. You might also want to get this as a permanent reminder.

Anything else? Sure, I have plenty of design and implementation ideas, but they’ll have to wait for another blog post.