[ovs-dev] [RFC] Making OVS less Ethernet specific

Lori Jakab lojakab at cisco.com
Mon Jun 17 18:19:36 UTC 2013

On 6/11/13 1:09 AM, Jesse Gross wrote:
> On Wed, Jun 5, 2013 at 2:56 PM, Lori Jakab <lojakab at cisco.com> wrote:
>> At a high level, we would introduce layer 3 (tunnel) vports, and LISP
>> would be such a vport.  Whenever a packet that ingressed on a L2 vport
>> needs to egress on a L3 vport, we apply the internal pop_eth action
>> automatically.  For packets going from L3 vports to L2 vports, a
>> push_eth action would add a MAC header, with addresses determined by ARP
>> resolution in user space.
> One other thing that you might want to keep in the back of your mind
> as you implement this is how it might interact with MAC-in-MAC
> encapsulation. OVS doesn't currently support this but if it did (and
> there have been requests), it would presumably want to use these
> actions as well.

Thanks for pointing this out, will keep it in mind.

I gather that these MAC header actions should then be VLAN tag aware, 
and be easily extended in the future to recognize 802.1ah service 

>> One such decision is how to handle the flow key.  I set all fields in
>> key->eth to 0, except the type, because we still need to know what kind
>> of L3 packet do we have.  Since a lot of code is accessing
>> key->eth.type, this is easier than having this information in a
>> different place, although it would be more elegant to set this field to
>> 0 as well.
> Can we use skb->protocol for the cases where we currently access the
> EtherType? Are there cases that you are particularly concerned about?

The only case I'm concerned about is in the action validation code, 
particularly the validate_set() and validate_tp_port() functions, since 
they don't have access to the skb, and need to know the layer 3 protocol 
of the flow.  In validate_set() we could relax the check for eth.type 
for OVS_KEY_ATTR_IPV4 and OVS_KEY_ATTR_IPV6, but I'm not sure what to do 
about validate_tp_port().

In general, I think it would be a good idea for the flow key to have a 
field specifying the layer 3 protocol, when an ethernet header is not 

>>   Now, in order to differentiate flows with mac addresses set
>> to 0 and flows without an Ethernet header, I added a boolean field to
>> tun_key, to mark L3 flows.
> For internal kernel usage, it might be more convenient to represent
> this as a flag in OVS_CB(skb). When we communicate to userspace, we
> could indicate that the packet is L3 by simply not including the
> Ethernet attribute.

This would have been my second option, I will move the L3 flag to 
OVS_CB(skb) then.

>> However, if we expect to have non-tunneled
>> L3 ports (I couldn't find a good reason for this) then we should move it
>> out into the main flow key structure.
> An example that comes to mind for this is L3 internal ports. Probably
> this would be mostly for talking to an L3 tunnel port but it is still
> a distinct port type, so I think it is good to make L3 ports generic.

Good to know, thanks!


More information about the dev mailing list