Michael and all, Michael, this argument/debate has been hashed before on other forums, as you know because you were a participant. I see that your arguments favoring including "Anycast" in a "Best practices" document as part of a routing policy have not changed. However such arguments do not appear to yet again carry sufficient justification to be wise or even "Doable" in a practical sense. Hence leaving again such a policy as you espouse to be considered close to reasonable... Michael.Dillon@radianz.com wrote:
They are, but they are not even using the amount of redundancy available by DNS today (read: "as many name servers as fit into a minimum sized UDP packet full of glue"). So there is hardly an argument for doing anycast.
I think that it is dangerous for a policy to force people to follow an evolutionary path when they implement technology. If it is considered "best practice" for a DNS infrastructure to use anycast then we should not penalize them because they jump there from a more primitive state.
The route servers use TCP, which will not work over anycast (in the general case - consider load balancing, every other packet going to a different destination machine. No problem for UDP, big problem for TCP)
It is also dangerous for a policy to punish people for evolving their technology. If it is considered "best practice" to use anycast to publish critical infrastructure databases then people should be able to change their services to enable them to use UDP and anycast.
There are many ways in which a service could be adapted to anycast, even a session-based service. There are also non-anycast ways to solve this type of problem, such as peer-2-peer overlay networks, that could still benefit from having a well-known address range as a rendezvous point.
I really don't think that the policy needs to be a close fit for a certain technical implementation. Instead it needs to express the basic principle which is a non-technical principle. Then it can provide a checklist which deal with technical questions. In the future if the technical implementations change, it will be easier to add or change checklist items if there is a solid principle underlying the policy.
--Michael Dillon
Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801