Hi Ronald,
> On 11 Jun 2021, at 23:19, Ronald F. Guilmette via db-wg <[email protected]>
> wrote:
>
> In message <[email protected]>,
> Edward Shryane <[email protected]> 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
>
