Dino,
-----Original Message-----
From: Dino Farinacci [mailto:dino@procket.com]
Sent: Thursday, March 22, 2001 11:10 PM
To: ggm@dstc.edu.au
Cc: finlayson@live.com; jared@puck.nether.net;
ssm-interest@external.cisco.com; mbone@ISI.EDU;
mboned@network-services.uoregon.edu
Subject: Re: Auto-tunnel Rant
>> There is probably a layering violation opr encapsulated traffic fubar
>> but I do want to ask, why its not possible for a multicast enabled
>> upstream to intercept a tunnel, and just *make* the endpoint terminate there
>> which should (in a global multicast) do the right thing anyway.
Because the number of tunnels cannot be bounded. Even if you configure
who is allowed to connect to you, as Radia indicated in her talk, you
still have to configure something, so it may as well be a list of tunnels.
I was arguing for static versus dynamic tunnels at MBONED.
It is extremely dangerous to abuse a router with unknown fanout. As I
indicated in MBONED, memory sizes, switching capacity, buffer memory k
capacity are all based on the speeds and feeds the router is designed for.
When replication is based on the physical interfaces, you can engineer a
box that actually does wire-speed multicast. Once you add tunnels
(unbounded or an unknown number) to the equation, you lose throughput in
a big way.
I also mentioned a very simple solution:
o PCs (windows) can already do multicast over their dial-up adaptors.
o Therefore IGMP messages can go to the dialed-up NAS device at the ISP.
o If you configure the NAS device to GRE tunnel to existing Juniper or
cisco boxes which reside in the multicast-capable cloud, you're done.
Upstream you can send IGMP request to the multicast enabled router. How about
a case in which the multicast enabled router is multiple hops away from the
NAS device and the routers in between do not support multicast. How is the traffic
going to flow downstream without creation of tunnels. Am I missing something here ?
I think the folks who allow tunnels to be created would be well aware that their
routers wouldn't be able to give wire speed performance.
Problem solved.
This is a lot different than asking a tier 2 or tier 3 ISP to run native
multicast. Of course, that is what we should encourage them to do but
the whole idea of doing tunnels at the edge of the network is to nudge
these access ISPs to see the light of multicast. So we have to proceed
one slow step at a time unfortunately.
The NAS boxes don't even have to do full multicast routing. Simply forward
IGMP reports received on an async line over the tunnel to the multicast
configured router in the backbone.
Doing this gets you 1-to-many source-tree based unbiqituous multicast.
AOL, Earthlink, and UUnet, are you listening?
Dino