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

Mukul Goyal <mukul@uwm.edu> Sat, 03 September 2011 15:31 UTC

Return-Path: <prvs=2203449e0=mukul@uwm.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4921F8B15 for <roll@ietfa.amsl.com>; Sat, 3 Sep 2011 08:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.032
X-Spam-Level:
X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKkD1LfMKHmA for <roll@ietfa.amsl.com>; Sat, 3 Sep 2011 08:31:58 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 002D421F8B14 for <roll@ietf.org>; Sat, 3 Sep 2011 08:31:57 -0700 (PDT)
Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 03 Sep 2011 10:33:35 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 82F062B3F2F; Sat, 3 Sep 2011 10:33:03 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu
Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t14Rq7oboMYE; Sat, 3 Sep 2011 10:33:03 -0500 (CDT)
Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 08A552B3F21; Sat, 3 Sep 2011 10:33:03 -0500 (CDT)
Date: Sat, 03 Sep 2011 10:33:35 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Ietf Roll <ietfroll@yahoo.com>
Message-ID: <1230776290.183247.1315064014742.JavaMail.root@mail05.pantherlink.uwm.edu>
In-Reply-To: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll WG <roll@ietf.org>
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Sep 2011 15:31:59 -0000

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

An open-source RPL implementation on Contiki has existed for a while. I am a cursory observer of the Contiki mailing list but it is clear to me that this RPL implementation is quite popular. INRIA (Matthias Phillip and Emmanuel Baccelli) did an RPL-P2P implementation on top of this implementation. This implementatio is uptodate with RPL-P2P version 4. I have checked this code (and also the core RPL implementation code) line by line and I dont see how we can characterize the implementation difficult/complex or fraught with inconsistencies. A second P2P-RPL implementation is in works at Sigma Design.

I hear the zigbee-IP folks have been testing various RPL implementations very aggressively. I have not heard difficult/complex/inconsistent complaints there too (although I have no direct participation in that effort but I hear about the ongings of zigbee-IP activities from people who do). So, I think this particular statement may not be accurate or fair. Perhaps some one from zigbee-IP camp can update us on the situation in this regard.  

I guess I object to rest of this email too. I guess people will realize it for what it is - unfounded libel from a person too afraid to identify himself/herself.

Thanks
Mukul

----- Original Message -----
From: "Ietf Roll" <ietfroll@yahoo.com>
To: "JP Vasseur" <jpv@cisco.com>, "Thomas Heide Clausen" <ietf@thomasclausen.org>
Cc: "roll WG" <roll@ietf.org>
Sent: Saturday, September 3, 2011 2:54:25 AM
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