[ovs-dev] [PATCH 0/1] RFC: Add support for pre-tunnel to the datapath

[Jesse Gross]

On Sat, Dec 8, 2012 at 5:35 AM, Kyle Mestery (kmestery)
<kmestery at cisco.com> wrote:
> On Dec 7, 2012, at 10:15 PM, Jesse Gross <jesse at nicira.com> wrote:
>> On Fri, Dec 7, 2012 at 1:47 PM, Kyle Mestery <kmestery at cisco.com> wrote:
>>> Some tunneling protocols require manipulation of the packet before the outer
>>> IP header is placed on the packet. An example of a tunneling protocol with
>>> this attribute is LISP. For these protocols, a way to manipulate the packet
>>> (for example, remove the MAC header) is provided.
>>
>> How does this work on the receiving side when you get a packet with
>> the MAC header removed?  I understand that it makes sense in the
>> context of a router but currently OVS expects full Ethernet frames.
>
> Well, one thought I had was we could add the MAC header back in the vport
> driver's receive function. Since the flow is extracted from the packet here,
> the existing flow extraction and matching code would work ok front his point
> on. What do you think?

If I'm not mistaken, we'll have completely thrown away the original
MAC header on transmit, right?  So we'll either have to fill in zeros,
use a set of static addresses, or do some kind of resolution.

I've also wondered whether we can make OVS less Ethernet specific.
Particularly for the basic match-and-forward functionality there isn't
a lot that is protocol dependent.  People have asked about Infiniband
before and potentially this could apply to raw IP as well.  There's a
good chance that as a practical matter it complicates things more than
it is worth though.