RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Lorenzo:

Multiple subjects : )

Let me break that down in threads.

Cheers,

Pascal

From: Lorenzo Colitti [mailto:[e-mail]]
Sent: jeudi 21 novembre 2013 09:10
To: Pascal Thubert (pthubert)
Cc: Erik Kline; Ole Troan; 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

On Thu, Nov 21, 2013 at 3:40 AM, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
So clearly, as we build a multilink subnet with 802.15.4 at the edge, we must place a router - called backbone router in ISA100.11a - between the .1 and the .15.4 links. You will note that even in that case, we need the registration mechanism to perform DAD - RFC 6775 was initially designed in that context -, and that proxy ND can be used at the backbone router, as discussed in the original ML subnet draft by Dave and Christian.

If you're routing, why do you need proxy ND? Just give the 802.15.4 network a separate /64 and run 6LoWPAN ND inside it.

I think that's when Erik says "merging two link types is not the solution", that's what he means. I think he's just suggesting that you use existing standard ND in the high-powered network and existing 6LowPAN ND in the low-power network, and just route between them. That way you don't have to define a new ND protocol.

Now, WiFi does not qualify as 'a different link type' that would require routing to Ethernet; on a same AP, some clients may be low power

Well, but isn't wifi fundamentally unsuited for low-power networks anyway? It's got beacons going all the time, it has multicast, etc.

We do not want to renumber each time a device re-associates to the next AP, so we care for a rather large subnet. And there, it is not just a problem of implementing multicast at layer 2 in a fashion  that serves solicited node mcast addresses, placing the burden on another layer that, as it goes, does not have the adapted support in place...

You don't have to change ND to do that. All you need to do is either use solicited-multicast node addresses over the multicast channel or, if the subnet is SO large that ND requests are overwhelming (but that seems like a LOT of ND traffic - how many clients do you need before this starts happening?), use MLDv2 snooping and send the NS packets L2 unicast to their destination.

There is also the need for much faster DAD (not based on timing out)

What's the use case for faster DAD if you have optimistic DAD?