<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div class="bloop_markdown">
<p>Of the proposed, I prefer option “B”.</p>
<p></p>
</div>
<div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<br>
</div>
<br>
<div id="bloop_sign_1504615729166629120" class="bloop_sign"></div>
<br>
<p class="airmail_on">On August 31, 2017 at 9:32:52 AM, Marcin Siodelski (<a href="mailto:marcin@isc.org">marcin@isc.org</a>) wrote:</p>
<blockquote type="cite" class="clean_bq"><span>
<div>
<div></div>
<div>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>
</div>
</div>
</span></blockquote>
</div>
<div class="bloop_markdown">
<p></p>
</div>
</body>
</html>