Registry Working Group

[Bill Owens <>]

As Jeff Bartig pointed out last week, Google is now flagging routes as 
'irr-invalid' in their ISP portal. However, in our case every 'invalid' route 
is actually being accepted and carrying traffic, though I can't tell whether 
that's because they are simply flagging, or because the ISP portal report is 
out of sync with the real filters. I'm leaning towards the former, that they 
are only reporting errors without placing the filters on the actual BGP 
sessions, because we have one prefix that is intentionally not in the RADb or 
any other IRR and it is still accepted. 

For some of the errors it appears they simply aren't getting a complete view 
of the data, since the vast majority of the 'invalid' routes have RADb 
entries. In at least a couple of cases all of the routes for a particular 
origin AS are flagged invalid except those that have old Level3 IRR objects, 
but there's no pattern I can discern. They do not appear to be using ARIN 
WHOIS OriginAS. For those keeping score, we are advertising 132 routes, they 
are flagging 35, all but one of those have correct RADb objects.

I've been doing my testing by starting up a GCP instance and running 
traceroute from the CLI, absent any Google traceroute looking glass. That 
works fine except that the GCP instance doesn't appear to have any support 
for IPv6, so I can only test v4 routes.

We do have one case where a campus is originating their prefix to NYSERNet 
using their AS, and having their ISP (a cable company) originate it using the 
ISP's AS; Google seems to be somewhat confused by this and is actually using 
both paths. We're going to work on that. There are valid RADb objects for 
both origins, and yet Google is flagging the one that comes across our 
peering. Weird.

Bill.