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

[adamv0025 at netconsultings.com]

> From: Saku Ytti [mailto:saku at ytti.fi]
> Thursday, April 20, 2017 10:08 AM
> 
> 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, 
Agree, there's a solution for that in form of FRR for IGP/RSVP and BGP, so in my opinion there's no value in investing time and effort into this. 

> 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.
> 
IOS-XR has BGP-RIB Feedback since 4.3.0. (It actually is FIB feedback, the name is so confusing). 
And you have also the periodic Route and Label Consistency Checker -very helpful to point out HW programming issues. 
I can't recall whether Junos has a similar feedback mechanism implemented or planned. 

> 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.
> 
Good point, I haven't checked actually but if the feedback wouldn't be all the way down to NPU lookup memory it wouldn't be of much help. 

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::