[ovs-dev] [PATCH v9 7/7] userspace: add non-tap (l3) support to GRE vports

[Jesse Gross]

On Mon, Feb 1, 2016 at 8:05 AM, Simon Horman <simon.horman at 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.horman at 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.horman at 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.