Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] New Policy Proposal - "Route aggregation policy (AFPUB-2017-V4-002-DRAFT-01)"

David Hilario d.hilario at
Wed Apr 26 05:23:13 UTC 2017

Hi Alain,

On 25 April 2017 at 11:57, ALAIN AINA <aalain at> wrote:
>> On Apr 24, 2017, at 4:39 PM, Mark Elkins <mje at> wrote:
>> Looking at the re-wording suggested by the Policy - I seem to remember
>> that AFRINIC staff try their best to do this type of thing
>> automatically. It may not be necessary to state.
> Yes, no need.
> Aggregation is one the Goals of the Internet Registry system and they always do their best  towards that  it during the distribution.
>> It is however, a good thing to say (try and allocate consecutive
>> allocations to LIRs) to attempt to reduce the number of entries in the
>> routing table.
> I can live  with this even though is redundant.
> But the text and the title of the policy seem to indicate  something more ...
> ====
> New text:
> 5.4.4 For any LIR or End User requesting IPv4 address space during the Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period. For the sake of routing table conservation, prefixes will be issued as aggregates when an LIR requests multiple additional allocations.
> =======
> Is the author implying:
> 1)  apply reservation ?
no reservation.

> 2)  force LIRs to renumber ?

Renumbering had not been considered.

I had not considered the scenario of renumbering from old allocations.
That would involve an LIR asking for an additional allocation with a
target size and agree to renumber allocation X,Y,Z within X amount of
time if approved.
Might not be feasible with the limited pool of the last /8.
It also opens the door for abuse in whitewashing IP address that
somehow got blacklisted.

I would limit the scope to new allocations only, in some form of
"aggregated requests" definition, the proposal text could be change to
explicitly state that and avoid confusion.

> And if yes, how to apply to the  last /8 as we are no longer in the normal mode.

Phase 1 does not really benefit from this proposed change, as LIR can
get the allocations they asked for up to /13 anyways.
In Phase 2 an LIR that needs a /20 will need to make 4 separate
requests to fulfill that need, sine the policy states there is not
limit on the amount of additional allocations requests, we can expect
organizations in need of space to make use of that.

The proposal here is simply to let AFRINIC evaluate the four requests
and issue an aggregated /20 as an outcome, since there is no explicit
limit on the amount of requests an LIR can do, it will only mean that
the process will take longer than to just receive a single /22, 4x/22
would need to be evaluated, it creates one administrative drawback for
the LIR and not so much for AFRINIC ltd as they would one way or
another make four evaluations either aggregated or individual ones,
but it also provides the LIR with an easier to manage pool at the end
of the tunnel when all is done and approved.

> On the general, do we need a  “Route Aggregation“ policy for this ? Can’t this just be an update to the Softlanding policy ?

I understood that since the AFRINIC CPM was put in place, policy
proposals were not full blown stand alone policy documents, but rather
now allow for changes to be made in the actual document where needed.
This enables small changes where needed without having to
review/re-approve the rest of the document anymore, apologies of that
isn't the case, then I would need to go back to the drawing board.

> Hope this helps
> —Alain
>> On 24/04/2017 11:52, SamiSalih wrote:
>>> Dear AFRINIC PDWG Members,
>>> Greetings,
>>> We have received a new policy Proposal - "Route aggregation policy (AFPUB-2017-V4-002-DRAFT-01)"
>>> From David Hilario (d.hilario at
>> --
>> Mark James ELKINS  -  Posix Systems - (South) Africa
>> mje at       Tel: +27.128070590  Cell: +27.826010496
>> For fast, reliable, low cost Internet in ZA:
>> _______________________________________________
>> RPD mailing list
>> RPD at
> _______________________________________________
> RPD mailing list
> RPD at

kind regards,
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
e: d.hilario at

More information about the RPD mailing list