On Thu, Feb 08, 2007 at 10:23:11AM -0800, Sean Hefty wrote:
The active side clearly cannot learn what the SLID of the passive
side's router should be.
We don't want to have the routers snoop and alter CM GMPs.
The passive side cannot use information from the LRH to get the router
LID
Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a
huge PITA..
[IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID
should not be validated against the QP context since it makes it
extra hard for multipath routing and QoS to work...]
Yes - this gets messy.
On Thu, 2007-02-08 at 14:54, Sean Hefty wrote:
Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a
huge PITA..
[IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID
should not be validated against the QP context since it makes it
extra hard for multipath
At 12:39 PM 2/8/2007, Hal Rosenstock wrote:
On Thu, 2007-02-08 at 14:54, Sean Hefty wrote:
Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a
huge PITA..
[IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID
should not be validated against the QP
This requires that the passive side be able to issue path record queries, but
I
think that it could work for static routes. A point was made to me that the
remote side could be a TCA without query capabilities.
Are you referring to SA query capabilities ? Would such a device just be
expected
On Thu, 2007-02-08 at 17:02, Sean Hefty wrote:
This requires that the passive side be able to issue path record queries,
but I
think that it could work for static routes. A point was made to me that the
remote side could be a TCA without query capabilities.
Are you referring to SA query
