Re: iscsi : changes involving tgt portal group tag.

["Mallikarjun C." <cbm@rose.hp.com>]

> The issue is that I am not sure that a target is checking today anything - 
> (adapter drivers may check oif in their realm they can give out a TSID). 
> Nothing else is needed.

Target is required to derive the TPGT and use it in both cases of Login -
     a) when TSID = 0, to ascertain if a session reinstatement needs to
         be effected for that TPGT.
     b) when TSID != 0, to ascertain the validity of TSID and add in
          the new connection to an existing session if it is valid for that TPGT.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747

----- Original Message ----- 
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Cc: <ips@ece.cmu.edu>; <t10@t10.org>
Sent: Tuesday, March 05, 2002 11:56 PM
Subject: Re: iscsi : changes involving tgt portal group tag.


> The issue is that I am not sure that a target is checking today anything - 
> (adapter drivers may check oif in their realm they can give out a TSID). 
> Nothing else is needed. Does SCSI have to be aware of it? Perhaps but 
> iSCSI certainly not. Does a "front-end" have to be - again probably not 
> the name identifies the node.
> 
> Julo
> 
> 
> 
> 
> "Mallikarjun C." <cbm@rose.hp.com>
> 05-03-02 22:34
> Please respond to "Mallikarjun C."
> 
>  
>         To:     Julian Satran/Haifa/IBM@IBMIL
>         cc:     <ips@ece.cmu.edu>, <t10@t10.org>
>         Subject:        Re: iscsi : changes involving tgt portal group tag.
> 
>  
> 
> Julian,
> 
> Whatever methods a target is expected to use today to derive the implicit
> TPGT to preclude a duplicate I-T nexus would work after the change as 
> well,
> except the derived value needs to be compared against the (proposed)
> TPGT in the Login Request payload.
> 
> Please comment if we're missing something.
> 
> Regards.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
> 
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: "Mallikarjun C." <cbm@rose.hp.com>
> Cc: <ips@ece.cmu.edu>; <owner-ips@ece.cmu.edu>; "Santosh Rao" 
> <santoshr@cup.hp.com>;
> <t10@t10.org>
> Sent: Monday, March 04, 2002 10:24 PM
> Subject: Re: iscsi : changes involving tgt portal group tag.
> 
> 
> > Has a decent target implementation and easy way of checking that the TPG
> > is correct?
> >
> > Julo
> >
> >
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>
> > Sent by: owner-ips@ece.cmu.edu
> > 05-03-02 01:12
> > Please respond to "Mallikarjun C."
> >
> >
> >         To:     "Santosh Rao" <santoshr@cup.hp.com>, <ips@ece.cmu.edu>
> >         cc:     <t10@t10.org>
> >         Subject:        Re: iscsi : changes involving tgt portal group 
> tag.
> >
> >
> >
> > Santosh and Jim,
> >
> > It appears a good idea to add in the portal group tag in the Login
> > Request header for a sanity check by the receiving target portal.
> >
> > I generally agree with Jim's comments that the duration of persistence
> > of a portal group tag is intricately linked to the extent of portal
> > reconfiguration.
> > Not every target reconfiguration may result in a portal group tag
> > reassignment.
> > OTOH, some reconfigurations may be so extensive as to cause even a node
> > name change.
> >
> > Some comments on Santosh's message -
> >
> > > "If a portal group is re-configured such that all its previously
> > > advertised network portals are no longer a part of the portal group,
> > > then, the portal group tag (and thereby, the port name/identifier)
> > > *MUST* be changed to indicate a new target port."
> >
> > I am not sure this solves the problem you're trying to get at.  If none 
> of
> > the earlier IP addresses can get an initiator to the SCSI target port 
> that
> > it
> > knew of (your scenario), it appears to me that it doesn't matter if the
> > portal group tags are changed or not....A new discovery process should
> > update the initiator of the changed portal addresses.
> >
> > I suggest the following text -
> >
> >    After a portal group reconfiguration which changed the view of LUs
> >    for an initiator with a given set of privileges, the target MUST 
> change
> >    the portal group tag that represents the reconfigured target portal
> > group.
> >
> > > > Under these events, shouldn't all "open/active I_T_L traffic" have
> > been
> > > > aborted, closed or otherwise ended?  So this shouldn't be an issue 
> at
> > all.
> > >
> > > On a session logout & re-login, it is not efficient/necessary to close
> > > and re-open each LUN behind that target port, due to the fact that a
> > > target port may have hundred's of LUNs behind it.
> >
> > I agree with Jim on this one - there should be *no* open/active I_T_L
> > nexus
> > traffic after a reconfiguration, targets can enforce this via simple 
> iSCSI
> > means
> > (reject initiator advances to continue the session for DefaultTime2Wait+
> > DefaultTime2Retain seconds).  In fact, Async logout request requires a
> > clean closure that implicitly aborts I/Os.
> >
> > What you're describing is typical O/S "LUN open" and "LUN close"
> > interactions.  I agree that they wouldn't have to be repeated, but care
> > must be taken to ensure that new I/Os (on the new session after
> > reconfiguration)
> > are not delivered to the incorrect LUs.  It seems that the addition of
> > TPGT in the login header and the proposed new text (above) would take
> > care of this.
> >
> > Regards.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> >
> > ----- Original Message -----
> > From: "Santosh Rao" <santoshr@cup.hp.com>
> > To: <ips@ece.cmu.edu>
> > Cc: <t10@t10.org>
> > Sent: Monday, March 04, 2002 10:40 AM
> > Subject: Re: iscsi : changes involving tgt portal group tag.
> >
> >
> > > * From the T10 Reflector (t10@t10.org), posted by:
> > > * Santosh Rao <santoshr@cup.hp.com>
> > > *
> > > Jim,
> > >
> > > I agree that a "complete re-configuration" of a target port can result
> > > in a new port name & port identifier. However, the tricky part is the
> > > definition of a "complete re-configuration of an iscsi target port", 
> due
> > > to the concepts of portal groups involving multiple network portals.
> > >
> > > For example, if a portal group (aka, an iscsi target port) were to be
> > > re-configured to include a new network portal [moved from another 
> portal
> > > group], then, the target port itself has not changed, since it is 
> still
> > > accessible through its previously used network portals. What has 
> changed
> > > is the individual network portal that has moved from 1 target port to
> > > another.
> > >
> > > Hence, it is sufficient, in this case, to maintain persistence of the
> > > target port name/identifier, without requiring any change in port
> > > name/identifier. By requiring initiators to send the intended TPGT 
> (scsi
> > > target port name/identifier) along with the login request, this allows
> > > the target port to detect that the network portal is being accessed to
> > > connect to a different target port and it can reject the login.
> > >
> > > It may be helpful to call out the specific case when a port
> > > name/identifier MUST change. How about something like :
> > >
> > > "If a portal group is re-configured such that all its previously
> > > advertised network portals are no longer a part of the portal group,
> > > then, the portal group tag (and thereby, the port name/identifier)
> > > *MUST* be changed to indicate a new target port."
> > >
> > > This would allow access to the target port through its un-altered
> > > network portals to continue un-disrupted. More comments inline, in
> > > response to some of your queries.
> > >
> > > Thanks,
> > > Santosh
> > >
> > > NOTE : In this discussion target port and target portal group are used
> > > to imply the same entity, within a target node.
> > >
> > >
> > > Jim Hafner wrote:
> > >
> > > > SAM-2 requires scsi port names to be persistent and 
> world-wide-unique.
> > > > (SAM-2 Rev 22 Section 4.7.7). Quoting from SAM-2 :
> > > >
> > > > "A scsi port name shall never change and may be used to persistently
> > > > identify a scsi initiator port or target port...".
> > > >
> > > > <JLH>
> > > > There are different ways that one can interpret this "persistent"
> > rule. The
> > > > intent was that names shouldn't change over time when *identifying 
> the
> > same
> > > > object*.   What that means is that if the object changes (in any
> > > > discernable way), then the name should change.  So, the object can
> > move to
> > > > a different piece of hardware, but it can still be named the same 
> way.
> >  If
> > > > the object changes, e.g., in this case, reconfigures as a different
> > set of
> > > > network portals with different addressing elements, then I would 
> think
> > that
> > > > the name should change as well.   That's all the persistence one
> > really
> > > > needs.
> > > >
> > > > I'm not sure what that implies about your recommendation.  I don't 
> see
> > any
> > > > problem with it, either.
> > > > </JLH>
> > >
> > > I think we may be in agreement. (See reasoning above).
> > >
> > >
> > > >
> > > > The rationale for (2) is :
> > > > --------------------------
> > > > Consider an initiator node establishing multiple sessions to a scsi
> > tgt
> > > > port, with each session established to a subset of the network 
> portals
> > > > within the tgt portal group.
> > > >
> > > > Consider an iscsi transport event involving the re-configuration of
> > > > target portal groups on the iscsi target node. This may be preceeded
> > by
> > > > the iscsi sessions seeing an async message "target requests logout",
> > > > followed by session logout, portal group re-configuration, and then,
> > the
> > > > initiator re-establishes sessions.
> > > >
> > > > Across a transport event that results in such session termination 
> and
> > > > re-establishment, the initiator needs to authenticate that it is 
> still
> > > > speaking to the same [i]scsi target port, in order to ensure that 
> any
> > > > open/active I-T-L nexus traffic on that session is not incorrectly
> > > > routed to a wrong LUN after such a transport event.
> > >
> > > > <JLH>
> > > > Under these events, shouldn't all "open/active I_T_L traffic" have
> > been
> > > > aborted, closed or otherwise ended?  So this shouldn't be an issue 
> at
> > all.
> > >
> > > On a session logout & re-login, it is not efficient/necessary to close
> > > and re-open each LUN behind that target port, due to the fact that a
> > > target port may have hundred's of LUNs behind it.
> > >
> > > All outstanding I/Os need to be aborted. Once the session is
> > > re-established [and the target port is authenticated to be the same],
> > > further I/O traffic can be resumed without requiring the SCSI ULP to
> > > close and re-open each LUN. Some transport specific clearing effects 
> may
> > > have occurred, which may require additional LUN level activity, in 
> some
> > > cases.
> > >
> > > (There are analogies to the above model in FCP & SRP, which 
> authenticate
> > > port name/identifier on login, allowing I/O resumption after session
> > > termination and re-establishment.)
> > >
> > >
> > > > To prevent such authentication issues, iscsi can send the iscsi 
> target
> > > > port identifier (portal group tag) explicitly in the login request,
> > and
> > > > the login can be rejected by the target on a portal group tag
> > mis-match.
> > > > (if the network portal does not belong to the addressed portal group
> > > > tag).
> > > > <JLH>
> > > > Did you mean for the initiator to send this TPGT?
> > > > </JLH>
> > >
> > > Yes. The initiator login request must include the target portal group
> > > tag, thus identifying the target port to which a session is being
> > > established.
> > >
> > > Login currently carries no addressing information, since the 
> addressing
> > > is implicit, based on the TCP connection in use. The problem with this
> > > approach is that the login implicitly addresses a network portal, and
> > > not the target port. As seen in the earlier example, the association 
> of
> > > network portal <-> target port can change, and such changes can be
> > > detected, if the initiator were to explicitly identify the target port
> > > being logged into.
> > >
> > > --
> > > ##################################
> > > Santosh Rao
> > > Software Design Engineer,
> > > HP-UX iSCSI Driver Team,
> > > Hewlett Packard, Cupertino.
> > > email : santoshr@cup.hp.com
> > > Phone : 408-447-3751
> > > ##################################
> > > *
> > > * For T10 Reflector information, send a message with
> > > * 'info t10' (no quotes) in the message body to majordomo@t10.org
> > >
> >
> >
> >
> 
> 
> 
>