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

[Joe Touch <[e-mail]>]

Hi, Tom,


On 2/9/2017 11:33 AM, Tom Herbert wrote:
> On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch <[e-mail]> wrote:
>> ...
>>
>> -  the discussion of TLV vs. bitfields needs a bit more expansion. E.g., TLV
>> necessarily requires serial processing, whereas bitfields can be processed
>> in parallel.
>>
> It looks like the intent is to have a control plane that defines the
> TLVs that will be used, a required ordering, and the assumption that
> all TLVs are all the same size. If that is true then parsing TLVs can
> be turned into a parallel problem, e.g. that can be accomplished with
> 2^N entries in a TCAM the same as bit fields. 

That's true only if the TLVs in use are known in advance - if that's
true, then the set of TLVs effectively becomes a large, static bitfield
in the context of that tunnel.

If that's true, then easy hardware processing is possible only in the
context of each individual tunnel, which requires a reconfigurable
hardware parser for each tunnel.

Otherwise, the only way to know where the Nth TLV field starts is to
parse through the N-1th, which - recursively - reduces to requiring
iterative processing.

> But, now implies that
> explicit tunnels need to be established by the control plane before
> the data plane can be used, and to be practical probably means that a
> node will expect to receive pretty much the same set of TLVs with the
> same order from all communicating devices (or maybe the intent is to
> have a universal ordering of TLVs?).
(agreed - the "known in advance case, as above)

> It would be good to have a reference to other low layer protocols that
> include TLVs or the like, especially IPv4 and IPv6, and an explanation
> as to how TLVs in nvo3 will address all the issues of those protocols
> that have deterred deployment of TLVs.
Agreed, especially if those are the "inner" headers that might need to
be parsed anyway.

Joe