Skip to Content.
Sympa Menu

wg-multicast - Re: "Virgin SSM": (was MSDP problems in the internet)

Subject: All things related to multicast

List archive

Re: "Virgin SSM": (was MSDP problems in the internet)


Chronological Thread 
  • From: "Marshall Eubanks" <>
  • To: John Zwiebel <>, Toerless Eckert <>
  • Cc: Marshall Eubanks <>, Hans Kuhn <>, David Meyer <>, Robert Olson <>, "Lucy E. Lynch" <>, Bill Owens <>, ,
  • Subject: Re: "Virgin SSM": (was MSDP problems in the internet)
  • Date: Wed, 15 May 2002 02:05:48 -0400

On Tue, 14 May 2002 12:16:27 -0700
John Zwiebel
<>
wrote:
>
> On Tuesday, May 14, 2002, at 11:36 AM, Toerless Eckert wrote:
>
> >
> > John, a host can not join to (*,G) and (S,G) with IGMPv3.
> > Blame IGMPv3 to be a broken protocol, but basically you
> > can either do an EXCLUDE({},G) membership (aka join (*,G))
> > or an INCLUDE({S},G) (aka join (S,G)). Remember: IGMPv3
> > allows you to only report INCLUDE or EXCLUDE mode for a group !
>
> Just to be clear, I didn't mean to say that a host could
> do this. What I understand is that some routers, when
> they get an include for an (S,G) that is not in the 232/8
> range will send a PIM (S,G) join as you would expect, but
> will -also- send a (*,G) join based solely on the IGMPv3
> include.
>
> Now, I might be mistaken (or rather my source might be mistaken).
> IHNO on whether this is a "good thing" or a "bad thing".
> Certainly, it would be something that should be considered by
> the content provider and the receiver.

Dear John;

Well, as a content provider, this does not seem like something that I
should rely on, regardless of how good or bad a thing it is.

It is likely that application writers (those who have put in SSM IGMPv3
calls at all) will assume 232/8 == SSM and that other multicast addresses are
ASM. So, as appears to be the case with MIM, I cannot assume that an
application
will do the right thing with a SSM join from outside of the SSM range.

When SSM was set up, the consensus was that it should not interoperate with
ASM. One can argue with this (it seemed unwise to me), but that was the
consensus. To set up SSM join information for an ASM group is thus a kludge.
It
seems unwise to me to try and set up a broadcast solution that relies upon a
kludge.

We will have a permanent SSM MPEG-4 channel up this week.

Regards
Marshall
>
>
> >
> > Yes, with IGMPv3lite we can do this ;-))
>
> IHNO on whether this is "good" or "bad".
>
> >
> > Cheers
> > Toerless
> >
> > Unless you come up with a completely twisted IGMP
> > If a host does an IGMP
> > On Tue, May 14, 2002 at 11:23:31AM -0700, John Zwiebel wrote:
> >> Toerless Eckert wrote:
> >>>
> >>> On Tue, May 14, 2002 at 07:27:30AM -0400, Marshall Eubanks wrote:
> >>>>
> >>>> I must admit that as a practical matter, I am dubious about the
> >>>> effacy of just
> >>>> treating ASM sessions as if they were SSM. The two were deliberately
> >>>> intended
> >>>> not to interoperate at the group level, and it seems like a kludge
> >>>> to treat them
> >>>> as if they were.
> >>>>
> >>>> Marshall
> >>>
> >>> Please explain.
> >>
> >> FWIW:
> >> I suggested to him that if the source was included in the
> >> SAP description that a host could decide for itself
> >> whether it wanted to join (*,G) or (S,G) allowing
> >> him to use a single source to satisfy both SSM and ASM.
> >>
> >> Since some vendor implementations will have the last hop
> >> join to the (*,G) as well as the (S,G) on receipt of
> >> an IGMPv3 report, and for many other reasons, his
> >> reluctance to follow this suggestion is valid. I
> >> totally agree that doing this is a kludge.
> >>
> >> But then so was MSDP, any-cast RP, and IGMP snooping.
> >>
> >> If the community wants to stay "virgin" and keep ssm
> >> only in the 232/8 range (ie there is 'virgin SSM' and
> >> 'compromised SSM' which would be to implement my
> >> kludge.) that's fine with me. There are probably
> >> many reasons to do so.
> >>
> >> OTOH, there's no reason to not use the kludge. It
> >> doesn't result in any interoperability problems and
> >> it does get packets to the receiver without having to
> >> depend on MSDP. So, I'm happy to leave it up to the
> >> content provider and the receiver to make the
> >> choice about whether or not they want to maintain
> >> their virginity.
> >>
> >> z
> >
> > --
> > Thanks
> > Toerless Eckert
> >
>




Archive powered by MHonArc 2.6.16.

Top of Page