[j-nsp] Hardware configuration for cRPD as RR

[Mark Tinka]

On 2/6/24 18:53, Saku Ytti wrote:

> Not just opinion, fact. If you see everything, ORR does nothing but adds cost.
>
> You only need AddPath and ORR, when everything is too expensive, but
> you still need good choices.
>
> But even if you have resources to see all, you may not actually want
> to have a lot of useless signalling and overhead, as it'll add
> convergence time and risk of encouraging rare bugs to surface. In the
> case where I deployed it, having all was not realistic possibly, in
> that, having all would mean network upgrade cycle is determined when
> enough peers are added, causing RIB scale to demand triggering full
> upgrade cycle, despite not selling the ports already paid.
> You shouldn't need to upgrade your boxes, because your RIB/FIB doesn't
> scale, you should only need to upgrade your boxes, if you don't have
> holes to stick paying fiber into.

I agree.

We started with 6 paths to see how far the network could go, and how 
well ECMP would work across customers who connected to us in multiple 
cities/countries with the same AS. That was exceedingly successful and 
customers were very happy that they could increase their capacity 
through multiple, multi-site links, without paying anything extra and 
improving performance all around.

Same for peers.

But yes, it does cost a lot of control plane for anything less than 32GB 
on the MX. The MX204 played well if you unleased it's "hidden memory" 
hack :-).

This was not a massive issue for the RR's which were running on CSR1000v 
(now replaced with Cat8000v). But certainly, it did test the 16GB 
Juniper RE's we had.

The next step, before I left, was to work on how many paths we can 
reduce to from 6 without losing the gains we had made for our customers 
and peers. That would have lowered pressure on the control plane, but 
not sure how it would have impacted the improvement in multi-site load 
balancing.

Mark.