SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: comments on draft



    
    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
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:26 2001
6315 messages in chronological order