On Thu, Jul 18, 2013 at 6:08 AM, <andr...@brinner.de> wrote: > > One thing that I think should be pointed out is that it is NOT the > purpose > > of OVS in-band rules to forward traffic *for other devices* - the rules > > exist *only* to ensure that OVS's own control connection functions > > properly. > > Under that premise my patch certainly doesn't make sense. Once the OVS is > connected to the controller, the controller certainly can add rules which > enables cascaded switches to connect. > > But then the DESIGN paper is at least unclear or misleading >
As I originally replied, I find the DESIGN doc a little inconsistent about the goals of the hidden rules for in-band control. The ARP rules make sense and losing that level of control isn't unreasonable, as there's no persistent connection here. However, the TCP rules hijack the control connection of other devices (unless you work around this by putting them on other trasport-layer ports, but that's a configuration nightmare). I've been looking at this for a couple days and hopefully will have time to write down some more concrete thoughts in the near term - I've been running openflow networks with in-band control since certainly at least early 2011 and have experienced a lot of implementations (although we also took a lot of guidance from the OVS DESIGN document at the time when tweaking things), and what OVS does at this point seems like over-reaching a bit. -- Nick
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
