Shared subnets configuration in Kea - feedback requested

Tue Sep 5 13:35:30 UTC 2017

On Fri, Sep 1, 2017 at 6:09 PM, Chuck Anderson <cra at wpi.edu> wrote:

> Option A seems best--we regularly answer questions on this very list
> where new people assume everything is hierarchical (even host
> declarations).  So it seems natural to keep the shared-network/subnet
> as a hierarchical config.
>
> On Fri, Sep 01, 2017 at 06:54:10PM +0000, Patrick Trapp wrote:
> > 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 <perl-list at network1.net<mailto:
> perl-list at network1.net>> 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" <tomasz at isc.org<mailto:tomasz at isc.org>>
> > To: "Users of ISC DHCP" <dhcp-users at lists.isc.org<mailto:
> 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<mailto:marcin at isc.org>>
> > Adresat: Kea Users List <kea-users at lists.isc.org<mailto:
> 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
>

My preference is A.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170905/0a443f5d/attachment-0001.html>