On Fri, Oct 29, 2021 at 01:20:33AM +0400, Musa Stephen Honlue wrote:
Personally I recommend dropping them invalids.
100%
However, you could set local preferences as follows: - Valids routes get the highest local pref - unknown routes get a medium local pref - Invalids routes get the lowest local pref
In this way, if you have competing routes, the one with the higher local pref gets preferred. By so doing, you are sure that an invalid route will never get preferred over an unknown one or a valid one.
There are two core issues with the above approach: 1/ invalid 'more-specific' routes, regardless of local pref, will 'win', so the approach is 'useless'. 2/ modifying BGP path attributes based on the validation state introduces needless churn and BGP UPDATE flooding. Consider the following scenario: someone new to the RPKI ecosystem decides to create RPKI ROAs. They expect nothing to happen, but under the hood new BGP UPDATEs are flooded in all directions because the LOCAL_PREF attributes needs to be updated. Same problem when associating BGP communities to validation states. To quote myself from https://bgpfilterguide.nlnog.net/guides/reject_invalids/ """ It is considered harmful to manipulate BGP Path Attributes (for example LOCAL_PREF or COMMUNITY) based on the RPKI Origin Validation state. Making BGP Path Attributes dependent on RPKI Validation states introduces needless brittleness in the global routing system as explained here. Additionally, the use of RFC 8097 is STRONGLY ABSOLUTELY NOT RECOMMENDED. RFC 8097 has caused issues for multi-vendor network operators. """ Nick Hilliard shared similar sentiment: https://mailarchive.ietf.org/arch/msg/sidrops/dwQi9lgYKRVctdlMAHhtgYkzhSM/ Kind regards, Job