<html><body>
<p><tt>Jason,</tt><br>
<br>
<tt>The bottom line of this patch is the same DAD bahavior w/o this patch, let's see how DAD behaves w/i, w/o this patch:</tt><br>
<tt>1. If multicast join failure forever, then the IPv6 address is useless in both cases, but IPv4 will work in fabrics w/i this patch, but IPv4 doesn't work w/o this patch.</tt><br>
<tt>2. If multicast join successfully right away, then most likely we will receive the NA on time, then there is no DAD issue in both cases.</tt><br>
<tt>3. If multicast join successfully within the DAD timer, most likely we will receive the NA on time in both cases.</tt><br>
<tt>4. If mulitcast join succesffully after the DAD timer, then we have DAD issue in both cases.</tt><br>
<br>
<tt>Only a tiny timing difference (a few lines code) w/i w/o the patch, that's I don't understand why you think this patch impacts the DAD behavior, but I think this patch does turn on carrier on on right time. Look at RFC IPoIB in section 5:</tt><br>
<br>
<tt><b>Thus, the IPoIB link is formed by the IPoIB nodes joining the broadcast group. There is no physical demarcation of the IPoIB link other than that determined by the broadcast group membership.</b></tt><br>
<br>
<tt>>If IPoIB is asked to send to a multicast address that is not yet<br>
>joined (join is pending to the SA, or whatever) then it uses the<br>
>broadcast MLID for the packet. This is similar to how ethernet works<br>
>and would let DAD and RS work correctly in all cases.<br>
</tt><br>
<tt>Yes this is another patch I am working on. For IPv4 we use broadcast MLID, for IPv6 we use all host multicast MLID for the packet. Here is the RFC regarding not finding the multicast entry, but it only mentions remote subnet, not for local subnet. We do need a patch for IB multicast join for different subnets in the fabrics. It is missing in IPoIB right now.</tt><br>
<br>
<tt>10. Sending and Receiving IP Multicast Packets</tt><br>
<tt> Multicast in InfiniBand differs in a number of ways from multicast in<br>
ethernet. This adds some complexity to an IPoIB implementation when<br>
supporting IP multicast over IB.<br>
<br>
A) An IB multicast group must be explicitly created through the SA<br>
before it can be used.<br>
This implies that in order to send a packet destined for an IP<br>
multicast address, the IPoIB implementation must check with the<br>
SA on the outbound link first for a "MCMemberRecord" that<br>
matches the MGID. If one does exist, the Multicast Local<br>
Identifier (MLID) associated with the multicast group is used<br>
as the Destination Local Identifier (DLID) for the packet.<br>
Otherwise, it implies no member exists on the local link. If<br>
the scope of the IP multicast group is beyond link-local, the<br>
packet must be sent to the on-link routers through the use of<br>
the all-router multicast group or the broadcast group. This is<br>
to allow local routers to forward the packet to multicast<br>
listeners on remote networks. The all-router multicast group<br>
is preferred over the broadcast group for better efficiency.<br>
If the all-router multicast group does not exist, the sender<br>
can assume that there are no routers on the local link; hence<br>
the packet can be safely dropped.</tt><tt><font size="4"><br>
<br>
</font></tt><tt>I had started another thread discussing the second patch before.</tt><br>
<br>
Thanks<br>
Shirley Ma</body></html>