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

Andrew 👽 Yourtchenko <ayourtch@gmail.com> Tue, 21 July 2015 09:33 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 F0AEC1B2BFB for <v6ops@ietfa.amsl.com>; Tue, 21 Jul 2015 02:33:49 -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 ljMf-rGHLYWo for <v6ops@ietfa.amsl.com>; Tue, 21 Jul 2015 02:33:48 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (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 6E0141A044D for <v6ops@ietf.org>; Tue, 21 Jul 2015 02:33:48 -0700 (PDT)
Received: by iebmu5 with SMTP id mu5so137255679ieb.1 for <v6ops@ietf.org>; Tue, 21 Jul 2015 02:33:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nx0JpWBFa6NJeoKcoi9EP9lm7Xqj7kXktsKg549gsw4=; b=wMBZ/SnxniBv0XShIcAWVTOOdejS04+SeQto0b17hi2FXpMi0ga6bfR9fXxIjOUsOB 555I/iIcCw779iakZRJ3fZZ3QxnALv3kRUFRyLLNRk6C07e34eEBXtuQ6FHpyBNm3Ccj /6nfoUnoFJ0iC6/uewk78QHYbo9xBmZZRhklkHtvgfLFCaH0Rl3oguvJZDaqT8e53pWP dcehk3Cek+Ikh54Bdg0W9gZgwquw1KdaKD1gVrXlbVgbyGPnP7OzZmzK86+8r3uxdk/s pyTCKdNEMLFN9ZxTuQtYITJ6qq06ha7pN3tl6GEfGKz9GkLBsokvE8bLf0ZupNbYiDBa Wwzg==
MIME-Version: 1.0
X-Received: by 10.107.137.154 with SMTP id t26mr43224827ioi.13.1437471227901; Tue, 21 Jul 2015 02:33:47 -0700 (PDT)
Received: by 10.107.182.7 with HTTP; Tue, 21 Jul 2015 02:33:47 -0700 (PDT)
In-Reply-To: <55AD3B64.5070400@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>
Date: Tue, 21 Jul 2015 11:33:47 +0200
Message-ID: <CAPi140P+kfpyQKzCRDA7bZQRowQx_YRcZYa85hHe64g4AvsVTg@mail.gmail.com>
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= <ayourtch@gmail.com>
To: Erik Nordmark <nordmark@acm.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/fEGuQ82s5YF_yVj5wvpDW_73BB0>
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: Tue, 21 Jul 2015 09:33:50 -0000

On 7/20/15, Erik Nordmark <nordmark@acm.org>; wrote:
> On 7/17/15 9:34 AM, Fred Baker (fred) wrote:
>>> 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.
>> If it were me implementing it, I think I would go about this in a little
>> different way, hopefully simpler. I would want to send at most one (e.g.,
>> either zero or one) RA per some interval (a second?). In the normal case,
>> that is sent unicast. However, having sent a unicast RA at time t, if I
>> now receive another RS before t+1, I send the next one (at time t+1) as a
>> multicast.
>
> First of all I support this document as a WG document.
>
> But in terms of implementation, isn't it simpler to always(*) respond to
> a RS with a unicast RA?

Yes. I did not respond on-list yet - but from operational perspective
"always send solRA unicast" / "always send solRA multicast" definitely
wins in my book, and I'd avoid premature optimizations (but maybe we
can say the implementers are explicitly free to do their own
optimizations if they see fit)

That said, will be very interesting to hear data from folks who will
run "all-unicast solRA", in real networks and then compare the effect
of their proposal optimizations on their real-world scenarios.

> 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.
>
> (*) the only case in RFC 4861 when I think a multicast response might be
> considered is when the source IPv6 address in the RS is the unspecified
> address. Further, an implementation which rate limits received RS
> packets (e.g., CoPP in a router) might also want to detect when the rate
> limit might have dropped RS packets and multicast an RA in that case.
>
>
> I do wonder why implementations haven't already changed to send unicast
> solicited RA, and whether it would make a difference if we have an

TBH that's my concern as well. I think we should tweak the text in
4861 to encourage a bit more consideration on the implementer's side.

> informational document asking them to do this. Alternatively we could
> have a proposed standard which updates section 6.2.6 to change the "MAY
> unicast" to a "SHOULD unicast".

Yeah, I actually have had the different text aimed for 6man, but
Lorenzo's concern was 6man would say "there is no protocol update
here, go away", so he rewrote it for v6ops.

We should probably discuss this at the mic and get the opinion of the
6man chairs - if there is no outright "no" on this, a normative doc
would be a better way to convince the implementers ?

>
> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.

Nice catch, thanks!

--a

>
> Thanks,
>     Erik
>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>