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

[Ole Troan <[e-mail]>]

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=[e-mail]> 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 <[e-mail]> On Behalf Of Jeremy Duncan
> Sent: Thursday, November 2, 2023 6:24 PM
> To: Alexandre Petrescu <[e-mail]>; [e-mail]
> 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 <[e-mail]> on behalf of Alexandre Petrescu <[e-mail]>
> Sent: Thursday, November 2, 2023 11:33:07 AM
> To: [e-mail] <[e-mail]>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>  _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops