<div dir="ltr"><p dir="ltr">Interesting, I'll have a look.  We should get this on the neutron drivers' agenda.  The drivers team has been dormant for a couple of weeks but I'm sure it will pick up again very soon.</p>
<p dir="ltr">Carl</p>
<div class="gmail_quote">On Sep 20, 2015 12:28 AM, "Gal Sagie" <<a href="mailto:gal.sagie@gmail.com" target="_blank">gal.sagie@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello All,<br><br></div>I have sent a spec [1] to resume the work on port forwarding API and reference implementation.<br><br></div>Its currently marked as "WIP", however i raised some "TBD" questions for the community.<br></div>The way i see port forwarding is an API that is very similar to floating IP API and implementation<br></div>with few changes:<br><br></div>1) Can only define port forwarding on the router external gateway IP (or additional public IPs<br></div>   that are located on the router.  (Similar to the case of centralized DNAT)<br><br></div>2) The same FIP address can be used for different mappings, for example FIP with IP X<br></div>    can be used with different ports to map to different VM's X:4001  -> VM1 IP    <br></div>    X:4002 -> VM2 IP (This is the essence of port forwarding).<br></div>    So we also need the port mapping configuration fields<br><br></div>All the rest should probably behave (in my opinion) very similar to FIP's (for example<br></div>not being able to remove external gateway if port forwarding entries are configured, <br></div>if the VM is deletd the port forwarding entry is deleted as well and so on..)<br></div>All of these points are mentioned in the spec and i am waiting for the community feedback <br></div>on them.<br><br></div>I am trying to figure out if implementation wise, it would be smart to try and use the floating IP<br></div>implementation and extend it for this (given all the above mechanism described above already<br></div>works for floating IP's)<br></div>Or, add another new implementation which behaves very similar to floating IP's in most aspects <br></div>(But still differ in some)<br></div>Or something else...<br><br></div>Would love to hear the community feedback on the spec, even that its WIP<br><br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Thanks<br>Gal.<br><br>[1] <a href="https://review.openstack.org/#/c/224727/" target="_blank">https://review.openstack.org/#/c/224727/</a><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<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>
<br></blockquote></div>
</div>