Greg Ferro does a nice job here directly stating the networking incumbents should step up with an SDN strategy.  I agree 100%.  Brad Casemore also chimes in with his thoughts.  If you aren’t already reading their blogs, I encourage you to do so because you’re missing out.

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.

Repeating what has already been said before, why is it taking so long for these companies to form their official technical strategy in this space, or better yet, why aren’t they the driving force?  Wouldn’t that help them maintain the mindshare of their current customers?  Including Cisco, if the incumbents were really on the offensive against each other, they wouldn’t have to worry about commoditized hardware or reduced margins, which are supposedly major drawbacks of adopting such a strategy. 

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. 

Several of the next slides review network absractions and the need for various types of APIs for different functions.  While stating not all APIs are created the same is pretty obvious (see slide below), having a common foundation is hopeful and wishful thinking.  This looks to be the approach Cisco is taking.  Nice job!  They are calling it “Cisco onePK” (one Platform Kit) and will be the underlying architecture for the APIs that are opened up on Cisco network devices.

Here is a more detailed look at the APIs in the slide above showing practical use-case scenarios for each.  More details can be found in slides 23-26 of the presentation. These slides are also shown below.

  1. 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
  2. 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.
  3. 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.
  4. 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 ApplicationsExample:  Topology Graph

Unified view of Slides 23 – 26:

These examples are what we’d expect given the rich amount of announcements and articles that have been published over the past year. 

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.
The picture on the right in this slide was taken from the Lightspeed Venture presentation that was delivered at the Open Network Summit.  Download it if you wish to review the whole deck - I'd recommend doing so.  By looking at the hype cycle, we can clearly see we are entering a fascinating time in the networking industry. 

Will this play out to be a network evolution or a network revolution is the question?  I can’t wait to find out.

 


Comments

06/10/2012 20:56

Hey Jason...

A fine job of sleuthing. :) So Frank's session is really meant to be a deeper dive into our POV with regards to SDN. As you have pointed out, there is actually a fair amount of complexity related to SDN, regardless of any vendors' particular strategy, and that is a lot of what Frank explores. If you are interested in a deeper understanding of SDN, I highly suggest you try and catch one of the two deliveries. In terms of other things we might end up talking about, rest assured we understand we have a number of different audiences and strive to keep them all happy. If you want to chat later this week, feel free to ping me.

Regards,
Omar (@omarsultan)
Cisco

Reply
06/10/2012 21:12

Omar, thanks for stopping by.

Yes, definitely a fair amount of complexity in SDN as a whole. Many moving parts and a growing ecosystem.

Because of that, my hope is that as we see more from Cisco (and others) the messaging is clear and concise. I just worry that initially too much content can cause confusion.

What were you referring to when you said, "one of the two deliveries?"

Reply
06/11/2012 00:05

If I remember correctly, Frank has two deliveries of his session one on Wednesday and one on Thursday.

Omar

06/11/2012 01:43

"one of the two deliveries" just means that I'm presenting the session twice - Wednesday at 8am, Thursday at 10am.

Regards, Frank

06/11/2012 08:05

Omar/Frank, thanks for confirming. That's what I figured. Unfortunately, I'm not able to make Cisco LIVE this year. I look forward to some video recordings or feedback from the blog/twitter communities that are attending.

Thanks,
Jason




Leave a Reply