SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: LUN in a ping



    True and I apologize for that remark.
     
    I asked how the initiator would use it and what you pointed out was that the target would use it to identify origin.
     
    If the initiator is only required to echo it and not interpret it, then I see no reason to force a target to fill it in. For example in my case, a valid LUN is not readily available at the time that I want to send a ping. Granted it is not in a fast path but, by my poorly thought out remark, I am saying a spec should not mandate requirements that have no use.
     
    Eddy
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Thursday, January 23, 2003 11:47 AM
    To: Eddy Quicksall
    Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu; Rod Harrison
    Subject: RE: iSCSI: LUN in a ping


    Eddy,

    We all appreciate you opinion - but this has been hotly debated more than 18 months ago.
    And I recall sending you an explanation regarding the middle boxes and how they handle the LUN for routing in a "clustered" target.
    And your comment about a "requirement with no good reason" besides being derogatory does not add any value to the discussion.

    Julo


    Eddy Quicksall <eddy_quicksall@ivivity.com>
    Sent by: owner-ips@ece.cmu.edu

    23/01/03 17:19

    To
    Rod Harrison <rod.harrison@windriver.com>, Julian Satran <julian@cs.haifa.ac.il>, ips@ece.cmu.edu
    cc
    Subject
    RE: iSCSI: LUN in a ping





    For that, wouldn't the target generate REPORTED LUNS DATA HAS CHANGED
    (3F/0E)?

    It is my opinion that this is just another requirement that has been put on
    the target for no good reason.

    It should be up to the target as to if the LUN field has meaning and the
    initiator should be the one that has a requirement to echo the value.

    Eddy

    -----Original Message-----
    From: Rod Harrison [mailto:rod.harrison@windriver.com]
    Sent: Wednesday, January 22, 2003 1:52 PM
    To: Eddy Quicksall; Julian Satran; ips@ece.cmu.edu
    Subject: RE: iSCSI: LUN in a ping



    The initiator might try to rediscover the LUN topology if it sees a NOP from
    a
    LUN that it previously thought was not present.

    - Rod

    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Eddy Quicksall
    Sent: Wednesday, January 22, 2003 10:28 AM
    To: Julian Satran; Eddy Quicksall; ips@ece.cmu.edu
    Subject: RE: iSCSI: LUN in a ping


    Yes, I remember that but the necessity for the target to set it should be up
    to the target because the initiator should not be trying to interpret it (it
    should only be required to echo it).

    Is there a case where the initiator will interpret the LUN?

    Eddy

    -----Original Message-----
    From: Julian Satran [mailto:julian@cs.haifa.ac.il]
    Sent: Wednesday, January 22, 2003 12:43 AM
    To: 'Eddy Quicksall'; ips@ece.cmu.edu
    Subject: RE: iSCSI: LUN in a ping


    TTT & LUN uniquely identify the "origin" (if target is a "composite"
    each of the parts can issue their own TTTs - no coordination needed).

    Regards,
    Julo


    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
    Eddy Quicksall
    Sent: 22 January, 2003 00:07
    To: ips@ece.cmu.edu
    Subject: iSCSI: LUN in a ping


    Does anyone know why we added "the LUN must be valid" for a target
    initiated ping? It would seem that it is N/A when the ping is just being
    used to checkup on the connection.

    What will the initiator do with the LUN anyway?

    10.19.3 LUN
    A LUN MUST be set to a correct value when the Target Transfer Tag is
    valid (not the reserved value 0xffffffff).

    Eddy
    mailto: Eddy_Quicksall@iVivity.com




Home

Last updated: Thu Jan 23 14:19:07 2003
12236 messages in chronological order