<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [Openib-windows] IPoIB GUID to MAC conversion</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Fab Tillier [<A HREF="mailto:ftillier@silverstorm.com">mailto:ftillier@silverstorm.com</A>] </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > Can be one of:</FONT>
<BR><FONT SIZE=2>> > 1) generic hash on GID - all nodes will show the same MAC</FONT>
<BR><FONT SIZE=2>> > entries on ARP. You're stuck if you have hash collision</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> To add to the collision woes, we probably also want to report </FONT>
<BR><FONT SIZE=2>> valid MAC addresses (globally unique or locally administered </FONT>
<BR><FONT SIZE=2>> - as controlled by the corresponding bit in the 48-bit MAC). </FONT>
<BR><FONT SIZE=2>> If we hash, then the MAC is locally unique, and must have the </FONT>
<BR><FONT SIZE=2>> second to last bit of the first byte set. It should also not </FONT>
<BR><FONT SIZE=2>> have the least significant bit of the first byte set to </FONT>
<BR><FONT SIZE=2>> indicate that it isn't a multicast MAC address. That is, the </FONT>
<BR><FONT SIZE=2>> lower two bits of the first byte need to be binary 10. I </FONT>
<BR><FONT SIZE=2>> don't know what the Windows networking code does with the MAC </FONT>
<BR><FONT SIZE=2>> addresses, and don't know if it's safe to just return full </FONT>
<BR><FONT SIZE=2>> 48-bit hashed values. I'd prefer to hash to 46 bits.</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>Right. The two first bits of the MAC address are reserved to </FONT>
<BR><FONT SIZE=2>unicast/mcast and localy/globally administered. We only have</FONT>
<BR><FONT SIZE=2>46 bits left for tricks. This applies to all 4 approaches.</FONT>
</P>
<P><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > 2) create locally faked MAC in each node - not all nodes will</FONT>
<BR><FONT SIZE=2>> > show the same MAC (arp -a). You can solve it by writing</FONT>
<BR><FONT SIZE=2>> > a new utility, e.g. ipoib_arp, which will dump the full 20B</FONT>
<BR><FONT SIZE=2>> > MAC addresses by using some private interface with the NDIS</FONT>
<BR><FONT SIZE=2>> > miniport</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> This is similar to the hash as far as reserving bits and what </FONT>
<BR><FONT SIZE=2>> not. It trades collision for inconsistency. I think </FONT>
<BR><FONT SIZE=2>> collision is probably better than inconsistency.</FONT>
</P>
<P><FONT SIZE=2>Let's think about what collision means for the network administrator. It </FONT>
<BR><FONT SIZE=2>means that he effectively has two cards with the same MAC and therefore</FONT>
<BR><FONT SIZE=2>has to replace one of them or flash it with a newly assigned GUID. If this </FONT>
<BR><FONT SIZE=2>is acceptable, then collision is not a problem.</FONT>
<BR><FONT SIZE=2>You can always argue about the likelihood of this to happen.</FONT>
<BR><FONT SIZE=2>Inconsistency can be solved by having a new utility, new "arp" command,</FONT>
<BR><FONT SIZE=2>that will print the full 20B MAC address, and will make all nodes consistent.</FONT>
</P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > 3) assume some GUID assignment algorithm - can be problematic</FONT>
<BR><FONT SIZE=2>> > looking into the future. Might not fit all cards, all </FONT>
<BR><FONT SIZE=2>> vendors, etc.</FONT>
<BR><FONT SIZE=2>> > I'm not sure that all the vendors can commit on how they</FONT>
<BR><FONT SIZE=2>> > assign GUIDs today, because they may want the ability</FONT>
<BR><FONT SIZE=2>> > to change the GUID assignment method without rewriting</FONT>
<BR><FONT SIZE=2>> > the miniport.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I don't think this should be the only option - if a vendor </FONT>
<BR><FONT SIZE=2>> has an algorithm, it should be used since it generates a </FONT>
<BR><FONT SIZE=2>> valid MAC address. This option would be used in conjunction </FONT>
<BR><FONT SIZE=2>> with one of the others.</FONT>
</P>
<P><FONT SIZE=2>You mean that it can be used to optimize the hashing algorithm ?</FONT>
</P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > 4) Use the 48 bits to contain the path information. A non </FONT>
<BR><FONT SIZE=2>> IB routable</FONT>
<BR><FONT SIZE=2>> > approach will use the bits as follows: 16 LID, 4 SL, 24 QPN,</FONT>
<BR><FONT SIZE=2>> > 2 static rate (might be not enough to hold all static </FONT>
<BR><FONT SIZE=2>> rate options)</FONT>
<BR><FONT SIZE=2>> > 2 reserved (local/global, unicast/mcast) - total 48 bits.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> This is interesting, as it would allow creating static ARP </FONT>
<BR><FONT SIZE=2>> entries. Does it break the ability of IPoIB routers to route </FONT>
<BR><FONT SIZE=2>> traffic from IB to Ethernet? </FONT>
</P>
<P><FONT SIZE=2>No. This approach is IP routable (IPoIB to IPoEther). It is not</FONT>
<BR><FONT SIZE=2>IB routable because we won't be able to add a GID when sending</FONT>
<BR><FONT SIZE=2>packets.</FONT>
</P>
<P><FONT SIZE=2>> I personally don't give a hoot </FONT>
<BR><FONT SIZE=2>> about IB global routing. I think it's a dumb feature and </FONT>
<BR><FONT SIZE=2>> adds needless complexity to the architecture.</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
</BODY>
</HTML>