On Sun, Apr 19, 2009 at 1:42 PM, Joel M. Halpern <[email protected]> wrote: > I suspect that our disagreement may relate to the definition of Anycast.
Hi Joel, I'm talking about anycast as described in RFCs 1546, 3068 and 3258. I'm not well familiar with RFC 2526 but it seems to describe some subnet-centric considerations which would be outside of the RRG's scope. On Sun, Apr 19, 2009 at 12:44 PM, Tony Li <[email protected]> wrote: >> Unicast is a special case of anycast in which there is only one >> destination endpoint. > > Nothing absurd about it. It's been said many times that unicast is a > special case of multicast and your observation is that anycast fits in the > middle of that hierarchy, since anycast is also a special case of multicast > where delivery is to only one receiver. Hi Tony, I disagree with you there. Broadcast and Multicast are forms of non-determinisitic routing. Anycast and unicast are both forms of deterministic routing. There's a wide gulf between deterministic and non-deterministic routing. What works efficiently for one just flat doesn't work well for the other. I claim that on the deterministic side, the difference between anycast and its unicast subset is sufficiently trivial that a well conceived protocol will neither need nor want to treat the two cases differently. When I say, "Unicast is a case of anycast in which there is only one destination endpoint," I really mean it. Unicast doesn't exist. It's just a convenience label for Anycast in which only one destination endpoint is currently active, and that's precisely how the routing system treats it. The same can't be said of multicast. Multicast has different semantics even if there's only one host in the group. Still think I haven't proposed a radically different way to visualize the routing system? > What you're proposing is certainly reasonable. The gist is that you don't > end up with a global route per service, and that you use the mapping > function to convert anycast into a unicast service. > > Some folks do that already today (e.g., http://www.pool.ntp.org) with DNS as > the mapping function. If using DNS that way worked, we could all go home. Unfortunately, what happens is that the ntp server looks up the name to address binding once when the machine boots and never reconsiders it during the year and a half the server is running, even after queries to the server's IP address stop returning data. This is typical. Though their operational cycle is usually limited to days or weeks, web browsers do the same thing. (DNS pinning) The strategy B systems essentially replace DNS with a system where the timeouts are mandatory. The strategy A systems add an additional layer of indirection between DNS and routing so that the DNS is free to continue its trend toward static bindings. In both approaches we acknowledge that decades of practice have rendered the existing forward DNS irretrievable as a source of dynamic binding to the routing elements. > That's certainly fine and has no impact on routing > whatsoever, obviously. We just don't call it anycast. If it quacks like a duck... Regards, Bill -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
