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

[Lorenzo Colitti <[e-mail]>]

Ole,

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.

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.

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.

Cheers,
Lorenzo

On Thu, Nov 2, 2023 at 6:50 PM Ole Troan <otroan=
[e-mail]> wrote:

> 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
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>