<html>
<body>
<font size=3>At 01:05 PM 9/29/2004, you wrote:<br>
<blockquote type=cite class=cite cite="">On Wed, 2004-09-29 at 13:46,
Michael Krause wrote: <br>
> In what I was proposing, the change in IP service being provided for
a<br>
> given partition would result in a service event notification.
You are<br>
> correct that unless an endnode periodically examines its P_Key
table<br>
> per port for change, there is no method to know that an admin
has<br>
> effected a change in the partition space. The IP service with
event<br>
> notification would provide this state change as a service
event.<br><br>
Are you saying that when a particular service record is created in
the<br>
SA, an event is generated to a set of interested endnodes ? I don't<br>
think there is a way to do that. The only choice is for the endnode
<br>
to continue to poll the service records based on the matching
criteria<br>
which we would need to define (ServiceID or name
perhaps).</font></blockquote><br>
A proposal would be reflected in an ECR that basically re-used the trap
event notification method to return status indicating service state has
changed. In this case, it would be the addition / deletion of a partition
that supported the IP service.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>> It isn't
required that an endnode leave but if there is one around to<br>
> listen, why remain in the multicast group.<br><br>
I don't think there is a way to tell a node is the last (full) member
of<br>
the group. Anyhow, if this were done, how would that node know to
rejoin<br>
once another node came along ?</blockquote><br>
The SM knows this and could simply delete the group. It isn't
important to have happen as most fabrics will have at least one IP
service partition running with multiple members.<br><br>
Mike</font></body>
</html>