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

Ole Troan <otroan@employees.org> Thu, 23 July 2015 11:41 UTC

Return-Path: <otroan@employees.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 0B1EF1A89B3 for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 04:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 MlwusE2o6nzs for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 04:41:20 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8A21A854B for <v6ops@ietf.org>; Thu, 23 Jul 2015 04:41:20 -0700 (PDT)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 1627961CB; Thu, 23 Jul 2015 04:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=FwUbZPH+Vomc01ZoqKFC1SoCUII=; b= RSDwkAkICO0a5nuvK6A9lTJ5SKmRWMiGOHq6dv+SC7CbNVpBl2k8WDxpZx3V4JZG 85O7acgYNps1cdC8ckJ8lbnLhk39hKh35RugVvfZzgeLdAKAeM2dIoZaYjxriFdD SemegehX36tWdVuUGs1J7NIfMOVAFComCsB9DoWWmk0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=apq4kpf3oRrvCx8t3K9dK+tdof 3PRU8PEXy7MR/eLoDz7WU0TzjzVVIyMciGVwHnkT3y4Qoo/+nktLu5zUCheenXug fHlh6qcuklOLXvQRdasQn5q2Lc8FxxCMlBXNY+X/+TBtDtNyB5wXGD5HsQw00wAd LBCVKSCwozKYZGM0s=
Received: from gomlefisk.localdomain (dhcp-a290.meeting.ietf.org [31.133.162.144]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 8DBDC61C9; Thu, 23 Jul 2015 04:41:18 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 16B07498C400; Thu, 23 Jul 2015 04:33:11 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: multipart/signed; boundary="Apple-Mail=_C48BE15C-F464-42C1-B01B-8F4A415623A8"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Ole Troan <otroan@employees.org>
In-Reply-To: <ABC0E1F2-44C0-487B-A89F-565401B05CE1@delong.com>
Date: Thu, 23 Jul 2015 04:33:10 -0700
Message-Id: <47B242F5-FFE7-4D68-8C22-968D044F532B@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> <55B01B96.8090205@acm.org> <ABC0E1F2-44C0-487B-A89F-565401B05CE1@delong.com>
To: Owen DeLong <owen@delong.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/IXst7DsJEezL760xmASDQTso1sQ>
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: Thu, 23 Jul 2015 11:41:22 -0000

Owen,

>> 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.

a quick wireshark on the IETF wireless shows lots of MLD for solicited node multicast addresses as well as other link-scoped addresses.

we put that in there under the assumption that we needed to, to deal with MLD snooping switches. I’m not sure that assumption held true.

>> - 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.

the issue isn’t necessarily link-utilisation.
there are router control planes that would rate-limit 10000 RS messages / second. I agree with Owen and I don’t think we can make a blanket statement that RS replies should always be unicast.

cheers,
Ole