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

[Mark Smith <[e-mail]>]

On 16 July 2015 at 19:18, Mark Smith <[e-mail]> wrote:
> Hi Fred,
>
> On 16 July 2015 at 18:23, Fred Baker (fred) <[e-mail]> wrote:
>>
>>> On Jul 16, 2015, at 10:15 AM, Mark Smith <[e-mail]> wrote:
>>>

<snip>

>
> "A unicast response may be delayed, and a multicast
>    response must be delayed, for a small random interval not greater
>    than MAX_RESPONSE_DELAY, in order to prevent synchronization with
>    other responding routers, and to allow multiple, closely-spaced
>    solicitations to be answered with a single multicast advertisement."
>
> In 1991, hosts were pretty much mains powered, fixed location and
> wired, so they could all rush to send multicast RSes after a mains
> power outage or the 10BASE2 cable broke and was then fixed, and they
> wouldn't have come and gone much from the link either. A single
> multicast RA in response to the first RS in a flood of them could have
> caused a lot of later RSes to be suppressed.
>

So the next logical thing to do would be to have the router default to
unicast Router Advertisements, measure the rate of received Router
Solicitations, and switch to multicast RA mode past a certain
threshold to cover this sort of situation. Once the number of RSes
falls, it switches back to unicast RA mode.

That would get rid of the configuration knob proposed in this ID, and
is behaviour that I think could be universal for all link types,
rather than just for the case of wireless ones with mobile devices.