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 Fri, 11 Oct 2002, Marshall Eubanks wrote:

> On Thu, 10 Oct 2002 19:08:07 -0700 (PDT)
>  Greg Shepherd <shep@juniper.net> wrote:
> >
> > 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
>
> Greg;
>
> I am not sure I agree...
>
> Assume some many to many game application implemented using multicast
>
> Suppose that you at home and someone at the U of O want to participate in the
> same group, and that I join here too. Assume (as I believe to be the case) that
> you and the UO guy are topologically close in the network, and let the router A
> be at the point where the tree from me to you two diverges, and assume symmetric
> routing.

Where or not the paths diverge has no impact on state. You join *,G - you
get packets from S1 and S2, so your DR joins S1,G and S2,G - you get data
from both sources and you have the state for both source trees and the
shared tree.

Greg

> Now, in an ASM model, I join one group. At the router A, once the SPT is set up,
> there is only state for the one path to me. In the SSM model, I have  to join 2
> channels - one for you, and one for UO. At router A, even though the groups have
> the same path, state has to be maintained for both channels. So, no, I do not
> see that the state is the same between SSM and ASM in this case, at least
> between router A and me, although the data flow is the same. Whether this is
> important is another question.
>
> > 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. ;-)
> >
>
> You may be right. Maybe there is no real _need_ for inter-domain ASM protocols
> in IPv6.
>
> Maybe a toolkit approach would make sense here - if you need automatic
> source-discovery, here are some ways to do it - along the lines of the reliable
> multicast working group approach.
>
> > Greg
> >
>
> Marshall
>
> > > 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
> > >
> > >
> >
>
>