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

Erik Nordmark <nordmark@acm.org> Wed, 22 July 2015 22:31 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 9A0651A6EE8 for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 15:31: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 AHyZhFsd3imh for <v6ops@ietfa.amsl.com>; Wed, 22 Jul 2015 15:31:28 -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 915E71A1BD1 for <v6ops@ietf.org>; Wed, 22 Jul 2015 15:31:28 -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 t6MMVJQG017907 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 15:31:20 -0700
To: Lorenzo Colitti <lorenzo@google.com>, Erik Nordmark <nordmark@acm.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> <CAKD1Yr1QD8QtR5AJ4vobkXW57RBYC-YK2qPokqk8t5UK4MuHcQ@mail.gmail.com>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <55B019B7.4030805@acm.org>
Date: Thu, 23 Jul 2015 00:31:19 +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: <CAKD1Yr1QD8QtR5AJ4vobkXW57RBYC-YK2qPokqk8t5UK4MuHcQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVZcK3LX88Tms4YOvq16pMjWshIKDMuLzaSJ9YC0XRGDaNASGC7IJi5hcj6zsdTEUkkNKuxHCYt9fXePo7UFiLsV
X-Sonic-ID: C;6ASoX8Ew5RGg/4wFrKU7pA== M;iipTYMEw5RGg/4wFrKU7pA==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/QEsMtOAuUsdr2Zs9-Pi7nUGJlHI>
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:31:29 -0000

On 7/21/15 11:35 AM, Lorenzo Colitti wrote:
> On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark <nordmark@acm.org 
> <mailto:nordmark@acm.org>> wrote:
>
>     But in terms of implementation, isn't it simpler to always(*)
>     respond to a RS with a unicast RA?
>
>
> It would be simpler to document, yes, but I don't know that we should 
> make a one-size-fits all recommendation, because there might be link 
> types or environments where this is more expensive.
I don't think we should be too prescriptive, but it sounds like we 
should at least require that routers have support for unicast solicated RAs.
One could also argue that the default should be to unicast solicited RAs.
>
>     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.
>
>
> This sort of thing can still happen. If lots of devices join at once, 
> (e.g., if something happens at a large-scale event when hundreds of 
> people pull their phones out of their pockets and turn them on at the 
> same time), it may well be cheaper for the network to send one 
> multicast RA.
>
> I'm not opposed to changing the standards as well, but I think 
> respinning RFC 4861 would require much more careful consideration than 
> simply publishing an operational guidance document such as this one. 
> Perhaps we can just recommend in this document that 6man consider this 
> operational need and consider modifying the protocol?
But the draft sort of does in suggesting the operator to enable a knob 
(unicast solicited RAs) which does not exist in many implementations 
because it isn't required. Hence you are placing requirements on 
implementations.
If a v6ops informational document gets the work done (i.e., get those 
implementations updated) then we're ok. But if we need a more forceful 
message ... then a short document which updates section 6.2.6 in RFC 
4861 isn't that difficult.

Regards,
    Erik