[ofa-general] [RFC] host stack IB-to-IB router support
Michael Krause
krause at cup.hp.com
Wed Mar 21 12:09:24 PDT 2007
At 10:51 AM 3/21/2007, Sean Hefty wrote:
>>Ok, lets assume Sean would finish his experiments with remote_sa, how
>>would that find its way into the commercial sm/sa versions that are
>>mostly used, how would we guarantee interoperability between all
>>implementations, .. ?
>>How would that address future routing, security, QoS, .. enhancements ?
>>can it ?
>
>The 'remote sa' as simply a proprietary UD protocol. Whatever data two
>'remote sa' services exchange shouldn't matter, nor should the fact that
>each issues local SA path records. There's nothing magical about this.
>
>If I have an app that can query its local SA, there's nothing that
>prevents that app from sending that data to whatever peer it can connect
>to. It can even send the data over TCP if it wants. Keeping the SA
>subnet local doesn't add any real security.
>
>Coming up with a solution that doesn't work with any existing hardware,
>targets, and SAs isn't very useful.
Just to clarify:
- Nothing in the router protocol should have an impact on existing or even
future hardware if done right. The basic wire protocol, i.e. the use of
GRH, etc. should not require any modifications to operate on existing hardware.
- Whether a HCA or a TCA, there will be some level of management protocol
changes. This impacts the software above but not the hardware itself
unless the implementation hard-coded / state machined its behavior in which
case it is unlikely to work in any router environment.
- For the SA, I think most will agree that there will be implementation
changes required to comprehend where a router exists on a subnet and how to
respond to queries that target a router. However, much of what I've noted
here does not impact existing SA or SM operations - they continue to work
as implemented. The changes proposed would be new additional capabilities
that would enable router communication to occur. If people construct
something like a DNS equivalent service to find the IB router, then this
leverages the practices used with IP today and the more IB looks like IP
when it comes to its operation, the easier it is to get it actually
deployed beyond the HPC market.
None of these items breaks or changes interoperability among any components.
Again, I don't see any harm in waiting until Sonoma to discuss this
face-to-face. Quite true that no major breakthroughs are likely but the
benefits of plowing ahead with an implementation that may be viewed as an
academic or a niche experiment does not seem worthwhile. However, people
are free to spend their time as they desire. My only caution is such work
should not set precedence nor should there be any expectation that it will
ever see commercial adoption or deployment.
Mike
More information about the general
mailing list