>> 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. > > I gave an example above where that's not the case. A value in a single bit > field can redefine other fields - and that can't be avoided as a possibility > unless all values of all fields are known in advance and don't do so. > We expressly disallow that in GUE. New extensions are always additive information. From section 3.3.1:
"Flags (or paired flags) are idempotent such that new flags must not cause reinterpretation of old flags. Also, new flags should not alter interpretation of other elements in the GUE header nor how the message is parsed (for instance, in a data message the proto/ctype field always holds an IP protocol number as an invariant)." >> With TLVs these are variables that need to be considered with >> each packet. > > Incorrect - the same is true for TLV. If you specify the order, then they're > ordered. If you specify which are required, then they're required. They're > just different size bit fields. But again, we don't have any examples of a protocol with ordered TLVs that does this and there is no concrete proposal for doing this in Geneve so this idea is just speculation. There are already well-deployed protocols with bit-fields such that options order is invariant (e.g. GRE) and that is characteristic is used to implement efficient parsing. > >> This is why bit-fields naturally yield the simpler and >> more feasible implementation. > > This is the conclusion that cannot be reached. If you want to pick bitfields > arbitrarily, fine. If you have another reason, present it. But the same rules > apply to bitfields and TLVs - known patterns are equally easy, and unknowns > are equally hard. > I've made pretty much presented all the rationale. Processing a list of TLVs is demonstrably less efficient than an equivalent set of bit-fields. In HW we can use TCAM to parse bit fields, in software we can do it without loops. I've also given the argument for random access of extensions when processing order is relevant. You can readily see these characteristics in open source SW implementations. Last time I checked with HW experts about this they claimed TLVs were problematic, that was a couple of years ago I suppose someone might have solved the combinatorics of parsing since then but haven't heard that from anyone yet. Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
