Subject: Re: a few comments on anycast mechanisms

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Mar 2003 15:46:16 +0100 (CET)

Sorry for the late response.

> True. It is also worth asking what is the proper granularity for storing
> the binding: per host, per flow, or something in between? Do we want to
> redirect all applications to the same unicast address, or should we
> allow different flows go to different unicast addresses?

In most cases it shouldn't matter since the routing system will be stable
enough so that multiple applications/connections/flows using the same
anycast destination will reach the same node.
But it makes sense thinking about this when there is routing changes e.g.
due to an anycast member failing and routing changes propagating.
During such a change does it make sense to allow the old, long-running
connections to continue trying to use the old anycast member while new
connections having the option to use the new anycast member?

> Maybe some basic L3 mechanisms, like the binding cache and RR, could be
> made available to applications and transport protocols as a "toolbox"
> via an appropriate service interface. Each "anycast user" could then use
> this toolbox in the most appropriate way.

I think this makes a lot of sense.
If anycast takes off we might even see application protocols which know a
priori that the destination is anycast, thus the app can invoke the anycast
binding protocol before setting up a transport connection.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Mar 2003 21:47:00 +0200

On Mon, 2003-03-10 at 16:46, Erik Nordmark wrote:
> > the binding: per host, per flow, or something in between?
> 

True. I had some vague thoughts about load balancing using something
like random selection rather than route metric but that is probably not
a valid use of anycast addressing.

> connections having the option to use the new anycast member?

Good point. The binding should probably be deleted if the unicast
address becomes unreachable. The best way to do is probably to just let
it time out fairly quickly after all transport connections have died
away. Changes in routing might also cause another anycast member to
become "closer" even if the cached binding is working fine. Does it make
sense to try and detect this? Doing so would require the ability to
store any old bindings that are still being used by transport
connections.

	MikaL