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

[Mark Smith <[e-mail]>]

On 21 July 2015 at 19:35, Lorenzo Colitti <[e-mail]> wrote:
> On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark <[e-mail]> wrote:
>>
>> But in terms of implementation, isn't it simpler to always(*) respond to a
>> RS with a unicast RA?
>
>
> It would be simpler to document, yes, but I don't know that we should make a
> one-size-fits all recommendation, because there might be link types or
> environments where this is more expensive.
>
>> 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.
>
>
> This sort of thing can still happen. If lots of devices join at once, (e.g.,
> if something happens at a large-scale event when hundreds of people pull
> their phones out of their pockets and turn them on at the same time), it may
> well be cheaper for the network to send one multicast RA.
>

Actually I've witnessed these sorts of events in recent times - when
1000s or 10s of 1000s of residential broadband subscribers come back
on-line after the BRAS/BNG has booted either due to failure or
maintenance, or the backhaul infrastructure between the BRAS/BNG and
subscribers has failed and recovered.

Unicast RAs in the specific scenarios I've seen it in though may not
have helped, as the subscribers were attached via individual PPPoE
sessions, so multicasting a single RA to many/all of them efficiently
might not be possible, unless there was some fancy hardware/firmware
that meant the control plane didn't have to do it.

However, if single link/multi-access methods of attaching subscribers
are used e.g., TR-101 N:1 VLAN, then solicited multicast RAs would
help significantly reduce the number of multicast RSes from CPE during
these events.

> I'm not opposed to changing the standards as well, but I think respinning
> RFC 4861 would require much more careful consideration than simply
> publishing an operational guidance document such as this one. Perhaps we can
> just recommend in this document that 6man consider this operational need and
> consider modifying the protocol?