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

Mark Smith <> Fri, 17 July 2015 23:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 87EB61A903B for <>; Fri, 17 Jul 2015 16:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l8HfshdMFeHF for <>; Fri, 17 Jul 2015 16:51:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28BDB1A87A6 for <>; Fri, 17 Jul 2015 16:51:37 -0700 (PDT)
Received: by iehx8 with SMTP id x8so6726725ieh.3 for <>; Fri, 17 Jul 2015 16:51:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=nN/oB+PagahRyY9C4s7Jn/TDSVeWMYj0Ii1p9fUA3mM=; b=zxokB0wIrwB3YqSNrXYITLF5iy7VquQFUNJAk1URdPVTkgVoE9O4N7UVvtLaJKPi0d 7FcDZD53mvlCrAL5/G10VDCQkR4yPPNSV/fruSzg0pRfZUmAs3fG4YyFwujhrqB5hwpi figzEeDViGswpxFmJj6Cmw0se2iikysf/I/zvkok3j0lBE+0DMUOOjBFoAoLrbtEO3j5 qjPPye9f085F/gcVhgwp8vjy4W7V501jPaWO0dyndhDdoa90vm1+g7I7JcPyD9A3tmgA +nCcybDq8oGFz+R3sl21lDRj11xFBteA4XhzjfdC2c4OuaJTlhtuvlYqNO/0WoEWWiKJ PIvg==
X-Received: by with SMTP id u5mr77080igh.9.1437177096577; Fri, 17 Jul 2015 16:51:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 17 Jul 2015 16:51:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Mark Smith <>
Date: Sat, 18 Jul 2015 09:51:06 +1000
Message-ID: <>
To: Andrew Yourtchenko <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, v6ops list <>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jul 2015 23:51:38 -0000

On 18 July 2015 at 02:57, Andrew Yourtchenko <> wrote:
> On 17 Jul 2015, at 09:34, 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.
> values of T less than 3 seconds would make performance worse than today.
> There are many things to optimize for:
> - wireless airtime
> - bandwidth used by RAs
> - CPU usage sending unicast RAs by router
> - energy consumption on devices for more than one medium
> Some of them are orthogonal, some of them contradict each other, some of them align. People may want to optimize differently.
> I'd opt for simplicity - and use the text Erik Kline posted in another email.
> This would allow the developers to adapt for individual use cases on the spot.

I think specifically calling out the above optimisation considerations
would be good to do in this draft.

While providing flexibility is useful to cover the unexpected, I also
think it is also important to have consistency. Specific case
optimisations can be beneficial, but they're also variations and
exceptions. The more variations and exceptions there are, the more
things people have to try to understand and remember, which makes then
makes configuration and troubleshooting harder.

So, for example, it would be good to have a consistent default
behaviour for all Wifi links (likely unicast solicited RAs, because
hosts (PCs, laptops, smartphones) come and go regularly), and a
consistent default behaviour for all wired links (likely multicast
solicited RAs, because hosts (servers) don't come and go regularly, so
the recovery from power outage scenario flood of RSes is the likely
common scenario for solicited RAs).


> --a
>> _______________________________________________
>> v6ops mailing list