Re: iSCSI: comments on draft

["Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>]

Julo,

My comments in-line and the rest clipped.

Jim Hafner


julian_satran@il.ibm.com@ece.cmu.edu on 11-12-2000 10:38:19 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: comments on draft





Jim,

Thanks for your careful reading.


On most of the editorial changes I will not comment here - I will correct
as much as I can
up to the end of next week.

Some non-editorial comments:

   timers - I am aware that they are not a proper protocol issue as they
   don't appear on the wire. They are somewhat similar to TCP timers.  The
   intent was to help gateways to FCP do some stateless recovery.  I think
   we should consider them carefully and decide how many of them we want,
   if the values have to be agreed by initiator and target (I had a private
   mail suggesting that) or that, in extremis, we can live without them at
   all (as Matt suggested).  If we include them we have to make their
   implementation mandatory -   if gateway recovery can't assume they are
   implemented then they are worthless.
   At connection termination the finish was meant to convey "wait until
   they finish" - I did not  mean abort.  I will try a formulation that
   clearly expresses this intent.
<JIM>
With respect to this an other related explicit or implicit logouts, a table
analagous to Table 4 of FCP2 (r04b) "Clearing effects of link related
functions" would be very useful.
</JIM>
   On Bidi as I said in a previous note - I am still considering how to fit
   it in
   On the AE for abort - it was optional and I heard a strong voice for
   making it mandatory (of the sort we call in this group consensus) so I
   did.  I personally consider that a check condition and ACA are required
   anyhow and AE will give you the "management trigger" for initiators
   otherwise idle.
<JIM>
I personally think that mandatory AE is not a good idea particularly under
the conditions mentioned here (commands aborted by other initiators).
Besides the problem with interfering with the new SCSI Status, I suspect
that no OS SCSI layers have any idea what to do with it (though I suppose
the iSCSI layer could deal with).
</JIM>
   Loging Resets - the place IP devices today log is in MIB that can be
   retrieved through SNMP.  I will try to clarify this - but I will not
   make any specific reference to a MIB field as this group has not yet
   work on the proposed MIB
   LUN or Reserved in data out.    The LUN is required for solicited data
   as the target task tag is not required to be unique target-wide.  I will
   attempt to spell it out.
   The 8 byte descriptors apply to the unmap function I will try to spell
   it out.
   The purpose of map and unmap is to enable target addressing in all IP
   formats in binary as well as DNS style formats. When T10 will have it we
   can make the commands obsolete.
<JIM>
And I'm suggesting that this should be removed now to avoid confusion
later.  It's actually quite difficult to make things obsolete.  I'm
probably going to personally take up the banner of getting this function
into SCSI and hope for a resolution either in Jan. or in Mar.  It's not a
contentious issue, it has lots of support in T10, the only thing slowing it
down are (a) Ed Gardner's higher priority for SRP (aka SVP) and (b) getting
the details right.
</JIM>
   Maps implementation is a entirely up to
   the target. However values mapped are assumed to be persistent until
   unmapped.    In the text I a working on I state that no third party
   address can be used if it was not mapped and appropriate error will be
   returned if this rule is violated or the target has lost the maps due to
   a power down or reset.
<JIM>
This disagrees with your statement above that they are persistent until
unmapped.  In SCSI, "persistent" means survives power-cycles."
You don't specify the "appropriate error" in case an SRA is not known to
the target (i.e., is currently not mapped).
</JIM>
   As for proxy tokens - how are they covered in
   third party commands?
<JIM>
I've explained that proxy tokens are references to logical units, not
target devices.  I've also tried to explain that all this is handled by
approved changes to EXTENDED COPY as described in t10/99-245r9 and slated
for insertion in SPC-3.
</JIM>
   I will clean-up a bit the wording and will add a
   statement about table reset. However the mechanisms used by the  target
   to implement the mapping and to keep it are implementation specific. The
   clarification we have to add is that SRAs are guaranteed walid only on a
   given session (you are not supposed to hand them from initiator to
   initiator) bu the target is not required to check the SRA ownership
   validity
<JIM>
How can they be valid only in a given session but the target not be
required to check SRA ownership?  What happens if to initiators just manage
to request mappings for the same SRA?  This is either an error (i.e., when
SRAs are global over all initiators) or requires the target to check SRA
ownership (which you don't claim is required).

As I mentioned, I never could figure out where the SRA was in the parameter
data; additionally, I don't see how that was going to be used in EXTENDED
COPY.  This needs to be highly integrated with EXTENDED COPY so that it
makes some sense.  What flags in EXTENDED COPY target descriptors suggest
looking in the map table to resolve the target identifier?  I know you have
words to the effect that coordination with T10 is necessary here, but I'm
suggesting it's simpler and easier just to let T10 take it all.
</JIM>
   The IP in IPsec might lead you to think that it provides only link level
   security but IPsec provides (depending on the policy) end-to-end
   security
<JIM>
This is NOT what I understood from the security experts I got my
information from. I did NOT derive my comment from the "IP" in IPsec.
</JIM>
   For errors in format we will introduce a specific sense - iSCSI format
   error
   I value your insight in SCSI working and you helping us out on this -
   and it was from this that the team realized during the drafting meeting
   in Haifa that if an OS+CPU has already a signature, the AccessID, we
   could as well use it and not invent a new one.  I don't see exactly what
   layering principles are violated here - an ID is an ID and it does not
   make sense to have 10 of them.  The principals involved are the same.  I
   can hardly understand the rest of your comment. Isn't the AccessID
   identifying the initiator to the target?  Why should we maintain
   different IDs for the same principals?  (layering is an abstraction
   techniquue that does hardly apply here )
<JIM>
Here are a few more comments:
1) the AccessID is not necessarily unique between hosts, much less between
initiators.  It is quite possible that the same AccessID is used among many
different hosts of a cluster to simplify the LUN Mapping policy.  It may be
that this doesn't matter for the security context you envision but it may
also be *critical* that there be a different security context for each host
in a cluster to enable fencing.
2) AccessIDs are NOT globally unique, they are not assigned by any naming
authority in the way that InitiatorUI's ought to be.  They are scoped only
within the domain where target LUN maps need to be managed, that is, only
in the context of a single Partition Access Management (PAM) space.
3) There is nothing to prohibit a "PAM" from using globally unique
InitiatorUIs for AccessIDs (the PAM owns that namespace and can do what it
wants), but I'm not sure the converse holds.
4) "An ID is an ID" only within the context of where it makes sense.  A MAC
is an ID but I can have 10 of them in a host and it still makes sense.
5) As I said, the target will need to make login accept/reject decisions
based on things besides AccessID (proxy token, PAM Management Identifier
Key, etc), so binding AccessID to login is not necessarily the right thing
to do.
6) Not every host is REQUIRED to have an AccessID!
</JIM>

Thanks again,
Julo