[ovs-discuss] Flow removed message bug

[Derek Cormier]

Justin,

I see what you mean and I agree that a switch shouldn't store 
unnecessary information. But is it really a burden in this case? The 
wildcards are stored in a single 32-bit integer, so no extra space is 
needed. I also don't think it should cause compatibility problems with 
controllers. If a controller sees that the dl_type is 5, then it doesn't 
need to look at the unnecessary wildcard fields.

However, I don't know much about the implementation of switches and 
controllers. Please let me know if I'm making some incorrect assumptions.

Thanks,
-- Derek

On 02/21/2011 02:57 PM, Justin Pettit wrote:
> On Feb 18, 2011, at 1:13 PM, kk yap wrote:
>
>> 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.
> Thanks for catching that, KK.  I do think it's reasonable (and less surprising) that the "wildcards" field from the "match" be maintained across Flow Mod and Flow Removed.  However, I don't think that the rest of the fields should be maintained if they correspond to a field that is indicated as being wildcarded; it places a burden on the switch implementor to maintain data that the caller has indicated is not relevant.  All this would be more appropriate on the openflow-spec mailing list, though.
>
> Regardless, as far as I know, all OpenFlow switches (hardware and software) are based on either the reference implementation or Open vSwitch.  This means that the de facto standard is that those wildcard bits are normalized.  I'm afraid that if we modify the switch to be more in line with the spec, that we'll actually be less interoperable with other OpenFlow controllers.  If we can convince the majority of OpenFlow switches out there to stop normalizing the wildcard bits in their OpenFlow 1.0 implementations, then we will certainly change this behavior in Open vSwitch.  However, I suspect it is unlikely to occur now.  If anyone feels passionately about it, I encourage them to get the ball rolling on the openflow-spec or openflow-dev mailing lists.
>
> --Justin
>
>
>
>