[kea-dev] Shared subnet requirements

[Tomek Mrugalski]

W dniu 14.06.2017 o 16:40, mailinglists at sogetel.net pisze:
> Back in February 2017, I did a suggestion to address this issue.  At
> that time, "shared subnet" wasn't a hot topic... I kindly repost my
> suggestion :
Thanks for bringing that one up.

>> In the Mikrotik's RouterOS, there is a "next pool" directive that make
>> possible to "chained" subnet to subnet and so on...
>>
>> Why not using the same kind of concept?  If a subnet is exhausted, it
>> will look at the new "next-subnet" option, look at it, pick and IP
>> (if available), if not, look for an other next "next-subnet" option
>> and so on...  That way, you don't have to implement some form of grouping.
While such a logic would be easy to implement, I think we would quickly
regret it. This way is very error prone and can lead to weird corner
cases. Let me give you specific examples:

example 1 (circular dependency)
subnet1, next-subnet pointing to subnet2
subnet2, next-subnet pointing to subnet1

Should this be rejected as invalid configuration? If not, when should
the server stop following the next-server?

example 2 (circular dependency lite)

subnet1, next-subnet pointing to subnet1
This is more absurd version of the earlier one.

example 3:
subnet1, next-subnet points to subnet2
subnet2, next-subnet points to subnet3
subnet3, next-subnet not set

This one looks like valid configuration, but depending on which subnet
would be considered first, the server would look at three, two or just
one subnet when trying to allocate a lease. This would lead to obscure
bugs and unhappy users.

example 4:
subnet1, next-subnet points to subnet3
subnet2, next-subnet points to subnet3
subnet3, next-subnet not set

This looks like misconfiguration (if subnet1 and subnet3 are on the same
physical link and subnet2 is on the same link as subnet3, shouldn't
subnet1 and subnet2 be on the same link)? This is just a trivial case,
the situation may be more complex is there are more subnets.

So am afraid I don't like that approach at all. Yes, it would be easy to
implement, but it would be tricky to set up properly and easy to
misconfigure. What's worse, there wouldn't be an easy way for Kea to
report the misconfiguration.

>> Obviously each subnet in a chain have their gateway's IP configured on
>> the router physical interface (as we already do).  The IP of the first
>> subnet in the chain must be configure as the "primary" IP on the
>> router interface since DHCP we request will come from that IP...  Not
>> a big deal.
What I was thinking (note I haven't finalized the design proposal yet,
so this may change) is that we will have a separate shared-network
structure that enumerates the subnets. It would also let you to
configure options and perhaps some other parameters that would apply to
all subnets. If an option is specified on both shared network scope and
subnet scope, the subnet would take precedence as it's more specific.

That way if you have 10 shared subnets and 9 of them have value A and
only one subnet has value B, you would specify the option once. It would
apply to all subnets, except the one where the value would be specified
as B. Not sure if we get that kind of flexibility from day 1, but that's
the goal I'd like to reach one day.

Tomek