Subject: RE: Auto-tunnel Rant

From: "Sundeep Singatwaria" <[email-masked]>
Date: Sat, 24 Mar 2001 05:46:07 -0800

Dino,

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]]
Sent: Thursday, March 22, 2001 11:10 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
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