[ovs-dev] [RFC] Making OVS less Ethernet specific
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
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...
Size: 8298 bytes
Desc: not available
More information about the dev