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

[Alexandre Petrescu <[e-mail]>]

Le 03/11/2023 à 00:13, Lorenzo Colitti a écrit :
> [...] This draft focuses on what the network needs to do to provide 
> prefixes to clients.

Sorry if this has already been said, and I know we are past the time of 
scoping the draft.

How the network provides prefixes to WiFi or cellular clients (not home 
CPE) is written in PMIPv6 DHCPv6-PD RFCs on StdTracks.

(the difference between CPE and a 4G router is not that clear cut).

> And it's not true to say there are no clients: there are plenty of 
> existing clients in the form of RFC 7084 routers.

I think there is something in doubt here.

RFC7084 is a set of requirements, not a protocol implementation.

Further, that RFC 7084 is clear about the requirements of the prefix 
length - check it.  It is not really along the lines this draft proposes 
(RFC7084 has a stance on the /64 which reads different than being fixed, 
as this draft proposes).

Alex

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