[ovs-dev] [PATCH 02/24] nx-match: Do not include NXM only matches when putting an OMX match

[Ben Pfaff]

On Wed, Jul 25, 2012 at 09:40:07AM +0900, Simon Horman wrote:
> 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 <yamahata at valinux.co.jp?
> > > > > Signed-off-by: Simon Horman <horms at 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?

Yes, I think so.

(What unexpected metadata fields was Ryu getting?)