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

hemant@mnkcg.com Thu, 18 May 2023 17:10 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 BE69FC15108A for <coin@ietfa.amsl.com>; Thu, 18 May 2023 10:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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=ham 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 3n7F1vRbSJr6 for <coin@ietfa.amsl.com>; Thu, 18 May 2023 10:10:18 -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 93E81C151542 for <coin@irtf.org>; Thu, 18 May 2023 10:10:18 -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=ddO+QCbot2d9+bN9oh5XcIVK++Qvc55K6pFJXFHbInM=; b=iUYQikfP3Gmi4+TzqLAzjETOGs JpoMA4Hxhshy/CiEYQd7RqXrl3tAMGAk3PdpEqm3rL2btOZkRCRsqBCo5Fly4kcqAiC0VCeFXvUVc yRONo59UYw4vM8cY4FJ4w1Dt8s+E+UBdyCYxo6x68//SX21xPCxYXJLVzVaZRwwmnqxLmlhC9Rac6 DZl34o7epkdVrv/uINdXfPDFT64RjaAKcMpygo7ykBdK75r+y1eUJ5r2uilvFqb2mdSyBGg6S5AT7 DQg0GevC5h5PcNv2X4pNgLWd4m5bNaZ3E6JwRWSnYAI2P1ov6DY6Ke6TZ7lgM3BXcG8hClDaJV78y EjjOJvEg==;
Received: from [76.191.34.66] (port=60540 helo=hemantPC) by web50.dnchosting.com with esmtpa (Exim 4.96) (envelope-from <hemant@mnkcg.com>) id 1pzh8r-0001kJ-1K; Thu, 18 May 2023 13:10:17 -0400
From: hemant@mnkcg.com
To: 'Haoyu Song' <haoyu.song@futurewei.com>, ehalep@mojatatu.com, 'Toerless Eckert' <tte@cs.fau.de>
Cc: hemant=40mnkcg.com@dmarc.ietf.org, "'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:10:18 -0400
Message-ID: <02c501d989ab$9ee63440$dcb29cc0$@mnkcg.com>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIxBKBzfrzN0AW7R0uxmgt8NzLx7gE7vxklAjW3P5gCJVowzwG6owZPAbklKiwBjPTNRAHuP0tRAq/Fk7oBMBPHnALP0N6QAji6kzgB08G1vK33PZHg
Content-Language: en-us
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_02C0_01D9898A.1785FF10"
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/U6kfuhji4eQnKyuFrkowHdNCnDo>
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:10:22 -0000

Also, the P4 PNA work has sample P4 programs to maintain TCP connection
state.  

Hemant

-----Original Message-----
From: Coin <coin-bounces@irtf.org> On Behalf Of Haoyu Song
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; '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. 
--
Coin mailing list
Coin@irtf.org
https://www.irtf.org/mailman/listinfo/coin