Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

ietf@thomasclausen.org Thu, 17 March 2016 17:21 UTC

Return-Path: <Ietf@thomasclausen.org>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C439412DD89 for <manet@ietfa.amsl.com>; Thu, 17 Mar 2016 10:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DStHYe3kFrYp for <manet@ietfa.amsl.com>; Thu, 17 Mar 2016 10:20:58 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4476F12DD0E for <manet@ietf.org>; Thu, 17 Mar 2016 10:15:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D6012240D1C; Thu, 17 Mar 2016 10:15:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1458234932; bh=GuIsKRY4bB2AZequpyQpa3jJrc+WRtnP4Bym/9oUiyU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=F+xY8qoOmRHgUBHHuK3fczWhWpAvf6pT5wH0a39rUplzqsQOzKLPoyIToTCP5MwHg FN4ANj1GNNMM4R1TkflcJbpOIJnlL39SwKxjkGyn+YnQ2rRoG5VAVexHUeHpKCWo03 zgk6vM8zly65dQJb3vb0GJt/RPb7ErdUTZAqlaUg=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [129.104.89.231] (unknown [129.104.89.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0A12D24069F; Thu, 17 Mar 2016 10:15:31 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_1C935FE1-644D-4A6C-B7A1-679BAC5AA9D3"
From: ietf@thomasclausen.org
In-Reply-To: <280329CF-8CE8-439A-93AA-A75DAA8D1ACE@fu-berlin.de>
Date: Thu, 17 Mar 2016 18:15:30 +0100
Sendlaterdate: Thu, 17 Mar 2016 18:15:30 +0100
Message-Id: <73243573-85E4-4163-A626-F6C3368F5D87@thomasclausen.org>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org> <280329CF-8CE8-439A-93AA-A75DAA8D1ACE@fu-berlin.de>
To: Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/0rEVF3GPZ7vYSeZ9Q84S2KsB-Tk>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2016 17:21:01 -0000

> On 17 Mar 2016, at 17:25, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
> 
> Hi Thomas, 
> 
>> Am 17.03.2016 um 17:00 schrieb ietf@thomasclausen.org <mailto:ietf@thomasclausen.org>:
>> 
>> Dear all,
>> 
>> Apologies for not having gotten this done sooner - day-job leaving few spare cycles.
>> 
>> I’ve previously offered reviews and comments, and some of those have been addressed in the latest I-D — others have not, but should be. I recall that there was some mail attempting to rebut parts of the review, and I will dig it out and reply to that.
>> 
>> With that being said, I have reviewed the latest version of the document, and full details will be forthcoming. There’re a couple of big-ticket/architectural items that I want to address up front, as I believe that before we have those hammered out, it will be useless to go into details. Note, I do not claim that this is an exhaustive list of “big ticket items”, but that’s as far as I have gotten in thinking this through.
>> 
>> I also bring these up as they are items that have been brought up repeatedly over the past years, but not resolved nor discussed.
>> 
>> Loops
>> Just to bring this out: I share Chris’ worry about conflicting and concurrent statements from the authors on “There are no loops possible” and “We need to fix two situations where loops can occur” and “we are still investigating some loop conditions”
> 
> Just one thing until I can go through your entire review: the conflict was between „There are no loops possible“ and „There were two loops possible and we’ve fixed them.“. I’ve written down the fixes for said loops under the description how they can occur.

On March 1, Perkins wrote:
> Other discussion about routing loops has not identified routing loop problems in the existing specification.  Use of unconfirmed or invalid routes for routing might lead to errors, but that doesn't carry over to produce loops in the route table.

On March 2, Chris wrote:
> My concerns have been that your co-authors have continued to discuss whether looping could occur since you published to the list saying all was well. (An issue to do with multiple unconfirmed routes.) Maybe that’s a problem, maybe it isn’t. But it lacks transparency, because it hasn’t been discussed here.

Which yesterday, March 16, you replied to by saying:
> The loop possibility you’re referring to was a different one than the one discussed by Charlie. We’ve been contacted by researchers who are model checking MANET protocols to see if they permit any unwanted behaviour. They’ve used AODVv2 as a case study for the framework they’ve implemented to do this, and they’ve found the following loop:



Of course, not being privy to non-mane-list-discussions,  all I can go by is public record. Which is that Perkins clearly affirmed (on the list) that there had been looping discussions, but no loop possibilities identified, on March 1, and you wrote March 16 that apparently there was another loop possibility discussed, brought t you by some researchers …