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

[Lori Jakab]

[Reviving and older thread...]

On Jun 21, 2013, at 2:50 AM, Jesse Gross wrote:

> 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?

I meant that MAC-in-MAC is more than a simple 
destination_MAC|source_MAC|ether_type header, it also has a VLAN tag and 
some extra fields.  So I wonder if the eth_push action should have 
optional attributes that specify the extra fields, and if the eth_pop 
action needs to be able to recognize and handle them.

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

I guess this answers my question above... according to the above 
eth_push should only concern itself with simple Ethernet headers, and 
other action(s) should do the specifics for whichever encapsulation is 
needed.  Still not sure about eth_pop however.  I guess it should be 
made MAC-in-MAC aware only when support for that lands in OVS?

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

You mean that we keep eth.type as the L3 protocol field, or define a new 
one, separate from the eth union?

-Lori