Dear Jeff, Thanks. This is indeed an interesting discussion. Thanks for sharing https://datatracker.ietf.org/meeting/97/materials/slides-97-rtgarea-code-point-management-00.
* not intended to be exclusively proprietary is usually "move fast". I would argue it is both. * > Such things never stay secret. Correct. They are usually documented for network operator like this: https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/concepts_application_discovery/#vendor-specific-fields Another good example on the discussion on FCFS vs PEN. What we see below is a vendor documentation referencing to a individual document at IETF where IPFIX entities in the IANA registry are requested. An adoption call at OPSAWG was requested but not considered due to an overlap with an existing IANA standards IPFIX entity. What becomes obvious is that the implementor has not shared similar to the previous example what PEN and IPFIX entity is being used. IE names such as forwardingExceptionCode are listed which point to IE 137 commonPropertiesId and describes somewhat crude the schema but not semantics. https://community.juniper.net/blogs/julian-lucek/2024/01/02/detection-of-blackholes-in-networks-using-jri https://www.juniper.net/documentation/us/en/software/junos/flow-monitoring/topics/topic-map/resiliency-exception-reporting.html https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions https://mailarchive.ietf.org/arch/msg/opsawg/h7QYKZ0VjBWmiqsQGrWgsqzpg44/ * IPFIX encoding has an additional property that simplifies such an exercise: It has templates. * Without knowing the spec, you can't build a generic parser for these code points in BMP. I expand. Without knowing the schema AND semantics, an operator can't implement properly. IPFIX data-templates can export schema however not semantics. Here is no way around a registry, documentation. There are open-source implementations https://github.com/NetGauze/NetGauze using the IANA registry https://mailarchive.ietf.org/arch/msg/opsawg/cgxHtKqO9Yks7wSFXr5HGDI0yUE/ to obtain these information's for decoding and transformation. As previously voiced, I have a tendency on PEN since it gives the vendor the freedom to implement, prove with an operator that it addresses their use cases and from there come to standards to refine further. With FCFS, https://datatracker.ietf.org/doc/html/rfc8126#section-4.4, there is no expert review. Therefore above would have created a potential overlap with existing entries. Where with PEN this is kept separate. I am all about moving fast. Both choices, FCFS vs. PEN, are addressing this. The question is where do we want to have the documentation and how many of such use cases do we need to cover. Both choices have the drawback of giving the implementor the full control, no governance, on how much he wants to document. However that is in the nature of moving fast I guess. Best wishes Thomas From: Jeffrey Haas <[email protected]> Sent: Wednesday, April 16, 2025 3:53 PM To: Paolo Lucente <[email protected]> Cc: Graf Thomas, INI-NET-VNC-E2E <[email protected]>; [email protected]; [email protected] Subject: Re: [GROW] bmp ebit and rfc 9515 Be aware: This is an external email. Paolo, On Apr 11, 2025, at 2:26 PM, Paolo Lucente <[email protected]<mailto:[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 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
