Re: [6lowpan] Fwd: New Version Notificationfordraft-chakrabarti-6lowpan-ipv6-nd-simple-00

"Mathilde Durvy (mdurvy)" <mdurvy@cisco.com> Tue, 23 March 2010 14:41 UTC

Return-Path: <mdurvy@cisco.com>
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 6435C3A6A13 for <6lowpan@core3.amsl.com>; Tue, 23 Mar 2010 07:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.869
X-Spam-Level:
X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8]
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 Wd77Nz+G6ZAB for <6lowpan@core3.amsl.com>; Tue, 23 Mar 2010 07:41:24 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 068F83A69A4 for <6lowpan@ietf.org>; Tue, 23 Mar 2010 07:41:23 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: smime.p7s : 4235
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAAAF9wqEuQ/uCWe2dsb2JhbACbLBUBAQsLJAYcol+ZIYR9BA
X-IronPort-AV: E=Sophos; i="4.51,295,1267401600"; d="p7s'?scan'208"; a="58436031"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2010 14:41:41 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2NEffQ6007840; Tue, 23 Mar 2010 14:41:41 GMT
Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 15:41:41 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 23 Mar 2010 15:41:39 +0100
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0150_01CACA5C.4609A680"
Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE01A58E8C@XMB-AMS-103.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0180DBC4@XMB-AMS-107.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [6lowpan] Fwd: New Version Notificationfordraft-chakrabarti-6lowpan-ipv6-nd-simple-00
Thread-Index: Acq5RIljm1ULao1BR22YIuVOVqa5jQQmi38AAAz3dIAAIJmOcA==
References: <4B8BBE45.4080402@sun.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01A589F8@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0180DBC4@XMB-AMS-107.cisco.com>
From: "Mathilde Durvy (mdurvy)" <mdurvy@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Erik Nordmark <erik.nordmark@sun.com>, 6lowpan <6lowpan@ietf.org>
X-OriginalArrivalTime: 23 Mar 2010 14:41:41.0787 (UTC) FILETIME=[F3CFD6B0:01CACA96]
Subject: Re: [6lowpan] Fwd: New Version Notificationfordraft-chakrabarti-6lowpan-ipv6-nd-simple-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/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: Tue, 23 Mar 2010 14:41:25 -0000

Hi Pascal,

Thanks for your answer.

> - Section 7.3: I feel like you are underestimating the role that the 
> routing protocol might play. If you take the example of what RPL is 
> defining, an
> IPv6 host could very well be a RPL leaf node, in which case it might 
> discover its default router by listening to DIO messages, and send DAO 
> to 'register'. In addition, if the 6LR are RPL routers that use DHCPv6 
> or another scheme for address allocation, RS/RA might be completely
disabled.
[Pascal] 
The classical way is that the routing protocol operates between routers. ND
provides the abstraction for a host to locate and interact with its router.
This is why in the current WG doc, the registration also belongs to ND. 
[Mathilde]
What you are saying makes sense. Although in 4861 the host is not really
registering with the router it is just discovering it. Hence, it is a host
-> router relationship but the opposite is not quite true, the router does
not use ND to route to the host (at least for off-link prefixes)... 

[Pascal]
Based on the registration, it is up to the router to redistribute the
information in the route-over protocol, whether that is RPL or something
else. If we lose the ND registration capability, we end up forcing every
host attached to a RPL network  to support RPL. Don't you feel that's wrong?
[Mathilde]
At this stage I don't know if this is right or wrong, but I would like to
understand what RPL is assuming? It's not so clear in the draft... Maybe it
relates to the questions that were asked on the role of leaf nodes during
the WG meeting yesterday.

Best,
Mathilde