On 9/15/25 3:08 PM, Reuven Plevinsky via dev wrote: > From: Eli Britstein <[email protected]> > > > Introduce eth-type field to tunnel metadata that is internally matched > for tunnels, for robust detection of the IP type. > > Signed-off-by: Eli Britstein <[email protected]> > --- > 1. Please note this is a draft-only proposal. We didn't take care on > all tunnel types, testsuite etc.
Hi, Eli and Reuven. Thanks for the patch. For the future, please, add RFC into the subject prefix for incomplete/RFC work. Also, the patch seem to be mangled by your mail client or the server, you may need to find a different way of sending patches. > 2. About backward compatibility: You mentioned that today OpenFlow > allows setting both tunnel IPv4 and IPv6 fields simultaneously. > While that is true technically, there is no valid use case or > semantic meaning to matching both address types at once. Matching > on IPv4 and IPv6 together simply does not make sense from a protocol > perspective. So, in practice, I would argue that this is not a real > compatibility issue, because the "dual set" case is already invalid. As I said before, it's not invalid on the OpenFlow level. In fact, it may be the only way to tell if the packet is from a tunnel or not for non-keyed tunnels. > 3. About dependencies and pipeline design: I understand the point about > dependencies and the mismatch with OpenFlow's "all fields can be set" > model. But the key here is that the proposed tunnel_eth_type is an > internal field. It is not exposed directly in OpenFlow as a > user-visible match key. Instead, it provides internal consistency > for the datapath and avoids ambiguity in cases where the tunnel IP > version matters. Since it is internal, existing OpenFlow semantics > remain untouched, and no user-facing behavior is broken. It may be fine to add an internal field. As long as other fields do not depend on it, there should indeed not be any compatibility breakages. But we should still not deny addition of OpenFlow rules that match on both types of addresses as that will be incompatible. We can clear the 'always true' matches before sending them to the datapath, based on the eth_type, but only when the eth_type is also matched in the datapath, i.e. we'll need to also add support for matching the tunnel eth_type in the datapath. And we'll need to detect if our datapath supports these matches and only clear the address fields in this case. The datapath support is necessary as everything that is used to make a decision in ofproto layer must be matched in the datapath. This is all revolving around the problem of being able to match on "this packet is not from a tunnel" condition, which will be covered by a 'tun.eth_type == 0' match in the datapath. > 4. If we go forward with this approach, more commits will follow to > handle offloads and cleanups of "dual set", that as mentioned it is > already invalid. Feel free to send RFC v2 with a proper implementation, including support on the datapath level and corresponding conditional use of this new field. If that will look good, then we can proceed with making the kernel changes first and then accepting the userspace parts. The implementation may be a bit challenging, but I don't see fundamental issues of why this can't be done. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
