On Sat, Aug 20, 2016 at 01:41:26AM +0000, Mooney, Sean K wrote: > > > > -----Original Message----- > > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff > > Sent: Friday, August 19, 2016 9:57 PM > > To: Xiao Liang <shaw.l...@gmail.com>; dev@openvswitch.org > > Subject: Re: [ovs-dev] [PATCH v4 1/4] Add support for 802.1ad (QinQ > > tunneling) > > > > 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 > [Mooney, Sean K] am I correct in assuming that this new flag will be set in > the ovsdb > Either on the bridge or prereably globally in the other_config section fo the > Open_vSwitch table. > Both will allow easy detection of the feature form openstack so we can detect > if qinq can be used. > The openstack ovs neutron agent currently uses vlans for tenant isolatation > so this would enable > Vlan transparency when qinq is available.
No flag is needed. It was a miss understanding on my part. > > > > > 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". Thanks Ben. I understand now. > [Mooney, Sean K] out of interest would it be possible to support 3 laryers of > vlans and still be able to match on the inner packet headers. > As I said about neutron currently uses on level of vlans for tenant isolation > Having qinq would allow the tenant to send one level of vlan and neutron to > use one > Layer of vlans for isolation. Support 3 layares fo vlans in ovs would allow > the guest to use qinq > Neutron to use vlans for isolation at the same time. Not with this series. It only supports two VLAN tags. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
