[ovs-dev] [PATCH v4 1/4] Add support for 802.1ad (QinQ tunneling)

Fri Sep 9 10:18:50 UTC 2016


> -----Original Message-----
> From: Xiao Liang [mailto:shaw.leon at gmail.com]
> Sent: Friday, September 9, 2016 5:27 AM
> To: Mooney, Sean K <sean.k.mooney at intel.com>
> Cc: Ben Pfaff <blp at ovn.org>; dev at 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.mooney at intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Ben
> Pfaff
> >> Sent: Friday, August 19, 2016 9:57 PM
> >> To: Xiao Liang <shaw.leon at gmail.com>; dev at 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 <blp at 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
> <blp at 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.
> 
> Thanks,
> Xiao