Re: [OpenDaylight TSC] Request Creation Review for Cardinal - OpenDaylight Monitoring as a Service

Pande Gaurav <pande.gaurav@...>

Hi Jesse, Colin,

Thanks for the inputs. Please find clarifications to the queries marked with tag //**Gaurav**//. 

Thanks and Regards,
Gaurav Pande
Tata Consultancy Services

-----Jesse White <jesse@...> wrote: -----
To: Colin Dixon <colin@...>, Pande Gaurav <pande.gaurav@...>, "project-proposals@..." <project-proposals@...>
From: Jesse White <jesse@...>
Date: 04/07/2016 11:45PM
Cc: "tsc@..." <tsc@...>, Partha Datta <partha.datta@...>, Srivastava Rajani <srivastava.rajani@...>, Philip Robb <probb@...>, cgallen@..., Ed Warnicke <hagbard@...>
Subject: Re: [OpenDaylight TSC] Request Creation Review for Cardinal - OpenDaylight Monitoring as a Service


On 04/07/2016 12:17 PM, Colin Dixon wrote:
> I wanted to take this opportunity to follow up with the creation review along two threads.
> First, I'm not sure if you're aware, but the OpenNMS guys (two of which are cc'ed) have been working on integrating
> OpenNMS with OpenDaylight in a variety of ways that are very similar to what was proposed in Cardinal. It might be worth
> talking a bit about where there's commonality and seeing if there's room for collaboration.

Thanks for looping us in Colin.

From what I gather the Cardinal project is adding SNMP support to ODL, allowing the ODL controller to be monitored using
existing NMSs. Lacking SNMP support we have opted to integrate using the existing interfaces, notably JMX and RESTconf.

That said, if SNMP support (provided by Cardinal) were available we could also evaluate monitoring the ODL controller(s)
via SNMP, making OpenNMS a consumer of this service.

//**Gaurav**// That is correct. With Cardinal project (in OpenDaylight Boron) - Open-source / Vendor NMS' will be able to start monitoring OpenDaylight. Yes - the NMS will be a consumer of this service

Aside from monitoring the JVM and the state of the Karaf services, we believe there is also value in generating
autonomous events or traps for application specific faults such as "pushing this flow failed", or "this intent could not
be realized due to the current operational constraints". Is this within the scope of the Cardinal project?

//**Gaurav**// Agreed. As part of the Cardinal plan, in ODL-Boron release OpenDaylight System Info, Karaf / MD-SAL parameters pertaining to feature/plugin status/scalability will be provided. In the ODL-Carbon release (as discussing during TSC review) the network parameters will be looked into. 

//**Gaurav**// However, we will surely look into the above application specific faults and evaluate if the same can be incorporated into our ODL-Boron release plan
> Second, Ed (cc'ed) and I talked about the OpenDaylight deployment model and how requiring an external daemon might
> complicate things. In essence, we've found the most successful OpenDaylight projects provide some out-of-the-box
> features by just downloading the Karaf distribution, unzipping it and running it. If you also require that people
> download and install snmpd and snmptrapd, it decreases the number of people who will download it and try it out.

I thought it may be worth mentioning that snmp4j can also be used to setup an agent and sends traps, allowing this
functionality to be embedded in the JVM instead of relying external services. Perhaps this could be used as the default
implementation instead of registering as a snmpd sub-agent?

//**Gaurav**// Agreed. Based on the inputs received during TSC review, we were also investigating on usage of a native library (instead of the likes of Net-SNMP)

//**Gaurav**//  As part of investigation, our view on a OpenDaylight MIB (as part of Cardinal project is as follows):

1) Enterprise MIB:
  • Using a new enterprise mib requires to register the enterprise mib oid at IANA
  • Project cardinal requires to compile and parse the Enterprise MIB, so that the mib values can be accessed via java code
  • To compile a mib we have looked into snmp4j.smi ( library but in order to compile an enterprise mib one needs to purchase the full license of the snmp4j.smi library (

2) Experimental MIB:
  • For OpenDaylight-Boron, we will be using experimental MIB as part of the Cardinal project
  • Has being compiled and parsed successfully using the snmp4j.smi  library

Within OpenNMS, are there any open-source MIB compilers being used ? We looked into "mib2opennms" - but per our understanding is only to extract all the NOTIFICATION-TYPEs in OpenNMS eventconf.xml format.


Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

Join { to automatically receive all group messages.