Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> Fri, 22 April 2016 09:28 UTC

Return-Path: <lotte.steenbrink@fu-berlin.de>
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 B3DAB12EA94 for <manet@ietfa.amsl.com>; Fri, 22 Apr 2016 02:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.197
X-Spam-Level:
X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YSzlGVkLAwri for <manet@ietfa.amsl.com>; Fri, 22 Apr 2016 02:28:20 -0700 (PDT)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA7C12D9B0 for <manet@ietf.org>; Fri, 22 Apr 2016 02:28:20 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from <lotte.steenbrink@fu-berlin.de>) id <1atXNq-002hJH-TB>; Fri, 22 Apr 2016 11:28:18 +0200
Received: from p548d7b4d.dip0.t-ipconnect.de ([84.141.123.77] helo=[192.168.46.209]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from <lotte.steenbrink@fu-berlin.de>) id <1atXNq-004A6k-Hu>; Fri, 22 Apr 2016 11:28:18 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>
In-Reply-To: <CAGnRvuo6uE8SW5HXAhTvT5hxk2h9ZgkHVfzcg7bxCTvZYZ3iDw@mail.gmail.com>
Date: Fri, 22 Apr 2016 11:28:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org> <DE42008F-25E3-492E-8499-2DC13BDB0E8E@fu-berlin.de> <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de> <CAGnRvuo6uE8SW5HXAhTvT5hxk2h9ZgkHVfzcg7bxCTvZYZ3iDw@mail.gmail.com>
To: Henning Rogge <hrogge@gmail.com>
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 84.141.123.77
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/9KS1B3AsexXoxu-cvdmRhY_J2Rk>
Cc: Mobile Ad Hoc Networks mailing list <manet@ietf.org>
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: 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: Fri, 22 Apr 2016 09:28:21 -0000

Hi Henning,

> Am 22.04.2016 um 11:08 schrieb Henning Rogge <hrogge@gmail.com>:
> 
> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
> <lotte.steenbrink@fu-berlin.de> wrote:
>> Hi Thomas,
>> Can it?! Iirc, the reason why we adopted the “regeneration” language in the
>> first place is that we’ve been told that whenever one bit in the message
>> (apart from its header) is changed, the entire thing has to be regenerated.
>> I’m starting to get the feeling we’ve just been misunderstanding each other
>> for more than a year. :( Anyway, it seems like we’re getting close now, so
>> yay.
> 
> "Modifying" the binary message instead of parsing and generating a new
> one will be difficult as soon someone writes an extension to AODVv2
> that adds more TLVs to the message.
> 

D’oh, right. Yeah, if I remember it correctly, that’s what you explained to me when I got confused about the topic last spring… But– even if a message contains TLVs that the AODVv2 implementation handling it doesn’t understand, it will still be able to recognize the Metric TLV, right? Isn’t that the nifty thing about RFC5444? So, while we really shouldn’t write “before calculating the ICV, set the n-th 4 octets to 0”, we might say “identify the octets that make up the metric value and set those to 0”?

Best regards,
Lotte

> Henning Rogge