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:

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.

12 comments:

  1. I am equally interested to know if anyone is using ONOS in their production environment ?
    Replies
    1. Frequentis uses ONOS with the NetBroker Controller on top of it and the NetBroker Probe in the Brasil ANSP. This a big nation wide safety critical network. The solution is developed according to ED-153 safety guidelines. It is in production now.
      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.
  2. "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."

    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).
    Replies
    1. Yes, intent models are the way to go. Applications shouldn't have to bother with "programming the network". Specify what you need, and let the orchestrator figure it out. However, if you're going to use intent models, use TOSCA, not YANG. YANG is just a data modeling language, whereas TOSCA is an orchestration language (which includes a full data modeling component).
    2. Thanks for your reply Chris. We obviously agree on the intent-part. The problem with TOSCA is that it can only describe cloud applications stacks. If you want to convey intent to anything that is not a cloud (i.e. a network element, a packet core, an optical network), TOSCA can't help you.

      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.
    3. http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html
  3. Not ODL specifically, but some people did manage to prove the value, if you try hard enough. :)

    http://opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf
    Replies
    1. Oh, that one. They decided to become a router manufacturer, and decided to use OpenFlow as forwarding table/TCAM programming protocol. Not exactly relevant IMHO.

      http://blog.ipspace.net/2012/05/openflow-google-brilliant-but-not.html
  4. Tried ODL in 2014 on a production network and decided to steer clear, building instead a straightforward custom controller which is still in prod (and growing), as you have in your podcast:
    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!

  5. I wouldn't say people are downloading and using ODL as it sits for much of anything. There are however a lot of vendor controllers or platforms built on top of ODL since it does have some useful components like a topology manager and SAL. Especially in the transport realm, Ciena (before the Cyan acquisition), Infinera, Coriant, and others have built products on top of ODL.
  6. Generally agree with this characterization: Infinera's Xceed controller is built on ODL with additions and is in production use, e.g. at Windstream. As of fairly recently, it was the only Transport SDN controller certified as powered by OpenDaylight, so I'm not sure the other vendors mentioned have gotten to the stage of deploying ODL-based products.
  7. AT&T already use it as the global controller as well as for many of the L1-L3 ones. Your comment in the post only refers to one of the domains. Tencent is another public user.
Add comment
Sidebar