Subject: Re: [nvo3] Review of draft-dt-nvo3-encap-01

From: Tom Herbert <[email-masked]>
Date: Sat, 6 May 2017 10:00:32 -0700

- As I mentioned in a rebuttal to this objection the flag-fields can
be extended with for flags. This has already been implemented, the
objection is not valid.

DT: We are documenting the concerns based on what is already out there
–  a mailing list rebuttal or how it can be sorted out with “this has
already been implemented” doesn’t sound very helpful.

Sorry, I don't understand this statement at all.

A technical objection was raised, a thorough explanation on the
mailing list was given as to why it's not valid, the protocol draft
describes the necessary mechanism, and the mechanism has been
implemented and running. The discussion pertaining to the this (and
many other issues) is in the nvo3 archives and could have been found
with a little diligence. If you are truly attempting to do an
objective analysis and perform an objective selection for one of these
protocols then how can this possibly not be helpful?

Anyway, please remove the objection from the next version your draft,
it is NOT valid!

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 6 May 2017 10:15:43 -0700

- The combinatorics of TLVs and sequential processing requirements are
hard to make efficient in both software and hardware implementations.
Bit-fields do not have this problem

DT:  This is not true according to the HW vendors presented in the  design team.

So the long standing known complexities of sequential TLV parsing,
combinatoric ordering, random access, DOS threats, parser buffer
sizes, dealing with loop free parsing mechanisms like P4 that have
plagued other TLV implementations like IP options IPv6 EH and other
protocols in IETF is now a solved problem? That's awesome!!! But can
you please provide the ***details*** why this is now considered a
solved problem for both software *and* hardware.

Tom