[openib-general] IB routing discussion summary

[Michael Krause]

I do not see the need for any of this.   The router protocol should be 
designed to work with each subnet's SM / SA to provide information on what 
GID prefix is on each router Port.  This is used to look up the subnet 
local LRH fields.

The only cross-subnet challenges are global based, e.g. what is the P_Key 
to use and how to manage those across subnets or how should TClass be 
interpreted to achieve a consistent behavior independent of how the TClass 
is subnet local mapped to a SL.    These were the types of challenges 
remaining when we stopped development of the router specification.   If the 
IBTA decides to develop a router specification then it might be best to 
join that effort and work it out in detail before attempting to develop the 
management infrastructure.  May be able to slightly lag in order to 
validate the technical directions that the spec will take without having to 
wait until 1.0 to say, yep, this looks good or here is where you need to 
change the spec.   Not clear what can be developed until there is a router 
specification to execute to in the industry.

Mike


At 01:17 PM 2/13/2007, Sean Hefty wrote:
>Here's a first take at summarizing the IB routing discussion.
>
>The following spec references are noted:
>
>9.6.1.5 C9-54. The SLID shall be validated (for connected QPs).
>12.7.11. CM REQ Local Port LID - is LID of remote router.
>13.5.4: Defines reversible paths.
>
>The main discussion point centered on trying to meet 9.6.1.5 C9-54.  This
>requires that the forward and reverse data flows between two QPs traverse the
>same router LID on both subnets.  The idea was made to try to eliminate this
>compliance statement for packets carrying a GRH, but this is viewed as going
>against the spirit of IBA.
>
>Ideas were presented around trying to construct an 'inter-subnet path record'
>that contained the following:
>
>    - Side A GRH.SGID = active side's Port GID
>    - Side A GRH.DGID = passive side's Port GID
>    - Side A LRH.SLID = any active side's port LID
>    - Side A LRH.DLID = A subnet router
>    - Side A LRH.SL   = SL to A subnet router
>
>    - Side B GRH.SGID = Side A GRH.DGID
>    - Side B GRH.DGID = Side A GRH.SGID
>    - Side B LRH.SLID = any passive side's port LID
>    - Side B LRH.DLID = B subnet router
>    - Side B LRH.SL   = SL to B subnet router
>
>It is still unclear how such a record can be constructed.  But communication
>with remote SAs might be achieved by using a well-known GID suffix.  It's also
>unclear whether the fields in a path record are relative to the SA's subnet or
>the SGID.
>
>It's anticipated that SAs will need to interact with routers, but in an
>unspecified manner.