[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auto-tunnel Rant
2cents:
IMHO, the auto-tunnels should be taken care of by a CDN (or layer 4-7
replicator) rather than done automatically by routers.
Most CDN folks claim they want to "avoid the congestion in the core"
Sounds nice.
Problem is that folks on the edge may not want that information at
the same time its being offered.
The trick is to multicast it to the edge, to be cached for delivery
on demand to the user.
CDN is a tool. Multicast is a tool. Pick the right tool for the
job.
^ On Thu, Mar 22, 2001 at 12:23:26PM -0500, Marshall Eubanks wrote:
^ >
^ >
^ > Bill Nickless wrote:
^ > >
^ > > -----BEGIN PGP SIGNED MESSAGE-----
^ > >
^ > > At 01:51 AM 3/22/2001 -0500, Marshall Eubanks wrote:
^ > > > I think that the promotion of auto-tunnels for the purpose of
^ > > >furthering multicast deployment is WRONG. It is, IMHO, NOT productive t
o
^ > > >expend time and effort in this direction. It diverts resources from the
^ > > >real goal, which is multicast deployment. If deployed, it will cause
^ > > >problems that will be inevitably be blamed on multicast.
^ > >
^ > > As I've been playing Multicast Bully, one of the hardest things I've had
to
^ > > do is to get people who think they've got a working multicast deployment
to
^ > > fix it. (Fix it means MSDP/PIM-SM/MBGP). These are usually people who
^ > > have a DVMRP tunnel off to a service provider. I've also seen situation
s
^ > > where an organization has their service provider run a PIM RP.
^ > >
^ > > Adding another set of non-BCP multicast deployment options using these
^ > > auto-tunneling procedures will inevitably increase the problem space. I
'm
^ > > already having to ask people why their MSDP SA advertisements are coming
^ > > from an RP in an unrelated university in another state (probably because
of
^ > > old dense mode connections).
^ > >
^ > > If we need tunnels to get around broken service providers, let's do them
^ > > explicitly so that we know where they are and can take them out when clu
es
^ > > get appropriately spread out.
^ >
^ > Bill;
^ >
^ > Keep up the good work. I appreciate it.
^ >
^ > Just to clear things up,
^ > I have nothing against tunnels per se - use, have 'em, will sell you one.
^ > Its putting a lot of effort into auto-tunnels that I do not regard as a go
od idea.
^
^
^ I must also agree. I like the idea of the tunnels in
^ theory but in practice I have a lot of concerns in running a network
^ that supports multicast. We have native multicast (almost) everywhere
^ and available to customers. I do not like the idea of my routers
^ doing auto tunnels across my customers network to their downstream
^ customer. They need to be educated and become more savvy in their
^ operations.
^
^ I think that instead of putting effort into auto-tunnels that
^ more time should be spent working on educating the community. The problem
^ is that people associate multicast with dvmrp and mbone which is
^ problematic. They remember having a 10M dvmrp link and don't understand
^ that pim sm+msdp+ssm don't have that dramatic bandiwdth downside.
^
^ - Jared
^
^ --
^ Jared Mauch | pgp key available via finger from jared@puck.nether.net
^ clue++; | http://puck.nether.net/~jared/ My statements are only mine.
------------------------------------------------------------------------------
John Zwiebel Phone: 408-526-5303
Cisco Systems Inc.
IP Multicast Group