On Tue, Jan 19, 2016 at 10:15 PM, Simon Horman <simon.hor...@netronome.com> wrote: > Add support for layer 3 GRE vports (non-tap aka non-VTEP). > > This makes use of a separate vport type for GRE, rather than a new mode for > the existing (tap/VTEP) GRE vports as this fits more naturally with the > kernel where implementation of GRE and thus implementation of this feature > there. > > In order to differentiate packets for two different types of GRE vports a > new flow key attribute, OVS_KEY_ATTR_NEXT_BASE_LAYER, is used. It is > intended that this attribute is only used in userspace as there appears to > be no need for it to be used in the kernel datapath. > > It is envisaged that this attribute may be used for other non-UDP > encapsulation protocols that support both layer3 and layer2 inner-packets. > While for UDP encapsulation the UDP port can be used for differentiation > without the need for this new attribute. > > One alternative approach to this new attribute, which I have not > investigated in detail, would be to use a second classifier in tnl-ports.c > for non-UDP layer3 tunnels; leaving the existing classifier for all other > tunnels. > > Signed-off-by: Simon Horman <simon.hor...@netronome.com>
I think it's likely that we'll have a variety of tunnels in the near future that can natively support multiple inner frame formats without changing the encapsulation type. This is somewhat different from what we have now where although different tunnels support various frame formats, there is primarily a 1:1 mapping of encapsulation:inner frame (such as with VXLAN, LISP, and STT). Protocols that fall into this category include GRE (Ethernet/IPv4/IPv6/MPLS), Geneve, and VXLAN-GPE (NSH). It seems like it would be ideal if we can avoid creating a new port type for each of these possible combinations and somehow just make the flow keys look right. After all, in the case of GRE, we already support all of the inner protocols that I mentioned about through the main flow lookup so it would be cool if after decapsulation the appropriate packet came out with the addition of GRE metadata. One other comment - in the case of UDP based protocols I don't think that it is likely that different UDP ports will be used to indicated different inner protocols. This shouldn't be necessary for protocols that have a next protocol field and I don't think the people would be excited about changing the port in that case. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
