There are multiple solutions that vendors are providing for SDN today, but there are also multiple needs in the market for these solutions. With onePK, we are looking to consistently and proactively allow for users to now access their OS in easier ways than before – so you no longer have 3 operating systems, but actually an abstraction layer that allows for you to harness the power of all 3 via the interface. This interface, while currently in Java and C, will also be RESTful (soon) and we are looking at other languages as well (Python is one, and we’d like your feedback on that).

SDN means many things to many people. What it comes down to is the problem folks are trying to solve. onePK is just one aspect of Cisco’s solution (see http://www.cisco.com/go/one for more info) but we have more coming down the pipeline soon. Dave Ward & I will be following up with a podcast in the next month with more details on this – and we’d love to hear what you’d like us to talk about. At the end of the day our job is to build what you, our customers and users, need – and your feedback is essential to that, so please do engage!

You can reach me directly at my address below or my twitter account – and look forward to more dialogue!

Lauren Cooney
Sr. Director, Software Market & Developer Strategy
NOSTG, Cisco Systems
lauren.cooney@cisco.com
http://www.twitter.com/lcooney

   0 likes

Thanks,
Kevin Woods
Director, Product Management, NOSTG

   0 likes

There is a big difference between SDK’s and API’s and so far Cisco interchangeably uses both terms which is disingenuous. Dictating languages like Java and C is another problem. Plus the SDK route means new languages mean additional development time and maintenance cycles for Cisco. What we really need is a proper RESTful API that doesn’t require another layer of language dictated SDK.

Again I understand you can’t bolt API’s onto something like IOS, but I wonder if some players will move to a network operating system that was built from day one to provide a proper API that I can interact with with any language I choose.

   0 likes

Thanks for the interest. Its a closed beta right now, but ping me at osultan at cisco dot com and we can chat some more.

Regards,

Omar

   0 likes

Is there a way to get access to Cisco’s proof-of-concept openflow controller and agent? Secondly, which hardware is supported?

Thanks,
AJ

   0 likes

You are correct–we can build an OpenFlow agent for a given switch using onePK. One benefit of this approach is that it can take full advantage of the capabilities of the underlying hardware.

Thanks for helping to clarify.

Regards,

Omar

   0 likes

Check out this post – onePK Plays Well With Others – http://blogs.cisco.com/datacenter/cisco-onepk-plays-well-with-others/
and see if it answers your question–if not post another comment and let me know.

Regards,

Omar

PS – As part o the formal release of onePK, we will have all sorts of tutorials, sample code etc to help bring folks up to speed

   0 likes

   0 likes

Now, I know SDN means different things to different people and vendors. But one widely accepted definition is the separation of CP and DP via a Controller-led network with northbound APIs between the user/applications and the Controller (to my knowledge, none have been defined yet) and southbound APIs between the Controller and the switches (e.g. OpenFlow and NETCONF).

What I’m looking for from Cisco is a tutorial on the following: Using the definition of SDN above, where does onePK sit and what value does it bring? Thanks.

   0 likes

Thanks for reading. I can certainly understand your perspective. Many folks expect us to be defensive about SDN and certainly some of our competitors would like to believe we are too doddering to do anything about it. Simply not true.

So, is onePK proprietary–only to the degree it is designed to work only with Cisco gear–but that is the nature of an SDK on the southbound side–Juniper’s SDK only works with their stuff and even at a lower-level, Broadcom and Intel/Fulcrum SDKs only work with their respective silicon. BTW this is not necessarily a bad thing–it allows the SDK to tap the full capabilities of the hardware as you will see later on. Anyway, the most of the action is happening on the northbound side. There, things are anything but proprietary. onePK exposes an immense amount of information–onePK is the exact same development environment (no secret squirrel APIs) our own engineers use to create features for our operating systems, so you that should give you an idea of how powerful the develop tools are–you are getting the keys to the kingdom–perhaps this also answers Umair’s question a bit too.

Anyway, with this SDK on the northbound side you can do some interesting things. You can directly access the hardware via onePK–currently with C and JAVA, other languages coming soon. However, we will also release agents that allow you to access the hardware via other mechanisms–for example, this summer we demoed an OpenFlow agent–down the the road, as other protocols emerge (IRS, PCE, etc) we can quickly and easily stand up agents to support those technologies.

So when we do these podcasts, I ask everyone to keep things conversational–the kind of chat you would have over a beer. The reasons is these are complex topics and I want to keep them accessible to folks–we are trying to be educational, not demonstrate how smart we are. That being said, its important to recognize that David is currently the chair of the Technical Advisory Board at ONF (check out this post for a snapshot of all the folks we have contributing to ONF efforts http://blogs.cisco.com/datacenter/what-comes-next-with-cisco-and-the-onf/) and he is also the CTO for the SP engineering teams so things he is talking about on the podcast are the things he is advocating in the standards bodies (i,e, IRS) and building for Cisco.

Regards,

Omar

   1 like