Hi, Tom,
On 2/9/2017 11:33 AM, Tom Herbert wrote: > On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch <[email protected]> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
