Re: Auto-tunnel Rant

[Jared Mauch <jared@puck.nether.net>]

	My concern becomes that lets say streaming vendor X
becomes a customer of my global ip network because we support
native multicast and offer this as a service.  I am not opposed
to tunneling over equipment within my network that does not support
pim-sm, ssm, etc..  What I am opposed to is now the rest of
the non-multicast enabled internet turns my routers into
big tunneling machines to provide services across my public and
private peering links to other networks customers that do not
have multicast deployed.

	This means I may end up with hundreds of tunnels out
each peering link and increasing the burden on my routers.  This
means that I am not paid for this packet replication across the
private/public link and is now giving my customer 100x the bandwidth
for the cost of a single outgoing stream when it costs me
more than that to deliver it to other networks.  If the network
offers multicast delivering this traffic to them in an efficent
manner is acceptable.  While I wouldn't mind becoming the #1
provider, I don't want to provide tunneling across any
interprovider links that I have (that are not customers).

	Education in deploying SSM, and pim-sm multicast I think
is important in getting deployment rates higher than what they
are presently.

	These are my concerns.

	- Jared

On Fri, Mar 23, 2001 at 12:32:59PM +1000, George Michaelson wrote:
> 
> 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.
> 
> Obviously, 'private' tunnels are just that: but if a public framework
> which is acting as a 'find me a multicast' is going to tunnel over an
> enabled fabric, why not tear it open there?
> 
> I can't see what the multicast-centric answer is that makes this bad
> 
> 	the ISP is multicasting already: they can't object to the traffic
> 	class
> 
> 	its traffic efficient
> 	
> 	its actually a higher QoS than the user asked for since the mesh
> 	will have true local scopes
> 
> So its the layer or privacy violation thats a problem?
> 
> -George
> 

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.