On 6/11/13 1:09 AM, Jesse Gross wrote:
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.
Thanks for pointing this out, will keep it in mind.
I gather that these MAC header actions should then be VLAN tag aware,
and be easily extended in the future to recognize 802.1ah service
encapsulation?
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?
The only case I'm concerned about is in the action validation code,
particularly the validate_set() and validate_tp_port() functions, since
they don't have access to the skb, and need to know the layer 3 protocol
of the flow. In validate_set() we could relax the check for eth.type
for OVS_KEY_ATTR_IPV4 and OVS_KEY_ATTR_IPV6, but I'm not sure what to do
about validate_tp_port().
In general, I think it would be a good idea for the flow key to have a
field specifying the layer 3 protocol, when an ethernet header is not
present.
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.
This would have been my second option, I will move the L3 flag to
OVS_CB(skb) then.
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.
Good to know, thanks!
-Lori
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
