Re: [6lowpan] lowpan-aodv draft comments

Soohong Daniel Park <soohong.park@samsung.com> Sat, 10 September 2005 03:35 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDw9W-000626-QB; Fri, 09 Sep 2005 23:35:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDw9T-0005zs-4h for 6lowpan@megatron.ietf.org; Fri, 09 Sep 2005 23:35:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00694 for <6lowpan@ietf.org>; Fri, 9 Sep 2005 23:35:35 -0400 (EDT)
Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDwCq-000333-Rh for 6lowpan@ietf.org; Fri, 09 Sep 2005 23:39:28 -0400
Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IML00AVX0MFWL@mailout2.samsung.com> for 6lowpan@ietf.org; Sat, 10 Sep 2005 12:35:03 +0900 (KST)
Received: from natpt ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IML001210MF20@mmp1.samsung.com> for 6lowpan@ietf.org; Sat, 10 Sep 2005 12:35:03 +0900 (KST)
Date: Sat, 10 Sep 2005 12:34:57 +0900
From: Soohong Daniel Park <soohong.park@samsung.com>
Subject: Re: [6lowpan] lowpan-aodv draft comments
To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>, nandakishore.kushalnagar@intel.com, itijibox-6lowpan@yahoo.com
Message-id: <005c01c5b5b8$9e014360$6dc6dba8@natpt>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <200509092203.j89M3mEx341893@jurassic.eng.sun.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
Sender: 6lowpan-bounces@ietf.org
Errors-To: 6lowpan-bounces@ietf.org

Samita, 

>  When are you planning to publish the next revision of this draft?

Obviously, you have to refer a new version here;
http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-load-adhoc-routing-01.txt
which is updating what you are refering...


Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.
----- Original Message ----- 
From: "Samita Chakrabarti" <Samita.Chakrabarti@eng.sun.com>
To: <nandakishore.kushalnagar@intel.com>; <itijibox-6lowpan@yahoo.com>
Cc: <6lowpan@ietf.org>
Sent: Saturday, September 10, 2005 7:02 AM
Subject: [6lowpan] lowpan-aodv draft comments


> Hello Gabriel and Nandu:
> 
> I have recently reviewed draft-montenegro-lowpan-aodv-00.
> 
> Here are some questions and comments:
> 
> * DYMO would be replacing AODV in future. Are we working on
>   AODV lowpan because of Zigbee compatibility or because
>   availability of experimental RFC3561 ? 
>   
> * The draft refers to *aodvbis*, but the aodvbis draft has expired.
>   Is there a plan for aodvbis draft to make progress for another RFC?
>   If that is not the case, then I am happy to see that this draft defines
>   the aodvbis format in this draft and go forward as 'lowpan-aodv' protocol.
>    Otherwise, we should follow either RFC3561 format or DYMO format.
>   
> *  The lowpan-aodv draft requires only RREQ and RREP for control data.
>     How about RERR for propagating error messages back to the sender ?
>     AFAIK, the L2 ACK failure may detect a link failure in the intermediate
>     node during a data transfer, should not it send an error message back
>     to the sender(previous node) of the packet ? 
>     Should the intermediate node do route repairing on behalf of the 
>     sender node?
>     
> *   Also, aodvbis or dymo appends intermediate node information at each
>     hop with the RREQ and RREP control packet. This increases the length
>     of the control packet unnecessarily. In IEEE802.15.4 network, these
>     additional bits are undesirable, as we know. It is a good idea that
>     lowpan-aodv draft recommends not to use additional path node information
>     on the RREQ and recommends APN-count to be zero in the RREP.
>     
>  *   The lowpan-aodv draft also needs to discuss Hostid size field values
>      for lowpan. 
>      

>  
>  Thanks,
>  -Samita
> 
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www1.ietf.org/mailman/listinfo/6lowpan
> 
> 

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan