On Tue, Mar 25, 2025 at 05:30:05AM +0000, [email protected] wrote: > > My point is that the FCFS range, in combination with the proposal for ebit, > > REQUIRES the use of ebit. > > I understood now your point. That draft-ietf-grow-bmp-tlv-ebit uses the > experimental range 65531-65534 for the e-bit marker and 32768-65530 for > enterprise code points. 32768-65530 has been classified prior to RFC 9515 > as "Specification Required" and now is "First Come First Served". > draft-ietf-grow-bmp-tlv-ebit basically obsoletes RFC 9515. Correct?
Correct. > I think both documents, RFC 9515 and draft-ietf-grow-bmp-tlv-ebit aim to > lower the bar for implementations however by with two different aims. With > both approaches we have coordinated code points. With IANA administered > "First Come First Served" it is publicly visible where in > draft-ietf-grow-bmp-tlv-ebit it is only visible which company issued the > code point. We are in agreement here. > From a network operator, users, point of view I prefer > draft-ietf-grow-bmp-tlv-ebit since IANA administered "First Come First > Served" lack the documentation of the semantics which is the main benefit > of having a public registry. I don't follow this point. Neither FCFS nor Enterprise provide specific incentive for documenting the code points. Actual FCFS interaction practice does lead to opportunity for the chairs that steward the code point space to request documentation, but it's not a blocking action. In the case of PEN managed space, there is zero incentive for such code point documentation. Somewhat more problematic is there's no established practice for documenting in a IETF/IANA public fashion the meaning of internally allocated code points. Further, PEN managed code points lack IETF process motivation for stability. These issues are not insurmountable. It's a small amount of Internet-Draft work to establish IANA registries for enterprise-managed parties if that's what we choose. Similarly, drafts could be issued that document the use of these PEN based code points. However: > With > https://mailarchive.ietf.org/arch/msg/grow/rSkjGSefcC1crt0UkG8ExTrUVM4/ we > have a good example. This is a implementation specific counter. BGP > protocol specific counters in my opinion are always "Standards Action". The discussion point I tend to have about standardizing telemetry values is that it is almost always to the benefit of the operators that if a value has clear vendor-neutral semantics, it should be documented in a vendor-neutral fashion. For the example about the licensed prefix limits, the feature is somewhat common but not universally given the same semantics. If some agreement was given on the semantics, standardizing the code point for this purpose is possible. And if there isn't consistent agreement, FCFS remains a simple option. Such may be what a "coalition of the willing" choose in order to document such a code point if there is resistance from grow about the standards range. This is often perceived as preferable to picking the first vendor's PEN that tried to implement the value since people start asking "why is my prefix limit for vendor FOO under vendor BAR's management?" For truly proprietary values, enterprise management is useful. But the example above often motivates discussion about "doing it publicly" rather than starting privately. > I fully agree with you assessment that we need feedback from the mailing > list to understand different few points. What is your preference? For the moment, the goal was to flag this issue and ensure it's documented in the current ebit draft. If the ebit functionality is not widely deployed in BMP software, there is perhaps a somewhat amusing solution: shift the bit by one. One may consider the current most significant bit to be the "FCFS bit" after the updates to RFC 9515. The next less significant bit could be the e-bit. This would then partition both the standards action and the FCFS spaces into an e-bit/no e-bit space in exactly the same manner as the current draft. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
