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

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 19 Jun 2002 09:49:34 -0700

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?

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

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

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

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 19 Jun 2002 10:15:23 -0700 (PDT)

> 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

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