Hi Ronald, > On 11 Jun 2021, at 23:19, Ronald F. Guilmette via db-wg <db-wg@ripe.net> > wrote: > > In message <4282f6ef-99c9-4306-817b-95382487c...@ripe.net>, > Edward Shryane <eshry...@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.
This particular cleanup job is deleting route(6) objects referencing *unregistered* space ("available" or "reserved" in delegated stats), rather than any "bogons". The aim is to cleanup route(6) objects after an RIR deregisters space (e.g. 196.52.0.0/14, as discussed in January). > > And isn't the project here to detect and eliminate bogon route objects? > > We seem to have a communications/terminology gap at some level. Not for now. I suggest we define "bogon" space and cleanup any referencing route(6) objects as a separate effort. Note that Whois already blocks the creation of new route(6) objects with a "bogon" prefix, as defined here: http://www.team-cymru.com/bogon-reference.html > >> 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. > Thanks Nick for explaining the location of the RIR delgated stats files. > (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.) > I'm using the RIR delegated stats as they are already in use by Whois, I haven't checked for differences with the NRO delegated stats. >>> 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? We can extend the cleanup job to also validate the origin AS, if the rules are clear and if the DB-WG agrees. > >> 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. > Thanks, that was my question, should we validate that *either* the IP or AS is unregistered, or *both* IP and AS are unregistered (and you indicated *either*). Regards Ed Shryane RIPE NCC >> 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 >