Hi Jeff,
Thanks for catching this & your proposal for the top-most bit being the
FCFS one is super sensible - i'll edit the document accordingly.
One remaining question: does in your opinion FCFS make sense in
conjunction with e-bit? Or would e-bit only make sense with Standards
Action? I am myself tending for the latter given the interesting
conversation you and Thomas were having: both e-bit and FCFS are
mechanisms to lower the bar, one going private-first, the other going
public-first -- probably the intersection of the two is ornamental and
we could skip it.
Paolo
On 25/3/25 14:30, Jeffrey Haas wrote:
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]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
