Hi graham,<br><br>On Thursday, April 5, 2012, Graham Beneke  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi McTim<br>
<br>
On 27/03/2012 17:06, McTim wrote:<br>
> If you are doing Anycast and (only anycast or mostly anycast) for<br>
> non-critical infra, then you can't meet the 24%/50% requirements for<br>
> usage.  Furthermore, you can't get additional space because you won't<br>
> have used the majority of your previous allocation /assignment.<br>
><br>
> I think we do have an issue here, that being that our policies don't<br>
> allow folks to pursue a certain biz model/networking technology<br>
> without lying to our hostmasters.  We should fix this, or at least<br>
> have a formal policy proposal to do so, and talk about it using the<br>
> PDP.<br>
<br>
I think that the issue is a little broader than just anycast. There are<br>
a handful of scenarios where BGP engineering trumps the requirements for<br>
aggregated allocations.<br>
<br></blockquote><div><br></div><div>ACK. Not all of them rise to the level of having a special policy however.</div><br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I recently had a requirement for a separate /24 in order to implement<br>
GRX[1]. The prefix was to be publicly advertised but with a different<br>
policy to the existing blocks held by the LIR. The LIR did not qualify<br>
for this allocation due to the fact that they had recently been<br>
allocated a large block that was mostly unassigned.<br>
<br></blockquote><div><br></div><div>If I understand correctly, they could have used one of their allocated /24s for this, no?</div><div><br></div><div>Regards,</div><div><br></div><div>McTim</div><div><br></div><span></span><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The policy probably needs to be written to account for these<br>
requirements as well.<br>
<br>
[1] <a href="http://en.wikipedia.org/wiki/GPRS_Roaming_Exchange" target="_blank">http://en.wikipedia.org/wiki/GPRS_Roaming_Exchange</a><br>
<br>
--<br>
Graham Beneke<br>
</blockquote><br><br>-- <br>Cheers,<br><br>McTim<br>"A name indicates what we seek. An address indicates where it is. A route indicates how we get there."  Jon Postel<br>