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

[Brian E Carpenter <[e-mail]>]

Lorenzo,
On 10-Oct-23 19:27, Lorenzo Colitti wrote:
> On Tue, Oct 10, 2023 at 3:10 PM Ole Troan <[e-mail] <mailto:[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. 

Hmm. That requires the operator (a fallible and unscaleable component) to estimate the maximum usage for each link. It seems to me that is a fallible solution that doesn't scale. Either the local pool size should be computed and maintained automatically, or there should be a central on-demand pool of some kind. (This is really why we used prefix assignment as an example use case for autonomic networking - it's not exactly a new problem - and why we did RFC8992.)

    Brian

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