Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04

Ted Lemon <mellon@fugue.com> Tue, 20 October 2020 22:23 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id E17473A1433; Tue, 20 Oct 2020 15:23:27 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0E33A1428 for <xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com>; Tue, 20 Oct 2020 15:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 mN1HZHUcG8Sj for <xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com>; Tue, 20 Oct 2020 15:23:25 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 230CC3A1437 for <draft-ietf-v6ops-slaac-renum.all@ietf.org>; Tue, 20 Oct 2020 15:23:24 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id h12so475115qtu.1 for <draft-ietf-v6ops-slaac-renum.all@ietf.org>; Tue, 20 Oct 2020 15:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=k1+08mZfCJe2uQIeC9I671DLbKf2gBrK/YoS4WqvgH11hrel/FNgKknuMlBMntazQs aI555tq4LSyCLK5rOyNYI00pMBMopjVvyuthRSTH9OBJlFmncBvwYTDq+I5yWSwcPjow Qf7PSZ3hkTqv/KFVAt9VJqo6+8t9wWjuxF43m3nPii830E4nM1bwoyio1rNxefvRzF8b HLIfuK6iqePNGtiyMIl2Du6IKCXze/psgnq5FJuKJ17qN/DyIAON4CoOpEN3uYkh6oqG XokjAnSbmGR3s65vJ/A07rQaMNz0ZHkgZojVF6YVBkOezMYg2lbUXUMcsKENn4Hwj1ya yHew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=lKhzMmI9IM9TlAJRg1eVahPUb2OufKuGoWcueUkPbt8xx4CzR9YMdTsWtE9qFPFiVQ nmI4stsVfuUPnDIax0CoxfBvoTteUtr5LjFZNkyTr1kkjEbCh0XM/v8WuiXNbCUuvF0i c05oWMTrnuEfAN/rr2wFRQBXeEIMI7AUuqa1xqyBa6RFWVjQuIqR6NHd5KQbrV/rMP6A W9PggrDsDMG1XbBPfBvX8RVPq6KarASIGZcc3oMST1uApqOiO1NiWBlDFfEzpwfJ/p/O CTcch2ypDGSg4S89WzOcEqOTQcuWg10t+txw1F/PXruq/2927Xu2tJn1WijJWsVO/Fat T2Qg==
X-Gm-Message-State: AOAM530LZLvgLt8tjpLPtwK3lHc92UnheQKWsai1zUEBvDf9g8SDxhFq Q/SAfVV0dMdZ4HK1BvL72qa2dg==
X-Google-Smtp-Source: ABdhPJzLLnbMaAb8u6c1VkfgguBlZC5NdhUQIO3DSuFIkAstJqWF1YWst7AjuKaH9yq0wa96rmJBPg==
X-Received: by 2002:ac8:48c7:: with SMTP id l7mr332029qtr.275.1603232603893; Tue, 20 Oct 2020 15:23:23 -0700 (PDT)
Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id u11sm16253qtk.61.2020.10.20.15.23.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 15:23:23 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <B1A116F7-A851-4318-A6A9-B22F40FF6FE4@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.91\))
Date: Tue, 20 Oct 2020 18:23:21 -0400
In-Reply-To: <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com>
Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list <v6ops@ietf.org>, last-call@ietf.org
To: Fernando Gont <fgont@si6networks.com>
References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com>
X-Mailer: Apple Mail (2.3654.0.3.2.91)
Resent-From: alias-bounces@ietf.org
Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, warren@kumari.net, rwilton@cisco.com, Owen DeLong <owen@delong.com>, v6ops@ietf.org, owen@delong.com
Resent-Message-Id: <20201020222327.E17473A1433@ietfa.amsl.com>
Resent-Date: Tue, 20 Oct 2020 15:23:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/89tz98YKr9Bku4eo4YfOr9foAIw>
Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 20 Oct 2020 22:23:28 -0000

On Oct 20, 2020, at 3:51 PM, Fernando Gont <fgont@si6networks.com> wrote:
>> This is relevant because some IoT deployments make use of sleepy devices that may only wake up once per day or even less frequently. The suggested parameters would be inappropriate for such a device.
> 
> Just me double-checking: Do you mean it would be to short for them?
> 
> Please note that the default router lifetime is 1800 seconds. So a host
> that sleeps for longer than that will presumably not have a default router when it wakes up, and would need to do a "refresh" procedure (RS/RA exchange) before it would be able to send a packet, anyway.

Right, in a situation like this, where the network is pretty stable, it would make sense to use longer lifetimes. Also bear in mind that the communication on this network might be between two hosts on the same link—one a data collector and one a reporting device. So the router lifetime might not be an issue. If the communication is going off-network, a longer router lifetime would be required.

>> At the same time such a device likely is not relying on RA, since it
>> would not be awake for periodic refreshes. Nevertheless the operational mitigations section could use some additional verbiage about applicability so that readers do not assume that the advice given there is universally applicable.
> 
> Please clarify the above, and based on that, we could craft some text if
> necessary.

What I’m suggesting is simply that you mention that the defaults you are recommending are really most applicable in home networks, and may not be applicable in various commercial networks, including the IoT deployment I used as an example.  IOW, make it clear that these defaults are not universally applicable. There’s no text right now that says that (unless I missed it).