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

Ole Troan <otroan@employees.org> Thu, 02 November 2023 23:32 UTC

Return-Path: <otroan@employees.org>
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 D9AC6C151073 for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2023 16:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=employees.org
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 Nb3qxSZUELv0 for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2023 16:32:31 -0700 (PDT)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [IPv6:2607:7c80:54:6::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4DD0BC15106C for <v6ops@ietf.org>; Thu, 2 Nov 2023 16:32:30 -0700 (PDT)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 775C3E7ABB; Thu, 2 Nov 2023 23:32:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=CEo7sTIUlBxT2xYh mezcCcIa8pNe/JFenQUIAiykoUU=; b=dxl+HelyVfKU9JYOM0oM8B0UAbBI0Ix8 c9jwT1GVkmMlNYj3F75JOh27MA8RlD7KtUlgvG+m0y8nOK/soRsv9HEmBbIXOGAm F6QaLsXcB947wRb4rqG3/m4+RqNGRLBKM028/4tTp/j12AQ1hXUBEKjov2+PlS6x 0QONAkB8vB0sXnuO2Db79ArfD+uD/7mw2C8NY4D0cXNr1XfGyd6LUyk/KPMN8qzZ gs/biVoiMAxQ4jeZXi5ofF0oSjtckxdVgAOfYlXMf5s4GhxUkiZqD8RnkuQ1CNOl 58av3aqAnmOm0m0EYYsTsCE7/CJrMh2dztyGJGpn/s2PgnLWoK899g==
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id 55B53E7AB9; Thu, 2 Nov 2023 23:32:29 +0000 (UTC)
Received: from smtpclient.apple (unknown [IPv6:2001:4650:c3ed:37a:1e9f:54b:1ba9:d468]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 97B374E11A43; Thu, 2 Nov 2023 23:32:28 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAKD1Yr3wDTO7J3K_0kEAwHpkqSfYzfb4tuxYhJEdm3rpMT-7CQ@mail.gmail.com>
Date: Fri, 03 Nov 2023 00:32:15 +0100
Cc: Xipengxiao <xipengxiao@huawei.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C6C80B9-741E-4A74-8A30-B27026083066@employees.org>
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> <CAKD1Yr3wDTO7J3K_0kEAwHpkqSfYzfb4tuxYhJEdm3rpMT-7CQ@mail.gmail.com>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.100.2.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Do3y2M2sMVUVDEMB3Bej5T1Am4M>
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 23:32:35 -0000

Lorenzo,

> Your concerns are around client behaviour, but those are out of scope for this draft. This draft focuses on what the network needs to do to provide prefixes to clients. And it's not true to say there are no clients: there are plenty of existing clients in the form of RFC 7084 routers. These require no code changes. SNAC routers are being standardized elsewhere, but those will also be able to use this draft as is.

That’s a bit like saying we are only going to specify the server side of the DHCP protocol and the client side is out of scope...

You don’t know if this “operational” guidance is correct until you have implementations and deployment.

Isn’t the scenario here Enterprise networks? Then IPv6 CE routers as specified in 7084 might not be the best example. 7084 uses PD for delegation across administrative boundaries. If I recall it also assumes hierarchical PD (although I’m not sure if that’s spelt out clearly).

You may be right that most of 7084 would also apply to a host that implements this. But too early to tell I think.

> Even if, as you say, DHCPv6 PD on hosts is not well defined or widely implemented, that is very much orthogonal to this document. No matter how hosts behave, the network needs to behave as described in this draft in order to support them. So this document is useful by itself.

How can you be so certain, given no running code?
It would certainly have been a useful project at the hackathon.

Which is why I suggest this to be put on hold until we have host requirements document and running code.
It’s not like there is a rush for this, as it will not be operable before implementations exists anyway.

> As for relationships with other documents: SNAC is already cited and I don't see what needs to be said in this draft. If a SNAC router asks for a prefix and the network wants to provide it, then this document provides operational guidance for how to do that.  Same with draft-winters-v6ops-cpe-lan-pd - that talks about IPv6 CE routers as defined by RFC 7084, and again, this document explains how the network needs to behave to delegate prefixes to RFC 7084 clients.

So what’s the operational guidance here, is it for flat PD or hierarchical PD?
A network configured for hierarchical PD will be unlikely to have a policy allowing more than a single prefix, while a flat PD network will allow for more but likely all of the same size.
An operational document should make a stance. And it should not conflict with the other two documents.

O.