[ovs-dev] [PATCH] ofp-actions: Account for OF version when enforcing action consistency

Ben Pfaff blp at nicira.com
Fri Nov 15 00:50:04 UTC 2013


On Fri, Nov 15, 2013 at 09:47:59AM +0900, Simon Horman wrote:
> On Thu, Nov 14, 2013 at 09:46:32AM -0800, Ben Pfaff wrote:
> > On Thu, Nov 14, 2013 at 11:36:56AM +0900, Simon Horman wrote:
> > > What follows is rather long but it tries to explain the crux
> > > of the problem I am trying to solve: the motivation for this patch.
> > > 
> > > * To support verification of combinations of VLAN and MPLS actions
> > >   using OpenFlow1.3 tag ordering.
> > > 
> > >   Currently Open vSwitch always uses the pre-OpenFlow1.3 tag ordering.
> > >   That is an mpls_push action adds an MPLS LSE after any VLAN tags that
> > >   immediately follow the ethernet header (dl type, source and destination
> > >   address).
> > > 
> > >   The OpenFlow1.3+ tag order is different. In this case an mpls_push action
> > >   will place an MPLS LSE immediately after the ethernet header and thus
> > >   before any VLAN tags which previously occupied that position.  Support
> > >   for this new OF1.3 tag order proposed as part "[PATCH v2.48 0/4] MPLS
> > >   actions and matches".
> > > 
> > >   In the case of the pre-OpenFlow1.3 tag ordering an mpls_push action does
> > >   not change whether a packet is a VLAN packet or not. This is because the
> > >   MPLS LSE that is pushed always goes after any VLAN tags.  However, with
> > >   the OpenFlow1.3+ tag ordering after an mpls_push any previously present
> > >   VLAN tags will follow the new MPLS LSE and are thus are no longer
> > >   directly after the ethernet header. I believe that from the point of view
> > >   of verifying actions this means the packet is no longer a VLAN packet.
> > 
> > Thanks.  That makes sense.  I agree.
> > 
> > But isn't this bigger than VLANs?  If you start with a TCP packet, and
> > then you push an MPLS header, it's no longer a TCP packet or even an IP
> > packet, because all of that information has been lost, hidden by the
> > MPLS label.  If we're going to discard the VLAN information, shouldn't
> > we discard everything else that follows the MPLS label?
> 
> Hi Ben,
> 
> I was thinking about this patch last night and I came to the same conclusion.
> I think it is easy enough to fix things up to cover these cases.
> I will see about doing so.

OK.  Thank you!  That has actually been on a mental to-do list of mine
for a while, so I'm glad to see it being addressed.  (I didn't realize
that there was a VLAN special case that stood out.)



More information about the dev mailing list