On 13 Apr 2005, at 21:06, Rob Austein wrote:
So the criteria here are:
a) Short-lived session (typically two packet UDP exchange, but some argue that even a fast 7 packet TCP exchange is ok, so long as it's fast);
For the record, I know of people who have distributed video streaming services and ftp servers using anycast, with attendant long-held, million-packet TCP sessions, and who have done so very successfully. POP3 and SMTP services have been anycast in real, live ISPs' production networks for a long time (I know of an example that dates back at least 10 years).
As I noted in my reply to Bob, the nature of the protocol is not the final discriminator here -- it's the protocol *and* the network *and* the distribution of nodes, and a comprehensive treatment (such as might be expected if MUST NOTs are showing up in the text) is not going to fit in this draft.
Another approach is to write a separate document that relaxes the rules and
describes the issues in more depth than we might want to add here. This
would keep the current limits in the address architecture (going forward to
Draft standard) and have the new document start at Proposed standard.
Such a draft already exists in the form of draft-jabley-v6-anycast-clarify, which tersely defers most commentary to the grow draft. If there is a use for that draft, then perhaps it lies in being able to include a normative reference to the grow draft without holding the v6 architecture document too long in the RFC editor's queue (waiting for the grow document to be WGLCd and published).
[...] Anycast is mostly an IP issue, not an IPv6 or IPv4 issue.
That is my view, too, which is why I keep trying to illustrate this v6 discussion with examples of v4 anycast deployment.
Joe
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
