Michael> The IETF might be able to do something here but the best
Michael> that might be done is perhaps an informational draft. Is
Michael> this what is required to make forward progress here?
I think so. Without an IETF draft, there _will_ be implementations
that do not create a service record, and therefore interoperable
implementations will have to function both in subnets without service
records and subnets with service records.
I'll talk with Bill about getting a draft submitted if that is consensus and there is support for this approach.
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
decide whether to use that P_Key?
Based on IETF discussions, our intent was:
- 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.
- 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.
- 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.
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.
Mike
_______________________________________________ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
