Let me turn this about.
If the "anycast" we are talking about is something that must be used
only by a few specialized services that are intended to optimize certain
network behaviors, then it is a hack. Maybe a useful hack, but still a
hack.
Conversely, if we are expecting to allow anycast for any distribution of
services, then it had better not be in the core routing system. Such
anycast "addresses" do not name a location. Hence they are inherently
non-aggregateable. They need to go through a mapping system of some
sort before we ask packet forwarding to handle them.
(Yes, there are architectures where routing does not require "where",
such as compact routing. But until we know how to make such systems
actually work I will not assert that even they can handle this sort of
anycast.)
Yours,
Joel
William Herrin wrote:
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
