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

[Simon Horman]

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?

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.