<html>
<body>
<font size=3>At 08:49 AM 9/29/2004, David M. Brean wrote:<br>
<blockquote type=cite class=cite cite="">The subnet management state is
protected by an M_Key (see section 14.2.4). The M_Key is managed by
the SM. The M_Key is not exposed via the Verbs or through SA
queries [the exception being the trusted entity, but that entity is
another SA or higher layer management application - so let's ignore for
this situation.] An endnode implementation should not allow
any back-door mechanism that enables changing the subnet management state
without the M_Key if the port is protected. Note, the M_Key and
protection bits can be in persistent storage and preserved across port
power cycles to eliminate the power-up exposure. So, without making
subnet assumptions/restrictions, there is no reliable way for an IB
client, like the local MAD layer, to specify the LID.<br><br>
LID assignment is SM policy and the SM may choose to preserve a port's
LID, however, I don't think IB clients should depend on this
behavior.</font></blockquote><br>
It has been the clear intent of the IBTA that LID assignment be strictly
done by the SM as centralized management is the operating paradigm
defined. It has also been clear from the start that LID values are,
by definition, dynamic and should never be preserved or relied upon by
endnodes. There is no requirement or policy that a SM should
attempt to preserve LID assignment. Given I authored addressing and
other sections of the IB specs and chaired the workgroup responsible for
the link wire protocols, I'm fairly confident that this is the intent of
the IBTA.<br><br>
Mike<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>-David<br><br>
Roland Dreier wrote:<br><br>
<blockquote type=cite class=cite cite=""> David> Ok.
How does the port inform the SM that it has a<br>
David> "preferred" LID?<br><br>
The port will already have a LID assigned when the SM discovers it.<br>
My understanding is that the SM is "encouraged" to preserve a
port's<br>
LID if it doesn't conflict with any other LIDs, and this is what
we're<br>
relying on.<br><br>
- Roland<br>
_______________________________________________<br>
openib-general mailing list<br>
openib-general@openib.org<br>
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">http://openib.org/mailman/listinfo/openib-general</a><br><br>
To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">http://openib.org/mailman/listinfo/openib-general</a><br>
<br>
</blockquote><br>
_______________________________________________<br>
openib-general mailing list<br>
openib-general@openib.org<br>
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">http://openib.org/mailman/listinfo/openib-general</a><br><br>
To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">http://openib.org/mailman/listinfo/openib-general</a></font></blockquote></body>
</html>