Paolo, > On Apr 11, 2025, at 2:26 PM, Paolo Lucente <[email protected]> wrote: > > 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).
It's been some years since I've done flow analytics for a living, but I do understand the motivations here. The effective motivation for such assignments when not intended to be exclusively proprietary is usually "move fast". This permits vendors to implement a bit of telemetry (usually a statistic) and any interested consumers of that data to be able to use it in short order. Such things never stay secret. It's necessary to cover that point because people will want to have code in their products that are able to consume the enterprise specific stuff - especially if it never makes it through any publicly visible specification. By contrast, we tend to push for at least a basic spec during FCFS allocations in IETF even though it's not a requirement. IPFIX encoding has an additional property that simplifies such an exercise: It has templates. When you have an IE for a given PEN, the template will tell you how the fields are to be interpreted. By contrast, we don't have any direct hint in the current BMP infrastructure to know what a given code point means for parsing its data. For example, is it a simple UINT32 or is it afi-safi specific? Without knowing the spec, you can't build a generic parser for these code points in BMP. I'm not necessarily saying "change BMP". However, the inclination we have towards publishing specs for the allocated code points means there's a short path to building the parsers. With stuff "behind the enterprise wall", that's less likely to happen. I'll also note the motivations for stability for the contents of the data remove some of the justification for "move fast" to be "we may change our mind in a non-backward compatible way". Note that most of my opinion has been pretty stable on these points for a while. We're probably due for a rtgarea refresher: https://datatracker.ietf.org/meeting/97/materials/slides-97-rtgarea-code-point-management-00 <https://datatracker.ietf.org/meeting/97/materials/slides-97-rtgarea-code-point-management-00> > > 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. I've seen it go both ways. > > 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. There isn't a strong motivation for a vendor with a popular feature they pioneered to push it out of their PEN space. As an operator, I suspect I know what your answer would be if, for example, my employer said "we decline to implement stats from vendor X's PEN space". :-) Now, if you want to take that as a point of consideration that another vendor SHOULD NOT implement features from another vendor's PEN because of lack of "contract" in how things will be maintained, that's a reasonable thing to put into this internet-draft. In other words, discuss the migration path to public code points as preferred policy. > > 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? The technical considerations are understood. This philosophical discussion is very much about how the working group would like to encourage new work to happen. -- Jeff
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
