Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

Ted Lemon <mellon@fugue.com> Thu, 22 October 2020 14:11 UTC

Return-Path: <mellon@fugue.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 A73713A0D31 for <v6ops@ietfa.amsl.com>; Thu, 22 Oct 2020 07:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 lP7OSYLryPQL for <v6ops@ietfa.amsl.com>; Thu, 22 Oct 2020 07:11:29 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C325C3A0D33 for <v6ops@ietf.org>; Thu, 22 Oct 2020 07:11:29 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id 140so1549018qko.2 for <v6ops@ietf.org>; Thu, 22 Oct 2020 07:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cpOdbE+/o6Nf4MV+fel+6LgyKb8tQ+YaBQ/zpV2Frjw=; b=pCm3RPrOYafzAQ6w9RBz1AHuQ/beRMdm5rJ8Jo2nlFbhovzTCR5uJk7ChsuoFCuVIR uUGiveS8Xzqb+rpCWs9itrNy4V0R2ywzsPWl7/tFifJIi+PNKNEvTy0BhxDmjSvEtJZR hnQqkkkju2UUE4KgCC/EvXCJ2Rn9S2DKYhhvw2iabD0h1QarPpe0wJQZJqg/0owTORCP k7wtJOYBGb5zDarOIwkDKZaI6s4hNs+8x+NJed2lIklFB4ll89ikO+ZpGqXr2f/OUzTu P5Vzg9GYuXd37PLPX+WiChkTyJlNi9N04MslX0XuBFM7/x5OxjuZwdUVlI1o6w+Gsf/B 9v3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=cpOdbE+/o6Nf4MV+fel+6LgyKb8tQ+YaBQ/zpV2Frjw=; b=i05XaJvraa2RTU1vBnxmdVz4wKFNz467xVoMxQNvO4R87PIbv5QJCBTIf3SyepSOR/ wEBJmET8PP9g0OWQPioqhuC6UnoZu0EX2zFNUdTTF6GUJzwECosjRlfIX0mPvfv7xLCZ 7d4a0FlPOXBo5tzjRBZVNGCVwD94HpoxZTOPn1TUggz9SSfDilgoWi0gXj+Teei+f4Cu nc4MZ+NxPT5RiK0ptAWfc9ilsvkcZyq/yvCFg/XPuOkq1FmAhM/QqhIBofaptMMnrWCu ElCm0FWi9DIalXicpf2m/H5a2aZBrl/2cNbx2IZo60NEqLSxdR9yCj6p4DFgxzMzR2RB HTAg==
X-Gm-Message-State: AOAM531jy7tu1hTZ7+zBoQYkRip+4gMrtFWR8ADOh5Ol+GAWYh54NVuT YQlobxmzS1zODCjmKKDEmNBrOA==
X-Google-Smtp-Source: ABdhPJwF2eHtcqF4Kcc10Wc9bPsv4aMp3SV1SaB/cvai1lBqWMeJ04jfAQikR2nCj2eVZlijgEXJmA==
X-Received: by 2002:a37:86c4:: with SMTP id i187mr1033765qkd.371.1603375886784; Thu, 22 Oct 2020 07:11:26 -0700 (PDT)
Received: from [192.168.4.114] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id p38sm1109859qtb.20.2020.10.22.07.11.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2020 07:11:26 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 22 Oct 2020 10:11:24 -0400
Message-Id: <34783E29-F267-4A58-9C3E-5CC2C0D93B49@fugue.com>
References: <160334506239.20395.15102292380884503313@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, v6ops-chairs@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum@ietf.org
In-Reply-To: <160334506239.20395.15102292380884503313@ietfa.amsl.com>
To: Erik Kline <ek.ietf@gmail.com>
X-Mailer: iPhone Mail (18B79)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xZXTo-fYX2bsCV9892mvz5Y3bl4>
Subject: Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and 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, 22 Oct 2020 14:11:32 -0000

I think it’s reasonable to assume that in some situations a ULA will be generated and not remembered, or that the /48 will be remembered but the subnetting will not be. E.g. this could happen in an HNCP-delegated network pretty easily. The set of behaviors we are seeing in existing border routers fairly constrained with respect to what is theoretically possible and even reasonable.  So I don’t think there’s a good reason to suggest different treatment for ULAs. 

> On Oct 22, 2020, at 01:37, Erik Kline via Datatracker <noreply@ietf.org> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-v6ops-cpe-slaac-renum-05: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> [ section 3.2 ]
> 
> * I absolutely agree in principle at these other lifetimes should be updated
>  to the shorter of the two applicable lifetimes, but I'm worried that this
>  text is not sufficiently precise.  Specifically, this recommendation only
>  applies to options that depend in any way on the change in the delegated
>  prefix, yes?  Perhaps just this qualifier is sufficient?
> 
>  For example, none of these comparative lifetime recommendations apply to
>  a stable ULA for a router that meets requirements ULA-[1..5] and chooses
>  to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.
> 
>  That being said, should this document also be saying that the ULA-derived
>  options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot
>  causes a new ULA to be generated (i.e. the one supposedly in stable storage
>  is lost or otherwise unrecoverable)?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ comments ]]
> 
> [ section 3.1 ]
> 
> * With respect to the second bullet: the lifetimes need to be dynamically
>  *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT
>  values are always lower than the remaining PD lifetimes.  In this situation,
>  the requirement is still that the lifetimes can be updated, but to the
>  casual observer of the steady state the RA contents might appear static
>  (e.g., while the PD'd prefix is continuously renewed).
> 
>  Maybe there's no text required here, but I didn't want a reader to be left
>  with the impression that no two RAs could be identical
> 
> 
> [[ nits ]]
> 
> [ section 3.3 ]
> 
> * In the 2nd bullet's 2nd bullet (this might be easier if these lists were
>  numbered), it might be good to clarify that "the *deprecated* prefix can
>  simply be advertised..."
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops