Michael> It was not specified due to the lack of standards for
Michael> higher-level service management which partitioning is
Michael> classified. Given there is an OpenSM effort in flight
Michael> and the Service ID spec is already in existence, it isn't
Michael> that tough to acquire an IP service ID (or any other
Michael> protocol that one wants to support) and implement a
Michael> solution along the lines that I describe above. This
Michael> would lead to a more dynamic environment while reducing
Michael> the impact to the administrator.
This scheme might indeed be reasonable. However, given the absence of
an IBTA spec or IETF draft, I don't see how we can rely on it in our
IPoIB driver right now.
The IBTA defined the specifications to establish standard wire protocols to discover services without having to track all potential services. The IETF does not address how P_Keys are managed only that the IP over IB component must follow a set of semantics / operations to enable IP communication; all IB-specific management issues are outside the scope of the drafts.
As another person put it - embrace and extend. The approach being advocated is something that will be interoperable and provides a solution that can be easily incorporated into all IP over IB implementations. It also clarifies the ambiguous IB - admin management interactions for IP communications.
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
