On Oct 17, 2013, at 11:47 AM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Oct 16, 2013 at 04:16:05PM -0700, Jarno Rajahalme wrote: >> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com> > > This raises an issue that I had resolved one way, and you resolved > another (even if you did not realize it). I am not certain that I chose > the right way, so let me present the issue for discussion. > > The definition of the "set-ecn" action in OpenFlow 1.1 is: > > Replace the existing IP ECN value and up- > date the IP checksum. Only applies to IPv4 > packets. > > It's the "only applies to IPv4" that concerns me. According to a plain > reading of the specification, this makes the action do nothing (or be > invalid) for IPv6. But a spec standards lawyer[*] would notice that > OF1.1 did not support IPv6, and so "only applies to IPv4" could be read > as meaning that the action does not apply to the other protocols that > OF1.1 does support (e.g. it is meaningless for ARP, MPLS, …)
I did not read it in the sense of "must not apply on IPv6". Considering that even OF1.1 *has* minimal support for IPv6, in the sense that it is legal to match on IPv6 ether type, in which case my reading of the spec would change the ECN in a case where your more strict reading would not. > [*] Catch me playing a spec standards lawyer in a special guest > appearance on an upcoming episode of "CSI: OpenFlow", next > Wednesday at ten (nine central)! > > I interpreted this according to the plain wording in other cases, and > so, for example, OFPAT_SET_DSCP only sets the DSCP for IPv4 and becomes > a no-op for IPv6. Maybe I was wrong. Either way, I would like to be > consistent here. I noticed this, and kept wondering why, without thinking to read the spec that strictly. I think your reading is safer, since a controller might actually depend on it. Will update accordingly. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
