SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: login issue - partial consensus call


    • To: <eddy_quicksall@ivivity.com>, <ips@ece.cmu.edu>
    • Subject: RE: iSCSI: login issue - partial consensus call
    • From: "Martin, Nick" <Nick.Martin@compaq.com>
    • Date: Thu, 6 Sep 2001 13:46:47 -0500
    • content-class: urn:content-classes:message
    • Content-Transfer-Encoding: 8bit
    • Content-Type: text/plain;charset="iso-8859-1"
    • Sender: owner-ips@ece.cmu.edu
    • Thread-Index: AcE25DrhUcXvbqLWEdWqmgBQiwLxogAA/rFg
    • Thread-Topic: iSCSI: login issue - partial consensus call

    Eddy,
    
    Yes, two HBAs in the same host could have different initiator names, but
    are they really separate initiators?  It is likely that they could
    provide two paths to the same target.  Perhaps one is an HBA and the
    other is a software stack on a standard NIC.  Must they have separate
    access rights?  Should the target have to maintain their identities
    separately?  If all HBAs within a system share the same InitiatorName,
    they can be used interchangeably for path fail-over.  If they do not,
    then the target will need to maintain separate access rights for each
    HBA within the same system.
    
    I agree, that if they have different InitiatorName they can not have
    ISID collisions, so there is no issue.
    
    If they do share a common InitiatorName, can they peacefully co-exist in
    the same ISID space within the protocol?  Can they establish sessions
    with a common target without stepping on each other, and also without
    requiring a common host based mechanism for partitioning the ISID space?
    
    Today in Fibre Channel, permissions at the target are generally
    administered using the unique WWUID of each HBA.  A host with multiple
    HBAs must have permissions for each HBA to access the same storage or
    identically wired HBAs still do not have identical privileges.  I hoped
    that with iSCSI InitiatorName was identifying the host, not the HBA so
    that identical permissions would normally be granted to all HBAs within
    a single host.
    
    Probably I have missed the point somewhere.  Perhaps this what
    "AccessID" is for?
    
    If no two HBAs (even in the same host) will share the same
    InitiatorName, then their ISID spaces are not shared.  Even software
    only iSCSI stacks must then invent unique InitiatorName.  The remaining
    reason to maintain a difference between recovery login and initial login
    would be ... I'm not sure.  
    
    Thanks,
    Nick
    -----Original Message-----
    From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
    Sent: Thursday, September 06, 2001 9:57 AM
    To: Martin, Nick; ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    But wouldn't the two different vendors you mention below have different
    iSCSI Initiator Names? Remember, the Initiator is not the host, it is
    the
    HBA in this case.
    
    If two different HBA's are going to play together then a common driver
    would
    be used and the driver would provide the iSCSI Initiator Name. Then, the
    ISID would be properly maintained by the driver.
    
    Think of the Initiator Name as the owner of the ISID's for that name.
    
    Eddy
    
    -----Original Message-----
    From: Martin, Nick [mailto:Nick.Martin@compaq.com]
    Sent: Wednesday, September 05, 2001 5:50 PM
    To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    Marj,
    
    You mention vendors not knowing how to play right.
    The problem is that iSCSI does not and will not specify how two HBAs
    from different vendors installed in the same Initiator should or could
    get a range of ISIDs for their exclusive use.  This will be operating
    system specific and vendor defined.  It is uncertain that the same tool
    or repository would be used by all HBA vendors in any environment.
    Given this, accidental overlap in ISID space is not unlikely.
    
    Given that there is no one way to play right, we must make sure that
    everyone can at least play nice.
    
    My expectation is that sessions are infrequently established and long
    lived.  ISIDs may be re-used at will by their current owners.  When no
    "already owned" ISIDs are available, or an attempt to re-use an "already
    owned" ISID failed, and HBA would need to a) "probe" for a new available
    ISID or b) fail the request to establish the session.  Session recovery
    should not be attempted unless a session is known to have failed.
    
    If tools are available, and the administrator has used them correctly,
    then HBAs will not collide in ISID space.  If the tools are not
    available or were not used correctly, I would hope the second HBA can
    still attempt to come up without impacting the sessions established by
    the first.
    
    Again, I state my support for a login with existing ISID harmlessly
    fails (the Target state does not change) unless a session recovery
    indicator is set.  Also if a session recovery indicator is set, and the
    ISID is not in use (by this Initiator at this Target), the login also
    fails.
    
    Thanks,
    Nick
    -----Original Message-----
    From: KRUEGER,MARJORIE (HP-Roseville,ex1)
    [mailto:marjorie_krueger@hp.com]
    Sent: Friday, August 31, 2001 12:09 PM
    To: Martin, Nick; ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    > In particular this enables independent agents within the same
    initiator to
    > attempt a login without knowing all ISIDs in use by other agents.
    Each
    > agent would know the ISID of sessions it had successfully
    established,
    but
    > not the ISIDs for sessions established by others.  It can use the
    ISIDs it
    > knows to recover sessions it owns.  If an agent gets a  failure
    attempting
    to
    > establish a new session, it would pick a different ISID and
    > retry (or just quit), rather than disrupting a session of another
    agent.
    
    The intent of the presentation on SCSI/iSCSI modeling, and the text in
    the
    draft, is to illustrate how this example is not a recommended
    implementation
    choice due to the probability of violating the SCSI/iSCSI rules pointed
    out.
    If the "independant agents" had partitioned the ISID space, there would
    be
    no collision on login and no time wasted.  Your illustrated
    implementation
    could spend significant time "trying" ISID's in use by the "other
    agents".
    
    However, I'm starting to have more sympathy with Julian's concerns due
    to
    the apparent risks of different vendors' initiator implementations not
    following the rules.
    
    I just imagined having vendor A's HBA installed and happily servicing
    applications, installing vendor B's "plug-n-play" implementation, and
    having
    all A's sessions aborted cause B doesn't know how to play right :-(
    
    Marj
    


Home

Last updated: Fri Sep 07 12:17:11 2001
6423 messages in chronological order