> From: Morten Brørup [mailto:m...@smartsharesystems.com] > Sent: Wednesday, 2 August 2023 12.25 > > > From: Qi Zhang [mailto:qi.z.zh...@intel.com] > > Sent: Wednesday, 2 August 2023 19.35 > > > > From: Cristian Dumitrescu <cristian.dumitre...@intel.com> > > > > For network devices that are programmable through languages such as > > the P4 language, there are no pre-defined flow items and actions. > > > > The format of the protocol header and metadata fields that are used to > > specify the flow items that make up the flow pattern, as well as the > > flow actions, are all defined by the program, with an infinity of > > possible combinations, as opposed to being selected from a finite > > pre-defined list. > > > > It is virtually impossible to pre-define all the flow items and the > > flow actions that programs might ever use, as these are only limited > > by the set of HW resources and the program developer's imagination. > > > > To support the programmable network devices, we are introducing: > > > > * A generic flow item: The flow item is expressed as an array of bytes > > of a given length, whose meaning is defined by the program loaded by > > the network device. > > The flow item is not "generic", it is "opaque": Only the application knows > what this flow item does. > > I hate the concept for two reasons: > 1. The inability for applications to detect which flow items the underlying > hardware supports. > 2. The risk that vendors will use this instead of introducing new flow item > types, available for anyone to implement.
After further consideration, there might be a middle ground. Consider Vendor-Specific attributes for DHCP and RADIUS, or SNMP MIBs... Any vendor is free to add his own, proprietary special-purpose attributes, without going through the standardization process. (This is the key challenge this patch seems to be aiming at.) The vendor might publish these attributes, and other vendors may implement them too. And in order to prevent collisions, the Vendor-Specific attributes contain a globally unique vendor ID, such as the Private Enterprise Number [1] managed by IANA. If similar principles can be worked into the patch, I can support it. Preferably, there should also be a means for applications to query if specific Vendor-Specific flow items and actions are supported or not. [1]: https://www.iana.org/assignments/enterprise-numbers/
