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

Hello Erik and Ole,

There are multiple possible deployments that require the registration mechanism. The case that you seem to refer to when "trying to merge two different link types" is probably that of  802.15.4 (aka LoWPAN), clearly a different family of MAC, 64bits address, etc.... You'll note that this is not the case that this draft addresses. Interestingly, we discussed that issue at IEEE last week, and concluded as you do here that if you connect a 802.15.4 network to a .1/.11 backbone, bridging is not the way to go between the 2 link types. 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.

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 and some will not, and we could bridge either way. The problem arises when the number of clients grow and intensifies when they move. 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... There is also the need for much faster DAD (not based on timing out) and lookup operations that do not depend on a response from a sleeping device, a need for movement detection that does not consider that 2 advertisements from 2 places mean that there are 2 routes to the same address but can differentiate up to date from stale.

DAD, lookup, scalability, fast movement ... we can address these better in ND than in a routing protocol; imagine that we need some MANET properties, plus DAD features, and at a large scale, all in a single routing protocol. So the idea here is to divide and conquer; use routing inside the .1/.11 fabric to L2R (e.g. ISIS at L2) in a fashion that leaves the L2 topology mostly stable and acceptable in scale, and then handle the L3 issues at L3 so that support for movement does not require either broadcasts or constant reachability, and can be achieved in a split second. The question that the WiND draft addresses is such L3 operation on the backbone, whatever the client is, .11, .15.4 via a router, or even a VM. We'll note that on top of enabling unicast DAD and lookup, fast mobility, and sleeping devices, the draft also allows a degree of visibility and control on the network that matches an actual demand from operators. The difference is that today, this result is obtained by snooping the multicast protocols in SAVI implementations. 

Cheers,

Pascal

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Erik Kline
Sent: mardi 19 novembre 2013 20:17
To: Ole Troan
Cc: 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

> There was moderate support to adopt this draft at the working group meeting in Vancouver.
> This is an adoption call to confirm the result of the hum at the meeting.
>
> Please provide a view with reasons as to whether the WG should adopt this or not.

I know I promised to give more detailed feedback, but time is not on my side at the moment.  Still, I'd like to say why I'm not in favor of this work.

Fundamentally, the main use case seems to be trying to merge two different link types.  One link type for low power nodes, one for "more traditional" nodes, if you will.

I think we have *routing* for this.  Merging what is really two different L2 types so that they can try to be one seemless L2 domain still doesn't feel right to me.

Just my top-level 2 cents.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------