I was talking elsewhere this week about the speed at which Software Defined Networking (SDN) is being implemented by companies and made a slightly pessimistic comparison between the adoption of SDN and that of IPv6. I’m undoubtedly not the first to make this comparison, but in may ways it’s compelling. Well ok, maybe it’s not entirely fair, but let’s look at a few areas of similarity between the two technologies.

Incomplete Technologies

With IPv6, early adopters were faced by the fact that the protocol was simply not complete at the time; working groups were still trying to hammer out the details of some of the functionality, and people predictably were not willing to jump on a protocol that wasn’t ready to go. The nature of the IETF is that decisions and approvals take time because of the thorough process through which they have to run. Then once the protocol was stabilizing, we then had to wait for vendors’ code to support IPv6 properly and fully (and in the case of network hardware, without reverting to software switching, please). SDN has a slightly different problem. Firstly, what on earth is the scope of “SDN” anyway? That changes every week it seems, along with a highly fragmented market space of solutions, both open source, open API and vendor-proprietary. I believe that while this is an inevitable stage we will have to go through as the component technologies mature, it also puts people off jumping in and shifting their production network to “SDN”. The additional negative impact of SDN-washing isn’t helping either, and just further blurs the definition of what Software Defined Networking really is (whatever that might be) and makes it sound like a buzz word not a serious proposition. I will say again that I’m waiting for the “SDN Compliant!” sticker to start appearing on hardware boxes and technical datasheets. Either way, the technology and the concept of SDN is still very much in a state of flux, and until it settles down and has a more identifiable shape to a broader section of the market, it won’t be adopted the way it perhaps deserves to be.

Reskilling Required

Subnetting in IPv6 is not exactly fun; if you thought it was bad for IPv4, then it only gets worse in IPv6, and it’s very easy to make mistakes. The need for good DNS for IPv6 becomes critical, and managing allocations is a heck of a lot messier than for IPv4. Configuration for IPv6 on the network is not always as simple as just adding an IPv6 address to an interface, and managing allocations to end points in an Enterprise is a whole new way of doing things. Not that any of this is insurmountable, but it can cause people to hesitate. For SDN the reskilling fear has revolved around DevOps (or programming skills in general). With IPv6 it seemed clear that dual stack was going to be the way of the world for a reasonable time to come; the two protocols would run side by side. With SDN for some reason, the majority seem convinced that SDN adoption is an all or nothing proposition, and you either start coding or you’ll be out of a job. Why is a hybrid SDN/legacy network not apparently considered as likely an outcome when we’re worried about what’s going to happen in the future? For Openflow fans, I’d actually argue that having a hybrid model is not only inevitable in the short term, but it’s actually preferable. For example, when I spoke to Plexxi about their SDN solution, I asked what happens when the switches boot up and can’t contact a controller? Answer: they have enough in-built intelligence to automatically (and autonomously) create a network without loops and pass your traffic quite happily. Although the marketing department might not want to shout about it, in some ways that is the very definition of a hybrid SDN solution where rather than just having dumb switches that are 100% reliant on a controller, we at least embed enough smarts in the switches to do their job with or without the controller. Similarly with Ethernet fabric technologies like TRILL, SPB and QFabric, you aren’t forced to migrate your entire network to that technology; it can very easily work as a part (usually a core) of a larger network that also runs legacy protocols. In short (too late for short, I fear), in both cases we’re not looking at reskilling our network engineers, we’re simply enhancing and broadening the skillset. As I have said before, I strongly believe that most deployments of SDN will not involve programming, because most people won’t want to risk their network on their own bug-ridden code. Chances are, you’ll want to risk your network on somebody else’s bug-ridden code – somebody that you can call up at 3AM and scream at when your network goes down.

No Killer App

This, no pun intended, is the killer for fast adoption of either technology. Putting aside executives reading airline magazines and announcing that “we should be doing this,” what is the motivation to adopt a new technology? One of the biggest divides between hard core technical geeks and upper management can be that the geeks are perceived as wanting to do things because they’re clever, they’re cool, or they just feel like they should be keeping up with the latest thing out there. Management on the other hand – mostly – have to stop and ask what the business case is for investing in the skills, software and hardware necessary to implement a new technology, not to mention signing off on any potential stability risks for the business as a result. And yes, there are absolutely those who fly too much and just want to have something because, well, everybody else seems to be doing it, so if we aren’t doing it we must be doing something wrong.

IPv6 is the classic example of a solution looking for a problem to solve. IPv4 NAT-PT has extended the life of IPv4 beyond any reasonable estimates, and despite the exhaustion of IPv4 blocks perhaps courtesy of overly generous legacy allocations, we still haven’t seen the speed of adoption you’d hope for with such a huge global problem staring us in the face because most people have no need to change. While adoption is increasing over time, which is great, I’m not sure we’ve yet found the hook that will have people saying “Wow, I have to have this so that I can do .” I have had an IPv6 tunnel running to my house (and thus, IPv6 on my LAN) for just over five years now, but for the longest time I’d explain to people that the big problem with the IPv6 Internet was that once you had connected to it, there was nothing to when you go there. And that was including the fact that I used Google’s DNS so that I could get IPv6 access to Google and YouTube even though regular DNS wouldn’t resolve them, and many other sites required manual intervention to use IPv6 (e.g. http://www.v6.facebook.com/). I’m pleased to say that things have improved since then with many more of the sites I want to visit on the Internet supporting IPv6 now. Still the point remains – if IPv6 were not enabled on these web sites, then so what? What difference would it make to my browsing?

As I say, there’s no compelling reason, no killer app, that means that IPv6 is a “must-have” on my network. The closest thing I can think of to a compelling argument is the use of IPv6 to support IMS both for mobile to mobile services as well as fixed/mobile convergence applications; but that’s more of an SP issue than a good reason to deploy v6 in your data center.

SDN in many ways has the same problem. It’s cool, it offers lots of potential benefits and clever solutions, but what’s that one critical reason to deploy it? I’ll spare you by not inserting the marketing claims here because I’m feeling like we’re at or near the top of the Hype Cycle (the “peak of inflated expectation”) when it comes to SDN right now. What will happen in the coming months and years is that we’ll see how much of the hype turns into reality, and even when we know what’s real we’ll still have to figure out whether that’s necessarily a reason to disrupt our network operations and shift to a new (or hybrid) paradigm. I would say though that in my own opinion, the benefits of SDN are going to be more tangible, more measurable, and thus with a more demonstrable payback period, than is the case for IPv6.

Talking Turkey

IPv6

IPv6 has faced a painfully slow adoption rate since it was first dreamed up almost 20 years ago. Here are a few depressing statistics:

• Of the Alexa Top 1000 websites, only 137 are accessible using IPv6
• Google tracks the percentage of their users accessing Google over IPv6 – less than 3.7% are using IPv6:

• Only 17.5% of ASNs in the IMF’s “G7 countries” are announcing IPv6 prefixes. Things are not much better elsewhere, though APNIC has reached the heady heights of 21%.

Just in case it sounds like it’s all doom and gloom, the Internet Society offers a brighter outlook, believing that by the end of 2014:

• 10% of all global Internet traffic to Google, Facebook, and Yahoo! will use IPv6
• IPv6 will have additional large commercial rollouts on every continent
• All major United States network operators will offer IPv6 on a commercial basis to end users

The second and third bullets are a touch on the vague side, but number 1 is brave given Google’s own statistics above. The reality is that these figures can only go up if IPv6 in the consumer market (i.e. consumer-facing service providers) becomes the de facto standard.

SDN

So what of Software Defined Networking? If you believe the SDN-washers, we’ve had SDN for years now. Who knew?! But how on earth can you put a figure on something that isn’t well defined? IPv6 is a definite “you use it or you don’t” thing, but SDN is so much more wishy-washy in terms of what it might be. Gigaom reported on a survey commissioned by Brocade that concluded that 1 in 5 Enterprises use Software-Defined Networks. That data point is then quietly tinged by the comment that “The tricky part is what exactly respondents had in mind when they said they are using SDN technology now.” It’s a very real problem; when a technology has such an unclear definition how on earth do you actually figure out real adoption rates? The only way, as I see it, would be to either follow up in that survey with a question saying “If yes, which technologies are you using?” Or perhaps better still, create a bit fat list of as many SDN-related technologies as you can, and as people which ones they have in the lab, in production, or are planning to test in the next 12 months. And yes, this is why I don’t design surveys for a living! The thing is, I’ve seen a few charts out there claiming to show historical and predicted SDN adoption and I simply don’t know what that means in real terms. SDN is moving so quickly and potentially covers so many things, how can we put numbers on it?

Beyond that we get to gut feeling. Aspects of SDN really do feel like there’s a sense of urgency about it, and that there is a short- to mid-term potential gain available by introducing those technologies. That’s good, because while I see strong similarities with IPv6 and I imagine that the SDN adoption charts will ultimately turn out looking just like those for IPv6, I also think that the timelines in which these changes happen will be significantly more compressed in the case of SDN. The difference is that with IPv6 I never felt a sense of urgency about it in the industry; it was always tomorrow’s project. SDN – or at least some aspects of it – seem to be something that people are seriously considering, and looking at very actively as something they might benefit from. Early adopters are still taking the risks, and they of all people are most likely to benefit from a strong DevOps capability to customize their SDN solution to what they need it to do and integrate it with their existing systems. However, I can well see that in the next 5 years may of us will be be Hype Cycling right up the “Slope of Enlightenment”. Or if you prefer the Technology Adoption Cycle terminology, we’ll be moving from Early Adopter to Early Majority.

But first, we’d better figure out what on earth we’re measuring and calling SDN.

 

Disclosures

Both Brocade and Plexxi were paid presenters at Networking Field Days 5 and 7, though beyond answering one question (Plexxi), their presentations at these events did not feed into this post. While I received no compensation for my attendance at this event, my travel, accommodation and meals were paid for by Tech Field Day. I was explicitly not required or obligated to blog, tweet, or otherwise write about or endorse the sponsors, but if I choose to do so I am free to give my honest opinions about the vendors and their products, whether positive or negative.