PD configuration proposal
Tomek Mrugalski
tomasz at isc.org
Mon Sep 16 14:48:00 UTC 2013
Replying back to the list.
On 16.09.2013 16:00, Thomas Markwalder wrote:
> I suppose tacking the prefix length onto the end of the pool string is
> as good of an approach as any other. My primary concern is how much
> logical validation are we doing or do we plan to do? It looks like we
> are giving them an whole bunch of rope to wrap around their necks. If
> they specify 4 pools and 10 pd-pools for a subnet, is there some set of
> rules or analysis that we can or should perform on these to check for
> overlaps or other problems? I foresee an endless list of test cases,
> edge cases...
For now, the validation checks if the specified pool is within the
subnet. We also check if obviously stupid things, like v4 pool in v6
subnet, are not attempted. For prefix, I've added checks that you can't
delegate larger prefixes out of too small pool (e.g. you can't delegate
/48 out of your /56 pool). It is easy to check if the new pool being
added does not overlap with other already configured pools. I haven't
implemented that check, but there's a todo for it in Subnet::addPool. As
for 4 pools and 10 pd-pools, the first part (4 pools) is already
supported and covered by unit-tests and, according to my knowledge,
working properly. I see no reason why the same approach couldn't work
for PD.
> I am not suggesting we not build in the flexibility, but if we do not or
> cannot enforce some level of sanity, then we have to publish some sort
> of disclaimer that says "yes you can do just about anything you want,
> but your real world results may be just as much nonsense as your
> configuration".
That's a good suggestion. There will be big, red, flashing warning about
PD support being experimental.
As for the multiple pools in a single subnet, there are real life use
cases. You can say that for a given subnet, one range (pool) should go
to engineering, the other one to accounting and a third one to HR dept.
They could all use the same subnet. Granted, we do not support client
classification and such a segregation is not possible yet, but we will
get there eventually.
Tomek
More information about the bind10-dhcp
mailing list