Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 22 April 2011 07:37 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lowpan@ietfc.amsl.com
Delivered-To: 6lowpan@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76507E06AA for <6lowpan@ietfc.amsl.com>; Fri, 22 Apr 2011 00:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.08
X-Spam-Level:
X-Spam-Status: No, score=-9.08 tagged_above=-999 required=5 tests=[AWL=1.519, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGK+Ext5sX6k for <6lowpan@ietfc.amsl.com>; Fri, 22 Apr 2011 00:37:40 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 961D7E0679 for <6lowpan@ietf.org>; Fri, 22 Apr 2011 00:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1523; q=dns/txt; s=iport; t=1303457860; x=1304667460; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wp31cOXlNpJF2XDPE4K7YmgUz27DzVX3cukNAN8MH5c=; b=TVMhJnFncdU6JgetxI4dRBnJY8QxGmp/1JU4RludydTPrJGzNFphek8j v6dwAQFTapd7jBaOcOzjERTlIC8KbYxScJuE/S8iZRDdtjhB50itVAxJj GqMa+yKkV9dbZQqbPG38g5s/Vs6UkmvfDvBLomdewJ3DoWfyAuD9MUb0V 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcEAHwvsU2Q/khMgWdsb2JhbAClXhQBARYmJYhwnRicXYV2BJI7
X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="26718732"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Apr 2011 07:37:39 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3M7bdXl019690; Fri, 22 Apr 2011 07:37:39 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 09:37:39 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 Apr 2011 09:37:37 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0470FA28@XMB-AMS-107.cisco.com>
In-Reply-To: <4DB0A442.4010905@acm.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
Thread-Index: AcwAbKrVoBRI44dBSdWftn+cgFdEKQAUoWtA
References: <OF0DBCBB23.FB5BBA7F-ONC1257879.004686FB-C1257879.004FB860@Schneider-Electric.com> <4DB0A442.4010905@acm.org>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Erik Nordmark" <nordmark@acm.org>, <nicolas.riou@schneider-electric.com>
X-OriginalArrivalTime: 22 Apr 2011 07:37:39.0697 (UTC) FILETIME=[28503E10:01CC00C0]
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 07:37:41 -0000

> 
> > The TID can fit in "reserved" field of ARO/DAR/DAC and thus can come
> > at no cost.
> 
> FWIW Complexity is the true cost, because unneeded complexity leads to
> non-interoperability for no benefit.
> 
> > Thanks to the lollipop mechanism defined in 6lowpan-nd-07 the TID
can
> > be implemented even in the most constrained devices which might not
be
> > able to consistently increment the TID.
> 
> The lollipop stuff is not proven technology. It existed in an early
draft of
> OSPF, and was replaced. I assume it was replaced for a reason.
> 
[Pascal] that's FUD. 
OSPF does not use lollipop because it is not the appropriate tool, not
because it is a bad tool.
Lollipop has evolved. RPL has one that avoids the well-known pitfalls
like s1<s2<s3<s1.

> Any proven TID scheme would require stable storage on the device, so
that
> the device doesn't accidentally reuse old TIDs too soon. I don't think
we want
> to require that capability on all 6lowpan hosts, just because it is
perceived too
> hard to have RPL keep track of things.

[Pascal] Nicolas 's point exactly. If the user of the TID has an
appropriate mechanism (like a modern lollipop) then the device is
allowed to reboot and loose states. So we are not requiring persistent
memory.
And you can't just avoid something simple in the host by pushing
something undeterminably  complex in the router, because a RPL router is
usually the exact same hardware with the same constraints as the host.

Pascal