On Tue, Dec 11, 2012 at 11:41:39PM -0800, Rob Sherwood wrote:
> On Tue, Dec 11, 2012 at 11:33 PM, Ben Pfaff <b...@nicira.com> wrote:
> > On Tue, Dec 11, 2012 at 09:55:07PM -0800, Rob Sherwood wrote:
> >> Is it your interpretation that for OF1.0, the spec is *clear* that one
> >> should not match on cookie in a DELETE or do you think it is ambiguous
> >> and you've chosen the interpretation that it does not? More to the
> >> point: if I were to submit a patch to change the behavior to match on
> >> cookie in this situation, would you be inclined to accept it?
> >
> > This is the first I've heard of a disagreement here. What makes you
> > think that cookie is significant for matching on flow_mod operations in
> > OF1.0? OVS doesn't use the cookie for matching in any kind of OF1.0
> > flow_mod. My (overly quick, I admit) reading of the OpenFlow 1.0
> > reference implementation, both kernel and user datapath, is that it
> > doesn't do that either.
>
>
> The quote from the spec is (S5.3.3):
>
> "The cookie field is an opaque data value that is set by the
> controller. It is not
> used in any matching functions, and thus does not need to reside in hardware.
> The value -1 (0xfffffffffff) is reserved and must not be used.
> It is required
> that when command is OFPC_MODIFY or OFPC_MODIFY_STRICT that matched
> flows have their cookie field updated appropriately."
>
> Note the last line explicitly calls out that cookies should be updated
> on match, so this is different from OVS's behavior.
OVS does update the cookie field on OFPC_MODIFY and OFPC_MODIFY_STRICT.
As DESIGN says:
- OFPFC_MODIFY and OFPFC_MODIFY_STRICT updated the cookie for
the flow or flows that it modified.
> It is not explicitly about what to do on DELETE, but it seems like
> from Justin's 2010 thread that the intent[1] was to be able to match
> and delete by it and this is certainly consistent with the MATCH
> behavior.
I have always interpreted this statement that limits updating the cookie
to OFPC_MODIFY and OFPC_MODIFY_STRICT as meaning that:
- On OFPC_ADD we don't "update" the cookie. It's a new flow so
we're setting the initial cookie. (Even if the new flow is
replacing an existing flow with the same match criteria, it's
still logically a new flow, not an update to an old one.)
- On OFPC_MODIFY and OFPC_MODIFY_STRICT, we update the cookie,
it makes sense in that case.
- On OFPC_DELETE and OFPC_DELETE_STRICT, there would be no point
in updating the cookie, since the flow is going away, so the
spec doesn't require it.
I don't see anything in the OF1.0 spec that mentions matching on a
cookie. I think that interpreting a sentence that says that delete
operations don't *update* a cookie to mean that modify operations
*match* on the cookie is overreaching.
> So, I think there are two questions:
>
> 1) What does the spec actually prescribe?
> 2) What _should_ the right behavior be?
>
> For (1), I claim it's ambiguous and for (2) there seems to be
> consensus that it really should use cookie to DELETE, so... will you
> accept my patch below :-)
This would change long-standing behavior in OVS, that has existed for
years, since before the OVS 1.0 release. The same behavior also exists
in the OpenFlow 1.0 reference implementation. This will break real
software.
With this change, it becomes impossible to delete an individual flow in
OF1.0 without knowing its cookie. One effect is that it becomes
impossible to delete all the flows in a switch in a single operation
(which is useful and which has always been possible before) in OF1.0 if
there is more than one unique cookie in the flow table. I am, also,
almost certain that it will break NVP, which I have been told prefers to
assign random cookie values to some flows, which it then throws away, so
that it doesn't even keep track of what the cookies are.
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
