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 PROTECTED] --------------------------------------------------------------------
