Subject: Re: [OPSAWG] IoT & Network Management

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Apr 2014 13:41:10 +0200

On Mon, Mar 31, 2014 at 02:53:13PM +0200, Hannes Tschofenig wrote:
> Hi all,
> 
> after I listened to Juergen's presentation in the CORE working group at
> the last IETF meeting about 'constrained management' I was wondering
> about the following aspect:
> 
> More and more devices (specifically IoT devices) come with a built-in
> software update mechanism (even at different levels). For example, you
> can see firmware update mechanisms, the ability to update individual
> files (if there is a file system), or package managers being used.

There is a wide range of different device classes. I do not believe
that package managers are generally available on all device classes.
In a nutshell, there are the really constrained devices (see LWIG
terminology) and then there are devices with sufficient resources to
run an embedded Linux or BSD kernels. A file system and package
managers sound to me you are assuming the later.
 
> The configuration data and the code is often treated in the same way and
> also updated using the same style (to better deal with the constrained
> nature of these devices).

Reference?

> I am wondering what the role of traditional network management protocols
> actually is.
>
> Why would I add, let's say, SNMP to my IoT device to configure the
> device or to retrieve sensor information when I anyway have to provide a
> software update mechanism together with some application layer protocol
> (like CoAP)?

What matters most is reuse of data models. How you ship the data
depends on many criteria. All I can say (since we did implement SNMP)
is that SNMP works reasonably well on constrained devices. But yes, if
you live in a CoAP world, you may prefer to ship data via CoAP (once
you have worked out the details). What would be a failure in my view
is to redo the data models.

/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: Hannes Tschofenig <[email-masked]>
Date: Tue, 01 Apr 2014 14:31:33 +0200

Hi Juergen,

thanks for your response.

> managers sound to me you are assuming the later.

There are certainly a range of devices. For that reason I have listed a
number of techniques used by these devices to provide updates.

Many Linux-based IoT devices use a form of package manager. These are
more "high-end" devices.

>> nature of these devices).

Thinking about some of the products I have seen in the wearable space I
might be wrong since there you often have a firmware update mechanism
for the core functionality (code & long-term configuration data) but
then also a configuration mechanism for short-term data.

Since it would require reverse engineering to really find out what these
products are doing it raises the question about where interoperability
is needed. Many of today's products show a pattern that is very close to
what we described in Figure 2 of
http://tools.ietf.org/html/draft-iab-smart-object-architecture-03.

In that sense it does not really matter whether and how configuration
data is attached to the code itself since it is proprietary anyway.

> is that SNMP works reasonably well on constrained devices.

Unless you do all your tasks on an embedded device with SNMP (or a
similar protocol) it seems to be the wrong choice to me since you are
adding one additional protocol to implement with functionality that
overlaps the other protocol.  You might have some experience that I have
not yet understood though (which caused me to start a discussion about it).

> But yes, if

That's an interesting perspective. What data models from the network
management community do you see most valuable?

(Of course, I am not married to CoAP and there is a lot of HTTP usage
out there as well. I have only seen one product that used SNMP in the
lighting space and I was asking myself why didn't they use CoAP or HTTP.)

Ciao
Hannes

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 1 Apr 2014 18:48:04 +0300

I agree with Jürgen that it would be useful to maintain currently defined
data models (in SMI and YANG). The protocol exchanging the actual data
could be a different one if we conclude that SNMP/NETCONF are unsuitable
for constrained environments. I remember that in one of the unofficial
COMAN meetings, we discussed the possibility to port RESTCONF
(draft-bierman-netconf-restconf-04) to COAP instead of HTTP. That would be
one option to reuse existing Yang models. And possibly MIB modules via RFC
6643.

Best regards
Ulrich

On Tue, Apr 1, 2014 at 2:41 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Apr 2014 09:27:01 +0200

> not yet understood though (which caused me to start a discussion about it).

Yes, on our constrained devices, we actually do everything via SNMP
(since reading some energy sensors is pretty straight-forward to do
with SNMP). And yes, if you life in a CoAP world, you likely want to
do as much as possible with CoAP. (But then I must admit that we also
did implement mDNS since since it is just so cool to see your sensors
popping up in your mDNS enables applications. Sometimes it is the ease
of reuse of existing stuff that compensates some extra implementation
costs.)

> management community do you see most valuable?

If you want to expose basic counters related to your network
interfaces or your IP stack or you want to expose your IP
configuration, then I think we should try to reuse what we have and
not reinvent the wheel. If RESTCONF can be mapped well to CoAP and
constrained devices, this may be an interesting option.

/js

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 02 Apr 2014 09:49:25 +0200

Hi Juergen,

> of reuse of existing stuff that compensates some extra implementation

Did you document that work somewhere? (an IETF draft or so?)

> constrained devices, this may be an interesting option.

I could see this data being of interest for a router/switch but not
necessarily for an end device.

Would you agree?

Ciao
Hannes

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 2 Apr 2014 09:04:48 -0700 (PDT)

> necessarily for an end device.

Often times it is because there are differing technologies that the network 
operations team stop at the edge switch and not at the nic/ip stack on the end device.  
Yet this is one of the most common areas for failure for any number of reasons. 

In my experience working with Fortune 50 enterprises I keep hearing
this  common refrain, it goes like this:

"Company X is taking a holistic view of their data center and wish to
treat all assets in a uniform manner."

And why is that? because it lowers the cost of doing business. 
If adapters to convert one technology to another are needed they 
cost time and money. So while I agree its not fun to have to implement
overlapping technologies from the developers point of view, at
least if one of the technologies is snmp at least it didn't 
suck up all the devices remaining resources and is highly likely
to be used to good effect.

Mike

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 2 Apr 2014 13:37:21 -0400

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Michael
> MacFaden
> Sent: Wednesday, April 02, 2014 12:05 PM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [OPSAWG] IoT & Network Management
> 

Assuming "this data" in your question refers to the network interfaces
and/or IP stack, I wouldn't agree that this is only interesting for a
router/switch. The network ends at the endpoint, not at the forwarding
device. Troubleshooting a networking problem often requires troubleshooting
the endpoint configuration of the relevant interfaces (and interface-using
applications), not just the router/switch.

 David Harrington
[email-masked]
+1-603-828-1401

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Apr 2014 08:18:55 +1300

>> constrained devices, this may be an interesting option.

Please explain what you mean by mapping RESTCONF to CoAP. Do you
mean some sort of RESTCONF/CoAP gateway box? I can't imagine
RESTCONF itself on a constrained device.

    Brian

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Apr 2014 18:36:00 -0700

> RESTCONF itself on a constrained device.
I think HTTP and TCP are more problematic than RESTCONF.
The concept of CRUD operations on a datastore scales down
to constrained devices.

CoAP defines an HTTP <--> CoAP proxy server, so the CoAP translation
could be used.  The direct translation may not be optimal, so there might
be a "native CoAP mode" between CoAP client and CoAP server
that was more efficient.

>     Brian

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Apr 2014 17:14:03 +0200

> Did you document that work somewhere? (an IETF draft or so?)

We published performance and resource usage numbers for our SNMP
implementation and we share the code (so people can compare to it even
if they run on different platforms).

http://dx.doi.org/10.1109/MCOM.2012.6384464
http://dx.doi.org/10.1109/GreenCom.2012.21
http://dx.doi.org/10.1007/978-3-642-21484-4_13

/js