Re: [nvo3] Draft Geneve

[Anton Ivanov <[e-mail]>]

On 01/03/14 22:28, Tom Herbert wrote:
> On Sat, Mar 1, 2014 at 1:00 PM, Anton Ivanov (antivano)
> <[e-mail]> wrote:
>> Hi Tom,
>>
>> Based on your comments you have not followed the discussion. I think it will
>> be good if you go through the thread in the archive.
>>
> This discussion is about geneve which is what I was commenting on.

This discussion is about the fact that geneve is a reinvention of what
we have already. It is not "about geneve". It is about geneve as an
encapsulation not having sufficient technical merit to warrant its
perpetration.

>
>> First, we started the discussion by announcing the fact that we have open
>> sourced a working static tunnel L2TPv3 implementation as an overlay at vNIC
>> level (allowing for off-host switching, direct overlay to physical and
>> direct vm to vm overlay). Based on this discussion I will add back (I
>> actually removed it as I saw it as unnecessary) the "application-specific
>> data between header and payload" feature.
>>
>> Second, I have been very specific about using _STATIC_ tunnels. What you are
>> saying in your mail is mostly invalid in a static tunnel context.
>>
>> Static tunnels are just PWEs  - same as any other encaps.
>>
>> 1. There is no control plane. RFC 4719 does not apply.
>>
>> 2. For an example - see
>> http://tools.ietf.org/html/draft-mkonstan-l2tpext-keyed-ipv6-tunnel-00 .
>> This is one example use case, the limitations specified in it are not
>> necessary in most others.
>>
>> 3. L2TPv3 static tunnels do not specify what the payload is and have no
>> in-band information on this. You can have PPP, Ethernet, IP, ZigBee, RFC1149
>> or whatever else you may like. If you want a special packet type in the
>> static tunnel case it is up to you. L2TPv3 will carry it for you.
>>
> If you don't carry a protocol type in each packet doesn't this prevent
> network devices that don't have access to tunnel state from parsing
> the inner packet. How would you implement LRO in a NIC, deep packet
> inspection, or network flow monitoring in that case?

Depends on device capabilities.

For big boxes - just go and ask anyone who has built a BNG and its NPUs
- all of them have been implementing it and supporting it for nearly a
decade now. There will be plenty of people from that area at the IETF.
As I said - for a lot of us it is a case of been there, done that. There
is no need to invent a new encaps the world does not need.

As far as offloads on a generic compute system and low(ish) end NICs

    TX: Let's for sake of argument, assume that we have a NIC that can
do generic TSO that is so generic that it can do VXLAN, GRE or geneve.
This means that you can program the NIC to do a reasonably arbitrary
header and put the segment at the end of it. So no difference there.

    RX: This one is more interesting. For RX I can see the benefit of
having a header length field or a well defined header length, especially
in the case of a well defined protocol. However, from an implementation
standpoint I do not see a difference between that and programming the
NIC with a trivial "for this rxhash, 5-tupple, whatever - offload from
offset X" and communicating that offset via control plane.  That has the
limitation of keeping the offset constant per session. It is however
easier to implement compared to parsing variable length options - both
in software and hardware (by the way, so far nobody has specified a use
case which explicitly requires the length of options to vary within a
session).

In any case, for both RX/TX - if we want to go down the "options may
vary within session" route instead of "variable, but fixed per session",
I do not see why we should not specify the app extension header (the one
which presently needs to be set via offset) to have a format which
includes a header length field. This also decouples sufficiently the
encaps from the metadata as preferred by most people who have spoken so
far. It is should be a separate header, not something welded to the encaps.

By the way, in its current form the checksum section,
drive-by-shooting-by-UDP, etc in the geneve spec look like they have
been built with the assumption of all or nothing (full offload by some
single offload spec offered by vendor X or no offload). That is not the
way you build things - you have to have have the cases in-between
handled in a reasonable manner. For example the spec should be friendly
to partial checksum re-use (you take the hardware checksum on RX and
compute the inner payload checksum as a difference from that over outer
header), etc. Also, the drive-by-shooting by UDP is extremely unfriendly
with respect to how you implement things on a Type 2 (kvm and Co).

A.

>
>
[snip]

-- 
"If you think it's expensive to hire a professional to do the job,
    wait until you hire an amateur."
				    Paul Neal "Red" Adair 

A. R. Ivanov
E-mail:  [e-mail]