Hi Bill,
I disagree with you there. Broadcast and Multicast are forms of non-determinisitic routing. Anycast and unicast are both forms of deterministic routing.
Interesting. That rumbling sound you here is Dino's keyboard... ;-) How do you figure it's non-deterministic? If you take a global snapshot at any given point in time, then for any given mcast packet sent by a given source, it's straightforward to compute the receivers.
Similarly for broadcast, it's trivial to see who should receive it.
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.
Except that we haven't figured out how to aggregate anycast, which from a routing perspective, makes it completely unique.
The same can't be said of multicast. Multicast has different semantics even if there's only one host in the group.
Say more please, I'm not following.
Still think I haven't proposed a radically different way to visualize the routing system?
Not yet, but I don't grok your perspective yet.
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.
Ok, but how would a map resolution change that? Is the key point here that whatever mapping function is used, the map result has a TTL and needs to be refreshed periodically? Or, the applications need to be able to trigger a refresh?
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.
Hmmm... not at all convinced. And I'm still not seeing how strategy A does anything significantly different other than giving us a chance to re-implement differently. You certainly don't want the ITR to be application/service aware, so it's simply forced into periodic retries. It seems like that is also going to have numerous downsides, such as broken anycast connections.
If it quacks like a duck...
It doesn't seem to quack at all. ;-) Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
