Hi Med,
Inline: On 10/2/25 07:36, mohamed.boucad...@orange.com wrote:
Hi Paolo, [ .. ] [Med] Great, looking forward to see the merged version.
Sure, i'll do as a last step after any conversation that may stall the TLV draft is cleared out.
[Med] Some text is needed to better explain the rationale. For the design itself, assigning a bit (and actually a full range) is not the only option. Please refer to the design adopted by other protocols and see how they manage to address this with one single VENDOR_CLASS codepoint.
As noted in the document too, we did inspire ourselves to the design of other protocols -- namely IPFIX. I know there are multiple options, including re-inventing the wheel, we went for one of existing ones which has proven to be solid and does the work.
The other side effect of your current design is that you artificially created a dependency on the E-bit spec for all the other TLV documents! This wouldn't be the case with a VENDOR_CLASS type/TLV is used.
Documents defining a standard with IANA allocations are oblivious to the use of e-bit. When creating a new registry the topmost bit should be reserved, equivalent to the current less flexible Experimental range arrangement.
The current proposal achieves the goal to seamlessly allow for two scenarios: 1) exporters to pass TLVs that are non-standardized at all; 2) exporters to pass TLVs that have been standardized but, for example, are extended by some proprietary nuance (ie. private path marking code points).
The two scenarios can happen concurrently and standard and proprietary TLVs can be interleaved as needed to either facilitate encoding for the exporter or decoding for the monitoring station without having to dedicate a section exclusively for proprietary data -- which is a plus in a highly verbose context like BGP synchronization.
Paolo _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
