Dear Lu, On Wed, Jun 13, 2018 at 06:19:10PM +0800, Lu Heng via db-wg wrote:
In the past three weeks, we have done some tests on 3 AFRINIC /24 which have been announced in the US, Europe, and Asia, by an ARIN ASN, APNIC ASN, and an RIPE ASN.
Test results:
If it is a direct announce to NTT, Telia, GTT as a small provider and without route object, announcement will not be accepted.
It is of course expected and documented behavior. https://www.us.ntt.net/support/policy/rr.cfm I am happy to learn that competitors also reject announcements from their customers if no route-object exists.
All of them accept RIPE route object.
NTT would also accept the announcement if it were registered in any of the other IRRs https://www.us.ntt.net/support/policy/routing.cfm#RR The list of accepted IRRs differs from provider to provider.
Current situation:
AFRINIC accepts foreign ASN with manual verification of the ownership of the ASN holder as stated by their hostmaster in the mailing list. If you don't own the ASN, they will not create the route object. Despite this, the process is long and unpractical in daily operation.
For some context, here AfriNIC staff indicate they see no downside but it is considered a low priority. https://lists.afrinic.net/pipermail/dbwg/2018-June/000053.html Another mail on the topic indicates that AfriNIC is taking it under consideration to stop doing the useless manual verification: https://lists.afrinic.net/pipermail/dbwg/2018-June/000064.html The upside is that AfriNIC staff is properly informed and aware of the effects of their constraints impose on operations.
Some providers do accept RPKI. One can create an AFRINIC RPKI that go though the filter, however, not all provider accept RPKI at the moment.
In conclusion, If you employ a non-Afrinic asn for announcements (which means a foreign asn), using RIPE’s route object will be the only choice for you unless you are one of those big telecoms which has the liberty to announce anything as they wish.
This is not correct, you can also use RADB, NTTCOM, LEVEL3, or ALTDB, etc. RIPE is/was not an exclusive provider for this type of service.
I am not opposing to the idea of cleaning up the database, but until things get fixed, the current process will only break networks.
Fortunately the current scheduled changes do not involve deleting objects from the RIPE NCC IRR. So it will not break existing networks, but it may inconvenience or delay provisioning if you are relying on a security hole in the RIPE database. This is an important distinction. Ultimately this is a problem between you and AfriNIC. You are a member of AfriNIC and you pay money to AfriNIC for them to provide you services (such registration, IRR, and RPKI) and you currently you can't make good use of those services. I hope AfriNIC will make the required changes rather sooner than later. Kind regards, Job