[j-nsp] rib-sharding and NSR update

[Saku Ytti]

On Mon, 3 Jun 2024 at 05:26, Gustavo Santos via juniper-nsp
<juniper-nsp at puck.nether.net> wrote:

> We will try it again later this year. If update threading / rib-sharding
> works as expected it will be better than having non stop routing running.

I think you need to contact support and work with them, NOS SW quality
is terrible and whatever problem you're seeing might be some corner
case that happens just you, and it will never get fixed if you're not
proactive about it.

> Last time we had an issue caused by bgp routing update, it tooks about 50
> minutes to advertise all needed routes to one of the transit providers,
> because the time it takes to send full routing tables feed to remote peers.

Could be a plethora of things, but by default the TCP window won't
grow past 16kB, so if you have any latency at all, performance is
destroyed. You can raise this to 64kB, but windowning is currently not
supported. And in my own testing, performance was gated by the 64kB
window, we were able to fill the entire window, so convergence was
limited by the 64k window.

But it's not necessarily super trivial to make BGP perform well, as
you may have 10Mbps static policer for queue towards control-plane
shared by BGP, all IGPs, etc, so if you were able to make BGP perform,
you could potentially kill your IGP, so problem may recurse into
complex one, and the DE who made the design choices may not anymore be
employed so there may not be anyone left who will be able to make
informed decision on how to change the behaviour.


-- 
  ++ytti