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

Ben Pfaff blp at nicira.com
Wed Jul 25 00:20:20 UTC 2012


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.)



More information about the dev mailing list