[j-nsp] juniper router reccomendations

[Jesper Skriver]

On Mon, Aug 01, 2016 at 01:03:59PM +0300, Saku Ytti wrote:
> On 1 August 2016 at 11:02, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:
> 
> > So essentially you're suggesting holding up BGP updates to peers until the
> > router has it's FIB fully populated right?
> 
> Yes.
> 
> > I think that might be easier said than done, there would have to be a
> > correlation between Protocol to RIB update job ID and RIB to FIB update job
> > ID, so that each FIB update job is traceable back to the protocol which
> > initiated it. Now what would constitute the job, single pfx a bulk of pfxes?
> 
> I don't see why it would be fundamentally impossible. Just don't send
> ACK until you've converged. Maybe in practice it's too expensive,
> maybe you can make it cheap enough by throwing DRAM and cores at it.
> I'm thinking something like BEAM cost processes for each BGP TCP packet.
> 
> > Anyways, till the triggered approach is implemented I think you can slow
> > down iBGP update generation with the "out-delay" knob.
> > It's not as clear of a cut as with csco's "neighbor advertisement-interval"
> > but looks like it can do the same thing.
> > https://kb.juniper.net/InfoCenter/index?page=content&id=KB26446&actp=search
> 
> Relying on timers seems like huge, hard to manage complexity.

Unreliably more like it, what would the right timer value be to
avoid even short blackholes when things are busy, without having
excessive waits in other case.

update wait-install seems like what is needed, I believe both
Arista and Cisco (at least on some OSs) supports this today,
possibly other vendors too.

/Jesper