On Apr 30, 2013, at 18:54 , ext Jesse Gross wrote: > On Mon, Apr 29, 2013 at 10:21 PM, Rajahalme, Jarno (NSN - FI/Espoo) > <jarno.rajaha...@nsn.com> wrote: >> >> On Apr 29, 2013, at 20:49 , ext Jesse Gross wrote: >> >>> On Sun, Apr 28, 2013 at 11:29 AM, Rajahalme, Jarno (NSN - FI/Espoo) >>> <jarno.rajaha...@nsn.com> wrote: >>>> >>>> Another thing that I came to think only when reading Ben's new tutorial: >>>> Output to the input port is skipped. This would be a problem if you only >>>> have one generic flow based GRE port (as enabled by the last patch in >>>> this series), and you should forward GRE input to another GRE output. >>>> This could be fixed by always allowing output (in xlate_output_action()) >>>> to a tunnel that has cfg.ip_dst_flow set, even if the output port is the >>>> same as the input port. Thoughts? >>> >>> I know that Ben was thinking about ways to relax this check anyways, >>> so it might be good to see how that fits with this. >> >> >> It seems to me that it should be relatively safe to allow packets that have >> been modified by actions to be sent to the input port, if so directed by the >> flow action. At least when the destination mac has been changed. > > The concern that Ben had was that this changes OpenFlow semantics and > that will lead to confusion over time. You coud make a similar > argument about vlans: performing a vlan action should disable the > loopback check. However, that is not what the spec says.
Maybe the cleanest way forward would be a new bit in ofp_port.config to allow output on incoming port (maybe for modified packets only). This would need to be set by the controller for any ports it wants to behave like this, therefore no confusion. Obviously this would be an extension to the current spec. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
