[Reviving and older thread...]
On Jun 21, 2013, at 2:50 AM, Jesse Gross wrote:
On Mon, Jun 17, 2013 at 11:19 AM, Lori Jakab <loja...@cisco.com> wrote:
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?
It depends on your definition of aware, I guess. What behavior were
you thinking of?
I meant that MAC-in-MAC is more than a simple
destination_MAC|source_MAC|ether_type header, it also has a VLAN tag and
some extra fields. So I wonder if the eth_push action should have
optional attributes that specify the extra fields, and if the eth_pop
action needs to be able to recognize and handle them.
It may actually be better to make the kernel fairly dumb and just push
headers on as it gets them. That would actually give userspace more
flexibility to reorder and change things than if the kernel tries to
arrange them properly.
I guess this answers my question above... according to the above
eth_push should only concern itself with simple Ethernet headers, and
other action(s) should do the specifics for whichever encapsulation is
needed. Still not sure about eth_pop however. I guess it should be
made MAC-in-MAC aware only when support for that lands in OVS?
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.
That makes sense to me.
You mean that we keep eth.type as the L3 protocol field, or define a new
one, separate from the eth union?
-Lori
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
