Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team

[Tom Herbert <[e-mail]>]

>> I agree with that, however there are fewer unknowns to deal with when
>> using bit-fields as opposed to TLVs. Once the sender and receiver
>> agree on options to be used, with bit-fields the order and length are
>> fixed.
>
> I gave an example above where that's not the case. A value in a single bit field can redefine other fields - and that can't be avoided as a possibility unless all values of all fields are known in advance and don't do so.
>
We expressly disallow that in GUE. New extensions are always additive
information. From section 3.3.1:

"Flags (or paired flags) are idempotent such that new flags must not
cause reinterpretation of old flags. Also, new flags should not alter
interpretation of other elements in the GUE header nor how the message
is parsed (for instance, in a data message the proto/ctype field
always holds an IP protocol number as an invariant)."

>> With TLVs these are variables that need to be considered with
>> each packet.
>
> Incorrect - the same is true for TLV. If you specify the order, then they're ordered. If you specify which are required, then they're required. They're just different size bit fields.

But again, we don't have any examples of a protocol with ordered TLVs
that does this and there is no concrete proposal for doing this in
Geneve so this idea is just speculation. There are already
well-deployed protocols with bit-fields such that options order is
invariant (e.g. GRE) and that is characteristic is used to implement
efficient parsing.

>
>> This is why bit-fields naturally yield the simpler and
>> more feasible implementation.
>
> This is the conclusion that cannot be reached. If you want to pick bitfields arbitrarily, fine. If you have another reason, present it. But the same rules apply to bitfields and TLVs - known patterns are equally easy, and unknowns are equally hard.
>
I've made pretty much presented all the rationale. Processing a list
of TLVs is demonstrably less efficient than an equivalent set of
bit-fields. In HW we can use TCAM to parse bit fields, in software we
can do it without loops. I've also given the argument for random
access of extensions when processing order is relevant. You can
readily see these characteristics in open source SW implementations.
Last time I checked with HW experts about this they claimed TLVs were
problematic, that was a couple of years ago I suppose someone might
have solved the combinatorics of parsing since then but haven't heard
that from anyone yet.

Tom