On Thu, 11 Nov 2021 at 15:01, Mark Tinka <[email protected]> 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
