<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" ><p class="p1" ><span class="s1" >Hi everyone,</span></p>
<p class="p1" ><span class="s1" >I want to open up the discussion regarding how to support OVN VTEP gateway deployment and its lifecycle in Neutron. </span></p>
<p class="p1" ><span class="s1" >In the "Life Cycle of a VTEP gateway" part in the OVN architecture document (<a href="http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf" >http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf</a></span>), step 3 is where the Neutron OVN plugin is involved. At a minimum, the Neutron OVN plugin will enable setting the type as "vtep" and the vtep-logical-switch and vtep-physical-switch options in the OVN_Northbound database.</p>
<p class="p2" > </p>
<p class="p1" ><span class="s1" >There are 2 parts to the proposal/discussion - a short term solution and a long term one:</span></p>
<p class="p1" ><span class="s1" >A short term solution (proposed by Russell Bryant) is similar to the work that was done for container support in OVN - using a binding profile <a href="http://networking-ovn.readthedocs.org/en/latest/containers.html" >http://networking-ovn.readthedocs.org/en/latest/containers.html</a></span>. A ovn logical network/switch can be mapped to a vtep logical gateway by creating a port in that logical network and creating a binding profile for that port in the following manner:</p>
<p class="p1" ><span class="s1" >neutron port-create --binding-profile '{"vtep-logical-switch":"vtep_lswitch_key", "vtep-physical-switch":"vtep_pswitch_key"}' private.</span></p>
<p class="p1" ><span class="s1" >Where vtep-logical-switch and vtep-physical-switch should have been defined in the OVN_Southbound database by the previous steps (1,2) in the life cycle. </span></p>
<p class="p2" > </p>
<p class="p1" ><span class="s1" >For the longer term solution, there needs to be a discussion:</span></p>
<p class="p1" ><span class="s1" >Should the knowledge about the physical and logical step gateway should be exposed to Neutron - if yes how? This would allow a Neutron NB API/extension to bind a “known” vtep gateway to the neutron logical network. This would be similar to the workflow done in the networking-l2gw extension <a href="https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst" >https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst</a></span></p>
<p class="p1" ><span class="s1" >1. Allow the admin to define and manage the vtep gateway through Neutron REST API.</span></p>
<p class="p1" ><span class="s1" >2. Define connections between Neutron networks and gateways. This is conceptually similar to Step 3 of the step gateway performed by the OVN Plugin in the short term solution.</span></p>
<p class="p3" ><span class="s1" >OR</span></p>
<p class="p3" ><span class="s1" >Should OVN pursue it’s own Neutron extension (including vtep gateway support).</span></p>
<p class="p4" > </p>
<p class="p1" ><span class="s1" >Thanks Amitabha</span></p></div>
<div dir="ltr" ><table></table></div></div></div></div></div></div><BR>