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

Lori Jakab lojakab at cisco.com
Wed Jun 5 21:56:35 UTC 2013


The LISP tunneling support as of now is not yet ready for upstreaming,
for reasons outlined in this message:


One solution to the above issues is to make OVS less Ethernet specific,
meaning that it should accept and work with packets/flows without an
Ethernet header.

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.

I attached a patch to this email with proposed changes to the datapath
to make this happen.  I didn't use git-send-email since it is still
early work, and I don't expect anyone to apply it, just wanted to get
some early feedback on some of the design decisions.

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

Let me know what you think.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: l3_ovs_dataplane.patch
Type: text/x-patch
Size: 8298 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20130606/a671a6af/attachment-0005.bin>

More information about the dev mailing list