On Wed, Aug 14, 2013 at 7:01 AM, Lori Jakab <loja...@cisco.com> wrote: > [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?
OK, I see what you meant by "aware" now. In general, I would try to unbundle the actions as much as possible. In the case of the outer vlan tag, there shouldn't be a problem using basically the existing push/pop actions plus a set of simple Ethernet actions (this is also what OpenFlow does). For the I-SID, I guess it depends on how you were thinking about defining the MAC push/pop actions. For example, if pop were to pull off everything up to the L3 header (which I believe is what you had in the original patch) then all of these issues just go away. However, it then seems like there are difficulties with popping stacks of MAC headers. >> >>>> >>>>> 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? I think it's fine to keep using eth.type as the protocol field. I think we can probably some holes to move the is_layer3 flag into the non-tunnel portion of the flow though. X-CudaMail-Whitelist-To: dev@openvswitch.org _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
