On Sat, Aug 20, 2016 at 9:41 AM, Mooney, Sean K <sean.k.moo...@intel.com> 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. >> > > > 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". > [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.
I believe OVS doesn't have to be aware of the third VLAN in this case. It can be treated as payload. Thanks, Xiao _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
