[rpd] AnyCast assignments - Update

Sat Nov 8 06:28:35 UTC 2014

Hi,

sorry to come pretty late with this, but maybe better now than never (or
later)...

There are 2 ways for anycast deployments:
1. announce and see what happens
2. announce and at some locations limit the scope of the announcements to
only directly peering networks (with the well-known NO_EXPORT community).

By using the 2nd method, some anycast operators differentiate between their
"global nodes" and "local nodes".
see also: http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt

When 2 networks AS1 and AS2 are both connected (and preferring) local
nodes, they will carry the anycast prefix with NO_EXPORT in their network.

A common customer AS3 that is multihomed to both AS1 and AS2 and receiving
"full BGP table" from them, will not receive the anycast prefix. If AS3
doesn't use a default, they will not reach the anycast service.

The original:
http://www.merit.edu/mail.archives/nanog/2005-10/msg01226.html
Fix by RIPE NCC ("K"):
http://meetings.ripe.net/ripe-52/presentations/ripe52-dns-kroot-anycast.pdf

To avoid this, anycast operators have added an announcement for the
covering /23 from the global nodes. This will always be announced without
NO_EXPORT community, and will thus be visible and reachable to everyone.

I think the same can be expected of anycast operators using this proposed
policy. Therefore I suggest we give them the option to request and receive
either /24 or /23 - their choice.
In IPv6 I also suggest to optionally assign a bigger block than /48.
A /47 would suffice but I guess we don't want to split the nibble into bits ;-)

So I propose to replace every instance of "/24" with "/23 or /24" and
replace every instance of "/48" with "/44 or /48"  - or maybe "/44 up to /48".

Meaning anycast operators can choose which one they request, and they can
get these according to their request.

Sorry for bringing this up that late.

Frank

On 11/4/2014 12:06 PM, Mark Elkins wrote:
> I'm happy to make changes along the lines of what Nishal suggested...
> that is:
> 
> Replace:
> These resources must
> be used for the sole purpose of anycasting web or authoritative DNS
> servers as described in BCP126/RFC 4786
> (http://www.ietf.org/rfc/rfc4786.txt) or for GPRS Roaming Exchange.
> 
> With:
> These resources must be used for the sole purposes of providing anycast
> services.
> 
> 
> I have been trying to have Ernest update the website - he may have
> malaria again.
> 
> On Mon, 2014-10-20 at 21:45 +0200, Mark Elkins wrote:
>> On Mon, 2014-10-20 at 22:11 +0300, Ernest wrote:
>>>>> 3) Proposal
>>>>> AFPUB-2012-V4-001 is modified from the original version to the
>>>>> following version:
>>>>> ...........................................................
>>>>> 1. Summary of the problem being addressed by the policy proposal
>>>>> This proposal allows an organization to receive an IPv4/IPv6
>>>>> allocation or assignment and an AS Number purely for anycast or GPRS
>>>>> Roaming Exchange (GRX) usage.
>>>>>
>>>>> 2. Summary of how this proposal addresses the problem
>>>>> This proposal allows the use of:
>>>>> a. One (1) /24 of IPv4 for anycast services from a PA allocation of
>>>>> an LIR or direct end-user assignment.
>>>>> b. One /48 of IPv6 for anycast services from an IPv6 LIR allocation
>>>>> or direct end-user assignment.
>>>>> c. An AS Number for anycast purposes.
>>>>
>>>> let me explain the second request. the policy, as is worded, is
>>>> potentially ambiguous.  hostmasters _may_ be tempted to say that,
>>>> as per policy, they have satisfied the requirement to allocate
>>>> one, and only one prefix for anycast purposes, to an
>>>> organisation, when, a forward thinking organisation might wish to
>>>> have more than one anycast cloud.  while having one prefix, is
>>>> obviously better than zero, it would be _wrong_ to limit this to
>>>> just one anycast cloud.
>>>>
>>>> so, while the current policy doesn't _disallow_ more than a
>>>> single allocation, it's not clear (i think) to the hostmaster
>>>> team, that more than one allocation might be allowed. (i guess,
>>>> the other way of looking at this, is that there is no requirement
>>>> to _change_ policy if, there is acknowledgement from the
>>>> hostmaster team that they understand this - perhaps we can get
>>>> them to comment here.  the task of determining valid usage will
>>>> still be up to the hostmasters of course)
>>>
>>> As there are no explicitly indicated limitations in the current
>>> policy, we implemented this such that an organization can request
>>> and be granted one /24 *per request*. The frequency of the anycast
>>> requests however (from the same organization) is unlimited per our
>>> interpretation.
>>>
>>> While reading through the new proposal - we also interpret it such
>>> that one /24 v4, one /48 v6 prefix and one ASN will be assigned with
>>> *each* anycast request from the same organization, and there is no
>>> limit on the number of times the same org can request such resources.
>>
>> Which should mean there is nothing wrong with the wording!
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> 
> 
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> 