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: academia, Cisco, community, controller, data center, developers, Enterprise, LISP, netconf, Neutron, NFV, open source, opendaylight, OpenStack, Overlay, ovsdb, SDN, Service Provider, virtualization, yang
With the announcements on NX-OS APIs, Application Centric infrastructure APIs, python scripting support, SDN, open source projects OpenStack, OpenDaylight, and Puppet, I have opened an account at codecademy.com and will start with Python and Java. I see many late nights in my future. This stubborn old networker is finally onboard.
Read my full article for a closer look!
Tags: #ciscochampion, ACI, APIs, AVC, Cisco Developer Network, collaboration, CTI, Energywise, FlexPod, jabber, java, Nexus 9000, onePKXNC, Open Daylight, OpenStack, Puppet, python, SDN, TelePresence, UCS
As cloud-enabled services transform IT departments everywhere, your path to success as an IT professional was made easier today with Cisco’s announcement to expand its cloud portfolio. With Cisco’s comprehensive cloud portfolio offerings, you can easily and securely combine workloads to manage cloud services across different clouds. By increasing your flexibility for strategic sourcing of cloud-enabled IT services, you can increase your influence as a trusted business partner to your stakeholders. And, as you take on these new strategic roles, Cisco and our channel partners can help you and your organization gain control of cloud services.
While defining and deploying a comprehensive cloud architecture presents tremendous opportunity for IT chiefs, this task is not without its challenges. Successful cloud implementation requires a cloud governance model fueled by strategic vision and a holistic approach that addresses all aspects of your data center and IT operations in the new application economy fueled by cloud.
Tags: ACI, application centric infrastructure, Cisco, Cisco Domain Ten, Cisco Services, cloud, Cloud Consumption, Hybrid Cloud, InterCloud, OpenStack
Two weeks ago, I presented a webinar on Dynamic Fabric Automation (DFA) and went over the allocated 1 hour to cover the content. Yesterday, as I was doing follow up with a hands-on demo, I went over time too. This illustrates how rich DFA is, and how much there is to say about it! Dynamic Fabric Automation is an environment for data center automation that is centered on the CPOM (Central Point of Management), a set of services that are provided with the new Data Center Network Manager (DCNM) release 7.0(1).
The services available on the CPOM provide the following:
- Power On Auto Provisioning (POAP)
- Inter-switch link connection verification
- A single console for configuration
- Network Auto-Config Profile provisioning
- Message processing for external orchestrator
- Automatic host provisioning
- Embedded management for network monitoring and data collection
All of these services are provided using standard protocols and applications. For example, the POAP service uses DHCP, TFTP and SCP/SFTP, but using a combination of templates and a very intuitive and easy-to-use GUI, DCNM provides a simplified and systematic way of bringing up your data center fabric. The inter-switch link validation or cable consistency check allows the operator to verify the fabric connections against a predefined template and prevent unexpected connections to come up.
The Jabber process provides the single console for configuration, statistics and troubleshooting. Using any XMPP client, an operator can “chat” with the fabric devices; this approach offers the possibility to organize devices in chat groups that match their role, their location or simply some administrative set. With XMPP, a single command can be sent to multiple devices in a secure way.
The most important element of the CPOM is certainly the network profile provisioning. Read More »
Tags: #CLEUR, BGP, Cisco, Cisco Live Milan, Cloud Computing, datacenter, FabricPath, OpenStack, orchestration, VMware vCloud Director
Would SDN, by any other name, still smell as sweet?
Perhaps I’m in the minority that is still frustrated by this, but as a marketing person who is tasked with explaining technology and solutions to customers and prospects, I feel hamstrung by a lack of a widely agreed upon definition of what is and is not “SDN” still. This usually comes up in discussions about our new Application Centric Infrastructure (ACI), and how it compares to traditional SDN concepts, as well as alternative approaches, such as overlay networks advocated by VMware.
The topic came up again this with a NetworkWorld article in which the head of VMware’s network virtualization business is now saying, “SDN will never happen” (our rebuttal). Well, what is happening, if it’s not SDN? Or just because the technology has evolved, do we need to create a new term just because some early assumptions the industry made have changed? As we start out a new year, I thought it a good time to try and reframe the definition, and look at how the trends in SDN may be shaping up to extend the concept into new areas.
Why do customers need SDN?
By early 2012, there was so much hype and expectations around Software Defined Networking, focused on the ability to “program” the network, that real customer use cases and the killer SDN app was lost in the conversation. But what slowly emerged, that is driving all the investment, pilots and product designs is a much better way to manage the data center and cloud network, and to automate IT tasks so that the infrastructure could respond dynamically to rapidly changing business conditions and requirements. The “intelligence” to make all that happen is moving from the network devices and device management consoles, to centralized policy-management platforms, orchestration tools and cloud-managers.
What’s caused the biggest evolution in SDN is the realization that very few organizations really have the desire, skills and incentives to write a new class of applications to a published API to program the network. These users are outlying use cases compared to the vast majority of organizations just looking to automate IT tasks, accelerate application deployment, make their cloud networks more flexible, and better align their IT infrastructure with business requirements. The focus has shifted from SDN being an open API/controller platform, to a platform capable of hosting a myriad of orchestration and IT workflow automation solutions that drive customers to their end goal. To that end, ACI is meeting all those objectives, and in more advanced and innovative ways than earlier SDN approaches.
Read More »
Tags: ACI, Cisco ONE, Open Daylight, Open Network Environment, OpenFlow, OpenStack, SDN, software defined networking, XNC