[openib-general] IB Address Translation service

[Yaron Haviv]

> -----Original Message-----
> From: Libor Michalek [mailto:libor at topspin.com]
> Sent: Tuesday, March 01, 2005 2:04 AM
> To: Yaron Haviv
> Cc: Paul Baxter; openib-general at openib.org
> Subject: Re: [openib-general] IB Address Translation service
> 
> On Mon, Feb 28, 2005 at 09:55:50PM +0200, Yaron Haviv wrote:
> > From: Libor Michalek
> > >
> > > The two are not interoperable, they
> > > reside in parallel, and succeed in producing much confusion. (IMO)
> >
> > One note, the two can be made interoperable, if nodes that use IPoIB
> > register them self in the ATS database as well (which has its merits
for
> > reverse resolution that cannot be satisfied by IPoIB), this way the
> > nodes that just use ATS can locate the IPoIB ones.
> 
>   This relies on each node in a fabric keeping the information between
> the two parallel methods in sync. Which leads to the question, why
have
> two independent methods for getting the exact same information? The
> only logical answer is that there are some nodes which can only use
> one of the methods. In which case the two sets of data are not
identical,
> because of these nodes, which succeeds in producing much confusion.
Not
> to mention the race conditions between keeping a centralized database
> (ATS)
> in sync with the distributed mechanism. (ARP)
> 
>   For these reasons I cringe at hearing IP address and ATS in the
> same sentence, I really wish DAT had chosen a different name for
> the addresses.
> 
>   Really, we all discussed this years ago in the IETF, the merits of
> using broadcast vs. centralized data store, and a solution was
> developed. This is why open standards bodies are so useful.
> 

Libor, I agree with most of your statements here, I also advocated to
use ARP based mechanisms in the DAT calls rather than ATS.
And our DAPL implementation enable ARP based resolution in addition to
ATS 
The one thing that ATS provide and is not possible with ARP is reverse
resolution GID->IP, any ideas how to achieve that without ATS ?

The protocols such as SDP and iSER pass the source IP address as part of
the CM REQ Private Data, so they don't really need the reverse
translation, DAT people have tried to make a generalized mechanism 

I assume James or Arkady should comment on the need for ATS and DAPL
reverse resolution

One other approach can be to provide ATS support to user applications
only, and eliminate the kDAPL support for those functions.
Also I kind of like Paul's application for thin IB clients.

> > Anyway the merits if the proposed API goes much beyond the use of
ATS,
> > so I hope we don't just hang on that one.
> 
>   Agreed, there is certainly a lot more to discuss then just ATS and
ARP.
> 

Any comments on my email explaining the forward resolution mechanisms
(IP->GID, GID->path) ?  (not relating to ATS)

Yaron

> 
> -Libor