On Mon, 2003-03-10 at 16:46, Erik Nordmark wrote:
> > True. It is also worth asking what is the proper granularity for storing
> > the binding: per host, per flow, or something in between?
>
> 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.
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.
> 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?
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
