[ofa-general] [RFC] host stack IB-to-IB router support

[Hal Rosenstock]

On Wed, 2007-03-21 at 12:33, Yaron Haviv wrote:
> > -----Original Message-----
> > From: general-bounces at lists.openfabrics.org [mailto:general-
> > bounces at lists.openfabrics.org] On Behalf Of Hal Rosenstock
> > Sent: Wednesday, March 21, 2007 1:28 PM
> > To: Michael Krause
> > Cc: general at lists.openfabrics.org
> > Subject: RE: [ofa-general] [RFC] host stack IB-to-IB router support
> > 
> > On Wed, 2007-03-21 at 10:41, Michael Krause wrote:
> > > At 07:22 AM 3/21/2007, Hal Rosenstock wrote:
> > > >The SM is subnet local but it is unclear about the SA.
> > >
> > > The SA was intended to be subnet local.
> > 
> > What about ServiceRecords ? ServiceIDs can have non local subnet scope
> > per Annex A1. That's one issue.
> > 
> 
> Hal, the fact that we have bits saying something is global vs. local 
> Doesn't mean the control plain for that needs to be in the SM/SA
> Not to mention that with OpenFabric fabric independent model ServiceIDs
> are now 16bits and map to TCP like ports  
> 
> We want to have the SM/SA be the monitoring/configuration tool for a
> specific subnet and not grant it with more authorities than it should 
> Some IB mechanisms are too centralized already, we don't want to carry
> that legacy into an inter-subnet framework unless we have to.
> 
> If there are holes in the spec that inhibit us from doing it in the
> right way (like in IP routing), we should identify them and drive them
> quickly via IBTA, after all IB usage model may have changed a bit since
> the draft was written few years ago.
> 
> 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, .. ?

It wouldn't necessarily. It is a vehicle for experimentation.

I believe there is separation of what is spec compliant and non
compliant and it allows for more flexible configurations than what can
currently be done by the current spec.

> How would that address future routing, security, QoS, .. enhancements ?
> can it ? 

It can evolve but the controversial part of this was meant for more
flexible configurations for experimentation.

-- Hal

> Yaron