The UAL and UEC seem like very interesting initiatives for the networking world. Although the official specifications are not available yet, there are plenty of presentations on YT, for example, https://www.youtube.com/watch?v=_oQjOLj2-W4. It seems to me that P4 could be a interesting tool for implementing certain “elements”/“componets” of UAL and/or UEC. I’m curious to know, what’s the community’s opinion on this?
I do not know how much companies selling programmable network devices have published about UEC, but in general, any time there are a large number of ideas being proposed, prototyped, and/or used in production in a short time frame (i.e. faster than it takes to get a new ASIC design to market), having “enough” programmability in a network device is a great way to implement new ideas faster in existing network devices.
Note that just because a device is P4-programmable does not automatically mean that it can implement any new idea someone proposes. For example, if some new proposal was most easily implemented by tracking the total packet buffer occupancy in an Ethernet switch, independently for each of several traffic classes, and then use some function of those occupancies on every packet to affect how they were processed or forwarded, that would be most easily accomplished if the programmable ASIC already exposed such measurements to the P4-programmable parts of the device, e.g by metadata values from the traffic manager to egress processing, or by providing extern functions that let the P4 code read those values for every packet.
In that example, it might be possible to use P4 registers and a few dozen lines of P4 code to add the necessary tracking of per-TC packet buffer occupancy, but especially in programmable Ethernet switches with multiple independent “pipes” (Tofino terminology – this is called “slice” by some other vendors), it can be very challenging to find ways to implement such things using existing P4 constructs.
I asked this because UAL and UEC appear to be initiatives aimed at introducing innovations in networking across multiple layers, including L2 and L3.
Moreover, some vendors in the P4 community are involved in one of these two consortium:
Given that, it seems possible that extensions to the P4 language could be required to support UAL and UEC, especially as these initiatives may introduce new use cases and requirements for programmable networking. However, we’re still waiting for the official UEC specifications, while UAL was released a few days ago.
In other words, I’m wondering whether these initiatives might influence the evolution of the P4 language, since they may reflect emerging needs from P4 users and “stakeholders”.
Agreed that it might lead to desired changes in the P4 language. However, I suspect that far more often a good approach to implementing new features in a system using P4 is to define the right kinds of standard/intrinsic metadata, and the right set of extern functions, that enable implementing a feature in the data plane. If you look at the difference between the published TNA architecture vs. v1model, the differences are not in the P4 language, but in those things:
Yesterday, I saw the UAL presentation, and indeed you are right, Andy. They said that they are going to define a UAL model that specifies how a device that supports UAL should look like. This might open up the creation of a new P4 model.