Re: Reducing the battery impact of ND

Ole Troan <otroan@employees.org> Wed, 22 January 2014 21:52 UTC

Return-Path: <otroan@employees.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 853FC1A0445 for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 13:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] 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 PR62ojXN7Tgs for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 13:52:41 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id E16BD1A02F0 for <ipv6@ietf.org>; Wed, 22 Jan 2014 13:52:40 -0800 (PST)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 2C19E5FF3; Wed, 22 Jan 2014 13:52:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=h3ZxLjBv8J3RBH9TwPIuD MW7Ju0=; b=d095koerL+9rAf45u74+w/kKZJmRxLF0+dV1JJKXWhm33YNzey/d7 iDd9OUPGEweEAlX9bS18T2zq+XeV4ITheAW1MjfLzM0mzkPGrPTIb8HXQZ7XeWhl xdX6I13SLpXMi5Z7RV9L+oVRUERjtPzqII8PljoUvgO+mypgYVISRw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=MnnP3MgTdNVAGdE j34e0Y0sWQUd8xFx/ubsHUSrq1UBueQLIZtUyEB6hV9rAetl6eK/yVWwn0X91wk3 Q/PwkZMNVzW6HqD0BuxbpOnjbd+Ju/huoppepkA/IjDReakIdHNVre2C9X1ssnwm cCymWEISH5GWVPBoR90YVNcZ1Eeo=
Received: from dhcp-10-61-97-137.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id EEEF55FC9; Wed, 22 Jan 2014 13:52:36 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C8F506DF-A2EE-41C9-BD05-60481F2A1D87"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Reducing the battery impact of ND
From: Ole Troan <otroan@employees.org>
In-Reply-To: <52E03C9D.7010605@sonic.net>
Date: Wed, 22 Jan 2014 22:52:33 +0100
Message-Id: <6D5AD847-30B2-467A-87B6-31C089C9380F@employees.org>
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> <52E03C9D.7010605@sonic.net>
To: Erik Nordmark <nordmark@sonic.net>
X-Mailer: Apple Mail (2.1827)
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Erik Nordmark <nordmark@acm.org>, 6man WG <ipv6@ietf.org>, Andrew Yourtchenko <ayourtch@gmail.com>
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:52:42 -0000

Erik,

>>>     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.

the first reading implies that the host looses connectivity after router lifetime seconds.
"never sent" doesn't leave much room for interpretation.

>>> 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.

cheers,
Ole