On Wed, Apr 20, 2016 at 11:38:31AM -0700, Jesse Gross wrote: > Thanks for that analysis. I agree with you that this looks safe. I'm > glad - there are fewer corner cases than I was expecting. > > One minor comment that I noticed on the patch itself - I don't know if > the port mapping functions are handling IPsec variants of tunnels > correctly in all situations (or maybe are handling them by accident). > Since both IPsec and non-IPsec ports share the same dpif_port name, we > might get the wrong class back and then it seems like we don't handle > the IPsec class types when converting between names and types, which > could itself be an independent bug. Can you take a look?
Sure, I am not too familiar with the ipsec code. Looking at it, I don't see anything really special about it. It just requires that some configuration is available and that the ovs-monitor-ipsec daemon is running. When adding and removing devices, the same procedure would still work. So, I don't see why we would need to handle it specially, do you? On the other hand, I noticed that VXLAN-GBP tunnels will have the problem of sharing the same dpif_port name with non GBP tunnels. That means that tunnels using different remote IPs with the same port all must be GBP or not GBP. If we used extensions for GPE, that would also apply there. Maybe we should just add an infix gbp and gpe, resulting in vxlan_sys_gbp_4789 and vxlan_sys_gpe_4789. How about that? Regards. Cascardo. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
