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

Mark Smith <markzzzsmith@gmail.com> Thu, 16 July 2015 09:50 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8E1A87F1 for <v6ops@ietfa.amsl.com>; Thu, 16 Jul 2015 02:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixDWJFrXdPEi for <v6ops@ietfa.amsl.com>; Thu, 16 Jul 2015 02:50:17 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522391A6FF2 for <v6ops@ietf.org>; Thu, 16 Jul 2015 02:50:17 -0700 (PDT)
Received: by ieik3 with SMTP id k3so52439995iei.3 for <v6ops@ietf.org>; Thu, 16 Jul 2015 02:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zl9JQgnADIm4qOj/R42ug/aQxKg7otFLeCFToM3smDo=; b=EB02r00ndMR5osHInHfwa0dGcc2mJE83mOnIDaSIT9SPb4/Y5S05wfY7O3qpNQ/glB L5yoeNSCPBmjUE97bK+laYqf3tmU5DJPrrMOI+9LwLjZPbhZ8Ce9XxR4iaIZ2txoY3tq jrn5XMUVNnhXlBbnb9OzLlYKeKSP846iyldEb29+Ogct4kD9ATaQl/ZJPYnybEo2AMWt mGX+NIWr4ishdi/ExGrZuw6EVxJpXsCZqyJNh3UhwW4SfbNEPQwPdULt7pZmRao9heA7 zNtmw4r1lrrKYm7cocMGVRJxXTm34aR5TthPWGrwR9yL0DApvXZwiHlKhQPIwMtzoLuP YUBw==
X-Received: by 10.50.109.138 with SMTP id hs10mr2958953igb.48.1437040216854; Thu, 16 Jul 2015 02:50:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.205.5 with HTTP; Thu, 16 Jul 2015 02:49:47 -0700 (PDT)
In-Reply-To: <CAO42Z2w3fOxGJHasKqYZRfGZ2u=7FnZBm+jgLtgDvfZ7HYW=iw@mail.gmail.com>
References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <CAO42Z2x7mNFbB_w_+W+80pY+LeCAKXaOBXMmQvkcaMSWhwW60g@mail.gmail.com> <EF21B630-5D0A-415A-A93F-9058900CC80C@cisco.com> <CAO42Z2zAqMXhBZ2wa=q0wtHGhMpMWU9TSjfFyd2quiki9w0oSw@mail.gmail.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <CAO42Z2w3fOxGJHasKqYZRfGZ2u=7FnZBm+jgLtgDvfZ7HYW=iw@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 16 Jul 2015 19:49:47 +1000
Message-ID: <CAO42Z2z+DwOin23HQTysrZ9dNP924+LQ-vOExmJc_xZUEB4yCQ@mail.gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ytpq00hk4-UfXeQcfFYQCXx9VIw>
Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" <draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org>, v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2015 09:50:18 -0000

On 16 July 2015 at 19:18, Mark Smith <markzzzsmith@gmail.com>; wrote:
> Hi Fred,
>
> On 16 July 2015 at 18:23, Fred Baker (fred) <fred@cisco.com>; wrote:
>>
>>> On Jul 16, 2015, at 10:15 AM, Mark Smith <markzzzsmith@gmail.com>; wrote:
>>>

<snip>

>
> "A unicast response may be delayed, and a multicast
>    response must be delayed, for a small random interval not greater
>    than MAX_RESPONSE_DELAY, in order to prevent synchronization with
>    other responding routers, and to allow multiple, closely-spaced
>    solicitations to be answered with a single multicast advertisement."
>
> In 1991, hosts were pretty much mains powered, fixed location and
> wired, so they could all rush to send multicast RSes after a mains
> power outage or the 10BASE2 cable broke and was then fixed, and they
> wouldn't have come and gone much from the link either. A single
> multicast RA in response to the first RS in a flood of them could have
> caused a lot of later RSes to be suppressed.
>

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.