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 <[email protected]> wrote: > > Of the proposed, I prefer option “B”. > > > On August 31, 2017 at 9:32:52 AM, Marcin Siodelski ([email protected] > <mailto:[email protected]>) 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 >> [email protected] >> https://lists.isc.org/mailman/listinfo/kea-users > > > _______________________________________________ > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users Victoria Risk Internet Systems Consortium [email protected]
_______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
