|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Canonical TargetsSteph, One argument for SendTargets on non-canonical targets would be the following (and might help address your iterator concerns). A canonical target *could* respond to SendTargets with list of actual targets but only provide a partial list of addressess and ports (an abbreviated list). Then each actual target could respond to SendTargets with just itself in its list and its complete list of all addresses and ports it responds to. This gives a heirarchical local discovery mechanism. N&DT hasn't fully scoped these issues, which is why this discussion was started. I don't think there is a requirement in what Mark wrote that the response to SendTargets to any target (canonical or actual) has to report complete knowledge of everything known to that box. I have a question for you (and the list) about a long Text response (as might be needed for SendTargets). Can the Text response come in multiple PDUs? In particular, can one "key=value" pair span multiple PDUs? If so (for either question), what exactly is the spec'ed method? And if so, does this help address your resources concerns? (The target can send the response is chunks.) Jim Hafner Stephen Bailey <steph@cs.uchicago.edu>@ece.cmu.edu on 05-13-2001 07:54:28 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Canonical Targets Mark, This is mostly fine with me. However, I KNOW implementors are going to gripe about having to know the target name before performing an operational login. In general, the spec seems a bit capricious about when implementors just have to suck it up and do the hard thing, versus when we try to make it easy for them. Realistically, it's not a big deal to learn the name (just an extra login), but most end points are going to have a single target, and from a configuration standpoint endpoint (and, hence the target) is going to be specified by transport coordinates (address, port). This extra login for discovery is simply an irritant. Also, I think this part still needs a little more specification work: > 6. We can further specify the order in which the SendTargets response > fields are returned, to simplify things further, e.g. each target > in the SendTargets response MUST return these fields in this order: > > - A TargetName= field > - A TargetAlias= field (value left blank if there's no alias) > - One or more TargetAddress= fields > - Any vendor-specific fields (ignored by standard initiators) I can only guess that you are implying that target descriptions following this rule may be tiled arbitrarily into Text PDUs returned from the target? If so, we should specify that. > 1. Should a non-canonical target respond to a SendTargets command? I'd say no. Given the nature of the interaction, why bother? Now, I know the iSCSI philosophy seems to be `if it's not complete gibberish, why NOT bother?' but that results in complicated implementation. Specifically, each end (target and initiator) should be able to audit the other for correctness when possible. Hard rules like `thou shalt not issue a SendTargets in an operational session' make the auditing a zillion times easier. To this end, I would go a step further and allow only a single outstanding SendTargets exchange in a target discovery session. Steph
Home Last updated: Tue Sep 04 01:04:43 2001 6315 messages in chronological order |