Comments on draft-yourtchenko-colitti-nd-reduce-multicast

[Erik Nordmark <[e-mail]>]

Thanks for putting this draft together. Some questions and comments below.

In section 3 you have:
* One solicited RA per host joining the network (if solicited RAs are 
sent using multicast)
That isn't entirely true. Because of the rate limiting of multicast RAs 
if a lot of hosts join at the same time, then there will be less.

In section 4.2 we can suggest an implementation that does unicast:
If we believe that the flash crowd case is still important (when we 
wrote ND the concern was around a building power failure and recovery - 
today it might be a stadium setting), then one could implement a mix as 
follows:
  - When RS received start timer.
  - If N additional RSs arrives before timer fires, then multicast one 
RA. Otherwise when timer fires unicast RAs to the received RSs.
For N=1 this is trivial.

In section 4.3 there are two suggestions: MLD snooping and L2 unicast or 
L3 multicast packets. I think there are some operational concerns around 
MLD snooping - I hope others can fill in some information in that space 
since I don't know the issues.
(Editorially it would be clearer if those two are separate sub-sections.)

The multicast-over-unicast refers to SAVI as a way to collect the state, 
but it doesn't specify where you see that state used. Presumably for DAD 
(and NS in general unless you also do section 4.7)? But SAVI doesn't 
claim to have all addresses since it is concerned with conflicts. Thus a 
host can exist and be silent - but DAD would still expect to reach it. 
Or a host could have moved to a different port and SAVI having stale 
state - yet DAD should work. My point is that the details of how the 
state is 1) maintained and 2) used to forward packets are key to 
analyzing how the neighbor discovery functionality and robustness would 
be affected by this idea.

I section 4.4 the document refers to proxy but without specifying which 
of the different proxy approaches you have in mind.
There is the proxy ND RFC, and there is the DAD proxy internet-draft in 
6man. Are you referring to one of those, or some slightly different form 
of proxy? (For example, ND proxy would respond with the LLA of the 
router/AP, but that might result in host movement looking like a 
duplicate address - again depends on the details.)

I don't have any issue with removing the somewhat arbitrary 9000 second 
max AdvDefaultLifetime in section 5.1. However, the tradeoff for what 
default lifetime to use in section 4.5 needs to take into account one 
additional factor.
The default lifetime serves to garbage collect entries from the default 
router list should a router silently disappear. Thus for links that do 
not have a fixed (set of) link-local address(es) for the router(s), 
having a high default lifetime means that after a failure the hosts 
would have one entry in the default router list which us unreachable - 
until that high lifetime expires. I don't know if there has been a study 
on the performance impact of that would have on the hosts e.g., how 
often they would re-probe the default router.

Section 4.6 has the same concern. But 4.5 and 4.6  makes lots of sense 
e.g., in a VRRP deployment where the link-local address of the virtual 
default router would always be the same. Ditto for networks with a 
single point of failure single router at a fixed address (e.g., if the 
router is always at fe80::1 or some other fixed address.) Thus I think 
we should recommend 4.5 and 4.6 that within that applicability. Added 
benefit is that the routers control it, hence the operator of the 
network can set the values higher for VRRP or single router cases.

Section 4.7 talks about limiting the table space on the hosts. But 
clearing the on-link bit in the advertised prefixes also has the benefit 
of removing any multicast NS sent from hosts for non-link-local 
destinations. And per RFC 4861 the table will be filled in by the router 
sending redirects. Thus the router can be used to control which 
addresses get in the tables on the hosts by choose whether and when to 
send the redirects (redirects with target==destination).

In think it would be good to separate out the second half of section 4.7 
(blocking link-locals) into a separate section, since it is quite 
different than clearing the on-link bit. That idea has significant 
implications since it changes the IP subnet model (RFC 4903 talks about 
this.) I not saying that we shouldn't consider this, but I do think it 
would fall in a very different category than the other ideas in this 
draft. Might even be best to have a separate draft on this radical idea 
so it can be explored fully.

4.8 seems to conflate the address assignment with DAD. Just because we 
might want to centralize the DAD checks doesn't imply that we want to 
remove the ability for the host to pick its own privacy enhanced 
interface-IDs to form its addresses.
 From a deployment perspective DHCPv6 is available for address 
assignment, but don't think we want to require that for WiFi or other 
links which have packet loss. (Packet loss occurs on wired networks as 
well, but the drop distribution is different - might happen during 
spanning tree reconvergence etc.)
Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses 
received from the DHCP server - needed since the server could be confused.

In don't understand 4.9. Should I read it as a host shutting things down 
if it goes to sleep even for a short time, and then waking up and 
multicasting a few RSs to get RAs, then multicasting a DAD probe for 
each assigned IPv6 address? If all the hosts did that then I think there 
would be more multicasts.
Note that even if the host doesn't revert to multicasting RSs, it still 
needs to be concerned about a duplicate address having arrived on the 
link while it was asleep (and not responding to any DAD probes.)

The suggestion in section 5.2 is needs a lot more work. I tried to work 
out some of these issues in section 8.9 in 
draft-chakrabarti-nordmark-6man-efficient-nd-05.
But even if we figure out how to do that without causing lots of 
unneeded RS load on the routers, in the case of your draft wouldn't the 
router(s) still need to multicast RAs at the same frequency? The 
router(s) have no way to know whether all the hosts on the link initiate 
RS to refresh RA information.

Regards,
     Erik