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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf