Separating SDN hype from reality: A user's view

In January 2013, Citylink announced to the New Zealand Network Operators Group at their annual conference that it intended to invest in software defined networking technology, and planned to apply this technology to the NZ Internet Exchange Points in Auckland, Wellington, Christchurch, Palmerston North and Hamilton.

We’re looking to improve the architectural design of the Internet Exchange. I won’t go into the detail but suffice to say it has some issues – and those issues affect all Internet Exchange operators worldwide.

Back in early 2013, software-defined networking (SDN) was a relatively new technology, and the leading realisation of that was via the open standard, Openflow. Since that time a great deal has changed. We’ve seen many, many different vendors claim their latest technological breakthrough as SDN. I was reminded of this recently with an IP PABX vendor claiming it to be SDN. Sadly today this happens far too often with overly enthusiastic marketers pushing the boundaries that separate fact from fiction.

That’s not to say that Openflow is the only implementation of SDN technology, but it is certainly one of the first (if not the first).

For the purposes of this article I’m going to boldly ignore the derivative developments and address Openflow as the key area to focus on. My reasons will become clear.

And let me be clear. We are a service provider and a customer of technology just like you. We have exacting needs (as you’d hope) but we hope that you find our insight useful.

Focus on open standardsOur view is that one of the success factors of the Internet was that it was based on some key open standards: TCP/IP, HTTP, DNS etc. We suggest that when you’re dealing with your SDN vendor you hold them to account when they claim their technology is based on an open standard.

'Based on an open standard' is not good enough. It either is or it isn’t. Demand standards and demand better. We want internet scale technology and look closely at what is a mandatory part of the standard and the aspects that are optional.

Why? Because we think the real promise of SDN is ensuring the value of the application resides with the customer. An open standard enables this because there is a clear delineation between hardware and software. It enables the customers to invest in SDN without fear of being held to ransom by a proprietary solution. It also allows reuse of part or most of your investment in later years.

Resist the temptation of all encompassing proprietary solutions that are 'based on an open standard'. After all, we have that now - why would you invest in SDN to get the same result? Yes, it might offer operational workflow benefits, yes the orchestration and streamlining of provisioning is nirvana and yes it is 2014 buzzword compliant.

Choose carefully

We struck some real challenges early on in our SDN development. It turns out that what we’re trying to do (and doing) is actually complex and hard by SDN standards.

Our case meant that there were 25 million traffic flow scenarios and we wanted an architecture that allowed for planned outages with no impact on the service levels. Our flow count was considered gargantuan by most SDN vendors and it wasn’t until version 1.3 of Openflow was widely supported that we started seeing a match between what we wanted and what vendors wanted to sell us.

Take it from an expert that you want to demand Openflow 1.3 at least. Anything else is baby-steps that won’t enable a sophisticated customer to move ahead in a meaningful way. Oh, and ask if you can use a third party Openflow controller. That’s a good test.

Think about your use case, don’t believe the hype.As I said earlier, we think that customer empowerment and ensuring the value of the investment in your network stays with you. To get that true return on investment you do need to think carefully about the problem you’re trying to solve.

SDN’s trick is to present a set of API’s, tools, and tight integration with databases of information so that ease of use is achievable, realistic and frankly, slick.But that does require you and your networking folks to think about layers 1,2,3 and 4 and beyond.

SDN will not eliminate the challenges you face now overnight. But I can assure you that it will present you a new way of dealing with challenges that you previously thought were too hard or impossible. But you need to be very very clear on the problem you are trying to solve. And you need some smart partners.

It is not a panaceaContrary to some media reports, SDN will not do your dishes for you, will not magically refill your coffee cup and certainly will not solve your business challenges overnight.

But it does present an incredibly interesting approach that will allow you to look at your enterprise or data center or networking architecture in a new light. It does allow you to reconsider old problems and deal with them using new approaches.

We think it is one of the most exciting things that’s been in discussion for a very long time and that’s why we’re backing it. But it will not cure all.

Be sensibleThat is our final word. Don’t think that SDN is the magic ‘pain away’ or instant ‘exponential growth’ deliverer. It is not. It will require your investment and your attention.

With it warts and all, SDN, Openflow and a commitment to being sensible and rational, we think that it’s something worth paying attention to. One more thing – make sure IPv6 is supported now. You will be thankful for this later – I can promise you that.

Jamie Baddeley is group chief technology officer for TeamTalk, Citylink and Bay City Communications (t/a Farmside).