<p dir="ltr">Hi Jerome,</p>
<p dir="ltr">There is a related policy awaiting board ratification which you may want to look at and then propose an update through following the normal PDP (policy development process)</p>
<p dir="ltr"><a href="http://www.afrinic.net/en/community/policy-development/policy-proposals/1275-afpub-2014-gen-003-draft-04">http://www.afrinic.net/en/community/policy-development/policy-proposals/1275-afpub-2014-gen-003-draft-04</a></p>
<p dir="ltr">Cheers!</p>
<p dir="ltr">sent from Google nexus 4<br>
kindly excuse brevity and typos.</p>
<div class="gmail_quote">On 7 Feb 2015 06:37, "Jérôme Fleury" <<a href="mailto:jerome@fleury.net">jerome@fleury.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
I'm new to this mailing-list, so please pardon any misstep.<br>
<br>
While I have been searching discussions on this matter in this<br>
mailing-list, I have been unable to find an adequate answer.<br>
<br>
I'd like to discuss the relevance of AFPUB-2012-V4-001<br>
(<a href="http://www.afrinic.net/en/library/policies/701-anycast-assignments-in-the-afrinic-region-" target="_blank">http://www.afrinic.net/en/library/policies/701-anycast-assignments-in-the-afrinic-region-</a>).<br>
In summary, it prevents companies operating anycast CDN (like mine)<br>
from requesting anycast allocations to Afrinic because allowing only a<br>
/24 per allocation is insufficient to meet our current expansion<br>
needs.<br>
Our service currently runs fully on anycast, and we use 4 times more<br>
anycast addresses than unicast ones. We could like to expand our<br>
service in Africa.<br>
<br>
<br>
While having policies to discuss anycast is very much needed and<br>
welcome, I don't agree with the following:<br>
<br>
"In addition, current anycast practice announces an entire /24.<br>
AFRINIC current IPv4 policy states that the minimum allocation size on<br>
initial allocation is a /22. To use a /22 for anycast when you<br>
potentially are only using a few addresses in the block is wasteful."<br>
<br>
- While it's true that a lot of anycast prefixes seen in the global<br>
routing table are /24s (for traffic-engineering purpose), this should<br>
not be considered as a basis for this policy. I can certify that a lot<br>
of anycast prefixes are more than /24s; for example, we advertise<br>
/20s.<br>
<br>
- Announcing "bigger than a /24 is wasteful" is not true in our case.<br>
When we advertise a /20 for anycast purpose, we make sure that each<br>
and every one of the addresses are used for production traffic. When<br>
you serve millions of websites on your infrastructure, I can assure<br>
you that you don't waste addresses.<br>
<br>
After this discussion from 2007<br>
<a href="https://lists.afrinic.net/pipermail/rpd/2007/000354.html" target="_blank">https://lists.afrinic.net/pipermail/rpd/2007/000354.html</a>, there hasn't<br>
been much further discussion since. The anycast world has changed a<br>
lot in the meantime and in my opinion this policy should be amended to<br>
reflect today's reality of anycast addressing.<br>
<br>
I welcome thoughts and comments.<br>
_______________________________________________<br>
rpd mailing list<br>
<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>
</blockquote></div>