[openib-general] Re: IP addressing on InfiniBand networks (Caitlin Bestler)

[Michael Krause]

At 10:39 PM 6/29/2005, Bill Strahm wrote:

>>------------------------------
>>
>>Message: 2
>>Date: Wed, 29 Jun 2005 09:00:37 -0700
>>From: Roland Dreier <rolandd at cisco.com>
>>Subject: Re: [openib-general] IP addressing on InfiniBand networks
>>To: Caitlin Bestler <caitlin.bestler at gmail.com>
>>Cc: "Lentini, James" <James.Lentini at netapp.com>, Christoph Hellwig
>>         <hch at lst.de>,   openib-general <openib-general at openib.org>
>>Message-ID: <5264vxi256.fsf at topspin.com>
>>Content-Type: text/plain; charset=us-ascii
>>
>>    Caitlin> An assigned GID meets all of the requirements for an IA
>>    Caitlin> Address.  I think taking advantage of that existing
>>    Caitlin> capability is just one of many options that can be done
>>    Caitlin> by the IB CM rather than forcing IB specific changes up
>>    Caitlin> to the application layer.
>>
>>Just to be clear, the IBA spec is very clear that a GID _is_ an IPv6 address.
>>
>>- R.
>>
>>
>Just to be REALLY clear - IANA has not allocated IPv6 address space to any 
>Infiniband entities - so they are not Internet IPv6 addresses.  GIDs are 
>formatted like IPv6 addresses but in no sense should EVER be used at an IP 
>layer 3 address.
>
> From an IPoIB stance - IB is just a very over engineered Layer 2 that has 
> a singularly large MAC address.
>
> From an IB ULP point of view - how you get to the layer 2 address that is 
> needed to perform communications that do not include IP, it isn't a 
> problem - but let me tell you.... The leadership of the IETF is scared of 
> IB because of saying things IB GIDs _ARE_ IPv6 addresses.

Being the person who led the addressing definition for IB, I can state 
quite clearly that GID are NOT IPv6 addresses.  They were intentionally 
defined to have a similar look-n-feel since they were derived in large part 
from Future I/O which had them as real IPv6 addresses.  But again, they are 
NOT IPv6 addresses.

For IP over IB, it is unfortunate that we could not have simply used a raw 
datagram service as that would have made life very simple but we are in the 
state we are so that means there is a UD transport providing a layer 2 
Ethernet equivalent of functionality.

Mike 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050630/a63a57a1/attachment.html>