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

[Ietf Roll <[e-mail]>]

This is good news that Zigbee is making it work.  I guess that since your 
requirements are only 30 nodes then that matches the paper that says RPL for constrained devices should be limited to 30 nodes.

It is also good to be re-affirmed that downward routing is not 
particularly good in RPL.  Others have already stated this and Zigbee 
seems to confirm this.


Rav

PS - Since many keep pointing at 
me, I am not putting my full name and company in my email for I fear retribution.  I do not want to lose my job for asking questions and 
criticizing parts of the RPL design.  I do not want my company or my 
supervisor called by people like a chair and have my job put at risk.


________________________________
From: Don Sturek <[e-mail]>
To: Ietf Roll <[e-mail]>; JP Vasseur <[e-mail]>; Thomas Heide Clausen <[e-mail]>
Cc: roll WG <[e-mail]>
Sent: Sunday, September 4, 2011 7:20 AM
Subject: 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 <[e-mail]>
Reply-To:  Ietf Roll <[e-mail]>
Date:  Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
To:  JP Vasseur <[e-mail]>, Thomas Heide Clausen <[e-mail]>
Cc:  roll WG <[e-mail]>
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 [e-mail] https://www.ietf.org/mailman/listinfo/roll