To learn more about the OpenDaylight Project and Helium, read the Q&A below, catch the full presentation.
How does OpenDaylight relate to ONOS?
OpenDaylight: ONOS and ODL are two separate efforts. ONOS is being driven out of Stanford and is focused on service providers taking a very specific focused approach, mainly around OpenFlow. ODL is focused on overcoming fragmentation in the SDN industry and is a broad community bringing together major players in theSDN industry creating a platform for all types of hardware, protocols, and approaches.
Any new modules related to firewalls? IDS? Or security services?
ODL: In OpenDaylight Helium, we added support for Neutron security groups. The Defense4All project provides anti-DDoS support. We would love to see people come forward and help us provide more features including IDS support and/or support for Neutron’s Firewall as a Service (FWaaS) APIs.
What hardware switch vendors are proven to work with ODL?
ODL: Any hardware that uses a supported southbound API should work with ODL (e.g., OpenFlow, BGP, OVSDB,NETCONF). If you find something that works differently than you expect, please let us know via the mailing lists and we’ll work to fix it.
Is OpenDaylight implemented completely in Java?
How do you select the candidate project to integrate OpenDaylight with? i.e. OpenStack (Neutron)?
ODL: We do this mostly based on interest from both inside ODL and the other project. In the case of OpenStack, this interest was there in droves. If you have a project in mind, please come and talk to us.
Does ODL supports PCEP protocol?
ODL: Yes. See this project.
Apache has a clustering project within Felix/Karaf — Why not use that?
ODL: We looked at using other clustering projects and decided that Akka provided the best cluster management solutions around for the JVM and that we really needed to build our own to support the particular data store needs we had.
How do you implement distributed ODL Controllers?
ODL: We currently support a clustered implementation with the underlying part being based on an Akka implementation of the RAFT consensus algorithm.
What is the release periodicity, for maintenance and main releases?
ODL: Right now main releases are every ~6 months and maintenance updates every ~6 weeks with two updates per major release.
Unified Models. What are your modeling tools? Eclipse Modeling Frameworks is the state of the art for MDE. Is EMF being considered?
ODL: Our unified models are based on the YANG modeling language.
How would ODL integrate with a hybrid environment that has hardwired routers and virtual routers?
ODL: As long as the virtual or physical devices speak a supported protocol, it will work just fine and be able to communicate with them.
Will the presentation cover scenarios?
ODL: Today, I don’t think we have specific content on that. Typical scenarios include network virtualization, building custom L2 fabrics, better visibility and monitoring, and just to control devices via supported protocols, e.g., OpenFlow, OVSDB, NETCONF.
The SNMP solutions for OpenDaylight — Can these be used as a generic SNMP manager for managing traditional net and sys equipment with public and private MIBS?
ODL: The SNMP support that exists is mostly targeted at recreating L2 forwarding control like a “poor man’s”OpenFlow, however there is library support that could likely be adapted to what you mention. We’d love help getting there.
Do you have tutorials on building distributed ODL Controllers? What datastore does ODL use? Or how to communicate from one ODL Controller to other Controllers (East/West API)?
Is there a deeper dive or demo planned in this same format anytime soon?
ODL: We host ODL user group meetups around the globe where you could get a deeper dive, and we’re also talking about more intensive training. Some folks like Brocade and Inocybe have introduced deeper dive trainings too and the project is working on that. The developer wiki has a bunch of tutorials and demos if you haven’t been there yet.
Have you looked at the OSGi compendium standards to see the various services that may complement network management? Particularly Configuration Admin?
ODL: Not to my knowledge, but thanks for the pointer. We’ll look into it.
Nonetheless, “Academia” is the only environment that may stand a fair chance to analyze things fairly, more or less. Also, it may bring in some “foundation” and, hopefully, help weed-out the dead-ends… Is there any major involvement with universities and major research facilities?
ODL: I absolutely agree. I’ve seen a lot of universities pick OpenDaylight up and use it (and even contribute), despite not having a formal program for doing so. For example, I know that there are cool demos from Internet2 folks using ODL to control WiFi deployments and Marist College is doing stuff. If you’d like to get more involved, reach out.
How would ODL support a multi-layer controller architecture for current deployment scenarios e.g., a hub and spoke architecture (CO, metro-pop, mega DC, etc.)?
ODL: I think that this is something we could support, but it would probably involve some effort in composing the features that are already there. We’d love to see somebody show up and work with us to attack problems like this.
What is the status of OpFlex in OpenDaylight?
How is OpenDaylight different from OpenContrail?
ODL: They are both open source SDN Controllers. OpenDaylight is backed by a multi-vendor consortium.
What about the licensing terms of OpenDaylight in very simple terms?
ODL: It’s published under the Eclipse Public License, which is a “weak copyleft” license.
Does ODL orchestrate (connect together) virtual network functions (VNF) based on intent or is that managed by OpenStack integration to ODL?
Does ODL provide a standard northbound API and how critical are standard northbound APIs for the success of SDN?
ODL: That’s a really complex question. We provide northbound APIs and strive to have compatibility from version to version, but APIs do change over time. Eventually, I think that you’ll find that there will be core APIs that move less over time and become de facto standards. We might even really standardize them later.
How scalable is OpenDaylight? Say if we have around 1000 switches in a data center, then can we rely on this? I see that the performance numbers given in the OpenDaylight wiki is for 64 switches.
ODL: Scalability is something we care about and we’re testing/improving. We have good data for controlling a few hundred switches with the goal of targeting thousands in the near future.