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

Nabil Benamar <benamar73@gmail.com> Tue, 21 July 2015 22:41 UTC

Return-Path: <benamar73@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 B80851A887C for <v6ops@ietfa.amsl.com>; Tue, 21 Jul 2015 15:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 8Hk7aewNWQ5h for <v6ops@ietfa.amsl.com>; Tue, 21 Jul 2015 15:41:45 -0700 (PDT)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 B3E501A6FCB for <v6ops@ietf.org>; Tue, 21 Jul 2015 15:41:44 -0700 (PDT)
Received: by lbbyj8 with SMTP id yj8so125445510lbb.0 for <v6ops@ietf.org>; Tue, 21 Jul 2015 15:41:43 -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=j/6wyGqN8bvgwP09wQIl0DdRvZQn0Rf9/ajNXy8BBAk=; b=R3JkP3UFo/A4droha53UPOAVz/C/Dd94LsyRog0Sd5G5jjl1PO3+TX8vWE41mjHhyf 5p/GEKHhY1EGLxANcFY5adKxsvNxr60RRYMbTBllpG/wEaIrUaJRhvqip59UhuJxAFr/ U2Uuv1eRIeCHlKIO+KMXVK+JFsHrF1R0RnrvmhB/AWW4gbRRbzUA3bNsVdQEepGMYCR6 7xd0FJSwM3Mggk/tkyNE1kzdvg4M9wCRuiChsoirKsqXddBt1LV2CKgTsG71yLUTq7PQ KpHkEplM5RT6GJ7KlKpH5hy0IkI+1/40emxkGIo3OjttJJ0x9S/nsZHisLI9OiS9XXIW ytiA==
MIME-Version: 1.0
X-Received: by 10.112.161.40 with SMTP id xp8mr35011823lbb.71.1437518503162; Tue, 21 Jul 2015 15:41:43 -0700 (PDT)
Received: by 10.25.41.146 with HTTP; Tue, 21 Jul 2015 15:41:43 -0700 (PDT)
In-Reply-To: <C5901B99-F3A7-4DB0-8216-38D95EA89D6A@delong.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> <CAPi140P+kfpyQKzCRDA7bZQRowQx_YRcZYa85hHe64g4AvsVTg@mail.gmail.com> <C5901B99-F3A7-4DB0-8216-38D95EA89D6A@delong.com>
Date: Tue, 21 Jul 2015 23:41:43 +0100
Message-ID: <CAMugd_Xox_zYv6oftPdAZVZGz+FYZo+Dm-QRSSn4pMEj-x1XjA@mail.gmail.com>
From: Nabil Benamar <benamar73@gmail.com>
To: Owen DeLong <owen@delong.com>
Content-Type: multipart/alternative; boundary=001a11c25f52bd3ad0051b6a5b26
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/NSV5W-sl68eG0UMBf7wU0qa8L0A>
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 22:41:47 -0000

Hi Folks,

I support this document which is very informative, useful and its
implementation will certainly reduce energy consumption due to excessive
Multicast RA sent. The proposed algorithm seems to be suitable for this end
!


Best regards



On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong <owen@delong.com>; wrote:

> It seems to me that the following algorithm would be relatively easy to
> implement
> and provide reasonable network optimization…
>
>
> On receipt of an RS:
>
>         if(multicast_ra_time_remaining > 15 seconds)
>         {
>           Send_Unicast_ra
>         }
>         else
>         {
>           Send_Multicast_ra
>           reset_multicast_timer
>         }
>
> In this way, if the timing is reasonably close, you multicast a packet you
> were about to send
> anyway, but if the timing isn’t close, you’re not wasting multicast
> bandwidth answering a single
> node where nobody else cares.
>
> Overall, I’ve always thought that multicast response to RS was kind of
> silly. It’s probably most
> harmful on WiFi.
>
> Owen
>
> > On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko <ayourtch@gmail.com>;
> wrote:
> >
> > 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
> >>
> >
> > _______________________________________________
> > 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
>