Re: [Roll] RPL MIB

["Turner, Randy" <[e-mail]>]

Hi Peter,

Yes, the eventual model may be that there is  an SNMP proxy on a less-resource-constrained DODAG root device, which proxies SNMP operations (and notifications) between head-end management stations and endpoint devices on the LLN.  The protocol that is proxied "to" could be CoAP, or something else, but I would try to avoid creating something new.  My first attempt would be to somehow "profile" SNMPv3 "as is" (no proxy), and if that is too much for an endpoint (or LLN), then move to other proxy methods.

Randy

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of peter van der Stok
Sent: Wednesday, September 04, 2013 5:37 AM
To: [e-mail]
Subject: Re: [Roll] RPL MIB

Hi Randy,

excellent idea to look at a MIB for RPL, RPL-P2P, and MPL. I hope you will also include the parameters that need initialization,
like: k, c, Imin, DIOIntervalMin, DIOIntervalDoublings, etc.

I agree fully with the reuse of the existing MIB base also for low resource devices.
The separation between SNMP and MIB is nicely described in RFC 3410.
I don't see people changing their existing SNMP installed base, but I get requests to look at a CoAP interface to the MIBs for the small devices.

I have been working on a CoAP interface to the MIBs, called CoMI (CoAP Management Interface).
I expect to publish a second, much improved, more focussed, draft the coming weeks.

According to me the advantages are: One programming interface for management and other applications and the subsequent reduction in stack complexity, reduction of security complexity as proposed during the DICE BoF will follow automatically with CoAP updates, use of resource discovery will come for free, possible use of multicast to initialize variables to a group of devices.
Disadvantages are: a different approach to the multi packet transport, and a different approach to passing through the lexicographically ordered list of data.
This list of (dis)advantages still needs to be validated.

Greetings,

Peter van der Stok



Turner, Randy schreef op 2013-09-03 19:23:
> Agreed, if they already have COAP in the box, then there's an 
> incentive to reuse it as much as possible -- but if they don't, there 
> are a multitude of existing network management infrastructures that 
> utilize SNMP managers -- this infrastructure could be reused -- I'm 
> not aware of any NMS vendors looking at adapting anything new on the 
> protocol front (except possibly NETCONF, which has its' own 
> implications for constrained devices). I'm happy to be proved wrong 
> here :)
> 
> At the end of the day, I would like to reuse existing SNMP management 
> infrastructure as much as possible, but I'm not opposed to using 
> something else to transport the management information, if need be.
> 
> I think we're going to want to secure the network management traffic 
> regardless of transport, so I'm assuming crypto overhead is "sunk 
> cost", meaning it's going to be there.
> 
> If there is consensus in the WG, I would like to "restart" the MIB and 
> associated management effort, with of course input from other 
> interested parties (CORE, etc.)
> 
> R.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Juergen Schoenwaelder
> Sent: Tuesday, September 03, 2013 1:01 PM
> To: Routing Over Low power and Lossy networks
> Subject: Re: [Roll] RPL MIB
> 
> 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
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll