|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI: NIC interoperabilityAfter seeing some of the emails on this topic from Dave Sheehy, David Black and Jim Hafner, I have some comments and questions. It appears to me that the following three are the major issues that one has to deal with for building a multi-NIC iSCSI Node, where the NICs are potentially from different vendors. A. Each NIC MUST allow the Node name to be configurable. B. Each NIC MUST allow the ISID range to be configurable (if deployed in an initiator configuration). C. In addition, if only one (initiator/target) portal group is sought to be presented (i.e. session spanning across any and all of these NICs is a requirement), each NIC MUST allow itself to be managed by an externally-resident "session manager" in some "TBD standard way". Admittedly, C is is the hardest and till the "TBD standard way" is defined to interact with a session manager, it cannot be mandated. Failure to comply with C would only create multiple portal groups in an iSCSI implementation - each portal group limited to NIC(s) from a given vendor. But, A and B above seem reasonable and in fact seem required to be mandated - both to avoid the problems as with FC Node Name, and also to address the concerns of not leaving target with a deterministic way to enforce access control mechanisms and such. I realize that the "no duplicate nexus" goal does not strictly require A (hence neither B), but I recommend that A be mandated, thus automatically making B an additional requirement for initiator configurations. Rev08 iSCSI draft seems to refer to A and B in section 9 (implementation notes) as "should". Was there a concern about the appropriateness of mandating A and B in the main modeling discussion? They appear fairly straightforward to implement. If the reasoning was not to require _any_ configuration of an iSCSI NIC, I would argue that you require some "name" to be configurable anytime you want to build a logically monolithic entity (as in a node) from smaller components (each of which can act as a logically independent entity in its own right). Comments from NDT and/or Julian would help. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com
Home Last updated: Sat Oct 20 22:17:46 2001 7307 messages in chronological order |