Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Martin Heusse <Martin.Heusse@imag.fr> Fri, 18 May 2012 20:45 UTC

Return-Path: <Martin.Heusse@imag.fr>
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 B577121F85F4 for <roll@ietfa.amsl.com>; Fri, 18 May 2012 13:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.505
X-Spam-Level: **
X-Spam-Status: No, score=2.505 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_BELOW2=2.154, HELO_EQ_FR=0.35]
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 gbdBbpliUmBS for <roll@ietfa.amsl.com>; Fri, 18 May 2012 13:45:21 -0700 (PDT)
Received: from rominette.imag.fr (mx2.imag.fr [IPv6:2001:660:5301:59::17]) by ietfa.amsl.com (Postfix) with ESMTP id E3A6121F85EE for <roll@ietf.org>; Fri, 18 May 2012 13:45:20 -0700 (PDT)
Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id q4IKbVnB013718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2012 22:37:31 +0200
Received: from [192.168.1.1] (lns-bzn-51f-81-56-135-57.adsl.proxad.net [81.56.135.57]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id q4IKodHr025504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 22:50:40 +0200
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Martin Heusse <Martin.Heusse@imag.fr>
In-Reply-To: <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu>
Date: Fri, 18 May 2012 22:46:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr>
References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <B1B81482-0F7E-4BCE-BBA7-B21949E3C16C@cisco.com> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <ACBA7834-F4A1-4D9C-80D6-E76C793A6770@cisco.com> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <BE51553F-67BE-4652-A8E8-9654BF953A96@thomasclausen.org> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu>
To: roll WG <roll@ietf.org>
X-Mailer: Apple Mail (2.1278)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Fri, 18 May 2012 22:37:32 +0200 (CEST)
X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information
X-MailScanner-ID: q4IKbVnB013718
X-IMAG-MailScanner: Found to be clean
X-IMAG-MailScanner-SpamCheck:
X-IMAG-MailScanner-From: martin.heusse@imag.fr
MailScanner-NULL-Check: 1337978255.17568@u6Mi47PKqDoJG4mFjBG89Q
Cc: Michael Richardson <mcr@sandelman.ca>
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
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: Fri, 18 May 2012 20:45:21 -0000

Phil, 
what you are writing bellow may be true (although...) but it does not address comment 12, that we have no idea when DAOs should be sent and how DAOs should be handled (how long should the route be kept?). 

Along those lines, 2 comments:
1) I notice that draft-ietf-roll-applicability-ami, for instance, ignores DAOs except for specifying that DAOs SHOULD be sent -- so they might not be sent--, even though "Two-way communication is a requirement"(?). At the same time, this draft goes as far as suggesting what parameters to use for trickle (big deal) or for MaxRankIncrease (big deal: will things break if someone uses 512 instead of 1024?). 
(same comment applies to draft-gnawali-roll-rpl-recommendations-03.)
2) <sarcasm> What is the point of making DAOs compact in storing mode (learning the route recursively) while the packets that actually contain data have to carry the whole path anyway? </sarcasm> 

Best regards,
Martin


Philip Levis wrote:

> For 12, "implementations may exhibit a bad performance if not carefully implemented."  I think it is safe to say this is true for almost ANY protocol. A specification is not intended to be a complete statement of efficient implementation, otherwise you give little latitude to future improvements and good engineering.