Re: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03

[Jen Linkova <[e-mail]>]

Hi Ole,

On Mon, Oct 9, 2023 at 11:36 PM Ole Troan <[e-mail]> wrote:
> > On Tue, Oct 10, 2023 at 3:10 PM Ole Troan <[e-mail]> wrote:
> > > This is very similar to how address pools are allocated when using DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), where each link has a dedicated pool of addresses, and clients on the link obtain addresses from the pool. In this model, each link's pool can be sized according to the expected maximum of devices on a particular link, similar to how DHCPv4 pools are sized today. For example, if the network assigns a /64 to every client, then any link that is assigned an IPv4 prefix of /X (e.g., X=/18, X=/24) would require a corresponding prefix pool of size X+32 (e.g., X=/50, X=56).
> >
> > I think I would like to see some operational guidance.
> >
> > Isn't the text I suggested above already operational guidance? It basically says that for the pool-per-link model (which is the only one documented in the draft), the operator should assign one pool for each link and size the pools based on expected maximum usage, which is basically the same way that operators size IPv4 address pools today. Not sure what else we should say here, maybe say that the lease times need to be consistent with IPv4 lifetimes as well, to prevent prefix exhaustion?
>
> Yes, lifetimes as well as T1/T2 timers.
> It would probably be good to not say consistent with IPv4 timers, as we’d like the text to be applicable in an IPv6 only context.

This is very much similar to how operators choose DHCPv4 lease timers nowadays.
Maybe we can just say smth like:

"As most operators have some experience with IPv4, they can use the
similar approach for choosing the pool size and the timers (such as
T1/T2 timers). In particular the following factors shall be taken into
account:
- the expected maximum number of clients;
- average duration of a client connection;
- how mobile the clients are (a network where all clients are
connected to a single wired VLAN might choose longer timers than a
network where clients can switch between multiple wireless SSIDs);
- expected level of recurring clients (for example, a corporate
authenticated WiFI network might be using longer timers than an open
public WiFi)."

I do not think we can recommend specific values as there is no "one
size fits all" solution.

What do you think?

> This document should be in sync with (and probably should reference the stub router document.
> At least there should be text explaining the two models. Flat and hierarchical. And that the network needs to support both.

I think it's not possible to support an arbitrary number of clients
with an arbitrary number of networks (flat or hierarchical) behind
them (unless we have truly unlimited resources). I believe the goal of
this draft is to document what can be expected to work and what is a
"nice to have" extras.
So I have a suggestion. How about this:

- we clarify in the Applicability and Limitations section that the
proposed solution supports expanding the network to at least one
interface behind a client, and it MAY support more - depending on the
network policy and resource availability.
- in the Prefix Length consideration section, we'll add a reference to
the draft-ietf-snac-simple as another example (thanks for the
reference, btw!)



--
SY, Jen Linkova aka Furry