On Dec 2, 2014, at 11:34 AM, Ben Pfaff <b...@nicira.com> wrote: > On Tue, Dec 02, 2014 at 11:30:26AM -0800, Ben Pfaff wrote: >> On Mon, Dec 01, 2014 at 10:50:45PM -0800, varanasi sandhya wrote: >>> OFPFF_CHECK_OVERLAP flag Issue: >>> >>> When OFPFF_CHECK_OVERLAP flag is set at RYU controller in ofctl_v1_3.py >>> code in the mod_flow_entry definition, OVS should ideally return >>> OFPFMFC_OVERLAP error on inserting a duplicate flow with same priority and >>> match. But instead the new flow entry just replaces the old flow. >> >> Do you have evidence to support this interpretation of the OpenFlow >> specification? > > In fact, this is an unresolved question in the OpenFlow specification > working group. Open issue EXT-406 addresses it. I just added a > comment to try to revive the issue.
I bumped to this while working on the OF bundles code.. Would you mind summarizing which way EXT-406 proposes to address this? As of now, this is what OF 1.4.0 spec says: “For add requests (OFPFC_ADD) with the OFPFF_CHECK_OVERLAP flag set, the switch must first check for any overlapping flow entries in the requested table. Two flow entries overlap if a single packet may match both, and both entries have the same priority. If an overlap conflict exists between an existing flow entry and the add request, the switch must refuse the addition and respond with an ofp_error_msg with OFPET_FLOW_MOD_FAILED type and OFPFMFC_OVERLAP code. For non-overlapping add requests, or those with no overlap checking, the switch must insert the flow entry in the requested table. If a flow entry with identical match fields and priority already resides in the requested table, then that entry, including its duration, must be cleared from the table, and the new flow entry added. If the OFPFF_RESET_COUNTS flag is set, the flow entry counters must be cleared, otherwise they should be copied from the replaced flow entry. No flow-removed message is generated for the flow entry eliminated as part of an add request; if the controller wants a flow-removed message it should explicitly send a delete request for the old flow entry prior to adding the new one." This could be easily read to mean that the overlap flag is to be checked first, leading to a flow with an identical match (and priority) to be also considered an overlap. OVS currently does these checks in the reverse order. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
