On Sat, Dec 8, 2012 at 5:35 AM, Kyle Mestery (kmestery) <kmest...@cisco.com> wrote: > On Dec 7, 2012, at 10:15 PM, Jesse Gross <je...@nicira.com> wrote: >> On Fri, Dec 7, 2012 at 1:47 PM, Kyle Mestery <kmest...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
