<html>
<body>
<font size=3>At 08:16 AM 9/29/2004, Roland Dreier wrote:<br>
<blockquote type=cite class=cite cite=""> Michael>
The IETF might be able to do something here but the best<br>
Michael> that might be done is perhaps an
informational draft. Is<br>
Michael> this what is required to make forward
progress here?<br><br>
I think so. Without an IETF draft, there _will_ be
implementations<br>
that do not create a service record, and therefore interoperable<br>
implementations will have to function both in subnets without
service<br>
records and subnets with service records.</font></blockquote><br>
I'll talk with Bill about getting a draft submitted if that is consensus
and there is support for this approach.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>However, reading
back over this thread, I'm not clear on what purpose having a service
record for IPoIB serves. Why can't an implementation just look for
the IPoIB broadcast multicast groups for each P_Key to<br>
decide whether to use that P_Key?</font></blockquote><br>
Based on IETF discussions, our intent was:<br><br>
- For each partition that is enabled to support IP communication, the IP
over IB implementation should join (create if the first) the associated
"all nodes" multicast group. This is analogous to
Ethernet VLAN usage model where if allowed to communicate, one does;
hence, it isn't a decision.<br><br>
- When an endnode is enabled in the IB subnet and the IP over IB driver
is configured, it can examine the configured P_Key and communicate with
the SM/SA to determine what multicast groups are available. Based
on this information, the endnode can request to join a multicast group
thus enabling IP over IB to issue ARP / ND messages. <br><br>
- An endnode would then need to set up an event notification to
understand when partitions were updated - add or deleted - for its local
ports. The endnode would also need to know whether it is the last
member of the multicast group as well. <br><br>
The method for an admin to indicate what partitions were configured is
not defined by the IETF specs nor do I recall a method to state that a
given IB multicast group is associated with IP and hence our discussions
to date. My initial inquiry was in response to the requirement to
use a tool. I view such a tool as unnecessary as well as
non-scalable as the size of the cluster increases. Therefore, I
have suggested a method that would not require a tool. I'm quite
open to any approach as long as it avoids creating a tool as everything
can be more easily integrated into an IP over IB driver which benefits
the admin and the use of IB technology.<br><br>
Mike<br><br>
</body>
</html>