|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Canonical TargetsActually, that's a good point about the multiple target names. If a host is allowed to use a target without learning its name, it has two problems: 1. If it has multiple targets with the name "iscsi", it will not know whether they are multiple targets, or multiple addresses for the same target. 2. If the target's IP address changes, it will not be able to tell whether a newly-discovered target is the same target at a new address, or a new target. Given these, I think there is too much danger in allowing a host not to learn the actual name of a target. Also, Jim is correct about discovery being a one-time thing; after the first time a host has connected, it will probably squirrel the iSCSI name away in a config file or registry somewhere anyway, so it knows where to look for its disks, and which /dev entries to map them to the next time it boots. Jim Hafner wrote: > > Mark and Steph, > > I guess I'm having trouble understanding the issues here. We seem to be > moving toward three types of iSCSI targets: > 1) one for discovery only, suitable for login only by authenticated > initiators, i.e., a one-sided authentication, but ONLY for the purposes of > SendTargets. > 2) one "nameless" target ("iSCSI"), again suitable for login only by > authenticated initiators, i.e., a one-sided authentication, but used for > real SCSI stuff > 3) all other "named" targets, that may or may not require two-sided > authentication, but are used for real SCSI stuff. > > Frankly, I think I see no real need for the second one (a SCSI-functional > thing with no true name). The third one can perform the function of the > second one if the initiator doesn't bother to authenticate the target's > name (provided it has a straightforward way to get the name). The first > one was what we were moving to as the functional use of the "iSCSI" target. > The only value I see is that the initiator doesn't have to find the name > first. But the target will need to "correct" that name in response anyway > (at which point it has a name which it can use for all other sessions) -- > it could/should be a one time deal, probably, to go through the discovery > (SendTargets) step. I don't think we really want the host to think that it > has any number of real targets all named "iSCSI"! > > Jim Hafner > > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 05-16-2001 12:14:35 PM > > Sent by: owner-ips@ece.cmu.edu > > To: Stephen Bailey <steph@cs.uchicago.edu> > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Canonical Targets > > That kind of makes sense. If we limit SendTargets to the discovery > session, and disallow SCSI commands to the discovery session, then > we really don't have a target at all from SCSI's point of view; but > we do have a "special" target from iSCSI's point of view since we > are doing the full login to it. > > So if we used > > TargetName= > > we would get the discovery target; if we used > > TargetName=iSCSI # Note: this is case-insensitive > > we would get whatever default target the iSCSI device wanted > our initiator to see. Even if we do end up supporting both, I > guess I'd rather see a target name, rather than leaving it > blank. How about > > TargetName=discovery > > BTW, nobody else has spoken up for having this default target > that would avoid having to use SendTargets if there were not > multiple targets available to an initiator. > > Who plans to make use of this? I don't mind putting it in > (we had sort of implied the functionality before), but if > it is not in anyone's plans, I'd rather go for a simpler spec. > > Stephen Bailey wrote: > > > > > Any other ideas? > > > > My suggestion was to not supply any target name for a discovery login > > (which is how a discovery login would be distinguished) and call > > `iSCSI' the `default' (operational) target. > > > > Steph > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054
Home Last updated: Tue Sep 04 01:04:41 2001 6315 messages in chronological order |