On 16 May 2004, at 18:22, Dean Anderson wrote:
... and that further, the root servers
operators have widely adopted a dubious anycast replication model that
won't work well with TCP and load-balancing BGP configurations that are
gaining the interest of ISPs. Such load balancing configurations will
send
packets over different paths to the same IP address. This is
significant
because an Anycast server is two (or more) physical servers with the
same
IP address, but with different paths to each server to distribute load.
This is not the case with F (I can't speak for other operators
deploying Internet-scope anycast services). The different paths are
made available in order to provide redundancy and diversity, and
absolutely not to share load.
If you have an example of someone enabling multi-path BGP hacks in
order to allow selection of more than one path, and specifically one
who has ever selected two or more paths to different nodes of F (that
is, paths to 192.5.5.0/24) I would be very interested to hear about it.
Feedback and measurement data we have seen has not yet revealed an
occurrence of this, and conversations so far with operators does not
suggest there is much risk that we will. Your data will be interesting
to hear, however, if you can pass it on.
Anycast will not cause problems with single packet UDP DNS queries, but
will have problems with load balanced, TCP connections, especially
where
BGP load balancing configurations would be likely to send packets over
different paths (and thus to different anycast servers) within a very
short period of time, perhaps even sequential packets could sent over
different paths.
There is a risk that during a routing transition, when one path to
192.5.5.0/24 is promoted over another due to a link failure or some
other policy or topology change, a TCP transaction to an anycast node
will fail. This is documented in both ISC technical notes written to
describe what we are doing with F.
Our experience is that such route churn is of such a low frequency that
the effect on extremely transient TCP DNS transactions is statistically
negligible (and quite possibly indistinguishable from timeouts during
reconvergence events to non-anycast servers). In addition, before the
frequency of the route churn became sufficiently high to cause a
problem, it would be well and truly damped to death by anybody running
with common BGP damping parameters and the inability to talk to the few
root servers which have anycast instances would be the last of your
problems.
There's a specific section in ISC-TN-2004-1 which describes the
applicability of cluster-scope anycast to protocols with longer-lived
transaction times than DNS, and which warns implementers to test
thoroughly since the opportunities for flows switching between hosts is
greater there than in the global/BGP case. This is not the case you
were talking about, but I mention it anyway for completeness.
Just thought I'd add some operational perspective to this particular
point. I have no useful comments to make on the rest of your message,
since I am neither a BIND developer nor a DNS/DNSSEC architect.
Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf