Hi Jeff,
As we said, the main difference between FCFS and e-bit in fast
assignment is in going private-first (e-bit), ie. a vendor develops
something privately with some customer, versus going public-first (fcfs).
In IPFIX there is some track record of stuff that followed either the
e-bit path or using very high Information Element IDs "to avoid
squatting" (mainly stuff coming from NetFlow v9 where e-bit was not
available, let's give the benefit of doubt that if e-bit was available
then, the e-bit route would have been followed). These were exactly
cases so that a vendor could initially work on something without going
public. For example Application reporting (now rfc6759) or NAT/CGNAT
session reporting (where now all the relevant pre- and post- NAT IEs are
IANA governed).
Actually, one may even not contradict the other. Where as a technology
gets standardized, it can transition from e-bit to fcfs or standards
action. Why? Because maybe most networks are not single vendor so, once
vendor X prizes itself with invention Y, then a natural next step is to
make sure other vendors implement it too.
This dynamic is what i have seen happening in IPFIX, IMO makes sense and
applies to more structured frameworks than "just a few more stats"; i
perfectly concur with you that vendor Z would never go pick code points
from vendor X PEN space.
So maybe explaining this dynamic and adding an encouragement to
transition from e-bit to fcfs or standards action should be added to the
text of e-bit?
Paolo
On 3/4/25 01:42, Jeffrey Haas wrote:
Paolo,
On Apr 2, 2025, at 1:42 PM, Paolo Lucente <[email protected]> wrote:
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.
My thinking on the longer solution is not crystal clear. Mostly this was
flagging we had a bad interaction that lead to unexpected behavior.
The overall motivation for both the FCFS and the ebit (IMO) is fast assignment.
FCFS as a change made this incredibly easy.
The e-bit proposal has the additional property outside of a FCFS or standards assigned
code point of "private management". Basically, once you have a code point
where the contents are an e-bit, you can do largely what you like without IETF
coordination. What does this give us?
That internal use case is a challenge for any code point you may want to be
multi-vendor. Picking an example, would Cisco be wanting to implement a
counter from the Juniper PEN space?
Generally when we want code points to be multi-vendor, this is where the benefit of even
light-weight IETF process is helpful. We see this for the statistics draft. The code
points were assigned "fast" (although not as fast as the coders originally
wanted), and the semantics of them iterated in a few cases.
If the code points had started in PEN space where change control is outside of
what IETF provides, what's going to be the comfort of various vendors
implementing it? Operators using it?
I think with easy and plentiful FCFS that PEN as a general mechanism is less
needed.
It might be helpful to hear what people think the use cases for PEN code points
will enable different than what we now have. That will give us a sense about
what encoding requirements we may want.
-- Jeff
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
