nanog mailing list archives

Re: Anycast provider for SMTP?


From: "Joe Abley" <jabley () hopcount ca>
Date: Mon, 15 Jun 2015 15:34:19 -0400

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".

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):

   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


Current thread: