On Thu, Jan 2, 2014 at 6:01 PM, Chris Luke <chr...@flirble.org> wrote: >> On Jan 2, 2014, at 16:51, Jesse Gross <je...@nicira.com> wrote: >>> On Mon, Dec 23, 2013 at 11:46 PM, Chris Luke <chr...@flirble.org> wrote: >>> Jesse Gross wrote (on Tue 24 Dec, 2013 at 03:05 GMT): >>>> * This type of concept has come up before and its usually in the >>>> context of allowing an existing daemon like lldpad to be run on an OVS >>>> port. At a minimum, we would need to make sure that whatever we do >>>> here is compatible with that and ideally we would be able to >>>> essentially solve both problems at the same time. If you are planning >>>> on running routing protocol daemons then maybe it is already pretty >>>> similar. >>> >>> >>> Exactly. I have lldpd running on my test setup and it appears to work >>> fine, but I'll dig into it to be sure. >> >> Do the packets sent from the daemon go through OVS? It doesn't seem >> like they would and while this would likely work in many cases, it is >> odd. > > No, from the daemon they go directly out the port. The case that needs OVS > involvement is incoming packets.
I believe that it works correctly in most cases but it seems somewhat weird and asymmetric. Is there anything that we can do about it? >>> If you are suggesting a new openflow action, I think that's a broader >>> conversation point. 'normal' in the OF protocol is imprecise, but it >>> seems to suggest that the device do whatever is 'normal' for it. OVS >>> took the approach of being a switch, whereas I want it to behave like a >>> Linux machine normally would. I saw these as discrete modes of >>> operation, hence the approach of switching which behaviour is desired. >> >> It seems impossibly confusing for OVS to have a switch that makes it >> operate in a non-OVS mode, including with external configuration, etc. >> Furthermore, I suspect that the most common use case of this would be >> to have an LLDP daemon running on a port but OVS doing the traffic >> switching. In that case, you could actually need to use both types of >> "normal" simultaneously. I see that you added an additional action in >> the newest revision of patch but that just means we have multiple very >> similar mechanisms to configure this. > > Yes, I've come to that conclusion independently. I've split the patch up. > Will post the series later. Originally I wanted to avoid custom open flow > actions, since in my case I am modeling devices that are layer 3 focused. But > I don't now think that's as big a deal as I did. > > If you feel the switch mode idea is a non-starter then I'll abandon it. Yeah, I'm pretty strongly opposed to hanging more things onto the normal action. In OVS there's a history of breaking things out of normal because they tend to not interact very well with the OpenFlow pipeline so I'm not eager to mix more things in. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
