<html>
<body>
<font size=3>At 10:26 AM 9/29/2004, you wrote:<br>
<blockquote type=cite class=cite cite="">On Wed, 2004-09-29 at 12:48,
Michael Krause wrote:<br>
> Based on IETF discussions, our intent was:<br>
> <br>
> - For each partition that is enabled to support IP communication,
the<br>
> IP over IB implementation should join (create if the first)
the<br>
> associated "all nodes" multicast group. This is
analogous to Ethernet<br>
> VLAN usage model where if allowed to communicate, one does; hence,
it<br>
> isn't a decision.<br><br>
There is the "limited" broadcast group from which the
parameters would<br>
be derived for joining the "all nodes" multicast group
(224.0.0.1).</font></blockquote><br>
Correct.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>> - When an
endnode is enabled in the IB subnet and the IP over IB<br>
> driver is configured, it can examine the configured P_Key and<br>
> communicate with the SM/SA to determine what multicast groups
are<br>
> available. Based on this information, the endnode can request
to join<br>
> a multicast group thus enabling IP over IB to issue ARP / ND<br>
> messages. <br><br>
I don't understand the last sentence of this. For a partition that
an<br>
IPoIB interface is on (which is one of the IB port's partitions),
all<br>
the relevant multicast groups can be obtained from the SA but what
does<br>
this have to do with enabling "ARP/ND". Doesn't the broadcast
group<br>
creation/join take care of ARP ?</font></blockquote><br>
Apologies for my sentence structure. Yes. <br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>> - An endnode
would then need to set up an event notification to<br>
> understand when partitions were updated - add or deleted - for
its<br>
> local ports. <br><br>
Unfortunately, there is no local partition table changed event defined in
IBA.</font></blockquote><br>
In what I was proposing, the change in IP service being provided for a
given partition would result in a service event notification. You
are correct that unless an endnode periodically examines its P_Key table
per port for change, there is no method to know that an admin has
effected a change in the partition space. The IP service with event
notification would provide this state change as a service
event.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>> The endnode
would also need to know whether it is the last member of<br>
> the multicast group as well.<br><br>
Not sure why this is needed by the endnode. I presume you are
referring<br>
to the last full member. The group is deleted when the last full
member<br>
leaves the group.</blockquote><br>
It isn't required that an endnode leave but if there is one around to
listen, why remain in the multicast group.<br><br>
Mike</font></body>
</html>