Subject: Re: [Roll] RPL MIB

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 2 Sep 2013 11:31:34 +0100

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: [email-masked] [mailto:[email-masked]] 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 <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 3 Sep 2013 06:20:09 +0000

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 <[email-masked]> wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 3 Sep 2013 07:44:42 +0000

Typo "I cannot agree MORE" ;-)

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 3 Sep 2013 13:34:16 +0000

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: [email-masked] [mailto:[email-masked]] 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

On Sep 3, 2013, at 8:20 AM, JP Vasseur (jvasseur) <[email-masked]> 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.
>
>> 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
>>
>>> The WG has discussed this question a few times and has not reached
>>> any consensus.
>>>
>>> Here is the summary:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> --

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Sep 2013 15:45:51 +0200

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 3 Sep 2013 14:12:55 +0000

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: [email-masked] [mailto:[email-masked]] 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:
> > 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.
> >
> >> In this context it might make a lot of sense for some work to be 
> >> done on a "management framework for RPL devices".
> >>
> >> This would lead to an Information model, which might in time lead 
> >> to a data model.
> >>
> >>>> 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.
> >>>
> >>> 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.
> >>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Sep 2013 19:01:21 +0200

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

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 3 Sep 2013 17:23:01 +0000

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: [email-masked] [mailto:[email-masked]] 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:
> > >> 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 
> > >> It is definitely also worth coordinating with CORE to see what 
> > >> they think about higher layer protocols to constrained devices.
> > >>
> > >> Cheers,
> > >> Adrian
> > >>
> > >>> The WG has discussed this question a few times and has not 
> > >>> reached any consensus.
> > >>>
> > >>> Here is the summary:
> > >>>
> > >>> 4) opinions have ranged from HTTP / CoAP to NetCONF/YANG as 
> > >>> other transport  alternatives to SNMP.
> > >>>
> > >>> 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.
> > >>>
> > >>> --

---

From: peter van der Stok <[email-masked]>
Date: Wed, 04 Sep 2013 11:37:27 +0200

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

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 4 Sep 2013 14:42:01 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Wednesday, September 04, 2013 5:37 AM
To: [email-masked]
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:
> 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 
> a side effect, it of course works well with SNMP as an access mechanism.