I spend a lot of time behind curtains. That’s not really out of choice as it’s the nature of where they stick you when you’re running the network at a large tradeshow. We call it the Network Operations Center – NOC if you want to sound cool – but most people just know it as the guys to complain to when your computer doesn’t work at a show. It’s often a thankless gig and it can be extremely stressful at times, but setting up a temporary network that might live for less than a week to deliver fast wired and wireless access to thousands of people in a completely foreign environment is an exciting challenge. Here’s how it happens. Read More »
Now that you’ve survived the annual gift-giving extravaganza (at least in the US) of the holidays, you have probably noticed some colleagues and employees showing up touting new smart phones, tablets, or random internet-connecting devices. Happy as you may be for them, you probably also know (because, hey, you’re reading this blog) that all these fun little devices can put a strain on a company.
In the last few weeks, your IT team (that probably includes you or someone you know) has probably been spending an inordinate amount of time helping users get their devices connected. They’ve probably been dealing more with maintenance headaches than working on more interesting services. In fact, headache medicine sales spike in mid-January in regions with higher densities of people in IT*.
For me, even though I am mostly a hardware geek, one of the coolest parts of the Cisco ONE launch at CiscoLive was the introduction of onePK. We see onePK as an core enabling technology that will have some cool stuff down the road.
So, one of the more common questions I get is about the relationship between onePK and other technologies related to network programmability such as OpenFlow (OF). Many folks mistakenly view this as an either/or choice. To be honest, when I first heard about onePK, I thought it was OpenFlow on steroids too; however, I had some fine folks from NOSTG educate me on the difference between the two. They are, in fact, complementary and for many customer scenarios, we expect them to be used in concert. Take a look at the pic below, which shows how these technologies map against the multi-layer model we introduced with Cisco ONE:
As you can see, onePK gives developers comprehensive, granular programmatic access to Cisco infrastructure through a broad set of APIs. One the other hand, protocols such as OpenFlow concern themselves with communications and control amongst the different layers—in OpenFlow’s case, between the control plane and the forwarding plane. Some folks have referred to onePK as a “northbound” interface and protocols such as OpenFlow as “southbound” interfaces. While that might be helpful to understand the difference between the two technologies, I don’t think that this is a strictly accurate description. For one thing, developers can use onePK to directly interact with the hardware. Second, our support for other protocols such as OpenFlow is delivered through agents that are built using onePK.
That last part, about the agent support is actually pretty cool. We can create agents to provide support for whatever new protocols come down the pike by building them upon onePK. This allows flexibility and future-proofing while still maintaining a common underlying infrastructure for consistency and coherency.
For instance, we are delivering our experimental OF support by building it atop the onePK infrastructure. For customers this is a key point, they are not locked into a single approach—they can concurrently use native onePK access, protocol-based access, or traditional access (aka run in hybrid mode) as their needs dictate. Because we are building agents atop onePK, you don’t have to forgo any of the sophistication of the underlying infrastructure. For example, with the forthcoming agent for the ASR9K, we expect to have industry leading performance because of the level of integration between the OF agents and the underlying hardware made possible by onePK.
In closing, you can see how extensible our programmatic support is with the ability to use onePK natively or to support technologies and protocols as they are developed and released. This gives customers a remarkable level of flexibility, extensibility and risk mitigation.
As the Product Manager for Fibre Channel over Ethernet (FCoE), I often get asked some of the hard questions about how the technology works. Sometimes I get asked the easy questions. Sometimes -- like two nights ago -- I get asked if the standards for FCoE are done.
I’m not kidding.
My own expectations for discussing FCoE were focused around the topics and conversations that we’ve been seeing over the last year, since the last Cisco Live in 2011. Read More »