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

["Fred Baker (fred)" <[e-mail]>]

Lorenzo and Andrew:

I'm trying to figure out how to unjam the Prague agenda, and I wonder if this (very simple) draft can be sorted out on the list before the event. We already have two supportive comments. I'll note that what you describe for IPv6 is pretty common in IPv4 today - and I have it in my head it is common in IPv6 today. What I think you're saying is "please make it common if it's not".

RFC 4861, section 6.2.6, says:

   In addition to sending periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   an advertising interface.  A ROUTER MAY CHOOSE TO UNICAST THE
   RESPONSE DIRECTLY TO THE SOLICITING HOST'S ADDRESS (if the
   solicitation's source address is not the unspecified address), but
   the usual case is to multicast the response to the all-nodes group.
   In the latter case, the interface's interval timer is reset to a new
   random value, as if an unsolicited advertisement had just been sent
   (see Section 6.2.4).

emphasis mine.

Your draft says, if I may summarize in two sentences, "routers that don't send unicast RAs in response to an RS cost the network and its hosts a lot of resources" and "please send RAs unicast unless there is a good reason not to, such as a periodic RA".

Correct?

If I were to give you an agenda slot, did I just say everything (modulo perhaps a supporting graphic) that you would say?

Presuming the answer to be "yes", let me propose a short-circuit process. I would invite immediate discussion - do we agree with this? Is there an alternative viewpoint we're missing? Are there other cases the draft should address (it's primarily about mobile, but I would submit it is relevant to any shared L2 infrastructure, which could describe data centers and WiFi networks)?

BTW, chair hat off, I would suggest that your proposed configuration knob default to "send unicast", not "send multicast".  Take that as you see fit. I have been wrong before.

Given an avalanche of "yes, and let's make it a WG document, but here's a comment", I'd suggest that
 - I don't give the authors a meeting slot
 - We accept this as a working group document
 - The authors post the updated draft as draft-ietf-v6ops-solicited-ra-unicast in August
 - I run a WGLC in September
 - we ship it