Re: [v6ops] Chair decision on WGLC for draft-ietf-v6ops-dhcp-pd-per-device-04

Ted Lemon <mellon@fugue.com> Thu, 02 November 2023 19:55 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 A0755C151534 for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2023 12:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 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_BLOCKED=0.001, 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 xvch2FrDLdlV for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2023 12:55:41 -0700 (PDT)
Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950B7C15152D for <v6ops@ietf.org>; Thu, 2 Nov 2023 12:55:41 -0700 (PDT)
Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-58686e94ad7so679931eaf.3 for <v6ops@ietf.org>; Thu, 02 Nov 2023 12:55:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1698954940; x=1699559740; 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=pOEuFubzvbfHIjtdj+oFh4/AJJ2SK2faXtrIRBApw2Y=; b=SnS7h8M5ztrVaGd1Ojc5M1UUW1HlD6XrJCxDT/thNbw22X7pHnMVxCEid2YPXv6IAe trw31cLT7iRysge5oi/BWlgU0AL+wPVk2UdjJGViUngdCj2ZlDw5D4f5DAdL1Dr7WyJe 3zjfNSilbGKyymQ3+jufDWY70420er+5mOmU1lTfr4o+H2qq5GcMnol/efW2qe/2e9Kf 64OZkdXpee9gz1uGiuaaaSlD4eka3B58yYB4K14C6eg4sY5D8iyHvGIfMuVnnSbBHkrJ qe+Bi+h3tbJeJ01PlNEVx2XM7QmAvXvocRk8O2fexgnphsNY33k+LQGBcSK2g8ABGxgB p3WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698954940; x=1699559740; 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=pOEuFubzvbfHIjtdj+oFh4/AJJ2SK2faXtrIRBApw2Y=; b=AdavDwtnecY+BjvS3cxbS6VrCrzdVTERiZkKGEm4dbpuPjYNG2/SlQBdXe0pRHQNTu nteZpn9YaK9/SrXTLd3Ly5HegqemBDHinioC4qzaANfWbtLcWZjTEgXBleGANsphsMHI vvJpBDF1w5OMNx4yEFYqSeJRscCJfdSzkbcS5akw5c7JvQQpHWDuQ4FboyAop0UIEK+3 3MijOI6B6Ge9GwdSLurka8tcIaCgKs0DqnQKNnMsPGHik3IfLpLP9yRMmQaCmERaNtam vzQ3U5BuDYsLeE1sE0/a1C7fmNWlB7PoecoGW22gWWtmLCFZWUCcJ7kr/XCAK94miqR0 EQgA==
X-Gm-Message-State: AOJu0YyczlLw8iFO9jGqye/BzO65+sOgJHmIWrAs2+e4aheESEJWhJT6 jepMKz0ZVeuULxpz/hKzzU5vuHBEVEULKsngyNrung==
X-Google-Smtp-Source: AGHT+IH5qEPw+jNvXvtluDGrIzhKzOofwekoYGpIkIuv8Lfrw+L6439SBweijFgrCGli6gWZoCDZ/9/dQ22YAVOD5cY=
X-Received: by 2002:a05:6358:ee8f:b0:168:e5e9:e8a3 with SMTP id il15-20020a056358ee8f00b00168e5e9e8a3mr23688772rwb.10.1698954940043; Thu, 02 Nov 2023 12:55:40 -0700 (PDT)
MIME-Version: 1.0
References: <e078c90495b54390a3fb4c7bae143b05@huawei.com> <82240620-5d81-48bc-adcd-4f7d45a32482@gmail.com> <BL1PR18MB4277B500C01CF41FEA137693ACA6A@BL1PR18MB4277.namprd18.prod.outlook.com> <b204c19975b7420d803d0ad2b79fb1ab@huawei.com> <C55EFA0E-BD25-4B6A-9E07-C4B3DBA385CF@employees.org>
In-Reply-To: <C55EFA0E-BD25-4B6A-9E07-C4B3DBA385CF@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 02 Nov 2023 20:55:04 +0100
Message-ID: <CAPt1N1kwG6F9SUHK-AOm3CydAGWo+c8i4+dGLoEDRNOJwD5XmQ@mail.gmail.com>
To: Ole Troan <otroan=40employees.org@dmarc.ietf.org>
Cc: Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b0ecda060930c5ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/W6xrChUWgz8AxHpG8dkbJzp0Fn0>
Subject: Re: [v6ops] Chair decision on WGLC for draft-ietf-v6ops-dhcp-pd-per-device-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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, 02 Nov 2023 19:55:42 -0000

I support moving forward. The prefix-length discussion comes up with every
document that is published, but weirdly the people who keep arguing about
it don't propose their own document that would actually address the
problem, nor talk about the migration strategy that would be required to
successfully allow us to switch to e.g. /80 as the default prefix length.
Litigating that in the last calls of every v6ops document is I guess low
effort, but not very effective.

On Thu, Nov 2, 2023 at 7:50 PM Ole Troan <otroan=
40employees.org@dmarc.ietf.org> wrote:

> XiPeng,
>
> Did you intend this to be a consensus call to confirm the chair’s call on
> the WGLC?
> If so, I do not think it is ready to progress to the next phase.
> (I’m also happy to continue this discussion during the IETF last call, if
> the working group chairs stand by their call that there is rough consensus
> to proceed.)
>
> To reiterate the main concerns I have with this document:
>
> 1) It needs to clarify it’s relationship with:
>   draft-ietf-snac-simple-00
>   draft-winters-v6ops-cpe-lan-pd-04
>   What are the overlaps and are there conflicts?
>
> 2) While the network side may possibly fall within “operational”, the host
> side does not.
>   There are no host implementations yet. My suggestion is that this
> document should proceed together with the host requirements document. Host
> changes, especially that hosts need with this to do address selection needs
> some consideration, and is certainly not operational. It requires code
> changes.
>
> 3) The prefix length and extension issues discussed at length. Basically
> if only to number a local interface on the host a /64 is needed. If a /64
> is assigned, it still doesn’t allow for an extension more than a single
> link (if following the author’s logic).
> The consequences of this document being progressed is that we worst case
> will have hosts that only allow extensions in large enterprise network with
> the resources to grab large chunks of address space.
>
> 4) The flat versus hierarchical delegation model needs to be clarified.
> It’s not clear what a host is supposed to “ask” for or behave.
>
> I think it’s premature to progress this. Host implementations should be
> written and experimented with, and actual operational experience gained.
>
> O.
>
>
>
>
> > On 2 Nov 2023, at 18:37, Xipengxiao <xipengxiao=
> 40huawei.com@dmarc.ietf.org> wrote:
> >
> > Hi Folks,
> >  The draft is not in a WG adoption call.  The chairs have declared it
> passed WG Last Call (WGLC) but there are still different opinions.  So if
> you support moving this draft forward to next phase, please say “support
> moving-forward” so that there is no ambiguity.  Thank you!
> >  XiPeng
> >  From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Jeremy Duncan
> > Sent: Thursday, November 2, 2023 6:24 PM
> > To: Alexandre Petrescu <alexandre.petrescu@gmail.com>; v6ops@ietf.org
> > Subject: Re: [v6ops] Chair decision on WGLC for
> draft-ietf-v6ops-dhcp-pd-per-device-04
> >  Not sure if I'm too late, but I support adoption of this draft.
> >   Semper Fi,
> > Jeremy Duncan
> > Sent from my cell
> >  From: v6ops <v6ops-bounces@ietf.org> on behalf of Alexandre Petrescu <
> alexandre.petrescu@gmail.com>
> > Sent: Thursday, November 2, 2023 11:33:07 AM
> > To: v6ops@ietf.org <v6ops@ietf.org>
> > Subject: Re: [v6ops] Chair decision on WGLC for
> draft-ietf-v6ops-dhcp-pd-per-device-04
> >
> >
> > Sorry for being too direct, it's because it is short.
> >
> > Do not count the draft authors in the balance.  It's normal for the
> > authors to be 'for'.
> >
> > > many existing hosts only support SLAAC with /64 prefixes, and in order
> not to require changes to such hosts.
> > It's because decision after decision people in WGs keep imposing that
> > /64 limit.  This decision only prolongs that.
> >
> > On another hand, the IPv6 archi doc, the SLAAC spec, and some
> > implementations - do allow for what these decisions dont allow, i.e.
> > SLAAC with other-than-64 plens.
> >
> > The only thing that truly requires that to be /64 is the not-000 binary
> > prefix of IP addresses.  (RFC 4291 "For all unicast addresses, except
> > those that start with the binary value 000, Interface IDs are required
> > to be 64 bits long").  In that sense, that 'not-000' criterion could be
> > set in the title of this draft.
> >
> > Instead of:
> >
> >  > Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large
> > Broadcast Networks
> >
> > it would be more correct:
> >
> >  > Using DHCPv6-PD to Allocate Unique IPv6 Prefix - starting with any
> > other value than binary 000 - per Client in Large Broadcast Networks
> >
> > Alex
> >
> >
> > Le 01/11/2023 à 15:27, Xipengxiao a écrit :
> > > Hi folks,
> > >
> > > Seeing the hot discussion on
> draft-ietf-v6ops-dhcp-pd-per-device-02/03/04, the chairs have let the WGLC
> run longer than originally designated to let people fully express their
> view.  But the chairs must also make a decision at some point.
> > >
> > > Going through the mails, the chairs counted the following opinions:
> > > •       For: Jen L., Lorenzo C., Joel H., Nick B., Erik K., David F.,
> Owen D., Brian C.
> > > •       Against: Pascal T., Eduard V., Martin H., Ole T., Gert D.
> > >
> > > It’s clear that there is no clear consensus.  Due to a large number of
> emails and some people not expressing their For/Against opinion clearly,
> the chairs may have missed 1-2 opinions. But even if so, “no clear
> consensus” remains the case.
> > >
> > > In general, the draft is in good shape.  The remaining debate focuses
> on prefix size.  The chairs would like to point out that there is no need
> for a draft to solve all problems to pass WGLC - It only needs to solve the
> problems in the intended scenarios and make no harm in other scenarios.
> This draft points out that many existing hosts only support SLAAC with /64
> prefixes, and in order not to require changes to such hosts,  /64 or
> shorter prefixes must be delegated.  This is a practical choice.  For other
> scenarios where unique /64 (or shorter) prefix per client cannot be
> afforded, people can choose not to take this approach so this draft makes
> no harm.  With this consideration and acknowledging that it's a "rough
> consensus", the chairs declare this draft has passed WGLC.  Thanks to all
> the people who provided reviews and comments.
> > >
> > > Ron and XiPeng
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >  _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>