On Fri, Mar 22, 2019 at 11:22:50AM +0000, Lucas Alvares Gomes wrote: > Hi, > > Getting back to this topic because we do have people (read clients) > interested in this work for their Telco/Edge computing uses cases as a > way to preventing each edge site to try to create tunnels with every > node on every site. > > Also, another request we saw which this feature would help is related > to security where people want to create "trust zones" and prevent > computes in a more secure zone to communicate with a less secure zone. > > As Dan Sneddon pointed out in this thread, it's possible to use > firewalls to workaround these problems but the approach is not ideal > (and may result in negative consequences) because each Chassis in OVN > will still try again and again to form the tunnel mesh with every > other Chassis but it will fail/timeout over and over. > > Regarding to the approach to implement this I see we have a couple > ideas floating around: > > 1. Explicit setting the transport zone(s) in the OpenVSwitch table for > the Chassis. > > 2. Dynamically creating tunnels between Chassis that are logically > connected with each other. > > 3. Creating the tunnels on demand when the first packet is going > to/from a Chassis (although Ben has stated that he is not pushing for > this). > > So, while every approach has their pos/cons, personally (and also by > talking to some work colleagues), I think that 1. is probably the > best/most straight forward way to go with this because since it's > explicit it is also the easiest to troubleshoot/monitor what's going > on with the network. The approach 2. and 3., while very interesting > from an engineering point of view, might not be so interesting for > folks responsible for monitoring the network because it leaves the > compute nodes in some "unknown" state (is there a tunnel between > Chassis A and B ? no/yes/not yet ?). > > If there's no objection from people in this thread (specially Han and > Ben) I would be more than happy in helping implementing this feature.
I don't object. I'm happy to see OVN become appropriate for more use cases. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
