All things related to multicast

[David Meyer <>]

So are you in favor of just leaving MSDP where it is (i.e.,
shutting down the WG and publishing what we have as experimental
or informational or?).

Dave

On Mon, May 13, 2002 at 03:41:59PM -0700, John Zwiebel wrote:
>> 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
>> >