Hi Bill,
I have this mental picture of the NFAs and DFAs (finite automata) used to process regular grammars from the formal languages class I took in college. All NFA's can be translated to DFAs but the translation explosively grows the automata. Seems to me like NFAs are decent metaphors for broadcast and multicast while DFAs are metaphors for anycast and unicast. And I think its notable that anycast groups with unicast (it's DFA-like) instead of grouping with multicast.
Ok, I remember these. Still have the textbook right here. ;-)
Except that we haven't figured out how to aggregate anycast, which from a routing perspective, makes it completely unique.What do you mean? Anycast aggregates the same way as unicast: whenever the endpoints physically group together, they aggregate. At a practical level, that's rarely useful for anycast... But then at a practical level aggregating unicast that way (or failing to) is the source of our current grief.
Well, the problem with aggregating anycast is that it ends up with one route per service. In a world of highly differentiated services, the sheer number of services could be explosive. And you can only aggregate them if they are numbered appropriately and are topologically correlated. How often is that going to happen with anycast?
To be fair, we do get substantial aggregation up to the site level with unicast, it's above that level that things get iffy.
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.With anycast, the packet's next hop is always in exactly one direction, precisely the same as with unicast. And knowledge about what that next hop should be propagates precisely the same way. With multicast, the packet is replicated in all currently valid directions with complex subscription/desubscription overhead that has to be maintained even if there's only one receiver in the group.
Having watched the development of PIM, BGP, OSPF, ARP, HSRP, VRRP, and IS-IS, I'm having a hard time saying that the "complex subscription/desubscription" overhead for multicast is all that much worse than what we do for unicast.
As for the forwarding plane, the differences are NOT that large. Ok, yes, there is an order of magnitude more complexity in doing the packet replication, but it becomes quite clear that with one receiver it does devolve nicely into an effective unicast. No one would implement unicast that way, of course, but that's an efficiency issue, not a conceptual one.
Even if multicast's differentiation is the replication in the data plane, I'm not sure I see how that becomes non-deterministic. I see no references to an oracle. The right things always seems to happen with total determinism.
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?You'd put the map resolution outside the app developer's scope, either in the network (as proposed by strategy A) or in the system-level host software (as proposed by strategy B). Unprivileged applications simply wouldn't be able to diddle with addresses at the routing layer. With a guaranteed maximum time that a given map remains valid and no application-level access to the routing element, the protocol and weigh in favor of renumbering for aggregation instead of rerouting for multiple connections. But this is rather off on a tangent from anycast and its rather identical nature to unicast.
Seems like useful implementation strategies to me. And it leads me again to the conclusion that it's again not something that's happening within the routing subsystem.
Tony
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.