SDN: The Daylight Project

Author
Peter Welcher
Architect, Operations Technical Advisor

Thanks to the person who asked me about the Daylight Project via a blog comment. I’ve been researching the rumors online. The purpose of this blog is to summarize the consistent (leaked?) themes, particularly for those who haven’t been watching SDN closely. And sneak in some thoughts of my own. I’m writing this while in San Jose, where you never know, one or more of the Network Field Day 5 vendors might drop some hints. If I write about Daylight beforehand, we can all be assured that I won’t run into any NDA issues. Nothing but the best rumors here!

I should note that fellow NFD5 attendee Brent Salisbury blogged about Daylight back when it was breaking news. See http://networkstatic.net/more-vendors-define-their-sdn-strategy/.

Per the first two reference links below, Daylight is a SDN group with Cisco, IBM, HP, Citrix, NEC, and BigSwitch as members. The group is producing open source software, following the Apache and OpenStack models. The code will be an OpenFlow capable controller with Citrix service chaining code and HP code for L2 services. It will have high availability and clustering capabilities.

Public announcement is expected in April at the Open Network Exchange conference.

Per the Network World article below, Juniper commented in general reflecting its own SDN approach, and would not indicate whether it was joining the Daylight group. If I’d just spent a lot of money on my own solution and gearing up to market it, I too might not want to comment.

I enjoyed the commentary in the SDNcentral link listed below. “This should reduce the number of SDN platforms / controllers you may have to write to.” Definitely. Good thing, too.

To this observer, right now the whole SDN and OpenFlow arena seems characterized by way too many VC-funded startups. Might we call this a “VC bloom”, by analogy with the algae blooms you get when there is too much nutrient in a pond? I’d much prefer to see innovation around a common core than a lot of underfunded and/or struggling efforts, each with their own unique value and twist but lacking the power of full core functionality.

I used to wonder about all the forks in Linux code producing different variants. Was it really wise to split the people and coding energy across so many variants? I recall the joys of trying to get a package from X that allegedly supported variant Y but was built on Z to actually compile and run properly. Colossal waste of my time. (And rarely had the time to actually get stubborn network management packages to work.) Linux has at least converged to a few big players now. It is far too early days for such convergence in the SDN world.

The SDNcentral link goes on to say that one purpose of Daylight is to provide a VMware / Nicira alternative. That may be. In my SDN reading, I’ve been getting the feeling that various vendors have been trying to take SDN in a direction that matches their world view, or at least their business plan. That doesn’t necessarily produce a lot of commonality in terms of direction.

The simplistic version of that might be that hardware vendors want to … control hardware, VMware wants to control virtual machines and networks, and cloud vendors might want SDN to move you smoothly into their cloud (but not out or to a competitor). If you think about it, SDN might even be programming say Intel chips doing switching or other OpenFlow functions in hypervisor host NICs, rather than physically standalone OpenFlow switches.

One impression is that Cisco seems to be very interested in the hybrid cloud, perhaps because then they can sell you or your cloud vendor hardware. The flexibility of mixing private and public cloud then might be an incentive to use … Cisco hardware?

Per recent blogs about VMware’s antagonism to the cloud providers, is it likely that their tools will provide cross-hypervisor cloud support? Or is this a case of any cloud as long as it uses VMware?

Perhaps we could hope that the hardware vendors might take Daylight in a more agnostic direction, one where the controller supports provisioning vendor-specific hardware, OpenFlow or other platforms, and cloud platforms and whatever else evolves as well? Open source would be a good first step in that direction!

Optimistically, this gives up most if not all single vendor lock-in and provides a shared playing field for the vendors to compete with innovation. And yes, that’s arguably quite a bit better for the customer.

I’m not sure I buy into the idea some OpenFlow people have of generic hardware at low cost. With an open source controller and modular code, we can at least hope that Daylight might support migrating between vendors, to whichever one you choose in the future as meeting your performance / cost goals. I hope to have more to say on this aspect of SDN in another blog.

Links about Daylight

http://www.sdncentral.com/companies/spotlight-on-daylight-sdn-consortium-open-source-controller/2013/02/

http://searchnetworking.techtarget.com/news/2240178127/Networking-blog-roundup-Cisco-SDN-controller-and-a-new-SDN-consortium

http://www.networkworld.com/community/blog/sdn-meet-sheds-little-light-cisco-daylight


Disclosure

The vendors for NFD 5 are paying my travel expenses and perhaps providing small gift items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds. I’d like to think that my blogs aren’t influenced by that. Yes, the time spent in presentations and discussion gets me and the other attendees looking at and thinking about the various vendors’ products, marketing spin, and their points of view. I intend to try to remain as objective as possible in my blogs. I’ll concede that cool technology gets my attention! Stay tuned!

Twitter: @pjwelcher

2 responses to “SDN: The Daylight Project

  1. (Disclaimer: I work for VMware/Nicira.)

    Hi Pete, thanks for taking the time to share your views on the oft-rumored Daylight project and its potential effects on SDN. I did want to very briefly comment on your statement regarding VMware’s cross-hypervisor support. While it’s true that VMware’s server virtualization and associated products have been rather hypervisor-specific (although we are starting to see changes there), VMware’s network virtualization product–which came from the Nicira acquisition–is highly hypervisor-agnostic. Nicira was also pivotal in the development of Open vSwitch, which is also highly hypervisor-agnostic (works equally well with Xen or KVM). With regard to network virtualization, this is a trend that you won’t see changing.

    Thanks!

  2. Great! Thanks for setting me straight. I think you’re saying it’s a coop-etition (cooperate / compete) situation, as stuff around evolving . (Compete and cooperate.) That subtlety escaped me when typing the blog.

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.