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'm wondering if we can carry a loose relationship between the VRP database, and RIB state.
Of course it would be better to store ROV-rejects separately, instead of rejecting them. Better yet: add a new drop statement in RPL, which makes the route not eligible for path selection, but doesn't remove it from memory - this way the operator has full flexibility.
I still don't get why we need to worry about Invalid routes, if the operator is doing ROV to drop them. As soon as they become Valid, the RTR update will tell us that and we can allow for incremental changes for what we ask our neighbors to accept.
I can't believe I'm saying this, but a famous CPE vendor from Latvia actually supports this (routing filter action: reject vs discard) [1], maybe the XR BGP team could steal some ideas from them ;)
:-).
I don't like to depend on optional or not commonly used BGP features and code paths in other people's networks for changes of any kind on my end.
In Juniper's case, their default to keep a copy of Adj-RIB-In had the unintended side-effect of making ROV deployment less exciting. However, I still feel not being able to leverage Route Refresh and avoid this clumsiness with ROV is below par for what we can design. After all, that was the whole point of Route Refresh...
Memory consumption was negligible for my use-case, iirc it was 200 - 300 MB for 30 - 40 peers, one of which was transit (so full table - this was about a year ago). I believe we had this conversation before, and you mentioned that this could be a DoS vector, which is true but all the solutions that we can possibly suggest simply implement a "selective" soft-reconfig inbound always" anyway, so the DoS vector needs to be addressed in a different way, in my opinion.
Well, we had several peers disable sessions with us because their CPU was being impacted by all the refresh messages we were sending. So we have seen it become a DoS vector toward others, and then by extension, toward us when we have to lose shorter paths to those peers due to the session tear-down.
Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
