Re: multicast-transition

["Tony Ballardie" <ballardie@dial.pipex.com>]

Marshall,

> It seems to me that if you go to the trouble of having IGMP or PIM set up,
then you
> are likely to be multicast savvy, and so won't really need this.
Otherwise, IGMP may
> be set up (or not) by your provider - if they don't do multicasting, they
are unlikely to
> do IGMP. In fact, I know of at least one ISP that has PIM enabled
backbones
> but does not IGMP enable edge routers just to keep multicasting under
tight control.
> This all seems a lot different from the case of IPv6, where the provider
may be
> assumed to be cooperative. Having application level auto-tunneling would
really
> expand the usability of multicasting, I suspect a lot more than for
network-layer tunnels.

the idea, as I envisage it, is to have a special IGMP message
anycast to a well-known (hard coded) anycast address, though
probably changeable through a config option. Most OSs support
IGMP, so the user would/can be oblivious, and similarly for
intervening ISP(s).

The other component to auto-tunnelling I forgot to mention is
where a *router* has to get over non mcast infrastructure.
My first suggestion for this was to alter the destn of PIM joins
to the anycast addr, but I gather it affects other PIM behaviours.
However, whether the trade-off of doing it anyway and altering
PIM accordingly, is worth it?? My view is, that after all these years
of not getting very far, we *need* transparent auto-tunnelling
for the host AND router, else IP mcast will never fulfil its potential.

As I see it that's not the end of the story either... then there's
QoS, reliability (ok, dealt with by RMT, but still early days), and
inter-provider pricing to solve before it can become commercially
viable in itself. And I'm a fan of IP mcast, but these seem to be the
harsh realities :-(   The CDNs have overtaken IPM because their
solutions plug the holes, although they tend to be less efficient
in the network.

Tony