On Mon, Feb 1, 2016 at 8:05 AM, Simon Horman <simon.hor...@netronome.com> wrote: > On Tue, Jan 26, 2016 at 10:09:28PM -0800, Jesse Gross wrote: >> 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. > > I think that sounds reasonable. But I am wondering if you have any thoughts > on how this might be implemented. > > The once approach that I have considered so far would be to rework of > kernel's GRE code to allow it to provide a netdev that can handle both tap > and non-tap (l2 and l3 payloads). I can investigate this more closely if > you think it is an approach worth pursuing.
I think this sounds like a good idea if we can find a way to do it cleanly. From OVS's perspective, the main thing that we need is a way to indicate the first header that we expect to see. We used to have this in struct tnl_ptk_info proto but that is no longer exposed to OVS. We also want to make sure that a device that is configured in this mode behaves in a logical way when not connected to OVS - i.e. it knows whether to emit ARP for L2 ports but not L3. I suppose now that lightweight tunneling is here both interfaces are common and therefore the problem is the same in each case, which is a good thing. Jiri (cc'ed) is working on GPE and NSH support to VXLAN at the moment. I think this is very closely related and complementary as it also depends on sending non-Ethernet frames to OVS. He might have some ideas on how to handle this. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
