Search RPD Archives
[rpd] New Policy Proposal - "Route aggregation policy (AFPUB-2017-V4-002-DRAFT-01)"
aalain at trstech.net
Tue May 23 19:19:18 UTC 2017
> On 23 May 2017, at 08:13, David Hilario <d.hilario at laruscloudservice.net> wrote:
> Thanks to Ernest for the heads-up that staff assessment was published yesterday:
>> Although we can make a best effort, AFRINIC cannot guarantee that subsequent >assignments/allocations will be contiguous.
> The purpose of the proposal is to have a procedure setup by AFRINIC in
> case someone wants to have contiguous rather than split space from the
> same /8 when making future requests.
> It was left without any specific implementation to leave free hands in
> its possible implementation.
It has always been like that and RIRs have done a great job in allocating the v4 space (limited resources). IPv6 makes it easier…
I hope we may got another /8 v4, otherwise your proposal can only serve for the 102/8 which is been managed through the 2 phases of the soft landing policy.
The soft landing policy adopted a gradual landing with fair distribution, avoiding stocking at AFRINIC while people may need the numbers for their networks in our growing environment. Thus the “no limit on number of request”
In phase 2, at each request, you get a max of /22. You use it and apply again as you have to prove that all previous allocations have been used to 90%. Depending on the queue, you may get another /22, contiguous on non-contiguous.
In this phase, we are likely distributing a /11. If all goes in /22, we would have made 2,048 entries.
Some regions distributed their last /8 in max /22 or individual /22. 16,384 entries ?
If the objective is to help the routing table with aggregated allocation, would you be interested in working on a proposal for aggregated v4 transfer ?
>> CPM 184.108.40.206.3 already covers appears to cover what this proposal is all about - making this proposal >possibly not needed: "AFRINIC will always try to allocate contiguous address ranges, allowing the LIR to >minimise the number of route announcements it makes. However, it will not always be possible to >allocate a range contiguous with the LIR's previous allocation".
> CPM 220.127.116.11.3 unfortunately does not quite fulfill the requirements,
> as it leaves it to "chance" rather than procedurally ensuring it is
> going to happen.
No. It leaves it to availability, hostmaster appreciation and BCPs.
Hope this helps
> Since the staff assessment came in so close before the AFRINIC meeting
> and that there were comments regarding the possibility of renumbering,
> which is not the intention of this proposal.
> I will draft a new version to be published after the AFRINIC meeting to have:
> Clear statement in the proposal that this is only for new requests
> under the current Phase 1/2, not to enable a form of renumbering when
> getting a new IP range in order to avoid returning "dirty" space in
> favour of fresh clean one.
> Outline and describe a workflow within policy proposal text for
> AFRINIC staff's procedure.
> 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/uk
> e: d.hilario at laruscloudservice.net
> On 24 April 2017 at 12:52, SamiSalih <sami at ntc.gov.sd> wrote:
>> Dear AFRINIC PDWG Members,
>> We have received a new policy Proposal - "Route aggregation policy (AFPUB-2017-V4-002-DRAFT-01)"
>> From David Hilario (d.hilario at laruscloudservice.net)
>> Published in this link
>> Best Regards,
>> PDWG Co-chairs
>> RPD mailing list
>> RPD at afrinic.net
> RPD mailing list
> RPD at afrinic.net
More information about the RPD