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

[Ole Troan <[e-mail]>]

> On Mon, Oct 9, 2023 at 5:29 PM Ole Troan <[e-mail]> wrote:
> I think section 8 is enough and that this could be deleted.
> It’s regardlessly an operational choice.
> Alternatively say something like:
> “If SLAAC is {needed, required, used}, the server MUST provide a prefix short enough…”
> 
> Section 8 is what motivates this recommendation, but by itself, section 8 is clearly more about discussion than about recommendations. I think it's useful to have that requirement in the server consideration sections as well, to provide clear advice to implementors and guarantee interoperability with the most devices and scenarios (e.g., RFC 7084 requires at least one /64).

I suggest it’s replaced with guidance rather than requirement.
(MUSTs in informational documents aside).


>  Garbage collection is going to be a challenge in this solution.
> Regardless of deployment you will have a fairly small number space, that can easily be exhausted.
> 
> The only way you can deal with that is by using short lease timers, right?
> Would it be worth providing some guidelines regarding that? At least describe the problem?
> 
> Actuall, this is less of a problem than it sounds, because this model is effectively identical to how we manage IPv4 addresses today. The draft sort of already says this in the "prefix pool allocation" section, but perhaps we could add an extra sentence to clarify:
> 
> ====
> 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.

Also, regarding the prefix pool idea. When this was last discussed in SNAC the opinions seemed to lean towards flat allocation. That’s a lot more efficient for address utilisation. The pool approach is hierarchical. At least at the first level.
If an EN has 3 downstream links, I think the network should get a PD request with 3 IA_PD options. Assigning a /64 to each. Instead of a request of a /62 with a prefix hint. The document likely needs some guidance regarding that. Not quite sure how the text should look like.

Cheers,
Ole