Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Here are a few points to maybe consider:
1)   ZigBee is not "having problems making it work" (referring to ROLL RPL.
I chair the group in ZigBee testing "ZigBee IP" and we have had relatively
good success using RPL for the use cases we are considering.
2)   The Smart Energy 2.0 use cases are for only 30 devices in a single home
area network.   We are testing 30 nodes with 3 hops
3)   The upward routing feature in RPL is quite efficient.  The downward
routing feature either assumes storing mode (which we don't use) or
non-storing mode with source routing (which does not offer pro-active or
re-active route establishment).
4)   I personally would not use ROLL RPL as it is for low latency
applications like lighting control, home automation, etc.   I fully support
the ROLL RPL P2P draft for these applications.

On additional, perhaps related topics:
5)  I don't believe there will be only a single mesh routing protocol
defined for all applications in IETF.  I fully support the work going on in
MANET and also think "mesh under" solutions will also be useful for some
applications

And finally:
6)  All this said, I think ZigBee IP will successfully conclude testing
using ROLL RPL

Happy to sign my real name,

Don Sturek

From:  Ietf Roll <ietfroll@yahoo.com>
Reply-To:  Ietf Roll <ietfroll@yahoo.com>
Date:  Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
To:  JP Vasseur <jpv@cisco.com>, Thomas Heide Clausen
<ietf@thomasclausen.org>
Cc:  roll WG <roll@ietf.org>
Subject:  Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new
ROLL WG document

JP Vasseur wrote:

*if* you think that this not elegant enough (which has to be demonstrated
IMO), then you must be supportive
of the P2P IDs work that the WG has been working on ?

[rav] how about a demonstration that RPL actually works as purported.
Thomas has said that his group implemented it and it was difficult, complex
and fraught with inconsistencies in specification.
         I heard that zigbee is having problems making it work and the only
paper that I've seen on RPL says that for constrained nodes they recommend
no more than 30 nodes in a network.  Hardly the scale necessary for some of
the 
         use cases been suggested (like AMI).

         The P2P is a hack to try to fix the fact the RPL is basically a
collection tree and as such downward routing is an distant after thought
(certainly not elegant).

         Without lots of memory, node must use non-storing mode (oh and we
are talking about constrained devices so lots of memory is then
inconsistent) and then routing is up to the root and back down.  Not what
anyone who
         understands routing would consider elegant P2P.

         In the rush to get RPL out of the working group we all were
bamboozled by the chair into believing the draft was actually complete and
the IESG further compounded this error.

         If it were possible to fix things, RPL should be an experimental
draft until such time as there are working interoperable implementations
that are shown to provide the services that were required in the various
Use-case
         drafts - or even just one of them.

         And now we are rushing to generate and publish a marketing document
(called an applicability statement) without having any experience with the
protocol.

         Are we rushing and putting so much pressure and bending the systems
so that this gets published before we find we've built a house of cards and
it comes crashing down.

         This will be really counter productive to the industry and the
Internet (certainly not Thomas's warnings).  When everyone looks at this
mistake and says, why didn't the IETF do its job and exercise proper
engineering, then the ROLL WG
          and the Chairs will be the ones that have hurt the industry and
the Internet.

Rav

_______________________________________________ Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll