In message <4282F6EF-99C9-4306-817B-95382487CBBA@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
I see. That message is very interesting. There are a couple of parts of it that I have trouble interpreting however, to wit:
There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected.
Can you explain the meaning of that, in small words?
The cleanup job will use all of the RIRs delegated stats. If the route prefix is not defined in any delegated stats, then it's skipped.
Umm... I thought that it was the definition of a "bogon" that it is some IP space (or ASN) that has not been assigned, by any RIR, to any other party. And isn't the project here to detect and eliminate bogon route objects? We seem to have a communications/terminology gap at some level.
I'm not using the NRO extended stats, but rather I'm combining each RIRs delegated stats.
Each RIRs delegated stats are more specific about the prefix status, including "assigned".
Could you please post the 5 URLs for those 5 RIR delegated stats files? I'm sure that I could find them on my own, if pressed, but it would save me a small amount of time if you would just post them. (It is a curious oddity that the NRO stats file is apparently not quite a perfect representation of the sum total of those 5 files.)
Last but not least, there is this very perplexing line:
The origin AS status is not considered, only the IPv4/IPv6 prefix.
Why?
The origin AS is not validated either in the RIPE database when creating or updating a route(6) object (apart from excluding AS numbers reserved by IANA).
Also, this cleanup job was created out of discussion about deregistered address space: "196.52.0.0/14 revoked, cleanup efforts needed" in January.
OK, but as long as a cleanup is happening anyway, I would like to propose that all (stale?) route objects which reference bogon ASN should be elided also. It seems quite entirely half fast for you/NCC to be doing all of this work to eliminate JUST the bogus route objects that reference bogon IP address space, while leaving alone all of the route objects that refer to bogon ASNs. I mean, is it just me, or isn't that obvious?
If the DB-WG agrees that we should, and can define *which* AS numbers should be cleaned up, the job can be extended to include AS numbers.
I have stated my own preference. I certainly would be happy to hear the opinions of others in the WG.
If so, should *both* the prefix and origin be considered, or separately (i.e. should we cleanup if either is unregistered)?
I'm not sure that I am following you here. I mean I'm not even sure your question makes any sense to me. I will just reiterate what I believe I have already expressed, i.e. that in my opinion a given route object is, by definition, "bogus" (and should be removed from the DB) if *either* it references bogon IP space *or* it references an unassigned (bogon) ASN.
Also thanks to you for checking NONAUTH for bogon route objects, your questions and comments are very welcome.
Just trying to be helpful, if I can be. I should be thanking *you* for your work on and involvement in this rather elaborate cleanup process. It's a tough and probably thankless job, but somebody's got to do it. I wish that I could wake up tomorrow and find that the whole world had totally and universally embraced RPKI, but until then, the route registries of the 5 RIRs are still being relied upon by a lot of folks, and it just won't do to have these route registries oozing bogosity. Regards, rfg