Re: [Coin] Fwd: The Future of P4, Revisited

[Hesham ElBakoury <[e-mail]>]

Hi Haoyu,
You say: "P4 has very limited support for stateful processing"

I am not sure I can agree with your characterization of P4. Perhaps can you
elaborate on this.

Thanks
Hesham

On Thu, May 18, 2023, 9:19 AM Haoyu Song <[e-mail]> wrote:

> Interesting discussion. See my comments below  [HS]
>
> Haoyu
>
> > For example, in the multicast drafts i write, we use C-pseudocode
> > to specify behavior, but we do attempt to implemnt on Tofino in P4.
> Should we really
> > use P4 code for the RFC specs... ? (much longer than C Pseudocode). Aka:
> quite selfish
> > (but IETF relevant ;-) reason to highlight this point.
>
> [EH]: This is an area I'm very interested in. Having a standardized and
> formal language to describe protocols and behavior can bring a lot of
> functionality and benefits to the IETF.
> My initial thinking is that having such a blueprint, the IETF could
> generate tools to create a reference implementation that can be used for
> interoperability purposes therefore decreasing time to test and implement
> protocols and therefore RFC publications.
>
> [HS] P4 can only describe dataplane behaviors, so any control plane stuff
> is out of scope. For dataplane, if it's used to describe header format,
> it's not better than the "struct" in C. The language uses the match-action
> table abstraction with an implication of pipeline implementation which may
> make it cumbersome or even impossible to describe the  behavior (e.g.,  P4
> has very limited support for stateful processing). In general, I don't
> think P4 at its current form can undertake the role for formal protocol
> specification.
>