[ovs-dev] [RFC] Making OVS less Ethernet specific
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
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
>> 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