<html><body><div style="font-family: Andale Mono; font-size: 10pt; color: #000000"><div style="font-family: Andale Mono; font-size: 10pt; color: #000000;" data-mce-style="font-family: Andale Mono; font-size: 10pt; color: #000000;">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><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Tomek Mrugalski" <tomasz@isc.org><br><b>To: </b>"Users of ISC DHCP" <dhcp-users@lists.isc.org><br><b>Sent: </b>Friday, September 1, 2017 8:39:41 AM<br><b>Subject: </b>Shared subnets configuration in Kea - feedback requested<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;">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>https://lists.isc.org/pipermail/kea-users/2017-August/001167.html<br>and continues here:<br>https://lists.isc.org/pipermail/kea-users/2017-September/001171.html<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>Nadawca: Marcin Siodelski <marcin@isc.org><br>Adresat: Kea Users List <kea-users@lists.isc.org><br><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>http://kea.isc.org/wiki/SharedSubnetsDesign#ConfigurationFormat<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>http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative1<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>http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative2<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>_______________________________________________<br>Kea-users mailing list<br>Kea-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/kea-users<br>_______________________________________________<br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users</blockquote></div></div><br></div></body></html>