Re: [v6ops] Erik Kline's Yes on draft-ietf-v6ops-cpe-slaac-renum-07: (with COMMENT)

Fernando Gont <fgont@si6networks.com> Thu, 25 February 2021 07:42 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBA23A14D1; Wed, 24 Feb 2021 23:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vXhYtuF0iCF6; Wed, 24 Feb 2021 23:42:02 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89AD3A1511; Wed, 24 Feb 2021 23:41:39 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:f0e0:52b6:fa0e:8799] (unknown [IPv6:2800:810:464:2b9:f0e0:52b6:fa0e:8799]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2EC0D28049A; Thu, 25 Feb 2021 07:41:33 +0000 (UTC)
To: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong <owen@delong.com>
References: <161423409814.30483.4228112460025308703@ietfa.amsl.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <a38ea347-822f-f1ec-c00d-559b06616562@si6networks.com>
Date: Thu, 25 Feb 2021 04:18:48 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <161423409814.30483.4228112460025308703@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/CQavsaMh4e26CSdNZTUTsCkPh0M>
Subject: Re: [v6ops] Erik Kline's Yes on draft-ietf-v6ops-cpe-slaac-renum-07: (with COMMENT)
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: Thu, 25 Feb 2021 07:42:05 -0000

Hello, Erik,

Thanks a lot for your comments! In-line....

On 25/2/21 03:21, Erik Kline via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ comments ]]
> 
> [ section 3.4 ]
> 
> * At the end of the 2nd paragraph and the 2nd NOTES paragraph, I think it
>    could be made clearer that this recommendation especially applies to ND
>    Options that contain address or prefix information from within a prefix
>    learned on the WAN side.

Are you referring that of "the lifetimes not spanning past the remaining 
lifetime", or to the recommendation to set the PIO lifetimes to 
(ND_VALID_LIMIT, ND_PREFERRED_LIMIT).

If the former, I definitely agree. If the latter, I'd probably argue 
that when it comes to PIOs the advice is also valid even if the prefix 
is locally generated. -- e.g., consider the case where a CE Router is 
simply replaced by another one. If the (VL, PL) was (1 week, 1 month) 
you'd have them around for quite a while (same for e.g. RDNSS options). 
-- that said, I wouldn't mind clarifying that this only applies to 
sub-prefixes of prefixes learned from the WAN-side if you think that's 
warranted.



>    These timers seem fine in general as well, but I think as written it's
>    a blanket recommendation without explicitly saying why these options
>    need updating, i.e. if someone asks what does "if and where applicable"
>    actually mean -- it means ND options with address/prefix information
>    taken from a delegated prefix whose lifetime has been reduced
>    (possibly to zero, possibly progressively shorter values trending to zero).

FWIW, what we *meant* with "if and where applicable" was essentially 
"[any future] Neighbor Discovery options that depend in any way on 
changes in the prefix employed for address configuration on the LAN-side"

Just let us know how we should clarify the above.

Thanks a lot!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492