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
> OVS_DP_ATTR_USER_FEATURES an appropriate way to communicate this to the
> kernel?

Why does the kernel need to know?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to