Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-00.txt

From: [email-masked]
Date: Tue, 12 Jul 2005 10:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: iSCSI Implementer's Guide
	Author(s)	: M. Chadalapaka
	Filename	: draft-ietf-ips-iscsi-impl-guide-00.txt,.pdf
	Pages		: 19
	Date		: 2005-7-12
	
     iSCSI is a SCSI transport protocol and maps the SCSI family 
     of application protocols onto TCP/IP.  RFC 3720 defines the 
     iSCSI protocol.  This document compiles the clarifications to 
     the original protocol definition in RFC 3720 to serve as a 
     companion document for the iSCSI implementers. This document 
     updates RFC 3720 and the text in this document supersedes the 
     text in RFC 3720 when the two differ. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-impl-guide-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: William Studenmund <[email-masked]>
Date: Tue, 12 Jul 2005 23:57:41 -0400

Mallikarjun,

Thank you for working on this draft. I think it will help clarify a 
number of points.

I think section 3, however, could use some modification. I have two 
main concerns with it.

First, it focuses a lot on the REPORT LUNS command. However that 
command is not the only command that behaves this way. Any command that 
uses an "Allocation Length" parameter is in this class, such as INQUIRY 
and MODE SENSE. I think we should generalize this discussion so it is 
clear that it applies to all of them.

Second, I think it would be good to add a SCSI Expected Data Transfer 
Length (SEDTL) term and concept. This concept is present in the text, 
but unnamed. I think naming it will add a lot of clarity to the 
discussion.

For a REPORT LUNS command, an INQUIRY command, a MODE SENSE command, or 
other comparable commands, the SEDTL is given by the ALLOCATION LENGTH 
in the CDB. For SCSI READ or WRITE commands to a disk, the SEDTL is 
given by the block size multiplied by the number of blocks to transfer. 
I'm not 100% sure what the SEDTL is for a tape drive in face of varying 
block sizes.

(O) and (U) bits then depend only on the difference between the EDTL 
and the SEDTL (assuming I understand the concept right :-) .

Then the second paragraph of 3.1 becomes something like:

iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI Response 
and SCSI Data-Out PDUs for READ-type commands (or the (o) bit, bit 3, 
for bidirectional commands) to indicate that an iSCSI target was unable 
to transfer to the initiator all of the SCSI data for a command because 
the SEDTL exceeded the EDTL.

I also am concerned with the use of "at least" in the fourth paragraph. 
While correct, my concern is that if the EDTL is greater than the SEDTL 
(ALLOCATION LENGTH), we in fact need to set the (U) bit and note an 
under run, :-)

To make sure I understand it:

For a write phase:

If SEDTL is greater than EDTL, we wanted more data than we got. After 
the command completes, we will report an under run of SEDTL - EDTL.

If SEDTL is less than EDTL, we got more data than we wanted. After the 
command completes, we will report an overrun of EDTL - SEDTL.

For a read phase:

If SEDTL is greater than EDTL, we got more data than we wanted. After 
the command completes, we will report an overrun of SEDTL - EDTL.

If SEDTL is less than EDTL, we wanted more data than we got. After the 
command completes, we will report an under run of EDTL - SEDTL.

Did I get that right?

Also, what do we do in case of an error? In addition to CHECK CONDITION 
and ASC/ASCQ, do we try to flag either an under run or overrun to 
indicate how far we got into the transaction before the error happened?

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 14 Jul 2005 13:10:36 -0700

Bill,

 >I think we should generalize this discussion so it is clear that
 > it applies to all of them.

I think that's a good suggestion.

 > Length (SEDTL) term and concept.

We have to be careful not to assume that all SCSI-level *expected* data 
is transacted through the iSCSI layer.  E.g., target SCSI device server 
may not have *presented* enough bytes to iSCSI layer for the Data-in 
buffer, say, due to bad blocks.  I think the iSCSI layer should not flag 
an Overflow if its EDTL matched with what was presented to it, 
regardless of the SEDTL value.

I would suggest the notion of "SCSI-Presented Data Transfer Length" 
(SPDTL) to denote the aggregate data length that the SCSI layer presents 
to iSCSI layer for a Data-in/out transfer in the context of a SCSI task.

If you agree, it would then be:

    SPDTL > EDTL --> iSCSI Overflow    Residual Count = SPDTL - EDTL
    SPDTL < EDTL --> iSCSI Underflow   Residual Count = EDTL - SPDTL

Similar approach applies to bidirectional operations.

 > (ALLOCATION LENGTH), we in fact need to set the (U) bit and note an

You are correct, although the text as written is accurate.  I agree it 
would be good to note the underflow scenario.  I'll do it in the next rev.

 > Did I get that right?

I think you got the write under/overflows backwards.  IOW, I do not see 
how the underflow/overflow result changes between read & write for given 
SPTDL & EDTL values (RFC 3720, 10.4.1 doesn't qualify the definitions 
based on read & write) .....

 >In addition to CHECK CONDITION

iSCSI should be technically ignorant of SCSI error specifics.  I suggest 
the only factor for setting the U & O bits (and their lower-case 
friends) at the iSCSI layer be SPDTL.  In short, "it depends".

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

William Studenmund wrote:
> I think section 3, however, could use some modification. I have two main 
> concerns with it.
> 
> First, it focuses a lot on the REPORT LUNS command. However that command 
> is not the only command that behaves this way. Any command that uses an 
> "Allocation Length" parameter is in this class, such as INQUIRY and MODE 
> SENSE. I think we should generalize this discussion so it is clear that 
> it applies to all of them.
> 
> but unnamed. I think naming it will add a lot of clarity to the discussion.
> 
> (O) and (U) bits then depend only on the difference between the EDTL and 
> the SEDTL (assuming I understand the concept right :-) .
> 
> ------------------------------------------------------------------------
>

---

From: William Studenmund <[email-masked]>
Date: Thu, 14 Jul 2005 22:43:57 -0700

On Jul 14, 2005, at 1:10 PM, Mallikarjun C. wrote:

> We have to be careful not to assume that all SCSI-level *expected* 
> data is transacted through the iSCSI layer.  E.g., target SCSI device 
> server may not have *presented* enough bytes to iSCSI layer for the 
> Data-in buffer, say, due to bad blocks.  I think the iSCSI layer 
> should not flag an Overflow if its EDTL matched with what was 
> presented to it, regardless of the SEDTL value.

Ok, another term will be good. I was 1) focusing on non-error cases, 
and 2) trying to differentiate between how much REPORT LUNS/MODE 
SENSE/etc. data are there and how much SCSI expects to transfer. i.e. 
the whole REPORT LUNS discussion gets clearer when there were two 
different SCSI lengths involved. We can then say that only one of them 
matters for O&I.

I agree that in an error case, we should not use the "expected" amount 
but something more reflective of reality.

> (SPDTL) to denote the aggregate data length that the SCSI layer 
> presents to iSCSI layer for a Data-in/out transfer in the context of a 
> SCSI task.
>
> I think you got the write under/overflows backwards.  IOW, I do not 
> see how the underflow/overflow result changes between read & write for 
> given SPTDL & EDTL values (RFC 3720, 10.4.1 doesn't qualify the 
> definitions based on read & write) .....

Then we definitely need to document this!

I always understood overflow to mean you had more data than wanted and 
underflow to mean you got less than wanted. That's probably as I 
started out with serial ports where bit and byte timings could generate 
these issues.

The flipping was deliberate, and reflected the fact that in write 
cases, iSCSI is presenting data to SCSI (that then doesn't know what to 
do with it) and in read cases, SCSI presents data to iSCSI which can't 
do anything with it. Looking at 10.4.1, you are right that it has no 
reflection. While I find this definition counter-intuitive, it has a 
bit of symmetry; it's always the iSCSI # relative to the SCSI #.

> iSCSI should be technically ignorant of SCSI error specifics.  I 
> suggest the only factor for setting the U & O bits (and their 
> lower-case friends) at the iSCSI layer be SPDTL.  In short, "it 
> depends".

I think we're agreeing. I agree iSCSI shouldn't care about the error 
code, I was just trying to figure out what a target does in addition to 
setting them. Admittedly I'm coming from an integrated SCSI/iSCSI 
target scenario. :-)

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Fri, 15 Jul 2005 16:29:00 +0300

You may want to consider that in any
decent implementation the overrun/underrun values (counts not flags) will
probably originate from SCSI. This may make you want to change SPDTL into
P(otential)SPDTL - :-)

On a more philosophical plan underflow/overflow
is basically a SCSI issue that originates by SCSI using two potentially
different length related parameters.

Some are classics (blocks/buffer) and
some are new (allocated vs. expected). The origin of the mess is the parallel
SCSI where length (EDTL) was not conveyed to target.

- and it is still with us.

Julo

William Studenmund <[email-masked]>

Sent by: [email-masked]

15/07/2005 01:43

To

"Mallikarjun C." <[email-masked]>

cc

IPS <[email-masked]>

Subject

Re: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt

matters for O&I.

I agree that in an error case, we should not use the "expected"
amount

> > I also am concerned with the use of "at least" in the
fourth

> paragraph.

> > While correct, my concern is that if the EDTL is greater than
the

> SEDTL

> would be good to note the underflow scenario.  I'll do it in
the next

> rev.

these issues.

> > indicate how far we got into the transaction before the error

> happened?

target scenario. :-)

Take care,

Bill

Ips mailing list

[email-masked]

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 15 Jul 2005 11:44:24 -0700

> You may want to consider that in any decent implementation the
 > overrun/underrun values (counts not flags) will probably originate from
 > SCSI. This may make you want to change SPDTL into P(otential)SPDTL - :-)

That is a good observation, I'll add a sentence to the draft to include 
this idea.  I'd though leave the SPDTL unchanged because the 
"presenting" really is logical (and I'll note it as such).

As Bill requested, I'll also document the fact that underflow/overflow & 
residual count setting are agnostic about reads & writes.  The only 
exception is when read and write are *both* in progress (bidirectional 
operation), in which case, the residuals and flags for bidi reads are to 
be captured separately in other header fields (the over/underflow logic 
is still the same even here, results merely encoded in different fields).

Mallikarjun

Mallikarjun Chadalapaka

Julian Satran wrote:
> 
> You may want to consider that in any decent implementation the 
> overrun/underrun values (counts not flags) will probably originate from 
> SCSI. This may make you want to change SPDTL into P(otential)SPDTL - :-)
> 
> On a more philosophical plan underflow/overflow is basically a SCSI 
> issue that originates by SCSI using two potentially different length 
> related parameters.
> Some are classics (blocks/buffer) and some are new (allocated vs. 
> expected). The origin of the mess is the parallel SCSI where length 
> (EDTL) was not conveyed to target.
> *William Studenmund <[email-masked]>*

---

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 15 Jul 2005 18:32:15 -0700

Mallikarjun,

Thanks for starting this activity.

I have some confusion on Section 4.1.2 under the
heading "The Target" which describes the steps the
target should perform.

Is the Target term as used here, the "Service Delivery System"
or the "Task Manager"? The reason I have the confusion is
that

a. The determination of the affected tasks 
can be performed only by the "Task
Manager" which knows the scope of the Task Management
Function based on various Control Mode Page settings

b. Don't know whether target SCSI layer in step d means
the "Device Server" or the "Task Manager"

c. The step (e) is transport specific and at least
there is no abstract "transport protocol service" interface
defined to make sure the acknowledgements have been
received by the initiator (i.e. there is no way to force
NOP-Ins at specific points).

-----

Another item that would be useful to discuss in the
implementors guide is the behavior when UA conditions
are generated (including transport specific conditions),
but I will generate another email on that.

Thanks,
Somesh

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 18 Jul 2005 16:12:35 -0700

Somesh,

 > or the "Task Manager"?

Neither...  It is used in the same sense RFC 3720 used the term:

"SCSI is a client-server architecture. Clients of a SCSI interface
are called "initiators". Initiators issue SCSI "commands" to request
services from components, logical units, of a server known as a
"target"."

In short, it is the network entity composed of an iSCSI node and a 
corresponding SCSI device.  BTW, SAM-2 makes a clear distinction between 
"service delivery subsystem" and a "task manager".

 > Function based on various Control Mode Page settings

AFAIK, control mode page settings are needed only for Clear Task Set.

At any rate, the current text defines the chronological sequence of 
actions in the iSCSI layer relative to the Task management SCSI 
transport protocol service indication & response (step d).  Its intent 
is not to define what happens in the SCSI layer.

 > the "Device Server" or the "Task Manager"

It actually refers to the iSCSI layer ("..receives the response from the 
target SCSI layer.").

 > c. The step (e) is transport specific and at least

Not sure what you mean, the entire list is specific to iSCSI.

 > received by the initiator

Not sure again - why would SCSI want to know about StatSN acks?

Mallikarjun

Mallikarjun Chadalapaka

---

From: "Robert D. Russell" <[email-masked]>
Date: Tue, 19 Jul 2005 15:32:42 -0400 (EDT)

Mallikarjun:

Last August (2004) there was a long discussion on the reflector about
how the ISID rule applied to discovery sessions.  A satisfactory 
resolution was arrived at, but given that your new implementer's guide
is intended to clarify 3720, would you consider adding that resolution
of the ISID/discovery problem to your new guide as a clarification?

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 19 Jul 2005 16:53:21 -0700

Bob,

Yes, I will certainly consider.  Please send me a URL to a decent 
summary email in that thread.  Or please do me a favor by writing up one 
if a summary doesn't exist.

Thanks.

Mallikarjun

Mallikarjun Chadalapaka

---

From: Pat LaVarre <[email-masked]>
Date: Tue, 19 Jul 2005 21:03:59 -0700

> but I will generate another email on that.

SK ASC = x 6 28 for each gone ready of a media insertion, x 6 29 for 
each reset or plug in to promise x 6 28 later, end of story ... no?

---

From: "Robert D. Russell" <[email-masked]>
Date: Mon, 25 Jul 2005 12:27:20 -0400 (EDT)

Mallikarjun:

> Yes, I will certainly consider.  Please send me a URL to a decent summary 
> email in that thread.  Or please do me a favor by writing up one if a summary 
> doesn't exist.
>

Attached below is my draft of a proposed clarification
based on two long threads that appeared on the reflector in
August, 2004, both having to do with the uniqueness of iscsi
sessions and I_T nexus identifiers.

The first thread appeared under the heading:
"ISCSI Name and Multi-Port Targets", starting with
http://www.spinics.net/lists/iscsi/msg10052.html

The second thread appeared under two headings:
"final resolution of ISID rule as it applies to discovery sessions",
starting with http://www.spinics.net/lists/iscsi/msg10129.html
and (note the missing space)
"final resolution of ISID rule as it applies to discoverysessions",
starting with http://www.spinics.net/lists/iscsi/msg10142.html

In writing this summary I realized that the "final resolution of the
ISID rule for discovery sessions" thread never mentioned what to do
about the Portal Group Tag in the I_T nexus identifier when the
Target Name was omitted during the first login request of a
discovery session.  It seems to me that without the Target Name
no Portal Group Tag can be uniquely determined, even based on the
IP address and port number used by the initiator to connect to the
target (since that IP address and port number can belong to different
portal groups under different Target Names used by the same target
network entity).  I therefore wrote in the summary that the Portal
Group Tag component of the I_T nexus identifier was also NULL or ""
in this case.

Comments?

Thanks,

Bob Russell
InterOperability Lab

---------------------------------------------------------------------------

Uniqueness of iSCSI sessions
----------------------------

According to Section 3.4.2 c) of RFC 3720, the SCSI "I_T nexus" defined
in SAM2 is equivalent to the iSCSI session defined in RFC 3720.
This section also defines the "I_T nexus identifier" to be the tuple:

    (iSCSI Initiator Name + 'i' + ISID,
     iSCSI Target Name + 't' + Portal Group Tag)

where both the iSCSI Initiator Name and iSCSI Target Name are
intended to be world-wide unique names.

Therefore, two such tuples with a difference in any one of the four
components will identify two different I_T nexi and therefore two
different iSCSI sessions.  This has several implications:

1) An initiator may use the same iSCSI Initiator Name and ISID when
    establishing different (i.e., unique) sessions with different targets
    and/or different portal groups.  This behavior is discussed in section
    9.1.1 and is, in fact, encouraged as conservative reuse of ISIDs.

2) According to section 9.1.2, there is intended to be just one iSCSI
    Initiator Name per operating system image on a machine.  Therefore,
    when multiple initiators are running on the same operating system
    image on the same machine, they should all share the same
    iSCSI Initiator Name and manage the ISID name space between them
    to avoid conflicts (e.g., by appropriate partitioning).

3) The I_T nexus identifier applies to all session types (normal and
    discovery).  When an initiator supplies a Target Name on the first
    login request of a discovery session, there is a Portal Group Tag
    associated with that Target Name and formation of the I_T nexus
    identifier is straight-forward.  However, according to section
    3.2.6.1, the initiator MAY omit supplying the iSCSI Target Name on
    the first login request of a discovery session, in which case the
    I_T nexus identifier is constructed by supplying an empty value
    (e.g., NULL or "") for both the iSCSI Target Name and the Portal
    Group Tag components.  The consequences of this are:

    a) The I_T nexus identifier of a discovery session established WITH a
       Target Name MAY match the I_T nexus identifier of a normal session,
       in which case such a discovery session will force reinstatement of
       an existing normal session (and vice versa) as defined in section
       5.3.1.

    b) The I_T nexus identifier of a discovery session established WITHOUT
       a Target Name NEVER matches the I_T nexus identifier of a normal
       session, so that such a discovery session NEVER forces reinstatement
       of an existing normal session (and vice versa) as defined in section
       5.3.1.

    c) At any time, a single target should have at most one discovery
       session with the I_T nexus identifier:
       (iSCSI Initiator Name + 'i' + ISID + "" + 't' + "")

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 26 Jul 2005 18:06:44 -0700

Bob,

Many thanks for the URLs to old threads and the summary.  I reviewed 
them all.  Your summary looks OK to me, I will incorporate this issue 
into the next revision with some editorial changes.

 >I therefore wrote in the summary that the Portal

I agree.  That's why I was commenting in the past email thread that it's 
really a session to the Network Entity - with no node and no TPG 
affiliation.

 >       (iSCSI Initiator Name + 'i' + ISID + "" + 't' + "")

The implication of this, to be explicit, is that a discovery session 
reinstates another discovery session if both implied - by omitting - the 
NULL target name with the same Initiator Name & ISID.

Thanks!

Mallikarjun

Mallikarjun Chadalapaka

Robert D. Russell wrote:
>> summary email in that thread.  Or please do me a favor by writing up 
>> one if a summary doesn't exist.
>>
>

---

From: William Studenmund <[email-masked]>
Date: Tue, 26 Jul 2005 18:37:55 -0700

> sessions and I_T nexus identifiers.

Thank you for this.

> Group Tag component of the I_T nexus identifier was also NULL or ""

My one thought would be to leave the handling of TPGT to the 
implementation. While I do not think your suggestion is unreasonable, I 
think it would also be reasonable for the target implementation to be 
able to associate a unique TPGT to the session, based on the IP address 
and port number used to connect to the target network entity. If that 
is the case, I would like us to permit such a target to handle the 
session uniqueness rules using the given TPGT.

I believe that it is reasonable that a target MUST always use the same 
TPGT for discovery sessions for an initiator connecting to a given 
portal (IP addr and TCP port), for a given configuration. Thus a target 
has a choice of ""/NULL or some valid TPGT value, but regardless of 
what it does it must keep doing the same, until its configuration 
changes. That way session reinstatement will work correctly.

Also, will implementations deal with an omitted TPGT value 
("key=\000")? Perhaps a better solution is to use the value 0 (zero) 
for the case where we do not have a valid TPGT value. According to 
SAM2, the TPGT is a non-zero two-byte integer, so 0 is outside the 
valid value space.

Take care,

Bill

---

From: "Robert D. Russell" <[email-masked]>
Date: Wed, 27 Jul 2005 11:07:32 -0400 (EDT)

Bill:
A couple of comments on your idea to leave it up to the target
to set the TPGT on a discovery session when no TargetName is
given.

1. You mentioned that the TPGT comes from SAM2 -- I thought the TPGT
    was invented by iSCSI as a means of allowing the target to specify
    the grouping of (IP-address, port-number) pairs (i.e., of Network
    Portals), and had no visibility in SCSI (SAM2).

2. You mentioned that a TPGT of 0 was somehow a special case.
    According to RFC3720, section 12.9, the value is a
    16-bit-binary-value, with 0 not given any special meaning.
    Also in section 3.4.1 e) it says "Portal Groups are identified
    within an iSCSI Node by a portal group tag, a simple unsigned-integer
    between 0 and 65535."  This also implies that a value of 0 is
    nothing special, and in particular does not indicate "no portal group".

3. If the target is allowed to assign a TPGT to a discovery session when
    there is no TargetName given, then it would be possible for there to
    be several simultaneously active "unnamed" discovery sessions to the
    same initiator (InitiatorName + ISID) -- one for each possible portal
    group.  This seems to be contrary to the idea expressed by Mallikarjun
    that an "unnamed" discovery session is intended to be to the
    "Network Entity", and therefore there can/should be only one of them
    (i.e., a second unnamed discovery session to the same Network Entity
    would log out the first unnamed discovery session that that Network
    Entity).

Comments?

Thanks,

Bob Russell
InterOperability Lab

>>> email in that thread.  Or please do me a favor by writing up one if a 
>>> summary doesn't exist.
>>> 
>> 
> My one thought would be to leave the handling of TPGT to the implementation. 
> While I do not think your suggestion is unreasonable, I think it would also 
> be reasonable for the target implementation to be able to associate a unique 
> TPGT to the session, based on the IP address and port number used to connect 
> to the target network entity. If that is the case, I would like us to permit 
> such a target to handle the session uniqueness rules using the given TPGT.
>
> I believe that it is reasonable that a target MUST always use the same TPGT 
> for discovery sessions for an initiator connecting to a given portal (IP addr 
> and TCP port), for a given configuration. Thus a target has a choice of 
> ""/NULL or some valid TPGT value, but regardless of what it does it must keep 
> doing the same, until its configuration changes. That way session 
> reinstatement will work correctly.
>
> Also, will implementations deal with an omitted TPGT value ("key=\000")? 
> Perhaps a better solution is to use the value 0 (zero) for the case where we 
> do not have a valid TPGT value. According to SAM2, the TPGT is a non-zero 
> two-byte integer, so 0 is outside the valid value space.
>
> Take care,
>
> Bill
>

---

From: William Studenmund <[email-masked]>
Date: Wed, 27 Jul 2005 10:25:45 -0700

>    Portals), and had no visibility in SCSI (SAM2).

We are both right. TPGT is an iSCSI concept. However it is an 
implementation of a target port identifier, which is a SCSI concept. 
TPGT is visible to SCSI, in the parts that need to know about 
transport-specific information.

Or at least that's what I understood TPGT to be. A target device has to 
have a port identifier, which is part of the I_T nexus rule. For iSCSI, 
we use TPGT for that, thus TPGT == Target port identifier.

>    nothing special, and in particular does not indicate "no portal 

You are correct. However please see SAM 2 or SAM 3. For SAM 2r23, Table 
A.4 on page 117 and Table A.6 on page 118 both mention, in foot notes, 
that the TPGT is a non-zero two-byte integer. SAM 3 (rev 13a) is a bit 
more verbose. In Table A.3 (page 121) and Table A.5 (page 123), the 
Target Portal Group Tag is described as a UTF-8 encode hexadecimal 
representation of a non-zero two-byte integer. Note: this is how it is 
expressed while naming SCSI entities, not how it is expressed during 
iSCSI negotiation.

So while the RFC permits zero, SAM does not.

We should probably address this issue in its own right in this draft. 
:-) As Target Portal IDs have been non-zero for longer than iSCSI has 
been around, we should probably disallow 0.

However we still have the question which inspired me to suggest 0. RFC 
3720 states that the key "TargetPortalGroupTag" has a value which is an 
integer. Do we know how existing implementations will react if we don't 
give a valid value? I actually think we'd do better to skip the TPGT 
rather than send an ill-formed one.

>    would log out the first unnamed discovery session that that Network

Well, what does it hurt to permit multiple ones? Put another way, why 
do we NEED to prevent multiple ones?

As an example where it helps to be flexible, consider a system where 
iSCSI processing is handled by PCI add-in cards, and the host system 
only handles SCSI-level issues. If we permit implementations, at their 
discretion, to retain the TPGT behavior, then each add-in card just has 
its own TPGT and all is well. All iSCSI processing happens only in a 
card, and the host does SCSI.

Now if we require there be only one discovery session per network 
entity, that means that these iSCSI offload cards have to be able to 
communicate the existence of a discovery session to the host, and the 
host has to coordinate it between them. Thus when a discovery session 
happens on one card, it has to ensure that any discovery sessions on 
other cards get logged out.

That sounds like a lot of hassle.

So while I don't disagree with the idea that we only intend there to be 
one discovery session per network entity, to actively enforce that can 
be a lot of pain to an implementation (or implementations, as in my 
example the iSCSI offload may come from multiple vendors who are not 
the vendor of the underlying system). Since I don't see a need for this 
pain, I think it would be easier to permit a target to retain the TPGT 
behavior (send a valid value) if it wishes.

As before, I believe that a target should stick with whichever behavior 
it chooses.

Regardless of the TPGT value sent, the session ID rules will still be 
in effect. If two different portals (IP addr/TCP port) return the same 
TPGT value to an initiator, logging into one of them with a new 
discovery session will of course log out the other one. If two 
different portals return the "not really a TPGT" TPGT value, a new 
session to one of them will trigger session reinstatement on the other.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 27 Jul 2005 16:45:02 -0700

Bill,

 > TPGT is visible to SCSI,

Only as a substring in a longer string.

 > So while the RFC permits zero, SAM does not.

Thanks for pointing this out.  Rob Elliott though noted the following 
offline on my prompt: a) That is just an informative annex in SAM-nn, 
not normative, so other documents can override it, and b) The existing 
SAM-nn text is historical (until iSCSI rev13 or so, we required it to be 
between 1-65535).  Rob also volunteered to move a T10 proposal to sync 
up the SAM-4 wording to RFC 3720 (thanks Rob!).

 > We should probably address this issue in its own right in this draft.

I agree.  Per above comments, I will note in the next revision of 
Implementer's guide that  zero-value is expressly allowed.

 >I actually think we'd do better to skip the TPGT

Are you referring to the case when TargetName is not given by the 
initiator?  If so, I agree.  TPGT is not required to be returned per RFC 
3720.

When TargetName is specified in the Login Request though, there's no 
choice wrt returning TPGT.

 > entity,...

Only for a given InitiatorName-ISID combination.

 >I think it would be easier to permit a target to retain the TPGT
 > behavior (send a valid value) if it wishes

Unfortunately though, by definition, it will be invalid in the absence 
of a TargetName context.

Section 3.4.1 in RFC 3720 says the following: "A Portal Group defines a 
set of Network Portals within an iSCSI Node...." and "Portal Groups are 
identified within an iSCSI Node by a portal group tag,...."

When a TargetName is not specified for a discovery session, there isn't 
an iSCSI Node context, a TPGT thus is not meaningful and cannot be 
inferred.  While TPGT is not required to be returned per RFC 3720, I 
therefore propose that it must not be returned in this case.

So a "workaround" we have been implying in our discussions so far is 
that there be a No-Name (aka NULL aka "") TPGT that identifies this 
invalid "thing" (that isn't really a portal group).  Since one cannot 
distinguish by definition between multiple No-Name "things", an 
application of the ISID RULE argues for a discovery session 
reinstatement once the InitiatorName-ISID tuple matches.

I personally think it is easier to implement since the same ISID RULE is 
used to manage discovery and normal sessions alike (you can map your 
implmentation's TPGT for the "No-Name thing" to index 0, and start your 
valid TPGTs from index 1 - AFAICT, that's legal).

 >If we permit implementations, at their

I am not sure such a functionality partition can satisfy the following 
in Appendix D of RFC 3720:

"In a discovery
session, a target MUST return all path information (target name and
IP address-port pairs and portal group tags) for the targets on the
target network entity which the requesting initiator is authorized to
access."

Thanks.

Mallikarjun

Mallikarjun Chadalapaka

William Studenmund wrote:
> Well, what does it hurt to permit multiple ones? Put another way, why do 
> we NEED to prevent multiple ones?
> 
> example the iSCSI offload may come from multiple vendors who are not the 
> vendor of the underlying system). Since I don't see a need for this 
> Regardless of the TPGT value sent, the session ID rules will still be in 
> effect. If two different portals (IP addr/TCP port) return the same TPGT 
> value to an initiator, logging into one of them with a new discovery 
> session will of course log out the other one. If two different portals 
> return the "not really a TPGT" TPGT value, a new session to one of them 
> will trigger session reinstatement on the other.
> 
> Take care,
> 
> Bill

---

From: William Studenmund <[email-masked]>
Date: Wed, 27 Jul 2005 18:24:32 -0700

On Jul 27, 2005, at 4:45 PM, Mallikarjun C. wrote:

> SAM-nn text is historical (until iSCSI rev13 or so, we required it to 
> be between 1-65535).  Rob also volunteered to move a T10 proposal to 
> sync up the SAM-4 wording to RFC 3720 (thanks Rob!).
>

Ok.

> initiator?  If so, I agree.  TPGT is not required to be returned per 
> RFC 3720.
>

I agree on both counts.

> Only for a given InitiatorName-ISID combination.

Yes...

> Section 3.4.1 in RFC 3720 says the following: "A Portal Group defines 
> a set of Network Portals within an iSCSI Node...." and "Portal Groups 
> are identified within an iSCSI Node by a portal group tag,...."
>
> When a TargetName is not specified for a discovery session, there 
> isn't an iSCSI Node context, a TPGT thus is not meaningful and cannot 
> be inferred.  While TPGT is not required to be returned per RFC 3720, 
> I therefore propose that it must not be returned in this case.

Actually I disagree with the above. I think it depends on how the 
target handles its internal configuration.

If the target assigns the same TPGT to all nodes accessible via a 
portal, then the TPGT can be considered an attribute of the portal, not 
the node-portal link. I am specifically thinking of the case in 
draft-ietf-ips-iscsi-mib-10.txt where iscsiTgtPortalNodeIndexOrZero 
would be zero (Or I think I am, the MIB document has changed since I 
last studied it).

So in that case, the target can always have a TPGT available. And it 
would be easier to let it just return it, rather than making its return 
depend on session type.

I also like this idea as I have things coded this way and I'd rather 
not change it if I don't have to. :-)

> reinstatement once the InitiatorName-ISID tuple matches.

Yes. While I would rather the target not HAVE to use No-Name, I agree 
that if it does, then any new discovery session to a "No-Name" portal 
triggers reinstatement once the InitiatorName-ISID tuple matches.

> I personally think it is easier to implement since the same ISID RULE 
> is used to manage discovery and normal sessions alike (you can map 
> your implmentation's TPGT for the "No-Name thing" to index 0, and 
> start your valid TPGTs from index 1 - AFAICT, that's legal).

I'm sorry if I was confusing. I have always wanted the same ISID rule 
to apply. :-)

> target network entity which the requesting initiator is authorized to

True.

I guess my thought was that this can be handled by either 
special-casing SendTargets processing, or uploading a config to each 
card. Said config would include both nodes served by the card and nodes 
served by other cards. Either way, there is no need for 
card-coordination during the middle of login processing.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 29 Jul 2005 18:01:50 -0700

OK, I see two options in dealing with TPGTs.  I sketched out the options 
and respective implications below as I see them.  Since I plan to 
mandate one of the two based on the list feedback in the Implementer's 
guide, please review carefully - your initiator, target or NIC *may be* 
affected.

I personally am leaning towards Option A because I see it's closest to 
RFC 3720 semantics and would require no new conceptual additions.

Mallikarjun

Mallikarjun Chadalapaka

Options:

A. TPGTs are always Node-scoped.  If Node name isn't specified in the 
discovery Login Request PDU, TPGT is meaningless and can't be inferred 
(or inferred to be invalid).

B. TPGTs are always Node-scoped.  If Node name isn't specified in the 
discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. 
  This No-Name iSCSI Node has its own TPGT numbering space - one tag for 
each physically possible portal group - and thus the TPGT can be inferred.

Implications -

Option A:

1. There can only be one no-named discovery session to a Network Entity 
with a given InitiatorName-ISID combination. A new no-named discovery 
session reinstates the first.  If this is your current behavior, speak up.

2. An initiator doing parallel discovery probing of multiple IP 
addresses using a generic InitiatorName-ISID tuple may see all but one 
of its probe attempts fail in each set of IP addresses hosted by one 
Network Entity (if you're doing SLP/iSNS-based discovery, this may be a 
no-op).

3. To realize the session reinstatement of a no-named discovery session 
on matching InitiatorName-ISID, target CPU software may have to be 
involved in Login processing for no-named discovery sessions.  Depending 
on your implementation, it may not all be offloaded to hardware.

Option B:
1. There can be multiple no-named discovery sessions to a Network Entity 
with a given InitiatorName-ISID combination - one for each TPGT of the 
No-Name Node. A new no-named discovery session reinstates an existing 
discovery session only if the TPGT matches.  If this is your current 
behavior, speak up.

2. An initiator doing parallel discovery probing of multiple IP 
addresses using a generic InitiatorName-ISID tuple may have all 
successful probes, but all such probes of each set of IP addresses 
hosted by one Network Entity return duplicate discovery data (if you're 
doing SLP/iSNS-based discovery, this may be a no-op).

3. For some implementations, it is technically feasible to offload the 
login processing for a no-named discovery session.  Target CPU software 
is not required to be involved (although your code may have other 
reasons to get involved).

4. Introduces a new notion of a "No-Name" iSCSI Node that must host all 
physically possible portal groups.  No-Name Node is however not a 
full-fledged Node because TargetPortalGroupTag must not be returned - 
though it can be inferred - on no-named discovery sessions per RFC 3720, 
and is limited to hosting only the no-named discovery sessions.

---

From: Julian Satran <[email-masked]>
Date: Sun, 31 Jul 2005 21:30:19 +0300

Mallikarjun,

Option A was the one considered when iSCSI was written. Bill is talking 
about an implementation in which TPGT is an entity by its own used by 
several targets.
His parallel with the target port-id illustrates this point. TPGT however 
was not intended to be a target port-id by itself.

Regards,
Julo

30-07-05 04:01

To
IPS <[email-masked]>
cc

Subject
Re: [Ips] Re: ISID and Discovery Re: 
draft-ietf-ips-iscsi-impl-guide-00.txt

Mallikarjun

Mallikarjun Chadalapaka

Options:

Implications -

Option A:

Option B: