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

Erik Nordmark <nordmark@acm.org> Wed, 22 July 2015 22:39 UTC

Return-Path: <nordmark@acm.org>
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 60B7B1B2F3B for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 15:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 e9Ljp2BfJLGD for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 15:39:27 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 8B4EB1ACD36 for <v6ops@ietf.org>; Wed, 22 Jul 2015 15:39:27 -0700 (PDT)
Received: from [31.133.138.67] (dhcp-8943.meeting.ietf.org [31.133.138.67] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6MMdIfI026642 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 15:39:19 -0700
To: Ole Troan <otroan@employees.org>
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>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <55B01B96.8090205@acm.org>
Date: Thu, 23 Jul 2015 00:39:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <AA2C4CCF-CFE0-4027-AE92-21352EC93EEA@employees.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Sonic-CAuth: UmFuZG9tSVb8rZbpWcil2qDQ737U1lMpjoUuu5cQW+tRY3K27X2JHbRsVJZvH+JlO26fVDLQfVbHsRxTvCriTMhmPySDib1V
X-Sonic-ID: C;pkcpfcIw5RG8TYwFrKU7pA== M;LG/VfcIw5RG8TYwFrKU7pA==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/f_bs_cFmeok49mahltHgcj1vMec>
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: Wed, 22 Jul 2015 22:39:29 -0000

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
  - 10000 RS messages(*)
  - 1/10000 RA messages
  - 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.

    Erik