<div dir="ltr">Jérome,<div><br></div><div>Thanks for participating.  Keep in mind that LIRs and end users can still apply through normal channels for IP space even if the purpose is Anycast.  The Anycast policies provide another channel to Anycast deployments that might otherwise be difficult to get through the other channels - but those existing channels are still available.</div><div><br></div><div>Cheers,</div><div>Adam</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div style="font-family:arial;font-size:small">--</div><div style="font-family:arial;font-size:small">Kili - Cloud for Africa: <a href="http://kili.io/" style="color:rgb(17,85,204)" target="_blank">kili.io</a><br></div><div style="font-family:arial;font-size:small">Musings:<a href="https://twitter.com/varud" style="color:rgb(17,85,204)" target="_blank"> twitter.com/varud</a></div><div style="font-family:arial;font-size:small">More Musings: <a href="http://varud.com" target="_blank">varud.com</a></div><div style="font-family:arial;font-size:small">About Adam: <a href="https://www.linkedin.com/in/adamcnelson" style="color:rgb(17,85,204)" target="_blank">www.linkedin.com/in/adamcnelson</a></div></div></div></div></div>
<br><div class="gmail_quote">On Sat, Feb 7, 2015 at 7:32 PM, Seun Ojedeji <span dir="ltr"><<a href="mailto:seun.ojedeji@gmail.com" target="_blank">seun.ojedeji@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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="HOEnZb"><div class="h5">
<div class="gmail_quote">On 7 Feb 2015 06:37, "Jérôme Fleury" <<a href="mailto:jerome@fleury.net" target="_blank">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" target="_blank">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>
</div></div><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>
<br></blockquote></div><br></div>