Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

[Owen DeLong <[e-mail]>]

> On Jul 22, 2015, at 15:39 , Erik Nordmark <[e-mail]> wrote:
> 
> On 7/21/15 12:47 PM, Ole Troan wrote:
>>> But in terms of implementation, isn't it simpler to always(*) respond to a RS with a unicast RA?
>>> As background, the text in RFC4861 comes from the old concern that all devices might boot at the same time when the power is re-established after a building power failure; that doesn't happen since most devices (laptops, smartphones, IoT devices) have batteries today. In that case it might have made sense to sending fewer RA messages by using multicast.
>> in addition to Mark’s points.
>>  - what happens when the router reboots, will not all the hosts then try to actively reconnect?
>>    that router could server thousands of users.
>>  - while this is intended for WIFI networks, in common deployments the WIFI interface is not integrated in the router. for the router’s perspective this just looks like another wired interface. either this has to be made configurable and not the default, or considerations of large flat wired L2 networks must also be considered.
>> 
> 
> Ole,
> 
> Even on a flat wired L2 network I don't think it is harmful to default to unicast solicited RAs.
> 
> If we take a worst case of 10000 hosts on the L2 network all rebooting/initializing at the same time, we will see:
> - 10000 DAD probes for link-local address
> - 10000 MLD joins for the solicited node MC for their link-locals

As was pointed out earlier, we shouldn’t see MLD joins for LL solicited nodes or any other LinkScoped group, unless I am badly misunderstanding things.

> - 10000 RS messages(*)
> - 1/10000 RA messages

I think you mean 1 to 10000 because I don’t think fractional messages are possible.

> - 10000 DAD probes for global addresses (N x 10000 if N prefixes on-link)
> - N x 10000 mDNS etc type packets
> 
> (*) RFC 4861 suggests receiving an RA before an RS is sent, thus under some timing conditions some RS messages might be avoided.
> 
> But at best we seem to be talking about saving 20% of the packet during the boot of the 10000 hosts.

True… However, even if this is an actual concern, we could consider a threshold in PPS where we send an RA Mcast response.

e.g. if more than 10 RS received in 1 second, send a multicast RA.

In fact, we could probably get away with delaying an RA response to RS for 250ms. If another RS arrives during that delay, respond multicast, else unicast.

That probably still eliminates most of the RA traffic, may eliminate many of those 10000 RS messages, and could provide kind of the best of both worlds.
I’m not sure how hard it would be to implement in silicon, however.

Owen