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
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
