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

[Omprakash Gnawali <[e-mail]>]

Can someone post a link to the paper being referenced? Thanks.

- om_p

On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll <[e-mail]> wrote:
> 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
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>