[Kea-users] Shared subnets configuration - input needed

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Kea-users] Shared subnets configuration - input needed

Marcin Siodelski
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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

Chaigneau, Nicolas

Hello,

I prefer the first option.

But it would be even better if we had an "include" directive. I think it has already been suggested, maybe it's time to add this.
This would allow to easily move subnets from/to a shared network.

E.g.:

{
    "shared-networks": [
        {
            "name": "foo",
            "interface": "eth0"

            include "subnets4-foo.conf"
        },

        {
            "name": "bar",
            "interface": "eth1"

            include "subnets4-bar.conf"
        }
    ],

    include "subnets4-standalone.conf"
}






> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
>
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

Tobias -
In reply to this post by Marcin Siodelski
Hi!

All of them seem to have quite a few cons and the configuration files can already be quite large. But A looks like the better option at first glance but the others aren't too bad either so it's difficult to tell.

Being able to reference subnets or even common configuration options would make it less complicated. Defining all subnets in a common pool of subnets with user specified names would be a nice fit for any kind of organization.

JSON doesn't support anything out of the ordinary. You could look at YAML as an alternative to JSON since it supports everything JSON supports but YAML also allows you to use anchors and references which are only visible to the user and the interpreter but the result would be just as if things were copied and pasted.

So would would YAML be a viable alternative configuration file format? Allow the user to use either format and if they want a more complex setup then they could utilize the strengths of YAML. A YAML processing tool would see references which is why I propose this. It would avoid some Kea-specific concepts and stick to a format that supports referencing out of the box.

Best regards,
Tobias D

Den 31 aug. 2017 3:33 em skrev Marcin Siodelski <[hidden email]>:
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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

Francis Dupont
In reply to this post by Chaigneau, Nicolas
"Chaigneau, Nicolas" writes:
> But it would be even better if we had an "include" directive. I think it has
> already been suggested, maybe it's time to add this.

=> we already have a lexical (*) include as an extension to JSON,
e.g.: <?include "/foo/bar" ?>
(PS: lexical as it is handled by flex generated code, for instance
you can include unbalanced JSON parts when CPP is syntactic).

Regards

Francis Dupont <[hidden email]>

PS: this feature was added for exactly this use case. It supports
recursive includes and raises a fatal error when the include stack
depth is greater than 10 (i.e. when it loops).
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

Chaigneau, Nicolas
Oh... didn't realize this was already in. :)

I assume the file is looked for in the same directory as the including file ?

Can you also specify absolute file paths ? (<?include "/var/data/file.json"?>)
And relative paths ? (<?include "./subnets/foo.json"?>)


-----Message d'origine-----
De : Francis Dupont [mailto:[hidden email]]
Envoyé : vendredi 1 septembre 2017 13:40
À : Chaigneau, Nicolas
Cc : Marcin Siodelski; Kea Users List
Objet : Re: [Kea-users] Shared subnets configuration - input needed

"Chaigneau, Nicolas" writes:
> But it would be even better if we had an "include" directive. I think
> it has already been suggested, maybe it's time to add this.

=> we already have a lexical (*) include as an extension to JSON,
e.g.: <?include "/foo/bar" ?>
(PS: lexical as it is handled by flex generated code, for instance you can include unbalanced JSON parts when CPP is syntactic).

Regards

Francis Dupont <[hidden email]>

PS: this feature was added for exactly this use case. It supports recursive includes and raises a fatal error when the include stack depth is greater than 10 (i.e. when it loops).
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

Francis Dupont
"Chaigneau, Nicolas" writes:
> I assume the file is looked for in the same directory as the including file?
>  ?
>
> Can you also specify absolute file paths ? (<?include "/var/data/file.json"
> ?>)
> And relative paths ? (<?include "./subnets/foo.json"?>)

=> it does fopen(filename.c_str(), "r") so the answer is yes to all questions.

Regards

Francis Dupont <[hidden email]>
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

Christian Kratzer
In reply to this post by Marcin Siodelski
Hi,


On Thu, 31 Aug 2017, Marcin Siodelski wrote:

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

I tend to agree that option A is the most straight forward and I recommend keeping it simple.



Greetings
Christian


--
Christian Kratzer                   CK Software GmbH
Email:   [hidden email]               Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

James Sumners
In reply to this post by Marcin Siodelski

Of the proposed, I prefer option “B”.




On August 31, 2017 at 9:32:52 AM, Marcin Siodelski ([hidden email]) wrote:

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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Shared subnets configuration - input needed

vicky risk
Administrator
Thanks to everyone who replied (and we asked the question on the dhcp-users mailing list too).  It seemed like most people preferred ‘A’ so that is the approach we are pursuing. 

Regards,

Vicky
On Sep 5, 2017, at 5:49 AM, James Sumners <[hidden email]> wrote:

Of the proposed, I prefer option “B”.


On August 31, 2017 at 9:32:52 AM, Marcin Siodelski ([hidden email]) wrote:

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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

Victoria Risk
Internet Systems Consortium





_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users