RE: TargetPortalGroupTag for redirection

[Vysyaraju Daliraju <VDaliraju@sbs.com>]

I hava qlogic 4010c host base adapter for iscsi initiator. Could some one
suggest a target emulator (pure software no hardware)  to test this
initiator?

Vysyaraju Dali Raju 
__________________________________________
Vysyaraju Daliraju, / Systems Software Engineer
SBS Technologies, 8371C Central Ave. / Newark, CA 94560
Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com
<mailto:VDaliraju@sbs.com>



-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Thursday, July 17, 2003 6:44 AM
To: wrstuden@wasabisystems.com; Julian Satran
Cc: Robert D. Russell; ips@ece.cmu.edu
Subject: RE: TargetPortalGroupTag for redirection


I think part of what he is saying is similar to my EMAIL on May 23rd.

>>I have a question regarding the determination of the Target Portal
>>Group Tag during a discovery session when the TargetName is not supplied.
>>
>>The TargetPortalGroupTag must be reported in the first Login
>>Response for all session types. But without the TargetName,
>>how does the network entity determine which Target Portal 
>>Group Tag to report if two different targets in the network 
>>entity are using the same IP Address/TCP Port?"


Eddy

-----Original Message-----
From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] 
Sent: Wednesday, July 16, 2003 10:32 PM
To: Julian Satran
Cc: Robert D. Russell; ips@ece.cmu.edu
Subject: Re: TargetPortalGroupTag for redirection

On Sat, 12 Jul 2003, Julian Satran wrote:

I'm sorry for the delay, I have been out of town.

> 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."

I'm confused. Where's the conflict? One is talking about the
TargetPortalGroupTag key, and the other, I thought, is talking about the
portal-group-tag within the TargetAddress response:

TargetAddress=domainname[:port][,portal-group-tag]

They are two different things. How is there any confusion?

> 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.

I don't see the inconsistency. We're talking about two different portals,
so they can have two different portal tag values. One requirement speaks
to one value, and the other requirement speaks to the other.

> 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?

Well, I can't speak for the group, but I don't see the conflict. :-) I do
however think that if an initiator gets a TargetPortalGroupTag and a
redirect, it should NOT think that the portal tag it got is the one for
that redirected target.

> 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.

While I disagree with the statement of the problem, I actually do agree
with this solution. :-) A MAY omit is excelent. And since all the info you
need to decide this came in the initial packet, the target will know what
to do.

Why? Because I can see the desire to have a total-redirector. Say you have
an address that used to be a server and now isn't. You can run an
iscsi_redirectd that just does redirections. And for that, the idea of a
portal group tag may not make sense, so there might not be anything to
really report with the TargetPortalGroupTag key.

Take care,

Bill