|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: login issue - partial consensus callEddy, I believe you have this wrong. The iSCSI Initiator Node Name comes from the OS, NOT the HBA. The iSCSI Initiator function is suppose to use the same iSCSI Initiator Node Name as that was assigned to the OS. The OS is suppose to have some method to send to the iSCSI HBA, the iSCSI Initiator Node Name so that it can configure itself to use that Name. If this was not True then the Authentication would be based on the Adapter interface, as it is in FC, instead of the OS. We did not want the administrator to have to know about all those HBAs, only names associated with OSs. By the way, the OS is also suppose to have a way to hand out (partition up) ISIDs to the various iSCSI Initiator functions, whether they are Software or Hardware. So, even though, I was initially swayed by Nick's Arguments -- we require the OS to partition up the ISID space and hand out specific ISIDs or ranges of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of whether they are in Software or Hardware) -- I do not now see, if the implementation is as specified in our spec., how there is a conflict in ISID. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Eddy Quicksall" <eddy_quicksall@ivivity.com>@ece.cmu.edu on 09/06/2001 07:56:50 AM Please respond to <eddy_quicksall@ivivity.com> Sent by: owner-ips@ece.cmu.edu To: <Nick.Martin@compaq.com>, <ips@ece.cmu.edu> cc: Subject: RE: iSCSI: login issue - partial consensus call But wouldn't the two different vendors you mention below have different iSCSI Initiator Names? Remember, the Initiator is not the host, it is the HBA in this case. If two different HBA's are going to play together then a common driver would be used and the driver would provide the iSCSI Initiator Name. Then, the ISID would be properly maintained by the driver. Think of the Initiator Name as the owner of the ISID's for that name. Eddy -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, September 05, 2001 5:50 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Marj, You mention vendors not knowing how to play right. The problem is that iSCSI does not and will not specify how two HBAs from different vendors installed in the same Initiator should or could get a range of ISIDs for their exclusive use. This will be operating system specific and vendor defined. It is uncertain that the same tool or repository would be used by all HBA vendors in any environment. Given this, accidental overlap in ISID space is not unlikely. Given that there is no one way to play right, we must make sure that everyone can at least play nice. My expectation is that sessions are infrequently established and long lived. ISIDs may be re-used at will by their current owners. When no "already owned" ISIDs are available, or an attempt to re-use an "already owned" ISID failed, and HBA would need to a) "probe" for a new available ISID or b) fail the request to establish the session. Session recovery should not be attempted unless a session is known to have failed. If tools are available, and the administrator has used them correctly, then HBAs will not collide in ISID space. If the tools are not available or were not used correctly, I would hope the second HBA can still attempt to come up without impacting the sessions established by the first. Again, I state my support for a login with existing ISID harmlessly fails (the Target state does not change) unless a session recovery indicator is set. Also if a session recovery indicator is set, and the ISID is not in use (by this Initiator at this Target), the login also fails. Thanks, Nick -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Friday, August 31, 2001 12:09 PM To: Martin, Nick; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call > In particular this enables independent agents within the same initiator to > attempt a login without knowing all ISIDs in use by other agents. Each > agent would know the ISID of sessions it had successfully established, but > not the ISIDs for sessions established by others. It can use the ISIDs it > knows to recover sessions it owns. If an agent gets a failure attempting to > establish a new session, it would pick a different ISID and > retry (or just quit), rather than disrupting a session of another agent. The intent of the presentation on SCSI/iSCSI modeling, and the text in the draft, is to illustrate how this example is not a recommended implementation choice due to the probability of violating the SCSI/iSCSI rules pointed out. If the "independant agents" had partitioned the ISID space, there would be no collision on login and no time wasted. Your illustrated implementation could spend significant time "trying" ISID's in use by the "other agents". However, I'm starting to have more sympathy with Julian's concerns due to the apparent risks of different vendors' initiator implementations not following the rules. I just imagined having vendor A's HBA installed and happily servicing applications, installing vendor B's "plug-n-play" implementation, and having all A's sessions aborted cause B doesn't know how to play right :-( Marj
Home Last updated: Thu Sep 06 15:17:04 2001 6384 messages in chronological order |