On Thu, Apr 9, 2009 at 10:22 AM, Joel M. Halpern <[email protected]> wrote: > William Herrin wrote: >> On Wed, Apr 8, 2009 at 10:56 PM, Joel M. Halpern <[email protected]> >> wrote: >>> The last analysis I saw is that anycast is in some sense a fiction. >> So you see an abnormality here, not a pattern in the evolution of routing? > What I see is a hack that would be ineffective in a system that actually > drove serious aggregation.
Joel, Okay, well, I see an evolutionary pattern in the routing architecture. I see a set of core services, like map resolution, where causing the first packet to reach any one of the many eligible and available respondents represents a significant efficiency gain for the overall Internet architecture versus a unicast timeout and retry cycle which continues until an available respondent is found. And I see more of it in our future. Frankly, I'm surprised no one has published an RFC describing an "anycast DNS resolver address" that can be statically configured in TCP/IP network stacks with the expectation that it'll reach the nearest operational DNS resovler. It would greatly simplify client configuration and would make maintenance downtime on the primary resolver much less disruptive. If its practical for anycast to be an integral part of unicast routing then it's likely to be suboptimal or even destructive to architect it as a peer to unicast routing. I also foresee a combined anycast/multicast address where a host sends a multicast packet to a single unknown respondent on the LAN, the local router keeps track of whether there is a respondent on the LAN, and if there isn't then the router takes the multicast packet and forwards it unicast to the nearest respondent that has introduced a route into the system. With the combined address, a host could perform a map lookup to an architecurally defined destination (zero configuration) by emitting a single packet on the LAN with the expectation that barring packet loss it'll reach a system capable of fulfilling the map lookup. A minor tweak would solve the noise on the LAN by having the host subsequently use the respondent's unicast IP address until there's a timeout. But I 'spose that's an ineffective hack too, yes? Regards, Bill Herrin -- 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
