Re: Comments on draft-ietf-ipoib-link-multicast-04.txt

> >   And shouldn't the IPoIB sender subscribe to the IB multicast group
> >   creation events using a wildcard MGID so that it can
> >   "SendOnlyNonMember" join the group if a listener appears on the 
local
> >   IB subnet, or "SendOnlyNonMember" join the all-routers group if a
> >   router appears on-link and creates the all-routers multicast group?
> >   And doesn't it need to subscribe to the IB multicast group deletion
> >   events so that it knows when to switch back to sending to the
> >   all-router multicast group and/or stop sending?
> 
> An IP application may send the multicast packet to any group. One could
> request that the interface be notified of every MGID creation/deletion 
but the
> application(s) might never send any data to those groups. Therefore,
> the wildcard report request is something that the implementation will
> have to weigh against usage. The choice is upto the implementor.

This wasn't clear to me from reading the spec.  Let me see if I have 
this straight: 

- A listener MUST perform a "FullMember" join for the MGID of the 
  multicast group
- A listener MUST be able to receive an IP multicast packet over either
  the broadcast GID or the MGID for the multicast group
- A router MUST be able to receive an IP multicast packet over either 
  the MGID, all-router MGID, or broadcast GID
- If there is an on-link listener, a sender may send the packet using
  either the MGID or to the broadcast GID
- If there is not an on-link listener, a sender may send the packet to 
  either the broadcast GID or the all-router MGID

Is that correct?

And, if a sender wants to send packets using the MGID, it will need to 
listen for MGID creation/deletion reports so that it can switch between 
the MGID and the all-router MGID (or broadcast GID, I suppose) as 
on-link listeners join/leave the group.

I do have to wonder whether having such a large number of optional 
mechanisms to handle the mapping of IP to IB multicasting is really a 
good idea.  Would we be better off just selecting one approach and 
saying all IPoIB nodes should take that approach?
 
> 
> It does seem like a reasonable thing to request creation/deletion
> report on the all-router multicast GID.
> 
> 
> >
> >   But I'm wondering why a node needs to do this at all.  Wouldn't it
> >   make more sense for the IPoIB node instead create the multicast 
group
> >   and join the group so that IPoIB multicast routers can join the 
group?
> >   Yes, the IPoIB sender will need create the group as a "FullMember",
> >   but this seems to provide a simpler mapping of IP multicast to IB
> >   multicast.
> 
> It will work but how is this a better thing to do ? I also
> do not think that such behavior can/should be disallowed.

I'm just trying to understand if there is some way to simplify the 
mapping of IP multicast groups to IB multicast groups.  My main concern 
is with listening for IB group creation/deletion reports so a sender 
can tell if/when to use the multicast group's MGID and when to use the 
all-router MGID.  If the sender performs a "FullMember" join, then it 
will always send using the MGID for the corresponding IB multicast 
group.

But, based on what you said above, a sender can always use the broadcast 
GID when sending to a multicast group for which it is not also 
listening.  This does simplify the logic, but at the cost of forcing 
every IPoIB node to filter the IP multicast packets for which they are 
not interested.  Then again, it saves the SM from having to reprogram
the switches/routers in the IB fabric when the sender performs a
non-member join.  To be honest, I have no idea how to go about making
a rational choice on which approach will yield the better results.

Roy