On Tue, May 03, 2005 at 06:59:45PM -0400, Paul G wrote:
----- Original Message ----- From: "Dean Anderson" <dean@av8.com> To: "Mark Boolootian" <booloo@ucsc.edu> Cc: <Nanog@merit.edu> Sent: Tuesday, May 03, 2005 6:33 PM Subject: Re: [dnsop] DNS Anycast revisited (fwd)
On Tue, 3 May 2005, Mark Boolootian wrote:
Note the nonsense about anycast being "completely coherent".
If you check, I think you'll see that he actually said "ultradns's anycast for .ORG is completely coherent".
There seems to be no possibility for anycast to be "completely coherent", so ultradns' anycast couldn't be "completely coherent" either. But Vixie mentions it to respond to comments by others about Ultradns' particularly pervasive use of anycast.
it may not be possible to make every service *consistent*, but it is perfectly possible to make it coherent (i'm talking about coherency of copies of a shared resource). i'm curious to see how you can substantiate this claim, since any backend which supports distributed transaction semantics will give you this. i can't comment on the veracity of paul's statement comme applique ultradns, since i'm not familiar with how they do things, but that doesn't change the fact that you've just made a statement which appears blatantly false to anyone with any distributed systems experience.
Coherency of DNS service is dependent upon the operational clue of the hostmaster in charge of such DNS systems and ensuring that each specific system is maintained to provide consistent service. (i.e. ensuring zones are properly updated on all servers, ensuring each system can answer the queries by enduser with proper answer) Anycast obviously opens a small set of can of caveats and notes while providing benefits. A properly configured and maintained anycast DNS setup can provide just as much coherency than using different unicast addresses, and ofcourse YMMV. And this has been done and is already being done by more ISPs to simplify their resolver DNS service. Honestly I've heard more success stories with anycast deployments than failure stories from the operational community thus far. Failure stories I've heard so far with respect to operational caveats of anycast were primarily brought up by those researching different and varying scenarios, many of which are very uncommon on the normal internet, but not primarily from those who actually operate a network and striving to provide service. Just as with anycast, people implementing per-packet load balancing should be aware of its caveats and implications before turning it on without reading the fine manual. Also note that most of popular setup of per-packet load balancing is done on a setup where multiple circuits are bound to the _same_ router, to provide added throughput. For most people, the extensive jitter provided by enabling PPLB accross different uplink POPs/ISPs is enough to fail the Return On Investment (ROI) of doing so. Before we even get to jitter, I would hate to see a sporadic sick-looking traceroute for all hops beyond the point where PPLB is enabled, due to PPLB being enabled between different IGP paths or uplink carriers. I myself would agree with the most of the anycast-supportive operators in that we should rather worry about tangible reality operational problems, not theories or lab-environment-generated proof of concepts. To really understand just what anycast is, I find this pdf introduction pretty useful for many folks who are new to the anycast topic and are looking to find some value in this long thread :) -- <http://www.nanog.org/mtg-0310/miller.html> -J (another person who deploys anycast for a few networks and have been very happy with the results it provided)
-p
--- paul galynin
-- James Jun Infrastructure and Technology Services TowardEX Technologies Office +1-617-459-4051 x179 | Mobile +1-978-394-2867 james@towardex.com | www.towardex.com