Re: Auto-tunnel Rant

[Toerless Eckert <eckert@cisco.com>]

On Thu, Mar 22, 2001 at 03:50:35PM +0000, Jon Crowcroft wrote:
> 
> i would ameliorate this comment - as edge nets have lans (e.g. dsl
> access via ether not usb) edge sites might well have multicast but be
> one hop removed from the core, but with no applciatio nlevel box
> between them and coree multicast capable nets.

Point not taken:

If the network administrator is able and willing to update his last-hop-router
to do not only multicast but also the tunnel-trick, why shouldn't he want
to deploy multicast throughout his network in the first place ? 

If necessary he would just do a tunnel-transit on his networks exit router
towards the Internet. That is just one tunnel, and we are doing this
for over 10 years now. If that model isn't working for someone, than why the
heck should something copletely new with maybe a bit less of configuration ???
(hey, you still have to get the tunnel box working somehow, even if you 
don't have to configure the remote tunnel endpoint adress!)

I think the tunnel solution that we don't have is one where the PC user
can easily take the initiative to get things going, but given that it would
be possible for an ISP to offer this today with some amount of initial
work, i wonder if we just don't have it because ISPs do not want to offer
this:

If let's say a Tier1 ISP wants to offer a multicast service down to Tier2/Tier3
customers that don't have contiguous IP Multicast connectivity because their
intermediate ISPs don't provide it: Why does that ISP not try to get
a dialin service provisioned based on some large-enough dial-in router
he puts someplace in his core with for example L2TP tunnels with Radius
authentication and appropriate access-lists managed from some web-server via
a CGI script that will create accounts for users whose IP source addresses are
verified to come from the ISPs downstream tiers, and which also passes some
windows install script down to the PC to configure the L2TP tunnel on the
windows PC.

Ok, so i haven't tried to sit down to check out all loose ends here, but
it seems to me as if this would all just be a question of packaging for
available components together with some level of web programming
(and maybe, uhm.. some bug fixing in components).

Sure, it's ugly in the eyes of the IETF snob, but it could be a 
"one-click solution for the user to get IP multicast", and certainly faster
to realize than solutions depending on development of completely new protocols.
Those completely new protocols in my view can just be an outgrowth, trying
to improve on such a solution (or similar ones) where necessary. Thus, if such
a solution isn't even tried to be deployed, then why would it be commercially
viable to improve on it ? Uglyness was never an important factor for commercial
success or failure in networking (yeah, we need fashion-networking, that's it!).

Cheers
	Toerless

P.S.: "ameliorate" - cool ;-))