Re: New draft on embedding the RP address in IPv6 multicast address

[Greg Shepherd <shep@juniper.net>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

On Thu, 10 Oct 2002, Marshall Eubanks wrote:

> 2000 member multi-player games come to mind. I believe that these have
> been done (as military simulations).
>
> SSM will have state and flows that goes as N^2 in this case - the

Many-to-many will always have flow of order of 1 outbound and N-1 inbound
- ASM or SSM. State is also the same between SSM and ASM - though
technically SSM has less state in that it does not require *,G for each
unique G. Only a shared-tree-only mechanism like BiDir can reduce state
for ASM.

The ONLY thing ASM has over SSM is in-band source discovery. So do we
build some ~universal mechanism in protocols to provide this, or do we
push off to the application writers to provide source-discovery as best
fits their audience scale and needs. Hmmm. ;-)

Greg

> real question is, can there be multi-domain solutions that only require
> state and flows of order N.
>
> Regards
> Marshall
>
> Leonard Giuliano wrote:
> > -) >
> > -) > However, you might be able to make ASM "SSM like" in that, if you
> > -) > find the group address by some means out of band, you can join to the RP
> > -) > and either send or receive.
> > -)
> > -) This is actually what is expected to happen.  The steps look like:
> > -)
> >
> > Going back a bit, if this ASM mechanism will rely on SSM-like group
> > discovery, why not just use SSM in the first place?
> >
> > The main problem with SSM in IPv4 is that ASM was already in use, and
> > there aren't enough implementations/deployments of SSM yet.  But v6 need
> > not carry the same albatross of legacy mechanisms around it's neck.  It's
> > a chance to do things right from the start.
> >
> > Does anyone actually see any real cases where SSM won't be at least "good
> > enough?"  Is all the complexity of ASM, and the duct tape solutions being
> > discussed worth it just so that SDR will work?
> >
> >
> > -Lenny
> >
>
>
> --
>                                   Regards
>                                   Marshall Eubanks
>
>
> T.M. Eubanks
> Multicast Technologies, Inc
> 10301 Democracy Lane, Suite 410
> Fairfax, Virginia 22030
> Phone : 703-293-9624       Fax     : 703-293-9609
> e-mail : tme@multicasttech.com
> http://www.multicasttech.com
>
> Test your network for multicast :
> http://www.multicasttech.com/mt/
>   Status of Multicast on the Web  :
>   http://www.multicasttech.com/status/index.html
>
>