<div dir="ltr">I'm writing this up for the meeting right now and have noted:<div><br></div><div>1. There are 2 replies in support of the proposal.</div><div>2. There hasn't been a new draft to address some of the concerns brought up.  Is one forthcoming?</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, Nov 8, 2014 at 9:28 AM, Frank Habicht <span dir="ltr"><<a href="mailto:geier@geier.ne.tz" target="_blank">geier@geier.ne.tz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
sorry to come pretty late with this, but maybe better now than never (or<br>
later)...<br>
<br>
There are 2 ways for anycast deployments:<br>
1. announce and see what happens<br>
2. announce and at some locations limit the scope of the announcements to<br>
only directly peering networks (with the well-known NO_EXPORT community).<br>
<br>
By using the 2nd method, some anycast operators differentiate between their<br>
"global nodes" and "local nodes".<br>
see also: <a href="http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt" target="_blank">http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt</a><br>
<br>
When 2 networks AS1 and AS2 are both connected (and preferring) local<br>
nodes, they will carry the anycast prefix with NO_EXPORT in their network.<br>
<br>
A common customer AS3 that is multihomed to both AS1 and AS2 and receiving<br>
"full BGP table" from them, will not receive the anycast prefix. If AS3<br>
doesn't use a default, they will not reach the anycast service.<br>
<br>
The original:<br>
<a href="http://www.merit.edu/mail.archives/nanog/2005-10/msg01226.html" target="_blank">http://www.merit.edu/mail.archives/nanog/2005-10/msg01226.html</a><br>
Fix by RIPE NCC ("K"):<br>
<a href="http://meetings.ripe.net/ripe-52/presentations/ripe52-dns-kroot-anycast.pdf" target="_blank">http://meetings.ripe.net/ripe-52/presentations/ripe52-dns-kroot-anycast.pdf</a><br>
<br>
To avoid this, anycast operators have added an announcement for the<br>
covering /23 from the global nodes. This will always be announced without<br>
NO_EXPORT community, and will thus be visible and reachable to everyone.<br>
<br>
<br>
I think the same can be expected of anycast operators using this proposed<br>
policy. Therefore I suggest we give them the option to request and receive<br>
either /24 or /23 - their choice.<br>
In IPv6 I also suggest to optionally assign a bigger block than /48.<br>
A /47 would suffice but I guess we don't want to split the nibble into bits ;-)<br>
<br>
So I propose to replace every instance of "/24" with "/23 or /24" and<br>
replace every instance of "/48" with "/44 or /48"  - or maybe "/44 up to /48".<br>
<br>
Meaning anycast operators can choose which one they request, and they can<br>
get these according to their request.<br>
<br>
Sorry for bringing this up that late.<br>
<span class="HOEnZb"><font color="#888888"><br>
Frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 11/4/2014 12:06 PM, Mark Elkins wrote:<br>
> I'm happy to make changes along the lines of what Nishal suggested...<br>
> that is:<br>
><br>
> Replace:<br>
> These resources must<br>
> be used for the sole purpose of anycasting web or authoritative DNS<br>
> servers as described in BCP126/RFC 4786<br>
> (<a href="http://www.ietf.org/rfc/rfc4786.txt" target="_blank">http://www.ietf.org/rfc/rfc4786.txt</a>) or for GPRS Roaming Exchange.<br>
><br>
> With:<br>
> These resources must be used for the sole purposes of providing anycast<br>
> services.<br>
><br>
><br>
> I have been trying to have Ernest update the website - he may have<br>
> malaria again.<br>
><br>
> On Mon, 2014-10-20 at 21:45 +0200, Mark Elkins wrote:<br>
>> On Mon, 2014-10-20 at 22:11 +0300, Ernest wrote:<br>
>>>>> 3) Proposal<br>
>>>>> AFPUB-2012-V4-001 is modified from the original version to the<br>
>>>>> following version:<br>
>>>>> ...........................................................<br>
>>>>> 1. Summary of the problem being addressed by the policy proposal<br>
>>>>> This proposal allows an organization to receive an IPv4/IPv6<br>
>>>>> allocation or assignment and an AS Number purely for anycast or GPRS<br>
>>>>> Roaming Exchange (GRX) usage.<br>
>>>>><br>
>>>>> 2. Summary of how this proposal addresses the problem<br>
>>>>> This proposal allows the use of:<br>
>>>>> a. One (1) /24 of IPv4 for anycast services from a PA allocation of<br>
>>>>> an LIR or direct end-user assignment.<br>
>>>>> b. One /48 of IPv6 for anycast services from an IPv6 LIR allocation<br>
>>>>> or direct end-user assignment.<br>
>>>>> c. An AS Number for anycast purposes.<br>
>>>><br>
>>>> let me explain the second request. the policy, as is worded, is<br>
>>>> potentially ambiguous.  hostmasters _may_ be tempted to say that,<br>
>>>> as per policy, they have satisfied the requirement to allocate<br>
>>>> one, and only one prefix for anycast purposes, to an<br>
>>>> organisation, when, a forward thinking organisation might wish to<br>
>>>> have more than one anycast cloud.  while having one prefix, is<br>
>>>> obviously better than zero, it would be _wrong_ to limit this to<br>
>>>> just one anycast cloud.<br>
>>>><br>
>>>> so, while the current policy doesn't _disallow_ more than a<br>
>>>> single allocation, it's not clear (i think) to the hostmaster<br>
>>>> team, that more than one allocation might be allowed. (i guess,<br>
>>>> the other way of looking at this, is that there is no requirement<br>
>>>> to _change_ policy if, there is acknowledgement from the<br>
>>>> hostmaster team that they understand this - perhaps we can get<br>
>>>> them to comment here.  the task of determining valid usage will<br>
>>>> still be up to the hostmasters of course)<br>
>>><br>
>>> As there are no explicitly indicated limitations in the current<br>
>>> policy, we implemented this such that an organization can request<br>
>>> and be granted one /24 *per request*. The frequency of the anycast<br>
>>> requests however (from the same organization) is unlimited per our<br>
>>> interpretation.<br>
>>><br>
>>> While reading through the new proposal - we also interpret it such<br>
>>> that one /24 v4, one /48 v6 prefix and one ASN will be assigned with<br>
>>> *each* anycast request from the same organization, and there is no<br>
>>> limit on the number of times the same org can request such resources.<br>
>><br>
>> Which should mean there is nothing wrong with the wording!<br>
>><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>
><br>
><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>
<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>
</div></div></blockquote></div><br></div>