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 > > > > [email protected] > > > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > > > > > > > To unsubscribe, please visit > > > http://openib.org/mailman/listinfo/openib- > > > > general > > > _______________________________________________ > > > general mailing list > > > [email protected] > > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > > > > > To unsubscribe, please visit > > http://openib.org/mailman/listinfo/openib-general > > > >_______________________________________________ > >general mailing list > >[email protected] > >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > > >To unsubscribe, please visit > >http://openib.org/mailman/listinfo/openib-general > > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
