Hi,
On Thu, 31 Aug 2017, Marcin Siodelski 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.
</snipp> I tend to agree that option A is the most straight forward and I recommend keeping it simple. Greetings Christian -- Christian Kratzer CK Software GmbH Email: [email protected] Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
