On Fri, Jul 13, 2018 at 02:37:32PM +0200, Mark Tinka wrote: > Anyway, the operational issue we ran into was due to our aggressive > policy to drop Invalids. The reason this became an issue was networks > that ROA'd just their aggregates, but either forgot to or decided not to > ROA the longer prefixes that were children of the aggregate. > > So suddenly, you have a customer who is multi-homed; one connection was > to us, SEACOM, and the other was to another ISP not doing OV. Our policy > meant the customer was receiving far fewer routes from SEACOM vs. the > other provider, which took traffic away from us (and consequently, $$); > not to mention the NOC-related headache. > > After 2 years of struggling to get community traction with OV based on > this policy, we decided to maintain the validation, but remove any > actions being ran against the validation result.
Have you considered applying "invalid == reject" on just transit/peering sessions rather than customer sessions as an intermediate step? I bet most misconfigurations or hijacks didn't come in via your customers. > I would really be keen to hear feedback from you or others that have > decided to deploy OV and drop Invalids. I'm more than happy to get > back on to this wagon in the interest of cleaning up the global BGP > table. But it needs mass... Cool! Kind regards, Job