[openib-general] IB routing discussion summary

[Michael Krause]

At 02:05 PM 2/15/2007, Sean Hefty wrote:
>>Is this first an IBTA problem to solve if you believe there is a problem?
>
>Based on my interpretation, I do not believe that there's an error in the 
>architecture.  It seems consistent.  Additional clarification of what 
>PathRecord fields mean when the GIDs are on different subnets may be 
>needed, and a change to the architecture may make things easier to 
>implement, but that's a separate matter.
>
>>I contend CM does not require anything that is subnet local other than to
>>target a given router port which should be derived from local SM/SA only
>
>Then please state how the passive side obtains the information (e.g. 
>SLID/DLID) it needs in order to configure its QP.  I claim that 
>information is carried in the CM REQ.

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.


>The alternatives that I see are:
>
>1. The passive side extracts the data from the LRH that carries the CM REQ.
>2. The passive side issues its own local path record query.
>
>Will you please clarify where this information comes from?

The router protocol determines path to the next hop.   As noted in prior 
e-mails, the router works in conjunction with the SM/SA to populate its 
database so that any CM or other query for a path record to get to / from 
the router can be derived and optimized based on local policy, e.g. QoS, 
within each subnet.


>>I will further state that SA-SA communication sans perhaps a
>>P_Key / Q_Key service lookup should be avoided wherever possible.
>
>I agree - which is why my proposal avoided SA-SA communication.  I see 
>nothing in the architecture that prohibits a node from querying an SA that 
>is not on its local subnet.

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.

Mike