Re: Reducing the battery impact of ND

Erik Nordmark <nordmark@sonic.net> Wed, 22 January 2014 21:48 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8681A0451 for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 13:48:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] 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 UVnNpaNWsTkV for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 13:48:37 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id ABA281A0111 for <ipv6@ietf.org>; Wed, 22 Jan 2014 13:48:37 -0800 (PST)
Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MLmDbW017286 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 13:48:14 -0800
Message-ID: <52E03C9D.7010605@sonic.net>
Date: Wed, 22 Jan 2014 13:48:13 -0800
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ole Troan <otroan@employees.org>, Lorenzo Colitti <lorenzo@google.com>
Subject: Re: Reducing the battery impact of ND
References: <CAKD1Yr29S=O5L4DfhNoiVieWPkgBJ2veuOu6ig5rwgK4ELz7Xw@mail.gmail.com> <52D96663.6060005@sonic.net> <CAKD1Yr3pCQ15uFz36MvKG3Q_Vzt27ws0aG1=94377FFaJtWV7g@mail.gmail.com> <52DA0ABA.8030903@acm.org> <CAKD1Yr1zSfAOv8j9XgB_ph9uaUUNW0yrJhfjJTsSTYHNKYNx9A@mail.gmail.com> <F34BE236-AB15-4D33-9968-B8C7B04A2572@employees.org>
In-Reply-To: <F34BE236-AB15-4D33-9968-B8C7B04A2572@employees.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;hBbS5K6D4xGGksecJ1f4WQ== M;EOvu5K6D4xGGksecJ1f4WQ==
X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Erik Nordmark <nordmark@acm.org>, Andrew Yourtchenko <ayourtch@gmail.com>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 21:48:39 -0000

On 1/21/14 2:35 PM, Ole Troan wrote:
> Lorenzo,
>
>>      One of your "yes please" below is a change to ND - Andrew's b) about
>>      restarting RS would require a (small) standards update.
>>
>>
>> We should try to get that into draft-6man-resilient-rs.
>>
>> It seems to be out of scope for the problem resilent-rs set out to solve which was loss issues for the initial RS. It might not be wise to expand that drafts scope to also cover (part of) efficient-nd.
>
> the abstract has the following text:
>     "Furthermore, on some links, unsolicited multicast
>     Router Advertisements are never sent and the mechanism in this
>     document is intended to work even in such scenarios."

I think that text can be read in different ways.

One way is within the scope of the  initial configuration (which is what 
the RSs are for) is robust even if there are no unsolicited multicast RAs.

Another way is that the document intended to get rid of the need for 
unsolicited multicast RAs.

Based on the title, name, and content of the document, my conclusion is 
that the first reading is much more accurate.

>> To my mind, sending an RS when the RA lifetime is about to expire is a robustness fix, not an efficiency fix. In a world where IPv6 is optional and IPv4 is the main protocol, just having your IPv6 address expire is not necessarily a problem. But in a world where IPv6 is the main protocol, then hosts will probably want to try harder to keep their IPv6 address around.
>
> I believe you have found a bug in the resilient-rs draft.
> could you reply to the WGLC thread for that document and notify the authors?

It makes sense having the document be clear on its scope, so some 
clarification is in order.

Regards,
    Erik