[ewg] [PATCH] Make multicast and path record queue flexible.

[Christoph Lameter]

On Tue, 5 Oct 2010, Jason Gunthorpe wrote:

> > > I still think the problem you have with IGMPv2 is best solved by
> > > leaning on the gateway vendors to support IGMPv3 - which *does* send
> > > all reports to 244.0.0.22
> >
> > s/22/2
>
> No, 22. RFC 3376:
>
> 4.2.14. IP Destination Addresses for Reports
>
>    Version 3 Reports are sent with an IP destination address of
>    224.0.0.22, to which all IGMPv3-capable multicast routers listen.  A
>    system that is operating in version 1 or version 2 compatibility
>    modes sends version 1 or version 2 Reports to the multicast group
>    specified in the Group Address field of the Report.  In addition, a
>    system MUST accept and process any version 1 or version 2 Report
>    whose IP Destination Address field contains *any* of the addresses
>    (unicast or multicast) assigned to the interface on which the Report
>    arrives.

Argh. Another MC group. And the ib layer does need to do IB level joins
for those. So the initial messages will be lost for the first join(s)?

> > Certainly a solution for the igmp messages themselves but not for
> > initial traffic or traffic send via sendonly join.
>
> Using .22 will generally solve the problems with sychronizing the
> IPoIB gateway to the state of the IGMPv3 clients. Yes, there will
> still be some unknown lag in building the IB side of the network and
> for the router(s) to get ready to handle the group - but at least it
> is no longer dependent on any timeouts.

How do you propose to handle the IB level join to 224.0.0.22 to avoid
packet loss there? IGMP messages will still get lost because of that.