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

[Lorenzo Colitti <[e-mail]>]

Alexandre,

I think that ius satisfied by the current text though, no? It says:

   -  The server MUST provide a prefix short enough for the client to
   extend the network to at least one interface, and allow nodes on that
   interface to obtain addresses via SLAAC. It should be noted that [RFC8168]
   allows the server to provide a prefix shorter that the prefix-length hint
   value received from the client).

So if a RFC 7084 client asks for, say, a /60, the network can support that.

Cheers,
Lorenzo

On Fri, Nov 3, 2023 at 10:11 AM Alexandre Petrescu <
[e-mail]> wrote:

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