On Mon, Jun 15, 2015 at 12:34 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 15 Jun 2015, at 15:05, Dave Taht wrote:
I have been using anycast at a small scale on mesh networks, for dns, primarily. Works.
Many of us have been using anycast at Internet scale for DNS for a couple of decades. I would go further than "works" and perhaps say "necessary".
Oh, I agree. My point was that anycast is also potentially of use in smaller (corporate/mesh) networks, not just in DNS, but smtp as being discussed here. Web and other forms of proxy, also. Other cases, like gittorrent? I'm pretty sure it's a bad idea for ntp, and for non-fully mirrored file distribution services.
There were some wise words written in RFC 4786 about use of anycast with other protocols (well, I think they are wise, but then I wrote some of them):
a good read.
When a service is anycast between two or more nodes, the routing system makes the node selection decision on behalf of a client. Since it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction, it follows that the routing system's node selection decision ought to be stable for substantially longer than the expected transaction time, if the service is to be provided reliably.
Some services have very short transaction times, and may even be carried out using a single packet request and a single packet reply (e.g., DNS transactions over UDP transport). Other services involve far longer-lived transactions (e.g., bulk file downloads and audio- visual media streaming).
Services may be anycast within very predictable routing systems, which can remain stable for long periods of time (e.g., anycast within a well-managed and topologically-simple IGP, where node selection changes only occur as a response to node failures). Other deployments have far less predictable characteristics (see Section 4.4.7).
The stability of the routing system, together with the transaction time of the service, should be carefully compared when deciding whether a service is suitable for distribution using anycast. In some cases, for new protocols, it may be practical to split large transactions into an initialisation phase that is handled by anycast servers, and a sustained phase that is provided by non-anycast servers, perhaps chosen during the initialisation phase.
This document deliberately avoids prescribing rules as to which protocols or services are suitable for distribution by anycast; to attempt to do so would be presumptuous.
Operators should be aware that, especially for long running flows, there are potential failure modes using anycast that are more complex than a simple 'destination unreachable' failure using unicast.
Joe
-- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast