Anycast provider for SMTP?

Joe Abley jabley at hopcount.ca
Mon Jun 15 19:34:19 UTC 2015


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



More information about the NANOG mailing list