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

[Jesse Gross]

On Mon, Jun 17, 2013 at 11:19 AM, Lori Jakab <lojakab at cisco.com> wrote:
> 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 encapsulation?

It depends on your definition of aware, I guess. What behavior were
you thinking of?

It may actually be better to make the kernel fairly dumb and just push
headers on as it gets them. That would actually give userspace more
flexibility to reorder and change things than if the kernel tries to
arrange them properly.

>>
>>> 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 present.

That makes sense to me.