[rpd] Last Call for "AFPUB-2016-GEN-001-DRAFT-04 - Internet Number Resources Review by AFRINIC"

[David Hilario]

Hi Simon,

Thanks.

On 12 July 2017 at 20:31, Noah <noah at neo.co.tz> wrote:
>
>
> On Wed, Jul 12, 2017 at 8:27 PM, Simon mayoye <mayoye at seacom.mu> wrote:
>>
>> Hi David,
>> Well I believe every network has a way of resource usage, for us a churned
>> customer translates to a freed resource for use by any new customer and if
>> Afrinic ran an audit and realized that we do not meet the % usage and fits
>> in the policy, happy to have other users get allocations as well.
>>
>

It is very honorable of anyone who is willing to return space, I have
seen it happen a few times in other regions where some organisations
actually returned extremely large pools of unused space to their
respective registries, it was only LEGACY though, and there was no
audit policy with de-registration in mind needed for that, they just
saw it as the thing to do.

A quick glance at the AFRINIC Database gives the following:

Your company manages just a bit over one million IPs, largest
allocation being issued more than 3 years ago.
Roughly 40%  is registered in the AFRINIC database as assignments,
leaving 60% of the space technically unused, by policy space that is
not registered is not in use, it doesn't matter if it is being
announced.

With unregistered space ranging from /24s to /16s.

Out of the ~40% that is registered, none are registered as end-user
assignments, but almost entirely as infrastructure, which is usually
common for service provider with end-users where there are no subnets
issued to customers. LIRs that mainly deal with corporate customers
are normally issuing subnets to their customers in /29, /28 and so on
based on the customers needs, each of those requiring to be registered
separately in the AFRINIC database by policy.
Or as sub-allocations whenever the customer will further delegate to
their own end-users.

At the moment from my understanding of the current AFRINIC policies,
the only part where you maybe are in policy violation is the end-user
assignments that may or not be missing that could cause an issue to
your organisation under the current policies.
But AFRINIC is not actively hunting those and will not threaten for
de-registration as it is today (I hope) it would become an issue
during an additional allocation request I guess, or maybe you truly
have no customers receiving subnets and all your corporate customers
are on shared pools.


If the review policy passes, many here have been asking for space that
was unused after being issued years ago to be returned accordingly so
it can be redistributed, this review policy will be targeting larger
LIRs at first.

Many in this thread voiced a favor for the deregistration of such
space, if that is applied.
Ultimately you would go from one nicely aggregated /12 to some 18 or
so different route announcements to manage and breaking reverse
delegations in the process each time you need to break apart a /16.

Further down the line of the audit would be the registration of the
assignments or sub-allocations, retro-actively fixing around 400K of
IP registration, if you have end customers receiving subnets that is.

This alone will be taking some time, not sure if 3 months is enough
unless you put quite a few full time staffers on it or face
de-registration after three months.

This is really close to a worst case scenario, I really cannot see
this happening to any organisation, but as you see, the larger the
organisation the bigger the problems become within this Review policy.

I do not wish for any LIR to have to go through any of the above.
This is why I oppose large part of this policy, it is blindly asking
for things that cannot possibly be done without harming the members,
their customers and ultimately the relationship between the members
and the AFRINIC.


> +1 Simon.
>
>  Noah
David Hilario

IP Manager

Larus Cloud Service Limited

p: +852 29888918  m: +359 89 764 1784
f: +852 29888068
a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
w: laruscloudservice.net
e: d.hilario at laruscloudservice.net