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

[Tom Herbert <[e-mail]>]

On Thu, Feb 9, 2017 at 11:42 AM, Joe Touch <[e-mail]> wrote:
> 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.
>
Yep, in that case even the meanings of the bit fields would haven't to
fixed the whole data packet format could just be negotiated by the
control plane. The only issue with that is if intermediate boxes are
expected to parse the optional data then they need to be privy to what
was negotiated, but that would also be true if we expected middleboxes
to be able to efficiently parse TLVs and they need to see the control
plane negotiation to set up the processing path.

> 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.
>
Yes, and iterative processing of an open ended list of TLVs is still
hard to do in hardware _and_ software and in fact is an obvious DOS
vector. Last I checked OpenFlow, P4, and eBPF don't fully implement
loops that are needed to process an arbitrary list of TLVs (they
resolved this through some hackery and artificial constraints). The
unlimited flexibility of TLVs does not come without a cost...

Tom

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