Subject: RE: [Ipoverib] Bit number of IP address in MGID

From: "H.K. Jerry Chu" <[email-masked]>
Date: Wed, 6 Feb 2002 18:55:53 -0800 (PST)

Koji,

While I don't feel Ethernet compatibility is a strong enough
justification in this case, pains caused by bugs or implementation
anomaly are real. Note that for the forseeable future IPv6 will be
using only the lower 32 bits as group ID so it's not an issue.
But the issue is real for IPv4. As one of the authors of the draft
I'm willing to consider the change if there is enough demand (e.g.
other implementations also have the same problem).

Jerry

>Date: Wed, 6 Feb 2002 15:43:44 +0900 (JST)
>From: [email-masked] (Koji Takahara)
>To: [email-masked]
>Subject: RE: [Ipoverib] Bit number of IP address in MGID
>Mime-Version: 1.0 (generated by tm-edit 7.66)
>X-Mailman-Version: 1.0
>List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
>X-BeenThere: [email-masked]
>
>Vivek, Roy,
>
>What is the merit of 80bits for IPv6 and 28bits for IPv4 ? 
>I think 32bits for IPv6 and 23bits for IPv4 are enough. 
>
>If we use 32bits for IPv6 and 23bits for IPv4,
>the lower bits of the multicast address which are used by ipoib driver
>become compatible with Ethernet.
>I think if an interface can be compatible with the current one,
>it is better to be so.
>
>Koji
>
>> Koji,
>> 
>>         DL_ENABMULTI_REQ primitive includes the multicast address
>>         length. Your implementation needs to be modified as needed for
>>         the IPoIB link.
>> 
>>         As far as I know the complete multicast address (and therefore
>>         dependent on the link) needs to be passed to the driver. So
>>         reducing the number of the bits in the mapping really has no
>>         effect anyway.
>> 
>> Vivek
>
>> Koji,
>> 
>> For Linux, this is not problem.  The upper layer software is link device
>> independent.  When a link specific operation needs to be performed, like
>> mapping a multicast address to a link multicast filter, it performs a
>> switch-case on the link device type.
>> 
>> So, for IPv4, there is a arp_mc_map() function which contains a switch-case
>> that is currently sensitive to Ethernet, FDDI, IEEE802, and Token Ring.  To
>> fit into this infrastructure, I'll need to add a case for IPoIB.  I grant
>> you that this does require a source code change, but the source is freely
>> available and the infrastructure is setup to add new link types.  We'll be
>> working with the Linux community to accept IBA as a supported link in future
>> Linux releases.
>> 
>> I thought DLPI was also link independent.  Why is passing in an Ethernet
>> address?  Can SVR4/Solaris only support Ethernet link types?
>> 
>> Roy
>
>_______________________________________________
>IPoverIB mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipoverib

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