On Thu, May 12, 2022 at 8:55 AM Aaron Conole <[email protected]> wrote: > > Ben Pfaff <[email protected]> writes: > > > Hi Aaron! This will move the following fields from the L4 segment to > > the L3 segment: > > > > struct in6_addr nd_target; /* IPv6 neighbor discovery (ND) target. */ > > struct eth_addr arp_sha; /* ARP/ND source hardware address. */ > > struct eth_addr arp_tha; /* ARP/ND target hardware address. */ > > ovs_be16 tcp_flags; /* TCP flags/ICMPv6 ND options type. > > * With L3 to avoid matching L4. */ > > ovs_be16 pad2; /* Pad to 64 bits. */ > > struct ovs_key_nsh nsh; /* Network Service Header keys */ > > > > > > The one that stands out to me is tcp_flags. I remember that we had a > > reason that we wanted to include this in the L3 segment. I think it was > > because we might want to match on flags without matching on anything > > else in L4, but I don't remember the exact details. There is a comment > > to that effect above. > > I guess the reason that would be done would be to implement a stateless > firewall using the openflow rules. I haven't seen many flow pipelines > recently that use tcp_flags, but I can see it might help those kinds of > scenarios where we want to allow/drop packets based on some kinds of > flags (or drop xmas packets before they get processed). > > Do you think it will be a problem? For now, I assume most folks are > using the ct() action and that should be based on ct_state field (which > isn't impacted).
I don't know whether it will be a problem. Everything like this always comes back to "how well do we know how our users use Open vSwitch?" and the answer is always "not very well" :-( Since this is an important correctness issue, I think we should fix it and, if performance problems arise in cases we're not sure about, we can address them. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
