[v6ops] Re: Correction: Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd

Ted Lemon <mellon@fugue.com> Mon, 12 August 2024 15:15 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 4F3E3C14F69E for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2024 08:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WvS-wA1Stkq for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2024 08:15:30 -0700 (PDT)
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469CCC14F5E2 for <v6ops@ietf.org>; Mon, 12 Aug 2024 08:15:29 -0700 (PDT)
Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-264988283a3so2946205fac.0 for <v6ops@ietf.org>; Mon, 12 Aug 2024 08:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1723475729; x=1724080529; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PwF1uiESABzx+vxfPE7balwQYiTHq/DSHIbjGPZMS14=; b=YH3txWjAw+72F1bpdXBgXjc33Zbx8GcuGBOytU1tVRxewN5MgRMfHZezVhl1v07+9o quibgzedHQ47uK2uYkFdz0vzLMqHkMR5WhV28kYSDP+EkaV2mGlrM1EGIFohxVdDyKZS SaH6BWnFXTpfQmpWt0008D+AYLy657LN1Tz+4v0DpEIW19+HVcPm/9t8bfIlaaZf0twK JpSLlwtkuMHdsMVdIyAE6atEhl1D18cR70GfV44ogg64/SIyHSiiLogZlJIPfu9cUhmX UQKVMe2VBHlK6nDJKRzURu6EZFhgA0IHtnjHaFgYUwmuPqWZzipDqonqQTk7K/Ra2tbS 6l/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723475729; x=1724080529; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PwF1uiESABzx+vxfPE7balwQYiTHq/DSHIbjGPZMS14=; b=TLwABgx1wK44CjK+AM3q9YmhuwR0xdPyjg7pKmbnCAchf7y8Zb/O5YgbyHwOk74tBc +EMnF6QqRScgGblxD6fE8yFJ0sMSzwjd+p2bhbnwxz87aTBaxT1isxDJ1NQTzZlRyAky ETMz3ALnAoJ5OROXIMUxrMch1vVVXbyqKSuuCTjkMRNDtbaSxftm7td5Kh7PTH7AJV1l n0x6F9eMhN2BMSrcTnEdm+0wEQv8ImzNVeyaXngdlX2PrSVWWyshdUM0GCTMAgN4AYqh +VxRl3W94Tw1O/35Fe8mg6J6zgdkyxya5G9rPirhr9/pCuupAj0ig+qLCtVioru3nUBk 77Dg==
X-Forwarded-Encrypted: i=1; AJvYcCUDJYOXc7IspztOBTvEJmFQ+5pwV88IwXuJlMOo6JaVZZCQllCHWos0+gRCb1T6Lg5JqafWdle/t58O66EDLQ==
X-Gm-Message-State: AOJu0YySL4VbLCtgYeRBcgjCP9RunyG0OIxlJXlArRrMcNrk58FfwZ0b tdnsKl4QmqO/qP6aawCKWIln9CLg/YrKpufCVa81Z3iNrSeI74GZDsRYr66si8khtv1SpeEBDzW eWBINu8wn2cO9IaFuCyabjX5S9NgQEAdveYbclQ==
X-Google-Smtp-Source: AGHT+IGAqBYMIQSGCGi1so5SQU4ps/Sp51sCUjo43CxRRS/STPpMYmveQ9WNtpfyWgkdvc5yNYRYA9iEK7KELmXLATk=
X-Received: by 2002:a05:6870:e60a:b0:268:7946:8a83 with SMTP id 586e51a60fabf-26fcb6b4290mr454541fac.22.1723475729177; Mon, 12 Aug 2024 08:15:29 -0700 (PDT)
MIME-Version: 1.0
References: <CACMsEX_x0ORZZ+nYeUQ5Lf83W9GZPwZOfcWpfq5gDtuY7oqk9w@mail.gmail.com> <11d52d74-b53a-4176-8128-5d2aa80320ca@gmail.com> <DB9PR07MB7771A90163C51552F8BCE28CD6B82@DB9PR07MB7771.eurprd07.prod.outlook.com> <CAJgLMKtS=yD=PjamVAjW88ZtvNpGqV6QgqPNfPPgfTVBE_wCEw@mail.gmail.com> <DB9PR07MB7771DC1F7FB03FD2B9BEF1EBD6B92@DB9PR07MB7771.eurprd07.prod.outlook.com> <CAJgLMKuQ_SNNNt3s4ps=JOgx=P33bkxpVxaDLZ8NQgdx2ub3UA@mail.gmail.com> <CAPt1N1kc99ntYzvkrYqTDPUH-WSLpR1zcbX1J5Oxs5GVAfqPqQ@mail.gmail.com> <CAJgLMKtb9HB48s7UkALqYjBhnDgr+h3y_Or2WO9sxnT=_TmrQA@mail.gmail.com> <CAFU7BARTioScMuprHTkJvFu_h835znqpcnKKJL8MyG66hJ5HSg@mail.gmail.com>
In-Reply-To: <CAFU7BARTioScMuprHTkJvFu_h835znqpcnKKJL8MyG66hJ5HSg@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 12 Aug 2024 11:15:18 -0400
Message-ID: <CAPt1N1nr+xZ_sJ5LmkeXLSh3bcSycV6Yomchhk7kH=-W=RypTA@mail.gmail.com>
To: Jen Linkova <furry13@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009dfa75061f7df665"
Message-ID-Hash: 53ZNXP5OTFKOR5QPGAY6IOLJ4UVNDY7F
X-Message-ID-Hash: 53ZNXP5OTFKOR5QPGAY6IOLJ4UVNDY7F
X-MailFrom: mellon@fugue.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Tim Chown <Tim.Chown@jisc.ac.uk>, IPv6 Operations <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Correction: Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mHppx5on0xyJLxL-VPM2jtwR7jw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

Mow that you mention is, it does seem like a gap not to specify how the isp
lifetime and dependent router lifetime interact.

For example, it’s probably worth making sure we don’t get into a Xeno’s
paradox situation with the downstream lease, because the remaining lifetime
isn’t constant and hence the lifetime of the downstream lease could always
be shorter than the lifetime of the prefix provided by the ISP. However,
specifying that would complexify the document a bit.

But the main point is that I can think of several ways to choose the
lifetime of the downstream lease based on the current text, and that’s not
good. :)

Op ma 12 aug 2024 om 10:29 schreef Jen Linkova <furry13@gmail.com>

> Hi Tim,
>
> Sorry, coming late to the party (..again...;( )
>
> On Fri, Aug 9, 2024 at 4:36 AM Timothy Winters <tim@qacafe.com> wrote:
> > LPD-7:
> > The IPv6 CE Router MUST provision IA_PD prefixes with a prefix-length of
> 64 unless configured to different prefix-length by the user. The prefix
> length of 64 is used as that is the current prefix length supported by
> SLAAC.
>
> While I do not have a strong opinion on that, I think that maybe
> saying smth like 'MUST provision....a prefix length suitable for SLAAC
> (currently /64)' would be better...
>
> I read the text you have in -04 as 'the router MUST provide /64 (btw
> we chose that number because it's the current value for SLAAC)', so
> the value is still hardcoded, so if we ever change the SLAAC prefix
> length, this document would still require an update.
>
> What do you think?
>
> A few more comments:
>
> 1) shall the draft say anything about a flash renumbering/the change
> of the delegated prefix?
> LPD-3 allows the onlink prefix change if the topology or config
> changes, but what about the pool? Would it be too much to ask for a
> reconfigure message to be sent?
> 2) is it assumed that T1/T2 values are consistent with T1/T2 received
> from the ISP?
> 3) It's been mentioned already, I believe, that the draft updates 7084
> but there is no update text. In particular, I think, it needs to
> update  WPD-5 to include packets to delegated prefixes.
>
>
> > On Thu, Aug 8, 2024 at 2:15 PM Ted Lemon <mellon@fugue.com> wrote:
> >>
> >> What happened to the updates we talked about earlier (e.g., MUST, and
> explaining what "by default" means)? :)
> >>
> >> I'm otherwise okay with this text though.
> >>
> >> On Thu, Aug 8, 2024 at 2:04 PM Timothy Winters <tim@qacafe.com> wrote:
> >>>
> >>> Hi Tim,
> >>>
> >>> I can get on board with that.
> >>>
> >>> OLD:
> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
> prefixes with a prefix-length of 64.
> >>>
> >>> New:
> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
> prefixes with a prefix-length of 64. The prefix length of 64 is
> >>>    used as that is the current prefix length supported by SLAAC.
> >>>
> >>> ~Tim
> >>>
> >>> On Thu, Aug 8, 2024 at 4:22 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> >>>>
> >>>> Hi Tim,
> >>>>
> >>>>
> >>>>
> >>>> From: Timothy Winters <tim@qacafe.com>
> >>>> Date: Wednesday, 7 August 2024 at 20:09
> >>>> To: Tim Chown <Tim.Chown@jisc.ac.uk>
> >>>> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Nick Buraglio <
> buraglio@forwardingplane.net>, IPv6 Operations <v6ops@ietf.org>
> >>>> Subject: Re: [v6ops] Re: Correction: Re: Working group Last call:
> draft-ietf-v6ops-cpe-lan-pd
> >>>>
> >>>> Hi Tim,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Aug 7, 2024 at 7:24 AM Tim Chown <Tim.Chown=
> 40jisc.ac.uk@dmarc.ietf.org> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>
> >>>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> >>>> Date: Tuesday, 6 August 2024 at 21:53
> >>>> To: Nick Buraglio <buraglio@forwardingplane.net>, IPv6 Operations <
> v6ops@ietf.org>
> >>>> Subject: [v6ops] Correction: Re: Working group Last call:
> draft-ietf-v6ops-cpe-lan-pd
> >>>>
> >>>> I support the draft going forward.
> >>>>
> >>>> I do have one comment on the scope of the document. I believe that it
> should also cover use of PD for a locally assigned ULA prefix. Please don't
> turn this into another endless ULA thread - but if the CE has assigned a
> ULA prefix, and supports PD for a GUA prefix, it should also support PD for
> the ULA prefix.
> >>>>
> >>>>
> >>>>
> >>>> This seems reasonable.
> >>>>
> >>>>
> >>>>
> >>>> Should /64 be hard coded in the document, or should it refer to a
> prefix of the length required to support SLAAC as currently defined?
> >>>>
> >>>> I'm concerned this will cause confusion amongst the CE Router
> community if I don't put an actual number.  If you really want we can 64 is
> based on the prefix length of SLAAC as currently defined.  How strong do
> you feel about this?
> >>>>
> >>>>
> >>>>
> >>>> Not strongly, but the WG has of late been trying not to unnecessarily
> hard code the 64 into documents. If 64 is used, then a short statement as
> to why would be good.
> >>>>
> >>>>
> >>>>
> >>>> The pd-per-device draft uses /64 in an example and says “Note that
> the prefix lengths used in the example are /64 because that is the prefix
> length currently supported by SLAAC and is not otherwise required by the
> proposed deployment model” and says a little more on /64 in section 8 which
> also refers to RFC 7084, and in section 11. The 64 isn’t “hard coded” in
> there, in that its use in the example is clearly explained.
> >>>>
> >>>> Minor nit – the “addresses” at the end of para 1 of the intro should
> probably say “prefixes”.
> >>>>
> >>>> thanks, fixed in -03.
> >>>>
> >>>>
> >>>>
> >>>> Best wishes,
> >>>>
> >>>> Tim
> >>>>
> >>>>
> >>>>
> >>>> Tim
> >>>>
> >>>>
> >>>>
> >>>> (There are several grammatical nits in the Introduction. I'll send
> them to the author off-list.)
> >>>>
> >>>> Regards
> >>>>      Brian Carpenter
> >>>>
> >>>> On 07-Aug-24 03:18, Nick Buraglio wrote:
> >>>> > All,
> >>>> >
> >>>> > This message begins the working group last call for
> draft-ietf-v6ops-cpe-lan-pd. Please read the draft and send your comments
> in response to this email.
> >>>> >
> >>>> > The draft can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/ <
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/>
> >>>> >
> >>>> > nb
> >>>> >
> >>>> > _______________________________________________
> >>>> > v6ops mailing list -- v6ops@ietf.org
> >>>> > To unsubscribe send an email to v6ops-leave@ietf.org
> >>>>
> >>>> _______________________________________________
> >>>> v6ops mailing list -- v6ops@ietf.org
> >>>> To unsubscribe send an email to v6ops-leave@ietf.org
> >>>>
> >>>> _______________________________________________
> >>>> v6ops mailing list -- v6ops@ietf.org
> >>>> To unsubscribe send an email to v6ops-leave@ietf.org
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list -- v6ops@ietf.org
> >>> To unsubscribe send an email to v6ops-leave@ietf.org
> >
> > _______________________________________________
> > v6ops mailing list -- v6ops@ietf.org
> > To unsubscribe send an email to v6ops-leave@ietf.org
>
>
>
> --
> Cheers, Jen Linkova
>