
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">

</head>

<body dir="auto">

<div></div>

<div>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.</div>

<div><br>

On Sep 1, 2017, at 1:33 PM, perl-list <<a href="mailto:perl-list@network1.net">perl-list@network1.net</a>> wrote:<br>

<br>

</div>

<blockquote type="cite">

<div>

<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" <<a href="mailto:tomasz@isc.org">tomasz@isc.org</a>><br>

<b>To: </b>"Users of ISC DHCP" <<a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>><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>

<a href="https://lists.isc.org/pipermail/kea-users/2017-August/001167.html">https://lists.isc.org/pipermail/kea-users/2017-August/001167.html</a><br>

and continues here:<br>

<a href="https://lists.isc.org/pipermail/kea-users/2017-September/001171.html">https://lists.isc.org/pipermail/kea-users/2017-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>

Nadawca: Marcin Siodelski <<a href="mailto:marcin@isc.org">marcin@isc.org</a>><br>

Adresat: Kea Users List <<a href="mailto:kea-users@lists.isc.org">kea-users@lists.isc.org</a>><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>

<a href="http://kea.isc.org/wiki/SharedSubnetsDesign#ConfigurationFormat">http://kea.isc.org/wiki/SharedSubnetsDesign#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">http://kea.isc.org/wiki/SharedSubnetsDesign#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">http://kea.isc.org/wiki/SharedSubnetsDesign#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>

_______________________________________________<br>

Kea-users mailing list<br>

<a href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a><br>

<a href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a><br>

_______________________________________________<br>

dhcp-users mailing list<br>

<a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><br>

<a href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a></blockquote>

</div>

</div>

<br>

</div>

</div>

</blockquote>

<blockquote type="cite">

<div><span>_______________________________________________</span><br>

<span>dhcp-users mailing list</span><br>

<span><a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a></span><br>

<span><a href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a></span></div>

</blockquote>

</body>

</html>