Agreed.

I think as a practical matter, the large majority of operators probably only care about time from last update / EoRIB -> FIBs forwarding working. As long as that time delta is acceptable for their environment and circumstances, that's 'good enough'. Definitely some edge cases and circumstances that can factor in.

Those of us in the massive scale part of the world certainly have our own unique problems with this stuff. :)

On Sat, Apr 13, 2024 at 11:58 AM Jared Mauch <jared@puck.nether.net> wrote:

> On Apr 13, 2024, at 12:15 AM, 7riw77@gmail.com wrote:
>
>
>> I feel like this shouldn't be listed on a data sheet for just the whitebox hardware. The software running on it would be the gating factor.
> There would be two things ... BGP convergence, and then the time required to get routes from the RIB into the hardware forwarding tables. These are completely separate things. Both are gated on software for the most part, and it would be hard to measure them unless you know a lot more about the environment. Even then it would be a bit of a guess.
>
> Contact me off list if you're interested in prior experience in this area.
>
> :-) /r

Yeah, I think the question is coming from the wrong direction, which is what route scale do you need then match it to the hardware. You can load a variety of software on these devices, including putting something like cRPD on top of it so you have the Juniper software and policy language, or roll your own with FRR, BIRD or something else.

The kernel -> FIB (hardware) download performance will vary as will the way the TCAM is carved up into the various routes and profiles.

It also depends on what you download to the FIB vs what you have in your RIB, for example a fib-filter in Juniper parlance may give you the ability to carry a full routing table but just a default and your local stub routes depending on the device role. (Connected/static + local iBGP+eBGP learned)

- Jared