<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1060054937;
mso-list-type:hybrid;
mso-list-template-ids:-326971728 787021446 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks Salvatore. Here are my thoughts, hopefully there’s some merit to them:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">With implicit allocations, the thinking is that this is where a subnet is created in a backward-compatible way with no subnetpool_id and the subnets API’s continue
to work as they always have.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In the case of a specific subnet allocation request (create-subnet passing a pool ID and specific CIDR), I would look in the pool’s available prefix list and
carve out a subnet from one of those prefixes and ask for it to be reserved for me. In that case I know the CIDR I’ll be getting up front. In such a case, I’m not sure I’d ever specify my gateway using notation like 0.0.0.1, even if I was allowed to. If
I know I’ll be getting 10.10.10.0/24, I can simply pass gateway_ip as 10.10.10.1 and be done with it. I see no added value in supporting that wildcard notation for a gateway on a specific subnet allocation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In the case of an “any” subnet allocation request (create-subnet passing a pool ID, but no specific CIDR), I’m already delegating responsibility for addressing
my subnet to Neutron. As such, it seems reasonable to not have strong opinions about details like gateway_ip when making the request to create a subnet in this manner.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">To me, this all points to not supporting wildcards for gateway_ip and allocation_pools on subnet create (even though it found its way into the spec). My opinion
(which I think lines up with yours) is that on an any request it makes sense to let the pool fill in allocation_pools and gateway_ip when requesting an “any” allocation from a subnet pool. When creating a specific subnet from a pool, gateway IP and allocation
pools could still be passed explicitly by the user.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Ryan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Salvatore Orlando [mailto:sorlando@nicira.com]
<br>
<b>Sent:</b> Monday, March 09, 2015 6:06 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] [api][neutron] Best API for generating subnets from pool<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Greetings!<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Neutron is adding a new concept of "subnet pool". To put it simply, it is a collection of IP prefixes from which subnets can be allocated. In this way a user does not have to specify a full CIDR, but simply a desired prefix length, and
then let the pool generate a CIDR from its prefixes. The full spec is available at [1], whereas two patches are up for review at [2] (CRUD) and [3] (integration between subnets and subnet pools).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">While [2] is quite straightforward, I must admit I am not really sure that the current approach chosen for generating subnets from a pool might be the best one, and I'm therefore seeking your advice on this matter.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A subnet can be created with or without a pool.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Without a pool the user will pass the desired cidr:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">POST /v2.0/subnets<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">{'network_id': 'meh',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'cidr': '<a href="http://192.168.0.0/24">192.168.0.0/24</a>'}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Instead with a pool the user will pass pool id and desired prefix lenght:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">POST /v2.0/subnets<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">{'network_id': 'meh',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'prefix_len': 24,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'pool_id': 'some_pool'}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The response to the previous call would populate the subnet cidr.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">So far it looks quite good. Prefix_len is a bit of duplicated information, but that's tolerable.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It gets a bit awkward when the user specifies also attributes such as desired gateway ip or allocation pools, as they have to be specified in a "cidr-agnostic" way. For instance:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">POST /v2.0/subnets<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">{'network_id': 'meh',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'gateway_ip': '0.0.0.1',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'prefix_len': 24,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'pool_id': 'some_pool'}<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">would indicate that the user wishes to use the first address in the range as the gateway IP, and the API would return something like this:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">POST /v2.0/subnets<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">{'network_id': 'meh',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'cidr': '<a href="http://10.10.10.0/24">10.10.10.0/24</a>'<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'gateway_ip': '10.10.10.1',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'prefix_len': 24,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'pool_id': 'some_pool'}<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The problem with this approach is, in my opinion, that attributes such as gateway_ip are used with different semantics in requests and responses; this might also need users to write client applications expecting the values in the response
might differ from those in the request.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I have been considering alternatives, but could not find any that I would regard as winner.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I therefore have some questions for the neutron community and the API working group:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) (this is more for neutron people) Is there a real use case for requesting specific gateway IPs and allocation pools when allocating from a pool? If not, maybe we should let the pool set a default gateway IP and allocation pools. The
user can then update them with another call. Another option would be to provide "subnet templates" from which a user can choose. For instance one template could have the gateway as first IP, and then a single pool for the rest of the CIDR.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2) Is the action of creating a subnet from a pool better realized as a different way of creating a subnet, or should there be some sort of "pool action"? Eg.:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">POST /subnet_pools/my_pool_id/subnet<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">{'prefix_len': 24}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">which would return a subnet response like this (note prefix_len might not be needed in this case)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">{'id': 'meh',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'cidr': '<a href="http://192.168.0.0/24">192.168.0.0/24</a>',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'gateway_ip': '192.168.0.1',<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'pool_id': 'my_pool_id'}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I am generally not a big fan of RESTful actions. But in this case the semantics of the API operation are that of a subnet creation from within a pool, so that might be ok.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3) Would it be possible to consider putting information about how to generate a subnet from a pool in the subnet request body as follows?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">POST /v2.0/subnets<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">{<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'pool_info':<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> {'pool_id': my_pool_id,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 'prefix_len': 24}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This would return a response like the previous.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This approach is in theory simple, but composite attributes proved to a difficult beast already - for instance you can look at external_gateway_info in the router definition [4]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks for your time and thanks in advance for your feedback.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Salvatore<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://review.openstack.org/#/c/148698/">https://review.openstack.org/#/c/148698/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[3] <a href="https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py">https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[4] <a href="http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106">http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106</a><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>