Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Shared subnets configuration in Kea - feedback requested
(Tomek Mrugalski)
2. Re: Shared subnets configuration in Kea - feedback requested
(Simon Hobson)
3. syntax question (Christopher Barry)
4. Re: Shared subnets configuration in Kea - feedback requested
(Chris Buxton)
5. Re: Shared subnets configuration in Kea - feedback requested
(perl-list)
----------------------------------------------------------------------
Message: 1
Date: Fri, 1 Sep 2017 14:39:41 +0200
From: Tomek Mrugalski <tom...@isc.org>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Shared subnets configuration in Kea - feedback requested
Message-ID: <da5d78bd-a8d5-fce0-cb53-94d230272...@isc.org>
Content-Type: text/plain; charset=UTF-8
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 <mar...@isc.org>
Adresat: Kea Users List <kea-us...@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-us...@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
------------------------------
Message: 2
Date: Fri, 1 Sep 2017 14:18:58 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Shared subnets configuration in Kea - feedback requested
Message-ID: <d2e8ef5d-d598-427f-9154-b4977e3ac...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Tomek Mrugalski <tom...@isc.org> wrote:
> 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.
As I finish in my current job today, I don't particularly see me having the
opportunity to use the feature in the foreseeable future, though I've used it a
few times in the past (with dhcpd).
TBH I don't have any significant preference either way - all will work, all
have pros and cons, whichever is chosen will need some learning before using it.
------------------------------
Message: 3
Date: Fri, 1 Sep 2017 10:03:26 -0400
From: Christopher Barry <christopher.r.ba...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: syntax question
Message-ID: <20170901100326.5f31f...@monolith.infinux.org>
Content-Type: text/plain; charset=US-ASCII
Hello everyone,
I want to use the substring keyword to return a part of a string that
starts at character 5, and goes to the end of the string. The strings
will be of variable length. Do I simply omit the second numeric
parameter to accomplish that? I can't find anything about this in the
man pages.
Thanks
--
Regards,
Christopher
------------------------------
Message: 4
Date: Fri, 1 Sep 2017 09:46:21 -0700
From: Chris Buxton <cli...@buxtonfamily.us>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Shared subnets configuration in Kea - feedback requested
Message-ID: <dbb378ad-843c-4c91-bd6b-9b42f52de...@buxtonfamily.us>
Content-Type: text/plain; charset=utf-8
Tomek,
Personally, I think proposal C (alternative 2) is the best one.
Regards,
Chris Buxton
BlueCat
> On Sep 1, 2017, at 5:39 AM, Tomek Mrugalski <tom...@isc.org> wrote:
>
> 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 <mar...@isc.org>
> Adresat: Kea Users List <kea-us...@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-us...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 5
Date: Fri, 1 Sep 2017 14:32:50 -0400 (EDT)
From: perl-list <perl-l...@network1.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Shared subnets configuration in Kea - feedback requested
Message-ID:
<935953850.479500.1504290770527.javamail.zim...@network1.net>
Content-Type: text/plain; charset="utf-8"
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" <tom...@isc.org>
> To: "Users of ISC DHCP" <dhcp-users@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 <mar...@isc.org>
> Adresat: Kea Users List <kea-us...@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-us...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@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.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 107, Issue 1
******************************************
