Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02

Hi all,
Idea in general is great.
However, implementation is tailored for the small use case (3GPP TE==ND proxy).
My strong objection is only against limiting further address sub-delegation by SLAAC. DHCP or local algorithms should be permitted too.

"Client" may use 3 mechanisms to further re-distribute addresses from the DHCP-PD prefix:
1. SLAAC
2. DHCP
3. Local algorithm (if VMs or Containers are local to the "client").
It is wrong that:
Section 5 restricts the use case to SLAAC.
Section 7 restricts (“MUST”) to only SLAAC.

Some smaller comments are below (not principal):

"when individual clients connected to"
What is an "individual client"? People may not read definitions before reading the Abstract.
Maybe "DHCP-PD client"?

"At the very least, a host can be expected to have one link-local address, one temporary address and, in most cases, one stable global address. On an IPv6-only network the device would need to have a dedicated 464XLAT address".
How proposed solution help to "link-local" or XLAT? But the statement misled me that it would help.

"The number of global addresses can easily double, bringing the total number of addresses to 7."
The solution is specific to one PIO. The total number of addresses is not relevant to the discussion.

"On VXLAN [RFC7348] networks each address might be represented as a route so 8 addresses instead of 1 requires the devices to support 8 times more routes, etc".
How we did come to 8? It was 7 just the previous paragraph.
In reality, it is 3 per PIO: stable, new temporary, old temporary.

I do not see a difference between a "client" definition and a "node".
It is potentially possible to change: "Client - a node that requested and received the prefix by DHCP-PD".

Section 6.2 assumes that the router should be stateful for every delegated prefix (with precautions for Bulk download).
It is better to assume that the router would be stateful only for manually defined bigger prefixes (smaller number of bits). Then statefulness may be assumed just by manual configuration.

Section 14: routing churn may be mitigated by stopping snooping too.

Ed/
> -----Original Message-----
> From: Vasilenko Eduard
> Sent: Thursday, October 5, 2023 12:21 PM
> To: 'Joel Halpern' <jmh@joelhalpern.com>; Xipengxiao
> <xipengxiao=40huawei.com@dmarc.ietf.org>; v6ops@ietf.org
> Subject: RE: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02
> 
> Hi all,
> Just a comment that this draft could not become RFC before I-D.collink-
> 6man-pio-pflag,
> Because it is dependent on it in section 9.
> It is probably not a problem for WGLC – it could wait in the queue later.
> Ed/
> On 9/30/2023 4:42 PM, Xipengxiao wrote:
> 
> Hi Folks,
> 
> This message initiates a WGLC for draft-ietf-v6ops-dhcp-pd-per-device-02.
> The call will end on Oct 14, 2023.  Your opinion will be valued.
> 
> Ron & XiPeng
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops