IETF Logo Mail Archive

[Bier] ASIC restrictions

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 10 November 2022 18:40 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D374C1526F8 for <bier@ietfa.amsl.com>; Thu, 10 Nov 2022 10:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 UeoBw-uG6yrs for <bier@ietfa.amsl.com>; Thu, 10 Nov 2022 10:40:01 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF240C15270E for <bier@ietf.org>; Thu, 10 Nov 2022 10:40:00 -0800 (PST)
Received: from frapeml500006.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4N7VvL2rm6z67kFH; Fri, 11 Nov 2022 02:37:50 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by frapeml500006.china.huawei.com (7.182.85.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 10 Nov 2022 19:39:57 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 10 Nov 2022 21:39:56 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.031; Thu, 10 Nov 2022 21:39:56 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "bier@ietf.org" <bier@ietf.org>
CC: Toerless Eckert <tte@cs.fau.de>
Thread-Topic: ASIC restrictions
Thread-Index: Adj1L2JWyFGjbSQ/RoaUjTp3hbbFvA==
Date: Thu, 10 Nov 2022 18:39:56 +0000
Message-ID: <81ff0e3b3bad4e6a892e3aa005aa9e9a@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.149.109]
Content-Type: multipart/related; boundary="_004_81ff0e3b3bad4e6a892e3aa005aa9e9ahuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/PjPBIx9jlf0NmGi16H3hN2c66pY>
Subject: [Bier] ASIC restrictions
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2022 18:40:03 -0000

Dear multicast experts,
I am not subscribed to this alias, I am not even a multicast expert, I am a stranger here.
When I heard today the comment that 1280B+1280B is the challenge from MTU's point of view - I reacted that it is not the biggest problem, a much bigger problem would be the overall size of all headers that particular Chip could process (no way for 1280Bytes, never!).
Toerless Eckert asked me to put my comment here.
Well, I did believe that it is well-known and some sort of obvious.
Some routing switches (for DC/Cloud) still have the restriction 128Bytes for all headers (including MAC, VLAN, GTP, SRv6, etc).
Some high-high-end Telco routers are capable to process 384bytes - it is probably the upper limit now (again, for all L2-L4 headers).
When I have seen the first BIER IETF presentation in 2016 - it immediately comes to my mind that "not all vendors would be capable to implement this".
It would be not polite to say at least 2 names here - I could not respond for other vendors.
I have seen 1k routers network (and many in the range between 256 and 512 PEs), but 1k is already 128bytes just for BIER bit-field.
Especially problem would be in the combination with SRv6 which could have an SRH header up to 208bytes.
Of course, it is possible to break E2E, split for Areas/Domains, and stitch by Gateways.
And you discussed today the way how to localize bit patterns - it is probably some sort of automatic split for Areas (I did not read the draft).
I did always believe that "headers size" is the BIER's primary problem. Hence, it was probably discussed here many-many times.
Sorry, if I stepped on something well discussed again. As I said: I am a stranger. I am just passing by. Sorry, for the point if it is a triple duplicate.

Your architecture is so nice (stateless) - I like it very much. And I am sure that my employer has no problem with header sizes. BIER forever:)

[cid:image001.png@01D3A7DF.E7D86320]
Best Regards
Eduard Vasilenko
Senior Architect
Europe Standardization & Industry Development Department
Tel: +7(985) 910-1105, +7(916) 800-5506

v2.29.0 | Report a Bug | By Email | System Status