[c-nsp] FIB scale on ASR9001

[Lukas Tribus]

On Thu, 11 Nov 2021 at 15:01, Mark Tinka <mark at tinka.africa> wrote:
>
>
>
> On 11/11/21 15:43, Lukas Tribus wrote:
>
> > For ROV to work reliably it needs to be able to reconsider previously
> > rejected invalids, so I would not recommend disabling
> > soft-reconfiguartion inbound, instead I'd suggest to set it to always.
>
> If my router vendor is not automatically applying BGP policy based on
> RPKI state, it shouldn't matter what ended up in RIB if I have not set
> an explicit policy to act on RPKI state.
>
> So if a previously-Invalid route now becomes a VRP, and is then good to
> go for export toward a neighbor based on existing policy that matches,
> why can we not leverage Route Refresh to only cater for that change?

I believe with the amount of RAM we have on those boxes nowadays,
keeping a copy of everything should be a non-issue.

On the other hand, leveraging route-refresh changes your EBGP
behaviour, which can trigger remote and local bugs, or, as in your
case, trigger humans with most likely a little over-dramatic
monitoring. I won't trust other peoples BGP routers and
implementations more than I absolutely have to and I don't think my
time is well spent arguing with other people about their
underdimensioned control plane CPU, oversensitive CPU load monitoring
or troubleshooting corner cases in their BGP implementation that
trigger bugs in route refresh code. And then the need to explain in a
RFO why your network heavily uses route-refresh which triggered that
remote bug in the first place, while your competitor didn't change
anything in their BGP configuration in the last decade, so "they
didn't have any issue with this, only your network has issues''.

Those are all rabbit holes that I will gladly trade for a little bit
of RAM usage in a heartbeat.


Lukas