Re: [Bier] ASIC restrictions

[Tony Przygienda <[e-mail]>]

yes, discussion has been many times but in 2 quips

1. high end chips at least are not really limited by the overall size but
the size they can put on the "really, really fast packet header
processing scratchboard". And then you recirculate if you blow out that
size. Which halves the throughput and hence the problem. That's, as you
have seen in e.g. P4 work that was presented, makes things that work fine
in smaller labs, networks, not feasible in large deployments in terms of
economics. Making the scratchboard wider is very expensive in terms of
die/power etc/etc obviously so it needs really strong economic drivers.
2. BIER introduced a way to deal with the problem via the concept of sets
(and subdomains) and that's about the best engineering tradeoff on high end
chips that's viable. ON good chips replicating a packet three times instead
of twice is till much cheaper than recirculating from engineering
perspective. In very loose terms explanation lies in the fact that holding
stuff on-chip is very expensive, pushing it out the box is significantly
cheaper (in a sense timexdelay buffer is way cheaper than on-die buffer)

BIER has been built as architecture by folks that were fighting those
silicon things from the early days of the IP technology and many of them
_way_ before ;-)

--- tony

On Thu, Nov 10, 2022 at 6:40 PM Vasilenko Eduard <vasilenko.eduard=
[e-mail]> wrote:

> 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 foreverJ
>
>
>
> [image: cid:image001.png@01D3A7DF.E7D86320]
>
> Best Regards
>
> Eduard Vasilenko
>
> Senior Architect
>
> Europe Standardization & Industry Development Department
>
> Tel: [phone]
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>