On Fri, Sep 9, 2016 at 6:18 PM, Mooney, Sean K <sean.k.moo...@intel.com> wrote: > > >> -----Original Message----- >> From: Xiao Liang [mailto:shaw.l...@gmail.com] >> Sent: Friday, September 9, 2016 5:27 AM >> To: Mooney, Sean K <sean.k.moo...@intel.com> >> Cc: Ben Pfaff <b...@ovn.org>; dev@openvswitch.org >> Subject: Re: [ovs-dev] [PATCH v4 1/4] Add support for 802.1ad (QinQ >> tunneling) >> >> 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. > [Mooney, Sean K] correct ovs would not have to be aware of the third vlan in > this case but > It would have to be able to look past it and read the l2 heardse of the > packet for the normal action to work.
I think MAC addresses and top two VLANs should be enough for normal action. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev