<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><br></div></div><div class="gmail_quote">On Fri, Sep 1, 2017 at 6:09 PM, Chuck Anderson <span dir="ltr"><<a href="mailto:cra@wpi.edu" target="_blank">cra@wpi.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Option A seems best--we regularly answer questions on this very list<br>
where new people assume everything is hierarchical (even host<br>
declarations).  So it seems natural to keep the shared-network/subnet<br>
as a hierarchical config.<br>
<span class=""><br>
On Fri, Sep 01, 2017 at 06:54:10PM +0000, Patrick Trapp wrote:<br>
> 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.<br>
><br>
</span><span class="">> On Sep 1, 2017, at 1:33 PM, perl-list <<a href="mailto:perl-list@network1.net">perl-list@network1.net</a><<wbr>mailto:<a href="mailto:perl-list@network1.net">perl-list@network1.net</a>><wbr>> wrote:<br>
><br>
> 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.<br>
><br>
> ______________________________<wbr>__<br>
</span>> From: "Tomek Mrugalski" <<a href="mailto:tomasz@isc.org">tomasz@isc.org</a><mailto:<a href="mailto:tomasz@isc.org">tomasz@<wbr>isc.org</a>>><br>
> To: "Users of ISC DHCP" <<a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><<wbr>mailto:<a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.<wbr>org</a>>><br>
<div><div class="h5">> Sent: Friday, September 1, 2017 8:39:41 AM<br>
> Subject: Shared subnets configuration in Kea - feedback requested<br>
> Hi,<br>
><br>
> As you probably know, ISC is working on Kea, a new DHCP server software.<br>
> Since you're subscribed to dhcp-users, the chances are you are using<br>
> dhcpd, because either didn't look at Kea or looked at it and decided it<br>
> doesn't have the features you need to migrate. Typically, the two major<br>
> reasons cited are lack of shared subnets support and lack of v4 failover<br>
> capabilities. We're now working on addressing the former.<br>
><br>
> The design phase for shared subnets is going well and there is one<br>
> aspect I'd like to ask for your feedback on. There are several ways how<br>
> shared subnets could be defined in the configuration file. Marcin sent<br>
> out three proposals with an honest list of pros and cons. (see the<br>
> forwarded e-mail below). Let us know which syntax would work best for you.<br>
><br>
> The shared subnets will be implemented in upcoming Kea 1.3. The commands<br>
> to manage them (to be used over RESTful API) are also planned, but<br>
> they're unlikely to make it into 1.3 due to scheduling constraints.<br>
> They're much more likely to materialize in 1.4 timeframe.<br>
><br>
> If none of the syntax proposals would be good for you and you have a<br>
> better idea, we'd love to hear it. Just keep in mind that certain things<br>
> are non-negotiable. The configuration is and will remain to be JSON.<br>
><br>
> If you can, please subscribe to kea-users and share your comments there.<br>
> If you can't, sending them to dhcp-users is ok, but may be frown upon by<br>
> people who are interested in dhcpd only and couldn't care less about Kea.<br>
><br>
> If you want to follow the earlier discussion, it started here:<br>
> <a href="https://lists.isc.org/pipermail/kea-users/2017-August/001167.html" rel="noreferrer" target="_blank">https://lists.isc.org/<wbr>pipermail/kea-users/2017-<wbr>August/001167.html</a><br>
> and continues here:<br>
> <a href="https://lists.isc.org/pipermail/kea-users/2017-September/001171.html" rel="noreferrer" target="_blank">https://lists.isc.org/<wbr>pipermail/kea-users/2017-<wbr>September/001171.html</a><br>
><br>
> Thanks in advance,<br>
><br>
> Tomek Mrugalski<br>
> Kea Lead Engineer<br>
> ISC<br>
><br>
> --- Treść przekazanej wiadomości ---<br>
> Temat: [Kea-users] Shared subnets configuration - input needed<br>
> Data: Thu, 31 Aug 2017 15:32:39 +0200<br>
</div></div>> Nadawca: Marcin Siodelski <<a href="mailto:marcin@isc.org">marcin@isc.org</a><mailto:<a href="mailto:marcin@isc.org">marcin@<wbr>isc.org</a>>><br>
> Adresat: Kea Users List <<a href="mailto:kea-users@lists.isc.org">kea-users@lists.isc.org</a><<wbr>mailto:<a href="mailto:kea-users@lists.isc.org">kea-users@lists.isc.org</a><wbr>>><br>
<div class="HOEnZb"><div class="h5">><br>
> Hello Kea Users,<br>
><br>
> We are currently working on implementation of a "shared networks"<br>
> mechanism in Kea, to provide ability for grouping multiple subnets<br>
> belonging to the same link.<br>
><br>
> This is useful to extend address pools for clients on the same physical<br>
> link, i.e. clients located on this link may get addresses from different<br>
> subnets. In such case, the DHCP server would allocate addresses from<br>
> another subnet (and its pools) if there are no more addresses available<br>
> in the first subnet.<br>
><br>
> It is also useful in cable networks, when a cable modem and a router are<br>
> on the same physical link but they should get addresses from different<br>
> subnets. Client classification is used in such case.<br>
><br>
> The ISC engineering team has been working on a design for this feature.<br>
> One of the contentious points is how to organize shared networks<br>
> configuration within the Kea config file.<br>
><br>
> We have discussed three different options. Let's call them A, B, C,<br>
> which are briefly discussed below. The ISC engineering team is leaning<br>
> towards A, but we'd also like to get some input from our Users what they<br>
> think might be more convenient.<br>
><br>
> Proposal A<br>
><br>
> Sample configuration link:<br>
> <a href="http://kea.isc.org/wiki/SharedSubnetsDesign#ConfigurationFormat" rel="noreferrer" target="_blank">http://kea.isc.org/wiki/<wbr>SharedSubnetsDesign#<wbr>ConfigurationFormat</a><br>
><br>
> In this case, the shared-networks list contains a full specification of<br>
> each subnet that belongs to shared networks. It is still possible to<br>
> define subnets outside of the shared-networks scope. Such subnets will<br>
> not be associated with any shared network.<br>
><br>
> Pros:<br>
> - Make use of hierarchical nature of JSON - subnets enclosed within<br>
> shared-networks structure belong to shared-networks. Other subnets do<br>
> not. No need to refer to subnets from another structure by name or id etc.<br>
> - Avoid configuration error whereby a single subnet may belong to<br>
> different shared networks.<br>
> - Avoid configuration error caused by manual matching of subnets with<br>
> networks.<br>
> - Is compatible with autogenerated subnet identifiers.<br>
> - JSON viewing tools can be used to visualize which subnets belong to<br>
> shared network by simply looking at the JSON hierarchy.<br>
> - Is similar to other configuration structures we use (except option<br>
> definitions).<br>
> - Is similar to how it is organized in ISC DHCP.<br>
><br>
> Cons:<br>
> - Moving subnets between shared networks requires copy pasting large<br>
> portions of configuration (entire subnet specification has to be<br>
> copied), possibly between distant locations in the configuration file.<br>
> - Makes it hard to see how many subnets are specified within a shared<br>
> network without JSON processing tools that can hide portions of the<br>
> configuration.<br>
><br>
><br>
> Proposal B<br>
> Sample configuration link:<br>
> <a href="http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative1" rel="noreferrer" target="_blank">http://kea.isc.org/wiki/<wbr>SharedSubnetsDesign#<wbr>Alternative1</a><br>
><br>
> This is the first of the proposals in which all subnets are defined at<br>
> the same configuration level (regardless if they belong to shared<br>
> networks or not). The shared-networks structure is separate and for each<br>
> network it refers to subnet ids that belong to the shared network.<br>
><br>
> Pros:<br>
> - shared-networks structure is much smaller because it only contains<br>
> subnet identifiers, rather than full subnet definitions. It may also<br>
> contain DHCP options etc.<br>
> - It makes it easier to move subnets between shared networks (or remove<br>
> them entirely) because it is just a matter of copy pasting subnet ids,<br>
> rather than full network specifications.<br>
><br>
> Cons:<br>
> - User error prone: subnet ids specified within shared-networks must<br>
> exist. It is easy to specify id of non-existing subnet or id of a wrong<br>
> subnet.<br>
> - User error prone: it is possible to specify the same id in two<br>
> different networks which is not allowed<br>
> - If there are many subnets, specifying a subnet and associating it with<br>
> a shared network means update to the config file in two different<br>
> (possibly distant) locations.<br>
> - Removal of a subnet belonging to a shared network requires config<br>
> update in two different locations.<br>
> - Is incompatible with autogenerated subnet identifiers because these<br>
> identifiers may vary between server configurations, e.g. when any subnet<br>
> is removed.<br>
> - Generic JSON tools can't do matching between subnets and shared<br>
> networks because they can't interpret subnet ids as a reference.<br>
><br>
><br>
> Proposal C<br>
> Sample configuration link:<br>
> <a href="http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative2" rel="noreferrer" target="_blank">http://kea.isc.org/wiki/<wbr>SharedSubnetsDesign#<wbr>Alternative2</a><br>
><br>
> Pros:<br>
> - Has the same pros as proposal B<br>
> - It avoids the use of subnet ids, but uses shared network names (subnet<br>
> ids autogeneration problem is solved)<br>
> - Resolves a problem with proposal B, whereby it was possible to assign<br>
> a single subnet to multiple networks.<br>
> - Removal of a subnet is easier than in B, because it is enough to<br>
> delete subnet declaration.<br>
><br>
> Cons:<br>
> - Comparing to B, it makes it harder to know how many subnets belong to<br>
> shared network, because we'd need to search for all subnets that have a<br>
> parameter "network" set to a given name.<br>
> - Some other unresolved cons from proposal B.<br>
><br>
><br>
> We're planning to close the discussion around Monday/Tuesday next week.<br>
> We'd appreciate any input before that time.<br>
><br>
> Kind Regards,<br>
><br>
> Marcin Siodelski<br>
> ISC Engineering Team<br></div></div></blockquote><div><br></div><div>My preference is A.</div><div><br></div><div>-- </div><div>Bob Harold</div><div><br></div></div></div></div>