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

[Tom Herbert <[e-mail]>]

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. With TLVs these are variables that need to be considered with
each packet. This is why bit-fields naturally yield the simpler and
more feasible implementation. The trade-off for this simplicity is
loss of flexibility as pointed out by the draft. Defining 100s of
bit-fields in GUE probably wouldn't work. My response to that argument
is to ask why would we ever want to define 100s of extensions in a
protocol? Again, looking at other protocols that have extensibility we
see relatively few extensions being defined. IP has around 20 options,
TCP around 50. Grant it some of these options allow different lengths,
but for the most part defining new extensions seems to be a rare
occurrence. For GUE we estimated that after an initial set of
extensions have been defined (about ten), we'll maybe add one per
year. Extrapolating from this, we believe the protocol can accommodate
all the necessary extensibility for at least a thirty years.

Tom