On Tue, Jul 24, 2012 at 05:20:20PM -0700, Ben Pfaff wrote: > On Wed, Jul 25, 2012 at 08:57:08AM +0900, Simon Horman wrote: > > On Tue, Jul 24, 2012 at 11:53:49AM -0700, Ben Pfaff wrote: > > > On Mon, Jul 23, 2012 at 03:16:31PM +0900, Simon Horman wrote: > > > > Suggested by Isaku Yamahata > > > > > > > > Cc: Isaku Yamahata <yamah...@valinux.co.jp? > > > > Signed-off-by: Simon Horman <ho...@verge.net.au> > > > > > > I don't think I agree with this idea. There is no incompatibility > > > between OXM and NXM and in fact the NXM classes are reserved > > > explicitly in OF1.2 for Nicira use. What's the benefit to omitting > > > important details from a flow? > > > > Is the implication of this that a parser should just ignore fields that it > > doesn't understand? > > > > The reason that this came up was that I was testing OVS using Ryu and > > Ryu does strict parsing, complaining bitterly if a field which it > > doesn't understand is present. > > No, I don't think a parser should ignore fields that it doesn't > understand[*], and I think (without knowing anything about Ryu) that > Ryu is probably doing the right thing. Here are the two possibilities > and my opinion on their implications: > > - OVS only sends OXM-defined fields in OXM contexts. Suppose > a controller is initializing itself by dumping a flow table > and comparing against what it thinks should be there. If an > NXM controller was running before, then the new controller > could see duplicate flows (that differ only in match fields > it doesn't see), and it could see flows that it thinks have > match fields it understands but really have hidden match > fields that it doesn't. If it tries to delete or change any > of those flows, it can easily make the problem worse, > because it could create more "duplicates" or not match > anything for deletion because of the lack of the hidden > fields. The controller could get very confused and just > foul everything up more and more over time. > > - OVS sends the full match, including NXM fields. Consider > the same situation. The controller may complain bitterly > but it can easily recognize what the situation is, which > gives it some clear options. It could, for example, copy > the raw match bytewise into a flow_mod to delete those flows > individually, or it could just send a "delete all flows" > message. > > [*] One exception is "packet-in" messages, where I think that the > controller should just ignore the extra metadata fields it doesn't > recognize. There isn't the same problem as above in that > situation. (That's why OVS has the "loose" versions of NXM/OXM > parsing.)
The test-case was using packet-in messages. So to clarify, it would be best if Ryu ignored unknown OXM fields in packet-in messages? With regards to non-packet-in messages, I'm also not sufficiently familiar with Ryu to say what it should do. But in general I believe it would be up to the Ryu application that is in use and providing the option to do loose parsing seems logical to me. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
