I sent a message on this topic to the IBTA several days ago, but I am still awaiting details (likely early next week).
>It should not be carried in the CM REQ. The SLID / DLID of the router >ports should be derived through local subnet SA / SM query. When a CM REQ >traverses one or more subnets there will be potentially many SLID / DLID >involved in the communication. Each router should be populating its >routing tables in order to build the new LRH attached to the GRH / CM REQ >that it is forwarding to the next hop. I'm referring to configuration of the QP, not the operation of the routers. To establish a connection, the passive side QP needs to transition from Init to RTR. As part of that transition, the modify QP verb needs as input the Destination LID of its local router. It sounds like you expect the passive side to perform an SA query to obtain its own local routing information, which would essentially invalidate the data carried in the primary and alternate path fields in the CM REQ. >From reading 12.7.11, 13.5.1, and 17.4, I do not believe that such a >requirement was expected to be placed on the passive side of a connection. The initial response I received agreed with this. >I'd need to go back but the architecture is predicated that the SM and SA >are strictly local and for security purposes their communication should >remain local. Higher level management entities built to communicate with >SM and SA are responsible for cross subnet communications without exposing >the SA or SM to direct interaction. P_Key and Q_Key management across >subnets is an example of such communication across subnets that would not >be exposed to the SA and SM. My initial thoughts are that this sounds like a good idea. It's not eliminating the need for interacting with a remote SA, so much as it abstracts it to another entity. My hope is that we can reach an agreement on the CM REQ. Depending on that, it still needs to determine if the existing SA attributes are sufficient to allow forming inter-subnet connections, and if they are, can such attributes be obtained. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
