Subject: [v6ops] Fwd: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 20 Feb 2014 09:09:09 +0000

Erik's note is sent to 6man. The general topic of ND multicast reduction will also be discussed from an operational perspective, and the authors have asked to briefly present this as background for it. Hence, I'm forwarding Erik's excellent review. That particular conversation will likely continue on 6man and not be cross-posted, for those interested.

Begin forwarded message:

> From: Erik Nordmark <[email-masked]>
> Subject: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
> Date: February 20, 2014 8:30:27 PM GMT+13:00
> To: IETF IPv6 <[email-masked]>, Lorenzo Colitti <[email-masked]>, "Andrew Yourtchenko (ayourtch)" <[email-masked]>
> 
> 
> 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
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

	• Make things as simple as possible, but not simpler.
Albert Einstein