Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt

James Woodyatt <jhw@nestlabs.com> Thu, 05 November 2015 06:00 UTC

Return-Path: <jhw@nestlabs.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A729A1B3A46 for <v6ops@ietfa.amsl.com>; Wed, 4 Nov 2015 22:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 PfmCfwKqeCKZ for <v6ops@ietfa.amsl.com>; Wed, 4 Nov 2015 22:00:17 -0800 (PST)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B952F1B3A3C for <v6ops@ietf.org>; Wed, 4 Nov 2015 22:00:17 -0800 (PST)
Received: by padhx2 with SMTP id hx2so68874477pad.1 for <v6ops@ietf.org>; Wed, 04 Nov 2015 22:00:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=3TNER+x7i9dezgtK3Xpb6WswpZzFHU589gMK2uZ78fs=; b=O1poVkR2MIxGB+aa8aKYKwjXbc7ZtlRA/2kvGDLZaFOFK/x+AQGMmt07VftTpGwSGO dYArhOyoIpUOzJ4bbEBh6Ab/MTQQ02QfPN/2DOPd2pUaLe2t3Yx5lfsjVbGoFQQizz1L DnUWGPhJvxOtLVQ2r3Ofpp1IA23XgRVuxBCmM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=3TNER+x7i9dezgtK3Xpb6WswpZzFHU589gMK2uZ78fs=; b=dUgJg+FhDGaBKfNIf2cA5A4QExqd8a3ZPIPPBe3zvhzIC6oiuR9VXE/82sCVuEZWI6 rvX9fCTsl7sEcuTIC1pv/TbH0MCfeLLFRJo54/tB1p7n4qVhQrCB86e5JQ31WC6hWcjt dOk9Zp81PAnna2ju5h/0hgQ1jCqWKTYifXAStNeD7DQAmbaU4DLNKJX63DaN7vdTTo2x GJv7MzLdGSWpu3hfTSjSzgT64ILawxaQXqSK4Zki59QJoCDxuW0HLTeZkwlZF2sGg+uD 3cuNcHPy6rmRKRwkxJVwm9mklicMKESDQyj1yCxys/6RNrWt/9iWonNv8dhxXdm0aFmn 6C2g==
X-Gm-Message-State: ALoCoQmDgsu3uwPz56ZOOuEjDU1tL0+W+R2sJJ2OQZAlL6RfNICLaVRHe3ODZD6PuRMrkOB8Sc1iS1B1w7s7kcntH/mj0x2ve0PV6NyZ9ugVWE4wtf31RdDRN0KLCrMX+35LvWNo+sCNJeC5ixdxFMCX3onFSYz7JVzUuMyOUcIuv9oPoPbVLvw=
X-Received: by 10.67.13.206 with SMTP id fa14mr7178693pad.143.1446703217329; Wed, 04 Nov 2015 22:00:17 -0800 (PST)
Received: from t20010c4000003024bcdd43682b0b79a2.v6.meeting.ietf94.jp (t20010c4000003024bcdd43682b0b79a2.v6.meeting.ietf94.jp. [2001:c40:0:3024:bcdd:4368:2b0b:79a2]) by smtp.gmail.com with ESMTPSA id rn7sm5490505pab.23.2015.11.04.22.00.16 for <v6ops@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 22:00:16 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: James Woodyatt <jhw@nestlabs.com>
In-Reply-To: <563AB521.8000309@acm.org>
Date: Thu, 05 Nov 2015 15:00:13 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <714D355E-81FA-4D5D-95CA-BF3FE15C17C1@nestlabs.com>
References: <20151001150947.6527.30286.idtracker@ietfa.amsl.com> <CAKD1Yr3Xw=ddZieF0OzU=wyqs2P5WXvRh8CXn1S2qS6WEZmb9A@mail.gmail.com> <E616A912-FC4D-4EBE-ABFA-17CD60CC5D79@cisco.com> <563AB521.8000309@acm.org>
To: "v6ops@ietf.org WG" <v6ops@ietf.org>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/oIIPM1gret2oq1qCJ3l-LxsmITA>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 06:00:22 -0000

On Nov 5, 2015, at 10:47, Erik Nordmark <nordmark@acm.org> wrote:
> 
> I had reviewed draft-ietf-v6ops-reducing-ra-energy-consumption-00 and fully agreed with the the recommendations in section 4 about implementation and configuration of routers.
> 
> However, in 01 there was a section added (4.2 - now 5.2) with device side recommendations/requirements, with with I have serious reservations at several levels:
> 1. The text uses terms like "maintain IPv6 connectivity" and "disconnect from the IPv6 network" which are not defined. I would not know what impact this has on an implementation with those terms being defined. E.g., does "disconnect" mean to discard all IPv6 addresses and prefixes and release all DHCPv6 leases? Kill all connections? What?

I had to talk verbally with Lorenzo before I understood this properly that A) “maintain IPv6 connectivity” means to delegate either an internal or an external sleep proxy with the task of remaining “reachable” under NUD, e.g. the ECMA ProxyZzzz service or the Bonjour Sleep Proxy service, and that B) “disconnect from the IPv6 network” means to detach from the link, thereby leaving the set of “reachable” nodes under NUD and entailing the commission of the DNAv6 procedure (RFC 6059) when the host reawakens and reattaches to the link.

Perhaps some wordsmithing would be in order, to use terminology more in keeping with the language of RFC 6059.

> 2. Section 5.2 changes (or at least clarifies) the IPv6 standards which seems to not be in scope in the v6ops charter.
> 
> Thus I think section 5.2 should be removed and that discussion be had in the 6man WG.


I’m opposed to that suggestion. The practice described in section 5.2 is necessary today for dealing with behavior of deployed networks that conform to existing standards. If 6MAN wants to clarify or improve the ND6 specification to change the need for the behavior documented here, then that would be splendid, but please count me on the list of people who prefer not to wait for the deliberations in 6MAN to resolve successfully before a practical solution to real world problems can be applied.


—james