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

From: Vivek Kashyap <[email-masked]>
Date: Thu, 6 Jun 2002 17:42:41 -0700 (PDT)

> 
> A couple of weeks ago I asked IBTA for a summary to the IPoIB
> reflector on the changes likely to come as part of IBA 1.1
> spec later this year that will affect IPoIB. Unfortunately,
> the request was declined because IBTA rules forbid any 1.1
> info to go outside of member companies at this point. But
> based on my knowledge of their progress I felt comfortable to
> move the current drafts forward without risking incompatibility
> with IBA 1.1. If the latter does happen, we can always amend
> the drafts then.
> 
> But yesterday I heard from David Brean of IBTA/MGTWG that the
> item 3
> 
> a facility to allow the software emulation of the promiscuous
> multicast mode
> 
> remains unresolved within IBTA. Vivek also raised some concern
> too. IMO it is probably not worth holding the drafts for a single
> issue. But I decided to give it another try to resolve this issue
> in the next few days. If we can't reach a consensus before next
> Friday, I'd suggest we move the rest of the drafts forward
> leaving this issue behind to be addressed later.

        Are you suggesting that we define the algorithm based on
        points (1) and (2) ignoring (3) or are you suggesting that we
        define IPoIB multicast based on the current IB specification ? 

> 
> Let me restate that the promiscuous multicast mode is not only
> required for the proper operation of IP group mamagement protocol,
> it is also how a sender's multicast pkt gets picked up by an IP
> multicast router. The details are described in
> 
> rfc1112 -
> "Note that the multicast routers receive all IP multicast
> datagrams, and therefore need not be addressed explicitly..."
> 
> rfc2710 -
> "For each interface over which the router is operating the MLD
> protocol, the router must configure that interface to listen to all
> link-layer multicast address that can be generated by IPv6
> multicasts..."
> 
> IBA 1.0 spec. does not provide a promiscuous multicast mode in
> hardware or allow one to be emulated in software. So far there
> have been three proposals to address this issue:
> 
> 1. Require the IPoIB driver to send a copy of every outgoing
> multicast pkt to the all router multicast group. The algorithm
> looks like this: for a pkt destined to a multicast group M
> 
> 	if (M doesn't exist)
> 		send pkt to all_router
> 	else if (M != all_router)
> 		send pkt to all_router;
> 		send pkt to M;
> 	else send pkt to M;
> 		
> 2. Modify IP group management protocol module to do some extra
> work in case the link type is IB. An IP router will explicitly
> join any new multicast group that comes into existence. The
> router needs to figure out when to leave too (details from
> Vivek).
> 
> 3. Ask IBTA to add a facility to allow promiscuous multicast
> mode to be emulated in software.

        And a 4th would be to use only one multicast group at the IB
        layer for all IP multicast packets such as use broadcast_GID
        for all IP multicast. Not a good solution but an option.

> 
> 1. above seems to be the least painful. But it requires every
> node to be capable of sending pkts to all_router multicast
> group.

        The most bothersome issue of this option is the deliberate
        insertion of duplicates into the network. A big no-no in my
        opinion. 

> 
> The biggest problem with 2. IMO is that it requires changes to
> existing IP code in every version of group management code
> including IGMPv1, IGMPv2, MLD..., etc, and the change doesn't
> seem trivial. It may present a big obstacle for many OSes to
> request IB only changes in generic IP code.

        That is not the case. 

        In a generic implementation, the routing daemon (mrouted/gated
        for example) updates the kernel routing and multicast group
        tables. This is done since the IP forwarding code looks into
        this table when making its decisions.

        The multicast group information is always linked to the
        interface it is relevant to (ie. the subnet the multicast
        group is on). All one has to do is to add code that looks at
        the interface type and takes interface specific action(s). In
        the case of IPoIB it would join the corresponding IB MGIDs.

        Such a change is no different than adding an IB specific
        module. It does not effect the IGMPv1/v2/MLD code.

> >From what I've heard 3 should be simple to add. The SA has all
> the MC info already. It simply needs to supply the caller a
> list of all the existing MC groups, and notify the caller of
> any new group coming into existence so that the caller (driver
> of an IP router) can ensure it "join to observe" every
> multicast group.

        I am unclear on the meaning of 'join to observe'. A router may
        have to send packets out on the MGID - so it will have to
        'join' for receive and send.

> 
> Please express your opinion if you have one in the next few
> days. If we can't get to a consensus I'd say we shelf it and
> proceed with the rest of stuff. Note that since the
> encapsulation draft has a dependency on the link/multicast
> draft, it can't move forward alone. Also I don't want to wait

	The link-multicast draft defines the :

		- mapping from IP multicast to IB MGID
		- the definition of the IPoIB link

        We need to define the multicast forwarding methodology. In the
        interest of forward movement I suggest we do one of the
        following: 

        a) Add the mapping and link-definition pieces to the
        encapsulation draft. These two items are quite straigtforward
        and simple enough. Define the multicast forwarding later when
        IBTA publishes its specification.

        b) Publish the link-multicast draft now without multicast
        forwarding. It will define only the mapping and the notion of
        IPoIB link. The mutlicast forwarding solution is published
        later when IBTA specification comes out.

        We can live without having IPoIB multicast routing defined
        until september. 

> until September for the IBA 1.1 spec. We have other work to do.

        Does the other work include advanced capabilities (and
        DHCP/MIB)? 

Vivek

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

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

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

---

From: Michael Krause <[email-masked]>
Date: Mon, 10 Jun 2002 07:05:53 -0700

>         else if (M != all_router)

Strongly oppose this as previously discussed many months back.

>router needs to figure out when to leave too (details from

This does not require any change to the IP router code - the router joins 
any multicast group through event notification if it and group are in the 
same partition.

>mode to be emulated in software.

Don't see anything that must be added by the IBTA to allow this to work.

>of an IP router) can ensure it "join to observe" every

I believe group event notification is supposed to be defined as part of 
V1.1.  There is no reason to have an observe capability.

Recommend just proceeding with the other work and waiting until V1.1 which 
solves many of the multicast issues required and also solves a number of 
errata from IB as a whole.  This IB version, IMO, what will be deployed as 
volume product in 2003 so aligning with its functionality bodes best for 
interoperability and minimizing development costs.

Mike