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

[Dan Luedtke <[e-mail]>]

Hi,

I know I am too late to make any significat contribution but I like to
express why I think this draft is only the second best solution to the
problem.

A switch should not send a solicited node multicast packet to all
connected devices but only to those which's hardware address matches
the last 24 bit. In case of non-EUI64 addresses (e.g. Privacy
Extensions), the node has previously joined the solicited node
multicast groups matching the last 24 bit of its addresses. A switch
should track the corresponding MLD messages and thus be able to
transmit the multicast message only to the affected ports. Not every
multicast message on network layer has to become a broadcast message
on link layer. In fact, most switches just flood out multicast packets
on all ports, but I see more of a switch issue here than a protocol
flaw in NDP.
IMHO this is a problem on the link layer and should not lead to quirks
or increase of complexity in network layer protocols.

On wireless links the situation is probably very different and the
wakeup of nodes heavily depends on how many multicast addresses the
hardware can listen to without waking up CPU and driver software. My
understanding is that there is some kind of hardware filtering before
the OS stack gets notified.

I also dislike the idea of centralizing the network management by
using a single instance (the router) for node registration. It's
probably more a personal thing but to me a network seems more reliable
if the nodes "defend" their addresses themselves via DAD.

Here are my comments:

Section 1.2:
> EUI-64 identifiers are recommended as unique Interface Identifiers,
> however if the network is isolated from the Internet, uniqueness of
> the identifiers may be obtained by other mechanisms such as a random
> number generator with lowest collision rate.
Does this collide with draft-gont-6man-deprecate-eui64-based-addresses-00?

Section 3.:
> An EUI-64 interface ID required for global
> communication.
See above.

Section 9:
> A legacy IPv6 Host compliant EAH SHOULD be able to fall
> back to RFC 4861 host behavior if there is no efficiency-aware router
> (NEAR) in the link.
I would like to see a MUST here instead of a SHOULD. The definition of
"legacy compliant" implies being able to fall back. Did I miss the
point here?

Section 10.2:
> The new default
> router then first sends a NS to its peers with a link scope multicast
> message to IPv6 address ff02::2 with the ARO option.
Just bikeshedding, sorry, but I would like to see "all link-local
routers multicast address" instead of the constant ff02::2.


Section 20:
> MIN_DELAY_BETWEEN_RAS(CHANGED)          1 second
Wow. I consider this a big change! What is the reason for chosing 1
second? We are not speaking of periodic RA, right? Then why wait a
second between two unicast RA, it does slow down things. For example
massive movement of mobile clients from one wifi to another. Happens
on conferences sometimes :)
Again, I might miss the point here since I had not the time to get to
know this draft earlier.


Some possible minor typos?!:
> intermediate devices include Wireless Controllers that terminate a
> overlay tunnel
typo: an overlay

> o  In a datacenter, where VM mobility and VM address reslution also
typo: resolution

Regards,

Dan


-- 
Dan Luedtke
http://www.danrl.de