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

[Erik Kline <[e-mail]>]

On 17 July 2015 at 16:34, Fred Baker (fred) <[e-mail]> wrote:
>>
>> 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.
>
> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second?). In the normal case, that is sent unicast. However, having sent a unicast RA at time t, if I now receive another RS before t+1, I send the next one (at time t+1) as a multicast.

Like what happened with the Happy Eyeballs draft, I think many
strategies will be possible.  It may be best to simply document the
considerations, along with a baseline recommendation that unicast
options of some kind SHOULD be available.

I'd leave it at roughly:

    - multicast RA at least once every max_ra is still a MUST (iirc)
    - unicast RAs MAY be sent at any time, whether solicited or not
    - unicast RAs SHOULD be considered for link layers where this
helps efficiency

The exact strategy for Happy Hosts / Happy Routers (Happy Nodes?) will
likely depend on link layers and use cases, some of which have yet to
be defined.