All things related to multicast

[John Zwiebel <>]

WRT Marshall's idea on ASM, I could support it with the caveat
that having the RP be a router responsible
for decapsulating the packet so it can be forwarded down the shared
tree is a mistake.

In such a case, -perhaps- the bootstrap router or auto-RP could
be configured to accept messages from a host specifically set up
to do this decapsulation and which would also have the ability
to monitor which senders there were and filtering these senders
out of the conversation (session).  After all, there's nothing
that says an RP has to be a router.  It just has to be capable
of acting as a rendezvous point and the root of the shared-tree.

I would think that then you (Robert) could keep the ad hoc
conferencing you want the network to do for you.  Your receivers
do have to know the multicast group they want to join.  How do
they get that information now?

I know that its convenient now for the network to handle distribution
of source information, but since you have to distribute group information
anyway...  And if you were to combine this with Marshall's ASM 
suggestion,
you could distribute sources down that same multicast path.

WRT using SDP, it doesn't matter at all what method you use to
distribute the source information.  Use any method you like or
even a combination of methods to meet the requirements of different
applications.  I should have said "SAP" message, but if you don't
like SAP, then whatever else you might want will work just
as well.  After all, you already have to distribute (I imagine, I could
be wrong) quite a bit of other types of information.  A list of the
participants shouldn't be that difficult to add.  (i do realize you
have to add it, but -- without knowing what I'm really talking about
since I don't know what you distribute -- it just doesn't seem like
it could be that much more difficult.  After all, putting IGMPv3 into
FreeBSD or Linux or any OS has already been done and proven
to work.  The amazing thing to me is that it hasn't been made
a default configuration item yet.  It "just can't be that tough" --
can it?  ;-)

WRT your customers, I suppose that if they are willing to accept
what will eventually be seen as substandard performance and the
loss of reliability in the service then there's no need for them to move
to SSM.  And, if it isn't clear, they don't have to move to SSM if they
don't want to.  ASM and SSM can quite peacefully coexist -- with
the SSM receivers having a much higher reliability of services -plus-
the added benefit of the 232/8 address space with will allow a
completely SSM conference to avoid having to filter unwanted
sources at the receiver.

You don't have to move to SSM if you don't want to.  But realize that
the compromises you have to make by not doing so are going to
result in a product that is going to have other problems further down
the line.

Just in case, SSM is not a "final solution", all it does is eliminate
from the PIM protocol those functions that should never have been
included in a multicast protocol from the beginning.  Source discovery
for unicast certainly doesn't depend exclusively on RIP or OSPF.  ;-)

So, in the end, the biggest question access-grid has to answer (at
least with respect to multicast) is  how are you going to allocate
multicast group addresses in an ad hoc way so that receivers
receive -only- from the sources they are interested in?  This problem
seems to be at least as difficult as figuring out how to distribute
the sources you -do- want to listen to.  (IMHO,  knowing what you
want is a lot easier than knowing what you don't want -- that is if
you can even make that choice. ;-)


Now that I'm trying to solve problems that I don't completely
understand, I appreciate everyone's forbearance, I will try to refrain
from further suggestions -- but everyone, please recognize that if
you are expecting MSDP to get fixed -- it ain't gonna happen.  No
matter how much effort is put into it, it has to be recognized that
trying to encapsulate a data packet in a control packet that is then
flooded throughout the entire world is never, ever going to work.

z

On Monday, May 13, 2002, at 01:39 PM, Robert Olson wrote:

> At 01:33 PM 5/13/2002 -0700, John Zwiebel wrote:
> > On Monday, May 13, 2002, at 01:02 PM, Robert Olson wrote:
> >
> > > If we could know that SSM was available on all sites' last-hop 
> > > routers,
> > > and that all the OSs we use had support for IGMPv3 we'd be moving 
> > > faster
> > > toward SSM (it has some nice properties we'd like to make use of...)
> >
> > IMHO, if it isn't, if you move to SSM, the folks that really want to 
> > play
> > with
> > you will make sure that happens.  In the mean time, that shouldn't 
> > prevent
> > you from being able to do both.  Moving to SSM means only:
> >    -- including the source in the SDP information
>
> But I may not know that. In an ad hoc conferencing application, I need
> additional infrastructure to keep track of senders so the address of a 
> new
> sender can be distributed to everyone so they can join. It's quite
> convenient for the network to do this for me...
>
>
>
> > in both cases, exactly what you are doing now.
>
> Except that I don't have a way to distribute source IP address 
> information
> at the moment..
>
>
> > The movement to SSM -does-not- require a "flag day".  Nor does SSM
> > require that you uses the 232/8 range.  If you are sending on an ASM
> > multicast group (ie anything other than 232/8) if the application knows
> > how to read the source info in the SDP message,
>
>
> You're assuming I'm using an SDP message for coordination..
>
> > and can send an
> > IGMPv3 report, there is -nothing- preventing that last hop router from
> > joining the shortest-path for that source.
>
>
>
> > > Any news on support in L2 switches for IGMPv3 switching? How about 
> > > Linux
> > > support for IGMPv3 (last I saw the sprint code isn't being supported).
> > IGMPv3 snooping is easier to implement than IGMPv2 snooping. Vendors
> > who haven't done so should be put out of business.
>
> Okay, I'll have my network folks chase after Cisco and Intel.
>
>
> > What does it take to get the sprint code "supported"?  Consumer demand.
> > You're a consumer, tell your Linux vendor you want it or you won't buy 
> > it.
> > OTOH, it isn't "supported" because no one is using it.  Taht circular
> > thing again.
>
> Exactly. But I can't go out and require a service that my customers 
> can't
> get...
>
> --bob