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

[Hal Rosenstock]

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.

>   What is above the SM / SA were 
> left to implementation discretion but these two were intended to be 
> strictly subnet local.
> 
> >Currently, if one knows the GID of the SA, it can be contacted remotely.
> 
> One can communicate with anything that has a GID.   While it is true that 
> does not make it the right choice.
> 
> >  To support routing, there are a number of things that SA supports that I 
> > think will
> >need to be exchanged across SAs so in this sense it may not be that far
> >off in that it separates this aspect which can evolve to wherever it
> >ends up in the architecture.
> 
> The only thing one needs to comprehend are the <GID, P_Key, Q_Key> of the 
> destination.   Ideally, one would create the equivalent of a DNS service 
> agent that would operate in each subnet and provide a local look up for any 
> endnode requesting a remote's information.   The subnet local router would 
> provide information into the SM / SA to enable endnode's to comprehend 
> which router port to target their LRH structure.   The router would strip 
> the LRH and add a new one to the next hop - whether another router or the 
> destination port.    This gets you going without a lot of complexity.

> Now, if you want to add in QoS attributes to the path discovery, then there 
> are two areas to explore:
> 
> - Subnet local QoS to the subnet local router port.
> - Router protocol provided QoS information between routers.
> 
> The first just uses the existing infrastructure.   The second would be new 
> and part of the router protocol to populate the SM/SA.   If one associated 
> a given GID prefix with one or more QoS attributes, then the source can 
> make intelligent decisions without requiring any remote SA involvement.
> 
> >It is a temporary measure to get by with the lack of specificity in the 
> >routing space. As you can see, there is an immediate need within 
> >OpenFabrics to resolve these issues or at least take an experimental stab 
> >at them so more IB router protoyping can be done.
> 
> Caution is recommended.   If the IBTA can get its act together on the 
> basics in a reasonable amount of time then the legacy problem can be 
> avoided entirely.  If not, well, customers have to make choice points, test 
> matrix get larger, etc.    Waiting until Sonoma isn't going to kill anyone 
> and may provide better insight into what should be specified in the interim 
> between now and the IBTA getting its act together.

That would be nice (and I wish it were otherwise) but I do not expect
that solutions/directions sufficient for an implementation will be
coming out of the Sonoma discussions.

-- Hal

> Mike
> 
> 
> >-- Hal
> >
> > > > I agree with you that this is not a good place to be, but with current
> > > > hardware I think we are stuck with it..
> > >
> > > I do not think so (with my ib hw asic vendor hat on).
> > >
> > > >
> > > > Regards,
> > > > Jason
> > > > _______________________________________________
> > > > general mailing list
> > > > general at lists.openfabrics.org
> > > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> > > >
> > > > To unsubscribe, please visit
> > > http://openib.org/mailman/listinfo/openib-
> > > > general
> > > _______________________________________________
> > > general mailing list
> > > general at lists.openfabrics.org
> > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> > >
> > > To unsubscribe, please visit 
> > http://openib.org/mailman/listinfo/openib-general
> >
> >_______________________________________________
> >general mailing list
> >general at lists.openfabrics.org
> >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> >
> >To unsubscribe, please visit 
> >http://openib.org/mailman/listinfo/openib-general
> 
>