From owner-ips@ece.cmu.edu Thu Nov 1 02:06:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22773
for ; Thu, 1 Nov 2001 02:06:33 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA16C5207899
for ips-outgoing; Thu, 1 Nov 2001 01:12:05 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA16C2l07893
for ; Thu, 1 Nov 2001 01:12:02 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA18848
for ; Thu, 1 Nov 2001 07:11:56 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA16Bu839728
for ; Thu, 1 Nov 2001 07:11:56 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: Re: iSCSI:SCSI responses for iSCSI errors
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 08:11:52 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 08:11:55,
Serialize complete at 01/11/2001 08:11:55
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Ken,
It is entirely up to the implementer.
IMHO R2Ts that where not sent yet don't have to be sent.
A response PDU will close nicely the cycle.
The whole purpose of the delay is to avoid having PDUs carrying the ITT
hit the target
when the target has cleared its own control structures referring to the
task.
Julo
"Ken Sandars"
Sent by: owner-ips@ece.cmu.edu
31-10-01 19:08
Please respond to "Ken Sandars"
To:
cc:
Subject: iSCSI:SCSI responses for iSCSI errors
Gidday all,
With reference to 3.4.2, when a target detects an error
does:
'...MUST wait until it receives a Data PDU with the F
bit set, in the last expected sequence, before sending the
Response PDU'
imply the target waits for the entire Expected Data Transfer
Length worth to be transferred?
If so, the target may have to R2T for the solicited data! Should
it R2T with 'correct' values, regardless of what the initiator sent?
In this case it is possible that this clean-up action actually solicits
all the required data, however, the command is still going to get
a response with sense data indicating an abort.
Is it possible to just reject the original command PDU when validity
checking picks up one of these errors? Any Data-Out PDUs
in the pipeline which belong to this rejected command can be silently
discarded by the target. What am I missing?
Thoughts?
Ken Sandars
ksandars@eurologic.com
Eurologic Systems
+44 117 930 9616
From owner-ips@ece.cmu.edu Thu Nov 1 03:44:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04597
for ; Thu, 1 Nov 2001 03:44:33 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA17q4M13482
for ips-outgoing; Thu, 1 Nov 2001 02:52:04 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sansrv1.san-rad.co.il ([212.199.104.228])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA17pRl13436
for ; Thu, 1 Nov 2001 02:51:30 -0500 (EST)
content-class: urn:content-classes:message
Subject: RE: iSCSI: New iSCSI MIB draft
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Disposition-Notification-To: "Michele Hallak - Stamler"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Thu, 1 Nov 2001 09:52:53 +0200
Message-ID: <838D8D2617300146B7F47E4D9AE7FF10114A0E@SANSRV1.SAN-RAD.CO.IL>
Thread-Topic: iSCSI: New iSCSI MIB draft
Thread-Index: AcFiRAs1SBgPmPydQ/SAe6ZBP+HQ0AAZXx9w
From: "Michele Hallak - Stamler"
To: "Mark Bakke" , "IPS"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fA17pYl13440
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
Hi,
1.I see that the target access list is still read-only. How do you think
that it should be configured?
2. Who should configure the aliases of the iscsi targets and initiators?
3. Same question for the portals.
Thanks,
Michele
-----Original Message-----
From: Mark Bakke [mailto:mbakke@cisco.com]
Sent: Wednesday, October 31, 2001 9:01 PM
To: IPS
Subject: Re: iSCSI: New iSCSI MIB draft
For those who are more pictorially inclined when looking at
MIBs, I have an updated MIB tree drawing available at:
ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-03.pd
f
--
Mark
Mark Bakke wrote:
>
> We have submitted a new iSCSI MIB draft to the repository.
> Until it becomes available, it may be retrieved as either
> a gzipped or text version from:
>
> ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt.gz
>
> ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt
>
> A matching UML drawing is available at:
>
> ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-03.pdf
>
> The table hierarchy has been significantly flattened. This does
> not change the object model, but does reduce the number of redundant
> levels of OIDs when address individual objects. I will send a
> new table structure drawing soon.
>
> We will send a list of open issues to the IPS list shortly.
>
> Thanks,
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054
From owner-ips@ece.cmu.edu Thu Nov 1 05:15:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09189
for ; Thu, 1 Nov 2001 05:15:49 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA19G1J18109
for ips-outgoing; Thu, 1 Nov 2001 04:16:01 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from best.eurologic.com ([193.120.246.5])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA19Fwl18102
for ; Thu, 1 Nov 2001 04:15:58 -0500 (EST)
Received: from COORS (coors.eurologic.com [192.168.7.111] (may be forged))
by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id JAA14293;
Thu, 1 Nov 2001 09:12:16 GMT
Message-ID: <004001c162b5$e87a8230$6f07a8c0@COORS>
From: "Ron Cohen"
To: "ips" , "Santosh Rao"
References: <008f01c16232$4d808640$3d7db184@trebiaazner66z> <3BE0569C.A6CCCAF5@cup.hp.com>
Subject: Re: iSCSI: current UNH Plugfest: Autosense
Date: Thu, 1 Nov 2001 09:16:21 -0000
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Santosh,
I don't see how you can have autosense mandatory and not have sense data
available. I would tend to agree with Anshul that the sense data MUST be
provided.
The Check Condition/Request Sense mechanisms of parallel SCSI are archaic.
In the old days, you couldn't have autosense because you couldn't have sense
data coming in when the command had data going out (Write). In the end,
this mechanism was a pain in the ass -- its basically saying that an error
occurred but I'm not telling you what it is.
Returning a Check Condition with no sense data in the example you give with
an error in the data segment does not seem correct to me. I would assume
that the SCSI LLP would return a driver error in this case indicating that
the data segment was lost rather than a SCSI error.
Ron
----- Original Message -----
From: "Santosh Rao"
To: "Anshul Chadda"
Cc:
Sent: Wednesday, October 31, 2001 7:53 PM
Subject: Re: iSCSI: current UNH Plugfest
> Anshul,
>
> I don't know why the initiator should care if the sense data arrived
> along with the CHECK CONDITION scsi status or not. (?)
>
> Most, if not all, SCSI initiator stacks have some form of indicating
> sense_status from SCSI LLP (hba driver, device driver, mini-port driver,
> etc) to SCSI ULP (class driver, target driver, etc), which indicates
> what the status of the sense operation was and whether sense data is
> available or not.
>
> For instance, you also need to deal with a scenario where the target
> sends a SCSI status of CHECK CONDITION and accompanies it with the sense
> data in the data segment. However, the initiator encounters a data
> digest error on the sense data data segment and drops the sense data
> data segment. The initiator can always choose to complete the I/O and
> return the SCSI status back to its SCSI ULP, indicating that no sense
> data was available.
>
> I don't see why you would need the wording tightened to a MUST.
> Initiators must not assume that the sense data will always be available
> on a check condition. The sense operation may be unsuccessful and no
> sense data may be available.
>
> Regards,
> Santosh
>
>
> > Anshul Chadda wrote:
> >
> > Hello:
> > As this issue has come up with setting CHECK CONDITION in the SCSI
> > Response. It is assumed that if CHECK CONDITION is set in the SCSI
> > Response PDU, then there has to be sense data accompanied with it. So
> > as far as I see it, it would help if the following sentence in the
> > draft has the MUST/must in there. In the current wording, i can think
> > that if there is no data segment in the SCSI Response PDU for a CHECK
> > CONDITION, it is still OK.
> >
> > In draft 8, the sentence looks like the following:
> > -------------------------------------------------------
> > 3.4.6 Data Segment - Sense and Response Data Segment
> >
> > iSCSI targets MUST support and enable autosense. If Status is CHECK
> > CONDITION (0x02), then the Data Segment contains sense data for the
> > failed command.
> >
> > -------------------------------------------------------
> >
> > It can be changed to the following:
> >
> > -------------------------------------------------------
> > 3.4.6 Data Segment - Sense and Response Data Segment
> >
> > iSCSI targets MUST support and enable autosense. If Status is CHECK
> > CONDITION (0x02), then the target MUST have sense data in the data
> > segment for the failed command.
> >
> > -------------------------------------------------------
> >
> > I don't know if there is a reason that the draft has the wording in
> > the current way. Apologies if this subject has already been
> > discussed.
> >
> > Regards,
> > Anshul
> >
>
> --------------------------------------------------------------------------
---------------------------------------
> >
> > 5. Some common error situations:
> >
> > 1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
> > some targets are not including the SenseLength as the first 2
> > bytes in the data segment. Although the format of the data
> > segment
> > is clear from the diagram in section 3.4.6 on page 62 of draft 8
> > (page 63 of draft 8a), the last entry in the diagram for the
> > SCSI
> > Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
> > misleading because it mentions only the Sense Data and Response
> > Data and omits the Sense Length. It would therefore be helpful
> > if the last entry in the diagram on page 58 were changed to
> > explicitly
> > reference the diagram on page 62, as in:
> >
> > Data Segment -- see section 3.4.6 (optional)
> >
> >
>
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################
>
From owner-ips@ece.cmu.edu Thu Nov 1 05:30:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09486
for ; Thu, 1 Nov 2001 05:30:00 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA19q2Y19983
for ips-outgoing; Thu, 1 Nov 2001 04:52:02 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA19q0l19976
for ; Thu, 1 Nov 2001 04:52:00 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA31824
for ; Thu, 1 Nov 2001 10:51:54 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA19pr827476
for ; Thu, 1 Nov 2001 10:51:53 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: Re: iSCSI: current UNH Plugfest
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 11:51:49 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 11:51:53,
Serialize complete at 01/11/2001 11:51:53
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Bob,
Comments in text.
Thanks,
Julo
"Robert D. Russell"
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:06
Please respond to "Robert D. Russell"
To: ips@ece.cmu.edu
cc:
Subject: Re: iSCSI: current UNH Plugfest
Attached are some new issues that arose during the iSCSI plugfest at
UNH on Tuesday 29-Oct-2001.
(Note: these issues do not take into account any modifications or
clarifications that occured in the standard due to the issues raised
on Monday.)
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
-----------------------------------------------------------------------------
1. Situation: as the first command on a new TCP connection, the initiator
sends a login with T=1, CSG=1, NSG=3, and valid InitiatorName,
TargetName,
and SessionType keys. However, there is also a valid key having an
invalid value, such as MaxConnections=abcd (i.e., not a number after
the
'=') or MaxConnections4 (i.e., missing the '=').
What should the target do?
Interpretation 1:
According to section 3.10.4 page 82 of draft 8 (page 83 of draft 8a),
"Any other key not understood by the target may be ignored by the
target without affecting basic function. However the Text Response
for a key that was not understood MUST be key=NotUnderstood."
Two things have to be clarified:
1. Does this section also apply to keys received in a login?
2. Can "NotUnderstood" also apply to "values of keys" that are not
understood, even if the key word itself is understood?
+++
1.NotUnderstood appears also in the negotiation section so it applies to
login.
I will remove it from the text section
2.It does not apply to values
+++
If the answer to these 2 of these questions is "yes", then the
appropriate
response would seem to be for the target to just ignore the key and
send
back MaxConnections=NotUnderstood as part of its next login response.
Interpratation 2:
According to section 8.7 page 129 of draft 8 (page 130 of draft 8a),
"A negotiation failure is considered one or both of the following:
- None of the choices or the stated value is acceptable to one
negotiating side. ..."
Clearly this stated value ("abcd") is not acceptable to the target.
Therefore, the following rule on page 129, draft 8 (page 130, draft 8a)
applies:
"- During Login, any failure in negotiation MUST be considered
as the login process failure and the connection must be dropped."
Therefore, the target should just drop the connection without sending
any login response back to the initiator.
Interpretation 3:
This is a login command that contains an error caused by the
initiator. Therefore, the target should send back a login response
with a status code of 0x0200 and then close the TCP connection.
+++ I think this is the correct interpretation and we will fix the wording
in section 8 to say this. I suggest:
- During Login, any failure in negotiation MUST be considered as the login
process failure and the login phase must be terminated. If the failure is
detected by the target, it must reject the login with the appropriate
code. The connection must be terminated by the initiator.
+++
2. Situation: on the first login command in operational parameter
negotiation
stage, the initiator sends no operational keys, thereby telling the
target
that it accepts all the default values for these keys. However, the
target
wants to negotiate the value of MaxConnections, so in the login
response
it sends back "MaxConnections=3" (for example). Should the initiator
send a response to this key or not?
The statement in section 2.2.4 on page 30 of draft 8 and 8a:
"For numerical (and single literal) negotiations, the responding party
MUST
respond with the required key.(...)"
makes it clear that the responding party MUST respond. However, in
this
situation, it is not clear who the responding party is.
+++ we are using the term offering and responding to distinguish them from
initiator and target and explicitly say (in 2.2.4) that the target may
offer keys
+++
Interpretation 1:
By not explicitly sending this key in the login command, the initiator
is implicitly offering the default value and therefore is the offering
party and the target is the responding party. The conclusion is that
the initiator does not have to send a response to this key from the
target.
+++ there is no implicit ofering of defaults. A default is accepted only
if the two parties are silent.
+++
Interpretation 2:
The target is the offering party because it is the party that
explicitly
stated the key for the first time during these negotiations. The
conclusion is that the initiator MUST send a response to this key from
the
target.
NOTE 1: If interpretation 1 is correct, it would seem to imply that the
target MUST respond to every key whether or not it is present in the
login from the initiator, even if it does not want to change the
default
value. The reason is that a missing key is an implicit offer of the
default value, and the responding party MUST respond. Is this a
correct
interpretation?
NOTE 2: The following statements in section 2.2.4 page 29 of draft 8a:
Originator-> =
Responder-> =|NOtUnderstood
seem to imply that the originator is the party (initiator or target)
that
explicitly offers a key, and that omitting a key is not an implicit
offer
of that key with the default value. However, even in the revised draft
8a
there is no definition of "Originator" and/or "Responder" that would
make this clear. Adding to the standard these definitions, and an
explicit statement that "a missing key does not constitute an implicit
offer of the default" would help eliminate misunderstandings. In
addition, including an example of this situation (where an initiator
omits a key and the target offers the key) would be a big help.
+++ will do +++
3. Some of the login phase examples given in Appendix A of both draft 8
and
8a do not follow the rule in section 3.12.4 page 87 of draft 8 (page 88
of draft 8a):
"The next stage value is valid only when the T bit is 1 and is
reserved otherwise."
and the rule in section 3 page 48 of draft 8 (page 49 of draft 8a):
"Any reserved fields and values MUST be 0 unless specified
otherwise."
If these rules are applied, all examples having T=0 should also
have NSG=0. Presently all of them with T=0 also have NSG=1 or NSG=3.
+++ Will fix the examples +++
4. Situation: The initiator and target have successfully completed the
login phase for a discovery session and are now in full feature phase.
The initiator sends a text command containing the single key:
"SendTargets=". What response is expected from the target?
Interpretation 1:
According to the explanation on page 188 of draft 8 (page 189 of
draft 8a):
"If no target name is specified, the session should respond with
addresses only for the target to which the session is logged in.
This MUST be supported on operational sessions, and MAY NOT
return targets other than the one to which the session is logged in."
However, for a discovery session there is no target per se (the
initiator does not specify a TargetName= during login), so the
target therefore follows the rule on page 188 of draft 8 (page 189
of draft 8a):
+++
That is not strictly correct. You may use discovery to determine the
addresses and portal groups for a specific target - i.e. you may give a
target-name. If you give a target name that is all you get. If don't give
a name you get all the targets you are allowed to get to.
++++
"A SendTargets response MAY contain no target names, if there are no
targets for the requesting initiator to access."
and sends back a Text Response with no keys in it.
Interpretation 2:
In a discovery session, the key "SendTargets=" makes no sense and
should
be treated by the target in the same manner as the key
"SendTargets=all".
5. Some common error situations:
1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
some targets are not including the SenseLength as the first 2
bytes in the data segment. Although the format of the data segment
is clear from the diagram in section 3.4.6 on page 62 of draft 8
(page 63 of draft 8a), the last entry in the diagram for the SCSI
Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
misleading because it mentions only the Sense Data and Response
Data and omits the Sense Length. It would therefore be helpful
if the last entry in the diagram on page 58 were changed to
explicitly
reference the diagram on page 62, as in:
Data Segment -- see section 3.4.6 (optional)
+++ will do +++
2) - after sending a CmdSN on an initial login, some initiators are
incrementing it before sending their first non-immediate command.
(i.e., if the initial login contains CmdSN=123, they are sending
CmdSN=124 on the first non-immediate command after the login phase).
Section 3.12.10 on page 89 of draft 8 (page 90 of draft 8a) is
clear that in this example the first non-immediate command should
carry CmdSN=123, not 124. This was an issue at the July plugfest
and apparently some implementations have not been updated to conform
to the draft 8 standard in their handling of CmdSN.
From owner-ips@ece.cmu.edu Thu Nov 1 06:06:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10028
for ; Thu, 1 Nov 2001 06:06:17 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1ACGg21166
for ips-outgoing; Thu, 1 Nov 2001 05:12:16 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1ACDl21154
for ; Thu, 1 Nov 2001 05:12:13 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA33480
for ; Thu, 1 Nov 2001 11:12:02 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1AC2858072
for ; Thu, 1 Nov 2001 11:12:02 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: Re: iSCSI: current UNH Plugfest
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 12:11:57 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 12:12:02,
Serialize complete at 01/11/2001 12:12:02
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Anshul,
IMHO a single MUST in the paragraph is strong enough and covers all the
cases.
Julo
"Anshul Chadda"
Sent by: owner-ips@ece.cmu.edu
31-10-01 19:34
Please respond to "Anshul Chadda"
To:
cc:
Subject: Re: iSCSI: current UNH Plugfest
Hello:
As this issue has come up with setting CHECK CONDITION in the SCSI
Response. It is assumed that if CHECK CONDITION is set in the SCSI
Response PDU, then there has to be sense data accompanied with it. So as
far as I see it, it would help if the following sentence in the draft has
the MUST/must in there. In the current wording, i can think that if there
is no data segment in the SCSI Response PDU for a CHECK CONDITION, it is
still OK.
In draft 8, the sentence looks like the following:
-------------------------------------------------------
3.4.6 Data Segment - Sense and Response Data Segment
iSCSI targets MUST support and enable autosense. If Status is CHECK
CONDITION (0x02), then the Data Segment contains sense data for the failed
command.
-------------------------------------------------------
It can be changed to the following:
-------------------------------------------------------
3.4.6 Data Segment - Sense and Response Data Segment
iSCSI targets MUST support and enable autosense. If Status is CHECK
CONDITION (0x02), then the target MUST have sense data in the data segment
for the failed command.
-------------------------------------------------------
I don't know if there is a reason that the draft has the wording in the
current way. Apologies if this subject has already been discussed.
Regards,
Anshul
-----------------------------------------------------------------------------------------------------------------
5. Some common error situations:
1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
some targets are not including the SenseLength as the first 2
bytes in the data segment. Although the format of the data segment
is clear from the diagram in section 3.4.6 on page 62 of draft 8
(page 63 of draft 8a), the last entry in the diagram for the SCSI
Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
misleading because it mentions only the Sense Data and Response
Data and omits the Sense Length. It would therefore be helpful
if the last entry in the diagram on page 58 were changed to
explicitly
reference the diagram on page 62, as in:
Data Segment -- see section 3.4.6 (optional)
From owner-ips@ece.cmu.edu Thu Nov 1 07:48:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13243
for ; Thu, 1 Nov 2001 07:48:04 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1Baxw09111
for ips-outgoing; Thu, 1 Nov 2001 06:36:59 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Bawl09106
for ; Thu, 1 Nov 2001 06:36:58 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA21124
for ; Thu, 1 Nov 2001 12:36:49 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1Ban887888
for ; Thu, 1 Nov 2001 12:36:49 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: RE: iSCSI: current UNH Plugfest
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 13:36:45 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 13:36:49,
Serialize complete at 01/11/2001 13:36:49
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Bob,
I assume that your statement about request sense refers to a data-in PDU
not a data segment (e.g., not the data segment of a response PDU).
Normally a request sense will result in a single input PDU - a Data-IN
including also the good status for the request sense (if the implementer
had enough goodwill to collapse the 2 phases).
As for the MUST the paragraph has already a MUST (MUST support autosense).
Julo
Robert Snively
Sent by: owner-ips@ece.cmu.edu
31-10-01 22:39
Please respond to Robert Snively
To: "'Santosh Rao'" , Anshul Chadda
cc: ips@ece.cmu.edu
Subject: RE: iSCSI: current UNH Plugfest
The "MUST have sense information if CHECK CONDITION" is
a property of SCSI that requires the use of autosensing,
as iSCSI does.
It is only non autosensing drivers that will present
CHECK CONDITION indications with sense data missing.
Sense Data will never be generated in a data segment to any command except
REQUEST SENSE. In that case, CHECK CONDITION will never
be indicated unless the REQUEST SENSE command failed in
some way, and (if autosensing is used), the CHECK CONDITION
will be associated with its own set of sense information in
the response PDU.
Note that if the unit cannot assemble relevant sense information
from the attached hardware, that is in itself a CHECK CONDITION,
and the corresponding inability to access critical hardware
must be posted in the sense information.
That is why MUST is the proper requirement.
Bob
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, October 31, 2001 11:53 AM
> To: Anshul Chadda
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: current UNH Plugfest
>
>
> Anshul,
>
> I don't know why the initiator should care if the sense data arrived
> along with the CHECK CONDITION scsi status or not. (?)
>
> Most, if not all, SCSI initiator stacks have some form of indicating
> sense_status from SCSI LLP (hba driver, device driver,
> mini-port driver,
> etc) to SCSI ULP (class driver, target driver, etc), which indicates
> what the status of the sense operation was and whether sense data is
> available or not.
>
> For instance, you also need to deal with a scenario where the target
> sends a SCSI status of CHECK CONDITION and accompanies it
> with the sense
> data in the data segment. However, the initiator encounters a data
> digest error on the sense data data segment and drops the sense data
> data segment. The initiator can always choose to complete the I/O and
> return the SCSI status back to its SCSI ULP, indicating that no sense
> data was available.
>
> I don't see why you would need the wording tightened to a MUST.
> Initiators must not assume that the sense data will always be
> available
> on a check condition. The sense operation may be unsuccessful and no
> sense data may be available.
>
> Regards,
> Santosh
>
>
> > Anshul Chadda wrote:
> >
> > Hello:
> > As this issue has come up with setting CHECK CONDITION in the SCSI
> > Response. It is assumed that if CHECK CONDITION is set in the SCSI
> > Response PDU, then there has to be sense data accompanied
> with it. So
> > as far as I see it, it would help if the following sentence in the
> > draft has the MUST/must in there. In the current wording, i
> can think
> > that if there is no data segment in the SCSI Response PDU
> for a CHECK
> > CONDITION, it is still OK.
> >
> > In draft 8, the sentence looks like the following:
> > -------------------------------------------------------
> > 3.4.6 Data Segment - Sense and Response Data Segment
> >
> > iSCSI targets MUST support and enable autosense. If Status is CHECK
> > CONDITION (0x02), then the Data Segment contains sense data for the
> > failed command.
> >
> > -------------------------------------------------------
> >
> > It can be changed to the following:
> >
> > -------------------------------------------------------
> > 3.4.6 Data Segment - Sense and Response Data Segment
> >
> > iSCSI targets MUST support and enable autosense. If Status is CHECK
> > CONDITION (0x02), then the target MUST have sense data in the data
> > segment for the failed command.
> >
> > -------------------------------------------------------
> >
> > I don't know if there is a reason that the draft has the wording in
> > the current way. Apologies if this subject has already been
> > discussed.
> >
> > Regards,
> > Anshul
> >
> >
> --------------------------------------------------------------
> ---------------------------------------------------
> >
> > 5. Some common error situations:
> >
> > 1) - when a SCSI Response contains a CHECK CONDITION
> (Status=0x02),
> > some targets are not including the SenseLength as the first 2
> > bytes in the data segment. Although the format of the data
> > segment
> > is clear from the diagram in section 3.4.6 on page 62
> of draft 8
> > (page 63 of draft 8a), the last entry in the diagram for the
> > SCSI
> > Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
> > misleading because it mentions only the Sense Data
> and Response
> > Data and omits the Sense Length. It would therefore
> be helpful
> > if the last entry in the diagram on page 58 were changed to
> > explicitly
> > reference the diagram on page 62, as in:
> >
> > Data Segment -- see section 3.4.6 (optional)
> >
> >
>
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################
>
From owner-ips@ece.cmu.edu Thu Nov 1 08:24:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15560
for ; Thu, 1 Nov 2001 08:24:59 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1CS3311869
for ips-outgoing; Thu, 1 Nov 2001 07:28:03 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1CS0l11863
for ; Thu, 1 Nov 2001 07:28:01 -0500 (EST)
Received: (from mailgate@localhost)
by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id HAA16963
for ips@ece.cmu.edu; Thu, 1 Nov 2001 07:27:55 -0500 (EST)
Received: from compuserve.com (dal-tgn-tkl-vty21.as.wcom.net [216.192.224.21])
by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id HAA16946
for ; Thu, 1 Nov 2001 07:27:48 -0500 (EST)
Message-ID: <3BE140FC.1E188857@compuserve.com>
Date: Thu, 01 Nov 2001 06:33:00 -0600
From: Ralph Weber
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector
Subject: FCencap: Missing SOF/EOF characters
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Off and on I hear complaints that it is not obvious
why draft-ietf-ips-fcencapsulation-03.txt fails to
list all the possible Fibre Channel SOF and EOF
characters in 5.3.
To address this concern, I propose adding the following
text at the end of 5.3.
Note: Some of the SOF and EOF characters defined by
Fibre Channel are not listed in Table 1 and Table 2
because the design an operating characteristics
of an IP Network make it inappropriate for
transporting FC Frames containing those SOF and/or
EOF characters.
I proposed to make this addition in a new draft that
will be available in time for consideration in Salt
Lake.
Comment appreciated.
Ralph Weber
From owner-ips@ece.cmu.edu Thu Nov 1 08:29:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15773
for ; Thu, 1 Nov 2001 08:29:31 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1CULs11985
for ips-outgoing; Thu, 1 Nov 2001 07:30:21 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1CUJl11981
for ; Thu, 1 Nov 2001 07:30:19 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA118966
for ; Thu, 1 Nov 2001 13:30:12 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1CUC808296
for ; Thu, 1 Nov 2001 13:30:12 +0100
Importance: Normal
Subject: iSCSI: IPsec tunnel / transport mode decision
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001
Message-ID:
From: "Ofer Biran"
Date: Thu, 1 Nov 2001 14:31:26 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 14:30:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
I'd like to drive this open issue into group consensus. It seems to
me that the tendency was more toward making tunnel mode a MUST as iFCP
and FCIP did, mainly due the option of integrating an existing IPsec
chip/box with the iSCSI implementation offering. If we reach this decision,
we may choose even not to mention transport mode (as MAY or some other
recommending text).
There is an excellent analysis made by Bernard Aboba in Section
"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
that can help us with this decision (also Section "5.2. NAT traversal" is
relevant).
Regards,
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
From owner-ips@ece.cmu.edu Thu Nov 1 09:36:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19150
for ; Thu, 1 Nov 2001 09:36:28 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1DFFQ14647
for ips-outgoing; Thu, 1 Nov 2001 08:15:15 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1DFDl14642
for ; Thu, 1 Nov 2001 08:15:13 -0500 (EST)
Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49])
by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id fA1DFwT04167
for ; Thu, 1 Nov 2001 08:15:58 -0500 (EST)
From: "Eddy Quicksall"
To:
Subject: RE: iSCSI: current UNH Plugfest
Date: Thu, 1 Nov 2001 08:14:48 -0500
Message-ID: <000101c162d7$330d39c0$0102a8c0@eddylaptop>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
I am reluctant to say this because I think most people think the
initiator/target must check for correctness ... but, it is my feeling that
that job should be up to a basher program. The target should not be in the
business of diagnosing the initiator. The only time a target should check a
field is when it could crash the system or data. Some format errors may have
no consequences whatsoever.
Eddy
-----Original Message-----
From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
Sent: Wednesday, October 31, 2001 05:39 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
Attached are the new issues that arose during the iSCSI plugfest
at UNH on Wednesday 31-Oct-2001.
(Note: these issues do not take into account any modifications or
clarifications that occured in the standard due to the issues raised
on Monday or Tuesday.)
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
------------------------------------------------------------------------
----
1. Are receivers (initiator or target) REQUIRED to check that reserved
bits and/or fields are set to 0?
Section 3 on page 48 of draft 8 says:
"Any bits not defined MUST be set to zero. Any reserved fields and
values MUST be 0 unless specified otherwise."
and Section 8.3 on page 127 of draft 8 says:
"Explicit violations of the PDU layout rules stated in this
document
are format errors. This when detected, usually indicates a major
implementation flaw in one of the parties.
When a target or an initiator receives an iSCSI PDU with a format
error, it MUST reset all transport connections in the session
immediately and escalate the format error to session recovery
(section 8.11.4)."
According to these rules, a PDU with reserved bits and/or fields that
are not set to 0 violates the PDU layout rules. Therefore, if an
initiator or target receives such a PDU, it should immediately close
all connections in the session and go to session recovery.
Clearly a format error has extremely severe consequences!
Although all vendors are setting reserved bits and fields to 0 on
PDUs they are sending, many are NOT checking PDUs they are receiving
to see if these bits and fields are set to 0. Basically, vendors are
saying "who cares if reserved bits and/or fields in incoming PDUs are
not zero? We do not want to take the time to do this checking, and
there is no benefit to doing it. As long as the non-reserved bits
and
fields are set properly, we can and should proceed. Any time devoted
to doing this checking is wasted in 99+% of the cases, and in the
(unlikely) case that a non-zero bit or field is found, the
consequences are too severe."
There should be some statement in the standard to clarify what
checking
is required and what is optional.
2. A similar situation arises with respect to checking the consistency
of fields such as Version-max, Version-min and Version-active in
Login
Requests and Login Responses.
For example, consider the Version-max field.
Section 3.12.5 says:
"All Login requests within the Login phase MUST carry the same
Version-max."
All vendor initiators are setting Version-max correctly on all
login requests they are sending, but many vendor targets are NOT
checking received login requests to ensure that this rule is
enforced.
In particular, many targets simply use the Version-max and
Version-min
on the first login request they receive on a new connection, and then
they ignore these fields on all subsequent login requests in the same
login phase.
Strictly speaking, a change in the Version-max field during the login
phase constitutes a protocol error according to section 8.8 on page
130
of draft 8:
"All violations of iSCSI PDU exchange sequences specified in this
draft are also protocol errors. This category of errors can be
addressed only by fixing the implementations; iSCSI defines Reject
and response codes to enable this".
Therefore the target should send back a login response with a status
of 0x0200 and then close the connection.
However, Section 3.12.5 also says:
"The target MUST use the value presented with the first login
request."
This rule seems to imply that the value CAN change, because if it
cannot
change, then it doesn't matter which one of the login requests it is
taken from, they are all the same anyway.
The suggestion is to keep the requirement that the target MUST use
the
value presented on the first login request, but to allowed the target
to ignore the value presented on all subsequent login requests in the
same login phase. A similar rewording should be done for the other
fields.
3. Can commands be sent out of order on the same connection?
The behavior of targets is clearly specified in Section 2.2.2.3 on
page 25 of draft 8, which says:
"Except for the commands marked for immediate delivery the iSCSI
target layer MUST eliver the commands for execution in the order
specified by CmdSN."
Section 2.2.2.3 on page 26 of draft 8 also says:
"- CmdSN - the current command Sequence Number advanced by 1 on
each command shipped except for commands marked for immediate
delivery."
but the meaning of the term "shipped" is vague, and does not
necessarily
require that the PDUs arrive on the other end of a TCP connection
in the same order that the CmdSN values were assigned to these PDUs.
Some initiators have been designed to send commands out of CmdSN
order on one connection. Consider the situation where there is only
one connection and a high-level dispatcher creates a PDU for a SCSI
command that involves writing immediate data to the target. This PDU
is enqueued to a lower-level layer which has to setup, start, and
wait-for a DMA operation to move the immediate data into an onboard
buffer before the PDU can be put onto the wire. While this is
happening, the dispatcher creates another unrelated PDU for a SCSI
read command (for example), and when this PDU is passed to the
lower-level layer it can be sent immediately, ahead of the previous
write PDU and therefore out of order on this connection.
The standard clearly allows this to happen if the two PDUs were sent
on different connections, and seems to imply that this can also
happen
when the two PDUs are sent on the same connection.
The suggestion is to put in the standard an explicit statement that
this is allowed or not allowed, as appropriate.
If this is allowed, such a statement would avoid the erroneous
assumption being made by some target implementers that within a
single
connection, commands will arrive in order.
If this is not allowed, such a statement would avoid the erroneous
assumption being made by some initiator implementers that within a
single connection, commands can be put on the wire out of order.
4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
now allow: "A value of 0 indicates no limit."
Is this useful? Does it buy anything?
The difficulties implementers are having with this are:
1) It is a special case.
2) It causes discontinuous ranges (for example, [0,64..2**24])
3) It violates the min/max function normally used for the key.
4) There is always a limit anyway.
Consider FirstBurstSize, which can have a value that is described
as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
is selected.
I one side offers 0 to mean unlimited, and the other side
has a limit, it will reply with that limit, say 128 Kbytes.
Therefore, the result is not min(0, 128K) but rather max(0, 128K).
The statement in the standard that "the minimum of the 2 numbers is
selected" is therefore wrong when one of the numbers is 0.
Furthermore, when an initiator or target receives an offer for one
of these keys, it cannot simply check that the offered value is
legal by testing it against some minimum and maximum. It must first
check for 0 and then only if that check shows the value is non-zero
can it do the min/max range check for legality (i.e., 64-2**24).
Finally, there is always a limit. If nothing else it is the
limit imposed by the 24-bit DataSegmentLength field of the PDU
requesting the transfer. It is useless to specify a FirstBurstSize
(or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
the largest possible DataSegmentLength in any PDU that can use
this value is 2**24-1.
The suggestion is to just eliminate this special case of 0 and
require
that the range 64-to-(2**24-1) be used instead -- it has exactly the
same effect in all cases, it is easier to describe in the standard
because it avoids all the extra words, and it is easier to code
because it avoids all the special cases.
NOTE: the standard should specify the limit in the ranges for
MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
of 2**24. The number 2**24 cannot be represented in the 24-bit
DataSegmentLength field and therefore can never be used.
5. This is a suggestion for a minor rewording in the standard to avoid
misunderstandings.
In Appendix E on page 188 of draft 8 it says:
"The response to this command is a text response containing a list
of
targets and their addresses. Each target is returned as a target
record. A target record begins with the TargetName text key,
followed by a list of TargetAddress text keys, ..."
In fact, there are situations where there are no targets and/or no
addresses. These situations are clearly defined in the draft after
the sentences quoted above, but it would help if those sentences
at least hinted at the possibility that the lists could be empty
or might not contain addresses. A possible rewording would be:
"The response to this command is a text response containing a list
of
zero or more targets and, optionally, their addresses. Each target
is returned as a target record. A target record begins with the
TargetName text key, followed by a list of zero or more
TargetAddress text keys, ..."
6. This is a suggestion for another very minor rewording in the
standard.
At the end of section 2.2.3 on page 29 of draft 8 it says:
"Before full feature phase is established, only Login PDUs are
allowed. ..."
The suggested rewording is:
"Before full feature phase is established, only Login Request and
Login Response PDUs are allowed. ..."
From owner-ips@ece.cmu.edu Thu Nov 1 11:00:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22235
for ; Thu, 1 Nov 2001 11:00:51 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1EoQp21178
for ips-outgoing; Thu, 1 Nov 2001 09:50:26 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1EoOl21173
for ; Thu, 1 Nov 2001 09:50:24 -0500 (EST)
Received: from localhost (rdr@localhost)
by iol.unh.edu (8.9.3/8.9.3) with ESMTP id JAA02944;
Thu, 1 Nov 2001 09:50:04 -0500 (EST)
Date: Thu, 1 Nov 2001 09:50:04 -0500
From: "Robert D. Russell"
To: Julian Satran
cc: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Julian:
IMHO if we mean MUST then we MUST say MUST.
It is clear from the exchange between Anshul, Santosh and Robert
that we already have different interpretations of what
it means without MUST and hence we have interoperability problems.
In this particular case I agree with Anshul and Robert that the
standard should say MUST. Santosh's argument that in an error
case the data gets lost does not seem to be relevant --
in error cases lots of information gets lost and recovery is
necessary to get that information back. The spec provides for
this. We should not be introducing interoperability problems
because of a situation that may arise in the rare case of an error,
especially when the spec already deals with recovery of that
information when the error is detected.
Thanks,
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
On Thu, 1 Nov 2001, Julian Satran wrote:
> Anshul,
>
> IMHO a single MUST in the paragraph is strong enough and covers all the
> cases.
>
> Julo
>
>
>
>
> "Anshul Chadda"
> Sent by: owner-ips@ece.cmu.edu
> 31-10-01 19:34
> Please respond to "Anshul Chadda"
>
>
> To:
> cc:
> Subject: Re: iSCSI: current UNH Plugfest
>
>
>
> Hello:
> As this issue has come up with setting CHECK CONDITION in the SCSI
> Response. It is assumed that if CHECK CONDITION is set in the SCSI
> Response PDU, then there has to be sense data accompanied with it. So as
> far as I see it, it would help if the following sentence in the draft has
> the MUST/must in there. In the current wording, i can think that if there
> is no data segment in the SCSI Response PDU for a CHECK CONDITION, it is
> still OK.
>
> In draft 8, the sentence looks like the following:
> -------------------------------------------------------
> 3.4.6 Data Segment - Sense and Response Data Segment
> iSCSI targets MUST support and enable autosense. If Status is CHECK
> CONDITION (0x02), then the Data Segment contains sense data for the failed
> command.
> -------------------------------------------------------
>
> It can be changed to the following:
>
> -------------------------------------------------------
> 3.4.6 Data Segment - Sense and Response Data Segment
> iSCSI targets MUST support and enable autosense. If Status is CHECK
> CONDITION (0x02), then the target MUST have sense data in the data segment
> for the failed command.
> -------------------------------------------------------
> I don't know if there is a reason that the draft has the wording in the
> current way. Apologies if this subject has already been discussed.
>
> Regards,
> Anshul
>
> -----------------------------------------------------------------------------------------------------------------
>
> 5. Some common error situations:
>
> 1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
> some targets are not including the SenseLength as the first 2
> bytes in the data segment. Although the format of the data segment
> is clear from the diagram in section 3.4.6 on page 62 of draft 8
> (page 63 of draft 8a), the last entry in the diagram for the SCSI
> Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
> misleading because it mentions only the Sense Data and Response
> Data and omits the Sense Length. It would therefore be helpful
> if the last entry in the diagram on page 58 were changed to
> explicitly
> reference the diagram on page 62, as in:
>
> Data Segment -- see section 3.4.6 (optional)
>
>
>
>
>
From owner-ips@ece.cmu.edu Thu Nov 1 12:00:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23709
for ; Thu, 1 Nov 2001 12:00:23 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1FltX25921
for ips-outgoing; Thu, 1 Nov 2001 10:47:55 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Flrl25913
for ; Thu, 1 Nov 2001 10:47:53 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA130154
for ; Thu, 1 Nov 2001 16:47:46 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1Flf888876
for ; Thu, 1 Nov 2001 16:47:41 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: Re: iSCSI: current UNH Plugfest
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 17:47:37 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 17:47:46,
Serialize complete at 01/11/2001 17:47:46
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Bob,
The spec already says MUST. I don't agree that saying MUST twice is a
good practice.
Julo
"Robert D. Russell"
01-11-01 16:50
Please respond to "Robert D. Russell"
To: Julian Satran/Haifa/IBM@IBMIL
cc: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
Julian:
IMHO if we mean MUST then we MUST say MUST.
It is clear from the exchange between Anshul, Santosh and Robert
that we already have different interpretations of what
it means without MUST and hence we have interoperability problems.
In this particular case I agree with Anshul and Robert that the
standard should say MUST. Santosh's argument that in an error
case the data gets lost does not seem to be relevant --
in error cases lots of information gets lost and recovery is
necessary to get that information back. The spec provides for
this. We should not be introducing interoperability problems
because of a situation that may arise in the rare case of an error,
especially when the spec already deals with recovery of that
information when the error is detected.
Thanks,
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
On Thu, 1 Nov 2001, Julian Satran wrote:
> Anshul,
>
> IMHO a single MUST in the paragraph is strong enough and covers all the
> cases.
>
> Julo
>
>
>
>
> "Anshul Chadda"
> Sent by: owner-ips@ece.cmu.edu
> 31-10-01 19:34
> Please respond to "Anshul Chadda"
>
>
> To:
> cc:
> Subject: Re: iSCSI: current UNH Plugfest
>
>
>
> Hello:
> As this issue has come up with setting CHECK CONDITION in the SCSI
> Response. It is assumed that if CHECK CONDITION is set in the SCSI
> Response PDU, then there has to be sense data accompanied with it. So as
> far as I see it, it would help if the following sentence in the draft
has
> the MUST/must in there. In the current wording, i can think that if
there
> is no data segment in the SCSI Response PDU for a CHECK CONDITION, it is
> still OK.
>
> In draft 8, the sentence looks like the following:
> -------------------------------------------------------
> 3.4.6 Data Segment - Sense and Response Data Segment
> iSCSI targets MUST support and enable autosense. If Status is CHECK
> CONDITION (0x02), then the Data Segment contains sense data for the
failed
> command.
> -------------------------------------------------------
>
> It can be changed to the following:
>
> -------------------------------------------------------
> 3.4.6 Data Segment - Sense and Response Data Segment
> iSCSI targets MUST support and enable autosense. If Status is CHECK
> CONDITION (0x02), then the target MUST have sense data in the data
segment
> for the failed command.
> -------------------------------------------------------
> I don't know if there is a reason that the draft has the wording in the
> current way. Apologies if this subject has already been discussed.
>
> Regards,
> Anshul
>
>
-----------------------------------------------------------------------------------------------------------------
>
> 5. Some common error situations:
>
> 1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
> some targets are not including the SenseLength as the first 2
> bytes in the data segment. Although the format of the data
segment
> is clear from the diagram in section 3.4.6 on page 62 of draft 8
> (page 63 of draft 8a), the last entry in the diagram for the SCSI
> Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
> misleading because it mentions only the Sense Data and Response
> Data and omits the Sense Length. It would therefore be helpful
> if the last entry in the diagram on page 58 were changed to
> explicitly
> reference the diagram on page 62, as in:
>
> Data Segment -- see section 3.4.6 (optional)
>
>
>
>
>
From owner-ips@ece.cmu.edu Thu Nov 1 12:28:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24446
for ; Thu, 1 Nov 2001 12:28:59 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1Gski01734
for ips-outgoing; Thu, 1 Nov 2001 11:54:46 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Gsil01728
for ; Thu, 1 Nov 2001 11:54:45 -0500 (EST)
Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87])
by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fA1Gsba02308
for ; Thu, 1 Nov 2001 08:54:37 -0800 (PST)
Received: from DAPW2K (sjc-vpn2-59.cisco.com [10.21.112.59])
by sponge.cisco.com (Mirapoint)
with SMTP id AAY10940;
Thu, 1 Nov 2001 10:51:59 -0600 (CST)
From: "Dave Peterson"
To: "Ips@Ece. Cmu. Edu"
Subject: iSCSI: iSCSI Rev 8
Date: Thu, 1 Nov 2001 10:56:03 -0600
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Good Morning,
Suggested rewording for clause 3.4.1 in iSCSI Rev 8:
bit 4 (o) set for Bidirectional Read Residual Overflow. In this case, the
Bidirectional Read Residual Count indicates the number of bytes that were
not transferred to the initiator because the initiator's Expected
Bidirectional Read Data Transfer Length was not sufficient.
bit 3 (u) set for Bidirectional Read Residual Underflow. In this case, the
Bidirectional Read Residual Count indicates the number of bytes that were
not transferred to the initiator out of the number of bytes that were
expected to be transferred.
bit 2 (O) set for Residual Overflow. In this case, the Residual Count
indicates the number of bytes that were not transferred because the
initiator's Expected Data Transfer length was not sufficient. For a
bidirectional operation, the Residual Count contains the residual for the
write operation.
bit 1 (U) set for Residual Underflow. In this case, the Residual Count
indicates the number of bytes that were not transferred out of the number of
bytes that were expected to be transferred. For a bidirectional operation,
the Residual Count contains the residual for the write operation.
Suggested rewording for clause 3.4.4
3.4.4 Residual Count
The Residual Count field is valid only in the case where either the U
bit or the O bit is set. If neither bit is set, the Residual Count
field SHOULD be zero. If the O bit is set, the Residual Count indicates
the number of bytes that were not transferred because the initiator's
Expected Data Transfer Length was not sufficient. If the U bit is set,
the Residual Count indicates the number of bytes that were not transferred
out of the number of bytes expected to be transferred.
3.4.5 Bidirectional Read Residual Count
The Bidirectional Read Residual Count field is valid only in the case
where either the u bit or the o bit is set. If neither bit is set,
the Bidirectional Read Residual Count field SHOULD be zero. If the o bit
is set, the Bidirectional Read Residual Count indicates the number of
bytes that were not transferred to the initiator because the initiator's
Expected Bidirectional Read Transfer Length was not sufficient. If the u
bit is set, the Bidirectional Read Residual Count indicates the number
of bytes that were not transferred to the initiator out of the number of
bytes that were expected to be transferred.
Dave
From owner-ips@ece.cmu.edu Thu Nov 1 12:30:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24545
for ; Thu, 1 Nov 2001 12:30:57 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1GOrO29194
for ips-outgoing; Thu, 1 Nov 2001 11:24:53 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1GOgl29169
for ; Thu, 1 Nov 2001 11:24:46 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fA1GNpS22779
for ; Thu, 1 Nov 2001 11:23:51 -0500 (EST)
Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com;
Thu, 1 Nov 2001 11:21:37 -0500
Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52])
by zcard00m.ca.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id VPDBJ6ZS; Thu, 1 Nov 2001 11:21:00 -0500
Received: from cse-ns-laptop.nortelnetworks.com (cse-ns-laptop.us.nortel.com [47.16.69.109])
by zbl6c002.corpeast.baynetworks.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id VW7FBLQ0; Thu, 1 Nov 2001 11:21:00 -0500
Message-Id: <5.1.0.14.2.20011101111644.02e8e500@zbl6c002.corpeast.baynetworks.com>
X-Sender: travos@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 01 Nov 2001 11:23:15 -0500
To: ENDL_TX@computer.org, IPS Reflector
From: "Franco Travostino"
Subject: Re: FCencap: Missing SOF/EOF characters
In-Reply-To: <3BE140FC.1E188857@compuserve.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_10463525==_.ALT"
X-Orig:
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
--=====================_10463525==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Ralph,
why should we be waiting until 5.3 (last page) to break this news (e.g.,
Class 1 isn't supported)?
Can we move your text up to section 1, aptly titled "Scope". Alternately,
we could narrow down the very title of the document.
0.02
-franco
At 07:33 AM 11/1/2001, Ralph Weber wrote:
>Off and on I hear complaints that it is not obvious
>why draft-ietf-ips-fcencapsulation-03.txt fails to
>list all the possible Fibre Channel SOF and EOF
>characters in 5.3.
>
>To address this concern, I propose adding the following
>text at the end of 5.3.
>
> Note: Some of the SOF and EOF characters defined by
> Fibre Channel are not listed in Table 1 and Table 2
> because the design an operating characteristics
> of an IP Network make it inappropriate for
> transporting FC Frames containing those SOF and/or
> EOF characters.
>
>I proposed to make this addition in a new draft that
>will be available in time for consideration in Salt
>Lake.
>
>Comment appreciated.
>
>Ralph Weber
Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
--=====================_10463525==_.ALT
Content-Type: text/html; charset="us-ascii"
Ralph,
why should we be waiting until 5.3 (last page) to break this news (e.g.,
Class 1 isn't supported)?
Can we move your text up to section 1, aptly titled "Scope".
Alternately, we could narrow down the very title of the
document.
0.02
-franco
At 07:33 AM 11/1/2001, Ralph Weber wrote:
Off and on I hear complaints that
it is not obvious
why draft-ietf-ips-fcencapsulation-03.txt fails to
list all the possible Fibre Channel SOF and EOF
characters in 5.3.
To address this concern, I propose adding the following
text at the end of 5.3.
Note: Some of the SOF and EOF characters defined by
Fibre Channel are not listed in Table 1 and Table 2
because the design an operating characteristics
of an IP Network make it inappropriate for
transporting FC Frames containing those SOF and/or
EOF characters.
I proposed to make this addition in a new draft that
will be available in time for consideration in Salt
Lake.
Comment appreciated.
Ralph Weber
Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
--=====================_10463525==_.ALT--
From owner-ips@ece.cmu.edu Thu Nov 1 12:35:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24742
for ; Thu, 1 Nov 2001 12:35:51 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1GuK001850
for ips-outgoing; Thu, 1 Nov 2001 11:56:21 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1GuIl01842
for ; Thu, 1 Nov 2001 11:56:18 -0500 (EST)
Received: from icarus.sanera.net (icarus [192.168.254.11])
by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fA1GuBu00638;
Thu, 1 Nov 2001 08:56:11 -0800
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
by icarus.sanera.net (8.11.6/8.11.2) with SMTP id fA1Gu6630922;
Thu, 1 Nov 2001 08:56:06 -0800
From: "Bill Strahm"
To: "Eddy Quicksall" ,
Subject: RE: iSCSI: current UNH Plugfest
Date: Thu, 1 Nov 2001 08:55:57 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <000101c162d7$330d39c0$0102a8c0@eddylaptop>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
Usually the "Conservative in what you send, Liberal in what you accept"
policy is used...
In otherwords, The sender MUST set to 0 (or some other value) The receiver
MUST ignore the value...
This allows for some tweaking of the implementation, if I control both ends
I might set a reserved value to 1, then I know something... If I receive a
reserve value set to 1 and I don't do anything the other end knows it is not
talking to itself (this can even be a versioning thing as well)
Now, we need to be VERY careful in defining this, do we plan on having
Protocol V1 endpoints talk to Protocol V2 endpoints, what does that mean...
is it possible, is it desirable ? will there be extensions ???
If you can truly answer NO to all of those things, I would argue for
REMOVING the reserved fields (if possible), if not, the MUST set, MUST
ignore policy seems better
Bill
+========+=========+=========+=========+=========+=========+=========+
Bill Strahm Software Development is a race between Programmers
Member of the trying to build bigger and better idiot proof software
Technical Staff and the Universe trying to produce bigger and better
bill@sanera.net idiots.
(503) 601-0263 So far the Universe is winning --- Rich Cook
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Eddy Quicksall
Sent: Thursday, November 01, 2001 5:15 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: current UNH Plugfest
I am reluctant to say this because I think most people think the
initiator/target must check for correctness ... but, it is my feeling that
that job should be up to a basher program. The target should not be in the
business of diagnosing the initiator. The only time a target should check a
field is when it could crash the system or data. Some format errors may have
no consequences whatsoever.
Eddy
-----Original Message-----
From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
Sent: Wednesday, October 31, 2001 05:39 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
Attached are the new issues that arose during the iSCSI plugfest
at UNH on Wednesday 31-Oct-2001.
(Note: these issues do not take into account any modifications or
clarifications that occured in the standard due to the issues raised
on Monday or Tuesday.)
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
------------------------------------------------------------------------
----
1. Are receivers (initiator or target) REQUIRED to check that reserved
bits and/or fields are set to 0?
Section 3 on page 48 of draft 8 says:
"Any bits not defined MUST be set to zero. Any reserved fields and
values MUST be 0 unless specified otherwise."
and Section 8.3 on page 127 of draft 8 says:
"Explicit violations of the PDU layout rules stated in this
document
are format errors. This when detected, usually indicates a major
implementation flaw in one of the parties.
When a target or an initiator receives an iSCSI PDU with a format
error, it MUST reset all transport connections in the session
immediately and escalate the format error to session recovery
(section 8.11.4)."
According to these rules, a PDU with reserved bits and/or fields that
are not set to 0 violates the PDU layout rules. Therefore, if an
initiator or target receives such a PDU, it should immediately close
all connections in the session and go to session recovery.
Clearly a format error has extremely severe consequences!
Although all vendors are setting reserved bits and fields to 0 on
PDUs they are sending, many are NOT checking PDUs they are receiving
to see if these bits and fields are set to 0. Basically, vendors are
saying "who cares if reserved bits and/or fields in incoming PDUs are
not zero? We do not want to take the time to do this checking, and
there is no benefit to doing it. As long as the non-reserved bits
and
fields are set properly, we can and should proceed. Any time devoted
to doing this checking is wasted in 99+% of the cases, and in the
(unlikely) case that a non-zero bit or field is found, the
consequences are too severe."
There should be some statement in the standard to clarify what
checking
is required and what is optional.
2. A similar situation arises with respect to checking the consistency
of fields such as Version-max, Version-min and Version-active in
Login
Requests and Login Responses.
For example, consider the Version-max field.
Section 3.12.5 says:
"All Login requests within the Login phase MUST carry the same
Version-max."
All vendor initiators are setting Version-max correctly on all
login requests they are sending, but many vendor targets are NOT
checking received login requests to ensure that this rule is
enforced.
In particular, many targets simply use the Version-max and
Version-min
on the first login request they receive on a new connection, and then
they ignore these fields on all subsequent login requests in the same
login phase.
Strictly speaking, a change in the Version-max field during the login
phase constitutes a protocol error according to section 8.8 on page
130
of draft 8:
"All violations of iSCSI PDU exchange sequences specified in this
draft are also protocol errors. This category of errors can be
addressed only by fixing the implementations; iSCSI defines Reject
and response codes to enable this".
Therefore the target should send back a login response with a status
of 0x0200 and then close the connection.
However, Section 3.12.5 also says:
"The target MUST use the value presented with the first login
request."
This rule seems to imply that the value CAN change, because if it
cannot
change, then it doesn't matter which one of the login requests it is
taken from, they are all the same anyway.
The suggestion is to keep the requirement that the target MUST use
the
value presented on the first login request, but to allowed the target
to ignore the value presented on all subsequent login requests in the
same login phase. A similar rewording should be done for the other
fields.
3. Can commands be sent out of order on the same connection?
The behavior of targets is clearly specified in Section 2.2.2.3 on
page 25 of draft 8, which says:
"Except for the commands marked for immediate delivery the iSCSI
target layer MUST eliver the commands for execution in the order
specified by CmdSN."
Section 2.2.2.3 on page 26 of draft 8 also says:
"- CmdSN - the current command Sequence Number advanced by 1 on
each command shipped except for commands marked for immediate
delivery."
but the meaning of the term "shipped" is vague, and does not
necessarily
require that the PDUs arrive on the other end of a TCP connection
in the same order that the CmdSN values were assigned to these PDUs.
Some initiators have been designed to send commands out of CmdSN
order on one connection. Consider the situation where there is only
one connection and a high-level dispatcher creates a PDU for a SCSI
command that involves writing immediate data to the target. This PDU
is enqueued to a lower-level layer which has to setup, start, and
wait-for a DMA operation to move the immediate data into an onboard
buffer before the PDU can be put onto the wire. While this is
happening, the dispatcher creates another unrelated PDU for a SCSI
read command (for example), and when this PDU is passed to the
lower-level layer it can be sent immediately, ahead of the previous
write PDU and therefore out of order on this connection.
The standard clearly allows this to happen if the two PDUs were sent
on different connections, and seems to imply that this can also
happen
when the two PDUs are sent on the same connection.
The suggestion is to put in the standard an explicit statement that
this is allowed or not allowed, as appropriate.
If this is allowed, such a statement would avoid the erroneous
assumption being made by some target implementers that within a
single
connection, commands will arrive in order.
If this is not allowed, such a statement would avoid the erroneous
assumption being made by some initiator implementers that within a
single connection, commands can be put on the wire out of order.
4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
now allow: "A value of 0 indicates no limit."
Is this useful? Does it buy anything?
The difficulties implementers are having with this are:
1) It is a special case.
2) It causes discontinuous ranges (for example, [0,64..2**24])
3) It violates the min/max function normally used for the key.
4) There is always a limit anyway.
Consider FirstBurstSize, which can have a value that is described
as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
is selected.
I one side offers 0 to mean unlimited, and the other side
has a limit, it will reply with that limit, say 128 Kbytes.
Therefore, the result is not min(0, 128K) but rather max(0, 128K).
The statement in the standard that "the minimum of the 2 numbers is
selected" is therefore wrong when one of the numbers is 0.
Furthermore, when an initiator or target receives an offer for one
of these keys, it cannot simply check that the offered value is
legal by testing it against some minimum and maximum. It must first
check for 0 and then only if that check shows the value is non-zero
can it do the min/max range check for legality (i.e., 64-2**24).
Finally, there is always a limit. If nothing else it is the
limit imposed by the 24-bit DataSegmentLength field of the PDU
requesting the transfer. It is useless to specify a FirstBurstSize
(or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
the largest possible DataSegmentLength in any PDU that can use
this value is 2**24-1.
The suggestion is to just eliminate this special case of 0 and
require
that the range 64-to-(2**24-1) be used instead -- it has exactly the
same effect in all cases, it is easier to describe in the standard
because it avoids all the extra words, and it is easier to code
because it avoids all the special cases.
NOTE: the standard should specify the limit in the ranges for
MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
of 2**24. The number 2**24 cannot be represented in the 24-bit
DataSegmentLength field and therefore can never be used.
5. This is a suggestion for a minor rewording in the standard to avoid
misunderstandings.
In Appendix E on page 188 of draft 8 it says:
"The response to this command is a text response containing a list
of
targets and their addresses. Each target is returned as a target
record. A target record begins with the TargetName text key,
followed by a list of TargetAddress text keys, ..."
In fact, there are situations where there are no targets and/or no
addresses. These situations are clearly defined in the draft after
the sentences quoted above, but it would help if those sentences
at least hinted at the possibility that the lists could be empty
or might not contain addresses. A possible rewording would be:
"The response to this command is a text response containing a list
of
zero or more targets and, optionally, their addresses. Each target
is returned as a target record. A target record begins with the
TargetName text key, followed by a list of zero or more
TargetAddress text keys, ..."
6. This is a suggestion for another very minor rewording in the
standard.
At the end of section 2.2.3 on page 29 of draft 8 it says:
"Before full feature phase is established, only Login PDUs are
allowed. ..."
The suggested rewording is:
"Before full feature phase is established, only Login Request and
Login Response PDUs are allowed. ..."
From owner-ips@ece.cmu.edu Thu Nov 1 12:42:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25040
for ; Thu, 1 Nov 2001 12:41:59 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1H17o02243
for ips-outgoing; Thu, 1 Nov 2001 12:01:07 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1H15l02238
for ; Thu, 1 Nov 2001 12:01:06 -0500 (EST)
Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21])
by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fA1H0xn15708
for ; Thu, 1 Nov 2001 12:00:59 -0500 (EST)
Content-Class: urn:content-classes:message
Subject: RE: FCencap: Missing SOF/EOF characters
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C162F6.C73518A4"
Date: Thu, 1 Nov 2001 12:00:58 -0500
Disposition-Notification-To: "Elizabeth Rodriguez"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Message-ID: <9410A0F67DFE7F4D998D45382364983617B29B@nc8220exchange.ral.lucent.com>
Thread-Topic: FCencap: Missing SOF/EOF characters
Thread-Index: AcFi9au2o3NyDHH+Q723eTU6AwEItAAAHTcw
From: "Elizabeth Rodriguez"
To: "Franco Travostino" , ,
"IPS Reflector"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
This is a multi-part message in MIME format.
------_=_NextPart_001_01C162F6.C73518A4
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Chair hat off --
=20
Inclusion of this information sounds good to me.
Locale of information does not matter to me as much.
As mentioned in previous email, we may also want to include the 'why not
appropriate' in annex, for reader's information.
=20
Elizabeth
-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: Thursday, November 01, 2001 10:23 AM
To: ENDL_TX@computer.org; IPS Reflector
Subject: Re: FCencap: Missing SOF/EOF characters
Ralph,
why should we be waiting until 5.3 (last page) to break this news (e.g.,
Class 1 isn't supported)?
Can we move your text up to section 1, aptly titled "Scope".
Alternately, we could narrow down the very title of the document.
0.02
-franco
At 07:33 AM 11/1/2001, Ralph Weber wrote:
Off and on I hear complaints that it is not obvious
why draft-ietf-ips-fcencapsulation-03.txt fails to
list all the possible Fibre Channel SOF and EOF
characters in 5.3.
To address this concern, I propose adding the following
text at the end of 5.3.
Note: Some of the SOF and EOF characters defined by
Fibre Channel are not listed in Table 1 and Table 2
because the design an operating characteristics
of an IP Network make it inappropriate for
transporting FC Frames containing those SOF and/or
EOF characters.
I proposed to make this addition in a new draft that
will be available in time for consideration in Salt
Lake.
Comment appreciated.
Ralph Weber
Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
------_=_NextPart_001_01C162F6.C73518A4
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Chair=20
hat off --
Inclusion of this information sounds good to=20
me.
Locale=20
of information does not matter to me as much.
As=20
mentioned in previous email, we may also want to include the 'why not=20
appropriate' in annex, for reader's information.
Elizabeth
-----Original =
Message-----
From:=20
Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: =
Thursday,=20
November 01, 2001 10:23 AM
To: ENDL_TX@computer.org; IPS=20
Reflector
Subject: Re: FCencap: Missing SOF/EOF=20
characters
Ralph,
why=20
should we be waiting until 5.3 (last page) to break this news (e.g., =
Class 1=20
isn't supported)?
Can we move your text up to section 1, aptly =
titled=20
"Scope". Alternately, we could narrow down the very title of the=20
document.
0.02
-franco
At 07:33 AM 11/1/2001, Ralph =
Weber=20
wrote:
Off and on I hear =
complaints that it=20
is not obvious
why draft-ietf-ips-fcencapsulation-03.txt fails =
to
list=20
all the possible Fibre Channel SOF and EOF
characters in =
5.3.
To=20
address this concern, I propose adding the following
text at the =
end of=20
5.3.
Note: Some of the SOF and EOF characters defined=20
by
Fibre Channel are not listed in Table 1 and Table =
2
=20
because the design an operating characteristics
of an IP =
Network=20
make it inappropriate for
transporting FC Frames =
containing those=20
SOF and/or
EOF characters.
I proposed to make this =
addition=20
in a new draft that
will be available in time for consideration =
in=20
Salt
Lake.
Comment appreciated.
Ralph=20
Weber
Franco Travostino, Director Content Internetworking=20
Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 =
Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: =
978 288=20
4690
email:=20
travos@nortelnetworks.com
------_=_NextPart_001_01C162F6.C73518A4--
From owner-ips@ece.cmu.edu Thu Nov 1 12:43:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25083
for ; Thu, 1 Nov 2001 12:43:34 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1GVZe29788
for ips-outgoing; Thu, 1 Nov 2001 11:31:35 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1GVXl29778
for ; Thu, 1 Nov 2001 11:31:33 -0500 (EST)
Received: from localhost (rdr@localhost)
by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA05738;
Thu, 1 Nov 2001 11:31:27 -0500 (EST)
Date: Thu, 1 Nov 2001 11:31:27 -0500
From: "Robert D. Russell"
To: Julian Satran
cc: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Julian:
Comments below:
> 4. Situation: The initiator and target have successfully completed the
> login phase for a discovery session and are now in full feature phase.
> The initiator sends a text command containing the single key:
> "SendTargets=". What response is expected from the target?
>
>
> Interpretation 1:
>
> According to the explanation on page 188 of draft 8 (page 189 of
> draft 8a):
> "If no target name is specified, the session should respond with
> addresses only for the target to which the session is logged in.
> This MUST be supported on operational sessions, and MAY NOT
> return targets other than the one to which the session is logged in."
>
> However, for a discovery session there is no target per se (the
> initiator does not specify a TargetName= during login), so the
> target therefore follows the rule on page 188 of draft 8 (page 189
> of draft 8a):
>
> +++
> That is not strictly correct. You may use discovery to determine the
> addresses and portal groups for a specific target - i.e. you may give a
> target-name. If you give a target name that is all you get. If don't give
> a name you get all the targets you are allowed to get to.
> ++++
If I understand this reply correctly, you are saying that
in a discovery session, when the initiator sends:
SendTargets=
it should expect to receive all the targets it is allowed to get to.
Correct?
This leads to 2 further questions/points:
1. Is this response any different from the response the initiator will
get when it sends:
SendTargets=all
2. If these responses are the same, then the explanation of
on page 188 of draft 8 should be changed to indicate that this is what
happens for a discovery session.
Thanks,
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
From owner-ips@ece.cmu.edu Thu Nov 1 12:52:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25510
for ; Thu, 1 Nov 2001 12:52:30 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1HGQO03478
for ips-outgoing; Thu, 1 Nov 2001 12:16:26 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1HGOl03474
for ; Thu, 1 Nov 2001 12:16:24 -0500 (EST)
Received: (from kzm@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA25752
for ips@ece.cmu.edu; Thu, 1 Nov 2001 09:16:18 -0800 (PST)
From: Keith McCloghrie
Message-Id: <200111011716.JAA25752@cisco.com>
Subject: iSCSI MIB - comments on iscsiAccessList
To: ips@ece.cmu.edu
Date: Thu, 1 Nov 2001 09:16:18 -0800 (PST)
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
I have some questions/suggestions regarding iscsiAccessList
in draft-ietf-ips-iscsi-mib-03.txt.
> 6.9. iscsiAccessList
>
> The iscsiAccessListAttributesTable contains an entry for each
> initiator that is allowed to access the target under which it
> appears. If a target allows access to any initiator, an
> AccessListAttributesEntry with the initiator's iSCSI name should be
> used.
I think the last sentence is
a) confusing (do you mean "any initiator" ?) and
b) may not always be true - with a wildcard mechanism ("iscsi" in the next
paragaph), an initiator's name does not have to be in the table, right ?
> This table does not cover all possible access control schemes that a
> vendor could implement. If access to an initiator cannot be
> determined just by its iSCSI name, an implementation may either
> include a single entry per target with the initiator name "iscsi", or
> may choose to place no entries in this table.
Does no entries in the table allow any initiator access, or does it
deny access to all initiators ?
> iscsiAccessListAttributesTable OBJECT-TYPE
> SYNTAX SEQUENCE OF IscsiAccessListAttributesEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "A list of iSCSI initiators which will be granted access
> to iSCSI resources through targets within the iSCSI
> instance."
Can you say explicitly:
- what does no entries in the table mean, and
- how does the wildcard entry (an entry with name="iscsi") work.
> ...
>
> iscsiALInitiatorName OBJECT-TYPE
> SYNTAX SnmpAdminString
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "An octet string that defines an initiator identified
> by the key of the Login Command which will
> be granted access. If this string has the value of 'iscsi',
> then any initiator may access this target."
> ::= { iscsiAccessListAttributesEntry 2 }
If you intend that an entry of "iscsi" means that "any initiator
name is allowed", then I think it's a little strange that a special
meaning applies to a name that an administrator might just happen to
use without realising it.
Here are three alternatives which I think are better:
1. have a column in the iscsiTargetAttributesTable which enables/disables
the use of the access-list. (Then, disabling has the same function as
"icsci" entry.)
2. have the zero-length name allow access to any name; (this is a special
case of #3 below.)
3. have an additional column, iscsiALInitiatorMatchType, which is an
INTEGER { exact(1), prefix(2) } where 'exact' is the type you currently
have, and 'prefix' says that longer initiator names will match
if they can be truncated to the value of iscsiALInitiatorName.
Keith.
From owner-ips@ece.cmu.edu Thu Nov 1 12:54:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25584
for ; Thu, 1 Nov 2001 12:54:18 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1HUWe04661
for ips-outgoing; Thu, 1 Nov 2001 12:30:32 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1HUUl04655
for ; Thu, 1 Nov 2001 12:30:30 -0500 (EST)
Received: from core.rose.hp.com (unknown [15.43.208.100])
by atlrel7.hp.com (Postfix) with ESMTP
id 7AD2D1F90A; Thu, 1 Nov 2001 12:27:48 -0500 (EST)
Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id JAA14784; Thu, 1 Nov 2001 09:31:50 -0800 (PST)
Message-Id: <200111011731.JAA14784@core.rose.hp.com>
Date: Thu, 01 Nov 2001 09:42:35 -0800
From: "Mallikarjun C."
Reply-To: cbm@rose.hp.com
Organization: Hewlett-Packard, Roseville
X-Mailer: Mozilla 4.73 [en] (X11; U; HP-UX B.10.20 9000/715)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Julian,
> +++ I think this is the correct interpretation and we will fix the wording
> in section 8 to say this. I suggest:
>
> - During Login, any failure in negotiation MUST be considered as the login
> process failure and the login phase must be terminated. If the failure is
> detected by the target, it must reject the login with the appropriate
> code. The connection must be terminated by the initiator.
I agree. However, I suggest the following with a minor change (and
leaving out the last sentence).
- During Login, any failure in negotiation MUST be considered as the
login
process failure and the login phase must be terminated. If the failure
is
detected by the target, it must terminate the login with the
appropriate
login response status code.
Regards.
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com
Julian Satran wrote:
>
> Bob,
>
> Comments in text.
>
> Thanks,
> Julo
>
> "Robert D. Russell"
> Sent by: owner-ips@ece.cmu.edu
> 31-10-01 02:06
> Please respond to "Robert D. Russell"
>
>
> To: ips@ece.cmu.edu
> cc:
> Subject: Re: iSCSI: current UNH Plugfest
>
>
>
> Attached are some new issues that arose during the iSCSI plugfest at
> UNH on Tuesday 29-Oct-2001.
> (Note: these issues do not take into account any modifications or
> clarifications that occured in the standard due to the issues raised
> on Monday.)
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>
> -----------------------------------------------------------------------------
>
> 1. Situation: as the first command on a new TCP connection, the initiator
> sends a login with T=1, CSG=1, NSG=3, and valid InitiatorName,
> TargetName,
> and SessionType keys. However, there is also a valid key having an
> invalid value, such as MaxConnections=abcd (i.e., not a number after
> the
> '=') or MaxConnections4 (i.e., missing the '=').
> What should the target do?
>
> Interpretation 1:
>
> According to section 3.10.4 page 82 of draft 8 (page 83 of draft 8a),
> "Any other key not understood by the target may be ignored by the
> target without affecting basic function. However the Text Response
> for a key that was not understood MUST be key=NotUnderstood."
>
> Two things have to be clarified:
> 1. Does this section also apply to keys received in a login?
> 2. Can "NotUnderstood" also apply to "values of keys" that are not
> understood, even if the key word itself is understood?
> +++
> 1.NotUnderstood appears also in the negotiation section so it applies to
> login.
> I will remove it from the text section
> 2.It does not apply to values
> +++
>
> If the answer to these 2 of these questions is "yes", then the
> appropriate
> response would seem to be for the target to just ignore the key and
> send
> back MaxConnections=NotUnderstood as part of its next login response.
>
>
> Interpratation 2:
>
> According to section 8.7 page 129 of draft 8 (page 130 of draft 8a),
> "A negotiation failure is considered one or both of the following:
> - None of the choices or the stated value is acceptable to one
> negotiating side. ..."
> Clearly this stated value ("abcd") is not acceptable to the target.
> Therefore, the following rule on page 129, draft 8 (page 130, draft 8a)
> applies:
> "- During Login, any failure in negotiation MUST be considered
> as the login process failure and the connection must be dropped."
>
> Therefore, the target should just drop the connection without sending
> any login response back to the initiator.
>
> Interpretation 3:
>
> This is a login command that contains an error caused by the
> initiator. Therefore, the target should send back a login response
> with a status code of 0x0200 and then close the TCP connection.
>
> +++ I think this is the correct interpretation and we will fix the wording
> in section 8 to say this. I suggest:
>
> - During Login, any failure in negotiation MUST be considered as the login
> process failure and the login phase must be terminated. If the failure is
> detected by the target, it must reject the login with the appropriate
> code. The connection must be terminated by the initiator.
>
> +++
>
> 2. Situation: on the first login command in operational parameter
> negotiation
> stage, the initiator sends no operational keys, thereby telling the
> target
> that it accepts all the default values for these keys. However, the
> target
> wants to negotiate the value of MaxConnections, so in the login
> response
> it sends back "MaxConnections=3" (for example). Should the initiator
> send a response to this key or not?
>
> The statement in section 2.2.4 on page 30 of draft 8 and 8a:
> "For numerical (and single literal) negotiations, the responding party
> MUST
> respond with the required key.(...)"
> makes it clear that the responding party MUST respond. However, in
> this
> situation, it is not clear who the responding party is.
>
> +++ we are using the term offering and responding to distinguish them from
> initiator and target and explicitly say (in 2.2.4) that the target may
> offer keys
> +++
>
> Interpretation 1:
>
> By not explicitly sending this key in the login command, the initiator
> is implicitly offering the default value and therefore is the offering
> party and the target is the responding party. The conclusion is that
> the initiator does not have to send a response to this key from the
> target.
>
> +++ there is no implicit ofering of defaults. A default is accepted only
> if the two parties are silent.
>
> +++
> Interpretation 2:
>
> The target is the offering party because it is the party that
> explicitly
> stated the key for the first time during these negotiations. The
> conclusion is that the initiator MUST send a response to this key from
> the
> target.
>
> NOTE 1: If interpretation 1 is correct, it would seem to imply that the
> target MUST respond to every key whether or not it is present in the
> login from the initiator, even if it does not want to change the
> default
> value. The reason is that a missing key is an implicit offer of the
> default value, and the responding party MUST respond. Is this a
> correct
> interpretation?
>
> NOTE 2: The following statements in section 2.2.4 page 29 of draft 8a:
>
> Originator-> =
> Responder-> =|NOtUnderstood
>
> seem to imply that the originator is the party (initiator or target)
> that
> explicitly offers a key, and that omitting a key is not an implicit
> offer
> of that key with the default value. However, even in the revised draft
> 8a
> there is no definition of "Originator" and/or "Responder" that would
> make this clear. Adding to the standard these definitions, and an
> explicit statement that "a missing key does not constitute an implicit
> offer of the default" would help eliminate misunderstandings. In
> addition, including an example of this situation (where an initiator
> omits a key and the target offers the key) would be a big help.
>
> +++ will do +++
>
> 3. Some of the login phase examples given in Appendix A of both draft 8
> and
> 8a do not follow the rule in section 3.12.4 page 87 of draft 8 (page 88
> of draft 8a):
> "The next stage value is valid only when the T bit is 1 and is
> reserved otherwise."
> and the rule in section 3 page 48 of draft 8 (page 49 of draft 8a):
> "Any reserved fields and values MUST be 0 unless specified
> otherwise."
>
> If these rules are applied, all examples having T=0 should also
> have NSG=0. Presently all of them with T=0 also have NSG=1 or NSG=3.
>
> +++ Will fix the examples +++
>
> 4. Situation: The initiator and target have successfully completed the
> login phase for a discovery session and are now in full feature phase.
> The initiator sends a text command containing the single key:
> "SendTargets=". What response is expected from the target?
>
> Interpretation 1:
>
> According to the explanation on page 188 of draft 8 (page 189 of
> draft 8a):
> "If no target name is specified, the session should respond with
> addresses only for the target to which the session is logged in.
> This MUST be supported on operational sessions, and MAY NOT
> return targets other than the one to which the session is logged in."
>
> However, for a discovery session there is no target per se (the
> initiator does not specify a TargetName= during login), so the
> target therefore follows the rule on page 188 of draft 8 (page 189
> of draft 8a):
>
> +++
> That is not strictly correct. You may use discovery to determine the
> addresses and portal groups for a specific target - i.e. you may give a
> target-name. If you give a target name that is all you get. If don't give
> a name you get all the targets you are allowed to get to.
> ++++
>
> "A SendTargets response MAY contain no target names, if there are no
> targets for the requesting initiator to access."
> and sends back a Text Response with no keys in it.
>
> Interpretation 2:
>
> In a discovery session, the key "SendTargets=" makes no sense and
> should
> be treated by the target in the same manner as the key
> "SendTargets=all".
>
> 5. Some common error situations:
>
> 1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
> some targets are not including the SenseLength as the first 2
> bytes in the data segment. Although the format of the data segment
> is clear from the diagram in section 3.4.6 on page 62 of draft 8
> (page 63 of draft 8a), the last entry in the diagram for the SCSI
> Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
> misleading because it mentions only the Sense Data and Response
> Data and omits the Sense Length. It would therefore be helpful
> if the last entry in the diagram on page 58 were changed to
> explicitly
> reference the diagram on page 62, as in:
>
> Data Segment -- see section 3.4.6 (optional)
> +++ will do +++
>
> 2) - after sending a CmdSN on an initial login, some initiators are
> incrementing it before sending their first non-immediate command.
> (i.e., if the initial login contains CmdSN=123, they are sending
> CmdSN=124 on the first non-immediate command after the login phase).
> Section 3.12.10 on page 89 of draft 8 (page 90 of draft 8a) is
> clear that in this example the first non-immediate command should
> carry CmdSN=123, not 124. This was an issue at the July plugfest
> and apparently some implementations have not been updated to conform
> to the draft 8 standard in their handling of CmdSN.
From owner-ips@ece.cmu.edu Thu Nov 1 12:54:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25596
for ; Thu, 1 Nov 2001 12:54:27 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1HUGp04640
for ips-outgoing; Thu, 1 Nov 2001 12:30:16 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1HUDl04629
for ; Thu, 1 Nov 2001 12:30:13 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA32672
for ; Thu, 1 Nov 2001 18:30:07 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1HU6842482
for ; Thu, 1 Nov 2001 18:30:06 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: Re: iSCSI: current UNH Plugfest
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 19:30:02 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 19:30:06,
Serialize complete at 01/11/2001 19:30:06
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Bob,
Rereading the text I understand what is confusing. The target name
mentioned is the one from the previous item!
I will reformulate it to read:
The value must be one of:
all
The initiator is requesting that information on all relevant targets known
to the implementation be returned. This value MUST be supported on a
discovery session, and MAY NOT be supported on an operational session.
If an iSCSI target name is specified, the session should respond with
addresses for only the named target, if possible. This value MUST be
supported on discovery sessions. A discovery session MUST be capable of
returning addresses for those targets that would have been returned had
value=all been designated.
The session should respond with addresses only for the target to which the
session is logged in. This MUST be supported on operational sessions, and
MAY NOT return targets other than the one to which the session is logged
in.
Thanks,
Julo
"Robert D. Russell"
01-11-01 18:31
Please respond to "Robert D. Russell"
To: Julian Satran/Haifa/IBM@IBMIL
cc: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
Julian:
Comments below:
> 4. Situation: The initiator and target have successfully completed the
> login phase for a discovery session and are now in full feature
phase.
> The initiator sends a text command containing the single key:
> "SendTargets=". What response is expected from the target?
>
>
> Interpretation 1:
>
> According to the explanation on page 188 of draft 8 (page 189 of
> draft 8a):
> "If no target name is specified, the session should respond with
> addresses only for the target to which the session is logged in.
> This MUST be supported on operational sessions, and MAY NOT
> return targets other than the one to which the session is logged in."
>
> However, for a discovery session there is no target per se (the
> initiator does not specify a TargetName= during login), so the
> target therefore follows the rule on page 188 of draft 8 (page 189
> of draft 8a):
>
> +++
> That is not strictly correct. You may use discovery to determine the
> addresses and portal groups for a specific target - i.e. you may give a
> target-name. If you give a target name that is all you get. If don't
give
> a name you get all the targets you are allowed to get to.
> ++++
If I understand this reply correctly, you are saying that
in a discovery session, when the initiator sends:
SendTargets=
it should expect to receive all the targets it is allowed to get to.
Correct?
This leads to 2 further questions/points:
1. Is this response any different from the response the initiator will
get when it sends:
SendTargets=all
2. If these responses are the same, then the explanation of
on page 188 of draft 8 should be changed to indicate that this is what
happens for a discovery session.
Thanks,
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
From owner-ips@ece.cmu.edu Thu Nov 1 13:47:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27344
for ; Thu, 1 Nov 2001 13:47:02 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1IF7508569
for ips-outgoing; Thu, 1 Nov 2001 13:15:07 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1IF4l08557
for ; Thu, 1 Nov 2001 13:15:04 -0500 (EST)
Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA19673; Thu, 1 Nov 2001 13:14:57 -0500 (EST)
Message-ID: <3BE18ECE.89BB64E0@cisco.com>
Date: Thu, 01 Nov 2001 12:05:02 -0600
From: Mark Bakke
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Keith McCloghrie
CC: ips@ece.cmu.edu
Subject: Re: iSCSI MIB - comments on iscsiAccessList
References: <200111011716.JAA25752@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Keith McCloghrie wrote:
>
> I have some questions/suggestions regarding iscsiAccessList
> in draft-ietf-ips-iscsi-mib-03.txt.
>
> > 6.9. iscsiAccessList
> >
> > The iscsiAccessListAttributesTable contains an entry for each
> > initiator that is allowed to access the target under which it
> > appears. If a target allows access to any initiator, an
> > AccessListAttributesEntry with the initiator's iSCSI name should be
> > used.
>
> I think the last sentence is
>
> a) confusing (do you mean "any initiator" ?) and
No. I meant "any particular initiator"; this was badly worded.
> b) may not always be true - with a wildcard mechanism ("iscsi" in the next
> paragaph), an initiator's name does not have to be in the table, right ?
Yes. That is correct.
> > This table does not cover all possible access control schemes that a
> > vendor could implement. If access to an initiator cannot be
> > determined just by its iSCSI name, an implementation may either
> > include a single entry per target with the initiator name "iscsi", or
> > may choose to place no entries in this table.
>
> Does no entries in the table allow any initiator access, or does it
> deny access to all initiators ?
I think that we need to decide that here. It was originally intended
to mean that all initiators are allowed, but since we have a way to
say that by putting in "iscsi", I think that it should mean either that
all initiators are denied, or that the access list mechanism in the
MIB is not enough to determine whether or not an initiator will
be granted access. I would tend toward the latter; if there are no
access list entries for a target, it means that there is not enough
information to tell who gets to access it from this MIB. Implementations
that provide value-add access control can augment this MIB with their
own enterprise MIBs for access control.
I would like to re-word this to:
... The value "iscsi" in an access list entry means that any
initiator may access this target. If a target has no entries
in the access list attributes table, it means that there is
not enough information here to determine whether or not an
initiator will be granted access.
> > iscsiAccessListAttributesTable OBJECT-TYPE
> > SYNTAX SEQUENCE OF IscsiAccessListAttributesEntry
> > MAX-ACCESS not-accessible
> > STATUS current
> > DESCRIPTION
> > "A list of iSCSI initiators which will be granted access
> > to iSCSI resources through targets within the iSCSI
> > instance."
>
> Can you say explicitly:
>
> - what does no entries in the table mean, and
> - how does the wildcard entry (an entry with name="iscsi") work.
OK.
> > ...
> >
> > iscsiALInitiatorName OBJECT-TYPE
> > SYNTAX SnmpAdminString
> > MAX-ACCESS read-only
> > STATUS current
> > DESCRIPTION
> > "An octet string that defines an initiator identified
> > by the key of the Login Command which will
> > be granted access. If this string has the value of 'iscsi',
> > then any initiator may access this target."
> > ::= { iscsiAccessListAttributesEntry 2 }
>
> If you intend that an entry of "iscsi" means that "any initiator
> name is allowed", then I think it's a little strange that a special
> meaning applies to a name that an administrator might just happen to
> use without realising it.
"iscsi" is a reserved initiator name value, and must not be assigned
to an initiator or target by an adminstrator or manufacturer. There
should be no problems with using it here.
>
> Here are three alternatives which I think are better:
>
> 1. have a column in the iscsiTargetAttributesTable which enables/disables
> the use of the access-list. (Then, disabling has the same function as
> "icsci" entry.)
This is probably the cleanest; an implementation that does not do
access lists would not have to implement the access list part of
the MIB at all.
> 2. have the zero-length name allow access to any name; (this is a special
> case of #3 below.)
>
> 3. have an additional column, iscsiALInitiatorMatchType, which is an
> INTEGER { exact(1), prefix(2) } where 'exact' is the type you currently
> have, and 'prefix' says that longer initiator names will match
> if they can be truncated to the value of iscsiALInitiatorName.
>
> Keith.
--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054
From owner-ips@ece.cmu.edu Thu Nov 1 13:50:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27446
for ; Thu, 1 Nov 2001 13:50:40 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1INAf09315
for ips-outgoing; Thu, 1 Nov 2001 13:23:10 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1IN8l09311
for ; Thu, 1 Nov 2001 13:23:08 -0500 (EST)
Received: (from kzm@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA13407;
Thu, 1 Nov 2001 10:22:59 -0800 (PST)
From: Keith McCloghrie
Message-Id: <200111011822.KAA13407@cisco.com>
Subject: Re: iSCSI MIB - comments on iscsiAccessList
To: mbakke@cisco.com (Mark Bakke)
Date: Thu, 1 Nov 2001 10:22:58 -0800 (PST)
Cc: kzm@cisco.com (Keith McCloghrie), ips@ece.cmu.edu
In-Reply-To: <3BE18ECE.89BB64E0@cisco.com> from "Mark Bakke" at Nov 01, 2001 12:05:02 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
> > > 6.9. iscsiAccessList
> > >
> > > The iscsiAccessListAttributesTable contains an entry for each
> > > initiator that is allowed to access the target under which it
> > > appears. If a target allows access to any initiator, an
> > > AccessListAttributesEntry with the initiator's iSCSI name should be
> > > used.
> >
> > I think the last sentence is
> >
> > a) confusing (do you mean "any initiator" ?) and
>
> No. I meant "any particular initiator"; this was badly worded.
How about also changing "with the initiator's iSCSI name" to
"with that initiator's iSCSI name".
> > > This table does not cover all possible access control schemes that a
> > > vendor could implement. If access to an initiator cannot be
> > > determined just by its iSCSI name, an implementation may either
> > > include a single entry per target with the initiator name "iscsi", or
> > > may choose to place no entries in this table.
> >
> > Does no entries in the table allow any initiator access, or does it
> > deny access to all initiators ?
>
> I think that we need to decide that here. It was originally intended
> to mean that all initiators are allowed, but since we have a way to
> say that by putting in "iscsi", I think that it should mean either that
> all initiators are denied, or that the access list mechanism in the
> MIB is not enough to determine whether or not an initiator will
> be granted access. I would tend toward the latter; if there are no
> access list entries for a target, it means that there is not enough
> information to tell who gets to access it from this MIB. Implementations
> that provide value-add access control can augment this MIB with their
> own enterprise MIBs for access control.
>
> I would like to re-word this to:
>
> ... The value "iscsi" in an access list entry means that any
> initiator may access this target. If a target has no entries
> in the access list attributes table, it means that there is
> not enough information here to determine whether or not an
> initiator will be granted access.
OK.
> > > iscsiALInitiatorName OBJECT-TYPE
> > > SYNTAX SnmpAdminString
> > > MAX-ACCESS read-only
> > > STATUS current
> > > DESCRIPTION
> > > "An octet string that defines an initiator identified
> > > by the key of the Login Command which will
> > > be granted access. If this string has the value of 'iscsi',
> > > then any initiator may access this target."
> > > ::= { iscsiAccessListAttributesEntry 2 }
> >
> > If you intend that an entry of "iscsi" means that "any initiator
> > name is allowed", then I think it's a little strange that a special
> > meaning applies to a name that an administrator might just happen to
> > use without realising it.
>
> "iscsi" is a reserved initiator name value, and must not be assigned
> to an initiator or target by an adminstrator or manufacturer. There
> should be no problems with using it here.
>
> >
> > Here are three alternatives which I think are better:
> >
> > 1. have a column in the iscsiTargetAttributesTable which enables/disables
> > the use of the access-list. (Then, disabling has the same function as
> > "icsci" entry.)
>
> This is probably the cleanest; an implementation that does not do
> access lists would not have to implement the access list part of
> the MIB at all.
OK.
Thanks,
Keith.
From owner-ips@ece.cmu.edu Thu Nov 1 13:56:08 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27609
for ; Thu, 1 Nov 2001 13:56:07 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1Hn0x06366
for ips-outgoing; Thu, 1 Nov 2001 12:49:00 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Hmxl06362
for ; Thu, 1 Nov 2001 12:48:59 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA35618
for ; Thu, 1 Nov 2001 18:48:53 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1Hmqr120470
for ; Thu, 1 Nov 2001 18:48:52 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: Re: iSCSI: iSCSI Rev 8
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 19:48:48 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 19:48:52,
Serialize complete at 01/11/2001 19:48:52
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Thanks - Julo
"Dave Peterson"
Sent by: owner-ips@ece.cmu.edu
01-11-01 18:56
Please respond to "Dave Peterson"
To: "Ips@Ece. Cmu. Edu"
cc:
Subject: iSCSI: iSCSI Rev 8
Good Morning,
Suggested rewording for clause 3.4.1 in iSCSI Rev 8:
bit 4 (o) set for Bidirectional Read Residual Overflow. In this case, the
Bidirectional Read Residual Count indicates the number of bytes that were
not transferred to the initiator because the initiator's Expected
Bidirectional Read Data Transfer Length was not sufficient.
bit 3 (u) set for Bidirectional Read Residual Underflow. In this case, the
Bidirectional Read Residual Count indicates the number of bytes that were
not transferred to the initiator out of the number of bytes that were
expected to be transferred.
bit 2 (O) set for Residual Overflow. In this case, the Residual Count
indicates the number of bytes that were not transferred because the
initiator's Expected Data Transfer length was not sufficient. For a
bidirectional operation, the Residual Count contains the residual for the
write operation.
bit 1 (U) set for Residual Underflow. In this case, the Residual Count
indicates the number of bytes that were not transferred out of the number
of
bytes that were expected to be transferred. For a bidirectional operation,
the Residual Count contains the residual for the write operation.
Suggested rewording for clause 3.4.4
3.4.4 Residual Count
The Residual Count field is valid only in the case where either the U
bit or the O bit is set. If neither bit is set, the Residual Count
field SHOULD be zero. If the O bit is set, the Residual Count indicates
the number of bytes that were not transferred because the initiator's
Expected Data Transfer Length was not sufficient. If the U bit is set,
the Residual Count indicates the number of bytes that were not transferred
out of the number of bytes expected to be transferred.
3.4.5 Bidirectional Read Residual Count
The Bidirectional Read Residual Count field is valid only in the case
where either the u bit or the o bit is set. If neither bit is set,
the Bidirectional Read Residual Count field SHOULD be zero. If the o bit
is set, the Bidirectional Read Residual Count indicates the number of
bytes that were not transferred to the initiator because the initiator's
Expected Bidirectional Read Transfer Length was not sufficient. If the u
bit is set, the Bidirectional Read Residual Count indicates the number
of bytes that were not transferred to the initiator out of the number of
bytes that were expected to be transferred.
Dave
From owner-ips@ece.cmu.edu Thu Nov 1 14:29:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28335
for ; Thu, 1 Nov 2001 14:29:50 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1Id3R10706
for ips-outgoing; Thu, 1 Nov 2001 13:39:03 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10])
by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fA1Icwl10699
for ; Thu, 1 Nov 2001 13:38:58 -0500 (EST)
Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99])
by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fA1IcbM03325;
Thu, 1 Nov 2001 13:38:37 -0500
Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1])
by deneb.dev.equallogic.com (8.11.2/8.11.2) with ESMTP id fA1Icab30981;
Thu, 1 Nov 2001 13:38:37 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15329.38576.650000.176588@gargle.gargle.HOWL>
Date: Thu, 1 Nov 2001 13:38:40 -0500
From: Paul Koning
To: bill@sanera.net
Cc: Eddy_Quicksall@ivivity.com, ips@ece.cmu.edu
Subject: RE: iSCSI: current UNH Plugfest
References: <000101c162d7$330d39c0$0102a8c0@eddylaptop>
X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Excerpt of message (sent 1 November 2001) by Bill Strahm:
> Usually the "Conservative in what you send, Liberal in what you accept"
> policy is used...
That's a very important principle...
> In otherwords, The sender MUST set to 0 (or some other value) The receiver
> MUST ignore the value...
That's the way to express the principle. But the text quoted in the
earlier notes does not express it the same way.
In particular "... are format errors. This when detected..." implies
that receivers may or may not detect format errors. In other words,
it implies -- but does NOT state explicitly -- that receivers MAY
check reserved fields for zeroness.
> This allows for some tweaking of the implementation, if I control both ends
> I might set a reserved value to 1, then I know something... If I receive a
> reserve value set to 1 and I don't do anything the other end knows it is not
> talking to itself (this can even be a versioning thing as well)
>
> Now, we need to be VERY careful in defining this, do we plan on having
> Protocol V1 endpoints talk to Protocol V2 endpoints, what does that mean...
> is it possible, is it desirable ? will there be extensions ???
>
> If you can truly answer NO to all of those things, I would argue for
> REMOVING the reserved fields (if possible), if not, the MUST set, MUST
> ignore policy seems better
I agree strongly. There is a lot of experience in the community on
what helps and what hurts convenient version upgrade. In particular,
there is a LOT of evidence that ANY checking of reserved fields is a
nasty thing. Unless you plan never to go beyond V1, you really need
to require the rule Bill stated, i.e., receivers MUST ignore the
contents of reserved fields -- they are NOT allowed to "verify" them.
So the spec needs to be clarified to say that random values in
reserved fields are NOT format errors and receivers MUST NOT treat
them as such.
paul
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Eddy Quicksall
> Sent: Thursday, November 01, 2001 5:15 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: current UNH Plugfest
>
>
> I am reluctant to say this because I think most people think the
> initiator/target must check for correctness ... but, it is my feeling that
> that job should be up to a basher program. The target should not be in the
> business of diagnosing the initiator. The only time a target should check a
> field is when it could crash the system or data. Some format errors may have
> no consequences whatsoever.
>
> Eddy
>
>
> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
> Sent: Wednesday, October 31, 2001 05:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: current UNH Plugfest
>
>
> Attached are the new issues that arose during the iSCSI plugfest
> at UNH on Wednesday 31-Oct-2001.
>
> (Note: these issues do not take into account any modifications or
> clarifications that occured in the standard due to the issues raised
> on Monday or Tuesday.)
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>
> ------------------------------------------------------------------------
> ----
>
> 1. Are receivers (initiator or target) REQUIRED to check that reserved
> bits and/or fields are set to 0?
>
> Section 3 on page 48 of draft 8 says:
> "Any bits not defined MUST be set to zero. Any reserved fields and
> values MUST be 0 unless specified otherwise."
>
> and Section 8.3 on page 127 of draft 8 says:
> "Explicit violations of the PDU layout rules stated in this
> document
> are format errors. This when detected, usually indicates a major
> implementation flaw in one of the parties.
>
> When a target or an initiator receives an iSCSI PDU with a format
> error, it MUST reset all transport connections in the session
> immediately and escalate the format error to session recovery
> (section 8.11.4)."
>
> According to these rules, a PDU with reserved bits and/or fields that
> are not set to 0 violates the PDU layout rules. Therefore, if an
> initiator or target receives such a PDU, it should immediately close
> all connections in the session and go to session recovery.
>
> Clearly a format error has extremely severe consequences!
>
> Although all vendors are setting reserved bits and fields to 0 on
> PDUs they are sending, many are NOT checking PDUs they are receiving
> to see if these bits and fields are set to 0. Basically, vendors are
> saying "who cares if reserved bits and/or fields in incoming PDUs are
> not zero? We do not want to take the time to do this checking, and
> there is no benefit to doing it. As long as the non-reserved bits
> and
> fields are set properly, we can and should proceed. Any time devoted
> to doing this checking is wasted in 99+% of the cases, and in the
> (unlikely) case that a non-zero bit or field is found, the
> consequences are too severe."
>
> There should be some statement in the standard to clarify what
> checking
> is required and what is optional.
>
> 2. A similar situation arises with respect to checking the consistency
> of fields such as Version-max, Version-min and Version-active in
> Login
> Requests and Login Responses.
>
> For example, consider the Version-max field.
>
> Section 3.12.5 says:
> "All Login requests within the Login phase MUST carry the same
> Version-max."
>
> All vendor initiators are setting Version-max correctly on all
> login requests they are sending, but many vendor targets are NOT
> checking received login requests to ensure that this rule is
> enforced.
> In particular, many targets simply use the Version-max and
> Version-min
> on the first login request they receive on a new connection, and then
> they ignore these fields on all subsequent login requests in the same
> login phase.
>
> Strictly speaking, a change in the Version-max field during the login
> phase constitutes a protocol error according to section 8.8 on page
> 130
> of draft 8:
>
> "All violations of iSCSI PDU exchange sequences specified in this
> draft are also protocol errors. This category of errors can be
> addressed only by fixing the implementations; iSCSI defines Reject
> and response codes to enable this".
>
> Therefore the target should send back a login response with a status
> of 0x0200 and then close the connection.
>
> However, Section 3.12.5 also says:
> "The target MUST use the value presented with the first login
> request."
>
> This rule seems to imply that the value CAN change, because if it
> cannot
> change, then it doesn't matter which one of the login requests it is
> taken from, they are all the same anyway.
>
> The suggestion is to keep the requirement that the target MUST use
> the
> value presented on the first login request, but to allowed the target
> to ignore the value presented on all subsequent login requests in the
> same login phase. A similar rewording should be done for the other
> fields.
>
> 3. Can commands be sent out of order on the same connection?
>
> The behavior of targets is clearly specified in Section 2.2.2.3 on
> page 25 of draft 8, which says:
> "Except for the commands marked for immediate delivery the iSCSI
> target layer MUST eliver the commands for execution in the order
> specified by CmdSN."
>
> Section 2.2.2.3 on page 26 of draft 8 also says:
> "- CmdSN - the current command Sequence Number advanced by 1 on
> each command shipped except for commands marked for immediate
> delivery."
> but the meaning of the term "shipped" is vague, and does not
> necessarily
> require that the PDUs arrive on the other end of a TCP connection
> in the same order that the CmdSN values were assigned to these PDUs.
>
> Some initiators have been designed to send commands out of CmdSN
> order on one connection. Consider the situation where there is only
> one connection and a high-level dispatcher creates a PDU for a SCSI
> command that involves writing immediate data to the target. This PDU
> is enqueued to a lower-level layer which has to setup, start, and
> wait-for a DMA operation to move the immediate data into an onboard
> buffer before the PDU can be put onto the wire. While this is
> happening, the dispatcher creates another unrelated PDU for a SCSI
> read command (for example), and when this PDU is passed to the
> lower-level layer it can be sent immediately, ahead of the previous
> write PDU and therefore out of order on this connection.
>
> The standard clearly allows this to happen if the two PDUs were sent
> on different connections, and seems to imply that this can also
> happen
> when the two PDUs are sent on the same connection.
>
> The suggestion is to put in the standard an explicit statement that
> this is allowed or not allowed, as appropriate.
>
> If this is allowed, such a statement would avoid the erroneous
> assumption being made by some target implementers that within a
> single
> connection, commands will arrive in order.
>
> If this is not allowed, such a statement would avoid the erroneous
> assumption being made by some initiator implementers that within a
> single connection, commands can be put on the wire out of order.
>
> 4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
> now allow: "A value of 0 indicates no limit."
>
> Is this useful? Does it buy anything?
>
> The difficulties implementers are having with this are:
>
> 1) It is a special case.
> 2) It causes discontinuous ranges (for example, [0,64..2**24])
> 3) It violates the min/max function normally used for the key.
> 4) There is always a limit anyway.
>
> Consider FirstBurstSize, which can have a value that is described
> as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
> is selected.
>
> I one side offers 0 to mean unlimited, and the other side
> has a limit, it will reply with that limit, say 128 Kbytes.
> Therefore, the result is not min(0, 128K) but rather max(0, 128K).
> The statement in the standard that "the minimum of the 2 numbers is
> selected" is therefore wrong when one of the numbers is 0.
>
> Furthermore, when an initiator or target receives an offer for one
> of these keys, it cannot simply check that the offered value is
> legal by testing it against some minimum and maximum. It must first
> check for 0 and then only if that check shows the value is non-zero
> can it do the min/max range check for legality (i.e., 64-2**24).
>
> Finally, there is always a limit. If nothing else it is the
> limit imposed by the 24-bit DataSegmentLength field of the PDU
> requesting the transfer. It is useless to specify a FirstBurstSize
> (or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
> the largest possible DataSegmentLength in any PDU that can use
> this value is 2**24-1.
>
> The suggestion is to just eliminate this special case of 0 and
> require
> that the range 64-to-(2**24-1) be used instead -- it has exactly the
> same effect in all cases, it is easier to describe in the standard
> because it avoids all the extra words, and it is easier to code
> because it avoids all the special cases.
>
> NOTE: the standard should specify the limit in the ranges for
> MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
> of 2**24. The number 2**24 cannot be represented in the 24-bit
> DataSegmentLength field and therefore can never be used.
>
> 5. This is a suggestion for a minor rewording in the standard to avoid
> misunderstandings.
>
> In Appendix E on page 188 of draft 8 it says:
>
> "The response to this command is a text response containing a list
> of
> targets and their addresses. Each target is returned as a target
> record. A target record begins with the TargetName text key,
> followed by a list of TargetAddress text keys, ..."
>
> In fact, there are situations where there are no targets and/or no
> addresses. These situations are clearly defined in the draft after
> the sentences quoted above, but it would help if those sentences
> at least hinted at the possibility that the lists could be empty
> or might not contain addresses. A possible rewording would be:
>
> "The response to this command is a text response containing a list
> of
> zero or more targets and, optionally, their addresses. Each target
> is returned as a target record. A target record begins with the
> TargetName text key, followed by a list of zero or more
> TargetAddress text keys, ..."
>
>
> 6. This is a suggestion for another very minor rewording in the
> standard.
>
> At the end of section 2.2.3 on page 29 of draft 8 it says:
>
> "Before full feature phase is established, only Login PDUs are
> allowed. ..."
>
> The suggested rewording is:
>
> "Before full feature phase is established, only Login Request and
> Login Response PDUs are allowed. ..."
From owner-ips@ece.cmu.edu Thu Nov 1 14:32:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28408
for ; Thu, 1 Nov 2001 14:32:34 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1IspC12106
for ips-outgoing; Thu, 1 Nov 2001 13:54:51 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Isnl12100
for ; Thu, 1 Nov 2001 13:54:49 -0500 (EST)
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06444;
Thu, 1 Nov 2001 11:54:31 -0700 (MST)
Received: from matador.Central.Sun.COM (matador.Central.Sun.COM [172.20.248.1])
by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13606;
Thu, 1 Nov 2001 11:54:44 -0700 (MST)
Received: from sun.com (nws-dhcp-199-212.Central.Sun.COM [172.20.193.212])
by matador.Central.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id LAA04388;
Thu, 1 Nov 2001 11:54:44 -0700 (MST)
Message-ID: <3BE19A82.1E3895A3@sun.com>
Date: Thu, 01 Nov 2001 11:54:58 -0700
From: "Mark A. Carlson"
Reply-To: mark.carlson@sun.com
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Bakke
CC: ips@ece.cmu.edu
Subject: Re: iSCSI MIB - comments on iscsiAccessList
References: <200111011716.JAA25752@cisco.com> <3BE18ECE.89BB64E0@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Mark Bakke wrote:
>
> Keith McCloghrie wrote:
> >
...
> > > This table does not cover all possible access control schemes that a
> > > vendor could implement. If access to an initiator cannot be
> > > determined just by its iSCSI name, an implementation may either
> > > include a single entry per target with the initiator name "iscsi", or
> > > may choose to place no entries in this table.
> >
> > Does no entries in the table allow any initiator access, or does it
> > deny access to all initiators ?
>
> I think that we need to decide that here. It was originally intended
> to mean that all initiators are allowed, but since we have a way to
> say that by putting in "iscsi", I think that it should mean either that
> all initiators are denied, or that the access list mechanism in the
> MIB is not enough to determine whether or not an initiator will
> be granted access. I would tend toward the latter; if there are no
> access list entries for a target, it means that there is not enough
> information to tell who gets to access it from this MIB. Implementations
> that provide value-add access control can augment this MIB with their
> own enterprise MIBs for access control.
>
> I would like to re-word this to:
>
> ... The value "iscsi" in an access list entry means that any
> initiator may access this target. If a target has no entries
> in the access list attributes table, it means that there is
> not enough information here to determine whether or not an
> initiator will be granted access.
But isn't the fact that the iSCSI name is used, as part of what access
control is based on, useful to applications? For example, if I use a
combination of iSCSI name and host userid to determine access, I would
still like to know that *some* access is available from this initiator
so that I can relate this logical relationship (maybe draw a graph).
How about a field that indicates "additional information required" rather
than leaving the whole entry blank? (empty really should mean no access,
rather than no standard access, and we need to differentiate these two).
Even if a vendor extends iscsiAccessList for their own access control, at
least the standard properties could be supported so that applications
can see that access is allowed from somewhere.
Having iscsiALInitiatorName = iscsi, and "additional information" = true,
would indicate that the proprietary access control mechanism needs to be
consulted to understand who has access, but at least there is some access
allowed.
-- mark
From owner-ips@ece.cmu.edu Thu Nov 1 14:51:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28717
for ; Thu, 1 Nov 2001 14:51:47 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1JQAT14679
for ips-outgoing; Thu, 1 Nov 2001 14:26:10 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1JQ8l14674
for ; Thu, 1 Nov 2001 14:26:08 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA23286
for ; Thu, 1 Nov 2001 20:26:02 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay02.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1JQ1W48556
for ; Thu, 1 Nov 2001 20:26:01 +0100
To: ips@ece.cmu.edu
MIME-Version: 1.0
Subject: Re: iSCSI: current UNH Plugfest
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Thu, 1 Nov 2001 21:25:59 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 21:26:01,
Serialize complete at 01/11/2001 21:26:01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fA1JQ9l14676
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
Sandeep - your note made me look - and I found that I forgot the list -
Sorry - Julo
----- Forwarded by Julian Satran/Haifa/IBM on 01-11-01 21:25 -----
Julian Satran
01-11-01 14:02
To: "Robert D. Russell"
cc:
From: Julian Satran/Haifa/IBM@IBMIL
Subject: Re: iSCSI: current UNH Plugfest
Bob,
Comments in text - thanks - Julo
"Robert D. Russell"
Sent by: owner-ips@ece.cmu.edu
01-11-01 00:39
Please respond to "Robert D. Russell"
To: ips@ece.cmu.edu
cc:
Subject: Re: iSCSI: current UNH Plugfest
Attached are the new issues that arose during the iSCSI plugfest
at UNH on Wednesday 31-Oct-2001.
(Note: these issues do not take into account any modifications or
clarifications that occured in the standard due to the issues raised
on Monday or Tuesday.)
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
----------------------------------------------------------------------------
1. Are receivers (initiator or target) REQUIRED to check that reserved
bits and/or fields are set to 0?
Section 3 on page 48 of draft 8 says:
"Any bits not defined MUST be set to zero. Any reserved fields and
values MUST be 0 unless specified otherwise."
and Section 8.3 on page 127 of draft 8 says:
"Explicit violations of the PDU layout rules stated in this document
are format errors. This when detected, usually indicates a major
implementation flaw in one of the parties.
When a target or an initiator receives an iSCSI PDU with a format
error, it MUST reset all transport connections in the session
immediately and escalate the format error to session recovery
(section 8.11.4)."
According to these rules, a PDU with reserved bits and/or fields that
are not set to 0 violates the PDU layout rules. Therefore, if an
initiator or target receives such a PDU, it should immediately close
all connections in the session and go to session recovery.
Clearly a format error has extremely severe consequences!
Although all vendors are setting reserved bits and fields to 0 on
PDUs they are sending, many are NOT checking PDUs they are receiving
to see if these bits and fields are set to 0. Basically, vendors are
saying "who cares if reserved bits and/or fields in incoming PDUs are
not zero? We do not want to take the time to do this checking, and
there is no benefit to doing it. As long as the non-reserved bits and
fields are set properly, we can and should proceed. Any time devoted
to doing this checking is wasted in 99+% of the cases, and in the
(unlikely) case that a non-zero bit or field is found, the
consequences are too severe."
There should be some statement in the standard to clarify what checking
is required and what is optional.
+++
As it was said already on this list there are things that a standard
better leaves unsaid :-)
In accordance with the good tradition of other iSCSI transports I suggest
we stay silent on this.
+++
2. A similar situation arises with respect to checking the consistency
of fields such as Version-max, Version-min and Version-active in Login
Requests and Login Responses.
For example, consider the Version-max field.
Section 3.12.5 says:
"All Login requests within the Login phase MUST carry the same
Version-max."
All vendor initiators are setting Version-max correctly on all
login requests they are sending, but many vendor targets are NOT
checking received login requests to ensure that this rule is enforced.
In particular, many targets simply use the Version-max and Version-min
on the first login request they receive on a new connection, and then
they ignore these fields on all subsequent login requests in the same
login phase.
Strictly speaking, a change in the Version-max field during the login
phase constitutes a protocol error according to section 8.8 on page 130
of draft 8:
"All violations of iSCSI PDU exchange sequences specified in this
draft are also protocol errors. This category of errors can be
addressed only by fixing the implementations; iSCSI defines Reject
and response codes to enable this".
Therefore the target should send back a login response with a status
of 0x0200 and then close the connection.
However, Section 3.12.5 also says:
"The target MUST use the value presented with the first login
request."
This rule seems to imply that the value CAN change, because if it
cannot
change, then it doesn't matter which one of the login requests it is
taken from, they are all the same anyway.
The suggestion is to keep the requirement that the target MUST use the
value presented on the first login request, but to allowed the target
to ignore the value presented on all subsequent login requests in the
same login phase. A similar rewording should be done for the other
fields.
+++
As above.
+++
3. Can commands be sent out of order on the same connection?
The behavior of targets is clearly specified in Section 2.2.2.3 on
page 25 of draft 8, which says:
"Except for the commands marked for immediate delivery the iSCSI
target layer MUST eliver the commands for execution in the order
specified by CmdSN."
Section 2.2.2.3 on page 26 of draft 8 also says:
"- CmdSN - the current command Sequence Number advanced by 1 on
each command shipped except for commands marked for immediate
delivery."
but the meaning of the term "shipped" is vague, and does not
necessarily
require that the PDUs arrive on the other end of a TCP connection
in the same order that the CmdSN values were assigned to these PDUs.
Some initiators have been designed to send commands out of CmdSN
order on one connection. Consider the situation where there is only
one connection and a high-level dispatcher creates a PDU for a SCSI
command that involves writing immediate data to the target. This PDU
is enqueued to a lower-level layer which has to setup, start, and
wait-for a DMA operation to move the immediate data into an onboard
buffer before the PDU can be put onto the wire. While this is
happening, the dispatcher creates another unrelated PDU for a SCSI
read command (for example), and when this PDU is passed to the
lower-level layer it can be sent immediately, ahead of the previous
write PDU and therefore out of order on this connection.
The standard clearly allows this to happen if the two PDUs were sent
on different connections, and seems to imply that this can also happen
when the two PDUs are sent on the same connection.
The suggestion is to put in the standard an explicit statement that
this is allowed or not allowed, as appropriate.
If this is allowed, such a statement would avoid the erroneous
assumption being made by some target implementers that within a single
connection, commands will arrive in order.
If this is not allowed, such a statement would avoid the erroneous
assumption being made by some initiator implementers that within a
single connection, commands can be put on the wire out of order.
+++
will add an explicit statement saying that this behaviour is forbidden.
2.2.2.1 will contain:
On any given connection, the iSCSI initiator MUST send the commands in the
order specified by CmdSN.
+++
4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
now allow: "A value of 0 indicates no limit."
Is this useful? Does it buy anything?
+++
I have already removed this.
However the numerical negotiation will have 0 (wherever appropriate) as a
means to indicate "I don't care"
The text suggested for this is:
For numerical negotiations, the value 0 MAY be specified by the offering
party as a "don't care"/"unlimited" value for parameters that explicitly
allow it; in this case, the responder may choose any legal value for the
parameter.
And in the MAXBurstSize etc:
A value of 0 MAY be used as a "don't care" offer in negotiations.
+++
The difficulties implementers are having with this are:
1) It is a special case.
2) It causes discontinuous ranges (for example, [0,64..2**24])
3) It violates the min/max function normally used for the key.
4) There is always a limit anyway.
Consider FirstBurstSize, which can have a value that is described
as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
is selected.
I one side offers 0 to mean unlimited, and the other side
has a limit, it will reply with that limit, say 128 Kbytes.
Therefore, the result is not min(0, 128K) but rather max(0, 128K).
The statement in the standard that "the minimum of the 2 numbers is
selected" is therefore wrong when one of the numbers is 0.
Furthermore, when an initiator or target receives an offer for one
of these keys, it cannot simply check that the offered value is
legal by testing it against some minimum and maximum. It must first
check for 0 and then only if that check shows the value is non-zero
can it do the min/max range check for legality (i.e., 64-2**24).
Finally, there is always a limit. If nothing else it is the
limit imposed by the 24-bit DataSegmentLength field of the PDU
requesting the transfer. It is useless to specify a FirstBurstSize
(or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
the largest possible DataSegmentLength in any PDU that can use
this value is 2**24-1.
The suggestion is to just eliminate this special case of 0 and require
that the range 64-to-(2**24-1) be used instead -- it has exactly the
same effect in all cases, it is easier to describe in the standard
because it avoids all the extra words, and it is easier to code
because it avoids all the special cases.
NOTE: the standard should specify the limit in the ranges for
MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
of 2**24. The number 2**24 cannot be represented in the 24-bit
DataSegmentLength field and therefore can never be used.
5. This is a suggestion for a minor rewording in the standard to avoid
misunderstandings.
In Appendix E on page 188 of draft 8 it says:
"The response to this command is a text response containing a list of
targets and their addresses. Each target is returned as a target
record. A target record begins with the TargetName text key,
followed by a list of TargetAddress text keys, ..."
In fact, there are situations where there are no targets and/or no
addresses. These situations are clearly defined in the draft after
the sentences quoted above, but it would help if those sentences
at least hinted at the possibility that the lists could be empty
or might not contain addresses. A possible rewording would be:
"The response to this command is a text response containing a list of
zero or more targets and, optionally, their addresses. Each target
is returned as a target record. A target record begins with the
TargetName text key, followed by a list of zero or more
TargetAddress text keys, ..."
+++
OK
+++
6. This is a suggestion for another very minor rewording in the standard.
At the end of section 2.2.3 on page 29 of draft 8 it says:
"Before full feature phase is established, only Login PDUs are
allowed. ..."
The suggested rewording is:
"Before full feature phase is established, only Login Request and
Login Response PDUs are allowed. ..."
+++
OK
+++
From owner-ips@ece.cmu.edu Thu Nov 1 15:24:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28409
for ; Thu, 1 Nov 2001 14:32:34 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1J8rQ13182
for ips-outgoing; Thu, 1 Nov 2001 14:08:53 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from pop.mainstreet.net (smtp.mainstreet.net [207.5.0.46])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Hwel07182
for ; Thu, 1 Nov 2001 12:58:40 -0500 (EST)
Received: from vip (saqibj.mainstreet.net [207.5.1.168])
by pop.mainstreet.net (8.11.3/8.11.3) with SMTP id fA1HsrP22880;
Thu, 1 Nov 2001 09:54:54 -0800 (PST)
Reply-To:
From: "Saqib Jang"
To: "Ofer Biran" ,
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Date: Thu, 1 Nov 2001 10:03:29 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To:
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
I thought the latest security draft already closed
on this issue.
>From Section 2.3 of -04 draft.
iSCSI security implementations MUST support ESP in transport mode.
Saqib
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Ofer Biran
Sent: Thursday, November 01, 2001 4:31 AM
To: ips@ece.cmu.edu
Subject: iSCSI: IPsec tunnel / transport mode decision
I'd like to drive this open issue into group consensus. It seems to
me that the tendency was more toward making tunnel mode a MUST as iFCP
and FCIP did, mainly due the option of integrating an existing IPsec
chip/box with the iSCSI implementation offering. If we reach this decision,
we may choose even not to mention transport mode (as MAY or some other
recommending text).
There is an excellent analysis made by Bernard Aboba in Section
"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
that can help us with this decision (also Section "5.2. NAT traversal" is
relevant).
Regards,
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
From owner-ips@ece.cmu.edu Thu Nov 1 15:40:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29764
for ; Thu, 1 Nov 2001 15:40:09 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1Ju9317265
for ips-outgoing; Thu, 1 Nov 2001 14:56:09 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Ju7l17258
for ; Thu, 1 Nov 2001 14:56:07 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id UAA118736;
Thu, 1 Nov 2001 20:56:00 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1Jtxw27002;
Thu, 1 Nov 2001 20:55:59 +0100
Importance: Normal
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
To:
Cc:
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "Ofer Biran"
Date: Thu, 1 Nov 2001 21:57:08 +0100
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
01/11/2001 21:55:59
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
No, this issue never got rough consensus. The statement was
put there just to provoke the discussion. And before the thread
of the security draft official positioning is awaken - an effort
will be made s.t. it will not include any normative text that
doesn't match the protocols standards normative text.
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
"Saqib Jang" on 01/11/2001 19:03:29
Please respond to
To: Ofer Biran/Haifa/IBM@IBMIL,
cc:
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
I thought the latest security draft already closed
on this issue.
From Section 2.3 of -04 draft.
iSCSI security implementations MUST support ESP in transport mode.
Saqib
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Ofer Biran
Sent: Thursday, November 01, 2001 4:31 AM
To: ips@ece.cmu.edu
Subject: iSCSI: IPsec tunnel / transport mode decision
I'd like to drive this open issue into group consensus. It seems to
me that the tendency was more toward making tunnel mode a MUST as iFCP
and FCIP did, mainly due the option of integrating an existing IPsec
chip/box with the iSCSI implementation offering. If we reach this decision,
we may choose even not to mention transport mode (as MAY or some other
recommending text).
There is an excellent analysis made by Bernard Aboba in Section
"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
that can help us with this decision (also Section "5.2. NAT traversal" is
relevant).
Regards,
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
From owner-ips@ece.cmu.edu Thu Nov 1 15:42:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29885
for ; Thu, 1 Nov 2001 15:42:45 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1KF8518952
for ips-outgoing; Thu, 1 Nov 2001 15:15:08 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1KEIl18879
for ; Thu, 1 Nov 2001 15:14:20 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA128846
for ; Thu, 1 Nov 2001 14:11:38 -0600
Received: from d04nms41.raleigh.ibm.com (d04nms41.raleigh.ibm.com [9.67.228.19])
by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA1KEC9210008
for ; Thu, 1 Nov 2001 15:14:12 -0500
Subject: Re: is TargetName always mandatory or not?
To: "Jim Hafner"
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
Message-ID:
From: "Andre Asselin"
Date: Thu, 1 Nov 2001 15:15:13 -0500
X-MIMETrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.8 |June 18, 2001) at
11/01/2001 03:14:11 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Jim,
I agree with what you say, except for the part that mapping
TSID=target portal group tag will work.
Let's assume the following architecture: I have a network entity with one
network portal (and thus one portal group). Inside this entity lives two
iSCSI targets.
Scenerio: An iSCSI initiator opens a connection to the network portal in
order to add a connection to an already existing session (the network
entity's networking code knows this because TSID in the initial login
request is 0). The networking code needs to determine what session the
initiator wants to add to, so it compares some items from the initial login
request to each of the established sessions until it finds a match. The
question is what items should it compare to identify a match?
Section 3.12.9 of the spec reads:
The TSID is the target assigned tag for a session with a specific
named initiator that, together with the ISID uniquely identifies a
session with that initiator.
As you say, this is clearly target centric (because, for example, an
initiator could have 2 different sessions open to two different targets
that have the same TSID). But from a target point of view, what that text
means to me that the network entity's networking code should compare ISID +
InitiatorName + TSID to determine a match. That implies that TSID must be
unique per TargetName and per portal group ID. If TSID is just the target
portal group tag, then the comparison wouldn't work. For example, using
the architecture above where there is just one portal group, the target
could have two sessions open: session A (InitiatorName=foo, ISID=1,
TargetName=bar, TSID=0) and session B (InitiatorName=foo, ISID=1,
TargetName=foobar, TSID=0). If it receives a login request with
(InitiatorName=foo, ISID=1, TSID=0), which session is it for?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
Jim Hafner
To: Andre Asselin/Raleigh/IBM@IBMUS
10/31/2001 cc: ips@ece.cmu.edu
06:33 PM From: Jim Hafner/Almaden/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?(Document link: Andre Asselin)
Andre,
First, your comment "SSID + InitiatorName must be enough to uniquely
identify a session" is target-centric. It would be different from the
initiator's viewpoint. However, from the target's viewpoint, the target
name is implicit and from the initiator viewpoint, the initiator name is
implicit, so globally, the triple of the two names + SSID (made up of the
ISID and TSID) form the identifier of the session. Locally (between two
specific guys), the names are implicit so only the SSID is required. It's
all a matter of point of view!
As for the difference in identifiers, as I mentioned in the private note,
the session is an iSCSI construct and is identified by iSCSI things. The
nexus is a SCSI thing and is identified by SCSI constructs (based on how
we've mapped the iSCSI things to SCSI things).
However, you've brought to the fore again a related question: "what value
does the TSID provide to the protocol?"
I'm not going to answer that, but I will note that one target
implementation that (I think) works is that the TSID = target portal group
tag.
The other thing to ask is "what value is there in the nexus identifier?"
This is never really used in SCSI at all, so it's not a critical issue what
composes it. However, it is important (IMO) that the SCSI ports have names
and the logical derivative of that statement is that the nexus is
identified by the concatenation of the SCSI port names (hence the
definition we have).
Jim Hafner
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 03:00:53 pm
Sent by: owner-ips@ece.cmu.edu
To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or not?
John,
WHOOPS! I was wrong; you are absolutely right that the spec says
"TargetName" and not "TSID". When I was reading through it, I saw
"TargetName", but read to myself "TSID". Apologies...
In my defense (confusion?), however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a session. Going by that, SSID +
InitiatorName must be enough to uniquely identify a session.
Jim Hafner pointed out to me that the I_T nexus is identified by one
thing and the session is identified by another. If the two must have a 1-1
mapping in iSCSI, why are there two different identifiers? Why not just
use the current definition of the I_T nexus to uniquely identify both the
nexus and session (i.e. get rid of TSID)?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre
Asselin/Raleigh/IBM@IBMUS
10/31/2001 cc: ips@ece.cmu.edu
04:42 PM From: John Hufferd/San
Jose/IBM@IBMUS
Subject: Re: is TargetName
always mandatory or not?(Document link: Andre Asselin)
Andre,
I looked again through the document and No where could I find a statement
that you claimed as "a nexus, and therefore an iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and portal group tag". It is
the InitiatorName, ISID, TSID, with the TargetName and PortalGroup.
Please point out to me in the Spec (8 or above), where I can find your
statement on I_T Nexus.
I did find the following (please ignore for this conversation the "i" and
't" stuff):
"- Session: The group of TCP connections that link an initiator with a
target, form a session (loosely equivalent to a SCSI I-T nexus). TCP
connections can be added and removed from a session. Across all connections
within a session, an initiator sees one "target image". "
" - I_T nexus: According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The
I_T nexus can be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus
identifier is not equal to the session identifier (SSID). "
I have not found a place where Session ID is tied to the TSID.
Hence my comment that we also need to have the TargetName in the Initial
Login on all Connections.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
John & Julian,
How about this for the section 5 text:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The initial login
request
of the leading Login MAY also include the SessionType key=value pair, in
which case if the SessionType is not "discovery", then the initial login
request
MUST also include the key=value pair TargetName.
John,
I disagree with your second statement: I don't see any way you could
have 2 different sessions established within the same portal group with the
same InitiatorName, ISID, and TSID. The spec. says that a nexus, and
therefore an iSCSI session, is uniquely identified by the InitiatorName,
ISID, TSID, and portal group tag. There is no mention of TargetName
contributing to the identificaiton of a session. In my opinion, a
non-leading connection should NOT have the TargetName, since it doesn't
contribute anything.
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John
Hufferd/San To: Julian
Satran/Haifa/IBM@IBMIL
Jose/IBM@IBMUS cc: ips@ece.cmu.edu
Sent by: Subject: Re: is TargetName
always mandatory or not?
owner-ips@ece.
cmu.edu
10/31/2001
04:20 AM
Julian,
I think the TargetName should be included on the Initial Login Request on
the Leading Login. It seem strange to permit the Authentication functions
to proceed if perhaps the intended Target is different then the one doing
the Authentication. The way it currently is written, you could pass all
the Security test and then find out just before going into Full Function
Phase, that it was intended for some other Target. Seems like a waste.
My I think that TargetName should also be on all connections on the Initial
Login Request. Here is my thinking:
The SSID (ISID+TSID) is unique only with regards to a Specific Initiator
and Target Node Pair. It is therefore not clear that just knowing the SSID
and InitiatorName is enough to understand what session the subsequent
connections are being attached to. And it is possible that the CID could
be also overlapped with another session.
Therefore, I think it make since to determine all this on the initial Login
on every Connection, so you know at the beginning what values can be
negotiated, or that are being set to the right Session.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/30/2001 11:33:50 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: Re: is TargetName always mandatory or not?
It is the leading login:
The section 5 paragraph will read:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The leading Login
request MAY also include the SessionType key=value pair in which case if
the SessionType is not "discovery" then the leading Login Request MUST
also include the key=value pair TargetName.
Julo
Andre Asselin/Raleigh/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:08
Please respond to Andre Asselin
To: "IPS Reflector (E-mail)"
cc:
Subject: is TargetName always mandatory or not?
In section 5 of the spec, it says "If the SessionType is not
"discovery" then the initial Login Request MUST also include the key=value
pair TargetName.". However, in Appendix D, the description for TargetName
says it is Leading Only.
Should TargetName not be Leading Only, or should the text in section
5
say that TargetName must be in the initial Login Request of a leading
connection?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
From owner-ips@ece.cmu.edu Thu Nov 1 15:43:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29904
for ; Thu, 1 Nov 2001 15:43:34 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1Jvsu17410
for ips-outgoing; Thu, 1 Nov 2001 14:57:54 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Jvol17398
for ; Thu, 1 Nov 2001 14:57:50 -0500 (EST)
Received: from icarus.sanera.net (icarus [192.168.254.11])
by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fA1Jviu02362;
Thu, 1 Nov 2001 11:57:44 -0800
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
by icarus.sanera.net (8.11.6/8.11.2) with SMTP id fA1Jvc604150;
Thu, 1 Nov 2001 11:57:38 -0800
From: "Bill Strahm"
To: , "Ofer Biran" ,
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Date: Thu, 1 Nov 2001 11:57:21 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To:
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Funny because RFC 2401 says (Section 4.1)
"
In summary,
a) A host MUST support both transport and tunnel mode.
b) A security gateway is required to support only tunnel
mode. If it supports transport mode, that should be used
only when the security gateway is acting as a host, e.g.,
for network management.
"
I am assuming that at least one end of the iSCSI implementation is a Host
(if not both ends) and therefore will have a conformant IPsec
implementation...
Now the question is where do we want to allow security endpoints to be. If
we want to allow only host-host security (and the requisite policy
nightmares) then Transport Mode will work. However if we want to allow
Tunneling between hosts and security gateways, then Tunnel mode will need to
be used. In reality I think we should stick with the 2401 requirements,
that way I don't have to write my own implementation...
I have not seen a call of consensus on this issue, have you issued it David
?
Bill
+========+=========+=========+=========+=========+=========+=========+
Bill Strahm Software Development is a race between Programmers
Member of the trying to build bigger and better idiot proof software
Technical Staff and the Universe trying to produce bigger and better
bill@sanera.net idiots.
(503) 601-0263 So far the Universe is winning --- Rich Cook
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Saqib Jang
Sent: Thursday, November 01, 2001 10:03 AM
To: Ofer Biran; ips@ece.cmu.edu
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
I thought the latest security draft already closed
on this issue.
>From Section 2.3 of -04 draft.
iSCSI security implementations MUST support ESP in transport mode.
Saqib
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Ofer Biran
Sent: Thursday, November 01, 2001 4:31 AM
To: ips@ece.cmu.edu
Subject: iSCSI: IPsec tunnel / transport mode decision
I'd like to drive this open issue into group consensus. It seems to
me that the tendency was more toward making tunnel mode a MUST as iFCP
and FCIP did, mainly due the option of integrating an existing IPsec
chip/box with the iSCSI implementation offering. If we reach this decision,
we may choose even not to mention transport mode (as MAY or some other
recommending text).
There is an excellent analysis made by Bernard Aboba in Section
"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
that can help us with this decision (also Section "5.2. NAT traversal" is
relevant).
Regards,
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
From owner-ips@ece.cmu.edu Thu Nov 1 16:17:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00708
for ; Thu, 1 Nov 2001 16:17:00 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1KgDs21327
for ips-outgoing; Thu, 1 Nov 2001 15:42:13 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from imo-m10.mx.aol.com (imo-m10.mx.aol.com [64.12.136.165])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1KgBl21322
for ; Thu, 1 Nov 2001 15:42:11 -0500 (EST)
Received: from VAHUJA@aol.com
by imo-m10.mx.aol.com (mail_out_v31_r1.8.) id 3.fc.e76e9bf (4240)
for ; Thu, 1 Nov 2001 15:42:04 -0500 (EST)
From: VAHUJA@aol.com
Message-ID:
Date: Thu, 1 Nov 2001 15:42:03 EST
Subject: Fwd: iSCSI: IPsec tunnel / transport mode decision
To: ips@ece.cmu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="part1_fc.e76e9bf.29130d9b_boundary"
X-Mailer: AOL 5.0 for Windows sub 138
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
--part1_fc.e76e9bf.29130d9b_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
My concern is with the requirement that a host MUST support both Tunnel and
Transport Mode. A large enterprise most likely has its own VPN today. For it
to not trust its Intranet is a question they already addressed. Instead of
imposing another layer of IPSec for the enterprise, we ought to make it easy
for them to use their existing VPNs for securing transport over the Internet.
Bottom line, I think we should go with Tunnel Mode, that can be deployed
anywhere in the customer environment, and leave it up to the customer and
vendor to determine where exactly to deploy the Tunnel Mode. Transport Mode
should be Optional and let the market demand vs cost drive its
implementations.
Trust the customer!
--part1_fc.e76e9bf.29130d9b_boundary
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path:
Received: from rly-za03.mx.aol.com (rly-za03.mail.aol.com [172.31.36.99]) by air-za04.mail.aol.com (v82.22) with ESMTP id MAILINZA45-1101152150; Thu, 01 Nov 2001 15:21:50 -0500
Received: from ece.cmu.edu (ece.cmu.edu [128.2.136.200]) by rly-za03.mx.aol.com (v80.21) with ESMTP id MAILRELAYINZA310-1101152123; Thu, 01 Nov 2001 15:21:23 -0500
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1Jvsu17410
for ips-outgoing; Thu, 1 Nov 2001 14:57:54 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1Jvol17398
for ; Thu, 1 Nov 2001 14:57:50 -0500 (EST)
Received: from icarus.sanera.net (icarus [192.168.254.11])
by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fA1Jviu02362;
Thu, 1 Nov 2001 11:57:44 -0800
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
by icarus.sanera.net (8.11.6/8.11.2) with SMTP id fA1Jvc604150;
Thu, 1 Nov 2001 11:57:38 -0800
From: "Bill Strahm"
To: , "Ofer Biran" ,
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Date: Thu, 1 Nov 2001 11:57:21 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To:
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Funny because RFC 2401 says (Section 4.1)
"
In summary,
a) A host MUST support both transport and tunnel mode.
b) A security gateway is required to support only tunnel
mode. If it supports transport mode, that should be used
only when the security gateway is acting as a host, e.g.,
for network management.
"
I am assuming that at least one end of the iSCSI implementation is a Host
(if not both ends) and therefore will have a conformant IPsec
implementation...
Now the question is where do we want to allow security endpoints to be. If
we want to allow only host-host security (and the requisite policy
nightmares) then Transport Mode will work. However if we want to allow
Tunneling between hosts and security gateways, then Tunnel mode will need to
be used. In reality I think we should stick with the 2401 requirements,
that way I don't have to write my own implementation...
I have not seen a call of consensus on this issue, have you issued it David
?
Bill
+========+=========+=========+=========+=========+=========+=========+
Bill Strahm Software Development is a race between Programmers
Member of the trying to build bigger and better idiot proof software
Technical Staff and the Universe trying to produce bigger and better
bill@sanera.net idiots.
(503) 601-0263 So far the Universe is winning --- Rich Cook
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Saqib Jang
Sent: Thursday, November 01, 2001 10:03 AM
To: Ofer Biran; ips@ece.cmu.edu
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
I thought the latest security draft already closed
on this issue.
>From Section 2.3 of -04 draft.
iSCSI security implementations MUST support ESP in transport mode.
Saqib
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Ofer Biran
Sent: Thursday, November 01, 2001 4:31 AM
To: ips@ece.cmu.edu
Subject: iSCSI: IPsec tunnel / transport mode decision
I'd like to drive this open issue into group consensus. It seems to
me that the tendency was more toward making tunnel mode a MUST as iFCP
and FCIP did, mainly due the option of integrating an existing IPsec
chip/box with the iSCSI implementation offering. If we reach this decision,
we may choose even not to mention transport mode (as MAY or some other
recommending text).
There is an excellent analysis made by Bernard Aboba in Section
"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
that can help us with this decision (also Section "5.2. NAT traversal" is
relevant).
Regards,
Ofer
Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com 972-4-8296253
--part1_fc.e76e9bf.29130d9b_boundary--
From owner-ips@ece.cmu.edu Thu Nov 1 16:17:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00721
for ; Thu, 1 Nov 2001 16:17:02 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1KhXu21454
for ips-outgoing; Thu, 1 Nov 2001 15:43:33 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1KhVl21448
for ; Thu, 1 Nov 2001 15:43:31 -0500 (EST)
Received: from localhost (rdr@localhost)
by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA12313;
Thu, 1 Nov 2001 15:43:18 -0500 (EST)
Date: Thu, 1 Nov 2001 15:43:18 -0500
From: "Robert D. Russell"
To: Julian Satran
cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or not?
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Julian:
Please see comments below:
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
> From Julian_Satran@il.ibm.com Wed Oct 31 08:15:10 2001
> Date: Wed, 31 Oct 2001 09:33:50 +0200
> From: Julian Satran
> To: ips@ece.cmu.edu
> Subject: Re: is TargetName always mandatory or not?
>
> It is the leading login:
>
> The section 5 paragraph will read:
>
> The initial Login request of the first connection of a session (leading
> login) MUST include the InitiatorName key=value pair. The leading Login
> request MAY also include the SessionType key=value pair in which case if
> the SessionType is not "discovery" then the leading Login Request MUST
> also include the key=value pair TargetName.
>
> Julo
I believe the phrase "in which case" should be taken out, because in the
case when SessionType key is omited, the default session type is normal
and the initial Login request MUST include the TargetName key.
Furthermore, if the session is to be a discovery session, then the
SessionType=discover pair MUST also be present in the initial login
request. The new wording would then be:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. If the session
is to be a discovery session, then the leading Login request MUST also
include the SessionType=discovery pair. If the session is to be a
normal session, then the leading Login request MUST also include the
key=value pair TargetName.
I also have some related changes that need to be made in order
to maintain consistency with the above wording in section 5.
1. The following sentence must be removed from the end of section 5.1
(because the LO designation means that the InititatorName, TargetName,
and SessionType keys cannot be sent at all during the login phase of
new connections within existing sessions).
remove
If sent on new connections within an existing session the iSCSI
Target Name and the iSCSI Initiator Name MUST be the same as the
one used for the leading connection.
2. The wording in Appendix D for the InitiatorName and TargetName
entries should be changed as follows:
for InitiatorName:
change
"This key MUST be provided by the initiator of the TCP connection to
the remote endpoint before the end of the login phase."
to
"This key MUST be provided by the initiator on the initial Login
request of the first connection of any type of session."
for TargetName:
change
"This key MUST be provided by the initiator of the TCP connection to
the remote endpoint before the end of the login phase."
to
"This key MUST be provided by the initiator on the initial Login
request of the first connection of a normal session."
3. The following phrase should be added to the wording in Appendix D
for the SessionType entry:
"This key can only be used on the initial Login request of the first
connection of a session."
4. Finally, the wording in section 2.2.7 should be changed:
change
The only exception is if a discovery session (see 2.4) is to be
established; the iSCSI Initiator Name is still required, but the
iSCSI Target Name may be ignored. The key "SessionType=discovery"
is sent by the initiator at login to indicate a discovery session.
to
The only exception is if a discovery session (see 2.4) is to be
established; the iSCSI Initiator Name is still required, but the
iSCSI Target Name may be omitted. The key "SessionType=discovery"
MUST be sent by the initiator on the initial Login request of the
first connection to indicate a discovery session.
From owner-ips@ece.cmu.edu Thu Nov 1 16:17:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00746
for ; Thu, 1 Nov 2001 16:17:14 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1KWoM20506
for ips-outgoing; Thu, 1 Nov 2001 15:32:50 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1KWYl20473
for ; Thu, 1 Nov 2001 15:32:34 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA77522
for ; Thu, 1 Nov 2001 14:29:54 -0600
Received: from d04nms41.raleigh.ibm.com (d04nms41.raleigh.ibm.com [9.67.228.19])
by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA1KWR9128212
for ; Thu, 1 Nov 2001 15:32:27 -0500
Subject: Re: is TargetName always mandatory or not?
To: "John Hufferd"
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
Message-ID:
From: "Andre Asselin"
Date: Thu, 1 Nov 2001 15:33:28 -0500
X-MIMETrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.8 |June 18, 2001) at
11/01/2001 03:32:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
John,
Section 3.12.9 of the spec reads:
The TSID is the target assigned tag for a session with a specific
named initiator that, together with the ISID uniquely identifies a
session with that initiator.
So according to that, TSID + ISID + InitiatorName must be enough
information for a target to uniquely idenfity a session, so mapping TSID to
target portal group ID won't always work (see my other note addressed to
Jim for an example of where it won't).
After thinking about this for a while, I've come to the same
conclusion as you (that a target should compare ISID + InitiatorName +
TargetName + target portal group to uniquely identify a session), but from
a different angle.
My reasoning: Since there is a 1-1 correspondence between an I_T
nexus and a session, if you can identify the nexus, you've identified the
session, and vice versa. Since 3.12.9 says that TSID + ISID +
InitiatorName must uniquely identify a session, then TSID must be an alias
for TargetName + target portal group ID, since (ISID + InitiatorName +
TargetName + portal group ID) uniquely identifies a nexus. In my opinion,
that aliasing only complicates (and confuses!) the protocol and should be
done away with. If TargetName were required on every initial login
request, then the target could compare (ISID + InitiatorName + TargetName +
portal group) to determine a session match, and forget about TSID entirely.
In that case, there is no need for TSID, except to flag whether the login
request is to create a new session or to add a new connection to an
existing session (i.e. indicate leading login), in which case it could be
dropped and replaced with a single bit.
To eliminate TSID, I believe the following changes would be needed:
- Eliminate TSID from login request and login response
- Use one of the bits in byte 1 of login request to indicate a leading
login, and update any text that refers to TSID=0 to refer to this bit
- Define session to be equivalent to I_T nexus (not "loosely equivalent
to")
- Define SSID/session ID to be the same as the I_T nexus identifier
- Remove the "LO" from TargetName
- If it hasn't already been done, remove the "LO" from InitiatorName
Comments?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre Asselin/Raleigh/IBM
10/31/2001 cc: ips@ece.cmu.edu
06:32 PM From: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?(Document link: Andre Asselin)
Andre,
TSID, and therefore SSID is a handle that can be use to queue stuff within
the scope of the Initiator Node and Target Node. The target can use what
ever it wants in this field. Some Folks might want to use the TSID to be
the Portal Group Tag and I think then it might be unique. But even then
only within the InitiatorName+ISID Space. Anyway, you need to think of it
only as a handle. Also since most folks will not have 64k Sessions into
their box, some (most?) implementations might find it unique. But it is
not unique in the Architecture.
Now the important thing is that, as things stand now, the Login needs the
InitiatorName, and the TargetName on the Initial Login of ALL Connections
in order to uniquely identify secondary Connections to the Original
Connection of the Session.
Does that seem correct to you and others on the Reflector?
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin
10/31/2001 03:00 PM
To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not? (Document link: John
Hufferd)
John,
WHOOPS! I was wrong; you are absolutely right that the spec says
"TargetName" and not "TSID". When I was reading through it, I saw
"TargetName", but read to myself "TSID". Apologies...
In my defense (confusion?), however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a session. Going by that, SSID +
InitiatorName must be enough to uniquely identify a session.
Jim Hafner pointed out to me that the I_T nexus is identified by one
thing and the session is identified by another. If the two must have a 1-1
mapping in iSCSI, why are there two different identifiers? Why not just
use the current definition of the I_T nexus to uniquely identify both the
nexus and session (i.e. get rid of TSID)?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre Asselin/Raleigh/IBM@IBMUS
10/31/2001 cc: ips@ece.cmu.edu
04:42 PM From: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?(Document link: Andre Asselin)
Andre,
I looked again through the document and No where could I find a statement
that you claimed as "a nexus, and therefore an iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and portal group tag". It is
the InitiatorName, ISID, TSID, with the TargetName and PortalGroup.
Please point out to me in the Spec (8 or above), where I can find your
statement on I_T Nexus.
I did find the following (please ignore for this conversation the "i" and
't" stuff):
"- Session: The group of TCP connections that link an initiator with a
target, form a session (loosely equivalent to a SCSI I-T nexus). TCP
connections can be added and removed from a session. Across all connections
within a session, an initiator sees one "target image". "
" - I_T nexus: According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The
I_T nexus can be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus
identifier is not equal to the session identifier (SSID). "
I have not found a place where Session ID is tied to the TSID.
Hence my comment that we also need to have the TargetName in the Initial
Login on all Connections.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
John & Julian,
How about this for the section 5 text:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The initial login
request
of the leading Login MAY also include the SessionType key=value pair, in
which case if the SessionType is not "discovery", then the initial login
request
MUST also include the key=value pair TargetName.
John,
I disagree with your second statement: I don't see any way you could
have 2 different sessions established within the same portal group with the
same InitiatorName, ISID, and TSID. The spec. says that a nexus, and
therefore an iSCSI session, is uniquely identified by the InitiatorName,
ISID, TSID, and portal group tag. There is no mention of TargetName
contributing to the identificaiton of a session. In my opinion, a
non-leading connection should NOT have the TargetName, since it doesn't
contribute anything.
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John
Hufferd/San To: Julian
Satran/Haifa/IBM@IBMIL
Jose/IBM@IBMUS cc: ips@ece.cmu.edu
Sent by: Subject: Re: is TargetName
always mandatory or not?
owner-ips@ece.
cmu.edu
10/31/2001
04:20 AM
Julian,
I think the TargetName should be included on the Initial Login Request on
the Leading Login. It seem strange to permit the Authentication functions
to proceed if perhaps the intended Target is different then the one doing
the Authentication. The way it currently is written, you could pass all
the Security test and then find out just before going into Full Function
Phase, that it was intended for some other Target. Seems like a waste.
My I think that TargetName should also be on all connections on the Initial
Login Request. Here is my thinking:
The SSID (ISID+TSID) is unique only with regards to a Specific Initiator
and Target Node Pair. It is therefore not clear that just knowing the SSID
and InitiatorName is enough to understand what session the subsequent
connections are being attached to. And it is possible that the CID could
be also overlapped with another session.
Therefore, I think it make since to determine all this on the initial Login
on every Connection, so you know at the beginning what values can be
negotiated, or that are being set to the right Session.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/30/2001 11:33:50 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: Re: is TargetName always mandatory or not?
It is the leading login:
The section 5 paragraph will read:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The leading Login
request MAY also include the SessionType key=value pair in which case if
the SessionType is not "discovery" then the leading Login Request MUST
also include the key=value pair TargetName.
Julo
Andre Asselin/Raleigh/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:08
Please respond to Andre Asselin
To: "IPS Reflector (E-mail)"
cc:
Subject: is TargetName always mandatory or not?
In section 5 of the spec, it says "If the SessionType is not
"discovery" then the initial Login Request MUST also include the key=value
pair TargetName.". However, in Appendix D, the description for TargetName
says it is Leading Only.
Should TargetName not be Leading Only, or should the text in section
5
say that TargetName must be in the initial Login Request of a leading
connection?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
From owner-ips@ece.cmu.edu Thu Nov 1 16:26:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00952
for ; Thu, 1 Nov 2001 16:26:12 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1KeVX21188
for ips-outgoing; Thu, 1 Nov 2001 15:40:31 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1KeOl21168
for ; Thu, 1 Nov 2001 15:40:24 -0500 (EST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA26448
for ; Thu, 1 Nov 2001 15:37:29 -0500
Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41])
by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1KdqC95554
for ; Thu, 1 Nov 2001 13:39:52 -0700
Importance: Normal
Subject: Re: is TargetName always mandatory or not?
To: "Andre Asselin"
Cc: ips@ece.cmu.edu
From: "Jim Hafner"
Date: Thu, 1 Nov 2001 12:39:51 -0800
Message-ID:
X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at
11/01/2001 12:39:52 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Andre,
Your picture isn't quite right. The portal group tag is relative to the
iSCSI target and that target is *uniquely* identified by it's name. So, in
your picture, there are two targets (not one). Each can label its target
portal group any way it wants (independent of the other). Each has
independent control over the TSIDs it uses. Each may *share* use of a
network portal, but that's a different issue. The model implies two
independent targets (even if they live in the same network entity and share
resources) in your scenario.
In other words, the portal groups are wrt targets not the network entity.
In your scenario, whatever layer (you put it in the network code) has to
decide what session to add the connection to has the initiator name, the
ISID, the TSID *and* the target name (you left this out) in the login
request. That fully qualifies both the target and the session as well.
Jim Hafner
Andre Asselin
11/01/2001 12:15 pm
To: Jim Hafner/Almaden/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not? (Document link:
Database 'Jim Hafner', View '($Inbox)')
Jim,
I agree with what you say, except for the part that mapping
TSID=target portal group tag will work.
Let's assume the following architecture: I have a network entity with one
network portal (and thus one portal group). Inside this entity lives two
iSCSI targets.
Scenerio: An iSCSI initiator opens a connection to the network portal in
order to add a connection to an already existing session (the network
entity's networking code knows this because TSID in the initial login
request is 0). The networking code needs to determine what session the
initiator wants to add to, so it compares some items from the initial login
request to each of the established sessions until it finds a match. The
question is what items should it compare to identify a match?
Section 3.12.9 of the spec reads:
The TSID is the target assigned tag for a session with a specific
named initiator that, together with the ISID uniquely identifies a
session with that initiator.
As you say, this is clearly target centric (because, for example, an
initiator could have 2 different sessions open to two different targets
that have the same TSID). But from a target point of view, what that text
means to me that the network entity's networking code should compare ISID +
InitiatorName + TSID to determine a match. That implies that TSID must be
unique per TargetName and per portal group ID. If TSID is just the target
portal group tag, then the comparison wouldn't work. For example, using
the architecture above where there is just one portal group, the target
could have two sessions open: session A (InitiatorName=foo, ISID=1,
TargetName=bar, TSID=0) and session B (InitiatorName=foo, ISID=1,
TargetName=foobar, TSID=0). If it receives a login request with
(InitiatorName=foo, ISID=1, TSID=0), which session is it for?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
Jim Hafner
To:
10/31/2001 cc:
06:33 PM From:
Subject: (Document link: Andre Asselin)
Andre,
First, your comment "SSID + InitiatorName must be enough to uniquely
identify a session" is target-centric. It would be different from the
initiator's viewpoint. However, from the target's viewpoint, the target
name is implicit and from the initiator viewpoint, the initiator name is
implicit, so globally, the triple of the two names + SSID (made up of the
ISID and TSID) form the identifier of the session. Locally (between two
specific guys), the names are implicit so only the SSID is required. It's
all a matter of point of view!
As for the difference in identifiers, as I mentioned in the private note,
the session is an iSCSI construct and is identified by iSCSI things. The
nexus is a SCSI thing and is identified by SCSI constructs (based on how
we've mapped the iSCSI things to SCSI things).
However, you've brought to the fore again a related question: "what value
does the TSID provide to the protocol?"
I'm not going to answer that, but I will note that one target
implementation that (I think) works is that the TSID = target portal group
tag.
The other thing to ask is "what value is there in the nexus identifier?"
This is never really used in SCSI at all, so it's not a critical issue what
composes it. However, it is important (IMO) that the SCSI ports have names
and the logical derivative of that statement is that the nexus is
identified by the concatenation of the SCSI port names (hence the
definition we have).
Jim Hafner
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 03:00:53 pm
Sent by: owner-ips@ece.cmu.edu
To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or not?
John,
WHOOPS! I was wrong; you are absolutely right that the spec says
"TargetName" and not "TSID". When I was reading through it, I saw
"TargetName", but read to myself "TSID". Apologies...
In my defense (confusion?), however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a session. Going by that, SSID +
InitiatorName must be enough to uniquely identify a session.
Jim Hafner pointed out to me that the I_T nexus is identified by one
thing and the session is identified by another. If the two must have a 1-1
mapping in iSCSI, why are there two different identifiers? Why not just
use the current definition of the I_T nexus to uniquely identify both the
nexus and session (i.e. get rid of TSID)?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre
Asselin/Raleigh/IBM@IBMUS
10/31/2001 cc: ips@ece.cmu.edu
04:42 PM From: John Hufferd/San
Jose/IBM@IBMUS
Subject: Re: is TargetName
always mandatory or not?(Document link: Andre Asselin)
Andre,
I looked again through the document and No where could I find a statement
that you claimed as "a nexus, and therefore an iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and portal group tag". It is
the InitiatorName, ISID, TSID, with the TargetName and PortalGroup.
Please point out to me in the Spec (8 or above), where I can find your
statement on I_T Nexus.
I did find the following (please ignore for this conversation the "i" and
't" stuff):
"- Session: The group of TCP connections that link an initiator with a
target, form a session (loosely equivalent to a SCSI I-T nexus). TCP
connections can be added and removed from a session. Across all connections
within a session, an initiator sees one "target image". "
" - I_T nexus: According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The
I_T nexus can be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus
identifier is not equal to the session identifier (SSID). "
I have not found a place where Session ID is tied to the TSID.
Hence my comment that we also need to have the TargetName in the Initial
Login on all Connections.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
John & Julian,
How about this for the section 5 text:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The initial login
request
of the leading Login MAY also include the SessionType key=value pair, in
which case if the SessionType is not "discovery", then the initial login
request
MUST also include the key=value pair TargetName.
John,
I disagree with your second statement: I don't see any way you could
have 2 different sessions established within the same portal group with the
same InitiatorName, ISID, and TSID. The spec. says that a nexus, and
therefore an iSCSI session, is uniquely identified by the InitiatorName,
ISID, TSID, and portal group tag. There is no mention of TargetName
contributing to the identificaiton of a session. In my opinion, a
non-leading connection should NOT have the TargetName, since it doesn't
contribute anything.
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John
Hufferd/San To: Julian
Satran/Haifa/IBM@IBMIL
Jose/IBM@IBMUS cc: ips@ece.cmu.edu
Sent by: Subject: Re: is TargetName
always mandatory or not?
owner-ips@ece.
cmu.edu
10/31/2001
04:20 AM
Julian,
I think the TargetName should be included on the Initial Login Request on
the Leading Login. It seem strange to permit the Authentication functions
to proceed if perhaps the intended Target is different then the one doing
the Authentication. The way it currently is written, you could pass all
the Security test and then find out just before going into Full Function
Phase, that it was intended for some other Target. Seems like a waste.
My I think that TargetName should also be on all connections on the Initial
Login Request. Here is my thinking:
The SSID (ISID+TSID) is unique only with regards to a Specific Initiator
and Target Node Pair. It is therefore not clear that just knowing the SSID
and InitiatorName is enough to understand what session the subsequent
connections are being attached to. And it is possible that the CID could
be also overlapped with another session.
Therefore, I think it make since to determine all this on the initial Login
on every Connection, so you know at the beginning what values can be
negotiated, or that are being set to the right Session.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/30/2001 11:33:50 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: Re: is TargetName always mandatory or not?
It is the leading login:
The section 5 paragraph will read:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The leading Login
request MAY also include the SessionType key=value pair in which case if
the SessionType is not "discovery" then the leading Login Request MUST
also include the key=value pair TargetName.
Julo
Andre Asselin/Raleigh/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:08
Please respond to Andre Asselin
To: "IPS Reflector (E-mail)"
cc:
Subject: is TargetName always mandatory or not?
In section 5 of the spec, it says "If the SessionType is not
"discovery" then the initial Login Request MUST also include the key=value
pair TargetName.". However, in Appendix D, the description for TargetName
says it is Leading Only.
Should TargetName not be Leading Only, or should the text in section
5
say that TargetName must be in the initial Login Request of a leading
connection?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
From owner-ips@ece.cmu.edu Thu Nov 1 17:38:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02222
for ; Thu, 1 Nov 2001 17:38:08 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1LdLw25757
for ips-outgoing; Thu, 1 Nov 2001 16:39:21 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1LdIl25750
for ; Thu, 1 Nov 2001 16:39:18 -0500 (EST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA29668
for ; Thu, 1 Nov 2001 16:36:43 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA1LdBC155350
for ; Thu, 1 Nov 2001 14:39:11 -0700
X-Priority: 1 (High)
Importance: Normal
Subject: Re: is TargetName always mandatory or not?
To: "Andre Asselin"
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "John Hufferd"
Date: Thu, 1 Nov 2001 13:38:16 -0800
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
11/01/2001 02:39:11 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Andre,
I think Jim has just answered your question on the use of portal groups.
In any event the wordage you point out in 3.12.9 is a bit loose. When it
says: "The TSID is the target assigned tag ...." it is only implied that
the TSID is chosen in the context of the Target (iSCSI Target Node) and not
a iSCSI Network Entity. Therefore, the implication that the code would
only need the TSID + ISID + InitiatorName to bind a connection to a
Session, is only valid in the context of a Specific iSCSI Target Node. The
Fact that more then one iSCSI Target Node could be located in a iSCSI
Network Entity, means that the implementation needs more complete
information to direct the connection binding with the approprate Session
(and hence the approprate Target Node).
Depending on the implementation, it is probably possible to use the 64K
different possibilities to make the TSID unique across the entire iSCSI
Network Entity, but that is not a hard requirement of the protocol.
I do not mind having the TSID being left in, it can be most useful in many
(most) installations is sufficient as a unique qualifier with the ISID +
InitiatorName, but that is SIZE and implementation determined.
I think we need to update the wordage in 3.12.9 and other places to make
sure that everyone understands that TSID is only specified as being unique
in the setting of a specific iSCSI Node. And we need to update the Draft
to ensure that Both the InitiatorName and TargetName are always used on all
non Discovery Connection Logins, and always on the Initial Login request of
each connection.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin
11/01/2001 12:33 PM
To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not? (Document link: John
Hufferd)
John,
Section 3.12.9 of the spec reads:
The TSID is the target assigned tag for a session with a specific
named initiator that, together with the ISID uniquely identifies a
session with that initiator.
So according to that, TSID + ISID + InitiatorName must be enough
information for a target to uniquely idenfity a session, so mapping TSID to
target portal group ID won't always work (see my other note addressed to
Jim for an example of where it won't).
After thinking about this for a while, I've come to the same
conclusion as you (that a target should compare ISID + InitiatorName +
TargetName + target portal group to uniquely identify a session), but from
a different angle.
My reasoning: Since there is a 1-1 correspondence between an I_T
nexus and a session, if you can identify the nexus, you've identified the
session, and vice versa. Since 3.12.9 says that TSID + ISID +
InitiatorName must uniquely identify a session, then TSID must be an alias
for TargetName + target portal group ID, since (ISID + InitiatorName +
TargetName + portal group ID) uniquely identifies a nexus. In my opinion,
that aliasing only complicates (and confuses!) the protocol and should be
done away with. If TargetName were required on every initial login
request, then the target could compare (ISID + InitiatorName + TargetName +
portal group) to determine a session match, and forget about TSID entirely.
In that case, there is no need for TSID, except to flag whether the login
request is to create a new session or to add a new connection to an
existing session (i.e. indicate leading login), in which case it could be
dropped and replaced with a single bit.
To eliminate TSID, I believe the following changes would be needed:
- Eliminate TSID from login request and login response
- Use one of the bits in byte 1 of login request to indicate a leading
login, and update any text that refers to TSID=0 to refer to this bit
- Define session to be equivalent to I_T nexus (not "loosely equivalent
to")
- Define SSID/session ID to be the same as the I_T nexus identifier
- Remove the "LO" from TargetName
- If it hasn't already been done, remove the "LO" from InitiatorName
Comments?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre Asselin/Raleigh/IBM
10/31/2001 cc: ips@ece.cmu.edu
06:32 PM From: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
(Document link: Andre Asselin)
Andre,
TSID, and therefore SSID is a handle that can be use to queue stuff within
the scope of the Initiator Node and Target Node. The target can use what
ever it wants in this field. Some Folks might want to use the TSID to be
the Portal Group Tag and I think then it might be unique. But even then
only within the InitiatorName+ISID Space. Anyway, you need to think of it
only as a handle. Also since most folks will not have 64k Sessions into
their box, some (most?) implementations might find it unique. But it is
not unique in the Architecture.
Now the important thing is that, as things stand now, the Login needs the
InitiatorName, and the TargetName on the Initial Login of ALL Connections
in order to uniquely identify secondary Connections to the Original
Connection of the Session.
Does that seem correct to you and others on the Reflector?
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin
10/31/2001 03:00 PM
To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not? (Document link: John
Hufferd)
John,
WHOOPS! I was wrong; you are absolutely right that the spec says
"TargetName" and not "TSID". When I was reading through it, I saw
"TargetName", but read to myself "TSID". Apologies...
In my defense (confusion?), however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a session. Going by that, SSID +
InitiatorName must be enough to uniquely identify a session.
Jim Hafner pointed out to me that the I_T nexus is identified by one
thing and the session is identified by another. If the two must have a 1-1
mapping in iSCSI, why are there two different identifiers? Why not just
use the current definition of the I_T nexus to uniquely identify both the
nexus and session (i.e. get rid of TSID)?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre Asselin/Raleigh/IBM@IBMUS
10/31/2001 cc: ips@ece.cmu.edu
04:42 PM From: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
(Document link: Andre Asselin)
Andre,
I looked again through the document and No where could I find a statement
that you claimed as "a nexus, and therefore an iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and portal group tag". It is
the InitiatorName, ISID, TSID, with the TargetName and PortalGroup.
Please point out to me in the Spec (8 or above), where I can find your
statement on I_T Nexus.
I did find the following (please ignore for this conversation the "i" and
't" stuff):
"- Session: The group of TCP connections that link an initiator with a
target, form a session (loosely equivalent to a SCSI I-T nexus). TCP
connections can be added and removed from a session. Across all connections
within a session, an initiator sees one "target image". "
" - I_T nexus: According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The
I_T nexus can be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus
identifier is not equal to the session identifier (SSID). "
I have not found a place where Session ID is tied to the TSID.
Hence my comment that we also need to have the TargetName in the Initial
Login on all Connections.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
John & Julian,
How about this for the section 5 text:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The initial login
request
of the leading Login MAY also include the SessionType key=value pair, in
which case if the SessionType is not "discovery", then the initial login
request
MUST also include the key=value pair TargetName.
John,
I disagree with your second statement: I don't see any way you could
have 2 different sessions established within the same portal group with the
same InitiatorName, ISID, and TSID. The spec. says that a nexus, and
therefore an iSCSI session, is uniquely identified by the InitiatorName,
ISID, TSID, and portal group tag. There is no mention of TargetName
contributing to the identificaiton of a session. In my opinion, a
non-leading connection should NOT have the TargetName, since it doesn't
contribute anything.
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John
Hufferd/San To: Julian
Satran/Haifa/IBM@IBMIL
Jose/IBM@IBMUS cc: ips@ece.cmu.edu
Sent by: Subject: Re: is TargetName
always mandatory or not?
owner-ips@ece.
cmu.edu
10/31/2001
04:20 AM
Julian,
I think the TargetName should be included on the Initial Login Request on
the Leading Login. It seem strange to permit the Authentication functions
to proceed if perhaps the intended Target is different then the one doing
the Authentication. The way it currently is written, you could pass all
the Security test and then find out just before going into Full Function
Phase, that it was intended for some other Target. Seems like a waste.
My I think that TargetName should also be on all connections on the Initial
Login Request. Here is my thinking:
The SSID (ISID+TSID) is unique only with regards to a Specific Initiator
and Target Node Pair. It is therefore not clear that just knowing the SSID
and InitiatorName is enough to understand what session the subsequent
connections are being attached to. And it is possible that the CID could
be also overlapped with another session.
Therefore, I think it make since to determine all this on the initial Login
on every Connection, so you know at the beginning what values can be
negotiated, or that are being set to the right Session.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/30/2001 11:33:50 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: Re: is TargetName always mandatory or not?
It is the leading login:
The section 5 paragraph will read:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The leading Login
request MAY also include the SessionType key=value pair in which case if
the SessionType is not "discovery" then the leading Login Request MUST
also include the key=value pair TargetName.
Julo
Andre Asselin/Raleigh/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:08
Please respond to Andre Asselin
To: "IPS Reflector (E-mail)"
cc:
Subject: is TargetName always mandatory or not?
In section 5 of the spec, it says "If the SessionType is not
"discovery" then the initial Login Request MUST also include the key=value
pair TargetName.". However, in Appendix D, the description for TargetName
says it is Leading Only.
Should TargetName not be Leading Only, or should the text in section
5
say that TargetName must be in the initial Login Request of a leading
connection?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
From owner-ips@ece.cmu.edu Thu Nov 1 18:19:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02725
for ; Thu, 1 Nov 2001 18:19:31 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1MX0329928
for ips-outgoing; Thu, 1 Nov 2001 17:33:00 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from wellington.xo.com (wellington.xo.com [207.155.252.73])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1MWwl29923
for ; Thu, 1 Nov 2001 17:32:58 -0500 (EST)
Received: from blekinge ([66.89.96.162])
by wellington.xo.com
id RAA12331; Thu, 1 Nov 2001 17:32:21 -0500 (EST)
[ConcentricHost SMTP Relay 1.14]
Message-ID: <015f01c16324$f8725720$1001010a@blekinge>
From: "Peter Mellquist"
To: "Michele Hallak - Stamler"
Cc: "IPS"
References: <838D8D2617300146B7F47E4D9AE7FF10114A0E@SANSRV1.SAN-RAD.CO.IL>
Subject: Re: iSCSI: New iSCSI MIB draft
Date: Thu, 1 Nov 2001 14:31:35 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
I agree. I would assume that I can use SNMPv3 to manage the ACL in a secure
manner. This would require read/write access. Basically, it should be
possible to manage and control an iSCSI target or initiator via SNMP.
-peter
Peter Mellquist
Seven Systems Technology
peterm@seven-systems.com
----- Original Message -----
From: "Michele Hallak - Stamler"
To: "Mark Bakke" ; "IPS"
Sent: Wednesday, October 31, 2001 11:52 PM
Subject: RE: iSCSI: New iSCSI MIB draft
> Hi,
> 1.I see that the target access list is still read-only. How do you think
> that it should be configured?
> 2. Who should configure the aliases of the iscsi targets and initiators?
> 3. Same question for the portals.
> Thanks,
> Michele
>
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Wednesday, October 31, 2001 9:01 PM
> To: IPS
> Subject: Re: iSCSI: New iSCSI MIB draft
>
>
> For those who are more pictorially inclined when looking at
> MIBs, I have an updated MIB tree drawing available at:
>
> ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-03.pd
> f
>
> --
> Mark
>
> Mark Bakke wrote:
> >
> > We have submitted a new iSCSI MIB draft to the repository.
> > Until it becomes available, it may be retrieved as either
> > a gzipped or text version from:
> >
> > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt.gz
> >
> > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt
> >
> > A matching UML drawing is available at:
> >
> > ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-03.pdf
> >
> > The table hierarchy has been significantly flattened. This does
> > not change the object model, but does reduce the number of redundant
> > levels of OIDs when address individual objects. I will send a
> > new table structure drawing soon.
> >
> > We will send a list of open issues to the IPS list shortly.
> >
> > Thanks,
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>
From owner-ips@ece.cmu.edu Thu Nov 1 19:22:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03647
for ; Thu, 1 Nov 2001 19:22:32 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA1NVpc04193
for ips-outgoing; Thu, 1 Nov 2001 18:31:51 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA1NVnl04186
for ; Thu, 1 Nov 2001 18:31:49 -0500 (EST)
Received: from localhost (rdr@localhost)
by iol.unh.edu (8.9.3/8.9.3) with ESMTP id SAA15624
for ; Thu, 1 Nov 2001 18:31:48 -0500 (EST)
Date: Thu, 1 Nov 2001 18:31:48 -0500
From: "Robert D. Russell"
To: ips@ece.cmu.edu
Subject: Re: iSCSI: current UNH Plugfest
In-Reply-To:
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Attached are the new issues that arose during the iSCSI plugfest at
UNH on Thursday 1-Nov-2001.
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
----------------------------------------------------------------------
There were no new issues today! Lots of people were busy sending
data and interoperating with each other! There were, however, a
few suggestions/requests for clarifications in the standard:
1. Since all Login Requests MUST be issued as immediate requests,
the diagram in section 3.12 should show bit 6 of byte 0 as "1",
not "I", and section 3.12.2 should simply be eliminated.
2. The first paragraph of Appendix D should describe the special
role of the first Login request on the first connection of a new
session. In particular, there are 3 keys that MUST be sent in
that Login PDU (InitiatorName, SessionType if it is discovery,
TargetName if the session is normal). This is, in fact, yet
another classification that is currently included within LO, but
LO is too general, since LO allows keys to appear at any time
during the leading login phase, and these keys must appear on the
very first login PDU in that leading login phase.
3. A target cannot release its resources for a command until it
receives an ExpStatSN back from the initiator that acknowledges
receipt of the StatSN carried in the SCSI Response to that command.
However, if the initiator does not have any more I/O to perform,
that ExpStatSN will not come back to the target, and the target
may end up holding on to those resources indefinitely. This is a
situation where initiator non-action can impact target performance,
and could even lead to denial of service attacks if several
initiators were to do this simultaneously to the same target.
The standard provides the NOP-In/Out mechanism to deal with this:
The last paragraph of section 2.2.2 says:
During periods when traffic on a connection is unidirectional,
iSCSI NOP-Out/In PDUs may be utilized to synchronize the command
and status ordering counters of the target and initiator.
and section 3.18 says:
A NOP-Out may also be used to confirm a changed ExpStatSN if
there is no other PDU to carry it for a long time.
The question is, is there a recommended mechanism to trigger these
NOP-pings?
Clearly the target could set a timer, and if ExpStatSN is not
received back at the end of the time interval, the target could
send a NOP-in as a ping in order to get the initiator to send back
a NOP-out with the updated ExpStatSN.
Also clearly the initiator could set a timer, and if it has no
traffic to send during the time interval, the initiator could send
a NOP-out to deliver the updated ExpStatSN to the target.
This approach is probably not as reliable as the first, since
a) if the initiator does not do it, only the target gets hurt, and
b) if the connection drops, the target will never receive the NOP-out.
On the other hand, it may be more efficient for the initiator to do
this, since a typical target may be dealing with hundreds of
connections, and the initiator only a few.
Which is the best procedure? Are there other ways to do this?
What is the recommended way, or is there a reason for the standard
not to recommend a triggering mechanism, in which case, could
the standard suggest methods or provide guidance, especially if there
are better, less obvious ways to do it?
From owner-ips@ece.cmu.edu Thu Nov 1 21:24:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06668
for ; Thu, 1 Nov 2001 21:24:35 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA21JS112038
for ips-outgoing; Thu, 1 Nov 2001 20:19:28 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA21JRl12033
for ; Thu, 1 Nov 2001 20:19:27 -0500 (EST)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
by msgbas1.cos.agilent.com (Postfix) with ESMTP
id 214AF2F53; Thu, 1 Nov 2001 18:19:26 -0700 (MST)
Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144])
by msgrel1.cos.agilent.com (Postfix) with SMTP
id ED00225B; Thu, 1 Nov 2001 18:19:25 -0700 (MST)
Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 01 Nov 2001 18:19:25 -0700
Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 1 Nov 2001 18:19:25 -0700
Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF68D@axcs13.cos.agilent.com>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)"
To: "'Ofer Biran'" , ips@ece.cmu.edu
Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" ,
"SHEEHY,DAVE (A-Americas,unix1)"
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Date: Thu, 1 Nov 2001 18:19:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
It seems to me (who has not had the experience of implementing IpSec) that
tunnel mode, even when implemented in the end host (rather than in a
router), is a superset of transport mode whose only significant disadvantage
is that tunnel mode requires more overhead in the form of the extra IP
header. On the other hand, tunnel mode offers more flexibility in
implementation as it is easier to implement in BITS and BITW implementations
whereas transport mode can only be easily implemented when IPSec is
implemented as part of the network layer i.e. integrated into the OS. The
reason is that the IPSec headers are inserted AFTER the IP payload is
constructed. This means that IPSec has to duplicate IP functionality because
it has to recalculate the IP checksum and fragment the packet when
necessary.
I would support making tunnel mode the favored mode in iSCSI. IPSec
compliance requires that transport mode be implemented but if iSCSI
discourages it the implementation need not be as efficient as tunnel mode.
Vince
|-----Original Message-----
|From: Ofer Biran [mailto:BIRAN@il.ibm.com]
|Sent: Thursday, November 01, 2001 4:31 AM
|To: ips@ece.cmu.edu
|Subject: iSCSI: IPsec tunnel / transport mode decision
|
|
|I'd like to drive this open issue into group consensus. It seems to
|me that the tendency was more toward making tunnel mode a MUST as iFCP
|and FCIP did, mainly due the option of integrating an existing IPsec
|chip/box with the iSCSI implementation offering. If we reach
|this decision,
|we may choose even not to mention transport mode (as MAY or some other
|recommending text).
|
|There is an excellent analysis made by Bernard Aboba in Section
|"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
|( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
|that can help us with this decision (also Section "5.2. NAT
|traversal" is
|relevant).
|
| Regards,
| Ofer
|
|Ofer Biran
|Storage and Systems Technology
|IBM Research Lab in Haifa
|biran@il.ibm.com 972-4-8296253
|
From owner-ips@ece.cmu.edu Fri Nov 2 02:06:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22569
for ; Fri, 2 Nov 2001 02:06:40 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA26Hse01170
for ips-outgoing; Fri, 2 Nov 2001 01:17:54 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA26Hql01166
for ; Fri, 2 Nov 2001 01:17:52 -0500 (EST)
Received: from icarus.sanera.net (icarus [192.168.254.11])
by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fA26Hju05796;
Thu, 1 Nov 2001 22:17:45 -0800
Received: from strahmw2k (ras-pc-7-4.sanera.net [172.16.7.4])
by icarus.sanera.net (8.11.6/8.11.2) with SMTP id fA26Hc618038;
Thu, 1 Nov 2001 22:17:39 -0800
From: "Bill Strahm"
To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" ,
"'Ofer Biran'" ,
Cc: "SHEEHY,DAVE \(A-Americas,unix1\)"
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Date: Thu, 1 Nov 2001 22:17:32 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED920CF68D@axcs13.cos.agilent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Ok,
First off with complexity comes a configuration nightmare...
Second I can implement both a BITS and a BITW IPsec Transport and Tunnel
mode... it really isn't all that hard. BITS implies that you are making OS
changes, or at least changes under the TCP/UDP layer that is traditionally
exposed to user applications, so I think most of the argument you are trying
to make in your second paragraph doesn't hold much water for me. I would
rather use Tunnel mode myself, however my reasons are that I can completely
offload the implementation off of the host and target and let intermediate
devices deal with security policies and such things... However most of the
tone of the security draft is to require for at least one end if not both to
be intimately aware of what is going on with security...
Bill
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
CAVANNA,VICENTE V (A-Roseville,ex1)
Sent: Thursday, November 01, 2001 5:19 PM
To: 'Ofer Biran'; ips@ece.cmu.edu
Cc: CAVANNA,VICENTE V (A-Roseville,ex1); SHEEHY,DAVE (A-Americas,unix1)
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
It seems to me (who has not had the experience of implementing IpSec) that
tunnel mode, even when implemented in the end host (rather than in a
router), is a superset of transport mode whose only significant disadvantage
is that tunnel mode requires more overhead in the form of the extra IP
header. On the other hand, tunnel mode offers more flexibility in
implementation as it is easier to implement in BITS and BITW implementations
whereas transport mode can only be easily implemented when IPSec is
implemented as part of the network layer i.e. integrated into the OS. The
reason is that the IPSec headers are inserted AFTER the IP payload is
constructed. This means that IPSec has to duplicate IP functionality because
it has to recalculate the IP checksum and fragment the packet when
necessary.
I would support making tunnel mode the favored mode in iSCSI. IPSec
compliance requires that transport mode be implemented but if iSCSI
discourages it the implementation need not be as efficient as tunnel mode.
Vince
|-----Original Message-----
|From: Ofer Biran [mailto:BIRAN@il.ibm.com]
|Sent: Thursday, November 01, 2001 4:31 AM
|To: ips@ece.cmu.edu
|Subject: iSCSI: IPsec tunnel / transport mode decision
|
|
|I'd like to drive this open issue into group consensus. It seems to
|me that the tendency was more toward making tunnel mode a MUST as iFCP
|and FCIP did, mainly due the option of integrating an existing IPsec
|chip/box with the iSCSI implementation offering. If we reach
|this decision,
|we may choose even not to mention transport mode (as MAY or some other
|recommending text).
|
|There is an excellent analysis made by Bernard Aboba in Section
|"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
|( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
|that can help us with this decision (also Section "5.2. NAT
|traversal" is
|relevant).
|
| Regards,
| Ofer
|
|Ofer Biran
|Storage and Systems Technology
|IBM Research Lab in Haifa
|biran@il.ibm.com 972-4-8296253
|
From owner-ips@ece.cmu.edu Fri Nov 2 04:44:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28525
for ; Fri, 2 Nov 2001 04:44:45 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA28jsC09041
for ips-outgoing; Fri, 2 Nov 2001 03:45:54 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA28jrl09036
for ; Fri, 2 Nov 2001 03:45:53 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA37786
for ; Fri, 2 Nov 2001 09:45:46 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
by d12relay01.de.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA28jk567180
for ; Fri, 2 Nov 2001 09:45:46 +0100
To: ips@ece.cmu.edu
Importance: High
MIME-Version: 1.0
Subject: iSCSI-countdown
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
From: "Julian Satran"
Message-ID:
Date: Fri, 2 Nov 2001 10:45:44 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
02/11/2001 10:45:46,
Serialize complete at 02/11/2001 10:45:46
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Dear colleagues,
Since I will probably not be able to finish the editorial changes to the
draft untill the cutoff date for IETF I intend to send 09 in the current
format and merge with the editorial changes in the next version.
I started the "countdown" - you can see the 08-90 in both txt and
pdf-with-changebar format on my site:
http://www.haifa.il.ibm.com/satran/ips
Julo
From owner-ips@ece.cmu.edu Fri Nov 2 09:15:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05061
for ; Fri, 2 Nov 2001 09:15:06 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2CjrE04253
for ips-outgoing; Fri, 2 Nov 2001 07:45:53 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from exch-connector.netcomsystems.com (mushroom.netcomsystems.com [12.9.24.195])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2Cjol04249
for ; Fri, 2 Nov 2001 07:45:50 -0500 (EST)
Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2653.19)
id ; Fri, 2 Nov 2001 04:45:44 -0800
Message-ID: <9384475DFC05D2118F9C00805F6F263106DDB912@exchange1.netcomsystems.com>
From: "Cunningham, Howard"
To: "'Jim Hafner'" ,
Andre Asselin
Cc: ips@ece.cmu.edu
Subject: RE: is TargetName always mandatory or not?
Date: Fri, 2 Nov 2001 04:45:43 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C1639C.49086720"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1639C.49086720
Content-Type: text/plain;
charset="iso-8859-1"
Andre:
I apologize if I have missed something in this thread, but...
A non-zero TSID means either a connection re-start (X) bit or add a new
connection to an existing session. It seems to me ISID-TSID uniquely
determines the session, while a new CID (unique within the session only)
indicates a new connection.
In draft 8 section 3.12.9, it says:
3.12.9 TSID
The TSID is the target assigned tag for a session with a specific
named initiator that, together with the ISID uniquely identifies a
session with that initiator.
On a Login request a TSID value of 0 indicates a request to open a
new session.
A non zero TSID indicates a request to add a connection to an
existing session.
Regards...
-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Thursday, November 01, 2001 3:40 PM
To: Andre Asselin
Cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or not?
Andre,
Your picture isn't quite right. The portal group tag is relative to the
iSCSI target and that target is *uniquely* identified by it's name. So, in
your picture, there are two targets (not one). Each can label its target
portal group any way it wants (independent of the other). Each has
independent control over the TSIDs it uses. Each may *share* use of a
network portal, but that's a different issue. The model implies two
independent targets (even if they live in the same network entity and share
resources) in your scenario.
In other words, the portal groups are wrt targets not the network entity.
In your scenario, whatever layer (you put it in the network code) has to
decide what session to add the connection to has the initiator name, the
ISID, the TSID *and* the target name (you left this out) in the login
request. That fully qualifies both the target and the session as well.
Jim Hafner
Andre Asselin
11/01/2001 12:15 pm
To: Jim Hafner/Almaden/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not? (Document link:
Database 'Jim Hafner', View '($Inbox)')
Jim,
I agree with what you say, except for the part that mapping
TSID=target portal group tag will work.
Let's assume the following architecture: I have a network entity with one
network portal (and thus one portal group). Inside this entity lives two
iSCSI targets.
Scenerio: An iSCSI initiator opens a connection to the network portal in
order to add a connection to an already existing session (the network
entity's networking code knows this because TSID in the initial login
request is 0). The networking code needs to determine what session the
initiator wants to add to, so it compares some items from the initial login
request to each of the established sessions until it finds a match. The
question is what items should it compare to identify a match?
Section 3.12.9 of the spec reads:
The TSID is the target assigned tag for a session with a specific
named initiator that, together with the ISID uniquely identifies a
session with that initiator.
As you say, this is clearly target centric (because, for example, an
initiator could have 2 different sessions open to two different targets
that have the same TSID). But from a target point of view, what that text
means to me that the network entity's networking code should compare ISID +
InitiatorName + TSID to determine a match. That implies that TSID must be
unique per TargetName and per portal group ID. If TSID is just the target
portal group tag, then the comparison wouldn't work. For example, using
the architecture above where there is just one portal group, the target
could have two sessions open: session A (InitiatorName=foo, ISID=1,
TargetName=bar, TSID=0) and session B (InitiatorName=foo, ISID=1,
TargetName=foobar, TSID=0). If it receives a login request with
(InitiatorName=foo, ISID=1, TSID=0), which session is it for?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
Jim Hafner
To:
10/31/2001 cc:
06:33 PM From:
Subject: (Document link: Andre
Asselin)
Andre,
First, your comment "SSID + InitiatorName must be enough to uniquely
identify a session" is target-centric. It would be different from the
initiator's viewpoint. However, from the target's viewpoint, the target
name is implicit and from the initiator viewpoint, the initiator name is
implicit, so globally, the triple of the two names + SSID (made up of the
ISID and TSID) form the identifier of the session. Locally (between two
specific guys), the names are implicit so only the SSID is required. It's
all a matter of point of view!
As for the difference in identifiers, as I mentioned in the private note,
the session is an iSCSI construct and is identified by iSCSI things. The
nexus is a SCSI thing and is identified by SCSI constructs (based on how
we've mapped the iSCSI things to SCSI things).
However, you've brought to the fore again a related question: "what value
does the TSID provide to the protocol?"
I'm not going to answer that, but I will note that one target
implementation that (I think) works is that the TSID = target portal group
tag.
The other thing to ask is "what value is there in the nexus identifier?"
This is never really used in SCSI at all, so it's not a critical issue what
composes it. However, it is important (IMO) that the SCSI ports have names
and the logical derivative of that statement is that the nexus is
identified by the concatenation of the SCSI port names (hence the
definition we have).
Jim Hafner
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 03:00:53 pm
Sent by: owner-ips@ece.cmu.edu
To: John Hufferd/San Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or not?
John,
WHOOPS! I was wrong; you are absolutely right that the spec says
"TargetName" and not "TSID". When I was reading through it, I saw
"TargetName", but read to myself "TSID". Apologies...
In my defense (confusion?), however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a session. Going by that, SSID +
InitiatorName must be enough to uniquely identify a session.
Jim Hafner pointed out to me that the I_T nexus is identified by one
thing and the session is identified by another. If the two must have a 1-1
mapping in iSCSI, why are there two different identifiers? Why not just
use the current definition of the I_T nexus to uniquely identify both the
nexus and session (i.e. get rid of TSID)?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John Hufferd
To: Andre
Asselin/Raleigh/IBM@IBMUS
10/31/2001 cc: ips@ece.cmu.edu
04:42 PM From: John Hufferd/San
Jose/IBM@IBMUS
Subject: Re: is TargetName
always mandatory or not?(Document link: Andre Asselin)
Andre,
I looked again through the document and No where could I find a statement
that you claimed as "a nexus, and therefore an iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and portal group tag". It is
the InitiatorName, ISID, TSID, with the TargetName and PortalGroup.
Please point out to me in the Spec (8 or above), where I can find your
statement on I_T Nexus.
I did find the following (please ignore for this conversation the "i" and
't" stuff):
"- Session: The group of TCP connections that link an initiator with a
target, form a session (loosely equivalent to a SCSI I-T nexus). TCP
connections can be added and removed from a session. Across all connections
within a session, an initiator sees one "target image". "
" - I_T nexus: According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The
I_T nexus can be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus
identifier is not equal to the session identifier (SSID). "
I have not found a place where Session ID is tied to the TSID.
Hence my comment that we also need to have the TargetName in the Initial
Login on all Connections.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc: John Hufferd/San Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or not?
John & Julian,
How about this for the section 5 text:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The initial login
request
of the leading Login MAY also include the SessionType key=value pair, in
which case if the SessionType is not "discovery", then the initial login
request
MUST also include the key=value pair TargetName.
John,
I disagree with your second statement: I don't see any way you could
have 2 different sessions established within the same portal group with the
same InitiatorName, ISID, and TSID. The spec. says that a nexus, and
therefore an iSCSI session, is uniquely identified by the InitiatorName,
ISID, TSID, and portal group tag. There is no mention of TargetName
contributing to the identificaiton of a session. In my opinion, a
non-leading connection should NOT have the TargetName, since it doesn't
contribute anything.
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
John
Hufferd/San To: Julian
Satran/Haifa/IBM@IBMIL
Jose/IBM@IBMUS cc: ips@ece.cmu.edu
Sent by: Subject: Re: is TargetName
always mandatory or not?
owner-ips@ece.
cmu.edu
10/31/2001
04:20 AM
Julian,
I think the TargetName should be included on the Initial Login Request on
the Leading Login. It seem strange to permit the Authentication functions
to proceed if perhaps the intended Target is different then the one doing
the Authentication. The way it currently is written, you could pass all
the Security test and then find out just before going into Full Function
Phase, that it was intended for some other Target. Seems like a waste.
My I think that TargetName should also be on all connections on the Initial
Login Request. Here is my thinking:
The SSID (ISID+TSID) is unique only with regards to a Specific Initiator
and Target Node Pair. It is therefore not clear that just knowing the SSID
and InitiatorName is enough to understand what session the subsequent
connections are being attached to. And it is possible that the CID could
be also overlapped with another session.
Therefore, I think it make since to determine all this on the initial Login
on every Connection, so you know at the beginning what values can be
negotiated, or that are being set to the right Session.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/30/2001 11:33:50 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: Re: is TargetName always mandatory or not?
It is the leading login:
The section 5 paragraph will read:
The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The leading Login
request MAY also include the SessionType key=value pair in which case if
the SessionType is not "discovery" then the leading Login Request MUST
also include the key=value pair TargetName.
Julo
Andre Asselin/Raleigh/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:08
Please respond to Andre Asselin
To: "IPS Reflector (E-mail)"
cc:
Subject: is TargetName always mandatory or not?
In section 5 of the spec, it says "If the SessionType is not
"discovery" then the initial Login Request MUST also include the key=value
pair TargetName.". However, in Appendix D, the description for TargetName
says it is Leading Only.
Should TargetName not be Leading Only, or should the text in section
5
say that TargetName must be in the initial Login Request of a leading
connection?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
------_=_NextPart_001_01C1639C.49086720
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
RE: is TargetName always mandatory or not?
Andre:
I apologize if I have missed something in this =
thread, but...
A non-zero TSID means either a connection re-start =
(X) bit or add a new connection to an existing session. It seems to me =
ISID-TSID uniquely determines the session, while a new CID (unique =
within the session only) indicates a new connection.
In draft 8 section 3.12.9, it says:
3.12.9 =
TSID
=
The TSID =
is the target assigned tag for a session with a specific
named =
initiator that, together with the ISID uniquely identifies a
session =
with that initiator.
=
On a =
Login request a TSID value of 0 indicates a request to open a
new =
session.
=
A non =
zero TSID indicates a request to add a connection to an
existing =
session.
Regards...
-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com=
]
Sent: Thursday, November 01, 2001 3:40 PM
To: Andre Asselin
Cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or =
not?
Andre,
Your picture isn't quite right. The portal =
group tag is relative to the
iSCSI target and that target is *uniquely* =
identified by it's name. So, in
your picture, there are two targets (not one). =
Each can label its target
portal group any way it wants (independent of the =
other). Each has
independent control over the TSIDs it uses. =
Each may *share* use of a
network portal, but that's a different issue. =
The model implies two
independent targets (even if they live in the same =
network entity and share
resources) in your scenario.
In other words, the portal groups are wrt targets =
not the network entity.
In your scenario, whatever layer (you put it in the =
network code) has to
decide what session to add the connection to has the =
initiator name, the
ISID, the TSID *and* the target name (you left this =
out) in the login
request. That fully qualifies both the target =
and the session as well.
Jim Hafner
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; Andre =
Asselin  =
;  =
;
&nb=
sp; 11/01/2001 12:15 =
pm &nbs=
p;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
To: Jim Hafner/Almaden/IBM@IBMUS
cc: ips@ece.cmu.edu
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject: Re: is TargetName always mandatory or =
not? (Document link:
Database 'Jim =
Hafner', View '($Inbox)')
Jim,
I agree with what you say, =
except for the part that mapping
TSID=3Dtarget portal group tag will work.
Let's assume the following architecture: I have =
a network entity with one
network portal (and thus one portal group). =
Inside this entity lives two
iSCSI targets.
Scenerio: An iSCSI initiator opens a connection to =
the network portal in
order to add a connection to an already existing =
session (the network
entity's networking code knows this because TSID in =
the initial login
request is 0). The networking code needs to =
determine what session the
initiator wants to add to, so it compares some items =
from the initial login
request to each of the established sessions until it =
finds a match. The
question is what items should it compare to identify =
a match?
Section 3.12.9 of the spec reads:
The TSID =
is the target assigned tag for a session with a specific
named =
initiator that, together with the ISID uniquely identifies a
session =
with that initiator.
As you say, this is clearly target centric (because, =
for example, an
initiator could have 2 different sessions open to =
two different targets
that have the same TSID). But from a target =
point of view, what that text
means to me that the network entity's networking =
code should compare ISID +
InitiatorName + TSID to determine a match. =
That implies that TSID must be
unique per TargetName and per portal group ID. =
If TSID is just the target
portal group tag, then the comparison wouldn't =
work. For example, using
the architecture above where there is just one =
portal group, the target
could have two sessions open: session A =
(InitiatorName=3Dfoo, ISID=3D1,
TargetName=3Dbar, TSID=3D0) and session B =
(InitiatorName=3Dfoo, ISID=3D1,
TargetName=3Dfoobar, TSID=3D0). If it receives =
a login request with
(InitiatorName=3Dfoo, ISID=3D1, TSID=3D0), which =
session is it for?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; Jim =
Hafner =
=
=
=
=
=
=
=
&nb=
sp; &nb=
sp; &nb=
sp; =
To: &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; =
10/31/2001 =
cc: &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; 06:33 =
PM &nbs=
p; =
From: &=
nbsp; &=
nbsp; &=
nbsp; &=
nbsp; &=
nbsp; &=
nbsp; &=
nbsp;
&nb=
sp; &nb=
sp; &nb=
sp; Subject: =
(Document link: Andre =
Asselin) &nbs=
p; &nbs=
p; &nbs=
p; &nbs=
p;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
&nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp;
Andre,
First, your comment "SSID + InitiatorName must =
be enough to uniquely
identify a session" is target-centric. It =
would be different from the
initiator's viewpoint. However, from the =
target's viewpoint, the target
name is implicit and from the initiator viewpoint, =
the initiator name is
implicit, so globally, the triple of the two names + =
SSID (made up of the
ISID and TSID) form the identifier of the =
session. Locally (between two
specific guys), the names are implicit so only the =
SSID is required. It's
all a matter of point of view!
As for the difference in identifiers, as I mentioned =
in the private note,
the session is an iSCSI construct and is identified =
by iSCSI things. The
nexus is a SCSI thing and is identified by SCSI =
constructs (based on how
we've mapped the iSCSI things to SCSI =
things).
However, you've brought to the fore again a related =
question: "what value
does the TSID provide to the protocol?"
I'm not going to answer that, but I will note that =
one target
implementation that (I think) works is that the TSID =
=3D target portal group
tag.
The other thing to ask is "what value is there =
in the nexus identifier?"
This is never really used in SCSI at all, so it's =
not a critical issue what
composes it. However, it is important (IMO) =
that the SCSI ports have names
and the logical derivative of that statement is that =
the nexus is
identified by the concatenation of the SCSI port =
names (hence the
definition we have).
Jim Hafner
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on =
10/31/2001 03:00:53 pm
Sent by: owner-ips@ece.cmu.edu
To: John Hufferd/San =
Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject: Re: is TargetName always mandatory or =
not?
John,
WHOOPS! I was wrong; =
you are absolutely right that the spec says
"TargetName" and not =
"TSID". When I was reading through it, I saw
"TargetName", but read to myself =
"TSID". Apologies...
In my defense (confusion?), =
however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a =
session. Going by that, SSID +
InitiatorName must be enough to uniquely identify a =
session.
Jim Hafner pointed out to me =
that the I_T nexus is identified by one
thing and the session is identified by =
another. If the two must have a 1-1
mapping in iSCSI, why are there two different =
identifiers? Why not just
use the current definition of the I_T nexus to =
uniquely identify both the
nexus and session (i.e. get rid of TSID)?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
&nb=
sp; John Hufferd
&nb=
sp; &nb=
sp; &nb=
sp; To: =
Andre
Asselin/Raleigh/IBM@IBMUS
&nb=
sp; =
10/31/2001 =
cc: ips@ece.cmu.edu
&nb=
sp; 04:42 =
PM &nbs=
p; From: John Hufferd/San
Jose/IBM@IBMUS
&nb=
sp; &nb=
sp; &nb=
sp; Subject: Re: =
is TargetName
always mandatory or not?(Document link: Andre =
Asselin)
Andre,
I looked again through the document and No where =
could I find a statement
that you claimed as "a nexus, and therefore an =
iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and =
portal group tag". It is
the InitiatorName, ISID, TSID, with the TargetName =
and PortalGroup.
Please point out to me in the Spec (8 or above), =
where I can find your
statement on I_T Nexus.
I did find the following (please ignore for this =
conversation the "i" and
't" stuff):
"- Session: The group of TCP connections that =
link an initiator with a
target, form a session (loosely equivalent to a SCSI =
I-T nexus). TCP
connections can be added and removed from a session. =
Across all connections
within a session, an initiator sees one "target =
image". "
" - I_T nexus: According to [SAM2], the I_T =
nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For =
iSCSI, this relationship
is a session, defined as a relationship between an =
iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI =
Target's Portal Group. The
I_T nexus can be identified by the conjunction of =
the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI =
Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). =
NOTE: The I_T nexus
identifier is not equal to the session identifier =
(SSID). "
I have not found a place where Session ID is tied to =
the TSID.
Hence my comment that we also need to have the =
TargetName in the Initial
Login on all Connections.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, =
eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on =
10/31/2001 10:40:55 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc: John Hufferd/San =
Jose/IBM@IBMUS
Subject: Re: is TargetName always mandatory or =
not?
John & Julian,
How about this for the =
section 5 text:
The initial Login request of the first connection of =
a session (leading
login) MUST include the InitiatorName key=3Dvalue =
pair. The initial login
request
of the leading Login MAY also include the =
SessionType key=3Dvalue pair, in
which case if the SessionType is not =
"discovery", then the initial login
request
MUST also include the key=3Dvalue pair =
TargetName.
John,
I disagree with your second =
statement: I don't see any way you could
have 2 different sessions established within the =
same portal group with the
same InitiatorName, ISID, and TSID. The spec. =
says that a nexus, and
therefore an iSCSI session, is uniquely identified =
by the InitiatorName,
ISID, TSID, and portal group tag. There is no =
mention of TargetName
contributing to the identificaiton of a =
session. In my opinion, a
non-leading connection should NOT have the =
TargetName, since it doesn't
contribute anything.
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
&nb=
sp; John
&nb=
sp; =
Hufferd/San =
To: Julian
Satran/Haifa/IBM@IBMIL
&nb=
sp; =
Jose/IBM@IBMUS =
cc: ips@ece.cmu.edu
&nb=
sp; Sent =
by: &nb=
sp; Subject: Re: is TargetName
always mandatory or not?
&nb=
sp; =
owner-ips@ece.
&nb=
sp; cmu.edu
&nb=
sp; 10/31/2001
&nb=
sp; 04:20 AM
Julian,
I think the TargetName should be included on the =
Initial Login Request on
the Leading Login. It seem strange to permit =
the Authentication functions
to proceed if perhaps the intended Target is =
different then the one doing
the Authentication. The way it currently is =
written, you could pass all
the Security test and then find out just before =
going into Full Function
Phase, that it was intended for some other =
Target. Seems like a waste.
My I think that TargetName should also be on all =
connections on the Initial
Login Request. Here is my thinking:
The SSID (ISID+TSID) is unique only with regards to a =
Specific Initiator
and Target Node Pair. It is therefore not =
clear that just knowing the SSID
and InitiatorName is enough to understand what =
session the subsequent
connections are being attached to. And it is =
possible that the CID could
be also overlapped with another session.
Therefore, I think it make since to determine all =
this on the initial Login
on every Connection, so you know at the beginning =
what values can be
negotiated, or that are being set to the right =
Session.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, =
eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on =
10/30/2001 11:33:50 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: Re: is TargetName always mandatory or =
not?
It is the leading login:
The section 5 paragraph will read:
The initial Login request of the first connection of =
a session (leading
login) MUST include the InitiatorName key=3Dvalue =
pair. The leading Login
request MAY also include the SessionType key=3Dvalue =
pair in which case if
the SessionType is not "discovery" then =
the leading Login Request MUST
also include the key=3Dvalue pair TargetName.
Julo
Andre Asselin/Raleigh/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
31-10-01 02:08
Please respond to Andre Asselin
=
To: "IPS Reflector (E-mail)" =
<ips@ece.cmu.edu>
=
cc:
=
Subject: is TargetName always =
mandatory or not?
In section 5 of the spec, it =
says "If the SessionType is not
"discovery" then the initial Login Request =
MUST also include the key=3Dvalue
pair TargetName.". However, in Appendix =
D, the description for TargetName
says it is Leading Only.
Should TargetName not be =
Leading Only, or should the text in section
5
say that TargetName must be in the initial Login =
Request of a leading
connection?
Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC
------_=_NextPart_001_01C1639C.49086720--
From owner-ips@ece.cmu.edu Fri Nov 2 10:27:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07773
for ; Fri, 2 Nov 2001 10:27:28 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2E82Y09326
for ips-outgoing; Fri, 2 Nov 2001 09:08:02 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mayfair.vxindia.veritas.com (bay-bridge.veritas.com [143.127.3.10])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2E7wl09318
for ; Fri, 2 Nov 2001 09:07:59 -0500 (EST)
Received: from RAHULB (rahulb.vxindia.veritas.com [10.212.80.59])
by mayfair.vxindia.veritas.com (8.9.3/8.9.3) with SMTP id TAA17208
for ; Fri, 2 Nov 2001 19:37:48 +0530 (IST)
Message-ID: <018501c163a7$d70371e0$3b50d40a@vxindia.veritas.com>
From: "Rahul Bhagwat"
To:
Subject: Data re-read from Device Server
Date: Fri, 2 Nov 2001 19:38:22 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0182_01C163D5.EE5CFD60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0182_01C163D5.EE5CFD60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
Section 8 mentions "It is also assumed that at target, incoming data =
(read data)
MAY be kept for recovery or it can be re-read from a device server."
Is it assumed here that the data from the device server is idempotent =
i.e will not
change when tried to re-read. If that is not the case and we have more =
than one
Data In PDU being sent in the response (for one of which a =
retransmission is=20
requested), it will result in in-correct view of the data being given to =
the initiator.
As an example, consider that the following response needs to be given
------------------
| 1 | 2 | 3 | 4 |
-----------------
which gets transmitted in two Data In PDUs like this
-------- ---------
| 1 | 2 | | 3 | 4 |
-------- ---------
Now if a re-read generates
------------------
| 1 | 3 | 4 | 5 |
------------------
and retransmission is requested for 2nd PDU. It will get transmitted =
like=20
--------
| 4 | 5 |
--------
which means the initiator neither got 1,2,3,4 nor got 1,3,4,5 (both of =
which are
valid snapshots at some point in time), instead it got 1,2,4,5 which =
never existed
at the target.
If we try to re-read only data pertaining to retransmitting PDU, the =
problem persists.
Regards,
Rahul
------=_NextPart_000_0182_01C163D5.EE5CFD60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
Section 8 mentions "It is also assumed =
that at=20
target, incoming data (read data)
MAY be kept for recovery or it can be =
re-read from=20
a device server."
Is it assumed here that the data from =
the device=20
server is idempotent i.e will not
change when tried to re-read. If that =
is not the=20
case and we have more than one
Data In PDU being sent in the response =
(for one of=20
which a retransmission is
requested), it will result in =
in-correct view of=20
the data being given to the initiator.
As an example, consider that the =
following response=20
needs to be given
------------------
| 1 | 2 | 3 | 4 |
-----------------
which gets transmitted in two Data In =
PDUs like=20
this
=20
--------  =
; =20
---------
| 1 | 2=20
| =
| =20
3 | 4 |
=20
--------  =
; =20
---------
Now if a re-read generates
------------------
| 1 | 3 | 4 | 5 =
|
------------------
and retransmission is requested for 2nd PDU. It will get =
transmitted like=20
--------
| 4 | 5 |
--------
which means the initiator neither got 1,2,3,4 nor got 1,3,4,5 (both =
of=20
which are
valid snapshots at some point in time), instead it got 1,2,4,5 =
which never=20
existed
at the target.
If we try to re-read only data pertaining to retransmitting PDU, =
the=20
problem persists.
Regards,
Rahul
------=_NextPart_000_0182_01C163D5.EE5CFD60--
From owner-ips@ece.cmu.edu Fri Nov 2 11:01:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08759
for
; Fri, 2 Nov 2001 11:01:53 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2FNNA14808
for ips-outgoing; Fri, 2 Nov 2001 10:23:23 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fA2FNLl14800
for ; Fri, 2 Nov 2001 10:23:21 -0500 (EST)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Nov 2 10:22:38 EST 2001
Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10])
by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fA2FLuR30835
for ; Fri, 2 Nov 2001 10:21:56 -0500 (EST)
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA07972
for ; Fri, 2 Nov 2001 10:21:56 -0500 (EST)
Message-ID: <3BE2BA13.63F2B387@research.bell-labs.com>
Date: Fri, 02 Nov 2001 10:21:55 -0500
From: Sandeep Joshi
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: Data re-read from Device Server
References: <018501c163a7$d70371e0$3b50d40a@vxindia.veritas.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
I believe the implicit assumption is that the ULP is holding
the right locks. Since retransmission has been requested, the
particular command has not yet completed at the initiator.
That, in turn, implies that the ULP is still waiting for the
data and has not yet released its relevant locks.
-Sandeep
> Rahul Bhagwat wrote:
>
>
> Hi,
>
> Section 8 mentions "It is also assumed that at target, incoming data
> (read data)
> MAY be kept for recovery or it can be re-read from a device server."
>
> Is it assumed here that the data from the device server is idempotent
> i.e will not
> change when tried to re-read. If that is not the case and we have more
> than one
> Data In PDU being sent in the response (for one of which a
> retransmission is
> requested), it will result in in-correct view of the data being given
> to the initiator.
>
> As an example, consider that the following response needs to be given
>
> ------------------
> | 1 | 2 | 3 | 4 |
> -----------------
>
> which gets transmitted in two Data In PDUs like this
>
> -------- ---------
> | 1 | 2 | | 3 | 4 |
> -------- ---------
>
> Now if a re-read generates
>
> ------------------
> | 1 | 3 | 4 | 5 |
> ------------------
>
> and retransmission is requested for 2nd PDU. It will get transmitted
> like
>
> --------
> | 4 | 5 |
> --------
>
> which means the initiator neither got 1,2,3,4 nor got 1,3,4,5 (both of
> which are
> valid snapshots at some point in time), instead it got 1,2,4,5 which
> never existed
> at the target.
>
> If we try to re-read only data pertaining to retransmitting PDU, the
> problem persists.
>
> Regards,
> Rahul
From owner-ips@ece.cmu.edu Fri Nov 2 11:04:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08824
for ; Fri, 2 Nov 2001 11:04:04 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2Ewlf12889
for ips-outgoing; Fri, 2 Nov 2001 09:58:47 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from best.eurologic.com ([193.120.246.5])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2Ewel12876
for ; Fri, 2 Nov 2001 09:58:41 -0500 (EST)
Received: from COORS (coors.eurologic.com [192.168.7.111])
by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id OAA17677;
Fri, 2 Nov 2001 14:55:05 GMT
Message-ID: <001901c163ae$f30a6a90$6f07a8c0@COORS>
From: "Ron Cohen"
To: "ips" , "Paul Koning"
References: <000101c162d7$330d39c0$0102a8c0@eddylaptop> <15329.38576.650000.176588@gargle.gargle.HOWL>
Subject: Re: iSCSI: current UNH Plugfest: Reserved bits
Date: Fri, 2 Nov 2001 14:59:18 -0000
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
The problem with accepting values in reserved bits is that when the reserved
bit is no longer reserved (evolution in the standard) it gives the
impression to the initiator that a target implements the new feature when it
may actually only be ignoring it.
Ron
----- Original Message -----
From: "Paul Koning"
To:
Cc: ;
Sent: Thursday, November 01, 2001 6:38 PM
Subject: RE: iSCSI: current UNH Plugfest
> Excerpt of message (sent 1 November 2001) by Bill Strahm:
> > Usually the "Conservative in what you send, Liberal in what you accept"
> > policy is used...
>
> That's a very important principle...
>
> > In otherwords, The sender MUST set to 0 (or some other value) The
receiver
> > MUST ignore the value...
>
> That's the way to express the principle. But the text quoted in the
> earlier notes does not express it the same way.
>
> In particular "... are format errors. This when detected..." implies
> that receivers may or may not detect format errors. In other words,
> it implies -- but does NOT state explicitly -- that receivers MAY
> check reserved fields for zeroness.
>
> > This allows for some tweaking of the implementation, if I control both
ends
> > I might set a reserved value to 1, then I know something... If I receive
a
> > reserve value set to 1 and I don't do anything the other end knows it is
not
> > talking to itself (this can even be a versioning thing as well)
> >
> > Now, we need to be VERY careful in defining this, do we plan on having
> > Protocol V1 endpoints talk to Protocol V2 endpoints, what does that
mean...
> > is it possible, is it desirable ? will there be extensions ???
> >
> > If you can truly answer NO to all of those things, I would argue for
> > REMOVING the reserved fields (if possible), if not, the MUST set, MUST
> > ignore policy seems better
>
> I agree strongly. There is a lot of experience in the community on
> what helps and what hurts convenient version upgrade. In particular,
> there is a LOT of evidence that ANY checking of reserved fields is a
> nasty thing. Unless you plan never to go beyond V1, you really need
> to require the rule Bill stated, i.e., receivers MUST ignore the
> contents of reserved fields -- they are NOT allowed to "verify" them.
>
> So the spec needs to be clarified to say that random values in
> reserved fields are NOT format errors and receivers MUST NOT treat
> them as such.
>
> paul
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Eddy Quicksall
> > Sent: Thursday, November 01, 2001 5:15 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI: current UNH Plugfest
> >
> >
> > I am reluctant to say this because I think most people think the
> > initiator/target must check for correctness ... but, it is my feeling
that
> > that job should be up to a basher program. The target should not be in
the
> > business of diagnosing the initiator. The only time a target should
check a
> > field is when it could crash the system or data. Some format errors may
have
> > no consequences whatsoever.
> >
> > Eddy
> >
> >
> > -----Original Message-----
> > From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
> > Sent: Wednesday, October 31, 2001 05:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: current UNH Plugfest
> >
> >
> > Attached are the new issues that arose during the iSCSI plugfest
> > at UNH on Wednesday 31-Oct-2001.
> >
> > (Note: these issues do not take into account any modifications or
> > clarifications that occured in the standard due to the issues raised
> > on Monday or Tuesday.)
> >
> > Bob Russell
> > InterOperability Lab
> > University of New Hampshire
> > rdr@iol.unh.edu
> > 603-862-3774
> >
> > ------------------------------------------------------------------------
> > ----
> >
> > 1. Are receivers (initiator or target) REQUIRED to check that reserved
> > bits and/or fields are set to 0?
> >
> > Section 3 on page 48 of draft 8 says:
> > "Any bits not defined MUST be set to zero. Any reserved fields and
> > values MUST be 0 unless specified otherwise."
> >
> > and Section 8.3 on page 127 of draft 8 says:
> > "Explicit violations of the PDU layout rules stated in this
> > document
> > are format errors. This when detected, usually indicates a major
> > implementation flaw in one of the parties.
> >
> > When a target or an initiator receives an iSCSI PDU with a format
> > error, it MUST reset all transport connections in the session
> > immediately and escalate the format error to session recovery
> > (section 8.11.4)."
> >
> > According to these rules, a PDU with reserved bits and/or fields that
> > are not set to 0 violates the PDU layout rules. Therefore, if an
> > initiator or target receives such a PDU, it should immediately close
> > all connections in the session and go to session recovery.
> >
> > Clearly a format error has extremely severe consequences!
> >
> > Although all vendors are setting reserved bits and fields to 0 on
> > PDUs they are sending, many are NOT checking PDUs they are receiving
> > to see if these bits and fields are set to 0. Basically, vendors are
> > saying "who cares if reserved bits and/or fields in incoming PDUs are
> > not zero? We do not want to take the time to do this checking, and
> > there is no benefit to doing it. As long as the non-reserved bits
> > and
> > fields are set properly, we can and should proceed. Any time devoted
> > to doing this checking is wasted in 99+% of the cases, and in the
> > (unlikely) case that a non-zero bit or field is found, the
> > consequences are too severe."
> >
> > There should be some statement in the standard to clarify what
> > checking
> > is required and what is optional.
> >
> > 2. A similar situation arises with respect to checking the consistency
> > of fields such as Version-max, Version-min and Version-active in
> > Login
> > Requests and Login Responses.
> >
> > For example, consider the Version-max field.
> >
> > Section 3.12.5 says:
> > "All Login requests within the Login phase MUST carry the same
> > Version-max."
> >
> > All vendor initiators are setting Version-max correctly on all
> > login requests they are sending, but many vendor targets are NOT
> > checking received login requests to ensure that this rule is
> > enforced.
> > In particular, many targets simply use the Version-max and
> > Version-min
> > on the first login request they receive on a new connection, and then
> > they ignore these fields on all subsequent login requests in the same
> > login phase.
> >
> > Strictly speaking, a change in the Version-max field during the login
> > phase constitutes a protocol error according to section 8.8 on page
> > 130
> > of draft 8:
> >
> > "All violations of iSCSI PDU exchange sequences specified in this
> > draft are also protocol errors. This category of errors can be
> > addressed only by fixing the implementations; iSCSI defines Reject
> > and response codes to enable this".
> >
> > Therefore the target should send back a login response with a status
> > of 0x0200 and then close the connection.
> >
> > However, Section 3.12.5 also says:
> > "The target MUST use the value presented with the first login
> > request."
> >
> > This rule seems to imply that the value CAN change, because if it
> > cannot
> > change, then it doesn't matter which one of the login requests it is
> > taken from, they are all the same anyway.
> >
> > The suggestion is to keep the requirement that the target MUST use
> > the
> > value presented on the first login request, but to allowed the target
> > to ignore the value presented on all subsequent login requests in the
> > same login phase. A similar rewording should be done for the other
> > fields.
> >
> > 3. Can commands be sent out of order on the same connection?
> >
> > The behavior of targets is clearly specified in Section 2.2.2.3 on
> > page 25 of draft 8, which says:
> > "Except for the commands marked for immediate delivery the iSCSI
> > target layer MUST eliver the commands for execution in the order
> > specified by CmdSN."
> >
> > Section 2.2.2.3 on page 26 of draft 8 also says:
> > "- CmdSN - the current command Sequence Number advanced by 1 on
> > each command shipped except for commands marked for immediate
> > delivery."
> > but the meaning of the term "shipped" is vague, and does not
> > necessarily
> > require that the PDUs arrive on the other end of a TCP connection
> > in the same order that the CmdSN values were assigned to these PDUs.
> >
> > Some initiators have been designed to send commands out of CmdSN
> > order on one connection. Consider the situation where there is only
> > one connection and a high-level dispatcher creates a PDU for a SCSI
> > command that involves writing immediate data to the target. This PDU
> > is enqueued to a lower-level layer which has to setup, start, and
> > wait-for a DMA operation to move the immediate data into an onboard
> > buffer before the PDU can be put onto the wire. While this is
> > happening, the dispatcher creates another unrelated PDU for a SCSI
> > read command (for example), and when this PDU is passed to the
> > lower-level layer it can be sent immediately, ahead of the previous
> > write PDU and therefore out of order on this connection.
> >
> > The standard clearly allows this to happen if the two PDUs were sent
> > on different connections, and seems to imply that this can also
> > happen
> > when the two PDUs are sent on the same connection.
> >
> > The suggestion is to put in the standard an explicit statement that
> > this is allowed or not allowed, as appropriate.
> >
> > If this is allowed, such a statement would avoid the erroneous
> > assumption being made by some target implementers that within a
> > single
> > connection, commands will arrive in order.
> >
> > If this is not allowed, such a statement would avoid the erroneous
> > assumption being made by some initiator implementers that within a
> > single connection, commands can be put on the wire out of order.
> >
> > 4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
> > now allow: "A value of 0 indicates no limit."
> >
> > Is this useful? Does it buy anything?
> >
> > The difficulties implementers are having with this are:
> >
> > 1) It is a special case.
> > 2) It causes discontinuous ranges (for example, [0,64..2**24])
> > 3) It violates the min/max function normally used for the key.
> > 4) There is always a limit anyway.
> >
> > Consider FirstBurstSize, which can have a value that is described
> > as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
> > is selected.
> >
> > I one side offers 0 to mean unlimited, and the other side
> > has a limit, it will reply with that limit, say 128 Kbytes.
> > Therefore, the result is not min(0, 128K) but rather max(0, 128K).
> > The statement in the standard that "the minimum of the 2 numbers is
> > selected" is therefore wrong when one of the numbers is 0.
> >
> > Furthermore, when an initiator or target receives an offer for one
> > of these keys, it cannot simply check that the offered value is
> > legal by testing it against some minimum and maximum. It must first
> > check for 0 and then only if that check shows the value is non-zero
> > can it do the min/max range check for legality (i.e., 64-2**24).
> >
> > Finally, there is always a limit. If nothing else it is the
> > limit imposed by the 24-bit DataSegmentLength field of the PDU
> > requesting the transfer. It is useless to specify a FirstBurstSize
> > (or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
> > the largest possible DataSegmentLength in any PDU that can use
> > this value is 2**24-1.
> >
> > The suggestion is to just eliminate this special case of 0 and
> > require
> > that the range 64-to-(2**24-1) be used instead -- it has exactly the
> > same effect in all cases, it is easier to describe in the standard
> > because it avoids all the extra words, and it is easier to code
> > because it avoids all the special cases.
> >
> > NOTE: the standard should specify the limit in the ranges for
> > MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
> > of 2**24. The number 2**24 cannot be represented in the 24-bit
> > DataSegmentLength field and therefore can never be used.
> >
> > 5. This is a suggestion for a minor rewording in the standard to avoid
> > misunderstandings.
> >
> > In Appendix E on page 188 of draft 8 it says:
> >
> > "The response to this command is a text response containing a list
> > of
> > targets and their addresses. Each target is returned as a target
> > record. A target record begins with the TargetName text key,
> > followed by a list of TargetAddress text keys, ..."
> >
> > In fact, there are situations where there are no targets and/or no
> > addresses. These situations are clearly defined in the draft after
> > the sentences quoted above, but it would help if those sentences
> > at least hinted at the possibility that the lists could be empty
> > or might not contain addresses. A possible rewording would be:
> >
> > "The response to this command is a text response containing a list
> > of
> > zero or more targets and, optionally, their addresses. Each target
> > is returned as a target record. A target record begins with the
> > TargetName text key, followed by a list of zero or more
> > TargetAddress text keys, ..."
> >
> >
> > 6. This is a suggestion for another very minor rewording in the
> > standard.
> >
> > At the end of section 2.2.3 on page 29 of draft 8 it says:
> >
> > "Before full feature phase is established, only Login PDUs are
> > allowed. ..."
> >
> > The suggested rewording is:
> >
> > "Before full feature phase is established, only Login Request and
> > Login Response PDUs are allowed. ..."
>
>
From owner-ips@ece.cmu.edu Fri Nov 2 11:58:01 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11473
for ; Fri, 2 Nov 2001 11:58:01 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2G4Dn18160
for ips-outgoing; Fri, 2 Nov 2001 11:04:13 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2G4Cl18154
for ; Fri, 2 Nov 2001 11:04:12 -0500 (EST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA46222
for ; Fri, 2 Nov 2001 11:01:35 -0500
Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41])
by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA2G44j124592
for ; Fri, 2 Nov 2001 09:04:04 -0700
Importance: Normal
Subject: RE: is TargetName always mandatory or not?
To: ips@ece.cmu.edu
From: "Jim Hafner"
Date: Fri, 2 Nov 2001 08:04:03 -0800
Message-ID:
X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at
11/02/2001 08:04:04 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Folks,
I think this thread may be exposing either an ambiguity in the draft or
perhaps a gap.
I think it's possible to interpret the requirement that TargetName be
supplied (for normal sessions) only on the *first login message on the
first connection of a new session* and is not required on the *first login
message of subsequent connections intended for the same session". My
personal interpretation is that the TargetName is required on the *first
login message on every connection (in all cases, new session or adding
connections to existing sessions)*. I also think Andre's example of a
network entity containing many iSCSI targets with shared network portals
(and the scoping of portal group tags and TSIDs by iSCSI target) points out
the need for the more restrictive requirement (and the rest of my response
to Andre assumed this).
But I've heard other comments that can be interpreted as the less
restrictive requirement is what is intended.
So, I suggest (and I don't think this is asking much) that the requirement
be that TargetName be supplied on the first Login message of every
connection (not just the leading one).
Jim Hafner
From owner-ips@ece.cmu.edu Fri Nov 2 13:09:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13756
for ; Fri, 2 Nov 2001 13:09:45 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2HSlR24652
for ips-outgoing; Fri, 2 Nov 2001 12:28:47 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2HSkl24647
for ; Fri, 2 Nov 2001 12:28:46 -0500 (EST)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
by msgbas1.cos.agilent.com (Postfix) with ESMTP
id 7B3E31969; Fri, 2 Nov 2001 10:28:45 -0700 (MST)
Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145])
by msgrel1.cos.agilent.com (Postfix) with SMTP
id 2C44465C; Fri, 2 Nov 2001 10:28:45 -0700 (MST)
Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 02 Nov 2001 10:28:44 -0700
Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19)
id ; Fri, 2 Nov 2001 10:28:44 -0700
Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF692@axcs13.cos.agilent.com>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)"
To: "'Bill Strahm'"
Cc: "SHEEHY,DAVE (A-Americas,unix1)" ,
"CAVANNA,VICENTE V (A-Roseville,ex1)" ,
"'Ofer Biran'" , ips@ece.cmu.edu
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Date: Fri, 2 Nov 2001 10:28:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Good Morning Bill,
To me, a BITS implementation of IPSec does not require changes to the OS
(with its built-in network stack) and is in fact useful when such changes
are not feasible. In BITS, I assume IPSec is implemented as a shim between
the network and data link layer. I thought, from reading the literature,
that this was a conventional definition of BITS.
If you are allowed to make changes to the network stack when adding IPSec
functionality then, as I noted in my original memo, I consider transport
mode to be feasible .
If I understand you correctly then, what you really favor is a BITW
implementation which I understand to be essentially an external crypto
device. I would like to be able to use that too, but only provisionally, as
a BITW implementation will eventually (as iSCSI matures) be considered too
expensive and IPSec will have to be incorporated more tightly into the
network stack.
Vince
-----Original Message-----
From: Bill Strahm [mailto:bill@Sanera.net]
Sent: Thursday, November 01, 2001 10:18 PM
To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Ofer Biran'; ips@ece.cmu.edu
Cc: SHEEHY,DAVE (A-Americas,unix1)
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Ok,
First off with complexity comes a configuration nightmare...
Second I can implement both a BITS and a BITW IPsec Transport and Tunnel
mode... it really isn't all that hard. BITS implies that you are making OS
changes, or at least changes under the TCP/UDP layer that is traditionally
exposed to user applications, so I think most of the argument you are trying
to make in your second paragraph doesn't hold much water for me. I would
rather use Tunnel mode myself, however my reasons are that I can completely
offload the implementation off of the host and target and let intermediate
devices deal with security policies and such things... However most of the
tone of the security draft is to require for at least one end if not both to
be intimately aware of what is going on with security...
Bill
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
CAVANNA,VICENTE V (A-Roseville,ex1)
Sent: Thursday, November 01, 2001 5:19 PM
To: 'Ofer Biran'; ips@ece.cmu.edu
Cc: CAVANNA,VICENTE V (A-Roseville,ex1); SHEEHY,DAVE (A-Americas,unix1)
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
It seems to me (who has not had the experience of implementing IpSec) that
tunnel mode, even when implemented in the end host (rather than in a
router), is a superset of transport mode whose only significant disadvantage
is that tunnel mode requires more overhead in the form of the extra IP
header. On the other hand, tunnel mode offers more flexibility in
implementation as it is easier to implement in BITS and BITW implementations
whereas transport mode can only be easily implemented when IPSec is
implemented as part of the network layer i.e. integrated into the OS. The
reason is that the IPSec headers are inserted AFTER the IP payload is
constructed. This means that IPSec has to duplicate IP functionality because
it has to recalculate the IP checksum and fragment the packet when
necessary.
I would support making tunnel mode the favored mode in iSCSI. IPSec
compliance requires that transport mode be implemented but if iSCSI
discourages it the implementation need not be as efficient as tunnel mode.
Vince
|-----Original Message-----
|From: Ofer Biran [mailto:BIRAN@il.ibm.com]
|Sent: Thursday, November 01, 2001 4:31 AM
|To: ips@ece.cmu.edu
|Subject: iSCSI: IPsec tunnel / transport mode decision
|
|
|I'd like to drive this open issue into group consensus. It seems to
|me that the tendency was more toward making tunnel mode a MUST as iFCP
|and FCIP did, mainly due the option of integrating an existing IPsec
|chip/box with the iSCSI implementation offering. If we reach
|this decision,
|we may choose even not to mention transport mode (as MAY or some other
|recommending text).
|
|There is an excellent analysis made by Bernard Aboba in Section
|"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
|( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
|that can help us with this decision (also Section "5.2. NAT
|traversal" is
|relevant).
|
| Regards,
| Ofer
|
|Ofer Biran
|Storage and Systems Technology
|IBM Research Lab in Haifa
|biran@il.ibm.com 972-4-8296253
|
From owner-ips@ece.cmu.edu Fri Nov 2 13:13:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13907
for ; Fri, 2 Nov 2001 13:13:07 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2HlJR26004
for ips-outgoing; Fri, 2 Nov 2001 12:47:19 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2HlGl25998
for ; Fri, 2 Nov 2001 12:47:16 -0500 (EST)
Received: from icarus.sanera.net (icarus [192.168.254.11])
by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fA2HlAu08377;
Fri, 2 Nov 2001 09:47:10 -0800
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
by icarus.sanera.net (8.11.6/8.11.2) with SMTP id fA2Hl5625494;
Fri, 2 Nov 2001 09:47:05 -0800
From: "Bill Strahm"
To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)"
Cc: "SHEEHY,DAVE \(A-Americas,unix1\)" ,
"'Ofer Biran'" ,
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Date: Fri, 2 Nov 2001 09:46:55 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED920CF692@axcs13.cos.agilent.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Ok,
I have implemented IPsec (both Transport & Tunnel) as a Win32 Intermediate
Driver for Win 9x/NT 4 (We didn't need it in W2K because it is implemented
there all ready). I have also implemented it as a set of Linux Netfilter
rules for the 2.4 kernel... I would consider both of these BITS
implementations and I consider these as OS modifications (all though
depending on if you consider the drivers as a part of the OS they may not
be)
There are a few optimizations that you can make if you actually own the TCP
stack.
1) Setting the MTU for the connection to take out the size of the IPsec
overhead, however you can use ICMP error messages from the IPsec layer to do
the same thing.
2) Handling TCP timeouts while a SA is negotiated. My implementation would
drop the first TCP/SYN packet while the negotiation was going on, then send
the second packet that comes down, usually after the negotiation went
through... The other option was to send the TCP/SYN packet in the clear...
BITW implementations have many of the same things to do, the only difference
is that it happens after it goes through Ethernet processing... I have heard
of an implementation that went through a Linux TUN(???) driver to pass the
full Ethernet packet up to user space to have the IPsec processing done on
it before passing back down as a raw Ethernet packet to go out eth0... Then
there are external gateways that we are all familiar with...
I am interested in external gateways mainly because they are
1) Purchasable off of the shelf
2) Don't have integration requirements - just tell the customer to buy two
and get them to work, we run over it
Bill
-----Original Message-----
From: CAVANNA,VICENTE V (A-Roseville,ex1)
[mailto:vince_cavanna@agilent.com]
Sent: Friday, November 02, 2001 9:29 AM
To: 'Bill Strahm'
Cc: SHEEHY,DAVE (A-Americas,unix1); CAVANNA,VICENTE V (A-Roseville,ex1);
'Ofer Biran'; ips@ece.cmu.edu
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Good Morning Bill,
To me, a BITS implementation of IPSec does not require changes to the OS
(with its built-in network stack) and is in fact useful when such changes
are not feasible. In BITS, I assume IPSec is implemented as a shim between
the network and data link layer. I thought, from reading the literature,
that this was a conventional definition of BITS.
If you are allowed to make changes to the network stack when adding IPSec
functionality then, as I noted in my original memo, I consider transport
mode to be feasible .
If I understand you correctly then, what you really favor is a BITW
implementation which I understand to be essentially an external crypto
device. I would like to be able to use that too, but only provisionally, as
a BITW implementation will eventually (as iSCSI matures) be considered too
expensive and IPSec will have to be incorporated more tightly into the
network stack.
Vince
-----Original Message-----
From: Bill Strahm [mailto:bill@Sanera.net]
Sent: Thursday, November 01, 2001 10:18 PM
To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Ofer Biran'; ips@ece.cmu.edu
Cc: SHEEHY,DAVE (A-Americas,unix1)
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
Ok,
First off with complexity comes a configuration nightmare...
Second I can implement both a BITS and a BITW IPsec Transport and Tunnel
mode... it really isn't all that hard. BITS implies that you are making OS
changes, or at least changes under the TCP/UDP layer that is traditionally
exposed to user applications, so I think most of the argument you are trying
to make in your second paragraph doesn't hold much water for me. I would
rather use Tunnel mode myself, however my reasons are that I can completely
offload the implementation off of the host and target and let intermediate
devices deal with security policies and such things... However most of the
tone of the security draft is to require for at least one end if not both to
be intimately aware of what is going on with security...
Bill
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
CAVANNA,VICENTE V (A-Roseville,ex1)
Sent: Thursday, November 01, 2001 5:19 PM
To: 'Ofer Biran'; ips@ece.cmu.edu
Cc: CAVANNA,VICENTE V (A-Roseville,ex1); SHEEHY,DAVE (A-Americas,unix1)
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
It seems to me (who has not had the experience of implementing IpSec) that
tunnel mode, even when implemented in the end host (rather than in a
router), is a superset of transport mode whose only significant disadvantage
is that tunnel mode requires more overhead in the form of the extra IP
header. On the other hand, tunnel mode offers more flexibility in
implementation as it is easier to implement in BITS and BITW implementations
whereas transport mode can only be easily implemented when IPSec is
implemented as part of the network layer i.e. integrated into the OS. The
reason is that the IPSec headers are inserted AFTER the IP payload is
constructed. This means that IPSec has to duplicate IP functionality because
it has to recalculate the IP checksum and fragment the packet when
necessary.
I would support making tunnel mode the favored mode in iSCSI. IPSec
compliance requires that transport mode be implemented but if iSCSI
discourages it the implementation need not be as efficient as tunnel mode.
Vince
|-----Original Message-----
|From: Ofer Biran [mailto:BIRAN@il.ibm.com]
|Sent: Thursday, November 01, 2001 4:31 AM
|To: ips@ece.cmu.edu
|Subject: iSCSI: IPsec tunnel / transport mode decision
|
|
|I'd like to drive this open issue into group consensus. It seems to
|me that the tendency was more toward making tunnel mode a MUST as iFCP
|and FCIP did, mainly due the option of integrating an existing IPsec
|chip/box with the iSCSI implementation offering. If we reach
|this decision,
|we may choose even not to mention transport mode (as MAY or some other
|recommending text).
|
|There is an excellent analysis made by Bernard Aboba in Section
|"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
|( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
|that can help us with this decision (also Section "5.2. NAT
|traversal" is
|relevant).
|
| Regards,
| Ofer
|
|Ofer Biran
|Storage and Systems Technology
|IBM Research Lab in Haifa
|biran@il.ibm.com 972-4-8296253
|
From owner-ips@ece.cmu.edu Fri Nov 2 13:13:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13929
for ; Fri, 2 Nov 2001 13:13:46 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2HOKw24291
for ips-outgoing; Fri, 2 Nov 2001 12:24:20 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2HOFl24280
for ; Fri, 2 Nov 2001 12:24:15 -0500 (EST)
Received: from icarus.sanera.net (icarus [192.168.254.11])
by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fA2HO5u08192;
Fri, 2 Nov 2001 09:24:05 -0800
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
by icarus.sanera.net (8.11.6/8.11.2) with SMTP id fA2HNx624806;
Fri, 2 Nov 2001 09:23:59 -0800
From: "Bill Strahm"
To: "Ron Cohen" , "ips" ,
"Paul Koning"
Subject: RE: iSCSI: current UNH Plugfest: Reserved bits
Date: Fri, 2 Nov 2001 09:23:49 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <001901c163ae$f30a6a90$6f07a8c0@COORS>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
In many cases that is acceptable... Imagine what would happen if Router
vendors threw out packets with headers that set reserved bits to anything
but 1. Anyone that wanted to play with DiffServ would have to buy new
routers that implemented the functionality of the TOS bits... This when it
is perfectly acceptable to just ignore them and send packets on without
applying any extra functionality - What a pain.
Some of the upgrade problem can be handled with a new version number (if you
don't speak the new version, I will drop the packet) but there are MANY
extensions that I can think of where using a bit or two of a reserved field
would allow potentially better performance if the endpoint knows what to do,
and no real degradation of service if it doesn't know what to do... Why
should I have to rev the version number to handle this case ?
Bill
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Ron Cohen
Sent: Friday, November 02, 2001 6:59 AM
To: ips; Paul Koning
Subject: Re: iSCSI: current UNH Plugfest: Reserved bits
The problem with accepting values in reserved bits is that when the reserved
bit is no longer reserved (evolution in the standard) it gives the
impression to the initiator that a target implements the new feature when it
may actually only be ignoring it.
Ron
----- Original Message -----
From: "Paul Koning"
To:
Cc: ;
Sent: Thursday, November 01, 2001 6:38 PM
Subject: RE: iSCSI: current UNH Plugfest
> Excerpt of message (sent 1 November 2001) by Bill Strahm:
> > Usually the "Conservative in what you send, Liberal in what you accept"
> > policy is used...
>
> That's a very important principle...
>
> > In otherwords, The sender MUST set to 0 (or some other value) The
receiver
> > MUST ignore the value...
>
> That's the way to express the principle. But the text quoted in the
> earlier notes does not express it the same way.
>
> In particular "... are format errors. This when detected..." implies
> that receivers may or may not detect format errors. In other words,
> it implies -- but does NOT state explicitly -- that receivers MAY
> check reserved fields for zeroness.
>
> > This allows for some tweaking of the implementation, if I control both
ends
> > I might set a reserved value to 1, then I know something... If I receive
a
> > reserve value set to 1 and I don't do anything the other end knows it is
not
> > talking to itself (this can even be a versioning thing as well)
> >
> > Now, we need to be VERY careful in defining this, do we plan on having
> > Protocol V1 endpoints talk to Protocol V2 endpoints, what does that
mean...
> > is it possible, is it desirable ? will there be extensions ???
> >
> > If you can truly answer NO to all of those things, I would argue for
> > REMOVING the reserved fields (if possible), if not, the MUST set, MUST
> > ignore policy seems better
>
> I agree strongly. There is a lot of experience in the community on
> what helps and what hurts convenient version upgrade. In particular,
> there is a LOT of evidence that ANY checking of reserved fields is a
> nasty thing. Unless you plan never to go beyond V1, you really need
> to require the rule Bill stated, i.e., receivers MUST ignore the
> contents of reserved fields -- they are NOT allowed to "verify" them.
>
> So the spec needs to be clarified to say that random values in
> reserved fields are NOT format errors and receivers MUST NOT treat
> them as such.
>
> paul
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Eddy Quicksall
> > Sent: Thursday, November 01, 2001 5:15 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI: current UNH Plugfest
> >
> >
> > I am reluctant to say this because I think most people think the
> > initiator/target must check for correctness ... but, it is my feeling
that
> > that job should be up to a basher program. The target should not be in
the
> > business of diagnosing the initiator. The only time a target should
check a
> > field is when it could crash the system or data. Some format errors may
have
> > no consequences whatsoever.
> >
> > Eddy
> >
> >
> > -----Original Message-----
> > From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
> > Sent: Wednesday, October 31, 2001 05:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: current UNH Plugfest
> >
> >
> > Attached are the new issues that arose during the iSCSI plugfest
> > at UNH on Wednesday 31-Oct-2001.
> >
> > (Note: these issues do not take into account any modifications or
> > clarifications that occured in the standard due to the issues raised
> > on Monday or Tuesday.)
> >
> > Bob Russell
> > InterOperability Lab
> > University of New Hampshire
> > rdr@iol.unh.edu
> > 603-862-3774
> >
> > ------------------------------------------------------------------------
> > ----
> >
> > 1. Are receivers (initiator or target) REQUIRED to check that reserved
> > bits and/or fields are set to 0?
> >
> > Section 3 on page 48 of draft 8 says:
> > "Any bits not defined MUST be set to zero. Any reserved fields and
> > values MUST be 0 unless specified otherwise."
> >
> > and Section 8.3 on page 127 of draft 8 says:
> > "Explicit violations of the PDU layout rules stated in this
> > document
> > are format errors. This when detected, usually indicates a major
> > implementation flaw in one of the parties.
> >
> > When a target or an initiator receives an iSCSI PDU with a format
> > error, it MUST reset all transport connections in the session
> > immediately and escalate the format error to session recovery
> > (section 8.11.4)."
> >
> > According to these rules, a PDU with reserved bits and/or fields that
> > are not set to 0 violates the PDU layout rules. Therefore, if an
> > initiator or target receives such a PDU, it should immediately close
> > all connections in the session and go to session recovery.
> >
> > Clearly a format error has extremely severe consequences!
> >
> > Although all vendors are setting reserved bits and fields to 0 on
> > PDUs they are sending, many are NOT checking PDUs they are receiving
> > to see if these bits and fields are set to 0. Basically, vendors are
> > saying "who cares if reserved bits and/or fields in incoming PDUs are
> > not zero? We do not want to take the time to do this checking, and
> > there is no benefit to doing it. As long as the non-reserved bits
> > and
> > fields are set properly, we can and should proceed. Any time devoted
> > to doing this checking is wasted in 99+% of the cases, and in the
> > (unlikely) case that a non-zero bit or field is found, the
> > consequences are too severe."
> >
> > There should be some statement in the standard to clarify what
> > checking
> > is required and what is optional.
> >
> > 2. A similar situation arises with respect to checking the consistency
> > of fields such as Version-max, Version-min and Version-active in
> > Login
> > Requests and Login Responses.
> >
> > For example, consider the Version-max field.
> >
> > Section 3.12.5 says:
> > "All Login requests within the Login phase MUST carry the same
> > Version-max."
> >
> > All vendor initiators are setting Version-max correctly on all
> > login requests they are sending, but many vendor targets are NOT
> > checking received login requests to ensure that this rule is
> > enforced.
> > In particular, many targets simply use the Version-max and
> > Version-min
> > on the first login request they receive on a new connection, and then
> > they ignore these fields on all subsequent login requests in the same
> > login phase.
> >
> > Strictly speaking, a change in the Version-max field during the login
> > phase constitutes a protocol error according to section 8.8 on page
> > 130
> > of draft 8:
> >
> > "All violations of iSCSI PDU exchange sequences specified in this
> > draft are also protocol errors. This category of errors can be
> > addressed only by fixing the implementations; iSCSI defines Reject
> > and response codes to enable this".
> >
> > Therefore the target should send back a login response with a status
> > of 0x0200 and then close the connection.
> >
> > However, Section 3.12.5 also says:
> > "The target MUST use the value presented with the first login
> > request."
> >
> > This rule seems to imply that the value CAN change, because if it
> > cannot
> > change, then it doesn't matter which one of the login requests it is
> > taken from, they are all the same anyway.
> >
> > The suggestion is to keep the requirement that the target MUST use
> > the
> > value presented on the first login request, but to allowed the target
> > to ignore the value presented on all subsequent login requests in the
> > same login phase. A similar rewording should be done for the other
> > fields.
> >
> > 3. Can commands be sent out of order on the same connection?
> >
> > The behavior of targets is clearly specified in Section 2.2.2.3 on
> > page 25 of draft 8, which says:
> > "Except for the commands marked for immediate delivery the iSCSI
> > target layer MUST eliver the commands for execution in the order
> > specified by CmdSN."
> >
> > Section 2.2.2.3 on page 26 of draft 8 also says:
> > "- CmdSN - the current command Sequence Number advanced by 1 on
> > each command shipped except for commands marked for immediate
> > delivery."
> > but the meaning of the term "shipped" is vague, and does not
> > necessarily
> > require that the PDUs arrive on the other end of a TCP connection
> > in the same order that the CmdSN values were assigned to these PDUs.
> >
> > Some initiators have been designed to send commands out of CmdSN
> > order on one connection. Consider the situation where there is only
> > one connection and a high-level dispatcher creates a PDU for a SCSI
> > command that involves writing immediate data to the target. This PDU
> > is enqueued to a lower-level layer which has to setup, start, and
> > wait-for a DMA operation to move the immediate data into an onboard
> > buffer before the PDU can be put onto the wire. While this is
> > happening, the dispatcher creates another unrelated PDU for a SCSI
> > read command (for example), and when this PDU is passed to the
> > lower-level layer it can be sent immediately, ahead of the previous
> > write PDU and therefore out of order on this connection.
> >
> > The standard clearly allows this to happen if the two PDUs were sent
> > on different connections, and seems to imply that this can also
> > happen
> > when the two PDUs are sent on the same connection.
> >
> > The suggestion is to put in the standard an explicit statement that
> > this is allowed or not allowed, as appropriate.
> >
> > If this is allowed, such a statement would avoid the erroneous
> > assumption being made by some target implementers that within a
> > single
> > connection, commands will arrive in order.
> >
> > If this is not allowed, such a statement would avoid the erroneous
> > assumption being made by some initiator implementers that within a
> > single connection, commands can be put on the wire out of order.
> >
> > 4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
> > now allow: "A value of 0 indicates no limit."
> >
> > Is this useful? Does it buy anything?
> >
> > The difficulties implementers are having with this are:
> >
> > 1) It is a special case.
> > 2) It causes discontinuous ranges (for example, [0,64..2**24])
> > 3) It violates the min/max function normally used for the key.
> > 4) There is always a limit anyway.
> >
> > Consider FirstBurstSize, which can have a value that is described
> > as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
> > is selected.
> >
> > I one side offers 0 to mean unlimited, and the other side
> > has a limit, it will reply with that limit, say 128 Kbytes.
> > Therefore, the result is not min(0, 128K) but rather max(0, 128K).
> > The statement in the standard that "the minimum of the 2 numbers is
> > selected" is therefore wrong when one of the numbers is 0.
> >
> > Furthermore, when an initiator or target receives an offer for one
> > of these keys, it cannot simply check that the offered value is
> > legal by testing it against some minimum and maximum. It must first
> > check for 0 and then only if that check shows the value is non-zero
> > can it do the min/max range check for legality (i.e., 64-2**24).
> >
> > Finally, there is always a limit. If nothing else it is the
> > limit imposed by the 24-bit DataSegmentLength field of the PDU
> > requesting the transfer. It is useless to specify a FirstBurstSize
> > (or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
> > the largest possible DataSegmentLength in any PDU that can use
> > this value is 2**24-1.
> >
> > The suggestion is to just eliminate this special case of 0 and
> > require
> > that the range 64-to-(2**24-1) be used instead -- it has exactly the
> > same effect in all cases, it is easier to describe in the standard
> > because it avoids all the extra words, and it is easier to code
> > because it avoids all the special cases.
> >
> > NOTE: the standard should specify the limit in the ranges for
> > MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
> > of 2**24. The number 2**24 cannot be represented in the 24-bit
> > DataSegmentLength field and therefore can never be used.
> >
> > 5. This is a suggestion for a minor rewording in the standard to avoid
> > misunderstandings.
> >
> > In Appendix E on page 188 of draft 8 it says:
> >
> > "The response to this command is a text response containing a list
> > of
> > targets and their addresses. Each target is returned as a target
> > record. A target record begins with the TargetName text key,
> > followed by a list of TargetAddress text keys, ..."
> >
> > In fact, there are situations where there are no targets and/or no
> > addresses. These situations are clearly defined in the draft after
> > the sentences quoted above, but it would help if those sentences
> > at least hinted at the possibility that the lists could be empty
> > or might not contain addresses. A possible rewording would be:
> >
> > "The response to this command is a text response containing a list
> > of
> > zero or more targets and, optionally, their addresses. Each target
> > is returned as a target record. A target record begins with the
> > TargetName text key, followed by a list of zero or more
> > TargetAddress text keys, ..."
> >
> >
> > 6. This is a suggestion for another very minor rewording in the
> > standard.
> >
> > At the end of section 2.2.3 on page 29 of draft 8 it says:
> >
> > "Before full feature phase is established, only Login PDUs are
> > allowed. ..."
> >
> > The suggested rewording is:
> >
> > "Before full feature phase is established, only Login Request and
> > Login Response PDUs are allowed. ..."
>
>
From owner-ips@ece.cmu.edu Fri Nov 2 14:19:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15764
for ; Fri, 2 Nov 2001 14:19:40 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2IKJ328612
for ips-outgoing; Fri, 2 Nov 2001 13:20:19 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2IKHl28607
for ; Fri, 2 Nov 2001 13:20:17 -0500 (EST)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
by atlrel2.hp.com (Postfix) with ESMTP id DF16F307
for ; Fri, 2 Nov 2001 13:20:16 -0500 (EST)
Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA04104 for ; Fri, 2 Nov 2001 10:21:43 -0800 (PST)
Message-Id: <200111021821.KAA04104@core.rose.hp.com>
Date: Fri, 02 Nov 2001 10:32:30 -0800
From: "Mallikarjun C."
Reply-To: cbm@rose.hp.com
Organization: Hewlett-Packard, Roseville
X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715)
X-Accept-Language: en
MIME-Version: 1.0
To: ips
Subject: iSCSI: new state diagrams for rev09
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
All:
Consequent to the feedback I received both online and
offline, iSCSI state diagrams are considerably revamped.
Thanks to all those who provided the feedback. The new
state diagrams are posted at:
http://storage-arch.hp.com/iscsi_states_rev09.pdf
The ASCII forms of the above are currently part of rev 08-90
draft that Julian posted on his web.
The major changes are -
- The initiator and target state machines are split for
both standard connection diagram and session state
diagram. It is hoped that this separation makes it
easier to follow.
- Several (informative, but) non-essential states were
eliminated, since they were waiting for internal events
(like acquiring resources) that are likely non-existent
in good implementations. That leaves us with a 7-state
machine for both initiator and target.
- The reduction of states has a salutary effect on the ASCII
representation. I was able to translate all the diagrams
into ASCII!
- The state descriptions are more descriptive now, specifically
calling out the event(s) that the state machine is waiting
for in that state.
- The transition descriptions are also more descriptive,
listing the set of events that causes the given transition
for each of the roles.
- The "connection recovery state diagram" has been renamed
as "connection cleanup state diagram" since the word "recovery"
was inadvertently overloaded. Connection recovery (the
act of reassigning the task allegiance to a different connection)
happens outside the scope of this state machine depending on
the operational ErrorRecoveryLevel - all this diagram
specifies is the dynamics of gracefully closing an active
iSCSI connection, perhaps replacing with a new connection.
- Consequent to the above and for general clarity, some
states have been renamed to reflect the "wait reason" better.
- Certain missing/incorrect transitions are now fixed -
like the "close the session" Logout handling etc.
- I added some text on the first slide that describes the
design philosophy behind the current model, perhaps also
can be called design assumptions.
I have only one (likely) open issue on my list. I received
feedback from one reviewer that the _description_ of the diagrams
is not "traditional" - for example, the current tabular format
captures the transitions (each caused by a set of events) in
a state-state matrix, but does not describe them in terms of
an event-state matrix for each state (which would run into
several pages). The current description scheme seemed quite
acceptable to myself (and also to Julian among others) - but
I am open on this. Please comment if you strongly feel about
this issue.
Thanks!
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com
From owner-ips@ece.cmu.edu Fri Nov 2 15:59:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18016
for ; Fri, 2 Nov 2001 15:59:14 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2JfoP05643
for ips-outgoing; Fri, 2 Nov 2001 14:41:50 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2Jfml05637
for ; Fri, 2 Nov 2001 14:41:48 -0500 (EST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA39548
for ; Fri, 2 Nov 2001 14:39:12 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id fA2Jfjj208464
for ; Fri, 2 Nov 2001 12:41:45 -0700
X-Priority: 1 (High)
Importance: Normal
Subject: RE: is TargetName always mandatory or not?
To: "Julian Satran"
Cc: "Jim Hafner" , ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID:
From: "John Hufferd"
Date: Fri, 2 Nov 2001 11:40:50 -0800
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
11/02/2001 12:41:45 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Julian,
I agree with Jim Hafner on this issue. The Draft should say:
"The TargetName is required on the first login message on every connection
(in all cases, new session or adding connections to existing sessions)."
Also I think we need to change section 3.12.9, which currently says:
"The TSID is the target assigned tag for a session with a specific named
initiator that, together with the ISID uniquely identifies a session with
that initiator".
Should be changed to:
"The TSID is the target assigned tag for a session with a specific named
initiator that, together with the ISID uniquely identifies a session from
that specific target to that specific initiator. That is, the TSID is a
unique value within the scope of a specific Target (Not necessarily Unique
within the iSCSI Target Network Entity)."
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com
Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 11/02/2001 08:04:03 AM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: RE: is TargetName always mandatory or not?
Folks,
I think this thread may be exposing either an ambiguity in the draft or
perhaps a gap.
I think it's possible to interpret the requirement that TargetName be
supplied (for normal sessions) only on the *first login message on the
first connection of a new session* and is not required on the *first login
message of subsequent connections intended for the same session". My
personal interpretation is that the TargetName is required on the *first
login message on every connection (in all cases, new session or adding
connections to existing sessions)*. I also think Andre's example of a
network entity containing many iSCSI targets with shared network portals
(and the scoping of portal group tags and TSIDs by iSCSI target) points out
the need for the more restrictive requirement (and the rest of my response
to Andre assumed this).
But I've heard other comments that can be interpreted as the less
restrictive requirement is what is intended.
So, I suggest (and I don't think this is asking much) that the requirement
be that TargetName be supplied on the first Login message of every
connection (not just the leading one).
Jim Hafner
From owner-ips@ece.cmu.edu Fri Nov 2 17:17:01 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20176
for ; Fri, 2 Nov 2001 17:17:01 -0500 (EST)
Received: (from majordom@localhost)
by ece.cmu.edu (8.11.0/8.10.2) id fA2LJig14028
for ips-outgoing; Fri, 2 Nov 2001 16:19:44 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36])
by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fA2LJgl14023
for ; Fri, 2 Nov 2001 16:19:42 -0500 (EST)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5B71231CD
for