<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 7:02 PM, Hong Hui Xiao <span dir="ltr"><<a href="mailto:xiaohhui@cn.ibm.com" target="_blank">xiaohhui@cn.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all.<br>
<br>
I did some investigation recently. And I think we can start some<br>
discussion now.<br>
<br>
All below thinking is based on the current implementation of neutron. With<br>
routed network, a subnet will be considered as a L2 domain. Things might<br>
change.<br>
<br>
I think routed network in OVN can implement in this way:<br>
User creates provider network. For example:<br>
neutron net-create provider-101 --shared \<br>
--provider:physical_network providernet \<br>
--provider:network_type vlan \<br>
--provider:segmentation_id 101<br>
<br>
These attributes "--provider:physical_network" will be recorded in the<br>
external_ids of Logical_Switch in OVN_Northbound.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
To Russell:<br>
I will expect OVN to do the following things.<br>
1) The OVN_Southbound will have the latest information of<br>
"ovn-bridge-mappings" of each Chassis.<br>
2) After creating a new network with "provider:physical_network" set, the<br>
OVN will update Logical_Switch in OVN_Northbound.<br>
The Logical_Switch will have new key:value pair in external_ids.<br>
neutron:available_hosts="compute-host1,compute-host2"<br>
3) When a compute host join/leave the OpenStack topology, or a compute<br>
host just updates its ovn-bridge-mappings, OVN should updated<br>
Logical_Switch with related physical_network. This is a bottom-up change,<br>
which is similar to the port status change.<br>
4) networking-ovn should be able to catch the update of Logical_Switch in<br>
2) & 3) and update the SegmentHostMapping, which will be introduced in<br>
[2].<br>
<br>
I think 1) 2) & 3) need additional work in OVN code. And 4) need code<br>
change in networking-ovn.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​There's some work happening in OVN where the information currently in ovn-bridge-mappings on each hypervisor will become accessible in the OVN Southbound database.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>As a nice side effect, the Neutron plugin should be able to read those bridge mappings from the OVN database and have all of the information it needs.​</div></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><font face="arial black, sans-serif">Russell Bryant</font></div></div></div>
</div></div>