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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
