Is Anyone Using Open Daylight?
A while ago I sent out an email to my SDN and network automation mailing list (join here) asking whether anyone uses Open Daylight in anything close to a production environment (because I haven’t ever seen one).
Among many responses saying “not here” I got a polite email from VP of Marketing working for a company that sells OpenDaylight-related services listing tons of customer deployments (no surprise there). As I started investigating some of them, it turned out quite a few use cases were along the lines of “we tried it, and it sort-of-worked, and these are the missing parts…” or “this is the proof-of-concept we did”. Better than “this works so well in PowerPoint” but totally missing my question.
There were a few real deals in that listing:
- Avaya is using ODL in one of their products (I wonder whether that one will survive the Extreme acquisition);
- Telstra is using ODL to program a WAN network.
Also, AT&T is talking about replacing Contrail with ODL in their OpenStack deployments (yeah, that what’s the kind of information you get from VP of Marketing when you ask about production OpenDaylight deployments). Anyway, I wish them luck.
I also got another email from VP of Product Management working for a startup:
You are right in your assessment that ODL is mostly restricted to academic discussions. We started our startup by writing fancy ODL applications, which found good adoption with some Tier-1 customers that were planning to roll out ODL networks with white-label OpenFlow switches.
We wrote fancy path computing algorithms, with extensive APIs to integrate this with business applications. But none of them saw the light of the day. Almost all the customers who had initial plans never went ahead with production deployment. AFAIK, reasons mostly were like changed business interests, lack of solid support for ODL for the community edition, fear of lock-in with vendor based ODLs (like Cisco, Brocade, Ericssson etc, all of who had their own flavor of ODL).
For our startup, we subsequently moved away from ODL (or for that matter, any controller based apps), to realizing SDN-like orchestration systems for legacy networks, using model-driven mediation platform, which is finding good traction.
Have I missed any other production-grade ODL deployment? Please write a comment.
However, we use only a subset of the ONOS core functionality. New versions of NetBroker might use more functions in the future from the ONOS core.
Its not only startups moving away from ODL to model-driven mediation platforms. Its large companies as well...
OpenFlow and ODL were interesting technology for the lab, but it didn't solve any real world problem (Ok, we could rip the CPU from the forwarding system, but thats not really the cost). Conveying the intent to and from a platform through an abstracted interface (hello, YANG!) does make sense. It gives you flexibility with regard to the platforms you deploy (reducing vendor lock-in) and enables you to open your service platform in a controlled manner to the rest of the organisation through APIs (increasing service velocity).
So it depends where you come from and what the abstraction level is where you want to play. If you can manage with the models standardised by OASIS, then TOSCA is the way to go. But if you need to adapt and extend the models themselves to fit your business, YANG might be a better fit.
http://opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf
http://blog.ipspace.net/2012/05/openflow-google-brilliant-but-not.html
http://blog.ipspace.net/2016/06/build-your-own-service-provider-gear-on.html
:)
Remember that early "misunderstanding" of SDN: let's reimplement centrally every single edge networking protocol! Yay! What could possibly go wrong? And let's have microflows (e.g., matching l2 src and dst pairs) everywhere, it sounds like a great idea! This monumental piece of java should handle it well, I'm sure!