[Kea-users] Shared subnets configuration - input needed

Fri Sep 8 19:20:48 UTC 2017

Thanks to everyone who replied (and we asked the question on the dhcp-users mailing list too).  It seemed like most people preferred ‘A’ so that is the approach we are pursuing. 

Regards,

Vicky
> On Sep 5, 2017, at 5:49 AM, James Sumners <JamesSumners at clayton.edu> wrote:
> 
> Of the proposed, I prefer option “B”.
> 
> 
> On August 31, 2017 at 9:32:52 AM, Marcin Siodelski (marcin at isc.org <mailto:marcin at isc.org>) wrote:
> 
>> Hello Kea Users, 
>> 
>> We are currently working on implementation of a "shared networks" 
>> mechanism in Kea, to provide ability for grouping multiple subnets 
>> belonging to the same link. 
>> 
>> This is useful to extend address pools for clients on the same physical 
>> link, i.e. clients located on this link may get addresses from different 
>> subnets. In such case, the DHCP server would allocate addresses from 
>> another subnet (and its pools) if there are no more addresses available 
>> in the first subnet. 
>> 
>> It is also useful in cable networks, when a cable modem and a router are 
>> on the same physical link but they should get addresses from different 
>> subnets. Client classification is used in such case. 
>> 
>> The ISC engineering team has been working on a design for this feature. 
>> One of the contentious points is how to organize shared networks 
>> configuration within the Kea config file. 
>> 
>> We have discussed three different options. Let's call them A, B, C, 
>> which are briefly discussed below. The ISC engineering team is leaning 
>> towards A, but we'd also like to get some input from our Users what they 
>> think might be more convenient. 
>> 
>> Proposal A 
>> 
>> Sample configuration link: 
>> http://kea.isc.org/wiki/SharedSubnetsDesign#ConfigurationFormat 
>> 
>> In this case, the shared-networks list contains a full specification of 
>> each subnet that belongs to shared networks. It is still possible to 
>> define subnets outside of the shared-networks scope. Such subnets will 
>> not be associated with any shared network. 
>> 
>> Pros: 
>> - Make use of hierarchical nature of JSON - subnets enclosed within 
>> shared-networks structure belong to shared-networks. Other subnets do 
>> not. No need to refer to subnets from another structure by name or id etc. 
>> - Avoid configuration error whereby a single subnet may belong to 
>> different shared networks. 
>> - Avoid configuration error caused by manual matching of subnets with 
>> networks. 
>> - Is compatible with autogenerated subnet identifiers. 
>> - JSON viewing tools can be used to visualize which subnets belong to 
>> shared network by simply looking at the JSON hierarchy. 
>> - Is similar to other configuration structures we use (except option 
>> definitions). 
>> - Is similar to how it is organized in ISC DHCP. 
>> 
>> Cons: 
>> - Moving subnets between shared networks requires copy pasting large 
>> portions of configuration (entire subnet specification has to be 
>> copied), possibly between distant locations in the configuration file. 
>> - Makes it hard to see how many subnets are specified within a shared 
>> network without JSON processing tools that can hide portions of the 
>> configuration. 
>> 
>> 
>> Proposal B 
>> Sample configuration link: 
>> http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative1 
>> 
>> This is the first of the proposals in which all subnets are defined at 
>> the same configuration level (regardless if they belong to shared 
>> networks or not). The shared-networks structure is separate and for each 
>> network it refers to subnet ids that belong to the shared network. 
>> 
>> Pros: 
>> - shared-networks structure is much smaller because it only contains 
>> subnet identifiers, rather than full subnet definitions. It may also 
>> contain DHCP options etc. 
>> - It makes it easier to move subnets between shared networks (or remove 
>> them entirely) because it is just a matter of copy pasting subnet ids, 
>> rather than full network specifications. 
>> 
>> Cons: 
>> - User error prone: subnet ids specified within shared-networks must 
>> exist. It is easy to specify id of non-existing subnet or id of a wrong 
>> subnet. 
>> - User error prone: it is possible to specify the same id in two 
>> different networks which is not allowed 
>> - If there are many subnets, specifying a subnet and associating it with 
>> a shared network means update to the config file in two different 
>> (possibly distant) locations. 
>> - Removal of a subnet belonging to a shared network requires config 
>> update in two different locations. 
>> - Is incompatible with autogenerated subnet identifiers because these 
>> identifiers may vary between server configurations, e.g. when any subnet 
>> is removed. 
>> - Generic JSON tools can't do matching between subnets and shared 
>> networks because they can't interpret subnet ids as a reference. 
>> 
>> 
>> Proposal C 
>> Sample configuration link: 
>> http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative2 
>> 
>> Pros: 
>> - Has the same pros as proposal B 
>> - It avoids the use of subnet ids, but uses shared network names (subnet 
>> ids autogeneration problem is solved) 
>> - Resolves a problem with proposal B, whereby it was possible to assign 
>> a single subnet to multiple networks. 
>> - Removal of a subnet is easier than in B, because it is enough to 
>> delete subnet declaration. 
>> 
>> Cons: 
>> - Comparing to B, it makes it harder to know how many subnets belong to 
>> shared network, because we'd need to search for all subnets that have a 
>> parameter "network" set to a given name. 
>> - Some other unresolved cons from proposal B. 
>> 
>> 
>> We're planning to close the discussion around Monday/Tuesday next week. 
>> We'd appreciate any input before that time. 
>> 
>> Kind Regards, 
>> 
>> Marcin Siodelski 
>> ISC Engineering Team 
>> _______________________________________________ 
>> Kea-users mailing list 
>> Kea-users at lists.isc.org 
>> https://lists.isc.org/mailman/listinfo/kea-users 
> 
> 
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users

Victoria Risk
Internet Systems Consortium
vicky at isc.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20170908/1bfefd4a/attachment.htm>