<div dir="ltr">Some thoughts inline.<div><br></div><div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 11 March 2016 at 23:15, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I have started to get into coding [1] for the Neutron routed networks<br>
specification [2].<br>
<br>
This spec proposes a new association between network segments and<br>
subnets.  This affects how IPAM needs to work because until we know<br>
where the port is going to land, we cannot allocate an IP address for<br>
it.  Also, IPAM will need to somehow be aware of segments.  We have<br>
proposed a host / segment mapping which could be transformed to a host<br>
/ subnet mapping for IPAM purposes.<br>
<br>
I wanted to get the opinion of folks like Salvatore, John Belamaric,<br>
and you (if you interested) on this.  How will this affect the<br>
interface to pluggable IPAM and how can pluggable implementations can<br>
accommodate this change.  Obviously, we wouldn't require<br>
implementations to support it but routed networks wouldn't be very<br>
useful without it.  So, those implementations would not be compatible<br>
when routed networks are deployed.<br></blockquote><div><br></div><div>I think it is ok to augment the IPAM interface. As any API, it needs to evolve.</div><div>I don't think we have a story for its versioning; therefore I reckon that the simplest way to achieve this would be adding a new method for segment-aware IPAM, that only drivers supporting routing networks will be required to implement.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another related topic was brought up in the recent Neutron mid-cycle.<br>
We talked about adding a service type attribute to to subnets.  The<br>
reason for this change is to allow operators to create special subnets<br>
on a network to be used only by certain kinds of ports.  For example,<br>
DVR fip namespace gateway ports burn a public IP for no good reason.<br>
This new feature would allow operators to create a special subnet in<br>
the network with private addressing only to be used by these ports.<br>
<br>
Another example would give operators the ability to use private<br>
subnets for router external gateway ports if shared SNAT is not needed<br>
or doesn't need to use public IPs.<br>
<br>
These are two ways in which subnets are taking on extra<br>
characteristics which distinguish them from other subnets on the same<br>
network.  That is why I lumped them together in to one thread.<br></blockquote><div><br></div><div>I wonder if we could satisfy this requirement with tags - as it seems these subnets are anyway operator-owned you should probably not worry about regular tenants fiddling with them, and therefore the "helper" subnet needed for the fip namespace could just be tagged to the purpose.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Carl<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div>