Re: Reducing the battery impact of ND

Erik Nordmark <nordmark@acm.org> Wed, 22 January 2014 22:03 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 87F301A04CF for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 14:03:10 -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 Qioh6BCy3ROC for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 14:03:09 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id CE1A61A04CD for <ipv6@ietf.org>; Wed, 22 Jan 2014 14:03:09 -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 s0MM05FH009334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 14:00:06 -0800
Message-ID: <52E03F65.5030700@acm.org>
Date: Wed, 22 Jan 2014 14:00:05 -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: Ole Troan <otroan@employees.org>
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> <52E03C9D.7010605@sonic.net> <6D5AD847-30B2-467A-87B6-31C089C9380F@employees.org>
In-Reply-To: <6D5AD847-30B2-467A-87B6-31C089C9380F@employees.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;trkbjbCD4xGd1/MsIE/FGg== M;cLtQjbCD4xGd1/MsIE/FGg==
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 22:03:10 -0000

On 1/22/14 1:52 PM, Ole Troan wrote:
> 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.

That would only be true if resilent-rs claims that no periodic 
unsolicited RAs are needed. I don't see any such text in the protocol 
specification in that draft (section 2-4). The introductory text talks 
about scenarios, and perhaps that scenario text doesn't match what the 
proposed protocol actually does?

Thus the document needs to be more clear.

Regards,
    Erik