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