<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2019 at 9:40 PM Han Zhou <<a href="mailto:zhouhan@gmail.com">zhouhan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Tue, Mar 5, 2019 at 7:24 PM Ben Pfaff <<a href="mailto:blp@ovn.org" target="_blank">blp@ovn.org</a>> wrote:<br>
> What's the effective difference between an OVN deployment with 3 zones,<br>
> and a collection of 3 OVN deployments? Is it simply that the 3-zone<br>
> deployment shares databases? Is that a significant advantage?<br>
<br>
Hi Ben, based on the discussions there are two cases:<br>
<br>
For completely separated zones (no overlapping) v.s. separate OVN<br>
deployments, the difference is that separate OVN deployments requires<br>
some sort of federation at a higher layer, so that a single CMS can<br>
operate multiple OVN deployments. Of course separate zones in same OVN<br>
still requires changes in CMS to operate but the change may be smaller<br>
in some cases.<br>
<br>
For overlapping zones v.s. separate OVN deployments, the difference is<br>
more obvious. Separate OVN deployments doesn't allow overlapping.<br>
Overlapping zones allows sharing gateways between different groups of<br>
hypervisors.<br>
<br>
If the purpose is only reducing tunnel mesh size, I think it may be<br>
better to avoid the zone concept but instead create tunnels (and bfd<br>
sessions) on-demand, as discussed here:<br>
<a href="https://mail.openvswitch.org/pipermail/ovs-discuss/2019-March/048281.html" rel="noreferrer" target="_blank">https://mail.openvswitch.org/pipermail/ovs-discuss/2019-March/048281.html</a><br>
<br>
Daniel or other folks please comment if there are other benefit of<br>
creating zones.<br>
<br>
Thanks,<br>
Han<br></blockquote><div><br></div><div>The original discussion came about when I was consulting with a very large bank who were considering network designs for an application cloud. In that case, all chassis were in a single site, and the desire was to be able to separate groups of chassis into trust zones with no East-West communication between zones. Of course this same result can be handled via network segregation and firewalling, but zones would provide an additional layer of security enforcement. In their case, the choice due to policy was to have separate flow controllers and software routers in each zone rather than rely on firewalls alone, but this increased the hardware footprint.</div><div><br></div><div>When I discovered that there was no way to prevent tunnels from being formed between all chassis, that became an obvious problem for edge scenarios. To me that is the more pressing issue, which dynamic tunnels would solve. However, the ability to have separate transit zones would also be a useful feature, in my opinion.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Dan Sneddon<br></div></div></div>