Re: [Roll] RPL MIB

[Juergen Schoenwaelder <[e-mail]>]

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/>