Everyone thinks they're a unicorn and they're special and it's a secret... 
other than those that don't. ;-) 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Tom Samplonius" <t...@samplonius.org> 
To: nanog@nanog.org 
Sent: Thursday, November 16, 2023 6:54:17 PM 
Subject: Generally accepted BGP acceptance criteria? 


In the world of IRR and RPKI, BGP route acceptance criteria is important to get 
right. 

DE-CIX has published a detailed flow chart documenting their acceptance 
criteria: https://www.de-cix.net/en/locations/frankfurt/route-server-guide 

But I don’t see a lot of operators publishing their criteria. I imagine there 
is a some sort of coalescing industry standard out there, but so far I can’t 
find it. Of the upstreams I use, just one publishes a flowchart. Another is 
basically refusing to explain anything other than they “use” IRR and RPKI, ad 
that RPKI is “good”. 

I assumed that everyone implementing RPKI validation, would skip IRR route 
object validation if the route is RPKI-valid. I assumed that everyone is doing 
this now, or would do this when they implement RPKI validation. But I spoke to 
an operator today, which still expects all routes to pass IRR as well (and 
while they perform RPKI-validation, they effectively do nothing with the 
result). To me, this seems like a different direction than most operators are 
going. Or is it? 

The most surprising thing in the DE-DIX flow chart, was that they check that 
the origin AS exists in the IRR as-set, before doing RPKI, and if the set 
existence fails, they reject the route. I don’t see a problem with this, as 
maintaining as-sets is easy, but it does prevent an eventual 100% RPKI future 
with no IRR at all. 

I also thought there may be an informational RFC on this, but I couldn’t find 
anything. Has there been anything published or any presentations given, on 
generally accepted BGP route acceptance criteria? 


Tom 

Reply via email to