Shared subnets configuration in Kea - feedback requested

perl-list perl-list at network1.net
Fri Sep 1 18:32:50 UTC 2017


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" <tomasz at isc.org>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> 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 <marcin at isc.org>
> Adresat: Kea Users List <kea-users at lists.isc.org>

> 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
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170901/b0d645f2/attachment-0001.html>


More information about the dhcp-users mailing list