[kea-dev] Shared subnet requirements

[mailinglists at sogetel.net]

Hi Tomek,

You don't have to feel bad about rejecting my proposition...

My goal is to "fuel" discussions and reflexions about that subject...

It seems that it works ;-)


> Le 14 juin 2017 à 11:16, Tomek Mrugalski <tomasz at isc.org> a écrit :
> 
> 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