Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00

Anthony Schoofs <anthony.schoofs@philips.com> Mon, 28 July 2008 11:37 UTC

Return-Path: <6lowpan-bounces@ietf.org>
X-Original-To: 6lowpan-archive@megatron.ietf.org
Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D173A6880; Mon, 28 Jul 2008 04:37:03 -0700 (PDT)
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31C03A67DB; Mon, 28 Jul 2008 04:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.635
X-Spam-Level:
X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtfhRDVJ4pDn; Mon, 28 Jul 2008 04:37:00 -0700 (PDT)
Received: from gw-eur4.philips.com (gw-eur4.philips.com [161.85.125.10]) by core3.amsl.com (Postfix) with ESMTP id 331F43A683C; Mon, 28 Jul 2008 04:37:00 -0700 (PDT)
Received: from smtpscan-eur7.philips.com (smtpscan-eur7.mail.philips.com [130.144.57.172]) by gw-eur4.philips.com (Postfix) with ESMTP id BAC951A35; Mon, 28 Jul 2008 11:35:53 +0000 (GMT)
Received: from smtpscan-eur7.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 10F6BD05; Mon, 28 Jul 2008 11:37:04 +0000 (GMT)
Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur7.philips.com (Postfix) with ESMTP id E21558CD; Mon, 28 Jul 2008 11:37:03 +0000 (GMT)
Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id BC048A7; Mon, 28 Jul 2008 11:37:03 +0000 (GMT)
In-Reply-To: <1344176C-F7DF-44C9-98C6-B43EAC328A87@archrock.com>
To: Jonathan Hui <jhui@archrock.com>
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OFD30A812D.CFD4EBFF-ONC1257494.003ECC56-C1257494.003FD0AC@philips.com>
From: Anthony Schoofs <anthony.schoofs@philips.com>
Date: Mon, 28 Jul 2008 13:39:39 +0200
X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.6FP2HF30 | November 25, 2007) at 28/07/2008 13:39:42
MIME-Version: 1.0
Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: multipart/mixed; boundary="===============1518067650=="
Sender: 6lowpan-bounces@ietf.org
Errors-To: 6lowpan-bounces@ietf.org

Hi Jonathan,
I just had a quick look at your draft about Neighbor Discovery and
Autoconfiguration for Route-Over 6LoWPAN Networks. It seems very good!

- A general question: as you recall it, either the IEEE EUI-64 or short
address combined with the PAN ID may be used to generate an IID, as
specified in [RFC4944].
  Later you mention that  appropriate link-layer address can be regenerated
from the IID.
  When a node from network A receives a packet from network B, how does it
know whether the source node has used the short adress or the EUI-64
address to form the IID? I understand that you can use the U/L bit to
separate EUI-64 from short addressing usage, but will destination nodes
always have to check this U/L bit when receiving packets?

-  About the Router Advertisements, we need to make sure that they are
received by all the nodes. With respect to sensor networks constraints,
nodes may not always be able to be awake when they are multicasted. Do you
leave this issue to be solved by other means (global network time synchro,
local buffering of RAs for transmission when nodes are awake,..)?

- It is mentionned that the RAs transmission period must use the trickle
algorithm. I am not familiar with it, but it seems to me that it is not
appropriate for networks with mobile nodes. I am looking at networks where
nodes can move anytime, and we would go for short RAs periods. Is mobility
out of your document scope?

- Finally, you wrote that all 6LoWPAN nodes MUST accept the newest prefix
information. Is this a requirement? Again, I am interested in mobile nodes
and we may want to use other metrics for choosing the prefix information.

Thanks!
Best regards,
Anthony

--
Anthony Schoofs
Research Scientist
Philips Research
High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands
Email: anthony.schoofs@philips.com



                                                                           
                                                                           
                                                                           
                                                                        To 
                                       6lowpan <6lowpan@ietf.org>          
                                                                        cc 
     Jonathan Hui                                                          
     <jhui@archrock.com>                                           Subject 
                                       [6lowpan] Fwd: New Version          
     Sent by:                          Notification for                    
     6lowpan-bounces@ietf              draft-hui-6lowpan-nd-00             
     .org                                                   Classification 
                                                                           
     28-07-2008 12:07                                                      
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Feedback/suggestions welcome.

Thanks.

--
Jonathan Hui



Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> Date: July 28, 2008 2:15:48 AM PDT
> To: jhui@archrock.com
> Subject: New Version Notification for draft-hui-6lowpan-nd-00
>
>
> A new version of I-D, draft-hui-6lowpan-nd-00.txt has been
> successfuly submitted by Jonathan Hui and posted to the IETF
> repository.
>
> Filename:         draft-hui-6lowpan-nd
> Revision:         00
> Title:                        Neighbor Discovery and Autoconfiguration
for Route-Over
> 6LoWPAN Networks
> Creation_date:          2008-07-28
> WG ID:                        Independent Submission
> Number_of_pages: 24
>
> Abstract:
> This document specifies a simple version of IPv6 Neighbor Discovery
> for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover
> routers, discover network configuration parameters, and IPv6 prefixes
> for use with stateless address autoconfiguration and context-based
> 6LoWPAN compression for IPv6 headers.  This document also specifies
> autoconfiguration mechanism for use in 6LoWPAN networks.
>
>
>
> The IETF Secretariat.
>
>

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