Re: [v6ops] As promised...

Francisco Paletta <francisco@assembler.com.br> Fri, 24 July 2015 03:05 UTC

Return-Path: <francisco@assembler.com.br>
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 774931ACE3D for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 20:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 gacB2k1_icc8 for <v6ops@ietfa.amsl.com>; Thu, 23 Jul 2015 20:05:54 -0700 (PDT)
Received: from mail-vn0-f50.google.com (mail-vn0-f50.google.com [209.85.216.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 8E6BE1ACD38 for <v6ops@ietf.org>; Thu, 23 Jul 2015 20:05:53 -0700 (PDT)
Received: by vnk197 with SMTP id 197so4341507vnk.3 for <v6ops@ietf.org>; Thu, 23 Jul 2015 20:05:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tj/cz7uaBUREWZckaumRmzZaH//AAdk1q5dvyktySBg=; b=FxV7qqVTBBJfB/hJv+1/+Lb/mI8wVqKB9jMRVulhwSBXSBxEHU/vX7ZZR5qaQy6EGg xYo8yiuItv6IIOkmET79B5gAAXu5NItTcv05mVI1EeT2XtMWmYY4o7Kd9CnvGcIWG2S9 VqYs6HXiy0+jlfjz8rUkVR17OuYflRFCnBpYkcZOVWOsx522b0fCy/vQwCq0F+HseekB 6dj2pnCdRBkQZ9DO7huPoZHcfGciK0iiP5ht5VuKITYwHnf9mM+3+9VxI4p4V6E/C+h5 EqaABHn6y4RukP4S1d8938PBK1A12zRtggOVtRVlRdE788oKGgSC/SLK4L64GyIPY91Z e7cQ==
X-Gm-Message-State: ALoCoQmPuqpD1aQPFmevmXEOaBgvpxGv1lKyW73jObUqwYwQPv9cmnBgoBJYDn9RZardLcXmwOhs
X-Received: by 10.52.17.2 with SMTP id k2mr14154451vdd.15.1437707152813; Thu, 23 Jul 2015 20:05:52 -0700 (PDT)
Received: from mail-vn0-f52.google.com (mail-vn0-f52.google.com. [209.85.216.52]) by smtp.gmail.com with ESMTPSA id b7sm1449023vda.28.2015.07.23.20.05.52 for <v6ops@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 20:05:52 -0700 (PDT)
Received: by vnaa140 with SMTP id a140so4348356vna.2 for <v6ops@ietf.org>; Thu, 23 Jul 2015 20:05:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.181.6 with SMTP id ds6mr14073550vdc.60.1437707152070; Thu, 23 Jul 2015 20:05:52 -0700 (PDT)
Received: by 10.31.206.193 with HTTP; Thu, 23 Jul 2015 20:05:52 -0700 (PDT)
In-Reply-To: <D8D4E92C-FF39-4A1A-8DF7-FC6675D17F44@delong.com>
References: <E8058299-E0DF-487A-BAB5-31B7A5EAC3B9@cisco.com> <CAM86=bfaeu7T+wjYc1Xe5B2Kzkp6sDz==C0dQ9bcY0yhrBL=mA@mail.gmail.com> <D8D4E92C-FF39-4A1A-8DF7-FC6675D17F44@delong.com>
Date: Fri, 24 Jul 2015 00:05:52 -0300
Message-ID: <CAM86=bccm+hN7Sh=U6VRKV0KpfApWCpBB8B+Opof77BR88+i+Q@mail.gmail.com>
From: Francisco Paletta <francisco@assembler.com.br>
To: Owen DeLong <owen@delong.com>
Content-Type: multipart/alternative; boundary=bcaec547cbb5173379051b96488e
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/1KQ5ai_evGVfzEH9lVV5-AK7DqE>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] As promised...
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: Fri, 24 Jul 2015 03:05:57 -0000

I'm not saying I don't support the recommendation in this draft. I
acknowledge all the benefits.

I'm just saying that the motivation should not be the issues presented on
the references [1] and [2] on the doc. We can change configurations on the
routers and achieve best scenario for devices but we cannot guarantee that
in all cases, and therefore the devices need to be able to handle heavy
traffic and avoid situations like the ones referenced (normal scenarios).

Using a metaphor to compare, this is like asking to reduce a speed limit on
a road because drivers don't use safety belt. Of course there are many
safety reasons to slow down traffic speed, but should not be because people
don't want to buckle up...

Francisco

2015-07-23 23:26 GMT-03:00 Owen DeLong <owen@delong.com>om>:

> That’s sort of akin to saying “DDoS must not disrupt a device’s normal
> operation”.
>
> If you flood a link with traffic, stuff’s going to break.
>
> There are scenarios where multicast traffic can get out of control,
> including RA and related.
>
> Reducing the number of multicast RAs to those periodic ones necessary to
> refresh timers of every host on the link just makes sense.
>
> As such, I think the consequences are perfectly valid justification in
> addition to the other points raised.
>
> Owen
>
> On Jul 23, 2015, at 10:39 , Francisco Paletta <francisco@assembler.com.br>
> wrote:
>
> Hello,
>
> I believe it's a good "best practice".
>
> I just have suggestions regarding the "3. Consequences" points 2 and 3.
> Despite the fact that frequent RA messages are causing those consequences,
> they should not be used as base to support this recommendation.
>
> In my opinion, the frequency or broadness of RA messages should not cause
> a device to disrupt it's communication. The device must deal with it
> another way. Obviously they can benefit from the changes in RA messages
> behaviors. But should not be the motivation.
>
> Nevertheless I agree that once the device receives an information and have
> to deal with it, it spends power on that process and we should control that
> to favor battery-powered devices.
>
> Regards,
>
> Francisco Paletta
>
>
> 2015-07-23 10:10 GMT-03:00 Fred Baker (fred) <fred@cisco.com>om>:
>
>>
>> https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption
>>   "Reducing energy consumption of Router Advertisements", Andrew
>>   Yourtchenko, Lorenzo Colitti, 2015-07-23,
>>
>> We had quite a bit of discussion Tuesday, especially considering the
>> length (or brevity) of this draft.
>>
>> I'd suggest you read it. Especially given the number of "+2" comments on
>> the list, I tend to think we can come to consensus relatively quickly on
>> it. If there are lingering issues, let's get them out of the way.
>>
>> _______________________________________________
>> 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
>
>
>