On Wed, Jun 5, 2013 at 2:56 PM, Lori Jakab <loja...@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. > 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? > 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. For internal kernel usage, it might be more convenient to represent this as a flag in OVS_CB(skb). When we communicate to userspace, we could indicate that the packet is L3 by simply not including the Ethernet attribute. > 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. An example that comes to mind for this is L3 internal ports. Probably this would be mostly for talking to an L3 tunnel port but it is still a distinct port type, so I think it is good to make L3 ports generic. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
