Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

[Fred Baker]

To be honest, I can't imagine a routing protocol that does anything 
similar to prefix aggregation carrying tags around for individual /32 
or /128 addresses. And while it is conceptually possible to do 
per-packet load balancing, very few routers are actually configured 
that way, because the end station guys complain about the extra packet 
copy load it introduces in TCP. Generally speaking, the source and 
destination addresses in a packet are hashed, the hash reduced using a 
modulus or similar function, and the result used as an index into the 
next hop list in the multipath route. This is done explicitly to limit 
the TCP packet copy issues by reducing the amount of reordering that 
happens in the network. It's legal, but "legal" doesn't make it a good 
thing.

The real issue is temporal. "What is the probability that routing could 
change during the time this address is in use".

Note that none of this about packets going from the anycast server to 
the session originator, which would be the concern that would lead one 
to look hard at packets that had an anycast address as a source. It has 
to do with packets going from the session originator to two different 
nodes offering the anycast service - routing to the anycast address, 
routing changing, choice of server by the network...

What you're cautioning against is the use of an anycast service by an 
originator, not the use of an anycast address as a source.

Do you have any concerns that relate to using an anycast address as the 
*source*?

On Apr 6, 2005, at 4:50 PM, Mark Andrews wrote:
        The prohibition was put in as we didn't know how to do anycast
        correctly for all cases.  How to do the route injection etc.
        For single packet transactions (one packet each way) as long as
        you don't source the first packet from a anycast address there
        is no problems with sending the reply from the anycast address.
        DNS/UDP falls into this space.
        For sessions bigger than this there are going to be issues that
        need to be examined and maybe addressed.
        e.g.
        * per pack load balancing which causes traffic to go to different
        anycast nodes.
        * routing table changes which change the anycast node.
        DNS/TCP w/ anycast assumes the first of these to be almost
        non-exisitant and the second to be a non-issue as the
        sessions have short life times.  Again this is with the
        server on the anycast address and the client on the unicast
        address.
        Note the important thing here is that the session (not
        packet) originated from a unicast address.  Replying with
        unicast source address is reasonable in some/all cirumstances.
        I suspect that the one of the bigger issues will be PPLB
        which may require routing protocols to be able to tag
        prefixes as containing anycast addresses to turn off
        non-parrallel path PPLB. This tag may or may not need to
        be exported across AS boundaries.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------