Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Shared subnet requirements (S. M. Hossein Hamidi)
2. Re: Shared subnet requirements ([email protected])
3. Re: Shared subnet requirements (Tomek Mrugalski)
4. Re: Shared subnet requirements ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Jun 2017 15:30:38 +0200
From: "S. M. Hossein Hamidi" <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Shared subnet requirements
Message-ID:
<CAO0ERSwMMcDDqVjVQU2aM9RqrFi=gj-427wk9jfbxefmd_u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
See a few remarks below:
- I don't relate to the term "shared subnet" while considering the
definition. My impression from the term "shared subnet" is a subnet which
is shared between more than a single tenant. However, it seems here it is
more about a shared physical link to DHCP server.
- There is a use case which, I guess, lies in the category of 5 from there
are managed Virtual Private Networks.
Regards,
On Wed, Jun 14, 2017 at 1:46 PM, Tomek Mrugalski <[email protected]> wrote:
> Hi,
>
> One of the major parts of upcoming Kea 1.3 will be shared subnets, an
> ability of the DHCP server to handle multiple IP subnets in the same
> physical location.
>
> Similar to other new features, the process assumes we write down
> requirements first, discuss them and later come up with a design that
> fulfils them. So far, the requirements are ready for review:
>
> http://kea.isc.org/wiki/SharedSubnets
>
> There's also a stub page for a design, but please ignore it for now.
> It's very early work in progress, not ready for broader discussion.
>
> Tomek
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20170614/cebccc25/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 14 Jun 2017 10:40:09 -0400
From: [email protected]
To: "S. M. Hossein Hamidi" <[email protected]>
Cc: Tomek Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Shared subnet requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
Back in February 2017, I did a suggestion to address this issue. At that time,
"shared subnet" wasn't a hot topic... I kindly repost my suggestion :
> In the Mikrotik's RouterOS, there is a "next pool" directive that make
> possible to "chained" subnet to subnet and so on...
>
> Why not using the same kind of concept? If a subnet is exhausted, it will
> look at the new "next-subnet" option, look at it, pick and IP (if available),
> if not, look for an other next "next-subnet" option and so on... That way,
> you don't have to implement some form of grouping.
>
> Obviously each subnet in a chain have their gateway's IP configured on the
> router physical interface (as we already do). The IP of the first subnet in
> the chain must be configure as the "primary" IP on the router interface since
> DHCP we request will come from that IP... Not a big deal.
regards,
Dominic Germain
---------------------------------------------
Administrateur r?seau / Network administrator
Sogetel
www.sogetel.net
[email protected]
> Le 14 juin 2017 ? 09:30, S. M. Hossein Hamidi <[email protected]> a
> ?crit :
>
> Hi,
>
> See a few remarks below:
>
> - I don't relate to the term "shared subnet" while considering the
> definition. My impression from the term "shared subnet" is a subnet which is
> shared between more than a single tenant. However, it seems here it is more
> about a shared physical link to DHCP server.
>
> - There is a use case which, I guess, lies in the category of 5 from there
> are managed Virtual Private Networks.
>
> Regards,
>
>
> On Wed, Jun 14, 2017 at 1:46 PM, Tomek Mrugalski <[email protected]
> <mailto:[email protected]>> wrote:
> Hi,
>
> One of the major parts of upcoming Kea 1.3 will be shared subnets, an
> ability of the DHCP server to handle multiple IP subnets in the same
> physical location.
>
> Similar to other new features, the process assumes we write down
> requirements first, discuss them and later come up with a design that
> fulfils them. So far, the requirements are ready for review:
>
> http://kea.isc.org/wiki/SharedSubnets <http://kea.isc.org/wiki/SharedSubnets>
>
> There's also a stub page for a design, but please ignore it for now.
> It's very early work in progress, not ready for broader discussion.
>
> Tomek
> _______________________________________________
> kea-dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.isc.org/mailman/listinfo/kea-dev
> <https://lists.isc.org/mailman/listinfo/kea-dev>
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20170614/ea907032/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 14 Jun 2017 17:16:10 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected], "S. M. Hossein Hamidi"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Shared subnet requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
W dniu 14.06.2017 o 16:40, [email protected] pisze:
> Back in February 2017, I did a suggestion to address this issue. At
> that time, "shared subnet" wasn't a hot topic... I kindly repost my
> suggestion :
Thanks for bringing that one up.
>> In the Mikrotik's RouterOS, there is a "next pool" directive that make
>> possible to "chained" subnet to subnet and so on...
>>
>> Why not using the same kind of concept? If a subnet is exhausted, it
>> will look at the new "next-subnet" option, look at it, pick and IP
>> (if available), if not, look for an other next "next-subnet" option
>> and so on... That way, you don't have to implement some form of grouping.
While such a logic would be easy to implement, I think we would quickly
regret it. This way is very error prone and can lead to weird corner
cases. Let me give you specific examples:
example 1 (circular dependency)
subnet1, next-subnet pointing to subnet2
subnet2, next-subnet pointing to subnet1
Should this be rejected as invalid configuration? If not, when should
the server stop following the next-server?
example 2 (circular dependency lite)
subnet1, next-subnet pointing to subnet1
This is more absurd version of the earlier one.
example 3:
subnet1, next-subnet points to subnet2
subnet2, next-subnet points to subnet3
subnet3, next-subnet not set
This one looks like valid configuration, but depending on which subnet
would be considered first, the server would look at three, two or just
one subnet when trying to allocate a lease. This would lead to obscure
bugs and unhappy users.
example 4:
subnet1, next-subnet points to subnet3
subnet2, next-subnet points to subnet3
subnet3, next-subnet not set
This looks like misconfiguration (if subnet1 and subnet3 are on the same
physical link and subnet2 is on the same link as subnet3, shouldn't
subnet1 and subnet2 be on the same link)? This is just a trivial case,
the situation may be more complex is there are more subnets.
So am afraid I don't like that approach at all. Yes, it would be easy to
implement, but it would be tricky to set up properly and easy to
misconfigure. What's worse, there wouldn't be an easy way for Kea to
report the misconfiguration.
>> Obviously each subnet in a chain have their gateway's IP configured on
>> the router physical interface (as we already do). The IP of the first
>> subnet in the chain must be configure as the "primary" IP on the
>> router interface since DHCP we request will come from that IP... Not
>> a big deal.
What I was thinking (note I haven't finalized the design proposal yet,
so this may change) is that we will have a separate shared-network
structure that enumerates the subnets. It would also let you to
configure options and perhaps some other parameters that would apply to
all subnets. If an option is specified on both shared network scope and
subnet scope, the subnet would take precedence as it's more specific.
That way if you have 10 shared subnets and 9 of them have value A and
only one subnet has value B, you would specify the option once. It would
apply to all subnets, except the one where the value would be specified
as B. Not sure if we get that kind of flexibility from day 1, but that's
the goal I'd like to reach one day.
Tomek
------------------------------
Message: 4
Date: Wed, 14 Jun 2017 12:59:53 -0400
From: [email protected]
To: Tomek Mrugalski <[email protected]>
Cc: "S. M. Hossein Hamidi" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Shared subnet requirements
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Tomek,
You don't have to feel bad about rejecting my proposition...
My goal is to "fuel" discussions and reflexions about that subject...
It seems that it works ;-)
> Le 14 juin 2017 ? 11:16, Tomek Mrugalski <[email protected]> a ?crit :
>
> W dniu 14.06.2017 o 16:40, [email protected] pisze:
>> Back in February 2017, I did a suggestion to address this issue. At
>> that time, "shared subnet" wasn't a hot topic... I kindly repost my
>> suggestion :
> Thanks for bringing that one up.
>
>>> In the Mikrotik's RouterOS, there is a "next pool" directive that make
>>> possible to "chained" subnet to subnet and so on...
>>>
>>> Why not using the same kind of concept? If a subnet is exhausted, it
>>> will look at the new "next-subnet" option, look at it, pick and IP
>>> (if available), if not, look for an other next "next-subnet" option
>>> and so on... That way, you don't have to implement some form of grouping.
> While such a logic would be easy to implement, I think we would quickly
> regret it. This way is very error prone and can lead to weird corner
> cases. Let me give you specific examples:
>
> example 1 (circular dependency)
> subnet1, next-subnet pointing to subnet2
> subnet2, next-subnet pointing to subnet1
>
> Should this be rejected as invalid configuration? If not, when should
> the server stop following the next-server?
>
> example 2 (circular dependency lite)
>
> subnet1, next-subnet pointing to subnet1
> This is more absurd version of the earlier one.
>
> example 3:
> subnet1, next-subnet points to subnet2
> subnet2, next-subnet points to subnet3
> subnet3, next-subnet not set
>
> This one looks like valid configuration, but depending on which subnet
> would be considered first, the server would look at three, two or just
> one subnet when trying to allocate a lease. This would lead to obscure
> bugs and unhappy users.
>
> example 4:
> subnet1, next-subnet points to subnet3
> subnet2, next-subnet points to subnet3
> subnet3, next-subnet not set
>
> This looks like misconfiguration (if subnet1 and subnet3 are on the same
> physical link and subnet2 is on the same link as subnet3, shouldn't
> subnet1 and subnet2 be on the same link)? This is just a trivial case,
> the situation may be more complex is there are more subnets.
>
> So am afraid I don't like that approach at all. Yes, it would be easy to
> implement, but it would be tricky to set up properly and easy to
> misconfigure. What's worse, there wouldn't be an easy way for Kea to
> report the misconfiguration.
>
>>> Obviously each subnet in a chain have their gateway's IP configured on
>>> the router physical interface (as we already do). The IP of the first
>>> subnet in the chain must be configure as the "primary" IP on the
>>> router interface since DHCP we request will come from that IP... Not
>>> a big deal.
> What I was thinking (note I haven't finalized the design proposal yet,
> so this may change) is that we will have a separate shared-network
> structure that enumerates the subnets. It would also let you to
> configure options and perhaps some other parameters that would apply to
> all subnets. If an option is specified on both shared network scope and
> subnet scope, the subnet would take precedence as it's more specific.
>
> That way if you have 10 shared subnets and 9 of them have value A and
> only one subnet has value B, you would specify the option once. It would
> apply to all subnets, except the one where the value would be specified
> as B. Not sure if we get that kind of flexibility from day 1, but that's
> the goal I'd like to reach one day.
>
> Tomek
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 39, Issue 3
**************************************
