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,
> 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. 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 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.

Another mail on the topic indicates that AfriNIC is taking it under
consideration to stop doing the useless manual verification:

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,


Reply via email to