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

On 7/20/15, Erik Nordmark <nordmark@acm.org> wrote:
> On 7/17/15 9:34 AM, Fred Baker (fred) 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.
>
> First of all I support this document as a WG document.
>
> But in terms of implementation, isn't it simpler to always(*) respond to
> a RS with a unicast RA?

Yes. I did not respond on-list yet - but from operational perspective
"always send solRA unicast" / "always send solRA multicast" definitely
wins in my book, and I'd avoid premature optimizations (but maybe we
can say the implementers are explicitly free to do their own
optimizations if they see fit)

That said, will be very interesting to hear data from folks who will
run "all-unicast solRA", in real networks and then compare the effect
of their proposal optimizations on their real-world scenarios.

> 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.
>
> (*) the only case in RFC 4861 when I think a multicast response might be
> considered is when the source IPv6 address in the RS is the unspecified
> address. Further, an implementation which rate limits received RS
> packets (e.g., CoPP in a router) might also want to detect when the rate
> limit might have dropped RS packets and multicast an RA in that case.
>
>
> I do wonder why implementations haven't already changed to send unicast
> solicited RA, and whether it would make a difference if we have an

TBH that's my concern as well. I think we should tweak the text in
4861 to encourage a bit more consideration on the implementer's side.

> informational document asking them to do this. Alternatively we could
> have a proposed standard which updates section 6.2.6 to change the "MAY
> unicast" to a "SHOULD unicast".

Yeah, I actually have had the different text aimed for 6man, but
Lorenzo's concern was 6man would say "there is no protocol update
here, go away", so he rewrote it for v6ops.

We should probably discuss this at the mic and get the opinion of the
6man chairs - if there is no outright "no" on this, a normative doc
would be a better way to convince the implementers ?

>
> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.

Nice catch, thanks!

--a

>
> Thanks,
>     Erik
>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>