[OpenDaylight TSC] New Project Proposal - SNMP Plugin
|
Jan Medved (jmedved) <jmedved@...>
+1 on using/implementing RFC6643. That would be the best way to handle SNMP and abstract MIBs to all apps using the MD-SAL infra.
Thanks,
Jan
From: Robert Varga <nite@...>
Date: Wednesday, December 10, 2014 at 2:51 AM To: "Dean, Steve" <sdean@...>, "project-proposals@..." <project-proposals@...> Cc: "tsc@..." <tsc@...> Subject: Re: [OpenDaylight TSC] [Project-proposals] New Project Proposal - SNMP Plugin
|
|
|
|
Raza, Sarwar S. (HP Networking - ATG) <sarwar.s.raza@...>
This would certainly takes the ‘S’ out of SNMP…. I see the value in the architectural clean-ness: but we should check with project originators if the intent is to have SNMP be a first class southbound protocol that allows every table and object to be addressable (I can see the case for it) vs. needing the ability to selective poll a sysOid or counter to accomplish a very specific and narrow task. \Sarwar Sarwar Raza Director, Cloud Networking & SDN Advanced Technology Group - HP Networking Hewlett-Packard, Littleton MA +1 (978)-760-3701 (mobile)
From: tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Jan Medved (jmedved)
Sent: Wednesday, December 10, 2014 12:00 PM To: Robert Varga; Dean, Steve; project-proposals@... Cc: tsc@... Subject: Re: [OpenDaylight TSC] [Project-proposals] New Project Proposal - SNMP Plugin
+1 on using/implementing RFC6643. That would be the best way to handle SNMP and abstract MIBs to all apps using the MD-SAL infra.
Thanks, Jan
From: Robert Varga <nite@...>
|
|
|
|
Dean, Steve <sdean@...>
I took a quick look at RFC 6643 and don’t fully understand how it works. The RFC appears to define how to translate SNMP MIBs into Yang models. I don’t see where the RFC defines how you actually interact with an SNMP agent to get or set SNMP MIB objects.
The DIDM (Device Identification and Driver Management) project needs to fetch (get) the SNMP sysObjectId from the device so that we can determine the type of device. I can also envision drivers (applications) that use SNMP to configure VLANs and VxLANs. These functions can be done using a simple SNMP Southbound Plugin that can be developed fairly quickly using an open source SNMP library (eg, snmp4j).
I’m working on the DIDM project which has the need to get the SNSMP sysObjectId from a device. We have two options regarding SNMP. The DIDM project could use an SNMP library for its private use and not make it available to other applications. The other option is to split the DIDM project into two project, DIDM project and SNMP project. The SNMP project would develop an SNMP Plugin that can be used by all applications to interact with devices using SNMP.
RFC 6643 may be a good long term solution and may fit well with a model driven architecture. However, this comes down to engineering resources. If other community members want to work on an RFC 6643 base approach, that would be fine. I was looking for a quick and cheap way for applications to perform basic SNMP operations with devices that support an SNMP agent.
Thanks, Steve
From: Raza, Sarwar S. (HP Networking - ATG)
Sent: Wednesday, December 10, 2014 10:07 AM To: Jan Medved (jmedved); Robert Varga; Dean, Steve; project-proposals@... Cc: tsc@... Subject: RE: [OpenDaylight TSC] [Project-proposals] New Project Proposal - SNMP Plugin
This would certainly takes the ‘S’ out of SNMP…. I see the value in the architectural clean-ness: but we should check with project originators if the intent is to have SNMP be a first class southbound protocol that allows every table and object to be addressable (I can see the case for it) vs. needing the ability to selective poll a sysOid or counter to accomplish a very specific and narrow task. \Sarwar Sarwar Raza Director, Cloud Networking & SDN Advanced Technology Group - HP Networking Hewlett-Packard, Littleton MA +1 (978)-760-3701 (mobile)
From:
tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Jan Medved (jmedved)
+1 on using/implementing RFC6643. That would be the best way to handle SNMP and abstract MIBs to all apps using the MD-SAL infra.
Thanks, Jan
From: Robert Varga <nite@...>
|
|
|
|
Kent Watsen <kwatsen@...>
Once a MIB is translated to a YANG module per RFC 6643, the expectation is that a NETCONF server would advertise support for said YANG modules and subsequent interactions would proceed via NETCONF. It sounds like you might want something a bit different,
to use 6643 to generate YANG to feed MD-SAL to generate RESTCONF API, but still use SNMP protocol southbound. If this is indeed the case, I think that you may be able to ignore the warning in http://tools.ietf.org/html/rfc6643#section-11 regarding
read-write/read-create SMIv2 objects being mapped to read-only (config false) YANG objects, since the underlying protocol would actually then still be SNMP.
Thanks,
Kent
From: <Dean>, Steve <sdean@...>
Date: Wednesday, December 10, 2014 at 2:40 PM To: "Raza, Sarwar S. (HP Networking - ATG)" <sarwar.s.raza@...>, "Jan Medved (jmedved)" <jmedved@...>, Robert Varga <nite@...>, "project-proposals@..." <project-proposals@...> Cc: "tsc@..." <tsc@...> Subject: Re: [Project-proposals] [OpenDaylight TSC] New Project Proposal - SNMP Plugin I took a quick look at RFC 6643 and don’t fully understand how it works. The RFC appears to define how to translate SNMP MIBs into Yang models. I don’t see where the RFC defines how you actually interact with an SNMP agent to get or set SNMP MIB objects.
The DIDM (Device Identification and Driver Management) project needs to fetch (get) the SNMP sysObjectId from the device so that we can determine the type of device. I can also envision drivers (applications) that use SNMP to configure VLANs and VxLANs. These functions can be done using a simple SNMP Southbound Plugin that can be developed fairly quickly using an open source SNMP library (eg, snmp4j).
I’m working on the DIDM project which has the need to get the SNSMP sysObjectId from a device. We have two options regarding SNMP. The DIDM project could use an SNMP library for its private use and not make it available to other applications. The other option is to split the DIDM project into two project, DIDM project and SNMP project. The SNMP project would develop an SNMP Plugin that can be used by all applications to interact with devices using SNMP.
RFC 6643 may be a good long term solution and may fit well with a model driven architecture. However, this comes down to engineering resources. If other community members want to work on an RFC 6643 base approach, that would be fine. I was looking for a quick and cheap way for applications to perform basic SNMP operations with devices that support an SNMP agent.
Thanks, Steve
From: Raza, Sarwar S. (HP Networking - ATG)
Sent: Wednesday, December 10, 2014 10:07 AM To: Jan Medved (jmedved); Robert Varga; Dean, Steve; project-proposals@... Cc: tsc@... Subject: RE: [OpenDaylight TSC] [Project-proposals] New Project Proposal - SNMP Plugin
This would certainly takes the ‘S’ out of SNMP…. I see the value in the architectural clean-ness: but we should check with project originators if the intent is to have SNMP be a first class southbound protocol that allows every table and object to be addressable (I can see the case for it) vs. needing the ability to selective poll a sysOid or counter to accomplish a very specific and narrow task. \Sarwar Sarwar Raza Director, Cloud Networking & SDN Advanced Technology Group - HP Networking Hewlett-Packard, Littleton MA +1 (978)-760-3701 (mobile)
From:tsc-bounces@... [mailto:tsc-bounces@...]
On Behalf Of Jan Medved (jmedved)
+1 on using/implementing RFC6643. That would be the best way to handle SNMP and abstract MIBs to all apps using the MD-SAL infra.
Thanks, Jan
From: Robert Varga <nite@...>
|
|
|
|
Robert Varga
Exactly. The SNMP integration would
then work by formatting native MD-SAL data (which conforms to the
MIB) into SNMP PDUs.
From resource/engineering perspective, yes this is a larger chunk of work. Its benefit is the fact that SNMP devices will become almost first-class citizens. If we do not cover this in either snmp4sdn or the this plugin work, I think we can turn this into an intern project. Bye, Robert On 12/10/2014 10:26 PM, Kent Watsen wrote:
|
|
|
|
Dean, Steve <sdean@...>
I need some education here. I have some questions to help me understand how this will work. 1) It appears that RFC 6643 defines how to translate an SNMP MIB definition into a Yang model. I assume the yang model defines how SNMP MIB data will be store in the MD_SAL data store. Is this correct?
2) If I want to set an SNMP MIB object in a device, I assume I write the value to the data store as defined by the yang model that represents the SNMP MIB object I want to set. Is this correct?
3) If I set an SNMP MIB object by writing the value to the data store, I assume this will notify a data change listener who will use an SNMP library to send an SNMP SetRequest message to the device. Is this correct?
4) How do I fetch (get) an SNMP MIB object from a device? Is there an RPC that I would call? I assume the code that implements the RPC would then have to call the SNMP library to send a GetRequest message to the device.
5) Does this approach attempt to keep all MIB data for all device in the MD-SAL data store? This seems like it would be a lot of data. How do we keep it accurate and up-to-date (ie, synchronized)? This seems like a lot of overhead to get the data and keep it up-to-date.
6) Are there tools that translate from an SNMP MIB definition to a Yang model as defined in RFC6643, or does this translation have to be done by hand? Sorry for all the question, but I want to understand how this will work.
Thanks Steve
From: Robert Varga [mailto:nite@...]
Sent: Thursday, December 11, 2014 1:22 AM To: Kent Watsen; Dean, Steve; Raza, Sarwar S. (HP Networking - ATG); Jan Medved (jmedved); project-proposals@... Cc: tsc@... Subject: Re: [Project-proposals] [OpenDaylight TSC] New Project Proposal - SNMP Plugin
Exactly. The SNMP integration would then work by formatting native MD-SAL data (which conforms to the MIB) into SNMP PDUs.
|
|
|
|
Tony Tkacik
Hi,
few observations / ideas how to utilize MD-SAL concepts for making SNMP first class citizen of Opendaylight. 1) It appears that RFC 6643 defines how to translate an SNMP MIB definition into a Yang model. I assume > the yang model defines how SNMP MIB data will be store in the MD_SAL data store. Is this correct?It also could be done as pass-thru mountpoint (which I would suggest, e.g. this is also used for Netconf Connector) - that means no data are kept in MD-SAL data store, but retrieved from remote device when someone is trying to read them. 2) If I want to set an SNMP MIB object in a device, I assume I write the value to the data storeYes, from user perspective it is write to MD-SAL datastore. Implementation wise it could be pass-thru mount point, which will write data directly to device, so there is no need to kept them in one of MD-SAL datastores. 3) If I set an SNMP MIB object by writing the value to the data store, I assume this will notify a dataIf you go with pass-thru mount point approach you will not get data change event, but rather callback what client want to set and based on your plugin logic you will only need to translate that and dispatch SNMP request to device. 4) How do I fetch (get) an SNMP MIB object from a device? Is there an RPC that I would call?You are correct. 5) Does this approach attempt to keep all MIB data for all device in the MD-SAL data store?Pass-thru mount-point approach (akka Netconf connector) will prevent this and data will be fetched once someone requsted them. Caching some data and data invalidation could be extension built on top of pass-thru mountpoint. 6) Are there tools that translate from an SNMP MIB definition to a Yang model as defined in RFC6643, or does this translation have to be done by hand? Currently I am not aware of any Java tooling, but there are some in other languages (eg. smidump). Tony ---- From: project-proposals-bounces@... [mailto:project-proposals-bounces@...] On Behalf Of Dean, Steve Sent: Friday, December 12, 2014 1:41 AM To: Robert Varga; Kent Watsen; Raza, Sarwar S. (HP Networking - ATG); Jan Medved (jmedved); project-proposals@... Cc: tsc@... Subject: Re: [Project-proposals] [OpenDaylight TSC] New Project Proposal - SNMP Plugin I need some education here. I have some questions to help me understand how this will work. 1) It appears that RFC 6643 defines how to translate an SNMP MIB definition into a Yang model. I assume the yang model defines how SNMP MIB data will be store in the MD_SAL data store. Is this correct? 2) If I want to set an SNMP MIB object in a device, I assume I write the value to the data store as defined by the yang model that represents the SNMP MIB object I want to set. Is this correct? 3) If I set an SNMP MIB object by writing the value to the data store, I assume this will notify a data change listener who will use an SNMP library to send an SNMP SetRequest message to the device. Is this correct? 4) How do I fetch (get) an SNMP MIB object from a device? Is there an RPC that I would call? I assume the code that implements the RPC would then have to call the SNMP library to send a GetRequest message to the device. 5) Does this approach attempt to keep all MIB data for all device in the MD-SAL data store? This seems like it would be a lot of data. How do we keep it accurate and up-to-date (ie, synchronized)? This seems like a lot of overhead to get the data and keep it up-to-date. 6) Are there tools that translate from an SNMP MIB definition to a Yang model as defined in RFC6643, or does this translation have to be done by hand? Sorry for all the question, but I want to understand how this will work. Thanks Steve From: Robert Varga [mailto:nite@...] Sent: Thursday, December 11, 2014 1:22 AM To: Kent Watsen; Dean, Steve; Raza, Sarwar S. (HP Networking - ATG); Jan Medved (jmedved); project-proposals@... Cc: tsc@... Subject: Re: [Project-proposals] [OpenDaylight TSC] New Project Proposal - SNMP Plugin Exactly. The SNMP integration would then work by formatting native MD-SAL data (which conforms to the MIB) into SNMP PDUs. From resource/engineering perspective, yes this is a larger chunk of work. Its benefit is the fact that SNMP devices will become almost first-class citizens. If we do not cover this in either snmp4sdn or the this plugin work, I think we can turn this into an intern project. Bye, Robert On 12/10/2014 10:26 PM, Kent Watsen wrote: Once a MIB is translated to a YANG module per RFC 6643, the expectation is that a NETCONF server would advertise support for said YANG modules and subsequent interactions would proceed via NETCONF. It sounds like you might want something a bit different, to use 6643 to generate YANG to feed MD-SAL to generate RESTCONF API, but still use SNMP protocol southbound. If this is indeed the case, I think that you may be able to ignore the warning in http://tools.ietf.org/html/rfc6643#section-11 regarding read-write/read-create SMIv2 objects being mapped to read-only (config false) YANG objects, since the underlying protocol would actually then still be SNMP. Thanks, Kent From: <Dean>, Steve <sdean@...> Date: Wednesday, December 10, 2014 at 2:40 PM To: "Raza, Sarwar S. (HP Networking - ATG)" <sarwar.s.raza@...>, "Jan Medved (jmedved)" <jmedved@...>, Robert Varga <nite@...>, "project-proposals@..." <project-proposals@...> Cc: "tsc@..." <tsc@...> Subject: Re: [Project-proposals] [OpenDaylight TSC] New Project Proposal - SNMP Plugin I took a quick look at RFC 6643 and don't fully understand how it works. The RFC appears to define how to translate SNMP MIBs into Yang models. I don't see where the RFC defines how you actually interact with an SNMP agent to get or set SNMP MIB objects. The DIDM (Device Identification and Driver Management) project needs to fetch (get) the SNMP sysObjectId from the device so that we can determine the type of device. I can also envision drivers (applications) that use SNMP to configure VLANs and VxLANs. These functions can be done using a simple SNMP Southbound Plugin that can be developed fairly quickly using an open source SNMP library (eg, snmp4j). I'm working on the DIDM project which has the need to get the SNSMP sysObjectId from a device. We have two options regarding SNMP. The DIDM project could use an SNMP library for its private use and not make it available to other applications. The other option is to split the DIDM project into two project, DIDM project and SNMP project. The SNMP project would develop an SNMP Plugin that can be used by all applications to interact with devices using SNMP. RFC 6643 may be a good long term solution and may fit well with a model driven architecture. However, this comes down to engineering resources. If other community members want to work on an RFC 6643 base approach, that would be fine. I was looking for a quick and cheap way for applications to perform basic SNMP operations with devices that support an SNMP agent. Thanks, Steve From: Raza, Sarwar S. (HP Networking - ATG) Sent: Wednesday, December 10, 2014 10:07 AM To: Jan Medved (jmedved); Robert Varga; Dean, Steve; project-proposals@... Cc: tsc@... Subject: RE: [OpenDaylight TSC] [Project-proposals] New Project Proposal - SNMP Plugin This would certainly takes the 'S' out of SNMP.. I see the value in the architectural clean-ness: but we should check with project originators if the intent is to have SNMP be a first class southbound protocol that allows every table and object to be addressable (I can see the case for it) vs. needing the ability to selective poll a sysOid or counter to accomplish a very specific and narrow task. \Sarwar Sarwar Raza Director, Cloud Networking & SDN Advanced Technology Group - HP Networking Hewlett-Packard, Littleton MA +1 (978)-760-3701 (mobile) sarwar.raza@... From:tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Jan Medved (jmedved) Sent: Wednesday, December 10, 2014 12:00 PM To: Robert Varga; Dean, Steve; project-proposals@... Cc: tsc@... Subject: Re: [OpenDaylight TSC] [Project-proposals] New Project Proposal - SNMP Plugin +1 on using/implementing RFC6643. That would be the best way to handle SNMP and abstract MIBs to all apps using the MD-SAL infra. Thanks, Jan From: Robert Varga <nite@...> Date: Wednesday, December 10, 2014 at 2:51 AM To: "Dean, Steve" <sdean@...>, "project-proposals@..." <project-proposals@...> Cc: "tsc@..." <tsc@...> Subject: Re: [OpenDaylight TSC] [Project-proposals] New Project Proposal - SNMP Plugin Hello Steve, I do not have specific experience with SNMP, but on the data modeling side, I think we should take a very good look at RFC6643 and try implementing it. It should provide us with near-native feel of all SMI-modeled data in MD-SAL context by giving us the ability to create YANG models from MIBs. The SNMP integration would then become an exercise in translating SNMP messages into NormalizedNode trees and the rest would be (probably) be taken care of the common MD-SAL infrastructure. Bye, Robert On 12/05/2014 07:11 PM, Dean, Steve wrote: Robert, First some background. I proposed two projects, SNMP project and Device Identification and Driver Management (D IDM) project. The DIDM project needs to determine the type of device (eg, HP 3800, Cisco 2960). For Openflow devices we may be able to determine the type of device based on the OF description information (eg, manufacture and hardware description). If we cannot determine the device type based on OF information or the device is not an OF device, then we will attempt to get the SNMP SysObjectID which will allow us to determine the type of device. The DIDM project needs to be able to perform a simple SNMP get operation. Regarding implementation. I haven't given it a lot of thought, but using an open source implementation such as snmp4j should satisfy the requirement. One option is for the DIDM project to use snmp4j for its private use. However, it seems that other applications will want to interact with a device using SNMP, so a separate SNMP Southbound Plugin project seems like the right approach. I'm interested to hear people's thought and experience with open source SNMP libraries. We don't have to use snmp4j. I'm also interested in hearing opinion about how to make the SNMP functionality available to applications. I'm still learning ODL and MD-SAL, but my understanding is that the API for a southbound plugin would be defined as a yang model and exposed to applications as RPCs (either global or routed). This will require writing some code that implements the API and uses the SNMP library to interact with devices. As mentioned above, the DIDM project just needs a simple API that allows it get a mib object. For the first release the API can be simple get and set methods. We can expose more functionality (like trap and walks) in future releases. How much functionality that can be implemented will depend on engineering resources that want to contribute to the project. Steve From: Robert Varga [mailto:nite@...] Sent: Friday, December 05, 2014 12:38 AM To: Dean, Steve; project-proposals@... Cc: tsc@... Subject: Re: [Project-proposals] New Project Proposal - SNMP Plugin Hello Steve, Would it be possible to expand the proposal with some mechanics/general approach? I would like to understand how you plan to deal with the actual payload. Thanks, Robert On 12/05/2014 02:44 AM, Dean, Steve wrote: We have posted a new project proposal for the Lithium release called "SNMP Plugin. https://wiki.opendaylight.org/view/Project_Proposals:SNMP_Plugin Phil, can we get a spot on the TSC agenda on December 18th for the presentation and Creation Review. Thanks Steve Dean _______________________________________________ project-proposals mailing list project-proposals@... https://lists.opendaylight.org/mailman/listinfo/project-proposals |
|
|