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

[Alexandre Petrescu <[e-mail]>]

If one wants a network protocol dhcp-pd-per-device to satisfy the RFC 
7084 reqs then do satisfy this requirement:

> WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
>             router the size of the prefix it requires.  If so, it MUST
>             ask for a prefix large enough to assign one /64 for each of
>             its interfaces, rounded up to the nearest nibble, and SHOULD
>             be configurable to ask for more.

Alex

Le 03/11/2023 à 11:05, Alexandre Petrescu a écrit :
>
> 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
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops