On Fri, Aug 19, 2016 at 04:42:18PM -0400, Eric Garver wrote: > On Fri, Aug 19, 2016 at 01:24:10PM -0700, Ben Pfaff wrote: > > On Fri, Aug 19, 2016 at 04:19:31PM -0400, Eric Garver wrote: > > > On Sat, Aug 06, 2016 at 08:04:44PM -0700, Ben Pfaff wrote: > > > > On Sun, Aug 07, 2016 at 10:54:00AM +0800, Xiao Liang wrote: > > > > > On Thu, Aug 4, 2016 at 6:07 AM, Ben Pfaff <b...@ovn.org> wrote: > > > > > > Thanks for the replies, I have some further responses below. > > > > > > > > > > > > On Sun, Jul 31, 2016 at 08:22:47AM +0800, Xiao Liang wrote: > > > > > >> On Thu, Jul 28, 2016 at 2:40 AM, Ben Pfaff <b...@ovn.org> wrote: > > > > > >> > I'm concerned about backward compatibility. Consider some > > > > > >> > application > > > > > >> > built on Open vSwitch using OpenFlow. Today, it can distinguish > > > > > >> > single-tagged and double-tagged packets (that use outer Ethertype > > > > > >> > 0x8100), as follows: > > > > > >> > > > > > > >> > - A single-tagged packet has vlan_tci != 0 and some non-VLAN > > > > > >> > dl_type. > > > > > >> > > > > > > >> > - A double-tagged packet has vlan_tci != 0 and a VLAN > > > > > >> > dl_type. > > > > > >> > > > > > > >> > With this patch, this won't work, because neither kind of packet > > > > > >> > has a > > > > > >> > VLAN dl_type. Instead, applications need to first match on the > > > > > >> > outer > > > > > >> > VLAN, then pop it off, then match on the inner VLAN. This > > > > > >> > difference > > > > > >> > could lead to security problems in applications. An application > > > > > >> > might, for example, want to pop an outer VLAN and forward the > > > > > >> > packet, > > > > > >> > but only if there is no inner VLAN. If it is implemented > > > > > >> > according to > > > > > >> > the previous rules, then it will not notice the inner VLAN. > > > > > >> > > > > > >> Maybe some applications are implemented this way, but they are > > > > > >> probably wrong. OpenFlow says eth_type is "ethernet type of the > > > > > >> OpenFlow packet payload, after VLAN tags", so it is the payload > > > > > >> ethtype for a double-tagged packet. It's the same for single-tagged > > > > > >> packet: application must explicitly match vlan_tci to decide > > > > > >> whether > > > > > >> it has VLAN tag. > > > > > > > > > > > > OpenFlow does say that, but it's inconsistent with long-standing > > > > > > Open > > > > > > vSwitch practice and will cause backward incompatibility and, worse, > > > > > > security problems. If we need the official OpenFlow behavior then I > > > > > > think we'll need to add a feature switch to turn on that behavior. > > > > > > > > > > It's a good idea to add a switch. I think QinQ can be disabled and > > > > > fallback to current behavior if the switch is off, since these legacy > > > > > applications are not written for QinQ. > > > > > > > > OK. I'm happy with that solution, as long as the implementation is > > > > clean. > > > > > > Is a new flag, i.e. OVS_DP_F_8021AD, passed via > > > OVS_DP_ATTR_USER_FEATURES an appropriate way to communicate this to the > > > kernel? > > > > Why does the kernel need to know? > > When extracting the key from a double tagged frame how does the kernel > know whether the second tag should be classified as second VLAN or an > Ethertype?
The kernel should always classify it as a second VLAN. datapath/README.md explains this in detail, under "Basic rule for evolving flow keys". _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
