Cisco Blogs


Cisco Blog > SP360: Service Provider

Making Programmable Networks Easier to Achieve (and for Free!)

making programmable networks easier to achieveThe “P” in EPN stands for “Programmable,” as in “Evolved Programmable Network” and Cisco has just made the “P” easier to achieve to help drive services to the cloud. We’ve now contributed Basic ConfD, a free version of our powerful ConfD by Tail-f management agent software to the networking industry. Tail-f joined Cisco last summer and this announcement demonstrates Cisco’s commitment to not only embrace but also drive open standards in the best interest of the entire ecosystem. Read More »

Tags: , , , , , ,

“Standing Room Only” in the Service Provider Booth at Cisco Live Milan 2015

Written by Igor Dayen, SP Product and Solutions MarketingIgor Photo

If you had a chance to join us at Cisco Live Milan last month, thank you very much for making this another exciting event for all of us. If you missed out being there in person, let me give you a brief summary of the highlights. Milan is the main industrial, commercial, and financial center of Italy and a leading global city where the EXPO 2015  will take place. What could be better than such a city to host the Cisco Live 2015 event!   It proved to be fertile grounds for driving innovations with our service provider customers and partners.   Our exhibition was structured to tell the story of the fddOpen Network Strategy by presenting over 15 technology and business demos.    We also brought the newest routers and switches with us to showcase the latest innovations that service providers can start deploying today.   Last but not least we have teamed up with the DevNet area where attendees could get their hands on developing applications and learning on virtualization, orchestration, and automation.  Our service provider booth of the Cisco Campus in the World of Solutions was very busy: “standing room only” and so many insightful conversations were conversations around the NFV (Network Functions Virtualization) and the SDN (Software Defined Networks), as pillars for delivering cloud services and an automated networking handling respectively, have matured significantly and are ready for prime time. Read More »

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

The Napkin Dialogues: Nexus Programmability, Part I

I know that I take a different approach to learning new things than most people. At least, I know my approach is different than the way people present them. The good news is that when I get something, I really get it. However, when looking at the juggernaut that is “Software-Defined X,” or even “programmability,” I know that I’m still a long, long way away from feeling like I have a handle on it.

When I wrote the previous blog post on some of the key “Open” terms were in programmability, I was overjoyed to find out that there were a few people who also had difficulty getting a grip on this too.

In other words, I’m not alone!

There is still a bewildering amount of information that I still need to learn, however, and it seems to me that if I resonated with a few people about these high-level topics, there are probably a few more who are curious about what lies beneath as well. Fortunately I work for a company (and with a lot of people) who have been willing to help me. Read More »

Tags: , , , , ,

OpenDaylight Unleashes Hydrogen to the Masses

The OpenDaylight Project today announced that its first open source software release Hydrogen is now available for download. As the first simultaneous code release cross-community it has contributions across fifty organizations and includes over one million lines of code. Yes. ODL > 1MLOC. For those of you interested that’s approximately two hundred and thirty man-years of work completed in less than twelve months.

It was around this time last year that the media started to pick up on a few rumors that something may be in the works with software-defined networking and controllers. I remember our first meeting at Citrix where the community started to collaborate on The OpenDaylight Project and come to common ground on how to start something this large. We had multiple companies and academics in the room and many ideas of where we wanted this project to go but there was one thing we had in common: the belief and vision to drive networking software innovation to the Internet in a new way and accelerate SDN in the open; transparently and with diverse community support. Each of us had notions of what we could bring to the table, from controller offerings to virtualization solutions, SDN protocol plugins and apps to solve IT problems. Over two days at Citrix we looked at things from a customer perspective, a developer perspective and ultimately and arguably the most important, a community perspective. From there The OpenDaylight Project emerged under the Linux Foundation. As I look back I want to applaud and thank the companies, partners, developers, community members and the Linux Foundation for driving such a large vision from concept to reality in less than twelve months, which is an incredible feat in itself.

Hydrogen is truly a community release. Use cases span across enterprise, service provider, academia, data center, transport and NfV. There are multiple southbound protocols abstracted to a common northbound API for cross-vendor integration and interoperability and three editions have been created to ensure multi-domain support and application delivery as well as deployment modularity and flexibility for different domain-specific configurations. These packages have a consistent environment yet are tailored to domain and role-based needs of network engineers, developers and operators.

  • The Base Edition, which includes a scalable and multi-vendor SDN protocol based on OSGi, the latest (and backward compatible) OpenFlow 1.3 Plugin and Protocol Library, OVSDB, NetConf/Yang model driver SDN and Java-based YANG tooling for model-driven development.
  • The Virtualization Edition (which includes the Base Edition) and adds Affinity Metadata Service (essentially APIs to express workload relationships and service levels), Defense4All (DDoS detection & mitigation), Open DOVE, VTN, OpenStack Neutron NorthBound API support and a virtual tenant network offering.
  • The Service Provider Edition (again, including the Base Edition) that also offers the Metadata Services and Defense4All but includes BGP-LS and PCEP, LISP Flow Mapping and SNMP4SDN to manage routers, gateways switches.

More information can be found on the website with regards to the releases and projects themselves.

I want to stress the importance of how well the vision has been delivered to date. I’ve been involved in multiple standards-bodies and in open source discussions in the past but this is truly one of the largest undertakings I’ve seen come together in my entire career. OpenDaylight developers have been coding day and night to get this release out the door and it’s amazing to see the collaboration and coherency of the team as we unite to deliver on the industry’s first cross-vendor SDN and NfV Platform. In addition and frequently not mentioned is that many of the protocols listed in the Editions above are also standardized at organizations like the IETF during the same period. Code and specs at the same time. It’s been a long time since rough consensus and running code has been the norm.

Over here at Cisco we’re fully committed to OpenDaylight. We’re currently using it as a core component in our WAN Orchestration offering for service providers to allow intelligent network placement and automated capacity and workload planning. The ACI team (formerly Insieme) collaborated with IBM, Midokura and Plexxi to create a project in OpenDaylight that creates a northbound API that can set policy and be used across a wide range of network devices. And of course we’re bringing components of the OpenDaylight codebase into our own controllers and ensuring application portability for customers, partners and developers alike. From this I would expect to see more code donations going into the community moving forward as well. We made several announcements last week about our campus/branch controller that includes OpenDaylight technology.

At the end of the day an open source project is only as strong as its developers, its community and its code. As we as a community move forward with OpenDaylight I expect it to become stronger with more members joining with new project proposals as new code contributors coming onboard from different industries as well. As I look at our roadmap and upcoming release schedule I’m pumped for what’s next and so happy the community has catalyzed a developer community around networking.

Please do visit the site, download the code and take Hydrogen for a test-drive. We want to hear feedback on what we can make better, what features to add or how you’re going to utilize it. Moreover, we’d love you to participate. It’s a kick-ass community and I think you’ll have fun and the best part; you’ll see your hard work unleashed on the Internet and across multiple communities too.

Tags: , , , , , , , , , , , , , , , , , , ,

Cisco onePK Plays Well With Others

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.

Tags: , , , , , ,