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