Hi, Actually on page 37 of the OpenFlow 1.0 spec, it is stated that "The match, cookie, and priority fields are the same as those used in the flow setup request.". I interpret that to be that the switch should not change them.
Caveat: I am not saying or asking the switch not to normalize the flow for efficiency. But when the flow_removed is triggered, the match returned should be the same as the flow mod. How the mapping back is done is completely out of the spec IMHO. Does that make sense? Regards KK On 18 February 2011 12:52, Justin Pettit <jpet...@nicira.com> wrote: > This behavior would be best described as under-specified in the OpenFlow > spec. The OpenFlow reference implementation makes the same modifications to > the one you're seeing in OVS. It would probably be worth bringing up on the > openflow-spec mailing list, if you'd like to see this behavior changed/better > defined. > > --Justin > > > On Feb 17, 2011, at 7:21 PM, Derek Cormier wrote: > >> Yes, that's true. I though about using the cookie field, but I want to leave >> that open for a future use. My main concern is that it goes against the >> OpenFlow protocol. >> >> - Derek >> >> On 02/18/2011 12:05 PM, Justin Pettit wrote: >>> What about flow cookies? They're 64-bit identifiers that exist in both the >>> Flow Mod and Flow Removed messages. >>> >>> --Justin >>> >>> >>> On Feb 17, 2011, at 6:50 PM, Derek Cormier wrote: >>> >>>> Sure, let me explain the problem. I am maintaining a copy of the flows in >>>> memory outside of the controller (Nox). When a flow is removed, I need to >>>> remove it from the stored flows. However, if the wildcards are not exact >>>> in the removed message, I cannot identify exactly which flow it is. I >>>> could have a flow with those extra fields set to 0 and I would think it's >>>> that flow being deleted, when it's really a different one. >>>> >>>> Thanks, >>>> - Derek >>>> >>>> On 02/18/2011 11:40 AM, Justin Pettit wrote: >>>>> Hi, Derek. I just wanted to let you know that we're still discussing how >>>>> to best handle this. How difficult is it from your perspective if OVS >>>>> continued to behave in this manner? There was a time when this >>>>> normalization was more important from a performance perspective than it >>>>> is now, so we may be able to either stop normalizing or at least store >>>>> the original wildcards. However, OVS has behaved this way for a long >>>>> time, and we haven't heard other application writers have issues with it. >>>>> I understand how it could be confusing, though. >>>>> >>>>> --Justin >>>>> >>>>> >>>>> On Feb 16, 2011, at 1:39 AM, Justin Pettit wrote: >>>>> >>>>>> Okay, that makes a bit more sense. My guess is that if you look in >>>>>> ovs-vswitchd's logs, you'll see some messages about "normalization >>>>>> changed ofp_match". Internally, we're clearing those other wildcard >>>>>> bits, since they're meaningless for non-IP/ARP flows (such as your flow >>>>>> definition with ethertype of 5). I'll talk with Ben about how we want >>>>>> to handle this from an OpenFlow-compatiblity standpoint tomorrow. >>>>>> >>>>>> --Justin >>>>>> >>>>>> >>>>>> On Feb 16, 2011, at 12:51 AM, Derek Cormier wrote: >>>>>> >>>>>>> Great. I also made a mistake about the field. It was dl_type, not >>>>>>> dl_src. It actually works fine for dl_src. >>>>>>> >>>>>>> - Derek >>>>>>> >>>>>>> On 02/16/2011 05:36 PM, Justin Pettit wrote: >>>>>>>> No problem. Most of us are subscribed to both. :-) We'll take a >>>>>>>> look at it in the morning, California time. I don't expect it will be >>>>>>>> a difficult fix. >>>>>>>> >>>>>>>> Thanks for reporting it. >>>>>>>> >>>>>>>> --Justin >>>>>>>> >>>>>>>> >>>>>>>> On Feb 16, 2011, at 12:26 AM, Derek Cormier wrote: >>>>>>>> >>>>>>>>> Now that I think about it, this should have been posted to the dev >>>>>>>>> board. Sorry about that! >>>>>>>>> >>>>>>>>> - Derek >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> discuss mailing list >>>>>>>>> discuss@openvswitch.org >>>>>>>>> http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org >>>>> >>> >>> >> > > > _______________________________________________ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
