Subject: Re: [Ipoverib] IPoIB architecture/encapsulation

From: "H.K. Jerry Chu" <[email-masked]>
Date: Sun, 9 Dec 2001 23:26:18 -0800 (PST)

Vivek,

I have a few comments on draft-kashyap-ipoib-requirements-01.txt.
I'm going to skip the IB overview and focus on IPoIB related sections.

First, what's the plan for this I-D? Is it intended to be informational,
or is it intended to get on the standard track?

I have also some serious concern, after reading past section 4, about
the intent of this i-d. It seems have gone way beyond its scope as a
"requirement" doc.

Section 3.2 Multicast support, I'd like to suggest making the IB
multicast support a requirement for running IP. Without a proper link
multicast support, it may signifcantly complicate the IPoIB standard.

This is not to say that implementation lacking hardware multicast
support can't emulate multicast function in software. But such
emulation must be made completely transparent to standard IPoIB stacks.

Section 3.2.2 Transient flag in IB MGIDs, IBA, after failing to
includie P_Key as part of an IB multicast group definition, has
acknowledged the infeasibility of IB well known MGIDs. So there is not
much point to follow the rule that was set for IB well known MGIDs.

Section 3.4 Multicast address to LID mapping, IMO not much of
explanation is needed here because according to IB spec., LID is
allocated and managed by SM, period. (Clients can't specify a MLID when
creating a MCGroupRecord.)

Subsection 1) Sending/receiving IP multicast, I don't think a
sender of a mulicast packet must be a member of that multicast group.
This is similar to IP over Ethernet. The only trouble for IB is that
there may not be a link mutlicast group to send this packet out. I have
suggested for such a case to forward the packet to a local multicast
router.

4.0 IP subnets in InfiniBand fabrics, IMO it goes beyond the scope of
a requirement. and gets into some specific mechanics. Although what you
said there is what you and I have agreed upon, it's best to leave
this section to the multicast I-D we'll be working together.

4.1 IPoIB VLANs, again IMO you've deviated from the requirement and
got into specifics.

4.2 Multicast in IPoIB subnets, I'm not sure about the three levels
you described there. Which RFCs are these levels defined?

4.2.1 Sending IP multicast datagrams, I don't think what you
described is correct. An non-existing IB multicast group on the local
link only means that there is no member node of the group on the local
link. (I don't believe resources for MGID allocation will be a real
issue.) But a multicast router must attempt to forward the packet to
members in remote networks.

4.2.2 Receiving multicast packets, it seems a bit redundant. There is
no need to mention IGMP/MLD or any specific protocols. Once IPoIB
multicast mapping is defined, things will fall into place automatically.

After 4.2.2, I decided to stop because it becomes less and less clear
to me what the intent of this I-D is. You seem to have deviated
gradually from the 'requirement' spec., and included most of the
multicast material that you and I have agreed to work upon in a
separate draft. Can this draft be made to focus on "requirement" only?

Jerry

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

---

From: Michael Krause <[email-masked]>
Date: Mon, 10 Dec 2001 18:56:53 -0800

>multicast support, it may signifcantly complicate the IPoIB standard.

Agreed.  All implementations must support multicast to avoid a repeat of 
the problems found with other technologies that did not support native 
multicast.

>emulation must be made completely transparent to standard IPoIB stacks.

It would also require changes to the hardware and remote packet validation 
should an implementation not support the use of MLIDs.

>creating a MCGroupRecord.)

If one were using only Raw Multicast, they could provide such a capability 
but given the use of IB transports for this effort, the multicast group is 
identified by its MGID and not by the MLID (especially since one can map 
multiple MGIDs to a single MLID making de-multiplexing in software even 
more cumbersome to implement / support).

>suggested for such a case to forward the packet to a local multicast

An endnode is allowed to inject multicast packets without being a 
member.  As you note, there is an issue in that the IB SM may not have set 
up the MLIDs to switch the packet into the fabric.  A solution would be to 
always require the SM to use the default multicast output port per switch 
to forward the packet into the multicast-enabled portion the 
fabric.  However, even this is not really that practical as there can be 
many multicast groups with different endnodes participating so a proxy 
router would be required as you suggest or it may require the SM to set up 
a switch that acts as a root for all multicast groups thereby allowing the 
default to direct all packets to this switch who then forwards the packets 
on the endnode's behalf.

>separate draft. Can this draft be made to focus on "requirement" only?

Mike