> -----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.
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
