Fwd: Re: Reducing the battery impact of ND

Erik Nordmark <nordmark@acm.org> Wed, 22 January 2014 22:01 UTC

Return-Path: <nordmark@acm.org>
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 E40151A038D for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 14:01:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 JX933oWqamja for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 14:01:17 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 341571A04BD for <ipv6@ietf.org>; Wed, 22 Jan 2014 14:01:14 -0800 (PST)
Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MM1Avo010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 14:01:11 -0800
Message-ID: <52E03FA6.3020806@acm.org>
Date: Wed, 22 Jan 2014 14:01:10 -0800
From: Erik Nordmark <nordmark@acm.org>
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: IETF IPv6 <ipv6@ietf.org>
Subject: Fwd: Re: Reducing the battery impact of ND
References: <52E03C9D.7010605@sonic.net>
In-Reply-To: <52E03C9D.7010605@sonic.net>
X-Forwarded-Message-Id: <52E03C9D.7010605@sonic.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;ZlXls7CD4xGtyvMsIE/FGg== M;GiwUtLCD4xGtyvMsIE/FGg==
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 22:01:19 -0000

[I don't think this made it to the list.]

-------- Original Message --------
Subject: Re: Reducing the battery impact of ND
Date: Wed, 22 Jan 2014 13:48:13 -0800
From: Erik Nordmark <nordmark@sonic.net>
To: Ole Troan <otroan@employees.org>, Lorenzo Colitti <lorenzo@google.com>
CC: Erik Nordmark <nordmark@acm.org>, Andrew Yourtchenko 
<ayourtch@gmail.com>,        6man Chairs <6man-chairs@tools.ietf.org>, 
6man WG <ipv6@ietf.org>

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