IETF Logo Mail Archive

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

hemant@mnkcg.com Thu, 18 May 2023 17:05 UTC

Return-Path: <hemant@mnkcg.com>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AD6C14CEE3 for <coin@ietfa.amsl.com>; Thu, 18 May 2023 10:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnkcg.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS18Zj2BwBXn for <coin@ietfa.amsl.com>; Thu, 18 May 2023 10:05:50 -0700 (PDT)
Received: from web50.dnchosting.com (web50.dnchosting.com [192.64.150.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61991C151549 for <coin@irtf.org>; Thu, 18 May 2023 10:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mnkcg.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CUZmfGFB+IigXh6YMZammZMo/iDKrSYqXXrAwgNeXWw=; b=NFdO1XNoszkpobTZy2XdnvjkCc 7PG0efhHWF4MOtzXoqKBpjApTPdZ09fjd4183jUwBni9i+wr4pekmuzddsXY+9ZLI6rMEihtGyNbQ Iq04a7enB9dvFGumQa4lbv5xwFZWjShzoCJ4WMzoGyVt9LWyMwqZbV+K2gqx4kWuZfdRuOxZua5zU h3477fMoyCYBx5uQCQMMYIP+vN3nug2n1WHWF3FmwtXg3cuzs3rJwPNWWTQzQCpw8YGXjjPAKL4iz aBk/7oLx3+XFRZLK/4GQFyWDd6ZEQH0LvocdWxRu7/5uLLrYzQI3r549w7Nfm/S3dbjLRISPBDVO/ /gpSB19g==;
Received: from [76.191.34.66] (port=41193 helo=hemantPC) by web50.dnchosting.com with esmtpa (Exim 4.96) (envelope-from <hemant@mnkcg.com>) id 1pzh4S-0000kZ-2j; Thu, 18 May 2023 13:05:45 -0400
From: hemant@mnkcg.com
To: 'Haoyu Song' <haoyu.song@futurewei.com>, ehalep@mojatatu.com, 'Toerless Eckert' <tte@cs.fau.de>
Cc: "'Bernier, Daniel'" <daniel.bernier@bell.ca>, 'Hesham ElBakoury' <helbakoury@gmail.com>, 'Marie-Jose Montpetit' <marie@mjmontpetit.com>, 'coin' <coin@irtf.org>, coinrg-chairs@ietf.org
References: <CAPjWiCT2ipu=yiZFr8hBGF2wy-Y_Dmze=8j+PgeDFyN7KNZR6w@mail.gmail.com> <ZGJl+6YPQarlDSTr@faui48e.informatik.uni-erlangen.de> <034201d98757$bbd87550$33895ff0$@mnkcg.com> <c98c172c-a483-5f69-9bff-dedd4b6a78bb@gmail.com> <044101d9876a$9f0490e0$dd0db2a0$@mnkcg.com> <c9b9a119-27ba-88db-2f08-18e8ff2c6337@gmail.com> <ZGQbyzRW5d1vkgVV@faui48e.informatik.uni-erlangen.de> <9EABD595-552E-4775-B69C-72BE49BD5C93@bell.ca> <00c501d988ea$bbd16f50$33744df0$@mnkcg.com> <095d01d98914$0bba99f0$232fcdd0$@mojatatu.com> <ZGWFQRGI0hmc3g5O@faui48e.informatik.uni-erlangen.de> <001101d989a0$4e180530$ea480f90$@mojatatu.com> <BY3PR13MB47877D31EC3B4511C8095D329A7F9@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB47877D31EC3B4511C8095D329A7F9@BY3PR13MB4787.namprd13.prod.outlook.com>
Date: Thu, 18 May 2023 13:05:44 -0400
Message-ID: <02b401d989aa$fc70d940$f5528bc0$@mnkcg.com>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIxBKBzfrzN0AW7R0uxmgt8NzLx7gE7vxklAjW3P5gCJVowzwG6owZPAbklKiwBjPTNRAHuP0tRAq/Fk7oBMBPHnALP0N6QAji6kzgB08G1vK33PAtA
Content-Language: en-us
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_02B0_01D98989.74C9FE20"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web50.dnchosting.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mnkcg.com
X-Get-Message-Sender-Via: web50.dnchosting.com: authenticated_id: hemant@mnkcg.com
X-Authenticated-Sender: web50.dnchosting.com: hemant@mnkcg.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/jJ8XhLI3m7If-mxu5oBMxD5DDkA>
Subject: Re: [Coin] Fwd: The Future of P4, Revisited
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 May 2023 17:05:54 -0000

Four five years back P4 presented a paper from Stanford on events-based 
processing which of course maintains state. Just search for event-based 
processing P4.

Hemant

-----Original Message-----
From: Haoyu Song <haoyu.song@futurewei.com>
Sent: Thursday, May 18, 2023 12:19 PM
To: ehalep@mojatatu.com; 'Toerless Eckert' <tte@cs.fau.de>
Cc: hemant=40mnkcg.com@dmarc.ietf.org <hemant@mnkcg.com>; 'Bernier, Daniel' 
<daniel.bernier@bell.ca>; 'Hesham ElBakoury' <helbakoury@gmail.com>; 
'Marie-Jose Montpetit' <marie@mjmontpetit.com>; 'coin' <coin@irtf.org>; 
coinrg-chairs@ietf.org
Subject: RE: [Coin] Fwd: The Future of P4, Revisited

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.

v2.23.0 | Report a Bug | By Email