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

[Joe Touch <[e-mail]>]

> On Feb 16, 2017, at 6:17 PM, Tom Herbert <[e-mail]> wrote:
> 
>> On Thu, Feb 16, 2017 at 4:48 PM, Joe Touch <[e-mail]> wrote:
>> 
>> 
>>> On 2/16/2017 4:39 PM, Tom Herbert wrote:
>>> The operational issues we see with TLVs in terms of performance and
>>> DDOS are not aberrations, they are fundamental issues we face in
>>> deployment.
>> Agreed, in the case where TLV sets are not fixed for a given path. The
>> same is also true for bitfields: Ethernet uses a different Ethertypes
>> for IPv4 and IPv6, even though they're intended to be treated as a
>> single protocol class with internal versioning indicated by bitfields.
>> 
>> Unknowns are the cause of the problem - in either case.
>> 
> Joe,
> 
> 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.

> 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.

> 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.

TLVs make the difficulties easier to see, but not more difficult to avoid.

Joe