declarations). So it seems natural to keep the shared-network/subnet
> If I understand the proposal, Option A is most like what I currently use in dhcpd. I confess a bias toward what I already know, but as was mentioned, that seems the most logical approach, anyway.
>
> On Sep 1, 2017, at 1:33 PM, perl-list <
[hidden email]<mailto:
[hidden email]>> wrote:
>
> I prefer option A as it is the easiest to read. My experience is that easiest to read = easiest to maintain however wordy it may be.
>
> ________________________________
> From: "Tomek Mrugalski" <
[hidden email]<mailto:
[hidden email]>>
> To: "Users of ISC DHCP" <
[hidden email]<mailto:
[hidden email]>>
> Sent: Friday, September 1, 2017 8:39:41 AM
> Subject: Shared subnets configuration in Kea - feedback requested
> Hi,
>
> As you probably know, ISC is working on Kea, a new DHCP server software.
> Since you're subscribed to dhcp-users, the chances are you are using
> dhcpd, because either didn't look at Kea or looked at it and decided it
> doesn't have the features you need to migrate. Typically, the two major
> reasons cited are lack of shared subnets support and lack of v4 failover
> capabilities. We're now working on addressing the former.
>
> The design phase for shared subnets is going well and there is one
> aspect I'd like to ask for your feedback on. There are several ways how
> shared subnets could be defined in the configuration file. Marcin sent
> out three proposals with an honest list of pros and cons. (see the
> forwarded e-mail below). Let us know which syntax would work best for you.
>
> The shared subnets will be implemented in upcoming Kea 1.3. The commands
> to manage them (to be used over RESTful API) are also planned, but
> they're unlikely to make it into 1.3 due to scheduling constraints.
> They're much more likely to materialize in 1.4 timeframe.
>
> If none of the syntax proposals would be good for you and you have a
> better idea, we'd love to hear it. Just keep in mind that certain things
> are non-negotiable. The configuration is and will remain to be JSON.
>
> If you can, please subscribe to kea-users and share your comments there.
> If you can't, sending them to dhcp-users is ok, but may be frown upon by
> people who are interested in dhcpd only and couldn't care less about Kea.
>
> If you want to follow the earlier discussion, it started here:
>
https://lists.isc.org/pipermail/kea-users/2017-August/001167.html> and continues here:
>
https://lists.isc.org/pipermail/kea-users/2017-September/001171.html>
> Thanks in advance,
>
> Tomek Mrugalski
> Kea Lead Engineer
> ISC
>
> --- Treść przekazanej wiadomości ---
> Temat: [Kea-users] Shared subnets configuration - input needed
> Data: Thu, 31 Aug 2017 15:32:39 +0200
> Nadawca: Marcin Siodelski <
[hidden email]<mailto:
[hidden email]>>
> Adresat: Kea Users List <
[hidden email]<mailto:
[hidden email]>>
>
> 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
Locked
