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

[Lorenzo Colitti <[e-mail]>]

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?


> 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.
>

I don't think we can easily make such a recommendation since a direct
contradiction of RFC 7084 (WPD-2 says that if it supports hinting it MUST
ask for a single prefix enough to address the entire router). Also, this
draft is trying to avoid specifying any host behaviour as much as possible,
and focus on the network side. This is because removing the text that we
had about hosts resolved a lot of objections/lack of consensus, and
because v6ops this isn't really a WG that is chartered to change host
behaviour or define new protocols. This draft is strictly operational - it
describes an operational model and what network operators need to do to
support it.

Once this is published I think we can get more ambitious - for example,
work on the mobility problem that as Pascal points out would be a major
upgrade - but I think we should get this document out first.