On Mon, Jun 15, 2015 at 12:34 PM, Joe Abley <jab...@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
