Several companies have announced they have OpenFlow-enabled switches, but for these companies, there is still no strategy and no reasoning as to why their switch should be used when deploying an OpenFlow based SDN. Furthermore, they lack a strategy overall looking at the various components of a Software Defined Network. From a hardware standpoint, some of the same features and characteristics (buffers, table sizes, etc.) will still need to be compared as we already do today in traditional networks, but even that, isn’t documented in these announcements. A lot of these vendors think they are on the offensive [vs. Cisco] announcing OpenFlow enabled switches (without a controller), but they really aren’t, in my opinion.
Greg also comments about not having heard much from Cisco stating, “Therefore, I'm expecting something at Cisco Live next week as part of usual announcement blitz.” Since I’m intimately involved with Cisco and their technologies on a daily basis, I’ll agree there as well. They have been pretty tight-lipped about what they are doing and even thinking with regards to Software Defined Networking…until now.
If you are attending Cisco LIVE and do some digging, you will actually find what Cisco is going to present next week – at least some of it. So you are in for a real treat. Those that are registered to attend LIVE can download the presentations ahead of time. For those who have lots of time, I’d recommend downloading the presentation titled, “Software Defined Networks and OpenFlow.” It is BRKRST-2051 and will be presented by Frank Brockners, Technical Leader, based out of Cisco Germany. I jokingly say, “for those who have lots of time,” because the slide deck is ninety-three (93), yes 93, slides. I urge those to go through as much as possible ahead of the session to ask more intelligent questions during the presentation.
Here’s the thing. The slide deck covers a lot of material. Maybe that’s stating the obvious because it is 93 slides, but I question if it’s too much too soon – for Cisco. Aside from the slide deck that was presented during the Morgan Stanley call last week, I believe this is the first, or one of the very first public Cisco slide decks on SDN. So I ponder – why so many slides given the majority of Cisco customers that will likely be in attendance, have probably not heard much in this space yet? Wouldn’t it be better to keep it simple? I’m thinking to use fewer slides, wow the audience, and have those that bleed blue foaming at the mouth wanting more, no? Doesn’t a strip tease always work better? I digress.
On a side note, there isn’t any product related information reviewed in the presentation – it’s aimed at more of the conceptual approach Cisco will be taking with SDN and general market education.
Anyway, my intent was not to harp on the marketing style, but just think it could have been done a little differently. That’s all.
As stated previously, there is a lot of good content to digest. The deck is broken up into three major sections including Programmatic APIs, Agents and Controllers, and Network Infrastructure Virtualization. David Ward already stated this at the ONS back in April, that he and Cisco, believe the market has been focusing solely on the separation of the control and data planes and hasn’t focused on all other planes available to be programmed or leveraged for state extraction. Here is a slide where Cisco shows how they foresee enabling a holistic programmable network across multiple layers.
- Element APIs – provide operators with how packets flow through the network. Network Management Apps to use onePK APIs to show path of flows. Example: Path Trace, Diagnostics, and Troubleshooting
- Places in the Network APIs – operator needs to re-direct traffic flows. Custom Route Application deployed with onePK APIs communicating directly with the forwarding plane. Example: Highly customized routing algorithms.
- Places in the Network APIs – operator needs to enable superior experience accessing a particular type of service/application. Customer Policy Server deployed with onePK APIs communicating end users and network devices, i.e. user request service, policy server automatically generates required bandwidth/qos onto associated network devices. Example: Bandwidth on Demand, Policy Controlled Subscriber Gateway, etc.
- Area APIs – operator needs a central view of the network, need to locate an optimal service, or optimize load placement. While this slide doesn’t explicitly state onePK APIs at all, at this point, let’s assume they are being used. Network devices deployed with onePK APIs communicating with applications such as Network Positioning System (NPS), Hadoop systems, and Network Management Applications. Example: Topology Graph
Unified view of Slides 23 – 26:
As I think through these applications and numerous APIs, I wonder how cohesive the development will be because there are so many Business Units within Cisco, or will they look to partner with smaller, more nimble companies to develop some of these applications? Then again, will it and should it matter?
One of the driving forces behind Software Defined Networking (SDN) is to make the ecosystem more vertically oriented such that the pace of software, hardware, and especially application development can be independent from one another so we should see far superior tools and applications than we have in the past. That is grand because simple to use applications (NMS, etc.) for the network operator is an area that has struggled across the Enterprise over the past two decades.
However, from the pictures shown in the slides, it is how you’d imagine, with various applications using the onePK architecture extracting information and manipulating the forwarding plane of network devices. If you have multiple applications that can manipulate the forwarding plane and/or config of a device, these applications need to be integrated somehow. Don’t they? Will we face even more technical challenges in the future? These are just some of the things that need to be thought about by all, not just Cisco. However, for Cisco, it becomes even more important because they play in so many markets and have so many device types. Unfortunately, that is sometimes a drawback as well for the end users. That isn’t new news – pretty typical for a large company and wide install base across many segments.
This post is longer than I had anticipated, but the next section in the presentation went over Agents, Controllers, and OpenFlow. This section could have been cut down by several slides. It reviewed high level concepts, but also drilled down quite a bit on the history of the OpenFlow protocol, and covered some deployment scenarios for OpenFlow switches, and even had a slide on federated controllers. The presentation ends by reviewing overlays, VPN technologies, network partitioning, and even talks about the “History of SDN.” Is it that old already? I’m not going to go into too much more detail here, so I’d encourage you to attend this session (wish I could with you), and download the slide deck as well. Please write about the session should you be attending!
In parting, here is one last slide that caught my attention.
Will this play out to be a network evolution or a network revolution is the question? I can’t wait to find out.