<html>
<body>
<font size=3>At 07:24 PM 9/29/2004, Fab Tillier wrote:<br>
<blockquote type=cite class=cite cite="">> From: Michael Krause
[<a href="mailto:krause@cup.hp.com" eudora="autourl">mailto:krause@cup.hp.com</a>]<br>
> Sent: Wednesday, September 29, 2004 5:50 PM<br>
> <br>
> The SM is the only entity that is supposed to assign LID as well as
the<br>
> subnet prefix. The SM should not trust any CA / switch
configuration if<br>
> it has not configured it thus should wipe it out and replace it with
what<br>
> it deems best. As for the subnet merge problem, until the
M_Key is sorted<br>
> out, reassignment isn't an issue per se.<br><br>
In the case where the SM crashes or is stopped and then restated and
there<br>
is no failover SM, resetting all LIDs seems rather drastic. Even
the case<br>
where the SM is stopped, upgraded, and then restarted need to account
for<br>
situations where the fabric as configured by the previous SM, while
fully<br>
functional, followed a different algorithm than the updated SM
code. I<br>
don't see how an SM can distinguish between a LID assigned by a
"micro-SM"<br>
embedded on every host system and one assigned by a previous
incarnation.<br>
Resetting every assigned LID just because it can't be trusted would be
quite<br>
disruptive IMO. If a CA/switch configuration does not cause
problems, the<br>
SM should do its best to keep things from changing so as to minimize
the<br>
impact of SM disruptions on overall fabric operation.</blockquote><br>
Examine the purpose and associated specification text regarding the
M_Key. The SM can distinguish between a locally assigned value and
one it assigned through the use of the M_Key. If the SM is also
reasonably robust, it would also implement a SM database to understand
what CA / switch exist in the fabric, how addressing was assigned, SL /
VL arbitration, etc. The SM is supposed to be smart and thus should
enable recovery.<br><br>
As for resetting because it cannot be trusted, that is exactly what the
IBTA intended. If in doubt, then reset the values so that one does
not violate the objective of partitioning and the defined trust
domains. This is no different in desire than the growing use of
802.1x for Ethernet fabric login. Customers want to know that the
components that are communicating have been properly identified and
configured to communicate within a defined partition / trust
domain. If any component is blindly trusted, then that puts the
fabric and other components at risk. <br><br>
Mike</font></body>
</html>