<html>
<body>
<font size=3>At 06:24 AM 9/30/2005, Yaron Haviv wrote:<br>
<blockquote type=cite class=cite cite="">> -----Original
Message-----<br>
> From: Roland Dreier
[<a href="mailto:rolandd@cisco.com" eudora="autourl">
mailto:rolandd@cisco.com</a>]<br>
> Sent: Thursday, September 29, 2005 9:50 PM<br>
> To: Sean Hefty<br>
> Cc: Yaron Haviv; Openib<br>
> Subject: Re: [openib-general] [RFC] IB address translation using
ARP<br>
> <br>
> I think the usage model is the following: you have some magic
device<br>
> that has an IB port on one side and "something else" on
the other<br>
> side. Think of something like a gateway that talks SDP on the
IB side<br>
> and TCP/IP on the other side.<br>
> <br><br>
Also applicable to two IB ports, e.g. forwarding SDP traffic from one
IB<br>
partition to SDP on another partition (may even be the same port
with<br>
two P_Keys), and doing some load-balancing or traffic management in<br>
between, overall there are many use cases for that. </blockquote><br>
While I can envision how an endpoint could communicate with another in
separate partitions, doing so really violates the spirit of the
partitioning where endpoints must be in the same partition in order to
see one another and communicate. Attempting to create an
intermediary who has insights into both and then somehow is able to
communicate how to find one another using some proprietary (can't be
through standards that I can think of) method, seems like way too much
complexity to be worth it.<br><br>
Mike</font></body>
</html>