SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Canonical Targets



    Stephen Bailey wrote:
    > 
    > 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.
    
    True; it is an extra login.  In actual use, however, an initiator might
    be configured with the IP address of a target to use, and it would have
    to do the extra session after the SendTargets.  Once the initiator has
    discovered the actual iSCSI name of the target, it will probably have to
    keep it in a registry or configuration file anyway, since it will need to
    look for it next time it boots.  Some operating systems are particularly
    fussy about making the same LUs map to the same /dev entries, and so on,
    and the only way to make them appear in the same place every time is to
    keep track.  Given this, it is not always effective to just discover by
    address after the first use of a device.
    
    You had mentioned in the interim meeting that we could provide a separate
    "default" target (different from the canonical target), that would represent
    the only target of a single-target device, and could be logged into without
    having to know its name.  This would make these devices simpler, but an
    initiator would still need to have the functionality to handle multiple-
    target devices anyway.
    
    I also don't think that there will be a lot of single-target devices out
    there, at least not right away.  Most devices will likely be accessed through
    iSCSI-FC or iSCSI-SCSI gateways in the near future, before iSCSI interfaces are
    added to the devices themselves.  Our gateway, for example, provides more
    than one target; my guess is that others will do the same.  In this case,
    an initiator has to deal with multiple targets anyway.
    
    
    > 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.
    
    That's pretty much what it does now; I was trying to specify it a little
    tighter.  Do you have any suggestions?
    
    > > 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.
    
    I'm leaning that way as well.
    
    > To this end, I would go a step further and allow only a single
    > outstanding SendTargets exchange in a target discovery session.
    
    That's a good idea; I can't imagine a reason that the initiator would
    want to do this more than once in a session, and it would be nice for
    a target to know it can reject a SendTargets command if it already has
    one outstanding on the same session.
    
    > Steph
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    


Home

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