From mailnull@www1.ietf.org Sun Sep 1 06:58:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14138 for ; Sun, 1 Sep 2002 06:58:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g81Axar04110 for ips-archive@odin.ietf.org; Sun, 1 Sep 2002 06:59:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81Axao04107 for ; Sun, 1 Sep 2002 06:59:36 -0400 From: sip-admin@ietf.org Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14095 for ; Sun, 1 Sep 2002 06:58:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81Ax6o03671 for ; Sun, 1 Sep 2002 06:59:06 -0400 Date: Sun, 01 Sep 2002 06:59:06 -0400 Message-ID: <20020901105906.1916.2388.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: ips-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ips-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@. Thanks! Passwords for ips-web-archive@ietf.org: List Password // URL ---- -------- ips@ietf.org SFpt https://www1.ietf.org/mailman/options/ips/ips-web-archive%40ietf.org From sip-admin@ietf.org Sun Sep 1 09:26:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19806 for ; Sun, 1 Sep 2002 09:26:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81DRfo17479 for ; Sun, 1 Sep 2002 09:27:41 -0400 Date: Sun, 01 Sep 2002 09:27:41 -0400 Message-ID: <20020901132741.1916.19375.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: ips-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ips-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@. Thanks! Passwords for ips-archive@lists.ietf.org: List Password // URL ---- -------- ips@ietf.org INMn https://www1.ietf.org/mailman/options/ips/ips-archive%40lists.ietf.org From owner-ips@ece.cmu.edu Sun Sep 1 22:15:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01878 for ; Sun, 1 Sep 2002 22:15:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g821VAY23608 for ips-outgoing; Sun, 1 Sep 2002 21:31:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from master.linux-ide.org (astound-64-85-224-253.ca.astound.net [64.85.224.253]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g820bko21187 for ; Sun, 1 Sep 2002 20:37:46 -0400 (EDT) Received: from localhost (andre@localhost) by master.linux-ide.org (8.9.3/8.9.3) with ESMTP id RAA08336; Sun, 1 Sep 2002 17:37:17 -0700 Date: Sun, 1 Sep 2002 17:37:17 -0700 (PDT) From: Andre Hedrick X-Sender: andre@master.linux-ide.org To: Julian Satran cc: ips@ece.cmu.edu Subject: SAS and iSCSI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian et al. Give these are both "SCSI" type transports, what are the means to add future SAS extentions and opcodes to the expected final version of the working group document? Would this be considered a vendor specific issue. Regards, Andre Hedrick iSCSI Software Solutions Provider http://www.PyXTechnologies.com/ From owner-ips@ece.cmu.edu Mon Sep 2 13:23:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27286 for ; Mon, 2 Sep 2002 13:23:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g82GkP513878 for ips-outgoing; Mon, 2 Sep 2002 12:46:25 -0400 (EDT) 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 g82GkNo13871 for ; Mon, 2 Sep 2002 12:46:23 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g82GkBeB020534; Mon, 2 Sep 2002 18:46:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g82Gk84C018826; Mon, 2 Sep 2002 18:46:10 +0200 Subject: Re: SAS and iSCSI To: Andre Hedrick Cc: ips@ece.cmu.edu, "Julian Satran" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Mon, 2 Sep 2002 19:39:35 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/09/2002 19:46:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Extension (as keys, etc.) can be handled in iSCSI in a standard defined way. I assume that SAS (a limited distance serial attachement) and iSCSI are complementary and I view SAS a "local" (vs. SAN) attachment and iSCSI more as a network attachment. Julo Andre Hedrick cc: ips@ece.cmu.edu Subject: SAS and iSCSI 02/09/02 03:37 Hi Julian et al. Give these are both "SCSI" type transports, what are the means to add future SAS extentions and opcodes to the expected final version of the working group document? Would this be considered a vendor specific issue. Regards, Andre Hedrick iSCSI Software Solutions Provider http://www.PyXTechnologies.com/ From owner-ips@ece.cmu.edu Mon Sep 2 14:10:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28460 for ; Mon, 2 Sep 2002 14:10:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g82HaxE16352 for ips-outgoing; Mon, 2 Sep 2002 13:36:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g82Hawo16348 for ; Mon, 2 Sep 2002 13:36:58 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Sep 2002 13:36:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C251@CORPMX14> From: Black_David@emc.com To: andre@pyxtechnologies.com Cc: ips@ece.cmu.edu Subject: RE: SAS and iSCSI Date: Mon, 2 Sep 2002 13:36:41 -0400 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 If the extensions and opcodes use the SCSI CDB and associated data movement paradigm as defined by T10, no modifications to the iSCSI specs should be necessary. It's hard to be more specific without more details on what is specifically of concern. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Andre Hedrick [mailto:andre@pyxtechnologies.com] > Sent: Sunday, September 01, 2002 8:37 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: SAS and iSCSI > > > > Hi Julian et al. > > Give these are both "SCSI" type transports, what are the means to add > future SAS extentions and opcodes to the expected final version of the > working group document? > > Would this be considered a vendor specific issue. > > Regards, > > Andre Hedrick > iSCSI Software Solutions Provider > http://www.PyXTechnologies.com/ > From owner-ips@ece.cmu.edu Mon Sep 2 16:29:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00795 for ; Mon, 2 Sep 2002 16:29:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g82JovW23312 for ips-outgoing; Mon, 2 Sep 2002 15:50:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g82Jouo23308 for ; Mon, 2 Sep 2002 15:50:56 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Sep 2002 15:50:50 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C253@CORPMX14> From: Black_David@emc.com To: andre@pyxtechnologies.com Cc: ips@ece.cmu.edu Subject: RE: SAS and iSCSI Date: Mon, 2 Sep 2002 15:50:44 -0400 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 Andre, > Will the additional opcodes and command descriptor blocks that > are definied in SAS be transferred using additional header > segements by the iSCSI transport? At the moment, the SAS specification (ftp://ftp.t10.org/t10/drafts/sas/sas-r01.pdf) says: 10.3 SCSI commands No SAS-specific SCSI commands are defined. So, no iSCSI modifications are currently needed. > This assumes there will be new opcodes as SAS is very much > ontrack to be an API for array management. As long as those opcodes are SCSI opcodes that use SCSI CDBs in a fashion specified by T10, no iSCSI modifications will be needed. > Specifically where many of the current > management applications of heavily mated to SCSI and SAS is a means to > grant them extended life, whereas the hardware is dying. So > in order to acommidate such dependencies, the concern is to insure that > iSCSI will be adaptable to address their over short comings to be so > tightly tied to a transport layer and semi dependent of physical layers. Yes and no. To the extent that they depend on issuing SCSI commands, receiving SCSI responses, etc., iSCSI handles that. To the extent that they depend on physical layer specifics (e.g., parallel SCSI mode pages), they're broken and should be fixed, although I don't think there are any fundamental obstacles to emulating parallel SCSI mode pages in an iSCSI target to accommodate such brain-damaged software if one really wanted to do so. As for the original question about whether iSCSI AHSs (additional header segments) would be used for SAS, the answer appears to be "only for extended CDB formats defined by T10", something that iSCSI already supports (AHS code 1). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 2 21:00:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04301 for ; Mon, 2 Sep 2002 21:00:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g830OZT06862 for ips-outgoing; Mon, 2 Sep 2002 20:24:35 -0400 (EDT) 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 [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g830OWo06854 for ; Mon, 2 Sep 2002 20:24:33 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel7.hp.com (Postfix) with ESMTP id 4A2FA804FC0; Mon, 2 Sep 2002 20:24:31 -0400 (EDT) Received: from swathi (pal1nai162119.nsr.hp.com [15.244.162.119]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id RAA25204; Mon, 2 Sep 2002 17:24:29 -0700 (PDT) Message-ID: <003801c252e0$445b20d0$77a2f40f@rose.hp.com> From: "Mallikarjun C." To: "Julian Satran" Cc: , , References: Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions) Date: Mon, 2 Sep 2002 17:24:28 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, >I suggest > that we say that a target will never execute a TM abort task on a TM > function. I agree, that's what I suggested in bullet (a) of the proposed text. We already have an exception documented elsewhere about Task Reassign wrt Text Requests (bullet (b) - first half). The one thing that we (I) missed in the past was about the exception related to Task Reassign wrt Logout command (bullet (b) - second half). We should specify that in the draft somewhere. To summarize, with your latest change below, 2 out of 3 exceptions are already in the document. > Do we really need those exceptions? It appears that you're suggesting that we don't need to be as formal as I suggested, which is a separate "how" part from the "what" part. I'd continue to maintain that summarizing all three exceptions in one new subsection is a good thing. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: "Mallikarjun C." Cc: ; ; ; Sent: Friday, August 30, 2002 10:38 PM Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions) > Mallikarjun, > > Do we really need those exceptions? > > For the ABORT TASK the only ambiguity I see in the text is that of what is > the result of an ABORT TASK on an ABORT TASK. I thought that the return > of a response for each will be an indication of the action taken. > > To really simplify thing and not build excessive logic around it I suggest > that we say that a target will never execute a TM abort task on a TM > function. > > The text of 9.5.1 becomes: > > Function > The Task Management functions provide an initiator with a way to > explicitly control the execution of one or more Tasks (SCSI and iSCSI > tasks). The Task Management function codes are listed below. For a more > detailed description of SCSI task management, see [SAM2]. > > 1 - ABORT TASK - aborts the task identified by the Referenced Task Tag > field. > > 2 - ABORT TASK SET - aborts all Tasks issued via this session on the > logical unit. > > 3 - CLEAR ACA - clears the Auto Contingent Allegiance condition. > > 4 - CLEAR TASK SET - aborts all Tasks in the appropriate task set as > defined by the TST field in the Control mode page (see [SPC3]). > > 5 - LOGICAL UNIT RESET > > 6 - TARGET WARM RESET > > 7 - TARGET COLD RESET > > 8 - TASK REASSIGN - reassigns connection allegiance for the task > identified by the Initiator Task Tag field to this connection, thus > resuming the iSCSI exchanges for the task. > > For all these functions, the Task Management function response MUST be > returned as detailed in Section 9.6 Task Management Function Response. All > these functions apply to the referenced tasks regardless of whether they > are proper SCSI tasks or tagged iSCSI operations. Task management > requests must act on all the commands having a CmdSN lower than the task > management CmdSN. If the task management request is marked for immediate > delivery, it must be considered immediately for execution, but the > operations involved (all or part of them) may be postponed to allow the > target to receive all relevant tasks. According to [SAM2], for all the > tasks covered by the Task Management response (i.e., with CmdSN not higher > than the task management command CmdSN), additional responses MUST NOT be > delivered to the SCSI layer after the Task Management response. The iSCSI > initiator MAY deliver to the SCSI layer all responses received before the > Task Management response (i.e., it is a matter of implementation if the > SCSI responses, received before the Task Management response but after the > task management request was issued, are delivered to the SCSI layer by the > iSCSI layer in the initiator). The iSCSI target MUST ensure that no > responses for the tasks covered by a task management function are > delivered to the iSCSI initiator after the Task Management response. > > For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue > to respond to all valid target transfer tags (received via R2T, Text > Response, NOP-In, or SCSI Data-in PDUs) related to the affected task set, > even after issuing the task management request. The issuing initiator > SHOULD however terminate (i.e., by setting the F-bit to 1) these response > sequences as quickly as possible. The target on its part MUST wait for > responses on all affected target transfer tags before acting on either of > these two task management requests. In case all or part of the response > sequence is not received (due to digest errors) for a valid TTT, the > target MAY treat it as a case of within-command error recovery class (see > Section 5.1.4.1 Recovery Within-command) if it is supporting > ErrorRecoveryLevel >= 1, or alternatively may drop the connection to > complete the requested task set function. > > If the connection is still active (it is not undergoing an implicit or > explicit logout), ABORT TASK MUST be issued on the same connection to > which the task to be aborted is allegiant at the time the Task Management > Request is issued. If the connection is implicitly or explicitly logged > out (i.e., no other request will be issued on the failing connection and > no other response will be received on the failing connection), then an > ABORT TASK function request may be issued on another connection. This Task > Management request will then establish a new allegiance for the command to > be aborted as well as abort it (i.e., the task to be aborted will not have > to be retried or reassigned, and its status, if issued but not > acknowledged, will be reissued followed by the Task Management response). > > At the target an ABORT TASK function MUST NOT be executed on a Task > Management request; such a request MUST result in Task Management response > of "Function rejected". > > For the LOGICAL UNIT RESET function, the target MUST behave as dictated by > the Logical Unit Reset function in [SAM2]. > > The implementation of the TARGET WARM RESET function and the TARGET COLD > RESET function is OPTIONAL and when implemented, should act as described > below. The TARGET WARM RESET is also subject to SCSI access controls on > the requesting initiator as defined in [SPC3]. When authorization fails > at the target, the appropriate response as described in Section 9.6 Task > Management Function Response MUST be returned by the target. The TARGET > COLD RESET function is not subject to SCSI access controls, but its > execution privileges may be managed by iSCSI mechanisms such as login > authentication. > > When executing the TARGET WARM RESET and TARGET COLD RESET functions, the > target cancels all pending operations on all Logical Units known by the > issuing initiator. Both functions are equivalent to the Target Reset > function specified by [SAM2]. They can affect many other initiators logged > in with the servicing SCSI target port. > > The target MUST treat the TARGET COLD RESET function additionally as a > power on event, thus terminating all of its TCP connections to all > initiators (all sessions are terminated). For this reason, the Service > Response (defined by [SAM2]) for this SCSI task management function may > not be reliably delivered to the issuing initiator port. > > For the TASK REASSIGN function, the target should reassign the connection > allegiance to this new connection (and thus resume iSCSI exchanges for the > task). TASK REASSIGN MUST ONLY be received by the target after the > connection on which the command was previously executing has been > successfully logged-out. The Task Management response MUST be issued > before the reassignment becomes effective. > For additional usage semantics see Section 5.2 Retry and Reassign in > Recovery. > > At the target a TASK REASSIGN function request MUST NOT be executed to > reassign the connection allegiance of a Task Management function request > an active text negotiation task, or a Logout task; such a request MUST > result in Task Management response of "Function rejected". > > TASK REASSIGN MUST be issued as an immediate command. > > > > > > "Mallikarjun C." > Sent by: owner-ips@ece.cmu.edu > 31/08/02 05:45 > > > To: , , > cc: > Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol > questions) > > > > The intent consistently expressed in the draft is that all iSCSI tasks > are the same in that they are "managed" by the same task management > functions (proposed exceptions below) - some iSCSI tasks are also SCSI > tasks as a co-incidence. Technically, I thought we had concluded in > the past that, one could use Abort Task TMF to abort Text Requests as well > (and that's reflected in 2.2.2.1, second para). I think this is one of > the core ideas in the draft, and not worth risking a last minute change. > > Tony caught a scenario that however, I think, merits an explicit > clarification in > the draft - due to the inherent ambiguity in delivering an Abort Task > TMF to the SCSI layer that's directed at an abort operation already > being carried out by the SCSI layer (What does a successful completion > of the second abort mean to the original task state? Should the first > Abort response be sent back or not?). OTOH, there's no ambiguity > for the Task Set management case, because one knows that all the tasks > are dead once the TMF completes (SCSI tasks, iSCSI "abort" > tasks, everything). > > I suggest that we add a clarification for the "Abort-of-Abort" case, and > a couple of others (one of which is currently covered in 9.10) in one > new subsection. > > ---------------------------------------------------------------------------- > 9.5.7 Exceptions to Task Management Function Request usage > > The following two exceptions apply to the usage of iSCSI Task Management > functions defined earlier in the document. > > a) The ABORT TASK task management function request MUST NOT > be directed at a prior iSCSI task performing an ABORT TASK task > management function request. > > b) The TASK REASSIGN task management function request MUST > NOT be used to reassign the connection allegiance of an active text > > negotiation task, or a Logout task. > ------------------------------------------------------------------------------ > > If we do this, we'd have to > > - Have the "any iSCSI task" language in section 2.2.2.1, second para > to > point to the new 9.5.7, to make the reader aware of the exceptions. > - ditto for the first sentence in 9.5.1. > - ditto for the "All these functions apply..." sentence later in 9.5.1 > that > David identified. > > Comments? > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: > To: ; > Sent: Friday, August 30, 2002 7:58 AM > Subject: RE: Several iSCSI protocol questions > > > > > > > Since the Task Management Function itself has a CmdSN and > > > > > valid LUN, can one > > > > > Task Management Function affect (abort) another? > > > > > > > > No, SCSI task management functions operate on *SCSI* tasks, not > *iSCSI* > > > > tasks, and a task management function is not a *SCSI* task - see > SAM-2. > > > > > > This contradicts the text in Section 9.5.1: "The Task Management > functions > > > provide an initiator with a way to explicitly control the execution of > one > > > or more Tasks (SCSI and iSCSI tasks)." Your interpretation makes more > > sense > > > to me, however. > > > > And there's more text further down in 9.5.1 that seems to imply that > > one ought to be able to abort a Task Management Function. > > > > All these functions apply to the referenced tasks regard- > > less of whether they are proper SCSI tasks or tagged iSCSI opera- > > tions. > > > > I think you've caught something we need to fix ... > > > > > > > If not, then what is the > > > > > appropriate Task Management Function Response for an ABORT TASK > that > > > > > attempts to operate on another Task Management Function? > > > > > > > > That can't happen. The only task management function that could > > possibly > > > > attempt "to operate on another Task Management Function" is ABORT > TASK, > > but > > > > it identifies the task to be aborted by an Initiator Task Tag, > something > > > > that Task Management Functions *do not* have - see Section > > > > 9.5 of the iSCSI draft. > > > > > > I am looking at Section 9.5. I see "Initiator Task Tag" in the table > > > showing the PDU format, although it is not mentioned in the > > > text. Another typo? > > > > My mistake - I think we have some text cleanup to do, as SAM-2 > definitely > > considers task management functions not to be tasks, thus avoiding > issues > > of what happens when a task management function is applied to a task > > management function - I believe iSCSI needs to follow this route. > Julian? > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > From owner-ips@ece.cmu.edu Tue Sep 3 12:32:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03712 for ; Tue, 3 Sep 2002 12:32:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83Fp1O06366 for ips-outgoing; Tue, 3 Sep 2002 11:51:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from master.linux-ide.org (astound-64-85-224-253.ca.astound.net [64.85.224.253]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g82J5mo20927 for ; Mon, 2 Sep 2002 15:05:52 -0400 (EDT) Received: from localhost (andre@localhost) by master.linux-ide.org (8.9.3/8.9.3) with ESMTP id MAA01903; Mon, 2 Sep 2002 12:04:25 -0700 Date: Mon, 2 Sep 2002 12:04:25 -0700 (PDT) From: Andre Hedrick X-Sender: andre@master.linux-ide.org To: Julian Satran , Black_David@emc.com cc: ips@ece.cmu.edu Subject: Re: SAS and iSCSI 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 and David, Thanks for the reply and update, I guess the second part never made it to the reflector. Will the additional opcodes and command descriptor blocks that are definied in SAS be transferred using additional header segements by the iSCSI transport? This assumes there will be new opcodes as SAS is very much ontrack to be an API for array management. Specifically where many of the current management applications of heavily mated to SCSI and SAS is a means to grant them extended life, whereas the hardware is dying. So in order to acommidate such dependencies, the concern is to insure that iSCSI will be adaptable to address their over short comings to be so tightly tied to a transport layer and semi dependent of physical layers. Cheers, Andre Hedrick iSCSI Software Solutions Provider http://www.PyXTechnologies.com/ From owner-ips@ece.cmu.edu Tue Sep 3 12:32:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03727 for ; Tue, 3 Sep 2002 12:32:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83FqTE06504 for ips-outgoing; Tue, 3 Sep 2002 11:52:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83BaEo19277 for ; Tue, 3 Sep 2002 07:36:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22041; Tue, 3 Sep 2002 07:34:23 -0400 (EDT) Message-Id: <200209031134.HAA22041@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-mib-02.txt Date: Tue, 03 Sep 2002 07:34:22 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects For iFCP Author(s) : K. Gibbons, C. Monia, J. Tseng, F. Travostino Filename : draft-ietf-ips-ifcp-mib-02.txt Pages : 23 Date : 2002-8-29 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based monitoring and management of the Internet Fibre Channel Protocol (iFCP). This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-ifcp-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-ifcp-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-29142317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-29142317.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Sep 3 13:53:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07188 for ; Tue, 3 Sep 2002 13:53:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83HHLk13998 for ips-outgoing; Tue, 3 Sep 2002 13:17:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f12.pav2.hotmail.com [64.4.37.12]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83HCno13619 for ; Tue, 3 Sep 2002 13:12:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Sep 2002 10:12:43 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 03 Sep 2002 17:12:43 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: cdeng@iol.unh.edu, ips@ece.cmu.edu, qtao@iol.unh.edu, rdr@iol.unh.edu Subject: Logical Block address in iSCSI CDB Date: Tue, 03 Sep 2002 17:12:43 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Sep 2002 17:12:43.0483 (UTC) FILETIME=[1DB66AB0:01C2536D] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, I established a full feature phase in ISCSI and mounted a disk from a remote machine. I copied a file from my local file system to the mounted disk. SCSI issues a series of Write commands that are encapsulated inside ISCSI PDUs. My doubt is.... Do the logical block address contained in SCSI CDB inside ISCSI PDUs are actual address of the remote disk. Can we change that ???? What I am trying to do is,....... If SCSI sends only 2 block or 3 blocks, wait and collect data upto 16 blocks (Usual max PDU of ISCSI) and send them over the network so that it will reduce the header over-head. Any suggestions and indeas are highly appertiated. Thanking You Shesha Arizona State University. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ips@ece.cmu.edu Tue Sep 3 13:54:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07226 for ; Tue, 3 Sep 2002 13:54:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83HH0Q13966 for ips-outgoing; Tue, 3 Sep 2002 13:17:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mr1.sj.mailhost.seagate.com (mr1.sj.mailhost.seagate.com [204.160.183.125]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83GPVo10130; Tue, 3 Sep 2002 12:25:31 -0400 (EDT) Received: from mh0.sj.mailhost.seagate.com (mh0.sj.mailhost.seagate.com [10.26.8.221]) by mr1.sj.mailhost.seagate.com (8.12.3/8.12.3) with ESMTP id g83GPN0A018409; Tue, 3 Sep 2002 16:25:23 GMT Received: from sv-gw1.notes.seagate.com (sv-gw1.stsj.seagate.com [10.26.8.33]) by mh0.sj.mailhost.seagate.com (8.12.3/8.12.3) with ESMTP id g83GPMJZ002994; Tue, 3 Sep 2002 16:25:22 GMT Subject: Re: SAS and iSCSI To: andre@pyxtechnologies.com Cc: Black_David@emc.com, ips@ece.cmu.edu, Julian Satran , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: Dave.B.Anderson@seagate.com Date: Tue, 3 Sep 2002 11:25:15 -0500 X-MIMETrack: Serialize by Router on SV-GW1/Seagate Internet(Release 5.0.8 |June 18, 2001) at 09/03/2002 09:25:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There are no new opcodes or CDB's in SAS. The thing the questioner might be thinking of is the additional SAS task management information located after the header and before the start of the CDB in a command frame. This is unique to SAS, and I would not think it will appear as such in iSCSI. Dave Andre Hedrick , Black_David@emc.com ogies.com> cc: ips@ece.cmu.edu Sent by: Subject: Re: SAS and iSCSI owner-ips@ece.cmu .edu No Phone Info Available 09/02/2002 02:04 PM Julian and David, Thanks for the reply and update, I guess the second part never made it to the reflector. Will the additional opcodes and command descriptor blocks that are definied in SAS be transferred using additional header segements by the iSCSI transport? This assumes there will be new opcodes as SAS is very much ontrack to be an API for array management. Specifically where many of the current management applications of heavily mated to SCSI and SAS is a means to grant them extended life, whereas the hardware is dying. So in order to acommidate such dependencies, the concern is to insure that iSCSI will be adaptable to address their over short comings to be so tightly tied to a transport layer and semi dependent of physical layers. Cheers, Andre Hedrick iSCSI Software Solutions Provider http://www.PyXTechnologies.com/ From owner-ips@ece.cmu.edu Tue Sep 3 13:54:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07224 for ; Tue, 3 Sep 2002 13:54:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83HgwA16083 for ips-outgoing; Tue, 3 Sep 2002 13:42:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (host02.cybernetics.com [206.246.200.18] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83Hgto16078 for ; Tue, 3 Sep 2002 13:42:55 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119054>; Tue, 3 Sep 2002 13:42:41 -0400 Reply-To: From: "Tony Battersby" To: "'Julian Satran \(Actcom\)'" Cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Tue, 3 Sep 2002 13:42:38 -0400 Message-ID: <000e01c25371$4c57d670$e0019d89@cybernetics.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C2534F.C547BD10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <00b201c2507c$0b995480$0100000a@JA31> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C2534F.C547BD10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran (Actcom) Sent: Friday, August 30, 2002 7:22 PM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: aborting an immediate command with ABORT TASK > Immediate commands do not create holes. True. > Immediate commands can be aborted ONLY if referenced by their ITT. Immediate commands are uniquely identified by their ITT, not their CmdSN. So yes, an existing immediate command at the target can be aborted ONLY if the ITT matches the Referenced Task Tag. >Again RefCmdSN is used only if the command is not found by ITT - and then only to avoid having to send a duplicate command. > Julo It seems that the implicit assumption that you are making and I am not is that the target will always find a command with ITT equal to the Referenced Task Tag when the initiator attempts to abort an immediate command. It follows that if this were the case, then the target would never use the RefCmdSN improperly. However, I do not see any mechanism that guarantees this assumption, especially given the following three observations: 1) The possible out-of-order arrival of an abort and the immediate command upon which it is supposed to act 2) The race between an immediate command finishing normally (causing the target to free the command and forget its associated ITT) and the initiator aborting it 3) The immediate command to be aborted may have been discarded due to a header digest error In the examples I gave previously, there are several specific situations in which the assumption does not hold, leading to incorrect behavior of the target. Tony ----- Original Message ----- From: Tony Battersby To: 'Julian Satran' Cc: ips@ece.cmu.edu Sent: 30 August, 2002 21:29 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK In my example, the command with the Initiator Task Tag matching the Referenced Task Tag is not at the target. When the target considers the command with RefCmdSN received, it assumes _incorrectly_ that the command with RefCmdSN must have Initiator Task Tag == Referenced Task Tag. That assumption can be incorrect when immediate commands are used because multiple commands with different Initiator Task Tags can have the same CmdSN. This is just another way of looking at the problem, but the problem still exists. -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 30, 2002 2:15 PM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: aborting an immediate command with ABORT TASK Tony, As it was already pointed out CmSN is a SECONDARY identifier - the primary being the Referenced Task Tag. I was introduced to simplify handling holes (commands discarded or arriving late). In your example A and B have different ITT or one of them gets bumped. Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 30/08/02 20:16 Please respond to tonyb To: cc: Subject: iSCSI: aborting an immediate command with ABORT TASK It seems that an initiator attempting to abort an immediate command may inadvertently cause the next non-immediate command to be aborted instead. For example, Initiator sends an immediate command "A" with CmdSN 10. Initiator sends a non-immediate command "B" with CmdSN 10. Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to abort command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task Tag of "A"). If the target either: 1) Receives "C" before "A" or "B", OR 2) Receives "C" before "B" but after executing and freeing "A", ...then the target will not have a matching task for the abort in its queue, and will consider CmdSN 10 received because it is inside the valid CmdSN window. If the target then receives "B", it will silently ignore the command because it is outside the valid CmdSN window. This is obviously not what the initiator was trying to accomplish. This problem could be solved by adding a flag to the PDU for the ABORT TASK command to indicate if the task to be aborted is immediate or non-immediate. If the target does not have a matching task and the RefCmdSN is inside the valid command window, then the target should consider the CmdSN received only if the flag indicates that the task to be aborted is non-immediate. ----------------------- One other thing: for draft 16, I recommend that the the following phrase: "... (i.e., with CmdSN not higher than the task management command CmdSN) ..." in section 9.5.1 be changed to: "... (i.e., with CmdSN lower than the task management command CmdSN) ...". This is for consistency with another sentence earlier in the same paragraph. Anthony J. Battersby Cybernetics ------=_NextPart_000_000F_01C2534F.C547BD10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran = (Actcom)
Sent:=20 Friday, August 30, 2002 7:22 PM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI:=20 aborting an immediate command with ABORT TASK
 
> Immediate commands do not create = holes.=20
 
True.
 
> Immediate commands can be aborted = ONLY if=20 referenced by their ITT.
 
Immediate commands are uniquely = identified by=20 their ITT, not their CmdSN.  So yes, an existing immediate command at the = target can be=20 aborted ONLY if the ITT matches the = Referenced=20 Task Tag.
 
>Again RefCmdSN is used only if the = command is=20 not found by ITT - and then only to avoid having to send a duplicate=20 command.
>=20 Julo
It = seems that the=20 implicit assumption that you are making and I am not is that the target = will=20 always find a command with ITT equal to the Referenced Task Tag when the = initiator attempts to abort an immediate command.  It follows that = if this=20 were the case, then the target would never use the RefCmdSN = improperly. =20 However, I=20 do not see any mechanism that guarantees this assumption, especially = given the=20 following three observations:
 
1) The possible=20 out-of-order arrival of an abort and the immediate command upon which it = is=20 supposed to act
2) The = race between=20 an immediate command finishing normally (causing the target to free = the=20 command and forget its associated ITT) and the initiator aborting=20 it
3) The = immediate=20 command to be aborted may have been discarded due to a header digest=20 error
 
In the = examples I=20 gave previously, there are several specific situations in which the = assumption does not hold, leading to incorrect behavior of the=20 target.
 
Tony
----- Original Message -----
From:=20 Tony=20 Battersby
Sent: 30 August, 2002 = 21:29
Subject: RE: iSCSI: aborting = an=20 immediate command with ABORT TASK

In = my example,=20 the command with the Initiator Task Tag matching the Referenced Task = Tag is=20 not at the target.  When the target considers the command = with=20 RefCmdSN received, it assumes _incorrectly_ that the command with = RefCmdSN=20 must have Initiator Task Tag =3D=3D Referenced Task Tag.  That = assumption=20 can be incorrect when immediate commands are used because = multiple=20 commands with different Initiator Task Tags can have the same = CmdSN. =20 This is just another way of looking at the = problem, but the = problem still=20 exists.
 
 
  -----Original = Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 30, = 2002=20 2:15 PM
To: tonyb@cybernetics.com
Cc: = ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iSCSI: aborting an = immediate=20 command with ABORT TASK

Tony,

As it = was already=20 pointed out CmSN is a SECONDARY identifier - the primary being the=20 Referenced Task Tag.
I = was=20 introduced to simplify handling holes (commands discarded or = arriving=20 late).
In your example A = and B have=20 different ITT or one of them gets bumped.

Julo



"Tony Battersby"=20 <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu=20

30/08/02 20:16 =
Please respond to tonyb =

       =20
    =    =20 To:        <ips@ece.cmu.edu>=20
      =   cc:=20        
        Subject:     =  =20  iSCSI: aborting an immediate command with ABORT = TASK=20

     =20  


It seems that an initiator attempting to abort an immediate = command=20 may
inadvertently cause the next non-immediate command to be = aborted=20 instead.
For example,

Initiator sends an immediate command = "A"=20 with CmdSN 10.
Initiator sends a non-immediate command "B" with = CmdSN=20 10.
Initiator sends an immediate ABORT TASK command "C" with = CmdSN 11 to=20 abort
command "A" (RefCmdSN =3D=3D 10, Referenced Task Tag =3D=3D = Initiator Task=20 Tag of
"A").

If the target either:
1) Receives "C" = before "A"=20 or "B", OR
2) Receives "C" before "B" but after executing and = freeing=20 "A",

...then the target will not have a matching task for the = abort=20 in its queue,
and will consider CmdSN 10 received because it is = inside=20 the valid CmdSN
window.  If the target then receives "B", it = will=20 silently ignore the
command because it is outside the valid CmdSN = window.=20  This is obviously not
what the initiator was trying to=20 accomplish.

This problem could be solved by adding a flag to = the PDU=20 for the ABORT TASK
command to indicate if the task to be aborted = is=20 immediate or non-immediate.
If the target does not have a = matching task=20 and the RefCmdSN is inside the
valid command window, then the = target=20 should consider the CmdSN received
only if the flag indicates = that the=20 task to be aborted is=20 non-immediate.

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

One other = thing: for=20 draft 16, I recommend that the the following phrase:
"... (i.e., = with=20 CmdSN not higher than the task management command = CmdSN)
..."
in=20 section 9.5.1 be changed to:
"... (i.e., with CmdSN lower than = the task=20 management command CmdSN) ...".
This is for consistency with = another=20 sentence earlier in the same paragraph.


Anthony J.=20 = Battersby
Cybernetics



------=_NextPart_000_000F_01C2534F.C547BD10-- From owner-ips@ece.cmu.edu Tue Sep 3 13:55:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07272 for ; Tue, 3 Sep 2002 13:55:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83HlY016477 for ips-outgoing; Tue, 3 Sep 2002 13:47:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83HlUo16457 for ; Tue, 3 Sep 2002 13:47:30 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g83HlLA23044; Tue, 3 Sep 2002 13:47:21 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g83HlK726882; Tue, 3 Sep 2002 13:47:20 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 13:47:20 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C263@CORPMX14> From: Black_David@emc.com To: bhushan_vadulas@hotmail.com, ips@ece.cmu.edu Subject: RE: Logical Block address in iSCSI CDB Date: Tue, 3 Sep 2002 13:47:08 -0400 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 > My doubt is.... Do the logical block address contained in > SCSI CDB inside ISCSI PDUs are actual address of the remote disk. > Can we change that ???? Yes and no in that order. > What I am trying to do is,....... > > If SCSI sends only 2 block or 3 blocks, wait and collect data upto 16 > blocks (Usual max PDU of ISCSI) and send them over the network so that it > will reduce the header over-head. That sort of thing is usually called a proxy. Proxies can do anything they want, but have to take full responsibility for the results (e.g., if multiple SCSI operations have been combined into a single iSCSI operation, when the iSCSI response comes back, it has to be split into the individual responses that SCSI expects to its individual operations. iSCSI (like SCSI) generally does not support scatter-gather over the wire - the blocks in an individual read or write operation generally have to be contiguous. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 3 17:11:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14441 for ; Tue, 3 Sep 2002 17:11:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83KZeX02969 for ips-outgoing; Tue, 3 Sep 2002 16:35:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83KZao02961 for ; Tue, 3 Sep 2002 16:35:36 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g83KZQH31502; Tue, 3 Sep 2002 16:35:26 -0400 Message-ID: <3D751D10.2DA7E776@splentec.com> Date: Tue, 03 Sep 2002 16:35:28 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: shesha bhushan CC: ips@ece.cmu.edu Subject: Re: Logical Block address in iSCSI CDB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit shesha bhushan wrote: > > What I am trying to do is,....... > > If SCSI sends only 2 block or 3 blocks, wait and collect data upto 16 > blocks (Usual max PDU of ISCSI) and send them over the network so that it > will reduce the header over-head. > An iSCSI implementations should support clustering of requests. Clustering of requests goes hand in hand with the elevator algorithm. (<>) The Linux block layer and SCSI core, support clustering and the IOL/UNH implementation (which is the one you are using) should _enable_ it (please don't tell me if it does/doesn't -- I don't care). Please note that you are saying ``... wait and collect ...'', at which point you've overruled an implementation of being fast. Please further note, that as an interconnect/transport, iSCSI has NOTHING to do with any of this. Please also don't assume the size of a ``block'' and the size of the iSCSI PDU. A self-respecting OS should've optimized the requests before submitting them down to the interconnect driver (FC/SPI/iSCSI/etc). Linux would do that for you if you've enabled clustering. Thus if speed is what you're after, I'd suggest you use a commercial iSCSI solution. -- Luben P.S. Please just let us know what you are _actually_ trying to do, rather than putting ellipsis at the end of your sentence. I certainly hope you are not trying to do your assignment, else we should NOT be replying to you. We could give you a lot more and invaluable help rather than you asking details and trying to put their answers together. From owner-ips@ece.cmu.edu Tue Sep 3 17:13:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14494 for ; Tue, 3 Sep 2002 17:13:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83Kn8K04109 for ips-outgoing; Tue, 3 Sep 2002 16:49:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (host02.cybernetics.com [206.246.200.18] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83Kn6o04103 for ; Tue, 3 Sep 2002 16:49:06 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119054>; Tue, 3 Sep 2002 16:48:57 -0400 Reply-To: From: "Tony Battersby" To: "'Julian Satran \(Actcom\)'" Cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Tue, 3 Sep 2002 16:48:52 -0400 Message-ID: <001901c2538b$50846a50$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <000e01c25371$4c57d670$e0019d89@cybernetics.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 1) The possible out-of-order arrival of an abort and the immediate command upon which > it is supposed to act > 2) The race between an immediate command finishing normally (causing the target > to free the command and forget its associated ITT) and the initiator aborting it > 3) The immediate command to be aborted may have been discarded due to a header digest > error Replying to myself, #1 should actually not happen because of the requirement for an ABORT TASK to be issued on the same connection to which the task being acted upon is currently allegiant. Points #2 and #3 are still valid though. Another possibility is that the target is in the process of sending a Reject PDU for the immediate command to be aborted when it receives the ABORT TASK command, and the target implementation doesn't check the ITT from a PDU that it has chosen to reject. Tony From owner-ips@ece.cmu.edu Tue Sep 3 18:09:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15953 for ; Tue, 3 Sep 2002 18:09:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83LVmU07259 for ips-outgoing; Tue, 3 Sep 2002 17:31:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83LVjo07254 for ; Tue, 3 Sep 2002 17:31:45 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 17:31:29 -0400 Message-ID: From: Eddy Quicksall To: "'shesha bhushan'" , cdeng@iol.unh.edu, ips@ece.cmu.edu, qtao@iol.unh.edu, rdr@iol.unh.edu Subject: RE: Logical Block address in iSCSI CDB Date: Tue, 3 Sep 2002 17:31:29 -0400 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 What you are asking for is usually done at a slightly higher level than the device driver. This is very common at the caching level (at least in embedded systems). So something like iSCSI gets it for free. Device drivers in lower end systems (like DOS) actually did this. So, if you are writing iSCSI for DOS, you may want to put this in your device driver. :) Eddy -----Original Message----- From: shesha bhushan [mailto:bhushan_vadulas@hotmail.com] Sent: Tuesday, September 03, 2002 1:13 PM To: cdeng@iol.unh.edu; ips@ece.cmu.edu; qtao@iol.unh.edu; rdr@iol.unh.edu Subject: Logical Block address in iSCSI CDB Hi, I established a full feature phase in ISCSI and mounted a disk from a remote machine. I copied a file from my local file system to the mounted disk. SCSI issues a series of Write commands that are encapsulated inside ISCSI PDUs. My doubt is.... Do the logical block address contained in SCSI CDB inside ISCSI PDUs are actual address of the remote disk. Can we change that ???? What I am trying to do is,....... If SCSI sends only 2 block or 3 blocks, wait and collect data upto 16 blocks (Usual max PDU of ISCSI) and send them over the network so that it will reduce the header over-head. Any suggestions and indeas are highly appertiated. Thanking You Shesha Arizona State University. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ips@ece.cmu.edu Tue Sep 3 19:38:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17310 for ; Tue, 3 Sep 2002 19:38:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83MwKw13049 for ips-outgoing; Tue, 3 Sep 2002 18:58:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f25.pav2.hotmail.com [64.4.37.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83KUio02582 for ; Tue, 3 Sep 2002 16:30:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Sep 2002 13:30:38 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 03 Sep 2002 20:30:37 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: ips@ece.cmu.edu Subject: Logical Block Addresses in SCSI Date: Tue, 03 Sep 2002 20:30:37 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Sep 2002 20:30:38.0137 (UTC) FILETIME=[C38ED290:01C25388] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi All, I have mounted a remote directory and created a file. So this will generate SCSI WRITE CDBs that contain Logical Block Addresses (LBA) which is encapsulated in an ISCSI command PDU. How did SCSI at the local system generate a valid LBA for the remote disk? I appertiate all your answers. Thanking You Shesha _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ips@ece.cmu.edu Tue Sep 3 19:38:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17328 for ; Tue, 3 Sep 2002 19:38:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83NOWa14436 for ips-outgoing; Tue, 3 Sep 2002 19:24:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83NOVo14431 for ; Tue, 3 Sep 2002 19:24:31 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 19:24:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C269@CORPMX14> From: Black_David@emc.com To: bhushan_vadulas@hotmail.com, ips@ece.cmu.edu Subject: RE: Logical Block Addresses in SCSI Date: Tue, 3 Sep 2002 19:24:17 -0400 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 > I have mounted a remote directory and created a file. So this will generate > SCSI WRITE CDBs that contain Logical Block Addresses (LBA) which is > encapsulated in an ISCSI command PDU. How did SCSI at the local system > generate a valid LBA for the remote disk? SCSI didn't - the filesystem at the local system read the filesystem metadata and the directory and decided what blocks to use for the file you created. The LBA numbers were generated by the filesystem. SCSI doesn't understand the concept of files. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 3 19:39:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17350 for ; Tue, 3 Sep 2002 19:39:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g83NLGu14252 for ips-outgoing; Tue, 3 Sep 2002 19:21:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g83NLFo14247 for ; Tue, 3 Sep 2002 19:21:15 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g83NL5Q24448; Tue, 3 Sep 2002 19:21:06 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g83NL5719668; Tue, 3 Sep 2002 19:21:05 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 19:21:05 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C268@CORPMX14> From: Black_David@emc.com To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Tue, 3 Sep 2002 19:20:55 -0400 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 Tony, > > 1) The possible out-of-order arrival of an abort and the immediate command > > upon which it is supposed to act > > 2) The race between an immediate command finishing normally > > (causing the target to free the command and forget its associated ITT) > > and the initiator aborting it > > 3) The immediate command to be aborted may have been > > discarded due to a header digest error > > Replying to myself, #1 should actually not happen because of the requirement > for an ABORT TASK to be issued on the same connection to which the task > being acted upon is currently allegiant. Points #2 and #3 are still valid > though. That's not correct. In case 2) the ABORT TASK always succeeds no matter how the race turns out - SAM-2 Section 6.2 says: If the logical unit supports this function, a response of FUNCTION COMPLETE shall indicate that the task was aborted or was not in the task set. The words "or was not in the task set" are the crucial ones. In case 2), the ABORT TASK always returns FUNCTION COMPLETE, and there may or may not be a response from the aborted task prior to that FUNCTION COMPLETE, but there MUST NOT be one afterwards. The analysis for 3) is similar - if the command to be aborted was discarded due to a header digest error, the ABORT TASK still succeeds because the task "was not in the task set". > Another possibility is that the target is in the process of sending > a Reject PDU for the immediate command to be aborted when it receives the > ABORT TASK command, and the target implementation doesn't check the ITT from > a PDU that it has chosen to reject. Yet another similar analysis - the ABORT TASK succeeds whether it was received before or after the Reject PDU was sent. Similar to the above, the Reject PDU MUST NOT follow the response to the ABORT TASK. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Sep 4 02:35:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18746 for ; Wed, 4 Sep 2002 02:35:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g845tPV03573 for ips-outgoing; Wed, 4 Sep 2002 01:55:25 -0400 (EDT) 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 g845tNo03568 for ; Wed, 4 Sep 2002 01:55:23 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g845tGVb026652; Wed, 4 Sep 2002 07:55:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g845tG6d052282; Wed, 4 Sep 2002 07:55:16 +0200 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI version 16 draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 4 Sep 2002 08:55:13 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/09/2002 08:55:16, Serialize complete at 04/09/2002 08:55:16 Content-Type: multipart/alternative; boundary="=_alternative 001F8C1DC2256C2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001F8C1DC2256C2A_= Content-Type: text/plain; charset="us-ascii" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.pdf This version completely replaces: draft-ietf-ips-iscsi-15.txt and pdf This version includes all editorial changes required during the WG last call and DOES NOT HAVE a change log. Please pay attention to all reserved and fixed field values as some have changes required to ensure simplicity and consistency have caused some pain to some implementations lately. Julian Satran - IBM Research Laboratory at Haifa --=_alternative 001F8C1DC2256C2A_= Content-Type: text/html; charset="us-ascii"



On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.pdf


This version completely replaces:

draft-ietf-ips-iscsi-15.txt and pdf



This version includes all editorial changes required during the WG last call and DOES NOT HAVE a change log.
Please pay attention to all reserved and fixed field values as some have changes required to ensure simplicity and consistency
have caused some pain to some implementations lately.

Julian Satran - IBM Research Laboratory at Haifa































--=_alternative 001F8C1DC2256C2A_=-- From owner-ips@ece.cmu.edu Wed Sep 4 09:55:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29772 for ; Wed, 4 Sep 2002 09:55:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g84DBw406133 for ips-outgoing; Wed, 4 Sep 2002 09:11:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g84DBuo06129 for ; Wed, 4 Sep 2002 09:11:56 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119044>; Wed, 4 Sep 2002 09:11:41 -0400 Reply-To: From: "Tony Battersby" To: Cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Wed, 4 Sep 2002 09:11:39 -0400 Message-ID: <001c01c25414$9b91fbf0$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C268@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Black_David@emc.com > Sent: Tuesday, September 03, 2002 7:21 PM > To: tonyb@cybernetics.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > Tony, > > > > 2) The race between an immediate command finishing normally > > > (causing the target to free the command and forget its > associated ITT) > > > and the initiator aborting it > > That's not correct. In case 2) the ABORT TASK always succeeds no > matter how the race turns out - SAM-2 Section 6.2 says: > > If the logical unit supports this function, a response of > FUNCTION COMPLETE shall indicate that the task was aborted > or was not in the task set. > > The words "or was not in the task set" are the crucial ones. In > case 2), the ABORT TASK always returns FUNCTION COMPLETE, and > there may > or may not be a response from the aborted task prior to that FUNCTION > COMPLETE, but there MUST NOT be one afterwards. I am not really concerned about the response code to the ABORT TASK. My concern is that the initiator may end up plugging a CmdSN hole when it shouldn't. From Section 9.6.1 (draft 15), "...targets must consider the CmdSN received and return the "Function complete" response." I don't have a problem with returning the "Function complete" response. I do have a problem with the target considering the CmdSN received if the initiator intended to abort an immediate command. Tony From owner-ips@ece.cmu.edu Wed Sep 4 09:58:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29971 for ; Wed, 4 Sep 2002 09:58:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g84Dige08558 for ips-outgoing; Wed, 4 Sep 2002 09:44:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g84Dido08545 for ; Wed, 4 Sep 2002 09:44:39 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g84DiSZ0010730; Wed, 4 Sep 2002 15:44:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g84DiSPC073038; Wed, 4 Sep 2002 15:44:28 +0200 To: Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 4 Sep 2002 16:44:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/09/2002 16:44:28, Serialize complete at 04/09/2002 16:44:28 Content-Type: multipart/alternative; boundary="=_alternative 004ADA34C2256C2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004ADA34C2256C2A_= Content-Type: text/plain; charset="us-ascii" The plug-in is meant to avoid having to resend the missing command. This is also the reason for mandating ABORT TASK on the same connection! Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 04/09/02 16:11 Please respond to tonyb To: cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Black_David@emc.com > Sent: Tuesday, September 03, 2002 7:21 PM > To: tonyb@cybernetics.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > Tony, > > > > 2) The race between an immediate command finishing normally > > > (causing the target to free the command and forget its > associated ITT) > > > and the initiator aborting it > > That's not correct. In case 2) the ABORT TASK always succeeds no > matter how the race turns out - SAM-2 Section 6.2 says: > > If the logical unit supports this function, a response of > FUNCTION COMPLETE shall indicate that the task was aborted > or was not in the task set. > > The words "or was not in the task set" are the crucial ones. In > case 2), the ABORT TASK always returns FUNCTION COMPLETE, and > there may > or may not be a response from the aborted task prior to that FUNCTION > COMPLETE, but there MUST NOT be one afterwards. I am not really concerned about the response code to the ABORT TASK. My concern is that the initiator may end up plugging a CmdSN hole when it shouldn't. From Section 9.6.1 (draft 15), "...targets must consider the CmdSN received and return the "Function complete" response." I don't have a problem with returning the "Function complete" response. I do have a problem with the target considering the CmdSN received if the initiator intended to abort an immediate command. Tony --=_alternative 004ADA34C2256C2A_= Content-Type: text/html; charset="us-ascii"
The plug-in is meant to avoid having to resend the missing command.
This is also the reason for mandating ABORT TASK on the same connection!

Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

04/09/02 16:11
Please respond to tonyb

       
        To:        <Black_David@emc.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Black_David@emc.com
> Sent: Tuesday, September 03, 2002 7:21 PM
> To: tonyb@cybernetics.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI: aborting an immediate command with ABORT TASK
>
>
> Tony,
>

> > > 2) The race between an immediate command finishing normally
> > > (causing the target to free the command and forget its
> associated ITT)
> > >  and the initiator aborting it

>
> That's not correct.  In case 2) the ABORT TASK always succeeds no
> matter how the race turns out - SAM-2 Section 6.2 says:
>
>                  If the logical unit supports this function, a response of
>                  FUNCTION COMPLETE shall indicate that the task was aborted
>                  or was not in the task set.
>
> The words "or was not in the task set" are the crucial ones.  In
> case 2), the ABORT TASK always returns FUNCTION COMPLETE, and
> there may
> or may not be a response from the aborted task prior to that FUNCTION
> COMPLETE, but there MUST NOT be one afterwards.

I am not really concerned about the response code to the ABORT TASK.  My
concern is that the initiator may end up plugging a CmdSN hole when it
shouldn't.  From Section 9.6.1 (draft 15),

"...targets must consider the CmdSN received and return the "Function
complete" response."

I don't have a problem with returning the "Function complete" response.  I
do have a problem with the target considering the CmdSN received if the
initiator intended to abort an immediate command.

Tony

--=_alternative 004ADA34C2256C2A_=-- From owner-ips@ece.cmu.edu Wed Sep 4 10:54:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03278 for ; Wed, 4 Sep 2002 10:54:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g84EKdP11298 for ips-outgoing; Wed, 4 Sep 2002 10:20:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g84EKao11286 for ; Wed, 4 Sep 2002 10:20:36 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119049>; Wed, 4 Sep 2002 10:20:30 -0400 Reply-To: From: "Tony Battersby" To: "'Julian Satran'" Cc: , Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Wed, 4 Sep 2002 10:20:28 -0400 Message-ID: <001f01c2541e$3856f450$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, September 04, 2002 9:44 AM To: tonyb@cybernetics.com Cc: Black_David@emc.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > The plug-in is meant to avoid having to resend the missing command. If the missing command was non-immediate, then yes, the plug-in avoids having to resend the missing command. But, if the missing command was immediate, then there is no hole to plug. In this case, the spec requires the target to plug a hole which does not exist, which is the problem that I am trying to point out. Tony From owner-ips@ece.cmu.edu Wed Sep 4 13:27:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11860 for ; Wed, 4 Sep 2002 13:27:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g84Geca21989 for ips-outgoing; Wed, 4 Sep 2002 12:40:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g84GeYo21983 for ; Wed, 4 Sep 2002 12:40:35 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 9234A30706; Wed, 4 Sep 2002 12:40:34 -0400 (EDT) Date: Wed, 4 Sep 2002 09:34:06 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: shesha bhushan Cc: Subject: Re: Logical Block Addresses in SCSI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 3 Sep 2002, shesha bhushan wrote: > Hi All, > > I have mounted a remote directory and created a file. So this will generate > SCSI WRITE CDBs that contain Logical Block Addresses (LBA) which is > encapsulated in an ISCSI command PDU. How did SCSI at the local system > generate a valid LBA for the remote disk? This question is off-topic for this list. As others have said, a layer above the iSCSI layer will have handed us the LBAs. Is your question, "How did SCSI at the local system generate a[n] LBA" or "... a valid LBA"? The first question has to do with the file system. The file system knew it had a given amount of space, and generated write operations (say wrote blocks in the buffer cache) at specific offsets in its partition. It is a very simple transform to go from the offsets of those blocks in the partition to blocks on the disk (you add the partition offset). So writing blocks in the buffer cache (or pages in the VM system, depends on kernel design) readily turns into writing blocks on the disk. This question really is about file systems and buffer caches. How you get "valid" LBAs is either you have a partition map that says you can access up to a given maximum, or you just try the command and see what happens. This question really is about disk labels. Take care, Bill From owner-ips@ece.cmu.edu Thu Sep 5 03:46:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12131 for ; Thu, 5 Sep 2002 03:46:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g856p6V08913 for ips-outgoing; Thu, 5 Sep 2002 02:51:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g856p5o08907 for ; Thu, 5 Sep 2002 02:51:05 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g856oqi25454; Thu, 5 Sep 2002 02:50:53 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g856oq703456; Thu, 5 Sep 2002 02:50:52 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 02:50:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C27C@CORPMX14> From: Black_David@emc.com To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 02:50:51 -0400 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 This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 5 09:00:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17702 for ; Thu, 5 Sep 2002 09:00:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85CFuC04318 for ips-outgoing; Thu, 5 Sep 2002 08:15:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85BKmo02260 for ; Thu, 5 Sep 2002 07:20:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15054; Thu, 5 Sep 2002 07:18:57 -0400 (EDT) Message-Id: <200209051118.HAA15054@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-15.txt,.pdf Date: Thu, 05 Sep 2002 07:18:56 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-15.txt,.pdf Pages : 283 Date : 2002-9-4 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-4143159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-4143159.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Sep 5 09:01:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17725 for ; Thu, 5 Sep 2002 09:01:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85CkbK05621 for ips-outgoing; Thu, 5 Sep 2002 08:46:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85CkYo05613 for ; Thu, 5 Sep 2002 08:46:34 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 08:46:34 -0400 Message-ID: From: Eddy Quicksall To: "'Black_David@emc.com'" , tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 08:46:31 -0400 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 Can we say that aborts with the immediate bit only abort commands with the immediate bit? And then say that the window is not advanced under that situation? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 05, 2002 2:51 AM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 5 09:09:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17981 for ; Thu, 5 Sep 2002 09:09:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85CQu404798 for ips-outgoing; Thu, 5 Sep 2002 08:26:56 -0400 (EDT) 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 g85CQso04792 for ; Thu, 5 Sep 2002 08:26:54 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85CQhBM067828; Thu, 5 Sep 2002 14:26:43 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85CQgBC015150; Thu, 5 Sep 2002 14:26:43 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com MIME-Version: 1.0 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 5 Sep 2002 15:26:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 15:26:43, Serialize complete at 05/09/2002 15:26:43 Content-Type: multipart/alternative; boundary="=_alternative 00436687C2256C2B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00436687C2256C2B_= Content-Type: text/plain; charset="us-ascii" The next command can't be clobered. Abort Task acts on command up to 6 (included) but not 7- and it has to be on the same connection as the aborted command. That insures that it will abort the first immediate but not the non-immediate after. As for the mapping - you are right - I'll mark it for the final edit (whenever that happens). Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 05/09/02 09:50 To: tonyb@cybernetics.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- --=_alternative 00436687C2256C2B_= Content-Type: text/html; charset="us-ascii"
The next command can't be clobered. Abort Task acts on command  up to 6 (included) but not 7- and it has to be on the same
connection as the aborted command. That insures that it will abort the first immediate but not the non-immediate after.

As for the mapping - you are right - I'll mark it for the final edit (whenever that happens).

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

05/09/02 09:50

       
        To:        tonyb@cybernetics.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


This thread's taken a while to sort through, but there
does appear to be a problem in here.

> If the missing command was non-immediate, then yes, the plug-in avoids
> having to resend the missing command.  But, if the missing command was
> immediate, then there is no hole to plug.  In this case, the spec requires
> the target to plug a hole which does not exist, which is the problem that
I
> am trying to point out.

I'm working off of -15.  Section 2.2.2.1 contains the following statements:

                CmdSN always contains the number to be
     assigned to the next Command PDU.

  Commands meant for immediate delivery are marked with an immediate
  delivery flag; they MUST also carry the current CmdSN.

So suppose CmdSN is 7, and the initiator sends an immediate command
with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
ABORT crosses the response to successful completion of the immediate
command on the wire.  At this point the following text in Section
9.6.1 applies:

    b)  if the Referenced Task Tag does not identify an existing task
    but if the CmdSN indicated by the RefCmdSN field in the Task Man-
     agement function request is within the valid CmdSN window (between
     MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
     and return the "Function complete" response.

7 is still the CmdSN of the next non-immediate command to be sent,
so it is within the window (ExpCmdSN is also 7).  Following these
directions, the Target considers CmdSN 7 to be received, and advances
its window.  Now, when the initiator sends its next non-immediate
command (CmdSN=7), its CmdSN is outside the window, and the target
bit-buckets the command instead of executing it.

This went awry because the task to be aborted was (implicitly)
identified by its CmdSN, and not its Task Tag resulting in an attempt
to abort an immediate command actually clobbering the next non-
immediate one.  I think Tony gets credit for finding another problem.

While I'm in here, it also appears that the text describing the
mapping of iSCSI task management response codes to SCSI service
responses needs to change to map 1 (Task does not exist) to
FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
Section 6.2 of SAM-2.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

--=_alternative 00436687C2256C2B_=-- From owner-ips@ece.cmu.edu Thu Sep 5 09:41:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19037 for ; Thu, 5 Sep 2002 09:41:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85D2TJ06555 for ips-outgoing; Thu, 5 Sep 2002 09:02:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85D2Oo06548; Thu, 5 Sep 2002 09:02:24 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 09:02:24 -0400 Message-ID: From: Eddy Quicksall To: "'Julian Satran'" , Eddy Quicksall Cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 09:02:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C254DC.76B64430" 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_01C254DC.76B64430 Content-Type: text/plain; charset="iso-8859-1" How about another bit in the abort that says it is aborting an immediate command and hence does not advance the window? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 9:00 AM To: Eddy Quicksall Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration. And there are no known scenarios (to us) in which it does not work. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 05/09/02 15:46 To: "'Black_David@emc.com'" , tonyb@cybernetics.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Can we say that aborts with the immediate bit only abort commands with the immediate bit? And then say that the window is not advanced under that situation? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 05, 2002 2:51 AM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- ------_=_NextPart_001_01C254DC.76B64430 Content-Type: text/html; charset="iso-8859-1"
How about another bit in the abort that says it is aborting an immediate command and hence does not advance the window?
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 9:00 AM
To: Eddy Quicksall
Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration.
And there are no known scenarios (to us) in which it does not work.

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

05/09/02 15:46

       
        To:        "'Black_David@emc.com'" <Black_David@emc.com>, tonyb@cybernetics.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


Can we say that aborts with the immediate bit only abort commands with the
immediate bit? And then say that the window is not advanced under that
situation?

Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, September 05, 2002 2:51 AM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


This thread's taken a while to sort through, but there
does appear to be a problem in here.

> If the missing command was non-immediate, then yes, the plug-in avoids
> having to resend the missing command.  But, if the missing command was
> immediate, then there is no hole to plug.  In this case, the spec requires
> the target to plug a hole which does not exist, which is the problem that
I
> am trying to point out.

I'm working off of -15.  Section 2.2.2.1 contains the following statements:

                CmdSN always contains the number to be
     assigned to the next Command PDU.

  Commands meant for immediate delivery are marked with an immediate
  delivery flag; they MUST also carry the current CmdSN.

So suppose CmdSN is 7, and the initiator sends an immediate command
with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
ABORT crosses the response to successful completion of the immediate
command on the wire.  At this point the following text in Section
9.6.1 applies:

    b)  if the Referenced Task Tag does not identify an existing task
    but if the CmdSN indicated by the RefCmdSN field in the Task Man-
     agement function request is within the valid CmdSN window (between
     MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
     and return the "Function complete" response.

7 is still the CmdSN of the next non-immediate command to be sent,
so it is within the window (ExpCmdSN is also 7).  Following these
directions, the Target considers CmdSN 7 to be received, and advances
its window.  Now, when the initiator sends its next non-immediate
command (CmdSN=7), its CmdSN is outside the window, and the target
bit-buckets the command instead of executing it.

This went awry because the task to be aborted was (implicitly)
identified by its CmdSN, and not its Task Tag resulting in an attempt
to abort an immediate command actually clobbering the next non-
immediate one.  I think Tony gets credit for finding another problem.

While I'm in here, it also appears that the text describing the
mapping of iSCSI task management response codes to SCSI service
responses needs to change to map 1 (Task does not exist) to
FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
Section 6.2 of SAM-2.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


------_=_NextPart_001_01C254DC.76B64430-- From owner-ips@ece.cmu.edu Thu Sep 5 09:42:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19078 for ; Thu, 5 Sep 2002 09:42:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85DMxV07606 for ips-outgoing; Thu, 5 Sep 2002 09:22:59 -0400 (EDT) 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 g85DMuo07598 for ; Thu, 5 Sep 2002 09:22:56 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85DMkVb071610; Thu, 5 Sep 2002 15:22:47 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85DMiBC097412; Thu, 5 Sep 2002 15:22:44 +0200 To: Eddy Quicksall Cc: "'Black_David@emc.com'" , Eddy Quicksall , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com MIME-Version: 1.0 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 5 Sep 2002 16:22:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 16:22:44, Serialize complete at 05/09/2002 16:22:44 Content-Type: multipart/alternative; boundary="=_alternative 0048D431C2256C2B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0048D431C2256C2B_= Content-Type: text/plain; charset="us-ascii" No need - it works always as it is. An immediate is aborted based on ITT or not at all. Add to it the fact that they are on the same connection and immediates are not reassigned and everything works AS IS. What am I missing? Julo Eddy Quicksall 05/09/02 16:02 To: Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK How about another bit in the abort that says it is aborting an immediate command and hence does not advance the window? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 9:00 AM To: Eddy Quicksall Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration. And there are no known scenarios (to us) in which it does not work. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 05/09/02 15:46 To: "'Black_David@emc.com'" , tonyb@cybernetics.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Can we say that aborts with the immediate bit only abort commands with the immediate bit? And then say that the window is not advanced under that situation? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 05, 2002 2:51 AM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- --=_alternative 0048D431C2256C2B_= Content-Type: text/html; charset="us-ascii"
No need - it works always as it is. An immediate is aborted based on ITT or not at all.
Add to it the fact that they are on the same connection and immediates are not reassigned
and everything works AS IS.
What am I missing?

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

05/09/02 16:02

       
        To:        Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall <eddy_quicksall@ivivity.com>
        cc:        "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


How about another bit in the abort that says it is aborting an immediate command and hence does not advance the window?
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 9:00 AM
To: Eddy Quicksall
Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration.
And there are no known scenarios (to us) in which it does not work.

Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

05/09/02 15:46

       
       To:        "'Black_David@emc.com'" <Black_David@emc.com>, tonyb@cybernetics.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

     



Can we say that aborts with the immediate bit only abort commands with the
immediate bit? And then say that the window is not advanced under that
situation?

Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, September 05, 2002 2:51 AM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


This thread's taken a while to sort through, but there
does appear to be a problem in here.

> If the missing command was non-immediate, then yes, the plug-in avoids
> having to resend the missing command.  But, if the missing command was
> immediate, then there is no hole to plug.  In this case, the spec requires
> the target to plug a hole which does not exist, which is the problem that
I
> am trying to point out.

I'm working off of -15.  Section 2.2.2.1 contains the following statements:

               CmdSN always contains the number to be
    assigned to the next Command PDU.

 Commands meant for immediate delivery are marked with an immediate
 delivery flag; they MUST also carry the current CmdSN.

So suppose CmdSN is 7, and the initiator sends an immediate command
with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
ABORT crosses the response to successful completion of the immediate
command on the wire.  At this point the following text in Section
9.6.1 applies:

   b)  if the Referenced Task Tag does not identify an existing task
   but if the CmdSN indicated by the RefCmdSN field in the Task Man-
    agement function request is within the valid CmdSN window (between
    MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
    and return the "Function complete" response.

7 is still the CmdSN of the next non-immediate command to be sent,
so it is within the window (ExpCmdSN is also 7).  Following these
directions, the Target considers CmdSN 7 to be received, and advances
its window.  Now, when the initiator sends its next non-immediate
command (CmdSN=7), its CmdSN is outside the window, and the target
bit-buckets the command instead of executing it.

This went awry because the task to be aborted was (implicitly)
identified by its CmdSN, and not its Task Tag resulting in an attempt
to abort an immediate command actually clobbering the next non-
immediate one.  I think Tony gets credit for finding another problem.

While I'm in here, it also appears that the text describing the
mapping of iSCSI task management response codes to SCSI service
responses needs to change to map 1 (Task does not exist) to
FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
Section 6.2 of SAM-2.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

--=_alternative 0048D431C2256C2B_=-- From owner-ips@ece.cmu.edu Thu Sep 5 09:43:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19183 for ; Thu, 5 Sep 2002 09:43:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85DO0I07679 for ips-outgoing; Thu, 5 Sep 2002 09:24:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85DNvo07675 for ; Thu, 5 Sep 2002 09:23:57 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119041>; Thu, 5 Sep 2002 09:23:45 -0400 Reply-To: From: "Tony Battersby" To: "'Julian Satran'" , Cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 09:23:43 -0400 Message-ID: <003201c254df$752c6880$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 8:27 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > The next command can't be clobered. Abort Task acts on command up to 6 > (included) but not 7- and it has to be on the same connection as the > aborted command. That insures that it will abort the first immediate but > not the non-immediate after. Ok, here's the gotcha: The initiator sends a non-immediate command with CmdSN 7 on a different connection before sending the immediate ABORT TASK for the first immediate command. The ABORT TASK is sent on the same connection as the immediate command with CmdSN 7 to be aborted, but a different connection than the non-immediate command with CmdSN 7. The ABORT TASK will carry a CmdSN of 8, and the target may receive the ABORT TASK before it receives the non-immediate command with CmdSN 7, because they are sent on different connections. If this happens, the target considers CmdSN 7 received and then discards the non-immediate command with CmdSN 7 when it finishes receiving it on the other connection. Tricky, tricky, tricky... Tony From owner-ips@ece.cmu.edu Thu Sep 5 09:43:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19201 for ; Thu, 5 Sep 2002 09:43:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85DS0Z07863 for ips-outgoing; Thu, 5 Sep 2002 09:28:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85DRvo07856 for ; Thu, 5 Sep 2002 09:27:57 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119041>; Thu, 5 Sep 2002 09:27:44 -0400 Reply-To: From: "Tony Battersby" To: "'Eddy Quicksall'" , "'Julian Satran'" Cc: , Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 09:27:42 -0400 Message-ID: <003701c254e0$0458ef60$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, September 05, 2002 9:02 AM To: 'Julian Satran'; Eddy Quicksall Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > How about another bit in the abort that says it is aborting an > immediate command and hence does not advance the window? I also recommended that in the message that started this thread. That solution has my approval. Tony From owner-ips@ece.cmu.edu Thu Sep 5 09:43:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19234 for ; Thu, 5 Sep 2002 09:43:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85D0o706376 for ips-outgoing; Thu, 5 Sep 2002 09:00:50 -0400 (EDT) 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 g85D0go06356 for ; Thu, 5 Sep 2002 09:00:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85D0VVb069812; Thu, 5 Sep 2002 15:00:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85D0VXH096304; Thu, 5 Sep 2002 15:00:31 +0200 To: Eddy Quicksall Cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com MIME-Version: 1.0 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 5 Sep 2002 16:00:20 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 16:00:31, Serialize complete at 05/09/2002 16:00:31 Content-Type: multipart/alternative; boundary="=_alternative 0046BD5DC2256C2B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0046BD5DC2256C2B_= Content-Type: text/plain; charset="us-ascii" I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration. And there are no known scenarios (to us) in which it does not work. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 05/09/02 15:46 To: "'Black_David@emc.com'" , tonyb@cybernetics.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Can we say that aborts with the immediate bit only abort commands with the immediate bit? And then say that the window is not advanced under that situation? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 05, 2002 2:51 AM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- --=_alternative 0046BD5DC2256C2B_= Content-Type: text/html; charset="us-ascii"
I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration.
And there are no known scenarios (to us) in which it does not work.

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

05/09/02 15:46

       
        To:        "'Black_David@emc.com'" <Black_David@emc.com>, tonyb@cybernetics.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


Can we say that aborts with the immediate bit only abort commands with the
immediate bit? And then say that the window is not advanced under that
situation?

Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, September 05, 2002 2:51 AM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


This thread's taken a while to sort through, but there
does appear to be a problem in here.

> If the missing command was non-immediate, then yes, the plug-in avoids
> having to resend the missing command.  But, if the missing command was
> immediate, then there is no hole to plug.  In this case, the spec requires
> the target to plug a hole which does not exist, which is the problem that
I
> am trying to point out.

I'm working off of -15.  Section 2.2.2.1 contains the following statements:

                CmdSN always contains the number to be
     assigned to the next Command PDU.

  Commands meant for immediate delivery are marked with an immediate
  delivery flag; they MUST also carry the current CmdSN.

So suppose CmdSN is 7, and the initiator sends an immediate command
with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
ABORT crosses the response to successful completion of the immediate
command on the wire.  At this point the following text in Section
9.6.1 applies:

    b)  if the Referenced Task Tag does not identify an existing task
    but if the CmdSN indicated by the RefCmdSN field in the Task Man-
     agement function request is within the valid CmdSN window (between
     MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
     and return the "Function complete" response.

7 is still the CmdSN of the next non-immediate command to be sent,
so it is within the window (ExpCmdSN is also 7).  Following these
directions, the Target considers CmdSN 7 to be received, and advances
its window.  Now, when the initiator sends its next non-immediate
command (CmdSN=7), its CmdSN is outside the window, and the target
bit-buckets the command instead of executing it.

This went awry because the task to be aborted was (implicitly)
identified by its CmdSN, and not its Task Tag resulting in an attempt
to abort an immediate command actually clobbering the next non-
immediate one.  I think Tony gets credit for finding another problem.

While I'm in here, it also appears that the text describing the
mapping of iSCSI task management response codes to SCSI service
responses needs to change to map 1 (Task does not exist) to
FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
Section 6.2 of SAM-2.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

--=_alternative 0046BD5DC2256C2B_=-- From owner-ips@ece.cmu.edu Thu Sep 5 09:48:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19389 for ; Thu, 5 Sep 2002 09:48:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85DKmZ07494 for ips-outgoing; Thu, 5 Sep 2002 09:20:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85DKio07483; Thu, 5 Sep 2002 09:20:44 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 09:20:44 -0400 Message-ID: From: Eddy Quicksall To: "'Julian Satran'" , Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 09:20:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C254DF.04128D00" 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_01C254DF.04128D00 Content-Type: text/plain; charset="iso-8859-1" If the Abort Task had its RefCmdSN == 7, then wouldn't this cause the problem David and Tony point out (considering everything David said)? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 8:27 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK The next command can't be clobered. Abort Task acts on command up to 6 (included) but not 7- and it has to be on the same connection as the aborted command. That insures that it will abort the first immediate but not the non-immediate after. As for the mapping - you are right - I'll mark it for the final edit (whenever that happens). Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 05/09/02 09:50 To: tonyb@cybernetics.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- ------_=_NextPart_001_01C254DF.04128D00 Content-Type: text/html; charset="iso-8859-1"
If the Abort Task had its RefCmdSN == 7, then wouldn't this cause the problem David and Tony point out (considering everything David said)?
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 8:27 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


The next command can't be clobered. Abort Task acts on command  up to 6 (included) but not 7- and it has to be on the same
connection as the aborted command. That insures that it will abort the first immediate but not the non-immediate after.

As for the mapping - you are right - I'll mark it for the final edit (whenever that happens).

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

05/09/02 09:50

       
        To:        tonyb@cybernetics.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


This thread's taken a while to sort through, but there
does appear to be a problem in here.

> If the missing command was non-immediate, then yes, the plug-in avoids
> having to resend the missing command.  But, if the missing command was
> immediate, then there is no hole to plug.  In this case, the spec requires
> the target to plug a hole which does not exist, which is the problem that
I
> am trying to point out.

I'm working off of -15.  Section 2.2.2.1 contains the following statements:

                CmdSN always contains the number to be
     assigned to the next Command PDU.

  Commands meant for immediate delivery are marked with an immediate
  delivery flag; they MUST also carry the current CmdSN.

So suppose CmdSN is 7, and the initiator sends an immediate command
with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
ABORT crosses the response to successful completion of the immediate
command on the wire.  At this point the following text in Section
9.6.1 applies:

    b)  if the Referenced Task Tag does not identify an existing task
    but if the CmdSN indicated by the RefCmdSN field in the Task Man-
     agement function request is within the valid CmdSN window (between
     MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
     and return the "Function complete" response.

7 is still the CmdSN of the next non-immediate command to be sent,
so it is within the window (ExpCmdSN is also 7).  Following these
directions, the Target considers CmdSN 7 to be received, and advances
its window.  Now, when the initiator sends its next non-immediate
command (CmdSN=7), its CmdSN is outside the window, and the target
bit-buckets the command instead of executing it.

This went awry because the task to be aborted was (implicitly)
identified by its CmdSN, and not its Task Tag resulting in an attempt
to abort an immediate command actually clobbering the next non-
immediate one.  I think Tony gets credit for finding another problem.

While I'm in here, it also appears that the text describing the
mapping of iSCSI task management response codes to SCSI service
responses needs to change to map 1 (Task does not exist) to
FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
Section 6.2 of SAM-2.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


------_=_NextPart_001_01C254DF.04128D00-- From owner-ips@ece.cmu.edu Thu Sep 5 09:59:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19652 for ; Thu, 5 Sep 2002 09:59:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85DcfZ08578 for ips-outgoing; Thu, 5 Sep 2002 09:38:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85Dcao08573; Thu, 5 Sep 2002 09:38:37 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 09:38:36 -0400 Message-ID: From: Eddy Quicksall To: "'Julian Satran'" Cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 09:38:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C254E1.8280D050" 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_01C254E1.8280D050 Content-Type: text/plain; charset="iso-8859-1" I don't see that fact when I read the spec. 9.5.5 RefCmdSN implies that the RefCmdSN may be used if the Referenced Task Tag (ITT) is not with the target anymore. And, I think that is David and Tony's point. I may have missed it someplace ... can you please point out where it says or implies "an immediate is aborted based on ITT"? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 9:23 AM To: Eddy Quicksall Cc: 'Black_David@emc.com'; Eddy Quicksall; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK No need - it works always as it is. An immediate is aborted based on ITT or not at all. Add to it the fact that they are on the same connection and immediates are not reassigned and everything works AS IS. What am I missing? Julo Eddy Quicksall 05/09/02 16:02 To: Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK How about another bit in the abort that says it is aborting an immediate command and hence does not advance the window? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 9:00 AM To: Eddy Quicksall Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration. And there are no known scenarios (to us) in which it does not work. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 05/09/02 15:46 To: "'Black_David@emc.com'" , tonyb@cybernetics.com cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Can we say that aborts with the immediate bit only abort commands with the immediate bit? And then say that the window is not advanced under that situation? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 05, 2002 2:51 AM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- ------_=_NextPart_001_01C254E1.8280D050 Content-Type: text/html; charset="iso-8859-1"
I don't see that fact when I read the spec. 9.5.5 RefCmdSN implies that the RefCmdSN may be used if the Referenced Task Tag (ITT) is not with the target anymore. And, I think that is David and Tony's point.
 
I may have missed it someplace ... can you please point out where it says or implies "an immediate is aborted based on ITT"?
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 9:23 AM
To: Eddy Quicksall
Cc: 'Black_David@emc.com'; Eddy Quicksall; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


No need - it works always as it is. An immediate is aborted based on ITT or not at all.
Add to it the fact that they are on the same connection and immediates are not reassigned
and everything works AS IS.
What am I missing?

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

05/09/02 16:02

       
        To:        Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall <eddy_quicksall@ivivity.com>
        cc:        "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


How about another bit in the abort that says it is aborting an immediate command and hence does not advance the window?
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 9:00 AM
To: Eddy Quicksall
Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration.
And there are no known scenarios (to us) in which it does not work.

Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

05/09/02 15:46

       
       To:        "'Black_David@emc.com'" <Black_David@emc.com>, tonyb@cybernetics.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

     



Can we say that aborts with the immediate bit only abort commands with the
immediate bit? And then say that the window is not advanced under that
situation?

Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, September 05, 2002 2:51 AM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


This thread's taken a while to sort through, but there
does appear to be a problem in here.

> If the missing command was non-immediate, then yes, the plug-in avoids
> having to resend the missing command.  But, if the missing command was
> immediate, then there is no hole to plug.  In this case, the spec requires
> the target to plug a hole which does not exist, which is the problem that
I
> am trying to point out.

I'm working off of -15.  Section 2.2.2.1 contains the following statements:

               CmdSN always contains the number to be
    assigned to the next Command PDU.

 Commands meant for immediate delivery are marked with an immediate
 delivery flag; they MUST also carry the current CmdSN.

So suppose CmdSN is 7, and the initiator sends an immediate command
with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
ABORT crosses the response to successful completion of the immediate
command on the wire.  At this point the following text in Section
9.6.1 applies:

   b)  if the Referenced Task Tag does not identify an existing task
   but if the CmdSN indicated by the RefCmdSN field in the Task Man-
    agement function request is within the valid CmdSN window (between
    MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
    and return the "Function complete" response.

7 is still the CmdSN of the next non-immediate command to be sent,
so it is within the window (ExpCmdSN is also 7).  Following these
directions, the Target considers CmdSN 7 to be received, and advances
its window.  Now, when the initiator sends its next non-immediate
command (CmdSN=7), its CmdSN is outside the window, and the target
bit-buckets the command instead of executing it.

This went awry because the task to be aborted was (implicitly)
identified by its CmdSN, and not its Task Tag resulting in an attempt
to abort an immediate command actually clobbering the next non-
immediate one.  I think Tony gets credit for finding another problem.

While I'm in here, it also appears that the text describing the
mapping of iSCSI task management response codes to SCSI service
responses needs to change to map 1 (Task does not exist) to
FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
Section 6.2 of SAM-2.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------



------_=_NextPart_001_01C254E1.8280D050-- From owner-ips@ece.cmu.edu Thu Sep 5 10:25:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20607 for ; Thu, 5 Sep 2002 10:25:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85Du8e09672 for ips-outgoing; Thu, 5 Sep 2002 09:56:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85Du5o09664 for ; Thu, 5 Sep 2002 09:56:05 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85DtvZ0019070 for ; Thu, 5 Sep 2002 15:55:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85DtvBD084096 for ; Thu, 5 Sep 2002 15:55:58 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 5 Sep 2002 16:55:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 16:55:57, Serialize complete at 05/09/2002 16:55:57 Content-Type: multipart/alternative; boundary="=_alternative 004C6527C2256C2B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004C6527C2256C2B_= Content-Type: text/plain; charset="us-ascii" ----- Forwarded by Julian Satran/Haifa/IBM on 05/09/02 16:54 ----- Julian Satran 05/09/02 16:53 To: cc: From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Again no - there was no hole filed and the second 7 gets through. Julo "Tony Battersby" 05/09/02 16:23 Please respond to tonyb To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 8:27 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > The next command can't be clobered. Abort Task acts on command up to 6 > (included) but not 7- and it has to be on the same connection as the > aborted command. That insures that it will abort the first immediate but > not the non-immediate after. Ok, here's the gotcha: The initiator sends a non-immediate command with CmdSN 7 on a different connection before sending the immediate ABORT TASK for the first immediate command. The ABORT TASK is sent on the same connection as the immediate command with CmdSN 7 to be aborted, but a different connection than the non-immediate command with CmdSN 7. The ABORT TASK will carry a CmdSN of 8, and the target may receive the ABORT TASK before it receives the non-immediate command with CmdSN 7, because they are sent on different connections. If this happens, the target considers CmdSN 7 received and then discards the non-immediate command with CmdSN 7 when it finishes receiving it on the other connection. Tricky, tricky, tricky... Tony --=_alternative 004C6527C2256C2B_= Content-Type: text/html; charset="us-ascii"
----- Forwarded by Julian Satran/Haifa/IBM on 05/09/02 16:54 -----
Julian Satran

05/09/02 16:53


        To:        <tonyb@cybernetics.com>
        cc:        
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASKLink
 





Again no - there was no hole filed and the second 7 gets through. Julo


"Tony Battersby" <tonyb@cybernetics.com>

05/09/02 16:23
Please respond to tonyb

       
        To:        Julian Satran/Haifa/IBM@IBMIL, <Black_David@emc.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

       


From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 8:27 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

> The next command can't be clobered. Abort Task acts on command  up to 6
> (included) but not 7- and it has to be on the same connection as the
> aborted command. That insures that it will abort the first immediate but
> not the non-immediate after.

Ok, here's the gotcha:

The initiator sends a non-immediate command with CmdSN 7 on a different
connection before sending the immediate ABORT TASK for the first immediate
command.  The ABORT TASK is sent on the same connection as the immediate
command with CmdSN 7 to be aborted, but a different connection than the
non-immediate command with CmdSN 7.  The ABORT TASK will carry a CmdSN of 8,
and the target may receive the ABORT TASK before it receives the
non-immediate command with CmdSN 7, because they are sent on different
connections.  If this happens, the target considers CmdSN 7 received and
then discards the non-immediate command with CmdSN 7 when it finishes
receiving it on the other connection.

Tricky, tricky, tricky...

Tony



--=_alternative 004C6527C2256C2B_=-- From owner-ips@ece.cmu.edu Thu Sep 5 10:27:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20673 for ; Thu, 5 Sep 2002 10:27:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85DnKt09222 for ips-outgoing; Thu, 5 Sep 2002 09:49:20 -0400 (EDT) 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 g85DnIo09217 for ; Thu, 5 Sep 2002 09:49:18 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g85DnCN12611 for ; Thu, 5 Sep 2002 09:49:12 -0400 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 g85DnCk12599; Thu, 5 Sep 2002 09:49:12 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g85DnBr01960; Thu, 5 Sep 2002 09:49:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15735.24791.535753.333953@pkoning.dev.equallogic.com> Date: Thu, 5 Sep 2002 09:49:11 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Julian" == Julian Satran writes: Julian> The next command can't be clobered. Abort Task acts on Julian> command up to 6 (included) but not 7- and it has to be on the Julian> same connection as the aborted command. That insures that it Julian> will abort the first immediate but not the non-immediate Julian> after. If the abort has to be sent on the same connection as the command being aborted, then it cannot overtake an immediate command preceding it. At least not in the network stack... So that seems to eliminate the case that David was worrying about. paul From owner-ips@ece.cmu.edu Thu Sep 5 11:24:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22787 for ; Thu, 5 Sep 2002 11:24:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85Epc813137 for ips-outgoing; Thu, 5 Sep 2002 10:51:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85Epbo13129 for ; Thu, 5 Sep 2002 10:51:37 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 10:51:36 -0400 Message-ID: From: Eddy Quicksall To: "'Paul Koning'" Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 10:51:27 -0400 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 Paul, Its a race having to do with sending the command response and receiving the abort ... not between getting the command and the abort request. I-T> immediate cmdSN=7 T-I> some delay but finally command response for above w/ExpCmdSN=7 (a race here due to processing at the initiator) I-T> before getting the response, sends abort for 7 (target advances ExpCmdSN to 8) I-T> non-immediate CmdSN=7 (outside of the command window, target dumps the command) The directions say to consider the command received (that would mean the non-immediate command) and that would be command 7. So you would advance ExpCmdSN to 8. When non-immediate command 7 arrives, it will be outside of the window and will be thrown out. This is all considering ErrorRecoveryLevel 0. Maybe I have missed something so please point out where I'm wrong. Eddy -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Thursday, September 05, 2002 9:49 AM To: Julian_Satran@il.ibm.com Cc: Black_David@emc.com; ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK >>>>> "Julian" == Julian Satran writes: Julian> The next command can't be clobered. Abort Task acts on Julian> command up to 6 (included) but not 7- and it has to be on the Julian> same connection as the aborted command. That insures that it Julian> will abort the first immediate but not the non-immediate Julian> after. If the abort has to be sent on the same connection as the command being aborted, then it cannot overtake an immediate command preceding it. At least not in the network stack... So that seems to eliminate the case that David was worrying about. paul From owner-ips@ece.cmu.edu Thu Sep 5 11:29:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22907 for ; Thu, 5 Sep 2002 11:29:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85EWFw11861 for ips-outgoing; Thu, 5 Sep 2002 10:32:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85EWBo11857 for ; Thu, 5 Sep 2002 10:32:11 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119041>; Thu, 5 Sep 2002 10:31:58 -0400 Reply-To: From: "Tony Battersby" To: "'Julian Satran'" Cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 10:31:57 -0400 Message-ID: <004601c254e8$fde19340$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let me break it down: From the initiator's perspective: 1) Send an immediate command with ITT = 22 and CmdSN = 7 on connection A 2) Send a non-immediate command with CmdSN = 7 on connection B 3) Send an immediate ABORT TASK command with Referenced Task Tag = 22 and RefCmdSN = 7 and CmdSN = 8 From the target's perspective: 4) ExpCmdSN is 7 5) Receive the immediate command with ITT = 22 and CmdSN = 7 on connection A 6) Send the response to the immediate command from step 5 and free its resources 7) Receive the immediate ABORT TASK command with Referenced Task Tag = 22 and RefCmdSN = 7 and CmdSN = 8 on connection A 8) Since no task exists with ITT = 22, and RefCmdSN is within the valid CmdSN window, and RefCmdSN is less than the CmdSN of the ABORT TASK command, consider CmdSN 7 received and set ExpCmdSN to 8 9) Receive the non-immediate command with CmdSN = 7 on connection B and silently discard it because it is outside the valid CmdSN window. In summary: 10) The end result is that the target aborted the wrong command. Specifically, which one of these steps can't happen, and why? AFAIK, this _can_ happen in my current target iSCSI implementation. If I am missing something, then my implementation may be broken and I would like to fix it; if I am not missing something, then there may be a real but fixable problem with the way ABORT TASK works. Tony -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 9:56 AM To: tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Again no - there was no hole filed and the second 7 gets through. Julo "Tony Battersby" 05/09/02 16:23 Please respond to tonyb To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 8:27 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > The next command can't be clobered. Abort Task acts on command up to 6 > (included) but not 7- and it has to be on the same connection as the > aborted command. That insures that it will abort the first immediate but > not the non-immediate after. Ok, here's the gotcha: The initiator sends a non-immediate command with CmdSN 7 on a different connection before sending the immediate ABORT TASK for the first immediate command. The ABORT TASK is sent on the same connection as the immediate command with CmdSN 7 to be aborted, but a different connection than the non-immediate command with CmdSN 7. The ABORT TASK will carry a CmdSN of 8, and the target may receive the ABORT TASK before it receives the non-immediate command with CmdSN 7, because they are sent on different connections. If this happens, the target considers CmdSN 7 received and then discards the non-immediate command with CmdSN 7 when it finishes receiving it on the other connection. Tricky, tricky, tricky... Tony From owner-ips@ece.cmu.edu Thu Sep 5 12:27:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24524 for ; Thu, 5 Sep 2002 12:27:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85Fced16506 for ips-outgoing; Thu, 5 Sep 2002 11:38:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85Fcbo16500 for ; Thu, 5 Sep 2002 11:38:37 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g85FcVO29201 for ; Thu, 5 Sep 2002 08:38:31 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 08:38:31 -0700 Message-ID: From: Robert Snively To: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 08:38:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C254F2.48899470" 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_01C254F2.48899470 Content-Type: text/plain; charset="iso-8859-1" This has become a remarkably complex structure. FCP took a somewhat simpler approach to the TASK ABORT synchronization problem. In FCP, the principal was that the ABORT TASK chase the targeted command through the chain of host adapter, transport media, target/logical unit, and back again, clearing up whatever residues were encountered along the way. That way, ordering was never an issue, because the command was either completed before an ABORT TASK ever started, or the ABORT TASK tracked it down and aborted the artifacts associated with the command wherever they were found. The inclusion of the HBA in the chain eliminated any possibility of the command escaping after the ABORT TASK was transmitted. It also eliminated ordering issues associated with transport paths, since any residue left in the transport path was deprived of context and discarded if it popped out later. Bob > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Thursday, September 05, 2002 7:51 AM > To: 'Paul Koning' > Cc: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > Paul, > > Its a race having to do with sending the command response and > receiving the > abort ... not between getting the command and the abort request. > > I-T> immediate cmdSN=7 > T-I> some delay but finally command response for above w/ExpCmdSN=7 > (a race here due to processing at the initiator) > I-T> before getting the response, sends abort for 7 > (target advances ExpCmdSN to 8) > I-T> non-immediate CmdSN=7 > (outside of the command window, target dumps the command) > > The directions say to consider the command received (that > would mean the > non-immediate command) and that would be command 7. So you > would advance > ExpCmdSN to 8. When non-immediate command 7 arrives, it will > be outside of > the window and will be thrown out. > > This is all considering ErrorRecoveryLevel 0. > > Maybe I have missed something so please point out where I'm wrong. > > Eddy > > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, September 05, 2002 9:49 AM > To: Julian_Satran@il.ibm.com > Cc: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > >>>>> "Julian" == Julian Satran writes: > > Julian> The next command can't be clobered. Abort Task acts on > Julian> command up to 6 (included) but not 7- and it has to be on the > Julian> same connection as the aborted command. That insures that it > Julian> will abort the first immediate but not the non-immediate > Julian> after. > > If the abort has to be sent on the same connection as the command > being aborted, then it cannot overtake an immediate command preceding > it. At least not in the network stack... So that seems to eliminate > the case that David was worrying about. > > paul > ------_=_NextPart_001_01C254F2.48899470 Content-Type: text/html; charset="iso-8859-1" RE: iSCSI: aborting an immediate command with ABORT TASK

This has become a remarkably complex structure.
FCP took a somewhat simpler approach to the TASK ABORT
synchronization problem.

In FCP, the principal was that the ABORT TASK chase
the targeted command through the chain of host adapter,
transport media, target/logical unit, and back again, clearing
up whatever residues were encountered along the way.

That way, ordering was never an issue, because the command
was either completed before an ABORT TASK ever started, or
the ABORT TASK tracked it down and aborted the artifacts
associated with the command wherever they were found.  The
inclusion of the HBA in the chain eliminated any possibility
of the command escaping after the ABORT TASK was transmitted.
It also eliminated ordering issues associated with transport
paths, since any residue left in the transport path was
deprived of context and discarded if it popped out later.

Bob

> -----Original Message-----
> From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
> Sent: Thursday, September 05, 2002 7:51 AM
> To: 'Paul Koning'
> Cc: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: aborting an immediate command with ABORT TASK
>
>
> Paul,
>
> Its a race having to do with sending the command response and
> receiving the
> abort ... not between getting the command and the abort request.
>
> I-T> immediate cmdSN=7
> T-I> some delay but finally command response for above w/ExpCmdSN=7
> (a race here due to processing at the initiator)
> I-T> before getting the response, sends abort for 7
> (target advances ExpCmdSN to 8)
> I-T> non-immediate CmdSN=7
> (outside of the command window, target dumps the command)
>
> The directions say to consider the command received (that
> would mean the
> non-immediate command) and that would be command 7. So you
> would advance
> ExpCmdSN to 8. When non-immediate command 7 arrives, it will
> be outside of
> the window and will be thrown out.
>
> This is all considering ErrorRecoveryLevel 0.
>
> Maybe I have missed something so please point out where I'm wrong.
>
> Eddy
>
> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, September 05, 2002 9:49 AM
> To: Julian_Satran@il.ibm.com
> Cc: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: aborting an immediate command with ABORT TASK
>
>
> >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
>
>  Julian> The next command can't be clobered. Abort Task acts on
>  Julian> command up to 6 (included) but not 7- and it has to be on the
>  Julian> same connection as the aborted command. That insures that it
>  Julian> will abort the first immediate but not the non-immediate
>  Julian> after.
>
> If the abort has to be sent on the same connection as the command
> being aborted, then it cannot overtake an immediate command preceding
> it.  At least not in the network stack...  So that seems to eliminate
> the case that David was worrying about.
>
>     paul
>

------_=_NextPart_001_01C254F2.48899470-- From owner-ips@ece.cmu.edu Thu Sep 5 14:38:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01716 for ; Thu, 5 Sep 2002 14:38:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85HqlT25159 for ips-outgoing; Thu, 5 Sep 2002 13:52:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85Hqjo25154 for ; Thu, 5 Sep 2002 13:52:45 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 13:52:39 -0400 Message-ID: From: Eddy Quicksall To: "'Robert Snively'" , ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 13:52:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25505.06377390" 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_01C25505.06377390 Content-Type: text/plain; charset="iso-8859-1" In SCSI host adapters this race also exists ... the way that is handled is the host adapter does not see the task and just responds with "task not fund". The driver doesn't have a problem because the only way the task could not be found is if it already completed. iSCSI has introduced this problem by 9.6.1 saying that if the task does not exist, it is considered to have existed ("Function complete"). I think we should just say "task not found". The initiator then sees the whole story and can work it out. However, the condition that Tony points out may be an additional case that I am not addressing. Eddy -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Thursday, September 05, 2002 11:38 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This has become a remarkably complex structure. FCP took a somewhat simpler approach to the TASK ABORT synchronization problem. In FCP, the principal was that the ABORT TASK chase the targeted command through the chain of host adapter, transport media, target/logical unit, and back again, clearing up whatever residues were encountered along the way. That way, ordering was never an issue, because the command was either completed before an ABORT TASK ever started, or the ABORT TASK tracked it down and aborted the artifacts associated with the command wherever they were found. The inclusion of the HBA in the chain eliminated any possibility of the command escaping after the ABORT TASK was transmitted. It also eliminated ordering issues associated with transport paths, since any residue left in the transport path was deprived of context and discarded if it popped out later. Bob > -----Original Message----- > From: Eddy Quicksall [ mailto:eddy_quicksall@ivivity.com ] > Sent: Thursday, September 05, 2002 7:51 AM > To: 'Paul Koning' > Cc: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > Paul, > > Its a race having to do with sending the command response and > receiving the > abort ... not between getting the command and the abort request. > > I-T> immediate cmdSN=7 > T-I> some delay but finally command response for above w/ExpCmdSN=7 > (a race here due to processing at the initiator) > I-T> before getting the response, sends abort for 7 > (target advances ExpCmdSN to 8) > I-T> non-immediate CmdSN=7 > (outside of the command window, target dumps the command) > > The directions say to consider the command received (that > would mean the > non-immediate command) and that would be command 7. So you > would advance > ExpCmdSN to 8. When non-immediate command 7 arrives, it will > be outside of > the window and will be thrown out. > > This is all considering ErrorRecoveryLevel 0. > > Maybe I have missed something so please point out where I'm wrong. > > Eddy > > -----Original Message----- > From: Paul Koning [ mailto:ni1d@arrl.net ] > Sent: Thursday, September 05, 2002 9:49 AM > To: Julian_Satran@il.ibm.com > Cc: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > >>>>> "Julian" == Julian Satran writes: > > Julian> The next command can't be clobered. Abort Task acts on > Julian> command up to 6 (included) but not 7- and it has to be on the > Julian> same connection as the aborted command. That insures that it > Julian> will abort the first immediate but not the non-immediate > Julian> after. > > If the abort has to be sent on the same connection as the command > being aborted, then it cannot overtake an immediate command preceding > it. At least not in the network stack... So that seems to eliminate > the case that David was worrying about. > > paul > ------_=_NextPart_001_01C25505.06377390 Content-Type: text/html; charset="iso-8859-1" RE: iSCSI: aborting an immediate command with ABORT TASK
In SCSI host adapters this race also exists ... the way that is handled is the host adapter does not see the task and just responds with "task not fund". The driver doesn't have a problem because the only way the task could not be found is if it already completed.
 
iSCSI has introduced this problem by 9.6.1 saying that if the task does not exist, it is considered to have existed ("Function complete").
 
I think we should just say "task not found". The initiator then sees the whole story and can work it out.
 
However, the condition that Tony points out may be an additional case that I am not addressing.
 
Eddy
-----Original Message-----
From: Robert Snively [mailto:rsnively@Brocade.COM]
Sent: Thursday, September 05, 2002 11:38 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

This has become a remarkably complex structure.
FCP took a somewhat simpler approach to the TASK ABORT
synchronization problem.

In FCP, the principal was that the ABORT TASK chase
the targeted command through the chain of host adapter,
transport media, target/logical unit, and back again, clearing
up whatever residues were encountered along the way.

That way, ordering was never an issue, because the command
was either completed before an ABORT TASK ever started, or
the ABORT TASK tracked it down and aborted the artifacts
associated with the command wherever they were found.  The
inclusion of the HBA in the chain eliminated any possibility
of the command escaping after the ABORT TASK was transmitted.
It also eliminated ordering issues associated with transport
paths, since any residue left in the transport path was
deprived of context and discarded if it popped out later.

Bob

> -----Original Message-----
> From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
> Sent: Thursday, September 05, 2002 7:51 AM
> To: 'Paul Koning'
> Cc: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: aborting an immediate command with ABORT TASK
>
>
> Paul,
>
> Its a race having to do with sending the command response and
> receiving the
> abort ... not between getting the command and the abort request.
>
> I-T> immediate cmdSN=7
> T-I> some delay but finally command response for above w/ExpCmdSN=7
> (a race here due to processing at the initiator)
> I-T> before getting the response, sends abort for 7
> (target advances ExpCmdSN to 8)
> I-T> non-immediate CmdSN=7
> (outside of the command window, target dumps the command)
>
> The directions say to consider the command received (that
> would mean the
> non-immediate command) and that would be command 7. So you
> would advance
> ExpCmdSN to 8. When non-immediate command 7 arrives, it will
> be outside of
> the window and will be thrown out.
>
> This is all considering ErrorRecoveryLevel 0.
>
> Maybe I have missed something so please point out where I'm wrong.
>
> Eddy
>
> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, September 05, 2002 9:49 AM
> To: Julian_Satran@il.ibm.com
> Cc: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: aborting an immediate command with ABORT TASK
>
>
> >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
>
>  Julian> The next command can't be clobered. Abort Task acts on
>  Julian> command up to 6 (included) but not 7- and it has to be on the
>  Julian> same connection as the aborted command. That insures that it
>  Julian> will abort the first immediate but not the non-immediate
>  Julian> after.
>
> If the abort has to be sent on the same connection as the command
> being aborted, then it cannot overtake an immediate command preceding
> it.  At least not in the network stack...  So that seems to eliminate
> the case that David was worrying about.
>
>     paul
>

------_=_NextPart_001_01C25505.06377390-- From owner-ips@ece.cmu.edu Thu Sep 5 16:55:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05561 for ; Thu, 5 Sep 2002 16:55:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85KEBS04966 for ips-outgoing; Thu, 5 Sep 2002 16:14:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85KE8o04957 for ; Thu, 5 Sep 2002 16:14:08 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85KDwZ0027890; Thu, 5 Sep 2002 22:13:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85KDvBC067528; Thu, 5 Sep 2002 22:13:58 +0200 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK To: Eddy Quicksall Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 5 Sep 2002 17:41:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 23:13:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that whole confusion is the result of some missing words. The missing words are the that you cannot have RefCmdSN reffer to something equal or higher than the ABORT TASKS CmdSN. It is implied in the section 2 text (about the scope of commands) but not explicit. I will add a word about ASAP. the text I suggest for 9.5.5 is: For the ABORT TASK function, initiators MUST always set this to the CmdSN of the task identified by the Referenced Task Tag field. Targets must use this field as described in section 9.6.1 when the task identified by the Referenced Task Tag field is not with the target. RefCmdSN MUST be lower than the Task Management Request CmdSN field (in serial arithmetic sense). As for immediate commands and RefCmdSN - my comment was that a missed immediate command is missed forever! The RefCmdSN will not help you when it is missing since an immediate commad does not generate a hole! Julo Eddy Quicksall cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com 05/09/02 16:38 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK I don't see that fact when I read the spec. 9.5.5 RefCmdSN implies that the RefCmdSN may be used if the Referenced Task Tag (ITT) is not with the target anymore. And, I think that is David and Tony's point. I may have missed it someplace ... can you please point out where it says or implies "an immediate is aborted based on ITT"? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 9:23 AM To: Eddy Quicksall Cc: 'Black_David@emc.com'; Eddy Quicksall; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK No need - it works always as it is. An immediate is aborted based on ITT or not at all. Add to it the fact that they are on the same connection and immediates are not reassigned and everything works AS IS. What am I missing? Julo Eddy Quicksall Eddy Quicksall cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, 05/09/02 16:02 owner-ips@ece.cmu.edu, tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK How about another bit in the abort that says it is aborting an immediate command and hence does not advance the window? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 9:00 AM To: Eddy Quicksall Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration. And there are no known scenarios (to us) in which it does not work. Julo Eddy Quicksall , tonyb@cybernetics.com Sent by: owner-ips@ece.cmu.edu cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK 05/09/02 15:46 Can we say that aborts with the immediate bit only abort commands with the immediate bit? And then say that the window is not advanced under that situation? Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September 05, 2002 2:51 AM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: aborting an immediate command with ABORT TASK This thread's taken a while to sort through, but there does appear to be a problem in here. > If the missing command was non-immediate, then yes, the plug-in avoids > having to resend the missing command. But, if the missing command was > immediate, then there is no hole to plug. In this case, the spec requires > the target to plug a hole which does not exist, which is the problem that I > am trying to point out. I'm working off of -15. Section 2.2.2.1 contains the following statements: CmdSN always contains the number to be assigned to the next Command PDU. Commands meant for immediate delivery are marked with an immediate delivery flag; they MUST also carry the current CmdSN. So suppose CmdSN is 7, and the initiator sends an immediate command with CmdSN 7 and then decides to abort it, and sends TASK ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose the TASK ABORT crosses the response to successful completion of the immediate command on the wire. At this point the following text in Section 9.6.1 applies: b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Man- agement function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. 7 is still the CmdSN of the next non-immediate command to be sent, so it is within the window (ExpCmdSN is also 7). Following these directions, the Target considers CmdSN 7 to be received, and advances its window. Now, when the initiator sends its next non-immediate command (CmdSN=7), its CmdSN is outside the window, and the target bit-buckets the command instead of executing it. This went awry because the task to be aborted was (implicitly) identified by its CmdSN, and not its Task Tag resulting in an attempt to abort an immediate command actually clobbering the next non- immediate one. I think Tony gets credit for finding another problem. While I'm in here, it also appears that the text describing the mapping of iSCSI task management response codes to SCSI service responses needs to change to map 1 (Task does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with Section 6.2 of SAM-2. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 5 16:55:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05577 for ; Thu, 5 Sep 2002 16:55:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85KEBW04964 for ips-outgoing; Thu, 5 Sep 2002 16:14:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85KE8o04956 for ; Thu, 5 Sep 2002 16:14:08 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85KE1Z0016102 for ; Thu, 5 Sep 2002 22:14:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85KE1BC056994 for ; Thu, 5 Sep 2002 22:14:01 +0200 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 5 Sep 2002 19:26:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 23:14:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Forget the previous text - we wont the clarification to be added for the "plugging side" (the target) and the we suggest changing the last bullet b in 9.6.1 to: If the Referenced Task Tag does not identify an existing task, but if the CmdSN indicated by the RefCmdSN field in the Task Management function request is within the valid CmdSN window and less than the CmdSN of the Task Management function request itself, then targets must consider the CmdSN received and return the "Function complete" response. We thought this was obvious from the overview text but it apparently is not. Julo The current wording IS CORRECT! From owner-ips@ece.cmu.edu Thu Sep 5 16:56:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05602 for ; Thu, 5 Sep 2002 16:56:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85KEEq04973 for ips-outgoing; Thu, 5 Sep 2002 16:14:14 -0400 (EDT) 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 g85KEDo04968 for ; Thu, 5 Sep 2002 16:14:13 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85KE6BM047520; Thu, 5 Sep 2002 22:14:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85KE6BC012866; Thu, 5 Sep 2002 22:14:06 +0200 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK To: ips@ece.cmu.edu Cc: Black_David@emc.com X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 5 Sep 2002 22:05:06 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 23:14:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk In addition in order to eliminate the "corner case" I mentioned earlier (and that is the only ambiguity we know about) - that a TASK ABORT may abort both an immediate and a non-immediate that have the same number and are both lost even though only the immediate was intended I added the following text to 9 If an ABORT TASK is issued for a task created by an immediate command then RefCmdSN MUST be that of the Task Management request itself (i.e. CmdSN and RefCmdSN are equal; otherwise RefCmdSN MUST be set to the CmdSN of the task to be aborted (lower than CmdSN). and made 9.5.5 to raed: RefCmdSN If an ABORT TASK is issued for a task created by an immediate command then RefCmdSN MUST be that of the Task Management request itself (i.e. CmdSN and RefCmdSN are equal). For an ABORT TASK of a task created by non-immediate command RefCmdSN MUST be set to the CmdSN of the task identified by the Referenced Task Tag field. Targets must use this field as described in section 9.6.1 when the task identified by the Referenced Task Tag field is not with the target. Otherwise, this field is reserved. Regards, Julo ----- Forwarded by Julian Satran/Haifa/IBM on 05/09/02 21:56 ----- Julian Satran To: ips@ece.cmu.edu 05/09/02 19:26 cc: From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Forget the previous text - we wont the clarification to be added for the "plugging side" (the target) and the we suggest changing the last bullet b in 9.6.1 to: If the Referenced Task Tag does not identify an existing task, but if the CmdSN indicated by the RefCmdSN field in the Task Management function request is within the valid CmdSN window and less than the CmdSN of the Task Management function request itself, then targets must consider the CmdSN received and return the "Function complete" response. We thought this was obvious from the overview text but it apparently is not. Julo The current wording IS CORRECT! From owner-ips@ece.cmu.edu Thu Sep 5 17:33:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06553 for ; Thu, 5 Sep 2002 17:33:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85Kk6907343 for ips-outgoing; Thu, 5 Sep 2002 16:46:06 -0400 (EDT) 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 g85Kk2o07336 for ; Thu, 5 Sep 2002 16:46:02 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g85KjuVb016358; Thu, 5 Sep 2002 22:45:56 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g85KjuBC056958; Thu, 5 Sep 2002 22:45:56 +0200 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI version 16 draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 5 Sep 2002 23:45:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 23:45:55, Serialize complete at 05/09/2002 23:45:55 Content-Type: multipart/alternative; boundary="=_alternative 0071C3E1C2256C2B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0071C3E1C2256C2B_= Content-Type: text/plain; charset="us-ascii" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.pdf This version completely replaces: draft-ietf-ips-iscsi-15.txt and pdf This version includes all editorial changes required during the WG last call and DOES NOT HAVE a change log. Please pay attention to all reserved and fixed field values as some have changes required to ensure simplicity and consistency have caused some pain to some implementations lately. Julian Satran - IBM Research Laboratory at Haifa --=_alternative 0071C3E1C2256C2B_= Content-Type: text/html; charset="us-ascii"







On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-16.pdf


This version completely replaces:

draft-ietf-ips-iscsi-15.txt and pdf



This version includes all editorial changes required during the WG last call and DOES NOT HAVE a change log.
Please pay attention to all reserved and fixed field values as some have changes required to ensure simplicity and consistency
have caused some pain to some implementations lately.

Julian Satran - IBM Research Laboratory at Haifa

































--=_alternative 0071C3E1C2256C2B_=-- From owner-ips@ece.cmu.edu Thu Sep 5 18:26:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10087 for ; Thu, 5 Sep 2002 18:26:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85Li6Y11139 for ips-outgoing; Thu, 5 Sep 2002 17:44:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85Li4o11135 for ; Thu, 5 Sep 2002 17:44:04 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 17:44:04 -0400 Message-ID: From: Eddy Quicksall To: "'Julian Satran'" , ips@ece.cmu.edu Cc: Black_David@emc.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Thu, 5 Sep 2002 17:44:00 -0400 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 The two last EMAIL's you sent regarding this work for me. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 05, 2002 3:05 PM To: ips@ece.cmu.edu Cc: Black_David@emc.com Subject: RE: iSCSI: aborting an immediate command with ABORT TASK In addition in order to eliminate the "corner case" I mentioned earlier (and that is the only ambiguity we know about) - that a TASK ABORT may abort both an immediate and a non-immediate that have the same number and are both lost even though only the immediate was intended I added the following text to 9 If an ABORT TASK is issued for a task created by an immediate command then RefCmdSN MUST be that of the Task Management request itself (i.e. CmdSN and RefCmdSN are equal; otherwise RefCmdSN MUST be set to the CmdSN of the task to be aborted (lower than CmdSN). and made 9.5.5 to raed: RefCmdSN If an ABORT TASK is issued for a task created by an immediate command then RefCmdSN MUST be that of the Task Management request itself (i.e. CmdSN and RefCmdSN are equal). For an ABORT TASK of a task created by non-immediate command RefCmdSN MUST be set to the CmdSN of the task identified by the Referenced Task Tag field. Targets must use this field as described in section 9.6.1 when the task identified by the Referenced Task Tag field is not with the target. Otherwise, this field is reserved. Regards, Julo ----- Forwarded by Julian Satran/Haifa/IBM on 05/09/02 21:56 ----- Julian Satran To: ips@ece.cmu.edu 05/09/02 19:26 cc: From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Forget the previous text - we wont the clarification to be added for the "plugging side" (the target) and the we suggest changing the last bullet b in 9.6.1 to: If the Referenced Task Tag does not identify an existing task, but if the CmdSN indicated by the RefCmdSN field in the Task Management function request is within the valid CmdSN window and less than the CmdSN of the Task Management function request itself, then targets must consider the CmdSN received and return the "Function complete" response. We thought this was obvious from the overview text but it apparently is not. Julo The current wording IS CORRECT! From owner-ips@ece.cmu.edu Thu Sep 5 18:26:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10102 for ; Thu, 5 Sep 2002 18:26:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g85MEA212944 for ips-outgoing; Thu, 5 Sep 2002 18:14:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msg001.maranti.com (66-147-154-78.focaldata.net [66.147.154.78] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g85ME7o12939 for ; Thu, 5 Sep 2002 18:14:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: iSCSI : Login response with zero DataSegmentLength MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25528.EDE1D6AE" Date: Thu, 5 Sep 2002 15:09:39 -0700 Message-ID: Thread-Topic: iSCSI : Login response with zero DataSegmentLength Thread-Index: AcJVKO38m/2l0yTFQmiqGIkr1zSJSg== From: "Priya Viswambharan" To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C25528.EDE1D6AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 Consider the following scenario.=20 =20 1) I -> T : login request: T=3D0, csg =3D 1, some text parameters = that require negotiation 2) I <- T : login response: T =3D 0, csg =3D 1, response for the initiator's text parameters + target's own text parameters that require negotiation. 3) I -> T : login request: T =3D 1, csg =3D 1, nsg =3D 3, response = for the parameters proposed by the target in step 2 =20 Assume that at the end of the login request in step 3 all text parameters that need negotiation have been negotiated correctly at both ends. Is it valid for the target to send a login response as follows signifying the end of login phase? If not, what should be the correct response from the target ? =20 4) I <- T : login response : T=3D1, csg =3D 1, nsg =3D 3, = DataSegmentLength =3D 0 =20 I observed that the draft says that "A target or initiator SHOULD NOT use a Text or Login Response or Text or Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule." =20 To me the above scenario does not seem to be covered by this rule. Please clarify. =20 Thanks Priya =20 ------_=_NextPart_001_01C25528.EDE1D6AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Consider the following scenario. =

 

1) I -> T    : login request: T=3D0, csg =3D 1, some text = parameters that require negotiation

2) I <- T    : login response: T =3D 0, csg =3D 1, response for = the initiator’s text parameters + target’s own text parameters = that require negotiation.

3) I -> T    : login request: T =3D 1, csg =3D 1, nsg =3D 3, response for the parameters proposed by the target in step = 2

 

Assume that at the end of the login request in step 3 = all text parameters that need negotiation have been negotiated correctly at = both ends. Is it valid for the target to send a login response as follows = signifying the end of login phase? If not, what should be the correct response from = the target ?

 

4) I <- T : login = response : T=3D1, csg =3D 1, nsg =3D 3, DataSegmentLength =3D = 0

 

I observed that the draft = says that “A target or initiator SHOULD NOT use a = Text or Login Response or Text or Login Request with no data = segment (DataSegmentLength 0) unless explicitly = required by a general or a key-specific negotiation = rule.”

 

To me the above scenario does not seem to be covered = by this rule. Please clarify.

 

Thanks

Priya

 

=00 ------_=_NextPart_001_01C25528.EDE1D6AE-- From owner-ips@ece.cmu.edu Thu Sep 5 21:26:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13309 for ; Thu, 5 Sep 2002 21:26:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g860mEL20496 for ips-outgoing; Thu, 5 Sep 2002 20:48:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g860mBo20491 for ; Thu, 5 Sep 2002 20:48:11 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g860m2O08006 for ; Thu, 5 Sep 2002 17:48:02 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Sep 2002 17:48:02 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: Please disregard iSCSI draft 15 announcement Date: Thu, 5 Sep 2002 17:47:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2553F.08FB1B10" 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_01C2553F.08FB1B10 Content-Type: text/plain; charset="iso-8859-1" Hi all, On Sept 5, an announcement for draft 15 was sent to the list. I am in the process of investigating this, but please disregard. We believe that this is the same draft 15 announced about a month ago, that completed WG last call. Julian has just submitted draft 16, and that should be posted soon. Thanks, Elizabeth Rodriguez ------_=_NextPart_001_01C2553F.08FB1B10 Content-Type: text/html; charset="iso-8859-1" Please disregard iSCSI draft 15 announcement

Hi all,

On Sept 5, an announcement for draft 15 was sent to the list.
I am in the process of investigating this, but please disregard.
We believe that this is the same draft 15 announced about a month ago, that completed WG last call.
Julian has just submitted draft 16, and that should be posted soon.

Thanks,

Elizabeth Rodriguez

------_=_NextPart_001_01C2553F.08FB1B10-- From owner-ips@ece.cmu.edu Fri Sep 6 08:13:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00947 for ; Fri, 6 Sep 2002 08:13:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g86BSPu27733 for ips-outgoing; Fri, 6 Sep 2002 07:28:25 -0400 (EDT) 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 g86BSNo27729 for ; Fri, 6 Sep 2002 07:28:24 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g86BSGZC036682; Fri, 6 Sep 2002 13:28:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g86BSFu0067480; Fri, 6 Sep 2002 13:28:16 +0200 To: "Priya Viswambharan" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI : Login response with zero DataSegmentLength X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 6 Sep 2002 14:28:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/09/2002 14:28:16, Serialize complete at 06/09/2002 14:28:16 Content-Type: multipart/alternative; boundary="=_alternative 003E426DC2256C2C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003E426DC2256C2C_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Priya, The answer you suggest in step 4 is correct - as you are required to=20 conclude the negotiation. If your answer would have had T=3D0 and a zero=20 length Data Segment that would have violated the rule you quote.=20 Basically the rule is there to help avoid unnecessary traffic. Julo "Priya Viswambharan" Sent by: owner-ips@ece.cmu.edu 06/09/02 01:09 =20 To: cc:=20 Subject: iSCSI : Login response with zero DataSegmentLength =20 Hi all, =20 Consider the following scenario.=20 =20 1) I -> T : login request: T=3D0, csg =3D 1, some text parameters that=20 require negotiation 2) I <- T : login response: T =3D 0, csg =3D 1, response for the=20 initiator's text parameters + target's own text parameters that require=20 negotiation. 3) I -> T : login request: T =3D 1, csg =3D 1, nsg =3D 3, response for t= he=20 parameters proposed by the target in step 2 =20 Assume that at the end of the login request in step 3 all text parameters=20 that need negotiation have been negotiated correctly at both ends. Is it=20 valid for the target to send a login response as follows signifying the=20 end of login phase? If not, what should be the correct response from the=20 target ? =20 4) I <- T : login response : T=3D1, csg =3D 1, nsg =3D 3, DataSegmentLength= =3D 0 =20 I observed that the draft says that "A target or initiator SHOULD NOT use a= Text or Login Response or Text or=20 Login Request with no data segment (DataSegmentLength 0) unless explicitly = required by a general or a key-specific negotiation rule." =20 To me the above scenario does not seem to be covered by this rule. Please=20 clarify. =20 Thanks Priya =20 --=_alternative 003E426DC2256C2C_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Priya,

The answer you suggest in step 4 is = correct - as you are required to conclude the negotiation. If your answer w= ould have had T=3D0 and a zero length
Data Segment that would have violate= d the rule you quote.

Basically the rule is there to help = avoid unnecessary traffic.

Julo


"Priya Viswambharan" &l= t;priyav@marantinetworks.com>
Sent by: owner-ips@ece.cmu.edu

06/09/02 01:09

       
        To: &nbs= p;      <ips@ece.cmu.edu>
        cc: &nbs= p;      
        Subject:=        iSCSI : Login response with zero DataSegmentLen= gth

       


Hi all,

 

Consider the following scenario.

 

1) I -> T    : login request:= T=3D0, csg =3D 1, some text parameters that require negotiation

2) I <- T    : login response= : T =3D 0, csg =3D 1, response for the initiator's text parameters + target= 's own text parameters that require negotiation.

3) I -> T    : login request:= T =3D 1, csg =3D 1, nsg =3D 3, response for the parameters proposed by the= target in step 2

 

Assume that at the end of the login reques= t in step 3 all text parameters that need negotiation have been negotiated = correctly at both ends. Is it valid for the target to send a login response= as follows signifying the end of login phase? If not, what should be the c= orrect response from the target ?

 

4) I <- T : login response : T=3D1, csg= =3D 1, nsg =3D 3, DataSegmentLength =3D 0

 

I observed that the draft says that "A target or initiator SHOULD NOT use a Te= xt or Login Response or Text or Login Request with no data segment (DataSeg= mentLength 0) unless explicitly required by a general or a key-specific neg= otiation rule."

 

To me the above scenario does not seem to = be covered by this rule. Please clarify.

 

Thanks

Priya

 

--=_alternative 003E426DC2256C2C_=-- From owner-ips@ece.cmu.edu Fri Sep 6 09:54:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03716 for ; Fri, 6 Sep 2002 09:54:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g86DFQ002771 for ips-outgoing; Fri, 6 Sep 2002 09:15:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g86DFOo02762 for ; Fri, 6 Sep 2002 09:15:24 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119042>; Fri, 6 Sep 2002 09:15:13 -0400 Reply-To: From: "Tony Battersby" To: "'Julian Satran'" , Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Fri, 6 Sep 2002 09:15:13 -0400 Message-ID: <006201c255a7$701b4550$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree. This sounds like a good solution to me. Thanks for listening! Tony > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Eddy Quicksall > Sent: Thursday, September 05, 2002 5:44 PM > To: 'Julian Satran'; ips@ece.cmu.edu > Cc: Black_David@emc.com > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > The two last EMAIL's you sent regarding this work for me. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Thursday, September 05, 2002 3:05 PM > To: ips@ece.cmu.edu > Cc: Black_David@emc.com > Subject: RE: iSCSI: aborting an immediate command with ABORT TASK > > > In addition in order to eliminate the "corner case" I > mentioned earlier > (and that is the only ambiguity we know about) - that a TASK ABORT may > abort > both an immediate and a non-immediate that have the same > number and are > both lost even though only the immediate was intended I added > the following > text to 9 > > If an ABORT TASK is issued for a task created by an immediate > command then RefCmdSN MUST be that of the Task > Management request > itself (i.e. CmdSN and RefCmdSN are equal; otherwise > RefCmdSN MUST > be set to the CmdSN of the task to be aborted (lower > than CmdSN). > > and made 9.5.5 to raed: > > RefCmdSN > > > If an ABORT TASK is issued for a task created by an immediate > command then RefCmdSN MUST be that of the Task > Management request > itself (i.e. CmdSN and RefCmdSN are equal). > > For an ABORT TASK of a task created by non-immediate command > RefCmdSN MUST be set to the CmdSN of the task identified by the > Referenced Task Tag field. Targets must use this field > as described > in section 9.6.1 when the task identified by the > Referenced Task Tag > field is not with the target. > > Otherwise, this field is reserved. > > Regards, > Julo > > ----- Forwarded by Julian Satran/Haifa/IBM on 05/09/02 21:56 ----- > > > Julian Satran > > To: > ips@ece.cmu.edu > > 05/09/02 19:26 cc: > > From: Julian > Satran/Haifa/IBM@Haifa/IBM@IBMIL > > Subject: RE: > iSCSI: aborting > an immediate command with ABORT TASK > > > > > > > > > > Forget the previous text - we wont the clarification to be > added for the > "plugging side" (the target) and the we suggest changing the > last bullet b > in 9.6.1 > to: > > If the Referenced Task Tag does not identify an > existing task, > but if the CmdSN indicated by the RefCmdSN field in the Task > Management function request is within the valid > CmdSN window and > less than the CmdSN of the Task Management function request > itself, then targets must consider the CmdSN > received and return > the "Function complete" response. > > We thought this was obvious from the overview text but it > apparently is > not. > > Julo > > The current wording IS CORRECT! > > > > From owner-ips@ece.cmu.edu Fri Sep 6 09:54:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03822 for ; Fri, 6 Sep 2002 09:54:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g86D3Gp02073 for ips-outgoing; Fri, 6 Sep 2002 09:03:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g86D3Fo02069 for ; Fri, 6 Sep 2002 09:03:15 -0400 (EDT) Received: from breinhold (h00e09871f366.ne.client2.attbi.com [24.128.217.142]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PV0A17NT; Fri, 6 Sep 2002 09:03:14 -0400 From: "Barry.Reinhold@trebia.com" To: "Julian Satran" Cc: "James Smart" , "Anshul Chadda" , "ISCSI" Subject: Task Reassignment Date: Fri, 6 Sep 2002 10:05:21 -0400 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 V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I believe clause 9.5.1 2nd PP, starting at 5th sentence, is not what we intend for TASK REASSIGNMENT. It states: "According to [SAM2], for all the tasks covered by the Task Management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the Task Management response. ...stuff cut here... "The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI initiator after the Task Management response." I believe the draft, as now worded, requires the following: Initiator: Sends the Task Management Function Request with Function field set to TASK REASSIGN. Target: If the identified task is associated with a logged out connection, it is made allegiant to the connection on which the "Task Management Function Request" PDU was received. No activity for the reassigned task may take place until the "Task Management Function Response" PDU with the Response field set to FUNCTION COMPLETE is sent. (9.5.1 Page 147 3rd PP) At this point in time the reassigned task is to complete in a normal fashion which may involve addition data exchange but MUST conclude with status in a data or response PDU. (5.2.2 Pg 86 1st PP) Thus the target is required to send the response for the reassigned command after the response associated with the Task Management request, which violates 9.5.1. I don't believe this is really a technical issue (SAM2 experts check me on this..) and all we need is an editorial change or note in 9.5.1 allowing for reassigned commands to send responses after the task management response. Proposed wording: Add the following note to the end of the paragraph in question in clause 9.5.1: Note: This does not apply to the TASK REASSIGN function. For TASK REASSIGN the status response associated with the reassigned command is required. (See Allegiance Reassignment) Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-659-0885 (Durham)/978-264-7656 (Acton)/603 767-5290 (Cell) From owner-ips@ece.cmu.edu Fri Sep 6 12:50:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13385 for ; Fri, 6 Sep 2002 12:50:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g86G23J14151 for ips-outgoing; Fri, 6 Sep 2002 12:02:03 -0400 (EDT) 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 g86G21o14145 for ; Fri, 6 Sep 2002 12:02:01 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g86G1VVb072316; Fri, 6 Sep 2002 18:01:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g86G1Uu0124456; Fri, 6 Sep 2002 18:01:30 +0200 To: "Barry.Reinhold@trebia.com" Cc: "Anshul Chadda" , "ISCSI" , "James Smart" MIME-Version: 1.0 Subject: Re: Task Reassignment X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 6 Sep 2002 19:01:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/09/2002 19:01:29, Serialize complete at 06/09/2002 19:01:29 Content-Type: multipart/alternative; boundary="=_alternative 004D5CE4C2256C2C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004D5CE4C2256C2C_= Content-Type: text/plain; charset="us-ascii" Barry, The cluse you quote refers to the paragraph it appears into which treats TASK group management like TASK SET CLEAR etc. TASK reassign has no such requirement. I will try rewording at the first chance (whenever that may be). Regards, Julo "Barry.Reinhold@trebia.com" , "Anshul Chadda" , "ISCSI" Subject: Task Reassignment Julian, I believe clause 9.5.1 2nd PP, starting at 5th sentence, is not what we intend for TASK REASSIGNMENT. It states: "According to [SAM2], for all the tasks covered by the Task Management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the Task Management response. ...stuff cut here... "The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI initiator after the Task Management response." I believe the draft, as now worded, requires the following: Initiator: Sends the Task Management Function Request with Function field set to TASK REASSIGN. Target: If the identified task is associated with a logged out connection, it is made allegiant to the connection on which the "Task Management Function Request" PDU was received. No activity for the reassigned task may take place until the "Task Management Function Response" PDU with the Response field set to FUNCTION COMPLETE is sent. (9.5.1 Page 147 3rd PP) At this point in time the reassigned task is to complete in a normal fashion which may involve addition data exchange but MUST conclude with status in a data or response PDU. (5.2.2 Pg 86 1st PP) Thus the target is required to send the response for the reassigned command after the response associated with the Task Management request, which violates 9.5.1. I don't believe this is really a technical issue (SAM2 experts check me on this..) and all we need is an editorial change or note in 9.5.1 allowing for reassigned commands to send responses after the task management response. Proposed wording: Add the following note to the end of the paragraph in question in clause 9.5.1: Note: This does not apply to the TASK REASSIGN function. For TASK REASSIGN the status response associated with the reassigned command is required. (See Allegiance Reassignment) Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-659-0885 (Durham)/978-264-7656 (Acton)/603 767-5290 (Cell) --=_alternative 004D5CE4C2256C2C_= Content-Type: text/html; charset="us-ascii"
Barry,

The cluse you quote refers to the paragraph it appears into which treats TASK group management like TASK SET CLEAR etc.
TASK reassign has no such requirement.

I will try rewording  at the first chance (whenever that may be).

Regards,
Julo


"Barry.Reinhold@trebia.com" <barry.reinhold

06/09/02 17:05

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "James Smart" <james.smart@trebia.com>, "Anshul Chadda" <achadda@trebia.com>, "ISCSI" <ips@ece.cmu.edu>
        Subject:        Task Reassignment

       


Julian,
                I believe clause 9.5.1 2nd PP, starting at 5th sentence, is not what we
intend for TASK REASSIGNMENT. It states:

"According to [SAM2], for all the tasks covered by the Task Management
response (i.e., with CmdSN not higher than the task management command
CmdSN), additional responses MUST NOT be delivered to the SCSI layer after
the Task Management response.
...stuff cut here...
"The iSCSI target MUST ensure that no responses for the tasks covered by a
task management function are delivered to the iSCSI initiator after the Task
Management response."

I believe the draft, as now worded, requires the following:

Initiator: Sends the Task Management Function Request with Function field
set to TASK REASSIGN.

Target: If the identified task is associated with a logged out connection,
it is made allegiant to the connection on which the "Task Management
Function Request" PDU was received. No activity for the reassigned task may
take place until the "Task Management Function Response" PDU with the
Response field set to FUNCTION COMPLETE is sent. (9.5.1 Page 147 3rd PP) At
this point in time the reassigned task is to complete in a normal fashion
which may involve addition data exchange but MUST conclude with status in a
data or response PDU. (5.2.2 Pg 86 1st PP)

Thus the target is required to send the response for the reassigned command
after the response associated with the Task Management request, which
violates 9.5.1.

I don't believe this is really a technical issue (SAM2 experts check me on
this..) and all we need is an editorial change or note in 9.5.1 allowing for
reassigned commands to send responses after the task management response.

Proposed wording:
Add the following note to the end of the paragraph in question in clause
9.5.1:

Note: This does not apply to the TASK REASSIGN function. For TASK REASSIGN
the status response associated with the reassigned command is required. (See
Allegiance Reassignment)

Barry Reinhold
Principal Architect
Trebia Networks
barry.reinhold@trebia.com
603-659-0885 (Durham)/978-264-7656 (Acton)/603 767-5290 (Cell)

--=_alternative 004D5CE4C2256C2C_=-- From owner-ips@ece.cmu.edu Mon Sep 9 09:54:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01935 for ; Mon, 9 Sep 2002 09:54:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g89D7as07947 for ips-outgoing; Mon, 9 Sep 2002 09:07:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g89C1Ao05140 for ; Mon, 9 Sep 2002 08:01:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28853; Mon, 9 Sep 2002 07:59:22 -0400 (EDT) Message-Id: <200209091159.HAA28853@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-16.txt,.pdf Date: Mon, 09 Sep 2002 07:59:22 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-16.txt,.pdf Pages : 283 Date : 2002-9-6 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-16.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-6143050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-6143050.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Sep 9 17:19:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17029 for ; Mon, 9 Sep 2002 17:19:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g89KmvI09887 for ips-outgoing; Mon, 9 Sep 2002 16:48:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g89Kmso09883 for ; Mon, 9 Sep 2002 16:48:55 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g89KmnO19847 for ; Mon, 9 Sep 2002 13:48:49 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Sep 2002 13:48:49 -0700 Message-ID: From: Elizabeth Rodriguez To: "IPS Mailing List (E-mail)" Subject: IPS-All: WG last call on "Definitions of Managed Objects for iFCP " Date: Mon, 9 Sep 2002 13:48:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25842.4871F970" 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_01C25842.4871F970 Content-Type: text/plain; charset="iso-8859-1" All, We would like to announce IPS WG last call on the draft "Definitions of Managed Objects For iFCP ". The last call period is for two weeks, ending at 5pm EST on Monday, September 23. Editorial comments may be directly sent to the editor/authors of the document -- with copy to myself [erodrigu@brocade.com], David Black [black_david@emc.com] and Franco Travostino [travos@nortelnetworks.com] Technical comments should be sent to the IPS mailing list for discussion. Summary: Draft: Definitions of Managed Objects for iFCP URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-02.txt Period: 2 weeks, ending at 5pm Monday, Sept 23 Editor: Kevin Gibbons [kgibbons@NishanSystems.com] Authors: Kevin Gibbons [kgibbons@NishanSystems.com] Charles Monia [cmonia@NishanSystems.com] Josh Tseng [jtseng@NishanSystems.com] Franco Travostino [travos@nortelnetworks.com] TC: Franco Travostino [travos@nortelnetworks.com] Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs ------_=_NextPart_001_01C25842.4871F970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: WG last call on "Definitions of Managed Objects = for iFCP"

All,

We would like to announce IPS WG last = call on the draft "Definitions of Managed Objects For iFCP = ".
The last call period is for two = weeks, ending at 5pm EST on Monday, September 23.

Editorial comments may be directly = sent to the editor/authors of the document --
with copy to myself = [erodrigu@brocade.com], David Black [black_david@emc.com] and Franco = Travostino [travos@nortelnetworks.com]

Technical comments should be sent to = the IPS mailing list for discussion.

Summary:
Draft:  =         =         Definitions of Managed = Objects for iFCP
URL:    =         http://www.ietf.org/internet-drafts/draft-ietf-ips-ifc= p-mib-02.txt
Period: =         2 weeks, ending at 5pm = Monday, Sept 23
Editor: =         Kevin Gibbons = [kgibbons@NishanSystems.com]
Authors:        Kevin Gibbons = [kgibbons@NishanSystems.com]
        =         Charles Monia [cmonia@NishanSystems.com]
        =         Josh Tseng [jtseng@NishanSystems.com]
        =         Franco Travostino [travos@nortelnetworks.com]
TC:     =         Franco Travostino = [travos@nortelnetworks.com]

Thanks,

Elizabeth Rodriguez & David = Black,
IPS co-chairs


------_=_NextPart_001_01C25842.4871F970-- From owner-ips@ece.cmu.edu Mon Sep 9 17:19:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17055 for ; Mon, 9 Sep 2002 17:19:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g89Kaa009033 for ips-outgoing; Mon, 9 Sep 2002 16:36:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g89KaWo09022 for ; Mon, 9 Sep 2002 16:36:32 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g89KaQO19039 for ; Mon, 9 Sep 2002 13:36:26 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Sep 2002 13:36:26 -0700 Message-ID: From: Elizabeth Rodriguez To: "IPS Mailing List (E-mail)" Subject: IPS-All: FCIP draft sent onto ADs for further processing. Date: Mon, 9 Sep 2002 13:36:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25840.907122C0" 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_01C25840.907122C0 Content-Type: text/plain; charset="iso-8859-1" Hi all, A note to let you know that the FCIP draft was sent on to the ADs today for further processing. A reminder on what happens now: The ADs will review the documents, determine if they feel these documents are ready to go forward or not. Things they look for when reviewing the draft are: Technical quality, interoperability, completeness, security, nits, readability and usability/usefulness. They may return the documents for further processing by the authors/working group if they feel it is not ready to be forwarded. Once they have completed this review, and feel that the document is ready, it will be submitted for IETF Last Call, which will be a minimum of a two week period. We will keep this list updated on the progress of the drafts. Thanks Elizabeth Rodriguez IPS co-chair ------_=_NextPart_001_01C25840.907122C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: FCIP draft sent onto ADs for further = processing.

Hi all,
A note to let you know that the FCIP = draft was sent on to the ADs today for further processing.
A reminder on what happens = now:
The ADs will review the documents, = determine if they feel these documents are ready to go forward or = not.
Things they look for when reviewing the = draft are:
Technical quality, interoperability, = completeness, security, nits, readability and = usability/usefulness.
They may return the documents for = further processing by the authors/working group if they feel it is not = ready to be forwarded.

Once they have completed this review, = and feel that the document is ready, it will be submitted for IETF Last = Call, which will be a minimum of a two week period.

We will keep this list updated on the = progress of the drafts.
Thanks
Elizabeth Rodriguez
IPS co-chair

------_=_NextPart_001_01C25840.907122C0-- From owner-ips@ece.cmu.edu Mon Sep 9 17:20:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17071 for ; Mon, 9 Sep 2002 17:20:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g89KqMm10132 for ips-outgoing; Mon, 9 Sep 2002 16:52:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g89KqKo10127 for ; Mon, 9 Sep 2002 16:52:20 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g89KqEO20080 for ; Mon, 9 Sep 2002 13:52:14 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Sep 2002 13:52:14 -0700 Message-ID: From: Elizabeth Rodriguez To: "IPS Mailing List (E-mail)" Subject: IPS-All: Reminder: 3 drafts complete last call this week Date: Mon, 9 Sep 2002 13:52:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25842.C646A6C0" 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_01C25842.C646A6C0 Content-Type: text/plain; charset="iso-8859-1" Just a reminder, We have 3 drafts in WG last call that complete last call this week. 1) Finding FCIP Entities Using SLPv2 URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-slp-03.txt Period: 2 weeks, ending at 5pm Tuesday, Sept 10 2) Bootstrapping Clients using the iSCSI Protocol URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-boot-06.txt Period: 2 weeks, ending at 5pm Thursday, Sept 12 3) iSCSI Naming and Discovery URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-06.txt Period: 2 weeks, ending at 5pm Thursday, Sept 12 Please get any comments on these drafts in. Technical comments to the reflector, Editorial comments to editor/authors with copy to TC and David and I. Thanks, Elizabeth ------_=_NextPart_001_01C25842.C646A6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: Reminder: 3 drafts complete last call this = week

Just a reminder,
We have 3 drafts in WG last call that = complete last call this week.

1) Finding FCIP Entities Using SLPv2
URL:    =         http://www.ietf.org/internet-drafts/draft-ietf-ips-fci= p-slp-03.txt
Period: 2 weeks, ending at 5pm = Tuesday, Sept 10

2) Bootstrapping Clients using the iSCSI = Protocol
URL:    =         http://www.ietf.org/internet-drafts/draft-ietf-ips-isc= si-boot-06.txt
Period: 2 weeks, ending at 5pm = Thursday, Sept 12

3) iSCSI Naming and Discovery
URL:    =         http://www.ietf.org/internet-drafts/draft-ietf-ips-isc= si-name-disc-06.txt
Period: 2 weeks, ending at 5pm = Thursday, Sept 12

Please get any comments on these = drafts in.
Technical comments to the reflector, =
Editorial comments to editor/authors = with copy to TC and David and I.

Thanks,

Elizabeth

------_=_NextPart_001_01C25842.C646A6C0-- From owner-ips@ece.cmu.edu Mon Sep 9 21:54:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22083 for ; Mon, 9 Sep 2002 21:53:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8A1EJY23979 for ips-outgoing; Mon, 9 Sep 2002 21:14:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8A1EGo23974 for ; Mon, 9 Sep 2002 21:14:16 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g8A1DsO07868; Mon, 9 Sep 2002 18:13:54 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Sep 2002 18:13:54 -0700 Message-ID: From: Elizabeth Rodriguez To: "Dave Peterson (E-mail)" Cc: "David Black (E-mail)" , "Murali Rajagopal (E-mail)" , "IPS Mailing List (E-mail)" Subject: A few comments on "Finding FCIP Entities Using SLPv2" -- 1 techn ical. Date: Mon, 9 Sep 2002 18:13:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25867.53D551C0" 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_01C25867.53D551C0 Content-Type: text/plain; charset="iso-8859-1" 1) (Technical) Section 6.1 (pg 9) Think this section needs cleaning up. I think what we need to say here is that SLPv2 security MUST be implemented and IPsec for use with SLPv2 MAY be implemented. When confidentiality is needed, SLPv2 with IPsec must be used. When confidentiality is not needed, SLPv2 security may be used. 2) (Editorial) Has this draft been compared to and synchronized to the Security draft version 15 yet? 3) (Editorial) Titles on pages 2- show "FCIP and SLPV2". This should probably be changed to "Finding FCIP Entities Using SLPv2" 4) (Editorial) Section 4.1, just below figure 1 (pg. 4) "As indicated in the above drawing above" -- change to "As indicated in the drawing above" 5) (Editorial) Section 4.2 (pg 5): Should the recommendations to handle NAPTs/NATs be made stronger -- since run time recommendation, can not use upper case form of reserved words, but can use lower case. e.g. Suggested change: "Use a fully-qualified domain name instead of IP address in service URLs and in the mgmt-entity attribute." to "A fully-qualified domain name should be used in service URLs and mgmt-entity attribute" 6) (Editorial) Section 4.2, (pg 6) "Use the default IANA-assigned FCIP TCP port number in service URLs, , when possible." -- Remove second "," 7) (Editorial) References need to be separated into Normative and Non-normative sections. 8) (Editorial) FCIP and Security draft references need to be updated. ------_=_NextPart_001_01C25867.53D551C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A few comments on "Finding FCIP Entities Using SLPv2" = -- 1 technical.

1) (Technical) Section 6.1 (pg 9) = Think this section needs cleaning up.
I think what we need to say here is = that SLPv2 security MUST be implemented and  IPsec for use with = SLPv2 MAY be implemented.

When confidentiality is needed, SLPv2 = with IPsec must be used.  When confidentiality is not needed, = SLPv2 security may be used.

2) (Editorial) Has this draft been = compared to and synchronized to the Security draft version 15 = yet?
3) (Editorial)  Titles on pages = 2- show "FCIP and SLPV2".  This should probably be = changed to "Finding FCIP = Entities Using SLPv2"

4) (Editorial) Section 4.1, just = below figure 1 (pg. 4) "As indicated in the above drawing = above" -- change to "As indicated in the drawing = above"

5) (Editorial) Section 4.2 (pg = 5):  Should the recommendations to handle NAPTs/NATs be made = stronger -- since run time recommendation, can not use upper case form = of reserved words, but can use lower case.

e.g. Suggested change: = "Use a fully-qualified = domain name instead of IP address in service URLs and in the = mgmt-entity attribute." to "A fully-qualified domain name = should be used in service URLs and mgmt-entity = attribute"

6) (Editorial) Section 4.2, (pg 6) = "Use the default IANA-assigned FCIP TCP port number in service = URLs, , when possible."  -- Remove second = ","

7) (Editorial) References need to be = separated into Normative and Non-normative sections.
8) (Editorial) FCIP and Security = draft references need to be updated.

------_=_NextPart_001_01C25867.53D551C0-- From owner-ips@ece.cmu.edu Mon Sep 9 22:04:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22324 for ; Mon, 9 Sep 2002 22:04:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8A1kw225392 for ips-outgoing; Mon, 9 Sep 2002 21:46:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8A1kuo25388 for ; Mon, 9 Sep 2002 21:46:56 -0400 (EDT) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel13.hp.com (Postfix) with ESMTP id BCB18400611; Mon, 9 Sep 2002 18:46:50 -0700 (PDT) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id AE773E0009E; Mon, 9 Sep 2002 18:46:25 -0700 (PDT) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 9 Sep 2002 18:46:15 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF7B1@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Elizabeth Rodriguez'" , "IPS Mailing List (E-mail)" Cc: "Kaladhar Voruganti (E-mail)" , "David Black (E-mail)" Subject: iSCSI: Last call issues for the Naming and Discovery document Date: Mon, 9 Sep 2002 18:46:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2586B.D902F5B0" 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_01C2586B.D902F5B0 Content-Type: text/plain; charset="iso-8859-1" Some cleanup items for the iSCSI Naming and Discovery document: 1) Sec.1 p.5 and p. 14 define "iSCSI Address" but contradict each other. p. 5 defines it as simply and IP address [& port] and p. 14 says it's the iSCSI name and IP addr [+port]. Paragraph 5 needs to be modified to match p. 14. 2) Sec. 1 p. 17 says In this example, Robert's SSN is like the iSCSI Name, his phone number and addresses are analogous to the TCP addresses which make up an iSCSI session, and "Robert Smith" would be a human-friendly label for this person. The statement that Robert Smith's addresses are like an iSCSI session makes no sense to me. An iSCSI session is a relationship between two separate iSCSI nodes. Robert's addresses are only one end of the relationship. Perhaps this paragraph means to say his phone number, etc. are like an iSCSI nodes TCP addresses? 3) Sec. 1.1 p. 1 first sentence "iSCSI has given the Organizational naming authority additional flexibility by permitting it to hand out local naming authority to subordinate organizations." I suggest changing this to "The iSCSI naming scheme was constructed to give an organizational naming authority the flexibility to further subdivide the responsibility for name creation to subordinate naming authorities." Use of "capital O" in Organization implies there's some globally defined naming authority that this sentence is referring to. 4) General comment on section 1.1 To reflect the definition in the iSCSI main draft, sec. 2.2.6.3.2, either the examples need to be changed to show the ":" after the reversed domain name in the string, or the text needs to be changed to say that these substrings are sub-domain names. 5)sec. 1.1, p 15 - this example is missing the ":" following the reversed domain name. 6)sec. 3, p 1 - the last sentence is missing something. It's "Moreover, iSCSI discovery mechanism only deals with target discovery and one still needs to use the SCSI protocol for LUN discovery." and should be "Moreover, the iSCSI discovery mechanisms listed here only deal with target discovery and one still needs to use the SCSI protocol for LUN discovery." 7) sec. 3 p 2 - 2nd sentence is missing something. It's "The goal of iSCSI discovery mechanism is to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." and should be "The goal of iSCSI discovery mechanisms are to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." 8) sec. 3, p 5 the sentence "This mechanism assumes that the IP address and TCP port information are already available to the initiator." is missing something, should be "This mechanism assumes that the target's IP address and TCP port information are already available to the initiator." 9) appendix B.3, I think there's a typo in the first sentence. "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to real iSCSI targets as it chooses." should be "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to SCSI targets as it chooses." 10) appendix B.4 another typo? "An iSCSI proxy is a SCSI gateway..." should be "An iSCSI proxy is an iSCSI gateway.." 11) appendix B.5, p 4 refers to a "DMZ" There is no definition of this term in this document. Needs to either be defined or substitute some more descriptive phrase here. Regards, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard ------_=_NextPart_001_01C2586B.D902F5B0 Content-Type: text/html; charset="iso-8859-1" IPS-All: Reminder: 3 drafts complete last call this week
Some cleanup items for the iSCSI Naming and Discovery document:
 
1) Sec.1 p.5 and p. 14 define "iSCSI Address" but contradict each other.  p. 5 defines it as simply and IP address [& port] and p. 14 says it's the iSCSI name and IP addr [+port].  Paragraph 5 needs to be modified to match p. 14.
 
2) Sec. 1 p. 17 says
 
In this example, Robert's SSN is like the iSCSI Name, his phone number and addresses are analogous to the TCP addresses which make up an iSCSI session, and "Robert Smith" would be a human-friendly label for this person.
The statement that Robert Smith's addresses are like an iSCSI session makes no sense to me.  An iSCSI session is a relationship between two separate iSCSI nodes.  Robert's addresses are only one end of the relationship.  Perhaps this paragraph means to say his phone number, etc. are like an iSCSI nodes TCP addresses?
 
3) Sec. 1.1 p. 1 first sentence "iSCSI has given the Organizational naming authority additional flexibility by permitting it to hand out local naming authority to
   subordinate organizations."
 
I suggest changing this to "The iSCSI naming scheme was constructed to give an organizational naming authority the flexibility to further subdivide the responsibility for name creation to subordinate naming authorities."  Use of "capital O" in Organization implies there's some globally defined naming authority that this sentence is referring to. 
 
4) General comment on section 1.1  To reflect the definition in the iSCSI main draft, sec. 2.2.6.3.2,  either the examples need to be changed to show the ":" after the reversed domain name in the string, or the text needs to be changed to say that these substrings are sub-domain names.
 
5)sec. 1.1, p 15 - this example is missing the ":" following the reversed domain name.
 
6)sec. 3, p 1 - the last sentence is missing something.  It's "Moreover, iSCSI discovery  mechanism only deals with target discovery and one still needs to use  the SCSI protocol for LUN discovery." and should be "Moreover, the iSCSI discovery  mechanisms listed here only deal with target discovery and one still needs to use the SCSI protocol for LUN discovery."
 
7) sec. 3 p 2 - 2nd sentence is missing something. It's "The goal of iSCSI discovery mechanism is to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." and should be "The goal of iSCSI discovery  mechanisms are to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." 
 
8) sec. 3, p 5  the sentence "This mechanism assumes that the IP address and TCP port information are already available to the initiator." is missing something, should be "This mechanism assumes that the target's IP address and TCP port information are already available to the initiator."
 
9) appendix B.3, I think there's a typo in the first sentence.  "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to real iSCSI targets as it chooses." should be "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to SCSI targets as it chooses."

10)  appendix B.4 another typo?  "An iSCSI proxy is a SCSI gateway..." should be "An iSCSI proxy is an iSCSI gateway.."
 
11) appendix B.5, p 4 refers to a "DMZ"  There is no definition of this term in this document.  Needs to either be defined or substitute some more descriptive phrase here.
 

Regards,

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions
Hewlett-Packard

------_=_NextPart_001_01C2586B.D902F5B0-- From owner-ips@ece.cmu.edu Tue Sep 10 10:17:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15159 for ; Tue, 10 Sep 2002 10:17:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8ADU2h02747 for ips-outgoing; Tue, 10 Sep 2002 09:30:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8ADTxo02738 for ; Tue, 10 Sep 2002 09:29:59 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8ADTmKB018127; Tue, 10 Sep 2002 06:29:48 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8ADTmZH005326; Tue, 10 Sep 2002 06:29:48 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA29440; Tue, 10 Sep 2002 06:29:47 -0700 (PDT) Message-ID: <3D7DF85C.F749643C@cisco.com> Date: Tue, 10 Sep 2002 08:49:16 -0500 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: Prasenjit Sarkar , Duncan Missimer , Costa Sapuntzakis , Elizabeth Rodriguez , David Black , John Hufferd , IPS Subject: iSCSI Boot Last Call - Technical Comments 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 only a few technical comments on the boot draft. The editorials have been sent to the authors. The draft looks good! Page 4 > The "LUN" field is a hexadecimal representation of the 8-byte LU > number. Digits above 9 may be either lower or upper case, and all 16 > nibbles must be present. If the LUN field is blank, then LUN 0 is > assumed. Since most LUNs are just 16 bits (and many of these are even smaller), I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual LUN value into a field in the DHCP GUI is quite error-prone, since in a DHCP server's user interface or /etc/dhcpd.conf, this string will be entered directly by the end user. So in addition to the rules above, how about: - If the LUN field contains four or fewer hex digits, these digits constitute the LUN number from which to boot. Page 5 > It is possible that the port number obtained from the Discovery > Service may conflict with the one obtained from the DHCP service. In > such a case, the implementor has the option to try both port numbers > in the Boot stage. In this case, I think that we should pick one to take precedence, instead of leaving it up to the implementor. Since the discovery service should have the most up-to-date IP address and port number information, I think that it should be the one that is used. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 10 11:58:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18381 for ; Tue, 10 Sep 2002 11:58:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AExMR08191 for ips-outgoing; Tue, 10 Sep 2002 10:59:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AExJo08184 for ; Tue, 10 Sep 2002 10:59:19 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8AEwNEG241360; Tue, 10 Sep 2002 10:58:25 -0400 Received: from d03nmar1.almaden.ibm.com (d03nmar1.almaden.ibm.com [9.1.20.239]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8AExBac116154; Tue, 10 Sep 2002 08:59:11 -0600 Importance: Normal To: Mark Bakke Cc: Prasenjit Sarkar , Duncan Missimer , Costa Sapuntzakis , Elizabeth Rodriguez , David Black , John Hufferd , IPS Subject: Re: iSCSI Boot Last Call - Technical Comments X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Jim Hafner Date: Tue, 10 Sep 2002 07:59:04 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build V60_M14_08012002 Release Candidate|August 01, 2002) at 09/10/2002 07:59:17, Serialize complete at 09/10/2002 07:59:17 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005224BD88256C30_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005224BD88256C30_= Content-Type: text/plain; charset="us-ascii" Mark, I would rather not go the route your going with the LUN number issue. GUIs can always do the translation to more nibbles under the covers. Besides, if you have a LUN that has only 16bits or less of significant (i.e., nonzero) digits, you'll need to carefully specify where these digits go in the 8 byte defined SCSI LUN and that depends on the LUN number convention of the target. So, to avoid that can of worms and the extra descriptions required, I'd suggest leaving this as an 8byte (16 hex nibble) field. On the other point, I have no opinion. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: Prasenjit Sarkar , Duncan Missimer , Costa Sapuntzakis , Elizabeth Rodriguez , David Black , John Hufferd/San Jose/IBM@IBMUS, IPS cc: Subject: iSCSI Boot Last Call - Technical Comments I have only a few technical comments on the boot draft. The editorials have been sent to the authors. The draft looks good! Page 4 > The "LUN" field is a hexadecimal representation of the 8-byte LU > number. Digits above 9 may be either lower or upper case, and all 16 > nibbles must be present. If the LUN field is blank, then LUN 0 is > assumed. Since most LUNs are just 16 bits (and many of these are even smaller), I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual LUN value into a field in the DHCP GUI is quite error-prone, since in a DHCP server's user interface or /etc/dhcpd.conf, this string will be entered directly by the end user. So in addition to the rules above, how about: - If the LUN field contains four or fewer hex digits, these digits constitute the LUN number from which to boot. Page 5 > It is possible that the port number obtained from the Discovery > Service may conflict with the one obtained from the DHCP service. In > such a case, the implementor has the option to try both port numbers > in the Boot stage. In this case, I think that we should pick one to take precedence, instead of leaving it up to the implementor. Since the discovery service should have the most up-to-date IP address and port number information, I think that it should be the one that is used. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 005224BD88256C30_= Content-Type: text/html; charset="us-ascii"
Mark,

I would rather not go the route your going with the LUN number issue.  GUIs can always do the translation to more nibbles under the covers.  Besides, if you have a LUN that has only 16bits or less of significant (i.e., nonzero) digits, you'll need to carefully specify where these digits go in the 8 byte defined SCSI LUN and that depends on the LUN number convention of the target.   So, to avoid that can of worms and the extra descriptions required, I'd suggest leaving this as an 8byte (16 hex nibble) field.
On the other point, I have no opinion.

Jim Hafner

Sent by:        owner-ips@ece.cmu.edu

To:        Prasenjit Sarkar <psarkar@almaden.ibm.com>, Duncan Missimer <duncan_missimer@hp.com>, Costa Sapuntzakis <csapuntz@stanford.edu>, Elizabeth Rodriguez <erodrigu@Brocade.COM>, David Black <Black_David@emc.com>, John Hufferd/San Jose/IBM@IBMUS, IPS <ips@ece.cmu.edu>
cc:        
Subject:        iSCSI Boot Last Call - Technical Comments




I have only a few technical comments on the boot draft.  The editorials
have been sent to the authors.  The draft looks good!
Page 4
>    The "LUN" field is a hexadecimal representation of the 8-byte LU
>    number.  Digits above 9 may be either lower or upper case, and all 16
>    nibbles must be present. If the LUN field is blank, then LUN 0 is
>    assumed.
Since most LUNs are just 16 bits (and many of these are even smaller),
I'd like to relax this a bit.  Typing 14 or 15 zeroes plus the actual
LUN value into a field in the DHCP GUI is quite error-prone, since in
a DHCP server's user interface or /etc/dhcpd.conf, this string will be
entered directly by the end user.
So in addition to the rules above, how about:
- If the LUN field contains four or fewer hex digits, these digits
constitute the LUN number from which to boot.


Page 5
>    It is possible that the port number obtained from the Discovery
>    Service may conflict with the one obtained from the DHCP service. In
>    such a case, the implementor has the option to try both port numbers
>    in the Boot stage.
In this case, I think that we should pick one to take precedence, instead
of leaving it up to the implementor.  Since the discovery service should
have the most up-to-date IP address and port number information, I think
that it should be the one that is used.

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 005224BD88256C30_=-- From owner-ips@ece.cmu.edu Tue Sep 10 12:37:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19392 for ; Tue, 10 Sep 2002 12:37:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AGBCT13025 for ips-outgoing; Tue, 10 Sep 2002 12:11:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AGB8o13018; Tue, 10 Sep 2002 12:11:08 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8AGB2KB002793; Tue, 10 Sep 2002 09:11:02 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8AGB01b026033; Tue, 10 Sep 2002 09:11:00 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA07506; Tue, 10 Sep 2002 09:10:58 -0700 (PDT) Message-ID: <3D7E1E24.980D329C@cisco.com> Date: Tue, 10 Sep 2002 11:30:28 -0500 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: Prasenjit Sarkar CC: Jim Hafner , David Black , Costa Sapuntzakis , Duncan Missimer , Elizabeth Rodriguez , IPS , John Hufferd , owner-ips@ece.cmu.edu Subject: Re: iSCSI Boot Last Call - Technical Comments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It would be nice if the GUI could handle this. However, a DHCP GUI (Microsoft, for example), only provides a place to paste in the entire root-path option; it won't give you separate fields to type in the IP address, LUN, and target name. So the user is left with the job of correctly typing in the root-path option. We found (through experience) that the LUN field was particularly frustrating, expecially since a 16-bit LUN value actually appears in the top characters of the LUN field. For example, LUN 12 (hex 0x0c) would appear as: 000c000000000000 in the option string. Getting the wrong number of zeroes before or after either causes the option to be refused by a network boot program, or causes the wrong LUN to be tried. Either way, the user has to decide what the problem is, fix the LUN string, and try again. It's also a bit non-intuitive since most users would expect that the LUN should have been entered as 000000000000000c (BTW, I missed a zero counting that last one, and I caught it because the length looked wrong comparing it to the previous one). Anyway, this is an extremely easy thing to do to make our users' lives easier, and we have no control over adding iSCSI user interface capabilities to DHCP servers. I really think that this is the right thing to do. -- Mark Prasenjit Sarkar wrote: > > > > > > Mark, > > I tend to agree with Jim that machines can help with 8-byte entities. > > Regarding the prioritization, I do not doubt that your assertion will > generally hold true, but at the same time, I feel that we should not make > any assumptions about the order of updates to the Discovery and DHCP > databases in a boot environment. However, if people insist, I can make the > change. > > Thanks, > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose > > > Jim Hafner > > bm.com> cc: Prasenjit Sarkar , Duncan > Sent by: Missimer , Costa Sapuntzakis > owner-ips@ece.cmu , Elizabeth Rodriguez > .edu , David Black , > John Hufferd/San Jose/IBM@IBMUS, IPS > Subject: Re: iSCSI Boot Last Call - Technical Comments > 09/10/2002 07:59 > AM > > > > Mark, > > I would rather not go the route your going with the LUN number issue. GUIs > can always do the translation to more nibbles under the covers. Besides, > if you have a LUN that has only 16bits or less of significant (i.e., > nonzero) digits, you'll need to carefully specify where these digits go in > the 8 byte defined SCSI LUN and that depends on the LUN number convention > of the target. So, to avoid that can of worms and the extra descriptions > required, I'd suggest leaving this as an 8byte (16 hex nibble) field. > > On the other point, I have no opinion. > > Jim Hafner > > Sent by: owner-ips@ece.cmu.edu > > To: Prasenjit Sarkar , Duncan Missimer > , Costa Sapuntzakis , > Elizabeth Rodriguez , David Black > , John Hufferd/San Jose/IBM@IBMUS, IPS > > cc: > Subject: iSCSI Boot Last Call - Technical Comments > > I have only a few technical comments on the boot draft. The editorials > have been sent to the authors. The draft looks good! > > Page 4 > > > The "LUN" field is a hexadecimal representation of the 8-byte LU > > number. Digits above 9 may be either lower or upper case, and all 16 > > nibbles must be present. If the LUN field is blank, then LUN 0 is > > assumed. > > Since most LUNs are just 16 bits (and many of these are even smaller), > I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual > LUN value into a field in the DHCP GUI is quite error-prone, since in > a DHCP server's user interface or /etc/dhcpd.conf, this string will be > entered directly by the end user. > > So in addition to the rules above, how about: > > - If the LUN field contains four or fewer hex digits, these digits > constitute the LUN number from which to boot. > > Page 5 > > > It is possible that the port number obtained from the Discovery > > Service may conflict with the one obtained from the DHCP service. In > > such a case, the implementor has the option to try both port numbers > > in the Boot stage. > > In this case, I think that we should pick one to take precedence, instead > of leaving it up to the implementor. Since the discovery service should > have the most up-to-date IP address and port number information, I think > that it should be the one that is used. > > -- > 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 Tue Sep 10 12:39:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19431 for ; Tue, 10 Sep 2002 12:39:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AGE5f13182 for ips-outgoing; Tue, 10 Sep 2002 12:14:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AGE3o13177 for ; Tue, 10 Sep 2002 12:14:03 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8AGDp3x005420 for ; Tue, 10 Sep 2002 09:13:51 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8AGDsH0010772 for ; Tue, 10 Sep 2002 09:13:54 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA10023 for ; Tue, 10 Sep 2002 09:13:53 -0700 (PDT) Message-ID: <3D7E1ED2.3B3B6630@cisco.com> Date: Tue, 10 Sep 2002 11:33:22 -0500 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: IPS Subject: iSCSI SLP: Updated identity model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The iSCSI SLP template currently supports an access-list attribute for each registered iSCSI URL. This access-list is a list of iSCSI initiator names that are to be allowed access to the IP address and target in the URL. Since this attribute was added, we have added more authentication methods to the iSCSI authentication MIB, including access control by IP address and CHAP or SRP credentials, as well as methods to keep track of multiple identities. To support accurate discovery searches by initiators looking for appropriate targets, I'd like to propose the following modifications to the current SLP template: 1. Rename access-list to auth-name, to reflect that this is really a list of names that can access the target. 2. Add an auth-addr attribute, which takes a list of IP addresses of hosts allowed to access the target. 3. Add an auth-cred attribute, which lists the CHAP and/or SRP usernames allowed to access the target (subject, of course, to the host providing the correct password which is not published via SLP). 4. Change the default value of auth-name from "iscsi" to "any", to be consistent with other list wildcards. 5. Add an optional, opaque "identity" string to the end of the URL, to allow the above attributes to be used in different combinations (I'll try to explain the reason for this better below; it's easier after the attributes have been properly described). These attributes would work together with the same semantics described in the authentication MIB: 1. An initiator, to access a target, must have: - an initiator name matching one name in the auth-name - an IP address matching one address in the auth-addr - a CHAP or SRP credential matching one user name in the auth-cred. 2. If auth-name contains the value "any", the initiator name requirement is ignored. 3. If the auth-addr contains the value "any", the IP address requirement is ignored. 4. If the auth-cred contains the value "any", the CHAP/SRP requirement is ignored. So the new template would include: auth-name = string M X # A list of iSCSI Initiator Names that can access this target. # Normal iSCSI names will be 80 characters or less; max length is 255. # Normally, only one or a few values will be in the list. # Using the equivalence search on this will evaluate to "true" # if any one of the items in this list matches the query. # If this list contains the default name "any", any initiator # is allowed to access this target, provided it matches the # other auth-xxx attributes. auth-addr = string M X # A list of initiator IP addresses (or host names) which will # be allowed access to this target. If this list contains the # default name "any", any IP address is allowed access to this # target, provided it matches the other auth-xxx attributes. auth-cred = string M X # A list of credentials which will be allowed access to the target # (provided they can provide the correct password or other # authenticator). Entries in this list are of the form # "method/identifier", where the currently defined methods are # "chap" and "srp", both of which take usernames as their identifiers. These attributes are use by an initiator when doing SLP discovery, so that only appropriate targets are found. In the following example, suppose that the initiator has the initiator name "iqn.com.mydisk:host47", IP addresses 10.1.1.47 and 10.1.2.47, and can use both a CHAP user name of "foo" and an SRP user name of "my-user-name". This initiator needs to locate targets that will accept its identity. Example: Service: service:iscsi:target Scope: initiator-scope Query: &(|(auth-name=iqn.com.mydisk:host47)(auth-name=any) |(auth-addr=10.1.1.47)(auth-addr=10.1.2.47)(auth-addr=any) |(auth-cred=chap/foo)(auth-cred=srp/my-user-name)(auth-cred=any)) Note that it's possible for the initiator to have multiple identities that are acceptable to the target, so multiple URLs for the same target and address may be returned. It is up to the iSCSI initiator as the user of SLP sort this out. Also note that if an initiator does not include all three auth- attributes in its query, it is very likely to receive URLs to which it is not allowed access. It must be prepared to handle the fact that it will not be able to log in to these. A well- behaved iSCSI initiator must search using all three attributes. Now, back to that opaque identity thing. Basically, all of the above attributes can be used as described in the authentication MIB to say things like: auth-name=iqn.com.mydisk:host1, iqn.com.mydisk:host2 auth-addr=10.1.1.1-10.1.1.254, 10.2.1.1 auth-cred=chap/user42 This translates to "if the initiator name is iqn.com.mydisk:host1 or iqn.com.mydisk.host2 and the IP address is in the range 10.1.1.1 to 10.1.1.254 or is 10.2.1.1, and the CHAP user name is user42, the initiator can access the target." This is reasonably powerful by itself. However, it can't also express that the target can also be accessed by an initiator that provides SRP user name "srp-name1" from any initiator name or IP address. To do that requires an additional set of attributes: auth-name=any auth-addr=any auth-cred=srp/srp-name1 Obviously, we can't combine these two lists of attributes in the same SLP registration for the target. This means we have to have two registrations; one for each of the above identities. Since we can't register the same URL twice (remember the URL contains the IP address, TCP port, and iSCSI target name), we have to have a different URL for each one. Since the basic URL information is the same, we need to add something to make each one unique. The simplest way to do this is the extent the URL, adding an opaque identifier (selected by the target that produces the registration, and ignored by the initiator), for each address-target-identity tuple. Since the "/" character is allowed in the SLP URL but not in the iSCSI target name, we can use it as a separator. Here's the new URL format: template-url-syntax= url-path = ipaddr [ : tcpport ] / iscsi-name [ / identity ] ipaddr = DNS host name or ip address tcpport = decimal tcp port number iscsi-name = iSCSI target name identity = optional initiator identity allowed to access target ; The iscsi-name part of the URL is required and must be the iSCSI ; name of the target being registered. ; A device representing multiple targets must individually ; register each target/address combination with SLP. ; ; Example: ; service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678 Here are some examples using the above target, and the previously- described identies: Registration #1: service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678/1 auth-name=iqn.com.mydisk:host1, iqn.com.mydisk:host2 auth-addr=10.1.1.1-10.1.1.254, 10.2.1.1 auth-cred=chap/user42 Registration #2: service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678/1 auth-name=any auth-addr=any auth-cred=srp/srp-name1 This scheme has the added advantage of being completely consistent with the iSCSI and Authentication MIBs. Thoughts? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 10 12:39:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19446 for ; Tue, 10 Sep 2002 12:39:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AG1bE12396 for ips-outgoing; Tue, 10 Sep 2002 12:01:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AG1ao12391 for ; Tue, 10 Sep 2002 12:01:36 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8AG1LEG177092; Tue, 10 Sep 2002 12:01:21 -0400 Received: from d03nm694.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8AG1IKd039040; Tue, 10 Sep 2002 12:01:18 -0400 Subject: Re: iSCSI Boot Last Call - Technical Comments To: Jim Hafner Cc: David Black , Costa Sapuntzakis , Duncan Missimer , Elizabeth Rodriguez , IPS , John Hufferd , Mark Bakke , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Prasenjit Sarkar Date: Tue, 10 Sep 2002 09:00:55 -0700 X-MIMETrack: Serialize by Router on D03NM694/03/M/IBM(Build V60_09042002A|September 04, 2002) at 09/10/2002 10:01:19 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, I tend to agree with Jim that machines can help with 8-byte entities. Regarding the prioritization, I do not doubt that your assertion will generally hold true, but at the same time, I feel that we should not make any assumptions about the order of updates to the Discovery and DHCP databases in a boot environment. However, if people insist, I can make the change. Thanks, Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Jim Hafner bm.com> cc: Prasenjit Sarkar , Duncan Sent by: Missimer , Costa Sapuntzakis owner-ips@ece.cmu , Elizabeth Rodriguez .edu , David Black , John Hufferd/San Jose/IBM@IBMUS, IPS Subject: Re: iSCSI Boot Last Call - Technical Comments 09/10/2002 07:59 AM Mark, I would rather not go the route your going with the LUN number issue. GUIs can always do the translation to more nibbles under the covers. Besides, if you have a LUN that has only 16bits or less of significant (i.e., nonzero) digits, you'll need to carefully specify where these digits go in the 8 byte defined SCSI LUN and that depends on the LUN number convention of the target. So, to avoid that can of worms and the extra descriptions required, I'd suggest leaving this as an 8byte (16 hex nibble) field. On the other point, I have no opinion. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: Prasenjit Sarkar , Duncan Missimer , Costa Sapuntzakis , Elizabeth Rodriguez , David Black , John Hufferd/San Jose/IBM@IBMUS, IPS cc: Subject: iSCSI Boot Last Call - Technical Comments I have only a few technical comments on the boot draft. The editorials have been sent to the authors. The draft looks good! Page 4 > The "LUN" field is a hexadecimal representation of the 8-byte LU > number. Digits above 9 may be either lower or upper case, and all 16 > nibbles must be present. If the LUN field is blank, then LUN 0 is > assumed. Since most LUNs are just 16 bits (and many of these are even smaller), I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual LUN value into a field in the DHCP GUI is quite error-prone, since in a DHCP server's user interface or /etc/dhcpd.conf, this string will be entered directly by the end user. So in addition to the rules above, how about: - If the LUN field contains four or fewer hex digits, these digits constitute the LUN number from which to boot. Page 5 > It is possible that the port number obtained from the Discovery > Service may conflict with the one obtained from the DHCP service. In > such a case, the implementor has the option to try both port numbers > in the Boot stage. In this case, I think that we should pick one to take precedence, instead of leaving it up to the implementor. Since the discovery service should have the most up-to-date IP address and port number information, I think that it should be the one that is used. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 10 14:45:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23315 for ; Tue, 10 Sep 2002 14:45:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AI0nH20839 for ips-outgoing; Tue, 10 Sep 2002 14:00:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AI0ko20833 for ; Tue, 10 Sep 2002 14:00:46 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g8AI0cs06329; Tue, 10 Sep 2002 11:00:38 -0700 From: "Amir Shalit" To: "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , "'Elizabeth Rodriguez'" , "IPS Mailing List \(E-mail\)" Cc: "Kaladhar Voruganti \(E-mail\)" , "David Black \(E-mail\)" Subject: RE: iSCSI: Last call issues for the Naming and Discovery document Date: Tue, 10 Sep 2002 11:00:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030B_01C258B9.4AA9A0E0" 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 V5.50.4807.1700 In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87805CCF7B1@xrose06.rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_030B_01C258B9.4AA9A0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit IPS-All: Reminder: 3 drafts complete last call this weekB.4 is a subset of B.3 and can be dropped. In case we keep it, I suggest the following text: An iSCSI gateway is a SCSI gateway presenting only virtual iSCSI targets and virtual iSCSI initiators. A virtual iSCSI device is also called an iSCSI proxy. instead of: "An iSCSI proxy is a SCSI gateway that happens to be terminating the iSCSI protocol on both sides, rather than translate between iSCSI and some other transport." An iSCSI proxy by itself is not a gateway making above sentence inaccurate. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of KRUEGER,MARJORIE (HP-Roseville,ex1) Sent: Monday, September 09, 2002 6:46 PM To: 'Elizabeth Rodriguez'; IPS Mailing List (E-mail) Cc: Kaladhar Voruganti (E-mail); David Black (E-mail) Subject: iSCSI: Last call issues for the Naming and Discovery document Some cleanup items for the iSCSI Naming and Discovery document: 1) Sec.1 p.5 and p. 14 define "iSCSI Address" but contradict each other. p. 5 defines it as simply and IP address [& port] and p. 14 says it's the iSCSI name and IP addr [+port]. Paragraph 5 needs to be modified to match p. 14. 2) Sec. 1 p. 17 says In this example, Robert's SSN is like the iSCSI Name, his phone number and addresses are analogous to the TCP addresses which make up an iSCSI session, and "Robert Smith" would be a human-friendly label for this person. The statement that Robert Smith's addresses are like an iSCSI session makes no sense to me. An iSCSI session is a relationship between two separate iSCSI nodes. Robert's addresses are only one end of the relationship. Perhaps this paragraph means to say his phone number, etc. are like an iSCSI nodes TCP addresses? 3) Sec. 1.1 p. 1 first sentence "iSCSI has given the Organizational naming authority additional flexibility by permitting it to hand out local naming authority to subordinate organizations." I suggest changing this to "The iSCSI naming scheme was constructed to give an organizational naming authority the flexibility to further subdivide the responsibility for name creation to subordinate naming authorities." Use of "capital O" in Organization implies there's some globally defined naming authority that this sentence is referring to. 4) General comment on section 1.1 To reflect the definition in the iSCSI main draft, sec. 2.2.6.3.2, either the examples need to be changed to show the ":" after the reversed domain name in the string, or the text needs to be changed to say that these substrings are sub-domain names. 5)sec. 1.1, p 15 - this example is missing the ":" following the reversed domain name. 6)sec. 3, p 1 - the last sentence is missing something. It's "Moreover, iSCSI discovery mechanism only deals with target discovery and one still needs to use the SCSI protocol for LUN discovery." and should be "Moreover, the iSCSI discovery mechanisms listed here only deal with target discovery and one still needs to use the SCSI protocol for LUN discovery." 7) sec. 3 p 2 - 2nd sentence is missing something. It's "The goal of iSCSI discovery mechanism is to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." and should be "The goal of iSCSI discovery mechanisms are to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." 8) sec. 3, p 5 the sentence "This mechanism assumes that the IP address and TCP port information are already available to the initiator." is missing something, should be "This mechanism assumes that the target's IP address and TCP port information are already available to the initiator." 9) appendix B.3, I think there's a typo in the first sentence. "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to real iSCSI targets as it chooses." should be "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to SCSI targets as it chooses." 10) appendix B.4 another typo? "An iSCSI proxy is a SCSI gateway..." should be "An iSCSI proxy is an iSCSI gateway.." 11) appendix B.5, p 4 refers to a "DMZ" There is no definition of this term in this document. Needs to either be defined or substitute some more descriptive phrase here. Regards, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard ------=_NextPart_000_030B_01C258B9.4AA9A0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: Reminder: 3 drafts complete last call this = week

B.4 is=20 a subset of B.3 and can be dropped. In case we keep = it,
I=20 suggest the following text:
 
An=20 iSCSI gateway is a SCSI gateway presenting only virtual iSCSI=20 targets
and=20 virtual iSCSI initiators. A virtual iSCSI device is also called an iSCSI = proxy.
 
instead of:
 
 "An iSCSI proxy is a = SCSI=20 gateway that happens to be terminating the
   iSCSI = protocol on=20 both sides, rather than translate between iSCSI and
   some = other=20 transport."
 
An=20 iSCSI proxy by itself is not a gateway making above sentence=20 inaccurate.
 
Amir
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of KRUEGER,MARJORIE=20 (HP-Roseville,ex1)
Sent: Monday, September 09, 2002 6:46=20 PM
To: 'Elizabeth Rodriguez'; IPS Mailing List=20 (E-mail)
Cc: Kaladhar Voruganti (E-mail); David Black=20 (E-mail)
Subject: iSCSI: Last call issues for the Naming and = Discovery document

Some cleanup items for the = iSCSI Naming=20 and Discovery document:
 
1) Sec.1 p.5 and p. 14 = define "iSCSI=20 Address" but contradict each other.  p. 5 defines it as = simply and=20 IP address [& port] and p. 14 says it's the iSCSI name and IP addr = [+port].  Paragraph 5 needs to be modified to match p.=20 14.
 
2) Sec. 1 p. 17=20 says
 
In this example, Robert's SSN is like the = iSCSI Name,=20 his phone number and addresses are analogous to the TCP addresses = which make=20 up an iSCSI session, and "Robert Smith" would be a human-friendly = label for=20 this person.
The=20 statement that Robert Smith's addresses are like an iSCSI session = makes no=20 sense to me.  An iSCSI session is a relationship between two = separate=20 iSCSI nodes.  Robert's addresses are only one end of the=20 relationship.  Perhaps this paragraph means to say his phone = number, etc.=20 are like an iSCSI nodes TCP addresses?
 
3) Sec. 1.1 p. 1 first sentence "iSCSI has given the Organizational naming authority = additional=20 flexibility by permitting it to hand out local naming authority=20 to
   subordinate = organizations."
 
I=20 suggest changing this to "The iSCSI naming scheme was constructed to = give an=20 organizational naming authority the flexibility to further subdivide = the=20 responsibility for name creation to subordinate naming = authorities."  Use=20 of "capital O" in Organization implies there's some globally defined = naming=20 authority that this sentence is referring to.  =
 
4)=20 General comment on section 1.1  To reflect the definition in the = iSCSI=20 main draft, sec. 2.2.6.3.2,  either the examples need to be = changed to=20 show the ":" after the reversed domain name in the string, or the text = needs=20 to be changed to say that these substrings are sub-domain=20 names.
 
5)sec. 1.1, p 15 - this example is missing the ":" following = the=20 reversed domain name.
 
6)sec. 3, p 1 - the last sentence is missing something.  = It's "Moreover, = iSCSI=20 discovery  mechanism only deals with target discovery and one = still needs=20 to use  the SCSI protocol for LUN discovery." and=20 should be "Moreover, the iSCSI discovery  mechanisms = listed=20 here only deal with target discovery and one still needs to = use the=20 SCSI protocol for LUN discovery."
 
7) sec. 3 p=20 2 - 2nd sentence is missing something. It's "The=20 goal of iSCSI discovery mechanism is to provide low overhead support = for small=20 iSCSI setups, and scalable discovery solutions for large enterprise = setups."=20 and should be "The goal of iSCSI = discovery =20 mechanisms are to provide low overhead support for small iSCSI=20 setups, and scalable discovery solutions for large enterprise=20 setups." 
 
8) sec. 3, p=20 5  the = sentence "This mechanism assumes that the IP address = and TCP port=20 information are already available to the initiator." is missing = something,=20 should be "This mechanism assumes that the target's IP = address and=20 TCP port information are already available to the=20 initiator."
 
9) appendix=20 B.3, I think there's a typo in the first sentence.  "This gateway presents = logical=20 targets (iSCSI Names) to the initiators, and maps them to real iSCSI = targets=20 as it chooses." should be "This gateway = presents=20 logical targets (iSCSI Names) to the initiators, and maps them to SCSI = targets=20 as it chooses."

10) =20 appendix B.4 another typo?  "An iSCSI proxy = is a SCSI=20 gateway..." should be "An iSCSI proxy is = an iSCSI=20 gateway.."
 
11) appendix=20 B.5, p 4 refers to a "DMZ"  There is no definition of this term = in this=20 document.  Needs to either be defined or substitute some more = descriptive=20 phrase here.
 

Regards,

Marjorie=20 Krueger
Networked Storage Architecture
Networked Storage=20 Solutions
Hewlett-Packard

------=_NextPart_000_030B_01C258B9.4AA9A0E0-- From owner-ips@ece.cmu.edu Tue Sep 10 15:43:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25110 for ; Tue, 10 Sep 2002 15:43:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AJ2c825347 for ips-outgoing; Tue, 10 Sep 2002 15:02:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AJ2ao25339 for ; Tue, 10 Sep 2002 15:02:36 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8AJ2UKB027915; Tue, 10 Sep 2002 12:02:30 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8AJ2SAw029290; Tue, 10 Sep 2002 12:02:28 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA29708; Tue, 10 Sep 2002 12:02:23 -0700 (PDT) Message-ID: <3D7E4650.88CD30D8@cisco.com> Date: Tue, 10 Sep 2002 14:21:52 -0500 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: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: "'Elizabeth Rodriguez'" , "IPS Mailing List (E-mail)" , "Kaladhar Voruganti (E-mail)" , "David Black (E-mail)" Subject: Re: iSCSI: Last call issues for the Naming and Discovery document References: <6BD67FFB937FD411A04F00D0B74FE87805CCF7B1@xrose06.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Marjorie- Thanks for the detailed comments. I've embedded my responses below. -- Mark > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > Some cleanup items for the iSCSI Naming and Discovery document: > > 1) Sec.1 p.5 and p. 14 define "iSCSI Address" but contradict each other. p. 5 defines it as > simply and IP address [& port] and p. 14 says it's the iSCSI name and IP addr [+port]. Paragraph > 5 needs to be modified to match p. 14. How about (page 5): iSCSI nodes also have addresses. An iSCSI address specifies a single path to an iSCSI node and consists of the iSCSI name, plus a transport (TCP) address which uses the following format: [:] Where is one of: > > 2) Sec. 1 p. 17 says > > In this example, Robert's SSN is like the iSCSI Name, his phone number and addresses are analogous > to the TCP addresses which make up an iSCSI session, and "Robert Smith" would be a human-friendly > label for this person. > The statement that Robert Smith's addresses are like an iSCSI session makes no sense to me. An > iSCSI session is a relationship between two separate iSCSI nodes. Robert's addresses are only one > end of the relationship. Perhaps this paragraph means to say his phone number, etc. are like an > iSCSI nodes TCP addresses? You're right; that's what I had meant. I'll fix the wording. > > 3) Sec. 1.1 p. 1 first sentence "iSCSI has given the Organizational naming authority additional > flexibility by permitting it to hand out local naming authority to > subordinate organizations." > > I suggest changing this to "The iSCSI naming scheme was constructed to give an organizational > naming authority the flexibility to further subdivide the responsibility for name creation to > subordinate naming authorities." Use of "capital O" in Organization implies there's some globally > defined naming authority that this sentence is referring to. > > 4) General comment on section 1.1 To reflect the definition in the iSCSI main draft, sec. > 2.2.6.3.2, either the examples need to be changed to show the ":" after the reversed domain name > in the string, or the text needs to be changed to say that these substrings are sub-domain names. > > 5)sec. 1.1, p 15 - this example is missing the ":" following the reversed domain name. > > 6)sec. 3, p 1 - the last sentence is missing something. It's "Moreover, iSCSI discovery > mechanism only deals with target discovery and one still needs to use the SCSI protocol for LUN > discovery." and should be "Moreover, the iSCSI discovery mechanisms listed here only deal with > target discovery and one still needs to use the SCSI protocol for LUN discovery." > > 7) sec. 3 p 2 - 2nd sentence is missing something. It's "The goal of iSCSI discovery mechanism is > to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large > enterprise setups." and should be "The goal of iSCSI discovery mechanisms are to provide low > overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise > setups." > > 8) sec. 3, p 5 the sentence "This mechanism assumes that the IP address and TCP port information > are already available to the initiator." is missing something, should be "This mechanism assumes > that the target's IP address and TCP port information are already available to the initiator." > > 9) appendix B.3, I think there's a typo in the first sentence. "This gateway presents logical > targets (iSCSI Names) to the initiators, and maps them to real iSCSI targets as it chooses." > should be "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to > SCSI targets as it chooses." > > 10) appendix B.4 another typo? "An iSCSI proxy is a SCSI gateway..." should be "An iSCSI proxy > is an iSCSI gateway.." > > 11) appendix B.5, p 4 refers to a "DMZ" There is no definition of this term in this document. > Needs to either be defined or substitute some more descriptive phrase here. > > > Regards, > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions > Hewlett-Packard -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 10 17:11:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26677 for ; Tue, 10 Sep 2002 17:11:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AKNYS01620 for ips-outgoing; Tue, 10 Sep 2002 16:23:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AKNUo01614 for ; Tue, 10 Sep 2002 16:23:30 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8AKNIKB017950; Tue, 10 Sep 2002 13:23:18 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8AKNGf0014163; Tue, 10 Sep 2002 13:23:17 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA06461; Tue, 10 Sep 2002 13:23:15 -0700 (PDT) Message-ID: <3D7E593F.C597A422@cisco.com> Date: Tue, 10 Sep 2002 15:42:39 -0500 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: Amir Shalit CC: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , "'Elizabeth Rodriguez'" , "IPS Mailing List (E-mail)" , "Kaladhar Voruganti (E-mail)" , "David Black (E-mail)" Subject: Re: iSCSI: Last call issues for the Naming and Discovery document References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit When we first added B.4, it was intended to be a special case of the B.3 gateway, with the exception that a B.3 iSCSI-iSCSI gateway would fully terminate iSCSI targets and initiators on both sides, while a B.4 proxy would be aware that both sides are iSCSI, and may pass some PDUs, and the data CRC, through the box without modification. It may also handle target naming and other things more transparently. The main reason to have this section was to point out that if a SCSI gateway is aware that iSCSI is used on both sides, it can do things like keep the CRC all the way through. Amir writes: > B.4 is a subset of B.3 and can be dropped. In case we keep it, > I suggest the following text: > > An iSCSI gateway is a SCSI gateway presenting only virtual iSCSI targets > and virtual iSCSI initiators. A virtual iSCSI device is also called an iSCSI proxy. > > instead of: > > "An iSCSI proxy is a SCSI gateway that happens to be terminating the > iSCSI protocol on both sides, rather than translate between iSCSI and > some other transport." > > An iSCSI proxy by itself is not a gateway making above sentence inaccurate. > > Amir -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 10 17:46:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27423 for ; Tue, 10 Sep 2002 17:46:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8ALN4K05546 for ips-outgoing; Tue, 10 Sep 2002 17:23:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8ALN0o05522; Tue, 10 Sep 2002 17:23:00 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8ALKW3x027878; Tue, 10 Sep 2002 14:20:32 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8ALKZ4x022636; Tue, 10 Sep 2002 14:20:35 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA00937; Tue, 10 Sep 2002 14:20:20 -0700 (PDT) Message-ID: <3D7E66A6.47D62427@cisco.com> Date: Tue, 10 Sep 2002 16:39:50 -0500 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: Prasenjit Sarkar CC: Constantine Sapuntzakis , Jim Hafner , David Black , Duncan Missimer , Elizabeth Rodriguez , IPS , John Hufferd , owner-ips@ece.cmu.edu Subject: Re: iSCSI Boot Last Call - Technical Comments References: <3D7E1E24.980D329C@cisco.com> <3D7E3743.5050306@stanford.edu> <005601c2590e$882a4140$fe150109@almaden.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It's true that in many cases, zero is all that is needed. However, consider an application where a host will be able to be booted from a small set of different LUNs, perhaps to change O/S levels in a test environment, or to make a different application available on the host. Having these LUNs mapped behind the same iSCSI target and editing the LUN in the root-path string is a lot simpler than having several different targets, and changing the iSCSI name in the root-path. I still think that allowing a 16-bit LUN in the string is the simplest, least error-prone approach. -- Mark Prasenjit Sarkar wrote: > > Mark and Costa, > > If you are so very concerned with entering the value wrong, you can leave > the lun value blank. The lun value defaults to zero and you can always use > lun mapping in the target to make the boot lun to be zero for the initiator. > > Analogous to the other issue you brought up, I think this is going to be the > common case. > > Sincerely, > Prasenjit > > ----- Original Message ----- > From: "Constantine Sapuntzakis" > To: "Mark Bakke" > Cc: "Prasenjit Sarkar" ; "Jim Hafner" > ; "David Black" ; "Duncan > Missimer" ; "Elizabeth Rodriguez" > ; "IPS" ; "John Hufferd" > ; > Sent: Tuesday, September 10, 2002 11:17 AM > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > Many people also use emacs/vi for their configuration too, so they have > > the same problem Mark has with the GUI. I would agree with Mark on his > > point about entry being error-prone. > > > > -Costa > > > > > > Mark Bakke wrote: > > > It would be nice if the GUI could handle this. However, a DHCP > > > GUI (Microsoft, for example), only provides a place to paste in > > > the entire root-path option; it won't give you separate fields > > > to type in the IP address, LUN, and target name. So the user is > > > left with the job of correctly typing in the root-path option. > > > We found (through experience) that the LUN field was particularly > > > frustrating, expecially since a 16-bit LUN value actually appears > > > in the top characters of the LUN field. For example, LUN 12 (hex > > > 0x0c) would appear as: > > > > > > 000c000000000000 > > > > > > in the option string. Getting the wrong number of zeroes before > > > or after either causes the option to be refused by a network boot > > > program, or causes the wrong LUN to be tried. Either way, the > > > user has to decide what the problem is, fix the LUN string, > > > and try again. It's also a bit non-intuitive since most users > > > would expect that the LUN should have been entered as > > > > > > 000000000000000c > > > > > > (BTW, I missed a zero counting that last one, and I caught it > > > because the length looked wrong comparing it to the previous > > > one). > > > > > > Anyway, this is an extremely easy thing to do to make our users' > > > lives easier, and we have no control over adding iSCSI user > > > interface capabilities to DHCP servers. > > > > > > I really think that this is the right thing to do. > > > > > > -- > > > Mark > > > > > > Prasenjit Sarkar wrote: > > > > > >> > > >> > > >> > > >> > > >>Mark, > > >> > > >>I tend to agree with Jim that machines can help with 8-byte entities. > > >> > > >>Regarding the prioritization, I do not doubt that your assertion will > > >>generally hold true, but at the same time, I feel that we should not > make > > >>any assumptions about the order of updates to the Discovery and DHCP > > >>databases in a boot environment. However, if people insist, I can make > the > > >>change. > > >> > > >>Thanks, > > >> > > >> Prasenjit Sarkar > > >> Research Staff Member > > >> IBM Almaden Research > > >> San Jose > > >> > > >> > > >> Jim Hafner > > >> > > >> bm.com> cc: Prasenjit > Sarkar , Duncan > > >> Sent by: Missimer > , Costa Sapuntzakis > > >> owner-ips@ece.cmu , > Elizabeth Rodriguez > > >> .edu , > David Black , > > >> John Hufferd/San > Jose/IBM@IBMUS, IPS > > >> Subject: Re: iSCSI Boot > Last Call - Technical Comments > > >> 09/10/2002 07:59 > > >> AM > > >> > > >> > > >> > > >>Mark, > > >> > > >>I would rather not go the route your going with the LUN number issue. > GUIs > > >>can always do the translation to more nibbles under the covers. > Besides, > > >>if you have a LUN that has only 16bits or less of significant (i.e., > > >>nonzero) digits, you'll need to carefully specify where these digits go > in > > >>the 8 byte defined SCSI LUN and that depends on the LUN number > convention > > >>of the target. So, to avoid that can of worms and the extra > descriptions > > >>required, I'd suggest leaving this as an 8byte (16 hex nibble) field. > > >> > > >>On the other point, I have no opinion. > > >> > > >>Jim Hafner > > >> > > >>Sent by: owner-ips@ece.cmu.edu > > >> > > >>To: Prasenjit Sarkar , Duncan Missimer > > >>, Costa Sapuntzakis , > > >>Elizabeth Rodriguez , David Black > > >>, John Hufferd/San Jose/IBM@IBMUS, IPS > > >> > > >>cc: > > >>Subject: iSCSI Boot Last Call - Technical Comments > > >> > > >>I have only a few technical comments on the boot draft. The editorials > > >>have been sent to the authors. The draft looks good! > > >> > > >>Page 4 > > >> > > >> > > >>> The "LUN" field is a hexadecimal representation of the 8-byte LU > > >>> number. Digits above 9 may be either lower or upper case, and all > 16 > > >>> nibbles must be present. If the LUN field is blank, then LUN 0 is > > >>> assumed. > > >> > > >>Since most LUNs are just 16 bits (and many of these are even smaller), > > >>I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual > > >>LUN value into a field in the DHCP GUI is quite error-prone, since in > > >>a DHCP server's user interface or /etc/dhcpd.conf, this string will be > > >>entered directly by the end user. > > >> > > >>So in addition to the rules above, how about: > > >> > > >>- If the LUN field contains four or fewer hex digits, these digits > > >>constitute the LUN number from which to boot. > > >> > > >>Page 5 > > >> > > >> > > >>> It is possible that the port number obtained from the Discovery > > >>> Service may conflict with the one obtained from the DHCP service. In > > >>> such a case, the implementor has the option to try both port numbers > > >>> in the Boot stage. > > >> > > >>In this case, I think that we should pick one to take precedence, > instead > > >>of leaving it up to the implementor. Since the discovery service should > > >>have the most up-to-date IP address and port number information, I think > > >>that it should be the one that is used. > > >> > > >>-- > > >>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 Tue Sep 10 17:48:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27481 for ; Tue, 10 Sep 2002 17:48:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8ALDWn04861 for ips-outgoing; Tue, 10 Sep 2002 17:13:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub2.almaden.ibm.com (p1.almaden.ibm.com [198.4.83.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8ALDRo04854; Tue, 10 Sep 2002 17:13:27 -0400 (EDT) Received: from ibmjh9qh9xf2ft (dyn-9-1-21-254.almaden.ibm.com [9.1.21.254]) by mailhub2.almaden.ibm.com (AIX4.3/8.9.3/8.9.3) with SMTP id OAA18154; Tue, 10 Sep 2002 14:11:43 -0700 Message-ID: <005601c2590e$882a4140$fe150109@almaden.ibm.com> From: "Prasenjit Sarkar" To: "Constantine Sapuntzakis" , "Mark Bakke" Cc: "Jim Hafner" , "David Black" , "Duncan Missimer" , "Elizabeth Rodriguez" , "IPS" , "John Hufferd" , References: <3D7E1E24.980D329C@cisco.com> <3D7E3743.5050306@stanford.edu> Subject: Re: iSCSI Boot Last Call - Technical Comments Date: Tue, 10 Sep 2002 14:10:46 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark and Costa, If you are so very concerned with entering the value wrong, you can leave the lun value blank. The lun value defaults to zero and you can always use lun mapping in the target to make the boot lun to be zero for the initiator. Analogous to the other issue you brought up, I think this is going to be the common case. Sincerely, Prasenjit ----- Original Message ----- From: "Constantine Sapuntzakis" To: "Mark Bakke" Cc: "Prasenjit Sarkar" ; "Jim Hafner" ; "David Black" ; "Duncan Missimer" ; "Elizabeth Rodriguez" ; "IPS" ; "John Hufferd" ; Sent: Tuesday, September 10, 2002 11:17 AM Subject: Re: iSCSI Boot Last Call - Technical Comments > Many people also use emacs/vi for their configuration too, so they have > the same problem Mark has with the GUI. I would agree with Mark on his > point about entry being error-prone. > > -Costa > > > Mark Bakke wrote: > > It would be nice if the GUI could handle this. However, a DHCP > > GUI (Microsoft, for example), only provides a place to paste in > > the entire root-path option; it won't give you separate fields > > to type in the IP address, LUN, and target name. So the user is > > left with the job of correctly typing in the root-path option. > > We found (through experience) that the LUN field was particularly > > frustrating, expecially since a 16-bit LUN value actually appears > > in the top characters of the LUN field. For example, LUN 12 (hex > > 0x0c) would appear as: > > > > 000c000000000000 > > > > in the option string. Getting the wrong number of zeroes before > > or after either causes the option to be refused by a network boot > > program, or causes the wrong LUN to be tried. Either way, the > > user has to decide what the problem is, fix the LUN string, > > and try again. It's also a bit non-intuitive since most users > > would expect that the LUN should have been entered as > > > > 000000000000000c > > > > (BTW, I missed a zero counting that last one, and I caught it > > because the length looked wrong comparing it to the previous > > one). > > > > Anyway, this is an extremely easy thing to do to make our users' > > lives easier, and we have no control over adding iSCSI user > > interface capabilities to DHCP servers. > > > > I really think that this is the right thing to do. > > > > -- > > Mark > > > > Prasenjit Sarkar wrote: > > > >> > >> > >> > >> > >>Mark, > >> > >>I tend to agree with Jim that machines can help with 8-byte entities. > >> > >>Regarding the prioritization, I do not doubt that your assertion will > >>generally hold true, but at the same time, I feel that we should not make > >>any assumptions about the order of updates to the Discovery and DHCP > >>databases in a boot environment. However, if people insist, I can make the > >>change. > >> > >>Thanks, > >> > >> Prasenjit Sarkar > >> Research Staff Member > >> IBM Almaden Research > >> San Jose > >> > >> > >> Jim Hafner > >> > >> bm.com> cc: Prasenjit Sarkar , Duncan > >> Sent by: Missimer , Costa Sapuntzakis > >> owner-ips@ece.cmu , Elizabeth Rodriguez > >> .edu , David Black , > >> John Hufferd/San Jose/IBM@IBMUS, IPS > >> Subject: Re: iSCSI Boot Last Call - Technical Comments > >> 09/10/2002 07:59 > >> AM > >> > >> > >> > >>Mark, > >> > >>I would rather not go the route your going with the LUN number issue. GUIs > >>can always do the translation to more nibbles under the covers. Besides, > >>if you have a LUN that has only 16bits or less of significant (i.e., > >>nonzero) digits, you'll need to carefully specify where these digits go in > >>the 8 byte defined SCSI LUN and that depends on the LUN number convention > >>of the target. So, to avoid that can of worms and the extra descriptions > >>required, I'd suggest leaving this as an 8byte (16 hex nibble) field. > >> > >>On the other point, I have no opinion. > >> > >>Jim Hafner > >> > >>Sent by: owner-ips@ece.cmu.edu > >> > >>To: Prasenjit Sarkar , Duncan Missimer > >>, Costa Sapuntzakis , > >>Elizabeth Rodriguez , David Black > >>, John Hufferd/San Jose/IBM@IBMUS, IPS > >> > >>cc: > >>Subject: iSCSI Boot Last Call - Technical Comments > >> > >>I have only a few technical comments on the boot draft. The editorials > >>have been sent to the authors. The draft looks good! > >> > >>Page 4 > >> > >> > >>> The "LUN" field is a hexadecimal representation of the 8-byte LU > >>> number. Digits above 9 may be either lower or upper case, and all 16 > >>> nibbles must be present. If the LUN field is blank, then LUN 0 is > >>> assumed. > >> > >>Since most LUNs are just 16 bits (and many of these are even smaller), > >>I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual > >>LUN value into a field in the DHCP GUI is quite error-prone, since in > >>a DHCP server's user interface or /etc/dhcpd.conf, this string will be > >>entered directly by the end user. > >> > >>So in addition to the rules above, how about: > >> > >>- If the LUN field contains four or fewer hex digits, these digits > >>constitute the LUN number from which to boot. > >> > >>Page 5 > >> > >> > >>> It is possible that the port number obtained from the Discovery > >>> Service may conflict with the one obtained from the DHCP service. In > >>> such a case, the implementor has the option to try both port numbers > >>> in the Boot stage. > >> > >>In this case, I think that we should pick one to take precedence, instead > >>of leaving it up to the implementor. Since the discovery service should > >>have the most up-to-date IP address and port number information, I think > >>that it should be the one that is used. > >> > >>-- > >>Mark A. Bakke > >>Cisco Systems > >>mbakke@cisco.com > >>763.398.1054 > > > > > > > > From owner-ips@ece.cmu.edu Tue Sep 10 18:33:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28256 for ; Tue, 10 Sep 2002 18:33:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AM6cf08054 for ips-outgoing; Tue, 10 Sep 2002 18:06:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AM6ao08048 for ; Tue, 10 Sep 2002 18:06:36 -0400 (EDT) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 08D4C16EF; Tue, 10 Sep 2002 16:06:36 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with SMTP id F1839482; Tue, 10 Sep 2002 16:05:51 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 16:06:34 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Sep 2002 16:06:34 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00E182AC4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: erodrigu@Brocade.COM, ips@ece.cmu.edu Cc: kaladhar@us.ibm.com, Black_David@emc.com Subject: iSCSI: Last call issues for the Naming and Discovery document Date: Tue, 10 Sep 2002 16:06:24 -0600 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 In the interest of getting these out in a timely fashion, I haven't compared them to the other postings to see if there are duplicates. Pat Thaler Technical issues The third paragraph of 1 has the following text: "An iSCSI node name is also the SCSI device name of an iSCSI device. The iSCSI name of a SCSI device...." The first sentence says the iSCSI node name and SCSI device name are the same but the next sentence uses a different term: iSCSI name which is used through much of the remainder of the document. (There only seems to be one later use of iSCSI node name.) Please state whether iSCSI name the same as iSCSI node name. Also, why does the first sentence use "iSCSI device" but the second sentence use "SCSI device"? It seems that both should use "iSCSI device" I'm not sure if this is technical or editorial because it isn't clear whether the small differences in the terms were intended to refer to different items or whether they should have used the same terms. Appendix B.1 and B.2: This should mention the effect of port redirectors and SOCKS servers on Send Targets because the address mapping performed on the headers will not be performed on Send Targets responses. The Send Targets would need to use the fully qualified domain name form of iSCSI address or, if it must use an IP address form, it would need to know the mapping used by the gateway (and whether the initiator was on the far side of the gateway). Also, either the gateway will have to be configured to map the default port on the initiator side to whatever port the target is using (which could also be the default port; if it isn't the default port the target would have to know to suppress the port number) or the target will have to know the mapping used for ports on the gateway to supply the initiator the right port number in the iSCSI address. Some of the references do not have a reference in the body of the document and don't have a clear relationship to the document. Specifically, [5] IEEE 802 (which would be relevant if MAC address space was discussed at all but it isn't mentioned and [22] and [23] which are Java references. If these references are necessary then text should be added to the body to clarify their relevance. Editorial nits Fifth paragraph of 1: The first sentence would be better: "An iSCSI node also has one or more addresses." to make it clear that a node does not necessarily have just one address. Address examples in 1. For completeness it would be nice for some of the addresses to include a . If none of them do, then they should be renamed examples of domain-name. 2.2 second paragraph below the first show targets listing: The first sentence has a grammar problem. Suggest "allocated to the hosts. The alias can provide a more descriptive name." The appendices should come at the end - after the Author's names. From owner-ips@ece.cmu.edu Tue Sep 10 18:35:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28303 for ; Tue, 10 Sep 2002 18:35:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8ALwhP07600 for ips-outgoing; Tue, 10 Sep 2002 17:58:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8ALwgo07596 for ; Tue, 10 Sep 2002 17:58:42 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel8.hp.com (Postfix) with ESMTP id AF743A00848; Tue, 10 Sep 2002 17:58:41 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id A566A156; Tue, 10 Sep 2002 17:58:41 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Sep 2002 17:58:41 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF7C0@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Mark Bakke'" Cc: "'Elizabeth Rodriguez'" , "IPS Mailing List (E-mail)" , "Kaladhar Voruganti (E-mail)" , "David Black (E-mail)" Subject: RE: iSCSI: Last call issues for the Naming and Discovery document Date: Tue, 10 Sep 2002 17:58:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Responses embedded > > 1) Sec.1 p.5 and p. 14 define "iSCSI Address" but > contradict each other. p. 5 defines it as > > simply and IP address [& port] and p. 14 says it's the > iSCSI name and IP addr [+port]. Paragraph > > 5 needs to be modified to match p. 14. > > How about (sec 1 para 5): > > iSCSI nodes also have addresses. An iSCSI address specifies a single > path to an iSCSI node and consists of the iSCSI name, plus a transport > (TCP) address which uses the following format: OK > > 4) General comment on section 1.1 To reflect the > definition in the iSCSI main draft, sec. > > 2.2.6.3.2, either the examples need to be changed to show > the ":" after the reversed domain name > > in the string, or the text needs to be changed to say that > these substrings are sub-domain names. > > I'm not sure I understand this one. The first three examples > all use the : to illustrate how it can be used to keep conflicts > from happening. The fourth also uses the :, and the fifth chooses > to leave it out (it is optional). Which examples need to be > fixed? The paragraphs don't mention or imply that the string preceeding the colon is a reversed domain name. The iSCSI spec. says the string following the reversed domain name must be prefixed by ":". > > 5)sec. 1.1, p 15 - this example is missing the ":" > following the reversed domain name. > > Since the ':' is optional, I think we should keep one example > without it. The ":" is only optional if nothing follows the reversed domain name. I can see how the current text led you to believe the colon is optional, but if you read the text carefully, the word "optional" applies to the "colon prefixed string" (see the 3rd sentence in that paragraph) > > 11) appendix B.5, p 4 refers to a "DMZ" There is no > definition of this term in this document. > > Needs to either be defined or substitute some more > descriptive phrase here. > > OK. I'll use DMZ (De-Militarized Zone). If we keep an > informative reference to > the Middlebox RFC3303, I can reference their definition. OK From owner-ips@ece.cmu.edu Tue Sep 10 19:34:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29364 for ; Tue, 10 Sep 2002 19:34:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AN8UP11256 for ips-outgoing; Tue, 10 Sep 2002 19:08:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AN8So11252 for ; Tue, 10 Sep 2002 19:08:28 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 149BF977; Tue, 10 Sep 2002 19:08:28 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 091D811D; Tue, 10 Sep 2002 19:08:28 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Sep 2002 19:08:27 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF7C5@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'THALER,PAT (A-Roseville,ex1)'" , Mark Bakke Cc: "IPS Mailing List (E-mail)" Subject: RE: iSCSI: Last call issues for the Naming and Discovery document Date: Tue, 10 Sep 2002 19:08:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > This doesn't seem consistent with the iSCSI > (draft-ietf-ips-iscsi-16) use of "address". I can't find > anywhere where it calls the address the iSCSI name plus a > transport address. For example, in 11.8, it defines target address as: > > TargetAddress=domainname[:port][,portal-group-tag] > > This doesn't include iSCSI name and it does include > portal-group-tag which isn't mentioned in the Naming and > Discovery document. To harmonize the two documents, iSCSI > address should not include the iSCSI name and the option for > portal-group-tag should be added to Naming and Discovery. The iSCSI protocol document is not defining the concept of an iSCSI address, it's specifying the format of a key value pair. The N&D doc is purely an informative discussion of concepts. I don't see any problem with speaking of an iSCSI address as both the iSCSI name and IP address, since you can't address a target without knowing it's iSCSI name. > Also, the use of Address in the iSCSI draft is asymmetrical. > The iSCSI draft only applies the structure of address, > [:], to target addresses. Initiator > address is generally not mentioned. While the iSCSI protocol > doesn't explicitly use initiator addresses, they may be > useful for other things such as management interfaces so a > target can report address along with who is connected. The > Naming and Discovery document should at least explain the > difference between the asymmetry in the use of address in > iSCSI and the symmetry in Naming and Discovery. One might > also mention that a target will be only able to report the > address of a connected initiator in one of the IP formats > because it doesn't ever receive a DNS based name. A target could perform reverse lookup on an address, just as the initiator would have to do a name lookup to find the target's IP address if it had a host name. Marj From owner-ips@ece.cmu.edu Tue Sep 10 19:36:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29420 for ; Tue, 10 Sep 2002 19:36:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8AN1VV10830 for ips-outgoing; Tue, 10 Sep 2002 19:01:31 -0400 (EDT) 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 g8AN1To10821 for ; Tue, 10 Sep 2002 19:01:29 -0400 (EDT) Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5CF1FC6DA; Tue, 10 Sep 2002 17:01:28 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by relcos1.cos.agilent.com (Postfix) with SMTP id F0A88771; Tue, 10 Sep 2002 17:01:08 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 17:01:27 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Sep 2002 17:01:27 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00E182ADE@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Mark Bakke , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "'Elizabeth Rodriguez'" , "IPS Mailing List (E-mail)" , "Kaladhar Voruganti (E-mail)" , "David Black (E-mail)" Subject: RE: iSCSI: Last call issues for the Naming and Discovery document Date: Tue, 10 Sep 2002 17:01:23 -0600 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 Mark, This doesn't seem consistent with the iSCSI (draft-ietf-ips-iscsi-16) use of "address". I can't find anywhere where it calls the address the iSCSI name plus a transport address. For example, in 11.8, it defines target address as: TargetAddress=domainname[:port][,portal-group-tag] This doesn't include iSCSI name and it does include portal-group-tag which isn't mentioned in the Naming and Discovery document. To harmonize the two documents, iSCSI address should not include the iSCSI name and the option for portal-group-tag should be added to Naming and Discovery. Also, the use of Address in the iSCSI draft is asymmetrical. The iSCSI draft only applies the structure of address, [:], to target addresses. Initiator address is generally not mentioned. While the iSCSI protocol doesn't explicitly use initiator addresses, they may be useful for other things such as management interfaces so a target can report address along with who is connected. The Naming and Discovery document should at least explain the difference between the asymmetry in the use of address in iSCSI and the symmetry in Naming and Discovery. One might also mention that a target will be only able to report the address of a connected initiator in one of the IP formats because it doesn't ever receive a DNS based name. Pat -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Marjorie- Thanks for the detailed comments. I've embedded my responses below. -- Mark > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > Some cleanup items for the iSCSI Naming and Discovery document: > > 1) Sec.1 p.5 and p. 14 define "iSCSI Address" but contradict each other. p. 5 defines it as > simply and IP address [& port] and p. 14 says it's the iSCSI name and IP addr [+port]. Paragraph > 5 needs to be modified to match p. 14. How about (page 5): iSCSI nodes also have addresses. An iSCSI address specifies a single path to an iSCSI node and consists of the iSCSI name, plus a transport (TCP) address which uses the following format: [:] Where is one of: From owner-ips@ece.cmu.edu Tue Sep 10 20:24:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00220 for ; Tue, 10 Sep 2002 20:24:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8ANfPm12940 for ips-outgoing; Tue, 10 Sep 2002 19:41:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8ANfNo12936 for ; Tue, 10 Sep 2002 19:41:23 -0400 (EDT) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id A2F5E14B3; Tue, 10 Sep 2002 17:41:22 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by relcos2.cos.agilent.com (Postfix) with SMTP id 4F3F7489; Tue, 10 Sep 2002 17:40:38 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 17:41:18 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Sep 2002 17:41:18 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00E182AF5@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mbakke@cisco.com, psarkar@almaden.ibm.com, duncan_missimer@hp.com, csapuntz@stanford.edu, erodrigu@Brocade.COM, Black_David@emc.com, hufferd@us.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI Boot Last Call - Technical Comments Date: Tue, 10 Sep 2002 17:41:18 -0600 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 Assuming that the requirement for all 16 bits to be present is not changed, the current text is logically contradictory. "...all 16 nibbles must be present. If the LUN field is blank,..." If the LUN field is blank all 16 nibbles are not present. I suggest "...upper case. If the LUN field is not blank, all 16 nibbles must be present." Pat -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Tuesday, September 10, 2002 6:49 AM To: Prasenjit Sarkar; Duncan Missimer; Costa Sapuntzakis; Elizabeth Rodriguez; David Black; John Hufferd; IPS Subject: iSCSI Boot Last Call - Technical Comments I have only a few technical comments on the boot draft. The editorials have been sent to the authors. The draft looks good! Page 4 > The "LUN" field is a hexadecimal representation of the 8-byte LU > number. Digits above 9 may be either lower or upper case, and all 16 > nibbles must be present. If the LUN field is blank, then LUN 0 is > assumed. Since most LUNs are just 16 bits (and many of these are even smaller), I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual LUN value into a field in the DHCP GUI is quite error-prone, since in a DHCP server's user interface or /etc/dhcpd.conf, this string will be entered directly by the end user. So in addition to the rules above, how about: - If the LUN field contains four or fewer hex digits, these digits constitute the LUN number from which to boot. Page 5 > It is possible that the port number obtained from the Discovery > Service may conflict with the one obtained from the DHCP service. In > such a case, the implementor has the option to try both port numbers > in the Boot stage. In this case, I think that we should pick one to take precedence, instead of leaving it up to the implementor. Since the discovery service should have the most up-to-date IP address and port number information, I think that it should be the one that is used. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Sep 10 20:27:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00377 for ; Tue, 10 Sep 2002 20:27:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8B03eM13975 for ips-outgoing; Tue, 10 Sep 2002 20:03:40 -0400 (EDT) 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 [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8B03bo13968 for ; Tue, 10 Sep 2002 20:03:37 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel7.hp.com (Postfix) with ESMTP id B102C8054E7; Tue, 10 Sep 2002 20:03:36 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id RAA04701; Tue, 10 Sep 2002 17:03:35 -0700 (PDT) Message-ID: <010b01c25926$ab18e540$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Mark Bakke" , "Prasenjit Sarkar" Cc: "Constantine Sapuntzakis" , References: <3D7E1E24.980D329C@cisco.com> <3D7E3743.5050306@stanford.edu> <005601c2590e$882a4140$fe150109@almaden.ibm.com> <3D7E66A6.47D62427@cisco.com> Subject: Re: iSCSI Boot Last Call - Technical Comments Date: Tue, 10 Sep 2002 17:03:33 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > consider an application where a host will be able to be booted from > a small set of different LUNs, perhaps to change O/S levels in a > test environment How does the DHCP server distinguish which O/S level the client wants to boot from, to provide the right LUN in the Root Path? If it's a well-known LUN->O/S_rev mapping that the client boot code uses by convention, then there's no issue with always leaving the LUN field blank (for 0) in the DHCP response. What am I missing? > I still think that allowing a 16-bit LUN in the string is the > simplest, least error-prone approach. AFAICT, this assumes that the user knows how to figure out which 16-bits of the 64-bit LUN are to be entered into the DHCP server file. I'm not sure that's a valid assumption. My preference is to require 64-bits always (if non-blank), so the boot client can simply copy the value in the iSCSI PDUs as-is. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Mark Bakke" To: "Prasenjit Sarkar" Cc: "Constantine Sapuntzakis" ; "Jim Hafner" ; "David Black" ; "Duncan Missimer" ; "Elizabeth Rodriguez" ; "IPS" ; "John Hufferd" ; Sent: Tuesday, September 10, 2002 2:39 PM Subject: Re: iSCSI Boot Last Call - Technical Comments > It's true that in many cases, zero is all that is needed. However, > consider an application where a host will be able to be booted from > a small set of different LUNs, perhaps to change O/S levels in a > test environment, or to make a different application available > on the host. Having these LUNs mapped behind the same iSCSI target > and editing the LUN in the root-path string is a lot simpler than > having several different targets, and changing the iSCSI name in > the root-path. > > I still think that allowing a 16-bit LUN in the string is the > simplest, least error-prone approach. > > -- > Mark > > Prasenjit Sarkar wrote: > > > > Mark and Costa, > > > > If you are so very concerned with entering the value wrong, you can leave > > the lun value blank. The lun value defaults to zero and you can always use > > lun mapping in the target to make the boot lun to be zero for the initiator. > > > > Analogous to the other issue you brought up, I think this is going to be the > > common case. > > > > Sincerely, > > Prasenjit > > > > ----- Original Message ----- > > From: "Constantine Sapuntzakis" > > To: "Mark Bakke" > > Cc: "Prasenjit Sarkar" ; "Jim Hafner" > > ; "David Black" ; "Duncan > > Missimer" ; "Elizabeth Rodriguez" > > ; "IPS" ; "John Hufferd" > > ; > > Sent: Tuesday, September 10, 2002 11:17 AM > > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > > > Many people also use emacs/vi for their configuration too, so they have > > > the same problem Mark has with the GUI. I would agree with Mark on his > > > point about entry being error-prone. > > > > > > -Costa > > > > > > > > > Mark Bakke wrote: > > > > It would be nice if the GUI could handle this. However, a DHCP > > > > GUI (Microsoft, for example), only provides a place to paste in > > > > the entire root-path option; it won't give you separate fields > > > > to type in the IP address, LUN, and target name. So the user is > > > > left with the job of correctly typing in the root-path option. > > > > We found (through experience) that the LUN field was particularly > > > > frustrating, expecially since a 16-bit LUN value actually appears > > > > in the top characters of the LUN field. For example, LUN 12 (hex > > > > 0x0c) would appear as: > > > > > > > > 000c000000000000 > > > > > > > > in the option string. Getting the wrong number of zeroes before > > > > or after either causes the option to be refused by a network boot > > > > program, or causes the wrong LUN to be tried. Either way, the > > > > user has to decide what the problem is, fix the LUN string, > > > > and try again. It's also a bit non-intuitive since most users > > > > would expect that the LUN should have been entered as > > > > > > > > 000000000000000c > > > > > > > > (BTW, I missed a zero counting that last one, and I caught it > > > > because the length looked wrong comparing it to the previous > > > > one). > > > > > > > > Anyway, this is an extremely easy thing to do to make our users' > > > > lives easier, and we have no control over adding iSCSI user > > > > interface capabilities to DHCP servers. > > > > > > > > I really think that this is the right thing to do. > > > > > > > > -- > > > > Mark > > > > > > > > Prasenjit Sarkar wrote: > > > > > > > >> > > > >> > > > >> > > > >> > > > >>Mark, > > > >> > > > >>I tend to agree with Jim that machines can help with 8-byte entities. > > > >> > > > >>Regarding the prioritization, I do not doubt that your assertion will > > > >>generally hold true, but at the same time, I feel that we should not > > make > > > >>any assumptions about the order of updates to the Discovery and DHCP > > > >>databases in a boot environment. However, if people insist, I can make > > the > > > >>change. > > > >> > > > >>Thanks, > > > >> > > > >> Prasenjit Sarkar > > > >> Research Staff Member > > > >> IBM Almaden Research > > > >> San Jose > > > >> > > > >> > > > >> Jim Hafner > > > >> > > > > >> bm.com> cc: Prasenjit > > Sarkar , Duncan > > > >> Sent by: Missimer > > , Costa Sapuntzakis > > > >> owner-ips@ece.cmu , > > Elizabeth Rodriguez > > > >> .edu , > > David Black , > > > >> John Hufferd/San > > Jose/IBM@IBMUS, IPS > > > >> Subject: Re: iSCSI Boot > > Last Call - Technical Comments > > > >> 09/10/2002 07:59 > > > >> AM > > > >> > > > >> > > > >> > > > >>Mark, > > > >> > > > >>I would rather not go the route your going with the LUN number issue. > > GUIs > > > >>can always do the translation to more nibbles under the covers. > > Besides, > > > >>if you have a LUN that has only 16bits or less of significant (i.e., > > > >>nonzero) digits, you'll need to carefully specify where these digits go > > in > > > >>the 8 byte defined SCSI LUN and that depends on the LUN number > > convention > > > >>of the target. So, to avoid that can of worms and the extra > > descriptions > > > >>required, I'd suggest leaving this as an 8byte (16 hex nibble) field. > > > >> > > > >>On the other point, I have no opinion. > > > >> > > > >>Jim Hafner > > > >> > > > >>Sent by: owner-ips@ece.cmu.edu > > > >> > > > >>To: Prasenjit Sarkar , Duncan Missimer > > > >>, Costa Sapuntzakis , > > > >>Elizabeth Rodriguez , David Black > > > >>, John Hufferd/San Jose/IBM@IBMUS, IPS > > > >> > > > >>cc: > > > >>Subject: iSCSI Boot Last Call - Technical Comments > > > >> > > > >>I have only a few technical comments on the boot draft. The editorials > > > >>have been sent to the authors. The draft looks good! > > > >> > > > >>Page 4 > > > >> > > > >> > > > >>> The "LUN" field is a hexadecimal representation of the 8-byte LU > > > >>> number. Digits above 9 may be either lower or upper case, and all > > 16 > > > >>> nibbles must be present. If the LUN field is blank, then LUN 0 is > > > >>> assumed. > > > >> > > > >>Since most LUNs are just 16 bits (and many of these are even smaller), > > > >>I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual > > > >>LUN value into a field in the DHCP GUI is quite error-prone, since in > > > >>a DHCP server's user interface or /etc/dhcpd.conf, this string will be > > > >>entered directly by the end user. > > > >> > > > >>So in addition to the rules above, how about: > > > >> > > > >>- If the LUN field contains four or fewer hex digits, these digits > > > >>constitute the LUN number from which to boot. > > > >> > > > >>Page 5 > > > >> > > > >> > > > >>> It is possible that the port number obtained from the Discovery > > > >>> Service may conflict with the one obtained from the DHCP service. In > > > >>> such a case, the implementor has the option to try both port numbers > > > >>> in the Boot stage. > > > >> > > > >>In this case, I think that we should pick one to take precedence, > > instead > > > >>of leaving it up to the implementor. Since the discovery service should > > > >>have the most up-to-date IP address and port number information, I think > > > >>that it should be the one that is used. > > > >> > > > >>-- > > > >>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 Tue Sep 10 20:44:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00766 for ; Tue, 10 Sep 2002 20:44:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8B0PvC15053 for ips-outgoing; Tue, 10 Sep 2002 20:25:57 -0400 (EDT) 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 g8B0Pso15046 for ; Tue, 10 Sep 2002 20:25:54 -0400 (EDT) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 686139C58; Tue, 10 Sep 2002 18:25:53 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by relcos2.cos.agilent.com (Postfix) with SMTP id 6BD493FC; Tue, 10 Sep 2002 18:25:09 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 18:25:52 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Sep 2002 18:25:52 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00E182B0A@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: psarkar@almaden.ibm.com, duncan_missimer@hp.com, csapuntz@stanford.edu, erodrigu@Brocade.COM, Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI Boot Last Call - Technical Comments Date: Tue, 10 Sep 2002 18:25:51 -0600 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 Technical 4. last two paragraphs: "If the "servername" field is provided by DHCP, then that field is used in conjunction with other associated fields to contact the boot server in the Boot stage (Section 6). However, if the "servername" field is not provided, then the "targetname" field is then used in the Discovery Service stage (Section 5)." Shouldn't the second paragraph say "is used in conjunction with the other associated fields"? "targetname" doesn't provide the LUN or protocol. The "port" field is may be relevant because the Target address needs to be fetched and will include port if necessary. 5. first paragraph "if the DHCP server ... is unaware of the iSCSI Target Port Name" What does Target port name (defined as iSCSI Target Name together with a label that idenifies it as a target port name and the portal group tag) have to do with this? The DHCP server string definition doesn't include a Target port name and even if it did, the discovery service stage would be necessary to convert that into an address. The discovery service stage is required if the DHCP server provided a target name because it converts target name to an IP address and port number. It is also required if the DHCP server didn't provide an iSCSI string. Reference [17]: Can a URL be used as a reference? Intel could change the structure of their website and the URL would no longer locate the document. It would be better to reference a document title. Editorial 4. 5 paragraphs from the end, "several different LU" should be "several different LUs" 4. 3 paragraphs from the end, except for the sentence "If the "servername" field is blank ....", all the other statements about defaults are duplicates of statements in the paragraphs where the fields were defined. Moving the statement about servername to the servername paragraphs above and deleting this paragraph. From owner-ips@ece.cmu.edu Tue Sep 10 22:45:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03122 for ; Tue, 10 Sep 2002 22:45:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8B27qT19440 for ips-outgoing; Tue, 10 Sep 2002 22:07:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8AIMUo22449; Tue, 10 Sep 2002 14:22:30 -0400 (EDT) Received: from stanford.edu ([63.192.219.28]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H2800109J1FXQ@mta7.pltn13.pbi.net>; Tue, 10 Sep 2002 11:22:28 -0700 (PDT) Date: Tue, 10 Sep 2002 11:17:39 -0700 From: Constantine Sapuntzakis Subject: Re: iSCSI Boot Last Call - Technical Comments To: Mark Bakke Cc: Prasenjit Sarkar , Jim Hafner , David Black , Duncan Missimer , Elizabeth Rodriguez , IPS , John Hufferd , owner-ips@ece.cmu.edu Message-id: <3D7E3743.5050306@stanford.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 References: <3D7E1E24.980D329C@cisco.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Many people also use emacs/vi for their configuration too, so they have the same problem Mark has with the GUI. I would agree with Mark on his point about entry being error-prone. -Costa Mark Bakke wrote: > It would be nice if the GUI could handle this. However, a DHCP > GUI (Microsoft, for example), only provides a place to paste in > the entire root-path option; it won't give you separate fields > to type in the IP address, LUN, and target name. So the user is > left with the job of correctly typing in the root-path option. > We found (through experience) that the LUN field was particularly > frustrating, expecially since a 16-bit LUN value actually appears > in the top characters of the LUN field. For example, LUN 12 (hex > 0x0c) would appear as: > > 000c000000000000 > > in the option string. Getting the wrong number of zeroes before > or after either causes the option to be refused by a network boot > program, or causes the wrong LUN to be tried. Either way, the > user has to decide what the problem is, fix the LUN string, > and try again. It's also a bit non-intuitive since most users > would expect that the LUN should have been entered as > > 000000000000000c > > (BTW, I missed a zero counting that last one, and I caught it > because the length looked wrong comparing it to the previous > one). > > Anyway, this is an extremely easy thing to do to make our users' > lives easier, and we have no control over adding iSCSI user > interface capabilities to DHCP servers. > > I really think that this is the right thing to do. > > -- > Mark > > Prasenjit Sarkar wrote: > >> >> >> >> >>Mark, >> >>I tend to agree with Jim that machines can help with 8-byte entities. >> >>Regarding the prioritization, I do not doubt that your assertion will >>generally hold true, but at the same time, I feel that we should not make >>any assumptions about the order of updates to the Discovery and DHCP >>databases in a boot environment. However, if people insist, I can make the >>change. >> >>Thanks, >> >> Prasenjit Sarkar >> Research Staff Member >> IBM Almaden Research >> San Jose >> >> >> Jim Hafner >> >> bm.com> cc: Prasenjit Sarkar , Duncan >> Sent by: Missimer , Costa Sapuntzakis >> owner-ips@ece.cmu , Elizabeth Rodriguez >> .edu , David Black , >> John Hufferd/San Jose/IBM@IBMUS, IPS >> Subject: Re: iSCSI Boot Last Call - Technical Comments >> 09/10/2002 07:59 >> AM >> >> >> >>Mark, >> >>I would rather not go the route your going with the LUN number issue. GUIs >>can always do the translation to more nibbles under the covers. Besides, >>if you have a LUN that has only 16bits or less of significant (i.e., >>nonzero) digits, you'll need to carefully specify where these digits go in >>the 8 byte defined SCSI LUN and that depends on the LUN number convention >>of the target. So, to avoid that can of worms and the extra descriptions >>required, I'd suggest leaving this as an 8byte (16 hex nibble) field. >> >>On the other point, I have no opinion. >> >>Jim Hafner >> >>Sent by: owner-ips@ece.cmu.edu >> >>To: Prasenjit Sarkar , Duncan Missimer >>, Costa Sapuntzakis , >>Elizabeth Rodriguez , David Black >>, John Hufferd/San Jose/IBM@IBMUS, IPS >> >>cc: >>Subject: iSCSI Boot Last Call - Technical Comments >> >>I have only a few technical comments on the boot draft. The editorials >>have been sent to the authors. The draft looks good! >> >>Page 4 >> >> >>> The "LUN" field is a hexadecimal representation of the 8-byte LU >>> number. Digits above 9 may be either lower or upper case, and all 16 >>> nibbles must be present. If the LUN field is blank, then LUN 0 is >>> assumed. >> >>Since most LUNs are just 16 bits (and many of these are even smaller), >>I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual >>LUN value into a field in the DHCP GUI is quite error-prone, since in >>a DHCP server's user interface or /etc/dhcpd.conf, this string will be >>entered directly by the end user. >> >>So in addition to the rules above, how about: >> >>- If the LUN field contains four or fewer hex digits, these digits >>constitute the LUN number from which to boot. >> >>Page 5 >> >> >>> It is possible that the port number obtained from the Discovery >>> Service may conflict with the one obtained from the DHCP service. In >>> such a case, the implementor has the option to try both port numbers >>> in the Boot stage. >> >>In this case, I think that we should pick one to take precedence, instead >>of leaving it up to the implementor. Since the discovery service should >>have the most up-to-date IP address and port number information, I think >>that it should be the one that is used. >> >>-- >>Mark A. Bakke >>Cisco Systems >>mbakke@cisco.com >>763.398.1054 > > From owner-ips@ece.cmu.edu Wed Sep 11 14:46:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20925 for ; Wed, 11 Sep 2002 14:46:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BI3VC19138 for ips-outgoing; Wed, 11 Sep 2002 14:03:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BI3To19133 for ; Wed, 11 Sep 2002 14:03:29 -0400 (EDT) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel10.hp.com (Postfix) with ESMTP id 9D832C00A9D for ; Wed, 11 Sep 2002 11:03:27 -0700 (PDT) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id 5464FE002CC for ; Wed, 11 Sep 2002 11:03:27 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 11:03:27 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF7CB@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: iSCSI:Typo in draft 16? Date: Wed, 11 Sep 2002 11:03:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C259BD.84535520" 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_01C259BD.84535520 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 10, 2002 11:38 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Black_David@emc.com; Elizabeth.G.Rodriguez@123mail.net; John Hufferd Subject: RE: iSCSI:Typo in draft 16 Thanks - Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 11/09/02 01:23 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI:Typo in draft 16 Oop, forgot to add: Is the pagination off? The first page break seems to come too early, but maybe that's deliberate. The indentation got messed up between page 38 and page 39 - the 3rd, 4th 5th bullets have different indentation from the first two bullets. Hi Julian Assuming that you make changes due to IETF last call, can you correct this item? I think there's a typo in sec. 2.2.6.3.1 "Type "iqn." (iSCSI Qualified Name)" The 5th bullet items says "An optional colon (:), or prefixed string within the character set and ^^^^^ length boundaries that the owner of the domain name deems appropriate. " I think the ", or" is a typo? If the string is present, it must be prefixed by a ":" The current wording leave the impression that the ":" is optional. Regards, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard ------_=_NextPart_001_01C259BD.84535520 Content-Type: text/html; charset="iso-8859-1"
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, September 10, 2002 11:38 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Black_David@emc.com; Elizabeth.G.Rodriguez@123mail.net; John Hufferd
Subject: RE: iSCSI:Typo in draft 16


Thanks - Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

11/09/02 01:23

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        RE: iSCSI:Typo in draft 16

       


Oop, forgot to add:
Is the pagination off?  The first page break seems to come too early, but maybe that's deliberate.
 
The indentation got messed up between page 38 and page 39 - the 3rd, 4th 5th bullets have different indentation from the first two bullets.  

Hi Julian

Assuming that you make changes due to IETF last call, can you correct this item?  I think there's a typo in sec. 2.2.6.3.1  "Type "iqn." (iSCSI Qualified Name)"

 The 5th bullet items says

"An optional colon (:), or prefixed string within the character set and
                      ^^^^^
length boundaries that the owner of the domain name deems appropriate. "
 
I think the ", or" is a typo?  If the string is present, it must be prefixed by a ":"  The current wording leave the impression that the ":" is optional.

Regards,
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions
Hewlett-Packard

------_=_NextPart_001_01C259BD.84535520-- From owner-ips@ece.cmu.edu Wed Sep 11 16:47:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24227 for ; Wed, 11 Sep 2002 16:47:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BK8v128170 for ips-outgoing; Wed, 11 Sep 2002 16:08:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BK8to28165 for ; Wed, 11 Sep 2002 16:08:55 -0400 (EDT) Received: from hqmailweb.Crossroads.com ( [65.68.235.6:25]) by mc.va3.ummail.com with SMTP id Z0911-1608-08d100; Wed, 11 Sep 2002 20:08:45 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.Crossroads.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 15:08:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C259CF.0724A9B0" Disposition-Notification-To: "Lee Xing" Subject: iSCSI: Changes made from 0.15 to 0.16 Date: Wed, 11 Sep 2002 15:08:43 -0500 Message-ID: Thread-Topic: iSCSI- draft 16 ready to ship Thread-Index: AcJP80HAudKIkj6RRrKEuH0mE4JcfQJ2o3pA From: "Lee Xing" To: "Julian Satran" Cc: X-OriginalArrivalTime: 11 Sep 2002 20:08:44.0506 (UTC) FILETIME=[07E0A3A0:01C259CF] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C259CF.0724A9B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Julian, =20 Could you please tell me all the changes made from 0.15 to 0.16. =20 I downloaded a 0.16 working draft on 8/30/2002 which contains the = following changes: =20 =20 - Text cleanup - ExpDataSN in TM Reassign can use 0 to say "all unacked" data - Reorganized the recovery section =20 But I'm not sure if more changes have been added to the 0.16 release = version after 8/30/02. =20 Thanks, =20 =20 Lee Xing Crossroads Systems, Inc. =20 =20 =20 ------_=_NextPart_001_01C259CF.0724A9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Julian,
 
Could you please tell me all the changes made = from 0.15=20 to 0.16.
 
I=20 downloaded a 0.16 working draft on 8/30/2002 which contains the following changes: 
 
     - Text=20 cleanup
     - ExpDataSN in TM Reassign can use 0 = to say=20 "all unacked" data
     - Reorganized the = recovery=20 section
 
But I'm not = sure=20 if more changes have been added to = the 0.16=20 release version after 8/30/02.
 
Thanks,
 
 
Lee Xing
Crossroads Systems,=20 Inc.
 
 
 
------_=_NextPart_001_01C259CF.0724A9B0-- From owner-ips@ece.cmu.edu Wed Sep 11 18:48:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27403 for ; Wed, 11 Sep 2002 18:48:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BMOir07200 for ips-outgoing; Wed, 11 Sep 2002 18:24:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BMOeo07189 for ; Wed, 11 Sep 2002 18:24:40 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMOT3x018933; Wed, 11 Sep 2002 15:24:29 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMOWVE010672; Wed, 11 Sep 2002 15:24:32 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA03239; Wed, 11 Sep 2002 15:24:30 -0700 (PDT) Message-ID: <3D7FC72B.2BE1FA04@cisco.com> Date: Wed, 11 Sep 2002 17:43:55 -0500 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: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: "'Elizabeth Rodriguez'" , "IPS Mailing List (E-mail)" , "Kaladhar Voruganti (E-mail)" , "David Black (E-mail)" Subject: Re: iSCSI: Last call issues for the Naming and Discovery document References: <6BD67FFB937FD411A04F00D0B74FE87805CCF7C0@xrose06.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > 4) General comment on section 1.1 To reflect the > > definition in the iSCSI main draft, sec. > > > 2.2.6.3.2, either the examples need to be changed to show > > the ":" after the reversed domain name > > > in the string, or the text needs to be changed to say that > > these substrings are sub-domain names. > > > > I'm not sure I understand this one. The first three examples > > all use the : to illustrate how it can be used to keep conflicts > > from happening. The fourth also uses the :, and the fifth chooses > > to leave it out (it is optional). Which examples need to be > > fixed? > > The paragraphs don't mention or imply that the string preceeding the colon > is a reversed domain name. It discusses this in the examples, but doesn't at the beginning of 1.1. I'll fix this. > The iSCSI spec. says the string following the > reversed domain name must be prefixed by ":". It looks like we are reading the "An optional colon..." part of the spec two different ways. I took it to mean that the colon could be left out of the string if the owner of the reversed domain name was certain that no naming authorities would make use of sub-domains underneath the one being used. Reading it again, I'm not sure which... > > > 5)sec. 1.1, p 15 - this example is missing the ":" > > following the reversed domain name. > > > > Since the ':' is optional, I think we should keep one example > > without it. > > The ":" is only optional if nothing follows the reversed domain name. I can > see how the current text led you to believe the colon is optional, but if > you read the text carefully, the word "optional" applies to the "colon > prefixed string" (see the 3rd sentence in that paragraph) But something has to following the reversed domain name, unless a company manufacturing the name only intends to create one instance of one product. I was under the impression that while using a ":" was optional, adding appropriate uniqueness to the remainder of the name was not. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 11 18:48:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27423 for ; Wed, 11 Sep 2002 18:48:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BMAnm06317 for ips-outgoing; Wed, 11 Sep 2002 18:10:49 -0400 (EDT) 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 g8BMAmo06311 for ; Wed, 11 Sep 2002 18:10:48 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMAfds028872; Wed, 11 Sep 2002 15:10:41 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMAevq001949; Wed, 11 Sep 2002 15:10:40 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA20645; Wed, 11 Sep 2002 15:10:29 -0700 (PDT) Message-ID: <3D7FC3DE.1DCF2F77@cisco.com> Date: Wed, 11 Sep 2002 17:29:50 -0500 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: "Mallikarjun C." CC: Prasenjit Sarkar , Constantine Sapuntzakis , ips@ece.cmu.edu Subject: Re: iSCSI Boot Last Call - Technical Comments References: <3D7E1E24.980D329C@cisco.com> <3D7E3743.5050306@stanford.edu> <005601c2590e$882a4140$fe150109@almaden.ibm.com> <3D7E66A6.47D62427@cisco.com> <010b01c25926$ab18e540$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun- My comments are embedded. -- Mark "Mallikarjun C." wrote: > > > consider an application where a host will be able to be booted from > > a small set of different LUNs, perhaps to change O/S levels in a > > test environment > > How does the DHCP server distinguish which O/S level the client > wants to boot from, to provide the right LUN in the Root Path? The DHCP server doesn't. In this type of environment, the DHCP server is generally under the control of the same test folks who are booting the servers. One would manually change the LUN in the DHCP server GUI or config file, and reboot. The DHCP server doesn't have to do anything special, but it's one more scenario where the LUN field is directly manipulated by a user, which is why I'd like to keep it simple. > If it's a well-known LUN->O/S_rev mapping that the client boot > code uses by convention, then there's no issue with always leaving > the LUN field blank (for 0) in the DHCP response. What am I missing? > > > I still think that allowing a 16-bit LUN in the string is the > > simplest, least error-prone approach. > > AFAICT, this assumes that the user knows how to figure out which > 16-bits of the 64-bit LUN are to be entered into the DHCP server > file. I'm not sure that's a valid assumption. Actually, the user only has to worry about this when the 64-bit LUN field is used. The 16-bit version always ends up in the high bytes of the LUN field in the protocol, and the user never sees this structure, which is really not pretty. I don't think most users will ever want (or need) to see more than a 16-bit LUN. > My preference is to require 64-bits always (if non-blank), so the boot > client can simply copy the value in the iSCSI PDUs as-is. What customer or user looks at iSCSI PDUs? Would they copy and paste one from a network analyzer? This doesn't make sense to me. End users don't care about PDUs. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Mark Bakke" > To: "Prasenjit Sarkar" > Cc: "Constantine Sapuntzakis" ; "Jim Hafner" ; "David Black" > ; "Duncan Missimer" ; "Elizabeth Rodriguez" > ; "IPS" ; "John Hufferd" ; > Sent: Tuesday, September 10, 2002 2:39 PM > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > It's true that in many cases, zero is all that is needed. However, > > consider an application where a host will be able to be booted from > > a small set of different LUNs, perhaps to change O/S levels in a > > test environment, or to make a different application available > > on the host. Having these LUNs mapped behind the same iSCSI target > > and editing the LUN in the root-path string is a lot simpler than > > having several different targets, and changing the iSCSI name in > > the root-path. > > > > I still think that allowing a 16-bit LUN in the string is the > > simplest, least error-prone approach. > > > > -- > > Mark > > > > Prasenjit Sarkar wrote: > > > > > > Mark and Costa, > > > > > > If you are so very concerned with entering the value wrong, you can leave > > > the lun value blank. The lun value defaults to zero and you can always use > > > lun mapping in the target to make the boot lun to be zero for the initiator. > > > > > > Analogous to the other issue you brought up, I think this is going to be the > > > common case. > > > > > > Sincerely, > > > Prasenjit > > > > > > ----- Original Message ----- > > > From: "Constantine Sapuntzakis" > > > To: "Mark Bakke" > > > Cc: "Prasenjit Sarkar" ; "Jim Hafner" > > > ; "David Black" ; "Duncan > > > Missimer" ; "Elizabeth Rodriguez" > > > ; "IPS" ; "John Hufferd" > > > ; > > > Sent: Tuesday, September 10, 2002 11:17 AM > > > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > > > > > Many people also use emacs/vi for their configuration too, so they have > > > > the same problem Mark has with the GUI. I would agree with Mark on his > > > > point about entry being error-prone. > > > > > > > > -Costa > > > > > > > > > > > > Mark Bakke wrote: > > > > > It would be nice if the GUI could handle this. However, a DHCP > > > > > GUI (Microsoft, for example), only provides a place to paste in > > > > > the entire root-path option; it won't give you separate fields > > > > > to type in the IP address, LUN, and target name. So the user is > > > > > left with the job of correctly typing in the root-path option. > > > > > We found (through experience) that the LUN field was particularly > > > > > frustrating, expecially since a 16-bit LUN value actually appears > > > > > in the top characters of the LUN field. For example, LUN 12 (hex > > > > > 0x0c) would appear as: > > > > > > > > > > 000c000000000000 > > > > > > > > > > in the option string. Getting the wrong number of zeroes before > > > > > or after either causes the option to be refused by a network boot > > > > > program, or causes the wrong LUN to be tried. Either way, the > > > > > user has to decide what the problem is, fix the LUN string, > > > > > and try again. It's also a bit non-intuitive since most users > > > > > would expect that the LUN should have been entered as > > > > > > > > > > 000000000000000c > > > > > > > > > > (BTW, I missed a zero counting that last one, and I caught it > > > > > because the length looked wrong comparing it to the previous > > > > > one). > > > > > > > > > > Anyway, this is an extremely easy thing to do to make our users' > > > > > lives easier, and we have no control over adding iSCSI user > > > > > interface capabilities to DHCP servers. > > > > > > > > > > I really think that this is the right thing to do. > > > > > > > > > > -- > > > > > Mark > > > > > > > > > > Prasenjit Sarkar wrote: > > > > > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >>Mark, > > > > >> > > > > >>I tend to agree with Jim that machines can help with 8-byte entities. > > > > >> > > > > >>Regarding the prioritization, I do not doubt that your assertion will > > > > >>generally hold true, but at the same time, I feel that we should not > > > make > > > > >>any assumptions about the order of updates to the Discovery and DHCP > > > > >>databases in a boot environment. However, if people insist, I can make > > > the > > > > >>change. > > > > >> > > > > >>Thanks, > > > > >> > > > > >> Prasenjit Sarkar > > > > >> Research Staff Member > > > > >> IBM Almaden Research > > > > >> San Jose > > > > >> > > > > >> > > > > >> Jim Hafner > > > > >> > > > > > > >> bm.com> cc: Prasenjit > > > Sarkar , Duncan > > > > >> Sent by: Missimer > > > , Costa Sapuntzakis > > > > >> owner-ips@ece.cmu , > > > Elizabeth Rodriguez > > > > >> .edu , > > > David Black , > > > > >> John Hufferd/San > > > Jose/IBM@IBMUS, IPS > > > > >> Subject: Re: iSCSI Boot > > > Last Call - Technical Comments > > > > >> 09/10/2002 07:59 > > > > >> AM > > > > >> > > > > >> > > > > >> > > > > >>Mark, > > > > >> > > > > >>I would rather not go the route your going with the LUN number issue. > > > GUIs > > > > >>can always do the translation to more nibbles under the covers. > > > Besides, > > > > >>if you have a LUN that has only 16bits or less of significant (i.e., > > > > >>nonzero) digits, you'll need to carefully specify where these digits go > > > in > > > > >>the 8 byte defined SCSI LUN and that depends on the LUN number > > > convention > > > > >>of the target. So, to avoid that can of worms and the extra > > > descriptions > > > > >>required, I'd suggest leaving this as an 8byte (16 hex nibble) field. > > > > >> > > > > >>On the other point, I have no opinion. > > > > >> > > > > >>Jim Hafner > > > > >> > > > > >>Sent by: owner-ips@ece.cmu.edu > > > > >> > > > > >>To: Prasenjit Sarkar , Duncan Missimer > > > > >>, Costa Sapuntzakis , > > > > >>Elizabeth Rodriguez , David Black > > > > >>, John Hufferd/San Jose/IBM@IBMUS, IPS > > > > >> > > > > >>cc: > > > > >>Subject: iSCSI Boot Last Call - Technical Comments > > > > >> > > > > >>I have only a few technical comments on the boot draft. The editorials > > > > >>have been sent to the authors. The draft looks good! > > > > >> > > > > >>Page 4 > > > > >> > > > > >> > > > > >>> The "LUN" field is a hexadecimal representation of the 8-byte LU > > > > >>> number. Digits above 9 may be either lower or upper case, and all > > > 16 > > > > >>> nibbles must be present. If the LUN field is blank, then LUN 0 is > > > > >>> assumed. > > > > >> > > > > >>Since most LUNs are just 16 bits (and many of these are even smaller), > > > > >>I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual > > > > >>LUN value into a field in the DHCP GUI is quite error-prone, since in > > > > >>a DHCP server's user interface or /etc/dhcpd.conf, this string will be > > > > >>entered directly by the end user. > > > > >> > > > > >>So in addition to the rules above, how about: > > > > >> > > > > >>- If the LUN field contains four or fewer hex digits, these digits > > > > >>constitute the LUN number from which to boot. > > > > >> > > > > >>Page 5 > > > > >> > > > > >> > > > > >>> It is possible that the port number obtained from the Discovery > > > > >>> Service may conflict with the one obtained from the DHCP service. In > > > > >>> such a case, the implementor has the option to try both port numbers > > > > >>> in the Boot stage. > > > > >> > > > > >>In this case, I think that we should pick one to take precedence, > > > instead > > > > >>of leaving it up to the implementor. Since the discovery service should > > > > >>have the most up-to-date IP address and port number information, I think > > > > >>that it should be the one that is used. > > > > >> > > > > >>-- > > > > >>Mark A. Bakke > > > > >>Cisco Systems > > > > >>mbakke@cisco.com > > > > >>763.398.1054 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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 Wed Sep 11 18:48:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27446 for ; Wed, 11 Sep 2002 18:48:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BMXUw07693 for ips-outgoing; Wed, 11 Sep 2002 18:33:30 -0400 (EDT) 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 g8BMXSo07689 for ; Wed, 11 Sep 2002 18:33:28 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMXMds011438; Wed, 11 Sep 2002 15:33:22 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMXKpv016072; Wed, 11 Sep 2002 15:33:21 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA10761; Wed, 11 Sep 2002 15:33:13 -0700 (PDT) Message-ID: <3D7FC937.ED8F74AD@cisco.com> Date: Wed, 11 Sep 2002 17:52:39 -0500 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: pat_thaler@agilent.com CC: erodrigu@Brocade.COM, ips@ece.cmu.edu, kaladhar@us.ibm.com, Black_David@emc.com Subject: Re: iSCSI: Last call issues for the Naming and Discovery document References: <1BEBA5E8600DD4119A50009027AF54A00E182AC4@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat- Thanks for the careful read. I've embedded my comments below. -- Mark pat_thaler@agilent.com wrote: > > In the interest of getting these out in a timely fashion, I haven't compared them to the other postings to see if there are duplicates. Pat Thaler > > Technical issues > > The third paragraph of 1 has the following text: "An iSCSI node name is also the SCSI device name of an iSCSI device. The iSCSI name of a SCSI device...." The first sentence says the iSCSI node name and SCSI device name are the same but the next sentence uses a different term: iSCSI name which is used through much of the remainder of the document. (There only seems to be one later use of iSCSI node name.) Please state whether iSCSI name the same as iSCSI node name. Also, why does the first sentence use "iSCSI device" but the second sentence use "SCSI device"? It seems that both should use "iSCSI device" OK; I'll clarify that: - An iSCSI node name and iSCSI name are one and the same (perhaps I'll omit iSCSI node name as a term, and define that an iSCSI name is the unique identifier for an iSCSI node. - The whole SCSI device name thing is a link to T10 stuff. Jim and Marjorie, any ideas on how to make this more clear? > I'm not sure if this is technical or editorial because it isn't clear whether the small differences in the terms were intended to refer to different items or whether they should have used the same terms. > > Appendix B.1 and B.2: This should mention the effect of port redirectors and SOCKS servers on Send Targets because the address mapping performed on the headers will not be performed on Send Targets responses. The Send Targets would need to use the fully qualified domain name form of iSCSI address or, if it must use an IP address form, it would need to know the mapping used by the gateway (and whether the initiator was on the far side of the gateway). Also, either the gateway will have to be configured to map the default port on the initiator side to whatever port the target is using (which could also be the default port; if it isn't the default port the target would have to know to suppress the port number) or the target will have to know the mapping used for ports on the gateway to supply the initiator the right port number in the iSCSI address. I'll add the SendTargets note; that will be helpful. To handle IP address and port translations when the domain names are not used, it would be necessary to proxy the discovery session (SendTargets) as you mentioned. I'll note that as well. > > Some of the references do not have a reference in the body of the document and don't have a clear relationship to the document. Specifically, [5] IEEE 802 (which would be relevant if MAC address space was discussed at all but it isn't mentioned and [22] and [23] which are Java references. If these references are necessary then text should be added to the body to clarify their relevance. OK; some of these references are quite old, and are no longer used. I will remove them. > > Editorial nits > > Fifth paragraph of 1: The first sentence would be better: "An iSCSI node also has one or more addresses." to make it clear that a node does not necessarily have just one address. OK > > Address examples in 1. For completeness it would be nice for some of the addresses to include a . If none of them do, then they should be renamed examples of domain-name. OK > > 2.2 second paragraph below the first show targets listing: The first sentence has a grammar problem. Suggest "allocated to the hosts. The alias can provide a more descriptive name." OK > > The appendices should come at the end - after the Author's names. OK -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 11 18:49:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27460 for ; Wed, 11 Sep 2002 18:49:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BMF1s06524 for ips-outgoing; Wed, 11 Sep 2002 18:15:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BMExo06516 for ; Wed, 11 Sep 2002 18:14:59 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMEqKB022674; Wed, 11 Sep 2002 15:14:52 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8BMEpFp005428; Wed, 11 Sep 2002 15:14:51 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA24721; Wed, 11 Sep 2002 15:14:49 -0700 (PDT) Message-ID: <3D7FC4E8.AEF00BD8@cisco.com> Date: Wed, 11 Sep 2002 17:34:16 -0500 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: pat_thaler@agilent.com CC: psarkar@almaden.ibm.com, duncan_missimer@hp.com, csapuntz@stanford.edu, erodrigu@Brocade.COM, Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI Boot Last Call - Technical Comments References: <1BEBA5E8600DD4119A50009027AF54A00E182B0A@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, On #5, I think that this should say "iSCSI Target Name"; as you said, portal groups are not necessary for boot. Mark pat_thaler@agilent.com wrote: > > Technical > > 4. last two paragraphs: > "If the "servername" field is provided by DHCP, then that field is > used in conjunction with other associated fields to contact the boot > server in the Boot stage (Section 6). > > However, if the "servername" field is not provided, then the > "targetname" field is then used in the Discovery Service stage > (Section 5)." > > Shouldn't the second paragraph say "is used in conjunction with the other associated fields"? "targetname" doesn't provide the LUN or protocol. The "port" field is may be relevant because the Target address needs to be fetched and will include port if necessary. > > 5. first paragraph "if the DHCP server ... is unaware of the iSCSI Target Port Name" What does Target port name (defined as iSCSI Target Name together with a label that idenifies it as a target port name and the portal group tag) have to do with this? The DHCP server string definition doesn't include a Target port name and even if it did, the discovery service stage would be necessary to convert that into an address. The discovery service stage is required if the DHCP server provided a target name because it converts target name to an IP address and port number. It is also required if the DHCP server didn't provide an iSCSI string. > > Reference [17]: Can a URL be used as a reference? Intel could change the structure of their website and the URL would no longer locate the document. It would be better to reference a document title. > > Editorial > > 4. 5 paragraphs from the end, "several different LU" should be "several different LUs" > > 4. 3 paragraphs from the end, except for the sentence "If the "servername" field is blank ....", all the other statements about defaults are duplicates of statements in the paragraphs where the fields were defined. Moving the statement about servername to the servername paragraphs above and deleting this paragraph. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 11 18:50:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27488 for ; Wed, 11 Sep 2002 18:50:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BMdF908003 for ips-outgoing; Wed, 11 Sep 2002 18:39:15 -0400 (EDT) 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 g8BMdCo07999 for ; Wed, 11 Sep 2002 18:39:12 -0400 (EDT) Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id D58EE992B; Wed, 11 Sep 2002 16:39:11 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id 6DD9BA3A; Wed, 11 Sep 2002 16:38:52 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 11 Sep 2002 16:39:11 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Sep 2002 16:39:10 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00E182D66@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mbakke@cisco.com Cc: psarkar@almaden.ibm.com, duncan_missimer@hp.com, csapuntz@stanford.edu, erodrigu@Brocade.COM, Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI Boot Last Call - Technical Comments Date: Wed, 11 Sep 2002 16:39:10 -0600 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 Mark, The sentence at the beginning of 5: "This stage is required if the DHCP server (v4 or v6) is unaware of the iSCSI Target Port Name of the iSCSI boot server." is incorrect even if one changes iSCSI Target Port Name to iSCSI Target Name. If the DHCP server supplies an iSCSI Target Port Name, then the booting device still needs to use the Discovery stage to convert that name into an address. The only cases where Discovery stage could be skipped is when the DHCP server supplies a servername or where the boot target address is configured into the boot client. The servername doesn't require discovery stage because it is either an IP address or a domain name that the DNS server can convert ot an IP address. Pat -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Wednesday, September 11, 2002 3:34 PM To: pat_thaler@agilent.com Cc: psarkar@almaden.ibm.com; duncan_missimer@hp.com; csapuntz@stanford.edu; erodrigu@Brocade.COM; Black_David@emc.com; ips@ece.cmu.edu Subject: Re: iSCSI Boot Last Call - Technical Comments Pat, On #5, I think that this should say "iSCSI Target Name"; as you said, portal groups are not necessary for boot. Mark pat_thaler@agilent.com wrote: > > Technical > > 4. last two paragraphs: > "If the "servername" field is provided by DHCP, then that field is > used in conjunction with other associated fields to contact the boot > server in the Boot stage (Section 6). > > However, if the "servername" field is not provided, then the > "targetname" field is then used in the Discovery Service stage > (Section 5)." > > Shouldn't the second paragraph say "is used in conjunction with the other associated fields"? "targetname" doesn't provide the LUN or protocol. The "port" field is may be relevant because the Target address needs to be fetched and will include port if necessary. > > 5. first paragraph "if the DHCP server ... is unaware of the iSCSI Target Port Name" What does Target port name (defined as iSCSI Target Name together with a label that idenifies it as a target port name and the portal group tag) have to do with this? The DHCP server string definition doesn't include a Target port name and even if it did, the discovery service stage would be necessary to convert that into an address. The discovery service stage is required if the DHCP server provided a target name because it converts target name to an IP address and port number. It is also required if the DHCP server didn't provide an iSCSI string. > > Reference [17]: Can a URL be used as a reference? Intel could change the structure of their website and the URL would no longer locate the document. It would be better to reference a document title. > > Editorial > > 4. 5 paragraphs from the end, "several different LU" should be "several different LUs" > > 4. 3 paragraphs from the end, except for the sentence "If the "servername" field is blank ....", all the other statements about defaults are duplicates of statements in the paragraphs where the fields were defined. Moving the statement about servername to the servername paragraphs above and deleting this paragraph. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 11 18:51:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27554 for ; Wed, 11 Sep 2002 18:51:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BMgd208223 for ips-outgoing; Wed, 11 Sep 2002 18:42:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BMgao08218 for ; Wed, 11 Sep 2002 18:42:36 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g8BMgNs15340; Wed, 11 Sep 2002 15:42:23 -0700 From: "Amir Shalit" To: "Amir Shalit" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , "'Elizabeth Rodriguez'" , "IPS Mailing List \(E-mail\)" Cc: "Kaladhar Voruganti \(E-mail\)" , "David Black \(E-mail\)" Subject: RE: iSCSI: Last call issues for the Naming and Discovery document Date: Wed, 11 Sep 2002 15:42:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0355_01C259A9.D1786A70" 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 V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0355_01C259A9.D1786A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit IPS-All: Reminder: 3 drafts complete last call this weekAn iSCSI proxy functionality (i.e. iSCSI device mapping) within a SCSI gateway can also take advantage of the specific transport properties mentioned in B.4. Is it possible to re-word B.4 as such? Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Amir Shalit Sent: Tuesday, September 10, 2002 11:01 AM To: KRUEGER,MARJORIE (HP-Roseville,ex1); 'Elizabeth Rodriguez'; IPS Mailing List (E-mail) Cc: Kaladhar Voruganti (E-mail); David Black (E-mail) Subject: RE: iSCSI: Last call issues for the Naming and Discovery document B.4 is a subset of B.3 and can be dropped. In case we keep it, I suggest the following text: An iSCSI gateway is a SCSI gateway presenting only virtual iSCSI targets and virtual iSCSI initiators. A virtual iSCSI device is also called an iSCSI proxy. instead of: "An iSCSI proxy is a SCSI gateway that happens to be terminating the iSCSI protocol on both sides, rather than translate between iSCSI and some other transport." An iSCSI proxy by itself is not a gateway making above sentence inaccurate. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of KRUEGER,MARJORIE (HP-Roseville,ex1) Sent: Monday, September 09, 2002 6:46 PM To: 'Elizabeth Rodriguez'; IPS Mailing List (E-mail) Cc: Kaladhar Voruganti (E-mail); David Black (E-mail) Subject: iSCSI: Last call issues for the Naming and Discovery document Some cleanup items for the iSCSI Naming and Discovery document: 1) Sec.1 p.5 and p. 14 define "iSCSI Address" but contradict each other. p. 5 defines it as simply and IP address [& port] and p. 14 says it's the iSCSI name and IP addr [+port]. Paragraph 5 needs to be modified to match p. 14. 2) Sec. 1 p. 17 says In this example, Robert's SSN is like the iSCSI Name, his phone number and addresses are analogous to the TCP addresses which make up an iSCSI session, and "Robert Smith" would be a human-friendly label for this person. The statement that Robert Smith's addresses are like an iSCSI session makes no sense to me. An iSCSI session is a relationship between two separate iSCSI nodes. Robert's addresses are only one end of the relationship. Perhaps this paragraph means to say his phone number, etc. are like an iSCSI nodes TCP addresses? 3) Sec. 1.1 p. 1 first sentence "iSCSI has given the Organizational naming authority additional flexibility by permitting it to hand out local naming authority to subordinate organizations." I suggest changing this to "The iSCSI naming scheme was constructed to give an organizational naming authority the flexibility to further subdivide the responsibility for name creation to subordinate naming authorities." Use of "capital O" in Organization implies there's some globally defined naming authority that this sentence is referring to. 4) General comment on section 1.1 To reflect the definition in the iSCSI main draft, sec. 2.2.6.3.2, either the examples need to be changed to show the ":" after the reversed domain name in the string, or the text needs to be changed to say that these substrings are sub-domain names. 5)sec. 1.1, p 15 - this example is missing the ":" following the reversed domain name. 6)sec. 3, p 1 - the last sentence is missing something. It's "Moreover, iSCSI discovery mechanism only deals with target discovery and one still needs to use the SCSI protocol for LUN discovery." and should be "Moreover, the iSCSI discovery mechanisms listed here only deal with target discovery and one still needs to use the SCSI protocol for LUN discovery." 7) sec. 3 p 2 - 2nd sentence is missing something. It's "The goal of iSCSI discovery mechanism is to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." and should be "The goal of iSCSI discovery mechanisms are to provide low overhead support for small iSCSI setups, and scalable discovery solutions for large enterprise setups." 8) sec. 3, p 5 the sentence "This mechanism assumes that the IP address and TCP port information are already available to the initiator." is missing something, should be "This mechanism assumes that the target's IP address and TCP port information are already available to the initiator." 9) appendix B.3, I think there's a typo in the first sentence. "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to real iSCSI targets as it chooses." should be "This gateway presents logical targets (iSCSI Names) to the initiators, and maps them to SCSI targets as it chooses." 10) appendix B.4 another typo? "An iSCSI proxy is a SCSI gateway..." should be "An iSCSI proxy is an iSCSI gateway.." 11) appendix B.5, p 4 refers to a "DMZ" There is no definition of this term in this document. Needs to either be defined or substitute some more descriptive phrase here. Regards, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard ------=_NextPart_000_0355_01C259A9.D1786A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: Reminder: 3 drafts complete last call this = week

An iSCSI proxy functionality (i.e. iSCSI device = mapping)=20 within a SCSI gateway can also = take=20 advantage of the specific transport

properties mentioned = in B.4.=20

Is it=20 possible to re-word B.4 as such?

Amir

-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Amir = Shalit
Sent:=20 Tuesday, September 10, 2002 11:01 AM
To: KRUEGER,MARJORIE=20 (HP-Roseville,ex1); 'Elizabeth Rodriguez'; IPS Mailing List=20 (E-mail)
Cc: Kaladhar Voruganti (E-mail); David Black=20 (E-mail)
Subject: RE: iSCSI: Last call issues for the Naming = and=20 Discovery document

B.4=20 is a subset of B.3 and can be dropped. In case we keep = it,
I=20 suggest the following text:
 
An=20 iSCSI gateway is a SCSI gateway presenting only virtual iSCSI=20 targets
and=20 virtual iSCSI initiators. A virtual iSCSI device is also called an = iSCSI=20 proxy.
 
instead of:
 
 "An iSCSI proxy is = a SCSI=20 gateway that happens to be terminating the
   iSCSI = protocol on=20 both sides, rather than translate between iSCSI and
   = some other=20 transport."
 
An=20 iSCSI proxy by itself is not a gateway making above sentence=20 inaccurate.
 
Amir
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of KRUEGER,MARJORIE=20 (HP-Roseville,ex1)
Sent: Monday, September 09, 2002 6:46=20 PM
To: 'Elizabeth Rodriguez'; IPS Mailing List=20 (E-mail)
Cc: Kaladhar Voruganti (E-mail); David Black=20 (E-mail)
Subject: iSCSI: Last call issues for the Naming = and=20 Discovery document

Some cleanup items for the = iSCSI=20 Naming and Discovery document:
 
1) Sec.1 p.5 and p. 14 = define "iSCSI=20 Address" but contradict each other.  p. 5 defines it as = simply and=20 IP address [& port] and p. 14 says it's the iSCSI name and IP = addr=20 [+port].  Paragraph 5 needs to be modified to match p.=20 14.
 
2) Sec. 1 p. 17=20 says
 
In this example, Robert's SSN is like the = iSCSI=20 Name, his phone number and addresses are analogous to the TCP = addresses=20 which make up an iSCSI session, and "Robert Smith" would be a = human-friendly=20 label for this person.
The statement that Robert Smith's addresses are like an = iSCSI session=20 makes no sense to me.  An iSCSI session is a relationship = between two=20 separate iSCSI nodes.  Robert's addresses are only one end of = the=20 relationship.  Perhaps this paragraph means to say his phone = number,=20 etc. are like an iSCSI nodes TCP addresses?
 
3) Sec. 1.1 p. 1 first sentence "iSCSI has given the Organizational naming authority = additional=20 flexibility by permitting it to hand out local naming authority=20 to
   subordinate = organizations."
 
I=20 suggest changing this to "The iSCSI naming scheme was constructed to = give an=20 organizational naming authority the flexibility to further subdivide = the=20 responsibility for name creation to subordinate naming = authorities." =20 Use of "capital O" in Organization implies there's some globally = defined=20 naming authority that this sentence is referring to. =20
 
4)=20 General comment on section 1.1  To reflect the definition in = the iSCSI=20 main draft, sec. 2.2.6.3.2,  either the examples need to be = changed to=20 show the ":" after the reversed domain name in the string, or the = text needs=20 to be changed to say that these substrings are sub-domain=20 names.
 
5)sec. 1.1, p 15 - this example is missing the ":" = following the=20 reversed domain name.
 
6)sec. 3, p 1 - the last sentence is missing = something. =20 It's "Moreover, = iSCSI=20 discovery  mechanism only deals with target discovery and one = still=20 needs to use  the SCSI protocol for LUN discovery." and should be "Moreover, the iSCSI = discovery =20 mechanisms listed here only deal with target discovery and one = still=20 needs to use the SCSI protocol for LUN=20 discovery."
 
7) sec. 3=20 p 2 - 2nd sentence is missing something. It's "The goal of iSCSI discovery mechanism is to provide = low=20 overhead support for small iSCSI setups, and scalable discovery = solutions=20 for large enterprise setups." and should = be "The=20 goal of iSCSI discovery  mechanisms are to provide low overhead = support=20 for small iSCSI setups, and scalable discovery solutions for = large=20 enterprise setups." 
 
8) sec. 3, p=20 5  the=20 sentence "This mechanism assumes = that the=20 IP address and TCP port information are already available to = the initiator." is=20 missing something, should be "This mechanism assumes that the = target's IP address and TCP port information are already = available to=20 the initiator."
 
9)=20 appendix B.3, I think there's a typo in the first sentence.  = "This gateway presents = logical=20 targets (iSCSI Names) to the initiators, and maps them to real iSCSI = targets=20 as it chooses." should be "This gateway = presents=20 logical targets (iSCSI Names) to the initiators, and maps them to = SCSI=20 targets as it chooses."

10) =20 appendix B.4 another typo?  "An iSCSI = proxy is a=20 SCSI gateway..." should be "An iSCSI = proxy is an=20 iSCSI gateway.."
 
11) appendix=20 B.5, p 4 refers to a "DMZ"  There is no definition of this term = in this=20 document.  Needs to either be defined or substitute some more=20 descriptive phrase here.
 

Regards,

Marjorie=20 Krueger
Networked Storage Architecture
Networked Storage=20 Solutions
Hewlett-Packard =

------=_NextPart_000_0355_01C259A9.D1786A70-- From owner-ips@ece.cmu.edu Wed Sep 11 19:33:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28496 for ; Wed, 11 Sep 2002 19:33:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BN6og09409 for ips-outgoing; Wed, 11 Sep 2002 19:06:50 -0400 (EDT) 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 [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BN6mo09405 for ; Wed, 11 Sep 2002 19:06:48 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 40EA8804E9A; Wed, 11 Sep 2002 19:06:48 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 182F8400109; Wed, 11 Sep 2002 19:06:46 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Sep 2002 19:06:45 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF7D0@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Mark Bakke'" , pat_thaler@agilent.com Cc: erodrigu@Brocade.COM, ips@ece.cmu.edu, kaladhar@us.ibm.com, Black_David@emc.com Subject: RE: iSCSI: Last call issues for the Naming and Discovery document Date: Wed, 11 Sep 2002 19:06:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk >> The third paragraph of 1 has the following text: "An iSCSI >> node name is also the SCSI device name of an iSCSI device. >> The iSCSI name of a SCSI device...." The first sentence says >> the iSCSI node name and SCSI device name are the same but the >> next sentence uses a different term: iSCSI name which is used >> through much of the remainder of the document. (There only >> seems to be one later use of iSCSI node name.) Please state >> whether iSCSI name the same as iSCSI node name. Also, why >> does the first sentence use "iSCSI device" but the second >> sentence use "SCSI device"? It seems that both should use >> "iSCSI device" > > > OK; I'll clarify that: > > - An iSCSI node name and iSCSI name are one and the same > (perhaps I'll omit > iSCSI node name as a term, and define that an iSCSI name is > the unique identifier for an iSCSI node. > > - The whole SCSI device name thing is a link to T10 stuff. > Jim and Marjorie, any ideas on how to make this more clear? I admit I don't find any of the quoted text confusing. The main draft uses the same mixture of terms, and the paragraphs that preceed and follow this paragraph further define and clarify the usage of terms. I think the current text is sufficient. Perhaps you can add a pointer to the sections in the main draft that you are paraphrasing here? As to Pat's comment that "iSCSI device" should be used where "SCSI device" is used, I disagree. SCSI get's it's device name from the transport, and this sentence is pointing out that the SCSI device name is derived from the iSCSI name. Perhaps if you change the following sentence: "The iSCSI name of a SCSI device is the principal object used in authentication of targets to initiators and initiators to targets." to "The iSCSI name is the principal object used in authentication of targets to initiators and initiators to targets." removing the reference to the "SCSI device"ness to avoid overloading this sentence? Cheers, Marj From owner-ips@ece.cmu.edu Wed Sep 11 19:33:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28514 for ; Wed, 11 Sep 2002 19:33:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BNQXI10377 for ips-outgoing; Wed, 11 Sep 2002 19:26:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub2.almaden.ibm.com (p1.almaden.ibm.com [198.4.83.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BNQVo10371 for ; Wed, 11 Sep 2002 19:26:31 -0400 (EDT) Received: from ibmjh9qh9xf2ft (ibm-jh9qh9xf2ft.almaden.ibm.com [9.1.22.179]) by mailhub2.almaden.ibm.com (AIX4.3/8.9.3/8.9.3) with SMTP id QAA60898; Wed, 11 Sep 2002 16:18:59 -0700 Message-ID: <007d01c259e9$79f38650$b3160109@almaden.ibm.com> From: "Prasenjit Sarkar" To: "Mark Bakke" , "Mallikarjun C." Cc: "Constantine Sapuntzakis" , References: <3D7E1E24.980D329C@cisco.com> <3D7E3743.5050306@stanford.edu> <005601c2590e$882a4140$fe150109@almaden.ibm.com> <3D7E66A6.47D62427@cisco.com> <010b01c25926$ab18e540$edd52b0f@rose.hp.com> <3D7FC3DE.1DCF2F77@cisco.com> Subject: Re: iSCSI Boot Last Call - Technical Comments Date: Wed, 11 Sep 2002 16:18:02 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit My personal opinion is that an argument is on a very slippery slope when it relies on editing iscsi names vs editing luns. I do not find this mult-OS testing scenario compelling enough to make this change. I dont think Mallikarjun was referring to users looking into PDUs - he was referring to LUN equivalence. Regardless of my personal opinion, I think there are more voices against making the change than in favor. Sincerely, Prasenjit ----- Original Message ----- From: "Mark Bakke" To: "Mallikarjun C." Cc: "Prasenjit Sarkar" ; "Constantine Sapuntzakis" ; Sent: Wednesday, September 11, 2002 3:29 PM Subject: Re: iSCSI Boot Last Call - Technical Comments > Mallikarjun- > > My comments are embedded. > > -- > Mark > > "Mallikarjun C." wrote: > > > > > consider an application where a host will be able to be booted from > > > a small set of different LUNs, perhaps to change O/S levels in a > > > test environment > > > > How does the DHCP server distinguish which O/S level the client > > wants to boot from, to provide the right LUN in the Root Path? > > The DHCP server doesn't. In this type of environment, the DHCP server > is generally under the control of the same test folks who are booting > the servers. One would manually change the LUN in the DHCP server > GUI or config file, and reboot. The DHCP server doesn't have to do > anything special, but it's one more scenario where the LUN field is > directly manipulated by a user, which is why I'd like to keep it > simple. > > > > If it's a well-known LUN->O/S_rev mapping that the client boot > > code uses by convention, then there's no issue with always leaving > > the LUN field blank (for 0) in the DHCP response. What am I missing? > > > > > I still think that allowing a 16-bit LUN in the string is the > > > simplest, least error-prone approach. > > > > AFAICT, this assumes that the user knows how to figure out which > > 16-bits of the 64-bit LUN are to be entered into the DHCP server > > file. I'm not sure that's a valid assumption. > > > Actually, the user only has to worry about this when the 64-bit LUN > field is used. The 16-bit version always ends up in the high > bytes of the LUN field in the protocol, and the user never sees > this structure, which is really not pretty. I don't think most > users will ever want (or need) to see more than a 16-bit LUN. > > > > My preference is to require 64-bits always (if non-blank), so the boot > > client can simply copy the value in the iSCSI PDUs as-is. > > What customer or user looks at iSCSI PDUs? Would they copy and > paste one from a network analyzer? This doesn't make sense to > me. End users don't care about PDUs. > > > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > ----- Original Message ----- > > From: "Mark Bakke" > > To: "Prasenjit Sarkar" > > Cc: "Constantine Sapuntzakis" ; "Jim Hafner" ; "David Black" > > ; "Duncan Missimer" ; "Elizabeth Rodriguez" > > ; "IPS" ; "John Hufferd" ; > > Sent: Tuesday, September 10, 2002 2:39 PM > > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > > > It's true that in many cases, zero is all that is needed. However, > > > consider an application where a host will be able to be booted from > > > a small set of different LUNs, perhaps to change O/S levels in a > > > test environment, or to make a different application available > > > on the host. Having these LUNs mapped behind the same iSCSI target > > > and editing the LUN in the root-path string is a lot simpler than > > > having several different targets, and changing the iSCSI name in > > > the root-path. > > > > > > I still think that allowing a 16-bit LUN in the string is the > > > simplest, least error-prone approach. > > > > > > -- > > > Mark > > > > > > Prasenjit Sarkar wrote: > > > > > > > > Mark and Costa, > > > > > > > > If you are so very concerned with entering the value wrong, you can leave > > > > the lun value blank. The lun value defaults to zero and you can always use > > > > lun mapping in the target to make the boot lun to be zero for the initiator. > > > > > > > > Analogous to the other issue you brought up, I think this is going to be the > > > > common case. > > > > > > > > Sincerely, > > > > Prasenjit > > > > > > > > ----- Original Message ----- > > > > From: "Constantine Sapuntzakis" > > > > To: "Mark Bakke" > > > > Cc: "Prasenjit Sarkar" ; "Jim Hafner" > > > > ; "David Black" ; "Duncan > > > > Missimer" ; "Elizabeth Rodriguez" > > > > ; "IPS" ; "John Hufferd" > > > > ; > > > > Sent: Tuesday, September 10, 2002 11:17 AM > > > > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > > > > > > > Many people also use emacs/vi for their configuration too, so they have > > > > > the same problem Mark has with the GUI. I would agree with Mark on his > > > > > point about entry being error-prone. > > > > > > > > > > -Costa > > > > > > > > > > > > > > > Mark Bakke wrote: > > > > > > It would be nice if the GUI could handle this. However, a DHCP > > > > > > GUI (Microsoft, for example), only provides a place to paste in > > > > > > the entire root-path option; it won't give you separate fields > > > > > > to type in the IP address, LUN, and target name. So the user is > > > > > > left with the job of correctly typing in the root-path option. > > > > > > We found (through experience) that the LUN field was particularly > > > > > > frustrating, expecially since a 16-bit LUN value actually appears > > > > > > in the top characters of the LUN field. For example, LUN 12 (hex > > > > > > 0x0c) would appear as: > > > > > > > > > > > > 000c000000000000 > > > > > > > > > > > > in the option string. Getting the wrong number of zeroes before > > > > > > or after either causes the option to be refused by a network boot > > > > > > program, or causes the wrong LUN to be tried. Either way, the > > > > > > user has to decide what the problem is, fix the LUN string, > > > > > > and try again. It's also a bit non-intuitive since most users > > > > > > would expect that the LUN should have been entered as > > > > > > > > > > > > 000000000000000c > > > > > > > > > > > > (BTW, I missed a zero counting that last one, and I caught it > > > > > > because the length looked wrong comparing it to the previous > > > > > > one). > > > > > > > > > > > > Anyway, this is an extremely easy thing to do to make our users' > > > > > > lives easier, and we have no control over adding iSCSI user > > > > > > interface capabilities to DHCP servers. > > > > > > > > > > > > I really think that this is the right thing to do. > > > > > > > > > > > > -- > > > > > > Mark > > > > > > > > > > > > Prasenjit Sarkar wrote: > > > > > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >>Mark, > > > > > >> > > > > > >>I tend to agree with Jim that machines can help with 8-byte entities. > > > > > >> > > > > > >>Regarding the prioritization, I do not doubt that your assertion will > > > > > >>generally hold true, but at the same time, I feel that we should not > > > > make > > > > > >>any assumptions about the order of updates to the Discovery and DHCP > > > > > >>databases in a boot environment. However, if people insist, I can make > > > > the > > > > > >>change. > > > > > >> > > > > > >>Thanks, > > > > > >> > > > > > >> Prasenjit Sarkar > > > > > >> Research Staff Member > > > > > >> IBM Almaden Research > > > > > >> San Jose > > > > > >> > > > > > >> > > > > > >> Jim Hafner > > > > > >> > > > > > > > > >> bm.com> cc: Prasenjit > > > > Sarkar , Duncan > > > > > >> Sent by: Missimer > > > > , Costa Sapuntzakis > > > > > >> owner-ips@ece.cmu , > > > > Elizabeth Rodriguez > > > > > >> .edu , > > > > David Black , > > > > > >> John Hufferd/San > > > > Jose/IBM@IBMUS, IPS > > > > > >> Subject: Re: iSCSI Boot > > > > Last Call - Technical Comments > > > > > >> 09/10/2002 07:59 > > > > > >> AM > > > > > >> > > > > > >> > > > > > >> > > > > > >>Mark, > > > > > >> > > > > > >>I would rather not go the route your going with the LUN number issue. > > > > GUIs > > > > > >>can always do the translation to more nibbles under the covers. > > > > Besides, > > > > > >>if you have a LUN that has only 16bits or less of significant (i.e., > > > > > >>nonzero) digits, you'll need to carefully specify where these digits go > > > > in > > > > > >>the 8 byte defined SCSI LUN and that depends on the LUN number > > > > convention > > > > > >>of the target. So, to avoid that can of worms and the extra > > > > descriptions > > > > > >>required, I'd suggest leaving this as an 8byte (16 hex nibble) field. > > > > > >> > > > > > >>On the other point, I have no opinion. > > > > > >> > > > > > >>Jim Hafner > > > > > >> > > > > > >>Sent by: owner-ips@ece.cmu.edu > > > > > >> > > > > > >>To: Prasenjit Sarkar , Duncan Missimer > > > > > >>, Costa Sapuntzakis , > > > > > >>Elizabeth Rodriguez , David Black > > > > > >>, John Hufferd/San Jose/IBM@IBMUS, IPS > > > > > >> > > > > > >>cc: > > > > > >>Subject: iSCSI Boot Last Call - Technical Comments > > > > > >> > > > > > >>I have only a few technical comments on the boot draft. The editorials > > > > > >>have been sent to the authors. The draft looks good! > > > > > >> > > > > > >>Page 4 > > > > > >> > > > > > >> > > > > > >>> The "LUN" field is a hexadecimal representation of the 8-byte LU > > > > > >>> number. Digits above 9 may be either lower or upper case, and all > > > > 16 > > > > > >>> nibbles must be present. If the LUN field is blank, then LUN 0 is > > > > > >>> assumed. > > > > > >> > > > > > >>Since most LUNs are just 16 bits (and many of these are even smaller), > > > > > >>I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual > > > > > >>LUN value into a field in the DHCP GUI is quite error-prone, since in > > > > > >>a DHCP server's user interface or /etc/dhcpd.conf, this string will be > > > > > >>entered directly by the end user. > > > > > >> > > > > > >>So in addition to the rules above, how about: > > > > > >> > > > > > >>- If the LUN field contains four or fewer hex digits, these digits > > > > > >>constitute the LUN number from which to boot. > > > > > >> > > > > > >>Page 5 > > > > > >> > > > > > >> > > > > > >>> It is possible that the port number obtained from the Discovery > > > > > >>> Service may conflict with the one obtained from the DHCP service. In > > > > > >>> such a case, the implementor has the option to try both port numbers > > > > > >>> in the Boot stage. > > > > > >> > > > > > >>In this case, I think that we should pick one to take precedence, > > > > instead > > > > > >>of leaving it up to the implementor. Since the discovery service should > > > > > >>have the most up-to-date IP address and port number information, I think > > > > > >>that it should be the one that is used. > > > > > >> > > > > > >>-- > > > > > >>Mark A. Bakke > > > > > >>Cisco Systems > > > > > >>mbakke@cisco.com > > > > > >>763.398.1054 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > 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 Wed Sep 11 19:33:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28510 for ; Wed, 11 Sep 2002 19:33:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BN1QR09169 for ips-outgoing; Wed, 11 Sep 2002 19:01:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BN1No09164 for ; Wed, 11 Sep 2002 19:01:23 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel11.hp.com (Postfix) with ESMTP id A98B56002B4; Wed, 11 Sep 2002 16:01:22 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id QAA00241; Wed, 11 Sep 2002 16:01:21 -0700 (PDT) Message-ID: <00bb01c259e7$25111870$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Mark Bakke" Cc: "Prasenjit Sarkar" , "Constantine Sapuntzakis" , References: <3D7E1E24.980D329C@cisco.com> <3D7E3743.5050306@stanford.edu> <005601c2590e$882a4140$fe150109@almaden.ibm.com> <3D7E66A6.47D62427@cisco.com> <010b01c25926$ab18e540$edd52b0f@rose.hp.com> <3D7FC3DE.1DCF2F77@cisco.com> Subject: Re: iSCSI Boot Last Call - Technical Comments Date: Wed, 11 Sep 2002 16:00:41 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, >I don't think most > users will ever want (or need) to see more than a 16-bit LUN. Having a 32/48/64-bit LUN, I believe, doesn't mean that there are more than 2^16 LUNs. IIRC, the 64-bit LUN address space can be sparsely populated, depending on how many levels of addressing a target supports and which specific LUs are distributed into which level. So, I cannot agree with this statement. >>so the boot > > client can simply copy the value in the iSCSI PDUs as-is. > > What customer or user looks at iSCSI PDUs? A boot client is not a customer, but a very thin code probably running on the iSCSI NICs, and working off the DHCP responses. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Mark Bakke" To: "Mallikarjun C." Cc: "Prasenjit Sarkar" ; "Constantine Sapuntzakis" ; Sent: Wednesday, September 11, 2002 3:29 PM Subject: Re: iSCSI Boot Last Call - Technical Comments > Mallikarjun- > > My comments are embedded. > > -- > Mark > > "Mallikarjun C." wrote: > > > > > consider an application where a host will be able to be booted from > > > a small set of different LUNs, perhaps to change O/S levels in a > > > test environment > > > > How does the DHCP server distinguish which O/S level the client > > wants to boot from, to provide the right LUN in the Root Path? > > The DHCP server doesn't. In this type of environment, the DHCP server > is generally under the control of the same test folks who are booting > the servers. One would manually change the LUN in the DHCP server > GUI or config file, and reboot. The DHCP server doesn't have to do > anything special, but it's one more scenario where the LUN field is > directly manipulated by a user, which is why I'd like to keep it > simple. > > > > If it's a well-known LUN->O/S_rev mapping that the client boot > > code uses by convention, then there's no issue with always leaving > > the LUN field blank (for 0) in the DHCP response. What am I missing? > > > > > I still think that allowing a 16-bit LUN in the string is the > > > simplest, least error-prone approach. > > > > AFAICT, this assumes that the user knows how to figure out which > > 16-bits of the 64-bit LUN are to be entered into the DHCP server > > file. I'm not sure that's a valid assumption. > > > Actually, the user only has to worry about this when the 64-bit LUN > field is used. The 16-bit version always ends up in the high > bytes of the LUN field in the protocol, and the user never sees > this structure, which is really not pretty. I don't think most > users will ever want (or need) to see more than a 16-bit LUN. > > > > My preference is to require 64-bits always (if non-blank), so the boot > > client can simply copy the value in the iSCSI PDUs as-is. > > What customer or user looks at iSCSI PDUs? Would they copy and > paste one from a network analyzer? This doesn't make sense to > me. End users don't care about PDUs. > > > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > ----- Original Message ----- > > From: "Mark Bakke" > > To: "Prasenjit Sarkar" > > Cc: "Constantine Sapuntzakis" ; "Jim Hafner" ; "David Black" > > ; "Duncan Missimer" ; "Elizabeth Rodriguez" > > ; "IPS" ; "John Hufferd" ; > > Sent: Tuesday, September 10, 2002 2:39 PM > > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > > > It's true that in many cases, zero is all that is needed. However, > > > consider an application where a host will be able to be booted from > > > a small set of different LUNs, perhaps to change O/S levels in a > > > test environment, or to make a different application available > > > on the host. Having these LUNs mapped behind the same iSCSI target > > > and editing the LUN in the root-path string is a lot simpler than > > > having several different targets, and changing the iSCSI name in > > > the root-path. > > > > > > I still think that allowing a 16-bit LUN in the string is the > > > simplest, least error-prone approach. > > > > > > -- > > > Mark > > > > > > Prasenjit Sarkar wrote: > > > > > > > > Mark and Costa, > > > > > > > > If you are so very concerned with entering the value wrong, you can leave > > > > the lun value blank. The lun value defaults to zero and you can always use > > > > lun mapping in the target to make the boot lun to be zero for the initiator. > > > > > > > > Analogous to the other issue you brought up, I think this is going to be the > > > > common case. > > > > > > > > Sincerely, > > > > Prasenjit > > > > > > > > ----- Original Message ----- > > > > From: "Constantine Sapuntzakis" > > > > To: "Mark Bakke" > > > > Cc: "Prasenjit Sarkar" ; "Jim Hafner" > > > > ; "David Black" ; "Duncan > > > > Missimer" ; "Elizabeth Rodriguez" > > > > ; "IPS" ; "John Hufferd" > > > > ; > > > > Sent: Tuesday, September 10, 2002 11:17 AM > > > > Subject: Re: iSCSI Boot Last Call - Technical Comments > > > > > > > > > Many people also use emacs/vi for their configuration too, so they have > > > > > the same problem Mark has with the GUI. I would agree with Mark on his > > > > > point about entry being error-prone. > > > > > > > > > > -Costa > > > > > > > > > > > > > > > Mark Bakke wrote: > > > > > > It would be nice if the GUI could handle this. However, a DHCP > > > > > > GUI (Microsoft, for example), only provides a place to paste in > > > > > > the entire root-path option; it won't give you separate fields > > > > > > to type in the IP address, LUN, and target name. So the user is > > > > > > left with the job of correctly typing in the root-path option. > > > > > > We found (through experience) that the LUN field was particularly > > > > > > frustrating, expecially since a 16-bit LUN value actually appears > > > > > > in the top characters of the LUN field. For example, LUN 12 (hex > > > > > > 0x0c) would appear as: > > > > > > > > > > > > 000c000000000000 > > > > > > > > > > > > in the option string. Getting the wrong number of zeroes before > > > > > > or after either causes the option to be refused by a network boot > > > > > > program, or causes the wrong LUN to be tried. Either way, the > > > > > > user has to decide what the problem is, fix the LUN string, > > > > > > and try again. It's also a bit non-intuitive since most users > > > > > > would expect that the LUN should have been entered as > > > > > > > > > > > > 000000000000000c > > > > > > > > > > > > (BTW, I missed a zero counting that last one, and I caught it > > > > > > because the length looked wrong comparing it to the previous > > > > > > one). > > > > > > > > > > > > Anyway, this is an extremely easy thing to do to make our users' > > > > > > lives easier, and we have no control over adding iSCSI user > > > > > > interface capabilities to DHCP servers. > > > > > > > > > > > > I really think that this is the right thing to do. > > > > > > > > > > > > -- > > > > > > Mark > > > > > > > > > > > > Prasenjit Sarkar wrote: > > > > > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >>Mark, > > > > > >> > > > > > >>I tend to agree with Jim that machines can help with 8-byte entities. > > > > > >> > > > > > >>Regarding the prioritization, I do not doubt that your assertion will > > > > > >>generally hold true, but at the same time, I feel that we should not > > > > make > > > > > >>any assumptions about the order of updates to the Discovery and DHCP > > > > > >>databases in a boot environment. However, if people insist, I can make > > > > the > > > > > >>change. > > > > > >> > > > > > >>Thanks, > > > > > >> > > > > > >> Prasenjit Sarkar > > > > > >> Research Staff Member > > > > > >> IBM Almaden Research > > > > > >> San Jose > > > > > >> > > > > > >> > > > > > >> Jim Hafner > > > > > >> > > > > > > > > >> bm.com> cc: Prasenjit > > > > Sarkar , Duncan > > > > > >> Sent by: Missimer > > > > , Costa Sapuntzakis > > > > > >> owner-ips@ece.cmu , > > > > Elizabeth Rodriguez > > > > > >> .edu , > > > > David Black , > > > > > >> John Hufferd/San > > > > Jose/IBM@IBMUS, IPS > > > > > >> Subject: Re: iSCSI Boot > > > > Last Call - Technical Comments > > > > > >> 09/10/2002 07:59 > > > > > >> AM > > > > > >> > > > > > >> > > > > > >> > > > > > >>Mark, > > > > > >> > > > > > >>I would rather not go the route your going with the LUN number issue. > > > > GUIs > > > > > >>can always do the translation to more nibbles under the covers. > > > > Besides, > > > > > >>if you have a LUN that has only 16bits or less of significant (i.e., > > > > > >>nonzero) digits, you'll need to carefully specify where these digits go > > > > in > > > > > >>the 8 byte defined SCSI LUN and that depends on the LUN number > > > > convention > > > > > >>of the target. So, to avoid that can of worms and the extra > > > > descriptions > > > > > >>required, I'd suggest leaving this as an 8byte (16 hex nibble) field. > > > > > >> > > > > > >>On the other point, I have no opinion. > > > > > >> > > > > > >>Jim Hafner > > > > > >> > > > > > >>Sent by: owner-ips@ece.cmu.edu > > > > > >> > > > > > >>To: Prasenjit Sarkar , Duncan Missimer > > > > > >>, Costa Sapuntzakis , > > > > > >>Elizabeth Rodriguez , David Black > > > > > >>, John Hufferd/San Jose/IBM@IBMUS, IPS > > > > > >> > > > > > >>cc: > > > > > >>Subject: iSCSI Boot Last Call - Technical Comments > > > > > >> > > > > > >>I have only a few technical comments on the boot draft. The editorials > > > > > >>have been sent to the authors. The draft looks good! > > > > > >> > > > > > >>Page 4 > > > > > >> > > > > > >> > > > > > >>> The "LUN" field is a hexadecimal representation of the 8-byte LU > > > > > >>> number. Digits above 9 may be either lower or upper case, and all > > > > 16 > > > > > >>> nibbles must be present. If the LUN field is blank, then LUN 0 is > > > > > >>> assumed. > > > > > >> > > > > > >>Since most LUNs are just 16 bits (and many of these are even smaller), > > > > > >>I'd like to relax this a bit. Typing 14 or 15 zeroes plus the actual > > > > > >>LUN value into a field in the DHCP GUI is quite error-prone, since in > > > > > >>a DHCP server's user interface or /etc/dhcpd.conf, this string will be > > > > > >>entered directly by the end user. > > > > > >> > > > > > >>So in addition to the rules above, how about: > > > > > >> > > > > > >>- If the LUN field contains four or fewer hex digits, these digits > > > > > >>constitute the LUN number from which to boot. > > > > > >> > > > > > >>Page 5 > > > > > >> > > > > > >> > > > > > >>> It is possible that the port number obtained from the Discovery > > > > > >>> Service may conflict with the one obtained from the DHCP service. In > > > > > >>> such a case, the implementor has the option to try both port numbers > > > > > >>> in the Boot stage. > > > > > >> > > > > > >>In this case, I think that we should pick one to take precedence, > > > > instead > > > > > >>of leaving it up to the implementor. Since the discovery service should > > > > > >>have the most up-to-date IP address and port number information, I think > > > > > >>that it should be the one that is used. > > > > > >> > > > > > >>-- > > > > > >>Mark A. Bakke > > > > > >>Cisco Systems > > > > > >>mbakke@cisco.com > > > > > >>763.398.1054 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > 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 Wed Sep 11 20:25:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29374 for ; Wed, 11 Sep 2002 20:25:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8BNoUq11471 for ips-outgoing; Wed, 11 Sep 2002 19:50:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8BNoQo11463 for ; Wed, 11 Sep 2002 19:50:26 -0400 (EDT) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 74433E2F; Wed, 11 Sep 2002 17:50:25 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by relcos2.cos.agilent.com (Postfix) with SMTP id 95F784B0; Wed, 11 Sep 2002 17:49:40 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 11 Sep 2002 17:50:24 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Sep 2002 17:50:23 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00E182D9B@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: marjorie_krueger@hp.com, mbakke@cisco.com, pat_thaler@agilent.com Cc: erodrigu@Brocade.COM, ips@ece.cmu.edu, kaladhar@us.ibm.com, Black_David@emc.com Subject: RE: iSCSI: Last call issues for the Naming and Discovery document Date: Wed, 11 Sep 2002 17:50:21 -0600 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 That looks like a good change. Pat -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) As to Pat's comment that "iSCSI device" should be used where "SCSI device" is used, I disagree. SCSI get's it's device name from the transport, and this sentence is pointing out that the SCSI device name is derived from the iSCSI name. Perhaps if you change the following sentence: "The iSCSI name of a SCSI device is the principal object used in authentication of targets to initiators and initiators to targets." to "The iSCSI name is the principal object used in authentication of targets to initiators and initiators to targets." removing the reference to the "SCSI device"ness to avoid overloading this sentence? Cheers, Marj From owner-ips@ece.cmu.edu Thu Sep 12 02:01:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06250 for ; Thu, 12 Sep 2002 02:01:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8C5J7i26278 for ips-outgoing; Thu, 12 Sep 2002 01:19:07 -0400 (EDT) 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 g8C5J3o26272 for ; Thu, 12 Sep 2002 01:19:03 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8C5IrHR075492; Thu, 12 Sep 2002 07:18:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8C5InuD091512; Thu, 12 Sep 2002 07:18:51 +0200 To: "Lee Xing" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Changes made from 0.15 to 0.16 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 12 Sep 2002 08:18:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/09/2002 08:18:53, Serialize complete at 12/09/2002 08:18:53 Content-Type: multipart/alternative; boundary="=_alternative 001CEC2CC2256C32_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001CEC2CC2256C32_= Content-Type: text/plain; charset="us-ascii" Edits and a clarification on task abort and immediate tasks (chapter 9). Julo "Lee Xing" 11/09/02 23:08 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: Changes made from 0.15 to 0.16 Hi Julian, Could you please tell me all the changes made from 0.15 to 0.16. I downloaded a 0.16 working draft on 8/30/2002 which contains the following changes: - Text cleanup - ExpDataSN in TM Reassign can use 0 to say "all unacked" data - Reorganized the recovery section But I'm not sure if more changes have been added to the 0.16 release version after 8/30/02. Thanks, Lee Xing Crossroads Systems, Inc. --=_alternative 001CEC2CC2256C32_= Content-Type: text/html; charset="us-ascii"
Edits and a clarification on task abort and immediate tasks  (chapter 9).

Julo


"Lee Xing" <lxing@crossroads.com>

11/09/02 23:08

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        iSCSI: Changes made from 0.15 to 0.16

       


Hi Julian,
 
Could you please tell me all the changes made from 0.15 to 0.16.
 
I downloaded a 0.16 working draft on 8/30/2002 which contains the following changes:  
 
     - Text cleanup
    - ExpDataSN in TM Reassign can use 0 to say "all unacked" data
    - Reorganized the recovery section
 
But I'm not sure if more changes have been added to the 0.16 release version after 8/30/02.
 
Thanks,
 
 
Lee Xing
Crossroads Systems, Inc.
 
 
 

--=_alternative 001CEC2CC2256C32_=-- From owner-ips@ece.cmu.edu Thu Sep 12 14:22:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02161 for ; Thu, 12 Sep 2002 14:22:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8CHYoe12220 for ips-outgoing; Thu, 12 Sep 2002 13:34:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8CHYmo12215 for ; Thu, 12 Sep 2002 13:34:48 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g8CHYdO26076 for ; Thu, 12 Sep 2002 10:34:39 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Sep 2002 10:34:39 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: iSCSI: Boot draft -- Technical comment Date: Thu, 12 Sep 2002 10:34:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25A82.AAF77E70" 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_01C25A82.AAF77E70 Content-Type: text/plain; charset="iso-8859-1" [Chair hat off] Is the notation used for an IPv6 address in iSCSI boot the appropriate format to use? iSCSI N&D used [] enclosed address. Elizabeth ------_=_NextPart_001_01C25A82.AAF77E70 Content-Type: text/html; charset="iso-8859-1" iSCSI: Boot draft -- Technical comment

[Chair hat off]

Is the notation used for an IPv6 address in iSCSI boot the appropriate format to use?
iSCSI N&D used [] enclosed address.

Elizabeth

------_=_NextPart_001_01C25A82.AAF77E70-- From owner-ips@ece.cmu.edu Thu Sep 12 14:22:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02229 for ; Thu, 12 Sep 2002 14:22:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8CI5uK14419 for ips-outgoing; Thu, 12 Sep 2002 14:05:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub2.almaden.ibm.com (p1.almaden.ibm.com [198.4.83.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8CI5ro14412 for ; Thu, 12 Sep 2002 14:05:53 -0400 (EDT) Received: from ibmjh9qh9xf2ft (ibm-jh9qh9xf2ft.almaden.ibm.com [9.1.22.179]) by mailhub2.almaden.ibm.com (AIX4.3/8.9.3/8.9.3) with SMTP id LAA51506; Thu, 12 Sep 2002 11:05:46 -0700 Message-ID: <016901c25a86$e2955470$b3160109@almaden.ibm.com> From: "Prasenjit Sarkar" To: "Elizabeth Rodriguez" , References: Subject: Re: iSCSI: Boot draft -- Technical comment Date: Thu, 12 Sep 2002 11:04:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01C25A4C.36197E90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0166_01C25A4C.36197E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI: Boot draft -- Technical commentTHis is a format specific to iSCSI = boot and I've checked that this format is permissible, Thanks, Prasenjit ----- Original Message -----=20 From: Elizabeth Rodriguez=20 To: ips@ece.cmu.edu=20 Sent: Thursday, September 12, 2002 10:34 AM Subject: iSCSI: Boot draft -- Technical comment [Chair hat off]=20 Is the notation used for an IPv6 address in iSCSI boot the appropriate = format to use?=20 iSCSI N&D used [] enclosed address.=20 Elizabeth=20 ------=_NextPart_000_0166_01C25A4C.36197E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI: Boot draft -- Technical comment
THis is a format specific to iSCSI boot = and I've=20 checked that this format is permissible,
 
Thanks,
Prasenjit
----- Original Message -----
From:=20 Elizabeth=20 Rodriguez
Sent: Thursday, September 12, = 2002 10:34=20 AM
Subject: iSCSI: Boot draft -- = Technical=20 comment

[Chair hat off]

Is the notation used for an IPv6 = address in iSCSI=20 boot the appropriate format to use?
iSCSI=20 N&D used [] enclosed address.

Elizabeth =

------=_NextPart_000_0166_01C25A4C.36197E90-- From owner-ips@ece.cmu.edu Thu Sep 12 16:53:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07807 for ; Thu, 12 Sep 2002 16:53:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8CK7pV23477 for ips-outgoing; Thu, 12 Sep 2002 16:07:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8CK7Yo23462 for ; Thu, 12 Sep 2002 16:07:35 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g8CK5cH00820; Thu, 12 Sep 2002 16:05:39 -0400 Message-ID: <3D80F395.E42DE4AA@splentec.com> Date: Thu, 12 Sep 2002 16:05:41 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Mallikarjun C." CC: Mark Bakke , Prasenjit Sarkar , Constantine Sapuntzakis , ips@ece.cmu.edu Subject: Re: iSCSI Boot Last Call - Technical Comments References: <3D7E1E24.980D329C@cisco.com> <3D7E3743.5050306@stanford.edu> <005601c2590e$882a4140$fe150109@almaden.ibm.com> <3D7E66A6.47D62427@cisco.com> <010b01c25926$ab18e540$edd52b0f@rose.hp.com> <3D7FC3DE.1DCF2F77@cisco.com> <00bb01c259e7$25111870$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Mallikarjun C." wrote: > > Mark, > > >I don't think most > > users will ever want (or need) to see more than a 16-bit LUN. > > Having a 32/48/64-bit LUN, I believe, doesn't mean that there are > more than 2^16 LUNs. IIRC, the 64-bit LUN address space > can be sparsely populated, depending on how many levels of > addressing a target supports and which specific LUs are distributed > into which level. So, I cannot agree with this statement. Agreed completely with Mallikarjun on all 2 points. A LUN _is_ 64 bit and so it should be used. The argument regarding the error-prone user input and GUI problems has NOTHING to do with the issue. Those are HCI (human computer interaction) issues and should be raised as such elsewhere. E.g. Let blank mean a default LUN (maybe 0, or in the future if T10 defines a well-known to boot from LUN), else a 64 bit lun should be entered. (IPv6 argument as well...) -- Luben P.S. I raised the exact same argument on Linux SCSI a month ago -- the move towards 64 bit LUN for the exact same points: sparce space, LUN mapping, etc. From owner-ips@ece.cmu.edu Fri Sep 13 11:56:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09996 for ; Fri, 13 Sep 2002 11:56:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8DF5TI01374 for ips-outgoing; Fri, 13 Sep 2002 11:05:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8DF5Qo01365 for ; Fri, 13 Sep 2002 11:05:27 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119372>; Fri, 13 Sep 2002 11:05:20 -0400 Reply-To: From: "Tony Battersby" To: Subject: iSCSI Usage of Retry editorial comment Date: Fri, 13 Sep 2002 11:05:20 -0400 Message-ID: <002301c25b36$fb25df40$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In Section 5.2.1, Usage of Retry, the text implies (but does not explicitly state) that a command marked for immediate delivery cannot be retried. IMHO, this limitation is easy to overlook, and is worth stating explicitly. Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Fri Sep 13 14:34:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15163 for ; Fri, 13 Sep 2002 14:34:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8DHhRB11850 for ips-outgoing; Fri, 13 Sep 2002 13:43:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8DHhPo11842 for ; Fri, 13 Sep 2002 13:43:25 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g8DHhJO02052; Fri, 13 Sep 2002 10:43:19 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Sep 2002 10:43:18 -0700 Message-ID: From: Robert Snively To: "'shesha bhushan'" , ips@ece.cmu.edu Subject: RE: Logical Block Addresses in SCSI Date: Fri, 13 Sep 2002 10:43:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25B4D.063940A0" 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_01C25B4D.063940A0 Content-Type: text/plain The development of LBA's is not done by SCSI. It is done by file systems, applications, and drivers outside the SCSI layer. In most cases, references to directories or other meta-data is required to obtain correct LBA's for a remote disk. > -----Original Message----- > From: shesha bhushan [mailto:bhushan_vadulas@hotmail.com] > Sent: Tuesday, September 03, 2002 1:31 PM > To: ips@ece.cmu.edu > Subject: Logical Block Addresses in SCSI > > > Hi All, > > I have mounted a remote directory and created a file. So this > will generate > SCSI WRITE CDBs that contain Logical Block Addresses (LBA) which is > encapsulated in an ISCSI command PDU. How did SCSI at the > local system > generate a valid LBA for the remote disk? > > I appertiate all your answers. > > Thanking You > Shesha > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > ------_=_NextPart_001_01C25B4D.063940A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Logical Block Addresses in SCSI

The development of LBA's is not done by SCSI.  = It is
done by file systems, applications, and drivers = outside
the SCSI layer.  In most cases, references to = directories
or other meta-data is required to obtain correct = LBA's for
a remote disk.

> -----Original Message-----
> From: shesha bhushan [mailto:bhushan_vadulas@hotma= il.com]
> Sent: Tuesday, September 03, 2002 1:31 = PM
> To: ips@ece.cmu.edu
> Subject: Logical Block Addresses in SCSI
>
>
> Hi All,
>
> I have mounted a remote directory and created a = file. So this
> will generate
> SCSI WRITE CDBs that contain Logical Block = Addresses (LBA) which is
> encapsulated in an ISCSI command PDU. How did = SCSI at the
> local system
> generate a valid LBA for the remote = disk?
>
> I appertiate all your answers.
>
> Thanking You
> Shesha
>
> = _________________________________________________________________=
> Send and receive Hotmail on your mobile device: = http://mobile.msn.com
>

------_=_NextPart_001_01C25B4D.063940A0-- From owner-ips@ece.cmu.edu Fri Sep 13 17:10:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19159 for ; Fri, 13 Sep 2002 17:10:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8DKOJD22652 for ips-outgoing; Fri, 13 Sep 2002 16:24:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8DKOGo22647 for ; Fri, 13 Sep 2002 16:24:17 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8DKOAKB016241; Fri, 13 Sep 2002 13:24:10 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8DKO888018778; Fri, 13 Sep 2002 13:24:08 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA26483; Fri, 13 Sep 2002 13:23:56 -0700 (PDT) Message-ID: <3D824DE6.39112B93@cisco.com> Date: Fri, 13 Sep 2002 15:43:18 -0500 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: Robert Grant CC: ips@ece.cmu.edu Subject: Re: IPS-All: WG Last Call on "iSCSI Naming and Discovery" References: <8C4B1DAFE17AE14AABFB2F866B64AB39022B9C@nyexu01.mcdata.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert- I agree, and will add your caveat. Thanks, Mark Robert Grant wrote: > > Hello, > > One aspect of the Naming and Discovery draft that I find misleading lies in > the sentence in Section B.3 > > "The gateway may manufacture its own iSCSI Names, or use those provided by > the real devices." > > Now B.3 deals with non-iSCSI devices, so does the phrase "those provided by > the real devices" refer to non-iSCSI devices providing an iSCSI Name? I read > "those provided by the real devices" as the native identifiers (i.e. FC > WWN). This may lead to the conclusion that a Gateway can use the "eui." form > of the iSCSI name in a fairly straight-forward manner. Unfortunately, we > know is not true (at least for the case where multiple gateways can see the > same device on a SAN). So - I suggest a caveat is warranted, like > > "It is the responsibility of the gateway to ensure the uniqueness of any > iSCSI name it manufactures. The gateway may need to account for multiple > gateways having access to a single real device". > > Now - of course I would REALLY like to see something done at the naming > level that would allow gateway vendors to preserve some part of the identity > of the real device in a non-proprietary fashion. But at least alerting > readers to the problem would be a good step. > > Regards, > Rob. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sat Sep 14 02:34:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06580 for ; Sat, 14 Sep 2002 02:34:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8E5n1c15107 for ips-outgoing; Sat, 14 Sep 2002 01:49:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8E5mxo15103 for ; Sat, 14 Sep 2002 01:48:59 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8E5mrxj051952 for ; Sat, 14 Sep 2002 07:48:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8E5mqTj024588 for ; Sat, 14 Sep 2002 07:48:52 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI Usage of Retry editorial comment X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 14 Sep 2002 08:48:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/09/2002 08:48:52, Serialize complete at 14/09/2002 08:48:52 Content-Type: multipart/alternative; boundary="=_alternative 001FE909C2256C34_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001FE909C2256C34_= Content-Type: text/plain; charset="us-ascii" I am not sure that we have to say something about retry on immediate comand as the loss of an immediate command can't be detected by any of the listed mechanisms. Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 13/09/02 18:05 Please respond to tonyb To: cc: Subject: iSCSI Usage of Retry editorial comment In Section 5.2.1, Usage of Retry, the text implies (but does not explicitly state) that a command marked for immediate delivery cannot be retried. IMHO, this limitation is easy to overlook, and is worth stating explicitly. Anthony J. Battersby Cybernetics --=_alternative 001FE909C2256C34_= Content-Type: text/html; charset="us-ascii"
I  am not sure that we have to say something about retry on immediate comand as the loss of an immediate command can't be detected by any of the listed mechanisms.

Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

13/09/02 18:05
Please respond to tonyb

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI Usage of Retry editorial comment

       


In Section 5.2.1, Usage of Retry, the text implies (but does not explicitly
state) that a command marked for immediate delivery cannot be retried.
IMHO, this limitation is easy to overlook, and is worth stating explicitly.

Anthony J. Battersby
Cybernetics

--=_alternative 001FE909C2256C34_=-- From owner-ips@ece.cmu.edu Sun Sep 15 19:55:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12939 for ; Sun, 15 Sep 2002 19:55:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8FN2s821369 for ips-outgoing; Sun, 15 Sep 2002 19:02:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cubert.attheoffice.org (cubert.attheoffice.org [216.62.240.170]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8FN2qo21362 for ; Sun, 15 Sep 2002 19:02:53 -0400 (EDT) Received: from subjeKt.volcom.net (adsl-64-172-181-222.dsl.snfc21.pacbell.net [64.172.181.222]) by cubert.attheoffice.org (8.11.2/8.11.2) with ESMTP id g8FLsl808355 for ; Sun, 15 Sep 2002 16:54:48 -0500 Subject: iSCSI: Recognizing Recovery R2Ts From: Nick Bellinger To: ips@ece.cmu.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 15 Sep 2002 15:54:30 -0600 Message-Id: <1032126871.32736.13.camel@subjeKt> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Greetings all, The question is how does an initiator know when a R2T is a recovery R2T and not a normal R2T? The case I am referring is in regard to the last paragraph in section 9.8 of iSCSI-v17-working: "DataSequenceInOrder governs the buffer offset ordering in consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST refer to continuous non-overlapping ranges except for Recovery-R2Ts." So the initiator is allowed to ignore the buffer offset in the case of DataSequenceInOrder=Yes when receiving a Recovery R2T, but how does the initiator know in fact an R2T is being used for within-command recovery? AFAICS there is no "Recovery bit" in the R2T pdu, and am at a loss as to how the initiator would reliably ascertain this situation. Cheers, Nicholas Bellinger - PyxTechnologies.com From owner-ips@ece.cmu.edu Sun Sep 15 20:44:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13414 for ; Sun, 15 Sep 2002 20:44:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G08bg23260 for ips-outgoing; Sun, 15 Sep 2002 20:08:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G08ao23256 for ; Sun, 15 Sep 2002 20:08:36 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Sep 2002 20:08:30 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C2D0@CORPMX14> From: Black_David@emc.com To: nickb@attheoffice.org, ips@ece.cmu.edu Subject: RE: iSCSI: Recognizing Recovery R2Ts Date: Sun, 15 Sep 2002 20:08:26 -0400 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 > The question is how does an initiator know when a R2T is a recovery > R2T and not a normal R2T? The case I am referring is in regard to the > last paragraph in section 9.8 of iSCSI-v17-working: > > "DataSequenceInOrder governs the buffer offset ordering in consecutive > R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST refer > to continuous non-overlapping ranges except for Recovery-R2Ts." > > So the initiator is allowed to ignore the buffer offset in the case of > DataSequenceInOrder=Yes when receiving a Recovery R2T, No, the initiator is *never* allowed to ignore the buffer offset. An R2T *always* describes the data that the Target wants transferred. > but how does the initiator know in fact an R2T is being used for > within-command recovery? AFAICS there is no "Recovery bit" in the > R2T pdu, and am at a loss as to how the initiator would reliably > ascertain this situation. A Recovery R2T is a retry of part or all of some previous R2T. Whether the initiator knows this depends on whether it saw the previous R2T. The initiator's behavir should not be affected - it is supposed to respond to R2Ts (including retries, as allowed by DataSequenceInOrder - see Section 11.19) until the target gets all the data it wants and issues a SCSI Response. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Sep 15 21:36:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13956 for ; Sun, 15 Sep 2002 21:36:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G0rI324649 for ips-outgoing; Sun, 15 Sep 2002 20:53:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G0rGo24644 for ; Sun, 15 Sep 2002 20:53:16 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8G0r7G10125 for ; Sun, 15 Sep 2002 20:53:08 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g8G0r7722326 for ; Sun, 15 Sep 2002 20:53:07 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Sep 2002 20:53:07 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C2D2@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI Boot - LUN size Date: Sun, 15 Sep 2002 20:53:03 -0400 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 With WG co-chair hat off: I realize that I'm supposed to be closing this issue, but I think Mark has a point here. To illustrate that point, let me start with Luben's concise rebuttal: > The argument regarding the error-prone user input and GUI problems > has NOTHING to do with the issue. Those are HCI (human computer > interaction) issues and should be raised as such elsewhere. There's a hidden assumption buried in there, and that is that all of the HCI issues caused by the introduction of iSCSI into an environment have been addressed (i.e., all the appropriate software components that have any need to be iSCSI-aware have been appropriately modified). While that's a fine assumption for the long term, there are crucial components for which it is manifestly not true in the short term, the DHCP servers. When iSCSI goes into an environment, it has to work with the existing DHCP server(s), not the possible future one(s) that will be modified to deal with iSCSI HCI issues ... and those modification requests are somewhere in a large stack of other things that the DHCP server developers need to worry about. Mark's point was that allowing a 16-bit LUN format (NOTE: not requiring its use, 64 bits are still needed for full functionality/generality) will simplify a transition issue with *existing* DHCP servers. I tend to agree. With WG co-chair hat on: The above issue is the only technical issue against the boot draft. It needs to be resolved here on the list. Once it's resolved, a new version of the boot draft containing the resolution and responses to editorial comments will be forwarded to the ADs/IESG - a second WG Last Call will not be necessary. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Sep 15 21:36:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13974 for ; Sun, 15 Sep 2002 21:36:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G1I0M25472 for ips-outgoing; Sun, 15 Sep 2002 21:18:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cubert.attheoffice.org (cubert.attheoffice.org [216.62.240.170]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G1Hwo25468 for ; Sun, 15 Sep 2002 21:17:58 -0400 (EDT) Received: from subjeKt.volcom.net (adsl-64-172-181-222.dsl.snfc21.pacbell.net [64.172.181.222]) by cubert.attheoffice.org (8.11.2/8.11.2) with ESMTP id g8G09r809220; Sun, 15 Sep 2002 19:09:53 -0500 Subject: RE: iSCSI: Recognizing Recovery R2Ts From: Nick Bellinger To: Black_David@emc.com Cc: ips@ece.cmu.edu In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C2D0@CORPMX14> References: <277DD60FB639D511AC0400B0D068B71E0564C2D0@CORPMX14> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 15 Sep 2002 18:09:34 -0600 Message-Id: <1032134975.32734.99.camel@subjeKt> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, On Sun, 2002-09-15 at 18:08, Black_David@emc.com wrote: > > The question is how does an initiator know when a R2T is a recovery > > R2T and not a normal R2T? The case I am referring is in regard to the > > last paragraph in section 9.8 of iSCSI-v17-working: > > > > "DataSequenceInOrder governs the buffer offset ordering in consecutive > > R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST refer > > to continuous non-overlapping ranges except for Recovery-R2Ts." > > > > So the initiator is allowed to ignore the buffer offset in the case of > > DataSequenceInOrder=Yes when receiving a Recovery R2T, > > No, the initiator is *never* allowed to ignore the buffer offset. An > R2T *always* describes the data that the Target wants transferred. > Sorry, left out a key word here. I had intended to say "buffer offset ordering". > > but how does the initiator know in fact an R2T is being used for > > within-command recovery? AFAICS there is no "Recovery bit" in the > > R2T pdu, and am at a loss as to how the initiator would reliably > > ascertain this situation. > > A Recovery R2T is a retry of part or all of some previous R2T. > Whether the initiator knows this depends on whether it saw the > previous R2T. The initiator's behavir should not be affected - > it is supposed to respond to R2Ts (including retries, as allowed > by DataSequenceInOrder - see Section 11.19) until the target gets > all the data it wants and issues a SCSI Response. > Im still lost here. Please consider the example: MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No, InitialR2T=Yes. I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0 I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192 I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192 I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, DataLength=8192 (Data Payload Fails on DataSN=2) T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3, DataLength=8192 Can the Target either: (Are both of these legal?) a) Accept DataSN=3 even though DataSN=2 Failed Only request retransmisson of Failed DataOut T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384 or b) Discard DataSN=3, Request retransmission of all DataOut from failed to MaxBurstLength T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384 Initiator: (This is where im confused) Received either a) or b), and knows the R2T is a Recovery R2T because the DDTL is not 32768 (MaxBurstLength or rest of the original EDTL) and Offset is not 32768. Following a) I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, DataLength=8192 Following B) I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 Target: MaxBurstLength is Completed: T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768 I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, DataLength=8192 Etc.... Your statement "Whether the initiator knows this depends on whether it saw the previous R2T" is still confusing to me. The logic used in the above example (EDTL and Offset) I assume is incorrect. Would you mind elaborating with a specific example of the proper method of doing so? Thanks David! Nicholas Bellinger - Pyxtechnologies.com > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Sun Sep 15 22:13:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14485 for ; Sun, 15 Sep 2002 22:13:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G1jJc26360 for ips-outgoing; Sun, 15 Sep 2002 21:45:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G1jHo26354 for ; Sun, 15 Sep 2002 21:45:17 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Sep 2002 21:45:12 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C2D5@CORPMX14> From: Black_David@emc.com To: nickb@attheoffice.org Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Recognizing Recovery R2Ts Date: Sun, 15 Sep 2002 21:45:08 -0400 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 > Im still lost here. Please consider the example: > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No, > InitialR2T=Yes. > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0 > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192 > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192 > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, DataLength=8192 > > (Data Payload Fails on DataSN=2) > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3, > DataLength=8192 > > Can the Target either: (Are both of these legal?) > > a) Accept DataSN=3 even though DataSN=2 Failed > Only request retransmisson of Failed DataOut > T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384 > > or b) Discard DataSN=3, Request retransmission of > all DataOut from failed to MaxBurstLength > T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384 Yes, both are legal, a) is preferred for obvious reasons. > Initiator: (This is where im confused) > Received either a) or b), and knows the R2T is a Recovery > R2T because the DDTL is not 32768 (MaxBurstLength or rest of > the original EDTL) and Offset is not 32768. Not exactly. The R2T is a recovery R2T because it requests data covered by the previous R2T (Offset < 32768). This doesn't affect the initiator's behavior - it just responds to the R2T it receives. > Following a) > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > DataLength=8192 > > Following B) > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 I think you flipped the a) and b) cases above, so you clearly are confused :-). In both cases, the initiator looks at the R2T to determine what data the Target is asking for and sends it - a) asked for 8k, b) asked for 16k. The one PDU that responds to a) needs to have the F bit set, as it completes the response to the second R2T. If the target needs to distinguish the recovery data transfer from the original transfer, it should use a different Target Transfer Tag in the recovery R2T. > Target: > MaxBurstLength is Completed: > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768 > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, DataLength=8192 Ok. > Your statement "Whether the initiator knows this depends on whether it > saw the previous R2T" is still confusing to me. The logic used in the > above example (EDTL and Offset) I assume is incorrect. Would you mind > elaborating with a specific example of the proper method of doing so? I don't understand the problem here. In all cases, the initiator looks at the offset and length in the R2T it receives and sends the data requested by that R2T. In both cases a) and b) above, the initiator can tell that it's a recovery R2T because the requested data range overlaps a previous R2T. The statement I wrote covers a completely different case in which the target sends an R2T that doesn't arrive (e.g., header digest error), and decides to try to recover from that. I also don't understand the reference to EDTL in the command (as opposed to DDTL in the R2T0. If a Recovery R2T causes more than EDTL of data to be transferred for a command that's fine - the target is in charge of data flow and will tell the initiator when the command was complete and how much was actually transferred (consider unexpected end-of-tape on a tape device to understand why this is done this way). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Sep 15 22:15:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14510 for ; Sun, 15 Sep 2002 22:15:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G1WPX25912 for ips-outgoing; Sun, 15 Sep 2002 21:32:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cubert.attheoffice.org (cubert.attheoffice.org [216.62.240.170]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G1WMo25906 for ; Sun, 15 Sep 2002 21:32:22 -0400 (EDT) Received: from subjeKt.volcom.net (adsl-64-172-181-222.dsl.snfc21.pacbell.net [64.172.181.222]) by cubert.attheoffice.org (8.11.2/8.11.2) with ESMTP id g8G0OH809244; Sun, 15 Sep 2002 19:24:17 -0500 Subject: RE: iSCSI: Recognizing Recovery R2Ts From: Nick Bellinger To: Black_David@emc.com Cc: ips@ece.cmu.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 15 Sep 2002 18:23:59 -0600 Message-Id: <1032135840.32736.103.camel@subjeKt> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Correction of an obvious error in the previous example: "Following a) I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, DataLength=8192 Following B) I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192" A and B should be switched here. Thanks, Nicholas Bellinger - Pyxtechnologies.com From owner-ips@ece.cmu.edu Sun Sep 15 22:17:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14528 for ; Sun, 15 Sep 2002 22:17:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G1wRw26810 for ips-outgoing; Sun, 15 Sep 2002 21:58:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G1wQo26805 for ; Sun, 15 Sep 2002 21:58:26 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Sep 2002 21:58:21 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C2D6@CORPMX14> From: Black_David@emc.com To: nickb@attheoffice.org Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Recognizing Recovery R2Ts Date: Sun, 15 Sep 2002 21:58:17 -0400 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 One additional important note - the Recovery R2T generates its own data sequence, so in the following: > > Following a) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > DataLength=8192 > > > > Following B) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 The DataSN's should be 0 and 1, not 2 and 3 (and in the B) case above, the F bit needs to be set, as I previously noted). The initiator really does respond to a Recovery R2T in the same fashion as any other R2T. Thanks, --David > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Sunday, September 15, 2002 9:45 PM > To: nickb@attheoffice.org > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > Im still lost here. Please consider the example: > > > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No, > > InitialR2T=Yes. > > > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 > > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0 > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, > DataLength=8192 > > > > (Data Payload Fails on DataSN=2) > > > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error > > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3, > > DataLength=8192 > > > > Can the Target either: (Are both of these legal?) > > > > a) Accept DataSN=3 even though DataSN=2 Failed > > Only request retransmisson of Failed DataOut > > T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384 > > > > or b) Discard DataSN=3, Request retransmission of > > all DataOut from failed to MaxBurstLength > > T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384 > > Yes, both are legal, a) is preferred for obvious reasons. > > > Initiator: (This is where im confused) > > Received either a) or b), and knows the R2T is a Recovery > > R2T because the DDTL is not 32768 (MaxBurstLength or rest of > > the original EDTL) and Offset is not 32768. > > Not exactly. The R2T is a recovery R2T because it requests data > covered by the previous R2T (Offset < 32768). This doesn't affect > the initiator's behavior - it just responds to the R2T it receives. > > > Following a) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > DataLength=8192 > > > > Following B) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > I think you flipped the a) and b) cases above, so you clearly are > confused :-). In both cases, the initiator looks at the R2T to > determine what data the Target is asking for and sends it - a) asked > for 8k, b) asked for 16k. The one PDU that responds to a) needs > to have the F bit set, as it completes the response to the second > R2T. If the target needs to distinguish the recovery data transfer > from the original transfer, it should use a different Target Transfer > Tag in the recovery R2T. > > > Target: > > MaxBurstLength is Completed: > > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768 > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, > DataLength=8192 > > Ok. > > > Your statement "Whether the initiator knows this depends on > whether it > > saw the previous R2T" is still confusing to me. The logic > used in the > > above example (EDTL and Offset) I assume is incorrect. > Would you mind > > elaborating with a specific example of the proper method of > doing so? > > I don't understand the problem here. In all cases, the initiator > looks at the offset and length in the R2T it receives and sends the > data requested by that R2T. In both cases a) and b) above, > the initiator > can tell that it's a recovery R2T because the requested data > range overlaps > a previous R2T. The statement I wrote covers a completely different > case in which the target sends an R2T that doesn't arrive > (e.g., header > digest error), and decides to try to recover from that. > > I also don't understand the reference to EDTL in the command > (as opposed to DDTL in the R2T0. If a Recovery R2T causes > more than EDTL of data to be transferred for a command that's fine - > the target is in charge of data flow and will tell the initiator when > the command was complete and how much was actually transferred > (consider unexpected end-of-tape on a tape device to understand > why this is done this way). > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Mon Sep 16 02:55:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27281 for ; Mon, 16 Sep 2002 02:55:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G5opN03898 for ips-outgoing; Mon, 16 Sep 2002 01:50:51 -0400 (EDT) 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 g8G5ono03891 for ; Mon, 16 Sep 2002 01:50:49 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8G5oXHR100380; Mon, 16 Sep 2002 07:50:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8G5oWpI026478; Mon, 16 Sep 2002 07:50:32 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, nickb@attheoffice.org, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Recognizing Recovery R2Ts X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 16 Sep 2002 08:50:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/09/2002 08:50:32, Serialize complete at 16/09/2002 08:50:32 Content-Type: multipart/alternative; boundary="=_alternative 001FC5EAC2256C36_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001FC5EAC2256C36_= Content-Type: text/plain; charset="us-ascii" Nick, I understand that your issue is mainly related to an initiator expecting "in order" R2Ts and seing an R2T that is out of order. The simplest answer (and the one that we had in mind when we designed the protocol) is that in general nodes willing to accept ErrorRecoveryLevels 1 and 2 will probably accept R2Ts out of order. In this case an initiator does not need to make any distinction. But not wanting to be that restrictive we let even nodes accepting only ordered R2Ts do recovery but then (if they care) they may:: initiators: reject any R2T that is unordered (i.e. do not recover) accept R2T based on having "previously seen it" (as David Black suggests) - with the caveat that if the R2T is lost you may have to fall back to 1 targets: have only one R2T outstanding if you have both "in order" and error recovery (a rare thing we believe) Regards, Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 16/09/02 04:58 To: nickb@attheoffice.org cc: ips@ece.cmu.edu Subject: RE: iSCSI: Recognizing Recovery R2Ts One additional important note - the Recovery R2T generates its own data sequence, so in the following: > > Following a) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > DataLength=8192 > > > > Following B) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 The DataSN's should be 0 and 1, not 2 and 3 (and in the B) case above, the F bit needs to be set, as I previously noted). The initiator really does respond to a Recovery R2T in the same fashion as any other R2T. Thanks, --David > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Sunday, September 15, 2002 9:45 PM > To: nickb@attheoffice.org > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > Im still lost here. Please consider the example: > > > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No, > > InitialR2T=Yes. > > > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 > > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0 > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, > DataLength=8192 > > > > (Data Payload Fails on DataSN=2) > > > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error > > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3, > > DataLength=8192 > > > > Can the Target either: (Are both of these legal?) > > > > a) Accept DataSN=3 even though DataSN=2 Failed > > Only request retransmisson of Failed DataOut > > T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384 > > > > or b) Discard DataSN=3, Request retransmission of > > all DataOut from failed to MaxBurstLength > > T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384 > > Yes, both are legal, a) is preferred for obvious reasons. > > > Initiator: (This is where im confused) > > Received either a) or b), and knows the R2T is a Recovery > > R2T because the DDTL is not 32768 (MaxBurstLength or rest of > > the original EDTL) and Offset is not 32768. > > Not exactly. The R2T is a recovery R2T because it requests data > covered by the previous R2T (Offset < 32768). This doesn't affect > the initiator's behavior - it just responds to the R2T it receives. > > > Following a) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > DataLength=8192 > > > > Following B) > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > I think you flipped the a) and b) cases above, so you clearly are > confused :-). In both cases, the initiator looks at the R2T to > determine what data the Target is asking for and sends it - a) asked > for 8k, b) asked for 16k. The one PDU that responds to a) needs > to have the F bit set, as it completes the response to the second > R2T. If the target needs to distinguish the recovery data transfer > from the original transfer, it should use a different Target Transfer > Tag in the recovery R2T. > > > Target: > > MaxBurstLength is Completed: > > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768 > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, > DataLength=8192 > > Ok. > > > Your statement "Whether the initiator knows this depends on > whether it > > saw the previous R2T" is still confusing to me. The logic > used in the > > above example (EDTL and Offset) I assume is incorrect. > Would you mind > > elaborating with a specific example of the proper method of > doing so? > > I don't understand the problem here. In all cases, the initiator > looks at the offset and length in the R2T it receives and sends the > data requested by that R2T. In both cases a) and b) above, > the initiator > can tell that it's a recovery R2T because the requested data > range overlaps > a previous R2T. The statement I wrote covers a completely different > case in which the target sends an R2T that doesn't arrive > (e.g., header > digest error), and decides to try to recover from that. > > I also don't understand the reference to EDTL in the command > (as opposed to DDTL in the R2T0. If a Recovery R2T causes > more than EDTL of data to be transferred for a command that's fine - > the target is in charge of data flow and will tell the initiator when > the command was complete and how much was actually transferred > (consider unexpected end-of-tape on a tape device to understand > why this is done this way). > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > --=_alternative 001FC5EAC2256C36_= Content-Type: text/html; charset="us-ascii"
Nick,

I understand that your issue is mainly related to an initiator expecting "in order" R2Ts and seing an R2T that is out of order.

The simplest answer (and the one that we had in mind when we designed the protocol) is that in general nodes willing to accept ErrorRecoveryLevels 1 and 2 will probably accept R2Ts out of order. In this case an initiator does not need to make any distinction.

But not wanting to be that restrictive we let even nodes accepting only ordered R2Ts do recovery but then (if they care) they may::
  • initiators:
  1. reject any R2T that is unordered (i.e. do not recover)
  2. accept R2T based on having "previously seen it"  (as David Black suggests) - with the caveat that if the R2T is lost you may have to fall back to  1
  • targets:
  1. have only one R2T outstanding if you have both "in order" and error recovery (a rare thing we believe)


    Regards,
    Julo


    Black_David@emc.com
    Sent by: owner-ips@ece.cmu.edu

    16/09/02 04:58

    		       
            To:        nickb@attheoffice.org
            cc:        ips@ece.cmu.edu
            Subject:        RE: iSCSI: Recognizing Recovery R2Ts

           


    One additional important note - the Recovery R2T generates
    its own data sequence, so in the following:

    > > Following a)
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
    > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3,
    > > DataLength=8192
    > >
    > > Following B)
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192

    The DataSN's should be 0 and 1, not 2 and 3 (and in the B) case above,
    the F bit needs to be set, as I previously noted).  The initiator really
    does respond to a Recovery R2T in the same fashion as any other R2T.

    Thanks,
    --David

    > -----Original Message-----
    > From: Black_David@emc.com [mailto:Black_David@emc.com]
    > Sent: Sunday, September 15, 2002 9:45 PM
    > To: nickb@attheoffice.org
    > Cc: ips@ece.cmu.edu
    > Subject: RE: iSCSI: Recognizing Recovery R2Ts
    >
    >
    > > Im still lost here.  Please consider the example:
    > >
    > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No,
    > > InitialR2T=Yes.
    > >
    > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10
    > > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2,
    > DataLength=8192
    > >
    > > (Data Payload Fails on DataSN=2)
    > >
    > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3,
    > > DataLength=8192
    > >
    > > Can the Target either: (Are both of these legal?)
    > >
    > >                  a) Accept DataSN=3 even though DataSN=2 Failed
    > >                     Only request retransmisson of Failed DataOut
    > >                  T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384
    > >
    > >                  or b) Discard DataSN=3, Request retransmission of
    > >                        all DataOut from failed to MaxBurstLength  
    > >                  T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384
    >
    > Yes, both are legal, a) is preferred for obvious reasons.
    >
    > > Initiator: (This is where im confused)
    > >                  Received either a) or b),  and knows the R2T is a Recovery
    > >                  R2T because the DDTL is not 32768 (MaxBurstLength or rest of
    > >                  the original EDTL) and Offset is not 32768.
    >
    > Not exactly.  The R2T is a recovery R2T because it requests data
    > covered by the previous R2T (Offset < 32768).  This doesn't affect
    > the initiator's behavior - it just responds to the R2T it receives.
    >
    > > Following a)
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
    > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3,
    > > DataLength=8192
    > >
    > > Following B)
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
    >
    > I think you flipped the a) and b) cases above, so you clearly are
    > confused :-).  In both cases, the initiator looks at the R2T to
    > determine what data the Target is asking for and sends it - a) asked
    > for 8k, b) asked for 16k.  The one PDU that responds to a) needs
    > to have the F bit set, as it completes the response to the second
    > R2T.  If the target needs to distinguish the recovery data transfer
    > from the original transfer, it should use a different Target Transfer
    > Tag in the recovery R2T.
    >
    > > Target:
    > >                  MaxBurstLength is Completed:
    > > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768
    > >
    > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0,
    > DataLength=8192
    >
    > Ok.
    >  
    > > Your statement "Whether the initiator knows this depends on
    > whether it
    > > saw the previous R2T" is still confusing to me.  The logic
    > used in the
    > > above example (EDTL and Offset) I assume is incorrect.  
    > Would you mind
    > > elaborating with a specific example of the proper method of
    > doing so?
    >
    > I don't understand the problem here.  In all cases, the initiator
    > looks at the offset and length in the R2T it receives and sends the
    > data requested by that R2T.  In both cases a) and b) above,
    > the initiator
    > can tell that it's a recovery R2T because the requested data
    > range overlaps
    > a previous R2T.  The statement I wrote covers a completely different
    > case in which the target sends an R2T that doesn't arrive
    > (e.g., header
    > digest error), and decides to try to recover from that.
    >
    > I also don't understand the reference to EDTL in the command
    > (as opposed to DDTL in the R2T0.  If a Recovery R2T causes
    > more than EDTL of data to be transferred for a command that's fine -
    > the target is in charge of data flow and will tell the initiator when
    > the command was complete and how much was actually transferred
    > (consider unexpected end-of-tape on a tape device to understand
    > why this is done this way).
    >
    > Thanks,
    > --David
    > ---------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC Corporation, 42 South St., Hopkinton, MA  01748
    > +1 (508) 249-6449            FAX: +1 (508) 497-8018
    > black_david@emc.com       Mobile: +1 (978) 394-7754
    > ---------------------------------------------------
    >


--=_alternative 001FC5EAC2256C36_=-- From owner-ips@ece.cmu.edu Mon Sep 16 03:07:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27480 for ; Mon, 16 Sep 2002 03:07:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G6dqA05057 for ips-outgoing; Mon, 16 Sep 2002 02:39:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G6dpo05053 for ; Mon, 16 Sep 2002 02:39:51 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel9.hp.com (Postfix) with ESMTP id 888D2E003EF; Mon, 16 Sep 2002 02:39:46 -0400 (EDT) Received: from swathi (atl1nai176134.ssr.hp.com [15.228.176.134]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id XAA28112; Sun, 15 Sep 2002 23:39:44 -0700 (PDT) Message-ID: <008001c25d4b$d74d4150$96b0e40f@rose.hp.com> From: "Mallikarjun C." To: "Nick Bellinger" , References: <1032126871.32736.13.camel@subjeKt> Subject: Re: iSCSI: Recognizing Recovery R2Ts Date: Sun, 15 Sep 2002 23:04:10 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The question is how does an initiator know when a R2T is a recovery > R2T and not a normal R2T? The case I am referring is in regard to the > last paragraph in section 9.8 of iSCSI-v17-working: > > "DataSequenceInOrder governs the buffer offset ordering in consecutive > R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST refer > to continuous non-overlapping ranges except for Recovery-R2Ts." > > So the initiator is allowed to ignore the buffer offset in the case of > DataSequenceInOrder=Yes when receiving a Recovery R2T, but how does the > initiator know in fact an R2T is being used for within-command > recovery? AFAICS there is no "Recovery bit" in the R2T pdu, and am at > a loss as to how the initiator would reliably ascertain this situation. An operational ErrorRecoveryLevel>=1 and DataSequenceInOrder=Yes is assumed for this discussion. - Generally from the initiator's perspective, any R2T with a "Buffer Offset" that's seeking some data that the initiator already transmitted as Data-Out is a recognizable recovery R2T. - While the target may be generating a "recovery R2T" in some cases, the initiator may not recognize it as such because the earlier R2T was lost for the initiator. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Mon Sep 16 04:07:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28169 for ; Mon, 16 Sep 2002 04:07:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8G7RQT06236 for ips-outgoing; Mon, 16 Sep 2002 03:27:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cubert.attheoffice.org (cubert.attheoffice.org [216.62.240.170]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8G7ROo06232 for ; Mon, 16 Sep 2002 03:27:24 -0400 (EDT) Received: from subjeKt.volcom.net (adsl-64-172-181-222.dsl.snfc21.pacbell.net [64.172.181.222]) by cubert.attheoffice.org (8.11.2/8.11.2) with ESMTP id g8G6JH812648; Mon, 16 Sep 2002 01:19:18 -0500 Subject: RE: iSCSI: Recognizing Recovery R2Ts From: Nick Bellinger To: Julian Satran Cc: Black_David@emc.com, ips@ece.cmu.edu, cbm@rose.hp.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 16 Sep 2002 00:18:57 -0600 Message-Id: <1032157138.32734.145.camel@subjeKt> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, On Sun, 2002-09-15 at 23:50, Julian Satran wrote: > Nick, > > I understand that your issue is mainly related to an initiator expecting > "in order" R2Ts and seing an R2T that is out of order. > > The simplest answer (and the one that we had in mind when we designed the > protocol) is that in general nodes willing to accept ErrorRecoveryLevels 1 > and 2 will probably accept R2Ts out of order. In this case an initiator > does not need to make any distinction. > > But not wanting to be that restrictive we let even nodes accepting only > ordered R2Ts do recovery but then (if they care) they may:: > > initiators: > > reject any R2T that is unordered (i.e. do not recover) > accept R2T based on having "previously seen it" (as David Black suggests) > - with the caveat that if the R2T is lost you may have to fall back to 1 Considering ErrorRecoveryLevel>=1 and DataSequenceinOrder=Yes: The potentially lost R2T your referring to is the original one correct? Original meaning the R2T the initiator can use to determine if the R2T is infact a recovery R2T and is requesting retransmissing of an previously requested offset. If this is the case, I dont see how this situation could possibly happen. If the R2T the target originally sent gets lost and the initiator cannot send any data out without the lost R2T, how could the target possibly be able to generate a recovery r2t with differing offsets for a data out that was never received? So if this is indeed correct, the target generates a sequence timeout under the guise of within-command recovery, and sends a Recovery R2T with identical values to the one no data out was received for and presumed lost. And then if there is a Data Digest failure on data out the target generates a recovery R2T with a previously requested offset, and the initiator is able to tell the difference in R2Ts. I think this is a bit confusing (to me anyways) as a recovery R2T can either mean: a) A identical retransmission due to a header digest error (no data out received, manifests as a sequence timeout) b) Previously requested offset requested due to a data digest error. Is there something I am missing as to how the initiator with DataSequenceinOrder=Yes could lose an original R2T and still somehow receive a Recovery R2T (of type b) and have within-command recovery fail? Thanks Julian! Nicholas Bellinger - Pyxtechnologies.com > targets: > have only one R2T outstanding if you have both "in order" and error > recovery (a rare thing we believe) > > > Regards, > Julo > > > > > Black_David@emc.com > Sent by: owner-ips@ece.cmu.edu > 16/09/02 04:58 > > > To: nickb@attheoffice.org > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > One additional important note - the Recovery R2T generates > its own data sequence, so in the following: > > > > Following a) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > > DataLength=8192 > > > > > > Following B) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > The DataSN's should be 0 and 1, not 2 and 3 (and in the B) case above, > the F bit needs to be set, as I previously noted). The initiator really > does respond to a Recovery R2T in the same fashion as any other R2T. > > Thanks, > --David > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Sunday, September 15, 2002 9:45 PM > > To: nickb@attheoffice.org > > Cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > > > > Im still lost here. Please consider the example: > > > > > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No, > > > InitialR2T=Yes. > > > > > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 > > > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0 > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, > > DataLength=8192 > > > > > > (Data Payload Fails on DataSN=2) > > > > > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error > > > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3, > > > DataLength=8192 > > > > > > Can the Target either: (Are both of these legal?) > > > > > > a) Accept DataSN=3 even though DataSN=2 Failed > > > Only request retransmisson of Failed DataOut > > > T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384 > > > > > > or b) Discard DataSN=3, Request retransmission of > > > all DataOut from failed to MaxBurstLength > > > T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384 > > > > Yes, both are legal, a) is preferred for obvious reasons. > > > > > Initiator: (This is where im confused) > > > Received either a) or b), and knows the R2T is a > Recovery > > > R2T because the DDTL is not 32768 (MaxBurstLength or rest > of > > > the original EDTL) and Offset is not 32768. > > > > Not exactly. The R2T is a recovery R2T because it requests data > > covered by the previous R2T (Offset < 32768). This doesn't affect > > the initiator's behavior - it just responds to the R2T it receives. > > > > > Following a) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > > DataLength=8192 > > > > > > Following B) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > > I think you flipped the a) and b) cases above, so you clearly are > > confused :-). In both cases, the initiator looks at the R2T to > > determine what data the Target is asking for and sends it - a) asked > > for 8k, b) asked for 16k. The one PDU that responds to a) needs > > to have the F bit set, as it completes the response to the second > > R2T. If the target needs to distinguish the recovery data transfer > > from the original transfer, it should use a different Target Transfer > > Tag in the recovery R2T. > > > > > Target: > > > MaxBurstLength is Completed: > > > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768 > > > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, > > DataLength=8192 > > > > Ok. > > > > > Your statement "Whether the initiator knows this depends on > > whether it > > > saw the previous R2T" is still confusing to me. The logic > > used in the > > > above example (EDTL and Offset) I assume is incorrect. > > Would you mind > > > elaborating with a specific example of the proper method of > > doing so? > > > > I don't understand the problem here. In all cases, the initiator > > looks at the offset and length in the R2T it receives and sends the > > data requested by that R2T. In both cases a) and b) above, > > the initiator > > can tell that it's a recovery R2T because the requested data > > range overlaps > > a previous R2T. The statement I wrote covers a completely different > > case in which the target sends an R2T that doesn't arrive > > (e.g., header > > digest error), and decides to try to recover from that. > > > > I also don't understand the reference to EDTL in the command > > (as opposed to DDTL in the R2T0. If a Recovery R2T causes > > more than EDTL of data to be transferred for a command that's fine - > > the target is in charge of data flow and will tell the initiator when > > the command was complete and how much was actually transferred > > (consider unexpected end-of-tape on a tape device to understand > > why this is done this way). > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > From owner-ips@ece.cmu.edu Mon Sep 16 07:44:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00643 for ; Mon, 16 Sep 2002 07:44:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8GBHiW23428 for ips-outgoing; Mon, 16 Sep 2002 07:17:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cubert.attheoffice.org (cubert.attheoffice.org [216.62.240.170]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8GBHgo23424 for ; Mon, 16 Sep 2002 07:17:42 -0400 (EDT) Received: from subjeKt.volcom.net (adsl-64-172-181-222.dsl.snfc21.pacbell.net [64.172.181.222]) by cubert.attheoffice.org (8.11.2/8.11.2) with ESMTP id g8GA6R814657; Mon, 16 Sep 2002 05:06:27 -0500 Subject: RE: iSCSI: Recognizing Recovery R2Ts From: Nick Bellinger To: Julian Satran Cc: Black_David@emc.com, cbm@rose.hp.com, ips@ece.cmu.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 16 Sep 2002 04:06:05 -0600 Message-Id: <1032170766.32734.161.camel@subjeKt> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-09-16 at 04:52, Julian Satran wrote: > Nick, > > In case you have ErrorRecoveryLevel >=1 and DataSequenceInOrder=Yes then > then either: > > the target has only one outstanding R2T (to avoid at all price an > out-of-order R2T) > or the initiator can go by an out-of-order R2T if it is a data-offset it > has "passed-over" (even if not touched). Please observe that an initiator > is aware of the gap in the R2T sequence when an R2T is lost if the target > has more than one R2T missing and the missing one is not the last. If the > missing one is the last (or only) there will be no violation of ordering. > > Regards, > Julo. > The ordering rules require the offsets to be in non-decreasing order. > > Ok, just to few more points to verify with regard to a lost R2T due to a Header Digest error: In the case of ErrorRecoveryLevel=>1, DataSequenceinOrder=No and MaxOutStandingR2T=>1: Initiator is able to ascertain a lost R2T by receiving an R2TSN greater than expected, and sends a SNACK of type R2T to request retransmission of the lost R2T. Target retransmits R2T with identical values as the lost R2T. In the case of ErrorRecoveryLevel=>1, DataSequenceinOrder=Yes and MaxOutStandingR2T=1: Target will timeout waiting for Data OUT from the lost R2T and sends a Recovery R2T with identical values of the lost R2T. Thanks again for your time gentlemen, Nicholas Bellinger - Pyxtechnologies.com > > > Nick Bellinger > 16/09/02 09:18 > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: Black_David@emc.com, ips@ece.cmu.edu, cbm@rose.hp.com > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > Julian, > > On Sun, 2002-09-15 at 23:50, Julian Satran wrote: > > Nick, > > > > I understand that your issue is mainly related to an initiator expecting > > > "in order" R2Ts and seing an R2T that is out of order. > > > > The simplest answer (and the one that we had in mind when we designed > the > > protocol) is that in general nodes willing to accept ErrorRecoveryLevels > 1 > > and 2 will probably accept R2Ts out of order. In this case an initiator > > does not need to make any distinction. > > > > But not wanting to be that restrictive we let even nodes accepting only > > ordered R2Ts do recovery but then (if they care) they may:: > > > > initiators: > > > > reject any R2T that is unordered (i.e. do not recover) > > accept R2T based on having "previously seen it" (as David Black > suggests) > > - with the caveat that if the R2T is lost you may have to fall back to 1 > > Considering ErrorRecoveryLevel>=1 and DataSequenceinOrder=Yes: > > The potentially lost R2T your referring to is the original one correct? > Original meaning the R2T the initiator can use to determine if the R2T > is infact a recovery R2T and is requesting retransmissing of an > previously requested offset. > > If this is the case, I dont see how this situation could possibly > happen. If the R2T the target originally sent gets lost and the > initiator cannot send any data out without the lost R2T, how could the > target possibly be able to generate a recovery r2t with differing > offsets for a data out that was never received? > > So if this is indeed correct, the target generates a sequence timeout > under the guise of within-command recovery, and sends a Recovery R2T > with identical values to the one no data out was received for and > presumed lost. And then if there is a Data Digest failure on data out > the target generates a recovery R2T with a previously requested offset, > and the initiator is able to tell the difference in R2Ts. > > I think this is a bit confusing (to me anyways) as a recovery R2T can > either mean: > a) A identical retransmission due to a header digest > error (no data > out received, manifests as a sequence timeout) > b) Previously requested offset requested due to a data > digest > error. > > Is there something I am missing as to how the initiator with > DataSequenceinOrder=Yes could lose an original R2T and still somehow > receive a Recovery R2T (of type b) and have within-command recovery > fail? > > Thanks Julian! > > Nicholas Bellinger - Pyxtechnologies.com > > > targets: > > have only one R2T outstanding if you have both "in order" and error > > recovery (a rare thing we believe) > > > > > > Regards, > > Julo > > > > > > > > > > Black_David@emc.com > > Sent by: owner-ips@ece.cmu.edu > > 16/09/02 04:58 > > > > > > To: nickb@attheoffice.org > > cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > > > > > One additional important note - the Recovery R2T generates > > its own data sequence, so in the following: > > > > > > Following a) > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > > > DataLength=8192 > > > > > > > > Following B) > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > > The DataSN's should be 0 and 1, not 2 and 3 (and in the B) case above, > > the F bit needs to be set, as I previously noted). The initiator really > > does respond to a Recovery R2T in the same fashion as any other R2T. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Sunday, September 15, 2002 9:45 PM > > > To: nickb@attheoffice.org > > > Cc: ips@ece.cmu.edu > > > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > > > > > > > Im still lost here. Please consider the example: > > > > > > > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No, > > > > InitialR2T=Yes. > > > > > > > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 > > > > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0 > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192 > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192 > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, > > > DataLength=8192 > > > > > > > > (Data Payload Fails on DataSN=2) > > > > > > > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3, > > > > DataLength=8192 > > > > > > > > Can the Target either: (Are both of these legal?) > > > > > > > > a) Accept DataSN=3 even though DataSN=2 Failed > > > > Only request retransmisson of Failed DataOut > > > > T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384 > > > > > > > > or b) Discard DataSN=3, Request retransmission of > > > > all DataOut from failed to MaxBurstLength > > > > T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384 > > > > > > Yes, both are legal, a) is preferred for obvious reasons. > > > > > > > Initiator: (This is where im confused) > > > > Received either a) or b), and knows the R2T is a > > Recovery > > > > R2T because the DDTL is not 32768 (MaxBurstLength or > rest > > of > > > > the original EDTL) and Offset is not 32768. > > > > > > Not exactly. The R2T is a recovery R2T because it requests data > > > covered by the previous R2T (Offset < 32768). This doesn't affect > > > the initiator's behavior - it just responds to the R2T it receives. > > > > > > > Following a) > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > > > DataLength=8192 > > > > > > > > Following B) > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > > > > I think you flipped the a) and b) cases above, so you clearly are > > > confused :-). In both cases, the initiator looks at the R2T to > > > determine what data the Target is asking for and sends it - a) asked > > > for 8k, b) asked for 16k. The one PDU that responds to a) needs > > > to have the F bit set, as it completes the response to the second > > > R2T. If the target needs to distinguish the recovery data transfer > > > from the original transfer, it should use a different Target Transfer > > > Tag in the recovery R2T. > > > > > > > Target: > > > > MaxBurstLength is Completed: > > > > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768 > > > > > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, > > > DataLength=8192 > > > > > > Ok. > > > > > > > Your statement "Whether the initiator knows this depends on > > > whether it > > > > saw the previous R2T" is still confusing to me. The logic > > > used in the > > > > above example (EDTL and Offset) I assume is incorrect. > > > Would you mind > > > > elaborating with a specific example of the proper method of > > > doing so? > > > > > > I don't understand the problem here. In all cases, the initiator > > > looks at the offset and length in the R2T it receives and sends the > > > data requested by that R2T. In both cases a) and b) above, > > > the initiator > > > can tell that it's a recovery R2T because the requested data > > > range overlaps > > > a previous R2T. The statement I wrote covers a completely different > > > case in which the target sends an R2T that doesn't arrive > > > (e.g., header > > > digest error), and decides to try to recover from that. > > > > > > I also don't understand the reference to EDTL in the command > > > (as opposed to DDTL in the R2T0. If a Recovery R2T causes > > > more than EDTL of data to be transferred for a command that's fine - > > > the target is in charge of data flow and will tell the initiator when > > > the command was complete and how much was actually transferred > > > (consider unexpected end-of-tape on a tape device to understand > > > why this is done this way). > > > > > > Thanks, > > > --David > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Sep 16 07:45:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00666 for ; Mon, 16 Sep 2002 07:45:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8GAqrF22782 for ips-outgoing; Mon, 16 Sep 2002 06:52:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8GAqpo22778 for ; Mon, 16 Sep 2002 06:52:51 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8GAqgxj022486; Mon, 16 Sep 2002 12:52:43 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8GAqgpI013982; Mon, 16 Sep 2002 12:52:42 +0200 To: Nick Bellinger Cc: Black_David@emc.com, cbm@rose.hp.com, ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Recognizing Recovery R2Ts X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 16 Sep 2002 13:52:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/09/2002 13:52:42, Serialize complete at 16/09/2002 13:52:42 Content-Type: multipart/alternative; boundary="=_alternative 003B397BC2256C36_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003B397BC2256C36_= Content-Type: text/plain; charset="us-ascii" Nick, In case you have ErrorRecoveryLevel >=1 and DataSequenceInOrder=Yes then then either: the target has only one outstanding R2T (to avoid at all price an out-of-order R2T) or the initiator can go by an out-of-order R2T if it is a data-offset it has "passed-over" (even if not touched). Please observe that an initiator is aware of the gap in the R2T sequence when an R2T is lost if the target has more than one R2T missing and the missing one is not the last. If the missing one is the last (or only) there will be no violation of ordering. Regards, Julo. The ordering rules require the offsets to be in non-decreasing order. Nick Bellinger 16/09/02 09:18 To: Julian Satran/Haifa/IBM@IBMIL cc: Black_David@emc.com, ips@ece.cmu.edu, cbm@rose.hp.com Subject: RE: iSCSI: Recognizing Recovery R2Ts Julian, On Sun, 2002-09-15 at 23:50, Julian Satran wrote: > Nick, > > I understand that your issue is mainly related to an initiator expecting > "in order" R2Ts and seing an R2T that is out of order. > > The simplest answer (and the one that we had in mind when we designed the > protocol) is that in general nodes willing to accept ErrorRecoveryLevels 1 > and 2 will probably accept R2Ts out of order. In this case an initiator > does not need to make any distinction. > > But not wanting to be that restrictive we let even nodes accepting only > ordered R2Ts do recovery but then (if they care) they may:: > > initiators: > > reject any R2T that is unordered (i.e. do not recover) > accept R2T based on having "previously seen it" (as David Black suggests) > - with the caveat that if the R2T is lost you may have to fall back to 1 Considering ErrorRecoveryLevel>=1 and DataSequenceinOrder=Yes: The potentially lost R2T your referring to is the original one correct? Original meaning the R2T the initiator can use to determine if the R2T is infact a recovery R2T and is requesting retransmissing of an previously requested offset. If this is the case, I dont see how this situation could possibly happen. If the R2T the target originally sent gets lost and the initiator cannot send any data out without the lost R2T, how could the target possibly be able to generate a recovery r2t with differing offsets for a data out that was never received? So if this is indeed correct, the target generates a sequence timeout under the guise of within-command recovery, and sends a Recovery R2T with identical values to the one no data out was received for and presumed lost. And then if there is a Data Digest failure on data out the target generates a recovery R2T with a previously requested offset, and the initiator is able to tell the difference in R2Ts. I think this is a bit confusing (to me anyways) as a recovery R2T can either mean: a) A identical retransmission due to a header digest error (no data out received, manifests as a sequence timeout) b) Previously requested offset requested due to a data digest error. Is there something I am missing as to how the initiator with DataSequenceinOrder=Yes could lose an original R2T and still somehow receive a Recovery R2T (of type b) and have within-command recovery fail? Thanks Julian! Nicholas Bellinger - Pyxtechnologies.com > targets: > have only one R2T outstanding if you have both "in order" and error > recovery (a rare thing we believe) > > > Regards, > Julo > > > > > Black_David@emc.com > Sent by: owner-ips@ece.cmu.edu > 16/09/02 04:58 > > > To: nickb@attheoffice.org > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > One additional important note - the Recovery R2T generates > its own data sequence, so in the following: > > > > Following a) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > > DataLength=8192 > > > > > > Following B) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > The DataSN's should be 0 and 1, not 2 and 3 (and in the B) case above, > the F bit needs to be set, as I previously noted). The initiator really > does respond to a Recovery R2T in the same fashion as any other R2T. > > Thanks, > --David > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Sunday, September 15, 2002 9:45 PM > > To: nickb@attheoffice.org > > Cc: ips@ece.cmu.edu > > Subject: RE: iSCSI: Recognizing Recovery R2Ts > > > > > > > Im still lost here. Please consider the example: > > > > > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No, > > > InitialR2T=Yes. > > > > > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 > > > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0 > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, > > DataLength=8192 > > > > > > (Data Payload Fails on DataSN=2) > > > > > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error > > > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3, > > > DataLength=8192 > > > > > > Can the Target either: (Are both of these legal?) > > > > > > a) Accept DataSN=3 even though DataSN=2 Failed > > > Only request retransmisson of Failed DataOut > > > T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384 > > > > > > or b) Discard DataSN=3, Request retransmission of > > > all DataOut from failed to MaxBurstLength > > > T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384 > > > > Yes, both are legal, a) is preferred for obvious reasons. > > > > > Initiator: (This is where im confused) > > > Received either a) or b), and knows the R2T is a > Recovery > > > R2T because the DDTL is not 32768 (MaxBurstLength or rest > of > > > the original EDTL) and Offset is not 32768. > > > > Not exactly. The R2T is a recovery R2T because it requests data > > covered by the previous R2T (Offset < 32768). This doesn't affect > > the initiator's behavior - it just responds to the R2T it receives. > > > > > Following a) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3, > > > DataLength=8192 > > > > > > Following B) > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192 > > > > I think you flipped the a) and b) cases above, so you clearly are > > confused :-). In both cases, the initiator looks at the R2T to > > determine what data the Target is asking for and sends it - a) asked > > for 8k, b) asked for 16k. The one PDU that responds to a) needs > > to have the F bit set, as it completes the response to the second > > R2T. If the target needs to distinguish the recovery data transfer > > from the original transfer, it should use a different Target Transfer > > Tag in the recovery R2T. > > > > > Target: > > > MaxBurstLength is Completed: > > > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768 > > > > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, > > DataLength=8192 > > > > Ok. > > > > > Your statement "Whether the initiator knows this depends on > > whether it > > > saw the previous R2T" is still confusing to me. The logic > > used in the > > > above example (EDTL and Offset) I assume is incorrect. > > Would you mind > > > elaborating with a specific example of the proper method of > > doing so? > > > > I don't understand the problem here. In all cases, the initiator > > looks at the offset and length in the R2T it receives and sends the > > data requested by that R2T. In both cases a) and b) above, > > the initiator > > can tell that it's a recovery R2T because the requested data > > range overlaps > > a previous R2T. The statement I wrote covers a completely different > > case in which the target sends an R2T that doesn't arrive > > (e.g., header > > digest error), and decides to try to recover from that. > > > > I also don't understand the reference to EDTL in the command > > (as opposed to DDTL in the R2T0. If a Recovery R2T causes > > more than EDTL of data to be transferred for a command that's fine - > > the target is in charge of data flow and will tell the initiator when > > the command was complete and how much was actually transferred > > (consider unexpected end-of-tape on a tape device to understand > > why this is done this way). > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > --=_alternative 003B397BC2256C36_= Content-Type: text/html; charset="us-ascii"
Nick,

In case you have ErrorRecoveryLevel >=1 and DataSequenceInOrder=Yes then then either:
  • the target has only one outstanding R2T (to avoid at all price an out-of-order R2T)
  • or the initiator can go by an out-of-order R2T if it is a data-offset it has "passed-over" (even if not touched). Please observe that an initiator is aware of the gap in the R2T sequence when an R2T is lost if the target has more than one R2T missing and the missing one is not the last. If the missing one is the last (or only) there will be no violation of ordering.

    Regards,
    Julo.
    The ordering rules require the offsets to be in non-decreasing order.


    Nick Bellinger <nickb@attheoffice.org>

    16/09/02 09:18

    		       
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        Black_David@emc.com, ips@ece.cmu.edu, cbm@rose.hp.com
            Subject:        RE: iSCSI: Recognizing Recovery R2Ts

           


    Julian,

    On Sun, 2002-09-15 at 23:50, Julian Satran wrote:
    > Nick,
    >
    > I understand that your issue is mainly related to an initiator expecting
    > "in order" R2Ts and seing an R2T that is out of order.
    >
    > The simplest answer (and the one that we had in mind when we designed the
    > protocol) is that in general nodes willing to accept ErrorRecoveryLevels 1
    > and 2 will probably accept R2Ts out of order. In this case an initiator
    > does not need to make any distinction.
    >
    > But not wanting to be that restrictive we let even nodes accepting only
    > ordered R2Ts do recovery but then (if they care) they may::
    >
    > initiators:
    >
    > reject any R2T that is unordered (i.e. do not recover)
    > accept R2T based on having "previously seen it"  (as David Black suggests)
    > - with the caveat that if the R2T is lost you may have to fall back to  1

    Considering ErrorRecoveryLevel>=1 and DataSequenceinOrder=Yes:

    The potentially lost R2T your referring to is the original one correct?
    Original meaning the R2T the initiator can use to determine if the R2T
    is infact a recovery R2T and is requesting retransmissing of an
    previously requested offset.  

    If this is the case,  I dont see how this situation could possibly
    happen.  If the R2T the target originally sent gets lost and the
    initiator cannot send any data out without the lost R2T,  how could the
    target possibly be able to generate a recovery r2t with differing
    offsets for a data out that was never received?  

    So if this is indeed correct,  the target generates a sequence timeout
    under the guise of within-command recovery,  and sends a Recovery R2T
    with identical values to the one no data out was received for and
    presumed lost. And then if there is a Data Digest failure on data out
    the target generates a recovery R2T with a previously requested offset,
    and the initiator is able to tell the difference in R2Ts.  

    I think this is a bit confusing (to me anyways) as a recovery R2T can
    either mean:
                    a) A identical retransmission due to a header digest error (no                     data
    out received, manifests as a sequence timeout)
                    b) Previously requested offset requested due to a data digest                    
    error.
         
    Is there something I am missing as to how the initiator with
    DataSequenceinOrder=Yes could lose an original R2T and still somehow
    receive a Recovery R2T (of type b) and have within-command recovery
    fail?

    Thanks Julian!

                    Nicholas Bellinger - Pyxtechnologies.com

    > targets:
    > have only one R2T outstanding if you have both "in order" and error
    > recovery (a rare thing we believe)
    >
    >
    > Regards,
    > Julo
    >
    >
    >
    >
    > Black_David@emc.com
    > Sent by: owner-ips@ece.cmu.edu
    > 16/09/02 04:58
    >
    >  
    >         To:     nickb@attheoffice.org
    >         cc:     ips@ece.cmu.edu
    >         Subject:        RE: iSCSI: Recognizing Recovery R2Ts
    >
    >  
    >
    > One additional important note - the Recovery R2T generates
    > its own data sequence, so in the following:
    >
    > > > Following a)
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3,
    > > > DataLength=8192
    > > >
    > > > Following B)
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
    >
    > The DataSN's should be 0 and 1, not 2 and 3 (and in the B) case above,
    > the F bit needs to be set, as I previously noted).  The initiator really
    > does respond to a Recovery R2T in the same fashion as any other R2T.
    >
    > Thanks,
    > --David
    >
    > > -----Original Message-----
    > > From: Black_David@emc.com [mailto:Black_David@emc.com]
    > > Sent: Sunday, September 15, 2002 9:45 PM
    > > To: nickb@attheoffice.org
    > > Cc: ips@ece.cmu.edu
    > > Subject: RE: iSCSI: Recognizing Recovery R2Ts
    > >
    > >
    > > > Im still lost here.  Please consider the example:
    > > >
    > > > MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No,
    > > > InitialR2T=Yes.
    > > >
    > > > I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10
    > > > T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2,
    > > DataLength=8192
    > > >
    > > > (Data Payload Fails on DataSN=2)
    > > >
    > > > T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3,
    > > > DataLength=8192
    > > >
    > > > Can the Target either: (Are both of these legal?)
    > > >
    > > >              a) Accept DataSN=3 even though DataSN=2 Failed
    > > >                 Only request retransmisson of Failed DataOut
    > > >              T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384
    > > >
    > > >              or b) Discard DataSN=3, Request retransmission of
    > > >                    all DataOut from failed to MaxBurstLength
    > > >              T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384
    > >
    > > Yes, both are legal, a) is preferred for obvious reasons.
    > >
    > > > Initiator: (This is where im confused)
    > > >              Received either a) or b),  and knows the R2T is a
    > Recovery
    > > >              R2T because the DDTL is not 32768 (MaxBurstLength or rest
    > of
    > > >              the original EDTL) and Offset is not 32768.
    > >
    > > Not exactly.  The R2T is a recovery R2T because it requests data
    > > covered by the previous R2T (Offset < 32768).  This doesn't affect
    > > the initiator's behavior - it just responds to the R2T it receives.
    > >
    > > > Following a)
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3,
    > > > DataLength=8192
    > > >
    > > > Following B)
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
    > >
    > > I think you flipped the a) and b) cases above, so you clearly are
    > > confused :-).  In both cases, the initiator looks at the R2T to
    > > determine what data the Target is asking for and sends it - a) asked
    > > for 8k, b) asked for 16k.  The one PDU that responds to a) needs
    > > to have the F bit set, as it completes the response to the second
    > > R2T.  If the target needs to distinguish the recovery data transfer
    > > from the original transfer, it should use a different Target Transfer
    > > Tag in the recovery R2T.
    > >
    > > > Target:
    > > >              MaxBurstLength is Completed:
    > > > T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768
    > > >
    > > > I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0,
    > > DataLength=8192
    > >
    > > Ok.
    > >
    > > > Your statement "Whether the initiator knows this depends on
    > > whether it
    > > > saw the previous R2T" is still confusing to me.  The logic
    > > used in the
    > > > above example (EDTL and Offset) I assume is incorrect.
    > > Would you mind
    > > > elaborating with a specific example of the proper method of
    > > doing so?
    > >
    > > I don't understand the problem here.  In all cases, the initiator
    > > looks at the offset and length in the R2T it receives and sends the
    > > data requested by that R2T.  In both cases a) and b) above,
    > > the initiator
    > > can tell that it's a recovery R2T because the requested data
    > > range overlaps
    > > a previous R2T.  The statement I wrote covers a completely different
    > > case in which the target sends an R2T that doesn't arrive
    > > (e.g., header
    > > digest error), and decides to try to recover from that.
    > >
    > > I also don't understand the reference to EDTL in the command
    > > (as opposed to DDTL in the R2T0.  If a Recovery R2T causes
    > > more than EDTL of data to be transferred for a command that's fine -
    > > the target is in charge of data flow and will tell the initiator when
    > > the command was complete and how much was actually transferred
    > > (consider unexpected end-of-tape on a tape device to understand
    > > why this is done this way).
    > >
    > > Thanks,
    > > --David
    > > ---------------------------------------------------
    > > David L. Black, Senior Technologist
    > > EMC Corporation, 42 South St., Hopkinton, MA  01748
    > > +1 (508) 249-6449            FAX: +1 (508) 497-8018
    > > black_david@emc.com       Mobile: +1 (978) 394-7754
    > > ---------------------------------------------------
    > >
    >
    >




--=_alternative 003B397BC2256C36_=-- From owner-ips@ece.cmu.edu Mon Sep 16 15:14:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14719 for ; Mon, 16 Sep 2002 15:14:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8GIZW519558 for ips-outgoing; Mon, 16 Sep 2002 14:35:32 -0400 (EDT) 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 g8GIZTo19548 for ; Mon, 16 Sep 2002 14:35:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8GIZH2j097448; Mon, 16 Sep 2002 20:35:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8GIZHpI014272; Mon, 16 Sep 2002 20:35:17 +0200 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI version 16 draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 16 Sep 2002 21:35:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/09/2002 21:35:17, Serialize complete at 16/09/2002 21:35:17 Content-Type: multipart/alternative; boundary="=_alternative 0064C5E9C2256C36_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0064C5E9C2256C36_= Content-Type: text/plain; charset="us-ascii" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-17.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-17.pdf This version completely replaces: draft-ietf-ips-iscsi-16.txt and pdf The only changes from x-16 are several minor typos (marked in the pdf version). Julian Satran - IBM Research Laboratory at Haifa --=_alternative 0064C5E9C2256C36_= Content-Type: text/html; charset="us-ascii"


On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-17.txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-17.pdf


This version completely replaces:

draft-ietf-ips-iscsi-16.txt and pdf



The only changes from  x-16 are several minor typos (marked in the pdf version).

Julian Satran - IBM Research Laboratory at Haifa

































--=_alternative 0064C5E9C2256C36_=-- From owner-ips@ece.cmu.edu Mon Sep 16 19:06:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19699 for ; Mon, 16 Sep 2002 19:06:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8GMOiv04219 for ips-outgoing; Mon, 16 Sep 2002 18:24:44 -0400 (EDT) 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 [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8GMOgo04213 for ; Mon, 16 Sep 2002 18:24:42 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel7.hp.com (Postfix) with ESMTP id C785180569C; Mon, 16 Sep 2002 18:24:37 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id PAA22393; Mon, 16 Sep 2002 15:24:37 -0700 (PDT) Message-ID: <00e901c25dcf$d69249c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Nick Bellinger" Cc: References: <1032170766.32734.161.camel@subjeKt> Subject: Re: iSCSI: Recognizing Recovery R2Ts Date: Mon, 16 Sep 2002 15:24:35 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nick, > Ok, just to few more points to verify with regard to a lost R2T due to > a Header Digest error: > > In the case of ErrorRecoveryLevel=>1, DataSequenceinOrder=No and > MaxOutStandingR2T=>1: > > Initiator is able to ascertain a lost R2T by receiving an > R2TSN greater than expected, and sends a SNACK of type R2T > to request retransmission of the lost R2T. Target retransmits R2T with > identical values as the lost R2T. Yes, it's the most likely scenario even though the initiator may simply choose to leave it up to the target to generate a recovery R2T (initiator meanwhile may continue to work on the following R2Ts, if any) even in this case. > > In the case of ErrorRecoveryLevel=>1, DataSequenceinOrder=Yes and > MaxOutStandingR2T=1: > > Target will timeout waiting for Data OUT from the lost R2T > and sends a Recovery R2T with identical values of the lost R2T. With the next higher R2TSN (recovery R2T uses a new sequence number). Again, this is the most likely scenario. There's an outside chance that an initiator may choose to generate a proactive R2T SNACK based on aggressive timeouts (even though the spec cautions that sequence timeout- driven R2Ts "SHOULD NOT" be used, section 5.1.4.1). Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Tue Sep 17 03:50:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06819 for ; Tue, 17 Sep 2002 03:50:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8H6tFi27828 for ips-outgoing; Tue, 17 Sep 2002 02:55:15 -0400 (EDT) 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 g8H6tDo27823; Tue, 17 Sep 2002 02:55:13 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8H6t6b0020298; Tue, 17 Sep 2002 08:55:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8H6t5QT013406; Tue, 17 Sep 2002 08:55:05 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: "Ips Reflector (E-mail)" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI:Typo in draft 16? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 17 Sep 2002 09:55:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/09/2002 09:55:05, Serialize complete at 17/09/2002 09:55:05 Content-Type: multipart/alternative; boundary="=_alternative 00250BD4C2256C37_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00250BD4C2256C37_= Content-Type: text/plain; charset="us-ascii" Marjorie - except for formatting they are in 17. Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 11/09/02 21:03 To: "Ips Reflector (E-mail)" cc: Subject: iSCSI:Typo in draft 16? -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, September 10, 2002 11:38 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Black_David@emc.com; Elizabeth.G.Rodriguez@123mail.net; John Hufferd Subject: RE: iSCSI:Typo in draft 16 Thanks - Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" 11/09/02 01:23 To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI:Typo in draft 16 Oop, forgot to add: Is the pagination off? The first page break seems to come too early, but maybe that's deliberate. The indentation got messed up between page 38 and page 39 - the 3rd, 4th 5th bullets have different indentation from the first two bullets. Hi Julian Assuming that you make changes due to IETF last call, can you correct this item? I think there's a typo in sec. 2.2.6.3.1 "Type "iqn." (iSCSI Qualified Name)" The 5th bullet items says "An optional colon (:), or prefixed string within the character set and ^^^^^ length boundaries that the owner of the domain name deems appropriate. " I think the ", or" is a typo? If the string is present, it must be prefixed by a ":" The current wording leave the impression that the ":" is optional. Regards, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard --=_alternative 00250BD4C2256C37_= Content-Type: text/html; charset="us-ascii"
Marjorie - except for formatting they are in 17.  Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

11/09/02 21:03

       
        To:        "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI:Typo in draft 16?

       


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, September 10, 2002 11:38 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Black_David@emc.com; Elizabeth.G.Rodriguez@123mail.net; John Hufferd
Subject: RE: iSCSI:Typo in draft 16

Thanks - Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

11/09/02 01:23

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        
       Subject:        RE: iSCSI:Typo in draft 16

     



Oop, forgot to add:
Is the pagination off?  The first page break seems to come too early, but maybe that's deliberate.
 
The indentation got messed up between page 38 and page 39 - the 3rd, 4th 5th bullets have different indentation from the first two bullets.  

Hi Julian

Assuming that you make changes due to IETF last call, can you correct this item?  I think there's a typo in sec. 2.2.6.3.1  "Type "iqn." (iSCSI Qualified Name)"

 The 5th bullet items says

"An optional colon (:), or prefixed string within the character set and
                     ^^^^^
length boundaries that the owner of the domain name deems appropriate. "
 
I think the ", or" is a typo?  If the string is present, it must be prefixed by a ":"  The current wording leave the impression that the ":" is optional.

Regards,
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions
Hewlett-Packard

--=_alternative 00250BD4C2256C37_=-- From owner-ips@ece.cmu.edu Tue Sep 17 10:25:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16675 for ; Tue, 17 Sep 2002 10:25:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8HDmsO28850 for ips-outgoing; Tue, 17 Sep 2002 09:48:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8HC2Ao23453 for ; Tue, 17 Sep 2002 08:02:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11251; Tue, 17 Sep 2002 08:00:09 -0400 (EDT) Message-Id: <200209171200.IAA11251@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-17.txt,.pdf Date: Tue, 17 Sep 2002 08:00:09 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-17.txt,.pdf Pages : 285 Date : 2002-9-16 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-16151952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-16151952.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Sep 17 10:25:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16694 for ; Tue, 17 Sep 2002 10:25:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8HDn1o28861 for ips-outgoing; Tue, 17 Sep 2002 09:49:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8HC2Ao23453 for ; Tue, 17 Sep 2002 08:02:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11251; Tue, 17 Sep 2002 08:00:09 -0400 (EDT) Message-Id: <200209171200.IAA11251@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-17.txt,.pdf Date: Tue, 17 Sep 2002 08:00:09 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-17.txt,.pdf Pages : 285 Date : 2002-9-16 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-16151952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-16151952.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Sep 17 10:27:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16735 for ; Tue, 17 Sep 2002 10:27:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8HDn8028871 for ips-outgoing; Tue, 17 Sep 2002 09:49:08 -0400 (EDT) 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 g8HCSmo24456 for ; Tue, 17 Sep 2002 08:28:48 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8HCSgvG011200 for ; Tue, 17 Sep 2002 14:28:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8HCSfQT049434 for ; Tue, 17 Sep 2002 14:28:41 +0200 Subject: iSCSI boot - DHCP Root Path Option To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Eliot Salant" Date: Tue, 17 Sep 2002 15:27:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/09/2002 15:28:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Can the DHCP Root Path Option be extendible with vendor specified options? For example, specifying what operating system or version of an O/S resides on a given target and LUN will allow the boot client to decide which target to boot from. =================================== Eliot Salant IBM Haifa Research Labs Haifa University, Mt. Carmel, Haifa, Israel 31905 Tel. +972-48296-121 FAX: +972-48550-070 ==================================== From owner-ips@ece.cmu.edu Tue Sep 17 18:09:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02237 for ; Tue, 17 Sep 2002 18:09:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8HLTxb01028 for ips-outgoing; Tue, 17 Sep 2002 17:29:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8HLTvo01023 for ; Tue, 17 Sep 2002 17:29:57 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 17:29:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C2F1@CORPMX14> From: Black_David@emc.com To: SALANT@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI boot - DHCP Root Path Option Date: Tue, 17 Sep 2002 17:29:47 -0400 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 > Can the DHCP Root Path Option be extendible with vendor > specified options? *NO*, root path should be limited to the format given - vendor- specific extensions *will* create interoperability problems. Find some other DHCP option(s) to convey additional info. If you need more functionality than appears to be available, write an Internet-Draft on what you need and how you propose to do it based on currently-available DHCP options. > For example, specifying what operating > system or version of an O/S resides on a given target and LUN > will allow the boot client to decide which target to boot from. Seems like a less than wonderful place to put this functionality. Have you considered the alternative of having the DHCP server decide what to return based on who is issuing the request, or having the boot client include additional information in its request if the MAC address doesn't provide enough information for the DHCP server to figure out what to return? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Sep 18 00:04:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08292 for ; Wed, 18 Sep 2002 00:04:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8I3Dvo18013 for ips-outgoing; Tue, 17 Sep 2002 23:13:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f109.pav2.hotmail.com [64.4.37.109]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8I3Dso18006 for ; Tue, 17 Sep 2002 23:13:54 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Sep 2002 20:13:48 -0700 Received: from 131.107.3.70 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 18 Sep 2002 03:13:47 GMT X-Originating-IP: [131.107.3.70] From: "Bernard Aboba" To: ips@ece.cmu.edu Subject: IPS Security Draft 16 Date: Tue, 17 Sep 2002 20:13:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Sep 2002 03:13:48.0205 (UTC) FILETIME=[67BEC5D0:01C25EC1] Sender: owner-ips@ece.cmu.edu Precedence: bulk A strawman version of the -16 IPS security draft is available for inspection: http://www.drizzle.com/~aboba/IPS/draft-ietf-ips-security-16.txt Comments welcome. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ips@ece.cmu.edu Wed Sep 18 15:35:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27408 for ; Wed, 18 Sep 2002 15:35:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8IIsi013479 for ips-outgoing; Wed, 18 Sep 2002 14:54:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from almaden.ibm.com (p1.almaden.ibm.com [198.4.83.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8IIsgo13474 for ; Wed, 18 Sep 2002 14:54:42 -0400 (EDT) Received: from ibmjh9qh9xf2ft (ibm-jh9qh9xf2ft.almaden.ibm.com [9.1.23.22]) by almaden.ibm.com (AIX4.3/8.9.3/8.9.3) with SMTP id LAA62672 for ; Wed, 18 Sep 2002 11:54:36 -0700 Message-ID: <001201c25f44$b484eba0$16170109@almaden.ibm.com> From: "Prasenjit Sarkar" To: Subject: iSCSI Boot: LUN Technical Issue Date: Wed, 18 Sep 2002 11:53:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C25F0A.074884E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C25F0A.074884E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a status on the technical issue regarding representation of LUN = values in the iSCSI boot DHCP string. The arguments supporting the representation of a 16-bit LUN value is = primarily HCI. (It should be noted that HCI issues are particularly = difficult to resolve). The arguments against the representation of such a value is (a) use of = the default LUN simplifies HCI issues in most cases, and (b) LUN = equivalence between the DHCP string and iSCSI PDUs is a simpler and = desirable paradigm. I have not heard any new arguments in the past few days, I will let the = chairs declare a timeout. Prasenjit ------=_NextPart_000_000F_01C25F0A.074884E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Here is a status on the technical issue = regarding=20 representation of LUN values in the iSCSI boot DHCP string.
 
The arguments supporting the = representation of a=20 16-bit LUN value is primarily HCI. (It should be noted that HCI issues = are=20 particularly difficult to resolve).
 
The arguments against the = representation of such a=20 value is (a) use of the default LUN simplifies HCI issues in most cases, = and (b)=20 LUN equivalence between the DHCP string and iSCSI PDUs is a simpler and=20 desirable paradigm.
 
I have not heard any new arguments in = the past few=20 days, I will let the chairs declare a timeout.
 
Prasenjit
------=_NextPart_000_000F_01C25F0A.074884E0-- From owner-ips@ece.cmu.edu Wed Sep 18 15:36:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27458 for ; Wed, 18 Sep 2002 15:36:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8IJ1Fc13916 for ips-outgoing; Wed, 18 Sep 2002 15:01:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8IJ1Bo13909 for ; Wed, 18 Sep 2002 15:01:12 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8IJ131X007007; Wed, 18 Sep 2002 12:01:03 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8IJ114X021872; Wed, 18 Sep 2002 12:01:01 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA27607; Wed, 18 Sep 2002 12:01:00 -0700 (PDT) Message-ID: <3D88CD6C.9918C4B5@cisco.com> Date: Wed, 18 Sep 2002 14:01:00 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Prasenjit Sarkar CC: ips@ece.cmu.edu Subject: Re: iSCSI Boot: LUN Technical Issue References: <001201c25f44$b484eba0$16170109@almaden.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Prasenjit- What does HCI stand for? > Prasenjit Sarkar wrote: > > Here is a status on the technical issue regarding representation of LUN values in the iSCSI boot > DHCP string. > > The arguments supporting the representation of a 16-bit LUN value is primarily HCI. (It should be > noted that HCI issues are particularly difficult to resolve). > > The arguments against the representation of such a value is (a) use of the default LUN simplifies > HCI issues in most cases, and (b) LUN equivalence between the DHCP string and iSCSI PDUs is a > simpler and desirable paradigm. > > I have not heard any new arguments in the past few days, I will let the chairs declare a timeout. > > Prasenjit -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 18 16:15:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28617 for ; Wed, 18 Sep 2002 16:15:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8IJhXX16629 for ips-outgoing; Wed, 18 Sep 2002 15:43:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8IJhUo16625 for ; Wed, 18 Sep 2002 15:43:30 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 15:43:20 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C304@CORPMX14> From: Black_David@emc.com To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Boot: LUN Technical Issue Date: Wed, 18 Sep 2002 15:42:53 -0400 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 Human-Computer Interface. --David > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Wednesday, September 18, 2002 3:01 PM > To: Prasenjit Sarkar > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI Boot: LUN Technical Issue > > > Prasenjit- > > What does HCI stand for? > > > Prasenjit Sarkar wrote: > > > > Here is a status on the technical issue regarding > representation of LUN values in the iSCSI boot > > DHCP string. > > > > The arguments supporting the representation of a 16-bit LUN > value is primarily HCI. (It should be > > noted that HCI issues are particularly difficult to resolve). > > > > The arguments against the representation of such a value is > (a) use of the default LUN simplifies > > HCI issues in most cases, and (b) LUN equivalence between > the DHCP string and iSCSI PDUs is a > > simpler and desirable paradigm. > > > > I have not heard any new arguments in the past few days, I > will let the chairs declare a timeout. > > > > Prasenjit > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Sep 18 16:22:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28840 for ; Wed, 18 Sep 2002 16:22:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8IJlOf16897 for ips-outgoing; Wed, 18 Sep 2002 15:47:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12804.mail.yahoo.com (web12804.mail.yahoo.com [216.136.174.39]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g8IJlLo16892 for ; Wed, 18 Sep 2002 15:47:21 -0400 (EDT) Message-ID: <20020918194720.60682.qmail@web12804.mail.yahoo.com> Received: from [209.47.35.250] by web12804.mail.yahoo.com via HTTP; Wed, 18 Sep 2002 12:47:20 PDT Date: Wed, 18 Sep 2002 12:47:20 -0700 (PDT) From: Luben Tuikov Subject: Re: iSCSI Boot: LUN Technical Issue To: Mark Bakke , Prasenjit Sarkar Cc: ips@ece.cmu.edu In-Reply-To: <3D88CD6C.9918C4B5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Mark Bakke wrote: > Prasenjit- > > What does HCI stand for? > Human Computer Interaction -- see my message on the thread ``Re: iSCSI Boot Last Call - Technical Comments'' dating Thu, 12 Sep 2002 16:05:41 -0400. It is a somewhat newer field in computer science encompassing several various disciplines (psychology, etc). It has existed before but never formally. Now one can actually specialise in HCI in a university CS program. ... -- Luben P.S. I can name a number of companies who _desperately_ need ppl specialised in HCI... but alas... ===== -- __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-ips@ece.cmu.edu Wed Sep 18 16:22:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28861 for ; Wed, 18 Sep 2002 16:22:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8IKEng18745 for ips-outgoing; Wed, 18 Sep 2002 16:14:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8IKEmo18741 for ; Wed, 18 Sep 2002 16:14:48 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8IKEfW4028170; Wed, 18 Sep 2002 13:14:41 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8IKEe3x018541; Wed, 18 Sep 2002 13:14:40 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA20272; Wed, 18 Sep 2002 13:14:38 -0700 (PDT) Message-ID: <3D88DEAF.5A7E25B2@cisco.com> Date: Wed, 18 Sep 2002 15:14:39 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Prasenjit Sarkar CC: ips@ece.cmu.edu Subject: Re: iSCSI Boot: LUN Technical Issue References: <001201c25f44$b484eba0$16170109@almaden.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Prasenjit- OK, now I know what you meant (Thanks, David and Luben). > Prasenjit Sarkar wrote: > > Here is a status on the technical issue regarding representation of LUN values > in the iSCSI boot DHCP string. > > The arguments supporting the representation of a 16-bit LUN value is > primarily HCI. (It should be noted that HCI issues are particularly > difficult to resolve). So if HCI issues are difficult, why not take a small step by allowing the user to do the simplest thing most of the time? I don't think that anyone will be modifying their DHCP servers to do this for us. > The arguments against the representation of such a value is > (a) use of the default LUN simplifies HCI issues in most cases, and > (b) LUN equivalence between the DHCP string and iSCSI PDUs is a > simpler and desirable paradigm. I still see no reason why the iSCSI PDU matters. Except for a few curious (or perhaps frustrated) people who end up watching their traffic with Ethereal (an excellent tool, BTW), no customer or end user is going to care about PDUs, or their formats. We have an iSCSI target with a good set of drivers that has been available for nearly two years, and there is no mention of the LUN data structure (beyond that LUNs are 16-bit numbers) in any of our documentation. And nobody's asked. From a standards point of view, this LUN structure exists, but from a practical point of view, use of more than a 16-bit LUN (and in most cases 8 bits) is quite rare. We are choosing between making life easier for the end user, and making our solution more elegant with respect to the standards. I'm on the end user's side. The frustrating thing is we just finished allowing the iSCSI negotiation sequence to use decimal numbers in addition to hex, thinking it might be easier for a user to look at or cut and paste (which I think will be rare), and now we are going to limit the LUN field in a DHCP option to a strict, difficult- to-type format, which will always be entered by a user. This seems backwards. Anyway, sorry for the rant, but I really want to see this be made as easy as possible on the user. > I have not heard any new arguments in the past few days, I will > let the chairs declare a timeout. > > Prasenjit -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 18 16:26:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28953 for ; Wed, 18 Sep 2002 16:26:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8IKBPI18552 for ips-outgoing; Wed, 18 Sep 2002 16:11:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8IKBMo18543 for ; Wed, 18 Sep 2002 16:11:22 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g8IKBGO26843 for ; Wed, 18 Sep 2002 13:11:16 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 13:11:17 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: iscsi: iSCSI Boot -- Informational or Standards track Date: Wed, 18 Sep 2002 13:11:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25F4F.8B397990" 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_01C25F4F.8B397990 Content-Type: text/plain; charset="iso-8859-1" [chair hat off] All When reviewing the Boot document last week, one think I overlooked was the fact that the boot draft is currently informational. In my editorial comments (to the authors only), I listed the fact that it was not written in the language of RFC 2119. It was pointed out that the draft is informational. I feel that it probably should be standards track. It lists minimum requirements for boot, parameters, as well as defaults for optional parameters, and formats for these fields. This appears to me to be content for a standards track document, not an informational one. Informational documents are of general interest/information, not necessarily representative of group consensus. This document seems to be one which is really trying to define parameters and behavior needed for iSCSI Boot, which means interoperability considerations -- that is a standards track type of document. What does the rest of the group think? Thanks, Elizabeth ------_=_NextPart_001_01C25F4F.8B397990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iscsi: iSCSI Boot -- Informational or Standards track

[chair hat off]

All

When reviewing the Boot document last = week, one think I overlooked was the fact that the boot draft is = currently informational.

In my editorial comments (to the = authors only), I listed the fact that it was not written in the = language of RFC 2119.
It was pointed out that the draft is = informational.  I feel that it probably should be standards = track.
It lists minimum requirements for = boot, parameters, as well as defaults for optional parameters, and = formats for these fields.

This appears to me to be content for a = standards track document, not an informational one.

Informational documents are of general = interest/information, not necessarily representative of group = consensus.
This document seems to be one which = is really trying to define parameters and behavior needed for iSCSI = Boot,
which means interoperability = considerations -- that is a standards track type of document.

What does the rest of the group = think?

Thanks,

Elizabeth

------_=_NextPart_001_01C25F4F.8B397990-- From owner-ips@ece.cmu.edu Wed Sep 18 20:48:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05450 for ; Wed, 18 Sep 2002 20:48:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8J0BmK02380 for ips-outgoing; Wed, 18 Sep 2002 20:11:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8J0Blo02376 for ; Wed, 18 Sep 2002 20:11:47 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8J0BcG03274 for ; Wed, 18 Sep 2002 20:11:38 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g8J0BD715168 for ; Wed, 18 Sep 2002 20:11:38 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 20:11:13 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C308@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: WG Last Call status Date: Wed, 18 Sep 2002 20:11:09 -0400 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 The IPS WG has a number of drafts that have recently undergone ips WG Last Call. Here's a summary of their current state - for some of these drafts, this is the announcement that they have completed WG Last Call. FC Encapsulation, iFCP, FCIP - At the IESG in the queue for evaluation by our Area Directors. See http://www.ietf.org/IESG/status.html iSCSI, IPS Security - Completed WG Last Call a while ago. What should be the last edits have been made resulting in iSCSI -17 (on the I-D servers) and IPS Security -16 (to be submitted shortly). Both will go to the ADs/IESG shortly. The change in the security draft from -15 to -16 was to add key values and IANA Considerations text for the SRP groups. Finding FCIP Entities using SLP - Successfully completed WG Last call with editorial comments only. An edited version incorporating those comments is expected in the near future and will be submitted to the ADs/IESG. Fibre Channel Management MIB - Completed WG Last Call with one open technical issue involving the possible functions of entities that support this MIB (FcUnitFunctions). This issue is believed to be resolved including coordination with the appropriate T11 document. The resolution will need to be posted to the list by the folks who came up with it, and then the next version of this MIB with this change and the changes from WG Last Call can be submitted to the ADs/IESG. iSCSI Naming and Discovery - Has completed WG Last Call. The one technical issue whose resolution was not reported to the list was the meaning of "optional" for the ":" in an iSCSI iqn-format name. The resolution is that the ":" must be present if anything follows the reversed domain name of the naming authority as specified in Section 2.2.6.3.1 of the iSCSI draft. A new version of the N&D draft incorporating this change and the rest of the Last Call changes is in preparation and will be submitted to the ADs/IESG when it's ready. iSCSI Boot - Has completed WG Last Call, but with two open issues - whether to allow a 16 bit LUN format and whether to make the draft standards track. These are both open for discussion on the list. Unless the resulting changes are extensive, a second WG Last Call will not be necessary. iFCP MIB - Currently in WG Last Call, which will end next Monday, September 23rd. By the way, the Sheinwald CRC draft (draft-sheinwald-iscsi-crc-02.txt) is in the RFC Editor's Queue for publication as an Informational RFC, and the iSCSI Requirements draft did eventually emerge as RFC 3347. More WG Last Calls will be coming soon - your WG co-chairs hope to move most of our drafts through WG Last Call and on to the ADs before the Atlanta meeting. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Sep 18 21:40:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06710 for ; Wed, 18 Sep 2002 21:40:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8J17pF05286 for ips-outgoing; Wed, 18 Sep 2002 21:07:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8J17no05279 for ; Wed, 18 Sep 2002 21:07:49 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 21:07:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C30D@CORPMX14> From: Black_David@emc.com To: erodrigu@Brocade.COM, ips@ece.cmu.edu Subject: RE: iscsi: iSCSI Boot -- Informational or Standards track Date: Wed, 18 Sep 2002 21:07:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25F78.F35603D0" 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_01C25F78.F35603D0 Content-Type: text/plain; charset="iso-8859-1" [WG chair hat on] Folks, Having just had to explain how/why fiddling with formats for the DHCP Root Path option could cause interoperability problems, I'm inclined to send have the boot draft go standards track in order to specify that when the "iscsi:" prefix is used for the DHCP Root Path option to support booting via iSCSI, then the format defined in the boot draft MUST be used. At the moment, I think use of RFC 2119 imperatives (e.g., MUST) would be limited to Section 4 of the boot draft where this format is defined, but I think the interoperability issue recently discussed on this list merits using those imperatives. Section 1 of the boot draft is about requirements on booting mechanisms for iSCSI and hence does not appear to warrant RFC 2119 imperatives. Comments? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Elizabeth Rodriguez [mailto:erodrigu@Brocade.COM] Sent: Wednesday, September 18, 2002 4:11 PM To: ips@ece.cmu.edu Subject: iscsi: iSCSI Boot -- Informational or Standards track [chair hat off] All When reviewing the Boot document last week, one think I overlooked was the fact that the boot draft is currently informational. In my editorial comments (to the authors only), I listed the fact that it was not written in the language of RFC 2119. It was pointed out that the draft is informational. I feel that it probably should be standards track. It lists minimum requirements for boot, parameters, as well as defaults for optional parameters, and formats for these fields. This appears to me to be content for a standards track document, not an informational one. Informational documents are of general interest/information, not necessarily representative of group consensus. This document seems to be one which is really trying to define parameters and behavior needed for iSCSI Boot, which means interoperability considerations -- that is a standards track type of document. What does the rest of the group think? Thanks, Elizabeth ------_=_NextPart_001_01C25F78.F35603D0 Content-Type: text/html; charset="iso-8859-1" iscsi: iSCSI Boot -- Informational or Standards track
[WG chair hat on]
 
Folks,
 
Having just had to explain how/why fiddling with formats for
the DHCP Root Path option could cause interoperability problems,
I'm inclined to send have the boot draft go standards track in
order to specify that when the "iscsi:" prefix is used for the
DHCP Root Path option to support booting via iSCSI, then the format
defined in the boot draft MUST be used.  At the moment, I think use
of RFC 2119 imperatives (e.g., MUST) would be limited to Section 4
of the boot draft where this format is defined, but I think the
interoperability issue recently discussed on this list merits
using those imperatives.  Section 1 of the boot draft is about
requirements on booting mechanisms for iSCSI and hence does
not appear to warrant RFC 2119 imperatives.
 
Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

-----Original Message-----
From: Elizabeth Rodriguez [mailto:erodrigu@Brocade.COM]
Sent: Wednesday, September 18, 2002 4:11 PM
To: ips@ece.cmu.edu
Subject: iscsi: iSCSI Boot -- Informational or Standards track

[chair hat off]

All

When reviewing the Boot document last week, one think I overlooked was the fact that the boot draft is currently informational.

In my editorial comments (to the authors only), I listed the fact that it was not written in the language of RFC 2119.
It was pointed out that the draft is informational.  I feel that it probably should be standards track.
It lists minimum requirements for boot, parameters, as well as defaults for optional parameters, and formats for these fields.

This appears to me to be content for a standards track document, not an informational one.

Informational documents are of general interest/information, not necessarily representative of group consensus.
This document seems to be one which is really trying to define parameters and behavior needed for iSCSI Boot,
which means interoperability considerations -- that is a standards track type of document.

What does the rest of the group think?

Thanks,

Elizabeth

------_=_NextPart_001_01C25F78.F35603D0-- From owner-ips@ece.cmu.edu Thu Sep 19 02:32:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21868 for ; Thu, 19 Sep 2002 02:32:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8J5uI017462 for ips-outgoing; Thu, 19 Sep 2002 01:56:18 -0400 (EDT) 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 g8J5uEo17455; Thu, 19 Sep 2002 01:56:14 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8J5u5A2017594; Thu, 19 Sep 2002 07:56:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8J5u4D1036374; Thu, 19 Sep 2002 07:56:04 +0200 To: Elizabeth Rodriguez Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Eliot Salant" MIME-Version: 1.0 Subject: Re: iscsi: iSCSI Boot -- Informational or Standards track X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 19 Sep 2002 08:56:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/09/2002 08:56:04, Serialize complete at 19/09/2002 08:56:04 Content-Type: multipart/alternative; boundary="=_alternative 00204C3CC2256C39_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00204C3CC2256C39_= Content-Type: text/plain; charset="us-ascii" Elizabeth, I tend to agree. If it stays informational we will end up with a myriad of vendor specific ways of registering boot data in DHCP for iSCSI. An item that is not quoted as open (perhaps it went in too late for the last call) was a request to format in a "generally accepted way" information about the boot target (e.g., what OS image does it carry?). Regards, Julo Elizabeth Rodriguez Sent by: owner-ips@ece.cmu.edu 18/09/02 23:11 To: ips@ece.cmu.edu cc: Subject: iscsi: iSCSI Boot -- Informational or Standards track [chair hat off] All When reviewing the Boot document last week, one think I overlooked was the fact that the boot draft is currently informational. In my editorial comments (to the authors only), I listed the fact that it was not written in the language of RFC 2119. It was pointed out that the draft is informational. I feel that it probably should be standards track. It lists minimum requirements for boot, parameters, as well as defaults for optional parameters, and formats for these fields. This appears to me to be content for a standards track document, not an informational one. Informational documents are of general interest/information, not necessarily representative of group consensus. This document seems to be one which is really trying to define parameters and behavior needed for iSCSI Boot, which means interoperability considerations -- that is a standards track type of document. What does the rest of the group think? Thanks, Elizabeth --=_alternative 00204C3CC2256C39_= Content-Type: text/html; charset="us-ascii"
Elizabeth,

I tend to agree. If it stays informational we will end up with a myriad of vendor specific ways of registering boot
data in DHCP for iSCSI.  An item that is not quoted as open  (perhaps it went in too late for the last call) was a request to format in a "generally accepted way"
information about the boot target (e.g., what OS image does it carry?).

Regards,
Julo


Elizabeth Rodriguez <erodrigu@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu

18/09/02 23:11

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: iSCSI Boot -- Informational or Standards track

       


[chair hat off]

All

When reviewing the Boot document last week, one think I overlooked was the fact that the boot draft is currently informational.

In my editorial comments (to the authors only), I listed the fact that it was not written in the language of RFC 2119.
It was pointed out that the draft is informational.  I feel that it probably should be standards track.
It lists minimum requirements for boot, parameters, as well as defaults for optional parameters, and formats for these fields.

This appears to me to be content for a standards track document, not an informational one.

Informational documents are of general interest/information, not necessarily representative of group consensus.
This document seems to be one which is really trying to define parameters and behavior needed for iSCSI Boot,
which means interoperability considerations -- that is a standards track type of document.

What does the rest of the group think?

Thanks,

Elizabeth

--=_alternative 00204C3CC2256C39_=-- From owner-ips@ece.cmu.edu Thu Sep 19 12:19:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12691 for ; Thu, 19 Sep 2002 12:19:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8JFeFP24323 for ips-outgoing; Thu, 19 Sep 2002 11:40:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8JFeCo24312 for ; Thu, 19 Sep 2002 11:40:12 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Sep 2002 11:40:01 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C312@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, SALANT@il.ibm.com Subject: RE: iscsi: iSCSI Boot -- Informational or Standards track Date: Thu, 19 Sep 2002 11:39:58 -0400 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 > An item that is not quoted as open (perhaps it went in too late > for the last call) was a request to format in a "generally accepted way" > information about the boot target (e.g., what OS image does it carry?). The specific request was to modify the iscsi DHCP Root Path option format to carry that information, and the response to that request is a firm "NO"; as a result the item is not open. I have privately advised the originator of the request to find a more general way to do this via other DHCP options (preferably existing ones, but new ones if necessary), which will have the added benefit of providing this functionality for network boot mechanisms other than iSCSI. That should be written up in a separate Internet-Draft, probably for the dhc WG rather than the ips WG. That draft could reference the iSCSI boot draft, but as a mechanism of wider applicability, I believe it's inappropriate to add this material to the iSCSI boot draft. Comments? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Sep 19 12:27:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12955 for ; Thu, 19 Sep 2002 12:27:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8JFwex25709 for ips-outgoing; Thu, 19 Sep 2002 11:58:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8JFwco25703 for ; Thu, 19 Sep 2002 11:58:38 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D22453070C; Thu, 19 Sep 2002 11:58:37 -0400 (EDT) Date: Thu, 19 Sep 2002 08:58:34 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: iscsi: iSCSI Boot -- Informational or Standards track In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C30D@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 18 Sep 2002 Black_David@emc.com wrote: > [WG chair hat on] > > Folks, > > Having just had to explain how/why fiddling with formats for > the DHCP Root Path option could cause interoperability problems, > I'm inclined to send have the boot draft go standards track in > order to specify that when the "iscsi:" prefix is used for the > DHCP Root Path option to support booting via iSCSI, then the format > defined in the boot draft MUST be used. At the moment, I think use > of RFC 2119 imperatives (e.g., MUST) would be limited to Section 4 > of the boot draft where this format is defined, but I think the > interoperability issue recently discussed on this list merits > using those imperatives. Section 1 of the boot draft is about > requirements on booting mechanisms for iSCSI and hence does > not appear to warrant RFC 2119 imperatives. Sounds appropriate. Take care, Bill From owner-ips@ece.cmu.edu Thu Sep 19 15:23:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19650 for ; Thu, 19 Sep 2002 15:23:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8JIhFb06716 for ips-outgoing; Thu, 19 Sep 2002 14:43:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mangelwurzel.iol.unh.edu (d124070.iol.unh.edu [132.177.124.70]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8JIhEo06712 for ; Thu, 19 Sep 2002 14:43:14 -0400 (EDT) Received: from iol.unh.edu (localhost.localdomain [127.0.0.1]) by mangelwurzel.iol.unh.edu (8.11.6/8.11.6) with ESMTP id g8JIgJ702973 for ; Thu, 19 Sep 2002 14:42:20 -0400 Message-ID: <3D8A1A8B.1030006@iol.unh.edu> Date: Thu, 19 Sep 2002 14:42:19 -0400 From: Stephen Schaeffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Looking for vendors of 'odd' SCSI devices Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, The Interoperability Lab is looking for vendors of devices like scanners or cd-rom or such so we can capture new SCSI commands and broaden the scope of our tools. Please respond directly to me if your company manufactures something that we could use. Thanks -- Stephen Schaeffer Fibre Channel and iSCSI Consortia Manager InterOperability Lab, University of New Hampshire Email: stephens@iol.unh.edu Phone: 603-862-5083 Lab Phone: 603-862-0701 URL: www.iol.unh.edu From owner-ips@ece.cmu.edu Fri Sep 20 01:50:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04508 for ; Fri, 20 Sep 2002 01:50:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8K5Ama11844 for ips-outgoing; Fri, 20 Sep 2002 01:10:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8K5Alo11840 for ; Fri, 20 Sep 2002 01:10:47 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8K5AfW4008618 for ; Thu, 19 Sep 2002 22:10:41 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8K5AeFg006669 for ; Thu, 19 Sep 2002 22:10:40 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id WAA00484 for ; Thu, 19 Sep 2002 22:10:38 -0700 (PDT) Message-ID: <3D8AADCA.942F9DBC@cisco.com> Date: Fri, 20 Sep 2002 00:10:34 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI Naming and Discovery Draft Content-Type: multipart/mixed; boundary="------------1A4C64E4A0CA2EEE710D85B9" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------1A4C64E4A0CA2EEE710D85B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've made (I think) all of the edits required for the naming and discovery draft. A pre-release of the draft is available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi/working/draft-ietf-ips-iscsi-name-disc-07.txt I will submit the draft after the commentors have made sure that I didn't mess anything up (it's getting late), and would like to post the draft either on Monday or whenever David or Elizabeth want it done. I'll renumber the references in order of appearance after I'm sure that there are no more changes. Marjorie, Pat, Elizabeth, Robert, Amir- Thanks for your comments. Please take a look to make sure everything's OK. In particular, look at 1.1 and B.4. I've attached a (hopefully) complete list of changes below. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --------------1A4C64E4A0CA2EEE710D85B9 Content-Type: text/plain; charset=us-ascii; name="name-disc-07-changes.txt" Content-Disposition: inline; filename="name-disc-07-changes.txt" Content-Transfer-Encoding: 7bit Changes made from N&D draft-06 to draft-07: Overall x PT - Move appendices to the end after the Authors names ? PT - Target Address difference from iSCSI TargetAddress key MK - That's OK, since they have different purposes ? PT - Initiator addresses are not described MB - I'm not sure we need to describe them; I haven't done anything with this comment yet. Section 1 x MK - Address example cleanup x PT - Clarified iSCSI node relationship, removed term "iSCSI node name", Referenced T10 doc for SCSI device name x PT - Clarify node has one or more addresses x PT - Have some of the examples include a x PT/MK - Reword the "principal object" sentence x MK - Remove iSCSI session from the address analogy Section 1.1 Please take a look at new wording. x MK - Clarification of organizational naming authority x MK - Fix up text on ":" to be more clear about sub-domain names Split out the first three examples for better clarity. Added comments about responsibilities and domain name ownership. Added reference to iSCSI and spelled out the construction of an iqn name. Deleted confusing text on the use of ':' and clarified it using the examples instead. x MK - Add ":" to last example x MB - Also fixed up descriptions of parts of the IQN, such as the date code. Section 2 x ER - Alias definition needs reference to iSCSI doc Section 2.2 x PT - Need rewording after in first example Section 3 x MK - Editorial fix on LUN discovery sentence x MK - Editorial fix on iSCSI discovery goals x MK - Clarify that it's the target's IP address and TCP port info Section B.1 x PT - Add note about the effects of port redirectors on SendTargets This comment is inherited for SOCKS servers by reference. Section B.3 x RG - Added gateway caveat. x MK - Mapping typo - change iSCSI to SCSI Section B.4 Please take a look at new wording. x MK - Gateway confusing x AS - Reword proxy functionality to take advantage of specific transport properties Section B.5 x MK - Define DMZ References x PT - Three references are no longer used - will remove them Authors x MB - Add John's contact info Don't Forget! x Fix up page numbers in TOC x Check dates x Make sure references are up to date x Add names to RFC references x Add T10 SCSI domain name reference Left to do (when I'm really sure this is done) Renumber references in order of appearance --------------1A4C64E4A0CA2EEE710D85B9-- From owner-ips@ece.cmu.edu Fri Sep 20 10:35:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24146 for ; Fri, 20 Sep 2002 10:35:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8KDtET16720 for ips-outgoing; Fri, 20 Sep 2002 09:55:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8KDtBo16714 for ; Fri, 20 Sep 2002 09:55:11 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119051>; Fri, 20 Sep 2002 09:55:02 -0400 Reply-To: From: "Tony Battersby" To: Subject: iSCSI: ABORT TASK SET et al. in Drafts 16 & 17 Date: Fri, 20 Sep 2002 09:54:59 -0400 Message-ID: <000b01c260ad$502843e0$e0019d89@cybernetics.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Consider the following scenario: a) Target receives a non-immediate command with CmdSN 9 b) Target receives an immediate ABORT TASK SET with CmdSN 11 c) Target receives an immediate command with CmdSN 11 d) Target receives a non-immediate command with CmdSN 10 e) Target receives a non-immediate command with CmdSN 11 (the target could receive the commands out-of-order because they might be sent on different connections) For processing the ABORT TASK SET, Section 9.6.2 (Draft 17), "Task Management Actions on Task Sets", the target: "b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received." The set of "all affected tasks" is defined in Section 9.5.1. Prior to Draft 16, this was: "Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN." Going with this definition, the target should abort the commands from steps a) and d) but not from steps c) and e). The target would have to wait for and abort the non-immediate command with CmdSN 10 in step d) before returning the Task Management Function Response. However, later in the same paragraph (Draft 15), the set of "all affected tasks" was re-defined as the tasks "with CmdSN not higher than the task management command CmdSN", which is different from the first definition for the case of tasks with CmdSN equal to the Task Management Function. When I asked about this discrepancy (in the message with the subject "iSCSI: Abort Task Set CmdSN: < or <="), I was told "Abort Task Set should act only on commands that where issued before it and immediate commands with the same CmdSN do not meet this criteria." This explanation worked for me, and I assumed that the CmdSN comparison should be "<" rather than "<=". However, in Draft 16, the text was changed to: "Task management requests must act on all the commands having a CmdSN that do not exceed the task management CmdSN." I assume that this change was made along with the other changes for ABORT TASK on immediate commands. This change in wording may work for ABORT TASK but it does not make sense to me for other Task Management Functions (ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET). To see this, consider the same example again: Using a "<=" comparison on CmdSN, the target would have to abort the commands from steps a), b), d), and e). The target would have to wait for command e) before returning the Task Management Function Response. Because of the requirement for immediate commands to carry the current CmdSN value, the initiator would have had to issue command e) _after_ the ABORT TASK SET command. So, the target would have to wait for and abort a command that was issued after the ABORT TASK SET itself. This clearly does not make sense, so I assume that the change in wording in Draft 16 was not intended to imply a change in behavior for ABORT TASK SET et al., correct? Could the wording be revised to fix this? Anthony Battersby Cybernetics From owner-ips@ece.cmu.edu Fri Sep 20 12:02:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27383 for ; Fri, 20 Sep 2002 12:02:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8KFNCu23207 for ips-outgoing; Fri, 20 Sep 2002 11:23:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8KBsuo09612 for ; Fri, 20 Sep 2002 07:54:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19060; Fri, 20 Sep 2002 07:52:52 -0400 (EDT) Message-Id: <200209201152.HAA19060@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-security-16.txt Date: Fri, 20 Sep 2002 07:52:52 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Securing Block Storage Protocols over IP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-16.txt Pages : 68 Date : 2002-9-19 This document discusses how to secure block storage and storage discovery protocols running over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-16.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-security-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-security-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-19154721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-19154721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Sep 20 15:38:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05451 for ; Fri, 20 Sep 2002 15:38:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8KIw4708720 for ips-outgoing; Fri, 20 Sep 2002 14:58:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from almaden.ibm.com (p1.almaden.ibm.com [198.4.83.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8KIw1o08713 for ; Fri, 20 Sep 2002 14:58:02 -0400 (EDT) Received: from ibmjh9qh9xf2ft (ibm-jh9qh9xf2ft.almaden.ibm.com [9.1.21.109]) by almaden.ibm.com (AIX4.3/8.9.3/8.9.3) with SMTP id LAA52952 for ; Fri, 20 Sep 2002 11:57:55 -0700 Message-ID: <013001c260d7$80e6a6f0$16170109@almaden.ibm.com> From: "Prasenjit Sarkar" To: Subject: iSCSI Boot: Technical Issues Date: Fri, 20 Sep 2002 11:57:01 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012D_01C2609C.D45FFBA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_012D_01C2609C.D45FFBA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1. Looks like there is no opposition to making this a standard draft. 2. After talking to an HCI person in IBM, I have the following proposal: We can change the LUN format to be xxxx-xxxx-xxxx-xxxx This notation is subtantially better than "xxxxxxxxxxxxxxxx" in terms of = HCI errors and is almost equivalent to a 16-bit format representation. Since most of the numbers are going to be zeros, all we need to do is to = edit 1 set of "xxxx". I hope concerned parties at both sides are amenable to a resolution, = since I have not seen any new arguments in the past week, Thanks, Prasenjit ------=_NextPart_000_012D_01C2609C.D45FFBA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

1. Looks like there is no opposition to = making this=20 a standard draft.
 
2. After talking to an HCI person in = IBM, I have=20 the following proposal:
 
We can change the LUN format to be=20 xxxx-xxxx-xxxx-xxxx
 
This notation is subtantially better = than=20 "xxxxxxxxxxxxxxxx" in terms of HCI errors and is almost equivalent to a = 16-bit=20 format representation.
 
Since most of the numbers are going to = be zeros,=20 all we need to do is to edit 1 set of "xxxx".
 
I hope concerned parties at both sides = are amenable=20 to a resolution, since I have not seen any new arguments in the past=20 week,
 
Thanks,
Prasenjit
------=_NextPart_000_012D_01C2609C.D45FFBA0-- From owner-ips@ece.cmu.edu Fri Sep 20 16:34:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07145 for ; Fri, 20 Sep 2002 16:34:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8KJxVM13311 for ips-outgoing; Fri, 20 Sep 2002 15:59:31 -0400 (EDT) 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 g8KJxSo13306 for ; Fri, 20 Sep 2002 15:59:28 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g8KJxMN27204 for ; Fri, 20 Sep 2002 15:59:22 -0400 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 g8KJxMk27195; Fri, 20 Sep 2002 15:59:22 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g8KJxMk23998; Fri, 20 Sep 2002 15:59:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15755.32282.37168.492446@pkoning.dev.equallogic.com> Date: Fri, 20 Sep 2002 15:59:22 -0400 From: Paul Koning To: psarkar@almaden.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues References: <013001c260d7$80e6a6f0$16170109@almaden.ibm.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Prasenjit" == Prasenjit Sarkar writes: Prasenjit> 1. Looks like there is no opposition to making this a Prasenjit> standard draft. 2. After talking to an HCI person in IBM, Prasenjit> I have the following proposal: Prasenjit> We can change the LUN format to be xxxx-xxxx-xxxx-xxxx Prasenjit> This notation is subtantially better than Prasenjit> "xxxxxxxxxxxxxxxx" in terms of HCI errors and is almost Prasenjit> equivalent to a 16-bit format representation. Prasenjit> Since most of the numbers are going to be zeros, all we Prasenjit> need to do is to edit 1 set of "xxxx". I don't see why human factors questions appear in discussions about protocols. If you want the UI to be nice, put a nice UI on the application that generates the protocol. I see no reason to make the protocol encoding itself user-friendly. paul From owner-ips@ece.cmu.edu Fri Sep 20 16:34:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07161 for ; Fri, 20 Sep 2002 16:34:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8KKG3614511 for ips-outgoing; Fri, 20 Sep 2002 16:16:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8KKG0o14504 for ; Fri, 20 Sep 2002 16:16:01 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8KKFm3x019056; Fri, 20 Sep 2002 13:15:48 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8KKFriH021416; Fri, 20 Sep 2002 13:15:53 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA21990; Fri, 20 Sep 2002 13:15:51 -0700 (PDT) Message-ID: <3D8B81F8.AF32511D@cisco.com> Date: Fri, 20 Sep 2002 15:15:52 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Prasenjit Sarkar CC: ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues References: <013001c260d7$80e6a6f0$16170109@almaden.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Prasenjit- I like the dashes better. They would also make it easier to just specify the part of the LUN structure that is needed. SAM-2 section 4.9 defines three formats for 4-byte LUNs; the first two only use the first 16 bits, and most implementations only use these. I still think that it will be a relatively rare case to use more than the first four digits. Can I suggest: Single-level LUNs (defined in SAM-2 4.9.3) use xxxx; these can have values up to 0x3fff. Multiple-level LUNs (defined in 4.9.4) use as many xxxx fields as they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and xxxx-xxxx-xxxx-xxxx are all valid; unspecified xxxx are zeroes). That would fit well with the way the LUN structuring works in SAM-2; each implementation uses the number of levels that it needs. I just noticed that SAM-2 also allows extended single-level LUN fields up to 8 bytes. It appears that these are there for single- level LUN implementations that need to define LUN values greater than 0x3fff, without using the multi-level LUN structure which was built mostly for (I think) parallel SCSI gateways. Anyway, I think that your dash format, allowing for as many sets of xxxx as needed, would be the ideal LUN format. -- Mark > Prasenjit Sarkar wrote: > > 1. Looks like there is no opposition to making this a standard draft. > > 2. After talking to an HCI person in IBM, I have the following proposal: > > We can change the LUN format to be xxxx-xxxx-xxxx-xxxx > > This notation is subtantially better than "xxxxxxxxxxxxxxxx" in terms of HCI errors and is almost > equivalent to a 16-bit format representation. > > Since most of the numbers are going to be zeros, all we need to do is to edit 1 set of "xxxx". > > I hope concerned parties at both sides are amenable to a resolution, since I have not seen any new > arguments in the past week, > > Thanks, > Prasenjit -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Sep 20 16:35:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07210 for ; Fri, 20 Sep 2002 16:35:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8KKKLX14793 for ips-outgoing; Fri, 20 Sep 2002 16:20:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8KKKJo14789 for ; Fri, 20 Sep 2002 16:20:19 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8KKKA1X007995; Fri, 20 Sep 2002 13:20:10 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8KKKAKE005525; Fri, 20 Sep 2002 13:20:10 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA24732; Fri, 20 Sep 2002 13:20:08 -0700 (PDT) Message-ID: <3D8B82F9.1A67040C@cisco.com> Date: Fri, 20 Sep 2002 15:20:09 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Paul Koning CC: psarkar@almaden.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues References: <013001c260d7$80e6a6f0$16170109@almaden.ibm.com> <15755.32282.37168.492446@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul- Since DHCP strings are configured directly by the user of a DHCP server (which knows nothing about iSCSI or LUNs, and probably shouldn't), we do have to care about the human factors here. Otherwise, anyone wanting to support iSCSI boot will either have to build their own DHCP server tools (or interfaces to Linux or Microsoft servers), or will have to convince Microsoft to add iSCSI string and LUN support to DHCP (and wait for this to happen), or let the user live with a difficult format. None of the above solutions are that appealing. Making the LUN format easier to handle is by far the simplest solution. -- Mark Paul Koning wrote: > > >>>>> "Prasenjit" == Prasenjit Sarkar writes: > > Prasenjit> 1. Looks like there is no opposition to making this a > Prasenjit> standard draft. 2. After talking to an HCI person in IBM, > Prasenjit> I have the following proposal: > > Prasenjit> We can change the LUN format to be xxxx-xxxx-xxxx-xxxx > > Prasenjit> This notation is subtantially better than > Prasenjit> "xxxxxxxxxxxxxxxx" in terms of HCI errors and is almost > Prasenjit> equivalent to a 16-bit format representation. > > Prasenjit> Since most of the numbers are going to be zeros, all we > Prasenjit> need to do is to edit 1 set of "xxxx". > > I don't see why human factors questions appear in discussions about > protocols. > > If you want the UI to be nice, put a nice UI on the application that > generates the protocol. I see no reason to make the protocol encoding > itself user-friendly. > > paul -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Sep 20 18:15:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11498 for ; Fri, 20 Sep 2002 18:15:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8KLWua19725 for ips-outgoing; Fri, 20 Sep 2002 17:32:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8KLWto19721 for ; Fri, 20 Sep 2002 17:32:55 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8KLWlx10446; Fri, 20 Sep 2002 17:32:47 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g8KLWk701556; Fri, 20 Sep 2002 17:32:46 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 17:32:46 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C331@CORPMX14> From: Black_David@emc.com To: psarkar@almaden.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI Boot: Technical Issues Date: Fri, 20 Sep 2002 17:32:38 -0400 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 > 1. Looks like there is no opposition to making this a standard draft. With my WG co-chair hat on, I believe this to be the rough consensus of the IP Storage WG. Please limit the use of MUST/SHOULD/MAY and the like to Section 4 of the draft. > 2. After talking to an HCI person in IBM, I have the following proposal: > > We can change the LUN format to be xxxx-xxxx-xxxx-xxxx > > This notation is subtantially better than "xxxxxxxxxxxxxxxx" in terms of > HCI errors and is almost equivalent to a 16-bit format representation. > > Since most of the numbers are going to be zeros, all we need to do is to > edit 1 set of "xxxx". With my WG co-chair hat off, I definitely like this proposal. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 20 22:42:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17105 for ; Fri, 20 Sep 2002 22:42:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8L24F603212 for ips-outgoing; Fri, 20 Sep 2002 22:04:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12803.mail.yahoo.com (web12803.mail.yahoo.com [216.136.174.38]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g8L24Do03208 for ; Fri, 20 Sep 2002 22:04:13 -0400 (EDT) Message-ID: <20020921020412.86103.qmail@web12803.mail.yahoo.com> Received: from [24.43.193.25] by web12803.mail.yahoo.com via HTTP; Fri, 20 Sep 2002 19:04:12 PDT Date: Fri, 20 Sep 2002 19:04:12 -0700 (PDT) From: Luben Tuikov Subject: Re: iSCSI Boot: Technical Issues To: Mark Bakke , Prasenjit Sarkar Cc: ips@ece.cmu.edu In-Reply-To: <3D8B81F8.AF32511D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Mark Bakke wrote: > > Multiple-level LUNs (defined in 4.9.4) use as many xxxx > fields as > they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and > xxxx-xxxx-xxxx-xxxx > are all valid; unspecified xxxx are zeroes). More formally: `` ... unspecified xxxx to the left, are zeros.'' -- Luben ===== -- __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ips@ece.cmu.edu Sat Sep 21 17:24:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17600 for ; Sat, 21 Sep 2002 17:24:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8LKYKZ25728 for ips-outgoing; Sat, 21 Sep 2002 16:34:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-d08.mx.aol.com (imo-d08.mx.aol.com [205.188.157.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8LKYIo25721 for ; Sat, 21 Sep 2002 16:34:18 -0400 (EDT) Received: from VAHUJA@aol.com by imo-d08.mx.aol.com (mail_out_v34.10.) id 3.9b.2db0af4e (3964) for ; Sat, 21 Sep 2002 16:34:05 -0400 (EDT) From: VAHUJA@aol.com Message-ID: <9b.2db0af4e.2abe31bd@aol.com> Date: Sat, 21 Sep 2002 16:34:05 EDT Subject: D-H Software Implementation To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 7.0 for Windows US sub 10637 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is a request - I am looking for a software implementation of Diffie Hellman algorithm - commercial or freeware. Any info anyone has in this regard will help....thanks in advance, vijay From owner-ips@ece.cmu.edu Sun Sep 22 09:52:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07694 for ; Sun, 22 Sep 2002 09:52:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8MCxBg08772 for ips-outgoing; Sun, 22 Sep 2002 08:59:11 -0400 (EDT) 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 g8MCx8o08767; Sun, 22 Sep 2002 08:59:08 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8MCwqTn034092; Sun, 22 Sep 2002 14:58:52 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8MCwpaD008730; Sun, 22 Sep 2002 14:58:52 +0200 To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: ABORT TASK SET et al. in Drafts 16 & 17 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 22 Sep 2002 15:58:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/09/2002 15:58:51, Serialize complete at 22/09/2002 15:58:51 Content-Type: multipart/alternative; boundary="=_alternative 00471D32C2256C3C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00471D32C2256C3C_= Content-Type: text/plain; charset="us-ascii" Tony, It is a mistake. I will fix it the first time I have a chance. Thanks, Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 20/09/02 16:54 Please respond to tonyb To: cc: Subject: iSCSI: ABORT TASK SET et al. in Drafts 16 & 17 Consider the following scenario: a) Target receives a non-immediate command with CmdSN 9 b) Target receives an immediate ABORT TASK SET with CmdSN 11 c) Target receives an immediate command with CmdSN 11 d) Target receives a non-immediate command with CmdSN 10 e) Target receives a non-immediate command with CmdSN 11 (the target could receive the commands out-of-order because they might be sent on different connections) For processing the ABORT TASK SET, Section 9.6.2 (Draft 17), "Task Management Actions on Task Sets", the target: "b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received." The set of "all affected tasks" is defined in Section 9.5.1. Prior to Draft 16, this was: "Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN." Going with this definition, the target should abort the commands from steps a) and d) but not from steps c) and e). The target would have to wait for and abort the non-immediate command with CmdSN 10 in step d) before returning the Task Management Function Response. However, later in the same paragraph (Draft 15), the set of "all affected tasks" was re-defined as the tasks "with CmdSN not higher than the task management command CmdSN", which is different from the first definition for the case of tasks with CmdSN equal to the Task Management Function. When I asked about this discrepancy (in the message with the subject "iSCSI: Abort Task Set CmdSN: < or <="), I was told "Abort Task Set should act only on commands that where issued before it and immediate commands with the same CmdSN do not meet this criteria." This explanation worked for me, and I assumed that the CmdSN comparison should be "<" rather than "<=". However, in Draft 16, the text was changed to: "Task management requests must act on all the commands having a CmdSN that do not exceed the task management CmdSN." I assume that this change was made along with the other changes for ABORT TASK on immediate commands. This change in wording may work for ABORT TASK but it does not make sense to me for other Task Management Functions (ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET). To see this, consider the same example again: Using a "<=" comparison on CmdSN, the target would have to abort the commands from steps a), b), d), and e). The target would have to wait for command e) before returning the Task Management Function Response. Because of the requirement for immediate commands to carry the current CmdSN value, the initiator would have had to issue command e) _after_ the ABORT TASK SET command. So, the target would have to wait for and abort a command that was issued after the ABORT TASK SET itself. This clearly does not make sense, so I assume that the change in wording in Draft 16 was not intended to imply a change in behavior for ABORT TASK SET et al., correct? Could the wording be revised to fix this? Anthony Battersby Cybernetics --=_alternative 00471D32C2256C3C_= Content-Type: text/html; charset="us-ascii"
Tony,

It is a mistake. I will fix it the first time I have a chance.

Thanks,
Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

20/09/02 16:54
Please respond to tonyb

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: ABORT TASK SET et al. in Drafts 16 & 17

       


Consider the following scenario:

a) Target receives a non-immediate command with CmdSN 9
b) Target receives an immediate ABORT TASK SET with CmdSN 11
c) Target receives an immediate command with CmdSN 11
d) Target receives a non-immediate command with CmdSN 10
e) Target receives a non-immediate command with CmdSN 11

(the target could receive the commands out-of-order because they might be
sent on different connections)

For processing the ABORT TASK SET, Section 9.6.2 (Draft 17), "Task
Management Actions on Task Sets", the target:

"b) Waits for all target transfer tags to be responded to and for all
affected tasks in the task set to be received."

The set of "all affected tasks" is defined in Section 9.5.1.  Prior to Draft
16, this was:

"Task management requests must act on all the commands having a CmdSN lower
than the task management CmdSN."

Going with this definition, the target should abort the commands from steps
a) and d) but not from steps c) and e).  The target would have to wait for
and abort the non-immediate command with CmdSN 10 in step d) before
returning the Task Management Function Response.

However, later in the same paragraph (Draft 15), the set of "all affected
tasks" was re-defined as the tasks "with CmdSN not higher than the task
management command CmdSN", which is different from the first definition for
the case of tasks with CmdSN equal to the Task Management Function.  When I
asked about this discrepancy (in the message with the subject "iSCSI: Abort
Task Set CmdSN: < or <="), I was told "Abort Task Set should act only on
commands that where issued before it and immediate commands with the same
CmdSN do not meet this criteria."  This explanation worked for me, and I
assumed that the CmdSN comparison should be "<" rather than "<=".

However, in Draft 16, the text was changed to:

"Task management requests must act on all the commands having a CmdSN that
do not exceed the task management CmdSN."

I assume that this change was made along with the other changes for ABORT
TASK on immediate commands.  This change in wording may work for ABORT TASK
but it does not make sense to me for other Task Management Functions (ABORT
TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET).  To see this, consider the
same example again:

Using a "<=" comparison on CmdSN, the target would have to abort the
commands from steps a), b), d), and e).  The target would have to wait for
command e) before returning the Task Management Function Response.  Because
of the requirement for immediate commands to carry the current CmdSN value,
the initiator would have had to issue command e) _after_ the ABORT TASK SET
command.  So, the target would have to wait for and abort a command that was
issued after the ABORT TASK SET itself.

This clearly does not make sense, so I assume that the change in wording in
Draft 16 was not intended to imply a change in behavior for ABORT TASK SET
et al., correct?  Could the wording be revised to fix this?

Anthony Battersby
Cybernetics

--=_alternative 00471D32C2256C3C_=-- From owner-ips@ece.cmu.edu Sun Sep 22 21:03:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15847 for ; Sun, 22 Sep 2002 21:03:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8N0K3v03052 for ips-outgoing; Sun, 22 Sep 2002 20:20:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8N0K1o03048 for ; Sun, 22 Sep 2002 20:20:01 -0400 (EDT) Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.10) with SMTP id ; Sun, 22 Sep 2002 20:19:58 -0400 Received: from nwd2mhb2 ([137.71.6.12]) by nwd2gtw1; Sun, 22 Sep 2002 20:19:56 -0400 (EDT) Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb2.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id UAA23280; Sun, 22 Sep 2002 20:19:55 -0400 (EDT) Received: from ramana.analog.com (dhcp16 [137.71.139.81]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id RAA03665; Sun, 22 Sep 2002 17:19:54 -0700 (PDT) Message-Id: <4.3.2.7.1.20020922171725.00d81780@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 22 Sep 2002 17:18:16 -0700 To: VAHUJA@aol.com, ips@ece.cmu.edu From: Ramana Yarlagadda Subject: Re: D-H Software Implementation In-Reply-To: <9b.2db0af4e.2abe31bd@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Look at openSSL or GMP library. At 04:34 PM 9/21/02 -0400, VAHUJA@aol.com wrote: >This is a request - I am looking for a software implementation of Diffie >Hellman algorithm - commercial or freeware. Any info anyone has in this >regard will help....thanks in advance, vijay From owner-ips@ece.cmu.edu Mon Sep 23 10:09:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09766 for ; Mon, 23 Sep 2002 10:09:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NDcqM16902 for ips-outgoing; Mon, 23 Sep 2002 09:38:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NDcno16893 for ; Mon, 23 Sep 2002 09:38:49 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8NDccW4018887; Mon, 23 Sep 2002 06:38:38 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NDcbkP028823; Mon, 23 Sep 2002 06:38:37 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA10464; Mon, 23 Sep 2002 06:38:36 -0700 (PDT) Message-ID: <3D8F195C.1898522C@cisco.com> Date: Mon, 23 Sep 2002 08:38:36 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "Robert D. Russell" CC: Luben Tuikov , Prasenjit Sarkar , ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Robert D. Russell" wrote: > > Mark -- Two clarifications please: > > 1. Each x in xxxx is a hex digit, correct? Correct. > > 2. Are the missing xxxx supplied to the left, as Luben suggests, > or to the right, as was implied by the reason that this > whole discussion came up. i.e., is 1234-5678 > shorthand for 1234-5678-0000-0000 or for > 0000-0000-1234-5678? > I believe the first interpretation (1234-5678-0000-0000) > is the only useful one, because the second interpretation > means you always have to enter all 4 groups of xxxx due to > the format of the 64-bit LUN field in iscsi PDUs. You are correct; it should be to the right. I should have read your message before I sent the last response. -- Mark > > Thanks for the clarification. > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > On Fri, 20 Sep 2002, Luben Tuikov wrote: > > > --- Mark Bakke wrote: > > > > > > Multiple-level LUNs (defined in 4.9.4) use as many xxxx > > > fields as > > > they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and > > > xxxx-xxxx-xxxx-xxxx > > > are all valid; unspecified xxxx are zeroes). > > > > More formally: `` ... unspecified xxxx to the left, are > > zeros.'' > > > > -- > > Luben > > > > > > > > ===== > > -- > > > > __________________________________________________ > > Do you Yahoo!? > > New DSL Internet Access from SBC & Yahoo! > > http://sbc.yahoo.com > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Sep 23 10:17:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10089 for ; Mon, 23 Sep 2002 10:17:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NDVkI16417 for ips-outgoing; Mon, 23 Sep 2002 09:31:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NDVio16410 for ; Mon, 23 Sep 2002 09:31:44 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NDVV3x014539; Mon, 23 Sep 2002 06:31:31 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NDVatM024760; Mon, 23 Sep 2002 06:31:36 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA08955; Mon, 23 Sep 2002 06:31:35 -0700 (PDT) Message-ID: <3D8F17B7.21A31391@cisco.com> Date: Mon, 23 Sep 2002 08:31:35 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Luben Tuikov CC: Prasenjit Sarkar , ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues References: <20020921020412.86103.qmail@web12803.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Oh, yes, I forgot to specify that. Actually, it should be "unspecified xxxx to the right are all zeroes". The reason is that the LUN field is not a number; it is a structure. The first two bytes are the first-level LUN; the second two are the second-level LUN, and so forth. It's meant to allow a gateway to take, for instance, a group of targets, each with their own LUNs, make the original LUNs second-level LUNs, then make up its own first-level LUN for each target. These can be used in other ways as well. This all means that when specifying a first-level LUN, it would be (let's say LUN 4) 0004-0000-0000-0000. So saying they are unspecified to the right would be the way to go. -- Mark Luben Tuikov wrote: > > --- Mark Bakke wrote: > > > > Multiple-level LUNs (defined in 4.9.4) use as many xxxx > > fields as > > they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and > > xxxx-xxxx-xxxx-xxxx > > are all valid; unspecified xxxx are zeroes). > > More formally: `` ... unspecified xxxx to the left, are > zeros.'' > > -- > Luben > > ===== > -- > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Sep 23 11:06:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12076 for ; Mon, 23 Sep 2002 11:06:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NEewF21250 for ips-outgoing; Mon, 23 Sep 2002 10:40:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NEeto21244; Mon, 23 Sep 2002 10:40:55 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8NEdvUD039422; Mon, 23 Sep 2002 16:39:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8NEduCd045836; Mon, 23 Sep 2002 16:39:56 +0200 To: Mark Bakke Cc: ips@ece.cmu.edu, Luben Tuikov , owner-ips@ece.cmu.edu, "Prasenjit Sarkar" MIME-Version: 1.0 Subject: Re: iSCSI Boot: Technical Issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 23 Sep 2002 17:39:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/09/2002 17:39:56, Serialize complete at 23/09/2002 17:39:56 Content-Type: multipart/alternative; boundary="=_alternative 004F8DB6C2256C3D_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004F8DB6C2256C3D_= Content-Type: text/plain; charset="us-ascii" Mark, Carefully. You may want to add the "0s to the right" as this is practical. But don't add the LUN structure text. It is not always so. There are several types of LUN structures... And I am sure you don't want to go there. Julo Mark Bakke Sent by: owner-ips@ece.cmu.edu 23/09/02 15:31 To: Luben Tuikov cc: Prasenjit Sarkar/Almaden/IBM@IBMUS, ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues Oh, yes, I forgot to specify that. Actually, it should be "unspecified xxxx to the right are all zeroes". The reason is that the LUN field is not a number; it is a structure. The first two bytes are the first-level LUN; the second two are the second-level LUN, and so forth. It's meant to allow a gateway to take, for instance, a group of targets, each with their own LUNs, make the original LUNs second-level LUNs, then make up its own first-level LUN for each target. These can be used in other ways as well. This all means that when specifying a first-level LUN, it would be (let's say LUN 4) 0004-0000-0000-0000. So saying they are unspecified to the right would be the way to go. -- Mark Luben Tuikov wrote: > > --- Mark Bakke wrote: > > > > Multiple-level LUNs (defined in 4.9.4) use as many xxxx > > fields as > > they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and > > xxxx-xxxx-xxxx-xxxx > > are all valid; unspecified xxxx are zeroes). > > More formally: `` ... unspecified xxxx to the left, are > zeros.'' > > -- > Luben > > ===== > -- > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 004F8DB6C2256C3D_= Content-Type: text/html; charset="us-ascii"
Mark,

Carefully. You may want to add the "0s to the right" as this is practical.
But don't add the LUN structure text. It is not always so. There are several types of LUN structures...
And I am sure you don't want to go there.

Julo


Mark Bakke <mbakke@cisco.com>
Sent by: owner-ips@ece.cmu.edu

23/09/02 15:31

       
        To:        Luben Tuikov <ltuikov@yahoo.com>
        cc:        Prasenjit Sarkar/Almaden/IBM@IBMUS, ips@ece.cmu.edu
        Subject:        Re: iSCSI Boot: Technical Issues

       


Oh, yes, I forgot to specify that.

Actually, it should be "unspecified xxxx to the right are
all zeroes".  The reason is that the LUN field is not a
number; it is a structure.  The first two bytes are the
first-level LUN; the second two are the second-level LUN,
and so forth.  It's meant to allow a gateway to take, for
instance, a group of targets, each with their own LUNs,
make the original LUNs second-level LUNs, then make up its
own first-level LUN for each target.  These can be used
in other ways as well.

This all means that when specifying a first-level LUN, it
would be (let's say LUN 4) 0004-0000-0000-0000.  So saying
they are unspecified to the right would be the way to go.

--
Mark


Luben Tuikov wrote:
>
> --- Mark Bakke <mbakke@cisco.com> wrote:
> >
> > Multiple-level LUNs (defined in 4.9.4) use as many xxxx
> > fields as
> > they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and
> > xxxx-xxxx-xxxx-xxxx
> > are all valid; unspecified xxxx are zeroes).
>
> More formally: `` ... unspecified xxxx to the left, are
> zeros.''
>
> --
> Luben
>
> =====
> --
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 004F8DB6C2256C3D_=-- From owner-ips@ece.cmu.edu Mon Sep 23 11:07:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12106 for ; Mon, 23 Sep 2002 11:07:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NEUep20540 for ips-outgoing; Mon, 23 Sep 2002 10:30:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web21209.mail.yahoo.com (web21209.mail.yahoo.com [216.136.175.167]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g8NEUco20536 for ; Mon, 23 Sep 2002 10:30:38 -0400 (EDT) Message-ID: <20020923143037.90583.qmail@web21209.mail.yahoo.com> Received: from [152.15.23.61] by web21209.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 10:30:37 EDT Date: Mon, 23 Sep 2002 10:30:37 -0400 (EDT) From: David Wong Subject: Re: D-H Software Implementation To: Ramana Yarlagadda , VAHUJA@aol.com, ips@ece.cmu.edu In-Reply-To: <4.3.2.7.1.20020922171725.00d81780@golf.cpgdesign.analog.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk A very good and efficient implementation is from: MIRACL http://indigo.ie/~mscott/ which is indeed much better and efficient than several "commercial" versions. --- Ramana Yarlagadda wrote: > Hi, > > Look at openSSL or GMP library. > > At 04:34 PM 9/21/02 -0400, VAHUJA@aol.com wrote: > >This is a request - I am looking for a software > implementation of Diffie > >Hellman algorithm - commercial or freeware. Any > info anyone has in this > >regard will help....thanks in advance, vijay > > ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From owner-ips@ece.cmu.edu Mon Sep 23 11:07:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12134 for ; Mon, 23 Sep 2002 11:07:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NEo8I21826 for ips-outgoing; Mon, 23 Sep 2002 10:50:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NEo4o21820; Mon, 23 Sep 2002 10:50:04 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8NEkD1X023926; Mon, 23 Sep 2002 07:46:13 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8NEkCug009242; Mon, 23 Sep 2002 07:46:12 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA04640; Mon, 23 Sep 2002 07:46:11 -0700 (PDT) Message-ID: <3D8F2933.A6E3C364@cisco.com> Date: Mon, 23 Sep 2002 09:46:11 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu, Luben Tuikov , owner-ips@ece.cmu.edu, Prasenjit Sarkar Subject: Re: iSCSI Boot: Technical Issues 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 agree on not adding LUN structure text; it's just too scary for one thing, and like you said, it's not the only one. If we can just say 0s to the right, that's fine with me. Thanks, Mark Julian Satran wrote: > > Mark, > > Carefully. You may want to add the "0s to the right" as this is practical. > But don't add the LUN structure text. It is not always so. There are several types of LUN > structures... > And I am sure you don't want to go there. > > Julo > > Mark Bakke > Sent by: owner-ips@ece.cmu.edu To: Luben Tuikov > cc: Prasenjit Sarkar/Almaden/IBM@IBMUS, > 23/09/02 15:31 ips@ece.cmu.edu > Subject: Re: iSCSI Boot: Technical Issues > > > > Oh, yes, I forgot to specify that. > > Actually, it should be "unspecified xxxx to the right are > all zeroes". The reason is that the LUN field is not a > number; it is a structure. The first two bytes are the > first-level LUN; the second two are the second-level LUN, > and so forth. It's meant to allow a gateway to take, for > instance, a group of targets, each with their own LUNs, > make the original LUNs second-level LUNs, then make up its > own first-level LUN for each target. These can be used > in other ways as well. > > This all means that when specifying a first-level LUN, it > would be (let's say LUN 4) 0004-0000-0000-0000. So saying > they are unspecified to the right would be the way to go. > > -- > Mark > > Luben Tuikov wrote: > > > > --- Mark Bakke wrote: > > > > > > Multiple-level LUNs (defined in 4.9.4) use as many xxxx > > > fields as > > > they need (e.g. xxxx-xxxx, xxxx-xxxx-xxxx, and > > > xxxx-xxxx-xxxx-xxxx > > > are all valid; unspecified xxxx are zeroes). > > > > More formally: `` ... unspecified xxxx to the left, are > > zeros.'' > > > > -- > > Luben > > > > ===== > > -- > > > > __________________________________________________ > > Do you Yahoo!? > > New DSL Internet Access from SBC & Yahoo! > > http://sbc.yahoo.com > > -- > 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 Mon Sep 23 12:35:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15460 for ; Mon, 23 Sep 2002 12:35:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NGDKW27968 for ips-outgoing; Mon, 23 Sep 2002 12:13:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NGDIo27961 for ; Mon, 23 Sep 2002 12:13:18 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Sep 2002 12:13:07 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C33D@CORPMX14> From: Black_David@emc.com To: ltuikov@yahoo.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Boot: Technical Issues Date: Mon, 23 Sep 2002 12:13:05 -0400 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 > Q: is xxxx-xxxx-xxxx-xxxx supposed to be _just_ as > SAM-3 stipulates? (rhetorical question) > > If so, then ``within each group of 4 hexacedimal digits > zeros are filled to the right, and groups of zeros > are filled to the left'' might be a wiser stipulation. > > This ``right/left'' rule will be easy on the average user's > (the luser :-)) brain not to strain too much to understand > what it is (LUN) and that the good old '4' still > works just as the newer '801F-0000-...'. Clearer desciption of the same idea - it's four 16-bit hex numbers separated by dashes, if there are less than four numbers, the missing numbers are on the right and are all zero. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 23 12:36:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15475 for ; Mon, 23 Sep 2002 12:36:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NFrVg26604 for ips-outgoing; Mon, 23 Sep 2002 11:53:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12807.mail.yahoo.com (web12807.mail.yahoo.com [216.136.174.42]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g8NFrTo26600 for ; Mon, 23 Sep 2002 11:53:30 -0400 (EDT) Message-ID: <20020923155329.63668.qmail@web12807.mail.yahoo.com> Received: from [24.43.193.25] by web12807.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 08:53:28 PDT Date: Mon, 23 Sep 2002 08:53:28 -0700 (PDT) From: Luben Tuikov Subject: Re: iSCSI Boot: Technical Issues To: Mark Bakke Cc: Prasenjit Sarkar , ips@ece.cmu.edu In-Reply-To: <3D8F17B7.21A31391@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Mark Bakke wrote: > > This all means that when specifying a first-level LUN, it > would be (let's say LUN 4) 0004-0000-0000-0000. So > saying > they are unspecified to the right would be the way to go. Careful! Tom, Dick and Harriet are used to just enter for a LUN a number (and they think it's a number), so you'll have ppl entering just `4'. Using ``to the right'' would make this 4000-0000-0000-0000, contrary to your example. Using ``to the right'' rule is kind of half way telling users _what_ the SAM-3 LUN structure might be like and I also don't think this is wise as Julian has suggested. Natural ordering (e.g. what humans use) would suggest ``to the left'' rule. So that the current (physical) addressing of LUN (`4') and the future (801F-0000-...) supported addressing are both easy on users. (This was more or less my original argument for the ``to the left rule''.) Q: is xxxx-xxxx-xxxx-xxxx supposed to be _just_ as SAM-3 stipulates? (rhetorical question) If so, then ``within each group of 4 hexacedimal digits zeros are filled to the right, and groups of zeros are filled to the left'' might be a wiser stipulation. This ``right/left'' rule will be easy on the average user's (the luser :-)) brain not to strain too much to understand what it is (LUN) and that the good old '4' still works just as the newer '801F-0000-...'. -- Luben ===== -- __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ips@ece.cmu.edu Mon Sep 23 12:38:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15563 for ; Mon, 23 Sep 2002 12:38:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NG8we27684 for ips-outgoing; Mon, 23 Sep 2002 12:08:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NG8uo27679 for ; Mon, 23 Sep 2002 12:08:56 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NG8h3x026334; Mon, 23 Sep 2002 09:08:43 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NG8mVY009044; Mon, 23 Sep 2002 09:08:48 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA28652; Mon, 23 Sep 2002 09:08:47 -0700 (PDT) Message-ID: <3D8F3C8F.4D4636A1@cisco.com> Date: Mon, 23 Sep 2002 11:08:47 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Luben Tuikov CC: Prasenjit Sarkar , ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues References: <20020923155329.63668.qmail@web12807.mail.yahoo.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 see your point. In fact, we would take "4" as 0004-0000-0000-0000. How about saying: Within dashes, zeroes to the left; e.g. 4A == 004A. Missing dashed fields become zeroes to the right. 4A = 004A-0000-0000-0000 12C-4-32 = 012C-0004-0032-0000 etc. This is more what I think the user would expect. -- Mark Luben Tuikov wrote: > > --- Mark Bakke wrote: > > > > This all means that when specifying a first-level LUN, it > > would be (let's say LUN 4) 0004-0000-0000-0000. So > > saying > > they are unspecified to the right would be the way to go. > > Careful! > > Tom, Dick and Harriet are used to just enter for a LUN a > number (and they think it's a number), so you'll have > ppl entering just `4'. Using ``to the right'' would make > this 4000-0000-0000-0000, contrary to your example. > > Using ``to the right'' rule is kind of half way telling > users _what_ the SAM-3 LUN structure might be like and > I also don't think this is wise as Julian has suggested. > > Natural ordering (e.g. what humans use) would > suggest ``to the left'' rule. So that the current > (physical) > addressing of LUN (`4') and the future (801F-0000-...) > supported addressing are both easy on users. > (This was more or less my original argument for the > ``to the left rule''.) > > Q: is xxxx-xxxx-xxxx-xxxx supposed to be _just_ as > SAM-3 stipulates? (rhetorical question) > > If so, then ``within each group of 4 hexacedimal digits > zeros are filled to the right, and groups of zeros > are filled to the left'' might be a wiser stipulation. > > This ``right/left'' rule will be easy on the average user's > (the luser :-)) brain not to strain too much to understand > what it is (LUN) and that the good old '4' still > works just as the newer '801F-0000-...'. > > -- > Luben > > ===== > -- > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Sep 23 13:32:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17575 for ; Mon, 23 Sep 2002 13:32:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NGtkW00597 for ips-outgoing; Mon, 23 Sep 2002 12:55:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12803.mail.yahoo.com (web12803.mail.yahoo.com [216.136.174.38]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g8NGteo00584 for ; Mon, 23 Sep 2002 12:55:40 -0400 (EDT) Message-ID: <20020923165537.81116.qmail@web12803.mail.yahoo.com> Received: from [24.43.193.25] by web12803.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 09:55:37 PDT Date: Mon, 23 Sep 2002 09:55:37 -0700 (PDT) From: Luben Tuikov Subject: Re: iSCSI Boot: Technical Issues To: Mark Bakke Cc: Prasenjit Sarkar , ips@ece.cmu.edu In-Reply-To: <3D8F3C8F.4D4636A1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Mark Bakke wrote: > I see your point. In fact, we would take "4" as > 0004-0000-0000-0000. How about saying: > > Within dashes, zeroes to the left; e.g. 4A == 004A. > Missing dashed fields become zeroes to the right. > > 4A = 004A-0000-0000-0000 > 12C-4-32 = 012C-0004-0032-0000 The examples are great, though the stipulation is not formal as there are _only_ two groups ``within dashes''. A clear an unambiguous stipulation would include this definition plus your examples: Within each group of 4 hexacedimal digits zeros are filled to the right, and groups of zeros are filled to the left. Example: 4A = 004A-0000-0000-0000 12C-4-32 = 012C-0004-0032-0000 The advantage is that is is formal, and unambiguous without a doubt. It implicitly defines what a group is (four hexadecimal digits), if not defined anywhere in the embedding document. -- Luben ===== -- __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ips@ece.cmu.edu Mon Sep 23 13:35:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17671 for ; Mon, 23 Sep 2002 13:35:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NHBI801592 for ips-outgoing; Mon, 23 Sep 2002 13:11:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NHBGo01588 for ; Mon, 23 Sep 2002 13:11:16 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NHB43x021220; Mon, 23 Sep 2002 10:11:04 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NHB8L5029467; Mon, 23 Sep 2002 10:11:08 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA26090; Mon, 23 Sep 2002 10:11:07 -0700 (PDT) Message-ID: <3D8F4B2B.B36AC0AF@cisco.com> Date: Mon, 23 Sep 2002 12:11:07 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Luben Tuikov CC: Prasenjit Sarkar , ips@ece.cmu.edu Subject: Re: iSCSI Boot: Technical Issues References: <20020923165537.81116.qmail@web12803.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Luben- I like it. -- Mark Luben Tuikov wrote: > > --- Mark Bakke wrote: > > I see your point. In fact, we would take "4" as > > 0004-0000-0000-0000. How about saying: > > > > Within dashes, zeroes to the left; e.g. 4A == 004A. > > Missing dashed fields become zeroes to the right. > > > > 4A = 004A-0000-0000-0000 > > 12C-4-32 = 012C-0004-0032-0000 > > The examples are great, though the stipulation is not > formal as there are _only_ two groups ``within dashes''. > > A clear an unambiguous stipulation would include > this definition plus your examples: > > Within each group of 4 hexacedimal digits zeros are > filled to the right, and groups of zeros are filled > to the left. > > Example: > 4A = 004A-0000-0000-0000 > 12C-4-32 = 012C-0004-0032-0000 > > The advantage is that is is formal, and unambiguous > without a doubt. It implicitly defines what a group > is (four hexadecimal digits), if not defined anywhere > in the embedding document. > > -- > Luben > > ===== > -- > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Sep 23 14:27:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19829 for ; Mon, 23 Sep 2002 14:27:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NHk2b03646 for ips-outgoing; Mon, 23 Sep 2002 13:46:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NHjxo03639 for ; Mon, 23 Sep 2002 13:45:59 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Sep 2002 13:45:53 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C33E@CORPMX14> From: Black_David@emc.com To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Boot: Technical Issues Date: Mon, 23 Sep 2002 13:45:43 -0400 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 Except that I think Luben got his left and right reversed ... how about: Within a group of 4 hexadecimal digits, leading zeros MAY be omitted, but at least one digit MUST be present if the group is not otherwise omitted. A trailing zero-valued group or groups MAY be omitted; the recipient MUST assume that omitted groups are zero and MUST suffix the zeroes to the right of the supplied groups. A zero group that is to the left of any non-zero group MUST NOT be omitted. Examples: 4A = 004A-0000-0000-0000 12C-4-32 = 012C-0004-0032-0000 0-5F-C = 0000-005F-000C-0000 Thanks, --David > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Monday, September 23, 2002 1:11 PM > To: Luben Tuikov > Cc: Prasenjit Sarkar; ips@ece.cmu.edu > Subject: Re: iSCSI Boot: Technical Issues > > > Luben- > > I like it. > > -- > Mark > > Luben Tuikov wrote: > > > > --- Mark Bakke wrote: > > > I see your point. In fact, we would take "4" as > > > 0004-0000-0000-0000. How about saying: > > > > > > Within dashes, zeroes to the left; e.g. 4A == 004A. > > > Missing dashed fields become zeroes to the right. > > > > > > 4A = 004A-0000-0000-0000 > > > 12C-4-32 = 012C-0004-0032-0000 > > > > The examples are great, though the stipulation is not > > formal as there are _only_ two groups ``within dashes''. > > > > A clear an unambiguous stipulation would include > > this definition plus your examples: > > > > Within each group of 4 hexacedimal digits zeros are > > filled to the right, and groups of zeros are filled > > to the left. > > > > Example: > > 4A = 004A-0000-0000-0000 > > 12C-4-32 = 012C-0004-0032-0000 > > > > The advantage is that is is formal, and unambiguous > > without a doubt. It implicitly defines what a group > > is (four hexadecimal digits), if not defined anywhere > > in the embedding document. > > > > -- > > Luben > > > > ===== > > -- > > > > __________________________________________________ > > Do you Yahoo!? > > New DSL Internet Access from SBC & Yahoo! > > http://sbc.yahoo.com > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Mon Sep 23 16:15:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23304 for ; Mon, 23 Sep 2002 16:15:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NJWlo10786 for ips-outgoing; Mon, 23 Sep 2002 15:32:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12804.mail.yahoo.com (web12804.mail.yahoo.com [216.136.174.39]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g8NJWjo10781 for ; Mon, 23 Sep 2002 15:32:45 -0400 (EDT) Message-ID: <20020923193244.52997.qmail@web12804.mail.yahoo.com> Received: from [209.47.35.250] by web12804.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 12:32:44 PDT Date: Mon, 23 Sep 2002 12:32:44 -0700 (PDT) From: Luben Tuikov Subject: RE: iSCSI Boot: Technical Issues To: Black_David@emc.com, mbakke@cisco.com Cc: ips@ece.cmu.edu In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C33E@CORPMX14> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Black_David@emc.com wrote: > Except that I think Luben got his left and right > reversed ... how about: > > Within a group of 4 hexadecimal digits, leading > zeros MAY be omitted, but at least one digit MUST > be present if the group is not otherwise omitted. > A trailing zero-valued group or groups MAY be omitted; > the recipient MUST assume that omitted groups are zero > and MUST suffix the zeroes to the right of the supplied > groups. A zero group that is to the left of any > non-zero > group MUST NOT be omitted. With all due respect David, I do not have my left and right reversed. Your definition is more reminicent of _how_ to do it, rather than the true formalizm of _what_ it is. It is also too long, talks about recipient, etc, which are NOT needed since the right/left rule can be applied at either end to the same effect. ``Within each group of 4 hexacedimal digits zeros are filled to the right, and groups of zeros are filled to the left.'' This is a necessary and sufficient definition, the minimal such, and one may derive all of the stipulations which you've mentioned. E.g. the fact that a leading 0000 group must not be omitted, is implicit in this definition. (else, the LUN representation would be ambiguous, contrary to the assumption that it is not.) group: an ordered sequence of 4 hexadecimal digits. (ordered -- human brain assumes without question) within each group ... filled to the right: 4 --> 0004, and etc _recursively_ for as many groups there'd be (max 4 groups in LUN), i.e. 4-4 -> 0004-0004 groups of zeros are filled to the left: that is, this is done to complement to 4 groups, e.g. from the previous example: 0004-0004 -> 0004-0004-0000-0000 The more challenging example 0-4-0-4 is left as an exercise to the reader. :-) Thus, one cannot assume that 4 can somehow be equivalent to 0000-0004-0000-0000, because of the _left_ rule -- that is groups of zeros are ONLY filled to the left! (as the definition stipulates) Nevertheless, the definition I gave is more mathematical, and though clearer, succinct and straightforward, I can see how the average reader could cough up reading it. -- Luben ===== -- __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ips@ece.cmu.edu Mon Sep 23 16:18:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23398 for ; Mon, 23 Sep 2002 16:18:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NJp3t11951 for ips-outgoing; Mon, 23 Sep 2002 15:51:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NJp2o11947 for ; Mon, 23 Sep 2002 15:51:02 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Sep 2002 15:50:54 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C342@CORPMX14> From: Black_David@emc.com To: ltuikov@yahoo.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Boot: Technical Issues Date: Mon, 23 Sep 2002 15:50:50 -0400 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 Luben, ``Within each group of 4 hexadecimal digits zeros are filled to the right, So starting with "C" and filling zeroes to the right, I get "C000". and groups of zeros are filled to the left.'' So starting from "15-2C" and filling to the left, I get "0000-0000-15-2C" before applying the first part of the rule. Perhaps now you wee why I fail to understand: > This is a necessary and sufficient definition, the minimal > such, and one may derive all of the stipulations which > you've mentioned. since I followed the exact words you wrote and got completely wrong results ... that strongly suggests that the "sufficient" part is wrong. The problems here have to do with ambiguous meanings of "to the left" and "to the right" - these have to be cleaned up. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Luben Tuikov [mailto:ltuikov@yahoo.com] > Sent: Monday, September 23, 2002 3:33 PM > To: Black_David@emc.com; mbakke@cisco.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI Boot: Technical Issues > > > --- Black_David@emc.com wrote: > > Except that I think Luben got his left and right > > reversed ... how about: > > > > Within a group of 4 hexadecimal digits, leading > > zeros MAY be omitted, but at least one digit MUST > > be present if the group is not otherwise omitted. > > A trailing zero-valued group or groups MAY be omitted; > > the recipient MUST assume that omitted groups are zero > > and MUST suffix the zeroes to the right of the supplied > > groups. A zero group that is to the left of any > > non-zero > > group MUST NOT be omitted. > > With all due respect David, I do not have my left and right > reversed. > > Your definition is more reminicent of _how_ to do it, > rather than the true formalizm of _what_ it is. > It is also too long, talks about recipient, etc, > which are NOT needed since the right/left rule can > be applied at either end to the same effect. > > ``Within each group of 4 hexacedimal digits zeros are > filled to the right, and groups of zeros are filled > to the left.'' > > This is a necessary and sufficient definition, the minimal > such, and one may derive all of the stipulations which > you've mentioned. > > E.g. the fact that a leading 0000 group must not be > omitted, > is implicit in this definition. (else, the LUN > representation would be ambiguous, contrary to the > assumption that it is not.) > > group: an ordered sequence of 4 hexadecimal digits. > (ordered -- human brain assumes without question) > > within each group ... filled to the right: > 4 --> 0004, and etc _recursively_ for as many groups > there'd be (max 4 groups in LUN), i.e. 4-4 -> 0004-0004 > > groups of zeros are filled to the left: > that is, this is done to complement to 4 groups, > e.g. from the previous example: > 0004-0004 -> 0004-0004-0000-0000 > > The more challenging example 0-4-0-4 is left as > an exercise to the reader. :-) > > Thus, one cannot assume that 4 can somehow be equivalent > to 0000-0004-0000-0000, because of the _left_ rule -- that > is groups of zeros are ONLY filled to the left! > (as the definition stipulates) > > Nevertheless, the definition I gave is more mathematical, > and though clearer, succinct and straightforward, I can > see how the average reader could cough up reading it. > > -- > Luben > > > > > > ===== > -- > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com > From owner-ips@ece.cmu.edu Mon Sep 23 16:18:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23417 for ; Mon, 23 Sep 2002 16:18:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NJdjn11262 for ips-outgoing; Mon, 23 Sep 2002 15:39:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8NJdgo11253 for ; Mon, 23 Sep 2002 15:39:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: SCSI Read/Write commands and data transfer size Date: Mon, 23 Sep 2002 12:37:44 -0700 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290035EED@mail1irv.inside.istor.com> Thread-Topic: SCSI Read/Write commands and data transfer size Thread-Index: AcJjOLBTvYSR/FpeQbufjsyKr2yqgA== From: "Ken Craig" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g8NJdgo11254 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Looking at the SCSI Command and Response PDUs in draft 17 seems to indicate that the maximum transfer size allowed by the protocol is 4G bytes. Since there are SCSI commands that have the capability to transfer up to 4G blocks is there any thought being given to expanding the maximum transfer size in the future to handle those larger transfers? Thanks, Kenneth Ray Craig, Jr. From owner-ips@ece.cmu.edu Mon Sep 23 16:56:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24594 for ; Mon, 23 Sep 2002 16:56:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8NKDPa13429 for ips-outgoing; Mon, 23 Sep 2002 16:13:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12807.mail.yahoo.com (web12807.mail.yahoo.com [216.136.174.42]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g8NKDMo13421 for ; Mon, 23 Sep 2002 16:13:22 -0400 (EDT) Message-ID: <20020923201321.8796.qmail@web12807.mail.yahoo.com> Received: from [209.47.35.250] by web12807.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 13:13:21 PDT Date: Mon, 23 Sep 2002 13:13:21 -0700 (PDT) From: Luben Tuikov Subject: RE: iSCSI Boot: Technical Issues To: Black_David@emc.com Cc: ips@ece.cmu.edu In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C342@CORPMX14> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Black_David@emc.com wrote: > Luben, > > ``Within each group of 4 hexadecimal digits zeros are > filled to the right, > > So starting with "C" and filling zeroes to the right, I > get > "C000". > > and groups of zeros are filled > to the left.'' > > So starting from "15-2C" and filling to the left, I get > "0000-0000-15-2C" before applying the first part of the > rule. > > Perhaps now you wee why I fail to understand: Yes, yes, yes. Exchange left and right then. I must've been having something else on my mind to _completely_ swap those two. The important point is that you understand what I meant: ``Within each group of 4 hexacedimal digits zeros are filled to the left, and groups of zeros are filled to the right.'' This is what I meant and this is what you understood -- _that_ is the important thing. ... as is clear by the examples concurred in our emails. -- Luben ===== -- __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ips@ece.cmu.edu Mon Sep 23 22:30:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04350 for ; Mon, 23 Sep 2002 22:30:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8O1nkh00069 for ips-outgoing; Mon, 23 Sep 2002 21:49:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8O1nio00062 for ; Mon, 23 Sep 2002 21:49:44 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D3E373070E; Mon, 23 Sep 2002 21:49:43 -0400 (EDT) Date: Mon, 23 Sep 2002 18:49:39 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: iSCSI Boot: Technical Issues In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C33E@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 23 Sep 2002 Black_David@emc.com wrote: > Except that I think Luben got his left and right > reversed ... how about: > > Within a group of 4 hexadecimal digits, leading > zeros MAY be omitted, but at least one digit MUST > be present if the group is not otherwise omitted. > A trailing zero-valued group or groups MAY be omitted; > the recipient MUST assume that omitted groups are zero > and MUST suffix the zeroes to the right of the supplied > groups. A zero group that is to the left of any non-zero > group MUST NOT be omitted. > > Examples: > 4A = 004A-0000-0000-0000 > 12C-4-32 = 012C-0004-0032-0000 > 0-5F-C = 0000-005F-000C-0000 Sounds good. Take care, Bill From owner-ips@ece.cmu.edu Tue Sep 24 10:13:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28668 for ; Tue, 24 Sep 2002 10:13:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8ODS7N09804 for ips-outgoing; Tue, 24 Sep 2002 09:28:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8ODS5o09800 for ; Tue, 24 Sep 2002 09:28:05 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Sep 2002 09:21:00 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C349@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI Boot Format Consensus Call Date: Tue, 24 Sep 2002 09:20:59 -0400 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 With my WG co-chair hat on, it's time to close discussion on this so that the authors can produce the next (and we hope final) version of the iSCSI boot draft. I believe the rough consensus of the IP Storage WG on the format of the LUN portion of the DHCP Root Path option when used for an iSCSI-based boot (i.e., string begins with "iscsi:") to be: - 4 groups of 4 hex digits each separated by dashes. Each group represents 16 bits of the LUN. - At most 3 leading zero digits may be omitted in each group. - Trailing zero groups may be omitted. Omitting a group also omits the dash preceding the omitted group. The draft authors should use their best judgment in deciding how to specify this format, but should include examples. Paul Koning's objection to this is noted - this consensus call is made over that objection. Any other comments/objections should be sent to the list ASAP. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Sep 24 11:01:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00963 for ; Tue, 24 Sep 2002 11:01:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8OEM2r13231 for ips-outgoing; Tue, 24 Sep 2002 10:22:02 -0400 (EDT) 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 g8OELvo13218 for ; Tue, 24 Sep 2002 10:21:57 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g8OELpN07159 for ; Tue, 24 Sep 2002 10:21:51 -0400 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 g8OELmk07150; Tue, 24 Sep 2002 10:21:48 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g8OELmr19541; Tue, 24 Sep 2002 10:21:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15760.29948.468928.622463@pkoning.dev.equallogic.com> Date: Tue, 24 Sep 2002 10:21:48 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI Boot Format Consensus Call References: <277DD60FB639D511AC0400B0D068B71E0564C349@CORPMX14> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Black" == Black David writes: Black> The draft authors should use their best judgment in deciding Black> how to specify this format, but should include examples. Paul Black> Koning's objection to this is noted ... I withdraw my objection... paul From owner-ips@ece.cmu.edu Tue Sep 24 11:50:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03411 for ; Tue, 24 Sep 2002 11:50:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8OEt2G15275 for ips-outgoing; Tue, 24 Sep 2002 10:55:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8OBu7o05727 for ; Tue, 24 Sep 2002 07:56:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23469; Tue, 24 Sep 2002 07:54:01 -0400 (EDT) Message-Id: <200209241154.HAA23469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-isns-13.txt Date: Tue, 24 Sep 2002 07:54:01 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Internet Storage Name Service (iSNS) Author(s) : J. Tseng, K. Gibbons et al. Filename : draft-ietf-ips-isns-13.txt Pages : 90 Date : 2002-9-23 This document specifies the iSNS protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices, or any combination thereof. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-23152108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-23152108.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Sep 24 17:57:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13584 for ; Tue, 24 Sep 2002 17:57:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8OLKGT11663 for ips-outgoing; Tue, 24 Sep 2002 17:20:16 -0400 (EDT) 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 g8OLK1o11651 for ; Tue, 24 Sep 2002 17:20:15 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8OLJtHa016005 for ; Tue, 24 Sep 2002 14:19:55 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8OLJrjk019604 for ; Tue, 24 Sep 2002 14:19:54 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA12438 for ; Tue, 24 Sep 2002 14:19:52 -0700 (PDT) Message-ID: <3D90D6F8.249ECEF8@cisco.com> Date: Tue, 24 Sep 2002 16:19:52 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI Naming & Discovery draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I haven't seen any comments on the latest N&D draft, so I assumed that it resolves the last call issues (or at least comes close). I've just submitted N&D draft 07. The only changes from the provisional draft-07 in my working directory were that I redid the reference numbers as reference names (they were out of order anyway). The draft is available at (this path is different from the last message): ftp://ftpeng.cisco.com/mbakke/ips/iscsi/draft-ietf-ips-iscsi-name-disc-07.txt For those who had last call comments, please take a look at the relevant sections to make sure your concerns were addressed. Thanks, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Sep 25 10:57:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28462 for ; Wed, 25 Sep 2002 10:57:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8PEKN313122 for ips-outgoing; Wed, 25 Sep 2002 10:20:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8PC16o05338 for ; Wed, 25 Sep 2002 08:01:06 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22627; Wed, 25 Sep 2002 07:58:57 -0400 (EDT) Message-Id: <200209251158.HAA22627@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-07.txt Date: Wed, 25 Sep 2002 07:58:57 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Naming and Discovery Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-name-disc-07.txt Pages : 22 Date : 2002-9-24 This document provides examples of iSCSI [iSCSI] name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol draft. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-name-disc-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-24150455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-disc-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-24150455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Sep 25 11:50:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00050 for ; Wed, 25 Sep 2002 11:50:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8PFKHA17340 for ips-outgoing; Wed, 25 Sep 2002 11:20:17 -0400 (EDT) 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.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8PFKFo17334 for ; Wed, 25 Sep 2002 11:20:15 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA10999; Wed, 25 Sep 2002 08:20:01 -0700 (PDT) From: Keith McCloghrie Message-Id: <200209251520.IAA10999@cisco.com> Subject: Re: WG Last Call status To: Black_David@emc.com Date: Wed, 25 Sep 2002 08:20:01 -0700 (PDT) Cc: ips@ece.cmu.edu In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C308@CORPMX14> from "Black_David@emc.com" at Sep 18, 2002 08:11:09 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 > The IPS WG has a number of drafts that have recently undergone > ips WG Last Call. Here's a summary of their current state - > for some of these drafts, this is the announcement that they > have completed WG Last Call. > > ... > > Fibre Channel Management MIB - Completed WG Last Call with > one open technical issue involving the possible functions > of entities that support this MIB (FcUnitFunctions). This > issue is believed to be resolved including coordination with > the appropriate T11 document. The resolution will need > to be posted to the list by the folks who came up with it, > and then the next version of this MIB with this change > and the changes from WG Last Call can be submitted to > the ADs/IESG. The resolution is to insert 'storageDevice' as an additional enumeration of FcUnitFunctions. An updated MIB is at ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-03.txt If I don't hear any objections, I will submit this as an I-D. Keith. From owner-ips@ece.cmu.edu Wed Sep 25 14:59:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06680 for ; Wed, 25 Sep 2002 14:59:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8PIQFS01481 for ips-outgoing; Wed, 25 Sep 2002 14:26:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8PIQCo01476 for ; Wed, 25 Sep 2002 14:26:12 -0400 (EDT) Subject: login response for non-login request. From: Michael Morrison To: iSCSI Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Sep 2002 11:22:12 -0700 Message-Id: <1032978132.20055.7.camel@jackallnx.engasic.istor.com> Mime-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In the last paragraph of section 2.2.3 of draft 17 "Once the Login phase has started, if the target receives any PDU except a Login request, it MUST send a Login reject (with Status "invalid during login") and then disconnect. If the initiator receives any PDU except a Login response, it MUST immediately terminate the connection." Shouldn't the target send back a Reject PDU with PROTOCOL ERROR in this case? why would the target send a Login Response to a non-login request? Thanks -- Michael Morrison mmorrison@istor.com ISTOR Networks 7585 Irvine Center Dr. Ste 250 Irvine Ca. 92618 PGP Key ID: http://pgp.mit.edu:11371/pks/lookup?search=0x74C30155&op=index From owner-ips@ece.cmu.edu Wed Sep 25 18:50:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12328 for ; Wed, 25 Sep 2002 18:50:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8PMSSw21785 for ips-outgoing; Wed, 25 Sep 2002 18:28:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8PMSQo21781 for ; Wed, 25 Sep 2002 18:28:26 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id F161A3070A; Wed, 25 Sep 2002 18:28:25 -0400 (EDT) Date: Wed, 25 Sep 2002 15:28:10 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Michael Morrison Cc: iSCSI Subject: Re: login response for non-login request. In-Reply-To: <1032978132.20055.7.camel@jackallnx.engasic.istor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On 25 Sep 2002, Michael Morrison wrote: > In the last paragraph of section 2.2.3 of draft 17 > > "Once the Login phase has started, if the target > receives any PDU except a Login request, it MUST send a Login reject > (with Status "invalid during login") and then disconnect. If the > initiator receives any PDU except a Login response, it MUST > immediately terminate the connection." > > Shouldn't the target send back a Reject PDU with PROTOCOL ERROR in this > case? No. This case explicitly requires a Login Response. > why would the target send a Login Response to a non-login request? You mean besides the fact that's what the standard says? :-) I think the idea is if we're not in FFP, only Login Req/Rsp PDUs are valid. If we're in FFP, everything except them is valid. If the target thinks the initiator broke that rule, it should not also break the rule in telling the initiator that the initiator messed up. Thus a Login Rsp. Also, things should be clearer for the initator. If it thinks it's not in FFP, and it gets a PDU other than Login Rsp, it can immediately flag it as an error. It doesn't have to look and see, "oh, the target is saying I did something wrong." Take care, Bill From owner-ips@ece.cmu.edu Wed Sep 25 18:51:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12355 for ; Wed, 25 Sep 2002 18:51:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8PMCCB20595 for ips-outgoing; Wed, 25 Sep 2002 18:12:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8PLOBo16869 for ; Wed, 25 Sep 2002 17:24:12 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.6/8.12.6) with ESMTP id g8PLO64K012626; Wed, 25 Sep 2002 17:24:06 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.6/8.12.6/Submit) with ESMTP id g8PLO6Uf012623; Wed, 25 Sep 2002 17:24:06 -0400 Date: Wed, 25 Sep 2002 17:24:06 -0400 (EDT) From: "Robert D. Russell" To: Michael Morrison cc: iSCSI Subject: Re: login response for non-login request. In-Reply-To: <1032978132.20055.7.camel@jackallnx.engasic.istor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael: The simplest answer is because the target is allowed to send only Login Response PDUs during login phase, and it is therefore illegal for it to send a Reject PDU. Best, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On 25 Sep 2002, Michael Morrison wrote: > In the last paragraph of section 2.2.3 of draft 17 > > "Once the Login phase has started, if the target > receives any PDU except a Login request, it MUST send a Login reject > (with Status "invalid during login") and then disconnect. If the > initiator receives any PDU except a Login response, it MUST > immediately terminate the connection." > > Shouldn't the target send back a Reject PDU with PROTOCOL ERROR in this > case? > > why would the target send a Login Response to a non-login request? > > Thanks > > > -- > Michael Morrison > mmorrison@istor.com > ISTOR Networks > 7585 Irvine Center Dr. Ste 250 > Irvine Ca. 92618 > PGP Key ID: > http://pgp.mit.edu:11371/pks/lookup?search=0x74C30155&op=index > > From owner-ips@ece.cmu.edu Thu Sep 26 11:27:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11741 for ; Thu, 26 Sep 2002 11:27:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8QEKE829703 for ips-outgoing; Thu, 26 Sep 2002 10:20:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8QCZco22040 for ; Thu, 26 Sep 2002 08:35:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04233; Thu, 26 Sep 2002 08:33:44 -0400 (EDT) Message-Id: <200209261233.IAA04233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org, ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-isnsoption-03.txt,.pdf Date: Thu, 26 Sep 2002 08:33:44 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Options for Internet Storage Name Service Author(s) : J. Tseng et al. Filename : draft-ietf-dhc-isnsoption-03.txt,.pdf Pages : 13 Date : 2002-9-25 This document describes the DHCP option to allow iSNS clients using DHCP to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-isnsoption-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-25142204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-25142204.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Sep 26 11:30:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11865 for ; Thu, 26 Sep 2002 11:29:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8QEKGo29714 for ips-outgoing; Thu, 26 Sep 2002 10:20:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8QCaco22117 for ; Thu, 26 Sep 2002 08:36:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04439; Thu, 26 Sep 2002 08:34:44 -0400 (EDT) Message-Id: <200209261234.IAA04439@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-boot-07.txt Date: Thu, 26 Sep 2002 08:34:44 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Bootstrapping Clients using the iSCSI Protocol Author(s) : P. Sarkar, D. Missimer, C. Sapuntzakis Filename : draft-ietf-ips-iscsi-boot-07.txt Pages : 10 Date : 2002-9-25 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. iSCSI is a proposed transport protocol for SCSI that operates on top of TCP[12]. This memo describes a standard mechanism to enable clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server, assuming this information is not available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-boot-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-boot-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-boot-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-25142352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-boot-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-boot-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-25142352.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Sep 27 13:02:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00266 for ; Fri, 27 Sep 2002 13:02:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8RGkGx29077 for ips-outgoing; Fri, 27 Sep 2002 12:46:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8RGk9o29062 for ; Fri, 27 Sep 2002 12:46:14 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Sep 2002 12:46:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C380@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS-ALL: iSCSI stringprep WG Last Call Date: Fri, 27 Sep 2002 12:45:55 -0400 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 All, We would like to announce IPS Working Group Last call for the String Profile for iSCSI Names. Details: Document: String Profile for iSCSI Names URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-02.txt Note: This draft specifies the application to iSCSI names of "Preparation of Internationalized Strings ("stringprep")", draft-hoffman-stringprep-06 (under consideration by the IESG for Proposed Standard). The iSCSI stringprep draft currently references version -03 of the main stringprep draft. At the completion of WG Last Call, this reference will be updated to the current version and any changes needed to bring the iSCSI stringprep draft into alignment with the main stringprep draft will be applied. Last call period: 2 Weeks Submit comments no later than: Sunday, October 13, 2002 at 5pm EST Editor: Mark Bakke (mbakke@cisco.com) Please submit editorial comments directly to Mark, with copy to David Black (black_david@emc.com), and Elizabeth Rodriguez (erodrigu@brocade.com) Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector. Thanks, David Black & Elizabeth Rodriguez IPS co-chairs --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 27 13:08:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00470 for ; Fri, 27 Sep 2002 13:08:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8RG7tn26284 for ips-outgoing; Fri, 27 Sep 2002 12:07:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8RG7so26280 for ; Fri, 27 Sep 2002 12:07:54 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Sep 2002 12:07:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C37F@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS-ALL: iSNS WG Last Call Date: Fri, 27 Sep 2002 12:07:15 -0400 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 All, We would like to announce IPS Working Group Last call for the Internet Storage Name Service (iSNS). Details: Document: Internet Storage Name Service (iSNS) URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt Note: There are formatting (line length) problems with this draft. It may get updated to -14 shortly to correct them without change to its content. Last call period: 2 Weeks Submit comments no later than: Sunday, October 13, 2002 at 5pm EST Editor: Josh Tseng Please submit editorial comments directly to Josh, with copy to David Black (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector. Thanks, David Black & Elizabeth Rodriguez IPS co-chairs --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Sep 27 13:09:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00526 for ; Fri, 27 Sep 2002 13:09:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8RGmZ329298 for ips-outgoing; Fri, 27 Sep 2002 12:48:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8RGmYo29294 for ; Fri, 27 Sep 2002 12:48:34 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Sep 2002 12:48:29 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C381@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS-ALL: iFCP MIB WG Last Call conclusion Date: Fri, 27 Sep 2002 12:48:24 -0400 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 The iFCP MIB (draft-ietf-ips-ifcp-mib-02.txt) has completed IPS WG Last Call with editorial comments only. A revised version incorporating those comments will be prepared, and after approval by our MIB expert (Keith McCloghrie), it will be forwarded to the ADs/IESG. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Sep 28 10:47:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06049 for ; Sat, 28 Sep 2002 10:47:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8SEDQH22802 for ips-outgoing; Sat, 28 Sep 2002 10:13:26 -0400 (EDT) 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 g8SEDPo22797 for ; Sat, 28 Sep 2002 10:13:25 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g8SEDIKq027102; Sat, 28 Sep 2002 16:13:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8SEDITS010988; Sat, 28 Sep 2002 16:13:18 +0200 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: iSCSI version 18 draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 28 Sep 2002 17:13:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/09/2002 17:13:17, Serialize complete at 28/09/2002 17:13:17 Content-Type: multipart/alternative; boundary="=_alternative 004DBB9AC2256C42_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004DBB9AC2256C42_= Content-Type: text/plain; charset="us-ascii" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-18.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-18.pdf This version completely replaces: draft-ietf-ips-iscsi-17.txt and pdf The changes marked on the pdf are cumulative form version 16 and are all typos (some old and some introduced by me when going to 16). Julian Satran - IBM Research Laboratory at Haifa --=_alternative 004DBB9AC2256C42_= Content-Type: text/html; charset="us-ascii"


On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-18.txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-18.pdf


This version completely replaces:

draft-ietf-ips-iscsi-17.txt and pdf


The changes marked on the pdf are cumulative form version 16 and are all typos (some  old and some introduced by me when going to 16).

Julian Satran - IBM Research Laboratory at Haifa



































--=_alternative 004DBB9AC2256C42_=-- From owner-ips@ece.cmu.edu Sat Sep 28 12:33:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07249 for ; Sat, 28 Sep 2002 12:33:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8SFvN227978 for ips-outgoing; Sat, 28 Sep 2002 11:57:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8SFvMo27973 for ; Sat, 28 Sep 2002 11:57:22 -0400 (EDT) Received: from sahara ([12.81.6.184]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20020928155716.DCQO8019.mtiwmhc13.worldnet.att.net@sahara>; Sat, 28 Sep 2002 15:57:16 +0000 Message-ID: <200209280900240925.03C74F31@mailhost.worldnet.att.net> In-Reply-To: <1032978132.20055.7.camel@jackallnx.engasic.istor.com> References: <1032978132.20055.7.camel@jackallnx.engasic.istor.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Sat, 28 Sep 2002 09:00:24 -0700 Reply-To: sganguly@opulentsystems.com From: "Sukanta Ganguly" To: "Michael Morrison" , "IPS" Subject: Re: login response for non-login request. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g8SFvMo27974 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Michael, It makes perfect sense. In case of processing the Login request the Target is in the Login processing state machine, if you will. Hence sending a Login reject is the most appropriate response. The development process also stays simple in that manner. Regards Sukanta Ganguly Opulent Systems *********** REPLY SEPARATOR *********** On 9/25/2002 at 11:22 AM Michael Morrison wrote: >In the last paragraph of section 2.2.3 of draft 17 > >"Once the Login phase has started, if the target >receives any PDU except a Login request, it MUST send a Login reject >(with Status "invalid during login") and then disconnect. If the >initiator receives any PDU except a Login response, it MUST >immediately terminate the connection." > >Shouldn't the target send back a Reject PDU with PROTOCOL ERROR in this >case? > >why would the target send a Login Response to a non-login request? > >Thanks > > >-- >Michael Morrison >mmorrison@istor.com >ISTOR Networks >7585 Irvine Center Dr. Ste 250 >Irvine Ca. 92618 >PGP Key ID: >http://pgp.mit.edu:11371/pks/lookup?search=0x74C30155&op=index From owner-ips@ece.cmu.edu Sat Sep 28 19:33:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13648 for ; Sat, 28 Sep 2002 19:33:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8SMqEV19636 for ips-outgoing; Sat, 28 Sep 2002 18:52:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8SMqCo19630 for ; Sat, 28 Sep 2002 18:52:13 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8SMqBte061768; Sat, 28 Sep 2002 18:52:11 -0400 Received: from d03nm014.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8SMqA8v146086; Sat, 28 Sep 2002 16:52:10 -0600 X-Priority: 1 (High) Importance: Normal Subject: SCSI: login response for non-login request. To: sganguly@opulentsystems.com Cc: "Michael Morrison" , "IPS" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sat, 28 Sep 2002 15:51:37 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 09/28/2002 04:52:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This is another reminder to folks on this reflector to use the prefix iSCSI: at the beginning of the subject line, as is shown in this reply. . . . 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, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Sukanta Ganguly" @ece.cmu.edu on 09/28/2002 09:00:24 AM Please respond to sganguly@opulentsystems.com Sent by: owner-ips@ece.cmu.edu To: "Michael Morrison" , "IPS" cc: Subject: Re: login response for non-login request. Hi Michael, It makes perfect sense. In case of processing the Login request the Target is in the Login processing state machine, if you will. Hence sending a Login reject is the most appropriate response. The development process also stays simple in that manner. Regards Sukanta Ganguly Opulent Systems *********** REPLY SEPARATOR *********** On 9/25/2002 at 11:22 AM Michael Morrison wrote: >In the last paragraph of section 2.2.3 of draft 17 > >"Once the Login phase has started, if the target >receives any PDU except a Login request, it MUST send a Login reject >(with Status "invalid during login") and then disconnect. If the >initiator receives any PDU except a Login response, it MUST >immediately terminate the connection." > >Shouldn't the target send back a Reject PDU with PROTOCOL ERROR in this >case? > >why would the target send a Login Response to a non-login request? > >Thanks > > >-- >Michael Morrison >mmorrison@istor.com >ISTOR Networks >7585 Irvine Center Dr. Ste 250 >Irvine Ca. 92618 >PGP Key ID: >http://pgp.mit.edu:11371/pks/lookup?search=0x74C30155&op=index From owner-ips@ece.cmu.edu Mon Sep 30 10:25:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05630 for ; Mon, 30 Sep 2002 10:25:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8UDWxv00574 for ips-outgoing; Mon, 30 Sep 2002 09:32:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8UDWuo00569 for ; Mon, 30 Sep 2002 09:32:56 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8UDWgJ02747 for ; Mon, 30 Sep 2002 09:32:42 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g8UDWf719598 for ; Mon, 30 Sep 2002 09:32:41 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 09:32:41 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C39B@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Reminder: final versions of drafts Date: Mon, 30 Sep 2002 09:32:37 -0400 Importance: high X-Priority: 1 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 A reminder to draft authors - the final version of an Internet-Draft for submission to the ADs/IESG MUST comply with the guidelines found at the following two URLs: http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ID-nits.html In addition, as a WG document, only the first IPR statement is acceptable, namely: This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. The old adage about "a stitch in time saves nine" applies to checking all of this now vs. having it discovered later in the process. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Sep 30 13:58:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15040 for ; Mon, 30 Sep 2002 13:58:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g8UHAQF24695 for ips-outgoing; Mon, 30 Sep 2002 13:10:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g8UHANo24691 for ; Mon, 30 Sep 2002 13:10:23 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 13:10:17 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C3A2@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS-ALL: Draft status and Atlanta Date: Mon, 30 Sep 2002 13:10:09 -0400 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 For those who may not have been following everything, a list of the current status of the WG's drafts follows. Please let me know if there are any errors/omissions/ oversights on this list. The WG co-chairs expect/hope to have essentially all of our drafts in or through WG Last Call by the time of the Atlanta meeting. So, there may not be much to discuss in Atlanta - if anyone has something that they would like to see on the IPS Atlanta agenda, please get a draft written and submitted (e.g., the igate draft authors need to get their draft in). We've currently reserved a 2 hour meeting slot for IPS in Atlanta, but this may get adjusted downward if there isn't enough material to make good use of it. Thanks, --David IETF IP Storage (ips) Working Group WG Internet-Draft Status: September 2002 ------------------------------------ Summary: 23 documents total: - 1 has been published as an RFC - 1 is in the RFC Editor queue - 4 have been forwarded to ADs/IESG after completing WG Last Call - 6 have completed WG Last Call with all issues resolved. Next versions with editorial updates will be forwarded to ADs/IESG. - 2 are in WG Last Call - 3 will not be published as RFCs (WG Last Call comment resolution) That leaves 6 drafts still to go through WG Last Call. At least 4 of these should go through WG Last Call by the end of October. NOTE: PDF versions for some drafts are for ease of review only. The definitive format for RFCs is text, and it is the text versions that will be forwarded to the IESG for publication as RFCs. -- Security for all IPS protocols draft-ietf-ips-security-16.txt To be a proposed standard RFC. Has completed WG Last Call and been submitted to the ADs/IESG. -- iSCSI draft-ietf-ips-iscsi-17.txt draft-ietf-ips-iscsi-17.pdf To become a proposed standard RFC. Has completed WG Last Call, and -17 version reflects the resulting changes. A minor problem has been discovered with one of the changes. This will be fixed in the -18 version, which will be submitted to the ADs/IESG when it appears. draft-ietf-ips-iscsi-boot-07.txt To become a proposed standard RFC. WG Last Call resulted in a few issues, which have been resolved on the list. The resulting -07 version of the draft will be forwarded to the ADs/IESG shortly. draft-ietf-ips-iscsi-reqmts-06.txt Has been published as RFC 3347. draft-ietf-ips-iscsi-name-disc-07.txt To become an informational RFC. Has completed WG Last Call - all technical issues raised in WG Last Call have been resolved. The -07 version contains the resulting changes, but a -08 version is needed to correct an oversight in the boilerplate text. That version will be forwarded to the ADs/IESG when it appears. draft-ietf-ips-iscsi-slp-03.txt To become a proposed standard RFC. WG Last Call expected in the next month, probably on a -04 version. draft-ietf-ips-iscsi-string-prep-02.txt To become a proposed standard RFC. Currently in WG Last Call, which will conclude on October 13. draft-ietf-ips-iscsi-mib-05.txt To be a proposed standard RFC. WG Last Call expected shortly on the forthcoming -06 version. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/Visio-ietf-iscsi-uml-model-05.pd f draft-ietf-ips-auth-mib-01.txt To be a proposed standard RFC. User identity information MIB split out from basic iSCSI MIB for more general use, but currently only being used for iSCSI. Forthcoming -02 version will go to WG Last Call with the iSCSI MIB shortly. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/auth-mib/Visio-ietf-ips-auth-mib-01.pdf draft-sheinwald-iscsi-crc-01.txt The IESG has approved publication as an informational RFC; this draft is currently in the RFC Editor Queue. -- FC Common Encapsulation draft-ietf-ips-fcencapsulation-08.txt draft-ietf-ips-fcencapsulation-08.pdf To be a proposed standard RFC. Has completed WG Last Call and been forwarded to ADs/IESG. -- FCIP draft-ietf-ips-fcovertcpip-12.txt draft-ietf-ips-fcovertcpip-12.pdf To be a proposed standard RFC. Has completed WG Last Call and been forwarded to ADs/IESG. draft-ietf-ips-fcip-slp-03.txt To be a proposed standard RFC. Has completed WG Last Call, next (-04) version incorporating last call comments will be forwarded to ADs/IESG. draft-ietf-ips-fcip-mib-01.txt To be a proposed standard RFC. Has been restructured to align with new structure of FC Management MIB and been reviewed by the WG's MIB Technical Expert. Next revision should be ready for WG Last Call. -- iFCP draft-ietf-ips-ifcp-13.txt draft-ietf-ips-ifcp-13.pdf To be a proposed standard RFC. Has completed WG Last Call and been forwarded to ADs/IESG. draft-ietf-ips-ifcp-mib-02.txt To be a proposed standard RFC. Has completed WG Last Call. Next version with editorial updates will be forwarded to ADs/IESG. -- iSNS draft-ietf-ips-isns-13.txt To be a proposed standard RFC. Currently in WG Last Call, which will conclude on October 13. Formatting problems in the -13 draft may result in a -14 with no change to content. The related draft-ietf-dhc-isnsoption-03.txt requests allocation of a DHC option code for iSNS, and is being handled in the DHC WG. draft-ietf-ips-isns-mib-02.txt To be a proposed standard RFC. WG Last Call should be within next month. -- SCSI MIB draft-ietf-ips-scsi-mib-03.txt To be a proposed standard RFC. -03 version is close to done. Structure diagram available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-uml-model-01.pdf Diagram showing relationships among SCSI family of MIBS available at: ftp://ftpeng.cisco.com/mbakke/ips/scsi-mib/Visio-scsi-mib-family-01.pdf -- Fibre Channel Management MIB draft-ietf-ips-fcmgmt-mib-02.txt To be a proposed standard RFC. This work has been transferred to the IPS WG from the IPFC WG, and the scope has been expanded to include replacement of the FC Fabric Element MIB (RFC 2837). Has completed WG Last Call. -03 version with minor changes resulting from WG Last Call will be forwarded to ADs/IESG. -- Last Call Drafts draft-ietf-ips-fcencap-wglc-01.txt draft-ietf-ips-fcip-wglc-02.txt draft-ietf-ips-ifcp-wglcc-00.txt These drafts will not be published as RFCs. They exist solely to record the resolution of WG Last Call comments on the FC Encapsulation, FCIP and iFCP drafts. ----- Document Completion Guesstimates ------ A rough guess is 2 remaining waves of documents: (1) WG Last Call by end of October for: - iSNS (in WG Last Call now) - iSNS MIB - iSCSI stringprep (in WG Last Call now) - iSCSI SLP - iSCSI MIB - iSCSI Auth MIB iSNS MIB WG Last Call will follow iSNS WG Last Call. (2) A couple of MIBs still need some work. The WG co-chairs would like to start WG Last Call on these prior to Atlanta, but some work is still needed: - FCIP MIB - SCSI MIB -- Potential Additional Work Additional drafts may be forthcoming in the future on: - Issues involved in gateways and bridges between iSCSI and other SCSI protocols - Additional MIB(s) that extend the FC Management MIB to cover additional aspects of Fibre Channel --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------