Networking Field Day 5 (NFD5) drew to a close yesterday, and I have found myself sitting in a plane at around 32000 feet musing somewhat on the fact that my trip home has just been redirected via Chicago rather than Las Vegas (Viva Chicago!), but mostly reflecting on the week’s activities. If you aren’t sure what I’m talking about, read my recent post about the Networking Field Days.
What struck me more than anything was not just that the vendors presenting to NFD5 each delivered a very clear message, but that most of them delivered the same message.
Software Defined Networking (SDN)
Not just a “buzzword-du-jour”, Software Defined Networking (SDN) really is starting to take shape, and it was evident from every corner that SDN is a core part of the strategy going forward. It’s beyond the scope of this particular post to dig into what SDN really is (that’s another post coming soon), but at a high level we can think of it as making the network controllable programmatically. SDN reminds me a little of “cloud” in terms of the different solutions that claim to represent it. I’d say that SDN is distinct from – though closely related to – things like orchestration, automation and OpenFlow. I think it’s also fair to say that running an expect script to configure a CLI does not count as SDN!
Cisco
Cisco’s presented their ONE (Open Network Environment) and the onePK (Open Network Environment Platform Kit). Cisco plans to roll out the ONE framework to pretty much all existing devices (we’ll see how that eventually works out), offering access to the platforms through multiple APIs including REST, OSGI, OpenFlow and Puppet, which together could allow for automated provisioning and software-managed forwarding control. The ability to push applications to platforms could allow for distributed (edge) filtering and forwarding policies, and then perhaps the overall topology could be handled by another system.
Juniper
Juniper talked this time about the inclusion of a Puppet agent as an Extension in Junos, currently for EX4200, EX4550 and QFX3500 but planned for release soon for other platforms as the relevant Junos release updates to include support for loadable packages. The inclusion of Puppet again looks to the automated provisioning. They also spoke about the ‘programmable core’, and their vision of moving to all-Layer3 networks where possible, and using Layer 2 only when necessary.
Plexxi
Plexxi is a start up that offers an interesting Ethernet switching product that appears to offer a scalable, dynamic fully meshed switching core. In Plexxi’s case, forwarding is not controlled real time by an external controller, but instead the controller provides the intelligence to manage the high level topology and provide bandwidth where needed, honor specific needs for traffic isolation and provide a form of constraint-based switching (e.g. minimum number of hops, bandwidth needs, and so forth). Managing this kind of process manually would be impractical and error-prone, and in today’s environment would require change windows to execute the changes due to the impact of making the changes. Plexxi’s solution offers the possibility to re-provision bandwidth between switches on the fly, without any physical changes needed, and apparently without interruption. While this all happens with a proprietary control protocol, the network changes are once again happening through computers – not by logging in to all the devices.
Brocade
Still cursed by the impression that they are “just a storage company”, Brocade in fact have a fairly well developed Ethernet switching portfolio, and certainly if we are to believe the message they gave, are ahead of Cisco and Juniper in terms of actually getting out there and implementing programmable networks via OpenFlow. Their very active membership of the Open Networking Foundation (ONF, ironically a closed group with a high cost of entry) demonstrates their leadership in the OpenFlow space, and it was inspiring to hear them talk about their vision for networking.
Off Message?
Ok, that’s perhaps a slightly unfair heading, because the remaining two vendors that presented were not necessarily in a position to talk about SDN in quite the same way as the switching hardware vendors above.
Ruckus Wireless
They may not be all about SDN, but the visit to Ruckus was one of my favorite of the week. WiFi is not my area of expertise, but I thoroughly enjoyed hearing about their goals to address wireless performance problems, and seeing their products. For what it’s worth, their guest wireless network was very fast despite an incredibly busy airspace (the number of SSIDs showing up in my inSSIDer scan was quite disturbing!
Solarwinds
Solarwinds specialize in management products, and the one thing that was evident (and was the subject of some heated discussion) is that the network landscape is changing rapidly, and one weak point of SDN is going to be OA&M. SNMP just doesn’t cut it, but right now it’s almost the only ‘standard’ out there that most products are likely to support. This is going to be a challenge for companies like Solarwinds whose product set covers everything from security management, to configuration management, performance management and IP Address Management. Managing SDN may well need even better, and faster reacting, tools than we have now – but at a minimum will require the ability to communicate with the various solutions out there. Solarwinds doesn’t seem to have an answer to the needs of managing a software defined network yet, and while there was a hint that this was a very active topic internally, they weren’t able to share their direction at NFD5.
Reasons To Care
“Infrastructure is code” — Abner Germanow (Juniper)
Wise words. One way or another, the industry’s direction is SDN – which means that the ability to configure a particular CLI will slowly become less important than the ability to knock up some code in Ruby (or similar), and to configure and manage the controllers that will be managing your network in the future. The network no longer ends at the access switch either – we have already seen the deployment of soft switches (e.g. vSwitch) and other network services running as VMs or within the hypervisors themselves. And communication between the servers and the network will become all the more important because those virtualized network services need to integrate with the common policies defined for the network. Intelligence – and even the underlying layer 3 forwarding decisions – are being pushed out to the very edge of the network as localized, distributed functions; a stark contrast to the centralized services we are used to today.
From a network configuration perspective, there won’t be a need to write a script to configure a new server port on a switch and schedule a change window to bring it up – that process will be integrated into an error-free (hah!) process of automation and orchestration that will see a server provisioned as a VM, and all the necessary network configuration pushed out from a centralized system based on pre-built templates and customizations based on the application needs. Protocols like Spanning Tree are on their way out (keep the applause down, please) – not through techniques like VSS, VPC, TRILL and SPB, but rather because the intelligence for loop avoidance has moved to a controller that understands the network topology and programs the switches to provide a loop free, load-shared infrastructure. Adding a VLAN for east-west communication no longer means running VTP or configuring multiple switches and trunks – you simply define the need, and let the controllers get on with making it happen and figuring out where it needs to be trunked. And finally, adding and removing redundant paths can be done without interrupting traffic – additions don’t trigger recalculations that stop traffic flowing, and scheduled path interruptions or removals can be effected without any impact by pre-emptively reprogramming traffic flows to avoid the link in question before taking it out of service. Does that sound good?
SDN sounds great to me. It’s not entirely here yet though – every SDN story I heard seems to have gaps in it that are glossed over somewhat in the presentations, but without which the end to end solution isn’t anywhere near as nice and automated as you’d like it to be. However, the progress that has been made even since Networking Field Day 4 last October is huge, and all the major players are engaging with SDN in a very serious manner.
Think how quickly server virtualization orchestration has moved in the last few years. It feels like we were using nothing but dedicated server 5 years ago, and yet we seem to use nothing but Virtual Machines (VMs) now. We’ve gone from a manual VM provisioning process to the point where you can fill in a web form, select your image or software requirements and receive an IP and login for your newly created custom VM 10 minutes later.
Choo Choo!
While the SDN train is by no means leaving the station, if you aren’t in line to buy a ticket there’s a strong chance you’ll be left behind.
Disclosures
The vendors listed above were paid presenters at Networking Field Day 5, and while I received no compensation for my attendance at this event, my travel, accommodation and meals were paid for by NFD5. 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.
Please see my Disclosures page for more information.
Leave a Reply