Re: [Roll] RPL MIB

[Juergen Schoenwaelder <[e-mail]>]

Randy,

we have done a detailed analysis of our SNMP stack implemented on
Contiki. SNMP itself is not a resource hog (actually no surprise given
that SNMP was designed in the 80s). If you do crypto in software, then
the crypto code is the killer in size and (depending on the platform)
in performance. But this applies equally well to DTLS as long as you
can't exploit hardware crypto and you use off-the-shelf cryto
algorithms.

Anyway, having agreement which counters etc. should be in the RPL code
would already be a big plus. If people can ship the data more
efficiently or more comfortably over CoAP and there is no need to
integrate with SNMP-based tools, fine.

/js

On Tue, Sep 03, 2013 at 02:12:55PM +0000, Turner, Randy wrote:
> 
> Yes, you can separate the usage of the MIB data model within a device from the SNMP protocol used to transport it -- however, there should be a very good reason for doing this.  I think it might be possible to "profile" SNMPv3 in such a way as to make it more attractive to constrained devices.
> 
> Randy
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, September 03, 2013 9:46 AM
> To: Routing Over Low power and Lossy networks
> Subject: Re: [Roll] RPL MIB
> 
> Hi,
> 
> the key is to find agreement which counters etc. are relevant to instrument in the RPL code. Whether one provides access to these counters via SNMP or some other means may depends on the specific constraints of the device and the deployment target.
> 
> A MIB module is a way to define what needs to be instrumented and, as a side effect, it of course works well with SNMP as an access mechanism. But this does not exclude other access mechanism from being used instead.
> 
> /js
> 
> On Tue, Sep 03, 2013 at 01:34:16PM +0000, Turner, Randy wrote:
> > 
> > There is an expired draft for an RPL MIB that I think is a good  start...that doesn't seem to violate the spirit of what is being proposed below.
> > 
> > So it doesn't appear that this would be a "from scratch" effort.
> > 
> > The data model suggested by the expired draft offers some good ideas, much of it I think is quite usable and valuable.
> > 
> > There remains a "non-data-related" aspect of management in an LLN, which might suggest that there are some endpoint devices that are too constrained to support something like an SNMP agent.   While that maybe true, I believe the more constrained a device is in functionality and capability, the less likely I may want to actively (pro-actively) manage such an endpoint.
> > 
> > Randy
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf 
> > Of JP Vasseur (jvasseur)
> > Sent: Tuesday, September 03, 2013 3:45 AM
> > To: Adrian Farrel; Routing Over Low power and Lossy networks
> > Subject: Re: [Roll] RPL MIB
> > 
> > Typo "I cannot agree MORE" ;-)
> > 
> > On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) <[e-mail]> wrote:
> > 
> > > Hi,
> > >
> > > I cannot agree, adding some thoughts: of course, we would need to 
> > > think very careful on where such a management MIB would be run and 
> > > the framework should cover some of the required workflow. Indeed, 
> > > running a RPL MIB on a router would make total sense, but may be 
> > > simply not possible on a low-end node (due to memory but also bandwidth constraint), and this is where we would need to sync up with CORE.
> > >
> > > Cheers.
> > >
> > > JP.
> > >
> > > On Sep 2, 2013, at 12:31 PM, Adrian Farrel <[e-mail]> wrote:
> > >
> > >> Hi,
> > >>
> > >> In this context it might make a lot of sense for some work to be 
> > >> done on a "management framework for RPL devices".
> > >>
> > >> What needs to be configurable? What protocol needs to be visible?
> > >> What information is needed for diagnostics? What alarms/alerts are 
> > >> needed? What are the implications of storing logs? What are the 
> > >> implications of sending unsolicited notifications and/or of 
> > >> responding to status queries? What protocols are appropriate?
> > >>
> > >> This would lead to an Information model, which might in time lead 
> > >> to a data model.
> > >>
> > >> It is definitely also worth coordinating with CORE to see what they 
> > >> think about higher layer protocols to constrained devices.
> > >>
> > >> Cheers,
> > >> Adrian
> > >>
> > >>> -----Original Message-----
> > >>> From: [e-mail] [mailto:[e-mail]] On 
> > >>> Behalf Of
> > >> Michael
> > >>> Richardson
> > >>> Sent: 30 August 2013 18:52
> > >>> To: Routing Over Low power and Lossy networks
> > >>> Subject: Re: [Roll] RPL MIB
> > >>>
> > >>>
> > >>> Turner, Randy <[e-mail]> wrote:
> > >>>> On the IETF ROLL WG page, I was looking for a current (not 
> > >>>> expired) version of the RPL MIB draft, but there doesn?t appear to be one.
> > >>>
> > >>> It likely expired.
> > >>>
> > >>> http://datatracker.ietf.org/doc/draft-sehgal-roll-rpl-mib/
> > >>>
> > >>>> Can someone let me know what the status of this work is ?
> > >>>
> > >>> The WG has discussed this question a few times and has not reached 
> > >>> any consensus.
> > >>>
> > >>> Here is the summary:
> > >>>
> > >>> 1) many feel that an **SNMP** Agent is not going to fit into 
> > >>> constrained
> > >> devices.
> > >>> 2) Jurgen has demonstrated it does fit into a class 2 device on 
> > >>> using  Contiki.
> > >>> 3) others have pointed out that SNMP is not the only way to deal 
> > >>> with a MIB,  and the important things in a MIB is the set of 
> > >>> statistics which one might  collect, and transmit in *some* way.
> > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as other 
> > >>> transport  alternatives to SNMP.
> > >>>
> > >>> I think that it is simply early for many people to talk about 
> > >>> having consistent sets of statistics... BUT. PLEASE FEEL FREE TO PROVE ME WRONG.
> > >>>
> > >>> In particular, I think that *some* standard way to get the network 
> > >>> adjacency matrix (as well as the DODAG) out of motes would be very 
> > >>> useful for network operators.
> > >>>
> > >>> --
> > >>> Michael Richardson <[e-mail]>, Sandelman Software Works
> > >>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
> > >>
> > >>
> > >> _______________________________________________
> > >> Roll mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/roll
> > >
> > > _______________________________________________
> > > Roll mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/roll
> > 
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> > 
> > 
> > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
> > 
> > This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>