Re: [v6ops] Updating RFC 7084 - alternate logic

[Ted Lemon <[e-mail]>]

Op do 1 dec. 2022 om 02:48 schreef Olorunloba Olopade <loba.olopade=
[e-mail]>

> I will rather take a /61 (as an example) than multiple /64s.


This is stated as if we are having a discussion about each other’s
opinions. Can you state this instead as a use case?

The debate is about flat vs tree. SLAAC works with both. I'm not bringing
> variable length SLAAC into the debate.


No. The debate is about whether there should be a single server subdividing
the prefix acquired from the ISP or not. The topology of the network
doesn’t matter in this discussion other than that neither approach does
well with loops, absent additional mechanisms.

The question is simply whether we want to have multiple DHCP servers or
only one, per ISP.

I haven’t heard any argument for why having multiple servers is good. I can
think of quite a few in favor of a single server:

1. No prefixes go to waste because of arbitrary allocation policies
2. No problem with lease computation when subdelegating (the subdelegated
prefix has a lease, so the subdelegating server has to figure out the lease
it offers in dependence on that)
3. Single source of truth (only one server)
4. Don’t run out of prefixes as soon (flat model will allocate multiple
/64s per stub network, when there is definitely no need, and will run out
of prefixes much sooner as you add stub routers to the home network
5. Notification path is less complex when renumbering happens or the ISP
connection goes offline (no cascading notifications).

I could go on, but the point I’m making here is that if you really think we
should follow the cable labs spec, you need to make a technical case for
doing so, and thus far you have not.

>