Re: Reducing the battery impact of ND

Erik Nordmark <> Wed, 22 January 2014 22:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 87F301A04CF for <>; Wed, 22 Jan 2014 14:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qioh6BCy3ROC for <>; Wed, 22 Jan 2014 14:03:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CE1A61A04CD for <>; Wed, 22 Jan 2014 14:03:09 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (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: <>
Date: Wed, 22 Jan 2014 14:00:05 -0800
From: Erik Nordmark <>
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 <>
Subject: Re: Reducing the battery impact of ND
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
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 <>, Erik Nordmark <>, 6man WG <>, Andrew Yourtchenko <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.