Subject: Re: [Ipoverib] remaining multicast issues - one more try

From: "H.K. Jerry Chu" <[email-masked]>
Date: Mon, 10 Jun 2002 10:32:50 -0700 (PDT)

>>For each active MC group (with > 0 member) the router needs to
>>join in order to receive. But the regular "join to receive" will
>>count the router as a real member, which must not be the case (otherwise
>>the MC group won't ever be deleted because its member count will
>>never drop to 0.) Thus we'll need a special "join to observe" that
>>still adds the caller to the list of listeners but doesn't cause the
>>member count maintained by SA to increment.
>
>Routers send / receive multicast packets thus are real members just like 
>any other endnode within an IB subnet especially if they are using the 
>subnet as an intermediate hop along the way to other subnets and the 
>multicast group spans all subnets even if not locally used by any other 
>endnode.  The SA would need to identify the router and determine whether 
>there is anyone using this service to determine whether the router should 
>be told to go away.

Note that we're talking about IP routers here. How would SA at the IB
level knows that a node is performing IP forwarding function? When
an IB MC group is created because an IP MC listener comes into
existence, the IP router needs to be notified in order to join the
MC group to pick up pkts. Later when the only IP MC listener quits,
how would SA knows that there is no more "real listener" on the MC
group if the IP router is counted as a real listener? There seems
to be some confusion that IP multicast routing protocols will somehow
magically work this out. I don't think so.

If IBTA believes it will have all the necessary facility to allow
an emulation of promiscous MC mode that is great. I just don't see
how that works without the above. (And I really hope to be proven
wrong.)

Jerry

>Mike

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 19 Jun 2002 10:37:26 -0700

I found it in the achieves.  Looks like it hasn't made it through our email
system yet.  Bill's response (which I did receive) now has some context and
I think he's covering the same concerns I have.

Roy 

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, June 19, 2002 10:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Ipoverib] remaining multicast issues - one more try

> 
> Vivek,
> 
> Is the last paragraph of your mail the answer to Bill's question on how
the
> router will even get the IGMP report to begin with?  I.e. register for
group
> create/delete traps and adding the filter when they are received.  Is so,
> doing something base on a received IGMP report is redundant.  If not, how
> does the router receive the report sent to a multicast group it is not a
> member of in IGMPv1 and IGMPv2 environments?

No, the response to his question was in another mail. See the latest
mails from me and Bill for that discussion. 

Vivek

> 
> Roy
> 
> -----Original Message-----
> From: Vivek Kashyap [mailto:[email-masked]]
> Sent: Tuesday, June 18, 2002 4:45 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ipoverib] remaining multicast issues - one more try
> 
> 
> > 
> > Thanks for the explanation, Bill. So if I understand correctly,
> > proposal # 2 won't work unless changes are made to the IP code on
> > both the host side and the router side (with the exception of IGMPv3,
> > which has been widely deployed), right?
> 
>         Read my previous mail - I have put forth this example earlier
>         too. Let us discuss this in detail before knocking it off.
> 
> > 
> > I proposed a "hack" (#1) initially to require the host side IPoIB driver
> > to copy every outbound multicast pkt to all-router. There was a small
> > problem if a router itself is a genuine member of the targe multicast
> > group but this problem can be worked around easily (yes more hack :-(.
> > This workaround is not something one would brag about. But at least
> > it is transparent to IP implementations.
> 
>         As noted earlier in the thread - this has the possibility of
>         inserting duplicates in the network. To implement the 'hack'
>         wouldn't the router have to change too and the host too ?
> 
>   As was noted on June 7th in this thread:
> 
>             "How do one ensure that the router is not a member of any
>             IB group ? What mechanism stops it from being a member ?
>             Many nodes do double duty - they host applications and
>             also act as routers - how do they decide?
> 
>             As per this solution a router will receive two packets and
>             if the IP subnet has multiple routers then multiple
>             routers get two packets. If the corresponding IP group has
>             a scope larger than the local subnet - each of these
>             routers will now forward multiple packets outward. If one
>             or more of these neighbouring subnets are IPoIB subnets we
>             can further multiply the number of copies by a factor of
>             two at the least. The result would be that IPoIB
>             subnetswould end up creating multicast storms quite
>             often.  "
> 
>     
> 
> > 
> > A different proposal #2 below was made later (by Vivek). My problem
> > with that propsal is that it requires link-specific changes to router
> > implementation. Now it looks like it requires changes to host side
> > as well.
> 
>         Not later :) - I proposed it in my earliest drafts too since
>         the IBTA spec was very limited in this regard.
> 
> 
>         See my previous mail. I had written in this thread on June 7th
>         regarding this proposal :
> 
>                 "
>     Take a look at the description below. The change is a
>                 simple function in the driver with a line or two added
>                 (considering BSD code) to the 'add multicast group'
>                 socket option.
> 
>                 The suggestion works within the existing
>                 infrastructure with a minor addition.
> 
>                 In existing implmementation the routing daemon on
>                 receiving an IGMP report adds the IP multicast group
>                 to the interface list. It tells the kernel to add the
>                 group by a socket option (in BSD/LInux
>                 implementations). The function after it adds the IP
>                 group to the interface can call the interface's device
>                 specific function - for IPoIB this function will ask
>                 the driver to join the IB group.
> 
>     (IGMP_report)--- n/w -> driver -> IGMP -> mrouted/gated
>                                                         |
>                                                     setsockopt(ADD_LGRP)
>                                                         |
>                                                         :
>                                                         :
>                                                         add_grp()
>                                                         |
>                                                 ** call device_add_grp()
**
>                                                 ** join relevant IB group
**
>                                                 ** if needed            **
> 
>                 Only the call marked with '**' is new. Nothing else.
>                 Note that the same function or similar function will
>                 have to exist on hosts for IP_ADD_MEMBERSHIP directive
>                 when a host application joins a particular IP group.
>                 In this case the router does the same thing on
>                 receiving an IGMP_HOST_MEMBERSHIP_REPORT.
> 
>                 The change is simple and does not require changes to
>                 'every version of group mgmt code'. It does not
>                 require changes to routing daemons, nor does it imply
>                 large, complicated changes in OSes. "
> 
> 
> 
> For the rest, I am suggesting solutions based on the current state of the
> draft including the two enhancements regarding group create/delete traps
you
> have mentioned. Promiscuous mode is not included in the IBTA
specification.
> Vivek

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)