Re: Use of SAP in a PIM SSM Network

[Toerless Eckert <eckert@cisco.com>]

> I suppose one way to make SAP work in SSM is to modify the protocol to
> have the directly connected routers to active sources use unicast to
> register with core "rendezvous points".  Then each of these rendezvous
> points will talk to each other with another protocol to tell each other
> about the active sources that they are each aware of.  Wait, this sounds
> familiar...

Selling the spanish inquisition to protestants!

> SSM presents an interesing tradeoff where some functionality is reduced to
> meet a much more common model as well as radically simplifying network
> deployment.  Being only able to join a single source is inherantly
> incompatible with something like SAP, but few commercial content providers
> would disagree that sdr doesn't represent the commercially viable future
> of multicast.  SSM hinges upon the mass appeal of one-to-many apps like
> WMP, Real player and IP/TV, while eliminating the biggest hinderance to
> deployment: a PIM-SM/MSDP RP-based infrastructure is too complex.
> 
> Maybe SSM is just a stepping stone to the full functionality that
> shared-tree infrastructures provide.  But it will be a whole lot better
> than what we have now, where multicast is virtually nowhere to be found.

The whole point is that global source discovery in the network layer with
a non-hierarchically managed address space has shown to be a non-scaling
approach. There are things that sound cool in the first place and work
to a point but have some limits. Just because we learnt this about the
IP Multicast model after 10 years doesn't mean that the model is bad or
that we should force to make it work somehow, if there are much more
easy alternatives to get to the same results by just putting tasks into
different layers.