[j-nsp] improving global unicast convergence (with or without BGP-PIC)

[Saku Ytti]

On 20 April 2017 at 11:43,  <adamv0025 at netconsultings.com> wrote:

Hey,

> FIB programming time has always been a memory write limitation, router memories used for lookup are streamlined for read performance, sacrificing read performance to reduce the cost, so there's only so fast you can go and with the forwarding tables ever growing it's a lost battle, and a meaningless one as well, since we already have elegant solutions to work around this limitation. I mean it's good they're fixing crappy code to catch up with the actual HW limits at hand though.

The memory is just DRAM on Trio, DRAM isn't significant bottleneck,
considering there are/were pathological cases where router has
advertised new path and not programmed in in HW for 30min or more.
Also somewhere JNPR has gotten wrong message from customers, as they
seemed to think this is just about FIB update being slow, but that's
not even the main problem, main problem is software and hardware being
decoupled. Blackholing is bad, using old path in software and hardware
until you can actually program the new entry is acceptable. After this
is done, THEN focus on making it faster.

Juniper has very good view into the problem, they know how much of
convergence budget is being used in each step, I'm sure account team
can share a deck about it. I know they are working on both problems,
better guarantees that blackholing won't happen, and reducing time
spent in each place in the overall convergence budget.

The synchronicity guarantees are not JNPR specific problem at all, I
know people see these in some CSCO platforms and Arista by default
does not guarantee it, they have knob for it today. It wasn't entirely
obvious to me what the guarantee actually does, it wasn't
all-the-way-to-chip guarantee, I guess it was to the LC CPU guarantee.

-- 
  ++ytti