This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] PI for Not-DNS Anycast.
- Previous message (by thread): [address-policy-wg] PI for Not-DNS Anycast.
- Next message (by thread): [address-policy-wg] PI for Not-DNS Anycast.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
michael.dillon at bt.com
michael.dillon at bt.com
Wed Jun 13 11:26:09 CEST 2007
> 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 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. > ==> 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 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. --Michael Dillon
- Previous message (by thread): [address-policy-wg] PI for Not-DNS Anycast.
- Next message (by thread): [address-policy-wg] PI for Not-DNS Anycast.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]