[address-policy-wg] PI for Not-DNS Anycast.

Hi,

michael.dillon at bt.com wrote:
>> some people already raised their voice about "other anycast 
>> services, not being DNS" (see mailinglist archives).
>> The problem is, noone came up with some concrete idea what 
>> that might be. You obviously don't have an idea about some 
>> concrete example either.
> 
> I believe that I did give such an example when we discussed this on or
> about the 10th of May this year. IPv4 Anycast works with any application

my apologies if i missed it.

> and any protocol which uses a short-lived connection to serve up
> information from a relatively static database which has been replicated
> to many locations. DNS is an example of such an application but not the
> only possibility. LDAP services could be anycast. Plain old HTTP sites
                                   ^^^^^
> serving static data over short-lived connections can also be anycast.
                                                    ^^^
> People can design protocols to be anycast-friendly. For instance a
          ^^^
> long-lived file transfer where missing or delayed packets result in the
> client sending a NACK, could be done using UDP so that any server in the
> anycast group would respond to the NACK with the correct data packet.
> And the protocol would continue to send at least a few packets after not
> receiving an ACK.
> 
> Just because some people don't have the imagination to see the
> possibilities does not mean that RIPE should make restrictive policies
> that limit innovation in Europe.

I still don't see a point for that. Do you have an implementation? 
(besides IRC :-)
You can develop much, but as long as it's not there, why the need for a 
policy on that? Do we really want a very very vague policy?
Last time i checked, i was told that RIPE NCC doesn't like vague policies.

Again, do you have a real world example? Why isn't the policy about 
experimental assignments, which is there for IPv4 and IPv6 not enough to 
get the development started?

>> ==> Currently it doesn't look like there is a need to discuss 
>> this as long as noone needs it because all this in only 
>> theoretically - is it?.
> 
> We make policy BEFORE handing out resources. Therefore, the use of the

..soo in your eyes, the ULA-C policy proposal was timed right? :-)

> resources has to be somewhat theoretical at the time the policy is made.
> The current IPv4 anycast policy requires applicants to wast over 99% of
> their allocation at a time when we are dangerously close to IPv4
> exhaustion. This is negligent and we need to correct this. IPv4 anycast
> allocations should be tied to having a distributed infrastructure in
> many different locations, not to the use of a specific protocol or
> specific port number. We should encourage organizations who have IPv4
> anycast allocations to offer IPv4 anycast hosting services using their
> anycast topology. That way we can reduce the waste level, possibly down
> to zero.

OK, i think i need another .. say two /23s and /32s for Anycast usage, i 
MIGHT deploy it someday in the future, PROBABLY i will anycast my LDAP 
servers, EVENTUALLY even my HTTP servers and oh yes i do run an IRC 
Server... and i have some file-transfer protocol in the back of my head 
that implements anycast, i will DEVELOP that soon, but i need anycast 
space now so i can test it, i'm not happy with an experimental 
assignment because i will sell the services right away during my tests!

... sounds ridiculous to me, but probably i'm not in a good mood today 
since it's Microsoft Patchday.

==> If someone puts up a policy proposal, i'm happy to think about it 
again. Please don't misunderstand me, but i'm not fond of long 
theoratical discussions without much outcome.

Someone who thinks we need an Any-Anycast policy, please make up a 
draft! Get the process going so that we will have a policy in place 
soon. I completely share the opinion that innovation shouldn't be 
hindered just because i don't see the point here.

-- 
========================================================================
= Sascha Lenz                  SLZ-RIPE          slz at baycix.de         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================