SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: TargetPortalGroupTag for redirection


    • To: "Julian Satran" <Julian_Satran@il.ibm.com>
    • Subject: RE: TargetPortalGroupTag for redirection
    • From: "Dean Scoville" <dean.scoville@qlogic.com>
    • Date: Mon, 14 Jul 2003 11:54:24 -0700
    • Cc: <ips@ece.cmu.edu>
    • content-class: urn:content-classes:message
    • Content-Transfer-Encoding: quoted-printable
    • Content-Type: text/plain;charset="iso-8859-1"
    • Delivered-To: ips-outgoing@sos.ece.cmu.edu
    • Delivered-To: ips-outgoing@ece.cmu.edu
    • Delivered-To: ips@sos.ece.cmu.edu
    • Delivered-To: ips@ece.cmu.edu
    • Sender: owner-ips@ece.cmu.edu
    • Thread-Index: AcNIM2D68Pg+e+jESRG+elannwjmYwCAqhBw
    • Thread-Topic: TargetPortalGroupTag for redirection

    Julian,
    I've heard several references to changes that will be made during
    the "last 48h". When do you expect the "last 48h" window to occur?
    Is the delay due to a backlog at the RFC editor?
    
    Do you have a list of the changes that are planned for the "last 48h"
    (or a new iSCSI draft that includes them) so we can start upgrading
    our Draft 20 implementations to be compliant with what will 
    eventually become the iSCSI RFC?
    
    thanks,
    Dean
    
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Friday, July 11, 2003 10:06 PM
    To: Robert D. Russell
    Cc: ips@ece.cmu.edu
    Subject: Re: TargetPortalGroupTag for redirection
    
    
    Bob,
    
    Your interpretation is correct.
    I will see what I can do on the text (if I can do) during the "last 48h".
    
    Thanks,
    Julo
    
    
    
    "Robert D. Russell" <rdr@io.iol.unh.edu> 
    10-07-03 16:58
    
    To
    ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
    cc
    
    Subject
    TargetPortalGroupTag for redirection
    
    
    
    
    
    
    Julian:
    
    The 6th UNH iSCSI Plugfest has been underway since Monday, 7 July,
    with 22 companies participating.  Yesterday we came up with the
    first issue relating to the standard, and it is a minor one that
    actually is related to the discussion on the mailing list at the
    end of May under the thread TargetPortalGroupTag for discovery.
    
    The issue here involves the use of the TargetPortalGroupTag
    during discovery.  Section 10.13.5 says:
      "All of the redirection status class responses MUST return one
      or more text key parameters of the type "TargetAddress", which
      indicates the target's new address."
    and Section 12.8 says:
      "If the TargetAddress is returned as the result of a redirect
      status in a login response, the comma and portal group tag
      MUST be omitted."
    
    However, Section 5.3.1 says:
      "During the Login Phase the iSCSI target MUST return the
      TargetPortalGroupTag key with the first Login Response PDU
      with which it is allowed to do so (i.e., the first Login
      Response issued after the first Login Request with the C bit
      set to 0) for all session types."
    
    where as a result of the discussion on the mailing list in May,
    the end of that last quote should probably now read:
      "for Normal sessions."
    
    There seems to be an inconsistency in the case of redirection,
    because on the one hand, the target MUST NOT supply the
    target portal group tag with the required TargetAddress,
    but on the other hand it MUST supply the target portal group tag
    in the required TargetPortalGroupTag key.
    
    Presumably, the target portal group tag is omitted from the
    TargetAddress because it is not meaningful during a redirection,
    and therefore, the TargetPortalGroupTag key should not be
    required if the first Login Response is a redirection response.
    This is especially relevant because the target at the new
    address could presumably supply a different TargetPortalGroupTag
    value.
    
    Is this the correct interpretation?
    
    The issue is complicated a bit by the fact that redirection is
    not required to occur on the first Login Response, and continuation
    of the Login Phase may depend on the initiator knowing the target
    portal group tag value.  Therefore, the first Login Response
    should probably be allowed to omit the TargetPortalGroupTag key only
    when it is a redirection or is a response to a first Login Request
    that includes the SessionType=Discovery key.
    
    Comments?
    
    Thanks,
    Bob Russell
    
    
    


Home

Last updated: Tue Aug 05 12:46:13 2003
12771 messages in chronological order