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

Andrew 👽 Yourtchenko <ayourtch@gmail.com> Wed, 22 July 2015 23:52 UTC

Return-Path: <ayourtch@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 0E58C1B2FB8 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 16:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 pMMOzc4HAGSc for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 16:52:40 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 2B4BE1B2FB4 for <v6ops@ietf.org>; Wed, 22 Jul 2015 16:52:40 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so194838767wib.0 for <v6ops@ietf.org>; Wed, 22 Jul 2015 16:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xkbMThrq6egFP6lHyxZDed1o0yZSrrrvlCqLMyGA/Ig=; b=WyaUOG5FDYg8xumLOe2QgvKiJx18kEreX4r8AQxJGiA5C9xH35FLCzDat5iOJhvfj5 987rxo+MQ1rYpG38HF+Ya7OUh443sKMlzjac9SKoyw/TzeM54IypzX2dHVWA8m8wZaD/ /DuXuEl6UMjpFAfPvG+QL8BrYbix/fywbz0dE96riJDH+AjhpdYX8OfzcZtRC5vPcp4v +JXIVElvFQ6r+j+rRSQMblypBrLtJhSWj0nYNzjApQwWVVjhVtsvKJenrNG7iFbgmFMV 8atnt9eKbO40/mtjET/DJMeIeI9+gCEKtL6xE5gtXb9woKwQ108hN5mtma3H6AljsZ7P zH1Q==
X-Received: by 10.194.2.161 with SMTP id 1mr9378945wjv.143.1437609158953; Wed, 22 Jul 2015 16:52:38 -0700 (PDT)
Received: from [10.77.152.93] ([188.188.93.64]) by smtp.gmail.com with ESMTPSA id r6sm24349579wiy.13.2015.07.22.16.52.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 16:52:38 -0700 (PDT)
Content-Type: text/plain; charset=windows-1251
Mime-Version: 1.0 (1.0)
From: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= <ayourtch@gmail.com>
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <ABC0E1F2-44C0-487B-A89F-565401B05CE1@delong.com>
Date: Thu, 23 Jul 2015 01:52:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <75B2DB50-4B68-43DE-BF17-013F4BCAE72A@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> <CAO42Z2z+DwOin23HQTysrZ9dNP924+LQ-vOExmJc_xZUEB4yCQ@mail.gmail.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <AA2C4CCF-CFE0-4027-AE92-21352EC93EEA@employees.org> <55B01B96.8090205@acm.org> <ABC0E1F2-44C0-487B-A89F-565401B05CE1@delong.com>
To: Owen DeLong <owen@delong.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/xu72iXCK7Ib0nTs5dRWQYCudcv4>
Cc: v6ops list <v6ops@ietf.org>, "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" <draft-yc-v6ops-solicited-ra-unicast@tools.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: Wed, 22 Jul 2015 23:52:42 -0000

> On 23 Jul 2015, at 01:14, Owen DeLong <owen@delong.com>; wrote:
> 
> 
>> On Jul 22, 2015, at 15:39 , Erik Nordmark <nordmark@acm.org>; wrote:
>> 
>> On 7/21/15 12:47 PM, Ole Troan wrote:
>>>> But in terms of implementation, isn't it simpler to always(*) respond to a RS with a unicast RA?
>>>> 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.
>>> in addition to Mark’s points.
>>> - what happens when the router reboots, will not all the hosts then try to actively reconnect?
>>>  that router could server thousands of users.
>>> - while this is intended for WIFI networks, in common deployments the WIFI interface is not integrated in the router. for the router’s perspective this just looks like another wired interface. either this has to be made configurable and not the default, or considerations of large flat wired L2 networks must also be considered.
>> 
>> Ole,
>> 
>> Even on a flat wired L2 network I don't think it is harmful to default to unicast solicited RAs.
>> 
>> If we take a worst case of 10000 hosts on the L2 network all rebooting/initializing at the same time, we will see:
>> - 10000 DAD probes for link-local address
>> - 10000 MLD joins for the solicited node MC for their link-locals
> 
> As was pointed out earlier, we shouldn’t see MLD joins for LL solicited nodes or any other LinkScoped group, unless I am badly misunderstanding things.

You will see MLD for anything that is not ff02::1. Unlike in IPv4, which does not require LL joins.

RFC3810 talks about this I think.

--a

> 
>> - 10000 RS messages(*)
>> - 1/10000 RA messages
> 
> I think you mean 1 to 10000 because I don’t think fractional messages are possible.
> 
>> - 10000 DAD probes for global addresses (N x 10000 if N prefixes on-link)
>> - N x 10000 mDNS etc type packets
>> 
>> (*) RFC 4861 suggests receiving an RA before an RS is sent, thus under some timing conditions some RS messages might be avoided.
>> 
>> But at best we seem to be talking about saving 20% of the packet during the boot of the 10000 hosts.
> 
> True… However, even if this is an actual concern, we could consider a threshold in PPS where we send an RA Mcast response.
> 
> e.g. if more than 10 RS received in 1 second, send a multicast RA.
> 
> In fact, we could probably get away with delaying an RA response to RS for 250ms. If another RS arrives during that delay, respond multicast, else unicast.
> 
> That probably still eliminates most of the RA traffic, may eliminate many of those 10000 RS messages, and could provide kind of the best of both worlds.
> I’m not sure how hard it would be to implement in silicon, however.
> 
> Owen
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops